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

Настройка поддержки виртуальной сети для экземпляра Кэш Azure для Redis класса Premium

  • Статья

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

Примечание.

Классическая модель развертывания прекращается в августе 2024 г. Дополнительные сведения см. в разделе Прекращение использования модели развертывания Облачных служб (классической) с 31 августа 2024 г.

Внимание

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

Ограничения внедрения виртуальной сети

  • Создание и обслуживание конфигураций виртуальной сети часто подвержены ошибкам. Устранение неполадок также сложно. Неправильные конфигурации виртуальной сети могут привести к проблемам:
    • Незащищенная передача метрик из экземпляров кэша
    • сбой узла реплики для репликации данных из первичного узла
    • потенциальная потеря данных
    • сбой операций управления, таких как масштабирование
    • в наиболее сложных сценариях потеря доступности
  • Внедренные кэши виртуальной сети доступны только для Кэш Azure для Redis уровня "Премиум", а не для других уровней.
  • При использовании внедренного кэша виртуальной сети необходимо изменить виртуальную сеть для кэширования зависимостей, например списков отзыва сертификатов (CRL), PKI, AKV, службы хранилища Azure, Azure Monitor и т. д.
  • Невозможно внедрить существующий экземпляр Кэш Azure для Redis в виртуальная сеть. Этот параметр необходимо выбрать при создании кэша.

Поддержка настройки виртуальной сети

Поддержка виртуальной сети настраивается во время создания кэша в области New Azure Cache for Redis (Новый Кэш Azure для Redis).

  1. Для создания кэша ценовой категории "Премиум" войдите на портал Azure и выберите Создать ресурс. Его также можно создать с помощью шаблонов Resource Manager, PowerShell или Azure CLI. Дополнительные сведения о создании экземпляра Кэша Azure для Redis см. в разделе Создание кэша.

    Снимок экрана: создание группы ресурсов.

  2. На странице Создание выберите Базы данных. Затем выберите Кэш Azure для Redis.

    Снимок экрана: выбор Кэша Azure для Redis.

  3. На странице Новый кэш Redis настройте параметры для нового кэша ценовой категории "Премиум".

    Параметр Предлагаемое значение Description
    DNS-имя Введите глобально уникальное имя. Имя кэша должно быть строкой длиной от 1 до 63 символов и содержать только цифры, буквы и дефисы. Имя должно начинаться и заканчиваться цифрой или буквой и не может содержать более одного дефиса подряд. Имя узла экземпляра кэша будет\<DNS name>.redis.cache.windows.net.
    Подписка Выберите подписку в раскрывающемся списке. В этой подписке будет создан новый экземпляр кэша Redis для Azure.
    Группа ресурсов Из раскрывающегося списка выберите группу ресурсов или щелкните Создать новую и введите имя новой группы ресурсов. Имя группы ресурсов, в которой будут созданы кэш и другие ресурсы. Поместив все ресурсы приложения в одну группу ресурсов, вы сможете легко управлять ими и/или удалить их вместе.
    Местонахождение Выберите расположение из раскрывающегося списка. Выберите оптимальный регион для других служб, которые будут использовать кэш.
    Тип кэша Из раскрывающегося списка выберите кэш ценовой категории "Премиум", чтобы настроить функции этой ценовой категории. Дополнительные сведения см. на странице Цены на Кэш Azure для Redis. Ценовая категория определяет размер, производительность и функции, доступные для кэша. Дополнительные сведения см. в статье Общие сведения о Кэше Azure для Redis.

  4. Выберите вкладку Сети или нажмите кнопку Сети в нижней части страницы.

  5. На вкладке Сети в качестве метода подключения выберите Виртуальные сети. Чтобы использовать новую виртуальную сеть, сначала создайте ее, выполнив действия, описанные в разделе Создание виртуальной сети с помощью портала Azure или статье Создание классической виртуальной сети с помощью портала Azure. Затем вернитесь в область New Azure Cache for Redis (Новый Кэш Azure для Redis), чтобы создать и настроить кэш ценовой категории "Премиум".

    Внимание

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

    Параметр Предлагаемое значение Description
    Виртуальная сеть В раскрывающемся списке выберите свою виртуальную сеть. Выберите виртуальную сеть в той же подписке и в том же расположении, что и ваш кэш.
    Подсеть В раскрывающемся списке выберите свою подсеть. Диапазон адресов подсети должен быть в нотации CIDR (например, 192.168.1.0/24). Он должен содержаться в адресном пространстве виртуальной сети.
    Статический IP-адрес Введите статический IP-адрес (необязательно). Если вы не укажете статический IP-адрес, то он будет выбран автоматически.

    Внимание

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

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

  6. Выберите вкладку Далее: Дополнительно или нажмите в нижней части страницы кнопку Далее: Дополнительно.

  7. На вкладке Дополнительно для экземпляра кэша ценовой категории "Премиум" настройте параметры для портов, отличных от TLS, а также кластеризацию и сохраняемость данных.

  8. Выберите вкладку Далее: Теги или нажмите в нижней части страницы кнопку Далее: Теги.

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

  10. Выберите Review + create (Просмотреть и создать). Вы будете перенаправлены на вкладку Проверка и создание, где Azure проверит вашу конфигурацию.

  11. Когда отобразится сообщение Проверка пройдена зеленого цвета, выберите Создать.

