ГЛАВА 2

Схема контроллера облака

Пользуйтесь переводом существенно переработанной и дополенной 2й редакции (12-дек-2014),
находящейся теперь и в режиме постоянно обновляемой документации
(последняя пока доступна только на англ.яз.).

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

Для получения более подробной информации об общей архитектуре отсылаем вас к Главе 7.

Как описывается в данном руководстве, контроллер облака является отдельным узлом, который поддерживает базы данных, службу очереди сообщений, службу аутентификации и авторизации, службу управления образами, инструментальную панель пользователей, а также API конечных точек (API endpoint).

Контроллер облака обеспечивает централизованную систему управления для развертывания OpenStack с многими узлами. Обычно контроллер облака управляет аутентификацией и отсылкой сообщений всем системам с использованием очереди сообщений.

В нашем примере контроллер облака имеет коллекцию компонентов nova-*, которая представляет глобальное состояние облака, общается со службами, такими как аутентификация, обработка информации об облаке в базе данных, с помощью очередей устанавливает связь со всеми вычислительными узлами и работающими устройствами (worker) систем хранения, а также обеспечивает API. Каждая работающая на выделенном контроллере облака служба может быть разбита на отдельные узлы для масштабируемости или доступности.

Анализ аппаратных средств

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

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

Число предполагаемых к запуску экземпляров
Число имеющихся у вас вычислительных узлов
Число пользователей, которые будут иметь доступ к службам вычислений или хранения
Будут ли пользователи взаимодействовать с вашим облаком через REST API или через инструментальную панель
Будут ли пользователи выполнять аутентификацию во внешней системе (такой, как LDAP или Active Directory)
насколько продолжительной будет работа отдельных экземпляров

Анализ	Результат
Как много экземпляров будет работать одновременно?	Соответствующий размер вашего сервера базы данных, а также, если отчет сообщит о необходимости одновременного наличия многих экземпляров, масштабирование за пределы контроллера облака и планирование вычислительной мощности для запуска нового экземпляра.
Сколько вычислительных узлов работает одновременно?	Убедитесь, что ваши очереди сообщений успешно обрабатывают запросы и имеют соответствующий размер.
Как много пользователей будут иметь API доступ?	Если много пользователей будет делать большое количество запросов, убедитесь, что нагружаемые ЦПУ контроллера облака смогут их обработать.
Как много пользователей будет иметь доступ к инструментальной панели?	Инструментальная панель выполняет много запросов, даже больше, чем API доступ, следовательно, добавьте еще больше ЦПУ, если ваша инструментальная панель выступает в роли главного инструмента для ваших пользователей.
Сколько nova-api служб вы предполагаете использовать в своем облаке?	Вы должны подогнать контроллер по размеру ядер под службы.
Как продолжительно работает одна служба?	Запуск и останов служб запрашивается на вычислительном узле, однако, поскольку существуют потребности очередей API и планировщиков, нагрузка также меняется на узле контроллера.
Выполняется ли вовне верификация вашей системы аутентификации?	Убедитесь в достаточности коммуникаций между контроллером облака и внешней системы аутентификации и мощности ЦПУ контроллера облака для обработки запросов.

Разделение служб

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

Запуск серверов glance-* на сервере swift-proxy	Подобная реализация получает достаточную дополнительную поддержку ввода/вывода прокси- сервера хранилища объектов (Object Storage proxy), к тому же часть Glance, отвечающая за доставку образов получает преимущества от физического размещения на аппаратных средствах хранилища объектов (Object Storage) и, следовательно, наличия хороших коммуникаций с ним.
Запуск центрального выделенного сервера базы данных	Такая реализация имеет центральный выделенный сервер, обеспечивающий базами данных все службы. Это упрощает операции по изоляции обновлений сервера баз данных, а также позволяет упростить создание вторичных серверов баз данных для отказоустойчивости.
Запуск одной VM на службу	Подобное развертывание выполняет центральные службы на наборе серверов с запущенным KVM. Выделенная VM создавалась для каждой службы (планировщик nova, rabbitmq, база данных и т.д.). Это помогает развертыванию при масштабировании, поскольку делает возможной настройку ресурсов для каждой виртуальной машины на основе полученной ими нагрузки (нечто не очень понятное в процессе установки).
Использование внешнего балансировщика нагрузки	Подобная реализация использует дорогостоящее оборудование для балансировщика нагрузки в своей организации. В ней работает много серверов `nova-api` и `swift-proxy` на различных физических серверах и используется балансировщик нагрузки для переключения между ними.

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

