Pradeep Sindhu : « Juniper double la performance de ses produits chaque année.»

Stratégies Channel

Le fondateur et directeur technique de Juniper explique quelques enjeux de QFabric, et détaille les trois leviers de sa R&D, où plus d’un milliard de dollars ont déjà été investis.
Par José Diz, une interview SiliconDSI

Pendant plusieurs années passées comme ingénieur principal au Computer Science Lab du fameux centre de recherche de Xerox (le PARC ou Palo Alto Research Center), Pradeep Sindhu a travaillé sur l’interconnexion à très haute vitesse des processeurs à mémoire partagée (des travaux qui serviront à la conception des serveurs Sun Microsystem SS1000 et SS2000, par exemple).
En février 2006, il crée Juniper Networks, dont il a occupé plusieurs responsabilités, de président à PDG. Aujourd’hui, il en est vice-président et directeur technique (CTO), et donc en charge de la feuille de route technologique.

Pradeep Sindhu, fondateur de Juniper


Comment l’infrastructure QFabric simplifie-t-elle la gestion des datacenters ?
La gestion des datacenters est devenue très complexe, car elle doit prendre en compte à la fois le réseau, le stockage et la puissance de calcul. En outre, ces trois types d’équipements ont évolué en silos technologiques. Juniper a conçu QFabric pour que chaque ressource soit perçue comme une composante d’un pool de ressources. Ce qui permet de voir et de gérer toutes ressources physiques virtualisées (réseau, stockage ou puissance de calcul) comme des pools communs.

Cela permet :
    * d’assembler toutes les ressources en un pool unique. Ainsi, Google peut décider d’utiliser toutes ses ressources pour réaliser du Search, ou Amazon pour les revendre de façon fractionnée à des centaines d’entreprises. Autant d’opérations rendues possibles grâce à une gestion dynamique des trois types de ressources ;
    * de virtualiser les équipements physiques afin d’allouer dynamiquement ces ressources de manière uniforme (provisionner/déprovisionner), à travers des interfaces utilisées par des solutions comme Tivoli d’IBM, Unicenter de CA Technologies, OpenView d’HP, etc.
Et QFabric est un moyen d’y parvenir en apportant une brique réseau unifiée, gérée dans une seule fenêtre et conçue pour être intégrée aux solutions de VMware, IBM ou Microsoft, et d’autres à venir.

Et qu’en est-il de la coopération entre deux dacatencers QFabric distants ?
Deux Qfabric dans deux datacenters peuvent être connectés et gérés collectivement de façon logique. Néanmoins, il faut prendre en compte les contraintes de distance géographique qui ont forcément un impact sur les performances, selon ce que souhaite faire l’entreprise. Toutefois, cela s’avère intéressant pour une multinationale qui souhaite, par exemple, disposer d’un système d’information de type “Follow the sun”, totalement transparent pour les utilisateurs via un mécanisme de type VMotion qui gère un relai sans interruption de VM entre datacenters.

A suivre, page 2…

 

QFabric utilise-t-elle une version spécifique de JunOS ?
Bien entendu, QFabric s’exécute sous la dernière version de notre système d’exploitation JunOS. Et plus de la moitié de nos efforts en R&D ont effectivement porté sur le logiciel, y compris les extensions à JunOS.
Chaque nouvelle version de notre OS est plus riche, mais sans rupture, garantissant la continuité pour nos clients, et la pérennité de leurs investissements.

L’innovation n’est-elle pas aujourd’hui plus dans le logiciel que dans le matériel ?
Juniper est très attachée à la propriété intellectuelle de ses technologiques qui portent sur les trois pièces-clés de l’infrastructure réseau. Je conçois cette dernière comme une pyramide inversée avec de haut en bas : le logiciel, le système et le silicone. Et les cycles de développement diffèrent puisque les contraintes sont spécifiques. Ainsi, le silicone [les processeurs] imposant de multiples contraintes physiques (précision, chauffe…) nécessite environ trois ans de travail, contre une année environ pour un nouvel OS. Quant au logiciel, nous pouvons en proposer une nouvelle version chaque trimestre.

Le cycle logiciel semble alors plus intéressant…
Effectivement, il pourrait être tentant de tout mettre dans le logiciel. Cependant, le logiciel doit bien tourner sur du matériel et sous un système d’exploitation. Ainsi, si les primitives de vos processeurs sont conçues pour un rendement optimal de votre système et de vos logiciels, vous obtenez de bien meilleures performances globales. Et les primitives des composants sont très différentes entre les équipements réseau et les serveurs, non seulement dans la manière dont elles agissent, mais aussi dans le degré d’efficacité qu’elles permettent sur les performances globales.

Les besoins en ressources explosent, et les performances devraient pouvoir suivre. Juniper doit ainsi doubler les performances de ses solutions chaque année. Et pour y parvenir, le logiciel seul ne suffit pas.

Nous avons déjà investi un milliard de dollars en R&D, et la répartition entre ces trois composantes reste un exercice d’équilibriste complexe pour obtenir la bonne alchimie afin que chacun participe au maximum au meilleur résultat global.