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

Один из выборов который всегда возникает, использовать виртуализацию или нет. Некоторые службы, такие как серверы nova-compute, swift-proxy и swift-object, не подлежат виртуализации. Однако, серверы управления часто могут быть успешно виртуализованы -падение производительности часто может быть компенсировано простым запуском большего числа служб.

Утрата базыданных ведет к ошибкам. Как результат, мы рекомендуем вам использовать кластер баз данных в некоем виде для придания отказоустойчивости. Настройка и сопровождение кластера базы данных выходит за пределы OpenStack и определяются программным обеспечением самойбазы данных, которую вы выбрали для использования в своей облачной среде. MySQL/Galera является популярным выбором для баз данных на основе MySQL.

Служба проводника (прим. пер. или дирижера: conductor) разрешает обе эти проблемы выступая в качестве прокси для службы nova-compute. Теперь вместо того, чтобы nova-compute напрямую обращалась к базе данных, она взаимодействует со службой nova-conductor, а nova-conductor осуществляет доступ к базе данных в интересах nova-compute. Поскольку nova-compute больше не осуществляет прямой доступ к базе данных, проблема безопасности решена. Дополнительно nova-conductor является неблокирующей службой, следовательно, запросы от всех вычислительных узлов выолняются параллельно.

	Замечание
	Если вы все еще используете nova-network и сетевые службы с множеством хостов в своей облачной среде, nova-compute все еще требует прямого доступа кбазе данных.

Служба nova-conductor горизонтально масштабируется. Чтобы сделать nova-conductor высокодоступной и отказоустойчивой, просто запустите дополнительные экземпляры процесса nova-conductor либо на томже сервере, или на нескольких серверах.

Вы можете выбрать между Amazon EC2 совместимым API или прямым OpenStack API. Одна из проблем, которая может возникнуть при работе сразу с двумя API, заключается в несовместимости при обращении к образам и экземплярам.

Если OpenStack не установлен надлежащим образом, элементарно получить ситуацию, при которой пользователи не смогут связаться со своими экземплярами просто из-за неправильных псевдонимов DNS. Несмотря на это, EC2- совместимость может помочь пользователям мигрировать на ваше облако.

OpenStack Compute API является расширяемым. Расширение добавляет возможности к API поверх уже определенных в ядре. Внедрение новых функций, типов MIME, действий, состояний, заголовков, параметров и ресурсов могут быть выполнены с помощью расширений в ядре API. Это позволяет введение новых функций в API, не требуя изменения версии и позволяет введения ниши функциональности конкретного производителя.

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

Часть glance-api является уровнем абстракции, допускающим выбор сервера образов (back-end). В настоящее время, он поддерживает:

Если у вас есть служба хранения объектов OpenStack (OpenStack Object Storage), мы рекомендуем использовать ее как масштабируемое пространство для хранения ваших образов. Вы также можете использовать файловую систему с достаточной производительностью или Amazon S3 - если вы не нуждаетесь в возможности загрузки новых образов с помощью OpenStack.

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

Служба идентификации поддерживает различные плагины для решений аутентификации и храненилищ информации. Примеры таких плагинов включают в себя:

Многие реализации используют базу данных SQL, однако LDAP также является популярным выбором для решений, которые должны быть интегрированы с существующей инфраструктурой.

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

Мы рекомендуем вам использовать быстрые NIC, например, 10 Gb. Вы также можете выбрать использование двух сетевых карт 10 Gb и объединить их вместе. Хотя вы не можете получить всю объединенную скорость 20 Gb, различные потоки используют различные сетевые адаптеры. Например, если контроллер облака передает два образа, каждый образ использует отличную сетевую карту и получает полную пропускную способность 10 Gb.