• 产品与解决方案
  • 行业解决方案
  • 服务
  • 支持
  • 合作伙伴
  • 新华三人才研学中心
  • 关于我们

RMDB远程数据库技术白皮书-6W100

手册下载

RMDB远程数据库技术白皮书-6W100-整本手册.pdf  (399.13 KB)

  • 发布时间:2021/8/9 14:05:49
  • 浏览量:
  • 下载量:

RMDB远程数据库技术白皮书

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Copyright © 2021 新华三技术有限公司 版权所有,保留一切权利。

非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。

除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。

本文中的内容为通用性技术信息,某些信息可能不适用于您所购买的产品。



概述

1.1  产生背景

vBRAS转发与控制分离组网中,由于设备故障、用户潮汐时设备弹性伸缩以及设备升级等原因,需要将PPPoEIPoE等用户的数据在vBRAS设备之间进行迁移。RMDBRemote Database,远程数据库)是一种应用在转发与控制分离组网中的备份技术。它通过借助远端Redis数据库服务器实现数据的备份和恢复,可以很好地解决用户数据迁移问题。

图1 RMDB远程数据库数据迁移功能示意图

 

1.2  技术优点

1.2.1  设备角度

vBRAS设备角度来说,RMDB具有以下优点:

·     支持对PPPoEIPoEL2TP等多种业务数据进行备份。

·     支持按单个UP或一组UP进行用户数据迁移,可根据实际需要灵活选择数据迁移方案。

1.2.2  数据库角度

Redis数据库服务器角度来说,RMDB具有以下优点:

·     Redis数据库服务器性能高、读写速度快。

·     Redis数据库服务器支持数据持久化,可避免因服务器系统重启等原因导致数据丢失,有利于数据长期保存。

·     Redis数据库服务器支持主从复制,主服务器会自动将数据同步给从服务器,当主服务器发生故障时,从服务器能够升为主,接替原主服务器的工作,提高数据服务的可靠性。

1.3  基本概念

·     用户主机:用户终端的客户端系统,支持IPoEPPPoEL2TP三种客户端。

·     UPUser Plane,用户平面):负责完成用户数据流量转发和流量控制等转发平面业务的设备。UPvBRAS系列虚拟宽带远程接入服务器、路由器等设备担任。

·     CPControl Plane,控制平面):负责完成用户身份认证、地址分配与管理等控制平面业务的设备。CPvBRAS系列虚拟宽带远程接入服务器担任。

·     Redis客户端:负责向远程Redis数据库服务器备份数据以及从远程数据库获取备份数据。在RMDB组网中,由CP担任Redis客户端的角色,

·     Redis服务器:负责存储Redis客户端备份的用户数据。Redis服务器采用了一种基于代理的高性能Redis集群方案,即Codis方案。关于Codis方案的详细介绍建议参见网页:https://github.com/CodisLabs/codis

1.4  基本原理

RMDB工作机制的基本流程如下:

(1)     CP设备上开启RMDB远程数据库功能,并配置一个或多个ZookeeperIP地址和端口信息。

(2)     CP设备按配置的时间顺序逐个尝试和所有配置的Zookeeper建立连接,直到和某个Zookeeper成功建立连接,并且从该Zookeeper获取到可用的Codis-proxy信息。

(3)     RMDB模块按一定的算法从获取到的所有Codis-proxy中选择一个合适的Codis-proxy,然后将该Codis-proxyIP地址和端口等信息发送给各业务模块。

(4)     各业务模块收到Codis-proxyIP地址和端口等信息后,主动和该Codis-proxy建立连接。

(5)     后续,各业务模块根据需要自行连接Codis-proxy进行数据的备份和恢复。

远程数据库技术实现

2.1  数据库架构

RMDB远程数据库采用了一种基于代理的高性能Redis集群方案,即Codis方案。如下图所示,这种集群方案使得Redis客户端连接到Codis-proxy和连接原生的Redis-server没有明显的区别,上层应用可以像使用单机的Redis-server一样使用CodisCodis内部各节点之间的交互以及数据迁移等工作对于Redis客户端来说是透明的。

图2 数据库架构图

 

其中,Redis服务器主要包括如下几种功能节点:

·     Codis-proxy:用于为CP提供Redis代理服务,CP借助Codis-proxy实现数据的备份和恢复。

·     Zookeeper:用于监控和存放Codis-proxy的信息,以及在Codis-proxy之间同步Redis-server的分组信息。CP设备通过Zookeeper来获取Codis-proxy的信息。

