Налаштування SPICE-консолі віртуальних машин в OpenStack

Ця стаття буде цікава адміністраторам хмарної платформи OpenStack. Мова піде про відображення консолі віртуальних машин в дашборде. Справа в тому, що за замовчуванням в OpenStack використовується noVNC консоль, яка з прийнятною швидкістю працює в рамках локальної мережі, але погано підходить для роботи з виртуалками, запущеними у віддаленому датацентрі. У цьому випадку чуйність консолі, м'яко кажучи, пригнічує.
У даній статті мова піде про те, як налаштувати в своїй інсталяції Опенстека набагато більш швидку SPICE-консоль.

У Опенстеке є два протоколи графічної консолі виртуалок — VNC і SPICE. З коробки йде веб-реалізація клієнта VNC — noVNC.
Про SPICE знають набагато менше людей. Взагалі, SPICE — це протокол віддаленого доступу, який підтримує масу корисних речей, таких як передача потокового відео, передача аудіо, копіпаст, кидок USB і багато іншого. Однак, в дашборде Опенстека використовується SPICE-HTML5 веб-клієнт, який всі ці функції не підтримує, але зате дуже ефективно і швидко відображає консоль виртуалок, тобто робить саме те, що потрібно.



В офіційній документації (ссылка1 ссылка2) Опенстека досить мало інформації по налаштуванню SPICE-консолі. До того ж йдеться, що «VNC must be explicitly disabled to get access to the SPICE console». Це не зовсім правда, скоріше мова йде про те, що при включеній VNC консоль ви не зможете дашборда скористатися SPICE-консоллю (але як і раніше зможете використовуючи API, тобто «nova get-spice-console», використовуючи python-novaclient). До того ж SPICE-консоль буде доступна тільки для нових виртуалок, старі до хард-ребут, ресайза або міграції як і раніше будуть використовувати тільки VNC.

Отже, в даній статті я використовував відразу дві версії Опенстека від Mirantis: Kilo (Mirantis OpenStack 7.0) і Mitaka (Mirantis OpenStack 9.0). Як і у всіх enterprise-дистрибутивах використовується конфігурація з трьома контролер-нодами і HTTPS фронтенде. Гіпервізор qemu-kvm, операційка скрізь Ubuntu 14.04, деплой хмари здійснювався через Fuel.

Конфігурація застрагивает і контролер-ноди і компут. На контролер-ноди, робимо наступне.
Ставимо сам пакет spice-html5:
apt-get install spice-html5

В конфіг Nova вносимо наступні значення:
/etc/nova/nova.conf
[DEFAULT]
ssl_only = True
cert = '/path/to/SSL/cert'
key = '/path/to/SSL/key'
web=/usr/share/spice-html5

[spice]
spicehtml5proxy_host = ::
html5proxy_base_url = https://<FRONTEND_FQDN>:6082/spice_auto.html
enabled = True
keymap = en-us

де <FRONTEND_FQDN> — це FQDN вашого Horizon-дашборда. Очевидним чином, сертифікат і ключ вище повинні відповідати FRONTEND_FQDN, інакше сучасний браузер не дасть працювати SPICE-віджету. Якщо у вас Horizon не юзає HTTPS, то налаштування SSL можна не робити.

