OpenStack — розгортаємо «руками» Kilo

Привіт всім Хабралюдям!

У минулій статті, я розповідав про те, як можна швидко розгорнути тестову середу за допомогою 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.
# cat /etc/hosts
10.0.0.11 controller
10.0.0.31 compute1


Налаштовуємо інтерфейси
на контролері:
# cat /etc/network/interfaces
auto p2p1.10
iface p2p1.10 inet static
address 10.0.0.11
netmask 255.255.255.0
gateway 10.0.0.1
dns-серверів імен 10.0.0.1

auto p2p1.11
iface p2p1.11 inet static
address 10.0.1.11
netmask 255.255.255.0

auto p2p1.12
iface p2p1.12 inet static
address 10.0.2.11
netmask 255.255.255.0

# Інтерфейс для зовнішньої мережі
auto p3p1
iface p3p1 inet manual
up ip link set dev $IFACE up
down ip link set dev $IFACE down




на обчислювальному вузлі:
# cat /etc/network/interfaces
auto p2p1.10
iface p2p1.10 inet static
address 10.0.0.31
netmask 255.255.255.0
gateway 10.0.0.1
dns-серверів імен 10.0.0.1

auto p2p1.11
iface p2p1.11 inet static
address 10.0.1.31
netmask 255.255.255.0

auto p2p1.12
iface p2p1.12 inet static
address 10.0.2.31
netmask 255.255.255.0




Перевіряємо, щоб обидві машини бачили один одного і ходили в мережу.

NTP
На контролері:
# apt-get install ntp-y
# cat /etc/ntp.conf 
server ntp.oceantelecom.ru iburst
restrict -4 default kod notrap nomodify
restrict -6 default kod notrap nomodify
# service ntp stop
# ntpdate ntp.oceantelecom.ru
# service ntp start


На обчислювальній ноде:
# apt-get install ntp-y
# cat /etc/ntp.conf 
server controller iburst
# service ntp stop
# ntpdate controller
# service ntp start


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


# apt-get install ubuntu-cloud-keyring
# echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu" "trusty-updates/kilo main" > /etc/apt/sources.list.d/cloudarchive-kilo.list


Kilo досить молодий випуск — квітень 2015 року. Найбільше в цьому релізі мені сподобався російську мову в інтерфейсі Horizon.
Більш докладно можна почитати тут.

Оновлюємося:
# apt-get update && apt-get dist-upgrade-y


SQL + RabbitMQ
У ролі SQL сервера може бути MySQL, PostgreSQL, Oracle або будь-який інший, який підтримується SQLAlchemy. Ми будемо встановлювати MariaDB як і в офіційному мануалі.
# apt-get install mariadb-server python-mysqldb-y
# cat /etc/mysql/conf.d/mysqld_openstack.cnf
[mysqld]
bind-address = 10.0.0.11
default-storage-engine = innodb
innodb_file_per_table
collation-server = utf8_general_ci
init-connect = 'SET NAMES utf8'
character-set-server = utf8

# service mysql restart
# mysql_secure_installation

Якщо є зайві HDD з хорошою продуктивністю, то файли БД можна покласти на нього і це не буде зайвим, якщо ви плануєте розвивати стенд обчислювальними нодами.

Ну і звичайно ж RabbitMQ:
# apt-get install rabbitmq-server
# rabbitmq-plugins enable rabbitmq_management
# service rabbitmq-server restart

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

Створюємо користувача та встановлюємо права йому:
rabbitmqctl add_user openstack RABBIT_PASS
rabbitmqctl set_permissions openstack ".*" ".*" ".*"


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

Підготуємо БД:
# mysql-u root-p
CREATE DATABASE keystone;
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY 'KEYSTONE_DBPASS';
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'KEYSTONE_DBPASS';

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

Відключаємо автозавантаження keystone сервісу та встановлюємо всі необхідні компоненти:
# echo "manual" > /etc/init/keystone.override
# apt-get install keystone python-openstackclient apache2 libapache2-mod-wsgi memcached python-memcache


В конфіги /etc/keystone/keystone.conf прописуємо наступні рядки:
[DEFAULT]
admin_token = ADMIN_TOKEN

