meta data for this page

Руководство аварийного восстановления Росплатформа

Возможные сценарии нештатных системы серверной виртуализации

Приоритет Проблема Симптомы Процедура реагирования Процедура восстановления
5 Сбой операционной системы виртуальной машины Виртуальная машина не отвечает по сети
Виртуальная машина не отвечает в консоли администрирования
Гостевые утилиты виртуальной машины не отвечают 		vm_os_failure vm_os_failure
5 Виртуальная машина не загружается После миграции виртуальная машина не загружает ОС
Выводится сообщение в консоли виртуальной машины об отсутсвующем устройстве загрузки
Виртуальная машина перезагружается циклически
Запускается мастер восстановления загрузки операционной системы Windows 		vm_os_boot_failure vm_os_boot_failure
4 Отказ интерфейса веб-управления Страница веб управления не загружается
Контейнер интерфейса веб управления не запущен
Адрес интерфейса веб управления не отвечает на команды ping 		r-man_webui_failure r-man_webui_failure
4 Потеря конфигурации виртуальной машины Виртуальная машина отсутствует в списке
В конфигурации виртуальной машины отутсвуют все необходимые виртуальные устройства 		vm_config_corrupt vm_config_corrupt
4 Повреждение данных виртуальной машины Операционная система ВМ не загружается
Файлы внутри ВМ повреждены
Регулярные сбои операционной системы ВМ
Виртуальная машина не включается 		vm_hdd_corrupt vm_hdd_corrupt
3 Отказ интерфейса управления из коммандной строки Команды выполняются с ошибками
Команды не найдены
Отсутствует подключение по SSH к серверу виртуализации 		rvirt_cli_failure rvirt_cli_failure

Возможные сценарии нештатных ситуаций системы хранения данных

Приоритет Проблема Симптомы Процедура реагирования Процедура восстановления
5 Отказ жесткого диска Аварийная индикация на диске сервера
Индикция о сбое диска в веб интерфейсе управления СХД; 		drive_failure drive_failure
5 Отказ интерфейса веб-управления Страница веб управления не загружается;
Контейнер интерфейса веб управления не запущен;
Адрес интерфейса веб управления не отвечает на команды ping; 		vstor_webui_failure vstor_webui_failure
4 Отказ порта кластерной сети хранения данных Индикация о сбое сетевого порта в веб интерфейсе управления СХД; vstor_net_failure vstor_net_failure
3 Отказ интерфейса командной строки мониторинга и управления Команды выполняются с ошибками;
Команды не найдены;
Отсутствует подключение по SSH к серверу хранения; 		vstorage_cli_failure vstorage_cli_failure

Возможные сценарии нештатных системы вычислительных серверов

Приоритет Проблема Симптомы Процедура реагирования Процедура восстановления
3 Единичный отказ зарезервированного компонента сервера Аварийная индикация в консоли управления сервером IPMI о сбое
Аварийная индикация на лицевой или тыльной стороне сервера
Индикация о сбое диска в интерфейсе Р-Хранилище
Снижение производительности одного из серверов
Повышенный уровень шума, воздушного потока, тепловыделения сервера 		not_fatal_hw_failure not_fatal_hw_failure
2 Отказ загрузочного устройства сервера Сервер виртуализации не отвечает на команды ping
Аварийная индикация в консоли управления сервером IPMI
Не удается подключиться к серверу виртуализации по протоколу SSH
Сервер не отвечает на команды интерфейса веб управления 		fatal_hardware_failure host_boot_volume_failure
2 Отказ сервера целиком Аварийная индикация в интерфейсе веб управления виртуализации
Сервер виртуализации не отвечает на команды ping
Аварийная индикация в консоли управления сервером IPMI
Не удается подключиться к серверу виртуализации по протоколу SSH
Отсутствие физических следов работы сервера: шума, воздушного потока, тепловыделения, энергопотребления 		fatal_hardware_failure fatal_hardware_failure

Процедуры реагирования в случае возникновения внештатных ситуаций

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

Симптомы

  • В консоли “Р-Хранилище” в разделе “Серверы” выводится сообщение о наличии проблем с одним из серверов.
  • В консоли “Р-Хранилище” в разделе “Оповещение” выводится сообщение о наличии сбойного накопителя.
  • Снижение производительности ввода-вывода
  • Индикация на лицевой панели сервера свидетельствует о сбое жесткого диска;

Причины

  • Жесткие диски и твердотельные накопители подвержены естественному износу и периодически могут выходить из строя в виду исчерпания ресурса или производственного брака;
  • Диск был ошибочно извлечен во время проведения запланированного обслуживания;

Влияние на доступность сервисов

  • В случае единичного отказа влияние на доступность сервисов не происходит;
  • При выходе из строя жесткого диска снижается общая надежность системы и в некоторых случаях одновременный выход из строя второго накопителя может приводить к потере данных;

План реагирования

  • Открыть консоль веб администрирования Р-Хранилище;

  • Перейти в раздел “Серверы” и выбрать сервер, на котором произошел сбой диска;

  • Выбрать сервер на котором произошла поломка, данный сервер отмечен знаком предупреждения;

  • Открыть раздел управления дисками, нажав на заголовок плитки “ДИСКИ;

  • В разделе управления дисками сервера определить роль диска который вышел из строя по значению в столбце “Статус”.

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

Отказавшие диски Хранилища

  • Выбрать отказавший диск с ролью Хранилище из списка и нажмите кнопку “Освободить” в правой части окна;

  • Отметить режим “Принудительное освобождение” и нажать кнопку “ОК”;

  • После высвобождения диска система произведет автоматическую балансировку блоков данных для восстановления требуемого уровня отказоустойчивости, если это возможно. Таким образом надежность системы, если это возможно, позволит избежать потери данных в случае выхода из строя еще одного накопителя.
  • Подключиться к консоли одного из серверов и проверить состояние процесса восстановления, путем вызова команды vstorage -c %CLUSTER_NAME% top, где %CLUSTER_NAME% - имя кластера. После запуска команды top нажать на клавиатуре клавишу v для отображения подробной информации о ходе репликации.

Проверить ход репликации в поле Repl IO. По завершении процесса восстановления отказоустойчивости статус кластера должен перейти в состояние OK, процесс репликации должен завершиться.

Отказавшие диски Кэша

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

Удалите все отказавшие диски хранения как описано выше в соответствующем разделе.

Отказавшие диски Метаданных

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

 

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

Симптомы

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

Причины

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

Влияние на доступность сервисов

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

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

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

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

