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 Гбит/с, с адресами IPv4 и IPv6 и участием в маршрутном сервере.
• На страницах компании описаны IaaS, управляемый Kubernetes, работа над дистрибутивами OpenStack для on-premises, GPU-инстансы, хранилище Ceph, размещение в немецких дата-центрах, сертификаты ISO 27001 и ISO 9001, совместимая с SCS облачная работа и такие клиенты, как Scalytics, tracetronic, Nyris, elevait, alphaspeech, flow.d и N+P.
• Уровень доказательности высокий (Strong) для сетевой идентичности и существования продукта, средний (Medium) для локализации площадки и межсоединений и только средний для отказоустойчивости, поскольку публичные материалы не раскрывают количество стоек, топологию электропитания, резервные пулы серверов, точное размещение зон доступности, подтверждение резервного копирования, клиентские тесты экспорта или историю инцидентов.

Название начинается как маршрут, но компания шире маршрута

Запись в справочнике по адресуhttps://btw.media/en/directory/cnh-primary-cloud-heat-technologies-gmbhуказывает на вполне конкретный публичный инфраструктурный субъект: cnh-primary CLOUD & HEAT Technologies GmbH. Часть «cnh-primary» — не маркетинговый ход. Это имя AS203592 в реестре RIPE, которое показано в базе RIPE по адресуhttps://rest.db.ripe.net/ripe/aut-num/AS203592.jsonи в RDAP по адресуhttps://rdap.db.ripe.net/autnum/203592. AS была зарегистрирована 4 декабря 2015 года и последний раз изменена 28 января 2026 года. 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/описывает модели self-managed, on-demand, Basic и Full Service. Страница 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 и on-premises — предложения по консалтингу, ПО и управляемой эксплуатации. Страницы об энергоэффективности и профили OpenInfra описывают позиционирование в области устойчивости и открытого кода. Покупатель виртуальной машины зависит от одного, покупатель поддерживаемого дистрибутива OpenStack для собственного оборудования — от другого.

Пользователь управляемого Kubernetes зависит от доступа к API, кластеров, постоянных томов, мониторинга и окон обслуживания. Покупатель консалтинга зависит от людей и процессов больше, чем от AS203592. Публичные данные о компании реальны, но у каждого продукта свой путь отказа.

Ключевой вопрос поэтому не в том, существует ли CLOUD & HEAT. Она, безусловно, существует. Вопрос в том, какие публичные доказательства есть, если читать компанию как размещённую инфраструктуру. RIPE, RIPEstat и PeeringDB подтверждают сетевую карту AS203592. Сайт компании подтверждает каталог публичного облака и управляемых сервисов. OpenStack Marketplace по адресу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 может обещать мониторинг, пока клиенту всё равно нужен собственный план резервного копирования, развёртывания и экспорта. Запись о площадке может показывать присутствие в Дрездене, не раскрывая количество стоек, схему подводов питания или условия remote hands. Публичные данные достаточно сильны, чтобы отнести cnh-primary к серьёзной инфраструктурной категории, но читать их нужно с инженерной осторожностью.

Маршрутные доказательства актуальны, видны и чище, чем простая страница компании

Обзор AS203592 в RIPEstat по адресуhttps://stat.ripe.net/data/as-overview/data.json?resource=AS203592определил владельца как «cnh-primary CLOUD & HEAT Technologies GmbH» и показал announced=true на 2026-07-15 00:00 UTC. Это привязанный ко времени, но важный сигнал: AS не просто зарегистрирована — она была видна в публичных данных маршрутизации на дату публикации. Метод announced-prefixes в RIPEstat по адресуhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS203592перечислил четыре маршрута в двухнедельном окне, закончившемся 15 июля 2026 года: 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 и 2a0c:2c0:dd80::/44.

Метод routing-status по адресуhttps://stat.ripe.net/data/routing-status/data.json?resource=AS203592усилил сигнал. Он сообщил о двух префиксах IPv4, двух префиксах IPv6, 1280 адресах 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 — по адресуhttps://stat.ripe.net/data/prefix-overview/data.json?resource=94.198.185.0/24. Он также показал агрегат IPv6 2a0c:2c0::/29 по адресуhttps://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0::/29и более специфичный 2a0c:2c0:dd80::/44 по адресуhttps://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0:dd80::/44. Связь более специфичного IPv6-префикса важна: она намекает на сегментированное использование IPv6, а не на единый неразделённый аллокат.

