Windows server 2008 cluster

First published on MSDN on Jan 18, 2008

So they asked me to write for a blog.  Well, I’m new here, and what can a new guy write about?

The basics!

But the target audience for this blog is not the faint of heart, so, let’s start with a

NEW basic

thing for everybody: “Creating a Cluster in Windows Server 2008”.

First a small introduction:

Clustering is available in Windows Server® 2008 Enterprise and Windows Server® 2008 Datacenter editions.  The improvements to

failover clusters

(formerly known as server clusters) are aimed at simplifying clusters, making them more secure, and enhancing cluster stability.  Cluster setup and management are easier with the new MMC Snap-In management interface, and complexity is reduced by providing the user with a simple interface to create, manage and use their failover cluster.  Setup is more straightforward, with fewer steps and less configuration.  Also, Cluster setup is fully scriptable so that you can automate your deployment.  Security and networking in clusters have been improved, as has the way a failover cluster communicates with storage.

Does your current hardware works?  Just run the new validation wizard.  It will run tests to determine whether your system, storage, and network configuration is suitable for a cluster.  These tests include specific simulations of cluster actions, and fall into the following categories: System Configuration tests, Network tests and Storage tests.

What else is new?  Well, GUID partition table (GPT) disks and partitions of up to 2 TB are supported in failover cluster storage.  And, if you’re like me, you’re asking what is a GPT?  Here is the answer: GPT disks provide increased disk size and robustness.  Specifically, GPT disks can have partitions larger than two terabytes (that’s a lot) and have built-in redundancy in the way partition information is stored, unlike master boot record (MBR, bye old friend) disks.  With failover clusters, you can use either type of disk.

Validating a Potential Cluster Configuration:

Ok, so let’s start with this cluster business.  I’ll create a simple cluster to show you the reduced numbers of steps.  Let’s suppose you have two servers, running Win2k8 Enterprise already, with the

“Failover Clustering”

feature installed.  So, hit

Start

, type

failover

, and there it is, the management interface, just hit

enter

.  (Off topic: I love this new

Start Menu

, don’t you?)

And then, the new MMC Snap-In for “

Failover Clustering Management

” appears:

These is your main

“Cluster Control Panel”

.  From here you can create, manage and even shutdown your cluster, along with a lot of other options.  This is also where you can run the

Validate a Configuration Wizard

, to make sure your servers’ hardware conform to the basic requirements.  As a best practice, we’ll do this first to make sure the hardware configuration will work and be supported.

Just click the link

Validate a Configuration…

and the new

Validate a Configuration Wizard

appears.  This info page remind you of the tests that will be performed and has links on how to prepare your hardware.

Once read, hit

Next

and select all the tests (additional storage devices and nodes exponentially increase the time to completion, so if, for example, you have tested the storage before you may want to skip it).  Again, select

Next

and you will have a review page, listing your servers and all tests that will be performed on them.

Hit

Next

and it

starts

! See it running on my second server:

This can take some time.  Cofee anyone?

When it’s done, you see a new page, with a review of all tests, and can hit the

View Report

button, to get a nicely formated web page, with all tests details, like below:

A copy of this report is stored in your

%windir%\cluster\reports

directory if you need to access it later.

OK, so as expected your hardware is perfectly clusterable.  What?  Some issues?  Failed?  OK, there is a link on the tests review page that explains the validation tests and gives you some hints of what to do.  This part is done, hit finish and we are back on our

“Cluster Control Panel”

.

Creating a Cluster

So, hit the link

Create a Cluster…

, and the

Create Cluster Wizard

appears, with some useful information regarding clustering.  After reading, hit

Next

and the fun begins.  This is where you will enter the servers that will participate in your “soon-to-be-formed” cluster (remember this in W2k3?).  Just put the name and hit

add

for each one of them.  I already did it for my two test machines:

Once you are done listing your servers (you can even put just one, but that is not a cluster, isn’t it?), hit

Next

, and the new validation screen appears, asking if you want to validate your configuration.  Select

No

, as we already know our servers passes all tests.

