Отказоустойчивый кластер windows server 2008 r2

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

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

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

Введение

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

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

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

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

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

В качестве хранилища я буду использовать самую слабую из своих рабочих станций, закинув в нее пару жестких дисков на 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Гб, а все остальное оставил под данные. По-хорошему — под кворум с лихвой хватит и гигабайта, однако мало ли что.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начиная с этой записи, постараюсь сделать ряд заметок о Службах удалённых рабочих столов Microsoft Windows Server 2008 R2 – серверной роли Remote Desktop Services (RDS). Для начала рассмотрим процесс создания фермы серверов RDS с использованием механизма балансировки нагрузки с помощью Remote Desktop Connection Broker (RDCB).

Описание задачи

Не будем заострять внимания на описании функций служб Remote Desktop Services, так как этой информации более чем достаточно в официальных источниках Microsoft. Предметом этой заметки будет пошаговое практическое описание процесса создания фермы из трёх виртуальных серверов, на каждом из которых будут совмещены компоненты RD Session Host и кластеризованная служба RD Connection Broker. То есть мы попробуем при минимуме серверных экземпляров Windows Server 2008 R2 собрать отказоустойчивое решение RDS.

По информации доступной из блога TechNet Blogs > Mark Ghazai’s Blog > Windows Server 2008 R2 Highly Available (Clustered) Remote Desktop Connection Broker на каждом из серверов в кластере RD Connection Broker будет использоваться локальная база с информацией о всех пользовательских сессиях в ферме и лишь одна из нод кластера будет иметь активный экземпляр этой БД, который будет использоваться при обслуживании пользовательских запросов всей этой фермы. В случае недоступности активной ноды БД перестроится на другом сервере и начнёт обслуживать запросы клиентов.

Среда исполнения

Три виртуальных сервера на базе Windows Server 2008 R2 Enterprise EN. Корпоративная редакция ОС потребуется нам из-за необходимости использования средств Windows Failover Clustering.

Каждый из серверов имеет по два сетевых интерфейса.

Серверам присвоены имена — KOM-AD01-RDS01 , KOM-AD01-RDS02 и KOM-AD01-RDS03.

Создаваемый в процессе описания кластерный экземпляр Windows Failover Clustering будет иметь имя KOM-AD01-RDSCL.

Кластеризованный экземпляр службы RD Connection Broker будет иметь имя KOM-AD01-RDCB

С точки зрения сетевого взаимодействия, упрощённая схема отказоустойчивой фермы RDS в нашем случае будет выглядеть так:

Настраиваем сетевые параметры

Итак, на каждом сервере мы имеем по два сетевых интерфейса. Назовём их NIC1 – Public и NIC2 – Cluster и условимся, что согласно нашей схемы, NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера) а NIC2 будет отвечать за работу сервера в кластере Windows Failover Cluster.

Выполним описанные ниже настройки на каждом из трёх серверов.

Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).

NIC1 должен иметь приоритет над NIC2, то есть в списке подключений должен стоять первым.

Интерфейс NIC1 настроим обычным образом, задав ему IP адрес (согласно нашей схемы), маску подсети, IP адрес шлюза, адреса DNS серверов. Несколько иначе будет настроен интерфейс NIC2.

В свойствах кластерного интерфейса NIC2 можно отключить все компоненты, за исключением TCP/IP:

В свойствах компонента TCP/IP зададим только выделенный IP адрес и маску подсети. Кластерная подсеть должна отличаться от от подсети интерфейса NIC1 иначе в дальнейшем при создании кластера могут возникнуть проблемы с автоматическим созданием кластерных сетей. Также нужно понимать, что так как мы не указываем на этом интерфейсе адрес шлюза, все три сервера через этот интерфейс должны находиться в одном физическом сегменте сети.

Здесь же, по кнопке Advanced откроем окно дополнительных настроек

В окне дополнительных настроек TCP/IP на закладке DNS отключаем опцию регистрации этого подключения в DNS – Register this connection’s addresses in DNS 

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

Устанавливаем роль Remote Desktop Services

На каждом из серверов выполняем установку необходимых нам компонент роли Remote Desktop Services. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Roles вызываем мастер добавления ролей действием Add Roles

