第七章：其它模式

灾备组网

高可用性组网，单核心场景下，直接在两个站点中设置一个第三方仲裁站点，两个站点同时连接到仲裁，并且连接到对方。一旦出现问题，则由仲裁站点进行判断，进行业务切换

双核心场景下，仲裁站点通过接收两个站点的管理网络发送的心跳信息，进行业务在线判断，一旦其中某一站点出现问题，那么仲裁会发送消息到另一端的管理网络，要求该端拉起业务，保证业务连续性，同时仲裁站点还会记录故障时间，和当前情况，便于后续生产站点恢复之后，进行业务的还原。

两地三中心场景下，仲裁负责的是本地生产和本地灾备站点的主备切换，CSDR服务中包含的容灾，则是通过业务核心进行数据的远程复制，从生产站点或者是灾备站点复制到异地灾备站点。

双核心场景下，两地三中心需仲裁站点连接本地生产和本地灾备，同单独CSHA场景。但是包含了CSDR容灾之后，就需要异地灾备站点的管理核心和业务核心同时连接本地生产和本地灾备的管理核心和业务核心。不论客户最终使用串联3DC还是并联3DC模式，线都是要连接好的。因为这种大规模的DC建设必须要做好客户需求变更的设计冗余，不要在初始化设置的时候就只做满足用户基本需求的设计，而是需要做好冗余设计，便于后期用户修改需求。

云联邦

云联邦主要是针对于云间网络进行的设计，云间网络包含管理网和业务网两个模块。

管理平面主要承载云间管理数据，包括认证鉴权、业务管理、运维管理等

业务平面主要承载业务交互数据，例如灾备场景的数据同步、业务软件间的接口调用等

云联邦网络设计基准：

1. 用户对网络性能需求高，那么就使用专线，如果用户穷，就用普通网络
2. 网络安全需求高，则专线+VPN，其他情况选择普网+VPN
3. 网络质量要求高，则根据需求选择，如果客户只是需要高带宽，普网和专线区别不大。如果对可靠性和延迟要求极高，那么一定专线。
4. 预算

如果不使用任何专线，那么就直接配置IPSec VPN进行连接

如果全专线，可以和华为定制接入方案

第八章：HCS架构设计

HCS网络平面设计

1. 公共服务平面
   1. External_OM（Openstack manager）：HCS云平台管理平面，主要负责运维接入对接外部服务器，以及流量转发，分为了Cascading管理流量和Cascaded被管理流量。
   2. DMZ_Service：公共服务区云服务使用的网络，包括LVS、Nginx负载均衡类服务，CloudConsole云控制服务以及相关的一些接入性控制服务。同时包含了高级云服务和底层VM互通的网络服务提供
2. 存储平面：
   1. 管理存储平面：Management_Storage_Data
   2. 业务存储平面：Service_Storage_Data
3. OpenStack管理平面
   1. External_Relay_Network：租户内大网平面，主要是负责VM内部与管理侧相关服务进行通信的需求，由于在实际使用过程中，多个VPC内部的VM地址可能重叠，但是这些VM在访问公共服务以及相关的管理服务的时候，是不能使用VPC内部IP的，会导致网络冲突。所以就需要内大网平面进行NAT转换，将VPC内部的地址转换为不冲突的IP，保证每个VM的内大网地址是唯一的，这样就可以避免冲突，保证全局内大网地址唯一。内大网的分配一般来说会建议分配一个非常大的网段，尤其是在业务量比较大的情况下，因为内大网分配的IP地址是要求全局唯一的，但是内部的VM数量是非常多的。所以内大网分配的网段IP数量一定要非常多，一般建议选择10.0.0.0/10这个范围以上。
   2. Internal_Base：内部管理平面，主要承担的是PXE流量（DHCP网卡启动），OpenStack的南向通信，代理、运维、网络配置手机、升级、告警、公共服务等相关的流量。所以Internal_base一般也建议选择一个比较大的网段，如172.16.0.0/15网段，这个网段内的IP，也是通过DHCP分配的，由OpenStack进行分配

规划规则：

1. 单个Region内，所有网络平面的分配是不允许冲突的
2. 多个Region的时候，建议不要选择合并设计IP，最好是分开设计，全局统一IP设计的时候，容易造成IP地址不足
3. 针对于网络服务、VPN、专线服务等固定IP的设计，不允许冲突，不能复用，即不允许一个公网IP，即作为网络出口也作为专线接入接口，这样做容易造成网络拥塞和网络冲突
4. External_OM平面在进行管理的时候，必须要和BMS、存储的带外管理网络互通。其他服务也遵循这个概念，但是大数据FusionInsight HD除外。
5. 规划的IP地址，至少要以120%的标准超分。

交换机VRF（虚拟路由转发）设计

