И снова здравствуйте!
Нет, это не Fez
В прошлый раз я вкратце рассказал, что есть на рынке open-source для создания карманного облака.
Теперь же настало время рассказать вам про сам OpenStack и его реализацию в виде Mirantis OpenStack 5.1.
Вместо тысячи слов
Для начала я вкратце расскажу, из чего же состоит OpenStack. Итак, Horizon — непосредственно веб интерфейс, через него происходит большая часть работы с облаком. В редких случаях вам понадобится делать что-то из консоли. Nova — занимается provisioning'ом ваших виртуалок. Всё, что связано с настройкой libvirt, раздачей квот, выбором физического железа для размещения находится в nova, так же этот компонент отвечает за один из вариантов сети — nova-network. Neutron(в прошлом Quantum) — отвечает за всё, что связанно с сетью — интерфейсы, виртуальные роутеры, dhcp, маршрутизация. В основе лежит Open vSwitch. Если что-то невозможно сделать через веб интерфейс, то скорее всего это реализуется в консоли. Cinder — отвечает за работу с блочными устройствами, все вопросы по выдаче дополнительных дисков в вашу виртуалку направляются сюда. Glance — тут хранятся изначальные образы виртуалок. Здесь же хранятся снапшоты работающих систем. Swift — объектное хранилище(object storage). Имеет обширное API для работы с файлами, совместимо с Amazon S3. Cellometr — мониторинг всего и вся. Собирает данные со всех компонентов облака, складирует, анализирует. Работает через REST API. Keystone — последний и самый важный компонент. Производит авторизацию и аутентификацию всех остальных компонентов, а так же пользователей, от скорости его работы напрямую зависит как быстро вы будете получать доступ к остальным компонентам. Умеет интеграцию с LDAP. Heat — с его помощью вы можете автоматизировать установку виртуалок любой конфигурации. Использует HOT (Heat orchestration template) — по сути yaml-файл с описанием основных параметров и отдельной секцией userdata в которую вы можете писать как sh-скрипты, так и bat.
Так же в OpenStack Juno будет добавлена пара новых компонентов. Ironic — работа с «голым» железом. По сути то, чем сейчас занимается Fuel — загрузка по PXE, работа с IPMI и прочие прелести. Trove — база данных как сервис (DBaaS). Более подробно тут.
Что это такое вы можете глянуть по ссылке в начале статьи. Теперь же я расскажу, что и как тут настраивается. Первое что вы видите после установки — окно логина, а за ним кнопку создания окружения. Тут описываются базовые параметры вашего облака, как то — строим отакзоустойчивое облако или нет, что использовать в качестве бекенда — LVM или Ceph, какую сеть хотим, строимся мы на реальном железе (KVM), виртуальном (QEMU) или вообще хотим просто управлять уже рабочей vSphere ESXi. Для последнего у вас должен быть установлен vCenter. В качестве ОС вы можете выбрать либо CentOS 6.5 либо Ubuntu 12.04.4. Моя конфигурация выглядит как non-HA/Ceph/KVM/Neutron GRE соответственно некоторые вещи описанные в статье могут не подходить для другой схемы. Много вопросов может вызвать выбор сети, от этого же параметра зависят некоторые настройки в дальнейшем.
Disclaimer: openstack разделяет сеть на сегменты. Management сеть — для работы служебных команд OpenStack, из этой же сети ваши сервера будут получать ip-адреса. Storage — сеть, по которой ездит весь трафик от вашего хранилища. Public — это ваша реальная сеть, она маршрутизируется «в мир» и из неё же вы выдаёте адреса для виртуалок в облаке. Сети вы можете разделить как физически, так и при помощи VLAN. Для работы Fuel необходима еще одна, не тегированная, сеть. В ней будет жить DHCP+PXE и по ней же будет осуществляться проверка доступности серверов.
Кликабельно
Nova-network — переведена в статус deprecated. Подходит только для совсем домашнего использования, когда вам не надо разделять облако между разными клиентами. Умеет работать только с layer 3 модели OSI.
Neutron with VLAN — необходима поддержка 802.1Q на роутере. Так же только с этой опцией работает melanox'овый драйвер с SR-IOV плагином и iSER. Предполагается, что вы знаете кол-во клиентов заранее, поскольку требует указать конечное число используемых VLAN ID. Возможны проблемы с CentOS, для их устранения в Fuel есть «VLAN splinters».
Neutron with GRE — альтернативный вариант сети. Связность между нодами осуществляется с помощью GRE-тоннелей, это создаёт дополнительную нагрузку на процессор, но избавляет от необходимости заранее считать количество клиентов и настраивать VLAN'ы на роутерах. Так же, в отличии от предыдущего варианта, нет необходимости в отдельном сетевом интерфейсе.
Disclaimer 2: На текущий момент существует ограничение в Fuel UI при настройке neutron сети — Public и Floating IP должны быть из одного сегмента сети (CIDR). Теоретически это можно сделать уже после установки всех компонентов облака через Open vSwitch CLI. Больше информации про разницу между сетями и примеры настройки некоторых моделей свитчей вы можете найти здесь. Так же рекомендую ознакомиться с замечательной статьей про VxLAN.
Я бы описал это как «сетевой RAID». Это распределенная файловая система, предоставляющая как блочные устройства, так и объектные хранилища. Система критична к таймингам, поэтому время на всех серверах должно быть синхронизировано. Имеет очень хорошую документацию, потому заниматься здесь её переводом я не буду. Fuel вполне неплохо* справляется с настройкой, так что в базовой конфигурации вам практически ничего не надо допиливать напильником.
Окно настройки диска в Fuel
Диск можно разделить на 4 логические части. И если с первым тремя всё вроде как понятно, то вот Virtual Storage у меня долго вызывал вопросы. Как оказалось, его нельзя сделать меньше 5Гб, но это еще пол беды. Основная проблема вылезла когда я пытался использовать qcow2 образы для создания виртуалок — этот раздел нужен был OpenStack'у что б конвертировать образ в raw и складывать в cinder. Так же он требовался для создания снапшотов с qcow2. В итоге мне пришлось потратить несколько дней на вылавливание неочевидных ошибок из логов и чтение документации, чтобы перейти на работу исключительно с raw образами системы.
Внимание на колонки (total)
И напоследок немного про распределение ресурсов. Изначально Fuel настраивает cpu_allocation_ratio=8.0, что означает что на 1 реальный cpu вашего сервера можно выделить 8 «виртуальных». Вы можете изменить этот параметр в /etc/nova/nova.conf и после перезапуска openstack-nova-api должны бы увидеть это в вебморде, но из-за бага в API это пока невозможно. Та же проблема возникнет если вы поменяете ram_allocation_ratio (по дефолту стоит 1). Как ведут себя приложения внутри виртуалок, когда вся доступная память исчерпана дважды (ram_allocation_ratio=2) мне еще предстоит выяснить. Но памятуя как это работало в OpenVZ, я не советую вам сильно изменять этот параметр.
В следующей, и скорее всего заключительной, статье я попытаюсь рассказать, как в пределах одного облака построить несколько гипервизоров (KVM + Docker), как автоматизировать настройку виртуалок при помощи Heat и Murano, а так же немного про мониторинг и поиски «узкого горлышка» в вашем облаке.
Нет, это не Fez
В прошлый раз я вкратце рассказал, что есть на рынке open-source для создания карманного облака.
Теперь же настало время рассказать вам про сам OpenStack и его реализацию в виде Mirantis OpenStack 5.1.
OpenStack
Вместо тысячи слов
Для начала я вкратце расскажу, из чего же состоит OpenStack. Итак, Horizon — непосредственно веб интерфейс, через него происходит большая часть работы с облаком. В редких случаях вам понадобится делать что-то из консоли. Nova — занимается provisioning'ом ваших виртуалок. Всё, что связано с настройкой libvirt, раздачей квот, выбором физического железа для размещения находится в nova, так же этот компонент отвечает за один из вариантов сети — nova-network. Neutron(в прошлом Quantum) — отвечает за всё, что связанно с сетью — интерфейсы, виртуальные роутеры, dhcp, маршрутизация. В основе лежит Open vSwitch. Если что-то невозможно сделать через веб интерфейс, то скорее всего это реализуется в консоли. Cinder — отвечает за работу с блочными устройствами, все вопросы по выдаче дополнительных дисков в вашу виртуалку направляются сюда. Glance — тут хранятся изначальные образы виртуалок. Здесь же хранятся снапшоты работающих систем. Swift — объектное хранилище(object storage). Имеет обширное API для работы с файлами, совместимо с Amazon S3. Cellometr — мониторинг всего и вся. Собирает данные со всех компонентов облака, складирует, анализирует. Работает через REST API. Keystone — последний и самый важный компонент. Производит авторизацию и аутентификацию всех остальных компонентов, а так же пользователей, от скорости его работы напрямую зависит как быстро вы будете получать доступ к остальным компонентам. Умеет интеграцию с LDAP. Heat — с его помощью вы можете автоматизировать установку виртуалок любой конфигурации. Использует HOT (Heat orchestration template) — по сути yaml-файл с описанием основных параметров и отдельной секцией userdata в которую вы можете писать как sh-скрипты, так и bat.
Так же в OpenStack Juno будет добавлена пара новых компонентов. Ironic — работа с «голым» железом. По сути то, чем сейчас занимается Fuel — загрузка по PXE, работа с IPMI и прочие прелести. Trove — база данных как сервис (DBaaS). Более подробно тут.
Fuel
Что это такое вы можете глянуть по ссылке в начале статьи. Теперь же я расскажу, что и как тут настраивается. Первое что вы видите после установки — окно логина, а за ним кнопку создания окружения. Тут описываются базовые параметры вашего облака, как то — строим отакзоустойчивое облако или нет, что использовать в качестве бекенда — LVM или Ceph, какую сеть хотим, строимся мы на реальном железе (KVM), виртуальном (QEMU) или вообще хотим просто управлять уже рабочей vSphere ESXi. Для последнего у вас должен быть установлен vCenter. В качестве ОС вы можете выбрать либо CentOS 6.5 либо Ubuntu 12.04.4. Моя конфигурация выглядит как non-HA/Ceph/KVM/Neutron GRE соответственно некоторые вещи описанные в статье могут не подходить для другой схемы. Много вопросов может вызвать выбор сети, от этого же параметра зависят некоторые настройки в дальнейшем.
Disclaimer: openstack разделяет сеть на сегменты. Management сеть — для работы служебных команд OpenStack, из этой же сети ваши сервера будут получать ip-адреса. Storage — сеть, по которой ездит весь трафик от вашего хранилища. Public — это ваша реальная сеть, она маршрутизируется «в мир» и из неё же вы выдаёте адреса для виртуалок в облаке. Сети вы можете разделить как физически, так и при помощи VLAN. Для работы Fuel необходима еще одна, не тегированная, сеть. В ней будет жить DHCP+PXE и по ней же будет осуществляться проверка доступности серверов.
Кликабельно
Nova-network — переведена в статус deprecated. Подходит только для совсем домашнего использования, когда вам не надо разделять облако между разными клиентами. Умеет работать только с layer 3 модели OSI.
Neutron with VLAN — необходима поддержка 802.1Q на роутере. Так же только с этой опцией работает melanox'овый драйвер с SR-IOV плагином и iSER. Предполагается, что вы знаете кол-во клиентов заранее, поскольку требует указать конечное число используемых VLAN ID. Возможны проблемы с CentOS, для их устранения в Fuel есть «VLAN splinters».
Neutron with GRE — альтернативный вариант сети. Связность между нодами осуществляется с помощью GRE-тоннелей, это создаёт дополнительную нагрузку на процессор, но избавляет от необходимости заранее считать количество клиентов и настраивать VLAN'ы на роутерах. Так же, в отличии от предыдущего варианта, нет необходимости в отдельном сетевом интерфейсе.
Disclaimer 2: На текущий момент существует ограничение в Fuel UI при настройке neutron сети — Public и Floating IP должны быть из одного сегмента сети (CIDR). Теоретически это можно сделать уже после установки всех компонентов облака через Open vSwitch CLI. Больше информации про разницу между сетями и примеры настройки некоторых моделей свитчей вы можете найти здесь. Так же рекомендую ознакомиться с замечательной статьей про VxLAN.
Ceph
Я бы описал это как «сетевой RAID». Это распределенная файловая система, предоставляющая как блочные устройства, так и объектные хранилища. Система критична к таймингам, поэтому время на всех серверах должно быть синхронизировано. Имеет очень хорошую документацию, потому заниматься здесь её переводом я не буду. Fuel вполне неплохо* справляется с настройкой, так что в базовой конфигурации вам практически ничего не надо допиливать напильником.
Окно настройки диска в Fuel
Диск можно разделить на 4 логические части. И если с первым тремя всё вроде как понятно, то вот Virtual Storage у меня долго вызывал вопросы. Как оказалось, его нельзя сделать меньше 5Гб, но это еще пол беды. Основная проблема вылезла когда я пытался использовать qcow2 образы для создания виртуалок — этот раздел нужен был OpenStack'у что б конвертировать образ в raw и складывать в cinder. Так же он требовался для создания снапшотов с qcow2. В итоге мне пришлось потратить несколько дней на вылавливание неочевидных ошибок из логов и чтение документации, чтобы перейти на работу исключительно с raw образами системы.
Скрытый текст
* — Есть некоторые проблемы с Ceph как бекендом для glance/cinder. Отчасти они вызваны ошибками в puppet скриптах самого Fuel, отчасти это особенности логики OpenStack. Так например ceph умеет нормально работать только с RAW образами. Если вы будете использовать Qcow2 (который, кстати, из коробки подразумевает copy-on-write, в отличии от raw), то OpenStack для работы с этим образом будет вызывать 'qemu-img convert', что даёт ощутимую нагрузку как на дисковую систему, так и на процессор. Так же при работе с raw на текущий момент есть проблемы с созданием снапшотов — вместо того, что б сделать тот же CoW, Ceph'у приходится копировать образ целиком. А это в свою очередь резко увеличивает потребление места. Правда к выходу Mirantis OpenStack 6 эту проблему обещали исправить. Также стоит внимательно следить за свободным местом на контроллерах, где Fuel располагает ceph monitor. Как только на корневом разделе у вас останется менее 5% свободного места — ceph-mon сыпется и начинаются проблемы с доступом к ceph-osd.
Есть еще одна не очень приятная особенность в самом Horizon — он неправильно считает доступное на стораджах место. Так, например, если у вас есть 5 серверов, на которых суммарно 1Tb Ceph стораджа, в дашборде вы увидите 5Tb доступного места. Дело в том, что ceph рапортует о общем объеме хранилища с каждой ноды, а horizon просто суммирует эти данные.
Есть еще одна не очень приятная особенность в самом Horizon — он неправильно считает доступное на стораджах место. Так, например, если у вас есть 5 серверов, на которых суммарно 1Tb Ceph стораджа, в дашборде вы увидите 5Tb доступного места. Дело в том, что ceph рапортует о общем объеме хранилища с каждой ноды, а horizon просто суммирует эти данные.
Внимание на колонки (total)
И напоследок немного про распределение ресурсов. Изначально Fuel настраивает cpu_allocation_ratio=8.0, что означает что на 1 реальный cpu вашего сервера можно выделить 8 «виртуальных». Вы можете изменить этот параметр в /etc/nova/nova.conf и после перезапуска openstack-nova-api должны бы увидеть это в вебморде, но из-за бага в API это пока невозможно. Та же проблема возникнет если вы поменяете ram_allocation_ratio (по дефолту стоит 1). Как ведут себя приложения внутри виртуалок, когда вся доступная память исчерпана дважды (ram_allocation_ratio=2) мне еще предстоит выяснить. Но памятуя как это работало в OpenVZ, я не советую вам сильно изменять этот параметр.
В следующей, и скорее всего заключительной, статье я попытаюсь рассказать, как в пределах одного облака построить несколько гипервизоров (KVM + Docker), как автоматизировать настройку виртуалок при помощи Heat и Murano, а так же немного про мониторинг и поиски «узкого горлышка» в вашем облаке.
