37. Понятие bindery, NDS, eDirectory. Виды объектов. Имена. В второй-третьей версии Netware вся инфа о сетевых объектах хранилась в отдельных базах данных (bindery), которая имела плоскую структуру. Все объекты существовали на одном уровне. Подобная собственная база была у каждого сервера. Причем отдельные серверы не могли обмениваться инфой, В частности о пользователях.

В 98 году, Novell первой в мире создала сетевую службу каталогов NDS - novell directory service. В службе каталогов длина имен не более 64 символов, полное - не более 256. Имеется несколько классов контейнерных объектов:

1. country - страна. Используется редко, располагается непосредственно под корневым объектом. (C=Ru)

2. locality - местоположение или регион. Используется так же редко (L=RB)

3. Organization - организация. Используется всегда. Располагается под 1) и 2). (O=...)

4. Organization unit - подразделение. Располагается под 3). Может быть несолько подуровней. (O=USATU, OU=vtizi)

5. Замыкающий объект, в независимости от их типа CN=Popkov (common name).

Контекстовый объект - его положение в дереве. Применяется несколько видов имен:

1. Полное характерное имя. Начинается с точкии состоит из имени объекта и списка имен всех вышестоящих контейнерных объектов вплоть до корня. Отдельные имена выделяются точкой.

.Popkov.Students.ZI.vtizi.FIRT.USATU

2. Полнотипное имя - включает аббревиатуры типов объекта

CN=Popkov, OU=Students, OU=ZI...

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

Само по себе имя объекта без прилагающихся к нему имен контейнерных объектов, как и в случае AD называется относительным характерным именем. (RDP, либо CN=Popkov)

В рамках одного контейнера все имена объектов должны быть уникальны.

В начале 21 века novell изменила название своей службы каталогов на eDirectory, дела ее пошли хуже, для этого они и переименовали, подчеркивая что будут использовать кроссплатформенность.

38. Репликация в Active Directory.

Чтобы на всех контроллерах домена хранились идентичные последние версии данных каталогов, осуществляется регулярная репликация или тиражирование внесенных изменений на другие контроллеры. Репликация осуществляется автоматически, незаметно для пользователя. Содержимое копий каталога, хранимое на каждом контроллере домена можно разделить на три категории:

1. Данные обо всех объектах домена. Реплицируются в пределах соответствующих доменов.

2. Данные о схеме АД. Схема является общей для всех доменов леса и поэтому данные о ней реплицируются между всеми доменами.

3. Данные конфигурации. Отражает топологию репликаций между контроллерами доменов. Данная информация реплицируется между всеми доменами леса.

Если БД на втором контроллере обновилась до того как обновление на первом было реплицировано на все контроллеры системы, то возникает конфликт репликации. Для распознавания тиражирования изменений внутри узла используется 64битные порядковые номера изменений (USM или ASN), хранящиеся на каждом сервере АД. Они отсчитываются на каждом контроллере домена независимо от других контроллеров. Когда сервер вносит изменения в АД, этот номер увеличивается на единицу и сохраняется вместе с внесенными изменениями. Самые большие УСН у первого контроллера, созданного в лесу, так как он был установлен ранее других и на нем произошло больше изменений объекктов. Каждый сервер АД поддерживает таблицу ЮСМ номеров, полученных от других серверов в результате репликации. При необходимости репликации или в случае сбоя, сервер запрашивает все изменения, превышающие эти номера. Для каждого измененного атрибута объекта сохраняется его локальный номер ЮСМ. Если данные одного и того же объекта изменились на нескольких контроллерах доменов, то обновление идет следующим образом, позволяющим сделать выбор переговоров:

1) Анализируется номер версии. У каждого свойства есть свой номер версии. Выбирается изменение с большим номером версии. Если номера одинаковы, а содержимое свойств или БД разное, то это признак конфликта репликации и необходимо проанализировать след. фактор - временная ветка - создается вместе с номеров версии при модификации свойства объекта. Предполагает что все контроллеры домена синхронизированы по времени. Предпочтение отдается версии, созданной позднее. Анализируется размер буфера или свойства. Предпочтение отдается свойствам, которые занимают больший объем. Если и размер одинаков, то отказаться от обоих изменений.

Два вида репликаций - внутриузловая и межузловая.

При первой, при изменении в каталоге какого либо объекта система ожидает некоторое время для завершения последовательности изменений и посылает сообщение об изменении партнеру по репликации. Даже если в течении некоторого времени не было изменений, то все равно через определенное времч инициируется процесс репликации. В случае критичных обновлений каталогов - мер блокировки, удаления учетки, изменений пароля, репликация выполняется незамедлительно - срочная репликация.

Репликация между узлами происходит по четко назначенному расписанию. Это позволет перенести процесс репликации на нерабочее время, когда загрузка линии минимальна, но так сложнее обеспечить целостность данных. Для осуществления репликации между серверами разных узлов, между ними нужно установить связи или соединения.

Каждое соединение узлов - объект АД и имеет следующие атрибуты:

1. Названия узлов связи

2. Стоимость соединения.

3. Расписание доступности.

4. Частота репликации.

Несколько соединений узлов могут образовывать соединительный мост между.

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