Rendez-vous avec Eric ANTIBI,
Directeur technique, NetApp France
Propos recueillis par Frédéric MILLIOT

HPC Today – Première question, pour rentrer dans le vif du sujet, quelle est votre définition du “Big Data” ? S’agit-il simplement de problématiques de données à grande échelle ?

Eric Antibi – Non, bien sûr, il ne s’agit pas que de cela. Chez NetApp, pour définir le terme Big Data, on part d’une approche dite “ABC”, où A, B et C décrivent des domaines distincts et connexes, certains pas toujours innovants d’ailleurs… Le domaine A, c’est celui de l’Analytique. Sans s’étendre, puisque le terme est connu, il s’agit grosso modo de savoir comment tirer plus de richesse, de profit, de sens, pourquoi pas en temps réel, de données que l’organisation possède déjà. Il arrive fréquemment que les données, en effet, soient déjà présentes ; il manque juste les infrastructures de grande envergure pour pouvoir les exploiter. Le problème étant alors que, plus elles vieillissent, plus elles perdent de leur valeur. C’est peut-être moins un peu moins vrai dans le domaine scientifique que dans le domaine marketing – encore que. Mais passons. Le domaine B, c’est celui de la Bande passante, préoccupation qui rejoint assez directement celles du monde HPC, et qui pour nous est au cœur de problématiques techniques précises, notamment celles qui concernent la vidéo. Enfin, le domaine C est celui des Contenus, comme vous l’aurez probablement deviné. Cet aspect touche surtout aux besoins en stockage, c’est-à-dire comment faire pour qu’un utilisateur dispose de l’ensemble des données dont il a besoin à partir d’un référentiel unique. Là, on parle de stockage objet, d’un index unifié permettant l’accès à des milliards d’éléments, pour adresser plusieurs Pétaoctets de données et cela quel que soit leur site d’hébergement.

Entre parenthèses, cette approche ABC, plutôt propre à NetApp, rejoint directement la définition classique des 4V (Volume, Velocity, Variety, Veracity) grâce à laquelle on définit classiquement le Big Data. Et donc, pour répondre aux besoins spécifiques du HPC, NetApp propose des briques de stockage offrant des spécifications clés : la performance (débits granulaires, jusqu’à plusieurs dizaines de Go/s tenus en continu), la densité (jusqu’à 70 disques sur 4U) et un très haut taux de disponibilité et de résilience. Pour ces deux derniers points, il est toujours difficile de publier des chiffres officiels mais on est clairement en “5×9” [99,999 % de disponibilité – Ndlr] – mesure établie sur une base installée de plus de 500 000 briques de type E-Series. Les besoins HPC étant très spécifiques, il leur faut des solutions appropriées. Nous pensons que ces solutions doivent offrir au minimum les mêmes performances que les solutions de classe entreprise. D’où en pratique une première voie de convergence…

Justement, restons sur cette question de la convergence. Les deux communautés HPC et Big Data semblent désormais parties pour travailler ensemble aux mêmes objectifs. Quels sont, selon vous, les principaux axes de rapprochement ?

La vision que nous avons aujourd’hui est que, concrètement, il existe effectivement des points communs dans les démarches, mais pas encore de vraies solutions convergentes, en tout cas d’un point de vue opérationnel. Les solutions HPC basées sur Hadoop ne sont encore qu’embryonnaires, quand elles fonctionnent. Cela étant dit, si l’on se projette à quelques années, en tous cas avant 2020, nous pensons que les infrastructures vont s’unifier, que le concept de fermes de serveurs avec stockage attaché sera le seul réellement applicable à très grande échelle, que l’administration répartie va se révéler incontournable et que dans tous les cas, l’Open Source va régner en maître. Hadoop et Lustre en sont deux parfaits exemples.

Quelles sont les bonnes pratiques HPC que vous souhaiteriez voir répliquer dans le monde Big Data  ?

