目  录

1 概述

2 Web类高危操作

2.1 页面配置

2.1.1 EAD终端智能接入模块批量加入黑名单

2.1.2 批量强制下线在线用户

2.1.3 下发ACL

2.1.4 LDAP服务器故障时逃生

2.1.5 MSCHAPv2 Server进程重启

2.1.6 LDAP同步时自动删除已经不存在的用户

2.1.7 同步转移接入服务(手工指定)

2.1.8 同步转移接入服务(按AD组)

2.1.9 按用户分组申请服务立即生效

2.1.10 LDAP同步处理阈值

2.1.11 安全策略安全级别为加入黑名单并下线

2.1.12 外设管理策略禁用USB存储设备

2.1.13 外设管理策略禁用USB非存储设备

2.1.14 EAD鹰视端点探测模块加入黑名单

2.1.15 修改网卡IP和北向IP地址

2.1.16 修改统一数字底盘的端口和协议

2.1.17 使用外置文件备份服务器

2.1.18 断开授权连接

2.1.19 系统访问控制

2.1.20 修改系统时间

2.1.21 系统重启/关机/异常断电/硬关机

2.1.22 服务器异常断电

2.1.23 ETCD分区磁盘IOPS不满足要求引起的环境异常

2.1.24 修改SSH服务端口号

2.1.25 手动修改/etc/resolv.conf文件导致节点异常

2.1.26 使用未适配过系统安装环境

2.1.27 主机名/hosts文件修改

2.2 系统高危操作

2.2.1 重启Pod

1 概述

高危操作只能由有资质且经过培训的维护人员执行。如果操作不当，可能会导致设备断电、设备重启、业务中断、业务运行异常、重要文件被删除、所有配置被清除、用户无法登录、用户下线等现象发生。

在进行高危操作之前，请先了解可能带来的风险并申请变更窗口后再进行操作。

2 Web类高危操作

2.1  页面配置

2.1.1  EAD终端智能接入模块批量加入黑名单

1. 操作后果

被批量加入黑名单的用户无法通过认证上网，请谨慎使用。

2. 操作步骤

(1)     单击[自动化>网络准入>准入管理>接入用户]菜单项。

(2)     在接入用户列表中，选中账号名复选框，可多选。

(3)     单击接入用户列表中的<加入黑名单>按钮。

(4)     在弹出的对话框中单击<确认>按钮，将所选的单个或多个用户加入黑名单。

图1 批量加入黑名单

 

图2 提示对话框

 

2.1.2  批量强制下线在线用户

1. 操作后果

被批量强制下线的在线用户会掉线，请谨慎使用。

2. 操作步骤

(1)     单击[自动化>网络准入>准入管理>在线用户]菜单项，进入在线用户列表页面。

(2)     勾选在线用户账号名复选框，可多选。

(3)     单击<强制下线已选用户>按钮。

(4)     在弹出的对话框中单击<确认>按钮，将所选的一个或多个本地在线用户强制下线。

图3 批量强制下线

 

图4 提示对话框

 

2.1.3  下发ACL

1. 操作后果

ACL下发不合理会导致终端和认证服务器通信异常，可能导致大量用户掉线，请谨慎使用。

2. 操作步骤

(1)     单击[自动化>网络准入>准入管理>接入服务>接入策略]菜单项。所有接入策略都显示在接入策略列表中。

(2)     在接入策略列表页面中，单击<增加>按钮，进入接入策略增加页面。

(3)     配置授权信息，勾选“下发ACL”，如下图所示。

图5 下发ACL

 

2.1.4  LDAP服务器故障时逃生

1. 操作后果

开启“LDAP服务器故障时逃生”功能后，当服务器与LDAP服务器通信异常或者LDAP服务器故障时，LDAP用户仍然会认证成功，请谨慎使用。

2. 操作步骤

(1)     单击[自动化>网络准入>准入管理>LDAP配置>参数配置]菜单项，进入LDAP参数配置页面。

(2)     启用LDAP服务器故障时逃生功能，如下图所示。

图6 LDAP服务器故障时逃生

 

2.1.5  MSCHAPv2 Server进程重启

1. 操作后果

MSCHAPv2 Server进程重启操作将发送停止进程的消息给MSCHAPv2 Server进程，后续由监控代理自动将MSCHAPv2 Server进程启动。该进程重启过程中将影响MSCHAPv2 Server认证，请谨慎使用。

