云梯1跨机房测试整体解决方案

云梯1跨机房测试整体解决方案

阅读本文前建议先阅读云梯跨机房方案介绍，了解云梯跨机房项目背景,难点以及解决方案。本文重点介绍下跨机房 测试的整体解决方案

　　 功能测试

　　 测试用例管理:http://kelude.taobao.net/testsuites?project_id=12202

　　数据安全性测试

　　数据安全简单的说就是不能丢数据，跨机房后集群规模到达近万台，数据存储到达数百PB，如何确保数据安全是一个很大的挑战

　　在跨机房的情况下，我们通过（Sange、Slive、DFSIO）模拟线上比例的各种混合性操作，通过NN的FSCK, CN的 CrossCheck工具定位异常数据如CORRUPT，一直处于BEING WRITTEN无法关闭的文件，跨机房失败的文件

　　数据安全性测试里需要考虑的一种重要场景是NN和DN重启，在实际的升级过程中，在集群重启前各业务线并没有停止读写数据，重启后数据的一致性和可恢复性非常重要；在实际的跨机房测试中我们曾发现一个因为重启后状态不一致导致无法加载EDITLOG从而使NN无法启动的BUG，如果这种问题发生到线上，后果不堪设想

　 　性能测试

　　性能测试的关键点是如何建立性能基准，对线上性能进行准确评估，跨机房测试性能基准工具主要包括：

　　DFSIO:  HDFS  I/O（读写） 性能基准

　　Slive: 主要模拟线上各种RPC,在每个TASK发起混合型RPC操作，并可以指定文件和block大小，该工具可以同时测试NN和DN的性能；

　　Sange:  主要模拟线上各种RPC操作压力，在每个TASK启动大量Thread进行混合性RPC操作 ,对NN产生压力,进而评估NN RPC 处理能力；SANGE工具不能指定文件和Block大小，会产生大量小文件，比SLIVE对NN可以产生更大的RPC压力

　　Terasort：MapReduce 数据排序能力基准

　　Gridmix ：Gridmix和Rumen结合可以模拟和生产作业相应的负载，更真实的模拟生产环境

　　SmallJobBench:通过创建大量sleep job到不同group来测试jobtracker性能

　　SubmitJobBench：通过每个map启动（-nThreads）个线程，每个线程顺序提交（-nTasks）个作业, 每个线程有自己的独立账号,来模拟线上多账号并行度2K情况下JTProxy性能

　　 跨机房性能主要对比场景：

　　主要针对上述场景进行性能对比和评估包括NN带宽，内存，CPU load, NN RPC 指标, NN 各个operation的吞吐量(opsper second)和平均执行时间， NN同步editlog性能指标，跨机房带宽流量，跨机房复制速率，跨机房副本删除速率，CROSSFSCK时间

　　跨机房测试还有很重要的一点是要保证计算一定优先从本机房读数据，除非本机房没有数据才会跨机房读；实际测试中TERASORT跨机房读对比本机房读性能会有32%左右的下降,而且对带宽也是很大的浪费。

　重要性能指标参考：

1.   cpu_user 2.   cpu_wio 3.   mem_free 4.   bytes_in 5.   bytes_out 6.   load_five 7.   total-iops 8.   total-ReadBytes 9.   total-WriteBytes 10.  dfs.namenode.Syncs_avg_time 11.  dfs.namenode.Syncs_num_ops 12.  dfs.namenode.Transactions_num_ops 13.  rpc.metrics.RpcProcessingTime_avg_time 14.  rpc.metrics.RpcQueueTime_avg_time 15.  rpc.metrics.RpcProcessingTime_num_ops 16.  rpc.metrics.delayedCallsQueueLen 17.  rpc.metrics.RpcQueueTime_num_ops 18.  rpc.metrics.addBlock_num_ops 19.  rpc.metrics.append_num_ops 20.  rpc.metrics.create_num_ops 21.  rpc.metrics.delete_num_ops 22.  rpc.metrics.getFileInfo_num_ops 23.  rpc.metrics.getListing_num_ops 24.  rpc.metrics.listCorruptFileBlocks_num_ops 25.  rpc.metrics.mkdirs_num_ops 26.  rpc.metrics.rename_num_ops 27.  rpc.metrics.RpcProcessingTime_num_ops 28.  rpc.metrics.RpcQueueTime_num_ops 29.  rpc.metrics.blockReport_num_ops 30.  rpc.metrics.blockReceivedAndDeleted_num_ops 31.  rpc.metrics.sendHeartbeat_num_ops 32.  rpc.metrics.rollEditLog_num_ops 33.  rpc.metrics.getBlockLocationsHA_num_ops 34.  rpc.metrics.getBlockLocations_num_ops

　　 压力测试

　　压力测试和性能测试关系紧密，压力测试更侧重于在线上最大压力的情况下系统是否可以正常工作，性能测试则侧重于新上线的版本是否有性能下降问题，主要是基于基准进行性能对比

　　压力测试比较难的一点是如何在小规模的测试集群模拟线上真实的压力，基本思路是     启动MR程序, 每个Task启动多个Thread,在每个thread进行大量模拟操作，NN和DN压力测试我们可以用到SANGE和Slive，JTPROXY压力测试可以用到SubmitJobBench，JT压力测试可以用到SmallJobBench和GurgleClient（TaskTracker模拟器）

　　跨机房压力测试主要是评估crossnode的自身压力和crossnode对namenode、datanode的压力影响；crossnode对namenode压力主要体现在RPC的请求，对datanode的压力目前主要体现在带宽和磁盘上

　　数据准备：利用SLIVE工具产生跟线上一样数量的Block和文件数

　 　跨机房压力主要场景：

　　 稳定性测试

　　构建BI仿真实验室，模拟整个云梯跨机房项目变更流程，运行BI线一日的作业，查看作业运行情况和做数据产出对比，验证跨机房后数据的正确性和业务线运行时间是否受影响

　 　总结

　　整个项目过程中，测试人员共发现有效bug 100多个，其中5个bug严重影响性能，10个bug可能导致丢数据，4个bug会导致服务不可用

　　本文主要是跨机房的测试整体介绍，整个跨机房测试是一个非常复杂的过程，可能大家觉得不是很过瘾，后续会进行跨机房测试经典BUG和工具分享，敬请期待