Зачастую перед администратором встает задача отладки приложений в вашей виртуальной сети 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
18 ноября 2015
Статья по архитектуре SDS Ceph
В ноябрьском номере журнала "Системный администратор" вышла моя первая статья из цикла о программно-определяемой системе хранения данных для OpenStack - Ceph.
02 ноября 2015
Особенности OpenStack для NFV и Telco
Рассказываю про особенности OpenStack для NFV и Telco 24 ноября в Москве на RISS http://www.pcweek.ru/its/riss/ и 28 ноября в Питере на Piter United http://piter-united.ru. Приходите кому интересно.
30 сентября 2015
Подготовка образов для OpenStack при помощи Oz
В составе официальной документации OpenStack работе с образами посвящено отдельное руководство – OpenStack Virtual Machine Image Guide. Документ содержит как обзор средств автоматизированного создания образов, так и примеры их создания вручную.
В качестве примера рассмотрим работу с утилитой Oz.
Это утилита командной строки написана на Python и на Linux-машине с гипервизором KVM и сервисом libvirtd позволяет создавать образы виртуальных машин с минимальным вмешательством пользователя. Для этого Oz использует заранее подготовленные файлы ответов не интерактивной установки операционной системы. Например, для установки Windows используются файлы ответов unattended setup, для CentOS – kickstart-файлы и так далее. Файлы ответов для различных операционных систем расположены в директории /usr/lib/python2.7/site-p ackages/oz/auto/. Их можно и нужно редактировать, например для выбора правильной временной зоны. В качестве инструкций сам Oz требует файлы в формате Template Description Language (TDL). Это XML-файлы, описывающие какая операционная система устанавливается, где находится дистрибутив, какие дополнительные изменения необходимо внести в образ.
Не рекомендуется запуск утилиты на тех же хостах, где развернуты сервисы OpenStack. Во время работы утилита запускает виртуальную машину в которой и производится установка операционной системы по вашим инструкциям TDL шаблона с использованием общих файлов ответов.
В CentOS и Fedora установка утилиты производится командой:
# yum -y install oz
Для Ubuntu в стандартных репозиториях пакета нет, поэтому вам нужно либо установить утилиту из исходных кодов, либо самостоятельно собрать пакет. Убедимся в том, что определе-на сеть libvirtd, используемая по умолчанию. Если вывод команды virsh net-list не покажет нам сеть default, то определим ее и зададим автозапуск сети:
# virsh net-define /usr/share/libvirt/networ ks/default.xml
Network default defined from /usr/share/libvirt/networ ks/default.xml
# virsh net-autostart default
Network default marked as autostarted
# virsh net-list
Name State Autostart Persistent
------------------------- ------------------------- --------
default active yes yes
Конфигурационный файл утилиты по умолчанию -/etc/oz/oz.cfg. Зададим в качестве типа образа формат qcow2 вместо raw:
# crudini --set /etc/oz/oz.cfg libvirt image_type qcow2
Теперь нам потребуется TDL-шаблон. Примеры поставляются с утилитой и располагают-ся в /usr/share/doc/oz-*/examp les. Используем самый простейший, в котором определяется только путь к дистрибутиву и пароль пользователя root:
$ cat my-template.tdl
Из полезных секций, которые можно найти в примерах можно отметить: packages, repositories, files и commands. Соответственно: установка пакетов, добавление репозиториев, создание файлов и выполнение команд. Есть секции специфичные для операционных систем. В качестве примера можно назвать ключи активации для Windows.
Запускаем утилиту:
# oz-install -d 2 -t 4000 my-template.tdl
Libvirt network without a forward element, skipping
Checking for guest conflicts with CentOS-7
Fetching the original media
Fetching the original install media from http://centos-mirror.rbc. ru/pub/centos/7/os/x86_64 /images/pxeboot/vmlinuz
Fetching the original media
Fetching the original install media from http://centos-mirror.rbc. ru/pub/centos/7/os/x86_64 /images/pxeboot/initrd.im g
Generating 20GB diskimage for CentOS-7
Running install for CentOS-7
Generate XML for guest CentOS-7 with bootdev None
Install of CentOS-7 succeeded
Generate XML for guest CentOS-7 with bootdev hd
Cleaning up after install
Libvirt XML was written to CentOS-7Sep_30_2015-00:31 :23
Ключ -t 3000 говорит о том, через сколько секунд инсталлятор должен прервать установку. Также установка прервется если в течение 300 секунд не было дисковой активности
Ключ -d показывает уровень сообщений об ошибках. Для более подробного вывода укажите вместо двойки тройку.
Далее, вне зависимости используете ли вы OZ или вы самостоятельно готовите образ виртуальной машины, например при помощи virt-builder из пакета libguestfs-tools, необходимо или вручную, или при помощи утилиты virt-sysprep из того же пакета убрать специфичную для конкретного экземпляра машины информацию.
Для разных операционных систем и дистрибутивов это делается по-разному. Например, для систем Windows можно воспользоваться утилитой sysprep. Приведем пример для CentOS:
• Необходимо удалить или заменить на localhost.localdomain содержимое параметра HOSTNAME в файле cat /etc/sysconfig/network.
• Необходимо убедиться, что в файлах всех сетевых адаптеров, кроме интерфейса короткой петли, в параметре BOOTPROTO указан DHCP и отсутствуют привязки к MAC-адресам (параметр HWADDR). Имена конфигурационных файлов – /etc/sysconfig/network-sc ripts/ifcfg-*.
• Необходимо удалить SSH-ключи хоста. Удалите /etc/ssh/ssh_host_* и /etc/ssh/moduli.
• Удалите файлы ls /etc/udev/rules.d/*persis tent*, отвечающие за именование сетевых устройств.
• Убедитесь, что отсутствуют специфичные для сервисов keytab-файлы Kerberos и SSL- сертификаты.
Все это за вас может проделать утилита virt-sysprep. Для примера с нашей виртуальной машины запустим команду:
# virt-sysprep --add /var/lib/libvirt/images/C entOS-7.qcow2
[ 0.0] Examining the guest ...
[ 102.0] Performing "abrt-data" ...
[ 102.0] Performing "bash-history" ...
…
[ 103.0] Setting a random seed
[ 104.0] Performing "lvm-uuids" ...
Посмотреть информацию про образ можно при помощи утилиты qemu-img (при необходимости установите пакет qemu-img):
$ qemu-img info /tmp/cirros-0.3.4-x86_64-
disk.img
image: /tmp/cirros-0.3.4-x86_64- disk.img
file format: qcow2
virtual size: 39M (41126400 bytes)
disk size: 13M
cluster_size: 65536
Format specific information:
compat: 0.10
В выводе команды:
• file format – формат диска;
• virtual size – размер диска виртуальной машины;
• disk size – действительный размер файла;
• cluster_size – размер блока (кластера) qcow;
• format specific information – специфичная для формата информация. В данном случае версия qcow.
В качестве примера рассмотрим работу с утилитой Oz.
Это утилита командной строки написана на Python и на Linux-машине с гипервизором KVM и сервисом libvirtd позволяет создавать образы виртуальных машин с минимальным вмешательством пользователя. Для этого Oz использует заранее подготовленные файлы ответов не интерактивной установки операционной системы. Например, для установки Windows используются файлы ответов unattended setup, для CentOS – kickstart-файлы и так далее. Файлы ответов для различных операционных систем расположены в директории /usr/lib/python2.7/site-p
Не рекомендуется запуск утилиты на тех же хостах, где развернуты сервисы OpenStack. Во время работы утилита запускает виртуальную машину в которой и производится установка операционной системы по вашим инструкциям TDL шаблона с использованием общих файлов ответов.
В CentOS и Fedora установка утилиты производится командой:
# yum -y install oz
Для Ubuntu в стандартных репозиториях пакета нет, поэтому вам нужно либо установить утилиту из исходных кодов, либо самостоятельно собрать пакет. Убедимся в том, что определе-на сеть libvirtd, используемая по умолчанию. Если вывод команды virsh net-list не покажет нам сеть default, то определим ее и зададим автозапуск сети:
# virsh net-define /usr/share/libvirt/networ
Network default defined from /usr/share/libvirt/networ
# virsh net-autostart default
Network default marked as autostarted
# virsh net-list
Name State Autostart Persistent
-------------------------
default active yes yes
Конфигурационный файл утилиты по умолчанию -/etc/oz/oz.cfg. Зададим в качестве типа образа формат qcow2 вместо raw:
# crudini --set /etc/oz/oz.cfg libvirt image_type qcow2
Теперь нам потребуется TDL-шаблон. Примеры поставляются с утилитой и располагают-ся в /usr/share/doc/oz-*/examp
$ cat my-template.tdl
Из полезных секций, которые можно найти в примерах можно отметить: packages, repositories, files и commands. Соответственно: установка пакетов, добавление репозиториев, создание файлов и выполнение команд. Есть секции специфичные для операционных систем. В качестве примера можно назвать ключи активации для Windows.
# oz-install -d 2 -t 4000 my-template.tdl
Libvirt network without a forward element, skipping
Checking for guest conflicts with CentOS-7
Fetching the original media
Fetching the original install media from http://centos-mirror.rbc.
Fetching the original media
Fetching the original install media from http://centos-mirror.rbc.
Generating 20GB diskimage for CentOS-7
Running install for CentOS-7
Generate XML for guest CentOS-7 with bootdev None
Install of CentOS-7 succeeded
Generate XML for guest CentOS-7 with bootdev hd
Cleaning up after install
Libvirt XML was written to CentOS-7Sep_30_2015-00:31
Ключ -t 3000 говорит о том, через сколько секунд инсталлятор должен прервать установку. Также установка прервется если в течение 300 секунд не было дисковой активности
Ключ -d показывает уровень сообщений об ошибках. Для более подробного вывода укажите вместо двойки тройку.
Далее, вне зависимости используете ли вы OZ или вы самостоятельно готовите образ виртуальной машины, например при помощи virt-builder из пакета libguestfs-tools, необходимо или вручную, или при помощи утилиты virt-sysprep из того же пакета убрать специфичную для конкретного экземпляра машины информацию.
Для разных операционных систем и дистрибутивов это делается по-разному. Например, для систем Windows можно воспользоваться утилитой sysprep. Приведем пример для CentOS:
• Необходимо удалить или заменить на localhost.localdomain содержимое параметра HOSTNAME в файле cat /etc/sysconfig/network.
• Необходимо убедиться, что в файлах всех сетевых адаптеров, кроме интерфейса короткой петли, в параметре BOOTPROTO указан DHCP и отсутствуют привязки к MAC-адресам (параметр HWADDR). Имена конфигурационных файлов – /etc/sysconfig/network-sc
• Необходимо удалить SSH-ключи хоста. Удалите /etc/ssh/ssh_host_* и /etc/ssh/moduli.
• Удалите файлы ls /etc/udev/rules.d/*persis
• Убедитесь, что отсутствуют специфичные для сервисов keytab-файлы Kerberos и SSL- сертификаты.
Все это за вас может проделать утилита virt-sysprep. Для примера с нашей виртуальной машины запустим команду:
# virt-sysprep --add /var/lib/libvirt/images/C
[ 0.0] Examining the guest ...
[ 102.0] Performing "abrt-data" ...
[ 102.0] Performing "bash-history" ...
…
[ 103.0] Setting a random seed
[ 104.0] Performing "lvm-uuids" ...
Посмотреть информацию про образ можно при помощи утилиты qemu-img (при необходимости установите пакет qemu-img):
$ qemu-img info /tmp/cirros-0.3.4-x86_64-
disk.img
image: /tmp/cirros-0.3.4-x86_64-
file format: qcow2
virtual size: 39M (41126400 bytes)
disk size: 13M
cluster_size: 65536
Format specific information:
compat: 0.10
В выводе команды:
• file format – формат диска;
• virtual size – размер диска виртуальной машины;
• disk size – действительный размер файла;
• cluster_size – размер блока (кластера) qcow;
• format specific information – специфичная для формата информация. В данном случае версия qcow.
08 августа 2015
Очередная статья в "Системном администраторе"
My fourth article on OpenStack was published in Russian magazine Samag 7-8/15 (p. 14-17). Read the full in paper.
Вышла моя четвертая статья цикла посвященного OpenStack в ж-ле "Системный администратор" 7-8/2015. Полная версия в печатном номере. http://samag.ru/archive/article/2982
02 августа 2015
Авторизованный курс и экзамен по Red Hat OpenStack в УЦ Инвента
Коллеги, 31 августа - 4 сентября читаю в УЦ Инвента (Москва) курс по RHELOSP 6 и провожу экзамен Red Hat Certified System Adminstrator in OpenStack. Курс и экзамен проводятся в первый раз в России. С учетом курса и летней акции учебного центра - стоит это в три раза дешевле чем в Фарнборо. Подробности - на сайте учебного центра http://rhd.ru/training/offers.html (курс в конце списка). Содержание курса там-же по ссылкам.
16 июля 2015
Моя книга вышла!
Презентация состоится на конференции "День рождения OpenStack" 22 июля. Программа мероприятия - http://openstack.ru/blog/s-dnem-rozhdeniya-openstack/
07 июля 2015
Update по книге OpenStack
Издательство ДМК-Пресс сообщило что на мою книгу по OpenStack очень большое число предзаказов. Сопоставимое было только у одной из книг по администрированию VMware. Презентация книги будет на конференции "День рождения OpenStack" 22 июля. Регистрация на конференцию - http://www.openstackday.ru/birthday2015/ Подробнее о книге - http://markelov.blogspot.ru/p/openstack.html
30 июня 2015
Предзаказ моей книги по OpenStack
Друзья, Рукопись сдана и результат моих трехмесячных трудов - книга по OpenStack доступна для предзаказа на сайте издательства. Постоянная ссылка на информацию по книге в моем блоге и ссылка на предзаказ - тут
.
.
23 июня 2015
Выделение вычислительных ресурсов для OpenStack
Говоря о
ресурсах, нужно заметить что OpenStack
позволяет подтверждать виртуальным
машинам больше физической памяти и
вычислительных ресурсов, чем имеется
в наличии. По умолчанию планировщик
ассоциирует с одним физическим или
«гипертрейдинговым» ядром 16 виртуальных
процессоров (vCPU). Объем памяти, выделяемой
виртуальным машинам по умолчанию в
полтора раза больше, чем имеющийся
физический. За эти значения в
конфигурационном файле /etc/nova/nova.conf
отвечают параметры:
cpu_allocation_ratio=16.0
ram_allocation_ratio=1.5
В целом, по
рекомендациям в списках рассылки
OpenStack для памяти выбирают значение 0.9.
Также рекомендуется задать резервирование
оперативной памяти при помощи параметра
reserved_host_memory_mb в nova.conf. Обычно в расчетах
можно руководствоваться закладывая на
накладные расходы порядка 100 Мб на одну
виртуальную машину. Обязательно нужно
предусмотреть swap, как минимум вдвое
больший чем этот параметр. Для процессора
коэффициент сильно зависит от нагрузки.
Обычно память становится раньше
«бутылочным горлышком», чем ресурсы
центрального процессора. Если запускается
много требовательных к ЦП приложений
типа Hadoop, то коэффициент выставляется
ближе к 2, а иногда и к 1. Если основная
нагрузка веб-сервера, то число можно
увеличить вплоть до 16 заданного по
умолчанию. Если вы не можете разделить
типы нагрузки, то можно попробовать
использовать коэффициент от 2 до 5.
Рекомендуется
по возможности ограничить в своем облаке
использование flavor (типы виртуальных
машин) с числом vCPU более одного. Для
гипервизоров первого типа намного проще
выделить ресурсы виртуальной машине с
1 vCPU. Например, для выделения вычислительных
ресурсов машине типа m1.xlarge планировщику
гипервизора необходимо будет ждать
пока не освободятся восемь физических
ядер центрального процессора.
Для целей
приблизительного «сайзинга» (определения
достаточных аппаратных требований)
можно воспользоваться калькулятором
от Mirantis —
https://www.mirantis.com/openstack-services/bom-calculator/.
Еще один калькулятор приводится в
руководстве по планированию архитектуры
OpenStack на официальном сайте OpenStack —
https://github.com/noslzzp/cloud-resource-calculator/blob/master/cloud-resource-calculator.ods.
Полезной
командами для сбора статистики по
использованию оперативной памяти будет
nova diagnostics. По умолчанию ее выполнять
может только пользователь admin. В качестве
аргумента команде необходим идентификатор
экземпляра виртуальной машины:
$ nova diagnostics 6aec269e-2633-4c56-9a61-7b8cb084995e
+---------------------------+-------------+
| Property | Value |
+---------------------------+-------------+
| cpu0_time | 34150000000 |
| memory | 307200 |
| memory-actual | 307200 |
| memory-rss | 127812 |
| tap6fc6b1e7-e7_rx | 10177 |
| tap6fc6b1e7-e7_rx_drop | 0 |
| tap6fc6b1e7-e7_rx_errors | 0 |
| tap6fc6b1e7-e7_rx_packets | 97 |
| tap6fc6b1e7-e7_tx | 11576 |
| tap6fc6b1e7-e7_tx_drop | 0 |
| tap6fc6b1e7-e7_tx_errors | 0 |
| tap6fc6b1e7-e7_tx_packets | 116 |
| vda_errors | -1 |
| vda_read | 17636864 |
| vda_read_req | 731 |
| vda_write | 324608 |
| vda_write_req | 98 |
+---------------------------+-------------+
Еще одна
полезная подкоманда virsh dommemstat которую
необходимо использовать непосредственно
на вычислительном узле. Для начала
необходимо узнать имя виртуальной
машины:
[root@os2 ~]# virsh list
Id Name State
----------------------------------------------------
2 instance-00000036 running
После чего
можно отдать непосредственно команду
virsh dommemstat:
[root@os2 ~]# virsh dommemstat instance-00000036
actual 307200
rss 127812
Также могу порекомендовать запись в моем
блоге о структурах памяти Linux, на которую я всегда ссылаюсь читая курс о настройке производительности в GNU/Linux (интересно, что это - самая популярная запись :) —
http://markelov.blogspot.ru/2009/01/linux-procmeminfo.html.
12 июня 2015
My third article on OpenStack Glance was published
My third article on
OpenStack Glance was published in Russian magazine Samag 6/15 (p.
12-14). Read the full in paper.
Вышла моя третья статья цикла посвященного
OpenStack в ж-ле "Системный администратор"
6/15. Полная версия в печатном номере.
08 июня 2015
Знакомство с простейшим HOT шаблоном сервиса оркестрации OpenStack
Службы Heat
позволяют автоматизировать управление
жизненным циклом наборов облачных
сервисов (виртуальными машинами, сетями,
томами, группами безопасности и т.д.)
как единым целым, объединяя их в так
называемые стеки (stack). Задачи могут быть
как простыми, например развертывание
виртуальной машины, таки и более сложными,
например старт комплексного приложения
из многих машин и его масштабирование
в зависимости от информации передаваемой
модулем телеметрии. Для описания стеков
используются специальные, одновременно
легко читаемые человеком и дружественные
к обработке машиной форматы описания
ресурсов, их ограничений, зависимостей
и параметров:
- HOT (Heat Orchestration Template) — формат предназначенный исключительно для OpenStack. Представляет собой документ формата YAML. Призван заменить собой CFN — шаблоны и именно с ним мы и будем работать.
- CFТ (AWS CloudFormation) — Документ формата JSON в формате совместимом с шаблонами сервиса CloudFormation (http://aws.amazon.com/ru/cloudformation/). Наличие возможности работать с этим типом форматов позволяет использовать множество уже существующих для AWS шаблонов.
1 heat_template_version: 2014-10-16
2 description: >
3 OpenStack. Практическое
знакомство с облачной операционной
системой.
4 Пример запуска одной ВМ
5
6 parameters:
7 network:
8 type: string
9 description: Сеть экземпляра ВМ
10 default: demo-net
11 image:
12 type: string
13 description: Образ для
запуска ВМ
14 default: cirros-0.3.3-x86_64
15
16 resources:
17 my_server:
18 type: OS::Nova::Server
19 properties:
20 flavor: m2.tiny
21 key_name: demokey1
22 networks:
23 - network: { get_param: network }
24 image: { get_param: image }
25 user_data: |
26 #!/bin/sh
27 echo "Instance STARTED!"
28 user_data_format: RAW
29
30 outputs:
31 instance_name:
32 description: Имя экземпляра ВМ
33 value: { get_attr: [my_server, name] }
34 private_ip:
35 description: IP-адрес ВМ в частной сети
36 value: { get_attr: [ my_server,first_address ] }
Данный шаблон является одной из многих вариаций «Hello, World!» для Heat. Создается стек состоящий из одной виртуальной машины, которой во время старта передается скрипт, выводящий сообщение «Instance STARTED!» на стандартный вывод. Прежде чем запустить стек, рассмотрим листинг.
Строки с первой по четвертую — это заголовок шаблона и описание. Дата в версии heat_template_version выберется не произвольно, а задается одним из следующих вариантов, соответствующих релизу OpenStack:
- 2013-05-23 — Icehouse
- 2014-10-16 — Juno
- 2015-03-30 — Kilo
Далее следуют три секции, первая из которых parameters начинается с шестой строки. В данной части шаблона определяются параметры network и image которые можно задать во время запуска стека. Оба параметра имеют тип — строка. У каждого из параметров есть значения по умолчанию, используемые если во время запуска стека их не задали — это строки десятая и четырнадцатая. В шаблоне мог также могла быть секция parameter_groups в которой задавалось бы как параметры должны быть сгруппированы и их порядок, но в этом шаблоне секция отсутствует.
Следующая секция resources которая описывает ресурсы шаблона. В этой секции должен быть описан как минимум один ресурс. В данном случае как раз и описан один ресурс с именем my_server типа OS::Nova::Server. В подсекции properties определены параметры сервера которые мы обычно задаем командой nova boot. Три из них, а именно размер виртуальной машины (flavor), имя открытого SSH-ключа и скрипт, который будет исполнен при старте при помощи cloud-init жестко заданны в теле шаблона. Еще два параметра, которые ранее были описаны в секции parameters подставляются при помощи функции get_param.
Наконец, третья секция outputs, которая также опциональна задает параметры которые будут выводится пользователю когда шаблон отработает в выводе heat stack-show или в интерфейсе Horizon.
Теперь когда мы разобрали шаблон, попробуем его запустить командой heat stack-create. Нам нужно указать путь к файлу шаблона и по желанию после опции -P параметры которые были определены в секции parameters. По желанию, потому что в шаблоне для них заданы значения по умолчанию.
$ source keystonerc_demo
$ heat stack-create -f test-server.yml -P network=demo-net teststack
+------+------------+--------------------+----------------------+
| id | stack_name | stack_status | creation_time |
+------+------------+--------------------+----------------------+
| 08.. | teststack | CREATE_IN_PROGRESS | 2015-06-06T20:03:19Z |
+------+------------+--------------------+----------------------+
При помощи следующей команды мы можем следить за процессом отработки стека, дождавшись пока статус не поменяется на CREATE_COMPLETE:
$ heat stack-list
+------+------------+-----------------+----------------------+
| id | stack_name | stack_status | creation_time |
+------+------------+-----------------+----------------------+
| 08.. | teststack | CREATE_COMPLETE | 2015-06-06T20:03:19Z |
+------+------------+-----------------+----------------------+
Проверим что у нас действительно была создана виртуальная машина. При этом обратите внимание что ее имя было сформировано из имени стека и имени ресурса:
$ nova list
+------+--------------------------+--------+------------+-------------+----------------------+
| ID | Name | Status | Task State | Power State | Networks |
+------+--------------------------+--------+------------+-------------+----------------------+
| f8.. | teststack-my_server-hv.. | ACTIVE | - | Running | demo-net=172.16.0.30 |
+------+--------------------------+--------+------------+-------------+----------------------+
Команда heat stack-show вместе с именем стека покажет его детали, включая параметры которые попросили вывести в секции outputs. Будут показаны имя экземпляра виртуальной машины и IP-адрес виртуальной машины в сети demo-net:
$ heat stack-show teststack
+----------------------+---------------------------------------------------+
| Property | Value |
+----------------------+---------------------------------------------------+
| capabilities | [] |
| creation_time | 2015-06-06T20:03:19Z |
| description | OpenStack. Практическое знакомство с облачной |
| | операционной системой. Пример запуска одной ВМ |
| disable_rollback | True |
| id | 08065001-1c81-4481-bc4f-0e7d2799f27c |
| links | http://os1.test.local:8004/v1/9c1c71f2c0f243b7a.. |
| notification_topics | [] |
| outputs | [ |
| | { |
| | "output_value": "teststack-my_server-hvio..", |
| | "description": "Имя экземпляра ВМ", |
| | "output_key": "instance_name" |
| | }, |
| | { |
| | "output_value": "172.16.0.30", |
| | "description": "IP-адрес ВМ в частной сети", |
| | "output_key": "private_ip" |
| | } |
| | ] |
| parameters | { |
| | "image": "cirros-0.3.3-x86_64", |
| | "OS::stack_id": "08065001-1c81-4481-bc4f-0e..", |
| | "OS::stack_name": "teststack", |
| | "network": "demo-net" |
| | } |
| parent | None |
| stack_name | teststack |
| stack_owner | demo |
| stack_status | CREATE_COMPLETE |
| stack_status_reason | Stack CREATE completed successfully |
| template_description | OpenStack. Практическое знакомство с облачной |
| | операционной системой. Пример запуска одной ВМ |
| timeout_mins | None |
| updated_time | None |
+----------------------+---------------------------------------------------+
Для того, чтобы убедится что скрипт, выводящий сообщение через cloud-init сработал можно либо подключится к консоли виртуальной машине в Horizon, либо ввести команду nova, которая показывает вывод консоли:
$ nova console-log teststack-my_server-hvio4ophfajb
03 июня 2015
Работа с OpenStack Telemetry (Ceilometer)
Сервис OpenStack Telemetry (Ceilometer) — компонент облака OpenStack, отвечающий за сбор, хранение метрик и мониторинг использования ресурсов в первую очередь для целей биллинга. Помимо сбора метрик работы облака Ceilometer также собирает информацию о событиях происходящих в работающей системе. Название сервиса Ceilometer происходит от названия прибора, используемого метеорологами для измерения высоты облаков над поверхностью земли.
Сервис спроектирован как расширяемый за счет подключаемых агентов сбора информации и легко маштабируемый горизонтально. Ceilometer поддерживает два способа сбора данных. Предпочтительный метод сбора при помощи очереди сообщений. Реализуется сервисом ceilometer-collector. Данный сервис запускается на одном или более управляющих узлах и отслеживает очередь сообщений. Сборщик получает уведомления от инфраструктурных сервисов (Nova, Glance, Cinder, Neutron, Swift, Keystone, Heat), затем преобразует их в сообщения телеметрии и отправляет обратно в очередь сообщений. Сообщения телеметрии записываются в хранилище без преобразований. Второй, менее предпочтительный способ - через опрашивающие инфраструктуру агенты. При помощи вызовов API или других инструментов агенты периодически запрашивают у сервисов необходимую информацию.
В веб-интерфейсе OpenStack за отображение информации Ceilometer отвечают две вкладки на странице Admin->System->Resource Usage (на рисунке). Намного больше возможностей предоставляет клиент командной строки ceilometer который использует RESTful API.
Попробуем запросить метрики телеметрии для которых уже есть записи в базе данных:
$ ceilometer meter-list
+---------------------+-------+----------+-------------+---------+------------+
| Name | Type | Unit | Resource ID | User ID | Project ID |
+---------------------+-------+----------+-------------+---------+------------+
| disk.ephemeral.size | gauge | GB | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| disk.root.size | gauge | GB | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| instance | gauge | instance | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| instance:m2.tiny | gauge | instance | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| memory | gauge | MB | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| vcpus | gauge | vcpu | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
+---------------------+-------+----------+-------------+---------+------------+
Нужно обратить внимание, что данная команда выведет данные, только если они были предварительно собраны, поэтому если вы запускаете команду ceilometer первый раз после установки сервиса, запустите при помощи nova boot хотя бы одну виртуальную машину. Ограничить вывод по конкретному ресурсу, например по определенному экземпляру виртуальной машины можно добавив опции --query resource=.
Можно также попробовать вывести все измерения для заданной метрики:
$ ceilometer sample-list -m instance
+-------------+----------+-------+--------+----------+----------------------------+
| Resource ID | Name | Type | Volume | Unit | Timestamp |
+-------------+----------+-------+--------+----------+----------------------------+
| 66746d4a-.. | instance | gauge | 1.0 | instance | 2015-05-31T18:51:36.981000 |
| 66746d4a-.. | instance | gauge | 1.0 | instance | 2015-05-31T18:51:23.358000 |
+-------------+----------+-------+--------+----------+----------------------------+
Или получить статистику, опять же в разрезе заданной метрики:
$ ceilometer statistics -m instance
+--------+--------------+-------------+-----+-----+-----+------+-------+----------+----------------+--------------+
| Period | Period Start | Period End | Max | Min | Avg | Sum | Count | Duration | Duration Start | Duration End |
+--------+--------------+-------------+-----+-----+-----+------+-------+----------+----------------+--------------+
| 0 | 2015-05-16.. | 2015-05-1.. | 1.0 | 1.0 | 1.0 | 46.0 | 46 | 1316727 | 2015-05-16T1.. | 2015-05-31.. |
+--------+--------------+-------------+-----+-----+-----+------+-------+----------+----------------+--------------+
Более сложные запросы можно создавать при помощи команды ceilometer query-samples используя опции --filter, --orderby и —limit.
Данные собранные сервисом ceilometer-collector также можно отправлять в различные внешние сервисы и системы при помощи механизма публикаций. За эти настройки отвечает файл pipeline.yaml, находящийся в директории /etc/ceilometer. Для дальнейших экспериментов поправим в этом файле периодичность снятия метрик по процессору с десяти минут до одной минуты. Соответствующая часть файла должна выглядеть:
- name: cpu_source
interval: 60
Попробуем познакомиться с триггерами или сигналами оповещения (alarms). Триггер может быть в трех состояниях: «Ok», «Тревога» и «Не достаточно данных». Правила триггеров могут объединяться при помощи операторов AND и OR. К триггеру можно привязать определенное правило, которое чаще всего HTTP-команда POST для заданного URL. Можно также в качестве действия выбрать запись в файл журнала, но это используется только для отладки, поскольку необходим доступ с правами администратора облака.
Попробуем создать простой триггер для виртуальной машины. Для начала запустим экземпляр:
$ source keystonerc_demo
$ nova boot --flavor m2.tiny --image cirros-0.3.3-x86_64 --key-name demokey1 --security-groups demo-sgroup mytest1
$ nova add-floating-ip mytest1 10.100.1.101
$ nova list
+-------+---------+--------+------------+-------------+-----------------------+
| ID | Name | Status | Task State | Power State | Networks |
+-------+---------+--------+------------+-------------+-----------------------+
| b99.. | mytest1 | ACTIVE | - | Running | demo-net=172.16.0.21, |
| | | | | | 10.100.1.101 |
+-------+---------+--------+------------+-------------+-----------------------+
В выводе последней команды нас интересует ID экземпляра (в таблице для экономии места первый столбец сокращен). Создадим триггер используя этот ID:
$ source keystonerc_admin
$ ceilometer alarm-threshold-create --name myalarm1 --meter-name cpu_util --threshold 60.0 --comparison-operator gt --statistic avg --period 60 --evaluation-periods 3 --alarm-action 'log://' --query resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de
+---------------------------+--------------------------------------+
| Property | Value |
+---------------------------+--------------------------------------+
| alarm_actions | [u'log://'] |
| alarm_id | c33000db-a4eb-41ea-9742-96e5d7b4d034 |
| comparison_operator | gt |
| description | Alarm when cpu_util is gt a avg of |
| | 60.0 over 60 seconds |
| enabled | True |
| evaluation_periods | 3 |
| exclude_outliers | False |
| insufficient_data_actions | [] |
| meter_name | cpu_util |
| name | myalarm1 |
| ok_actions | [] |
| period | 60 |
| project_id | |
| query | resource_id == b99e45af-95d2-436f-.. |
| repeat_actions | False |
| state | insufficient data |
| statistic | avg |
| threshold | 90.0 |
| type | threshold |
| user_id | 595c7da34b8e41bb812a0f3ecd6e7260 |
+---------------------------+--------------------------------------+
Мы создали триггер с именем myalarm1, который сработает если средняя загрузка процессора виртуальной машины превысит 60% для трех измерений подряд через каждые 60 секунд. Как видно из вывода команды, сразу после создания триггер находится в состоянии «недостаточно данных» (insufficient data). Подождем несколько минут и выполним команду:
$ ceilometer alarm-list
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| Alarm ID | Name | State | Enabled | Continuous | Alarm condition | Time constraints |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| c33000d.. | myalarm1 | ok | True | False | cpu_util > 60.0 during 3 x 60s | None |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
Состояние триггера изменилось на «Ok». Это значит, что данные собираются, но заданное условие не наступило. Проверим загрузку процессора:
$ ceilometer sample-list --meter cpu_util -q 'resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de'
+--------------------------------------+----------+-------+---------------+------+---------------------+
| Resource ID | Name | Type | Volume | Unit | Timestamp |
+--------------------------------------+----------+-------+---------------+------+---------------------+
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 10.868852459 | % | 2015-06-02T19:05:09 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 9.81632653061 | % | 2015-06-02T19:04:08 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 6.875 | % | 2015-06-02T19:03:19 |
+--------------------------------------+----------+-------+---------------+------+---------------------+
или суммарную статистику:
$ ceilometer statistics -m cpu_util -q 'resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de'
+--------+-------------+------------+-------+------+------+-------+-------+----------+---------------+--------------+
| Period | Period Start| Period End | Max | Min | Avg | Sum | Count | Duration | Duration Start| Duration End |
+--------+-------------+------------+-------+------+------+-------+-------+----------+---------------+--------------+
| 0 | 2015-06-02T1| 2015-06-02T| 14.35 | 6.87 | 11.9 | 250.6 | 21 | 1189.0 | 2015-06-02T19 | 2015-06-02T1 |
+--------+-------------+------------+-------+------+------+-------+-------+----------+---------------+--------------+
Действительно, значение около десяти процентов. Исправим это, подключившись к виртуальной машине:
$ ssh -i demokey1 cirros@10.100.1.101
$ md5sum /dev/zero
Проверим что команда md5sum действительно загрузила процессор более чем на шестьдесят процентов:
$ ceilometer sample-list --meter cpu_util -q 'resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de'
+--------------------------------------+----------+-------+---------------+------+---------------------+
| Resource ID | Name | Type | Volume | Unit | Timestamp |
+--------------------------------------+----------+-------+---------------+------+---------------------+
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 69.7666666667 | % | 2015-06-02T20:20:37 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 88.7627118644 | % | 2015-06-02T20:19:37 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 82.6 | % | 2015-06-02T20:18:38 |
+--------------------------------------+----------+-------+---------------+------+---------------------+
и триггер сработал:
$ ceilometer alarm-list
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| Alarm ID | Name | State | Enabled | Continuous | Alarm condition | Time constraints |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| c33000d.. | myalarm1 | alarm | True | False | cpu_util > 60.0 during 3 x 60s | None |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
При необходимости можно также обновить триггер, например задать границу срабатывания в 75 процентов:
$ ceilometer alarm-threshold-update --threshold 75.0 c33000db-a4eb-41ea-9742-96e5d7b4d034
Наконец, можно просмотреть историю по триггеру:
$ ceilometer alarm-history -a c33000db-a4eb-41ea-9742-96e5d7b4d034
+------------------+----------------------------+----------------------+
| Type | Timestamp | Detail |
+------------------+----------------------------+----------------------+
| rule change | 2015-06-.. | rule: cpu_util > 75.0 during 3 x 60s |
| state transition | 2015-06-.. | state: ok |
| state transition | 2015-06-.. | state: alarm |
| creation | 2015-06-.. | name: myalarm1 |
| | | description: Alarm when cpu_util is |
| | | gt a avg of 60.0 over 60 seconds |
| | | type: threshold |
| | | rule: cpu_util > 60.0 during 3 x 60s |
| | | time_constraints: None |
+------------------+----------------------------+----------------------+
Когда триггер нам больше не нужен, его можно удалить командой ceilometer alarm-delete.
Сервис спроектирован как расширяемый за счет подключаемых агентов сбора информации и легко маштабируемый горизонтально. Ceilometer поддерживает два способа сбора данных. Предпочтительный метод сбора при помощи очереди сообщений. Реализуется сервисом ceilometer-collector. Данный сервис запускается на одном или более управляющих узлах и отслеживает очередь сообщений. Сборщик получает уведомления от инфраструктурных сервисов (Nova, Glance, Cinder, Neutron, Swift, Keystone, Heat), затем преобразует их в сообщения телеметрии и отправляет обратно в очередь сообщений. Сообщения телеметрии записываются в хранилище без преобразований. Второй, менее предпочтительный способ - через опрашивающие инфраструктуру агенты. При помощи вызовов API или других инструментов агенты периодически запрашивают у сервисов необходимую информацию.
В веб-интерфейсе OpenStack за отображение информации Ceilometer отвечают две вкладки на странице Admin->System->Resource Usage (на рисунке). Намного больше возможностей предоставляет клиент командной строки ceilometer который использует RESTful API.
Попробуем запросить метрики телеметрии для которых уже есть записи в базе данных:
$ ceilometer meter-list
+---------------------+-------+----------+-------------+---------+------------+
| Name | Type | Unit | Resource ID | User ID | Project ID |
+---------------------+-------+----------+-------------+---------+------------+
| disk.ephemeral.size | gauge | GB | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| disk.root.size | gauge | GB | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| instance | gauge | instance | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| instance:m2.tiny | gauge | instance | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| memory | gauge | MB | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
| vcpus | gauge | vcpu | 66746d4a-.. | f3aab.. | 9c1c71f2.. |
+---------------------+-------+----------+-------------+---------+------------+
Нужно обратить внимание, что данная команда выведет данные, только если они были предварительно собраны, поэтому если вы запускаете команду ceilometer первый раз после установки сервиса, запустите при помощи nova boot хотя бы одну виртуальную машину. Ограничить вывод по конкретному ресурсу, например по определенному экземпляру виртуальной машины можно добавив опции --query resource=
Можно также попробовать вывести все измерения для заданной метрики:
$ ceilometer sample-list -m instance
+-------------+----------+-------+--------+----------+----------------------------+
| Resource ID | Name | Type | Volume | Unit | Timestamp |
+-------------+----------+-------+--------+----------+----------------------------+
| 66746d4a-.. | instance | gauge | 1.0 | instance | 2015-05-31T18:51:36.981000 |
| 66746d4a-.. | instance | gauge | 1.0 | instance | 2015-05-31T18:51:23.358000 |
+-------------+----------+-------+--------+----------+----------------------------+
Или получить статистику, опять же в разрезе заданной метрики:
$ ceilometer statistics -m instance
+--------+--------------+-------------+-----+-----+-----+------+-------+----------+----------------+--------------+
| Period | Period Start | Period End | Max | Min | Avg | Sum | Count | Duration | Duration Start | Duration End |
+--------+--------------+-------------+-----+-----+-----+------+-------+----------+----------------+--------------+
| 0 | 2015-05-16.. | 2015-05-1.. | 1.0 | 1.0 | 1.0 | 46.0 | 46 | 1316727 | 2015-05-16T1.. | 2015-05-31.. |
+--------+--------------+-------------+-----+-----+-----+------+-------+----------+----------------+--------------+
Более сложные запросы можно создавать при помощи команды ceilometer query-samples используя опции --filter, --orderby и —limit.
Данные собранные сервисом ceilometer-collector также можно отправлять в различные внешние сервисы и системы при помощи механизма публикаций. За эти настройки отвечает файл pipeline.yaml, находящийся в директории /etc/ceilometer. Для дальнейших экспериментов поправим в этом файле периодичность снятия метрик по процессору с десяти минут до одной минуты. Соответствующая часть файла должна выглядеть:
- name: cpu_source
interval: 60
Попробуем познакомиться с триггерами или сигналами оповещения (alarms). Триггер может быть в трех состояниях: «Ok», «Тревога» и «Не достаточно данных». Правила триггеров могут объединяться при помощи операторов AND и OR. К триггеру можно привязать определенное правило, которое чаще всего HTTP-команда POST для заданного URL. Можно также в качестве действия выбрать запись в файл журнала, но это используется только для отладки, поскольку необходим доступ с правами администратора облака.
Попробуем создать простой триггер для виртуальной машины. Для начала запустим экземпляр:
$ source keystonerc_demo
$ nova boot --flavor m2.tiny --image cirros-0.3.3-x86_64 --key-name demokey1 --security-groups demo-sgroup mytest1
$ nova add-floating-ip mytest1 10.100.1.101
$ nova list
+-------+---------+--------+------------+-------------+-----------------------+
| ID | Name | Status | Task State | Power State | Networks |
+-------+---------+--------+------------+-------------+-----------------------+
| b99.. | mytest1 | ACTIVE | - | Running | demo-net=172.16.0.21, |
| | | | | | 10.100.1.101 |
+-------+---------+--------+------------+-------------+-----------------------+
В выводе последней команды нас интересует ID экземпляра (в таблице для экономии места первый столбец сокращен). Создадим триггер используя этот ID:
$ source keystonerc_admin
$ ceilometer alarm-threshold-create --name myalarm1 --meter-name cpu_util --threshold 60.0 --comparison-operator gt --statistic avg --period 60 --evaluation-periods 3 --alarm-action 'log://' --query resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de
+---------------------------+--------------------------------------+
| Property | Value |
+---------------------------+--------------------------------------+
| alarm_actions | [u'log://'] |
| alarm_id | c33000db-a4eb-41ea-9742-96e5d7b4d034 |
| comparison_operator | gt |
| description | Alarm when cpu_util is gt a avg of |
| | 60.0 over 60 seconds |
| enabled | True |
| evaluation_periods | 3 |
| exclude_outliers | False |
| insufficient_data_actions | [] |
| meter_name | cpu_util |
| name | myalarm1 |
| ok_actions | [] |
| period | 60 |
| project_id | |
| query | resource_id == b99e45af-95d2-436f-.. |
| repeat_actions | False |
| state | insufficient data |
| statistic | avg |
| threshold | 90.0 |
| type | threshold |
| user_id | 595c7da34b8e41bb812a0f3ecd6e7260 |
+---------------------------+--------------------------------------+
Мы создали триггер с именем myalarm1, который сработает если средняя загрузка процессора виртуальной машины превысит 60% для трех измерений подряд через каждые 60 секунд. Как видно из вывода команды, сразу после создания триггер находится в состоянии «недостаточно данных» (insufficient data). Подождем несколько минут и выполним команду:
$ ceilometer alarm-list
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| Alarm ID | Name | State | Enabled | Continuous | Alarm condition | Time constraints |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| c33000d.. | myalarm1 | ok | True | False | cpu_util > 60.0 during 3 x 60s | None |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
Состояние триггера изменилось на «Ok». Это значит, что данные собираются, но заданное условие не наступило. Проверим загрузку процессора:
$ ceilometer sample-list --meter cpu_util -q 'resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de'
+--------------------------------------+----------+-------+---------------+------+---------------------+
| Resource ID | Name | Type | Volume | Unit | Timestamp |
+--------------------------------------+----------+-------+---------------+------+---------------------+
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 10.868852459 | % | 2015-06-02T19:05:09 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 9.81632653061 | % | 2015-06-02T19:04:08 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 6.875 | % | 2015-06-02T19:03:19 |
+--------------------------------------+----------+-------+---------------+------+---------------------+
или суммарную статистику:
$ ceilometer statistics -m cpu_util -q 'resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de'
+--------+-------------+------------+-------+------+------+-------+-------+----------+---------------+--------------+
| Period | Period Start| Period End | Max | Min | Avg | Sum | Count | Duration | Duration Start| Duration End |
+--------+-------------+------------+-------+------+------+-------+-------+----------+---------------+--------------+
| 0 | 2015-06-02T1| 2015-06-02T| 14.35 | 6.87 | 11.9 | 250.6 | 21 | 1189.0 | 2015-06-02T19 | 2015-06-02T1 |
+--------+-------------+------------+-------+------+------+-------+-------+----------+---------------+--------------+
Действительно, значение около десяти процентов. Исправим это, подключившись к виртуальной машине:
$ ssh -i demokey1 cirros@10.100.1.101
$ md5sum /dev/zero
Проверим что команда md5sum действительно загрузила процессор более чем на шестьдесят процентов:
$ ceilometer sample-list --meter cpu_util -q 'resource_id=b99e45af-95d2-436f-bfc6-64e5bfa999de'
+--------------------------------------+----------+-------+---------------+------+---------------------+
| Resource ID | Name | Type | Volume | Unit | Timestamp |
+--------------------------------------+----------+-------+---------------+------+---------------------+
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 69.7666666667 | % | 2015-06-02T20:20:37 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 88.7627118644 | % | 2015-06-02T20:19:37 |
| b99e45af-95d2-436f-bfc6-64e5bfa999de | cpu_util | gauge | 82.6 | % | 2015-06-02T20:18:38 |
+--------------------------------------+----------+-------+---------------+------+---------------------+
и триггер сработал:
$ ceilometer alarm-list
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| Alarm ID | Name | State | Enabled | Continuous | Alarm condition | Time constraints |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
| c33000d.. | myalarm1 | alarm | True | False | cpu_util > 60.0 during 3 x 60s | None |
+-----------+----------+-------+---------+------------+--------------------------------+------------------+
При необходимости можно также обновить триггер, например задать границу срабатывания в 75 процентов:
$ ceilometer alarm-threshold-update --threshold 75.0 c33000db-a4eb-41ea-9742-96e5d7b4d034
Наконец, можно просмотреть историю по триггеру:
$ ceilometer alarm-history -a c33000db-a4eb-41ea-9742-96e5d7b4d034
+------------------+----------------------------+----------------------+
| Type | Timestamp | Detail |
+------------------+----------------------------+----------------------+
| rule change | 2015-06-.. | rule: cpu_util > 75.0 during 3 x 60s |
| state transition | 2015-06-.. | state: ok |
| state transition | 2015-06-.. | state: alarm |
| creation | 2015-06-.. | name: myalarm1 |
| | | description: Alarm when cpu_util is |
| | | gt a avg of 60.0 over 60 seconds |
| | | type: threshold |
| | | rule: cpu_util > 60.0 during 3 x 60s |
| | | time_constraints: None |
+------------------+----------------------------+----------------------+
Когда триггер нам больше не нужен, его можно удалить командой ceilometer alarm-delete.
21 мая 2015
11 мая 2015
Настройка работы Docker и OpenStack
Первое с чего мы начнем —
это установка Docker и необходимых пакетов.
Обращаю внимание, что этот вариант
установки подходит только для тестовых
сред. Для «боевой установки» следует
собрать rpm-пакет с драйвером Docker и не
устанавливать на вычислительные узлы
средства, применяемые при разработке.
Действия выполняем на вычислительном
узле:
[root@os2 ~]# yum -y install net-tools docker-io python-pip git
Также обратите внимание на
то, что мы устанавливаем пакет net-tools,
который в современных дистрибутивах
при установке по умолчанию заменен на
iproute,а утилиты из его состава имеют
статус устаревших. Нам он понадобится
ради команды ifconfig, которая используется
драйвером Docker.
Теперь забираем с Github исходный код
драйвера и устанавливаем:[root@os2 ~]# git clone https://github.com/stackforge/nova-docker.git
[root@os2 ~]# cd nova-docker
[root@os2 nova-docker]# git checkout -b pre-i18n 9045ca43b645e72751099491bf5f4f9e4bddbb91
[root@os2 nova-docker]# python setup.py install
[root@os2 nova-docker]# pip install pbr
Команду git checkout мы выполняем
до обновления исходного кода, который
«ломает» совместимость с релизом
OpenStack Juno. Следующим шагом запускаем и включаем
сервис Docker и выполняем не очень «чистый»
обходной прием с правами, для того чтоб
в CentOS драйвер получил доступ к Docker:
[root@os2 ~]# systemctl start docker
[root@os2 ~]# systemctl enable docker
[root@os2 ~]# chmod 660 /var/run/docker.sock
Нам необходимо в соответствии
с инструкцией на Github настроить драйвер.
Создаем файл с инструкциями по настройки
сети для Docker:
[root@os2 ~]# mkdir /etc/nova/rootwrap.d
[root@os2 ~]# vi /etc/nova/rootwrap.d/docker.filters
и в файл docker.filters копируем
следующие содержимое:
#nova-rootwrap command filters for setting up network in the docker driver
# This file should be owned by (and only-writeable by) the root user
[Filters]
# nova/virt/docker/driver.py: 'ln', '-sf', '/var/run/netns/.*'
ln: CommandFilter, /bin/ln, root
Наконец на узле Glance добавляем к форматам
контейнеров docker:
[root@os1 ~]# crudini --set /etc/glance/glance-api.conf DEFAULT container_formats ami,ari,aki,bare,ovf,ova,docker
[root@os1 ~]# systemctl restart openstack-glance-api
А на вычислительном узле os2 в качестве драйвера указываем драйвер Docker. Других изменений производить не надо:
[root@os2 ]# crudini --set /etc/nova/nova.conf DEFAULT compute_driver novadocker.virt.docker.DockerDriver
[root@os2 ]# systemctl restart openstack-nova-compute
Теперь тестируем нашу
конфигурацию. Для начала ограничимся
работоспособностью контейнеров Docker.
Попробуем запустить контейнер с
дистрибутивом Fedora:
[root@os2 ~]# docker run -i -t fedora /bin/bash
Unable to find image 'fedora:latest' locally
Trying to pull repository docker.io/fedora ...
...
Status: Downloaded newer image for docker.io/fedora:latest
bash-4.3# cat /etc/redhat-release
Fedora release 21 (Twenty One)
Как мы видим, из репозитория docker.io был скачен последний образ Fedora и запущен. Если посмотреть на список контейнеров, мы также это уведем:
[root@os2 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
cb7b37a3a1b2 fedora:latest "/bin/bash" 9 minutes ago Up 9 minutes heisenberg
Теперь скачаем образ с
минимальным http-сервером thttpd, который
будем использовать для проверки работы:
[root@os2 ~]# docker pull larsks/thttpd
Trying to pull repository docker.io/larsks/thttpd ...
...
Status: Downloaded newer image for docker.io/larsks/thttpd:latest
После этого загрузим его в Glance:
[root@os2 ~]# source keystonerc_admin
[root@os2 ~]# docker save larsks/thttpd | glance image-create --is-public True --container-format docker --disk-format raw --name larsks/thttpd
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| checksum | c98dcd00b284eaf35ba8d10e1bff941c |
| container_format | docker |
| created_at | 2015-05-09T19:42:23 |
| deleted | False |
| deleted_at | None |
| disk_format | raw |
| id | 7133ae58-03aa-4d80-af98-adf5e1c02a5e |
| is_public | True |
| name | larsks/thttpd |
| owner | a5c42139ce154b4d945b4ed806cbee81 |
| protected | False |
| size | 1083392 |
| status | active |
| updated_at | 2015-05-09T19:42:25 |
| virtual_size | None |
+------------------+--------------------------------------+
Проверяем список образов:
[root@os2 ~]# glance image-list
+------+---------------------+-------------+------------------+----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
+------+---------------------+-------------+------------------+----------+--------+
| bc.. | cirros-0.3.3-x86_64 | qcow2 | bare | 13200896 | active |
| 71.. | larsks/thttpd | raw | docker | 1083392 | active |
+------+---------------------+-------------+------------------+----------+--------+
И в графическом интерфейсе Horizon:
Наконец, можно попробовать создать экземпляр контейнера:
$ source keystonerc_demo
$ nova boot --image larsks/thttpd --flavor m1.small test1
+--------------------------------------+-------------------------------------+
| Property | Value |
+--------------------------------------+-------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-STS:power_state | 0 |
| OS-EXT-STS:task_state | scheduling |
| OS-EXT-STS:vm_state | building |
| adminPass | Y6htpjH5xe2X |
| created | 2015-05-09T20:05:08Z |
| flavor | m1.small (2) |
| id | 65de57d0-f033-4818-a522-2c3291dc.. |
| image | larsks/thttpd (7133ae58-03aa-4d8..) |
| metadata | {} |
| name | test1 |
| os-extended-volumes:volumes_attached | [] |
| security_groups | default |
| status | BUILD |
| tenant_id | 9c1c71f2c0f243b7a3b1d0d1880820e9 |
| updated | 2015-05-09T20:05:08Z |
| user_id | f3aabe457c2c4fe5912a0f90e569e04d |
+--------------------------------------+-------------------------------------+
Проверяем, что контейнер запущен:
[root@os2 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4680097f2cc0 larsks/thttpd:latest "/thttpd -D -l /dev/ 13 minutes ago Up 13 minutes nova-65de57d0-f033-4818-a522-2c3291dc516bВ графическом интерфейсе это выглядит следующим образом:
Для доступа к http-серверу присвоим экземпляру внешний floating IP:
[root@os1 ~]# nova floating-ip-associate test1 10.100.1.101
Проверяем:
[root@os1 ~]# nova list
+------+-------+--------+------------+-------------+-----------------------+
| ID | Name | Status | Task State | Power State | Networks |
+------+-------+--------+------------+-------------+-----------------------+
| 65.. | test1 | ACTIVE | - | Running | demo-net=172.16.0.14, |
| | | | | | 10.100.1.101 |
+------+-------+--------+------------+-------------+-----------------------+
И из тестовой машины со внешней сети пробуем подключится к серверу:
$ curl http://10.100.1.101
____ _ _
_ _
/ ___|___ _ __ __ _ _ __ __ _| |_ _ _| |
__ _| |_(_) ___ _ __ ___
| | / _ \| '_ \ / _` | '__/ _` | __| | | | |/
_` | __| |/ _ \| '_ \/ __|
| |__| (_) | | | | (_| | | | (_| | |_| |_| | |
(_| | |_| | (_) | | | \__ \
\____\___/|_| |_|\__, |_|
\__,_|\__|\__,_|_|\__,_|\__|_|\___/|_| |_|___/
|___/
Все работает, можно наградить себя
чашечкой кофе.
Подписаться на:
Сообщения (Atom)