Résumé

  • Rackspace IT Hosting AS IT Hosting Provider Hong Kong correspond à AS45187 dans les registres publics APNIC et RIPEstat. Le relevé RDAP d'APNIC nomme Rackspace.com Hong Kong Limited comme organisation titulaire, et RIPEstat étiquette le titulaire "RACKSPACE-AP - Rackspace IT Hosting AS IT Hosting Provider Hong Kong".
  • La surface de routage est matériellement visible. L'instantané du statut de routage de RIPEstat pour AS45187 montrait 13 préfixes IPv4, 2 préfixes IPv6, 66 816 adresses IPv4, une visibilité RIS complète observée pour les deux familles d'adresses, et 23 voisins observés. La vue des préfixes annoncés listait les préfixes actifs incluant 119.9.64.0/19, 119.9.96.0/19, 120.136.32.0/20, 180.150.128.0/19, 202.168.208.0/21, 203.60.0.0/17, 2401:1800::/32, et 2407:fa00::/32.
  • PeeringDB ajoute un contexte de site et d'interconnexion plutôt qu'une garantie de capacité. Il liste "Rackspace Hong Kong" pour AS45187, une politique ouverte, des comptes de préfixes indicatifs de 100 IPv4 et 10 IPv6, deux entrées d'échange 10G à Equinix Hong Kong et HKIX, et une entrée de site à MEGA-i à Hong Kong.
  • Les pages HKG1 et HKG5 de Rackspace rendent visible la dépendance physique. HKG1 est décrit à Tsuen Wan avec des modules UPS, une alimentation double 11 kV et des composants réseau redondants; HKG5 est décrit à Tseung Kwan O avec 917 m² d'espace de centre de données dédié, une puissance électrique totale de 13,5 MW, une capacité UPS de 7,2 MW, sept opérateurs de fibre, 10 Gbit/s par opérateur, une optimisation de route BGP multipath, et une séparation énoncée où les clients conservent le contrôle administratif des serveurs loués tandis que Rackspace contrôle le matériel réseau.
  • Le niveau de preuve est Élevé pour l'identité réseau publique et les preuves d'exploitation à Hong Kong, mais ce n'est pas un chèque en blanc pour toutes les charges de travail hébergées. Les clients ont toujours besoin de preuves spécifiques au service concernant le placement, la redondance, les délais de restauration, l'escalade des tickets, les exclusions de maintenance, l'accès aux pièces de rechange, le statut RPKI, les limites contractuelles et les voies de sortie.

La question utile n'est plus de savoir si Rackspace existe à Hong Kong

Certains profils d'infrastructure commencent par un nom mince et un ASN faible. Ce n'est pas le cas ici. Le registre public autour de Rackspace IT Hosting AS IT Hosting Provider Hong Kong est suffisamment épais pour déplacer l'enquête de l'existence à la dépendance. L'enregistrement RDAP du système autonomed’APNIC identifie AS45187 comme RACKSPACE-AP, avec le pays HK et Rackspace.com Hong Kong Limited comme organisation titulaire. Lavue d'ensemble ASde RIPEstat utilise l'étiquette de titulaire "Rackspace IT Hosting AS IT Hosting Provider Hong Kong" et marque l'ASN comme annoncé. Cette paire est plus solide qu'une entrée de répertoire d'hébergement extraite ou une page d'entreprise obsolète.

Les preuves de routage sont également suffisamment actuelles pour compter. Lestatut de routagede RIPEstat pour AS45187 montrait une visibilité IPv4 et IPv6 sur tous les pairs RIS observés au moment de l'instantané, 13 préfixes IPv4, 2 préfixes IPv6, et 23 voisins observés. L'ensemble de données des préfixes annoncéslistait 15 lignes de préfixes actuelles. Celles-ci incluent deux grands agrégats IPv6, 2401:1800::/32 et 2407:fa00::/32, et des routes IPv4 telles que 119.9.64.0/19, 119.9.96.0/19, 120.136.32.0/20, 122.200.132.0/22, 180.150.128.0/19, 202.168.208.0/21, et 203.60.0.0/17. Ce n'est pas un réseau de vanity à préfixe unique.

Les documents publics sur les installations de Rackspace rendent la question encore moins abstraite. Lapage du centre de données HKG1de Rackspace place une installation à Hong Kong à Tsuen Wan et décrit l'alimentation, le refroidissement, la sécurité, la connectivité et les garanties. Sapage HKG5place une autre installation à Tseung Kwan O et va plus loin, listant 917 m² d'espace de centre de données dédié, une puissance électrique totale de 13,5 MW, une capacité UPS de 7,2 MW, sept opérateurs de fibre sur le site, et une optimisation de route BGP multipath. La question de l'existence est donc suffisamment réglée pour le travail d'approvisionnement. La question ouverte est de savoir si le service hébergé d'un client particulier a la même résilience que ce que suggère l'empreinte publiée.

Cette distinction importe car "Rackspace" est une grande marque, "Hong Kong" est une étiquette de marché, AS45187 est une frontière réseau, et une charge de travail client est un déploiement spécifique au contrat. Un acheteur peut voir les ressources numériques publiques et les affirmations de Rackspace sur ses installations, mais ne peut en déduire quelle salle, quel rack, quel opérateur, quel VLAN, quel système de sauvegarde, quelle équipe de support ou quel calendrier de maintenance s'applique à son propre environnement. Une page d'installation bien documentée devrait rendre l'examen plus strict, pas moins rigoureux.

