企业容灾架构选型必知概念、跨中心数据复制技术

一、必须知道的概念

1. 什么是企业的容灾？

1.1 什么是企业的业务连续性管理（Business Continuity Management）？

企业的业务连续性是指企业有应对风险、自动调整和快速反应的能力，以保障企业业务的连续运转。为企业的重要应用和流程提供业务连续性应该包括连续操作（Continuous Operations）、高可用性（High Availability）、灾难恢复（Disaster Recovery）三个方面，这几个方面不是孤立存在的，而是相互联系存在的。连续操作强调的指在没有物理故障发生的情况下，保障业务连续的常规运维操作能力；高可用性强调的是基础架构在本地故障的场合下的恢复能力；灾难恢复强调的是在灾难场合下，企业的业务恢复能力。从业务连续性上来讲，企业的容灾也就是我们所说的灾难恢复范畴，应该是业务连续性的子集。

1.2 什么是企业的容灾架构（Disaster Tolerance）？

广义的容灾，我们可以认为就是业务连续性计划当中的灾难恢复，就是指能够容忍灾难的能力。要容忍的灾难类型就包括地震、洪水、火灾等灾害、软硬件故障、网络或病毒攻击、人为蓄意破坏等。容灾能力建设的主要目的，就是在灾难发生的时候，能够保证生产业务系统的不间断运行。

狭义的容灾，我们可以认为是指在相隔较远的区域（同城或者异地），建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。

1.3 什么是企业的备份和恢复（Backup and Recovery）？

备份和恢复是指备份数据以防数据丢失，且设置安全系统以便恢复数据的流程。数据备份要求复制和存档计算机数据以保证数据损坏或删除后数据仍可访问。数据备份恢复是业务恢复的一种形式，因此它属于业务连续性计划当中的连续操作和灾难恢复范围。备份包括系统备份和数据备份，系统备份是指将系统运行环境作为一个整体进行备份，当发生故障时将系统运行环境整体恢复。数据备份是指将应用系统当中保存的数据作为单独的形式进行备份，当数据发生丢失或者损坏的时候进行恢复。

1.4 什么是企业IT基础架构的高可用（High Availability）？

高可用性（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。企业的高可用架构通常指的是为了在面对数据中心本地软硬件故障场景下，保证业务的连续性而规划部署的非对称（主备、主从）以及对称架构（主主、集群），可以是网络架构、主机架构、数据库架构以及存储架构等类IT基础架构，例如交换机的堆叠技术、负载均衡设备的集群架构、主机的HA架构、数据库的Oracle RAC集群等。

1.5 什么是企业的IT基础架构的容错（Fault-tolerant）？

在计算机通信领域来讲，容错就是指当系统在运行时有错误被激活的情况下仍能保证不间断提供服务的方法和技术。从广义来讲，我们所述的容灾、备份恢复、高可用等都是容错的一种手段。

但是通常来讲，我们对IT基础架构当中的容错性有着约定俗成的专指含义，实际上它是指我们在IT设备配置或者软件配置过程当中，为了杜绝网络线路、设备零件、软件模块等方面的运行错误导致的应用系统中断而采取的冗余性设计。例如网卡的逻辑绑定、存储链路的聚合、LVM逻辑卷设计等等。

1.6 如何理解业务连续性、备份恢复以及容灾？

1、从范畴上来讲，我们用以下的图来诠释这几个概念的差异。

备份恢复、高可用架构设计、容错设计、容灾都是为了保障业务连续性的一种手段、技术和工具。在广义的容灾设计当中必然也会包括基础架构的高可用设计、设备软件的容错设计以及必要的备份恢复。但是备份恢复、高可用和容错是可以独立存在的，不依赖容灾架构。

2、从设计功能上来讲，备份恢复不仅仅可以解决由物理故障引起的数据损坏和丢失，而且更重要的是它可以解决由人为的逻辑错误导致的数据损坏和丢失，比如误删数据。备份恢复是一种事后的补救措施，也就是说它只能发生在问题发生之后。容错、高可用、容灾中核心的架构设计是为了解决实时问题，是一种事中解决问题的思路，但是这两者都无法解决人为导致的逻辑错误故障导致的业务中断，只能解决物理故障导致的业务中断问题。

