PowerScale、Isilon OneFS：Isilon 上的 HBase 性能测试

简介

我们使用 YCSB 基准测试套件和 CDH 5.10 对 Isilon X410 群集进行了一系列性能基准测试。

CAE POC 实验室环境配置了 5 个 Isilon x410 节点，运行的是 OneFS 8.0.0.4 和更高版本 8.0.1.1 NFS 大型数据块流式传输基准 在上述任何测试中，我们的理论聚合最大值应为 5 倍 ~700 MB/s（3.5 GB/s）和 5 倍 ~1 GB/s 读取（5 GB/s）。

（9） 个计算节点是运行 CentOS 7.3.1611 的 Dell PowerEdge FC630 服务器，每个服务器配置有 2 个 18C/36T-Intel Xeon® CPU E5-2697 v4 @ 2.30GHz，带 512 GB RAM。本地存储在 RAID 1 中为 2 个 SSD，格式化为 XFS，适用于操作系统和暂存空间/泼溅文件。

此外，还有三个额外的边缘服务器用于驱动 YCSB 负载。

计算节点和 Isilon 之间的后端网络为 10 Gbps，为 NIC 和交换机端口设置了巨型帧 （MTU=9162）。

初始测试

第一系列测试旨在确定影响整体输出的 HBASE 端的相关参数。我们使用 YCSB 工具为 HBASE 生成负载。此初始测试是使用 YCSB 和 4000 万行的“加载”阶段使用单个客户端（边缘服务器）运行的。此表在每次运行之前已删除。
 

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=family -threads 256 -p recordcount=400000000

hbase.regionserver.maxlogs — 预写日志 （WAL） 文件的最大数量。此值乘以 HDFS 数据块大小 （dfs.blocksize） 是在服务器崩溃时必须重放的 WAL 的大小。此值与刷新到磁盘的频率成反比。

hbase.wal.regiongrouping.numgroups — 使用多个 HDFS WAL 作为 WALProvider 时，设置每个 RegionServer 应运行的写入日志数量。导致此数量的 HDFS 管道。给定区域的写入仅转至单个管道，从而分散 RegionServer 总负载。

这里的理念是并行处理尽可能多的写入，因此增加 WAL 数量，然后每个 WAL 的线程数（管道）可以实现这一点。前两个图表显示，对于“maxlogs”128 或 256 的给定数字，我们看到没有真正的变化，表明我们没有真正从客户端推入此数字。尽管我们看到了指示对并行化敏感的参数的趋势，但请注意每个文件的“管道”数量。下一个问题是，Isilon 在磁盘 I/O、网络、CPU 或 OneFS 方面会“妨碍”哪些方面，我们可以查看 Isilon 统计信息报告。



网络和 CPU 图形告诉我们，Isilon 群集利用率低下，并且有更多工作空间。CPU 为 > 80%，网络带宽将超过 3 GB/s。



这些绘图显示 HDFS 协议统计信息以及 OneFS 如何转换它们。HDFS ops 是 dfs.blocksize 的倍数，此处为 256 MB。有趣的是，“热”图显示了 OneFS 文件操作，您可以看到写入和锁定的关联。在这种情况下，HBase 将附加到 WAL，因此 OneFS 会为附加的每个写入锁定 WAL 文件。这是我们在群集文件系统上实现稳定写入的预期。这一组测试似乎造成了这一组测试中的限制因素。

HBase 更新

下一个测试是进行一些更多的实验，以查找大规模发生的情况，因此我创建了一个十亿行表，该表花了一个小时才生成，然后执行 YCSB 运行，使用“workloada”设置（50/50 读/写）更新了 1000 万行。这是在单个客户端上运行的，我还在寻找可以生成的吞吐量，因此我作为 YCSB 线程数的函数运行此功能。另一个注意事项是，我们对 Isilon 进行了一些调整，并转至 OneFS 8.0.1.1，该版本对数据节点服务进行了性能调整。您可以看到与上一组运行相比性能的提升。对于这些运行，我们设置 hbase.regionerver.maxlogs = 256，将 hbase.wal.regiongrouping.numgroups 设置为 20

看一看这些运行，第一个明显的是线程数高时出现故障。我很好奇这是 Isilon 问题还是客户端问题。我们将在后面的段落中看到一些关于该内容的进一步测试。但我可以说，以 3 毫秒的 < 更新延迟推动 20 万次以上运营的运行是令人印象深刻的。每个更新运行速度都很快，我可以一个接一个地运行，下面的图表显示了这些运行的 Isilon 节点之间的平衡。



同样，您可以从热图中看到，文件操作是写入和锁定，与 WAL 进程的附加性质相对应。

区域服务器扩展

下一个测试是确定 Isilon 节点（其中五个）如何针对不同数量的区域服务器进行攻击。在上一次测试中运行的相同更新脚本在此处运行。10 亿行表和 1000 万行使用单个客户端和 YCSB 线程 51 的“workloada”进行更新，我们还在 maxlogs 和管道上保留相同的设置（分别为 256 和 20）。

 
结果信息丰富，但并不令人意外。HBase 的横向扩展特性与 Isilon 和 more==better 的横向扩展特性相结合。作为规模调整练习的一部分，我建议客户在其环境中运行这项测试。它的回报可能会下降，但在这里，我们有九台强大的服务器在推送五个 Isilon 节点，看起来还有更多空间。

更多客户端

最后一系列测试来自深暗的地方，这使您想要打破正在测试的系统。毕竟，它是一种非常有效的科学方法，可以对测试进行测试，直至出现故障并调用，从而知道所测试参数的上限是什么。在这一系列测试中，我可以使用另外两台服务器从中运行客户端，此外，我在每个测试上运行两个 YCSB 客户端，允许我扩展到最多六个客户端，每个客户端驱动 512 个线程，即 4096 个线程。我返回并创建了两个不同的表，其中一个包含 40 亿行，划分为 600 个区域，一个 4000 万行划分为 90 个区域。  

 



 

如您所见，此测试中表的大小非常重要。再次看一下 Isilon 热图，您可以看到，文件操作的数量有一些百分比的差异，主要是内联文件操作，40 亿行表与 4 亿行的差异。

结论

HBase 非常适合在 Isilon 上运行，这主要是因为横向扩展到横向扩展体系结构。HBase 会执行很多自己的缓存，并且会将表拆分到许多区域，您可以让 HBase 使用数据进行横向扩展。换言之，它很好地处理自己的需求，并且文件系统存在以实现持久性。我们无法将负载测试推送到实际突破点，但如果您在 HBase 设计中查看了 40 亿行，并且预计需要 800,000 个操作，延迟小于 3 毫秒，此体系结构支持它。如果您注意到，我没有详细提及您可以应用于 HBase 的任何其他客户端调整，我预计所有这些调整仍然有效，并且超出此测试的范围。