IBM Cloud vend le choix de région à travers les limites physiques des centres de données et du transit

Résumé

• IBM Cloud possède une empreinte opérationnelle vérifiable. Son registre d'emplacement actuel nomme neuf régions métropolitaines multizones, quatre régions multizones monocampus et 42 centres de données d'infrastructure classique, tandis que sa documentation mappe les zones VPC logiques aux installations physiques et aux points de présence réseau.
• Le choix de la région ne rend pas la capacité abstraite. IBM indique que certains profils dépendants du matériel ne sont pas disponibles dans toutes les régions, expose l'inventaire bare-metal par centre de données, documente les erreurs de capacité insuffisante et vend des réservations qui dédient de la capacité dans une zone choisie.
• La résilience reste un achat architectural plutôt qu'une propriété automatique d'un compte. Un serveur zonal unique n'est pas déplacé vers une autre zone après une défaillance de zone, Direct Link n'est pas intrinsèquement redondant, les zones monocampus peuvent partager des dépendances, et la reprise après sinistre régionale demeure en grande partie la responsabilité du client.
• La localité des données est également spécifique au service. IBM indique que le contenu client pour les services régionaux et zonaux est stocké et traité dans la région sélectionnée, mais les métadonnées du compte et les fonctions de contrôle globales peuvent être gérées ailleurs. Les sauvegardes, l'accès au support, les copies interrégionales et les procédures de sortie font donc partie de la décision de localité, et non après celle-ci.

Un nom de région est une revendication sur des machines dans des bâtiments particuliers

La géographie du cloud est souvent présentée comme un menu propre de noms de villes. La documentation publique d'IBM Cloud rend cette abstraction inhabituellement facile à décomposer. Sonregistre d'emplacementsdécrit une région comme un territoire géographique indépendant contenant une ou plusieurs zones, généralement nommé d'après une zone métropolitaine. Il répertorie actuellement des régions multizones complètes à Dallas, Washington, São Paulo, Toronto, Francfort, Londres, Madrid, Sydney et Tokyo. Il répertorie séparément des régions multizones monocampus à Chennai, Montréal, Mumbai et Osaka.

La distinction entre les deux types de régions n'est pas cosmétique. IBM indique qu'une région multizone complète utilise trois centres de données ou plus sur des sites distincts, avec une alimentation électrique, un refroidissement et une connectivité réseau indépendants, et avec au moins un mile entre les zones. Une région multizone monocampus place trois zones dans différentes parties d'un même bâtiment ou dans des bâtiments sur un même campus. Ses dépendances en matière d'alimentation, de refroidissement, de réseau et de sécurité physique peuvent se chevaucher.

IBM indique que les deux formes portent le même engagement de niveau de service, mais elle avertit également qu'une catastrophe dans un centre de données peut affecter toute une région monocampus parce que les zones sont plus étroitement liées.

Cela crée une première règle utile pour les acheteurs: l'étiquette de région identifie un marché et une zone de latence, et non un quantum uniforme d'indépendance physique. Trois zones à Francfort ne sont pas physiquement équivalentes à trois zones sur un campus à Montréal. Même dans la catégorie des régions complètes, IBM publie seulement une séparation minimale, et non la distance, le bassin versant, les services publics, les conduits ou les détails des opérateurs pour chaque paire de sites.

Un acheteur peut savoir que les zones sont conçues comme des domaines de défaillance indépendants sans connaître tous les mécanismes par lesquels ces domaines pourraient encore être corrélés.

Le registre d'IBM va plus loin en exposant la traduction entre les noms logiques et physiques. Un client VPC voit une zone telle queus-south-1, mais le compte reçoit une correspondance avec une désignation physique universelle telle queus-south-dal10-a. IBM indique que cette correspondance est établie lors de la création de la première ressource VPC dans la région et est déterminée par IBM. Dallas possède actuellement quatre emplacements universels associés à DAL10, DAL12, DAL13 et DAL14, bien que la région ordinaire visible par le compte présente trois zones numérotées. Un client peut inspecter l'affectation après la création et peut demander un changement à un responsable technique de compte dans de rares cas, mais IBM évalue ces demandes individuellement.

Cela importe lorsqu'une organisation mélange VPC, Power Virtual Server et infrastructure classique. VPC utilise la correspondance logique-physique du compte; les ressources classiques et Power peuvent être commandées en fonction de codes de centre de données spécifiques. IBM conseille explicitement de créer d'abord les ressources VPC, d'inspecter la zone universelle, puis de placer les autres ressources dans la même installation physique lorsque la colocalisation est souhaitée. Le nom de la ville seul est trop large pour cette tâche.

Le registre classique actuel nomme 42 centres de données: 19 dans les Amériques, 12 en Europe et 11 en Asie-Pacifique. Il comprend six sites à Dallas, quatre à Washington, quatre à Londres et trois dans plusieurs autres marchés. C'est une preuve solide d'un patrimoine d'hébergement mondial fonctionnel, et non d'une carte spéculative. Cela montre également pourquoi un seul chiffre pour les « régions IBM Cloud » est trompeur. Les régions VPC, les régions monocampus, les bâtiments classiques, les emplacements Power et les points de présence réseau sont des unités liées mais non interchangeables.

IBM indique qu'un centre de données classique peut contenir plusieurs pods, chacun composé de racks, de serveurs, de réseaux, de stockage et de générateurs de secours. Placer des serveurs sur plusieurs pods peut améliorer la disponibilité, mais l'entreprise prévient que les centres de données ne fournissent pas eux-mêmes une isolation par rapport aux arrangements multizones dans le même emplacement.

Un pod est un domaine de défaillance et de capacité plus petit à l'intérieur d'un bâtiment; une zone est l'unité que les clients utilisent pour séparer les ressources VPC; une région regroupe des zones; et une fonction de contrôle globale peut encore se situer au-dessus de toutes. L'achat physique ne commence qu'une fois ces couches séparées.

SoftLayer a laissé à IBM un patrimoine d'hébergement, pas un pool infiniment élastique

L'accent mis sur le physique est en partie hérité. IBM a acheté SoftLayer en 2013 et l'a combiné avec IBM SmartCloud. Ledépôt d'IBM pour ce trimestrefait état d'une contrepartie en espèces de 1,977 milliard de dollars. Undocument d'information sur l'acquisitiond'IBM décrivait SoftLayer comme un fournisseur d'infrastructure basé à Dallas servant 21 000 clients avec des serveurs dédiés, des serveurs virtuels et des clouds privés. L'attrait n'était pas seulement logiciel. C'était un système d'hébergement installé avec des clients, des installations, de l'automatisation et un réseau.

Cet héritage reste visible dans la coexistence de l'infrastructure classique et du VPC. Les clients classiques peuvent toujours sélectionner un centre de données nommé et commander des serveurs virtuels ou bare-metal en fonction de l'inventaire physique. VPC présente des ressources zonales plus standardisées et une mise en réseau définie par logiciel.

IBM recommande désormais VPC pour de nombreux déploiements modernes, mais le patrimoine classique et ses hypothèses opérationnelles restent importants pour les clients existants, les déploiements VMware, les sociétés d'hébergement et les applications construites autour des réseaux de l'ère SoftLayer.

L'économie de ce patrimoine apparaît dans les propres règles de disponibilité d'IBM. Lapolitique de déploiement des servicesdivise les offres en services de base et services axés sur le marché. Les services de base, y compris VPC, Object Storage, Kubernetes, OpenShift, PostgreSQL et la gestion des clés, sont attendus dans chaque région multizone. D'autres services sont déployés là où la demande des clients le justifie. IBM indique que les nouveaux services de base doivent atteindre toutes les régions multizones dans les 90 jours suivant leur premier déploiement régional et que les mises à jour doivent suivre dans les 30 jours, mais elle note expressément que les profils et fonctionnalités dépendants du matériel ne sont pas disponibles dans toutes les régions.

C'est la logique commerciale derrière la carte. Ouvrir une ville ne signifie pas installer chaque processeur, accélérateur, niveau de stockage et appliance à une profondeur illimitée. Un fournisseur doit décider combien de racks alimenter, quelles générations de serveurs stocker, quelle marge de réseau et de stockage réserver, et si la demande pour un service spécialisé justifiera un déploiement et un support locaux. Un service peut être présent dans une région alors qu'un profil particulier reste absent ou rare.

Dallas offre un exemple concret de capacité suivant la demande. IBM a annoncéDAL14 comme zone VPC supplémentaire, le décrivant comme le dixième centre de données d'IBM à Dallas et la quatrième installation de zone de disponibilité dans cette zone. L'annonce indique que l'expansion ajoute de la capacité pour les charges de travail VPC et complète deux points de présence réseau et d'autres infrastructures sur le marché. Le mot important est capacité. Une nouvelle zone est une décision de capital et d'approvisionnement impliquant un bâtiment, une alimentation électrique, un refroidissement, de la fibre, des serveurs et une couverture opérationnelle, pas une nouvelle étiquette ajoutée à une console.

Les chiffres environnementaux à l'échelle de l'entreprise d'IBM donnent une idée générale de la facture physique, bien qu'ils ne doivent pas être confondus avec des mesures propres à IBM Cloud. IBM rapporte que ses centres de données ont eu une efficacité énergétique moyenne pondérée de 1,39 en 2025, que 85 % de leur électricité provenait de sources renouvelables et que 44 centres de données étaient alimentés à 100 % par de l'électricité renouvelable. La mêmedivulgation énergétiqueindique qu'une partie de l'électricité renouvelable provient de propriétaires ainsi que de fournisseurs d'électricité directs. Elle ne publie pas la consommation Cloud par installation, les mégawatts contractés, les contraintes du réseau ou la durée du carburant de secours. L'agrégat établit un effort opérationnel matériel; il ne peut pas dire à un client de Dallas quel service public ou quelle dépendance de propriétaire se trouve sous une zone particulière.

Le choix de la région porte donc deux prix. Le prix visible est le tarif pour le calcul, le stockage et le trafic. Le prix moins visible est la décision du fournisseur d'installer une capacité suffisante et appropriée à cet emplacement et la décision du client de la réserver ou de la dupliquer. Un déploiement local à faible latence, du matériel spécialisé et un inventaire de rechange profond sont en concurrence pour les mêmes racks et la même alimentation. La carte montre où IBM peut vendre; l'écran de commande révèle ce qu'elle peut livrer maintenant.

La capacité installée ne devient utilisable que lorsque le profil demandé est libre

La documentation bare-metal d'IBM est franche sur l'inventaire. Songuide du serveurindique que les clients peuvent voir quels serveurs à provisionnement rapide sont disponibles dans chaque centre de données. Si un serveur sélectionné n'est pas disponible, l'interface de commande identifie d'autres emplacements où cette configuration existe. Les systèmes à provisionnement rapide deviennent généralement configurables en 30 à 40 minutes, tandis que le provisionnement bare-metal plus large peut prendre jusqu'à quatre heures. Des tests matériels étendus optionnels peuvent ajouter deux heures, et IBM indique que les erreurs de test critiques entraînent le remplacement des composants avant la livraison.

