Использование Azure Front Door в мультитенантном решении

  • Статья

Azure Front Door — это современная сеть доставки содержимого облака (CDN), которая обеспечивает быстрый, надежный доступ между пользователями и приложениями статического и динамического веб-содержимого по всему миру. В этой статье описываются некоторые функции Azure Front Door, которые полезны при работе в мультитенантных системах. Он также содержит ссылки на дополнительные рекомендации и примеры.

При использовании Azure Front Door в составе мультитенантного решения необходимо принять некоторые решения на основе дизайна и требований вашего решения. Необходимо учитывать следующие факторы:

  • Сколько клиентов у вас есть, и сколько вы ожидаете в будущем?
  • Совместное использование уровня приложений между несколькими клиентами, развертывание нескольких экземпляров приложений с одним клиентом или развертывание отдельных меток развертывания, совместно используемых несколькими клиентами?
  • Хотите ли ваши клиенты принести собственные доменные имена?
  • Будут ли использоваться домены подстановочных знаков?
  • Вам нужно использовать собственные сертификаты TLS или управлять сертификатами TLS майкрософт?
  • Вы рассмотрели квоты и ограничения , которые применяются к Azure Front Door? Знаете ли вы, какие ограничения вы будете приближаться по мере роста? Если вы подозреваете, что вы подойдите к этим ограничениям, рассмотрите возможность использования нескольких профилей Azure Front Door. Или рассмотрите возможность изменения способа использования Azure Front Door, чтобы избежать ограничений. Обратите внимание, что номер SKU уровня "Премиум" имеет более высокие ограничения, чем номер SKU уровня "Стандартный".
  • У вас или клиентов есть требования к фильтрации IP-адресов, геоблокировки или настройке правил WAF?
  • Доступны ли все серверы приложений клиентов в Интернете?

Функции Azure Front Door, поддерживающие мультитенантность

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

Личные домены

Azure Front Door предоставляет имя узла по умолчанию для каждой создаваемой конечной точки, например contoso.z01.azurefd.net. Для большинства решений вместо этого необходимо связать собственное доменное имя с конечной точкой Azure Front Door. Пользовательские доменные имена позволяют использовать собственную фирменную символику и настраивать маршрутизацию на основе имени узла, указанного в запросе клиента.

В мультитенантном решении можно использовать доменные имена или поддомены для конкретного клиента и настроить Azure Front Door для маршрутизации трафика клиента в правильную группу источников для рабочей нагрузки этого клиента. Например, можно настроить имя личного домена, например tenant1.app.contoso.com. С помощью Azure Front Door можно настроить несколько пользовательских доменов в одном профиле Azure Front Door.

Дополнительные сведения см. в руководстве Добавление личного домена в Front Door.

Домены с подстановочными знаками

Домены подстановочных знаков упрощают настройку записей DNS и конфигурацию маршрутизации трафика Azure Front Door при использовании общего домена и поддомена для конкретного клиента. Например, предположим, что клиенты получают доступ к своим приложениям с помощью поддоменов, таких как tenant1.app.contoso.com и tenant2.app.contoso.com. Вы можете настроить домен подстановочных знаков, *.app.contoso.comа не настраивать каждый домен для конкретного клиента по отдельности.

Azure Front Door поддерживает создание пользовательских доменов, использующих подстановочные знаки. Затем можно настроить маршрут для запросов, поступающих в домен подстановочных знаков. При подключении нового клиента вам не нужно перенастраивать DNS-серверы, выдавать новые сертификаты TLS или обновлять конфигурацию профиля Azure Front Door.

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

Azure Front Door не выдает управляемые сертификаты TLS для доменов подстановочных знаков, поэтому необходимо приобрести и предоставить собственный сертификат.

Дополнительные сведения см. в разделе "Домены подстановочных знаков".

Управляемые сертификаты TLS