·     Codis-feCodis集群管理界面,多个Codis集群可以共用同一个Codis-fe

·     Codis-dashboardCodis的管理工具,支持添加/删除Redis-server节点、添加/删除Codis-proxy节点,发起数据迁移等操作。

·     Redis-server:真正用来存储数据的节点。Redis-server采用主从结构,由主用Redis-server负责数据存储工作,备用Redis-server负责对主用Redis-server进行备份。

·     Redis-sentinel:负责对Redis-server进行监控和故障转移,当主用Redis-server故障时,Redis-sentinel按一定算法从备用Redis-server中选举出新的主用Redis-server

2.2  实现机制

2.2.1  为什么要做集群

如果仅部署一个单节点Redis-server,很明显会遇到单点故障的问题。

图3 单点故障示意图

 

要解决单点故障的问题,可以将两个Redis-server做成主从结构。

图4 主从结构示意图

 

主从Redis-server之间用户数据同步基本过程如下:

(1)     如果从节点要同步主节点的数据,它首先会发Sync指令给主节点。

(2)     主节点收到Sync指令之后会执行BGSAVE命令生成RDB文件,这个RDB文件指的是快照文件。

(3)     如果在主节点生成RDB文件的过程当中,客户端发来了待存储数据,主节点按如下原则处理:

a.     主节点会把这部分待存储数据全部写入缓冲区。

b.     主节点等待当前RDB文件生成后,将其发送给从节点。

c.     主节点自己存储一份缓存区数据,并把缓冲区的存储数据给所有从节点各发送一份,这样就完成了主节点上所有用户数据由主节点到从节点的同步。

单一的主从结构虽然可以解决单点故障问题,但会遇到海量数据存储的效率问题。即如果有海量数据需要存储,那么BGSAVE指令生成的RDB文件会非常巨大,这个文件传送给从节点会非常慢;同时,如果缓冲区存储的数据很多的话,从节点同步数据时也会执行很久。所以,要解决单点问题和海量数据存储问题,还需要采用集群方案。

2.2.2  Codis集群实现

下面按照Codis的架构演进过程介绍Codis集群原理。

1. Redis-server

Redis-server采用如下图所示的主从机制来提供可靠性,保证主节点宕机后从节点能快速接替主节点工作。

图5 主从结构示意图

 

2. Redis-sentinel

Redis-sentinel负责监控主从Redis-server节点的状态,并在主节点故障后,在从节点中选举出一个新的主节点来接替故障主节点工作。

图6 Redis-sentinel

 

为解决Redis-sentinel的单点问题,Redis-sentinel需要做成集群。

图7 Redis-sentinel集群

 

Redis-sentinel采用哨兵机制来实现主从Redis-server切换。

如下图所示:

·     每个Redis-sentinel作为哨兵通过PING机制监测所有Redis-server的运行状态

·     哨兵之间也通过PING机制互相监测彼此的运行状态,并且交换监测到的状态信息。

图8 哨兵机制

 

假设有三个Redis-sentinel作为哨兵来共同管理一主两从共三个Redis-server节点。当有一个Redis-server下线的情况下,哨兵机制基本工作过程如下。

(1)     哨兵确认Redis-server节点下线

确认规则

a.     如果哨兵监测到某一个Redis-server节点在规定时间内没有回复,则该哨兵认为该Redis-server节点为主观下线。

b.     当有足够多数量的哨兵都认为该Redis-server节点主观下线时,该Redis-server节点将被标记为客观下线。

如果客观下线的是从Redis-server节点,则操作到此为止;如果客观下线的是主Redis-server节点,则进行下面的故障转移操作,即在从Redis-server节点中选举出一个新的主节点来接替故障主Redis-server节点工作进行。

(2)     哨兵选举领头人

在选举新的主Redis-server节点前,需要先在Redis-sentinel集群中选举一个Redis-sentinel作为领头人,由该领头人负责故障主Redis-server节点的故障转移工作。

领头人选举规则为:

a.     每个哨兵都可能成为领头人,当一个哨兵确认主Redis-server节点客观下线后,会请求其它哨兵选举自己为领头人。

b.     被请求的哨兵如果没有同意过其它哨兵的选举请求,则同意该哨兵的请求(获选票数+1),否则不同意。

c.     当某个哨兵获得的选举票数达到成为领头人的最低票数时,则该哨兵将被选举为领头人,否则重新进行选举。

(3)     领头人选出主节点

哨兵领头人在从Redis-server节点中选出一个新的主节点来接替故障主Redis-server节点工作。

选举规则为:所有从Redis-server节点依次从上到下匹配如下条件,若有多个节点满足当前条件,则继续匹配下一个条件,一旦筛选出唯一匹配者,则将其作为新的主Redis-server节点。

¡     工作状态正常,无故障。

¡     节点的优先级高。优先级数值越小则优先级越高。

¡     已从Redis-server节点同步数据量大。

¡     节点的进程ID值小

(4)     领头人负责主备切换

切换机制为:在新的主Redis-server节点选举出来后,领头人会将新主Redis-server节点的信息通知给其它哨兵和Redis-server节点。后续,其它从Redis-server节点从新的主Redis-server节点同步备份数据。

3. Codis-proxy

为解决存储海量数据时,主从Redis-server节点之间的数据同步缓慢问题,需要将一个主从结构变成多个主从结构,形成多个主从Redis-server分组,以便将需要存储的数据分摊到不同的Redis-server分组中。

图9 多主从结构

 

Codis-proxy负责按一定的规则将待存储数据分摊到不同的Redis-server分组中,具体规则如下:

(1)     Codis方案中,每个待存储数据都自带一个key属性,通过将所有的key分为1024个槽位,每一个槽位和一个Redis-server分组建立映射关系,槽位与Redis-server分组的映射关系可以进行自定义。

(2)     Codis-proxy收到待存储数据时,首先要根据CRC32算法,针对该数据的key算出32位的哈希值,然后除以1024取余,这个取余的值即为这个key所属的槽位。

(3)     根据槽与分组的映射关系,将待存储的数据存储到相应的Redis-server分组

图10 Codis-proxy

 

槽位与分组的映射关系由Codis-proxy保存,为避免Codis-proxy本身单点故障问题,需要对Codis-proxy做一个集群。

图11 Codis-proxy集群

 

4. Zookeeper

Zookeeper用于监控和存放Codis-proxy的信息,并将槽位和分组的映射关系同步给所有的Codis-proxy,以便所有Codis-proxy使用相同的槽位和分组的映射关系为Redis-client提供数据存储服务

图12 Zookeeper

 

5. Codis-dashboard

Codis-dashboard是整个Codis的管理平台,所有对集群的修改都必须通过Codis-dashboard完成。Codis-dashboard支持添加/删除Redis-server节点、添加/删除Codis-proxy节点,发起数据迁移等操作。

图13 Codis-dashboard

 

6. Codis-fe

Codis通过Codis-fe实现了集群管理界面功能,方便用户通过界面化的方式进行集群管理。

图14 Codis-fe

 

7. Redis-client

Redis客户端直接通过Codis-proxy访问后端服务。对于Redis客户端来说,Codis-proxy后端的Redis服务是透明的,可以认为后边连接的是一个内存无限大的Redis服务器。

Redis客户端通过Codis-proxy访问后端服务的基本过程如下

(1)     Redis客户端和某个Zookeeper建立连接,并从该Zookeeper获取到可用的Codis-proxy信息。

(2)     Redis客户端Codis-proxy建立连接。

(3)     后续,Redis客户端通过Codis-proxy进行数据的备份和恢复。

图15 Redis-client

 

2.3  DB-VM部署

如下图所示,Codis数据库的节点运行在DB-VM虚机上,多个DB-VM可以组成一个DB-VM组,多个DB-VM组又可以构成一个统一的数据库系统集群。

图16 数据库系统集群

 

其中:

·     DB-VM名称的格式为:DB-VM-ID-组内成员ID。目前每个DB-VM组仅支持两个DB-VM。例如,DB-VM-0-0DB-VM-0-1为一组,DB-VM-1-0DB-VM-1-1为另一组。

·     Redis-server是本地节点,DB-VM组内有效;Redis-sentinelZookeeperCodis-proxyCodis-fe&Codis-dashboard全局节点,在整个数据库系统集群有效。

·     每台DB-VM上部署四个Redis-server、一个Redis-sentinel、一个Zookeeper、一个Codis-proxy

·     一个数据库系统集群内仅有一台DB-VM可作为管理DB-VMCodis-feCodis-dashboard仅在管理DB-VM上启动。

·     一个DB-VM组内,其中一台DB-VM上的四个Redis-server节点和另一台DB-VM上的四个Redis-server节点分别两两组成一个Redis-server分组。

