Key Stones Cloud Tech Private Limited vend une capacité hébergée qui dépend encore des baies, du transit et des fenêtres de réparation

Résumé

• Key Stones Cloud Tech Private Limited possède une identité internet active. L'APNIC lui attribue AS150024 et le bloc IPv4 portable103.191.132.0/23; RIPE a vu AS150024 annoncer deux routes/24vers 325 des 326 pairs de table complète IPv4 le 12 juillet 2026.
• Le réseau est petit mais pas mono-attaché dans la vue des routes publiques. AS150024 avait deux voisins observés, AS138244 Hostzop Cloud Services Private Limited et AS146943 Tier 4 Cloud Services, et les deux routes visibles avaient une autorisation d'origine de route valide pour AS150024.
• La frontière entre entreprise et service n'est pas simple. Le propre site web de Key Stones fait la promotion de serveurs dédiés, VPS, colocation, sauvegarde et reprise après sinistre, tandis que sa page cloud indique que le cloud VPS est temporairement indisponible. Les commandes et les textes renvoient systématiquement aux systèmes Hostzop, et les conditions de Hostzop ont nommé Key Stones comme l'entreprise contractante.
• Hostzop indique désormais qu'une société distincte, Hostzop Cloud Services Private Limited, a été constituée en tant qu'extension en 2023 et identifie cette nouvelle société dans les pieds de page actuels. Les deux sociétés ont les mêmes deux dirigeants dans les agrégations d'entreprises publiques, mais une direction et une marque communes ne permettent pas d'établir laquelle possède un serveur, un contrat de baie, une route, un contrat client ou une responsabilité donnés.
• Les preuves publiques soutiennent donc une opération d'hébergement active autour de Key Stones, et non un cloud résilient entièrement cartographié. Les acheteurs ont besoin du fournisseur légal exact, de l'emplacement des installations et des baies, de l'inventaire installé et de rechange, de la diversité des fournisseurs d'accès amont et des chemins de fibre, de l'autorité de support, de l'isolation des sauvegardes, des résultats de restauration testés, de la continuité de facturation et d'une méthode de sortie exécutable par écrit.

AS150024 est un véritable point de jonction, pas une abstraction marketing

La preuve opérationnelle la plus solide pour Key Stones se trouve en dehors de sa copie produit. Leenregistrement APNIC pour AS150024nommeKEYSTONES-AS-IN, donne le pays comme l'Inde, décrit le titulaire comme Key Stones Cloud Tech Private Limited et marque le numéro comme actif. L'enregistrement a été créé le 3 août 2022. Son contact technique et administratif est Rajesh Kumar au domainekeystonescloudtech.comde la société et à une adresse à Choolai, Chennai. Il s'agit d'un enregistrement actuel de numéro internet avec un contact d'abus maintenu, et non d'un annuaire non corroboré.

La route est également visible. Au point d'observation du 12 juillet 2026, lerésultat de statut de routage de RIPEmontrait deux préfixes IPv4 couvrant 512 adresses, aucun espace IPv6, et deux voisins observés. Sur 326 pairs RIS de table complète IPv4, 325 voyaient l'ASN. La dernière route vue était présente à la dernière heure de mesure. Lerésultat des préfixes annoncésa identifié103.191.133.0/24et202.155.151.0/24comme les deux origines actuelles.

Cela distingue Key Stones d'une société qui a acquis un numéro sans jamais l'utiliser. RIPE a vu AS150024 pour la première fois annoncer103.191.132.0/24en août 2022, et sonhistorique de routageenregistre un ensemble changeant d'annonces depuis lors. L'utilisation des adresses et les arrangements de fournisseurs d'accès amont ont évolué, mais l'ASN a un historique public de plusieurs années. Leprofil IPinfo d'AS150024le classe également comme hébergement, liste les mêmes deux routes/24actuelles et signale des adresses répondantes dans chaque plage. Ces réponses actives ne prouvent pas que chaque produit de vente au détail est disponible, mais elles renforcent le fait que le réseau transporte des systèmes plutôt que d'exister uniquement sur le papier.

La sécurité de l'origine de la route ajoute un autre signal positif. Laréponse de validation de RIPE pour103.191.133.0/24rapporte une autorisation valide sous le/23de couverture de Key Stones, avec une longueur maximale de/24. Saréponse pour202.155.151.0/24rapporte également l'origine observée AS150024 comme valide. L'autorisation d'origine de route fait un travail utile: elle permet aux réseaux récepteurs de distinguer cette origine prévue d'une origine non autorisée. Elle ne crée pas une deuxième fibre, ne réserve pas un routeur de rechange, ne protège pas un hyperviseur ni ne garantit qu'un technicien puisse atteindre un serveur défaillant.

Cette distinction est importante tout au long de ce profil. Un ASN bien entretenu établit une intention opérationnelle et une connectivité visible. Ce n'est pas un inventaire de centre de données. Une route peut rester visible alors que tous les serveurs derrière elle sont injoignables; un serveur peut rester sain alors qu'une route disparaît. La tâche de l'acheteur est de relier le bord public au système physique et contractuel qui fournit le service acheté.

Un bloc portable révèle deux frontières opérationnelles

Leenregistrement d'adresse APNICattribue103.191.132.0/23à Key Stones Cloud Tech Private Limited en tant qu'espace portable alloué. La plage contient 512 adresses IPv4, de103.191.132.0à103.191.133.255, et utilise le même contact à Chennai et la même adresse e-mail d'entreprise qu'AS150024. Le statut portable est utile car l'allocation est associée au détenteur de la ressource plutôt que d'être une petite tranche d'adresses simplement déléguée par un fournisseur de transit. Il peut améliorer les options de sortie si les contrats, les autorisations de routage et les arrangements techniques permettent au titulaire de la déplacer.

