Cours NetApp — stockage bloc (ONTAP SAN)

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. situer ONTAP SAN par rapport aux autres gammes NetApp et au stockage fichier ;
2. expliquer la chaîne SVM → volume → LUN (ou espace de noms NVMe) → igroup (ou sous-système NVMe) → hôte, et la lire sur un schéma ;
3. distinguer iSCSI, FC et NVMe/FC / NVMe/TCP et leurs identifiants (IQN, WWPN, NQN) ;
4. comprendre le provisionnement fin/épais, la réserve d'espace et ses conséquences sur la sécurité des écritures ;
5. expliquer ce qu'est un snapshot de volume pour une LUN, et ce que « restaurer » détruit ;
6. lire un état multipath côté hôte (ESXi, Linux, Windows) et reconnaître des chemins optimisés et non optimisés ;
7. classer des commandes en lecture seule ou à effet notable, avant de les proposer.

Prérequis

• Notions de réseau IP (VLAN, MTU, adresse, routage) et, pour FC, de zoning.
• Notions de stockage bloc : disque, partition, système de fichiers, LUN.
• Avoir lu en diagonale la page « SAN management overview » (source 1).
• Accès, en lecture seule, à une instance ONTAP de laboratoire si l'on veut pratiquer ; sinon les exercices restent sur papier.
• Aucune version d'ONTAP n'est supposée : les exigences liées à une version sont signalées « à partir de 9.x » telles que les pages officielles les énoncent.

Parcours et chapitres

1. Situer la famille de produits

D'après les pages consultées :

Question pour Stéphane : quelles gammes sont réellement utilisées ? Le cours ne choisit pas à sa place ; si E-Series ou une offre cloud est utilisée, un cours dédié sera nécessaire.

Point d'attention de vocabulaire : la page sur la configuration hôte ESXi affiche une règle VMW_SATP_ALUA pour « NetApp E-Series arrays with ALUA support » (PSP par défaut VMW_PSP_MRU) distincte de celle des baies NetApp ONTAP (VMW_PSP_RR). Un hôte peut donc voir plusieurs familles à la fois.

2. Architecture logique ONTAP pour le bloc