3、从所属性质来讲，业务连续性是着眼业务层面的一套解决思路或者方法论指导下的制度、流程、方案、技术、工具、资源等一系列元素组成的。而容灾、高可用、备份恢复、容错仅仅是为了保障业务连续而对基础架构进行设计实现的技术工具或者手段。

2. 企业容灾架构的核心目标是什么？

企业容灾架构的核心目标是什么？也就是说我们为什么要花这么大力气去搞容灾建设？就一句话，RTO&RPO是搞容灾建设的最核心目标，一切容灾建设目的都需要回到RTO和RPO的评估上来。

① RTO：企业可容许服务中断的时间长度，简言之业务可以恢复的最快时间。

② RPO：企业可容许数据丢失的数量级，简言之数据可以恢复到最新的时刻点。

如图所示，RTO关注的是数据丢失的多少，而对什么时候恢复业务中断没有要求；RPO关注的是什么时候恢复业务，但是历史数据丢失多少并没有要求。只有这两个结合起来才是对现实生活当中的业务连续性的约束。要实现什么样的RTO&RPO目标，一定会有相应的方案来支撑，也必然有对此方案需要付出的IT成本投入。我们评估容灾的目标要求，一定是从RTO&RPO的选定范围出发，然后权衡企业可以付诸的投入，最终确定合理的容灾建设方案。

3. 企业容灾架构的行业标准都有哪些？

3.1企业容灾的国家级标准

《信息安全技术信息系统灾难恢复规范》国家标准（GB/T20988-2007）是我国灾难备份与恢复行业的第一个国家标准。该标准由国务院信息化工作办公室领导编制的，并于2007年11月1日开始正式实施。该标准规定了信息系统灾难恢复应遵循的基本要求，适用于信息系统灾难恢复的规划、审批、实施和管理，并参照国际标准SHARE78的7个层级定义，确定了符合中国国情的6个灾备能力等级要求。下面，概括性地介绍各个层级的内容：

1级：数据定时备份、异地存放。

2级：数据定时备份、异地设备冷备。

3级：数据定时备份、异地部分业务热备接管。

4级：数据定时备份、异地业务热备接管。

5级：数据实时备份、异地业务热备接管。

6级：零数据丢失、远程自动接管支持。

3.2企业容灾的行业监管标准

对于评价容灾的RTO&RPO这两个指标，不同的行业有不同的行业标准，例如人民银行在2008年的《银行业信息系统灾难恢复管理规范》当中规定：银行类信息系统恢复要求：

① 一类信息系统：RTO<6小时，rpo<15分钟。< p="">

② 二类信息系统：RTO<24小时，rpo<120分钟。< p="">

③ 三类信息系统：RTO<7天。< p="">

对于银行行业来讲，所有容灾建设必须遵循这个最低要求。在此基础之上，不同的企业对自身有不同的要求。比如工商银行、招商银行之类发展比较优秀的银行企业对自己提出了更高的要求(RTO~0，RPO~0)，有些小的地方银行则因为成本问题，是为了达到银监局及人民银行的最低要求而搞容灾建设。但是无论是出于什么样的目的搞容灾建设，最终必然要回到对RTO和RPO的评估上来，没有这两个核心目标的选择，则一切容灾建设方案都无根可寻。

3.3企业容灾的自我衡量标准

另外一种标准就是企业本身的业务要求，例如生产企业，RTO是可以直接计算企业损失的指标，如果停产1个小时将会给企业带来多少可计算的损失以及不可计算的损失。我们可以根据这个损失来衡量可以为容灾建设付出的成本范围。

4. 企业容灾架构都包含哪些技术框架？

企业的容灾架构根据容灾的地域距离可以划分为本地容灾和异地容灾，而且整个容灾架构不是单独的一类技术或者一类工具，而是系统的整体技术框架，包含了很多的元素和技术体系，如果分解阐述，可以从纵向和横向进行分解描述。

