Устранение неполадок с возможностью подключения

Статья
12/16/2023

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

Проблемы с прерывающимся подключением
Постоянные проблемы с подключением
Гео реплика с помощью внедрения виртуальных сетей с кэшами Premium

Проблемы с прерывающимся подключением

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

обслуживание сервера;

Кэш может проходить плановое или внеплановое обслуживание сервера. Во время обслуживания работа вашего приложения может быть нарушена. Это можно проверить с помощью метрики Errors (Type: Failover) на портале. Сведения о том, как минимизировать последствия отработки отказа, см. в разделе Устойчивость подключения.

Количество подключенных клиентов

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

Приложения, размещенные в Kubernetes

Если ваше клиентское приложение размещено в Kubernetes, убедитесь, что модуль, на котором выполняется клиентское приложение, или узлы кластера не ограничены в ресурсах памяти, ЦП или сети. Модуль pod, в котором работает клиентское приложение, может подвергаться воздействию других модулей pod, выполняемых в том же узле, и ограничивать подключения Redis или операции ввода-вывода.
Если вы используете Istio или другую сетку служб, убедитесь, что прокси-сервер сетки служб резервирует порты 13000-13019 или 15000-15019. Эти порты используются клиентами для обмена данными с кластерными узлами Кэша Azure для Redis и могут вызвать проблемы с подключением к этим портам.

Клиентское приложение на основе Linux

Использование оптимистичных параметров TCP в Linux может вызывать проблемы с подключением к клиентским приложениям. См. раздел Сбои подключений достигают 15 минут.

Постоянное подключение

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

Проверка подключения с помощью redis-cli

Проверка подключения с помощью redis-cli. Для получения дополнительных сведений о CLI используйте программу командной строки Redis с Кэшем Azure для Redis.

Проверка подключения с помощью PSPING

Если подключиться к redis-cli не удается, воспользуйтесь для проверки подключения PSPING в PowerShell.

psping -q <cache DNS endpoint>:<Port Number>

Убедитесь, что количество отправленных пакетов равно количеству полученных. Подтверждение предотвращает отказ подключения.

Конфигурация виртуальной сети

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

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

Конфигурация частной конечной точки

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

Флаг Public Network Access при создании частной конечной точки по умолчанию отключен. Убедитесь, что значение Public Network Access указано правильно. Если ваш кэш находится на портале Azure, в меню ресурсов слева от этого параметра найдите пункт Частная конечная точка.
Если вам нужно подключиться к частной конечной точке кэша не из виртуальной сети своего кэша, необходимо включить Public Network Access.
Если вы удалили свою частную конечную точку, убедитесь, что доступ к общедоступной сети включен.
Убедитесь, что частная конечная точка настроена правильно. Дополнительные сведения см. в разделе Создание частной конечной точки с новым экземпляром Кэша Azure для Redis.
Проверьте, подключено ли приложение к <cachename>.redis.cache.windows.net порта 6380. Рекомендуется избегать использования <cachename>.privatelink.redis.cache.windows.net в конфигурации или строке подключения.
Выполните команду nslookup <hostname> в виртуальной сети, связанной с частной конечной точкой, чтобы убедиться, что команда разрешается в частный IP-адрес кэша.

Правила брандмауэра

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

Сторонний брандмауэр или внешний прокси-сервер

Если в вашей сети используется сторонний брандмауэр или прокси-сервер, убедитесь, что конечная точка для Кэша Azure для Redis, *.redis.cache.windows.net, а также порты 6379 и 6380 разрешены. Возможно, при использовании кластеризованного кэша или георепликации нужно будет разрешить больше портов.

Изменение общедоступного IP-адреса

Если вы настроили какой-либо сетевой ресурс или ресурс безопасности для использования общедоступного IP-адреса кэша, проверьте, изменился ли общедоступный IP-адрес кэша. Дополнительные сведения см. в статье Используйте имя узла, а не общедоступный IP-адрес для кэша.

Гео реплика с помощью внедрения виртуальных сетей с кэшами Premium

Хотя можно использовать внедрение виртуальных сетей с кэшами класса Premium, рекомендуется Приватный канал Azure.

Дополнительные сведения см. в разделе:

Геоза реплика кэширования в виртуальных сетями поддерживается с помощью следующих предостережениях:

Георепликация между кэшами в одной виртуальной сети поддерживается.
Также поддерживается георепликация между кэшами в разных виртуальных сетях.
- Если виртуальные сети находятся в одном регионе, их можно подключить с помощью пиринга виртуальных сетей или подключения типа «виртуальная сеть — виртуальная сеть» через VPN-шлюз.
- Если виртуальные сети находятся в разных регионах, гео-реплика tion с использованием пиринга виртуальной сети не поддерживается. Клиентская виртуальная машина в виртуальной сети 1 (регион 1) не сможет получить доступ к кэшу в виртуальной сети 2 (регион 2) по DNS-имени из-за ограничения базовых внутренних подсистем балансировки нагрузки. Дополнительные сведения об ограничениях пиринга виртуальных сетей см. здесь: Виртуальная сеть — пиринг — требования и ограничения. Рекомендуется использовать подключения типа "виртуальная сеть — виртуальная сеть" через VPN-шлюз.

Чтобы эффективно настроить виртуальную сеть и избежать проблем с георепликацией, необходимо правильно настроить как входящие, так и исходящие порты. Дополнительные сведения о том, как избежать наиболее распространенных проблем с неправильной настройкой виртуальной сети, см. в статье Требования к порту однорангового узла георепликации.

В этих статьях содержатся дополнительные сведения о подключении и устойчивости: