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

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

После того, как контроллер облака перезагрузился, проверьте что успешно стартовали все необходимые службы. Следующие команды используют ps и grep для определения того, что nova, glance и keystone в настоящее время выполняются:

# ps aux | grep nova-
# ps aux | grep glance-
# ps aux | grep keystone
# ps aux | grep cinder

Также проверьте, что все службы функционируют. Следующий набор команд устанавливают происхождение файла openrc, затем выполняют некоторые основные команды glance, nova и keystone. Если команды выполняются надлежащим образом, вы можете быть уверены, что эти службы работают надлежащим образом:

# source openrc
# glance index
# nova list
# keystone tenant-list

Для прокси системы хранения убедитесь, что возобновилась служба системы хранения объектов (Object Storage):

# ps aux | grep swift

Также проверьте, что она работает:

# swift stat

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

Чтобы избежать подобной ситуации, создайте кластер контроллера облака высокой доступности. Это выходит за рамки данного документа, но вы можете прочитать дополнительные сведения в проекте Руководства высокой доступности OpenStack.

Другой хороший способ заключается в использовании инструмента управления конфигурацией, например, Puppet, для автоматического создания контроллера облака. Это не должно занять более 15 минут, если у вас имеется запасной сервер. После восстановления контроллера восстановите все сделанные резервные копии (см. Главу 14, Резервное копирование и восстановление).

Кроме того, на практике, службы nova-compute на вычислительных узлах иногда не аккуратно подключаются к размещенной на контроллере rabbitmq в случае, когда он возвращается после совместной перезагрузки и требуется перезагрузка служб nova на вычислительных узлах.

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

# nova list --host c01.example.com --all-tenants

# nova live-migration <uuid> c02.example.com

# nova live-migration --block-migrate <uuid> c02.example.com

# stop nova-compute

# mkdir /root/tmp
# mv /etc/init/nova-compute.conf /root/tmp
# mv /etc/init.d/nova-compute /root/tmp

# mv /root/tmp/nova-compute.conf /etc/init
# mv /root/tmp/nova-compute /etc/init.d/

# start nova-compute

После перезагрузки вычислительного узла, убедитесь что он успешно загрузился. Это включает в себя проверку того, что служба nova-compute работает:

# ps aux | grep nova-compute
# status nova-compute

# grep AMQP /var/log/nova/nova-compute
2013-02-26 09:51:31 12427 INFO nova.openstack.common.rpc.common [-] Connected to AMQP server on 199.116.232.36:5672

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

# nova list --host c01.example.com --all-tenants

После получения списка,вы можете использовать команду nova для запуска каждого экземпляра:

# nova reboot <uuid>

	Замечание
	После каждого неожиданного останова экземпляра могут возникать проблемы при загрузке. Например, экземпляр может потребовать выполнение fsck в корневом разделе. Если подобное произойдет, пользователь может использовать консоль VNC инструментальной панели (Dashboard) для исправления подобных проблем.

Если экземпляр не загружается, что означает, что virsh list никогда не показывает экземпляр даже предпринимающим попытку загрузки, выполните следующее на вычислительном узле:

# tail -f /var/log/nova/nova-compute.log

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

В большинстве случаев ошибка обусловлена чем-то в файле libvirt XML (/etc/libvirt/qemu/instance-xxxxxxxx.xml), который больше не существует. Вы можете применить восстановление файла XML, а также перезагрузку экземпляра, выполнив следующую команду:

# nova reboot --hard <uuid>

При некотором развитии событий экземпляры работают, однако не доступны через SSH и не отвечают ни на какие команды. Консоль VNC может отобразить ошибки загрузки или панические ошибки ядра (kernel panic error messages). Это может быть признаком разрушения файловой системы на самой виртуальной машине. Если вам необходимо восстановить файлы или проверить содержимое экземпляра, для монтирования диска может использоваться qemu-nbd.

	Предостережение
	Если вы осуществляете доступ или просматриваете содержимое и данные пользователя, вначале получите его разрешение!

Для доступа к диску экземпляра (/var/lib/nova/instances/instance-xxxxxx/disk) необходимо следовать следующим этапам:

1. Временно остановите экземпляр с помощью команды virsh.

2. Подключите к диску устройство qemu-nbd.

3. Смонтируйте устройство qemu-nbd.

4. Размонтируйте устройство после осмотра.

5. Отсоедините устройство qemu-nbd.

6. Возобновите экземпляр.

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

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

Если поврежденные экземляры также имели присоединенные тома, сначала создайте список UUID экземпляров и томов:

mysql> select nova.instances.uuid as instance_uuid,
cinder.volumes.id as volume_uuid, cinder.volumes.status,
cinder.volumes.attach_status, cinder.volumes.mountpoint,
cinder.volumes.display_name from cinder.volumes
inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid
 where nova.instances.host = 'c01.example.com';

