samedi 3 avril 2010

Architecture IBM XIV : petite mise au point ..

En ces jours printaniers, le coup de téléphone de prospection recommence à pleuvoir, notamment celui d'IBM pour me présenter les offres de stockages. J'explique que tout va bien et que nous sommes à jour avec des produits qui marchent plutôt pas mal. Point de N series ou de DS quelque chose en vue, non, là on me parle de XIV qui serait la même chose d'un point de vue architecture que du Pillar ....

J'avoue que ce n'est pas la première fois que j'entends cet argument un tantinet fallacieux : un stockage sous forme de noeuds de jbods en cluster (XIV) serait donc la même chose qu'un stockage modulaire (Pillar) ???? Voyons ensemble.


L'orgnisation du back-end de la XIV

Le back-end : du giga Ethernet commuté redondant, donc à tout casser 2 x 100 Mo de débit Sur ces bus transitent le trafic des blocs de données de 1Mo (stripping utilisé dans la machine), le heartbeat des noeuds, et les messages de synchro de l'ensemble.

Sur un Pillar AXIOM 600 actuel, le back-end est de 8 x 400 Mo en FC qui comme vous l'imaginez est un chouilla plus performant.


Les éléments d'un tiroirs disques de la XIV

La baie XIV intègre deux types de tiroirs de disques : Le Data Module et l'Interface Module. Ce sont en fait des serveurs LSI bi-XEON sans contrôleur RAID matériel avec 8 Go de ram dont un tiers est réservé à l'OS, ce dernier étant contenu dans une compact flash de 1Go. Le pilotage se fait au travers du port série RS-232.

L'intelligence d'un Pillar repose au sein du Pilot, un cluster linux actif/standby dédié et hors des bricks de disques. Si il s'arrête, la baie continue de vivre sa vie.


La XIV contient 9 Data Modules et 6 Interfaces Modules

Les 9 Data Modules n'ont pas vocation à dialoguer avec l'extérieur mais uniquement à stocker des données, ils n'intègrent donc qu'une carte PCI-Express dual port Ethernet non interchangeable à chaud et qui consitue un SPOF si elle lâche puisqu'elle n'est pas redondée ... Au passage, vous envisageriez-vous d'arrêter un partie de votre baie pour changer une simple carte Ethernet HS ??

Les 6 Interface Modules sont reliés au monde extérieur, intègrent 2 x 4 ports FC et 2 ports ISCSI, soit 24 ports FC et 6 ports ISCSI (3 modules maxi avec ISCSI).

La machine peut embarquer un total de 180 disques de 1To brut dont on ne peut utiliser que 50% soit 79 Go. A noter que l'aggrégation de liens Ethernet n'est possible qu'avec des ports provenant du même Interface Module .... L'administration s'opère au travers des mêmes interfaces qui véhiculent le ISCSI.

Les fonctions étant différentes entre les deux types de modules, les Interfaces Modules supporteront plus de charge que les Data Modules.

La XIV intègre 3 onduleurs 6Kva APC donnant les 12 minutes d'autonomie nécessaires à son extinction. Il faudra donc prévoir un remplacement préventif fréquent des batteries puisqu'en vieillissant elle tiennent la charge moins longtemps. Bien sûr, il faudra veiller à ce que votre faux plancher supporte le poids.

Chez Pillar, chaque brique de disques intègre deux contrôleurs RAID matériels. Elles sont reliées en FC au slammer dédié lui à l'interconnection vers le monde extérieur. Chaque slammer SAN intègre 48 Go de cache, 4 ports FC et 4 ports ISCSI. Une baie Pillar peut jusqu'à contenir 64 briques de disques soit 832 disques - 1,6 Po-, 4 slammers San et 4 slammers NAS intégrant 16 ports FC, 16 ports ISCSI et 16 ports NAS. On peut agréger l'ensemble de ces derniers pour accéder à un LUN (Multipathing). 92% de la volumétrie totale des disques est utilisable. Chaque slammer intègre deux batteries permettant de maintenir l'état du cache pendant 30 jours en cas de coupure électrique.

Les interfaces de management redondantes sont out-of-band sur des interfaces dédiées du Pilot.


Face avant et face arrière de la XIV

Concernant l'interface d'administration (GUI ou IHM en français), le XIV Storage Manager se présente sous la forme d'un outil à installer sur un PC déporté. Chez Pillar, Axiom One est intégré au sein du Pilot et ne nécessite qu'un browser Web.

Pour la gestion interne, la XIV impose de définir des storage pool d'au moins 17 Go contenant à la fois les LUNs et les snapshots. Il vaut mieux que vos LUNs notamment Thin Provisionnés soient multiples de 17, sinon bonjour la perte en ligne ....

Sur Pillar, la granularité descend au Mo. On alloue l'espace désiré pour son Lun, c'est tout. Il n'y a pas de considération à avoir concernant les snapshots, leur espace est affecté automatiquement par la baie. Le management est du simplicité biblique.


Le process d'écriture sur la XIV ... pas si redondé que celà

Concernant le mode d'écriture, là aussi il existe une différence notable en ce sens que dans la XIV un Interface Module va envoyer la donnée à écrire sur un Data Module; ce dernier la répliquant sur un autre Data Module. Donc, point d'écriture répartie sur l'ensemble des axes gage de très hautes performances.

Chez Pillar, votre donnée va être automatiquement ventilée par le ou les slammers en fonction de la redondance et du SLA demandé sur au moins 8 briques de disques (si vous les avez), le tout simultanément par les 16 contrôleurs disques RAID matériel mis à contribution.

Bref, vous l'aurez compris, si la XIV reste un très beau cluster de stockage, on ne peut pas dire qu'il fonctionne comme un AXIOM Pillar Data et qu'il soit aussi simple en terme de gestion.

10 commentaires:

Cyril a dit…

Bonsoir,

je viens de lire votre article et je suis assez surpris par la grande qualité de vos articles en général cependant je vous donne mon avis concernant la XIV.
Concernant les infos sur Pillar, je ne connais malheureusement pas leurs produits pour les juger.

Le back-end : du giga Ethernet commuté redondant, donc à tout casser 2 x 100 Mo de débit

Il faut relativiser au prix, je ne connais pas le prix d'une baie Pillar mais une baie XIV est l'entrée de gamme du haut de gamme IBM soit beaucoup moins cher qu'une DS8700 par exemple.

ils n'intègrent donc qu'une carte PCI-Express dual port Ethernet non interchangeable à chaud et qui consitue un SPOF

Je ne vois pas ou est le souci, une baie XIV tournera toujours même si un module complet + 3 disques sont HS. L'algorithme de répartition des taches de travail continuera à répartir équitablement les taches. La seule chose qui importe c'est de ne pas avoir d'interruption de service et il n'y en a pas avec la XIV, il faudrait que deux modules lâchent pour faire tomber la baie, chose plus qu'improbable.

les Interfaces Modules supporteront plus de charge que les Data Modules.

C'est exact sauf que la charge de la RAM et du CPU n'est pas la principale préoccupation de la XIV puisque le but est de répartir équitablement l'utilisation des disques et la performance des disques. Vous comparez des produits qui ne contiennent pas les mêmes éléments et n'ont certainement pas le même tarif.
En terme de performances, il faudrait donc comparer des produits comparables.

La machine peut embarquer un total de 180 disques de 1To brut dont on ne peut utiliser que 50% soit 79 Go.

C'est un choix de l'architecture, les données sont écrites en double. Concernant vos 92% utilisables sur une baie Pillar, je serai grandement étonné que la redondance des données soit de la même efficacité. Une baie XIV est faite plus dans une optique de sécurisation des données que de performances des transactions.

Le management est du simplicité biblique.

L'administration d'une XIV est d'une facilité déconcertante. Vous parlez de snapshots mais rien ne vous oblige à les utiliser. Il est cependant dommage qu'il ne soit pas possible de créer des LUNS de moins de 17Go du à l'algorithme. Cependant, le Thin Provisioning résout en parti ce souci.

un Interface Module va envoyer la donnée à écrire sur un Data Module; ce dernier la répliquant sur un autre Data Module

C'est faux, un interface module est un data module avec des interfaces externes supplémentaires ce qui est loin d'être la même chose que ce que vous dites. La donnée sera donc écrite de façon équitable sur tous les modules et donc tous les disques. Voila ce que veut dire le schéma...

on ne peut pas dire qu'il fonctionne comme un AXIOM Pillar Data et qu'il soit aussi simple en terme de gestion.

