nosql@vip — 唯品会nosql平台⾃动化发展及运维经验分享

39
2015中华数据库与运维大会 2015.06.06 ZHDBA.COM 中华数据库业协会

Upload: leo-zhou

Post on 14-Apr-2017

242 views

Category:

Technology


1 download

TRANSCRIPT

2015中华数据库与运维大会 � 2015.06.06 !

ZHDBA.COM中华数据库⾏行业协会

NoSQL@VIP!— 唯品会NoSQL平台⾃自动化发展及运维经验分享!

About Me -- 赵新宇!•  唯品会NoSQL平台负责⼈人!

•  资深数据库⼯工程师 !

•  前新浪微博⾼高级DBA!

•  Pythoner/Gopher!

•  Weibo: @RainSlytherin!

•  Weixin: @tju_newrain!

•  欢迎微博互粉或微信交流! !

•  招聘数据库/⾃自动化运维/源码开发等⼈人才! !

⺫⽬目录!•  从数据库规模的演变看业务的快速发展!

•  唯品会NoSQL⾃自动化运维平台的建设 !

•  Twemproxy中间层的改造及⼤大规模部署!

•  负载均衡服务化(Lbaas/Libra)!

•  唯品会Redis/MC/Twemproxy运维经验!

•  后续的发展思路探讨!

业务的快速发展!

2014 Now

Redis

Memcached

Twemproxy

Total

* 业务的快速发展,运维疲于奔命,持续重复单⼀一⼜又繁琐的⼯工作、与业务扯⽪皮沟通。!

3000

运维标准制定!

软件选型

使⽤用规范 资源分配

申请标准 服务部署

* 运维标准化的五个阶段分别制定严格的标准和规范。

软件选型标准!

Data Structure? Proxy or Client? HA? Persistence?

*⼤大部分情况下Redis都可以取代MC;DBA深⼊入到业务架构,决定选型和数据结构设计。

资源分配⽅方案!

产品树 重要程度 核⼼心业务 重点业务 次要业务

*简单清晰的资源分配⽅方案,让⾃自动化分配逻辑简单明了!

服务部署标准!

Port Version Config Yum

全局递增 单机多版本 统⼀一配置 ⼀一键安装

*统⼀一各种标准,简化各个流程,让⾃自动化部署更加⽅方便!

⾃自动化运维!

智能化

服务化

模版化(批量化)

可视化(产品化) √√

*⾃自动化运维的四个阶段,我们仍然是从头开始...

运维服务化!

* 集成基础服务,统⼀一访问模式,统⼀一API规范;基于API打造上层⾃自动化运维系统及⼯工具。 !

常⽤用的API服务!

•  /cluster/instances -- 获取某个业务的实例配置!

•  /redis/start -- 启动redis服务!

•  /memcached/stop -- 停⽌止MC服务 !

•  /twemproxy/clone -- 扩容twemproxy服务!

•  /zabbix/status -- 获取某个业务的监控状态!

•  /alert/send -- 发送报警!

基于API的Web管理系统!

* 包括:集群管理、服务器管理、实例管理等;集成Puppet、Zabbix及软件部署及资源展⽰示等功能。!

基于API的命令⾏行⼯工具 !

* 在Web管理系统以外,基于API开发命令⾏行⼯工具hedwig,基本可以完成95%的基础运维⼯工作。!

基于API的⾃自助申请部署系统 !

* 根据⽤用户申请的资源规模以及基于zabbix历史数据进⾏行分析,智能设定分⽚片规模及完成资源分配。!

运维可视化!

•  业务数据的多维度展⽰示 !

•  Zabbix + 定制化Dashboard!

•  全链路数据分析系统 -- Titan!

Dashboard — 实时、历史、对⽐比 !

* 基于zabbix数据开发的⽀支持实时、历史、⼤大促对⽐比等功能的Dashborad⻚页⾯面。!

全链路数据分析系统 -- Titan!

* Python脚本使⽤用tcpdump采样抓包写⽇日志 -> flume监控⽇日志变化将数据写⼊入kafka集群 -> 再经过spark实时分析存储在hbase中 -> 最后基于分析数据开发展⽰示系统Logview。!

Titian-⽇日志格式内容!

10.xxx.xxx.xxx 10.xxx.xxx.xxx 6379 1433080263 185 44 8 get xxx

来源地址 ⺫⽬目的端⼝口

请求时间

响应时间

请求⻓长度

响应⻓长度

具体命令 ⺫⽬目的地址

* 通过Python脚本解析⺴⽹网络包,获取上述所列格式。其中具体命令再根据对应的软件协议进⾏行进⼀一步解析。

Titan-响应时间分布!

* 提供响应时间分布,执⾏行次数分布,执⾏行⽐比例分布!

Titan-hot/slow key/query!

