 |
 С 1991 года на компьютерном рынке России |
 т.: 676 0965, 676 0396 Москва, Сосинская ул. 43, м. Волгоградский проспект |
|||||||||||||||||||||||||||||||||||||
| Руководство по эксплуатации OpenStack | |||||||||||||||||||||||||||||||||||||||
ГЛАВА 7Пример построенияПоскольку OpenStack чрезвачайно настраиваем с использованием очень большого количества параметров серверов и сети, трудно написать документацию, которая охватывала бы все возможные реализации OpenStack. По этой причине данное руководство приводит один пример построения для упрощения задачи документирования, а также сориентировать данное руководство таким образом, чтобы сконцентрироваться на конфигурации, в которой авторы имеют опыт развертывания. Пользуйтесь переводом существенно переработанной и дополенной 2й редакции (12-дек-2014),находящейся теперь и в режиме постоянно обновляемой документации (последняя пока доступна только на англ.яз.). Обзор
Звездочка (*) указывает отклонения примера построения от установок по умолчанию
ОбоснованиеЭтот пример построения был выбран на основе текущего набора свойств по умолчанию OpenStack Folsom, с акцентом на стабильность. В частности, если ни один из авторов руководства не имел опыта развертывания редакции OpenStack Folsom с определенным сервером или конфигурацией, мы не рассматривали их в качестве примера построения. Мы считаем, что многие облака, которые в настоящее время используют OpenStack в своей деятельнсти, выполнили подобный выбор. Вначале вы должны выбрать операционную систему, которая будет работать на всех физических узлах. Хотя OpenStack поддерживается множеством дистрибутивов Linux, мы использовали Ubuntu 12.04 LTS (Long Term Support), которая используется большинством в сообществе разработчиков, имеет полный набор возможностей по сравнению с другими дистрибутивами, а также имеет четкие планы дальнейшей поддержки. Мы рекомендуем вам не использовать пакеты установки,используемые по умолчанию Ubuntu OpenStack, а вместо этого воспользоваться Архивом Ubuntu Cloud (https://wiki.ubuntu.com/ServerTeam/CloudArchive). Архив Cloud является канонически поддерживаемым хранилищем пакетов, что позволяет перейти к будущим версиям OpenStack, оставаясь с Ubuntu 12.04. KVM в качестве дополнения гипервизора является выбором Ubuntu - будучи хорошо подогнанной парой в терминах поддержки, а также из-за значительной степени внимания, получаемого им от сообщества разработчиков OpenStack (в том числе от авторов, которые в основном используют KVM). Он также полностью укомплектован, свободен от лицензионных сборов и ограничений. MySQL следует аналогичной тенденции. Несмотря на недавнюю смену собственника, эта база данных является наиболее протестированой для использования с OpenStack и мощно документирована для работы под Ubuntu. Мы уклонились от использования базы данных по умолчанию, SQLite, поскольку SQLite не соответствует требованиям к использованию на практике для баз данных. Выбор RabbitMQ по сравнению с другими AMQP совместимыми вариантами, которые набирают возрастающую поддержку в OpenStack, такими как ZeroMQ и Qpid, связан с простотой его использования с Ubuntu и значительного объема тестирования на практике. Он также является единственным вариантом, поддерживает такие свойства, как Compute Cell. Мы рекомендуем кластеризацию с использованием RabbitMQ, поскольку он является неотъемлемой составляющей системы, и довольно прост в реализации в связи с его встроенной природой. Как уже говорилось в предыдущих главах, есть несколько вариантов создания сетей в OpenStack Compute.
Мы рекомендуем FlatDHCP при использовании режима работы в сети Multi-Host для обеспечения высокой доступности, запускающего по одному демону Миграция в реальном времени обеспечивается посредством совместного использования СХД с NFS в качестве распределенной файловой системы. Признавая, что для многих маломасштабных реализациях работа службы хранения объектов только для хранения образов виртуальных машин выглядит слишком дорогой, для каталога образов OpenStack и службы предоставления услуг (Glance) мы выбрали файловые сервера. Если проектирумое вами облако также предполагает запускать службу хранения объектов, будет просто использовать Object Storage вместо файловых серверов, причем это является рекомендуемым решением. Мы отдали предпочтение серверу SQL в качестве службы идентификации (keystone) над другими, например LDAP. Эти сервера просты в установке и надежны. Авторы признают, что для многих установок желательна связь с существующими службами каталогов, и предупреждают о необходимости точного понимания массива доступных опций (http://docs.openstack.org/trunk/config-reference/content/ch_configuring-openstack-identity.html#configuring-keystone-for-ldap-backend) Служба блочного хранения (cinder) изначально устанавливается на внешних узлах- хранилищах и использует плагин LVM/iSCSI. Большинство плагинов службы блочного хранения привязаны к продуктам и реализациям определенного производителя, что ограничивает их использование для потребителей рассматриваемых аппаратных платформ, однако LVM/iSCSI является надежной и стабильной службой при работе на серийно выпускаемой вычислительной технике. В то время как облако может работать без инструментальной панели (Dashboard) OpenStack, мы расцениваем ее как незаменимую, причем не только для взаимодействия пользователя с облаком, но и в качестве инструмента для операторов. Кроме того, использование инструментальной панели из Django превращает ее в гибкую структуру для расширения. Почему бы не воспользоваться сетевой службой OpenStack (quantum)?В данном руководстве мы не обсуждаем сетевую службу OpenStack (quantum), поскольку все авторы данного руководства имеют опыт промышленного развертывания исключительно с использованием nova-network. Кроме того, она пока не поддерживает мульти-хостовые сети. Зачем использовать мульти-хостовые сети?При развертывании OpenStack по умолчанию, именно единcтвенная служба Режим с мульти-хостом (Прим.пер.: текущее описание - http://docs.openstack.org/high-availability-guide/content/ch-network.html, устаревшая ссылка из оригинала: http://docs.openstack.org/folsom/openstack-compute/admin/content/existing-ha-networking-options.html#d6e8906) является вариантом с высоким уровнем доступности для конфигурации сети, в которой сервис Подробное описаниеЭталонная архитектура состоит из нескольких вычислительных узлов, контроллера облака, внешнего сервера хранения NFS для хранения экземпляров и сервера блочного хранилища для хранения томов (volume) OpenStack . Служба сетевого времени (Network Time Protocol, NTP) синхронизирует время для всех узлов. FlatDHCPManager в режиме мульти-хоста используется для построения сети.
Контроллер облака выполняет: инструментальную панель, службы API, базу данных (MySQL), сервер очереди сообщений (RabbitMQ), планировщик для выбора вычислительных ресурсов ( Вычислительные узлы находятся там, где проводятся вычисления, и в нашем примере применения они выполняют гипервизор (KVM), Сеть состоит из двух коммутаторов, один для управления или частного трафика, и второй, накрывающий общий доступ в том числе плавающий IP-адреса. Для поддержки этого, контроллер облака и вычислительные узлы имеют по две сетевых карты. Серверы хранения блочных данных OpenStack и NFS необходимы исключительно для доступа в частной сети и, следовательно, им нужна только одна сетевая карта, однако, если это возможно , рекомендуется связанная конфигурация с несколькими работающими в одном сервере платами. Плавающий IP доступ идет напрямую в интернет, в то время как доступ связный IP проходит через NAT.
Дополнительные расширенияВы можете расширить рассмотренную архитектуру следующим образом:
| |||||||||||||||||||||||||||||||||||||||
Следующие свойства OpenStack поддерживаются примером построения приводимом в данном руководстве, но не являются обязательными:
.