Доброго времени суток!

Есть система MS SQL Server -> Application Server (несколько) -> (.NET Remoting) -> Rich Client.
При этом сервер более, чем stateful, а также используются события, оповещающие клиентов об изменении состояния.
Возникла задача реализации АВР (автоматического включения резерва) сервера.

При этом важно, чтобы серверы из разных комплектов не работали одновременно.

Был предложен такой способ:
— серверы делаются так, чтобы все состояние было лишь кэшем данных в базе
— база резервируется с помощью Failover clastering
— в каждом сервере (физической машине) работают Application Server и Watchdog, считающийся надежным.
— вотчдог, считающий себя активным (если другой упал), посылает клиентам команду переподключиться к нужному комплекту после его старта и обновления инофрмации из базы, которую считаем консистентной и актуальной.

Тут встают вопросы:
— о выборе активного комплекта и надежной связи между вочдогами
— о принудительном завершении упавшего комплекта (если упал один из нескольких серверов, например)
— есть ли смысл делать watchdog claster-aware application

Коллеги, просьба попинать или мыслью/ссылочкой какой помочь.

Здравствуйте, Resnick, Вы писали:

R>При этом важно, чтобы серверы из разных комплектов не работали одновременно.

Почему такое ограничение?

R> — серверы делаются так, чтобы все состояние было лишь кэшем данных в базе

Т.е. переход к stateless модели?

R> — база резервируется с помощью Failover clastering

В один момент будет только одна база будет основной?

R> — в каждом сервере (физической машине) работают Application Server и Watchdog, считающийся надежным.

Надеюсь, БД сервер на отдельной машине?

R> — вотчдог, считающий себя активным (если другой упал), посылает клиентам команду переподключиться к нужному комплекту после его старта и обновления инофрмации из базы, которую считаем консистентной и актуальной.

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

Здравствуйте, IT, Вы писали:

R>> — вотчдог, считающий себя активным (если другой упал), посылает клиентам команду переподключиться к нужному комплекту после его старта и обновления инофрмации из базы, которую считаем консистентной и актуальной.

IT>Если апп-сервера посадить на лоад-балансер, то вочдог не нужен будет.

А вот отсюда можно поподробнее? Load Ballancer внешний или виндовый? Если приложение работает с сессиями на Application Server-е могут возникнуть проблемы, а если через, к примеру, SSL, то с внешним балансером могут возникнут трудности с настройкой и стоимостью...
Или как?

Здравствуйте, Spidola, Вы писали:

IT>>Если апп-сервера посадить на лоад-балансер, то вочдог не нужен будет.

S>А вот отсюда можно поподробнее? Load Ballancer внешний или виндовый?

Всмысле виндовый? COM+'овый что ли? С .NET я работал только с внешними.

S>Если приложение работает с сессиями на Application Server-е могут возникнуть проблемы,

Обязательно возникнут.

S>а если через, к примеру, SSL, то с внешним балансером могут возникнут трудности с настройкой и стоимостью...
S>Или как?

Вроде бы надо SSL акселератор покупать, если не будет справляться.

Честно говоря, в железе я ни бум-бук. От меня требуется только писать код, который индеферентен к сессиям и стейтам.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Resnick, Вы писали:

R>>При этом важно, чтобы серверы из разных комплектов не работали одновременно.

IT>Почему такое ограничение?

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

R>> — серверы делаются так, чтобы все состояние было лишь кэшем данных в базе

IT>Т.е. переход к stateless модели?

На уровне данных. К сожалению клиенты очень тесно интегрированы с сервером на объектной модели, и такого простого перехода от одного севера к другому, как в web модели не получается...

R>> — база резервируется с помощью Failover clastering

IT>В один момент будет только одна база будет основной?

Естественно...

R>> — в каждом сервере (физической машине) работают Application Server и Watchdog, считающийся надежным.

IT>Надеюсь, БД сервер на отдельной машине?

На двух отдельных, соединенных с помощью Failover clastering, т.е. логически один отдельный внешний сервер...

Здравствуйте, Spidola, Вы писали:

S>А вот отсюда можно поподробнее? Load Ballancer внешний или виндовый? Если приложение работает с сессиями на Application Server-е могут возникнуть проблемы, а если через, к примеру, SSL, то с внешним балансером могут возникнут трудности с настройкой и стоимостью...
S>Или как?

Проблема в том, что всякие сессии запиханы в Remoting. Это не модель request/responce, это с точки зрения приложения симметричный обмен данными.

Здравствуйте, Resnick, Вы писали:

R>Здравствуйте, Spidola, Вы писали:

S>>А вот отсюда можно поподробнее? Load Ballancer внешний или виндовый? Если приложение работает с сессиями на Application Server-е могут возникнуть проблемы, а если через, к примеру, SSL, то с внешним балансером могут возникнут трудности с настройкой и стоимостью...
S>>Или как?

R>Проблема в том, что всякие сессии запиханы в Remoting. Это не модель request/responce, это с точки зрения приложения симметричный обмен данными.

Прошу прощения, но я не очень хорошо знаком с Remoting? поэтому переспрошу...
Т.е. сообщение, передаваемое от сервера к клиенту и наоборот является самодостаточным? Т.е. данные сессии, если они есть, хранятся внутри каждого сообщения?

Здравствуйте, Spidola, Вы писали:

S>Прошу прощения, но я не очень хорошо знаком с Remoting? поэтому переспрошу...
S>Т.е. сообщение, передаваемое от сервера к клиенту и наоборот является самодостаточным? Т.е. данные сессии, если они есть, хранятся внутри каждого сообщения?

