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

Отработка отказа и исправление для Управляемого Redis в Azure (предварительная версия)

  • Статья

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

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

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

Что такое отработка отказа?

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

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

Схема, показывающая архитектуру предложения Управляемого Redis в Azure.

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

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

Процедура отработки отказа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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