Кластер без общего хранилища

[botmaster]

Опыта создания кластера очень мало, прочитал кучу документации. Необходимо создать кластер из четырех машин, но внешнего хранилища нет. Насколько я понял в WS2008R2 присутствует возможность создания кластера без общего хранилища. Только вот практических примеров в инете не нашел. Подскажите, действительно ли можно создать кластер не имея общего хранилища? Заранее спасибо.

[Denis Dyagilev]

Кластер каких сервисов?

[botmaster]

Виртуальные машины. В них (AD, DNS, Exchange, фаловый сервер).

[exo]

В них (AD, DNS »
и без кластера можно. Достаточно установить данные роли на несколько серверов и правильно настроить.
В них (Exchange »
и без кластера можно. Достаточно базы использовать как DAG (http://www.oszone.net/11177/Exchange-2010-DAG-1) хотя там есть часть кластерной технологии.
В них (файловый сервер »
а вот тут, скорее всего, необходимо внешнее хранилище. Другие решения мне не знакомы.

Если задумаете ещё DHCP в кластер - посмотрите в сторону Windows Server 2012. Оно там как "встроенное" без кластеризации, при наличии нескольких серверов.

[AkP]

Без общего хранилища кластер создать можно, но не нужно, так как это относится только к кворуму, дальше необходимость наличие общего диска будут диктовать сервисы, а не кластер. То-есть кластер соберется, но полезной для вас функции, например, в виде "файловый сервер" выполнять просто не сможет.
Отсюда вопрос, вы собираетесь собирать кластер из виртуальных машин в пределах одного физического сервера? Или физических серверов будет больше одного?
Если в рамках одного, то общий диск вы можете предоставить средствами гипервизора, то-есть один и тот же рейд массив отдать на растерзание всем узлам кластера, (как RAW Dvice Mapping) и внешнее хранилище вам не нужно.
Не уверен на что способен гипервизор от MS, но даже на бесплатной лицензии ESXi проблем с предоставлением дисков нет, разве что ваш сервер должен иметь минимум 2 рейд массива, один для стореджа гипервизора, где будут собственно жить ВМ и один для предоставления как общий диск для этих ВМ. Сам гипервизор можете хоть на флешке поставить, на это не стоит тратить дисковое пространство на быстрых и дорогих дисках, хотя один из рейд массивов можно использовать и как место установки для ESXi и как локальный сторедж для ВМ.
Я уверен что hyper v способен на нечто подобное, если вам милее гипервизор от MS.
Тем не менее по поводу ваших задач, то как было правильно сказано выше, для АД и ДНС, кластер не нужен, для Exchange, да есть DAG, но эта штука требует как раз кластер серверов. И для файлового серверв вам гарантировано без общего хранилища не сделать. К тому же DAG это лишь пол дела, он обеспечит отказоустойчивость баз данных, чтобы обеспечить непрерывный доступ пользователей, нужен еще и CAS, для которого необходим NLB. А поскольку кластер серверов и кластер балансировки не могут жить вместе, то вам фактически необходимо собирать 2 класера.
Как системный инженер я анализировал различные решения для организации непрерывной доступности для почтовых сервисов и пришел к выводу, что Exchange один из наихудших выборов, но это тема не для данного раздела.

В рамках описаных задач, вам понадобится 1 физический сервер требуемой производительности и 1 гипервизор, 2 ВМ для узлов НЛБ кластера (CAS), 2ВМ для узлов кластера серверов (DAG и Файл-сервера), и 2 ВМ для АД(ДНС) которые в кластер с остальными собирать не нужно.
Кластер имеющий более 2-х узлов собирать в данном случае не имеет смысла, так как кластер серверов Windows, это фактически Актив-Пассив конфигурация и под конкретный сервис работать будет только 1. Из 4 узлов есть смысл собирать если, например, имеется 3 задачи, которым необходимо обеспечить повышеный показатель готовности, при этом нет смысла приобретать 6 серверов и 3 общих массива или выделять 3 луна с наса и организовывать 3 кластера, а использовать 3 активных узла и 1 готовый принять на себя какую-то одну или сразу все 3 задачи... как то так..

[cameron]

тот же рейд массив отдать на растерзание всем узлам кластера, (как RAW Dvice Mapping) и внешнее хранилище вам не нужно. »
я не уверена что через RDM можно отдать контроллер или массив нескольким гостям одновременно, а если раздавать разные луны\слайсы то собственно это не shared storage.

да есть DAG, но эта штука требует как раз кластер серверов. »
да? с общим стораджом?

И для файлового серверв вам гарантировано без общего хранилища не сделать. »
DFS.
Как системный инженер я анализировал различные решения для организации непрерывной доступности для почтовых сервисов и пришел к выводу, что Exchange один из наихудших выборов, но это тема не для данного раздела. »
а что вы можете посоветовать?
В рамках описаных задач, вам понадобится 1 физический сервер требуемой производительности и 1 гипервизор, 2 ВМ для узлов НЛБ кластера (CAS), 2ВМ для узлов кластера серверов (DAG и Файл-сервера), и 2 ВМ для АД(ДНС) которые в кластер с остальными собирать не нужно. »
надеюсь вы шутите?

[AkP]

я не уверена что через RDM »
гарантировано можно, главное делать это по рекомендациям при создании кластеров, то-есть по одному серверу, чтобы до того как служба кластеров его не начала лочить, его не попытались использовать сразу все ОС, некоторые контроллеры при этом уходят в фатал эррор.
да? с общим стораджом? »
да, DAG зависит от ограниченного набора компонентов отказоустойчивой кластеризации Windows (Failover Cluster), в основном, от базы данных кластера, файлового ресурса-свидетеля и функции импульса синхронизации.
Нет общий диск им не нужен, функция кластера с единым хранилищем были убраны (зачем?). У каждого узла свой диск, где хранится база и он сам ее реплецирует, но это скорее минус, чем плюс (в рамках одного ЦОДа у вас нет проблем с подключением дискового массива к разным серверам и мы имеем необоснованное двукратное увеличение стоимости каждого мегабайта почты без фактического увеличения отказоустойчивости, а если учесть что дисковые массивы в лбом случае подлежат резервному копированию, то 2 продакшен массива(один из которых пассивный) будут каким то способом бакапится и мы имеет уже 4-х крантое увеличение стоимости. В рамках распределенных площадок, мы в любом случае будем иметь массивы которые скорее всего уже будут реплецироваться своими средствами.. вобщем тут много вариантов, что предоставив нам то, что мы уже можем сделать большим количеством средств и забрав общий массив... это явно не является френди решением) Да и непрерывной доступности все равно не получите ибо время на переключение ни кто не отменял. Это же Актив-пасив, а не Актив-Актив. Но несмотря на это без службы кластеров мы обойтись не можем, а значит одновременное использование НЛБ на этих же узлах для Client Access Service невозможна. А именно он отвечает за работу с почтовыми клиентами в Exchange. Можно ограничется БД, но от нее мало толку если CAS стоит на "умершем сервере", где жил первый экземпляр БД, а значит мы вынуждены ставить 3-тий сервер и он будет узким местом. Для организации отказоустойчивости этой службы существует Client Access Array, который позволяет объединить несколько CAS серверов в массив, а затем настроить доступ к FQDN этого массива при помощи стандартного Windows NLB!! отсюда и получается минимум 4 сервера и 2 массива для каждого DAG.
надеюсь вы шутите? »
Печально, но факт. Для обеспечения "непрерывной доступности" Exchange требует 4-6 серверов

[botmaster]

Про АД и ДНС мне известно, тут вопросов нет, про файловый сервер в принципе DFS может выручить. С Exchange посложнее, массивы я соберу (DAG и CAS), но вот вопрос с балансировщиком. Если машина, на котором стоит балансировщик, умрет. Тогда получается exchange отвалится у всех?

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

Куда поставить NLB от windows?

[Denis Dyagilev]

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

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

Вопросы по высокой доступности со ссылкой на данную тему лучше задавать в соответствующем подфоруме (http://forum.oszone.net/forum-76.html).

[cameron]

Хостовый кластер Hyper-V без общего хранилища не создать. »
есть такая штука (http://www.starwindsoftware.com/native-san-for-hyper-v) , но я не смотрела.

[botmaster]

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

Можно ли например средствами DFS файлы vhd дисков виртуальных машин реплицировать на другие сервера? то есть я создаю на каждом сервере папку с файлом "c:\server1\server1.vhd" и "c:\server1\server2.vhd". То есть у меня там хранятся виртуальные жесткие диски моих ВМ. Затем по расписанию раз в сутки их реплицировать на другие сервера. Если например, произойдет сбой одного сервера, то всегда можно будет подключить реплицированную копию, которая хранится на другом сервере. Возможен ли такой вариант? И есть ли ограничение на объем файла который можно реплицировать по DFS?

[exo]

Затем по расписанию раз в сутки их реплицировать на другие сервера »
размер VHD, к примеру, 200-300 GB. Сколько он будет реплицироваться по сети? А позже он ведь точно увеличится в объёме.
Есть вариант купить недорогое внешнее хранилище, например QNAP серии, отформатировать диск NTFS и подключить по iSCSI к обоим серверам кластера. Для файлового сервера, думаю, хватить должно.

Есть ли вам смысл разделять CAS +транспорт на отдельный сервер?

[Denis Dyagilev]

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

есть такая штука , но я не смотрела. »
Это программное хранилище. И не совсем правильное, на мой взгляд.

[botmaster]

Есть ли вам смысл разделять CAS +транспорт на отдельный сервер? »

В смысле есть ли смысл ставить отдельно от DAG? Можно и на один.
Мне нужно чтобы система выдержала падение ОДНОГО любого сервера, а затем чтобы можно было его восстановить по копии не более 24 часовой давности. При этом нет возможности докупить еще внешнее хранилище.

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

[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а).
Файловый сервер сделать отказоустойчивым вам ни как не удасться без общего хранилища. Есть еще несколько вариантов, собрать кластер для файловой помойки, которые не были озвучены, но все они в итоге затыкаются в одной точке отказа, которая будет эмулировать общее хранилище.

[Denis Dyagilev]

Вообще-то речь идет о кластере Hyper-V over SMB в 2012 - можно размещать высокодоступные ВМ на файловом сервере.

Про виртуализацию контроллера домена с кластером 2008 R2 капитанство, конечно. Вы смотрите, что цитируете-то. То, что кластер 2012 может стартовать без доступности контроллеров домена, используя локальную учетную запись для взаимной аутентификации узлов - объяснять не нужно?

По поводу хранилища. В любом случае, и при наличии специализированного аппаратного решения, и при программном (в случае того же Starwind или файлового сервера 2012) - место хранения ВМ всегда будет узким местом отказоустойчивости\высокой доступности.

[botmaster]

Итого. Физические сервера не должны (ВКД) быть собраны в кластер Hyper-V, без выноса ВКД за его пределы. »

Ну один физический сервер с КД можно будет достать. Я так понимаю, он не обязательно должен основным контроллером домена, достаточно и резервного. Вместе с ДНС?

[cameron]

обязательно должен основным контроллером домена, достаточно и резервного. »
эти термины устарели примерно 12-13 лет назад.
пожалуйста, не нужно ими пользоваться, более того, не понимания их смысла.

[exo]

эти термины устарели примерно 12-13 лет назад. »
иногда используют эти термины, имея ввиду под основным сервер со всеми ролями FSMO (а он может быть только один) и резервный - все остальные.
Если роли разносят по разным серверам - то PDC.
роли FSMO актуальны и по сегодняшний день

[cameron]

Если роли разносят по разным серверам - то PDC. »
какая чушь.
иногда используют эти термины, имея ввиду под основным сервер со всеми ролями FSMO (а он может быть только один) и резервный - все остальные. »
можно называть автобус дилижансом, а сапсан - паровозом.
но потом не обижайтесь, если вас не поймут или отправят отдохнуть-полечиться.