首先，从纵向来讲，整个容灾架构包括网络层、负载分发层、应用中间件层、应用层以及数据涉及的数据库和存储层，其中数据层最为重要，直接关系到RPO指标，应用层往上则主要关系到RTO指标。接着，我们从横向上来讲，会包括集群技术、数据复制技术以及应用切换技术，数据复制技术又是整个容灾的关键，因为它直接关系到RPO指标，应用切换技术则直接关系到RTO指标，集群技术一般是指在近距离（例如同城）场合下的数据复制和应用切换技术的融合体。最后，我们从整体基础架构来讲，为了支撑以上技术体系的实现，我们需要有一系列的软硬件基础架构来支撑其最终的实现，比如我们的交换机、服务器、存储、备份介质、网络线路以及为了实现应用的切换和数据复制技术体系所需要的SDN、LB、GLB、VM、HA、DB Cluster、Storage Gateway、Storage DP等软件模块。

接下来，我们来看实现企业容灾架构横向支撑的一些关键技术：

① 网络的跨地域L2技术（主要为虚拟机的漂移、集群IP地址漂移等）：同城距离可以采用波分设备和思科的OTV技术来实现跨中心的L2技术，但是这种技术可跨越的距离仅限百公里范围内级别。另外一类就是采用Overlay隧道技术，在原有网络基础架构之上通过逻辑隧道的模式实现L2的传输，这种技术不受距离限制，但是性能不是最佳。

② 跨数据中心负载分发技术（主要为客户端访问流量的切换）：通常需要域名解析DNS与本地负载均衡LB结合来实现全局的负载分发。DNS需要能够实现动态解析，也就是根据备选地址池的健康状况来确定最终的业务地址。本地不在均衡LB实现本地内的负载导流。如图所示：

③ 跨数据中心VM集群内漂移技术（主要为应用的跨地域高可用服务）：通常可以通过虚拟机的跨地域集群技术实现，只要具备跨数据中心L2网络和存储卷共享的条件，基本上都可以实现。关于跨区域的L2网络技术，上述章节已讨论过。存储卷共享可以通过NAS或者分布式存储来实现。

④ 跨数据中心数据复制技术（主要为数据跨区域冗余服务）：数据复制技术是关键，它是保障容灾目标RTO&RPO的关键技术，根据容灾级别的不同，可分为同步复制和异步复制，所使用的实现手段也因此而不同。关于它的具体实现方式，可以考虑从三个层面落地：系统层的双写、数据库层的数据复制、存储层的复制。具体实现方式及其优劣在后续文章详细介绍。

5. 数据复制技术在企业容灾架构当中的意义

如果上升到商业业务的高度，那么一切容灾技术都是为了业务的连续性服务的。

具体来说，数据复制技术即完成数据从一个数据中心到另外的数据中心的冗余性保护。一旦发生灾难导致一个数据中心的数据丢失或者损坏，可以通过另外一个数据中心的数据来支撑应用系统运行。没有应用系统的不中断运行就没有业务的连续性可言，没有数据的存在就没有应用系统的不中断运行可言，没有数据复制技术的支撑就没有容灾的必要性可言。数据在应用系统当中的地位直接决定了数据复制技术在容灾框架当中的绝对必要性地位。

① RPO：简言之，RPO就是衡量灾难时刻依靠容灾手段可以丢失的最少数据。数据复制的及时性直接决定RPO的量级标准，如果数据复制是同步模式，那么RPO必然是零。如果数据是异步模式，那么RPO就直接与数据复制的异步效率指标息息相关。

② RTO：简言之，RTO就是衡量灾难时刻依靠容灾手段可以恢复业务的最短时间。这个不仅仅取决于数据复制技术，还要依赖于纵向的网络、负载分发、服务器、应用、数据库、存储等各个层面的恢复技术。但是，数据复制技术一定是所有恢复技术的基石，没有这个基石，及时所有层面都恢复了，没有数据的业务访问也依然无效。

因此，数据复制技术是容灾体系架构当中最关键的技术元素。

二、跨中心数据复制技术

1. 什么是企业容灾的数据复制技术？

企业容灾架构中，所谓的数据复制技术主要是指能够将结构化数据进行复制，从而保证数据具备双副本或者多副本分散在不同数据中心的技术。这里面需要强调两点：

① 结构化数据：以结构化数据为主的数据复制技术。

② 分散在不同数据中心：数据副本必须分布在不同的数据中心。

