LIVEHOSTING centres de données SRL doit prouver si la capacité commercialisée de ses centres de données peut survivre aux contraintes électriques et des opérateurs

Résumé

• LIVEHOSTING centres de données SRL s'identifie publiquement comme l'exploitant d'un centre de données à Timisoara et comme le détenteur d'AS41635. Ses pages de vente actuelles proposent de l'hébergement web, des serveurs virtuels et dédiés, de la gestion de serveurs et de la colocation 1U-3U.
• Le périmètre réseau public est actif, pas seulement enregistré. RIPEstat a observé 89.38.208.0/22 depuis AS41635 le 12 juillet 2026, visible par les 326 pairs IPv4 déclarants dans son instantané de statut de routage, avec AS12302 et AS39737 comme réseaux adjacents observés.
• Les preuves physiques sont moins récentes. Un guide sectoriel roumain de 2012 faisait état d'une salle de données de 30 mètres carrés, de deux alimentations triphasées de 50 kW, d'un groupe électrogène diesel de 100 kW et de quatre onduleurs de 40 kW. Ces chiffres constituent un historique utile, mais ils n'établissent pas l'équipement, la charge, l'autonomie ou la redondance disponibles en 2026.
• La page de colocation répertorie deux alimentations, un onduleur, un groupe électrogène, une protection DDoS et un port Internet 1 Gbps. Elle ne publie pas la séparation des circuits A/B, l'endurance en carburant du générateur, la redondance du refroidissement, les entrées fibre, les engagements des opérateurs, les résultats des tests de maintenance ou un deuxième site de reprise.
• Le niveau de preuve réseau est Moyen. Il existe des preuves convaincantes d'un service actuel et d'une surface d'exploitation routée, mais pas suffisamment de preuves actuelles et indépendantes pour considérer la capacité commercialisée comme maintenable simultanément ou démontrablement récupérable après une défaillance de l'installation ou d'un opérateur.

L'affirmation est suffisamment spécifique pour être testée

LIVEHOSTING centres de données SRL ne se cache pas derrière une vague étiquette cloud. Sapage de contact actuellenomme la société légale roumaine, donne le numéro d'enregistrement J35/815/2010 et le code fiscal RO26963713, identifie AS41635, et indique que la société exploite son propre centre de données à Timisoara. Sonoffre de colocationplace les équipements des clients dans cette installation et répertorie la protection par onduleur et groupe électrogène. C'est plus concret qu'un revendeur qui n'identifie jamais un site ou un réseau.

La spécificité crée une charge de preuve utile. Si un fournisseur déclare exploiter l'infrastructure au niveau du bâtiment derrière les charges de travail des clients, l'unité pertinente n'est pas le serveur virtuel affiché sur une page de prix. C'est la chaîne complète depuis l'arrivée du réseau électrique jusqu'à l'onduleur, le groupe électrogène, la distribution électrique, le refroidissement, le rack, le commutateur, le routeur de périphérie, le chemin opérateur et le technicien. Chaque maillon peut réduire la capacité que les clients peuvent réellement utiliser en cas de panne.

Le domaine public de l'entreprise couvre plusieurs types de dépendances. Sapage d'accueilpropose de l'hébergement Windows et Linux, des serveurs virtuels, des serveurs dédiés, de la colocation et de la gestion de serveurs. Les clients d'hébergement mutualisé dépendent d'une plateforme contrôlée par le fournisseur. Les clients de serveurs virtuels dépendent de la conception de l'hôte et du stockage qu'ils ne peuvent pas inspecter directement. Les clients de serveurs dédiés dépendent du matériel, de la commutation et de l'accès à distance. Les clients de colocation possèdent davantage le serveur mais dépendent toujours de l'installation et du réseau. Une défaillance au niveau commun de l'alimentation ou du transporteur peut donc affecter des produits qui semblent distincts au niveau de la facturation.

La distinction clé est entre la preuve d'exploitation et la preuve de résilience. AS41635 et le catalogue de produits actuel font un cas convaincant que LiveHosting est en activité. Ils ne montrent pas, par eux-mêmes, quelle charge survit à la perte d'un chemin d'alimentation, d'une chaîne d'onduleurs, d'une unité de refroidissement, d'un routeur de périphérie ou d'une entrée fibre. Cette deuxième question détermine si un petit centre de données de Timisoara est simplement disponible un jour ordinaire ou récupérable un jour difficile.

Un service actuel derrière une petite empreinte publique

Les preuves publiques soutiennent une véritable activité commerciale. LiveHosting publie des prix pour les serveurs virtuels, les serveurs dédiés et la colocation, maintient des pages de compte client et de commande, et expose un contact pour les abus réseau. Sapage de serveurs virtuels SSDrépertorie six configurations, tandis que sapage NVMeen répertorie six autres. Ses pages de serveurs dédiés font la publicité de systèmesHP ProLiant DL360 G7etG8avec alimentations redondantes à chaud et multiples interfaces réseau.

Ces pages établissent une surface de vente, pas un inventaire. Elles ne disent pas combien d'hôtes physiques sont installés, combien sont disponibles pour livraison immédiate, quelle proportion de CPU et de mémoire est engagée, ou si des systèmes et des disques de remplacement sont conservés sur site. Une configuration peut rester commandable alors que le dernier châssis approprié est en cours d'utilisation, qu'une pièce de rechange est en réparation, ou que de nouvelles alimentations ne peuvent pas être allouées à un rack.

Les acheteurs doivent donc traiter les configurations listées comme des classes de service commercialisées plutôt que comme une capacité installée auditée.

L'empreinte publique de l'entreprise semble également petite.Le profil d'entreprise de Termene.ro, un agrégateur d'informations sur les sociétés roumaines, rapporte un chiffre d'affaires 2024 de RON736 213, un bénéfice net de RON286 410 et une moyenne d'un employé. LinkedIn, en revanche, classe l'entreprise dans une fourchette de deux à dix employés et indique qu'elle a servi plus de 4 000 clients depuis 2006. Aucune de ces sources ne prouve le nombre actuel d'ingénieurs disponibles pour un incident de nuit. Les sous-traitants, le personnel affilié, les techniciens des opérateurs et le personnel du bâtiment peuvent tous se situer en dehors d'une moyenne légale ou d'une fourchette de médias sociaux.