RPKI тоже согласован. RIPEstat вернул valid для AS203592 и 185.128.116.0/22 по адресуhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=185.128.116.0/22, valid для 94.198.185.0/24 по адресуhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=94.198.185.0/24, valid для 2a0c:2c0::/29 по адресуhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0::/29и valid для 2a0c:2c0:dd80::/44 по адресуhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0:dd80::/44. Валидность RPKI не предотвращает отказ стойки, но снижает один класс сбоев маршрутизации: строгие сети с меньшей вероятностью отклонят эти источники как невалидные.

База RIPE также показывает административную преемственность префиксов. Представление WHOIS для 185.128.116.0/22 по адресуhttps://stat.ripe.net/data/whois/data.json?resource=185.128.116.0/22показывает netname DE-CLOUDANDHEAT-20151125, страну DE, организацию ORG-CHTG1-RIPE и объект route, источником которого является AS203592. Представление для 94.198.185.0/24 по адресуhttps://stat.ripe.net/data/whois/data.json?resource=94.198.185.0/24показывает netname DE-CLOUDANDHEAT-20081029, страну DE и объект route, источником которого является AS203592 после обновления в январе 2026 года. Представление для 2a0c:2c0::/29 по адресуhttps://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0::/29показывает аллокацию RIPE 2018 года той же организации и объекты route6 для AS203592. Представление для 2a0c:2c0:dd80::/44 по адресуhttps://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0:dd80::/44особенно интересно: оно названо IBH-DD8 и имеет дату создания в декабре 2025 года. Это указывает на более свежий сегмент, локальный для Дрездена, но по-прежнему не раскрывает нагрузки, стоящей за ним.

Для клиента вывод о маршрутах прост. 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 Гбит/с, адрес IPv4 193.201.151.80, адрес IPv6 2001:7f8:79::3:1b48:1, участие в route server как true и operational=true.

Эта комбинация необычно полезна. Она помещает AS203592 в названную дрезденскую среду межсоединений, а не оставляет читателя только с корпоративным адресом. Запись о площадке в PeeringDB по адресуhttps://www.peeringdb.com/api/fac/14039определяет IBH Dresden C2 как площадку IBH connect GmbH в Дрездене, с путём публичного сайта для housing и rackpace по адресу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. Это не доказывает, что все вычислительные мощности IaaS CLOUD & HEAT находятся в этой одной площадке. Это не доказывает схему хранения. Это не показывает, подключён ли порт DD-IX напрямую к клиентским гипервизорам, пограничному маршрутизатору, лабораторному сегменту, управляющей сети или edge для биржи.

Это не показывает разнообразие кросс-коннектов, разнообразие коммутаторов, подводы питания к стойкам, резервирование генераторов, избыточность охлаждения или обязательства по ремонту remote hands.

Сама компания расширяет картину за пределы одной площадки в PeeringDB. На странице IaaS сказано, что инфраструктура публичного облака эксплуатируется исключительно в дата-центрах в Германии и что данные клиентов обрабатываются и хранятся в соответствии с GDPR. На странице управляемого Kubernetes сказано, что данные Kubernetes обрабатываются и хранятся в сертифицированных по ISO 27001 дата-центрах в Германии, соответствующих GDPR. Статья о SCS 2024 года по адресу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 получила статус «Certified SCS-compatible IaaS» и что награда будет вручена на саммите SCS 21 июня 2026 года. Эти пункты делают присутствие более широким, чем история одного порта AS, но не превращают всю карту мощностей в публичное знание.

Энергоснабжение и охлаждение — часть физической зависимости, а не просто заявление об устойчивости. На странице IaaS сказано, что Cloud&Heat использует прямое горячеводяное охлаждение и интеграцию в местные тепловые контуры для энергоэффективной работы и повторного использования отходящего тепла серверов. Страница OpenStack Marketplace также описывает серверы с водяным охлаждением и повторное использование отходящего тепла. Это полезный контекст: если облако спроектировано вокруг повторного использования тепла, здание, водяной контур, теплообменник, местный отбор тепла и окна обслуживания становятся частью зависимости сервиса.

