芜湖市政务云平台应急预案

发布时间:2024-11-13 09:46信息来源: 芜湖市数据资源管理局阅读次数:编辑:市数据资源管理局 字体:【  

 

一、 总则

1.1 文档目的

1.2 使用对象及场景

1.3 应急操作原则

1.4 适用范围

1.5 组织保障

1.5.1数据局及中心领导组

1.5.2电信领导组

1.5.3业务保障小组

1.5.4 应急响应小组

二、 政务云平台网络现状

2.1. 政务云网络拓扑图

2.2. 软网络系统架构图

2.3.可能性故障点列表

三、 政务云平台应急处置预案

3.1 故障处理预案

3.1.1网络类

3.1.2计算域类

3.1.4硬件类

3.1.4存储类

四、 系统备份、恢复方案


一、总则

1.1 文档目的

为应对芜湖市政务云软硬件平台突发事件,建立应急保障和恢复工作机制,保证应急工作迅速、高效、有序地进行,满足突发事件下芜湖市政务云及其承载的数据业务保障和恢复工作的需要,确保政务云软硬件平台的正常运行,特制定本应急方案。

1.2 使用对象及场景

本文档用于政务云平台维护人员使用参考。

设备出现紧急问题时,指导平台维护人员进行初步的故障定位与排除。

1.3 应急操作原则

业务应急恢复操作应综合考虑相应操作风险、成功恢复业务的可能性和相应操作的时间,基于先抢通业务的总原则指导处理过程。

推荐的操作排序如下:

1.耗时比较短、成功可能性比较大的操作。

2.耗时比较短、成功可能性比较小的操作。

3.耗时比较长、成功可能性比较大的操作。

注意事项

1.出现故障后以恢复业务为首要目标。

2.收集必要的日志供定位问题和事后分析,在收集日志和恢复业务发生冲突时,以尽快恢复业务为先。

3.避免处理不当导致问题扩大,对于关键操作要谨慎,要及时记录操作步骤,必要时进行恢复操作。

应急处理操作流程:

1.4 适用范围

本方案适用于芜湖市政务云平台发生突发事件的处置,常见的应急故障有以下几个方面。

1.网络软硬件故障导致平台承载的系统访问异常;

2.计算域软硬件功能故障导致业务部分功能无法正常使用;

3.存储软硬件功能故障导致系统无法正常运行;

4.各类支撑平台系统性能严重下降,导致承载业务系统不能正常使用;

5.服务器或关键核心设备发生致命硬件故障或宕机,以致业务中断运行。

当政务云平台在运行过程中突然出现上述故障情况时,可参考本文说明,选择对应的预案及时进行正确的处理,减少或者避免可能发生的损失或者损坏,让系统迅速恢复正常运行。

1.5 组织保障

1.5.1数据局及中心领导组

负责全面指挥政务云通信与网络信息安全应急保障工作,负责蒋实上级部门关于应急保障工作工作决策部署,审定应急保障方案,开展监督检查,指导突发安全事件处置,统一调度工作组人员,确保应急保障各项工作落地,关注应急保障期间值班情况。

序号

姓名

角色

1

尤银田

组长

2

夏光辉

副组长

3

岳磊

组长

4

冉明顺

副组长

 

 

1.5.2电信领导组

组长:徐红侠,就应急保障工作进行整体管理与协调。

副组长(外部接口):马能文,就来自各单位相关应急工作进行应急响应及外部协调工作。

副组长(内部接口):邓文轩,就实地应急进行保障与落地。

 

1.5.3业务保障小组

业务安全保障小组由邓文轩牵头政务云运维人员、政务云安全人员组成。负责政务云业务系统和云平台的日常巡检、预警监测、通报处置、安全防护、事件跟踪。

1.5.4 应急响应小组

应急响应小组包含IDC维护团队、云计算支撑团队,IDC维护团队由王航牵头协调机房运维人员、电力维护人员、环控维护人员,云计算支撑由邓文轩协调华为,李阿祥协调飞致云,李鑫协调安恒、天融信等政务云服务相关厂商。

职责如下:

IDC维护团队负责政务云数据中心机房、电力、环控、消防

云计算支撑负责政务云相关厂商应急联动、应急协调、技术支持与保障。

二、政务云平台网络现状

2.1. 政务云网络拓扑

2.2. 软网络系统架构图

2.3.可能性故障点列表

序号

故障类型

故障现象

影响业务

1

网络类

业务系统访问慢

1、本AZ关联虚拟机业务丢包
2、本AZ关联虚拟机丢包严重导致业务系统页面卡顿

2

设备间光模块对接不通

1、本AZ关联物理专线业务中断
2、本AZ关联的设备互联业务中断

3

静态LACP聚合接口转发流量异常

1、本AZ关联POP相关专线业务不通

4

路由震荡故障

1、本AZ关联POD业务丢包
2、本AZ关联POD丢包严重导致业务中断

5

环路导致业务异常

1、vlan的mac表、arp表出接口错误导致业务无法访问
2、大量基于组播的协议报文上送CPU,导致cpu利用率上升,触发cp-car,导致协商失败(如vrrp、arp),严重时甚至影响整个分区业务访问

6

专线网关堆叠TOR故障

1、本AZ的专线中断
2、本AZ的VPN业务中断
3、本AZ托管区访问VPC业务中断

7

vRouter达到性能瓶颈

数据面转发时延增大或者出现丢包

8

计算域类

KVM下Windows虚拟机内部网卡丢失

单台虚拟机网络不通

9

租户误删ECS实例

客户侧的原因导致的虚拟机误删,只影响此虚拟机上运行的业务

10

组合API数据库集群脑裂

弹性云主机相关管理操作异常

11

硬件类

硬件(硬盘、CPU、内存、电源)更换流程应急预案

常规冗余部件故障告警暂不影响业务,但存在风险隐患,重要组件、部件故障直接导致业务异常

12

存储类

硬件故障导致存储池OSD IO异常

硬件故障导致存储池OSD IO异常

13

存储池爆池

AZ关联存储POD业务写入异常

 

三、
政务云平台应急处置预案

3.1 故障处理预案

3.1.1网络类

网络类故障主要涉及政务云平台相关配置层面错误、变更割接的误操作、机房环境线缆误触碰等引发的故障,可以参考以下定位思路排查:

常见客户报障类型:

应用系统无法登陆:通过telnet 域名或弹性IP对应服务端口测试端口连通,如果连接异常,需要政务云维护团队排查网络层、虚机平台层原因。

服务器间网络故障:使用netstat命令查看端口是否正常监听、通过telnet测试端口是否可以正常连接、检查专线防火墙策略是否放行、主机iptables防火墙和安全组策略是否开放访问。

 

 

3.1.1.1 场景1:业务系统访问慢应急预案

【目的】

通过本应急预案的处理,针对排查现网环境中应用系统反馈访问缓慢网络层面问题,通过梳理网络可能原因,排除网络问题导致的业务访问慢故障风险。

【故障现象】

1、应用系统页面打开缓慢、卡顿

2、ping系统地址出现丢包、延迟现象

【故障影响】

1、本AZ关联虚拟机业务丢包

2、本AZ关联虚拟机丢包严重导致业务系统页面卡顿

【应急恢复时长】

60分钟

【故障处理思路】

1)流量途径设备CPU占用率高

2)中间链路出现了拥塞

3)网络中存在攻击或者MAC漂移

4)存在TCP重传现象

5)设备逐包转发导致乱序,乱序可能导致报文丢弃

6)设备被加入黑名单

【故障定位】按照故障处理思路分析排查后,排查网络层面启动应急方案恢复业务

【故障恢复】

1. 查看流量途径设备CPU占用率是否过高。

display cpu [ slot slot-id ]命令查询结果中整机CPU占用率“System CPU Using Percentage”偏高(例如超过70%),或者产生告警SYSTEM_1.3.6.1.4.1.2011.5.25.129.2.4.1 hwCPUUtilizationRisingAlarm,表示当前整机CPU占用率过高。在网络运行中CPU占用率高常常会导致业务访问慢。如果检查结果CPU占用率不高,请执行步骤2。