В открывшемся окне мастера выбираем роль Remote Desktop Services

Далее нам будет предложено выбрать соответствующие службы роли. Отмечаем Remote Desktop Session Host и Remote Desktop Connection Broker

На следующем шаге нужно выбрать режим аутентификации. Учитывая то, что в нашем окружении нет устаревших клиентов не поддерживающих NLA, выбираем рекомендуемый метод – Require Network Level Authentication

Значение этой настройки, как и всех других в этом мастере можно будет в изменить позже в любое время после установки роли с помощью оснасток управления RDS

На шаге выбора режима лицензирования выбираем опцию Configure later , так как для конфигурирования параметров режима лицензирования наших терминальных серверов мы в дальнейшем будем использовать возможности доменных групповых политик.

На шаге выбора групп добавим заранее созданную доменную группу безопасности, в которую будут включаться пользователи имеющие потребность в доступе к ресурсам расположенным на серверах создаваемой фермы RDS. После установки роли на сервере будет создана специальная локальная группа безопасности Remote Desktop Users в которую и будут включены выбранные нами на этом шаге группы

На следующем шаге мы сможем включить признак установки поддержки расширенных медиа компонент. Под Desktop Experience понимается установка дополнительных пользовательских компонент в составе:

• Windows Calendar
• Windows Mail
• Windows Media Player
• Desktop themes
• Video for Windows (AVI support)
• Windows Photo Gallery
• Windows SideShow
• Windows Defender
• Disk Cleanup
• Sync Center
• Sound Recorder
• Character Map
• Snipping Tool

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

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

Включаем поддержку кластеров — Failover Clustering

На каждом из серверов выполняем установку компоненты для возможности работы с кластером — Failover Clustering. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Features вызываем мастер добавления возможностей действием Add Features

В открывшемся окне мастера добавления возможностей выбираем Failover Clustering

Создаём кластер

На любом из трёх серверов, например на сервере KOM-AD01-RDS01 открываем оснастку Failover Cluster Manager (Cluadmin.msc) и в меню действий Action выбираем пункт создания нового кластера – Create a Cluster

В открывшемся мастере создания кластера добавляем все три сервера которые мы планируем включить в будущий кластер

На следующем шаге мастера укажем имя и IP адрес выделенный для администрирования кластера. Нужно учесть, что здесь задается не то имя, которое будет использоваться для подключения клиентов RDS, а то которое необходимо для обслуживания самого кластерного экземпляра Windows Server 2008 R2, на который мы в последствии будем добавлять кластеризованную службу RD Connection Broker.

Далее, исходя из нашей конфигурации, мастером будет автоматически создан кластер с моделью кворума большинства узлов — Node Majority. Это значит, что наш кластер будет оставаться в работоспособном состоянии (принимать запросы от клиентов) только в том случае, если будет доступно минимум два серверных узла из трёх. Такая модель кластера снимает требование к общему кластерному диску и мы можем получить дополнительный уровень абстрагирования от физической среды с использованием FC/SAS/iSCSI

В процессе создания кластера в домене должна быть создана его учетная запись (cluster name object) и выполнена регистрация указанного имени в DNS.

Настраиваем кластерные ресурсы

После того как экземпляр кластера создан, нам нужно настроить кластерные сети, чтобы один сетевой интерфейс использовался для клиентских подключений, а второй был ограничен исключительно для использования межузлового кластерного обмена. В свойствах кластерной сети, предназначенной для Cluster Heartbeat (в нашем случае это Cluster Network 2) должна быть отключена опция Allow clients to connect through this network. Таким образом, мы заставим кластер использовать данную кластерную сеть, состоящую из интерфейсов NIC2, только в целях межузлового обмена.

Теперь в нашем кластере мы можем создать службу RD Connection Broker. Для этого в разделе Services and applications выберем пункт Configure a Service or Application

В открывшемся мастере высокой доступности из списка доступных для кластеризации служб и приложений выберем службу Remote Desktop Connection Broker

Обратите внимание на то, что в официальной документации есть информация об ограничениях в ситуации когда вы хотите создать кластеризованный экземпляр службы RD Connection Broker в уже существующем кластере и при этом в этом кластере есть настроенные ранее службы типа Generic Service.

