Skip to main content
SAN hosts and cloud clients
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Utilisez Red Hat Enterprise Linux 6.9 avec ONTAP

Contributeurs

Vous pouvez utiliser les paramètres de configuration de l'hôte SAN ONTAP pour configurer Red Hat Enterprise Linux 6.9 avec ONTAP comme cible.

Installez Linux Unified Host Utilities

Le progiciel Utilitaires hôtes unifiés NetApp Linux est disponible sur le "Site de support NetApp"dans un fichier .rpm 32 bits et 64 bits. Si vous ne savez pas quel fichier est adapté à votre configuration, utilisez le "Matrice d'interopérabilité NetApp" pour vérifier lequel vous avez besoin.

NetApp recommande fortement d'installer les utilitaires d'hôtes unifiés Linux, mais ce n'est pas obligatoire. Les utilitaires ne modifient aucun paramètre sur votre hôte Linux. Ces utilitaires améliorent la gestion et aident le support client NetApp à collecter des informations sur votre configuration.

Si Linux Unified Host Utilities est actuellement installé, vous devez soit le mettre à niveau vers la dernière version, soit le supprimer et suivre ces étapes pour installer la dernière version.

Étapes
  1. Téléchargez le pack logiciel Linux Unified Host Utilities 32 bits ou 64 bits à partir du "Site de support NetApp" à votre hôte.

  2. Installez le pack logiciel :

    rpm -ivh netapp_linux_unified_host_utilities-7-1.x86_64

Remarque Vous pouvez utiliser les paramètres de configuration fournis dans ce document pour configurer les clients Cloud connectés à "Cloud Volumes ONTAP" et "Amazon FSX pour ONTAP".

Kit D'outils SAN

Le kit d'outils est installé automatiquement lorsque vous installez le pack NetApp Host Utilities. Ce kit contient le sanlun Utilitaire, qui vous aide à gérer les LUN et les HBA. Le sanlun La commande renvoie les informations relatives aux LUN mappées sur votre hôte, aux chemins d'accès multiples et aux informations nécessaires à la création des groupes initiateurs.

Exemple

Dans l'exemple suivant, le sanlun lun show La commande renvoie les informations relatives à la LUN.

# sanlun lun show all

Exemple de résultat :

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 Booting

Ce dont vous avez besoin

Si vous décidez d'utiliser le démarrage SAN, celui-ci doit être pris en charge par votre configuration. Vous pouvez utiliser le "Matrice d'interopérabilité NetApp" Pour vérifier que votre système d'exploitation, votre adaptateur de bus hôte, votre micrologiciel HBA, votre BIOS de démarrage HBA et votre version de ONTAP sont pris en charge.

Étapes
  1. Mappez la LUN de démarrage SAN sur l'hôte.

  2. Vérifiez que plusieurs chemins sont disponibles.

    Remarque Plusieurs chemins deviennent disponibles une fois que le système d'exploitation hôte est opérationnel sur les chemins.
  3. Activez le démarrage SAN dans le BIOS du serveur pour les ports auxquels la LUN de démarrage SAN est mappée.

    Pour plus d'informations sur l'activation du BIOS HBA, reportez-vous à la documentation spécifique au fournisseur.

  4. Redémarrez l'hôte pour vérifier que le démarrage a réussi.

Chemins d'accès multiples

Pour Red Hat Enterprise Linux (RHEL) 6.9, le fichier /etc/multipath.conf doit exister, mais vous n'avez pas besoin d'apporter de modifications spécifiques au fichier. RHEL 6.9 est compilé avec tous les paramètres requis pour reconnaître et gérer correctement les LUN ONTAP. Pour activer le gestionnaire ALUA, effectuez les opérations suivantes :

Étapes
  1. Créez une sauvegarde de l'image initrd.

  2. Ajoutez la valeur de paramètre suivante au noyau pour ALUA et non-ALUA à fonctionner :
    rdloaddriver=scsi_dh_alua

    kernel /vmlinuz-2.6.32-358.6.1.el6.x86_64 ro root=/dev/mapper/ vg_ibmx355021082-lv_root rd_NO_LUKS rd_LVM_LV=vg_ibmx355021082/ lv_root LANG=en_US.UTF-8 rd_LVM_LV=vg_ibmx355021082/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet rdloaddriver=scsi_dh_alua
  3. Utilisez le mkinitrd commande pour recréer l'image-initrd. RHEL 6x et les versions ultérieures utilisent : la commande : mkinitrd -f /boot/ initrd-"uname -r".img uname -r`Ou la commande : `dracut -f

  4. Redémarrez l'hôte.

  5. Vérifiez la sortie du cat /proc/cmdline pour vérifier que le paramètre est terminé.

Vous pouvez utiliser le multipath -ll Commande pour vérifier les paramètres des LUN ONTAP.

Les sections suivantes fournissent des exemples de sorties multivoies pour une LUN mappée sur des rôles ASA et non ASA.

Configurations All SAN Array

Toutes les configurations de baie SAN (ASA) optimisent tous les chemins d'accès à une LUN donnée en les gardant actives. Ce qui améliore les performances en assurant le service des opérations d'E/S sur tous les chemins en même temps.

Exemple