Je ne connais pas Pillar mais dire que la XIV n'est pas un produit simple à administrer est une hérésie. Jamais je n'ai touché un produit si simple d'accès. Quand à l'algorithme de répartition de charge et de données, c'est simple il répartit équitablement la charge sur tous les élements composants la baie (cpu, ram, cache, disques).

Je n'ai pas votre expérience mais je travaille sur des baies XIV, DS4k, DS6K, DS8K, NetApp Filer; je peux donc vous donner mon expérience sur ces produits.

dunestudio45 - DS45 a dit…

Bonsoir, je viens de lire votre article et je suis assez surpris par la grande qualité de vos articles en général cependant je vous donne mon avis concernant la XIV. Concernant les infos sur Pillar, je ne connais malheureusement pas leurs produits pour les juger.
-> Ca tombe bien, j'ai joué avec les deux.
Le back-end : du giga Ethernet commuté redondant, donc à tout casser 2 x 100 Mo de débit Il faut relativiser au prix, je ne connais pas le prix d'une baie Pillar mais une baie XIV est l'entrée de gamme du haut de gamme IBM soit beaucoup moins cher qu'une DS8700 par exemple.
-> Pillar est moins cher que XIV lorsque cette dernière n'est pas bradée pour acheter une référence : de 4,5To à 1,6Po, c'est la même machine .... Un AXIOM 600e avec contrat de maintenance et out le toutime est à peine plus cher qu'un FAS 2040.
ils n'intègrent donc qu'une carte PCI-Express dual port Ethernet non interchangeable à chaud et qui consitue un SPOF Je ne vois pas ou est le souci, une baie XIV tournera toujours même si un module complet + 3 disques sont HS. L'algorithme de répartition des taches de travail continuera à répartir équitablement les taches.
-> Outre l'impact de performance que celà génère, c'est vraiment dommange que la baie soit partie en vrille lorsque l'on a ejecté un disque lors du dernier POC auquel j'ai participé .... Pourquoi donc impacter toute la baie en déconnectant un module complet ???? Même sur un Clariion, pour changer un module Ethernet ou FC, on arrête pas la machine
La seule chose qui importe c'est de ne pas avoir d'interruption de service et il n'y en a pas avec la XIV, il faudrait que deux modules lâchent pour faire tomber la baie, chose plus qu'improbable. les Interfaces Modules supporteront plus de charge que les Data Modules.
-> "Note that the XIV Storage System does not load balance the requests itself. Load balancing must be implemented by storage administrators to equally distribute the host requests among all Interface Modules".
C'est exact sauf que la charge de la RAM et du CPU n'est pas la principale préoccupation de la XIV puisque le but est de répartir équitablement l'utilisation des disques et la performance des disques. Vous comparez des produits qui ne contiennent pas les mêmes éléments et n'ont certainement pas le même tarif. En terme de performances, il faudrait donc comparer des produits comparables.
-> Ce sont les revendeurs IBM qui passent leur temps à comparer XIV à Pillar .... J'ai eu le droit au couplet lorsque j'ai été démarché.
La machine peut embarquer un total de 180 disques de 1To brut dont on ne peut utiliser que 50% soit 79 Go. C'est un choix de l'architecture, les données sont écrites en double. Concernant vos 92% utilisables sur une baie Pillar, je serai grandement étonné que la redondance des données soit de la même efficacité. Une baie XIV est faite plus dans une optique de sécurisation des données que de performances des transactions.
-> Non, RAID logiciel sur XIV, répartition sur des RAID Groups matériel sur Pillar : donc sécurisation et très hautes performances en sus même quand on perd des disques ... La reconstruction est imperceptible pour l'utilisateur sur un Axiom

dunestudio45 - DS45 a dit…

