[AkP]

Хостовый кластер Hyper-V без общего хранилища не создать. »

Планирую так: 1 СЕРВЕР. -1-ая ВМ (DAG1) -2-ая ВМ (CAS1+транспорт) 2 СЕРВЕР. -1-ая ВМ (контроллер домена, DNS) 3 СЕРВЕР. -1-ая ВМ (DAG2) -2-ая ВМ (CAS2+транспорт) 4 СЕРВЕР. -1-ая ВМ (Файловый сервер) -2-ая ВМ (Контроллер домена, DNS, свидетель DAG) Куда поставить NLB от windows? »

Боже вас упаси создавать кластер Hyper-V, даже если бы общее хранилище было (без него можно на 2012 на 2008 не помню), если вы хотите виртуализировать на нем КД. Это классический пат ВКД, когда служба кластеров не может запуститься из за недоступности КД, а ВМ с КД не может стартовать из-за не запущенной на хосте службы кластеров. Если вам понадобится по каким то причинам полностью потушить сервера (оба КД), запустить снова !всю! инфраструктуру будет, мягко говоря, проблемой, не говоря о том что делать это придеться вручную. Есть и другие проблемы с ВКД которые MS обещают победить в будующем, пока не совсем понятно насколько далеком.

ВМы DAG1 и DAG2 - это кластер серверов. ВМы CAS1 и CAS2 - это NLB-кластер, а HTS болтается где попало и в каком угодно количестве.

Если машина, на котором стоит балансировщик, умрет »

каждый узел NLB "сам себе балансировщик", вы наверно путаете с СК для терминального НЛБ.

Вообще в таком случае проще будет использовать Windows Server 2012, где для кластера требование специализированного общего хранилища не является обязательным. Опять же снимется вопрос про репликацию ВМ. »

Вы путаете необходимость общего хранилища для создания кластера и общего хранилища для конкретной службы. В WS2008 тоже не нужно общее хранилище для кластера. В WS2012 речь идет только о !возможности! миграции без общего диска, но если 1 физическая машина вышла из строя, то ее делать уже некому и не откуда.

Т.е. дизайн будет приблизительно таким - кластер файлового сервера для размещения пользовательских данных и кластер виртуальных машин с хранением файлов ВМ на файловом сервере. »

То-есть файловый сервер ни как не обеспечивается отказоустойчивостью и в случае выхода из строя "ложит" не только пользовательские данные, но и все сервера? ну-ну. Или все таки файловый сервер это, "кластер файлового сервера" , ВМ-ы которого живут на ресурсе, который они же и обеспечивают, при чем без общего хранилища, к которому после сбоя мог бы получить доступ другой физический сервер? Ухх как загнули, хочу посмотреть на реализацию )

А насчет WS2012, что-то уж не очень хочется ставить ее пока. »

Тут политика лицензирования отличается от WS2008, вам понадобятся лицензии перЦПУ. При этом не смотря на то, что 1 лицензия (2фЦПУ) дает право на 2 ВМ, вы обязаны давать машинам не больше виртуальных процессоров, чем физических ядер на одном сокете. На HT надеяться не стоит, так как шедулер гипервизора попытается использовать физические ядра на втором фЦПУ, а это за рамками лицензионного использования. Если на одной лицензии у вас 2 ВМ и вы даете ВМ больше вЦПУ, чем есть на одном фЦПУ (HT не учитывается), вы обязаны делать привязку к сокету. Либо докупать дополнительные лицензии.
Вспоминаем так же что, если хост Hyper-V выполняет какую-либо роль, кроме виртуализации, то вы лишаетесь возможности в полной мере покрыть хостовой лицензией запущенные экземпляры виртуальных машин. То-есть отказаться где-то от виртуализации и поместить что-то на хост может быть проблемой.

Отказоустойчивость файлового сервера, как уже выше было сказано, можно обеспечить посредством DFS. »

DFS врядли подходит для обеспечения отказоустойчивости для файловых помоек, где все меняется слишком часто и много, и тем более для хранения ВМ, гарантировано будут проблемы (смотрим ограничения ДФС, а так же как где и когда делается репликация итд).

Итого. Физические сервера не должны (ВКД) быть собраны в кластер Hyper-V, без выноса ВКД за его пределы. Ставьте задержки для запуска ВМ, так, чтобы в случае отключения обоих ВКД, они не запустились позже остальных ВМ, иначе кластера DAGа итд не запустяться. Ни для одной роли, кроме файлового сервера не нужно общее хранилище, но режим кворума не должен быть Node Majority (большинство узлов) ибо в случае потери связи между кластерами, каждый нод начнет "тянуть на себя одеяло", для четного числа узлов подходит режим кворума - Node and File Share Majority (большинство узлов и файловый ресурс), но тут нужен дополнительный файловый ресурс за пределами кластера (собственно это свидетель, как и тот, что требуется для DAGа).
Файловый сервер сделать отказоустойчивым вам ни как не удасться без общего хранилища. Есть еще несколько вариантов, собрать кластер для файловой помойки, которые не были озвучены, но все они в итоге затыкаются в одной точке отказа, которая будет эмулировать общее хранилище.