Базы данных

Большинство центральных служб OpenStack Compute, а в нстоящее время и узлы вычислений nova используют базу данных для информации о текущих соединениях. Потеря этой возможности ведет к ошибкам. Как результат, мы рекомендуем вам использовать кластер баз данных в некоем виде для придания отказоустойчивости.

Очередь сообщений

Большинство служб OpenStack Compute общаются друг с другом с использованием очередей сообщений. Обычно при отказе очереди сообщений или возникновении ее недоступности кластер медленно деградирует и полностью останавливается в состоянии "доступен только для чтения" с зависшей информацией в точке, в которой было отправлено последнее сообщение. Соответственно, мы рекомендуем, чтобы ваша очередь сообщений кластера - и RabbitMQ имели встроенный механизм решать это.

Интерфейс прикладного программирования (API)

Весь открытый доступ, будь то прямой доступ, доступ с использованием командной строки или через инструментальную панель на основе веб- интерфейса использует службу API. Справочные материалы по API вы найдете по адресу http://api.openstack.org/.

Вы можете выбрать между Amazon EC2 совместимым API или только OpenStack API. Одна из проблем, которая может возникнуть при работе сразу с двумя API, заключается в несовместимости при обращении к образам и экземплярам. Например, EC2 API обращается к экземпляру с использованием шестнадцатиричного ID, в то время как OpenStack API использует имена и числа. Аналогично, EC2 API, как правило, полагается на псевдонимы DNS для соединения с виртуальными машинами, в отличие от OpenStack, который обычно перечисляет IP адреса.

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

Расширения

Спецификация API (http://docs.openstack.org/api/api-specs.html) определяет основные операции, совместимости и типы носителей OpenStack API. Клиент всегда может зависеть от доступности этого ядра API и разработчиков реализации всегда требуется поддерживать его в полном объеме. Требование строгого соответствия ядра API дает возможность клиентам полагаться на минимальный уровень функциональности при взаимодействии с различными реализациями одного и того же API.

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

Планировщик

Подгонка различных по размеру виртуальных машин (на разный вкус) к физическим nova- вычислительным узлам различных размеров является слжной задачей - обычно изучаемая в теории вычислительной техники как проблема упаковки.

Вы можете использовать различные методы для решения этой проблемы, один из которых заключается в наличии линейно масштабируемых предпочтительных размеров, который будет пропорционален долям физической производительности узла, хотя решение данной проблемы выходит за пределы данной книги. Для поддержки вашего выбора планирования OpenStack Compute предоставляет несколько драйверов планировщиков, полное обсуждение которых можно найти в справочном руководстве (http://docs.openstack.org/folsom/openstack-compute/admin/content/ch_scheduling.html).

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

Образы

Служба доставки и каталога образов OpenStack (OpenStack Image Catalog and Delivery) состоит из двух частей - glance-api и glance-registry. Первая отвечает за доставку образов и их использование вычислительными узлами для загрузки образов с серверов баз данных. Последняя поддерживает метаданные, связанные с образами виртуальных машин и необходимыми серверами хранения.

glance-api

Хранилище объектов OpenStack. Позволяет вам хранить образы в качестве объектов.
Файловая система. Использует любые существующие файловые системы для хранения образов в виде файлов.
S3. Позволяет вам осуществлять выборку образов из Amazon S3.
HTTP. Позволяет вам осуществлять выборку образов с веб- сервера. При использовании данного режима вы не можете записывать образы.

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

Инструментальная доска

Инструментальная доска OpenStack (OpenStack Dashboard) реализуется в виде веб приложения Python запущенного на Apache httpd. Таким образом, вы можете рассматривать его аналогичным любому другому веб- приложению, при условии, что ему доступны API серверы (включая его административные конечные приложения) с использованием сети.

Аутентификация и авторизация

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

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

Служба идентификации OpenStack (OpenStack Identity Service, Keystone) является пунктом, который обеспечивает решения об аутентификации и информацию об атрибутах пользователя, которые затем используются другими службами OpenStack для выполнения авторизации. Политики устанавливаются в файле policy.json. Для информации об их настройке, см. Главу 9.

Хранимые в памяти значения ключей
база данных SQL
PAM
LDAP

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

Анализ сети

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

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

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

Глава 1	Оглавление	Глава 3

Перевод: Copyright © 2014 . All rights reserved. Ссылки обязательны (Refs and links obligatory).		http://www.mdl.ru