HCIE华为云计算面试-云容灾

华为FusionSphere容灾方案中有两种组网方式（适用于虚拟化场景，用到的软件是UltraVR），简单描述一下两种技术原理，主机复制容灾方案的规划设计。（2种可以同时存在）

1. 主机复制容灾
   技术原理：利用主机的IO复制镜像功能，将生产站点上虚拟机的数据远程复制到容灾站点，实现虚拟机数据的复制和保护。
2. 存储阵列容灾
   技术原理：利用存储的同步/异步远程复制技术，将数据从生产中心复制到灾备中心。（一般用异步远程复制，因为两地站点一般相隔较远，同步远程复制技术时延较高）

• 与华为容灾解决方案中的本地高可用技术类似，但它基于本地
• 并没有用到vis，技术很落后，就用到了远程复制的技术

3. 主机复制容灾方案的规划设计
   1）规划前提
   根据客户的需求收集要容灾的应用类型，应用的写IOPS（平时和繁忙）是多少，要容灾多少虚拟机，传输的链路带宽有多少，客户对容灾的RPO和RTO的需求是多少
   2）规划网络带宽

• 管理链路的带宽：至少配置10Mbps的带宽
• 主机IO复制链路的带宽
  • 初始IO复制怎么复制
    把生产端数据导到存储，然后把存储搬到灾备站点，在复制进去
  • 增量IO复制链路的带宽
    连续IO复制的带宽计算公式：待容灾的虚拟机的数量x8/0.7（带宽利用率系数）带宽建议>=70MB/s
    非连续IO复制的带宽计算公式：待容灾的虚拟机的数量x虚拟机周期内平均的写IOPSxIO数据块的大小x8/0.7，带宽建议>=50MB/s
• 对IP链路的（网线，传输IP数据包）要求：时延（小于等于50ms,最大也不会超过200ms），丢包率（小于千分之一），防止单点故障（要两条链路去做负载均衡）
  3）规划生产站点，容灾站点系统配置
• MAC地址池的规划（fc可以提供10万个mac地址给用户使用，10万个mac地址分配到生产站点和灾备站点的时候不能重复）
• 确定容灾虚拟机数量，类型
• 确定数据存储的容量（一般容量大小根据容灾虚拟机的容量以及快照的数量去确定数据存储的容量）
• 快照，设置周期为4h，最少要对虚拟机打两个快照，最多32个快照
• VRG数量的考虑（IOPS/1500，磁盘数量总和/200，容灾虚拟机数量/150）选一个最大值，举例：一个VRG能容灾1500个IOPS，能容灾200个磁盘数量，能容灾150个虚拟机。（生产站点的VRG数量和灾备站点的VRG数量一一对应，并且部署的VRG一定要和主机要绑定）
  4）规划生产站点
• 装好软件进行初始配置包括各种映射关系，映射好主机，VRG等
• 默认创建VRG的最小规格（最小规格：2个cpu，6G内存，15G磁盘，挂100G的数据盘）一台主机上只能部署一台VRG。
• 容灾虚拟机使用的存储：一般使用虚拟化数据存储或者FS
• 容灾站点的规划和生产站点的规划基本是一样的
  追问：链路带宽是多少，IO增量复制带宽怎么计算，连续IO复制带宽和非连续IO复制带宽的计算公式是什么，公式里的数据代表什么含义。

追问：VRG虚拟机是什么？站位虚拟机是什么？

• VRG本质是一个虚拟机，作用是当虚拟化复制网关，实现主机层远程复制。
• 站位虚拟机，在灾备站点创建的和生产站点一模一样的虚拟机，平时不提供业务，只有灾难发生时，站位虚拟机才会被拉起提供业务

问题：请描述华为容灾解决方案全景图，并解释双活数据中心需要从哪些角度着手考虑？ 云计算容灾解决方案全景图（本地，同城，异地）用到的是BCManager这个软件（ebackup和eReplication）

1. 本地高可用方案

• 为了保证业务的连续性，从两方面考虑，一方面从虚拟化集群层的HA (high ability)考虑，RTO一定不为0，一方面从存储层考虑，存储层用到的是VIS和OceanStro V3，VIS是一个网关设备，可以管理很多存储，
• 答：本地高可用这个方案为了保证业务的连续性，可以从两个层次方面来考虑，一个是从主机，服务器这个层面考虑，假如这个服务器上的虚拟机或者说业务挂掉了，然后可以自动的从其他服务器上把它拉活，以此来保证业务的连续性，主要是通过集群HA的这些特性。还有一个是从存储层面上考虑，用到了VIS（华为虚拟化智能存储设备）这种网关设备，VIS会对华为的存储和其他异构的存储一起接管，上层虚拟机下发IO的时候，先到主机，然后再到存储，在到达存储之前必须先经过VIS这个设备，把写IO先写到VIS网关设备的虚拟卷上，然后通过这个设备把数据写到这个虚拟卷对应下面存储中的两个卷（lun），这两个卷上的数据互为mirror，如果其中一份数据坏了的话，另一份还可以继续使用，这个也是保证了业务的连续性。

