Показаны сообщения с ярлыком OpenStack. Показать все сообщения
Показаны сообщения с ярлыком OpenStack. Показать все сообщения

09 мая 2018

Предзаказ 4-го издания книги по OpenStack

Открыт предзаказ на четвертое издание моей книги по OpenStack. В 4-е издание добавлен материал по работе с сетью, настройками производительности и отказоустойчивости. В связи с переходом на сервис Gnocchi переработана глава, посвященная сервису телеметрии.

Ниже приведены некоторые изменения четвертого издания, по сравнению с третьим:
  • Обновлены главы, посвященные основным сервисам OpenStack, в соответствии с изменениями на начало 2018 года (версия Queens).
  • Добавлен материал в главах, посвященных работе с сетью, настройками производительности и отказоустойчивости.
  • Переработана глава, посвященная сервису телеметрии, в связи с переходом на сервис Gnocchi.
  • Примеры большинства команд обновлены с использованием клиента командной строки openstack.

16 марта 2018

Red Hat Certified Engineer in Red Hat OpenStack 10

I have received the results of EX310 Red Hat Certified Engineer in Red Hat OpenStack just now. I have upgraded my Red Hat Certified Architect Level to XI :) Exam was all about Networking & Foundations of NFV in OpenStack. Since my job role focus will shift from NVFi to another area, this exam was a good conclusion for the last two years of working with OpenStack :)

07 мая 2017

How to configure OpenStack TripleO Undercloud in virtual environment with the help of VBMC

This blog post describes the way to prepare a small lab in virtual environment intended for TripleO (Director) OpenStack deployment tool learning. This is a quick instruction. For deep understanding and command exploration use documentation

I used my home laptop with 16 Gb of memory and CentOS 7.3 on the top of it for the lab environment hardware and RHEL 7.3 and RHOPS 10 for virtual machines, but these instructions should be applicable for RDO OpenStack distribution with minor changes.

I created three virtual machines:
  • Undercloud VM with 8Gb of memory for Director;
  • Compute VM with 4Gb of memory for hypervisor;
  • Control VM with 6Gb of memory for all OpenStack services.
Director should work with managed VMs as they bare metal servers. Virtual BMC can be useful here. VirtualBMC is a small software that allows users to create a virtual BMC to manage a virtual machines using the IPMI protocol, similar to how real bare metal machines are managed.



You need to install VBMC on visualization host where all VMs will run. The easiest way is to use RPM provided by RDO repository:

# yum install -y https://www.rdoproject.org/repos/rdo-release.rpm
# yum install yum install python2-virtualbmc

Then you need to create BMCs for already existing VMs:

# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     OOO_Under                      running
 -     OOO_Compute                    shut off
 -     OOO_Control                    shut off

# vbmc add OOO_Compute --port 7001 --username admin --password openstack
# vbmc add OOO_Control --port 7002 --username admin --password openstack
# vbmc start OOO_Control
# 2017-05-07 13:10:11,080.080 5501 INFO VirtualBMC [-] Virtual BMC for domain OOO_Control started
# vbmc start OOO_Compute
# 2017-05-07 13:10:18,304.304 5509 INFO VirtualBMC [-] Virtual BMC for domain OOO_Compute started

In this example you created and started BMCs that will be available on 7001 and 7002 ports of visualization host. For both of them password is openstack and user name is admin.

You can see the list of running BMCs:
# vbmc list
+-------------+---------+---------+------+
| Domain name |  Status | Address | Port |
+-------------+---------+---------+------+
| OOO_Compute | running |    ::   | 7001 |
| OOO_Control | running |    ::   | 7002 |
+-------------+---------+---------+------+

Next, you need to allow access to BMCs from outside including Director VM. CentOS uses firewalld by default:

# firewall-cmd --zone=public --add-port=7001/udp --permanent
# firewall-cmd --zone=public --add-port=7002/udp --permanent
# firewall-cmd --reload

Now you can test VBMC from Director VM. You can try to power on VMs or check the power status. By default visualization host should be accessible on IP adders 192.168.122.1. For compute VM:

[root@ooounder ~]# ipmitool -I lanplus -U admin -P openstack -H 192.168.122.1 -p 7001 power on
Chassis Power Control: Up/On
[root@ooounder ~]# ipmitool -I lanplus -U admin -P openstack -H 192.168.122.1 -p 7001 power status
Chassis Power is on