C'est la capacité installée dans sa forme la plus littérale. Un châssis doit être présent, équipé du bon processeur, de la mémoire et des disques, connecté à des ports réseau fonctionnels, réussir les tests de résistance et rester non engagé. Un centre de données peut être opérationnel alors qu'une machine souhaitée est indisponible. Déménager vers un autre bâtiment peut résoudre le problème de stock mais modifier la latence, la séparation des pannes, la résidence ou la conception de l'interconnexion.

Les serveurs virtuels classiques exposent la même contrainte à un niveau mutualisé. Lapage de dépannage de la capacitéd'IBM documente une erreur de « capacité insuffisante » lorsqu'un routeur ou un centre de données ne dispose pas des ressources nécessaires pour répondre à une demande. Les réponses suggérées incluent l'attente, la sélection d'un autre routeur ou bâtiment, la commande d'instances moins nombreuses ou plus petites, la répartition de la demande sur plusieurs centres de données ou le changement du type de stockage. La page limite également le provisionnement de GPU classiques à un sous-ensemble nommé d'installations. L'élasticité est réelle, mais elle est limitée par des hôtes libres, des connexions réseau, du stockage et un catalogue de produits lié à des sites physiques.

La capacité VPC peut être rendue plus prévisible grâce à desréservations. IBM propose des engagements d'un ou trois ans pour une quantité et un profil dans une zone sélectionnée. Elle annonce des remises allant jusqu'à 60 % pour les serveurs virtuels et 55 % pour le bare metal, tout en dédiant la capacité réservée pour la durée. Une réservation bare-metal maintient la capacité même avant qu'un serveur ne soit provisionné. La création de réservation peut encore prendre du temps et peut échouer avant que la capacité ne soit dédiée.

L'arrangement expose clairement le compromis. L'achat à la demande donne au client de la flexibilité mais laisse la disponibilité immédiate soumise au pool partagé. Une réservation réduit cette incertitude en payant pour une demande engagée sur un profil et une zone spécifiques. Elle ne réserve pas toutes les dépendances autour du serveur. La bande passante réseau, le stockage, les logiciels, les images, les quotas, les équilibreurs de charge et la capacité de récupération ont leurs propres conditions. Une zone réservée ne devient pas non plus un site de reprise après sinistre simplement parce que le calcul y est garanti.

La capacité utilisable dépend également de la génération et du cycle de vie. IBM indique que certaines installations matures contiennent des serveurs 1U à socket unique sans double alimentation électrique et conseille aux clients qui ont besoin de redondance d'alimentation d'envisager des châssis 2U. Sesconseils de résilienceactuels indiquent que les centres de données disposent de plusieurs alimentations électriques, de liaisons fibre, de générateurs et de batteries, tout en identifiant cette exception au niveau du serveur. C'est un avertissement utile contre le traitement de la redondance du bâtiment comme une propriété automatiquement héritée par chaque machine.

La distinction s'étend à la disponibilité logicielle. Toutes les régions multizones portent un ensemble de base, mais les services axés sur le marché peuvent être absents, et le plan de données local d'un service peut dépendre d'Object Storage, de la gestion des clés, des bases de données, de l'identité ou des fonctions réseau. Une région peut avoir une capacité de calcul général abondante et pourtant manquer du matériel exact ou du service géré requis par une application.

Avant de déclarer un emplacement viable, un opérateur doit tester l'ensemble de la nomenclature, y compris la capacité de réserve pour un jour de basculement où de nombreux clients peuvent essayer de provisionner en même temps.

IBM exploite la couche cloud, tandis que les services publics, les propriétaires et les opérateurs restent en dessous

Ladéclaration de responsabilité partagéed'IBM place les installations, les réseaux physiques, le stockage, les hyperviseurs et les serveurs physiques sous la responsabilité opérationnelle d'IBM pour les services d'infrastructure publique. Les clients restent responsables de leurs données, applications et systèmes d'exploitation, tandis que les serveurs virtuels, le stockage et les réseaux sont des responsabilités partagées. Pour la reprise après sinistre, IBM fournit les services sous-jacents, mais le client doit créer des ressources dans une deuxième région et gérer la récupération des applications et des données.

Cette déclaration de responsabilité est plus forte qu'une promesse de louer de l'espace de rack. Elle indique qu'IBM est responsable envers le client de la couche physique sous-jacente au service public. Elle n'établit pas qu'IBM possède chaque bâtiment, connexion de service public ou route de fibre métropolitaine. La liste d'emplacements publics identifie les régions de Chennai et Mumbai avec Airtel dans leurs noms, et les rapports énergétiques d'IBM font référence à l'électricité renouvelable obtenue par l'intermédiaire des propriétaires.

IBM décrit également des arrangements Direct Link qui nécessitent des fournisseurs de connectivité externes et des interconnexions financées par le client. Le patrimoine a donc plusieurs frontières d'opérateur même lorsqu'IBM reste l'opérateur cloud contractuel.

Au niveau des installations, IBM annonce une alimentation et un refroidissement N+1 et une sécurité physique 24 heures sur 24 sur sapage mondiale des centres de données. Son document de résilience plus approfondi indique que les sites utilisent plusieurs alimentations, des générateurs dédiés et des batteries. Ces déclarations soutiennent l'existence de systèmes de secours techniques. Elles ne divulguent pas les sous-stations de services publics, les contrats de carburant, l'autonomie sous charge, les résultats des tests des générateurs, les dépendances en eau, les fabricants de tableaux de commutation ou si deux alimentations nominales partagent un élément de réseau en amont.

L'archive publique des incidents montre pourquoi ces détails manquants importent. IBM conserve les rapports d'analyse des événements majeurs pendant cinq ans. Sonindex des incidentscomprend une panne du réseau électrique affectant FRA05 en juillet 2023, un incendie affectant le centre de données Seoul 01 en octobre 2022, une panne de courant à Washington en avril 2021, une panne de courant de l'infrastructure de refroidissement à SAO01 en décembre 2020, et des perturbations du réseau liées à des installations et pods nommés. Les titres seuls n'établissent pas la faiblesse actuelle ni ne révèlent toutes les mesures correctives. Ils démontrent que les pannes de réseau électrique, d'incendie, de refroidissement, de réseau de bâtiment et de pod sont des catégories réelles dans ce patrimoine, pas des hypothèses lointaines.

Un achat résilient doit donc être testé à plusieurs frontières. Une charge de travail occupe-t-elle une machine, plusieurs machines dans un pod, plusieurs pods dans un bâtiment ou des zones distinctes? Les zones sélectionnées sont-elles sur des sites distincts ou un seul campus? Les deux sites dépendent-ils du même corridor d'opérateur métropolitain? La deuxième copie des données se trouve-t-elle dans une autre zone, une autre région, ou seulement sur un périphérique redondant dans la même salle? La région de récupération dispose-t-elle d'une capacité de calcul et de services gérés compatible suffisante?

Chaque réponse change ce que le client survit réellement.

Les limites de la divulgation publique doivent également rester visibles. IBM ne fournit pas de registre de propriété site par site, de diagramme de service public, de tableau d'autonomie des générateurs, d'inventaire de racks ou de carte des conduits de fibre métropolitaine. Sa conception de zone et son historique d'incidents sont des preuves substantielles, mais elles ne permettent pas à un tiers de vérifier la diversité physique jusqu'à chaque bail, chaque alimentation et chaque conduit.

Les grands clients réglementés peuvent être en mesure d'obtenir des rapports de dépendance sous confidentialité; IBM indique que de tels rapports peuvent être demandés par le biais du support de conformité. Les acheteurs publics ne doivent pas supposer silencieusement que le même détail existe dans les pages de produits ordinaires.

Le backbone est étendu, mais l'entrée privée du client commence comme un seul chemin

Le réseau est l'un des systèmes physiques les mieux documentés d'IBM Cloud. Unguide d'infrastructure physiquedécrit des réseaux publics et privés séparés, des commutateurs et routeurs clients appariés à l'intérieur des centres de données, et de multiples connexions d'opérateurs dans les centres de données et les points de présence réseau. Il indique que le trafic entre les installations utilise plusieurs connexions backbone de 10 ou 40 Gbps. Les hôtes bare-metal individuels orientés VMware peuvent recevoir des connexions redondantes de 10 ou 25 Gbps dans des commutateurs top-of-rack distincts pour les réseaux publics et privés.

IBM indique également que le trafic entre ses centres de données reste dans son backbone et son système autonome plutôt que de traverser d'autres réseaux. Ladescription de la connectivité privéeprésente ce backbone comme un système mondial reliant les ressources à l'intérieur des zones, entre les zones et entre les régions. À la périphérie publique, lapolitique de peeringd'IBM exige que les pairs opérationnels tiennent à jour les enregistrements de routage et un contact réseau 24 heures sur 24.

Il existe une corroboration indépendante, avec des limites. L'enregistrement public de PeeringDB pourAS36351identifie SoftLayer Technologies, une société d'IBM, également connue sous le nom d'IBM Cloud. En juillet 2026, il a signalé 1 à 5 Tbps de trafic, environ 1 800 préfixes IPv4, 450 préfixes IPv6 et des connexions à des points d'échange sur plusieurs continents. PeeringDB est maintenu par les opérateurs plutôt que d'être une déclaration de capacité auditée. Il soutient l'existence et la large portée du réseau; il ne peut pas prouver le trafic réel, les routes privées du backbone, la marge de congestion ou la diversité de la fibre entre deux installations IBM quelconques.

La propre revendication de backbone d'IBM est ambitieuse: sa page de résilience indique que des fournisseurs de télécommunications diversifiés sont utilisés dans la mesure du possible, que des fournisseurs de fibre noire connectent les sites périphériques aux installations de calcul régionales, et que les sites périphériques ont des liaisons redondantes vers d'autres régions. « Dans la mesure du possible » est un qualificatif important. La diversité des routes dépend de la structure du marché local, des entrées des bâtiments et des chemins physiques en amont disponibles.

Deux contrats peuvent toujours partager un conduit, un pont, un bâtiment d'échange ou un câble longue distance.

L'entrée du client sur ce réseau a une conception distincte.Direct Linkfournit une connexion privée de couche 3 d'un réseau extérieur vers le backbone privé d'IBM, avec des vitesses allant jusqu'à 10 Gbps. Le service est utile pour une latence prévisible, des applications hybrides et un transfert en masse, mais IBM déclare que la redondance n'est pas incluse automatiquement. Un client a besoin de deux connexions sur des routeurs d'interconnexion diversifiés et doit configurer le routage entre eux.

Lesprérequis de Direct Linksont encore plus clairs. IBM appelle chaque connexion un chemin non protégé. Le client paie le fournisseur et les coûts d'interconnexion nécessaires pour atteindre le point de présence d'IBM, et doit choisir entre deux routeurs dans un même emplacement ou des emplacements géographiquement séparés. IBM n'hébergera pas l'équipement du client dans les points de présence réseau ordinaires. Le client ou son opérateur possède la route de ses locaux ou de son espace de colocation jusqu'à la démarcation IBM.

Cela signifie que deux numéros de commande ne sont pas une preuve suffisante de diversité physique. Lesconseils Direct Linkd'IBM exigent des routeurs d'interconnexion distincts et une politique BGP contrôlée par le client. Elle avertit que les chemins à coût égal peuvent aboutir sur le même routeur, préservant un point de défaillance unique. Pour une protection plus forte, l'acheteur doit vérifier l'opérateur, l'entrée du bâtiment, le routeur d'interconnexion, le point de présence et, si nécessaire, la diversité métropolitaine.

