Главная Windows, Новое Active Directory — трудности перевода. Часть 2
  • Active Directory — трудности перевода. Часть 2

    dc Из первой части, мы четко уяснили, что для нормальной работы вашей доменной сети контроллер домена должен быть доступен, при этом иметь созданные учетные записи для ваших пользователей и компьютеров. А клиенты с свою очередь обязаны при входе в сеть обратиться к этому контроллеру. Теперь необходимо понять как клиент узнает IP-адрес контроллера что бы передать ему данные, введенные пользователем. Ведь ни имя, ни тем более IP-адрес контроллера не задается на клиентах.

    Ответ скрывается в базовом правиле Active Directory, говорящем о том что Active Directory не функционирует без системы разрешения имен DNS. Когда вы только настраиваете первый контроллер, служба DNS в вашей сети уже должна быть поднята. Если вдруг мастер установки Active Directory не обнаружит работающей службы DNS, она будет установлена на этот  же сервер вместе со службой AD и должным образом сконфигурирована. В  DNS будет автоматически создана зона (точнее две но пока это не важно) с именем вашего домена и в этой зоне появятся записи специального типа SRV, которые будут указывать на ваш контроллер. Следовательно клиент который работает в этом домене должен быть настроен на использование этого dns-сервера в качестве предпочитаемого. И  перед обращением к контроллеру домена, клиент осуществит запрос к DNS-серверу с просьбой сообщить ему SRV-запись для домена в котором он работает. Таким образом он в результате получит IP-адрес нужного контроллера и сможет переслать данные.

    Важно: На практике все контроллеры домена по совместительству несут на себе службу DNS. И причин разделять на разных серверах  DNS и контроллеры домена внутри вашей сети нет. (единственный случай где имеет смысл разделение это вынос DNS сервера за пределы вашей сети в демилитаризованную зону)

    srv

    Рис.1 Схема порядка входа клиента в сеть. Вначале обращение к DNS. В дальнейшем получив от DNS  IP-адрес контроллера, обращение к контроллеру. В жизни это как правило один сервер. (DC+DNS)

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

    Все просто. Необходимо установить еще один контроллер в рамках уже созданного домена Active Directory. Поднимая второй контроллер, вы создаете брата близнеца, который также как и первый будет хранить заветный файл ntds.dit  и также как и первый контроллер отвечать на запросы клиентов. Вашим клиентам будет абсолютно все равно какой из контроллеров их обслужил. Второй контроллер как и первый должен  иметь службу DNS иначе толку от него в случае падения первого будет очень мало. (я думаю понятно почему – AD не работает без DNS, а если мы имеем два контроллера и только на одном служба DNS, то что будет делать второй если первого не станет).

    Когда вы создаете пользователя в Active Directory, он создается в базе (ntds.dit) того контроллера, к которому в данный момент подключена оснастка.  А если контроллеров несколько  возникает ситуация в которой один контроллер знает об изменениях, а второй еще нет. Естественно такое безобразие долго длиться не должно и данные изменения обязаны быть доставлены на остающийся “незнающим” контроллер. Процесс синхронизации баз контроллеров в домене называется репликацией, которая происходит в фоном режиме без оповещения системного администратора.

    С выходом Windows Server 2008 появилась новая технология “Read Only Domain Controller” или контроллер домена только для чтения.  Особенность данного контроллера в том, что он работает только на чтение, т.е может обсуживать ваших клиентов, но записать в его базу AD вам ничего не удастся. Репликация в таком случае идет в одну сторону с полноценного контроллера на контроллер домена только для чтения. Используется он в ситуациях когда необходимо установить сервер в месте не обеспечивающего физическую безопасность.

    И так два контроллера будут прекрасно сосуществовать в рамках вашей сети и все будет здорово до одного момента. Когда к вам придет шэф и скажет: “Понимаешь %SysadminName%, мы слегка
    подросли и покупаем/арендуем новый офис в другом конце города. Часть компьютеров и самое главное Марью Ивановну из бухгалтерии мы перевозим в новое здание.” Ничего сложного отвечаете вы, достаете из тумбочки запылившиеся Cisco, в течении следующей недели неспешно настраиваете VPN-туннель между офисами  и перевозите на новый участок часть компьютеров, Марью Ивановну и конечно же один из контроллеров домена. В результате получаете следующую схему сети.

    sites

    Рис.2 Схема сети нашей фирмы.  

    А получаете вы сеть разделенную на два сегмента, каждый сегмент находится в своей подсети, трафик между подсетями маршрутизируется и передается в зашифрованном виде по VPN-туннелю. И все замечательно домен Active Directory продолжает работать, но вы начинаете замечать, что вход пользователя на компьютер стал занимать несколько  больше времени, а судя по детализации провайдера у вас появился лишний расход трафика. Ничего таинственного в этом нет. Те кто внимательно читали первую часть не могли пропустить строчку “Клиенту неважно какой контроллер домена его обслуживает”. Получается что ваши клиенты аутентифицируются на том контроллере, чью запись SRV вернул первой DNS сервер и далеко не всегда будет тот контроллер домена, который находится ближе. Таким образом трафик между клиентом и контроллером будет проходить VPN-туннель основанный на медленном WAN канале вызывая задержки при входе в сеть и лишний трафик.

    Для того, чтобы все было по-взрослому необходимо сконфигурировать сайты  Active Directory. Сайт AD не имеет ничего общего с www.ya.ru и.т.д. Это логическое объединение  клиентов и контроллеров связанных высокоскоростным соединением.  Ваша сеть состоит из двух участков в каждой скорость не меньше ста мегабит, а вот эти участки связанны каналом в два мегабита или того меньше. Получается что у вас будет два сайта (каждый филиал это сайт). И сконфигурировав сайты Active Directory вы добьетесь того, что клиенты всегда в первую очередь буду обращаться к тому контроллеру который находится с ними в одном сайте и если уж он не доступен, то запрос будет послан на другой контроллер. Когда вы устанавливали первый контроллер домена сайт с именем “default first site name” был создан автоматически и если вы ручками не меняли настройки, Active Directory считает, что все дополнительные контроллеры и все клиенты работают в одном сайте.

    После конфигурирования сайтов контроллеры также изменят свое поведение, репликация изменений Active Directory будет основываться на расписании, поскольку теперь AD понимает, что она развернута в территориально распределенной сети, каналы соединяющие участи узки и  используются не только для синхронизации контроллеров.

    Предвидя вопросы  “Как клиент понимает, что он принадлежит к тому или иному сайту” отвечу, что конфигурируя сайт, вы явно задаете подсети которые входят в него. Т.е если вы создали сайт “Rostov-on-Don” и закрепили за ним подсеть “192.168.5.0/24”, все клиенты имеющие IP-адрес в данной подсети будут считать себя члена данного сайта.

    И в окончании второй части раскрою “секретную команду”, позволяющую посмотреть, какой контроллер аутентифицировал вашего клиента. Эта команда SET.

    set 

    Рис. 3 Результат вывода команды SET.

    Введя SET в командной строке, вы получите множество информации, но интересовать вас должен параметр “LOGONSERVER”. При входе в домен “LOGONSERVER” будет указывать на аутентифицировавший вас контроллер домена, а при локальном входе  вместо имени контроллера домена  естественно будет стоять имя вашего клиентского компьютера.

    До встреч в эфире.

    Илья Рудь.

    • Рубрика: Windows,Новое
    • Автор: Илья Рудь
    • Дата: Wednesday 24 Jun 2009