AS45187 est un véritable bord opérationnel, mais le registre ne montre pas tous les services

Les enregistrements d'APNIC et de RIPEstat montrent une identité cohérente. L'enregistrement RDAP donne une date d'enregistrement de décembre 2014 et une date de dernière modification de juillet 2020. Lavue dérivée du whoisde RIPEstat enregistre l'aut-num comme 45187, l'as-name comme RACKSPACE-AP, la description comme Rackspace IT Hosting AS IT Hosting Provider Hong Kong, et le pays comme HK. Elle montre également des lignes de politique d'import et d'export historiques nommant AS3491, AS1239 et AS2914, ainsi que des contacts de mainteneur de routage Rackspace. Ces détails sont utiles car ils lient la ressource numérique à l'entité Rackspace Hong Kong et à un enregistrement d'administration de routage de longue date.

Cela ne suffit pas pour définir le produit. AS45187 peut porter des fonctions de cloud public, d'hébergement géré, de serveur dédié, de colocation, de stockage, de surveillance, de plan de contrôle, de support ou de backbone de différentes manières. Certains systèmes clients peuvent être directement adressés depuis AS45187. D'autres peuvent utiliser des adresses fournies par le fournisseur, des interconnexions privées, des adresses de fournisseur cloud ou des routes hybrides qui n'apparaissent pas comme des origines visibles par le client. Le registre peut dire à un acheteur où regarder.

Il ne peut pas lui dire quel produit exact utilise le bord de routage, quelle entité légale signe le contrat ou quel fournisseur est responsable d'un incident.

La preuve du titulaire APNIC doit donc être lue comme un point de départ pour la carte des responsabilités. Si l'on dit à un client qu'une charge de travail à Hong Kong est livrée depuis l'infrastructure Rackspace, AS45187 donne au client une frontière réseau concrète sur laquelle poser des questions. Quels préfixes sont impliqués? Lesquels sont orientés client, management uniquement, sauvegarde uniquement ou hérités? Quelles politiques de routage sont actives, et lesquelles sont historiques? Quels préfixes ont une autorisation d'origine de route, et lesquels restent inconnus des validateurs RPKI? Ce ne sont pas des questions académiques.

Elles déterminent si une fuite de route, un changement de filtre, un événement d'atténuation DDoS ou une panne en amont peut affecter le service.

La première mise en garde concerne RPKI. La vérification de validation utilisée pour cet article sur 119.9.64.0/19 via lepoint de terminaison de validation RPKIde RIPEstat a renvoyé un statut inconnu plutôt que valide. Le même statut est apparu pour l'ensemble de préfixes vérifié à partir de la liste des préfixes annoncés. Inconnu n'est pas la même chose qu'invalide, et cela ne signifie pas que le réseau échoue. Cela signifie que l'autorisation d'origine de route devrait être une question d'approvisionnement active, car les réseaux qui appliquent la validation d'origine de route traitent les routes valides, invalides et inconnues différemment. Pour un client qui dépend d'un bord stable à Hong Kong, "inconnu" devrait conduire à une discussion sur les ROA, les filtres de route, les procédures de contact et la propriété du contrôle des changements.

Rackspace publie deux types différents de preuves d'installation à Hong Kong

Les pages des installations de Rackspace à Hong Kong sont inhabituellement concrètes par rapport à de nombreux profils d'hébergement régionaux. HKG1, décrit surRackspace Technology Data Centers: Hong Kong (HKG1), est situé à Tsuen Wan. La page indique que les installations de Hong Kong sont dotées de professionnels de l'ingénierie des systèmes qui gèrent et maintiennent les systèmes 24/7/365. Les affirmations physiques listées pour HKG1 incluent des modules UPS de 400 KVA en configuration N+1, 30 minutes d'autonomie de batterie, deux alimentations 11 kV provenant de sous-stations HKE distinctes, des colonnes montantes d'alimentation doubles, plusieurs générateurs, et une installation neutre pour les opérateurs alimentée par des connexions télécom doubles.

HKG5, décrit surRackspace Technology Data Centers: Hong Kong (HKG5), est situé à Tseung Kwan O et expose un ensemble différent de spécificités. Il liste 917 m² d'espace de centre de données dédié, une puissance électrique totale de 13,5 MW, une capacité UPS de 7,2 MW, des générateurs diesel d'une capacité de 2,25 MW chacun, des réservoirs de carburant de 12 000 litres, plus de 1 MW de capacité de refroidissement, sept opérateurs fournissant une connectivité fibre au site, 10 Gigabit Ethernet par opérateur, des routeurs Cisco et Arista redondants, et une optimisation de route BGP multipath. Il indique également que les clients conservent le contrôle administratif des serveurs loués tandis que Rackspace conserve le contrôle du matériel réseau.

Ces affirmations ont une signification opérationnelle. Elles disent que Rackspace ne se contente pas de revendre une région cloud anonyme sous une étiquette Hong Kong. Elles indiquent une installation physique, une conception réseau, du personnel de support et des limites de contrôle. Mais elles doivent encore être converties en preuves spécifiques au service. "HKG5 dispose de sept opérateurs" ne prouve pas en soi que chaque service client dispose de sept chemins actifs, par défaut, payés et provisionnés.