So here it is finally, your cluster name.  This is how everybody in your company/store/business, will access your cluster (consequently your file server).  Give it a comprehensive name (my is

SIbagy-FileServ

) and hit

Next

.

See below the name?  Wow, that’s great!  Everything is setup automatically for us!  Didn’t I tell you we have a more straightforward interface, with fewer steps and less configuration?

So we get to a review page, with our cluster name, the nodes that will participate on it, even the IP addresses!  Hit

Next

.

Some time passes by, some messages, some blue bar filling up and…

We created a new cluster!  You can even check a detailed report with the

View Report

button.  When you press

Finish

, you go back to our Cluster Control Panel, with our two-node cluster created and ready to configure a highly-available service or application.

I will be describing how to set up a simple file server in my next post, so stay tuned for more fun next time I blog to you guys.

-Sergio Ibagy

Одно из достоинств Windows Server 2008 — высокая отказоустойчивость системы. Если говорить более конкретно, реализованные в системе Microsoft Windows Server 2008 средства создания отказоустойчивых кластеров обеспечивают поддержку более широкого набора аппаратных компонентов, модель единого кворума, способного функционировать в четырех режимах, а также упрощенный процесс создания кластеров.

К числу других модификаций Server 2008, повышающих эффективность средств отказоустойчивости кластеров, относятся гибкость настройки, допускающая более длительные задержки между расположенными в разных местах серверами, чем задержки, считающиеся приемлемыми при передаче сигналов подтверждения соединения heartbeats, а также средства мультисайтовой кластеризации, которые позволяют кластеру иметь IP-адреса в нескольких подсетях и, следовательно, на различных сайтах. Кроме того, средства отказоустойчивой кластеризации обеспечивают более высокий уровень масштабируемости, поскольку дают возможность использовать 16-узловые кластеры в 64-разрядной архитектуре. Для сравнения: в системах Server 2003 (и в 32-разрядной Server 2008) допускаются кластеры не более чем из 8 узлов. Я коснусь некоторых из этих нововведений, описывая основные усовершенствования средств отказоустойчивой кластеризации Server 2008.

Поддержка аппаратных компонентов

В свое время разработчики Windows Server 2003 подготовили специальный список аппаратных компонентов, сертифицированных для работы в кластерных конфигурациях. Пользователям системы Server 2008 приходится покупать компоненты с сертификатом, имеющим соответствующий логотип, а потом осуществлять процесс проверки кластера, дабы удостовериться, что данная конфигурация поддерживается. Если ваша конфигурация проходит тест проверки, это означает, что Microsoft поддерживает такой кластер. Процесс проверки можно выполнять и на настроенном кластере; таким образом выявляются проблемы, которые могут привести к отказу кластера.

Процесс проверки кластера не относится к числу новинок. Когда-то он именовался ClusPrep, и данное решение можно было загрузить с Web-узла Microsoft. В версии 2.0 ClusPrep подвергся модификации, и эта версия включена в комплект поставки Windows Server 2008. В процесс проверки кластера входят четыре типа тестов. Это тесты Inventory, Network, Storage и System Configuration.

Inventory. В ходе теста Inventory собираются следующие данные: сведения о системе BIOS, переменных окружения, о системе хранения данных Fibre Channel, об интерфейсе Serial Attached SCSI (SAS), о хост-адаптерах шины Host Bus Adapters (HBA), хост-адаптерах шины iSCSI, о памяти, операционной системе, об устройствах Plug-and-Play (PnP), о выполняемых процессах, службах, обновлениях программных средств, системных и неподписанных драйверах, а также общая информация о системе (такая, как модель компьютера или домен).

Network. В ходе теста Network проверяется сетевая конфигурация кластера. Затем проверяются сведения по адаптерам, касающиеся IP-адресации и подсетей, а также IP-конфигурация; это позволяет удостовериться в том, что адреса являются уникальными, что к одной подсети подключено не более одного адаптера, что шлюз по умолчанию настроен для работы с одним адаптером и что не существует дублирующих MAC-адресов (последнее обстоятельство важно в ситуациях, когда используются виртуальные машины). Проверяются сетевые каналы связи между узлами, а также правила брандмауэра, с тем чтобы обеспечить бесперебойное взаимодействие между компонентами кластера.

