OpenStack Nova: основные методы восстановления

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

Программная неисправность

Давайте рассмотрим самую простую, но, возможно, наиболее частую проблему. Например, если нам нужно обновить ядро или программное обеспечение, которое потребует перезагрузки хоста. Лучшим решением в этом случае будет перенести все виртуальные машины, работающие на этом сервере, на другие узлы кластера.
К сожалению, иногда это может оказаться невозможным по нескольким причинам, таким, как отсутствие общего хранилища для выполнения операции или ресурсов процессора / памяти для выделения под виртуальные машины. Единственный вариант – приостановить виртуальные машины на время процесса. Но как они должны быть запущены правильно после того, как прошла перезагрузка? Конечно, вы можете установить специальный флаг в nova.conf, и виртуальные машины запустятся автоматически после перезагрузки:

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

Данная команда пересоздаст и запустит Libvirt домен, используя XML виртуальной машины. Этот метод работает хорошо, если у вас нет подключенных удаленных томов, в противном случае nova boot выдаст ошибку. В этом случае вам придется загрузить домен вручную, используя команду virsh, подключить устройство ISCSI, создать XML-файл и прикрепить его к виртуальной машине, что превратится в кошмар, если у вас много виртуальных машин с подсоединенными томами.

Аппаратная неисправность

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

  1. Обновление поля host в БД для восстанавливаемых виртуальных машин.
  2. Запуск виртуальной машины на работающем compute узле.
  3. Поиск всех подключенных томов в базе данных.
  4. Поиск пути для устройства тома, подключение к нему с помощью ISCSI или какого-либо другого драйвера в случае необходимости.
  5. Присоединение его к гостевой системе.

Решение

Для этой и предыдущей ситуации мы разработали скрипт на python, который будет запускать виртуальную машину на хосте, где этот скрипт выполняется. Вы можете найти его на нашем Git репозитории: openstack-utils. Все что вам нужно, это скопировать скрипт на compute узле, где вы хотите восстановить виртуальную машину и выполнить:

Вы можете найти instance_id, используя команду nova list. Единственным ограничением является то, что виртуальная машина должна быть доступна на хост системе.
Конечно, при использовании OpenStack вам придется столкнуться с некоторыми сложностями, которые не удастся устранить с помощью данного скрипта. Например, если у вас конфигурация хранилища, которая обеспечивает зеркалирование данных между двумя compute узлами, и вам нужно восстановить виртуальную машину на третий узел, который не содержит ее на локальном жестком диске. Более сложные вопросы требуют более сложных решений, и мы работаем, чтобы охватить большинство из них.

Подписка на RSS канал
« »

Комментарии

Оставить комментарий
или