就具体的实现技术而言，就目前业界发展来看，可以实现数据复制的技术多种多样，有基于数据库层面的数据复制技术，例如Oracle公司的Active Data Gurad、IBM公司的 Db2 HADR等；有基于系统层面的数据复制技术，例如赛门铁克的vxvm、传统的逻辑卷管理（LVM）、Oracle公司的自动存储管理（ASM）冗余技术、IBM公司的GPFS等；有基于存储虚拟化实现的数据复制技术，例如EMC公司Vplex Stretch Cluster、IBM公司SVC Split Cluster、NetAPP公司Metro Cluster等；也有基于存储底层实现的数据复制技术，例如IBM公司的DS8000 PPRC技术、EMC公司的SRDF技术、HP公司的CA技术等等。每一种技术都有其实现的前提条件，也有各自的技术特点和实现的不同效果。

2. 企业容灾中的数据复制技术的分类

2.1 同步复制和异步复制

从RPO维度来划分，大的方面可以分为同步复制和异步复制。

① 同步复制：要求每一个写入操作在执行下一个操作处理之前，在源端和目标端都能完成。特点是数据丢失少，会影响生产系统性能，除非目标系统物理上离生产系统比较近。

② 异步复制：在处理下一个操作前， 只需要完成源端数据写入即可， 不等待数据复制到目标系统中。特点是复制的数据与源数据有时间差，但这种复制对生产系统性能影响较小。

那么这里有一个问题“如何界定一个写入操作完成？”，一般来讲，存储端的写入以存储设备的缓存写入为标准，数据库的写入以数据库的事务日志落盘为标准。

如果用图的方式来区别同步和异步之前的区别就在于：同步需要等待黑色和红色的ACK返回才会执行下一个IO，而异步只需要等待黑色的ACK返回即可执行下一个IO。从结果上来看，等待红色的ACK返回显然需要花费更多时间，因为A和B分别位于不同的数据中心；但是等待会带来RPO=0的回报。

2.2 根据实现复制的手段来划分

根据上图，数据复制最终完成的结果是在两个磁盘介质上完成同一个IO数据，但是将来自客户端的单个IO请求镜像为两个IO的源头可以有三种不同的选择：操作系统层面、数据库层面以及存储层面。

1). 操作系统层面的复制技术：以LVM、VXVM等逻辑卷镜像为基础，IO写入的时候可以在组成同一个逻辑卷的物理镜像上同时写入数据，底层数据写入是需要通过SAN协议完成的。

2). 数据库层面的复制技术：一种是类似操作系统逻辑卷的模式，比如ORACLE的ASM，它也是一种逻辑卷管理模式，同样也可以通过多个物理镜像来组成一个逻辑卷，从而通过镜像复制的方式完成数据副本的同时写入。本质上它与操作系统层面的逻辑卷镜像技术没有区别，只是它离数据库更近，数据库更懂它。另外一种是通过数据库事务日志复制的方式将数据修改行为在另外一个备库上重新演绎一遍，最终可以达到使数据结果一致的目的。

3). 存储层面的复制技术：一种是通过存储网关将两个物理存储卷组成一个逻辑存储卷，通过镜像复制的方式完成数据在存储落盘时的双写。本质上它与操作系统层面的逻辑卷镜像技术也没有区别，只是它选择在存储层面实现。另外一种是通过存储介质之间以块拷贝的方式来实现数据副本的冗余。

究其原理，其实无论从哪个层面来实现，这些技术从原理上可以划分为三种类型：

1、IO双写（操作系统逻辑卷镜像、ASM、存储网关镜像.etc）

2、事务回放（以Oracle ADG为代表.etc）

3、数据单元拷贝（以存储CA、DP技术为代表的存储复制技术）

3. 系统层如何实现数据复制？

3.1 通过操作系统逻辑卷镜像实现数据复制

对于操作系统层面的逻辑卷管理器LVM模式来讲，是将底层来自不同数据中心的的两个物理存储卷作为物理镜像( PV) 组合成一个可用的逻辑存储卷( LV) 提供给上层应用来存放数据，本地物理卷和远程物理卷分别是由存储经过本地SAN环境以及跨数据中心SAN环境提供给服务器操作系统层。