2. 检查中间链路有无拥塞。

诊断视图下,执行命令display qos buffer overrun history interface interface-type interface-number slot slot-id,查看接口流量超出缓存百分比门限的历史记录。(CE9800/8800/7800/6800/5800不支持slot参数。)

<HUAWEI> system-view

[~HUAWEI] diagnose

[~HUAWEI-diagnose] display qos buffer overrun history interface 10ge 1/0/1

-------------------------------------------------------------------

QueueId         BufferUsage(Cell/KBytes)          Overrun Time

-------------------------------------------------------------------

      0                3834/778                 2020-08-30 18:31:06

      0                3834/778                 2020-08-30 18:33:06

      0                3834/778                 2020-08-30 18:35:06

      0                3834/778                 2020-08-30 18:37:06

      0                3834/778                 2020-08-30 18:39:06

      1                3738/759                 2020-08-30 18:31:06

      1                3807/773                 2020-08-30 18:33:06

      1                3795/770                 2020-08-30 18:35:06

      1                3675/746                 2020-08-30 18:37:06

      1                3665/744                 2020-08-30 18:39:06

-------------------------------------------------------------------

如果没有回显,说明接口没有发生拥塞;当出现上述回显时,表明接口已达到限速值,并且发生了拥塞,其中QueueId记录的是发生拥塞的队列ID,BufferUsage(Cell/KBytes)记录的是检测到拥塞时队列已使用的缓存大小。

如果出现拥塞,检查是否配置了接口限速。操作步骤如下所示:

查看入方向的接口限速相关配置

<HUAWEI> display current-configuration | section include qos car inbound

#                                                                               

qos car test cir 1 gbps                                                          

#                                                                               

interface 10GE1/0/3                                                             

 qos car inbound test       

上述回显表示,在接口10GE1/0/3下配置了接口入方向限速,限速值为1Gbps。

查看出方向的接口限速相关配置

<HUAWEI> display current-configuration | section include lr

#                                                                               

interface 10GE1/0/10                                                            

 qos lr cir 5000 kbps outbound                                                  

 qos car inbound 222            

上述回显表示,在接口10GE1/0/10下配置了接口出方向限速,限速值为5000kbps。

如果配置了接口限速,则取消限速配置或者放大限速值。如果拥塞解除,业务访问正常,则问题已解决;否则执行步骤3。

如果没有配置接口限速,则需要考虑网络优化或者扩容,如果优化或扩容后拥塞解除,则问题已解决;否则执行步骤3。

对于CE12800&12800E&16800,还需要联系技术支持人员来检查接口板和网板之间的链路带宽是否足够,如果不够,需要增加网板;否则执行步骤3。

检查是否存在攻击或者MAC漂移。

3. 分别执行以下操作:

a. 系统视图下执行命令display current-configuration | section include auto-defend,查看攻击溯源功能是否开启,缺省情况下,未开启攻击溯源功能。如果显示有auto-defend enable的配置,表示当前开启了攻击溯源功能;反之表示没有开启该功能。

如果没有开启,则先按照如下操作使能攻击溯源功能,等待一段时间后,再查看攻击源信息。

<HUAWEI> system-view

[~HUAWEI] cpu-defend policy test

[*HUAWEI-cpu-defend-policy-test] auto-defend enable

[*HUAWEI-cpu-defend-policy-test] commit

如果已开启,则在任意视图下执行命令display auto-defend attack-source,查看攻击源信息。

<HUAWEI> display auto-defend attack-source

  Attack Source User Table on Slot 4 :                            

  -------------------------------------------------------------------------                                                         

  MAC Address      Interface       PacketType    VLAN:Outer/Inner      Total                                                               

  -------------------------------------------------------------------------                                                         

  0000-c102-0102   10GE4/0/8       ICMP          1000/                 4832                

  -------------------------------------------------------------------------                                                         

  Total: 1                         

  Attack Source IP Table on Slot 4 :                                      

  -------------------------------------------------------------------------                                                         

  IP Address      PacketType    Total                                                               

  -------------------------------------------------------------------------                                                         

  10.1.1.2        ICMP          1144                                                                

  -------------------------------------------------------------------------                                                         

  Total: 1                         

b. 从上述回显可以看出,网络中存在IP地址为10.1.1.2的攻击源,且其发出的1144个ICMP报文被丢弃。

如果存在攻击源,请查找攻击源并解决攻击。如果解决攻击后,业务访问正常,则故障解决。

如果不存在攻击源,或者解决攻击后问题仍存在,请执行步骤b。

c. 在任意视图下,执行命令display mac-address flapping [ slot slot-id ] [ begin YYYY/MM/DD HH:MM:SS ],查看是否有MAC漂移。

V200R003C00之前版本显示如下:

<HUAWEI> display mac-address flapping

……

-------------------------------------------------------------------------------

S  : start time    E  : end time    (D) : error down

-------------------------------------------------------------------------------

Time                  VLAN MAC Address    Original-Port  Move-Ports     MoveNum

                      /BD                                                      

-------------------------------------------------------------------------------

S:2020-12-11 11:00:08 3    0000-08cc-2206 10GE1/0/1      10GE1/0/2      120  

E:2020-12-11 11:33:13 /-

 

 

-------------------------------------------------------------------------------

Total items on slot 1: 1

V200R003C00及之后版本显示如下:

<HUAWEI> display mac-address flapping

……

-------------------------------------------------------------------------------

S  : start time    E  : end time    (D) : error down

-------------------------------------------------------------------------------

Time         : S:2020-08-24 14:40:11           E:2020-08-24 14:40:23      

VLAN/BD      : 3/-          

MAC Address  : 0000-08cc-2206              

Original-Port: 10GE1/0/1         

Move-Ports   : 10GE1/0/2     

MoveNum      : 120

-------------------------------------------------------------------------------

Total items on slot 1: 1

当有如上回显时,表示存在MAC漂移。

如果存在MAC漂移,请查找MAC漂移的根源并解决。如果解决后,业务访问正常,则故障解决。

如果没有MAC漂移,或者解决MAC漂移后问题仍存在,请执行步骤4。

3. 检查设备是否被列入黑名单。如果用户误操作导致设备在黑名单里,那么发出的报文会被丢弃,从而导致业务访问异常。

在任意视图下,通过执行命令display cpu-defend blacklist statistics [ slot slot-id ],查看基于黑名单上送CPU报文的统计信息。(对于CE12800&12800E&16800,V100R005C10及以后版本的设备执行此方法;CE9800/8800/7800/6800/5800设备不支持此命令。)

<HUAWEI> display cpu-defend blacklist statistics slot 3

-------------------------------------------------------------------------------

CPU defend policy b blacklist 1

Slot 3

-------------------------------------------------------------------------------

rule 5 deny ip source 10.1.1.2 0

 Droped Packets                    67, Droped Bytes                       6834

-------------------------------------------------------------------------------

从上述回显可以看出,源IP地址为10.1.1.2的设备为黑名单成员,其发出的67个报文被丢弃。可以执行以下操作,取消黑名单配置:

<HUAWEI> system-view

[~HUAWEI] display current-configuration | section include blacklist     //查看CPU防攻击策略b配置的黑名单对应的ACL规则

#

cpu-defend policy b

 blacklist 1 acl 2001

 auto-defend enable

 auto-defend trace-type source-mac source-ip

 auto-defend protocol all

[~HUAWEI] display acl 2001                              //查看ACL规则下配置的rule操作

Basic ACL 2001, 1 rule

ACL's step is 5

 rule 5 deny source 10.1.1.2 0 (67 times matched)

[~HUAWEI] acl 2001                           //进入ACL视图,取消对源IP地址的deny操作

[~HUAWEI-acl4-basic-2001] undo rule deny source 10.1.1.1 0

[*HUAWEI-acl4-basic-2001] commit

如果取消黑名单配置后,业务访问正常,则故障解决。

如果问题仍存在,请执行步骤5。

