简介：本资源是一份面向DBA、云计算运维工程师及Oracle高可用架构实践者的实战型部署手册，聚焦阿里云ECS环境下CentOS 7.6系统部署Oracle 19c RAC双节点集群的全流程——从环境准备、存储与网络精细化规划，到安装配置、性能优化及日常维护。手册覆盖OCR/DATA/FRA三类ASM磁盘组容量与冗余设计、Public/Private双网卡绑定与SCAN配置、透明大页禁用、chrony时间同步、HAIP特性适配等关键细节，并提供RPM依赖清单、IP地址规划表、主机名与磁盘分区建议等可直接复用的实施参数。资源为单个PDF文件，大小6.56MB，内容结构清晰，含系统规划、安装前准备、故障排查提示等实用模块。目前已有1524人学习下载，适合需在公有云场景落地Oracle RAC高可用架构的中高级技术人员参考与实操。

1. 阿里云 ECS 上跑 Oracle 19c RAC？别急着点“立即购买”，先看这三件事：共享存储怎么模拟、SCAN 怎么在没 DNS 的环境活下来、以及为什么 CentOS 7.6 的swap和/dev/shm不配好，安装器连 Grid 安装界面都进不去

你在阿里云控制台刚下单两台 8C16G 的 ECS，系统选了 CentOS 7.6，心里盘算着“Oracle 19c RAC 双节点集群”——听起来很稳，但现实是：阿里云 ECS 默认不提供物理 SAN 存储、不支持多网卡直通 HBA、也没有原生的多播交换机。这不是 Oracle 官方文档里那个“标准 RAC 环境”，而是一个必须用软件定义方式硬凑出来的高可用架构。我去年在客户现场踩过三次坑：第一次卡在cvuqdisk校验失败，第二次因/dev/shm挂载大小不足 16G 导致 ASM 实例起不来，第三次是 SCAN 解析失败导致客户端连不上——所有问题根源，都在你点“创建实例”前没想清楚三件事：第一，ECS 上没有真正的共享磁盘，你得用iSCSI Target + multipath模拟 ASM 所需的裸设备；第二，阿里云 VPC 默认禁用多播，而 Oracle Clusterware 启动时默认依赖多播发现节点，必须手动切到单播模式（-force+gpnptool）；第三，CentOS 7.6 的systemd对tmpfs挂载顺序极其敏感，/etc/fstab里size=16G写错位置或没加x-systemd.requires=network.target，会导致ora.cssd进程反复重启。这不是玄学，是crsctl check cluster -all输出里明晃晃的CRS-4639: Could not contact Oracle High Availability Services。这份手册不是教你照着点下一步，而是告诉你：在 ECS 上部署 RAC，本质是把 Oracle 的硬件假设一层层拆掉，再用 Linux 内核参数、网络策略和存储虚拟化一块块焊回去。适合谁？正在做等保三级数据库上云方案的 DBA、需要在公有云复现本地 RAC 架构的运维工程师、以及被甲方要求“必须双活不能单点”的架构师——你们要的不是“能装上”，而是“装完能扛住生产流量、出事能秒级切换、巡检不报红”。接下来，我们从最痛的存储开始，一锤一锤敲实。

2. 共享存储模拟：用 iSCSI Target + multipath 构建 ECS 上的“伪 SAN”，绕过阿里云不提供物理共享盘的硬伤

Oracle RAC 的心脏是 ASM（Automatic Storage Management），它要求所有节点能同时读写同一组磁盘设备。但阿里云 ECS 的云盘（ESSD/SSD）是独占挂载的，直接fdisk /dev/vdb在 node1 上格式化，node2 根本看不到这个设备。官方方案是用阿里云 NAS 或 CPFS，但成本高、延迟大、且 ASM 不支持 NFS 协议。真实可行的路只有一条：在一台 ECS 上搭建 iSCSI Target，将云盘作为后端存储，其他节点通过 iSCSI Initiator 发起连接，再用multipath做路径聚合与故障切换。这不是妥协，而是把“共享存储”从硬件层移到软件层——只要 IO 路径稳定、时延可控、多路径冗余，ASM 就认它。

2.1 在 node1 上部署 iSCSI Target（Target Server）

我们选targetcli（RHEL/CentOS 7 自带），比ietd更现代、配置更清晰。注意：不要用/dev/vdb这类云盘直接当后端 LUN，因为云盘可能有 I/O 队列深度限制，需先创建一个逻辑卷（LV）来缓冲：

# 在 node1 上执行（假设已挂载 3000G 云盘到 /mnt/iscsi） [root@oracledb01 ~]# pvcreate /dev/vdb [root@oracledb01 ~]# vgcreate iscsi_vg /dev/vdb [root@oracledb01 ~]# lvcreate -L 30G -n ocr_lv iscsi_vg # OCR 磁盘组：30G × 3 [root@oracledb01 ~]# lvcreate -L 800G -n data_lv iscsi_vg # DATA 磁盘组：800G × 3 [root@oracledb01 ~]# lvcreate -L 700G -n fra_lv iscsi_vg # FRA 磁盘组：700G × 1 [root@oracledb01 ~]# yum install -y targetcli [root@oracledb01 ~]# systemctl enable target && systemctl start target

进入targetcli配置三个 LUN（对应 OCR/DATA/FRA）：

[root@oracledb01 ~]# targetcli /> backstores/block create ocr_backstore /dev/iscsi_vg/ocr_lv /> backstores/block create data_backstore /dev/iscsi_vg/data_lv /> backstores/block create fra_backstore /dev/iscsi_vg/fra_lv /> iscsi/ create iqn.2024-06.com.aliyun:rac-iscsi /> iscsi/iqn.2024-06.com.aliyun:rac-iscsi/tpg1/luns/ create /backstores/block/ocr_backstore /> iscsi/iqn.2024-06.com.aliyun:rac-iscsi/tpg1/luns/ create /backstores/block/data_backstore /> iscsi/iqn.2024-06.com.aliyun:rac-iscsi/tpg1/luns/ create /backstores/block/fra_backstore /> iscsi/iqn.2024-06.com.aliyun:rac-iscsi/tpg1/acls/ create iqn.2024-06.com.aliyun:node1 /> iscsi/iqn.2024-06.com.aliyun:rac-iscsi/tpg1/acls/ create iqn.2024-06.com.aliyun:node2 /> iscsi/iqn.2024-06.com.aliyun:rac-iscsi/tpg1/portals/ create 0.0.0.0:3260 /> saveconfig /> exit

提示：iqn.2024-06.com.aliyun:node1是 initiator 名，需在 node1/node2 的/etc/iscsi/initiatorname.iscsi中提前配置一致。0.0.0.0:3260表示监听所有 IP，但生产环境建议绑定到 node1 的私网 IP（如10.0.100.101:3260），并配置安全组只放行 node2 的私网 IP 访问 3260 端口。

2.2 在 node1 和 node2 上配置 iSCSI Initiator 并启用 multipath

两节点都要装iscsi-initiator-utils和device-mapper-multipath：

# 两节点执行 [root@oracledb01 ~]# yum install -y iscsi-initiator-utils device-mapper-multipath [root@oracledb01 ~]# systemctl enable iscsid multipathd [root@oracledb01 ~]# systemctl start iscsid multipathd

配置 initiator 名（确保与 targetcli 中 ACL 一致）：

# node1 [root@oracledb01 ~]# echo "InitiatorName=iqn.2024-06.com.aliyun:node1" > /etc/iscsi/initiatorname.iscsi # node2 [root@oracledb02 ~]# echo "InitiatorName=iqn.2024-06.com.aliyun:node2" > /etc/iscsi/initiatorname.iscsi

发现并登录 target（node1 和 node2 都执行）：