Обычный клиент дата-центра в основном спрашивает об избыточности питания и охлаждения. Клиенту Cloud&Heat стоит также спросить, как обслуживание контура повторного использования тепла изолировано от доступности вычислений.

Таким образом, дрезденские доказательства поддерживают среднее утверждение. Есть публичное подтверждение точки межсоединения в Дрездене и публичное подтверждение компанией немецкого облачного хостинга. Недостаточно публичных доказательств, чтобы сопоставить каждую рабочую нагрузку клиента со стойкой, каждую зону доступности со зданием или каждый GPU-инстанс с конкретной цепочкой питания и охлаждения. Покупатели могут рассматривать Дрезден как значимый операционный центр, а не как полную схему инфраструктуры.

Продуктовые доказательства сильнее для OpenStack и Kubernetes, чем для резервных мощностей

Продуктовые страницы CLOUD & HEAT необычно конкретны для регионального облачного провайдера. Страница IaaS перечисляет вычислительные конфигурации от 1 vCPU / 2 ГБ ОЗУ / 15 ГБ SSD до 8 vCPU / 30 ГБ ОЗУ / 100 ГБ SSD, предлагает ценовые семейства standard и Memory+, рекламирует блочное/объектное хранилище на HDD и говорит, что кластеры хранения — это тройной резервированные кластеры Ceph для объектного и блочного хранения. Она также перечисляет классы GPU-инстансов, включая T4, A10, V100 и A100. На этой странице прямо сказано, что пул NVMe с тройной репликацией может быть предоставлен в пределах доступных мощностей.

Эта фраза важна: компания продаёт полезные ресурсы, но также признаёт, что некоторый класс хранения ограничен по ёмкости.

Страница управляемого Kubernetes столь же конкретна. Она описывает опцию self-managed на OpenStack, поддержку on-demand, Managed Kubernetes Basic с поддержкой 9/5 и временем ответа четыре часа, а также Managed Kubernetes Full Service с другими уровнями поддержки. Оба управляемых тарифа перечисляют развёртывание в нескольких зонах доступности для высокой доступности, защиту API через VPN, администрирование кластеров на основе GitOps, сервис балансировщика нагрузки, постоянные тома OpenStack Cinder, локальное статическое и динамическое хранилище и сетевые политики.

Full Service добавляет ingress, Certmanager, стек мониторинга Prometheus и Grafana, круглосуточный мониторинг и оповещение кластеров, а также GPU-инстансы. Это операционные заявления, а не просто лозунги.

Страница Patron усиливает сторону OpenStack. Она говорит, что Cloud&Heat Patron — это готовый к использованию дистрибутив OpenStack, основанный на открытом жизненном цикле управления с Yaook, с компонентами корпоративного класса, совместимостью с SCS, автоматизацией, отсутствием вендорного блокирования и опциями поддержки. Страница предлагает модель, где клиент эксплуатирует облако, и модель, где Cloud&Heat предоставляет эксплуатацию и мониторинг, анализ отказов, устранение отказов и обслуживание, например обновления. Упоминаются варианты контрактов поддержки 9-5 и 24/7.

Это говорит о том, что CLOUD & HEAT не просто перепродаёт виртуальные машины; она продаёт эксплуатационные знания вокруг самого OpenStack.

Источники OpenInfra подтверждают позиционирование в открытой инфраструктуре. Страница OpenStack Marketplace по адресу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 Marketplace содержит ссылки на клиентские кейсы elevait, N+P, Nyris и flow.d.

Это значимые сигналы от заинтересованных сторон, но не реестр арендаторов.

Различие между установленной и доступной ёмкостью — то место, где анализ должен замедлиться. Установленная ёмкость — это серверы, хранилище, GPU, коммутаторы, порты DD-IX, апстримы, кластеры OpenStack, control plane Kubernetes и инструменты поддержки, находящиеся под контролем или управлением компании. Доступная ёмкость — это часть, которую клиент может заказать, распределить, поддерживать в работе, восстановить и покинуть без неприемлемого простоя. Публичные страницы показывают классы продуктов, модели поддержки, имена клиентов и технологические решения.

Они не показывают текущий запас GPU, квоты по флейворам, общее количество гипервизоров, схему failure domain в Ceph, коэффициенты оверкоммита, календари обслуживания, политику хранения резервных копий или проверенное межзональное восстановление.