Les pages ONTAP décrivent, pour iSCSI et FC, des cibles de stockage appelées LUN (unités logiques) présentées aux hôtes comme des périphériques bloc standards. On crée les LUN, puis on les mappe à des igroups (groupes d'initiateurs), « tables » de WWPN FC et de noms de nœuds iSCSI qui décident quels initiateurs voient quelles LUN.

Chaîne logique :

Hôte (initiateur : IQN ou WWPN ou NQN)
   -> igroup (ou sous-système NVMe)
   -> mappage de LUN (ou d'espace de noms)
   -> LUN dans /vol/<volume>/<lun>
   -> volume FlexVol d'une SVM (machine virtuelle de stockage)
   -> agrégat / niveau local sur le nœud propriétaire

Règles lues dans la documentation :

• une igroup peut contenir plusieurs initiateurs ; plusieurs igroups peuvent contenir le même initiateur, mais on ne peut pas mapper une LUN à plusieurs igroups ayant le même initiateur ;
• un initiateur ne peut pas appartenir à des igroups de types d'OS différents ;
• les LUN se créent à la racine d'un volume ou d'un qtree, pas dans le volume racine de la SVM ;
• la documentation ne recommande pas de placer LUN SAN et partages NAS dans le même volume FlexVol ;
• l'ALUA est toujours activé à la création d'une LUN et ne peut pas être modifié ;
• pour FC, la page de provisionnement exige un zonage à initiateur unique pour les LIF FC de la SVM.

3. Protocoles : iSCSI, FC, NVMe

iSCSI et FC. FC est présenté avec des commutateurs FC et des adaptateurs côté hôte, les cibles étant identifiées par des WWPN ; iSCSI s'appuie sur des cartes Ethernet (ou HBA/CNA) et des noms IQN.

NVMe. Les pages « Provision NVMe storage » et de configuration hôte ESXi indiquent que :

• il faut créer un ou plusieurs espaces de noms (namespaces) et sous-systèmes, puis mapper chaque espace de noms à un sous-système ;
• si la SVM possède des interfaces NVMe/FC et NVMe/TCP, les espaces de noms d'un sous-système sont accessibles par les deux transports ; pour un accès par protocole, une SVM par protocole est conseillée ;
• NVMe/FC est pris en charge à partir d'ONTAP 9.4 (page ONTAP) ; pour ESXi 8, la page hôte indique NVMe/FC à partir d'ONTAP 9.9.1 P3 et NVMe/TCP à partir d'ONTAP 9.10.1 ;
• NVMe/TCP ne prend pas en charge l'auto-connexion : la découverte se fait par des opérations manuelles connect / connect-all (page hôte consultée pour les hôtes Linux ; à relire pour votre OS) ;
• l'accès multi-chemin NVMe utilise ANA (équivalent d'ALUA).

Le support exact d'une combinaison {ONTAP, OS hôte, adaptateur, protocole} est décidé par l'Interoperability Matrix Tool (IMT) de NetApp, qui se consulte pour chaque configuration ; ce cours n'en donne aucune.

4. Préparer la SVM pour iSCSI (lecture, puis changement)

La page « Configure an SVM for iSCSI » indique :

• au minimum une LIF iSCSI par nœud pour chaque SVM servant l'iSCSI ; pour la redondance, au moins deux LIF par nœud ;
• à partir d'ONTAP 9.19.1, les systèmes AFF prennent en charge le multi-chemin actif-actif avec bascule automatique de LIF au niveau SVM ; l'option doit être activée à la création de la SVM ;
• tâche à réaliser en tant qu'administrateur de cluster.

Commandes citées par la page (exemple, non exécuté) :

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

vserver iscsi create -vserver svm_demo -target-alias svm_demonetwork interface create -vserver svm_demo -lif lif_iscsi_demo_1 -data-protocol iscsi -service-policy default-data-iscsi -home-node node_demo_1 -home-port e0c -address 192.0.2.11 -netmask 255.255.255.0network interface show -vserver svm_demo

• Contexte : CLI ONTAP 9.6 ou ultérieur pour la forme avec -service-policy (la page donne une autre forme avec -role data pour 9.5 et antérieur). La variante exacte dépend de la version : à relire pour la version déployée.
• Droits : administrateur de cluster.
• Effet : active le service iSCSI de la SVM et crée une interface réseau de données ; modifie la configuration réseau de la SVM.
• Vérification : network interface show -vserver svm_demo affiche la LIF avec la politique attendue.
• Retour arrière : suppression de la LIF et du service (commandes non détaillées ici ; à vérifier dans la référence).
• Ne jamais lancer en production sans validation.

5. Volumes et provisionnement de l'espace

La page « Learn about SAN volume provisioning » décrit trois modes :

Une LUN space-reserved a son espace alloué à la création ; la page de la commande lun create indique que par défaut une LUN créée est en ligne et space-reserved, et que pour une LUN non réservée, des écritures peuvent échouer par manque d'espace, ce qui peut faire planter l'application ou l'OS hôte.

La réserve fractionnaire (fractional reserve, ou « LUN overwrite reserve ») est un attribut du volume qui ne prend que les valeurs 0 ou 100 %. À 0, l'utilisation du stockage augmente mais une application peut subir une interruption si le volume est plein ; la page énumère les conditions cumulatives (pas de déduplication ni de compression, snapshots à suppression automatique, etc.) d'une garantie d'écriture « au mieux » ; si elles ne sont pas toutes remplies et qu'il faut garantir l'espace, la page indique de régler la réserve fractionnaire à 100.

6. Créer une LUN, une igroup et un mappage

Les pages de référence de commandes (version 9.19.1) décrivent les trois commandes suivantes. Les valeurs sont synthétiques.

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

lun create -vserver svm_demo -volume vol_demo -lun lun_demo -size 100g -ostype linux -space-reserve enabledlun igroup create -vserver svm_demo -igroup igroup_demo -protocol iscsi -ostype linux -initiator iqn.2026-01.test.example:hote-demolun mapping create -vserver svm_demo -path /vol/vol_demo/lun_demo -igroup igroup_demo

Contexte et précautions :

• Contexte : CLI ONTAP 9 ; syntaxe lue dans la référence 9.19.1, à comparer à la référence de la version réellement déployée (le sélecteur de version de la documentation permet de le faire). Le volume doit exister et la SVM doit déjà avoir un service FC ou iSCSI et des LIF (pour mapper, il faut au moins une LIF iSCSI ou FCP sur le nœud propriétaire de la LUN et sur son partenaire HA).
• Droits : administrateur de cluster ou de SVM au niveau admin (la référence indique ce niveau de disponibilité).
• Effet : lun create consomme de l'espace (ou le réserve) et la taille réelle peut être supérieure à celle demandée (le système le signale) ; lun igroup create crée une igroup vide, sauf si -initiator est fourni ; lun mapping create rend la LUN visible par tous les initiateurs de l'igroup.
• Vérification : lun show, lun igroup show, lun mapping show côté ONTAP ; côté hôte : redécouverte (rescan) puis présence d'un seul disque multipath (chapitre 8).
• Retour arrière : lun mapping delete (retire la visibilité), puis lun delete (détruit la LUN) ; voir chapitre 9 pour les risques.
• Piège : le nom d'une igroup est indépendant du nom d'hôte DNS ; il ne faut pas en déduire une association automatique.
• Piège : les identifiants (IQN, WWPN, NQN) sont des données d'infrastructure ; ne jamais les copier dans ce corpus.
• Ne jamais lancer en production sans validation.

Sélective LUN Map (SLM). Page « Selective LUN Map overview » : SLM limite les chemins vers la LUN aux seuls nœuds propriétaire et partenaire HA ; il est activé par défaut sur toute nouvelle carte de LUN. Avant de déplacer une LUN ou un volume vers une autre paire HA, la page demande de modifier la liste reporting-nodes (commandes lun mapping add-reporting-nodes / remove-reporting-nodes), de re-scanner l'hôte, de vérifier que l'E/S passe par un chemin actif optimisé, puis de retirer les anciens nœuds. Opération à effet notable : à planifier.

7. Snapshots de volume et LUN

Une LUN vit dans un volume : les snapshots d'ONTAP sont pris au niveau du volume (la page de commande « volume snapshot create » parle de snapshot d'un volume). Commandes de référence :

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