建立逻辑卷的时候就已经定义好LV和PV的映射关系，并且逻辑页(LP ) 和物理页(PP ) 的映射关系也已经完全定义好了。这种复制只能采用同步复制机制，复制对象为逻辑卷层的变化Block，其过程为：捕获逻辑页( LP) 当中的变化块，同步写两个物理页( PP) ，等于在一个主机上将同一数据写入两个不同的磁盘，本地写完得到ACK确认，并且远端写完也得到ACK确认，才能算是一个完整的写入。假设远端存储卷写入超时就会被标为故障或者是离线状态，当远端存储写入恢复之后，对于LVM来讲需要重新进行手动同步实现镜像副本完全一致。

3.2 通过数据库逻辑卷镜像实现的数据复制

对于ASM模式来讲，其实原理与LVM基本相同，创建DiskGroup的时候，将冗余策略选择为Normal，也就是所有业务数据保证两份镜像。这样的话，我们可以将相等数量的磁盘分别归入不同的故障组( Failure Group) 。ASM对Oracle数据文件( Data File) 进行修改的时候，以AU为单元进行实时双向写入，本地写完得到ACK确认，并且远端写完也得到ACK确认，才能算是一个完整的写入。

相比LVM的优势在于两点：ASM会有一个短时间内的写事务日志记录，它会帮助恢复离线镜像恢复数据，但是如果超过这个时间，同样需要一个全新的同步来保证数据的一致性。另外一点，AU并非建立数据文件的时候就已经映射好了，ASM是在数据写入时才会分配具体的AU，完全可以做到通过指针转移的方式避免坏块儿导致的数据写入失败问题。

3.3 通过分布式文件系统文件镜像实现的数据复制

对于GPFS模式来讲，它是通过将底层来自不同站点的两个物理存储卷归属到不同的Failure Group当中，然后由这些物理存储卷经过文件系统格式化形成分布式文件系统，提供给上层应用以文件的形式写入数据。文件本身会被GPFS文件系统打散形成若干文件碎片，这些碎片在落盘时分别落入不同Failure Group当中的物理磁盘，从而保证底层数据的双副本。这种模式与前两种模式的最大区别在于它的数据落盘是根据NSD磁盘定义的服务实例顺序来决定的，正常情况下我们需要定义本站点的服务节点为磁盘的主服务节点，这样的话两个镜像写入的时候是靠GPFS位于不同中心的两个服务实例节点分别写入，两个服务实例之间也需要私有协议的交互，相当于数据的双写多了一个环节。

4. 数据库层如何实现数据复制？

4.1 通过数据库日志回放模式实现数据复制

对于事务日志的复制技术，可以分为绝对同步模式、近似同步模式和异步模式三种。

对于Oracle DB来讲，客户端的数据更新请求首先要由日志写入进程( LGWR) 从重做缓存刷到重做日志文件当中，然后由数据写进程再周期性地写入数据文件当中。重做日志当中以SCN为数据库独有的时间戳序列来记录所有数据库更新的先后顺序，从而保障数据库恢复能够按照正确的顺序执行保障数据一致性和完整性。也就是说在数据库的认知当中，只要事务日志写入重做日志文件，这个IO就算完成。

如图，对于配置了Data Guard绝对同步模式的数据库，在以上所述过程中，写入进程( LGWR) 在本地日志文件并不能结束，日志传输进程( LNS) 会将缓存里面的重做日志通过TCP /IP 网络传输给灾备站点的备库实例的日志接受进程(RFS ) ，备库实例的日志接收进程( RFS) 根据接受到的重做日志在备库上重新执行数据库的更新操作，然后将ACK回传给日志传输进程( LNS) ，日志传输进程( LNS) 再通知写入进程( LGWR) ，才算是一个完整的IO完成。这样做可以保证主库和备库的事务性更新行为实时一致，最终保证数据的一致。当然也有一个前提条件，那就是在Data Guard开始同步复制之前，必须保证备库的数据保持与主库的某一固定时间点的完整副本，这需要靠传统数据备份技术来实现备库的初始数据复制。因为事务复制的本质是行为复制，那么行为作用的初始数据副本必须保持一致，才能保证最终两副本的一致性。

如图，对于配置了Data Guard异步模式的数据库，日志传输进程( LNS) 会将缓存里面的重做日志以及被LGWR归档的重做日志文件通过TCP /IP 网络异步传输给灾备站点的备库实例的日志接受进程(RFS ) ，备库实例的日志接收进程( RFS) 根据接受到的重做日志在备库上重新执行数据库的更新操作，但是并不会实时给日志传输进程( LNS) 进行ACK反馈，PrimaryDB只要完成本库的事务更新就认为IO结束。但是备库日志接受进程(RFS ) 会定期将进度信息反馈给主库进程。

