С 1991 года на компьютерном рынке России

т.: 676 0965, 676 0396
Москва, Сосинская ул. 43,
м. Волгоградский проспект

ГЛАВА 11

Обслуживание, сбои и отладка

Пользуйтесь переводом существенно переработанной и дополенной 2й редакции (12-дек-2014),
находящейся теперь и в режиме постоянно обновляемой документации
(последняя пока доступна только на англ.яз.).

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

Отказы и техническое обслуживание контроллера облака и прокси системы хранения

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

Хорошей новостью для контроллера облака является то, что если ваше облако использует сетевой режим мультихостовой высокой доступности (multihost HA) FlatDHCP, то существующие экземпляры и тома продолжают работать при уходе контроллера облака в офлайн. Однако для прокси системы хранения невозможны никакие потоки хранимой информации до тех пор, пока он не вернется к работе.

Запланированное обслуживание

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

Перезагрузка контроллера облака или прокси системы хранения

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

После того, как контроллер облака и прокси системы хранения перезагрузились

После того, как контроллер облака перезагрузился, проверьте что успешно стартовали все необходимые службы:
# ps aux | grep nova-# grep AMQP /var/log/nova/nova-*.log # ps aux | grep glance-# ps aux | grep keystone # ps aux | grep cinder

Также проверьте, что все службы функционируют:
# source openrc # glance index # nova list # keystone tenant-list

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

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

Полный отказ контроллера облака

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

