9. Ввести оставшиеся четыре ВМ в домен и завершить его формирование.
Итак, у нас есть работающий домен-контроллер да еще и с DNS-сервером «поверх» него. Введем в домен оставшиеся четыре виртуальных машины. Процесс совершенно аналогичен для любой из них, возьмем, для примера, clustNodeA.
Переключаемся на указанную ВМ, а если она пока выключена — запускаем ее и логинимся в систему. Логиниться, понятно, пока следует под локальным администратором (adm), ведь мы же еще не в домене. В готовой к работе ВМ мы первым делом идем в настройки ее сетевых подключений. Для машин с одним сетевым адаптером ошибиться нельзя, а для машин с двумя (это пара машин — будущих нод кластера, clustNodeA как раз одна из них) выбираем тот из двух, что подключен к публичной (81-й) сети. Для выбранного адаптера открываем окно свойств его IP протокола 4-й версии, или, выражаясь проще — окно с его IP-адресом. Зачем мы его открыли? А затем, что буквально через минуту clustNodeA войдет в состав домена и сможет пользоваться (и даже обязан будет это делать) услугами доменного DNS, того самого что мы так кропотливо настраивали в предыдущем 8-м шаге. Стало быть, нам следует изменить поле Preferred DNS Server указанного окна на IP-адрес того сервера, что выполняет роль доменного DNS. А это, вне сомнений, IP-адрес машины clustDC, т.е. 192.168.81.110, его и указываем.
Щелкаем OK, с сетью пока закончили.
Теперь приступаем непосредственно к добавлению clustNodeA в домен. Из окна Run выполняем команду oobe, что приводит к открытию окна Initial Configuration Tasks. В нем нам интересна ссылка Provide computer name and domain.
В новом окне системных свойств щелкаем Change... и в поле Domain вводим clustDOM.local.
Нас должны запросить учетные данные безопасности (они же credentials) того, кто имеет полномочия на изменения состава домена. У нас таковые вполне имеются, CLUSTDOM\adm и 123 соответственно.
Если все проделано верно нас поздравят с «вливанием» машины в новый домен.
А еще нас пригласят перезагрузится, с чем мы спорить не будем. Пока перезагружается clustNodeA только что описанную операцию ввода в домен уместно будет провести с тремя оставшимися виртуальными машинами и их тоже отправить на reboot. Не забывайте на каждой очередной ВМ начинать описанную процедуру со смены IP-адреса предпочитаемого DNS сервера!
10. Подключить внешние (shared) диски сначала к будущей активной, а потом будущей пассивной нодам.
В очередном, 10-м по счету шаге наша задача будет такой: подключить внешние диски сначала к будущей активной ноде, clustNodeA, а затем будущей пассивной ноде, clustNodeB. Ведь что представляют из себя в настоящий момент виртуальные диски, что мы добавили в машину clustSAN (он же, напомню, наш iSCSI Target) в 6-м шаге нашего мануала? Пока что это полностью сформированная и готовая к работе «полка», или, говоря языком более официальным, полностью готовый к работе модульный массив для SAN. Да вот только потребители этого массива (а это как раз две упомянутые ранее машины-ноды) не знают о том что он готов. Собственно, они даже не в курсе его существования. Модульный SAN-массив это вам не USB-диск, вставляемый в любой USB-порт и готовый к работе с этого момента. Тут процесс похитрее будет, нежели простое «втыкивание» LAN коннекторов в соответствующие им разъемы. Однако, как это ни забавно, между USB и SAN дисками есть и общее! Это то, как они «видятся» их потребителями. То есть, USB-диск с точки зрения компьютера к которому он подключен — это что? Да это же локальный диск этого компьютера! Так вот SAN-диски — тоже самое, их потребители «думают» что это их локальные диски. А теперь откройте обозреватель (только не Internet, а Windows) хоть на clustNodeA, хоть на clustNodeB. Видите вы там другие диски кроме C:? Значит работа с нашим сетевым хранилищем, по сути, только начинается.
Начнем с будущей активной ноды, clustNodeA. Идем на эту машину (если нам потребуется ее включить не забываем о правильном логине в систему, см. окончание предыдущего шага) и запускаем окно настроек клиента нашей сети хранения данных (SAN). Мы уже знаем что провайдер такой сети называется iSCSI Target и что без отдельного пакета установленного нами в 5-м шаге данного мануала работать с ним мы бы в принципе не смогли, т.к. никакого iSCSI сервера в OS Windows Server изначально нет. Но вот клиент той же сети (зовущийся, как нам тоже известно, iSCSI Initiator) уже есть в той же OS изначально, дополнительные телодвижения помимо его настройки не нужны. Правда таким «изначальным» компонентом он стал только с версии операционной системы 2008-й. Если, по каким-то причинам, вы вынуждены использовать в качестве платформы (или ее части) Windows Server версий 2000/2003 то и в этом случае сконфигурировать iSCSI клиента у вас получится, вот только поставить его придется отдельно. Но для именно Windows Server 2008R2 (и 2008) ничего ставить не надо, просто вызываем меню Administrative Tools→iSCSI Initiator.
Открывается окно свойств текущего iSCSI клиента, которым в настоящий момент выступает ВМ clustNodeA. Прежде всего отправляемся на закладку Discovery и кликаем там кнопку Discovery Portal...
Тем самым мы заявляем что мы готовы указать нашу цель, наш iSCSI Target. В открывшемся окне следует указать IP-адрес последнего. Поскольку у ВМ clustSAN адрес 192.168.81.113 его и вводим, порт оставляем как есть.
Теперь вспоминаем вот про что. Когда мы в 5-м шаге данного мануала конфигурировали iSCSI сервер мы не указали ни одного клиента которому будет разрешено подключение к нему. Вместо этого мы поставили формальный 0 в поле идентификации клиента, а «на бумажке», или просто «в голове» поставили себе галочку — «вернуться позже и исправить». Вот давайте эти исправления и внесем, иначе наш сервер так и останется без клиентов. Прежде всего выясняем реальный iSCSI Qualified Name (IQN) (что это такое объяснялось в том же 5-м шаге) текущего клиента. Для чего переключаемся на последнюю закладку активного окна — Configuration. Там в поле Initiator Name будет проставлено интересующее нас значение.
Выделяем, копируем в буфер обмена. Поскольку фактически все буфера всех виртуальных машин (но только запущенных в настоящий момент, разумеется), а заодно и буфер хост-компьютера полностью синхронизированы, скопированное значение окажется, в том числе, и на машине clustSAN. Именно по этой причине лучше ее запустить (и корректно залогиниться в ее систему) до того как мы скопируем указанное значение. После чего, временно оставив iSCSI клиента (машину clustNodeA) переключаемся на машину-сервер, clustSAN. На этой последней вновь, как и в шаге 5-м, открываем из меню Administrative Tools окно iSCSITarget. Находим инициализированный нами ранее iSCSI сервер по имени FourDisksSAN и вызываем, через контекстное меню, окно его свойств.
В окне свойств переключаемся на вкладку iSCSI Initiators и сначала удаляем фиктивного клиента (у нас теперь есть реальный), а затем щелкаем по кнопке Add...
Однако обратите внимание, что между щелчками по двум кнопкам отмеченных на последней иллюстрации нам будет выдано предупреждение, что, мол удаляемый клиент больше не сможет подключаться к серверу. Для нас и нашего «нулевого» клиента это вполне отлично, то есть Yes.
Ну а после нажатия на кнопку Add... мы попадаем в окно Add/Edit Identifier. Именно здесь мы можем указать параметры клиента, которому мы хотим открыть доступ на сервер. Для этого во-первых, убеждаемся что тип идентификации клиента выставлен в IQN, ну а во-вторых, в поле Value вводим то самое запомненное (в разделяемом буфере обмена) значение.
Дважды щелкаем OK. Оставляем теперь в покое clustSAN (однако, разумеется, не выключая ее) и возвращаемся к нашему клиенту clustNodeA. Там у нас продолжает быть открытым окно свойств iSCSI инициатора, переходим на его вкладку Targets и щелкаем кнопку Refresh.
Тем самым мы просим систему обнаружить все iSCSI сервера к которым у нашего клиента есть право доступа. Если предыдущие шаги были корректны таковой непременно обнаружится.
Вполне предсказуемо что доступных серверов будет ровно одна штука, нам больше и не требуется. Однако обратите внимание на колонку Status с последней иллюстрации, а точнее на ее значение. Заметили что оно равно Inactive? Сам факт нахождения iSCSI сервера в списке панели Discovered targets говорит о том, что клиент может к нему подключиться. Но может и не подключаться — дело-то добровольное. Так вот отмеченное значение говорит как раз о том, что соединение не установлено. Исправим ситуацию, для чего достаточно щелкнуть кнопку Connect возле нижней границы той же панели Discovered targets.
В окне подтверждения соединения просто щелкаем OK принимая все параметры по умолчанию. Вот, теперь другое дело — коннекшен установлен!
Следующий вопрос — какие ресурсы из доступных на сервере мы желаем использовать? Ведь если SAN состоит из, допустим, 50-ти дисков это не значит что клиент обязан найти занятие для каждого. Опять же — дело добровольное, можно и одним диском ограничиться. В данном случае нам потребуются 4-е диска из 4-х, но это не более чем частный случай описываемой ситуации. В любом случае клиент обязан четко заявить свои притязания на каждый ресурс сервера (iSCSI сервера, разумеется) который он собирается использовать в «личных и корыстных» целях. А поэтому нам ничего не остается кроме как отправиться на закладку Volumes and Devices все того же окна настроек iSCSI клиента.
Тут с помощью кнопки Add... мы могли бы начать добавлять по одному диску за раз, однако есть способ лучше — кнопка Auto Configure. Она опросит сервер на предмет всех доступных ресурсов и выведет их в список Volume list. Попробуем?
Отлично! Все четыре доступных диска «зарегистрированы» для их использования текущим клиентом. Если бы нам это было нужно от «лишних» дисков можно было бы отказаться кнопкой Remove, однако, как уже было отмечено, нам нужны все четыре диска. Поэтому оставляем все как есть и щелчком по OK в самом низу окна iSCSI Initiator Properties закрываем последнее.
Теперь у нас на clustNodeA помимо «реально-локального» диска C: есть 4 «псевдо-локальных» диска. По крайней мере сам этот компьютер считает их абсолютно своими собственными. Однако это пока Offline локальные диски, их нужно вывести в Online и проинициализировать. Открываем оснастку консоли Computer Management из меню Administrative Tools и щелкаем по узлу Disk Management в дереве объектов слева. Видим, что прямо сейчас один диск у нас в он-лайне (C:) и четыре в офф-лайне.
Какие параметры дисков нам будут нужны для их корректной инициализации? Во-первых, нам нужно как-то (скорей всего по объему) определить предназначение этого диска. После этого следует определиться с меткой (label) того тома который будет создан нами на всем диске (в том смысле что у нас все свободное место каждого диска будет отдано под единственный том). И в-третьих, нам нужно выбрать букву под которой каждый SAN-диск станет известен компьютеру clustNodeA как локальный. Часть указанной информации уже имеется в таблице составленной нами в шаге 6-м данного мануала, когда мы «начиняли» наш «как бы» модульный массив для SAN «как бы» дисками. Часть же нам предстоит «сочинить» прямо сейчас. Хорошенько подумав приходим вот к такой комбинированной таблице.
| Размер диска в MB | Назначение диска | Метка диска | Буква диска |
| 2000 | Диск кворума | Quorum | Q: |
| 2000 | Диск сервиса MSDTC | MSDTC | M: |
| 4000 | Диск данных БД | DBdata | T: |
| 500 | Диск логов БД | DBlog | L: |
Порядок следования дисков в оснастке консоли скорей всего будет обратный тому, в которых вы их «вставляли» в iSCSI сервер. Т.е. Disk1=DBlog, Disk2=DBdata и т.д. Однако не «закладывайтесь» на это, лучше смотрите на объем диска и используйте его как «хинт». Возьмем, к примеру, первый из офф-лайновых дисков — Disk1. Это, несомненно, должен быть диск L: с меткой DBlog, так как именно он имеет объем 500MB. Первым делом выводим его в он-лайн, для чего щелкаем по нему правой кнопкой мыши и выбираем пункт Online из контекстного меню.
Переходим к инициализации диска, для чего повторно щелкаем по нему же, но на этот раз пункт меню уже называется Initialize Disk.
В открывшемся окне инициализации диска принимаем все установки по умолчанию, щелкаем OK.
В третий раз мы кликаем уже не по диску, а по его тому и выбираем из контекстного меню New Simple Volume.
Первые две страницы открывшегося визарда пролистываем «по умолчанию», отдавая тем самым все имеющееся пространство диска под создаваемый том, а на странице Assign Drive Letter or Path выбираем, согласно нашей таблице чуть выше, букву L. На следующей же странице, Format Partition, тоже все оставляем без изменений кроме поля Volume label, куда вносим значение DBlog взятое из той же строки той же таблицы.
Next и Finish. Итоговый вид который принимает только что проинициализированный и отформатированный диск в оснастке консоли Computer Management будет таким.
Повторяем ту же процедуру (начиная с вывода диска в Online и далее) для трех оставшихся дисков подставляя, разумеется, свои буквы и метки для каждого. Опять же, пользуйтесь последней таблицей. После завершения четвертой процедуры получаем примерно такой расклад.
Теперь нам точно так же будущую пассивную ноду (clustNodeB) нужно сделать вторым клиентом SAN-сервера, ведь ей тоже придется работать с его дисками! Идем на указанную ВМ и совершенно «буква-в-букву» повторяем все наши действия из текущего шага, начиная с первых его строк и, собственно, вплоть до открытия оснастки консоли Computer Management где мы увидим уже готовые к выводу в Online четыре SAN-диска. Единственным исключение из этого списка задач — удалять инициатора-ноду A (как мы это сделали с формальным, «нулевым» инициатором), конечно, не нужно, просто добавляем к ней второго инициатора, ноду B. Кстати, при таком добавлении нас предупредят, что множественные инициаторы к одному iSCSI провайдеру вообще-то подразумевают кластерное окружение. Без колебаний отвечаем Yes, именно такое окружение мы и создаем.
Итак, сейчас мы уже находимся в Computer Management виртуальной машины clustNodeB. Щелкаем по узлу Disk Management в дереве слева и, первым делом, выводим все 4 SAN-диска в Online уже на этой ноде. Мы видим что диски уже инициализированы, отформатированы и имеют нужные метки. И более того, им уже присвоены буквы! Единственное «упущение» — буквы эти им присвоены просто подряд, а не по той же схеме как мы это делали на ноде A. Поправим ситуацию. Щелчок правой кнопкой мыши по тому (а не диску) D: и выбираем в контекстном меню Change Drive Letter and Path...
Поскольку метка выбранного нами тома имеет значение MSDTC то правильная буква согласно нашей таблице не D: а M:, ее и устанавливаем. Меняем буквы остальных трех дисков и по итогу имеем картину очень похожую на таковую в предыдущей ноде.
Вот теперь вы можете снова открыть обозреватель (тот что Windows) на любой из двух нод и убедиться, что компьютер «думает» что он обладает целыми пятью локальными дисками! И если в отношении C: он совершенно прав, то в отношении Q:, M:, T:, L: он несколько заблуждается, однако это «правильное заблуждение», оставим наши ноды в таком счастливом неведении.