Титаны кластерного фронта: Решения для построения кластеров от Microsoft и Oracle. Конфигурирование сетевого адаптера частной сети

25.04.2019 Операционные системы

Уже на этапе планирования будущей виртуальной инфраструктуры следует задуматься об обеспечении высокой доступности ваших виртуальных машин. Если в обычной ситуации временная недоступность одного из серверов еще может быть приемлема, то в случае остановки хоста Hyper-V недоступной окажется значительная часть инфраструктуры. В связи с чем резко вырастает сложность администрирования - остановить или перезагрузить хост в рабочее время практически невозможно, а в случае отказа оборудования или программного сбоя получим ЧП уровня предприятия.

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

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

В данном материале мы будем рассматривать наиболее простую конфигурацию отказоустойчивого кластера, состоящего из двух узлов (нод) SRV12R2-NODE1 и SRV12R2-NODE2, каждый из которых работает под управлением Windows Server 2012 R2. Обязательным условием для этих серверов является применение процессоров одного производителя, только Intel или только AMD, в противном случае миграция виртуальных машин между узлами будет невозможна. Каждый узел должен быть подключен к двум сетям: сети предприятия LAN и сети хранения данных SAN.

Вторым обязательным условием для создания кластера является наличие развернутой Active Directory, в нашей схеме она представлена контроллером домена SRV12R2-DC1.

Хранилище выполнено по технологии iSCSI и может быть реализовано на любой подходящей платформе, в данном случае это еще один сервер на Windows Server 2012 R2 - SRV12R2-STOR. Сервер хранилища может быть подключен к сети предприятия и являться членом домена, но это необязательное условие. Пропускная способность сети хранения данных должна быть не ниже 1 Гбит/с.

Будем считать, что на оба узла уже установлена операционная система, они введены в домен и сетевые подключения настроены. Откроем Мастер добавления ролей и компонентов и добавим роль Hyper-V .

Следующим шагом добавим компоненту Отказоустойчивая кластеризация .

На странице настройки виртуальных коммутаторов выбираем тот сетевой адаптер, который подключен к сети предприятия.

Миграцию виртуальных машин оставляем выключенной .

Остальные параметры оставляем без изменения. Установка роли Hyper-V потребует перезагрузку, после чего аналогичным образом настраиваем второй узел.

Затем перейдем к серверу хранилища, как настроить iSCSI-хранилище на базе Windows Server 2012 мы рассказывали в , но это непринципиально, вы можете использовать любой сервер цели iSCSI. Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин. Диск-свидетель - это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.

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

И сопоставьте данной цели созданные виртуальные диски.

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

Подключенные диски инициализируем и форматируем.

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

После чего откроем Диспетчер Hyper-V и перейдем к настройке виртуальных коммутаторов. Их название на обоих узлах должно полностью совпадать .

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

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

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

Если существенных ошибок не обнаружено работа мастера завершится и он предложит вам создать на выбранных узлах кластер.

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

При создании кластера для него создается виртуальный объект, обладающий сетевым именем и адресом. Укажем их в открывшемся Мастере создания кластеров .

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

Закроем мастер и развернем дерево слева до уровня Хранилище - Диски , в доступных действиях справа выберем Добавить диск и укажем подключаемые диски в открывшемся окне, в нашем случае их два.

Затем щелкнем правой кнопкой мыши на объекте кластера в дереве слева и выберем Дополнительные действия - Настроить параметры кворума в кластере .

Далее последовательно выбираем: Выбрать свидетель кворума - Настроить диск-свидетель и указываем созданный для этих целей диск.

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

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

Общие хранилища становятся доступны на всех узлах кластера в расположении C:\ClusterStorage\VolumeN . Обратите внимание, что это не просто папки на системном диске, а точки монтирования общих томов кластера.

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

На этом настройка кластера закончена. Для работы с кластеризованными виртуальными машинами следует использовать Диспетчер отказоустойчивости кластеров , а не Диспетчер Hyper-V , который предназначен для управления виртуалками расположенными локально.

Чтобы создать виртуальную машину перейдите в раздел Роли в меню правой кнопки мыши выберите Виртуальные машины - Создать виртуальную машину , это же можно сделать и через панель Действия справа.

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

После выбора узла откроется стандартный Мастер создания виртуальной машины, работа с ним не представляет сложности, поэтому остановимся только на значимых моментах. В качестве расположения виртуальной машины обязательно укажите один из общих томов кластера C:\ClusterStorage\VolumeN .

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

После создания виртуальной машины перейдите в ее Параметры и в пункте Процессоры - Совместимость установите флажок Выполнить перенос на физический компьютер с другой версией процессора , это позволит выполнять миграцию между узлами с разными моделями процессоров одного производителя . Миграция с Intel на AMD или наоборот невозможна .