volume snapshot create -vserver svm_demo -volume vol_demo -snapshot snap_demo_1volume snapshot show -vserver svm_demo -volume vol_demo

(La page de volume snapshot show n'a pas été lue : syntaxe de cette seconde ligne non vérifiée, à contrôler dans la référence.)

• Contexte : CLI ONTAP 9, SVM et volume de démonstration (svm_demo, vol_demo) ; droits d'administration du stockage ; version d'ONTAP de Stéphane non confirmée.
• Droits : administration du stockage (voir Contexte).
• Effet : crée une copie de l'état du volume (et donc de ses LUN) ; consomme de l'espace au fil des modifications. La cohérence applicative (cohérence « crash » ou applicative) n'est pas abordée par la page de commande : non vérifié dans ce cours.
• Vérification : la liste des snapshots affiche snap_demo_1.
• Retour arrière : supprimer le snapshot de démonstration (volume snapshot delete, page non relue : non vérifié).

Restaurations (effets importants) :

• volume snapshot restore : la page indique que la commande remplace la copie de travail du volume par le snapshot, ce qui entraîne la perte de toutes les modifications faites depuis ; il faut mettre à jour manuellement les relations SnapMirror juste après. Le paramètre -preserve-lun-ids conditionne le comportement vis-à-vis des identifiants de LUN / espaces de noms ; s'il est à false, la page conseille de mettre les LUN hors ligne au préalable.
• volume snapshot restore-file : permet de restaurer un fichier, une LUN ou un espace de noms NVMe depuis un snapshot ; ne restaure pas de répertoires ; la destination doit être dans le même volume.
• volume snapshot delete : supprime un snapshot ; ne pas utiliser -force (niveau avancé) hors procédure validée.

Ne jamais lancer ces commandes en production sans validation. Avant toute restauration : identifier l'hôte, quiescer les écritures, noter la liste des LUN concernées, et prévoir un retour arrière (par exemple un snapshot pris juste avant la restauration — non vérifié comme pratique recommandée par NetApp dans les pages consultées).

8. Multipath et MPIO côté hôte

Le multi-chemin masque plusieurs chemins physiques derrière un seul disque logique ; sans lui, l'OS peut voir chaque chemin comme un disque distinct.

• Windows. La page Windows Host Utilities 2022 explique que MPIO se compose du module spécifique du matériel (DSM) et de Windows MPIO ; MPIO présente un disque pour tous les chemins ; sans MPIO « l'OS pourrait voir chaque chemin comme un disque distinct, ce qui peut entraîner une corruption de données ». L'outil mpclaim -s -d <n> affiche l'état d'un disque MPIO dans les exemples de la page.
• Linux. La page Ubuntu 24.04 montre multipath -ll et indique que les paramètres par défaut conviennent aux configurations ASA, AFF et FAS ; une LUN ONTAP ne devrait pas nécessiter plus de quatre chemins, au-delà des problèmes peuvent apparaître en cas de panne de stockage. La sortie d'exemple montre deux groupes de chemins avec priorités différentes (optimisés / non optimisés).
• ESXi. La page ESXi/vSphere 8.x indique que VMW_SATP_ALUA est le SATP utilisé pour ONTAP avec VMW_PSP_RR par défaut, et fournit les commandes esxcli storage nmp device list -d <naa> et esxcli storage nmp path list -d <naa>. Pour les configurations non-ASA, il doit y avoir deux groupes de chemins : actifs optimisés et actifs non optimisés (ces derniers ne servent que si les optimisés sont perdus). La page de réglages recommandés (réglages ESXi pour ONTAP) cite aussi Disk.QFullSampleSize à 32 et Disk.QFullThreshold à 8 ; ces réglages sont appliqués normalement par les outils NetApp pour vSphere, à vérifier.

Les SAN Host Utilities (Windows, Linux, AIX, HP-UX, Solaris) sont décrites comme recommandées si elles existent pour l'hôte ; l'IMT indique la version à installer.

9. Opérations à risque : redimensionner, démapper, supprimer

Les effets suivants sont extraits des pages de commande 9.19.1.

Pour chaque opération : écrire le contexte, les droits, l'effet attendu, la vérification, le retour arrière (par exemple un snapshot préalable pour un redimensionnement à la baisse) et ne jamais la lancer en production sans validation. L'exercice pratique se fait uniquement sur une instance de laboratoire isolée.

10. Diagnostic de premier niveau

Questions à poser dans l'ordre, sans modifier :

1. L'hôte voit-il la cible (session iSCSI, connexion FC / NVMe) ?
2. L'initiateur (IQN, WWPN, NQN) est-il dans la bonne igroup / le bon sous-système, avec le bon type d'OS ?
3. La LUN est-elle mappée, en ligne, avec un identifiant unique pour l'initiateur ?
4. Les chemins sont-ils tous présents et groupés en un seul disque ?
5. Les LIF du nœud propriétaire et de son partenaire HA sont-elles actives ? (condition de mappage citée par la référence)
6. La combinaison ONTAP / OS / carte / protocole figure-t-elle dans l'IMT ?

Commandes de lecture seule citées dans les pages : lun show, lun igroup show, lun mapping show (avec -fields reporting-nodes,node pour SLM), vserver iscsi show, network interface show, côté ESXi esxcli nvme info get, esxcli nvme adapter list, esxcfg-mpath -b.

11. Cycle de vérification

À chaque relecture : rouvrir les pages, noter la version la plus récente affichée, la date de dernière mise à jour des pages, comparer à la version de Stéphane (à fournir), et conserver ce document en brouillon jusqu'à validation.

Exercices et vérifications de fin de cours

Les exercices 1 à 5 sont sur papier ou en lecture seule.

1. Gammes. Remplir le tableau du chapitre 1 pour l'environnement de Stéphane (réponse à fournir par lui) ; lister ce qui reste non couvert.
2. Schéma. Dessiner la chaîne hôte → igroup → LUN → volume → SVM pour deux hôtes ESXi fictifs en cluster partageant une LUN et un hôte Windows fictif avec une LUN privée.
3. Identifiants. Pour chaque protocole, donner le format de l'identifiant d'initiateur (IQN, WWPN, NQN) avec une valeur synthétique.
4. Espace. Pour un volume fictif de 1 To en mode fin avec 3 LUN de 500 Go, expliquer le risque d'écriture refusée et deux contre-mesures citées par les pages (volume épais, surveillance de l'agrégat, autogrow avec suivi, réserve fractionnaire à 100).
5. Classement. Classer chaque commande de ce cours : lecture, création, modification, destruction, et indiquer pour chacune le retour arrière.
6. Facultatif — laboratoire isolé uniquement. Sur une instance de test sans donnée réelle, avec accord de Stéphane : exécuter les commandes du chapitre 6, vérifier, puis revenir en arrière par lun mapping delete et lun delete.

Critères de réussite

• Savoir dire quelles gammes NetApp sont couvertes ou exclues.
• Expliquer pourquoi une LUN mappée à deux igroups partageant un initiateur est refusée.
• Décrire ce que perd un volume snapshot restore.
• Distinguer chemin optimisé et non optimisé sur une sortie multipath.
• Citer la version de documentation consultée sans la confondre avec la version de production.