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

Переключение на резервную систему и патчинг для кэша Azure для Redis

  • Применимо к: ✅ Azure Cache for Redis

Это важно

Кэш Azure для Redis объявил о графике вывода из эксплуатации для всех SKU. Мы рекомендуем переместить существующие экземпляры кэша для Redis в Azure Managed Redis как можно скорее.

Дополнительные сведения о выходе на пенсию:

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

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

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

Что такое резервное переключение?

Начнем с обзора резервного переключения для Azure Cache for Redis.

Краткая сводка по архитектуре кэша

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

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

Замечание

Базовый кэш не имеет нескольких узлов и не предлагает соглашение об уровне обслуживания (SLA) для его доступности. Базовые кэши рекомендуется использовать только для целей разработки и тестирования. Используйте кэш уровня "Стандартный" или "Премиум" для развертывания с несколькими узлами для повышения доступности.

Объяснение аварийного переключения

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

Плановое переключение происходит в два разных времени:

  • Обновления системы, такие как исправление Redis или обновления ОС.
  • Операции управления, такие как масштабирование и перезагрузка.

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

Незапланированное переключение при отказе может произойти из-за сбоя оборудования или сети, либо других непредвиденных отказов на главном узле. Узел реплики переходит в состояние основного, но этот процесс занимает больше времени. Узел реплики должен сначала обнаружить, что его основной узел недоступен, прежде чем он сможет начать процесс переключения на резервный узел. "Узел реплики также должен убедиться, что этот незапланированный сбой не является временным или локализованным, чтобы избежать ненужного переключения на резерв." Эта задержка в обнаружении означает, что незапланированная отработка отказа обычно завершается в течение от 10 до 15 секунд.

Как происходит исправление?

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

  1. Служба сначала исправляет узел реплики.
  2. Обновлённая реплика самостоятельно повышается до основной. Эта операция считается плановым переключением.
  3. Бывший первичный узел перезагружается, чтобы принять новые изменения и снова начинает работать как узел реплики.
  4. Узел реплики подключается к основному узлу и синхронизирует данные.
  5. После завершения синхронизации данных процесс исправления повторяется для оставшихся узлов.

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

Это важно

Узлы исправляются по одному за раз, чтобы предотвратить потерю данных. Базовые кэши будут иметь потерю данных. Кластеризованные кэши за раз исправляются по одному сегменту.

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

Так как полная синхронизация данных происходит до повторения процесса, потеря данных вряд ли произойдет при использовании кэша уровня "Стандартный" или "Премиум". Кроме того, вы можете защититься от потери данных, экспортируя данные и обеспечивая сохраняемость.

Дополнительная загрузка кэша

Каждый раз, когда происходит сбой, стандартный и премиум-кеши должны реплицировать данные с одного узла на другой. Эта репликация приводит к увеличению нагрузки как в памяти сервера, так и на ЦП. Если экземпляр кэша уже загружен, клиентские приложения могут столкнуться с повышенной задержкой. В крайних случаях клиентские приложения могут получать исключения времени ожидания. Чтобы снизить влияние дополнительной нагрузки, настройте параметр кэша maxmemory-reserved .

Как переключение на резерв влияет на мое клиентское приложение?

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

Многие клиентские библиотеки могут вызывать различные типы ошибок при разрыве подключений, в том числе:

  • Исключения времени ожидания
  • Исключения подключений
  • Исключения сокетов

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

Большинство клиентских библиотек пытаются повторно подключиться к кэшу, если они настроены для этого. Однако непредвиденные ошибки иногда могут поместить объекты библиотеки в неустранимое состояние. Если ошибки сохраняются дольше, чем предварительно настроенное время, необходимо повторно создать объект подключения. В Microsoft.NET и других объектно-ориентированных языках повторное подключение без перезапуска приложения можно выполнить с помощью шаблона ForceReconnect.

Можно ли получать уведомления до обслуживания?

Кэш Azure для Redis публикует уведомления о техническом обслуживании во время выполнения в канале публикации и подписки (pub/sub) AzureRedisEvents. Многие популярные клиентские библиотеки Redis поддерживают подписку на каналы pub/sub. Получение уведомлений из AzureRedisEvents канала обычно является простым дополнением к клиентскому приложению. Дополнительные сведения о событиях обслуживания см. в статье AzureRedisEvents.

Замечание

Канал AzureRedisEvents не является механизмом, который может уведомлять за дни или часы до события. Канал может уведомлять клиентов о любых предстоящих событиях обслуживания сервера, которые могут повлиять на доступность сервера. AzureRedisEvents доступно только для уровней "Базовый", "Стандартный" и "Премиум".

Какие обновления включены в обслуживание?

Обслуживание включает следующие обновления:

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

Отображается ли обслуживание в работоспособности службы на портале Azure перед исправлением?

Нет, обслуживание не отображается нигде под работоспособностью службы на портале или в другом месте.

Сколько времени можно получить уведомление до планового обслуживания?

При использовании AzureRedisEvents канала вы получите уведомление через 15 минут до обслуживания.

Изменения конфигурации сети клиента

Некоторые изменения конфигурации сети на стороне клиента могут вызвать ошибку Нет подключения. Такие изменения могут включать:

  • Переключение виртуального IP-адреса клиентского приложения между тестовыми и рабочими слотами.
  • Масштабирование размера или количества экземпляров приложения.

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

Создание устойчивости

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

Как сделать приложение устойчивым?

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

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

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

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

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

  • Last updated on