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

Эта статья будет интересна администраторам облачной платформы OpenStack. Речь пойдет об отображении консоли виртуальных машин в дашборде. Дело в том, что по умолчанию в OpenStack используется noVNC консоль, которая с приемлемой скоростью работает в рамках локальной сети, но плохо подходит для работы с виртуалками, запущенными в удаленном датацентре. В этом случае отзывчивость консоли, мягко говоря, удручает.
В данном статье речь пойдет о том, как настроить в своей инсталляции Опенстека гораздо более быструю SPICE-консоль.

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

9de56a0df7024b9086d1ecc71cdfe0dd.png

В официальной документации (ссылка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://:6082/spice_auto.html
enabled = True
keymap = en-us

где  — это 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 :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 :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://: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 обе этих консоли:

    
      
    
    
      
    

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

Комментарии (0)

© Habrahabr.ru