架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移

目录

负载均衡简介

负载均衡原理

负载均衡分类

常见负载均衡服务器

常见的负载均衡算法

什么是容灾和备份?

容灾备份的解决方案

故障转移和恢复


负载均衡简介

面对大量用户访问、高并发请求,海量数据,可以使用高性能的服务器、大型数据库,存储设备,高性能Web服务器,采用高效率的编程语言比如(Go,Scala)等,当单机容量达到极限时,我们需要考虑业务拆分和分布式部署,来解决大型网站访问量大,并发量高,海量数据的问题。

从单机网站到分布式网站,很重要的区别是业务拆分和分布式部署,将应用拆分后,部署到不同的机器上,实现大规模分布式系统。分布式和业务拆分解决了,从集中到分布的问题,但是每个部署的独立业务还存在单点的问题和访问统一入口问题,为解决单点故障,我们可以采取冗余的方式。将相同的应用部署到多台机器上。解决访问统一入口问题,我们可以在集群前面增加负载均衡设备,实现流量分发。

负载均衡(Load Balance),意思是将负载(工作任务,访问请求)进行平衡、分摊到多个操作单元(服务器,组件)上进行执行。是解决高性能,单点故障(高可用),扩展性(水平伸缩)的终极解决方案。

负载均衡原理

系统的扩展可分为纵向(垂直)扩展和横向(水平)扩展。纵向扩展,是从单机的角度通过增加硬件处理能力,比如CPU处理能力,内存容量,磁盘等方面,实现服务器处理能力的提升,不能满足大型分布式系统(网站),大流量,高并发,海量数据的问题。因此需要采用横向扩展的方式,通过添加机器来满足大型网站服务的处理能力。比如:一台机器不能满足,则增加两台或者多台机器,共同承担访问压力。这就是典型的集群和负载均衡架构:如下图:

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第1张图片

  • 负载均衡的方式

应用集群:将同一应用部署到多台机器上,组成处理集群,接收负载均衡设备分发的请求,进行处理,并返回相应数据。

负载均衡设备:将用户访问的请求,根据负载均衡算法,分发到集群中的一台处理服务器。(一种把网络请求分散到一个服务器集群中的可用服务器上去的设备)

  • 负载均衡的作用(解决的问题):

1.解决并发压力,提高应用处理性能(增加吞吐量,加强网络处理能力);

2.提供故障转移,实现高可用;

3.通过添加或减少服务器数量,提供网站伸缩性(扩展性);

4.安全防护;(负载均衡设备上做一些过滤,黑白名单等处理)

负载均衡分类

根据实现技术不同,可分为DNS负载均衡,HTTP负载均衡,IP负载均衡,链路层负载均衡等。

DNS负载均衡

最早的负载均衡技术,利用域名解析实现负载均衡,在DNS服务器,配置多个A记录,这些A记录对应的服务器构成集群。大型网站总是部分使用DNS解析,作为第一级负载均衡。如下图:

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第2张图片

  • 优点
    • 使用简单:负载均衡工作,交给DNS服务器处理,省掉了负载均衡服务器维护的麻烦
    • 提高性能:可以支持基于地址的域名解析,解析成距离用户最近的服务器地址,可以加快访问速度,改善性能;
  • 缺点
    • 可用性差:DNS解析是多级解析,新增/修改DNS后,解析时间较长;解析过程中,用户访问网站将失败;
    • 扩展性低:DNS负载均衡的控制权在域名商那里,无法对其做更多的改善和扩展;
    • 维护性差:也不能反映服务器的当前运行状态;支持的算法少;不能区分服务器的差异(不能根据系统与服务的状态来判断负载)

实践建议

将DNS作为第一级负载均衡,A记录对应着内部负载均衡的IP地址,通过内部负载均衡将请求分发到真实的Web服务器上。一般用于互联网公司,复杂的业务系统不合适使用。如下图:

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第3张图片

IP负载均衡

在网络层通过修改请求目标地址进行负载均衡。

