传统业务上云:跨AZ容灾架构解析

Liyiming 2019-06-27

数字化转型浪潮之下,采用云计算服务提升业务敏捷性、降低运维成本,成为了传统企业的优选方案。网易云资深解决方案架构师张亮通过某物流企业客户的实际案例,分享了传统业务系统在云上的架构设计如何满足数据高可靠、业务高可用的需求,并总结了传统业务上云的常见问题和解决方案。

物流企业业务系统上云需求

对于物流企业来说,内部沟通、供应链协同对优化供应链效率提升核心竞争力非常重要。作为行业翘楚,该物流企业客户建立了一个企业级移动办公平台,该平台集成了即时通讯(IM)、企业内部的ERP、OA以及核心供应链信息,用于支持内部员工的内部沟通协作,会议、日程安排以及供应链信息、ERP信息、OA流程审批和办理的查询,平台同时也提供给上下游合作伙伴查询供应链信息,以满足供应链协同的需求。该系统最初部署在客户自建机房中,服务于客户内部员工,但为了给一些大型合作伙伴提供类似的能力,客户同时采用了网易云支撑系统的建设和运行。

客户自建机房和网易云基础设施存在一些差异,例如客户自建机房有共享SAN和NAS,并采用带库和商业备份软件来满足数据合规的要求(存储冷数据、归档),MySQL数据库运行在物理机上,而网易云作为成熟的互联网服务,采并没有提供共享块存储服务,数据库是运行在虚拟机上的。

由于该系统要作为一项业务给第三方提供服务,项目一期覆盖数万名用户,考虑基础设施的差异性,客户最为关注如下四个方面:

  • 数据安全性:影响客户业务的数据,包括员工通信记录、日程和供应链信息等,必须保证最高的安全性和可靠性;
  • 业务可用性:此业务系统是客户为其客户提供的服务,因此对于SLA关注度非常高。客户要求在极端状况下(整个生产站点不可用)需要有快速业务恢复能力;
  • 功能:应用探活、监控告警、内网负载均衡(LB)、内网DNS等功能,直接影响客户的运维能力和部署高可用业务的便捷性;
  • 性能:客户原有数据库使用物理机,采用虚拟机担心性能不足,需要避免高并发场景下会的卡顿甚至崩溃的情况。

网易云跨机房容灾架构方案

客户原有业务系统底层是一个传统的同城主备容灾双机房架构(主机房宕机,则备机房接管),在应用侧采用了Redis缓存、Kafka、内外网负载均衡,是一个类互联网架构。系统采用商业硬件全局负载均衡(GSLB)做站点间的容灾,后端存储有传统的SAN、NAS、磁带库和VTL(虚拟磁带库)等,持久化数据大部分在存储上,通过专线和存储能力做跨站点的快照同步和数据同步复制。一般说来,商业磁盘阵列的高级License会带这些功能,但高级License比较昂贵,且该方案的容灾能力极大依赖于阵列设备的容灾能力,一旦阵列设备出故障,数据存储就危险。此外,Jetty、Java应用间是软负载均衡的设计,对外有硬件负载均衡。

该业务系统在网易云上的部署是一个分步试水、逐步完善的过程。业务系统的即时通讯能力由网易云通信服务(云信)SDK提供底层能力,客户自己做上层的封装,云信和应用系统部署在不同的机房,通过网易云内部高速通信。刚开始的架构相对简单,没有考虑容灾,Redis、Kafka、RDS、NAS都映射原来的系统架构,GSLB取消,用Elasticsearch做日志搜索。

之后是跨机房容灾的完善。针对原有系统,运维部门每隔半年会进行一次容灾切换的演练,所以客户希望云上容灾也能满足数据可靠性、业务可用性的需求。

张亮介绍,云上跨机房容灾根据机房距离和网络延迟,可以分为两种:

  • 一是跨可用区(AZ)容灾,一般用来支持需要双活的业务;
  • 二是跨Region的容灾,一般是异地,两个机房比较远,网络延迟无法满足双活的要求。

网易云为客户设计了跨AZ容灾的方案。客户最初在云主机中自己搭建Redis和Kafka,后来发现需要自己关注监控、高可用,但这是网易云现成的Redis和Kafka服务自带的功能。

传统业务上云:跨AZ容灾架构解析

