Рекомендации по планированию сети Azure NetApp Files
Планирование архитектуры сети — это ключевой элемент в разработке любой инфраструктуры приложений. Эта статья поможет вам спроектировать для рабочих нагрузок эффективную сетевую архитектуру с поддержкой широких возможностей Azure NetApp Files.
Тома Azure NetApp Files размещаются в специализированной делегированной подсети в пределах виртуальной сети Azure. Таким образом, вы можете получить доступ к томам непосредственно из Azure через пиринг виртуальной сети или из локальной среды через шлюз виртуальная сеть (ExpressRoute или VPN-шлюз). Подсеть выделена Для Azure NetApp Files и нет подключения к Интернету.
Настраиваемые сетевые функции
В поддерживаемых регионах можно создавать новые тома или изменять существующие тома для использования сетевых функций уровня "Стандартный " или "Базовый ". В регионах, где сетевые функции уровня "Стандартный" не поддерживаются, том по умолчанию использует базовые сетевые функции. Дополнительные сведения см. в разделе "Настройка сетевых функций".
Стандартные
Выбор этого параметра обеспечивает более высокие ограничения IP-адресов и стандартные функции виртуальной сети, такие как группы безопасности сети и определяемые пользователем маршруты в делегированных подсетях, а также дополнительные шаблоны подключения, как показано в этой статье.Базовая
Выбор этого параметра включает выборочные шаблоны подключения и ограниченный масштаб IP-адресов, как упоминание в разделе "Рекомендации". Все ограничения применяются в этом параметре.
Поддерживаемые регионы
Параметр настройки сетевых функций уровня "Стандартный" в новых томах и изменения сетевых функций для существующих томов доступен в следующих регионах:
- Центральная Австралия
- Центральная Австралия 2
- Восточная Австралия
- Юго-Восточная часть Австралии
- Южная Бразилия
- Юго-Восточная Бразилия
- Центральная Канада
- Восточная Канада
- Центральная Индия
- Центральная часть США
- Восточная Азия
- Восточная часть США
- Восточная часть США 2
- Центральная Франция
- Северная Германия
- Центрально-Западная Германия
- Израиль, центральный регион
- Восточная Япония
- Западная Япония
- Республика Корея, центральный регион
- Республика Корея, южный регион
- Центрально-северная часть США
- Северная Европа
- Восточная Норвегия;
- Западная Норвегия
- Центральный Катар
- Северная часть ЮАР;
- Центрально-южная часть США
- Южная Индия
- Юго-Восточная Азия
- Центральная Швеция
- Северная Швейцария
- Западная Швейцария
- Центральная часть ОАЭ
- Северная часть ОАЭ;
- южная часть Соединенного Королевства
- западная часть Соединенного Королевства
- US Gov (Аризона)
- US Gov (Техас)
- US Gov (Вирджиния)
- Западная Европа
- Западная часть США
- западная часть США 2
- Западная часть США — 3
Рекомендации
При планировании сети для Azure NetApp Files следует учитывать некоторые аспекты.
Ограничения
В следующей таблице описывается, что поддерживается для каждой конфигурации сетевых функций:
| Функции | Стандартные сетевые функции | Основные сетевые функции |
|---|---|---|
| Количество IP-адресов в виртуальной сети (включая немедленно пиринговые виртуальные сети), обращающиеся к томам в Azure NetApp Files, на котором размещена виртуальная сеть | Те же стандартные ограничения, что и виртуальные машины | 1000 |
| Делегированные подсети Azure NetApp Files на виртуальную сеть | 1 | 1 |
| Группы безопасности сети (NSG) в делегированных подсетях Azure NetApp Files | Да | Нет |
| Определяемые пользователем маршруты (определяемые пользователем) в делегированных подсетях Azure NetApp Files | Да | Нет |
| Подключение тивность к Частные конечные точки | Да* | No |
| Подключение тивность к Конечные точки службы | Да | Нет |
| политики Azure (например, пользовательские политики именования) для интерфейса Azure NetApp Files; | No | No |
| подсистемы балансировки нагрузки для трафика Azure NetApp Files; | No | No |
| Виртуальная сеть с двумя стеками (IPv4 и IPv6) | Без (поддерживается только IPv4) |
Без (поддерживается только IPv4) |
| Трафик, перенаправленный через NVA из одноранговой виртуальной сети | Да | Нет |
* Применение групп безопасности сети Azure в подсети приватного канала к Azure Key Vault не поддерживается для ключей, управляемых клиентом Azure NetApp Files. Группы безопасности сети не влияют на подключение к Приватный канал, если политика сети частной конечной точки не включена в подсети. Рекомендуется отключить этот параметр.
Поддерживаемые топологии сети
В следующей таблице описаны топологии сети, поддерживаемые каждой конфигурацией сетевых функций Azure NetApp Files.
| Топологии | Стандартные сетевые функции | Основные сетевые функции |
|---|---|---|
| Подключение к тому в локальной виртуальной сети | Да | Да |
| Подключение к тому в одноранговой виртуальной сети того же региона | Да | Да |
| Подключение к тому в одноранговой виртуальной сети другого региона или глобального пиринга | Да* | No |
| Подключение к тому через шлюз ExpressRoute | Да | Да |
| ExpressRoute (ER) FastPath | Да | Нет |
| Подключение из локальной среды к тому в периферийной виртуальной сети через шлюз ExpressRoute и пиринг виртуальных сетей с транзитом через шлюз | Да | Да |
| Подключение из локальной среды к тому в периферийной виртуальной сети через шлюз VPN | Да | Да |
| Подключение из локальной среды к тому в периферийной виртуальной сети через шлюз VPN и пиринг виртуальных сетей с транзитом через шлюз | Да | Да |
| Подключение тивность через активные и пассивные VPN-шлюзы | Да | Да |
| Подключение тивность через активные и активные VPN-шлюзы | Да | Нет |
| Подключение волютивность через шлюзы с избыточностью активных и активных зон | Да | Нет |
| Подключение волютивность через избыточные шлюзы активных и пассивных зон | Да | Да |
| Подключение чувствительность к Виртуальная глобальная сеть (VWAN) | Да | Нет |
* Этот параметр взимает плату за входящий и исходящий трафик, использующий пиринг виртуальной сети. Дополнительные сведения см. в статье Цены на виртуальную сеть Microsoft Azure. Дополнительные сведения см. в разделе пиринга виртуальных сетей.
Виртуальная сеть для томов Azure NetApp Files
В этом разделе объясняются основные понятия, которые помогут в планировании виртуальных сетей.
Виртуальные сети Azure
Перед подготовкой тома Azure NetApp Files необходимо создать виртуальную сеть Azure или использовать ее, которая уже существует в той же подписке. Эта виртуальная сеть определяет границу сети для тома. Дополнительные сведения о создании виртуальных сетей см. в документации по виртуальным сетям Azure.
подсети;
Подсети сегментируют виртуальную сеть на отдельные адресные пространства, которые используют размещаемые в них ресурсы Azure. Тома Azure NetApp Files размещаются в специализированной делегированной подсети.
Делегирование подсети явно разрешает службе Azure NetApp Files создавать в этой подсети необходимые для службы ресурсы. При развертывании службы используется уникальный идентификатор. В этом случае создается сетевой интерфейс, поддерживающий подключение к Azure NetApp Files.
Если вы используете новую виртуальную сеть, можно создать подсеть и делегировать ее службе Azure NetApp Files, выполнив инструкции из статьи Делегирование подсети службе Azure NetApp Files. Вы также можете делегировать существующую пустую подсеть, которая не делегирована другим службам.
Если виртуальная сеть подключена к другой виртуальной сети, невозможно развернуть адресное пространство виртуальной сети. Это означает, что делегированную подсеть нужно создавать в уже имеющемся адресном пространстве виртуальной сети. Если адресное пространство необходимо расширить, сначала удалите пиринг виртуальной сети.
Внимание
Убедитесь, что размер адресного пространства виртуальной сети Azure NetApp Files превышает делегированную подсеть.
Например, если делегированная подсеть имеет значение /24, адресное пространство виртуальной сети, содержащее подсеть, должно быть /23 или больше. Несоответствие с этим руководством может привести к непредвиденным проблемам в некоторых шаблонах трафика: трафик, проходящий по топологии концентратора и периферийной сети, которая достигает Azure NetApp Files через сетевое виртуальное устройство, не работает должным образом. Кроме того, эта конфигурация может привести к сбоям при создании томов S МБ и CIFS, если они пытаются достичь DNS через топологию сети концентратора и периферийной сети.
Также рекомендуется, чтобы размер делегированной подсети был не менее /25 для рабочих нагрузок SAP и /26 для других сценариев рабочей нагрузки.
Определяемые пользователем маршруты и группы безопасности сети
Если подсеть имеет сочетание томов со стандартными и базовыми сетевыми функциями, определяемые пользователем маршруты (UDR) и группы безопасности сети (NSG), примененные к делегированным подсетям, будут применяться только к томам с помощью стандартных сетевых функций.
Примечание.
Связывание групп безопасности сети на уровне сетевого интерфейса не поддерживается для сетевых интерфейсов Azure NetApp Files.
Настройка UDR в исходных подсетях виртуальной машины с префиксом адреса делегированной подсети и следующим прыжком, так как NVA не поддерживается для томов с базовыми сетевыми функциями. Такой параметр приведет к проблемам с подключением.
Примечание.
Чтобы получить доступ к тому Azure NetApp Files из локальной сети через шлюз виртуальной сети (ExpressRoute или VPN) и брандмауэр, настройте таблицу маршрутов, назначенную шлюзу виртуальной сети, чтобы включить IPv4-адрес тома Azure NetApp Files, указанный в списке, и указать /32 брандмауэр в качестве следующего прыжка. Использование статистического адресного пространства, включающее IP-адрес тома Azure NetApp Files, не перенаправит трафик Azure NetApp Files в брандмауэр.
Примечание.
Если вы хотите настроить маршрут UDR в виртуальной сети виртуальной машины, чтобы управлять маршрутизацией пакетов, предназначенных для стандартного тома Azure NetApp Files в регионе, префикс UDR должен быть более конкретным или равным делегированной подсети тома Azure NetApp Files. Если префикс UDR больше, чем размер делегированной подсети, он не будет эффективным.
Собственные среды 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. Причиной этого является то, что периферийные виртуальные сети не пиринговые, а транзитная маршрутизация не поддерживается через пиринг виртуальной сети.
Глобальный или межрегионального пиринга виртуальной сети
На следующей схеме показана среда Azure с пирингом между регионами.
С помощью стандартных сетевых функций виртуальные машины могут подключаться к томам в другом регионе через глобальный или межрегионального пиринга виртуальной сети. На приведенной выше схеме в конфигурацию в разделе пиринга локальной виртуальной сети добавляется второй регион. Для виртуальной сети 4 на этой схеме том Azure NetApp Files создается в делегированной подсети и может быть подключен к виртуальной машине 5 в подсети приложения.
На схеме VM2 в регионе 1 может подключаться к тому 3 в регионе 2. VM5 в регионе 2 может подключаться к тому 2 в регионе 1 через пиринг виртуальной сети между регионом 1 и регионом 2.
Гибридные среды
На следующей схеме представлена гибридная среда.
В гибридном сценарии приложениям из локальных центров обработки данных требуется доступ к ресурсам в Azure. Это касается того, хотите ли вы расширить центр обработки данных в Azure или использовать собственные службы Azure или аварийное восстановление. Сведения о подключении нескольких локальных ресурсов к ресурсам в Azure с помощью VPN-подключения типа "сеть — сеть" или ExpressRoute см. в описании вариантов планирования VPN-шлюза.
В звездообразной гибридной топологии центральная виртуальная сеть, размещенная в Azure, выполняет роль центральной точки подключения к локальной сети. Периферийными называются виртуальные сети, для которых настроен пиринг с центральной сетью. Они могут использоваться для изоляции рабочих нагрузок.
В зависимости от конфигурации это позволяет подключать локальные ресурсы к ресурсам в центральной и периферийных виртуальных сетях.
В описанной выше топологии локальная сеть подключена к центральной виртуальной сети в Azure, а две периферийные виртуальные сети в том же регионе участвуют в пиринге с центральной виртуальной сетью. В этом сценарии для томов Azure NetApp Files поддерживаются следующие механизмы подключения:
- локальные ресурсы виртуальных машин 1 и 2 могут подключаться к тому 1 в центральной виртуальной сети через VPN-подключение типа "сеть — сеть" или канал ExpressRoute;
- Локальные ресурсы виртуальной машины 1 и виртуальной машины 2 могут подключаться к тому 2 или тому 3 через VPN-подключение типа "сеть — сеть" и региональной пиринговой сети.
- виртуальная машина 3 в центральной виртуальной сети может подключаться к тому 2 в периферийной виртуальной сети 1 и тому 3 в периферийной виртуальной сети 2;
- виртуальная машина 4 в периферийной виртуальной сети 1 и виртуальная машина 5 в периферийной виртуальной сети 2 могут подключаться к тому 1 в центральной виртуальной сети;
- Виртуальная машина 4 в периферийной виртуальной сети 1 не может подключиться к тому 3 в периферийной виртуальной сети 2. Кроме того, виртуальная машина 5 в периферийной виртуальной сети2 не может подключиться к тому 2 в периферийной виртуальной сети 1. Это связано с тем, что периферийные виртуальные сети не пиринговые и транзитная маршрутизация не поддерживается через пиринг виртуальной сети.
- В приведенной выше архитектуре при наличии шлюза в периферийной виртуальной сети также будет потеряно подключение к тому ANF из локального подключения через шлюз в Концентраторе. Стандартное поведение определяет, что приоритет отдается шлюзу в периферийной виртуальной сети, так что только подключенные к этому шлюзу компьютеры получают доступ к тому Azure NetApp Files.
Следующие шаги
- Делегирование подсети службе Azure NetApp Files
- Настройка сетевых функций для тома Azure NetApp Files
- Пиринг виртуальной сети
- Настройка Виртуальная глобальная сеть для Azure NetApp Files
- Хранилище уровня "Стандартный" с прохладным доступом в Azure NetApp Files
- Управление хранилищем Azure NetApp Files уровня "Стандартный" с прохладным доступом