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

不需要

不需要

简介

使用 YCSB 基准测试套件和 CDH 5.10 在 Isilon X410 群集上执行了一系列性能基准测试。

实验室测试环境配置了五个运行 OneFS v8.0.0.4 和更高版本 v8.0.1.1 的 Isilon x410 节点。运行了网络文件系统 （NFS） 大型数据块流式处理基准测试。测试的预期理论最大聚合为每个节点

~700 MB/s （3.5 GB/s） 写入和 ~1 GB/s 读取 （5 GB/s）。（9） 个计算节点是运行 CentOS v7.3.1611 的 Dell PowerEdge FC630 服务器，每个服务器配置有 2x18C/36T-Intel Xeon® CPU E5-2697 v4 @ 2.30GHz 和 512GB RAM。本地存储为 RAID 1 中的 2 个 SSD，格式化为 XFS，用于作系统和暂存空间或溢出文件。

另外还有三台额外的边缘服务器用于驱动 YCSB 负载。

计算节点和 Isilon 之间的后端网络为 10 Gbps，为 NIC 和交换机端口设置巨型帧 （MTU=9162）。
CDH 5.10 配置为在 Isilon 群集上的访问分区中运行。服务帐户在 Isilon Local 提供程序中创建，并在本地客户端 /etc/passwd 文件中创建。所有测试均使用基本测试客户端运行，没有特殊权限。

使用 IIQ 和 Grafana/Data Insights 软件包监视 Isilon 统计信息。CDH 统计信息使用 Cloudera Manager 和 Grafana 进行监控。

初始测试

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

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

• 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 运算是 dfs.blocksize 的倍数，此处为 256MB。有趣的是，“Heat”图表显示了 OneFS 文件作，并显示了写入和锁定的相关性。在这种情况下，HBase 将追加到 WAL，因此 OneFS 会锁定每次追加的写入的 WAL 文件。这是群集文件系统上稳定写入的预期结果。这些似乎促成了这组测试的限制因素。

HBase 更新

接下来的测试是做更多的实验，以找出大规模发生的事情。创建了一个 10 亿行的表，需要一个小时才能生成。运行 YCSB 测试，使用“workloada”设置（50/50 读/写）更新 1000 万行。此测试在单个客户端上运行。测试作为 YCSB 线程数量的函数运行，以便可以生成最大吞吐量。此外，还应用了一些调整，OneFS 升级到了 v8.0.1.1，其中对数据节点服务进行了性能调整。下图显示了与上一组运行相比性能提升。对于这些运行，hbase.regionserver.maxlogs 设置为 256，将 hbase.wal.regiongrouping.numgroups 设置为 20。    
对这些测试运行的审查显示，在高线程数下有明显的下降，这可能是 Isilon 或客户端问题。测试显示，在 3 毫秒的更新延迟 < 下，每秒 20 万次作给人留下了深刻的印象。每次更新测试运行速度都很快，并且可以连续运行。下图显示了每次测试运行中 Isilon 节点之间的均匀平衡。
热图显示文件作是与 WAL 进程的追加性质相对应的写入和锁定。

区域服务器扩展

下一个测试是确定 Isilon 节点（五个节点）在面对不同数量的区域服务器时的表现。在上一个测试中运行的相同更新脚本涉及 10 亿行表，并使用“workloada”进行 1000 万行更新。该测试使用单个客户端，其中 YCSB 线程数设置为 51。对 maxlogs 和管道应用相同的设置（分别为 256 和 20）。  
结果内容丰富，但并不令人惊讶。HBase 的横向扩展特性与 Isilon 的横向扩展特性相结合，表明数量越多越好。建议客户在其环境中运行此测试，作为他们自己的规模调整练习的一部分。目前有九台服务器各有五个 Isilon 节点，在达到收益递减的地步之前，似乎还有进一步发展的空间。

更多客户

最后一系列测试用于测试硬件配置的限制。这样做是为了确定正在测试的参数的上限。在这一系列测试中，使用了两台额外的服务器来运行客户端。此外，从每台服务器运行两个 YCSB 客户端，每个服务器最多允许六个客户端。每个客户端驱动 512 个线程，总共有 4096 个线程。创建了两个不同的表。一个表有 40 亿行，分为 600 个区域，另一个表有 4 亿行，分为 90 个区域。  
下图显示，在此测试中，表的大小无关紧要。Isilon 散热图表再次显示，文件作的数量存在一些百分比差异。大多数差异与 40 亿行表与 4 亿行表的差异一致。

结论

HBase 非常适合在 Isilon 上运行，这主要是因为从横向扩展到横向扩展的体系结构。HBase 会自行执行大量缓存，通过将表拆分到多个区域，HBase 可以随数据一起横向扩展。换言之，它很好地满足了自己的需求，而文件系统则提供了应用程序抗风险能力。测试无法将负载推到破坏事物的地步。如果 HBase 设计用于 800,000 次作，延迟小于 3 毫秒，则此体系结构支持它。HBase 支持对客户端和 HBase 本身进行大量性能调整和调整。对所有这些调整和调整的测试超出了此测试的范围。