Автор: Олег Гельбух Существует несколько основных требований для развертывания платформы OpenStack для коммерческого использования: либо в виде небольшого кластера для сред разработки стартапов, либо в виде крупномасштабной установки для поставщика облачных ресурсов.
Наиболее распространенными и, как следствие, наиболее важными требованиями являются: — Непрерывность обслуживания (HA) и резервирование — Масштабируемость кластера — Автоматизация технологических операций Компания «Мирантис» разработала подход, отвечающий всем трем этим требованиям.
Эта статья является первой в серии статей, описывающих наш подход. В статье представлен обзор используемых методов и инструментов.
Доступность (HA) и резервирование
В целом сервисы на базе платформы OpenStack можно разделить на несколько групп, в данном случае исходя из подхода к обеспечению непрерывности работы каждого сервиса.API-сервисы В первую группу входят API-серверы, а именно: -nova-api - взгляд-API - взгляд-регистрация -краеугольный камень Поскольку используются протоколы HTTP/REST, избыточность относительно легко обеспечить с помощью балансировщика нагрузки, добавленного в кластер.
Если балансировщик нагрузки поддерживает проверку работоспособности, этого достаточно для обеспечения базовой высокой доступности API. Обратите внимание, что в версии 2012.1 (Эссекс) платформы OpenStack только Swift API поддерживает вызов «проверки работоспособности».
Для проверки работоспособности других сервисов необходимы дополнения к API, поддерживающие такой вызов.
Вычислительные услуги Во вторую группу входят сервисы, которые собственно управляют виртуальными серверами и предоставляют для них ресурсы: - нова-компьютер - нова-сеть -nova-объем Эти услуги не требуют специального резервирования в производственной среде.
Подход к этим группам сервисов основан на базовой парадигме облачных вычислений, то есть той, в которой имеется множество взаимозаменяемых рабочих процессов и потеря одного из них приводит лишь к временному локальному нарушению управляемости, а не к сбою.
услуги, предоставляемой кластером.
Таким образом, достаточно контролировать эти сервисы с помощью внешней системы мониторинга, а также иметь в своем распоряжении основные сценарии восстановления, реализованные в виде обработчиков событий.
Самый простой сценарий — отправить уведомление администратору и попытаться перезапустить службу, которая вышла из строя.
Высокая доступность сервиса сетевой передачи данных, обеспечиваемая функцией поддержки мультихостов сервиса nova-network, описана в официальной документации OpenStack. Однако в реальных условиях частое переключение на эту схему предполагает перенос нагрузки сетевой маршрутизации на внешний аппаратный маршрутизатор.
Таким образом, служба nova-network выполняет только функции DHCP-сервера, а поддержка нескольких узлов гарантирует, что DHCP-сервер не является единой точкой отказа.
Планировщик Бронирование — встроенная часть сервиса nova-scheduler. Когда запускается первый экземпляр nova-scheduler, он начинает получать сообщения из очереди планировщика на сервере RabbitMQ. При этом создается дополнительная очередь Scheduler_fanout_, которую службы nova-compute используют для обновления статусов.
Параметр в имени очереди заменяется идентификатором нового экземпляра планировщика.
Все впоследствии запущенные планировщики nova-scheduler действуют одинаково, что позволяет им работать параллельно без дополнительных усилий.
Сервер очереди Сервер очереди RabbitMQ является основным каналом связи для всех сервисов nova и должен быть надежным в любой конфигурации производственной среды.
Кластеризация и зеркалирование очередей изначально поддерживаются сервером RabbitMQ, а балансировщик нагрузки может использоваться для распределения соединений между серверами RabbitMQ, работающими в режиме кластера.
Компания Mirantis также разработала обновление для библиотеки Nova RPC, которое позволяет ей выполнять аварийное переключение на резервный сервер RabbitMQ, если основной сервер не работает и не может принимать соединения.
База данных Наиболее распространенной базой данных, используемой при развертывании платформы OpenStack, является MySQL. Мирантис также чаще всего использует эту базу данных в своих установках.
Сегодня существует несколько решений, обеспечивающих бесперебойную и масштабируемую базу данных MySQL. Наиболее часто используемый инструмент управления репликацией с несколькими источниками изменения данных (менеджер репликации с несколькими хозяевами) — MySQL-MMM. Это решение использовалось в нескольких установках Мирантис и работает достаточно надежно, если не считать известных ограничений.
Хотя при использовании MMM не возникло серьезных проблем, мы рассматриваем возможность использования более современных решений с открытым исходным кодом для обеспечения непрерывности базы данных, в частности механизма кластеризации на основе WSREP для MySQL, Galera. Кластер Galera предоставляет простой и прозрачный механизм масштабируемости и поддерживает отказоустойчивость с помощью синхронной репликации с несколькими источниками изменения данных, реализованными на уровне WSREP.
Масштабируемость
Теперь, когда мы знаем, как балансировать нагрузку или распределять рабочую нагрузку параллельно, нам нужен механизм, позволяющий добавлять сервисные процессы в кластер и расширять его для размещения большей нагрузки, то есть «горизонтальное» масштабирование.Для большинства компонентов платформы OpenStack вам просто нужно добавить экземпляр сервера, включить его в конфигурацию балансировщика нагрузки и масштабировать кластер.
Однако это приводит к двум проблемам в промышленных установках: Большинство кластеров масштабируются по узлам, а не по экземплярам службы.
В связи с этим возникает необходимость определить роли узлов, позволяющие «умное» масштабирование кластеров.
Роль по существу соответствует набору служб, работающих на узле, и масштабируется путем добавления узла в кластер.
Горизонтальное масштабирование кластера путем добавления узла мониторинга требует изменения конфигурации в нескольких местах в определенном порядке, то есть нужно развернуть кластер, запустить сервисы и только потом обновить конфигурацию балансировщика нагрузки для включения нового узла.
Для вычислительных узлов процедура проще, но тем не менее требует высокой степени автоматизации на всех уровнях: от аппаратного обеспечения до настройки сервисов.
Узлы и роли Хотя сервисы OpenStack можно распределять по серверам с высокой степенью гибкости, наиболее распространенным вариантом развертывания платформы OpenStack является наличие узлов двух типов: узла управления и вычислительного узла.
Типичная установка разработки OpenStack включает в себя один узел управления, на котором выполняются все службы, кроме вычислительной группы, и несколько вычислительных узлов, на которых выполняются вычислительные службы и размещаются виртуальные серверы.
Становится ясно, что такая архитектура не подходит для коммерческих установок.
Для небольших кластеров мы рекомендуем сделать узлы кластера максимально самодостаточными, установив серверы API на вычислительных узлах, оставив на управляющем узле только базу данных, сервер очередей и панель управления.
Конфигурация узлов управления должна предусматривать резервирование.
Для этой архитектуры определены следующие роли узлов: — Конечный узел .
На этом узле выполняются службы балансировки нагрузки и обеспечения непрерывности, которые могут включать программное обеспечение для балансировки нагрузки и создания кластеров.
Конечный узел может представлять собой программно-аппаратный комплекс в сети, предназначенный для балансировки нагрузки.
Рекомендуется создать как минимум два конечных узла в кластере для обеспечения избыточности.
— Узел управления .
В этом узле размещаются коммуникационные службы, обеспечивающие работу всего облака, включая сервер очередей, базу данных, панель управления Horizon и, возможно, систему мониторинга.
На этом узле опционально может размещаться служба nova-scheduler и серверы API, распределением нагрузки которых управляет конечный узел.
Для обеспечения резервирования в кластере необходимо создать как минимум два узла управления.
Управляющий узел и конечный узел можно объединить на одном физическом сервере, но для этого необходимо внести изменения в конфигурацию сервисов nova — их нужно перенести подальше от портов, которые использует балансировщик нагрузки.
— Вычислительный узел .
На этом узле размещаются гипервизор и виртуальные экземпляры, использующие его вычислительную мощность.
Вычислительный узел также может выступать в качестве сетевого контроллера для размещенных на нем виртуальных экземпляров, если используется многохостовая схема.
Управление конфигурацией Для реализации предложенной выше архитектуры на каждом физическом сервере необходимо выполнить определенную последовательность шагов.
Некоторые шаги довольно сложны, другие требуют настройки нескольких узлов; например, настройка балансировщика нагрузки или настройка репликации с несколькими источниками изменения данных.
В связи со сложностью текущего процесса развертывания платформы OpenStack, для ее успешной реализации важно написание сценариев этих операций (сценариев).
Это привело к появлению нескольких проектов, в том числе знаменитых Devstack и Crowbar. Простого написания сценария процесса установки недостаточно для успешной установки решения OpenStack в производственных средах или обеспечения масштабируемости кластера.
Также, если вам нужно что-то изменить в своей архитектуре или обновить версии компонентов, вам потребуется разработать новые скрипты.
Это можно сделать с помощью инструментов, созданных специально для этих задач: программ настройки.
Наиболее известные среди них — Puppet и Chef, а также существуют продукты, разработанные на их основе (например, упомянутый выше Crowbar использует в качестве движка Chef).
Мы использовали Puppet и Chef для развертывания OpenStack в различных проектах.
Естественно, каждая программа имеет свои ограничения.
Наш опыт показывает, что наилучшие результаты достигаются, когда программное обеспечение для настройки поддерживается централизованным механизмом оркестрации, что обеспечивает плавное и успешное развертывание.
В сочетании с приложением для настройки физических серверов на аппаратном уровне и набором тестов для проверки качества установки мы получаем комплексный подход, позволяющий быстро установить платформу OpenStack в широком диапазоне аппаратных конфигураций и логических архитектур.
.
Автоматизация операций
Использование механизма оркестрации с системой конфигурации, учитывающей роли узлов, позволяет в достаточно высокой степени автоматизировать процесс развертывания.Мы также можем автоматизировать масштабирование.
Все это снижает затраты на эксплуатацию и поддержку OpenStack. Большинство современных механизмов оркестрации имеют API, который позволяет создавать интерфейсы командной строки или веб-интерфейсы для операторов, выполняющих задачи по управлению всем кластером или отдельными его частями.
Подробнее об этом мы расскажем в следующих статьях.
Теги: #continuity #ha #openstack #api #nova #rabbitmq #MySQL #puppet #chef #open source #puppet
-
Ваше Решение Для Печати С Картриджами Hp
19 Oct, 24 -
Когда У Проекта Более Одного Основателя
19 Oct, 24 -
Хабраюзерские Истории?
19 Oct, 24 -
Url В Печатных Изданиях
19 Oct, 24
