SqlCmd все о SQL технологиях.





Все что необходимо для изучения и работы с СУБД Microsoft SQL Server, MySQL, MariaDB, MongoDB. Авторские статьи, библиотека фрагментов T-SQL кода, сборник полезных инструментов.



MS SQL Server, SQL Server, T-SQL, исходники, сниппеты, статьи, учебники SQL, утилиты SQL, инструменты SQL



Header RSS-подписка на обновления сайта eMail-подписка на обновления сайта

SQL кластер на VMware Workstation. Часть 7/11.





9. Ввести оставшиеся четыре ВМ в домен и завершить его формирование.

Итак, у нас есть работающий домен-контроллер да еще и с DNS-сервером «поверх» него. Введем в домен оставшиеся четыре виртуальных машины. Процесс совершенно аналогичен для любой из них, возьмем, для примера, clustNodeA.

Переключаемся на указанную ВМ, а если она пока выключена — запускаем ее и логинимся в систему. Логиниться, понятно, пока следует под локальным администратором (adm), ведь мы же еще не в домене. В готовой к работе ВМ мы первым делом идем в настройки ее сетевых подключений. Для машин с одним сетевым адаптером ошибиться нельзя, а для машин с двумя (это пара машин — будущих нод кластера, clustNodeA как раз одна из них) выбираем тот из двух, что подключен к публичной (81-й) сети. Для выбранного адаптера открываем окно свойств его IP протокола 4-й версии, или, выражаясь проще — окно с его IP-адресом. Зачем мы его открыли? А затем, что буквально через минуту clustNodeA войдет в состав домена и сможет пользоваться (и даже обязан будет это делать) услугами доменного DNS, того самого что мы так кропотливо настраивали в предыдущем 8-м шаге. Стало быть, нам следует изменить поле Preferred DNS Server указанного окна на IP-адрес того сервера, что выполняет роль доменного DNS. А это, вне сомнений, IP-адрес машины clustDC, т.е. 192.168.81.110, его и указываем.

Change_Preferred_DNS_Server_For_TCPIP

Щелкаем OK, с сетью пока закончили.

Теперь приступаем непосредственно к добавлению clustNodeA в домен. Из окна Run выполняем команду oobe, что приводит к открытию окна Initial Configuration Tasks. В нем нам интересна ссылка Provide computer name and domain.

Initial_Configuration_Tasks_Window

В новом окне системных свойств щелкаем Change... и в поле Domain вводим clustDOM.local.

Domain_Changes

Нас должны запросить учетные данные безопасности (они же credentials) того, кто имеет полномочия на изменения состава домена. У нас таковые вполне имеются, CLUSTDOM\adm и 123 соответственно.

Name_password_for_domian_administrator

Если все проделано верно нас поздравят с «вливанием» машины в новый домен.

Welcome_to_Domain

А еще нас пригласят перезагрузится, с чем мы спорить не будем. Пока перезагружается clustNodeA только что описанную операцию ввода в домен уместно будет провести с тремя оставшимися виртуальными машинами и их тоже отправить на reboot. Не забывайте на каждой очередной ВМ начинать описанную процедуру со смены IP-адреса предпочитаемого DNS сервера!

Начиная с момента ввода последней, пятой, ВМ в домен мы на все виртуальные машины нашего тест-стенда всегда логинимся как доменный администратор, т.е. CLUSTDOM\adm и 123. Другие учетные записи не используем. Это правило действует, как минимум, до момента полной установки SQL сервера в кластерном окружении, т.е. до конца настоящего мануала.
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 ToolsiSCSI Initiator.

Menu_Administrative_Tools_iSCSI_Initiator

Открывается окно свойств текущего iSCSI клиента, которым в настоящий момент выступает ВМ clustNodeA. Прежде всего отправляемся на закладку Discovery и кликаем там кнопку Discovery Portal...

iSCSI_Initiator_Properties_Discovery_tab

Тем самым мы заявляем что мы готовы указать нашу цель, наш iSCSI Target. В открывшемся окне следует указать IP-адрес последнего. Поскольку у ВМ clustSAN адрес 192.168.81.113 его и вводим, порт оставляем как есть.

Discover_Target_Portal_Window

