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

在 Azure VM 上运行 Apache Cassandra

  • 项目

注意

本文引用了 CentOS，这是一个接近生命周期结束 (EOL) 状态的 Linux 发行版。 请相应地考虑你的使用和规划。 有关详细信息，请参阅 CentOS 生命周期结束指南。

本文介绍在 Azure 虚拟机上运行 Apache Cassandra 的性能注意事项。

这些建议基于性能测试结果，可以在 GitHub 上找到。 应将这些建议作为基线，然后针对自己的工作负载进行测试。

适用于 Apache Cassandra 的 Azure 托管实例

如果正在寻找在 Azure 虚拟机上运行 Apache Cassandra 的更自动化的服务，请考虑使用 Azure Managed Instance for Apache Cassandra。 此服务自动执行部署、管理（修补和节点运行状况）以及 Apache Cassandra 群集中的节点缩放。 它还提供混合群集功能，因此 Azure 中部署的 Apache Cassandra 数据中心可以加入现有本地或第三方托管的 Cassandra 环。 该服务是使用 Azure 虚拟机规模集部署的。 在此服务开发期间采用了以下建议。

Azure VM 大小和磁盘类型

Azure 上的 Cassandra 工作负载通常使用 Standard_DS14_v2、Standard_DS13_v2、Standard_D16s_v5 或 Standard_E16s_v5 虚拟机。 Cassandra 工作负载受益于 VM 中的更多内存，因此请考虑内存优化的虚拟机大小（例如 Standard_DS14_v2 或 Standard_E16s_v5）或本地存储优化的大小（如 Standard_L16s_v3）。

考虑到持久性，数据和提交日志通常存储在 2 到 4 个 1 TB 高级托管磁盘 (P30) 的条带集上。

Cassandra 节点的数据不应太密集。 建议每个 VM 最多有 1 - 2 TB 的数据，并且有足够的可用空间进行压缩。 若要使用高级托管磁盘实现可能的最高组合吞吐量和 IOPS，建议从几个 1 TB 磁盘创建条带集，而不是使用单个 2 TB 或 4 TB 磁盘。 例如，在 DS14_v2 VM 上，四个 1 TB 磁盘的最大 IOPS 为 4 × 5000 = 20 K，而单个 4 TB 磁盘的最大 IOPS 为 7.5 K。

为需要较小磁盘容量的 Cassandra 工作负载评估 Azure Ultra Disks。 它们可以在 Standard_E16s_v5 和 Standard_D16s_v5 等 VM 大小上提供更高的 IOPS/吞吐量，并且延迟会更低。

对于不需要持久存储（也就是说，可以轻松地从另一个存储介质重构数据）的 Cassandra 工作负载，请考虑使用 Standard_L16s_v3 或 Standard_L16s_v2。 这些 VM 大小具有大型且快速的本地临时 NVMe 磁盘。

有关详细信息，请参阅比较 Azure 本地/临时磁盘与附加/永久性磁盘的性能 (GitHub)。

加速网络

Cassandra 节点大量使用网络从客户端 VM 发送和接收数据，并在节点之间通信以进行复制。 为了获得最佳性能，Cassandra VM 从高吞吐量和低延迟网络中受益。

建议在 Cassandra 节点的 NIC 和运行访问 Cassandra 的客户端应用程序的 VM 上启用加速网络。

加速网络需要具有最新驱动程序的新式 Linux 分发版，如 Cent OS 7.5+ 或 Ubuntu 16.x/18.x。 有关详细信息，请参阅创建具有加速网络的 Linux 虚拟机。

Azure VM 数据磁盘缓存

当随机访问磁盘延迟较低时，Cassandra 读取工作负载的性能最佳。 建议使用启用了 ReadOnly 缓存的 Azure 托管磁盘。 ReadOnly 缓存提供较低的平均延迟，因为数据从主机上的缓存中读取，而不是进入后端存储。

即使缓存模式的吞吐量限制低于非缓存模式，读取量大、随机读取工作负载（如 Cassandra）也会从较低读取延迟中受益。 （例如，DS14_v2 虚拟机的最大缓存吞吐量为 512 MB/秒，而未缓存的吞吐量为 768 MB/秒。）

ReadOnly 缓存对于 Cassandra 时序和其他工作负载尤其有用，其中工作数据集适合主机缓存，并且数据不会经常被覆盖。 例如，DS14_v2 缓存大小为 512 GB，可存储来自 Cassandra 节点的高达 50% 的数据，其数据密度为 1-2 TB。

启用 ReadOnly 缓存时，缓存未命中不会显著降低性能，因此建议将缓存模式用于除了写入量最大的工作负载外的所有工作负载。

有关详细信息，请参阅比较 Azure VM 数据磁盘缓存配置 (GitHub)。

Linux 预读

在 Azure 市场中的大多数 Linux 发行版中，默认块设备预读设置为 4096 KB。 Cassandra 的读取 IO 通常是随机的，并且相对较小。 因此，大量的预读会因为读取不需要的部分文件而浪费吞吐量。

若要最大程度地减少不必要的预读，请将 Linux 块设备预读设置设置为 8 KB。 （请参阅 DataStax 文档中的建议生产设置。）

为条带集和阵列设备本身（例如 /dev/md0）的所有块设备配置 8 KB 预读量。

有关详细信息，请参阅比较磁盘预读设置的影响 (GitHub)。

磁盘阵列 mdadm 区块大小

在 Azure 上运行 Cassandra 时，通常会为多个数据磁盘创建一个 mdadm 条带集（即 RAID 0），以提高整体磁盘吞吐量和 IOPS，使其更接近 VM 限制。 最佳磁盘条带大小是特定于应用程序的设置。 例如，对于 SQL Server OLTP 工作负载，建议大小为 64 KB。 对于数据仓库工作负载，建议大小为 256 KB。

对于 Cassandra 读取工作负载，我们的测试发现 64 k、128 k 和 256 k 的区块大小之间没有显著差异。 对于 128 k 区块大小，似乎有一个略为明显的小优势。 因此，建议执行以下操作：

  • 如果已在使用 64 K 或 256 K 的区块大小，则重新生成磁盘阵列以使用 128-K 大小没有意义。

  • 对于新配置，建议一开始就使用 128 K。

有关详细信息，请参阅测量 mdadm 区块大小对 Cassandra 性能的影响 (GitHub)。

提交日志文件系统

当提交日志位于高吞吐量和低延迟的磁盘上时，Cassandra 写入性能最佳。 在默认配置中，Cassandra 3.x 大约每隔 10 秒将数据从内存刷新到提交日志文件，并且每次写入时都不会触及磁盘。 在此配置中，无论提交日志位于高级附加磁盘上还是本地/临时磁盘上，写入性能几乎完全相同。

提交日志必须持久，以便重启的节点可以从刷新的提交日志中重构尚未包含在数据文件中的任何数据。 为了获得更好的持续性，将提交日志存储在高级托管磁盘上，而不是本地存储上，如果 VM 迁移到其他主机，可能会丢失这些日志。

根据我们的测试，当提交日志位于 xfs 与 ext4 文件系统上时，CentOS 7.x 上的 Cassandra 的写入性能可能较低。 启用提交日志压缩可以使 xfs 的性能与 ext4 保持一致。 在我们的测试中，压缩的 xfs 的性能与压缩和未压缩的 ext4 一样好。

有关详细信息，请参阅对 ext4 和 xfs 文件系统和压缩提交日志的观察 (GitHub)。

测量基线 VM 性能

为 Cassandra 环部署 VM 后，运行一些综合测试来建立基线网络和磁盘性能。 使用这些测试，根据 VM 大小确认性能符合预期。

稍后，在你运行实际工作负载时，了解性能基线可以更轻松地调查潜在瓶颈。 例如，了解 VM 上网络出口的基线性能有助于排除网络瓶颈。

