cnh-primary CLOUD & HEAT Technologies GmbH vende capacidad alojada que todavía depende de los racks, el tránsito y las ventanas de reparación

Resumen

• cnh-primary corresponde al AS203592, el sistema autónomo registrado en RIPE llamado "cnh-primary" y asignado a CLOUD & HEAT Technologies GmbH. El RDAP de RIPE muestra el AS como activo, y RIPEstat lo mostró anunciado el 15 de julio de 2026 a las 00:00 UTC.
• La superficie de enrutamiento es actual e inusualmente bien documentada para este lote: RIPEstat listó 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 y 2a0c:2c0:dd80::/44 como anunciados por AS203592, con RPKI válido para los cuatro orígenes observados.
• PeeringDB registra AS203592 como CLOUD & HEAT Technologies GmbH, con una instalación listada, IBH Dresden C2, y una conexión DD-IX a 10 Gbps con direcciones IPv4 e IPv6 y participación en el servidor de rutas.
• Las páginas de la empresa describen IaaS, Kubernetes gestionado, trabajo de distribución OpenStack on-premise, instancias GPU, almacenamiento Ceph, alojamiento en centros de datos alemanes, certificaciones ISO 27001 e ISO 9001, trabajo cloud compatible con SCS y clientes como Scalytics, tracetronic, Nyris, elevait, alphaspeech, flow.d y N+P.
• El nivel de evidencia es Fuerte para la identidad de red y la existencia de productos, Medio para la instalación e interconexión local, y solo Medio para la resiliencia, ya que los documentos públicos no divulgan el número de racks, la topología de alimentación, los pools de servidores de repuesto, la ubicación exacta de las zonas de disponibilidad, la evidencia de respaldo, las pruebas de exportación de clientes o el historial de incidentes.

El nombre comienza como una ruta, pero la empresa es más amplia que una ruta

La entrada del directorio enhttps://btw.media/en/directory/cnh-primary-cloud-heat-technologies-gmbhapunta a una identidad de infraestructura pública muy específica: cnh-primary CLOUD & HEAT Technologies GmbH. La parte "cnh-primary" no es un adorno de marketing. Es el nombre AS de RIPE para AS203592, mostrado en la base de datos de RIPE enhttps://rest.db.ripe.net/ripe/aut-num/AS203592.jsony en RDAP enhttps://rdap.db.ripe.net/autnum/203592. El AS fue registrado el 4 de diciembre de 2015 y modificado por última vez el 28 de enero de 2026. RDAP identifica al titular como CLOUD & HEAT Technologies GmbH, con la dirección de Dresde también visible en las páginas de contacto de la empresa. Esto le da al artículo un punto de partida más sólido que muchos perfiles cloud pequeños: hay una empresa nombrada, un AS nombrado, una identidad de oficina pública y un registro activo de número de Internet.

La segunda capa es la evidencia del producto. La página de inicio en inglés de CLOUD & HEAT enhttps://www.cloudandheat.com/en/describe a la empresa como un proveedor de servicios cloud y tecnologías cloud con sede en Dresde, con productos construidos sobre OpenStack, Proxmox VE y Kubernetes. Su página de IaaS enhttps://www.cloudandheat.com/en/products/cloud-services-in-germany/infrastructure-as-a-service/vende tamaños de cómputo, almacenamiento en bloque y de objetos, instancias GPU y capacidad cloud alojada en Alemania. Su página de Kubernetes gestionado enhttps://www.cloudandheat.com/en/products/cloud-services-in-germany/managed-kubernetes-germany/describe modelos de Kubernetes autogestionados, bajo demanda, básicos y de servicio completo. Su página Patron enhttps://www.cloudandheat.com/en/products/on-premises-cloud-infrastructures/on-premises-cloud-tailored/cloudandheat-a-ready-to-use-openstack-distribution/vende una distribución de OpenStack y soporte operativo opcional. No es simplemente un AS inactivo adjunto a una página vacía.

Dicho esto, la empresa tiene más de una capa operativa, y estas capas no deben confundirse. AS203592 es la capa de enrutamiento pública. Las páginas de IaaS y Kubernetes son páginas de productos. Las páginas Patron y on-premise son ofertas de consultoría, software y operación gestionada. Las páginas de eficiencia energética y los perfiles de OpenInfra describen un posicionamiento sostenible y de código abierto. Un cliente que compra una máquina virtual depende de cosas diferentes a un cliente que compra una distribución de OpenStack soportada para su propio hardware.

Un cliente que utiliza Kubernetes gestionado depende del acceso a la API, los clusters, los volúmenes persistentes, la monitorización y las ventanas de mantenimiento. Un cliente que compra consultoría depende de las personas y los procesos más que de AS203592. Las pruebas públicas sobre la empresa son reales, pero cada producto tiene una trayectoria de fallo diferente.

La pregunta clave no es si CLOUD & HEAT existe. Claramente existe. La pregunta es qué evidencia pública respalda a la empresa cuando se lee como infraestructura alojada. RIPE, RIPEstat y PeeringDB respaldan un mapa de red AS203592. El sitio web de la empresa respalda un catálogo de cloud público y servicios gestionados. El OpenStack Marketplace enhttps://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-serviceslista los servicios cloud de Cloud & Heat e indica que el producto es OpenStack Powered. El perfil de empresa de apoyo de OpenStack enhttps://www.openstack.org/community/supporting-organizations/profile/cloud-and-heatdescribe a Cloud & Heat como un proveedor de servicios cloud y tecnologías cloud con sede en Dresde. Sin embargo, ninguna de estas fuentes proporciona una auditoría pública completa de la capacidad.

