ГЛАВА 10

Операции стороны пользователя

Данное руководство предназначено для операторов OpenStack и не преследует цель стать исчерпывающим справочником для пользователей, однако, оператору важно иметь общее представление о том, каким образом можно использовать облачные службы. В данной главе рассматривается OpenStack с точки зрения базового пользователя, что поможет вам понять потребности ваших пользователей и определить, когда вы получаете свидетельство о неприятности, является ли она проблемой пользователя или проблемой службы. Основные понятия охватывают образы, шаблоны виртуальных ресурсов (flavor), группы безопасности, блочные хранилища и экземпляры.

Образы

Образы OpenStack часто могут рассматриваться как "шаблоны виртуальных машин". Они также могут быть стандартными носителями для установки, такими как образы ISO. По существу, они содержат загружаемые файловые системы, которые используются для запуска экземпляров.

Добавление образов

Существуют некоторые предварительно собранные образы и они могут быть легко импортированы в службу образов (Image service). Образ CirrOS является очень маленьким общеупотребимым образом для добавления и используется для целей тестирования. Чтобы добавить этот образ, просто выполните:
# wget https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img
# glance image-create --name='cirros image' --is-public=true --container-format=bare --disk-format=qcow2 < cirros-0.3.0-x86_64-disk.img


Команда image-create glance предоставляет большой набор параметров для обеспечения вас образами. Например, параметр min-disk полезен для образов, которые требуют root диски определенного размера (например, большие образы Windows). Для ознакомления с этими параметрами выполните:
$ glance help image-create


Важно отметить параметр расположения (location). Он не копирует весь образ в Glance, а вместо этого дает ссылку на оригинальное местоположение, по которой может быть найден данный образ. После запуска экземпляра данного образа Glance получает образ из описанного местоположения.

Параметр copy-from копирует образ из описанного местоположения в каталог /var/lib/glance/images. То же самое выполняется при перенаправлении STDIN, как это демонстрируется в примере. Выполните следующую команду, чтобы посмотреть свойства существующих образов:
$ glance details


Удаление образов

Для удаления образа просто выполните:
$ glance image-delete <image uuid>


Удаление образа не влияет на экземпляры или моментальные снимки, которые основывались на нем.

Прочие параметры CLI