4. 使用端口镜像功能进行报文捕获并检查有无TCP重传。

系统视图下,执行命令observe-port [ observe-port-index ] interface interface-type interface-number,配置本地观察端口。

接口视图下,执行命令port-mirroring observe-port observe-port-index { both | inbound | outbound },配置需要观察流量的接口镜像到本地观察端口,对本地观察端口捕获的报文进行分析,判断有无TCP重传。

捕获报文后,分析业务报文的sequence number字段有无重复,如果有重复,表示有TCP重传;反之没有重传。

如果出现TCP重传,则检查是否是由本设备导致的TCP重传。通常TCP重传是由于丢包或者时延较大导致:

是否丢包,时延过大,可以通过分析中间链路有无拥塞来确认,具体操作请执行步骤6。

如果没有TCP重传,请执行步骤6。

 通过镜像报文捕获,检查是否存在乱序。(镜像端口的配置如步骤4所述。)

乱序一般是由于Eth-Trunk中采用逐包负载分担HASH算法导致的,建议采用逐流HASH算法。乱序的判别方法是:捕获报文后,分析业务报文的时间戳和sequence number字段,到达时间早的报文sequence number数值小,如果不是这样的情况,说明有乱序。

如果有乱序,请先根据上述判断方法确认设备是否使用逐包HASH的负载分担方式。判断方法如下所示:

<HUAWEI> display current-configuration | include hash

 eth-trunk hash-mode 4      

hash-mode为4,代表当前Eth-Trunk负载分担方式为逐包,非4的值为逐流负载分担方式。

如果使用逐包负载分担方式,请将该方式修改为逐流负载分担。

如果使用逐流负载分担方式,则按照此方法向上游设备排查。

如果设备乱序问题消失,则问题已解决;否则请执行步骤7。

如果没有出现乱序,请执行步骤7。

 联系技术支持人员并收集如下命令显示的相关诊断信息。

对于V100R003C00和V100R003C10版本:在诊断视图下,执行命令display configuration diagnostic-information 9 process 3display configuration diagnostic-information 9 process 6

对于V100R005C00及以后版本:在诊断视图下,执行命令display configuration diagnostic-information luascript iffy process 3display configuration diagnostic-information luascript iffy process 6

 

3.1.1.2 场景2:设备间光模块对接不通应急预案

【目的】

通过本应急预案的处理,解决针对现网环境中光纤链路两端的模块故障突发引发的业务问题。通过梳理可能导致的原因,使业务紧急规避故障风险。

【故障现象】

1、链路正常运行突发性中断

2、设备日志告警显示链路中断,一直未恢复

【故障影响】

1、本AZ关联物理专线业务中断

2、本AZ关联的设备互联业务中断

【应急恢复时长】

30分钟

【故障处理思路】

1)使用的光模块不是经过华为数据中心交换机认证的光模块。

2)光模块和光纤不匹配。

3)端口被shutdown。

4)发送光功率过低或者过高。

5)接收光功率过低或者过高。

6)两端对接的光模块不匹配。

【故障定位】技术分析排查后,确认模块问题需启动应急方案恢复业务

【故障恢复】

1. 确认该光模块是否是经过华为数据中心交换机认证的,CE系列交换机需使用华为数据中心交换机认证的光模块,非认证光模块可靠性无法保证,可能导致端口无法UP。

2. 检查光模块和光纤是否匹配。

单模光模块(一般波长为1310nm、1550nm)对应单模光纤(一般是黄色)。

多模光模块(一般波长为850nm)对应多模光纤(一般是橙色)。

3. 执行命令display interface transceiver查看“Alarm information”下光模块是否有告警信息。

<HUAWEI> display interface 10ge 1/0/1 transceiver

 

 10GE1/0/1 transceiver information:

-------------------------------------------------------------------

 Common information:

   Transceiver Type                      :10GBASE_SR

   Connector Type                        :LC

   Wavelength (nm)                       :850

   Transfer Distance (m)                 :30(62.5um/125um OM1)

                                          80(50um/125um OM2)

                                          300(50um/125um OM3)

                                          400(50um/125um OM4)

   Digital Diagnostic Monitoring         :YES

   Vendor Name                           :HUAWEI

   Vendor Part Number                    :02318169

   Ordering Name                         :

-------------------------------------------------------------------

 Manufacture information:

   Manu. Serial Number                   :AQG269Y

   Manufacturing Date                    :2020-10-20

   Vendor Name                          

-------------------------------------------------------------------

如果出现LOS Alarm告警,则说明对端没有信号发送过来,在接口模式下执行命令display this查看两端端口是否shutdown,如果端口shutdown了,则执行undo shutdown操作。

4. 执行命令display interface transceiver verbose查看光模块的诊断信息,查看光模块是否有发送或接收光功率方面的告警信息。

<HUAWEI> display interface 10ge 1/0/1 transceiver verbose

 

 10GE1/0/1 transceiver information:

-------------------------------------------------------------------

 Common information:

   Transceiver Type                      :10GBASE_SR

   Connector Type                        :LC

   Wavelength (nm)                       :850

   Transfer Distance (m)                 :30(62.5um/125um OM1)

                                          80(50um/125um OM2)

                                          300(50um/125um OM3)

                                          400(50um/125um OM4)

   Digital Diagnostic Monitoring         :YES

   Vendor Name                           :HUAWEI

   Vendor Part Number                    :02318169

   Ordering Name                         :

-------------------------------------------------------------------

 Manufacture information:

   Manu. Serial Number                   :AQG269Y

   Manufacturing Date                    :2020-10-20

   Vendor Name                           :HUAWEI

-------------------------------------------------------------------

 Alarm information:

-------------------------------------------------------------------

 Diagnostic information:

   Temperature (Celsius)                 :33.68

   Voltage (V)                           :3.29

   Bias Current (mA)                     :7.97

   Bias High Threshold (mA)              :13.20

   Bias Low Threshold (mA)               :4.00

   Current RX Power (dBm)                :-2.15

   Default RX Power High Threshold (dBm) :1.00

   Default RX Power Low Threshold (dBm)  :-11.90

   Current TX Power (dBm)                :-2.07

   Default TX Power High Threshold (dBm) :1.00

   Default TX Power Low Threshold (dBm)  :-9.30

-------------------------------------------------------------------

光模块的诊断信息中,可以查看当前发送和接收的光功率值,以及默认的最高和最低功率值。

如果接收功率低(RxPower Low),说明本端接收到的信号过低,则可能出现端口不UP或者UP后报文收发有丢弃,此时请先排查传输距离是否过远,超出了该光模块的传输距离,再排查光模、光纤是否有损坏。

如果接收功率高(RxPower High),说明本端接收到的信号过高,可能原因是该光模块为长距光模块,而实际传输距离太短,导致信号未衰减,此时应在光模块上增加光衰,以对光模块进行保护。

如果发送功率低(TxPower Low),说明该光模块发送信号不好或光模块本身故障,可能会导致对端接收功率低,而造成端口不UP或者UP后报文收发有丢弃,请与技术支持人员联系。

如果发送功率高(TxPower High),说明该光模块发送信号太强,可能会导致对端接收功率高,而造成对端光模块因接收功率持续过高而烧坏,可能原因是本端光模块故障,建议更换光模块。

因此,在端口插入光模块并对接成功后,要对发送或接收光功率方面的告警信息进行排查,避免因功率过低或者过高造成流量或者光模块不正常。

5. 如果两端均没有任何告警,而端口又不UP,请先截取光模块的详细信息和日志,然后尝试更换别的光纤或光模块,看是否能UP,如果能UP,则说明原来的光纤或光模块本身有问题,请更换新的光纤或光模块,如果还是不能UP,请与华为技术支持人员联系。

【恢复确认】

检查业务连续性是否恢复,设备状态和协议运行恢复则故障恢复,命令:

display interface transceiver verbose

3.1.1.3 场景3:静态LACP聚合接口转发流量异常应急预案

【目的】

通过本应急预案的处理,解决针对互联网区和外网区专线接入聚合口对接lacp模式下故障引发无法转发流量。

