Библиотека .NET для активной / пассивной отказоустойчивой кластеризации

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

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

Это идеальный кандидат для активной / пассивной кластеризации. Один узел считается «активным» и активно подключается к «одноэкземплярным» ресурсам (например, почтовому ящику), а другие - «пассивным». Если «Активный» узел умирает, тогда другие «Пассивные» узлы выбирают новый «Активный» узел между собой.

Теперь вопрос: есть ли где-нибудь .NET-библиотека, которая помогает реализовать обычную логику отказоустойчивой кластеризации? (то есть реализация необходимой отправки / обнаружения пульса и процесса выбора «активного» узла). Поскольку я не хочу изобретать велосипед.

Что я вижу из уже проведенного исследования:

  • BizTalk Server изначально поддерживает эту функциональность, но я не использую BizTalk, поскольку он слишком тяжелый и дорогой (но я хочу имитировать эту функциональность)
  • Windows Server поддерживает отказоустойчивую кластеризацию (в некоторых высокопроизводительных версиях, таких как Windows Server 2008 Enterprise или Datacenter), но, опять же, это дорогое решение (поскольку для каждого узла потребуется дорогая лицензия)
  • Существует много информации о том, как должен работать алгоритм аварийного переключения, но я нигде не вижу реализации с открытым исходным кодом ... (только в коммерческих продуктах, продаваемых с премией)

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

ОБНОВЛЕНИЕ 02.12.2011: обнаружен SAForum (http://www.saforum.org/link/linkshow.asp?link_id=214720), который представляет собой веб-сайт, на котором публикуются открытые спецификации для разработки концепций доступности услуг. Также существует OpenSAF (http://www.opensaf.org/Welcome-to-OpenSAF%E2%84%A2~151213~14944.htm), а также реализацию спецификаций C ++ с открытым исходным кодом на SAForum. Выглядит исчерпывающе, но очень тяжеловесно. На изучение спецификаций и документации у меня уйдет много времени. Он также охватывает гораздо больше, чем просто переключение при отказе, предлагая спецификацию для полностью масштабируемой распределенной системы (уведомления, распределенные события, блокировки, управление кластером и т. Д.) ... По-прежнему нигде нет никаких признаков реализации .NET.


.net cluster-computing failover failovercluster
person Lev    schedule 05.02.2011    source источник
comment
Сколько времени простоя вы можете выдержать в случае сбоя? Как только вы откажетесь от решений высокой доступности, стоимость лицензий резко снизится. То же самое и с усилиями по разработке его самостоятельно.   -  person saille    schedule 13.02.2011
comment
Допустим, даже кричащие 15-20 минут - это терпимо (потому что это означает, что работа стоит в очереди). Я просто хочу автоматическое переключение при отказе, чтобы не вмешиваться человеку. Какие библиотеки / решения вам известны, если таковые имеются?   -  person Lev    schedule 15.02.2011

Ответы (1)


arrow_upward
2
arrow_downward

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

Чтобы получить высокую доступность и горизонтальное масштабирование, вам нужно написать много кода. Тестирование того, что он работает до уровня, необходимого в производственной среде с высокой доступностью, также потребует значительных усилий. И даже если бы вы сделали все это, стали бы вы доверять своему собственному коду над кодом Microsoft, который накопил часы работы в gazilions и прошел через несколько версий, через которые должно пройти все программное обеспечение, чтобы стать зрелым и стабильным.

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

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

Я бы добавил сюда Rabbit MQ как высокодоступную, масштабируемую шину сообщений в интересах другие читают это. Доступна коммерческая поддержка, основанная на открытых стандартах (AMQP). Клиентские библиотеки доступны практически для любой основной платформы.

person saille    schedule 06.02.2011
comment
Спасибо, что собрали действительные баллы, @saille. Вы правы, что было бы разумно проанализировать затраты на такой проект. Сервер BizTalk работает по цене 45 тыс. Долларов США на ЦП, а стоимость Windows Datacenter (с возможностью аварийного переключения) составляет 3 тыс. Долларов США на ЦП + 800 долларов США за 20 клиентских лицензий. Если мне нужно, скажем, 4 процессора, это складывается. Так что просто нужно сравнить это с предполагаемыми затратами на разработку. За надежность - хороший момент! Я полностью согласен с критически важными вещами. В моем случае это серверные приложения, которые поддерживают бизнес, и, хотя время простоя нежелательно и разрушительно, его можно терпеть ради постепенного улучшения. - person Lev; 07.02.2011