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

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

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

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

Настройка виртуальной сети

Ознакомьтесь с az redis create.

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

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

• Каковы некоторые распространенные проблемы с неправильной настройкой Кэш Azure для Redis и виртуальных сетей?
• Как проверить, что кэш работает в виртуальной сети?
• Когда я пытаюсь подключиться к экземпляру Azure Cache для Redis в виртуальной сети, почему возникает ошибка с сообщением о недействительном удаленном сертификате?
• Можно ли использовать виртуальные сети с кэшем ценовой категории "Стандартный" или "Базовый"?
• Почему создание экземпляра кэша Azure для Redis завершается неудачей в некоторых подсетях, но не в других?
• Каковы требования к адресному пространству подсети?
• Можно ли подключиться к кэшу из одноранговой виртуальной сети?
• Поддерживается ли внедрение виртуальных сетей в кэше, где включен Azure Lighthouse?
• Работают ли все функции кэша при его размещении в виртуальной сети?
• Поддерживается ли внедрение виртуальных сетей в кэше, где включен Azure Lighthouse?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Выполните команду ping конечной точки кэша, используя порт 6380 с машины, которая находится в той же виртуальной сети, что и кэш, с помощью 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, блокирует исходящие подключения TCP через порт 80 для функций SSL/TLS, клиенты могут столкнуться с периодическими ошибками проверки сертификата TLS.

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

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

Почему в одних подсетях не удается создать Кэш 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 работает в локальном браузере (обычно на компьютере разработчика, который не подключен к виртуальной сети), она не может подключиться к кэшу.

Поддерживается ли VNet-инжекция в кэше, где включен Azure Lighthouse?

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

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

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

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

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

Решение заключается в определении одного или нескольких маршрутов, определяемых пользователем (UDR), в подсети, которая содержит экземпляр кэша Azure для Redis. UDR определяет маршруты, относящиеся к подсети, которые учитываются вместо маршрута по умолчанию.

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

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

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

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

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

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

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

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

• Кэш Azure для уровней обслуживания Redis уровня «Премиум»