Le réseau CHINANET SHAANXI province Cloud Base vend une capacité hébergée qui dépend toujours des racks, du transit et des fenêtres de maintenance

Résumé

• Le RDAP de l'APNIC listeAS134768commeCHINANET-SHAANXI-CLOUD-BASE, avec le nom descriptif CHINANET SHAANXI province Cloud Base network, pays CN, enregistrement en 2015 et un contact hostmaster Chinanet.
• La visibilité de routage actuelle est forte. L'aperçu ASde RIPEstat signale AS134768 comme annoncé, tandis que lestatut de routagede RIPEstat montre 86 préfixes IPv4, 39 préfixes IPv6 et 11 voisins observés dans la fenêtre publique vérifiée.
• La topologie est toujours dépendante du parent. Lesdonnées whoisdérivées de l'APNIC listent des importations depuis AS4134 et AS4809, mais les vues publiques actuelles des voisins de RIPEstat,bgp.tools, lapage BGPd'Hurricane Electric etIPinfoindiquent toutes AS4134, le backbone de China Telecom, comme amont visible.
• Les preuves d'adresses publiques sont mitigées d'une manière qui importe pour la capacité hébergée. De nombreux préfixes origines sont des ressources Chinanet du Shaanxi, mais les vues BGP publiques montrent également de l'espace routé décrit comme IDC et service cloud, ligne louée, Baidu, Zhejiang, Guangdong et blocs d'adresses Sichuan Xiaoteyun, donc un client ne peut pas déduire la propriété des charges de travail ou l'emplacement des racks à partir du seul numéro AS.
• Les signaux publics d'installations pointent vers une véritable base de cloud computing à Xi'an/Xixian. Un rapport de visite de l'Université du Nord-Ouest de 2025 décrit la base cloud computing Shaanxi de China Telecom comme un grand centre de cloud et big data de l'ouest de la Chine avec plus de 10 000 racks, des salles de norme T4, un PUE aussi bas que 1,25, des options de racks haute densité et un rôle dans les opérations cloud gouvernementales provinciales.
• Le niveau de preuve est Moyen, pas Fort. Le réseau est visiblement vivant et vaste, mais les sources publiques ne publient pas de carte actuelle et spécifique au produit de la propriété des racks, des alimentations électriques, du basculement amont, des tests de restauration, des limites de portabilité des données ou de l'escalade du support pour les clients achetant une capacité hébergée via ce réseau cloud base.

Une table de routage en direct n'est que la première preuve

Un fournisseur de capacité hébergée peut sembler fiable de deux manières très différentes. Une preuve est la table de routage: les routes sont visibles, les préfixes sont autorisés, les paquets ont un chemin, et l'AS apparaît sous un opérateur connu. L'autre preuve est opérationnelle: les racks ont de l'électricité, le système de refroidissement a de la marge, les hyperviseurs ont de la capacité de réserve, la copie de sauvegarde est restaurable, le support peut joindre le bon ingénieur, et le client peut déplacer les données à la fin de la relation.

Le réseau CHINANET SHAANXI province Cloud Base a une première preuve solide et une seconde preuve publique plus mince.

L'identité officielle est simple. Le RDAP de l'APNIC pourAS134768nomme l'ASCHINANET-SHAANXI-CLOUD-BASEet le décrit comme CHINANET SHAANXI province Cloud Base network. L'enregistrement le place en Chine, montre un enregistrement le 27 octobre 2015, et liste les contacts hostmaster Chinanet. Lavue whoisde RIPEstat répète le même nom et la même description d'AS, et ajoute des lignes de politique de routage important depuis AS4134 et AS4809 et exportant AS134768 vers ces réseaux. Cela suffit à traiter le réseau comme un véritable sujet de routage China Telecom Shaanxi, pas un slogan cloud vague.

L'état de routage actuel est également matériel. Lestatut de routagede RIPEstat montrait AS134768 visible pour presque tous les pairs RIS en IPv4 et IPv6 dans la fenêtre vérifiée de juillet 2026. Il comptait 86 préfixes IPv4, 39 préfixes IPv6, 184 576 adresses IPv4 et 12 576 équivalents /48 IPv6. Lavue des préfixes annoncésde RIPEstat listait 125 entrées de préfixes actuelles en IPv4 et IPv6. Lapage BGPd'Hurricane Electric rapportait une échelle similaire, avec 184 576 adresses IPv4 origines et aucune route RPKI invalide origine dans sa vue actuelle. Ce ne sont pas les signes d'un ASN dormant.

Mais une table de routage ne montre pas l'ensemble du service. Elle ne dit pas si une machine virtuelle fonctionne dans une salle appartenant à China Telecom, un rack appartenant au client dans la salle, une armoire exploitée par un partenaire, une région Tianyi Cloud, un pool cloud gouvernemental, un environnement de ligne louée ou un arrangement de colocation tiers. Elle ne révèle pas si l'espace annoncé est attaché à des serveurs de production, des passerelles périphériques, des routeurs clients, des nœuds d'hébergement, des plateformes de contenu ou des liens professionnels privés.

Elle ne dit pas à l'acheteur combien de temps il faut pour remplacer un serveur défaillant ou si une file d'attente de support surchargée peut retarder une migration.

Cette différence est la dépendance centrale de l'article. AS134768 vend l'impression d'une capacité cloud en réseau, et les preuves BGP publiques soutiennent l'existence d'un grand edge actif China Telecom Shaanxi. L'acheteur doit encore tester la couche physique et contractuelle derrière cet edge. Dans l'hébergement, la panne la plus dommageable n'est souvent pas « l'internet a disparu ».