【故障现象】

1、聚合对接的三层互联地址Ping不通

2、物理专线业务不通

【故障影响】

1、本AZ关联POP相关专线业务不通

【应急恢复时长】

30分钟

【故障处理思路】

 

 

【故障定位】

常见定位围绕以下步骤排查:

1)Eth-Trunk接口被阻塞。

2)Eth-Trunk成员接口没有Up。

3)Eth-Trunk接口的配置错误。

4)Eth-Trunk成员接口不能正常收发LACP报文。

5)底层转发异常。

【故障恢复】

1. 查看Eth-Trunk接口的STP状态是否为block。

端口状态正常是流量转发的前提。在任意视图下执行display stp brief命令查看Eth-Trunk的STP State字段,确认Eth-Trunk接口是否为block状态。

<HUAWEI> display stp brief

 MSTID  Port                        Role  STP State     Protection  Cost       Edged

     0  10GE1/0/1                   ROOT  forwarding    none        2000       disable

     0  Eth-Trunk10                 ALTE  discarding    none        2000       disable

     0  10GE1/0/3                   DESI  forwarding    none        2000       disable

如果显示为discarding则为block状态,此时数据报文无法转发,请排查网络中的环路。

如果Eth-Trunk接口的STP状态不是block状态,请执行步骤2。

2. 查看Eth-Trunk成员接口的物理状态是否为Up。

成员接口处于UP状态时才能被Eth-Trunk选中。在任意视图下执行display interface interface-type interface-number命令查看Eth-Trunk成员接口的物理状态,其中current state表示接口的物理状态。

<HUAWEI> display interface 10ge 1/0/1

10GE1/0/1 current state : UP (ifindex: 4)

Line protocol current state : UP

                                         

如果显示为UP则表示接口处于正常启动的状态,请执行步骤3。

如果显示不是UP,请检查Eth-Trunk成员接口的物理链路、光模块情况。

3. 检查Eth-Trunk接口的配置是否正确。

在任意视图下执行display eth-trunk trunk-id命令检查活动接口数上/下限阈值是否合理。其中Max Active-linknumber表示活动接口数上限阈值,Least Active-linknumber表示活动接口数下限阈值。

<HUAWEI> display eth-trunk 10

Eth-Trunk10's state information is:

Local:

LAG ID: 10                      Working Mode: Static

Preempt Delay Time: 10          Hash Arithmetic: profile default

System Priority: 120            System ID: 0025-9e95-7c31

Least Active-linknumber: 1      Max Active-linknumber: 2

Operating Status: up            Number Of Up Ports In Trunk: 2

Timeout Period: Slow

-------------------------------------------------------------------------------

如果配置的活动接口数上限阈值少于期望转发流量的接口,请在Eth-Trunk接口视图下执行lacp max active-linknumber命令修改配置。如果Eth-Trunk接口下Up的成员接口数目少于配置的活动接口数下限阈值,请在Eth-Trunk接口视图下执行least active-linknumber命令修改配置。

如果Eth-Trunk接口的配置正确,请执行步骤4。

4. 检查Eth-Trunk成员接口是否能够正常收发LACP报文。

· 查看LACP协议报文的收发计数。

在用户视图下执行reset lacp statistics eth-trunk trunk-id命令清除原始LACP报文计数。

清除LACP的统计信息后,以前的统计信息将无法恢复。

在任意视图下执行display lacp statistics eth-trunk trunk-id命令查看LACP报文收发情况。

<HUAWEI> display lacp statistics eth-trunk 10

 Eth-Trunk10's PDU statistic is:                                  

 -----------------------------------------------------------------

 Port         LacpRevPdu  LacpSentPdu  MarkerRevPdu  MarkerSentPdu

 10GE1/1/0/10    0            13          0             0         

 10GE1/1/0/12    13           13          0             0    

这里查看的是LACP组件的报文处理情况,正常情况下,接收计数LacpRevPdu和发送计数LacpSentPdu都有计数。

如果没有发送报文计数,则可能是LACP组件出了问题。

如果没有收到报文计数,则需要排查是否收到对端的报文。

· 查看LACP组件是否正常。

[~HUAWEI-diagnose] display system component running-state | include LACP

-----------------------------------------------------------------------------------------------------------------------

NAME                                    CID        PID       Type Version          Board       Process State           

-----------------------------------------------------------------------------------------------------------------------

LACP                             0x80480569   0x4804AC       0x48 2.0.2            1/1         1012    PRIMARY         

若状态State为NULL则表示LACP组件有问题,请联系技术支持人员处理。

· 查看ACL规则是否存在且正确。

在任意视图下执行display cpu-defend statistics命令查看ACL命中计数。

<HUAWEI> display cpu-defend statistics slot 1 | include lacp

Statistics(packets) on slot 1 :                                                 

--------------------------------------------------------------------------------

PacketType               Total Passed        Total Dropped   Last Dropping Time

                    Last 5 Min Passed   Last 5 Min Dropped                      

--------------------------------------------------------------------------------

lacp                                0                    0   -                  

--------------------------------------------------------------------------------

正常情况下,lacp一行中的Total PassedLast 5 Min Passed列中存在计数,间隔报文发送的一个周期计数会增加。如果不存在计数,或存在计数但不增加,则需进一步排查LACP的ACL规则是否存在。

在诊断视图下执行display system tcam service命令获取LACP的ACL规则的EntryID。

LACP规则为全局下发,每个芯片下发一次。

对于CE12800&12800E&16800系列交换机:

[~HUAWEI-diagnose] display system tcam service cpcar slot 1/1 | include lacp

Total: 98                                   

--------------------------------------------

PacketType                            Entry

--------------------------------------------

LACP                                  26    

--------------------------------------------

对于CE9800&8800&7800&6800&5800系列交换机:

[~HUAWEI-diagnose] display system tcam service cpcar slot 1/1 | include lacp

Total: 98                                                        

-----------------------------------------------------------------

PacketType                                 HitPackets      Entry

-----------------------------------------------------------------

LACP                                       2354            26    

-----------------------------------------------------------------

在诊断视图下执行fediag命令查看ACL规则是否正确。

[~HUAWEI-diagnose] fediag slot 1 chip 0 "get acl entry info 26"

Entry 26

Flags       = 00000007

+USED +IN_HW +WANT_HW -upd -chg -new -sta

Group       =        2

Priority    = 2063592367

Prev/Next   =       67 /       68

HW entry ID = 0000001B

HW priority = 05001450

Qualifiers:

DstMac (7) -> da (13)

01:80:C2:00:00:02/FF:FF:FF:FF:FF:FF

00000180C2000002/0000FFFFFFFFFFFF (expected)

00000180C2000002/0000FFFFFFFFFFFF (actual)

EtherType (29) -> ethertype (14)

8809/FFFF

0000000000008809/000000000000FFFF (expected)

0000000000008809/000000000000FFFF (actual)

上述显示信息中,如果DstMAC0180c2000002且EtherType8809,请执行步骤5。如果不是,请执行步骤6。

5. 查看底层转发表项是否正确。

LACP协商建立正常,成员口都为select状态,流量仍然不通则需要查看底层转发表项。

[~HUAWEI-diagnose] display interface Eth-Trunk 10 forwarding-table

 

Eth-Trunk10       The Forwarding Table is NULL.

如果转发表为空或者流量不同的接口不在该转发表中,则说明为Eth-Trunk转发表存在问题,请执行步骤6。

【恢复确认】

检查业务联通性是否恢复,设备状态和协议运行恢复则故障恢复,命令:

display lacp statistics eth-trunk **

3.1.1.4 场景4:路由震荡故障应急预案

【目的】

通过本应急预案的处理,解决针对AZ内部使用动态路由协议学习、传递路由,由于物理端口、软配置等导致的路由震荡产生业务时断时续特定场景引发的故障。通过梳理现网路由条目和路由下发配置信息,使得业务规避紧急故障风险。

【故障现象】

1、计算POD访问存储POD时断时续

2、设备性能耗尽,网络延迟高

【故障影响】