Le backbone peut également devenir une dépendance pour la localité et la récupération. Le routage local limite un Direct Link au marché associé; le routage global ouvre l'accès à d'autres régions IBM. Cela peut simplifier une conception de deuxième région, mais cela place plus de trafic de récupération sur des chemins longue distance et oblige le client à comprendre quelles routes et quels contrôles deviennent globaux. Un circuit privé n'est pas équivalent à un site de récupération physiquement indépendant, et une deuxième région n'est pas utile si les deux liaisons du client tombent en panne dans la même tranchée.

Le multizone ne déplace pas un serveur zonal lorsque sa zone disparaît

Lesconseils de haute disponibilité VPCd'IBM tracent une ligne cruciale entre ce que la plateforme protège et ce que le client doit construire. Le plan de contrôle VPC est distribué à travers les zones et séparé du plan de données. Les ressources existantes peuvent continuer à fonctionner lors de certaines pannes du plan de contrôle même lorsque les clients ne peuvent pas créer ou modifier l'infrastructure. La plupart des ressources du plan de données, cependant, sont zonales. Les sous-réseaux, les passerelles publiques, les points de terminaison virtuels et les serveurs virtuels vivent dans des domaines de défaillance particuliers.

Si une zone complète tombe en panne, IBM indique que les serveurs virtuels de cette zone deviennent indisponibles et ne sont pas déplacés vers une zone saine. Les ressources des autres zones continuent, et les services régionaux peuvent rester disponibles, mais les applications client survivent uniquement si elles étaient déjà distribuées et capables de basculer. Une région multizone est donc une opportunité d'acheter de la séparation. Ce n'est pas une copie automatique à trois voies de tout ce qui est provisionné dans une zone.

La défaillance de l'hôte est plus étroite. Sous la politique de récupération VPC par défaut, IBM peut détecter un hôte défaillant, déplacer un serveur virtuel affecté vers un matériel disponible dans la même zone et le redémarrer. Les données éphémères ne sont pas restaurées, et les écritures non sauvegardées peuvent être manquantes. Cette protection suppose également que du matériel approprié reste disponible dans cette zone. Elle récupère une machine d'une panne d'hôte; elle ne récupère pas l'application d'une panne de zone ou de région.

Le stockage suit ses propres limites. Les volumes en bloc utilisent du matériel redondant, mais IBM avertit qu'une catastrophe zonale ou plusieurs pannes matérielles peuvent toujours rendre un volume indisponible. Les instantanés sont conservés dans Object Storage régional et peuvent créer un volume dans une autre zone. Les copies d'instantanés interrégionales peuvent prendre en charge une récupération plus large, mais la restauration n'est pas instantanée.

IBM indique qu'une copie complète d'un volume de 3 To vers une autre région peut prendre jusqu'à 12,5 heures, et la restauration normale peut fonctionner avec des performances dégradées pendant que les données sont copiées dans le nouveau volume.

Le bare metal a moins de protections automatiques. IBM indique que les disques locaux sur les serveurs bare-metal VPC ne prennent pas en charge son mécanisme d'instantané, laissant la sauvegarde et la restauration au client. La documentation bare-metal classique indique de même qu'IBM n'effectue pas de sauvegardes des périphériques des clients; un utilisateur du compte doit lancer des sauvegardes planifiées ou ponctuelles. Une machine dédiée supprime le partage de voisin bruyant au niveau du processeur, mais elle rend le remplacement du matériel, le stockage local et la préparation à la récupération plus visibles.

L'archive publique des incidents contient également des pannes qui ont traversé une simple frontière physique. Elle répertorie des pannes d'accès et de gestion des services cloud dans plusieurs régions en juin 2025, des problèmes de disponibilité pour les clients dans toutes les régions en juin 2022, une panne de console en octobre 2023 et un événement DNS privé VPC en juin 2021. Ces rapports ne signifient pas que chaque charge de travail en cours d'exécution a échoué. Ils montrent que les dépendances de gestion, de nommage et de services partagés peuvent avoir un rayon d'impact différent de celui d'un rack ou d'une zone.

Le document général de résilience d'IBM reconnaît la structure. Les services globaux gèrent les identités, les comptes, la facturation, les catalogues et les fonctions de support sur l'ensemble du patrimoine. Certaines fonctions de contrôle des services, y compris la gestion de l'infrastructure classique, la gestion des adresses IP, le DNS, Transit Gateway, Direct Link et le provisionnement d'Object Storage, ont des composants globaux. IBM les conçoit pour un fonctionnement redondant, mais un événement affectant leurs régions d'hébergement peut altérer les opérations de gestion ailleurs.

Les plans de données existants peuvent continuer à servir le trafic tandis que les nouveaux serveurs, les changements de route ou les actions de récupération sont bloqués.

C'est le test difficile d'une architecture de récupération: non pas si l'application principale continue de servir des requêtes ordinaires, mais si les administrateurs peuvent s'authentifier, allouer des adresses, provisionner de la capacité, changer le DNS, attacher du stockage et ouvrir un dossier de support pendant le même événement. Un deuxième site chaud réduit la dépendance au provisionnement d'urgence. Un plan froid qui suppose que chaque fonction de contrôle et chaque profil seront disponibles après un incident large comporte plus de risque d'exécution.

Le support, la facturation et les décisions de cycle de vie sont aussi des dépendances d'infrastructure

