20 декабря 2015

Зеркалирование трафика на Open vSwitch для мониторинга сети в OpenStack (port mirroring)

        Зачастую перед администратором встает задача отладки приложений в вашей виртуальной сети OpenStack, и тогда возникает необходимость воспользоваться стандартными привычными инструментами наподобие tcpdump и Wireshark.

        Запустим один экземпляр виртуальной машины:

$ nova boot --flavor m2.tiny --image cirros-raw --key-name demokey1 --security-groups demo-sgroup test-vm




        Далее, определив на каком из вычислительных узлов запустилась виртуальная машина, посмотрим топологию Open vSwitch:

[root@compute-opt ~]# ovs-vsctl show
20eab69c-e759-41b0-a480-97688ec0b4b8
    Bridge br-int
        fail_mode: secure
        Port "qvobee51cf7-fb"
            tag: 1
            Interface "qvobee51cf7-fb"
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        fail_mode: secure
        Port "gre-c0a87adc"
            Interface "gre-c0a87adc"
                type: gre
                options: {df_default="true", in_key=flow, local_ip="192.168.122.215", out_key=flow, remote_ip="192.168.122.220"}
        Port br-tun
            Interface br-tun
                type: internal
        Port "gre-c0a87ad2"
            Interface "gre-c0a87ad2"
                type: gre
                options: {df_default="true", in_key=flow, local_ip="192.168.122.215", out_key=flow, remote_ip="192.168.122.210"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
    ovs_version: "2.4.0"

        Для наглядности я приведу релевантную часть диаграммы сформированной на этом узле при помощи plotnetcfg. Пока не обращайте внимание на интерфейс br-int-tcpdump, который сейчас отсутствует в топологии:



        Теперь из виртуальной машины test-vm попробуем «достучаться» до виртуального маршрутизатора:

$ ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56 data bytes
64 bytes from 172.16.0.1: icmp_seq=0 ttl=64 time=1.766 ms
64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=0.617 ms
...

        Попробуем с вычислительного узла захватить пакеты при помощи tcpdump. Однако все попытки приведут к ошибкам:

[root@compute-opt ~]# tcpdump -npi patch-tun -vvvs0 -w /tmp/dump.cap
tcpdump: patch-tun: No such device exists
(SIOCGIFHWADDR: No such device)
[root@compute-opt ~]# tcpdump -npi br-int -vvvs0 -w /tmp/dump.cap
tcpdump: br-int: That device is not up

        Это связанно с тем, что внутренние устройства Open vSwitch не видимы для большинства утилит извне OVS. В частности, именно из-за этого для реализации групп безопасности в Neutron используется Linux Bridge. Open vSwitch не может работать с правилами iptables, которые применяются на виртуальный интерфейс, непосредственно подключенный к порту коммутатора. Отсюда и появилась «прокладка» в виде моста qbr.
        В качестве выхода мы создадим dummy-интерфейс:

[root@compute-opt ~]# ip link add name br-int-tcpdump type dummy
[root@compute-opt ~]# ip link set dev br-int-tcpdump up

        Затем добавим br-int-tcpdump к мосту br-int трафик с которого мы хотим перехватывать:

[root@compute-opt ~]# ovs-vsctl add-port br-int br-int-tcpdump

        Проверяем:

[root@compute-opt ~]# ovs-vsctl show
20eab69c-e759-41b0-a480-97688ec0b4b8
    Bridge br-int
        fail_mode: secure
        Port "qvobee51cf7-fb"
            tag: 1
            Interface "qvobee51cf7-fb"
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
        Port br-int-tcpdump
            Interface br-int-tcpdump

...

Именно текущей конфигурации соответствует предыдущий рисунок. Осталось открыть man ovs-vsctl и поискать «Port Mirroring». В результате по man-странице задаем следующую команду при помощи которой мы будем зеркалировать трафик со внутреннего порта на br-int-tcpdump:

[root@compute-opt ~]# ovs-vsctl -- set Bridge br-int mirrors=@m -- --id=@br-int-tcpdump get Port br-int-tcpdump -- --id=@br-int get Port br-int -- --id=@m create Mirror name=mirrortest select-dst-port=@br-int select-src-port=@br-int output-port=@br-int-tcpdump select_all=1
49491b7d-d42a-4fbf-a5f5-2db84e7bc30d

        Наконец, можно начать перехватывать трафик:

[root@compute-opt ~]# tcpdump -npi br-int-tcpdump -vvvs0 -w /tmp/dump.cap
tcpdump: WARNING: br-int-tcpdump: no IPv4 address assigned
tcpdump: listening on br-int-tcpdump, link-type EN10MB (Ethernet), capture size 65535 bytes
^C23 packets captured
23 packets received by filter
0 packets dropped by kernel

        Копируем дамп на машину с установленным Wireshark для удобного анализа:

andrey@elx:~$ scp root@192.168.122.215:/tmp/dump.cap .
root@192.168.122.215's password:
dump.cap 100% 2626 2.6KB/s 00:00

        И наконец наша задача выполнена:

13 декабря 2015

Основы облачного хранилища данных Ceph. Часть 2. Установка кластера

My next article about Ceph published in Russian magazine Samag 12/2015, pp 07-11. The hands-on guide to installation of Ceph cluster with ceph-deploy and manual. The third article in January issue will discuss OpenStack integration. The announcement is here http://samag.ru/archive/article/3084

06 декабря 2015

OpenStack: Живая миграция виртуальных машин


Рассмотрим на практике что стоит за кнопкой "Live Migrate Instance" веб-интерфейса и как работает живая миграция виртуальных машин в OpenStack. Сразу оговоримся что для инициации вам понадобятся привилегии администратора облака, поскольку для пользователя информация об облаке скрыта, в том числе и о конкретных гипервизорах на которых запускаются виртуальные машины. Различные балансировки нагрузки и миграции в OpenStack — вне области ответственности пользователя.

Сервис OpenStack Nova поддерживает живую миграцию виртуальных машин в двух вариантах:
  • С общей системой хранения данных. Виртуальная машина перемещается между двумя вычислительными узлами с общим хранилищем к которым оба узла имеют доступ. В качестве общего хранилища может выступать например NFS или Ceph. Сюда же можно отнести вариант когда не используются временные диски (ephemeral disk), а в качестве единственной системы хранения при создании виртуальных машин используется Cinder.
  • Без общей системы хранения данных. Более простой в настройке вариант который мы рассмотрим далее. В этом случае на миграцию требуется больше времени, поскольку виртуальная машина копируется целиком с узла на узел по сети.

Для выполнения упражнения вам понадобятся два работающих гипервизора. Начните с проверки IP-связанности между вычислительными узлами:

[root@compute ~]# ping compute-opt
PING compute-opt.test.local (192.168.122.215) 56(84) bytes of data.
64 bytes from compute-opt.test.local (192.168.122.215): icmp_seq=1 ttl=64 time=0.302 ms
64 bytes from compute-opt.test.local (192.168.122.215): icmp_seq=2 ttl=64 time=0.363 ms
^C

Теперь запустим виртуальную машину и  определим на котором из узлов она работает.

$ nova hypervisor-servers compute.test.local
+----+------+---------------+---------------------+
| ID | Name | Hypervisor ID | Hypervisor Hostname |
+----+------+---------------+---------------------+
+----+------+---------------+---------------------+
$ nova hypervisor-servers compute-opt.test.local
+------------------+-------------------+---------------+------------------------+
| ID               | Name              | Hypervisor ID | Hypervisor Hostname    |
+------------------+-------------------+---------------+------------------------+
| 9e319540-9a67-.. | instance-000000df | 2             | compute-opt.test.local |
+------------------+-------------------+---------------+------------------------+

Мы видим что виртуальная машина работает на узле compute-opt. Дальше определим какой flavor использовался для этой виртуальной машины:

$ nova show 9e319540-9a67-4563-9aad-132c64faa1b1 | grep flavor
| flavor | m2.tiny (98cb36fb-3541-415b-9835-bfc7e73546e3) |

и достаточно ли ресурсов на узле, куда мы хотим мигрировать виртуальную машину:

$ nova host-describe compute.test.local
+--------------------+------------+-----+-----------+---------+
| HOST               | PROJECT    | cpu | memory_mb | disk_gb |
+--------------------+------------+-----+-----------+---------+
| compute.test.local | (total)    | 4   | 3952      | 49      |
| compute.test.local | (used_now) | 0   | 512       | 0       |
| compute.test.local | (used_max) | 0   | 0         | 0       |
+--------------------+------------+-----+-----------+---------+

Как мы видим ресурсов достаточно. Однако прежде чем отдавать команду на миграцию необходимо разрешить демону libvirtd слушать входящие подключения по сети. На обоих гипервизорах добавим опицю:

LIBVIRTD_ARGS="--listen"

в файл /etc/sysconfig/libvirtd, отвечающую за строку запуска демона. Следующим шагом в конфигурационном файле /etc/libvirt/libvirtd.conf разрешим подключение без аутентификации и шифрования:

listen_tls = 0
listen_tcp = 1
auth_tcp = "none"

Альтернативой могло бы быть использование сертификатов или Kerberos. Рестартуем libvirtd на вычислительных узлах:

# systemctl restart libvirtd

Последнее что нужно поправить — это флаги миграции. Делается это также на всех вычислительных узлах:

# crudini --set /etc/nova/nova.conf DEFAULT block_migration_flag VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

Данное изменение необходимо, поскольку флаги по умолчанию включают в себя TUNELLED, который не работает с обновленным кодом NBD (Network Block Device) в QEMU. Для применения изменений необходимо рестаротовать сервис nova-compute:

# systemctl restart openstack-nova-compute.service

Теперь можно отдать команду на живую миграцию, обязательно указав опцию --block-migrate, которая отвечает за миграцию без общего дискового хранилища:

$ source keystonerc_admin
$ nova live-migration --block-migrate 9e319540-9a67-4563-9aad-132c64faa1b1 compute.test.local
Однако, в случае использования CentOS и дистрибутива RDO мы живой миграции не увидим, а получим ошибку в файлах журнала nova-compute:

2015-12-05 23:07:49.391 31600 ERROR nova.virt.libvirt.driver
 [req-4986043d-abf4-40c4-85d4-7c6b3d235986 6310882678344e8183f2d7e886088293
 8cc74ebe8da94fe0a7ac6cf54f31b420 - - -] [instance: 7c505c55-69a8-493c-a119-cba65d58e3bb]
 Live Migration failure: internal error: unable to execute QEMU command 'migrate':
 this feature or command is not currently supported

Это связано с тем, что в CentOS пакет qemu-kvm собран без поддержки ряда функций, включая необходимые для живой миграции без общего хранилища. В дальнейшем CentOS Virt-SIG возможно это исправит, но пока нам необходимо заменить пакет qemu-kvm, подключив репозиторй oVirt, где он присутствует с нужным функционалом:

# yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm
# yum -y install qemu-kvm-ev

В результате пакеты qemu-kvm, qemu-kvm-common и qemu-img будут заменены. Снова можно повторить команду, указав идентификатор виртуальной машины, которую мы хотим мигрировать. При помощи nova show проверим на каком узле работает виртуальная машина до и после миграции:

$ nova show 1d95d3e3-338e-4681-bcb8-d549d1fa1a4c | grep  hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute-opt.test.local   |
$ nova live-migration --block-migrate 1d95d3e3-338e-4681-bcb8-d549d1fa1a4c
$ nova show 1d95d3e3-338e-4681-bcb8-d549d1fa1a4c | grep  hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute.test.local       |

Как мы видим, миграция на этот раз прошла удачно. В журнале должно появиться сообщение подобное следующему:

2015-12-05 23:29:54.298 887 INFO nova.compute.manager
 [req-a09dc90b-8b69-4e15-8dee-f96ac7d197c3 6310882678344e8183f2d7e886088293
 8cc74ebe8da94fe0a7ac6cf54f31b420 - - -] [instance: 1d95d3e3-338e-4681-bcb8-d549d1fa1a4c]
 Migrating instance to compute.test.local finished successfully.

Во время самого процесса миграции на узле-источнике можно следить за ходом ее выполнения при помощи команды virsh:

[root@compute-opt ~]# virsh domjobinfo instance-000000e3
Job type:         Unbounded   
Time elapsed:     1084         ms
Data processed:   25.162 MiB
Data remaining:   1.726 GiB
Data total:       2.016 GiB
Memory processed: 25.162 MiB
Memory remaining: 1.726 GiB
Memory total:     2.016 GiB
Memory bandwidth: 240.426 MiB/s
Constant pages:   69765       
Normal pages:     6276        
Normal data:      24.516 MiB
Expected downtime: 46           ms
Setup time:       2            ms