Затем перейдите в Сетевой адаптер - Аппаратное ускорение и убедитесь, что выбранные опции поддерживаются сетевыми картами всех узлов кластера или отключите их.

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

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

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

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

На этом настройка виртуальной машины закончена, можем запускать и работать с ней.

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

Каким образом происходит миграция в рабочей обстановке? Допустим нам надо выключить или перезагрузить первый узел, на котором в данный момент выполняется виртуальная машина. Получив команду на завершение работы узел инициирует передачу виртуальных машин:

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

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

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

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

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

Теги:

Please enable JavaScript to view the

Пресс-центр

Создание кластера на базе Windows 2000/2003. Шаг за шагом

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

Microsoft Windows 2000/2003 поддерживает две технологии кластеризации: кластеры с балансировкой нагрузки (Network Load Balancing) и кластеры серверов.

В первом случае (кластеры с балансировкой нагрузки) служба Network Load Balancing придает службам и приложениям свойства высокого уровня надежности и масштабируемости за счет объединения до 32 серверов в единый кластер. Запросы от клиентов в данном случае распределяются среди узлов кластера прозрачным образом. При отказе узла кластер автоматически изменяет свою конфигурацию и переключает клиента на любой из доступных узлов. Этот режим конфигурации кластера также называется active-active режимом, когда одно приложение работает на нескольких узлах.

Кластер серверов распределяет свою нагрузку среди серверов кластера, причем каждый сервер несет свою собственную нагрузку. Если происходит отказ узла в кластере, то приложения и службы, настроенные на работу в кластере, прозрачным образом перезапускаются на любом из свободных узлов. Кластеры серверов используют разделяемые диски для обмена данными внутри кластера и для обеспечения прозрачного доступа к приложениям и службам кластера. Для них требуется специальное оборудование, но данная технология обеспечивает очень высокий уровень надежности, поскольку сам кластер не имеет какой-либо единственной точки отказа. Этот режим конфигурации кластера также называется active-passive режимом. Приложение в кластере работает на одном узле с общими данными, расположенными на внешнем хранилище.

Кластерный подход к организации внутренней сети дает следующие преимущества:

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

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

Требования к программному обеспечению

Microsoft Windows 2000 Advanced (Datacenter) Server или Microsoft Windows 2003 Server Enterprise Edition, установленные на всех серверах кластера.
Установленная служба DNS. Немного поясню. Если вы строите кластер на основе двух контроллеров домена, то намного удобнее использовать службу DNS, которую вы в любом случае устанавливаете при создании Active Directory. Если вы создаете кластер на основе двух серверов, членов Windows NT домена, то вам придется использовать либо службу WINS, либо заносить соответствие имен и адресов машин в файл hosts.
Terminal Services для удаленного управления серверами. Не обязательно, но при наличии Terminal Services удобно управлять серверами со своего рабочего места.

Требования к аппаратному обеспечению

Аппаратное обеспечение для узла кластера лучше подбирать, основываясь на Cluster Service Hardware Compatible List (HCL). По рекомендациям Microsoft аппаратное обеспечение должно быть протестировано на совместимость с Cluster Services.
Соответственно вам понадобятся два сервера, имеющих по два сетевых адаптера; SCSI-адаптер, имеющий внешний интерфейс для подключения внешнего массива данных.
Внешний массив, имеющий два внешних интерфейса. Каждый из узлов кластера подключается к одному из интерфейсов.

Замечание: для создания двухузлового кластера совсем не обязательно иметь два абсолютно одинаковых сервера. После сбоя на первом сервере у вас будет немного времени, чтобы проанализировать и восстановить работу основного узла. Второй же узел будет работать на безотказность системы в целом. Однако это не означает, что второй сервер будет простаивать. Оба узла кластера могут спокойно заниматься своими делами, решать разные задачи. А вот некий критический ресурс мы и можем настроить на работу в кластере, увеличив его (этого ресурса) отказоустойчивость.

Требования к сетевым настройкам

Уникальное NetBIOS имя для кластера.
Пять уникальных статических IP-адресов. Два для сетевых адаптеров на кластерную сеть, два для сетевых адаптеров на общую сеть и один для кластера.
Доменная учетная запись для кластерного сервиса (Cluster service).
Все узлы кластера должны быть либо member server в домене, либо контроллерами домена.
Каждый сервер должен иметь два сетевых адаптера. Один для подключения в общую сеть (Public Network), второй для обмена данными между узлами кластера (Private Network).

Замечание: по рекомендациям Microsoft ваш сервер должен иметь два сетевых адаптера, один для общей сети, второй для обмена данными внутри кластера. Можно ли строить кластер на одном интерфейсе - наверное, да, но я не пробовал.