"L'optimisation de route BGP multipath" ne prouve pas la diversité des routes jusqu'à l'application, la couche de stockage ou la console de gestion du client. "Les clients conservent le contrôle administratif" ne prouve pas qu'un client peut récupérer le service si le matériel réseau, le portail, la file d'attente de support ou le statut de facturation bloque l'accès.

Les pages d'installation sont les plus solides là où elles nomment les entrées physiques. Les alimentations électriques, la capacité UPS, le carburant du générateur, les nombres d'opérateurs et les familles de routeurs sont tous des éléments réels qu'un acheteur peut demander à voir dans une conception de service. Les pages sont les plus faibles là où elles sont nécessairement génériques.

Elles ne publient pas les attributions de racks, le placement des clients, les panneaux de brassage, les cartes VLAN privées, la topologie de stockage, la géographie des sauvegardes, les bacs de pièces de rechange ou la profondeur de la file d'attente des techniciens qui serait appelée lors d'un incident. La tâche d'approvisionnement est de combler cet écart sans prétendre que la page d'installation publique l'a déjà fait.

PeeringDB confirme les signaux d'interconnexion, pas le placement client

L'API réseau PeeringDB pour ASN 45187liste une entité réseau nommée Rackspace Hong Kong. Les champs montrent une politique ouverte générale, un ensemble AS-IRR AS-RACKSPACE, des comptes de préfixes indicatifs de 100 IPv4 et 10 IPv6, un support IPv6, un nombre de points d'échange de 2, et un nombre de sites de 1. PeeringDB est un répertoire volontaire, donc aucun de ces champs n'est une certification. Néanmoins, l'entrée est précieuse car elle lie AS45187 à une posture d'interconnexion qui peut être comparée aux collecteurs de routes de Rackspace et aux déclarations sur les installations.

Lesenregistrements netixlan de PeeringDBlistent deux entrées actives orientées échange: Equinix Hong Kong et HKIX: HKIX Peering LAN. Les deux montrent une vitesse de 10 000 Mbit/s. La ligne Equinix Hong Kong liste une adresse IPv4 36.255.56.87 et une adresse IPv6 2001:de8:7::4:5187:2. La ligne HKIX liste une adresse IPv4 123.255.90.101 et une adresse IPv6 2001:7fa:0:1::ca28:a065. L'enregistrement netfac de PeeringDBliste MEGA-i (iAdvantage Hong Kong) à Hong Kong comme entrée de site pour l'entité réseau.

Ces lignes créent une tension utile avec les pages HKG1 et HKG5 de Rackspace. Rackspace publie des pages d'installation pour Tsuen Wan et Tseung Kwan O, tandis que PeeringDB expose une entrée de site réseau à MEGA-i et des rattachements d'échange à Equinix Hong Kong et HKIX. Il n'y a pas de contradiction à moins que quelqu'un essaie de faire dire à un seul enregistrement plus qu'il ne peut. PeeringDB peut décrire une présence d'interconnexion plutôt qu'un placement de calcul client. Les pages de centre de données de Rackspace peuvent décrire des installations d'hébergement plutôt que chaque emplacement d'échange ou d'interconnexion.

Un client a besoin de la carte qui relie ces couches: où se trouve le serveur, où se trouve le routeur de bord, où se fait le peering d'échange, où entre le transit, et où le client a des droits contractuels.

La leçon opérationnelle immédiate est que le nombre d'installations n'est pas la même chose que la redondance. Une ligne d'installation PeeringDB peut coexister avec plusieurs sites exploités ou commercialisés par Rackspace. Deux ports orientés échange peuvent améliorer l'accessibilité vers des réseaux sélectionnés sans prouver une diversité de transit complète. Un port d'échange 10G peut être utile pour le peering, mais le chemin client survivant lors d'une panne peut dépendre du transit payant, de l'interconnexion privée, du DNS, du filtrage de sécurité, des équilibreurs de charge, de la réplication de stockage et de l'accès au support.

L'enregistrement d'interconnexion public donne à l'acheteur des noms et des adresses à tester, pas un résultat de basculement de bout en bout.

La surface de routage est large, mais la diversité doit encore être prouvée deux fois

AS45187 a un ensemble de voisins visible. Lepoint de terminaison des voisins ASNde RIPEstat a renvoyé 23 voisins observés. La liste incluait de grands réseaux mondiaux tels que AS174, AS3257, AS3300, AS3491, AS4637, AS6453, AS6939 et AS7473 du côté gauche, une ligne droite pour AS58982, et plusieurs lignes incertaines. Le BGP public ne peut pas dire si chaque adjacence est un amont payant, un pair, un client, une relation de routeur d'échange, un artefact temporaire de fuite de route ou un artefact de classification du côté du collecteur. Il peut seulement nous dire que le bord de routage n'est pas invisible.

Les lignes de politique whois historiques d'APNIC ajoutent une autre couche. Elles listent des importations depuis AS3491, AS1239 et AS2914 et des exportations vers ces AS. C'est un élément utile de preuve historique d'administration de routage, mais il ne décrit pas automatiquement l'ingénierie du trafic actuelle. La liste actuelle des voisins de RIPEstat inclut indirectement certains de ces noms et en montre d'autres également. Un acheteur devrait demander à Rackspace la conception actuelle du transit et du peering plutôt que de se fier au texte de politique whois statique.