Storage. В ходе этого испытания составляется перечень всех дисков, в первую очередь — совместно используемых, которые видимы из всех узлов. После этого совместно используемые диски проверяются на пригодность к применению в отказоустойчивых конфигурациях; помимо прочего, проверяется способность этих дисков сохранять целостность данных.

System Configuration. В ходе этого теста проверяется корректность настройки службы Active Directory (AD), а также принадлежность всех узлов к одному домену (а в идеале и к одной организационной единице, OU), что важно для организации корректного применения групповых политик. Отметим, что принадлежность к одной OU не является обязательной; при несоблюдении этого условия всего лишь генерируется предупреждение. Также необязательна и принадлежность узлов к одной и той же подсети либо к одному сайту AD. Наряду с этим в ходе теста System Configuration проверяется, все ли драйверы подписаны и установлены ли на серверах операционные системы одной версии, пакеты обновлений и обновления программных средств. Система удостоверяется, что выполняются все необходимые службы кластеров (такие, как RpcSs, Remote Registry, LanmanServer, WinMgmt). Наконец, все узлы проверяются на использование одной и той же архитектуры, что является обязательным для компонентов кластера.

Процесс проверки кластера запускается из оснастки Failover Cluster Management консоли Microsoft Management Console (MMC). Выберите действие Validate a Configuration, введите имена узлов, которые войдут в состав кластера, и укажите тесты, которые необходимо выполнить. На экране 1 показано, как выполняются тесты проверки кластера. По завершении испытаний на экране отображается сводка с указанием состояния каждого теста. Области, требующие внимания, а также компоненты, неспособные функционировать в кластерной конфигурации, выделяются цветом. Для получения более подробного отчета нужно нажать кнопку View Report или перейти в папку \%windir%ClusterReports.

Картинка с сайта: www.osp.ru

Чтобы клиенты Microsoft не тратили средств на приобретение и установку неподходящих компонентов, корпорация разработала программу Failover Cluster Configuration Program (FCCP). Эта программа позволяет определять, какие компоненты пригодны для работы в кластерной конфигурации. Со списком кластерных конфигураций, уже проверенных специалистами компании Microsoft и ее партнеров, можно познакомиться на Web-узле Microsoft Windows Server Cluster Solutions.

В числе других фундаментальных изменений, которые касаются поддерживаемых системой Server 2008 компонентов, следует отметить SCSI и iSCSI. Проблема сбросов шины SCSI, которая была настоящим бичом версии Server 2003, решена; однако пользователи пакета Server 2008 по-прежнему должны быть настороже, ведь новая версия поддерживает другие средства хранения данных. Параллельный интерфейс SCSI с его ограничениями на длину кабеля и проблемами переходников теперь не поддерживается; ему на смену пришли технологии Fibre Channel, SAS и iSCSI. Если вы работаете с интерфейсом iSCSI, следует использовать отдельную сеть для обмена данными с сетью хранения данных iSCSI; таким образом вы устраните конфликты за полосу пропускания между обращениями к хранимым данным и другими компонентами взаимодействия клиент-кластер. Кроме того, следует позаботиться о том, чтобы средства хранения данных поддерживали стандарт SCSI-3, и прежде всего — итерацию SPC-3, которая документирует фиксированное распределение.

Модель кворума

Концепция кворума имеет большое значение для отказоустойчивости кластеров. Она обеспечивает единообразное представление о кластере в тех случаях, когда сохраняется его неделимость, а также когда узлы кластера дробятся на разделы (т. е. кластер делится на несколько групп узлов, неспособных взаимодействовать друг с другом). Благодаря кворуму ту или иную службу может предоставлять только один раздел кластера. Если одна и та же служба предоставляется несколькими разделами кластера, вероятно возникновение ошибки.