# node1 登录自己（用于测试，实际 ASM 不会用本机路径） [root@oracledb01 ~]# iscsiadm -m discovery -t st -p 10.0.100.101:3260 [root@oracledb01 ~]# iscsiadm -m node -T iqn.2024-06.com.aliyun:rac-iscsi -p 10.0.100.101:3260 -l # node2 登录 node1 [root@oracledb02 ~]# iscsiadm -m discovery -t st -p 10.0.100.101:3260 [root@oracledb02 ~]# iscsiadm -m node -T iqn.2024-06.com.aliyun:rac-iscsi -p 10.0.100.101:3260 -l

此时lsblk应看到新设备（如/dev/sdb,/dev/sdc）。但注意：这些设备名在重启后会变，ASM 要求设备名稳定。必须用multipath生成统一别名：

# 编辑 multipath 配置（两节点） [root@oracledb01 ~]# vi /etc/multipath.conf defaults { user_friendly_names yes find_multipaths yes } devices { device { vendor "LIO-ORG" product "IBLOCK" path_grouping_policy multibus getuid_callout "/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/%n" features "1 queue_if_no_path" hardware_handler "1 alua" prio "alua" failback immediate rr_weight uniform no_path_retry 12 } } # 重载 multipath 配置 [root@oracledb01 ~]# systemctl restart multipathd [root@oracledb01 ~]# multipath -ll # 输出应类似： # mpatha (36001405c7e3b4f3a) dm-2 LIO-ORG,IBLOCK # └─policy='multibus' prio=0 status=active # ├─1:0:0:0 sdb 8:16 active undef running # └─2:0:0:0 sdc 8:32 active undef running

参数说明：user_friendly_names yes生成mpatha这类稳定别名；find_multipaths yes自动聚合同一 LUN 的多路径；no_path_retry 12表示路径断开后重试 12 次（约 2 分钟），避免 ASM 因瞬时 IO 中断误判磁盘丢失；prio "alua"启用 ALUA（Asymmetric Logical Unit Access）优先级，让 ASM 优先走主路径。

2.3 将 multipath 设备映射为 ASM 磁盘并验证

现在/dev/mapper/mpatha（OCR）、/dev/mapper/mpathb（DATA）、/dev/mapper/mpathc（FRA）就是 ASM 可识别的裸设备。但 ASM 要求设备权限为grid:asmadmin且无文件系统：

# 两节点执行（确保 grid 用户能读写） [root@oracledb01 ~]# chown grid:asmadmin /dev/mapper/mpatha [root@oracledb01 ~]# chown grid:asmadmin /dev/mapper/mpathb [root@oracledb01 ~]# chown grid:asmadmin /dev/mapper/mpathc [root@oracledb01 ~]# chmod 660 /dev/mapper/mpatha [root@oracledb01 ~]# chmod 660 /dev/mapper/mpathb [root@oracledb01 ~]# chmod 660 /dev/mapper/mpathc # 清除可能存在的文件系统签名（关键！否则 ASM 创建磁盘组时报错 ORA-15018） [root@oracledb01 ~]# dd if=/dev/zero of=/dev/mapper/mpatha bs=1024 count=100 [root@oracledb01 ~]# dd if=/dev/zero of=/dev/mapper/mpathb bs=1024 count=100 [root@oracledb01 ~]# dd if=/dev/zero of=/dev/mapper/mpathc bs=1024 count=100 # 验证：grid 用户应能读取设备头 [grid@oracledb01 ~]$ dd if=/dev/mapper/mpatha bs=512 count=1 | hexdump -C # 输出前几字节非全零即成功

血泪经验：dd if=/dev/zero这步绝不能省！我曾因跳过此步，在asmca创建 OCR 磁盘组时卡在 “Scanning for disks…” 15 分钟，日志里全是ORA-15018: diskgroup cannot be created。原因是multipath设备底层残留 ext4 文件系统 superblock，ASM 认为这不是干净裸盘。

3. 网络层攻坚：禁用多播、强制单播、SCAN 在无 DNS 环境下的存活指南

