Идеальная конфигурация резервирования для 3 физических серверов, работающих под управлением IIS и SQL Server
Я хочу создать как можно более избыточную архитектуру для обслуживания веб-приложения, ориентированного на данные, всего с 3 серверами (всего 5U стоечного пространства). Между этими двумя настройками, которые были бы наиболее идеальными, и какие плюсы и минусы для каждого я бы рассматривал?
Опция 1:
- 2 веб-сервера + 1 сервер базы данных. Веб-серверы будут умеренно мощными и будут обслуживать трафик балансировщиком нагрузки, в то время как сервер базы данных будет значительно более мощной машиной с максимально возможной встроенной избыточностью (источники питания, жесткие диски с горячей заменой и т. Д.).
Вариант 2:
- 3 идентичных сервера, на каждом из которых работает IIS и SQL Server. Каждый из них был бы более мощным, чем веб-серверы варианта 1, каждый с настройками RAID 5/10, тоннами оперативной памяти, 8-16 ядрами и т. Д. Я не уверен, будут ли у них такие вещи, как диски с возможностью горячей замены или источники питания, хоть.
Мне нравится простота варианта 1, но мне не нравится, когда сервер базы данных является большой ошибкой. Вариант 2, по-видимому, решает проблему с базой данных, однако я уверен, что будут некоторые предостережения, связанные с зеркальным отображением базы данных в трех экземплярах и с параллельным IIS.
Какие-нибудь мысли? Заранее спасибо.
1 ответ
Если ваша цель - высокая доступность (HA), вам действительно нужен отдельный сайт для аварийного восстановления. Что произойдет, если вы потеряете питание вашей стойки? Ваше приложение отключается. Зеркальное отображение базы данных - хорошее, дешевое решение для сервера базы данных. Вы можете также рассмотреть возможность двойной репликации или даже реплицированной сети SAN (более дорогой), чтобы можно было реплицировать и веб-сервер.
Для локальной HA вы можете настроить веб-сервер с балансировкой нагрузки на компьютерах A и B. Затем настроить отказоустойчивый кластер SQL Server на компьютерах B и C, где B является пассивным узлом, а C - активным. Это означает, что машины A и B будут обслуживать веб-запросы и будут передавать эти запросы серверу базы данных на машине C. Если машина C умрет, база данных перейдет на сбой к машине B, что даст вам избыточность, но с возможным падением производительности. Если машина A умрет, то машина B вступит во владение. Если машина B умирает, то машина A будет обслуживать веб-запросы, а машина C будет обслуживать запросы к базе данных, как обычно. Вы можете отключить две машины (если они оба не являются веб-сервером), и ваше приложение все еще будет работать, но с существенным падением производительности.
Мне нравится предложение Phoebus об использовании виртуальных машин для этого, однако вам действительно необходимо протестировать производительность с виртуальными машинами, поскольку это может быть ограничивающим фактором. Я бы не стал кластеризовать виртуальные машины, но предпочел бы использовать Vmotion для восстановления после отказа. Для производительности у меня также было бы только 1 ВМ на хост - нет смысла создавать более 1 ВМ на хост IMO. Имейте в виду ограничения виртуальных машин, хотя - сокращение оперативной памяти и процессора. Вам также нужен кто-то достаточно опытный, чтобы настроить его полностью оптимально. Например, я обнаружил, что в некоторых случаях производительность может увеличиться за счет уменьшения количества виртуальных ЦП, которые должна иметь виртуальная машина, до 1.
Для того чтобы найти лучшее решение, нужно провести много тестов и сравнительного анализа, но я считаю, что нужно использовать веб-серверы с балансировкой нагрузки и кластеризацию SQL Server. Убедитесь, что ваши дисковые массивы можно настроить как общие диски.