В версии Server 2008 допускается функционирование лишь одной модели кворума, тогда как в Server 2003 таких моделей было несколько. Реализованная в Server 2008 модель Majority Quorum Model может функционировать в одном из четырех режимов в зависимости от того, как размещаются имеющиеся голоса. Перечислим упомянутые выше четыре режима. Это Node Majority, Node and Disk Majority, Node and File Share Majority и No Majority: Disk Only.

Голос могут иметь следующие компоненты кластеров Server 2008:

• узлы кластера;

• общие диски (известные также как диски-свидетели);

• общие папки-свидетели, т. е. обычные общие папки на серверах Server 2008 или Server 2003, не являющихся частью кластера.

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

Node Majority. Данный режим назначает голоса только узлам кластера. Это значит, что, если кластер дробится на разделы, раздел может предоставлять службы лишь в том случае, если получает более половины общего числа голосов. Так, если разделяется кластер из пяти узлов, составлять кворум, а значит, и предоставлять службы может лишь раздел с тремя узлами. Режим Node Majority дает наилучшие результаты и рекомендуется для применения в кластерах с нечетным числом узлов. Если количество узлов четное, например при наличии четырех узлов, для кворума необходимо три узла. Если в ситуациях такого типа два узла расположены в одном месте и два узла — в другом и если по какой-то причине взаимодействие между местами расположения узлов невозможно, ни одно из этих мест не будет иметь достаточного числа узлов для формирования кворума, и кластер не сможет предоставлять службы. При наличии нечетного числа узлов — скажем, пяти — одно место будет иметь три узла, а второе — два узла. То место, где размещаются три узла, сможет сформировать кворум и продолжать предоставлять службы. В ситуациях с четным числом узлов разумнее использовать режимы с дисками-свидетелями и общими папками-свидетелями.

Node and Disk Majority. В этом режиме голос имеет каждый узел, а также общий диск, именуемый диском-свидетелем. Режим предпочтителен в ситуациях с четным числом узлов при наличии общих ресурсов хранения данных. Предположим, у нас имеется четыре узла, которые разделены на две равные группы. Только один из разделов может владеть диском-свидетелем и получить вследствие этого дополнительный голос. Следовательно, раздел, владеющий диском-свидетелем, может сформировать кворум и предоставлять службы.

Диск-свидетель должен быть базовым диском с одним томом, иметь объем не менее 512 Мбайт и быть отформатированным по NTFS. Этому диску должен быть присвоен отдельный номер логического устройства, и он не требует буквенного обозначения. Диск-свидетель и хранящиеся на нем данные не следует подвергать проверкам на наличие вирусов.

Node and File Share Majority. Этот режим функционирует точно так же, как и режим Node and Disk Majority, с одним исключением: диск-свидетель в нем заменяется общей папкой. Режим Node and File Share Majority рекомендуется использовать в ситуациях, когда имеется четное число узлов и отсутствуют общие средства хранения данных.

Общая папка должна размещаться на файловом сервере Server 2008 или Server 2003, который не является частью кластера, и данная папка в нем играет роль общей папки-свидетеля (она может располагаться в другом кластере). Кроме того, эта общая папка должна размещаться на сервере, входящем в тот же лес Active Directory (AD), что и обслуживаемый папкой кластер. Возлагаемые на общую папку задачи должны ограничиваться исключительно задачами общей папки-свидетеля. Если кластер является многосайтовым, общая папка в идеале должна размещаться на отдельном сайте, где не представлены узлы кластера; тогда она будет обладать дополнительной устойчивостью в случае отказа сайта. Наконец, общая папка не должна быть частью пространства имен DFS.

No Majority: Disk Only. В этом режиме голос имеет только общий диск (т. е. диск-свидетель). Узлы подобны европейцам с «зеленой картой»: голосов они не имеют. Кластер имеет кворум до тех пор, пока в нем присутствует диск-свидетель. Если кластер разделяется на части, кворум может формировать раздел, владеющий диском-свидетелем. Очевидная слабость этого режима в том, что диск-свидетель является единственной точкой отказа. При отсутствии диска-свидетеля кластер не может формировать кворум и предоставлять службы. В таблице представлены рекомендации, касающиеся того, какой из четырех режимов следует применять в тех или иных случаях. Отметим, что использование режима Disk Only не рекомендуется.

