系统高可用专项

背景

• 晨刚和治锌反馈kafka不稳定，经常commit超时，业务受到一定影响

• 10-02 zookeeper full GC导致集群震荡

        主要的原因是现在集群不够稳定，尤其当有大任务运行、集群间发生数据同步或数据平衡时，经常单机的网络IO会打满，导致一些服务间的心跳超时或连接超时，影响服务的稳定。

        前期部署节点不足，角色复用混布太多，现在集群部署不够合理，需要优化。

集群现有问题

• 角色混部

  • kafka与DataNode/NodeManager
  • NameNode与DataNode/NodeManager
  • ResourceManager与DataNode/NodeManager
    • 这两台节点还部署了mysql、hive、hue、oozie，clouderaManager等
    • 但是这些角色使用资源不是很多，可以与ResourceManager混布

• zookeeper复用

  • Kafka和集群高可用使用的zookeeper复用

• 关键角色使用的机器不够稳定

  • NameNode

  • ResourceManager

  • ClouderaManager

  • Zookeeper

• 网络问题

  • 最近一段时间网络不是很稳定

  • Ethan说是因为机柜间带宽跑满导致的丢包和延时

  • 暂时无法解决，等Ethan后续优化

混合部署的缺点

        Hdfs和Yarn的资源限制无法限制IO和CPU，混合部署导致大任务占用过多资源，影响其他服务的可靠性。比如当IO占用较高时导致Kafka写入失败，读取超时等。最好DataNode/Nodemanager单独部署，不要和其他角色混布（impala、hbase强等依赖HDFS的除外）

        zookeeper复用，有可能导致zookeeper不稳定。比如，随着kafka的topic增多，zookeeper需要的内存增多，更容易触发full GC，可能导致集群震荡。集群高可用使用的zookeeper应该拆分出来，不要与kafka复用，保证集群稳定

关键角色迁移

49-55节点使用的机器是单网卡，用来做namenode等角色不太合适，应该迁移角色，让这几台回归datanode

解决方案

• kafka独立部署

• zookeeper拆分，集群高可用使用的zookeeper单独部署

  • 可以与journalNode混布，但不能与kafka等组件混布

• 关键角色迁移

  • 关键角色可以迁移到性能较好的机器

  • 目前看来，烽火台新采购的机器比较合适，如果烽火台的服务全部改为k8s，机器可以空出来给集群

计划

新的部署方案

由于FHT的服务对kafka要求比较高，需要为FHT单独部署一套Kafka

角色	台数	来源
zookeeper	3	旧集群kafka
NameNode	2	FHT采购机器
ResourceManager	2	FHT采购机器
kafka	5	旧集群flume
kafka（FHT专用）	3	旧集群flume

阶段目标

第一阶段：kafka独立部署，预计11-04完成（本周可以先部署FHT专用kafka，下周迁移kafka）

第二阶段：zookeeper拆分、迁移，预计11-11完成(需要nameNode停机)

第三阶段：NameNode迁移（以下需要依赖FHT服务的K8s化，时间暂不能确定）

第四阶段：ResourceManager及hive等迁移

第五阶段：ClouderaManager迁移