Установка кластера

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

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

Установка двухузлового кластера может быть разделена на 5 шагов

Установка и настройка узлов в кластере.
Установка и настройка разделяемого ресурса.
Проверка дисковой конфигурации.
Конфигурирование первого узла кластера.
Конфигурирование второго узла в кластере.

Это пошаговое руководство позволит вам избежать ошибок во время установки и сэкономить массу времени. Итак, начнем.

Установка и настройка узлов

Мы немного упростим задачу. Поскольку все узлы кластера должны быть либо участниками домена, либо контроллерами домена, то корневым держателем каталога AD (Active Directory) сделаем 1-й узел кластера, на нем же будет работать DNS-служба. 2-й узел кластера будет полноправным контроллером домена.

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

Сетевые настройки

Перед началом установки кластера и Active Directory необходимо выполнить сетевые настройки. Все сетевые настройки хочется разделить на 4 этапа. Для распознавания имен в сети желательно иметь DNS-сервер с уже существующими записями о серверах кластера.

Каждый сервер имеет по две сетевые карты. Одна сетевая карта будет служить для обмена данными между узлами кластера, вторая будет работать на клиентов в нашей сети. Соответственно первый назовем Private Cluster Connection, второй назовем Public Cluster Connection.

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

My Network Places → Properties

Private Cluster Connection → Properties → Configure → Advanced

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

Internet Protocol (TCP/IP) → Properties → Use the following IP: 192.168.30.1
(Для второго узла используйте адрес 192.168.30.2). Введите маску подсети 255.255.255.252 . В качестве адреса DNS-сервера для обоих узлов используйте адрес 192.168.100.1 .
Дополнительно на вкладке Advanced → WINS выберите пункт Disabled NetBIOS over TCP/IP . Для настроек сетевых адаптеров общей (Public) сети этот пункт опустите.
Проделайте то же самое с сетевой картой для локальной сети Public Cluster Connection. Используйте адреса, приведенные в таблице. Единственная разница в конфигурации двух сетевых плат состоит в том, что для Public Cluster Connection не требуется выключения режима WINS - NetBIOS over TCP/IP .

Для конфигурирования всех сетевых адаптеров на узлах кластера используйте следующую табличку:

Узел	Сетевое имя	IP address	MASK	DNS Server
1	Public Cluster Connection	192.168.100.1	255.255.255.0	192.168.100.1
1	Private Cluster Connection	192.168.30.1	255.255.255.252	192.168.100.1
2	Public Cluster Connection	192.168.100.2	255.255.255.0	192.168.100.1
3	Private Cluster Connection	192.168.30.2	255.255.255.252	192.168.100.1

Установка Active Directory

Поскольку моя статья не преследует цель рассказать об установке Active Directory, то этот пункт я опущу. Всевозможных рекомендаций, книг об этом написано достаточно много. Выберете доменное имя, вроде mycompany.ru, установите Active Directory на первом узле, добавьте второй узел в домен в качестве контроллера домена. Когда все сделаете, проверьте конфигурации серверов, Active Directory.

Установка Cluster User Account

Start → Programs → Administrative Tools → Active Directory Users and Computers
Добавьте нового пользователя, например, ClusterService.
Установите флажки на: User Cannot Change Password и Password Never Expires .
Также добавьте этого пользователя в группу администраторов и дайте ему права Log on as a service (права назначаются в Local Security Policy и Domain Controller Security Policy ).

Настройка внешнего массива данных

Для настройки внешнего массива данных в кластере необходимо помнить, что перед установкой Cluster Service на узлах вы должны сначала сконфигурировать диски на внешнем массиве, только потом устанавливать службу кластера сначала на первом узле, только потом на втором. В случае нарушения порядка установки у вас произойдет сбой, и вы не достигнете цели. Можно ли будет исправить - наверное, да. Когда появится ошибка, у вас будет время, чтобы поправить настройки. Но Microsoft столь загадочная штука, что совсем не знаешь, на какие грабли наступишь. Проще иметь перед глазами пошаговую инструкцию и не забывать нажимать на кнопки. По шагам конфигурирование внешнего массива выглядит так:

Оба сервера должны быть выключены, внешний массив включен, подсоединен к обоим серверам.
Включаем первый сервер. Получаем доступ к дисковому массиву.
Проверяем, чтобы внешний дисковый массив был создан как Basic. Если это не так, то переведем диск с помощью опции Revert to Basic Disk .
Создаем на внешнем диске через Computer Manage-ment → Disk Management небольшой раздел. По рекомендациям Microsoft он должен быть не менее 50 Мб. Я рекомендую создать раздел в 500 Мб. или чуть больше. Для размещения кластерных данных этого вполне достаточно. Раздел должен быть отформатирован в NTFS.
На обоих узлах кластера этот раздел будет назван одной буквой, например, Q. Соответственно при создании раздела на первом сервере выберем пункт Assign the following drive letter - Q .
Оставшуюся часть диска вы можете разметить по своему желанию. Конечно, крайне желательно использовать файловую систему NTFS. Например, при настройке служб DNS, WINS основные базы служб будут перенесены на общий диск (не системный том Q, а второй, созданный вами). И по соображению безопасности вам будет удобнее использовать именно NTFS-тома.
Закрываем Disk Management и проверяем доступ к вновь созданному разделу. Например, можно создать на нем текстовый файл test.txt , записать и удалить. Если все прошло нормально, то с конфигурацией внешнего массива на первом узле мы закончили.
Теперь выключаем первый сервер. Внешний массив должен быть включен. Включаем второй сервер и проверяем доступ к созданному разделу. Также проверим, чтобы буква, назначенная первому разделу, была идентична выбранной нами, то есть Q.

На этом конфигурация внешнего массива завершена.

Установка Cluster Service Software

Конфигурация первого узла кластера

Перед началом установки Cluster Service Software все узлы кластера должны быть выключены, все внешние массивы должны быть включены. Перейдем к конфигурации первого узла. Внешний массив включен, первый сервер включен. Весь процесс установки происходит с использованием Cluster Service Configuration Wizard:

Конфигурация второго узла кластера

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

В диалоговом окне Create or Join a Cluster выберите The second or next node in the cluster и нажмите далее.
Введите имя кластера, которое мы задали ранее (в примере это MyCluster), и нажмите далее.
После подключения второго узла к кластеру Cluster Service Configuration Wizard автоматически заберет все установки с основного узла. Для запуска службы Cluster Service используйте имя, которые мы создавали ранее.
Введите пароль вашей учетной записи и нажмите далее.
В следующем диалоговом окне нажмите Finish для завершения установки.
Cluster service будет запушен на втором узле.
Закройте окно Add/Remove Programs .

Для установки дополнительных узлов кластера используйте эту же инструкцию.

Постскриптум, благодарности

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

Шаг	Узел 1	Узел 2	Внешний массив

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

Следующим шагом добавим компоненту Отказоустойчивая кластеризация .

Миграцию виртуальных машин оставляем выключенной .

Затем перейдем к серверу хранилища, как настроить iSCSI-хранилище на базе Windows Server 2012 мы рассказывали в данной статье, но это непринципиально, вы можете использовать любой сервер цели iSCSI. Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин. Диск-свидетель - это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.

И сопоставьте данной цели созданные виртуальные диски.

Подключенные диски инициализируем и форматируем.

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

Общие хранилища становятся доступны на всех узлах кластера в расположенииC:\ClusterStorage\VolumeN . Обратите внимание, что это не просто папки на системном диске, а точки монтирования общих томов кластера.

На этом настройка виртуальной машины закончена, можем запускать и работать с ней.

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

После нескольких лет молчания, решил поделиться опытом по развертыванию отказоустойчивого кластера на основе Windows Server 2012.
Постановка задачи: Развернуть отказоустойчивый кластер для размещения на нем виртуальных машин, с возможностью выделения виртуальных машин в отдельные виртуальные подсети (VLAN), обеспечить высокую надежность, возможность попеременного обслуживания серверов, обеспечить доступность сервисов. Обеспечить спокойный сон отделу ИТ.

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

Сервер HP ProLiant DL 560 Gen8 4x Xeon 8 core 64 GB RAM 2 шт.
SAS Хранилище HP P2000 на 24 2,5» дисков 1 шт.
Диски для хранилища 300 Gb 24 шт. //С объемом не густо, но к сожалению бюджеты такие бюджеты…
Контроллер для подключения SAS производства HP 2 шт.
Сетевой адаптер на 4 1Gb порта 2 шт. //Можно было взять модуль под 4 SFP, но у нас нет оборудования с поддержкой 10 Gb, гигабитного соединения вполне достаточно.

Естественно обновляем BIOS и Firmware с официального сайта.
Организация подключений:

У нас на самом деле подключено в 2 разных коммутатора. Можно подключить в 4 разных. Я считаю, что достаточно 2х.
На портах коммутаторов, куда подключены сервера необходимо сменить режим интерфейса с access на trunk, для возможности разнесения по виртуальным подсетям.

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

Создаем виртуальные диски:

Диск raid10 на основе Raid 1+0 из 4 дисков +1 spare
Диск raid5 на основе Raid 5 из 16 дисков +1 spare
2 диска - ЗИП

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