Lorsque le matériel, le routage ou les fonctions de contrôle échouent, la récupération dépend de personnes ayant accès aux systèmes concernés. IBM propose plusieurs niveaux de support, et leurs différences sont opérationnellement significatives. Sontableau de gravité du supportdéfinit la gravité 1 comme un service en panne ou une fonction critique pour l'entreprise inopérante. Le support Premium a un objectif de réponse initiale de moins de 15 minutes; Advanced vise une heure; Basic n'a pas d'objectif de réponse initiale. IBM souligne qu'il s'agit d'objectifs plutôt que de garanties et que le client doit mettre du personnel technique à disposition pour un travail continu sur un cas de gravité 1.

Les cas de facturation, de facture et de vente sont exclus de ces objectifs de réponse. Ce détail importe car la facturation peut affecter la couche de service. Lapage de dépannage Direct Linkd'IBM indique qu'une connexion privée peut passer à l'état suspendu en raison d'un paiement manqué et oriente le client vers le support. Sa documentation VPC indique que les serveurs virtuels et les systèmes bare-metal suspendus sont éteints et ne peuvent pas être utilisés ou modifiés lorsqu'une ressource est suspendue pour violation des conditions. Ce sont des situations différentes, mais les deux montrent que l'administration du compte peut atteindre la disponibilité du réseau et du calcul.

IBM publie des objectifs de niveau de service pour les configurations à haute disponibilité, y compris 99,999 % pour VPC et 99,9999 % pour le réseau cloud. Lapage SLOindique explicitement qu'un objectif n'est pas une garantie et ne déclenche pas de crédits. L'explication de l'accord de niveau de servicedistincte décrit des crédits sur les frais lorsqu'un service couvert manque son objectif de disponibilité contractuel. Ni un objectif ni un crédit ne répare les revenus perdus ni ne reconstruit les données. Les acheteurs doivent inspecter la description de service applicable, la topologie requise, les exclusions et la procédure de réclamation plutôt que de convertir un pourcentage en temps de fonctionnement supposé de l'application.

Les décisions de cycle de vie peuvent être tout aussi physiques que les pannes. IBM indique que certains centres de données plus anciens ne peuvent pas être mis à niveau et doivent fermer. Sonavis de modernisationactuel prévoit que CHE01 à Chennai cessera ses activités le 10 juin 2027. Le nouveau provisionnement devient progressivement restreint, les services de plateforme ont une date limite de migration plus précoce, et IBM avertit qu'aucune prolongation n'est disponible. L'entreprise oriente les clients vers les nouvelles régions multizones de Chennai et Mumbai.

Ce n'est pas une preuve qu'IBM Cloud se retire de l'Inde. C'est une preuve qu'un code de centre de données n'est pas permanent. La densité de puissance du bâtiment, la conception du réseau, l'âge de l'équipement, les conditions du propriétaire et la faisabilité de la mise à niveau changent finalement la réponse économique. IBM peut ajouter DAL14 dans un marché en croissance tout en fermant un site de Chennai qu'elle juge inadapté à la modernisation. Les clients supportent le travail d'application nécessaire pour suivre ces décisions patrimoniales.

La relation opérationnelle est donc plus large que le temps de fonctionnement. Elle comprend le droit au support, des contacts de facturation précis, la continuité des bons de commande et des cartes, le renouvellement des engagements réservés, la connaissance des avis de fin de service et un délai suffisant pour reconstruire ailleurs. Un administrateur cloud qui ne peut pas voir les factures, approuver la capacité ou recevoir les avis de service peut devenir un point de défaillance unique même lorsque chaque serveur est sain.

La récupération est un exercice de capacité et de déplacement de données, pas une case à cocher

IBM recommande de distribuer les applications évolutives à travers les zones derrière des équilibreurs de charge et d'utiliser une autre région pour la reprise après sinistre. Elle fournit des copies d'instantanés interrégionales, la réplication de fichiers, Object Storage, des définitions d'infrastructure et des API. Mais ses conseils VPC attribuent l'action de récupération régionale au client: créer des ressources dans un emplacement disponible, restaurer les données et rediriger l'application.

Elle conseille aux clients de conserver la configuration en dehors de la région défaillante, de pratiquer les étapes et d'envisager le pré-provisionnement des ressources pour garantir la disponibilité.

Le pré-provisionnement mérite d'être souligné. Un incident régional peut créer une demande corrélée pour les mêmes profils de serveur dans le marché de récupération. Un plan non testé peut découvrir que les quotas sont trop bas, qu'un profil est indisponible, qu'un service clé est absent, qu'un Direct Link n'atteint que le marché local, ou qu'une copie d'instantané est encore en cours de déplacement. Payer pour une capacité chaude semble inefficace en fonctionnement normal car sa valeur est la capacité de ne pas être en concurrence pour le stock pendant une situation anormale.

Object Storage illustre comment un seul nom de produit peut contenir une résilience physique différente. IBM indique que les données sont chiffrées, codées par effacement et dispersées sur trois emplacements, mais la distance entre ces emplacements dépend de la classe choisie. Sesconseils sur les bucketsdistinguent le stockage interrégional réparti sur des zones métropolitaines, le stockage régional réparti sur une seule zone métropolitaine et le stockage à centre de données unique réparti sur des périphériques sur un seul site. Le client choisit l'emplacement et la résilience lors de la création du bucket.

Le bucket ne peut pas simplement être retagé dans un autre endroit. IBM indique que changer d'emplacement nécessite de créer un nouveau bucket et de déplacer les données. Songuide de copieutilise l'utilitaire open source compatible S3rclone, mais avertit que les paramètres du bucket et les métadonnées des objets ne sont pas tous copiés automatiquement. Le chiffrement, la rétention, le comportement d'archive, la politique d'accès et d'autres fonctionnalités doivent être recréés et vérifiés. Les points de terminaison privés peuvent éviter certains frais de sortie réseau lorsque le transfert s'exécute sur l'infrastructure IBM.

