Операции управления в Управляемом экземпляре Azure для Apache Cassandra

Статья
08/15/2024

Azure Управляемый экземпляр для Apache Cassandra — это полностью управляемая служба для чистых кластеров Apache Cassandra с открытым кодом. Служба также позволяет переопределить конфигурации в зависимости от конкретных потребностей каждой рабочей нагрузки, что позволяет обеспечить максимальную гибкость и контроль при необходимости. В этой статье описаны предоставляемые службой операции и функции управления. Он также объясняет разделение обязанностей между командой поддержка Azure и клиентами при обслуживании гибридных кластеров.

Сжатие

Существуют различные типы сжатия. В настоящее время мы выполняем дополнительное сжатие с помощью ремонта (см . раздел "Обслуживание"). Это выполняет сжатие дерева Merkle, которое является особым видом сжатия.
В зависимости от стратегии сжатия, установленной в таблице с помощью CQL (например WITH compaction = { 'class' : 'LeveledCompactionStrategy' }), Cassandra автоматически сжимается, когда таблица достигает определенного размера. Рекомендуется тщательно выбрать стратегию сжатия для рабочей нагрузки и не делать никаких ручных уплотнений за пределами стратегии.

Исправление

Исправления на уровне операционной системы применяются автоматически с частотой в 2 недели.
Исправления на уровне программного обеспечения Apache Cassandra устанавливаются при обнаружении уязвимостей безопасности. Периодичность установки исправлений может быть разной.
Во время установки исправлений компьютеры перезапускаются по стойке за раз. Вы не должны столкнуться с какой-либо деградацией на стороне приложения, пока параметр кворума ALL не используется, и коэффициент репликации равен 3 или выше.
Версия в Apache Cassandra имеет формат X.Y.Z. Вы можете управлять развертыванием основных (X) и дополнительных (Y) версий вручную с помощью инструментов служб. При этом исправления Cassandra (Z), необходимые для соответствующего сочетания основной и дополнительной версий, устанавливаются автоматически.

Примечание.

В настоящее время служба поддерживает Cassandra версии 3.11 и 4.0. Обе версии являются общедоступной версией. Краткое руководство по Azure CLI (шаг 5) по указанию версии Cassandra во время развертывания кластера.

Обслуживание

Служба автоматически запускает инструмент Nodetool с помощью средства reaper. Это средство запускается каждую неделю. Его можно отключить, если вы используете собственную службу для гибридного развертывания.
Служба мониторинга работоспособности узла отвечает за следующие задачи:
- Активное отслеживание членства каждого узла в круге Cassandra.
- Автоматическое обнаружение и автоматическое создание проблем инфраструктуры, таких как виртуальная машина, сеть, хранилище, Linux и поддержка сбоев программного обеспечения.
- Проактивный мониторинг ЦП, диска, потери кворума и других проблем с ресурсами.
- Автоматическое создание неработоспособных узлов по возможности и ручное создание узлов в ответ на автоматически созданные предупреждения.

Поддержка

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

К нашим преимуществам поддержки относятся следующие преимущества:

Единый пункт контакта для проблем с инфраструктурой Cassandra - нет необходимости создавать варианты поддержки с командами IaaS (диск, вычисления, сеть) отдельно.
Профессиональный совет по электронной почте о проблемах с производительностью, размерах и других проблемах с ограничениями ресурсов.
Покрытие поддержки 24x7, включая автоматически созданные инциденты для любых серьезных проблем сбоем.
Поддержка утвержденных исправлений сообщества (см . исправление).
Техническая поддержка java JDK/JVM.
Поддержка операционной системы Linux с безопасностью цепочки поставок программного обеспечения.

Внимание

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

Вот некоторые примеры таких проблем:

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

В случае, если мы расследуем случай поддержки и обнаружили, что первопричина проблемы находится на уровне конфигурации Apache Cassandra (а не на базовом уровне платформы), мы по-прежнему предоставим рекомендации и рекомендации по исправлению или устранению рисков (по возможности) перед закрытием дела.

Мы рекомендуем включить метрики и (или) ознакомиться с интеграцией Azure Monitor, чтобы предотвратить распространенные проблемы на уровне приложения и конфигурации в Apache Cassandra, например приведенные выше.

Предупреждение

Azure Управляемый экземпляр для Apache Cassandra также давайте запустите nodetool и sstable команды для обычного администрирования DBA. См. статью здесь. Некоторые из этих команд могут дестабилизировать кластер cassandra и выполняться тщательно и после тестирования в непроизводственных средах. По возможности --dry-run сначала следует развернуть параметр. Корпорация Майкрософт не может предлагать соглашение об уровне обслуживания или поддержку при выполнении команд, которые изменяют конфигурацию базы данных по умолчанию и (или) таблицы.

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

Резервные копии моментальных снимков включены по умолчанию и выполняются каждые 24 часа. Резервные копии хранятся во внутренней учетной записи Хранилище BLOB-объектов Azure и хранятся до 2 дней (48 часов). Для начальных 2 резервных копий нет затрат. Плата за дополнительные резервные копии взимается, см . цены. Чтобы изменить интервал резервного копирования или период хранения, можно изменить политику на портале:

Чтобы восстановить существующую резервную копию, отправьте запрос в службу поддержки в портал Azure. При отправке обращения в службу поддержки необходимо выполнить следующие действия.

Укажите идентификатор резервного копирования на портале для резервной копии, которую требуется восстановить. Это можно найти на портале:
Сообщите нам, был ли удален исходный центр обработки данных. Это будет важно, чтобы определить правильную учетную запись резервного копирования для восстановления.
Если восстановление всего кластера не требуется, укажите пространство ключей и таблицу (если применимо), которую необходимо восстановить.
Укажите, нужно ли восстановить резервную копию в существующем кластере или в новом кластере.
Если вы хотите восстановить новый кластер, сначала необходимо создать новый кластер. Убедитесь, что целевой кластер соответствует исходному кластеру с точки зрения количества центров обработки данных и что соответствующий центр обработки данных имеет одинаковое количество узлов. Вы также можете решить, следует ли хранить учетные данные (имя пользователя или пароль) в новом целевом кластере или разрешить восстановление для переопределения имени пользователя или пароля с помощью того, что было создано первоначально.
Вы также можете решить, следует ли хранить system_auth пространство ключей в новом целевом кластере или разрешить восстановление перезаписать его данными из резервной копии. Пространство system_auth ключей в Cassandra содержит данные авторизации и внутренней проверки подлинности, включая роли, разрешения ролей и пароли. Обратите внимание, что процесс восстановления по умолчанию перезаписывает пространство ключей system_auth .

Примечание.

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

Предупреждение

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

Безопасность

Управляемый экземпляр Azure для Apache Cassandra содержит множество встроенных явных средств и функций управления безопасностью:

Укрепленные в плане защиты образы виртуальных машин Linux с управляемой цепочкой поставок.
Мониторинг распространенных уязвимостей и атак (CVE) на уровне операционной системы.
Смена сертификатов для программного обеспечения Apache Cassandra и Prometheus, размещенного на управляемых виртуальных машинах.
Активное сканирование уязвимостей.
Активный поиск вирусов.
Безопасный программный код.

Дополнительные сведения о функциях безопасности см . здесь.

Поддержка гибридной конфигурации

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

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

Начните работу с изучения одного из кратких руководств:

Поделиться через