Содержание статьи
Не так давно на страницах рубрики syn/ack мы рассматривали
открытую систему для
создания облачных сервисов Eucalyptus, которая лежит в основе Ubuntu
Enterprise Cloud. Сегодня мы поговорим о его главном конкуренте, одним из
разработчиков которой выступает агентство NASA, а среди покровителей числятся
Intel, AMD, Dell еще два десятка именитых компаний.
Мы привыкли к тому, что все наши приложения, сетевые сервисы и базы данных
работают на реальных, осязаемых машинах, которые необходимо покупать,
доставлять, выделять площадь для установки, настраивать и следить за
работоспособностью. Однако времена меняются и на смену дорогостоящим железным
серверам приходят серверы виртуальные, которые гораздо дешевле, удобнее в
обслуживании и совершенно не боятся экспериментов и чрезвычайных ситуаций.
Спустя несколько секунд после клика по кнопке "купить" наш новенький сервер
готов к работе и мы даже не подозреваем о том, как он функционирует, какую часть
серверной занимает и сколько выделяет тепла. А также не заботимся о
своевременной замене жестких дисков и других компонентов системы. Все это
происходит где-то далеко в облаке, скрыто от наших глаз.
Виртуальные серверы получили очень широкое распространение после открытия
сервиса Amazon EC2, который стал эталоном для облачных сервисов уровня IaaS (это
когда в аренду сдается целая инфраструктура для управления виртуальными
серверами, а не выделенная виртуальная машина или приложение). EC2 позволил
организациям отказаться от собственных серверных и половины штата системных
администраторов в пользу парка удобных в сопровождении удаленных серверов,
которые можно использовать для любых нужд, увеличивая количество машин по мере
надобности. Сервис, созданный Amazon, оказался не только удобным в
использовании, но и весьма технологичным, так что многие, кто пытался создать
облако для своих нужд или конкуренции с Amazon, терпели неудачу. При всей
простоте самой идеи, облачный сервис уровня IaaS очень труден в реализации,
потому как требует создания умной, самоконтролируемой инфраструктуры, которая бы
умела равномерно распределять нагрузку между физическими машинами, не боялась
расширения и была устойчива к сбоям оборудования. Такое было под силу только
большим коммерческим организациям, которые просили за свои продукты немалых
денег, а тем, кто не мог их заплатить, приходилось довольствоваться тем, что
есть: большим количеством разрозненных компонентов, которые нужно собирать
вместе и долго тестировать надежность работы получившейся системы.
Типы облачных сервисов
SaaS — Software as a Service (программное обеспечение в
качестве сервиса). Предоставляет потребителю возможность использовать ПО,
работающее в облаке. Ярчайший пример: gmail.PaaS — Platform as a Service (платформа в качестве
сервиса). Позволяет потребителю развертывать собственные приложения на
подготовленной для этого платформе. В качестве примера можно привести среду
Java, работающую удаленно.IaaS — Infrastructure as a Service (инфраструктура в
качестве сервиса). Дает потребителю целую инфраструктуру, позволяющую
запускать виртуальные машины, налаживать межу ними связь и использовать
дисковое пространство.
Eucalyptus стал одним из первых Open Source проектов, нацеленных на создание
комплексной инфраструктуры, позволяющей поднять cloud-сервис уровня IaaS не
прибегая к дополнительным инструментам. Предлагаемая им инфраструктура
действительно удобна, эффективна, устойчива и, что немаловажно, полностью
совместима с клиентскими инструментами Amazon EC2. Тем не менее, инфраструктура
на основе Eucalyptus оказалась недостаточно масштабируемой, а публичная версия
фреймворка сильно урезанной по функциональности. Поэтому совсем скоро на рынке
появился проект, призванный решить эти проблемы и, ни много ни мало, стать
стандартной открытой платформой.
OpenStack был образован путем слияния двух независимых проектов:
"Cloud Files and Cloud Servers", разрабатываемой RockSpace, и "Nebula Cloud
Platform", созданной NASA. В результате получилась довольно интересная солянка,
разделенная опять же на два почти независимых продукта: OpenStack Nova и
OpenStack Swift.
Nova — счетная машина
Главный компонент OpenStack — это Nova (Compute), контроллер,
управляющий работой виртуальных машин. Фактически Nova отвечает за все:
обрабатывает запросы на создание виртуальных машин, соединяет их с внешним
миром, следит за работоспособностью и распределением нагрузки на физические
машины и каналы связи, реагирует на сбои и т.д. Nova основана на коде системы
NASA Nebula, написана на
языке программирования Python и опирается на протокол обмена сообщениями AMQP.
Система состоит из семи обособленных компонентов:
- контроллер облака (Cloud Controller) следит за состоянием системы и
выступает в роли связующего звена всех остальных компонентов системы; - сервер API (API Server) реализует web-интерфейс, позволяющий управлять
контроллером облака; - контроллер вычислений (Compute Controller) отвечает за запуск
виртуальных машин и их связь со всей остальной инфраструктурой; - хранилище (Object Store) предоставляет сервис хранения данных,
совместимый с Amazon S3; - менеджер аутентификации (Auth Manager) предоставляет сервисы
аутентификации и авторизации; - контроллер томов (Volume Controller) позволяет подключать виртуальные
устройства хранения к виртуальным машинам; - сетевой контроллер (Network Controller) создает виртуальные сети,
позволяя виртуальным машинам взаимодействовать друг с другом и внешней
сетью; - планировщик (Scheduler) ответственен за выбор подходящего контроллера
вычислений для запуска новой виртуальной машины.
На рисунке хорошо видно, как эти компоненты связаны между собой. Сервер API,
контроллер облака и менеджер аутентификации составляют "управляющий центр"
облака, который должен работать на выделенной машине. Администратор использует
утилиту nova-manage для управления характеристиками всей инфраструктуры и
доступом к ней пользователей. Клиенты, желающие использовать облачный сервис,
подключаются к серверу API с помощью клиентских утилит Amazon EC2 или их
свободного варианта под названием euca2ool из проекта Eucalyptus.
Еще одна выделенная машина отвечает за управление хранилищем данных (Object
Store). В состав Nova включена только начальная реализация S3-совместимого
хранилища данных, которая может быть использована только для отладки. В реальных
же проектах на ее месте должен быть установлен Swift, развивающийся обособленно
от Nova.
Еще одна машина — это контроллер томов, позволяющий подключать к виртуальным
машинам своего рода внешние накопители данных (виртуальные флэшбрелки). Его
присутствие в инфраструктуре совсем не обязательно.
Несколько машин выполняют работу сетевых контроллеров, которые отвечают за
распределение IP-адресов между виртуальными машинами и могут выступать в роли
шлюза, отделяющего виртуальные машины от остальных сегментов сети. Обычно на
один сегмент внутренней виртуальной сети приходится один сетевой контроллер, но
это скорее правило, чем требование.
Одна из машин выполняет функции планировщика, который должен следить за
контроллерами вычислений и, в случае поступления нового запроса на создание
виртуальной машины, выбирать для этой цели наиболее подходящего кандидата
(решение о пригодности может быть принято на основе загруженности контроллеров
вычислений, количества виртуальных машин, выполняемых на них и других факторов).
Контроллеры вычислений — это основной костяк облачной инфраструктуры
OpenStack, обычно их количество намного превосходит количество всех
остальных машин сети. Контроллеры вычислений занимаются приемом запросов на
создание новой виртуальной машины, ее запуском, слежением за состоянием
виртуальных машин, перезапуском и так далее. Чем больше контроллеров вычислений
в инфраструктуре, тем больше клиентов может обслуживать сервис.
Обработка пользовательских запросов в такой системе выглядит следующим
образом: используя клиентские инструменты, пользователь инициирует запрос на
создание виртуальной машины к серверу API. После аутентификации и авторизации
пользователя сервер API разбирает запрос и посылает его контроллеру облака,
который инициирует три новых запроса: к сетевому контроллеру, к хранилищу и к
планировщику. Сетевой контроллер выделяет IP-адрес для новой виртуальной машины
и возвращает его контроллеру облака. В сетевом хранилище происходит поиск
подходящего образа жесткого диска для будущей виртуальной машины, адрес которого
возвращается контроллеру облака. Теперь, имея все необходимое для создания новой
виртуальной машины, контроллер облака посылает запрос планировщику, который
выбирает наиболее подходящий контроллер вычислений и отдает ему запрос на
создание ВМ. После того, как новая ВМ будет запущена, контроллер облака
завершает свою работу и сообщает серверу API об успехе всей операции. Теперь
пользователь может подключиться к ВМ, а всю деятельность по поддержанию ее в
работоспособном состоянии, выделении дискового пространства, маршрутизации
сетевых пакетов и прочую черную работу берет на себя система.
Стоит заметить, что облачная инфраструктура на основе OpenStack
получается очень гибкой и управляемой. Компоненты системы полностью обособлены
друг от друга и общаются только с помощью отправки асинхронных сообщений или
протокола HTTP. Уже настроенная и работающая система легко выдержит любые
изменения в своем дизайне и не потребует много времени на переконфигурирование.
Кроме того, OpenStack не замкнут сам в себе и везде, где это возможно,
использует сторонние продукты. Для его управления можно использовать стандартные
клиенты сервиса Amazon EC2, а для запуска виртуальных машин применять наиболее
удобные в данном конкретном случае системы виртуализации (на сегодня
поддерживаются KVM, UML, XEN, HyperV и qemu).
Swift — безграничное хранилище
Swift (OpenStack Object Storage) — это полностью
распределенное, отказоустойчивое высоконадежное хранилище данных, созданное по
образу и подобию Amazon S3.
Swift почти полностью основан на наработках компании Rackspace.
Система состоит из четырех основных компонентов:
- прокси-сервер (Proxy Server), объединяющий все остальные компоненты
системы вместе; - объектный сервер (Object Server), ответственный за хранение данных;
- контейнерный сервер (Container Server), ответственный за отдачу списка
объектов; - сервер аккаунтинга (Account Server), отдающий листинги контейнеров для
конкретного аккаунта.
Типичная Swift-инфраструктура представляет собой кластер, одна из машин
которого выполняет функции прокси-сервера, несколько машин работают в качестве
контейнерных серверов и серверов аккаунтинга, а все остальные (сотни и тысячи
машин) представляют собой контейнерные серверы.
Прокси-сервер поддерживает внешний ReST-ful API, реализованный в рамках
протокола HTTP. Поэтому запрос доступа к объектам внутри хранилища выглядит
очень наглядно и просто:
GET http://swift.host.com/v1/account/container/object
Здесь account — это пользовательский аккаунт, container — пространство имен,
используемое для классификации данных, а object — непосредственно данные (или,
другими словами, файл).
Прокси-сервер использует так называемые кольца (rings) для поиска реального
положения данных в кластере. Это своего рода база данных, описывающая то, где на
самом деле расположены данные. Она модифицируется при каждой записи новых данных
в хранилище, их удаления или выходе узлов из строя. Для аккаунтов, контейнеров и
объектов предусмотрены отдельные кольца.
Объектные серверы — наиболее важный компонент Swift-кластера. Они отвечают за
хранение и отдачу данных. Любые объекты хранилища в конечном счете оседают на
жестких дисках этих серверов, которые записывают данные в обычные файлы,
сопровождая их метаданными, записываемыми в расширенные атрибуты файлов (xattr).Надежность
хранения данных достигается за счет дублирования сразу на несколько серверов,
так что если один из них выйдет из строя, система сможет восстановить данные с
другого сервера и вновь продублировать их. По умолчанию система создает три
копии каждого объекта, так что в качестве железной составляющей кластера можно
использовать даже самые дешевые машины, не снабженные RAID-контроллерами.
Один из основных плюсов системы состоит в ее прозрачной масштабируемости.
Расширить хранилище можно, просто подключив новый узел к кластеру, а всю
остальную работу по его синхронизации с хранилищем возьмет на себя Swift. Лучше
всего этот кластер подходит для хранения таких данных, как образы виртуальных
машин (собственно, для этого он и был создан), банки фотографий, электронные
письма, бэкапы и тому подобное.
Пробуем
OpenStack — сложная система, для описания установки и использования
которой потребовалась бы не одна статья, поэтому мы не будем углубляться в
детали, а просто посмотрим, насколько быстро можно развернуть облачный сервис на
локальной машине. С помощью Nova это довольно просто сделать, и нам даже не
понадобится помощь Swift, мы просто установим все компоненты системы на одну
машину и посмотрим, как они функционируют вместе. В дальнейшем инфраструктуру
можно будет расширить до нескольких машин, добавив к ней распределенное
хранилище данных, но это тема для отдельной статьи.
Несмотря на свою молодость, Nova и Swift уже успели попасть в официальные
репозитории некоторых дистрибутивов, поэтому для установки нужных нам
компонентов можно использовать стандартный менеджер пакетов:
$ sudo apt-get install rabbitmq-server \
redis-server
$ sudo apt-get install nova-api \
nova-objectstore nova-compute \
nova-scheduler nova-network \
euca2ools unzip
Фактически уже после установки система полностью готова к работе, остается
только завести учетную запись суперпользователя:
$ sudo nova-manage user admin vasya
И создать новый проект, в рамках которого мы будем производить все дальнейшие
эксперименты:
$ sudo nova-manage project create experiments vasya
Далее просим систему запаковать данные, необходимые для доступа к проекту, в
zip-архив:
$ sudo nova-manage project zipfile experiments vasya
Теперь эти данные можно использовать, чтобы управлять работой облака с
помощью EC2-совместимых инструментов. Для этого распакуем архив и выполним
команды, прописанные в файле novarc:
$ unzip nova.zip
$ . novarc
Чтобы протестировать работу сервиса, нам понадобится EC2-образ виртуальной
машины.
Минимальный Linux-образ можно получить на сайте Rackspace:
$ wget http://c2477062.cdn.cloudfiles.rackspacecloud.com/images.tgz
Распаковываем:
$ tar -xzf images.tgz
Образ необходимо зарегистрировать в облаке, поэтому делаем следующее:
1. Создаем манифесты для ядра и рамдиска:
$ euca-bundle-image -i images/aki-lucid/image -p kernel --kernel true
$ euca-bundle-image -i images/ari-lucid/image -p ramdisk --ramdisk true
2. Заливаем ядро и рамдиск в облако:
$ euca-upload-bundle -m /tmp/kernel.manifest.xml -b mybucket
$ euca-upload-bundle -m /tmp/ramdisk.manifest.xml -b mybucket
3. Регистрируем ядро и рамдиск:
$ euca-register mybucket/kernel.manifest.xml
$ euca-register mybucket/ramdisk.manifest.xml
Эти команды должны выдать на экран идентификаторы ядра и рамдиска внутри
облака. Их нужно запомнить или скопировать.
4. Подготавливаем образ машины, используя зарегистрированные в прошлом шаге
ядро и рамдиск:
$ euca-bundle-image -i images/ami-tiny/image -p machine --kernel
ID-ядра --ramdisk ID-диска
5. Загружаем образ машины в облако:
$ euca-upload-bundle -m /tmp/machine.manifest.xml -b mybucket
6. Регистрируем образ машины и запоминаем ее идентификатор:
$ euca-register mybucket/machine.manifest.xml
Теперь можно запустить виртуальную машину на исполнение, но сначала мы должны
получить SSH-ключ для доступа к нашим машинам:
$ euca-add-keypair mykey > mykey.priv
$ chmod 600 mykey.priv
Запускаем виртуальную машину:
$ euca-run-instances ID-машины --kernel ID-ядра --ramdisk ID-рамдиска -k
mykey
Смотрим состояние машины:
$ euca-describe-instances
Проверяем, была ли она корректно запущена:
$ virsh list
Подключаемся к машине по SSH:
$ euca-authorize -P tcp -p 22 default
$ ssh -i mykey.priv root@10.0.0.3
Убиваем машину:
$ uca-terminate-instances ID-машины
Заключение
Описанное в статье — только вершина айсберга под названием OpenStack.
Чтобы описать систему полностью, понадобилась бы целая книга и огромное
количество свободного времени. Но я надеюсь, что и эта небольшая порция
информации поможет тебе начать освоение этого, без сомнения, грандиозного
продукта, который в скором времени вполне может стать стандартом в среде
открытых облачных сервисов.
WWW
Описание архитектуры Nova:
http://nova.openstack.org/nova.concepts.html;Руководство администратора Nova:
http://nova.openstack.org/adminguide/index.htmll;Руководство по созданию Nova-кластера:
http://wiki.openstack.org/NovaInstall/MultipleServer;Описание архитектуры Swift:
http://swift.openstack.org/overview_architecture.html
