大规模集群故障处理，能抗住这3个灵魂拷问算你赢
|
副标题[/!--empirenews.page--]
我相信每一个集群管理员，在长期管理多个不同体量及应用场景的集群后，都会多少产生情绪。其实这在我看来，是一个很微妙的事，即大家也已经开始人性化的看待每一个集群了。
既然是人性化的管理集群，我总是会思考几个方向的问题：
在长期大规模集群治理实践过程中，也针对各个集群的各种疑难杂症形成了自己的西药(trouble shooting)丶中药(Returning for analysis)丶健身预防(On a regular basis to optimize)的手段及产品。 下面通过自我的三个灵魂拷问来分享一下自己对于大规模集群治理的经验及总结。 灵魂拷问1 集群量大，到底有啥特点? 集群数量多，规模大：管理着大小将近20个集群，最大的xxx集群和xx集群达到1000+节点的规模。 灵魂拷问2 平时集群容易生什么病，都有哪些隐患呢? 集群在整体功能性，稳定性，资源的使用等大的方面都会有一些痛点问题。 常见的文件数过多丶小文件过多丶RPC队列深度过高，到各个组件的版本bug，使用组件时发生严重生产故障，以及资源浪费等都是集群治理的常见问题。 灵魂拷问3 对于集群的突发疾病如何精准地解决故障? 对于集群突发的故障，平台应具备全面及时的监控告警，做到分钟级发现告警故障，推送告警通知，这是快速解决故障的前提保障。 对于集群的慢性疾病，应该从底层收集可用的详细数据，分析报告加以利用，通过长期的治理来有效的保障集群的深层次健康(具体请阅读《运维老司机都想要掌握的大数据平台监控技巧》)，并开发形成能实实在在落地企业的数据资产管理丶数据治理产品。 下面将针对上面的9个集群问题或故障逐一解答如何解决。 1、底层计算引擎老旧，业务加工占用大量资源且异常缓慢。 集群底层使用MR计算引擎，大量任务未进合理优化，大多数任务占用上千core，上百TB内存，且对集群造成了大量的IO读写压力。 解决手段：通过监控“拎大头”，找出消耗资源巨大的任务，通过业务，计算引擎，参数调优来优化集群资源使用，提高集群算力。 业务优化：从业务角度明确来源数据，减少加载数据量。 计算引擎优化 ：MR转Spark。 参数调优：小文件合并优化，内存内核调优，并发量调优，防止数据倾斜。 2、xx集群RPC故障问题。 现象概述：XX产线集群提交作业执行慢; 业务数据加工逻辑为读取HDFS新增文件>>>入库HBase; 遍历列表文件周期为5s。 根因分析：    解决方案： 阅读RPC源码：动态代理机制+NIO通信模型。 调整NN RPC关键参数，做对比实验。 1)优化系统参数配置： ipc.server.handler.queue.size;
2)将HDFS千万级目录扫描周期从5s调整为5分钟 3)增加集群RPC请求分时段分业务模型深度监控 3、xx集群由于承载对外多租户，面对各个租户提出的集群生产环境的需求都不一致，造成集群环境复杂化，yarn资源打满，并且容易出现负载过高的接口机，加重运维成本。 解决手段： 集群环境多版本及异构管理： 配置多版本Python环境，并搭建私有第三方库。  配置多版本Spark，Kafka环境。  实时监控yarn队列资源使用，监控yarn应用任务，重点优化。  配置明细接口机监控，优化接口机负载。 接口机从基础指标，top分析，CPU内存消耗过大的进程多维度监控，及时的合理调整优化接口机的调度任务，降低接口机负载。    4、xxx集群由于文件数过多，导致集群运行缓慢，NameNode进程掉线。 集群的文件对象达到九千多万。且集群的读写IO是写多读少。NameNode启动需要加载大量的块信息，启动耗时过长。 解决手段： 计算引擎优化 ：尽量使用Spark，有效率使用内存资源，减少磁盘IO读写。 周期性清理：根据HDFS业务目录存储增量，定期协调业务人员清理相关无用业务数据。 块大小管理：小文件做合并，增加block大小为1GB，减少小文件块数量。 深度清理：采集监控auit日志做HDFS文件系统的多维画像。深入清理无用数据表，空文件，废文件。 5、HDFS数据目录权限管理混乱，经常造成数据误删或丢失。 由于下放的权限没有及时回收，或者一些误操作造成了数据的误删和丢失。 解决办法： 业务划分：明确梳理各个业务对应权限用户，整改当前HDFS数据目录结构，生产测试库分离控制。 数据生命周期管理：  6、yarnJOB造成节点负载过高影响了其他job运行。 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
