Зачастую перед администратором встает задача отладки приложений в вашей виртуальной сети 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
И наконец наша задача выполнена:
The personal blog of Andrey Markelov (Андрей Маркелов) about Linux and Cloud computing.
20 декабря 2015
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
Подписаться на:
Сообщения (Atom)