[database]
connection = mysql://keystone:KEYSTONE_DBPASS@controller/keystone

[memcache]
servers = localhost:11211

[token]
provider = keystone.token.providers.uuid.Provider
driver = keystone.token.persistence.backends.memcache.Token

[revoke]
driver = keystone.contrib.revoke.backends.sql.Revoke


ADMIN_TOKEN генера за допомогою "openssl rand-hex 16".
Синхронізуємо локальну БД з SQL сервером
# su-s /bin/sh-c "keystone-manage db_sync" keystone


Налаштовуємо апач:
онуча
# cat /etc/apache2/apache2.conf
...
ServerName controller
...
# cat /etc/apache2/sites-available/wsgi-keystone.conf
Listen 5000
Listen 35357

<VirtualHost *:5000>
WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone display-name=%{GROUP}
WSGIProcessGroup keystone-public
WSGIScriptAlias / /var/www/cgi-bin/keystone/main
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
<IfVersion >= 2.4>
ErrorLogFormat "%{cu}t %M"
</IfVersion>
LogLevel info
ErrorLog /var/log/apache2/keystone-error.log
CustomLog /var/log/apache2/keystone-access.log combined
</VirtualHost>

<VirtualHost *:35357>
WSGIDaemonProcess keystone-admin processes=5 threads=1 user=keystone display-name=%{GROUP}
WSGIProcessGroup keystone-admin
WSGIScriptAlias / /var/www/cgi-bin/keystone/admin
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
<IfVersion >= 2.4>
ErrorLogFormat "%{cu}t %M"
</IfVersion>
LogLevel info
ErrorLog /var/log/apache2/keystone-error.log
CustomLog /var/log/apache2/keystone-access.log combined
</VirtualHost>

# ln-s /etc/apache2/sites-available/wsgi-keystone.conf /etc/apache2/sites-enabled
# mkdir-p /var/www/cgi-bin/keystone
# curl http://git.openstack.org/cgit/openstack/keystone/plain/httpd/keystone.py?h=stable/kilo | tee /var/www/cgi-bin/keystone/main /var/www/cgi-bin/keystone/admin
# chown-R keystone:keystone /var/www/cgi-bin/keystone
# chmod 755 /var/www/cgi-bin/keystone/*
# service apache2 restart
# rm-f /var/lib/keystone/keystone.db


Ми міняємо ServerName на ім'я нашого контролера.
Робочі скрипти ми беремо з репозиторію openstack.

Налаштуємо endpoint'и. Вообщем-то саме завдяки endpoint'ам openstack буде знати де і який сервіс працює.

Додамо змінні оточення, для того щоб не вказувати кожен раз в параметрах keystone:
# export OS_TOKEN=ADMIN_TOKEN
# export OS_URL=http://controller:35357/v2.0


Тепер створюємо сервіс:
# openstack service create --name keystone --description "OpenStack Identity" identity

Ну і створюємо API endpoint:
# openstack create endpoint --publicurl http://controller:5000/v2.0 --internalurl http://controller:5000/v2.0 --adminurl http://controller:35357/v2.0 --region RegionOne identity

RegionOne можна поміняти на будь удобочитаемое ім'я. Я буду використовувати його, щоб не «заморочуватися».

Створюємо проекти, користувачів і ролі.

Будемо продовжувати робити за офіційним ману, так що все так само: адмін і демо
# openstack create project --description "Admin Project" admin
# openstack create user --password-prompt admin
# openstack role create admin
# openstack role add --project admin --user admin admin

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

Тепер створюємо проектservice:
# openstack create project --description "Service Project" service


За аналогією з admin'ом створюємо demo:
# openstack create project --description "Demo Project" demo
# openstack create user --password-prompt demo
# openstack create user role
# openstack role add --project demo --user user demo


Створимо скрипти оточення:
сценарії
# cat admin-openrc.sh
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=admin
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=ADMIN_PASS
export OS_AUTH_URL=http://controller:35357/v3
export OS_IMAGE_API_VERSION=2
export OS_VOLUME_API_VERSION=2