Cette incertitude importe sans impliquer qu'une petite équipe est incapable. Les petits opérateurs peuvent être techniquement disciplinés et réactifs. Ils peuvent aussi dépendre fortement des connaissances d'un seul administrateur et de fournisseurs dont les délais de réponse échappent au contrat du client. Les preuves pertinentes sont un registre de service actuel, un dispositif d'escalade, une liste d'accès et un droit de support des fournisseurs. Les signaux d'effectifs publics rendent simplement ces questions plus importantes.

Timisoara est le lieu de service, mais pas un plan de site complet

LiveHosting déclare à plusieurs reprises qu'il exploite son propre centre de données à Timisoara. Ses coordonnées légales placent le siège social à Dumbravita, juste à l'extérieur de la ville, tandis que la page de colocation indique que le lieu de service est « LiveHosting centres de données Timisoara ». Ce sont des déclarations compatibles, mais elles ne prouvent pas que le siège social, la salle de données et chaque serveur annoncé se trouvent à la même adresse.

L'entrée d'installation de centres de données Mapdécrit une installation LiveHosting à moins de deux kilomètres du centre-ville de Timisoara et indique que l'emplacement exact n'est pas public. Sa page écosystème ne signale aucune donnée réseau ou de fournisseur de services pour le site. centres de données Map est un répertoire commercial, pas un audit d'ingénierie, mais l'absence d'une adresse exacte publique renforce une frontière importante: la ville est prise en charge; l'identité du bâtiment et la structure de propriété ne le sont pas.

« Propre centre de données » peut décrire plusieurs arrangements. L'entreprise peut posséder la propriété et toutes les installations mécaniques et électriques. Elle peut posséder la salle informatique dans un bâtiment loué. Elle peut exploiter des racks et de la commutation tandis qu'un propriétaire contrôle l'arrivée électrique, les systèmes d'incendie ou le refroidissement. Elle peut sous-traiter la maintenance du générateur ou la sécurité à distance. Aucun de ces modèles n'est intrinsèquement déficient. Ils créent des droits de rétablissement différents et des fournisseurs de délais différents.

Un client évaluant la colocation devrait demander une matrice de responsabilités. Elle devrait identifier qui possède le bâtiment, qui exploite chaque étape électrique, qui entretient le refroidissement, qui contrôle l'accès physique, qui détient le contrat de carburant du générateur, qui possède la fibre externe, et qui peut autoriser un travail d'urgence. Elle devrait également distinguer le siège social légal de l'adresse de l'installation et de tout emplacement de secours. Sans cette carte, l'expression « propre centre de données » est utile mais incomplète.

La zone de service est la plus claire au niveau réseau. AS41635 est enregistré en Roumanie, le produit est vendu en roumain, et un traceroute IPinfo a atteint une adresse dans le bloc d'origine via Prime Telecom jusqu'à une destination étiquetée Timisoara en juin 2026. Cela soutient une livraison roumaine. Cela ne prouve pas que chaque sauvegarde, service de contrôle, sonde de surveillance ou copie client reste en Roumanie.

Un instantané détaillé de 2012 ne peut pas certifier l'installation de 2026

La description publique la plus spécifique de l'installation physique apparaît dans le guidecentres de données 2012de Market Watch. Le guide indiquait une salle de données de 30 mètres carrés, deux alimentations de transformateur triphasé nominales de 50 kW chacune, une décrite comme venant d'Electrica et l'autre de CET, un groupe électrogène diesel de 100 kW et quatre onduleurs de 40 kW chacun. Il listait également des communications à 1 Gbps, des serveurs Dell, du stockage et du réseau, une surveillance via PRTG et DRAC, et des certifications ISO 9001 et ISO 27001.

C'est une preuve historique précieuse car elle donne des échelles et des topologies que le site web actuel ne fournit pas. Elle a aussi quatorze ans. L'équipement vieillit, les batteries sont remplacées, le refroidissement est étendu, le câblage est refait, les contrats des opérateurs changent et les installations déménagent. Le guide peut avoir capturé avec précision la description du fournisseur à l'époque tout en disant peu sur l'installation qui sert maintenant les clients.

Les chiffres nécessitent également une interprétation. Deux alimentations nominales de 50 kW ne signifient pas nécessairement 100 kW de charge informatique résiliente. Si l'une ou l'autre alimentation doit pouvoir supporter toute la salle, la capacité utilitaire résiliente peut être plus proche de la puissance utilisable du chemin le plus petit après pertes et charges non informatiques. Un groupe électrogène de 100 kW n'établit pas la charge informatique qu'il peut supporter une fois le refroidissement, les pertes de l'onduleur, l'éclairage, les pompes et les courants de démarrage inclus.

Quatre onduleurs de 40 kW ne révèlent pas s'ils ont été configurés en N, N+1, 2N ou en systèmes séparés supportant différentes charges.

Le site web actuel doit donc être lu parallèlement, et non fusionné, avec le guide de 2012. Les pages actuelles prouvent que les produits de colocation et de serveur restent commercialisés. L'ancien guide montre ce que l'entreprise a divulgué un jour. Aucun document public examiné ici ne relie les données historiques à un schéma électrique unifilaire actuel, un rapport de mise en service, un test de charge, un rapport d'état des batteries ou un test d'autonomie de carburant. Jusqu'à ce qu'ils apparaissent, les chiffres historiques sont une base de questions, pas un certificat de capacité actuelle.

Deux alimentations de serveur ne prouvent pas deux chemins d'alimentation indépendants

Le tableau de colocation actuel liste « 2 » sous alimentations pour ses plans 1U, 2U et 3U. Les pages de serveurs dédiés font également la publicité d'alimentations doubles à chaud de 750 W. C'est une bonne conception au niveau des composants: un serveur peut continuer après la défaillance d'un module d'alimentation si l'autre module et son entrée restent sains. Mais la résilience dépend de l'endroit où les deux cordons mènent.

Si les deux alimentations du serveur se connectent à la même PDU de rack, la PDU reste un point de défaillance unique. Si deux PDU se connectent à la même sortie d'onduleur ou au même tableau de distribution, le chemin électrique amont reste partagé. Si des systèmes d'onduleurs séparés dépendent d'un seul commutateur de transfert ou d'un seul générateur, une défaillance à cet endroit peut supprimer les deux alimentations apparentes. Même des connexions électriques physiquement séparées peuvent partager une sous-station, un chemin de câble ou un schéma de protection à l'extérieur du bâtiment.