用户请求数据包,到达负载均衡服务器后,负载均衡服务器在操作系统内核进程获取网络数据包,根据负载均衡算法得到一台真实服务器地址,然后将请求目的地址修改为,获得的真实ip地址,不需要经过用户进程处理。

真实服务器处理完成后,响应数据包回到负载均衡服务器,负载均衡服务器,再将数据包源地址修改为自身的ip地址,发送给用户浏览器。如下图:

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第4张图片

IP负载均衡,真实物理服务器返回给负载均衡服务器,存在两种方式:(1)负载均衡服务器在修改目的ip地址的同时修改源地址。将数据包源地址设为自身盘,即源地址转换(snat)。(2)将负载均衡服务器同时作为真实物理服务器集群的网关服务器。

  • 优点
    • 在内核进程完成数据分发,比在应用层分发性能更好;
  • 缺点
    • 所有请求响应都需要经过负载均衡服务器,集群最大吞吐量受限于负载均衡服务器网卡带宽;

链路层负载均衡

在通信协议的数据链路层修改mac地址,进行负载均衡。

数据分发时,不修改ip地址,指修改目标mac地址,配置真实物理服务器集群所有机器虚拟ip和负载均衡服务器ip地址一致,达到不修改数据包的源地址和目标地址,进行数据分发的目的。

实际处理服务器ip和数据请求目的ip一致,不需要经过负载均衡服务器进行地址转换,可将响应数据包直接返回给用户浏览器,避免负载均衡服务器网卡带宽成为瓶颈。也称为直接路由模式(DR模式)。如下图:

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第5张图片

优点:性能好;

缺点:配置复杂;

实践建议:DR模式是目前使用最广泛的一种负载均衡方式。

混合型负载均衡

由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异,可以考虑给每个服务器群采用最合适的负载均衡方式,然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务(即把这多个服务器群当做一个新的服务器群),从而达到最佳的性能。将这种方式称之为混合型负载均衡。

此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。是目前大型互联网公司,普遍使用的方式。

方式一,如下图:

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第6张图片

以上模式适合有动静分离的场景,反向代理服务器(集群)可以起到缓存和动态请求分发的作用,当时静态资源缓存在代理服务器时,则直接返回到浏览器。如果动态页面则请求后面的应用负载均衡(应用集群)。

方式二,如下图:

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第7张图片

以上模式,适合动态请求场景。

因混合模式,可以根据具体场景,灵活搭配各种方式,以上两种方式仅供参考。

常见负载均衡服务器

平时我们常用的有四层负载均衡和七层负载均衡,四层的负载均衡是基于IP和端口实现的,七层的负载均衡是在四层的基础上,基于URL等信息实现。

四层负载均衡

LVS:重量级软件,本身不支持正则表达式,部署起来比较麻烦,但是性能高,应用范围广,一般的大型互联网公司都有用到。

HAProxy:轻量级软件,支持的负载均衡策略非常多,较灵活。

Nginx:轻量级软件,支持的协议少(HTTP、HTTPS和Email协议),对于Session支持不友好。

七层负载均衡

HAProxy:全面支持七层代理,灵活性高,支持Session会话保持。

Nginx:可以针对HTTP应用进行分流,正则规则灵活,支持高并发,部署简单。

Apache:性能较差,一般不考虑。

MySQL Proxy:官方的数据库中间件,可以实现读写分离,负载均衡等功能,但是对分表分库支持不完善(可选替代品:Atlas,Cobar,TDDL)。

常见的负载均衡算法

常见的负载均衡算法包含:

  • 轮询法(Round Robin)
  • 加权轮询法(Weight Round Robin)
  • 平滑加权轮询法(Smooth Weight Round Robin)
  • 随机法(Random)
  • 加权随机法(Weight Random)
  • 源地址哈希法(Hash)
  • 最小连接数法(Least Connections)

什么是容灾和备份?

容灾技术是系统的高可用性技术的一个组成部分,容灾系统更加强调处理外界环境对系统的影响,特别是灾难性事件对整个IT节点的影响,提供节点级别的系统恢复功能。

容灾备份实际上是两个概念:

  • 容灾是为了在遭遇灾害时能保证信息系统能正常运行,帮助企业实现业务连续性的目标;
  • 备份是为了应对灾难来临时造成的数据丢失问题。

