Переключение на резервный сервер и обновление исправлений для Azure Managed Redis

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

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

• Что такое переключение при отказе?
• Как осуществляется переключение при установке исправлений.
• Создание отказоустойчивого клиентского приложения.

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

Начнем с обзора переключения при отказе для Azure Managed Redis.

Краткий обзор архитектуры кэша

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

Подробные сведения об архитектуре управляемого Redis Azure можно найти here.

Переключение при отказе

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

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

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

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

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

Как выполняется исправление?

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

1. Служба создает новые актуальные виртуальные машины для замены всех виртуальных машин, которые исправляются.
2. Затем он продвигает одну из новых виртуальных машин в качестве лидера кластера.
3. Поочерёдно все узлы, которые обновляются, удаляются из кластера. Любые сегменты на этих виртуальных машинах будут переведены в пониженный статус и перемещены на одну из новых виртуальных машин.
4. Наконец, удаляются все виртуальные машины, которые были заменены.

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы узнать о журнале обслуживания на портале Azure, проверьте журнал Azure Activity log для экземпляра кэша. Событие "healthevent" срабатывает при начале обслуживания.

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

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

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

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

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

Встроенная отказоустойчивость

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

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

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

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

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

• Устойчивость соединения