C'est pourquoi l'explication du système de classification Tier de l'Uptime Institutedistingue les composants redondants de la maintenabilité simultanée et de la tolérance aux pannes. Un deuxième composant n'est pas la même chose qu'un deuxième chemin de livraison. L'article n'attribue aucun niveau Tier à LiveHosting; la page d'entreprise examinée ici n'en revendique pas, et le guide de 2012 n'a explicitement pas fourni de classification Uptime. Le cadre n'est utile que pour clarifier quelles preuves soutiendraient un langage plus fort.

Pour chaque rack vendu comme double alimentation, LiveHosting devrait pouvoir montrer les chemins A et B depuis le réseau ou le générateur à travers l'appareillage, l'onduleur, la distribution et la PDU. Il devrait indiquer quels appareils restent à un seul cordon et si des commutateurs de transfert sont utilisés. Il devrait publier la puissance maximale du rack, le calibre du disjoncteur, la charge stable autorisée et la méthode de comptage. La page de colocation indique que la consommation d'électricité est incluse, mais elle ne quantifie pas d'allocation électrique.

Cette omission rend difficile la traduction d'un espace 1U, 2U ou 3U en un engagement électrique sûr et commercialement exécutoire.

Le test le plus important n'est pas un schéma seul. C'est un transfert contrôlé à charge réaliste alors que l'équipement client reste en ligne, suivi d'une preuve que les batteries, le générateur, le refroidissement et l'équipement réseau se sont comportés comme prévu.

La présence d'un générateur n'est pas la même chose que son endurance

La page de vente actuelle liste un générateur, et le guide de 2012 faisait état d'une unité diesel de 100 kW. Un générateur peut combler une longue interruption du réseau, mais seulement lorsque tout le système de support fonctionne: détection automatique, batteries de démarrage, équipement de transfert, carburant, refroidissement, échappement, maintenance, acceptation de charge et accès pour le ravitaillement. Le mot « générateur » ne divulgue aucune de ces conditions.

L'autonomie est le premier nombre manquant. Un réservoir peut supporter des heures à charge partielle mais beaucoup moins à charge nominale. La consommation de carburant change avec la demande électrique, et la demande de l'installation comprend plus que les serveurs. Le refroidissement doit continuer pendant une perte de réseau; sinon le générateur peut maintenir les équipements informatiques sous tension tandis que la température de la salle augmente vers un arrêt forcé.

Une autonomie publique devrait donc indiquer la charge critique supportée, le carburant minimum sur site, le contrat de ravitaillement et les hypothèses sur le refroidissement.

Lesdirectives sur les systèmes de carburant de l'Uptime Institutedécrivent une attente de stockage minimum de douze heures pour les topologies Tier à la charge N déclarée de l'installation. C'est un point de référence, pas une preuve que LiveHosting y répond ou a besoin d'adopter cette conception exacte. Un petit fournisseur peut choisir un objectif de risque différent. Ce qui importe est que les clients connaissent l'objectif et puissent le comparer avec leurs besoins de récupération.

Les tests comptent autant que la taille du réservoir. Un démarrage mensuel sans charge ne prouve pas que le générateur et le système de transfert supporteront la salle par une journée chaude. Un enregistrement significatif inclurait des tests de transfert en charge, la durée, le pourcentage de charge, la qualité du carburant, les alarmes, les démarrages infructueux et les actions correctives. Il montrerait également si les deux chemins de transport actuels et la surveillance externe restent disponibles lorsque l'alimentation du réseau est coupée.

La conséquence pour le client est directe. Une courte interruption peut être absorbée par les batteries de l'onduleur. Une panne plus longue devient un événement de générateur et de carburant. Si le générateur tombe en panne ou ne peut pas supporter le refroidissement, tous les produits dans la salle peuvent converger vers la même échéance d'arrêt, quel que soit le nombre de machines virtuelles, d'ensembles RAID ou d'alimentations de serveur au-dessus.

Le refroidissement détermine la quantité de capacité électrique utilisable

Le matériel public examiné ici ne donne pas de conception de refroidissement actuelle, de capacité de refroidissement installée, de niveau de redondance, de disposition de confinement ou de plage de fonctionnement environnementale. Cette absence empêche un lecteur de convertir les données électriques historiques en capacité informatique utilisable. Presque chaque watt consommé par l'équipement informatique devient de la chaleur qui doit être évacuée, et la salle peut être contrainte par le refroidissement avant d'atteindre une limite électrique nominale.

Le chiffre de 30 mètres carrés rapporté en 2012 ne dit rien non plus sur la densité actuelle des racks. Une petite salle avec des racks légèrement chargés peut être stable. La même salle remplie de serveurs biprocesseurs, de stockage dense ou de commutation haute vitesse peut développer des points chauds même lorsque la puissance totale du bâtiment reste dans une limite nominale. Le catalogue de serveurs dédiés comprend des systèmes avec plusieurs disques et double processeur, tandis que l'équipement de colocation des clients est moins prévisible.

L'allocation de capacité doit tenir compte à la fois de la chaleur moyenne et de la concentration locale.

La redondance du refroidissement comporte plusieurs couches: l'unité de refroidissement, le compresseur ou la source d'eau glacée, les pompes et ventilateurs, le système de contrôle, l'alimentation électrique et le chemin de rejet de chaleur. Un refroidissement « N+1 » peut toujours cacher des tuyauteries communes, des dépendances de contrôle ou électriques. La maintenance peut être plus révélatrice qu'une panne. Si une unité de refroidissement ne peut pas être isolée et entretenue par une journée chaude sans réduire la salle en dessous de sa charge engagée, la capacité installée dépasse la capacité utilisable simultanément.

Un acheteur devrait demander les plages de température et d'humidité aux entrées du serveur, l'emplacement des capteurs, les seuils d'alarme, les enregistrements historiques, la marge par temps chaud et le résultat d'un test de perte d'unité de refroidissement. La réponse devrait expliquer la politique d'arrêt automatique et l'avis au client si la température augmente. Elle devrait également indiquer si la capacité du générateur inclut tout le refroidissement nécessaire pour la charge informatique engagée.

Les implications en matière d'incendie et d'eau suivent. Les condensats, les fuites de toiture ou de plomberie peuvent affecter rapidement une salle compacte. La détection et la suppression d'incendie doivent être compatibles avec les espaces occupés et les équipements électriques sous tension. Le matériel public mentionne la sécurité physique et la surveillance historiques, mais ne fournit pas de preuves actuelles sur le compartimentage incendie, la détection de fuites, la suppression ou la zone inondable. Les clients ne doivent pas déduire ces contrôles de la seule étiquette de centre de données.

