Bruno Picard, NetApp : « il n'y a pas de limites à notre archi pour datacenters virtuels »

NetApp a récemment annoncé une alliance avec VMware et Cisco pour proposer à ses clients une architecture clés en main pour les environnements virtualisés, une architecture qui fait écho à celle annoncé par EMC avec les mêmes VMware et Cisco dans le cadre de la co-entreprise Acadia. Afin d'en savoir plus sur cette architecture, LeMagIT a rencontré Bruno Picard le directeur technique de NetApp en France. L'occasion de discuter de l'alliance avec Cisco et VMware, mais aussi de revenir sur les annonces récentes autour d'Ontap 8. L'occasion enfin de discuter de l'avenir des baies de stockage à l'ère de la mémoire Flash.

LeMagIT : Lorsque l'on parle de blueprint (ou architecture de référence) pour le cloud comme vous le faites dans le cadre de votre alliance avec Cisco et VMware, on évoque en général des configurations relativement musclées, dimensionnées pour des datacenters ou les grands hébergeurs. Y-a-t-il des limites à ce que vous avez défini ?

Bruno Picard : La configuration n'est en aucun cas limitée ni vers le haut, ni vers le bas. On propose une architecture de référence qui fonctionne avec l'ensemble de nos baies, d'entrée de milieu ou de haut de gamme puisque ces dernières partagent toutes le même microcode. Cela nous différencie d'un concurrent comme EMC dont chaque gamme Clariion, Symetrix ou Celerra, nécessite un blueprint différent. NetApp a l'avantage d'avoir une architecture uniforme, ce qui fait que le blueprint n'est pas limité. En revanche, on a des guides de dimensionnement qui permettent à nos partenaires, en fonction des besoins des clients, de dimensionner le nombre de serveurs Cisco UCS et de baies NetApp selon le nombre et la typologie des VM déployées.

LeMagIT : Acadia, la co-entreprise entre Cisco, VMware et EMC veut livrer à ses clients et partenaires des solutions préconfigurées. Est-il question dans le cadre de votre alliance avec VMware et Cisco d'avoir le même type d'approche ?

B.P. : C'est le rôle des partenaires et des intégrateurs. Notre architecture a pour but de fournir aux partenaires de nos trois sociétés le moyen de délivrer le plus vite possible une infrastructure aux clients. Le partenaire s'approvisionnera chez ses différents fournisseurs et c'est lui qui délivrera la solution finale.

LeMagIT : L'architecture de référence conçue par VMware, Cisco et EMC spécifie soit l'usage de FC soit celui de FCoE jusqu'au commutateur Nexus situé en sommet de rack. En est-il de même pour NetApp ou avez-vous mis en avant d'autre protocoles comme NFS ou iSCSI ?

B.P. : En fait, dans la première version, on supporte NFS et iSCSI. La prochaine mouture supportera les protocoles FC ou FC sur Ethernet. La raison principale de ce choix est que la majorité des clients qui déploient du vSphere sur NetApp le font sur iSCSI ou NFS. Et même une majorité sur NFS. De nombreux benchmarks ont en effet montré que c'est tout aussi performant et surtout beaucoup, beaucoup plus simple. Les technologies de déduplication qui sont embarquées dans nos baies ont aussi plus d'intéret sur NFS, car on voit immédiatement les gains. En terme d'administration et d'exploitation, cela reste aussi beaucoup plus flexible.

LeMagIT : Je soupçonne que FCoE reste pour l'instant marginal en l'état de la normalisation ?

B.P. : Nous avons un premier client français qui vient de signer avec nous pour du vSphere en FCoE avec des commutateurs Nexus. Mais le projet n'est pas encore finalisé. Il va connecter ses serveurs directement au stockage.

LeMagIT : Pour revenir à l'utilisation de NFS, quelle sont les raisons qui font préférer ce protocole à vos clients ?

B.P. : Lorsque l'on présente les avantages des différentes technologies en terme d'administration, de performances ou de flexibilité, plus de 2 clients sur 3 choisissent NFS. On réalise des benchmarks de façon régulière, soit en prêtant des machines à des clients, soit dans notre propre centre. Dans la plupart des cas, après un benchmark, le choix se porte sur NFS.

LeMagIT : Je suppose que l'on évite ainsi certains des problèmes de contention que rapportent les clients avec VMFS sur du stockage en mode bloc ?

B.P. : Exactement. C'est le problème que rencontrent la plupart des clients. La manière dont est géré le driver FCP dans VMware ESX est la source de ces soucis de contention.

LeMagIT : A propos de NFS, le support actuel dans VMWare est NFS V3. Il est question du développement d'un pilote NFS v4 dans vSphere avec support de pNFS...

