Blog du DS45: NetAPP Metro Cluster vs Pillar Data w/IpStor

mercredi 14 juillet 2010

NetAPP Metro Cluster vs Pillar Data w/IpStor

Un petit point sur deux technos de continuté de service pour le SAN d'entreprise que j'ai eu la chance de mettre en oeuvre ces dernières semaines dans le cadre de mon auto-entreprise. Si elles répondent toutes deux à la même problématique, elles ne s'architecturent pas du tout de la même manière de part leur fonctionnement interne respectif.

Pour rappel, les produits NetAPP sont des produits appartenant à la catégorie des stockages monolithiques tandis que Pillar appartient à celle des modulaires.

Dans un NetAPP, toutes les fonctionnalités sont intégrées dans la tête NAS ici en rouge. Si un manque de puissance se fait ressentir durant la vie de la machine, il faudra changer la tête et son logiciel pour passer à la version supérieure plus puissante. On appelle celà l'effet de gamme.

Chez Pillar, c'est strictement l'inverse, toutes les fonctionnalités sont réparties dans des éléments physiques et l'on complète la machine en fonction de ses besoins comme avec un jeu de LEGO. Par exemple si l'on manque de puissance, on ajoutera un nouveau slammer pour augmenter la capacité de traitement. A l'inverse, il ne sera jamais demandé d'upgrade logiciel pour offirir plus de capacité disque, de possibilité de connexion ou de puissance.

NetAPP ne supporte la redondance Métro qu'à partir de la série FAS 3XXX (oubliez les 2XXX) et elle peut-être de deux types :

- 'Split-Brain' ou 'Stretch' pour une distance inter-site faible (270m à 4Gb/s, 500m à 2Gb/s)

- ou Fabric Cluster autorisant de longues distances pouvant atteindre les 100Km mais n'acceptant pas de shelves de type ATA :

Le Fabric Metro-cluster nécessite l'intégration de 4 switchs FC Brocade strictement dédiés et avec un code supporté par Netapp. Les têtes deviennent propriétaires de la moitié des shelves locaux et distants. Ca revient à faire du RAID 1 entre baies, chacune pouvant comporter au maximum 670 disques. L'utilisation des ports est très stricte et impose d'en définir certains en mode traffic isolation exclusivement dédiés au fonctionnement propre du cluster - ce dernier étant constitué par le couple des deux têtes - les autres ne se chargeant que du flux des données à traiter sur disque.

Si pour la bascule en cas de problème tout se passe facilement, le retour arrière après déclenchement du PRA obligera à manipuler le CLI et à rebooter l'ensemble lorsque tout le monde se verra de nouveau.

aggr status -r (quel est l'état des aggérgats locaux)
partner (on va sur le survivant)
aggr status –r (on lit les aggrégats survivants)
aggr offline disaster_aggr (on les mets offline)
aggr mirror aggr_name -v disaster_aggr (on recrée les aggrégats mirrorés à la mano)
partner (on revient )
cf giveback (le noeud du site de PRA reboot)
reboot (local pour resynchro des IDs des volumes)

Ceci peut se faire de manière automatique mais impose de créer un script sur mesure qui devra (heureusement) être validé par le support NetAPP.

Chez Pillar, courte ou longue distance, le fonctionnement reste le même et n'impose pas de limitation particulière pour le stockage (de 4,5To à 1,6 Po, disques SATA ...) par machine puisque l'outil de mise en mirroir est une brique dédiée supplémentaire qui ne vient pas en rupture entre les contrôleurs disques et le(s) contrôleurs d'entrée/sortie. Cette brique se nomme IPSTOR.

- Courte distance en FC 4 Gb/s :

- Longue distance FC 2Gb/s ou FC 4 Gb/s :

Ici, les switchs Brocade ou Cisco ne font office que d'extender (extension des liens) et n'interviennent pas dans le back-end de la baie. Il faudra toutefois prévoir la license buffer credits ad-hoc pour compenser la latence au-delà de plusieurs kilomètres et la license ISL pour trunker les liens.

Les IPSTOR fonctionnent par couple et sont propriétaires tous les deux des deux baies. Les WWN ou les IQN des LUNs présentés aux serveurs sont spoofés, la resynchronisation des volumes est automatique et n'impose pas de manoeuvre complexe en CLI ou dans le GUI. . Au passage, on abuse de cette fonctionnalité lors des upgrades en pleine journée sans se poser plus de question La remise en état du mirroir se fait très rapidement. Bref c'est de l'écriture synchrone en 'Y' tout ce qu'il y a de plus bête

En résumé, si ces deux solutions ont largement fait leurs preuves, celle de NetAPP nécessitera d'être plus vigilant pour son implémentation de part ses contraintes intrinsèques qui induiront quelques manipulations lors de la procédure de failback (retour à l'état nominal après bascule). Toujours chez NetAPP, concernant la volumétrie utilisable, si vous souhaitez disposer de 20To utile de chaque côté il vous faudra acquérir 70To (RAID DP + RAID1).

Quelques liens concernant Pillar :

10 commentaires:

Unknown a dit…: Bonjour,

Dans la solution NetApp MetroCluster, je ne pense pas qu'il soit nécessaire de rebooter les contrôleurs à l'issue d'un retour en mode de fonctionnement normal, contrairement à ce que vous évoquez ?
Il me semble que les seules commandes à saisir soient les suivantes, une fois que le contrôleur défaillant affiche "waiting for giveback" :
- cf giveback, pour forcer le contrôleur défaillant à un retour en mode de fonctionnement normal
- cf status, sur chaque contrôleur pour vérifier que le cluster est à nouveau opérationnel sur chaque contrôleur (=> "cluster enabled"); 9 septembre 2010 à 17:46
dunestudio45 - DS45 a dit…: Extrait de Data ONTAP Active/Active COnfigration : Disaster recovery using MetroCluster p179/180

Rejoining the mirrored aggregates to reestablish a MetroCluster
Describes how to rejoin the mirrored aggregates if the mirrored aggregate was in a normal state before
the forced takeover.
Attention: If you attempt a giveback operation prior to rejoining the aggregates, you might cause
the node to boot with a previously failed plex, resulting in a data service outage.
Steps
1. Validate that you can access the remote storage by entering the following command:
aggr status -r
2. Turn on power to the node at the disaster site.
After the node at the disaster site boots, it displays the following message:
Waiting for Giveback...
3. Determine which aggregates are at the surviving site and which aggregates are at the disaster site
by entering the following command:
Disaster recovery using MetroCluster | 179aggr status
Aggregates at the disaster site show plexes that are in a failed state with an out-of-date status.
Aggregates at the surviving site show plexes as online.
4. If aggregates at the disaster site are online, take them offine by entering the following command
for each online aggregate:
aggr offline disaster_aggr
disaster_aggr is the name of the aggregate at the disaster site.
Note: An error message appears if the aggregate is already offine.
5. Re-create the mirrored aggregates by entering the following command for each aggregate that was
split:
aggr mirror aggr_name -v disaster_aggr
aggr_name is the aggregate on the surviving site’s node.
disaster_aggr is the aggregate on the disaster site’s node.
The aggr_name aggregate rejoins the disaster_aggr aggregate to reestablish the MetroCluster
confguration.
6. Verify that the mirrored aggregates have been re-created by entering the following command:
aggr status -r mir
The giveback operation only succeeds if the aggregates have been rejoined.
7. Enter the following command at the partner node:

cf giveback

The node at the disaster site reboots.; 9 septembre 2010 à 18:12
Unknown a dit…: Les éléments physiques qui se rajoutent chez Pillar peuvent-ils tomber en panne ? Que se passe-t'il en cas de panne ? Perte de puissance et/ou de fonctionnalités ?
Les modules "slammer" se rajoutent à chaud ? Combien de modules peut-on rajouter ? L'augmentation de puissance est-elle immédiate ?; 9 septembre 2010 à 19:23
dunestudio45 - DS45 a dit…: Les éléments physiques qui se rajoutent chez Pillar peuvent-ils tomber en panne ? Que se passe-t'il en cas de panne ? Perte de puissance et/ou de fonctionnalités ?

-> tout élément physique peut tomber en panne ... Pas de perte de puissance puisque l'on est pas sous la seule responsabilité d'un contrôleur en charge de tout.

Les modules "slammer" se rajoutent à chaud ? Combien de modules peut-on rajouter ? L'augmentation de puissance est-elle immédiate ?

-> oui l'upgrade est est non disruptif (sans arrêt de prod), pour le nombre c'est actuellement 8 (ça pourrait bien augmenter de beaucoup plus dans pas longtemps...).

Bien sûr que l'augmentation est immédiate. Mieux, dans une config NetApp, essayez donc de mélanger une tête FAS 3020 et une tête 3140 : pas possible.

... et bien chez Pillar on peut mixer un slammer Axiom 500 d'il y a 4 ans et ses tiroirs de disques (largement d'actualité) à un slammer 600 v3 (8 Giga FC, 10 Giga). C'est une vraie capitalisation, on ne se fait pas facturer la puissance en sus contrairement à NetAPP, quand il ne faut pas aussi changer les Disk Shelf pour cause d'incompatibilité.