The same should work for the control VM with the only exception of port 7002. The rest part of the  installation of Undercloud VM should be done in accordance with the documentation.

Add required repos and update OS:

[root@ooounder ~]# subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpms --enable=rhel-7-server-openstack-10-rpms
[root@ooounder ~]# yum -y update
[root@ooounder ~]# init 6

Use the following commands to create the user named stack and set a password:

[root@ooounder ~]# useradd stack
[root@ooounder ~]# passwd stack

Disable password requirements for this user when using sudo:

[root@ooounder ~]# echo "stack ALL=(root) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/stack
stack ALL=(root) NOPASSWD:ALL
[root@ooounder ~]# chmod 0440 /etc/sudoers.d/stack

The director also requires an entry for the system’s hostname and base name in /etc/hosts:

127.0.0.1   ooounder ooounder.test.local localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

Use the following command to install the director. Then switch to stack user:
[root@ooounder ~]# yum install -y python-tripleoclient
[root@ooounder ~]# su - stack

Next, you should prepare basic template undercloud.conf  to help determine the required settings for your installation. You can use documentation and helpful tool https://github.com/cybertron/ucw. Here is my example for the lab:

[stack@ooounder ~]$ grep -o '^[^#]*' undercloud.conf
[DEFAULT]
undercloud_hostname = ooounder.test.local
local_ip = 192.168.24.1/24
network_gateway = 192.168.24.1
undercloud_public_host = 192.168.24.2
undercloud_admin_host = 192.168.24.3
undercloud_service_certificate =
generate_service_certificate = True
local_interface = eth1
local_mtu = 1500
network_cidr = 192.168.24.0/24
masquerade_network = 192.168.24.0/24
dhcp_start = 192.168.24.4
dhcp_end = 192.168.24.15
inspection_iprange = 192.168.24.16,192.168.24.17
scheduler_max_attempts = 10
[auth]

Run the following command:

[stack@ooounder ~]$ openstack undercloud install

At the end, you should get:

#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################


To initialize the stack user to use the command line tools, run the following command:

[stack@ooounder ~]$ source stackrc

The director requires several disk images for provisioning overcloud nodes. Obtain these images and import into the director:

[stack@ooounder ~]$ mkdir ~/images
[stack@ooounder ~]$ sudo yum install rhosp-director-images rhosp-director-images-ipa
[stack@ooounder ~]$ cd ~/images
[stack@ooounder ~]$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-10.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-10.0.tar; do tar -xvf $i; done
[stack@ooounder ~]$ openstack overcloud image upload --image-path /home/stack/images/

Check a list of the images in the CLI:

[stack@ooounder ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| 1c8325f3-e13b-454d-ae1d-119bd8656013 | bm-deploy-ramdisk      | active |
| da47e44f-6b59-49ef-8373-9e4e88bf2b46 | bm-deploy-kernel       | active |
| 0150b142-16aa-41e0-b1eb-808e6d070c15 | overcloud-full         | active |
| bd4f8a2d-9e05-4546-8a7d-654d7eea3c62 | overcloud-full-initrd  | active |
| aa2a737a-727e-4891-bb0e-0c9d8493fe49 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+

Overcloud nodes require a nameserver. Find the ID of subnet and update DNS server:

[stack@ooounder ~]$ neutron subnet-list
+--------------------------------------+------+-----------------+---------------------------------------------------+
| id                                   | name | cidr            | allocation_pools                                  |
+--------------------------------------+------+-----------------+---------------------------------------------------+
| 50f5a202-3c87-4f3c-b57f-3e3ca086be1c |      | 192.168.24.0/24 | {"start": "192.168.24.4", "end": "192.168.24.15"} |
+--------------------------------------+------+-----------------+---------------------------------------------------+
[stack@ooounder ~]$ neutron subnet-update 50f5a202-3c87-4f3c-b57f-3e3ca086be1c --dns-nameservers list=true 8.8.8.8
Updated subnet: 50f5a202-3c87-4f3c-b57f-3e3ca086be1c


The director requires a node definition template, which you create manually. This file contains the hardware and power management details for your nodes. I have two nodes with known IPMI details. Also you need to add MAC addresses of VMs NIC for PXE booting.
Here is my example:

[stack@ooounder ~]$ cat instackenv.json
{
    "nodes":[
        {
            "mac":[
                "52:54:00:d6:b4:bb"
            ],
            "cpu":"2",
            "memory":"4096",
            "disk":"100",
            "arch":"x86_64",
            "name":"compute",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"openstack",
            "pm_addr":"192.168.122.1",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:63:d8:a9"
            ],
            "cpu":"2",
            "memory":"4096",
            "disk":"100",
            "arch":"x86_64",
            "name":"controller",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"openstack",
            "pm_addr":"192.168.122.1",
            "pm_port":"7002"
        }
    ]
}