La diversité doit être prouvée deux fois: une fois dans le routage, et une fois dans les opérations physiques. Un réseau peut avoir de nombreux voisins BGP dans les données publiques tandis que plusieurs chemins partagent le même bâtiment, la même salle de rencontre, le même domaine d'alimentation, le même conduit de fibre, la même paire de routeurs ou la même file d'attente de support. Inversement, un service peut avoir une résilience privée ou côté fournisseur solide qui est à peine visible dans le BGP public.

Le but n'est pas de punir Rackspace pour avoir caché des détails opérationnels; c'est d'éviter de confondre un graphe AS public avec une conception de récupération client testée.

Les meilleures questions sont spécifiques à la couche. Quels préfixes AS45187 proviennent de quels routeurs de bord à Hong Kong? Quels amonts transportent les routes par défaut pour le service pendant le fonctionnement normal? Quelles sessions d'échange sont du peering sans règlement versus une accessibilité critique? Quels chemins sont diversifiés au niveau de l'entrée de fibre et du bâtiment? Combien de trafic le chemin restant peut-il transporter en pointe après le retrait d'un opérateur, d'un échange, d'un routeur ou d'un domaine d'installation? Le BGP public peut suggérer où poser des questions.

Il ne peut pas répondre à toutes par lui-même.

Rackspace vend de l'abstraction, mais l'économie de Hong Kong reste physique

Lapage d'hébergement géréde Rackspace présente le produit dans un langage d'entreprise familier: hébergement géré dédié, infrastructure dédiée monolocataire, bare metal, bases de données, réseautage, stockage, sauvegarde gérée, reprise après sinistre, RackConnect et cloud privé. La promesse commerciale est que Rackspace convertira la complexité physique en service. Les clients achètent des performances, du support et du contrôle sans posséder chaque routeur, alimentation électrique, baie de stockage, interconnexion et processus de maintenance.

Cet échange a une réelle valeur, mais il n'efface pas l'économie sous-jacente. Leguide client de colocationde Rackspace décrit la facturation basée sur le kilowatt pour l'alimentation critique redondante réservée, avec des frais récurrents mensuels séparés pour les interconnexions et la bande passante mélangée lorsqu'elle est achetée. Il fait également référence à des frais de configuration uniques, des circuits d'alimentation, des cages privées, des PDU dans le rack et des interconnexions. C'est le vocabulaire de la capacité physique. La facture cloud repose toujours sur l'allocation d'énergie, l'espace rack, l'optique, les mains à distance, les engagements de bande passante et la main-d'œuvre.

Les pages Hong Kong rendent cela visible. L'affirmation de HKG5 de 13,5 MW de puissance électrique, ses 7,2 MW de capacité UPS et ses sept opérateurs de fibre ne sont pas une décoration marketing. Ce sont des entrées de capacité qui peuvent contraindre ou protéger un client. Si la densité des racks augmente, si un client a besoin de plus d'interconnexions, si un routeur de rechange n'est pas disponible, si un chemin d'opérateur est congestionné, ou si une fenêtre de maintenance nécessite un travail sérialisé, le client ressent l'état physique à travers la latence, le retard des tickets, les limites de migration ou les crédits après panne.

La capacité hébergée est achetée en tant que service, mais elle échoue en tant que chaîne d'étapes physiques et administratives.

C'est pourquoi il faut séparer la capacité "installée" de la capacité "utilisable". La capacité installée est ce que l'empreinte publiée semble inclure: installations, générateurs, systèmes UPS, connexions d'opérateurs, routeurs, préfixes et personnel de support. La capacité utilisable est ce qui reste pour un client après avoir pris en compte les réservations normales, la surréservation, la maintenance, le routage spécifique au client et les domaines de protection. La capacité récupérable est encore plus étroite: la partie qui peut être restaurée dans le délai requis par le client après une défaillance de composant.

Les pages publiques sont bonnes pour la capacité installée. L'assurance client doit prouver la capacité utilisable et récupérable.

Le contrôle est divisé par conception

La ligne la plus importante sur HKG5 n'est peut-être pas celle sur les mégawatts ou le nombre d'opérateurs. La page indique que les clients conservent le contrôle administratif des serveurs loués tandis que Rackspace conserve le contrôle du matériel réseau. Cette séparation est exactement ce qu'un client d'hébergement géré souhaite pendant le fonctionnement normal: le client peut gérer sa charge de travail, tandis que le fournisseur protège la couche réseau partagée. Lors d'une panne, la même séparation devient une frontière qui doit être répétée.

Si un serveur loué est sain mais inaccessible, les droits administratifs du client peuvent ne pas suffire. Si un client peut atteindre un serveur via VPN mais ne peut pas atteindre le service public, la frontière réseau importe. Si un client a besoin d'un changement de route, d'une règle de pare-feu, d'un ticket d'interconnexion ou d'un remplacement matériel, l'autorité et la file d'attente de Rackspace deviennent le facteur limitant. Si le client a une sauvegarde mais ne peut pas déplacer suffisamment de données sur le chemin disponible, le contrôle au niveau du serveur est une preuve publique limitée.

