Проблемы и лучшие практики для отказоустойчивых услуг - PullRequest
7 голосов
/ 18 ноября 2009

Кто-нибудь знает какие-либо признанные передовые практики для запуска служб Windows (в моем случае, разработанные в .NET), чтобы они (автоматически) правильно переключались на другой сервер для целей высокой доступности?

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

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

Спасибо

John

Ответы [ 5 ]

3 голосов
/ 20 ноября 2009

Вот что сработало для меня.

С точки зрения инфраструктуры вам потребуется кластеризовать 2 сервера Windows. (Подойдут 2 стандартных блока Windows Server, компонент Clustering может быть установлен и настроен, большинство администраторов sys должны знать, как это сделать.) Затем установите службу на обоих узлах кластера и отключите их оба и установите значение MANUAL. запускать. Затем добавьте кластерный ресурс в администратор кластеров Windows для своей службы, которая будет управлять включением и выключением службы на любом активном узле. Позвольте кластеру Windows управлять, когда ваша служба работает и на каком узле. Это простая часть кластеризации вашего сервиса.

С точки обслуживания вы захотите спроектировать свой сервис таким образом, чтобы он мог быть как можно без состояний. Это своего рода неудачный совет, но он действительно зависит от того, что делает ваш сервис. При проектировании просто предположите, что в какой-то момент в течение времени жизни кода он остановится в самый неподходящий момент. Как служба на узле 2 узнает, где можно забрать, где остановился узел 1? Это сложная часть, для которой вам нужно разработать. В зависимости от того, что делает ваша служба, вы можете оставить последнее выполненное задание в таблице базы данных или в файле общих данных. Вы также можете запустить его с самого начала и дважды проверить, было ли выполнено это задание, прежде чем выполнять его.

Опять же, это действительно будет зависеть от того, что сервис должен выполнить. Надеюсь, это поможет.

0 голосов
/ 18 ноября 2009

Существует два основных подхода.

  1. клиенты знают о другом адресе конечной точки и переключаются по мере необходимости или по указанию другого сервиса или механизма конфигурации. (например, демонстрационное приложение stocktrader делает это.)

  2. Клиенты не знают, и вы используете стандартный подход балансировки сетевой нагрузки, который также может обеспечить отработку отказа. F5 это один продукт. Есть много других. По сути, это как NAT для служб, все запросы проходят через ваш NLB, и он отправляет их на сервер и пересылает ответ обратно вызывающей стороне. Эти продукты контролируют услуги и используют только те, которые работают. Кроме того, вы часто можете настроить его с помощью правил, чтобы он назначал новые запросы к серверам на основе серверных рабочих нагрузок. Сервер Windows имеет эту функциональность, в некоторой степени встроенную.

В любом случае, вам гораздо проще, если ваши сервисные вызовы "не сохраняют состояние".

0 голосов
/ 18 ноября 2009

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

0 голосов
/ 18 ноября 2009

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

В случаях, когда вы должны обработать аварийное переключение в коде:

  1. Тестовое соединение / сервисный звонок
  2. Если тест не пройден, отправить оповещение
  3. Переход на следующую "зарегистрированную" конечную точку службы
0 голосов
/ 18 ноября 2009

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

Для синхронизации используйте транзакционную базу данных. Попытка написать собственную синхронизацию обычно приводит к ошибкам.

...