Les deux moitiés de cette allocation racontent actuellement des histoires différentes.103.191.133.0/24est originaire de l'AS150024 de Key Stones. L'autre moitié,103.191.132.0/24, est originaire d'AS138244, Hostzop Cloud Services Private Limited. Des noms inversés de style Hostzop apparaissent dans toute la moitié inférieure, et le site web de Key Stones lui-même a été observé à103.191.132.77. Unerecherche DNS publiquerapporte également les serveurs de noms Hostzop à côté de cette adresse. Ce n'est pas un arrangement intrinsèquement problématique. Un titulaire d'adresse peut autoriser un autre réseau à originer une partie de son espace. C'est cependant une dépendance concrète.

La scission crée deux domaines de défaillance au sein d'un même bloc enregistré. Si l'AS150024 a un problème de plan de contrôle, les services sur la moitié auto-originée peuvent perdre leur joignabilité même si la moitié d'origine Hostzop reste disponible. Si l'AS138244 ou son remise de transporteur échoue, le site Key Stones et les systèmes sur103.191.132.0/24peuvent être affectés tandis que l'AS150024 continue d'annoncer ses propres routes. Un client se voyant attribuer une adresse devrait donc savoir de quelle moitié elle provient, quel ASN l'origine, si cette origine peut changer lors d'une récupération et si le DNS inversé, la réputation du courrier, les listes blanches de pare-feu et les licences peuvent se déplacer avec elle.

La deuxième route d'AS150024 introduit une dépendance différente. L'enregistrement APNIC couvrant202.155.151.0/24la place à l'intérieur de202.155.144.0/21, enregistré auprès d'OMAO Singapore Broadband en tant qu'espace non portable. Pourtant, le/24est légitimement originaire d'AS150024, et des observations tierces montrent des noms inversés de style Hostzop sur de nombreuses adresses. Cela ressemble à un espace d'adresses loué, délégué ou autrement autorisé plutôt qu'à une allocation détenue par Key Stones. L'arrangement commercial exact n'est pas public. Si un accord de fournisseur prend fin, les adresses peuvent ne pas être portables de la même manière que le/23de Key Stones.

C'est là que la quantité d'adresses peut être confondue avec la résilience. AS150024 originaire 512 adresses IPv4 en deux routes, mais seulement la moitié de ces adresses se trouvent dans l'allocation portable propre de Key Stones; le/24originaire restant appartient à un bloc plus grand enregistré à Singapour. Pendant ce temps, l'autre moitié de l'allocation portable de Key Stones est originaire de l'ASN de Hostzop. Le décompte est réel. Les droits de contrôle diffèrent. Un plan de sortie qui suppose que les 768 adresses associées à ces arrangements publics peuvent être transférées vers un autre fournisseur serait risqué sans lettres de route, enregistrements d'allocation et conditions contractuelles.

Deux fournisseurs d'accès amont réduisent un risque, pas tous

Lavue des voisins de RIPEa vu deux réseaux à gauche d'AS150024: AS138244 et AS146943. Le premier est Hostzop Cloud Services Private Limited. Le second est Tier 4 Cloud Services. Leprofil bgp.toolsindépendant rapporte les mêmes deux fournisseurs d'accès amont et deux préfixes IPv4 originaires. À un niveau de base, c'est mieux qu'une route publique qui dépend d'un seul ASN amont.

La topologie n'établit pas de diversité physique. Les deux sessions BGP pourraient se terminer sur un seul routeur. Deux routeurs pourraient utiliser un seul commutateur, une seule salle de rencontre, une seule entrée de bâtiment ou un seul conduit souterrain. Les deux fournisseurs d'accès amont pourraient en fin de compte dépendre d'un seul segment de fibre métropolitaine. Un événement électrique sur la baie pourrait supprimer les deux sessions à la fois. Les chemins AS publics montrent des voisins logiques, pas des identifiants d'interconnexion ou des chemins de fibre étudiés.

Les deux fournisseurs d'accès amont ont également des échelles et des empreintes publiques différentes. L'AS138244 de Hostzop est directement lié à l'allocation d'adresses et à l'historique de marque de Key Stones. Tier 4 Cloud Services est un réseau d'hébergement indien beaucoup plus vaste; safiche PeeringDBliste plusieurs points d'échange et installations, notamment Mumbai, Panvel, Pune et Greater Noida. Cette empreinte plus large peut faire de Tier 4 une option de transit utile, mais la liste ne révèle pas où AS150024 lui remet le trafic. Le transfert pourrait être local à une installation de Chennai ou livré à distance via le circuit d'une autre partie.

AS150024 lui-même n'a pas d'objet réseau PeeringDB. La participation est volontaire, donc l'absence n'est pas une preuve de mauvaise opération. Cela signifie qu'un acheteur ne peut pas utiliser ce registre public courant pour confirmer les installations de Key Stones, les ports d'échange, le niveau de trafic, la politique d'interconnexion, le looking glass ou les contacts d'opérations réseau. Lerésultat AS Rank de CAIDAvoit un petit edge avec un fournisseur dans sa propre vue de données et un cône client d'un AS. Ce résultat est en retard sur la vue de voisin plus riche, mais il décrit de manière appropriée le réseau comme un petit point de terminaison plutôt qu'une plateforme de transit étendue.

Il n'y a également aucune annonce IPv6 visible. RIPE a enregistré zéro préfixe IPv6 et zéro visibilité parmi 322 pairs IPv6. Un acheteur d'hébergement ayant besoin d'une double pile native ne devrait pas l'inférer de références génériques à IPv6 sur le site web. Il devrait demander le préfixe IPv6 attribué, une observation de route, la délégation DNS inverse, les détails de l'unité de transmission maximale et une instance de test. Un bord public uniquement IPv4 peut encore servir de nombreuses charges de travail, mais il réduit la stratégie d'adresses et laisse le fournisseur dépendant d'un inventaire IPv4 de plus en plus rare.

Une diligence réseau utile est donc spécifique. Demandez les deux noms de fournisseurs d'accès amont actuels, les routeurs et installations où chacun se termine, s'ils utilisent des alimentations électriques séparées, si leurs chemins de fibre entrent séparément, et quel chemin AS apparaît lors d'un basculement forcé. Demandez un avis de maintenance de chaque transporteur avec les champs commercialement sensibles supprimés. Ensuite, testez le retrait d'un chemin lors d'un exercice planifié. Deux noms dans BGP sont une preuve de choix logique.

