背景
一个月左右zk挂了2次,在此期间
Mafka和其他服务不可用,因为业务(使用不当)原因导致zk挂掉,间接影响其他服务(包括mafka)可用性,目前线上多个业务和多种服务共同一套mobile-zk集群,
只要一个业务使用不当,对zk造成影响或不可用,就会影响其他业务,所以现阶段拆分zk集群,做物理隔离,把mobile-zk集群按照业务分拆为多个zk集群。为mafka服务建立独立zk集群。
问题
2个原因造成zk集群宕机
其一是业务混布,多个业务依赖同一个mobile-zk集群,其二是zk集群部署存在问题,zk实例部署没有做隔离,一个虚拟机部署3个zk实例。
业务使用zk不当
- 错误把zk当做kv存储使用。
- 创建海量连接,耗尽资源最终压垮zk集群
- 其他不当操作等
前期zk部署方案
当时zk集群中所有节点参与选举,客户端通过配置ip列表连接本地机房zk节点。由于业务使用不当很容导致所有节点挂掉导致zk集群不可用,因为Kafka强依赖zk服务,这直接影响Kafka的可用性。
后期zk改进部署方案
部署改进:mafka-zk集群包括三台leader/follower和若干observer,每个机器上跑一个zk实例;客户端通过域名与本机房的observer连接,不直接与选举节点连接,观察节点不够可以随时扩容。迁移收益:可扩展性:客户端通过域名与本机房的observer连接,服务可以透明扩容和升级。可用性:mafka-zk集群包括三台follwer/leader和若干observer,客户端只访问observer,他的任何操作不会导致整个集群挂掉,不会影响zk集群可用性。
其他改进:流控和ip连接数限制,加强监控报警。
Zookeeper监控
可以使用淘宝的开源工具TaoKeeper进行监控。Zookeeper的监控包括下面几个方面:
1、机器的CPU、内存、负载、硬盘IO利用率等基础监控,这些均可以网管系统实现;
2、ZK日志目录所在磁盘空间监控,这可以针对性的监控;
3、各节点的进程监控,配置自动拉起等;
4、各节点的连接数监控,配置峰值告警;
5、各节点的Watcher数监控,配置峰值告警;
6、使用四字命令,对每个节点进行检查,确保进程不僵死;
7、节点存活个数监控;