Import it into the director using the following command:

[stack@ooounder ~]$ openstack baremetal import --json ~/instackenv.json
Started Mistral Workflow. Execution ID: c3370562-1121-4d50-89ea-1b09f6f4058f
Successfully registered node UUID 6b56c6f5-c1d8-40a3-8d38-597fac9a1425
Successfully registered node UUID f6d78cf5-0308-45e9-b2ca-e109f0667bc6
Started Mistral Workflow. Execution ID: 59827dfa-dfaa-4bbd-ad0a-abc30a96de95
Successfully set all nodes to available.

Assign the kernel and ramdisk images to all nodes:
[stack@ooounder ~]$ openstack baremetal configure boot

The nodes are now registered and configured in the director. View a list of these nodes in the CLI:

[stack@ooounder ~]$ openstack baremetal node list
+--------------------------------------+------------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name       | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+------------+---------------+-------------+--------------------+-------------+
| 6b56c6f5-c1d8-40a3-8d38-597fac9a1425 | compute    | None          | power off   | available          | False       |
| f6d78cf5-0308-45e9-b2ca-e109f0667bc6 | controller | None          | power off   | available          | False       |
+--------------------------------------+------------+---------------+-------------+--------------------+-------------+


Set all nodes to a managed state:

[stack@ooounder ~]$ for node in $(openstack baremetal node list -c UUID -f value) ; do openstack baremetal node manage $node ; done

Run the following commands one by one to inspect the hardware attributes of each node:

[stack@ooounder ~]$  openstack overcloud node introspect | 6b56c6f5-c1d8-40a3-8d38-597fac9a1425 --provide
[stack@ooounder ~]$  openstack overcloud node introspect f6d78cf5-0308-45e9-b2ca-e109f0667bc6 --provide

This process causes each node to boot an introspection agent over PXE. This agent collects hardware data from the node and sends it back to the director.

