Rackspace IT Hosting AS IT Hosting Provider Hong Kong vend une capacité hébergée qui dépend encore des racks, du transit et des fenêtres de réparation

Résumé

• Rackspace IT Hosting AS IT Hosting Provider Hong Kong correspond à AS45187 dans les registres publics APNIC et RIPEstat. L'enregistrement RDAP d'APNIC nomme Rackspace.com Hong Kong Limited comme organisation titulaire, et RIPEstat étiquette le détenteur « RACKSPACE-AP - Rackspace IT Hosting AS IT Hosting Provider Hong Kong ».
• La surface de routage est matériellement visible. L'instantané de l'état 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, y compris 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, des alimentations doubles 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, l'optimisation de routage BGP multipath et une séparation déclaré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 chemins de sortie.

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

Certains profils d'infrastructure commencent avec un nom mince et un ASN faible. Ce n'est pas le cas ici. Le dossier public autour de Rackspace IT Hosting AS IT Hosting Provider Hong Kong est suffisamment épais pour faire passer 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. L'aperçu ASde RIPEstat utilise l'étiquette de détenteur « Rackspace IT Hosting AS IT Hosting Provider Hong Kong » et marque l'ASN comme annoncé. Cet appariement est plus solide qu'une entrée d'annuaire d'hébergement récupérée ou une page d'entreprise obsolète.

Les preuves de routage sont également suffisamment actuelles pour avoir de l'importance. 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 comprennent deux grands agrégats IPv6, 2401:1800::/32 et 2407:fa00::/32, et des routes IPv4 comme 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 vanité à un seul préfixe.

Les documents publics sur les sites de Rackspace rendent le sujet encore moins abstrait. Lapage du centre de données HKG1de Rackspace situe une installation à Hong Kong à Tsuen Wan et décrit l'alimentation électrique, le refroidissement, la sécurité, la connectivité et les garanties. Sapage HKG5situe une autre installation à Tseung Kwan O et va plus loin, en 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 jusqu'au site et l'optimisation de routage 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 l'empreinte publiée le suggère.

Cette distinction importe parce que « 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 de numéros publiques et les affirmations de Rackspace sur ses installations, mais il ne peut pas déduire quelle salle, quelle baie, 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 étayée devrait rendre l'examen plus strict, pas moins rigoureux.

AS45187 est une véritable périphérie d'exploitation, mais le registre ne montre pas tous les services

Les enregistrements APNIC et RIPEstat montrent une identité cohérente. L'enregistrement RDAP donne une date d'enregistrement en décembre 2014 et une date de dernière modification en 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 anciennes lignes de politique d'import et d'export nommant AS3491, AS1239 et AS2914, ainsi que des contacts de maintenance de routage Rackspace. Ces détails sont utiles car ils lient la ressource de numéros à l'entité Rackspace de Hong Kong et à un enregistrement d'administration de routage de longue date.

Cela ne suffit pas à définir le produit. AS45187 peut transporter 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 attribuées par le fournisseur, des interconnexions privées, des adresses de fournisseur cloud, ou des routes hybrides qui n'apparaissent pas comme origines visibles par le client. Le registre peut indiquer à un acheteur où chercher.

Il ne peut pas lui dire quel produit exact utilise la périphérie de routage, quelle entité juridique 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 de la carte de responsabilité. Si l'on dit à un client qu'une charge de travail à Hong Kong est fournie à partir de l'infrastructure Rackspace, AS45187 donne au client une frontière réseau concrète sur laquelle poser des questions. Quels préfixes sont concernés? Lesquels sont orientés client, uniquement gestion, uniquement sauvegarde 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 est défaillant. 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 différemment les routes valides, invalides et inconnues. Pour un client qui dépend d'une périphérie 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 modifications.

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

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

HKG5, décrite surRackspace Technology Data Centers: Hong Kong (HKG5), est située à Tseung Kwan O et expose un ensemble différent de spécificités. Elle 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 l'optimisation de routage BGP multipath. Elle 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, un personnel de support et des limites de contrôle. Mais elles doivent encore être converties en preuves spécifiques au service. « HKG5 a sept opérateurs » ne prouve pas en soi que chaque service client dispose de sept chemins actifs, capables par défaut, payés et provisionnés.

« L'optimisation de routage BGP multipath » ne prouve pas la diversité des routes jusqu'à l'application, le niveau 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 de support ou l'état de facturation bloque l'accès.

Les pages d'installations sont les plus solides là où elles nomment les entrées physiques. Les alimentations électriques, la capacité UPS, le carburant des générateurs, le nombre d'opérateurs et les familles de routeurs sont toutes des choses réelles 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érales.

Elles ne publient pas les affectations de baies, le placement des clients, les panneaux de brassage, les cartes de VLAN privés, 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 seraient appelés lors d'un incident. La tâche d'approvisionnement consiste à 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 des clients

L'API réseau de PeeringDB pour ASN 45187liste un objet réseau nommé Rackspace Hong Kong. Les champs montrent une politique générale ouverte, un ensemble AS IRR de AS-RACKSPACE, des comptes de préfixes indicatifs de 100 IPv4 et 10 IPv6, la prise en charge IPv6, un nombre d'IX de 2 et un nombre d'installations de 1. PeeringDB est un annuaire 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 et aux déclarations d'installations de Rackspace.

Lesenregistrements netixlan de PeeringDBlistent deux entrées opérationnelles 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 l'adresse IPv4 36.255.56.87 et l'adresse IPv6 2001:de8:7::4:5187:2. La ligne HKIX liste l'adresse IPv4 123.255.90.101 et l'adresse IPv6 2001:7fa:0:1::ca28:a065. L'enregistrement netfac de PeeringDBliste MEGA-i (iAdvantage Hong Kong) à Hong Kong comme entrée d'installation pour l'objet réseau.

Ces lignes créent une tension utile avec les pages HKG1 et HKG5 de Rackspace. Rackspace publie des pages d'installations pour Tsuen Wan et Tseung Kwan O, tandis que PeeringDB expose une entrée d'installation 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 que ce qu'il peut. PeeringDB peut décrire une présence d'interconnexion plutôt que le placement de calcul des clients.

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 périphérie, où se fait le peering d'échange, où le transit entre, 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é à 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 pendant 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 publique 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 ASN-neighboursde RIPEstat a renvoyé 23 voisins observés. La liste comprenait de grands réseaux mondiaux tels qu'AS174, AS3257, AS3300, AS3491, AS4637, AS6453, AS6939 et AS7473 du côté gauche, une ligne de 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 serveur de route d'échange, un artefact temporaire de fuite de route ou un artefact de classification côté collecteur. Il peut seulement nous dire que la périphérie de routage n'est pas invisible.

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

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 plusieurs voisins BGP dans les données publiques alors 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 forte résilience privée ou côté fournisseur qui est à peine visible dans le BGP public.

L'objectif 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 périphérie à Hong Kong? Quels amonts transportent les routes par défaut pour le service en fonctionnement normal? Quelles sessions d'échange sont du peering sans frais par rapport à l'accessibilité critique? Quels chemins sont diversifiés au niveau de l'entrée fibre et du bâtiment? Quelle quantité de trafic le chemin restant peut-il transporter en période de pointe après la suppression d'un fournisseur, 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 à tout cela tout seul.

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 le langage familier des entreprises: hébergement dédié géré, infrastructure dédiée à locataire unique, bare metal, bases de données, mise en réseau, stockage, sauvegarde gérée, reprise après sinistre, RackConnect et cloud privé. La promesse commerciale est que Rackspace convertira la complexité physique en un service. Les clients achètent la performance, le support et le contrôle sans posséder chaque routeur, alimentation électrique, baie de stockage, interconnexion et processus de maintenance.

Cet échange a une valeur réelle, mais il n'efface pas l'économie sous-jacente. Leguide de colocation clientde Rackspace décrit une facturation allouée par kilowatt pour l'alimentation critique redondante réservée, avec des frais mensuels récurrents distincts pour les interconnexions et la bande passante mixte lorsqu'elle est achetée. Il fait également référence aux frais d'installation uniques, aux circuits d'alimentation, aux cages privées, aux PDU en baie et aux interconnexions. C'est le vocabulaire de la capacité physique. La facture cloud repose toujours sur l'allocation d'énergie, l'espace en baie, les optiques, les interventions à distance, les engagements de bande passante et la main-d'œuvre.

