Мультитенантность и Приватный канал Azure

  • Статья

Приватный канал Azure предоставляет частные IP-адреса для служб платформы Azure и для собственных приложений, размещенных на виртуальных машинах Azure. Вы можете использовать Приватный канал для включения частного подключения из сред Azure клиентов. Клиенты также могут использовать Приватный канал для доступа к решению из локальных сред, когда они подключены через шлюзы виртуальной частной сети (VPN-шлюз) или ExpressRoute.

Приватный канал Azure используется многими крупными поставщиками SaaS, включая Snowflake, Confluent Cloud и MongoDB Atlas.

В этой статье мы рассмотрим, как настроить Приватный канал для мультитенантного решения, размещенного в Azure.

Основные рекомендации

Перекрывающиеся пространства IP-адресов

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

Разные клиенты часто используют одинаковые или перекрывающиеся частные IP-адреса. Например, мультитенантное решение может использовать пространство 10.1.0.0/16IP-адресов. Предположим, клиент A использует собственную локальную сеть с тем же пространством IP-адресов, и совпало с клиентом B также использует то же пространство IP-адресов. Вы не можете напрямую подключать или объединять сети, так как диапазоны IP-адресов перекрываются.

При использовании Приватный канал для включения подключения от каждого клиента к мультитенантным решениям трафик каждого клиента автоматически применяется для преобразования сетевых адресов (NAT). Каждый клиент может использовать частный IP-адрес в своей собственной сети, а потоки трафика в мультитенантное решение прозрачно. Приватный канал выполняет NAT по трафику, даже если клиенты и поставщик служб используют перекрывающиеся диапазоны IP-адресов:

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

Когда трафик поступает в мультитенантное решение, он уже переведен. Это означает, что трафик создается из собственного IP-адреса виртуальной сети мультитенантной службы. Приватный канал предоставляет Функция протокола TCP Proxy версии 2, которая позволяет мультитенантной службе знать клиент, отправляющий запрос, и даже исходный IP-адрес из исходной сети.

Выбор службы

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

Приватный канал Azure служба используется с виртуальными машинами за стандартной подсистемой балансировки нагрузки.

Вы также можете использовать Приватный канал с другими службами Azure. К этим службам относятся платформы размещения приложений, такие как приложение Azure служба. Они также включают Шлюз приложений Azure или Azure Управление API, которые являются сетевыми и шлюзами API.

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

Ограничения

Тщательно рассмотрим количество частных конечных точек, которые можно создать на основе архитектуры решения. Если вы используете платформу приложений в качестве службы (PaaS), важно учитывать максимальное количество частных конечных точек, которые может поддерживать один ресурс. При запуске виртуальных машин можно подключить экземпляр службы Приватный канал к стандартной подсистеме балансировки нагрузки (SLB). В этой конфигурации обычно можно подключить большее количество частных конечных точек, но ограничения по-прежнему применяются. Эти ограничения могут определить, сколько клиентов можно подключить к ресурсам с помощью Приватный канал. Просмотрите ограничения подписки и службы Azure, квоты и ограничения , чтобы понять ограничения количества конечных точек и подключений.

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

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

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

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

Многие службы Azure PaaS поддерживают Приватный канал для входящего подключения, даже в разных подписках Azure и клиентах Microsoft Entra. Для предоставления конечной точки можно использовать Приватный канал возможности этой службы.

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

Например, предположим, что вы создаете приложение с доступом к Интернету, которое выполняется в масштабируемом наборе виртуальных машин. Вы используете Azure Front Door, включая брандмауэр веб-приложения (WAF), для ускорения безопасности и трафика, и вы настраиваете Front Door для отправки трафика через частную конечную точку в серверную службу (источник). Клиент A подключается к решению с помощью общедоступной конечной точки, а клиент B подключается с помощью частной конечной точки. Так как Front Door не поддерживает Приватный канал для входящих подключений, трафик клиента B проходит ваш Front Door и его WAF:

Схема, показывающая запросы, поступающие через Azure Front Door, а также через частную конечную точку, которая проходит Front Door.

Модели изоляции

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

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