Теперь вспоминаем вот про что. Когда мы в 5-м шаге данного мануала конфигурировали iSCSI сервер мы не указали ни одного клиента которому будет разрешено подключение к нему. Вместо этого мы поставили формальный 0 в поле идентификации клиента, а «на бумажке», или просто «в голове» поставили себе галочку — «вернуться позже и исправить». Вот давайте эти исправления и внесем, иначе наш сервер так и останется без клиентов. Прежде всего выясняем реальный iSCSI Qualified Name (IQN) (что это такое объяснялось в том же 5-м шаге) текущего клиента. Для чего переключаемся на последнюю закладку активного окна — Configuration. Там в поле Initiator Name будет проставлено интересующее нас значение.

iSCSI_Initiator_Properties_Configuration_tab

Выделяем, копируем в буфер обмена. Поскольку фактически все буфера всех виртуальных машин (но только запущенных в настоящий момент, разумеется), а заодно и буфер хост-компьютера полностью синхронизированы, скопированное значение окажется, в том числе, и на машине clustSAN. Именно по этой причине лучше ее запустить (и корректно залогиниться в ее систему) до того как мы скопируем указанное значение. После чего, временно оставив iSCSI клиента (машину clustNodeA) переключаемся на машину-сервер, clustSAN. На этой последней вновь, как и в шаге 5-м, открываем из меню Administrative Tools окно iSCSITarget. Находим инициализированный нами ранее iSCSI сервер по имени FourDisksSAN и вызываем, через контекстное меню, окно его свойств.

iSCSITarget_Properties_menu

В окне свойств переключаемся на вкладку iSCSI Initiators и сначала удаляем фиктивного клиента (у нас теперь есть реальный), а затем щелкаем по кнопке Add...

FourDisksSAN_Properties_iSCSI_Initiators_tab

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

Delete_iSCSI_Initiators_warning

Ну а после нажатия на кнопку Add... мы попадаем в окно Add/Edit Identifier. Именно здесь мы можем указать параметры клиента, которому мы хотим открыть доступ на сервер. Для этого во-первых, убеждаемся что тип идентификации клиента выставлен в IQN, ну а во-вторых, в поле Value вводим то самое запомненное (в разделяемом буфере обмена) значение.

Add_New_iSCSI_Initiator

Дважды щелкаем OK. Оставляем теперь в покое clustSAN (однако, разумеется, не выключая ее) и возвращаемся к нашему клиенту clustNodeA. Там у нас продолжает быть открытым окно свойств iSCSI инициатора, переходим на его вкладку Targets и щелкаем кнопку Refresh.

iSCSI_Initiator_Properties_Targets_tab

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

iSCSI_Initiator_Properties_Targets_tab_Discovered_Targets_panel

Вполне предсказуемо что доступных серверов будет ровно одна штука, нам больше и не требуется. Однако обратите внимание на колонку Status с последней иллюстрации, а точнее на ее значение. Заметили что оно равно Inactive? Сам факт нахождения iSCSI сервера в списке панели Discovered targets говорит о том, что клиент может к нему подключиться. Но может и не подключаться — дело-то добровольное. Так вот отмеченное значение говорит как раз о том, что соединение не установлено. Исправим ситуацию, для чего достаточно щелкнуть кнопку Connect возле нижней границы той же панели Discovered targets.

iSCSI_Initiator_Properties_Targets_tab_Discovered_Targets_Connect

В окне подтверждения соединения просто щелкаем OK принимая все параметры по умолчанию. Вот, теперь другое дело — коннекшен установлен!

iSCSI_Initiator_Properties_Targets_tab_Discovered_Targets_Status

Следующий вопрос — какие ресурсы из доступных на сервере мы желаем использовать? Ведь если SAN состоит из, допустим, 50-ти дисков это не значит что клиент обязан найти занятие для каждого. Опять же — дело добровольное, можно и одним диском ограничиться. В данном случае нам потребуются 4-е диска из 4-х, но это не более чем частный случай описываемой ситуации. В любом случае клиент обязан четко заявить свои притязания на каждый ресурс сервера (iSCSI сервера, разумеется) который он собирается использовать в «личных и корыстных» целях. А поэтому нам ничего не остается кроме как отправиться на закладку Volumes and Devices все того же окна настроек iSCSI клиента.