Esta es la distinción importante para los compradores. Un AS público puede estar sano mientras que una zona de disponibilidad no tiene máquinas de repuesto. Un cloud OpenStack puede estar listado mientras una clase de GPU particular está agotada. Una oferta de Kubernetes gestionado puede prometer monitorización mientras que un cliente todavía necesita su propia copia de seguridad, su plan de despliegue y exportación. Una entrada de instalación puede mostrar presencia en Dresde sin revelar el número de racks, el diseño de la alimentación eléctrica o las modalidades de asistencia remota.

El expediente público es lo suficientemente sólido para colocar a cnh-primary en una categoría de infraestructura seria, pero aún debe leerse con precaución técnica.

Las pruebas de enrutamiento son actuales, visibles y más claras que una simple página de empresa

La vista general de AS de RIPEstat para AS203592 enhttps://stat.ripe.net/data/as-overview/data.json?resource=AS203592identifica al titular como "cnh-primary CLOUD & HEAT Technologies GmbH" y mostró announced=true a las 2026-07-15 00:00 UTC. Esta es una señal específica en el tiempo pero importante: el AS no solo estaba registrado; era visible en los datos de enrutamiento públicos en la fecha de publicación. El endpoint de prefijos anunciados de RIPEstat enhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS203592listó cuatro rutas en la ventana de dos semanas que termina el 15 de julio de 2026: 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 y 2a0c:2c0:dd80::/44.

El endpoint de estado de enrutamiento enhttps://stat.ripe.net/data/routing-status/data.json?resource=AS203592reforzó la señal. Reportó dos prefijos IPv4, dos prefijos IPv6, 1.280 direcciones IPv4, 524.288 unidades IPv6 /48, cuatro vecinos observados y visibilidad observada completa en el conjunto de pares RIPE RIS para IPv4 e IPv6 en el momento de la consulta. Estos números no son capacidad de cliente. Muestran que AS203592 era ampliamente visible desde los colectores de rutas y no una nota al pie de un solo par.

Las vistas de prefijos individuales coinciden. RIPEstat mostró 185.128.116.0/22 anunciado por AS203592 enhttps://stat.ripe.net/data/prefix-overview/data.json?resource=185.128.116.0/22y 94.198.185.0/24 anunciado por AS203592 enhttps://stat.ripe.net/data/prefix-overview/data.json?resource=94.198.185.0/24. También mostró el agregado IPv6 2a0c:2c0::/29 enhttps://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0::/29y el más específico 2a0c:2c0:dd80::/44 enhttps://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0:dd80::/44. La relación IPv6 más específica es importante porque sugiere un uso segmentado de IPv6 en lugar de una única asignación indiferenciada.

El RPKI también está alineado. RIPEstat devolvió válido para AS203592 y 185.128.116.0/22 enhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=185.128.116.0/22, válido para 94.198.185.0/24 enhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=94.198.185.0/24, válido para 2a0c:2c0::/29 enhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0::/29y válido para 2a0c:2c0:dd80::/44 enhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0:dd80::/44. La validez del RPKI no evita una falla de rack, pero reduce una clase de falla de enrutamiento: las redes estrictas tienen menos probabilidades de rechazar estos orígenes como inválidos.

La base de datos de RIPE también muestra continuidad administrativa detrás de los prefijos. La vista WHOIS de 185.128.116.0/22 enhttps://stat.ripe.net/data/whois/data.json?resource=185.128.116.0/22muestra netname DE-CLOUDANDHEAT-20151125, país DE, organización ORG-CHTG1-RIPE y un objeto route originado en AS203592. La vista de 94.198.185.0/24 enhttps://stat.ripe.net/data/whois/data.json?resource=94.198.185.0/24muestra netname DE-CLOUDANDHEAT-20081029, país DE y un objeto route originado en AS203592 después de una actualización de enero de 2026. La vista de 2a0c:2c0::/29 enhttps://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0::/29muestra una asignación de RIPE de 2018 a la misma organización y objetos route6 para AS203592. La vista de 2a0c:2c0:dd80::/44 enhttps://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0:dd80::/44es particularmente interesante porque se llama IBH-DD8 y tiene una fecha de creación de diciembre de 2025. Esto apunta a un segmento más reciente localizado en Dresde, pero aún no revela las cargas de trabajo detrás.

Para un cliente, la conclusión sobre el enrutamiento es simple. AS203592 es una red viva, y las pruebas de enrutamiento públicas son sólidas. La conclusión más difícil es sobre la capacidad de servicio. Los prefijos y los ROA no nos dicen cuántos hipervisores están instalados, cuántos inquilinos están activos, qué sabores están agotados, dónde está físicamente el pool de GPU, o con qué frecuencia se prueba el almacenamiento en bloque después de una falla de nodo. Responden a la pregunta de identidad de red. No responden a la pregunta de aprovisionamiento.

La instalación y el registro de intercambio en Dresde son reales, pero no es todo el cloud