Комментарии

  1. Спасибо, очень познавательно. Жду продолжение Ваших докладов.

  2. Илья, а как же волшебная галочка “global catalog” ?

    Имхо:

    Стоит расписать пример с несколькими контролерами в одной подсети, мол “как так – в сетевом подключении стоит только один днс, а клиент “общается” с другим”

    Так же стоит упомянуть о минимальном времени репликации в сайтах и как с данным лимитом бороться.

    И как поведёт себя сервис DNS на RODC при падении WAN линка.

  3. cognize, ты меня конечно извени, но можно я сам буду решать, что и в каком порядке? 🙂 Я рад, что ты знаешь много страшных слов 🙂 Поверь я знаю не меньше и об Active Directory могу расказывать долго и “со смаком”. Ну просто данная серия дает читателю правильное вопсриятие концепции построения сетей на AD и если я буду в ней писать о GC, FSMO, сайтовой и межсайтовой репликации и все это на 3-х страницах текста, то превратится она в течнет, который уже создан и второй делать у меня в планах не стоит.
    Без обид.
    P.S В любой статье я подумаю информацию так, как мне кажется ее легче усвоить.

  4. Мне просто подумалось, чем можно дополнить данный мануал (поэтому и написал – имхо) -)

    О том, что Вам известно – знаю.

    С одной стороны материал = уровню 100, но в некоторых моментах “одной ногой” есть углубления.

    На то он и интернет – сносить мнения и критику.

    Пойду спать – на счёт комментариев всё понял -)

  5. Ну вот обиделся:) Это серия (в процессе написания) и именно уровня 100, задачей которой сделать так, чтобы человек прочитал и уровень 200 и 300 пошел как по маслу.

  6. Дабы не разводить флейма, данный комментарий можно потереть.

    Тут как у Горького из “детства” – “слушай, что говорят другие, но впитывай только необходимое”.

    Не обиделся, мне было интересно почитать – честно.

    Информация пригодится тем, кто будет готовиться к 70-294 и 70-640.

    Ценю чужой труд.

    Спокойной ночи 🙂

  7. Ну и отлично. Дальше будет интересней, я постараюсь. Спокойной ночи.
    P.S Коментарии никогда не тру.

  8. Здравствуйте Илья
    приятно читать Ваш труд. Труд большой и хотелось, как-то повлиять, косвенно конечно, Вы пишите, что буду писать так как считаю нужным и только самое основное. Может есть возможность по некоторым материалам отсылать в сеть ( делать ссылку) на более развернутую информацию. И опять надо, как думаю знать меру не отсылать читателя на англ докум., а на то место где вам понравилось, как сказано/написано жел. на русском. Спасибо большое.

  9. Ок, я учту и буду сноски со ссылками делать для тех кому нужно больше.

  10. на самом деле статья действительно очень интересна. Читателям же хотелось бы посоветовать. Если бы вы хотели написать иначе – садитесь и пишите. Я буду только рад что у нас появятся новые авторы.
    А то, вот здесь не так, здесь не эдак. Думаю что мне (уверен что и Илье тоже) было бы просто обидно. Считает что автор не прав – напишите свое. А так, просто сидеть и высказывать свое “фе”. Так проще.
    PS
    Илья, не обижайся. Я знаю что такое писать. Знаю что всем не угодишь. Пиши так как считаешь нужным. У тебя получается! Думаю что через некоторое время я сам буду рекомендовать тебя к статусу MVP. (Просто как обладатель статуса – имею право :))

  11. Чтобы не было недопониманий я еще раз свою позицию озвучу:
    1. Я за коментарии обеими руками. Когда нет коментариев желание писать отпадает моментально. Чувствуешь, что пишешь в стол.
    2. Я всегда говорю спасибо когда меня ловят на ошибке.
    3. Я не против когда говорят “а вот так бы было круче”, но когда идет серия судить о том что попало в содержание, а что нет нельзя пока не появится последняя часть.У каждого своя цепочка подачи информации.

  12. Хотел высказать своё наблюдение еще после первой части, но прочитав 3ий пункт в 11 комментарии понял, что нужно с ним повременить ;). Прежний коммент случайно отправил.

  13. Мы сделаем так: когда я напишу все что считаю нужным, вы в последней части скажете чего не хватает. И я выпущу add-on по замечаниям.

  14. Удобнее посмотреть, на какой сервер вы выполнили вход, с помощью команды
    “echo %logonserver%”.

  15. Крутая команда, спасибо

  16. В комментариях писалось про какие-то уровни, расскажите что это за уровни?
    “Информация пригодится тем, кто будет готовиться к 70-294 и 70-640”
    “С одной стороны материал = уровню 100”
    Или ссылку киньте, где можно почитать?

  17. Александр у технических докладов бывают уровни 100..200..300..400

    100 – это введение в технологию, а 400 доклад для тех кто с технологией по 5-6 лет уже отработал, т.е хардкор. 200 и 300 это промежуточные, но считается что 300 это офигенный технический доклад.

  18. c 2009 этот сборник статей какой-нибудь pdf формат обрел?
    Хотелось бы прочитать целиком