# cat demo-openrc.sh
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=demo
export OS_TENANT_NAME=demo
export OS_USERNAME=demo
export OS_PASSWORD=DEMO_PASS
export OS_AUTH_URL=http://controller:5000/v3
export OS_IMAGE_API_VERSION=2
export OS_VOLUME_API_VERSION=2




Власне:
# source admin-openrc.sh

На цьому налаштування сервісу keystone закінчена.

Glance
Glance — це інструмент OpenStack для зберігання шаблонів (образів) віртуальних машин. Образи можуть зберігатися в Swift, у власному сховищі Glance'а, але і де-то ще — головне щоб цей образ можна було отримати по http.

Почнемо як завжди з mysql:
# mysql-u root-p
CREATE DATABASE glance;
GRANT ALL PRIVILEGES ON glance.* TO 'погляд'@'localhost' IDENTIFIED BY 'GLANCE_DBPASS';
GRANT ALL PRIVILEGES ON glance.* TO 'погляд'@'%' IDENTIFIED BY 'GLANCE_DBPASS';


Створимо в keystone інформацію про майбутнє сервісі:
# openstack create user --password-prompt glance
# openstack role add --project service --user glance admin
# openstack service create --name glance --description "OpenStack Image service" image
# openstack create endpoint --publicurl http://controller:9292 --internalurl http://controller:9292 --adminurl http://controller:9292 --region RegionOne image

Ми створюємо користувача glance і підключаємо його до ролі admin, оскільки всі сервіси будуть працювати саме від цієї ролі, ми створюємо сервіс glance, задаємо endpoint.

Тепер приступимо до встановлення:
# apt-get install glance python-glanceclient

і налаштуванні:
налаштування
# 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.

Синхронізуємо БД:
# su-s /bin/sh-c "glance-manage db_sync" glance


Перезапускаємо сервіси і видаляємо локальну БД:
# service glance-registry restart
# service glance-api restart
# rm-f /var/lib/glance/glance.sqlite


В офіційному мануалі завантажується cirros, який загалом-то нам не потрібен, так що ми завантажимо образ Ubuntu:
# mkdir /tmp/images
# wget-P /tmp/images http://cloud-images.ubuntu.com/releases/14.04.2/release/ubuntu-14.04-server-cloudimg-amd64-disk1.img
# glance image-create --name "Ubuntu-Server-14.04.02-x86_64" --file /tmp/images/ubuntu-14.04-server-cloudimg-amd64-disk1.img --disk-format qcow2 --container-format bare --visibility public --progress
# rm-r /tmp/images

Можна відразу залити всі потрібні нам образи, але думаю дочекаємося моменту, коли у нас з'явиться Dashboard.
Загалом — наш сервіс Glance готовий.

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

Контролер


Знову починаємо з БД:
# mysql-u root-p
CREATE DATABASE nova;
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY 'NOVA_DBPASS';
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY 'NOVA_DBPASS';


Додаємо інформацію в keystone:
# openstack create user --password-prompt nova
# openstack role add --project service --user nova admin
# openstack service create --name nova --description "OpenStack Compute" compute
# openstack create endpoint --publicurl http://controller:8774/v2/%\(tenant_id\)s --internalurl http://controller:8774/v2/%\(tenant_id\)s --adminurl http://controller:8774/v2/%\(tenant_id\)s --region RegionOne compute


Встановлюємо необхідні пакети:
# apt-get install nova-api nova-cert nova-conductor nova-consoleauth nova-novncproxy nova-scheduler python-novaclient


/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



Синхронізуємо БД, перезапускаємо сервіси і видаляємо локальну БД.
# su-s /bin/sh-c "nova-manage db sync" nova
# service nova-api restart
# service nova-cert restart
# service nova-consoleauth restart
# service nova-scheduler restart
# service nova-conductor restart
# service nova-novncproxy restart
# rm-f /var/lib/nova/nova.sqlite


Обчислювальний вузол
Тепер ми нарешті почнемо працювати з обчислювальним вузлом. Всі описані дії справедливі для кожного обчислювального вузла в нашій системі.
# apt-get install nova-compute sysfsutils


/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.