На следующем шаге мастера введём имя и IP адрес точки доступа к службе. Именно эти данные в дальнейшем и будут нами использоваться для настройки фермы RD Connection Broker

На этапе создания службы в кластере в домене также будет создана дополнительная учетная запись и будет произведена регистрация имени в DNS

После окончания работы мастера в консоли управления кластером мы можем убедиться в том что кластеризованный экземпляр службы успешно создан, запущен и его активным владельцем является сервер KOM-AD01-RDS02. Также обращаем внимание на то, что по умолчанию включён режим автозапуска данной службы при начале работы кластера.

Нужно проверить то, что адрес кластерного ресурса службы RDCB корректно зарегистрировался в DNS и доступен в сети.

Включаем сервера в ферму RD Connection Broker

На каждом сервере с службой RD Connection Broker добавляем все наши сервера RD Session Host в локальную группу безопасности Session Broker Computers. В нашем случае это нужно сделать на всех трёх серверах.

Затем, на каждом из трёх наших серверов RD Session Host открываем консоль Remote Desktop Session Host Configuration (Start > Administrative Tools > Remote Desktop Services) и в разделе Edit settings, выбираем настройку Member of farm in RD Connection Broker.

На вкладке RD Connection Broker нажимаем кнопку Change Settings.

В окне RD Connection Broker Settings выбираем Farm member и вводим имя кластерного экземпляра службы RDCB. Имя создаваемой фермы в поле Farm name по рекомендации оставим схожим с именем кластерного экземпляра.

Отметим опцию Participate in Connection Broker Load-Balancing для включения механизма балансировки нагрузки в ферме RD Connection Broker. Значение Relative weight определяет относительный вес данного сервера в ферме (по умолчанию – 100). В том случае, если вы зададите вес одного сервера 100, а другого 50, это приведёт к тому, что сервер с меньшим весом будет получать в 2 раза меньше подключений.

Тип перенаправления оставим в значении по умолчанию — IP address redirection и отметим IP адрес интерфейса которым у нас будут обслуживаться пользовательские сессии на этом конкретном сервере.

В типичной конфигурации фермы RD Connection Broker предлагается использовать механизм DNS Round Robin для подключения клиентов к ферме. Вместо этого, в нашем случае, для подключения клиентов будет использоваться имя кластеризованного экземпляра RD Connection Broker и в дополнительных манипуляциях с DNS нет необходимости.

Для того чтобы проверить то, что наша ферма действительно создалась, в корневом элементе консоли Remote Desktop Services Manager в меню действий выберем пункт Import from RD Connection Broker…

… и укажем FQDN имя нашего кластеризованного экземпляра RD Connection Broker

После этого в консоли должна появиться информация о созданной ферме и задействованных в ней серверах с ролью RD Session Host

Уже на этом этапе можно попробовать работу нашей фермы в действии подключившись RDP клиентом на адрес фермы. При отключении пользовательского сеанса и повторном подключении RDCB должен направлять нас в уже существующую сессию.

Настраиваем сертификаты серверов RDSH фермы RDCB

При попытке подключения к ферме RD Connection Broker по короткому имени или FQDN клиенты могут получать предупреждение безопасности, говорящее о том что нет доверия сертификату того сервера сеансов на который он был перенаправлен

Если открыть свойства этого сертификата мы увидим что сертификат создаваемый на сервере RDSH по умолчанию является самоподписанным.

Чтобы избежать таких предупреждений нам нужно создать для каждого сервера сеансов сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС.

При создании запроса на сертификат необходимо использовать политику применения — Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)

Если в перспективе на ваших терминальных серверах вы планируете использование технологии RemoteApp с использованием цифровой подписи распространяемых RDP-файлов, то возможно вам резонно будет в запрос включить так же и политику применения  — Подписывание кода (1.3.6.1.5.5.7.3.3)

Также при создании запроса на сертификат нужно учесть то, что создаваемый сертификат желательно иметь с альтернативными именами объекта – Subject Alternative Name (SAN). В противном случае при подключении клиенты могут получать предупреждение безопасности RDP клиента о том, что имя которое мы используем для подключения не совпадает с именем сервера на который его перенаправляет RD Connection Broker

