你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Managed Instance for Apache Cassandra 中的管理操作

  • 项目

Azure Managed Instance for 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 版本。

维护

  • 服务使用 reaper 自动运行 Nodetool 修复。 此工具每周运行一次。 如果你将自己的服务用于混合部署，建议禁用该工具。

  • 节点运行状况监视包括：

    • 主动监视 Cassandra 环中每个节点的成员身份。
    • 自动检测和自动缓解基础结构问题，例如虚拟机、网络、存储、Linux 和支持软件故障。
    • 主动监视 CPU、磁盘、仲裁丢失和其他资源问题。
    • 在可能的情况下自动启动失败的节点，并手动启动节点以响应自动生成的警告。

支持

Azure Managed Instance for Apache Cassandra 提供托管群集中数据中心的可用性 SLA。 如果你在使用该服务时遇到任何问题，请在 Azure 门户中提交支持请求。

我们的支持权益包括：

  • Cassandra 基础结构问题的单点联系人 - 无需单独向 IaaS 团队提出支持案例（磁盘、计算、网络）。
  • 通过电子邮件主动提出关于性能瓶颈、调整调整和其他资源约束问题的建议。
  • 24x7 支持覆盖，包括面向任何严重中断问题的自动生成事件。
  • 社区批准的补丁支持（请参阅 修补）。
  • 内部 Java JDK/JVM 工程团队支持。
  • 软件供应链安全性的 Linux 操作系统支持。

重要

我们将会调查和诊断通过支持案例报告的任何问题，并尽可能解决或缓解这些问题。 但是，最终需要由你来负责解决使用任何 Apache Cassandra 配置级别时导致的 CPU、磁盘或网络问题。

此类问题的示例包括：

  • 查询操作效率低下。
  • 吞吐量超出容量。
  • 引入的数据超出存储容量。
  • 密钥空间配置设置不正确。
  • 数据模型或分区键策略表现不佳。

如果我们调查支持案例，并发现问题的根本原因在于 Apache Cassandra 配置级别（而不是我们维护的任何基础平台级别），我们在结束该案例之前仍将（在可能的情况下）提供有关修正或缓解的建议和指导。

我们建议启用指标和/或熟悉我们的 Azure Monitor 集成，以防止 Apache Cassandra 中出现常见应用程序/配置级别问题（例如上面列出的问题）。

警告

Azure Managed Instance for Apache Cassandra 也可以让你运行 nodetool 和 sstable 命令以进行常规 DBA 管理 - 请参阅此处的文章。 其中的某些命令可能会导致 cassandra 群集不稳定，只应在非生产环境中仔细运行和测试。 如果可以，应首先部署 --dry-run 选项。 对于更改默认数据库配置和/或表的运行命令出现的问题，Microsoft 无法提供任何 SLA 或支持。

备份和还原

快照备份默认已启用，每隔 24 小时备份一次。 备份存储在内部 Azure Blob 存储帐户中，最长保留 2 天（48 小时）。 初始 2 个备份不收费。 额外备份收费，请参阅定价。 若要更改备份间隔或保留期，可以在门户中编辑策略：

Screenshot of backup schedule configuration page.

若要从现有备份还原，请在 Azure 门户中提交支持请求。 提交支持案例时，需要：

  1. 为要还原的备份提供门户中的备份 ID。 可在门户中找到此项：

    Screenshot of backup schedule configuration page highlighting backup ID.

  2. 如果不需要还原整个群集，请提供需要还原的密钥空间和表（如果适用）。

  3. 建议是希望在现有群集中还原备份，还是要在新群集中还原备份。

  4. 如果要还原到新群集，需要先创建新群集。 确保目标群集在数据中心数方面与源群集匹配，并且相应的数据中心具有相同的节点数。 还可以决定是将凭据（用户名/密码）保留在新的目标群集中，还是允许还原以使用最初创建的内容替代用户名/密码。

  5. 还可以决定是将 system_auth 密钥空间保留在新的目标群集中，还是允许还原使用备份中的数据覆盖它。 Cassandra 中的 system_auth 密钥空间包含授权和内部身份验证数据，包括角色、角色权限和密码。 请注意，我们的默认还原过程将覆盖 system_auth 密钥空间。

注意

响应从备份还原请求所需的时间取决于所引发的支持案例的严重性（以及响应时间对应的 SLA），以及要还原的数据量。 但是，我们不提供 SLA 来完成还原的时间，因为这非常依赖于要还原的数据量。

警告

备份适用于意外删除场景，而不适用于异地冗余。 因此，不建议将备份用作整个区域发生服务中断时的灾难恢复 (DR) 策略。 若要在发生区域范围的服务中断时提供保护，我们建议进行多区域部署。 查看多区域部署快速入门。

安全

Azure Managed Instance for Apache Cassandra 提供许多内置的显式安全控制和功能：

  • 使用受控的供应链强化 Linux 虚拟机映像。
  • 操作系统级别的常见漏洞和披露 (CVE) 监视。
  • 托管虚拟机上的 Apache Cassandra 和 Prometheus 软件的证书轮换。
  • 主动漏洞扫描。
  • 主动病毒扫描。
  • 安全编码做法。

有关安全功能的详细信息，请参阅此处的文章。

混合支持

配置混合群集后，服务中运行的自动 reaper 操作将使整个群集受益。 其中包括未由该服务预配的数据中心。 除此之外，你还需要负责维护本地或外部托管的数据中心。

后续步骤

通过以下快速入门之一来完成入门：