La preuve de récupération commence quand l'un peut échouer sans emporter la charge de travail avec lui.

La vitrine vend de la capacité, mais ses propres pages sont en désaccord sur la disponibilité

Lapage d'accueil de Key Stonesprésente des serveurs dédiés, VPS, hébergement web, support géré, colocation, sauvegarde, gestion d'infrastructure, reprise après sinistre et services de centre de données. Elle publie des prix de départ de Rs.6 500 par mois pour un serveur dédié, Rs.450 pour un VPS et Rs.250 pour l'hébergement web. Sapage serveur dédiéliste les générations de processeurs, RAM, options de disque, allocations de transfert et ports 1Gbps. Ces détails décrivent des unités commercialisables reconnaissables plutôt qu'un vague conseil technologique.

Le chemin de commande complique l'attribution. Plusieurs boutons de serveur dédié mènent àsupport.webhostingbingo.com, tandis que les offres cloud et optimisées CPU mènent àmanage.hostzop.com. Le texte répète systématiquement le service Hostzop. Lapage de conditions de Hostzopa explicitement décrit l'accord comme étant entre Key Stones Cloud Tech Private Limited, utilisant le nom Hostzop, et le client. C'est une preuve solide que Key Stones exploitait historiquement l'identité commerciale Hostzop.

Mais la surface Hostzop actuelle identifie un successeur ou une extension. L'historique de Hostzopindique que Hostzop Cloud Services Private Limited a été constituée en tant qu'extension en 2023. Il dit que l'activité a commencé à offrir de l'hébergement sous le nom Hostzop en 2016 et a atteint une collaboration avec un centre de données en 2024. Les informations d'entreprise publiques pourHostzop Cloud Services Private Limiteddonnent un numéro d'identification d'entreprise distinct, une constitution en décembre 2023 et les mêmes deux dirigeants que Key Stones. Les pages actuelles de Hostzop placent le nom et l'enregistrement fiscal de la nouvelle société dans le pied de page.

L'image qui en résulte est plus crédible qu'une vitrine anonyme, mais moins simple qu'une société vendant à partir d'un seul site. La société plus ancienne Key Stones reste le détenteur de la ressource APNIC et l'opérateur d'AS150024. La nouvelle société Hostzop fait face au marketing actuel et aux revendications d'installation. AS138244 est enregistré au nom de la nouvelle société Hostzop et originaire de la moitié du bloc portable de Key Stones. Des dirigeants communs et un récit explicite d'"extension" suggèrent une continuité sous une direction commune.

Ils ne transfèrent pas, par eux-mêmes, la propriété des serveurs, ne cèdent pas les anciens contrats clients, ne rendent pas une société responsable des dettes de l'autre ni n'autorisent une société à émettre des crédits de service dans le cadre d'un accord signé par l'autre.

Il y a un deuxième avertissement dans le catalogue. Lapage serveur cloud de Key Stonesaffiche des configurations Linux et Windows détaillées mais indique également que le cloud VPS est temporairement indisponible. La page optimisée CPU porte le même message. Un tableau de produits peut persister après que le stock, la capacité de la plateforme ou la priorité commerciale aient changé. La déclaration directe d'indisponibilité temporaire doit primer sur les affirmations génériques de la page d'accueil qui impliquent une disponibilité universelle.

Un acheteur devrait donc traiter chaque commande comme une enquête factuelle nouvelle. Quel nom légal apparaît sur le devis, la facture et le contrat de service? Cette entité possède-t-elle ou loue-t-elle le serveur? Quel ASN et quel bloc d'adresses seront attribués? La commande est-elle pour du cloud, VPS, bare metal, colocation ou une couche gérée sur du matériel de quelqu'un d'autre? La configuration annoncée est-elle en stock maintenant? Les réponses déterminent qui peut réparer le service et ce qui peut être déplacé si la relation prend fin.

Chennai est le centre de gravité, pas une carte complète des baies

Les preuves publiques pointent systématiquement vers Chennai. APNIC enregistre le contact des ressources numériques de Key Stones au 93 Ashtabujam Road à Choolai. Les agrégateurs d'entreprises rapportent des sièges sociaux enregistrés à Chennai pour Key Stones, y compris une adresse ultérieure à Egmore. Lapage de contact actuelle de Hostzopdonne un siège social à Egmore pour Hostzop Cloud Services Private Limited et identifie séparément un centre de données AdaniConneX au SIPCOT IT Park à Siruseri, Chennai. Les pages produits actuelles de Hostzop indiquent que les serveurs sont basés à Chennai et Mumbai.

Ce sont différents types d'emplacements. Un siège social est un lieu où les avis et documents d'entreprise peuvent être traités; il ne prouve pas une salle de serveurs. Un bureau de support peut abriter du personnel tandis que l'équipement se trouve ailleurs. Une adresse d'installation identifie un bâtiment ou un campus mais pas le locataire contractant, la salle, la cage, la baie ou le circuit électrique. "Chennai et Mumbai" peut décrire la couverture produit tandis qu'un client spécifique existe sur un seul site.

La page de colocation de Key Stones fait des affirmations plus anciennes et moins établies. Elle décrit une installation "à venir" de 35 000 pieds carrés haute densité à l'intérieur d'une zone économique spéciale, ainsi qu'une redondance fibre à trois routes, une alimentation sans interruption centrale N+1 et des générateurs diesel N+1. Le futur est crucial. La page ne nomme pas l'installation, ne donne pas de date de mise en service ni ne fournit de certificat d'exploitation. Elle doit être lue comme une proposition de conception, pas une capacité installée actuelle.

Le matériel Hostzop actuel est plus spécifique sur Siruseri et AdaniConneX, mais il appartient à des pages marquées et signées par la nouvelle société Hostzop. Unepage serveur dédié vCoreindique que le service est hébergé dans l'installation AdaniConneX Chennai. Le site principal de Hostzop vend de la colocation en quart, demi et pleine baie à Chennai. Ce sont des affirmations de vente actuelles significatives. Elles n'établissent pas que chaque système dans l'AS150024 de Key Stones, chaque adresse dans le/23de Key Stones ou chaque client plus ancien de Key Stones se trouve dans cette installation.