L'exemple suivant illustre la sortie correcte d'une LUN ONTAP.

# multipath -ll
3600a0980383034466b2b4a3775474859 dm-3 NETAPP,LUN C-Mode
size=20G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
|- 1:0:8:1  sdb 8:16 active ready running
|- 2:0:8:1  sdd 8:48 active ready running
|- 1:0:9:1  sdc 8:32 active ready running
|- 2:0:9:1  sde 8:64 active ready running
Remarque Une seule LUN ne doit pas nécessiter plus de quatre chemins. La présence de plus de quatre chemins peut entraîner des problèmes de chemin pendant les pannes de stockage.

Configurations non ASA

Pour les configurations non ASA, il doit y avoir deux groupes de chemins avec des priorités différentes. Les chemins ayant des priorités plus élevées sont Active/Optimized (actif/optimisé), ce qui signifie que les services sont gérés par le contrôleur où se trouve l'agrégat. Les chemins aux priorités inférieures sont actifs, mais ne sont pas optimisés, car ils sont desservis par un autre contrôleur. Les chemins non optimisés ne sont utilisés que lorsque les chemins optimisés ne sont pas disponibles.

Exemple

L'exemple suivant montre la sortie correcte pour une LUN ONTAP avec deux chemins actifs/optimisés et deux chemins actifs/non optimisés.

# multipath -ll
3600a0980383034466b2b4a3775474859 dm-3 NETAPP,LUN C-Mode
size=20G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| |- 1:0:8:1  sdb 8:16 active ready running
| `- 2:0:8:1  sdd 8:48 active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
  |- 1:0:9:1  sdc 8:32 active ready running
  `- 2:0:9:1  sde 8:64 active ready running
Remarque Une seule LUN ne doit pas nécessiter plus de quatre chemins. La présence de plus de quatre chemins peut entraîner des problèmes de chemin pendant les pannes de stockage.

Paramètres recommandés

Le système d'exploitation RHEL 6.9 est compilé pour reconnaître les LUN ONTAP et définir automatiquement tous les paramètres de configuration pour les configurations ASA et non ASA.

Le multipath.conf fichier doit exister pour que le démon multichemin puisse démarrer. Si ce fichier n'existe pas, vous pouvez créer un fichier vide de zéro octet à l'aide de la touch /etc/multipath.conf commande.

Lors de la première création du multipath.conf fichier, vous devrez peut-être activer et démarrer les services multivoies en utilisant les commandes suivantes :

chkconfig multipathd on
/etc/init.d/multipathd start

Vous n'avez pas besoin d'ajouter des éléments directement au multipath.conf fichier, sauf si vous avez des périphériques que vous ne souhaitez pas gérer le multipathing ou si vous avez des paramètres existants qui remplacent les paramètres par défaut. Pour exclure les périphériques indésirables, ajoutez la syntaxe suivante au multipath.conf fichier, en remplaçant <DevId> par la chaîne d'identifiant universel (WWID) du périphérique à exclure :

blacklist {
        wwid <DevId>
        devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
        devnode "^hd[a-z]"
        devnode "^cciss.*"
}

L'exemple suivant détermine le WWID d'un périphérique et l'ajoute au multipath.conf fichier.

Étapes
  1. Déterminez le 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]
+

liste noire { wwid 3600a098038314c4a433f5774717a3046 devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" 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 | "round-robin 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.

valeurs par défaut { path_checker readsector0 no_path_retry fail }

Périphériques { device { vendor "NetApp" product "LUN.*" no_path_retry file path_Checker tur }

=== 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-problems-and-limitations]]
== Known issues

The RHEL 6.9 with ONTAP release has the following known issues:

[cols=3*,options="header"]
|===
| NetApp Bug ID
| Title
| Description
| link:https://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=1067272[1067272^] | Remote port status on EMULEX LPe32002 host might be in 'Blocked' state during storage failover operations | During storage failover operations, certain remote port status on RHEL 6.9 host with LPe32002 adapter might get into 'Blocked' state. Because the logical   interfaces go down when a storage node is down, the remote port sets the storage node status to "Blocked" state.  However, when the storage node comes back to optimal state, the logical interfaces also comes up and the remote port state is expected to be 'Online'.  But, on certain occasion the remote port continues to be in 'Blocked' state.  This state manifests as 'failed faulty' to LUNS at multipath layer.
| link:https://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=1076584[1076584^] | Firmware dumps occur on Red Hat Enterprise Linux 6.9 QLogic QE8362 HBA during storage failover operations | Firmware dumps can occur during storage failover operations on Red Hat Enterprise Linux (RHEL) 6.9 hosts with QLogic QLE8362 host bus adapters (HBA), firmware dumps are observed occasionally. The firmware dumps might manifest as an I/O outage on the host that can last as long as 1200 seconds. After the adapter completes dumping the firmware cores, the I/O operation resumes normally.  No further recovery procedure is required on the host. To indicate the firmware dump, the following message is displayed in /var/log/ message file: kernel: qla2xxx [0000:0c:00.3]-d001:3: Firmware dump saved to temp buffer (3/ffffc90018b01000), dump status flags (0x3f)
|===

// 2024 SEP 2, ONTAPDOC-2345