План реагирования

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

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

Большинство компонентов сервера, которые подвержены частому выходу из строя или износу задублировано, поэтому выход из строя таких компонентов обычно не приводит к остановке работы сервера целиком и позволяет продолжить, возможно со снижением производительности, функционирование сервера до полного устранения неисправности. К задублированным компонентам сервера относятся:

  • Блок питания;
  • Модуль оперативной памяти;
  • Вентилятор охлаждения;
  • Загрузочный диск;
  • Диск для хранения данных;
  • Модуль SFP;
  • Сетевой порт;

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

Симптомы

  • Аварийная индикация в консоли управления сервером IPMI о сбое;
  • Аварийная индикация на лицевой или тыльной стороне сервера;
  • Индикация о сбое диска в интерфейсе Р-Хранилище;
  • Снижение производительности одного из серверов;
  • Повышенный уровень шума, воздушного потока, тепловыделения сервера;

Причины

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

Влияние на доступность сервисов

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

План реагирования

  1. Убедиться в работоспособности интерфейса администрирования Р-Управление, Р-Хранилище;
  2. Убедиться в работоспособности виртуальных машин на сбойном сервере а также их нормальном функционировании, в случае подозрения на нестабильность работы выполнить освобождение сервера от виртуальных машин путем миграции без остановки. Данная процедура описана в соответствующем разделе руководства администратора (см. Перенос виртуальной машины между узлами виртуализации);
  3. Проверить загрузку сервера виртуализации и достаточность имеющихся ресурсов для выполнения всех виртуальных машин, размещенных на данном сервере. В случае необходимости освободить ресурсы путём переноса работающих виртуальных машин на более свободные серверы виртуализации кластера;
 

Процедура реагирования при отказе интерфейса Р-Управление

Симптомы

  • Страница веб управления не загружается;
  • Контейнер va-mn интерфейса веб управления не запущен;
  • Адрес интерфейса веб управления не отвечает на команды ping;

Причины

  • Контейнер в котором выполняется интерфейс Р-Управление остановлен;
  • Не верно настроена сеть в контейнере управления;
  • Не верно настроена сеть на узле виртуализации;
  • Данные контейнера повреждены;

Влияние на доступность сервисов

  • Воздействия на прикладные информационные системы заказчика не оказывается;
  • Ограничены возможности администрирования подсистемы серверной виртуализации посредством веб-интерфейса;

План реагирования

  1. Произвести выполнение необходимых задач администрирования используя интерфейс командной строки;
  2. Обнаружить сервер виртуализации, на котором выполняется контейнер администрирования и перезапустить его, для этого:
    1. Получить список контейнеров сервера командой vzlist -an, найти сервер на котором выполняется контейнер va-mn;
    2. Перезапустить контейнер управления командой prlctl restart va-mn
 

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

Симптомы

  • Команды управления подсистемой виртуализации выполняются с ошибками или не выполняются вовсе на одном из серверов:
    • prlctl;
    • prlsrvctl;
    • vzlist
    • и другие;

Причины

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

Влияние на доступность сервисов

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

План реагирования

  1. Перенести запущенные виртуальные машины со сбойного сервера если это не было сделано автоматически командой shaman, для этого:
    1. Подключиться к консоли одного из исправно функционирующих серверов кластера виртуализации и выполнить поиск файлов виртуальной машины в на системе хранения данных, командой cat /mnt/vstorage/vols/datastores/*/*/config.pvs | grep -E "<VmName>|<VmUuid>"
    2. В списке выведенных UUID и имен виртуальных машин найти искомую ВМ и зафиксировать UUID виртуальных машин, выполняемых на сбойном узле;
    3. Для каждого UUID виртуальной машины, запущенной на сбойном узле выполнить команду prlctl migrate %SOURCE_HOST%/%UUID% localhost, где %SOURCE_HOST% - праметры подключения по протоколу SSH к сбойному серверу в формате: [user[:password]@]server_IP_address_or_hostname[:port], %UUID% - UUID машины, полученный на предыдущем шаге.
  2. В случае если перенос запущенных виртуальных машин не может быть осуществлен необходимо:
    1. Остановить все виртуальные машины, запущенные на сбойном сервере путем подключения к операционной системе виртуальной машины и завершения работы из ОС.
    2. Отключить питание сбойного сервера виртуализации;
    3. Подключиться к консоли одного из исправно функционирующих серверов кластера виртуализации, выполнить следующую команду для проверки того, что указанные виртуальные машины не находятся в состоянии восстановления: shaman -c %CLUSTERNAME% stat, где %CLUSTERNAME - имя кластера Р-Хранилище;
    4. Выполнить поиск файлов виртуальных машин на системе хранения данных, командой cat /mnt/vstorage/vols/datastores/*/*/config.pvs | grep -E "<VmName>|<VmUuid>"
    5. В списке выведенных UUID и имен виртуальных машин найти искомую ВМ и зафиксировать UUID виртуальных машин, выполняемых на сбойном узле;
    6. Для каждого UUID виртуальной машины, запущенной на сбойном узле выполнить следующую команду для поиска директории виртуальной машины find /vz /mnt -name %UUID%, где UUID - UUID виртуальной машины, вида 57b19198-5658-4fa5-9d8c-98b07d03e296;
    7. Для каждой найденной дирректории ВМ выполнить команду для импорта конфигурации на текущий сервер виртуализации: prlctl register %PATH% --preserve-uuid, где %PATH% - путь к дирректории с файлами ВМ;
    8. Запустить импортированные виртуальные машины командой prlctl start %UUID%, где UUID - UUID виртуальной машины, вида 57b19198-5658-4fa5-9d8c-98b07d03e296;
 

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

Симптомы

  • В среде “Р-Управление” отсутствует требуемая виртуальная машина;
  • В конфигурации виртуальной машины присутствуют не все необходимые виртуальные устройства;

Причины

  • Виртуальная машина была ошибочно удалена из консоли Р-Управление;
  • Конфигурационный файл виртуальной машины был изменен, поврежден или удален;

Влияние на доступность сервисов

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

План реагирования

  1. При возможности подключиться к операционной системе виртуальной машины, если она запущена и зафиксировать основную системную информацию:
    1. Количество vCPU;
    2. Объем оперативной памяти;
    3. Объем и количество подключенных логических дисков;
    4. Шина подключения загрузочного логического диска;
    5. MAC адрес, тип и количество сетевых адаптеров а так-же назначенные IP адреса;
  2. При возможности выполнить резервное копирование с использованием агента, установленного внутри операционной системы виртуальной машины или средствами приложения;
  3. Зафиксировать всю необходимую информацию для восстановления приложения на чистой операционной системе.

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

 

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

