Влияние на приложения с поддержкой каталогов

  • Статья

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

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

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

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

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

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

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

Примечание.

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

 

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

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

Столкновений

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

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

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

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

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

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