网易云提供的容灾服务包括:

  • 负载均衡:提供跨机房的负载均衡服务(NLB),每个机房是2个NLB实例(主备),但客户流量进来只看到同一个公网IP——如果生产站点AZ1宕机,路由会实现IP漂移,把IP关联到灾备站点AZ2上,客户不需要关注IP的变化。
  • 数据持久化:提供跨机房的RDS高可用实例,生产站点主备2个实例,灾备站点1个实例(考虑成本因素),通过内部DNS访问,一边的RDS宕机,对于应用来说是无感知的,因为系统会自动把域名解析到灾备站点的RDS实例上。
  • 文件系统服务:通过跨机房的复制做数据同步,对于用户来说,数据持久化不需要管。
  • Kafka:通过MirrorMaker做跨机房同步,它的消费者可以在灾备站点去消费Kafka和消息,如果只是部分服务宕机,系统可以提供跨机房的访问,当然延迟会比同机房高一些,这取决于应用对访问数据延迟的要求,如果延迟要求非常高,可能需要做应用单元化,尽量减少跨机房的访问,把一些对延迟敏感的请求放在一个机房内,这是业务架构上的设计。

张亮补充说,网易云支持应用去访问另外一个机房的RDS,但应用之间的容灾还需要客户自己做跨机房部署。NLB可以通过内网DNS判断请求是从哪个AZ过来的,从而让应用能够正确访问对应的底层服务。

跨Region和跨AZ不一样,后者在同一个VPC里面,前者在两个不同的VPC里面,网络延迟比较高,NLB没有提供跨机房高可用实例,对外IP不一样,需要外部有一个类似GSLB或者DNS的服务去做流量切换。其他的如RDS、Kafka的复制,依赖于VPC Peering,需要在核心交换机上做一些后台操作,让两个VPC能打通(默认内网是不通的),否则需要通过公网再从前端路由绕回来,无法通过机房内部专线直接访问。

跨Region的RPO(恢复点目标)比跨AZ要差,跨AZ的RDS可以做到RPO等于0,两边都写入以后,才能返回“写成功”。而跨Region,一边写完就返回“写成功”,如果数据只是在主站点写成功,尚未复制到灾备站点时主站点宕机,这就会造成数据永久丢失。传统架构下的Oracle RAC跨机房集群、存储双活的方案,其实每一次数据写入都是双写,才能实现双活。

所以,跨Region容灾一般用于两地三中心的异地灾备,业务可用性要求高的情况下,建议客户采用跨AZ容灾的部署架构。对于客户而言,基于云的跨AZ容灾方案,只是在容灾、监控、服务的使用方法上和自建机房有所区别,但满足RPO和RTO的要求没有问题。

张亮补充说,跨AZ容灾切换是客户自己做切换,RPO取决于客户运维团队多久才能感知故障、多久把灾备站点服务配置好,因为客户应用的配置比较传统,提前把后端的服务IP、DNS域名写入配置文件,而不是采用服务注册/服务发现的机制动态发布。如果进行应用微服务化改造,RTO还可以有很大的提升空间。

上云常见问题与对策

对于托管IDC、自建机房的传统行业而言,云基础设施带来的变化确实需要考虑周全。基于网易云支撑传统业务上云的经验,张亮最后总结了传统业务上云的常见问题和解决方案。

传统业务上云:跨AZ容灾架构解析

云上很少有共享块存储。SQL Server提供的Always-On故障转移集群高可用方案需要共享块存储的支撑,但企业现在可以使用无需共享存储的SQL Server高可用方案,比如日志传输、Always-On可用性组等SQL Server 2012及之后的版本都支持的方案,都不依赖于任何共享存储形式。

VPC网络不支持广播、多播,而一些应用需要通过广播、多播的形式做集群。

Keepalived:升级到支持单播的新版本,在配置文件中指定使用单播,即可在VPC网络下正常工作。

Tomcat通过广播支持集群成员通信:一是使用Tomcat-Static cluster membership这种静态方式,通过在配置文件中手动告知集群节点有哪些成员,弹性伸缩比较麻烦,只适合规模小的业务;二是无状态化,把Session从Tomcat分出来,放到Redis之类的服务中。

采用N2N Peer-to-Peer VPN的方案,在VPC网络上再构建一个VPN网络,就可以广播,但这种方式会有性能损耗,可以用于POC测试、概念验证,生产环境慎用。

无物理磁带库。一些行业有合规要求,不经常访问的冷数据会存储在磁带库中。在云上有两种方案:一是通过云服务商提供的VTL存储网关,备份软件连接网关,可以把后端当做磁带库使用;二是现在不少的备份软件已经支持主流云服务商的对象存储服务,直接在备份软件中把数据备份到对象存储,成本比磁盘阵列或者NAS要低很多。

相关推荐