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

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





7. «Повысить» одну из ВМ до контроллера домена.

Понятно что повышать мы будем ВМ по имени clustDC, не зря же мы ее так назвали. По сути, нам требуется «поднять» на ней службу Active Directory Service, что и превратит указанную виртуальную машину в domain controller (DC), а поскольку служба Active Directory интегрирована со службой DNS, то та же ВМ станет еще и DNS Server для всех компьютеров нашего будущего домена.

Для начала процедуры открываем на указанной ВМ диспетчер Server Manager (из меню Administrative Tools) и слева выбираем узел Roles. Тогда справа появится возможность щелкнуть по ссылке Add Roles, так и поступаем.

Server_Manager_Add_Roles

На странице мастера Select Server Roles нам будет представлен список ролей потенциально готовых для добавления к нашему серверу. Все нам, конечно, не нужны, мы отмечаем галочкой лишь пункт Active Directory Domain Services.

Select_Server_Roles

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

Add_required_features

Возвращаемся к основной странице визарда Add Roles, где нужная нам роль теперь уже основательно отмечена галочкой.

Active_Directory_Domain_Services

Несколько раз Next, один раз Install — готово!

Role_added_successfully

Закрываем визард щелчком по кнопке Close. Мы успешно добавили нашему серверу роль, но это еще пока не повысило его до полнофункционального контроллера домена. Эту завершающую фазу процесса исполняет визард второй, Active Directory Domain Services Installation Wizard (уж такое у него длинное название). Запустить его можно разными способами, в том числе это можно было бы сделать прямо из финального окна сообщившего нам об успешном добавлении роли Active Directory Domain Services. Но раз уж мы его закрыли, то давайте по простому: в окне Run набираем dcpromo.exe и жмем Enter. Нас приветствует упомянутый мастер с тяжко перевариваемым именем.

Active_Directory_Domain_Services_Installation_Wizard

Несколько раз Next до страницы выбора: предназначен ли создаваемый контроллер домена для леса (forest) существующего или нового. Говорим, разумеется, что это будет новый домен в новом же лесу.

Create_a_new_domain

Тут нас, после щелчка по Next, может (и с большой вероятностью будет) подстерегать грозное предупреждение довольно объемного содержания начинающееся словами:

The local Administrator account becomes the domain Administrator account when you create a new domain. The new domain...

Без суеты, на время оставив наш визард как он есть, открываем Computer Management (из меню Administrative Tools) и с помощью узла Local Users and Groups меняем локальному администратору машины clustDC пароль на цифру 123. А если пароля у него нет — значит устанавливаем его в это значение. Однако:

  • локальный администратор машины — это не наш пользователь adm, это тот что BUILTIN\Administrator!
  • что бы данный финт в принципе сработал, вы должны были четко выполнить инструкции по настройке самой первой («мастер») виртуальной машины, особенно критично было удаление проверки сложности пароля.

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

Итак, после выбора типа установки домена (новый домен для нового леса) очередная страница мастера — Name the Forest Root Domain. Здесь мы должны ввести имя нового домена, причем имя называемое «полностью определенным именем домена» (Fully Qualified Domain Name, FQDN). Мы остановимся на варианте clustDOM.local, который и вводим в единственное поле данной страницы.

Fully_qualified_domain_name

Очередная страница визарда — Set Forest Functional Level, на которой мы ни секунды не сомневаясь выбираем Windows Server 2008 R2, ибо иных серверов в нашем домене нет, и, по видимому, не будет.

Forest_functional_level

На странице Additional Domain Controller Options оставляем все как есть. Опция DNS server уже помечена для нас и это хорошо, такой сервер нам понадобится буквально через пару минут.

Additional_domain_controller_options

Если при попытке через Next продвинуться с данной страницы далее мы получаем предупреждение о невозможности делегирования данного DNS сервера (а получаем мы его с вероятностью чуть более чем 99.99%), то просто соглашаемся на продолжение визарда выбирая кнопку Yes. Для корневого домен-контроллера леса (forest root domain controller, а это именно наш случай) такое предупреждение полностью нормально и никаких телодвижений не требует.

Новая страница носит название Location for Database, Log Files and SYSVOL. Определяем где разместятся системные файлы нашего домен-контроллера. Варианты по умолчанию устраивают нас более чем, просто Next.

Location_for_database_log_files_and_sysvol

Продолжаем, страница Directory Service Restore Mode Administrator Password. Сюда нужно ввести пароль. Однако это не пароль будущего администратора домена! Вовсе нет. Это пароль необходимый для работы с контроллером домена находящемся в особом режиме, restore mode. Объяснение сути и необходимости этого режима для тех целей что мы перед собой ставим будет совершенно избыточно, поэтому давайте просто введем что-нибудь нейтральное, вроде уже полюбившегося нам «магического» числа 123. Next.

Restore_mode_administrator_password

Ну наконец-то, страница итогов, она же Summary! Бегло проверяем наши установки и снова Next.

Active_Directory_Domain_Services_Wizard_Summary

Начинается конфигурирование Active Directory Domain Service, ждем. В финальном окне щелкаем Finish (попутно отметив для себя факт успешного окончания установки сервиса Active Directory) и соглашаемся на перезагрузку нового контроллера домена.

Active_Directory_Domain_Services_Wizard_Completing

Формально установка будет завершена лишь после того, как вы войдете в обновленную систему. Напомню, что служба DNS установилась совместно с Active Directory, поэтому нам не нужно об этом беспокоиться. Но вот как правильно залогиниться в наш только что созданный контроллер — вот об этом побеспокоиться следует! И как раз этот вопрос (помимо массы прочих) освещается в следующем, 8-м шаге данного мануала.

8. Создать на контроллере домена DNS сервер и сконфигурировать его.

Так вот, сразу определимся с корректным логином в домен-контроллер. Начиная с этих строк и далее, фраза «залогиньтесь в домен-контроллер» будет означать вход под именем доменного администратора и только его. Иными словами, сразу же после вынужденной перезагрузки связанной с окончанием процесса инсталляции Active Directory Domain Service из предыдущего 7-го шага, мы, в окне приветствия машины clustDC, указываем доменного пользователя CLUSTDOM\adm (соответствующим администратором он станет через несколько мгновений) и его «волшебный» пароль 123. И для указанной виртуальной машины отныне поступаем так всегда. OK, залогинились.

Первым же делом делегируем совершенно полный набор полномочий в рамках нового домена нашему пользователю adm. Для чего открываем оснастку консоли Active Directory Users and Computers, а для этого достаточно из меню Administrative Tools выбрать одноименный же пункт.

Menu_Administrative_Tools_Active_Directory_Users_and_Computers

В указанном окне, в дереве слева выбираем узел Users, в панели справа находим нашего пользователя adm, и включаем его в предопределенные группы Domain Admins и Enterprise Admins.

Active_Directory_Users_and_Computers_users

Make_adm_as_Domain_Admins

Щелкаем OK, окно Active Directory Users and Computers можно закрывать.

Теперь — мы хотим правильно сконфигурировать наш DNS сервер. Почему мы вообще обращаемся к этому вопросу? Потому что мы хотим при обращении к компьютеру, допустим, clustNodeA так и писать — «clustNodeA». А не какие-то малозначащие цифры 192.168.xx.yyy. Опять же, если у нас будет система из 25-ти компьютеров и серверов нам что же, таблицу «Computer Name→IP адрес» состоящую из того же количества строк так в голове и носить? И днем, и ночью? Нет уж, делаем итоговое решение значительно более «человекоориентированным». Собственно DNS сервер как таковой у нас уже есть. Напомню, что он успешно проинсталлировался в пару к свежеустановленному Active Directory Domain Service. Но, разумеется, пока он совершенно пуст и не содержит ни одной полезной записи о компьютерах нашего решения. Исправим это.

