Что такое архитектура Azure Active Directory?

Azure Active Directory (Azure AD) позволяет безопасно управлять доступом к службам и ресурсам Azure пользователей, а также содержит полный набор возможностей управления удостоверениями. Дополнительные сведения о возможностях Azure AD см. в статье Что такое Microsoft Azure Active Directory.

Благодаря Azure AD вы можете создавать пользователей и группы и управлять ими, разрешая и запрещая доступ к корпоративным ресурсам на основе разрешений. Дополнительные сведения об управлении удостоверениями см. в этой статье.

Архитектура Azure AD

Географически распределенная архитектура Azure AD сочетает в себе расширенные возможности мониторинга, автоматического перенаправления, отработки отказа и восстановления, которые предоставляют клиентам доступность и производительность корпоративного класса.

В этой статье рассматриваются следующие элементы архитектуры:

  • Схема архитектуры службы
  • Масштабируемость
  • Постоянная доступность
  • Центры обработки данных

Схема архитектуры службы

Наиболее распространенный способ создания доступной и удобной в использовании системы с большим количеством данных заключается в использовании независимых стандартных блоков или единиц масштабирования на уровне данных Azure AD. Эти единицы масштабирования называются разделами.

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

Схема раздела единого каталога

К компонентам архитектуры Azure AD относятся первичная реплика и вторичные реплики.

Первичная реплика

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

Вторичные реплики

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

Масштабируемость

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

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

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

Постоянная доступность

Доступность (или время непрерывной работы) определяет возможность системы работать без перебоя. Высокий уровень доступности Azure Active Directory обеспечивается возможностью служб быстро распределять трафик между несколькими географически распределенными центрами обработки данных. Каждый центр обработки данных является независимым, поэтому режимы сбоя практически не требуют корреляции. Благодаря архитектуре, обеспечивающей высокий уровень доступности, Azure Active Directory не прекращает работу во время обслуживания.

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

Отказоустойчивость

Чтобы обеспечить более высокую доступность системы, необходимо реализовать ее устойчивость к сбоям оборудования, сети и программного обеспечения. Для каждого раздела в каталоге назначена основная реплика с высоким уровнем доступности — первичная реплика. Эта реплика обрабатывает только операции записи на определенный раздел. Она постоянно находится под тщательным контролем, а в случае обнаружения сбоя операции записи немедленно перенаправляются на другую реплику (которая становится новой первичной репликой). Во время отработки отказа доступность для записи может быть потеряна на 1–2 минуты. Эта операция не влияет на доступность для чтения.

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

Устойчивость данных

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

Azure AD поддерживает нулевое значение цели времени восстановления (RTO), что позволяет не терять данные во время отработок отказа. В том числе:

  • выдача токенов и чтение каталога;
  • RTO для операций записи в каталог на уровне 5 минут.

Центры обработки данных

Реплики Azure AD хранятся в центрах обработки данных, расположенных по всему миру. Дополнительные сведения см. в разделе Глобальная инфраструктура Azure.

Azure Active Directory работает в центрах обработки данных со следующими характеристиками.

  • Службы проверки подлинности, Graph и другие службы AD находятся за службой шлюза. Шлюз управляет балансировкой нагрузки этих служб. При обнаружении неработоспособных серверов с использованием транзакционных проб работоспособности он автоматически выполняет отработку отказа. На основе проб работоспособности шлюз динамически направляет трафик в рабочие центры обработки данных.
  • Для операций чтения каталог имеет вторичные реплики и соответствующие интерфейсные службы с конфигурацией "активный — активный", работающие в нескольких центрах обработки данных. Если обработка в центре обработки данных завершается сбоем, трафик автоматически направляется в другой центр обработки данных.
  • Для операций записи каталог выполняет отработку отказа первичной реплики между несколькими центрами обработки данных в рамках планового (новая первичная реплика синхронизируется со старой) или экстренного процесса отработки отказа. Устойчивость данных достигается путем репликации всех фиксаций по крайней мере в два центра обработки данных.

Согласованность данных

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

Azure AD обеспечивает согласованность операций чтения и записи для приложений, использующих вторичную реплику, направляя их операции записи на первичную реплику и синхронно возвращая эти операции на вторичную реплику.

Операции записи приложений, выполняемые с помощью API Graph службы Azure Active Directory, абстрагируются от сохранения сходства с репликой каталога для согласованности операций чтения и записи. Служба API Graph поддерживает логический сеанс, имеющий сходство с вторичной репликой, используемой для операций чтения. Сходство сохраняется в токене реплики, кэшируемом службой в центре обработки данных с вторичной репликой. Затем этот токен используется в последующих операциях в том же логическом сеансе. Чтобы продолжить использование логического сеанса, последующие запросы необходимо направлять в один центр обработки данных Azure Active Directory. Логический сеанс продолжить не удастся, если запросы клиентов каталога направлены в несколько центров обработки данных Azure Active Directory. В этом случае у клиента имеется несколько логических сеансов с независимым согласованием чтения и записи.

Примечание

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

Резервное копирование на уровне службы

Azure AD реализует ежедневное резервное копирование данных каталога и может использовать эти резервные копии для восстановления данных в случае любой проблемы на уровне службы.

Каталог также реализует обратимые удаления вместо жестких удалений для выбранных типов объектов. Администратор клиента может отменить все случайные удаления этих объектов в течение 30 дней. Дополнительные сведения см. в разделе API для восстановления удаленных объектов.

Метрики и мониторы

Для выполнения службы с высоким уровнем доступности требуются метрики и возможности мониторинга мирового уровня. Azure AD постоянно анализирует метрики работоспособности основных служб и предоставляет сведения о них, а также о критериях успешной работы каждой из этих служб. Кроме того, постоянно разрабатываются и настраиваются метрики, возможности мониторинга и создания оповещений для каждого сценария в каждой службе Azure AD и во всех остальных службах.

Если какая-либо служба Azure AD не работает должным образом, немедленно предпринимается действие по восстановлению ее работоспособности. Самая важная метрика, отслеживаемая Azure AD, — это скорость обнаружения и устранения проблем на рабочем сайте клиента. Мы вложили много ресурсов в возможности мониторинга и создания оповещений, чтобы минимизировать время на обнаружение (менее 5 минут) и устранение (менее 30 минут) проблемы.

Защита операций

Мы используем операционные элементы управления, такие как многофакторная проверка подлинности (MFA), для всех операций, а также ведем аудит всех операций. Кроме того, мы используем JIT-систему повышения прав, чтобы предоставлять необходимый временный доступ к любой рабочей задаче по запросу на постоянной основе. Дополнительные сведения см. на странице Надежное облако.

Дальнейшие действия

Руководство разработчика по Azure Active Directory