C'est la panne plus petite et plus dure: un rack perd une alimentation et l'alimentation restante est déjà chargée, un changement amont expose une fuite de route, un pool de stockage a des sauvegardes mais pas de chemin de restauration rapide, un blocage de facturation empêche l'export pendant une migration, ou une fenêtre de maintenance est traitée comme extérieure à la promesse de disponibilité.

Ce que prouve le routage public

Le routage public prouve qu'AS134768 est visible et assez important pour être surveillé. L'aperçu ASde RIPEstat identifie le détenteur comme CHINANET-SHAANXI-CLOUD-BASE, avec le même nom descriptif utilisé par l'APNIC. Le statut de routage actuel de RIPEstat montre une large visibilité IPv4 et IPv6, pas une route marginale vue par quelques collecteurs. La même page de statut rapporte une première activité en janvier 2017 et un dernier élément le 12 juillet 2026. L'historique de routage soutient donc la continuité: l'internet public a vu cet ASN pendant des années, et il n'a pas été simplement enregistré et abandonné.

Les agrégateurs tiers s'alignent sur cette image.bgp.toolsclasse le réseau comme actif sous l'APNIC, étiquette le type de réseau comme contenu, montre le backbone China Telecom comme amont, et rapporte 75 préfixes IPv4 et 39 IPv6 origines dans sa vue visible. Lapage AS134768d'Hurricane Electric rapporte 127 préfixes origines au total, 88 IPv4 et 39 IPv6, plus 11 pairs BGP observés.IPinfodécrit l'ASN comme orienté hébergement, liste la Chine comme pays, montre des dizaines de milliers de domaines hébergés sur des adresses dans l'ASN, et nomme AS4134 comme amont dans son résumé visible.

Il y a des différences dans les compteurs car les collecteurs BGP publics utilisent différents points de vue, choix de filtrage et temps de mise à jour. RIPEstat comptait 86 préfixes IPv4 dans la vue du statut de routage, tandis que bgp.tools montrait 75 préfixes IPv4 origines et Hurricane Electric 88. Cette variation ne doit pas être surinterprétée comme une contradiction. Le signal commun est plus important que le nombre exact: AS134768 a une grande surface routée, un fort chemin parent China Telecom et un large mélange de ressources IPv4 et IPv6.

La preuve d'origine de route semble également meilleure que celle de nombreux petits réseaux d'hébergement. La validation d'origine de route de RIPEstat pour des blocs IPv4 représentatifs du Shaanxi tels que36.41.64.0/20,113.142.128.0/17et117.34.124.0/23renvoyait un statut valide pour AS134768 dans les résultats vérifiés. Il en va de même pour des échantillons de blocs cloud et réseau IPv6 tels que240e:982:4500::/40et240e:108:1140::/48. Des ROA valides ne garantissent pas la qualité du service, mais ils réduisent une classe de risque d'origine de route.

La conclusion opérationnelle n'est donc pas « réseau faible ». C'est « routage public fort, preuves client incomplètes ». Un client peut raisonnablement croire qu'AS134768 est actif. Il ne devrait pas, à partir de cela seul, croire que sa charge de travail hébergée a une protection multisite, deux chemins d'alimentation indépendants, une récupération de sauvegarde testée ou une portabilité de données facile. BGP répond à la question d'accessibilité. La capacité hébergée nécessite plusieurs autres réponses.

L'histoire de l'amont est plus étroite que ne le suggère la politique du registre

L'enregistrement whois dérivé de l'APNIC d'AS134768 nomme deux importations: AS4134 et AS4809. AS4134 est le backbone China Telecom. AS4809 est le réseau CN2 de China Telecom, souvent associé à des chemins backbone premium. Si les deux chemins transportaient activement et indépendamment les charges de travail des clients, ce serait une diversité utile. Les vues de routage publiques ne prouvent pas cette lecture plus forte.

Lavue des voisins ASNde RIPEstat montrait 11 voisins observés dans la fenêtre vérifiée. Le voisin gauche était AS4134 avec une haute visibilité en IPv4 et IPv6. Les voisins droits étaient un ensemble de réseaux 5G China Telecom Shaanxi des villes, incluant AS138387 pour Xi'an, AS138409 pour Tongchuan, AS138436 pour Baoji, AS138513 pour Weinan, AS138514 pour Xianyang et d'autres visibles principalement en IPv6. Le résumé d'IPinfo comptait également un amont,AS4134. bgp.tools présentait également AS4134 comme l'amont. Hurricane Electric montrait AS4134 comme le pair IPv4 et aussi le pair IPv6 nommé dans la table visible.

L'écart n'est pas fatal. Un grand opérateur peut conserver des enregistrements de politique de routage qui reflètent l'ingénierie interne, les chemins planifiés ou l'interconnexion privée que les collecteurs publics n'exposent pas complètement. AS4809 peut encore être important pour certains services même si AS4134 est l'amont public visible dans les vues échantillonnées. Mais un client achetant une capacité hébergée ne devrait pas traiter la ligne AS4809 dans whois comme une preuve d'un chemin de basculement vivant et affectant le client.

Le test est une preuve actuelle et spécifique au produit: quel amont transporte ce service, quel basculement vers quoi, comment la politique de route est filtrée, comment RPKI est appliqué, et si le chemin de secours a suffisamment de capacité engagée pendant les pics de charge.