Le stockage en bloc est également limité. Un instantané interrégional est une copie indépendante une fois stable, mais le premier transfert est complet, les copies plus volumineuses prennent plus de temps, et des frais s'appliquent pour le transfert et le stockage de destination. Ladocumentation sur les instantanésindique qu'une seule copie d'un instantané particulier peut exister dans chaque région. Un groupe de cohérence ne peut pas être copié en tant que groupe, de sorte que la cohérence d'écriture et l'ordre de récupération d'une application multi-volumes nécessitent une attention séparée.

Le passage du classique au VPC ajoute un travail architectural. Leguide de migrationd'IBM décrit la reconstruction d'une infrastructure équivalente dans VPC, le remappage des VLANs vers des sous-réseaux spécifiques à la zone, la recréation de la sécurité, l'attachement de nouveaux stockages, le déplacement des données et la mise à jour du DNS. Un changement de profil nécessite l'arrêt et le démarrage d'un serveur VPC. Il s'agit d'une reconstruction contrôlée, pas d'un réétiquetage en direct de l'ancienne machine.

Pour les données elles-mêmes, IBM estime que la copie de 1 000 Go avecrsyncpeut prendre de 2,5 heures à plus de 12 heures, et des millions de petits fichiers peuvent prendre des jours. Sesconseils de migration de données classiquesattribuent la plage au nombre de fichiers, aux performances du disque, à la capacité du réseau et à l'utilisation. Pendant le basculement final, une application peut avoir besoin d'un gel des écritures, d'une synchronisation incrémentielle et d'une décision de retour en arrière. Plus l'état est grand, plus la migration devient un projet de bande passante et de continuité d'activité.

Quitter IBM Cloud varie également selon le service. Object Storage fournit une surface d'exportation compatible S3 et documente laportabilité des données, mais IBM attribue aux clients la responsabilité de l'infrastructure alternative, des changements d'application, de la conversion de configuration et de l'exécution du transfert. Les systèmes d'exploitation bare-metal et les piles d'applications ouvertes peuvent être portables en principe tout en dépendant toujours des adresses IP, des licences d'appliance, des hypothèses réseau ou des services spécifiques à IBM.

Les conditions actuelles d'IBM ajoutent des allégements spécifiques à la juridiction. Sapage des conditions du Cloudindique que les clients de l'UE qui prévoient de déplacer des données peuvent bénéficier de frais de sortie réduits en vertu de la loi sur les données de l'UE, tandis que les clients en France peuvent demander une exonération des frais de sortie en vertu de la loi française SREN. Ces droits peuvent réduire un coût de sortie; ils ne réduisent pas le volume de données, le couplage applicatif, le temps de validation ou le besoin d'une plateforme cible.

Le test pratique de portabilité est donc une restauration réelle en dehors du compte principal et, pour les systèmes critiques, en dehors du fournisseur. L'organisation peut-elle recréer l'identité, les clés, le DNS, la politique réseau, les images machine, les bases de données et la surveillance à partir du matériel qu'elle contrôle? Combien de temps prend le plus grand transfert avec état? Quelles fonctionnalités disparaissent à la destination? Un téléchargement de fichier réussi prouve la possession des octets. Il ne prouve pas la récupération du service.

Des données locales ne rendent pas toutes les dépendances opérationnelles locales

Lesconseils de résidence des donnéesd'IBM indiquent que le contenu client fourni aux services régionaux et zonaux est stocké et traité localement dans la région sélectionnée. Elle indique également que les sauvegardes chiffrées peuvent rester dans cet emplacement. Il s'agit d'un engagement significatif pour les organisations qui choisissent un pays ou une zone métropolitaine pour des données réglementées ou sensibles à la latence.

La même page distingue le contenu client des métadonnées du compte. Les contacts professionnels, les informations d'utilisation et d'autres métadonnées client peuvent être stockés et traités là où les plans de contrôle régionaux ou mondiaux fonctionnent. La documentation sur la résilience mondiale place la gestion des comptes, l'identité, la facturation, les catalogues et les fonctions de support au-dessus des régions individuelles. Une sélection de région répond donc à l'endroit où le contenu d'un service s'exécute uniquement dans la mesure définie pour ce service.

Cela ne signifie pas que chaque journal, échange d'informations d'identification, dossier de support ou action administrative reste à l'intérieur de la même frontière.

L'accès au support est une autre couche. IBM permet à un propriétaire de compte d'activer leservice pris en charge par l'UE, qui achemine les tickets vers les équipes de support européennes et limite la prestation de services à cette région dans le cas ordinaire. IBM indique toujours que des équipes en dehors de l'UE peuvent être contactées lorsque l'équipe européenne ne peut pas résoudre un cas, sous réserve d'un examen par l'UE, d'un accès limité dans le temps et de contrôles de confidentialité. Le paramètre améliore la localité opérationnelle; ce n'est pas une affirmation absolue qu'aucune expertise en dehors de l'Europe ne peut jamais participer.

La résilience peut tirer dans la direction opposée d'une localité stricte. Un bucket Object Storage régional répartit les données dans une zone métropolitaine. Une classe interrégionale ou un instantané distant augmente la séparation géographique mais place les données dans des emplacements supplémentaires. Copier une charge de travail de Francfort à Londres franchit la frontière de l'UE; la copier à Madrid peut rester à l'intérieur de l'UE mais introduit une deuxième juridiction nationale et des chemins réseau différents.

Une entreprise doit choisir une géographie de récupération qui satisfait à la fois la séparation des dangers et les règles juridiques.