La responsabilité partagée n'est pas un slogan ici; c'est l'architecture opérationnelle.

Le guide de colocation de Rackspace renforce la même frontière. Il décrit les gestionnaires de mise en œuvre, la formation au portail client, les demandes de mains à distance, la création automatique de tickets, les moniteurs d'alerte et un runbook. Il indique que les clients peuvent interagir en créant des tickets via le portail client Rackspace et peuvent appeler l'équipe de support 24/7/365.

Il liste également les tâches de mains à distance telles que la mise sous/hors tension des appareils, la vérification visuelle, les tests de câbles, le remplacement de matériel fourni par le client, le montage et démontage en rack, le câblage réseau dans le rack et la destruction de disques durs. Ce sont les actions concrètes qui transforment la détection des pannes en réparation.

Pour un acheteur, la question de contrôle est simple: que pouvons-nous faire sans Rackspace, que peut faire Rackspace sans nous, et que nécessite que les deux parties agissent dans le bon ordre? Cette question devrait être répondue avant la production. Elle devrait être écrite en étapes opérationnelles, pas seulement en langage contractuel. Quels utilisateurs du portail ont l'autorité? Quel numéro de téléphone fonctionne si le portail est indisponible? Quels changements de route nécessitent un ticket? Quelles actions matérielles sont incluses? Quelles tâches sont facturées par incréments de 15 minutes?

Quelles tâches dépendent de pièces fournies par le client plutôt que de pièces fournies par Rackspace?

Les fenêtres de réparation sont une caractéristique du produit, pas une note de bas de page

Les pages du centre de données de Rackspace publient des garanties solides, mais les détails comptent. HKG1 et HKG5 incluent un langage de garantie pour le réseau, l'infrastructure et le remplacement matériel. Les sections réseau et infrastructure parlent en termes de disponibilité et de crédits, tandis que la garantie de remplacement matériel stipule que le remplacement ou la réparation du matériel ou des composants fournis par Rackspace commencera dans l'heure suivant l'identification du problème, avec des crédits si ce n'est pas le cas. Le mot "commencera" est important.

Ce n'est pas la même chose que "terminera", et cela ne décrit pas tous les composants fournis par le client.

Le tableau des tâches de mains à distance dans le guide de colocation est plus granulaire sur le plan opérationnel. Il montre que HKG1 a à la fois un SLA de réponse d'une heure et un SLA d'exécution de 24 heures pour les mains à distance. Le même guide donne des temps estimés pour les tâches courantes, telles que 30 minutes pour la mise sous/hors tension d'un routeur, serveur ou commutateur, 60 minutes pour trois câbles pour les tests de support de câblage, et 60 minutes pour le remplacement d'un appareil fourni par le client qui n'est pas à chaud.

Il liste un tarif de mains à distance de 46,25 $ US par incrément de 15 minutes plus la nomenclature. Ce ne sont pas des détails insignifiants. Ils montrent où l'horloge de réparation peut passer d'une mesure abstraite de disponibilité à du travail humain payé.

Un client devrait donc séparer trois horloges. Le temps de détection est le temps nécessaire à la surveillance pour remarquer et classer une panne. Le temps de réponse est le temps nécessaire à Rackspace ou au client pour accepter la responsabilité et commencer l'action. Le temps d'exécution est le temps réellement pris par la réparation, y compris les pièces, l'accès, le câblage, le redémarrage, le changement de route, la reconstruction du stockage et la vérification. Les crédits après panne sont commercialement importants, mais ils ne restaurent pas la charge de travail.

La surveillance de la résilience devrait se concentrer sur la restauration mesurée, pas seulement sur les crédits de service.

La même logique s'applique à la maintenance. Le langage de garantie de Rackspace exclut la maintenance planifiée ou d'urgence. Cette exclusion est normale, mais elle compte dans un examen de capacité hébergée. Si un chemin ou un site est indisponible pour maintenance, la véritable résilience du client est la capacité restante dans le chemin sans maintenance. Si un client a besoin d'un changement pendant un gel de maintenance du fournisseur, les règles d'escalade comptent. Si un événement de maintenance d'urgence touche un composant réseau partagé, les droits administratifs du client peuvent ne pas aider.

Les fenêtres de réparation et les fenêtres de maintenance font partie du produit, pas de la paperasse accessoire.

La sécurité de l'origine de route est le point faible d'une empreinte publique par ailleurs solide

La dégradation la plus évidente dans les preuves réseau est le statut RPKI. RIPEstat a clairement rapporté la surface de routage, et PeeringDB a donné des détails d'interconnexion, mais les vérifications de validation RPKI sur la liste actuelle des préfixes ont renvoyé un statut inconnu plutôt que valide dans l'échantillonnage utilisé ici. Un statut inconnu peut exister pour de nombreuses raisons, y compris l'absence de ROA, la couverture du validateur, le timing ou les choix de gestion des ressources. Cela ne signifie pas qu'AS45187 détourne des routes.

Cela signifie que la couche d'autorisation d'origine n'est pas aussi forte publiquement que la couche de visibilité BGP.

