Чтобы служба по крайней мере работала, вы можете настроить Windows Service Manager на автоматический перезапуск службы в случае сбоя (см. Вкладку «Восстановление» в свойствах службы.) Более подробная информация доступна здесь, в том числе пакетный скрипт для установки этих параметров. свойства - Перезапустить службу Windows, если она падает
Высокая доступность - это больше, чем просто поддержание сервиса извне - сам сервис должен быть построен с учетом высокой доступности (т. Е. Использовать хорошие методы программирования повсюду, соответствующие структуры данных, пары ресурсов и выпуски ресурсов), а также Весь стресс-тест, чтобы убедиться, что он будет оставаться под ожидаемыми нагрузками.
Для идемпотентных команд допускание периодических сбоев (таких как заблокированные ресурсы) может быть достигнуто повторным вызовом команды определенное количество раз. Это позволяет службе защитить клиента от сбоя (до определенного момента). Клиент также должен быть закодирован, чтобы предвидеть сбой. Клиент может обрабатывать сбои службы несколькими способами - ведение журнала, запрос пользователя, повторение X раз, запись фатальной ошибки и выход - все это возможные обработчики - какой из них вам подходит, зависит от ваших требований. Если у службы есть «состояние диалога», когда служба терпит неудачу (то есть процесс перезапускается), клиент должен знать об этой ситуации и обрабатывать ее, поскольку это обычно означает, что текущее состояние диалога утрачено.
Одна машина будет уязвима для аппаратного сбоя, поэтому, если вы собираетесь использовать одну машину, убедитесь, что она имеет избыточные компоненты. Жесткие диски особенно подвержены сбоям, поэтому имеют по крайней мере зеркальные диски или RAID-массив. Следующим слабым местом являются блоки питания, поэтому также стоит использовать резервный блок питания, как и ИБП.
Что касается кластеризации, Windows поддерживает кластеризацию служб и управляет службами, используя сетевое имя, а не отдельные имена компьютеров. Это позволяет вашему клиенту подключаться к любой машине, на которой запущена служба, а не к жестко заданному имени. Но если вы не примете дополнительные меры, это аварийное переключение ресурсов - перенаправление запросов из одного экземпляра службы в другой. Состояние конверсии обычно теряется. Если ваши службы записывают данные в базу данных, их также следует кластеризовать, чтобы обеспечить надежность и обеспечить доступность изменений для всего кластера, а не только для локального узла.
Это действительно только верхушка айсберга, но я надеюсь, что это даст вам идеи начать дальнейшие исследования.
Служба кластеризации Microsoft (MSCS)