Эта статья будет интересна администраторам облачной платформы 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 "AUTO", "VNC" or "SPICE"
# CONSOLE_TYPE = "AUTO"По умолчанию, значение 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).
Автор: celebrate