Для одночасної роботи noVNC і SPICE потрібно виконати такий фінт:
cp -r /usr/share/novnc/* /usr/share/spice-html5/

Для роботи через HTTPS потрібно використовувати Secure Websockets, для цього доведеться поправити файл /usr/share/spice-html5/spice_auto.html. В даному ділянці коду потрібно виправити «ws://» на «wss://»

/usr/share/spice-html5/spice_auto.html
function connect()
{
var host, port, password, scheme = "wss://", uri;

Знову ж для одночасної роботи noVNC і SPICE необхідно поправити upstart-скрипти /etc/init/nova-novncproxy.conf /etc/init/nova-spicehtml5proxy.conf. В обох скриптах потрібно закомментить один рядок:

/etc/init/nova-spicehtml5proxy.conf
script
[ -r /etc/default/nova-consoleproxy ] && . /etc/default/nova-consoleproxy || exit 0
#[ "${NOVA_CONSOLE_PROXY_TYPE}" = "spicehtml5" ] || exit 0

/etc/init/nova-novncproxy.conf
script
[ -r /etc/default/nova-consoleproxy ] && . /etc/default/nova-consoleproxy || exit 0
#[ "${NOVA_CONSOLE_PROXY_TYPE}" = "novnc" ] || exit 0

Власне, це дозволяє прибрати перевірку типу консолі з файлу /etc/default/nova-consoleproxy.

Тепер потрібно поправити конфіги Haproxy:

/etc/haproxy/conf.d/170-nova-novncproxy.cfg
listen nova-novncproxy
bind <PUBLIC_VIP>:6080 ssl crt /var/lib/astute/haproxy/public_haproxy.pem no-sslv3 no-tls-tickets ciphers AES128+EECDH:AES128+EDH:AES256+EECDH:AES256+EDH
balance source
option httplog
option http-buffer-request
timeout http request 10s
server controller1 192.168.57.6:6080 ssl verify none check
server controller2 192.168.57.3:6080 ssl verify none check
server controller3 192.168.57.7:6080 ssl verify none check

/etc/haproxy/conf.d/171-nova-spiceproxy.cfg
listen nova-novncproxy
bind <PUBLIC_VIP>:6082 ssl crt /var/lib/astute/haproxy/public_haproxy.pem no-sslv3 no-tls-tickets ciphers AES128+EECDH:AES128+EDH:AES256+EECDH:AES256+EDH
balance source
option httplog
timeout tunnel 3600s
server controller1 192.168.57.6:6082 ssl verify none check
server controller2 192.168.57.3:6082 ssl verify none check
server controller3 192.168.57.7:6082 ssl verify none check

де PUBLIC_VIP — це IP-адреса, на якому висить FRONTEND_FQDN.

Нарешті, рестартуем сервіси на контролер ноди:
service nova-spicehtml5proxy restart 
service apache2 restart
crm resource restart p_haproxy

тут p_haproxy — це Pacemaker-ресурс для Haproxy, через який працюють численні сервіси Опенстека.

На кожній compute-ноде потрібно внести зміни в конфіг Нові:
/etc/nova/nova.conf
[spice]
spicehtml5proxy_host = ::
html5proxy_base_url = https://<FRONTEND_FQDN>:6082/spice_auto.html
enabled = True
agent_enabled = True
server_listen = ::
server_proxyclient_address = COMPUTE_MGMT_IP
keymap = en-us

тут COMPUTE_MGMT_IP — адреса management-інтерфейсу даної compute-ноди (в Mirantis OpenStack є поділ на public management мережі).

Після цього потрібно рестартовать сервіс nova-compute:
service nova-compute restart


Тепер один важливий момент. Я вже писав вище, що ми не виключаємо VNC, оскільки в цьому випадку вже існуючі виртуалки втратять консоль в Дашборде. Однак, якщо ми деплоим хмара з нуля, то має сенс зовсім вимкнути VNC. Для цього потрібно в конфіги Нови на всіх ноди виставити:
[DEFAULT]
vnc_enabled = False
novnc_enabled = False

Але так чи інакше, якщо ми активуємо VNC і SPICE разом у хмарі, в якому вже крутяться виртуалки, то після всіх вищеописаних дій зовні нічого не зміниться ні для вже запущених виртуалок, ні для нових — все одно буде відкриватися noVNC консоль. Якщо подивитися в налаштування Horizon, то тип використовуваної консолі управляється наступній налаштуванням:

/etc/openstack-dashboard/local_settings.py
# Set Console type:
# valid options would be "АВТО", "VNC" або "SPICE"
# CONSOLE_TYPE = "АВТО"

За замовчуванням значення AUTO, тобто тип консолі вибирається автоматично. Але що це означає? Справа в одному файлі, де виставляється пріоритет консолей:

/usr/share/openstack-dashboard/openstack_dashboard/dashboards/project/instances/console.py
...
CONSOLES = SortedDict([('VNC', api.nova.server_vnc_console),
('SPICE', api.nova.server_spice_console),
('RDP', api.nova.server_rdp_console),
('SERIAL', api.nova.server_serial_console)])
...

Як бачите, пріоритет має VNC консоль, якщо вона є. Якщо її немає, то буде шукатися SPICE консоль. Має сенс поміняти перші два пункти місцями, тоді існуючі виртуалки будуть як і раніше працювати з повільною VNC, а нові — з новою швидкої SPICE. Як раз те, що потрібно!

Суб'єктивно, можна сказати, що SPICE-консоль дуже швидка. У режимі без графіки гальм немає взагалі, в графічному режимі все працює теж швидко, а порівняно з VNC-протоколом — просто небо і земля! Так що всім рекомендую!

На цьому налаштування можна вважати закінченою, проте в кінці покажу, як, власне кажучи, виглядають в XML-конфіги libvirt обидві консолі:
<graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0' keymap='en-us'>
<listen type='address' address='0.0.0.0'/>
</graphics>
<graphics type='spice' port='5901' autoport='yes' listen='::' keymap='en-us'>
<listen type='address' address='::'/>
</graphics>

Очевидно, що якщо у вас є мережевий доступ до compute-ноде виртуалки, то ви можете використовувати замість веб-інтерфейсу будь-який інший клієнт VNC/SPICE, просто підключаючись до вищезазначеного в конфігурації TCP порту (в даному випадку 5900 для VNC і 5901 для SPICE).
Джерело: Хабрахабр

0 коментарів

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