Использование 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.

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

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

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

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

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

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

Управляемые сертификаты 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. Обработчик правил можно использовать для переопределения конфигурации маршрутизации для запроса. Вы также можете использовать обработчик правил для изменения элементов запроса перед отправкой в источник, а также для изменения некоторых частей ответа перед возвратом клиенту.

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

Дополнительные сведения см. в разделе "Что такое обработчик правил 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 с помощью этой конфигурации:

Diagram that shows an Azure Front Door configuration that has a single custom domain, route, and origin group and a wildcard TLS certificate in 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 с помощью этой конфигурации:

Diagram that shows an Azure Front Door configuration that has multiple custom domains, routes, and origin groups and a wildcard TLS certificate in 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 с помощью этой конфигурации:

Diagram that shows an Azure Front Door configuration that has multiple custom stamp-based stem domains, routes, origin groups, and wildcard TLS certificate in 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 с помощью этой конфигурации:

Diagram that shows an Azure Front Door configuration that has multiple custom vanity domains, routes, and origin groups and a combination of TLS certificates in Key Vault and TLS certificates that are managed by 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.

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