Картинка с сайта: www.osp.ru

Формирование кластера

Чтобы создать кластер в системе Server 2008, откройте оснастку Failover Cluster Management консоли MMC, выделите пункт Create a Cluster, введите имя кластера и укажите в мастере, какие узлы будут входить в состав кластера. Мастер проверит среду и выберет оптимальный режим кворума, а также ресурсы, которые вам потребуются. Процесс формирования кластера отличается от процесса, реализованного в версии Server 2003, тем, что в более новой версии он выполняется однократно, а настройка всех узлов кластера осуществляется средствами мастера.

Средства кластеризации Server 2008 полностью совместимы с протоколами IPv6 и DHCP; единственное неудобство состоит в том, что, если сетевые адаптеры настроены для использования статического IP, система предложит ввести IP-адрес для кластера. Если статические IP-адреса используются для узлов кластера, необходимо указать IP-адрес, как показано на экране 2.

Картинка с сайта: www.osp.ru

В процессе формирования кластера настраиваются все узлы кластера и автоматически выбираются оптимальные параметры для кворума и конфигурации кластера (в зависимости от наличия общих средств хранения данных и от конфигурации узлов). Если для работы требуется диск-свидетель, для выполнения этой роли выбирается наименьший диск (но он должен вмещать не менее 512 Мбайт данных). Все остальные общие хранилища данных помещаются в область доступных для хранения данных и могут быть использованы ресурсами кластера (в этом состоит отличие от процесса кластеризации, реализованного в версии Server 2003).

По завершении формирования кластера на консоли MMC отображается сводка, где показаны узлы кластера, режим кворума, а также диск, выполняющий функцию диска-свидетеля (если таковой используется). Кроме того, мастер формирует отчет CreateCluster.mhtml и помещает его в папку \%windir%ClusterReports. Как и при проверке кластера, вы можете познакомиться с дополнительными деталями процесса создания кластера, нажав кнопку View Report. Кстати, в процессе создания кластера нет необходимости добавлять все нужные узлы; операцию добавления узлов можно выполнить и позже.

Имейте в виду, что мастер формирования кластеров может осуществлять описанные выше действия, но не более того. Если, к примеру, вы имеете конфигурацию с четным числом узлов, но не имеете общих хранилищ данных, мастер не сможет автоматически назначить общую папку и выбрать режим Node and File Share Majority. Вместо этого оснастка Failover Cluster Management консоли Microsoft Management Console (MMC) сгенерирует предупреждение в области кворума, извещающее о том, что конфигурация не является оптимальной и что вам следует изменить ее. Процесс изменения кворума довольно прост. Чтобы настроить общую папку-свидетель, пользователю достаточно указать, какую общую папку следует использовать (администратор должен иметь полный контроль над этой папкой); обо всем остальном позаботится мастер кворумов.

Windows Server 2008 и кластеры Server 2008

В версии Server 2008 средства отказоустойчивых кластеров были, в сущности, написаны заново — они должны были вписаться в усовершенствования новой серверной операционной системы, касающиеся высокого уровня готовности. К сожалению, эти изменения в архитектуре означают, что кластеры Server 2008 и Server 2003 несовместимы с точки зрения управления или сосуществования. Инструментальные средства управления кластерами Server 2008 не могут применяться к кластерам Server 2003 и наоборот.

Проблемы возникают даже при переходе от среды Server 2003 к среде Server 2008. Возможность «покомпонентного» обновления исключается, поскольку внутри кластера не допускается сосуществование узлов Server 2008 и 2003. Вместо этого приходится создавать новый кластер с узлами Server 2008, а затем с помощью мастера Migration wizard оснастки Failover Cluster Management консоли MMC, которая входит в состав системы Server 2008, переводить ресурсы из среды Server 2003.

