Go to main content
Guide d'administration des systèmes Oracle® ZFS Storage Appliance, version OS8.6.x

Quitter la vue de l'impression

Mis à jour : Septembre 2016
 
 

E/S d'interconnexion de cluster

Toute la communication entre les contrôleurs consiste en la transmission d'un ou de plusieurs messages via l'une des trois liaisons d'E/S de cluster fournies par le matériel CLUSTRON (reportez-vous à la section Controller Cluster I/O Ports dans Oracle ZFS Storage Appliance Cabling Guide). Ce périphérique permet deux liaisons série bas débit et une liaison Ethernet. L'utilisation des liaisons série offre une plus grande fiabilité car les liaisons Ethernet peuvent ne pas être traitées suffisamment vite par un système supportant une charge extrêmement lourde. La détection erronée de pannes et la reprise non souhaitée sont les pires manières pour un système clustérisé de répondre à une charge. Durant la reprise, les requêtes ne sont pas traitées et sont placées dans une file d'attente par les clients, ce qui entraîne une multitude de requêtes différées en plus d'une charge déjà lourde. Les liaisons série utilisées par les appareils de la série Oracle ZFS Storage Appliance ne sont pas sujets à ce type de panne. La liaison Ethernet offre de meilleures performances de transport pour les messages qui n'ont pas trait aux pulsations, notamment la synchronisation de réunion, et fournit un signal d'activité de sauvegarde.

Les trois liaisons sont formées à l'aide de câbles droits ordinaires EIA/TIA-568B (8 fils, Gigabit Ethernet). Pour autoriser l'utilisation de câbles droits entre deux contrôleurs identiques, vous devez utiliser les câbles pour connecter des sockets opposés sur les deux connecteurs, comme indiqué dans la section Connexion de câbles de cluster du Guide de câblage des systèmes Oracle ZFS Storage Appliance.

Les contrôleurs clustérisés ne communiquent jamais via un réseau de service ou d'administration. Leurs interconnexions ont lieu sur un réseau privé sécurisé. Les messages sont divisés en deux catégories générales : les pulsations régulières utilisées pour détecter la panne d'un contrôleur distant et le trafic de haut niveau associé au gestionnaire de ressources ainsi qu'au sous-système de gestion du cluster. Les pulsations sont envoyées et attendues sur les trois liaisons. Elles sont transmises en continu à intervalles fixes et ne sont jamais reconnues ni retransmises car elles sont toutes identiques et ne contiennent pas d'informations spécifiques. D'autres trafics peuvent être envoyés par l'intermédiaire d'une autre liaison quelconque, il s'agit généralement de la plus rapide disponible au moment de la transmission. Ce trafic est reconnu, vérifié puis retransmis si nécessaire pour garantir un transport fiable aux logiciels de niveau supérieur.

Quel que soit son type ou son origine, chaque message est envoyé en tant que paquet unique de 128 octets et contient une charge utile de données comprise entre 1 et 68 octets et une valeur de hachage de vérification de 20 octets visant à garantir l'intégrité des données. Les liaisons série s'exécutent à 115 200 bps avec 9 octets de données et un seul bit de démarrage et d'arrêt. La liaison Ethernet s'exécute à 1 Gbps. Par conséquent, la latence de message effective sur les liaisons série est d'environ 12,2 ms. La latence Ethernet varie énormément. Tandis que les temps d'attente standard s'expriment en microsecondes, les temps d'attente effectifs vers le logiciel de gestion de l'appareil peuvent être plus longs en raison de la charge du système.

Normalement, les pulsations sont envoyées par chaque contrôleur sur les trois liaisons d'E/S du cluster à 50 ms d'intervalle. L'impossibilité de réceptionner un message est considérée comme un échec de liaison après 200 ms (liaisons série) ou 500 ms (liaisons Ethernet). Si les trois liens échouent, le pair est considéré en échec ; l'arbitrage de la reprise est alors effectué. En cas de panique, le contrôleur concerné transmet un seul message de notification à chacune des liaisons série ; son pair effectue automatiquement la reprise indépendamment de l'état de ces autres liaisons. Compte tenu de ces caractéristiques, le sous-système de clustering peut normalement détecter l'échec de son pair dans un délai de :

  • 550 ms si le pair a arrêté de répondre ou n'est plus alimenté ;

  • 30 ms si le pair a rencontré une erreur logicielle fatale ayant déclenché une panique du système d'exploitation.

Toutes les valeurs décrites dans cette section sont fixes. En tant qu'appareil, le système de stockage Oracle ZFS Storage Appliance ne permet pas (ni ne requiert) de régler ces paramètres. Elles sont considérées comme des détails d'implémentation et sont fournies à titre informatif uniquement. Elles peuvent être changées à tout moment et sans préavis.


Remarque -  Pour éviter l'altération des données après le déplacement physique d'un cluster, vérifiez que tout le câblage du cluster est correctement installé dans le nouvel emplacement. Pour plus d'informations, reportez-vous à la section Prévention des états split-brain.

Rubriques connexes