My Services

Install manual

Install manual

https://habr.com/ru/articles/262049/

В прошлой статье, я рассказывал о том, как можно быстро развернуть тестовую среду при помощи DevStack. В этой публикации я расскажу как развернуть своё «облако» OpenStack на двух машинах (Controller, Compute) в комплектации:

  • Keystone

  • Glance

  • Nova

  • Neutron

  • Cinder

  • Horizon

В общем-то эта система позволит нам запускать множество виртуальных машин (сколько позволит памяти и CPU на compute), создавать виртуальные сети, создавать виртуальные диски и подключать их к VM, ну и конечно управлять всем этим через удобный дашборд.

Осторожно! Много «портянок» со списком команд и конфигами!

Сразу скажу:

  • Теоретически, я мог забыть что-то дописать или недоправить в конфигах, забыть, что нужно перезапустить какой-то сервис или ещё что-то.

  • Публикация не клонирует, но берёт свои корни из официальной документации, которая есть здесь (англ.)

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

Не надо бездумно «копипастить». Это, конечно, поможет установить OpenStack-среду по данному руководству, но не научит использовать это знание в полевых условиях.

Что будем использовать?

  • Controller i3-540/8Gb/2x120Gb + 2x500Gb/2NIC

  • Compute i7-2600/32Gb/2x500Gb/1NIC

ОС:

Ubuntu 14.04

(Можно использовать CentOS, но руководство будет основано на Ubuntu).

Редакция OpenStack:

Kilo

Подготовка

Сеть

В оригинальном руководстве используется 4 сети:

Management — 10.0.0.0/24 — VLAN 10

Tunnel — 10.0.1.0/24 — VLAN 11

Storage — 10.0.2.0/24 — VLAN 12

External — 192.168.1.0/24

External-сеть в нашем случае смотрит куда-нибудь в домашнюю сеть, но по большому счёту этот интерфейс может смотреть и во «всемирную паутину» — всё зависит от того, для чего разворачиваете облако.

Будет очень неплохо иметь работоспособный dns-server. Я использовал dnsmasq.

Настраиваем интерфейсы

на контроллере:

на вычислительном узле:

Проверяем, чтобы обе машины видели друг друга и ходили в сеть.

NTP

На контроллере:

На вычислительной ноде:

Репозиторий Kilo

Kilo довольно молодой выпуск — апрель 2015 года. Больше всего в этом релизе мне понравился русский язык в интерфейсе Horizon.

Более подробно можно почитать

тут

.

Обновляемся:

SQL + RabbitMQ

В роли SQL сервера может быть MySQL, PostgreSQL, Oracle или любой другой, который поддерживается SQLAlchemy. Мы будем устанавливать MariaDB как и в официальном мануале.

Если есть лишние HDD с хорошей производительностью, то файлы БД можно положить на него и это не будет лишним, если вы планируете развивать стенд вычислительными нодами.

Ну и конечно же RabbitMQ:

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

Создаём пользователя и устанавливаем права ему:

Keystone

Keystone — центр авторизации для OpenStack. Все авторизации проходят через него. Данные Keystone хранит в SQL-БД, но использует так же и memcache.

Подготовим БД:

Естественно, не забудьте подставить свой пароль, как и везде.

Отключаем автозагрузку keystone сервиса и устанавливаем все необходимые компоненты:

В конфиге

/etc/keystone/keystone.conf

прописываем следующие строки:

ADMIN_TOKEN

генерим при помощи "openssl rand -hex 16".

Синхронизируем локальную БД с SQL сервером

Настраиваем апач:

портянка

# cat /etc/apache2/apache2.conf ... ServerName controller ...

Мы меняем

ServerName

на имя нашего контроллера.

Рабочие скрипты мы берём с репозитория openstack.

Настроим endpointы. Вообщем-то именно благодаря endpointам openstack будет знать где и какой сервис работает.

Добавим переменные окружения, для того чтобы не указывать их каждый раз в параметрах keystone:

Теперь создаём сервис:

Ну и создаём API endpoint:

RegionOne

можно поменять на любое удобочитаемое имя. Я буду использовать его, чтобы не «заморачиваться».

Создаём проекты, пользователей и роли.

Будем продолжать делать по официальному ману, так что всё так же: админ и демо

Пароль для админа придумайте сами. По порядку: создали проект «Admin Project», пользователя и роль admin, и соединяем проект и пользователя с ролью.

Теперь создаём проект

service:

По аналогии с admin`ом создаём demo:

Создадим скрипты окружения:

скрипты

Собственно:

На этом настройка сервиса

keystone

закончена.

Glance

Glance — это инструмент OpenStack для хранения шаблонов (образов) виртуальных машин. Образы могут храниться в Swift, в собственном хранилище Glance`а, но и где-то ещё — главное чтобы этот образ можно было получить по http.