C'est particulièrement important car tous les chemins visibles se situent à l'intérieur de la grande famille China Telecom. La résilience du réseau parent peut être excellente, mais ce n'est pas la même chose qu'une indépendance commerciale ou physique. Une véritable affirmation de diversité séparerait au moins quatre couches: diversité de chemin BGP, diversité d'opérateur ou de backbone, diversité de chemin physique, et capacité de réserve après basculement.

Si les deux routes dépendent de la même tranchée de fibre métropolitaine, du même commutateur central du cloud base, de la même entrée de bâtiment ou du même plan de contrôle China Telecom, la deuxième ligne AS peut ne pas protéger le client de la panne qui l'inquiète.

Le langage d'approvisionnement approprié n'est pas hostile. Un acheteur peut demander: « Pour le service que nous achetons, quel AS d'origine, quels ASN amont, préfixes, zones de disponibilité et salles de données physiques sont dans le périmètre? Quel chemin est principal? Quel chemin est testé? Quel chemin est simplement disponible pour l'opérateur ailleurs dans le réseau? » Cette distinction empêche qu'un fort réseau China Telecom soit survendu comme une résilience complète multi-fournisseur.

Le mélange de préfixes montre ensemble hébergement, accès et surfaces partenaires

La liste publique de préfixes est suffisamment large pour suggérer plus d'une surface commerciale. De nombreux préfixes visibles sont de l'espace réseau simple Chinanet Shaanxi. Le RDAP de l'APNIC pour36.41.64.0/20résout en une allocation plus large CHINANET-SN, et l'étiquette de contact administratif place le bureau de communication de données à Xi'an. Le RDAP de l'APNIC pour113.142.128.0/17résout également en une allocation CHINANET-SN. Ces blocs soutiennent le cas qu'AS134768 transporte des ressources d'adresses China Telecom Shaanxi, même si certaines descriptions héritées utilisent l'orthographe « Shanxi(SN) » de manière à confondre Shaanxi et Shanxi. Le contexte du contact Xi'an est l'ancre pratique.

D'autres ressources routées rendent la frontière opérationnelle plus compliquée. bgp.tools liste plusieurs blocs de style 103.236.0.0/22 avec des descriptions pour Sichuan Xiaoteyun Technology. Le RDAP de l'APNIC pour103.236.88.0/22identifie XIAOTEYUN comme le nom de ressource enregistré et un contact à Chengdu, Sichuan, tandis que l'aperçu du préfixede RIPEstat montre AS134768 comme l'origine actuelle dans la vue de routage vérifiée. bgp.tools montre également des préfixes décrits comme Baidu et non-Shaanxi Chinanet sous la page AS134768. La présence de ces ressources n'est pas une preuve de méfait. C'est la preuve que l'AS d'origine, le client, le détenteur de ressource et le placement des installations peuvent diverger.

Cette divergence est normale dans les grands réseaux. Un opérateur peut originer de l'espace PI client, de l'espace protégé contre les DDoS, des adresses cloud, des réseaux de lignes louées, des blocs de diffusion de contenu, des segments cloud gouvernementaux ou des allocations partenaires. Le risque pour le client est que le nom de l'AS seul ne peut pas dire à l'acheteur quel arrangement opérationnel s'applique.

Un VPS fonctionnant sur l'infrastructure cloud China Telecom n'est pas la même chose qu'un routeur client dont le préfixe est origé par AS134768, et aucun des deux n'est identique à un site web hébergé sur une adresse IP comptée par les données de domaine hébergé d'IPinfo.

IPinfoillustre pourquoi cela importe. Il rapporte plus de 23 000 domaines hébergés sur des adresses dans l'ASN et met en évidence 103.236.90.151 comme une adresse avec des milliers de domaines. C'est un signal de marché utile: l'ASN semble héberger du trafic web dense en domaines. Cela ne peut pas prouver le propriétaire contractuel de ces sites, l'emplacement des racks, la politique de sauvegarde, ou si l'adresse appartient à un revendeur, une plateforme d'hébergement partagé, une couche CDN ou un environnement géré par le client.

Pour les clients, la carte des adresses devrait faire partie de l'intégration. Quel préfixe sera attribué au service? Est-ce de l'espace China Telecom Shaanxi, de l'espace client, de l'espace partenaire ou de l'espace partagé Tianyi Cloud? Qui contrôle le reverse DNS, le traitement des abus, la création de ROA, la politique de pare-feu et le null-routage d'urgence? Si le service est migré, l'IP se déplace-t-elle avec la charge de travail ou le client reçoit-il de nouvelles adresses? Ces questions transforment une grande table de routage en une carte de dépendance réelle.

L'étiquette cloud base pointe vers une capacité physique

Les signaux publics d'installations rendent le nom « Cloud Base » plus que décoratif. Un rapport de visite de 2025 de l'École d'économie et de gestion de l'Université du Nord-Ouest décrit labase cloud computing Shaanxi de China Telecomcomme ayant commencé sa construction en 2013 et mis en service officiel en 2015. Le même rapport la décrit comme un grand centre de cloud computing et big data de l'ouest de la Chine, avec des salles informatiques de norme T4, un PUE aussi bas que 1,25, plus de 10 000 racks, des options d'armoires de 5 kW, 8 kW, 12 kW et plus refroidies par liquide, une revendication d'affichage de bande passante d'export de 22T et un rôle comme l'un des nœuds backbone IDC centraux de China Telecom. Il indique également que les étudiants ont vu le refroidissement, la distribution d'énergie, les capacités de sécurité et l'architecture cloud gouvernementale provinciale.