2. 操作步骤

(1)     单击[自动化>网络准入>准入管理>LDAP配置>参数配置]菜单项，进入LDAP参数配置页面。

(2)     单击“MSCHAPv2 Server进程重启”对应的<重启>按钮。

(3)     在弹出的对话框中单击<确认>按钮。

图7 MSCHAPv2 Server进程重启

 

图8 提示对话框

 

2.1.6  LDAP同步时自动删除已经不存在的用户

1. 操作后果

启用该参数，则在执行LDAP同步时自动删除物理LDAP服务器上已经不存在的用户，请谨慎使用。

2. 操作步骤

(1)     单击的[自动化>网络准入>准入管理>LDAP配置>参数配置]菜单项，进入LDAP参数配置页面。

(2)     启用“LDAP同步时自动删除已经不存在的用户”功能，在对应下拉框中选择“允许”，如下图所示。

图9 LDAP同步时自动删除已经不存在的用户

 

2.1.7  同步转移接入服务(手工指定)

1. 操作后果

启用该参数，则同步用户时申请LDAP同步策略指定的服务，该参数仅对服务同步方式为“手工指定”的LDAP用户生效。接入服务的改变可能会对用户认证产生影响，请谨慎使用。

2. 操作步骤

(1)     单击[自动化>网络准入>准入管理>LDAP配置>参数配置]菜单项，进入LDAP参数配置页面。

(2)     启用“同步转移接入服务(手工指定)”功能，在对应下拉框中选择“允许”，如下图所示。

图10 同步转移接入服务(手工指定)

 

2.1.8  同步转移接入服务(按AD组)

1. 操作后果

启用该参数，则同步用户时申请LDAP同步策略里AD组指定的服务，该参数仅对服务同步方式为“基于AD组”的LDAP用户生效。接入服务的改变可能会对用户认证产生影响，请谨慎使用。

2. 操作步骤

(1)     单击[自动化>网络准入>准入管理>LDAP配置>参数配置]菜单项，进入LDAP参数配置页面。

(2)     启用“同步转移接入服务(按AD组)”功能，在对应下拉框中选择“允许”，如下图所示。

图11 同步转移接入服务(按AD组)

 

2.1.9  按用户分组申请服务立即生效

1. 操作后果

启用该参数，则当接入用户（服务同步方式为基于AD组的LDAP用户除外）在用户分组间转移或所属用户分组指定的服务发生变化时，立即为接入用户重新申请用户分组指定的服务。接入服务的改变可能会对用户认证产生影响，请谨慎使用。

2. 操作步骤

(1)     单击[自动化>网络准入>准入管理>参数配置>系统参数]菜单项，进入系统参数配置页面，配置参数“按用户分组申请服务”为“启用”，在弹出的对话框中单击<确认>按钮。

图12 系统参数配置页面

 

图13 按用户分组申请服务

 

 

(2)     配置参数“按用户分组申请服务立即生效”为“启用”，如下图所示。

图14 按用户分组申请服务立即生效

 

2.1.10  LDAP同步处理阈值

1. 操作后果

该参数决定在LDAP用户同步时，如何处理不存在的LDAP用户。当不存在的用户数量大于该参数值时，对不存在的LDAP用户进行注销或置为不存在状态。但考虑到可能是异常情况导致查询不到数据，所以一般不进行任何处理，该参数缺省为100，该操作涉及用户的注销，请谨慎使用。

2. 操作步骤

(1)     单击[自动化>网络准入>准入管理>LDAP配置>参数配置]菜单项，进入LDAP参数配置页面。

(2)     修改LDAP同步处理阈值，如下图所示。

图15 LDAP同步处理阈值

 

2.1.11  安全策略安全级别为加入黑名单并下线

1. 操作后果

请注意该配置可能会导致用户无法认证上线。

2. 操作步骤

(1)     单击[自动化>网络准入>准入安全管理>安全策略]菜单项，配置准入安全策略，安全级别选择加入黑名单并下线，如下图所示。安全检查不通过时，系统会将用户加入黑名单并下线，记录安全日志。

图16 安全级别

 

2.1.12  外设管理策略禁用USB存储设备

1. 操作后果

请注意该配置可能会导致U盘、移动硬盘、读卡器等USB存储设备无法使用。

2. 操作步骤

(1)     单击[自动化>网络准入>桌面资产管理>控制策略>外设管理策略]菜单项，单击<增加>按钮进入增加外设管理策略。

