Обеспечение бесперебойности (HA) с платформой OpenStack: варианты топологий

Автор: Piotr Siwczak

Когда я разрабатывал свою первую инфраструктуру OpenStack, я с трудом находил информацию о том, как следует распределять многочисленные ее компоненты по оборудованию. Я изучил множество документов, в том числе справочник по архитектуре Rackspace (который ранее был размещен по ссылке referencearchitecture.org, но сейчас, похоже, эта ссылка устарела). Я также просмотрел проектные схемы в документации OpenStack. Должен признать, что тогда у меня были только базовые знания о том, как взаимодействуют компоненты, поэтому я остановился на достаточно простой схеме: один “управляющий узел”, который включал все компоненты, в том числе API-сервисы, nova-scheduler, Glance, Keystone, базу данных и RabbitMQ. Под управление узла я поместил ферму “рабочих лошадок” — вычислительных узлов. Я также организовал три сети: частную (для трафика с фиксированным IP-адресом и управления серверами), общедоступную (для трафика с динамическим IP-адресом) и для хранения (для трафика по протоколу iSCSI сервиса nova-volume).

Когда я начал работать в Mirantis, я значительно изменил свой подход. Я понял, что все мои идеи по созданию фермы выделенных вычислительных узлов с одним или двумя управляющими узлами, были неверными. С одной стороны, мой подход был хорош в плане разделения компонентов, но на практике мы можем с легкостью смешивать и компоновать рабочие компоненты без перегрузки OpenStack (например, сервис nova-compute с сервисом nova-scheduler на одном узле). Оказывается в OpenStack “управляющий узел” и “вычислительный узел” могут иметь разные значения в зависимости от того, как гибко распределены компоненты OpenStack.

В общем, можно предположить, что в каждой установке OpenStack должны быть как минимум три типа узлов (и, возможно, четвертый), которые описал мой коллега Олег Гельбух:

— Оконечный узел. На этом узле запущены сервисы балансировки нагрузки и обеспечения бесперебойности, которые могут включать программное обеспечение для балансировки нагрузки и создания кластера. В качестве оконечного узла может выступать программно-аппаратный комплекс в сети, предназначенный для балансировки нагрузки. В кластере рекомендуется создать как минимум два оконечных узла для обеспечения избыточности.

— Управляющий узел. На этом узле располагаются коммуникационные сервисы, которые обеспечивают работу всего облака, в том числе сервер очередей, база данных, панель управления Horizon и, возможно, система мониторинга. На этом узле могут по желанию располагаться сервис nova-scheduler и API-серверы, балансировкой распределения нагрузки на которые управляет оконечный узел. В кластере необходимо создать как минимум два управляющих узла для обеспечения избыточности. Управляющий узел и оконечный узел могут быть объединены на одном физическом сервере, но при этом необходимо внести изменения в конфигурацию сервисов nova – необходимо перенести их с портов, которые использует балансировщик нагрузки.

— Вычислительный узел. На этом узле размещаются гипервизор и virtual instances, которые используют его вычислительные мощности. Вычислительный узел может также выступать в качестве контроллера сети для размещенных на нем virtual instances, если используется multihost-схема. Также на узле могут размещаться не требующие много ресурсов внутренние сервисы OpenStack, например, балансировщик, glance-api, и т.п.

— Узел хранения. Он необходим, если вы хотите использовать сервис the nova-volume. На этом узле размещается сервис nova-volume. Также этот узел является получателем трафика по протоколу iSCSI.

Хотя роль оконечного узла очевидна— на нем обычно располагается программный балансировщик нагрузки или программно-аппаратный комплекс, предназначенный для равномерного распределения трафика по компонентам OpenStack и обеспечения бесперебойности работы — управляющий и вычислительный узлы могут быть настроены по-разному, начиная от “толстых” управляющих узлов, на которых располагаются все внутренние служебные процессы OpenStack (планировщик, API-сервисы, Glance, Keystone, RabbitMQ, MySQL) до “тонких”, на которых располагаются только сервисы, ответственные за поддержание состояния OpenStack (RabbitMQ и MySQL). Тогда вычислительные узлы могут взять на себя часть внутренних служебных процессов OpenStack, за счет расположения на них API-сервисов и экземпляров планировщика.

У компании Mirantis есть опыт развертывания топологии сервисов для широкого диапазона клиентов. Здесь я кратко расскажу об этих топологиях, проиллюстрирую их схемами, а также опишу различные способы развертывания OpenStack. (Разделение сервисов можно продолжить и дальше.)

Топология с аппаратным балансировщиком нагрузки

В этом варианте развертывания программно-аппаратный комплекс, предназначенный для балансировки нагрузки, используется в качестве оконечного узла для подключения сервисов OpenStack. API-серверы, планировщики и экземпляры сервиса nova-scheduler развернуты на вычислительных узлах, а экземпляры glance-registry и Horizon развернуты на управляющих узлах.

Все собственные компоненты Nova представляют собой веб-сервисы, не хранящие информацию о состоянии; их масштабирование возможно за счет добавления дополнительных экземпляров в пул (подробно см. статью Mirantis о масштабировании API-сервиcов). Поэтому мы можем просто распределить эти компоненты по ферме вычислительных узлов. База данных и сервер очереди сообщений можно развернуть на обоих управляющих узлах с помощью кластеров (подробно этот способ будет описан в одной из следующих статей). И даже лучше: на управляющем узле теперь располагаются компоненты платформы, которые не являются внутренними сервисами OpenStack (MySQL и RabbitMQ – это стандартные демоны Linux). Таким образом, администратор облака может передать их администрирование внешней сущности, Database Team, выделенному кластеру RabbitMQ. Таким образом центральный управляющий узел устраняется и в нашей конфигурации остается набор вычислительных узлов/API-узлов, которые можно линейно масштабировать.

Топология с выделенным оконечным узлом

В этой конфигурации развертывания мы заменяем аппаратный балансировщик нагрузки оконечным узлом, который распределяет трафик по ферме сервисов. Другим значительным отличием от предыдущей архитектуры является помещение API-сервисов на управляющие узлы вместо вычислительных узлов. По сути управляющие узлы стали “толще”, а вычислительные узлы — “тоньше.” Кроме того, оба управляющих узла работают с переключением из рабочего режима в режим ожидания. Условия сбоя управляющего узла можно определить с помощью таких средств как Pacemaker и Corosync/Heartbeat.

Топология с простым резервированием управляющего узла

В этом варианте развертывания оконечные узлы комбинируются с управляющими узлами. API-сервисы и сервисы nova-scheduler устанавливаются на управляющих узлах, а масштабирование управляющего узла возможно за счет добавления узлов и переконфигурации HAProxy. Два экземпляра HAProxy развертываются для обеспечения бесперебойности, а определение сбоев и переключение определенного HAProxy из режима ожидания в рабочий режим может быть выполнено с помощью таких инструментов как Pacemaker и Corosync/Heartbeat.

Множество способов распределить сервисы

Я проиллюстрировал распределение сервисов по физическим узлам, которое компания Mirantis реализовывала для различных клиентов. Тем не менее, системный администратор может объединять и сочетать сервисы разными способами, в зависимости от ваших потребностей. На схеме ниже показаны — на основе опыта компании Mirantis—различные способы распределения сервисов OpenStack по разным типам узлов.

Аппаратные требования для различных типов узлов

Основную нагрузку на оконечный узел дает подсистема сети. Для узла этого типа требуется высокая производительность центрального процессора и высокая пропускная способность сети. Также для работы узла, если это возможно, полезно объединить сетевые интерфейсы для резервирования и повышения пропускной способности сети.

Управляющий узел облака может быть “толстым“ или “тонким”. Минимальная конфигурация включает компоненты OpenStack, которые поддерживают состояние системы: базу данных и сервер AMQP. Избыточная конфигурация управляющего узла облака требует как минимум два узла; мы рекомендуем использовать связывание сетевого интерфейса для резервирования в сети и массивы RAID1 или RAID10 для резервного хранения. Минимальная конфигурация для управляющего узла:

— Один 6-ядерный процессор

— Оперативная память 8 ГБ

— 2 жестких диска по 1 терабайт в программном массиве RAID1

Вычислительные узлы требуют максимально доступной памяти и мощности процессора. Требования к дисковой системе не очень жесткие, хотя использование SSD-дисков может значительно повысить производительность (так как файловые системы экземпляра узла обычно располагаются на локальном диске). В конфигурации без резервирования возможно использовать один диск, а в случае сбоя заменить диск и вернуть сервер назад в кластер в качестве нового вычислительного узла.

На самом деле требования к аппаратному обеспечению вычислительного узла зависят от оценки пользователем средних параметров виртуального объекта и желаемой плотности объектов на одном физическом узле.

Узлы управления хранением предоставляют виртуальным серверам постоянное хранилище данных в виде блоков. Так как блочное хранилище данных обычно содержит жизненно важные данные, очень важно обеспечить его доступность и целостность данных. Узел хранения должен содержать как минимум шесть дисков. Мы рекомендуем устанавливать операционную систему на избыточном дисковом массиве (RAID1). Оставшиеся четыре диска собраны в массив RAID5 или массив RAID10, в зависимости от конфигурации управляющего узла RAID.

Блочные хранилища совместно используются по протоколу iSCSI, что означает высокую нагрузку на подсистему сети. Мы рекомендуем как минимум два связанных интерфейса для обмена данными по протоколу iSCSI, возможно настроенные специально для обмена трафиком этого вида (jumbo-кадры и т.п.)