Bonsoir, je viens de lire votre article et je suis assez surpris par la grande qualité de vos articles en général cependant je vous donne mon avis concernant la XIV. Concernant les infos sur Pillar, je ne connais malheureusement pas leurs produits pour les juger.
-> Ca tombe bien, j'ai joué avec les deux.
Le back-end : du giga Ethernet commuté redondant, donc à tout casser 2 x 100 Mo de débit Il faut relativiser au prix, je ne connais pas le prix d'une baie Pillar mais une baie XIV est l'entrée de gamme du haut de gamme IBM soit beaucoup moins cher qu'une DS8700 par exemple.
-> Pillar est moins cher que XIV lorsque cette dernière n'est pas bradée pour acheter une référence : de 4,5To à 1,6Po, c'est la même machine .... Un AXIOM 600e avec contrat de maintenance et out le toutime est à peine plus cher qu'un FAS 2040.
ils n'intègrent donc qu'une carte PCI-Express dual port Ethernet non interchangeable à chaud et qui consitue un SPOF Je ne vois pas ou est le souci, une baie XIV tournera toujours même si un module complet + 3 disques sont HS. L'algorithme de répartition des taches de travail continuera à répartir équitablement les taches.
-> Outre l'impact de performance que celà génère, c'est vraiment dommange que la baie soit partie en vrille lorsque l'on a ejecté un disque lors du dernier POC auquel j'ai participé .... Pourquoi donc impacter toute la baie en déconnectant un module complet ???? Même sur un Clariion, pour changer un module Ethernet ou FC, on arrête pas la machine
La seule chose qui importe c'est de ne pas avoir d'interruption de service et il n'y en a pas avec la XIV, il faudrait que deux modules lâchent pour faire tomber la baie, chose plus qu'improbable. les Interfaces Modules supporteront plus de charge que les Data Modules.
-> "Note that the XIV Storage System does not load balance the requests itself. Load balancing must be implemented by storage administrators to equally distribute the host requests among all Interface Modules".
C'est exact sauf que la charge de la RAM et du CPU n'est pas la principale préoccupation de la XIV puisque le but est de répartir équitablement l'utilisation des disques et la performance des disques. Vous comparez des produits qui ne contiennent pas les mêmes éléments et n'ont certainement pas le même tarif. En terme de performances, il faudrait donc comparer des produits comparables.
-> Ce sont les revendeurs IBM qui passent leur temps à comparer XIV à Pillar .... J'ai eu le droit au couplet lorsque j'ai été démarché.
La machine peut embarquer un total de 180 disques de 1To brut dont on ne peut utiliser que 50% soit 79 Go. C'est un choix de l'architecture, les données sont écrites en double. Concernant vos 92% utilisables sur une baie Pillar, je serai grandement étonné que la redondance des données soit de la même efficacité. Une baie XIV est faite plus dans une optique de sécurisation des données que de performances des transactions.
-> Non, RAID logiciel sur XIV, répartition sur des RAID Groups matériel sur Pillar : donc sécurisation et très hautes performances en sus même quand on perd des disques ... La reconstruction est imperceptible pour l'utilisateur sur un Axiom

dunestudio45 - DS45 a dit…

Le management est du simplicité biblique. L'administration d'une XIV est d'une facilité déconcertante. Vous parlez de snapshots mais rien ne vous oblige à les utiliser. Il est cependant dommage qu'il ne soit pas possible de créer des LUNS de moins de 17Go du à l'algorithme. Cependant, le Thin Provisioning résout en parti ce souci.
-> Drôle de contrainte non ? Cette approche purment technique n'est pas de mise chez Pillar du fait que la machine a été conçue par des gens venant du logiciel et ne cherchant pas à rendre visible la complexité d'un stockage quelqu'il soit.
-> En terme de production, je n'aime pas utiliser le thin provisionning sauf à vouloir me prendre un jour ou l'autre les pieds dans le tapis (et je ne pense pas être le seul). Par contre, qu'elle est belle et intuitive l'interface XIV : 110% d'accord.
un Interface Module va envoyer la donnée à écrire sur un Data Module; ce dernier la répliquant sur un autre Data Module C'est faux, un interface module est un data module avec des interfaces externes supplémentaires ce qui est loin d'être la même chose que ce que vous dites.
-> J'avais bien compris la nuance, cependant j'explique le fonctionnement dans le cadre du schema.
La donnée sera donc écrite de façon équitable sur tous les modules et donc tous les disques. Voila ce que veut dire le schéma... on ne peut pas dire qu'il fonctionne comme un AXIOM Pillar Data et qu'il soit aussi simple en terme de gestion.
"Write path redundancy Data arriving from the hosts is temporarily placed in two separate caches before it is permanently written to disk drives located in separate modules. This design guarantees that the data is always protected against possible failure of individual modules, even before the data has been written to the disk drives.."
-> donc avant d'arriver sur disque, la donnée passe par deux caches différents avant d'arriver sur les disques au travers d'un bus Ethernet qui comme chacun sait ne permet pas de l'écriture synchrone. Sur un Axiom, on a pas accès à la répartition des données sur disque, c'est las machine qui gère : on ne fixe que le SLA attendu.
Je ne connais pas Pillar mais dire que la XIV n'est pas un produit simple à administrer est une hérésie. Jamais je n'ai touché un produit si simple d'accès. Quand à l'algorithme de répartition de charge et de données, c'est simple il répartit équitablement la charge sur tous les élements composants la baie (cpu, ram, cache, disques).