1、本AZ关联POD业务丢包

2、本AZ关联POD丢包严重导致业务中断

【应急恢复时长】

60分钟

【故障处理思路】

1、梳理计算pod以及存储pod网络分区业务网段

2、根据梳理的路由在相应设备上下发静态路由紧急恢复业务

1)计算pod汇聚CE12800静态路由下发

2)存储pod汇聚CE12800静态路由下发

3)存储pod TOR静态路由下发

【故障定位】业务中断,技术分析排查后,确认存储网络路由震荡需启动应急方案恢复业务

【故障恢复】

梳理网络分区路由以及相应设备上下发静态路由紧急恢复业务。需确认操作的网络设备配置备份和日志下载,并核实在其设备面板的标签,避免发生误设备操作

1、POD业务紧急恢复

1.1、 梳理各网络分区路由条目

方法一:块存储网络路由主要涉及“计算POD网络分区”、“核心网络分区”、“存储POD网络分区”,登陆以上网络分区网关设备,采集相应网络平面的网段信息,

计算pod网关位于CE12800,登陆CE12800输入以下命令

display ip interface brief | include pod-manage

存储pod网关位于TOR,登陆TOR输入以下命令

display ip interface brief | include pod-manage

注:在公有云2.0网络中,块存储属于pod-manage vrf            

方法二:通过查找LLD信息,梳理个网络分区的网段规划根据梳理的路由在相应设备上下发静态路由紧急恢复业务

1.2、计算pod网关静态路由下发

主用/备用网关上下发静态路由,下一跳指向计算pod与存储pod互联接口地址

Ip route-static vpn-instance pod-manage  存储POD块存储IP网段   掩码  下一跳  preference 5

1.3、块存储汇聚CE12800静态路由下发

主用、备用CE12800上下发静态路由

1)指向计算POD存储平面的静态路

 Ip route-static vpn-instance pod-manage  计算pod存储平面IP网段   掩码  下一跳  preference 5

2)指向存储TOR网关的静态路由

Ip route-static vpn-instance pod-manage  存储POD块存储IP网段   掩码  下一跳  preference 5

 每台TOR至少配置一条静态路由

1.4、块存储TOR网关静态路由下发

1)在所有块存储TOR网关的相应vrf上统一下发默认路由

     Ip route-static vpn-instance pod-manage 0.0.0.0 0.0.0.0 下一跳 preference 5

2)上行CE12800的接口停止发送OSPF hello报文

           Ospf 26 vpn-instance pod-manage

                silent-interface Eth-Trunk1

                silent-interface Eth-Trunk2

【恢复确认】

POD业务流量确认,检查业务连续性是否恢复,设备状态和协议运行恢复则故障恢复,命令:

Display ip interface brief | include pod-manage

3.1.1.5 场景5:环路导致业务异常应急预案

【目的】

通过本应急预案的处理,对Region内部使用二层组网(vrrp+stp)分区常见二层环路场景能采取相应措施。规避、修复二层环路引发的广播风暴、mac-flapping、协议报文丢包等典型故障。

【故障现象】

1、网络中形成广播风暴

2、日志告警ARP表项、MAC表项错误、MAC-Flapping现象

3、协议报文大量丢包(VRRP协议报文,ARP协议报文)

【故障影响】

1、vlan的mac表、arp表出接口错误导致业务无法访问

2、大量基于组播的协议报文上送CPU,导致cpu利用率上升,触发cp-car,导致协商失败(如vrrp、arp),严重时甚至影响整个分区业务访问

【应急恢复时长】

60分钟

【故障处理思路】

1)设备本接口自环

2)设备不同接口之间形成环路

3)下游设备环路

4)环形组网

【故障定位】

业务中断,技术分析排查后,确认网络二层环路故障需破除环路。

【故障恢复】

1. 识别环路。

可以通过如下现象和手段识别环路:

端口产生数据报文风暴

<HUAWEI> display interface brief | include up

PHY: Physical

*down: administratively down

^down: standby

(l): loopback

(s): spoofing

(b): BFD down

(e): ETHOAM down

(d): Dampening Suppressed

(p): port alarm down

(dl): DLDP down

InUti/OutUti: input utility rate/output utility rate

Interface                   PHY   Protocol InUti OutUti   inErrors  outErrors

10GE2/0/3                   up    up         70%    70%          0          0

10GE2/0/5                   up    up         70%    70%          0          0

MEth0/0/0                   up    up       0.01%  0.01%          0          0

NULL0                       up    up(s)       0%     0%          0          0

需要将上述查看到的端口流量和正常业务情况下的端口流量做对比,如果端口流量比正常业务大很多,可能出现环路:

如果只有一个端口风暴,可能是上述环路类型的本端自环和下游设备环路场景。

如果是两个端口风暴,则可能是上述环路类型的不同端口之间环路和环形组网的场景。

如果有更多的端口风暴,则可能是上述环路类型的几种情况组合之后的复杂场景。

检测发生MAC地址漂移

通过日志查看接口的MAC漂移记录。

可在日志log.log中或者用display logbuffer命令查看。如下信息表明有MAC地址漂移的记录,则说明在相应的接口可能有环路。

Sep 15 2020 15:23:58

A8_CE12808_1 %%01FEI/4/hwMflpVlanLoopAlarm_active(l):CID=0x807f047e-alarmID=0x095e0012;MAC flapping detected, VlanId = 310, MacAddress = 0016-3e00-0464, Original-Port = Eth-Trunk49, Flapping port = Eth-Trunk33,-. Please check the network to which the interface learning a flapping MAC address is connected.

在任意视图下执行display mac-address flapping命令查询接口的MAC漂移记录。

在回显信息中,MoveNum表示在相应时间段漂移的次数,如果MoveNum数值很大,表明出现了大量的MAC漂移,则极可能为环路导致,需要根据接口重点排查。

协议状态不稳定

环路可能导致某些协议(如OSPF)报文丢失、环回到本设备或者重复多份,可能导致协议不稳定。如果有大量的此类日志记录,则可能出现环路。

Sep 16 2020 10:55:56 A8_CE12808_1 %%01OSPF/6/NBR_CHANGE(l):CID=0x808304c7;Neighbor changes event: neighbor status changed. (ProcessId=1, NbrIpAddr=10.192.0.46, NbrEvent=1-Way, NbrPreviousState=ExStart, NbrCurrentState=Init)

Sep 16 2020 10:55:56 A8_CE12808_1 %%01OSPF/6/NBR_CHANGE(l):CID=0x808204c3;Neighbor changes event: neighbor status changed. (ProcessId=1, NbrIpAddr=10.192.0.46, NbrEvent=2WayReceived, NbrPreviousState=Init, NbrCurrentState=ExStart)

上送CPU的协议报文(如ARP)被抑制丢弃

当环回导致的大量报文上送到CPU的时候,可能会被抑制,可以通过display cpu-defend statistics packet-type arp all命令查询。如果出现大量dropped报文,则可能出现环路。

<HUAWEI> display cpu-defend statistics packet-type arp all

Statistics(packets) on slot 2 :                                                 

--------------------------------------------------------------------------------

PacketType               Total Passed        Total Dropped   Last Dropping Time

                    Last 5 Min Passed   Last 5 Min Dropped                      

--------------------------------------------------------------------------------

arp                             34515             14346678   -                  

                                34515                 1678                      

--------------------------------------------------------------------------------

使用Loopback Detection功能检测到环路

在相应的端口和VLAN使能Loopback Detection功能,设备会周期性的发送检测报文,当从本端口又收到此报文时,则说明发生了环路。可以根据现网情况配置某端口和VLAN的环回检测功能,通过display loopback-detect命令查看环路情况。

2. 解决环路。

当出现环路时,会极大影响网络性能,甚至导致业务异常,需要及时处理。解决环路问题可以从如下几点着手:

可能是组网连线导致物理上成环,需要现场工程师排查组网,去除多余的网线或光纤。现网定位时,可以通过shutdown接口来达到链路断开的目的。

现网shutdown接口时,需要特别谨慎,以免中断业务。

