Устранение неполадок с возможностью подключения
В этой статье рассказывается, как устранять неполадки, связанные с подключением клиентского приложения к Кэшу 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.
Дополнительные сведения см. в разделе:
- Миграция из кэша внедрения виртуальной сети в кэши приватных каналов
- Что такое Кэш Azure для Redis с Приватный канал Azure?
Геоза реплика кэширования в виртуальных сетями поддерживается с помощью следующих предостережениях:
- Георепликация между кэшами в одной виртуальной сети поддерживается.
- Также поддерживается георепликация между кэшами в разных виртуальных сетях.
- Если виртуальные сети находятся в одном регионе, их можно подключить с помощью пиринга виртуальных сетей или подключения типа «виртуальная сеть — виртуальная сеть» через VPN-шлюз.
- Если виртуальные сети находятся в разных регионах, гео-реплика tion с использованием пиринга виртуальной сети не поддерживается. Клиентская виртуальная машина в виртуальной сети 1 (регион 1) не сможет получить доступ к кэшу в виртуальной сети 2 (регион 2) по DNS-имени из-за ограничения базовых внутренних подсистем балансировки нагрузки. Дополнительные сведения об ограничениях пиринга виртуальных сетей см. здесь: Виртуальная сеть — пиринг — требования и ограничения. Рекомендуется использовать подключения типа "виртуальная сеть — виртуальная сеть" через VPN-шлюз.
Чтобы эффективно настроить виртуальную сеть и избежать проблем с георепликацией, необходимо правильно настроить как входящие, так и исходящие порты. Дополнительные сведения о том, как избежать наиболее распространенных проблем с неправильной настройкой виртуальной сети, см. в статье Требования к порту однорангового узла георепликации.
См. также
В этих статьях содержатся дополнительные сведения о подключении и устойчивости: