云上RDS架构

概述

越来越多的企业选择上云,最基础的云服务就是IaaS(Infrastructure as a Service)服务,直观理解就是虚拟主机,用户不用再自建机房,自己购买服务器,而是直接向云厂商购买虚拟主机服务ECS(Elastic Compute Service),按时按量付费。对于数据库而言,将数据库能力集成进来,就是DaaS(Database as a Service)服务,我这里主要讨论RDS(Relational Database Service)。因为目前主流云厂商在数据库领域,除了基础的RDS服务,还有新型分布式数据库服务,比如Amazon的Aurora,阿里云的PolarDB等。所以对于用户而言,他们选择在云上使用数据有两种方式,一种是自己买ECS,自己搭建数据库服务;另外一种方式是,直接购买RDS服务。本文主要讨论RDS的链路,RDS链路中的核心组件SLB转发模式,以及RDS中proxy的作用,最后还会提到RDS的高可用解决方案。

RDS链路

1. app+ECS(DB)自建

云上RDS架构

2. app+lvs+DB

云上RDS架构 

云上RDS架构

简单说明下,云上并不提供单独买一个RDS的服务,因为这种场景无法提供高可用能力,所以一般购买数据库服务时,会同时带上SLB作为一套整体解决方案。SLB本质就是基于LVS的改进,LVS工作在IOS七层网络模型的TCP/IP层,属于4层负载均衡。利用IP,Port映射转发能力,提供高可用,负载均衡等能力,RDS正是借助SLB来实现RDS的高可用和负载均衡等能力。LVS主要有几种工作模式,DR模式,NAT模式,FULL-NAT模式,IP-TUN模式以及我们阿里云优化的ENAT模式。

2.1 DR模式(Direct Routing)

核心逻辑:本质是2层转发,SLB-Server与RDS共享一个IP,经过SLB-Server时,SLB-Server将mac地址改为目标RDS的mac地址,将请求包转给真实的RDS;回包时不用经过SLB-Server,DR模式要求SLB和RDS需要配置相同的VIP地址。

云上RDS架构

云上RDS架构

2.2 NAT模式(Network Address Translation)

云上RDS架构

云上RDS架构

核心逻辑:client端不感知RDS真实地址;发包经过SLB时,dip(dest_ip)会被替换成RDS的ip,请求包返回经过SLB时,再将回包源地址改为vip。对比DR模式,请求和回报都需要经过SLB-Server,RDS的ip不再需要是公网地址;与DR模式相同的是,SLB和RDS需要在同一个局域网内。

2.3 FULL NAT模式

云上RDS架构

 

核心逻辑:本质是4层转发,请求经过LVS时,LVS请求的(IP,Port)替换成真实RDS的(IP,Port),回包时,再经过LVS,将回包的源地址改为LVS的(IP,Port),LVS与RDS不再要求在同一个局域网内。所有请求的来回都要经过LVS,效率比较低。

2.4 ENAT模式(Enhance NAT,三角模式)

云上RDS架构

核心逻辑:ENAT模式解决了来回包都要经过LVS问题,具体而言,LVS接收请求后,修改包地址时,会将用户的CIP地址冗余在网络包中,回包时,将包改为(vip,cip),这样就不用再经过LVS了。

3. app+lvs+proxy+DB

云上RDS架构

通过引入SLB,RDS已经具备了高可用的能力,但由于SLB是工作在4层负载均衡,对于应用层协议无法感知,所以当发生主备切换时,所有已经连接在old-master的连接都需要被断掉,对用户来说,就是连接发生了闪断,对于没有重连机制的业务简直就是灾难。引入proxy后,则能有效解决这种问题。切换过程中,对于old-master会等待事务完成,而新的请求则会路由到new-Master。

核心逻辑:本质是7层转发,proxy模拟实现MySQL协议,应用实际是连接proxy,proxy再连接RDS,转发SQL给RDS,并将结果集转发回传给应用。

4.主要优缺点对比

RDS链路类型

优势

缺陷

App+ECS(DB)自建

成本低

用户个人负责数据库的容灾、备份、恢复、监控、迁移

App+lvs+DB

无需经过proxy转发,RT短,具备高可用能力

无法解决闪断问题,也不容易实现读写分离等高级功能

App+lvs+Proxy+DB

功能丰富,包括防SQL注入,读写分离,连接池等。

多一跳proxy,增加RT。

Proxy中间件 VS TDDL 中间件

proxy中间件引入使得RDS除了具备必要的高可用能力,还能实现更多的高级功能,包括读写分离,连接池,防SQL注入,防闪断等,这部分能力的获取是通过牺牲一定RT来获得的。实际上,中间件有两种模式,一种是client模式,一种是server模式,集团的TDDL和云上的Proxy就是两种典型代表。client模式要求与语言强绑定,比如TDDL中间件以jar包的模式打进用户的应用,只支持JAVA语言,这对于云上业务肯定是不可行的,毕竟现在用PHP,Python写后端的应用也非常多。另外一点是,client模式会导致连接数随着client的个数同比例增加,这带来的影响是到后端DB的连接数增加,client模式的好处是不用经过proxy这一跳,RT更好;而server模式则能有效控制到后端DB的连接数,但是整个链路增加了一层,也就增加了一层风险,Proxy自身的高可用也需要严格保证,确保整个链路的可用性。至于功能层面的,比如读写分离,连接池,防SQL注入等功能,两种都是可以实现的。

RDS高可用

云上售卖的数据库都是传统的数据库包括MySQL,PostgreSQL,SQLServer等都是单机数据库,所以数据库的高可用还需要依赖于外部的HA组件。

云上RDS架构

云上RDS架构

参考文档

https://my.oschina.net/yunqi/blog/3069510

上一篇:nginx+SLB


下一篇:TcaplusDB君 · 行业新闻汇编(7月2日)