通过

你当前正在访问 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 个备份不收费。 额外备份收费，请参阅定价。 若要更改备份间隔或保留期，可以在门户中编辑策略：

备份计划配置页的屏幕截图。

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

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

    备份计划配置页的屏幕截图，其中突出显示了备份 ID。

  2. 告知我们源数据中心是否已删除。 要确定要从中还原的正确备份帐户，这一点非常重要。

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

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

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

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

注意

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

警告

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

安全

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

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

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

混合支持

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

后续步骤

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