(2)     在禁用设备区域，勾选“USB存储设备”，如下图所示。支持通过添加USB存储设备白名单进行禁用规避。

(3)     单击<确定>按钮完成操作。

图17 禁用USB存储设备

 

2.1.13  外设管理策略禁用USB非存储设备

1. 操作后果

请注意该配置可能会导致鼠标、键盘等USB非存储设备无法使用。

2. 操作步骤

(1)     单击[自动化>网络准入>桌面资产管理>控制策略>外设管理策略]菜单项，单击<增加>按钮进入增加外设管理策略。

(2)     在禁用设备区域，勾选“USB非存储设备”，如下图所示。支持通过添加USB非存储设备白名单进行禁用规避。

图18 禁用USB非存储设备

 

 

(3)     单击<确定>按钮完成操作。

2.1.14  EAD鹰视端点探测模块加入黑名单

1. 操作后果

生产环境中启用该配置，可能会导致大量新发现端点被阻断并加入黑名单，请谨慎使用。

2. 操作步骤

(1)     单击[自动化>网络准入>终端感知>联动管理>联动参数]菜单项，进入联动参数页面。

(2)     在联动参数页面，配置黑名单联动准入参数。

¡     加入黑名单方式选择“EIA联动”，业务场景选择“安全优先”，并启用“新发现端点自动加入黑名单”，如下图所示。

图19 加入黑名单1

 

¡     加入黑名单方式选择“扫描器联动”，业务场景选择“安全优先”，并启用“非直连端口加入黑名单”、“新发现端点自动加入黑名单”，如下图所示。

图20 入黑名单2

 

 

¡     加入黑名单方式选择“安全网关联动”，业务场景选择“安全优先”，并启用“新发现端点自动加入黑名单”，如下图所示。

图21 EPS加入黑名单3

 

 

2.1.15  修改网卡IP和北向IP地址

1. 高危操作

修改网卡配置文件里的IP地址后，重启操作系统，将导致“修改”集群的按钮置灰，无法进行下一步的修改。

将网卡配置文件中的IP地址修改后，先执行ifdown禁用网卡，等待超过30分钟再执行ifup启用网卡时，存在小概率会导致使用新IP无法访问Matrix页面。

2. 原理说明

修改网卡的IP地址后，重启了操作系统，将导致修改集群的按钮置灰，无法进行下一步的修改。

3. 推荐操作/规避方法

修改网卡配置文件里的IP后，不要重启操作系统，只需要重启网卡即可。并且建议在5分钟内使用新的网卡IP登录Matrix页面进行下一步的修改。

如果已经重启了操作系统，导致“”修改”按钮置灰，需要先将网卡IP改回原值，并执行systemctl restart matrix.service重启Matrix服务，恢复到初始状态后，再按标准流程重新修改IP。

如果在修改后出现使用新网卡IP无法访问Matrix页面的问题，同样可以通过执行systemctl restart matrix.service重启Matrix服务来恢复访问。

 

2.1.16  修改统一数字底盘的端口和协议

修改统一数字底盘的端口和协议需要同步修改扫描器配置的端口和协议，否则会影响扫描器扫描。

2.1.17  使用外置文件备份服务器

使用外置文件备份服务器时，需要与服务器保持持续连接，否则会导致备份文件失败或下载备份文件失败。

2.1.18  断开授权连接

1. 操作后果

断开授权连接后会导致环境中需要授权的菜单无法访问，如监控菜单等，如需执行该操作，请提前确认。

2. 操作步骤

单击导航树中的[系统>License管理>License信息]菜单项，单击<断开连接>按钮。

2.1.19  系统访问控制

1. 操作后果

只有系统访问控制列表内的IPv4或IPv6地址才能访问系统，请谨慎操作。

2. 操作步骤

单击[系统>系统配置>安全配置>系统访问控制]菜单项，单击<增加>按钮，如下图所示。

图22 系统访问控制

 

2.1.20  修改系统时间

1. 高危操作

直接使用date命令向前调整操作系统时间，可能导致系统时间发生跳变，引发Docker服务异常，并可能导致统一数字底盘页面无法访问，页面报未知错误。

2. 原理说明

修改系统时间时，请确保目标时间始终处于Kubernetes所有组件证书的有效期内，包括向前和向后调整时间的所有方式（包括通过NTP同步及直接修改操作系统时间）。否则可能导致平台不可用。

