Чтобы понять предлагаемые OpenStack возможности, лучше начать с базовых архитектур, которые продемонстрировали себя на практике и были протестированы промышленных окружениях. Мы предлагаем два таких примера с базовыми операционными системами (Ubuntu и Red Hat Enterprise Linux) и сетевыми архитектурами. Существуют и другие отличия между этими двумя примерами, но вы должны найти соображения, сделанные для выбора в каждом из них, а также обоснование того, почему он хорошо работает в данном окружении.
Поскольку OpenStack является чрезвычайно настраиваемым с использованием очень большого количества параметров серверов и сети, трудно написать документацию, которая охватывала бы все возможные реализации OpenStack. По этой причине данное руководство определяет пример построения для упрощения задачи документирования, а также для обеспечения данного руководства границами. Оба предлагаемых примера архитектуры в настоящее время запущены в производство и обслуживают пользователей.
![[Совет]](../common/images/admon/tip.png) |
Совет |
|---|---|
Как всегда, обратитесь к Словарю если вы не уверены в какой- нибудь терминологии, упоминающейся в этой архитектуре. |
Этот частный пример архитектуры был обновлен с Grizzly на Havana и протестирован на промышленном окружении в котором множество IP адресов доступно для назначения множеству экземпляров. После данного раздела вы сможете найти другой пример архитектуры, который использует OpenStack Networking (neutron). Каждый пример предлагает высокую доступность, означающую, что если некоторый узел выходит из строя, другой узел с аналогичной конфигурацией может взять на себя выполнение задач, следовательно служба будет все еще доступной.
Простейшая архитектура, которую вы можете построить для Compute имеет один контроллер облака и множество вычислительных узлов. Простейшая архитектура для системы хранения объектов имеет пять узлов: один для идентификации пользователей и представления запросов для API, и кроме того четыре для системы хранения самой по себе для обеспечения достаточного числа репликаций для окончательной связности. Этот пример архитектуры не диктует определенного числа узлов, однако показывает понимание и соображения , которые вошли в выбор данной архитектуры включая предложенные функции.
| Компонент | Детали |
|---|---|
Редакция OpenStack |
Havana |
Опреационная система хоста |
Ubuntu 12.04 LTS или Red Hat Enterprise Linux 6.5, включая производные ОС, такие как CentOS и Scientific Linux |
Репозиторий пакетов OpenStack |
Архив облака Ubuntu или RDO* |
Гипервизор |
KVM |
База данных |
MySQL* |
Очередь сообщений |
RabbitMQ для Ubuntu; Qpid для Red Hat Enterprise Linux и производные ОС |
Сетевая служба |
|
Менеджер сети |
FlatDHCP |
Одна |
multi-host* |
Сервер служб образов (glance) |
file |
Драйвер службы идентификации (keystone) |
SQL |
Сервер службы блочного хранения (cinder) |
LVM/iSCSI |
Сервер миграции в реальном времени |
Совместно используемая система хранения с использованием NFS* |
Система хранения объектов |
Система хранения объектов OpenStack (swift) |
Звездочка (*) обозначает, что пример архитектуры отклоняется от значений по умолчанию в установке. Мы дадим объяснения для этих отклонений позже.
![[Замечания]](../common/images/admon/note.png) | Замечания |
|---|---|
|
Следующие свойства OpenStack поддерживаются данным примером архитектуры, документированным в данном руководстве, но не являются обязательными:
|
Этот пример построения был выбран на основе текущего набора свойств по умолчанию OpenStack Havana, с акцентом на стабильность. Мы считаем, что многие облака, которые в настоящее время используют OpenStack в своей деятельности, выполнили подобный выбор.
Вначале вы должны выбрать операционную систему, которая будет работать на всех физических узлах. Хотя OpenStack поддерживается множеством дистрибутивов Linux, мы использовали Ubuntu 12.04 LTS (Long Term Support), которая используется большинством в сообществе разработчиков, имеет полный набор возможностей по сравнению с другими дистрибутивами, а также имеет четкие планы дальнейшей поддержки.
Мы рекомендуем вам не использовать пакеты установки, используемые по умолчанию Ubuntu OpenStack, а вместо этого воспользоваться Архивом Ubuntu Cloud. Архив Cloud является канонически поддерживаемым хранилищем пакетов, что позволяет перейти к будущим версиям OpenStack, оставаясь с Ubuntu 12.04.
KVM в качестве дополнения гипервизора является выбором Ubuntu - будучи хорошо подогнанной парой в терминах поддержки, а также из-за значительной степени внимания, получаемого им от сообщества разработчиков OpenStack (в том числе от авторов, которые в основном используют KVM). Он также полностью укомплектован, свободен от лицензионных сборов и ограничений.
MySQL следует аналогичной тенденции. Несмотря на недавнюю смену собственника, эта база данных является наиболее протестированной для использования с OpenStack и мощно документирована. Мы уклонились от использования базы данных по умолчанию, SQLite, поскольку SQLite не соответствует требованиям к использованию на практике для баз данных.
Выбор RabbitMQ по сравнению с другими AMQP совместимыми вариантами, которые набирают возрастающую поддержку в OpenStack, такими как ZeroMQ и Qpid, связан с простотой его использования и значительного объема тестирования на практике. Он также является единственным вариантом, поддерживает такие свойства, как Compute cell. Мы рекомендуем кластеризацию с использованием RabbitMQ, поскольку он является неотъемлемой составляющей системы, и довольно прост в реализации в связи с его встроенной природой.
Как уже говорилось в предыдущих главах, есть несколько вариантов создания сетей в
OpenStack Compute. Мы рекомендуем FlatDHCP при
использовании режима работы в сети Multi-Host
для обеспечения высокой доступности, запускающего по одному демону nova-network
на хост OpenStack Compute. Это обеспечивает надежный механизм гарантии изоляции прерываний работы сети
в отдельных вычислительных хостах, а также позволяет прямое использование аппаратных сетевых
шлюзов.
Миграция в реальном времени обеспечивается посредством совместного использования системы хранения с NFS в качестве распределенной файловой системы.
Признавая, что для многих мало масштабных реализациях работа службы хранения объектов только для хранения образов виртуальных машин выглядит слишком дорогой, для службы образов OpenStack (Glance) мы выбрали файловые сервера. Если проектируемое вами облако также предполагает запускать службу хранения объектов, вы легко сможете использовать ее в качестве серверов.
Мы отдали предпочтение серверу SQL в качестве службы идентификации (keystone) над другими, например LDAP. Эти сервера просты в установке и надежны. Авторы признают, что для многих установок желательна связь с существующими службами каталогов, и предупреждают о необходимости точного понимания массива доступных опций.
Служба блочного хранения (cinder) изначально устанавливается на внешних узлах- хранилищах и использует плагин LVM/iSCSI. Большинство плагинов службы блочного хранения привязаны к продуктам и реализациям определенного производителя, что ограничивает их использование для потребителей рассматриваемых аппаратных платформ, однако LVM/iSCSI является надежной и стабильной службой при работе на серийно выпускаемой вычислительной технике.
В то время как облако может работать без инструментальной панели (Dashboard) OpenStack, мы расцениваем ее как незаменимую, причем не только для взаимодействия пользователя с облаком, но и в качестве инструмента для операторов. Кроме того, использование инструментальной панели из Django превращает ее в гибкую структуру для расширения.
Данный пример архитектуры не использует сетевую службу OpenStack (neutron), поскольку она пока не осуществляет поддержку сети с многими хостами, а наши организации (университет, правительство) имеют доступ к большому диапазону IPv4 адресов с общественным доступом.
При развертывании OpenStack по умолчанию, именно единcтвенная служба nova-network,
которая работает в облаке (обычно на контроллере облака), предоставляет такие услуги, как трансляция сетевых
адресов (NAT), DHCP, DNS для гостевых экземпляров. Если отказывает один узел, который управляет
службой nova-network, вы не сможете получить доступ к экземплярам, а экземпляры
не смогут получить доступ в интернет. В случае возникновения чрезмерного сетевого трафика, единственный узел,
управляющий службой nova-network, может стать узким местом, и выйти
из состава облака.
|
Совет |
|---|---|
|
Режим с множеством хостов
является вариантом с высоким уровнем доступности для конфигурации сети, в которой служба |
Эталонная архитектура состоит из нескольких вычислительных узлов, контроллера облака, внешнего сервера хранения NFS для хранения экземпляров и сервера блочного хранилища OpenStack для хранения томов (volume). Служба сетевого времени (Network Time Protocol, NTP) синхронизирует время для всех узлов. FlatDHCPManager в режиме мульти-хоста используется для построения сети. Логическая диаграмма для данного примера архитектуры демонстрирует какие службы работают на каждом узле:
Контроллер облака выполняет: инструментальную панель, службы API, базу данных (MySQL), сервер очереди сообщений (RabbitMQ),
планировщик для выбора вычислительных ресурсов (nova-scheduler),
службы идентификации (keystone, nova-consoleauth),
службы образов (glance-api, glance-registry),
службы для консолей доступа гостей, а также службы блочного хранения,
включающие планировщик для ресурсов хранения (cinder-api и cinder-scheduler).
Вычислительные узлы находятся там, где проводятся вычисления, и в нашем
примере применения они выполняют гипервизор (KVM), libvirt (драйвер для
гипервизора, который позволяет динамическую миграцию с узла на узел),
nova-compute, nova-api-metadata (как правило,
используется только при работе в режиме мульти-хоста, он извлекает метаданные определенных экземпляров),
nova-vncproxy и
nova-network.
Сеть состоит из двух коммутаторов, один для управления или частного трафика, и второй, покрывающий общий доступ в том числе плавающие IP-адреса. Для поддержки этого, контроллер облака и вычислительные узлы имеют по две сетевых карты. Серверы хранения блочных данных OpenStack и NFS необходимы исключительно для доступа в частной сети и, следовательно, им нужна только одна сетевая карта, однако, если это возможно , рекомендуется связанная конфигурация с несколькими работающими в одном сервере платами. Плавающий IP доступ идет напрямую в интернет, в то время как доступ связного IP проходит через NAT. Чтобы представить сетевой трафик, используйте эту диаграмму:
Вы можете расширить рассмотренную архитектуру: следующим образом:
Добавить дополнительные облачные контроллеры (см. Главу 11, Обслуживание, сбои и отладка).
Добавить службы OpenStack Storage (см. главу Добавление хранилища объектов в Руководстве по установке OpenStack для вашего дистрибутива).
Добавить дополнительные хосты блочных хранилищ OpenStack (см. Главу 11, Обслуживание, сбои и отладка).
Данный раздел предоставляет пример архитектуры, использующей сетевое оборудование OpenStack, также известное как проект Neutron, в среде с высокой доступностью.
Если вам требуется среда, которую можно масштабировать горизонтально, или вы хотите, чтобы ваше облако продолжало работать после отказа узла, в действие может быть введена среда с высокой доступностью. Данный пример архитектуры был описан на основе текущего набора свойств по умолчанию для OpenStack Havana, с акцентом на высокую доступность.
| Компонента | Детали |
|---|---|
Редакция OpenStack |
Havana |
Операционная система хоста |
Red Hat Enterprise Linux 6.5 |
Репозиторий пакетов OpenStack |
|
Гипервизор |
KVM |
База данных |
MySQL |
Очередь сообщений |
Qpid |
Сетевая служба |
OpenStack Networking |
Разделение владельцев в сети |
VLAN |
Сервер службы образов (glance) |
GlusterFS |
Драйвер службы идентичности (keystone) |
SQL |
Сервер службы блочного хранения (cinder) |
GlusterFS |
Данный приер архитектуры был выбран на основе текущего набора особенностей по умолчанию редакции OpenStack Havana с акцентом на высокую доступность. В настоящее время данная архитектура развернута во внутреннем облаке Red Hat OpenStack и используется для размещенных в нем и совместно используемых служб, которые по своей природе должны обладать очень высокой доступностью.
Компоненты данной архитектуры были отобраны по следующим причинам:
- Red Hat Enterprise Linux
Вы должны выбрать операционную систему, которая может работать на всех физических узлах. Данный пример архитектуры основывается на Red Hat Enterprise Linux, которая предлагает надежность, долгосрочную поддержку, сертифицированные испытания и закаленность. Перемещающиеся сейчас в направлении использования OpenStack корпоративные клиенты обычно нуждаются в таких преимуществах.
- RDO
Пакет Red Hat Distributed OpenStack предлагает простой способ загрузки наиболее новой редакции OpenStack, которая построена под платформу Red Hat Enterprise Linux.
- KVM
KVM является поддерживаемым гипервизором, выбранным для Red Hat Enterprise Linux (и включенным в дистрибутив). Он полностью укомплектован и свободен от лицензионных сборов и ограничений.
- MySQL
MySQL используется для серверов баз данных для всех баз данных в окружении OpenStack. MySQL является поддерживаемой базой данных в выборе для Red Hat Enterprise Linux (и содержится в дистрибутиве); эта СУБД является масштабируемой системой с открытым кодом, к тому же хорошо управляющая памятью.
- Qpid
Apache Qpid предлагает 100 процентную совместимость со стандартом протоколом очередей расширенных сообщений (Advanced Message Queuing Protocol Standard), и его брокер доступен и для C++, и для Java.
- OpenStack Networking
Сетевое обеспечение OpenStack предлагает современную сетевую функциональность, содержащую разделение сетей Layer 2 (L2) и поставщиков сетевых служб.
- VLAN
Использование виртуальных локальных сетей предлагает широковещательное управление, безопасность и прозрачность физического уровня. Если необходимо, для расширения вашего адресного пространства используйте VXLAN.
- GlusterFS
GlusterFS предлагает масштабируемую систему хранения. По мере роста вашей среды вы можете добавлять дополнительные узлы хранения (вместо того, чтобы, например, быть ограниченным дорогим массивом хранения).
Данный раздел предлагает вам подразделение различных типов узлов, составляющих среду OpenStack. Узел является физической машиной, которая снабжена операционной системой и выполняет определенный стек программного обеспечения поверх ее. Таблица 1.1, “Типы узлов” представляет описание и спецификацию узлов.
| Тип | описание | Пример аппаратной реализации |
|---|---|---|
| Контроллер | Узлы контроллера отвечают за выполнение служб управляющего программного обеспечения, необходимого для работы окружения OpenStack. Эти узлы:
|
Модель: Dell R620 ЦПУ: 2x Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz Оперативная память: 32 ГБ Диск: два 300 ГБ 10000 RPM SAS диска Сеть: два сетевых порта 10G |
| Вычислительный узел | Вычислительные узлы выполняют экземпляры виртуальных машин OpenStack. Они:
|
Model: Dell R620 ЦПУ: 2x Intel® Xeon® CPU E5-2650 0 @ 2.00 GHz Оперативная память: 128 GB Диск: два 600 GB 10000 RPM SAS диска Сеть: четыре сетевых порта 10G (Для дальнейшего расширения настройки) |
| Узел хранения | Узлы хранения содержат все необходимые среде данные, включая образы дисков в библиотеке службы образов и постоянные тома системы хранения, создаваемые службой блочного хранения. Узлы хранения используют технологию GlusterFS для хранения высоко доступных и масштабируемых данных. |
Модель: Dell R720xd ЦПУ: 2x Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz Оперативная память: 64 ГБ Диск: два диска 500 ГБ 7200 RPM SAS и двадцать четыре диска 600 ГБ 10000 RPM SAS Disks Raid контроллер: PERC H710P интегрированный RAID контроллер, 1 ГБ NV кеш Сеть: два сетевых порта 10G |
| Сетевой узел | Сетевые узлы отвечают за обеспечение всех виртуальных сетей для клиентов, для создания общедоступных или частных сетей и выдачи виртуальных машин наружу, во внешние сети. Сетевые узлы:
|
Модель: Dell R620 ЦПУ: 1x Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz Оперативная память: 32 ГБ Диск: два диска 300 ГБ 10000 RPM SAS Сеть: пять сетевых портов 10G |
| Сервисные узлы | Сервисные узлы используются исключительно внутренним администрирующим персоналом предоставляя ряд основных функций системного администрирования, необходимых для поддержки в рабочем состоянии среды, а также работы и обслуживания аппаратных средств, операционной системы и программного обеспечения с которыми все работает. Эти узлы выполняют такие службы как выделение ресурсов, управление конфигурацией, мониторинг или управление программным обеспечением GlusterFS. Они не требуют масштабирования, хотя обычно эти машины резервируются. |
Модель: Dell R620 ЦПУ: 2x Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz Оперативная память: 32 ГБ Диск: два диска 500 GB 7200 RPM SAS Сеть: два сетевых порта 10G |
Сетевое оборудование содержит все устройства управления для всего оборудования в среде (например, включает в себя устройства Dell iDrac7 (интегрированного контроллера удаленного доступа Dell) для аппаратуры узлов, а также управляющую инфраструктуру для сетевых коммутаторов). Сетевое оборудование доступно исключительно внутреннему персоналу и только при выполнении задач диагностики и восстановления.
Эта сеть используется для функций управления OpenStack и
обмена, включающего в себя необходимые для предоставления аппаратуры
узлов службы (pxe, tftp,
kickstart), а также обмен между различными типами
узлов OpenStack с помощью OpenStack API и сообщений (например,
nova-compute взаимодействует с keystone
или cinder-volume обращается к
nova-api), а также весь обмен для хранимых данных на
уровне хранения передаваемый по протоколу Gluster. Все физические узлы имеют по
крайней мере один сетевой интерфейс (обычно eth0) в сети.
Эта сеть доступна исключительно через другие VLAN на порт 22 (для ssh
доступа управления машиной).
Данная сеть представляет собой сочетание:
-
IP адресов для интерфейсов на общественной стороне в узлах контроллера (через которые конечные пользователи получат доступ к службам OpenStack)
-
Диапазона подлежащих маршрутизации в общедоступных сетях сетевых адресов IPv4, которые будут использоваться сетевыми средствами OpenStack для плавающих IP. Возможно, вы будете ограничены в своем доступе к адресам IPv4; однако, большой диапазон адресов IPv4 не является необходимым.
-
Маршрутизаторы для частных сетей создаются самой OpenStack.
Эта сеть подключена к узлам контроллера, следовательно, пользователи могут получить доступ к интерфейсам OpenStack, а также подключаться к сетевым узлам для обеспечения виртуальных машин функциональностью маршрутизацией обмена в общедоступных сетях. Эта сеть также подключает сервисные узлы, следовательно может быть доступна любая сервисная служба, которая должна быть открыта (например, мониторинг системы).
Это закрытая сеть, которая не использует общедоступную маршрутизацию и просто используется как частная, внутренняя сеть для обмена между виртуальными машинами в OpenStack, а также между виртуальными машинами и сетевыми узлами, которые обеспечивают маршрутизацию уровня L3 в сеть общего пользования (а также плавающие IP-адреса для обратной связи с виртуальными машинами). Поскольку эта сеть закрытая, мы используем другое адресное пространство по сравнению с остальными для четкого определения такого разделения. К этой сети должны подключаться только вычислительные узлы и сетевые узлы OpenStack.
Следующий раздел даст подробное описание того, каким образом узлы объединяются в различные сети (см. раздел с названием “Компоновка сети”), а также какой дополнительный анализ необходимо выполнить (например, создание перемычек) при объединении узлов в сети.
В начале настройки соединения должны вращаться вокруг поддержки простого и непосредственного соединения для минимизации сложности и времени развертывания. Ввод в действие показан на Рисунке 1.1, “Развертывание базового узла”, преследующим цель наличия связи по 1 × 10G со всеми вычислительными узлами, в то же время используя соединения в соответствующих узлах для достижения максимальной производительности.
Если сетевой подсистемы базовой комплектации оказывается недостаточно, мы можете перейти к Рисунку 1.2, “Развертывание производительного узла”, который предоставляет 2 × 10G сетевые соединения всем экземплярам в среде, а также обеспечивает бОльшую пропускную способность к уровню хранения.
Следующие схемы (с Рисунка 1.3, “Узел контроллера” до Рисунка 1.6, “Узел хранения”) содержат логическую информацию о различных типах узлов с отображением того, какие службы будут работать на них и как они будут взаимодействовать друг с другом. Схемы также иллюстрируют то, каким образом достигается доступность и масштабируемость служб.
Таблица 1.2, “Настройка компонентов третьих производителей” и Таблица 1.3, “Настройка компонентов OpenStack” содержат пример и его анализ как для компонентов третьих производителей и OpenStack components:
| Компонент | Настройка | Доступность | Масштабирование |
|---|---|---|---|
| MySQL | binlog-format = row |
Репликации мастер/мастер. Однако оба узла не используются одновременно. Репликация поддерживает все узлы очень близко к актуальным данным настолько, насколько это возможно (хотя асинхронная природа репликаций означает, что полная согласованность невозможна). Подключение к базе данных осуществляется только через виртуальные IP Pacemaker, обеспечивая что большинство проблем репликации мастер-мастер можно избежать. | Не очень проработано. Как только загрузка сервера MySQL возрастает в достаточной степени для рассмотрения масштабируемости, может использоваться установка с несколькими мастерами или конфигурация ведущий/ведомый. |
| Qpid | max-connections=1000
worker-threads=20
connection-backlog=10, включает безопасность sasl
с аутентификацией SASL-BASIC |
Qpid добавляется в качестве ресурса для программного обеспечения Pacemaker которое выполняется на узлах контроллера, на которых расположен Qpid. Это гарантирует, что только один экземпляр Qpid работает в определенное время, и узел с виртуальным IP Pacemaker всегда будет узлом с запущенным Qpid. | Не очень проработано. Однако, Qpid может быть заменен для работы на всех узлах контроллера для задач масштабируемости и доступности и удален с Pacemaker. |
| HAProxy | maxconn 3000 |
HAProxy является балансировщиком нагрузки программного уровня -7, используемым в качестве точки входа для всех компонентов кластерного API OpenStack и выполняющего терминацию SSL. HAProxy может быть добавлен как ресурс для программного обеспечения Pacemaker, которое работает на узлах контроллера где расположен HAProxy. Это гарантирует, что только один экземпляр работать в определенный момент времени, а узел с виртуальным IP Pacemaker всегда будет узлом с работающим HAProxy. | Не рассматривается. HAProxy имеет достаточно небольшие накладные расходы
производительности, которые один экземпляр должен масштабировать в достаточной
степени для заданного уровня рабочей нагрузки. Если требуется
дополнительное масштабирование, можно добавить перед множеством копий
HAProxy keepalived или
другой балансировщик нагрузки 4 уровня. |
| Memcached | MAXCONN="8192" CACHESIZE="30457" |
Memcached является быстрым кэширующим в оперативной памяти пары ключ-значение программным обеспечением, которое используется компонентами OpenStack для кэширования данных и увеличения производительности. Memcached работает на всех узлах контроллера, гарантируя, что в случае выхода из строя одного из экземпляров, другой экземпляр будет доступен. | Не рассматривается. Один экземпляр Memcached должен иметь возможность масштабирования
до требуемых нагрузок. Если требуется масштабируемость, перед Memcached (в режиме
необработанного tcp) может быть помещен HAProxy для
использования множества экземпляров Memcached для масштабируемости.
Однако это может создать проблемы согласованности кэша. |
| Pacemaker | Настроен на использование corosync и
cman как средство управления стеком/кворумом кластерного
взамиодействия, а также как кластер из двух узлов. |
Pacemaker является кластерным программным обеспечением, используемым для гарантирования доступности служб, запущенных на узлах контроллера и сетевых узлах:
|
Если требуется сделать больше узлов доступных кластеру, Pacemaker может масштабироваться до 64 узлов. |
| GlusterFS | Во всех томах включается профиль производительности "virrt"
glusterfs. Тома устанавливаются в двух узловую репликацию. |
Glusterfs является кластерной файловой системой, которая работает
на узлах хранения для обеспечения постоянных масштабируемых систем хранения данных.
Поскольку все подключения к gluster используют родные gluster
точки монтирования, экземпляры gluster сами по себе
обеспечивают функциональность доступности и отказоустойчивости. |
Масштабируемость систем хранения GlusterFS может быть получена добавлением большего числа томов хранения. |
| Компонент | Тип узла | Настройка | Доступность | Масштабирование |
|---|---|---|---|---|
| Инструментальная панель (horizon) | Контроллер | Настроена на использование Memcached для хранения сессий,
поддержка neutron включена,
can_set_mount_point = False |
Инструментальная панель работает на всех узлах контроллера, обеспечивая доступность по крайней мере одного экземпляра в случае отказа узла. Она также расположена за HAProxy, который определяет отказы программного обеспечения и маршрутизации запросов во всех неисправных экземплярах. | Инструментальная панель выполняется на всех узлах контроллера, следовательно масштабируемость может быть достигнута за счет дополнительных узлов контроллера. HAProxy делает возможным масштабирование инструментальной панели по мере добавления большего числа узлов. |
| Идентификация (keystone) | Контроллер | Настроен на использование Memcached для кэширования и PKI для маркеров. | Идентификация работает на всех узлах контроллера, обеспечивая доступность по крайней мере одного экземпляра в случае отказа узла. Идентификация также расположена за HAProxy, который определяет отказы программного обеспечения и маршрутизации запросов во всех неисправных экземплярах. | Идентификация выполняется на всех узлах контроллера, следовательно масштабируемость может быть достигнута за счет дополнительных узлов контроллера. HAProxy делает возможным масштабирование инструментальной панели по мере добавления большего числа узлов. |
| Служба образов (glance) | Контроллер | /var/lib/glance/images является
монтируемым самой GlusterFS томом для выведения его за пределы
уровня системы хранения. |
Служба образов работает на всех узлах контроллера, обеспечивая доступность по крайней мере одного экземпляра в случае отказа узла. Она также расположена за HAProxy, который определяет отказы программного обеспечения и маршрутизации запросов во всех неисправных экземплярах. | Служба образов выполняется на всех узлах контроллера, следовательно масштабируемость может быть достигнута за счет дополнительных узлов контроллера. HAProxy делает возможным масштабирование инструментальной панели по мере добавления большего числа узлов. |
| Вычислительный узел (nova) | Контроллер, Вычислительные узлы | Настроен на использование Qpid,
Настраивает |
Службы nova API, планировщика заданий, хранилища объектов, cert, consoleauth, conductor и vncproxy работают на всех узлах контроллера, обеспечивая доступность по крайней мере одного экземпляра в случае отказа узла. Compute также расположена за HAProxy, который определяет отказы программного обеспечения и маршрутизации запросов во всех неисправных экземплярах. Вычислительные узлы служб compute и проводника(conductor), которые выполняются на вычислительных узлах, требуются только для выполнения служб на этих узлах, следовательно доступность этих служб тесно сочетается с доступными узлами. Пока вычислительный узел работает, он будет иметь запущенные на нем необходимые службы. |
Службы nova API, планировщика заданий, хранилища объектов, cert, consoleauth, conductor и vncproxy services выполняются на всех узлах контроллера, следовательно масштабируемость может быть достигнута за счет дополнительных узлов контроллера. HAProxy делает возможным масштабирование инструментальной панели по мере добавления большего числа узлов. Масштабируемость служб, запущенных на вычислительных узлах (compute, conductor) достигается в линейную зависимость путем добавления бОльшего числа вычислительных узлов. |
| Система блочного хранения (cinder) | Контроллер | Настроена на использование Qpid, qpid_heartbeat =
10,
настроена на использование томов Gluster
с уровня системы хранения в качестве сервера для блочного хранилища ()Block Storage),
с применением родного клиента Gluster. |
Службы API блочного хранилища, планировщика заданий и томов выполняются на всех узлах контроллера, обеспечивая доступность по крайней мере одного экземпляра в случае отказа узла. Блочное хранилище также расположено за HAProxy, который определяет отказы программного обеспечения и маршрутизации запросов во всех неисправных экземплярах. | Службы API блочного хранилища, планировщика заданий и томов выполняются на всех узлах контроллера, следовательно масштабируемость может быть достигнута за счет дополнительных узлов контроллера. HAProxy делает возможным масштабирование инструментальной панели по мере добавления большего числа узлов для хранения блоков. |
| Сетевые средства OpenStack (neutron) | Контроллер, Вычислительные узлы, Сетевые узлы | Настроен применять QPID,
qpid_heartbeat = 10, включена поддержка
службы имен ядра, tenant_network_type = vlan,
allow_overlapping_ips = true,
tenant_network_type = vlan,
bridge_uplinks = br-ex:em2,
bridge_mappings = physnet1:br-ex |
Служба сети OpenStack работает на всех вычислительных узлах, обеспечивая доступность по крайней мере одного экземпляра в случае отказа узла. Она также расположена за HAProxy, который определяет отказы программного обеспечения и маршрутизации запросов во всех неисправных экземплярах. Службы сетевая среды OpenStack |
Служба сети OpenStack работает на всех вычислительных узлах,
следовательно масштабируемость может быть достигнута за счет
дополнительных узлов контроллера. HAProxy делает возможным
масштабирование сетевой службы по мере добавления
большего числа узлов. Масштабируемость служб, запущенных на
сетевых узлах в настоящее время не поддерживается сетевыми ресурсами
OpenStack, следовательно, они не рассматриваются.
Одной копии служб должно быть достаточно для обработки
данной рабочей нагрузки.
Масштабируемость ovs-agent
работающих на вычислительных узлах, достигается добавлением по
мере необходимости бОльшего числа вычислительных узлов. |
При всем обилии доступных возможностей и опций мы надеемся обеспечить ваше изучение OpenStack несколькими четко обозначенными и проверенными способами. Если вам необходимы допонительные идеи, проверьте Дополнение A. Случаи использования, Руководство по установке OpenStack или Страницу пользовательских историй OpenStack.