Получение и установка сертификатов TLS может быть сложной и подверженной ошибкам. И срок действия сертификатов TLS истекает через период времени, как правило, один год, и его необходимо переустановить и переустановить, чтобы избежать нарушений трафика приложения. При использовании управляемых сертификатов TLS Azure Front Door корпорация Майкрософт отвечает за выдачу, установку и продление сертификатов для личного домена.

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

Если вы разрешаете клиентам предоставлять собственные пользовательские домены и хотите, чтобы Azure Front Door выдавал сертификаты для этих доменных имен, ваши клиенты не должны настраивать записи CAA на своих DNS-серверах, которые могут блокировать выдачу сертификатов от имени Azure Front Door. Дополнительные сведения см. в разделе TLS/SSL-сертификатов.

Дополнительные сведения о сертификатах TLS см. в статье "Сквозное подключение TLS" с Azure Front Door.

Маршрутизация

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

Azure Front Door имеет мощный набор возможностей маршрутизации, которые могут поддерживать ряд мультитенантных архитектур. Вы можете использовать маршрутизацию для распределения трафика между источниками в метке или отправки трафика на правильную метку для конкретного клиента. Вы можете настроить маршрутизацию на основе отдельных доменных имен, доменных имен подстановочных знаков и ПУТЕЙ URL-адресов. И вы можете использовать обработчик правил для дальнейшей настройки поведения маршрутизации.

Дополнительные сведения см. в разделе Общие сведения об архитектуре маршрутизации.

Обработчик правил

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

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

Ниже приведены некоторые примеры подходов к использованию обработчика правил Azure Front Door в мультитенантном решении:

  • Предположим, что вы развертываете многотенантный уровень приложений, в котором также используются поддомены поддоменов для конкретных клиентов, как описано в следующих примерах сценариев. Можно использовать обработчик правил для извлечения идентификатора клиента из поддомена запроса и добавления его в заголовок запроса. Это правило может помочь уровню приложений определить, из какого клиента поступил запрос.
  • Предположим, что вы развертываете многотенантный уровень приложений и используете маршрутизацию на основе путей (например, https://application.contoso.com/tenant1/welcome https://application.contoso.com/tenant2/welcome для клиентов 1 и 2 соответственно). Можно использовать обработчик правил для извлечения сегмента идентификатора клиента из сегмента ПУТИ URL-адреса и перезаписать URL-адрес, чтобы включить идентификатор клиента в параметр строки запроса или заголовок запроса для используемого приложения.

Дополнительные сведения см. в разделе "Что такое обработчик правил Azure Front Door?".

Пример сценариев

В следующих примерах сценариев показано, как настроить различные мультитенантные архитектуры в Azure Front Door и как решения, которые вы принимаете, могут повлиять на конфигурацию DNS и TLS.

Многие мультитенантные решения реализуют шаблон меток развертывания. При использовании этого подхода развертывания обычно развертывается один общий профиль Azure Front Door и используется Azure Front Door для маршрутизации входящего трафика на соответствующую метку. Эта модель развертывания является наиболее распространенной, и в сценариях 1–4 в этой статье показано, как использовать ее для удовлетворения ряда требований.

Однако в некоторых ситуациях можно развернуть профиль Azure Front Door в каждой метке решения. Сценарий 5 описывает эту модель развертывания.

Сценарий 1. Домен подстановочных знаков, управляемый поставщиком, одна метка

Компания Contoso создает небольшое мультитенантное решение. Компания развертывает одну метку в одном регионе, и эта метка обслуживает всех своих клиентов. Все запросы направляются на один сервер приложений. Компания Contoso решила использовать домены подстановочных знаков для всех клиентов, например tenant1.contoso.com и tenant2.contoso.com.

Компания Contoso развертывает Azure Front Door с помощью этой конфигурации:

Схема, показывающая конфигурацию Azure Front Door с одним пользовательским доменом, маршрутом и группой источников и сертификатом TLS с подстановочными знаками в Azure Key Vault.

DNS configuration (Настройка DNS)

Одноразовая конфигурация: Contoso настраивает две записи DNS:

  • Подстановочный знак TXT для *.contoso.com. Для него задано значение, указанное Azure Front Door во время процесса подключения личного домена.
  • Подстановочный знак CNAME— *.contoso.comэто псевдоним конечной точки Azure Front Door компании Contoso: contoso.z01.azurefd.net

При подключении нового клиента: дополнительная конфигурация не требуется.

Конфигурация протокола TLS

Однократная конфигурация: Компания Contoso покупает сертификат TLS с подстановочными знаками, добавляет его в хранилище ключей и предоставляет Azure Front Door доступ к хранилищу.

При подключении нового клиента: дополнительная конфигурация не требуется.

Конфигурация Azure Front Door

Однократная конфигурация: Contoso создает профиль Azure Front Door и одну конечную точку. Они добавляют один личный домен с именем *.contoso.com и связывают сертификат TLS с ресурсом личного домена. Затем они настраивают одну группу источников, содержащую один источник для сервера приложений. Наконец, они настраивают маршрут для подключения личного домена к группе источников.

При подключении нового клиента: дополнительная конфигурация не требуется.

Льготы

  • Эта конфигурация является относительно простой для настройки и предоставляет клиентам url-адреса с фирменной символикой Contoso.
  • Этот подход поддерживает большое количество клиентов.
  • При подключении нового клиента Contoso не требуется вносить изменения в сертификаты Azure Front Door, DNS или TLS.

Недостатки

  • Этот подход не может легко масштабироваться за пределами одной метки или региона приложения.
  • Компания Contoso должна приобрести сертификат TLS с подстановочными знаками и обновить и установить сертификат после истечения срока его действия.

Сценарий 2. Домен подстановочных знаков, управляемый поставщиком, несколько меток

Proseware создает мультитенантное решение для нескольких меток, развернутых как в Австралии, так и в Европе. Все запросы в одном регионе обслуживаются меткой в этом регионе. Как и Contoso, Proseware решил использовать домены подстановочных знаков для всех клиентов, например tenant1.proseware.com и tenant2.proseware.com.

Proseware развертывает Azure Front Door с помощью этой конфигурации:

На схеме показана конфигурация Azure Front Door с несколькими пользовательскими доменами, маршрутами и группами источников и сертификатом TLS с подстановочными знаками в Key Vault.

DNS configuration (Настройка DNS)

Одноразовая конфигурация: Proseware настраивает две записи DNS:

  • Подстановочный знак TXT для *.proseware.com. Для него задано значение, указанное Azure Front Door во время процесса подключения личного домена.
  • Подстановочный знак CNAME— *.proseware.comэто псевдоним конечной точки Azure Front Door в Proseware: proseware.z01.azurefd.net

При подключении нового клиента: дополнительная конфигурация не требуется.

Конфигурация протокола TLS

Однократная конфигурация: Proseware покупает сертификат TLS с подстановочными знаками, добавляет его в хранилище ключей и предоставляет Azure Front Door доступ к хранилищу.

При подключении нового клиента: дополнительная конфигурация не требуется.

Конфигурация Azure Front Door

Однократная конфигурация: Proseware создает профиль Azure Front Door и одну конечную точку. Компания настраивает несколько групп источников, по одному на метку приложения или сервер в каждом регионе.

При подключении нового клиента: Proseware добавляет ресурс личного домена в Azure Front Door. Они используют имя *.proseware.com и связывают сертификат TLS с ресурсом личного домена. Затем они создают маршрут, чтобы указать, в какую группу происхождения (метку) должны направляться запросы клиента. На предыдущей схеме маршруты tenant1.proseware.com в группу происхождения в регионе Австралии и tenant2.proseware.com маршруты в группу происхождения в регионе Европы.

Льготы

  • При подключении новых клиентов изменения конфигурации DNS или TLS не требуются.
  • Proseware поддерживает один экземпляр Azure Front Door для маршрутизации трафика на несколько меток в нескольких регионах.

Недостатки

  • Proseware необходимо перенастроить Azure Front Door при каждом подключении нового клиента.
  • Proseware необходимо обратить внимание на квоты и ограничения Azure Front Door, особенно на количество маршрутов и пользовательских доменов, а также составное ограничение маршрутизации.
  • Proseware необходимо приобрести сертификат TLS с подстановочным знаком.
  • Proseware отвечает за продление и установку сертификата после истечения срока его действия.

Сценарий 3. Поддомены поддомена на основе меток, управляемые поставщиком

Fabrikam создает мультитенантное решение. Компания развертывает марки в Австралии и США. Все запросы в одном регионе будут обслуживаться меткой в этом регионе. Fabrikam будет использовать домены на основе меток, например tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.comи tenant3.us.fabrikam.com.

Компания развертывает Azure Front Door с помощью этой конфигурации:

На схеме показана конфигурация Azure Front Door с несколькими настраиваемыми доменами стволовых объектов на основе меток, маршрутами, группами источников и сертификатом TLS с подстановочными знаками в Key Vault.

DNS configuration (Настройка DNS)

Одноразовая конфигурация: Fabrikam настраивает следующие две подстановочные записи DNS для каждой метки.

  • Подстановочный знак TXT для каждой метки: *.australia.fabrikam.com и *.us.fabrikam.com. Они задаются значениями, указанными Azure Front Door во время процесса подключения личного домена.
  • Подстановочные знаки CNAME для каждой метки и *.australia.fabrikam.com *.us.fabrikam.comоба псевдонима для конечной точки Azure Front Door: fabrikam.z01.azurefd.net

При подключении нового клиента: дополнительная конфигурация не требуется.

Конфигурация протокола TLS

Однократная конфигурация: Fabrikam покупает сертификат TLS с подстановочным знаком для каждой метки, добавляет их в хранилище ключей и предоставляет Azure Front Door доступ к хранилищу.

При подключении нового клиента: дополнительная конфигурация не требуется.

Конфигурация Azure Front Door

Однократная конфигурация: Fabrikam создает профиль Azure Front Door и одну конечную точку. Они настраивают группу источников для каждой метки. Они создают пользовательские домены, используя поддомен *.australia.fabrikam.com на основе меток: и *.us.fabrikam.com. Они создают маршрут для личного домена каждой метки для отправки трафика в соответствующую группу источников.

При подключении нового клиента: дополнительная конфигурация не требуется.

Льготы

  • Такой подход позволяет Fabrikam масштабироваться до большого количества клиентов по нескольким меткам.
  • При подключении новых клиентов изменения конфигурации DNS или TLS не требуются.
  • Fabrikam поддерживает один экземпляр Azure Front Door для маршрутизации трафика на несколько меток в нескольких регионах.

Недостатки

  • Так как URL-адреса используют структуру домена с несколькими частями, URL-адреса могут быть более сложными для работы с пользователями.
  • Fabrikam необходимо приобрести несколько подстановочных сертификатов TLS.
  • Fabrikam отвечает за продление и установку сертификатов TLS при истечении срока их действия.

Сценарий 4. Домены vanity

Adventure Works Cycles создает мультитенантное решение. Компания развертывает марки в нескольких регионах, таких как Австралия и США. Все запросы в одном регионе будут обслуживаться меткой в этом регионе. Adventure Works позволит своим клиентам принести собственные доменные имена. Например, клиент 1 может настроить имя личного домена, например tenant1app.tenant1.com.

Компания развертывает Azure Front Door с помощью этой конфигурации:

На схеме показана конфигурация Azure Front Door с несколькими настраиваемыми доменами, маршрутами и группами источников, а также сочетание сертификатов TLS в Key Vault и TLS-сертификатах, управляемых Azure Front Door.

DNS configuration (Настройка DNS)

Однократная конфигурация: нет.

При подключении нового клиента: клиент должен создать две записи на собственном DNS-сервере:

  • Запись TXT для проверки домена. Например, клиент 1 должен настроить запись TXT с именем tenant1app.tenant1.com и задать для него значение, указанное Azure Front Door во время процесса подключения личного домена.
  • Запись CNAME, которая является псевдонимом конечной точки Azure Front Door Adventure Works. Например, клиент 1 должен настроить запись CNAME с именем tenant1app.tenant1.com и сопоставить ее adventureworks.z01.azurefd.netс .

Конфигурация протокола TLS

Adventure Works и его клиенты должны решить, кто выдает сертификаты TLS:

  • Самый простой вариант — использовать Azure Front Door для выдачи сертификатов и управления ими, но клиенты не должны настраивать записи CCA на своих DNS-серверах. Если они делают, записи могут предотвратить выдачу сертификатов центром сертификации Azure Front Door.
  • Кроме того, клиенты могут предоставлять собственные сертификаты. Они должны работать с Adventure Works для отправки сертификата в хранилище ключей и предоставления доступа к Azure Front Door.

Конфигурация Azure Front Door

Однократная конфигурация: Adventure Works создает профиль Azure Front Door и одну конечную точку. Они настраивают группу источников для каждой метки. Они не создают ресурсы личного домена или маршруты.

При подключении нового клиента: Adventure Works добавляет ресурс личного домена в Azure Front Door. Они используют доменное имя клиента и связывают соответствующий сертификат TLS с ресурсом личного домена. Затем они создают маршрут, чтобы указать, в какую группу происхождения (метку) должны направляться запросы клиента. На предыдущей схеме tenant1app.tenant1.com направляется в группу источников в регионе Австралии и tenant2app.tenant3.com направляется в группу источников в регионе США.

Льготы

  • Клиенты могут предоставлять собственные доменные имена. Azure Front Door прозрачно направляет запросы в мультитенантное решение.
  • Adventure Works поддерживает один экземпляр Azure Front Door для маршрутизации трафика на несколько меток в нескольких регионах.

Недостатки

  • Adventure Works необходимо перенастроить Azure Front Door при каждом подключении нового клиента.
  • Арендаторы должны участвовать в процессе подключения. Они должны вносить изменения DNS и, возможно, выдавать сертификаты TLS.
  • Клиенты управляют записями DNS. Изменения записей DNS могут повлиять на их возможность доступа к решению Adventure Works.
  • Adventure Works необходимо обратить внимание на квоты и ограничения Azure Front Door, особенно на количество маршрутов и пользовательских доменов, а также составной предел маршрутизации.

Сценарий 5. Профиль Azure Front Door на метку

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

Совет

Azure Front Door — это глобальный ресурс. Даже если вы развертываете метки с региональной областью, каждый профиль Azure Front Door глобально распространяется. Следует учитывать, действительно ли вам нужно развертывать несколько профилей Azure Front Door и какие преимущества вы получаете за счет этого.

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

Льготы

  • Если вы расширяете конфигурацию в нескольких профилях, скорее всего, вы достигнете ограничений ресурсов Azure Front Door. Например, если вам нужно поддерживать большое количество пользовательских доменов, можно разделить домены между несколькими профилями Azure Front Door и оставаться в пределах каждого профиля.
  • Этот подход позволяет ограничить разрешения управления ресурсами Azure Front Door. Вы можете использовать управление доступом на основе ролей Azure (RBAC) для предоставления администраторам доступа к профилю одной метки.

Недостатки

  • Этот подход обычно вызывает высокую стоимость, так как развертывается больше профилей. Дополнительные сведения см. в разделе "Общие сведения о выставлении счетов Front Door".
  • Существует ограничение на количество профилей Azure Front Door, которые можно развернуть в одной подписке Azure. Дополнительные сведения см. в статье о квотах и ограничениях Front Door.
  • Необходимо настроить профиль Azure Front Door для каждой метки отдельно, а также управлять конфигурацией DNS, сертификатами TLS и конфигурацией TLS для каждой метки.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

Другие участники:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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