Management operations in Azure Managed Instance for Apache Cassandra

Azure Managed Instance for Apache Cassandra is a fully managed service for pure open-source Apache Cassandra clusters. The service also allows configurations to be overridden, depending on the specific needs of each workload, allowing maximum flexibility and control where needed. This article defines the management operations and features provided by the service. It also explains the separation of responsibilities between the Azure support team and customers when maintaining hybrid clusters.

Compaction

• There are different types of compaction. We currently perform a minor compaction via repair (see Maintenance). This performs a Merkle tree compaction, which is a special kind of compaction.
• Depending on the compaction strategy that was set on the table using CQL (for example WITH compaction = { 'class' : 'LeveledCompactionStrategy' }), Cassandra automatically compacts when the table reaches a specific size. We recommend that you carefully select a compaction strategy for your workload, and don't do any manual compactions outside the strategy.

Patching

• Operating System-level patches are done automatically at approximately 2-week cadence.

• Apache Cassandra software-level patches are done when security vulnerabilities are identified. The patching cadence may vary.

• During patching, machines are rebooted one rack at a time. You shouldn't experience any degradation at the application side as long as quorum ALL setting is not being used, and the replication factor is 3 or higher.

• The version in Apache Cassandra is in the format X.Y.Z. You can control the deployment of major (X) and minor (Y) versions manually via service tools. Whereas the Cassandra patches (Z) that may be required for that major/minor version combination are done automatically.

Maintenance

• The Nodetool repair is automatically run by the service using reaper. This tool is run once every week. You may wish to disable it if using your own service for a hybrid deployment.

• Node health monitoring consists of:

  • Actively monitoring each node's membership in the Cassandra ring.
  • Autodetecting, and automitigating infrastructure issues like virtual machine, network, storage, Linux, and support software failures.
  • Pro-actively monitoring CPU, disk, quorum loss, and other resource issues.
  • Automatically bringing up failed nodes where possible, and manually bringing up nodes in response to auto-generated warnings.

Support

Azure Managed Instance for Apache Cassandra provides an SLA for the availability of data centers in a managed cluster. If you encounter any issues with using the service, file a support request in the Azure portal.

Our support benefits include:

• Single point of contact for Cassandra infrastructure issues - no need to raise support cases with IaaS teams (disk, compute, networking) separately.
• Pro-active advise via email on performance bottle necks, sizing, and other resource constraint issues.
• 24x7 support coverage, including autogenerated incidents for any severe outage issues.
• Community approved patch support (see Patching).
• In-house Java JDK/JVM engineering team support.
• Linux Operating System support with software supply chain security.

Backup and restore

Snapshot backups are enabled by default and taken every 24 hours. Backups are stored in an internal Azure Blob Storage account and are retained for up to 2 days (48 hours). There's no cost for the initial 2 backups. Extra backups are charged, see pricing. To change the backup interval or retention period, you can edit the policy in the portal:

To restore from an existing backup, file a support request in the Azure portal. When filing the support case, you need to:

1. Provide the backup ID from portal for the backup you want to restore. This can be found in the portal:

   

2. If restore of the whole cluster is not required, provide the keyspace and table (if applicable) that needs to be restored.

3. Advise whether you want the backup to be restored in the existing cluster, or in a new cluster.

4. If you want to restore to a new cluster, you need to create the new cluster first. Ensure that the target cluster matches the source cluster in terms of the number of data centers, and that corresponding data center has the same number of nodes. You can also decide whether to keep the credentials (username/password) in the new target cluster, or allow restore to override username/password with what was originally created.

5. You can also decide whether to keep system_auth keyspace in the new target cluster or allow the restore to overwrite it with data from the backup. The system_auth keyspace in Cassandra contains authorization and internal authentication data, including roles, role permissions, and passwords. Note that our default restore process overwrites the system_auth keyspace.

Security

Azure Managed Instance for Apache Cassandra provides many built-in explicit security controls and features:

• Hardened Linux Virtual Machine images with a controlled supply chain.
• Common Vulnerability & Exposure (CVE) monitoring at the Operating System level.
• Certificate rotation for both Apache Cassandra and Prometheus software hosted on the managed Virtual Machines.
• Active vulnerability scanning.
• Active virus scanning.
• Secure coding practices.

For more information on security features, see our article here.

Hybrid support

When a hybrid cluster is configured, automated reaper operations running in the service benefits the whole cluster. This includes data centers that aren't provisioned by the service. Outside this, it is your responsibility to maintain your on-premises or externally hosted data center.

Next steps

Get started with one of our quickstarts:

• Create a managed instance cluster from the Azure portal
• Deploy a Managed Apache Spark Cluster with Azure Databricks
• Manage Azure Managed Instance for Apache Cassandra resources using Azure CLI