Мы можем создать единый сертификат который будет установлен на все сервера фермы и будет содержать в себе все возможные имена SAN.

Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. На примере изолированного ЦС проверить это можно выполнив на сервере ЦС команду.

certutil -getreg PolicyEditFlags

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

certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 
net stop certsvc 
net start certsvc

Подробнее об использовании Subject Alternative Name в цифровых сертификатах можно найти по ссылкам:

• Windows Server TechCenter — How to Request a Certificate With a Custom Subject Alternative Name
• KB931351 — How to add a Subject Alternative Name to a secure LDAP certificate
• PowerShell Crypto Guy’s weblog  > How to add FQDN to HP iLO request

Подготовим файл параметров для создания запроса на получение нужного нам сертификата. Это обычный текстовый файл, назовём его например RequestPolicy.inf

Содержимое этого файла в нашем примере выглядит так:

[Version]

Signature=«$Windows NT$»

[NewRequest]

Subject = «CN=KOM-AD01-RDSCB.holding.com» ;

Exportable = TRUE; Private key is exportable

KeyLength = 2048

KeySpec = 1; Key Exchange – Required for encryption

KeyUsage = 0xA0; Digital Signature, Key Encipherment

MachineKeySet = TRUE

ProviderName = «Microsoft RSA SChannel Cryptographic Provider»

RequestType = PKCS10

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

OID=1.3.6.1.5.5.7.3.3 ; Code signing

[RequestAttributes]

SAN  = «dns=KOM-AD01-RDSCB.holding.com&»

_continue_ = «dns=KOM-AD01-RDS01.holding.com&»

_continue_ = «dns=KOM-AD01-RDS02.holding.com&»

_continue_ = «dns=KOM-AD01-RDS03.holding.com&»

_continue_ = «dns=KOM-AD01-RDSCB&»

_continue_ = «dns=KOM-AD01-RDS01&»

_continue_ = «dns=KOM-AD01-RDS02&»

_continue_ = «dns=KOM-AD01-RDS03&»

_continue_ = «dns=10.160.0.39&»

_continue_ = «dns=10.160.0.41&»

_continue_ = «dns=10.160.0.42&»

_continue_ = «dns=10.160.0.43&»

С помощью встроенной в ОС утилиты CertReq.exe создадим файл запроса на основе файла параметров:

cd /d C:Temp 
CertReq –New RequestPolicy.inf RequestFile.req

Далее, на основании полученного файла запроса RequestFile.req в локальном центре сертификации можно получить сертификат. В нашем случае для отправки запроса и получения сертификата будет использоваться веб-узел локального изолированного ЦС Active Directory Certificate Services. Действия по запросу и получению сертификата нужно выполнять непосредственно с одного из тех серверов для которых будем создавать этот сертификат. В нашем примере мы выполним запрос и получения сертификата с сервера KOM-AD01-RDS01 

Итак на веб-узле локального ЦС последовательно перейдём по ссылкам:

Request a certificate >
advanced certificate request >
Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

и скопируем содержимое сгенерированного ранее запроса из файла RequestFile.req

После того как размещённый запрос на сертификат обработан администратором центра сертификации, мы можем с этого же веб-узла локального ЦС загрузить сертификат в формате Base 64 encoded пройдя по ссылке:

View the status of a pending certificate request

Будет предложено загрузить файл сертификата в формате PKCS #7 с именем certnew.p7b

Устанавливаем в систему полученный сертификат командой:

CertReq -accept certnew.p7b

После этого в консоли управления сертификатами в хранилище Local ComputerPersonal можно будет увидеть новый установленный сертификат, подписанный доверенным локальным ЦС

Затем на этом же сервере открываем консоль Remote Desktop Session Host Configuration и в разделе Connections, открываем свойства подключения.

В окне свойств подключения на закладке General в секции Security нажимаем кнопку Select для того чтобы выбрать только что установленный в систему сертификат

В окне выбора сертификатов выбираем соответствующий сертификат…

После этого сохраняем настройки свойств подключения

Теперь нам нужно установить этот же сертификат на другие два сервера – KOM-AD01-RDS02 и KOM-AD01-RDS03. Для этого в консоли управления сертификатами на сервере KOM-AD01-RDS01 выполним экспорт сертификата с закрытым ключом из хранилища Certificates /Local Computer/Personal.

