ubuntu maas что это
Что такое Ubuntu Maas?
Объясните на простом языке? Для чего он используется? Как я понял, для развертывания серверов на удаленных железяках? Или я неправильно понял?
malware as a service?
Metal as a Service
Насколько я понимаю, для быстрого превращения серверной стойки с пустыми серверами в серверную стойку с серверами на убунте.
MAAS предназначен для быстрого и удобного развертывания Ubuntu конфигураций на множестве серверов с использованием техник, используемых в облачных платформах. Но в отличие от облачных платформ, выделение ресурсов на таком кластере происходит на уровне физических серверов, а не виртуальных окружений.
В основе MAAS лежит простая идея PXE-загрузки и инструмент для развертывания и сопровождения окружений Juju, который позволяет превратить процесс установки и настройки ПО в чрезвычайно простую задачу, выполняемую с использованием двух-трёх команд.
Ручная настройка ОС и сервисов на каждом сервере-ноде в кластере заняла бы слишком много времени, тогда как инструменты типа MAAS позволяют развернуть целый кластер буквально за несколько минут.
MAAS даёт мощь реального железа и гибкость виртуальных серверов.
для быстрого превращения серверной стойки с пустыми серверами в серверную стойку с серверами на убунте
а образы ubuntu server из сети будут скачиваться? там есть вход из браузера под http://192.168.0.58/MAAS
Но в отличие от облачных платформ, выделение ресурсов на таком кластере происходит на уровне физических серверов, а не виртуальных окружений.
ОК. А прокатит ли на виртуалбоксе, если я буду создавать 10 машин? Или это уже слишком требовательно будет к железу? У меня на компе 4 гига оперативки.
13 причин использовать Ubuntu Server. Часть 1.
У многих администраторов есть предубеждение к Ubuntu Server. Дескать Ubuntu попсовая и сделана для десктопа, какой из неё сервер? Несмотря на успех Canonical на рынке десктопа, где единая Ubuntu охватывает разные устройства по своей архитектуре и форм-факторам, никто не забывает рынок серверов и облачных вычислений.
Разработчик Canonical Alan Pope написал в твиттере, а другой разработчик Jono Bacon подтвердил, что интернет-аукцион-магазин eBay, интернет-сервис VoD Netflix, телевизионное шоу по подписке Hulu используют или начали миграцию на Ubuntu Server.
OpenStack и облака.
Canonical поддерживает OpenStack в течении 3 лет. У Canonical есть автоматические тесты для OpenStack, которые вызываются каждый день и после каждого коммита. Только Canonical бэкпортирует новые версии OpenStack в свой стабильный и долгоподерживаемый релиз Ubuntu 12.04 LTS. Это означает, что если вы хотите свежайший OpenStack на стабильной платформе, то в Ubuntu вы это получите. Такого не делает больше никто.
Canonical и Inktank сотрудничают вместе для оказания лучшей поддержки Ceph в составе OpenStack на Ubuntu Server. Клиенты Canonical, использующие подписку Ubuntu Advantage, могут обратиться по любому вопросу, касающегося Ceph, напрямую к Canonical.
У Canonical есть автоматические тесты для Ceph, которые вызываются каждый день и после каждого коммита.
У Canonical есть инструмент JuJu, который, образно говоря, можно назвать apt для служб. Благодаря JuJu, Ceph легко разворачивается на любом количестве серверов и легко конфигурируется для работы с другими сервисами.
В основе MAAS лежит простая идея PXE-загрузки и инструмент для развертывания и сопровождения окружений Juju, который позволяет превратить процесс установки и настройки ПО в чрезвычайно простую задачу, выполняемую с использованием двух-трех команд.
Ручная настройка ОС и сервисов на каждом сервере-ноде в кластере заняла бы слишком много времени, тогда как инструменты типа MAAS позволяют развернуть целый кластер буквально за несколько минут.
MAAS даёт мощь реального железа и гибкость виртуальных серверов.
Hardware Enablement Stack
Ubuntu предоставляет механизм LTS Enablement Stack, который позволяет использовать для нового железа новые ядра linux. Но с другой стороны LTS Enablement Stack позволяет остаться на LTS платформе и использовать стабильное окружение.
Другими словами, вам гарантируют работу бэкпортированных линукс ядер в вашем стабильном релизе Ubuntu LTS.
Factor Group Blog
Как и облачные решения, MAAS позволяет представить кластер в виде пула ресурсов, которые могут быть запрошены в любой момент времени. Однако, в отличие от облачных платформ, выделение ресурсов на таком кластере происходит на уровне физических серверов, а не виртуальных. MAAS объединяет множество серверов в пул, а затем отдает команды с помощью веб или CLI-интерфейса на установку необходимой операционной системы.
В основе MAAS используется PXE окружение с возможностью загрузки с различных подготовленных образов операционных систем, который позволяет превратить процесс установки и настройки ОС в чрезвычайно простую задачу, выполняемую с использованием двух-трех команд, а также позволяет автоматически вести инвентаризацию серверов при их добавлении в пул.
MAAS спроектирован с учетом возможности масштабирования от нескольких серверов до тысяч серверов при необходимости. Это достигается за счет современной архитектуры решения. Ключевые компоненты MAAS:
С помощью простого Web interface MAAS позволяет, устанвливать, обновлять и удалять сервера по желанию. Кроме того по каждому серверу доступна инвенторизационная информация, по количеству RAM, CPU, Storage, Network interfaces, а также полный XML вывод «lshw» утилиты.
API MAAS может быть использован с помощью утилиты Juju для развертывания на серверных ресурсах различных приложений из магазина приложений JuJu.
How it works
MAAS has a tiered architecture with a central postgres database backing a ‘Region Controller (regiond)’ that deals with operator requests. Distributed Rack Controllers (rackd) provide high-bandwidth services to multiple racks. The controller itself is stateless and horizontally scalable, presenting only a REST API.
High availability in MAAS
MAAS is mission critical service, providing infrastructure coordination upon which HPC and cloud infrastructures depend. High availability in the region controller is achieved at the database level. The region controller will automatically switch gateways to ensure high availability of services to network segments in the event of a rackd failure.
Rackds are not in the primary data path, they are not routers or otherwise involved in the flow of data traffic, this diagram shows only the role that MAAS Rackds play in providing local services to racks, and the way in which they can cover for one another in the event of a failure.
MAAS can scale from a small set of servers to many racks of hardware in a datacentre. High-bandwidth activities (such as the initial operating system installation) are handled by the distributed gateways enabling massively parallel deployments.
Protocols
Initial machine inventory and commissioning is done from an ephemeral Ubuntu image that works across all major servers from all major vendors. It is possible to add custom scripts for firmware updates and reporting.
Physical availability zones
In keeping with the notion of a ‘physical cloud’ MAAS lets you designate machines as belonging to a particular availability zone. It is typical to group sets of machines by rack or room or building into an availability zone based on common points of failure. The natural boundaries of a zone depend largely on the scale of deployment and the design of physical interconnects in the data centre.
Nevertheless the effect is to be able to a scale-out service across multiple failure domains very easily, just as you would expect on a public cloud. Higher-level infrastructure offerings like OpenStack or Mesos can present that information to their API clients as well, enabling very straightforward deployment of sophisticated solutions from metal to container.
The MAAS API allows for discovery of the zones in the region. Chef, Puppet, Ansible and Juju can transparently spread services across the available zones.
Users can also specifically request machines in particular AZs.
There is no forced correlation between a machine location in a particular rack and the zone in which MAAS will present it, nor is there a forced correlation between network segment and rack. In larger deployments it is common for traffic to be routed between zones, in smaller deployments the switches are often trunked allowing subnets to span zones.
By convention, users are entitled to assume that all zones in a region are connected with very high bandwidth that is not metered, enabling them to use all zones equally and spread deployments across as many zones as they choose for availability purposes.
The node lifecycle
Each machine (“node”) managed by MAAS goes through a lifecycle — from its enlistment or onboarding to MAAS, through commissioning when we inventory and can setup firmware or other hardware-specific elements, then allocation to a user and deployment, and finally they are released back to the pool or retired altogether.
New machines which PXE-boot on a MAAS network will be enlisted automatically if MAAS can detect their BMC parameters. The easiest way to enlist standard IPMI servers is simply to PXE-boot them on the MAAS network.
Commissioning
Detailed inventory of RAM, CPU, disks, NICs and accelerators like GPUs itemised and usable as constraints for machine selection. It is possible to run your own scripts for site-specific tasks such as firmware updates.
Ready
A machine that is successfully commissioned is considered “Ready”. It will have configured BMC credentials (on IPMI based BMCs) for ongoing power control, ensuring that MAAS can start or stop the machine and allocate or (re)deploy it with a fresh operating system.
Allocated
Ready machines can be allocated to users, who can configure network interface bonding and addressing, and disks, such as LVM, RAID, bcache or partitioning.
Deploying
Users then can ask MAAS to turn the machine on and install a complete server operating system from scratch without any manual intervention, configuring network interfaces, disk partitions and more.
Releasing
When a user has finished with the machine, they can release it back to the shared pool of capacity. You can ask MAAS to ensure that there is a full disk-wipe of the machine when that happens.
Сам себе AWS. Часть 0
Доброго времени суток, %username%!
Сегодня я расскажу тебе, как при помощи напильника, кучки серверов и такой-то матери собрать что-то смутно похожее на EC2 от Amazon.
Статья получилась больше обзорная, так что придётся разбить её на несколько частей.
Я тебя слепила из того что было.
Это — демостенд, 6 х i5-3570T/8Gb RAM/рассыпуха всяких дисков.
Как-то встала у меня задача упорядочить все офисные сервисы, хаотично разбросанные по зоопарку серверов и операционок (у меня тут даже OpenBSD где-то бегает). И так вышло, что я давно хотел посмотреть на облака, а реального тесткейса не было. Так я и решил изучить, что нынче есть интересного в мире open-source и можно ли это применить в боевых условиях.
На текущий момент я посмотрел такие решения как MaaS + Juju имени Cannonical, RDO имени RedHat, Foreman с плагином и Fuel.
Забегая немного вперёд — Fuel для меня оказался самым адекватным, но пройдёмся по порядку.
Простой и аскетичный дизайн
MaaS представляет собою концепцию Metal as a Service, по сути — занимается менеджментом «голого» железа. Вы можете выбрать какую версию убунты установить на тот или иной сервер, узнать его ТТХ и по сути всё. Сервера можно разделять по регионам доступности. Так же умеет работать с виртуалками через libvirtd. Интересное начинается когда вы прикручиваете ко всему этому Juju — теперь вы можете сказать «установи мне бложек» и оно выберет из списка доступного метала железку и накатит туда весь необходимый софт, как то mysql, apache, wordpress/drupal/etc. Мило, удобно, но когда я попытался подобным образом развернуть OpenStack, всё встало колом. Возможно я делал что-то не так, возможно что-то не так делали создатели конфигов для juju. Но в итоге мне не удалось нормально развернуть контроллер на одном сервере. Под каждый компонент контроллера оно хотело отдельную железку. Т.е. нужен вам keystone?, не вопрос — вот отдельный сервер под keystone. И так со всем. Ко всему этому добавилась моя нелюбовь к ubuntu как серверной ОС, так что решение пришлось отложить.
Foreman
Тысячи графиков, начальство будет счастливо
Сам по себе The Foreman это вебинтерфейс для управления puppet’овыми конфигами и в этой роли он вполне удобен и интересен. Но помимо этого он умеет и provisioning. Так что, как и с MaaS, вы можете сказать серверу грузиться по сети, а дальше управлять установкой через удобную вебморду. Имея такое удобное решение сложно было не прийти к идее разворачивания клауда на его основе. И всякие народные умельцы начали это потихоньку реализовывать. На текущий момент в nightly build’ах есть плагин foreman-installer-staypuft. С его помощью вы устанавливаете как сам Foreman, так и необходимые плагины. Удобство этой конструкции в том, что буквально из одной точки вы можете установить ОС (причём как Linux-based, так и Windows), после чего раздать нужные роли и установить необходимый набор софта. Или развернуть клауд, и опять же из вебморды foreman’а назначить роли для инстансов в этом клауде. Есть только одно существенное НО — ночные сборки достаточно нестабильны.
Возможно со временем это решение доделают и оно будет вполне production-ready, но на текущий момент можно только баловаться и отправлять багрепорты разработчикам. Благо они активно читают гугло-группу.
У них похоже есть дизайнер
На текущий момент самое совершенное решение по разворачиванию клауда от достаточно именитой компании Mirantis. По сути — это заточенный исключительно на разворачивания клауда софт. Как и rdo/foreman — делает он это с помощью puppet’овых скриптов. Установка controller + 3 compute node занимает около 30 минут, зависит от скорости ваших винтов. Можно создавать как High availability, так и non-HA кластер. Умеет из коробки работать с Ceph, в версии 5.1 так же добавили драйвера для Mellanox’овых сетевух, что в комбинации LVM+Infiniband позволяет использовать RDMA (пока не проверял в действии, жду когда приедет свитч и сетевухи). Огромным плюсом является наличие большого количества документации.
В следующий раз я расскажу вам что же собственно у меня вышло сделать при помощи Fuel, немного про особенности ceph, как использовать несколько гипервизоров в одном клауде и как упростить себе жизнь автоматизировав всё и вся. А если ко мне таки доедет InfiniBand, то, возможно, и про особенности его работы с ceph и openstack.