- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 新华三人才研学中心
- 关于我们
手册下载
H3C CAS云计算管理平台 应急故障恢复指导-5W101-整本手册.pdf 
(3.18 MB)
H3C CAS云计算管理平台
应急故障恢复指导
资料版本：5W101-20240524
Copyright © 2024新华三技术有限公司 版权所有，保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。
除新华三技术有限公司的商标外，本手册中出现的其它公司的商标、产品标识及商品名称，由各自权利人拥有。
本文档中的信息可能变动，恕不另行通知。
目 录
3.4.4 虚拟机无法正常启动，报“Could not read snapshots: File too large”错误
3.4.8 虚拟机使用云彩虹迁移失败，报“文件拷贝错误”错误
3.4.9 CPU为海光7280的主机，Centos5/6.8虚拟机启动时报soft lockup错误
3.4.10 单台CVK主机故障，并且虚拟机无法通过HA恢复
3.5.6 启动共享存储池时失败，提示“存储池没有可用的slot”
3.6.7 银河麒麟操作系统的虚拟机配置DNS后，重启主机，配置失效
3.6.8 Ubuntu 20虚拟机配置IPv4地址，界面报错：修改虚拟机xxx配置失败
本文为H3C CAS云计算管理平台常见故障应急解决方案，目的是帮助在一些突发情况下尽快恢复业务。本手册主要适用于：现场技术支持与维护人员、网络管理员。
由于设备不同型号、不同配置、不同版本等原因，本手册中的内容可能与用户使用的设备显示信息不一致。实际使用中请以设备显示的内容为准。我们会在后续使用过程中，持续改进文档，力求做到更好地为客户、为生产、为现场服务提供最佳的指导。如果您在使用过程中发现任何问题，请联系技术支持并反馈！
应急处理以快速恢复设备的正常运行和维持业务的正常提供为核心指导思想，其总体处理流程如下图所示。
在出现需要应急恢复的故障时，应先尝试采取应急恢复措施，尝试恢复业务。无论是否恢复成功，均应在后续进行故障定位并彻底解决。
图1 故障处理流程图
重大故障很容易导致大面积的用户虚拟机故障、设备瘫痪等严重后果，具有很大的危害性。为提高重大故障的处理效率、并尽最大的限度降低此类故障的损失，在维护本设备之前，应充分考虑并遵循以下应急处理的基本原则。
· 应急处理以快速恢复设备的正常运行与业务的提供为核心，因此，提高重大故障处理效率的关键是：客户应参考应急处理手册及时制定各种重大故障的处理预案，并定期组织相关管理人员与维护人员进行学习、演练。
· 以客户业务尽快恢复，对客户影响最低为原则。在此前提下，进行问题定位恢复和数据收集。
· 维护人员在上岗前必须接受必要的应急处理培训，学习判断重大故障的基本方法、掌握处理重大故障的基本技能。
· 在重大故障的处理过程中，维护人员应及时联系新华三公司客户服务中心或新华三公司驻当地办事处，以便能够快速获取新华三公司的技术支持。
· 当维护人员完成重大故障的处理以后，应该及时采集与本次故障有关的设备故障告警信息，并将相关的故障处理报告、设备告警文件、日志文件等发送给新华三公司进行分析与定位，以便新华三公司能够更好地为客户提供售后服务。
业务恢复应综合考虑相应操作恢复业务成功的可能性和相应操作时间代价。参考的操作排序如下：
(1) 耗时比较短，成功可能性比较大的操作。
(2) 耗时比较短，成功可能性比较小的操作。
(3) 耗时比较长，成功可能性比较大的操作。
表1 应急日常准备
|
类别 |
应急日常准备 |
|
设备级备份 |
· 主备用设备要求：定期进行数据一致性检查，以及运行状态检查，确保应急时能够接管业务。 · 负荷分担设备要求：定期进行负荷评估，评估业务单平面运行性能评估，确保单点故障业务可以全部由另一个设备接管。 |
|
容灾（可选） |
容灾局及相关切换准备。 |
|
日常告警清理 |
关键设备需要常备备件。 |
|
基本信息 |
日常告警需要及时处理，确保没有未确认的活动告警，避免出现问题时，信息混乱，影响事故处理中的判断决策。 |
|
人员要求 |
维护人员需要准备以下基本信息： · 组网信息 · 设备基础信息 · 软件列表 · 网络设备IP地址信息 · 业务信息 · 备件信息 · 远程维护信息 · 相关接口人 |
图2 应急恢复流程图
观察故障状态并判断故障类型，故障类型包括：
· 计算相关异常：主要包括主机异常，虚拟机异常等。例如主机无法启动，虚拟机无法启动，迁移无法完成等情况。
· 存储相关异常：主要是共享存储池异常，例如磁盘IO异常，主机存储异常，存储池配置失败、不可用等情况。
· 网络相关异常：主要包括主机或虚拟机网络不可用，配置不正确，丢包率高等情况。
· 故障告警：明确的故障告警信息。
· 其他异常：主要包括管理平台不可用、外设不可用等。例如管理平台无法登陆，无法升级，系统时间异常等情况。
故障类型可通过如下信息进行判断：
· 查看任务执行失败的提示信息。
· 查看任务台任务执行情况。
· 查看管理平台中的告警信息。
· 观察虚拟机或主机性能监控信息。
在主机或虚拟机出现应急故障时，可以尝试采用如下方法尝试恢复业务。
· 重启虚拟机：在管理平台或SSH至虚拟机后台尝试重新启动虚拟机。
· 重启业务主机：参考《H3C CAS云计算管理平台 正常开关机配置指导》，重启业务主机。
· 重启网络设备：重启故障相关的物理交换机，路由器等网络设备，观察链路情况。
· 在管理主机后台重启如tomcat8等服务，各服务对应的模块详情可参考维护手册或联系技术支持。
系统硬件检测完成后，报错“No bootable device”。
主机无法正常启动。
· 服务器没有安装操作系统或服务器没有引导磁盘设备。
· 服务器引导模式发生过变更。
· RAID卡损坏或者RAID卡驱动不匹配。
· 检查是否存在磁盘设备，或者磁盘是否损坏，联系硬件修复，然后再安装系统。
· 若服务器引导模式发生过变更，需要重新安装系统。
· 若RAID卡损坏，联系硬件厂家修复，若RAID卡驱动不匹配，需联系技术支持进行驱动适配。
· 系统安装过程中卡死或黑屏。
· 安装完成后无xconsole界面。
系统无法正确安装、使用。
· 由于网络状态的原因，安装过程中出现中断。
· 用于安装的U盘格式不对。
· 使用飞腾CPU服务器，无xsconsole界面。
· 使用Linux DD方式制作U盘安装盘，命令格式为：dd if=/root/CAS-*.iso of=/dev/sdc bs=1M。
虚拟机无法正常启动。
虚拟机无法启动，用户业务无法正常使用。
· CPU或内存资源不足，检查物理服务器的CPU和内存资源占用情况。管理平台是否开启了“主机内存预留”功能，该功能会增加一个限制，如果物理主机内存+虚拟机内存>80%，后续虚拟机就不让启动了。
· Libvirt所做的资源检查不通过，导致无法启动。这种启动失败会记录在Libvirt的日志中，Libvirt的内存门限在如下配置文件中配置，如下所示。
cat /etc/cvk/cpu_mem_threshold.conf
CpuUsePercent 85 MemSysReserved 4
· 卸载亚信杀毒后，存在虚拟机配置文件残留配置，导致虚拟机无法启动。
· 如果是由于资源不够导致的问题，请手动释放CPU或者内存资源；如果是由于资源超配导致的问题，可以暂时关闭不使用的虚拟机或将其他虚拟机迁移至另外的主机以释放资源。
· 如果是配置文件残留，查看虚拟机日志有如下打印：
2017-05-18 11:01:52.617+0000: 29917:
error : qemuProcessWaitForMonitor:1852 : internal error process exited while connecting
to monitor: 2017-05-18 11:01:52.414+0000: domain pid 32504, created by libvirtd
pid 2974
char device redirected to /dev/pts/8 (label charserial0)
kvm: -chardev socket,id=charshmem0,path=/tmp/kvmsec: Failed to connect to socket:
No such file or directory
kvm: -chardev socket,id=charshmem0,path=/tmp/kvmsec: chardev: opening backend "socket"
failed
· 查看虚拟机配置，包含如下内容：
<shmem name='nu_fsec-4af99204-6623-45e9-afbf-d852746bf187'>
<size unit='M'>8</size>
<server path='/tmp/kvmsec'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</shmem>
这种情况的解决方案为：删除xml标签，然后重新启动虚拟机。
查看虚拟机日志，存在如下内容：
error: Failed to start domain centos
error: internal error process exited while connecting to monitor: 2016-08-02 19:52:42.707+0000:
domain pid 31971, created by libvirtd pid 3434
char device redirected to /dev/pts/5 (label charserial0)
kvm: -drive file=/vms/share/Centos6.5-tf.5-tf,if=none,id=drive-virtio-disk0,format=qcow2,cache=directsync:
could not open disk image /vms/share/Centos6.5-tf.5-tf: Could not read snapshots:
File too large
用户业务受此影响无法正常使用。
虚拟机镜像文件快照信息损坏。
(1) 用qcow2.py工具将qcow2头文件中的快照信息修改为0。使用的命令包括：qcow2.py dump-header、qcow2.py set-header nb_snapshots 0以及qcow2.py set-header snapshot_offset 0x0，示例如下。
root@mi-service:~# qcow2.py /vms/share/Centos6.5-tf.5-tf dump-header
magic 0x514649fb
version 3
backing_file_offset 0x0
backing_file_size 0x0
cluster_bits 21
size 26843545600
crypt_method 0
l1_size 1
l1_table_offset 0x600000
refcount_table_offset 0x200000
refcount_table_clusters 1
nb_snapshots 4
snapshot_offset 0x130600000
incompatible_features 0x0
compatible_features 0x0
autoclear_features 0x0
refcount_order 4
header_length 104
root@mi-service:~# qcow2.py /vms/share/Centos6.5-tf.5-tf set-header
nb_snapshots 0
root@mi-service:~# qcow2.py /vms/share/Centos6.5-tf.5-tf set-header
snapshot_offset 0x0
root@mi-service:~# qcow2.py /vms/share/Centos6.5-tf.5-tf dump-header
magic 0x514649fb
version 3
backing_file_offset 0x0
backing_file_size 0x0
cluster_bits 21
size 26843545600
crypt_method 0
l1_size 1
l1_table_offset 0x600000
refcount_table_offset 0x200000
refcount_table_clusters 1
nb_snapshots 0
snapshot_offset 0x0
incompatible_features 0x0
compatible_features 0x0
autoclear_features 0x0
refcount_order 4
header_length 104
(2) 操作完成后重新启动虚拟机。
重启虚机时报错，找不到启动盘。
用户业务受此影响无法正常使用。
查看虚拟机日志有如下字段：
qcow2: Preventing invalid write on metadata (overlaps with snapshot table); image marked as corrupt.
使用qemu-img check XXX（XXX代表磁盘镜像）命令检查该虚机的磁盘镜像有报错，如下图：
执行qemu-img check -r all xxx（XXX代表磁盘镜像）命令恢复镜像文件，恢复成功后，虚拟机即可启动。
修复之前，需要对于文件备份，以便后续可能等多次修复等。
· 虚拟机迁移卡住，长时间不能完成，进度显示为99%。
· 虚拟机详情页中的虚拟机迁移速度为0，保持15分钟以上。
用户业务可能受影响。
· 磁盘文件较大，管理网带宽为千兆网，所以磁盘迁移耗时较长。
· 业务繁忙，内存产生脏数据较快，内存迁移无法收敛。
· 存储故障，虚拟机被冻结。
· 迁移网络中断。
· 查看目的磁盘文件大小，并等待磁盘迁移完成。
· 暂停虚拟机内部业务，或等待业务压力减小后再继续。
· 检查虚拟机所使用的存储池是否正常，如有需要可终止目的端KVM进程来结束迁移任务。
· 如果是迁移网络中断，使用virsh list命令观察源端以及目的端虚拟机的状态，此时源端应为pause，目的端为running，使用virsh destroy命令关闭源端以及目的端虚拟机，使用systemctl restart libvirtd命令重启libvirtd服务，使用virsh undefined命令注销源端虚拟机，使用virsh start命令启动目的端虚拟机，并恢复相关业务。
在管理平台中部署虚拟机，结果为部分部署成功，错误码为7501。
虚拟机没有正确部署，可能影响正常使用。
错误码7501一般都是由于castools.py执行失败引起的，可以在日志/var/log/castools.log中查看具体故障原因。
目前比较常见的原因有：
· 虚拟机磁盘损坏，libguestfs会检查磁盘分区等信息，磁盘损坏则无法挂载。
· 虚拟机没有正确安装CAStools，虚拟机内部qemu-ga服务异常。
· 在主机后台执行qemu-img check -r all xxx（XXX代表磁盘镜像）命令恢复镜像文件。
· 重新安装CAStools。
虚拟机从E0710P11及之前的版本中通过云彩虹迁移至E0718及之后的版本中，出现部分虚拟机迁移任务失败，报错“文件拷贝错误”。
虚拟机无法使用云彩虹在线迁移。
查看cas.log时可以看到SCP任务执行失败，错误信息显示为“Bad SSH2 cipher spec 'arcfour128,aes128-ctr,aes192-ctr,aes256-ctr'”。
自E0718版本起，为了解决openssh漏洞升级了openssh的版本。因此，加密算法参数发生了变化。但老版本的云彩虹迁移接口下发的参数仍会采用“scp -o Ciphers=xxx”的方式。这种情况在E0718之后的版本上会执行失败。
在线迁移时，若虚拟机仅存在单级磁盘文件，则通过libvirt进行迁移，不会触发SCP任务。而对于离线迁移虚拟机，或磁盘文件存在多级镜像文件、快照的情况下，会触发SCP任务，从而导致云彩虹任务失败。
合并虚拟机镜像文件后，采用在线迁移即可。
在海光C86 7280 32-Core CPU环境下，使用Centos6.5/6.8虚拟机进行启动时，会出现“soft lockup”错误。
虚拟机无法正常启动。
在抓取虚拟机的kernel dump时，发现在启动过程中可能会出现“soft lockup”，并且这种情况发生在不同的应用程序中。值得注意的是，这些应用程序在运行到“exception RIP: get_random_bytes+41”时都无法返回。
PID: 1208 TASK: ffff8802374ff540 CPU: 0 COMMAND: "modprobe"
[exception RIP: get_random_bytes+41]
RIP: ffffffff81331419 RSP: ffff880236b6fcf8 RFLAGS: 00000203
RAX: ffffffffffffffff RBX: ffff880237f79cf0 RCX: 000000000000000a
RDX: 00000000000000ff RSI: 0000000000000008 RDI: ffff880237f79cf0
RBP: ffff880236b6fd38 R8: 0000000000000000 R9: 0000000000000180
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000008
R13: ffff880237f79ce4 R14: ffff880237f79df0 R15: 0000000000000001
CS: 0010 SS: 0018
#0 [ffff880236b6fd40] __ipv6_regen_rndid at ffffffffa01559ed [ipv6]
#1 [ffff880236b6fd60] ipv6_regen_rndid at ffffffffa0157240 [ipv6]
#2 [ffff880236b6fd80] ipv6_add_dev at ffffffffa015753e [ipv6]
#3 [ffff880236b6fdb0] addrconf_notify at ffffffffa015a8e9 [ipv6]
#4 [ffff880236b6fe90] register_netdevice_notifier at ffffffff8145d9bf
#5 [ffff880236b6fee0] addrconf_init at ffffffffa019e3be [ipv6]
#6 [ffff880236b6ff00] init_module at ffffffffa019e198 [ipv6]
#7 [ffff880236b6ff20] do_one_initcall at ffffffff8100204c
#8 [ffff880236b6ff50] sys_init_module at ffffffff810bc291
#9 [ffff880236b6ff80] system_call_fastpath at ffffffff8100b072
RIP: 00007efef7b33eda RSP: 00007ffeffffb808 RFLAGS: 00010287
RAX: 00000000000000af RBX: ffffffff8100b072 RCX: 0000000000000030
RDX: 000000000261e6e0 RSI: 000000000008ad20 RDI: 00007efef7e12010
RBP: 00007ffeffffbb00 R8: 00007efef7e9cd30 R9: 00007efef7ff7700
R10: 00007ffeffffb770 R11: 0000000000000206 R12: 000000000261e6e0
R13: 0000000002625250 R14: 000000000261d550 R15: 000000000261e6e0
ORIG_RAX: 00000000000000af CS: 0033 SS: 002b
经过分析，发现get_random_bytes()函数最终是通过CPU指令rdrand来获取随机数的。在虚拟机运行在主机匹配模式、直通模式下时，可能会存在rdrand flag问题。这主要是因为AMD CPU的rdrand指令不够稳定。此外，虚拟机所使用的CentOS6.8内核版本较老（为2.6.32），而该内核版本的Linux社区已经停止使用rdrand特性。
为了解决上述问题，可以在虚拟机的XML文件中修改CPU部分，将rdrand特性禁用即可。
本章节介绍在单台CVK主机故障且无法触发HA迁移虚拟机至正常主机时，如何在其他正常的CVK主机上应急恢复虚拟机。整体恢复思路为：通过拷贝虚拟机xml文件到正常主机下并通过virsh define xxx命令拉起虚拟机。
故障场景包括但不限于如下情况：
· 集群未开启HA。
· 集群开启HA，但主机故障时没有正常触发虚拟机高可靠迁移。
虚拟机无法正常使用，可能导致业务中断。
执行该恢复操作之前，请先确保集群环境满足如下前提条件：
· 原故障虚拟机的磁盘文件存在于共享文件系统，而非主机本地磁盘中。
· 集群中存在其他正常运行的CVK主机，并且剩余的CPU和内存资源充足。
· 原故障虚拟机已处于关机状态，以防止两台活动的虚拟机同时向磁盘写入数据，导致损坏磁盘文件。
· 故障CVK主机短时间内无法恢复，可以临时采取断开网络或者下电关机的方式将主机临时隔离出集群。
具体操作步骤如下：
(1) 查找并拷贝虚拟机的xml配置文件。
虚拟机的xml文件在其宿主机的/etc/libvirt/qemu/vm-name.xml路径中。此时，由于宿主机已经故障，无法登陆其后台查看虚拟机xml配置文件。此时需要通过下列方法获取虚拟机的xml文件。
¡ 如果集群开启HA功能，则可以在管理主机的/etc/cvm/ha/1/cvknode1（其中1为集群编号，cvknode1为故障主机主机名，根据实际情况替换）目录中拷贝虚拟机xml文件（命名方式为虚拟机高级名称.xml）至待迁移的目的主机的/etc/libvirt/qemu目录中。
¡ 如果集群未开启HA功能，可下载管理平台备份文件并在本地进行解压，虚拟机xml文件的路径为front\cvks\cvknode1\libvirt\qemu（其中cvknode1为故障主机主机名，根据实际情况替换）。
备份时间要晚于最后一次修改故障主机上虚拟机的时间，否则虚拟机配置文件会跟虚拟机本身不符，如没有合适的备份文件，请及时联系技术支持处理。
找到目标文件后，将虚拟机xml文件拷贝至待迁移的目的主机的/etc/libvirt/qemu目录中。
(2) 关闭虚拟机。如果虚拟机仍处于开机状态，请先手动关闭虚拟机，可依次尝试如下方法。
由于两台同名虚拟机同时对同一个磁盘文件进行读写会造成文件系统损坏，因此在迁移后的新虚拟机开机前需确保老虚拟机已关机。
¡ 操作系统内部安全关闭。
¡ 平台选择关闭电源。
¡ 故障CVK后台执行virsh list --all命令找到虚拟机ID，然后然后执行virsh destroy VM_ID命令。
¡ 特定场景下，如果以上方法均无法操作，则可以直接将故障CVK服务器下电关机，从而关闭其中的虚拟机。
(3) define虚拟机。define虚拟机指通过虚拟机的xml文件在其他主机将虚拟机拉起，在执行该动作时需保证目的主机具备这些条件：已挂载磁盘文件所在存储池、计算资源充足、网络配置与故障主机一致。
进入目的主机/etc/libvirt/qemu目录确认虚拟机xml文件已存在，执行virsh define ***.xml命令新建虚拟机，执行virsh start ***命令将虚拟机开机（***为虚拟机高级名称）。
(4) 重复步骤（1）-（3）将所有虚拟机迁移至目的主机，并在管理平台删除源故障主机，如果不删除源主机，则无法在管理平台页面中看到新define的虚拟机。
(5) 在管理平台的目的主机概览页面执行连接主机操作，执行该操作后，可在管理平台中看到新define的虚拟机。
(6) 通过此方法define的虚拟机网络策略模板为空，需在管理平台中手动为其选择网络策略模板。
(7) 启动虚拟机并检查业务是否正常。
故障主机问题修复后可重新加入集群，无需删除主机中遗留的源虚拟机，加入集群后这些虚拟机会被自动删除
在管理平台中，可以看到主机性能监控处磁盘IO延迟较大，虚拟机出现了卡顿现象。此外，在ping虚拟机时网络出现了抖动，并且甚至出现了丢包的现象。
虚拟机无法正常使用，影响用户业务。
存储池IO吞吐量较大，并且IOPS较高。
针对虚拟机业务IO压力较大的情况，可以考虑将虚拟机迁移到其他存储池中。如果必要的话，也可以对虚拟机的IO进行适当限制。如下图所示。
启动共享存储池时失败，报相应的错误信息。
用户无法启动共享存储池，业务无法正常使用。
可能的原因可能是现场网络或存储的配置的原因。因此，我们可以从网络和存储两个方面对问题进行排查。
在无法激活存储池的情况下，以下方面需要进行排查和考虑以找到解决方案：
· 检查存储是否发生了配置更改，导致主机无法访问对应的LUN。
· 检查服务器到存储的链路是否可达，可通过后台命令检查FC和IP SAN。
· 分析/var/log/ocfs2_shell_201511.log，/var/log/libvirt/libvirtd.log和/var/log/syslog日志文件，查看错误信息并尝试找到原因。
· 检查节点间共享文件系统的配置文件"/etc/default/o2cb"和"/etc/ocfs2/cluster.conf"是否一致。
· 检查多路径是否正常，可执行multipath -ll命令分析LUN是否正确建立了多路径，目录下是否有WWID（NAA）名称为/dev/disk/by-id/dm-name-36000eb34fe49de760000000000004064的路径。
· 如果条件允许，执行fdisk -l命令检查磁盘是否可用。
· 如果条件允许，可尝试重启对应的服务器以解决此问题。
如果通过上述步骤，仍然无法激活存储池，请及时收集日志文件，联系技术支持进行分析。
在管理平中，点击主机详情页中的存储池页签，页面无法正常显示，管理平台阻塞。
用户业务受较大面积影响。
故障可能性较多，需要逐个排查。
找到共享文件系统阻塞的根节点，重启对应的主机解决。
(1) 执行df –h命令，检查存储池挂接的各个mount point，观察能否正常访问。如果命令阻塞，长时间没有返回，则说明共享文件系统阻塞了。
(2) 执行mount | grep ocfs2命令，检查正在使用的共享文件系统。
root@B12-R390-FC-06:~# mount |grep ocfs2
ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw)
/dev/sdj on /vms/IPsan-St-002 type ocfs2 (rw,_netdev,heartbeat=local)
/dev/sdm on /vms/VM_BackUp type ocfs2 (rw,_netdev,heartbeat=local)
/dev/dm-0 on /vms/FC-St type ocfs2 (rw,_netdev,heartbeat=local)
/dev/sdk on /vms/IPsan-St-001 type ocfs2 (rw,_netdev,heartbeat=local)
/dev/sdl on /vms/ISO_POOL type ocfs2 (rw,_netdev,heartbeat=local)
(3) 执行debugfs.ocfs2 -R “fs_locks -B”命令，检查各个磁盘是否有阻塞lock。
a. 如果输出如下内容，说明磁盘sdb，sde没有阻塞，而sdc则存在阻塞的locks。sdc有3个dlm lock处于阻塞状态。
root@ZJ-WZDX-313-B11-R390-IP-07:~# mount |grep ocfs2
ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw)
/dev/sdb on /vms/IPsan-St-002 type ocfs2 (rw,_netdev,heartbeat=local)
/dev/sde on /vms/VM_BackUp type ocfs2 (rw,_netdev,heartbeat=local)
/dev/sdc on /vms/IPsan-St-001 type ocfs2 (rw,_netdev,heartbeat=local)
/dev/sdd on /vms/ISO_POOL type ocfs2 (rw,_netdev,heartbeat=local)
root@ZJ-WZDX-313-B11-R390-IP-07:~# debugfs.ocfs2 -R "fs_locks -B" /dev/sdb
root@ZJ-WZDX-313-B11-R390-IP-07:~# debugfs.ocfs2 -R "fs_locks -B" /dev/sde
root@ZJ-WZDX-313-B11-R390-IP-07:~# debugfs.ocfs2 -R "fs_locks -B" /dev/sdc
Lockres: P000000000000000000000000000000 Mode: No Lock
Flags: Initialized Attached Busy Needs Refresh
RO Holders: 0 EX Holders: 0
Pending Action: Convert Pending Unlock Action: None
Requested Mode: Exclusive Blocking Mode: No Lock
PR > Gets: 0 Fails: 0 Waits (usec) Total: 0 Max: 0
EX > Gets: 13805 Fails: 0 Waits (usec) Total: 8934764 Max: 5
Disk Refreshes: 0
Lockres: M000000000000000000020737820a41 Mode: No Lock
Flags: Initialized Attached Busy
RO Holders: 0 EX Holders: 0
Pending Action: Convert Pending Unlock Action: None
Requested Mode: Protected Read Blocking Mode: No Lock
PR > Gets: 2192274 Fails: 0 Waits (usec) Total: 15332879 Max: 1784
EX > Gets: 2 Fails: 0 Waits (usec) Total: 5714 Max: 3
Disk Refreshes: 1
Lockres: M000000000000000000020137820a41 Mode: No Lock
Flags: Initialized Attached Busy
RO Holders: 0 EX Holders: 0
Pending Action: Convert Pending Unlock Action: None
Requested Mode: Protected Read Blocking Mode: No Lock
PR > Gets: 851468 Fails: 0 Waits (usec) Total: 409746 Max: 8
EX > Gets: 3 Fails: 0 Waits (usec) Total: 6676 Max: 3
Disk Refreshes: 0
b. 查询阻塞的dlm lock的使用信息，在owner节点上查询对应的使用情况。查询dlm lock的信息，发现其owner为5，则需要到/etc/ocfs2/cluster.conf文件中找到编号为5的node，ssh到该node中，再次执行dlm的查询命令，查看dlm的各个节点的使用情况。
root@ZJ-WZDX-313-B11-R390-IP-07:~# debugfs.ocfs2 -R "dlm_locks P000000000000000000000000000000" /dev/sdc
Lockres: P000000000000000000000000000000 Owner: 5 State: 0x0
Last Used: 0 ASTs Reserved: 0 Inflight: 0 Migration Pending: No
Refs: 3 Locks: 1 On Lists: None
Reference Map:
Lock-Queue Node Level Conv Cookie Refs AST BAST Pending-Action
Converting 10 NL EX 10:1260
c. 节点5上对于该lock的使用情况，可以看到节点7一直持有，但不释放导致了其他node的阻塞：
root@ZJ-WZDX-313-B12-R390-FC-05:~# debugfs.ocfs2 -R "dlm_locks P000000000000000000000000000000" /dev/sdk
Lockres: P000000000000000000000000000000 Owner: 5 State: 0x0
Last Used: 0 ASTs Reserved: 0 Inflight: 0 Migration Pending: No
Refs: 12 Locks: 10 On Lists: None
Reference Map: 1 2 3 4 6 7 8 9 10
Lock-Queue Node Level Conv Cookie Refs AST BAST Pending-Action
Granted 7 EX -1 7:1446 2 No No None
Converting 4 NL EX 4:1443 2 No No None
Converting 2 NL EX 2:1438 2 No No None
Converting 8 NL EX 8:1442 2 No No None
Converting 6 NL EX 6:1441 2 No No None
Converting 3 NL EX 3:1438 2 No No None
Converting 1 NL EX 1:1442 2 No No None
Converting 10 NL EX 10:1260 2 No No None
Converting 5 NL EX 5:1442 2 No No None
Converting 9 NL EX 9:1259 2 No No None
d. 在阻塞的node上，例如上文中的node 7，也可以通过如下命令查看对应的阻塞进程。
ps -e -o pid,stat,comm,wchan=WIDE-WCHAN-COLUMN | grep D
PID STAT COMMAND WIDE-WCHAN-COLUMN
22299 S< o2hb-C12DDF3DE7 msleep_interruptible
27904 D+ dd ocfs2_cluster_lock.isra.30
e. 存储阻塞则需要重启对应的服务器来解决问题，重启的步骤如下：
- 在阻塞的node上，执行ps -ef |grep kvm命令查看所有该主机上运行的虚拟机。
- 后台查询所有的虚拟机进程，并记录各个虚拟机的VNC端口等信息。
- 采用VNC或者虚拟机的远程桌面，尽量从虚拟机内部关闭虚拟机。部分虚拟机无法关闭，则需要采用kill命令强制关闭虚拟机进程，命令未kill -9 pid。
- 采用reboot命令重启故障的主机。有时reboot命令会失败，此时需要通过iLo口登录到主机的管理界面，选择安全重启服务器，或者reset进行重启。
- 服务器启动后，检查系统是否恢复正常。
物理机在使用共享文件系统时会定期向设备写入时间戳。此外，当设备连接不通时，物理机会根据fence特性执行重启操作。这种操作是集群保护性策略的一种形式，用于规避集群资源访问完整性的风险，并将对于资源的损坏降到最低。fence技术是一种保障集群高可用的解决方案，旨在确保资源访问的连续性和完整性。通过采用fence技术，可以降低数据丢失和不可用的风险，提高集群的可靠性和稳定性。
用户业务受较大面积影响。
· 服务器到存储设备的链路不稳定或反复震荡。
· 存储异常。
一般情况下，在/var/log/syslog中会存在重启前链路断开的日志信息，如网口或FC的down、iSCSI或FC的链接断开、磁盘IO的异常信息。
另外在/var/log/ocfs2_fence_restart.log中也能看到重启的记录，具体由哪个LUN产生的，以及重启的原因：
Restarted at 2017-03-14 14:28:52 (1489501732.600511). UNKOWN_DEV, UNKOWN_UUID, o2quo_make_decision: TCP disconnected with other nodes.
Restarted at 2017-04-08 22:04:57 (1491689097.184531). dm-1, BE229C2491E64FEA98550DF0469B6C10, o2quo_disk_timeout: Disk heartbeat timeout.
重启问题需要排查中间链路，存储的访问是否正常。常见的排查策略，可从几个方面进行排查链路问题：
· 服务器，刀框的bios/firmware版本是否需要升级。
· VC刀框的配置是否合适。
· 服务器上IML硬件日志是否有硬件故障。
· 服务器/var/log/mcelog中是否报硬件异常。
· 连接FC交换机的FC光纤是否正常，可以通过交换机上查看对应接口光功率，crc错误等进行查看。
· 如果使用FC SAN，需要检查FC交换机上的配置是否一对一的端口zone，隔离不同HBA之间的影响。如果FC交换机做了堆叠，由于主机上对于LUN启用的多路径配置，建议取消FC交换机堆叠。对于某些型号的FC交换机，则需要考虑交换机的版本升级，请与交换机相关的技术支持进行确认。
· 如果使用IP SAN存储，需要查看主机对应物理网口的丢包情况，中间网线和交换机上是否有异常日志等信息。
· 在存储中检查是否有异常日志等信息，或者误操作等情况。
当服务器突然断电或出现其他异常情况时，共享文件系统存储在磁盘上的数据可能存在不一致性。这种问题可能会导致后续的共享文件系统使用异常。特别是在进行磁盘dd和fio等操作时，可能会导致磁盘损坏，需要进行修复，否则可能会在运行过程中发生数据丢失和服务器挂起等问题，从而导致业务中断。
用户业务中断，有数据丢失的风险。
服务器突然断电等异常。
(1) 需要在所有主机上暂停对应的共享文件系统。
(2) 以其中一台主机为例，采用命令进行预先检查，例如对于dm-0磁盘，执行fsck.ocfs2 -fn /dev/dm-0命令，并保存命令的输出。
(3) 执行修复命令（例如fsck.ocfs2 -fpy /dev/dm-0）进行修复。
(4) 待修复结束后，在所有的主机上激活存储池。
(5) 在所有的主机上启动对应的虚拟机业务。
· 出现需要修复处理，推荐优先联系技术支持人员远程处理。
· 需要记录操作的中间过程的信息输出，连同收集到的日志，一并发送给技术支持人员用于分析。
· 如果损坏严重，修复后还有可能无法使用，需要具体问题具体分析，请及时联系研发。
在管理平台中启动共享存储池时提示“存储池没有可用的slot”。
无法启动存储池，影响客户业务上线。
查看后台日志，确认挂载时是否有如下报错：
Error：Disk /dev/disk/by-id/dm-name-2225d000155a30dda had been mounted by other hosts，not need to format it。
如有，则是由于该存储卷已经挂给了其它集群的主机使用，系统后台检测到后该情况后，没有继续进行挂载。
将存储从另一平台中解除挂载，解除后，本平台即可正常挂载。
界面增加存储池时，选择所需添加的存储池时报错：“配置多路径失败，请检查或联系管理员。（错误代码：5106）”：
无法增加存储池，影响客户业务上线。
查看syslog日志，确认CAS识别的共享存储卷的WWID号与存储端设置的是否一致。如果不一致，说明存储侧在将所划的存储卷映射到CAS之后，存储端又对该存储卷进行了修改，使得WWID号发生了改变。如图所示：CAS识别到的wwid为~698，存储端的wwid为~699。
在每台主机中进行强制扫描存储的操作，重新识别存储端的配置。
主机或虚拟机出现网络问题，例如丢包或者用户网络业务不通等情况。
影响用户业务网络访问。
用户网络配置有误，或网络线路出现故障。
· 检查虚拟交换机聚合是否正常。
如上图所示，执行ovs-appctl bond/show命令可以查看虚拟交换机的聚合配置：
¡ 如果虚拟交换机使用的是静态主备聚合，则物理交换机不需要配置聚合组。
¡ 如果虚拟交换机使用的是静态负载分担聚合，要求物理交换机也配置静态聚合组，如交换机和服务器的聚合配置不一致，则会出现网络转发故障。
¡ 如果虚拟交换机使用动态聚合，则需要注意查看lacp_status状态。如果其状态是configured，则表示动态聚合协商失败，此时需要排查物理交换机聚合组的配置情况，包括聚合组类型、聚合组端口成员的正确性、以及端口是否处于select状态等情况。
· 检查虚拟交换机的物理网卡状态是否正确。从界面查询到虚拟交换机使用的物理网卡后，可以执行ifconfig ethx命令查看网卡的状态，例如：
网卡状态说明如下：
¡ <UP,BROADCAST,RUNNING,MULTICAST>：表示网卡正常UP，可以正常收发包；
¡ <UP,BROADCAST,MULTICAST>：表示网卡软件层面UP，但是链路层DOWN。此时可以使用ip link show dev ethx查看，如果网卡状态中有NO-CARRIER则表示网卡物理链路down，此时应该检查网卡插线是否有问题，如果是光卡，则可以尝试更换光纤或者光模块。
¡ <BROADCAST,MULTICAST>：表示网卡软件层面DOWN，可以尝试执行ifup ethx或ip link set dev ethx up命令，在软件层面将网卡UP。
· 检查网卡MTU是否正确，如MTU设置有误，可以在虚拟交换机界面进行修改。
· 网卡收发包是否存在丢包错包：如果存在丢包错包，则执行ifconfig ethx; sleep 10; ifconfig ethx命令查看丢包错包计数是否有增加。如果没有增加，说明计数是历史统计数据，可以忽略，如果有增加，则需要进行下一步的排查。
¡ dropped：表示数据包已经进入Ring Buffer，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。可以通过ethtool -G ethx rx xxx的方式增大网卡Ring Buffer的方式规避。注：修改网卡Ring Buffer会导致网卡短时中断，建议无业务时修改。
¡ overruns：Ring Buffer满，导致报文还没有到网卡的Ring Buffer时就被物理网卡丢弃，一般是CPU无法及时处理网卡中断引起。遇到此种情况，可以修改网卡中断的亲和性，将网卡中断放到空闲的CPU上处理。
¡ frame：接收到的CRC校验错误、且长度不是整字节数的报文的数量，这种情况建议更换网线/光纤和光模块。
¡ errors：所有收包错误数量的总和，报错：Ring Buffer溢出，too-long-frames错误，crc错误，overruns等。
· 检查虚拟网卡网络配置是否正确。在CVK主机后台执行/opt/bin/ovs_dbg_listports命令，获取CVK上当前网络拓扑信息，此网络拓扑信息在后续的问题排查中有很重要的作用。
¡ 检查VLAN配置是否正确：在CAS虚拟化网络拓扑图中，根据虚拟机的MAC地址（可在管理平台界面中查询），找到对应的vnetx设备后，可以查看虚拟网卡的VLAN配置，请核对是否和现网的业务要求相符。
¡ 检查IP/MAC绑定是否正确：在管理平台的修改虚拟机页面，找到对应的虚拟网卡，可以查看虚拟网卡是否配置了IP/MAC绑定：
IP/MAC绑定表示虚拟网卡绑定此IP后，此网卡只能使用绑定的IP发送数据报文，若使用其他的IP发送报文，则报文会被OVS流表拦截。
所以虚拟机内部有多个IP的场景，建议将IP/MAC绑定配置取消。同时也需要排查下绑定的IP与虚拟机内部的IP是否一致。
· 检查ACL/虚拟防火墙是否正确：ACL/虚拟防火墙配置不正确时，可能导致虚拟机发送的报文被OVS流表拦截。尤其是Cloud OS场景，需要排查与虚拟机不通的IP地址是否被安全组放行（OS默认白名单机制）。
· 检查是否开启虚拟机防病毒：防病毒异常场景，可能会导致虚拟机报文被防病毒拦截导致网络不通，或者虚拟机流量被防病毒限制导致带宽限速问题。
遇到此情况，可以尝试关闭防病毒，查看问题是否恢复。可执行service ds_am stop; service ds_agent stop; service ds_filter stop命令，关闭亚信防病毒。
· 抓包确认具体丢包位置：如果以上的所有方法均无法确认问题，可以通过抓包的方法，确认具体的丢包位置，锁定问题范围。
“check_network”脚本是在CAS虚拟化场景的通用抓包脚本，使用方法以及参数说明如下。
check_network.sh
[--vswitch=xxx]//指定需要抓包的vswitch，脚本会默认从vswitch，vswitch绑定的物理口抓包。
[--iface="vnet0,vnet1,vnet2,..."]//指定需要抓包的vnet设备。
[--iface_mac="0c:da:41:1d:f6:4b,0c:da:41:1d:1d:7d,..."]//可以通过mac指定需要抓包的虚拟机网卡。
[--ping=x.x.x.x]//同步在执行脚本的设备上发起ping任务，ping参数只支持指定一个ip。
[xxxxxxxxxxx]//指定抓包的过滤条件，防止pcap文件占用太大的空间，支持的条件请参考下方的example,上述参数均为可选参数，可以根据实际场景选择需要的参数。
dump example:
ARP: arp and host x.x.x.x
ICMP: icmp and host x.x.x.x
ICMP6: icmp6 and host x:x::x:x
DNS: port domain
DHCP: udp and port 67 and port 68
SSH: port 22 and host x.x.x.x
LLDP: ether proto 0x88cc
LACP: ether proto 0x8809
脚本使用方法举例：
¡ 问题1：偶现vswitch0故障告警。抓包方法如下所示。
- 在出现问题的CVK中执行/home/test/check_network.sh --vswitch=vswitch0 --ping=172.23.51.112 "icmp and host 172.23.51.112"命令。
--vswitch= vswitch0，指定使用虚拟交换机vswitch0来抓包。
--ping=172.23.51.112，表示脚本自动发起ping任务，ping的目的端为172.23.51.112。实际使用时，请指定成CVM的IP地址。
"icmp and host 172.23.51.112"，表示抓包的过滤条件，请将“172.23.51.112”替换为实际CVM的IP地址。
- 在CVM中执行/home/test/check_network.sh --vswitch=vswitch0 "icmp and host 172.23.51.114"命令。
无需--ping参数，因为在CVK中已经发起ping任务，所以不需要在CVM上重新发起ping任务。
--vswitch= vswitch0，同上。
"icmp and host 172.23.51.112"，表示抓包的过滤条件，请将IP地址替换为实际CVK主机的IP地址。
¡ 问题2：虚拟机凌晨虚拟机I/O大量飙升问题。该问题无明显指向，需排查I/O飙升时，虚拟机主要存在什么业务，所以需要抓取虚拟机的报文。
- 在虚拟机所在的CVK主机中执行/home/check_network/check_network.sh --iface_mac="0c:da:41:1d:f6:4b,0c:da:41:1d:1d:7d"命令。
-- iface_mac表示需要抓包的异常虚拟机的网卡MAC地址，可以指定多个MAC地址，中间用”,”隔开。虚拟机网卡的MAC地址可以在管理平台的虚拟机概要界面中查询。
- 脚本产生文件说明。
在/root/tcpdump/目录下，会生成相关的日志以及抓包文件。
-rw-r----- 1 root root 37 Jun 7 10:37 20230607103752-check_network.pid，记录check_network脚本运行生成的tcpdump以及ping任务的进程pid号。
-rw-r----- 1 root root 3313 Jun 7 10:37 20230607103752-ovs_dbg_listports，记录check_network脚本运行时的网络拓扑信息。
-rw-r----- 1 root root 1412 Jun 7 10:38 20230607103752-ping.log，ping任务日志。
-rw-r----- 1 root root 287 Jun 7 10:37 check_network.log，记录check_network脚本运行的日志。
drwxr-x--- 2 root root 4096 Jun 7 10:37 eth2，vswitch0绑定的物理网卡的抓包文件
drwxr-x--- 2 root root 4096 Jun 7 10:37 vnet0，指定的虚拟网卡的抓包文件
drwxr-x--- 2 root root 4096 Jun 7 10:37 vnet1，drwxr-x--- 2 root root 4096 Jun 7 10:37 vnet3，drwxr-x--- 2 root root 4096 Jun 7 10:37 vswitch0，vswitch0的抓包文件。
¡ 结束脚本任务。
查看check_network运行记录的pid文件，需要注意文件的时间戳信息。
cat /root/tcpdump/20230518100318-check_network.pid
2403 2405 2407 2408
执行kill命令，关闭上述pid文件中记录的pid，如kill 2403、kill 2405、kill 2407、kill 2408。
check_network.sh可多次运行，多次运行会产生多个pid文件，抓包结束后都需要手动kill pid文件中记录的pid。
抓包结束后，请一定即使结束抓包任务，避免持续抓包占用系统空间。
抓包结束后，请将/root/tcpdump目录打包发送给研发分析。
主机（以172.16.51.23为例）处于连接异常状态，查看主机的服务都是正常的；查看日志有连接该主机失败日志。SSH登录主机输入正确的密码，SSH无法连接并报密码不正确的错误。
无法正常链接主机。
在本地PC的网卡上开启抓包，同时在主机上的vswitch0上开启抓包，之后在PC上发起SSH请求，分析抓到的报文，示例如下。
· 本地PC上的请求报文如下，从报文中可以看到172.16.51.23对应的MAC地址是0c:da:41:1d:10:2e。
· 主机中未抓到请求报文，查看CVK中vswitch0的MAC地址是0c:da:41:1d:43:79，IP地址也是172.16.51.23。
· 上述分析发现局域网内部有两个设备都配置了IP地址172.16.51.23，导致IP地址冲突。
将存在IP冲突的地址重新配置为其他IP地址。
某局点现场发现从服务器（以192.168.12.19为例）ping物理交换机（以192.168.12.254为例）可以正常ping通，但是从物理交换机（192.168.12.254）ping服务器（192.168.12.19）出现时通时不通的现象。
用户网络出现丢包，影响虚拟化环境的稳定性。
组网示例如下：
在本例中，现场使用了UIS刀片服务器，并且刀箱内部使用了VC设备作为网络互联模块，刀片服务器的eth2和eth3分别连接VC#1和VC#2，VC#1和VC#2分别连接交换机SW#1和SW#2，SW#1和SW#2做IRF堆叠。
刀片服务器安装CAS系统，虚拟交换机vswitch1绑定eth2和eth3，并且配置静态主备负载分担聚合。eth2和eth3都开启了LLDP功能。
虚拟交换机vswitch1的IP地址为192.168.12.19，网关为192.168.12.254，该网关配置在物理交换机上。
(1) 发现从服务器（192.168.12.19）ping交换机（192.168.12.254）可以正常ping通，但是从交换机（192.168.12.254）ping服务器（192.168.12.19）出现时通时不通的现象。
(2) 进一步测试，发现当eth2网卡为主网卡时，CVK主机（192.168.12.19）与网关（192.168.12.254）互相均可以通信；主网卡为eth3时，网关ping主机时会出现丢包。因此重点分析eth3作为主链路时的报文转发情况。
¡ CVK主机（192.168.12.19）到网关（192.168.12.254）的报文的流程为：“vswitch1-eth3-VC#2-SW#2”。
¡ vswitch1的MAC地址“FC:15:B4:1C:AD:79”会记录在VC#2的下行口和SW#2的下行口。
¡ 网关（192.168.12.254）到CVK主机（192.168.12.19）的报文会根据SW#2和VC#2的MAC地址表项转发，流程为：“SW#2-VC#2-eth3-vswitch1”。
(3) 使用tcpdump命令对网卡eth2进行抓包，并保存报文。
(4) 将报文保存到本地PC，使用Wireshark工具分析报文，可以看到虽然网卡eth2状态为备链路，但仍在不停的发送LLDP_multicast报文（网卡eth2上开启了LLDP），报文信息如下所示：
LLDP_multicast报文的MAC地址为：FC:15:B4:1C:AD:79。
(5) eth3为主链路时，虚拟交换机vswitch1（mac: FC:15:B4:1C:AD:79）的MAC应该学习到SW#2和VC#2，但是网卡eth2（MAC也是FC:15:B4:1C:AD:79）会定时发送LLDP_multicast，从而影响VC#1上的MAC地址表项信息，导致MAC FC:15:B4:1C:AD:79漂移到了VC#1和SW#1，网关ping主机的报文会按照SW#1-VC#1-eth2的路径发送，此时eth2的状态为备用状态，不处理报文，OVS直接丢弃报文，导致ping不通。
关闭物理网卡的LLDP功能即可恢复。
虚拟机可以正常访问其他地址，但是无法访问网关（以172.16.51.6为例）。
用户虚拟机业务受影响。
报文转发路径为：虚拟机网卡-vent-主机网卡-物理交换机。在vnet和主机网卡eth0上抓包发现如下现象。
vnet上已经收到了icmp请求报文，但是eth上没有抓到。
通过如下方法，可以查看vnet上的ACL配置：
(1) 执行ovs_dbg_listports命令，可以查看vnet所属虚拟机。
(2) 执行virsh dumpxml vm_name命令，可以查看虚拟机的XML文件，可以找到interface节点，可以查看到如下信息：
<interface type='bridge'>
<mac address='0c:da:41:1d:56:a7'/>
<source bridge='vswitch0'/>
<vlan>
<tag id='1'/>
</vlan>
<virtualport type='openvswitch'>
<parameters interfaceid='bfcd8333-2282-4d08-a0bb-cc14a37ff1e9'/>
</virtualport>
<target dev='vnet0'/>
<model type='virtio'/>
<driver name='vhost'/>
<hotpluggable state='on'/>
<filterref filter='acl-test'/>//acl的名称
<priority type='low'/>
<mtu size='1500'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
(3) 执行virsh nwfilter-dumpxml acl_name命令，可以查看acl的具体内容。
root@cvknode112:~# virsh nwfilter-dumpxml acl-test
<filter name='acl-test' chain='root'> ACL名称acl-test
<uuid>41f62fca-275b-4a72-8ad8-515d9e9589c1</uuid>
<rule action='accept' direction='in' priority='4' statematch='false'> //入方向默认放行
<all/>
</rule>
<rule action='accept' direction='out' priority='5' statematch='false'>//出方向默认放行
<all/>
</rule>
<rule action='accept' direction='in' priority='6' statematch='false'>//入方向默认放行
<all-ipv6/>
</rule>
<rule action='accept' direction='out' priority='7' statematch='false'>//出方向默认放行
<all-ipv6/>
</rule>
<rule action='drop' direction='in' priority='10' statematch='false'>
<icmp dstipaddr='172.16.51.6' dstipmask='32'/>//丢弃目的地址为172.16.51.6的icmp报文
</rule>
</filter>
(4) 分析ACL规则，可以知道是，OVS的ACL规则将报文丢弃。
root@cvknode112:~# ovs-appctl dpif/dump-flows vswitch0 | grep "172.16.51.6"
recirc_id(0),in_port(8),eth_type(0x0800),ipv4(dst=172.16.51.6,proto=1,tos=0/0xfc,frag=no), packets:10426, bytes:1021748, used:0.369s, actions:drop
(5) 查看ovs的内核流表项，也可以看到报文被drop的信息。
修改虚拟机的ACL配置。
两个虚拟机都配置了虚拟防火墙，它的策略中不存在阻止SSH的规则，并且虚拟机配置了相同的VLAN，但虚拟机之间不能通过SSH互访。
虚拟机之间不能SSH互访，影响用户网络业务。
如果虚拟机网卡都绑定在vs-app上，虚拟机都配置相同的VLAN为188及虚拟机防火墙FW_white，如下图所示。
其中两个虚拟机的用户态流表如下：
通过对比发现，流表中zone的值不一样，一个为188，一个为0，正常情况下都应该是188，zone值不同导致SSH失败。
需要通过set_cvm_port_flow.sh以及set_cvk_port_flow.sh脚本进行修复。
· 在CVM中使用set_cvm_port_flow.sh命令执行脚本。具体操作方法如下：
a. 上传脚本set_cvm_port_flow.sh、set_cvk_port_flow.sh到CVM主机的同一目录下
b. 执行bash set_cvm_port_flow.sh脚本，会给所有cvk上传脚本set_cvk_port_flow.sh到/opt/bin/目录下。
c. 执行完成后，在/var/log/set_cvk_port_flow.log查看日志，根据日志可以看出是否存在流表error被修复的情况。
· 在CVK中执行set_cvk_port_flow.sh命令，可以针对某个具体的虚拟机端口进行flow的修复，也可以不加参数对所有虚机端口进行flow的修复。具体操作方法如下：
bash /opt/bin/set_cvk_port_flow.sh vnetx (参数不对时，会有提示)
bash /opt/bin/set_cvk_port_flow.sh aa:bb:cc:dd:ee:ff(参数不对时，会有提示)
bash /opt/bin/set_cvk_port_flow.sh
· 备注：
¡ set_cvm_port_flow.sh脚本只能在CVM上执行，脚本无参数，说明如下：
¡ script can only run on CVM!
¡ example:
¡ set_cvm_port_flow.sh check whether the virtual port configuration vfirewall and flow table are correct on cvm and cvk。
¡ 所有cvk上都有定时任务，每天23:00，会自动执行以下脚本set_cvk_port_flow.sh，如果出现虚机flow不对的情况，会自动修复。
¡ cvk日志说明如下：
-----------------------------------------2022/08/29 11:21:50-------------------------------------
cvknode116 vnet0 of vswitch0 is config FW, the flow table is correct, do not need revalidate flow
（配置状态防火墙，流表正确，不需要重刷流表）
cvknode116 vnet1 of vswitch0 is not config FW, do not need revalidate flow
cvknode116 vnet2 of vswitch0 is config FW, the flow table is error, do need revalidate flow
（配置状态防火墙，流表错误，需要重刷流表）
cvknode116 vnet3 of vswitch0 is config FW, the flow table is correct, do not need revalidate flow
cvknode116 vnet4 of vswitch0 is not config FW, do not need revalidate flow
（没有配置状态防火墙，不需要重刷流表）
cvknode116 vnet5 of vswitch0 is not config FW, do not need revalidate flow
cvknode116 vnet6 of vswitch0 is not config FW, do not need revalidate flow
-----------------------------------------2022/08/29 11:21:50-------------------------------------
主机中存在病毒，并且该病毒尝试向外部建立大量的非连接，这可能会导致网络资源的大量消耗，并最终导致网络故障。
用户业务网络受影响。
使用tcpdump进行抓包，判断环境是否存在异常的流量，异常流量可能具有以下特点：
· 发起DNS解析请求。
· 发起TCP SYN请求，但一般都不会建立连接。
· 目的IP不是用户自己环境里的，属于一些数据中心。
· 量大。
执行netstat –atunp命令查看是否有异常的进程在尝试建立网络连接。异常的进程可能具有以下特点。
· 连接的外部地址IP，非用户环境的IP。
· 进程名伪装成一些常用程序名：如“cd”，“ls”，“echo”，“sh”等。
· 如果CVK与外网不通，连接状态可能一直处在SYN_SENT。
执行top -c命令查看是否有异常的进程。异常进程可能有以下特点：
· CPU或内存占用高。
· 进程伪装成一个常用程序名。
查看/etc/crontab文件，看是否被添加了异常定时任务。目前CVK上有以下一些定时任务，这些范围外的，可以认为是被人篡改。
· 更换主机密码。
· 删除异常进程，并删除磁盘上进程可执行文件。
· 删除/etc/crontab中的异常任务。
· 重装CVK。
银河麒麟虚拟机配置DNS后，重启主机，配置失效。
影响用户虚拟机网络。
银河麒麟操作系统虚拟机的DNS配置文件位于“/etc/resolv.conf”，这是一个软链接文件。
可删除当前软链接文件“/etc/resolv.conf”，并重新创建一个新文件“/etc/resolv.conf”，再在新文件中添加所需的DNS配置信息。
Ubuntu 20及之后版本的操作系统，配置IPv4地址时，管理平台中报错：修改虚拟机xxx配置失败。原因：通过CAStools配置IPV4和IPV6网络信息错误。
Ubuntu 20以及之后的版本操作系统的虚拟机，无法在管理平台页面中配置网络。
配置IPv4地址时，系统会在最后设置MTU值，如果/var/log/set-ipv6.log日志中有“Can not find /etc/netplan/tools-netcfgv6.yaml to update mtu”异常报错，则会异常退出脚本的调用，导致无法配置IP地址。
在虚拟机后台手动新建文件/etc/netplan/tools-netcfgv6.yaml；或者尝试先配置IPv6地址，然后再配置所需的IPv4地址。
主机出现网卡故障告警。
用户业务受影响。
排查网卡是否人为down掉、链路是否断开、协商是否正常、查看syslog中是否存在存在网卡的错误日志。
根据情况相对应的进行up网卡、解决链接和协商问题、升级网卡固件、更换硬件等操作，尝试恢复。
主机出现MCE故障告警，后台查看/var/log/mce.log存在报错或告警。
该主机出现硬件故障，需进行紧急修复。
可能是主机服务器内存、主板等硬件故障，需检查服务器硬件日志是否存在异常。
尽快将虚拟机迁移至其他主机，并将该主机隔离，更换故障硬件。
前台界面无法正常登录。
前台界面无法正常登录，无法完成对平台的管理。
管理平台页面的相关服务可能出现异常。
通过SSH登陆CVM节点后台，执行service tomcat8 status命令，查看tomcat8是否正常运行。
· 如果tomcat8处于关闭状态，则执行service tomcat8 restart命令重启tomcat8。
· 如果tomcat8处于运行状态，执行ps -ef | grep tomcat8命令获取tomcat8的PID。
执行jstack -l PID > /vms/文件名称命令，获取tomcat8堆栈文件。
执行jmap -dump:format=b,file=/vms/文件名 PID命令，获取tomcat8内存映像。
执行service tomcat8 restart命令重启tomcat。
将上述收集文件交给工程师方便定位问题。
¡ 日志中报rabbitmq初始化失败：rabbitmq服务正常（执行service rabbitmq-seerver status命令查看），系统时间不对，早于2021年5月。尝试修改系统时间为当前时间，重启主机。
¡ rabbitmq服务异常，报错“Too short cookie string”，参考下图。
- 排查磁盘根目录（/）是否已满.
- 删除/var/lib/rabbitmq/.erlang.cookier文件。
¡ 启动rabbitmq（执行service rabbitmq-server start命令），查看cloud用户权限。
如果cloud用户权限不对，需要重新初始化rabbitmq用户权限，执行更新包中的脚本：rabbitmq-init.sh。
¡ rabbitmq服务异常，执行rabbitmq-server命令启动rabbitmq服务，报日志目录（/var/log/rabbitmq）权限不足，参考下图：
手动创建rabbitmq日志目录：/var/log/rabbitmq。
如果有该目录，尝试赋值（rabbitmq用户）权限。
¡ 启动rabbitmq服务。rabbitmq服务异常，尝试执行rabbitmq-server命令启动，启动需时很长，最终超时，可参考下图。
- 排查iptables中禁用了rabbitmq需要的端口号：4369和5672。
- 检查iptables规则，放行rabbitmq需要的端口。
- 启动rabbitmq服务。
前台界面无法正常打开，日志中报连接数据库失败。
前台界面无法正常登录，无法完成对平台的管理。
· 系统异常断电导致数据库服务异常。
· 数据库文件权限错误。
· 数据库空间满。
· 断电导致数据库服务无法启动，请参考《CAS云计算管理平台 MySQL服务无法启动快速处理方法》处理；
· 数据库数据目录、日志目录以及其中的文件属主需为mysql，若不是，则执行chown mysql:mysql -R /var/lib/mysql（双机为/var/lib/mysql-share）命令修改属主，/var/log/mariadb目录需做相同处理。
· 空间满导致的创建表失败，请参照《关于CAS、UIS、Workspace产品MariaDB数据库ibdata1文件空间占用大导致数据库服务异常的技术公告》处理。
前台界面查看虚拟机、存储池等信息卡住，无法继续正常操作。
前台界面卡住，无法正常进行管理操作。
· 存在销毁虚拟机、备份、快照等未完成的任务。
· 存储IO压力较大。
· 储发生故障，如fence umount。
· 等待任务完成后再操作，前台任务台上可查看任务进度。
· 可参考4.2.1章节解决存储IO压力大的问题。
· 在系统后台检查存储池是否正常，排查存储故障。
虚拟机内部操作卡顿问题，并且管理平台界面中虚拟机图标变为蓝色，不能修改虚拟机，不能访问VNC控制台，无法ping通虚拟机网络。
影响用户虚拟机业务。
· 虚拟机磁盘所在存储池异常，导致磁盘的读写不能返回，qemu主进程一直在等待内核层的返回结果。
· 虚拟机开启了防病毒，而防病毒模块的后端驱动（杀毒厂商在CVK上安装的软件）异常，导致qemu进程在等待内核层返回。
· 云桌面环境中，一般使用spice组件。该组件需要虚拟机qemu进程配合，如果组件异常，会导致qemu的调用一直不能结束，引起阻塞。
· 虚拟机在线迁移存储时会对虚拟机磁盘限速，导致虚拟机内部运行速度慢，这种情况是正常现象。
· 虚拟机磁盘大小一般为若干TB，而虚拟机内部某些业务容易产生磁盘碎片，当碎片率达到50%及以上时，再做快照操作，就会引起虚拟机内部卡顿，该问题是qcow2格式磁盘自身的缺陷。
· 由虚拟机上的其他有问题的设备引起，例如：USB设备异常。
· 如果虚拟机正在做迁移存储、或者删除快照操作，虚拟机运行速度慢是正常现象，尤其是磁盘数据量达到TB级别时。
· 查看虚拟机运行态配置，确定虚机有什么不常用的配置，如虚机开启了杀毒、挂载ukey、U盘、移动硬盘等USB设备、是否有透传设备等，可以查看虚拟机qemu日志（/var/log/libvirt/qemu/虚拟机名称.log），看看异常时间点前后有哪些报错信息，可初步了解虚拟机到底是哪个设备出问题。
· 执行ps aux | grep 虚拟机名称命令，查看其是否为D状态或Z状态。
· 执行top –c –H –p 虚拟机qemu进程pid命令，看进程的CPU、memory使用率是否异常。执行cat /proc/虚拟机qemu进程pid/stack命令，可以查看进程栈。
将USB设备插到主机后，在管理平台中为虚机添加USB设备时找不到该设备。
无法使用USB设备。
· USB插入的插槽不正确。
· USB设备本身存在问题。
更换USB插槽，可通过执行lsusb –t命令，检查USB设备插入的插槽是否正确。例如：
root@cvk-163:~# lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
命令返回结果里的UHCI表示USB1.1、EHCI表示USB2.0、XHCI表示USB3.0。一般USB1.1最大传输速率为12Mbps，USB2.0最大传输速率为480Mbps，USB3.0最大传输速率为5Gbps。
如果服务器支持多种USB总线标准，给服务器添加一个USB2.0设备后，在USB2.0（ehci-pci）的总线下新增一个USB设备，则说明USB设备插的插槽是正确的。
如果进行上述操作后，仍然无法正常识别，则在拔插USB设备前后，执行lsusb命令查看是否有新增设备，例如：
root@ CVK:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 002: ID 03f0:7029 Hewlett-Packard
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
如果无新增设备，说明系统识别不到，建议更换USB设备再进行尝试。
CVM主机向过去修改超过10天的时间，集群开启HA时失败，任务台报“HA进程响应超时”。
无法开启集群高可靠性功能。
后台HA进程连接数据库失败，导致HA进程无法正常启动。日志有报如下错误信息：SSL connection error: protocol version mismatch。
· 将主机时间修改为与当前时间一致。
· 在文件/etc/mysql/mysql.conf.d/mysqld.cnf中增加skip_ssl选项。
在应急恢复操作完成后，需要需要收集故障信息作为处理故障的参考，或者作为将故障信息提供给H3C技术支持人员，以便彻底定位和排除故障。
请参考《H3C CAS云计算管理平台 系统日志手册》收集故障相关的日志信息。
(1) 选中顶端的“系统”页签，单击左侧导航树中的[操作日志/日志文件收集]菜单项，进入收集日志文件页面。
(2) 在日志文件收集区域，输入物理主机日志文件大小，选择物理主机日志时间范围，并选择一个或多个主机，单击<日志文件收集>按钮，开始收集日志文件。
(3) 收集完成后，单击<日志文件下载>按钮，单击<下载>按钮将日志文件下载到本地保存。
(1) 在管理平台中，选择顶部“监控告警”页签，单击导航树中[告警管理/实时告警]菜单项，进入实时告警列表页面。单击<告警信息>按钮，将弹出查看告警详细信息对话框。
图3 查看实时告警信息
(2) 设置过滤查询参数后，单击<查询>按钮查询符合要求的告警信息。单击
按钮，下载当前告警列表。
支持
售前咨询
售后咨询
人工在线咨询