Contrairement à la majorité de nos clients, un site qui fait du HPC à grande échelle depuis 10 ans et qui doit intégrer un projet analytique devrait normalement tirer profit de son savoir faire en termes d’administration, de fermes de calculs, de systèmes de fichiers partagés, de briques de stockage attachées à chacun des serveurs… pour probablement gagner pas mal de temps dans le déploiement d’Hadoop. C’est pour lui un énorme avantage. Pourrait-il donc faire autrement ? En revanche, il faut savoir que dans le monde de l’entreprise, là où naissent la majorité des projets Big Data, ce sont généralement les directions marketing qui sont à l’initiative. Du point de vue des cultures opérationnelles et techniques, l’adoption des bonnes pratiques peut alors être plus délicate – ou au moins plus longue… Pour les aspects system management, accélération matérielle, parallélisation des traitements, qui sont sans doute les plus importantes des bonnes pratiques HPC dont le Big Data aurait besoin, c’est parfois un peu dommage.

Et à l’inverse, quelles sont les bonnes pratiques du Big Data dont, à votre sens, la communauté HPC pourrait profiter ?

Il y a bien la culture de la modélisation des données, dont l’objectif est d’augmenter la lisibilité et de simplifier les traitements en aval, donc de pouvoir techniquement les accélérer, mais, à vrai dire, il existe aujourd’hui une différence de maturité telle entre les deux mondes qu’il est sans doute prématuré d’évoquer des bonnes pratiques Big Data suffisamment établies pour qu’elles puissent profiter au HPC.

Dans le monde HPC, on sait a priori où les données résident. Ce n’est typiquement pas le cas dans le monde Big Data. Comment voyez-vous cette équation se résoudre ? Avec les problèmes de performances d’accès que cela suppose, de performances d’interconnexions distantes…

Effectivement, dans un cas d’implémentation Big Data typique, on cherche à tirer profit de données qui peuvent être internes, externes, distantes… sans qu’on se préoccupe réellement de leur localisation. Ce n’est bien sûr pas le cas dans un environnement HPC traditionnel, d’autant que cette localisation précise joue un rôle déterminant dans la performance. Avant de parler de performance pure en Big Data, on voit néanmoins arriver des connecteurs entre Hadoop, par exemple, et des solutions de stockage objet. Il s’ensuit une prise en compte de la notion de contenus et une localisation en tous cas logique via un référentiel unifié. Les intérêts fonctionnels sont multiples et permettent, aux utilisateurs qui doivent pouvoir accéder à tel ou tel sous-ensemble de données, de pouvoir le faire quasiment comme si ces données étaient stockées de façon classique.

Un certain nombre de gros sites HPC dans le monde industriel ont des POC Hadoop. Qu’avez-vous a leur offrir pour concrétiser ces POC en solutions de production ?

Des infrastructures hébergées chez nous et de dimensions quasiment illimitées, leur permettant de tester des solutions, de valider des stratégies de déploiement ou de mesurer des niveaux de performance réels à l’échelle exacte – sinon plus – de leurs besoins. Avec en accompagnement des ressources techniques dont je crois qu’on peut dire qu’elles sont de haut niveau. Ensuite, quand les options sont validées, nous avons évidemment les produits et les équipes pour mettre les systèmes en production, que ce soit à l’initiative de l’utilisateur final ou par le biais d’un intégrateur global auprès duquel nous serions partenaires. Et, vous avez raison, ces POC Hadoop se multiplient, parfois sur des sites qui nous surprennent nous-mêmes, ce qui tend à prouver que l’ensemble de la communauté IT, et plus particulièrement de gros utilisateurs HPC, s’y intéressent de très près.

On s’achemine vers des applications HPC produisant tellement de données qu’il devient inenvisageable de les stocker toutes intégralement. C’est notamment le cas en astronomie. Quelle(s) solution(s) préconisez-vous pour déterminer lesquelles garder, en temps quasi réel ? MapReduce ?

