cnh-primary CLOUD & HEAT Technologies GmbH 出售的主机容量仍依赖于机架、传输和维修窗口

摘要

• cnh-primary 映射到 AS203592，即 RIPE 注册的自治系统，名为“cnh-primary”，注册至 CLOUD & HEAT Technologies GmbH。RIPE RDAP 显示该 AS 活跃，RIPEstat 显示其在 2026-07-15 00:00 UTC 被通告。
• 路由表面是当前的，并且对于该批次来说异常文档完善：RIPEstat 列出了 185.128.116.0/22、94.198.185.0/24、2a0c:2c0::/29 和 2a0c:2c0:dd80::/44 由 AS203592 通告，所有四个观察到的来源都有有效的 RPKI。
• PeeringDB 将 AS203592 记录为 CLOUD & HEAT Technologies GmbH，列出一个设施 IBH Dresden C2 和一个 DD-IX 连接，速度为 10 Gbps，具有 IPv4 和 IPv6 地址以及路由服务器参与。
• 该公司自己的页面描述 IaaS、托管 Kubernetes、基于 OpenStack 的本地分发工作、GPU 实例、Ceph 存储、德国数据中心托管、ISO 27001 和 ISO 9001 认证、SCS 兼容云工作以及客户如 Scalytics、tracetronic、Nyris、elevait、alphaspeech、flow.d 和 N+P。
• 证据等级：网络身份和产品存在为强，设施和互连地点为中等，弹性仅为中等，因为公开材料未披露机架数量、电源拓扑、备用服务器池、确切的可用区布局、备份证明、客户导出测试或事件历史。

名称始于路由，但公司比路由更广泛

目录条目位于https://btw.media/en/directory/cnh-primary-cloud-heat-technologies-gmbh，指向一个非常具体的公共基础设施身份：cnh-primary CLOUD & HEAT Technologies GmbH。“cnh-primary”部分并非营销点缀。它是 AS203592 的 RIPE AS 名称，显示在 RIPE 数据库https://rest.db.ripe.net/ripe/aut-num/AS203592.json和 RDAPhttps://rdap.db.ripe.net/autnum/203592中。该 AS 于 2015 年 12 月 4 日注册，最后更改于 2026 年 1 月 28 日。RDAP 将注册者标识为 CLOUD & HEAT Technologies GmbH，德累斯顿地址也出现在公司自己的联系页面上。这为文章提供了比许多小型云档案更坚实的起点：有一个已命名的公司、一个已命名的 AS、一个公共办公室身份和活跃的互联网编号注册。

第二层是产品证据。CLOUD & HEAT 的英文主页https://www.cloudandheat.com/en/将公司描述为德累斯顿云服务和云技术提供商，产品基于 OpenStack、Proxmox VE 和 Kubernetes。其 IaaS 页面https://www.cloudandheat.com/en/products/cloud-services-in-germany/infrastructure-as-a-service/销售计算大小、块存储和对象存储、GPU 实例和德国托管的云容量。其托管 Kubernetes 页面https://www.cloudandheat.com/en/products/cloud-services-in-germany/managed-kubernetes-germany/描述自我管理、按需、基础和全服务 Kubernetes 模型。其 Patron 页面https://www.cloudandheat.com/en/products/on-premises-cloud-infrastructures/on-premises-cloud-tailored/cloudandheat-a-ready-to-use-openstack-distribution/销售 OpenStack 分发和可选的运营支持。这不仅仅是一个休眠的 AS 附加到一个壳页面。

也就是说，公司有多个运营层，这些层不应混淆。AS203592 是公共路由层。IaaS 和 Kubernetes 页面是产品页面。Patron 和本地页面是咨询、软件和托管运营产品。能效页面和 OpenInfra 档案描述可持续性和开源定位。购买虚拟机的客户依赖的东西与购买支持型 OpenStack 分发用于自己硬件的客户不同。使用托管 Kubernetes 的客户依赖 API 访问、集群、持久卷、监控和维护窗口。购买咨询的客户依赖人员和流程，而非 AS203592。公共公司证据是真实的，但每个产品都有不同的故障路径。

