Résumé

  • Les preuves publiques les plus solides pointent vers un emplacement d'infrastructure classique IBM Cloud à Singapour plutôt que vers une installation commercialisée séparément. La propre documentation des plages IP d'IBM listesng01à Jurong East, et les tableaux de localisation Kubernetes et OpenShift d'IBM listent Singapour comme une région classique à centre de données unique avec la zonesng01; voirhttps://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-ibm-cloud-ip-ranges,https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zonesethttps://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zones.
  • Les preuves physiques du site sont concentrées autour du campus 29A International Business Park de Digital Realty à Jurong East. La page actuelle SIN10 de Digital Realty donne l'adresse et la taille du bâtiment surhttps://www.digitalrealty.com/data-centers/asia-pacific/singapore/sin10, tandis que les anciennes annonces de bail Digital Realty/SoftLayer et IBM lient l'expansion de l'hébergement cloud, dédié et géré à cette même propriété.
  • Les preuves réseau sont larges au niveau d'IBM Cloud mais minces au niveau du serveur de Singapour. PeeringDB identifie AS36351 comme SoftLayer Technologies, Inc. (une société IBM), également connu sous le nom d'IBM Cloud, avec 1 800 préfixes IPv4, 450 préfixes IPv6 et un trafic de 1 à 5 Tbps; BGP.tools montre le peering AS36351 à Singapour chez BBIX Singapore. Ce sont des signaux globaux utiles, pas une preuve de placement client exactsng01.
  • Le principal risque opérationnel n'est pas de savoir si IBM Cloud existe à Singapour. Il s'agit de savoir si le service d'un client donné est lié à un centre de données classique, à un chemin Direct Link, à un stock de matériel, à une file d'attente de support, à une conception de sauvegarde ou à un chemin de migration. Les propres docs Direct Link d'IBM disent que Direct Link n'est pas intrinsèquement redondant et que les clients doivent déployer la diversité.
  • Le niveau de preuve est Moyen. Les enregistrements publics soutiennent une surface d'hébergement IBM Cloud à Singapour, mais ils ne divulguent pas le nombre actuel de racks, le placement des charges de travail des clients, la profondeur des pièces de rechange, la durée du bail de l'installation, les procédures de réparation privées ou le basculement testé entre Singapour et d'autres emplacements IBM Cloud.

La vente est cloud; la dépendance est toujours une salle à Singapour

Le nom IBM-SG-AP IBM Sinapore Server Farm est maladroit, mais la question opérationnelle qui le sous-tend est ordinaire et importante: lorsqu'un client achète une capacité hébergée IBM Cloud à Singapour, de quel système physique et contractuel dépend-il réellement? IBM commercialise une plateforme cloud globale, des serveurs bare metal, une connectivité privée, un stockage d'objets, des services VPC et des modèles de conception haute disponibilité. L'acheteur expérimente ces services via une console, une API, une grille tarifaire, une page de statut de service et un ticket de support. La panne, cependant, a toujours un corps.

Il peut s'agir d'un rack perdant une alimentation, d'une commande de cross-connect retardée par un opérateur d'installation, d'une configuration de serveur de rechange indisponible dans la bonne ville, d'un événement de maintenance de routeur, d'une panne de session BGP, d'une sauvegarde client qui n'a jamais quitté le site affecté, ou d'un ticket de support qui manque le moment où un opérateur peut encore déplacer une charge de travail proprement.

Le dossier public est suffisamment bon pour dire que Singapour est un véritable emplacement d'infrastructure IBM Cloud. La documentation d'IBM pour les plages IP d'infrastructure classique surhttps://cloud.ibm.com/docs/infrastructure-hub?topic=infrastructure-hub-ibm-cloud-ip-rangeslistesng01à Jurong East et montre les plages d'adresses de l'équilibreur de charge et du réseau privé associées à cet emplacement. La page de localisation d'IBM surhttps://cloud.ibm.com/docs/overview?topic=overview-locationsexplique que les clients d'infrastructure classique peuvent sélectionner des centres de données individuels et distingue les centres de données classiques des régions multizones. Le tableau des localisations du service Kubernetes d'IBM surhttps://cloud.ibm.com/docs/containers?topic=containers-regions-and-zonesliste Asie-Pacifique, Singapour, Singapour, métrosng-mtr, zonesng01, géré depuis Asie du Nord. Le tableau des localisations OpenShift d'IBM surhttps://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zonesrépète la même ligne classique de centre de données unique à Singapour.

Ces documents IBM comptent car ils ancrent l'actif dans le vocabulaire de service actuel. Ils fixent également la limite de la revendication. Une ligne classique de centre de données unique n'est pas la même chose qu'une région Singapour tolérante aux pannes avec trois zones de disponibilité indépendantes. La documentation plus large des localisations d'IBM explique les régions multizones comme un moyen de répartir les ressources sur des emplacements physiques, et les régions multizones à campus unique comme des conceptions où certaines dépendances peuvent être partagées. La liste classiquesng01de Singapour n'est pas présentée dans ces tableaux comme une région multizone de Singapour. Pour un acheteur, cela signifie qu'un serveur placé à Singapour peut satisfaire aux exigences de latence, de juridiction ou d'accès local, mais il ne doit pas être traité comme une conception de résilience complète en soi.