Kubernetes集群对节点时间有严格要求，这主要源于其作为分布式系统的核心特性。时间发生变化或不一致会引发一系列关键问题，影响集群的稳定性与可靠性。可能导致的问题：

·     证书与安全通信故障：Kubernetes组件（如kube-apiserver、kubelet）之间广泛使用基于TLS的证书进行双向认证和安全通信。这些证书都有明确的有效期。如果节点时间严重偏离真实时间，可能导致在证书有效期内被判定为过期或尚未生效，从而造成组件间通信中断，节点被标记为不可用。

·     事件记录与日志混乱：Pod事件、资源变更、审计日志等都依赖时间戳进行排序和关联分析。节点时间不一致会使跨节点的日志时间线错乱，严重影响故障排查、监控告警和合规性审计。

·     调度与控制器逻辑紊乱：一些控制器（如CronJob、Deployment的滚动更新）以及调度器本身的部分决策逻辑依赖于时间计算。时间漂移可能导致任务在错误的时间被触发、副本集状态判断失误或资源调度出现非预期行为。

·     有状态工作负载和数据一致性风险：在Kubernetes上运行的分布式中间件（如Etcd、ZooKeeper、Kafka、Redis Cluster、各类数据库）通常内置了基于超时的心跳、租约（Lease）和领导者选举机制（如Raft协议）。这些机制对时间极其敏感。

¡     心跳超时：时间过快或过慢的节点可能过早或过晚地判定主节点失活，从而触发不必要的领导者选举，导致服务短暂中断。

¡     数据一致性：依赖时间戳的事务、多版本并发控制（MVCC）或冲突解决机制可能因时间错乱而产生数据不一致、丢失或损坏。

·     容器运行时创建容器名称冲突：时间发生修改会导致Kubernetes kubelet层面出现容器名冲突的问题，根本原因也是kubelet要根据时间去创建容器id，改了时间就可能导致id创建冲突。

3. 推荐操作/规避方法

修改指定NTP服务器的时间（包括外置或者内置），请先在系统后台执行：docker ps -q | xargs docker inspect --format '{{.Created}},{{.Name}},{{.Id}}'|sort -k 1 -rn|sed -n 1p|awk -F , '{print $1}'命令获取集群内最新一个容器的创建时间（如2024-9-13 16:24:39Z），然后按照下面步骤处理：

·     若修改的目标时间晚于当前时钟源时间，可直接进行时钟源修改（如目标时间是2024-9-13 19:24:39Z，当前时钟源时间是2024-9-13 18:24:39Z）。

·     若修改的目标时间早于当前时钟源时间，但是晚于集群内最新一个容器的创建时间，可以继续进行修改（如目标时间是2024-9-13 17:24:39Z，当前时钟源时间是2024-9-13 18:24:39Z）。修改后需要重启操作系统。

·     若修改的目标时间早于当前时钟源时间，也早于集群内最新一个容器的创建时间（如目标时间是2024-9-13 15:24:39Z，当前时钟源时间是2024-9-13 18:24:39Z），则需要等待修改的目标时间超过最新一个容器的创建时间后再进行修改，否则将会导致平台不可用。

若环境已连续运行7天，需要将系统时间往前调整，且“回退时间”小于环境已运行时长（如仅回退2天），则允许直接回退时间。时间修改完成后必须重启操作系统；若不重启，将导致统一数字底盘页面无法访问并报“未知错误”。

若环境刚上电仅运行约5小时，却需要将时间往前回退8小时（即回退时间大于环境运行时长），此时禁止直接回退系统时间，否则会导致平台异常。建议先让环境继续运行一两天，再进行时间回退操作，并在修改时间后重启操作系统。

2.1.21  系统重启/关机/异常断电/硬关机

1. 高危操作

·     如果直接使用reboot、shutdown、poweroff等命令，或直接断电导致操作系统重启/关机，可能会造成Docker服务无法启动、containerd服务异常、Matrix进入紧急模式。

·     系统节点如果频繁断电重启，或长时间处于网络异常状态，可能会导致Prometheus无法正常启动。

·     在三机集群环境中，重启主节点后，可能出现启动约20分钟内，通过统一数字底盘页面登录时提示“用户名不存在或密码错误”的情况。

2. 原理说明

·     服务器异常断电、关机或重启操作，有一定概率导致系统文件损坏，进而引起平台功能异常，部分组件业务无法正常使用等问题。