Pour un client hébergé, cela importe car la validation d'origine n'est plus exotique. La RFC 6811 décrit la validation d'origine de route comme un moyen d'utiliser l'infrastructure à clé publique de ressource pour déterminer si un AS est autorisé à annoncer un préfixe. Le propre matériel RPKI d'APNIC explique la certification des ressources en termes opérationnels. Un client qui dépend de l'accessibilité publique devrait se soucier de savoir si les préfixes de production de son fournisseur sont valides, inconnus ou invalides, et si les propres préfixes routés du client ont des ROA corrects avant la migration.

La question pratique n'est pas "Est-ce que Rackspace connaît BGP?" L'ensemble de voisins public et les affirmations sur les installations suggèrent des opérations de routage matures. La question plus étroite est: pour les préfixes exacts qui portent le service du client, les autorisations d'origine de route sont-elles publiées et testées avec les validateurs principaux? Si le client apporte son propre espace d'adressage, qui crée et maintient les ROA? Si Rackspace attribue l'espace d'adressage, Rackspace peut-il montrer le statut et le processus de contrôle des changements?

Si un préfixe doit être déplacé lors d'un incident, qu'arrive-t-il à l'état ROA et au filtre?

C'est l'un des rares contrôles publics où la réponse peut être améliorée sans révéler de détail privé sur les installations. Un ROA valide ne prouve pas la résilience client, mais il supprime un mode de défaillace évitable. Une route inconnue peut encore fonctionner sur la plupart des réseaux; elle donne simplement à l'acheteur moins d'assurance au niveau de la validation d'origine. Dans un dossier Rackspace Hong Kong par ailleurs solide, c'est exactement le genre de question spécifique et réparable qui ne devrait pas être perdue sous le poids d'une grande marque.

La localité des données n'est pas réglée par les lettres HK

La région d'allocation est HK, APNIC liste AS45187 avec le pays HK, Rackspace publie des installations à Hong Kong, et l'enregistrement PeeringDB décrit une interconnexion à Hong Kong. Ce sont de bons signaux de localité. Ils ne prouvent toujours pas où se trouvent les données, les sauvegardes, les journaux, les enregistrements de support, le système d'identité, les instantanés ou les copies de récupération d'un client. Dans les contrats cloud et d'hébergement géré, la localité est une matrice de placement, pas un code de pays.

L'autorité de protection des données de Hong Kong souligne ce point dans ses orientations publiques. LesLignes directrices sur le cloud computingdu PCPD de janvier 2025 disent aux utilisateurs de données de considérer l'emplacement du stockage des données, les mesures de sécurité au niveau des équipements, l'intégrité et la compétence des personnes ayant accès, la transmission sécurisée, les contrats avec les sous-traitants, les contrôles de conservation et les implications des transferts transfrontaliers. Unenote de cas du PCPD sur les systèmes cloud en dehors de Hong Kongindique que l'ordonnance n'interdit pas le stockage de données personnelles dans un système cloud en dehors de Hong Kong, mais que les utilisateurs de données doivent toujours se conformer à la PDPO et aux principes de protection des données. Lesclauses contractuelles types recommandéespar le PCPD fournissent un cadre contractuel pour les transferts transfrontaliers.

Pour les clients de Rackspace Hong Kong, la conséquence est pratique. Le client devrait demander où sont stockées les données primaires, où sont stockés les instantanés, où sont stockées les sauvegardes, où sont stockés les journaux de gestion, quelles équipes de support peuvent accéder à l'environnement, quels sous-traitants ou clouds partenaires sont impliqués, et si une action de support normale transfère des données personnelles en dehors de Hong Kong.

Un bord de routage à Hong Kong peut coexister avec des outils de support non hongkongais, des systèmes d'identité mondiaux, des copies de sauvegarde offshore ou des interconnexions multi-cloud. Rien de tout cela n'est nécessairement impropre. Il doit simplement être divulgué et testé par rapport aux propres obligations réglementaires du client.

La localité interagit également avec la récupération. Une sauvegarde en dehors de Hong Kong peut améliorer la résilience mais modifier l'analyse des transferts. Une sauvegarde uniquement locale peut satisfaire une préférence de résidence mais échouer si l'installation locale subit un événement régional. Une conception multisite à Hong Kong peut être meilleure pour la latence et la juridiction mais plus coûteuse et toujours dépendante de fournisseurs communs. L'acheteur a besoin de la conception, pas du slogan.

Les preuves de sortie font partie de la résilience

Un service hébergé n'est pas entièrement résilient tant que le client ne peut pas le quitter sous pression. La documentation de Rackspace contient des signes utiles que certains services exposent des chemins d'exportation et de migration. Le manuel cloud Rackspace sur OpenStack Flex pointe vers des fonctions de création de machines virtuelles, de stockage par blocs, de stockage d'objets, d'exportation d'images, d'importation d'images et de planification de migration. Leguide d'exportation d'imagesdécrit l'exportation d'instantanés d'instance depuis un projet OpenStack Flex. Leguide API Object Storageexplique que l'accès nécessite des identifiants cloud Rackspace, des détails de projet et des appels API.

Ces documents ne prouvent pas que chaque client d'hébergement géré à Hong Kong peut effectuer une sortie d'urgence complète. Ils prouvent que la sortie devrait être discutée au niveau des artefacts. Le client peut-il exporter des images VM? Peut-il exporter des volumes de blocs? Les sauvegardes sont-elles portables? Les configurations réseau, les règles de pare-feu, les paramètres d'équilibreur de charge, les zones DNS, les certificats, les journaux et l'historique de surveillance sont-ils exportables? L'exportation fonctionne-t-elle si le portail client est dégradé? Nécessite-t-elle un engagement de support payant?

