В ближайшие пару месяцев мы собираемся добавить отказоустойчивость и балансировку нагрузки в нашу среду. У нас будет 2 сервера, которые являются хостами Hyper V. Мы хотим иметь сервер приложений IIS и сервер баз данных SQL на обоих хостах. Таким образом, если один блок выйдет из строя, другой займет его место. Теперь мое замешательство вызвано некоторыми поисками в Google, которые я делал. Насколько я могу судить, похоже, есть кластеризация SQL / настройка одноранговых транзакций, а также кластеризация Hyper-V. Я не уверен, что будет лучше всего работать в этой ситуации. На хостах также будут случайные другие серверы, такие как системный центр, наш сервер билетов, сервер администратора Exchange и несколько других, разделенных между ними. Поэтому я не уверен, будет ли кластер Hyper-V худшим вариантом.
Спасибо.
решение1
При кластеризации Hyper-V у вас есть пул серверов Hyper-V (2+), все из которых подключены к одному и тому же набору сетевых хранилищ, так что LUN доступны всем серверам в кластере Hyper-V. Для этой настройки у вас должно быть сетевое хранилище. При динамической миграции Hyper-V вы можете переместить работающую виртуальную машину с одного хоста 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 или NLB. Кроме того, для других ваших виртуальных машин, если они также не кластеризованы/не сбалансированы по нагрузке, они не защищены от проблемы с хостом Hyper-V без кластеризации Hyper-V.
решение2
Если вы собираетесь зеркалировать виртуальных гостей между двумя хостами, то избегайте кластеризации HyperV. Это позволяет виртуальным гостям запускаться на другом хосте, когда один из них выходит из строя, и позволяет вам балансировать нагрузки на уровне хоста.
Если вы делаете кластеризацию SQL, вы можете сделать резервный шаг SQL намного быстрее и начать обрабатывать запросы. А для балансировки веб-нагрузки используйте NLB (привлеките своего сетевого специалиста, чтобы сделать это правильно, почитайте о многоадресной NLB). И используйте кластеризацию Exchange между двумя виртуальными Exchange. Вы будете намного счастливее.