PeeringDB añade la pista física pública más clara. La búsqueda de red enhttps://www.peeringdb.com/api/net?asn=203592lista a CLOUD & HEAT Technologies GmbH como AS203592, con alcance regional, IPv6 habilitado, política de peering abierta, un intercambio y una instalación. El objeto de red enhttps://www.peeringdb.com/api/net/40650muestra la instalación configurada en IBH Dresden C2 y el intercambio configurado en DD-IX. El endpoint netfac enhttps://www.peeringdb.com/api/netfac?net_id=40650repite la asociación IBH Dresden C2. El endpoint netixlan enhttps://www.peeringdb.com/api/netixlan?asn=203592lista DD-IX, un campo de velocidad 10 Gbps, dirección IPv4 193.201.151.80, dirección IPv6 2001:7f8:79::3:1b48:1, route-server peer true y operational=true.

Esta combinación es inusualmente útil. Coloca a AS203592 en un entorno de interconexión nombrado en Dresde en lugar de dejar a los lectores solo con una dirección de empresa. El registro de instalación de PeeringDB enhttps://www.peeringdb.com/api/fac/14039identifica a IBH Dresden C2 como una instalación de IBH connect GmbH en Dresde, con la ruta del sitio web público para alojamiento y espacio en rack enhttps://www.ibh.de/rechenzentrum/housing-rackpace. El registro de intercambio DD-IX enhttps://www.peeringdb.com/api/ix/4282identifica a DD-IX como un intercambio en Dresde, lista IBH Dresden C2 y SachsenEnergieCenter Dresden en su conjunto de instalaciones, y apunta ahttps://dd-ix.net,https://dd-ix.net/statsyhttps://status.dd-ix.net. El sitio de DD-IX describe el intercambio como una plataforma no comercial para Dresde, diseñada para mantener el tráfico local local y servir a la región de Sajonia.

La lectura física aún debe mantenerse precisa. PeeringDB prueba que AS203592 tiene una asociación de instalación listada en IBH Dresden C2 y una conexión DD-IX. Esto no prueba que todo el cómputo IaaS de CLOUD & HEAT se encuentre en esa única instalación. Esto no prueba la disposición del almacenamiento. Esto no revela si el puerto DD-IX está cableado directamente a los hipervisores de clientes, a un router fronterizo, a un segmento de laboratorio, a una red de gestión o a un borde de intercambio.

Esto no revela la diversidad de cables transversales, la diversidad de switches, las alimentaciones eléctricas de los racks, la cobertura de generadores, la redundancia de refrigeración o los compromisos de reparación remota.

La propia empresa amplía el panorama más allá de una sola instalación de PeeringDB. Su página de IaaS indica que la infraestructura cloud pública se opera exclusivamente en centros de datos en Alemania y que los datos de los clientes se procesan y almacenan de acuerdo con el RGPD. Su página de Kubernetes gestionado indica que los datos de Kubernetes se procesan y almacenan en centros de datos certificados ISO 27001 conformes con el RGPD en Alemania. Su artículo SCS 2024 enhttps://www.cloudandheat.com/en/news-press/strengthening-digital-sovereignty-new-ways-in-the-cloud-with-yaook-and-scs-compatibility/discute un proyecto de centro de datos en Leipzig con envia TEL, Yaook y SCS. Su noticia de certificación 2026, del mismo sitio, indica que Cloud & Heat recibió el reconocimiento "Certified SCS-compatible IaaS" y que el premio se presentaría en el SCS Summit el 21 de junio de 2026. Estos puntos hacen que la huella sea más que una simple historia de puerto AS, pero no convierten todo el mapa de capacidad en conocimiento público.

La alimentación y la refrigeración son parte de la dependencia física, no solo una afirmación de sostenibilidad. La página de IaaS indica que Cloud & Heat utiliza refrigeración directa por agua caliente y la integración en circuitos de calefacción locales para permitir una operación eficiente en energía y la reutilización del calor residual de los servidores. La página del OpenStack marketplace también describe servidores refrigerados por agua y la reutilización del calor residual de los servidores.

Este es un contexto útil: si el cloud está diseñado en torno a la reutilización de calor, la instalación del edificio, el circuito de agua, el intercambiador de calor, la extracción de calor local y las ventanas de mantenimiento se convierten en parte de la dependencia del servicio. Un cliente de centro de datos convencional pregunta principalmente sobre la redundancia de alimentación y refrigeración. Un cliente de Cloud & Heat también debería preguntar cómo el mantenimiento de la reutilización de calor está aislado de la disponibilidad de cómputo.

Por lo tanto, las pruebas de Dresde respaldan una afirmación intermedia. Existe evidencia pública de un punto de interconexión en Dresde y evidencia pública de empresa de alojamiento cloud alemán. No hay suficiente evidencia pública para mapear cada carga de trabajo de cliente a un rack, cada zona de disponibilidad a un edificio, o cada instancia GPU a una cadena de alimentación y refrigeración específica. Los compradores pueden considerar Dresde como un centro operativo significativo, no como un diagrama de infraestructura completo.

Las pruebas de producto son más sólidas para OpenStack y Kubernetes que para la capacidad de repuesto

