Службы Windows - сценарии высокой доступности и подход к проектированию

Question

Допустим, у меня есть автономная служба Windows, работающая на компьютере с Windows Server. Как сделать так, чтобы это было доступно?

1). Какие рекомендации по уровню дизайна вы можете предложить?

2). Как сделать его доступным как первичный / вторичный, например, кластерные решения, доступные в настоящее время на рынке

3). Как справляться со сквозными проблемами в случае любых сценариев отработки отказа

Если есть что-то еще, пожалуйста, добавьте его сюда ..

Примечание: Вопрос касается только Windows и Windows Services, пожалуйста, попробуйте выполнить это правило:)

Answer 1

Чтобы служба по крайней мере работала, вы можете настроить Windows Service Manager на автоматический перезапуск службы в случае сбоя (см. Вкладку «Восстановление» в свойствах службы.) Более подробная информация доступна здесь, в том числе пакетный скрипт для установки этих параметров. свойства - Перезапустить службу Windows, если она падает

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

Для идемпотентных команд допускание периодических сбоев (таких как заблокированные ресурсы) может быть достигнуто повторным вызовом команды определенное количество раз. Это позволяет службе защитить клиента от сбоя (до определенного момента). Клиент также должен быть закодирован, чтобы предвидеть сбой. Клиент может обрабатывать сбои службы несколькими способами - ведение журнала, запрос пользователя, повторение X раз, запись фатальной ошибки и выход - все это возможные обработчики - какой из них вам подходит, зависит от ваших требований. Если у службы есть «состояние диалога», когда служба терпит неудачу (то есть процесс перезапускается), клиент должен знать об этой ситуации и обрабатывать ее, поскольку это обычно означает, что текущее состояние диалога утрачено.

Одна машина будет уязвима для аппаратного сбоя, поэтому, если вы собираетесь использовать одну машину, убедитесь, что она имеет избыточные компоненты. Жесткие диски особенно подвержены сбоям, поэтому имеют по крайней мере зеркальные диски или RAID-массив. Следующим слабым местом являются блоки питания, поэтому также стоит использовать резервный блок питания, как и ИБП.

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

Это действительно только верхушка айсберга, но я надеюсь, что это даст вам идеи начать дальнейшие исследования.

Служба кластеризации Microsoft (MSCS)

Answer 2

Если служба не предоставляет какой-либо интерфейс для подключения клиента, вы можете:

• Трансляция или показ сообщения «Я жив» или сигнал базы данных / реестра / tcp / что бы вы ни были живы

• Имейте вторую службу (монитор), которая проверяет эти сигналы «Я жив» и попробуйте перезапустить службу, если она не работает

Но если у вас есть клиент, подключающийся к этой службе через namedpipes / tcp / etc, клиент должен будет проверить адрес машины, на которой запущена служба в базе данных, или иметь что-то более изящное, например интеллектуальный коммутатор для перенаправления трафика .

Answer 3

Если вы разберетесь с проблемами, которые пытаетесь решить, я думаю, вы, вероятно, сами придумаете несколько ответов. Как Джастин упомянул в комментарии, нет единого ответа. Это полностью зависит от того, что делает ваш сервис и как его используют клиенты. Вы также не указываете какие-либо подробности о клиент-серверной интерактивности. HTTP? TCP? UDP? Другое

Вот несколько вещей, о которых стоит подумать, чтобы вы начали.

1) Что вы делаете, если служба или сервер не работает?

• Как насчет запуска более одного экземпляра вашей службы на отдельных серверах?

2) Хорошо, но как теперь клиенты узнают о множественных услугах?

• Вы можете жестко закодировать список в каждом клиенте (не рекомендуется)
• Вы можете использовать циклический перебор DNS для пересылки запросов по всем из них.
• Вы можете использовать устройство балансировки нагрузки.
• У вас может быть отдельная служба, которая знает обо всех других службах и может направлять клиентов к доступным службам.

3) Так что, если один сервис отключится?

• Знают ли клиентские приложения, что делать, если служба, к которой они подключены, выходит из строя? Если нет, то их необходимо обновить, чтобы справиться с этой ситуацией.

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