Windows Services — Высоконадежные сценарии и подход дизайна
Скажем, у меня есть автономный сервис окон, работающий в машине Windows Server. Как удостовериться, что это является высоконадежным?
1). Каковы все инструкции по уровню дизайна, которые можно предложить?
2). Как сделать это высоконадежным как основной/вторичный, например, решения по кластеризации в настоящее время доступный на рынке
3). Как иметь дело со сквозными проблемами в случае, если любые сценарии обработки отказа
Если кто-либо другой, о котором можно думать, добавляет его здесь..
Примечание: Вопрос только связан с окнами и сервисами окон, попытайтесь соблюсти это правило :)
3 ответа
Чтобы поддерживать службу хотя бы в рабочем состоянии, вы можете настроить диспетчер служб Windows на автоматический перезапуск службы в случае сбоя (см. вкладку Recovery в свойствах службы). ) Более подробная информация доступна здесь, включая пакетный скрипт для установки этих свойств - Restart a windows service if it crashes
Высокая доступность - это не просто поддержание работоспособности службы извне - сама служба должна быть построена с учетом высокой доступности (т.е. использовать хорошие методы программирования, соответствующие структуры данных, парное получение и освобождение ресурсов), а также пройти стресс-тестирование, чтобы убедиться, что она будет работать при ожидаемых нагрузках.
Для идемпотентных команд терпимость к периодическим сбоям (таким как блокировка ресурсов) может быть достигнута путем повторного вызова команды определенное количество раз. Это позволяет сервису оградить клиента от сбоя (до определенного момента). Клиент также должен быть закодирован для предвидения сбоя. Клиент может обрабатывать отказ сервиса несколькими способами - протоколирование, запрос пользователю, повторная попытка X раз, протоколирование фатальной ошибки и выход - все это возможные способы обработки, но какой из них подходит вам, зависит от ваших требований. Если у сервиса есть "состояние разговора", то при жестком отказе сервиса (т.е. перезапуске процесса) клиент должен знать об этой ситуации и справиться с ней, поскольку это обычно означает, что текущее состояние разговора было потеряно.
Одиночная машина будет уязвима к аппаратным сбоям, поэтому если вы собираетесь использовать одну машину, убедитесь, что она имеет избыточные компоненты. Жесткие диски особенно подвержены сбоям, поэтому используйте как минимум зеркальные диски или RAID-массив. Блоки питания - следующее слабое место, поэтому стоит иметь избыточный блок питания, а также ИБП.
Что касается кластеризации, Windows поддерживает кластеризацию служб и управляет службами, используя сетевое имя, а не имена отдельных компьютеров. Это позволяет вашему клиенту подключаться к любой машине, на которой запущена служба, а не к жестко заданному имени. Но если вы не примете дополнительных мер, это будет обход отказа ресурса - направление запросов от одного экземпляра службы к другому. Состояние конвертации обычно теряется. Если ваши службы записывают данные в базу данных, то она также должна быть кластеризована, чтобы обеспечить надежность и гарантировать, что изменения доступны всему кластеру, а не только локальному узлу.
Это лишь вершина айсберга, но я надеюсь, что это даст вам идеи для начала дальнейших исследований.
Если вы разберете проблемы, которые пытаетесь решить, я думаю, вы сами найдете несколько ответов. Как упомянул Джастин в комментарии, единого ответа не существует. Это полностью зависит от того, что делает ваш сервис и как клиенты его используют. Вы также не указали никаких подробностей о взаимодействии клиента и сервера. HTTP? TCP? UDP? Другое?
Вот некоторые вещи, о которых стоит подумать, чтобы начать.
1) Что вы будете делать, если служба или сервер выйдет из строя?
- Как насчет запуска нескольких экземпляров вашей службы на отдельных серверах?
2) Хорошо, но теперь как клиенты узнают о нескольких службах?
- Вы можете жестко закодировать список в каждом клиенте (не рекомендуется)
- Вы можете использовать DNS round-robin для пересылки запросов через все из них.
- Вы можете использовать устройство балансировки нагрузки.
- Вы можете иметь отдельную службу, которая знает обо всех других службах и может направлять клиентов к доступным службам.
3) Что делать, если одна служба выйдет из строя?
- Знают ли клиентские приложения, что делать, если служба, к которой они подключены, выйдет из строя? Если нет, то их необходимо обновить, чтобы они могли справиться с этой ситуацией.
Это должно дать вам основное представление о том, как начать работу с высокой доступностью. Если вы предоставите конкретные детали вашей архитектуры, вы, вероятно, получите гораздо лучший ответ.
Если служба не предоставляет никакого интерфейса для подключения клиентов, вы можете:
Транслировать или выставлять сообщение "Я жив" или сигнализировать базе данных/реестру/tcp/whatever, что вы живы
Иметь вторую службу (монитор), которая проверяет эти сигналы "Я жив" и пытается перезапустить службу в случае ее падения
Но если у вас есть клиент, подключающийся к этой службе через namedpipes/tcp/etc, клиенту придется проверить адрес машины с запущенной службой в базе данных, или иметь что-то более сложное, например, интеллектуальный коммутатор для перенаправления трафика.