C'est plus fort qu'une page produit vague car cela décrit des attributs physiques: racks, densité de puissance, conception de refroidissement, protection incendie, bande passante et un rôle de campus. Cela correspond également historiquement à un rapport de 2015 de centres de données Dynamics sur labase de cloud computing de Xi'an de China Telecom, qui décrivait l'ouverture d'une base cloud dans la région ouest et notait la stratégie plus large de nœuds cloud régionaux de China Telecom. Des pages secondaires et partenaires, y compris ladescription de nœud de Fenghuoyunet unarticle de Phoenix du Shaanxi de 2018sur les services cloud Tianyi entrepreneurship, localisent également la base cloud du Shaanxi dans la nouvelle zone de Xixian, ville nouvelle de Fengxi, et discutent de la capacité IDC, cloud et colocation.

Ces descriptions publiques d'installations aident, mais elles doivent encore être lues comme un contexte au niveau de l'installation plutôt que comme une preuve spécifique au client. La page de l'Université du Nord-Ouest est un rapport de visite, pas un contrat de service. Les pages Fenghuoyun et Phoenix sont des descriptions de partenaires ou de médias, pas des audits neutres. La capacité de conception n'est pas la même que la capacité utilisable.

Un nombre de racks n'est pas une déclaration sur la disponibilité de racks vides, la marge de puissance, les commutateurs de réserve, l'inventaire matériel, les fenêtres de migration client ou la répartition actuelle entre cloud, charges de travail gouvernementales, accès internet, lignes louées et services partenaires.

La conclusion la plus utile est la spécificité physique avec une mise en garde. Les clients devraient supposer qu'il existe un campus significatif de cloud et IDC China Telecom associé à l'histoire du cloud base du Shaanxi. Ils ne devraient pas supposer que tout service routé via AS134768 est physiquement dans une salle nommée, soutenu par tout le campus, ou protégé par chaque fonctionnalité de redondance décrite dans une visite publique. Une base cloud peut héberger plusieurs environnements logiquement séparés. Certains peuvent avoir une reprise après sinistre sur deux sites. Certains peuvent être mono-zone.

Certains peuvent être des racks partenaires. Certains peuvent être des zones cloud publiques. Certains peuvent être de la colocation client.

L'acheteur devrait donc demander la déclaration de placement réelle: campus, bâtiment, classe de salle, rack ou carte de zone de disponibilité, conception d'alimentation, classe de refroidissement, chemin de cross-connect, périmètre de politique de maintenance et si le service est sur une plateforme partagée ou un rack dédié. La réponse importe plus que l'échelle totale de la base.

La capacité installée n'est pas la capacité utilisable

Le matériel public du cloud base met l'accent sur l'échelle, et l'échelle est utile. Un campus avec des milliers de racks, des options d'armoires haute densité et une grande relation avec le backbone China Telecom peut absorber plus de demande qu'un petit fournisseur hébergé dans un bureau. Il a également plus de couches où le service du client peut dépendre des choix d'allocation internes de l'opérateur.

La capacité installée est ce qui a été construit ou peut être montré dans un plan public. La capacité utilisable est ce que la charge de travail du client peut consommer sans violer les contraintes de puissance, de refroidissement, de stockage, de réseau ou de support. La capacité récupérable est ce qui reste disponible après une panne. Un nombre de racks ne dit pas grand-chose sur les deuxième et troisième catégories. Si toute la capacité haute densité de réserve est réservée aux charges de travail cloud gouvernementales, un serveur hébergé commercial peut ne pas en bénéficier.

Si le pool de stockage de sauvegarde est grand mais que la bande passante de restauration est étroite, un client peut avoir une sauvegarde sans chemin de récupération. Si la base cloud a 22T de bande passante d'export affichée mais que le niveau de produit du client est limité en débit ou mono-hébergé dans un segment de service, la bande passante principale ne définit pas le mode de défaillance du client.

La documentation publique de Tianyi Cloud elle-même renforce cette vue en couches. Lapage d'accueil Tianyi Cloudprésente la marque autour de l'intégration cloud-réseau, de la sécurité, de la personnalisation dédiée et de multiples formes de cloud, y compris les services cloud publics, privés, dédiés, hybrides, edge et full-stack. Sa documentation ECS pour lesrégions et zones de disponibilitéexplique qu'une zone de disponibilité est un ou plusieurs centres de données physiques dans une région, avec une alimentation et un réseau indépendants, et dit que l'objectif est l'isolation des pannes sauf pour les grandes catastrophes ou les pannes de courant majeures. C'est une déclaration d'architecture sensée. Cela signifie aussi que le client doit savoir si la charge de travail achetée couvre réellement plusieurs zones, ou si elle est simplement dans un pool de ressources local.

Il en va de même pour la capacité bare-metal, VPS, colocation et services gérés. Un client achetant une armoire veut de l'énergie de réserve, des mains à distance, un délai de cross-connect, du matériel de remplacement et des fenêtres de maintenance. Un client achetant des machines virtuelles veut la taille du cluster d'hyperviseurs, la réplication du stockage, l'isolation des instantanés, l'export d'images et le placement des domaines de défaillance. Un client achetant du cloud pour le secteur public veut la conformité politique, l'emplacement de la sauvegarde, les contrôles d'identité et une reprise après sinistre testée.

AS134768 peut transporter du trafic pour toutes ces surfaces, mais chacune a une définition différente de la capacité utilisable.