A oui, on peut aussi désallouer on-line ...; 9 septembre 2010 à 19:41
Unknown a dit…: Je vous remercie pour ces infos.
Connaissez-vous des liens web où je peux trouver des comparatifs NetApp / Pillar, ou même avec d'autres systèmes de stockage (IBM, HP, EMC, 3PAR, HDS, ...) ?; 9 septembre 2010 à 19:48
dunestudio45 - DS45 a dit…: Etant un des rares utilisateurs finaux à écrire sur ces sujets passionnants, je vous renvoie aux liens suivants :

http://ds45.blogspot.com/2010/01/3par-un-stockage-fait-par-des.html

http://ds45.blogspot.com/2010/04/architecture-ibm-xiv-petite-mise-au.html

Concernant HP, j'ai peut que l'EVA ne survive pas à l'intégration chez HP des 3Par série F ...; 9 septembre 2010 à 19:54
Unknown a dit…: Si j'ai bien compris pour la gestion de la haute-dispo entre 2 sites (ou 2 salles)

--> chez NetApp : se gère via le mode appelé MetroCluster pour lequel il n'est pas nécessaire d'ajouter d'équipements matériels : cette gestion est totalement intégrée au système de stockage.

--> chez Pillar, il est nécessaire d'intégrer des boîtiers FlaconStor (2 boîtiers par site). Le fait d'avoir des équipements supplémentaires n'ajoute-t'il pas une complexitité supplémentaire (administration d'équipements supplémentaires) et des risques de pannes ? Par ailleurs, comment se passe la maintenance entre Pillar et FlaconStor : l'un ne risque-t'il pas de renvoyer la balle vers l'autre ?
Par ailleurs, ce mode de gestion avec des boîtiers est-il "comparable" à ce que fait IBM (solution SVC) ou HP (SVSP) ?; 9 septembre 2010 à 20:02
dunestudio45 - DS45 a dit…: Chez Netapp tout est intégré tant que l'on est sur une distance de quelques centaines de mètres, au-delà des brocades au firmware bien spécifique intègre la baie elle même.

Concernant Pillar, c'est 1 boitier par site (et pas 2) qu'il faut intégrer, boitier vendu et supporté directement par pillar : 1 seul interlocuteur et pas de ping pong pour le support.

Oui ça s'apparente à du SVC, mais avec bien plus de fonctionnalités : Virtualisation stockage, Dedup, VTL, Migration de Lun ...; 9 septembre 2010 à 20:10
Unknown a dit…: Les schémas présentés dans l'article le montre bien : tant pour la solution NetApp que pour la solution Pillar, dès lors que la distance dépasse qq centaines de mètres, il est nécessaire de disposer des switches FC pour "s'affranchir" de la problématique de distance. Donc, sauf erreur de ma part, il n'y a pas de différence à ce niveau.

Par contre, pour la solution Pillar, je pense que le fait d'avoir 1 boîtier FalconStor par site (ou salle) ajoute les problématiques suivantes :
- en cas de panne ou de maintenance (mise à jour firmware, ...), il est nécessaire de prévoir la bascule de l'ensemble du système de stockage sur le 2nd site, puisqu'il n'y a apparemment qu'un boîtier par site.
- il est nécessaire d'administrer et exploiter 2 équipements matériels supplémentaires
- les boîtiers n'étant pas directement fabriqués par Pillar, il n'y a a priori pas d'assurance de la compatibilité dans l'ensemble de la solution de stockage

Par ailleurs, je ne comprends pas très bien l'intérêt qu'il y aurait à mixer des contrôleurs de puissance différentes (pour reprendre votre exemple avec un FAS3020 et un FAS3140), dans la mesure où les 2 contrôleurs fonctionnent en mode "cluster", et où chaque contrôleur doit, potentiellement, pouvoir assurer l'activité de toute la baie. Dans ce cas, il paraît tout de même plus logique et pertinent de disposer de 2 contrôleurs de même gamme.; 9 septembre 2010 à 20:51
dunestudio45 - DS45 a dit…: 1. Dans le cas de NetAPP, les brocades viennent en rupture entre les têtes et les DS.
Chez Pillar, il n'interviennent pas entre les slammers et les tiroirs de disques.

2. Le boitiers Falcon fonctiuonnant en cluster, isl sont vus comme une seulle et même machine propriétaire des deux baies. Si l'on reboot l'un des deux neouds, le trafic est géré par le second. Il n'y a précisément rien à prévoir. Il est même plus éfacile pour moi de faire les upgrades en journée et en production ... Concernant la compatibilité, c'est le couple Falcon et Pillar qui l'assure.

3. C'est la bande passante en entrée de la baie (vers les serveurs) que l'on augmente, pas la puissance du backend de la baie. La redondance s'appuie dans ce cas sur dynapath, ou AXIOM Path Manager (ALUA VMware, MPIO Windows ...); 9 septembre 2010 à 21:03

Enregistrer un commentaire