1. 交换机中不同功能的接入和流量必须要做好隔离，不允许在交换机层面进行互通
2. 如果真的平面之间需要进行互通，则需要通过北向转发，到防火墙层面通过安全策略开放互通
3. 交换机的几种流量设计
   1. InterNet：主要是承担外部访问流量，虽然名字叫互联网，但是实际设计的时候，只要是从外部来的流量，都属于外部访问流量，这个流量可以来自于公网，也可以来自于内部的东西向或者是南向流量。所以这种流量名字也可以被叫做External
   2. Public：也称为公共区流量，主要传递的是内部运维流量和云服务之间通讯流量，包括前往内大网、东西向以及VXLAN相关的多种流量都是通过公共服务平面转发。
   3. DMZ：主要负责的是云服务业务流量，包括对公网进行暴露的服务的流量。
   4. BMC：底层带外管理流量，一般不建议管理业务流量和带外管理流量通过一台服务器进行转发，最好是底层带外管理流量接入专门的交换机进行统一纳管
   5. OMAccess：运维接入平面，主要是远程接入和本地运维使用，属于可选项，一般来说可以和管理业务平面使用相同的交换机。但是在高安全的场景下，比如等保和涉密场景，业务、管理、带外管理、运维需要通过不同的设备做物理隔离。
4. 防火墙域设计

为了能够满足网络安全性需求，我们将不同设备接入的物理连线划分到对应的domain域中，通过安全区域的设计，将各种流量进行隔离，根据用户的需求，底层交换机有多少个网络平面类型，防火墙就应该有多少个安全区域

1. 网络互联设计

核心网互联IP规划需要遵循可用，足够使用即可，不要多分IP，即交换机和出口PE或外部接入TOR之间的访问，IP地址至少需要一个30位掩码的IP规划。如果交换机连接不同设备使用不同网段，那么就配置30位掩码，即2个可用IP配置在连接的设备两端。多设备使用相同的VLAN时，根据实际需求按需分配。

核心区和防火墙互联的时候，需要保证交换机的每个平面或者说是防火墙的每个安全区域都要和核心交换机有一个网段做互联，不要使用相同网段的IP。每对互联的地址，至少是29位IP（6个可用IP，防火墙1，核心交换机1，接入TOR1，业务服务器1），根据实际提供服务的服务器的数量进行合理划分，建议超分50%

1. 静态路由设计

交换机对于整体性转发或默认路由转发都需要以静态路由配置，静态路由需要完成几个任务

1. 1. 默认路由到PE：负责对外转发流量
   2. 默认路由由核心交换到管理墙：负责将网络平面的流量转发到防火墙的安全区域网关或VRF，每个VRF都需要有默认路由的存在。
   3. 公网访问：公网访问的流量，首先需要通过核心交换转发到防火墙进行安全检查，所以访问内部的流量都需要先行转发到防火墙，然后再通过核心交换转发到对应的位置
   4. 网络节点流量转发：外部访问流量，经过防火墙之后，会被转发到BR进行内部转发（SDN），内部流量根据转发的位置不同，转发到相应的服务，BR（外部访问），ENAT（外部访问、VPC互访、云连接），vRouter（跨网段站点内互访使用）……参考HCS网络流量概述章节

1. 1. 防火墙的静态路由分为了两个部分，对外使用默认路由直接转发到出口PE，对内通过VRF进行转发即可。

部署规划设计

基础控制节点至少3台，网络计算融合节点至少2台，计算节点按需设置，扩展管理节点根据部署的高阶云服务进行扩展。

管理节点：

网络节点：

由于网络服务是通过SDN实现的，所以均支持虚拟化部署

基础云服务节点（ECS、EVS）：

通用ECS是必选的，计算节点中的EVS是可选的，但是EVS服务是必选的。计算节点中的EVS是属于扩展资源类，EVS服务是ECS启动的必选项，如果不使用计算节点的存储资源建设EVS，那么就必须通过其他形式实现，如IPSAN、Dorado存储、OceanStor Pacific等

ECS和EVS并没有在基础云服务中直接安装，只是安装了一个可以发放和创建ECS和EVS的管理框架，即FusionSphere OpenStack，实际安装的时候，就是安装这个进程和服务接口。

BMS节点：

可选服务，如果安装BMS，那么FusionSphere OpenStack、和BMGW是必须要安装的。其他的待发放的BMS节点，都没有预制相关的进程，仅当客户下发请求要求拉起BMS的时候FusionSphere OpenStack才会下发请求到BMS节点，加载EVS硬盘拉起系统给用户使用。

备份和高可用性节点：

ebackup：备份容灾服务，预制安装ebackup服务端、代理。Agent客户端仅当发起备份容灾的业务的时候，才会安装在被备份和容灾的系统上。ebackup本身是一个软件，预制在EulerOS系统中，我们没办法直接装ebackup软件，只能是安装系统，系统自动化会部署好。（ebackup虽然在图中标识必须要物理部署，但是实际上虚拟机部署也可以用）