Las páginas de producto de CLOUD & HEAT son inusualmente concretas para un proveedor cloud regional. La página de IaaS lista tamaños de cómputo de 1 vCPU / 2 GB RAM / 15 GB SSD a 8 vCPU / 30 GB RAM / 100 GB SSD, ofrece familias de precios estándar y Memory+, publicita almacenamiento en bloque/objeto HDD, e indica que los clusters de almacenamiento son clusters Ceph de triple redundancia para almacenamiento de objetos y bloques. También lista clases de instancias GPU que incluyen T4, A10, V100 y A100. Esta página indica explícitamente que un pool NVMe de triple replicación puede ser suministrado dentro de las capacidades disponibles.

Esta frase es importante: la empresa vende recursos útiles, pero también reconoce que algunas clases de almacenamiento tienen capacidad limitada.

La página de Kubernetes gestionado es igualmente específica. Describe una opción autogestionada sobre OpenStack, soporte bajo demanda, Managed Kubernetes Basic con soporte 9/5 y tiempo de respuesta de cuatro horas, y Managed Kubernetes Full Service con diferentes niveles de soporte. Ambos niveles gestionados listan despliegue en múltiples zonas de disponibilidad para alta disponibilidad, protección de API mediante VPN, administración de clusters basada en GitOps, servicio de balanceador de carga, volúmenes persistentes OpenStack Cinder, almacenamiento local estático y dinámico, y políticas de red.

Full Service añade ingress, Certmanager, una pila de monitorización Prometheus y Grafana, monitorización y alertas de cluster 24/7, e instancias GPU. Estas son afirmaciones operativas, no solo eslóganes.

La página Patron refuerza el aspecto OpenStack de la historia. Indica que Cloud & Heat Patron es una distribución de OpenStack lista para usar, basada en la gestión del ciclo de vida de código abierto con Yaook, con componentes de nivel empresarial, compatibilidad SCS, automatización, sin bloqueo de proveedor y opciones de soporte. La página ofrece un modelo donde el cliente opera el cloud y un modelo donde Cloud & Heat proporciona la operación y monitorización, análisis de fallos, reparación de fallos y mantenimiento como actualizaciones. Menciona opciones de contrato de soporte 9-5 y 24/7.

Esto nos dice que CLOUD & HEAT no solo revende máquinas virtuales; vende conocimiento operativo en torno al propio OpenStack.

Las fuentes de OpenInfra corroboran el posicionamiento de infraestructura abierta. La página del OpenStack Marketplace enhttps://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-serviceslista los servicios cloud de Cloud & Heat e indica que el producto es OpenStack Powered. La página de empresa de apoyo de OpenInfra enhttps://www.openstack.org/community/supporting-organizations/profile/cloud-and-heatdescribe su pila tecnológica como que incluye OpenStack, Kubernetes, Yaook y Krake, e indica que la empresa contribuye a los esfuerzos de Sovereign Cloud Stack. La página del Foro de Estándares SCS enhttps://sovereigncloudstack.org/en/about-scs/forum-scs-standards/lista a Cloud & Heat Technologies GmbH entre los miembros comprometidos con infraestructuras cloud seguras y señala la colaboración con la Open Infrastructure Foundation.

La señal de cliente también es pública. La página de IaaS nombra a Scalytics, tracetronic, Nyris, elevait, alphaspeech y flow.d entre los clientes. La página de Kubernetes gestionado nombra a N+P Informationssysteme GmbH y elevait GmbH & Co. KG. La página de inicio contiene citas de N+P, elevait y STACKIT: N+P y elevait describen a Cloud & Heat como su proveedor de Kubernetes gestionado, mientras que STACKIT describe a Cloud & Heat como un socio tecnológico cloud que ayuda con el conocimiento de OpenStack. La página del OpenStack Marketplace enlaza a casos de estudio de clientes para elevait, N+P, Nyris y flow.d.

Estas son señales significativas de partes afectadas, pero no es un inventario de inquilinos.

La distinción entre instalado y utilizable es donde el análisis debe ralentizarse. La capacidad instalada son los servidores, almacenamiento, GPUs, switches, puertos DD-IX, proveedores de acceso, clusters OpenStack, planos de control Kubernetes y herramientas de soporte bajo control o gestión de la empresa. La capacidad utilizable es la parte que un cliente puede pedir, asignar, mantener en funcionamiento, recuperar y abandonar sin tiempo de inactividad inaceptable. Las páginas públicas muestran clases de producto, modelos de soporte, nombres de clientes y opciones tecnológicas.

No muestran el stock actual de GPU, cuotas por sabor, número total de hipervisores, diseño del dominio de fallo de Ceph, ratios de sobreasignación, calendarios de mantenimiento, retención de copias de seguridad o recuperación probada entre zonas.

La mención "dentro de las capacidades disponibles" en la nota de almacenamiento NVMe es una ventana útil a la realidad de la economía del cloud más pequeño. Un proveedor cloud puede publicitar una clase de almacenamiento y aún así limitar esa clase porque los discos de alto rendimiento son caros, la alimentación de la instalación es limitada, la replicación de almacenamiento consume capacidad bruta y la demanda del cliente cambia. Esto no hace que la oferta sea débil. La hace física.

Un comprador debería traducir cada línea de servicio en una pregunta de capacidad: cuánto está instalado, cuánto está reservado, cuánto se puede entregar este mes, y qué sucede cuando la demanda aumenta.

El riesgo ascendente, de soporte y de reparación se encuentra debajo de la capa de marketing