Оговорка «в пределах доступных мощностей» в примечании о NVMe-хранилище — полезное окно в реальность экономики небольшого облака. Облачный провайдер может рекламировать класс хранилища и всё же ограничивать его, потому что высокопроизводительные диски дороги, мощность площадки конечна, репликация хранения потребляет полезную ёмкость, а клиентский спрос меняется. Это не делает предложение слабым. Это делает его физическим. Покупателю следует переводить каждую строку сервиса в вопрос о ёмкости: сколько установлено, сколько зарезервировано, сколько может быть поставлено в этом месяце и что меняется при скачке спроса.

Апстримы, поддержка и ремонтные риски находятся ниже маркетингового слоя

Публичная политика маршрутизации в базе RIPE перечисляет AS3320, AS15372, AS6830 и AS8220 вокруг AS203592. Метод observed-neighbours в RIPEstat по адресуhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS203592видел AS15372, AS3320, AS8220 и AS213973 14 июля 2026 года. RIPEstat определяет AS15372 как IBH connect по адресуhttps://stat.ripe.net/data/as-overview/data.json?resource=AS15372, AS3320 как Deutsche Telekom по адресуhttps://stat.ripe.net/data/as-overview/data.json?resource=AS3320, AS8220 как Colt по адресуhttps://stat.ripe.net/data/as-overview/data.json?resource=AS8220, AS6830 как Liberty Global по адресуhttps://stat.ripe.net/data/as-overview/data.json?resource=AS6830и AS213973 как BCIX Management по адресуhttps://stat.ripe.net/data/as-overview/data.json?resource=AS213973. Это правдоподобная смесь локальных, национальных и коммерческих сигналов связности.

Оговорка в том, что публичный список соседей — не карта контрактов. Он не говорит, какой путь — платный транзит, какой — пиринг, какой — резервный, какие префиксы принимаются где, какие фильтры маршрутов строгие, какие окна обслуживания пересекаются и привязан ли клиентский трафик к конкретному edge. Он также не доказывает, что API-эндпоинт Kubernetes и бэкенд хранилища IaaS имеют одинаковую сетевую защиту. Хорошая новость в том, что AS203592 публично не выглядит островом с одним соседом.

Вопрос для закупки — достаточно ли реального разнообразия путей у конкретного клиентского сервиса, чтобы пережить именно тот сбой, которого опасается клиент.

Отказ площадки — следующий слой. Если рабочая нагрузка работает в немецком дата-центре, подключённом к AS203592, сервис зависит от питания стоек, охлаждения, апстрим-кросс-коннектов, коммутаторов, маршрутизаторов, сетей хранения и доступа персонала. Площадка PeeringDB для IBH Dresden C2 указывает diverse serving substations=true, что является положительным сигналом на уровне площадки. Но она не раскрывает схему питания стоек CLOUD & HEAT, покрытие dual-cord, байпас обслуживания, время работы батарей, историю тестов генераторов или возможность переместить конкретную клиентскую ВМ из затронутой площадки во время локального инцидента.

Подключение к DD-IX помогает локальному обмену трафиком, но сбой биржи и сбой дата-центра — разные события.

Отказ поддержки не менее важен. Страница управляемого Kubernetes даёт уровень поддержки 9/5 с четырёхчасовым временем ответа для Basic и круглосуточный мониторинг и оповещение для Full Service. Страница Patron предлагает варианты контрактов поддержки 9-5 и 24/7 для эксплуатируемых сред OpenStack. Страница IaaS обещает персональные, ориентированные на сервис консультации от экспертов OpenStack и DevOps. Это полезные публичные обязательства, но клиенту всё равно нужен договор.

Страница не раскрывает цели эскалации для сбоя хранилища, эвакуации гипервизора, замены GPU, утечки маршрута, сбоя DNS, жалобы на злоупотребления, блокировки биллинга или срочного экспорта данных.