有关运行性能测试的详细信息，请参阅验证基线 Azure VM 性能 (GitHub)。

文档大小

Cassandra 的读取和写入性能取决于文档大小。 读取或写入较大的文档时，会看到更高的延迟和更低的每秒操作数。

有关详细信息，请参阅比较各种 Cassandra 文档大小的相对性能 (GitHub)。

复制因子

在使用附加的高级磁盘时，大多数 Cassandra 工作负载使用复制因子 (RF) 3，在使用临时/临时本地磁盘时甚至为 5。 Cassandra 环中的节点数应为复制因子的倍数。 例如，RF 3 意味着一个由 3、6、9 或 12 个节点组成的环，而 RF 5 则有 5、10、15 或 20 个节点。 当使用 RF 大于 1 和 LOCAL_QUORUM 的一致性级别时，读取和写入性能通常低于使用 RF 1 运行的同一工作负载。

有关详细信息，请参阅比较各种复制因子的相对性能 (GitHub)。

Linux 页面缓存

Cassandra 的 Java 代码读取数据文件时使用常规文件 I/O，并受益于 Linux 页面缓存。 一次读取部分文件后，读取内容将存储在 OS 页面缓存中。 对相同数据的后续读取访问要快得多。

因此，对相同数据执行读取性能测试时，第二次和后续读取似乎要比原始读取快得多，因为原始读取需要在远程数据磁盘或在启用 ReadOnly 时从主机缓存访问数据。 若要在后续运行时获得类似的性能测量值，请清除 Linux 页面缓存并重启 Cassandra 服务以清除其内部内存。 启用 ReadOnly 缓存后，数据可能位于主机缓存中，即使在清除 OS 页面缓存并重启 Cassandra 服务后，后续读取也会更快。

有关详细信息，请参阅对 Linux 页面缓存的 Cassandra 使用情况的观察 (GitHub)。

多数据中心复制

Cassandra 原生支持多个数据中心的概念，因此可以轻松地跨多个 Azure 区域或跨一个区域中的可用性区域配置一个 Cassandra 环。

对于多区域部署，请使用 Azure 全球 VNet 对等互连来连接不同区域的虚拟网络。 当 VM 部署在同一区域但位于不同的可用性区域中时，VM 可以位于同一虚拟网络中。

测量区域之间的基线往返延迟非常重要。 区域之间的网络延迟可能比区域内延迟高 10-100 倍。 使用 LOCAL_QUORUM 写入一致性时，在第二个区域出现数据之间可能会有延迟，或者使用 EACH_QUORUM 时写入性能显著下降。

大规模运行 Apache Cassandra（特别是在多 DC 环境中）时，节点修复会变得困难。 Reaper 等工具可帮助协调大规模修复（例如，跨数据中心的所有节点（一次一个数据中心）来限制整个群集节点上的负载）。 但是，大型群集的节点修复问题还没有完全解决，它适用于所有环境，无论是本地还是在云中。

将节点添加到次要区域时，性能不会线性缩放，因为跨区域接收和发送复制流量会占用一定的带宽和 CPU/磁盘资源。

有关详细信息，请参阅测量多 dc 跨区域复制的影响 (GitHub)。

提示移交配置

在多区域 Cassandra 环中，写入一致性级别为 LOCAL_QUORUM 的工作负载可能会丢失次要区域中的数据。 默认情况，Cassandra 提示移交被限制为相对较低的最大吞吐量下和三小时提示生存期。 对于写入量较大的工作负载，建议增加提示移交限制和提示窗口时间，以确保在复制之前不会删除提示。

有关详细信息，请参阅对跨区域复制中提示移交的观察 (GitHub)。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

其他参与者：

若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

有关这些性能结果的详细信息，请参阅 Azure VM 上的 Cassandra 性能试验。

有关常规 Cassandra 设置（并非特定于 Azure）的信息，请参阅：