IBM i, Le stockage hébergé en miroir

Dans la configuration que montre la figure 2, une partition IBM i fournit le stockage pour des charges de travail hébergées. Les espaces de stockage du serveur de réseau (c’est-à-dire les disques virtuels) se trouvent dans le pool de stockage auxiliaire indépendant (independent auxiliary storage pool, IASP) dans les deux systèmes. La technologie miroir IBM i, telle que le miroir géographique, est utilisée pour dupliquer en miroir le stockage virtuel entre deux IASP (un sur le système de production et un sur le système de secours.) Donc, à ce stade, les deux systèmes contiennent une copie du disque virtuel.

De plus, le second système (ou système de secours) nécessitera aussi que l’on ait défini la partition logique pour la (les) charge(s) de travail ainsi que la description du serveur de réseau. Si cette solution est appliquée pour les solutions intégrées x86, les objets de configuration supplémentaires requis pour ces solutions devront aussi être définis sur les deux systèmes. Quand un arrêt de la charge de travail se produit sur le système de production, cette même charge de travail peut être transférée sur le système de secours. En fait, l’opération « vary » du serveur de réseau comporte des points de sortie qui peuvent être utilisés pour automatiser le portage de la charge de travail sur le système de secours. Vous pouvez mettre en place une configuration similaire en utilisant deux unités SAN (une connectée à chaque système), puis en utilisant les mécanismes de réplication SAN, comme remote mirror et copy, pour tenir les disques virtuels synchronisés sur les deux unités.

Sachez que la solution que je viens de décrire tiendra le ou les objets qui représentent le disque virtuel, synchronisés entre les unités de stockage connectées à deux systèmes disparates. Vous vous assurerez que les deux systèmes ont les LPAR définis pour que les charges de travail deviennent rendues hautement disponibles et qu’il y ait suffisamment de ressources processeur et mémoire pour prendre en charge la (les) charge(s) de travail en cas de basculement sur le système de secours.
Il existe une solution similaire mais moins élégante : copier manuellement l’objet de stockage virtuel entre les systèmes de production et de secours. En utilisant l’IBM i comme exemple de partition hébergeante, vous pourriez utiliser la commande SAV pour sauvegarder l’espace de stockage du serveur de réseau (NWSSTG), puis utiliser la commande RST pour le restaurer sur le système de secours.

Avant la version i6.1, cette solution demande l’arrêt de la charge de travail hébergée car l’espace de stockage ne peut pas être copié pendant l’activité. Avec la version i6.1, vous pouvez bénéficier du save-while-active pour sauvegarder l’espace de stockage même quand la charge de travail hébergée est active : la solution est alors plus gérable. Rappelons que l’espace de stockage sur le système de secours sera au même niveau d’actualisation que la dernière fois qu’il a été sauvegardé à partir du système de production. Par conséquent, c’est une bonne solution pour des charges de travail de type infrastructure dont les données changent peu, mais ce n’est peut-être pas la meilleure solution pour les charges de travail dont les données changent fréquemment.

Stockage hébergé réparti entre des partitions hébergeantes

Il existe une autre méthode fournissant la haute disponibilité du stockage virtualisé : fournir ce dernier à partir de plus d’une source, puis permettre à la charge de travail de dupliquer en miroir le stockage. Dans la configuration qu’illustre la figure 3, la partition guest (celle qui bénéficie du stockage virtualisé) reçoit le stockage de deux partitions hébergeantes (ces dernières peuvent être des partitions IBM i, des partitions VIOS, ou un mélange des deux). Cette configuration demande une relation d’adaptateur SCSI virtuel entre la partition guest et chacune des partitions hébergeantes.

Désormais, comme la charge de travail guest a de multiples disques, elle peut appliquer son propre mécanisme de protection de disques logiciels sur ces disques. Par exemple, si la charge de travail guest est une partition Linux, le support RAID logiciel dans Linux pourrait être utilisé pour dupliquer en miroir le stockage sur les multiples disques que Linux voit. Quand l’une des partitions hébergeantes sera mise à l’arrêt, l’OS hébergé verra cela comme un disque « défaillant » et continuera à tourner sur le disque miroir. Ensuite, quand la partition hébergeante sera remise en service, le « disque » sera à nouveau à la disposition de l’OS hébergé, et il pourra redupliquer en miroir ou resynchroniser le stockage. À noter qu’une partition IBM i hébergée peut supporter ce genre de configuration à la condition que le matériel Power 6 et les partitions IBM i guest et host soient tous au niveau i6.1