La route visible ne règle pas non plus la géographie. Les services de géolocalisation IP placent une grande partie de l'espace associé à Chennai ou Mumbai, mais ces estimations sont construites à partir d'observations réseau et de données commerciales. Elles peuvent identifier une métropole plausible et sont utiles pour la planification de la latence. Elles ne peuvent pas prouver la garde physique d'un disque, la juridiction d'une copie de sauvegarde ou l'installation nommée dans un contrat.

La déclaration de localisation correcte est donc bornée: Key Stones est un détenteur de ressources indien enregistré à Chennai avec un ASN d'hébergement actif; le matériel de marque Hostzop sous une direction liée fait la publicité d'une capacité à Chennai et Mumbai, et la nouvelle société Hostzop nomme une installation à Siruseri. L'emplacement exact de la baie pour un service particulier de Key Stones reste spécifique à la commande.

Un acheteur sérieux devrait exiger le nom de l'installation, l'adresse complète du service, la limite de la suite ou de la cage, l'identifiant de la baie, le propriétaire de l'équipement, le bailleur ou la contrepartie de colocation et l'emplacement de la sauvegarde avant de se fier à la localité ou à la récupération multisite.

La capacité installée n'est pas la même que la capacité pouvant survivre à une panne

Les catalogues d'hébergement traduisent des équipements irréguliers en unités mensuelles nettes. Une machine virtuelle peut être vendue avec six processeurs virtuels, 16 Go de mémoire et 100 Go de stockage. Un serveur dédié peut être vendu avec un vieux Xeon, 32 Go de RAM, un disque SSD de 960 Go et 5 To de transfert. Un plan de baie peut inclure 10U, 20U ou 42U et une allocation électrique déclarée. Ces unités aident un client à comparer les prix. Elles ne divulguent pas l'inventaire qui les supporte.

Il existe au moins six états de capacité utiles. La capacité planifiée existe dans un dessin ou une intention d'achat. La capacité installée est physiquement présente. La capacité mise en service a passé l'acceptation. La capacité libre n'est pas actuellement allouée. La capacité commercialisable peut être attribuée sans violer les limites électriques, de refroidissement, de stockage ou de licence. La capacité récupérable est maintenue disponible pour que les hôtes défaillants ou un site défaillant puissent être absorbés.

Seul le dernier état répond à la question de savoir si un service peut survivre à une panne sans expulser une autre charge de travail.

Les pages de Key Stones ne donnent aucun nombre d'hôtes, nombre de baies, consommation électrique totale, niveau de remplissage du cluster de stockage, occupation des ports ou pourcentage de réserve pour basculement. Les pages actuelles de Hostzop publient davantage d'affirmations architecturales, notamment des hôtes AMD EPYC, du stockage NVMe, OpenStack et Ceph. Lapage cloud de Hostzopindique que les données Ceph sont répliquées sur plusieurs serveurs. Unepage haute performancedistincte revendique la migration en direct, les nœuds auto-réparateurs et le stockage triple réplication. Ces affirmations décrivent une conception résiliente plausible pour la nouvelle plateforme Hostzop. Elles ne quantifient pas la capacité libre ni ne prouvent que les anciens services de Key Stones utilisent cette plateforme.

L'économie des serveurs dédiés est particulièrement physique. Certaines configurations listées de Key Stones utilisent des processeurs Intel E5 v3 et v4, des générations qui peuvent encore servir un hébergement ordinaire mais ne sont plus actuelles. Des prix mensuels bas peuvent refléter du matériel amorti, une offre de gros, une utilisation élevée ou une stratégie de marge délibérée. Aucune de ces explications n'est automatiquement mauvaise. Elles créent différents risques de réparation.

Si une carte mère tombe en panne, le fournisseur a besoin d'une carte compatible, d'un châssis de rechange ou d'une destination de migration qui préserve les disques et l'identité réseau du client.

La capacité cloud est confrontée à une contrainte différente. La migration en direct nécessite des hôtes compatibles, un stockage partagé fonctionnel et suffisamment de mémoire et de capacité de processeur de rechange. La triple réplication nécessite au moins trois emplacements de stockage appropriés, mais trois copies dans une seule pièce peuvent toujours partager l'électricité, le refroidissement et le risque d'incendie. Un cluster de stockage au-dessus d'un niveau d'utilisation prudent peut avoir du mal à se reconstruire après une panne de disque ou de nœud.

Un acheteur devrait demander les plages d'utilisation actuelles, les étiquettes de domaine de défaillance, les tests de reconstruction et le nombre de pertes d'hôtes simultanées que le service est conçu pour absorber.

Les clients de colocation ont besoin de la vérité électrique plutôt que du marketing de surface. Une baie de 42U n'implique pas que les 42 unités peuvent être remplies de serveurs haute densité. Le facteur limitant peut être 4kVA de puissance contractée, le refroidissement par baie, la capacité du disjoncteur, les ports réseau ou la charge au sol. Si un plan inclut 4kVA, le client devrait demander s'il s'agit d'une puissance nominale, utilisable ou protégée; si les alimentations A et B sont mesurées séparément; et ce qui se passe lorsqu'une alimentation doit supporter toute la charge.

C'est pourquoi la capacité installée par rapport à la capacité utilisable devrait apparaître dans la révision du contrat. Demandez la configuration commandée, le numéro de série réel du matériel et son statut de propriété, l'attribution de l'hôte ou de la baie, la politique de surréservation, la redondance du stockage, la capacité libre actuelle et la politique de stock de remplacement. Un plan de vente au détail prouve une offre. Il ne prouve pas la marge de récupération.

L'électricité, le refroidissement et les fenêtres de réparation façonnent le niveau de service réel

Lapage de niveau de service de Key Stonesest exceptionnellement révélatrice car elle décrit les opérations physiques ainsi que la disponibilité. Elle définit une frontière réseau du commutateur du cabinet du client au routeur de bord, envisage l'accès aux installations, nomme la sauvegarde et la surveillance du matériel parmi les services optionnels, et promet une disponibilité de 99,98 % pour l'électricité et le refroidissement. Elle indique un objectif de résolution matérielle de quatre heures et demande aux clients de fournir une fenêtre de maintenance préventive une fois par trimestre.