Le test pratique est de demander une déclaration de capacité en cas de panne. Combien de calcul, de stockage, de bande passante et de support reste-t-il si un rack, un hôte, un commutateur, une étagère de stockage, une alimentation ou une route amont tombe en panne? Le pool restant peut-il supporter la charge client normale, ou seulement maintenir les clients prioritaires en ligne? Le client doit-il acheter une deuxième zone de disponibilité ou un produit de reprise après sinistre séparé pour recevoir cette protection? Sans cette réponse, « cloud base » reste une étiquette d'installation, pas une garantie de résilience.

L'alimentation, le refroidissement et les fenêtres de réparation décident de la panne

Les pages de centres de données présentent souvent l'alimentation et le refroidissement comme une fierté technique. Les clients devraient les lire comme des déterminants de panne. Le rapport de visite de l'Université du Nord-Ouest indique que la base du Shaanxi dispose de salles de norme T4, d'un faible PUE, d'options de racks haute densité et de capacités avancées de refroidissement et de sécurité. La page Fenghuoyun décrit les systèmes d'alimentation de secours, les services de type colocation, la commutation centrale et les revendications de certification de sécurité.

Un article de Phoenix du Shaanxi de 2018 indique que la base avait une grande capacité de racks planifiée et promouvait les niveaux de service de continuité de réseau et d'énergie. Ce sont des signaux publics positifs, mais pas un substitut aux conditions de service spécifiques au client.

La redondance de puissance a plusieurs niveaux. Les alimentations utilitaires peuvent être diversifiées, mais l'appareillage peut encore être commun. Les systèmes UPS peuvent être redondants, mais la durée de la batterie peut être courte. Des générateurs peuvent être disponibles, mais la logistique de carburant, la fiabilité de démarrage du générateur et l'état de maintenance décident de l'endurance réelle. Les PDU de rack peuvent avoir des alimentations A et B, mais un client peut accidentellement brancher les deux alimentations sur un seul côté.

Un rack haute densité refroidi par liquide peut être puissant, mais il ajoute des dépendances de liquide de refroidissement et d'infrastructure qui n'existent pas pour les serveurs ordinaires à faible densité.

La redondance de refroidissement a également des niveaux. Un faible PUE est précieux, mais ce n'est pas une métrique de disponibilité. Il dit quelque chose sur l'efficacité et la conception. Il ne dit pas si une rangée donnée a suffisamment de marge de refroidissement après une défaillance d'un refroidisseur, d'une pompe ou d'une unité de traitement d'air. Il ne dit pas si les armoires haute densité refroidies par liquide peuvent continuer à fonctionner pendant la maintenance. Il ne dit pas au client si un événement de déclassement temporaire forcera le déplacement des charges de travail.

Les fenêtres de réparation sont là où le client voit la vérité. Une panne de rack peut nécessiter des mains à distance. Une panne de serveur peut nécessiter des pièces de rechange. Une panne de routage peut nécessiter un ingénieur autorisé à modifier BGP. Une panne de stockage peut nécessiter une escalade du fournisseur. Une panne d'hyperviseur peut nécessiter un espace d'évacuation. Une panne de sauvegarde peut nécessiter que quelqu'un prenne une décision de restauration alors que le service principal est en panne.

La taille de China Telecom ne supprime pas ces étapes; elle donne à l'opérateur plus de ressources pour les gérer si le processus est préparé.

Le client devrait demander le chemin d'incident en termes simples. Qui ouvre le ticket interne? Qui peut entrer dans la salle? Quelles pièces sont stockées sur site? Quels changements nécessitent une fenêtre de maintenance? Comment les clients sont-ils notifiés si la maintenance planifiée affecte un edge cloud, une alimentation, un plan de stockage ou une route IP? Le SLA exclut-il la maintenance planifiée? Quels services sont crédités et lesquels sont simplement supportés au meilleur effort? Ces détails sont moins glamour qu'un nombre de racks, mais ils déterminent si une panne devient un court événement ou une longue migration.

Les signaux de domaine hébergé nécessitent une manipulation prudente

Les comptes de domaines hébergés d'IPinfo font ressembler AS134768 à un réseau d'hébergement, et c'est une preuve de marché utile. Il rapporte plus de 23 000 domaines hébergés sur l'ASN, avec des concentrations sur un petit ensemble d'IP. bgp.tools étiquette également le type de réseau comme contenu. L'ensemble de produits publics de Tianyi Cloud comprend des hôtes cloud élastiques, des hôtes cloud d'application, des services de machine physique, du stockage, de la sauvegarde, de la reprise après sinistre et d'autres offres d'infrastructure.

Ensemble, ces signaux soutiennent la prémisse centrale: le réseau cloud base fait partie d'une surface de capacité hébergée orientée client.

Ils ne prouvent pas le service exact derrière un domaine hébergé. Un domaine peut pointer vers un hébergement partagé, une plateforme de revendeur, un pare-feu d'application, un proxy inverse, un équipement client en colocation, un serveur hérité, une application gouvernementale interne ou un client professionnel utilisant un service IP statique. La concentration d'adresses IP n'est pas la même que la concentration de comptes cloud.

Un grand nombre de domaines sur 103.236.90.151, par exemple, peut indiquer un hébergement partagé ou une adresse de plateforme, mais le RDAP de l'APNIC pour l'allocation sous-jacente 103.236.88.0/22 identifie XIAOTEYUN comme le nom de ressource enregistré. Cela rend la chaîne opérationnelle plus compliquée que « China Telecom Shaanxi possède chaque site sur l'IP ».

