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