2. 同城容灾方案

• 主备容灾（同步远程复制技术/异地远程复制技术）
  • 同步远程复制和异步远程复制这两种技术的区别：写复制的时候不一样，同步远程复制就是对端写完成返回写成功，异步远程复制就是本端写完成返回写成功。
  • 只能是同构的存储，且需要人手动拉起。
  • 技术很成熟，但是会停业务，RTO不等于0。如果是用的同步远程复制技术，RPO=0；如果是用的异步远程复制技术，RPO就不等于0.
• 双活容灾
  系统能自动拉起。
  业务很关键，使用双活，成本高，RPO，RTO=0.

3. 异地容灾方案

• 两地三中心
  必须在双活的基础上做主备容灾（由于距离的情况只能是异步复制）
  对容灾要求很高，要对抗洪水，天灾，所以成本也高
• 主备容灾（异步远程复制技术）
  只能是同构的存储，且需要人手动拉起。

双活数据中心

• 得分点：从GSLB，业务层，虚拟化集群，数据库集群，存储层多层来考虑。任何一个单层的双活都不能称为真正意义上的双活，双活特性中的两个数据中心互为备份，且都处于运行中。
• 最少要考虑四层：业务层，网络层，计算集群层，存储层（重要双活层面）
  • 网络层双活：如果外部有一个业务请求过来了。先到SLB，SLB会看自己所在的数据中心的主机是不是好的，能否提供业务，如果SLB发现主机已经废了，这个时候会触发GSLB，然后该GSLB会通知对端的GSLB开始工作，GSLB会通知它下面的SLB工作，SLB会通知底下的主机对业务请求做出响应，然后返回响应给对端，完成双活。
  • 计算集群层双活（主机层双活）：把两个数据中心的这些主机搞成一个计算集群。
  • 存储层双活：一般选用华为OceanStor V3的存储，用的是hypermetro这个特性，实现了RPO,RTO=0，在写IO上，上层下发一个写IO，首先两端存储会有一个写互斥，先拿到写权限的一端就先开始写，要写完，然后另一端也写完成后才会返回写成功；读的时候，用到了ultra path，根据ultra path特性选择一个最优路径，免网关的一个设计，不需要VIS，替代VIS去权重选择一个最优路径，减少设备和开销。而且开启了hypermetro也可以异构存储，把这些存储阵列制成了vDISK统一使用。
  • 业务层双活：业务的双活是通过负载均衡来实现的，也就是GSLB和SLB这两个东西去实现的。通过应用集群技术和数据库集群技术实现的。
• 扩展两层
  • 传输层：设备和板卡冗余，构建可靠的双活传输网络
  • 安全层：通过防火墙和安全策略规划和设计保证访问安全，
• 追问1：本地高可用能不能用异构存储
  本地高可用用到了VIS做异构，而双活用的是hypermetro做异构
• 追问2：同城的主备和异地的主备有什么区别
• 追问3：在什么样的场景下建设两地三中心
• 追问4：GSLB这种东西你是怎么理解的
  网络层实现双活的手段，平时不工作，只有在灾难发生的情况下才会启用。

誉天答法：

• 本地容灾解决方案
  • 本地高可用方案
    • 应用层：做应用集群，实现业务的连续性，举例：手机，电脑，平板同时登录你的QQ（x）
    • 主机层：通过集群做HA，实现业务的连续性，可自动拉活业务，减少业务中断时间。
    • 存储层：技术三选一
    1. 第一种技术：同步远程复制技术，如果有eReplication，可以自动切换业务，没有的话，手动拉活（适用于两地）
       why：因为本地很近，同步和异步成本差不多，同步RPO=0
       同步远程复制技术的解释：生产站点的存储和灾备站点的存储各划一个lun，然后建立远程复制关系，写IO下来了，写复制的时候，主端先写完成后，然后把数据复制到从端，从端写完成后，才能返回写成功。RPO=0，RTO不等于0。
    2. 第二种技术：VIS华为虚拟化智能存储设备，VIS会对华为的存储和其他异构的存储一起接管，上层虚拟机下发IO的时候，先到主机，然后再到存储，在到达存储之前必须先经过VIS这个设备，把写IO先写到VIS网关设备的虚拟卷上，然后通过这个设备把数据写到这个虚拟卷对应下面存储中的两个卷（lun），这两个卷上的数据互为mirror，如果其中一份数据坏了的话，另一份还可以继续使用，这个也是保证了业务的连续性。
    3. 第三种技术：可以做存储层的双活，前提你得是华为的高级存储，如OceanstorV3，V5等，用到的是hypermetro特性。（x）
       答法：一般选用华为OceanStor V3的存储，用的是hypermetro这个特性，实现了RPO,RTO=0，在写IO上，上层下发一个写IO，首先两端存储会有一个写互斥，先拿到写权限的一端就先开始写，要写完，然后另一端也写完成后才会返回写成功；读的时候，用到了ultra path，根据ultra path特性选择一个最优路径，免网关的一个设计，不需要VIS，替代VIS去权重选择一个最优路径，减少设备和开销。而且开启了hypermetro也可以异构存储，把这些存储阵列制成了vDISK统一使用。
       答法：一般要选用华为的V3，V5等这样的存储才会有hypermetro这个特性，实现了RPO=0，RTO=0，在写IO上，上层下发一个写IO，首先两边的站点会有一个写互斥，先拿到写权限的一端就开始双写；读的时候，会用到ultra path这个多路径软件，根据ultra path特性去选择一个最优路径读，这是免网关的一个设计，可以减少设备的开销，然后因为开启了hypermetro，它还可以异构存储。
  • 主备容灾解决方案
    技术：同步远程复制技术
    和上面存储层的同步远程复制是一样的技术。