Les pages de Hong Kong rendent cela visible. L'affirmation de 13,5 MW de puissance électrique de HKG5, sa capacité UPS de 7,2 MW 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é de baie augmente, si un client a besoin de plus d'interconnexions, si un routeur de rechange est indisponible, si un chemin opérateur est congestionné, ou si une fenêtre de maintenance nécessite un travail en série, le client ressent l'état physique par la latence, le retard de ticket, les limites de migration ou les crédits après une panne.

La capacité hébergée est achetée comme un service, mais elle échoue comme une chaîne d'étapes physiques et administratives.

C'est pourquoi il faut séparer la capacité « installée » et la capacité « utilisable ». La capacité installée est ce que l'empreinte publiée semble inclure: installations, générateurs, systèmes UPS, connexions opérateurs, routeurs, préfixes et personnel de support. La capacité utilisable est ce qui reste pour un client après la prise en compte des réservations normales, du surbooking, de la maintenance, du routage spécifique au client et des 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 la défaillance d'un 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 de 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 en fonctionnement normal: le client peut gérer sa charge de travail, tandis que le fournisseur protège la couche réseau partagée. En cas de défaillance, 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 d'administration du client peuvent ne pas suffire. Si un client peut se connecter à un serveur via un 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 l'élément limitant. Si le client a une sauvegarde mais ne peut pas déplacer suffisamment de données via le chemin disponible, le contrôle au niveau du serveur est insuffisant.

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

Le guide de colocation Rackspace renforce la même frontière. Il décrit les responsables de mise en œuvre, la formation au portail client, les demandes d'interventions à 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 24h/24, 7j/7, 365 jours par an.

Il liste également des tâches d'interventions à distance telles que le cycle d'alimentation des appareils, la vérification visuelle, le test de câbles, le remplacement de matériel fourni par le client, le montage et le démontage en baie, le câblage réseau en baie et la destruction de disque dur. Ce sont les actions concrètes qui transforment la détection de panne en réparation.

Pour un acheteur, la question du contrôle est simple: que pouvons-nous faire sans Rackspace, que peut faire Rackspace sans nous, et qu'est-ce qui nécessite que les deux parties agissent dans le bon ordre? Cette question devrait trouver une réponse avant la production. Elle devrait être écrite en étapes opérationnelles, pas seulement en langage contractuel. Quels utilisateurs du portail ont 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 tranches de 15 minutes?

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

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

Les pages de centre de données de Rackspace publient des garanties solides, mais les détails sont importants. HKG1 et HKG5 incluent toutes deux des formulations de garantie pour le réseau, l'infrastructure et le remplacement du matériel. Les sections réseau et infrastructure parlent en termes de disponibilité et de crédits, tandis que la garantie de remplacement du matériel indique 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 terme « commencer » est important.

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

Le tableau des interventions à distance du guide de colocation est plus granulaire sur le plan opérationnel. Il montre que HKG1 a à la fois un SLA de réponse de 1 heure et un SLA d'exécution de 24 heures pour les interventions à distance. Le même guide donne des temps estimés pour les tâches courantes, comme 30 minutes pour le cycle d'alimentation d'un routeur, d'un serveur ou d'un commutateur, 60 minutes par trois câbles pour le test du support de câblage, et 60 minutes pour le remplacement d'un appareil fourni par le client qui n'est pas remplaçable à chaud.

Il liste un tarif d'intervention à distance de 46,25 $ US par tranche de 15 minutes plus la nomenclature. Ce ne sont pas des détails anodins. Ils montrent où l'horloge de réparation peut passer d'un temps de disponibilité abstrait à un travail humain payé.

Un client devrait donc séparer trois horloges. Le temps de détection est le temps que prend la surveillance pour remarquer et classer un défaut. Le temps de réponse est le temps que mettent Rackspace ou le client à accepter la propriété et à commencer l'action. Le temps d'exécution est le temps que prend réellement 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 une panne sont commercialement importants, mais ils ne restaurent pas la charge de travail.