В открывшемся мастере экспорта сертификата на странице Export Private Key выберем опцию Yes, export the private key

На странице Export File Format выбран один возможный вариант формата выгрузки — Personal Information Exchange – PKCS #12 (.PFX)

Затем вводим пароль для защиты закрытого ключа, который мы в дальнейшем будем использовать для импорта сертификата на серверах KOM-AD01-RDS02 и KOM-AD01-RDS03

Далее указываем имя файла в который будет экспортирован сертификат

Полученный файл в формате PFX копируем на другие два сервера и, открыв на них консоль управления сертификатами в хранилище Local ComputerPersonal вызываем мастер импорта сертификата

В открывшемся мастере импорта сертификата указываем расположение PFX файла содержащего сертификат с закрытым ключом

Затем указываем пароль, с которым ранее сертификат был экспортирован. Устанавливать признак экспортируемости ключа (Mark this key as exportable..) вовсе не обязательно.

На следующем шаге будет предложено выбрать хранилище сертификатов в которое производится импорт. Оставим значение Personal

После того как сертификат импортирован, откроем консоль Remote Desktop Session Host Configuration в разделе Connections, открываем свойства подключения и выполним привязку к установленному сертификату методом описанным ранее.

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

В конечном результате описанных действий подключение клиентов должно работать без предупреждений безопасности.

Дополнительные источники информации:

• Windows Server TechCenter — Deploying Remote Desktop Connection Broker with High Availability Step-by-Step Guide
• TechNet Blogs > Mark Ghazai’s Blog > Windows Server 2008 R2 Highly Available (Clustered) Remote Desktop Connection Broker
• ITBand.ru — Dmitry Rudykh — TS Session Broker

Кластеры от компании Microsoft.

Несмотря на неоднозначное отношение к Microsoft необходимо отметить, что компания сделала высокие технологии доступными для простых пользователей. Так или иначе, но современное положение сферы информационных технологий не в последнюю очередь определено именно компанией Microsoft.

Далеко не всегда решения и продукты от компании Microsoft сразу занимали позиции на уровне специализированных решений, однако наиболее важные все равно постепенно выбивались в лидеры в соотношении цена/функциональность, а также по простоте внедрения. Одним из таких примеров являются кластеры.

Разработка вычислительных кластеров не является сильной стороной Microsoft. Об этом свидетельствует, в том числе, тот факт, что разработки компании не попали в список Top-500 суперкомпьютеров. Поэтому совершенно логично, что в линейке Windows Server 2012 отсутствует редакция HPC (High-performance computing –высокопроизводительные вычисления).

Кроме того, учитывая особенности высокопроизводительных вычислений, платформа Windows Azure кажется более перспективной. Поэтому компания Microsoft сосредоточила свое внимание на кластерах высокой доступности.

Кластеры в Windows.

Впервые поддержка кластеров была реализована компанией Microsoft еще в операционной системе в Windows NT 4 Server Enterprise Edition в виде технологии Microsoft Cluster Service (MSCS). В операционной системе Windows Server 2008 она превратилась в компонент Failover Clustering. По сути это кластеры с обработкой отказа или высокодоступные кластеры, хотя иногда их не вполне корректно называют отказоустойчивыми.

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

Кластер высокой доступности на Windows включает в себя как минимум два узла с установленными операционными системами и соответствующими ролями. Узлы должны быть подключены к внешней сети и внутренней сети, необходимой для обмена служебными сообщениями, к общему хранилищу служебных ресурсов (например, диск-свидетель для кворума). Кроме того, в систему входят и данные кластеризуемых приложений. В ситуации, когда сервисы исполняются только на одном из узлов, реализуется схема Active-Passive, то есть сервисы выполняются на одном узле, а второй работает в дежурном режиме. Когда оба узла несут полезную нагрузку, реализуется схема Active-Active.

С момента первой реализации, поддержка кластеров в Windows существенно изменилась. Была реализована поддержка файловых и сетевых служб, позже SQL Server (в операционной системе Windows Server 2000), Exchange Server ( в Windows Server 2003), и другие стандартные службы и роли, включая Hyper-V (в операционной системе Windows Server 2008). Была улучшена масштабируемость (до 64 узлов в Windows Server 2012), список кластеризуемых сервисов был расширен.

