cnh-primary CLOUD & HEAT Technologies GmbH vend de la capacité hébergée qui dépend toujours des baies, du transit et des fenêtres de réparation

Résumé

• cnh-primary correspond à l'AS203592, le système autonome enregistré auprès du RIPE nommé "cnh-primary" et attribué à CLOUD & HEAT Technologies GmbH. Le RDAP du RIPE montre l'AS comme actif, et RIPEstat l'a montré annoncé le 15 juillet 2026 à 00h00 UTC.
• La surface de routage est actuelle et inhabituellement bien documentée pour ce lot: RIPEstat a listé 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 et 2a0c:2c0:dd80::/44 comme annoncés par l'AS203592, avec un RPKI valide pour les quatre origines observées.
• PeeringDB enregistre l'AS203592 comme CLOUD & HEAT Technologies GmbH, avec une installation listée, IBH Dresden C2, et une connexion DD-IX à 10 Gbps avec adresses IPv4 et IPv6 et participation au route-server.
• Les pages de l'entreprise décrivent des IaaS, du Kubernetes managé, du travail de distribution OpenStack sur site, des instances GPU, du stockage Ceph, un hébergement en centre de données allemand, des badges ISO 27001 et ISO 9001, un travail cloud compatible SCS et des clients tels que Scalytics, tracetronic, Nyris, elevait, alphaspeech, flow.d et N+P.
• Le niveau de preuve est Fort pour l'identité réseau et l'existence des produits, Moyen pour l'installation et l'interconnexion locale, et seulement Moyen pour la résilience car les documents publics ne divulguent pas le nombre de baies, la topologie d'alimentation, les pools de serveurs de rechange, le placement exact des zones de disponibilité, la preuve de sauvegarde, les tests d'exportation clients ou l'historique des incidents.

Le nom commence comme une route, mais l'entreprise est plus large qu'une route

L'entrée du répertoire surhttps://btw.media/en/directory/cnh-primary-cloud-heat-technologies-gmbhpointe vers une identité d'infrastructure publique très spécifique: cnh-primary CLOUD & HEAT Technologies GmbH. La partie "cnh-primary" n'est pas un embellissement marketing. C'est le nom AS RIPE pour l'AS203592, affiché dans la base de données RIPE àhttps://rest.db.ripe.net/ripe/aut-num/AS203592.jsonet dans RDAP àhttps://rdap.db.ripe.net/autnum/203592. L'AS a été enregistré le 4 décembre 2015 et modifié pour la dernière fois le 28 janvier 2026. RDAP identifie le titulaire comme CLOUD & HEAT Technologies GmbH, avec l'adresse de Dresde également visible sur les pages de contact de l'entreprise. Cela donne à l'article un point de départ plus solide que de nombreux profils cloud de petite taille: il y a une entreprise nommée, un AS nommé, une identité de bureau public et un enregistrement actif de numéro Internet.

La deuxième couche est la preuve produit. La page d'accueil anglaise de CLOUD & HEAT àhttps://www.cloudandheat.com/en/décrit l'entreprise comme un fournisseur de services cloud et de technologies cloud basé à Dresde avec des produits construits sur OpenStack, Proxmox VE et Kubernetes. Sa page IaaS àhttps://www.cloudandheat.com/en/products/cloud-services-in-germany/infrastructure-as-a-service/vend des tailles de calcul, du stockage bloc et objet, des instances GPU et une capacité cloud hébergée en Allemagne. Sa page Kubernetes managé àhttps://www.cloudandheat.com/en/products/cloud-services-in-germany/managed-kubernetes-germany/décrit des modèles Kubernetes autogérés, à la demande, de base et de service complet. Sa page Patron àhttps://www.cloudandheat.com/en/products/on-premises-cloud-infrastructures/on-premises-cloud-tailored/cloudandheat-a-ready-to-use-openstack-distribution/vend une distribution OpenStack et un support opérationnel optionnel. Ce n'est pas simplement un AS dormant attaché à une page vide.

Cela dit, l'entreprise a plus d'une couche opérationnelle, et ces couches ne doivent pas être confondues. L'AS203592 est la couche de routage publique. Les pages IaaS et Kubernetes sont des pages produits. Les pages Patron et sur site sont des offres de conseil, de logiciel et d'exploitation gérée. Les pages d'efficacité énergétique et les profils OpenInfra décrivent un positionnement durable et open source. Un client achetant une machine virtuelle dépend de choses différentes d'un client achetant une distribution OpenStack supportée pour son propre matériel.

Un client utilisant Kubernetes managé dépend de l'accès API, des clusters, des volumes persistants, de la surveillance et des fenêtres de maintenance. Un client achetant du conseil dépend des personnes et des processus plus que de l'AS203592. Les preuves publiques sur l'entreprise sont réelles, mais chaque produit a un chemin de défaillance différent.

La question clé n'est donc pas de savoir si CLOUD & HEAT existe. Elle existe clairement. La question est de savoir quelles preuves publiques soutiennent l'entreprise lorsqu'elle est lue comme infrastructure hébergée. RIPE, RIPEstat et PeeringDB soutiennent une carte réseau AS203592. Le site de l'entreprise soutient un catalogue de cloud public et de services gérés. L'OpenStack Marketplace àhttps://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-servicesliste les services cloud Cloud & Heat et indique que le produit est OpenStack Powered. Le profil d'entreprise de soutien d'OpenStack àhttps://www.openstack.org/community/supporting-organizations/profile/cloud-and-heatdécrit Cloud & Heat comme un fournisseur dresdois de services cloud et de technologies cloud. Aucune de ces sources, cependant, ne fournit un audit public complet de la capacité.

C'est la distinction qui importe pour les acheteurs. Un AS public peut être en bonne santé tandis qu'une zone de disponibilité n'a pas de machines de rechange. Un cloud OpenStack peut être listé tandis qu'une classe GPU particulière est épuisée. Une offre Kubernetes managée peut promettre une surveillance tandis qu'un client a toujours besoin de sa propre sauvegarde, de son plan de déploiement et d'exportation. Une entrée d'installation peut montrer une présence à Dresde sans révéler le nombre de baies, la conception de l'alimentation électrique ou les modalités d'assistance à distance.

Le dossier public est assez solide pour placer cnh-primary dans une catégorie d'infrastructure sérieuse, mais il doit toujours être lu avec prudence technique.

Les preuves de routage sont actuelles, visibles et plus claires qu'une simple page d'entreprise

La vue d'ensemble AS de RIPEstat pour l'AS203592 àhttps://stat.ripe.net/data/as-overview/data.json?resource=AS203592identifie le détenteur comme "cnh-primary CLOUD & HEAT Technologies GmbH" et a montré announced=true à 2026-07-15 00:00 UTC. C'est un signal spécifique dans le temps mais important: l'AS n'était pas seulement enregistré; il était visible dans les données de routage publiques à la date de publication. Le point de terminaison des préfixes annoncés de RIPEstat àhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS203592a listé quatre routes dans la fenêtre de deux semaines se terminant le 15 juillet 2026: 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 et 2a0c:2c0:dd80::/44.

Le point de terminaison du statut de routage àhttps://stat.ripe.net/data/routing-status/data.json?resource=AS203592a renforcé le signal. Il a rapporté deux préfixes IPv4, deux préfixes IPv6, 1 280 adresses IPv4, 524 288 unités IPv6 /48, quatre voisins observés et une visibilité observée complète dans l'ensemble de pairs RIPE RIS pour IPv4 et IPv6 au moment de la requête. Ces chiffres ne sont pas la capacité client. Ils montrent que l'AS203592 était largement visible depuis les collecteurs de routes et non une note de bas de page à pair unique.

Les vues de préfixes individuelles concordent. RIPEstat a montré 185.128.116.0/22 annoncé par l'AS203592 àhttps://stat.ripe.net/data/prefix-overview/data.json?resource=185.128.116.0/22et 94.198.185.0/24 annoncé par l'AS203592 àhttps://stat.ripe.net/data/prefix-overview/data.json?resource=94.198.185.0/24. Il a également montré l'agrégat IPv6 2a0c:2c0::/29 àhttps://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0::/29et le plus spécifique 2a0c:2c0:dd80::/44 àhttps://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0:dd80::/44. La relation plus spécifique IPv6 est importante car elle suggère une utilisation segmentée d'IPv6 plutôt qu'une allocation unique indifférenciée.

Le RPKI est également aligné. RIPEstat a retourné valide pour l'AS203592 et 185.128.116.0/22 àhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=185.128.116.0/22, valide pour 94.198.185.0/24 àhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=94.198.185.0/24, valide pour 2a0c:2c0::/29 àhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0::/29et valide pour 2a0c:2c0:dd80::/44 àhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0:dd80::/44. La validité du RPKI n'empêche pas une panne de baie, mais elle réduit une classe de panne de routage: les réseaux stricts sont moins susceptibles de rejeter ces origines comme invalides.

La base de données RIPE montre également une continuité administrative derrière les préfixes. La vue WHOIS de 185.128.116.0/22 àhttps://stat.ripe.net/data/whois/data.json?resource=185.128.116.0/22montre netname DE-CLOUDANDHEAT-20151125, pays DE, organisation ORG-CHTG1-RIPE et un objet route originaire de l'AS203592. La vue 94.198.185.0/24 àhttps://stat.ripe.net/data/whois/data.json?resource=94.198.185.0/24montre netname DE-CLOUDANDHEAT-20081029, pays DE et un objet route originaire de l'AS203592 après une mise à jour de janvier 2026. La vue 2a0c:2c0::/29 àhttps://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0::/29montre une allocation RIPE de 2018 à la même organisation et des objets route6 pour l'AS203592. La vue 2a0c:2c0:dd80::/44 àhttps://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0:dd80::/44est particulièrement intéressante car elle est nommée IBH-DD8 et a une date de création de décembre 2025. Cela pointe vers un segment plus récent localisé à Dresde, mais cela ne révèle toujours pas les charges de travail derrière.

Pour un client, la conclusion sur le routage est simple. L'AS203592 est un réseau vivant, et les preuves de routage publiques sont solides. La conclusion plus difficile concerne la capacité de service. Les préfixes et les ROA ne nous disent pas combien d'hyperviseurs sont installés, combien de locataires sont actifs, quelles saveurs sont en rupture de stock, où se trouve physiquement le pool GPU, ou à quelle fréquence le stockage bloc est testé après une panne de nœud. Ils répondent à la question de l'identité réseau. Ils ne répondent pas à la question de l'approvisionnement.

L'installation et l'enregistrement d'échange à Dresde sont réels, mais ce n'est pas tout le cloud

PeeringDB ajoute l'indice physique public le plus clair. La recherche de réseau àhttps://www.peeringdb.com/api/net?asn=203592liste CLOUD & HEAT Technologies GmbH comme AS203592, avec une portée régionale, IPv6 activé, une politique de peering ouverte, un échange et une installation. L'objet réseau àhttps://www.peeringdb.com/api/net/40650montre l'installation définie sur IBH Dresden C2 et l'échange défini sur DD-IX. Le point de terminaison netfac àhttps://www.peeringdb.com/api/netfac?net_id=40650répète l'association IBH Dresden C2. Le point de terminaison netixlan àhttps://www.peeringdb.com/api/netixlan?asn=203592liste DD-IX, un champ de vitesse 10 Gbps, adresse IPv4 193.201.151.80, adresse IPv6 2001:7f8:79::3:1b48:1, route-server peer true et operational=true.

Cette combinaison est inhabituellement utile. Elle place l'AS203592 dans un environnement d'interconnexion nommé à Dresde plutôt que de laisser les lecteurs avec seulement une adresse d'entreprise. L'enregistrement d'installation de PeeringDB àhttps://www.peeringdb.com/api/fac/14039identifie IBH Dresden C2 comme une installation d'IBH connect GmbH à Dresde, avec le chemin du site web public pour l'hébergement et l'espace baie àhttps://www.ibh.de/rechenzentrum/housing-rackpace. L'enregistrement d'échange DD-IX àhttps://www.peeringdb.com/api/ix/4282identifie DD-IX comme un échange à Dresde, liste IBH Dresden C2 et SachsenEnergieCenter Dresden dans son ensemble d'installations, et pointe vershttps://dd-ix.net,https://dd-ix.net/statsethttps://status.dd-ix.net. Le site DD-IX décrit l'échange comme une plateforme non commerciale pour Dresde, conçue pour maintenir le trafic local local et servir la région de Saxe.

La lecture physique doit encore rester précise. PeeringDB prouve que l'AS203592 a une association d'installation listée à IBH Dresden C2 et une connexion DD-IX. Cela ne prouve pas que tous les calculs IaaS de CLOUD & HEAT se trouvent dans cette seule installation. Cela ne prouve pas la disposition du stockage. Cela ne révèle pas si le port DD-IX est directement câblé aux hyperviseurs clients, à un routeur frontalier, à un segment de laboratoire, à un réseau de gestion ou à une bordure d'échange.

Cela ne révèle pas la diversité des câbles transversaux, la diversité des commutateurs, les alimentations électriques des baies, la couverture des générateurs, la redondance du refroidissement ou les engagements de réparation à distance.

L'entreprise elle-même élargit le tableau au-delà d'une seule installation PeeringDB. Sa page IaaS indique que l'infrastructure cloud publique est exploitée exclusivement dans des centres de données en Allemagne et que les données clients sont traitées et stockées conformément au RGPD. Sa page Kubernetes managé indique que les données Kubernetes sont traitées et stockées dans des centres de données certifiés ISO 27001 conformes au RGPD en Allemagne. Son article SCS 2024 àhttps://www.cloudandheat.com/en/news-press/strengthening-digital-sovereignty-new-ways-in-the-cloud-with-yaook-and-scs-compatibility/discute d'un projet de centre de données à Leipzig avec envia TEL, Yaook et SCS. Sa nouvelle de certification 2026, issue du même site, indique que Cloud&Heat a reçu la reconnaissance "Certified SCS-compatible IaaS" et que le prix serait présenté au SCS Summit le 21 juin 2026. Ces points rendent l'empreinte plus qu'une simple histoire de port AS, mais ils ne transforment pas toute la carte de capacité en connaissance publique.

L'alimentation et le refroidissement font partie de la dépendance physique, pas seulement une affirmation de durabilité. La page IaaS indique que Cloud&Heat utilise un refroidissement direct par eau chaude et l'intégration dans les circuits de chauffage locaux pour permettre un fonctionnement économe en énergie et la réutilisation de la chaleur perdue des serveurs. La page de l'OpenStack marketplace décrit également des serveurs refroidis par eau et la réutilisation de la chaleur perdue des serveurs.

C'est un contexte utile: si le cloud est conçu autour de la réutilisation de la chaleur, l'installation bâtiment, le circuit d'eau, l'échangeur de chaleur, le prélèvement de chaleur local et les fenêtres de maintenance deviennent partie de la dépendance de service. Un client de centre de données conventionnel se renseigne principalement sur la redondance de l'alimentation et du refroidissement. Un client de Cloud&Heat devrait également demander comment la maintenance de la réutilisation de la chaleur est isolée de la disponibilité du calcul.

Les preuves de Dresde soutiennent donc une affirmation intermédiaire. Il existe une preuve publique d'un point d'interconnexion à Dresde et une preuve publique d'entreprise d'hébergement cloud allemand. Il n'y a pas assez de preuves publiques pour cartographier chaque charge de travail client sur une baie, chaque zone de disponibilité sur un bâtiment, ou chaque instance GPU sur une chaîne d'alimentation et de refroidissement spécifique. Les acheteurs peuvent considérer Dresde comme un centre opérationnel significatif, pas comme un diagramme d'infrastructure complet.

Les preuves produit sont plus solides pour OpenStack et Kubernetes que pour la capacité de rechange

Les pages produit de CLOUD & HEAT sont inhabituellement concrètes pour un fournisseur cloud régional. La page IaaS liste des tailles de calcul de 1 vCPU / 2 Go RAM / 15 Go SSD à 8 vCPU / 30 Go RAM / 100 Go SSD, propose des familles de prix standard et Memory+, fait de la publicité pour le stockage bloc/objet HDD, et indique que les clusters de stockage sont des clusters Ceph triple redondance pour le stockage objet et bloc. Elle liste également des classes d'instances GPU incluant T4, A10, V100 et A100. Cette page indique explicitement qu'un pool NVMe triple répliqué peut être fourni dans les capacités disponibles.

Cette phrase est importante: l'entreprise vend des ressources utiles, mais elle reconnaît également que certaines classes de stockage ont une capacité limitée.

La page Kubernetes managé est tout aussi spécifique. Elle décrit une option autogérée sur OpenStack, un support à la demande, Managed Kubernetes Basic avec support 9/5 et temps de réponse de quatre heures, et Managed Kubernetes Full Service avec différents niveaux de support. Les deux niveaux gérés listent un déploiement sur plusieurs zones de disponibilité pour une haute disponibilité, une protection API via VPN, une administration de cluster basée sur GitOps, un service de load balancer, des volumes persistants OpenStack Cinder, un stockage local statique et dynamique et des politiques réseau.

Full Service ajoute ingress, Certmanager, une pile de surveillance Prometheus et Grafana, une surveillance et des alertes de cluster 24/7, et des instances GPU. Ce sont des affirmations opérationnelles, pas seulement des slogans.

La page Patron renforce l'aspect OpenStack de l'histoire. Elle indique que Cloud&Heat Patron est une distribution OpenStack prête à l'emploi, basée sur la gestion du cycle de vie open source avec Yaook, avec des composants de qualité entreprise, la compatibilité SCS, l'automatisation, pas de verrouillage fournisseur et des options de support. La page propose un modèle où le client opère le cloud et un modèle où Cloud&Heat fournit l'opération et la surveillance, l'analyse des pannes, la réparation des pannes et la maintenance comme les mises à jour. Elle mentionne des options de contrat de support 9-5 et 24/7.

Cela nous indique que CLOUD & HEAT ne se contente pas de revendre des machines virtuelles; elle vend des connaissances opérationnelles autour d'OpenStack lui-même.

Les sources OpenInfra corroborent le positionnement open infrastructure. La page de l'OpenStack Marketplace àhttps://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-servicesliste les services cloud Cloud & Heat et indique que le produit est OpenStack Powered. La page d'entreprise de soutien d'OpenInfra àhttps://www.openstack.org/community/supporting-organizations/profile/cloud-and-heatdécrit sa pile technologique comme incluant OpenStack, Kubernetes, Yaook et Krake, et indique que l'entreprise contribue aux efforts de Sovereign Cloud Stack. La page du Forum des normes SCS àhttps://sovereigncloudstack.org/en/about-scs/forum-scs-standards/liste Cloud&Heat Technologies GmbH parmi les membres engagés pour des infrastructures cloud sécurisées et note la collaboration avec l'Open Infrastructure Foundation.

Le signal client est également public. La page IaaS nomme Scalytics, tracetronic, Nyris, elevait, alphaspeech et flow.d parmi les clients. La page Kubernetes managé nomme N+P Informationssysteme GmbH et elevait GmbH & Co. KG. La page d'accueil contient des citations de N+P, elevait et STACKIT: N+P et elevait décrivent Cloud&Heat comme leur fournisseur Kubernetes managé, tandis que STACKIT décrit Cloud&Heat comme un partenaire technologique cloud aidant avec les connaissances OpenStack. La page de l'OpenStack Marketplace renvoie à des études de cas clients pour elevait, N+P, Nyris et flow.d.

Ce sont des signaux significatifs de parties affectées, mais ce n'est pas un inventaire des locataires.

La distinction entre installé et utilisable est là où l'analyse doit ralentir. La capacité installée correspond aux serveurs, au stockage, aux GPU, aux commutateurs, aux ports DD-IX, aux fournisseurs d'accès, aux clusters OpenStack, aux plans de contrôle Kubernetes et aux outils de support sous le contrôle ou la gestion de l'entreprise. La capacité utilisable est la partie qu'un client peut commander, allouer, maintenir en fonctionnement, récupérer et quitter sans temps d'arrêt inacceptable. Les pages publiques montrent des classes de produits, des modèles de support, des noms de clients et des choix technologiques.

Elles ne montrent pas le stock GPU actuel, les quotas par saveur, le nombre total d'hyperviseurs, la conception du domaine de défaillance Ceph, les ratios de surallocation, les calendriers de maintenance, la rétention des sauvegardes ou la récupération testée entre zones.

La mention "dans les capacités disponibles" sur la note de stockage NVMe est une fenêtre utile sur la réalité de l'économie du cloud plus petit. Un fournisseur cloud peut faire la publicité d'une classe de stockage et toujours limiter cette classe parce que les disques haute performance sont chers, l'alimentation de l'installation est limitée, la réplication du stockage consomme de la capacité brute, et la demande des clients change. Cela ne rend pas l'offre faible. Cela la rend physique.

Un acheteur devrait traduire chaque ligne de service en une question de capacité: combien est installé, combien est réservé, combien peut être livré ce mois-ci, et que se passe-t-il lorsque la demande augmente?

Le risque en amont, de support et de réparation se situe sous la couche marketing

La politique de routage publique dans la base de données RIPE liste AS3320, AS15372, AS6830 et AS8220 autour de l'AS203592. Le point de terminaison des voisins observés de RIPEstat àhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS203592a vu AS15372, AS3320, AS8220 et AS213973 le 14 juillet 2026. RIPEstat identifie AS15372 comme IBH connect àhttps://stat.ripe.net/data/as-overview/data.json?resource=AS15372, AS3320 comme Deutsche Telekom àhttps://stat.ripe.net/data/as-overview/data.json?resource=AS3320, AS8220 comme Colt àhttps://stat.ripe.net/data/as-overview/data.json?resource=AS8220, AS6830 comme Liberty Global àhttps://stat.ripe.net/data/as-overview/data.json?resource=AS6830et AS213973 comme BCIX Management àhttps://stat.ripe.net/data/as-overview/data.json?resource=AS213973. C'est un mélange crédible de signaux de connectivité locaux, nationaux et commerciaux.

La réserve est qu'une liste de voisins publics n'est pas une carte contractuelle. Elle ne dit pas quel chemin est un transit payant, quel chemin est un peering, quel chemin est une sauvegarde, quels préfixes sont acceptés où, quels filtres de route sont stricts, quelles fenêtres de maintenance se chevauchent, ou si le trafic client est épinglé à une bordure particulière. Elle ne prouve pas non plus qu'un point de terminaison d'API Kubernetes et un backend de stockage IaaS ont une protection réseau identique. La bonne nouvelle est que l'AS203592 n'est pas publiquement visible comme une île à voisin unique.

La question d'approvisionnement est de savoir si le service client pertinent a suffisamment de diversité de chemin réelle pour survivre à la défaillance spécifique qui préoccupe le client.

La défaillance d'installation est la couche suivante. Si une charge de travail s'exécute dans un centre de données allemand connecté à l'AS203592, le service dépend de l'alimentation des baies, du refroidissement, des câbles transversaux montants, des commutateurs, des routeurs, des réseaux de stockage et de l'accès du personnel. L'installation PeeringDB pour IBH Dresden C2 liste diverse serving substations=true, ce qui est un indice positif au niveau de l'installation.

Cela ne divulgue toujours pas la conception d'alimentation des baies de CLOUD & HEAT, la couverture double cordon, le bypass de maintenance, l'autonomie des batteries, l'historique des tests du générateur, ou si une VM client particulière peut être déplacée de l'installation affectée pendant un incident local. La connexion DD-IX aide pour l'échange de trafic local, mais une panne d'échange et une panne de centre de données sont des événements différents.

La défaillance de support est tout aussi importante. La page Kubernetes managé donne un niveau de support 9/5 avec un temps de réponse de quatre heures pour Basic et une surveillance et des alertes 24/7 pour Full Service. La page Patron propose des options de contrat de support 9-5 et 24/7 pour les environnements OpenStack opérés. La page IaaS promet des conseils personnalisés et orientés service de la part d'experts OpenStack et DevOps. Ce sont des engagements publics utiles, mais le client a toujours besoin du contrat.

La page ne divulgue pas les objectifs d'escalade pour une panne de stockage, l'évacuation d'hyperviseur, le remplacement de GPU, une fuite de route, une panne DNS, un ticket d'abus, un verrouillage de facturation ou une exportation de données d'urgence.

La preuve DNS ajoute un indice opérationnel petit mais utile. Une requête DNS lors de cette revue a résoluwww.cloudandheat.comvia cloudandheat.com vers 185.128.119.78, qui se trouve à l'intérieur du préfixe 185.128.116.0/22 annoncé par l'AS203592. La même requête a montré mail.cloudandheat.com comme MX, des serveurs de noms INWX et des enregistrements SPF qui incluent l'hôte mail et Google. Cela suggère que le site web public est servi depuis l'espace routé de l'entreprise plutôt que seulement depuis un grand CDN tiers. C'est positif pour l'identité réseau, mais cela signifie aussi que le site public de l'entreprise peut être affecté par son propre AS, son hôte web ou ses dépendances d'installation.

Le chemin d'impact client découle de la pile produit. Une panne réseau peut affecter l'accessibilité du cloud public, les API Kubernetes managées, les load balancers, l'entrée client, les points de distribution de logiciels, et éventuellement le propre site web ou les surfaces de support du fournisseur. Une panne de stockage peut affecter les volumes et le stockage objet. Un incident d'alimentation ou de refroidissement peut affecter les hyperviseurs et les machines GPU. Une pénurie de support ou d'opérations peut prolonger le temps de restauration même si le matériel est réparable.

Une panne de contrat ou de facturation peut bloquer les changements, les exportations ou la mise à l'échelle urgente. Le matériel public prouve que l'entreprise a de l'expérience dans ces domaines; il ne prouve pas que chaque chemin de défaillance a été répété.

Ce n'est pas une critique propre à CLOUD & HEAT. C'est la forme normale de la dépendance cloud régionale. Le fournisseur peut être plus transparent, plus aligné sur l'open source et plus local qu'une plateforme hyperscale, tout en étant soumis aux mêmes contraintes physiques: espace, alimentation, refroidissement, optique, pièces de rechange, filtres de route, fenêtres de maintenance et disponibilité humaine.

La localité des données est un point fort, mais la localité n'est pas la récupérabilité automatique

La promesse la plus forte de CLOUD & HEAT envers les lecteurs est la localité et la souveraineté numérique. La page IaaS indique que l'infrastructure cloud publique est exploitée exclusivement dans des centres de données en Allemagne et que les données sont traitées et stockées conformément au RGPD. La page Kubernetes managé indique que les données sont traitées et stockées dans des centres de données certifiés ISO 27001 conformes au RGPD en Allemagne. La page d'accueil indique que les clients peuvent utiliser l'infrastructure de CLOUD & HEAT ou des déploiements sur site.

Les sources SCS et OpenInfra présentent l'entreprise autour des normes ouvertes, de la portabilité et de la souveraineté numérique.

Ces affirmations comptent. Un client allemand ou européen essayant d'éviter un hébergement offshore opaque a un modèle de risque différent lorsque la page cloud public indique Allemagne, OpenStack et pile open source plutôt qu'une région générique mondiale. Le matériel lié à SCS est important pour l'interopérabilité. L'article de l'entreprise de 2024 indique que les normes SCS visent à augmenter l'interopérabilité et la portabilité des applications cloud. La nouvelle de certification 2026 indique que Cloud&Heat a reçu la reconnaissance Certified SCS-compatible IaaS.

Le profil OpenInfra indique que l'entreprise contribue à des normes telles que SCS. Tout cela est pertinent pour le sujet de la souveraineté et de la localité des données.

Mais la localité ne doit pas être confondue avec la récupération. Un client peut savoir que les données sont en Allemagne et ne toujours pas savoir si elles sont répliquées entre Dresde et Leipzig, entre deux salles de Dresde, sur deux zones de disponibilité dans un seul bâtiment, ou à l'intérieur d'un seul cluster de stockage avec des domaines de défaillance. La page Kubernetes managé indique un déploiement sur plusieurs zones de disponibilité pour une haute disponibilité, mais elle ne définit pas ces zones publiquement.

La page IaaS indique des clusters Ceph triple redondance et un pool NVMe triple répliqué optionnel dans la capacité disponible, mais elle ne divulgue pas si les répliques sont locales à la baie, locales à la salle, locales au bâtiment ou séparées sur le campus. Les pages publiques ne montrent pas l'emplacement des sauvegardes ni l'historique de restauration.

Cela importe pour les clients ayant des obligations de conformité. Si une charge de travail nécessite un stockage allemand, les pages publiques de CLOUD & HEAT soutiennent l'affirmation de départ. Si la charge de travail nécessite un État allemand particulier, une zone électrique, une séparation de zone de disponibilité, une ségrégation de sauvegarde, une exportation en air gap ou un plan de continuité sectoriel réglementé, les pages publiques ne suffisent pas.

Le client devrait demander une déclaration sur l'emplacement des données, les sous-traitants, l'emplacement des sauvegardes, la portée de la réplication du stockage, l'accès du personnel, les fenêtres de maintenance et la restauration testée. Si la charge de travail utilise Kubernetes managé, le client devrait également demander où résident le plan de contrôle, etcd, les volumes persistants, le registre d'images, les données de surveillance et les logs.

Le chemin de migration est plus clair grâce aux choix technologiques. OpenStack, Kubernetes, les volumes Cinder, le stockage Ceph, GitOps et la compatibilité SCS peuvent tous réduire le verrouillage s'ils sont implémentés avec des droits d'exportation et des outils testés. Un client peut exécuter une infrastructure en tant que code, maintenir des sauvegardes externes, garder le DNS sous son propre contrôle, conteneuriser les applications et préparer un environnement OpenStack ou Kubernetes de destination.

Mais les pages publiques ne promettent pas que chaque image, volume, snapshot, seau d'objets, IP flottante, load balancer ou charge de travail GPU peut être exporté rapidement. Les technologies standards rendent la migration possible; elles ne la rendent pas automatique.

La bonne conclusion est donc mitigée. CLOUD & HEAT a une histoire de souveraineté crédible car elle combine hébergement allemand, OpenStack, Kubernetes, travail SCS et interconnexion locale. La même histoire doit être testée à la frontière du service: quel service est hébergé en Allemagne, quelle partie est sur site chez un client, quelle partie dépend d'IBH ou de DD-IX, quelle partie dépend du courrier ou du DNS tiers, et quelle partie peut bouger pendant une panne du fournisseur? La souveraineté ne concerne pas seulement le pays. Elle concerne le contrôle en période de stress.

Qui est affecté si cnh-primary tombe en panne?

Le premier groupe affecté est celui des clients cloud public et IaaS. La page IaaS nomme des clients incluant Scalytics, tracetronic, Nyris, elevait, alphaspeech et flow.d. Elle vend des ressources de calcul, GPU et stockage et positionne le cloud pour la protection des données allemande et la souveraineté numérique. Si l'AS203592 ou le chemin d'installation pertinent tombe en panne, les machines virtuelles des clients peuvent rester allumées mais devenir inaccessibles. Si la couche de stockage tombe en panne, la disponibilité des données et l'attachement des volumes deviennent le problème.

Si la capacité est épuisée, le client peut être incapable de monter en charge même si les instances existantes continuent de fonctionner.

Le deuxième groupe est celui des clients Kubernetes managé. La page Kubernetes managé nomme N+P Informationssysteme GmbH et elevait GmbH & Co. KG. Elle décrit un accès API via VPN, des volumes persistants OpenStack Cinder, des load balancers, une surveillance, un ingress, Certmanager et un déploiement multi-zones. Si la couche cloud du fournisseur tombe en panne, Kubernetes peut replanifier les pods mais perdre les volumes, l'ingress ou l'accessibilité externe. Si le plan de contrôle ou le chemin VPN tombe en panne, les développeurs peuvent perdre l'accès à la gestion.

Si la pile de surveillance fait partie de l'offre de service complet du fournisseur, la visibilité des incidents peut se dégrader en même temps que le service lui-même.

Le troisième groupe est celui des clients utilisant CLOUD & HEAT comme partenaire d'exploitation OpenStack plutôt que comme hôte. La page d'accueil cite STACKIT disant que Cloud&Heat soutient le développement et l'expansion de l'infrastructure cloud avec des connaissances OpenStack. La page Patron vend une distribution OpenStack, l'installation, la mise en service, l'exploitation, la surveillance, l'analyse des pannes et les mises à jour. Une panne de l'AS203592 peut ne pas affecter directement un cloud opéré par le client, mais une panne de support peut encore lors des mises à niveau, des incidents ou des changements urgents.

Les clients de conseil et d'exploitation gérée sont affectés par la disponibilité du personnel, l'accès à distance, la documentation et l'escalade, pas nécessairement par les routes cnh-primary.

Le quatrième groupe est celui des réseaux régionaux et des entités au trafic local. Les preuves PeeringDB et DD-IX placent l'AS203592 sur DD-IX à Dresde. Un chemin d'échange local peut améliorer la latence régionale et la résilience quand il fonctionne; il peut aussi devenir une dépendance si les clients supposent que le trafic local restera local. DD-IX lui-même est un échange plus large avec plusieurs entités et installations, donc un problème de CLOUD & HEAT n'est pas un problème de DD-IX par défaut.

Mais les clients utilisant des services proches de Dresde devraient surveiller à la fois le statut de l'AS203592 et de DD-IX car le chemin d'interconnexion local fait partie de l'histoire de performance.

Le cinquième groupe est la présence publique du fournisseur lui-même. DNS a placéwww.cloudandheat.comà l'intérieur de 185.128.116.0/22. Si le même réseau ou la même pile d'hébergement soutient le site public de l'entreprise, un incident d'infrastructure peut rendre les pages produits et certains points d'entrée clients indisponibles au moment où les clients ont besoin d'informations. La preuve DNS publique ne prouve pas que le système de tickets de support est sur la même pile, et l'enregistrement SPF inclut Google, donc le courrier peut avoir un chemin de dépendance différent. Néanmoins, les communications publiques devraient faire partie de la diligence raisonnable du client: où se trouve la page de statut, que se passe-t-il si le site web principal est indisponible, et quels contacts d'urgence restent joignables?

C'est pourquoi le langage de la région affectée doit être conservateur. L'affectation marque la région comme Global car les services cloud et hébergés sont accessibles mondialement et la catégorie du répertoire est service cloud mondial. La région opérationnelle la plus forte dans les preuves publiques est l'Allemagne, en particulier Dresde et la Saxe, avec une connexion DD-IX documentée et des affirmations de centres de données allemands. Les clients en dehors de l'Allemagne peuvent toujours utiliser les services, mais la dépendance physique n'est pas mondiale au sens hyperscale.

C'est un fournisseur cloud et de technologies cloud allemand avec une portée mondiale.

La preuve de redondance est bonne en bordure de réseau et incomplète au niveau du service

Il y a plusieurs signaux de redondance positifs. L'AS203592 a quatre voisins observés dans RIPEstat, pas un. Il a une visibilité de routage publique sur l'ensemble des pairs RIS observés pour IPv4 et IPv6 au moment de la requête. Il a des origines valides RPKI pour les quatre préfixes observés. PeeringDB montre une participation au route-server sur DD-IX. La page Kubernetes managé promet un déploiement multi-zones de disponibilité pour une haute disponibilité. La page IaaS mentionne des clusters Ceph triple redondance et une option NVMe triple répliquée.

La page Patron propose des contrats d'exploitation et de surveillance, incluant des options 24/7.

Les lacunes sont tout aussi importantes. La visibilité de routage publique ne divulgue pas l'ingénierie du trafic. Le port DD-IX de 10 Gbps de PeeringDB ne divulgue pas l'utilisation ou le basculement. La validité RPKI ne prouve pas la préparation aux changements de route. "Plusieurs zones de disponibilité" ne définit pas la séparation du rayon d'explosion. "Ceph triple redondance" n'indique pas le placement des répliques. "Surveillance 24/7" ne révèle pas le personnel de réponse, l'autorité d'escalade ou les objectifs de restauration.

Les certificats ISO et le statut OpenStack Powered montrent une posture de processus et de technologie, mais ce ne sont pas des enregistrements d'incidents. Un acheteur ne devrait pas traduire ces affirmations publiques en une garantie globale de haute disponibilité.

La preuve de redondance pratique la plus forte qu'un acheteur puisse demander n'est pas une brochure. C'est un test de récupération exécuté: prendre une VM représentative, un volume, un seau d'objets, une charge de travail Kubernetes et une base de données; simuler une panne de zone; mesurer le temps de restauration; tester le changement DNS; exporter les images et les volumes; reconstruire sur un deuxième fournisseur ou site client; et vérifier la cohérence au niveau de l'application. Pour Kubernetes, demander comment etcd, les volumes persistants, les controleurs d'ingress, les load balancers et les dépendances du registre se récupèrent.

Pour OpenStack, demander comment Nova, Neutron, Cinder, Glance, Keystone, Ceph et le DNS externe se comportent lorsqu'un nœud de stockage, un hyperviseur, un routeur ou un lien d'installation tombe en panne.

La preuve de migration devrait également être spécifique au produit. Un client IaaS a besoin d'exportation d'image, d'exportation de snapshot/volume, de transfert de données d'objet, de planification de changement d'adresse et de libération de quota. Un client Kubernetes a besoin de manifestes, de Helm charts, de dépôts GitOps, de gestion des secrets, de migration de volumes persistants et de sauvegarde externe. Un client GPU a besoin de disponibilité matérielle alternative et de compatibilité des pilotes.

Un client Patron sur site a besoin de documentation, de runbooks, de chemins de mise à jour et de droits pour continuer à opérer si le support change. Ce sont des tests différents, et les pages publiques ne répondent pas à tous.

L'entreprise est aidée par ses choix open source. OpenStack et Kubernetes réduisent certains verrouillages par rapport aux plateformes propriétaires uniquement. La compatibilité SCS est conçue pour augmenter l'interopérabilité et la portabilité. Yaook et Tarook pointent vers une gestion automatisée du cycle de vie. Mais la valeur des normes ouvertes n'apparaît que si le client contrôle sa configuration, ses sauvegardes, ses identifiants et ses instructions de construction. L'open source n'est pas un substitut à la planification de sortie. C'est le fondement d'un meilleur plan de sortie.

Le niveau de dépendance final

cnh-primary CLOUD & HEAT Technologies GmbH devrait être mis à niveau depuis le soupçon initial d'"empreinte fine". Les preuves publiques ne sont pas minces. L'AS203592 est vivant. RIPE montre des annonces actuelles, des origines valides et des ressources numériques allemandes. PeeringDB montre une installation à Dresde et une connexion DD-IX. Le site de l'entreprise vend IaaS et Kubernetes managé avec des détails techniques significatifs. Les sources OpenStack et OpenInfra corroborent le rôle de l'entreprise dans l'infrastructure cloud ouverte. Les sources liées à SCS soutiennent l'histoire de la souveraineté et de l'interopérabilité.

Les références clients sont visibles.

La rétrogradation ne concerne pas l'existence. Elle concerne la preuve de résilience. Les preuves publiques ne divulguent pas le calcul installé total, le stock GPU, la capacité brute de stockage, le nombre de locataires, la conception par zone, le nombre de baies, les conditions contractuelles d'installation, la topologie d'alimentation, les procédures d'assistance à distance, l'emplacement des sauvegardes, l'historique de restauration, l'historique des incidents, les effectifs de support exacts ou les sorties de clients testées.

Le langage "dans les capacités disponibles" de la page IaaS est un rappel utile que la capacité utilisable est finie. Un acheteur devrait traiter chaque phrase de capacité publique comme une invitation à vérifier le stock, les quotas et les chemins de récupération.

Le niveau le plus utile est divisé. Identité réseau et preuves de routage: Fort. Preuves produit et client: Fort. Preuves d'installation et d'interconnexion locale: Moyen-Fort, car Dresde et DD-IX sont visibles mais toute l'empreinte cloud n'est pas cartographiée publiquement. Preuves de résilience de capacité hébergée: Moyen, car les pages publiques font des affirmations concrètes sur la disponibilité, le support et le stockage, mais elles s'arrêtent avant une preuve dure. Preuves de migration: Moyen, aidé par OpenStack, Kubernetes et SCS, mais dépendant des conditions contractuelles et de la préparation du client.

Le test pratique est de savoir si un client peut transformer ces forces publiques en contrôle opérationnel. Un acheteur qui considère Cloud&Heat comme un fournisseur cloud allemand stratégique devrait demander un état de capacité actuel, pas seulement un catalogue de services: CPU, mémoire, GPU, stockage bloc, stockage objet, stockage de sauvegarde et quota réseau disponibles par site ou zone de disponibilité.

Il devrait demander si une nouvelle machine virtuelle peut être provisionnée pendant un événement de stockage partiel, si un cluster Kubernetes peut être reconstruit sans secrets détenus par le fournisseur, si les IP flottantes peuvent être réaffectées pendant la maintenance du routeur, si les données d'objet peuvent être exportées sans limitation, et si le support peut exécuter des changements urgents lorsque le site public ou un chemin de peering est dégradé. Ce sont des questions ordinaires pour une capacité hébergée sérieuse. Elles n'affaiblissent pas l'histoire de l'entreprise; elles rendent les preuves publiques solides utilisables.

Pour la surveillance, suivre l'AS203592, 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29, 2a0c:2c0:dd80::/44, le port DD-IX, le site cloudandheat.com et les chemins de statut ou de support publics. Pour l'approvisionnement, demander des déclarations d'installation, des définitions de zones de disponibilité, des preuves de diversité de route, des conditions de réponse de support, des preuves de sauvegarde et d'exportation, et un plan de migration testé. L'entreprise a une infrastructure crédible.

Le point de décision est de savoir si le service spécifique qu'un client achète a suffisamment de capacité utilisable et de récupération répétée pour survivre aux défaillances physiques que toute capacité hébergée rencontre finalement.