Данные DNS добавляют небольшую, но полезную операционную зацепку. DNS-запрос во время этого обзора разрешилwww.cloudandheat.comчерез cloudandheat.com в 185.128.119.78, который находится внутри префикса 185.128.116.0/22, анонсируемого AS203592. Тот же запрос показал mail.cloudandheat.com как MX, NS-серверы INWX и записи SPF, включающие почтовый хост и Google. Это позволяет предположить, что публичный сайт обслуживается из собственного маршрутизируемого пространства компании, а не только с большого стороннего CDN. Это положительно для сетевой идентичности, но также означает, что публичный сайт компании может быть затронут сбоями её собственной AS, веб-хостинга или площадки.

Путь влияния на клиента следует из продуктового стека. Сбой сети может затронуть доступность публичного облака, API управляемого Kubernetes, балансировщики нагрузки, клиентский ingress, эндпоинты распространения ПО и, возможно, собственный сайт или поверхности поддержки провайдера. Сбой хранилища может затронуть тома и объектное хранилище. Инцидент с питанием или охлаждением может затронуть гипервизоры и GPU-машины. Дефицит поддержки или операций может увеличить время восстановления, даже если оборудование ремонтопригодно. Сбой контракта или биллинга может заблокировать изменения, экспорт или срочное масштабирование.

Публичные материалы доказывают, что компания опытна в этих областях; они не доказывают, что каждый путь отказа был отрепетирован.

Это критика не уникальна для CLOUD & HEAT. Это обычная форма зависимости от регионального облака. Провайдер может быть прозрачнее, более ориентирован на открытый код и более локальным, чем гиперскейлер, но при этом подчиняться тем же физическим ограничениям: пространство, питание, охлаждение, оптика, запчасти, фильтры маршрутов, окна обслуживания и наличие людей.

Локализация данных — преимущество, но локализация не означает автоматическое восстановление

Сильнейшее читаемое обещание CLOUD & HEAT — локализация и цифровой суверенитет. На странице IaaS сказано, что инфраструктура публичного облака эксплуатируется исключительно в дата-центрах в Германии и что данные обрабатываются и хранятся в соответствии с GDPR. На странице управляемого Kubernetes сказано, что данные обрабатываются и хранятся в сертифицированных по ISO 27001 дата-центрах в Германии, соответствующих GDPR. На главной странице сказано, что клиенты могут использовать инфраструктуру CLOUD & HEAT или локальные развёртывания.

Источники SCS и OpenInfra описывают компанию через открытые стандарты, переносимость и цифровой суверенитет.

Эти заявления важны. Немецкий или европейский клиент, пытающийся избежать непрозрачного зарубежного хостинга, имеет другую модель риска, когда страница публичного облака говорит «Германия», «OpenStack» и «стек с открытым кодом», а не общий глобальный регион. Материалы, связанные с SCS, важны для интероперабельности. Статья компании 2024 года говорит, что стандарты SCS призваны повысить интероперабельность и переносимость облачных приложений. Новость о сертификации 2026 года говорит, что Cloud&Heat получила статус Certified SCS-compatible IaaS. Профиль OpenInfra говорит, что компания вносит вклад в такие стандарты, как SCS.

Всё это относится к теме суверенитета и локализации данных.

Но локализацию не следует путать с восстановлением. Клиент может знать, что данные находятся в Германии, и при этом не знать, реплицируются ли они между Дрезденом и Лейпцигом, между двумя дрезденскими помещениями, через две зоны доступности в одном здании или внутри одного кластера хранения с failure domain. На странице управляемого Kubernetes сказано о развёртывании в нескольких зонах доступности для высокой доступности, но эти зоны публично не определены.

На странице IaaS сказано о тройных резервированных кластерах Ceph и опциональном пуле NVMe с тройной репликацией в пределах доступных мощностей, но не раскрыто, являются ли реплики локальными для стойки, помещения, здания или разделены по кампусу. Публичные страницы не показывают местоположение резервных копий или историю восстановлений.

Это важно для клиентов с обязательствами по соответствию. Если рабочей нагрузке требуется хранение в Германии, публичные страницы CLOUD & HEAT поддерживают исходное заявление. Если рабочей нагрузке требуется конкретная федеральная земля Германии, энергозона, разделение зон доступности, сегрегация резервных копий, изолированный экспорт или отраслевой план непрерывности, публичных страниц недостаточно. Клиенту следует запросить заявление о месте размещения данных, субагентах, месте резервного копирования, охвате репликации хранилища, доступе персонала, окнах обслуживания и проверенном восстановлении.