+--------------+------------+-------+--------------+-----------+--------------+
|instance_uuid |volume_uuid |status |attach_status |mountpoint | display_name |
+--------------+------------+-------+--------------+-----------+--------------+
|9b969a05      |1f0fbf36    |in-use |attached      |/dev/vdc   | test         |
+--------------+------------+-------+--------------+-----------+--------------+
1 row in set (0.00 sec)

# nova volume-detach <instance_uuid> <volume_uuid>
# nova volume-attach <instance_uuid> <volume_uuid> /dev/vdX

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

mysql> select uuid from instances where host = \
       'c01.example.com' and deleted = 0;

mysql> update instances set host = 'c02.example.com' where host = \
       'c01.example.com' and deleted = 0;

# nova reboot --hard <uuid>

Наконец, вновь присоедините тома, используя метод, аналогичный описанному в разделе Тома.

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

Если узлу хранения требуется перезагрузка- просто перезагрузите его. Запросы к размещенным на нем данным будут перенаправлены на другие копии до окончания процесса перезагрузки сервера.

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

# swift-ring-builder account.builder remove <ip address of storage node>
# swift-ring-builder container.builder remove <ip address of storage node>
# swift-ring-builder object.builder remove <ip address of storage node>
# swift-ring-builder account.builder rebalance
# swift-ring-builder container.builder rebalance
# swift-ring-builder object.builder rebalance

# for i in s01.example.com s02.example.com s03.example.com
> do
> scp *.ring.gz $i:/etc/swift
> done

В случае выхода из строя диска на узле хранения объектов его замена относительно проста. Она предполагает, что среда вашего хранилища объектов настроена правильно, т.е. хранящиеся на отказавшем диске данные также дублированы на другие диски в среде хранения объектов.

# umount /dev/sdb

# dmesg | tail

# mkfs.xfs /dev/sdb

# mount -a

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

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

	Замечание
	Если ваш новый узел хранения объектов имеет количество дисков отличное от значения для имевшихся в начале узлов, команда добавления нового узла отличается от первоначальных команд. Эти параметры меняются от среды к среде.

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

Просмотрите файл конфигурации компонентов, чтобы увидеть, как каждый компонент OpenStack получает доступ к соответствующей базе данных. Ищите sql_connection или просто connection sql_connection or simply connection. Следующая команда использует grep для отображения строк соединений SQL для nova, glance, cinder и keystone:

# grep -hE "connection ?=" /etc/nova/nova.conf /etc/glance/glance-*.conf
/etc/cinder/cinder.conf /etc/keystone/keystone.conf
sql_connection = mysql://nova:nova@cloud.alberta.sandbox.cybera.ca/nova
sql_connection = mysql://glance:password@cloud.example.com/glance
sql_connection = mysql://glance:password@cloud.example.com/glance
sql_connection = mysql://cinder:password@cloud.example.com/cinder
    connection = mysql://keystone_admin:password@cloud.example.com/keystone

Строки подключения имеют следующий формат:

mysql:// <username> : <password> @ <hostname> / <database name>

По мере роста облака MySQL используется все больше и больше. Если вы подозреваете, что MySQL может стать узким местом, вы должны начать изучение оптимизации MySQL. Руководство MySQL имеет целый раздел, посвященный этой теме: Обзор оптимизации.

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

# tail -f /var/log/nova/nova-api.log

# nova list

Ознакомьтесь со всеми ошибками и трассировкой в файле журнала. Для получения дополнительной информации ознакомьтесь с Гылавой 13, Ведение журналов и мониторинг.

Если ошибка индицирует, что проблема с другим компонентом, переключитесь на анализ хвоста файла журнала этой компоненты. Например, если nova не может получить доступ к glance, просмотрите журнал glance-api:

Terminal 1:

# tail -f /var/log/glance/api.log

Terminal 2:

# nova list

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

К сожалению, иногда ошибка не очевидна из файлов журналов. В этом случае измените тактику и используйте различные команды, возможно, запустите службу непосредственно в командной строке. Например, если служба glance-api отказывается стартовать и остается работающей, попробуйте запустить демон из командной строки:

# sudo -u glance -H glance-api

Это может вывести ошибку и причину проблемы.

	Замечание
	При работе демона с sudo необходим флаг -H, так как некоторые демоны будут записывать файлы относительно домашнего каталога пользователя и данная запись может окончиться неудачей при опускании -H.

Пример осложнений

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

Дальнейший поиск неисправностей показал, что libvirt вовсе не работает. Это имело больше смысла. Если libvirt не работает, то никакой экземпляр не может виртуализироваться с использованием KVM. После попытки запуска libvirt, она сразу молча падает. Журналы libvirt не объясняют причину.

Далее, демон libvirtd был запущен в командной строке. Наконец, полезное сообщение об ошибке: он не может подключиться к d-bus. Как не смешно это звучит, libvirt, и, следовательно, nova-compute, полагаются на d-bus и по какой-то причине d-bus отказывает. Простой старт d-bus устанавливает всю цепочку необходимым образом и вскоре все восстанавливается и работает.