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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

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

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

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

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

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

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

подсети;

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

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

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

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

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

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

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

В родных средах Azure

На следующей схеме показана среда, нативная для Azure:

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

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

Пиринговое соединение VNet

Если у вас есть другие виртуальные сети в том же регионе, для которого требуется доступ к ресурсам друг друга, виртуальные сети можно подключить с помощью пиринга VNet для обеспечения безопасного подключения через инфраструктуру 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 в делегированной подсети и может быть подключен к VM5 в подсети приложения.

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

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

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

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

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

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

В приведенной выше топологии локальная сеть подключена к центральной виртуальной сети в Azure, и в одном регионе есть 2 периферийные виртуальные сети, пиринговые с виртуальной сетью концентратора. В этом сценарии параметры подключения, поддерживаемые для томов 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 в виртуальной сети spoke VNet2 не может подключиться к Volume 2 в виртуальной сети spoke VNet1. Это связано с тем, что спицевые виртуальные сети не имеют пиринговых связей, и транзитная маршрутизация не поддерживается через пиринг виртуальной сети.
• В приведенной выше архитектуре, если в периферийной VNet также есть шлюз, то подключение к ANF-тома из локальной сети через шлюз в Hub будет потеряно. По задумке, предпочтение отдается шлюзу в периферийной виртуальной сети, и поэтому только компьютеры, подключенные через этот шлюз, могут получить доступ к ANF том.

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

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