Windows Failover и беспорядок Выравнивания нагрузки
Можно лицензировать на пользователя - в этом случае 30 CALs, необходимые для каждого сотрудника. Если пользователи совместно используют машины (например, неполный рабочий день работы), Вы могли бы пойти для CAL для каждого устройства вместо этого, который может удаться более дешевый для Вас, но он кажется, что необходимо идти на пользовательский маршрут
С кластеризацией Hyper-V у вас есть пул серверов Hyper-V (2+), все подключенные к одному и тому же набору сетевого хранилища, так что LUNS доступны для всех серверов в Hyper-V. -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 или NLB правильным вариантом. В дополнение к другим вашим виртуальным машинам, если они также не кластеризованы / сбалансирована нагрузка, они не защищены от проблем с хостом Hyper-V без кластеризации Hyper-V.
Если вы собираетесь зеркалировать виртуальных гостей между двумя хостами, избегайте кластеризации HyperV. Это позволяет виртуальным гостям запускаться на другом хосте, когда один из них выходит из строя, и позволяет балансировать нагрузку на уровне хоста.
Если вы выполняете кластеризацию SQL, вы можете гораздо быстрее выполнить этап резервного копирования SQL и начать обработку запросов. А для балансировки веб-нагрузки используйте NLB (вовлеките своего сетевого специалиста в это правильно, прочтите о многоадресной NLB). И используйте кластеризацию Exchange между двумя виртуальными машинами Exchange. Вы будете намного счастливее.