Если рабочая нагрузка использует управляемый Kubernetes, клиенту также стоит спросить, где живут control plane, etcd, постоянные тома, реестр образов, данные мониторинга и логи.

Путь миграции яснее благодаря технологическим решениям. OpenStack, Kubernetes, тома Cinder, хранилище на Ceph, GitOps и совместимость с SCS могут снизить зависимость от поставщика, если они реализованы с правами на экспорт и проверенными инструментами. Клиент может вести инфраструктуру как код, поддерживать внешние резервные копии, держать DNS под своим контролем, контейнеризировать приложения и подготовить целевую среду OpenStack или Kubernetes. Но публичные страницы не обещают, что каждый образ, том, снапшот, объектный бакет, плавающий IP, балансировщик нагрузки или GPU-нагрузка могут быть быстро экспортированы.

Стандартные технологии делают миграцию возможной; они не делают её автоматической.

Поэтому правильный вывод смешанный. CLOUD & HEAT имеет правдоподобную историю суверенитета, потому что сочетает немецкий хостинг, OpenStack, Kubernetes, работу с SCS и локальные межсоединения. Ту же историю нужно проверять на границе сервиса: какой сервис размещён в Германии, какая часть находится on-premises у клиента, какая зависит от 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. Она описывает доступ к API через VPN, постоянные тома OpenStack Cinder, балансировщики нагрузки, мониторинг, ingress, Certmanager и многозональное развёртывание. Если облачный слой провайдера выйдет из строя, Kubernetes может перепланировать поды, но потерять тома, ingress или внешнюю доступность. Если выйдет из строя control plane или VPN-путь, разработчики могут потерять управленческий доступ.

Если стек мониторинга является частью Full Service, видимость инцидентов может ухудшиться вместе с самим сервисом.

Третья группа — клиенты, использующие 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, поэтому почта может иметь другой путь зависимости. Тем не менее публичные коммуникации должны быть частью due diligence клиента: где страница статуса, что происходит, если основной сайт недоступен, и какие экстренные контакты остаются достижимыми?

Именно поэтому формулировки о затронутом регионе должны быть консервативными. Задание помечает регион как Global, потому что облачные и размещённые сервисы достижимы по всему миру, а категория справочника — глобальный облачный сервис. Сильнейший операционный регион по публичным доказательствам — Германия, особенно Дрезден и Саксония, с задокументированным подключением к DD-IX и заявлениями о немецких дата-центрах. Клиенты за пределами Германии тоже могут пользоваться сервисами, но физическая зависимость не является глобальной в смысле гиперскейлера. Это немецкое облако и облачно-технологическая компания с глобальной достижимостью.

Доказательства резервирования хороши на сетевом крае и неполны на уровне сервиса

Есть несколько положительных сигналов резервирования. У AS203592 четыре наблюдаемых соседа в RIPEstat, а не один. Она имеет публичную маршрутную видимость во всех наблюдаемых пирах RIS как для IPv4, так и для IPv6 на момент запроса. Все четыре наблюдаемых префикса имеют валидные источники RPKI. PeeringDB показывает участие в route server на DD-IX. Страница управляемого Kubernetes обещает многозональное развёртывание для высокой доступности. Страница IaaS упоминает тройные резервированные кластеры Ceph и опцию NVMe с тройной репликацией. Страница Patron предлагает контракты на эксплуатацию и мониторинг, включая варианты 24/7.

Пробелы не менее важны. Публичная маршрутная видимость не раскрывает инженерию трафика. Порт DD-IX на 10 Гбит/с в PeeringDB не раскрывает загрузку или переключение при отказе. Валидность RPKI не доказывает готовность к изменению маршрутов. «Несколько зон доступности» не определяет разделение радиуса поражения. «Тройной резервированный Ceph» не указывает размещение реплик. «Круглосуточный мониторинг» не показывает укомплектованность реагирования, полномочия эскалации или цели восстановления. Сертификаты ISO и статус OpenStack Powered показывают процессы и технологическую позицию, но не являются записями об инцидентах.

Покупателю не следует превращать эти публичные заявления в безусловную гарантию высокой доступности.