Вполне предсказуемо, та самая таблица трансляции имен в адреса что мы не желаем держать в голове, в DNS сервере реализуется как, в целом, обычная база данных. Только называется она не так, а зоной DNS (DNS zone). Вообще-то строго (и формально) говоря, зона DNS — это такой «сегмент» глобальной системы доменных адресов (Domain Name System, та самая DNS) для которого делегированы администраторские полномочия. Однако для нашего «чисто практического» мануала отвлечение на теоретическую науку и точные формулировки непозволительная роскошь, а с практической точки зрения все обстоит именно так как рассказывает автор: зона DNS — это база данных, с записями. То что наша зона-база будет содержать записи (упрощено) clustNodeA=192.168.xx.yyy — вполне ожидаемо и естественно, ради этого, собственно, весь огород. Однако, как ни странно, там должны быть и встречные записи (снова упрощено), 192.168.xx.yyy=clustNodeA! То есть как: «должны» это несколько чересчур, все будет работать и без таких встречных записей. Но все же их наличие делает наш DNS сервер «полноценным» (образно выражаясь) и обеспечивает корректную работу ряда сетевых утилит — tracert, ping и т.п. С учетом того, что конкретно в Windows Server 2008R2 такие «желательные» записи создаются крайне легко мы, конечно, не упустим случая тренировки и по этому вопросу.

С помощью меню Administrative ToolsDNS открываем оснастку консоли DNS Manager.

Menu_Administrative_Tools_DNS

В открывшемся окне оснастки сразу заметны два под-узла корневой ноды представляющей из себя наш контроллер. Я говорю о под-узле Forward Lookup Zones, и под-узле Reverse Lookup Zones. Возможно вы уже догадываетесь, что первая содержит «прямые» записи (без которых жить невозможно абсолютно), а вторая — записи «встречные», опциональные. Однако узлы эти всего лишь интерфейсные элементы оснастки, никакой реальной базы (хоть пустой, хоть с записями) за ними не стоит. Такую базу нам следует создать самим, «ручками». Что ж, нам не привыкать: правую кнопку на Reverse Lookup Zone и пункт New Zone... контекстного меню.

DNS_Manager_Reverse_Lookup_Zone

Открывается один из многочисленных мастеров OS Windows Server, на сей раз это New Zone Wizard.

New_zone_wizard

Next, и — страница Zone Type. Снова, не погружаясь в дебри сетевых технологий, скажем что наиболее типичной и распространенной зоной является основная зона (primary zone). Проводя параллели понятные нам, «SQL-щикам», основная зона — это база хранящая оригинальные записи (примерно как это делает паблишер в технологии репликации данных). Однако в отличии от паблишера и репликаций такая база основной зоны всегда и гарантировано открыта как на чтение, так и на запись (при условии наличия у вас достаточных полномочий на это действие, разумеется). В общем, без колебаний выбираем именно такую зону. Проставленная внизу той же страницы галочка указывает что наша «главная копия» будет сохранена в доменной службе Active Directory, а не просто во внешнем файле .dns (обычно создаваемым в папке %systemroot%\System32\Dns). Технически возможен и второй подход, однако, конечно же, настоятельно рекомендуется первый.

New_zone_wizard_Zone_Type

Очередная страница Active Directory Zone Replication Scope. Собственно говоря ее назначение должно быть понятно из ее названия: какие еще домен-контроллеры нашего леса будут получать копии оригинальных записей (т.е. будут выполнять роль аналогичную подписчикам в SQL репликации). Нас вполне устроит вариант номер два — сохранение (дублирование) записей на всех DNS серверах запущенных на любом домен-контроллере в рамках нашего домена. С учетом что в конкретно нашей системе это условие выполняется только компьютером clustDC и больше никаким мы, фактически, отказываемся от репликации записей. Ну да и не очень-то и хотелось.

New_zone_wizard_Active_Directory_Zone_Replication_Scope