Не, внутри Remoting хранится состояние соединения, насколько я понимаю, довольно сложное. Вопрос в том, что нельзя (или непонятно как) перенести stateful (включая внутреннее состояние Remoting) серверный объект на другую машину. Видимо, клиент должен переподключаться (т.е. брать данные и подписываться на события) к аналочному объекту второго комплекта.

Все ниженаписанное ИМХО на основе того, о чем было рассказано в ветке.

IT>>Почему такое ограничение?
S>Можно чтобы они были запущены одновременно, но работать одновременно им нельзя, т.к. во-первых они сами по себе пишут в базу много информации и в случае одновременной работы возможны накладки в базе, а во-вторых, сервера общаются по неким протоколам с некоторыми устройствами, причем это общение зачастую не зависит от клиенских запросов.
Общение с внешними устройствами нужно вынести в отдельный сервис, тем более что оно(общение) не зависет напрямую от клиентских запросов. Создать один общий кеш-сервис, который будет читать и писать в базу.
Отказаться от Remoting в пользу или веб-сервисов, или самописной системы передачи данных на основе XML.
Достаточно написать слой, который преобразует объекты в XML, возможно даже использовать возможности сериализации объектов в .NET
Плюсы:
1. Больше возможности по управлению сессиями
2. Гибкость
3. Можно резервировать различные сервисы в разных комбинациях
4. Распределение нагрузки между клиентом и сервером приложений

С уважением,
bw.

Здравствуйте, bigwizard, Вы писали:

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

Иногда зависит, а иногда и нет... Его тоже нужно резервировать.

B>Создать один общий кеш-сервис, который будет читать и писать в базу.

И как его резервировать?

B>Отказаться от Remoting в пользу или веб-сервисов,

И чего? Как прикажете оповещать клиента и передавать ему новые данные? Они все время появляются и должны доставляться
клиенту. Хранить на сервере списки обновления для каждого клиента? В любом случае придем к Remoting'у, только, возможно, трехколесному

или самописной системы передачи данных на основе XML.
B>Достаточно написать слой, который преобразует объекты в XML, возможно даже использовать возможности сериализации объектов в .NET

А еще можно на С++ на сокетах переписать

B>Плюсы:
B>1. Больше возможности по управлению сессиями

Имеется в виду передача сессии с комплекта на комплект? Тяжеловесно это все. Система-то практически готова и весьма объемна.

B>2. Гибкость

Гибкость и так есть.

B>3. Можно резервировать различные сервисы в разных комбинациях

Ну я и так понимаю, как резервировать request/responce

B>4. Распределение нагрузки между клиентом и сервером приложений

Проблема с нагрузкой вообще не стоит

B>С уважением,
B>bw.

Честно говоря, цели поста не понял. Коллеги, вопрос и состоит в том, что нельзя переходить к web-сервисам,
в этом случае вопрос не содержателен.

>Честно говоря, цели поста не понял.
Жаль, что Вы не поняли.

>— о выборе активного комплекта
Если будет список доступных экземпляров, можно просто брать первых из списка.
В принципе можно организовать ротацию на основе "мощности" экземпляра.

>— надежной связи между вочдогами
Так это не тот форум, хоть и форум по Архитектуре, но все же Программного обеспечения,
а не Аппаратного обеспечения. Самый простый способ дублирование каналов связи.

>— о принудительном завершении упавшего комплекта (если упал один из нескольких серверов, например)
Вопрос некорректно поставлен.
Если имеется ввиду, как остановить обслуживание клиентов и работу с внешнеми устройствами в тот момент, когда watchdog больше не является активным, то создается Событие и "сброс" этого События watchdog'ом останавливает работу экземпляра по обслуживанию внешних запросов.

>— есть ли смысл делать watchdog claster-aware application
Есть. Например, ведь нужно где-то регистрировать активные экземпляры, а хранилище данных кластера самое оно.

С уважением,
bw.

P.S. Слово кластер в английском языке пишется как "cluster".
И тогда эта ссылка рулит.

Здравствуйте, bigwizard, Вы писали:

>>— о выборе активного комплекта
B>Если будет список доступных экземпляров, можно просто брать первых из списка.
B>В принципе можно организовать ротацию на основе "мощности" экземпляра.

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

Хотелось бы отслеживать как можно больше ситуаций сбоя, таких как:
— банальная ошибка работы одного компонента основного комплекта (упало)
— ошибка железа основного комплекта (сгорел)
— сбой соединения между основным и резервным сервером

>>— надежной связи между вочдогами
B>Так это не тот форум, хоть и форум по Архитектуре, но все же Программного обеспечения,
B>а не Аппаратного обеспечения. Самый простый способ дублирование каналов связи.

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

>>— о принудительном завершении упавшего комплекта (если упал один из нескольких серверов, например)
B>Вопрос некорректно поставлен.
B>Если имеется ввиду, как остановить обслуживание клиентов и работу с внешнеми устройствами в тот момент, когда watchdog больше не является активным, то создается Событие и "сброс" этого События watchdog'ом останавливает работу экземпляра по обслуживанию внешних запросов.

Это понятно, но как это сделать как можно надежнее. Например в предложенной Вами схеме пусть например есть некий компонент, активно общающийся по Com-порту и он завис. Ни на какие события он, естественно реагировать не способен, но остановить его нужно. Так что не все так просто. Хотя здесть напрашивается простой ответ — перезапуск...

>>— есть ли смысл делать watchdog claster-aware application
B>Есть. Например, ведь нужно где-то регистрировать активные экземпляры, а хранилище данных кластера самое оно.

Активных экземпляров всего два — основной и резервный. Стоит ли оно того?

B>С уважением,
B>bw.

B>P.S. Слово кластер в английском языке пишется как "cluster".
B>И тогда эта ссылка рулит.

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