Поддержка виртуализации, а также позиционирование Windows Server как облачной операционной системы, стали поводом для дальнейшего развития поддержки кластеров, поскольку высокая плотность вычислений предъявляет высокие требования к надежности и доступности инфраструктуры. Поэтому, начиная с операционной системы Windows Server 2008, именно в этой области сосредоточена основная масса усовершенствований.

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

В Windows Server 2012 кластерная поддержка Hyper-V была усовершенствована. Была добавлена возможность управления на уровне целого кластера приоритетами виртуальных машин, определяющих порядок перераспределения памяти, восстановления вирутальных машин в случае выхода из строя узлов или запланированной массовой миграции. Были расширены возможности мониторинга – в случае сбоя контролируемой службы появилась возможность перезапуска не только самой службы, но и всей виртуальной машины. Есть возможность осуществления миграции на другой, менее загруженный узел. Реализованы и другие, не менее интересные нововведения, касающиеся кластеризации.

Кластеры в Windows Server 2012.

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

SMB 3.0

Новая версия протокола SMB 3.0 используется для сетевого обмена данными. Этот протокол востребован при выполнении чтения, записи и других файловых операций на удаленных ресурсах. В новой версии реализовано большое количество усовершенствований, которые позволяют оптимизировать работу SQL Server, Hyper-V и файловых кластеров. Обратим внимание на следующие обновления:

• прозрачная отказоустойчивость. Это новшество обеспечивает непрерывность выполнения операций. При сбое одного из узлов файлового кластера текущие операции автоматически передаются другому узлу. Благодаря этому нововведению стала возможной реализация схемы Active-Active с поддержкой до 8 узлов.
• масштабирование. Благодаря новой реализации общих томов кластера (версия 2.0) существует возможность одновременного доступа к файлам через все узлы кластера, за счет чего достигается агрегация пропускной способности и осуществляется балансировка нагрузки.
• SMB Direct. Реализована поддержка сетевых адаптеров с технологией RDMA. Технология RDMA (удаленный прямой доступ к памяти) позволяет передавать данные непосредственно в память приложения, существенно освобождая центральный процессор.
• SMB Multichannel. Позволяет агрегировать пропускную способность и повышает отказоустойчивость при наличии нескольких сетевых путей между сервером с поддержкой SMB 3.0 и клиентом.

Необходимо сказать, что для использования этих возможностей поддержка SMB 3.0 должна присутствовать на обоих концах соединения. Компания Microsoft рекомендует использование серверов и клиентов одного поколения (в случае с Windows Server 2012 такой клиентской платформой является Windows 8). К сожалению, на сегодня Windows 7 поддерживает только SMB версии 2.1.

Storage Spaces.

Технология Storage Spaces реализована впервые в операционных системах Windows Server 2012 и Windows 8. Реализована поддержка новой файловой системы ReFS, которая обеспечивает функции повышения отказоустойчивости. Есть возможность назначения дисков в пуле для горячей замены (в случае отказа других носителей или для быстрой замены исчерпавшего свой ресурс SSD). Кроме того, расширены возможности тонкой настройки с использованием PowerShell.

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

Далее на пулах можно создавать виртуальные диски следующих типов (не путать с VHD/VHDX):

• простой (является аналогом RAID 0);
• зеркало (двухстороннее зеркало является аналогом RAID1, трехстороннее зеркало представляет собой более сложную схему наподобие RAID 1E)
• с контролем четности (является аналогом RAID 5. Данный вариант обеспечивает минимальный перерасход пространства при минимальной отказоустойчивости).

Технология Storage Spaces не является абсолютным новшеством. Похожие возможности были давно реализованы в Windows Server, например в форме динамических дисков. Технология Storage Spaces позволяет сделать использование всех этих возможностей более удобными и обеспечить новый уровень использования. Среди прочих преимуществ Storage Spaces необходимо отметить тонкую инициализацию (thin provisioning), которая дает возможность назначать виртуальным дискам размеры сверх доступных в реальности из расчета на добавление в соответствующий пул новых накопителей впоследствии.

Один из наиболее непростых вопросов, связанных с технологией Storage Spaces – это производительность. Как правило, программные реализации RAID уступают по производительности аппаратным вариантам. Однако, если речь идет о файловом сервере, то Storage Spaces получает в свое распоряжение большой объем оперативной памяти и мощный процессор, поэтому необходимо тестирование с учетом различных видов нагрузки. С этой точки зрения особую ценность приобретают возможности тонкой настройки с использованием PowerShell.

Технология Storage Spaces предлагает отказ от RAID-контроллеров и дорогих систем хранения, перенеся из логику на уровень операционной системы. Эта идея раскрывает все свои достоинства и оказывается достаточно привлекательной вместе с еще одним новшеством.

Scale-Out File Server (SOFS).

Еще одним новшеством является режим кластеризуемой роли File Server в Windows Server 2012, который получил название Scale-Out File Server. Теперь реализована поддержка двух типов кластеризации, названия которых полностью звучат как File Sever for General Use и Scale-Out File Server (SOFS) for application data. Каждая из технологий имеет свои сферы применения, а также свои достоинства и недостатки.

Всецелевой файловый сервер представляет собой хорошо известный тип кластера Active-Passive. В свою очередь SOFS представляет собой кластер Active-Active, являясь действительно отказоустойчивой конфигурацией. Для совместного доступа к соответствующим папкам используется опция Continuously Available.

Помимо отличных характеристик отказоустойчивости это обеспечивает повышение пропускной способности при условии рационального проектирования сетевой архитектуры. Проксирующая файловая система CSV 2.0 (CSVFS) позволяет уменьшить влияние CHKDSK, позволяя утилите выполнять необходимые операции, сохраняя при этом возможность работы с томом активных приложений. Реализовано кэширование чтения с CSV. Использование CSV обеспечивает простоту и удобство развертывания и управления. Пользователю нужно создать обычный кластер, настроить том CSV и активировать роль файлового сервера в режиме Scale-Out File Server for application data.

Благодаря простоте и функциональности предложенного решения сформировался новый класс оборудования «кластер-в-коробке» (Сluster-in-a-Box, CiB). Как правило, это шасси с двумя блейд-серверами и дисковым массивом SAS JBOD с поддержкой Storage Spaces. Здесь важно, чтобы SAS JBOD были двухпортовыми, и имелся SAS HBA для реализации перекрестного подключения.

Такая организация системы ориентирована именно на поддержку SOFS. Учитывая, что iSCSI target стандартно интегрирован в Windows Server 2012 и также может быть кластеризована, таким образом может реализовать «самодельную» систему хранения данных на базе всецелевой операционной системы.

Однако следует иметь ввиду, что владельцем CSV по-прежнему является один из узлов, который отвечает за все операции с метаданными. При большом количестве метаданных может наблюдаться снижение производительности, поэтому для SOFS не рекомендуется использовать сценарий Information Worker, тогда как Hyper-V и SQL Server идеально подходят для этого, в том числе благодаря функциям агрегации пропускной способности.

Другие новшества технологий кластеризации Windows.

Выше мы перечислили только самые важные и крупные новшества в области кластеризации в Windows Server 2012. Другие менее крупные нововведения, однако, тоже появились не случайно.

Была расширена поддержка виртуализации за счет существенного упрощения создания гостевых кластеров (из виртуальных машин). В отличие от Windows Server 2008 R2, где для этого нужно было предоставить iSCSI Target в общее пользование виртуальных машин, в операционной системе Windows Server 2012 появилась функция, позволяющая виртуализировать FC-контроллер (по аналогии с сетевыми адаптерами), за счет чего виртуальные машины получают возможность непосредственного доступ к LUN. Реализован и более простой вариант с использованием общей сетевой папки SMB 3.0 для гостевых Windows Server 2012.

Одной из важных, но нетривиальных задач является установка программных обновлений в кластере. При этом может потребоваться перезагрузка узлов, поэтому процедура должна контролироваться. В операционной системе Windows Server 2012 предлагается инструмент Cluster-Aware Updating, который работает следующим образом: один из узлов назначается координатором и следит за наличием обновлений, загружает их на остальные узлы и выполняет поочередное обновление узлов, начиная с тех, которые загружены меньше всего. Благодаря этому доступность кластера сохраняется на максимально возможном уровне в течение всего процесса обновления.

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

