我们是这样运维HBase集群

标签: 运维 hbase 集群 | 发表时间:2012-11-15 23:55 | 作者:
出处:http://www.iteye.com

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

 

 

而最后的目标,是只要是集群运维,就没有我们搞不定的。无论是 hbase,ob, mysql, 在运维层面,应该有一致的东西。精髓 无非几个: 1. 细致的监控。有效的报警。在代码路径的每个细节,都有详尽的监控 2. 向上推动应用改造, 向下推动硬件和网络环境改造。

 

 

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

 

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。可运维性,永远是所有软件最大的课题。

 

 

 

 

 

 

 

 



已有 2 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [运维 hbase 集群] 推荐:

我们是这样运维HBase集群

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

HBase高可用集群运维实践

- - IT瘾-bigdata
文 | zengweizhan. 随着越来越多的业务选择HBase作为存储引擎,对HBase的可用性要求也越来越高,对于HBase的运维也提出了新的挑战. 目前运维集群超过30+,而且接入的业务类型繁多,对于性能要求也不完全一样,这是今年面临的问题. 从15年开始,结合京东的业务情况,基于大数据平台,实现用户接入使用全流程自动化.

从远端集群拷贝HBase表到本地HBase

- - 开源软件 - ITeye博客
背景描述:想导出 服务器HBase里面的一张表remine_4520及其数据,我能通过java连接HBase库,浏览器能访问master的信息. 方案:版本一样的话直接distcp表目录过来   然后hbck一下就行. HBase0.94.8,Hadoop 1.1.2,集群使用了loz压缩,远端HBase master节点域名为namenode.

使用zookeeper管理多个hbase集群

- d0ngd0ng - 蓝色时分
    zookeeper是hbase集群的"协调器". 由于zookeeper的轻量级特性,因此我们可以将多个hbase集群共用一个zookeeper集群,以节约大量的服务器. 多个hbase集群共用zookeeper集群的方法是使用同一组ip,修改不同hbase集群的"zookeeper.znode.parent"属性,让它们使用不同的根目录.

[hadoop] 基于Hadoop集群的HBase集群的配置

- - CSDN博客系统运维推荐文章
       a> 已经配置完成的Hadoop集群.        b> 所需要的软件包. 2>  单独安装的ZooKeeper集群,不基于HBase集群管理.        a> 在master01上解压zookeeper-3.4.4.tar.gz.        b> 修改Zookeeper的配置文件.

HBase入门笔记(四)--完全分布式HBase集群安装配置

- - 学着站在巨人的肩膀上
HBase 是一个开源的非关系(NoSQL)的可伸缩性分布式数据库. 它是面向列的,并适合于存储超大型松散数据. HBase适合于实时,随机对Big数据进行读写操作的业务环境. 关于HBase的更多介绍请参见 HBase项目官网.     本文环境与上一讲-- 完全分布式Hadoop集群配置一致.

Hadoop集群安装&Hbase实验环境搭建

- - CSDN博客云计算推荐文章
1.安装ubuntu10.04操作系统. 安装成功后,系统也会有相应提示:. sudo vi /etc/inetd.conf并加入以下一行. sudo vi /etc/xinetd.conf并加入以下内容:. sudo vi /etc/xinetd.d/telnet并加入以下内容:. 重启机器或重启网络服务sudo /etc/init.d/xinetd restart.

分布式集群环境hadoop、hbase、zookeeper搭建(全)

- - CSDN博客云计算推荐文章
集群环境至少需要3个节点(也就是3台服务器设备):1个Master,2个Slave,节点之间局域网连接,可以相互ping通,下面举例说明,配置节点IP分配如下:. 三个节点均使用centos 6.3系统,为了便于维护,集群环境配置项最好使用相同用户名、用户密码、相同hadoop、hbase、zookeeper目录结构.

linux集群运维工具:clustershell和pssh

- - Linux - 操作系统 - ITeye博客
由于需要安装hadoop集群,有10台机器需要安装,一开始打算用SCP复制,后来觉得不可接受(实际现场可能数倍的机器集群,就是10台也不想干). 后来在网上找了,发现了clustershell和pssh这两个工具. 这两个工具随便用其中一个就可以了. 环境说明:centos6.5机器10台. 需求:确定一个主机A,通过在A上执行命令即可同步在其他节点上执行.

从未降级的搜索技术 – HBase集群升级与优化

- - 搜索技术博客-淘宝
战争从来都是拼后勤拼平台支撑的,天猫双十一这一天对于我们搜索事业部来说,就是一场高强度的数字化战争. 为了这一天,各兄弟业务线的战友们已经摩拳擦掌,纷纷亮出各种新式武器,而我们原有的离线系统平台却渐渐显出疲态,慢慢被来自各业务线的不断提升的压力需求搞得捉襟见肘了. 个性化搜索实时数据处理平台(Pora)在双十一将正式亮相,当时我们预计会有数以十亿计的新增HBase读写请求,如果不进行升级优化,原有的离线集群预计将无法承受这一前所未有的压力;天猫业务线的增量在双十一更是重中之重,届时预计会有数倍甚至十多倍的增长,不断流,不延迟对于原有的离线集群来说也是巨大的考验;主搜、国际站等业务线也都对底层平台提出了越来越高的要求,凌晨全量的时间极其有限,不能出现任何闪失.