Ces termes rendent le titre de l'article littéral. La capacité hébergée dépend des baies, du transit et des fenêtres de réparation. Une fenêtre trimestrielle signifie que la maintenance peut nécessiter un temps d'arrêt du client. La page indique que la durée nécessaire dépend de l'environnement du client et que l'environnement peut être indisponible pendant la fenêtre. Elle liste également des exceptions larges, y compris la maintenance planifiée et d'urgence, les liaisons client, les réseaux extérieurs, le DNS en dehors du contrôle du fournisseur, les logiciels clients et les équipements fournis par d'autres.

Un pourcentage de disponibilité a besoin de ce dénominateur. À 99,98 %, un mois nominal de 30 jours contient environ 8,6 minutes en dehors de l'objectif avant exclusions. Une année contient environ 105 minutes. Mais si la maintenance planifiée, les travaux d'urgence et plusieurs pannes de dépendance ne comptent pas, le temps d'arrêt contractuel mesuré peut être bien inférieur au temps pendant lequel un client ne peut pas utiliser l'application. Le recours est également limité: la page décrit des crédits de service, avec un ticket requis pour établir l'éligibilité, plutôt qu'une compensation pour perte d'activité.

La déclaration sur le matériel de quatre heures a besoin d'une précision similaire. "Résolution" signifie-t-elle diagnostic, remplacement, rétablissement du service ou une mise à jour finale? L'horloge tourne-t-elle en dehors des heures ouvrables? Est-elle suspendue pendant que le fournisseur attend l'approbation du client? Y a-t-il du matériel de rechange sur place pour chaque génération de serveur listée? Un échange de disque peut être rapide; la reconstruction d'un grand réseau peut prendre beaucoup plus de temps.

Remplacer un hôte défaillant n'est pas la même chose que restaurer une application cliente si le disque de démarrage, l'image de machine virtuelle ou la licence ne démarrent pas sur le remplacement.

Les affirmations électriques nécessitent également une frontière. La page de colocation plus ancienne de Key Stones fait la publicité d'une alimentation sans interruption et de générateurs N+1, tandis que le texte du niveau de service indique une double alimentation active provenant de deux réseaux. Les matériaux actuels de Hostzop font des affirmations de redondance similaires pour l'installation de Chennai. Deux alimentations de service public peuvent encore se rencontrer sur un seul tableau de distribution. Les générateurs N+1 peuvent partager le carburant, les commandes ou un chemin de distribution commun.

Un serveur à double cordon peut encore être connecté à deux prises sur un circuit dérivé. La preuve utile est un schéma unifilaire, un test récent de charge du générateur, un test de transfert, un registre d'entretien des batteries et l'attribution réelle du circuit A/B de la baie.

Le refroidissement a le même problème. La page de niveau de service nomme une température cible de 23 degrés Celsius avec une tolérance de deux degrés. Une pièce peut atteindre cette moyenne tandis qu'une baie dense développe un point chaud. Le refroidissement N+1 protège contre la perte d'un composant uniquement si les unités restantes peuvent supporter la charge réelle et si la distribution électrique survit. Demandez les mesures d'entrée de la baie, les seuils d'alarme, la conception du confinement et un test montrant ce qui se passe lorsqu'une unité de refroidissement est délibérément mise hors service.

La maintenance n'est pas un défaut. Refuser la maintenance peut être plus dangereux que la planifier. La question importante est de savoir si le client peut concevoir autour de la fenêtre. Cela nécessite un préavis, un périmètre clair, un emplacement de récupération non affecté, un chemin de basculement testé et l'autorité de reporter les travaux non urgents lorsque la propre redondance du client est compromise.

Le support et la facturation peuvent échouer alors que les serveurs restent opérationnels

La continuité de l'infrastructure est en partie un problème de main-d'œuvre. Un fournisseur peut avoir de l'électricité, du réseau et des disques sains tandis qu'un client reste hors ligne parce qu'aucune personne autorisée ne peut réinitialiser un port de commutateur, remplacer un disque, approuver un changement de route ou restaurer l'accès au compte. Key Stones annonce une aide 24h/24 et un support géré. Son texte de niveau de service exige que le client ouvre un ticket de problème et utilise ce ticket pour demander un crédit.

Ce sont des conventions opérationnelles sensées, mais les pages publiques ne publient pas les niveaux de réponse, les noms d'escalade ou la profondeur du personnel.

La limite de la petite entreprise compte ici. Les agrégations d'entreprises publiques listent deux dirigeants pour Key Stones. Les mêmes deux personnes sont listées pour la nouvelle société Hostzop. Cette continuité peut rendre les décisions rapides, mais elle peut aussi concentrer l'autorité commerciale et technique. Les preuves publiques ne divulguent pas le nombre d'employés, la couverture de permanence ou si le travail sur installation est effectué par le personnel de l'entreprise, le personnel de Hostzop, une équipe de main à distance d'AdaniConneX ou un autre sous-traitant.

Un acheteur devrait cartographier l'autorité avant un incident. Qui peut entrer dans l'installation à 3 heures du matin? Qui peut approuver une intervention à distance d'urgence? Qui détient les identifiants du routeur? Qui peut autoriser un fournisseur amont à accepter un changement de route? Qui contrôle le portail client, les noms de domaine, le DNS et le compte de facturation? Si Key Stones a émis la facture originale mais que Hostzop Cloud Services exploite désormais la plateforme, quel service desk est contractuellement obligé d'agir?

La facturation est son propre domaine de panne. La page plus ancienne de Key Stones envoie différents produits vers plusieurs systèmes de commande. Un paiement échoué, une facture contestée ou une migration de compte peut suspendre un service sans aucune panne physique. Les conditions publiques sur le site de Key Stones identifientkeystonescloudtech.com, LLC, même si le sujet est une société indienne à responsabilité limitée privée; les conditions de Hostzop identifient Key Stones plus précisément, tandis que les pieds de page actuels de Hostzop identifient la nouvelle société. Un texte contractuel qui change de noms entre les pages devrait être résolu avant le paiement, pas après la suspension.

