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

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


366bef3a

3. Создать 5 «клонов» «мастер»-машины.

Переходим к клонированию. Сейчас у нас в консоли виртуальных машин должна быть всего одна выключенная ВМ — наш «мастер».

Выбираем пункт Clone из главного меню консоли.

VM_Manage_Clone

Должен запуститься Clone Virtual Machine Wizard.

Clone_Virtual_Machine_Wizard

Сообщаем, что нам нужен клон машины в том ее состоянии, в котором она пребывает на текущий момент.

Clone_form

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

Clone_type

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

  • папка D:\VM\ — «корень» всех ВМ. Абсолютно все машины вне зависимости от цели их создания находятся в этой папке;
  • папка D:\VM\ClusterPack5\ — «корень» для ВМ имеющих отношения к кластеру. Т.е. все 5 машин создаваемого нами решения будут собраны в этой под-папке;
  • папка D:\VM\ClusterPack5\<имя_виртуальной_машины>\ — персональная папка каждой из пяти ВМ.

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

Clone_machine_name

Заканчиваем визард и некоторое время ждем окончания процесса клонирования (запаситесь терпением — 8Gb не копируются односекундно даже в пределах одного диска!). Повторяем описанную процедуру еще 4 раза практически шаг-в-шаг, меняя лишь на последнем экране все того же визарда имя очередной ВМ и путь к папке с ее файлами. Что касается имен — выбирайте на каждой итерации очередное из вот этого списка:

  • clustNodeA
  • clustNodeB
  • clustSAN
  • clustWork

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

4. Внести некоторые изменения в конфигурацию рабочих ВМ.

Подумаем вот над чем — чем хороша возможность клонирования ВМ? Очевидно тем, что мы очень быстро (относительно, конечно, но определенно быстрее, чем если бы мы взялись «заливать» OS на каждую машину из пяти) получили практически готовый набор для нашего будущего стенда. Казалось бы — подкорректируй состав оборудования на тех машинах что требуют этого (намекаю — машины-ноды) и вперед, к сияющим кластерным вершинам! Однако в IT-отрасли редко встречаются шаги, решения и технологии несущие абсолютно одни плюсы и не содержащие ни единого минуса. Так и тут — копнешь чуть глубже и пожалуйста, вот и минус «нарисовался». Имя этому минусу — SID (Security Identifier), точнее даже не это отдельное число, а целый комплекс установок и данных которые четко отделяют компьютер А от компьютера Б. То есть в настоящий момент все наши 5 ВМ представляют собой совершенные копии друг-друга (клоны они клоны и есть), включая и те самые «computer-specific» данные. Политика поддержки клиентов компании Microsoft (support policy) четко предписывает — всякая и любая система предназначенная для дальнейшего клонирования должна (безусловно) быть обработана утилитой System Preparation (Sysprep). Она «сносит» те самые данные которые я собирательно назвал «SID-ом» (опять же, не воспринимайте этот так что мы имеем «затык» в одной единственной цифре! это комплекс данных), и которые не должны «расползтись» по клонам. Снова, с практической точки зрения, и с учетом что ни на какой support для нашей тест-площадки мы не претендуем и близко — нельзя ли для простоты и скорости этот пункт игнорировать? Можно, да вот наш будущий кластер «заартачится». Одним словом:

Если вы намерены довести вашу тест-площадку до состояния кластера (не важно с SQL сервером поверх него или нет) ни в коем случае не игнорируйте процедуру описываемую далее. Автор может вам практически гарантировать серьезные проблемы при «подъеме» кластера в противном случае. В тоже время, если вы ограничитесь созданием домена (а уж тем более только лишь рабочей группы) процедура описанная ниже становится для вас просто желательной, но никак не критически важной. С высокой степенью вероятности у вас все будет работать и на машинах совпадающих как две капли воды, проблемы могут обнаружиться лишь при очень самобытных условиях. В тоже время — да, вы правы — для проведения экспериментов максимально приближенных к условиям серверов работающих в «продакшн» окружении следует сначала «от-Sysprep-ить» «мастер»-машину, затем выключить ее (ни в коем случае не перегружая! ну или, как минимум, не позволяя стартовать системе прошедшей обработку данной утилитой) и уже из такого подготовленного образа делать клоны. Это будет идеально, но каждую машину придется настраивать/активировать снова, и снова, и снова... Автор предпочел (см. далее) «золотую середину»: не идеально, но работает и усилий настолько минимально, насколько это возможно. Но если вы чувствуете потребность/необходимость делать все «по высшему разряду» — нет проблем, меняйте SID-ы у каждой ВМ.

Итак, практические «грабли» заключаются в том, что кластер (и именно он) будет очень сильно «недоволен», когда обнаружит что две его потенциальные ноды фактически ничем не различаются. Поэтому мы обязаны применить указанный выше инструмент, но всего к двум машинам: clustNodeA и clustNodeB, т.к. они и являются будущими нодами. На обоих действуем абсолютно аналогично и даже можно пока первая машина «думает» переключаться на вторую и воспроизводить действия на ней. Сама обработка крайне проста. Первое — из окна Run запустить утилиту C:\Windows\System32\sysprep\sysprep.exe. Второе — установить в открывшемся окне опции согласно следующей иллюстрации и щелкнуть OK.

