Поделиться через

Архитектурные подходы к организации сети в мультитенантных решениях

  • Статья

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

Примечание.

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

Ключевые рекомендации и требования

Службы инфраструктуры и платформы

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

Службы инфраструктуры

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

Службы платформы

Если вы используете службы платформы Azure, такие как Служба приложений, Azure Cosmos DB или База данных SQL Azure, то используемая архитектура определит необходимые сетевые службы.

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

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

  • Требования к соответствию: может потребоваться соответствовать определенному стандарту соответствия. Для некоторых стандартов требуется, чтобы среда Azure была настроена определенным образом.
  • Требования клиентов: даже если у вашей организации нет конкретных требований к изоляции или элементам управления сетевого слоя, клиенты могут. Убедитесь, что у вас есть четкое представление о том, как ваши клиенты будут получать доступ к вашему решению и иметь ли у них какие-либо предположения о его сетевом проектировании.
  • Сложность. Это может быть сложнее для понимания и работы с виртуальными сетями. Убедитесь, что ваша команда имеет четкое представление о принципах, связанных с этим, или вы, скорее всего, развертываете небезопасную среду.

Убедитесь, что вы понимаете последствия использования частной сети.

Изменение размера подсетей

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

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

Аналогичным образом, при работе с управляемыми службами важно понимать, как используются IP-адреса. Например, при использовании Служба Azure Kubernetes с сетевым интерфейсом контейнеров Azure (CNI) количество IP-адресов, потребляемых из подсети, будет зависеть от таких факторов, как количество узлов, горизонтальное масштабирование и процесс развертывания службы, используемый вами. При использовании службы приложение Azure и Функции Azure с интеграцией виртуальной сети количество используемых IP-адресов зависит от количества экземпляров плана.

Ознакомьтесь с руководством по сегментации подсети при планировании подсетей.

Общедоступный или частный доступ

Рассмотрите, будут ли ваши клиенты получать доступ к службам через Интернет или через частные IP-адреса.

Для доступа через Интернет (общедоступный) можно использовать правила брандмауэра, разрешенный список IP-адресов и списки запретов, общие секреты и ключи, а также элементы управления на основе удостоверений для защиты службы.

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

Доступ к конечным точкам клиентов

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

Если необходимо отправить данные конечным точкам клиентов, рассмотрите следующие распространенные подходы:

  • Инициируйте подключения из решения к конечным точкам клиентов через Интернет. Рассмотрите, должны ли подключения исходить из статического IP-адреса. В зависимости от используемых служб Azure может потребоваться развернуть шлюз NAT, брандмауэр или подсистему балансировки нагрузки.
  • Разверните агент, чтобы включить подключение между размещенными в Azure службами и сетями клиентов независимо от того, где они находятся.
  • Для односторонного обмена сообщениями рекомендуется использовать службу, например Сетка событий Azure, потенциально в сочетании с доменами событий.

Подходы и шаблоны, которые следует учитывать

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

Виртуальные сети для конкретного клиента с ip-адресами, выбранными поставщиком услуг

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

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

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

Виртуальные сети для конкретного клиента с ip-адресами, выбранными клиентом

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

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

Звездообразная топология

Топология концентратора и периферийной виртуальной сети позволяет выполнять пиринг централизованной виртуальной сети концентратора с несколькими периферийными виртуальными сетями. Вы можете централизованно контролировать входящий трафик и исходящий трафик для виртуальных сетей, а также контролировать, могут ли ресурсы в виртуальной сети каждой периферийной виртуальной сети взаимодействовать друг с другом. Каждая периферийная виртуальная сеть также может получить доступ к общим компонентам, таким как Брандмауэр Azure, и она может использовать такие службы, как Защита от атак DDoS Azure.

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

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

Совет

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

Статические IP-адреса

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

При работе с виртуальными машинами и другими компонентами инфраструктуры рекомендуется использовать подсистему балансировки нагрузки или брандмауэр для входящего и исходящего статического IP-адреса. Рекомендуется использовать шлюз NAT для управления IP-адресом исходящего трафика. Дополнительные сведения об использовании шлюза NAT в мультитенантном решении см . в рекомендациях по мультитенантности шлюза Azure NAT.

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

Агенты

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

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

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

Ниже приведены примеры службы Майкрософт, которые предоставляют агенты для подключения к сетям клиентов:

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

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

Доменные имена, поддомены и TLS

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

Шаблоны маршрутизации и разгрузки шлюза

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

  • Маршрутизация запросов на серверные серверы или метки развертывания для конкретного клиента.
  • Обработка доменных имен для конкретного клиента и сертификатов TLS.
  • Проверка запросов на угрозы безопасности с помощью брандмауэра веб-приложения (WAF).
  • Кэширование ответов для повышения производительности.

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

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

Шаблон размещения статического содержимого

Шаблон размещения статического содержимого включает обслуживание веб-содержимого из облачной службы хранилища и использование сети доставки содержимого (CDN) для кэширования содержимого.

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

В зависимости от того, как разработано решение, вы также можете кэшировать файлы или данные клиента в CDN, например ответы API в формате JSON. Эта практика помогает повысить производительность и масштабируемость решения, но важно учитывать, достаточно ли изолированы данные для конкретного клиента, чтобы избежать утечки данных между клиентами. Рассмотрим способ очистки содержимого для конкретного клиента из кэша, например при обновлении данных или развертывании новой версии приложения. Включив идентификатор клиента в путь URL-адреса, можно управлять очисткой определенного файла, всеми файлами, связанными с конкретным клиентом, или всеми файлами для всех клиентов.

Неподходящие антишаблоны

Сбой планирования подключения к виртуальной сети

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

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

Не планируется для ограничений

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

Небольшие подсети

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

Неправильное сегментирование сети

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

Использование только элементов управления безопасностью на уровне сети

В современных решениях важно объединить сетевой уровень безопасности с другими элементами управления безопасностью, и не следует полагаться только на брандмауэры или сегментацию сети. Иногда это называется сетью нулевого доверия. Используйте элементы управления на основе удостоверений для проверки клиента, вызывающего или пользователя на каждом уровне решения. Рассмотрите возможность использования служб, позволяющих добавлять дополнительные уровни защиты. Доступные параметры зависят от используемых служб Azure. В AKS рассмотрите возможность использования сетки служб для взаимной проверки подлинности TLS и политик сети для управления трафиком на востоке запада. В Служба приложений рассмотрите возможность использования встроенной поддержки проверки подлинности и авторизации и ограничений доступа.

Перезапись заголовков узлов без тестирования

При использовании шаблона разгрузки шлюза можно перезаписать Host заголовок HTTP-запросов. Эта практика может упростить настройку серверной службы веб-приложений, выгрузив личный домен и управление TLS на шлюз.

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

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

Соавторы

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

Автор субъекта:

  • Джон Даунс | Главный инженер программного обеспечения

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

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

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