在现网定位的时候,一般很难在物理上做操作,所以绝大多数情况下,需要在配置上解决环路。比如:shutdown端口或端口退出成环的VLAN。

另外,可能是由于其他特性导致成环,比如STP、Smartlink等环网协议异常,导致无法正确破环,则需要定位相应特性的问题。请执行3

3. 请收集如下信息,并联系技术支持人员。

上述步骤的执行结果。

设备的配置文件、日志信息、告警信息。

【恢复确认】

      关联设备检查接口流量是否恢复正常,设备无异常告警日志且业务正常则故障恢复,命令:

display interface brief | include up 

3.1.1.6 场景6:专线网关堆叠TOR故障应急预案

【目的】

通过本应急预案的处理,修复专线网关监控中断,设备无法登陆的场景。修复后使得堆叠TOR恢复正常或者消除堆叠TOR的故障风险。

【故障现象】

1、专线网关监控中断

2、设备无法登陆

【故障影响】

1、本AZ的专线中断

2、本AZ的VPN业务中断

3、本AZ托管区访问VPC业务中断

【应急恢复时长】

60分钟

【故障处理思路】

1、专线业务切换

2、托管区业务切换

3、堆叠设备故障恢复

  1)故障设备隔离

  2)远程堆叠主备切换、主用成员框下电

  3)现场重启

  4)现场设备替换

【故障定位】业务中断,联系华为技术支持后,确认网络设备故障需要更换主设备

【故障恢复】

前提条件与待更换部件同型号规格的备件。已确认待更换的网络设备所在物理位置,并在其面板上粘贴更换标签,避免发生误操作

1、专线业务紧急恢复

1.1、EIP/ELB流量切换至备用AZ(EIP/ELB长连接会中断,重连即可恢复)

登录EIP防火墙,修改ECMP路由,将引向本AZ的软nat的路由删除,使从北往南方向的(ELB/EIP)流量引流至备用AZ的软nat集群,如

Undo ip routing-table EIP-prefix x.x.x.x

1.2、专线业务切换至备用AZ(手动切换)

停止发布本AZ的vrouter集群相关路由,使从南往北方向的ELB回程流量引流至备用AZ的vrouter集群,

1)登陆网络服务区汇聚,将vrouter所在网段vlanif接口shutdown,如

Interface vlanif 55

Shutdown

2)登陆核心交换,检查路由是否按预期切换至备用AZ

Display ip routing-table vpn tenant x.x.x.x

路由下一跳出接口为AZ互联接口

2、隔离故障设备,堆叠故障恢复

完成以上业务切换后,关闭专线网关相应接口,将故障设备隔离,并开始执行以下操作,若可以远程登录设备,则优先执行步骤1、步骤2,如无法登录设备则从步骤3开始执行

步骤1.远程堆叠主备切换;

     登录设备,进入系统视图,执行主备切换命令:

Quidway> System-view

Quidway# slave switch-over

若切换失败或切换后业务任然无法恢复业务则执行步骤2

步骤2.远程主用成员框下电;

登录设备,进入系统视图,执行主备切换命令:

Quidway> System-view

Quidway# display stack //查看主用成员的槽位号

Quidway# power off slot xx //将主用成员交换机下电

     若下电失败或下电后任然无法恢复业务则执行步骤3

步骤3.现场重启

      堆叠TOR下电,使堆叠系统重启,重启完成后检查是否恢复正常

Display ospf peer brief //检查ospf状态是否为full

Display ospf routing    //检查ospf路由学习情况

Display bgp vpnv4 all peer // 检查bgp状态是否为Established

Display bgp vpnv4 vpn-instance vpn-name routing-table //检查bgp路由学习情况

Display interface brief | in UP //检查接口流量是否恢复    

      如果现场重启无法恢复故障,则需执行步骤4

步骤4.设备替换、新设备入网

新设备按照原设备连接方式接入现网后,设备常规检查;

        Display logbuffer //检查是否有异常日志

        Display alarm all //检查是否有告警

        Display stack  //检查堆叠状态是否正常

        Display current-configuration //检查配置是否正确

 Vrouter修改网关MAC地址(设备替换场景);

              虚拟网络方面,Vrouter必须修改下一跳专线网关MAC地址为新替换设备的MAC地址,否则专线无法恢复;

              专线业务回切至主用AZ;

              EIP、ELB流量回切至主用AZ(ELB长连接会中断,重连即可恢复);

开启专线网关与网络服务区汇聚接口

Display ospf peer brief //检查ospf状态是否为FULL

      Display ospf routing    //检查ospf路由学习情况

      Display bgp vpnv4 all peer // 检查bgp状态是否为Established

      Display bgp vpnv4 vpn-instance vpn-name routing-table //检查bgp路由学习情况

网络服务区上恢复Vrouter所在vlanif接口

Interface vlanif xx

Undo shutdown

Vlanif开启后,登陆本AZ核心交换检查,确保路由从本AZ的网络服务区汇聚发出

开启专线网络与客户专线连接接口

【恢复确认】

专线与VPN流量确认

检查接口流量是否恢复,接口流量恢复则故障恢复,命令:

Display interface brief | in UP

3.1.1.7 场景7:vRouter达到性能瓶颈应急预案

【目的】

通过本应急预案的处理,快速恢复虚拟网络重大故障。

【故障现象】

首先,承载vRouter数据转发的网口有两种类型:

1)承载专线、VPN、NATGW、VPC-peering、CC(云连接)、VPC EP、EIP访问VIP到计算节点、内网ELB等流量的业务网口;

2)承载公网ELB、EIP访问VIP进入到vrouter节点流量的LB口。当存在某个租户的大象流或者大带宽流量转发到vRouter网关节点上;

当存在某个租户大象流或者大带宽流量转发到vRouter网关时,必然会影响到其他租户的业务的时延或者丢包。

【故障影响】

数据面转发时延增大或者出现丢包。

【应急恢复时长】

60分钟

【故障处理思路】

找出大象流来源或者大带宽来源,即TopN虚拟机或者租户,并针对虚拟机进行限速(pps/bps):

1.根据网关类型和网关节点IP地址自定义限速工具上查询TopN-VM。

2.ServiceCM Topn流量监测查询网关TopN。

3.CloudMNet网络服务监控根据时间点寻找增量TopN虚拟机。

找出大象流来源或者大带宽来源,即TopN虚拟机或者租户,并针对虚拟机进行限速(pps/bps)

1、下面介绍常规的几种TopN寻找的方法。

方法一:网络诊断 --- 自定义限速 --- TopN-VM限速

根据告警中网关类型和网关external_om平面IP地址查询TopN

方法二:网络运维工具---运维信息查询---Top流量监测

根据告警网关类型和POD查询TopN

方法三:网络服务监控---ECS服务监控---CNA节点概况或者计算实例概况查看对应时间点增加的计算节点或者ECS

 

2、基于前面找到的虚拟机进行限速,可以限制pps/bps限速,其中BPS单位为Mbps,PPS单位为pps。若识别大带宽数据来源为云专线或者云连接,可以联系对应负责同事进行单实例限速。

 

3.1.2计算域类

3.1.2.1 场景8:KVM下Windows虚机内部网卡丢失应急预案

【目的】

通过本应急预案的处理,解决在政务云环境下,KVM平台下windows虚拟机内部看不到网卡。

【故障现象】

步骤 1 Windows虚拟机网络不通,执行ifconfig看不到网卡

步骤 2 打开windows虚拟机的计算机管理,没有网络适配器

【故障影响】

单台虚拟机网络不通。

【应急恢复时长】

5分钟

【故障处理思路】

1、管理面确认是否网卡丢失,nova、neutron都需要确认。

2、虚拟化层面确认网卡是否丢失。

【故障定位】

1)分析虚机的网卡在nova管理面是否存在。被级联层执行nova interface-list {vm_id}

port信息代表网卡在管理面没有丢失

2)故障虚机的网卡在虚拟化层面是否存在

virsh dumpxml {instance_id} 查看是否有tap 信息或者“mac address”信息