当主备库传输管理剥离之后，主库会主动通过以下两种方式探测并尝试重新和备库建立联系，第一是归档日志进程会周期性ping备库，成功情况下，它会根据获得的备库控制文件的记录的最后归档点和自己的归档日志决定向备库推送哪些归档日志。第二是日志发送进程会在重做日志准备发生归档的时刻点主动去ping备库日志接受进程并把剩余的重做条目发送给备库接受进程。

近似同步模式是指在传输正常情况下保持与绝对同步模式一样的模式，在网络传输超时的情况下，就会剥离备库重做日志的过程，只要保证主库重做日志落盘就可以了。

5. 存储层如何实现数据复制？

5.1 通过存储网关逻辑卷镜像实现数据复制

所谓存储网关双写复制技术，就是在物理存储层之上增加一层网关技术，用以形成存储资源透明抽象层，即存储虚拟化是服务器与存储间的一个抽象层用以实现存储底层的虚拟化以及高可用镜像，它是物理存储的逻辑表示方法。其主要目的就是要把物理存储介质抽象为逻辑存储空间，将分散的物理存储管理整合为集中存储管理并且由存储网关来控制镜像写入的策略和模式。IBM、EMC、NETAPP 、 HUAWEI、英方等公司都有相应容灾技术方案及相应产品 。基于写入原理及策略的不同， 各自方案又各有一些区别。但是抛开细节究原理，归类总结之后有两种模式 。

模式 1，如 图中所示，是以 EMC Vplex为代表的分布式存储卷技术。在存储网关VPLEX上重新定义虚拟存储卷，该虚拟卷由分布在两个数据中心的物理存储卷以1:1方式映射组成，并且以共享模式提供给VPLEX的两个引擎，引擎之间类似Oracle RAC的原理来共享全局缓存、心跳信息以及分布式锁的信息。两个引擎同时可以写IO，对于Block级别的并发写操作，是通过分布式锁及全局缓存机制来完成。所以这种双写是可以做到IO级别。

模式 2，如图中所示，是以 IBM SVC为代表的虚拟存储卷技术。在存储网关SVC上重新定义虚拟存储卷，该虚拟卷由分布在两个数据中心的物理存储卷以1:1方式映射组成，并且归属同一个IO Group，并且以共享模式提供给SVC的两个节点，虽然两个节点都可以写操作，但是对于某一个IO Group来讲，只能通过一侧节点进行物理层面的双写操作，这样就避免了两个节点的在Block级别的并发控制。所以这种双写只能做到应用级别，做不到IO级别。

当然还有一些类似的架构，在某些细节上更先进，比如NetApp的容灾方案MCC架构，它在此基础之上可以将负责存储写操作的实例节点做到VM级别，VM负责以卷为粒度的双写，同时VM可以在存储网关的物理引擎或节点之间进行漂移和重组，这样的话以应用为粒度的写操作的容灾切换更加平滑。

5.2 通过存储介质块复制实现数据复制

对于存储存储底层的块儿复制技术来讲， 它的数据复制是完全脱离了上层的应用层、系统层、数据库层。主要是依靠存储层两个物理存储设备 来完成源到目标 设备 的 Block 复制。

如图所示，从组成上来看，只有两个同型物理存储设备，数据复制跟上层没有任何关系，只需要存储层从一边的物理卷捕获 Block变化，复制到另外一边的物理存储卷，整个复制行为通过源端的日志文件来记录进度以及保障故障恢复。根据整个复制过程是否需要等待复制完成的ACK返回可以分为同步复制和异步复制。复制过程依赖的传输环境可以是远距离的以太网也可以是近距离的SAN网络。

但是这种数据复制技术和上层的联系几乎是割裂的，基本很难与上层的容灾切换配合。

以上就是企业容灾架构选型必知概念、跨中心数据复制技术的介绍，亿联云为国内外用户供给包括全球主机托管、主机租用、云专线接入等方面的专业服务，资源覆盖全球。欢迎咨询。

<!--7天。<-->

<!--24小时，rpo<120分钟。<-->

<!--6小时，rpo<15分钟。<-->