携程数据库高可用和容灾架构演进

EdithRobert 发布于1年前
0 条问题

 

作者简介

 

郜德光,携程技术保障中心高级数据库经理,负责数据库相关的运维工作,参与了SQL Server和MySQL的高可用以及数据库容灾建设。喜欢钻研技术,对数据相关的技术一直保持着浓厚的兴趣。

网站稳定性对任何一家公司来说都至关重要。业务长时间中断,不仅仅意味着收入的损失,更可能会失去客户。数据库的稳定性和HA/DR建设是网站高可用建设非常重要的一个环节。

本文分享了携程数据库(SQL Server,MySQL和Redis)的高可用和容灾的重构历程,以及重构的原因。也会简单分享一下DR切换工具,该工具可以一键将主站数据库切换到DR站点,用于在主站IDC故障时,快速恢复数据库服务。

1.0时代【1999~2008】

自携程1999年成立到2008年左右,公司数据库产品主要是SQL Server。

这个阶段是公司初创和快速发展时期,以优先发展业务为主。数据库的架构设计比较简单。高可用通过数据库的镜像技术来实现。镜像主要的架构如下图所示。甚至为了节省服务器资源,我们采用多个主数据库共享一个辅助数据库服务器的方式。

携程数据库高可用和容灾架构演进

 

这种镜像方式搭建和运维都比较简单。主机如果出现故障,先尝试重启能否解决,如果不能恢复,则通过镜像切换的方式,切换数据库服务到从机。

这种HA架构比较简单、粗糙,优点是不需要群集和共享存储等资源,成本低。缺点是主机故障时没法自动转移,业务恢复速度较慢,严格来讲还不具备HA的能力。

前期对于支撑当时业务发展来说已经够了,随着后期业务快速发展,已经无法满足业务稳定性的需要。

2.0时代【2008~2012】

这一阶段,业务进入快速发展阶段,对数据库的依赖也越来越重。开始大量采用SAN共享存储来存放数据。单台数据库已无法支撑业务的压力,因此,也对数据库架构进行调整,引入了复制分发,用于读写分离。

架构如下图所示:产品的价格首先录入到录入数据库。通过SQL Server自有的表级别的复制分发技术,把数据传递到多个产品数据库,以供业务访问。如果业务访问压力大,则通过添加产品查询服务器的方式来进行扩容。

携程数据库高可用和容灾架构演进

对于非读写分离场景的数据库,高可用是通过Failover Cluster群集方式。DR依旧采用数据库镜像的方式。

如下图所示:一旦服务器主节点硬件故障,则会通过自动故障转移,转移业务到服务备节点,切换时间大概在2分钟左右。主备服务器都连接后台共享存储。

同时,还对数据库服务搭建了镜像,一旦存储发生故障,主备服务节点都不可用的情况下,则通过切换镜像到镜像服务器上,镜像服务本身也是一个Failover Cluster群集,也做了高可用。

由于SQL Server的镜像服务器平时是不可读的,我们还通过一个日志传输服务,搭建了只读数据库,以供BI取数或查询。这个只读数据库也用于验证数据库备份的有效性。

携程数据库高可用和容灾架构演进

由于业务的需求越来越复杂,数据库的架构开始逐渐复杂起来,主要体现在:

1、复制分发架构过于复杂,如城市表,基本上所有部门都需要使用,通过拉复制分发链路,把城市列表信息传递给其他部门的数据库,能快速解决问题,但随之而来,使得数据库的关系变成蜘蛛网状。维护起来相当困难。

2、过于依赖底层的SAN存储。SAN存储内含相当复杂的存储技术和网络技术,复杂一点的问题就需要依赖供应商来解决。

2012年,微软推出了AlwaysOn高可用性组,可以不依赖于共享存储。AlwaysOn高可用性组同时也具备读写分离的功能,而且也能做容灾。所以,我们逐渐朝AlwaysOn这个架构演进,并用SSD来代替SAN存储。

3.0时代【2012~2014】

在2014年左右AlwaysON技术已经非常成熟,对于多IDC环境下支持也已经非常好,是SQL Server主流的HA/DR方案解决方法。

因此在2014年后,我们开始逐步把SQL Server改造为Always ON架构。架构如下图所示:写还是一个节点,但可提供多个节点的读。并且其中的一个节点是同步模式,用于做写节点的高可用。

携程数据库高可用和容灾架构演进

纯AG架构

上面新的架构非常灵活。由于2014版本已经支持8个只读副本,AlwaysOn延迟又低,因此完全解决了群集+镜像架构中遇到的复制分发读写分离架构瓶颈的问题,同时也不在需要为离线查询和ETL取数部署单独的只读数据库。读副本的备份功能也大大降低了备份时主机的压力。