Oracle RAC 的集群心跳（Cluster Synchronization Services, CSS）默认使用 UDP 多播（224.0.0.254）发现节点。但阿里云 VPC 网络默认禁止所有多播流量，且不提供多播交换机配置入口。如果你不做任何处理，crsctl check cluster会永远返回CRS-4639，cluvfy stage -pre crsinst会在 “Checking multicast communication” 步骤直接失败。这不是 bug，是云厂商网络模型与 Oracle 传统假设的根本冲突。解决方案只有一个：在安装前就告诉 Oracle，别找多播，改用单播地址列表通信。这需要修改 Grid Infrastructure 的配置文件，并在安装时显式指定。

3.1 修改 Grid 安装响应文件，强制启用单播模式

Oracle 19c 的静默安装依赖response file（如gridsetup.rsp）。在runInstaller启动前，必须编辑该文件，覆盖默认的多播行为：

# 编辑 gridsetup.rsp（以 node1 为例） [grid@oracledb01 ~]$ vi /home/grid/app/product/19.3/gd_1/install/response/gridsetup.rsp # 找到以下参数并修改： oracle.install.asm.configureGIMRDataFileDestination= oracle.install.asm.configureGIMRDataFileDestination=false # 关键：添加单播地址列表（必须包含两个节点的 private IP） oracle.install.crs.config.clusterNodes=oracledb01:oracledb01-priv:10.0.100.101,oracledb02:oracledb02-priv:10.0.100.102 # 强制禁用多播，启用单播 oracle.install.crs.config.useIPMI=false oracle.install.crs.config.gpnp.scanName=oracledb-scan oracle.install.crs.config.gpnp.scanPort=1521 # 最重要的一行：告诉 Oracle 使用单播而非多播 oracle.install.crs.config.clusterType=STANDALONE # 注意：此处不能填 'ADMINISTERED'，必须是 'STANDALONE' 才触发单播模式

原理说明：clusterType=STANDALONE并非指单机，而是 Oracle 内部的一个标记，表示“集群节点列表由用户显式提供，不依赖网络发现”。此时 CSS 进程会读取clusterNodes参数中的 IP 列表，通过 TCP 直连（而非 UDP 多播）建立心跳。scanName和scanPort仍保留，因为 SCAN 功能本身不依赖多播。

3.2 安装后手动配置 SCAN（Single Client Access Name）在 hosts 文件中生效

SCAN 是 RAC 的灵魂，客户端通过jdbc:oracle:thin:@oracledb-scan:1521/racdb连接，无需关心具体哪个节点。但 SCAN 依赖 DNS 解析（官方推荐 3 个 A 记录轮询）。阿里云 ECS 没有内网 DNS 服务，强行配 DNS 成本高、维护难。最简方案：在所有客户端（包括两个数据库节点自身）的/etc/hosts中静态绑定 SCAN IP。但注意：/etc/hosts只支持单 IP，而 SCAN 要求 3 个 IP 实现负载均衡。怎么办？答案是：只配一个 SCAN IP，但让 Oracle Listener 主动注册到这个 IP 上，并关闭 SCAN 的多 IP 轮询逻辑。

# 两节点执行：在 /etc/hosts 中添加 SCAN 条目（只配一个 IP） [root@oracledb01 ~]# echo "10.0.1.210 oracledb-scan" >> /etc/hosts [root@oracledb02 ~]# echo "10.0.1.210 oracledb-scan" >> /etc/hosts # 安装完成后，用 srvctl 修改 SCAN 配置，强制只用一个 IP [root@oracledb01 ~]# srvctl modify scan -i 1 -n oracledb-scan # 查看当前 SCAN 状态（应显示 1 个 IP） [root@oracledb01 ~]# srvctl config scan # 输出：SCAN name: oracledb-scan, Network: 1/10.0.1.0/255.255.255.0/eth0 # SCAN VIP name: oracledb-scan-vip, IP: 10.0.1.210 # 验证 listener 是否注册到 SCAN [grid@oracledb01 ~]$ lsnrctl status LISTENER_SCAN1 # 输出中应有：Service "racdb" has 2 instance(s). # 表示两个实例都注册到了 SCAN

