Автор: Олег Гельбух
Существует несколько основных требований, которые предъявляются к развертыванию платформы OpenStack для коммерческой эксплуатации, как в качестве небольшого кластера для сред разработки в стартапах, так и в виде крупномасштабной установки для поставщика ресурсов для облачных сервисов. Чаще всего встречаются и, как следствие, являются наиболее важными следующие требования:
— Бесперебойность (HA) сервиса и резервирование
— Масштабируемость кластера
— Автоматизация технологических операций
Компания Mirantis разработала подход, который позволяет удовлетворять всем этим трем требованиям. Эта статья – первая в ряде статей, которые описывают наш подход. В статье содержится обзор используемых методов и инструментов.
В целом сервисы на базе платформы OpenStack можно разделить на несколько групп, в данном случае основываясь на подходе обеспечения бесперебойности для каждого сервиса.
API-сервисы
Первая группа включает API-серверы, а именно:
— nova-api
— glance-api
— glance-registry
— keystone
Так как используются протоколы HTTP/REST, резервирование относительно просто достигается с помощью балансировщика нагрузки, добавленного в кластер. Если балансировщик нагрузки поддерживает проверку работоспособности, этого достаточно для обеспечения базовой высокой доступности API. Примите во внимание, что в выпуске 2012.1 (Essex) платформы OpenStack только интерфейс Swift API поддерживает вызов “проверка работоспособности”. Чтобы проверить работоспособность других сервисов, требуются дополнения к API с поддержкой такого вызова.
Сервисы вычислений
Вторая группа включает сервисы, которые фактически управляют виртуальными серверами и предоставляют для них ресурсы:
— nova-compute
— nova-network
— nova-volume
Эти сервисы не требуют специального резервирования в production environment. Подход к этим группам сервисов основывается на базовой парадигме облачных вычислений, то есть такой парадигме, где существует много взаимозаменяемых рабочих процессов и потеря одного из них приводит только к временному локальному нарушению управляемости, а не сбою сервиса, предоставляемого кластером. Таким образом, достаточно отслеживать эти сервисы с помощью внешней системы мониторинга, а также иметь в своем распоряжении основные сценарии восстановления, реализованные в виде обработчиков событий. Самым простым сценарием является отправка уведомления администратору и попытка перезапуска сервиса, завершившегося с ошибкой.
Высокая доступность сервиса передачи данных по сети, предоставляемого функцией поддержки нескольких узлов (multihost) сервиса nova-network, описана в официальной документации OpenStack. В реально работающих средах, тем не менее, при частом переключении на эту схему применяется перенос нагрузки по сетевой маршрутизации на внешний аппаратный маршрутизатор. Таким образом, сервис nova-network выполняет только функции DHCP-сервера, а поддержка нескольких узлов гарантирует, что DHCP-сервер не является единственной точкой отказа.
Планировщик
Резервирование является встроенной частью сервиса nova-scheduler. При запуске первого экземпляра nova-scheduler, он начинает получать сообщения из очереди scheduler на сервере RabbitMQ. При этом создается дополнительная очередь scheduler_fanout_, которую сервисы nova-compute используют для обновления статусов. Параметр в названии очереди заменяется идентификатором нового экземпляра планировщика. Все в дальнейшем запускаемые планировщики nova-scheduler действуют аналогичным образом, что позволяет им работать параллельно без дополнительных усилий
Сервер очередей
Сервер очередей RabbitMQ является основным каналом связи для всех сервисов nova, и он должен быть надежным в любой конфигурации production environment. Создание кластеров и зеркалирование очереди изначально поддерживаются сервером RabbitMQ, а балансировщик нагрузки можно использовать для распределения подключений между серверами RabbitMQ, работающими в кластерном режиме. Также компания Mirantis разработала обновление для библиотеки Nova RPC, которое позволяет ей при сбое переключиться на резервный сервер RabbitMQ, если основной сервер вышел из строя и не может принимать подключения.
База данных
Чаще всего при развертывании платформы OpenStack используется база данных MySQL. Компания Mirantis также чаще всего использует эту базу данных в своих установках. На сегодняшний день существует несколько решений, которые обеспечивают бесперебойность и масштабируемость базы данных MySQL. Чаще всего используется инструмент управления репликациями с несколькими источниками изменений данных (multi-master replication manager) MySQL-MMM. Это решение используется в нескольких установках, выполненных компанией Mirantis, и работает достаточно надежно, за исключением известных ограничений.
Хотя с использованием MMM не было серьезных проблем, мы рассматриваем использование более современных решений с открытым исходным кодом для обеспечения бесперебойности работы базы данных, в частности движок для кластеризации для MySQL на основе WSREP, Galera. Кластер Galera предоставляет простой и прозрачный механизм масштабируемости и поддерживает отказоустойчивость с помощью синхронной репликации с несколькими источниками изменений данных, реализованными на уровне WSREP.
Теперь, когда мы знаем, как балансировать нагрузку или параллельно распределять загруженность, нам нужен механизм, который позволяет добавлять сервисные процессы в кластер и расширять его для обеспечения большей нагрузки, то есть выполнять “горизонтальное” масштабирование. Для большинства компонентов платформы OpenStack достаточно просто добавить экземпляр сервера, включить его в конфигурацию балансировщика нагрузки и выполнить горизонтальное масштабирование кластера. Тем не менее, это приводит к двум проблемам в промышленных установках:
Большинство кластеров масштабируются по узлам, а не по экземплярам сервисов. В связи с этим возникает необходимость определить роли узлов, которые позволяют выполнять “умное” масштабирование кластеров. Роль по сути соответствует набору сервисов, запущенных на узле, и масштабируется посредством добавления узла кластеру.
Горизонтальное масштабирование кластера за счет добавления контролирующего узла требует изменения конфигурации в нескольких местах в определенном порядке, то есть необходимо развернуть кластер, запустить сервисы, и только затем обновить конфигурацию балансировщика нагрузки, включив новый узел. Для вычислительных узлов процедура проще, но, тем не менее, она требует высокой степени автоматизации на всех уровнях, от оборудования до конфигурации сервисов.
Узлы и роли
В то время как сервисы OpenStack могут быть распределены по серверам с высокой степенью гибкости, наиболее частым вариантом развертывания платформы OpenStack является наличие двух типов узлов: управляющий узел и вычислительные узлы. Типичная установка OpenStack для разработки включает один управляющий узел, который запускает все сервисы, за исключением группы вычислений, и несколько вычислительных узлов, которые запускают вычислительные сервисы и на которых размещены виртуальные серверы.
Становится понятно, что такая архитектура не подходит для коммерческих установок. Для небольших кластеров мы рекомендуем делать кластерные узлы как можно более самодостаточными за счет установки API-серверов на вычислительных узлах, оставляя только базу данных, сервер очередей и панель управления на управляющем узле. Конфигурация управляющих узлов должна предусматривать резервирование. Для этой архитектуры определены следующие роли узлов:
— Конечный узел. На этом узле запущены сервисы балансировки нагрузки и обеспечения бесперебойности, которые могут включать программное обеспечение для балансировки нагрузки и создания кластера. В качестве конечного узла может выступать программно-аппаратный комплекс в сети, предназначенный для балансировки нагрузки. В кластере рекомендуется создать как минимум два конечных узла для обеспечения избыточности.
— Управляющий узел. На этом узле располагаются коммуникационные сервисы, которые обеспечивают работу всего облака, в том числе сервер очередей, база данных, панель управления Horizon и, возможно, система мониторинга. На этом узле могут по желанию располагаться сервис nova-scheduler и API-серверы, балансировкой распределения нагрузки на которые управляет конечный узел. В кластере необходимо создать как минимум два управляющих узла для обеспечения избыточности. Управляющий узел и конечный узел могут быть объединены на одном физическом сервере, но при этом необходимо внести изменения в конфигурацию сервисов nova – необходимо перенести их с портов, которые использует балансировщик нагрузки.
— Вычислительный узел. На этом узле размещаются гипервизор и virtual instances, которые используют его вычислительные мощности. Вычислительный узел может также выступать в качестве контроллера сети для размещенных на нем virtual instances, если используется multihost-схема.
Управление конфигурацией
Для реализации предложенной выше архитектуры на каждом физическом сервере необходимо выполнить определенную последовательность шагов. Некоторые шаги достаточно сложные, другие включают настройку нескольких узлов; например, конфигурирование балансировщика нагрузки или настройка репликации с несколькими источниками изменения данных. В связи со сложностью существующего на данный момент процесса развертывания платформы OpenStack важным для его успешной реализации является написание сценариев для этих операций (scripting). Это привело к появлению нескольких проектов, в том числе известных Devstack и Crowbar.
Простое написание сценариев процесса установки недостаточно ни для успешной установки решения OpenStack в производственных средах, ни для обеспечения масштабируемости кластера. Также, если вам потребуется изменить что-то в своей архитектуре или обновить версии компонентов, вам потребуется разработать новые сценарии. Это можно сделать с помощью инструментов, разработанных специально для этих задач: программ-конфигураторов. Наиболее известны среди них Puppet и Chef, а также есть продукты, разработанные на их основе (например, упомянутый выше Crowbar в качестве движка использует Chef).
Для развертывания OpenStack в различных проектах мы использовали как Puppet, так и Chef. Естественно, у каждой из программ есть свои ограничения. Наш опыт показывает, что наилучшие результаты достигаются, когда программа-конфигуратор поддерживается централизованным orchestration engine для гладкого и успешного развертывания. При сочетании с приложением для настройки физических серверов на аппаратном уровне и комплексом тестов для подтверждения качества установки мы получаем комплексный подход, позволяющий быстро установить платформу OpenStack в широком диапазоне конфигураций оборудования и логических архитектур.
Использование orchestration engine с системой настройки конфигурации, которая учитывает роли узлов, позволяет нам в достаточно высокой степени автоматизировать процесс развертывания. Мы также можем автоматизировать масштабирование. Все это сокращает расходы на эксплуатацию и поддержку OpenStack. Большинство современных orchestration engine имеют API-интерфейс, который позволяет создавать интерфейс командной строки или веб-интерфейсы для операторов, выполняющих задачи по управлению всем кластером или его отдельными частями.
Подробнее об этом мы расскажем в следующих статьях.
Существует несколько основных требований, которые предъявляются к развертыванию платформы OpenStack для коммерческой эксплуатации, как в качестве небольшого кластера для сред разработки в стартапах, так и в виде крупномасштабной установки для поставщика ресурсов для облачных сервисов. Чаще всего встречаются и, как следствие, являются наиболее важными следующие требования:
— Бесперебойность (HA) сервиса и резервирование
— Масштабируемость кластера
— Автоматизация технологических операций
Компания Mirantis разработала подход, который позволяет удовлетворять всем этим трем требованиям. Эта статья – первая в ряде статей, которые описывают наш подход. В статье содержится обзор используемых методов и инструментов.
Бесперебойность (HA) и резервирование
В целом сервисы на базе платформы OpenStack можно разделить на несколько групп, в данном случае основываясь на подходе обеспечения бесперебойности для каждого сервиса.
API-сервисы
Первая группа включает API-серверы, а именно:
— nova-api
— glance-api
— glance-registry
— keystone
Так как используются протоколы HTTP/REST, резервирование относительно просто достигается с помощью балансировщика нагрузки, добавленного в кластер. Если балансировщик нагрузки поддерживает проверку работоспособности, этого достаточно для обеспечения базовой высокой доступности API. Примите во внимание, что в выпуске 2012.1 (Essex) платформы OpenStack только интерфейс Swift API поддерживает вызов “проверка работоспособности”. Чтобы проверить работоспособность других сервисов, требуются дополнения к API с поддержкой такого вызова.
Сервисы вычислений
Вторая группа включает сервисы, которые фактически управляют виртуальными серверами и предоставляют для них ресурсы:
— nova-compute
— nova-network
— nova-volume
Эти сервисы не требуют специального резервирования в production environment. Подход к этим группам сервисов основывается на базовой парадигме облачных вычислений, то есть такой парадигме, где существует много взаимозаменяемых рабочих процессов и потеря одного из них приводит только к временному локальному нарушению управляемости, а не сбою сервиса, предоставляемого кластером. Таким образом, достаточно отслеживать эти сервисы с помощью внешней системы мониторинга, а также иметь в своем распоряжении основные сценарии восстановления, реализованные в виде обработчиков событий. Самым простым сценарием является отправка уведомления администратору и попытка перезапуска сервиса, завершившегося с ошибкой.
Высокая доступность сервиса передачи данных по сети, предоставляемого функцией поддержки нескольких узлов (multihost) сервиса nova-network, описана в официальной документации OpenStack. В реально работающих средах, тем не менее, при частом переключении на эту схему применяется перенос нагрузки по сетевой маршрутизации на внешний аппаратный маршрутизатор. Таким образом, сервис nova-network выполняет только функции DHCP-сервера, а поддержка нескольких узлов гарантирует, что DHCP-сервер не является единственной точкой отказа.
Планировщик
Резервирование является встроенной частью сервиса nova-scheduler. При запуске первого экземпляра nova-scheduler, он начинает получать сообщения из очереди scheduler на сервере RabbitMQ. При этом создается дополнительная очередь scheduler_fanout_, которую сервисы nova-compute используют для обновления статусов. Параметр в названии очереди заменяется идентификатором нового экземпляра планировщика. Все в дальнейшем запускаемые планировщики nova-scheduler действуют аналогичным образом, что позволяет им работать параллельно без дополнительных усилий
Сервер очередей
Сервер очередей RabbitMQ является основным каналом связи для всех сервисов nova, и он должен быть надежным в любой конфигурации production environment. Создание кластеров и зеркалирование очереди изначально поддерживаются сервером RabbitMQ, а балансировщик нагрузки можно использовать для распределения подключений между серверами RabbitMQ, работающими в кластерном режиме. Также компания Mirantis разработала обновление для библиотеки Nova RPC, которое позволяет ей при сбое переключиться на резервный сервер RabbitMQ, если основной сервер вышел из строя и не может принимать подключения.
База данных
Чаще всего при развертывании платформы OpenStack используется база данных MySQL. Компания Mirantis также чаще всего использует эту базу данных в своих установках. На сегодняшний день существует несколько решений, которые обеспечивают бесперебойность и масштабируемость базы данных MySQL. Чаще всего используется инструмент управления репликациями с несколькими источниками изменений данных (multi-master replication manager) MySQL-MMM. Это решение используется в нескольких установках, выполненных компанией Mirantis, и работает достаточно надежно, за исключением известных ограничений.
Хотя с использованием MMM не было серьезных проблем, мы рассматриваем использование более современных решений с открытым исходным кодом для обеспечения бесперебойности работы базы данных, в частности движок для кластеризации для MySQL на основе WSREP, Galera. Кластер Galera предоставляет простой и прозрачный механизм масштабируемости и поддерживает отказоустойчивость с помощью синхронной репликации с несколькими источниками изменений данных, реализованными на уровне WSREP.
Масштабируемость
Теперь, когда мы знаем, как балансировать нагрузку или параллельно распределять загруженность, нам нужен механизм, который позволяет добавлять сервисные процессы в кластер и расширять его для обеспечения большей нагрузки, то есть выполнять “горизонтальное” масштабирование. Для большинства компонентов платформы OpenStack достаточно просто добавить экземпляр сервера, включить его в конфигурацию балансировщика нагрузки и выполнить горизонтальное масштабирование кластера. Тем не менее, это приводит к двум проблемам в промышленных установках:
Большинство кластеров масштабируются по узлам, а не по экземплярам сервисов. В связи с этим возникает необходимость определить роли узлов, которые позволяют выполнять “умное” масштабирование кластеров. Роль по сути соответствует набору сервисов, запущенных на узле, и масштабируется посредством добавления узла кластеру.
Горизонтальное масштабирование кластера за счет добавления контролирующего узла требует изменения конфигурации в нескольких местах в определенном порядке, то есть необходимо развернуть кластер, запустить сервисы, и только затем обновить конфигурацию балансировщика нагрузки, включив новый узел. Для вычислительных узлов процедура проще, но, тем не менее, она требует высокой степени автоматизации на всех уровнях, от оборудования до конфигурации сервисов.
Узлы и роли
В то время как сервисы OpenStack могут быть распределены по серверам с высокой степенью гибкости, наиболее частым вариантом развертывания платформы OpenStack является наличие двух типов узлов: управляющий узел и вычислительные узлы. Типичная установка OpenStack для разработки включает один управляющий узел, который запускает все сервисы, за исключением группы вычислений, и несколько вычислительных узлов, которые запускают вычислительные сервисы и на которых размещены виртуальные серверы.
Становится понятно, что такая архитектура не подходит для коммерческих установок. Для небольших кластеров мы рекомендуем делать кластерные узлы как можно более самодостаточными за счет установки API-серверов на вычислительных узлах, оставляя только базу данных, сервер очередей и панель управления на управляющем узле. Конфигурация управляющих узлов должна предусматривать резервирование. Для этой архитектуры определены следующие роли узлов:
— Конечный узел. На этом узле запущены сервисы балансировки нагрузки и обеспечения бесперебойности, которые могут включать программное обеспечение для балансировки нагрузки и создания кластера. В качестве конечного узла может выступать программно-аппаратный комплекс в сети, предназначенный для балансировки нагрузки. В кластере рекомендуется создать как минимум два конечных узла для обеспечения избыточности.
— Управляющий узел. На этом узле располагаются коммуникационные сервисы, которые обеспечивают работу всего облака, в том числе сервер очередей, база данных, панель управления Horizon и, возможно, система мониторинга. На этом узле могут по желанию располагаться сервис nova-scheduler и API-серверы, балансировкой распределения нагрузки на которые управляет конечный узел. В кластере необходимо создать как минимум два управляющих узла для обеспечения избыточности. Управляющий узел и конечный узел могут быть объединены на одном физическом сервере, но при этом необходимо внести изменения в конфигурацию сервисов nova – необходимо перенести их с портов, которые использует балансировщик нагрузки.
— Вычислительный узел. На этом узле размещаются гипервизор и virtual instances, которые используют его вычислительные мощности. Вычислительный узел может также выступать в качестве контроллера сети для размещенных на нем virtual instances, если используется multihost-схема.
Управление конфигурацией
Для реализации предложенной выше архитектуры на каждом физическом сервере необходимо выполнить определенную последовательность шагов. Некоторые шаги достаточно сложные, другие включают настройку нескольких узлов; например, конфигурирование балансировщика нагрузки или настройка репликации с несколькими источниками изменения данных. В связи со сложностью существующего на данный момент процесса развертывания платформы OpenStack важным для его успешной реализации является написание сценариев для этих операций (scripting). Это привело к появлению нескольких проектов, в том числе известных Devstack и Crowbar.
Простое написание сценариев процесса установки недостаточно ни для успешной установки решения OpenStack в производственных средах, ни для обеспечения масштабируемости кластера. Также, если вам потребуется изменить что-то в своей архитектуре или обновить версии компонентов, вам потребуется разработать новые сценарии. Это можно сделать с помощью инструментов, разработанных специально для этих задач: программ-конфигураторов. Наиболее известны среди них Puppet и Chef, а также есть продукты, разработанные на их основе (например, упомянутый выше Crowbar в качестве движка использует Chef).
Для развертывания OpenStack в различных проектах мы использовали как Puppet, так и Chef. Естественно, у каждой из программ есть свои ограничения. Наш опыт показывает, что наилучшие результаты достигаются, когда программа-конфигуратор поддерживается централизованным orchestration engine для гладкого и успешного развертывания. При сочетании с приложением для настройки физических серверов на аппаратном уровне и комплексом тестов для подтверждения качества установки мы получаем комплексный подход, позволяющий быстро установить платформу OpenStack в широком диапазоне конфигураций оборудования и логических архитектур.
Автоматизация операций
Использование orchestration engine с системой настройки конфигурации, которая учитывает роли узлов, позволяет нам в достаточно высокой степени автоматизировать процесс развертывания. Мы также можем автоматизировать масштабирование. Все это сокращает расходы на эксплуатацию и поддержку OpenStack. Большинство современных orchestration engine имеют API-интерфейс, который позволяет создавать интерфейс командной строки или веб-интерфейсы для операторов, выполняющих задачи по управлению всем кластером или его отдельными частями.
Подробнее об этом мы расскажем в следующих статьях.