Симптомы

  • Операционная система ВМ не загружается;
  • Файлы внутри ВМ повреждены;
  • Виртуальная машина не включается;
  • Регулярные сбои операционной системы ВМ;

Причины

  • Повреждение файлов операционной системы внутри виртуальной машины в следствии некорректного завершения работы ВМ или работы механизма высокой доступности;
  • Повреждение файлов мгновенных снимков виртуальной машины и их удаление;
  • Недостаточное количество ресурсов подсистемы виртуализации;
  • Недостаточное количество ресурсов дисковой подсистемы;
  • Действия вредоносных программ внутри виртуальной машины;
  • Проблемы вызванные оборудованием сервера виртуализации;
  • Сбой системы хранения данных;

Влияние на доступность сервисов

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

План реагирования

  1. Исключить причину возникновения сбоя, связанную с изменением конфигурации виртуальной машины;
  2. Проверить наличие свободных ресурсов на подсистеме виртуализации, на сервере виртуализации и на подсистеме хранения данных, достаточных для запуска и функционирования виртуальной машины;
  3. Перенести подверженную сбою ВМ на другой сервер виртуализации с целью исключения причины возникновения сбоя, вызванной неисправностью аппаратных компонентов сервера;
  4. Произвести мониторинг состояния аппаратных ресурсов серверной подсистемы, мониторинг состояния системы хранения данных на предмет сбоев, командой vstorage -c %CLUSTER_NAME% top, где %CLUSTER_NAME% - имя кластера хранения данных.
  5. В случае если установлено что данные виртуальной машины безвозвратно испорчены необходимо переходить к процедуре восстановления;
 

Процедура реагирования при ошибке загрузки виртуальной машины

Симптомы

  • После миграции виртуальная машина не загружает операционную систему;
  • Выводится сообщение в консоли виртуальной машины об отсутствующем устройстве загрузки;
  • Запускается мастер восстановления загрузки операционной системы Windows;
  • Виртуальная машина перезагружается циклически;

Причины

  • Выбран не верный формат загрузки машины;
  • Выбран не поддерживаемый контроллер загрузочного диска;
  • Загрузочный диск поврежден;
  • Сбой восстановления из резервной копии;

Влияние на доступность сервисов

  • Все сервисы, расположенные на затронутой ВМ переходят в нерабочее состояние;
  • Часть данных затронутой ВМ возможно повреждена;

План реагирования

  1. При возможности переключить работу ИС на резервную виртуальную машину;
  2. Обнаружить причину возникновения сбоя использую журнал аудита виртуальной машины;
  3. В случае если ошибка была обнаружена в процессе миграции на среду виртуализации Р-Виртуализация со сторонних систем остановить работу по миграции данной машины и возобновить использование исходной ВМ;
 

Процедура реагирования при сбое операционной системы виртуальной машины

Симптомы

  • Операционная система виртуальной машины не отвечает на запрос ping;
  • Не удается удаленно подключиться к операционной системе виртуальной машины;
  • Виртуальная машина находится в состоянии “Пауза” в среде виртуализации Р-Виртуализация;
  • При возобновлении работы виртуальной машины из режима “Пауза” в скором времени машина снова встаёт на паузу;

Причины

  • Сбой в работе операционной системы виртуальной машины;
  • Сбой в работе прикладного ПО виртуальной машины;
  • Неверная конфигурация виртуального оборудования машины;
  • Сбой в работе гипервизора;

Влияние на доступность сервисов

  • Все сервисы, расположенные на затронутой ВМ переходят в нерабочее состояние;
  • Часть данных затронутой ВМ возможно повреждена;

План реагирования

  1. Перезагрузить виртуальную машину;
  2. Проверить целостность данных и работоспособность установленных ИС;
 

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

Симптомы

  • Команды vstorage и shaman выполняются с ошибками или не выполняются совсем;
  • Команды vstorage и shaman не найдены;

Причины

  • Недостаточный уровень прав пользователя;
  • Узел не подключен к кластеру хранения;
  • Неверно указано или не указано имя кластера хранения в параметрах запуска команд;
  • Закончилось свободное место на загрузочном диске ОС;
  • Операционная система узла хранения повреждена;

Влияние на доступность сервисов

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

План реагирования

Отказ интерфейса командной строки СХД не требует немедленного реагирования. Администрирование системы хранения данных производится с использованием веб-интерфейса Р-Хранилище. В случае необходимости отслеживания состояния СХД из командной строки необходимо подключиться к другому серверу кластера и провести работы с него.

 

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

Симптомы

  • Индикация о сбое сетевого порта в веб интерфейсе управления СХД;
  • Индикация о сбое сетевого порта на оборудовании сети передачи данных;
  • Сообщение о сбое в системе мониторинга;

Причины

  • Изменение настроек сетевого порта со стороны сервера;
  • Изменение настроек сетевого порта со стороны активного сетевого оборудования;
  • Повреждение коммуникационного кабеля;
  • Повреждение модуля SFP;
  • Отключение кабеля из разъема;
  • Коммуникационный кабель не до конца усажен в разъеме;

Влияние на доступность сервисов

  • Возможно снижение производительности работы подсистемы хранения данных в отдельных случаях;

План реагирования

  1. Проверить отсуствие аварийной индикации питания всего оборудования;
  2. Убедится, что всё оборудование включено;
  3. Убедиться в доступности сервисов;
  4. Убедиться в достаточной производительности сервисов;
  1. Обнаружить сбойную пару сетевых портов руководствуясь информацией, полученной в интерфейсе администрирования Р-Хранилище, информацией с активного сетевого оборудования. Один порт принадлежит серверу, второй порт принадлежит активному сетевому оборудованию.
  2. Проверить и при необходимости привести к проектному решению подключение всех информационных кабелей сервера на котором наблюдается неисправность;
  3. Переподключить все кабели соединяющие активное сетевое оборудование и порт сервера на котором наблюдается неисправность.
  4. Проверить корректность выполненных настроек на портах сервера с использованием команды nmtui;
 

Процедура реагирования при отказе интерфейса Р-Хранилище

Симптомы

  • Страница веб управления Р-Хранилище не загружается;
  • Контейнер vstorage-ui интерфейса веб управления не запущен;
  • Адрес интерфейса веб управления не отвечает на команды ping;

Причины

  • Контейнер в котором выполняется интерфейс Р-Хранилище остановлен;
  • Не верно настроена сеть в контейнере управления;
  • Не верно настроена сеть на узле виртуализации;
  • Данные контейнера повреждены;

Влияние на доступность сервисов

  • Воздействия на прикладные информационные системы заказчика не оказывается;
  • Ограничены возможности администрирования подсистемы хранения данных посредством веб-интерфейса;

План реагирования

  1. Произвести выполнение необходимых задач администрирования используя интерфейс командной строки;
  2. Обнаружить сервер виртуализации, на котором выполняется контейнер администрирования и перезапустить его, для этого:
    1. Получить список контейнеров сервера командой vzlist -an, найти сервер на котором выполняется контейнер vstorage-ui;
    2. Перезапустить контейнер управления командой prlctl restart vstorage-ui
 

r:

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

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

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

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

Восстановление отказавшего диска с ролью "Хранилище"

Данная процедура должна выполняться после доставки сменного накопителя.

  • Заменить сбойный накопитель в сервере исправным;
  • Открыть интерфейс управления Р-Хранилище;

  • Перейти в раздел “Серверы” и выбрать сервер, диск в котором был заменен;

  • Открыть раздел управления дисками, нажав на заголовок плитки “ДИСКИ;

  • Выбрать свободный диск из списка и в правой части окна нажать кнопку “Назначить”;

  • Выбрать роль “Хранилище” и установить режим кэширования в “Использовать SSD диск…” из списка и нажать кнопку “Готово”;

  • Дождаться завершения процесса добавления диска к конфигурации хранилища.

Проверка корректности создания файла журнала

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

В случае возникновения данной проблемы после замены диска объем занятого дискового пространства на дисках SSD распределен не равномерно (см. пример ниже).

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

  • Получить имена CS для которых созданы журналы на SSD дисках командой ls -alh /vstorage/*/journal
  • Задать размер журнала для CS, командой vstorage -c %CLUSTER_NAME% configure-cs -r $f -s %SIZE%, где %CLUSTER_NAME% - имя кластера, %SIZE% объем файла журнала.

Объем файла журнала должен быть рассчитан исходя из следующих принципов:

  • Полезный объем каждого SSD диска должен быть использован на 80%;
  • На каждом SSD диске должно быть максимально равномерное количество журналов одинакового объема.

Восстановление отказавшего диска с ролью "Кэш"

  1. Заменить сбойный накопитель;
  2. Открыть интерфейс управления Р-Хранилище;
  3. Перейти в раздел “Серверы” и выбрать сервер, диск в котором был заменен;
  4. Открыть раздел управления дисками, нажав на заголовок плитки “ДИСКИ;
  5. Выбрать свободный диск, предназначенный для кэширования из списка и в правой части окна нажать кнопку “Назначить”;
  6. Выбрать роль Кэш из списка и нажать кнопку “Готово”;
  7. Выбрать диски, которые были освобождены в результате выполнения процедуры реагирования при сбое диска кэширования и в правой части окна нажать кнопку “Назначить”
  8. Выбрать роль Хранилище и требуемый уровень из списка и нажать кнопку “Готово”;

Восстановление отказавшего диска с ролью "Метаданные"

  • При удалении и создании дополнительных дисков метаданных необходимо убедиться, что большинство дисков (больше половины) метаданных в кластере функционирует.
  • Неработающие диски метаданных рекомендуется освободить из кластера как можно скорее (например, сразу после замещения неисправного диска новым), чтобы все диски метаданных были запущены и в рабочем состоянии находилось большинство из них.
  • Например, если в кластере работают 3 диска метаданных, 1 диск метаданных выходит из строя и на смену ему в кластер добавляется новый диск метаданных, то общее число серверов метаданных становится 4, один из которых выключен.
  • При сбое еще одного диска метаданных только 2 диска метаданных останутся запущенными, и кластер станет недоступен, так как большинство (3 работающих диска метаданных) не достигнуто.

Восстановление выделенного диска с метаданными производится в следующей последовательности:

  1. Открыть интерфейс управления Р-Хранилище;
  2. Перейти в раздел “Серверы” и выбрать сервер на котором произошел сбой диска с ролью “Метаданные”.
    1. Открыть раздел управления дисками, нажав на заголовок плитки “ДИСКИ;
    2. Выбрать сбойный диск с метаданными из списка и в правой части окна нажать кнопку “Освободить”;
  3. Заменить сбойный диск;
    1. Выбрать новый диск из списка и в правой части окна нажать кнопку “Назначить”;
    2. Выбрать роль “Метаданные” из списка и нажать кнопку “Готово”;
  4. Перейти на вкладку “Сводка” и проверить суммарное количество сервисов метаданных должно быть равно трём или пяти. Все сервисы метаданных в кластере должны быть в состоянии “Исправен” - Заменить сбойный диск.

Восстановление отказавшего диска с ролью "Система+Метаданные"

Если на физическом сервере есть системный диск объемом более 100ГБ, этому диску можно дополнительно назначить роль Метаданные или Хранилище.

  • Роль Система+Метаданные рекомендуется назначать SSD-диску.
  • Назначение обеих ролей HDD-диску приведет к снижению производительности, и этот диск можно будет использовать только для “холодных” данных (например, для архивирования).
  • Роль “Система” нельзя совмещать с ролями “Кэш” и “Метаданные+Кэш”. При одновременном назначении данных ролей операции ввода-вывода операционной системы и приложений будут конкурировать с операциями ввода-вывода, генерируемыми в процессе журналирования, тем самым снижая производительность системы

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

Восстановление отказавшего диска с ролью "Метаданные+Кэш"

Серверов в кластере более 5 штук

При числе серверов в кластере более 5 штук без выделенного диска с метаданными:

  1. Открыть интерфейс управления Р-Хранилище;
  2. Перейти в раздел “Серверы” и выбрать сервер на котором нет дисков с назначенной ролью “Метаданные”.
    1. Открыть раздел управления дисками, нажав на заголовок плитки “ДИСКИ;
    2. Выбрать подходящий диск из списка и в правой части окна нажать кнопку “Назначить”;
    3. Выбрать роль “Метаданные” из списка и нажать кнопку “Готово”;
  3. Перейти в раздел “Серверы” и выбрать сервер на котором произошел сбой диска с ролью “Метаданные”.
    1. Открыть раздел управления дисками, нажав на заголовок плитки “ДИСКИ;
    2. Выбрать сбойный диск с метаданными из списка и в правой части окна нажать кнопку “Освободить”;
  4. Перейти на вкладку “Сводка” и проверить суммарное количество сервисов метаданных должно быть равно трём или пяти. Все сервисы метаданных в кластере должны быть в состоянии “Исправен” - Заменить сбойный диск.
    1. Роль метаданные на указанный диск не назначается;
    2. Назначить соответствующую роль новому диску, руководствуясь разделами данной методики.

Серверов в кластере менее 5 штук

При числе серверов в кластере менее 5 штук:

  1. Открыть интерфейс управления Р-Хранилище;
  2. Перейти в раздел “Серверы” и выбрать сервер на котором нет дисков с назначенной ролью “Метаданные”.
    1. Открыть раздел управления дисками, нажав на заголовок плитки “ДИСКИ;
    2. Выбрать подходящий диск из списка и в правой части окна нажать кнопку “Назначить”;
    3. Выбрать роль “Метаданные” из списка и нажать кнопку “Готово”;
  3. Перейти в раздел “Серверы” и выбрать сервер на котором произошел сбой диска с ролью “Метаданные”.
    1. Открыть раздел управления дисками, нажав на заголовок плитки “ДИСКИ;
    2. Выбрать сбойный диск с метаданными из списка и в правой части окна нажать кнопку “Освободить”;
  4. Перейти на вкладку “Сводка” и проверить суммарное количество сервисов метаданных должно быть равно трём. Все сервисы метаданных в кластере должны быть в состоянии “Исправен”
 

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

Процедура восстановления после отказа узла гиперконвегренции включает в себя следующие основные шаги:

  1. Восстановление работоспособности аппаратных компонентов сервера;
  2. Восстановление коммутации;
  3. Восстановление операционной системы ;
  4. Восстановление настроек системы;

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

Для восстановления работоспособности серверной вычислительной системы необходимо руководствоваться следующим планом:

  1. Используя приведенные процедуры восстановления в разделе “Мониторинг с использованием средств удаленного администрирования IPMI” руководства администратора СВС локализовать проблему.
  2. При наличии сервисного контракта обратиться к производителю оборудования или Подрядчику по договору для получения детального плана действий.
  3. При проведении работ руководствоваться соответствующими разделами руководства администратора СВС по замене компонентов сервера и актуальными версиями руководства администратора производителя оборудования.

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

Восстановление операционной системы сервера

Восстановление узла после замены загрузочного диска подразумевает необходимость полной переустановки операционной системы узла виртуализации и подключение данного узла к кластеру системы хранения и интерфейса администрирование “Р-Управление”. В данном случае необходимо руководствоваться следующей последовательностью действий:

  1. Получить актуальный дистрибутив системы виртуализации путем скачивания с репозитория производителя по адресу в сети Интернет: http://updates.rosplatforma.ru/r-virtualization/releases/;
  2. Установить операционную систему следуя соответствующему разделу руководства администратора (см. Руководство по установке дистрибутива системы виртуализации Росплатформа);
  3. Произвести базовые настройки в соответствии с Паспортом системы;

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

Ввод восстановленного узла в эксплуатацию

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

  1. Подключить сервер к кластеру системы следуя соответствующему разделу руководства администратора (см. Добавление узла в кластер хранения);
  2. Если операционная система была переустановлена необходимо повторно подключить сервер к интерфейсу централизованного управления “Р-Управление” следуя соответствующему разделу руководства администратора (см. Добавление узла в подсистему виртуализации);

Базовые настройки добавляемого узла виртуализации

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

  1. Установить значение «xmit_hash_policy» равное «layer3+4», командой nmcli con mod id %BOND_NAME% bond.options xmit_hash_policy=layer2+3, где %BOND_NAME% - имя сетевого агрегата.
  2. Включить механизм высокой доступности на сервере, командой hastart -c %RSTOR_CLUSTER_NAME% -n 10.56.110.0/24, где %RSTOR_CLUSTER_NAME% - имя кластера системы хранения, 10.56.110.0/24 - подсеть синхронизации системы хранения.

Настройка месторасположения виртуальных машин

В интерфейсе Р-Управление, после добавления сервера необходимо выполнить следующие базовые настройки:

  • В главном меню развернуть раздел “Инфраструктура” и выбрать требуемый физический сервер из списка;
  • Нажать на названии сервера для перехода в режим обзора основных показателей сервера;
  • В верхнем меню нажать кнопку “Настроить” и выбрать раздел “Настройка хоста для виртуальных сред”;

В окне “Изменение настроек хоста для виртуальных сред” необходимо задать следующие параметры:

  • Выбрать пул хранения или локальную директорию на сервере для хранения виртуальных дисков и конфигурационных файлов ВМ в разделе “Папка для виртуальных машин”;
  • Выбрать пул хранения или локальную директорию на сервере для хранения файлов контейнеров в разделе “Папка для контейнеров”;
  • Выбрать пул хранения или локальную директорию на сервере для резервных копий в разделе “Папка для резервных копий”;

Распределение нагрузки на добавляемый сервер

После выполнения процедур по базовой настройке узла виртуализации и указания параметров хранилища данных в интерфейсе “Р-Управление” необходимо вручную распределить нагрузку виртуальных машин на вводимый в эксплуатацию хост виртуализации.

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

 

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

  • Операционная система гипервизора запускается и работает с загрузочного диска узла виртуализации. В случае выхода из строя данного накопителя функционирование ОС завершается с ошибкой.
  • На пяти узлах кластера хранения запущен сервис метаданных кластера который отвечает за хранение конфигурации системы и критичен для ее функционирования. В случае потери большинства узлов метаданных доступ к кластеру останавливается.

Зафиксировать параметры настройки узла

Для восстановления узла необходимо подготовить карту настроек оборудования, при необходимости данная информация может быть собрана в интерфейсе “Р-хранилище” и “Р-Виртуализация” с вышедшего из строя сервера. Среди обязательных параметров для переустановки операционной системы находятся следующие:

  • Конфигурация сетевых интерфейсов, включая:
    • Методы объединения интерфейсов в агрегаты;
    • Метод балансировки нагрузки в агрегате;
    • DNS имя, IP адрес, шлюз по умолчанию, DNS сервер, доменный суффикс;
    • Адрес сервера точного времени;
    • Тип и расположение диска используемого для установки ОС.

Восстановить работоспособность сервера

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

Установка системы виртуализации

После восстановления сервера необходимо произвести установку системы виртуализации согласно инструкции администратора (см. Руководство по установке дистрибутива системы виртуализации Росплатформа).

При отсутствии необходимых значений во время установки необходимо руководствоваться сущностью вышедшего из строя сервера в интерфейсе “Р-Управление” и “Р-Хранилище”.

Подключение сервера к существующему кластеру

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

 

Устранение неисправностей с загрузкой виртуальной машины

Проблема "inaccessible boot device"

Скорее всего, интерфейс подключения, выбранный по умолчанию, может быть не верным, и гостевая ОС не сможет загружаться, поэтому попробуйте разные варианты подключения диска:

  • IDE
  • SCSI
  • VirtIO

Например виртуальная машина созданная в VMware с SCSI адаптером LSI Logic SAS запускается только с диском в среде Р-виртуализация подключенным по шине IDE.

Переключение зарузочного диска на шину virtio

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

  • добавить в виртуальную машину дополнительный виртуальный диск, подклчюенный по шине virtio;

  • установить гостевые утилиты;
  • проверить что добавленный диск и контроллер VIRTIO отображаются в диспетчере устройств и на них успешно установлены драйверы.

  • удалить временный диск и сменить шину загрузочного диска на Virtio;
  • перезагрузить машину для применения изменений;

  • операционная система загрузилась с диска подключенного по шине virtio.

Проблема "UEFI"

Если в гипервизоре-экспортёре была установлена функция загрузки «uefi», то необходимо включить эту же функцию после конвертации ВМ с помощью следующей команды: prlctl set <VM_name> --efi-boot on или через веб-интерфейс

 

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

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

К задублированным компонентам сервера относятся:

  • Блок питания;
  • Модуль оперативной памяти;
  • Вентилятор охлаждения;
  • Загрузочный диск;
  • Диск для хранения данных;
  • Модуль SFP;
  • Сетевой порт;

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

В случае замены диска для хранения данных необходимо дополнительно выполнить процедуру восстановления в интерфейсе Р-Хранилище. Подробное описание действий приведено в соответствующем разделе данного руководства (см. Процедура восстановления в случае единичного отказа накопителя).

 

Процедура восстановления при отказе интерфейса Р-Управление

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

  1. Проверить наличие и корректность установленной лицензии на продукт Р-Виртуализация 1) и при необходимости установить новый ключ, для этого:
    1. Подключиться к командной строке одного из серверов кластера и проверить наличие и состояние лицензии командой vzlicview
    2. При необходимости установить новый лицензионный ключ командой vzlicload;
  2. Проверить корректность сетевых настроек контейнера и при необхлодимости изменить их, для этого:
    1. Подключиться к командной строке сервера, на котором выполняется контейнер управления va-mn;
    2. Получить параметры контейнера командой prlctl list -i va-mn;
    3. При необходимости задать параметры сетевого подключения командой prlctl set va-mn
  3. Подключиться к консоли контейнера va-mn и провести диагностику неисправности операционной системы контейнера, для этого:
    1. Подключиться к командной строке сервера, на котором выполняется контейнер управления va-mn;
    2. Подключиться к контейнеру командой prlctl enter va-mn;
    3. Провести анализ журналов командой journalctl -xe и поиск неисправности контейнера;
  4. Развернуть контейнер управления из резервной копии, для этого необходимо:
    1. Получить VM_UUID идентификатор контейнера va-mn командой: prlctl backup-list -f --vmtype ct | grep -e 'va-mn' -B1;
    2. Восстановить резервную копию контейнера командой prlctl restore <VM_UUID>;

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

 

Процедура восстановления в случае отказа интерфейса командной строки узла подсистемы виртуализации

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

Необходимо локализовать причину возникновения неисправности, для этого необходимо:

  1. Проверить что требуемая команда запускается от имени пользователя с достаточными правами. Запустить команду от имени суперпользователя root;
  2. Проверить состояние операционной системы сервера гипервизора используя команды:
    1. df -h;
    2. journalctl -xe;
    3. dmesg | less;
    4. free -h;
  3. Проверить состояние загрузочного диска сервера командой: smartctl -a %DEVICE_NAME%, где %DEVICE_NAME% имя загрузочного устройства, раздел которого подключен в качестве корневой точки монтирования, вида /dev/sda;

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

 

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

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

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

Виртуальная машина еще выполняется

В случае если виртуальная машина выполняется, но при этом информация о данной ВМ отсутствует в консоли Р-Управление необходимо выполнить следующие действия:

  1. По mac адресу сетевых интерфейсов виртуальной машины проверить что машина выполняется на одном из серверов кластера Р-Виртуализация, который управляется указанным интерфейсом Р-Управление;
  2. Подключиться к консоли указанного сервера и вывести список всех виртуальных машин командой prlctl list -a. Указанная машина должна отображаться со статусом invalid.
  3. Зафиксировать UUID виртуальной машины из вывода команды prlctl list;
  4. Найти директорию с файлами виртуальной машины командой: find /vz /mnt -name %UUID%, где UUID - UUID виртуальной машины, вида 57b19198-5658-4fa5-9d8c-98b07d03e296;
  5. Перейти в директорию с файлами виртуальной машины;
  6. Проверить наличие резервной копии файла конфигурации с именем config.pvs.backup в указанной директории;
    1. При наличии резервной копии восстановить данные командой cp ./config.pvs.backup ./config.pvs;
    2. При отсутствии файла резервной копии создать новый пустой конфигурационный файл командой touch ./config.pvs;
  7. После указанных манипуляций запущенная виртуальная машина должна отображаться в интерфейсе Р-Управление;
  8. Когда станет возможным необходимо остановить виртуальную машину из консоли Р-Управление, если она еще выполняется. Эта операция воссоздаст конфигурационный файл на хранилище.

Виртуальная машина не доступна по сети

  1. Подключиться к консоли одного из серверов кластера виртуализации и выполнить поиск файлов виртуальной машины на системе хранения данных, командой cat /mnt/vstorage/vols/datastores/*/*/config.pvs | grep -E "<VmName>|<VmUuid>"
  2. В списке выведенных UUID и имен виртуальных машин найти искомую ВМ и зафиксировать UUID виртуальной машины;
  3. Найти директорию с файлами виртуальной машины командой: find /vz /mnt -name %UUID%, где UUID - UUID виртуальной машины, вида 57b19198-5658-4fa5-9d8c-98b07d03e296;
  4. Перейти в директорию с файлами виртуальной машины;
  5. Проверить наличие файла конфигурации config.pvs или резервной копии файла конфигурации с именем config.pvs.backup в указанной директории;
    1. При отсутствии файла конфигурации и наличии резервной копии восстановить данные командой cp ./config.pvs.backup ./config.pvs;
    2. При отсутствии указанных файлов необходимо создать новый пустой конфигурационный файл командой touch ./config.pvs;
  6. После указанных манипуляций в интерфейсе Р-Управление необходимо нажать правой кнопкой по однму из физических серверов и выбрать пункт меню “Регистрация виртуальной машины” ;
  7. В диалоговом окне необходимо ввести путь расположения файлов виртуальной машины и нажать кнопку “ОК”.
 

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

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

  1. Отключить питание виртуальной машины;
  2. Сохранить текущее состояние виртуальной машины на случай сбоя восстановления, для этого необходимо воспользоваться одним из приведенных способов:
    1. Создать резервную копию подверженной сбою виртуальной машины, например с использованием встроенного механизма резервного копирования среды управления “Р-Управления”
    2. Создать резервную копию средствами системы резервного копирования предприятия;
    3. Выполнить клонирование виртуальной машины средствами командной строки подсистемы виртуализации используя команду prlctl cone %MACHINE_NAME% --name %MACHINE_NAME%.backup, где %MACHINE_NAME% - имя виртуальной машины.
  3. Восстановить данные из резервной копии подверженной сбою виртуальной машине на момент консистентного состояния заменив существующую ВМ, для этого необходимо воспользоваться одним из приведенных способов в зависимости от наличия копий:
    1. Восстановить виртуальную машину из резервной копии, созданной встроенным механизмом резервного копирования Р-Управления следуя указаниям руководства Администратора (см. Восстановление виртуальной машины из резервной копии);
    2. Восстановить виртуальную машину из резервной копии, созданной системой резервного копирования следуя указаниям руководства Администратора по используемой системе резервного копирования предприятия;
    3. Откатить виртуальную машину на мгновенный снимок, созданной встроенным в командной строке гипервизора, следуя указаниям руководства Администратора (см. Управление мгновенными снимками виртуальной машины);

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

 