• 同城容灾解决方案
  • 同城双活（双活六层）
  1. 应用层双活（业务层双活）
     做应用集群
  2. 网络层双活
     通过全局负载均衡器来做双活，GSLB和SLB
     如果外部有一个业务请求过来了。先到SLB，SLB会看自己所在的数据中心的主机是不是好的，能否提供业务，如果SLB发现主机已经废了，这个时候会触发GSLB，然后该GSLB会通知对端的GSLB开始工作，GSLB会通知它下面的SLB工作，SLB会通知底下的主机对业务请求做出响应，然后返回响应给对端，完成双活。
  3. 安全层双活
     多台防火墙来保证访问安全。
  4. 计算集群层双活
     把两个数据中心的主机纳管到一个集群里，通过虚拟机HA等高级特性做双活
  5. 传输层双活
     设备冗余，例如交换机冗余，线路冗余。
  6. 存储层双活
     写IO下发下来了，数据会同时双写到两端站点的存储（lun）中，并且两端会同时向上提供业务，都是运行的，实现RTO=0，RPO=0，如遇故障，自动拉活业务。
     答法：一般要选用华为的V3，V5等这样的存储才会有hypermetro这个特性，实现了RPO=0，RTO=0，在写IO上，上层下发一个写IO，首先两边的站点会有一个写互斥，先拿到写权限的一端就开始双写；读的时候，会用到ultra path这个多路径软件，根据ultra path特性去选择一个最优路径读，这是免网关的一个设计，可以减少设备的开销，然后因为开启了hypermetro，它还可以异构存储。
  • 主备容灾解决方案
    • 第一种技术：同步远程复制技术，有延时
    • 第二种技术：异步远程复制技术，无延时
  • 虚拟化网关复制技术（主机层容灾，只能适用于虚拟机的场景，保护虚拟机）
    在两端的站点的主机上各用虚拟机装一个VRG，（VRG的作用是当虚拟复制网关，实现主机层远程复制），VRG不对外提供业务。假如一个主机上的虚拟机要做容灾，就会在对端的主机上创建一个一模一样的虚拟机（站位虚拟机），如果有IO下发，要写入的话，会通过IO mirror这个技术，把VRG虚拟机的磁盘和要做容灾的虚拟机的磁盘做成mirror，这个IO会写入这两个磁盘，然后该VRG会传输数据到对端的VRG，灾备端会通过write agent（写代理）把数据传输到站位虚拟机中，如果主端虚拟机挂了，灾备端的站位虚拟机会马上起来提供业务。RPO不等于0，RTO接近0，只要占位虚拟机开机业务就能活。
    站位虚拟机怎么来的：通过eReplication对接两端的VRM，然后eReplication把需要容灾的虚拟机的配置信息传到对端的VRM上，由对端的VRM创出来的。
• 异地容灾解决方案
  • 两地三中心
  1. 主端生产站点----同城灾备站点----异地灾备站点
     级联场景：对主端压力较小，但相对不安全
     同步+异步/异步+异步
  2. 主端生产站点
     同城灾备站点
     并联场景：对主端压力很大，但较安全
     同步+异步/异步+异步
     异地灾备站点
  3. 双活+异步
     级联
     并联
  • 主备容灾解决方案
    技术：异步远程复制技术
    why：因为距离较远，用同步远程复制技术的话时延太高
    异步远程复制技术的解释：生产站点的存储和灾备站点的存储各划一个lun，然后建立远程复制关系，写IO下来了，写复制的时候，主端写完成后，就返回写成功，当达到一个同步周期，主端就会把数据拷到从端。RPO和RTO都不等于0.
  • 虚拟化网关复制技术
    也是异步的，VRG的容量达到一个程度，才会传数据到对端的VRG上去。

RTO和RPO的解释：RTO指发生灾难了，业务中断时间；RPO指发生灾难了，数据损失量。举例，下午4点发生灾难，6点恢复，RTO=2，恢复数据只能恢复到下午3点，RPO=1。单位都是时间。

UltraVR只能用于虚拟化场景，eReplication可用于虚拟化场景，私有云场景，数据库场景。

转载：https://blog.csdn.net/u011708337/article/details/108249611