10 мая 2016

Quick info and tips for Certified OpenStack Administrator exam (COA)

In addition to Mirantis and Red Hat OpenStack certification I got Certified OpenStack Administrator from OpenStack Foundation yesterday. Now I am in process of writing Certified OpenStack Administrator Study Guide. It should be ready in November, I believe. This post is a short description and some tips for the exam.

Certified OpenStack Administrator (COA) is the first professional certification offered by the OpenStack Foundation. As OpenStack's web-site tells, it’s designed to help companies identify top talent in the industry, and help job seekers demonstrate their skills.
The COA certification is available to anyone who passes the exam. No mandatory learning is required. However, the Certified OpenStack Administrator is a professional typically with at least six months OpenStack experience. It is very important to gain practical skills of work with OpenStack before taking the exam. Practice, practice and practice is the only way to successfully reach the exam goals.

Quick facts about exam:

•    Duration is 2.5 hours.
•    Price is $300. One free retake per Exam purchase will be granted in the event that a passing score is not achieved.
•    Exam is performance-based. You may use graphical interface or command line.
•    Exam is vailable anywhere in the world through Internet.
•    Candidates are monitored virtually by a proctor during the exam session via streaming audio, video, and screensharing;



Tips for COA exam preparation

If you think you are ready for exam, you should start from reading "The OpenStack Foundation Certification Candidate Handbook for OpenStack Foundation Certified OpenStack Administrator (COA)". This guide is available from COA website - https://www.openstack.org/coa/. It contains all instructions and conditions that you need to know before exam. Some other tips are below.

It's very importent to test your PC for meeting minimal requirements at the exam provider's website. Pay attention to a screen resolution. At the moment of writing this post the minimum was set up to 1280x800. It is really a minimum value and it will be probably non comfort to work with exam consoles with this resolution. I would recommend you to use a monitor as big as it is possible.

Handbook tells you may launch http://docs.openstack.org/ to access technical documentation. Please find some time and investigate where to find information. You do not need to memorise everything, but it is good to know where and what documentation website contains.

It is probably better not to type long names of projects, volumes, directories, etc. but copy them from the exam task list to command line during the exam. You can avoid mistypes errors if you do so. Use Ctrl+Insert to copy and Shift+Insert to paste in Microsoft Windows operating systems. Shortcuts Ctrl+C and Ctrl+V are not supported in the exam terminal currently.

It is highly recommended to use one of terminal multiplexers because the exam terminal has a single console. You can use screen command or more advanced tmux. Take your time to practice with one of them.

09 апреля 2016

04 марта 2016

Доступен предзаказ 2го обновленного и расширенного издания книги о OpenStack.


Что нового во втором издании?

Текст книги обновлен, чтобы соответствовать актуальным версиям рассматриваемых проектов и компонент OpenStack по состоянию на начало 2016 года (версия Liberty), а объем книги увеличен более чем на треть. Некоторые изменения второго издания:

  • Исправлен ряд неточностей и опечаток первого издания вышедшего в июне 2015 года.
  • Добавлена глава, посвященная программно-определяемой системе хранения данных Ceph и использованию Ceph совместно с OpenStack.
  • Расширен и переработан материал по работе с виртуальными машинами и сетью (агрегация узлов, зоны доступности, живая миграция, создание образов виртуальных машин, работа с сетью и многое другое). С целью лучшей структуризации материал разбит на две отдельные главы.
  • При описании настройки тестового окружения разделены управляющий, сетевой и вычислительный узлы, что позволяет нагляднее познакомиться с типичными ролями серверов при развертывании OpenStack.
  • Значительно переработан материал по работе сети в OpenStack.
  • Вопросы производительности и отказоустойчивости сервисов OpenStack выделены в отдельную главу.
  • Добавлено более пятнадцати новых иллюстраций и снимков с экрана.

Предзаказ 2-го издания на сайте издательства

12 января 2016

Шифрование тома Cinder в OpenStack

Одной из полезных опций работы с блочными устройствами является их шифрование. Настройка шифрования томов требуется со стороны двух служб: Nova и Cinder. Сделать это можно при помощи общего секрета или при помощи сервиса управления ключами Barbican. Пойдем по пути использования общего секрета. Нужно иметь в виду, что если он скомпрометирован, то злоумышленник получит доступ ко всем зашифрованным томам.
Зададим ключ на узле Cinder и всех вычислительных узлах:

[root@compute ~]# crudini --set /etc/nova/nova.conf keymgr fixed_key 123456789
[root@compute ~]# systemctl restart openstack-nova-compute
[root@controller ~]# crudini --set /etc/cinder/cinder.conf keymgr fixed_key 123456789
[root@controller ~]# systemctl restart openstack-cinder-volume

Нам необходимо создать новый тип тома. Назовем его LUKS, поскольку для шифрования будет использоваться соответствующая спецификация:

$ source keystonerc_admin
$ cinder type-create LUKS
+--------------------------------------+------+-------------+-----------+
|                  ID                  | Name | Description | Is_Public |
+--------------------------------------+------+-------------+-----------+
| 7d5d38a3-ce84-4dfb-b184-74fed0309cef | LUKS |      -      |    True   |
+--------------------------------------+------+-------------+-----------+

Следующим шагом нужно создать тип шифрования:

$ cinder encryption-type-create --cipher aes-xts-plain64 --key_size 512 --control_location front-end LUKS nova.encryptors.luks.LuksEncryptor
+----------------+------------------------------------+-----------------+----------+------------------+
| Volume Type ID |              Provider              |      Cipher     | Key Size | Control Location |
+----------------+------------------------------------+-----------------+----------+------------------+
| 7d5d38a3-ce8.. | nova.encryptors.luks.LuksEncryptor | aes-xts-plain64 |   512    |    front-end     |
+----------------+------------------------------------+-----------------+----------+------------------+

Теперь у нас все готово для создания зашифрованного тома. Обратите внимание на свойство encrypted при выводе команды:

$ source keystonerc_demo 
$ cinder create --display-name myvolumeEncr --volume-type LUKS 1
+---------------------------------------+--------------------------------------+
|                Property               |                Value                 |
+---------------------------------------+--------------------------------------+
|              attachments              |                  []                  |
|           availability_zone           |                 nova                 |
|                bootable               |                false                 |
|          consistencygroup_id          |                 None                 |
|               created_at              |      2015-12-23T09:21:43.000000      |
|              description              |                 None                 |
|               encrypted               |                 True                 |
|                   id                  | 21cc946b-51ea-4806-adc1-46d42113af14 |
|                metadata               |                  {}                  |
|              multiattach              |                False                 |
|                  name                 |             myvolumeEncr             |
|      os-vol-tenant-attr:tenant_id     |   eca00feab38e4aa5b462bd31af0b9dca   |
|   os-volume-replication:driver_data   |                 None                 |
| os-volume-replication:extended_status |                 None                 |
|           replication_status          |               disabled               |
|                  size                 |                  1                   |
|              snapshot_id              |                 None                 |
|              source_volid             |                 None                 |
|                 status                |               creating               |
|                user_id                |   924c18c923654d7c930bcb1044580d8b   |
|              volume_type              |                 LUKS                 |
+---------------------------------------+--------------------------------------+


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