·     在服务器频繁重启或网络延迟较大的情况下，Prometheus会不断重启并持续生成大量WAL文件。当WAL文件累积过多时，即使服务器恢复正常，Prometheus在启动时仍需加载全部WAL文件，导致内存占用剧增。由于默认内存限制不足，会触发OOM，导致Prometheus无法正常启动并反复重启。

3. 推荐操作/规避方法

 

低版本统一数字底盘关机方法：执行优雅关机脚本关机

统一数字底盘版本为E7105，需要按照如下步骤执行优雅关机脚本进行关机。

(1)     将如下附件gracefully-shutdown.zip上传到环境的（集群环境的每一个节点）/opt/matrix/tools/目录下，然后进入此目录cd /opt/matrix/tools/ ;解压sudo unzip gracefully-shutdown.zip。

(2)     将如下附件tools.zip上传到环境的（集群环境的任意一个节点）/opt/matrix/app/install/metadata/UNIFIED-PLATFORM-BASE/scripts目录下，然后进入此目录cd /opt/matrix/app/install/metadata/UNIFIED-PLATFORM-BASE/scripts ; 解压unzip tools.zip;

(3)     将如下命令中的ip_address改为matrix各节点的IP，并逐个执行scp -r /opt/matrix/app/install/metadata/UNIFIED-PLATFORM-BASE/scripts/tools/seasql ip_address:/opt/middleware/ ，以将seasql开关机脚本分发到各节点；

(4)     系统后台任意目录上传如下附件的脚本invalid-ep-iptables-clear.sh

单机环境关机

(1)     ‍登录需要关机的节点后台，并执行sudo bash invalid-ep-iptables-clear.sh命令。

(2)     然后执行sudo bash /opt/matrix/tools/gracefully-shutdown/shutdown.sh进行关机。

集群环境关机步骤

(1)     ‍登录Matrix页面，单击[部署/集群]菜单项，进入集群部署页面，在该页面可查看集群中的所有节点。集群主用Master节点左上角有图标。

(2)     依次在备用Master节点、主用Master节点上执行sudo bash invalid-ep-iptables-clear.sh命令。

(3)     登录任一节点系统后台，执行sudo bash /opt/matrix/tools/gracefully-shutdown/shutdown-all.sh进行关机。

新版本统一数字底盘关机方法

统一数字底盘版本为E7302及之后版本，集成了优雅关机脚本并对脚本进行优化，执行shutdown、reboot命令会自动调用优雅关机脚本。因此可以直接执行shutdown、reboot命令。调用优雅关机脚本的关机时间约6分钟，控制台会打印当前脚本执行的步骤和状态。在未完成关机操作前，请不要直接下电。

脚本优化内容之一：关机或重启操作可能造成meta.db文件损坏导致docker服务和containerd服务无法正常工作，脚本里优化了自修复此文件功能。

由于异常关机、重启操作可能造成损坏的文件是未知的，因此脚本也无法覆盖全面完全解决此类问题。如果已经导致环境异常，请尽快联系相关技术人员定位。

如果出现集群环境，重启主节点，可能会导致POD全部启动后约20分钟统一数字底盘页面登录时报错“用户名不存在或密码错误”，再多等待一会环境会恢复正常状态。

如果出现Matrix页面monitor的prometheus启动失败，按照如下步骤进行修复。

出现Prometheus因内存不足而无法完成正常启动时，可以在Prometheus异常的环境上执行如下命令：

ll /var/lib/ssdata/imonitor/prometheus_data/wal/

查看/var/lib/ssdata/imonitor/prometheus_data/wal/目录下的WAL文件数量，正常情况下WAL文件数量应为3–4个，超过该数量即为异常。

在单机环境（或集群环境中的任一Master节点）执行以下命令，提升Prometheus的内存限制，使其能够加载全部WAL文件并完成启动。若10Gi内存仍不足以完成启动，可根据实际情况继续增大内存限制。

[root@node1 ~]# kubectl set resources -n monitor deployment/prometheus --containers=prometheus-server --limits=memory=10Gi

Prometheus启动完成后会对WAL文件进行压缩，压缩后文件数量会减少，并且会定期执行压缩。建议等到WAL文件数量减少到接近个位数时，再执行以下命令将Prometheus的内存限制调整回3Gi。