На создание кэша требуется некоторое время. Вы можете отслеживать ход выполнения на странице обзорных сведений кэша Azure для Redis. Когда Состояние примет значение Running (Выполняется), кэш будет готов к использованию. Создав кэш, конфигурацию виртуальной сети можно просмотреть, щелкнув в меню Ресурсы пункт Виртуальная сеть.

Виртуальная сеть

Вопросы и ответы по виртуальной сети Кэша Azure для Redis

В следующем списке содержатся ответы на часто задаваемые вопросы о Кэш Azure для Redis сети.

Каковы распространенные ошибки в конфигурации Кэша Azure для Redis и виртуальных сетей?

При размещении Кэша Azure для Redis в виртуальной сети используются порты, указанные в следующих таблицах.

Внимание

Если эти порты заблокированы, кэш может работать неправильно. Блокировка одного или нескольких из этих портов является самой распространенной ошибкой при настройке Кэша Azure для Redis в виртуальной сети.

Обязательные порты для исходящего трафика

Существует девять обязательных исходящих портов. Исходящие запросы в этих диапазонах: a) исходят для других служб, необходимых для функционирования кэша, или б) являются результатом внутреннего обмена данными между узлами в подсети Redis. Для георепликации существуют другие требования к исходящему трафику для обмена данными между подсетями основного кэша и его реплики.

Порты Направление Транспортный протокол Характер использования Локальный IP-адрес Удаленный IP-адрес
80, 443 Исходящие TCP Зависимости Redis в службе хранилища Azure или PKI (Интернет) (Подсеть Redis) * 4
443 Исходящие TCP Зависимость Redis от Azure Key Vault и Azure Monitor (Подсеть Redis) AzureKeyVault, AzureMonitor 1
53 Исходящие TCP/UDP Зависимости Redis в DNS (Интернет/виртуальная сеть) (Подсеть Redis) 168.63.129.16 и 169.254.169.254 2, а также любой пользовательский DNS-сервер для подсети 3
8443 Исходящие TCP Внутренний обмен данными для Redis (Подсеть Redis) (Подсеть Redis)
10221-10231 Исходящие TCP Внутренний обмен данными для Redis (Подсеть Redis) (Подсеть Redis)
20226 Исходящие TCP Внутренний обмен данными для Redis (Подсеть Redis) (Подсеть Redis)
13000-13999 Исходящие TCP Внутренний обмен данными для Redis (Подсеть Redis) (Подсеть Redis)
15000-15999 Исходящие TCP Внутренний обмен данными для Redis и георепликации (Подсеть Redis) (Подсеть Redis), (одноранговая подсеть геореплик)
6379-6380 Исходящие TCP Внутренний обмен данными для Redis (Подсеть Redis) (Подсеть Redis)

1 Вы можете использовать теги службы AzureKeyVault и AzureMonitor с группами безопасности сети Resource Manager (NSG).

2 Эти IP-адреса, принадлежащие корпорации Майкрософт, используются для адресации виртуальной машины узла, которая обслуживает Azure DNS.

3 Эта информация не требуется для подсетей без пользовательского DNS-сервера или более новых кэшей Redis, которые игнорируют пользовательскую службу DNS.

4 Дополнительные сведения см. в разделе Дополнительные требования к подключению к виртуальной сети.

Требования к портам, связанные с георепликацией

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

Обязательные порты для входящего трафика

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

