Настройка устойчивости данных для экземпляра Azure Cache для Redis

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

Область доступности

Типы сохраняемости данных в Redis

У вас есть два варианта сохранения с Кэш Azure для Redis: формат базы данных Redis (RDB) и формат "Добавить только файл" (AOF):

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

Функции постоянства в кэше Azure для Redis предназначены для автоматического восстановления данных в тот же кэш после потери. Сохраненные файлы данных RDB/AOF нельзя импортировать в новый кэш или существующий кэш. Для перемещения данных между кэшами используйте функцию импорта и экспорта. Дополнительные сведения см. в статье Импорт и экспорт данных в Кэше Azure для Redis.

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

Предварительные требования и ограничения

Функции сохраняемости предназначены для восстановления данных в том же кэше после потери данных.

• Сохраненные файлы данных RDB/AOF не могут быть импортированы в новый или существующий кэш. Вместо этого используйте функцию Импорт/экспорт.
• Сохраняемость не поддерживается с кэшами с использованием пассивной георепликации или активной георепликации.
• На уровне "Премиум" сохраняемость AOF не поддерживается с несколькими репликами.
• На уровне "Премиум" данные должны сохраняться в учетной записи хранения в том же регионе, что и экземпляр кэша.
• На уровне "Премиум" учетные записи хранения в разных подписках можно использовать для сохранения данных, если управляемое удостоверение используется для подключения к учетной записи хранения.

Различия между сохраняемостью на уровнях Premium и Enterprise

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

На уровнях Enterprise и Enterprise Flash данные сохраняются на управляемом диске, подключенном непосредственно к экземпляру кэша. Расположение не настраивается и не доступно пользователю. Использование управляемого диска повышает производительность сохраняемости. Диск шифруется с помощью управляемых майкрософт ключей (MMK) по умолчанию, но также можно использовать управляемые клиентом ключи (CMK). Дополнительные сведения см. в статье Управление шифрованием данных.

Настройка сохраняемости данных с помощью портал Azure

Настройка сохраняемости данных с помощью PowerShell и Azure CLI

New-AzRedisEnterpriseCache -Name "MyCache" -ResourceGroupName "MyGroup" -Location "West US" -Sku "Enterprise_E10" -RdbPersistenceEnabled -RdbPersistenceFrequency "1h"

Update-AzRedisEnterpriseCacheDatabase -Name "MyCache" -ResourceGroupName "MyGroup" -RdbPersistenceEnabled -RdbPersistenceFrequency "12h"

az redis create --location westus2 --name MyRedisCache --resource-group MyResourceGroup --sku Premium --vm-size p1 --redis-configuration @"config_rdb.json"

az redis update --name MyRedisCache --resource-group MyResourceGroup --set "redisConfiguration.rdb-storage-connection-string"="BlobEndpoint=https//..." "redisConfiguration.rdb-backup-enabled"="true" "redisConfiguration.rdb-backup-frequency"="15" "redisConfiguration.rdb-backup-max-snapshot-count"="1"

az redisenterprise create --cluster-name "cache1" --resource-group "rg1" --location "East US" --sku "Enterprise_E10" --persistence rdb-enabled=true rdb-frequency="1h" 

az redisenterprise database update --cluster-name "cache1" --resource-group "rg1" --persistence rdb-enabled=true rdb-frequency="12h" 

Управление шифрованием данных

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

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

С уровнями Enterprise и Enterprise Flash данные хранятся на управляемом диске, подключенном к экземпляру кэша. По умолчанию диск с данными сохраняемости и диск ОС шифруются с помощью ключей, управляемых Корпорацией Майкрософт. Ключ, управляемый клиентом (CMK), также можно использовать для управления шифрованием данных. Инструкции см. в разделе "Шифрование на кэшах корпоративного уровня".

Часто задаваемые вопросы о постоянстве

Следующий список содержит ответы на часто задаваемые вопросы о постоянстве Azure Cache для Redis.

• Можно ли включить постоянное хранение для ранее созданного кэша?
• Можно ли одновременно активировать сохраняемость AOF и RDB?
• Как сохраняемость работает с георепликацией?
• Какую модель сохраняемости следует выбрать?
• Что произойдет, если выполнено масштабирование до другого размера, а резервная копия была создана до этой операции?
• Можно ли использовать одну и ту же учетную запись хранения для сохраняемости данных в двух разных кэшах?
• Будет ли начисляться плата за хранилище, используемое для сохраняемости данных
• Как часто происходит запись RDB и AOF в мои BLOB-объекты, и стоит ли включать мягкое удаление?
• Повлияют ли исключения брандмауэра в учетной записи хранения на сохраняемость
• Как проверить, включено ли мягкое удаление в учетной записи хранения?
• Можно ли использовать учетную запись хранения в другой подписке, отличной от той, в которой находится мой кэш?

Сохраняемость RDB

• Можно ли изменить частоту резервного копирования RDB после создания кэша?
• Почему при установленной частоте резервного копирования RDB в 60 минут между созданием резервных копий проходит больше времени?
• Что происходит со старыми резервными копиями RDB при создании другой?

Сохраняемость AOF

• Когда следует использовать вторичную учетную запись хранения?
• Влияет ли сохраняемость AOF на пропускную способность, задержку или производительность кэша?
• Как удалить вторичную учетную запись хранения?
• Что такое перезапись и как она влияет на кэш?
• Чего ожидать при масштабировании кэша с включенным AOF?
• Как организованы данные AOF в хранилище?
• Можно ли включить сохраняемость AOF, если у меня несколько реплик?

