Надежность в Azure Managed Redis

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

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

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

Рекомендации по развертыванию в производственной среде

Чтобы обеспечить высокую надежность для рабочих экземпляров Redis в Azure, рекомендуется:

• Используйте высокий уровень доступности, который развертывает несколько узлов для кэша.

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

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

Обзор архитектуры надежности

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

Логическая архитектура

Управляемый Redis Azure основан на Redis Enterprise и обеспечивает надежность с помощью конфигураций высокой доступности и возможностей репликации.

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

Физическая архитектура

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

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

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

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

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

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

Устойчивость к временным сбоям

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

Все облачные приложения должны следовать рекомендациям по обработке временных ошибок Azure при обмене данными с любыми размещенными в облаке API, базами данных и другими компонентами. Дополнительные сведения см. в Рекомендациях по обработке временных сбоев.

Следуйте этим рекомендациям по управлению временными сбоями при использовании Управляемого Redis в Azure:

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

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

Устойчивость к сбоям зоны доступности

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

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

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

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

Схема с управляемым экземпляром Redis в Azure с высокой доступностью в двух зонах доступности. Раздел управляемого экземпляра Redis в Azure распространяется на все три зоны. Зоны 1 и 2 имеют один узел, а зона 3 не имеет узлов.

Требования

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

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

• Уровней: Все уровни Управляемого Redis Azure поддерживают зоны доступности.

Себестоимость

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

Настройка поддержки зоны доступности

• Создайте зонально-избыточный экземпляр. При создании нового экземпляра Управляемого Redis в Azure используйте конфигурацию высокой доступности и разверните ее в регионе, поддерживающем зоны доступности. Экземпляр включает резервирование зон по умолчанию, без необходимости дополнительной настройки.

  Дополнительные сведения см. в разделе «Создание экземпляра Управляемого Azure Redis».

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

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

Планирование ресурсов и управление ими

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

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

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

Поведение, когда все зоны работоспособны

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

• Маршрутизация трафика между зонами: Управляемый Redis Azure распределяет сегменты между узлами на основе политики кластера. Политика кластера также определяет, как маршрутизируется трафик к каждому узлу. Избыточность зоны не изменяет способ, которым сервис маршрутизирует трафик.

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

Поведение во время сбоя зоны

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

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

• Уведомление: Корпорация Майкрософт не уведомляет вас об отключении зоны. Однако вы можете использовать службу "Работоспособность служб Azure ", чтобы понять общую работоспособность службы, включая все сбои зоны, и вы можете настроить оповещения о работоспособности служб , чтобы уведомить вас о проблемах.

• Активные запросы: Служба может удалить запросы на полет, и приложения должны повторить их. Приложения должны реализовать логику повторных попыток для обработки этих временных прерываний.

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

• Ожидаемое время простоя: Небольшое время простоя, как правило 10–15 секунд, может возникнуть при переключении сегментов на узлы в работоспособных зонах. Для получения дополнительной информации о процессе незапланированного переключения на резервный узел см. в разделе "Объяснение переключений на резервный узел". При разработке приложений следуйте рекомендациям по обработке временных ошибок.

• Перенаправка трафика: Управляемый Redis Azure автоматически перенаправляет трафик на узлы в здоровых зонах.

Восстановление зоны

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

Тестирование на сбои в зоне

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

Устойчивость к сбоям на уровне региона

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

Активная георепликация

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

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

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

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

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

Требования

• Поддержка региона: Вы можете настроить активную георепликацию Azure Managed Redis между любыми регионами Azure, где доступна служба.

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

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

Соображения

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

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

Себестоимость

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

Настройка поддержки нескольких регионов

• Создайте экземпляр геореплицированного кэша. Настройте активную георепликацию при подготовке кэша, указав группу репликации и связав несколько экземпляров. Дополнительные сведения см. в разделе "Создание или присоединение активной группы георепликации".

• Добавьте существующий экземпляр кэша в группу георепликации. Существующий экземпляр кэша можно добавить в активную группу георепликации.

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

  Дополнительные сведения см. в разделе "Добавление существующего экземпляра в активную группу георепликации".