Порты Направление Транспортный протокол Характер использования Локальный IP-адрес Удаленный IP-адрес
6379, 6380 Входящий трафик TCP Обмен данными между клиентом и Redis, балансировка нагрузки Azure (Подсеть Redis) (Подсеть Redis), (подсеть клиента), AzureLoadBalancer 1
8443 Входящий трафик TCP Внутренний обмен данными для Redis (Подсеть Redis) (Подсеть Redis)
8500 Входящий трафик TCP/UDP Балансировка нагрузки Azure (Подсеть Redis) AzureLoadBalancer
10221-10231 Входящий трафик TCP Обмен данными между клиентом и кластерами Redis, внутренний обмен данными для Redis (Подсеть Redis) (Подсеть Redis), (подсеть клиента), AzureLoadBalancer
13000-13999 Входящий трафик TCP Обмен данными между клиентом и кластерами Redis, балансировка нагрузки Azure (Подсеть Redis) (Подсеть Redis), (подсеть клиента), AzureLoadBalancer
15000-15999 Входящий трафик TCP Обмен данными между клиентом и кластерами Redis, балансировка нагрузки Azure и георепликация (Подсеть Redis) (Подсеть Redis), (подсеть клиента), AzureLoadBalancer, (одноранговая подсеть геореплик)
16001 Входящий трафик TCP/UDP Балансировка нагрузки Azure (Подсеть Redis) AzureLoadBalancer
20226 Входящий трафик TCP Внутренний обмен данными для Redis (Подсеть Redis) (Подсеть Redis)

1 Можно использовать тег службы AzureLoadBalancer для Resource Manager или AZURE_LOADBALANCER для классической модели развертывания для разработки правил NSG.

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

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

  • Исходящие сетевые подключения к конечным точкам хранилища Azure по всему миру. Конечные точки Azure Key Vault разрешаются в домене vault.azure.netDNS.
  • Исходящие сетевые подключения к конечным точкам хранилища Azure по всему миру. Относится к конечным точкам, находящимся в одном регионе с экземпляром Кэша Azure для Redis, и конечным точкам хранилища, расположенным в других регионах Azure. служба хранилища Azure конечные точки разрешаются в следующих доменах DNS: table.core.windows.net, , blob.core.windows.netqueue.core.windows.netи file.core.windows.net.
  • Исходящее сетевое подключение к ocsp.digicert.com, crl4.digicert.com, ocsp.msocsp.com, mscrl.microsoft.com, crl3.digicert.com, cacerts.digicert.comи oneocsp.microsoft.comcrl.microsoft.com. Такое подключение необходимо для поддержки функций протокола TLS/SSL.
  • Конфигурация DNS для виртуальной сети должна разрешать все конечные точки и домены, упомянутые ранее. Эти требования DNS обеспечиваются за счет настройки допустимой инфраструктуры DNS и ее поддержания для виртуальной сети.
  • Исходящее сетевое подключение к следующим конечным точкам Azure Monitor, которые разрешаются в следующих доменах DNS: shoebox2-black.shoebox2.metrics.nsatc.net, north-prod2.prod2.metrics.nsatc.net, east-prod2.prod2.metrics.nsatc.netshoebox3.prod.microsoftmetrics.comshoebox2-red.shoebox2.metrics.nsatc.netazglobal-black.azglobal.metrics.nsatc.netshoebox3-red.prod.microsoftmetrics.comshoebox3-black.prod.microsoftmetrics.comazglobal-red.azglobal.metrics.nsatc.netazredis-red.prod.microsoftmetrics.com и .azredis-black.prod.microsoftmetrics.com

Как проверить, что кэш работает в виртуальной сети?

Внимание

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

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

  • Перезагрузите все узлы кэша. Если не установить все необходимые зависимости кэша (как описано в разделах Обязательные входящие порты и Обязательные исходящие порты), то кэш не сможет перезапускаться.
  • После перезапуска узлов кэша, как сообщается о состоянии кэша в портал Azure, можно выполнить следующие тесты:

    • Ping the cache endpoint by using port 6380 from a machine, который находится в той же виртуальной сети, что и кэш, с помощью tcping. Например:

      tcping.exe contosocache.redis.cache.windows.net 6380

      Если инструмент tcping сообщает, что порт открыт, то кэш доступен для подключения с клиентов в виртуальной сети.

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

Почему при попытке подключения к моему экземпляру Кэша Azure для Redis в виртуальной сети происходит ошибка и появляется сообщение о том, что удаленный сертификат является недопустимым?

При попытке подключения к экземпляру Кэша Azure для Redis в виртуальной сети появляется сообщение об ошибке проверки сертификатов, например такое:

{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}

Причина может заключаться в том, что вы подключаетесь к узлу по IP-адресу. Мы рекомендуем использовать имя узла. Другими словами, используйте следующую строку:

[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Не используйте IP-адрес, похожий на следующую строку подключения:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Если не удается разрешить DNS-имя, некоторые клиентские библиотеки содержат параметры конфигурации, например sslHost, которые предоставляет клиент StackExchange.Redis. Этот параметр позволяет переопределить имя узла, используемое для проверки сертификата. Например:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net

Можно ли использовать виртуальные сети с кэшем ценовой категории "Стандартный" или "Базовый"?

Виртуальные сети доступны только для кэшей ценовой категории "Премиум".

Почему в одних подсетях не удается создать Кэш Azure для Redis, а в других удается?

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

Кроме того, необходимо иметь достаточное количество доступных IP-адресов в подсети.

Каковы требования к адресному пространству подсети?

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

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

Можно ли подключиться к кэшу из одноранговой виртуальной сети?

Если виртуальные сети находятся в одном регионе, их можно подключить с помощью пиринга между виртуальными сетями или подключения типа "виртуальная сеть — виртуальная сеть" через VPN-шлюз.

Если одноранговые виртуальные сети Azure находятся в разных регионах: клиентская виртуальная машина в регионе 1 не может получить доступ к кэшу в регионе 2 через IP-адрес с подсистемой балансировки нагрузки, так как в нем есть ограничение подсистем балансировки нагрузки ценовой категории "Базовый". То есть, если это не кэш с подсистемой балансировки нагрузки ценовой категории "Стандартный", который в настоящее время является только кэшем, созданным с зонами доступности.

Дополнительные сведения об ограничениях пиринга между виртуальными сетями см. здесь: Виртуальная сеть — Пиринг — Требования и ограничения. Одно из решений — использовать подключение типа "виртуальная сеть — виртуальная сеть" через VPN-шлюз вместо пиринга между виртуальными сетями.

Работают ли все функции кэша при его размещении в виртуальной сети?

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

  • Консоль Redis. Так как консоль Redis работает в локальном браузере (обычно на компьютере разработчика, который не подключен к виртуальной сети), она не может подключиться к кэшу.

Поддерживается ли внедрение виртуальных сетей в кэше, где включен Azure Lighthouse?

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

Использование ExpressRoute с кэшем Azure для Redis

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

По умолчанию только что созданный канал ExpressRoute не использует принудительное туннелирование (объявление маршрута по умолчанию, 0.0.0.0/0) в виртуальной сети. В результате исходящее подключение к Интернету разрешается непосредственно из виртуальной сети. Клиентские приложения могут подключаться к другим конечным точкам Azure, включая экземпляр Кэша Azure для Redis.

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

Чтобы устранить эту проблему, следует указать один или несколько определяемых пользователем маршрутов в подсети, которая содержит экземпляр Кэша Azure для Redis. Определяемые пользователем маршруты задают маршруты для подсети, которые будут использоваться вместо основного маршрута.

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

  • Конфигурация ExpressRoute объявляет маршрут 0.0.0.0/0 и по умолчанию организует принудительное туннелирование всех исходящих подключений в локальную среду.
  • Определяемый пользователем маршрут в подсети, содержащей экземпляр Кэша Azure для Redis, направляет трафик TCP/IP к диапазону адресов 0.0.0.0/0 в общедоступный Интернет. Например, он устанавливает тип Интернет для следующего прыжка.

В результате этих действий определяемый пользователем маршрут уровня подсети получает приоритет над принудительным туннелированием ExpressRoute и обеспечивает исходящий интернет-доступ из экземпляра Кэша Azure для Redis.

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

Внимание

Маршруты, указанные в UDR, должны быть достаточно конкретными, чтобы иметь приоритет над всеми маршрутами, объявленными в конфигурации ExpressRoute. В приведенном ниже примере используется широкий диапазон адресов 0.0.0.0/0. Он может быть случайно переопределен объявлениями маршрутов с более узкими диапазонами адресов.

Предупреждение

Кэш Azure для Redis не поддерживается с конфигурациями ExpressRoute, которые неправильно осуществляют перекрестное объявление маршрутов из пути общедоступного пиринга в путь частного пиринга. Конфигурации ExpressRoute, для которых настроен общедоступный пиринг, будут получать объявления маршрутов от корпорации Майкрософт для большого набора диапазонов IP-адресов Microsoft Azure. Если эти диапазоны адресов неправильно перекрестно объявляются в пути частного пиринга, то все исходящие сетевые пакеты из подсети экземпляра кэша Azure для Redis ошибочно принудительно туннелируются в локальную сетевую инфраструктуру клиента. Такой сетевой поток нарушает работу кэша Azure для Redis. Решением этой проблемы является остановка перекрестного объявления маршрутов между путем общедоступного и закрытого пиринга.

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

Дополнительные сведения об ExpressRoute см. в статье Технический обзор ExpressRoute.

Связанный контент

Узнайте больше о функциях Кэша Azure для Redis.