Choisir la containerisation
De nombreuses startups ont adopté des concepts modernes tels que la fourniture de logiciels pouvant être exécutés sur des plates-formes matérielles de type « désagrégé » et l'adoption de logiciels open source tels que Linux.
Cependant, Kaloom délivre deux fonctionnalités absolument uniques :
- la première, c’est que nous avons construit notre solution en utilisant un langage moderne, GO
- la deuxième est que nous avons construit une application complètement « containerisée » afin que le même code puisse s'exécuter indépendamment de la cible physique (commutateurs, serveurs utilisant les toutes dernières générations de « SmartNIC[i] »). Kaloom est le seul fournisseur au monde à disposer de cette capacité. Les principaux fournisseurs de commutateurs tels que Cisco et Juniper ne peuvent pas exécuter leur code sur un serveur et espèrent offrir les mêmes performances et la même efficacité que sur un commutateur, tandis que les principaux fournisseurs de SDN tels que VMware peuvent tirer parti des « SmartNIC » mais ne peuvent pas fonctionner sur un commutateur. En permettant au logiciel Kaloom de fonctionner à la fois sur les commutateurs et les SmartNIC, nous relevons les trois défis mentionnés ci-dessus :
- Les ressources du serveur ne sont pas partagées par les fonctions réseau.
- Seules les fonctions qui ont un sens du point de vue de la topologie de l'application sont exécutées localement ; d'autres fonctions sont exécutées de manière centralisée.
- De grandes quantités de données d'état inter-instances ne sont pas générées, et le trafic n'a pas besoin d'être envoyé à un équipement spécifique pour être géré.
De plus, étant containerises, différents ensembles de conteneurs peuvent être instanciés pour chaque tranche de réseau (« slice »). Non seulement nous pouvons prendre en charge nos propres fonctions de réseau utilisant le concept de containeurs, mais nous pouvons également prendre en charge les applications, les fonctions et les charges de travail réelles des clients (c’est le concept derrière la solution appelée « Unified Edge Fabric »). Les utilisateurs y ont accès via une plate-forme commune et unifiée. Comparez cela aux machines virtuelles, qui ont une surcharge ou une segmentation importante du système d'exploitation au sein d'une pile logicielle monolithique, ce qui est complexe et peut entraîner non seulement de nombreuses failles de sécurité.
Le découpage va au-delà du plan de données (« data plane ») : notre plan de contrôle ( « control plane ») et notre plan de gestion (« management plane ») sont également containerises, de sorte que chaque tranche peut fonctionner de manière totalement indépendante. Cette indépendance matérielle nous permet de fonctionner sur des commutateurs comme sur des serveurs, et nous permet de facilement porter notre solution vers des puces plus récentes avec une meilleure efficacité énergétique, des performances et des capacités.
Avantages de la containerisation
La solution « Unified Edge Fabric » de Kaloom s'appuie sur une distribution Linux prête à l'emploi, à savoir Red Hat Enterprise Linux (RHEL) CoreOS, sans aucune modification (ce qui garantit des mises a jour faciles et rapides). En outre, Kaloom exploite la plate-forme de gestion de containeurs d'entreprise de Red Hat, OpenShift. Cette combinaison apporte plusieurs avantages :
- Kaloom bénéficie d'une large communauté d'utilisateurs qui améliorent la sécurité et la stabilité du système d'exploitation de base.
- Les clients de Kaloom peuvent utiliser immédiatement l’intégralité des outils disponibles autour de l’environnement OpenShift pour gérer la solution Kaloom.
- Dans le contexte « Unified Edge Fabric », les clients de Kaloom peuvent exécuter des fonctions réseau virtualisées et contenairisées, ainsi que des applications basées sur des VM (via l’outil « KubeVirt ») et des containeurs, en parallèle des containeurs Kaloom. Ceci est essentiel pour simplifier la gestion de milliers de sites périphériques, car cela évite d'avoir à gérer séparément les commutateurs, les serveurs, le système d'exploitation et les couches de virtualisation.
La périphérie (« Edge ») croit de manière exponentielle, poussée par des applications telles que l'AR/VR, les jeux, les véhicules autonomes et l'automatisation industrielle. Ces applications imposent des exigences de performance et d'efficacité, nous devions donc inclure autant de fonctions que possible à la périphérie (« Edge »). Et avec la 5G, puisque nous utilisons Red Hat OpenShift, nous pouvons l'utiliser pour contrôler les charges de travail.
Nous avons travaillé en étroite collaboration avec Red Hat pour développer et maintenant fournir une solution commune « Unified Edge Fabric » pour contrôler les charges applicatives via OpenShift. « Unified Edge Fabric » effectue la terminaison 5G pour le côté sans fil et l'orchestration de la charge de travail ; c'est beaucoup plus efficace que de rassembler différents composants séparément, qui ne s'adapteront pas à des dizaines ou des centaines de sites.
Bien sûr, le passage des VM aux conteneurs prenant du temps, nous utilisons donc KubeVirt dans la solution « Unified Edge Fabric » pour permettre aux clients d'exécuter des VM et des conteneurs côte à côte. Étant donné que le réseau est contenairisé, vous n'avez pas à vous soucier de la séparation des données au sein du logiciel réseau et de la complexité qui en résulte - nous déployons simplement un ensemble distinct de containeurs par tranche de réseau.
En éliminant une grande partie de la duplication qu'impliquent les machines virtuelles, vous n'avez besoin d'exécuter qu'un seul système d'exploitation. En revanche, si vous devez créer une machine virtuelle distincte pour chaque tranche, vous utiliserez rapidement toutes les ressources de traitement, de réseau et de stockage disponibles.
Améliorations futures
L'objectif de Kaloom pour le reste de 2022 est d'approfondir notre intégration avec l'écosystème Red Hat OpenShift et d'élargir le nombre de plates-formes matérielles validées. Jusqu'à présent, Kaloom s'est principalement concentré sur le chipset Intel Tofino1. Nous étendrons également nos capacités en prenant en charge les chipsets Intel Tofino2 et Stratix DX, ainsi que les SmartNIC de Intel et Nvidia.
[i] “SmartNICs” sont identifiées également comme « IPUs – Infrastructure Processing Units » ou « DPUs – Data Processing Units»