Полный набор опций можно найти с помощью:
$ glance help
или в руководстве по CLI службы образов OpenStack (OpenStack Image Service CLI Guide, http://docs.openstack.org/cli/quickstart/content/glance-cli-reference.html -- прим. перев. ссылка не работает, рекомендую взамен этой, по состоянию на на 19 сентября 2014: Image Service command-line client и glance commands)

Служба образов и базы данных

Единственное, что Glance не хранит в базе данных, это сами образы. База данных Glance имеет две основные таблицы:

• images (образы)
• image_properties (свойства образов)

Непосредственная работа с базой данных и выполнение SQL запросов может снабдить вас списками пользователей и сообщить об образах Glance. Технически, вы можете обновлять свойства об образах непосредственно через базу данных, хотя это и не рекомендуется.

Пример запросов к базе данных службы образов

Один интересный пример заключается в изменении таблицы образов и владельца этого образа. Это можно легко сделать, если вы просто отображаете уникальный идентификатор (ID) владельца, данный пример идет на шаг дальше и отображает читаемое имя владельца:
$ mysql> select glance.images.id, glance.images.name, keystone.tenant.name, is_public from glance.images inner join keystone.tenant on glance.images.owner=keystone.tenant.id;


Другой пример заключается в отображении всех свойств для определенного образа:
$ mysql> select name, value from image_properties where id = <image_id>


Шаблоны виртуального ресурса

Шаблоны виртуального оборудования в OpenStack называются "flavors" (особенностями), определяющими размеры оперативной памяти, дискового пространства, количества ядер и тому подобного. Установка по умолчанию обеспечивает диапазон из пяти шаблонов виртуальных ресурсов. Они настраиваются пользователями с правами администратора (что в свою очередь может быть делегировано путем переопределения управления доступом для compute_extension:flavormanage в /etc/nova/policy.json на сервере nova-api). Чтобы получить список доступных в вашей системе шаблонов выполните:
$ nova flavor-list
+----+-----------+-----------+------+-----------+\+-------+-\+-------------+
| ID | Name      | Memory_MB | Disk | Ephemeral |/| VCPUs | /| extra_specs |
+----+-----------+-----------+------+-----------+\+-------+-\+-------------+
| 1  | m1.tiny   | 512       | 1    | 0         |/| 1     | /| {}          |
| 2  | m1.small  | 2048      | 10   | 20        |\| 1     | \| {}          |
| 3  | m1.medium | 4096      | 10   | 40        |/| 2     | /| {}          |
| 4  | m1.large  | 8192      | 10   | 80        |\| 4     | \| {}          |
| 5  | m1.xlarge | 16384     | 10   | 160       |/| 8     | /| {}          |
+----+-----------+-----------+------+-----------+\+-------+-\+-------------+


Команда nova flavor-create позволяет авторизованным пользователям создавать новые шаблоны виртуальных ресурсов. Дополнительные команды работы с шаблонами виртуальных ресурсов могут быть отображены с помощью команды:
$ nova help | grep flavor.


Шаблоны виртуальных ресурсов определяют ряд элементов:

Графа	Описание
ID	Уникальный идентификатор в численном выражении.
Название	Описательное имя, например, xx.size_name, общеупотребимое, однако не обязательно, хотя некоторые инструменты сторонних производителей могут их использовать.
Memory_MB	размер оперативной памяти виртуальной машины в мегабайтах.
Disk	Размер виртуального корневого диска в гигабайтах. Это временный диск, в который копируется базовый образ. При загрузке с постоянного тома он не требуется. Размер "0" является специальным случаем, который использует для размера временного корневого тома собственный размер базового образа.
Ephemeral	Описывает размер вторичного временного диска данных. Это пустой, неформатированный диск и он существует только на время жизни экземпляра.
Swap	Не обязательное пространство свопинга выделяемое для покачки памяти экземпляром.
VCPUs	Количество виртуальных процессоров, предоставленных экземпляру.
RXTX_Factor	Опциональное свойство, позволяющее создаваемым серверам иметь предел пропускной способности, отличный от того, который определен в сети, к которым они подключены. Данный коэффициент умножается на свойство rxtx_base сети. Значением по умолчанию является 1.0 (т.е. то же что и у подключенной сети).
Is_Public	Булевское значение, определяющее доступен ли шаблон виртуального ресурса всем пользователям или он доступен только владельцу (tenant), который его создал. Значение по умолчанию True.
extra_specs	Дополнительные необязательные ограничения, с которыми могут работать шаблоны виртуальных ресурсов вычислительных узлов. Оно реализуется как пары ключ/ значение, которые должны сравниваться с соответствующими парами ключ/ значение в вычислительных узлах. Может быть использован для реализации сущностей, таких как специальные ресурсы (например, шаблоны виртуальных ресурсов, которые могут работать только на вычислительных узлах с аппаратными GPU).

Как мне изменить существующий шаблон виртуального ресурса?

К сожалению, OpenStack не обеспечивает интерфейс для изменения шаблонов виртуальных ресурсов, они ограничены только для созданием и удаления шаблонов. OpenStack Dashboard имитирует способность изменять шаблоны виртуальных ресурсов, путем удаления существующего шаблона и создания нового с тем же именем.

Группы безопасности

Один из наиболее распространенных вопросов начинающих работу с OpenStack пользователей является сбой установки соответствующей группы безопасности при запуске экземпляра с последующей невозможностью связи с экземпляром через сетевые средства. Группы безопасности являются наборами правил фильтрации IP, которые применяются к сетевым средствам экземпляра.

Они являются специфическими для проектов и, следовательно, члены проекта могут редактировать установленные по умолчанию правила для своей группы, а также добавлять новые множества правил. Все проекты имеют "установленную по умолчанию " группу безопасности, которая применяется к экземплярам, для которых не определена никакая другая группа безопасности, пока она не изменена, эта группыа безопасности отклоняет весь входящий трафик.

Параметр nova.conf allow_same_net_traffic (по умолчанию имеющий значение true) глобально управляет тем, применяются ли правила к совместно использующим сеть хостам. Будучи установленным в значение true (истинно), хосты из той же подсети не фильтруются и разрешены все типы обмена данными между ними. В однородной сети это разрешает нефильтруемое взаимодействие всем экземплярам всех проектов. При использовании сетевого окружения с виртуальными сетями это делает возможным взаимодействие между экземплярами в пределах одного проекта. Когда значение allow_same_net_trafficis установлено в false, ко всем соединениям применяются группы безопасности, в данном случае проекты могут имитировать allow_same_net_traffic путем настройки своих групп безопасности по умолчанию, разрешая весь трафик в своей подсети.

Группы безопасности для данного конкретного проекта могут быть найдены в инструментальной панели Horizon в разделе "Access & Security" для просмотра деталей текущей существующей группы выберите действие "edit" (редактирование) для данной группы безопасности. Понятно, что изменение существующих групп может быть выполнено из этого интерфейса "edit". Существует кнопка "Create Security Group" на главной странице Access & Security для создания новых групп. Мы обсудим используемые в этих полях термины по мере объяснения эквивалентов командной строки.

Вы можете получить список групп безопасности для определенного проекта, с которым вы работаете в настоящее время, выполнением команды nova в командной строке:
$ nova secgroup-list
+---------+-------------+
| Name    | Description |
+---------+-------------+
| default | default     |
| open    | all ports   |
+---------+-------------+


Для просмотра деталей группы безопасности "open":
$ nova secgroup-list-rules open
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| icmp        | -1        | 255     | 0.0.0.0/0 |              |
| tcp         | 1         | 65535   | 0.0.0.0/0 |              |
| udp         | 1         | 65535   | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+


Все приводимые правила являются правилами "разрешающего" (allow) типа, хотя по умолчанию установлены запрещающие (deny). Первый столбец является типом протокола IP (один из icmp, tcp или udp), второй и третий столбцы описывают подвергаемый действию диапазон портов. Четвертый столбец определяет диапазон IP в формате CIDR. Данный пример демонстрирует полный диапазон портов для всех протоколов, разрешаемых всем IP адресам.

Как отмечалось в предыдущей главе, число правил в группе безопасности управляется quota_security_group_rules, а количество разрешенных групп безопасности в проекте управляется квотой quota_security_groups.

При добавлении новой группы безопасности вы должны выбрать описательное, но краткое имя. Это имя появляется в кратких описаниях экземпляров, которые используют его там, где большие поля описания часто не доступны. Видя, что экземпляр использует группу безопасности "http", будет гораздо легче понять ее назначение, чем в случае ее именования "bobs_group" или "secgrp1".

В качестве примера, давайте создадим группу безопасности, которая позволяет веб-трафик повсеместно в интернете. Мы будем называть ее "global_http", что ясно и разумно кратко и при этом содержит информацию о том, что разрешено и откуда. В командной строке:
(Прим. перев.: в оригинале пропущена команда)
+-------------+-------------------------------------+
| Name        | Description                         |
+-------------+-------------------------------------+
| global_http | allow web traffic from the internet |
|             | (допускает обмен через интернет)    |
+-------------+-------------------------------------+


Это создает пустую группу безопасности, чтобы заставить ее выполнять то, что нужно нам, мы должны добавить некоторые правила.
$ nova secgroup-add-rule <secgroup> <ip-proto> <from-port> <to-port> <cidr>
$ nova secgroup-add-rule global_http tcp 80 80 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp         | 80        | 80      | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+


Обратите внимание, что все аргументы являются позиционными, и аргумент "from-port", и аргумент "to-port" определяют диапазон разрешенных соединений локальных портов, а не порты источника и получателя в соединении. Более сложные наборы правил могут быть построены посредством множественных вызовов nova secgroup-add-rule. Например, если вы хотите обмениваться и http, и https трафиком:
$ nova secgroup-add-rule global_http tcp 443 443 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp         | 443       | 443     | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+


Несмотря на вывод только вновь добавленного правила последняя операция аддитивная:
$ nova secgroup-list-rules global_http
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp         | 80        | 80      | 0.0.0.0/0 |              |
| tcp         | 443       | 443     | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+


Обратная операция называется secgroup-delete-rule и использует тот же формат. C помощью secgroup-Delete могут быть удалены группы безопасности целиком.

Чтобы создать правила группы безопасности для кластера экземпляров:

SourceGroup представляют собой особый динамический способ определения в формате CIDR разрешенных источников. Пользователь описывает SourceGroup (имя группы безопасности) и все другие использующие SourceGroup экземпляры пользователя выбираются динамически. Это избавляет от необходимости в индивидуальных правилах для каждого нового члена кластера. Применение:
nova secgroup-add-group-rule <secgroup> <source-group> <ip-proto> <from-port> <to-port>

$ nova secgroup-add-group-rule cluster global-http tcp 22 22


Правило "cluster" делает возможным ssh доступ из любого другого экземпляра, который использует группу "global-http".

Блочные хранилища

Тома OpenStack являются устройствами постоянного хранения при блочном доступе, причем могут быть присоединены и отсоединены к экземплярам, однако могут быть присоединены только к одному экземпляру одновременно, по аналогии с внешним жестким диском они на практике не являются совместно используемым хранилищем тем же образом, как это делают сетевая файловая система или хранилище объектов. Они оставляют операционной системе экземпляра выбор: помещать файловую систему на блочное устройство и монтировать его - или нет.

По аналогии с другими съемными дисковыми технологиями, важно, чтобы операционная система не пыталась использовать диск перед его удалением. В экземплярах Linux процесс обычно включает размонтирование всех файловых систем, смонтированных с тома. Служба тома OpenStack не может сообщить является ли удаление томов безопасным, поэтому она выполняет то, о чем ее просят. Если пользователь просит службу томов отсоединить тома от экземпляра во время записи на них, вы можете ожидать некоторый уровень разрушений файловой системы одновременно со сбоем в любом процессе экземпляра, который использует данное устройство.

Не существует ничего специфичного для OpenStack в понимании шагов, необходимых операционной системе экземпляра для доступа к блочному устройству: потенциально необходимое форматирование устройства перед его первым использованием и предосторожности при его удалении. Вот что действительно специфично, так это процесс создания нового тома, а также присоединение и отключение его от экземпляров. Все эти операции могут быть выполнены на странице "Volumes" инструментальной панели (Dashboard) или с использованием клиента командной строки cinder.

Для добавления новых томов вам потребуется только имя и размер тома в гигабайтах, либо поместив их в веб-форму "создать том" (create volume), или с помощью командной строки:
$ cinder create --display-name test-volume 10


Данная команда создает том объемом 10GB с названием "test-volume.". Чтобы вывести список томов и экземпляров, к которым они присоединены (если присоединение выполнялось):
$ cinder list
+------------+---------+--------------------+------+-------------+-------------+
| ID         | Status  | Display Name       | Size | Volume Type | Attached to |
+------------+---------+--------------------+------+-------------+-------------+
| 0821...19f | active  | test-volume        | 10   | None        |             |
+------------+---------+--------------------+------+-------------+-------------+


Служба блочных хранилищ также позволяет создавать моментальные снимки томов. Помните, что это моментальные снимки выполняются именно на блочном уровне, который является чувствительным к согласованности при сбоях, так что лучше, если том не подключен к экземпляру при создании моментального снимка и, если он все-таки присоединен: лучше будет, если том не будет использоваться экземпляром к которому он присоединен. Если том интенсивно используется, то моментальный снимок может иметь не согласованную файловую систему. На самом деле, по умолчанию служба тома не выполняет создание моментального снимка присоединенного к экземпляру тома, хотя это и может быть выполнено принудительно. Для получения моментального снимка тома либо выберите на странице тома (volume) инструментальной панели "Создать снимок" (Create Snapshot) в столбце действия (action), следующем за именем тома, или в командной строке:
usage: cinder snapshot-create [--force <True|False>]
[--display-name <display-name>]
[--display-description <display-description>]
<volume-id>
Add a new snapshot.
Positional arguments:
<volume-id> ID of the volume to snapshot
Optional arguments:
--force <True|False> Optional flag to indicate whether to snapshot a volume even if its attached to an instance (Default=False).
--display-name <display-name> Optional snapshot name. (Default=None)
--display-description <display-description> Optional snapshot description. (Default=None)

Перевод на русский язык:
Добавить новый снимок.
Позиционные аргументы:
<volume-id> ID тома для моментального снимка
Дополнительные аргументы:
--force <True|False> опциональный флаг, указывающий на необходимость создания моментального снимка тома, даже если он подключен к экземпляру (по умолчанию =False) .
--display-name <display-name> опциональное имя моментального снимка (по умолчанию =None).
--display-description <display-description> опциональное описание моментального снимка (по умолчанию =None).


Сбои при создании блочных хранилищ

Если пользователь пытается создать объем и сразу переходит в состояние ошибки, лучшим способ для устранения проблемы является вычленение из файла журналов cinder утилитой grep строк, содержащих UUID тома. Сначала проверьте файлы журналов в контроллере облака, а затем попробуйте на узле хранилища, на котором выполнялась попытка создания тома:
# grep 903b85d0-bacc-4855-a261-10843fc2d65b /var/log/cinder/*.log


Экземпляры

Экземпляры являются выполняемыми виртуальными машинами в пределах облака OpenStack. Данный раздел рассматривает как работать с ними и их подлежащими образами, их сетевыми свойствами и как они представлены в базе данных.

Запуск экземпляров

Чтобы запустить экземпляр вам необходимо выбрать образ, шаблон виртуального ресурса и имя. Имя не требует уникальности, однако ваша жизнь будет проще, если вы это сделаете, т.к. многие инструменты будут использовать имя на месте UUID пока имя является уникальным. Это может быть выполнено с инструментальной панели кнопкой "Запустить экземпляр" (Launch Instance) на странице "Instances" или выбрав действие "Запуск" (Launch), следующее за образом или моментальным снимком на странице "Images & Snapshots".

В командной строке:
$ nova boot --flavor <flavor> --image <image> <name>


Существует ряд дополнительных элементов, которые можно задать. Прежде чем попытаться их запустить, вы должны прочитать оставшуюся часть данного раздела об экземплярах, но приводимая команда является базовой на которую в последствии наслоятся детали.

Для удаления экземпляра с инструментальной панели выберите действие "Прекратить экземпляр " (Terminate instance) следующее за экземпляром на странице "Instances", из командной строки:
$ nova delete <instance-uuid>


Важно отметить, что выключение экземпляра не прекращает его в смысле OpenStack.

Сбои при загрузке экземпляра

Если экземпляр не запускается и немедленно переходит к состоянию "Ошибка" существует несколько различных способов отследить, что пошло не так. Некоторые из них можно выполнить обычным доступом пользователей, а другие требуют доступ к вашим журналам сервера или вычислительных узлов.

Простейшими причинами отказа в запуске узлов являются превышения квот или неспособность планировщика найти подходящий вычислительный узел для запуска экземпляра. В этих случаях ошибка очевидна при выполнении nova show отказавшем экземпляре.
$ nova show test-instance
+------------------------+-----------------------------------------------------\
| Property               | Value                                               /
+------------------------+-----------------------------------------------------\
| OS-DCF:diskConfig      | MANUAL                                              /
| OS-EXT-STS:power_state | 0                                                   \
| OS-EXT-STS:task_state  | None                                                /
| OS-EXT-STS:vm_state    | error                                               \
| accessIPv4             |                                                     /
| accessIPv6             |                                                     \
| config_drive           |                                                     /
| created                | 2013-03-01T19:28:24Z                                \
| fault                  | {u'message': u'NoValidHost', u'code': 500, u'created/
| flavor                 | xxl.super (11)                                      \
| hostId                 |                                                     /
| id                     | 940f3b2f-bd74-45ad-bee7-eb0a7318aa84                \
| image                  | quantal-test (65b4f432-7375-42b6-a9b8-7f654a1e676e) /
| key_name               | None                                                \
| metadata               | {}                                                  /
| name                   | test-instance                                       \
| security_groups        | [{u'name': u'default'}]                             /
| status                 | ERROR                                               \
| tenant_id              | 98333a1a28e746fa8c629c83a818ad57                    /
| updated                | 2013-03-01T19:28:26Z                                \
| user_id                | a1ef823458d24a68955fec6f3d390019                    /
+------------------------+-----------------------------------------------------\


В данном случае, просмотр "отказавшего" (fault) сообщения показывает NoValidHost (отсутствует допустимый хост), указывая на то, что планировщик не был в состоянии удовлетворить требования экземпляра.

Если nova show не достаточно объясняет отказ, осуществите поиск строк, содержащих UUID экземпляра в nova-compute.log на планировавшемся для запуска вычислительном узле или nova-scheduler.log на вашем хосте планировщика тоже является хорошим местом для начала поиска проблем более низкого уровня.

Использование nova show пользователем с правами администратора покажет как hostId вычислительный узел запланированного экземпляра, однако, если сбой запуска экземпляра произошел во время планирования данное поле будет пустым.

Данные, присущие экземпляру

Существует множество способов как внести пользовательские данные, включающих инъекцию идентификаторов authorized_keys, пользовательских данных, служб метаданных, а также инкапсулирование файла.

Для уточнения разницы между данными пользователя и метаданными уясните, что "данные пользователя" (user-data) являются фрагментами данных, размещенными при не запущенном экземпляре. Пользовательские данные доступны изнутри экземпляра при его работе. Персонал использует эти данные пользователя для хранения конфигурации, сценария или того, что хочет владелец.

Для Compute метаданные экземпляра представляет собой набор связанных с экземпляром пар ключ/ значение. Compute читает и пишет в эти пары ключ/ значение в любое время в течение времени жизни экземпляра, причем как из самого экземпляра, так и извне всякий раз, когда конечный пользователь применяет для этого интерфейс Compute API. Однако, у вас нет возможности запросить связанные с экземпляром пары ключ/ значение через службу метаданных по аналогии со службой метаданных Amazon EC2.

Пользователи могут создавать и регистрировать ключи ssh с использованием команды nova:
$ nova keypair-add mykey > mykey.pem


Она создает ключ с именем mykey, который вы можете связать с экземпляром. Файл mykey.pem является частным ключом, который должен быть сохранен в безопасном месте, поскольку он делает возможным доступ с правами root к экземпляру, с которым связан ключ mykey.

Вы можете зарегистрировать существующий общедоступный ключ в OpenStack при помощи команды
$ nova keypair-add --pub-key mykey.pub mykey


Вы должны иметь соответствующий частный ключ, чтобы получить доступ к связанным с этим ключом экземплярам.

Для связывания ключа с экземпляром про загрузке, например, добавьте в командую строку --key_name mykey:
$ nova boot --image ubuntu-cloudimage --flavor 1 --key_name mykey


При загрузке сервера вы можете добавить метаданные, так что вы сможете легко определить их среди других запущенных экземпляров. Используйте параметр --meta с парой key-value, где вы можете использовать строковое выражение и для ключа, и для значения. Например, можно добавить описание сервера, а также его автора.
$ nova boot --image=test-image --flavor=1 smallimage --meta description='Small test image'


При просмотре информации о сервере, вы сможете увидеть метаданные, находящееся в строке метаданных:
$ nova show smallimage
+------------------------+-----------------------------------------+
| Property               | Value                                   |
+------------------------+-----------------------------------------+
| OS-DCF:diskConfig      | MANUAL                                  |
| OS-EXT-STS:power_state | 1                                       |
| OS-EXT-STS:task_state  | None                                    |
| OS-EXT-STS:vm_state    | active                                  |
| accessIPv4             |                                         |
| accessIPv6             |                                         |
| config_drive           |                                         |
| created                | 2012-05-16T20:48:23Z                    |
| flavor                 | m1.small                                |
| hostId                 | de0...487                               |
| id                     | 8ec...f915                              |
| image                  | natty-image                             |
| key_name               |                                         |
| metadata               | {u'description': u'Small test image'}   |
| name                   | smallimage2                             |
| private network        | 172.16.101.11                           |
| progress               | 0                                       |
| public network         | 10.4.113.11                             |
| status                 | ACTIVE                                  |
| tenant_id              | e83...482                               |
| updated                | 2012-05-16T20:48:35Z                    |
| user_id                | de3...0a9                               |
+------------------------+-----------------------------------------+


Пользовательские данные (User Data) являются специальным ключом в службе метаданных, хранящей файл, который могут использовать в рамках гостевого экземпляра имеющие соответствующую компетенцию приложения облака. Например, cloudinit (https://help.ubuntu.com/community/CloudInit) является пакетом с открытым кодом из Ubuntu, обрабатывающим начальную инициализацию экземпляра облака, который позволяет использовать такие пользовательские данные.

Пользовательские данные могут быть помещены в файл в вашей локальной системе и, например, переданы в создаваемый экземпляр с помощью флага --user-data <user-data-file>:
$ nova boot --image ubuntu-cloudimage --flavor 1 --user-data mydata.file


Произвольные локальные файлы также могут быть размещены в файловой системе экземпляра в момент создания с помощью параметра --file <dst-path=src-path>. Вы можете сохранять до 5 файлов. Например, если у вас есть специальный файл authorized_keys с именем special_authorized_keysfile, который вы хотите поместить в экземпляр, причем по некоторым причинам без использования обычной инъекции с ключем ssh, вы можете использовать следующую команду:
$nova boot --image ubuntu-cloudimage --flavor 1 --file /root/.ssh/authorized_keys=special_authorized_keysfile


Привязывание группы безопасности

Обсуждавшиеся ранее группы безопасности, как правило, требуются для обеспечения сетевого трафика к экземпляру всякий раз, когда группа безопасности по умолчанию для проекта изменяется для снижения требований.

Добавление групп безопасности обычно выполняется при загрузке экземпляра. При запуске с инструментальной панели, существует вкладка "Access & Security " (Доступ и Безопасность) в диалоге "Launch Instance" (Запуск экземпляра). При запуске из командной строки присоединяйте к --security-groups разделенный запятыми список групп безопасности.

Кроме того, можно добавлять и удалять группы безопасности при запущенном экземпляре. В настоящее время эта функция доступна только через инструменты командной строки.
$ nova add-secgroup &t;server> <securitygroup>
$ nova remove-secgroup <server> <securitygroup>


Плавающие IP- адреса

Проекты имеют управляемое квотой количество плавающих IP- адресов, однако они должны быть выделены пользователем до того они доступны для использования. Для выделения проекту плавающих IP- адресов на странице инструментальной панели " Access & Security" (Доступ и Безопасность) существует кнопка "Allocate IP to Project" (Выделите IP для проекта) или в командной строке с помощью:
$ nova floating-ip-create


Будучи выделенными, плавающие IP- адреса могут назначаться работающим экземплярам из инструментальной панели либо путем выбора "Associate Floating IP" (Привязывание плавающих IP- адресов) из ниспадающего меню действий, следующего за IP на странице "Access & Security" (Доступ и Безопасность), или в аналогичном меню действий, следующим за экземпляром, к которому вы собираетесь привязывать IP- адреса на странице "Instances" (Экземпляры). Обратное действие "Dissociate Floating IP" (Отсоединение плавающих IP- адресов), доступно только со страницы "Access & Security" (Доступ и Безопасность) и не доступно со страницы "Instances" (Экземпляры).

Для выполнения этих задач в командной строке введите:
$ nova add-floating-ip <server> <address>
$ nova remove-floating-ip <server> <address>


Присоединение блочных хранилищ

Вы можете присоединить блочное хранилище к экземпляру с инструментальной панели на странице "Volumes" (Тома). Кликните действие "Edit Attachments" (Редактировать Присоединения) сразу за томом, который вы хотите присоединить.

Для выполнения этого действия из командной строки запустите следующую команду:
$ nova volume-attach <server> <volume>


Также вы можете описать отображение блочных устройств при загрузке экземпляра следующим образом с помощью команды nova:
--block-device-mapping <dev-name=mapping>


Формат отображения блочных устройств следующий: <dev-name=<id>:<type>:<size(GB)>:<deleteon-terminate>, где

dev-name

Имя устройства, с которым том присоединяется к системе в каталог /dev/dev_name.

id

ID тома (volume), с которого необходимо выполнять загрузку, как оно отображается в выдаче списка томов nova.

type

Принимает значение либо snap, что означает, что том был создан из моментального снимка (snapshot), либо что- то отличное от snap (допустима пустая строка). В приводимом выше примере том не создавался из моментального снимка, мы также оставили это поле пустым в нашем следующем примере.

size (GB)

Размер тома в ГигаБайтах. Более безопасно оставить это поле пустым и предоставить возможность внести размер службе Compute.

delete-on-terminate

Булевское значение, обозначающее: должен ли том быть удален после прекращения работы экземпляра. Истинное значение (True) может быть описано как True или 1. Ложное значение (False) может быть описано как False или 0.

Если вы предварительно подготовили блочное хранилище с загрузочным образом файловой системы, возможно будет даже загрузиться с постоянного блочного хранилища. Следующий пример будет пытаться загрузиться с тома, имеющего ID = 13, причем он не будет удаляться по завершению. Замените --key-namewith допустимое имя ключа:
$nova boot --flavor 2 --key-name mykey --block-device-mapping vda=13:::0 bootfrom-vol-test


Из- за ошибки (bug) 1163566 (https://bugs.launchpad.net/nova/+bug/1163566) вам необходимо описывать имя образа при его загрузке с Horizon, даже если этот образ не использовался.

Для нормальной загрузки с образа и присоединения блочного хранилища, пропишите устройство, отличное от vda.

Получение моментальных снимков

Механизм моментальных снимков OpenStack позволяет вам создавать новые образы из запущенных экземпляров. Это очень удобно для модернизации базовых образов или получения публикуемых образов, а также для их настройки для локального использования. Чтобы сделать моментальный снимок работающего экземпляра и поместить его в образ с помощью интерфейса командной строки (CLI):
$ nova image-create <instance name or uuid> <name of new image>


Интерфейс инструментальной панели (Dashboard) для моментальных снимков может ввести в заблуждение, поскольку страница "Images & Snapshots" (Образов и Снимков) разбивает содержимое на:

• Images (образы)
• Instance snapshots (моментальные снимки экземпляров)
• Volume snapshots (моментальные снимки томов)

Однако моментальный снимок экземпляра является образом. Единственная разница между образом, который вы загружаете непосредственно в glance и образом, который вы создаете с помощью моментального снимка заключается в том, что созданный моментальным снимком образ имеет дополнительные свойства в базе данных glance. Эти свойства можно найти в таблице image_properties, и включают в себя:

Название	Значение
image_type	snapshot (моментальный снимок)
instance_uuid	<uuid экземпляра, с которого делается моментальный снимок>
base_image_ref	<uuid оригинального образа экземпляра, с которого выполняется моментальный снимок>
image_location	snapshot (моментальный снимок)

Обеспечение согласованности моментальных снимков

Содержание взято из записи в блоге Sebastien Han OpenStack: Perform Consistent Snapshots ( http://www.sebastien-han.fr/blog/2012/12/10/openstack-perform-consistent-snapshots/)

Моментальный снимок фиксирует состояние файловой системы, а не состояние оперативной памяти. Следовательно, чтобы быть уверенным, что ваш моментальный снимок содержит необходимые вам данные, перед созданием моментального снимка вы должны убедиться, что:

• Выполняющиеся программы записали свое содержимое на диск
• Файловая система не имеет никаких "dirty" ("грязных") буферов: в которые программа отдала инструкцию сделать запись на диск, однако операционная система пока не выполнила запись

Чтобы быть уверенным, что важные службы выполнили запись своего содержимого на диск (например, такие, как базы данных), мы рекомендуем вам прочитать документацию на эти приложения для определения того, какие команды непосредственно выполняют синхронизацию их содержимого с диском. Если у вас нет уверенности как ее (синхронизацию) выполнить, самым надежным способом будет простой нормальный останов выполняющихся служб.

Для решения проблемы "грязного" буфера, мы рекомендуем использование команды синхронизации перед созданием моментального снимка:
# sync


Выполнение sync записывает грязный буфер (буферизованный блок, который был изменен, но пока не был переписан в дисковый блок) на диск.

Простое выполнение sync не гарантирует вам полной согласованности файловой системы. Мы рекомендуем вам использовать инструментарий fsfreeze, который приводит к прекращению нового доступа к файловой системе и создает стабильный образ на диске, который предназначен для моментального снимка. fsfreeze поддерживает несколько файловых систем, в том числе ext3, ext4 и XFS. Если ваш экземпляр виртуальной машины работает под Ubuntu, установите пакет util-linux для получения fsfreeze:
# apt-get install util-linux


В случае, когда ваша операционная система не имеет доступной версии fsfreeze, вы можете использовать вместо нее xfs_freeze, который доступен в Ubuntu из пакета xfsprogs. Несмотря на присутствие в имени "xfs", xfs_freeze также работает с ext3 и ext4, если вы используете ядро Linux версии 2.6.29 или старше, так как он работает на уровне виртуальной файловой системы (VFS), имеющейся начиная с версии 2.6.29. xfs_freeze поддерживает те же аргументы командной строки, что и fsfreeze.

Рассмотрим пример, в котором вы хотите сделать моментальный снимок тома постоянного хранения блочного устройства, обнаруженного гостевой операционной системой как /dev/vdb и смонтированного в /mnt. Команда fsfreeze принимает 2 аргумента:

• -f: заморозить систему
• -u: растопить (разморозить) систему

Чтобы заморозить том при подготовке к созданию моментального снимка, вы должны выполнить в пределах экземпляра с правами root:
# fsfreeze -f /mnt


Вы должны смонтировать файловую систему до выполнения команды fsfreeze.

После выдачи команды "fsfreeze -f", всем выполняющимся в файловой системе транзакциям разрешается завершиться, новые запросы на запись приостанавливаются, а также останавливаются все запросы к файловой системе, которые могут ее изменить. Что особенно важно, все грязные данные, метаданные и информация в журналах записываются на диск.

После того как том заморожен, не пытайтесь читать с него или осуществлять запись на него, поскольку все операции ставятся в ожидание (подвешиваются). Операционная система останавливает все операции ввода/ вывода и любые попытки ввода/ вывода будут задерживаться пока файловая система не будет разморожена.

После выполнения команды fsfreeze создание моментального снимка становится безопасным. Например, если ваш экземпляр называется mon-instance и вы хотите сделать его моментальный снимок в образ с названием mon-snapshot, вы можете теперь выполнить следующее:
$ nova image-create mon-instance mon-snapshot


После создания моментального снимка вы можете растопить файловую систему в пределах экземпляра следующей командой, обладая правами root:
# fsfreeze -u /mnt


Если вы хотите сделать резервную копию файловой системы root, вы не можете просто выполнить приводимую выше команду, так как она заморозит приглашение операционной системы (prompt). Вместо этого выполните с правами root внутри экземпляра следующий однострочный скрипт:
# fsfreeze -f / && sleep 30 && fsfreeze -u /


Экземпляры в базах данных

Поскольку информация об экземпляре хранится в нескольких таблицах базы данных, скорее всего, будут необходимы табличные операторы выполняемые относительно просмотра пользовательских экземпляров, являющихся таблицей "instances" ("экземпляров").

Таблица instances содержит всю основную информацию, связанную как с выполняющимися, так и с удаленными экземплярами. Она имеет приводящее в замешательство множество полей для исчерпывающего списка поиска по базе данных. Существуют наиболее полезные поля для создания запросов операций поиска.

Удаленные ("deleted") поля установлены в значение "1", если экземпляр был удален и NULL, если он не был удален, что важно для исключения удаленных экземпляров из ваших запросов.

Поле "uuid" является UUID экземпляра и используется в других таблицах в базе данных в качестве внешнего ключа (foreign key). Этот идентификатор также передается в журналы, инструментальные панели и инструменты командной строки для уникальной идентификации экземпляра.

Для поиска связей (relation) с экземплярами доступна совокупность внешних ключей. Наиболее полезные из них это "user_id" и "project_id", являющиеся, соответственно, UUID пользователя, запустившего экземпляр и проекта, в котором он запущен.

Поле "host" говорит о том, какой вычислительный узел является хостом экземпляра.

Поле "hostname" содержит имя экземпляра при его запуске. Первоначально "display-name" то же что и "hostname", однако может быть переустановлено командой nova rename.

Для отслеживания момента изменения состояния экземпляра являются полезными ряд полей, относящихся ко времени:

• created_at (создан в)
• updated_at (изменен в)
• deleted_at (удален в)
• scheduled_at (запланирован на)
• launched_at (запущен в)
• terminated_at (прекращен в)

Глава 9	Оглавление	Глава 11
Перевод: Copyright © 2015  . All rights reserved. Ссылки обязательны (Refs and links obligatory).		http://www.mdl.ru