• Отключите георепликацию в экземпляре кэша. Удалите экземпляр из группы георепликации, удалив экземпляр кэша. Остальные экземпляры автоматически настраивают свои параметры.

Планирование ресурсов и управление ими

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

Поведение, когда все регионы работоспособны

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

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

• Репликация данных между регионами: Служба использует асинхронную репликацию между регионами для обеспечения конечной согласованности. Он немедленно фиксирует операции записи в локальном регионе, а затем распространяет их на другие регионы в фоновом режиме. Реплицируемые типы данных без конфликтов (CRDTs) гарантируют, что служба автоматически объединяет одновременные записи в разных регионах.

Поведение во время сбоя региона

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

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

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

• Уведомления: Корпорация Майкрософт не уведомляет вас об отключении региона автоматически. Однако вы можете использовать службу "Работоспособность служб Azure ", чтобы понять общую работоспособность службы, в том числе сбои в любом регионе, и вы можете настроить оповещения о работоспособности служб , чтобы уведомить вас о проблемах.

  Вы также можете отслеживать состояние каждого экземпляра.

  Чтобы отслеживать работоспособность связи георепликации, используйте метрику здоровья георепликации. Метрика всегда имеет значение 1 (работоспособно) или 0 (неработоспособно). Настройте оповещения Azure Monitor для этой метрики, чтобы определить, когда экземпляры могут быть не синхронизированы.

• Активные запросы: Служба завершает запросы к региону сбоя, а логика восстановления после отказа приложения должна обрабатывать их. Приложения должны реализовывать политики повторных попыток, которые могут перенаправлять трафик в здоровые кэши.

• Ожидаемая потеря данных: Асинхронная репликация между регионами может привести к потере последних записей в неудавшихся регионах, если эти записи не реплицировались в другие регионы. Объем потенциальной потери данных зависит от задержки репликации во время сбоя. Дополнительные сведения см. в разделе "Активный—активный" геораспределенный Redisи рекомендации по обеспечению согласованности и потери данных в региональном сбое реплицированной базы данных (CRDB).

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

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

Восстановление региона

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

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

Проверка сбоев в регионе

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

Устойчивость к обслуживанию служб

Управляемый Redis Azure обрабатывает регулярные обновления служб и другие задачи обслуживания.

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

Дополнительные сведения о процессах обслуживания Azure Managed Redis см. в статье "Отработка отказов и обновление для Azure Managed Redis".

Резервное копирование и восстановление

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

• Сохраняемость данных: По умолчанию Управляемый Redis Azure сохраняет все данные кэша в памяти. Служба может при необходимости записывать моментальные снимки данных на диск с помощью сохраняемости данных. Если сбой оборудования влияет на узел, Azure Managed Redis автоматически восстанавливает данные. Вы можете выбрать разные типы сохраняемости данных, которые обеспечивают различные компромиссы между частотой моментальных снимков и последствиями производительности в кэше.

  Невозможно восстановить файлы данных в другом экземпляре, и вы не сможете получить доступ к файлам. Сохраняемость данных не защищает вас от повреждения или случайного удаления данных.

• Импорт и экспорт: Управляемый Redis Azure поддерживает резервное копирование данных при использовании функции импорта и экспорта, которая сохраняет файлы резервного копирования в хранилище BLOB-объектов Azure. Вы можете настроить геоизбыточное хранилище (GRS) в учетной записи Azure Storage в поддерживаемых регионах, или скопировать либо переместить резервные двоичные объекты (блобы) в другие расположения для дальнейшей защиты.

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

  Служба не включает встроенный планировщик импорта или экспорта, но вы можете разрабатывать собственные процессы автоматизации, использующие Azure CLI или Azure PowerShell для запуска операций экспорта.

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Для получения дополнительной информации см. Соглашения об уровне обслуживания для онлайн-сервисов.

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

Чтобы претендовать на соглашения об уровне доступности для Управляемого Redis на платформе Azure, необходимо выполнить следующие требования:

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

• Вы не должны инициировать какие-либо функции продукта или действия управления, которые документируются для создания временной недоступности.

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

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

• Надежность в Azure