Влияние на приложения Directory-Enabled

Неравномерное распределение версий

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

Например, служба RPC может публиковать свои конечные точки в каталоге с помощью стандартных API RPC (например , RpcNsBindingExport). Клиенты подключаются к службе, просматривая нужную конечную точку в каталоге ( RpcNsBindingLookupBegin, RpcNsBindingLookupNext и т. д.) и привязывая к ней.

Предположим, что служба RPC S₁ публикует конечную точку Es₁ и затем переходит на другой компьютер. Исходная конечная точка Es₁ изменена на Es2, отражая адрес нового компьютера. Клиенты, считывающие удаленные реплики службы каталогов, не могут подключаться к службе, пока обновленная конечная точка не будет реплицирована. Однако перемещение службы с одного компьютера на другой является редким явлением; следовательно, это прерывание или задержка редко возникает, особенно если перемещение службы хорошо запланировано.

Частичные обновления

Как правило, частичное обновление происходит, когда одно приложение считывает набор данных, а другое приложение записывает в тот же набор данных. Это ситуация, которая может возникнуть с любым приложением в многопользовательской системе. Это может произойти несколькими способами. Вы можете одновременно записывать несколько приложений в один набор данных. Если взглянуть на это таким образом, служба репликации каталогов — это просто другое приложение, которое потенциально может записывать данные в тот же набор данных, который может считывать другое приложение. Это может быть потенциальной проблемой для приложения. Однако период времени, в течение которого частичное обновление может повлиять на приложение, является относительно небольшим. Это редко должно возникать, если когда-либо возникает проблема для приложений, которые не зависят от синхронизации нескольких объектов. Если приложение сильно зависит от синхронизации связанного набора объектов, следует учитывать последствия частичного обновления в структуре приложения.

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

Примечание

Окно, в котором частичное обновление может повлиять на приложение, невелико: приложение должно начать чтение объектов во время выполнения входящего репликации после получения одного или нескольких связанных объектов, но прежде чем все было получено. Время между обновлениями в исходной реплике напрямую влияет на размер этого окна— обновления, которые происходят близко друг к другу во времени, реплицируются вместе во времени. Частичное обновление может быть проблемой, если приложение использует связанный набор объектов.

 

Например, служба удаленного доступа может использовать каталог для хранения данных политики и профиля. Данные политики хранятся в одном наборе объектов и профиле в другом наборе. Когда пользователь подключается к службе удаленного доступа, служба удаленного доступа считывает политику, чтобы определить, разрешено ли подключаться пользователю, и если да, какой профиль следует применить к сеансу пользователя. Частичное обновление может повлиять на службу удаленного доступа несколькими способами:

  • Если политика сложна и состоит из нескольких объектов, служба удаленного доступа может считывать частично обновленную политику, что приводит к неправильному отказу или предоставлению службы пользователю, невозможности обработки политики из-за внутренней несогласованности и т. д.
  • Если политика и профили обновлены, служба может правильно обработать политику, но применить устаревший профиль, так как объекты политики реплицировались, но объекты профиля не имеют.
  • Если профиль является сложным и состоит из нескольких объектов, служба может правильно обработать политику, но применить частично обновленный профиль, так как объекты политики реплицировались, но только некоторые объекты профиля сделали это.

Collisions

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

Простой пример — это сведения об адресе пользователя: пользователь изменяет почтовый адрес на реплике R1, а администратор изменяет тот же адрес рассылки на реплике R2. Записанное значение распространяется до тех пор, пока другое значение не будет выбрано над этим значением механизмом выверки конфликтов. Пока значение продолжает "выигрывать" от других значений в процессе разрешения конфликтов, значение продолжает распространяться. В конечном счете, это "выигрышное" значение будет распространяться на R1,R2 и все остальные реплики, если другие изменения не вносятся.

Разрешение конфликтов — это проблема для приложений, которые делают предположения о внутренней согласованности объектов или наборов объектов. Например, служба управления распределением пропускной способности сети хранит данные пропускной способности сети для заданного сегмента сети в каталоге в объекте O1. Объект содержит пропускную способность, доступную в битах в секунду, и максимальную пропускную способность может зарезервировать любой пользователь. Служба ожидает, что резервируемая пользователем пропускная способность всегда будет меньше или равна доступной пропускной способности.

Рассмотрим следующую последовательность событий.

  • Объект в начальном полностью реплицированном состоянии предоставляет доступную пропускную способность как 56 килобит в секунду, а пользователь резервируемую пропускную способность — 9600 бит в секунду.
  • Администратор реплики R₁ изменяет значения на 64 кб и 19 200 соответственно.
  • Администратор реплики R₁ изменяет значения на 10 миллионов и 1 млн соответственно до поступления обновления из R₁.

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