Рекомендации по обеспечению высокого уровня доступности и аварийного восстановления
Azure Управляемый экземпляр для Apache Cassandra — это полностью управляемая служба для чистых кластеров Apache Cassandra с открытым кодом. Служба также позволяет переопределить конфигурации в зависимости от конкретных потребностей каждой рабочей нагрузки, что позволяет обеспечить максимальную гибкость и контроль при необходимости.
Apache Cassandra — отличный выбор для создания высоко устойчивых приложений из-за распределенной природы и эталонной архитектуры— любой узел в базе данных может обеспечить ту же функциональность, что и любой другой узел, что способствует надежности и устойчивости Cassandra. В этой статье приводятся советы по оптимизации высокого уровня доступности и способам подхода к аварийному восстановлению.
RPO и RTO
RPO (цель точки восстановления) и RTO (цель времени восстановления) обычно будут низкими (близко к нулю) для Apache Cassandra до тех пор, пока у вас есть:
- Развертывание с несколькими регионами с репликацией между регионами и коэффициентом репликации 3.
- Включенные зоны доступности (выберите параметр при создании кластера на портале или с помощью Azure CLI).
- Настройка отработки отказа на уровне приложения с помощью политики балансировки нагрузки в клиентском драйвере и (или) отработке отказа на уровне балансировки нагрузки с помощью диспетчера трафика или front door Azure.
RTO ("как долго вы не работаете в сбоях") будет низким, так как кластер будет устойчивым в обоих зонах и регионах, и так как Apache Cassandra сам является очень отказоустойчивой, главной системой (все узлы могут записываться) по умолчанию. RPO ("сколько данных можно потерять в сбое") будет низким, так как данные будут синхронизированы между всеми узлами и центрами обработки данных, поэтому потеря данных в сбое будет минимальной.
Примечание.
Теоретически невозможно достичь RTO=0 и RPO=0 на кап теорем. Вам потребуется оценить компромисс между согласованностью и доступностью/оптимальной производительностью. Это будет выглядеть по-разному для каждого приложения. Например, если приложение считывает большой объем, возможно, лучше справиться с повышенной задержкой записи между регионами, чтобы избежать потери данных (в пользу согласованности). Если приложение выполняется с большим количеством операций записи, и при жесткой задержке бюджета, риск потери некоторых последних записей в крупном региональном сбое может быть приемлемым (в пользу доступности).
Зоны доступности
Эталонная архитектура Cassandra обеспечивает отказоустойчивость с нуля, а Azure Управляемый экземпляр для Apache Cassandra обеспечивает поддержку зон доступности в выбранных регионах для повышения устойчивости на уровне инфраструктуры. Учитывая коэффициент репликации 3, поддержка зоны доступности гарантирует, что каждая реплика находится в другой зоне доступности, что позволяет предотвратить зональный сбой от влияния на базу данных или приложение. По возможности рекомендуется включить зоны доступности.
Избыточность в нескольких регионах
Архитектура Cassandra, в сочетании с поддержкой зон доступности Azure, обеспечивает некоторый уровень отказоустойчивости и устойчивости. Однако важно учитывать влияние региональных сбоев для ваших приложений. Настоятельно рекомендуется развертывать кластеры с несколькими регионами для защиты от сбоев на уровне региона. Хотя они редки, потенциальное влияние является серьезным.
Для обеспечения непрерывности бизнес-процессов недостаточно только для создания базы данных с несколькими регионами. Другие части приложения также должны быть развернуты таким же образом путем распределения или с соответствующими механизмами отработки отказа. Если пользователи распределены по нескольким географическим расположениям, развертывание центра обработки данных с несколькими регионами для базы данных имеет дополнительные преимущества снижения задержки, так как все узлы во всех центрах обработки данных в кластере могут обслуживать как операции чтения, так и записи из региона, ближайшего к ним. Однако если приложение настроено как "активный—активный", важно рассмотреть, как теорема CAP применяется к согласованности данных между репликами (узлами) и компромиссами, необходимыми для обеспечения высокой доступности.
В терминах теоремы CAP Cassandra по умолчанию является системой базы данных AP (доступной секционаторной) с высокой согласованностью. В большинстве случаев использования рекомендуется использовать local_quorum для операций чтения.
- В активной пассивной записи существует компромисс между надежностью и производительностью: для надежности мы рекомендуем QUORUM_EACH но для большинства пользователей LOCAL_QUORUM или КВОРУМ является хорошим компромиссом. Обратите внимание, что в случае регионального сбоя некоторые записи могут быть потеряны в LOCAL_QUORUM.
- В случае параллельного запуска приложения QUORUM_EACH записи предпочтительнее в большинстве случаев обеспечить согласованность между двумя центрами обработки данных.
- Если ваша цель заключается в пользу согласованности (более низкого RPO), а не задержки или доступности (более низкий RTO), это должно быть отражено в параметрах согласованности и коэффициенте репликации. Как правило, количество узлов кворума, необходимых для чтения, а также количество узлов кворума, необходимых для записи, должно быть больше коэффициента репликации. Например, если у вас есть коэффициент репликации 3 и quorum_one на чтениях (один узел), следует quorum_all на записи (три узла), чтобы общее число 4 было больше, чем коэффициент репликации 3.
Примечание.
Оператор плоскости управления для Azure Управляемый экземпляр для Apache Cassandra будет развернут только в одном регионе (регион, выбранный при первоначальном развертывании первого центра обработки данных). В маловероятном случае полного сбоя региона мы зафиксируем 3-часовое время восстановления для отработки отказа плоскости управления в другой регион. Это не влияет на соглашение об уровне обслуживания для службы, так как центры обработки данных по-прежнему должны работать. Однако в течение этого периода может быть невозможно внести изменения в конфигурацию базы данных с портала или поставщика ресурсов.
Репликация
Рекомендуется выполнять аудит keyspaces и их параметры репликации от времени, чтобы обеспечить настройку требуемой репликации между центрами обработки данных. На ранних этапах разработки мы рекомендуем проверить, что все работает должным образом, выполняя простые тесты с помощью cqlsh. Например, вставка значения во время подключения к одному центру обработки данных и чтение его из другого.
В частности, при настройке второго центра обработки данных, в котором уже есть данные, важно определить, что все данные реплицированы и система готова. Мы рекомендуем отслеживать ход выполнения репликации nodetool netstatsс помощью команд DBA. Альтернативный подход заключается в подсчете строк в каждой таблице, но помните, что с размерами больших данных из-за распределенной природы Cassandra это может дать только приблизительную оценку.
Балансировка затрат на аварийное восстановление
Если приложение является "активным пассивным", мы по-прежнему рекомендуем развернуть одну емкость в каждом регионе, чтобы приложение мгновенно отработку отказа в "горячий резервный" центр обработки данных в дополнительном регионе. Это гарантирует отсутствие снижения производительности в случае регионального сбоя. Большинство клиентских драйверов Cassandra предоставляют возможности для запуска отработки отказа на уровне приложения. По умолчанию предполагается, что региональный сбой означает, что приложение также не работает, в этом случае отработка отказа должна происходить на уровне подсистемы балансировки нагрузки.
Тем не менее, чтобы сократить затраты на подготовку второго центра обработки данных, вы можете предпочесть развернуть меньший номер SKU и меньше узлов в дополнительном регионе. При возникновении сбоя масштабирование упрощается в Azure Управляемый экземпляр для Apache Cassandra путем вертикального и горизонтального масштабирования. При отработке отказа приложений в дополнительный регион можно вручную масштабировать и масштабировать узлы в дополнительном центре обработки данных. В этом случае дополнительный центр обработки данных выступает в качестве более низкой стоимости теплого резервирования. При таком подходе необходимо сбалансировать время, необходимое для восстановления системы до полной емкости в случае сбоя. Важно проверить и попрактиковаться, что происходит при потере региона.
Примечание.
Масштабирование узлов гораздо быстрее, чем масштабирование. Помните об этом при рассмотрении баланса между вертикальным и горизонтальным масштабированием и количеством узлов для развертывания в кластере.
Расписания резервного копирования
Резервные копии автоматически используются в Azure Управляемый экземпляр для Apache Cassandra, но вы можете выбрать собственное расписание для ежедневных резервных копий. Рекомендуется выбирать время с меньшей нагрузкой. Хотя резервные копии настроены только для использования простоя ЦП, они могут в некоторых случаях активировать сжатие в Cassandra, что может привести к увеличению использования ЦП. Сжатие может происходить в любое время с Cassandra и зависит от рабочей нагрузки и выбранной стратегии сжатия.
Внимание
Цель резервных копий заключается в том, чтобы устранить случайную потерю данных или повреждение данных. Мы не рекомендуем создавать резервные копии в качестве стратегии аварийного восстановления. Резервные копии не являются геоизбыточными, и даже если они были, это может занять очень много времени для восстановления базы данных из резервных копий. Поэтому настоятельно рекомендуется развертывать несколько регионов, в сочетании с включением зон доступности, где это возможно, для устранения последствий стихийных бедствий и эффективного восстановления от них. Это особенно важно в редких случаях, когда не удалось охватить регион, где без репликации в нескольких регионах все данные могут быть потеряны.
Следующие шаги
В этой статье мы изложили некоторые рекомендации по созданию устойчивых приложений с помощью Cassandra.