14. Создать кластер и просмотреть его основные свойства.
Итак, к текущему моменту все подготовительные операции по подготовке кластера должны быть завершены и, что значительно важнее, мы должны получить «добро» на его установку от мастера проверки оборудования из предыдущего шага. Идеальный случай если вообще все тесты последнего завершились успешно. Но, допустим, у автора все тесты кроме Validate Memory Dump Settings закончились успешно и вообще без замечаний и лишь упомянутый тест сообщил что:
Поскольку это именно «желтый warning», а не «красный error» мы имеем полное, моральное и техническое, право на продолжение работы. Вперед, к «подъему» кластера!
Надо полагать мы только что закончили валидацию нашего оборудования в мастере Validate a Configuration Wizard и продолжаем находиться внутри ВМ clustNodeA, а активное окно у нас все та же оснастка консоли Failover Cluster Manager. Выбираем в ней ссылку чуть ниже той, с которой начиналось тестирование, а именно ссылку Create a Cluster... Первую страницу очередного визарда Create Cluster Wizard пропускаем, на второй указываем две машины-ноды, ровно так же как мы делали это в предыдущем мастере при настройке теста оборудования. На следующей странице Access Point For Administering The Cluster мы вводим имя виртуального сервера (коим кластер и представляется нашим клиентам) и IP этого виртуального сервера. Однако эти имя и IP не для подключения клиентов вроде менеджеров, бухгалтеров и кадровиков! Это параметры по которым будем подключаться мы, администраторы, с целью как раз таки администрирования кластера. Потому и страница называется не просто «точка доступа», а «точка доступа для администрирования кластера». Имя и IP для «нормальной» клиентской работы с кластером будут указаны нами позже. Вводим, допустим, clust0adm и 192.168.81.81 соответственно.
Next, страница Confirmation, снова Next, и процесс запущен! По окончании видим окно Summary с отчетом о проделанной работы.
Как вы могли убедиться только что, если мы «доказали» системе что наши составные компоненты достойны образования из них кластера (т.е. «прорвались» через предварительные защитные тесты), само это образование как процесс действительно «проще пареной репы». Несколько кликов мышью и — вот он, кластер! В данном случае кластер с гордым именем clust0adm. Ну а почему бы и нет?
Щелчком по кнопке Finish «отпускаем» отработавший свое мастер Create Cluster Wizard и убеждаемся, что наш новый кластер занял подобающее ему место в окне управления таковыми, т.е. в Failover Cluster Manager-е.
На последней иллюстрации, кстати, обратите внимание, что операционная система сразу же начинает рассматривать весь кластер как отдельный, полноценный компьютер и присваивает ему полно квалифицированное доменное имя, т.е. имя_сервера.имя_домена.имя_домена_верхнего_уровня.
Немного исследуем текущее состояние кластера, для чего развернем узел с его именем (см. предыдущую иллюстрацию) и «пробежимся» по его под-узлам.
- Services and application — говорит нам что пока на кластере нет ни сервисов, ни приложений, т.е. пока он совершенно бесполезен. Ну да это не надолго;
- Nodes — перечисляет все ноды входящие в состав кластера и показывает их текущее состояние (работает или Offline);
- Storage — перечисляет все Shared-диски кластера (локальные диски отдельных нодов здесь никому не интересны). Показывается текущее состояние каждого диска (On- или Off- line), используется ли диск для нужд кластера, или он свободен под любые будущие сервисы которые мы надумаем захостить на данном кластере, а так же текущий «владелец» диска, т.е. нода им в данный момент управляющая. Мы видим что дисков у нас всего 4, все Online, и что лишь один занят под кворум кластера, а 3 свободны, и что всеми четырьмя распоряжается нода A. Кстати, пока мы находимся на этом под-узле проверьте, какой именно диск назначен под задачи кворума? Такой диск известен так же как диск-свидетель (witness disk). Для этого просто разверните его запись в правой панели активного окна.
Если это диск Q, как на последнем рисунке — все отлично, вы все сделали правильно. Если же буква иная, то поздравлять не с чем, вы не вняли предупреждению автора «Порядок их создания критически важен!» из той части мануала в котором мы создавали наше SAN-хранилище. Т.е. первым добавленным в хранилище диском у вас был не Q. А какой-то иной. Можно ли сейчас исправить ситуацию и принудительно назначить на эту роль именно диск Q? Вполне. Из контекстного меню всего кластера (а не его под-узла Storage) выбираем More Actions...→Configure Cluster Quorum Settings...
Пролистываем одноименный визард до страницы Configure Storage Witness в которой убираем галочку с текущего диск-свидетеля и ставим ее именно на Q диск.
Доводим визард до конца и проверяем что уж теперь-то именно диск Q играет роль witness диска. - Networks — в этом под-узле показываются все сети к которым подключен кластер. Можно видеть их статус (On/Off), их тип (внешняя, или Enabled, как определяет такой тип данная закладка, или внутренняя, Internal), а так же диапазон IP-адресов относящихся к каждой сети. На под-узлах каждой отдельной сети можно видеть тот IP адрес с которым подключена каждая отдельная нода входящая в кластер.
Итак, кластер «поднят» и готов к работе — самая трудная часть пути, несомненно, преодолена!
15. Установить Microsoft Distributed Transaction Coordinator (MS DTC).
Ну и что, вот теперь мы готовы приступать к самой центральной части задуманного — установке уже самого SQL Server на кластер? Почти, еще грамм терпения, а именно: нам нужно предварительно установить Microsoft Distributed Transaction Coordinator (MS DTC, координатор распределенных транзакций). Строго говоря, поскольку наши экземпляры сервера будут содержать лишь Database Engine и ничего более (если захотите дополнительных SQL-сервисов — не вопрос, но это уже будет ваша самостоятельная работа), то, вообще-то, формально говоря, он не нужен, но:
- мы можем захотеть позже добавить другие SQL-сервисы к нашим двум экземплярам;
- нам, в процессе работы с нашим тестовым окружением, можем понадобиться опробовать именно работу с распределенными транзакциями как таковыми;
- некоторые вторичные функции репликации могут зависеть от этого сервиса (но могут и нет);
- если начать установку SQL Server на кластер без данного сервиса, то будет предупреждение о его отсутствии. Продолжению инсталляции это никоим образом не мешает, но «осадок-то остается»
- наконец MS DTC значительно проще проинсталлировать до установки нового SQL сервера чем добавлять его к уже существующему;
- и последнее: один из наших виртуальных SAN-дисков (M:) специально создан под эту службу. Не пропадать же добру?
Поэтому, наше волевое решение — ставить! А это автоматически ведет нас к следующему заключению: нам следует добавить обоим серверам-нодам серверную роль Application Server, т.к. она безусловно требуется для поддержки сервиса MS DTC. Хорошо, приступаем к реализации задуманного.
Идем на любую ноду (пусть это будет нода A), открываем там уже привычный Server Manager, выбираем узел Roles и щелкаем по ссылке Add Roles в правой панели (все это очень напоминает наши действия из 7-го шага когда мы готовились установить роль Active Directory Domain Services). В открывшемся Add Roles Wizard переходим ко второй странице с набором доступных ролей, где и выбираем чек-бокс Application Server. Появляется приглашение так же проинсталлировать пару необходимых компонентов (features), первую из которых, .NET 3.5.1, по любому пришлось бы устанавливать, не сейчас, так 5 минут спустя — она в списке предварительных требований для запуска процесса установки SQL Server как такового. Разумеется соглашаемся на установку дополнительных компонентов.
После чего пролистываем мастер до страницы Select Role Services. На последней уже отмечен упомянутый .NET Framework и его мы не трогаем, но «до-отмечаем» пункты Incoming/Outgoing Remote Transactions (но не WS-Atomic Transaction!).
Запускаем визард на установку выбранных компонентов и ролей, а сами тем временем переключаемся на машину с нодой B и повторяем там описанную процедуру «буква-в-букву». Инсталляция на обоих серверах-нодах завершается успешно но с тремя предупреждениями: об отключенном автоматическом Windows Update и о невозможности добавить правило для файрвола. Ни одно из этих предупреждений не является сколь-либо значащим в нашем тестовом окружении, спокойно щелкаем Close. На возможную индикацию ошибок/предупреждений в правой панели Server Manager относящихся к только что инсталлированной роли внимания не обращаем, на текущий момент это нормально. Закрываем Server Manager.
Теперь у нас есть требуемая служба на двух серверах-нодах, но она не кластеризована. То есть у нас просто есть два идентичных сервиса ничего друг о друге не знающие. А работать-то, на самом деле, им предстоит «в одной упряжке», надо бы их «познакомить». Говоря языком формально-официальным нужно сделать указанный сервис кластерным ресурсом. Для реализации этого замысла на ноде A открываем Failover Cluster Management из меню Administrative Tools (впрочем, ту же оснастку консоли и с таким же успехом его можно было открыть и на ноде B, управление-то сервисом все-равно будет осуществляться одним и тем же кластером). Распахиваем в оснастке узел нашего кластера clust0adm.clustDOM.local, правой кнопкой мыши щелкаем по его под-узлу Services and applications и выбираем пункт контекстного меню Configure a Service or Application.
В открывшемся визарде (а это у нас будет High Availability Wizard) сразу идем ко второй странице и отмечаем элемент списка Distributed Transaction Coordinator (DTC).
Щелкаем Next. На следующей странице нам нужно ввести имя/IP-адрес для инсталлируемого сервиса. В отличии от похожей страницы в мастере создания нового кластера, это именно параметры «для клиентов», не администраторские! Имя можем принять то что предлагается нам по умолчанию, clust0admDtc, а адрес, допустим, сделаем 192.168.81.82.
На странице следующей выбираем предназначенный специально для этого сервиса диск — M:.
Подтверждаем установку, ждем когда она завершится, отмечаем для себя ее успешное завершение и щелкаем Finish. Убеждаемся, что новый сервис успешно принят на хост нашим кластером.
Однако, как следует из последнего изображения, сервис отдан под контроль ноде B, а мы хотим что бы она была полностью пассивной, а вся активность происходила на ноде противоположной. Поэтому поменяем положение вещей. Щелкаем правой кнопкой по названию сервиса в правой панели и в появившемся контекстном меню выбираем пункты Move this service or application to another node→Move to node clustNodeA.
Подтверждаем наше желание о передаче управления — готово, в колонке Current Owner теперь указана нода A вместо B (проверьте это!).
И лишь теперь мы готовы к главному событию — установке MS SQL Server на кластер.