Следующая страница мастера не требует, по счастью, вообще никаких пояснений — четвёртая версия IP протокола по-прежнему «наше все», просто Next.

New_zone_wizard_Reverse_Lookup

Теперь у нас страница Reverse Lookup Zone Name, причем это уже второе ее появление. Забавно что и предыдущая страница имеет ровно тоже самое имя. Однако это не баг мастера, просто тип протокола тоже (в том числе) определит финальное имя зоны. Так что это скорее одна логическая страница «размазанная» по двум физическим. Как бы там ни было — переходим непосредственно к определению имени зоны. В наших условиях проще определить имя через Network ID, т.е. идентификатора той сети «под» которую создается зона. У нас под какую сеть она создается? Под публичную, разумеется! Вот так и пишем: 192.168.81.

New_zone_wizard_Reverse_Lookup_Zone_Name

После ввода Network ID правильное финальное имя реверсивной зоны будет сформировано автоматически, видеть его можно в нижнем текстовом поле только для чтения. Next и очередная страница Dynamic Update. Она определит, будут ли обновления записей нашей зоны-базы безопасными или нет. В первом случае изменения смогут вносить лишь компьютеры нашего домена, во втором — любые компьютеры. Есть и третий вариант, закрыть обновления «наглухо», вне зависимости кто их пытается предложить. Нас вполне устроит вариант по умолчанию, Allow Only Secure Dynamic Updates. Т.е. безопасное обновление с компьютеров — членов домена. Тем более что эта опция является рекомендованной для Active Directory.

New_zone_wizard_Dynamic_update

Ну, и наконец — Finish, который мы незамедлительно и щелкаем.

New_zone_wizard_Completing

Если «косяков» допущено не было, обе зоны (и «прямая», и реверсивная) созданы. Проверить этот факт очень легко, достаточно распахнуть узел Forward Lookup Zones все той же оснастки консоли. В качестве его под-узла теперь должен фигурировать наш домен clustDOM (более точно — clustDOM.local). Если таковой обнаруживается — отлично, пока у нас все по плану. Теперь у нас есть реальная база. Пришла пора наполнить ее кой-каким содержимым. Вызываем контекстное меню упомянутого под-узла и щелкаем его пункт New Host (A or AAA)....

DNS_Manager_New_host_Menu

Такой наш ход откроет окно для внесения самой востребованной записи — типа A, или AAAA (первая для 4-й версии протокола IP, вторая для 6-й), или, как ее еще называют — записи ресурса (resource record). Подавляющее большинство DNS-записей относится именно к одному из этих двух типов. С учетом того, что как раз эти записи используются в зоне для связывания компьютерных имен (имен узлов) с IP-адресами ничего удивительного в этом факте нет. Давайте, для примера, поставим в соответствие имени компьютера clustNodeA его IP-адрес 192.168.81.111.

DNS_Manager_New_host_name

Не забудьте проверить наличие галочки Create associated pointer (PTR) record перед щелчком по кнопке Add Host! Ее наличие говорит о необходимости внесения записи не только «туда» (forward, имя компьютера переводится в IP-«цифры»), но и записи «обратно» (reverse, IP в имя компьютера). Повторяем описанную процедуру с машинами clustNodeB, clustSAN, clustWork не забывая каждый раз увеличивать IP-адрес на единицу. Вслед за внесением последнего компьютера (clustWork) щелкаем кнопку Done и проверяем финальный результат.

DNS_Manager_New_host_five_names

Обратите внимание, что A-запись для самого DNS-сервера (виртуальная машина clustDC) тоже обязана появиться в списке, хотя мы не указывали ее внесение. Это «любезность» со стороны мастера создания новой зоны. Если ваш результат совпадает с показанным (разумеется с учетом возможной корректировки адресов, если ваша публичная сеть не 81-я) — смело закрывайте окно DNS Manager, и эту фазу «подъема» кластера вы успешно преодолели.