我们是这样运维HBase集群

今天和@淘大舞 @dun_2010 @毅毅 @知付托 一起喝酒，聊了好多，这是一个虽然苦逼但是值得骄傲的团队。@淘大舞 说的话，如果说hbase的运维，国内有人比我们做的好，那就是我们还没有做到位。这样的环境，这样的氛围，这样靠谱的开发支持@庄庄2049 ，追求top，那是基本目标。

喝了酒，虽然头晕晕的，但既然是有感而发，就唠叨几句。

hbase发展到几天，从一开始的极度不稳定，逐渐成熟起来。一开始的监控，停留在最基本的ganglia，而监控的项也非常有限。无非就是request，load，memory，io 和network。 后来多了些，比如有了compation queue的监控。但是出现问题，就抓瞎。

后来，@庄庄2049 团队的开始潜心将hbase更多的监控埋点打入ganglia，从而大大改善了这个过程。从代码路径的一些细节，比如blockcache的命中率，memstore的大小，hlog的大小，gc的次数和时间，handle queue，read response time，write response time，fail write/read request, flush 流量，compaction 流量，现在，我们基本上能够做到在出问题前3~4个小时提前将问题处理掉。因为，监控总是比问题的发生来的更早一些。而每一次的出问题，又进一步加强这样的监控。

举个例子，当时先是一台机器的read response time 变高，而check 一下监控，发现命中率降低，再check 下 gc情况，发现是一次cms gc 唤出了大量的cache。 这样几个监控点，就可以迅速地定位到问题的产生。基本上集群我现在都不需要每天上去看。报警就是报告。而出了问题，查查监控，看看报警，一般的问题就能快速定位下来。

现在，我们两个运维人员，运维着整个集团20多个业务，大大小小20多个集群。但是，依然还是有时间去学习新的知识，因为，hbase的可运维性，大大地增强。

为了防止热点数据 和大请求的产生，我们 增加了黑名单，并对表、客户端的请求数进行了监控。hbase不能像mysql一样，对那些大sql直接kill掉，对于前端的疯狂请求，是hbase最头疼的地方。有了黑名单和客户端请求数监控后，我们能够在这样的层面，做一些保护工作。而后期，我们还会考虑对表、Region做更多的保护。

动态地调整参数，在这次大促中也发挥了很大的作用。我们对写入压力大的系统，可以动态增加flush和compaction thread的数目。从而将有效地提升。然而，hbase 对网卡的压力，较一般的数据库要大得多，因为它基于hdfs，写一份数据，需要同时拷贝两份到其他的机器上。而写压力增大后，compaction 会更加地频繁，从而增加更多的写，进一步加剧这样的问题。 而读一样会对网卡产生额外的压力。因为不能命中缓存的数据，必须从远端读，而一次虽然请求1K的数据，却要请求64K的数据（1个block），这样，一旦缓存命中率降低，本地化率随着多次的balance和集群规模的扩大，对集群out的网卡产生了不小的压力。我们一个业务，5Gbps的写入，10Gbps的读，内存命中率在90%，本地化率在80%的情况下，100台服务器，每台机器的网卡高峰期依然接近600Mbps。差不多是5倍的读写放大率。这也是现在hbase的一个问题。要把机器利用起来，首先要解决网卡的瓶颈。

所以，推动hbase性能的进一步提升，仅仅通过优化磁盘io，优化内存，优化压缩，都是疗效很小的。因为，这些都远没有达到瓶颈。很简单的一个数学题，现在一般都是10块SATA数据盘，每块盘，就算30MB/s的读写，全部能利用起来，至少也是300MB/s, 而网卡呢？千兆网卡，在保证服务质量的情况下，80MB/s 就已经很高了。

有两个办法，一是提升本地化率，通过优化balance 算法，让更多的数据通过本地读到。这一点，facebook就已经这样做了。因为他们的网络环境更差。更直接的办法，是改造网络。一提到这个时候，有人就会想，那上万兆网卡好了。哥，那样太贵了。万兆网卡的交换机，不是一般能买得起的。我们在之前，首先推动网工将网络保证了1：1 的收敛比。后面，因为我们本身是双上联，双网卡，开成两个active 模式，将网络由1Gbps 提升到2Gbps，乐观估计，应该能节省一半的机器。另外，就是想办法提升本地化率了。并将compaction变得更加的有效率。

无论是hbase还是hadoop，一个重要的特点，就是重开发。以前那种，认为有两个牛逼的dba就可以搞定mysql，oracle的想法，并不合适 像hbase这样并不是很成熟的软件。而且，哪怕是运维人员，也至少要能搞懂java，读过里面的部分核心代码。对风险有全局的把控。比如，我会很谨慎开发在split上面的改动，因为这块的是最复杂的，牵涉到事务。我也会很介意他们在hfile上面的变化。而如果是增加线程，增加监控，则会激进一些。

但是一定要支持开发。传统数据库，那种保守再保守的态度，也要有所改变。这是一个快速演进的系统。虽然有的开发不是那么有经验，开发的东西有bug，但是风险我们hold住，还是要勇敢地尝试。有时候，我比开发还激进，让他们快点把东西开发好，我要部署上线。因为我自信自己能控制住风险。我也知道，时间紧迫，hbase必须有更给力的发展。顶住更大的压力。跌点跟头，不怕，关键时刻，不能掉链子。最近，也开始尝试做演习。通过shutdown机器，kill 进程，拔硬盘等极端方法，在线上真实演练恢复时间。而业务方也很支持我们，只有平时多练兵，才能更有信心。

我会很关心jvm的发展，因为目前为止，老实说，jvm依然不能很好地掌控大内存。大内存，往往一次new gc的pause时间就达秒级，而full gc，cms gc有时更是达到10几秒，几十秒。给线上系统带来巨大的抖动。而马上，96GB的内存成为了主流，hbase在jvm依然不给力的情况下，必须考虑自己有能力不依赖jvm去管理好大内存。比如，现在，我们就开始尝试做2级缓存。将block cache和memestore的一部分，交由自己的二级缓存来管理。这样，以后也能用ssd，fusion io之类的高速存储设备了。

写着写着，酒也醒了。前面的文章，就当是糊里糊涂地乱吐槽吧。不要当作严肃的学术文章去读。另外，我就希望，开发不要总是搞些牛逼的东西，非找那些有难度的东西做，为了体现自己的kpi。可运维性，永远是所有软件最大的课题。

• —软件人才免语言低担保 赴美带薪读研！—