B.P. : On n'en voit pas vraiment le besoin. NFS v4 est supporté dans nos baies depuis deux ans et on doit avoir deux clients qui l'utilisent en France. Ce sont avant tout des clients qui ont besoin des ACL (listes de contrôle d'accès) de NFS v4 ou des clients qui ont besoin de faire du NFS dans une DMZ et pour lesquels NFS v4 est plus simple car il utilise un port TCP fixe. Sinon, en termes de performances, les différences ne sont pas flagrantes. En revanche la sécurité est meilleure.

LeMagIT : L'accord avec VMware et Cisco n'étant pas exclusif, NetApp travaille-t-il à une architecture similaire pour d'autres hyperviseurs comme Hyper-V ?

B.P. : Pour l'instant, il n'y a rien d'exclusif et rien n'interdit d'imaginer que Cisco et NetApp produisent une offre équivalente pour Hyper-V dans les mois à venir si tant est qu'Hyper-V puisse garantir le même niveau de sécurié qu'un vShield au niveau de VMware. L'architecture que nous avons imaginé avec Cisco et VMware permet en effet de sécuriser chacun des composants, des VM jusqu'au stockage, en s'appuyant sur les fonctions développées spécifiquement par les trois sociétés.

LeMagIT : De la même façon, avez-vous travaillé avec votre OEM IBM sur une architecture similaire s'appuyant sur des serveurs IBM et des équipements réseaux tiers comme ceux de Juniper et de Blade qui disposent, comme Cisco, de mécanismes de sécurisation du trafic réseau depuis et vers les VM ?

B.P. : Pas à ma connaissance...

LeMagIT : La version 8 d'Ontap est disponible, mais alors qu'elle devait unifier Ontap et OntapGX, on a encore une roadmap de convergence. Pouvez-vous clarifier cet état de fait ?

B.P. : Déjà nous avons déjà des clients en production sur Ontap 8. Pour clarifier, cette version est la première version commune entre GX et Ontap. Il n'y a plus qu'une ligne de développement. Mais, dans la version actuelle, elle fonctionne dans deux modes différents. C'est un OS à deux fonctionnalités. La première est celle de la 7 où l'on retrouve toutes les fonctionnalités ainsi que l'adressage des espaces de stockage en 64 bit, ce qui permet d'avoir des filesystem ou des LUN (Logical Unit Number, équivalent d'une partition dans le monde SAN) pouvant aller jusqu'à 100 To, alors qu'on était limité à 16 To dans la version 7. Sinon d'un point de vue fonctionnalités, on retrouve les fonctions de Ontap 7 avec toutefois un gain de performances non négligeable sur les plates-formes haut de gamme équipées de processeurs multi-coeur (pouvant atteindre 30 à 40 %). La migration se fait sans arrêt planifié, contrôleur par contrôleur. Et elle est non destructive.

L'autre mode de fonctionnement d'Ontap 8 est le mode cluster qui est stricto sensu celui de GX. Il faut en revanche un arrêt de la machine pour mettre à jour un système Ontap GX en Ontap 8. Au redémarrage, des processus en tâche de fond convertissent les systèmes de fichiers en mode 8.

LeMagIT : On a vu des clients multiplier au fil des années le nombre de baies NetApp. Certains d'entre eux envisagent-ils de les clusteriser afin de disposer d'un espace de nommage unique qui pourrait leur simplifier la vie en matière d'administration ? Y-a-t-il une préconisation de NetApp pour lutter contre la prolifération des baies et encourager les clients à clusteriser leurs filers ?

B.P. : En fait, peu de clients le font, sauf s'ils ont des problèmes ou des besoins d'espace de nommage global. Sinon ils s'abstiennent. On pourrait penser que mettre en frontal les filers (serveurs de fichiers, NDLR) par un boitier de virtualisation pourrait aussi régler le problème, mais rares sont ceux qui se livrent à l'exercice. Ce que l'on voit en revanche, c'est une consolidation de filers de plus petite taille sur des modèles plus performants. Il ne faut pas oublier que la version cluster de Ontap ne supporte que CIFS et NFS et ne supporte pas d'autres protocoles.

LeMagIT : Ceci dit, la prolifération des filers se fait en général dans des environnements où l'on stocke de grandes quantités de données non structurées et où les mécanismes d'accès sont des protocoles de fichiers comme CIFS et NFS, voire HTTP ou des mécanismes RESTful ...

B.P. : Je vous l'accorde. Et il est vrai que la croissance des données structurées est planifiable, ce qui est moins le cas des données non structurées. D'un autre côté, nos outils d'administration comme Data Fabric Manager permettent de monitorer un grand nombre de baies de façon centralisée et simple.

LeMagIT : Un des débats du moment porte sur la classification automatique de données et sur le déplacement plus ou moins intelligent de blocs de données au sein des baies pour les positionner sur la bonne classe de stockage. EMC et Hitachi le font au niveau du LUN. Avez-vous des mécanismes similaires sur baies NetApp ?

B.P. : On le fait au niveau du LUN, mais on a aussi un mécanisme supplémentaire qui s'appuie sur des cartes de mémoire cache à base de Flash. La problématique de la classification de données est notamment de gérer intelligemment les points chauds. Nos modules de mémoire Flash peuvent être ajoutés sur les contrôleurs en cache de second niveau derrière la mémoire vive (jusqu'à 4 To). Cela résoud la problématique de classification de données de la façon la plus transparente possible. Lorsque la lecture d'un bloc est requise, on va voir dans la RAM. Si ce bloc n'est pas présent, on va le lire sur disque et on le monte dans la RAM. Là on a un algorithme LRU qui tourne [LRU = Least Recently Used: l'algorithme de gestion du cache conserve en priorité les données les plus récemment utilisées, NDLR]. Si ce bloc est fréquemment accédé, il restera dans la cache durablement. Or les hotspots dans une baie sont très localisés ; c'est un index, une table ou deux tables. On parle de quelques centaines de gigaoctets, voire un ou deux teraoctets. Donc le cache Flash est largement suffisant et permet de résoudre le problème de la classification des données.

LeMagIT : On commence à parler de nouvelles architectures de baies de stockage conçues pour tirer parti de la Flash. NetApp a-t-il commencé à réfléchir à ce que pourrait être une baie à l'ère de la mémoire Flash ?

B.P. : Oui, on pense que l'on va voir la taille des caches Flash augmenter et, derrière, on ne verra plus que des disques SATA. On pense qu'à terme, si on peut augmenter la taille des caches pour être sûr de pouvoir gérer les problématiques de hotspots, on peut délivrer plus de performances avec un même nombre de disques et surtout la même performance avec beaucoup moins de disques et des disques bien plus économiques. On a réalisé des benchmarks où on a montré qu'en remplaçant des disques rapides par des disques SATA plus lents appuyés par de la Flash, on délivre des performances équivalentes ou supérieures.

LeMagIT : Toutes ces réflexions se heurtent toutefois à des effets de seuil et il faut aussi conserver un rapport performance/prix acceptable pour les clients...

B.P. : En fait, ce scénario Flash SATA est dès aujourd'hui rentable à l'achat, au mètre carré (car on limite l'espace physique occupé par les baies en réduisant le nombre de disques - le plus gros disques SAS fait 600 Go contre 2 To pour le plus gros disque SATA) et aussi en matière de consommation électrique.

LeMagIT : Tous les grands constructeurs utilisent des architectures RAID, mais on commence aussi à voir des alternatives par mirroring ou de distribution de la parité entre noeuds, notamment dans les architectures en cluster comme celle d'Isilon ou de Zetta.

B.P. : Je n'ai rien vu qui évolue de la sorte chez NetApp. Le Raid6 reste ce qu'il y a de plus efficace. Un groupe Raid6 SATA, ce sont 14 disques voire 16 chez NetApp, dont 2 dédiés à la parité. Et on a des clients qui font du 2/28e sur des disques FC ou SAS. De plus l'époque où l'on disait que le SATA n'est pas fiable est révolue.

LeMagIT : NetApp a récemment annoncé l'extinction de son offre VTL. Pourquoi ?

B.P. : On a annoncé l'arrêt du développement de nouvelles fonctionnalités (comme la déduplication inline). Mais la VTL reste à notre catalogue. D'un autre côté, le marché des VTL n'est plus ce qu'il était et on a certaines offres qui répondent souvent mieux aux besoins des clients que les VTL. C'est le cas de nos offres "Vault" qui font du disque à disque en mode bloc incrémental, avec de la déduplication sur la cible. Elles peuvent même servir directement au redémarrage de la production dans le cadre d'un PRA. La VTL était pour certains "un emplâtre sur une jambe de bois". Le seul vrai avantage était les gains de performances sans avoir à changer ses processus de sauvegarde. On a donc décidé de réallouer nos équipes de développement sur des solutions plus demandées, autour de la virtualisation notamment.

En savoir plus sur le MagIT :

Netapp acquiert Bycast pour le stockage des gros volumes

Cloud : après l'alliance VMware, Cisco, EMC, voici venir l'alliance VMware, Cisco, Netapp

Dossier infrastructures : Le cluster de plus en plus tendance en 2010

Notre dossier stockage d'octobre 2009