Чтобы избежать подобной ситуации, создайте кластер контроллера облака высокой доступности. Это выходит за рамки данного документа, но вы можете прочитать дополнительные сведения в проекте OpenStack High Availability Guide ( http://docs.openstack.org/trunk/openstack-ha/content/ch-intro.html).

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

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

Отказы вычислительных узлов и их обслуживание

Иногда вычислительный узел либо неожиданно испытывает сбой, либо требует перезагрузки по причинам технического характера.

Запланированное обслуживание

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

Затем переместите их один за другим:
# nova live-migration <uuid> c02.example.com

После переноса всех экземпляров обеспечьте останов всех служб nova-compute:
# stop nova-compute

Если вы используете систему управления настройками, например, Puppet, которая обеспечивает постоянную работу служб nova-compute, вы можете временно перенести файлы инициализации:
# mkdir /root/tmp # mv /etc/init/nova-compute.conf /root/tmp # mv /etc/init.d/nova-compute /root/tmp

Затем закройте свои вычислительные узлы, выполните ваши работы по обслуживанию и включите их снова. Вы можете снова запустить службу nova-compute, откатив предыдущие команды:
# mv /root/tmp/nova-compute.conf /etc/init # mv /root/tmp/nova-compute /etc/init.d/

Затем запустите службу nova-compute:
# start nova-compute

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

После перезагрузки вычислительных узлов

После перезагрузки вычислительного узла, убедитесь что он успешно загрузился.

Это включает в себя проверку того, что служба nova-compute работает:
# ps aux | grep nova-compute # status nova-compute

Также убедитесь, что она успешно подключилась к серверу AMQP:
# 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

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

Экземпляры

Вы можете создать список размещенных на вычислительном узле экземпляров, выполнив следующую команду:
# 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). Это может быть признаком разрушения файловой системы на самой виртуальной машине. Если вам необходимо восстановить файлы или проверить содержимое экземпляра, для монтирования диска может использоваться qemu-nbd.

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

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

Временно остановите экземпляр с помощью команды virsh
Подключите к диску устройство qemu-nbd
Смонтируйте устройство qemu-nbd
Размонтируйте устройство после осмотра
Отсоедините устройство qemu-nbd
Возобновите экземпляр

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

Он не будет отвечать ни на какие выполняемые OpenStack Compute команды и помечается остановленным.

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

Приостановите экземпляр с помощью команды virsh - принимая во внимание внутренний идентификатор (ID).
root@compute-node:~# virsh list Id Name State ---------------------------------- 1 instance-00000981 running 2 instance-000009f5 running 30 instance-0000274a running root@compute-node:~# virsh suspend 30 Domain 30 suspendedПрисоедините к диску устройство qemu-nbd:
root@compute-node:/var/lib/nova/instances/instance-0000274a# ls -lh total 33M -rw-rw---- 1 libvirt-qemu kvm 6.3K Oct 15 11:31 console.log -rw-r--r-- 1 libvirt-qemu kvm 33M Oct 15 22:06 disk -rw-r--r-- 1 libvirt-qemu kvm 384K Oct 15 22:06 disk.local -rw-rw-r-- 1 nova nova 1.7K Oct 15 11:30 libvirt.xml root@compute-node:/var/lib/nova/instances/instance-0000274a# qemu-nbd -c /dev/nbd0 `pwd`/disk
Смонтируте устройство qemu-nbd. Например, если vda диск, а vda1 корневой раздел, qemu-nbd экспортирует устройства в /dev/nbd0 и в /dev/nbd0p1 соответственно.
#mount the root partition of the device root@compute-node:/var/lib/nova/instances/instance-0000274a# mount /dev/nbd0p1 /mnt/ # List the directories of mnt, and the vm's folder is display # You can inspect the folders and access the /var/log/ files Для изучения второго или эфемерного диска используйте альтернативную точку монтирования, если вы хотите иметь в одно и то же время смонтированными и первичный, и вторичный диски.
# umount /mnt # qemu-nbd -c /dev/nbd1 `pwd`/disk.local # mount /dev/nbd1 /mnt/ root@compute-node:/var/lib/nova/instances/instance-0000274a# ls -lh /mnt/ total 76K lrwxrwxrwx. 1 root root 7 Oct 15 00:44 bin -> usr/bin dr-xr-xr-x. 4 root root 4.0K Oct 15 01:07 boot drwxr-xr-x. 2 root root 4.0K Oct 15 00:42 dev drwxr-xr-x. 70 root root 4.0K Oct 15 11:31 etc drwxr-xr-x. 3 root root 4.0K Oct 15 01:07 home lrwxrwxrwx. 1 root root 7 Oct 15 00:44 lib -> usr/lib lrwxrwxrwx. 1 root root 9 Oct 15 00:44 lib64 -> usr/lib64 drwx------. 2 root root 16K Oct 15 00:42 lost+found drwxr-xr-x. 2 root root 4.0K Feb 3 2012 media drwxr-xr-x. 2 root root 4.0K Feb 3 2012 mnt drwxr-xr-x. 2 root root 4.0K Feb 3 2012 opt drwxr-xr-x. 2 root root 4.0K Oct 15 00:42 proc dr-xr-x---. 3 root root 4.0K Oct 15 21:56 root drwxr-xr-x. 14 root root 4.0K Oct 15 01:07 run lrwxrwxrwx. 1 root root 8 Oct 15 00:44 sbin -> usr/sbin drwxr-xr-x. 2 root root 4.0K Feb 3 2012 srv drwxr-xr-x. 2 root root 4.0K Oct 15 00:42 sys drwxrwxrwt. 9 root root 4.0K Oct 15 16:29 tmp drwxr-xr-x. 13 root root 4.0K Oct 15 00:44 usr drwxr-xr-x. 17 root root 4.0K Oct 15 00:44 var
После того, как вы завершили просмотр, размонтируйте точку монтирования и освободите устройство qemu-nbd
root@compute-node:/var/lib/nova/instances/instance-0000274a# umount /mnt root@compute-node:/var/lib/nova/instances/instance-0000274a# qemu-nbd -d /dev/nbd0/dev/nbd0 disconnected
Возобновите экземпляр с помощью virsh
root@compute-node:/var/lib/nova/instances/instance-0000274a# virsh list Id Name State ---------------------------------- 1 instance-00000981 running 2 instance-000009f5 running 30 instance-0000274a paused root@compute-node:/var/lib/nova/instances/instance-0000274a# virsh resume 30 Domain 30 resumed

Тома

Если поврежденные экземляры также имели присоединенные тома, сначала создайте список 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';

Далее вручную отключите и повторно подключите тома:
# nova volume-detach <instance_uuid> <volume_uuid> # nova volume-attach <instance_uuid> <volume_uuid> /dev/vdX

Где X - соответствующая точка монтирования. Перед выполнением приведенных выше действий убедитесь, что экземпляр успешно загрузился и находится на окне регистрации (login screen).

Полный отказ вычислительного узла

Если вычислительный узел отказал и не может быть восстановлен в течение нескольких часов или более, вы можете возобновить все размещенные на отказавшем узле экземпляры, если вы используете совместно используемую систему хранения для /var/lib/nova/instances.

Чтобы сделать это, создайте список UUID размещенных на отказавшем узле экземпляров, выполнив следующий запрос к базе данных nova:
mysql> select uuid from instances where host = 'c01.example.com' and deleted = 0;

Далее сообщите Nova, что все экземпляры, которые раньше были размещены на c01.example.com, теперь размещаются на c02.example.com:
mysql> update instances set host = 'c02.example.com' where host = 'c01.example.com' and deleted = 0;

После этого, используйте команду nova для перезагрузки всех экземпляров, которые были запущены на на c01.example.com, одновременно генерируя их XML файлы:
# nova reboot --hard <uuid>

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

/var/lib/nova/instances

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

/var/lib/nova/instances содержит два типа каталогов.

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

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

Все файлы и директории в /var/lib/nova/instances именованы уникально. Файлы в _base имеют уникальные имена для образа glance, на котором они основаны, а имена каталогов instance-xxxxxxxx имеют уникальные для данного конкретного экземпляра. Например, если вы копируете все данные из /var/lib/nova/instances с одного вычислительного узла на другой, вы не перезаписываете все файлы и не наносите ущерб образам, которые имеют такое же уникальное имя, поскольку они являются по- существу, тем же самым файлом.

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

Отказы узлов хранения и их обслуживание

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

Перезагрузка узла хранения

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

Завершение работы узла хранения

Если вам нужно выключить узел хранения на длительный период времени (от одних суток и более), рассмотрите возможность удаления узла из кольца системы хранения. Например:
# 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

Данные действия эффективно изымают узел хранения из кластера хранения.

Когда узел способен присоединиться к кластеру, просто опять добавьте его в кольцо. Точный синтаксис добавления узла в ваш кластер Swift с использованием swift-ring-builder сильно зависит от исходных параметров, использовавшихся при первоначальном построении вашего кластера. Обратитесь, пожалуйста, к тем командам.

Замена диска Swift

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

В данном примере предполагается, что отказал /dev/sdbhas.

Во- первых размонтируйте диск:
# umount /dev/sdb

Далее, физически удалить диск из сервера и замените его на работающий диск. Убедитесь, что операционная система распознала новый диск:
# dmesg | tail

Вы должны увидеть сообщение о /dev/sdb. Поскольку рекомендуется не использовать разделы на диске swift, просто отформатируйте диск целиком:
# mkfs.xfs /dev/sdb

В конце смонтируйте диск:
# mount -a

Swift должен увидеть новый диск и убедиться, что не существует никаких данных. Затем он начинает репликацию данных на диск с других существующих копий.

Обработка полного отказа

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

1 Внутрисетевое подключение
2 Службы резервирования систем хранения
3 Подключение к общедоступной сети для пользователей виртуальных машин
4 Хосты nova-compute, nova-network, cinder
5 Виртуальные машины пользователей
10 Службы очередей сообщений и базы данных
15 Службы Keystone
20 Планировщик cinder
21 Службы каталога образов и доставки
22 Службы nova-scheduler
98 Cinder-api
99 Службы Nova-api
100 Узел инструментальной панели

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

Управление конфигурацией

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

Доступны различные инструменты управления конфигурацией и данное руководство не рекомендует какой- то один определенный. Двумя наиболее популярными в сообществе OpenStack являются Puppet (https://puppetlabs.com/) с доступными OpenStack Puppet modules ( http://github.com/puppetlabs/puppetlabs-openstack) и Chef ( http://opscode.com/chef) с доступными OpenStack Chef recipes (https://github.com/opscode/openstack-chef-repo). Другие, более новые средства настройки включают Juju (https://juju.ubuntu.com/), Ansible (Прим. перев.: по всей видимости, необходимо пользоваться ссылкой http://www.ansible.com, вместо приводимой в первоисточнике: http://ansible.cc) и Salt (http://saltstack.com), а более зрелые инструменты управления конфигурацией включают CFEngine (http://cfengine.com) и Bcfg2 (http://bcfg2.org).

Работа с аппаратными средствами

Аналогично с начальным развертыванием, вы должны убедиться, что все оборудование надлежащим образом включено перед его добавлением в работу. Запустите используемое аппаратными средствами программное обеспечение на свои ограничения - используйте до предела возможности ОЗУ, ЦПУ, диска и сети. Доступно много опций, причем обычно они дублируются в виде программного обеспечения замера производительности, следовательно вы получаете хорошее представление о производительности вашей системы.

Добавление вычислительного узла

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

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

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

Добавление узла хранения объектов

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

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

Замена компонентов

В крупномасштабных реализациях, подобных облачным инфраструктурам, отказы оборудования обычны.

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

Базы данных

Почти все компоненты OpenStack имеют в своей основе для хранения постоянной информации базу данных. Обычно MySQL является такой базой данных. К этим базам данных применимо стандартное администрирование MySQL. OpenStack не настраивает базы данных экстраординарным способом. Основное администрирование включает в себя улучшение производительности, высокую доступность, резервное копирование, восстановление и исправление. Для получения дополнительной информации ознакомьтесь со стандартным руководством администрирования MySQL.

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

Связь с базой данных

Просмотрите файл конфигурации компонентов, чтобы увидеть, как каждый компонент OpenStack получает доступ к соответствующей базе данных. Ищите sql_connectionor или просто connection:
# 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 имеет целый раздел, посвященный этой теме Optimization Overview ( http://dev.mysql.com/doc/refman/5.5/en/optimize-overview.html).

HDWMY

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

Каждый час

Проверяйте вашу систему мониторинга на наличие предупреждений и реагируйте на них.
Проверяйте очередь билетов на доступ к объектам на предмет новых билетов.

Ежедневно

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

Еженедельно

Проверьте использование облака:
- Квоты пользователя
- Дисковое пространство
- Использование образов
- Большие экземпляры
- Использование сети (пропускная способность и использование IP).
Убедитесь, что ваши механизмы предупреждения все еще работают.

Ежемесячно

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

Ежеквартально

Проведите анализ использования и трендов за последний квартал.
Подготовьте все квартальные отчеты об использовании и статистике.
Проведите анализ и планирование необходимых добавлений в облако.
Проведите анализ и планирование главных обновлений OpenStack.

Каждые полгода

Обновляйте OpenStack.
Проведите очистку после обновления OpenStack (вы должны быть в курсе о наличии всех неиспользуемых или новых служб?)

Выявление неисправных компонентов

Сбор OpenStack-ом сведений о том как взаимодействуют между собой различные компоненты обязателен. Например, загрузка образов требует взаимодействия от nova-api, glance-api, glance-registry, Keystone и, потенциально, swift-proxy. В результате, иногда бывает трудно определить точно источник проблемы. Цель данного раздела заключается в помощи в этом.

Хвосты журналов

Первое место для просмотра файла журнала, связанного с командой, которую вы пытаетесь запустить. Например, если nova list завершилась неудачей, попробуйте запустить просмотр хвоста файла журнала Nova и запустите команду снова:
Terminal 1:
# tail -f /var/log/nova/nova-api.log

Terminal 2:
# nova list

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

Например, если 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

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

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

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

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

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

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

Обновления

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

Процесс обновления обычно выполняет следующие действия:

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

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

Наиболее общий, кажущийся успешным, порядок следующий:

Обновите службу идентификации OpenStack (keystone).
Обновите службу образов OpenStack (glance).
Обновите службы вычислительных узлов OpenStack (nova).
Обновите службы блочных хранилищ OpenStack (cinder).

Для каждого из этих шагов выполните следующие под-этапы:

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

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

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

Хорошей мыслью также является выполнение некоторой "очистки" кластера перед запуском обновления для того, чтобы убедиться в согласованности. Например, иногда имеются сообщения о проблемах с экземплярами, которые не были полностью стерты из системы после их удаления. Запустите команду эквивалентную следующей:
$ virsh list --all
для поиска удаленных экземпляров, которые до сих пор зарегистрированы в гипервизоре,а удаление их до запуска обновления может помочь избежать проблем.

Деинсталляция

Хотя мы всегда рекомендовали бы выполнять деинсталляцию систем с помощью автоматизированной системы развертывания с нуля, иногда вы должны удалить OpenStack из системы тяжелым способом. Приведем как:

Удалите все пакеты
Удалите все оставшиеся файлы
Удалите базы данных

Эти действия зависят от вашего исходного дистрибутива, но в целом вы должны искать команды "purge" в менеджере пакетов, подобные aptitude purge ~c $package. Затем вы можете осуществить поиск потерянных файлов в каталогах, упомянутых в данном руководстве. Для удаления должным образом базы данных, обратитесь к руководству, соответствующего используемому вами продукту.

Глава 10	Оглавление	Глава 12

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