Процедура реагирования в случае отказа узла гиперконвергенции

• Сервер виртуализации не отвечает на команды;
• Не удается изменить конфигурацию сервера виртуализации;
• Не удается подключиться к серверу виртуализации по протоколу SSH;
• Аварийная индикация в консоли управления сервером IPMI о сбое загрузочного диска;
• Аварийная индикация в интерфейсе веб управления виртуализации;
• Сервер виртуализации не отвечает на команды ping;
• Аварийная индикация в консоли управления сервером IPMI;
• Отсутствие физических следов работы сервера: шума, воздушного потока, тепловыделения, энергопотребления;

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

Последствия со стороны подсистемы виртуализации:

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

Последствия со стороны подсистемы хранения данных:

• Кластер системы хранения автоматически пометит вышедший из строя сервер как нерабочий. Новые блоки данных на указанный сервер назначаться не будут.
• Производительность дисковой подсистемы будет снижена;
• Отказоустойчивость дисковой подсистемы будет снижена.

1. Убедиться в доступности сервисов;
2. Проверить доступность интерфейсов веб администрирования “Р-Управление” и “Р-Хранилище”, в случае необходимости восстановить работоспособность контейнеров администрирования, руководствуясь соответствующими разделами данного руководства (см. Процедура реагирования при отказе интерфейса Р-Управление и Процедура реагирования при отказе интерфейса Р-Хранилище)
3. Проверить исправность кластера хранения данных через интерфейс “Р-Хранилище”. Большинство сервисов метаданных должно функционировать для корректной работы кластера
4. Убедиться в корректности работы подсистемы виртуализации;
5. Проверить корректность работы кластера высокой доступности:
   1. Все виртуальные машины кроме исключенных из конфигурации shaman перенесены на свободные узлы кластера. В случае необходимости перенести требуемые виртуальные машины вручную;
   2. Машины которые были запущены на подверженном сбою хосте перезапущены. В случае необходимости запустить необходимые виртуальные машины вручную;
   3. Операционная системы виртуальных машин, которые были перезапущены запустилась, прикладное ПО работает. В случае необходимости восстановить работу виртуальных машин, руководствуясь разделом соответствующим данного руководства (см. Процедура реагирования в случае повреждения данных виртуальной машины);
6. Выяснить причину сбоя и ожидаемое время восстановления.
7. Принудительно освободить сбойный сервер из конфигурации системы хранения только при наличии следующих факторов:
   1. Произошел сбой только одного сервера в кластере хранения;
   2. Число узлов в кластере хранения больше трёх;
   3. Большинство сервисов метаданных функционирует на текущий момент;
   4. Срок восстановления работоспособности сервера больше суток;
8. После удаления сервера из конфигурации кластера будет автоматически произведено изменение конфигурации защиты блоков данных и начнется перестроение с целью восстановления отказоустойчивости данных. Данный процесс возможен только при наличии свободных ресурсов и удовлетворения данных ресурсов требованиям политики хранения. Например хранилище с политикой избыточного кодирования 3+2 и областью отказа “Сервер” не может быть перестроено на количестве серверов меньше пяти.