La virtualisation du stockage SAN

En virtualisant, nous nous sommes affranchis de tous les problèmes liés au changement de plateforme matériel et en plus grâce au vMotion, il est possible de procéder à la maintenance d'un host sans arrêter une seule VM. Ô combien avons-nous été heureux de disposer des mêmes fonctionnalités "haute disponibilité" que les châssis de cœurs de backbone réseaux, d'ailleurs rien ne vaut un bon "redundancy force-switchover" ou d'un bon Rapid Spanning Tree pour s'en rendre compte. La mise en place d'un PRAi se concevait dès lors avec moins de difficulté. Mais quid du stockage disque dans tout ça ??? Et bien oui, la première chose dont on doit disposer pour bénéficier de la "hot disponibilité" d'une VM, c'est d'avoir un stockage vu de tous les serveurs et tant qu'à faire sans Single Point Of Failure : baie mono contrôleur, passez votre chemin y'a rien à voir ...

Mais qui dit PRAi dit aussi copie des données essentielles dans un autre lieu. on dispose de plusieurs technologies pour cela :le basket-net en recopiant de manière incrémentale les données sur un média de transfert type bande ou disque dur USB que l'on restaure manuellement à l'arrivée, la réplication intégrée au système de stockage asynchrone sur IP ou FC qui vise à copier à des intervalles de temps ou des seuils de volumétrie atteints les données d'un site à l'autre, la réplication intégrée synchrone FC ou IP qui valide bien que les données sont enregistrées de part et d'autre avant de passer aux suivantes et enfin le miroir synchrone Fiber Channel qui permet l'écriture en ' Y ' de part et d'autre. Cette dernière solution est souvent agnostique car elle ne fonctionne pas au sein de la baie mais se présente sous la forme d'un cluster d'appliances externes :

Exemple de virtualisation de stockage

La distance entre les appliances et donc entre le site primaire et le site de repli peut aller jusqu'à une centaine de kilomètre au prix d'une certaine augmentation de la latence (temps de réponse du disque). Raisonnablement, en -dessous de 30km, cette solution fonctionne de manière nominale. Dans cette configuration, on peut maintenir voir perdre tout ou partie du SAN : contrôleur de virtualisation, Fabric SAN, baie de stockage, sur l'un des deux sites sans même impacter la production. L'accès au LUN se fait travers d'un wwn (world wide name, en gros la mac adresse de la carte FC) spoofé pris conjointement en charge par les contrôleurs de virtualisation. Mieux, la resynchronisation se réalise automatiquement. En termes de conseils d'implémentation, bien veiller à disposer de suffisamment de bande passante sur les liens inter-site (ISL) et de suffisamment de buffers crédits dans les Fabrics FC. En effet, pour diminuer au maximum la latence lors de la double copie, les gros blocs qui rentrent dans les contrôleurs de virtualisation sont découpés en blocs plus petits, ce qui a pour effet d'amplifier le nombre d'IOs : SAN déjà contraints, passez votre chemin ou dédiez-y une infrastructure SAN. Bien entendu, étant donné que l'on travail en mode synchrone, si l'utilisation de baies hétérogènes n'est pas inenvisageable, il faudra cependant bien veiller à ce qu'elles aient des performances relativement proches, à défaut l'ensemble de votre solution de stockage fonctionnera à la vitesse de la baie la moins rapide. Dernier avantage, la virtualisation du stockage constitue un outil qui facilite considérablement la migration des données entre une ancienne et une nouvelle baie : on met en miroir un LUN existant de l'ancienne baie sur un LUN de la nouvelle et on change simplement le wwn d'accès sur les serveurs qui l'utilisent.

Si vous utilisez tout comme moi un environnement Pillar Data, bien entendu vous pouvez vous appuyer sur l'offre IPSTOR mais aussi depuis peu sur la brique maison MAXREP qui offre peu ou prou les même fonctionnalités.