L'examen 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. Les formulations de garantie de Rackspace excluent la maintenance planifiée ou d'urgence. Cette exclusion est normale, mais elle importe dans un examen de capacité hébergée. Si un chemin ou un site est indisponible pour maintenance, la résilience réelle 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 d'administration 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 paperasserie annexe.

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 rapporté clairement la surface de routage, et PeeringDB a donné des détails d'interconnexion, mais les vérifications de validation RPKI par rapport à la liste des préfixes actuels ont renvoyé un statut inconnu plutôt que valide dans l'échantillonnage utilisé ici. Le statut inconnu peut exister pour de nombreuses raisons, notamment l'absence de ROA, la couverture des validateurs, le timing ou les choix de gestion des ressources. Cela ne signifie pas que AS45187 détourne des routes.

Cela signifie que la couche d'autorisation d'origine n'est pas aussi solide 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 ressources pour déterminer si un AS est autorisé à originer un préfixe. Le propre matériel RPKI d'APNIC explique le contrôle de 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 préfixes routés par le client ont des ROA corrects avant la migration.

La question pratique n'est pas « Rackspace connaît-il le BGP? » L'ensemble de voisins publics et les affirmations sur les installations suggèrent des opérations de routage matures. La question est plus étroite: pour les préfixes exacts qui transportent le service du client, les autorisations d'origine de route sont-elles publiées et testées avec les principaux validateurs? 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 modifications?

Si un préfixe doit être déplacé pendant un incident, qu'advient-il de l'état du ROA et du 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étails privés sur les installations. Un ROA valide ne prouve pas la résilience du client, mais il élimine un mode de défaillance évitable. Une route inconnue peut toujours 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ésolue par les lettres HK

La région de l'attribution 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 de cloud et d'hébergement géré, la localité est une matrice de placement, pas un code pays.

Le régulateur de la vie privée de Hong Kong souligne ce point dans ses orientations publiques. LeGuidance on Cloud Computingdu PCPD de janvier 2025 indique aux utilisateurs de données de prendre en compte l'emplacement de stockage des données, les mesures de sécurité dans les équipements, l'intégrité et la compétence des personnes y 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éesdu 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ù les données primaires sont stockées, où les instantanés sont stockés, où les sauvegardes sont stockées, où les journaux de gestion sont stockés, quelles équipes de support peuvent accéder à l'environnement, quels sous-traitants ou clouds partenaires participent, et si une action de support normale transfère des données personnelles en dehors de Hong Kong.

Une périphérie 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 inapproprié. Cela 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 du transfert. Une sauvegarde locale uniquement peut satisfaire une préférence de résidence mais échouer si l'installation locale subit un événement régional. Une conception multi-site à 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 pleinement 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 de Rackspace Cloud sur OpenStack Flex renvoie à 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 à partir d'un projet OpenStack Flex. Leguide de l'API Object Storageexplique que l'accès nécessite des informations d'identification Rackspace Cloud, des détails de projet et des appels d'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 de 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 de production?

La couche physique réapparaît lors de la sortie. Les exportations volumineuses consomment de la bande passante et du temps. La facturation des interconnexions, les plafonds de transit, les taux de lecture du stockage, les informations d'identification du 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 déménager » signifie en réalité « nous pouvons commencer un long transfert après que le fournisseur a approuvé la demande ». La planification de la sortie n'est pas une hostilité envers Rackspace.

C'est la fin honnête d'un examen de dépendance.

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

L'emballage corporatif est utile, mais la preuve locale l'emporte toujours

Le dossier corporatif plus large de Rackspace Technology aide à expliquer pourquoi ce profil de Hong Kong ne devrait pas être traité comme un petit hébergeur régional. Rackspace Technology, Inc. apparaît dans les soumissions à la SEC en tant que société cotée au Nasdaq sous le symbole RXT, et sonformulaire 10-K 2025donne aux investisseurs le contexte commercial et de risque plus large autour de ses opérations de cloud, d'hébergement et de services. Lapage mondiale des centres de donnéesde 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 des réseaux. Ces faits réduisent l'incertitude sur l'identité et rendent les pages des installations de Hong Kong plus crédibles qu'une page d'atterrissage autonome ne le serait.