Перезапускаємо сервіс і видаляємо локальну копію БД:
# service nova-compute restart
# rm-f /var/lib/nova/nova.sqlite


Перевіряємо чи все правильно працює:
# nova service-list
+----+------------------+------------+----------+---------+-------+----------------------------+-----------------+
| Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+----+------------------+------------+----------+---------+-------+----------------------------+-----------------+
| 1 | nova-conductor | controller | internal | enabled | up | 2014-09-16T23:54:02.000000 | - |
| 2 | nova-consoleauth | controller | internal | enabled | up | 2014-09-16T23:54:04.000000 | - |
| 3 | nova-scheduler | controller | internal | enabled | up | 2014-09-16T23:54:07.000000 | - |
| 4 | nova-cert | controller | internal | enabled | up | 2014-09-16T23:54:00.000000 | - |
| 5 | nova-compute | compute1 | nova | enabled | up | 2014-09-16T23:54:06.000000 | - |
+----+------------------+------------+----------+---------+-------+----------------------------+-----------------+

5ая рядок говорить про те, що ми все правильно зробили.

Ми зробили найголовніше — тепер у нас є IaaS.

Neutron
Neutron це сервіс надає мережа як послуга (NaaS). Взагалі офіційна документація трохи інше визначення дає, але так думаю буде зрозуміліше. Nova-networking оголошений як застарілий в нових версіях OpenStack, тому його ми не будемо. Та й функціонал у neutron значно ширше.

Контролер
Ми встановлюємо ядро мережі на контролері, хоча в мануалі використовується 3я нода. Якщо обчислювальних нод буде досить багато (>10) та/або мережева навантаження буде достатньо висока, то краще винести Network-сервер на окрему ноду.

Як завжди, почнемо з БД
# mysql-u root-p
CREATE DATABASE neutron;
GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' IDENTIFIED BY 'NEUTRON_DBPASS';
GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' IDENTIFIED BY 'NEUTRON_DBPASS';


Keystone:
# openstack create user --password-prompt neutron
# openstack role add --project service --user neutron admin
# openstack service create --name neutron --description "OpenStack Networking" network
# openstack create endpoint --publicurl http://controller:9696 --adminurl http://controller:9696 --internalurl http://controller:9696 --region RegionOne network


Встановлюємо необхідні компоненти:
# apt-get install neutron-server neutron-plugin-ml2 python-neutronclient neutron-plugin-openvswitch-agent neutron-l3-agent neutron-dhcp-agent neutron-metadata-agent


Так само необхідно підправити /etc/sysctl.conf
# cat /etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv4.conf.all..=0
net.ipv4.conf.default..=0

# sysctl-p


/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
# pkill 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 не видаляємо нічого, тільки додаємо.

Синхронізуємо БД і перезапускаємо сервіси:
# su-s /bin/sh-c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron
# service nova-api restart
# service neutron-server restart
# service openvswitch-switch restart


Створюємо міст і пов'язуємо його з external-інтерфейсом
# ovs-vsctl add-br br-ex
# ovs-vsctl add-port br-ex p3p1


Перезапускаємо інтерфейси
# service neutron-plugin-openvswitch-agent restart
# service neutron-l3-agent restart
# service neutron-dhcp-agent restart
# service neutron-metadata-agent restart


Обчислювальний вузол


Без коментарів.
# cat /etc/sysctl.conf
net.ipv4.conf.all..=0
net.ipv4.conf.default..=0
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1

# sysctl-p


# apt-get install neutron-plugin-ml2 neutron-plugin-openvswitch-agent


/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
# service openvswitch-switch restart


Додаємо рядки в /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 nova-compute restart
# service neutron-plugin-openvswitch-agent restart


