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

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

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

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

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


===== План реагирования =====
  - Убедиться в доступности сервисов;
  - Проверить доступность интерфейсов веб администрирования "Р-Управление" и "Р-Хранилище", в случае необходимости восстановить работоспособность контейнеров администрирования, руководствуясь соответствующими разделами данного руководства (см. [[domestic:rosplatforma:guide:dr:mitigation:r-man_webui_failure|Процедура реагирования при отказе интерфейса Р-Управление]] и [[domestic:rosplatforma:guide:dr:mitigation:vstor_webui_failure|Процедура реагирования при отказе интерфейса Р-Хранилище]])
  - Проверить исправность кластера хранения данных через интерфейс "Р-Хранилище". Большинство сервисов метаданных должно функционировать для корректной работы кластера {{domestic:rosplatforma:guide:dr:mitigation:host_failed:20221209-104121.png}}
  - Убедиться в корректности работы подсистемы виртуализации;
  - Проверить корректность работы кластера высокой доступности:
    - Все виртуальные машины кроме исключенных из конфигурации ''shaman'' перенесены на свободные узлы кластера. В случае необходимости перенести требуемые виртуальные машины вручную;
    - Машины которые были запущены на подверженном сбою хосте перезапущены. В случае необходимости запустить необходимые виртуальные машины вручную;
    - Операционная системы виртуальных машин, которые были перезапущены запустилась, прикладное ПО работает. В случае необходимости восстановить работу виртуальных машин, руководствуясь разделом соответствующим данного руководства (см. [[domestic:rosplatforma:guide:dr:mitigation:vm_hdd_corrupt|Процедура реагирования в случае повреждения данных виртуальной машины]]);
  - Выяснить причину сбоя и ожидаемое время восстановления.
  - Принудительно освободить сбойный сервер из конфигурации системы хранения только при наличии следующих факторов: 
    - Произошел сбой только одного сервера в кластере хранения;
    - Число узлов в кластере хранения больше трёх;
    - Большинство сервисов метаданных функционирует на текущий момент;
    - Срок восстановления работоспособности сервера больше суток;
  - После удаления сервера из конфигурации кластера будет автоматически произведено изменение конфигурации защиты блоков данных и начнется перестроение с целью восстановления отказоустойчивости данных. Данный процесс возможен только при наличии свободных ресурсов и удовлетворения данных ресурсов требованиям политики хранения. Например хранилище с политикой избыточного кодирования 3+2 и областью отказа "Сервер" не может быть перестроено на количестве серверов меньше пяти.