Cette distinction importe lors d'une panne. Si un client est sur une IP d'hébergement partagé, un incident d'abus par un autre locataire peut affecter la réputation, la délivrabilité des courriels ou le filtrage. Si un client est sur un espace d'adresse partenaire routé, les contacts d'origine de route et d'abus peuvent ne pas correspondre facilement au contrat. Si un client est sur un cloud privé virtuel avec une IP élastique, la migration peut nécessiter des changements DNS et un basculement de point d'extrémité.

Si un client est en colocation avec un routeur appartenant au client, le fournisseur peut être responsable de l'alimentation et des cross-connects mais pas du système d'exploitation ou de l'application du client.

L'article traite donc les comptes de domaines hébergés comme un signal de marché non officiel, pas une preuve de capacité finale. Ils suggèrent qu'AS134768 est utilisé pour le trafic web et d'infrastructure orienté client. Ils ne peuvent pas établir qui possède les serveurs, si les charges de travail sont sauvegardées, si la location est isolée, s'il existe un chemin de restauration testé, ou si le client peut exporter une image VM, un dump de base de données, une archive de boîte aux lettres ou un compte complet de type cPanel pendant le stress.

La preuve définitive serait une documentation produit liée au service réel: allocation d'adresse, conception d'isolation de locataire, portée de la sauvegarde et des instantanés, formats d'export, traitement des abus, contrôles DDoS, contrôle du reverse DNS, politique de réputation des courriels et support de migration. Sans ces détails, l'échelle des domaines hébergés est une raison de poser de meilleures questions, pas une raison de se détendre.

La localité des données est un argument de vente et une contrainte

Le champ région pour ce profil est CN, et les preuves publiques soutiennent une surface opérationnelle basée en Chine. L'APNIC liste l'AS en Chine. Les rapports sur la base cloud du Shaanxi placent le campus physique dans la région de Xi'an/Xixian. Les pages produits et les documents de service de Tianyi Cloud sont orientés vers la Chine. Cette présence locale peut être précieuse pour les charges de travail chinoises du secteur public, réglementées et sensibles à la latence. Elle peut également limiter la façon dont un client conçoit les sauvegardes, l'accès au support et les chemins de sortie.

L'environnement juridique chinois rend le placement des données plus qu'une préférence d'approvisionnement. La traduction de la loi sur la cybersécurité hébergée parDigiChinadécrit une exigence de localisation pour les informations personnelles et les données importantes collectées ou produites par les opérateurs d'infrastructures d'information critiques en Chine continentale. Laloi sur la sécurité des donnéesétablit un cadre national de sécurité des données. La loi sur la protection des informations personnelles, résumée par lePCPDde Hong Kong et traduite par des sources telles queChina Law Translate, ajoute des obligations de traitement des informations personnelles et de transfert transfrontalier. Les devoirs exacts dépendent du client, du type de données et de l'arrangement de service, mais la direction est claire: les règles de localisation, d'accès et de transfert comptent.

Pour les clients d'AS134768, la localité a trois dimensions pratiques. La première est la localité de production: où se trouvent réellement les points d'extrémité de calcul, de stockage et de réseau. La deuxième est la localité de sauvegarde: où sont stockés les instantanés, les archives, les répliques de reprise après sinistre et les journaux. La troisième est la localité administrative: qui peut accéder aux systèmes, d'où, sous quelle entité juridique et quel processus de support. Un service peut être hébergé localement mais utiliser une gestion à distance, des outils de sécurité externes ou une sauvegarde inter-région.

Un service peut annoncer une base cloud du Shaanxi mais fournir une reprise après sinistre dans une autre province. Cela peut être une bonne architecture, mais cela doit être explicite.

La localité des données affecte également la migration. Si un client doit partir, peut-il exporter des données vers un autre fournisseur basé en Chine, une autre région China Telecom, un système sur site ou une plateforme à l'étranger? Existe-t-il des limites légales, techniques ou contractuelles sur le transfert de journaux, d'informations personnelles, de données gouvernementales, de clés de chiffrement ou de sauvegardes? Le fournisseur prend-il en charge l'export en masse sans limitation de débit? Combien de temps après la résiliation le client conserve-t-il l'accès?

Que se passe-t-il si le compte est suspendu pour facturation alors que le client a encore besoin de récupération de données?

La lecture la plus sûre est que l'infrastructure locale en Chine est une fonctionnalité lorsque les besoins de conformité et de latence du client correspondent à la plateforme, et une contrainte lorsque le client a besoin de redondance transfrontalière ou d'une sortie rapide. La table de routage d'AS134768 ne peut pas répondre à ces questions. Seules les conditions de service et l'arrangement de traitement des données le peuvent.

Le contrat de service décide ce que le cloud ne couvre pas

Les clients cloud confondent souvent le langage de disponibilité avec une responsabilité opérationnelle complète. L'index SLAde Tianyi Cloud liste les accords de niveau de service pour les produits de calcul, de stockage, de sauvegarde et de reprise après sinistre. Sapage SLA ECSdirige les utilisateurs vers les conditions de niveau de service de l'hôte cloud élastique. Les documents produits de Tianyi Cloud distinguent également les zones de disponibilité, les types d'instances, les services GPU, les disques cloud, les produits de sauvegarde et les produits de reprise après sinistre. Cette structure dit quelque chose d'important aux clients: la résilience est assemblée à partir de services spécifiques, pas automatiquement héritée de la marque parente.

