Настройка кластера windows server 2008 r2

In this post I will explain how to build a Windows Server 2008 cluster with Server Core and Hyper-V.

---

Prepare the Nodes

---

Configure ISCSI Initiator and disks

On the Server Core Node, type «Iscsicpl.exe». If the Service is not already started, it will prompt you to start the service and then will open the iSCSI initiator Properties.

To configure disks we could use DISKPART command. While testing I had created 3 disks 2GB each.

DISKPART

LISTDISK 
(this will return the disks available in your system. (Disk 0 being the OS disk normally.)

Further steps will select the target disk, clear the readonly attribute, bring it online and create an NTFS partition

SELECT DISK 1

ATTRIBUTE DISK CLEAR READONLY
ONLINE DISK
CREATE PART PRIMARY
SELECT PART 1
ASSIGN LETTER=Q

Repeat the steps for other disks. Put the Disk Number and Drive letter accordingly.

Quit DISKPART. Format each disk by typing FORMAT  D: /q  where D is your Drive letter. No need to provide any label.

The servers are now completely configured to form a Windows Server 2008 R2 Failover Cluster.

---

Install PowerShell

In Windows Server 2008 R2 we are introducing PowerShell as the new scripting language for clustering technologies. 
PowerShell with Failover Clustering will replace Cluster.exe and the Windows Server 2008 R2 release will be the deprecation release for Cluster.exe. 
This means it will still be available for use so it doesn’t break legacy scripts, but no improvements have been made and Cluster.exe will be completely removed in the next release of Windows Server.

By default, Windows PowerShell is not installed on a computer that is running Windows Server 2008 R2 Core. You can use the below method to install Windows PowerShell on a computer that is running Windows Server
2008 R2 Core.

1.   
Run SCONFIG.

2.   
Select option 4 (Configure Remote Management).

3.   
Select option 2 (Enable Windows PowerShell).

4.   
Click OK.

Ref:  http://support.microsoft.com/kb/976736

Enable Failover Cluster Feature

You could use OCLIST command to find which all features/Roles are already installed.

Use OCSETUP to install the required Features

           
Start /w OCSETUP FailoverCluster-Core

           
Start /w OCSETUP FailoverCluster-Core-WOW64

Also add additional Features/Roles that you was Cluster Services.

In this scenario I have added File Server and DFSR roles

         
Start /w OCSETUP CoreFileServer

           
Start /w OCSETUP DFSNServer

           
Start /w OCSETUP DFSR-Infrastructure-ServerEdition

You may also use
DISM /Online /Get-Features command to list the features.

And to install features you can use
DISM /Online /Enable-Feature /FeatureName:<featureName>

Example:
DISM /Online /Enable-Feature /FeatureName: MicrosoftWindowsPowerShell

Repeat the tests on other Nodes as well.

---

Run Cluster Validation Tests

In Windows Server® 2008 and Windows Server 2008 R2, the way that clusters are qualified is changing significantly with the introduction of the cluster validation wizard. The cluster validation wizard is a feature that is integrated into failover clustering
in Windows Server 2008 and Windows Server 2008 R2. With the cluster validation wizard, you can run a set of focused tests on a collection of servers that you intend to use as nodes in a cluster. This cluster validation process tests the underlying hardware
and software directly, and individually, to obtain an accurate assessment of how well failover clustering can be supported on a given configuration.

A cluster validation report is required by Microsoft® Customer Support Services (CSS) as a condition of Microsoft supporting a given configuration.

To run the cluster validation tests using Power shell in Windows Server 2008 R2 Core:

1.   
Start Power shell and import the Failover Cluster module

POWERSHELL

IMPORT-MODULE FAILOVERCLUSTERS

2.   
Run the cluster Validation against the proposed cluster nodes

TEST-CLUSTER –NODE Node1,Node2

Create a Cluster

Once the cluster validations are passed, you can proceed with creating a cluster. You would provide a Name and IP for the cluster.

To create a Failover Cluster using Power shell in Windows Server 2008 R2 Core:

1.   
Start Power shell and import the Failover Cluster module

POWERSHELL

IMPORT-MODULE FAILOVERCLUSTERS

2.   
Create the cluster with the proposed cluster nodes

NEW-CLUSTER –NAME “CoreCluster” –NODE Node1,Node2,Node3 –STATICADDRESS 192.168.1.15

Wait for the Failover Cluster configuration to be complete.

Note: You may also perform these steps from a Windows Server 2008 R2 Full version using Failover Cluster Management RSAT tools.

Managing your Failover Cluster

---

Add a Service to Failover Cluster

Let’s try adding a File server Service to the Failover Cluster.

ADD-CLUSTERFILESERVERROLE -STORAGE “Cluster Disk 1” –NAME “CoreFileServer” –STATICADDRESS 192.162.1.20

Move the Services from one
Node to another Node

Move-ClusterGroup CorePrintServer -Node node2

This command moves the clustered service called MyPrintServer from the current owner node to node2.

Get-ClusterNode node3 | Get-ClusterGroup | Move-ClusterGroup

This command moves all clustered services and applications (resource groups) that are currently owned by node3 to other nodes. You can use this command before performing maintenance on the specified node.

Move-ClusterGroup CorePrintServer -Node node2 -Wait 0

This command moves the clustered service (resource group) called MyPrintServer from the current owner node to node2. Information about MyPrintServer is displayed immediately, while it is in the process of being moved.

Add Nodes to an existing failover cluster

Get-Cluster CoreCluster | Add-ClusterNode node3

---

Remove Nodes from your failover cluster

Remove-ClusterNode node4

This command removes node4 from the local cluster.

Remove-ClusterNode node4 -force

This command removes node4 from the local cluster without prompting for confirmation.

Destroy an existing failover cluster

Remove-Cluster

Remove-Cluster –Force

Get-Cluster CoreCluster | Remove-Cluster -Force –CleanupAD

This command destroys Cluster1, removes cluster configuration information from the cluster nodes, and deletes the cluster objects in Active Directory. 
The command does not prompt for confirmation.

---

NOTE: 

I am working on few more commands and screenshots to be added to this. Good Luck with your Windows Server 2008 R2 Server Core Failover Cluster. Let me know your feedback.
 

Необходимое предисловие от 30.03.17: Сегодня с удивлением обнаружил, что данное произведение (написанное как наполовину серьёзное по мотивам давнего эпичного обсуждения на «зелёном») некоторыми коллегами всерьёз рассматривается  (например, как здесь) в качестве инструкции по созданию рабочего отказоустойчивого решения для размещения зон DNS. Так вот, ответственно заявляю: эта статья — не инструкция по созданию отказоустойчивой DNS. Отказоустойчивость DNS достигается куда более простыми средствами: вторичными серверами зон. Использование же для построения отказоустойчивой системы DNS решения из этой статьи по сути  аналогично ректальному способу удаления гланд из известного анекдота: возможно, но трудно. Впрочем, описанные здесь техники, если к ним подходить творчески, могут пригодиться для кластеризации других нагрузок, напрямую службой кластеризации Windows не поддерживаемых. Короче, я вас предупредил.

Введение

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

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

В качестве исходного пункта для построения нашего отказоустойчивого кластера DNS возьмем двухузловой кластер с общим хранилищем на базе двух рядовых серверов в домене. Например, можно взять в качестве основы отказоустойчивый кластер файлового сервера, пошаговое руководство по установке которого есть  в MS Technet Library.  Серверы — узлы кластера, на примере которых в данном руководстве объясняется процесс построение кластера DNS называются в нашем примере NODE1 и NODE2, сам кластер — FTC01.

Описание процедуры создания кластерного сервера DNS.

Этап 1. Установка роли сервера DNS
На обоих узлах будущего кластера DNS устанавливаем роль DNS Server.

Поскольку эта операция описана во многих руководствах, здесь она подробно не рассматривается.

Этап 2. Предварительное конфигурирование службы сервера DNS
На каждом из узлов кластера заходим в оснастку управления сервером DNS и останавливаем сервер DNS

На всякий случай, чтобы не было никаких фокусов с регистрацией имен DNS — удаляем в реестре старое имя сервера DNS: значение PreviousLocalHostName в ключе HKLMSystemCurrentControlSetservicesDNSParameters (потому что в случае, если запомненное в этом значении имя не совпадает с текущим именем хоста, то сервер DNS пытается отменить регистрацию этого запомненного имени).

Этап 3. Создане кластерной службы DNS
Для создания кластерной службы DNS запускаем оснастку Failover Cluster Manager, выбираем узел Services and applications и с помощью пункта Configure a Service or Application запускаем мастер High Availability Wizard.

Проходим с помощью кнопки Next через страницу приветствия (Before you begin) и попадаем на страницу выбора типа  службы и приложения. В случае сервера DNS проще всего кластеризовать его как службу, поэтому выбираем пункт Generic Service

Нажимаем кнопку Next и попадаем на следующую страницу — страницу выбора службы. На ней указываем нужную службу — DNS Server

По кнопке Next переходим на страницу настройки точки доступа для клиентов.
На ней необходимо указать имя и IP-адрес, которые клиенты смогутиспользовать для доступа к службе.

Имя можно указать произвольное, главное чтобы он не не совпадало ни с одним именем компьютера или другой кластерной службы или приложения. Для доступа клиентов к серверу DNS оно не используется — клиенты используют только адрес IP. В нашем примере имя кластера DNS — FTC01DNS. Т.к. мы используем статические адреса IP для адаптеров сети для подключения клиентов, то адрес точки доступа необходимо назначить вручную.

По нажатию кнопки Next переходим на страницу настройки репликации разделов реестра. Здесь нужно указать ветви реестра, в которых кластеризуемая служба хранит свою конфигурацию. Для сервера DNS надо ввести значения, указанные на рисунке

Указанные здесь ветви реестра будут копироваться в базу данных кластера и реплицироваться на все его узлы. Т.е., их содержимое будет одинаковым на всех узлах кластера. Кстати, менять значения в этих ветвях (не важно, как — через интерфейс ли программы управления или же напрямую в редакторе реестра) можно только на активном узле кластера DNS — иначе изменения будут потеряны. И на это нам придется обратить внимание на одном из дальнейших шагов настройки. Жмем несколько раз кнопку Next, проходя все оставшиеся страницы и дожидаемся окончания процесса конфигурации.

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

Прежде всего, хотя сервер DNS в Windows хранит свои настройки в реестре, но содержимое зон, для которых этот сервер является полномочным, хранится в файловой системе — в файлах зон. Хотя файлы зон и меняются редко и только администратором сервера — если не разрешено автоообновление записей, что для зон, размещенных на рядовом сервере DNS не рекомендуется, т.к. на нем невозможно обеспечить безопасное обновление  — но лучше не придумывать способ их самопальной синхронизации между узлами, а перенести их на кластерный диск: он будет доступен именно тому узлу, на котором выполняется кластерный сервер DNS — благо при наличии общего хранилища мы имеем возможность использовать кластерные диски. Процедура, как это делается описана ниже.

Этап 4. Создание кластерного диска для кластера серверов DNS
Самое первое, что надо сделать — это, собственно, создать само логическое дисковое устройство (LUN) в хранилище для будущего кластерного диска, и предоставить доступ к нему обоим узлам кластера. Как это сделать, здесь рассматриваться не будет, это зависит от модели хранилища и объясняется в соответствующем руководстве.

После того, как LUN создан и доступ к нему для узлов кластера предоставлен, необходимо удостовериться, что оба узла кластера имеют к нему доступ. Для этого на каждом из узлов в Диспечере Сервера заходим в узел Storage/Disk management и проверяем, что соответствующее дисковое устройство появилось в списке. При этом устройство будет находиться на обоих узлах в автономном (offline) состоянии.

Далее, для создания кластерного диска вновь созданный диск необходимо проинициализовать. Для этого на любом из узлов переводим с помощью команды локального меню этот диск в оперативное (online) состояние

инициализуем его, опять-таки, с помощью локального меню как базовый диск (обратите внимание — динамические диски службой кластеризации не поддерживаются)

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

Выбираем вновь созданный и проиницализованный диск

и добавляем его в список устройств внешней памяти, доступных для кластера.

Теперь нужно добавить это устройство в наш кластер DNS. Переходим к узлу нашего кластера FTC01DNS в Services and Applications и добавляем с помощью команды локального меню вновь созданный диск в в кластер DNS:


Добавленное устройство теперь будет принадлежать тому же узлу кластера, которому принадлежат и остальные ресурсы кластерного сервера DNS — имя, адрсес IP — и на котором выполняется сервис DNS Server. В нашем случае этим узлом оказался узел NODE1.

Теперь на кластерном диске надо создать раздел, в файловой системе которого будут храниться зоны кластерного сервера DNS. Для этого на узле, где выполняется сейчас кластерный сервис DNS (NODE1 в нашем примере), в Диспетчере Сервера переходим в узел StorageDisk Management и создаем на кластерном диске (он должен находиться сейчас в режиме online) раздел, назначаем ему букву (для примера — Q) и форматируем его

Итак, мы создали кластерный диск для хранения зон DNS.

Этап 5. Настрока зависимостей для кластерного сервера DNS
Теперь укажем службе , что сервис DNS зависит от доступности кластерного диска, который мы добавили на предыдущем этапе, чтобы служба кластеризации не пыталась запускать сервис DNS Server в случае, если этот диск и хранящиеся на нем файлы зон недоступны.

Для этого в Диспетчере отказоустойчивого кластера выбираем слева в панели дерева в узле Services and Applications наш кластерный сервер DNS, и заходим в диалоговое окно свойств сервиса DNS Server его через локальное меню в панели просмотра

Переходим на вкладку Dependencies и добавляем во вторую строчку созданный на этапе 4 кластерный диск. Указываем в первом столбце, чтодля успешного запуска сервиса Server DSN необходимо оперативное (online) состояние и имени кластерного сервера, и кластерного диска- выбираем вариант AND

Теперь мы готовы перенести папку, в которой будут храниться файлы зон, на кластерный диск

Этап 6. Перенос папки для файлов зон.
Место расположения папки с фалами зон для сервера DNS задается в реестре, значением параметра DatabaseDirecory в ключеHKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesDNS. По умолчанию, т.е. если этого значения не существует, сервер DNS использует для хранения файлов зон папку DNS, находящуюся в папке %SystemRoot%system32 (т.е. при установке в расположение по умолчанию — в папке C:WINDOWSsystem32). Эту папку мы скопируем впоследствии на кластерный диск DNS, но прежде нужно внести изменения в реестр — создать параметр DatabaseDirecory типа REG_SZ в укзанном ключе и установить нужное значение

Редактировать реестр нужно обязательно на том узле, где выполняется кластерный сервер DNS и обязательно при условии, что если кластерный сервер DNS находится в оперативном (online) режиме — в противном случае внесенные изменения будут перезаписаны содержимым этого ключа, реплицируемым из кластерной базы данных (как вы помните, мы указали при создании кластера, что этот ключ необходимо реплицировать на все узлы).

И только теперь можно перевести кластерный сервер DNS в автономный(offline) режим

чтобы скопировать папку DNS на кластерный диск.

Копируем папку DNS из папки C:WINDOWSsystem32 в корень диска Q:

После копирования папки можно перевести сервер опять в оперативный режим.
Теперь файлы зон DNS для кластерного сервера хранятся на кластерном диске.

Осталось несколько последних штрихов.

Этап 7 Настройка кластерного сервера DNS на прослушивание только кластерного IP
В принципе, это можно и не делать, но для красоты решения укажем, что наш кластерный сервер должен прослушивать порты DNS только на IP-адресе своего кластера. Изменения опять-таки надо вносить на узле, на котором выполняется в данный момент кластерный сервер DNS.

Для удобства управления имеет смысл внести изменения в сохраненные консоли DNS на узлах кластера — удалить из них сервер с именем узла и добавить туда сервер с именем кластера, чтобы можно было настраивать DNS, не задумываясь, на каком сейчас узле выполняется кластерный сервер.

Все, кластерный сервер DNS готов к работе.

Что дальше.

Реализацию кластерного сервера DNS можно усовершенствовать. Дело в том, что выбранный вариант реализации, через Generic Service, отличаясь простотой, имеет тот недостаток, что служба кластеризации не обнаруживает отказы сервера DNS, не приводящие к падению службы или остановке сервера-узла кластера. Например, если служба сервера DNS зависнет и перестанет отвечать на запросы, то это не будет обнаружено службой кластеризации. Это происходит, потому что функция обратного вызова IsAlive для Generic Service проверяет лишь, что соответствующая служба запущена, но не проверяет ее работспособность. Чтобы устранить этот недостаток, можно реализовать кластерный сервер DNS с помощью сценария (Generic Script) — тогда в подпрограмме сценария IsAlive можно будет делать все необходимые проверки работоспособности службы.

Одно из достоинств 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.

Чтобы клиенты 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 не рекомендуется.

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

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

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

В процессе формирования кластера настраиваются все узлы кластера и автоматически выбираются оптимальные параметры для кворума и конфигурации кластера (в зависимости от наличия общих средств хранения данных и от конфигурации узлов). Если для работы требуется диск-свидетель, для выполнения этой роли выбирается наименьший диск (но он должен вмещать не менее 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 2008 и Hyper-V. Те, кто создавал кластер в Virtual Server оценят рациональность и удобство многих процессов в Windows 2008 и Hyper-V. Одно из значительных улучшений — это интеграция Hyper-V в качестве кластерного приложения и лучшая поддержка для создания отказоустойчивых виртуальных машин.

И так вот 10 шагов, которые вам нужно будет проделать для построениен защещенного кластера с использованием iSCSI хранилища (iSCSI target).

1. Установить два сервера Windows 2008 Enterprice или DataCenter с ролью Hyper-V
2. Настройте виртуальные сети в Hyper-V (Virtual Network Manager)
3. Настройте на iSCSI хранилище (iSCSI target) диски Кворум (Quorum) и Ситемными дисками (Data)
4. Используйте iSCSI коннектор (iSCSI initiator) для подключения Кворум и Системных дисков
5. Установите компоненту Failover Cluster на каждый сервер
6. Запустите утилиту проверки настроек серверов в кластере (Validate the cluster)
7. Создайте кластер
8. Создайте новую виртуальную машину (VM)
9. Сделайте новую VM отказоустойчивой
10. Проверьте отказоустойчивость VM

Настройки нашей модели

AMDNode1

LAN IP address = 192.168.0.170
Heartbeat IP address = 10.10.10.1

AMDNode2

LAN IP address = 192.168.0.171
Heartbeat IP address = 10.10.10.2

Cluster IP Address = 192.168.0.181

Шаг  1:

Установите на сервера Windows 2008 Enterprise или Data Center edition — это достаточно просто. После установки добавтьте роль Hyper-V на оба сервера и перезапустите их.

Шаг 2:

После того как сервера перезагрузятся и Hyper-V роль окончательно установится, запустите консоль управления Hyper-V на обоих серверах.

(Ввнимание — это надо проделать на обоих серверах). С правой стороны окна консоли управления Hyper-V нажмите Virtual Network Manager для создания новых виртуальных сетей. В открывшемся окне выберите New Virtual Network и тип сети Private. Назовите новую сеть — Private. Имя сети должно быть одинаково на обоих серверах.

Шаг 3:

На  iSCSI хранилище (iSCSI target) (хардверном или софтверном, что у вас?) создайте два диска для общего пользования. Один диск размером 500 мб или больше для информации о настройках кластера (Quorum), второй скажем 10 гиг для витруальной машины (Data). Проверьте что включена опция общего доступа или доступа кластера к дискам.

Шаг 4:

На сервере AMDNode1 запустите утилиту iSCSI коннектор (iSCSI initiator). Добавьте  iSCSI хранилище (iSCSI target) набрав имя или IP адрес сервера и подключите диски Data и Quorum.

Как только диски будут подключены к серверу AMDNode1, запустите консоль управления дисками (Disk Management) , для инициализации дисков и форматирования в NTFS. Назначьте буквы Q: на диск Quorum и например S: на диск Data.

Теперь переходите к настройкам iSCSI коннектор (iSCSI initiator) на сервере AMDNode2. Так же добавляете iSCSI хранилище (iSCSI target) и подключаете диски. Еще раз инициализировать и форматировать диски на этом сервере не нужно.

Шаг 5:

На каждом сервере используя консоль Server Manager, установите компоненту Failover Clustering и после установки запускайте на сервере AMDNode1 консоль управления кластером (Failover Clustering Management console).

Шаг 6:

Проверьте что диски корректно подключены к серверу AMDNode1 (в консоле управления дисками (Disk Management) диски Q: и S: присутсвуют, онлайн и отформатированы). Если все так запускайте сервере AMDNode1 утилиту проверки настроек кластера (Validate a Configuration).  Добавьте имена серверов которые будут в кластере и запустите все тесты.  Итогом работы утилиты проверки настроек кластера (Validate a Configuration) является отчет о результатах тестов и в случае возникновения ошибок будет написана причина и как устранить ее.

Нажмите Validate a Configuration

Добавьте имена серверов которые будут в кластере

Запустите процесс проверки

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

Шаг 7:

Если вы успешно прошли процесс проверки конфигурации, переходите непосредственно к осзданию кластера. Нужно будет проделать сделующие шаги:

1. Запустить утилиту построения кластера (Create Cluster) из консоли управления кластером (Failover Cluster Management console).
2. Ввести имена серверов кластера
3. Задать имя и IP адрес нового кластера
4. Запустить процедуру создания

Шаг 8:

В консоли управления Hyper-V на сервере AMDNode1, создайте новую виртуальную машину (VM). Назовите ее TestVM, укажите расположение виртуального диска и доступ к виртуальным интерфейсам. Используйте образ диска Windows 2008 в качестве установочного диска операционной системы. Эту VM мы и будем делать отказоустойчивой.

Не стартуйте эту VM, это необходимо для добавления виртуальной машины в кластер.

Шаг 9:

Добавим TestVM в кластер, это позволит нам запланированно или в случае сбоя мигрировать виртуальную машину с одного сервера на другой.

В консоле управления кластером нажмите Настройка Служб и Приложений (Configure a Service or Application)

В открывшемся окне выберите из списка Virtual Machine

В окне выбора виртуальной машины выберите нашу VM —  TestVM

Запустите процесс

Готово.

Теперь пора запустить виртуальную машину. Нажмите на нее правой кнопкой мыши и выберите Bring this service or application online.

Шаг 10:

Как только виртуальная машина запустилась мы можем провести тест, мигрировать ее с одного сервера на другой.

Нажмите правой кномпой мыши на виртуальную машину и выберите Move this service or application to another node, и выберите AMDNode2

Процесс выглядит следующим образом:

1. VM сохраняется на AMDNode1
2. Мигрирует на AMDNode2
3. И запускается на AMDNode2

В итоге наша VM благополучно мигрирована с одного сервера на другой.

В этой статье я рассказал о том как создать отказоустойчивый кластер из двух серверов на базе Windows 2008 и Hyper-V. Надеюсь это стало полезным для вас.