* 提供响应时间分布、hot/slow key/query,请求分布,请求占⽐比等功能。!

Titan-请求来源!

* 提供来源业务池信息,来源IP占⽐比,请求次数,响应时间占⽐比!

Titan-全站调⽤用拓扑!

* 基于来源IP数据与CMDB信息,绘制全站数据访问拓扑图; * 资源访问及混⽤用情况⼀一⺫⽬目了然,出问题直接定位相关业务⽅方。!

缓存中间层的使⽤用!

•  多个中间层功能对⽐比!

•  Twemproxy上线!

•  Twemproxy功能改造!

•  Twemproxy+Sentinel+ConfigCenter!

多种中间层⽅方案对⽐比!对⽐比维度 新浪cache service 腾讯ckv 淘宝tair 京东jimstore 百度bdrp

是否使⽤用twemproxy yes no no no yes

是否属于proxy模式 yes yes no no yes

是否存在config service yes yes yes yes yes

是否需要开发client yes yes yes yes no

是否使⽤用ssd冷热分离 no yes no yes no

是否⾃自动多副本 yes no yes no no

是否使⽤用replication复制数据 no yes no yes yes

是否⽀支持扩容后⾃自动数据迁移 no yes yes yes no

是否读写分离 yes no no yes yes

是否⾃自动容灾处理 yes yes yes yes yes

*根据开放⽂文档分析得出,实际的具体数据可能出现偏差。

Twemproxy中间层的优缺点!

Pros

Cons TCO ConfigHA SLB Levels

ShardCode DeployConfig

*喜忧参半,没有⼀一劳永逸的⽅方案,特定阶段解决特定问题!

Flow

Twemproxy上线!

* 2015年5⽉月19⽇日-5⽉月25⽇日的统计数据,⽇日请求量在150亿左右。!

2015/5/19 2015/5/20 2015/5/21 2015/5/22 2015/5/23 2015/5/24 2015/5/25

150

Twemproxy功能改造!

•  ⽇日志⾃自动切割!

•  配置动态更新!

•  Sentinel+配置中⼼心!

•  Replication Pool!

Twemproxy+Sentinel!

* Twemproxy与Sentinel同机部署,本机Sentinle只监控本机Twemproxy后端Redis资源。 * ⼀一期Sentinel直接更新Twemproxy配置,⼆二期引⼊入Config Center 。

Twemproxy+Replication Pool!

* 两层⼀一致性hash环,同时双写,第⼀一层miss后读第⼆二层; * 可做到每⼀一层的平滑扩缩容操作。

负载均衡服务化!

•  Libra(LBaaS) !

•  功能抽象!

•  架构(API+Daemon+SSH)!

•  管理系统展⽰示!

Libra-抽象化数据模型 !

* 将负载均衡各功能抽象化成数据模型,可⽀支持多种负载均衡软件接⼊入,如:LVS/Haproxy等。!

Libra — 整体架构图!

* 基于Tornado的API Server与基于Fabric的Task Schedule/Executor组成负载均衡服务的主要部分。!* 不同的负载均衡软件通过开发定制的Task Schedule以插件的形式接⼊入。!

Libra-管理系统展⽰示 !

* 后端⽇日志前端展⽰示,问题处理简单明了。 * LVS的各种常规运维操作不再需要再登录终端敲命令,改配置⽂文件了,全部⾃自动化。!

点击应⽤用名称进⾏行real server配置更新!

运维实战案例!

•  Redis TTL 为0!

•  Twemproxy全部请求超时!

Redis TTL=0!!

结论:如果⼀一个redis作为slave,且将slave-read-only设置为off,并写⼊入了⼀一个带有TTL的key时, 当key过期后,该key是不会被Redis删除的,且TTL在过期后永远为0。(3.0版本修复) 注意:在进⾏行服务迁移等情况所构成多级复制链的时候,在relay上进⾏行过期key的读写处理的时候 需要注意TTL带来的问题 详细过程:http://slytherin.sinaapp.com/?p=300!

TTL=0!

TTL=0!

TTL!= 0!

Twemproxy Timeout!

* 现象:单个MC超时,导致⼏几乎全部请求都超时。同时Twemproxy内存短时间内激增! 15min后才⾃自动剔除!(tcp_retries,tcp rto) * 结论:使⽤用Twemproxy务必注意添加timeout参数! * 推荐视频:http://redisconference.com/video/running-twemproxy-in-production/?iframe=yes!

发展与展望!

•  运维模板化、智能化 !

•  Redis Cluster/Tair/Gemfire/Others集群⽅方案!

•  Mesos+Docker资源隔离与资源调度!

•  ⾰革⾃自⼰己的命 — from 诸超 !

Thank you!!

ZHDBA.COM中华数据库⾏行业协会