Развертывание кластеров больших данных SQL Server в режиме AD в службах Azure Kubernetes (AKS)

  • Статья

Кластеры больших данных SQL Server поддерживают режим развертывания Active Directory (AD) для системы управления удостоверениями и доступом (IAM) . Управление удостоверениями и доступом для служб Azure Kubernetes (AKS) было сопряжено с определенными проблемами, поскольку SQL Server не поддерживает стандартные отраслевые протоколы, такие как OAuth 2.0 и OpenID Connect, которые широко используются на платформе управления удостоверениями Майкрософт.

В этой статье объясняется, как развернуть кластер больших данных SQL Server в режиме AD при развертывании в службах Azure Kubernetes (AKS).

Важно!

Поддержка надстройки "Кластеры больших данных" Microsoft SQL Server 2019 будет прекращена. Мы прекратим поддержку Кластеров больших данных SQL Server 2019 28 февраля 2025 г. Все существующие пользователи SQL Server 2019 с Software Assurance будут полностью поддерживаться на платформе, а программное обеспечение будет по-прежнему поддерживаться с помощью SQL Server накопительных обновлений до этого времени. Дополнительные сведения см. в записи блога объявлений и в статье о параметрах больших данных на платформе Microsoft SQL Server.

Топологии архитектуры

Доменные службы Active Directory (AD DS) работают на виртуальной машине Azure так же, как и на множестве других локальных экземпляров. После повышения уровня новых контроллеров домена в Azure и настройки основного и дополнительного DNS-сервера для виртуальной сети все локальные DNS-серверы будут понижены до третьего или более низкого уровня. С помощью проверки подлинности AD присоединенные к домену клиенты с Linux могут проходить проверку подлинности в SQL Server, используя свои учетные данные домена и протокол Kerberos.

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

  • Как расширить локальный домен Active Directory в Azure. Этот способ позволяет использовать среду Active Directory для предоставления распределенных служб проверки подлинности с помощью доменных служб Active Directory (AD DS) в Azure. Реплицируя локальные доменные службы Active Directory (AD DS), вы уменьшаете задержку, связанную с отправкой запросов на проверку подлинности из облака обратно в локальные службы AD DS. Как правило, это решение применяется в тех случаях, когда приложение размещается частично в локальной среде и частично в Azure, а запросы проверки подлинности передаются в обоих направлениях.

    Пошаговые инструкции по развертыванию этого решения см. в описании этой эталонной архитектуры.

  • Расширение леса ресурсов доменных служб Active Directory (AD DS) в Azure. В этой архитектуре создается новый домен в Azure, который является доверенным для локального леса AD. В этой архитектуре демонстрируется одностороннее отношение доверия между доменом в Azure и локальным лесом.

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

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

Типовая архитектура представлена на следующем рисунке:

Кластер AKS с AD и кластер больших данных SQL Server

Рекомендации

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

Рекомендации по сети

Для подключения локальной среды к Azure можно использовать несколько основных компонентов:

  • VPN-шлюз Azure. VPN-шлюз — это особый тип шлюза виртуальной сети, используемый для отправки зашифрованного трафика между виртуальной сетью Azure и локальным расположением через общедоступный Интернет. Вы будете использовать и шлюз виртуальной сети Azure, и локальный шлюз виртуальной сети. Сведения об их настройке см. в разделе Что такое VPN-шлюз.
  • Azure ExpressRoute. Подключения ExpressRoute не осуществляются через общедоступный Интернет и обеспечивают повышенный уровень безопасности, надежности и быстродействия с низким уровнем задержки по сравнению с обычными подключениями через Интернет. Выбор варианта подключения будет влиять на задержку, производительность и уровень соглашения об уровне обслуживания для вашего решения в зависимости от номеров SKU. Подробные сведения см. в статье Сведения о шлюзах виртуальных сетей ExpressRoute.

Большинство клиентов используют для доступа к другой инфраструктуре Azure переходную среду или Бастион Azure. Приватный канал Azure обеспечивает безопасный доступ к службам Azure PaaS, включая AKS в этом сценарии, а также к другим размещенным в Azure службам, через частную конечную точку в вашей виртуальной сети. Трафик между вашей виртуальной сетью и службой проходит через магистральную сеть Майкрософт, что позволяет избежать рисков общедоступного Интернета. Кроме того, вы можете создать в своей виртуальной сети собственную службу "Приватный канал" и предоставлять ее клиентам в частном порядке.

Рекомендации для Active Directory и Azure

Локальные службы AD DS хранят информацию об учетных записях пользователей и предоставляют другим авторизованным пользователям из этой сети доступ к этой информации с использованием прошедших проверку подлинности удостоверений, которые связаны с пользователями, компьютерами, приложениями или другими ресурсами, входящими в границы безопасности. В большинстве гибридных сценариев проверка подлинности пользователей происходит через VPN-шлюз или канал ExpressRoute, связанные с локальными службами AD DS.

Для развертывания кластера больших данных в режиме AD посредством интеграции локальных служб Active Directory с Azure должны выполняться следующие предварительные требования:

  • Учетная запись AD с определенными разрешениями на создание учетных записей компьютеров, пользователей и групп внутри указанного подразделения в локальном каталоге Active.
  • DNS-сервер для разрешения внутренних DNS-имен. Он должен содержать записи типа A (прямой просмотр) и PTR (обратный просмотр) на DNS-сервере с именами в этом домене. Настройка параметров DNS домена в профиле развертывания кластера больших данных.

Следующие шаги

Учебник. Развертывание кластеров больших данных SQL Server в режиме AD в службах Azure Kubernetes (AKS)