Le client devrait exiger un devis et un bon de commande qui utilisent un nom exact de société et un numéro d'enregistrement, identifient toutes les politiques incorporées, indiquent la devise de facturation et le traitement fiscal, et expliquent l'avis de suspension. Il devrait indiquer si les données restent accessibles pendant un litige de facturation, combien de temps un service résilié est conservé, si une exportation peut être effectuée alors qu'une facture est contestée et qui libère les adresses portables ou les transferts de domaine.

Les preuves de support devraient inclure un tableau de gravité, des objectifs d'accusé de réception et de rétablissement, des contacts d'escalade, des conditions de main à distance sur installation et un exemple de rapport d'incident. Une page de statut public peut aider, mais lapage de statut de Hostzopsemble centrée sur le temps de réponse et une seule adresse affichée,103.191.132.2. Cette adresse se trouve dans l'allocation de Key Stones mais est originaire d'AS138244. Surveiller un point de terminaison accessible ne peut pas établir l'état de chaque baie, cluster de stockage, réseau client, panneau de contrôle ou route AS150024. Les clients ont besoin d'avis au niveau des composants et de leur propre surveillance indépendante.

La sauvegarde est une option jusqu'à ce qu'une restauration prouve le contraire

Lapage de sauvegarde de Key Stonesprésente la sauvegarde comme un service géré, et sapage de reprise après sinistrepromet une préparation aux perturbations techniques et naturelles. Les pages actuelles de Hostzop vont plus loin, décrivant le stockage Ceph répliqué, les clichés, la migration en direct et une période d'exportation de 90 jours en cas de fermeture de l'activité. Ces affirmations identifient les bonnes préoccupations. Les pages publiques ne fournissent pas de point de récupération spécifique au client, de temps de récupération, d'emplacement de copie ou de dossier de restauration réussi.

Trois protections sont souvent confondues. La haute disponibilité maintient un service en fonctionnement lors d'une panne de composant. La sauvegarde préserve une copie antérieure qui peut être restaurée après suppression, corruption ou compromission. La reprise après sinistre recrée le service après la perte d'un domaine de défaillance plus vaste. Le stockage répliqué est précieux pour les pannes matérielles, mais il peut répliquer fidèlement une suppression accidentelle ou des données chiffrées par rançongiciel. Un cliché dans le même compte de contrôle peut être supprimé avec le système de production.

Une sauvegarde dans la même pièce peut être perdue avec la pièce.

Un client devrait demander où réside chaque copie, quelle entreprise l'exploite, quels identifiants peuvent la supprimer et si elle partage la même électricité, la même installation, le même transporteur ou le même administrateur de stockage. Au moins une copie de récupération devrait avoir un domaine de défaillance indépendant du service principal et une protection contre une modification immédiate. Le fournisseur devrait indiquer la rétention, le chiffrement, la garde des clés et le coût et le temps nécessaires pour récupérer un grand jeu de données.

Les tests de restauration sont la preuve. Pour une machine virtuelle, exportez une image, la configuration réseau et les volumes attachés, puis démarrez-la en dehors de l'environnement principal. Pour un hébergement partagé, restaurez les fichiers, les boîtes aux lettres, les bases de données, le DNS et les certificats dans un compte propre. Pour un bare metal, testez la récupération sur du matériel de remplacement. Pour une colocation, confirmez comment les sauvegardes quittent la baie si les deux périphériques client tombent en panne.

Enregistrez le point de récupération et le temps de récupération atteints, pas seulement qu'un travail de sauvegarde a signalé un succès.

La migration est tout aussi physique. Quelques gigaoctets peuvent partir sur un lien internet ordinaire. Des dizaines de téraoctets peuvent prendre des jours même à des débits soutenus gigabit, et les changements de production se poursuivent pendant le transfert. Les limites de sortie, la limitation, les frais de transfert et les fenêtres de maintenance peuvent prolonger le déplacement. Si les adresses du client proviennent du202.155.151.0/24non portable, le renumérotage peut également nécessiter des modifications DNS, un réchauffement du courrier, des mises à jour des listes blanches des partenaires et une révision des certificats.

L'espace portable de Key Stones pourrait améliorer la continuité pour les clients éligibles, mais seul le détenteur de la ressource peut coordonner l'autorité de route et seulement si le contrat client le permet. La plupart des petits clients d'hébergement reçoivent des adresses individuelles, et non des droits pour emporter le bloc d'un fournisseur ailleurs. Le package de sortie pratique est donc des données au format ouvert, la documentation de configuration, les fichiers de zone DNS actuels, le transfert des identifiants, une destination testée et une période de chevauchement pendant laquelle les deux services fonctionnent.

L'assurance de fermeture publique du fournisseur est un signal de marché positif, mais elle apparaît sur une page actuelle de Hostzop sous Hostzop Cloud Services Private Limited. Un client de Key Stones ne devrait pas supposer qu'elle modifie automatiquement un ancien contrat de Key Stones. L'assurance doit figurer dans la commande signée avec un gardien nommé et une méthode qui fonctionne encore si le portail de gestion est indisponible.

La localité est une chaîne de responsabilité, pas un drapeau indien à côté d'une adresse IP

La zone de service est l'Inde, et les affirmations physiques les plus solides pointent vers Chennai avec quelques pages Hostzop mentionnant également Mumbai. Cela peut convenir aux clients recherchant une latence indienne ou une garde locale. Pourtant, la localité nécessite plus qu'un code de pays de détenteur de ressources indien ou un résultat de géolocalisation. Elle dépend de l'endroit où résident réellement les disques primaires, les réplicas, les sauvegardes, les journaux et l'accès au support.

Le mélange de routes actuel illustre le problème. Le propre/23de Key Stones est enregistré en Inde. Le second/24originaire d'AS150024 est extrait d'un bloc plus grand enregistré à Singapour. Cet enregistrement ne prouve pas que les données client sont à Singapour; le pays du registre IP et l'emplacement du serveur peuvent différer. Inversement, une origine de route indienne ne prouve pas que chaque sauvegarde reste en Inde. La réponse correcte vient de l'architecture du service et du contrat.