Можно ли включить постоянное хранение для ранее созданного кэша?

Да, сохраняемость можно настроить как при создании кэша, так и в существующих кэшах Premium, Enterprise или Enterprise Flash.

Можно ли одновременно активировать сохраняемость AOF и RDB?

Нет, вы можете включить RDB или AOF, но не оба одновременно.

Как сохраняемость работает с георепликацией?

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

Какую модель сохраняемости следует выбрать?

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

• Узнайте больше о преимуществах и недостатках сохраняемости RDB.
• Узнайте больше о преимуществах и недостатках сохраняемости AOF.

Дополнительные сведения о производительности при использовании постоянного хранения AOF см. в разделе Влияет ли постоянное хранение AOF на пропускную способность, задержку или производительность кэша?

Влияет ли сохраняемость AOF на пропускную способность, задержку или производительность кэша?

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

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

Что произойдет, если выполнено масштабирование на другой размер, а резервная копия, созданная до этой операции, восстановлена?

Для сохраняемости как RDB, так и AOF:

• При увеличении масштаба до большего размера изменений не происходит.
• Если вы масштабировались до меньшего размера, и у вас есть настраиваемый параметр баз данных, превышающий ограничение баз данных для нового размера, данные в этих базах данных не восстанавливаются. Чтобы получить дополнительную информацию, см. Затрагивает ли масштабирование настройки моей пользовательской базы данных?
• Если вы масштабировались до меньшего размера, и в меньшем размере недостаточно места для хранения всех данных из последней резервной копии, ключи вытесаются во время процесса восстановления. Как правило, ключи удаляются согласно политике allkeys-lru.

Можно ли использовать одну и ту же учетную запись хранения для сохраняемости данных в двух разных кэшах?

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

Будет ли взиматься плата за хранилище, используемое для постоянства данных?

• Для кэшей класса Premium взимается плата за используемое хранилище в соответствии с моделью ценообразования учетной записи хранения.
• Для кэшей Enterprise и Enterprise Flash плата не взимается за управляемое хранилище дисков. Она включена в цену.

Как часто механизмы сохранения RDB и AOF записывают данные в мои BLOB-объекты, и стоит ли включать мягкое удаление?

Рекомендуется избегать включения мягкого удаления для учетных записей хранения при использовании с Azure Cache for Redis с сохраняемостью данных на уровне "Премиум". Механизм сохранения данных с использованием RDB и AOF может записывать данные в BLOB-разделы каждый час, каждые несколько минут или каждую секунду. Кроме того, активация функции мягкого удаления в аккаунте хранения означает, что кэш Azure для Redis не сможет сокращать расходы на хранилище за счет удаления старых резервных копий.

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

Можно ли изменить частоту резервного копирования RDB после создания кэша?

Да, частоту резервного копирования для постоянного хранения RDB можно изменить с помощью Azure Portal, CLI или PowerShell.

Почему при установленной частоте резервного копирования RDB в 60 минут между созданием резервных копий проходит больше времени?

Интервал частоты резервного копирования сохраняемости RDB не запускается до успешного завершения предыдущего процесса резервного копирования. Если интервал резервного копирования составляет 60 минут и на процесс резервного копирования уходит 15 минут, то следующее резервное копирование начнется не ранее чем через 75 минут после начала предыдущего резервного копирования.

Что происходит со старыми резервными копиями RDB при создании другой?

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

Когда следует использовать вторичную учетную запись хранения?

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

Как удалить вторичную учетную запись хранения?

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

Что такое перезапись и как она влияет на кэш?

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

Чего ожидать при масштабировании кэша с включенным AOF?

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

Дополнительные сведения см. в разделе Что произойдет, если выполнено масштабирование до другого размера, а резервная копия была создана до этой операции?

Как организованы данные AOF в хранилище?

При использовании уровня "Премиум" данные, хранящиеся в файлах AOF, делятся на несколько страничных BLOB-объектов в каждом шарде. По умолчанию половина объектов blob сохраняется в основном аккаунте хранения, а половина сохраняется в дополнительном аккаунте хранения. Разделение данных между несколькими Page Blob-объектами и двумя разными учетными записями хранилища повышает производительность.

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

Если включена кластеризация, каждый сегмент в кэше имеет свой собственный набор страничных BLOB-объектов, как показано в предыдущей таблице. Например, кэш P2 с тремя сегментами распределяет файл AOF между 48 BLOB-объектами со страницами: шестнадцать объектов на сегмент.

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

Будут ли исключения брандмауэра в учетной записи хранения влиять на сохраняемость?

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

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

Можно ли включить сохраняемость AOF, если у меня несколько реплик?

На уровне "Премиум" нельзя использовать сохраняемость только для добавления (AOF) с несколькими репликами. На уровнях Enterprise и Enterprise Flash архитектура реплик более сложная, но поддержка сохранения AOF обеспечивается при использовании кэшей Enterprise в развертывании с зональной избыточностью.

Как проверить, включено ли мягкое удаление в моей учетной записи хранения?

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

Можно ли использовать учетную запись хранения в другой подписке, отличной от той, в которой находится мой кэш?

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

Следующие шаги

Узнайте больше о функциях Кэша Azure для Redis.

• Кэш Azure для уровней обслуживания Redis уровня «Премиум»
• Добавление реплик в кэш Azure для Redis