Назад | Перейти на главную страницу

Путаница при отказе Windows и балансировке нагрузки

В ближайшие пару месяцев мы планируем добавить в нашу среду аварийное переключение и балансировку нагрузки. У нас будет 2 сервера, которые являются хостами Hyper V. Нам нужны сервер приложений IIS и сервер базы данных SQL на обоих хостах. Таким образом, если один ящик выйдет из строя, его место займет другой. Теперь мое замешательство вызвано некоторыми поисками в Google, которые я делал. Из того, что я могу сказать, похоже, есть кластеризация SQL / настройка одноранговых транзакций, а также кластеризация Hyper-V. Я не уверен, что лучше всего сработает в этой ситуации. У хостов также будут случайные другие серверы, такие как системный центр, наш сервер билетов, сервер администратора Exchange и несколько других, разделенных между двумя. Так что я не уверен, что сейчас кластер Hyper-V будет худшим вариантом.

Спасибо.

С кластеризацией Hyper-V у вас есть пул серверов Hyper-V (2+), все подключенных к одному и тому же набору сетевого хранилища, так что LUNS доступны для всех серверов в кластере Hyper-V. Для этой настройки у вас должно быть сетевое хранилище. С помощью Hyper-V Live Migration вы можете переместить работающую виртуальную машину с одного хоста Hyper-V на другой. Это позволяет переносить рабочую нагрузку с одного сервера на другой в случае отказа сервера. Это дает вам физическую избыточность, если ваши оставшиеся серверы способны справиться с нагрузкой дополнительных виртуальных машин. Эта настройка не защищает вас от повреждения ОС и самих приложений виртуальной машины. (Видеть http://technet.microsoft.com/en-us/library/dd446679(WS.10).aspx для получения подробной информации об этой настройке.)

SQL имеет собственную избыточность, доступную с несколькими различными вариантами кластеризации. Вы можете выполнить традиционную активную / пассивную кластеризацию с активным узлом и одним или несколькими пассивными узлами. Для этой настройки требуется общий диск между серверами, и он монтируется только на активном узле. SQL также поддерживает несколько типов репликации, что позволяет использовать несколько активных узлов. Этот метод не требует общего хранилища и сохраняет отдельную копию базы данных на каждом сервере. (Видеть http://msdn.microsoft.com/en-us/library/ee523927(v=sql.100).aspx для вариантов высокой доступности SQL 2008)

Кластеризация на уровне SQL защищает от сбоя ОС или приложения на отдельном узле, обеспечивая автоматическое переключение при отказе в этом сценарии. Если каждый экземпляр находится на другом сервере Hyper-V, вы также защищены от сбоев оборудования. Кроме того, некоторые методы кластеризации для SQL-сервера защищают от повреждения базы данных на отдельных узлах. Использование кластера Hyper-V и только одного экземпляра SQL-сервера не защищает вас от сбоя ОС / программного обеспечения на виртуальной машине. Если время простоя не является большой проблемой, вы можете восстановить данные из моментального снимка виртуальной машины за короткий промежуток времени.

Изменить: забыл часть балансировки нагрузки IIS.

Для балансировки нагрузки IIS можно использовать Windows Network Load Balancing, которая создает виртуальный IP-адрес, совместно используемый обоими узлами. (Видеть http://technet.microsoft.com/en-us/library/cc770689(v=ws.10).aspx)

К серверу IIS применяются те же правила, что и к серверу SQL, в зависимости от того, является ли кластеризация Hyper-V или балансировка сетевой нагрузки правильным вариантом. В дополнение к другим вашим виртуальным машинам, если они также не кластеризованы / сбалансированы по нагрузке, они не защищены от проблем с хостом Hyper-V без кластеризации Hyper-V.

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

Если вы выполняете кластеризацию SQL, вы можете гораздо быстрее выполнить этап резервного копирования SQL и начать обработку запросов. А для балансировки веб-нагрузки используйте NLB (вовлеките своего сетевого специалиста в это правильно, прочтите о многоадресной NLB). И используйте кластеризацию Exchange между двумя виртуальными машинами Exchange. Вы будете намного счастливее.