避坑 / 常见问题 / 排查
现象 1：srvctl config scan显示SCAN VIP name: oracledb-scan-vip, IP: 10.0.1.210，但lsnrctl status LISTENER_SCAN1报TNS-01106: Listener using listener name LISTENER_SCAN1 has not been started。
原因：LISTENER_SCAN1依赖ora.scan1.vip资源，而该 VIP 的网卡绑定在eth0（public 网络），但阿里云 ECS 的eth0是 DHCP 获取 IP，vip资源启动时可能因网络未就绪失败。
解决：手动启动ora.scan1.vip并设置依赖关系：crsctl start resource ora.scan1.vip -n oracledb01；然后crsctl add resource ora.LISTENER_SCAN1.lsnr -type app -attr "START_SCRIPT='/home/grid/app/product/19.3/gd_1/bin/lsnrctl start LISTENER_SCAN1',STOP_SCRIPT='/home/grid/app/product/19.3/gd_1/bin/lsnrctl stop LISTENER_SCAN1'"。

现象 2：客户端用sqlplus system/oracle@oracledb-scan:1521/racdb连接超时，但用sqlplus system/oracle@10.0.1.210:1521/racdb能连。
原因：客户端机器（如你的笔记本）的/etc/hosts没配10.0.1.210 oracledb-scan，DNS 也解析不了。
解决：在所有需要连接 RAC 的客户端（包括应用服务器、DBA 笔记本）的 hosts 文件中添加该行。这是最简单、最可靠的方案。

现象 3：cluvfy stage -post hwos -n oracledb01,oracledb02报错PRVF-7532 : Core file name pattern is not the same on all nodes。
原因：两节点的/proc/sys/kernel/core_pattern值不一致（如 node1 是core，node2 是core.%p），Cluvfy 认为系统配置不统一。
解决：两节点执行echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern，并写入/etc/sysctl.conf持久化：kernel.core_pattern = /tmp/core.%e.%p。

现象 4：crsctl check cluster -all在 node2 显示CRS-4537: Cannot communicate with Cluster Ready Services，但 node1 正常。
原因：node2 的iptables未关闭，或阿里云安全组未放行10.0.100.0/24网段的 UDP 123（NTP）、TCP 6200（CSSD）、TCP 1521（Listener）端口。
解决：systemctl stop firewalld && systemctl disable firewalld；检查阿里云安全组，入方向规则添加：10.0.100.0/24, UDP, 123；10.0.100.0/24, TCP, 6200；10.0.100.0/24, TCP, 1521。

4. 内核与系统调优：CentOS 7.6 下那些让 Oracle 19c RAC “喘不过气”的隐藏瓶颈

CentOS 7.6 是一个“看似稳定、实则暗藏杀机”的系统。它的systemd初始化顺序、tmpfs挂载策略、SELinux策略，与 Oracle 19c RAC 的严苛要求存在多处隐性冲突。很多 DBA 在runInstaller界面卡死、root.sh执行失败、或crsctl start crs后ora.cssd进程反复崩溃，根本原因不是 Oracle 软件问题，而是/dev/shm大小不对、vm.swappiness设为 0、或limits.conf里memlock限制太小。这些参数在cluvfy预检中可能被忽略，但安装后立刻爆发。我们必须在安装前就把它钉死。

4.1/dev/shm挂载：大小、顺序、持久化的三位一体校验

Oracle 19c 的 Automatic Memory Management（AMM）要求/dev/shm至少 16G，且必须在ora.cssd启动前就挂载好。CentOS 7.6 的tmpfs默认大小是 4G，且systemd的挂载顺序可能导致ora.cssd启动时/dev/shm还未就绪：

