Google Cloud porte ses instances X5 à 48 To pour les grandes bases SAP

Google Cloud annonce la disponibilité générale de la série X5, qui porte à 48 To la capacité mémoire maximale annoncée sur un seul nœud, contre 32 To pour X4.[1] Destinée notamment aux très grandes bases SAP HANA, cette offre repose sur des instances bare metal.[2] Pour les entreprises concernées, le choix devra associer capacité, continuité de service et coût complet.

Le plafond mémoire progresse de moitié

Les notes de version de Compute Engine du 25 septembre présentent une augmentation de 50 % du plafond mémoire par rapport à X4. Google met en avant la possibilité de faire grandir les bases critiques SAP HANA et les environnements RISE with SAP sur un seul nœud.[1]

Cette progression concerne la mémoire vive, utilisée pendant les traitements. Elle ne correspond ni à une capacité de stockage sur disque, ni à une accélération automatique de 50 % des applications. La note d’annonce ne fournit pas de résultat de performance permettant de déduire un tel gain.

Des serveurs bare metal intégrés à Compute Engine

La qualification technique compte : X5 donne accès aux ressources physiques du serveur, sans hyperviseur fourni par Google. Parler simplement de VM de 48 To masquerait donc une différence d’exploitation avec une machine virtuelle classique.[3]

La famille X5 utilise la plateforme Intel Granite Rapids et propose des configurations prédéfinies. La documentation indique jusqu’à 2 064 vCPU et une bande passante réseau pouvant atteindre 200 Gbit/s.[2] Ces plafonds décrivent des ressources disponibles ; ils ne constituent pas des débits applicatifs garantis.

Le très grand format SAP comporte une condition précise

La page de certification SAP recense des configurations X5 de 12, 16, 24, 32 et 48 To. Elle précise que le modèle de 48 To est disponible pour les charges SAP gérées par SAP dans le cadre de RISE with SAP.[4]

Cette condition doit accompagner le chiffre mis en avant. Une entreprise préparant une migration SAP ne peut pas déduire de la disponibilité générale de X5 que chaque taille est accessible dans tous les modes d’exploitation. Elle doit faire confirmer le modèle, le système d’exploitation et le cadre de support correspondant à son projet.

Une capacité supplémentaire pour les bases en mémoire

SAP HANA est une base relationnelle en mémoire, organisée en colonnes, conçue notamment pour l’analyse et le traitement des données en temps réel.[5] La montée en capacité d’un même serveur, ou scale-up, peut permettre de poursuivre la croissance d’un système sans répartir immédiatement son traitement sur plusieurs nœuds.

L’intérêt dépend toutefois de la contrainte réelle. Si une base manque de mémoire, une configuration plus grande peut constituer une option. Si les délais proviennent des requêtes, des accès au stockage ou des échanges avec d’autres applications, ajouter de la mémoire ne résout pas nécessairement le problème. Le dimensionnement doit partir des mesures de charge et de la croissance attendue.

Ce que cette évolution change dans les choix d’infrastructure

Notre lecture de cette annonce est celle d’un élargissement des options de consolidation dans le cloud. Une organisation peut envisager de conserver une base volumineuse sur un seul nœud, mais doit comparer ce scénario avec l’optimisation de l’existant et les autres architectures prises en charge par son application.

Ces tailles concernent surtout des environnements très exigeants. Pour une PME, l’enseignement n’est pas de viser systématiquement la configuration maximale : il est de demander à son intégrateur ou à son prestataire pourquoi une capacité donnée est nécessaire et quelles alternatives ont été examinées.

Les arbitrages à examiner avant une migration

Cette grille relie les besoins d’un projet aux vérifications nécessaires. Elle propose des critères de décision, sans présumer qu’une migration vers X5 soit la meilleure option.

La maintenance et le stockage imposent leurs propres choix

X5 utilise Hyperdisk, sans prise en charge de Persistent Disk ni de SSD locaux. La migration à chaud n’est pas disponible et le démarrage peut prendre jusqu’à trente minutes. L’offre est limitée à certaines régions et zones, ainsi qu’à des images système compatibles.[2]

Ces contraintes doivent entrer dans le plan de migration et les procédures d’exploitation. Une équipe qui reprend les habitudes d’une autre famille Compute Engine risque de sous-estimer les adaptations nécessaires. Le test utile consiste à vérifier le fonctionnement de l’application, mais aussi son arrêt, son redémarrage et sa restauration dans la configuration retenue.

Un nœud plus grand ne remplace pas une architecture de secours

Le guide Google consacré à la haute disponibilité SAP HANA décrit notamment la réplication du système vers une instance secondaire et les mécanismes de bascule. Les sauvegardes servent, elles, à reconstruire la base à un point dans le temps.[6]

Il faut donc distinguer trois questions : quelle quantité de données la plateforme peut-elle traiter, pendant combien de temps le service peut-il être indisponible et quelle perte de données est acceptable ? La taille mémoire répond surtout à la première. Les deux autres demandent une architecture et des essais de reprise.

La documentation renvoie vers l’interlocuteur commercial Google Cloud pour les tarifs et la commande X5.[2] Sans devis comparable incluant les ressources de secours, les licences, le stockage et l’exploitation, il serait prématuré de présenter cette capacité comme une économie.

L’architecte cloud doit justifier chaque choix de capacité

L’évolution de ces infrastructures renforce le rôle du Cloud Computing dans les décisions techniques de l’entreprise. Le professionnel doit savoir traduire les besoins d’une application en ressources adaptées, puis vérifier que ces ressources répondent aux exigences de disponibilité et de maintenance.

Cette compétence demande aussi de lire les conditions de certification, d’identifier les dépendances au fournisseur et de comparer plusieurs scénarios sur des critères communs. Un plafond mémoire impressionnant n’est utile que s’il répond à une contrainte démontrée.

La valeur du professionnel se situe ainsi dans sa capacité à expliquer un arbitrage : pourquoi retenir cette taille, comment assurer la reprise et à quel coût sur la durée ? Cette argumentation relie l’infrastructure aux priorités métier et facilite le dialogue avec les prestataires.

La capacité maximale devient un point de départ pour le dimensionnement

Avec X5, Google Cloud ouvre une option supplémentaire aux organisations dont les bases atteignent les limites d’un serveur. La décision de migration devra pourtant se jouer sur un dossier plus large que la mémoire : compatibilité, tests, reprise et budget. La bonne question est donc de savoir quelle architecture soutiendra la croissance attendue avec un niveau de service vérifiable.

L’Actu IT à 360°, décrypter la technologie pour comprendre les métiers de demain.

Découvrir CCCLX →