Начнём как всегда с mysql:

Создадим в keystone информацию о будущем сервисе:

Мы создаём пользователя glance и подключаем его к роли admin, т.к. все сервисы будут работать именно от этой роли, мы создаём сервис glance, задаём endpoint.

Теперь приступим к установке:

и настройке:

настройка

`# cat /etc/glance/glance-api.conf [DEFAULT] ... notification_driver = noop

[database] connection = mysql://glance:GLANCE_DBPASS@controller/glance

[keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = glance password = GLANCE_PASS

[paste_deploy] flavor = keystone

[glance_store] default_store = file filesystem_store_datadir = /var/lib/glance/images/`

Что бы ни было в секции

[keystone_authtoken]

— это нужно удалить. GLANCE_PASS — пароль от пользователя glance в keystone.

filesystem_store_datadir

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

В

/etc/glance/glance-registry.conf

дублируем ту же информацию из секций

database, keystone_authtoken, paste_deploy, DEFAULT

.

Синхронизируем БД:

Перезапускаем сервисы и удаляем локальную БД:

В официальном мануале загружается

cirros

, который в общем-то нам не нужен, так что мы загрузим образ Ubuntu:

Можно сразу залить все нужные нам образы, но думаю дождёмся момента, когда у нас появится Dashboard.

Целом — наш сервис Glance готов.

Nova

Nova — основная часть IaaS в OpenStack. Собственно благодаря Nova создаются виртуальные машины автоматически. Nova может взаимодействовать с KVM, Xen, Hyper-V, VMware и кажется Ironic (честно говоря не совсем понимаю как это работает). Мы будем использовать KVM, для других гипервизоров конфиги будут отличаться.

Контроллер

Опять начинаем с БД:

Добавляем информацию в keystone:

Устанавливаем необходимые пакеты:

/etc/nova/nova.conf

`[DEFAULT] ... rpc_backend = rabbit auth_strategy = keystone my_ip = 10.0.0.11 vncserver_listen = 10.0.0.11 vncserver_proxyclient_address = 10.0.0.11

[database] connection = mysql://nova:NOVA_DBPASS@controller/nova

[oslo_messaging_rabbit] rabbit_host = controller rabbit_userid = openstack rabbit_password = RABBIT_PASS

[keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = nova password = NOVA_PASS

[glance] host = controller

[oslo_concurrency] lock_path = /var/lib/nova/tmp`

Синхронизируем БД, перезапускаем сервисы и удаляем локальную БД.

Вычислительный узел

Теперь мы наконец начнём работать с вычислительным узлом. Все описанные действия справедливы для каждого вычислительного узла в нашей системе.

/etc/nova/nova.conf

`[DEFAULT] ... verbose = True rpc_backend = rabbit auth_strategy = keystone my_ip = 10.0.0.31 #MANAGEMENT_INTERFACE_IP_ADDRESS vnc_enabled = True vncserver_listen = 0.0.0.0 vncserver_proxyclient_address = 10.0.0.31 #MANAGEMENT_INTERFACE_IP_ADDRESS novncproxy_base_url = http://controller:6080/vnc_auto.html

[oslo_messaging_rabbit] rabbit_host = controller rabbit_userid = openstack rabbit_password = RABBIT_PASS

[keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = nova password = NOVA_PASS

[glance] host = controller

[oslo_concurrency] lock_path = /var/lib/nova/tmp

[libvirt] virt_type = kvm`

MANAGEMENT_INTERFACE_IP_ADDRESS

это адрес вычислительного узла из VLAN 10.

В

novncproxy_base_url

controller должен соответствовать тому адресу, через который будет возможность обратиться через Web-browser. Иначе вы не сможете воспользоваться vnc-консолью из Horizon.

Перезапускаем сервис и удаляем локальную копию БД:

Проверяем всё ли правильно работает:

5ая строчка говорит о том, что мы всё правильно сделали.

Мы сделали самое главное — теперь у нас есть IaaS.

Neutron

Neutron это сервис предоставляющий сеть как услуга (NaaS). Вообще официальная документация немного другое определение даёт, но так думаю будет понятнее. Nova-networking объявлен как устаревший в новых версиях OpenStack, поэтому его мы использовать не будем. Да и функционал у neutron значительно шире.

Контроллер

Мы устанавливаем ядро сети на контроллере, хотя в мануале используется 3я нода. Если вычислительных нод будет достаточно много (>10) и/или сетевая нагрузка будет достаточно высокая, то лучше вынести Network-сервер на отдельную ноду.

Как всегда начнём с БД

Keystone:

Устанавливаем необходимые компоненты:

Так же необходимо подправить

/etc/sysctl.conf

/etc/neutron/neutron.conf

`[DEFAULT] ... rpc_backend = rabbit auth_strategy = keystone core_plugin = ml2 service_plugins = router allow_overlapping_ips = True notify_nova_on_port_status_changes = True notify_nova_on_port_data_changes = True nova_url = http://controller:8774/v2

[oslo_messaging_rabbit] rabbit_host = controller rabbit_userid = openstack rabbit_password = RABBIT_PASS

[database] connection = mysql://neutron:NEUTRON_DBPASS@controller/neutron

[keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = neutron password = NEUTRON_PASS

[nova] auth_url = http://controller:35357 auth_plugin = password project_domain_id = default user_domain_id = default region_name = RegionOne project_name = service username = nova password = NOVA_PASS`

Редактируя конфиг не следует ничего оттуда удалять, кроме закомментированных строк.

/etc/neutron/plugins/ml2/ml2_conf.ini

`[ml2] type_drivers = flat,vlan,gre,vxlan tenant_network_types = gre mechanism_drivers = openvswitch

[ml2_type_gre] tunnel_id_ranges = 1000:2000

[ml2_type_flat] flat_networks = external

[securitygroup] enable_security_group = True enable_ipset = True firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

[ovs] local_ip = 10.0.1.11 #INSTANCE_TUNNELS_INTERFACE_IP_ADDRESS bridge_mappings = external:br-ex

[agent] tunnel_types = gre`

/etc/neutron/l3_agent.ini

[DEFAULT] interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver external_network_bridge = router_delete_namespaces = True

/etc/neutron/dhcp_agent.ini

[DEFAULT] interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq dhcp_delete_namespaces = True dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf

/etc/neutron/dnsmasq-neutron.conf

dhcp-option-force=26,1454 В официальной документации эта настройка использовалась для сетевых устройств без поддержки jumbo frames, но в целом там можно прописать практически любые настройки для dnsmasq.

Убиваем все процессы dnsmasq

/etc/neutron/metadata_agent.ini

[DEFAULT] auth_uri = http://controller:5000 auth_url = http://controller:35357 auth_region = RegionOne auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = neutron password = NEUTRON_PASS nova_metadata_ip = controller metadata_proxy_shared_secret = METADATA_SECRET

/etc/nova/nova.conf

`[DEFAULT] ... network_api_class = nova.network.neutronv2.api.API security_group_api = neutron linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver firewall_driver = nova.virt.firewall.NoopFirewallDriver

[neutron] url = http://controller:9696 auth_strategy = keystone admin_auth_url = http://controller:35357/v2.0 admin_tenant_name = service admin_username = neutron admin_password = NEUTRON_PASS service_metadata_proxy = True metadata_proxy_shared_secret = METADATA_SECRET` METADATA_SECRET это так же набор символов от 10 до 16 символов

Из

nova.conf

не удаляем ничего, только добавляем.

Синхронизируем БД и перезапускаем сервисы:

Создаём мост и связываем его с external-интерфейсом

Перезапускаем интерфейсы

Вычислительный узел

Без комментариев.

/etc/neutron/neutron.conf

`[DEFAULT] ... rpc_backend = rabbit auth_strategy = keystone core_plugin = ml2 service_plugins = router allow_overlapping_ips = True

[oslo_messaging_rabbit] rabbit_host = controller rabbit_userid = openstack rabbit_password = RABBIT_PASS

[keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = neutron password = NEUTRON_PASS`

/etc/neutron/plugins/ml2/ml2_conf.ini

`[ml2] type_drivers = flat,vlan,gre,vxlan tenant_network_types = gre mechanism_drivers = openvswitch

[ml2_type_gre] tunnel_id_ranges = 1000:2000

[ml2_type_flat] flat_networks = external

[securitygroup] enable_security_group = True enable_ipset = True firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

[ovs] local_ip = 10.0.1.31 #INSTANCE_TUNNELS_INTERFACE_IP_ADDRESS bridge_mappings = external:br-ex

[agent] tunnel_types = gre`

Перезапускаем openvswitch

Добавляем строчки в

/etc/nova/nova.conf

Перезапускаем сервисы:

Если я ничего не забыл упомянуть, то должно получиться так:

Сети

Сейчас мы сделаем начальную заготовку наших сетей. Мы создадим одну внешнюю сеть и одну внутреннюю.

Создаём виртуальную сеть:

Настраиваем нашу внешнюю подсеть:

Наша внешняя сеть 192.168.1.0/24 и маршрутизатор выпускающий в интернет 192.168.1.1. Внешние адреса для нашего облака будут выдаваться из диапазона 192.168.1.101-200.

