Организация схемы из двух серверов для intranet приложения?
Здравствуйте!
Заранее приношу извинения за качество вопроса, это не моя сфера, но так сложилось, что мне нужно немного погрузиться в этот вопрос.
У нас имеется intranet web приложение, написанное на asp.net, которое работает с субд ms sql. Сейчас оно крутится в тестовом режиме, руководство хочет, чтобы были куплены сервера и была построена система с резервированием. Предполагается что физически будет два сервера, один будет активен, второй будет в пассивном режиме, при отказе первого сервера будет "пробуждаться" второй, а первый переводиться в пассивный режим в автоматическом режиме. Для пользователей это должно выглядеть прозрачно, также нужна возможность переключать сервера в ручном режиме, чтобы я мог принудительно назначить активным нужный мне сервер, если, например, потребуется провести обслуживание второго.
Планируется использовать следующее ПО:
MS SQL server 2008
IIS
Windows server 2008/2012
Собственно вопрос: пожалуйста, подскажите, как правильно называется описываемая мною схема (или ближайшая, похожая на нее по смыслу), чтобы я мог почитать информацию на эту тему. Есть ли у microsoft готовое решение для похожих задач или надо будет использовать схему кластера для бд, а управление серверами (переключение между активными) реализовывать как-то самостоятельно?
Друзья, я приношу извинения за длительное молчание, у меня был небольшой отпуск и предшествующая ему запарка.
Большое спасибо за ваши комментарии. Постараюсь ответить на ваши уточняющие вопросы:
Набор требований к отказоустойчивости и подробности:
*) система должна размещаться в нашей серверной, в одной стойке (предполагается 2 одноюнитовых сервера)
*) система должна продолжать работать в случае отказа одного из комплектов ПО (отказ MSSQL на одном из серверов/IIS на том же сервере или сбой самого сервера - программный или аппаратный). При это в случае описанных сбоев в работу должен вступать дублирующий сервер, имеющий то же состояния базы данных, что было на главном сервере.
То есть никакого дата центра нет, все происходит в нашей серверной, есть желание, чтобы программная система крутилась на связке из двух серверов, одному из которых позволительно сбойнуть или быть намеренно выключенным (например, для проведения техобслуживания) без остановки работы всей системы. Максимально возможный даунтайм не критичен, главное, чтобы переключение с одного сервера на другой в случае сбоя/отключения происходило в автоматическом режиме и было незаметно для пользователя - (программа представляет собой web приложения типа CRUD - различные формы ввода и редактирования данных, там не требуется persistent connection и пр.)
Мой друг, который, как выяснилось, решал похожую задачу, описал следующий вариант:
Сделать failover cluster на базе двух серверов под управлением win2012server, завести в кластере роль hyper-v И там поднять виртуалки с IIS и MSSQL, между серверами сделать multipath io, организовать SAN и указать виртуалкам в hyper-v, что они живут на SAN. При падение одного из гипервизоров виртуалка должна автоматически переезжать на второй и продолжать работу.
Возможно, я не очень понятно описал схему, т.к. сам ее не пробовал и до конца не понимаю, но она в таком виде уже использовалась.
Если у кого-то сохранился интерес к теме, буду рад любым вопросам/комментариям.
Дело в том, что сама MS говорит, что из коробки IIS не кластеризуется через Faiover Cluster, поэтому остается сделать веб-ферму https://technet.microsoft.com/en-us/library/jj1293...
с NLB и мгновенной отработкой отказа, а MS SQL надо в Mirroring, ибо переключение в кластере не будет прозрачным для пользователя..
Тут надо понимать от чего именно вы хотите защищаться, от смерти сервера, датацентра, базы данных, дисков и тп. Каков максимально возможный даунтайм? Я бы рекомендовал сформировать набор требований к отказоустойчивости и только потом приступать к поиску решений. Обязательно определитесь с бюджетом - любая защита имеет свою цену.
Кроме решений на уровне приложения типа Windows NLB (для IIS) возможны решения на уровне виртальных серверов.
Имеет смысл посмотреть в сторону виртуализации. И таки да, присоединюсь к предыдущим ораторам -- необходимо чётко понимать, от каких конкретно сбоев вы пытаетесь защищаться.
Простой