La política de enrutamiento pública en la base de datos de RIPE lista AS3320, AS15372, AS6830 y AS8220 alrededor de AS203592. El endpoint de vecinos observados de RIPEstat enhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS203592vio a AS15372, AS3320, AS8220 y AS213973 el 14 de julio de 2026. RIPEstat identifica a AS15372 como IBH connect enhttps://stat.ripe.net/data/as-overview/data.json?resource=AS15372, AS3320 como Deutsche Telekom enhttps://stat.ripe.net/data/as-overview/data.json?resource=AS3320, AS8220 como Colt enhttps://stat.ripe.net/data/as-overview/data.json?resource=AS8220, AS6830 como Liberty Global enhttps://stat.ripe.net/data/as-overview/data.json?resource=AS6830y AS213973 como BCIX Management enhttps://stat.ripe.net/data/as-overview/data.json?resource=AS213973. Esta es una mezcla creíble de señales de conectividad locales, nacionales y comerciales.

La reserva es que una lista de vecinos públicos no es un mapa contractual. No dice qué camino es tránsito de pago, qué camino es peering, qué camino es respaldo, qué prefijos se aceptan dónde, qué filtros de ruta son estrictos, qué ventanas de mantenimiento se superponen, o si el tráfico de cliente está fijado a un borde particular. Tampoco prueba que un endpoint de API de Kubernetes y un backend de almacenamiento IaaS tengan protección de red idéntica. La buena noticia es que AS203592 no es visible públicamente como una isla de un solo vecino.

La pregunta de provisión es si el servicio de cliente relevante tiene suficiente diversidad de camino real para sobrevivir a la falla específica que preocupa al cliente.

La falla de instalación es la siguiente capa. Si una carga de trabajo se ejecuta en un centro de datos alemán conectado a AS203592, el servicio depende de la alimentación de los racks, refrigeración, cables transversales ascendentes, switches, routers, redes de almacenamiento y acceso del personal. La instalación de PeeringDB para IBH Dresden C2 lista diverse serving substations=true, lo cual es una pista positiva a nivel de instalación.

Esto aún no divulga el diseño de alimentación de los racks de CLOUD & HEAT, la cobertura de doble cordón, el bypass de mantenimiento, la autonomía de baterías, el historial de pruebas del generador, o si una VM de cliente particular puede ser movida de la instalación afectada durante un incidente local. La conexión DD-IX ayuda para el intercambio de tráfico local, pero una falla de intercambio y una falla de centro de datos son eventos diferentes.

La falla de soporte es igualmente importante. La página de Kubernetes gestionado da un nivel de soporte 9/5 con tiempo de respuesta de cuatro horas para Basic y monitorización y alertas 24/7 para Full Service. La página Patron ofrece opciones de contrato de soporte 9-5 y 24/7 para entornos OpenStack operados. La página IaaS promete asesoramiento personalizado y orientado al servicio de expertos en OpenStack y DevOps. Estos son compromisos públicos útiles, pero el cliente aún necesita el contrato.

La página no divulga los objetivos de escalado para una falla de almacenamiento, evacuación de hipervisor, reemplazo de GPU, fuga de ruta, falla de DNS, ticket de abuso, bloqueo de facturación o exportación de datos de emergencia.

La prueba de DNS añade una pista operativa pequeña pero útil. Una consulta DNS durante esta revisión resolviówww.cloudandheat.coma través de cloudandheat.com hacia 185.128.119.78, que se encuentra dentro del prefijo 185.128.116.0/22 anunciado por AS203592. La misma consulta mostró mail.cloudandheat.com como MX, servidores de nombres INWX y registros SPF que incluyen el host mail y Google. Esto sugiere que el sitio web público se sirve desde el espacio enrutado de la empresa en lugar de solo desde un gran CDN de terceros. Esto es positivo para la identidad de red, pero también significa que el sitio público de la empresa puede verse afectado por su propio AS, su host web o sus dependencias de instalación.

El camino de impacto del cliente se deriva de la pila de productos. Una falla de red puede afectar la accesibilidad del cloud público, las API de Kubernetes gestionadas, los balanceadores de carga, la entrada de clientes, los puntos de distribución de software y posiblemente el propio sitio web o las superficies de soporte del proveedor. Una falla de almacenamiento puede afectar volúmenes y almacenamiento de objetos. Un incidente de alimentación o refrigeración puede afectar hipervisores y máquinas GPU. Una escasez de soporte u operaciones puede prolongar el tiempo de restauración incluso si el hardware es reparable.

Una falla de contrato o facturación puede bloquear cambios, exportaciones o escalado urgente. El material público prueba que la empresa tiene experiencia en estas áreas; no prueba que cada trayectoria de falla haya sido ensayada.

Esta no es una crítica exclusiva de CLOUD & HEAT. Es la forma normal de la dependencia cloud regional. El proveedor puede ser más transparente, más alineado con el código abierto y más local que una plataforma hyperscale, mientras sigue sujeto a las mismas restricciones físicas: espacio, alimentación, refrigeración, óptica, piezas de repuesto, filtros de ruta, ventanas de mantenimiento y disponibilidad humana.

La localidad de los datos es un punto fuerte, pero la localidad no es recuperabilidad automática