3)确保网卡信息在nova数据库表INSTANCE_INFO_CACHES中

select NETWORK_INFO from INSTANCE_INFO_CACHES where INSTANCE_UUID='{vm_id}'; 查看虚机对应的NETWORK_INFO在数据库中存在

4)至此确认通过关机再开机可以恢复

 

【故障恢复】

场景一:被级联层表INSTANCE_INFO_CACHES中有网卡信息

l 操作场景

nova interface-list 能看到网卡,表INSTANCE_INFO_CACHES中有网卡信息代表管理面并没有丢失网卡,只需要虚拟机关机,再开机即可,这样会重新生成xml(虚机的bios信息)

l 前提条件

INSTANCE_INFO_CACHES中有网卡信息。

l 操作步骤

联系客户,对虚机进行关机再开机即可。

场景二:被级联层表INSTANCE_INFO_CACHES中无网卡信息,级联层此表有网卡信息

l 操作场景

nova interface-list 能看到网卡,级联层INSTANCE_INFO_CACHES 表中有网卡信息,但是被级联层表INSTANCE_INFO_CACHES中无网卡信息,此时代表被级联层管理面虚机对应的网卡信息已经丢失,需要从级联层恢复。

l 前提条件

级联层网卡信息没丢失,被级联层网卡信息丢失。

l 操作步骤

运维同事对虚机进行跨POD-HA即可。

【恢复确认】

步骤1 检查恢复结果,在计算节点查看虚机的xml,确保文件中有tap和mac信息。

步骤2 OS内部查看是否有网卡。

3.1.2.2 场景9:租户误删ECS实例应急预案

【目的】

通过本应急预案的处理,解决在公有云环境下,租户勿删ECS实例求助华为协助恢复场景下的应急指导。

【故障现象】

客户虚拟机被删除,请求恢复。

【故障影响】

客户侧原因导致的虚拟机误删,只影响此虚拟机上运行的业务。

【应急恢复时长】

60分钟

【故障处理思路】

恢复虚拟机挂载的数据卷,重新创虚拟机挂载原来的卷

【故障定位】不涉及

【故障恢复】

l 操作场景

不涉及。

l 前提条件

虚拟机删除72h以内。

l 操作步骤

1)获取虚拟机id。如果客户只能提供租户id,根据如下命令查询该租户删除的虚拟机,根据时间或虚拟机名称可以过滤出需要恢复的虚拟机id、flavor信息。

nova list --all-t --tenant ${project_id} --fields updated,status,created,name,task_state,flavor:original_name --deleted

2)根据虚拟机id登录级连层nova数据库备库查询删除的虚拟机对应的系统卷和数据卷id。

cps template-instance-list --service gaussdb_nova gaussdb_nova  //选择standby节点登录

select * from BLOCK_DEVICE_MAPPING where INSTANCE_UUID='xxx';

如下可以查到系统盘/dev/sda/对应的卷id;同样的方法也可以查到数据卷id。

3)将虚拟机对应的系统卷id及数据卷id提供给存储侧,由存储sre对卷进行恢复。删除72h以上的卷无法进行恢复。

4)存储完成数据恢复后,联系客户创建一个同样flavor的虚拟机,然后关机、卸载系统卷、修改私有ip地址为原有地址,最后将恢复的系统卷及数据卷再次挂载到新虚拟机上。若配置了弹性ip,还需要将弹性ip重新绑定到新虚拟机。

【恢复确认】

步骤 1 检查新创虚拟机vnc登录正常,且已挂载的系统卷id和数据卷id是否和数据库中删除的一致。


3.1.2.3 场景10:组合API数据库集群脑裂应急预案

【目的】

通过本应急预案的处理,解决在政务云环境下,API COM DB master节点CPU冲高至100%,备节点与主节点通信中断,备升主,但主未完全宕机,导致集群出现脑裂,客户端连接异常。

【故障现象】

1)客户报障,Console页面无法正常进行开关机。

2)组合API定位,连接数据库失败。

1. 连通性监控指标:ECS.apicom_check_connectivity.apicom_connectivity.connectivity(curl)

0为正常,1为异常(无法连接到主机或连接超时)

2. 数据库连接数监控指标:ECS.apicom_connections2db/apicom_connections2db

【故障影响】

弹性云主机相关管理操作异常。

【应急恢复时长】

15分钟

【故障处理思路】

1. 定界定位,快速发现周边依赖DB异常

2. DB定位,本案例为DB master节点CPU利用率飙高,导致主备通信中断,主备切换,主未宕机产生的脑裂

3. DB处理脑裂:强制重启卡死的master节点

4. 业务侧重启APICOM(怀疑是请求积压,导致数据库连接仍然打满,老的队列请求与新到请求均无法处理,此时需要重新释放数据库连接)

【故障定位】云服务侧:定界定位,快速发现公共组件DB异常,快速拉DB同事处理(DB也应主动处理?)。

1.组合API日志分析问题原因

cat /opt/cloud/logs/taskmgr/taskmgr.log | grep -Pi 'error'

2.数据库连接数监控指标:ECS.apicom_connections2db/apicom_connections2db

组合API到CloudDB连接数监控,用以显示CloudDB的压力,初步定界问题部件

3.数据库资源用量(本例问题为数据库master节点CPU飙高至100%)

4.DB侧定位。

【故障恢复】

场景一:DB集群脑裂

l 操作场景

DB master节点CPU冲高至100%,备节点与主节点通信中断,备升主,但主未完全宕机。

l 前提条件

DB集群双主,脑裂。

l 操作步骤

1)DB处理脑裂:强制重启卡死的master节点。

DB方:在FC强制下电已卡死的DB虚拟机

2)业务侧重启APICOM(若DB重启master节点5分钟后,业务仍未恢复)

请求积压,导致数据库连接仍然打满,老的队列请求与新到请求均无法处理,此时需要释放数据库连接,重新建连

3.1.4硬件类

3.1.3.4 场景11:硬件(硬盘、CPU、内存、电源)更换流程应急预案

【目的】

通过本应急预案的处理,解决在机房服务器硬件出现告警或者故障时按照应急预案流程采取相应的申请备件和替换操作,让业务规避风险。

【故障现象】

告警平台出现设备硬件告警信息。

【故障影响】

常规冗余部件故障告警暂不影响业务,但存在风险隐患,重要组件、部件故障直接导致业务异常。

【应急恢复时长】

30分钟

【故障处理思路】

1、 确认故障硬件的重要性和影响范围;

2、 创建维修单;

3、 授权维修单;

4、 现场更换操作;

5、 告警信息确认。

【故障定位】

一、创建维修单

场景一:普通IO、高IO类型、超高IO类型磁盘故障

普通IO、高IO类型更换磁盘无需减容存储节点。维修工单统一由华为方创建(电信政务云维护团队发现需要更换的磁盘,统一报备到华为方,由华为方创建)。

1、报修人员发邮件给硬件侧,报修格式如下:

场景二:其他硬件故障(要下电更换)

1、政务云维护团队负责人员查看故障服务器

2、维修工单统一由华为方创建(政务云维护团队发现需要更换的CPU、内存、电源灯,统一报备到华为方,由华为方创建)。

3、报修人员发邮件给硬件侧,报修格式如下:

二、授权维修单

场景一:普通IO、高IO类型、超高IO类型磁盘故障

注意:

1、禁止同一个局点多个存储池同时更换

2、禁止同一存储池非同一机柜的磁盘同时更换

3、如需减容节点,减容前需要确认所减容节点是否为故障节点,防止操作错对象

场景二:其他硬件故障

更换备件前需联系政务云维护团队负责人员核实系统当前告警及系统运行状态,获得许可后方可更换。

注意:

1、更换前需要确保业务系统虚拟机已迁移至其他宿主机上。

三、现场更换操作(实时观察告警)

关机—移除线缆—打开机箱—更换故障硬件—开机。

四、告警确定

确定硬件故障是否恢复,告警平台告警是否解除。

【故障恢复】