Процедура восстановления при ошибке загрузки виртуальной машины

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

  1. Откатить изменения в конфигурации виртуального оборудования и прикладного ПО которые могли стать причиной возникновения сбоя, для этого:
    1. Выключить виртуальную машину;
    2. Создать резервную копию текущего состояния ВМ;
    3. По одному откатить выполненные изменения виртуального оборудования, которые возможно, могли привести к данной проблеме;
    4. По одному откатить выполненные изменения прикладного ПО, которые возможно, могли привести к данной проблеме;
  2. Восстановить рабочее состояние виртуальной машины из резервной копии, проверить корректность функционирования машины и локализовать изменения, приведшие к сбою, для этого:
    1. Выключить виртуальную машину;
    2. Создать резервную копию текущего состояния ВМ;
    3. Выбрать самую актуальную, стабильную копию указанной ВМ и произвести ее восстановление;
    4. Проанализировать отличия текущего состояния ВМ и состояния в котором работа машины приводит к данной ошибке, локализовать причину сбоя.
    5. Устранить причину возникновения ошибки при возможности;
  3. Если локализовать причину сбоя не удается, но восстановленная из резервной копии машина работает исправно необходимо восстановить данные ИС из резервной копии приложения, при наличии или воссоздать их;

Проблемы вызванные миграцией со сторонних гипервизоров

