Re: PowerHA SAN failure

#12782
Alexander Tchoulkov
Участник

Здравствуйте,

при полной потере связи с внешними дисками PowerHA не делает аварийный останов системы в нормальных условиях (есть условия при которых он это сделает, точнее не он а RSCT в версиях до 7.1).

Причины:
1. одновременно на одном и том же узле могут присутствовать ресурсные группы которые не используют диски из SAN
2. связь с SAN может восстановиться и нет необходимости останавливать всю систему и все процессы в ней, повторный запуск иногда может занять весьма длительное время особенно если соседняя ресурсная группа это сервер базы данных использующий не диски а GPFS (и кроме того он может продолжать работать без downtime)
3. на узле могут присутствовать сервисы находящиеся не под контролем PowerHA, что в общем не рекомендуется но допустимо
4. становится возможным реализация disaster recovery при котором при пропадении доступа к SAN может осуществляться переключение на использование алтернативных путей доступа к данным необходимым для приложения.

На счёт стопового скрипта. С точки зрения PowerHA он не может зависнуть, он может не вернуть управление (завершиться) в определённый интервал времени. Стоповый скрипт должен быть написан определённым образом, в частности все ошибки он обязан обрабатывать сам и всегда возвращать управление с кодом возврата 0 и завершаться в течении 300 секунд (таймаут можно изменить в настройках PowerHA). Если он вернёт не 0 код возврата или не вернёт управление (не завершится в течении 300 секундв) то считается что необходимо вмешательство оператора и будет сгенерирован config_too_long означающий необходимость ручного вмешательства.

Обратите внимание на тот момент что все проблемы остановки приложения стоповый скрипт должен решать сам, т.е если NFS завис – убить или попытаться реанимировать NFS, если какой то процесс не останавливается из за того что не может получить доступ к файлу – убить процесс и пр. Если скрипт не может это сделать то он возвращает не нулевой код возврата или не завершается в определённый интервал времени. Что означает что в системе происходит нечто такое что должно быть решено оператором и об этом он должен знать, а не прийти и увидеть что машина (LPAR) просто выключены. При этом причина выключения может быть далеко не очевидна и можно потратить не один день на разбирательство где же это произошло.