cnh-primary CLOUD & HEAT Technologies GmbH تبيع سعة مستضافة

ملخص

cnh-primary يتوافق مع AS203592، نظام مستقل مسجل في RIPE باسم "cnh-primary" ومسجل لصالح CLOUD & HEAT Technologies GmbH. يُظهر RDAP في RIPE أن النظام المستقل نشط، وأظهر 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 المحلي، وأمثلة 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" ليس تزيينًا تسويقيًا. إنه اسم AS في RIPE لـ AS203592، كما هو موضح في قاعدة بيانات 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/نماذج 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 Marketplace علىhttps://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-servicesخدمات CLOUD & HEAT السحابية ويقول إن المنتج مدعوم من OpenStack. يصف ملف الشركة الداعمة لـ OpenStack علىhttps://www.openstack.org/community/supporting-organizations/profile/cloud-and-heatCLOUD & HEAT كمزود دريسدن للخدمات السحابية والتقنيات السحابية. لا يوفر أي من هذه المصادر تدقيقًا كاملاً للسعة العامة.

هذا هو التمييز المهم للمشترين. يمكن أن يكون AS عام صحيًا بينما لا توجد آلات احتياطية في منطقة توفر واحدة. يمكن إدراج سحابة OpenStack بينما تكون فئة GPU معينة مباعة بالكامل. يمكن أن يعد عرض Kubernetes المُدار بالمراقبة بينما لا يزال العميل بحاجة إلى خطة النسخ الاحتياطي والنشر والتصدير الخاصة به. يمكن أن يُظهر إدخال المنشأة وجودًا في دريسدن دون الكشف عن عدد الرفوف أو تصميم مصدر الطاقة أو شروط المساعدة عن بُعد. السجل العام قوي بما يكفي لوضع cnh-primary في فئة بنية تحتية جادة، لكنه لا يزال بحاجة إلى القراءة بحذر هندسي.

أدلة المسار حالية ومرئية وأنظف من صفحة شركة بسيطة

حددت نظرة عامة AS في RIPEstat لـ AS203592 على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 مسجلًا فقط؛ كان مرئيًا في بيانات التوجيه العامة في تاريخ النشر. سردت نقطة نهاية المسارات المعلنة في 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.

جعلت نقطة نهاية حالة التوجيه علىhttps://stat.ripe.net/data/routing-status/data.json?resource=AS203592الإشارة أقوى. أبلغت عن بادئتي IPv4 وبادئتي IPv6 و1,280 عنوان IPv4 و524,288 وحدة IPv6 /48 وأربعة جيران مرصودين ورؤية كاملة في مجموعة نظير RIS لـ RIPE لكل من 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::/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 صالحًا لـ AS203592 و185.128.116.0/22 علىhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=185.128.116.0/22، وصالحًا لـ 94.198.185.0/24 علىhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=94.198.185.0/24، وصالحًا لـ 2a0c:2c0::/29 علىhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0::/29، وصالحًا لـ 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/22netname 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/24netname DE-CLOUDANDHEAT-20081029 وcountry DE وكائن مسار نشأ من 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 هو شبكة حية، وأدلة التوجيه العامة قوية. الاستنتاج الأصعب يتعلق بسعة الخدمة. لا تخبرنا البادئات وROAs بعدد برامج المراقبة المثبتة، أو عدد المستأجرين النشطين، أو النكهات غير المتوفرة، أو مكان تواجد مجموعة GPU فعليًا، أو عدد مرات اختبار التخزين الكتلي بعد فشل العقدة. إنها تجيب على سؤال هوية الشبكة. لا تجيب على سؤال الشراء.

منشأة دريسدن وسجل التبادل حقيقيان، لكنهما ليسا السحابة بأكملها

يضيف PeeringDB أوضح دليل مادي عام. يسرد البحث عن الشبكة علىhttps://www.peeringdb.com/api/net?asn=203592CLOUD & 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=203592DD-IX وحقل سرعة 10 جيجابت في الثانية وعنوان 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/14039IBH Dresden C2 كمنشأة تابعة لـ IBH connect GmbH في دريسدن، مع مسار موقع الويب العام للإسكان ومساحة الرف علىhttps://www.ibh.de/rechenzentrum/housing-rackpace. يحدد سجل تبادل DD-IX علىhttps://www.peeringdb.com/api/ix/4282DD-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 موصولًا مباشرة ببرامج مراقبة العميل أو جهاز توجيه حدودي أو جزء معملي أو شبكة إدارة أو حافة مواجهة للتبادل. إنه لا يكشف تنوع التوصيلات المتقاطعة أو تنوع المحولات أو مصادر طاقة الرف أو تغطية المولد أو تبريد التكرار أو التزامات الإصلاح عن بُعد.

الشركة نفسها توسع الصورة إلى ما هو أبعد من منشأة 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 GB RAM / 15 GB SSD إلى 8 vCPU / 30 GB RAM / 100 GB SSD، وتقدم عائلات أسعار قياسية وMemory+، وتعلن عن تخزين كتلي/كائنات HDD، وتقول إن مجموعات التخزين هي مجموعات Ceph ثلاثية التكرار للتخزين الكتلي والكائنات. تسرد أيضًا فئات مثيلات GPU بما في ذلك T4 وA10 وV100 وA100. تقول تلك الصفحة صراحة إن مجموعة NVMe ثلاثية النسخ يمكن توفيرها ضمن السعات المتوفرة. هذه العبارة مهمة: تبيع الشركة موارد مفيدة، لكنها تعترف أيضًا أن بعض فئات التخزين محدودة السعة.

صفحة Kubernetes المُدارة محددة بالمثل. تصف خيارًا ذاتي الإدارة على OpenStack، ودعمًا عند الطلب، وManaged Kubernetes Basic مع دعم 9/5 ووقت استجابة أربع ساعات، وManaged Kubernetes Full Service بمستويات دعم مختلفة. يسرد كلا المستويين المُدارين النشر عبر مناطق توفر متعددة لتحقيق التوفر العالي، وحماية API عبر VPN، وإدارة المجموعة المستندة إلى GitOps، وخدمة موازن التحميل، وأحجام Cinder الثابتة من OpenStack، والتخزين المحلي الثابت والديناميكي وسياسات الشبكة. يضيف 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. تصف صفحة الشركة الداعمة لـ 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 وطائرات التحكم Kubernetes وأدوات الدعم تحت سيطرة الشركة أو إدارتها. السعة القابلة للاستخدام هي الجزء الذي يمكن للعميل طلبه وتخصيصه وإبقائه قيد التشغيل واستعادته ومغادرته دون توقف غير مقبول. تُظهر الصفحات العامة فئات المنتجات ونماذج الدعم وأسماء العملاء والخيارات التقنية. لا تُظهر مخزون GPU الحالي أو حصص لكل نكهة أو إجمالي عدد برامج المراقبة أو تصميم مجال فشل Ceph أو نسب التجاوز أو تقويمات الصيانة أو احتفاظ النسخ الاحتياطي أو الاسترداد المختبر عبر المناطق.

تحذير "ضمن السعات المتوفرة" في ملاحظة تخزين NVMe هو نافذة مفيدة على واقع اقتصادات السحابة الأصغر. يمكن لمزود السحابة الإعلان عن فئة تخزين وما زال يحد من تلك الفئة لأن محركات الأداء العالي باهظة الثمن، وطاقة المنشأة محدودة، وتستهلك نسخ التخزين السعة الخام، ويتغير طلب العملاء. هذا لا يجعل العرض ضعيفًا. إنه يجعله ماديًا. يجب على المشتري ترجمة كل سطر خدمة إلى سؤال سعة: ما هو المثبت، وما هو المحجوز، وما الذي يمكن تسليمه هذا الشهر، وما الذي يتغير عندما يرتفع الطلب؟

مخاطر المنبع والدعم والإصلاح تقع تحت طبقة التسويق

تسرد سياسة التوجيه العامة في قاعدة بيانات RIPE AS3320 وAS15372 وAS6830 وAS8220 حول AS203592. رأت نقطة نهاية الجيران المرصودين في RIPEstat علىhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS203592AS15372 و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. هذا مزيج موثوق من إشارات الاتصال المحلية والوطنية والتجارية.

التحذير هو أن قائمة الجيران العامة ليست خريطة عقد. إنها لا تقول أي مسار عبارة عن عبور مدفوع، وأي مسار نظير، وأي مسار احتياطي، وأي بادئات مقبولة وأين، ومرشحات التوجيه الصارمة، ونوافذ الصيانة المتداخلة، أو ما إذا كانت حركة مرور العميل مثبتة على حافة معينة. كما أنها لا تثبت أن نقطة نهاية API Kubernetes وواجهة تخزين IaaS لهما حماية شبكة متطابقة. الخبر السار هو أن AS203592 ليس مرئيًا بشكل عام كجزيرة ذات جار واحد. سؤال الشراء هو ما إذا كانت خدمة العميل ذات الصلة لديها تنوع مسار كافٍ للبقاء على قيد الحياة من الفشل المحدد الذي يهم العميل.

فشل المنشأة هو الطبقة التالية. إذا كان حمل العمل يعمل في مركز بيانات ألماني متصل بـ AS203592، فإن الخدمة تعتمد على طاقة الرف والتبريد والتوصيلات المتقاطعة العلوية والمحولات وأجهزة التوجيه وشبكات التخزين ووصول الموظفين. تسرد منشأة PeeringDB لـ IBH Dresden C2 diverse serving substations=true، وهو دليل إيجابي على مستوى المنشأة. لا يزال لا يكشف عن تصميم طاقة الرف لـ CLOUD & HEAT أو تغطية الكابل المزدوج أو تجاوز الصيانة أو وقت تشغيل البطارية أو تاريخ اختبار المولد أو ما إذا كان يمكن نقل جهاز افتراضي معين بعيدًا عن المنشأة المتأثرة أثناء حادث محلي.

يساعد اتصال DD-IX في تبادل حركة المرور المحلية، لكن انقطاع التبادل وانقطاع مركز البيانات حدثان مختلفان.

فشل الدعم مهم بنفس القدر. تعطي صفحة Kubernetes المُدارة مستوى دعم 9/5 مع وقت استجابة أربع ساعات للمستوى الأساسي ومراقبة وتنبيه على مدار الساعة طوال أيام الأسبوع للخدمة الكاملة. تقدم صفحة 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، وخوادم أسماء INWX وسجلات SPF التي تتضمن مضيف البريد وGoogle. يشير هذا إلى أن الموقع العام يُقدم من مساحة التوجيه الخاصة بالشركة بدلاً من شبكة توصيل محتوى كبيرة تابعة لجهة خارجية. هذا إيجابي لهوية الشبكة، لكنه يعني أيضًا أن الموقع العام للشركة يمكن أن يتأثر بـ AS الخاص بها أو مضيف الويب أو تبعيات المنشأة.

مسار تأثير العميل يتبع مكدس المنتج. يمكن أن يؤثر فشل الشبكة على قابلية الوصول إلى السحابة العامة وواجهات برمجة تطبيقات Kubernetes المُدارة وموازنات التحميل ومدخل العميل ونقاط نهاية توزيع البرامج وربما موقع الشركة الإلكتروني أو أسطح الدعم. يمكن أن يؤثر فشل التخزين على الأحجام والتخزين الكائني. يمكن أن يؤثر حادث الطاقة أو التبريد على برامج المراقبة وآلات 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. كل هذا مرتبط بموضوع سيادة البيانات والمحلية.

لكن لا ينبغي الخلط بين المحلية والاسترداد. يمكن للعميل أن يعرف أن البيانات في ألمانيا وما زال لا يعرف ما إذا كانت منسوخة بين دريسدن ولايبزيغ، أو بين غرفتين في دريسدن، أو عبر منطقتي توفر في مبنى واحد، أو داخل مجموعة تخزين واحدة مع مجالات فشل. تقول صفحة 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. تصف الوصول إلى API عبر VPN وأحجام Cinder الثابتة من OpenStack وموازنات التحميل والمراقبة وingress وCertmanager والنشر متعدد المناطق. إذا فشلت طبقة السحابة للمزود، قد يعيد Kubernetes جدولة القرون لكنه لا يزال يفقد الأحجام أو الدخول أو قابلية الوصول الخارجي. إذا فشلت طائرة التحكم أو مسار 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 لأن مسار الاتصال المحلي جزء من قصة الأداء.

المجموعة الخامسة هي الوجود العام للمزود. وضع DNSwww.cloudandheat.comداخل 185.128.116.0/22. إذا كانت نفس الشبكة أو مكدس الاستضافة يدعم الموقع العام للشركة، فقد يؤدي حادث البنية التحتية إلى جعل صفحات المنتج وبعض نقاط دخول العملاء غير متوفرة في اللحظة التي يحتاج فيها العملاء إلى المعلومات. لا يثبت دليل DNS العام أن نظام تذاكر الدعم موجود على نفس المكدس، ويشمل سجل SPF Google، لذا قد يكون للبريد مسار اعتماد مختلف. مع ذلك، يجب أن تكون الاتصالات العامة جزءًا من العناية الواجبة للعميل: أين صفحة الحالة، وماذا يحدث إذا كان الموقع الرئيسي غير متاح، وأي جهات اتصال طارئة تظل قابلة للوصول؟

لهذا السبب يجب أن تكون لغة المنطقة المتأثرة متحفظة. تصنف المهمة المنطقة على أنها عالمية لأن الخدمات السحابية والمستضافة قابلة للوصول عالميًا وفئة الدليل هي خدمة سحابية عالمية. أقوى منطقة تشغيل في الأدلة العامة هي ألمانيا، وخاصة دريسدن وساكسونيا، مع اتصال DD-IX موثق وادعاءات مركز بيانات ألماني. لا يزال العملاء خارج ألمانيا يمكنهم استخدام الخدمات، لكن الاعتماد المادي ليس عالميًا بالمعنى الواسع. إنها سحابة ألمانية ومزود تقنية سحابية مع قابلية وصول عالمية.

إثبات التكرار جيد على حافة الشبكة وغير كامل على طبقة الخدمة

هناك عدة إشارات تكرار إيجابية. لدى AS203592 أربعة جيران مرصودين في RIPEstat، وليس واحدًا. لديه رؤية توجيه عامة عبر جميع نظائر RIS المرصودة لـ IPv4 وIPv6 في وقت الاستعلام. لديه أصول صالحة لـ RPKI لجميع البادئات الأربعة المرصودة. يُظهر PeeringDB مشاركة خادم التوجيه في DD-IX. تعد صفحة Kubernetes المُدارة بالنشر متعدد مناطق التوفر لتحقيق التوفر العالي. تذكر صفحة IaaS مجموعات Ceph ثلاثية التكرار وخيار NVMe ثلاثي النسخ. تقدم صفحة Patron عقود التشغيل والمراقبة، بما في ذلك خيارات 24/7.

الفجوات مهمة بنفس القدر. لا تكشف رؤية التوجيه العامة عن هندسة حركة المرور. لا يكشف منفذ DD-IX بسرعة 10 جيجابت في الثانية في PeeringDB عن الاستخدام أو تجاوز الفشل. لا تثبت صلاحية RPKI الاستعداد لتغيير المسار. "مناطق توفر متعددة" لا تحدد فصل نصف قطر الانفجار. "Ceph ثلاثي التكرار" لا يذكر وضع النسخة. "مراقبة 24/7" لا تكشف عن توظيف الاستجابة أو سلطة التصعيد أو أهداف الاستعادة. تظهر شهادات ISO وحالة OpenStack Powered وضع العملية والتقنية، لكنها ليست سجلات حوادث. لا يجب على المشتري ترجمة هذه الادعاءات العامة إلى ضمان توفر عالٍ شامل.

أقوى دليل تكرار عملي يمكن أن يطلبه المشتري ليس كتيبًا. إنه تشغيل استرداد تم اختباره: خذ جهازًا افتراضيًا وحجمًا ومجموعة كائنات وحمل عمل Kubernetes وقاعدة بيانات ممثلين؛ قم بمحاكاة فشل منطقة؛ قياس وقت الاستعادة؛ اختبار تغيير DNS؛ تصدير الصور والأحجام؛ إعادة البناء في مزود ثانٍ أو موقع عميل؛ والتحقق من اتساق مستوى التطبيق. بالنسبة لـ Kubernetes، اسأل كيف تتعافى etcd والأحجام الثابتة ووحدات تحكم الدخول وموازنات التحميل وتبعيات السجل. بالنسبة لـ 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 كمزود سحابي ألماني استراتيجي يجب أن يطلب بيان السعة الحالية، ليس فقط كتالوج الخدمة: وحدة المعالجة المركزية والذاكرة وGPU والتخزين الكتلي والتخزين الكائني والتخزين الاحتياطي وحصة الشبكة المتاحة حسب الموقع أو منطقة التوفر.

يجب أن يسأل عما إذا كان يمكن توفير جهاز افتراضي جديد أثناء حدث تخزين جزئي، وما إذا كان يمكن إعادة بناء مجموعة Kubernetes بدون أسرار يحتفظ بها المزود، وما إذا كان يمكن إعادة تعيين IPs العائمة أثناء صيانة جهاز التوجيه، وما إذا كان يمكن تصدير بيانات الكائنات بدون اختناق، وما إذا كان الدعم يمكنه تنفيذ تغييرات طارئة عندما يكون الموقع العام أو مسار النظير معطلًا. هذه أسئلة عادية للسعة المستضافة الجادة. إنها لا تضعف قصة الشركة؛ إنها تجعل الأدلة العامة القوية قابلة للاستخدام.

للمراقبة، تتبع AS203592 و185.128.116.0/22 و94.198.185.0/24 و2a0c:2c0::/29 و2a0c:2c0:dd80::/44 ومنفذ DD-IX وموقع cloudandheat.com ومسارات الحالة العامة أو الدعم. للشراء، اطلب بيانات المنشأة وتعريفات مناطق التوفر وأدلة تنوع المسار وشروط استجابة الدعم وإثباتات النسخ الاحتياطي والتصدير وخطة ترحيل مختبرة. الشركة لديها بنية تحتية ذات مصداقية. نقطة القرار هي ما إذا كانت الخدمة المحددة التي يشتريها العميل لديها سعة قابلة للاستخدام كافية واسترداد مُجرّب كافٍ للبقاء على قيد الحياة من الإخفاقات المادية التي ستواجهها جميع السعة المستضافة في النهاية.