在容灾备份一体化产品出现之前,容灾系统与备份系统是独立的。容灾备份产品的最终目标是帮助企业应对人为误操作、软件错误、病毒入侵等“软”性灾害以及硬件故障、自然灾害等“硬”性灾害。

容灾的分类

从其对系统的保护程度来分,可以将容灾系统分为:

  • 数据级容灾是指通过建立异地容灾中心,做数据的远程备份,在灾难发生之后要确保原有的数据不会丢失或者遭到破坏,但在数据级容灾这个级别,发生灾难时应用是会中断的。在数据级容灾方式下,所建立的异地容灾中心可以简单地把它理解成一个远程的数据备份中心。数据级容灾的恢复时间比较长,但是相比其他容灾级别来讲它的费用比较低,而且构建实施也相对简单。

  • 应用级容灾是在数据级容灾的基础之上,在备份站点同样构建一套相同的应用系统,通过同步或异步复制技术,这样可以保证关键应用在允许的时间范围内恢复运行,尽可能减少灾难带来的损失,让用户基本感受不到灾难的发生,这样就使系统所提供的服务是完整的、可靠的和安全的。应用级容灾生产中心和异地灾备中心之间的数据传输是采用异类的广域网传输方式;同时应用级容灾系统需要通过更多的软件来实现,可以使多种应用在灾难发生时可以进行快速切换,确保业务的连续性。

  • 业务级容灾是全业务的灾备,除了必要的IT相关技术,还要求具备全部的基础设施。其大部分内容是非IT系统(如电话、办公地点等),当大灾难发生后,原有的办公场所都会受到破坏,除了数据和应用的恢复,更需要一个备份的工作场所能够正常的开展业务。

容灾的技术指标

主要有RPO(数据恢复点目标)和 RTO(恢复时间目标), 从客户的角度而言就是RPO需要为0(没有数据丢失),RTO越接近0越好(恢复时间越短越好)。

RPO(Recovery Point Objective):即数据恢复点目标,主要指的是业务系统所能容忍的数据丢失量,指灾难发生后,从IT系统宕机导致业务停顿之时开始,到IT系统恢复至可以支持各部门运作、恢复运营之时,此两点之间的时间段称为RTO,广道容灾备份系统RTO达到分钟级。

RTO(Recovery Time Objective):即恢复时间目标,主要指的是所能容忍的业务停止服务的最长时间,也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。

指从系统和应用数据而言,要实现能够恢复至可以支持各部门业务运作,系统及生产数据应恢复到怎样的更新程度,这种更新程度可以是上一周的备份数据,也可以是上一次交易的实时数据。

RPO针对的是数据丢失,而RTO针对的是服务丢失,二者没有必然的关联性。RTO和RPO的确定必须在进行风险分析和业务影响分析后根据不同的业务需求确定。对于不同企业的同一种业务,RTO和RPO的需求也会有所不同。

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第8张图片

容灾和容错的区别

  • 容灾(Disaster Tolerance):就是在上述的灾难发生时,在保证生产系统的数据尽量少丢失的情况下,保持生存系统的业务不间断地运行。容灾通常是通过冗余方式来实现的。

举例:飞机上有两个发动机,一个是主发动机,另外一个是备用发动机,主发动机坏了以后,立马切换到备用的发动机。

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第9张图片

  • 容错(fault tolerance): 发生故障时,系统还能继续运行。容错的目的是,发生故障时,系统的运行水平可能有所下降,但是依然可用,不会完全失败。

举例:飞机有四个引擎,如果一个引擎坏了,剩下三个引擎,还能继续飞,这就是"容错"。同样的,汽车的一个轮子扎破了,剩下三个轮子,也还是勉强能行驶。

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第10张图片

容灾备份的等级

国际标准SHARE 78 对容灾系统的定义有七个层次:从最简单的仅在本地进行磁带备份,到将备份的磁带存储在异地,再到建立应用系统实时切换的异地备份系统,恢复时间也可以从几天到小时级到分钟级、秒级或零数据丢失等。目前针对这七个层次,都有相应的容灾方案,所以,用户在选择容灾方案时应重点区分它们各自的特点和适用范围,结合自己对容灾系统的要求判断选择哪个层次的方案。

  • 0级:无异地备份

