JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Guide d'administration des systèmes Oracle® ZFS Storage Appliance
Oracle Technology Network
Bibliothque
PDF
Aperu avant impression
Commentaires
search filter icon
search icon

Informations document

Utilisation de la présente documentation

Chapitre 1 Présentation d'Oracle ZFS Storage Appliance

Chapitre 2 Statut

Chapitre 3 Configuration initiale

Chapitre 4 Configuration réseau

Page de configuration réseau

Périphériques

Liaisons de données

Interfaces réseau

MultiPathing IP réseau (IPMP)

Performances et disponibilité du réseau

Configuration de routage réseau

Entrées de routage réseau

Propriétés de routage réseau

Configuration du réseau à l'aide de la BUI

Page de configuration réseau

Adresses réseau

Page de routage réseau

Configuration du réseau à l'aide de la CLI

Tâches de configuration du réseau à l'aide de la BUI

Création d'une interface à port unique

Modification d'une interface

Création d'une interface à port unique, glisser-déplacer

Création d'une interface de liaison groupée LACP

Création d'un groupe IPMP à l'aide de la détection des défaillances basée sur sondes et sur l'état des liaisons

Création d'un groupe IPMP à l'aide de la détection des défaillances basée uniquement sur l'état des liaisons

Extension d'un groupement LACP

Extension d'un groupe IPMP

Création d'une liaison de données et d'une interface de partition InfiniBand

Création d'un VNIC sans ID de VLAN pour des contrôleurs en cluster

Création de VNIC avec le même ID de VLAN pour des contrôleurs en cluster

Ajout d'une route statique

Suppression d'une route statique

Tâches de configuration du réseau à l'aide de la CLI

Ajout d'une route statique

Suppression d'une route statique

Réglage de la propriété de multihébergement sur strict

Chapitre 5 Configuration de stockage

Chapitre 6 Configuration du réseau de stockage SAN

Chapitre 7 Configuration utilisateur

Chapitre 8 Définition des préférences de ZFSSA

Chapitre 9 Configuration des alertes

Chapitre 10 Configuration de cluster

Chapitre 11 Services ZFSSA

Chapitre 12 Partages, projets et schéma

Chapitre 13 Réplication

Chapitre 14 Migration shadow

Chapitre 15 Ecriture de scripts à l'aide de la CLI

Chapitre 16 Maintenance des workflows

Chapitre 17 Intégration

Index

MultiPathing IP réseau (IPMP)

Les groupes IP MultiPathing servent à fournir des adresses IP qui restent disponibles en cas de défaillance d'une interface IP (due à la déconnexion d'un câble physique ou à une défaillance de la connexion entre un périphérique réseau et son commutateur par exemple), ou en cas de défaillance du chemin entre le système et ses passerelles système. Le système détecte les défaillances en surveillant les notifications de fonctionnement ou de défaillance de la liaison de données sous-jacente de l'interface IP et, de façon optionnelle, en effectuant des vérifications à l'aide d'adresses de test pouvant être assignées à chaque interface IP du groupe, comme décrit plus bas. Il est possible de placer un nombre quelconque d'interfaces IP dans un groupe IPMP, à condition qu'elles se trouvent toutes sur la même liaison (LAN, partition IB ou VLAN) ; de même, il est possible d'assigner un nombre quelconque d'adresses haute disponibilité à un groupe IPMP.

Au sein d'un groupe IPMP, chaque interface IP est désignée soit comme <i>active</i> ou <i>de secours</i> :

Il est possible de configurer plusieurs interfaces IP actives et de secours, mais chaque groupe IPMP doit être configuré avec une interface IP active au moins. IPMP s'efforce d'activer autant d'interfaces IP de secours que nécessaire pour préserver le nombre d'interfaces actives configuré. Si un groupe IPMP est configuré avec deux interfaces actives et deux interfaces de secours par exemple et que toutes les interfaces fonctionnent correctement, seules les deux interfaces actives sont utilisées pour envoyer et recevoir des données. Si une interface active subit une panne, l'une des interfaces de secours est activée. Si l'autre interface active est défaillante (ou l'interface de secours activée tombe en panne), la seconde interface de secours est activée. Si, par la suite, les interfaces activées sont réparées, les interfaces de secours sont à nouveau désactivées.

Les interfaces IP peuvent être détectées par la détection via les liens ou via la détection par sonde (c'est-à-dire qu'une adresse de test est configurée).

Si la détection des défaillances basée sur sondes est activée sur une interface IP, le système détermine les systèmes cible à sonder de manière dynamique. La table de routage est tout d'abord analysée pour identifier les passerelles (routeurs) situées sur le même sous-réseau que l'adresse de test de l'interface IP, et jusqu'à cinq d'entre elles sont sélectionnées. Si aucune passerelle n'est trouvée sur le même sous-réseau, le système envoie une sonde ICMP multidiffusion (à 224.0.01. pour IPv4 ou ff02::1 pour IPv6) et sélectionne les cinq premiers systèmes situés sur le même sous-réseau qui envoient une réponse. Lors de la détection et de la réparation des défaillances réseau à l'aide d'IPMP, vous avez ainsi la garantie qu'au moins un voisin sur chaque liaison ou que la passerelle par défaut répond aux demandes d'écho ICMP. IPMP fonctionne aussi bien avec des configurations d'adresse IPv4 qu'avec des configurations d'adresse IPv6. Dans le cas d'IPv6, l'adresse liaison locale est utilisée en tant qu'adresse de test.


Remarque -  N'utilisez pas la détection des défaillances basée sur sondes lorsqu'aucun système (autre que le pair du cluster) sur le même sous-réseau que les adresses IPMP de test n'est configuré pour répondre aux demandes d'écho ICMP.

Le système sonde les systèmes cible à tour de rôle. Si cinq sondes successives restent sans réponse, l'interface IP est considérée comme défaillante. Inversement, s'il obtient des réponses à dix sondes successives, le système considère comme réparée une interface IP précédemment défaillante. Vous pouvez définir la valeur de temps de la détection des défaillances par sondes IPMP du système dans l'écran IPMP. Cette valeur détermine de manière indirecte le taux d'envoi des sondes et l'intervalle de réparation : un temps de détection des défaillances de 10 secondes, par exemple, signifie que le système envoie des sondes à intervalles de deux secondes environ et que le système aura besoin de 20 secondes pour détecter une réparation d'interface basée sur sondes. Vous ne pouvez pas contrôler directement les systèmes cible sélectionnés par le système, mais vous pouvez les contrôler de manière indirecte par le biais de la table de routage.

Le système surveille la table de routage et, le cas échéant, ajuste automatiquement les systèmes cible sélectionnés. Par exemple, si le système utilise des cibles détectées par multidiffusion, mais qu'une route comportant une passerelle sur le même sous-réseau que l'adresse de test de l'interface IP est ajoutée par la suite, le système passe automatiquement à l'envoi de sondes à la passerelle. De même, s'il procède à l'envoi de sondes à des cibles détectées par multidiffusion, le système actualise régulièrement l'ensemble de cibles sélectionnées, par exemple parce que des cibles précédemment sélectionnées ne répondent plus.

Vous trouverez des instructions détaillées sur la création de groupes IPMP dans la section MultiPathing IP réseau (IPMP) .

Pour plus d'informations sur les interfaces locales privées, reportez-vous au Chapter 10, Configuration de cluster.