·     Redis-server分组内,一个为主节点,一个为备节点。例如,DB-VM-0-0上的Redis-server A11DB-VM-0-1上的Redis-server A21组成一个分组,在该分组内Redis-server A11为主节点,Redis-server A21为备节点。

·     DB-VM组中,两个DB-VM互为主备。当系统中某台DB-VMDB-VM上某Redis-server分组中的主Redis-server节点故障时,Redis-sentinel会在该DB-VM组内为发生主Redis-server节点故障的所有Redis-server分组分别选出新的主Redis-server节点。

·     数据库系统集群中,基于如下考虑,要求初始至少部署2DB-VM组,即DB-VM初始部署数量不能小于4台,同时,要求这些DB-VM要反亲和性分别部署于不同的物理服务器上。

¡     部署DB-VM时,要求每两个DB-VM组成一个DB-VM组,组内互为备份。

¡     要求每台DB-VM上部署一个Redis-sentinel,同时鉴于哨兵领头人的选举机制,在选举领头人时,仅当获选票数大于Redis-sentinel总数的一半时才能选举成功,要求Redis-sentinel的个数不能小于3个。

2.4  DB-VM扩缩容

在业务需求增加时,需要备份的数据增加,此时需要扩容虚拟资源以保证业务的平滑扩展;在业务需求下降时,需要备份的数据减少,此时可缩容释放虚拟资源,提高虚拟资源的利用率。

·     DB-VM扩容:增加新的DB-VM,将部分用户数据从扩容前的DB-VM上移动到新扩容出的DB-VM上。DB-VM扩容完成后,Codis-proxy会自动按一定的算法将原有DB-VM上存储的用户数据平均分配到当前已有的所有DB-VM上,该过程无需用户干预。

·     DB-VM缩容:删除部分DB-VM,将用户数据从被缩容的DB-VM上移动到未被缩容的DB-VM上。缩容前,需要管理员手工执行缩容脚本先将待删除DB-VM上存储的数据迁移到其它DB-VM上。

远程数据库技术应用

3.1  用户数据备份

CP通过借助Codis-proxy实现各业务模块的数据备份,具体过程如下:

(1)     各业务模块和Codis-proxy建立连接。

(2)     业务模块自动将本业务模块需要备份的数据通过Codis-proxy备份到Redis数据库服务器。

(3)     后续,如果某业务模块有数据需要更新,该业务模块自动将需要更新的数据通过Codis-proxy备份到Redis数据库服务器。

图17 用户数据备份

3.2  用户数据迁移

CP上,RMDB通过和UPLBUser plane load balancingUP负载分担)配合,在UPLB的扩缩容过程中实现基于UP的用户数据迁移,具体过程如下:

(1)     RMDB通过响应UPLBUP迁移事件,获取待迁移的一个或一组UP ID信息。

(2)     RMDB通知各业务模块从远程数据库获取迁移UP的备份数据。

(3)     各业务模块自行通过Codis-proxy从远程数据库获取待迁移UP的备份数据以完成业务恢复。

图18 用户数据迁移

 

3.3  用户数据自恢复

RMDB的数据自恢复功能,是指在CP设备重启后,各业务模块能够自行连接Codis-proxy从数据库服务器获取CP设备重启前的备份数据进行业务恢复,具体过程如下:

(1)     CP设备重启后,各业务模块和Codis-proxy重新建立连接。

(2)     RMDB根据整机重启后RMDB自动恢复业务前的等待时间,以及业务模块和Codis-proxy的连接情况,选择合适的时机通知各业务模块自行从数据库服务器获取CP设备重启前的备份数据进行业务恢复。

图19 用户数据自恢复

 

典型组网应用

4.1  远程数据库数据备份及迁移

如下图所示,主机作为PPPoE Client,运行PPPoE客户端拨号软件。UP为用户接入设备,CP为控制设备。CP设备将用户会话信息备份到Redis数据库服务器。正常情况下,用户通过BRAS-VM 1接入;当BRAS-VM 1故障时,将BRAS-VM 1上的用户数据按UP迁移到BRAS-VM 2上。

图20 远程数据库数据备份及迁移组网图

 

参考文献

·     Redis开源网站https://redis.io/

·     Codis开源网站https://github.com/CodisLabs/codis

·     《中国移动基于转发和控制分离架构的vBRAS系统设备规范》

·     《中国移动基于转发和控制分离架构的vBRAS系统技术实现流程》

·     《中国移动基于转发和控制分离的vBRAS系统控制接口规范》

 

新华三官网
联系我们