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

Отклонение версий

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

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

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

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

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

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

Примечание

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

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

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

Collisions

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

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

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

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

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

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