Service Fabric имеет встроенный механизм для перезапуска сбойных приложений, но Service Fabric не понимает, что такое «плохое состояние».Если происходит сбой приложения и процесс завершается, SF перезапускает его несколько раз, пока он не сдастся и будет считать приложение неработоспособным и заблокировать перезапуск.
Если это происходит время от времени, например, несколькораз в неделю у него не будет никаких проблем, потому что существует порог того, как долго он будет рассматривать последовательные сбои как часть одной и той же проблемы.
Когда вы говорите Плохое состояние ,Каждое приложение может иметь различную концепцию Bad State, , поэтому SF не сможет идентифицировать его, если приложение не сообщит об этом через событие Health.
Пример:
- Приложение может потреблять слишком много памяти (утечка памяти), единственное, что вы можете сделать, это ограничить память приложения, установив ограничение, SF не знает, что этоутечка, возможно, часть потребления памяти при разработке вашего приложения.
- Другая проблема - API, возвращающий ответы об ошибках из-за неверной конфигурации или зависимой службы, не работает.Служебная структура не завязывается, если ошибка вызвана сбоем приложения или дизайном ваших служб.
В этих случаях вам нужно реализовать механизм, который сообщит SF, что эти ошибки не были ожидаемыми иSF будет обрабатывать отказоустойчивость для вас.Вы можете реализовать его следующим образом:
- Часть вашего приложения, оно будет выдавать свои собственные отчеты о работоспособности
- Приложение сторожевого устройства, работающее в кластере, которое отслеживает события служб или регистрирует и отправляет события вот имени других служб.
Для первого подхода быстрый способ сообщить об этом как произошел сбой , используя ReportFault :
Позволяет реплике сообщать о сбое во время выполнения и указывает, что обнаружена ошибка, из-за которой она не может быть восстановлена и должна быть либо перезапущена, либо удалена.
Для получения дополнительной информациио других отчетах о работоспособности смотрите в следующих документах: Отчеты о работоспособности Service Fabric
Для пунктов 2 и 3 ваших вопросов существует механизм, который определяет, когда узел недоступен в кластере., его понижают в должности, и SF временно удалит его из кольца.Распространенные проблемы: когда проблема с сетью не позволяет узлу взаимодействовать друг с другом, в некоторых случаях нехватка памяти может повлиять на SF Host Manager, и он начинает отказывать, медленные ответы, затем SF удалит узел из списка доступных узлов,пока он не восстановится.
Мне не известно о том, что в SF что-то перезапускает виртуальную машину, возможно, по тем же причинам, о которых говорилось ранее, в SF Explorer появится сообщение об ошибках, чтобы уведомить о проблеме, и выпридется справиться с этим.
Вы могли бы принять решение в рамках вышеупомянутого подхода к сторожевому режиму, в котором Disable-ServiceFabricNode потребуется переместить любые службы Healthy из узла, а затем выможно перезапустить базовую виртуальную машину с помощью Azure SDK .