En pratique, un acheteur devrait s'attendre à des exclusions. La plupart des SLA cloud excluent la maintenance planifiée, les défaillances de configuration côté client, les problèmes de compte et de paiement, les événements de force majeure et les défaillances en dehors de la frontière de service définie par le fournisseur. Certains produits ont des crédits plutôt que des garanties de restauration. Certaines instances haute performance ou spécialisées peuvent suivre un SLA différent. Certains produits de reprise après sinistre ne protègent que les données ou la configuration sélectionnées par le client. Rien de tout cela n'est inhabituel.

C'est pourquoi la lecture de l'accord spécifique au service est importante.

Pour AS134768, la frontière contractuelle devrait être testée par rapport aux principaux chemins de défaillance. Si la route amont tombe en panne, est-ce couvert par la disponibilité du réseau ou exclu comme maintenance du backbone? Si un rack perd de l'alimentation, le client reçoit-il un crédit de service, un support de restauration, ou les deux? Si une VM gérée par le client est mal configurée après le basculement, où s'arrête la responsabilité du fournisseur? Si une action d'atténuation DDoS met en null-route l'IP d'un client, quel est le chemin d'escalade?

Si une charge de travail cloud gouvernementale a des contrôles de sécurité différents du cloud commercial, quelle équipe de support agit?

La facturation et l'état du compte méritent de l'attention. La capacité hébergée peut échouer administrativement. Une facture impayée, un retard de renouvellement de contrat, un problème de vérification d'identité réelle, un problème de dépôt de domaine, une plainte pour abus ou une inadéquation d'identité client peuvent suspendre le service ou bloquer la migration aussi efficacement qu'un routeur cassé. Les clients achetant une capacité critique devraient demander si un litige de facturation peut affecter l'exportation de données, combien de temps les données sont conservées après la suspension, et qui peut autoriser l'accès d'urgence.

Le meilleur contrat cloud rend les dépendances invisibles visibles. Il énonce la frontière de service, la métrique de disponibilité, l'avis de maintenance, la conservation des données, la responsabilité de sauvegarde, la méthode d'exportation, la sévérité du support, l'objectif de réponse et les obligations du client. Si AS134768 est la surface de routage et Tianyi Cloud ou une unité China Telecom Shaanxi est le fournisseur de services, le client a besoin à la fois des faits de routage et des faits contractuels dans le même dossier.

Principaux chemins de défaillance à tester

Le premier chemin de défaillance est la panne de rack ou d'installation. Cela inclut l'alimentation du rack, le refroidissement de rangée, les erreurs PDU, les commutateurs top-of-rack, les cross-connects, les panneaux de fibres, l'accès physique et les erreurs de maintenance. Les rapports publics sur la base cloud suggèrent une installation substantielle, mais l'échelle de l'installation ne supprime pas la défaillance locale. Les clients doivent savoir si leur service est mono-rack, mono-salle, mono-bâtiment, multi-zone ou deux sites.

Le deuxième chemin est la défaillance amont ou du backbone. Les vues publiques actuelles montrent AS4134 comme l'amont visible. La politique whois mentionne AS4809, mais les collecteurs de routes n'en font pas un chemin de basculement client prouvé. Les clients ont besoin de la carte amont active, du test de basculement, des filtres de route, de l'état RPKI et du comportement attendu si AS4134 a un problème régional ou national.

Le troisième chemin est la défaillance du stock matériel. Une plateforme hébergée peut identifier rapidement un serveur défaillant et encore attendre un remplacement. Le calcul haute densité GPU, refroidi par liquide ou spécialisé ajoute plus de risque d'inventaire. Un client devrait demander quelles pièces sont stockées localement, lesquelles nécessitent un envoi du fournisseur, et si l'opérateur peut faire une migration en direct ou restaurer sur un matériel différent pendant que les pièces sont en transit.

Le quatrième chemin est la défaillance du support. Le réseau cloud base se trouve à l'intérieur d'une grande organisation de transporteur, ce qui peut être une force si l'escalade est mature. Cela peut aussi créer un risque de transfert entre les opérations locales, les opérations du backbone, les opérations cloud, le support client, la facturation, la sécurité et les équipes partenaires. Le client devrait savoir quel bureau possède chaque type d'incident et quel niveau de gravité déclenche une escalade 24h/24.

Le cinquième chemin est la défaillance de la sauvegarde et de la restauration. Les sauvegardes qui existent mais sont lentes, incomplètes ou contrôlées par le mauvais compte ne résolvent pas une panne. Les clients devraient exiger des preuves de restauration, pas seulement des noms de produits de sauvegarde. Pour une VM, cela signifie démarrer une image restaurée. Pour une base de données, cela signifie une preuve de cohérence et de point de récupération. Pour le stockage d'objets, cela signifie le versioning, la protection contre la suppression et la séparation des comptes.

Pour la colocation, cela peut signifier que le fournisseur ne sauvegarde pas du tout les données du client.

Le sixième chemin est la défaillance de migration. Les clients quittent souvent une plateforme pendant le stress, lorsqu'une application est instable ou que l'entreprise a perdu confiance. C'est le pire moment pour découvrir que les adresses IP ne peuvent pas bouger, les images ne peuvent pas être exportées, les instantanés sont propriétaires, la bande passante est limitée, ou le support n'aidera pas tant que les factures ne sont pas réglées. La migration devrait être répétée lorsque le service est en bonne santé.