Проблема "inaccessible boot device"

Скорее всего, интерфейс подключения, выбранный по умолчанию, может быть не верным, и гостевая ОС не сможет загружаться, поэтому попробуйте разные варианты подключения диска:

  • IDE
  • SCSI
  • VirtIO

Например виртуальная машина созданная в VMware с SCSI адаптером LSI Logic SAS запускается только с диском в среде Р-виртуализация подключенным по шине IDE.

Переключение зарузочного диска на шину virtio

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

  • добавить в виртуальную машину дополнительный виртуальный диск, подклчюенный по шине virtio;

  • установить гостевые утилиты;
  • проверить что добавленный диск и контроллер VIRTIO отображаются в диспетчере устройств и на них успешно установлены драйверы.

  • удалить временный диск и сменить шину загрузочного диска на Virtio;
  • перезагрузить машину для применения изменений;

  • операционная система загрузилась с диска подключенного по шине virtio.

Проблема "UEFI"

Если в гипервизоре-экспортёре была установлена функция загрузки «uefi», то необходимо включить эту же функцию после конвертации ВМ с помощью следующей команды: prlctl set <VM_name> --efi-boot on или через веб-интерфейс

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

 

Процедура восстановления при сбое операционной системы виртуальной машины

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

  1. Проанализировать журнал событий операционной системы, при необходимости обратиться к производителю ОС для устранения неисправности в коде ОС;
  2. Проверить наличие необходимых процессорных ресурсов и объема оперативной памяти для функционирования виртуальной машины, и при необходимости увеличить их, для этого:
    1. Проверить соответствие системным требованиям конфигурации ВМ;
    2. Проверить загрузку физического сервера виртуализации и наличие свободных ресурсов для выполнения указанной ВМ;
    3. Проверить работоспособность и среднее время отклика Р-Хранилища;
  3. Откатить изменения в конфигурации виртуального оборудования и прикладного ПО которые могли стать причиной возникновения сбоя, для этого:
    1. Выключить виртуальную машину;
    2. Создать резервную копию текущего состояния ВМ;
    3. По одному откатить выполненные изменения виртуального оборудования, которые возможно, могли привести к данной проблеме;
    4. По одному откатить выполненные изменения прикладного ПО, которые возможно, могли привести к данной проблеме;
  4. Восстановить рабочее состояние виртуальной машины из резервной копии, проверить корректность функционирования машины и локализовать изменения, приведшие к сбою, для этого:
    1. Выключить виртуальную машину;
    2. Создать резервную копию текущего состояния ВМ;
    3. Выбрать самую актуальную, стабильную копию указанной ВМ и произвести ее восстановление;
    4. Проанализировать отличия текущего состояния ВМ и состояния в котором работа машины приводит к данной ошибке, локализовать причину сбоя.
    5. Устранить причину возникновения ошибки при возможности;
  5. Если локализовать причину сбоя не удается, но восстановленная из резервной копии машина работает исправно необходимо восстановить данные ИС из резервной копии приложения, при наличии или воссоздать их;

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

 

Восстановление виртуальной машины из резервной копии КиберБэкап

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

Для доступа к настройкам оборудования виртуальной машины выполните следующие действия:

  • нажмите настроить;
  • выберите пункт меню “Настройки оборудования”.