La promesa más fuerte de CLOUD & HEAT a los lectores es la localidad y la soberanía digital. La página de IaaS indica que la infraestructura cloud pública se opera exclusivamente en centros de datos en Alemania y que los datos se procesan y almacenan de acuerdo con el RGPD. La página de Kubernetes gestionado indica que los datos se procesan y almacenan en centros de datos certificados ISO 27001 conformes con el RGPD en Alemania. La página de inicio indica que los clientes pueden usar la infraestructura de CLOUD & HEAT o despliegues on-premise.

Las fuentes SCS y OpenInfra presentan a la empresa en torno a estándares abiertos, portabilidad y soberanía digital.

Estas afirmaciones importan. Un cliente alemán o europeo que intenta evitar el alojamiento offshore opaco tiene un modelo de riesgo diferente cuando la página de cloud público indica Alemania, OpenStack y pila de código abierto en lugar de una región genérica mundial. El material relacionado con SCS es importante para la interoperabilidad. El artículo de la empresa de 2024 indica que los estándares SCS apuntan a aumentar la interoperabilidad y portabilidad de las aplicaciones cloud. La noticia de certificación 2026 indica que Cloud & Heat recibió el reconocimiento Certified SCS-compatible IaaS.

El perfil de OpenInfra indica que la empresa contribuye a estándares como SCS. Todo esto es pertinente al tema de la soberanía y localidad de los datos.

Pero la localidad no debe confundirse con la recuperación. Un cliente puede saber que los datos están en Alemania y aún no saber si están replicados entre Dresde y Leipzig, entre dos salas en Dresde, en dos zonas de disponibilidad en un solo edificio, o dentro de un solo cluster de almacenamiento con dominios de fallo. La página de Kubernetes gestionado indica despliegue en múltiples zonas de disponibilidad para alta disponibilidad, pero no define esas zonas públicamente.

La página de IaaS indica clusters Ceph de triple redundancia y un pool NVMe de triple replicación opcional dentro de la capacidad disponible, pero no divulga si las réplicas son locales al rack, locales a la sala, locales al edificio o separadas en el campus. Las páginas públicas no muestran la ubicación de las copias de seguridad ni el historial de restauración.

Esto importa para clientes con obligaciones de cumplimiento. Si una carga de trabajo requiere almacenamiento alemán, las páginas públicas de CLOUD & HEAT respaldan la afirmación inicial. Si la carga de trabajo requiere un estado alemán particular, una zona eléctrica, separación de zona de disponibilidad, segregación de copias de seguridad, exportación en air gap o un plan de continuidad sectorial regulado, las páginas públicas no son suficientes.

El cliente debería solicitar una declaración sobre la ubicación de los datos, los subprocesadores, la ubicación de las copias de seguridad, el alcance de la replicación de almacenamiento, el acceso del personal, las ventanas de mantenimiento y la restauración probada. Si la carga de trabajo utiliza Kubernetes gestionado, el cliente también debería preguntar dónde residen el plano de control, etcd, los volúmenes persistentes, el registro de imágenes, los datos de monitorización y los logs.

El camino de migración es más claro gracias a las opciones tecnológicas. OpenStack, Kubernetes, volúmenes Cinder, almacenamiento Ceph, GitOps y compatibilidad SCS pueden reducir el bloqueo si se implementan con derechos de exportación y herramientas probadas. Un cliente puede ejecutar infraestructura como código, mantener copias de seguridad externas, mantener el DNS bajo su propio control, contenerizar aplicaciones y preparar un entorno OpenStack o Kubernetes de destino.

Pero las páginas públicas no prometen que cada imagen, volumen, snapshot, bucket de objetos, IP flotante, balanceador de carga o carga de trabajo GPU pueda exportarse rápidamente. Las tecnologías estándar hacen posible la migración; no la hacen automática.

Por lo tanto, la conclusión correcta es mixta. CLOUD & HEAT tiene una historia de soberanía creíble porque combina alojamiento alemán, OpenStack, Kubernetes, trabajo SCS e interconexión local. La misma historia debe ser probada en el límite del servicio: qué servicio está alojado en Alemania, qué parte es on-premise en un cliente, qué parte depende de IBH o DD-IX, qué parte depende de correo o DNS de terceros, y qué parte puede moverse durante una falla del proveedor. La soberanía no se trata solo del país. Se trata del control en momentos de estrés.

¿Quién se ve afectado si cnh-primary falla?

El primer grupo afectado son los clientes de cloud público e IaaS. La página de IaaS nombra clientes como Scalytics, tracetronic, Nyris, elevait, alphaspeech y flow.d. Vende recursos de cómputo, GPU y almacenamiento y posiciona el cloud para la protección de datos alemana y la soberanía digital. Si AS203592 o la ruta de instalación relevante falla, las máquinas virtuales de los clientes pueden permanecer encendidas pero volverse inaccesibles. Si la capa de almacenamiento falla, la disponibilidad de datos y el adjunto de volúmenes se convierten en el problema.

Si la capacidad se agota, el cliente puede no poder escalar incluso si las instancias existentes continúan funcionando.

El segundo grupo son los clientes de Kubernetes gestionado. La página de Kubernetes gestionado nombra a N+P Informationssysteme GmbH y elevait GmbH & Co. KG. Describe acceso a API a través de VPN, volúmenes persistentes OpenStack Cinder, balanceadores de carga, monitorización, ingress, Certmanager y despliegue multi-zona. Si la capa cloud del proveedor falla, Kubernetes puede reprogramar pods pero perder volúmenes, ingress o accesibilidad externa. Si el plano de control o la ruta VPN falla, los desarrolladores pueden perder el acceso de gestión.

