La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Interfaces logiques

01/12/2026 Contributeurs

Les bases de données Oracle doivent accéder au stockage. Les interfaces logiques (LIF) correspondent à la tuyauterie réseau qui connecte une machine virtuelle de stockage (SVM) au réseau et, par conséquent, à la base de données. Une conception correcte des LIF est requise pour s'assurer qu'il y a suffisamment de bande passante pour chaque charge de travail de la base de données, et le basculement ne provoque pas de perte des services de stockage.

Cette section présente un aperçu des principaux principes de conception LIF pour les systèmes ASA r2, qui sont optimisés pour les environnements SAN uniquement. Pour une documentation plus complète, consultez le "Documentation de gestion de réseau ONTAP". Comme pour d'autres aspects de l'architecture de base de données, les meilleures options pour la conception de la machine virtuelle de stockage (SVM, connue sous le nom de vserver dans l'interface de ligne de commande) et de l'interface logique (LIF) dépendent fortement des exigences d'évolutivité et des besoins de l'entreprise.

Tenez compte des principaux sujets suivants lors de l'élaboration d'une stratégie LIF :

Performance. La bande passante du réseau est-elle suffisante pour les charges de travail Oracle ?
Résilience. y a-t-il des points de défaillance uniques dans la conception?
Gérabilité. le réseau peut-il être mis à l'échelle sans interruption ?

Ces rubriques s'appliquent à la solution de bout en bout, de l'hôte aux commutateurs et au système de stockage.

Types de LIF

Il existe plusieurs types de LIF. "Documentation ONTAP sur les types de LIF" Fournir des informations plus complètes à ce sujet, mais d'un point de vue fonctionnel, les LIF peuvent être divisées en plusieurs groupes :

LIFs de gestion de clusters et de nœuds. utilisées pour gérer le cluster de stockage.
LIF de gestion SVM. interfaces permettant l'accès à une SVM via l'API REST ou ONTAPI (aussi connue sous le nom de ZAPI) pour des fonctions telles que la création de snapshots ou le redimensionnement de volumes. Des produits tels que SnapManager pour Oracle (SMO) doivent avoir accès à une LIF de gestion SVM.
LIF de données. Interfaces pour protocoles SAN uniquement : FC, iSCSI, NVMe/FC, NVMe/TCP. Les protocoles NAS (NFS, SMB/CIFS) ne sont pas pris en charge sur les systèmes ASA r2.

Il n'est pas possible de configurer une interface à la fois pour le trafic iSCSI (ou NVMe/TCP) et le trafic de gestion, bien que les deux utilisent un protocole IP. Une interface LIF de gestion distincte est requise dans les environnements iSCSI ou NVMe/TCP. Pour garantir la résilience et les performances, configurez plusieurs LIF de données SAN par protocole et par nœud, et répartissez-les sur différents ports et infrastructures physiques. Contrairement aux systèmes AFF/ FAS , ASA r2 n'autorise pas le trafic NFS ou SMB, il n'y a donc aucune possibilité de réutiliser une LIF de données NAS pour la gestion.

Conception de SAN LIF

La conception de LIF dans un environnement SAN est relativement simple pour une raison : les chemins d'accès multiples. Toutes les implémentations SAN modernes permettent à un client d'accéder aux données sur plusieurs chemins réseau indépendants et de sélectionner le ou les chemins d'accès les plus adaptés. Par conséquent, les performances du design LIF sont plus simples à gérer, car les clients SAN équilibrent automatiquement la charge en E/S sur les meilleurs chemins disponibles.

Si un chemin devient indisponible, le client sélectionne automatiquement un autre chemin. La simplicité de conception qui en résulte rend les LIF SAN généralement plus faciles à gérer. Cela ne signifie pas pour autant qu'un environnement SAN est toujours plus facile à gérer, car de nombreux autres aspects du stockage SAN sont bien plus complexes que NFS. Cela signifie simplement que la conception de la LIF SAN est plus facile.

Performance

Le facteur le plus important à prendre en compte concernant les performances des interfaces LIF dans un environnement SAN est la bande passante. Par exemple, un cluster ASA r2 à deux nœuds avec deux ports FC 32Gb par nœud permet jusqu'à 64Gb de bande passante vers/depuis chaque nœud. De même, pour NVMe/TCP ou iSCSI, assurez-vous d'une connectivité suffisante de 25 GbE ou 100 GbE pour les charges de travail Oracle.

Résilience

Les interfaces logiques SAN ne basculent pas de la même manière que les interfaces logiques NAS. Les systèmes ASA r2 s'appuient sur le multipathing hôte (MPIO/ALUA) pour assurer la résilience. Si une interface LIF SAN devient indisponible en raison d'un basculement du contrôleur, le logiciel de gestion de chemins multiples du client détecte la perte d'un chemin et redirige les E/S vers un chemin alternatif. ASA r2 peut effectuer une relocalisation LIF après un court délai pour rétablir la disponibilité complète du chemin, mais cela n'interrompt pas les E/S car des chemins actifs existent déjà sur le nœud partenaire. Le processus de basculement a lieu afin de rétablir l'accès à l'hôte sur tous les ports définis.

Gestion aisée

Il n'est pas nécessaire de migrer une LIF dans un environnement SAN lorsque les volumes sont déplacés au sein de la paire HA. En effet, une fois le déplacement du volume terminé, ONTAP envoie une notification au SAN concernant un changement de chemin, et les clients SAN se réoptimisent automatiquement. La migration LIF vers SAN est principalement associée à des changements matériels physiques majeurs. Par exemple, si une mise à niveau non perturbatrice des contrôleurs est nécessaire, une interface SAN LIF est migrée vers le nouveau matériel. Si un port FC s'avère défectueux, une LIF peut être migrée vers un port inutilisé.

Recommandations de conception

NetApp formule les recommandations suivantes pour les environnements SAN ASA r2 :

Ne créez pas plus de chemins que nécessaire. Un nombre excessif de chemins complique la gestion globale et peut entraîner des problèmes de basculement de chemin sur certains hôtes. De plus, certains hôtes ont des limites de chemin inattendues pour les configurations comme le démarrage SAN.
Très peu de configurations doivent nécessiter plus de quatre chemins vers une LUN. L'intérêt d'avoir plus de deux nœuds de chemins publicitaires vers les LUN est limité, car l'agrégat hébergeant une LUN est inaccessible en cas de défaillance du nœud qui détient la LUN et de son partenaire haute disponibilité. Dans ce cas, la création de chemins sur des nœuds autres que la paire haute disponibilité principale n'est pas utile.
Même si vous pouvez gérer le nombre de chemins de LUN visibles en sélectionnant les ports inclus dans les zones FC, il est généralement plus facile d'inclure tous les points cibles potentiels dans la zone FC et de contrôler la visibilité des LUN au niveau des ONTAP.
Utilisez la fonction de mappage LUN sélectif (SLM), activée par défaut. Avec SLM, tout nouveau LUN est automatiquement annoncé à partir du nœud qui possède l'agrégat sous-jacent et du partenaire HA du nœud. Cette configuration évite d'avoir à créer des ensembles de ports ou à configurer un zonage pour limiter l'accessibilité des ports. Chaque LUN est disponible sur le nombre minimal de nœuds requis pour des performances et une résilience optimales.
Si une LUN doit être migrée en dehors des deux contrôleurs, les nœuds supplémentaires peuvent être ajoutés avec le lun mapping add-reporting-nodes commande permettant d'annoncer les LUN sur les nouveaux nœuds. Cela crée des chemins SAN supplémentaires vers les LUN pour la migration des LUN. Toutefois, l'hôte doit effectuer une opération de découverte pour utiliser les nouveaux chemins.
Ne vous souciez pas trop du trafic indirect. Dans un environnement très exigeant en E/S, il est préférable d'éviter le trafic indirect pour lequel chaque microseconde de latence est critique, mais l'impact visible sur la performance est négligeable pour les charges de travail classiques.