Подключите созданный загрузочный образ Кибербэкап, для этого:

  • перейдите в раздел “Устройства - CD/DVD-ROM”;
  • в поле “Образ диска библиотеки” выберите созданный файл образа;
  • нажмите “ОК”.

Дождитесь завершения задачи по подключиния образа и включите виртуальную машину нажав кнопку меню “Использование - Запустить”.

Откройте консоль виртуальной машины, для этого:

  • перейдите на вкладку “Консоль”;
  • нажмите кнопку “Detach Console” для запуска консоли в отдельном окне браузера;

В меню загрузочного диска выберите пункт “Cyber Backup” и нажмите на него левой клавишей мыши. Если мышь “не слушается” нажмите F10 и переместите курсор клавишами со стрелками и нажмите клавишу “Enter” вместо левой клавиши мыши.

Окно запуска агента представлено на рисунке ниже.

Для настройки сети выберите раздел “Изменить параметры сети”

Для продолжения операции по восстановлению выберите режим “Управляйте данной машиной локально”.

Для запуска процесса восстановления выберите режим “Восстановление данных”.

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

Укажите путь к хранилищу резервных копий и нажмите клавишу “Обзор” для проверки ввода.

Введите учетные данные пользователя с правами на чтение.

После появления зеленого указателя рядом со строкой пути - нажмите “ОК” чтобы подтвердить выбор сервера.

Выбрать резервную копию, для этого:

  • найти файл резервной копии в списке;
  • раскрыть меню файла;
  • выбрать последнюю резервную копию из списка;
  • переключить вид резервной копии на “Диски”, нажав ссылку в разделе “Содержимое резервной копии”;
  • отметить все диски для восстановления;

Убедиться что сопоставление восстанавливаемых копий и существующих дисков виртуальной машины прошло успешно и нажать “OK” для запуска процесса восстановления. Следить за ходом процесса восстановления можно на вкладке “ход выполнения”.

Результат восстановления будет отображен на вкладке “Задание”.

Для выхода из загрузочного диска нажмите меню “Действие” и выберите пункт “Выход”.

Нажмите кнопку “Выключить” для выключения виртуальной машины.

Дождитесь выключения виртуальной машины в консоли Р-Виртуализация.

Для доступа к настройкам оборудования виртуальной машины выполните следующие действия:

  • нажмите настроить;
  • выберите пункт меню “Настройки оборудования”.

Отключите загрузочный образ Кибербэкап, для этого:

  • перейдите в раздел “Устройства - CD/DVD-ROM”;
  • в поле “Образ диска библиотеки” выберите “–Выбрать–”;
  • нажмите “ОК”.

 

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

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

Необходимо локализовать причину возникновения неисправности, для этого необходимо:

  1. Проверить что команда запускается от имени пользователя с достаточными правами. Запустить команду от имени суперпользователя root;
  2. Проверить что сервер, с которого запускается команда мониторинга подключен к кластеру хранения и отображается в консоли веб администрирования “Р-Хранилище”;
  3. Проверить наличие сетевой связанности с остальными узлами кластера;
  4. Проверить состояние операционной системы сервера гипервизора используя команды:
    1. df -h;
    2. journalctl -xe;
    3. dmesg | less;
    4. free -h;
  5. Проверить состояние загрузочного диска сервера командой: smartctl -a %DEVICE_NAME%, где %DEVICE_NAME% имя загрузочного устройства, раздел которого подключен в качестве корневой точки монтирования, вида /dev/sda;

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

 

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

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

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

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

ip a | less

На порту сервера "Нет носителя"

Состояние “Нет носителя” (“NO-CARRIER”) выводится когда сетевой порт сервера не соединен с активным сетевым оборудованием.

  1. Обнаружить сбойную пару сетевых портов руководствуясь информацией, полученной в интерфейсе администрирования Р-Хранилище, информацией с активного сетевого оборудования. Один порт принадлежит серверу, второй порт принадлежит активному сетевому оборудованию.
  2. Проверить и при необходимости привести к проектному решению подключение всех информационных кабелей сервера на котором наблюдается неисправность;
  3. Восстановить настройки активного сетевого оборудования и сервера виртуализации в соответствии с проектным решением;
  4. Переподключить все кабели соединяющие активное сетевое оборудование и порт сервера на котором наблюдается неисправность;
  5. Заменить соединительные кабели при подозрении на повреждение;
  6. Заменить приемо-передающий модуль SFP если используется;
  7. Очистить оптические разъемы соединительных панелей, если используются;

Сигнал есть, отсутствует сетевая связанность

  1. Проверить корректность выполненных настроек на портах сервера с использованием команды nmtui;
  2. Проверить наличие связанности с серверами кластера командой ping xxx.xxx.xxx.xxx где xxx.xxx.xxx.xxx адрес кластерной сети хранения данных одного из серверов;
  3. Проверить журнал аппаратных событий командой dmesg | less с целью поиска и устранения аппаратной неисправности сервера;
 

Процедура восстановления при отказе интерфейса веб администрирования Р-Хранилище

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

  1. Проверить наличие и корректность установленной лицензии на продукт Р-Виртуализация 2) и при необходимости установить новый ключ, для этого:
    1. Подключиться к командной строке одного из серверов кластера и проверить наличие и состояние лицензии командой vzlicview
    2. При необходимости установить новый лицензионный ключ командой vzlicload;
  2. Проверить корректность сетевых настроек контейнера и при необхлодимости изменить их, для этого:
    1. Подключиться к командной строке сервера, на котором выполняется контейнер управления vstorage-ui;
    2. Получить параметры контейнера командой prlctl list -i vstorage-ui;
    3. При необходимости задать параметры сетевого подключения командой prlctl set vstorage-ui.
  3. Подключиться к консоли контейнера vstorage-ui и провести диагностику неисправности операционной системы контейнера, для этого:
    1. Подключиться к командной строке сервера, на котором выполняется контейнер управления vstorage-ui;
    2. Подключиться к контейнеру командой prlctl enter vstorage-ui;
    3. Провести анализ журналов командой journalctl -xe и поиск неисправности контейнера;
  4. Развернуть контейнер управления из резервной копии, для этого необходимо:
    1. Получить VM_UUID идентификатор контейнера vstorage-ui командой: prlctl backup-list -f --vmtype ct | grep -e 'vstorage-ui' -B1;
    2. Восстановить резервную копию контейнера командой prlctl restore <VM_UUID>;

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

 
1) , 2)
При отсутствии активной лицензии виртуальные среды автоматически выключаются через определённый промежуток времени.