Новшества в Windows Server 2012 R2.

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

Высокодоступные виртуальные машины.

Упрощена процедура создания гостевых кластеров, поскольку теперь появилась возможность использовать в качестве общего хранилища обычные VHDX, которые внутри виртуальной машины будут представлены как Shared SAS-диски. При этом сами VHDX должны быть размещены на CSV или в общих папках SMB 3.0. При этом в виртуальных машинах могут использоваться как Windows Server 2012 R2, так и Windows Server 2012 (с обновленными интеграционными компонентами).

Опция DrainOnShutdown призвана избавить системных администраторов от ошибок и лишней работы. Функция активирована по умолчанию и при плановых перезагрузках или выключениях заранее переводит узел в такой режим обслуживания при котором эвакуируются все кластеризованные роли. При этом происходит миграция активных виртуальных машин на другие узлы кластера Hyper-V.

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

Кворум.

Кроме динамического кворума в Windows Server 2012 R2 реализован еще и динамический диск-свидетель (witness). При изменении числа узлов его голос может быть автоматически учтен, так, чтобы общее число голосов оставалось нечетным. В случае, если сам диск окажется недоступным, его голос будет просто обнулен. Такая схема позволяет полностью положиться на автоматические механизмы, отказавшись от моделей кворума.

Увеличена надежность работы кластеров, размещенных на двух площадках. Часто при такой реализации на каждой площадке находится ровно половина узлов, поэтому нарушения коммуникации между площадками может возникнуть проблема с формированием кворума. Хотя с большинством подобных ситуаций успешно справляется механизм динамического кворума, в Windows Server 2012 R2 существует возможность назначить одной из площадок низкий приоритет, для того, чтобы в случае сбоя кластер всегда функционировал на основной площадке. В случае, если кластер был запущен с принудительным кворумом, то при восстановлении связи с удаленной площадкой службы кластера будут перезапущены в автоматическом режиме и весь кластер будет вновь объединен.

CSV 2.1

Существенные изменения коснулись и реализации CSV. Теперь роли владельцев томов равномерно распределяются по узлам в автоматическом режиме, в соответствии с изменением их числа. Увеличена отказоустойчивость CSV благодаря тому, что на каждом узле кластера запускается по два экземпляра серверной службы. Один используется для обслуживания клиентского SMB-трафика, другой обеспечивает коммуникацию между узлами. При этом обязательно производится мониторинг службы и в случае сбоя роль владельца CSV мигрирует на другой узел.

Целый ряд новшеств в CSV обеспечивает более эффективное использование SOFC и Storage Spaces. Добавлена поддержка файловой системы ReFS, которая обладает более совершенной, чем NTFS внутренней организацией. Скорее всего постепенно эта файловая система займет ведущее положение в продуктах компании Microsoft. Также в Windows Server 2012 R2 реализован механизм дедупликации, который ранее был прерогативой всецелевого файлового сервера. Активация дедупликации приводит к отключению CSV Block Cache, однако в некоторых случаях она может быть достаточно эффективной. Тома CSV могут создаваться на дисковых пространствах с контролем четности.

В Windows Server 2012 R2 возможность комбинировать накопители различных типов приобрела особый смысл с многоуровневыми пространствами. Появилась возможность формировать два уровня быстрый (на основе SSD) и емкий (на основе жестких дисках) и при создании виртуального диска выделять определенный объем из каждого из них. Далее в соответствии с некоторым расписанием содержимое виртуального диска будет анализироваться и размещаться блоками по 1 МБ на более быстрых или медленных носителях в зависимости от востребованности. Другим применением многоуровневых пространств является реализация кэша с обратной записью на SSD. В моменты пиковых нагрузок запись осуществляется на быстрые твердотельные накопители, а позже холодные данные перемещаются на более медленные жесткие диски.

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

Решения виртуализации VMware.

Как и многие из вас я проводил тесты и могу поделиться с вами некоторой информацей относительно шагов создания кластера на базе 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. Надеюсь это стало полезным для вас.