Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure Управляемый экземпляр для Apache Cassandra — это полностью управляемая служба для чистых кластеров Apache Cassandra с открытым кодом. Служба позволяет переопределить конфигурации в зависимости от потребностей каждой рабочей нагрузки, что обеспечивает максимальную гибкость и контроль, где это необходимо.
Apache Cassandra — отличный выбор для создания высоко устойчивых приложений из-за распределенной природы и одноранговой архитектуры. Любой узел в базе данных может предоставлять те же функции, что и любой другой узел. Эта конструкция способствует надежности и устойчивости Cassandra. В этой статье приводятся советы по оптимизации высокого уровня доступности и способам подхода к аварийному восстановлению.
Цель целевой точки восстановления и время восстановления
Если у вас есть следующие элементы, цель точки восстановления (RPO) и цель времени восстановления (RTO) обычно низкая, близко к нулю:
- Развертывание нескольких регионов с репликацией между регионами и коэффициентом репликации 3.
- Включенные зоны доступности. Настройте этот параметр при создании кластера на портале Azure или с помощью Azure CLI.
- Настройка отказоустойчивости на уровне приложения с помощью политики балансировки нагрузки в драйвере клиента или на уровне балансировки нагрузки, используя Azure Traffic Manager или Azure Front Door.
RTO — это продолжительность простоя при сбое. Это низко, так как кластер устойчив как в зонах, так и в регионах. Кроме того, Apache Cassandra сам является высоко отказоустойчивой, одноранговой системой, где все узлы могут записывать по умолчанию.
RPO — это то, сколько данных можно потерять в сбое. Это низко, так как данные синхронизируются между всеми узлами и центрами обработки данных. Потеря данных в сбое будет минимальной.
Примечание.
Невозможно достичь и RTO=0, и RPO=0 согласно теореме CAP. Оцените компромисс между согласованностью и доступностью или оптимальной производительностью.
Этот баланс выглядит по-разному для каждого приложения. Например, если приложение считывает большой объем, возможно, лучше справиться с повышенной задержкой записи между регионами, чтобы избежать потери данных, что способствует согласованности. Если приложение содержит частые записи со строгими требованиями к задержке, риск потери некоторых последних записей в крупном региональном сбое может быть приемлемым, что способствует доступности системы.
Зоны доступности
Одноранговая архитектура 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-часовое время восстановления для отработки отказа плоскости управления в другой регион.
Так как центры обработки данных по-прежнему должны работать, эта проблема не влияет на соглашение об уровне обслуживания для службы. В течение этого периода может быть невозможно внести изменения в конфигурацию базы данных с портала Azure или средств поставщика ресурсов.
Репликация
Рекомендуется время от времени выполнять аудит keyspaces и их настроек репликации, чтобы убедиться, что необходимая репликация между центрами данных настроена. На ранних этапах разработки рекомендуется выполнять простые тесты с помощью cqlsh. Например, вставьте значение, подключившись к одному центру обработки данных, и считайте его из другого.
В частности, при настройке второго центра обработки данных, где уже есть данные существующего центра обработки данных, определите, что реплицировали все данные и что система готова. Рекомендуется отслеживать ход репликации с помощью команд nodetool netstatsDBA. Альтернативный подход заключается в подсчете строк в каждой таблице. Имейте в виду, что с размерами больших данных из-за распределенной природы Cassandra этот подход может дать только приблизительную оценку.
Балансировка затрат на аварийное восстановление
Если ваше приложение является активным-пассивным, мы по-прежнему рекомендуем развернуть одинаковые мощности в каждом регионе. Такой подход помогает приложению мгновенно переключиться на центр данных с горячим резервом в дополнительном регионе. При возникновении регионального сбоя этот подход не обеспечивает снижение производительности. Большинство клиентских драйверов Cassandra предоставляют возможности для запуска отработки отказа на уровне приложения. По умолчанию предполагается, что региональный сбой означает, что приложение тоже недоступно, поэтому переключение на резерв должно происходить на уровне балансировщика нагрузки.
Чтобы сократить затраты на подготовку второго центра обработки данных, вы можете предпочесть развернуть меньший SKU и меньше узлов во вторичном регионе. При возникновении сбоя масштабирование под ключ, как вертикальное так и горизонтальное, упрощает процесс увеличения масштабов в Управляемом экземпляре Azure для Apache Cassandra. При отработке отказа приложений в дополнительный регион можно вручную увеличить количество и увеличить мощность узлов в дополнительном центре обработки данных. Резервный центр обработки данных используется в качестве площадки с низкой стоимостью в режиме ожидания. Принимая этот подход, необходимо сбалансировать время, необходимое для восстановления системы до полной емкости, если происходит сбой. Важно проверить и попрактиковаться, что происходит при потере региона.
Примечание.
Масштабирование узлов по вертикали происходит гораздо быстрее, чем масштабирование по горизонтали. Имейте в виду этот факт, когда вы рассматриваете баланс между вертикальным и горизонтальным масштабированием, а также количество узлов, которые необходимо развернуть в вашем кластере.
Расписания резервного копирования
Резервные копии автоматически используются в Управляемом экземпляре Azure для Apache Cassandra. Вы можете выбрать собственное расписание для ежедневных резервных копий. Рекомендуется выбирать время с меньшей нагрузкой. Хотя резервные копии настроены только для использования простоя ЦП, они могут в некоторых случаях активировать сжатие в Cassandra, что может привести к увеличению использования ЦП. Компакции могут происходить в любое время в Cassandra. Они зависят от рабочей нагрузки и выбранной стратегии сжатия.
Внимание
Цель резервных копий заключается исключительно в устранении случайной потери данных или повреждения данных. Мы не рекомендуем создавать резервные копии в качестве стратегии аварийного восстановления.
Резервные копии не являются геоизбыточными. Даже если бы они были, восстановление базы данных из резервных копий может занять много времени. Поэтому настоятельно рекомендуется использовать несколько развертываний регионов, в сочетании с включением зон доступности, где это возможно, для устранения последствий стихийных бедствий и эффективного восстановления от них. Этот подход особенно важен в редких сценариях, когда не удается восстановить неудачный регион. Без репликации в нескольких регионах все данные могут быть потеряны.