SysPrep

Трижды проверьте состояние чек-бокса Generalize (он должен быть отмечен) перед нажатием на OK. Обе машины перезагрузятся (после некоторого время потраченного ими на подготовку себя самих к запуску с новым «SID-ом») и предложат вам сделать «начальные установки», которые обычно производятся в момент инсталляции OS Windows Server (страна/регион, время/валюта, раскладка клавиатуры). Вся процедура очень проста и не займет у вас более 3-5 минут. А вот теперь — плохие новости. 99% настроек что мы производили со своей «мастер»-ВМ в пункте 2 настоящего мануала (а точнее в том подразделе этого пункта где мы занялись ее «причесыванием») будут «сброшены в ноль», увы. :( И у нас не остается иного выхода кроме как выполнить тот же отрезок инструкций еще раз, а точнее еще дважды — по разу на каждой из машин-нодов. «Однообразная работа», да. Утешайте себя во-первых, относительной краткостью списка упомянутых инструкций, а во-вторых, тем фактом что большинство-то машин (а именно — три) в полном порядке, их «прогонять» через Sysprep не требуется! Как бы там ни было, но к данной точке мануала вы должны иметь пять ВМ настроенных совершенно идентично (важно! причем идентичность должна быть как «внешняя», с точки зрения консоли виртуальных машин VMware, так и «внутренняя», с точки зрения OS Windows Server), но у двух должны быть сменены «SID-ы».

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

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

  • clustNodeA
  • clustNodeB
  • clustWork

увеличьте выделяемую им оперативную память до 1536MB. На эти машины мы будем ставить или сам SQL Server, или его клиентскую часть, надо подумать о памяти и для них. Только для первых двух (т.е. машин-нодов) добавьте по второму сетевому адаптеру (причины вынуждающие нас сделать это пояснялись ранее). Для чего: в окне свойств каждой машины щелкните Add... что бы перейти к списку доступного оборудования.

Add_new_hardware

Из списка выберите пункт Network Adapter, и щелкайте Next >.

New_Network_Adapter

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

Network_Adapter_Type

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

Two_Network_Adapters

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

  • clustDC
  • clustNodeA
  • clustNodeB
  • clustSAN
  • clustWork

Далее, всем машинам нужно назначить статические IP-адреса, а нодам — так и целых два. В машинах с одной сетевой картой ошибиться в выборе невозможно, а в машинах-нодах для описываемой процедуры выбирайте в окне Network Connections тот адаптер из двух, что уже подключен к 81-й сети (т.е. имеет IP-адрес 192.168.81.3). Наверняка таким окажется Local Area Connection, а не Local Area Connection 2. После этого на каждой из пяти машин, у соответствующего сетевого адаптера, меняйте только IP-адрес, остальные настройки оставляйте как есть (по факту достаточно изменить лишь последнюю цифру в октете адреса). По итогу наши адаптеры обзаведутся такими адресами:

  • clustDC — 192.168.81.110
  • clustNodeA — 192.168.81.111
  • clustNodeB — 192.168.81.112
  • clustSAN — 192.168.81.113
  • clustWork — 192.168.81.114

Теперь обратимся к двум пока незадействованным адаптерам на каждой из нод, которые были созданы нами эксклюзивно под приватную сеть. Настройки их IP-адресов следует выполнить согласно следующей таблице:

  • IP-address (для второго адаптера машины clustNodeA) — 192.168.136.111
  • IP-address (для второго адаптера машины clustNodeB) — 192.168.136.112
  • Subnet mask (обе машины) — 255.255.255.0 (по умолчанию, иными словами)
  • Default gateway (обе машины) — не заполнять вообще
  • Preferred DNS server (обе машины) — не заполнять вообще

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

Two_Adapters_in_Network_Connections

Теперь нажмите и сразу отпустите клавишу ALT , что бы появилось дополнительное меню в этого окна. В этом меню выбираем AdvancedAdvanced Settings. В открывшемся окне, с помощью боковых кнопок-стрелок делаем публичную сеть (в нашем случае это 81-я сеть и наверняка Local Area Connection) первой в списке, а приватную (в нашем случае это 136-я сеть и «Local Area Connection 2») — второй. Вот что должно получиться по итогу.

Advanced_Settings_for_Network_Adapters

Упрощенно, можете считать, что для обоих компьютеров публичная сеть теперь стала «главной», а приватная — «вспомогательной». Напомню, что проделать эту операцию следует на обоих компьютерах будущих нодах. Если все сделано верно (и изменения приоритетов зафиксированы щелчком по OK, разумеется) консольная команда

ipconfig /all

запущенная на этих двух машинах будет сначала выводить информацию по карте закрепленной за 81-й сетью, затем — за 136-й.