[root@node1 ~]# kubectl set resources -n monitor deployment/prometheus --containers=prometheus-server --limits=memory=3Gi

WAL文件的定时压缩速度较慢，通常每2小时进行一次。如果希望加速压缩，可以通过以下命令主动重启Prometheus，以触发压缩。其中，pod_name为故障节点上的Prometheus Pod名称。可以多次执行此命令以加速压缩，但每次执行后需等待Prometheus启动完成。

[root@node1 ~]# kubectl delete pod -n service-software pod_name

 

2.1.22  服务器异常断电

服务器异常断电，可能会造成系统文件损坏，集群功能异常，组件部分业务无法正常使用等。

2.1.23  ETCD分区磁盘IOPS不满足要求引起的环境异常

1. 高危操作

·     环境的ETCD所在磁盘分区由于磁盘I/O性能偏低，达不到要求，在系统关机重启后，有一定概率导致系统文件损坏，引发平台异常。

·     部分磁盘I/O偏低的环境中，当所有Pod状态正常后节点的kubeControllerManager和kubeScheduler异常，约10分钟后才恢复；也可能导致重启后Matrix页面提示进入紧急模式，约10分钟环境恢复正常状态。

·     若ETCD分区未使用独立的物理磁盘，而是与业务数据共用同一块磁盘，在环境运行一段时间后，会与业务共用磁盘I/O，导致ETCD可用的磁盘I/O降低；即便使用两块物理盘做RAID1，也会对ETCD的磁盘IO产生影响。

2. 原理说明

ETCD对磁盘I/O性能的依赖格外敏感，其根本原因在于其作为分布式键值存储的核心工作模式，尤其是其一致性协议和持久化机制，使得磁盘I/O成为整个系统性能和稳定性的关键瓶颈，这种敏感性主要体现在以下几个方面：

·     日志持久化是共识协议的核心环节：ETCD基于Raft共识算法实现数据一致性。Raft协议要求领导者节点在响应客户端写请求前，必须先将包含该操作的日志条目（Log Entry）持久化到本地磁盘，然后才能复制给其他节点。这个过程被称为Write-Ahead Logging。每一次写操作都必须等待磁盘完成一次同步写入（fsync）以确保数据不丢失。因此，磁盘的随机写入延迟直接决定了每次写请求的响应时间。如果磁盘I/O延迟过高，整个集群的写入吞吐量将急剧下降，并可能导致请求超时。

·     状态机快照依赖顺序I/O：为了防止日志无限增长，ETCD会定期将内存中的完整状态（即键值数据）序列化并写入磁盘，生成快照（Snapshot）。创建和加载快照涉及大量的顺序读写操作。虽然顺序I/O对磁盘相对友好，但在数据量巨大时，如果磁盘的顺序读写带宽不足，生成快照的过程会消耗大量时间，期间可能阻塞正常的读写请求，影响服务可用性。

·     高并发下的I/O压力：在生产环境中，尤其是作为Kubernetes等系统的后端存储时，ETCD会面临高并发的读写请求。这会导致大量的随机小I/O操作（如读写单个键值对）。机械硬盘（HDD）的磁头寻道时间是其固有弱点，在高并发随机I/O场景下，寻道延迟会迅速累积，导致请求排队，表现为P99或P999延迟（即长尾延迟）急剧升高，甚至出现秒级延迟，严重影响集群稳定性。

·     直接影响集群健康度：磁盘I/O性能不佳不仅影响单个节点的性能，还会危及整个ETCD集群。如果领导者节点因磁盘I/O缓慢而无法及时完成日志持久化或心跳响应，可能会触发Raft选举超时，从而引发不必要的领导者选举。频繁的选举会导致集群在一段时间内无法处理写请求，造成服务中断。

3. 推荐操作/规避方法

ETCD允许非独立磁盘部署。推荐安装ETCD的磁盘与安装系统及其它组件的磁盘分别对应不同的物理硬盘，若无法满足，则最低配置为7200转HDD盘+1G RAID卡，推荐使用SSD盘。

如果环境已经安装完毕，使用命令检查性能：bash /opt/matrix/tools/env_check.sh -p -d /var/lib/etcd/。如果结果为“风险”，建议更换符合要求的磁盘并用于ETCD分区，推荐ETCD分区使用单独物理磁盘，更推荐使用SSD硬盘。