时钟同步

全局所有的服务器、所有的进程、所有的业务，必须要保证时间差不能超过5min，否则会直接导致业务离线。在实际交付中，必须要配置NTP时钟源，时间可以不正确，但是必须全局一致

如果没有时钟源，建议配置一个时钟服务器，可以以虚拟机的形式进行提供，但是要绝对保证稳定，全局和时钟源进行时间同步

HCS LLD设计

1. 需求调研
   1. 建设背景（HCS Designer无法生成，需要自己写）
      1. 客户介绍
      2. 运营现状
      3. 数据中心调研（设备数、容量、业务类型）
      4. 客户需求和业务冲突
      5. 客户需求目标（简单业务目标）
   2. 建设目标（HCS Designer无法生成，需要自己写）
      1. 资源目标
      2. 参数目标（带宽、延迟、存储空间、响应速度……）
      3. 其他目标（备份、容灾……）
   3. 建设范围（怎么建设、建设什么？软件层面，自动生成）

1. 1. 项目物料概述（设备和硬件层面，自动生成）

1. 架构设计部分
   1. 逻辑架构设计：主要是HCS的业务安装选择以及控制组件、管理组件的安装配置
   2. 物理架构设计：包含组网、连线、以及底层架构的设计
   3. 设备选型：主要是硬件设备的选型设计，实际上和项目物料概述是有一定的重复性的，所以这个部分一般来说要写的是硬件和功能的对应，比如哪些型号的服务器要安装什么类型的服务
   4. 机房基础信息：依赖于工勘。从此刻开始，物理部署和上架部分开始
   5. 机柜部署方案：自动生成，系统会选择安全性最高的方式进行部署，主要依赖的就是以下几条规则
      1. 大型设备放下边，小型设备放上边
      2. 机柜连接的TOR包括BMC-TOR、管理/业务TOR、存储TOR等交换机，都是放在机柜的最上边
      3. 功能相同的交换机，一定要放在不同的机柜上
   6. 设备命名：根据自动化设计输出，主要命名方案为：机房缩写-机柜编号-设备位置-功能区-功能组件-设备型号-设备编号，例如DC1-A02-37U-Mgmt-BMCSW-CE6530-01
2. 网络设计
   1. 管理区
      1. 公共网络平面：
         1. External_OM（OpenStack Manager）：云平台管理平面，主要负责运维的接入，存储管理平面的接入、对接外部管理源（NTP、DNS、SYSLOG），同时负责后端VM、DB（内部DB）、VM内部网络的管理。
         2. DMZ_Service（服务区服务提供）：主要负责云服务使用的公共服务的提供，如LVS、Nginx负载均衡服务，云服务Console类接入，租户相关的全局类服务。即提供了全局云服务的管理和通用业务的提供
      2. 存储平面：
         1. Management_Storage_Data：管理存储平面
         2. Service_Storage_Data：业务存储平面
      3. OpenStack管理平面
         1. Relay_Network：内大网平面，主要是针对于全局云服务所需要的公共服务进行网络提供，保证全局资源可以通过一个统一网络进行连接和沟通，因为提供的公共服务面向于所有的用户，所以这些资源需要使用一个全局唯一的IP进行接入，所以内大网必须要大范围的IP提供
         2. Internal_Base：内部管理平面，主要是负责pxe的提供，即DHCP启动服务，OpenStack通过该平面进行运营运维信息的获取和采集

HCSD功能概览

HCS故障处理

1. 故障处理整体思路
   1. 信息收集：采集系统出现的相关的问题，告警、包括但不限于故障现象，故障时间频率，影响范围，日志（故障前的动作），故障处理进度。云平台故障信息采集主要是通过ManageOne实现，底层网络故障，是通过AutoOps实现的。CloudNetDebug可以收集网络设备的保障信息。
   2. 故障处理思路：先定位全局错误，在定位局部错误。先解决整体故障，在解决细节故障。先解决管理故障，后解决业务故障。

故障定位主要依靠于告警（警告、一般、严重、紧急）、日志（确定是否有误操作情况）、设备配置（是否出现了配置变更或硬件故障）

1. 1. 恢复思路：
      1. 先解决报警，根据告警代码解决相关问题
      2. 性能报障需要通过资源扩展或者是降低资源使用率进行实现
      3. 操作错误就通过反向配置恢复解决
      4. 数据配置错误可以重新进行配置
      5. 硬件设备异常根据实际硬件错误解决

根据IDC统计，在数据中心系统故障中，一般情况下，系统的问题70%左右都是由于硬件故障导致的，17%是由于配置故障出现的，只有不到3%是由于软件bug导致的，其余大部分故障原因都是由于人为因素造成。