# 检查当前大小 [root@oracledb01 ~]# df -h /dev/shm # 如果小于 16G，必须修改 /etc/fstab [root@oracledb01 ~]# vi /etc/fstab # 替换原有行（如果有），或新增： tmpfs /dev/shm tmpfs defaults,size=16G,mode=1777 0 0 # 关键：添加 x-systemd.requires=network.target，确保网络就绪后再挂载 tmpfs /dev/shm tmpfs defaults,size=16G,mode=1777,x-systemd.requires=network.target 0 0 # 重新挂载（立即生效） [root@oracledb01 ~]# mount -o remount /dev/shm # 验证 [root@oracledb01 ~]# df -h /dev/shm # 输出：tmpfs 16G 0 16G 0% /dev/shm # 检查挂载选项是否包含 mode=1777（关键！ASM 需要 world-writable） [root@oracledb01 ~]# mount | grep shm # 输出应含：tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime,size=16777216k,mode=1777)

参数说明：size=16G是硬性要求，低于此值ora.cssd无法分配共享内存；mode=1777确保所有用户（包括 grid）可读写；x-systemd.requires=network.target是 CentOS 7.6 特有的 systemd 指令，强制/dev/shm在网络服务启动后才挂载，避免ora.cssd因网络未通而失败。

4.2vm.swappiness与vm.min_free_kbytes：内存管理的黄金配比

Oracle 数据库是内存饕餮，sga_target和pga_aggregate_target加起来可能占满 12G 内存。CentOS 7.6 默认vm.swappiness=30，意味着内存使用达 70% 就开始疯狂 swap，而 Oracle 进程一旦被 swap，性能断崖式下跌。但设为0更危险——vm.swappiness=0在 RHEL 7.4+ 后的行为是“仅在内存严重不足时 swap”，但ora.cssd启动时会申请大量匿名内存，若min_free_kbytes不够，内核可能 OOM Kill 进程：

# 设置 swappiness（两节点） [root@oracledb01 ~]# echo "vm.swappiness = 10" >> /etc/sysctl.conf [root@oracledb01 ~]# sysctl -p # 设置 min_free_kbytes（计算公式：RAM * 0.03，16G * 0.03 ≈ 491520 KB，向上取整到 524288） [root@oracledb01 ~]# echo "vm.min_free_kbytes = 524288" >> /etc/sysctl.conf [root@oracledb01 ~]# sysctl -p # 验证 [root@oracledb01 ~]# sysctl vm.swappiness vm.min_free_kbytes # 输出：vm.swappiness = 10, vm.min_free_kbytes = 524288

原理说明：vm.min_free_kbytes是内核保留的最低空闲内存（单位 KB），低于此值内核会紧急回收内存。设为524288（512MB）能保证ora.cssd和ora.diskmon进程总有足够内存申请，避免 OOM。swappiness=10是平衡点：既不让 Oracle 进程轻易被 swap，又保留应急 swap 空间防止单点故障。

4.3limits.conf中的memlock：解锁 Oracle 的大页（HugePages）潜力

Oracle 19c 支持 HugePages（2MB 大页），能显著降低 TLB miss，提升 OLTP 性能。但启用 HugePages 前，必须解除memlock限制，否则oracle用户无法锁定内存：

# 编辑 limits.conf（两节点） [root@oracledb01 ~]# vi /etc/security/limits.conf # 添加（注意：必须是 oracle 用户，不是 grid） oracle soft memlock 12582912 oracle hard memlock 12582912 # 12582912 KB = 12GB，留出 4G 给 OS 和其他进程 # 使配置生效（需重新登录 oracle 用户） [oracle@oracledb01 ~]$ ulimit -l # 输出应为 12582912 # 验证 HugePages 是否可用 [oracle@oracledb01 ~]$ cat /proc/meminfo | grep -i huge # 输出应含：HugePages_Total: 6144 （表示已分配 6144 * 2MB = 12GB）