Lesdirectives CERT-Inde l'Inde sont directement pertinentes pour les centres de données, les fournisseurs VPS et les fournisseurs cloud. Elles exigent que les organisations couvertes conservent les journaux ICT en toute sécurité pendant 180 jours glissants dans la juridiction indienne et exigent que les informations d'abonné spécifiées soient conservées pendant cinq ans ou plus lorsque la loi l'exige. Un client d'hébergement devrait donc comprendre quels enregistrements d'identité, d'attribution et d'utilisation le fournisseur conserve, où ces enregistrements sont stockés et comment les demandes d'incident sont traitées.

Le cadre de protection des données de l'Inde est également en mise en œuvre par étapes. Lapage officielle des règles de protection des données personnelles numériques 2025publie les règles finales et le matériel de mise en œuvre. Lanotification de mise en œuvreéchelonne les principales dispositions sur un an et dix-huit mois à compter de novembre 2025. Les obligations d'un client dépendent de son rôle, de ses données et des dispositions en vigueur; un serveur à Chennai ne remplace pas une analyse juridique.

Les questions opérationnelles restent concrètes. Quelle société légale traite les données de compte et de support? Utilise-t-elle des sous-traitants? Le support à distance peut-il accéder au serveur depuis l'extérieur de l'Inde? Les enregistrements de surveillance sont-ils copiés à l'étranger? Où résident les copies de sauvegarde et de reprise après sinistre? Le client peut-il sélectionner Chennai uniquement, et cette sélection couvre-t-elle chaque réplica? Qu'advient-il des enregistrements d'identité et d'accès conservés après l'annulation?

La licence réseau ne doit pas être déduite d'un ASN. Le Département des télécommunicationsdécrit les autorisations de service internetpar portée et zone de service. Une société d'hébergement peut acheter du transit et fournir du calcul hébergé sans exploiter chaque type de service d'accès sous licence. AS150024 établit une activité de routage, pas une conclusion sur une licence que la société peut ou non nécessiter. Si un client achète de la connectivité réglementée plutôt qu'un hébergement ordinaire, il devrait demander l'autorisation exacte de la partie contractante.

La localité est mieux écrite comme un calendrier: site principal nommé, site de récupération nommé, pays de traitement approuvés, emplacements de sauvegarde, contrôles d'accès au support, périodes de rétention et notification avant changement. Ce calendrier devrait suivre la charge de travail lorsque le fournisseur change de plateforme ou d'entité juridique.

Qui est affecté quand une couche échoue

L'impact sur l'utilisateur dépend de la couche achetée. Les clients d'hébergement partagé peuvent perdre des sites web, des e-mails, des bases de données et l'accès au panneau de contrôle ensemble car de nombreuses fonctions partagent un serveur ou un domaine de gestion. Les clients VPS peuvent conserver des systèmes d'exploitation indépendants mais partagent toujours un hôte, un pool de stockage, un commutateur de tête de baie et un système de facturation.

Les clients de serveurs dédiés évitent les voisins bruyants au niveau du calcul mais restent dépendants de l'électricité, du réseau, des mains à distance et du matériel de rechange de l'installation. Les clients de colocation possèdent plus d'équipement mais doivent coordonner l'accès, les interconnexions et les pièces de rechange.

Une panne de route affecte la joignabilité publique. Si un fournisseur amont d'AS150024 échoue proprement et que l'autre chemin est vraiment indépendant, le trafic peut reconverger. Si les deux sessions partagent un chemin physique, les deux peuvent disparaître. Les clients sur la moitié originaire d'AS138244 du bloc Key Stones font face à une frontière de route différente de celle des clients sur AS150024. Une panne du site web de l'entreprise sur103.191.132.77ne prouverait pas qu'AS150024 est en panne, et une perte de202.155.151.0/24n'affecterait pas nécessairement le site web.

Un événement de baie a un rayon d'explosion plus petit mais plus physique. La perte d'une seule unité de distribution électrique peut affecter les dispositifs à cordon unique. Un commutateur défaillant peut isoler tous les serveurs d'une baie. Un problème de refroidissement peut forcer un arrêt ordonné. Une panne de disque peut devenir une perte de données si la redondance est déjà dégradée. Les clients ont besoin de savoir si leurs composants d'application partagent la même baie et si le fournisseur les alerte lorsque la protection est réduite mais que le service fonctionne toujours.

Une panne de support prolonge chaque interruption. Si la seule personne ayant autorité ne peut être jointe, un remplacement matériel de dix minutes peut attendre des heures. Si les dossiers clients sont répartis entre Key Stones et la nouvelle société Hostzop, le personnel peut avoir du mal à vérifier les droits ou à localiser le bon dispositif. Un registre d'actifs à jour et un accord d'agence clair sont des contrôles de résilience, pas des détails administratifs.

Une panne de facturation ou de contrat peut être abrupte. La suspension peut supprimer l'accès réseau tandis que les données restent intactes. La résiliation peut déclencher des horloges de suppression. L'insolvabilité ou un litige avec un propriétaire d'installation peut limiter l'accès physique. Un client avec des données portables mais aucune exportation actuelle est toujours piégé par le temps de transfert. Un client avec des sauvegardes mais aucun identifiant n'est pas rétabli.

Les conséquences en aval peuvent être plus larges que le compte direct. Une agence hébergeant des centaines de sites de petites entreprises peut propager une panne de serveur à de nombreuses entreprises. Un revendeur peut perdre le DNS et le courrier de ses clients. Une boutique en ligne peut perdre la caisse, l'inventaire et les e-mails transactionnels en même temps. Une société de logiciels peut perdre les portails d'application et de support sur le même fournisseur. Ces utilisateurs connaissent rarement l'ASN, mais ils subissent chaque dépendance partagée derrière lui.

