Отработка отказа и исправление в службе "Кэш Azure для Redis"

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

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

• Что такое отработка отказа?
• Выполнение отработки отказа во время установки исправлений.
• Создание отказоустойчивого клиентского приложения.

Давайте начнем с краткого обзора службы "Кэш Azure для Redis".

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

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

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

Плановая отработка отказа выполняется в двух случаях:

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

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

Внеплановая отработка отказа может произойти из-за сбоя оборудования, сбоя сети или других непредвиденных сбоев на основном узле. Уровень узла-реплики повышается до основного, однако процесс занимает больше времени. Узел-реплика сначала должен определить, что его основной узел недоступен, прежде чем будет запущен процесс отработки отказа. Узел-реплика также должен убедиться в том, что незапланированный сбой не является временным или локальным, чтобы избежать ненужной отработки отказа. Задержка при обнаружении означает, что внеплановая отработка отказа обычно завершается в течение 10 – 15 секунд.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Шаблоны надежности — конструктивные шаблоны для облака
• Рекомендации по повторным попыткам для служб Azure — рекомендации для облачных приложений
• Реализация повторных попыток с экспоненциальным обратным выходом

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

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

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

• Обновление канала и расписания обновлений
• Тестирование устойчивости приложений с помощью перезагрузки
• Настройка резервирований и политик памяти