Dell Unity : Comment le transfert forcé de LUN a lieu dans la baie Unity.

L’opération de transfert forcé de LUN se produit pour plusieurs raisons. Du côté de Unity, un transfert forcé de LUN se produit lors d’un événement de défaillance du processeur de service (SP) pour l’un des SP ou un hôte utilisant son chemin conçu non optimisé. Lorsque cela se produit, les LUN détenues sont transférées de manière forcée à l’autre SP.

Unity tire parti de l’ALUA (Asymmetric Logic Unit Access) pour l’accès hôte. Cela permet à plusieurs chemins d’être actifs pour les E/S, mais certains chemins sont optimisés tandis que d’autres ne le sont pas. Les chemins désignés comme optimisés sont connectés au SP propriétaire de cette ressource particulière. Si les E/S sont envoyées sur le chemin non optimisé, le processeur de stockage homologue tire parti du bus CMI (Common Messaging Interface) interne pour rediriger les E/S vers le processeur de stockage propriétaire de la ressource. Cette opération est transparente pour l’hôte et élimine la nécessité de transférer la ressource pour terminer les E/S. Cela suppose que les pratiques d’excellence pour la connexion d’un hôte ont été suivies : deux HBA par hôte, deux commutateurs et deux ports SP par SP. Ceci est configuré pour quatre chemins - voir la deuxième image ci-dessous.
 
Exemple : Voici différents scénarios dans lesquels des LUN sont transférées de manière forcée à l’autre SP « initialement sans propriétaire »
 
Scénario 1 :
dans l’image ci-dessous, si le SPA tombe en panne, les LUN qui lui appartiennent sont transférées du SPA vers le SPB. Une fois que le SPA revient en service, la propriété des LUN est redirigée vers le propriétaire initial : le transfert forcé vers le SPA. 

  

Scénario 2 :
si un grand nombre d’E/S sont reçues sur le chemin non optimisé, Unity transmet la LUN au processeur de stockage homologue afin d’optimiser le chemin d’accès des données.
Ce dernier scénario se produit lorsque, par erreur, l’hôte envoie ses données sur un chemin incorrect. Par conséquent, Unity transfère automatiquement les LUN pour optimiser le chemin d’accès des données. 
 
Unity évite ainsi l’utilisation intensive d’un SP qui ne possède pas une certaine LUN.

Scénario 3 :
dans l’image ci-dessous, en cas de défaillance d’un SP, la LUN bascule sur le SP restant et continue à traiter les E/S puisqu’elle est connectée aux mêmes commutateurs. En cas de défaillance du commutateur, le commutateur restant fournit un accès aux deux SP, éliminant ainsi le besoin d’utiliser le chemin non optimisé. En cas de défaillance de l’hôte, le cluster lance un basculement sur incident vers l’autre hôte et met l’application en ligne. Toute défaillance du chemin en raison d’un câble ou d’un port défectueux n’entraîne aucun problème, car le second chemin optimisé peut être utilisé.
 
Cette configuration peut également résister à plusieurs défaillances, tant qu’elles ne se trouvent pas dans le même composant. Par exemple, une défaillance de l’hôte B, du commutateur A et du SPA peut être tolérée, car les composants restants peuvent être utilisés pour accéder à la LUN. Dans ce cas, l’hôte A peut se connecter via le commutateur B et accéder à la LUN qui a été transférée au SPB.