在推进Always ON新架构过程中,我们也逐步用SSD来取代原有的SAN。除了SSD的价格越来越便宜容量越来越大,相比SSD,SAN存储对DBA基本是黑盒子,需要专业的运维团队支持,运维成本更高。

4.0时代【2014~2018】

SQLServer AlwaysON技术比较成熟,但其存在一个关键的问题,在于AlwaysON技术是闭源的。DBA难以深入了解该技术的底层细节。虽然脱离了SAN存储的依赖,但还是依赖于Windows的Failover Cluster集群。

因此,2012年开始在携程内部逐步推广开源的MySQL和Redis 。在推广MySQL的时候,我们意识到MySQL的性能比不上SQL Server, 所以同时推广数据库分库分表方案和前端Redis缓存。

MySQL的高可用和DR是通过MHA(Master High Availability)来实现的。具体架构如下:

携程数据库高可用和容灾架构演进

通过MHA管理节点,来监听主节点的可用性情况,一旦发现主机不可访问,则切换到slave节点。MHA的高可用模式,既兼顾到高可用,也兼顾到DR。对于读写分离的需求,主要是通过分库分表方案来进行的。部分有采用读写分离。

对于MHA的方式,是通过域名/虚拟IP的方式,提供给业务使用。其最大的风险的是脑裂。主机没完全挂死,同时主从切换后,新的主机开始提供业务访问,就产生了脑裂。为了解决这个问题,我们在数据库访问层,引入了动态数据源技术,不通过域名/虚拟IP的方式,而是通过实IP的方式。提供业务访问,有效的降低了脑裂的风险,同时不通过域名解析,能加快主从/DR切换时间。

随着MySQL的引入,Redis也逐渐广泛使用起来。由于Redis的Key/Value访问速度非常快,目前携程对Redis的依赖比对数据库还重要。Redis本身需要有高可用和DR的方案。

对于Redis,借助框架部门开发的中间件CRedis,用于Redis的访问和高可用控制。

简要架构如下图所示:

携程数据库高可用和容灾架构演进

说明如下:

1、业务访问的时候,通过引用框架的客户端组件读取配置信息。Redis切换由哨兵发起,并且Credis配置能及时捕获,并通知客户端IP和端口的变化。

2、对Redis拆分多个Group,以避免访问热点。每个Group包含多个Redis实例。

3、Redis实例Master/Slave在一个机房, 另外两个实例Slave-DR在另个机房。

4、访问请求通过CRedis配置路由到指定的分片。

5、Slave-DR实例和主实例的数据同步通过框架同步工具XPipe来实现。XPipe 已经开源,更多信息请访问:https://github.com/ctripcorp/x-pipe。

为应对日常DR演练以及硬件故障时快速恢复业务的场景,DBA设计开发了集中、一键式DR自动化切换工具,支持所有数据库产品。用来帮助DBA快速、安全的完成数据库切换。

DR切换工具支持不同的切换维度,覆盖了所有的场景:

1、单个或多个数据库群集,应对单机故障或日常维护等场景;

2、单个业务线下所有数据库群集,应对DR切换演练场景;

3、IDC下所有数据库群集,应对主IDC故障场景;

目前为止已经利用DR工具成功完成了200+次的切换演练。下面是用DR工具准备单群集切换的一个例子:

携程数据库高可用和容灾架构演进

如上图所示,工具中搜索到对应的群集后,工具会根据元数据信息展示群集的整体架构:节点(名字、IP地址等)、IDC、复制关系。

每个节点提供2种切换方式:

1、强切工单,强制切换。主机或主站down时,可能有数据丢失;

2、演练工单,正常切换。主机可用时,演练或计划内主机维护时使用;

生成的工单后续可以自动执行。

DBA把DR复杂的切换恢复流程全部集成工具里面,工具同时支持API根据不同维度快速批量生成切换工单,支持并发切换,可以快速完成业务的切换恢复。

为保证DR工具的高可用性,在设计DR工具时也消除了工具对单个IDC的依赖。只要保证一个IDC可用,就可以通过工具发起切换。

从以上架构的演变过程,我们可以看到是从简单 à 复杂 à 简单的一个演变趋势,但是稳定性和可用性有了质的飞越。 数据层本身变得越来越简单,而扩展了大量的辅助架构,来提升自动化运维能力。

希望以上的分享对大家有所帮助。

【推荐阅读】

11月23日上海,

携程首届技术峰会,

一起来聚~

戳下图了解详情

↓↓↓

携程数据库高可用和容灾架构演进

携程数据库高可用和容灾架构演进

查看原文: 携程数据库高可用和容灾架构演进

  • browngoose
  • yellowtiger
需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。