При отсутствии избыточных аппаратных компонентов для создания нового кластера Server 2008 необходимо удалить серверы из существующего кластера Server 2003, установить на этих серверах систему Server 2008, создать новый кластер и перевести на него требуемые ресурсы. Затем можно установить систему Server 2008 на остальных узлах Server 2003 и добавить их к кластеру Server 2008. Недостаток этого подхода состоит в том, что в то время, когда вы переводите в новый кластер необходимые ресурсы, оба кластера будут функционировать с сокращенным числом узлов, а это может привести к снижению производительности и повысить опасность отказа.

Усовершенствованные средства кластеризации

В среде Server 2008 легче планировать создание отказоустойчивых кластеров, эти кластеры легче формировать и ими легче управлять, нежели в среде Server 2003.

Версия Server 2008 предусматривает возможность использования большего числа аппаратных компонентов при создании кластеров, и в ней реализовано несколько режимов кворума, что обеспечивает более гибкую настройку. Внесенные в версию Server 2008 усовершенствования в области высокого уровня отказоустойчивости могут поставить себе на службу даже те организации, в штате которых нет групп сотрудников, специализирующихся на работе с кластерами. Кроме того, благодаря многосайтовым возможностям Server 2008 кластеризация представляется привлекательным решением проблемы восстановления после сбоя. Более подробные сведения о создании и проверке отказоустойчивых кластеров Server 2008, включая несколько видеоматериалов с практическими советами, можно получить на Web-сайте SavillTech video.

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP

Привет вам, хабрачеловеки.

Думаю все тем или иным образом осведомлены о недавнем выходе Windows Server 2008 R2 с модернизированной реализацией Hyper-V. Основным нововведением, относительно обычного 2008-го Hyper-V, заявляется поддержка функции Live Migration для переноса виртуальных машин между нодами кластера в реальном времени. Разумеется, для демонстрации этой функции, нам понадобится внешнее хранилище данных и кластер… а лишний SAN в кладовке обычно не валяется.

Картинка с сайта: habr.com

В данной заметке я расскажу как реализовать полноценный кластер Hyper-V 2008 R2 на подручном железе — трех рабочих станциях, две из которых поддерживают аппаратную виртуализацию. Под катом инструкция по сборке отказоустойчивого кластера Hyper-V с учетом нюансов и особенностей, а так же видео-демонстрация технологии Live Migration.

Введение

Картинка с сайта: habr.com

Краткий экскурс по самой технологии Live Migration. Ее основное отличие от Quick Migration — перенос виртуальной машины «на лету», без выгрузки памяти на диск (это иллюстрирует предыдущая картинка). Помимо этого, по заверениям Microsoft, перенос машины происходит быстрее, чем успевает разорваться TCP-сессия, так что пользователи если и будут испытывать дискомфорт, то небольшой.

Выбор железа и софта

У меня, разумеется, нет лишнего SAN-а для тестирования.
Все что у меня есть — две рабочих станции Aquarius (C2D 6420, 4Gb DDR2, 80Gb HDD) и одна станция на Celeron-D.
Разумеется все процессоры должны иметь поддержку 64бит, так как 2008 R2 существует только в 64-битной редакции.

Картинка с сайта: habr.com

Для реализации кластера, я возьму бесплатный вариант Hyper-V Server 2008 R2, который представляет собой модифицированный Windows Server 2008 R2 в режиме ядра, со включенным по-умолчанию гипервизором и относительно удобной консольной менюшкой для централизованного управления. Выбор обусловлен тем, что я не хочу, тратить ресурсы хостовой машины на поддержание каких-либо других ролей кроме гипервизора.

Картинка с сайта: habr.com

В случае использования данного гипервизора, лицензироваться будут только виртуальные машины, которые мы будем на нем крутить. Я это говорю на случай, если кому-то взбредет в голову внедрять данную кустарную систему в продакшн.

В качестве хранилища я буду использовать самую слабую из своих рабочих станций, закинув в нее пару жестких дисков на 250гб каждый и объединив их в софтверный RAID0 силами операционной системы. Для превращения импровизированного сервера в хранилище, я буду использовать самый дешевый из возможных вариантов — iSCSI. Эта же машина будет выступать в качестве управляющей для кластера Hyper-V, ну и заодно будет контроллером нашего маленького домена.