Effectivement, la solution de prédilection, en tous cas sur nos plateformes, c’est MapReduce. Son côté généraliste fait qu’il se plie assez bien à une large variété de contraintes fonctionnelles. Il autorise par ailleurs pas mal de traitements en temps réel et, par contrecoup, l’élimination de certaines données qu’il n’est plus nécessaire, après filtrage par exemple, de stocker de façon permanente. Cela dit, pour élargir un peu la question, il existe également des cas dans lesquels MapReduce n’est pas nécessaire. Ou, plutôt, dans lesquels l’analytique n’est pas nécessaire. Pour des problématiques simples de qualification de données, les bonnes vieilles techniques de business intelligence, telles qu’on les applique en entreprise depuis une bonne quinzaine d’années maintenant, suffisent amplement. Ce qui simplifie la mise en œuvre des solutions concrètes, ne serait-ce que du fait de la maturité de ces approches, et évite bien des inconvénients liés au surdimensionnement des solutions. Clairement, si les termes “Big Data”, “analytique” et “MapReduce” font l’actualité aujourd’hui, on peut aussi éviter de se laisser emporter. Hadoop, les piles Open Source, le stockage attaché… tous ces éléments sont aujourd’hui disponibles mais ils forment ensemble une infrastructure à mettre en place, avec ses problèmes techniques et ses coûts d’administration propres. C’est d’abord la nécessité de l’analytique que doivent évaluer les responsables de projets, industriels ou scientifiques.

Quelle est aujourd’hui, selon vous, la meilleure technologie pour l’analyse et le traitement de big data vidéo ?

Pour nous, la bonne solution en big data vidéo, c’est StorNext [plateforme logicielle proposée par Quantum – Ndlr]. D’ailleurs, nous avons déjà des déploiements en production chez plusieurs chaînes de télévision françaises. L’avantage de StorNext, c’est son système de fichiers distribué et, sur cette base, la possibilité de tenir des dizaines de Go par seconde. Autre gros avantage : en tant qu’infrastructure unifiée – c’est-à-dire la pile logicielle plus nos baies E-Series – cette solution permet de gérer à la fois les flux HD qui demandent de très très hautes performances, et le HSM [High-Speed Machining – Ndlr] qui permet un archivage des images lui aussi très performant, notamment en accès lecture. C’est un vrai progrès par rapport aux approches traditionnelles, où on trouve typiquement deux plateformes, l’une pour les flux, l’autres pour l’archivage, avec tous les inconvénients que comporte cette dualité. En général, chez nos clients en tous cas, c’est à l’occasion du passage en HD que les migrations se font, des anciennes infrastructures aux solutions StorNext.

Pour NetApp, la collaboration avec le CERN est emblématique. Nous y consacrerons prochainement un dossier technique détaillé mais, en attendant, pourriez-vous décrire en quoi elle consiste précisément ?

Au CERN, le contexte est un peu différent du HPC typique. On est plutôt dans le HTC [High-Throughput Computing – Ndrl] qui, comme son nom l’indique, met l’accent sur les performances en production de données plutôt qu’en calcul. Le fondement de la solution CERN, pour les données, c’est notre OS, ONTAP. Ce qui intéressait le CERN, c’était d’héberger des bases de données Oracle sur un protocole NFS, donc quelque chose de très courant, à ceci près peut-être que, chez eux, le client NFS est inclus dans la base Oracle. L’idée, ensuite, a consisté à tirer avantage de la dernière version d’ONTAP, baptisée ONTAP Cluster, qui permet d’avoir en même temps l’intelligence du SGBD, notamment la sauvegarde et la restauration rapide de bases de plusieurs Po, et la possibilité de monter en performances avec une approche cluster. Là où, traditionnellement, on a une baie avec au maximum deux contrôleurs, si on a besoin d’espace en plus, on juxtapose les baies. Avec ONTAP Cluster, la base globale a pu être consolidée sur une ferme de stockage unifiée offrant un espace virtuellement illimité vu comme une seule brique logique. On peut d’ailleurs faire une analogie valable entre ferme de serveurs et ferme de stockage. Les avantages de l’unification et de l’illimité sont les mêmes.

A votre avis, pourquoi le choix de NetApp ?

Principalement pour la valeur ajoutée présente dans ONTAP lorsqu’on l’utilise sur nos baies. Cette valeur ajoutée, plusieurs fonctionnalités y concourent. Difficile de les mentionner toutes mais citons d’abord les snapshots automatisés toutes les 15 minutes. Ensuite, il y a les clones fins, c’est-à-dire la possibilité d’exposer à X serveurs différents une même base sans avoir à la répliquer, et en conservant une parfaite synchronisation entre les X instances, d’où efficacité et économie d’espace. Enfin, le CERN a été sensible au très haut niveau de performances que nous atteignons à partir de disques SATA. Les baies NetApp utilisées disposent d’un cache intelligent qui passe en technologie flash (au niveau de plus fin, c’est-à-dire les blocs de 4 Ko) quand l’utilisateur a besoin d’accélérer l’accès au données, et redescend en SATA en utilisation “normale”. Cela permet de résoudre tous les problèmes de tiering sans devoir recourir à des stratégies complexes et sans administration. Techniquement, la pertinence de cette approche dépend de la taille des caches. Or, chez NetApp, ce cache peut aller jusqu’à 16 To par baie. Comme on est en configuration cluster et qu’on peut donc agréger des dizaines de baies, cette taille de cache peut atteindre plusieurs centaines de To… une spécification tout à fait en rapport avec les besoins du LHC.

Et vous n’avez jamais songé à multiplier les niveaux de cache, pour optimiser le ratio performances / espace / coût de cette approche ?

Pour ne rien vous cacher, c’est ce qu’on fait en pratique. Je m’explique : l’approche cache se gère selon trois modes. Primo, on accélère directement les accès aux données se trouvant sur les disques physiques. On appelle cette technique “flashpool” (ou agrégat hybride) : le SATA est complété d’un peu de SSD qui joue le rôle de cache. C’est un premier niveau, qui opère sur le back-end disk. Deuxième niveau, on opère au niveau contrôleur. Bien qu’il dispose déjà de sa propre mémoire de plusieurs dizaines de Go, on lui ajoute du flash cache, c’est-à-dire de la mémoire montée sur cartes PCI. Enfin, troisième niveau, on est capable d’OEMiser les solutions de cache côté serveur, en utilisant notamment FusionIO et en le combinant avec une de nos applications, FlashAccel. Dans cette configuration, le cache serveur prend la main sur le système de stockage traditionnel, d’où des temps de traitement, y compris en restauration, significativement plus intéressants. En particulier, on évite de repasser par le réseau SAN, ce qui, comme vous l’imaginez, se traduit immédiatement en termes de performances.

C’est donc une sorte de driver ?

Tout à fait, on peut le voir comme cela.

Imaginons la sortie éventuelle de data processors ou de data nodes plus orientés débits que calcul. Qu’est-ce qu’un acteur majeur comme NetApp peut attendre de ce type d’initiative ?

Il est clair que, en tant que consommateurs de processeurs, si de telles offres apparaissent, nous les intégreront dans nos solutions, notamment dans nos contrôleurs. C’est une évidence. Deuxième point, peut-être plus intéressant, nous proposons maintenant notre OS de clustering intelligent ONTAP, évoqué plus haut, en version logicielle. Aujourd’hui, vous pouvez utiliser ONTAP dans une VM sur un serveur VMWare. Donc, on peut imaginer que la combinaison de cette solution avec de tels data nodes ou processors donnerait des résultats intéressants. En résumé, en tant qu’intégrateur mais aussi en tant que fournisseur de solutions complémentaires, nous permettront aux utilisateurs NetApp de bénéficier directement de ces composants, le jour où, éventuellement, ils sortiront.

De votre point vue de spécialiste des données, quels obstacles techniques voyez-vous se dresser sur la route de l’exascale ?

Je verrai deux choses, clairement liées aux problématiques traitées par notre R&D depuis des années. La question la plus immédiate qui se pose, c’est comment être le plus efficace possible, le plus dense possible, face à l’explosion de la volumétrie, sachant qu’on ne pourra pas repousser les murs des datacenters à l’infini ? Seconde grande question, comment lier les traitements (HPC, Hadoop) et le référentiel objet, c’est-à-dire le contenu ? Si l’aspect objet me semble désormais acquis, reste maintenant à relever de gros défis techniques quant à son implémentation et à son optimisation. Sur ces deux points, les années qui viennent vont être assez passionnantes. Difficile de prédire quelles formes technologiques prendront les réponses à ces deux questions, mais ces obstacles devront nécessairement être franchis, faute de quoi l’exascale, notamment dans sa composante exabyte, ne sera pas atteinte.