La meilleure atténuation est en couches. Utilisez un DNS indépendant lorsque c'est approprié, conservez les identifiants et les fichiers de zone en dehors du compte d'hébergement, placez les sauvegardes sous une frontière de contrôle séparée, surveillez depuis l'extérieur des deux fournisseurs amont et maintenez une destination testée. Pour les services importants, séparez l'application, la sauvegarde et les plans de contrôle de récupération suffisamment pour qu'un seul compte d'entreprise ou un seul événement d'installation ne puisse pas supprimer les trois.

Quelles preuves transformeraient un cas moyen en un cas fort

Le cas public pour l'opération est déjà substantiel. AS150024 est actif et largement visible. Key Stones détient de l'espace d'adresses portable. Le bloc d'adresses porte des systèmes hébergés. Les pages produits, les liens de commande, les conditions et les registres d'entreprises publics relient Key Stones à l'historique de service Hostzop. Cela suffit pour rejeter l'hypothèse que l'entité n'a pas d'empreinte opérationnelle observable.

Le cas reste moyen car les affirmations d'infrastructure les plus récentes et les plus détaillées appartiennent à Hostzop Cloud Services Private Limited, une société distincte constituée en 2023. Les documents publics ne montrent pas de transfert d'actifs, de novation client, d'accord d'exploitation interentreprises ou de calendrier mappant les routes Key Stones aux baies Hostzop. Ils ne publient pas non plus de capacité site par site, de tests de route indépendants, d'inventaire de rechange, de résultats de restauration ou d'historique d'incidents.

Un cas plus fort commencerait par une clarté d'entreprise: une déclaration signée identifiant le fournisseur légal pour les comptes nouveaux et anciens; le rôle de Key Stones et Hostzop Cloud Services; le statut de propriété ou de location des routeurs, serveurs et baies AS150024; et l'accord permettant à AS138244 d'originer une partie du/23de Key Stones. Les clients existants devraient recevoir toute cession ou novation directement, et non l'inférer d'un pied de page.

Les preuves d'installation devraient identifier les emplacements réels de Chennai et, le cas échéant, de Mumbai, la société d'exploitation, la limite de la cage et de la baie, l'électricité contractée, la conception du refroidissement et le fournisseur de main à distance. Une certification indépendante actuelle peut soutenir les contrôles de l'installation, mais la portée et le titulaire du certificat doivent correspondre au service. Un certificat appartenant à un propriétaire ne couvre pas automatiquement les opérations du serveur du locataire.

Les preuves réseau devraient inclure des paires de routeurs, des remises de transporteurs séparées, une diversité de chemin physique, des filtres de route actuels, des contrôles de préfixe maximum, des autorisations d'origine de route et un résultat récent de basculement forcé. Les deux voisins publics sont un bon point de départ. Le test doit montrer que le trafic client survit à la perte de chaque chemin et que la surveillance détecte la dégradation.

Les preuves de capacité devraient montrer les hôtes et le stockage installés, les bandes d'utilisation actuelles, la marge de récupération réservée, les disques de rechange, les alimentations électriques et les serveurs de remplacement compatibles. Les clients cloud ont besoin de résultats de domaine de défaillance et de reconstruction. Les clients dédiés ont besoin d'un inventaire sérialisé et de délais de remplacement. Les clients de colocation ont besoin d'attributions de circuit et de baie.

Les preuves de récupération devraient définir le point de récupération et le temps de récupération par produit, situer les sauvegardes en dehors du domaine de défaillance principal, montrer des copies immuables ou contrôlées séparément, et inclure un rapport de restauration récent. Les preuves de sortie devraient inclure les formats, la bande passante, les frais, le calendrier de suppression, le traitement DNS et d'adresses, et une exportation testée effectuée avant que le service ne soit critique.

Enfin, le client devrait réconcilier les promesses publiques avec l'accord signé. La revendication de 99,98 %, la déclaration matérielle de quatre heures, la maintenance trimestrielle, les exclusions, la méthode de crédit de service, la clause de non-responsabilité pour perte de données et l'escalade de support devraient tous apparaître dans un seul contrat cohérent sous le bon nom de société. Le marketing peut décrire une ambition. Le contrat détermine qui agit lorsque la baie, le lien de transit, l'étagère de rechange, le système de compte ou l'accord du fournisseur échouent.

Le verdict: réseau opérationnel, périmètre d'actifs non résolu

Key Stones Cloud Tech Private Limited a plus de substance opérationnelle que son design de site web daté ne le suggère. AS150024 est actif, largement visible et protégé par des autorisations d'origine de route valides. Il originaire deux routes IPv4 via deux fournisseurs amont observés. Son/23portable contient des systèmes hébergés actifs, et son historique commercial est lié par des conditions de première partie à Hostzop.

Les mêmes preuves exposent la structure de dépendance. La moitié du bloc Key Stones est originaire de l'ASN de Hostzop. Une autre route AS150024 est tirée d'une allocation non portable enregistrée à Singapour. Les pages actuelles de Hostzop identifient une nouvelle société légale et font les affirmations les plus fortes d'installation, de cloud et de récupération sous ce nom. Le catalogue plus ancien de Key Stones fait encore la publicité de services qu'une autre page dit temporairement indisponibles. Les pages de contrat public utilisent des identités incohérentes.

Rien de tout cela ne prouve une défaillance de service ou une faute. Cela montre pourquoi les acheteurs ne devraient pas confondre marque, entreprise, ASN, détenteur d'adresses, fournisseur de transit, locataire d'installation et propriétaire de matériel en un seul opérateur supposé. La preuve de route mérite une note réseau moyenne. Une note de service solide nécessite une carte actuelle allant de l'accord client signé jusqu'à la baie, aux transporteurs, à l'inventaire de rechange, à l'autorité de support et à la copie récupérable.

Pour un site web ordinaire à faible risque, le prix et un support réactif peuvent suffire. Pour une application qui ne peut tolérer une longue interruption, l'acheteur devrait insister sur des preuves avant la migration: contrepartie exacte, site nommé, deuxième chemin testé, capacité récupérable, restauration mesurée et une exportation détenue en dehors du compte. La capacité cloud est facile à commander car les engagements physiques ont été pris à l'avance. La résilience n'existe que lorsque ces engagements restent disponibles pendant la fenêtre de réparation.