Créer un centre de données dans le cloud privé s'apparente à la construction d'une voiture de sport à partir de rien. Vous devez choisir le bon moteur, les bonnes pièces et les bons équipements pour répondre aux exigences de la route et du conducteur. Grâce aux innovations matérielles et logicielles, les architectes informatiques peuvent désormais concevoir leurs centres de données comme une Lamborghini et non plus comme une vieille voiture.
Les clouds privés sur site requièrent une surveillance, une gestion et une maintenance constantes. Les frais d'exploitation, tels que le remplacement de disque ou le surprovisionnement, peuvent s'additionner rapidement et peser lourd. Le coût total de possession des centres de données augmente et les résultats de l'entreprise s'en trouvent réduits. Cela est d'autant plus vrai que la collecte, la création et l'utilisation de données connaissent une croissance exponentielle chaque année.
Ces problèmes participent à la tendance actuelle forte de ce que Seagate appelle la « composabilité ». Les centres de données modernes et composables permettent à chaque serveur de cloud privé de reposer sur des éléments distants mais interconnectés au moyen d'une matrice et d'une bande passante optimales. Une infrastructure composable offre un moyen plus souple de gérer et d'accéder aux données sur plusieurs applications et flux de données.
Les architectes informatiques décident s'ils veulent utiliser une solution de cloud privé sur site ou un cloud public/privé hébergé par un tiers. Dans un cloud public, les services informatiques sont mutualisés avec les autres clients et hébergés dans un centre de données externe. Les fournisseurs tiers proposent également des clouds privés externes dont les services ne sont pas partagés.
Le cloud privé sur site, quant à lui, est un type de cloud dont la gestion et la maintenance sont assurées par le propre centre de données d'une entreprise et les services ne sont pas partagés avec les autres organisations. Les avantages principaux du cloud privé sur site sont la sécurité, la flexibilité et un niveau de performances plus élevé. Les utilisateurs peuvent personnaliser leurs ressources et leurs services de sorte que leur matériel réponde aux besoins uniques de chaque application, plutôt que d'opter pour une approche globale. Ils disposent d'un contrôle total sur la sécurité, l'évolutivité et la configurabilité de leurs serveurs.
À mesure que les besoins des applications augmentent ou diminuent, les composants et les serveurs communiquent entre eux afin d'équilibrer la charge de travail. Les architectes informatiques peuvent ainsi concevoir des centres de données sur mesure à l'aide d'un large éventail de composants matériels provenant de divers fabricants. Ils décomposent ou désagrègent littéralement l'infrastructure traditionnelle des centres de données, puis, une fois le châssis complètement désossé, ils reconstruisent le centre de données de manière à utiliser plus efficacement les ressources installées. Ils évitent ainsi le surcoût lié à l'achat de matériel inutile et peuvent remplacer les composants sans aucune interruption.
La désagrégation et la composabilité des centres de données dans le cloud privé ont évolué de l'architecture réseau traditionnelle vers l'infrastructure dynamique d'aujourd'hui qui permet d'exploiter des systèmes puissants et exigeants. L'infrastructure désagrégée composable présente plusieurs avantages clés, notamment une latence réduite et un renforcement de la sécurité et du contrôle sur les données.
Les limites du centre de données traditionnel
L'architecture informatique traditionnelle atteint ses limites en raison de la croissance exponentielle du volume de données et de la complexité croissante des applications logicielles. Les processeurs, la mémoire DRAM, la mémoire de type classe de stockage, les processeurs graphiques, les SSD et les disques durs font partie des composants les plus critiques pour un centre de données. Ceux-ci sont généralement hébergés ensemble dans un boîtier ou un serveur et constituent les fondements du centre de données. Dans cette architecture cloud d'entreprise traditionnelle, chaque composant, tel qu'un disque dur, est directement rattaché au reste du serveur.
À l'origine, les centres de données suivaient la règle « une application par serveur ». Puis, lorsque les capacités de stockage et de traitement des données fournies par chaque serveur n'ont plus été suffisantes pour les applications, les architectes informatiques ont commencé à regrouper plusieurs serveurs en clusters, qui pouvaient être utilisés comme pool de ressources. Les solutions propriétaires d'IBM, d'EMC, de NetApp et de l'équipe Dot Hill de Seagate ont été les premières à proposer une mutualisation des ressources serveur.
Afin de satisfaire les besoins applicatifs de plus en plus complexes, les centres de données ont évolué de la manière suivante : lorsqu'une application requiert davantage de stockage, de bande passante ou de puissance de processeur, des serveurs (ou nœuds) supplémentaires sont ajoutés au cluster. Le modèle en cluster qui regroupe plusieurs ressources constitue la base de l'infrastructure cloud d'entreprise convergée et hyperconvergée, et repose sur la technologie des hyperviseurs comme VMware ou autre.
Bien que ces clusters de nœuds aient rempli leur rôle aux débuts du cloud, ils sont enclins au surprovisionnement. Cela se produit lorsque les architectes informatiques achètent de nouveaux serveurs, qui à priori contiennent plus de ressources que nécessaire, créant ainsi des îlots de ressources inutilisées. Même si l'approche en cluster présente des avantages, notamment en termes d'espace de stockage et de puissance de calcul, les ressources non utilisées sur les serveurs sont synonymes de gaspillage. Toutefois, les architectes informatiques ont dû recourir au surprovisionnement pour répondre à la demande, car les centres de données n'avaient aucun moyen d'adapter dynamiquement des ressources ou des charges de travail spécifiques aux exigences des applications logicielles. Le surprovisionnement a tout naturellement entraîné des coûts excessifs.
Les architectes informatiques ont également été confrontés au problème du choix des composants matériels pour l'assemblage des serveurs. En effet, chaque composant de serveur ou de cluster devait être acheté auprès du même fabricant pour des raisons de compatibilité. Et il n'y avait aucune interface de programmation d'application ouverte capable de faire communiquer entre eux les composants matériels des différents fabricants. Lorsqu'un architecte souhaitait remplacer un processeur par un autre plus rapide, d'un autre fabricant par exemple, il arrivait souvent que ce n'était pas possible en raison d'une incompatibilité. Par conséquent, les composants matériels des divers fabricants ne pouvaient pas communiquer ni se coordonner entre eux.
Et les incompatibilités matérielles n'étaient pas les seuls inconvénients des infrastructures de données traditionnelles. En effet, se posaient aussi les problèmes de collecte, de stockage et d'analyse des très grandes quantités de données. L'explosion du Big Data n'a pas seulement repoussé les limites de stockage des clusters de cloud privé traditionnels, elle a également engendré un goulot d'étranglement au niveau du traitement des données. Chaque processeur est souvent trop occupé à traiter les données locales pour pouvoir partager les ressources avec d'autres applications, ce qui aboutit à un manque d'efficacité global de la répartition des ressources dans le centre de données.
Par exemple, des applications d'intelligence artificielle (IA) complexes s'appuient sur la capacité à traiter de grandes quantités de données en peu de temps. Lorsqu'une application IA utilise un centre de données en cluster, des goulots d'étranglement ont tendance à se former au niveau de la collecte et du traitement des données. De plus, lorsqu'une application a besoin de davantage de puissance de calcul, il n'est pas possible de basculer la charge de travail supplémentaire vers d'autres clusters. La latence, à savoir les délais de transmission des données entre les unités, est une autre conséquence négative.
Par exemple, vous pouvez avoir deux clusters de serveurs dans le même centre de données, l'un surchargé et l'autre sous-utilisé. L'application qui s'exécute sur le cluster surchargé peut subir des problèmes de performances et de ralentissement, et ceux-ci pourraient être facilement réglés en intégrant le cluster sous-utilisé et surprovisionné. Toutefois, le pool de ressources disponible pour cette application est strictement limité au cluster dédié à cette application. Cet exemple illustre parfaitement la raison pour laquelle les architectes informatiques ont recherché des moyens plus efficaces de composer un centre de données.
L'ère des applications propriétaires touche à sa fin. Les applications logicielles sophistiquées exigent une puissance de calcul et de stockage supérieure à celle que peuvent fournir les centres de données en cluster traditionnels. Et les architectes informatiques sont limités dans le choix des composants matériels en raison de l'absence d'API ouvertes permettant la communication entre les appareils. Pour aller de l'avant, les architectes informatiques doivent mieux comprendre l'impact des applications modernes sur l'architecture de cloud privé ainsi que la façon dont la composabilité peut aider à relever les défis des infrastructures informatiques traditionnelles.
L'impact des applications sur les centres de données de cloud privé
L'une des principales forces derrière la tendance de la composabilité concerne les exigences des applications logicielles. Les applications d'IA ou d'analyse métier doivent satisfaire des exigences matérielles de plus en plus complexes pour répondre à leurs besoins. Cela donne lieu à une compétition féroce en matière de calcul et de stockage dans les pools de ressources.
Comme nous l'avons vu, les centres de données traditionnels ont atteint leur point de rupture, et la puissance de calcul nécessaire aux applications dépasse les limites d'un modèle en cluster. Les exigences des applications évoluent constamment au fil du temps, et les changements peuvent intervenir rapidement. La nouvelle version d'une application métier peut ainsi exiger deux fois plus de puissance de calcul et de stockage que l'ancienne. Si les limites de son cluster dédié sont atteintes, il est alors nécessaire d'acquérir de nouveaux composants matériels. En réalité, les avancées logicielles ne font que souligner les limites du centre de données en cluster traditionnel.
Une infrastructure composable permet aux applications d'accéder à des pools de ressources en dehors de leur cluster dédié, libérant ainsi la puissance de calcul, ou d'autres ressources, des serveurs surprovisionnés. Chaque processeur, carte graphique ou nœud de stockage peut être adapté en fonction des besoins spécifiques de chaque application.
Les demandes de calcul supplémentaires créent également des goulots d'étranglement au sein de la matrice du centre de données traditionnel. La matrice d'un centre de données représente les connexions entre les divers nœuds et clusters. Dans l'idéal, une matrice composable qui répond aux besoins des applications modernes doit créer un pool de capacités flexibles. Cette matrice doit être configurable instantanément pour offrir un provisionnement dynamique de l'infrastructure et des ressources à mesure que les besoins de calcul d'une application augmentent. L'objectif est de fournir aux applications avancées un calcul plus rapide et en temps réel afin de permettre à ces applications de s'exécuter à des vitesses optimales.
La composabilité et la désagrégation sont essentielles pour répondre aux exigences des applications logicielles avancées. Une simple architecture en cluster traditionnelle n'est pas à la hauteur de la tâche et les informations ne peuvent pas circuler sur les réseaux commutés Ethernet suffisamment rapidement pour permettre aux applications avancées comme l'IA de fonctionner correctement. En désagrégeant les composants au sein d'un boîtier serveur et en leur offrant la possibilité de communiquer avec des protocoles d'API, les centres de données peuvent exécuter des applications complexes à moindres coûts.
Les avantages de la désagrégation du cloud privé
La désagrégation d'un centre de données de cloud privé signifie l'abandon complet du modèle de boîtier serveur traditionnel. Tous les composants ressources (processeurs, cartes graphiques, tous les niveaux de mémoire, SSD et stockage sur disque dur) peuvent être désagrégés et recomposés à la carte dans leur propre matrice. Ces ressources peuvent ensuite être utilisées en fonction des besoins d'une application, et non en fonction de la configuration des composants au sein d'un serveur physique spécifique. Tous les éléments accessibles sur un réseau commuté peuvent être désagrégés et recomposés ultérieurement.
Par exemple, le pool de ressources de stockage affecté à une application peut combiner des disques durs dans dix racks de serveurs différents, à divers emplacements d'un centre de données. Si l'application a besoin de plus de stockage qu'elle n'en utilise actuellement, un disque dur peut communiquer simplement avec un autre disque dur qui dispose d'espace et transférer facilement les données. La charge de travail de traitement peut également être transférée de manière dynamique lorsque les demandes de l'application augmentent. À l'inverse, lorsque les demandes de l'application diminuent, le stockage et le calcul peuvent être réaffectés de la manière la plus efficace possible sur le plan énergétique afin de réduire, voire d'éliminer, les coûts de surprovisionnement.
Il s'agit d'un changement radical par rapport aux JBOD confinés dans un seul rack de serveurs. Les JBOD ont évolué en pools accessibles à tout moment par les applications, permettant l'affectation plus intelligente des ressources du centre de données. Les architectes se sont alors tournés vers des systèmes de stockage externe normalisés capables de communiquer entre eux.
La désagrégation a également introduit la surveillance d'interface normalisée offrant aux architectes informatiques la possibilité de gérer la totalité d'un centre de données composable. La sélection de composants matériels en fonction des exigences, qu'il s'agisse de SSD, de disques durs, de processeurs ou d'autres composants réseau, ne représente qu'un aspect du processus global visant à désagréger le centre de données traditionnel pour créer ensuite une infrastructure composable. Les architectes ont toujours besoin des protocoles d'API ouvertes, tels que Redfish ou Swordfish, pour faciliter l'intégration et d'une interface utilisateur unique pour gérer le centre de données. Une API ouverte sert d'interface entre les composants matériels et logiciels écrits dans des langages différents afin qu'ils puissent communiquer entre eux.
Le fait de laisser les applications définir librement la composition du centre de données, et non l'inverse, ouvre la voie à un réseau SDN (Software-Defined Networking, réseau défini par logiciel) ou un stockage SDS (Software-Defined Storage, stockage défini par logiciel). La prochaine évolution du SDN et du SDS est le centre de données hypercomposable. Celui-ci pourrait placer l'architecture de cloud privé au même niveau que certains hyperscalers tels qu'Amazon Web Services (AWS) et Microsoft Azure. On entend par « hyperscaler » l'exploitant d'un important centre de données capable d'augmenter la capacité de stockage et de calcul à très grande échelle. La matrice Ethernet, c'est-à-dire la colonne vertébrale du réseau d'un centre de données, peut même être personnalisée pour fonctionner en tandem avec des disques durs et des SSD à faible latence. Cela réduit les retards lors du calcul ou de l'acheminement des données, car les applications peuvent accéder aux pools de ressources désagrégés s'exécutant sur des matrices à faible latence.
Les protocoles d'API ouvertes comme Redfish et Swordfish sont essentiels au bon fonctionnement des composants désagrégés. Seagate dispose de sa propre API REST qu'elle réserve à sa catégorie spécifique de produits dédiés aux centres de données afin de favoriser l'interopérabilité des appareils. Auparavant, l'installation et l'intégration de nouveaux appareils pouvaient durer des semaines. Les protocoles d'API permettent aux architectes de centres de données d'adopter une approche plug-and-play sur mesure pour provisionner les composants matériels. Les nouveaux appareils provenant de différents fabricants peuvent désormais être installés en un temps record.
La désagrégation du centre de données est ce qui rend la composabilité possible. Une fois que les architectes ont choisi leurs composants matériels en fonction des besoins de leurs applications logicielles, ils peuvent concevoir, exploiter et optimiser le centre de données composable de demain.
L'efficacité du centre de données composable moderne pour le cloud privé
Un centre de données composable ne permet pas seulement de connecter tous les composants désagrégés, il permet aussi d'améliorer les indicateurs clés de performances (KPI) liés à la rentabilité et aux performances des centres de données. Dans les centres de données traditionnels, le surprovisionnement est l'un des facteurs les plus importants dans les dépenses budgétaires. Lorsque les centres de données sont surprovisionnés, vous devez payer pour les serveurs et les ressources même s'ils sont inutilisés. Les architectes informatiques payent des pools de ressources sous-utilisés, ce qui entraîne une sous-exploitation des disques durs.
Les ressources sous-exploitées peuvent donner lieu à des pools orphelins, ou à des pools de ressources sans emplacement en raison de leur sous-utilisation. Il peut s'agit d'un processeur, d'une carte graphique, d'un circuit FPGA, d'une mémoire DRAM, d'un SSD, d'un disque dur ou d'une mémoire SCM. Ces blocs sont composés de manière dynamique pour construire des composants matériels adaptés à une application par le biais d'API logicielles.
Avant que les architectures de centre de données en open source ne soient composables, les clouds privés étaient généralement construits à l'aide de composants matériels provenant d'un même fabricant. Les centres de données connectés physiquement sont initialement plus coûteux, et les organisations sont souvent enfermées dans une architecture spécifique à un fabricant qui devient coûteuse avec le temps.
La tendance vers une architecture composable commence à gagner du terrain dans le cadre des architectures de cloud public. Des produits tels qu'AWS et Microsoft Azure en sont deux exemples. Une approche similaire peut être adoptée en termes de déploiement de cloud privé, permettant ainsi de réaliser des économies en n'étant pas lié à un seul fabricant et en composant des centres de données avec des appareils provenant de plusieurs fabricants.
Les responsables informatiques peuvent ainsi allouer davantage de ressources financières à des capacités de stockage plus importantes qui permettent ensuite d'extraire des informations à valeur ajoutée des données stockées.
Les organisations peuvent maintenant faire appel à une solution de stockage tierce, l'ajouter à leur centre de données et l'intégrer facilement grâce à une API en open source. Si un architecte informatique choisit un SSD d'un fabricant alors que les composants du centre de données proviennent d'un autre fabricant, il peut l'installer sans trop de difficultés. Les API garantissent que tous les composants fonctionnent de pair. Les responsables de centres de données n'ont pas besoin d'être obnubilés par la manière dont les composants communiqueront via le système de télémétrie, par exemple. Ainsi, ils seront plus libres d'utiliser des pièces provenant d'un autre fabricant, et moins stressés.
Un autre avantage clé d'une mémoire partagée ou d'une mémoire en pool est la capacité des applications à continuer à fonctionner en cas de défaillance d'un nœud sans que les machines virtuelles ou les clusters de conteneurs soient impactés. L'idée est que les autres nœuds peuvent désormais soit copier le dernier état de la mémoire de la machine virtuelle dans leur propre espace mémoire (dans le cas des architectures avec mémoire en pool), soit utiliser un processus de zéro copie par redirection de pointeur à travers la matrice à très faible latence et continuer là où le nœud défaillant s'est arrêté de manière transparente (dans le cas des architectures de mémoire partagée). Cela peut être considéré comme une évolution considérable des capacités de tolérance aux pannes des centres de données afin d'offrir une meilleure fiabilité et une plus grande disponibilité.
Une architecture composable permet également de collecter et de traiter plus rapidement les données issues de plusieurs sources et plus généralement d'utiliser plus efficacement les ressources installées. L'architecture source composable inclut généralement des capteurs physiques, des simulations de données, des informations générées par l'utilisateur et des communications par télémétrie. Les responsables des centres de données peuvent ensuite faire tourner les ressources en quelques minutes et les partager à la volée entre les différentes applications.
Une seule vue pour toutes les ressources
L'orchestration et la gestion d'un centre de données de cloud privé sont également plus faciles avec une architecture composable qui utilise un client d'orchestration conteneurisé. Tous les composants matériels peuvent être désagrégés, composés et surveillés à partir d'une interface unique. Les gestionnaires de centres de données disposent ainsi d'une image précise, en temps réel, des pools de ressources en cours d'utilisation afin de vérifier qu'il n'y a pas de surprovisionnement. Très souvent, la gestion sera réalisée à l'aide d'un seul logiciel standard. Celui-ci pourra être un logiciel propriétaire ou open source.
Le déploiement de nouvelles applications logicielles dans un environnement open source et conteneurisé est également plus flexible, notamment en raison de la souplesse avec laquelle les ressources de stockage peuvent être achetées et réparties. Par exemple, les architectes de centres de données n'ont plus besoin de surprovisionner des niveaux de stockage flash coûteux. En effet, n'importe quelle charge de travail applicative peut être instantanément déplacée vers un ensemble existant de ressources SSD en fonction des besoins, quel que soit l'endroit où elle se trouve physiquement. Cela permet d'éviter le surprovisionnement et de libérer de l'espace physique qui peut être utilisé à d'autres fins, comme l'augmentation de la capacité de stockage brute.
La nécessité de créer davantage de capacité de stockage brute est renforcée du fait de la croissance et de l'explosion des données brutes. En outre, les organisations s'efforcent d'obtenir encore plus de valeur et d'informations exploitables à partir d'un plus grand nombre de ces données afin de créer de nouvelles opportunités et d'améliorer leurs résultats. L'important est que les architectes informatiques puissent concevoir des infrastructures capables de collecter, de stocker et de transmettre de très grandes quantités de données. Un environnement matériel optimal signifie que davantage d'espace est disponible pour le stockage brut nécessaire à l'environnement Big Data actuel.
La solution est un centre de données composable qui puisse connecter n'importe quel processeur et n'importe quel pool de stockage à d'autres appareils selon les besoins. Tous les autres appareils font appel à la norme CSI, Redfish et Swordfish pour se connecter au réseau de gestion, le tout orchestré par des moteurs logiciels. Tous les autres blocs du centre de données peuvent être composés de manière dynamique pour s'adapter à une application spécifique grâce à des API logicielles.
Coût, performances et efficacité
La tendance vers une infrastructure désagrégée et composable dans les centres de données est guidée par le triangle coûts, performances et efficacité. Le temps où le processeur était le centre de l'univers connu, pour ainsi dire, et où tous les autres périphériques étaient installés dans le même boîtier est révolu. À présent, les architectes de cloud privé peuvent choisir les appareils, les composants matériels ainsi que les composants logiciels les plus appropriés à leurs utilisations et à leurs besoins spécifiques.
Le centre de données traditionnel à cluster conteneurisé a ouvert la voie à des applications plus complexes. Toutefois, les applications actuelles ont atteint un tel niveau de performances qu'une architecture plus dynamique est devenue nécessaire. Les cartes graphiques, les circuits FPGA et la mémoire composables seront à l'avenir soutenus par des interfaces à ultrafaible latence.
La composabilité signifie que la charge de travail de calcul est distribuée en temps réel, ce qui permet de partager les tâches avec les appareils sous-utilisés et d'éliminer les pools de données isolés. Résultat : une infrastructure de cloud privée parfaitement orchestrée qui aide les centres de données à traiter les charges de travail plus rapidement et à moindres coûts. Grâce à la désagrégation et à la composabilité, les architectes informatiques peuvent désormais répondre aux besoins des applications logicielles les plus exigeantes. L'infrastructure composable d'un centre de données dans son ensemble vaut bien plus que la somme de ses différentes composantes.