Peut-elle être testée sans déclencher un changement en production?

La couche physique réapparaît lors de la sortie. Les exportations importantes consomment de la bande passante et du temps. La facturation d'interconnexion, les plafonds de transit, les taux de lecture du stockage, les identifiants de stockage d'objets et les tickets de support font tous partie du chemin de migration. Un client qui n'a jamais mesuré une exportation complète peut découvrir lors d'un incident que "nous pouvons migrer" signifie en réalité "nous pouvons commencer un long transfert après que le fournisseur approuve la demande". La planification de sortie n'est pas une hostilité envers Rackspace.

C'est l'aboutissement honnête d'un examen de dépendance.

L'infrastructure publiée par Rackspace est suffisamment solide pour que de nombreux clients choisissent rationnellement de ne pas gérer eux-mêmes une infrastructure équivalente. C'est le point économique de l'hébergement géré. Le danger n'est pas d'utiliser un fournisseur; c'est d'en utiliser un sans conserver les preuves nécessaires pour migrer, restaurer ou vérifier indépendamment le service quand quelque chose tourne mal.

L'emballage corporatif aide, mais les preuves locales l'emportent encore

Le dossier corporatif plus large de Rackspace Technology aide à expliquer pourquoi ce profil Hong Kong ne devrait pas être traité comme un petit hébergeur régional. Rackspace Technology, Inc. apparaît dans les documents SEC comme une société cotée au Nasdaq sous le symbole RXT, et sondépôt 10-K 2025donne aux investisseurs le contexte plus large de l'entreprise et des risques autour de ses opérations cloud, d'hébergement et de services. Lapage des centres de données mondiauxde Rackspace présente une empreinte de centres de données multi-marchés et indique que ses installations utilisent la redondance dans les domaines de la sécurité, de l'alimentation, du refroidissement et du réseau. Ces faits réduisent l'incertitude sur l'identité et rendent les pages d'installation de Hong Kong plus crédibles qu'une page d'atterrissage autonome ne le serait.

Ils ne supprinent pas le besoin de preuves locales. Une entreprise mondiale peut encore avoir une contrainte d'installation locale, une dépendance régionale envers un fournisseur, un chemin de dépréciation spécifique au produit, un niveau de support spécifique au client ou une conception de cloud privé qui diffère de la page d'installation publique. Le 10-K est également rédigé pour les investisseurs, pas pour un client de Hong Kong essayant de savoir quel rack, quelle route, quel système de sauvegarde et quel ingénieur décideront d'une panne un samedi.

Les déclarations d'une société cotée peuvent décrire les risques commerciaux, les segments de revenus, la dette, la concurrence et les hypothèses opérationnelles. Elles ne peuvent pas certifier le chemin de récupération d'une charge de travail particulière sur AS45187.

Cet emballage corporatif change la méthode d'assurance. Avec un petit fournisseur inconnu, la première tâche pourrait être de prouver que l'entreprise et le réseau existent. Avec Rackspace Hong Kong, la première tâche est d'aligner plusieurs couches publiques qui sont chacune réelles: l'identité AS45187 d'APNIC, les preuves de routage actuelles de RIPEstat, les lignes d'interconnexion de PeeringDB, les pages d'installation HKG1 et HKG5 de Rackspace, la documentation d'hébergement géré et de colocation de Rackspace, et le propre contrat du client. Le risque n'est pas que chaque couche soit fausse.

Le risque est qu'un client suppose que toutes les couches s'appliquent à son service de la même manière.

L'acheteur devrait donc demander à Rackspace de produire un calendrier de service local. Il devrait nommer l'installation ou les installations, les ASN et préfixes pertinents, le site de récupération, l'emplacement de sauvegarde, le modèle de support, les exclusions de maintenance, le plan RPKI, les contrôles de localité des données et le processus de sortie. Une marque mondiale peut faciliter l'obtention de ce calendrier. Elle ne peut pas remplacer le calendrier.

Ce que les clients devraient tester avant de faire confiance au bord de Hong Kong

Le premier test est la cartographie. Demandez à Rackspace de mapper le service sur AS45187, l'installation ou les installations, les préfixes de production, les chemins de gestion, les chemins de sauvegarde et les systèmes de support. Recoupez la réponse ASN avec APNIC RDAP, les préfixes annoncés RIPEstat, l'enregistrement PeeringDB Rackspace Hong Kong et les pages HKG1/HKG5 de Rackspace. Si le service client n'utilise pas AS45187, cela peut être acceptable, mais cela devrait être clairement énoncé.

Le deuxième test est la panne. Supprimez un amont, un chemin d'échange, un routeur, un composant de stockage, un portail de support, un identifiant client et un domaine de maintenance dans un exercice sur table ou en direct. Enregistrez ce qui arrive à l'accessibilité, à l'accès à la console, au DNS, à la surveillance, à la sauvegarde, à la facturation, aux tickets et à l'exportation de données. Le résultat devrait identifier quelle partie du service est active-active, active-passive, sauvegarde uniquement ou manuelle.