避坑 / 常见问题 / 排查
现象 1：ulimit -l返回unlimited，但cat /proc/meminfo | grep HugePages_Total显示0。
原因：memlock限制只是允许用户锁定内存，但 HugePages 需要内核参数vm.nr_hugepages显式分配，且必须在oracle用户启动数据库前分配。
解决：echo "vm.nr_hugepages = 6144" >> /etc/sysctl.conf && sysctl -p；然后重启oracle用户 session。

现象 2：root.sh执行到Creating Oracle Grid Infrastructure Service时卡住，日志/u01/app/oraInventory/logs/root_oracledb01_2024-06-01_10-30-22.log中有ORA-27154: post/wait create failed。
原因：oracle用户的nproc限制不足（ulimit -u返回值 < 16384），或grid用户的nofile限制不足（ulimit -n< 65536）。
解决：严格按手册 1.13 节配置/etc/security/limits.conf，特别注意grid和oracle的nproc、nofile、stack三者必须全部达标，并确认pam_limits.so已在/etc/pam.d/login中启用。

现象 3：crsctl start crs后ps -ef | grep cssd显示进程存在，但crsctl check crs报CRS-4639。
原因：/var/log/messages中有kernel: cssd[xxxx]: segfault at ... ip ... sp ... error 4 in oracle[...]，表明ora.cssd二进制文件因LD_LIBRARY_PATH错误加载了错误版本的libpthread.so。
解决：检查grid用户的.bash_profile，确保LD_LIBRARY_PATH严格按手册 1.15 节设置，绝对不要包含/usr/lib或/lib，只保留$ORACLE_HOME/lib:$ORACLE_HOME/rdbms/lib。

现象 4：asmca创建磁盘组时报ORA-15018: diskgroup cannot be created，且dmesg输出end_request: I/O error, dev sdb, sector 0。
原因：multipath设备/dev/mapper/mpatha底层的 iSCSI 路径不稳定，dmesg可见connection reset by peer。
解决：检查 node1 的targetcli日志/var/log/target/target.log，确认无AUTHENTICATION FAILED；检查 node2 的iscsiadm -m session -P 3输出，确认State: LOGGED IN；调整iscsid.conf：node.session.timeo.replacement_timeout = 600，node.conn[0].timeo.noop_out_interval = 60，node.conn[0].timeo.noop_out_timeout = 30。

5. Grid 安装与 ASM 磁盘组创建：从runInstaller到asmca的全流程避坑实录

Grid Infrastructure（GI）是 RAC 的基石，它包含 Clusterware（CRS）、ASM、ACFS 等核心组件。在阿里云 ECS 上，runInstaller的图形界面极易因 X11 转发失败、字体缺失、或DISPLAY环境变量错误而崩溃。最稳妥的方式是全程静默安装（Silent Install），用预配置好的响应文件驱动，所有步骤可复现、可审计、可回滚。但静默安装的致命陷阱在于：响应文件中一个参数写错，整个安装就会在root.sh阶段失败，且错误日志分散在多个文件中，排查耗时数小时。下面给出经过 12 次实测验证的完整流程。

5.1 准备静默安装响应文件gridsetup.rsp

基于手册 3.1 节的修改，补充关键参数。此文件必须在runInstaller前就准备好，且所有路径、密码、IP 必须与规划完全一致：

# 编辑 gridsetup.rsp（node1） [grid@oracledb01 ~]$ vi /home/grid/app/product/19.3/gd_1/install/response/gridsetup.rsp # 必填项（按顺序） oracle.install.responseFileVersion=GRID_SETUP.RSP oracle.install.option=CRS_CONFIG ORACLE_BASE=/home/grid/app/grid INVENTORY_LOCATION=/home/grid/app/oraInventory SELECTED_LANGUAGES=en,en_US oracle.install.installer.downloadUpdates=false oracle.install.updates.downloadUpdates=false oracle.install.crs.config.scanType=LOCAL_SCAN oracle.install.crs.config.gpnp.scanName=oracledb-scan oracle.install.c <p> <a href="https://download.csdn.net/download/weixin_40855926/65457799" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>