La capacité installée, vendable et récupérable sont des nombres différents

Le fournisseur peut honnêtement avoir de l'équipement installé tout en ayant moins de capacité disponible pour les nouveaux clients et encore moins de capacité disponible en cas de panne. La capacité installée est la somme des plaques signalétiques et des ressources configurées. La capacité vendable est ce que les règles commerciales et techniques permettent après réservations et sursouscription. La capacité récupérable est ce qui reste, ou peut être restauré dans les délais, après la défaillance d'un composant défini.

Les pages publiques de LiveHosting font la publicité du CPU, de la mémoire, du stockage SSD ou NVMe et du trafic « illimité » du serveur. Ces spécifications décrivent un droit ou une configuration de produit. Elles ne montrent pas l'occupation de l'hôte, la réplication du stockage, la contention de la liaison montante ou le débit de sauvegarde. Le trafic « illimité » est particulièrement facile à mal interpréter: cela peut signifier une absence de facturation au volume alors que chaque paquet partage toujours un port, une périphérie et un engagement de transit finis.

L'espace de colocation est également incomplet sans puissance et marge réseau. Trois clients 1U peuvent consommer moins d'énergie qu'un client 3U, ou beaucoup plus, selon le matériel. Un port 1 Gbps est un débit d'interface, pas un débit Internet garanti en cas d'attaque ou après la défaillance d'un opérateur. Une plaque signalétique de générateur n'est pas un engagement de capacité client. Une puissance d'onduleur n'est pas une garantie d'autonomie.

La mesure opérationnelle qui importe est le budget en état de panne. Combien de kilowatts restent si un chemin d'alimentation est isolé? Quelle température de salle peut être maintenue après la perte d'une unité de refroidissement? Quelle capacité Internet reste si Prime Telecom ou Vodafone devient indisponible? Combien de serveurs virtuels peuvent être redémarrés à partir de la sauvegarde en même temps? Combien d'ingénieurs peuvent gérer simultanément des incidents matériels, réseau et clients?

Ces chiffres devraient être liés aux classes de clients. L'hébergement mutualisé peut tolérer un temps de récupération différent d'un site web du secteur public, d'une application transactionnelle, d'un serveur de messagerie ou d'un système d'entreprise en colocation. Une petite installation n'a pas besoin d'une capacité hyperscale pour être utile. Elle a besoin d'engagements adaptés à sa redondance réelle et d'un refus clair de vendre au-delà de l'enveloppe en état de panne.

AS41635 est actif et visible mondialement

Les preuves réseau sont la partie la plus solide du dossier public.RIPE RDAPliste AS41635 comme actif et nomme LIVEHOSTING-AS.L'aperçu AS de RIPEstatidentifie le titulaire comme LIVEHOSTING centres de données SRL et marque l'ASN annoncé. Cela correspond à la page de contact de l'entreprise elle-même.

Le 12 juillet 2026,le statut de routage de RIPEstatmontrait un préfixe IPv4 originaire contenant 1 024 adresses et aucun préfixe IPv6 originaire. La route IPv4 était visible par les 326 pairs IPv4 déclarants dans cet instantané.La vue des préfixes annoncés de RIPEstatidentifiait 89.38.208.0/22 comme l'annonce actuelle. La vue de l'historique de routage retrace l'espace d'adressage originaire de LiveHosting jusqu'en 2006, bien que l'agrégat soit passé d'un /21 au /22 actuel au fil du temps.

C'est une preuve d'exploitation significative. Une route largement visible maintenue sur des années est incompatible avec un enregistrement ASN purement décoratif. Le préfixe héberge le propre site web de l'entreprise et des noms de serveurs publics, et des agrégateurs indépendants l'identifient également.La boîte à outils BGP d'Hurricane Electricrapportait un préfixe IPv4, 1 024 adresses IPv4 originaires, deux pairs IPv4 observés et aucune origine IPv6.IPinfoclasse l'ASN comme hébergement et montre un chemin de juin 2026 atteignant le bloc via AS39737.

La route est également valide RPKI.La validation RIPEstata trouvé une autorisation valide pour AS41635 d'originer 89.38.208.0/22 avec une longueur maximale /22. Commel'explique le RIPE NCC, la validation d'origine répond si le détenteur légitime de la ressource a autorisé une combinaison préfixe-origine particulière. Elle ne valide pas le reste du chemin AS ni ne prouve la résilience physique.

La conclusion doit être étroite: LiveHosting a une origine IPv4 actuelle, valide et hautement visible. C'est plus fort qu'une carte marketing. Cela ne peut toujours pas montrer si les routeurs sont dupliqués, si les opérateurs entrent par des conduits séparés, ou si le chemin survivant peut supporter la demande du client après une panne.

Les deux chemins opérateurs visibles ont encore besoin de preuves physiques

La vue des voisins AS de RIPEstata observé deux réseaux adjacents le 12 juillet 2026: AS12302, Vodafone Roumanie, et AS39737, Prime Telecom. L'instantané d'état BGP montrait la grande majorité des chemins échantillonnés via Prime Telecom et un plus petit nombre via Vodafone. Hurricane Electric listait indépendamment les deux mêmes pairs.

Deux adjacences observées valent mieux qu'une car elles offrent des alternatives de route potentielles. Elles ne devraient pas être appelées deux opérateurs indépendants prouvés sans contrat et preuves de site. Un collecteur de routes observe les chemins AS, pas la propriété des fibres, les entrées de bâtiment, les interconnexions ou la capacité payée. Un opérateur peut revendre un autre. Deux circuits peuvent partager un conduit métropolitain, un regard, un passage de rue, un panneau de brassage ou le même équipement externe sous tension.

L'objet de registre RIPE ajoute une autre raison de prudence. Sa politique d'importation, dernière modification en 2021, nomme AS6830 et AS34279, tandis que les collecteurs actuels voient AS12302 et AS39737. Cette différence peut simplement refléter une politique de registre obsolète après des changements d'opérateurs ordinaires. Elle démontre pourquoi une déclaration de registre ne devrait pas remplacer une observation actuelle ou un calendrier d'opérateur actuel.

La capacité après panne est le problème suivant. Si le chemin principal transporte la plupart du trafic, le secondaire doit avoir suffisamment de capacité engagée et en rafale pour l'absorber. Le BGP peut reconverger avec succès tandis que les applications deviennent inutilisables car le circuit restant est congestionné. La protection DDoS ajoute une autre dépendance: le fournisseur devrait expliquer où se produit le filtrage, si les deux amonts le supportent, comment les routes sont détournées, et si un événement de protection réduit la capacité propre.

Les preuves requises sont pratiques. LiveHosting devrait identifier les deux fournisseurs contractés, les tailles de port et d'engagement, les démarcations physiques, les chemins d'entrée, les routeurs de périphérie et les domaines d'alimentation. Il devrait montrer un test récent dans lequel chaque amont a été retiré séparément à charge occupée, enregistrer la convergence et la perte de paquets, et confirmer que la surveillance et les communications avec les clients restaient joignables.

Pas de profil PeeringDB réduit ce qui peut être vérifié publiquement

Une requête à l'API PeeringDBn'a renvoyé aucune entité réseau pour AS41635 lors de cet examen. Ce n'est pas une preuve de panne réseau. La participation à PeeringDB est volontaire, et un petit réseau d'hébergement peut acheter du transit sans maintenir un profil d'interconnexion public. L'absence réduit la visibilité publique sur les installations, les échanges, les niveaux de trafic, la politique de peering et les contacts réseau.

La forme actuelle semble plutôt orientée transit qu'échange. Les collecteurs publics exposent deux réseaux adjacents, mais aucun enregistrement PeeringDB public n'identifie un échange Internet ou une connexion d'installation. Les clients doivent donc éviter de supposer que le réseau dispose de peering direct, de routes d'échange diversifiées ou d'une salle de rencontre neutre. Ces caractéristiques peuvent exister; le dossier public examiné ici ne les établit pas.

Cela importe pour l'isolation des pannes. Si tous les chemins externes dépendent d'un petit ensemble de remises de transit dans un seul bâtiment, la rencontre locale d'opérateur peut être un point de défaillance commun même lorsque la table de route mondiale montre deux ASN amonts. Si un circuit se termine hors site et atteint la salle de données via une queue locale partagée, la diversité logique peut disparaître au dernier kilomètre.

Le fournisseur peut résoudre une grande partie de cette incertitude sans exposer de détails sensibles. Il peut publier un diagramme réseau neutre pour l'installation montrant des entrées séparées, des équipements de périphérie séparés, les identités des opérateurs, les capacités des ports et la politique de basculement. Il peut maintenir un profil PeeringDB à jour si approprié. Il peut offrir un looking glass ou un service de statut hébergé en externe. Aucune de ces mesures ne prouve chaque conduit, mais ensemble elles rendent le modèle d'exploitation du réseau plus facile à vérifier.

L'absence d'origine IPv6 mérite une réponse directe

La page de colocation de LiveHosting indique qu'un sous-réseau IPv6 /56 est inclus avec chaque forfait. Pourtant, RIPEstat et Hurricane Electric montraient zéro préfixe IPv6 originaire par AS41635 dans les instantanés de juillet 2026. Le régulateur français des télécoms, l'ARCEP, listait également AS41635 avec une exposition IPv6 nulle dans ses mesures de 2025 sur les hébergeurs. Ces observations ne prouvent pas que les clients ne reçoivent aucun service IPv6.

Le /56 annoncé peut provenir de l'espace d'adressage d'un fournisseur amont et être routé vers LiveHosting sans qu'AS41635 n'originate un préfixe IPv6. Il peut être disponible uniquement sur demande. Il peut être configuré à l'intérieur de l'installation tout en n'étant pas visible dans les données publiques échantillonnées. Chaque explication a une conséquence de résilience différente.

L'IPv6 attribué par le fournisseur peut bien fonctionner, mais le basculement peut dépendre du fournisseur attribuant. Si le /56 appartient à un opérateur et que cet opérateur tombe en panne, LiveHosting peut ne pas être en mesure d'annoncer le même sous-réseau client via l'autre chemin. Renumériser un parc de serveurs lors d'un incident n'équivaut pas à un basculement BGP. Les DNS, les règles de pare-feu, les listes d'accès et les logiciels clients peuvent tous conserver les anciennes adresses.

L'acheteur devrait demander quel agrégat contient le /56, quel ASN l'originate, s'il est accessible via les deux amonts visibles, et si l'autorisation d'origine de route couvre l'origine prévue. Il devrait également demander si le port 1 Gbps et la protection DDoS s'appliquent également à l'IPv4 et à l'IPv6. Un service double pile n'est aussi résilient que la pile la moins testée lorsque les applications et les DNS publient les deux.

L'écart est important car l'IPv6 n'est pas une fonctionnalité décorative. La page de colocation le présente comme une capacité incluse. Les preuves de route publiques rendent la surface d'exploitation IPv4 claire; des preuves IPv6 équivalentes transformeraient le /56 d'une ligne de vente en un service réseau vérifiable.

L'engagement de qualité est plus étroit qu'une garantie d'installation

L'engagement de qualitéde LiveHosting s'applique aux forfaits d'hébergement web Windows ou Linux Standard, Business et Revendeur. Il définit la disponibilité comme la proportion mensuelle pendant laquelle le site web d'un client est accessible via HTTP depuis un emplacement neutre. La page indique que LiveHosting utilise des systèmes PRTG dans son centre de données et dans d'autres centres de données roumains et étrangers pour mesurer la disponibilité.

Le barème de crédit rembourse 50 % lorsque la disponibilité se situe entre 98 % et 99,5 %, 75 % entre 95 % et 97,9 %, et 100 % à 94,9 % ou moins. Un crédit de service est commercialement utile, mais ce n'est pas une compensation pour des ventes perdues, des données ou une réputation. Plus important encore, le champ d'application déclaré ne couvre pas automatiquement les serveurs virtuels, les serveurs dédiés ou la colocation. Les acheteurs de ces catégories ont besoin de leurs propres conditions de service.

Les exclusions sont larges. La page exclut, entre autres, l'interruption des communications, l'incendie, l'inondation, les catastrophes naturelles, les virus, les attaquants, les logiciels tiers, la maintenance annoncée ou critique, les mises à niveau de serveur, les DNS hors du contrôle de LiveHosting et plusieurs protocoles d'accès. Certaines exclusions décrivent exactement les chemins de défaillance qu'un client de centre de données a le plus besoin de comprendre. Les exclure des crédits ne les rend pas improbables; cela déplace leur coût économique vers le client.

La définition de mesure se concentre également sur l'accessibilité HTTP. Un site web peut répondre tandis que la messagerie, les connexions à la base de données, le stockage, les panneaux de contrôle, l'accès VPN ou un chemin d'opérateur sont dégradés. Inversement, une panne d'application peut faire échouer HTTP alors que l'alimentation et le réseau de l'installation restent sains. Les clients ont besoin de mesures au niveau des composants et d'un historique des incidents qui sépare les causes d'installation, de réseau, de calcul, de stockage et d'application.

Un ensemble d'assurance plus fort publierait les performances de service historiques par produit, les minutes de maintenance, les causes d'incident et les temps de récupération. Il indiquerait quels emplacements de surveillance sont indépendants d'AS41635 et si le canal de statut reste accessible pendant une panne totale d'installation ou de route.

Le temps de réponse n'est pas le temps de rétablissement

La page de qualité promet un temps de réponse maximum du support technique de 24 heures pendant les heures du lundi au vendredi de 10 h à 18 h. La page de contact actuelle liste le support technique du lundi au vendredi de 10 h à 17 h. Ces pages peuvent décrire des canaux différents ou simplement être désalignées. De toute façon, aucune des deux déclarations n'est une promesse de rétablir le service en 24 heures.

Lapage de gestion de serveursajoute une distinction commerciale plus granulaire. La gestion de base comprend deux heures par mois et une disponibilité en semaine. La gestion Premium comprend quatre heures par mois et indique une disponibilité du lundi au dimanche, 24 h/24. Lecontrat de servicespublic indique que le travail de gestion est limité aux heures de l'abonnement acheté, que le travail supplémentaire est facturable et que la disponibilité ou la performance des applications n'est pas garantie par le service de gestion.

Cela laisse plusieurs questions pour les clients dédiés non gérés et de colocation. L'intervention d'urgence de l'installation est-elle continue même lorsque la gestion du serveur ne l'est pas? Qui reconnaît une alarme d'alimentation, de refroidissement ou de réseau à 3 h du matin? Des mains distantes sont-elles disponibles à tout moment, et quel est l'objectif d'arrivée? La page de colocation tarifie les mains distantes à 25 EUR de l'heure mais ne publie pas d'engagement de réponse 24 h/24.

La distinction est critique dans une petite opération. La détection peut être automatique, mais le diagnostic et l'autorisation peuvent dépendre d'une personne. Un opérateur peut exiger le contact désigné du client. Un bâtiment peut restreindre l'accès après les heures de travail. Un serveur défaillant peut avoir une double alimentation mais nécessiter toujours un remplacement local de disque ou de câble. Chaque transfert ajoute du temps avant le début du rétablissement.

Les clients devraient demander quatre horloges séparées: alarme-accusé de réception, accusé de réception-diagnostic qualifié, diagnostic-intervention sur site et intervention-rétablissement. Ils devraient demander qui possède chaque horloge et ce qui se passe lorsque deux incidents se produisent simultanément. Un numéro de téléphone et une promesse de ticket sont des points d'entrée utiles; ce n'est pas un plan de récupération.

La maintenance peut exposer plus de risques qu'une panne soudaine

La redondance semble souvent la plus forte lorsque tout est sain et la plus faible lorsqu'un composant est délibérément retiré pour maintenance. Les batteries d'onduleurs doivent être remplacées, les générateurs doivent être testés en charge, l'équipement de refroidissement doit être nettoyé, les commutateurs doivent être mis à niveau et les opérateurs ont besoin de fenêtres de maintenance. Pendant ces périodes, le chemin restant peut supporter la charge totale sans réserve.

L'engagement de qualité exclut la maintenance annoncée, les travaux critiques et les mises à niveau de serveur de ses crédits. C'est courant dans les contrats d'hébergement, mais le risque pratique dépend de la manière dont la maintenance est conçue. Un client a besoin de savoir si l'installation peut maintenir chaque composant critique sans arrêter la charge informatique, si plusieurs fournisseurs peuvent travailler en même temps, et comment le retour arrière est géré.

Pour l'alimentation, les preuves de maintenance devraient inclure des chemins de contournement et des procédures qui ne placent pas toute la salle sur le réseau brut. Pour le refroidissement, elle devrait indiquer la charge maximale sûre avec une unité isolée. Pour le travail réseau, elle devrait montrer que les routes des clients restent stables via l'autre routeur et opérateur. Pour le stockage ou la virtualisation, elle devrait quantifier combien de charge de travail peut être déplacée avant la maintenance et combien de temps ce déplacement prend.

La concentration des changements est une autre préoccupation. Un petit fournisseur peut planifier plusieurs tâches dans une même fenêtre pour réduire les perturbations, mais coupler les changements d'alimentation, de réseau et d'hôte supprime les options de récupération indépendantes. Les clients devraient demander si les approbations de changement tiennent compte des dépendances communes et si un canal de communication accessible de l'extérieur est maintenu en dehors des systèmes affectés.

Les preuves qui trancheraient la question sont des documents opérationnels ordinaires: un calendrier de maintenance annuel expurgé, des avis de fenêtres récentes, des rapports de post-maintenance, des actions en cas d'échec de test et un impact visible par le client. C'est plus convaincant qu'un objectif général de disponibilité car cela montre comment l'opérateur gère les périodes où la redondance est intentionnellement réduite.

L'incendie, l'inondation et la perte de réseau convergent vers les données du client

L'engagement de qualité mentionne explicitement l'incendie et l'inondation parmi les exclusions de force majeure. C'est une allocation contractuelle, pas une preuve que l'installation est exposée ou non protégée. Les pages publiques examinées ici ne précisent pas le système actuel de détection et de suppression d'incendie, le classement des compartiments, la détection de fuites, l'évaluation des inondations ou la distance par rapport aux risques d'eau et de carburant.

Celles-ci importent davantage lorsque de nombreuses couches de service occupent un seul site. L'hébergement mutualisé, les VPS, les serveurs dédiés, la colocation, le DNS, la messagerie et les portails clients peuvent tous dépendre de la même salle. Si les données primaires, les sauvegardes et les systèmes de contrôle partagent l'installation, un événement dans le bâtiment peut supprimer le service de production et les moyens de le restaurer.

Le contrat de service public place une responsabilité significative sur les clients et limite les garanties. Il permet également la suspension ou la suppression du service pour non-paiement et réserve des droits étendus pour modifier ou interrompre les services. Ces conditions rendent les sauvegardes indépendantes et les procédures d'exportation testées commercialement importantes même en l'absence d'incident physique.

Un client devrait identifier où vit chaque copie, qui contrôle ses identifiants, à quelle fréquence elle est testée et comment la restauration fonctionne si le propre portail de compte ou le réseau de LiveHosting est indisponible. Une sauvegarde sur un autre serveur dans la même salle protège contre certaines pannes matérielles mais pas contre les événements d'alimentation, de refroidissement, d'incendie ou d'inondation à l'échelle de la salle. Une copie dans un autre bâtiment mais administrée via le même système d'identité inaccessible peut également être difficile à utiliser.

Pour les clients de colocation, la question s'étend à la récupération de l'équipement. Qui peut entrer après un incident? Le matériel du client est-il assuré par le fournisseur, l'exploitant du bâtiment ou le client? Un client peut-il récupérer son équipement lors d'une fermeture prolongée du service public ou d'accès? Les réponses peuvent se trouver dans les contrats individuels, mais elles ne sont pas établies par la page de planification publique.

La panne affecte différents clients de différentes manières

Les clients d'hébergement mutualisé sont susceptibles de ressentir d'abord une panne de plateforme commune sous forme de sites web, de messagerie ou de panneaux de contrôle inaccessibles. Ils peuvent avoir peu de visibilité sur quel serveur physique, commutateur ou système de stockage est tombé en panne. Les revendeurs peuvent amplifier l'impact car un compte peut représenter de nombreux sites en aval et des obligations de support.

Les clients de serveurs virtuels ont plus de contrôle sur les systèmes d'exploitation mais restent dépendants de la capacité de l'hyperviseur, du stockage et du réseau local du fournisseur. Une panne d'hôte peut être récupérable si les charges de travail peuvent redémarrer ailleurs, mais la page produit publique ne promet pas de migration en direct, de stockage répliqué ou de cluster de récupération. La présence de SSD ou NVMe ne dit rien sur le nombre et l'emplacement des copies.

Les clients de serveurs dédiés évitent certains risques de calcul partagé. Ils dépendent toujours du rack, des deux chemins d'alimentation, de la commutation, du transit opérateur et des mains distantes. Les alimentations doubles et le RAID peuvent absorber certaines défaillances de composants sélectionnés, mais ils ne peuvent pas survivre à une panne à l'échelle de la salle ou à une défaillance de la périphérie réseau partagée.

Les listes de serveurs dédiés publiques montrent également des générations G7 et G8 plus anciennes; cela peut être une offre économique, mais les acheteurs devraient demander la disponibilité des systèmes et composants de rechange.

Les clients de colocation possèdent leur propre équipement et peuvent annoncer leur propre espace d'adressage, comme la page produit le permet pour les annonces BGP. Leur dépendance envers LiveHosting est néanmoins physique. Ils ont besoin d'accès, d'alimentation, de refroidissement, d'interconnexions, de routage et d'aide à la réparation. Une panne d'installation peut arrêter un équipement par ailleurs entièrement géré par le client.

Les utilisateurs du secteur public, de la santé, de la finance ou de l'industrie peuvent également être confrontés à des obligations au-delà de la disponibilité. La localisation, la notification des incidents, la conservation des preuves et la continuité des fournisseurs peuvent compter. L'article n'identifie aucun client LiveHosting de ce type. Il souligne pourquoi la même affirmation d'installation peut avoir des conséquences très différentes selon la charge de travail qui y est placée.

Le fournisseur devrait donc résister à une déclaration universelle de résilience. Il devrait divulguer quelles protections s'appliquent à chaque service, ce que le client doit fournir et quelles dépendances partagées traversent toutes les gammes de produits.

Une démonstration significative de basculement doit supprimer les dépendances réelles

La meilleure façon d'établir la résilience actuelle est de tester des défaillances définies plutôt que d'accumuler des étiquettes. Pour LiveHosting, cinq exercices répondraient à la plupart des questions ouvertes.

Premièrement, supprimer l'alimentation normale du réseau à une charge de production représentative. Enregistrer le transfert de l'onduleur, le démarrage du générateur, la continuité du refroidissement, la consommation de carburant, les alarmes et l'impact client. Continuer assez longtemps pour démontrer l'objectif d'autonomie publié, puis rétablir le réseau sans perdre la charge.

Deuxièmement, isoler chaque chemin de distribution électrique et section d'onduleur à tour de rôle. Confirmer que les dispositifs clients à double cordon restent en ligne et identifier l'équipement à un seul cordon nécessitant un dispositif de transfert. Un test de générateur réussi ne remplace pas ce test de distribution interne.

Troisièmement, retirer une unité de refroidissement ou un chemin de refroidissement pendant une période ambiante exigeante. Suivre les températures d'entrée du serveur et confirmer quelle charge reste dans la limite environnementale déclarée de l'installation. Cela convertit une affirmation de redondance de refroidissement en preuve de capacité utilisable.

Quatrièmement, retirer Vodafone et Prime Telecom séparément pendant que le réseau est occupé. Mesurer la convergence BGP, la perte de paquets, la latence et le débit survivant à la fois sur IPv4 et sur le service IPv6 annoncé. Confirmer que la protection DDoS, la surveillance, le DNS et la communication client fonctionnent sur le chemin restant.

Cinquièmement, restaurer un compte d'hébergement mutualisé représentatif, un serveur virtuel et un service de contrôle à partir d'une copie en dehors du domaine de défaillance principal. Mesurer le temps de récupération et la perte de données, et inclure le cas où le portail client normal est indisponible.

Les résultats n'ont pas besoin d'être parfaits pour être précieux. Une faiblesse divulguée suivie d'une action corrective est une preuve plus forte qu'une affirmation non testée de disponibilité complète. Les clients peuvent alors juger si la récupération démontrée correspond à leur propre tolérance et s'ils ont besoin d'un deuxième site indépendant.

La croissance de l'alimentation et les permis doivent être traités comme des contraintes, pas des hypothèses

Le marché européen des centres de données traite de plus en plus la disponibilité de l'électricité comme une contrainte de développement. Lapage sur la performance énergétique de la Commission européennedécrit la demande croissante d'électricité, les impacts sur le refroidissement et l'eau, et les obligations de déclaration pour les installations dépassant le seuil pertinent. Rien dans les preuves publiques examinées ici n'établit que LiveHosting franchit le seuil de déclaration de 500 kW; les chiffres historiques suggèrent une installation beaucoup plus petite.

La petite échelle ne supprime pas la nécessité de gérer l'alimentation. Elle change le problème. Un site compact peut avoir une demande totale plus faible mais moins de place pour ajouter de l'appareillage, du refroidissement, des batteries, de l'échappement ou du stockage de carburant. Un bâtiment urbain ou périurbain peut faire face à des contraintes de bruit, d'émissions, de sécurité incendie et de construction. Une connexion électrique peut être suffisante pour la charge actuelle tout en rendant l'expansion lente ou coûteuse.

Le site actuel ne publie pas d'expansion planifiée, de nouveau bâtiment ou de demande d'électricité. Les acheteurs ne doivent pas en déduire une. Si LiveHosting commercialise une nouvelle capacité haute densité, les preuves devraient identifier si elle provient d'une efficacité améliorée, d'équipements plus anciens déclassés, d'une allocation électrique plus importante, d'un nouveau refroidissement ou d'un autre site. Le mot « disponible » devrait signifier que l'alimentation, le refroidissement et le réseau sont tous mis en service, pas simplement que l'espace de rack est vide.

Les permis affectent également la récupération. Remplacer un générateur, ajouter du stockage de carburant, modifier le service électrique ou modifier les systèmes d'incendie peut nécessiter des approbations et des délais de fournisseur. Le client n'a pas besoin de chaque numéro de permis en public. Il a besoin de l'assurance que l'équipement installé est autorisé, entretenu et supporté, et que la croissance planifiée ne mettra pas la salle existante dans un état de redondance réduite prolongé.

La mesure commerciale appropriée est la capacité prête pour une défaillance définie, pas l'espace théorique pour un autre serveur.

Ce qui augmenterait la confiance

LiveHosting peut faire passer le niveau de preuve vers le haut avec un ensemble de divulgations compact. Il devrait commencer par une fiche technique actuelle de l'installation datée et versionnée par l'exploitant. La fiche devrait indiquer l'adresse de service à un niveau approprié, les limites de l'exploitant et du propriétaire, la superficie de la salle de données, la charge informatique mise en service, le pic mesuré actuel, les limites de puissance des racks, la topologie de refroidissement et les contrôles d'incendie.

La section alimentation devrait montrer les entrées électriques, la topologie des onduleurs, la puissance du générateur, l'autonomie minimale à la charge critique engagée, les arrangements de carburant et la date et le résultat du dernier test de transfert en charge. Elle devrait distinguer les puissances nominales totales installées de la capacité N utile, de la capacité en état de maintenance et en état de panne.

La section réseau devrait concilier les observations actuelles de Vodafone et Prime Telecom avec l'objet de politique RIPE plus ancien. Elle devrait divulguer la capacité contractée des ports et d'engagement, la diversité des routeurs de périphérie, la séparation des entrées physiques, les arrangements DDoS et l'origine du /56 IPv6 annoncé. Une entrée PeeringDB ou un looking glass actuel améliorerait la visibilité externe mais ne remplacerait pas la documentation physique.

La section opérations devrait indiquer la propriété continue des alarmes, les objectifs de réponse de l'installation, la couverture des mains distantes, les stocks de pièces de rechange et l'escalade des fournisseurs. Elle devrait concilier les déclarations de support de 10 h à 17 h et de 10 h à 18 h et clarifier ce que la disponibilité Premium 24h/24 et 7j/7 signifie pour la réponse et le rétablissement.

Enfin, l'exploitant devrait publier des preuves anonymisées de tests et d'incidents: transfert électrique, perte d'unité de refroidissement, basculement d'opérateur, exercices de restauration, maintenance significative et leçons appliquées. La certification indépendante peut renforcer l'ensemble lorsque la portée et la validité actuelle sont claires. Les noms de certification de 2012 ne devraient pas être traités comme actuels sans certificats, sites, normes et dates d'expiration.

Ce niveau de divulgation n'exposerait pas les données des clients ni les plans d'étage sensibles. Il permettrait aux acheteurs de distinguer un petit centre de données fonctionnel avec des limites testées d'un dont la résilience est déduite principalement des étiquettes de produits.

Le niveau de preuve est Moyen

LIVEHOSTING centres de données SRL obtient un niveau de preuve réseau et d'infrastructure Moyen. Les preuves d'exploitation spécifiques à l'entreprise sont substantielles: un site de vente roumain actuel, une entité légale nommée, une offre de colocation explicite à Timisoara, AS41635, une route IPv4 visible mondialement, deux réseaux adjacents observés, une autorisation d'origine de route valide et des années d'historique de routage. Ce n'est pas un cas où l'existence du fournisseur ou le fonctionnement réseau de base repose sur une seule entrée de répertoire.

Le niveau s'arrête à Moyen car les affirmations de résilience ne sont pas assorties de preuves physiques actuelles. L'onduleur et le générateur sont listés, mais la topologie et l'autonomie sont absentes. Deux alimentations de serveur sont listées, mais la séparation A/B ne l'est pas. Un guide de 2012 offre des données détaillées, mais aucune preuve de mise en service ou de charge actuelle ne relie ces chiffres à l'installation de 2026.

Le refroidissement, l'incendie, l'inondation, les entrées fibre, les engagements des opérateurs, les performances de maintenance, la récupération externe et les résultats de basculement client restent non divulgués dans les sources examinées.

Les deux adjacences BGP actuelles soutiennent une diversité de chemin logique, tandis que l'absence de preuve physique de route empêche une conclusion plus forte. La route IPv4 valide réduit le risque d'origine, tandis que l'absence d'origine IPv6 de l'AS41635 laisse l'arrangement /56 annoncé non résolu. L'engagement de qualité donne aux clients un mécanisme de mesure et de crédit, tandis que sa portée produit et ses exclusions limitent ce qu'il dit sur la récupération à l'échelle de l'installation.

Ce niveau n'est pas un verdict sur la qualité de service. C'est une déclaration sur la distance entre ce qui peut être observé et ce qui doit encore être démontré. LiveHosting peut posséder des enregistrements d'ingénierie actuels plus solides que ce qu'il publie. Un acheteur devrait demander à les voir avant de placer une charge de travail dont le coût de panne dépasse la valeur des crédits de service.

La conclusion étroite est que la capacité commercialisée est crédible en tant que service en direct, mais pas encore prouvée en tant que capacité en état de panne. La prochaine preuve utile n'est pas une autre configuration de serveur. C'est un test actuel d'alimentation, de refroidissement et de transport montrant ce qui reste en ligne lorsque l'une des dépendances communes est délibérément retirée.