替换完成后,机房现场环境确认设备状态灯正常;登录告警平台查看对应设备告警已经解除;


3.1.4存储类

3.1.4.1 场景12:硬件故障导致存储池OSD IO异常应急预案

【目的】

通过本应急预案的处理,解决公有云环境下,FusionStorage出现硬件故障导致存储池OSD IO异常场景下的应急故障处理。

【故障现象】

FusionStorage portal上出现OSD IO异常告警:

【故障影响】

硬件故障导致存储池OSD IO异常。

【应急恢复时长】

10分钟

【故障处理思路】

快速找到故障节点进行故障隔离。

【故障定位】

分析OSD IO异常的告警,查看磁盘相关信息,确认磁盘ESN、OSD IO,执行命令进行隔离设备上下发静态路由紧急恢复业务。

【故障恢复】

场景一:NVME SSD卡硬件故障

l 操作场景

登录上报OSD IO异常告警的故障节点。

l 前提条件

l 操作步骤

步骤1  登录FSM,查找OSD节点IO异常告警节点的上报IP。

l 根据告警中的存储IP,在FSM服务器中查看存储IP对应的管理IP。

l 通过堡垒机登录该节点

步骤2  通过日志中的iostat结果,确认故障OSD的盘符信息nvmeXn1

步骤3  确认故障盘的nvme卡ESN

cat /proc/smio_host |grep nvme5n1

步骤4  从磁盘拓扑中查看nvme卡当前状态是否正常

步骤5  如果nvme卡不在集群,无需处理

步骤6  如果nvme卡还在集群里需要通过命令踢出集群

1、确认当前存储池使用率低于70%,写带宽低于基线50%,且当前没有数据迁移

2、执行命令踢出OSD

source /opt/dsware/agent/tool/set_di_cmd_env.sh

$mdc_di_cmd 101 pool_id |grep XXXXXX (查询故障盘的ID信息, pool_id是池ID,XXXXXX 是故障盘的ESN,使用步骤3可以看到)
$mdc_di_cmd 107 OSD_ID 4

查看故障nvme卡是否已踢出集群以及存储池时延是否正常。

步骤 1 影响面分析,Friday导出CDC TOPN在告警时间前后10分钟内时延超过1s的卷

 

 

3.1.4.2 场景13:存储池爆池应急预案

【目的】

通过本应急预案的处理,解决针对平台现网环境存储池爆池,需要关闭网络亚健康、开启Busy模式、关闭HINT,使得业务规避紧急故障风险。

【故障现象】

1、存储写入异常。

【故障影响】

AZ关联存储POD业务写入异常。

【应急恢复时长】

60分钟

【故障处理思路】

关闭网络亚健康、开启Busy模式、关闭HINT。

【故障定位】登录主FSM节点查询网络亚健康状态。

【故障恢复】

1、登录Friday 查询到待修改的region的主FSM等信息1、POD业务紧急恢复

方法一:Friday集群监控页面:

https://cloudscope.huaweicloud.com/evs-Friday/#/Friday/deviceList

FSM IP: XX.XX.XX.XX

MDC IP:XX.XX.XX.XX  MDC可以选择任一MDC节点,这里优选主MDC

方法二:若无Friday则可以登录到FSM管理portal查看主FSM节点IP信息,以及查询任一MDC节点IP信息

https://XX.XX.XX.XX

fsm :FSM管理portal -> 系统 -> 管理 IP (或者根据密码表查询主FSM节点)

MDC节点IP:FSM管理portal -> 监控 -> 进程监控 -> 所有进程 更换为MDC即可      

 

2、登录主FSM节点查询网络亚健康状态

登录主FSM XX.XX.XX.XX

FSM上查看主MDC节点上的配置确实是开启状态

sh /opt/dsware/client/bin/dswareTool.sh --op queryNetworkSubhealthSwitch -ip xxx.xxx.xxx.xxx

其中后面的ip xxx.xxx.xxx.xxx是MDC节点的管理IP

3、登录主MDC 查看跨节点亚健康配置

登录MDC  XX.XX.XX.XX

查看节点上的配置是开启状态

cat /opt/dsware/mdc/conf/mdc_conf.*  |grep -i g_mdc_cross_unhealth_switch

open表示为开启状态

4、登录MDC 查看Busy模式配置

登录主MDC  XX.XX.XX.XX

查看mdc节点上的Hint 配置,确认Busy模式为关闭状态

source /opt/dsware/agent/tool/set_di_cmd_env.sh

$mdc_di_cmd 189 pool_id query

其中后面的pool_id是待修改的存储池ID,根据需求修改

query固定不变,表示查询Busy模式

5、登录主FSM 查看Hint模式配置

登录主FSM XX.XX.XX.XX

 

以下两个参数均需要检查,确认为开启状态

1、查看Hint的配置全局开关

sh /opt/dsware/client/bin/dswareTool.sh --op queryGlobalParameters -paraName g_mdc_hint_switch

2、查看Hint配置的存储池开关

sh /opt/dsware/client/bin/dswareTool.sh --op queryPoolParameters -poolId XXX

查询参数p_mdc_hint_switch 值信息

其中后面的 XXX 是存储池ID

6、登录主fsm节点后台,关闭网络亚健康

登录主FSM  XX.XX.XX.XX

关闭网络亚健康:

sh /opt/dsware/client/bin/dswareTool.sh --op setNetworkSubhealthSwitch -s close

7、登录主fsm节点后台,关闭跨节点亚健康

登录主FSM  XX.XX.XX.XX

关闭跨节点IO亚健康:

sh /opt/dsware/client/bin/dswareTool.sh --op globalParametersOperation -opType modify -parameter g_mdc_cross_unhealth_switch:close

8、登录主MDC 节点后台,开启存储池的Busy模式(仅限于FusionstorageBlock的版本SPC8XX ,版本若不符合请找产品确认)

登录主MDC  XX.XX.XX.XX

开启存储池Busy模式:

source /opt/dsware/agent/tool/set_di_cmd_env.sh

$mdc_di_cmd 189 pool_id busy

其中pool_id 是待修改的存储池ID

9、登录主fsm节点后台,关闭存储池的HINT 开关

登录主FSM  XX.XX.XX.XX

sh /opt/dsware/client/bin/dswareTool.sh --op poolParametersOperation -opType modify -parameter p_mdc_hint_switch:0 -poolId XXX

其中 XXX 表示待修改的存储池ID

说明:这条命令关闭的是HINT的存储池开关,如果有多个存储池需要修改pooId后多次执行该命令,如果是存储节点失败,需要定位。

10、(选做)登录主fsm节点后台,关闭全局HINT开关(需要产品确认)

登录主FSM  XX.XX.XX.XX

若确定需要关闭全局Hint开关,则需要确保所有存储池的HINT关闭成功

sh /opt/dsware/client/bin/dswareTool.sh --op globalParametersOperation -opType modify -parameter g_mdc_hint_switch:close

说明:这条命令关闭的是HINT的全局开关,如果是计算节点上报错误,可以忽略。如果是存储节点,需要定位

执行完成之后,还需要确认 hintview视图清理,可以参考《基础服务块存储常规变更SOP(hint上线)_V2.0.docx》。

【恢复确认】

1)登录主MDC 查看跨节点亚健康配置

2)登录主MDC 查看Busy模式配置

3)登录主FSM 查看Hint模式配置

4)登录FSM 管理 Portal查看存储池状态和告警

备注:

 

 

四、系统备份、恢复方案

服务器采用双机热备及定时备份方案,每天凌晨对数据备份,数数据层增量备份,当数据丢失或异常故障发生需要恢复数据,可采用平台层按钮点击恢复功能,完成故障前节点的数据恢复,截图如下:

 

 

 


附件一:故障处理

 

政务云平台应急故障处理单

故障名称

 

填写人

 

发生时间

 

排除时间

 

故障描述:

 

 

主要工作小组故障分析及排除故障过程描述:

 

 

其他支撑工作组故障分析及排除故障过程描述:

 

 

故障排除结论:

 

遗留问题及存在隐患:

 

 

预防措施: