Stockage sur Kubernetes : comment Ondat entend devenir leader du marché

Interview. LeMagIT est allé à la rencontre de cette startup qui décline un savoir-faire acquis sur les systèmes des grandes banques pour proposer une élasticité inédite aux applications critiques.

Cet article est extrait d'un de nos magazines. Téléchargez gratuitement ce numéro de : STORAGE: Storage 32 : Kubernetes, le nouveau terrain de jeu du stockage

La startup Ondat, ex-StorageOS, va-t-elle devenir le leader des solutions de stockage pour Kubernetes ? C’est en tout ce que laissait supposer l’afflux de visiteurs sur son stand, lors du salon KubeCON, qui se tenait mi-mai à Valence. Jouant d’abord des coudes pour se faire un nom parmi les géants du stockage, convertis depuis peu à Kubernetes (Pure Storage, NetApp, Dell EMC, DataCore…), Ondat a changé de nom pour rendre ses différences technologiques plus audibles.

Notamment, il est le seul à proposer une solution de stockage pour Kubernetes qui fonctionne en mode bloc, c’est-à-dire au plus proche des performances d’une infrastructure. Cette caractéristique rend possible l’exécution de bases de données critiques depuis Kubernetes. Ou, dit autrement, elle fait sauter le verrou qui empêchait jusqu’ici les applications hautement performantes de bénéficier de toute l’élasticité qu’autorise le cloud.

Pour comprendre qui est ce probable futur champion du stockage pour Kubernetes, LeMagIT est allé à la rencontre de son PDG et fondateur, Alex Chircop. Interview.  

LeMagIT : En deux mots, quels sont les avantages d’Ondat sur le marché des systèmes de stockage pour Kubernetes ?

Alex Chircop : Notre atout parmi les autres solutions de stockage pour Kubernetes est que notre technologie est agnostique. Nous pouvons être déployés sur tous les systèmes, nous n’avons aucune dépendance envers un matériel ou envers le noyau d’un système. Tous nos concurrents s’installent avec une sorte de pilote qui doit spécifiquement exister pour l’architecture sous-jacente. En clair, lorsque vous savez utiliser notre solution, vous savez l’utiliser sur votre PC portable pour développer, sur les serveurs de votre entreprise qu’importe leur marque et sur les instances virtuelles des clouds publics.

Nous offrons le même niveau de service partout. C’est essentiel dans les projets de cloud hybride lorsque des questions de performances entrent en jeu et que vous redoutez que votre application ne fonctionne plus aussi rapidement selon l’endroit où elle est exécutée.

Le second avantage, justement, est que nous apportons de la performance, même quand vous agrandissez votre stockage. Nous revendiquons avoir la solution la plus rapide sur son segment de marché, de cinq à vingt fois plus rapide que les solutions Open source.

Alex Chircop, PDG d'Ondat.
Alex Chircop, PDG d'Ondat.

Enfin, nous sommes reconnus comme extrêmement fiables. Et pour cause, nous faisons de la réplication synchrone entre les nœuds. Synchrone, c’est-à-dire en temps réel, y compris entre deux datacenters, pour continuer l’activité en cas de sinistre sur un site de production. Accenture, par exemple, a déployé notre solution pour des applications critiques, dans de grandes banques notamment. Notre solution traite des milliards de transactions chaque jour.

LeMagIT : Comment faites-vous pour être plus performants que les autres ?

Alex Chircop : Nous travaillons au niveau bloc, pas au niveau fichier, c’est-à-dire au plus proche du matériel. Cela nous permet d’atteindre des latences excessivement faibles. Or, qui dit faible latence, dit plus de transactions par seconde pour une base de données. Vous savez, tous nos ingénieurs travaillaient auparavant sur les infrastructures des banques. Moi-même, j’ai construit chez Goldman Sachs des systèmes avec un stockage à très faible latence pour exécuter des applications hautement critiques.

LeMagIT : c’est tout de même paradoxal, non ? Votre solution est capable de soutenir des bases de données critiques, mais Kubernetes n’a pas été conçu pour exécuter des bases de données transactionnelles…

Alex Chircop : Je vais vous dire ce que nous observons sur le marché. En pratique, Kubernetes est utilisé pour apporter aux développeurs une approche déclarative de leurs applications. C’est-à-dire que, grâce à Kubernetes, ils peuvent enfin dire « voici mon application, voici la quantité de puissance de calcul et la bande passante réseau dont elle a besoin. » Et Kubernetes se charge tout seul de maintenir ces prérogatives au fur et à mesure qu’il démultiplie les containers pour supporter les pics d’activité. C’est tout. Et cela n’a rien à voir avec le type d’application que Kubernetes exécute. Seule l’élasticité automatique des bonnes caractéristiques d’infrastructure compte, en définitive.

Et puis, de fil en aiguille, les entreprises ont mis en containers des applications qui devaient stocker quelque part leurs données en cours de traitement. Éventuellement pour qu’elles soient reprises par des applications qui ne sont même pas exécutées par Kubernetes, mais qui sont exécutées sur des machines virtuelles, ou des serveurs physiques, dans le datacenter comme dans un cloud.

Vous allez me dire, pourquoi les entreprises ont-elles mis ces applications-là en containers ? Hé bien tout simplement parce que certaines entreprises dépensent par exemple 26 milliards de dollars par an pour faire tourner leurs bases de données sur RDS, l’offre d’AWS. C’est énorme. Et c’est énorme parce que, jusqu’ici les ressources n’étaient pas correctement provisionnées. On réservait trop de ressources par peur d’en manquer lors des pics d’activité. Avec Kubernetes, vous éliminez ce problème : les ressources déployées et facturées correspondent exactement à ce dont vous avez besoin pour servir tous vos utilisateurs.

Mais comme vous le faites remarquer, Kubernetes n’est pas prévu normalement pour cela. Jusqu’à ce que nous lui apportions le système de stockage qui rend cela possible. Et, encore une fois, il rend cela possible, quelle que soit l’infrastructure. C’est-à-dire qu’en cloud, nous sommes par exemple les seuls à pouvoir exploiter la vitesse maximale des ressources de stockage d’AWS ou d’Azure qui reposent sur des SSD NVMes. Sorti d’Ondat, vous utilisez toutes les ressources de stockage en cloud de manière équivalente, comme des volumes de fichiers. Et si vous comparez les prix, vous vous apercevez que les SSD NVMe en cloud coûtent au final 70 % moins cher que les baies Flash propriétaires que vous installez habituellement dans un datacenter pour avoir du NVMe.

LeMagIT : Comme les autres, votre solution repose sur un pilote CSI pour Kubernetes (Container Storage Interface). Il suffirait que vos concurrents ajoutent le mode bloc dans leur CSI pour atteindre les mêmes performances que vous, non ?

Alex Chircop : Pas seulement. Il y a un savoir-faire dans l’implémentation d’un CSI. Comme je vous le disais, nos concurrents vont proposer des CSI optimisés pour communiquer avec leurs infrastructures et qui se comporteront de manière générique dans le cloud. Sauf qu’en Kubernetes, vous êtes susceptible de créer et de détruire 10 000 volumes de stockage logique par jour dans le cloud. Aucune baie de stockage, aucun SDS n’est capable de supporter cela, donc leur CSI ne le supportera pas plus dans le cloud.

LeMagIT : Parmi tous les fournisseurs de stockage, n’est-ce pas un inconvénient pour vous d’être le seul à ne pas proposer de baies de disques ? N’avez-vous pas un problème de crédibilité ?

Alex Chircop : Nos clients nous disent qu’ils ne veulent pas acheter de solutions propriétaires. Franchement, quel est l’avantage de ces solutions ? Notre système vous permet de bâtir un cluster de stockage avec 300 000 SSD NVMe dans des tiroirs de disques génériques. Il vous permet de stocker depuis un seul serveur VDI 500 volumes pour autant de bureaux distants. Notre solution vous apporte plus d’évolutivité que toutes les baies de stockage existantes. Et, en plus, vous n’êtes pas prisonnier d’un matériel propriétaire.

LeMagIT : Initialement, vous vous appeliez StorageOS. Pourquoi avoir changé de nom ?

Alex Chircop : Pour nous rapprocher des développeurs. Nous avons constaté que sur les projets modernes, dits « cloud native », ce sont les développeurs à présent qui prennent les décisions sur les services de données, sur leur vitesse d’accès, sur leur protection. Or, les développeurs n’entendent rien au stockage comme on le conçoit dans une DSI. Ils veulent de la disponibilité, de la sécurité par chiffrement, ils ne veulent pas qu’on leur parle d’infrastructure. Donc, nous n’avons plus une marque qui raisonne comme un produit d’infrastructure.

Et ça marche. Depuis que nous avons changé de nom, nous avons plus de cent nouveaux utilisateurs par mois. Leur nombre a triplé. Vu le succès que nous rencontrons, nous pouvons affirmer que ce changement de marque était vraiment la bonne décision.

LeMagIT : sur quels sujets les visiteurs du salon KubeCON vous ont-ils interrogés ?

Alex Chircop : Majoritairement, sur la manière d’intégrer dans Kubernetes du stockage déjà déployé en cloud, typiquement sur l’offre en mode bloc EBS d’AWS. Le problème d’EBS est qu’il est très performant pour les bases de données – surtout s’il repose sur des SSD NVMe – mais, sans Kubernetes, il n’est pas élastique et encore moins élastique entre deux zones géographiques. Nous leur expliquons que, grâce à notre solution, leurs déploiements gagneront l’élasticité sans perdre les performances. Et que, en plus, nous répliquerons en temps réel leurs données entre plusieurs zones géographiques.

Étonnamment, alors que nous adressons plutôt habituellement les besoins des banques, les gens qui se sont le plus intéressés à notre solution venaient du monde des télécoms, de la défense, ou encore de la grande distribution. Ils ont vu dans Ondat la possibilité d’avoir des capacités plus grandes, plus élastiques, qu’ils pouvaient mieux segmenter. Ils ont aussi été très intéressés par notre capacité à faire du chiffrement en temps réel, toujours grâce à notre maîtrise de la performance.

Pour approfondir sur SAN et NAS

Close