Résumé
- L'objet réseau public précis derrière le nom de l'annuaire n'est pas actuellement une extrémité de routage active.L'aperçu AS de RIPEstat pour AS203301identifie le titulaire comme centres de données Cloud 9 Ltd., mais marque l'ASN comme non annoncé le 12 juillet 2026, etle statut de routage RIPEstatn'affiche aucun espace IPv4 ou IPv6 annoncé.
- La même organisation Cloud 9 Ltd. émet un signal opérationnel bien plus fort via AS57814.Le statut de routage RIPEstat pour AS57814montre l'ASN annoncé avec 27 préfixes IPv4, 3 préfixes IPv6 et 12 voisins observés, tandis quele texte du registre RIPElie AS57814 à ORG-CL434-RIPE, l'organisation Cloud 9 Ltd.
- Le site public Cloud9 commercialise un centre de données neutre vis-à-vis des opérateurs basé à Tbilissi, de la colocation, des VPS, des VDS, des serveurs dédiés, des domaines et de l'hébergement partagé. Sa proprepage centre de donnéesindique que la plupart des services sont fournis depuis son installation de Tbilissi et liste des revendications d'alimentation, de refroidissement, de suppression d'incendie, de sécurité et d'interconnexion.
- Les revendications de résilience physique sont inhabituellement précises mais restent des revendications orientées client. Cloud9 indique que l'installation utilise trois sous-stations électriques indépendantes, un générateur diesel de 630 KVA, une alimentation N+N pour la zone de colocation, un refroidissement DX, une suppression d'incendie Novec 1230, un accès planifié à l'installation et une couverture d'ingénierie 24h/24 et 7j/7; les clients ont toujours besoin de preuves d'historique de maintenance, de temps de fonctionnement du générateur, de basculement de refroidissement et de restauration.
- La note de preuve est Moyenne. Il existe de véritables preuves d'installation Cloud 9 Ltd. et de routage AS57814, ainsi que des entrées PeeringDB pour Cloud9 Dinamo Arena et IXP.ge, mais l'objet exact AS203301 est silencieux et le matériel public ne prouve pas la capacité auditée, le fonctionnement dual actif des services publics, la diversité des chemins opérateurs, la marge de puissance disponible ou les résultats de basculement client.
L'entreprise est visible, mais l'ASN de centre de données attribué est silencieux
Le premier test pour centres de données Cloud 9 Ltd. n'est pas de savoir si la marque a un site web. Il s'agit de déterminer si l'identité réseau publique exacte associée au sujet de l'annuaire est opérationnelle aujourd'hui. Sur cette question, la réponse est un déclassement.L'aperçu AS de RIPEstat pour AS203301indique que le titulaire est centres de données Cloud 9 Ltd. et montre l'ASN comme attribué, mais il signale également que l'ASN n'est pas annoncé.Le statut de routage RIPEstat pour AS203301n'affiche aucun préfixe IPv4 annoncé, aucun préfixe IPv6 annoncé et aucun voisin observé dans la vue du 12 juillet 2026.
Ce n'est pas une note de bas de page mineure. Si une fiche d'annuaire, une table de routage, une note d'approvisionnement ou une note client traite AS203301 comme le bord public actuel d'un service de centre de données, les preuves actuelles ne soutiennent pas ce traitement.Les préfixes annoncés RIPEstat pour AS203301renvoient une liste actuelle vide.L'historique de routage de RIPEstatmontre que AS203301 a précédemment annoncé 185.139.56.0/22 de 2016 jusqu'en octobre 2023, donc l'ASN n'a pas toujours été inerte. Mais une route historique n'est pas une capacité client utilisable en 2026. C'est une preuve d'opération antérieure, pas de service présent.
Le point le plus intéressant est que l'AS203301 silencieux ne fait pas disparaître Cloud 9 Ltd. Il impose une séparation entre un ASN de centre de données attribué et le réseau actuel plus large de l'opérateur.L'aperçu AS de RIPEstat pour AS57814identifie AS57814 comme Cloud9 Cloud 9 Ltd. et le marque comme annoncé.Le statut de routage RIPEstat pour AS57814indique 27 préfixes IPv4, 3 préfixes IPv6 et une visibilité complète des collecteurs de routes dans la vue vérifiée.Les données dérivées du registre RIPE pour AS57814lient l'ASN à ORG-CL434-RIPE, le même identifiant d'organisation Cloud 9 Ltd. visible dansl'enregistrement d'organisation de RIPE.
La lecture responsable n'est donc ni un rejet ni une confiance aveugle. AS203301 ne doit pas être traité comme un bord actif sans preuve récente. AS57814 montre que l'opération Cloud9 a une empreinte routée réelle. Un client évaluant la colocation, les VPS ou les serveurs dédiés devrait demander quels ASN et préfixes acheminent le service acheté, si AS203301 a été retiré, réservé ou réaffecté, et si un service orienté client dépend encore de son ancien plan de route. La distinction est importante car l'identité réseau n'est pas l'image de marque. C'est le chemin par lequel les systèmes clients joignables survivent à une panne.
L'installation commercialisée est un ancrage unique à Tbilissi
La position publique de Cloud9 est directe: sapage centre de donnéesprésente l'entreprise comme un opérateur de centre de données neutre vis-à-vis des opérateurs en Géorgie et indique que la plupart des services Cloud9 sont fournis depuis son centre de données situé à Tbilissi. Le pied de page et lapage de contactindiquent l'emplacement opérationnel au 2 Akaki Tsereteli Avenue, Dinamo Stadium, Gate 5, Tbilissi, Géorgie 0112.L'enregistrement d'installation PeeringDB pour Cloud9 Dinamo Arenaplace également une installation nommée Cloud9 Dinamo Arena au A. Tsereteli Ave 2 à Tbilissi, avec Cloud9 LTD comme organisation et des contacts de support par e-mail.
C'est mieux qu'une page cloud vague sans lieu attaché. L'empreinte publique donne à un acheteur une question à poser au niveau du bâtiment. Le problème est que l'adresse d'un bâtiment n'est pas la même chose qu'une carte complète des capacités.
Cloud9 peut crédiblement pointer vers une installation à Tbilissi, mais le matériel public ne divulgue pas le nombre de salles, les baies actives, les baies de réserve, la consommation électrique, la réserve de refroidissement, les contrats de carburant, le temps de fonctionnement du générateur sous charge mesurée, la diversité des entrées des opérateurs ou la quantité de capacité client qui reste après la défaillance d'un composant.
Le site de Cloud9 relie également plusieurs services à cet ancrage physique. Sapage de colocationvend des configurations 1U, 2U, serveur tour, demi-baie, baie complète et cage. Sapage VPSvend des serveurs privés virtuels gérés et autogérés. Sapage VDSvend des tranches virtuelles plus grandes, et sapage de serveurs dédiésvend des serveurs physiques. Lesconditions généralesde l'entreprise listent l'hébergement, la colocation, les services de centre de données, la location de baies, les interconnexions, les unités de distribution d'alimentation et l'interconnexion avec les fournisseurs d'accès Internet parmi les services offerts.
Cette ampleur de produits augmente les enjeux. Une panne à l'ancrage de Tbilissi peut affecter les clients de différentes manières: un client de colocation peut posséder le matériel défaillant mais dépendre de Cloud9 pour l'alimentation, le refroidissement, l'accès et les interconnexions; un client VPS peut dépendre de Cloud9 pour le serveur, le stockage, la plateforme de virtualisation et les sauvegardes; un client de serveur dédié peut dépendre de Cloud9 pour le remplacement du serveur, l'accès à distance et la continuité du réseau.
La même panne peut donc ressembler à un événement d'alimentation, un événement de refroidissement, un événement de routage ou un événement de support selon le contrat du client.
Les preuves de localisation sont suffisamment solides pour rendre l'analyse concrète. Elles ne suffisent pas à rendre le service résilient en soi. L'acheteur doit encore savoir si l'installation de Tbilissi est le seul site de production actif pour le service acheté, si les sauvegardes quittent le site, si le basculement utilise un autre emplacement Cloud9 ou seulement un autre cluster dans le même bâtiment, et si les contrats clients distinguent « disponible à la vente » de « utilisable après une panne ».
Les revendications d'alimentation sont précises, mais le temps de fonctionnement reste le test
Les revendications publiques d'alimentation de Cloud9 sont inhabituellement précises pour un fournisseur d'hébergement régional. Lapage centre de donnéesindique que l'installation est alimentée par trois sous-stations électriques indépendantes et dispose d'un générateur diesel de 630 KVA. La même page précise que la zone de colocation utilise une alimentation redondante N+N avec support UPS. Lapage de colocationrépète la promesse en termes orientés client: les forfaits de baie listent une alimentation double A/B pour les serveurs 1U et 2U, tandis que le service de serveur tour est listé avec une alimentation simple.
Ces détails sont utiles car ils créent des questions mesurables. Trois sous-stations peuvent réduire la concentration des services publics, mais cette phrase ne révèle pas si les alimentations sont simultanément actives, si elles entrent dans le bâtiment par des chemins physiquement séparés, si l'appareillage de commutation présente un point de défaillance unique, si la maintenance peut être effectuée sans exposer les clients, ou si toutes les baies de colocation peuvent tirer leur charge contractuelle pendant un événement sur les services publics.
Un générateur de 630 KVA est un équipement sérieux, mais le chiffre pertinent n'est pas la puissance nominale de la plaque. C'est le temps de fonctionnement testé et le profil de charge après le transfert de l'UPS, la livraison de carburant, la demande de refroidissement et les charges non informatiques du bâtiment incluses.
L'alimentation N+N est également une revendication qui nécessite une preuve au niveau de la baie. Si les deux côtés d'une baie à double alimentation sont véritablement indépendants, une défaillance d'une seule alimentation ne devrait pas arrêter l'équipement client à double cordon.
Mais de nombreuses pannes clients se produisent à la limite d'un plan d'alimentation bien conçu: un appareil à cordon unique connecté via la mauvaise unité de distribution d'alimentation, un côté A surchargé pendant la maintenance, un déclenchement de disjoncteur causé par une pointe de consommation client, un test de générateur qui n'inclut pas la charge réelle, ou une tâche à distance qui laisse un câble dans le mauvais chemin. Le matériel public de Cloud9 ne montre pas à quelle fréquence le basculement est testé ni comment les clients reçoivent les preuves.
Le forfait serveur tour est important car il utilise ouvertement une alimentation simple. Ce n'est pas un défaut; c'est un niveau de service. Cela signifie que les clients ne peuvent pas déduire une résilience électrique à l'échelle du centre de données d'un produit qui peut utiliser un seul chemin électrique au niveau du dispositif. L'acheteur doit faire correspondre la criticité de la charge de travail à la conception de l'équipement. Un serveur non critique peut rationnellement accepter un chemin d'alimentation unique.
Un système de production qui doit survivre à une panne d'alimentation nécessite un équipement à double cordon, une distribution A/B testée, suffisamment de marge de puissance disponible et un contrat qui explique ce que Cloud9 fera pendant la maintenance.
La plus grande question d'alimentation n'est pas de savoir si la page marketing nomme des composants. C'est de savoir si Cloud9 peut fournir des preuves récentes et pertinentes pour le client: dernier test de charge complet du générateur, dates des tests de transfert, fenêtres de maintenance de l'UPS, disposition de l'approvisionnement en carburant, densité de baie maximale supportée, charge réelle des clients et historique des incidents. Sans ces preuves, l'installation peut encore être bonne, mais l'acheteur se fie à une promesse plutôt qu'à un état de défaillance démontré.
Refroidissement, protection incendie et sécurité réduisent les chemins de défaillance possibles
La page d'installation offre un ensemble comparable de revendications pour le refroidissement, la protection incendie et la sécurité physique. Cloud9 indique que la température et l'humidité sont contrôlées par un système de refroidissement DX. Il précise que les salles de serveurs n'ont ni fenêtres ni murs donnant sur l'extérieur, et que la plomberie à proximité se limite au système de suppression d'incendie. Il indique également que le centre de données utilise une détection précoce de la température, de la fumée et du feu, plus un système de suppression d'incendie Novec 1230.
Pour le contrôle d'accès, la page mentionne la vidéosurveillance, les contrôles biométriques, un bâtiment aux normes sismiques et des locaux surveillés.
Ces revendications sont importantes car une panne de centre de données n'est souvent pas une pure panne de courant. Le refroidissement peut devenir la contrainte principale lors d'un événement sur le réseau électrique, un événement de générateur ou un déploiement de baies à haute densité. Si la capacité d'air refroidi, la gestion du flux d'air ou la redondance des compresseurs sont faibles, les serveurs peuvent manquer de marge thermique même lorsque l'alimentation reste disponible.
Le refroidissement DX peut être un choix de conception parfaitement valable, mais le client doit connaître le nombre d'unités, le modèle de redondance, les pratiques de maintenance, la disponibilité des pièces de rechange et la capacité d'élimination de la chaleur à la densité de baie contractuelle.
La protection incendie a également une limite stricte. La présence d'un système de suppression d'incendie à base de gaz n'est rassurante que si la détection, le zonage, le maintien de la pression, la réponse du personnel et la communication client sont à jour. Une décharge intempestive peut interrompre le service. Un véritable incendie peut rendre l'accès impossible même si l'équipement n'est pas détruit. Les dommages causés par la fumée ou la chaleur peuvent laisser l'équipement client dans un état incertain. La revendication publique montre une couche de protection prévue, pas le chemin de récupération testé après une alarme.
La sécurité présente une distinction similaire. La biométrie, la vidéosurveillance et les gardes réduisent le risque d'accès non autorisé. Ils ne répondent pas à qui peut entrer pendant une urgence, comment l'accès client est approuvé, à quelle vitesse une tâche à distance peut être effectuée, ou si l'accès à l'installation reste disponible pendant une perturbation à l'échelle de la ville. LaFAQ de colocation de Cloud9indique que les visites des clients doivent être planifiées et que les visiteurs doivent avoir une pièce d'identité valide. Les conditions indiquent que les clients de colocation peuvent demander un accès 24h/24 et 7j/7 sur accord préalable via le compte client ou par e-mail. Ces règles sont sensées, mais elles signifient également que l'accès est médié par le support et le personnel de l'installation de Cloud9.
C'est pourquoi l'infrastructure physique doit être lue comme un système. L'alimentation, le refroidissement, la protection incendie, le contrôle d'accès et le travail de support ne sont pas des cases marketing indépendantes. Une unité de refroidissement défaillante peut nécessiter des travaux électriques. Un événement électrique peut augmenter la charge de refroidissement. Une alarme incendie peut suspendre l'accès. Une règle de sécurité peut ralentir la réparation.
Un client devrait demander à Cloud9 le scénario combiné: que se passe-t-il si une alimentation électrique tombe en panne pendant qu'un composant de refroidissement est en maintenance, ou si un serveur client nécessite une intervention manuelle pendant une restriction d'accès à l'installation?
La neutralité vis-à-vis des opérateurs doit signifier plus qu'une simple liste d'opérateurs
Cloud9 utilise l'expression neutre vis-à-vis des opérateurs sur sapage centre de donnéeset indique être également un opérateur IXP. La même page indique que Cloud9 est connecté aux principaux opérateurs de télécommunications et aux petits FAI via de la fibre noire réservée avec plusieurs itinéraires alternatifs et une capacité d'interconnexion totale de 250 Gbps. Lapage de colocationindique que des connexions directes en fibre vers les principaux FAI locaux aident à fournir une accessibilité locale à faible latence.
Les preuves de routage apportent un soutien partiel à l'histoire d'interconnexion.Les voisins ASN RIPEstat pour AS57814montrent 12 voisins observés dans la vue vérifiée, y compris des réseaux géorgiens tels que Magticom, Caucasus Online, System Net, Silknet et Skytel, ainsi que d'autres réseaux adjacents et IXP.ge.Le profil réseau AS57814 de PeeringDBliste Cloud9 comme un réseau de services réseau régional avec support IPv6, politique de peering ouverte, une installation et une présence d'échange.L'entrée netixlan de Cloud9 sur PeeringDBmontre une connexion de 10 Gbps à IXP.ge.
Ce sont des signaux significatifs. Ils ne suffisent pas non plus à prouver la diversité des chemins opérateurs. Les collecteurs de routes peuvent montrer les ASN adjacents, mais ils ne peuvent pas montrer si les différents opérateurs entrent par des conduits séparés, si les interconnexions partagent une salle de rencontre, si un opérateur amont domine l'accessibilité internationale, si les pairs locaux acheminent le trafic de production pendant une panne amont, ou si les contrats clients incluent une quelconque garantie de diversité de route. Un réseau peut avoir plusieurs voisins logiques tout en partageant un chemin physique vulnérable.
La politique de route publique d'AS57814 dansles données dérivées du registre RIPEnomme plusieurs ASN amont ou adjacents dans les déclarations d'import et d'export. L'enregistrement exact d'AS203301 est plus étroit:les données dérivées du registre RIPE pour AS203301listent des déclarations de politique impliquant AS34797 et AS35076, tandis que le statut de route actuel ne montre aucune annonce active. Cette différence est une autre raison de demander quel plan de route s'applique à un service client donné.
La revendication de neutralité vis-à-vis des opérateurs est donc plausible mais incomplète. Un client devrait demander les opérateurs amont actuels, les accords de peering publics et privés, les options d'interconnexion, les chemins physiques de point de rencontre, les engagements de préavis de maintenance, les pratiques de sécurité de routage et les résultats de basculement mesurés. L'expression « neutre vis-à-vis des opérateurs » devrait signifier qu'un client peut faire de véritables choix parmi les opérateurs et les routes.
Cela ne devrait pas simplement signifier que l'installation est disposée à vendre une interconnexion si le client peut en organiser une.
AS57814 montre une ampleur qu'AS203301 n'a pas
La preuve réseau actuelle la plus solide est AS57814, pas AS203301. Dans la vue RIPEstat du 12 juillet 2026, AS57814 a une large empreinte pour un opérateur régional d'hébergement et de centre de données en Géorgie: 27 préfixes IPv4, 3 préfixes IPv6 et une visibilité complète depuis les pairs RIPE RIS dans les deux familles d'adresses.Les préfixes annoncés RIPEstat pour AS57814incluent des routes IPv4 telles que 188.93.94.0/24, 185.139.56.0/24, 185.139.57.0/24, 185.139.58.0/24, 45.138.44.0/22 et plusieurs autres /24, plus de l'espace IPv6 incluant 2a0d:8a00::/32.
Cette ampleur change la conclusion de l'article. Si seulement AS203301 existait, la note de preuve serait faible ou négative pour le routage actuel. AS57814 empêche cela. Il montre un réseau Cloud 9 Ltd. actif avec IPv4 et IPv6, plusieurs voisins et un support actuel de sécurité de routage.La validation RPKI RIPEstat pour 188.93.94.0/24 sous AS57814renvoie valide, et il en va de même pour les /24 Cloud9 vérifiés découpés dans l'ancien espace 185.139.56.0/22.
Le contraste avec AS203301 est net.L'aperçu de préfixe RIPEstat pour 185.139.56.0/22montre l'agrégat lui-même non annoncé, avec les /24 associés maintenant visibles.La cohérence de routage de préfixe RIPEstat pour 185.139.56.0/22montre 185.139.56.0/24, 185.139.57.0/24 et 185.139.58.0/24 en BGP actif sous AS57814, tandis que l'objet de route /22 n'est pas actif.La validation RPKI RIPEstat pour AS203301 et 185.139.56.0/22renvoie un résultat invalid-asn car l'autorisation de route dans la vue vérifiée pointe vers AS57814, pas AS203301.
Cela ne signifie pas que Cloud9 fait du mauvais routage. Cela signifie que l'autorité de route active semble être passée à AS57814. Pour un acheteur, c'est un problème de documentation et un problème de résilience. Les contrats, les descriptions de service et les guides d'incident doivent nommer l'ASN qui achemine effectivement le trafic de service. Si AS203301 est conservé comme objet de centre de données dormant ou hérité, Cloud9 devrait être clair à ce sujet. S'il est prévu qu'il revienne, l'autorisation d'origine de route et la politique de route devraient être modifiées avant que le trafic client n'en dépende.
IXP.ge améliore le récit local mais n'élimine pas le risque international
La revendication d'interconnexion de Cloud9 est aidée par les preuves d'IXP.ge.L'enregistrement IXP.ge de PeeringDBidentifie IXP.ge, également connu sous le nom de Geo-IX, à Tbilissi et note que l'échange est disponible à Tbilissi et Kutaisi.La page à propos d'IXP.gedécrit l'objectif de l'association d'échange comme l'échange direct de trafic Internet entre les réseaux géorgiens sans utiliser de réseaux tiers.La page des membres d'IXP.geliste Cloud9 parmi les membres à part entière.
C'est positif pour l'accessibilité locale. Lorsque les FAI locaux, les fournisseurs d'hébergement et les réseaux de services échangent du trafic localement, le trafic domestique peut éviter les détours inutiles via le transit étranger. Une latence plus faible et une moindre dépendance à un seul chemin étranger peuvent être importantes pour les clients géorgiens, le contenu, les services destinés au gouvernement et les petites entreprises qui servent principalement des utilisateurs à l'intérieur du pays. Cela correspond également à l'affirmation de Cloud9 selon laquelle la connectivité locale est un différenciateur.
La participation à un IXP ne doit pas être confondue avec une redondance complète. Le peering à un échange peut réduire la charge sur le transit amont et améliorer les chemins locaux, mais il ne protège pas automatiquement un client contre une panne d'alimentation de l'installation, une panne de commutateur, un problème de serveur de route, une rupture de fibre, une congestion internationale ou des pannes DNS et de couche applicative. PeeringDB liste le port IXP.ge de Cloud9 à 10 Gbps dans l'enregistrement vérifié; la page centre de données de Cloud9 annonce séparément 250 Gbps de capacité d'interconnexion totale.
Ces deux chiffres peuvent tous deux être vrais si ce dernier inclut des interconnexions privées, des amonts et d'autres capacités locales. Les registres publics ne réconcilient pas la composition.
La question la plus pertinente est de savoir quels chemins acheminent quel trafic lorsque quelque chose se casse. Si le principal amont international tombe en panne, combien de trafic passe à d'autres amonts et avec quelle qualité? Si le port IXP tombe en panne, les utilisateurs locaux restent-ils joignables via le transit? Si une route de fibre vers Dinamo Arena est endommagée, les itinéraires alternatifs sont-ils véritablement séparés? Si un client achète une interconnexion, est-elle sur un chemin diversifié des liens amont propres de Cloud9 ou dans le même faisceau physique?
Le matériel public de Cloud9 donne à l'acheteur de quoi poser de bonnes questions. Il ne fournit pas assez pour traiter le peering local comme une reprise après sinistre. La meilleure version du service combinerait un bord AS57814 actif, le trafic local IXP.ge, plusieurs amonts indépendants, une hygiène de sécurité de routage visible et des options d'ingénierie de trafic client claires. Le registre public soutient une partie de ce tableau. Il laisse le chemin physique et les tests de basculement à prouver.
Les offres de colocation révèlent où la capacité utilisable peut se réduire
Le menu de colocation de Cloud9 est inhabituellement transparent sur le forfait de base. Lapage de colocationliste les forfaits de baie 1U et 2U avec alimentation double A/B, lien 1 Gbps et un lien de gestion séparé. Elle liste également une option de serveur tour avec alimentation simple. La page indique que chaque client reçoit une connectivité illimitée de 1 Gbps vers les FAI géorgiens et une connectivité globale de 30 Mbps, et elle décrit les options de demi-baie, baie complète et cage comme des arrangements personnalisés ou d'entreprise.
Ces chiffres ne sont pas que des prix. Ils définissent la contrainte visible par le client. La connectivité locale peut être abondante par rapport à de nombreuses petites charges de travail, tandis que la connectivité globale par client de colocation de base est limitée. Un client géorgien servant principalement des utilisateurs domestiques peut trouver cela acceptable. Une entreprise servant des utilisateurs internationaux, des travailleurs à distance, des API transfrontalières ou des sauvegardes mondiales devrait tester soigneusement le chemin global.
Trente mégabits par seconde peuvent être suffisants pour la gestion, les petits sites ou les services à faible trafic, mais ce n'est pas une revendication générale de capacité cloud.
La distinction entre capacité installée et capacité utilisable est importante ici. Une installation peut annoncer une interconnexion agrégée élevée tandis que les produits individuels sont vendus avec des allocations globales plus étroites. Une baie peut avoir une alimentation double tandis que le propre serveur du client n'a qu'une seule alimentation. Un lien de gestion peut être disponible tandis qu'un système d'exploitation défaillant nécessite encore une action humaine. Une cage peut être personnalisée tandis que les ressources partagées de l'installation, la planification de l'accès et la capacité du générateur restent communes.
La FAQ de Cloud9 est utile car elle énonce les limites. Pour la colocation, la panne matérielle reste la responsabilité du client, tandis que Cloud9 dit qu'il aidera à la réparation. Les visites doivent être planifiées. Les installations de baie complète et de cage peuvent prendre plus de temps qu'une installation de serveur unique. Ce sont des conditions normales, mais elles signifient que la récupération est partagée. Un client ne peut pas externaliser chaque panne simplement en plaçant de l'équipement dans l'installation.
Le client devrait donc demander un tableau de résilience produit par produit. Pour le service 1U et 2U, que se passe-t-il si une alimentation tombe en panne? Pour le service tour, une redondance d'alimentation simple est-elle disponible via un commutateur de transfert automatique? Pour les demi-baies, quelle densité de puissance est incluse? Pour les cages, quelles options d'opérateur sont physiquement atteignables? Pour tous les types de service, combien de capacité globale reste disponible pendant la maintenance ou la panne amont? Les tableaux de forfaits publics sont un point de départ utile, pas la réponse finale.
Les VPS, VDS et serveurs dédiés transforment les revendications d'installation en engagements clients
Les produits de serveurs hébergés ajoutent une autre couche. Lapage VPSde Cloud9 propose des forfaits gérés et autogérés avec virtualisation KVM, sauvegardes quotidiennes, options de panneau de contrôle et vitesses réseau locales et globales annoncées. Lapage VDSpropose des serveurs virtuels à ressources fixes plus grands. Lapage de serveurs dédiésliste des forfaits gérés et autogérés, indique que les serveurs peuvent être configurés dans les 24 à 48 heures lorsqu'ils sont disponibles en stock, et décrit des disques de qualité entreprise, des connexions réseau redondantes et des alimentations redondantes.
Ces revendications déplacent le risque d'une question purement d'installation à une question d'exploitation. Pour les clients VPS et VDS, Cloud9 contrôle l'hôte, le stockage, la couche de virtualisation, le système de sauvegarde, l'allocation IP, le panneau de contrôle et le canal de support. Un client peut ne pas savoir quel serveur physique ou quelle baie supporte la charge de travail. La preuve de résilience doit donc inclure des tests de restauration de sauvegarde, la réponse à la panne de l'hôte, l'isolation du stockage, la surveillance, la communication client et la capacité de déplacer un serveur virtuel sans longue panne.
Les sauvegardes quotidiennes sont utiles, mais une revendication de sauvegarde n'est pas une revendication de récupération tant que le temps de restauration n'est pas connu. Un petit site web peut tolérer une restauration le lendemain. Un portail commercial ou un service transactionnel peut ne pas le tolérer. Les sauvegardes ont également besoin de détails de placement. Si les sauvegardes résident dans la même installation, elles peuvent protéger contre la suppression de fichiers et la panne de serveur mais pas contre un incident à l'échelle de l'installation.
Si les sauvegardes quittent l'installation, l'acheteur doit savoir où elles vont, comment elles sont chiffrées, à quelle vitesse elles peuvent être restaurées et ce qui se passe lorsque le client quitte.
Les serveurs dédiés créent une charge différente. Cloud9 indique que la disponibilité du processeur dépend du stock, et que les exigences personnalisées peuvent ajouter du temps d'installation. C'est normal, mais cela compte pendant une panne. Si un serveur dédié tombe en panne, y a-t-il un rechange à chaud, un remplacement le jour même, ou seulement un stock au mieux? Si un disque tombe en panne, qui le remplace et à quelle vitesse? Si un client autogère le serveur, où s'arrête la responsabilité de Cloud9?
Si des alimentations et des connexions réseau redondantes sont présentes, sont-elles connectées à des chemins d'installation indépendants?
La question centrale de l'article n'est donc pas de savoir si Cloud9 vend des produits hébergés. Il le fait clairement. La question est de savoir si la capacité commercialisée peut être transformée en un résultat de récupération testé pour chaque produit. Les clients VPS, VDS, serveurs dédiés et colocation achètent différentes parties de la pile. Ils devraient recevoir des preuves de résilience différentes.
Les conditions générales divulguent une frontière de maintenance et d'accès
Lesconditions générales de Cloud9sont importantes car elles divulguent des parties de la frontière opérationnelle que les pages marketing ne montrent pas. Les conditions nomment Cloud 9 LLC, donnent l'ID d'entreprise 405063755, indiquent une adresse légale en Géorgie et listent les catégories de produits offertes via le site et le portail Cloud9. Elles définissent les services de centre de données comme incluant la location de baies de télécommunications, les interconnexions, les unités de distribution d'alimentation, l'interconnexion avec les fournisseurs d'accès Internet et les opérateurs mobiles, et la location d'adresses IP.
Pour la colocation, les conditions indiquent que les clients doivent réserver l'accès à l'installation via le compte client ou par e-mail, fournir les détails des visiteurs et suivre les règles de conduite du centre de données. Elles indiquent également que les clients peuvent demander un accès 24h/24 et 7j/7 sur accord préalable et peuvent demander un service à distance 24h/24 et 7j/7 pour des tâches telles que le redémarrage ou le remplacement de câbles. Ce sont des engagements précieux, mais ils dépendent toujours de la disponibilité du personnel, du traitement des tickets et des conditions de l'installation au moment de l'incident.
La déclaration de maintenance la plus importante est que Cloud9 est autorisé à effectuer des travaux techniques planifiés pour le service de colocation, avec une durée ne dépassant pas huit heures. Cette clause ne doit pas être lue comme une garantie de disponibilité, mais c'est une frontière opérationnelle sérieuse. Si un client a besoin d'un service continu, il doit comprendre si les travaux planifiés peuvent affecter une alimentation, un routeur, un chemin de point de rencontre, une cage client ou le service complet.
Il doit également comprendre combien de préavis est donné, si les clients redondants peuvent éviter l'impact et comment les travaux d'urgence diffèrent des travaux planifiés.
Les conditions promettent également un support technique 24h/24 et 7j/7 par e-mail, et lapage de contactindique que l'e-mail ouvre un ticket. C'est utile pour les opérations de service, mais le support par e-mail peut être fragile pendant les incidents si le système de messagerie du client est hébergé chez le même fournisseur ou si le portail est affecté. Un client sérieux devrait garder un chemin de contact hors bande et savoir si le support peut agir lorsque l'identité du client, la facturation ou l'accès au portail est altéré.
Les contrats portent souvent la vraie réponse au risque d'infrastructure. Les pages marketing décrivent ce que l'opérateur veut vendre. Les conditions décrivent où la responsabilité est partagée, limitée ou planifiée. Dans le cas de Cloud9, les conditions ne sapent pas le récit du centre de données; elles le rendent plus concret. Elles montrent que l'accès client, les interventions à distance, les travaux planifiés, les sauvegardes et le support font partie de la frontière de service. Le travail de l'acheteur est de convertir ces clauses en engagements opérationnels mesurables.
La situation de la sécurité du routage est meilleure sur le bord actif
La sécurité du routage est un domaine où le bord Cloud9 actif semble meilleur que l'ASN dormant.La validation RPKI RIPEstat pour 188.93.94.0/24 annoncé par AS57814renvoie valide. Les préfixes Cloud9 vérifiés 185.139.56.0/24, 185.139.57.0/24, 185.139.58.0/24, 45.138.44.0/22 et 2a0d:8a00::/32 renvoient également valide lorsqu'ils sont testés contre AS57814. C'est un signal d'hygiène positif pour les routes que les clients sont plus susceptibles de voir aujourd'hui.
L'image exacte d'AS203301 est l'inverse. L'ancien agrégat 185.139.56.0/22 n'est pas actif en tant qu'agrégat dans l'aperçu de préfixe vérifié, et une vérification de validation d'origine AS203301 pour cet agrégat renvoie invalid-asn car l'autorisation visible est pour AS57814. Cela ne doit pas être sensationnalisé. Cela renforce simplement qu'AS203301 n'est pas le bord de route actuel pour l'ancien bloc d'adresses.
Pour un acheteur de centre de données, cela est important car la validation d'origine de route peut affecter la joignabilité lors d'un changement de route. Si un fournisseur déplace un préfixe entre ASN, change d'amont, introduit une annonce de sauvegarde ou désagrège pendant un incident, l'autorisation de route doit correspondre. Sinon, les réseaux qui filtrent les routes invalides peuvent abandonner le trafic au moment même où la résilience est nécessaire. La preuve AS57814 de Cloud9 est encourageante car le bord actif valide.
AS203301 doit être documenté comme silencieux à moins et jusqu'à ce que l'autorisation et le plan de route soient modifiés.
La question de l'acheteur est simple: quels préfixes mon service utilisera-t-il, quel est leur état RPKI actuel, et qui peut modifier les autorisations pendant une urgence? Pour les clients de colocation apportant leurs propres adresses, la question devient de savoir si Cloud9 prend en charge les objets de route client, les ROA, les sessions BGP et les changements de route d'urgence assez rapidement. Pour les adresses fournies par Cloud9, l'entreprise devrait être en mesure de montrer l'état d'origine valide actuel et d'expliquer son plan d'annonce de sauvegarde.
La sécurité du routage ne maintiendra pas un générateur en marche ni une unité de refroidissement en ligne. Elle supprime cependant un mode de défaillance évitable. Dans une installation qui vend de la neutralité vis-à-vis des opérateurs et de la capacité hébergée, le plan de contrôle réseau devrait être aussi bien documenté que la centrale électrique.
Capacité installée n'est pas capacité prête
La question de la capacité doit être divisée en trois couches: ce que Cloud9 a installé, ce qu'il est prêt à vendre et ce qui reste prêt après une panne ou une demande d'extension. Le site public est riche en catégories de services mais pauvre en marge de manœuvre physique. Il annonce des unités de colocation, des demi-baies, des baies complètes et des cages sur lapage de colocation, et il annonce des exigences de centre de données personnalisées sur lapage centre de données. Il ne publie pas la disponibilité des baies actives, les limites de densité de puissance, la marge de refroidissement réservée, la capacité de disjoncteur de rechange, l'inventaire de serveurs de rechange ou le temps nécessaire pour ajouter un nouveau chemin opérateur.
Cette couche manquante est importante car la capacité commercialisée peut devenir contrainte avant qu'une salle ne soit pleine. Une baie peut être physiquement vide mais indisponible à la densité de puissance dont un client a besoin. Un générateur peut supporter la charge d'aujourd'hui mais laisser peu de marge pour une nouvelle rangée à haute densité. Une conception de refroidissement peut supporter des baies d'hébergement standard mais nécessiter des changements pour du calcul dense. Une entrée de fibre peut prendre en charge les fournisseurs actuels mais nécessiter de nouveaux travaux de génie civil pour un itinéraire diversifié demandé.
Dans chaque cas, la page de vente peut être vraie alors que la capacité utilisable pour un client spécifique n'est pas immédiatement prête.
Les approbations locales et les contraintes du bâtiment devraient également faire partie de la diligence de l'acheteur. Les pages publiques de Cloud9 identifient l'emplacement Dinamo Stadium/Tsereteli Avenue et décrivent le centre de données comme construit et géré par Cloud9, mais elles ne divulguent pas les permis d'extension, les engagements de mise à niveau des services publics, les phases de construction ou les contraintes du propriétaire et du site du stade. Cette absence n'est pas une preuve de problème.
C'est une preuve qu'un client ne devrait pas traiter la capacité future de baie ou de cage comme un actif fini tant que Cloud9 n'a pas confirmé le chemin de livraison, le chemin d'alimentation, le chemin de refroidissement et le chemin d'interconnexion par écrit.
La même prudence s'applique à la déclaration d'installation en 24 heures pour certains services de colocation et à la déclaration de configuration en 24 à 48 heures pour les serveurs dédiés. Ces délais sont utiles pour les commandes standard. Ils ne doivent pas être réutilisés pour une baie complète, une cage, une construction d'opérateur, un déploiement à haute densité ou une migration de récupération à moins que Cloud9 ne dise que la configuration exacte est disponible.
Le chemin de défaillance dans cet article inclut le retard de construction car une promesse d'extension échoue souvent silencieusement: le client signe avant que le disjoncteur, la baie, le chemin de brassage, le stock de serveurs ou l'itinéraire opérateur ne soient réellement prêts.
L'acheteur devrait donc demander une déclaration de préparation, pas seulement un devis. Quelles baies sont actives maintenant? Quelles alimentations électriques sont déjà mises en service? Quels opérateurs sont déjà présents au point de rencontre demandé? Quels itinéraires nécessitent de nouveaux travaux? Quels serveurs sont en stock? Quelles pièces sont détenues localement? Quelles mises à niveau nécessitent l'approbation des services publics, de l'installation ou du fournisseur? Ces questions transforment une large revendication de centre de données en un engagement de livraison.
Qui est affecté lorsque l'ancrage de Tbilissi tombe en panne
La clientèle visible n'est pas entièrement divulguée, mais lapage à propos de Cloud9annonce plus de 1 200 clients actifs, plus de 3 500 services actifs, plus de 5 000 domaines enregistrés et une disponibilité système de 99,9 %. Ces chiffres sont publiés par l'opérateur et doivent être traités comme des chiffres marketing sauf documentation contractuelle, mais ils montrent le type de dépendance en jeu. Ce n'est pas simplement un ASN vide sans promesse client attachée. C'est une entreprise d'hébergement et de centre de données qui se présente comme un fournisseur d'infrastructure local.
Si l'installation de Tbilissi tombe en panne, différents clients échouent différemment. Les clients de colocation peuvent perdre l'alimentation, le refroidissement, l'accès de gestion ou la capacité de liaison montante tout en possédant toujours l'équipement. Les clients VPS peuvent perdre les serveurs virtuels, les panneaux de contrôle, les sauvegardes ou les mises à jour DNS. Les clients de serveurs dédiés peuvent attendre la réparation ou le remplacement du matériel. Les clients de domaine et d'hébergement peuvent subir des perturbations de messagerie, de site web et de compte.
Les clients utilisant Cloud9 pour la migration ou le support géré peuvent avoir besoin d'une action du personnel au moment même où tout le monde demande de l'aide.
La localité est à double tranchant. Un opérateur géorgien avec un support local peut être précieux pour la langue, la juridiction, le paiement, l'accès et le service domestique à faible latence. Cela peut également créer une concentration si de nombreuses petites entreprises, développeurs et organisations géorgiens dépendent d'un seul bâtiment à Tbilissi et du bureau de support d'un seul fournisseur. L'impact d'une panne ne se mesure pas seulement par le nombre total de préfixes ou la part de trafic mondial. Il se mesure par les clients qui n'ont pas de deuxième site, pas de deuxième fournisseur et pas de chemin de sortie testé.
Les preuves de route suggèrent que Cloud9 a un véritable réseau au-delà d'un petit stub. Le nombre actuel de préfixes d'AS57814, ses voisins et son support IPv6 sont significatifs. L'enregistrement d'installation Cloud9 Dinamo Arena de PeeringDB ajoute une couche d'interconnexion physique. L'adhésion à IXP.ge ajoute une pertinence d'échange local. Mais le registre public ne montre pas les résultats de basculement des clients.
Il ne montre pas combien de clients exploitent des services sur un seul site, combien utilisent des sauvegardes hors de l'installation, combien ont un service à double opérateur, ou combien connaissent la différence entre les allocations de bande passante locales et mondiales.
Cette incertitude est précisément la raison pour laquelle le titre de l'article assigné est important. La capacité de centre de données commercialisée doit survivre aux contraintes d'alimentation et de connectivité, pas simplement les décrire. L'histoire publique de Cloud9 est suffisamment crédible pour mériter un examen minutieux et suffisamment spécifique pour rendre cet examen équitable. La preuve manquante n'est pas l'identité. C'est la capacité de survie testée.
Ce qui élèverait la note de preuve
Cloud9 pourrait accroître la confiance sans exposer de détails sensibles de l'installation. Une page réseau publique pourrait indiquer le rôle actuel d'AS203301, le rôle actif d'AS57814, l'ensemble d'AS principal, les options BGP client, la politique de sécurité de routage et la pratique d'autorisation de route. Une page d'installation pourrait préserver la sécurité tout en donnant des fourchettes pour le nombre de baies actives, la densité de baie disponible, les densités de puissance supportées, le temps de fonctionnement du générateur, la redondance UPS, la redondance de refroidissement et les normes de préavis de maintenance.
Une page de statut pourrait séparer les services d'installation, de réseau, d'hébergement, DNS, de portail et de messagerie.
Pour la colocation d'entreprise, la preuve la plus précieuse serait spécifique au client. Les acheteurs devraient demander un résumé récent du test de charge du générateur, une preuve de maintenance UPS, la conception de la redondance de refroidissement, les objectifs de réponse des interventions à distance, des échantillons de communication d'incident, la preuve de basculement de route, les options de diversité d'interconnexion, le placement des sauvegardes, la preuve du temps de restauration et une déclaration claire des services qui sont sur un seul site. Si la réponse varie selon le produit, elle devrait varier par écrit.
Un serveur tour, un serveur 1U à double alimentation, une baie complète et un VDS géré ne partagent pas le même profil de risque.
Les preuves actuelles soutiennent une note Moyenne. AS203301 seul n'est pas actif et devrait être rétrogradé. L'opération plus large de Cloud9 est visible via les pages officielles de l'installation, les conditions légales, le routage AS57814, les entrées d'installation et d'échange PeeringDB, l'adhésion à IXP.ge et les vérifications d'origine de route valides sur les préfixes actifs.
Les lacunes restantes sont celles qui comptent habituellement pendant une panne: l'indépendance réelle du chemin d'alimentation, l'endurance du générateur, le basculement du refroidissement, la diversité physique des opérateurs, l'impact de la maintenance, le matériel de rechange, la restauration des sauvegardes et la preuve de migration client.
La conclusion pratique est directe. Un acheteur ne devrait pas rejeter Cloud9 simplement parce qu'AS203301 est silencieux. Il ne devrait pas acheter une capacité critique simplement parce que le site web dit centre de données neutre vis-à-vis des opérateurs.
La bonne approche consiste à traiter Cloud9 comme un véritable opérateur de centre de données et d'hébergement géorgien dont les preuves actives sont concentrées dans AS57814 et l'installation de Tbilissi, puis à exiger la preuve que le service acheté continue de fonctionner lorsqu'une alimentation, un chemin de refroidissement, un chemin opérateur, un hôte de serveur ou un canal de support tombe en panne.