Якщо я нічого не забув згадати, то повинно вийти так:
# neutron agent-list
+--------------------------------------+--------------------+----------+-------+----------------+---------------------------+
| id | agent_type | host | alive | admin_state_up | binary |
+--------------------------------------+--------------------+----------+-------+----------------+---------------------------+
| 30275801-e17a-41e4-8f53-9db63544f689 | Metadata agent | network | :-) | True | neutron-metadata-agent |
| 4bd8c50e-7bad-4f3b-955d-67658a491a15 | Open vSwitch agent | network | :-) | True | neutron-openvswitch-agent |
| 756e5bba-b70f-4715-b80e-e37f59803d20 | L3 agent | network | :-) | True | neutron-l3-agent |
| 9c45473c-6d6d-4f94-8df1-ebd0b6838d5f | DHCP agent | network | :-) | True | neutron-dhcp-agent |
| a5a49051-05eb-4b4f-bfc7-d36235fe9131 | Open vSwitch agent | compute1 | :-) | True | neutron-openvswitch-agent |
+--------------------------------------+--------------------+----------+-------+----------------+---------------------------+


Мережі
Зараз ми зробимо початкову заготівлю наших мереж. Ми створимо одну зовнішню мережу і одну внутрішню.

Створюємо віртуальну мережу:
# neutron net-create ext-net --router:external --provider:physical_network external --provider:network_type flat


Налаштовуємо нашу зовнішню підмережа:
# neutron subnet-create ext-net 192.168.1.0/24 --name ext-subnet \
--allocation-pool start=192.168.1.100,end=192.168.1.200 \
--disable-dhcp --шлюз 192.168.1.1

Наша зовнішня мережу 192.168.1.0/24 і маршрутизатор випускає в інтернет 192.168.1.1. Зовнішні адреси для нашого хмари будуть видаватися з діапазону 192.168.1.101-200.

Далі ми будемо створювати внутрішню мережу для проекту demo, тому слід завантажити змінні для demo-юзера:
# source demo-openrc.sh


Тепер створюємо віртуальну внутрішню мережу:
# neutron net-create demo-net
# neutron subnet-create demo-net 172.16.1.0/24 --name demo-subnet --gateway 172.168.1.1

Зрозуміло, що наша віртуальна мережа буде 172.16.1.0/24 і всі инстансы з неї будуть отримувати в якості маршрутизатора 172.168.1.1.
Питання: що це за маршрутизатор?
Відповідь: це віртуальний маршрутизатор.

«Фішка» в тому, що в Neutron можна будувати віртуальні мережі з досить великою кількістю підмереж, а значить для них необхідний віртуальний маршрутизатор. Кожен віртуальний маршрутизатор можна додавати порти в будь-яку з доступних віртуальних і зовнішніх мереж. І це дійсно «сильно»! Ми призначаємо маршрутизаторам лише доступ до мереж, а всіма правилами firewall ми управляємо з груп безпеки. Більш того! Ми можемо створити віртуальну машину з програмним маршрутизатором, налаштувати інтерфейси в усі необхідні мережі і керувати доступом через нього (я пробував використовувати Mikrotik).
Загалом, Neutron дає простір фантазії.

Створюємо віртуальний маршрутизатор, призначаємо йому інтерфейс в demo-subnet і приєднуємо його до зовнішньої мережі:
# neutron router-create demo-router
# neutron router-interface-add demo-router demo-subnet
# neutron router-gateway-set demo-router ext-net


Тепер з зовнішньої мережі має пинговаться наш віртуальний маршрутизатор:
# ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_req=1 ttl=64 time=0.619 ms
64 bytes from 192.168.1.100: icmp_req=2 ttl=64 time=0.189 ms
64 bytes from 192.168.1.100: icmp_req=3 ttl=64 time=0.165 ms
64 bytes from 192.168.1.100: icmp_req=4 ttl=64 time=0.216 ms
...


В цілому, у нас вже є працездатна хмара з мережею.

Cinder (Блочне сховище)
Cinder — сервіс надає можливість управляти блоковими пристроями (віртуальними дисками), приєднувати їх до віртуальних инстансам. Віртуальні диски можуть бути і завантажувальними. Це може бути дуже зручно для перенесення VM на інший обчислювальний інстанси.

БД:
# mysql-u root-p
CREATE DATABASE cinder;
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost' IDENTIFIED BY 'CINDER_DBPASS';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'%' IDENTIFIED BY 'CINDER_DBPASS';