也可以通过调整ETCD感知参数，降低对磁盘I/O的敏感程度，但也只能一定程度降低此类问题的概率并不能杜绝。如果需要调整，请联系研发人员。

2.1.24  修改SSH服务端口号

1. 高危操作

由于客户安全要求未开放默认的22号SSH端口，但仅在操作系统层面修改了SSH端口号，导致平台异常。

2. 原理说明

Matrix集群通过SSH连接完成节点的安装、修复等操作，并实现应用部署与监控等功能。各节点上的SSH服务默认使用22号端口监听客户端连接，双方建立TCP连接后即可进行数据信息的交互。

3. 推荐操作/规避方法

按照如下步骤进行修改：

(1)     若集群未部署，登录节点后台，使用netstat -anp | grep after_port-number检查指定的端口号是否被占用，若未被占用，则无返回信息；若被占用，则返回如下信息。其中，after_port-number为用户想要指定的SSH服务新的端口号。举例如下：

¡     12345端口号未被占用，可以修改为该端口号。

[root@node1 ~]# netstat -anp | grep 12345

¡     1234端口号被占用，不可以修改为该端口号。

[root@node1 ~]# netstat -anp | grep 1234

tcp        0      0 0.0.0.0:1234            0.0.0.0:*               LISTEN      26211/sshd

tcp6       0      0 :::1234                 :::*                    LISTEN      26211/sshd

若集群已部署，除上述的检查外，还需要执行以下命令确认环境中是否有业务容器占用该端口（如果还有其他形式的端口占用，请根据实际情况检查）。具体如下：

¡     12345端口号未被占用，可以修改为该端口号。

[root@node1 ~]# kubectl get svc -A -oyaml | grep nodePort | grep -w 12345

[root@node1 ~]# kubectl get pod -A -oyaml | grep hostPort | grep -w 12345

¡     1234端口号被nodePort或hostPort占用，不可以修改为该端口号。

[root@node1 ~]# kubectl get svc -A -oyaml | grep nodePort | grep -w 1234

        nodePort: 1234

[root@worker ~]# kubectl get pod -A -oyaml | grep hostPort | grep -w 1234 

        hostPort: 1234

(2)     使用vim /etc/ssh/sshd_config命令进入sshd服务的配置文件，将配置文件中端口号修改为用户想要指定的端口号（以12345为例），且需要删除注释符号#。

图23 修改前的端口号为22

 

图24 修改后的端口号

 

(3)     修改完成后，需重启sshd服务。需要注意的是，若当前操作系统为RHEL8.4/RHEL8.6/RHEL8.8/NingOS且未部署Matrix集群，请重启sshd服务前关闭SELINUX服务（命令：setenforce 0），否则可能导致重启ssh服务时报错。

[root@node1 ~]# setenforce 0

[root@node1 ~]# systemctl restart sshd

(4)     查看新的端口号是否修改成功。以Master节点为例，若有如下返回信息，则表示修改成功。

[root@node1 ~]# netstat -anp | grep -w 12345

tcp        0      0 0.0.0.0:12345            0.0.0.0:*               LISTEN      26212/sshd

tcp6       0      0 :::12345                 :::*                    LISTEN      26212/sshd

(5)     使用vim /opt/matrix/config/navigator_config.json命令进入navigator_config文件，查看该文件中是否存在sshPort字段，若存在，将该字段取值修改为用户想要指定的端口号（以12345为例）；若不存在，则需手动添加该字段并为其赋值。下面以x86版本为例进行说明。

{

"productName": "uc",

"pageList": ["SYS_CONFIG", "DEPLOY", "APP_DEPLOY"],

…略…

"matrixLeaderLeaseDuration": 30,

"matrixLeaderRetryPeriod": 2,

"sshPort": 12345

}

(6)     修改完成后，需重启Matrix服务。

[root@node1 ~]# systemctl restart matrix

(7)     查看新的端口号是否修改成功。以Master节点为例，若成功，则日志中最后一条信息如下。

[root@node1 ~]# cat /var/log/matrix-diag/Matrix/Matrix/matrix.log | grep "ssh port"

2022-03-24T03:46:22,695 | INFO  | FelixStartLevel  | CommonUtil.start:232 | ssh port = 12345.

2.1.25  手动修改/etc/resolv.conf文件导致节点异常

1. 高危操作