Теперь необходимо создать разделы.

raid5_quorum - Так называемый диск-свидетель (witness). Необходим для организации кластера из 2 нод.
raid5_store - Здесь мы будем хранить виртуальные машины и их жесткие диски
raid10_db - Здесь будет хранится жесткий диск виртуальной машины MS SQL сервера

Назначаем (map) наши разделы на порты sas контроллеров хранилища.
Обязательно необходимо включить feature Microsoft Multipath IO, иначе при сервера к обоим контроллерам хранилища в системе будет 6 дисков, вместо 3х, и кластер не соберется, выдавая ошибку, мол у вас присутствуют диски с одинаковыми серийными номерами, и этот визард будет прав, хочу я вам сказать.

Подключать сервера к хранилищу советую по очереди:

Подключили 1 сервер к 1 контроллеру хранилища
В хранилище появится 1 подключенный хост - дайте ему имя. Советую называть так: имясервера_номер контроллера (A или B)
И так, пока не подключите оба сервера к обоим контроллерам.

На коммутаторах, к которым подключены сервера необходимо создать 3 виртуальных подсети (VLAN):

ClusterNetwork - здесь ходит служебная информаци кластера (хэртбит, регулирование записи на хранилище)
LiveMigration - тут думаю все ясно
Management - сеть для управления

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

Заводим сервера в домен. Устанавливаем роль Hyper-V, Failover Cluster.
В настройках Multipath IO включаем поддержку SAS устройств.
Обязательно перезагружаем.

Следующие настройки необходимо выполнить на обоих серверах.

Переименуйте все 4 сетевых интерфейса в соответствии их физическим портам (у нас это 1,2,3,4).
Настраиваем NIC Teaming - Добавляем все 4 адаптера в команду, Режим (Teaming-Mode) - Switch Independent, Балансировка нагрузки (Load Balancing) - Hyper-V Port. Даем имя команде, я так и назвал Team.
Теперь необходимо поднять виртуальный коммутатор.
Открываем powershell и пишем:

New-VMSwitch "VSwitch" -MinimumBandwidthMode Weight -NetAdapterName "Team" -AllowManagementOS 0

Создаем 3 виртуальных сетевых адаптера.
В том же powershell:

Add-VMNetworkAdapter –ManagementOS –Name "Management" Add-VMNetworkAdapter –ManagementOS –Name "ClusterNetwork"Add-VMNetworkAdapter –ManagementOS –Name "Live Migration"

Эти виртуальные коммутаторы появятся в центре управления сетями и общим доступом, именно по ним и будет ходить траффик наших серверов.

Настройте адресацию в соответствии с вашими планами.

Переводим наши адапетры в соответствующие VLAN’ы.
В любимом powershell:

Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 2 -VMNetworkAdapterName "Management" -Confirm Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 3 -VMNetworkAdapterName "ClusterNetwork" -Confirm Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 4 -VMNetworkAdapterName "Live Migration" -Confirm

Теперь нужно настроить QoS.

При настройке QoS by weight (по весу), что является best practice, по заявлению Microsoft, советую расставить вес так, чтобы в общей сумме получилось 100, тогда можно считать, что значение указанное в настройке есть гарантированный процент полосы пропускания. В любом случае считается процент по формуле:

Процент полосы пропускания = установленный вес * 100 / сумма всех установленных значений веса

Set-VMSwitch “VSwitch” -DefaultFlowMinimumBandwidthWeight 15

Для служебной информации кластера.

Set-VMNetworkAdapter -ManagementOS -Name “Cluster” -MinimumBandwidthWeight 30

Для управления.

Set-VMNetworkAdapter -ManagementOS -Name "Management" -MinimumBandwidthWeight 5

Для Live Migration.

Set-VMNetworkAdapter -ManagementOS -Name “Live Migration” -MinimumBandwidthWeight 50

Чтобы трафик ходил по сетям верно, необходимо верно расставить метрики.
Трафик служебной информации кластера будет ходит по сети с наименьшей метрикой.По следующей по величине метрики сети будет ходить Live Migration.

Давайте так и сделаем.
В нашем ненаглядном:

$n = Get-ClusterNetwork “ClusterNetwork” $n.Metric = 1000 $n = Get-ClusterNetwork “LiveMigration” $n.Metric = 1050$n = Get-ClusterNetwork “Management” $n.Metric = 1100

Монтируем наш диск-свидетель на ноде, с которой будем собирать кластер, форматируем в ntfs.

В оснастке Failover Clustering в разделе Networks переименуйте сети в соответствии с нашими адаптерами.

Все готово к сбору кластера.

