Рекомендации по планированию сети Azure NetApp Files

Планирование архитектуры сети — это ключевой элемент в разработке любой инфраструктуры приложений. Эта статья поможет вам спроектировать для рабочих нагрузок эффективную сетевую архитектуру с поддержкой широких возможностей Azure NetApp Files.

Тома Azure NetApp Files размещаются в специализированной делегированной подсети в пределах виртуальной сети Azure. Таким образом, вы можете получить доступ к томам непосредственно из Azure через пиринг виртуальной сети или из локальной среды через шлюз виртуальной сети (шлюз ExpressRoute или VPN). Подсеть выделена для Azure NetApp Files, и отсутствует подключение к Интернету.

Параметр настройки сетевых функций уровня "Стандартный" для новых томов и изменения сетевых функций для существующих томов поддерживается во всех регионах с поддержкой Azure NetApp Files.

Настраиваемые сетевые функции

Вы можете создавать новые тома или изменять существующие тома для использования сетевых функций уровня "Стандартный " или "Базовый ". Дополнительные сведения см. в разделе "Настройка сетевых функций".

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

• Базовая
  Выбор этого параметра включает выборочные шаблоны подключения и ограниченный масштаб IP-адресов, как упоминалось в разделе "Рекомендации ". Все ограничения применяются в этом параметре.

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

При планировании сети для Azure NetApp Files следует учитывать некоторые аспекты.

Ограничения

В следующей таблице описывается, что поддерживается для каждой конфигурации сетевых функций:

Поддерживаемые топологии сети

В следующей таблице описаны топологии сети, поддерживаемые каждой конфигурацией сетевых функций Azure NetApp Files.

* Этот параметр взимает плату за входящий и исходящий трафик, использующий пиринг виртуальной сети. Дополнительные сведения см. в статье Цены на виртуальную сеть Microsoft Azure. Дополнительные сведения см. в разделе пиринга виртуальных сетей.

Виртуальная сеть для томов Azure NetApp Files

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

Виртуальные сети Azure

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

подсети;

Подсети сегментируют виртуальную сеть на отдельные адресные пространства, которые могут использоваться ресурсами Azure, находящимися в них. Тома Azure NetApp Files размещаются в специализированной делегированной подсети.

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

Если вы используете новую виртуальную сеть, можно создать подсеть и делегировать ее службе Azure NetApp Files, выполнив инструкции из статьи Делегирование подсети службе Azure NetApp Files. Вы также можете делегировать существующую пустую подсеть, которая не делегирована другим службам.

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

Определяемые пользователем маршруты (UDR) и группы безопасности сети (NSG)

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

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

Собственные среды Azure

На следующей схеме представлена собственная среда Azure.

Локальная виртуальная сеть

Базовый сценарий — создание или подключение тома Azure NetApp Files из виртуальной машины в той же виртуальной сети. Для виртуальной сети 2 на схеме том 1 создаётся в делегированной подсети и может быть подключён на виртуальной машине 1 в подсети по умолчанию.

Пиринговая связь между виртуальными сетями

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

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

Кроме того, рассмотрим сценарий, в котором виртуальная сеть 1 имеет пиринг с виртуальной сетью 2, а виртуальная сеть 2 выполняет пиринг с виртуальной сетью 3 в том же регионе. Ресурсы из виртуальной сети 1 могут подключаться к ресурсам в виртуальной сети 2, но не могут подключаться к ресурсам в виртуальной сети 3, если только виртуальная сеть 1 и виртуальная сеть 3 не имеют пиринговой связи.

На приведенной выше схеме, хотя виртуальная машина 3 может подключиться к тому 1, виртуальная машина 4 не может подключиться к тому 2. Причиной этого является то, что периферийные виртуальные сети не пиринговые, а транзитная маршрутизация не поддерживается через пиринг виртуальной сети.

Глобальный или межрегиональный VNet-пиринг

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

С помощью стандартных сетевых функций виртуальные машины могут подключаться к томам в другом регионе через глобальный или межрегионального пиринга виртуальной сети. На приведенной выше схеме в конфигурацию в разделе пиринга локальной виртуальной сети добавляется второй регион. Для виртуальной сети 4 на этой схеме том Azure NetApp Files создается в делегированной подсети и может быть подключен к виртуальной машине 5 в подсети приложения.

На схеме VM2 в Регионе 1 может соединяться с Томом 3 в Регионе 2. VM5 в регионе 2 может подключаться к тому 2 в регионе 1 через пиринг виртуальной сети между регионом 1 и регионом 2.

Гибридные среды

На следующей схеме представлена гибридная среда.

В гибридном сценарии приложениям из локальных центров обработки данных требуется доступ к ресурсам в Azure. Это касается того, хотите ли вы расширить центр обработки данных в Azure или использовать собственные службы Azure или аварийное восстановление. Сведения о подключении нескольких локальных ресурсов к ресурсам в Azure с помощью VPN-подключения типа "сеть — сеть" или ExpressRoute см. в описании вариантов планирования VPN-шлюза.

В звездообразной гибридной топологии центральная виртуальная сеть, размещенная в Azure, выполняет роль центральной точки подключения к локальной сети. Спицы — это виртуальные сети (VNets), настроенные на пиринг с узловой сетью, и они могут быть использованы для изоляции рабочих нагрузок.

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

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

• Локальные ресурсы ВМ 1 и ВМ 2 могут подключаться к Тому 1 в центральной виртуальной сети через VPN-подключение типа "сеть-сеть" или канал ExpressRoute.
• Локальные ресурсы виртуальных машин 1 и 2 могут подключаться к Volume 2 или Volume 3 через межсайтовой VPN и через региональную пиринговую VNet.
• виртуальная машина 3 в центральной виртуальной сети может подключаться к тому 2 в периферийной виртуальной сети 1 и тому 3 в периферийной виртуальной сети 2;
• виртуальная машина 4 в периферийной виртуальной сети 1 и виртуальная машина 5 в периферийной виртуальной сети 2 могут подключаться к тому 1 в центральной виртуальной сети;
• Виртуальная машина 4 в периферийной виртуальной сети 1 не может подключиться к тому 3 в периферийной виртуальной сети 2. Кроме того, виртуальная машина 5 в периферийной виртуальной сети2 не может подключиться к тому 2 в периферийной виртуальной сети 1. Это связано с тем, что спицевые VNet не соединены и транзитная маршрутизация не поддерживается при пиринге виртуальных сетей.
• В приведенной выше архитектуре, если в периферийной VNet также есть шлюз, то подключение к ANF-тома из локальной сети через шлюз в Hub будет потеряно. По задумке, предпочтение отдается шлюзу в периферийной виртуальной сети, и поэтому только компьютеры, подключенные через этот шлюз, могут получить доступ к ANF том.

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

• Делегирование подсети службе Azure NetApp Files
• Настройка сетевых функций для тома Azure NetApp Files
• Пиринг виртуальной сети
• Настройте виртуальную глобальную сеть для Azure NetApp Files
• Хранилище Azure NetApp Files с холодным доступом
• Управление хранилищем Azure NetApp Files с помощью холодного доступа