Si la pila de monitorización es parte de la oferta de servicio completo del proveedor, la visibilidad de incidentes puede degradarse al mismo tiempo que el servicio mismo.

El tercer grupo son los clientes que usan CLOUD & HEAT como socio de operación OpenStack en lugar de anfitrión. La página de inicio cita a STACKIT diciendo que Cloud & Heat apoya el desarrollo y expansión de la infraestructura cloud con conocimiento de OpenStack. La página Patron vende una distribución OpenStack, instalación, puesta en marcha, operación, monitorización, análisis de fallos y actualizaciones. Una falla de AS203592 puede no afectar directamente a un cloud operado por el cliente, pero una falla de soporte aún puede ocurrir durante actualizaciones, incidentes o cambios urgentes.

Los clientes de consultoría y operación gestionada se ven afectados por la disponibilidad del personal, el acceso remoto, la documentación y la escalada, no necesariamente por las rutas de cnh-primary.

El cuarto grupo son las redes regionales y entidades con tráfico local. Las pruebas de PeeringDB y DD-IX colocan a AS203592 en DD-IX en Dresde. Un camino de intercambio local puede mejorar la latencia regional y la resiliencia cuando funciona; también puede convertirse en una dependencia si los clientes asumen que el tráfico local permanecerá local. DD-IX en sí mismo es un intercambio más amplio con múltiples entidades e instalaciones, por lo que un problema de CLOUD & HEAT no es un problema de DD-IX por defecto.

Pero los clientes que utilizan servicios cercanos a Dresde deberían monitorear tanto el estado de AS203592 como de DD-IX, ya que el camino de interconexión local es parte de la historia de rendimiento.

El quinto grupo es la presencia pública del propio proveedor. DNS colocówww.cloudandheat.comdentro de 185.128.116.0/22. Si la misma red o pila de alojamiento soporta el sitio público de la empresa, un incidente de infraestructura puede hacer que las páginas de producto y algunos puntos de entrada de clientes no estén disponibles en el momento en que los clientes necesitan información. La prueba DNS pública no prueba que el sistema de tickets de soporte esté en la misma pila, y el registro SPF incluye Google, por lo que el correo puede tener una ruta de dependencia diferente. No obstante, las comunicaciones públicas deberían ser parte de la diligencia debida del cliente: dónde está la página de estado, qué sucede si el sitio web principal no está disponible, y qué contactos de emergencia permanecen accesibles.

Por eso el lenguaje de la región afectada debe ser conservador. La asignación marca la región como Global porque los servicios cloud y alojados son accesibles globalmente y la categoría del directorio es servicio cloud global. La región operativa más fuerte en las pruebas públicas es Alemania, particularmente Dresde y Sajonia, con una conexión DD-IX documentada y afirmaciones de centros de datos alemanes. Los clientes fuera de Alemania aún pueden usar los servicios, pero la dependencia física no es global en el sentido hyperscale. Es un proveedor de cloud y tecnologías cloud alemán con alcance global.

La prueba de redundancia es buena en el borde de red e incompleta a nivel de servicio

Hay varias señales de redundancia positivas. AS203592 tiene cuatro vecinos observados en RIPEstat, no uno. Tiene visibilidad de enrutamiento pública en todos los pares RIS observados para IPv4 e IPv6 en el momento de la consulta. Tiene orígenes RPKI válidos para los cuatro prefijos observados. PeeringDB muestra participación en el servidor de rutas en DD-IX. La página de Kubernetes gestionado promete despliegue multi-zona de disponibilidad para alta disponibilidad. La página de IaaS menciona clusters Ceph de triple redundancia y una opción NVMe de triple replicación.

La página Patron ofrece contratos de operación y monitorización, incluyendo opciones 24/7.

Las brechas son igualmente importantes. La visibilidad de enrutamiento pública no divulga la ingeniería de tráfico. El puerto DD-IX de 10 Gbps de PeeringDB no divulga el uso o la conmutación por error. La validez RPKI no prueba la preparación para cambios de ruta. "Múltiples zonas de disponibilidad" no define la separación del radio de explosión. "Ceph de triple redundancia" no indica la colocación de réplicas. "Monitorización 24/7" no revela el personal de respuesta, la autoridad de escalado o los objetivos de restauración.

Las certificaciones ISO y el estado OpenStack Powered muestran una postura de proceso y tecnología, pero no son registros de incidentes. Un comprador no debería traducir estas afirmaciones públicas en una garantía integral de alta disponibilidad.

La prueba de redundancia práctica más fuerte que un comprador puede solicitar no es un folleto. Es una prueba de recuperación ejecutada: tomar una VM representativa, un volumen, un bucket de objetos, una carga de trabajo Kubernetes y una base de datos; simular una falla de zona; medir el tiempo de restauración; probar el cambio de DNS; exportar imágenes y volúmenes; reconstruir en un segundo proveedor o sitio cliente; y verificar la consistencia a nivel de aplicación. Para Kubernetes, preguntar cómo se recuperan etcd, volúmenes persistentes, controladores de ingress, balanceadores de carga y dependencias del registro.

Para OpenStack, preguntar cómo se comportan Nova, Neutron, Cinder, Glance, Keystone, Ceph y el DNS externo cuando falla un nodo de almacenamiento, un hipervisor, un router o un enlace de instalación.

La prueba de migración también debería ser específica del producto. Un cliente IaaS necesita exportación de imágenes, exportación de snapshots/volúmenes, transferencia de datos de objetos, planificación de cambio de dirección y liberación de cuotas. Un cliente Kubernetes necesita manifiestos, Helm charts, repositorios GitOps, gestión de secretos, migración de volúmenes persistentes y copia de seguridad externa. Un cliente GPU necesita disponibilidad de hardware alternativa y compatibilidad de controladores.

Un cliente Patron on-premise necesita documentación, runbooks, rutas de actualización y derechos para continuar operando si el soporte cambia. Estas son pruebas diferentes, y las páginas públicas no responden a todas.

La empresa se beneficia de sus opciones de código abierto. OpenStack y Kubernetes reducen algunos bloqueos en comparación con plataformas exclusivamente propietarias. La compatibilidad SCS está diseñada para aumentar la interoperabilidad y la portabilidad. Yaook y Tarook apuntan a una gestión automatizada del ciclo de vida. Pero el valor de los estándares abiertos solo aparece si el cliente controla su configuración, copias de seguridad, credenciales e instrucciones de construcción. El código abierto no es un sustituto de la planificación de salida. Es la base de un mejor plan de salida.

El nivel de dependencia final

cnh-primary CLOUD & HEAT Technologies GmbH debería ser elevado desde la sospecha inicial de "huella delgada". Las pruebas públicas no son escasas. AS203592 está vivo. RIPE muestra anuncios actuales, orígenes válidos y recursos numéricos alemanes. PeeringDB muestra una instalación en Dresde y una conexión DD-IX. El sitio web de la empresa vende IaaS y Kubernetes gestionado con detalles técnicos significativos. Las fuentes de OpenStack y OpenInfra corroboran el papel de la empresa en la infraestructura cloud abierta. Las fuentes relacionadas con SCS respaldan la historia de soberanía e interoperabilidad.

Las referencias de clientes son visibles.

La degradación no se trata de existencia. Se trata de evidencia de resiliencia. Las pruebas públicas no divulgan el cómputo instalado total, el stock de GPU, la capacidad bruta de almacenamiento, el número de inquilinos, el diseño por zona, el número de racks, las condiciones contractuales de instalación, la topología de alimentación, los procedimientos de asistencia remota, la ubicación de las copias de seguridad, el historial de restauración, el historial de incidentes, el personal de soporte exacto o las salidas de clientes probadas.

El lenguaje "dentro de las capacidades disponibles" de la página de IaaS es un recordatorio útil de que la capacidad utilizable es finita. Un comprador debería tratar cada frase de capacidad pública como una invitación a verificar el stock, las cuotas y las rutas de recuperación.

El nivel más útil está dividido. Identidad de red y pruebas de enrutamiento: Fuerte. Pruebas de producto y cliente: Fuerte. Pruebas de instalación e interconexión local: Medio-Fuerte, ya que Dresde y DD-IX son visibles pero toda la huella cloud no está mapeada públicamente. Pruebas de resiliencia de capacidad alojada: Medio, ya que las páginas públicas hacen afirmaciones concretas sobre disponibilidad, soporte y almacenamiento, pero se detienen antes de una evidencia dura. Pruebas de migración: Medio, ayudado por OpenStack, Kubernetes y SCS, pero dependiente de condiciones contractuales y preparación del cliente.

La prueba práctica es si un cliente puede transformar estas fortalezas públicas en control operativo. Un comprador que considera a Cloud & Heat como un proveedor cloud alemán estratégico debería solicitar un estado de capacidad actual, no solo un catálogo de servicios: CPU, memoria, GPU, almacenamiento en bloque, almacenamiento de objetos, almacenamiento de copias de seguridad y cuota de red disponibles por sitio o zona de disponibilidad.

Debería preguntar si una nueva máquina virtual puede aprovisionarse durante un evento de almacenamiento parcial, si un cluster Kubernetes puede reconstruirse sin secretos retenidos por el proveedor, si las IPs flotantes pueden reasignarse durante el mantenimiento del router, si los datos de objetos pueden exportarse sin limitación, y si el soporte puede ejecutar cambios urgentes cuando el sitio público o una ruta de peering está degradada. Estas son preguntas ordinarias para una capacidad alojada seria. No debilitan la historia de la empresa; hacen que las pruebas públicas sólidas sean utilizables.

Para la monitorización, seguir AS203592, 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29, 2a0c:2c0:dd80::/44, el puerto DD-IX, el sitio cloudandheat.com y las rutas de estado o soporte públicas. Para el aprovisionamiento, solicitar declaraciones de instalación, definiciones de zonas de disponibilidad, evidencia de diversidad de ruta, condiciones de respuesta de soporte, evidencia de respaldo y exportación, y un plan de migración probado. La empresa tiene una infraestructura creíble.

El punto de decisión es si el servicio específico que un cliente compra tiene suficiente capacidad utilizable y recuperación ensayada para sobrevivir a las fallas físicas que toda capacidad alojada finalmente encuentra.