В оснастке Failover Clustering жмем validate. Проходим проверку. После чего создаем кластер (create cluster) и выбираем конфигурацию кворума (quorum configuration) Node and Disk majority, что также считается лучшим выбором для кластеров с четным количеством нод, а учитывая, что у нас их всего две - это единственный выбор.

В разделе Storage оснастки Failover Clustering, добавьте ваши диски. А затем по очереди добавляйте их как Cluster Shared Volume (правый клик по диску). После добавления в папке C:\ClusterStorage появится символическая ссылка на диск, переименуйте ее в соответствии с названием диска, добавленного как Cluster Shared Volume.

Теперь можно создавать виртуальные машины и сохранять их на эти разделы. Надеюсь статья была Вам полезна.

Прошу сообщать об ошибках в ПМ.

Советую к прочтению: Microsoft Windows Server 2012 Полное руководство. Рэнд Моримото, Майкл Ноэл, Гай Ярдени, Омар Драуби, Эндрю Аббейт, Крис Амарис.

P.S.: Отдельное спасибо господину Салахову, Загорскому и Разборнову, которые постыдно были забыты мною при написании данного поста. Каюсь >_< XD

Андрей Бирюков

Разворачиваем кластер на основе Windows Server 2003

Отказоустойчивые кластеры широко распространены в сетях средних и крупных компаний. Но у многих администраторов внедрение и обслуживание кластерных систем по-прежнему вызывает много вопросов. Рассмотрим реализацию отказоустойчивого кластера на основе Windows Server 2003.

Приступая к работе

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

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

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

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

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

В своей статье я рассмотрю программную реализацию двухузлового кластера на основе службы Microsoft Clustering Service. Такое решение является наиболее приемлемым для организаций средних размеров с небольшим IT-бюджетом.

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

У нас имеется два сервера с идентичной аппаратной частью. Требование идентичности не является обязательным, но желательно, чтобы мощность серверов была сходной.

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

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

О редакциях и лицензиях

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

При построении кластера следует запомнить, что наиболее распространенная редакция Windows Server 2003 Standard не поддерживает кластеризацию.

Таким образом, при построении отказоустойчивой системы следует использовать Windows Server 2003 Enterprise Edition.

Кстати, редакцию Enterprise нужно использовать и при построении кластеров для Microsoft Exchange и Microsoft SQL Server 2000. В противном случае вы не сможете кластеризовать почту и базы данных.

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

Поясню на примере. Если у вас в организации 250 пользователей и вы разворачиваете двухузловой кластер, то вам необходимо приобрести две серверные лицензии на Windows Server 2003 и 250 лицензий клиентского доступа.

Таким образом, количество узлов в кластере не влияет на число клиентских лицензий.

Новые понятия

Для лучшего понимания концепции кластеризации мы рассмотрим несколько основных понятий.

Отказоустойчивый кластер, как правило, состоит из четырех узлов, использующих общий дисковый ресурс для обмена данными. Этот ресурс также именуется кворум-устройством (quorum).

В идеале это кворум-устройство должно представлять из себя отдельное аппаратное хранилище данных с собственной поддержкой отказоустойчивости (диски RAID 1, RAID 5), подключающееся ко всем узлам кластера.

Подобные решения предоставляют IBM, EMC и другие производители.

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

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

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

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

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

Группы – это блоки для перехода по отключению (failover). Каждая группа содержит один или несколько ресурсов. При отказе любого из ресурсов внутри группы для всей группы выполняется совместный переход по отключению согласно политике перехода по отключению, определенной для данной группы.

В любой момент времени группа может принадлежать только одному узлу. При отказе какого-либо ресурса внутри группы он должен быть перемещен в альтернативный узел вместе со всеми остальными ресурсами этой группы.

При устранении причины отказа исходного узла вся группа передается назад в исходный узел в соответствии с политикой возврата после восстановления (failback) для данной группы.

Ресурсы – наше все

Следующим понятием являются ресурсы – логические или физические элементы, которые можно подсоединять или отсоединять от сети.

В систему Windows Server 2003 Enterprise Edition включено несколько различных типов ресурсов:

Physical Disk;
DHCP;
WINS;
Print Spooler;
File Share;
Internet Protocol Address;
Local Quorum;
Majority Node Set;
Network Name;
Generic Application;
Generic Script;
Generic Service.

Несколько слов по каждому из видов ресурсов.

Physical Disk используется для кворум-ресурса. Требуется для всех серверов кластера.

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

Print Spooler позволяет кластеризовать службы печати.

Тип ресурса File Share позволяет управлять разделяемыми файловыми системами тремя различными способами:

Стандартный разделяемый файловый ресурс , когда видна только папка верхнего уровня, представленная разделяемым именем.
С разделяемыми подпапками , когда папка верхнего уровня и каждая из ее непосредственных подпапок предоставляются для разделяемого доступа с различными именами.
Автономный корень распределенной файловой системы Dfs (Distributed File System). Но вы не можете использовать ресурс File Share кластерного сервера как часть отказоустойчивого корня Dfs.

Internet Protocol Address и Network Name используется для создания виртуального сервера, который позволяет клиентам использовать то же имя для доступа к кластеру даже после перехода по отключению failover.

Ресурс Local Quorum используется для управления системным диском в локальном узле кластера.

Majority Node Set применяется для управления конфигурацией данных кластера, которые могут располагаться на ЗУ кластера или вне этого устройства. Используется для согласования данных между географически разбросанными устройствами.

Тип ресурса Generic Application позволяет вам управлять в кластере обычными приложениями, не распознающими своего присутствия в кластере.

Generic Script – управление сценариями операционной системы как кластерным ресурсом.

Generic Service – позволяет управлять службами Windows Server 2003 как ресурсами кластера.

Важность планирования

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

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

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

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

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

Приведу небольшой пример построения дерева зависимостей для ресурса File Share.

Очевидно, что этот ресурс зависит от Physical Disk, так как это основной ресурс, используемый всеми узлами кластера. Далее для ресурсов общего доступа важно сетевое имя Network Name. Но в свою очередь Network Name не может использоваться без IP Address.

Таким образом, получаем следующие зависимости: ресурс File Share явно зависит от Physical Disk и Network Name и неявно – от IP Address.

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

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

Установка

Обсудив особенности реализации Microsoft Cluster Service, приступим непосредственно к развертыванию.

Первым делом на каждый из узлов устанавливаем Windows Server 2003 Enterprise Edition.

Сам процесс установки стандартный и описывать его в статье нет смысла. Единственное, о чем следует упомянуть, – это IP-адресация. Необходимо сразу выставить фиксированные адреса, чтобы впоследствии не возникло проблем с соединением.

После успешной установки необходимо дать имена каждому из узлов кластера. Для простоты назовем узлы Node1 и Node2.

В следующем окне необходимо указать имя домена, в котором находятся узлы, а также имя кластера (см. рис. 1).

Если проверка по всем пунктам закончилась успешно, то в следующем окне вам необходимо указать IP-адрес кластера.

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

Наконец, переходим к последней странице, в которой выводятся данные для подтверждения. Здесь можно указать кворум-устройство, как показано на рис. 3.

При нажатии «Next» запускается процесс установки кластера, внешне схожий с уже описанным анализом конфигурации.

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

Работа над ошибками

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

Как видно, при анализе были обнаружены две ошибки, вернее, проблемы. Так как полоска Task Completed зеленого цвета, можно продолжать установку, но лучше сначала разрешить проблемы.

Итак, что же было найдено в процессе анализа системы:

Не найдено кворум-устройство. Как уже обсуждалось ранее, оно представляет собой SCSI-диск, используемый всеми узлами кластера. Если вы получили такое сообщение, проверьте правильность подключения к SCSI-шине серверов. Также проверьте наличие данного диска в разделе «Administrative Tools -> Computer Management -> Disk Management».
На сервере найден только один сетевой адаптер. Большинство промышленных серверов имеют две сетевые карты, так что это довольно редкая ошибка. Но если она появилась, то необходимо проверить работоспособность второго адаптера. В случае, если вы хотите использовать только один интерфейс, воспользуйтесь описанием из раздела «Добавляем узлы».

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

Для идентификации более сложных ошибок можно воспользоваться кнопкой «View Log» для просмотра детального журнала событий.

Добавляем узлы

Теперь необходимо добавить узел в кластер. Но прежде сделаем несколько дополнительных настроек. В консоли Cluster Administration выбираем «Cluster Configuration», далее «Networks» (см. рис. 5).

У каждого узла кластера два сетевых интерфейса, при этом один подключен к локальной сети (LAN), а второй используется для взаимодействия между узлами кластера (Heartbeat).

Поочередно откройте закладку «Properties» для каждого из этих сетевых интерфейсов.

Для LAN в свойствах необходимо указать «Client Access Only (public only)», а для Heartbeat выбираем «Internal Cluster Communications Only (private network)».

Таким образом, теперь у нас интерфейс LAN будет использоваться только для внешнего взаимодействия, а Heartbeat – только для обмена информацией между узлами кластера. Это позволяет увеличить быстродействие системы вцелом.

Только не забудьте также разграничить сегменты на сетевом уровне. То есть сегмент, содержащий соединения Heartbeat, должен быть подключен в отдельный коммутатор или концентратор (не в ту же физическую сеть что и LAN!) из соображений безопасности и надежности.

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

