将Red Hat Enterprise Linux 7.5与ONTAP结合使用
您可以使用ONTAP SAN主机配置设置将ONTAP配置为目标Red Hat Enterprise Linux 7.5。
安装 Linux Unified Host Utilities
NetApp LINUX统一主机实用程序软件包以32位和64位.rpm文件的形式在上提供"NetApp 支持站点"。如果您不知道哪个文件适合您的配置、请使用验证您需要哪个文件"NetApp 互操作性表工具"。
NetApp强烈建议安装Linux统一主机实用程序、但这并不是必需的。这些实用程序不会更改Linux主机上的任何设置。这些实用程序可改进管理并帮助 NetApp 客户支持收集有关您的配置的信息。
如果您当前已安装Linux Unified Host Utilities、则应将其升级到最新版本或将其删除、然后按照以下步骤安装最新版本。
-
从下载 32 位或 64 位 Linux Unified Host Utilities 软件包 "NetApp 支持站点" 主机。
-
安装软件包:
rpm -ivh netapp_linux_unified_host_utilitis-7-1.x86_64
您可以使用本文档中提供的配置设置来配置连接到的云客户端 "Cloud Volumes ONTAP" 和 "适用于 ONTAP 的 Amazon FSX"。 |
SAN 工具包
安装 NetApp Host Utilities 软件包时,工具包会自动安装。此套件提供 sanlun
实用程序,可帮助您管理 LUN 和 HBA 。sanlun
命令可返回有关映射到主机的 LUN 的信息,多路径以及创建启动程序组所需的信息。
在以下示例中, sanlun lun show
命令将返回 LUN 信息。
# sanlun lun show all
示例输出:
controller(7mode/E-Series)/ device host lun vserver(cDOT/FlashRay) lun-pathname filename adapter protocol size Product ------------------------------------------------------------------------------------ data_vserver /vol/vol1/lun1 /dev/sdb host16 FCP 120.0g cDOT data_vserver /vol/vol1/lun1 /dev/sdc host15 FCP 120.0g cDOT data_vserver /vol/vol2/lun2 /dev/sdd host16 FCP 120.0g cDOT data_vserver /vol/vol2/lun2 /dev/sde host15 FCP 120.0g cDOT
SAN 启动
如果您决定使用 SAN 启动,则配置必须支持它。您可以使用 "NetApp 互操作性表工具" 验证您的操作系统, HBA , HBA 固件和 HBA 启动 BIOS 以及 ONTAP 版本是否受支持。
-
将 SAN 启动 LUN 映射到主机。
-
验证是否有多个可用路径。
在主机操作系统启动并运行多个路径后、这些路径将变为可用。 -
在服务器 BIOS 中为 SAN 启动 LUN 映射到的端口启用 SAN 启动。
有关如何启用 HBA BIOS 的信息,请参见供应商专用文档。
-
重新启动主机以验证启动是否成功。
多路径
对于 Red Hat Enterprise Linux ( RHEL ) 7.5 , /etc/multipath.conf 文件必须存在,但您不需要对该文件进行特定更改。RHEL 7.5 使用识别和正确管理 ONTAP LUN 所需的所有设置进行编译。
您可以使用 multipath -ll
命令验证 ONTAP LUN 的设置。
以下各节提供了映射到ASA和非ASA用户身份的LUN的示例多路径输出。
所有SAN阵列配置
全SAN阵列(ASA)配置可优化指向给定LUN的所有路径、使其保持活动状态。这样可以同时通过所有路径提供I/O操作、从而提高性能。
以下示例显示了ONTAP LUN的正确输出。
# multipath -ll 3600a09803831347657244e527766394e dm-5 NETAPP,LUN C-Mode size=80G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 alua' wp=rw `-+- policy='service-time 0' prio=50 status=active |- 11:0:7:1 sdfi 130:64 active ready running |- 11:0:9:1 sdiy 8:288 active ready running |- 11:0:10:1 sdml 69:464 active ready running |- 11:0:11:1 sdpt 131:304 active ready running
一个LUN不应需要四个以上的路径。如果路径数超过四个、则可能会在存储故障期间导致路径问题。 |
非ASA配置
对于非ASA配置、应具有两组具有不同优先级的路径。优先级较高的路径为主动/优化路径、这意味着它们由聚合所在的控制器提供服务。优先级较低的路径处于活动状态、但未进行优化、因为它们是从其他控制器提供的。只有在优化路径不可用时、才会使用非优化路径。
以下示例显示了具有两个主动 / 优化路径和两个主动 / 非优化路径的 ONTAP LUN 的正确输出。
# multipath -ll 3600a09803831347657244e527766394e dm-5 NETAPP,LUN C-Mode size=80G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle’ hwhandler='1 alua' wp=rw |-+- policy='service-time 0' prio=50 status=active | |- 11:0:1:0 sdj 8:144 active ready running | |- 11:0:2:0 sdr 65:16 active ready running `-+- policy='service-time 0' prio=10 status=enabled |- 11:0:0:0 sdb 8:i6 active ready running |- 12:0:0:0 sdz 65:144 active ready running
一个LUN不应需要四个以上的路径。如果路径数超过四个、则可能会在存储故障期间导致路径问题。 |
建议设置
RHEL 7.5 操作系统经过编译,可识别 ONTAP LUN ,并自动为 ASA 和非 ASA 配置正确设置所有配置参数。
`multipath.conf`要启动多路径守护进程、必须存在该文件。如果此文件不存在、您可以使用命令创建一个空的零字节文件 `touch /etc/multipath.conf`。
首次创建 `multipath.conf`文件时、可能需要使用以下命令启用并启动多路径服务:
chkconfig multipathd on /etc/init.d/multipathd start
您无需直接向文件中添加任何内容 multipath.conf
、除非您的设备不需要多路径管理、或者您的现有设置会覆盖默认值。要排除不需要的设备、请在文件中添加以下语法 multipath.conf
、将<DevId>替换为要排除的设备的全球通用标识符(WWID)字符串:
blacklist { wwid <DevId> devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" devnode "^hd[a-z]" devnode "^cciss.*" }
以下示例将确定设备的WWID并将其添加到文件中 multipath.conf
。
-
确定WWID:
/lib/udev/scsi_id -gud /dev/sda
3600a098038314c4a433f5774717a3046 /lib/udev/scsi_id -gud /dev/sda
360030057024d0730239134810c0cb833
+ `sda` is the local SCSI disk that you want to add to the blacklist. . Add the `WWID` to the blacklist stanza in `/etc/multipath.conf`: [source,cli] +
黑名单{ wwid 3600a098038314c4a433f5774717a3046 devnode "^(ram|raw|lo|fd|m|dm-|sr|scd|st)" devnode "^hd[a-z]" devnode "^cciss."}
Always check your `/etc/multipath.conf` file, especially in the defaults section, for legacy settings that might be overriding default settings. The following table demonstrates the critical `multipathd` parameters for ONTAP LUNs and the required values. If a host is connected to LUNs from other vendors and any of these parameters are overridden, they must be corrected by later stanzas in the `multipath.conf` file that apply specifically to ONTAP LUNs. Without this correction, the ONTAP LUNs might not work as expected. You should only override these defaults in consultation with NetApp, the OS vendor, or both, and only when the impact is fully understood. //ONTAPDOC-2578 9-Dec-2024 //ONTAPDOC-2561 25-Nov-202 [cols=2*,options="header"] |=== | Parameter | Setting | detect_prio | yes | dev_loss_tmo | "infinity" | failback | immediate | fast_io_fail_tmo | 5 | features | "3 queue_if_no_path pg_init_retries 50" | flush_on_last_del | "yes" | hardware_handler | "0" | no_path_retry | queue | path_checker | "tur" | path_grouping_policy | "group_by_prio" | path_selector | "service-time 0" | polling_interval | 5 | prio | "ontap" | product | LUN.* | retain_attached_hw_handler | yes | rr_weight | "uniform" | user_friendly_names | no | vendor | NETAPP |=== .Example The following example shows how to correct an overridden default. In this case, the `multipath.conf` file defines values for `path_checker` and `no_path_retry` that are not compatible with ONTAP LUNs. If they cannot be removed because of other SAN arrays still attached to the host, these parameters can be corrected specifically for ONTAP LUNs with a device stanza.
默认值为{ path_checker_readsector0 no_path_retry失败}
设备{设备{供应商"LUN NetApp "产品"LUN。*" NO_PATE_RETRY队列路径检查程序}
=== Configure KVM settings You can use the recommended settings to configure Kernel-based Virtual Machine (KVM) as well. There are no changes required to configure KVM because the LUN is mapped to the hypervisor. //ONTAPDOC-2561 5-Dec-2024 == Known issues The RHEL 7.5 with ONTAP release has the following known issues: [cols=3*,options="header"] |=== | NetApp Bug ID | Title | Description | 1440718 | If you unmap or map a LUN without performing a SCSI rescan, it might lead to data corruption on the host. | When you set the 'disable_changed_wwids' multipath configuration parameter to YES, it disables access to the path device in the event of a WWID change. Multipath will disable access to the path device until the WWID of the path is restored to the WWID of the multipath device. To learn more, see link:https://kb.netapp.com/Advice_and_Troubleshooting/Flash_Storage/AFF_Series/The_filesystem_corruption_on_iSCSI_LUN_on_the_Oracle_Linux_7[NetApp Knowledge Base: The filesystem corruption on iSCSI LUN on the Oracle Linux 7^]. | link:https://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=1139053[1139053^] | Kernel disruption occurs on RHEL7.5 with QLogic QLE2672 16GB FC during storage failover operations |During storage failover operations on the RHEL7U5 kernel with QLogic QLE2672 16GB fibre channel host bus adapter, the kernel disruption occurs due to a panic in the kernel. The kernel panic causes RHEL 7.5 to reboot, which leads to an application disruption. The kernel panic generates the vmcore file under the /var/crash/directory if kdump is configured. The vmcore file is used to understand the cause of the failure. In this case, the panic was observed in the “get_next_timer_interrupt+440” module which is logged in the vmcore file with the following string: " [exception RIP: get_next_timer_interrupt+440]" After the kernel disruption, you can recover the operating system by rebooting the host operating system and restarting the application as required. | link:https://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=1138536[1138536^] | Kernel disruption occurs on RHEL7U5 with QLogic QLE2742 32GB FC during storage failover operations | During storage failover operations on the Red Hat Enterprise Linux (RHEL) RHEL7U5 kernel with QLogic QLE2742 HBA, kernel disruption occurs due to a panic in the kernel. The kernel panic leads to a reboot of the operating system, causing an application disruption. The kernel panic generates the vmcore file under the /var/crash/ directory if kdump is configured. When the kernel panics, you can use the vmcore file to investigate the reason for the failure. The following example shows a panic in the bget_next_timer_interrupt+440b module. The panic is logged in the vmcore file with the following string: " [exception RIP: get_next_timer_interrupt+440]" You can recover the operating system by rebooting the host OS and restarting the application as required. | link:https://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=1148090[1148090^] | Kernel disruption occurs on RHEL 7.5 with QLogic QLE2742 32GB FC HBA during storage failover operations | During storage failover operations on the Red Hat Enterprise Linux (RHEL) 7.5 kernel with a QLogic QLE2742 Fibre Channel (FC) host bus adapter (HBA), a kernel disruption occurs due to a panic in the kernel. The kernel panic causes RHEL 7.5 to reboot, which leads to an application disruption. If the kdump mechanism is enabled, the kernel panic generates a vmcore file located in the /var/crash/ directory. You can analyze the vmcore file to determine the cause of the panic. In this instance, when storage failover with the QLogic QLE2742 HBA event occurs, the "native_queued_spin_lock_slowpath+464" module is affected. You can locate the event in the vmcore file by finding the following string: " [exception RIP: native_queued_spin_lock_slowpath+464]" After the kernel disruption, you can reboot the Host OS and recover the operating system, and then you can restart the applications as required. | link:https://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=1146898[1146898^] | Kernel disruption occurs on RHEL 7.5 with Emulex HBAs during storage failover operations | During storage failover operations on a Red Hat Enterprise Linux (RHEL) 7.5 system with Emulex LPe32002-M2 32-GB FC host bus adapters (HBAs), a disruption in the kernel occurs. The kernel disruption causes a reboot of the operating system, which in turn causes an application disruption. If you configure kdump, the kernel disruption generates the vmcore file under the /var/crash/ directory. You can use the vmcore file to determine the cause of the failure. In the following example, you can see the disruption in the "lpfc_hba_clean_txcmplq+368" module. This disruption is logged in the vmcore file with the following string: " [exception RIP: lpfc_hba_clean_txcmplq+368]" After the kernel disruption, reboot the host OS to recover the operating system. Restart the application as required. |=== // 2024 SEP 2, ONTAPDOC-2345