Настройка активной георепликации для экземпляров Redis под управлением Azure (предварительной версии)
Из этой статьи вы узнаете, как настроить кэш с активной георепликацией с помощью портала Azure.
При активной георепликации до пяти экземпляров Redis под управлением Azure (предварительной версии) группируются в один кэш, охватывающий несколько регионов Azure. Все экземпляры действуют как локальные первичные кэши. Приложение определяет, какие экземпляры следует использовать для запросов на чтение и запись.
Примечание.
Плата за передачу данных между регионами Azure будет взиматься по стандартному тарифу на пропускную способность.
Как работает активная георепликация
Активная георепликация использует реплицированные типы данных без конфликтов (CRDTs) для бесшовного распределения данных между экземплярами Redis, которые можно распределять по континентам. Эти экземпляры подключены в конфигурации active-active, где записи в один экземпляр автоматически отражаются в других экземплярах в той же группе георепликации. Эта двунаправленная репликация данных отличается от подходов к однонаправленной активно-пассивной репликации, где данные реплицируются от первичной в геореплику, но не от другого направления. Это мощный инструмент, который часто используется несколькими способами:
Предоставление локальной задержки путем распространения кэширования ближе к пользователям. Используя сеть активных геореплицированных экземпляров Redis, вы можете размещать кэши географически ближе к пользователям в каждом регионе, уменьшая задержку и повышая производительность приложения.
Синхронизация глобальных приложений. Так как геореплицированные кэши отображаются как один экземпляр Redis, вы можете глобально распределять данные без необходимости сегментировать данные по регионам. Например, можно использовать один отсортированный набор Redis для предоставления игровой таблицы лидеров для всех пользователей по всему миру, а не для отдельного списка лидеров для каждого географического региона.
Сокращение простоя и риска от региональных сбоев. Так как каждый экземпляр Redis в группе георепликации постоянно обновляется с последними данными из других экземпляров в группе, данные хорошо сохраняются во время регионального сбоя. Приложения могут временно переключаться на использование одного из других экземпляров в группе, и когда регион возвращается в режим "в сети", экземпляр Redis автоматически перезагружается с данными из других геореплицированных кэшей.
Более подробную информацию о том, как работает активная георепликация, см. в разделе "Геораспространения Active-Active" (на основе CRDTS)
Область доступности
| Уровень | Оптимизированный для памяти, сбалансированный, оптимизированный для вычислений | Оптимизированный для флэш-памяти |
|---|---|---|
| На месте | Да (кроме B0 и B1) | Да |
Внимание
SKU Balanced B0 и B1 не поддерживают активную георепликацию.
Условия для использования активной георепликации
Активная георепликация имеет ряд ограничений:
Активная георепликация поддерживается только в том случае, если Управляемый Redis Azure находится в конфигурации высокой доступности, то есть использует репликацию.
Поддерживаются только модули RediSearch и RedisJSON
На уровне Оптимизированный для флэш-памяти можно использовать только вариант политики вытеснения Без вытеснения. Все политики вытеснения поддерживаются на других уровнях.
Постоянное хранение данных не поддерживается, так как активная георепликация настолько эффективна, что этого не требуется.
У всех кэшей, входящих в группе георепликации, должна совпадать конфигурация. Например, у всех кэшей должны совпадать SKU, емкость, политика вытеснения и кластеризации, модули и настройки TLS.
Если один экземпляр в группе георепликации масштабируется, другие экземпляры в этой группе должны масштабироваться до того же размера, прежде чем может произойти любое другое масштабирование. Подробнее см. в разделе Масштабирование экземпляров в группе георепликации.
При использовании активной георепликации нельзя использовать команды Redis
FLUSHALLиFLUSHDB. Запрет на использование команд предотвращает непреднамеренное удаление данных. Вместо них следует использовать операцию очистки.
Создание или присоединение группы активной георепликации
При создании нового ресурса Redis под управлением Azure выберите вкладку Дополнительно. Заполните первую часть формы, включая политику кластеризации. Дополнительные сведения о выборе политики кластеризации см. в разделе Кластеризация в Redis под управлением Azure.
Нажмите кнопку Настроить, чтобы настроить активную георепликацию.
Создайте новую группу репликации для первого экземпляра кэша. Или выберите существующую из списка.
Нажмите кнопку Настроить, чтобы завершить процесс.
Дождитесь успешного создания первого кэша. После завершения вы увидите Настроено для Активной георепликации. Повторите описанные выше шаги для каждого экземпляра кэша в группе георепликации.
Добавление существующего экземпляра в активную группу георепликации
Чтобы добавить существующий экземпляр кэша в активную группу георепликации, вы можете принудительно установить связь с помощью REST API.
Все данные в связанном экземпляре кэша удаляются. Экземпляр также временно недоступен в течение нескольких минут при присоединении к группе георепликации. Поддержка портала и интерфейса командной строки пока недоступна для этой функции.
Удаление из группы активной георепликации
Чтобы удалить экземпляр кэша из группы активной георепликации, просто удалите его. Остальные экземпляры затем будут автоматически перенастроены.
Принудительная отмена связи в случае сбоя региона
Активная георепликация — это эффективная функция повышения доступности при использовании Redis под управлением Azure. Но в случае регионального сбоя вам необходимо выполнить определенные инструкции для подготовки кэшей.
Например, следуйте этим советам:
Заранее определите, на какой кэш в группе георепликации вы будете переключаться при сбое региона.
Убедитесь, что настройки брандмауэров позволяют любым приложениям и клиентам получать доступ к выбранному кэшу для резервного копирования.
У каждого кэша, состоящего в группе георепликации, есть собственный ключ доступа. Определите, как приложение переключается на разные ключи доступа при выборе кэша для резервного копирования.
В случае сбоя одного кэша, состоящего в группе георепликации, во всех кэшах, входящих в эту группу, начинается сборка данных. Пока записи не синхронизированы со всеми кэшами, метаданные невозможно удалить. Чтобы заранее отменить сборку метаданных, вы можете принудительно отменить привязку кэша, в котором произошел сбой. Рассмотрите возможность отслеживать доступную память в кэше и отменить привязку при нехватке памяти, особенно при выполнении рабочих нагрузок, предполагающих большее количество операций записи.
Кроме того, можно использовать шаблон автоматического выключения. Используйте этот шаблон, чтобы автоматически перенаправлять трафик из кэша с региональным сбоем в кэш для резервного копирования, входящий в ту же группу георепликации. Для перенаправления используйте такие службы Azure, как Диспетчер трафика Azure или Балансировщик нагрузки шлюза.
Если один из кэшей в группе репликации недоступен из-за сбоя региона, можно принудительно удалить недоступный кэш из группы репликации.
Необходимо удалить недоступный кэш, так как оставшиеся кэши в группе репликации начинают хранить метаданные, которые не были общими для недоступного кэша. В подобном случае доступные кэши в группе репликации могут столкнуться с нехваткой памяти.
Перейдите на портал Azure и выберите в группе репликации один из доступных кэшей.
В меню ресурсов слева выберите Активная георепликация, чтобы просмотреть параметры в рабочей области.
Выберите кэш, связь с которым требуется принудительно отменить, установив флажок.
Выберите Принудительная отмена связи и нажмите ОК для подтверждения.
Когда доступность региона восстановится, нужно будет удалить его кэш и повторно создать его, чтобы снова добавить в группу репликации.
Настройка активной георепликации с помощью Azure CLI или PowerShell
Azure CLI
Azure CLI позволяет создать кэш и группу георепликации или добавить новый кэш в существующую группу георепликации. Дополнительные сведения см. в разделе az redisenterprise create.
Создание нового экземпляра Redis под управлением Azure в новой группе георепликации с помощью Azure CLI
В этом примере создается новый сбалансированный экземпляр Redis под управлением Azure B10 под названием Cache1 в регионе "Восточная часть США". Затем кэш добавляется в новую группу активной георепликации replicationGroup:
az redisenterprise create --location "East US" --cluster-name "Cache1" --sku "Balanced_B10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"
Чтобы правильно настроить активную георепликацию, добавьте идентификатор создаваемого экземпляра кэша с параметром --linked-databases. Идентификатор имеет следующий формат.
/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default
Создание нового экземпляра Redis под управлением Azure в существующей группе георепликации с помощью Azure CLI
В этом примере создается новый сбалансированный экземпляр кэша B10 под названием Cache2 в регионе "Западная часть США". Затем скрипт добавляет этот кэш в активную группу георепликации replicationGroup, которая была создана в рамках предыдущей процедуры. Таким образом, он связан в конфигурации "активный — активный" с Cache1.
az redisenterprise create --location "West US" --cluster-name "Cache2" --sku "Balanced_B10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"
Как и ранее, необходимо перечислить Cache1 и Cache2 с использованием параметра --linked-databases.
Azure PowerShell
PowerShell позволяет создать кэш и группу георепликации или добавить новый кэш в существующую группу георепликации. Дополнительные сведения см. в статье New-AzRedisEnterpriseCache.
Создание нового экземпляра Redis под управлением Azure в новой группе георепликации с помощью PowerShell
В этом примере создается новый сбалансированный экземпляр кэша Redis под управлением Azure B10 под названием Cache1 в регионе "Восточная часть США". Затем кэш добавляется в новую группу активной георепликации replicationGroup:
New-AzRedisEnterpriseCache -Name "Cache1" -ResourceGroupName "myResourceGroup" -Location "East US" -Sku "Balanced_B10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}'
Чтобы правильно настроить активную георепликацию, добавьте идентификатор создаваемого экземпляра кэша с параметром -LinkedDatabase. Идентификатор имеет следующий формат.
/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default
Создание нового экземпляра Redis под управлением Azure в существующей группе георепликации с помощью PowerShell
В этом примере создается новый сбалансированный экземпляр кэша B10 под названием Cache2 в регионе "Западная часть США". Затем скрипт добавляет кэш в активную группу георепликации, репликациюGroup, созданную в предыдущей процедуре. В результате мы получаем два кэша, Cache1 и Cache2, которые связаны в конфигурации "активный — активный".
New-AzRedisEnterpriseCache -Name "Cache2" -ResourceGroupName "myResourceGroup" -Location "West US" -Sku "Balanced_B10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}', '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"}'
Как и ранее, необходимо перечислить Cache1 и Cache2 с использованием параметра -LinkedDatabase.
Масштабирование экземпляров в группе георепликации
Можно масштабировать экземпляры, настроенные для использования активной георепликации. Однако у вас могут возникнуть проблемы, если в одну группу георепликации будут входить кэши разного размера. Чтобы их предотвратить, проследите за тем, чтобы все кэши, входящие в одну группу георепликации, были одного размера и относились к одному и тому же уровню производительности.
Так как масштабирование требует изменения размера или уровня, и сложно одновременно масштабировать все экземпляры в группе георепликации, Управляемый Redis Azure имеет механизм блокировки. При масштабировании одного экземпляра в группе георепликации базовая виртуальная машина масштабируется, но доступная память ограничена исходным размером, пока другие экземпляры не будут масштабироваться. Кроме того, прочие операции масштабирования в отношении всех остальных экземпляров будут заблокированы до тех пор, пока их конфигурация не будет совпадать с конфигурацией первого масштабированного кэша.
Пример масштабирования
Например, в группе георепликации может быть три экземпляра, все экземпляры, оптимизированные для памяти M10:
| Имя экземпляра | Redis00 | Redis01 | Redis02 |
|---|---|---|---|
| Тип | Оптимизированный для операций в памяти экземпляр M10 | Оптимизированный для операций в памяти экземпляр M10 | Оптимизированный для операций в памяти экземпляр M10 |
Предположим, вы хотите масштабировать каждый экземпляр из этой группы георепликации до оптимизированного для вычислений экземпляра X20. Сначала вы масштабируете один из кэшей до X20:
| Имя экземпляра | Redis00 | Redis01 | Redis02 |
|---|---|---|---|
| Тип | Оптимизированный для вычислений экземпляр X20 | Оптимизированный для операций в памяти экземпляр M10 | Оптимизированный для операций в памяти экземпляр M10 |
На этом этапе экземпляры Redis01 и Redis02 можно масштабировать только до оптимизированного для вычислений экземпляра X20. Все прочие операции масштабирования заблокированы.
Примечание.
Экземпляр Redis00 не блокирует масштабирование дальше на этом этапе. Но он блокируется один раз Redis01 или Redis02 масштабируется, чтобы быть оптимизированным для вычислений X20.
После масштабирования каждого экземпляра до одного уровня и размера все блокировки масштабирования удаляются:
| Имя экземпляра | Redis00 | Redis01 | Redis02 |
|---|---|---|---|
| Тип | Оптимизированный для вычислений экземпляр X20 | Оптимизированный для вычислений экземпляр X20 | Оптимизированный для вычислений экземпляр X20 |
Операция очистки
Из-за непреднамеренной потери данных команды Redis FLUSHALL и FLUSHDB невозможно применить ни к каким экземплярам кэша, которые находятся в группе георепликации. Вместо этого нажмите кнопку Очистить кэш(и) в верхней части рабочей области Активная георепликация.
Метрика георепликации
Метрика "Работоспособность георепликации" в Управляемом Redis azure помогает отслеживать работоспособность геореплицированных кластеров. Эта метрика используется для отслеживания состояния синхронизации между георепликами.
Чтобы отслеживать метрику "Работоспособность георепликации" в портал Azure, выполните следующие действия.
Откройте портал Azure и выберите экземпляр Управляемого Redis в Azure.
В меню "Ресурс" выберите метрики в разделе "Мониторинг ".
Выберите "Добавить метрику" и выберите метрику "Работоспособность георепликации".
При необходимости примените фильтры для определенных геореплик.
Вы можете настроить оповещение, чтобы уведомить вас о том, что метрика "Георепликация работоспособной " выдает неработоспособное значение (0) непрерывно в течение более 60 минут.
Выберите Новое правило генерации оповещений.
Определите условие для активации, если значение метрики равно 0 не менее 60 минут, рекомендуемое время.
Добавьте группы действий для уведомлений, например электронной почты, SMS и других.
Сохраните оповещение.
Дополнительные сведения о настройке оповещений для кэша Redis Enterprise см. в разделе "Мониторинг кэшей Redis".
Внимание
Эта метрика может временно отображаться как неработоспособная из-за обычных операций, таких как события обслуживания или масштабирование, инициированные Azure или клиентом. Чтобы избежать ложных предупреждений, рекомендуется настроить окно наблюдения в течение 60 минут, где метрика продолжает оставаться неработоспособной в качестве соответствующего времени для создания оповещения, так как это может указывать на проблему, требующую вмешательства.
Распространенные проблемы на стороне клиента, которые могут вызвать проблемы синхронизации между георепликами
Использование пользовательских хэштегов — использование пользовательских хэштегов в Redis может привести к неравномерному распределению данных между сегментами, что может привести к проблемам с производительностью и синхронизацией в георепликах, поэтому не используйте пользовательские хэштеги, если база данных не должна выполнять несколько ключевых операций.
Большой размер ключа. Большие ключи могут создавать проблемы синхронизации между георепликами. Чтобы обеспечить плавную производительность и надежную репликацию, рекомендуется сохранить размеры ключей до 500 МБ при использовании георепликации. Если размер отдельного ключа приближается к 2 ГБ, кэш сталкивается с проблемами с работоспособностью георепликации.
Очистка кэшей с помощью Azure CLI или PowerShell
Чтобы активировать операцию очистки, можно также воспользоваться Azure CLI и PowerShell. Подробнее о применении Azure CLI см. в статье о az redisenterprise database flush. Подробнее о применении PowerShell см. в статье об Invoke-AzRedisEnterpriseCacheDatabaseFlush.
Внимание
При использовании функции Очистка кэшей соблюдайте осторожность. Если нажать на эту кнопку, будут удалены все данные, которые содержатся в текущем кэше и во ВСЕХ связанных с ним кэшах из соответствующей группы георепликации.
Для управления доступом к этой функции воспользуйтесь функцией Управление доступом на основе ролей Azure. Доступ к функции очистки всех кэшей следует предоставлять только авторизованным пользователям.