Если вы хотите использовать только один интерфейс, то укажите Internal and Client Access в свойствах LAN и Heartbeat. При этом и LAN и Heartbeat будут содержать один физический интерфейс.

Итак, мы оптимизировали настройки сетевых интерфейсов узла кластера и теперь переходим к следующему этапу – добавлению второго узла. Для этого на втором сервере также запускаем «Administrative Tools -> Cluster Administrator».

Только теперь выбираем «Add nodes to cluster» и указываем имя кластера.

На следующем шаге прописываем имя сервера, который будет использоваться в кластере.

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

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

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

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

Как упоминалось в начале статьи, мы будем настраивать ресурсы для службы File Share.

Для этого мы сначала создадим новую группу на виртуальном сервере HOME.

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

Поэтому для создания нашего ресурса типа File Share нужно сделать следующее:

создать группу, которая будет содержать нужные ресурсы;
создать ресурс типа Physical Disk;
создать ресурс типа IP Address;
создать ресурс типа Network Name;
создать ресурс типа File Share.

Начнем с создания кластерной группы.

Для этого в консоли «Cluster Administrator» щелкните на папке «Active Groups» для сервера, на котором будет находиться ресурс типа File Share, и выберите пункт «Group» в меню «New». Появится окно мастера создания группы «New Group Wizard» (см. рис. 7).

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

К примеру, вполне логично в начале списка указать наиболее мощные и менее загруженные узлы кластера.

В нашем случае необходимо выбрать узел и нажать «Add», затем аналогично добавить Node 2. После нажатия кнопки «Finish» группа будет создана.

Но обратите внимание на то, что сейчас она находится в автономном состоянии, так как с ней не связаны никакие активные ресурсы.

Теперь пришло время создать ресурс типа Physical Disk. Для этого щелкните правой кнопкой мыши на только что созданной группе и выберите пункт «Resource».

Заполните поля Name и Description и выберите в раскрывающемся списке «Resource Type» вариант «Physical Disk».

На следующем шаге укажите возможных владельцев ресурса Possible Owners. Тут нужно указать те машины, которые могут содержать этот ресурс (Node1, Node2).

На следующем этапе указываем параметры диска (Disk Parameters). В раскрывшемся списке будут представлены все ресурсы типа Physical Disk, которыми может управлять служба кластера.

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

После указания диска нажмите на кнопку «Finish», чтобы создать этот ресурс.

Третьим по списку мы должны создать ресурс типа IP Address.

По аналогии с предыдущим разделом выбираем пункт «Resources» в нашей группе, далее – «New». Указываем тип ресурса – IP Address, затем – возможные владельцы.

В следующем окне, Dependencies, должен появиться уже созданный нами ресурс Physical Disk. Но выбирать его не нужно, так как в данном случае никакой зависимости нет.

На следующей странице необходимо указать настройки для IP-адреса. Затем нажимаем «Finish».

Создадим ресурс типа Network Name. Для этого необходимо еще раз проделать все те действия, которые мы выполняли ранее для других типов ресурсов.

Но в разделе Dependencies теперь необходимо указать зависимость от ресурса IP Address.

Приступаем к завершающему этапу в создании кластерного ресурса File Share.

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

В разделе Advanced можно указать скрывать ли разделяемые ресурсы-поддиректории.

Разделяемый ресурс создан.

Обратите внимание на то, что по умолчанию для ресурса File Share будут заданы полномочия Read Only. Изменить эту установку можно в окне File Share Parameters.

Итак, мы получили отказоустойчивый ресурс в кластере и тем самым повысили доступность файловых ресурсов с помощью кластеров Microsoft.

Кластеры в виртуальной реальности

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

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

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

К примеру, для того чтобы развернуть двухузловой кластер на основе VMware, мне достаточно было рабочей станции с 1 Гб оперативной памяти. И никаких внешних SCSI-дисков, шумных серверов и прочей аппаратуры.

Так что, если вас интересует реализация кластеров на базе виртуальной машины VMware, то рекомендую обратиться к статье .

Заключение

Итак, мы развернули отказоустойчивый двухузловой кластер и установили разделяемый ресурс File Share.

Однако одним из наиболее распространенных применений службы Microsoft Cluster Services является организация кластеров почтовых серверов MS Exchange.

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

Рассел Ч. Microsoft Windows Server 2003. Справочник администратора.
Бережной А. Строим сетевую инфраструктуру на основе VMware Server. //Системный администратор, №3, 2007 г. – С. 14-18.
Статья о развертывании кластера на VMware – http://www.rootpermissions.net/Files/MS_Windows_2003_Cluster_on_VMware_GFX_3.rar .

Вконтакте