因此，关键问题不是 CLOUD & HEAT 是否存在。它显然存在。问题在于当公司将公司视为托管基础设施时，有哪些公共证据支持。RIPE、RIPEstat 和 PeeringDB 支持 AS203592 网络地图。公司网站支持公共云和托管服务目录。OpenStack 市场https://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-services列出了 Cloud & Heat 云服务，并说明产品是 OpenStack Powered。OpenStack 的支持公司档案https://www.openstack.org/community/supporting-organizations/profile/cloud-and-heat将 Cloud & Heat 描述为德累斯顿的云服务和云技术提供商。然而，这些来源都没有提供完整的公共容量审计。

这是对买家重要的区别。公共 AS 可以健康，而一个可用区没有备用机器。OpenStack 云可以列出，而某个 GPU 类别售罄。托管 Kubernetes 产品可以承诺监控，而客户仍然需要自己的备份、部署和导出计划。设施条目可以显示德累斯顿存在，而不揭示机架数量、电源馈电设计或远程手操作条款。公共记录足够强，可以将 cnh-primary 置于严肃基础设施类别，但仍需以工程谨慎态度阅读。

路由证据是当前的、可见的，并且比简单的公司页面更清晰

RIPEstat 的 AS203592 AS 概览https://stat.ripe.net/data/as-overview/data.json?resource=AS203592将持有者标识为“cnh-primary CLOUD & HEAT Technologies GmbH”，并在 2026-07-15 00:00 UTC 显示 announced=true。这是一个特定时间但重要的信号：AS 不仅已注册；它在发布日期在公共路由数据中可见。RIPEstat 的通告前缀端点https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS203592在截至 2026 年 7 月 15 日的两周窗口内列出了四条路由：185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 和 2a0c:2c0:dd80::/44。

路由状态端点https://stat.ripe.net/data/routing-status/data.json?resource=AS203592使信号更强。它报告了两个 IPv4 前缀、两个 IPv6 前缀、1,280 个 IPv4 地址、524,288 个 IPv6 /48 单位、四个观察到的邻居，以及在查询时间 RIPE RIS 对等集对 IPv4 和 IPv6 的完全观察可见性。这些数字不是客户容量。它们确实表明 AS203592 从路由收集器广泛可见，而不是一个一对等的私有注脚。

各个前缀视图一致。RIPEstat 显示 185.128.116.0/22 由 AS203592 通告https://stat.ripe.net/data/prefix-overview/data.json?resource=185.128.116.0/22，94.198.185.0/24 由 AS203592 通告https://stat.ripe.net/data/prefix-overview/data.json?resource=94.198.185.0/24。它还显示 IPv6 聚合 2a0c:2c0::/29https://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0::/29和更具体的 2a0c:2c0:dd80::/44https://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0:dd80::/44。IPv6 更具体关系很重要，因为它暗示了分段 IPv6 使用，而非单一未分化分配。

RPKI 也一致。RIPEstat 对 AS203592 和 185.128.116.0/22 返回 validhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=185.128.116.0/22，对 94.198.185.0/24 validhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=94.198.185.0/24，对 2a0c:2c0::/29 validhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0::/29，对 2a0c:2c0:dd80::/44 validhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0:dd80::/44。RPKI 有效性不能防止机架故障，但减少了一类路由故障：严格网络不太可能拒绝这些来源为无效。

RIPE 数据库还显示前缀背后的管理连续性。185.128.116.0/22 的 WHOIS 视图https://stat.ripe.net/data/whois/data.json?resource=185.128.116.0/22显示 netname DE-CLOUDANDHEAT-20151125, country DE, organisation ORG-CHTG1-RIPE 以及由 AS203592 发起的路由对象。94.198.185.0/24 视图https://stat.ripe.net/data/whois/data.json?resource=94.198.185.0/24显示 netname DE-CLOUDANDHEAT-20081029, country DE 以及在 2026 年 1 月更新后由 AS203592 发起的路由对象。2a0c:2c0::/29 视图https://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0::/29显示 2018 年 RIPE 分配给同一组织以及 AS203592 的 route6 对象。2a0c:2c0:dd80::/44 视图https://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0:dd80::/44特别有趣，因为它被命名为 IBH-DD8，创建日期为 2025 年 12 月。这指向一个更新的德累斯顿本地段，但仍未揭示其背后的工作负载。

对客户而言，路由结论很简单。AS203592 是一个活跃的网络，公共路由证据很强。较难的结论是关于服务容量。前缀和 ROA 不能告诉我们安装了多少个虚拟机管理程序、有多少租户活跃、哪些规格缺货、GPU 池物理位置在哪、或者节点故障后块存储测试的频率。它们回答网络身份问题。它们不回答采购问题。

德累斯顿设施和交换记录是真实的，但并非整个云

PeeringDB 添加了最清晰的公共物理线索。网络查询https://www.peeringdb.com/api/net?asn=203592将 CLOUD & HEAT Technologies GmbH 列为 AS203592，具有区域范围、启用 IPv6、开放对等策略、一个交换和一个设施。网络对象https://www.peeringdb.com/api/net/40650显示设施设置为 IBH Dresden C2，交换设置为 DD-IX。netfac 端点https://www.peeringdb.com/api/netfac?net_id=40650重复 IBH Dresden C2 关联。netixlan 端点https://www.peeringdb.com/api/netixlan?asn=203592列出 DD-IX, 10 Gbps 速度字段, IPv4 地址 193.201.151.80, IPv6 地址 2001:7f8:79::3:1b48:1, route-server peer true 和 operational=true。

这种组合异常有用。它将 AS203592 置于命名的德累斯顿互连环境中，而不仅仅是给读者一个公司地址。PeeringDB 的设施记录https://www.peeringdb.com/api/fac/14039将 IBH Dresden C2 标识为 IBH connect GmbH 在德累斯顿的设施，公共网站路径用于托管和机架空间https://www.ibh.de/rechenzentrum/housing-rackpace。DD-IX 交换记录https://www.peeringdb.com/api/ix/4282将 DD-IX 标识为德累斯顿的交换，在其设施集中列出 IBH Dresden C2 和 SachsenEnergieCenter Dresden，并指向https://dd-ix.net,https://dd-ix.net/stats和https://status.dd-ix.net。DD-IX 网站将该交换描述为德累斯顿的非商业平台，旨在保持本地流量本地化并为萨克森地区服务。

物理解读仍然应保持精确。PeeringDB 证明 AS203592 在 IBH Dresden C2 有列出的设施关联和一个 DD-IX 连接。它不证明 CLOUD & HEAT 的所有 IaaS 计算都位于该设施。它不证明存储布局。它不揭示 DD-IX 端口是直接连接到客户虚拟机管理程序、边界路由器、实验室段、管理网络还是面向交换的边缘。它不揭示交叉连接多样性、交换机多样性、机架电源馈电、发电机覆盖、冷却冗余或远程手维修承诺。

公司本身将画面扩展到单个 PeeringDB 设施之外。其 IaaS 页面说公共云基础设施完全在德国的数据中心运营，客户数据以 GDPR 合规形式处理和存储。其托管 Kubernetes 页面说 Kubernetes 数据在符合 GDPR 的 ISO 27001 认证德国数据中心处理和存储。其 2024 年 SCS 文章https://www.cloudandheat.com/en/news-press/strengthening-digital-sovereignty-new-ways-in-the-cloud-with-yaook-and-scs-compatibility/讨论了与 envia TEL、Yaook 和 SCS 的莱比锡数据中心项目。其 2026 年认证新闻，从同一网站浮现，称 Cloud&Heat 获得了“认证 SCS 兼容 IaaS”认可，该奖项将在 2026 年 6 月 21 日的 SCS 峰会上颁发。这些点使足迹超过单一 AS 端口故事，但不将整个容量地图变成公共知识。

电力和冷却是物理依赖的一部分，而不仅仅是可持续性声明。IaaS 页面说 Cloud&Heat 使用直接热水冷却和集成到本地供暖回路，以实现能效运营和服务器废热利用。OpenStack 市场页面也描述了水冷服务器和服务器废热再利用。这是有用的背景：如果云围绕热再利用设计，那么建筑设施、水循环、换热器、本地热输出和维护窗口成为服务依赖的一部分。传统数据中心客户主要询问电力和冷却冗余。Cloud&Heat 客户还应询问热再利用维护如何与计算可用性隔离。

因此，德累斯顿证据支持一个中间声明。有公共证据证明德累斯顿互连点，以及公共公司证据证明德国云托管。没有足够的公共证据将每个客户工作负载映射到一个机架、每个可用区映射到一栋建筑，或每个 GPU 实例映射到特定的电力和冷却链。买家可以将德累斯顿视为一个有意义的运营中心，而不是完整的基础设施图。

产品证据对 OpenStack 和 Kubernetes 更强，而非备用容量

CLOUD & HEAT 的产品页面对于一个区域云提供商来说异常具体。IaaS 页面列出了从 1 vCPU / 2 GB RAM / 15 GB SSD 到 8 vCPU / 30 GB RAM / 100 GB SSD 的计算大小，提供标准和 Memory+ 价格系列，宣传 HDD 块/对象存储，并说存储集群是三冗余 Ceph 集群用于对象和块存储。它还列出了 GPU 实例类别，包括 T4、A10、V100 和 A100。该页面明确说，在可用容量内可以提供三副本 NVMe 池。这个短语很重要：公司销售有用的资源，但也承认某些存储类容量有限。

托管 Kubernetes 页面同样具体。它描述了 OpenStack 上的自我管理选项、按需支持、托管 Kubernetes Basic（9/5 支持和四小时响应时间）和托管 Kubernetes Full Service（不同支持级别）。两个托管层级都列出了跨多个可用区部署以实现高可用性、通过 VPN 的 API 保护、基于 GitOps 的集群管理、负载均衡器服务、OpenStack Cinder 持久卷、本地静态和动态存储以及网络策略。Full Service 增加了 ingress、Certmanager、Prometheus 和 Grafana 监控栈、24/7 集群监控和警报，以及 GPU 实例。这些是运营声明，而不仅仅是口号。

Patron 页面加强了故事中的 OpenStack 部分。它说 Cloud&Heat Patron 是一个即用型 OpenStack 分发，基于使用 Yaook 的开源生命周期管理，具有企业级组件、SCS 兼容性、自动化、无供应商锁定和支持选项。该页面提供了客户运营云的模式，以及 Cloud&Heat 提供运营和监控、故障分析、故障修复和更新等维护的模式。它提到了 9-5 和 24/7 支持合同选项。这告诉我们 CLOUD & HEAT 不仅转售虚拟机；它还销售围绕 OpenStack 本身的运营知识。

OpenInfra 来源证实了开放基础设施定位。OpenStack 市场页面https://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-services列出了 Cloud & Heat 云服务，并说产品是 OpenStack Powered。OpenInfra 支持公司页面https://www.openstack.org/community/supporting-organizations/profile/cloud-and-heat描述其技术栈包括 OpenStack、Kubernetes、Yaook 和 Krake，并说公司为 Sovereign Cloud Stack 努力做出贡献。SCS 标准论坛页面https://sovereigncloudstack.org/en/about-scs/forum-scs-standards/列出了 Cloud&Heat Technologies GmbH 作为致力于安全云基础设施的成员，并注意到与 Open Infrastructure Foundation 的合作。

客户信号也是公开的。IaaS 页面在客户下命名了 Scalytics、tracetronic、Nyris、elevait、alphaspeech 和 flow.d。托管 Kubernetes 页面命名了 N+P Informationssysteme GmbH 和 elevait GmbH & Co. KG。主页包含来自 N+P、elevait 和 STACKIT 的引用：N+P 和 elevait 将 Cloud&Heat 描述为其托管 Kubernetes 提供商，而 STACKIT 将 Cloud&Heat 描述为云技术合作伙伴，帮助 OpenStack 知识。OpenStack 市场页面链接到 elevait、N+P、Nyris 和 flow.d 的客户案例研究。这些是有意义的受影响方信号，但它们不是租户清单。

安装容量与可用容量的区别是分析必须放慢的地方。安装容量是公司控制或管理下的服务器、存储、GPU、交换机、DD-IX 端口、上行链路、OpenStack 集群、Kubernetes 控制平面和支持工具。可用容量是客户可以订购、分配、保持运行、恢复和离开而不会经历不可接受停机的部分。公共页面显示产品类别、支持模型、客户名称和技术选择。它们不显示当前 GPU 库存、每规格配额、虚拟机管理程序总数、Ceph 故障域设计、超配比率、维护日历、备份保留或经过测试的跨区恢复。

NVMe 存储说明中的“在可用容量内”的限定词是进入较小云经济学现实的有用窗口。云提供商可以宣传存储类，但仍然限制该类，因为高性能驱动器昂贵，设施电力有限，存储复制消耗原始容量，客户需求变化。这不会使产品变弱。这使其物理化。买家应将每项服务线转化为容量问题：安装了多少，预留了多少，这个月可以交付多少，需求激增时会发生什么变化？

上行链路、支持和维修风险位于营销层之下

RIPE 数据库中的公共路由策略列出了 AS203592 周围的 AS3320、AS15372、AS6830 和 AS8220。RIPEstat 的观察邻居端点https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS203592在 2026 年 7 月 14 日看到了 AS15372、AS3320、AS8220 和 AS213973。RIPEstat 将 AS15372 识别为 IBH connecthttps://stat.ripe.net/data/as-overview/data.json?resource=AS15372, AS3320 为 Deutsche Telekomhttps://stat.ripe.net/data/as-overview/data.json?resource=AS3320, AS8220 为 Colthttps://stat.ripe.net/data/as-overview/data.json?resource=AS8220, AS6830 为 Liberty Globalhttps://stat.ripe.net/data/as-overview/data.json?resource=AS6830, AS213973 为 BCIX Managementhttps://stat.ripe.net/data/as-overview/data.json?resource=AS213973。这是本地、全国和商业连接信号的可信组合。

限定条件是公共邻居列表不是合同地图。它不说明哪个路径是付费传输、哪个路径是对等、哪个路径是备份、哪些前缀在哪里被接受、哪些路由过滤器严格、哪些维护窗口重叠、或者客户流量是否固定到特定边缘。它也不证明 Kubernetes API 端点和 IaaS 存储后端具有相同的网络保护。好消息是 AS203592 在公共视野中不是一个单邻居孤岛。采购问题是相关客户服务是否有足够的真实路径多样性来承受客户关心的特定故障。

设施故障是下一层。如果工作负载在连接到 AS203592 的德国数据中心运行，则服务依赖机架电源、冷却、上行交叉连接、交换机、路由器、存储网络和员工访问。IBH Dresden C2 的 PeeringDB 设施列出了 diverse serving substations=true，这是一个积极的设施级线索。它仍然不披露 CLOUD & HEAT 的机架电源设计、双电源覆盖、维护旁路、电池运行时间、发电机测试历史，或者特定客户 VM 是否可以在本地事件期间从受影响设施移走。DD-IX 连接有助于本地流量交换，但交换中断和数据中心中断是不同的事件。

支持故障同样重要。托管 Kubernetes 页面给出了 9/5 支持层级，Basic 为四小时响应时间，Full Service 为 24/7 监控和警报。Patron 页面为运营的 OpenStack 环境提供 9-5 和 24/7 支持合同选项。IaaS 页面承诺来自 OpenStack 和 DevOps 专家的个人、服务导向建议。这些是有用的公共承诺，但客户仍然需要合同。页面不披露存储故障、虚拟机管理程序疏散、GPU 更换、路由泄漏、DNS 中断、滥用工单、计费锁定或紧急数据导出的升级目标。

DNS 证据添加了一个虽小但有用的运营线索。本次审查期间的 DNS 查询将 www.cloudandheat.com 通过 cloudandheat.com 解析到 185.128.119.78，该地址位于 AS203592 通告的 185.128.116.0/22 前缀内。同一查询显示 mail.cloudandheat.com 作为 MX，INWX 域名服务器和 SPF 记录包括邮件主机和 Google。这暗示公共网站是从公司自己的路由空间提供，而非仅来自大型第三方 CDN。这对网络身份是积极的，但也意味着公司的公共网站可能受到其自身 AS、web 主机或设施依赖的影响。

客户影响路径源于产品栈。网络故障可能影响公共云可达性、托管 Kubernetes API、负载均衡器、客户入口、软件分发端点，以及可能提供商自己的网站或支持界面。存储故障可能影响卷和对象存储。电源或冷却事件可能影响虚拟机管理程序和 GPU 机器。支持或运营短缺可能延长恢复时间，即使硬件可修复。合同或计费故障可能阻止变更、导出或紧急扩展。公共材料证明公司在这些领域有经验；它不证明每条故障路径都经过演练。

这并非 CLOUD & HEAT 独有的批评。这是区域云依赖的正常形态。提供商可以比超大规模平台更透明、更开源对齐、更本地化，同时仍受制于相同的物理约束：空间、电源、冷却、光学器件、备件、路由过滤器、维护窗口和人员可用性。

数据本地性是一个优势，但本地性不自动意味着可恢复性

CLOUD & HEAT 面向读者最强的承诺是本地性和数字主权。IaaS 页面说公共云基础设施完全在德国的数据中心运营，数据以 GDPR 合规形式处理和存储。托管 Kubernetes 页面说数据在符合 GDPR 的 ISO 27001 认证德国数据中心处理和存储。主页说客户可以使用 CLOUD & HEAT 的基础设施或本地部署。SCS 和 OpenInfra 来源将公司置于开放标准、可移植性和数字主权周围。

这些声明很重要。试图避免不透明离岸托管的德国或欧洲客户在公共云页面说德国、OpenStack 和开源栈而非通用全球区域时，有不同的风险模型。SCS 相关材料对互操作性很重要。2024 年公司文章说 SCS 标准旨在提高云应用程序的互操作性和可移植性。2026 年认证新闻说 Cloud&Heat 获得了认证 SCS 兼容 IaaS 认可。OpenInfra 档案说公司为 SCS 等标准做出贡献。这一切都与数据主权和本地性主题相关。

但本地性不应被误认为是恢复能力。客户可以知道数据在德国，但仍然不知道它是在德累斯顿和莱比锡之间复制、在两个德累斯顿房间之间、在一栋建筑的两个可用区之间、还是在具有故障域的一个存储集群内。托管 Kubernetes 页面说跨多个可用区部署以实现高可用性，但没有公开定义这些区域。IaaS 页面说三冗余 Ceph 集群和在可用容量内的可选三副本 NVMe 池，但没有透露副本是机架本地、房间本地、建筑本地还是园区分离的。公共页面不显示备份位置或恢复历史。

这对有合规义务的客户很重要。如果工作负载需要德国存储，CLOUD & HEAT 的公共页面支持起始声明。如果工作负载需要特定的德国州、电力区、可用区分离、备份隔离、气隙导出或受监管部门的连续性计划，公共页面不够。客户应要求数据位置、子处理者、备份位置、存储复制范围、员工访问、维护窗口和经过测试的恢复的声明。如果工作负载使用托管 Kubernetes，客户还应询问控制平面、etcd、持久卷、镜像注册表、监控数据和日志位于何处。

由于技术选择，迁移路径更清晰。OpenStack、Kubernetes、Cinder 卷、Ceph 支持的存储、GitOps 和 SCS 兼容性如果实施时具有导出权限和经过测试的工具，都可以减少锁定。客户可以运行基础设施即代码、维护外部备份、保持 DNS 在自身控制下、容器化应用程序并准备目标 OpenStack 或 Kubernetes 环境。但公共页面不承诺每个镜像、卷、快照、对象桶、浮动 IP、负载均衡器或 GPU 工作负载都可以快速导出。标准技术使迁移成为可能；它们不使其自动。

因此，正确的结论是混合的。CLOUD & HEAT 有一个可信的主权故事，因为它结合了德国托管、OpenStack、Kubernetes、SCS 工作和本地互连。同样的故事必须在服务边界测试：哪个服务是德国托管的，哪个部分在客户本地，哪个部分依赖 IBH 或 DD-IX，哪个部分依赖第三方邮件或 DNS，哪个部分可以在提供商中断期间移动？主权不仅关乎国家。它关乎压力下的控制。

如果 cnh-primary 失败，谁受影响？

第一受影响群体是公共云和 IaaS 客户。IaaS 页面命名了客户包括 Scalytics、tracetronic、Nyris、elevait、alphaspeech 和 flow.d。它销售计算、GPU 和存储资源，并将云定位为适用于德国数据保护和数字主权。如果 AS203592 或相关设施路径失败，客户虚拟机可能保持通电但变得不可达。如果存储层失败，数据可用性和卷挂载成为问题。如果容量耗尽，客户可能无法扩展，即使现有实例保持运行。

第二群体是托管 Kubernetes 客户。托管 Kubernetes 页面命名了 N+P Informationssysteme GmbH 和 elevait GmbH & Co. KG。它描述了通过 VPN 的 API 访问、OpenStack Cinder 持久卷、负载均衡器、监控、ingress、Certmanager 和多区部署。如果提供商的云层失败，Kubernetes 可能重新调度 pod，但仍丢失卷、ingress 或外部可达性。如果控制平面或 VPN 路径失败，开发者可能失去管理访问。如果监控栈是提供商全服务产品的一部分，事件可见性可能随服务本身一起下降。

第三群体是使用 CLOUD & HEAT 作为 OpenStack 运营合作伙伴而非主机的客户。主页引用 STACKIT 说 Cloud&Heat 用 OpenStack 知识支持云基础设施的开发和扩展。Patron 页面销售 OpenStack 分发、安装、调试、运营、监控、故障分析和更新。AS203592 的故障可能不会直接中断客户运营的云，但支持中断在升级、事件或紧急变更期间仍然重要。咨询和托管运营客户通过人员可用性、远程访问、文档和升级受到影响，不一定是通过 cnh-primary 路由。

第四群体是区域网络和本地流量参与者。PeeringDB 和 DD-IX 证据将 AS203592 置于德累斯顿的 DD-IX。本地交换路径在正常工作时可以改善区域延迟和弹性；当它出现问题时，也可以成为依赖，如果客户假设本地流量将保持本地。DD-IX 本身是一个更广泛的交换，有多个参与者和设施，因此 CLOUD & HEAT 的问题默认不是 DD-IX 问题。但使用靠近德累斯顿服务的客户应监控 AS203592 和 DD-IX 状态，因为本地互连路径是性能故事的一部分。

第五群体是提供商自身的公共存在。DNS 将 www.cloudandheat.com 置于 185.128.116.0/22 内。如果相同网络或托管栈支持公司的公共网站，基础设施事件可能使产品页面和某些客户入口点在客户需要信息时不可用。公共 DNS 证据不证明支持工单系统在同一栈上，SPF 记录包括 Google，因此邮件可能有不同的依赖路径。尽管如此，公共通信应成为客户尽职调查的一部分：状态页面在哪里，主网站不可用时会发生什么，哪些紧急联系人保持可达？

这就是为什么受影响区域语言应保守。分配将区域标记为全球，因为云和托管服务全球可达，目录类别是全球云服务。公共证据中最强的运营区域是德国，特别是德累斯顿和萨克森，有记录的 DD-IX 连接和德国数据中心声明。德国以外的客户仍可使用服务，但物理依赖在超大规模意义上并非全球性。它是一个具有全球可达性的德国云和云技术提供商。

冗余证明在网络边缘良好，在服务层不完整

有几个积极的冗余信号。AS203592 有四个观察到的邻居，而非一个。它在查询时间对 IPv4 和 IPv6 的所有观察 RIS 对等集具有公共路由可见性。它对所有四个观察前缀具有 RPKI 有效来源。PeeringDB 显示 DD-IX 的路由服务器参与。托管 Kubernetes 页面承诺多可用区部署以实现高可用性。IaaS 页面提到三冗余 Ceph 集群和三副本 NVMe 选项。Patron 页面提供运营和监控合同，包括 24/7 选项。

差距同样重要。公共路由可见性不披露流量工程。PeeringDB 的 10 Gbps DD-IX 端口不披露利用率或故障转移。RPKI 有效性不证明路由变更准备。“多个可用区”不定义爆炸半径分离。“三冗余 Ceph”不说明副本放置。“24/7 监控”不揭示响应人员配备、升级权限或恢复目标。ISO 认证和 OpenStack Powered 状态显示流程和技术姿态，但它们不是事件记录。买家不应将这些公共声明转化为全面高可用性保证。

买家可以要求的最强实际冗余证明不是手册。而是经过测试的恢复运行：取一个代表性 VM、卷、对象桶、Kubernetes 工作负载和数据库；模拟区域故障；测量恢复时间；测试 DNS 更改；导出镜像和卷；在第二提供商或客户站点重建；验证应用程序级一致性。对于 Kubernetes，询问 etcd、持久卷、ingress 控制器、负载均衡器和注册表依赖如何恢复。对于 OpenStack，询问 Nova、Neutron、Cinder、Glance、Keystone、Ceph 和外部 DNS 在存储节点、虚拟机管理程序、路由器或设施链路故障时的行为。

迁移证明也应是产品特定的。IaaS 客户需要镜像导出、卷快照/导出、对象数据传输、地址更改规划和配额释放。Kubernetes 客户需要清单、Helm 图表、GitOps 仓库、秘密处理、持久卷迁移和外部备份。GPU 客户需要备用硬件可用性和驱动兼容性。本地 Patron 客户需要文档、运行手册、更新路径以及支持变更时保持运营的权利。这些是不同的测试，公共页面不回答所有问题。

公司因其开源选择而受益。OpenStack 和 Kubernetes 比纯专有平台减少了一些锁定。SCS 兼容性旨在提高互操作性和可移植性。Yaook 和 Tarook 指向自动化生命周期管理。但开放标准的价值只出现在客户控制其配置、备份、凭证和构建说明时。开源不是退出规划的替代品。它是更好退出计划的基础。

最终依赖等级

cnh-primary CLOUD & HEAT Technologies GmbH 应从最初的“薄足迹”怀疑中升级。公共证据并不薄弱。AS203592 活跃。RIPE 显示当前通告、有效来源和德国编号资源。PeeringDB 显示德累斯顿设施和 DD-IX 连接。公司网站销售 IaaS 和托管 Kubernetes，并附有有意义的技术细节。OpenStack 和 OpenInfra 来源证实公司在开放云基础设施中的角色。SCS 相关来源支持主权和互操作性故事。客户参考可见。

降级不是关于存在。而是关于弹性证明。公共证据不披露总安装计算、GPU 库存、存储原始容量、租户数量、每区设计、机架数量、设施合同条款、电源拓扑、远程手程序、备份位置、恢复历史、事件历史、确切支持人员编制或经过测试的客户退出。IaaS 页面“在可用容量内”的语言是一个有帮助的提醒，即可用容量是有限的。买家应将每个公共容量短语视为验证库存、配额和恢复路径的邀请。

最有用的等级是分裂的。网络身份和路由证据：强。产品和客户证据：强。设施和本地互连证据：中强，因为德累斯顿和 DD-IX 可见，但整个云足迹未公开映射。托管容量弹性证据：中，因为公共页面做出了具体的可用性、支持和存储声明，但缺乏硬证明。迁移证据：中，受 OpenStack、Kubernetes 和 SCS 帮助，但取决于合同条款和客户准备。

实际测试是客户能否将这些公共优势转化为运营控制。将 Cloud&Heat 视为战略德国云提供商的买家应要求当前的容量声明，而不仅仅是服务目录：按站点或可用区的可用 CPU、内存、GPU、块存储、对象存储、备份存储和网络配额。它应询问是否可以在部分存储事件期间配置新虚拟机，是否可以在没有提供商持有秘密的情况下重建 Kubernetes 集群，是否可以在路由器维护期间重新分配浮动 IP，是否可以无节流导出对象数据，以及支持是否可以在公共网站或对等路径受损时执行紧急更改。这些是严肃托管容量的普通问题。它们不会削弱公司故事；它们使强大的公共证据可用。

对于监控，跟踪 AS203592、185.128.116.0/22、94.198.185.0/24、2a0c:2c0::/29、2a0c:2c0:dd80::/44、DD-IX 端口、cloudandheat.com 站点以及公共状态或支持路径。对于采购，要求设施声明、可用区定义、路由多样性证据、支持响应条款、备份和导出证明，以及经过测试的迁移计划。公司有可信的基础设施。决策点是客户购买的特定服务是否有足够的可用容量和足够的演练恢复，以承受所有托管容量最终都会遇到的物理故障。