环境安装完成后，需配置DNS服务器IP，若直接手动修改/etc/resolv.conf`文件，会导致节点异常。

 

2. 原理说明

在K8S环境里，容器里的/etc/resolv.conf一般是由kubelet和容器运行时自动生成和挂载的DNS配置。在宿主机或容器里手动修改这个文件，会导致Pod里应用（比如Matrix 服务）解析域名异常，从而影响服务访问其它组件、外部服务或数据库等。

3. 推荐操作/规避方法

如果需要配置DNS，需要在Matrix页面修改集群参数，添加DNS服务器IP地址。不能直接修改/etc/resolv.conf文件。

如果已经修改了这个文件，这个文件里内容不为空，将此文件删除即可恢复正常。

2.1.26  使用未适配过系统安装环境

1. 高危操作

使用未适配过的操作系统安装环境，可能导致环境异常并且无法修复。

2. 原理说明

未适配的操作系统，可能存在系统的已知问题导致环境不可用。比如麒麟V10（内核版本为Linux 4.19.90-52.43.v2207.ky10.x86 64）+ OpenJ9 2.9.0（20230518版本），该版本的OpenJ9在麒麟国产化系统上存在codecacheManager内存分配的适配Bug，会导致平台功能异常，并且大概率无法修复。

3. 推荐操作/规避方法

查看统一数字底盘的版本说明书，使用里面适配过的操作系统安装环境。如果已经使用了未适配过系统，建议立即将环境数据进行备份，重新安装适配过的操作系统和相同的版本，然后使用备份文件恢复数据。

2.1.27  主机名/hosts文件修改

1. 高危操作

·     系统安装完毕后，手动修改/etc/hosts文件。

·     安装操作系统时，在“网络和主机名”步骤没有设置主机名，导致使用了默认的主机名。在Matrix安装前，直接修改主机名但未持久化，导致重启后不生效。

2. 原理说明

·     系统安装完毕后，手动修改/etc/hosts文件。

·     安装操作系统时，在“网络和主机名”步骤没有设置主机名，导致使用了默认的主机名。在Matrix安装前，直接修改主机名但未持久化，导致重启后不生效。

3. 推荐操作/规避方法

安装操作系统时，在“网络和主机名”步骤设置主机名。系统安装完毕后如果需要修改主机名，参考《H3C 统一数字底盘安装部署指导》的步骤和说明进行修改，并且修改后重启操作系统，确认新的主机名已经生效。如果安装系统时已经按照要求设置了主机名，则无需再修改hosts文件。

图25 网络和主机名

 

 

2.2  系统高危操作

2.2.1  重启Pod

如下图所示，重启Pod会对组件业务造成一定影响，请谨慎操作，重启一个pod大概需要1~2分钟的时间。

图26 Pod

 

1. ‍EAD终端智能接入模块

·     重启eia-uam-rs：影响前台访问，影响LDAP同步，不影响在线用户。

·     重启eia-uam-dm：影响认证上线，影响增删改接入用户/服务等，不影响在线用户。

·     重启eiapxc：可能导致Pod启动异常，系统中大多数功能都涉及数据库操作，数据库异常将导致操作不可用，不影响在线用户。

·     重启eiaredismaster：可能导致EAD终端智能接入模块部分功能异常，如导致分级管理的当前节点页面显示异常；系统中已有用户上线不受影响。

·     重启eia-uam-dif：影响消息下发和消息中转，不影响在线用户。

·     重启eia-weixinserver：影响移动端认证，如微信认证、企业微信认证、钉钉认证，不影响在线用户。

·     重启eia-byod-server：影响BYOD认证，不影响在线用户。

·     重启eia-mschapv2-server：影响MSCHAPv2认证，不影响在线用户。

·     重启eia-portalserver：影响Portal认证，不影响在线用户。

·     重启eia-third：影响第三方认证、影响用户通知、影响自助页面登录，不影响在线用户。

·     重启eia-ssv-rs：影响自助业务使用，不影响在线用户。

2. EAD终端合规管理模块

·     重启ead-rs/dam-rs：影响前台访问，影响安全策略管理相关业务。

·     重启eia-uam-isp：影响policyserver进程、damserver进程报文处理。

·     重启eia-uam-policy：影响安全认证。

·     重启dam-server：影响资产信息上报。

3. 统一数字底盘

·     重启kong网关：影响业务组件的前台访问、导致端口下服务异常。

·     重启kafka：影响业务组件向后台的消息发送，如可能导致增加接入服务失败；已上线用户不受影响。