Фактор Общая служба Приватный канал и общая подсистема балансировки нагрузки Выделенная служба Приватный канал и выделенная подсистема балансировки нагрузки Выделенная служба Приватный канал и общая подсистема балансировки нагрузки
Сложность развертывания Низкая Средний уровень в зависимости от количества клиентов Средний уровень в зависимости от количества клиентов
Операционная сложность Низкая Средний уровень в зависимости от количества ресурсов Средний уровень в зависимости от количества ресурсов
Ограничения для рассмотрения Количество частных конечных точек в той же службе Приватный канал Количество служб Приватный канал на подписку Количество служб Приватный канал для стандартной подсистемы балансировки нагрузки
Пример сценария Крупное мультитенантное решение с общим уровнем приложений Отдельные метки развертывания для каждого клиента Общий уровень приложений в одной метке с большим количеством клиентов

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

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

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

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

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

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

Модели изоляции для служб PaaS Azure с частными конечными точками

При развертывании служб платформы Azure как службы (PaaS) и требуется разрешить клиентам доступ к этим службам с частными конечными точками, а затем рассмотрите возможности и ограничения конкретной службы. Кроме того, рассмотрите, выделены ли ресурсы уровня приложений определенному клиенту или если они совместно используются между клиентами.

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

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

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

Псевдонимы служб

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

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

Видимость службы

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

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

Утверждения подключения

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

Служба Приватный канал поддерживает несколько типов потоков утверждения, в том числе:

  • Утверждение вручную, где ваша команда явно утверждает каждое подключение. Этот подход подходит, если у вас есть только несколько клиентов, которые используют службу через Приватный канал.
  • Утверждение на основе API, в котором служба Приватный канал обрабатывает подключение как требование ручного утверждения, и приложение использует API подключения к частной конечной точке обновления, Azure CLI или Azure PowerShell для утверждения подключения. Этот подход может оказаться полезным, если у вас есть список клиентов, которым разрешено использовать частные конечные точки.
  • Автоматическое утверждение, где сама служба Приватный канал поддерживает список идентификаторов подписок, которые должны иметь свои подключения автоматически утверждены.

Дополнительные сведения см. в разделе "Управление доступом к службе".

Протокол прокси версии 2

При использовании службы Приватный канал по умолчанию приложение имеет видимость только IP-адреса, который был выполнен через преобразование сетевых адресов (NAT). Это означает, что трафик, как представляется, передается из собственной виртуальной сети.

Приватный канал позволяет получить доступ к исходному IP-адресу клиента в виртуальной сети клиента. Эта функция использует протокол TCP-прокси версии 2.

Например, предположим, что администраторы клиентов должны добавить ограничения доступа на основе IP-адресов, например узел 10.0.0.10 может получить доступ к службе, но узел 10.0.0.20 не может. При использовании прокси-протокола версии 2 клиенты могут настроить эти типы ограничений доступа в приложении. Однако код приложения должен проверить исходный IP-адрес клиента и применить ограничения.

  • Приватный канал Azure объяснения и демонстрации служб от поставщика (SaaS ISV) и потребительских перспектив: видео, которое смотрит на функцию службы Приватный канал Azure, которая позволяет мультитенантным поставщикам услуг (например, независимым поставщикам программного обеспечения создавать продукты SaaS). Это решение позволяет потребителям получать доступ к службе поставщика с помощью частных IP-адресов из собственных виртуальных сетей Azure потребителя.
  • Протокол TCP-прокси версии 2 с Приватный канал Azure службой— глубокое погружение: видео, представляющее собой подробный обзор протокола TCP-прокси версии 2, который является расширенной функцией службы Приватный канал Azure. Это полезно в мультитенантных и сценариях SaaS. В видео показано, как включить протокол прокси версии 2 в службе Приватный канал Azure. В нем также показано, как настроить службу NGINX для чтения исходного частного IP-адреса исходного клиента, а не IP-адреса NAT для доступа к службе через частную конечную точку.
  • Использование NGINX Plus для декодирования TLV linkIdentifier прокси-протокола из службы Приватный канал Azure: видео, которое проверяет, как использовать NGINX Plus для получения протокола TCP Proxy версии 2 TLV из службы Приватный канал Azure. В видео показано, как затем извлечь и декодировать числовой linkIdentifier, также называемый LINKIDподключением к частной конечной точке. Это решение полезно для мультитенантных поставщиков, которым необходимо определить конкретный клиент потребителя, из которого было выполнено подключение.
  • Шаблон приватного подключения SaaS: пример решения, иллюстрирующий один подход для автоматизации утверждения подключений к частной конечной точке с помощью управляемых приложений Azure.

Соавторы

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

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

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

  • Sumeet Mittal | Основной диспетчер продуктов, Приватный канал Azure

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

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

Просмотрите сетевые подходы для мультитенантности.