Архитектура основного сервера и сервера горячего резерва

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

Сервер, который необходимо реплицировать, будет работать под управлением следующего:
- ОС Windows Server 2008 R2
- MS SQL 2008 R2 Std
- IIS 7.0, на котором будет выполняться веб-приложение, встроенное в asp.net
- Несколько фоновых сервисов, некоторые из них записывают данные в БД. Это приложения .net, которые были написаны собственными силами, но без методологии репликации.

Моя цель состоит в том, чтобы данные основного сервера постоянно реплицировались на дополнительный сервер, чтобы в случае сбоя дополнительный сервер мог начать действовать как Главный сервер как можно скорее.

Мои вопросы:
1. Какова рекомендуемая аппаратная топология в этом случае? Нужно ли мне какое-либо дополнительное оборудование, помимо двух серверов, которое будет действовать как DNS сервер для разрешения маршрутизации на правильный сервер?
Если нет, то как это можно сделать с помощью программного обеспечения?
2. Репликация базы данных. Я понимаю, что мне потребуется использовать какую-то доставку журналов для синхронизации между базами данных. Каковы ограничения и рекомендации? Мне нужно знать, есть ли компромисс между хорошей производительностью и актуальной репликацией базы данных. Хорошая статья будет полезна.
3. Учитывая, что переписать приложение служб для поддержки работы в каком-то «пассивном» режиме и передачи данных о состоянии между серверами, вероятно, невозможно, что следует сделать с этими службами на второстепенная машина?


operating-system architecture sql-server-2008 iis application-layer
person LimS    schedule 18.12.2013    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

Если у вас есть более двух доступных серверов, я также рекомендую вам взглянуть на балансировку сетевой нагрузки Windows (NLB), которая является функцией, включенной в Windows Server. /en-us/library/cc725691.aspx" rel="nofollow">http://technet.microsoft.com/en-us/library/cc725691.aspx. Но поскольку NLB и отказоустойчивый кластер не поддерживаются на одних и тех же серверах, я не могу рекомендовать это, если у вас есть только два сервера.

Для базы данных я бы рекомендовал вам использовать 2-узловой активно-пассивный кластер базы данных вместо развертывания двух отдельных экземпляров SQL с репликацией между ними. В кластерной конфигурации SQL Server работает на одном сервере, но если на этом сервере возникает проблема, SQL Server автоматически переключается на другой сервер. Дополнительные сведения о кластеризации SQL Server см. на странице http://sql.starwindsoftware.com/sql-server-clustering-technology.

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

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

Если у вас два сервера, я рекомендую:

          HW IP Load Balancer
                  |
    -----------------------------
    |                           |
SERVER A                     SERVER B
ASP.NET web app              ASP.NET web app
SQL Server (active)          SQL Server (passive)
Bg services (not running)    Bg services (running)

У вас есть четыре сервера, которые я бы порекомендовал:

        HW IP LB or Windows NLB
                  |
    -----------------------------
    |                           |
SERVER A                     SERVER B
ASP.NET web app              ASP.NET web app
    |                           |
    -----------------------------
                  |
    -----------------------------
    |                           |
SERVER C                     SERVER D
SQL Server (active)          SQL Server (passive)
Bg services (not running)    Bg services (running)
person Mattias Lindberg    schedule 17.01.2014