Топология сети

Топология сети OpenStack похожа на обычный центр хранения и обработки данных. (Другие статьи Mirantis дают более подробный обзор построения сети OpenStack: FlatDHCPManager, VlanManager.) Внутренний обмен данными между экземплярами происходит поверх фиксированного IP-адреса (частной сети ЦОД). Эта сеть сопрягается с общедоступной посредством транслятора сетевых адресов и сетевого экрана, предоставляемого компонентом nova-network. Для обмена данными с внешним миром используется общедоступная сеть с плавающими IP-адресами (демилитаризованная зона ЦОД). Для управления серверами используется сеть управления (сеть IPMI/BM (Intelligent Platform Management interface/baseboard management controller) ЦОД). Также, если необходимо, можно использовать отдельную сеть хранения для сервисов nova-volume (сеть хранения данных ЦОД). На схеме ниже представлена топология облака (тем не менее, в этом случае трафик по протоколу iSCSI объединен с трафиком управления). Две сети на eth1 представляют собой тегированные интерфейсы поверх eth1, использующие модуль ядра 802.1q.

Общедоступная сеть имеет следующее назначение:

— Сделать экземпляры с плавающими IP-адресами видимыми остальному миру.

— Сделать видимыми виртуальные IP-адреса оконечного узла, которые клиенты используют для подключения к API сервисов OpenStack.

Общедоступная сеть обычно изолирована от частных сетей и сетей управления. Общедоступная/корпоративная сеть представляет собой одну сеть класса C из диапазона публичных сетей владельца облака (для публичных облаков используется глобальная маршрутизация).

Частная сеть представляет собой сегмент сети, подключенный ко всем вычислительным узлам; все мосты на вычислительных узлах подключены к этой сети. Именно по этой сети экземпляры вычислительных узлов обмениваются трафиком по фиксированным IP-адресам. Если используется VlanManager, эта сеть далее сегментируется на изолированные виртуальные локальные сети, по одной на проект, существующий в облаке. Каждая сеть VLAN содержит сеть IP-адресов, выделенных для этого проекта, и объединяет виртуальные машины, которые принадлежат этому проекту. Если используется схема FlatDHCP, виртуальные машины из различных проектов используют единую виртуальную локальную сеть и единое пространство IP-адресов.

Сеть управления объединяет все кластерные узлы и используется для обмена внутренними данными между компонентами кластера OpenStack. Эту сеть следует изолировать от частной и общедоступной сетей по соображениям безопасности. Сеть управления также можно использовать для обмена данными по протоколу iSCSI между вычислительным узлом и узлом хранения, если трафик не слишком интенсивный. Это отдельная сеть класса C из частного диапазона IP-адресов (без глобальной маршрутизации).

Сеть iSCSI не требуется, если рабочая нагрузка не включает значительного объема данных, который обрабатывается блочными устройствами хранения. В случае значительной нагрузки мы рекомендуем обмен данными по протоколу iSCSI по выделенному соединению, чтобы избежать смешения с трафиком управления и обеспечить возможность оптимизации iSCSI-трафика, например, jumbo-кадров, распределения длины очередей для интерфейсов и т.п.

Служебные процессы Openstack vs. сети

В режиме бесперебойности (HA) все центральные компоненты OpenStack необходимо поместить за балансировщиком нагрузки. Для этого вы можете использовать специально выделенное аппаратное обеспечение или оконечный узел. На оконечном узле работает программное обеспечение бесперебойности и балансировки нагрузки; на одном IP-адресе располагается ферма служебных процессов OpenStack. Таблица ниже иллюстрирует расположение сервисов в различных сетях с балансировщиком нагрузки:

Выводы

Развертывание OpenStack можно организовать различными способами — это обеспечивает масштабируемость и доступность. Этот факт не очевиден из документации, которая находится в сети (по крайней мере, для меня не был очевиден), и я наблюдал несколько случаев, когда системные администраторы были уверены, что им обязательно нужен центральный управляющий узел.
Это не так; на самом деле возможны установки без центрального управляющего узла с размещением базы данных и сервера обмена сообщениями за пределами платформы.

В случае распределенной архитектуры необходимо тщательно распределить трафик по нескольким экземплярам сервиса, а также обеспечить тиражирование ресурсов с фиксацией состояния (таких, как MySQL и RabbitMQ). Команда OpenStack пока не упомянула это в своей документации, поэтому Mirantis попытается восполнить этот пробел в будущей серии статей о масштабировании платформы и API-сервисов.

Оригинал статьи (на английском языке): www.mirantis.com/blog/117072/

Автор: Mirantis_OpenStack

Источник