Существует несколько реализаций iSCSI для Windows. Две самые распространенные:

1. Microsoft iSCSI Software Target — поставляется только в паре с Windows Storage Server 2008, при покупке серверов у OEM-партнеров Microsoft. Найти ее в открытом доступе не так легко, но если кто найдет — может попробовать. Правда ставится она опять же, исключительно на Storage Server, который не сильно подходит для наших нужд.
2. StarWind iSCSI Software Target — продукт компании StarWind(имеющей совершенно непопулярный блог на Хабре) с поддержкой русского языка. У StarWind есть бесплатная версия, ограниченная в объеме хранилища до 2Тб, и двух конкурентных соединений к одному таргету. А нам для проверки больше и не надо.

Наше импровизированное хранилище будет работать под управлением полноценного Windows Server 2008 R2, версия в данном случае существенного значения не имеет, однако опытным путем выяснилось, что управление кластером с 32-битных систем может вызывать некоторые проблемы. Тем более, что в 2008 R2 стоит свежая консоль Failover Clustering, а в других версиях придется обновлять Remote Administration Tools. Ну и не стоит забывать, что машина будет выполнять также функции контроллера домена.

Настройка

Этап первый. Предварительный

Итак, у нас есть два чистых и ненастроенных Hyper-V Server 2008 R2, и один чистый Windows Server 2008 R2.

Перед настройкой кластера, необходимо настроить сетевую инфраструктуру для корректной работы. Задаем всем серверам локальные IP-адреса, предварительно подцепив их в маленький свитч(типа того, что у меня на фотке). Разрешаем удаленный доступ к нодам, как через RDP, так и через консоль MMC.

Лучше сделать это до того, как ноды окажутся в домене. Были ситуации, когда сервер ругался на невозможность изменения политик фаервола. Поднимаем домен и вводим в него наши будущие кластерные ноды.

Разумеется, включаем Failover Clustering Feature.

Этап второй. Хранилище.

Теперь можно перейти непосредственно к настройке хранилища. Начнем с того, что разобьем наш получившийся страйп (RAID0) на два логических диска — один для кворума (который ныне зовется File Share Witness), а второй для хранения наших виртуальных машин. Я выделил под кворум около 15Гб, а все остальное оставил под данные. По-хорошему — под кворум с лихвой хватит и гигабайта, однако мало ли что.

Картинка с сайта: habr.com

Переходим к установке StarWind iSCSI Target. Для загрузки с сайта производителя потребуется регистрация, которая ни к чему, в принципе, не обязывает. После регистрации, на электронную почту падает ссылка на прямую загрузку инсталлятора и файл-ключ с лицензией. Установка состоит из нескольких нажатий на кнопку Next, так что ничего существенно сложного там нет. После установки необходимо пропустить через Windows Firewall как минимум порты 3260 и 3261. Для ленивых — его можно просто отключить, так как в нашей импровизированной сети находятся только три наших сервера.

Картинка с сайта: habr.com

Запускаем консоль StarWind и пробуем подключиться к iSCSI-серверу, коим в нашем случае выступает компьютер с таинственным адресом 127.0.0.1. Для авторизации потребуется секретное сочетание дефолтного логина и пароля, которые в базовом варианте выглядят как root и starwind соответственно. Почему не просили задать пароль в процессе установки, или не повесили подсказку в интерфейсе — загадка.

Картинка с сайта: habr.com

После подключения к серверу, необходимо подсунуть ему файл с лицензией, упавший на электронную почту. Делается это во вкладке Configuration, серверной консоли StarWind. Все интуитивно понятно и просто, за исключением ссылки на загрузку самого файла в верхнем правом углу. Только после регистрации, программа позволит нам создавать таргеты.

Картинка с сайта: habr.com

В процессе создания таргета, мы создаем предразмеченные img-файлы, которые будут играть роль наших LUN-ов. Размещаем их на наших разделах в соответствии с целями, и не забываем выставлять галочку, отвечающую за конкурентные соединения iSCSI(т.е. кластеризацию). Можно также задать кэширование данных, это будет полезно в случае использования нашего медленного железа.