0等级容灾方案数据仅在本地进行备份,没有在异地备份数据,未制定灾难恢复计划。这种方式是成本最低的灾难恢复解决方案,但不具备真正灾难恢复能力。

在这种容灾方案中,最常用的是备份管理软件加上磁带机,可以是手工加载磁带机或自动加载磁带机。它是所有容灾方案的基础,从个人用户到企业级用户都广泛采用了这种方案。其特点是用户投资较少,技术实现简单。缺点是一旦本地发生毁灭性灾难,将丢失全部的本地备份数据,业务无法恢复。

  • 1级:实现异地备份

第1级容灾方案是将关键数据备份到本地磁带介质上,然后送往异地保存,但异地没有可用的备份中心、备份数据处理系统和备份网络通信系统,未制定灾难恢复计划。灾难发生后,使用新的主机,利用异地数据备份介质(磁带)将数据恢复起来。

这种方案成本较低,运用本地备份管理软件,可以在本地发生毁灭性灾难后,恢复从异地运送过来的备份数据到本地,进行业务恢复。但难以管理,即很难知道什么数据在什么地方,恢复时间长短依赖于何时硬件平台能够被提供和准备好。以前被许多进行关键业务生产的大企业所广泛采用,作为异地容灾的手段。目前,这一等级方案在许多中小网站和中小企业用户中采用较多。对于要求快速进行业务恢复和海量数据恢复的用户,这种方案是不能够被接受的。

  • 2级:热备份站点备份

第2级容灾方案是将关键数据进行备份并存放到异地,制定有相应灾难恢复计划,具有热备份能力的站点灾难恢复。一旦发生灾难,利用热备份主机系统将数据恢复。它与第1级容灾方案的区别在于异地有一个热备份站点,该站点有主机系统,平时利用异地的备份管理软件将运送到异地的数据备份介质(磁带)上的数据备份到主机系统。当灾难发生时可以快速接管应用,恢复生产。

由于有了热备中心,用户投资会增加,相应的管理人员要增加。技术实现简单,利用异地的热备份系统,可以在本地发生毁灭性灾难后,快速进行业务恢复。但这种容灾方案由于备份介质是采用交通运输方式送往异地,异地热备中心保存的数据是上一次备份的数据,可能会有几天甚至几周的数据丢失。这对于关键数据的容灾是不能容忍的。

  • 3级:在线数据恢复

第3级容灾方案是通过网络将关键数据进行备份并存放至异地,制定有相应灾难恢复计划,有备份中心,并配备部分数据处理系统及网络通信系统。该等级方案特点是用电子数据传输取代交通工具传输备份数据,从而提高了灾难恢复的速度。利用异地的备份管理软件将通过网络传送到异地的数据备份到主机系统。一旦灾难发生,需要的关键数据通过网络可迅速恢复,通过网络切换,关键应用恢复时间可降低到一天或小时级。这一等级方案由于备份站点要保持持续运行,对网络的要求较高,因此成本相应有所增加。

  • 4级:定时数据备份

第4级容灾方案是在第3级容灾方案的基础上,利用备份管理软件自动通过通信网络将部分关键数据定时备份至异地,并制定相应的灾难恢复计划。一旦灾难发生,利用备份中心已有资源及异地备份数据恢复关键业务系统运行。

这一等级方案特点是备份数据是采用自动化的备份管理软件备份到异地,异地热备中心保存的数据是定时备份的数据,根据备份策略的不同,数据的丢失与恢复时间达到天或小时级。由于对备份管理软件设备和网络设备的要求较高,因此投入成本也会增加。但由于该级别备份的特点,业务恢复时间和数据的丢失量还不能满足关键行业对关键数据容灾的要求。

  • 5级:实时数据备份