Les régions monocampus accentuent le problème. Un déploiement à Osaka ou Montréal peut satisfaire à la résidence nationale et offrir trois zones, mais IBM avertit que les dépendances du campus peuvent se chevaucher et qu'une catastrophe de centre de données peut affecter la région. Une deuxième région multizone peut améliorer la tolérance aux sinistres, mais la destination disponible, le catalogue de services et le traitement juridique doivent être vérifiés. La résidence est une condition limite de la résilience, pas un substitut à celle-ci.

La frontière de l'opérateur physique compte également. Un fournisseur de cloud peut s'engager à un traitement local tout en utilisant le bâtiment d'un propriétaire, un service public local, des fournisseurs de fibre extérieurs et un support d'entreprise mondial. La souveraineté des données implique l'autorité juridique et le contrôle opérationnel en plus de l'emplacement de stockage. IBM explique elle-même la distinction sur sapage de souveraineté des données: la résidence concerne l'endroit où les données sont physiquement détenues, tandis que la souveraineté concerne les lois qui s'appliquent. Les clients doivent lire les conditions spécifiques au service et obtenir des conseils appropriés pour leurs obligations plutôt que de déduire la souveraineté d'un nom de ville.

Un dossier de localité efficace doit identifier la région physique, la portée du service, l'emplacement de la sauvegarde, les exceptions du plan de contrôle, le paramètre de support, l'emplacement des clés de chiffrement, les règles d'accès du personnel et la destination de récupération. Il doit également être revu lorsqu'IBM modifie la disponibilité régionale d'un service ou ferme un centre de données. La géographie n'est pas un champ sélectionné une fois à l'achat; c'est une propriété continue de l'architecture et du contrat.

Ce qu'IBM Cloud prouve, et ce qu'un acheteur sérieux devrait encore vérifier

Les preuves opérationnelles d'IBM Cloud sont solides. L'entreprise publie les codes d'installation actuels, les correspondances VPC-bâtiment, les points de présence réseau, la conception du réseau physique, le comportement de l'inventaire, les erreurs de capacité, les réservations, les limites de résilience, les migrations, les dates de fermeture et les rapports d'incidents majeurs. Son enregistrement PeeringDB et son système autonome de longue date soutiennent indépendamment une empreinte Internet active. C'est bien au-delà d'un site Web mince ou d'une collection d'annonces non testées.

Des preuves solides ne rendent pas chaque affirmation complète. Les pages publiques d'IBM n'identifient pas le propriétaire de l'installation, la topologie des services publics, la durée du carburant, les mégawatts installés, l'occupation des racks, l'inventaire libre, les conduits de fibre métropolitaine ou les contrats d'opérateurs pour chaque zone. Elles ne publient pas une marge de capacité actuelle pour les événements de récupération. Même la distance physique entre les zones de région complète n'est donnée qu'à titre de minimum. L'architecture large est visible; le risque de concentration site par site ne l'est pas.

Pour un déploiement en production, cinq confirmations amélioreraient matériellement l'achat. Premièrement, cartographier chaque zone logique du compte à son emplacement physique universel et distinguer les régions multizones complètes des régions monocampus. Deuxièmement, confirmer que le calcul, les accélérateurs, le stockage, les services gérés et les quotas requis sont disponibles dans les emplacements principal et de récupération, avec des réservations là où la pénurie serait inacceptable.

Troisièmement, documenter la diversité de l'opérateur, du routeur, du point de présence et de la route physique de Direct Link plutôt que de compter les circuits.

Quatrièmement, mesurer la récupération. Copier des données réalistes, les restaurer, provisionner une capacité de remplacement, faire tourner les clés, mettre à jour le DNS et enregistrer le résultat dans le cadre du plan de support réellement acheté. Inclure un scénario dans lequel la console ou une fonction de contrôle globale est indisponible alors que les charges de travail existantes continuent.

Cinquièmement, documenter le chemin de sortie, y compris la configuration qui doit être recréée, les adresses qui changent, le débit de transfert, le traitement de sortie et la période de préavis contractuelle pour la fermeture ou le retrait du service.

Ces tests identifient qui est affecté par chaque défaillance. Une panne d'hôte unique peut interrompre un serveur virtuel jusqu'au redémarrage. Un événement de zone affecte toutes les ressources non répliquées à cet endroit. Un événement de campus peut menacer les trois zones d'une région monocampus. Une coupure d'opérateur métropolitain peut isoler les locaux du client même si le cloud d'IBM reste sain. Un incident d'identité ou de gestion mondial peut bloquer les administrateurs dans toutes les régions. Une suspension de facturation peut désactiver une connexion privée.

Une fermeture peut forcer chaque client restant dans un bâtiment à migrer selon un calendrier fixe.

La valeur d'IBM Cloud n'est pas que ces dépendances disparaissent. C'est qu'une grande partie d'entre elles est exposée en tant qu'infrastructure sélectionnable et exploitée dans le cadre d'une organisation de service substantielle. Le travail du client est d'acheter suffisamment de séparation, de réserver suffisamment de capacité et de préserver suffisamment d'état indépendant pour survivre aux dépendances qu'IBM n'absorbe pas.

C'est pourquoi le choix de la région est le bon centre de la proposition d'IBM Cloud, mais seulement lorsqu'il est lu physiquement. Dallas n'est pas un point coloré. C'est un ensemble de bâtiments nommés, de correspondances de zone spécifiques au compte, de pods, de serveurs stockés, de systèmes d'alimentation et de liaisons métropolitaines. Francfort n'est pas une garantie de souveraineté. C'est un engagement de localisation avec des qualifications de support, de métadonnées et de récupération. Direct Link n'est pas de la redondance.

C'est un chemin privé jusqu'à ce qu'un deuxième chemin, un routeur séparé et une politique de routage fonctionnelle en fassent plus.

La carte est crédible. La responsabilité cachée dans chaque point est le produit.