Картинка с сайта: habr.com

В результате, должна получиться примерно следующая картина. Два таргета — один под кворум, второй под данные. Пора подцеплять их к серверам.

Этап третий. Цепляемся к хранилищу.

В серверах версии 2008 R2 уже есть предустановленный iSCSI Initiator, отвечающий за подключение LUN-ов с нашего импровизированного хранилища, в качестве локальных дисков. Правда в связи с отсутствием адекватного GUI на консольном Hyper-V Server, его придется вызывать через командную строку или Powershell командой iscsicpl.

Картинка с сайта: habr.com

В поле, подсвеченное желтым нужно ввести IP-адрес нашего хранилища, после чего должно появиться всплывающее окошко с размещенными на сервере таргетами. Разумеется, если фаервол был правильно настроен или отключен. После того как таргеты будут подключены к нашему серверу, можно будет заняться монтированием их в качестве дисков.

Картинка с сайта: habr.com

После нажатия на Autoconfigure, в пустом окошке появятся два длинных пути к дискам, начинающимся на \?\. После этого, можно смело идти в Disk Management и задавать буквы дискам. К слову, после задания букв на первом гипервизоре, второй гипервизор подхватит имена дисков автоматически.

В результате мы получили два гипервизора, имеющих по два общих диска, подключенных через iSCSI к нашему хранилищу. Пора переходить непосредственно к кластеризации.

Этап четвертый. Кластеризация.

При настройке отказоустойчивого кластера на двух имеющихся гипервизорах, визард сам выбрал файловые разделы под кворум и под данные. Если я правильно понял алгоритм, в качестве общих ресурсов были выбраны диски, подключенные по iSCSI, и в качестве кворума был выбран наименьший. А может он выбрал их потому, что меньшему разделу я дал лейбл Quorum… =)

Картинка с сайта: habr.com

После объединения двух гипервизоров в кластер, с помощью визарда и такой-то матери, консоль отказоустойчивого кластера будет выглядеть примерно так, как на картинке сверху. Стоит заметить, что в данный момент мы имеем именно отказоустойчивый кластер, в котором всю работу выполняет только одна нода, а вторая в это время простаивает и ждет пока первая сдохнет. Но нам же нужно не это.

Картинка с сайта: habr.com

Тут нам поможет Cluster Shared Volumes — новая вкладка в консоли кластера, появившаяся только в 2008 R2. Именно на этом хранилище могут размещаться виртуальные машины, для обеспечения отказоустойчивости. Наша задача — превратить обычный кластерный ресурс в расшареный, используя волшебную кнопку «Add Storage». После предупреждения о том, что данный тип ресурсов работает только в версиях 2008 R2 и выше, во вкладке совместно используемых ресурсов появится наш диск. Диск, в свою очередь будет смонтирован на C:\ClusterStorage\Volume1, так что все совместно используемые данные будут находиться там. В том числе и виртуальные машины. Во избежание лишних глюков, в настройках гипервизоров на каждой ноде, советую выставить дефолтные пути для дисков и виртуальных машин, с размещением на нашем общем диске.

Картинка с сайта: habr.com

Этап пятый. Виртуальные машины.

Теперь можно создавать виртуальные машины непосредственно из оснастки управления кластером. Во вкладке сервисов выбираем Virtual Machines, выбираем ноду и создаем машину. Монтируем откуда-нибудь дистрибутив с ОС, устанавливаем и отмонтируем. Для корректной работы Live Migration, необходимо отсутствие зависимостей от внешних ресурсов на каждой ноде.

На видео показан процесс перегонки памяти с одной ноды на другую. На переносимой виртуальной машине стоял тот же Windows Server 2008 R2, а памяти у машины было 1024мб. Сразу стоит отметить весьма посредственную скорость миграции, которая связана с кустарной реализацией нашего хранилища и сетью в 100мбит. Позднее пересоберу кластер с использованием гигабитной сети и посмотрю на прирост производительности.

Надеюсь, статья окажется для кого-нибудь полезной. Эксперементируйте!