Сильнейшее практическое доказательство резервирования, которое может запросить покупатель, — не брошюра. Это проверенный прогон восстановления: взять репрезентативную ВМ, том, объектный бакет, рабочую нагрузку Kubernetes и базу данных; смоделировать отказ зоны; измерить время восстановления; проверить смену DNS; экспортировать образы и тома; пересобрать у второго провайдера или на площадке клиента; и убедиться в согласованности на уровне приложения. Для Kubernetes стоит спросить, как восстанавливаются etcd, постоянные тома, ingress-контроллеры, балансировщики нагрузки и зависимости реестра.

Для OpenStack стоит спросить, как Nova, Neutron, Cinder, Glance, Keystone, Ceph и внешний DNS ведут себя при отказе узла хранения, гипервизора, маршрутизатора или связи площадки.

Доказательство миграции также должно быть продуктово-специфичным. Клиенту IaaS нужны экспорт образов, снапшоты/экспорт томов, перенос объектных данных, планирование смены адресов и освобождение квот. Клиенту Kubernetes нужны манифесты, Helm-чарты, репозитории GitOps, работа с секретами, миграция постоянных томов и внешнее резервное копирование. GPU-клиенту нужна доступность альтернативного оборудования и совместимость драйверов. On-premises-клиенту Patron нужны документация, runbook, пути обновления и право продолжать работу при изменении поддержки. Это разные тесты, и публичные страницы отвечают не на все из них.

Компании помогают её решения в пользу открытого кода. OpenStack и Kubernetes снижают часть зависимости от поставщика по сравнению с платформами только с проприетарным ПО. Совместимость с SCS призвана повысить интероперабельность и переносимость. Yaook и Tarook указывают на автоматизированное управление жизненным циклом. Но ценность открытых стандартов проявляется только если клиент контролирует свою конфигурацию, резервные копии, учётные данные и инструкции по сборке. Открытый код — не замена планирования выхода. Это фундамент для лучшего плана выхода.

Итоговая оценка зависимости

cnh-primary CLOUD & HEAT Technologies GmbH следует повысить с первоначального подозрения в «тонком следе». Публичные доказательства не тонкие. AS203592 жива. RIPE показывает текущие анонсы, валидные источники и немецкие номерные ресурсы. PeeringDB показывает площадку в Дрездене и подключение к DD-IX. Сайт компании продаёт IaaS и управляемый Kubernetes со значимой технической детализацией. Источники OpenStack и OpenInfra подтверждают роль компании в открытой облачной инфраструктуре. Материалы, связанные с SCS, поддерживают историю суверенитета и интероперабельности. Видны клиентские рекомендации.

Понижение связано не с существованием. Оно связано с доказательством устойчивости. Публичные доказательства не раскрывают общий установленный объём вычислений, запас GPU, сырую ёмкость хранилища, количество арендаторов, схему зон, количество стоек, условия контракта на площадку, топологию питания, процедуры remote hands, место резервного копирования, историю восстановлений, историю инцидентов, точную укомплектованность поддержки или проверенные выходы клиентов. Оговорка «в пределах доступных мощностей» на странице IaaS — полезное напоминание, что доступная ёмкость конечна.

Покупателю следует рассматривать каждую публичную фразу о ёмкости как приглашение проверить запасы, квоты и пути восстановления.

Самая полезная оценка — раздельная. Сетевая идентичность и маршрутные доказательства: Strong (высокая). Продуктовые и клиентские доказательства: Strong (высокая). Доказательства площадки и локальных межсоединений: Medium-strong (средне-высокая), потому что Дрезден и DD-IX видны, но вся облачная география публично не нанесена на карту. Доказательства устойчивости размещённых мощностей: Medium (средняя), потому что публичные страницы делают конкретные заявления о доступности, поддержке и хранении, но не доходят до жёстких доказательств.

Доказательства миграции: Medium (средняя), чему помогают 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 и публичные пути статуса или поддержки. Для закупки запрашивайте заявления о площадке, определения зон доступности, доказательства разнообразия маршрутов, условия времени ответа поддержки, доказательства резервного копирования и экспорта и проверенный план миграции. У компании есть заслуживающая доверия инфраструктура.

Точка решения — достаточно ли у конкретного покупаемого сервиса доступной ёмкости и отрепетированного восстановления, чтобы пережить физические отказы, с которыми рано или поздно сталкиваются любые размещённые мощности.