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
Описание опционально и если оно не помещается в одну строку, то как в примере разбивается на несколько строк в соответствии со спецификацией YAML.
    Далее следуют три секции, первая из которых 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.

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 


  ____                            _         _   
   _   _ 
 / ___|___  _ __   __ _ _ __ __ _| |_ _   _| |
__ _| |_(_) ___  _ __  ___
| |   / _ \| '_ \ / _` | '__/ _` | __| | | | |/
_` | __| |/ _ \| '_ \/ __|
| |__| (_) | | | | (_| | | | (_| | |_| |_| | |
(_| | |_| | (_) | | | \__ \
\____\___/|_| |_|\__, |_| 
\__,_|\__|\__,_|_|\__,_|\__|_|\___/|_| |_|___/
                  |___/ 

Все работает, можно наградить себя
чашечкой кофе.