Dare to Bare: opérer les containers sur du bare metal

Pour ceux qui ont besoin de performance dans l’exploitation de leurs containers et qui ont des workloads importants, il est préférable d’exécuter les containers sur du bare metal plutôt que d’utiliser des instances cloud ou machines virtuelles (VM) comme couche entre le container et les serveurs physiques.

La structure la plus simple est souvent la plus efficace. Cela s’applique également aux infrastructures cloud. Pour ceux qui ont besoin de performance dans l’exploitation de leurs containers et qui ont des workloads importants, il est préférable d’exécuter les containers sur du bare metal plutôt que d’utiliser des instances cloud ou machines virtuelles (VM) comme couche entre le container et les serveurs physiques.

En éliminant la plateforme de virtualisation ou la couche IaaS, l’infrastructure devient immédiatement moins complexe avec un impact positif sur les opérations. Il y a moins de réseaux, d’hôtes et de disques à administrer, de sorte que l’infrastructure peut être gérée par moins de personnes.

Chaque couche en moins dans l’infrastructure conduit logiquement à ce que le système soit moins sujet aux erreurs, il y a moins de niveaux où quelque chose peut mal tourner ou dont quelqu’un doit s’occuper.

Meilleure exploitation des ressources

Côté performance, les éléments matériels peuvent être utilisés plus efficacement sur le bare metal. Toutes les ressources hardware peuvent être exploitées, puisqu’aucune n’est utilisée pour l’émulation matérielle par une couche de virtualisation. On élimine ainsi la double encapsulation des données et on accélère le réseau. Il n’y a pas deux SDN empilés l’un sur l’autre, mais un seul, ce qui augmente les performances.

Il est également intéressant de constater que pour un tel cloud, on peut très bien utiliser du matériel assez simple sans nécessiter de grandes redondances. Il n’est pas nécessaire d’investir dans des doubles alimentations ou des connexions réseau redondantes, car en cas de panne du système, la gestion des containers garantit que ces derniers sont redémarrés directement sur un autre système - ils sont déjà répartis dans plusieurs instances sur des systèmes multiples. Ainsi, si un serveur est en panne, il est simplement remplacé par un nouveau, qui n’a plus qu’à être allumé, le système de gestion cloud s’occupe du reste.

Moins de redondances

Si l’on exécute les services formant une couche IaaS – comme OpenStack – dans les containers, on fait d’une pierre deux coups: d’une part le framework de containers assure une haute disponibilité pour ces services, et d’autre part, les services IaaS apportent une valeur ajoutée bienvenue, par exemple dans le domaine du stockage et de la gestion du bare metal. On peut également les mettre à disposition pour les VM et instances cloud.

Maîtrise de la sécurité

Abordons enfin le domaine de la sécurité. Si l’application est exécutée sur des hôtes bare metal que l’on l’exploite soi-même, on a la sécurité sous contrôle. Avec une machine virtuelle dans un cloud public, les choses sont différentes: une fuite sur une VM quelconque de l’environnement peut avoir un effet sur sa propre VM. Dans un environnement bare metal, les applications ou les clients peuvent être physiquement séparés si besoin.

Bien sûr, il y a aussi des inconvénients à faire tourner ses containers sur du bare metal. Ainsi, la plateforme ne peut pas être mise à l’échelle de manière aussi flexible que sur des instances de cloud public. Il faut commander du nouveau hardware à temps et l’installer dans le rack si l’in souhaite utiliser une telle plateforme en interne. Mais de plus en plus de fournisseurs cloud offrent des performances bare metal pour les containers.

Compte tenu de la baisse des coûts du matériel et de la complexité croissante des écosystèmes de containers, le cloud bare metal semble être un endroit sûr pour l’avenir.

----------

Au-delà d’une certaine taille, le bare metal est une alternative plus rentable

Les containers sur des hôtes bare metal sont considérés comme l’avenir du cloud computing. Pourquoi et quels ­aspects doivent être pris en compte lors de la mise en place d’un tel environnement? Explications avec Dominik Wotruba, Head Solution Architecture chez Red Hat Suisse. Interview: Oliver Schneider

Dans son article, Stefan Marx suggère que les containers sur du bare metal sont l’avenir du cloud. Pourquoi en est-il ainsi?

L’avenir du cloud computing est hybride. Les raisons sont multiples: des besoins techniques différents – temps de latence, par exemple –, des modèles de prix différents, des exigences réglementaires et de sécurité différentes. En outre, les logiciels ne sont souvent certifiés que pour certains déploiements. Il est important de s’appuyer sur une technologie de container qui offre autant de flexibilité que possible et pour laquelle il n’y a pas de lock-in du fournisseur. Selon le cas d’utilisation, nous recommandons d’utiliser la technologie de container Red Hat OpenShift sur du bare metal, des machines virtuelles ou des clouds publics tels que Google, Azure ou Amazon. Le bare metal est certainement une approche utile, mais pas la seule. L’utilisation de GPU sur des serveurs bare metal pour l’intelligence artificielle est un bon cas d’utilisation.

Si le bare metal offre tant d’avantages, pourquoi s’appuie-t-on encore aujourd’hui sur les machines virtuelles?

Le bare metal n’a de sens pour les containers qu’à partir d’une certaine taille, workload ou cas d’utilisation, car des investissements en matériel sont nécessaires. Avec la virtualisation, on profite du fait que souvent une infrastructure virtuelle existe déjà avec de la capacité disponible. La virtualisation offre une flexibilité supplémentaire. C’est pourquoi, dans la plupart des cas, les clients optent pour la virtualisation. Au-delà d’une certaine taille, le bare metal est une alternative plus rentable, car on économise sur les licences de virtualisation et on élimine l’administration de la virtualisation. Passer de la virtualisation au bare metal demande un effort limité et peut se faire sans interruption si on le planifie bien.

En cas de panne du système bare metal, les containers peuvent être transférés directement sur un autre serveur. Comment cela fonctionne-t-il?

La technologie Red Hat OpenShift offre de la haute disponibilité via l’orchestration des containers en exécutant l’application containerisée sur plusieurs serveurs. Si un serveur tombe en panne, l’application est redémarrée sur un autre serveur. La solution s’assure également que tout se déroule de manière transparente pour l’utilisateur en acheminant le trafic vers un container ou une réplique fonctionnelle.

N’y a-t-il pas un risque de sécurité si tous les containers fonctionnent dans un seul système d’exploitation au lieu de machines virtuelles isolées?

Ce risque de sécurité est résolu dans OpenShift avec Red Hat Enterprise Linux en sous-jacent. Le système d’exploitation implémente un certain nombre de facteurs de protection, tels que SELinux, SECCOMP ou Capabilities, qui empêchent de forcer un container ou de subir des dommages supplémentaires en cas de prolifération d’un virus. L’orchestrateur possède également des fonctionnalités telles que Security Context Constraints qui implémentent et renforcent encore la sécurité.

De quoi les entreprises doivent-elles tenir compte si elles veulent construire un environnement de containers sur du bare metal?

Il y a différents modèles de licences et d’abonnements à considérer. Dans le cas du bare metal, il est également toujours important d’avoir des processus optimaux permettant de fournir rapidement du hardware supplémentaire si nécessaire. Le stockage, qu’il s’agisse d’approches hyperconvergées ou non, doit également être pris en compte, car la flexibilité peut ne pas toujours être la même qu’avec une solution virtualisée.