Keystone:
# openstack create user --password-prompt cinder
# openstack role add --project service --user cinder admin
# openstack service create --name cinder --description "OpenStack Block Storage" volume
# openstack service create --name cinderv2 --description "OpenStack Block Storage" volumev2
# openstack create endpoint --publicurl http://controller:8776/v2/%\(tenant_id\)s --internalurl http://controller:8776/v2/%\(tenant_id\)s --adminurl http://controller:8776/v2/%\(tenant_id\)s --region RegionOne volume
# openstack create endpoint --publicurl http://controller:8776/v2/%\(tenant_id\)s --internalurl http://controller:8776/v2/%\(tenant_id\)s --adminurl http://controller:8776/v2/%\(tenant_id\)s --region RegionOne volumev2


Установка необхідних пакетів:
# apt-get install cinder-api cinder-scheduler python-cinderclient


Поправимо конфіг:
/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




Далі синхронізуємо БД і перезапускаємо сервіси:
# su-s /bin/sh-c "cinder-manage db sync" cinder
# service cinder-scheduler restart
# service cinder-api restart


Т. к. наш контролер буде так само і сховищем, то такі дії так само проводимо на ньому.
Встановлюємо необхідні пакети:
# apt-get install qemu lvm2

Пам'ятайте я згадував у конфігурації про два 500Гб диска? Ми з них зробимо RAID 1 (вже це описувати я не буду). Чисто технічно, ми могли б просто створити lvm-розділ з двох фізичних дисків, але такий варіант поганий тим, що у нас не HA-проект і падіння одного з дисків може бути критичним. Розбирати як створити RAID-масив я не буду, це легко гуглится. Будемо вважати, що наш рейд називається /dev/md1:
# pvcreate /dev/md1
# vgcreate cinder-volumes /dev/md1

Ми створили фізична LVM-пристрій і створили lvm-групу cinder-volumes.
Далі правимо /etc/lvm/lvm.conf.
Знаходимо (або додаємо) туди такий рядок:
devices {
...
filter = [ "a/md1/", "r/.*/"]

Будемо вважати, що окрім як на рейд-розділі у нас нічого пов'язаного з lvm немає. Якщо робочий розділ так само розгорнуто на lvm, то слід його додати. Наприклад, якщо наша система розгорнута на /dev/md0 і поверх неї розгорнуто lvm, то наш конфіг буде виглядати так:
devices {
...
filter = [ "a/md0/", "a/md1/", "r/.*/"]

У цілому, думаю для тих, хто стикався з lvm це не повинно бути складно.

Встановлюємо необхідні пакети:
# apt-get install cinder-volume python-mysqldb


додаємо в конфіг:
/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




І перезапускаємо сервіси:
# service tgt restart
# service cinder-scheduler restart
# service cinder-api restart
# service cinder-volume restart


Horizon (dashboard)
Horizon — дашбоард для OpenStack, написаний на Python 2.7, движком є Django. З нього ведеться повне управління всією середовищем OpenStack: управління користувачами/проектами/ролями, управління образами, віртуальними дисками, инстансами, мережами і т. д.

Установка
# apt-get install openstack-dashboard

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

Поправимо конфіг /etc/openstack-dashboard/local_settings.py:
...
OPENSTACK_HOST = "controller"
...
ALLOWED_HOSTS = '*'
...
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': '127.0.0.1:11211',
}
}
...
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "user"
...
TIME_ZONE = "Asia/Vladivostok"
...

TIME_ZONE — ваш часовий пояс може бути (і швидше за все буде) іншого. Тут знайдете свій.

Перезапускаємо Апач:
# service apache2 reload


Тепер можна заходити на controller/horizon. У попередній моїй публікації можна подивитися скріни дашборда. В ubuntu додатково встановлюється пакет openstack-dashboard-ubuntu-theme, який додає деякі посилання з натяком на Juju. Якщо захочеться повернути оригінальну версію, то можна просто видалити пакет.

Так само можна в профілі користувача вибрати мову інтерфейсу Українська, то неабияк полегшить роботу Developer'ам.

Готово!

Публікація вийшла досить громіздка, але не хотілося розділяти.
Сподіваюся, ця стаття допоможе кому-небудь.
У наступній публікації (якщо мою карму не закидають «помідорами») буду описувати примітивну установку Chef-сервера і простого рецепту.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.