第5级容灾方案在前面几个级别的基础上使用了硬件的镜像技术和软件的数据复制技术,也就是说,可以实现在应用站点与备份站点的数据都被更新。数据在两个站点之间相互镜像,由远程异步提交来同步,因为关键应用使用了双重在线存储,所以在灾难发生时,仅仅很小部分的数据被丢失,恢复的时间被降低到了分钟级或秒级。由于对存储系统和数据复制软件的要求较高,所需成本也大大增加。

这一等级的方案由于既能保证不影响当前交易的进行,又能实时复制交易产生的数据到异地,所以这一层次的方案是目前应用最广泛的一类,正因为如此,许多厂商都有基于自己产品的容灾解决方案。如存储厂商EMC等推出的基于智能存储服务器的数据远程拷贝;系统复制软件提供商VERITAS等提供的基于系统软件的数据远程复制;数据库厂商Oracle和Sybase提供的数据库复制方案等。但这些方案有一个不足之处就是异地的备份数据是处于备用(Standby)备份状态而不是实时可用的数据,这样灾难发生后需要一定时间来进行业务恢复。更为理想的应该是备份站点不仅仅是一个分离的备份系统,而且还处于活动状态,能够提供生产应用服务,所以可以提供快速的业务接管,而备份数据则可以双向传输,数据的丢失与恢复时间达到分钟甚至秒级。据了解,目前DSG公司的RealSync全局复制软件能够提供这一功能。

  • 6级:零数据丢失

第6级容灾方案是灾难恢复中最昂贵的方式,也是速度最快的恢复方式,它是灾难恢复的最高级别,利用专用的存储网络将关键数据同步镜像至备份中心,数据不仅在本地进行确认,而且需要在异地(备份)进行确认。因为,数据是镜像地写到两个站点,所以灾难发生时异地容灾系统保留了全部的数据,实现零数据丢失。

这一方案在本地和远程的所有数据被更新的同时,利用了双重在线存储和完全的网络切换能力,不仅保证数据的完全一致性,而且存储和网络等环境具备了应用的自动切换能力。一旦发生灾难,备份站点不仅有全部的数据,而且应用可以自动接管,实现零数据丢失的备份。通常在这两个系统中的光纤设备连接中还提供冗余通道,以备工作通道出现故障时及时接替工作,当然由于对存储系统和存储系统专用网络的要求很高,用户的投资巨大。采取这种容灾方式的用户主要是资金实力较为雄厚的大型企业和电信级企业。但在实际应用过程中,由于完全同步的方式对生产系统的运行效率会产生很大影响,所以适用于生产交易较少或非实时交易的关键数据系统,目前采用该级别容灾方案的用户还很少。

容灾备份的解决方案

阿里云的容灾备份解决方案为例。

ECS的容灾备份

  • 备份恢复

阿里云ECS可通过快照镜像对系统盘、数据盘进行备份。如果存储在磁盘上的数据本身就是错误的数据,例如由于应用错误导致的数据错误,或者黑客利用应用漏洞进行恶意读写,此时就可以使用快照服务将磁盘上的数据恢复到期望的状态。另外ECS可通过镜像重新初始化磁盘或使用自定义镜像新购ECS实例。

  • 容灾应用

ECS可以从架构上实现容灾场景下的应用。例如,在应用前端购买SLB产品,后端相同应用部署至少两台ECS服务器,或者是使用阿里云的弹性伸缩技术,根据自定义ECS自身资源的使用规则进行弹性扩容。这样即便其中一台ECS服务器故障或者资源利用超负荷,也不会使服务对外终止,从而实现容灾场景下的应用。下图以同城两可用区机房部署ECS集群为例,所有通信均在阿里云千兆内网中完成,响应快速并减少了公网流量费用:

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第11张图片

  1. 负载均衡SLB:设备侧通过多可用区级别SLB做首层流量接入,用户流量被分发至两个及以上的可用区机房,机房内均部署ECS集群。
  2. ECS集群:可用区机房部署的ECS节点是对等的,单节点故障不影响数据层应用和服务器管控功能。发生故障后系统会自动热迁移,另外的ECS节点可以持续提供业务访问,防止可能的单点故障或者热迁移失败导致的业务访问中断。热迁移失败后通过系统事件获知故障信息,您可以及时部署新节点。
  3. 数据层:在地域级别部署对象存储,不同可用区机房的ECS节点可以直接读取文件信息。若是数据库应用,使用多可用区ApsaraDB for RDS服务做承载,主节点支持多可用区读写,与应用层流量来源无冲突关系。同时,备节点支持多可用区读能力,防止主节点故障时,ECS无法读取数据。