Le troisième test est la sécurité du routage. Demandez le statut RPKI sur les préfixes de production exacts, y compris les préfixes appartenant au client. Demandez comment les ROA sont modifiés pendant la migration et qui approuve le changement. Demandez si des filtres de route sont maintenus pour AS45187 et les annonces client. Le statut RPKI public inconnu ne doit pas être traité comme un scandale; il doit être traité comme un élément de contrôle ouvert.

Le quatrième test est le support et la réparation. Utilisez le vocabulaire des tâches de mains à distance du guide de colocation pour rendre l'exercice concret. Qui ouvre le ticket? Qui peut appeler si le portail tombe en panne? Quelles tâches sont incluses, facturables ou exclues? Quelles pièces de rechange sont fournies par Rackspace, par le client ou par le fournisseur? Quel SLA de mains à distance HKG1 s'applique, et quel est l'équivalent pour le service HKG5 exact? Si une garantie de remplacement matériel commence dans l'heure suivant l'identification du problème, qui identifie le problème et qu'est-ce qui marque le début?

Le cinquième test est la localité et la sortie. Demandez la matrice de localité des données, y compris les données primaires, les répliques, les sauvegardes, les journaux, les enregistrements de support et l'identité. Demandez une preuve d'exportation et un test de restauration chronométré. Le matériel du PCPD explique clairement pourquoi ces questions font partie d'une discussion cloud à Hong Kong: le client reste responsable du traitement des données personnelles même lorsqu'il utilise un fournisseur cloud ou un sous-traitant.

Le niveau de preuve

Rackspace IT Hosting AS IT Hosting Provider Hong Kong reçoit un niveau de preuve réseau public Élevé. Ce niveau reflète l'identité et la visibilité opérationnelle, pas une déclaration illimitée sur tous les services Rackspace. APNIC lie AS45187 à Rackspace.com Hong Kong Limited. RIPEstat montre AS45187 comme annoncé, avec 13 préfixes IPv4, 2 préfixes IPv6, une visibilité RIS complète observée à l'instantané vérifié, et 23 voisins observés. PeeringDB liste Rackspace Hong Kong avec deux entrées orientées échange 10G et une ligne d'installation à Hong Kong.

Rackspace publie les pages HKG1 et HKG5 avec des affirmations concrètes sur les installations, l'alimentation, les opérateurs, le réseau et le support.

Le niveau n'est pas plus élevé car les preuves publiques s'arrêtent toujours à la frontière du client. Elles ne divulguent pas l'attribution de rack d'un client, le nombre de serveurs, la puissance réservée, la topologie de stockage, la géographie des sauvegardes, l'inventaire des pièces de rechange, la file d'attente de support, les exclusions contractuelles, le calendrier de maintenance ou le temps de sortie testé. Elles laissent également l'autorisation d'origine de route comme une question ouverte car les préfixes actuels échantillonnés ont renvoyé un statut RPKI d'inconnu plutôt que valide.

La conclusion pratique est étroite et utile: ce n'est pas une empreinte d'hébergement mince à Hong Kong. C'est une présence réseau et d'installation Rackspace réelle et bien documentée qui nécessite encore une assurance spécifique au service. Les clients ne devraient pas la rejeter comme invérifiable. Ils ne devraient pas non plus laisser le nom de Rackspace, deux pages de centre de données à Hong Kong ou la surface de route AS45187 visible se substituer aux preuves de panne qui protègent réellement une charge de travail.

Qui ressent la panne

Les personnes qui ressentent en premier une panne d'AS45187 ou d'une installation à Hong Kong peuvent être des propriétaires d'applications, des opérateurs de revendeurs, des équipes fintech, des administrateurs SaaS, des détaillants en ligne, des propriétaires de bases de données, des gestionnaires de conformité ou des ingénieurs réseau essayant de maintenir l'accessibilité des services clients.

L'effet en aval peut rapidement passer de la perte de paquets à la perte de revenus, d'une alerte de stockage à une obligation réglementaire manquée, d'une panne de portail à une migration retardée, ou d'un différend de facturation à un verrouillage administratif.

L'échelle de Rackspace peut réduire certains risques. Elle dispose d'opérations mondiales de centres de données, de SLA publiés, d'installations nommées à Hong Kong, d'un langage de support mature et d'une interconnexion visible. L'échelle peut également cacher la dépendance spécifique au client. Un grand fournisseur peut avoir de nombreuses routes, mais le client dépend toujours de sa propre conception de service. Un grand fournisseur peut publier des garanties de remplacement matériel, mais le client doit encore savoir si la pièce défaillante est fournie par Rackspace, par le client ou contrôlée par un autre fournisseur.

Un grand fournisseur peut avoir des ingénieurs mondiaux, mais le client a toujours besoin d'un chemin d'escalade local et contractuel.

C'est pourquoi cet article traite Rackspace Hong Kong comme une dépendance à comprendre plutôt qu'un mystère à résoudre. Les preuves publiques sont bonnes. L'infrastructure physique est nommée. Le réseau est visible. L'enregistrement d'interconnexion a des détails utiles. Le travail restant est de tester comment ces faits se comportent lorsqu'une charge de travail réelle perd un rack, un amont, un composant matériel, un chemin de support, une autorisation de facturation, une fenêtre de maintenance ou une route de migration. La capacité hébergée n'est aussi résiliente que les preuves derrière ces réponses.