iSCSI_Initiator_Properties_Volumes_and_Devices_tab

Тут с помощью кнопки Add... мы могли бы начать добавлять по одному диску за раз, однако есть способ лучше — кнопка Auto Configure. Она опросит сервер на предмет всех доступных ресурсов и выведет их в список Volume list. Попробуем?

iSCSI_Initiator_Properties_Volumes_and_Devices_tab_Volume_List

Отлично! Все четыре доступных диска «зарегистрированы» для их использования текущим клиентом. Если бы нам это было нужно от «лишних» дисков можно было бы отказаться кнопкой Remove, однако, как уже было отмечено, нам нужны все четыре диска. Поэтому оставляем все как есть и щелчком по OK в самом низу окна iSCSI Initiator Properties закрываем последнее.

Теперь у нас на clustNodeA помимо «реально-локального» диска C: есть 4 «псевдо-локальных» диска. По крайней мере сам этот компьютер считает их абсолютно своими собственными. Однако это пока Offline локальные диски, их нужно вывести в Online и проинициализировать. Открываем оснастку консоли Computer Management из меню Administrative Tools и щелкаем по узлу Disk Management в дереве объектов слева. Видим, что прямо сейчас один диск у нас в он-лайне (C:) и четыре в офф-лайне.

Disk_Management_All_Local_Disks

Какие параметры дисков нам будут нужны для их корректной инициализации? Во-первых, нам нужно как-то (скорей всего по объему) определить предназначение этого диска. После этого следует определиться с меткой (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 из контекстного меню.

Disk_Management_make_disk_online

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

Disk_Management_Initialize_disk

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

Initialize_Disk_Window

В третий раз мы кликаем уже не по диску, а по его тому и выбираем из контекстного меню New Simple Volume.

Disk_Management_New_Simple_Volume

Первые две страницы открывшегося визарда пролистываем «по умолчанию», отдавая тем самым все имеющееся пространство диска под создаваемый том, а на странице Assign Drive Letter or Path выбираем, согласно нашей таблице чуть выше, букву L. На следующей же странице, Format Partition, тоже все оставляем без изменений кроме поля Volume label, куда вносим значение DBlog взятое из той же строки той же таблицы.

New_Simple_Volume_Wizard_Format_Partition
Читатель блога eduard.bader в комментариях к этой части руководства совершенно справедливо заметил, что для производственных сред настойчиво рекомендуется задавать размер кластера диска (опция Allocation Unit Size на последней иллюстрации) в фиксированное значение 64K. Потому что 8 последовательных страниц, да по 8К каждый будет как раз тот самый всем знакомый еxtent. Поскольку подогнать размер экстента под размер кластера решительно невозможно, делаем обратную подгонку. Аналогичную рекомендацию касательно размера кластера в 64K дают и производители HDD, описывая лучшие практики по эксплуатации их продуктов в системах SQL Server. Разумеется, для создаваемого нами в настоящий момент тестового стенда замечание совершенно не актуально, для него можно как выставить рекомендованное значение, так и удовлетвориться значением по умолчанию.

Next и Finish. Итоговый вид который принимает только что проинициализированный и отформатированный диск в оснастке консоли Computer Management будет таким.

Disk_Management_Disk_ready_to_work

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

Disk_Management_all_four_disks_are_ready

Теперь нам точно так же будущую пассивную ноду (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...

Disk_Management_Change_Drive_Letter_and_Paths_on_node2

Поскольку метка выбранного нами тома имеет значение MSDTC то правильная буква согласно нашей таблице не D: а M:, ее и устанавливаем. Меняем буквы остальных трех дисков и по итогу имеем картину очень похожую на таковую в предыдущей ноде.

Disk_Management_all_four_disks_are_ready_on_node2

Вот теперь вы можете снова открыть обозреватель (тот что Windows) на любой из двух нод и убедиться, что компьютер «думает» что он обладает целыми пятью локальными дисками! И если в отношении C: он совершенно прав, то в отношении Q:, M:, T:, L: он несколько заблуждается, однако это «правильное заблуждение», оставим наши ноды в таком счастливом неведении.