Elles ne suppriment pas le besoin de preuves locales. Une entreprise mondiale peut encore avoir une contrainte d'installation locale, une dépendance à un fournisseur régional, 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 quelle baie, quelle route, quel système de sauvegarde et quel ingénieur décideront d'une panne un samedi.

La divulgation d'une entreprise publique peut décrire les risques commerciaux, les segments de revenus, la dette, la concurrence et les hypothèses d'exploitation. Elle ne peut 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'installations HKG1 et HKG5 de Rackspace, la documentation sur l'hébergement géré et la 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 une annexe de service locale. Elle devrait nommer l'installation ou les installations, les ASN et préfixes pertinents, le site de récupération, l'emplacement de la sauvegarde, le modèle de support, les exclusions de maintenance, le plan RPKI, les contrôles de localisation des données et le processus de sortie. Une marque mondiale peut rendre cette annexe plus facile à obtenir. Elle ne peut pas remplacer l'annexe.

Ce que les clients devraient tester avant de faire confiance à la périphérie de Hong Kong

Le premier test est la cartographie. Demandez à Rackspace de cartographier le service vers 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. Comparez la réponse sur l'ASN avec RDAP APNIC, les préfixes annoncés de RIPEstat, l'enregistrement Rackspace Hong Kong de PeeringDB et les pages HKG1/HKG5 de Rackspace. Si le service client n'utilise pas AS45187, cela peut être acceptable, mais cela devrait être clairement indiqué.

Le deuxième test est la défaillance. Supprimez un amont, un chemin d'échange, un routeur, un composant de stockage, un portail de support, une information d'identification client et un domaine de maintenance dans un exercice sur table ou en direct. Enregistrez ce qui arrive à l'accessibilité, l'accès console, le DNS, la surveillance, la sauvegarde, la facturation, les tickets et l'exportation de données. Le résultat devrait identifier quelle partie du service est actif-actif, actif-passif, sauvegarde uniquement ou manuel.

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 devrait pas être traité comme un scandale; il devrait ê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 interventions à 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, facturées ou exclues? Quelles pièces de rechange sont fournies par Rackspace, par le client ou par le fournisseur? Quel SLA d'intervention à 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 localisation des données, y compris primaire, réplique, sauvegarde, journaux, enregistrements de support et identité. Demandez des preuves d'exportation et un test de restauration chronométré. Le matériel du PCPD explique clairement pourquoi ces questions appartiennent à une discussion sur le cloud à Hong Kong: le client reste responsable du traitement des données personnelles même lorsqu'il utilise un fournisseur ou un sous-traitant cloud.

Le niveau de preuve

Rackspace IT Hosting AS IT Hosting Provider Hong Kong obtient 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 10G orientées échange 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é que cela parce que les preuves publiques s'arrêtent toujours à la frontière du client. Elles ne divulguent pas l'affectation de baie 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 du 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 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'installations Rackspace réelle et bien documentée qui nécessite toujours 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 Rackspace, deux pages de centre de données à Hong Kong, ou la surface de route AS45187 visible se substituer aux preuves de défaillance qui protègent réellement une charge de travail.

Qui ressent la défaillance

Les personnes qui ressentent en premier une défaillance d'AS45187 ou d'une installation à Hong Kong peuvent être les propriétaires d'applications, les opérateurs revendeurs, les équipes de technologie financière, les administrateurs SaaS, les détaillants en ligne, les propriétaires de bases de données, les responsables de la conformité ou les ingénieurs réseau essayant de maintenir les services clients accessibles.

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 litige de facturation à un verrouillage administratif.

L'échelle de Rackspace peut réduire certains risques. Elle a des opérations de centres de données mondiales, des SLA publiés, des installations nommées à Hong Kong, un langage de support mature et une interconnexion visible. L'échelle peut aussi cacher une 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 de matériel, mais le client a toujours besoin de 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 consiste à tester comment ces faits se comportent lorsqu'une charge de travail réelle perd une baie, 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 la preuve derrière ces réponses.