Ces tests n'exigent pas de méfiance. Ce sont des diligences raisonnables ordinaires pour tout fournisseur de capacité hébergée dont les preuves de réseau public sont plus fortes que les preuves de frontière de service public.

Ce qui améliorerait le niveau de preuve

AS134768 mérite un niveau de preuve réseau Moyen car il dispose d'un routage public solide, d'une identité officielle APNIC et d'un contexte cloud physique plausible. Pour atteindre Fort, les preuves publiques ou contractuelles devraient connecter la table de routage au service client plus directement.

La première amélioration serait une déclaration de topologie actuelle. Elle devrait nommer l'AS d'origine actif, les ASN amont, les préfixes de produit, la région et la cartographie des zones de disponibilité. Elle devrait expliquer si AS4809 est actif pour le service ou n'apparaît que dans la politique de routage. Elle devrait identifier si les charges de travail des clients utilisent l'espace China Telecom Shaanxi, l'espace partagé Tianyi Cloud, l'espace PI client ou les blocs d'adresses partenaires. Elle devrait indiquer qui maintient les ROA et qui répond aux incidents d'abus ou de fuite de route.

La deuxième amélioration serait une preuve des limites de l'installation. Les clients n'ont pas besoin d'un plan d'étage public, mais ils ont besoin de savoir si leur charge de travail se trouve dans la base cloud Xixian/Fengxi, un autre centre de données du Shaanxi, un pool régional Tianyi Cloud, un rack partenaire ou une armoire appartenant au client. La déclaration devrait inclure la classe de puissance, les hypothèses de densité de rack, la politique de fenêtre de maintenance, le plan de pièces de rechange et si le service est mono-zone ou multi-zone.

La troisième amélioration serait une preuve de récupération. Un fournisseur solide peut montrer des exercices de restauration, pas seulement des produits de sauvegarde. Il peut décrire la restauration récente de VM, la restauration de stockage, la restauration de base de données, le basculement réseau et les tests d'export client. Il peut dire quelles défaillances sont couvertes par le basculement automatique et lesquelles nécessitent un ticket manuel. Il peut également énoncer des objectifs de temps de récupération et de point de récupération réalistes par produit.

La quatrième amélioration serait une preuve de localité des données et de sortie. Le fournisseur devrait décrire l'emplacement de production, l'emplacement de sauvegarde, l'emplacement des journaux, l'accès des sous-traitants, le contrôle des clés de chiffrement, les formats d'exportation, la conservation après résiliation et les contraintes de transfert transfrontalier. Pour les charges de travail gouvernementales ou réglementées, il devrait distinguer la conformité légale de la commodité commerciale.

La cinquième amélioration serait une preuve d'incident. Une page de statut, un résumé de l'historique des incidents, un calendrier de maintenance, une matrice de sévérité du support et un modèle de rapport post-incident feraient la différence entre une grande table de routage et un service client fiable. Les grands transporteurs gardent parfois ces informations derrière des portails clients, ce qui est bien pour les clients sous contrat. L'absence publique signifie encore qu'un lecteur externe ne devrait pas le supposer.

Si ces éléments sont produits, l'histoire passe de « grande surface routée China Telecom Shaanxi en direct avec un plausible soutien d'installation cloud base » à « plateforme de capacité hébergée vérifiée avec des domaines de défaillance et des chemins de récupération connus ». C'est la différence entre l'échelle du réseau et la confiance dans l'infrastructure.

La conclusion: routes solides, résilience conditionnelle

Le réseau CHINANET SHAANXI province Cloud Base est un sujet d'infrastructure actif. L'APNIC, RIPEstat, bgp.tools, Hurricane Electric et IPinfo soutiennent tous le même fait central: AS134768 est un réseau vivant de cloud base China Telecom Shaanxi avec une empreinte substantielle IPv4 et IPv6. Les vérifications représentatives de l'origine de la route sont valides. La visibilité actuelle est élevée. Le réseau n'est pas une coquille dormante.

La mise en garde opérationnelle est tout aussi claire. Le BGP public montre l'accessibilité, pas la propriété des racks. Les enregistrements d'adresses APNIC montrent les détenteurs de ressources et les contacts, pas les charges de travail des clients. Les comptes de domaines hébergés suggèrent une utilisation web et d'hébergement, pas la qualité de la sauvegarde.

Les rapports de visite de la base cloud et les pages partenaires pointent vers un véritable campus de centres de données et cloud dans la région de Xi'an, mais ils ne disent pas à un client quel produit est mono-zone, quel est multi-zone, quel chemin utilise AS4809, quel rack a de l'énergie de réserve, ou quelle équipe de support restaure un serveur défaillant à 2 heures du matin.

Pour un acheteur, la position pratique est une confiance disciplinée. Traitez le réseau comme vivant. Traitez le contexte de la base cloud China Telecom Shaanxi comme significatif. Demandez ensuite les preuves qui décident réellement des pannes: préfixe de produit, zone de disponibilité, chemin amont, propriété ROA, alimentation du rack, marge de refroidissement, matériel de rechange, portée de la sauvegarde, preuve de restauration, escalade du support, exclusions de maintenance, règles de continuité de facturation et conditions d'exportation des données.

La capacité hébergée n'est pas en apesanteur. Dans le Shaanxi, comme ailleurs, ce sont des routeurs, des fibres, des salles d'alimentation, des boucles de refroidissement, des ports de commutation, des files d'attente de support et des contrats. AS134768 rend cette capacité visible sur l'internet. Il ne supprime pas le besoin de vérifier la chaîne physique et opérationnelle en dessous.