Далее мы будем создавать внутреннюю сеть для проекта

demo

, поэтому следует загрузить переменные для demo-юзера:

Теперь создаём виртуальную внутреннюю сеть:

Понятно, что наша виртуальная сеть будет 172.16.1.0/24 и все инстансы из неё будут получать в качестве маршрутизатора 172.16.1.1.

Вопрос: что это за маршрутизатор?

Ответ: это виртуальный маршрутизатор.

«Фишка» в том, что в Neutron можно строить виртуальные сети с достаточно большим количеством подсетей, а значит для них необходим виртуальный маршрутизатор. Каждый виртуальный маршрутизатор можно добавлять порты в любую из доступных виртуальных и внешних сетей. И это действительно «сильно»! Мы назначаем маршрутизаторам только только доступ к сетям, а всеми правилами firewall мы управляем из групп безопасности. Более того! Мы можем создать виртуальную машину с программным маршрутизатором, настроить интерфейсы во все необходимые сети и управлять доступом через него (я пробовал использовать Mikrotik).

В общем, Neutron даёт простор фантазии.

Создаём виртуальный маршрутизатор, назначаем ему интерфейс в demo-subnet и присоединяем его к внешней сети:

Теперь из внешней сети должен пинговаться наш виртуальный маршрутизатор:

В целом, у нас уже есть работоспособное облако с сетью.

Cinder (Блочное хранилище)

Cinder — сервис предоставляющий возможность управлять блочными устройствами (виртуальными дисками), присоединять их к виртуальным инстансам. Виртуальные диски могут быть и загрузочными. Это может быть очень удобно для переноса VM на другой вычислительный инстанс.

БД:

Keystone:

Установка необходимых пакетов:

Поправим конфиг:

/etc/cinder/cinder.conf

`[DEFAULT] ... rpc_backend = rabbit auth_strategy = keystone my_ip = 10.0.0.11

[oslo_messaging_rabbit] rabbit_host = controller rabbit_userid = openstack rabbit_password = RABBIT_PASS

[database] connection = mysql://cinder:CINDER_DBPASS@controller/cinder

[keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = cinder password = CINDER_PASS

[oslo_concurrency] lock_path = /var/lock/cinder`

Далее синхронизируем БД и перезапускаем сервисы:

Т.к. наш контроллер будет так же и хранилищем, то следующие действия так же проводим на нём.

Устанавливаем необходимые пакеты:

Помните я упоминал в конфигурации про два 500Гб диска? Мы из них сделаем RAID 1 (уж это описывать я не буду). Чисто технически, мы могли бы просто создать lvm-раздел из двух физических дисков, но такой вариант плох тем, что у нас не HA-проект и падение одного из дисков может быть критичным. Разбирать как создать RAID-массив я не буду, это легко гуглится. Будем считать, что наш рейд называется

/dev/md1

:

Мы создали физическое LVM-устройство и создали lvm-группу

cinder-volumes

.

Далее правим

/etc/lvm/lvm.conf

.

Находим (или добавляем) туда такую строку:

Будем считать, что кроме как на рейд-разделе у нас ничего связанного с lvm нет. Если рабочий раздел так же развёрнут на lvm, то следует его добавить. Например, если наша система развёрнута на

/dev/md0

и поверх неё развёрнут lvm, то наш конфиг будет выглядеть так:

В целом, думаю для тех, кто сталкивался с lvm это не должно быть сложно.

Устанавливаем необходимые пакеты:

добавляем в конфиг:

/etc/cinder/cinder.conf

`[DEFAULT] ... enabled_backends = lvm glance_host = controller

[lvm] volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver volume_group = cinder-volumes iscsi_protocol = iscsi iscsi_helper = tgtadm`

И перезапускаем сервисы:

Horizon (dashboard)

Horizon — дашбоард для OpenStack, написан на Python 2.7, движком является Django. Из него ведётся полное управление всей средой OpenStack: управление пользователями/проектами/ролями, управление образами, виртуальными дисками, инстансами, сетями и т.д.

Установка

Установку можно производить на отдельном сервере с доступом к Controller-ноде, но мы установим на контроллере.

Поправим конфиг

/etc/openstack-dashboard/local_settings.py

:

TIME_ZONE

— ваш часовой пояс может быть (и скорее всего будет) другой.

Тут найдёте свой.

Перезапускаем Апач:

Теперь можно заходить на

controller/horizon

. В предыдущей моей публикации можно посмотреть скрины дашборда. В ubuntu дополнительно устанавливается пакет

openstack-dashboard-ubuntu-theme

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

Так же можно в профиле пользователя выбрать язык интерфейса

Русский, то изрядно облегчит работу Developer`ам.

Last updated

Was this helpful?