同城容灾

同城容灾指应用服务部署是多机房、单地域时,当其中一机房出现故障时,系统可实现业务7*24小时稳定运行,即使单机房故障也不影响业务的可持续性,保障用户访问连续不间断。

同城双活容灾架构,是指在同城建立两个可独立承担关键系统运行的数据中心,双中心具备基本等同的业务处理能力并通过高速链路实时同步数据,日常情况下可同时分担业务及管理系统的运行,并可切换运行;灾难情况下可在基本不丢失数据的情况下进行灾备应急切换,保持业务连续运行。多数企业为了兼顾成本与高可用性问题,会优先选择同城双活的部署方式。

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第12张图片

异地容灾(两地三中心)

异地容灾是指应用服务部署在不同地域时,当其中一地出现故障时,系统可以将出现故障地域的用户访问流量,调度至异地灾备中心,保障用户访问连续不间断。

两地三中心容灾架构,是指在同城双中心的基础上,在异地的城市建立一个备份的灾备中心,用于双中心的数据备份,当双中心出现自然灾害等原因而发生故障时,异地灾备中心可以用备份数据进行业务的恢复。

架构设计内容分享(三十):架构之高可用:负载均衡,容灾备份,故障转移_第13张图片

故障转移和恢复

什么是故障转移

故障转移(failover),即当活动的服务或应用意外终止时,快速启用冗余或备用的服务器、系统、硬件或者网络接替它们工作。 故障转移(failover)与交换转移操作基本相同,只是故障转移通常是自动完成的,没有警告提醒手动完成,而交换转移需要手动进行。

要使故障转移正常工作,必须有一个数据备份裸机服务器或虚拟机充当恢复站点系统,以便在发生故障时替换主站点。由于故障转移是灾难恢复中必不可少的步骤,因此数据备份系统本身必须不受故障影响。

需要持续可用性的系统需要整体故障转移和灾难恢复。在服务器级别,数据备份环境跟踪主服务器的“脉冲”,并在检测到中断时执行自动故障转移。

如何进行故障转移

有两种方法可以设置故障转移系统:主动-主动主动-被动(或主动-备用)配置。两种设置都需要至少两个节点(服务器或虚拟机)才能正常工作。

主动-主动设置中,多个节点同时运行。这允许他们分担工作量并防止任何一个节点过载。如果一个节点停止工作,它的工作负载将被其他活动节点占用,直到它重新激活。

主动-被动(主动-备用)设置还包括多个节点,但并非所有节点都同时处于活动状态。一旦主动节点停止工作,被动节点就会被激活并充当故障转移节点。当主节点再次运行时,数据备份节点将操作切换回主节点并再次变为被动状态。

无论采用哪种故障转移方法,两种配置都要求每个节点具有相同的配置。这确保了在站点之间切换时的一致性和稳定性。

什么是故障恢复

故障恢复是在计划内或计划外中断解决后切换回主站点的过程。故障恢复通常在故障转移之后作为灾难恢复计划的一部分。

故障恢复不是完成故障转移的唯一方法。使用虚拟机时,您可以执行永久故障回复,使数据备份虚拟机成为新的主站点。

如何进行故障恢复

成功执行故障回复需要一些准备。在切换回主站点之前,请考虑以下步骤:

  1. 检查与主站点的连接的质量和网络带宽。
  2. 检查备份站点上的所有数据是否存在潜在错误。这对于关键文件和文档尤其重要。
  3. 在开始故障恢复之前彻底测试所有主系统。
  4. 准备并实施故障恢复计划,以最大限度地减少停机时间和用户不便。

 

你可能感兴趣的:(架构设计,内容分享,架构,负载均衡,运维)