Je n'ai pas votre expérience mais je travaille sur des baies XIV, DS4k, DS6K, DS8K, NetApp Filer; je peux donc vous donner mon expérience sur ces produits.
-> ... des architectures toutes créées il y a 15 ouy 20 ans, je pense que le jour ou vous aurez la chance de toucher un AXIOM, vous aller changer d'avis. Tous les clients qui ont eu en POC XIV et Pillar ont retenu Pillar : quelle drôle d'idée non ???

Cyril a dit…

-> "Note that the XIV Storage System does not load balance the requests itself. Load balancing must be implemented by storage administrators to equally distribute the host requests among all Interface Modules".
Ca n'a rien à voir avec la charge interne, c'est l'équilibre des chemins entre les fabrics et la baie. IBM préconise 6 chemins par fabric ce qui équivaut dans une archi basique de type FC avec 2 fabrics à 12 fibres connectées sur la baie ce qui correspond à 2 fibres par interface module soit la moitié de disponible.

-> Ce sont les revendeurs IBM qui passent leur temps à comparer XIV à Pillar .... J'ai eu le droit au couplet lorsque j'ai été démarché.
Je veux bien vous croire car IBM vante tout le temps leurs produits qui sont souvent de bien moins bonne qualité et souvent plus cher.

-> Non, RAID logiciel sur XIV, répartition sur des RAID Groups matériel sur Pillar : donc sécurisation et très hautes performances en sus même quand on perd des disques ... La reconstruction est imperceptible pour l'utilisateur sur un Axiom
Effectivement seulement dire q'un raid logiciel c'est forcément moins bien qu'un raid hardware me parait un peu limite. Il faut comparer le but et ici que ce soit un raid logiciel ou matériel, il s'agit de copier en double les données sur la XIV ce que ne fait pas Pillar. Je ne dis pas que c'est un bon choix mais la conséquence de ces choix utilisent donc 50% de la baie. Il est vrai que le TCO est dans ce cas très haut avec 50% d'utilisation sans compter d'éventuels snapshots.

Si j'ai bien compris, vous etes indépendant dans le stockage ?

dunestudio45 - DS45 a dit…

Merci pour la précision sur les chemins externes. Au demeurant, 4 (2x2)chemins semble plus classique que 6.

Pour le dernier point, non je ne suis pas uniquement consultant indépendant notamment dans le stockage mais directeur de prod dans la vraie vie (avec 22 ans de métier) mais qui en a eu marre de se faire bobardiser, marketiser, bullshitiser et qui comme st Thomas voit pour juger l'apport réel.

Cyril a dit…

En tout cas, continuez à nous donner vos impressions et à nous écrire de bons articles sur le stockage car cela m'intéresse fortement. Je cherche à court terme à basculer 100% dans le stockage et la virtualisation pour mes 30 ans (dsl je n'ai pas vos 22ans d'expérience). Certificatons en vue j'espère aussi.

dunestudio45 - DS45 a dit…

N'hésitez pas à m'envoyer un mail, si vous souhaitez un coup de main pour approfondir vos connaissances.

Cyril a dit…

Bonjour,

je vais rajouter un point à vos propos. Un autre SPOF existe sur la XIV, l'ATS (automatic transfer switch) qui permet, en gros, de gérer la répartition de la charge électrique aux UPS. Malheureusement il n'est pas redondé et cette nuit, nous avons perdu la baie car l'ATS a laché.

dunestudio45 - DS45 a dit…

Pouvez-vous me contacter par mail car j'aurais souhaiter vous entretenir d'un point. Merci