After registering and inspecting the hardware of each node, you will tag them into specific profiles. These profile tags match your nodes to flavors, and in turn the flavors are assigned to a deployment role:
[stack@ooounder ~]$ ironic node-update compute add properties/capabilities='profile:compute,boot_option:local'
+------------------------+-------------------------------------------------------------------------+
| Property               | Value                                                                   |
+------------------------+-------------------------------------------------------------------------+
| chassis_uuid           |                                                                         |
| clean_step             | {}                                                                      |
| console_enabled        | False                                                                   |
| created_at             | 2017-05-07T11:16:37+00:00                                               |
| driver                 | pxe_ipmitool                                                            |
| driver_info            | {u'ipmi_port': u'7001', u'ipmi_username': u'admin', u'deploy_kernel': u |
|                        | 'da47e44f-6b59-49ef-8373-9e4e88bf2b46', u'ipmi_address':                |
|                        | u'192.168.122.1', u'deploy_ramdisk': u'1c8325f3-e13b-454d-ae1d-         |
|                        | 119bd8656013', u'ipmi_password': u'******'}                             |
| driver_internal_info   | {}                                                                      |
| extra                  | {u'hardware_swift_object': u'extra_hardware-                            |
|                        | 6b56c6f5-c1d8-40a3-8d38-597fac9a1425'}                                  |
| inspection_finished_at | None                                                                    |
| inspection_started_at  | None                                                                    |
| instance_info          | {}                                                                      |
| instance_uuid          | None                                                                    |
| last_error             | None                                                                    |
| maintenance            | False                                                                   |
| maintenance_reason     | None                                                                    |
| name                   | compute                                                                 |
| network_interface      |                                                                         |
| power_state            | power off                                                               |
| properties             | {u'memory_mb': u'4096', u'cpu_arch': u'x86_64', u'local_gb': u'199',    |
|                        | u'cpus': u'2', u'capabilities': u'profile:compute,boot_option:local'}   |
| provision_state        | available                                                               |
| provision_updated_at   | 2017-05-07T12:40:07+00:00                                               |
| raid_config            |                                                                         |
| reservation            | None                                                                    |
| resource_class         |                                                                         |
| target_power_state     | None                                                                    |
| target_provision_state | None                                                                    |
| target_raid_config     |                                                                         |
| updated_at             | 2017-05-07T12:40:14+00:00                                               |
| uuid                   | 6b56c6f5-c1d8-40a3-8d38-597fac9a1425                                    |
+------------------------+-------------------------------------------------------------------------+
[stack@ooounder ~]$ ironic node-update controller add properties/capabilities='profile:control,boot_option:local'
+------------------------+-------------------------------------------------------------------------+
| Property               | Value                                                                   |
+------------------------+-------------------------------------------------------------------------+
| chassis_uuid           |                                                                         |
| clean_step             | {}                                                                      |
| console_enabled        | False                                                                   |
| created_at             | 2017-05-07T11:16:37+00:00                                               |
| driver                 | pxe_ipmitool                                                            |
| driver_info            | {u'ipmi_port': u'7002', u'ipmi_username': u'admin', u'deploy_kernel': u |
|                        | 'da47e44f-6b59-49ef-8373-9e4e88bf2b46', u'ipmi_address':                |
|                        | u'192.168.122.1', u'deploy_ramdisk': u'1c8325f3-e13b-454d-ae1d-         |
|                        | 119bd8656013', u'ipmi_password': u'******'}                             |
| driver_internal_info   | {}                                                                      |
| extra                  | {u'hardware_swift_object': u'extra_hardware-f6d78cf5-0308-45e9-b2ca-    |
|                        | e109f0667bc6'}                                                          |
| inspection_finished_at | None                                                                    |
| inspection_started_at  | None                                                                    |
| instance_info          | {}                                                                      |
| instance_uuid          | None                                                                    |
| last_error             | None                                                                    |
| maintenance            | False                                                                   |
| maintenance_reason     | None                                                                    |
| name                   | controller                                                              |
| network_interface      |                                                                         |
| power_state            | power off                                                               |
| properties             | {u'memory_mb': u'4096', u'cpu_arch': u'x86_64', u'local_gb': u'199',    |
|                        | u'cpus': u'2', u'capabilities': u'profile:control,boot_option:local'}   |
| provision_state        | available                                                               |
| provision_updated_at   | 2017-05-07T12:42:55+00:00                                               |
| raid_config            |                                                                         |
| reservation            | None                                                                    |
| resource_class         |                                                                         |
| target_power_state     | None                                                                    |
| target_provision_state | None                                                                    |
| target_raid_config     |                                                                         |
| updated_at             | 2017-05-07T12:43:01+00:00                                               |
| uuid                   | f6d78cf5-0308-45e9-b2ca-e109f0667bc6                                    |
+------------------------+-------------------------------------------------------------------------+

Now everything is ready to start the configuration and installation of overcloud.

26 августа 2016

Экзамен по Red Hat OpenStack в УЦ Инвента в сентябре

Коллеги, 24 сентября, в субботу провожу в Москве в УЦ Инвента экзамен EX210 Red Hat Certified System Adminstrator in OpenStack. Описание - тут. Регистрация на сайте Инвенты - тут.

12 августа 2016

Книга по подготовке к экзамену Certified OpenStack Administrator доступна для предзаказа


Моя новая книга над которой я работал последние пол-года доступна для предварительного заказа на сайте издательства Apress.com. По плану она выходит 30 ноября 2016 года. Книга поможет подготовиться к экзамену Certified OpenStack Administrator от OpenStack Foundation. Также будет не бесполезна при подготовке к сертификации от Mirantis. Полное описание книги и оглавление - на сайте издательства.

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.

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

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-packages/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-*/examples. Используем самый простейший, в котором определяется только путь к дистрибутиву и пароль пользователя 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.img
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-scripts/ifcfg-*.
• Необходимо удалить SSH-ключи хоста. Удалите /etc/ssh/ssh_host_* и /etc/ssh/moduli.
• Удалите файлы ls /etc/udev/rules.d/*persistent*, отвечающие за именование сетевых устройств.
• Убедитесь, что отсутствуют специфичные для сервисов keytab-файлы Kerberos и SSL- сертификаты.
Все это за вас может проделать утилита virt-sysprep. Для примера с нашей виртуальной машины запустим команду:

# virt-sysprep --add /var/lib/libvirt/images/CentOS-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.