Sihe Cloud Shanghai Technology Co., Ltd. verkauft gehostete Kapazität, die von Racks, Transit und Wartungsfenstern abhängt

Zusammenfassung

• Der APNIC-Eintrag fürAS151217identifiziertSIHE-SHCTals Sihe Cloud Shanghai Technology Co., Ltd. mit Sitz in der 1508 Kunyang Road, Shanghai. Das Unternehmen besitzt auch den portablen IPv4-Bereich160.19.76.0/23und den portablen IPv6-Bereich2401:9e20::/32, beide im Mai 2024 registriert mit entsprechendensihe.ai-Kontakten.
• AS151217 selbst ist nicht öffentlich aktiv.Der Routing-Status von RIPEmeldet keine angekündigten IPv4- oder IPv6-Räume, keine beobachteten Nachbarn und null Sichtbarkeit unter seinen Full-Table-Peers. Die IPv6-Zuteilung des Shanghaier Unternehmens ist ebenfalls ungeroutet.
• Der IPv4-Block ist anders:RIPE sieht160.19.76.0/23bei jedem IPv4-Peer, der zurückreicht, mit Ursprung in AS9808, China Mobile. Die Route ist seit Juni 2024 sichtbar. Dies beweist die öffentliche Erreichbarkeit der Adressressource, nicht einen unabhängigen Netzbetrieb durch AS151217 oder einen bestimmten Rack-Standort.
• Eineaktive Sihe Cloud-Websiteverkauft virtuelle Maschinen, Container, verwaltete Datenbanken, Objektspeicher und Dateispeicher, unterstützt durch eine zugänglicheKonsoleund einDokumentationszentrum. Diese öffentlichen Seiten und dieStandard-Service-Vereinbarungidentifizieren jedoch Haining Sihe Cloud Computing Technology Co., Ltd. als Anbieter. Sie erläutern nicht die Rolle des Shanghaier Unternehmens bei der Erbringung von Einzelhandelsdiensten.
• Die vorsichtige Schlussfolgerung ist daher eng. Sihe Cloud Shanghai Technology Co., Ltd. kontrolliert nachweislich Internet-Nummernressourcen und verfügt über einen über einen großen Betreiber gerouteten IPv4-Block. Öffentliche Belege belegen nicht, dass sie ein Rechenzentrum besitzt, die kundenorientierte Cloud betreibt, eine Multi-Operator-Peripherie kontrolliert, einen Migrationspuffer unterhält oder die Support- und Datenrückgabeverpflichtungen übernimmt, die unter dem Namen Sihe verkauft werden.

Die aktive Route ist die stärkste Tatsache und wirft die schwierigste Frage auf

Kleine Cloud-Unternehmen sind oft leichter über die öffentlichen Internet-Ressourcen zu finden, die an ihre legalen Namen gebunden sind. Dies ist hier der Fall, aber die Einträge ergeben nicht das einfache Bild, das ein Firmenname suggeriert. DerAS151217-Eintragnennt Sihe Cloud Shanghai Technology Co., Ltd., gibt den NetzwerknamenSIHE-SHCTan und lokalisiert den administrativen Kontakt im zweiten Stock des Gebäudes 2, 1508 Kunyang Road, Bezirk Minhang, Shanghai. Die Registrierung erfolgte am 11. Mai 2024. Die administrativen, technischen und Missbrauchskontakte verwenden alle die Domainsihe.ai.

Am selben Datum erhielt das Unternehmen zwei portable Adressressourcen. Die erste,160.19.76.0/23, umfasst 512 IPv4-Adressen. Die zweite,2401:9e20::/32, ist eine IPv6-Zuteilung, die groß genug ist, um eine enorme Anzahl von Kunden-Subnetzen zu unterstützen. Dies sind keine bloßen Verzeichniseinträge. Es sind autoritative Ressourceneinträge, die über APNIC und CNNIC gepflegt werden. Sie belegen, dass das Shanghaier Unternehmen der benannte Inhaber der Ressourcen ist und eine anerkannte operationelle Kontaktfläche für Missbrauch und Netzverwaltung besitzt.

Was sie nicht belegen, ist ebenso wichtig. Eine Büroadresse in einem Internet-Register ist keine Rechenzentrumsadresse. Ein portabler Block offenbart nicht, ob der Inhaber die Router besitzt, einen Rack mietet, einen vom Betreiber verwalteten Ankündigungsdienst nutzt, Adressen an Kunden zuweist, den Platz für eine spätere Bereitstellung reserviert hat oder den täglichen Betrieb an ein anderes Unternehmen delegiert hat. DieRichtlinien zur Ressourcenregistrierung von APNICbesagen, dass eine Organisation für eine ASN berechtigt ist, wenn sie mit einer eindeutigen Routing-Politik multihomed ist oder nachweisen kann, dass sie diese Kriterien kurz nach Erhalt der Nummer erfüllen wird. Den Identifikator zu besitzen, ist daher eine Option und eine Absicht, eine eindeutige Routing-Politik zu betreiben, nicht der Beweis, dass die Option derzeit ausgeübt wird.

Der IPv4-Block des Shanghaier Unternehmens ist dennoch aktiv.Die Netzwerkinformationen von RIPEordnen das gesamte/23AS9808 zu.Die Routing-Status-Ansichtverzeichnet AS9808 als Ursprung, zeigt Sichtbarkeit bei allen 325 verfügbaren IPv4-Peers am Beobachtungspunkt und datiert die erste gesehene Route auf den 7. Juni 2024. DerRouting-Verlaufzeigt wiederholte sichtbare Intervalle unter demselben Ursprung ab Juni 2024. Die Route ist kein vergessener Registereintrag. Sie erreicht die globale Tabelle.

Dies macht die zentrale Frage dringlicher, nicht einfacher. Erhält ein Kunde eine Adresse aus diesem Block, zeigt die öffentliche Route, dass das Netzwerk von China Mobile der für den Rest des Internets sichtbare Ursprung ist. Die Route führt nicht über AS151217. Das Shanghaier Unternehmen mag eine kommerzielle Vereinbarung haben, die ihm legitime und nützliche Kontrolle über Adressierung, Filterung und Kundenvergabe gibt, aber der öffentliche Pfad offenbart die Bedingungen nicht.

Wenn ein Vorfall eine dringende Routenänderung, eine Abhilfemaßnahme oder einen Präfixentzug erfordert, müssen die Kunden wissen, welche Partei diese Änderung vornehmen kann und welche Partei lediglich ein Ticket eröffnet.

AS151217 ist zugewiesen, aber still

Es gibt keine Unklarheit in der aktuellen Collector-Ansicht der eigenen ASN des Shanghaier Unternehmens. DieAS-Übersicht von RIPEmarkiert AS151217 als nicht angekündigt. SeineRouting-Status-Antwortmeldet null IPv4-Präfixe, null IPv6-Präfixe, keine erste gesehene Route, keine letzte gesehene Route und keinen beobachteten Nachbarn. Die Sichtbarkeit ist null unter den 325 IPv4-Peers und 322 IPv6-Peers mit voller Tabelle. DieAntwort der angekündigten Präfixeist leer, und dieNachbarn-Ansichtmeldet keinen linken, rechten, eindeutigen oder unsicheren Nachbarn.

Unabhängige Topologiebelege weisen in dieselbe Richtung. DerAS Rank-Eintrag von CAIDAidentifiziertSIHE-SHCTin China, markiert ihn jedoch als nicht gesehen, ohne Anbieter-, Peer- oder Kundengrad und ohne Adress- oder Präfix-Kegel. DerCIDR-Berichtgibt an, dass die ASN nicht verwendet wird, um ein Präfix in der globalen Tabelle anzukündigen oder als sichtbarer Transit-AS. Eine Abfrage beiPeeringDBgibt kein Netzwerkobjekt zurück. Die Teilnahme an PeeringDB ist freiwillig, daher ist das Fehlen kein Beweis für fehlende Interkonnektion. Zusammen mit den Collector-Daten bietet es jedoch keine Unterstützung für eine öffentliche Peering-Präsenz oder Installation unter AS151217.

Die Stille bedeutet nicht, dass das Unternehmen in jeder Hinsicht inaktiv ist. Es kann vom Anbieter zugewiesene Adressen verwenden, Geräte hinter einem Betreiber platzieren, private Netze betreiben oder eine andere ASN bitten, seinen portablen Raum anzukündigen. Das geroutete/23zeigt, dass die letzte dieser Möglichkeiten nicht theoretisch ist. Die Unterscheidung ist wichtig, da ein von einem Betreiber stammendes Präfix einen voll funktionsfähigen Hosting-Dienst unterstützen kann. Es gibt dem Kunden lediglich ein anderes Kontrollmodell als wenn das Hosting-Unternehmen sichtbar seine eigene Peripherie betreibt und unabhängig beobachtbare Upstream-Beziehungen hat.

Die portable IPv6-Zuteilung ist ebenfalls still.Der Status von RIPE für2401:9e20::/32findet keinen Ursprung, keine spezifischere Route, keine weniger spezifische Route und null Sichtbarkeit unter den verfügbaren IPv6-Peers. Die Zuteilung ist administrativ substantiell, aber operationell von der öffentlichen Tabelle abwesend. Diese Lücke ist wichtig für Kunden, die einen Dual-Stack-Dienst erwarten, da eine IPv6-Ressource auf dem Papier nicht einem gerouteten IPv6-Dienst mit getesteten Kundenvergaben, Filterung, Überwachung und Vorfallreaktion gleichkommt.

Das Sicherheitsbild des Routings ist ebenfalls dünn. DerRPKI-Validator von RIPEgibtunknownfür das Paar AS9808 und160.19.76.0/23zurück, da er keine gültige Route Origin Authorization findet. Unbekannt bedeutet nicht ungültig und ist kein Beweis für Hijacking. Es bedeutet, dass das öffentliche kryptografische System keine positive Autorisierung dafür liefert, dass AS9808 dieses Präfix ankündigen darf. Für einen über einen Dritten gerouteten portablen Block würde eine gültige Autorisierung den beabsichtigten Ursprung expliziter machen und eine Kategorie von Routing-Mehrdeutigkeit reduzieren.

Der Ursprung gehört China Mobile, nicht der ASN des Ressourceninhabers

DerAPNIC-Eintrag für AS9808identifiziertCHINAMOBILE-CNals China Mobile Communications Group Co., Ltd. Dies ist ein großer Betreibernetz mit einer Größe und Routing-Präsenz weit über dem/23des Shanghaier Unternehmens hinaus. Seine Präsenz als Ursprung verleiht dem Block globale Erreichbarkeit und einen Betreiberqualitätspfad zum weiteren Internet. Es sagt einem Kunden nicht, ob das Shanghaier Unternehmen Transit kauft, einen Zugangskreis mietet, Hosting-Kapazität least, ein Adressankündigungsprodukt nutzt oder eine andere Vereinbarung hat.

Dieser Unterschied zwischen Zuteilung und Ursprung ist nicht nur eine Routing-Technizität. Der Ressourceninhaber kann für die Adressvergabe und Missbrauchskontakte verantwortlich sein, während das Ursprungsnetz die für die Welt sichtbare Grenzrichtlinie kontrolliert. Ein Denial-of-Service-Angriff kann Maßnahmen beider Parteien erfordern: Der Dienstanbieter identifiziert das Ziel und die gewünschte Reaktion, während der Betreiber die Filterung oder Bereinigung an einem Punkt anwendet, an dem der Verkehr noch absorbiert werden kann. Ein Route-Leak kann erfordern, dass der Ursprung seine Richtlinie ändert.

Ein geplantes Wartungsfenster bei der Übertragung des Betreibers kann Server trennen, die weiterhin mit Strom versorgt und gesund bleiben. Ein kommerzieller Streit über die Schaltung kann eine gültige Adresszuteilung unzugänglich machen.

Die öffentliche Route offenbart auch nur einen einzelnen Ursprung, keine Diversität. Ein Multi-Operator-Dienst kann ein Präfix immer noch über eine einzelne ASN ankündigen, während er andere Betreiber auf eine Weise nutzt, die Collectoren nicht offenlegen, aber es gibt keine öffentliche Grundlage, dies hier anzunehmen. AS151217 hat keinen sichtbaren Nachbarn. Das/23hat einen einzigen sichtbaren Ursprung. Das Fehlen einesPeeringDB-Netzwerkeintragshinterlässt keine freiwillige Liste von Austauschpunkten, Einrichtungen oder Interkonnektionspolitik. Ein Käufer müsste daher die Betreiberdiversität als unbeantwortete technische Frage behandeln, anstatt sie aus der Existenz einer ASN oder allgemeinen Aussagen auf einer verlinkten kommerziellen Website abzuleiten.

Die physische Übertragung ist ebenso wichtig wie die logische Route. Zwei Verträge mit unterschiedlichen Betreibernamen können immer noch einen einzelnen Gebäudeeingang, einen einzelnen Glasfaserpfad, einen einzelnen Aggregationsrouter oder eine einzelne städtische Leitung gemeinsam nutzen. Umgekehrt kann ein Betreiber manchmal wirklich diversifizierte Pfade bereitstellen. Der Nachweis der Resilienz erfordert Routing-Schemata, Schaltungs-IDs, Eingangspfade, Demarkationspunkte, Wartungsverantwortung und die Ergebnisse von Ausfalltests. Eine Liste von Logos kann diese Arbeit nicht leisten.

Die öffentlichen Daten für das Shanghaier Unternehmen geben nicht einmal die Einrichtung preis, in der der geroutete Block endet, daher ist die erste Aufgabe, den Standort zu ermitteln, bevor die Diversität darin bewertet wird.

Der bestellbare Sihe-Dienst verweist auf ein anderes Vertragsunternehmen

Es gibt einen funktionierenden kommerziellen Dienst unter dem Namen Sihe. DieStartseite von Sihe Cloudbewirbt elastische virtuelle Maschinen, Container-Computing, verwaltete relationale Datenbanken, Lastenausgleich, Objektspeicher, Dateispeicher und Schutz vor verteilten Denial-of-Service-Angriffen. Sie verlinkt auf einezugängliche Verwaltungskonsole, in der sich ein Benutzer registrieren kann, und auf einDokumentationszentrummit Produktanweisungen, Preisseiten und Servicebedingungen. Dies sind stärkere operationelle Signale als eine ruhende Unternehmenswebsite oder ein bloßer Registereintrag. Sie zeigen eine gepflegte Kundenoberfläche mit Produkten, die detailliert genug beschrieben sind, um eine tatsächliche Nutzung zu unterstützen.

Aber der legale Name auf diesem Dienst ist nicht Sihe Cloud Shanghai Technology Co., Ltd. Die Metadaten der Startseite, die Unternehmensbeschreibung und die Fußzeile identifizieren Haining Sihe Cloud Computing Technology Co., Ltd. DieÜber-Seitegibt an, dass dieses Haininger Unternehmen 2018 gegründet wurde, und beschreibt Cloud Computing, Gerätedesign und -herstellung sowie IDC-Bau und -Betrieb. Sie gibt eine Kundendienstnummer und eine Adresse in der 180 Canghai Road, Haining, Zhejiang. Die Fußzeile der Dokumentation nennt ebenfalls Haining Sihe und zeigt ein ICP-Filing aus Zhejiang und eine Lizenznummer für Mehrwertdienste.

DasStandard-Service-Rahmenwerk und SLAist expliziter. Es besagt, dass Haining Sihe Cloud Computing Technology Co., Ltd. mit dem Benutzer kontrahiert, um die Sihe Cloud-Computing-Plattform bereitzustellen. Es nennt die 180 Canghai Road, Haining, als Erfüllungsort. Es verspricht einen 24/7-Betriebsdienst, eine monatliche Verfügbarkeit von mindestens 99,9 % und den Beginn einer Antwort innerhalb von 30 Minuten nach einem technischen Problem. Es definiert auch Ausschlüsse, Zahlungsverpflichtungen, Aussetzungsrechte, Kündigungsbedingungen und die Rückgewinnung von Ressourcen.

Keine dieser Seiten schreibt dem Shanghaier Unternehmen eine Rolle zu. Die gemeinsamensihe.ai-Kontakte, derselbe Name Sihe und die offensichtliche geschäftliche Nähe können auf eine gemeinsame Organisation oder Zusammenarbeit hindeuten. Sie können für sich genommen Eigentum, Tochtergesellschaft, Mandat, Unterauftrag oder gemeinsame Verantwortung nicht belegen. Der öffentliche Vertrag erlaubt es dem Dienstanbieter, Rechte oder Pflichten unter bestimmten Umständen zu übertragen, aber er identifiziert das Shanghaier Unternehmen nicht als die Partei, die den gerouteten Block, die Racks oder den technischen Support betreibt.

Diese Grenze muss intakt bleiben. Das Shanghaier Unternehmen kann als Inhaber von AS151217 und der beiden portablen Zuteilungen beschrieben werden, weil das Register es sagt. Das Haininger Unternehmen kann als öffentlicher Anbieter beschrieben werden, weil die Website und die Bedingungen es sagen. Der IPv4-Block kann als von China Mobile stammend beschrieben werden, weil die Route es sagt. Diese drei Fakten zu einer einzigen unternehmerischen und operationellen Kette zu verbinden, erfordert eine Vereinbarung, einen Eigentumsnachweis oder eine technische Offenlegung aus erster Hand, die nicht öffentlich ist.

Die Website ist über eine vierte Netzoberfläche erreichbar

Der sichtbare Webdienst verwendet derzeit nicht den portablen IPv4-Block des Shanghaier Unternehmens. Das öffentliche DNS fürdie Startseite,die Konsoleunddie Dokumentationsseiteführt über Deyang benannte Hosts bei Sihe zu222.213.119.154. DieNetzwerkinformationen von RIPEordnen diese Adresse in222.208.0.0/13mit Ursprung AS4134 zu. DerAPNIC-Adresseintragidentifiziert das abdeckende Netzwerk alsCHINANET-SC, das Sichuan-Netzwerk von China Telecom.

Dies ist eine Momentaufnahme der Dienstperipherie, keine Karte der Anwendungs- oder Speicherinfrastruktur. Ein DNS-Label, das Deyang enthält, kann eine Namenskonvention eines Betreibers widerspiegeln; es beweist nicht das Gebäude, in dem sich jeder Server befindet. Eine Ursprungs-ASN identifiziert das Netzwerk, das den Endpunkt ankündigt, nicht den Eigentümer des dahinter liegenden Servers. Ein Web-Frontend kann auch von den Rechen- und Speicherregionen getrennt sein. Die Beobachtung bleibt nützlich, da sie zeigt, dass die sichtbarsten Sihe-Kundenoberflächen nicht über AS151217 oder das160.19.76.0/23des Shanghaier Unternehmens erreicht werden.

Kunden sollten daher vermeiden, die Route der Website als Beweis für die Platzierung ihrer Arbeitslast zu verwenden. Die öffentliche Peripherie könnte ein Load-Balancer, ein Reverse-Proxy, ein Objektspeicher-Website-Endpunkt oder ein kombinierter Diensthost sein. Die Konsole könnte Maschinen anderswo steuern. Die Dokumentation könnte unabhängig von der Produktion bereitgestellt werden.

Um eine Arbeitslast zu lokalisieren, sind die relevanten Belege die zugewiesene Instanzadresse, der Speicherendpunkt, Traceroutes von nützlichen Zugangsnetzen, die vertragliche Region, die Offenlegung der Einrichtung und die Datenlokalisierungszusagen des Anbieters.

Die Trennung erzeugt auch ein Ausfallmuster, das leicht übersehen wird. Die Website und die Konsole können ausfallen, während die Kundengeräte erreichbar bleiben. Die Kundengeräte können ausfallen, während die Konsole gesund erscheint. Die Dokumentation kann während eines Control-Plane-Ausfalls online bleiben. Das vom Betreiber stammende/23des Shanghaier Unternehmens kann sichtbar bleiben, während ein dahinter liegender Rack die Stromversorgung verliert, oder zurückgezogen werden, während jeder Server weiterhin mit Strom versorgt wird. Ein glaubwürdiges Statusmodell benötigt separate Prüfungen für den Kontozugriff, Steuerungsoperationen, Rechenzugänglichkeit, Speicheroperationen, DNS, jedes öffentliche Präfix und jede angekündigte Zone.

Ein Produktkatalog beschreibt Verpflichtungen, nicht die installierte Kapazität

DieECS-Dokumentationbeschreibt virtuelle Maschinen, die nach CPU, Speicher und Festplatte konfiguriert, über mehrere Netzwerkprotokolle bereitgestellt, in der Konsole überwacht und bei Nachfrageänderungen skaliert werden können. Sie gibt auch an, dass die Plattform bei Ausfall eines physischen Hosts virtuelle Maschinen automatisch auf eine gesunde Maschine migriert, während sie Kunden rät, ihre Dienste für den automatischen Start zu konfigurieren. Dies ist ein konkretes operationelles Versprechen. Es impliziert einen Planer, einen gemeinsamen Speicher oder eine funktionierende Festplattenmigrationsmethode, eine Host-Reservekapazität, Gesundheitserkennung und einen Zielhost, der mit der ausgefallenen Arbeitslast kompatibel ist.

DieRDS-Dokumentationgeht bei der verwalteten Verantwortung weiter. Sie besagt, dass der Anbieter die Infrastruktur, Verfügbarkeit, Sicherung und Wiederherstellung, Upgrades und Migration bei Ausfall verwaltet und Einzelknoten- und Mehrknoten-Datenbankmodelle anbietet. Ein Kunde, der diese Beschreibung liest, mietet nicht einfach nur CPU-Zeit. Der Kunde verlässt sich auf ein Betriebsteam, um einen Host-Ausfall von einem Datenbankausfall zu unterscheiden, Backups ausreichend getrennt zu halten, um den relevanten Ausfall zu überstehen, Wiederherstellungen zu testen und die Konsistenz beim Failover zu bewahren.

Die Speicherprodukte multiplizieren diese Abhängigkeiten. DieObjektspeicher-Seitebeansprucht verteilten Speicher, automatische Kopien auf verschiedenen Geräten und Rechenzentren, hohe Verfügbarkeit, automatische Skalierung und Zugriff über eine weit verbreitete Objektschnittstelle. DasS3-Befehlszeilen-Tutorialzeigt einen Exportpfad unter Verwendung von S3-kompatiblen Tools und Zugangsdaten. DieNAS-Seitebeschreibt redundante Cloud-Festplatten, Multi-Instance-Mounting und gemeinsamen Dateizugriff.

Diese Seiten etablieren eine verkaufbare Produktoberfläche. Sie zählen nicht die physischen Hosts, Festplatten, Ports, Racks, den Stromverbrauch oder die ungenutzte Failover-Reserve dahinter auf. Sie identifizieren nicht, welche Produkte den portablen Block des Shanghaier Unternehmens verwenden. Sie zeigen nicht, ob Objektkopien unabhängige Gebäude, unabhängige Brandschutzbereiche oder einfach nur verschiedene Geräte im selben Raum belegen. Sie liefern keine kundenspezifischen Recovery-Point- oder Recovery-Time-Zusagen.

Der Unterschied zwischen einer dokumentierten Funktion und der installierten Kapazität ist der Ort, an dem sich das Cloud-Risiko normalerweise verbirgt.

DieECS-Preisseitebepreist CPU, Speicher, Festplatte und ausgehenden Verkehr als separate Verbrauchseinheiten und gibt an, dass der Konsolenpreis maßgeblich ist. Dies ist wirtschaftlich für einen Käufer verständlich, aber jede Einheit entspricht einer endlichen Infrastruktur. Eine virtuelle CPU ist ein Anteil einer Host-CPU. Ein Gigabyte Speicher muss in einem Server installiert sein. Eine Festplattenzuteilung verbraucht Medien, Controller, Replikationsverkehr und einen Ersatzbestand. Die ausgehende Übertragung verbraucht eine Betreiberzusage und möglicherweise einen überlasteten Port. Der Detailzähler offenbart nicht die Einkaufsverpflichtung des Anbieters oder die verfügbare Reserve bei einem Ausfall.

Installierte, verkaufbare und wiederherstellbare Kapazität sind unterschiedliche Größen

Ein Cloud-Betreiber kann einen breiten Katalog ankündigen, während er in der genauen Fehlerdomäne, die zählt, wenig Reservekapazität hat. Kapazität durchläuft mehrere Phasen. Ein Standort kann geplant, gebaut und mit Strom versorgt sein. Racks können installiert, aber leer sein. Server können installiert, aber auf Netzwerk- oder Speicherinbetriebnahme warten. Hosts können in Betrieb genommen, aber bereits zugewiesen sein. Ressourcen können technisch frei, aber für Wartung, Replikation oder Fehlerbehebung reserviert sein. Nur der Rest ist sicher verkaufbar.

Die Sihe-Startseite beansprucht drei Maschinenräume oder Verfügbarkeitszonen mit unabhängiger Kühlung und Netzwerk, doppelter Stromversorgung von zwei Umspannwerken, mehrleitigem Netzwerkzugang, N+1-Kühlung, einem eigenen Photovoltaik-Kraftwerk, 20 Gb öffentlicher Bandbreite und einem internen Netzwerk von 50 GbE oder 400 GbE. Dies sind bedeutende Behauptungen, da sie physische und logische Designentscheidungen beschreiben. Sie werden nicht von Einrichtungsnamen, Standortadressen, einpoligen Stromlaufplänen, Betreiberschaltungsdetails, in Betrieb genommener Last, Nutzung, Prüfberichten oder Failover-Tests begleitet.

Die Behauptungen müssen daher als Darstellungen des Anbieters gelesen werden, nicht als Maße der aktuell für Kunden verfügbaren Kapazität.

Das Wort „drei“ ist besonders leicht überzuinterpretieren. Drei Räume im selben Gebäude bieten nicht denselben Schutz wie drei Standorte auf separaten Versorgungssystemen, Hochwasser-, Brand- und Betreibernetzen. Drei logische Zonen können sich immer noch ein Control Plane oder eine Speicherstruktur teilen. Unabhängige Kühlung innerhalb der Räume kann immer noch von einem einzigen Wasser- oder Stromsystem des Gebäudes abhängen. Zwei Stromversorgungen können trotz einer Designabsicht, sie zu trennen, auf dasselbe Umspannwerk, dieselbe Schalttafel oder denselben Transformator konvergieren.

Eine Solaranlage kann die Energiekosten senken, ohne die Serverlast während eines Netzausfalls aufrechtzuerhalten. Jede Behauptung benötigt eine Karte der Fehlerdomänen.

Für das Shanghaier Unternehmen kommt zuerst die Standortlücke. Seine Registeradresse in der Kunyang Road ist eine administrative Kontaktadresse und sollte nicht als Rack-Standort beworben werden. Die Haininger Servicevereinbarung gibt einen Vertragserfüllungsort, aber keine Liste von Rechenzentren. Die Web-Peripherie nutzt den Adressraum von Sichuan und Deyang-Labels, aber das lokalisiert nicht die gesamte Cloud. Das Shanghaier/23stammt von China Mobile, aber eine Betreiberherkunft gibt nicht preis, welche Stadt oder welches Gebäude die Endgeräte enthält. Die öffentlichen Belege unterstützen daher eine Dienstzone in China, aber keine genaue Karte der installierten Anlagen.

Diese Unsicherheit verändert den Einkauf. Ein Käufer kann das korrelierte Risiko zwischen Rechnen, Datenbank und Objektspeicher nicht berechnen, solange er nicht weiß, ob sich ihre primären und Wiederherstellungskopien einen Standort teilen. Er kann die Stromversorgungskontinuität nicht bewerten, ohne den vertraglichen Rack und den Strompfad zu kennen. Er kann die Betreiberdiversität nicht beurteilen, ohne die Schaltungen und Eingänge zu sehen. Er kann den Hardware-Ersatz nicht bewerten, ohne den Anlagentyp und den lokalen Ersatzteilbestand zu kennen.

In einer kleinen Cloud kann eine moderate Anzahl ungenutzter Hosts oder Festplatten den Unterschied zwischen einer schnellen Migration und einer verlängerten Warteschlange ausmachen.

Der Fehlerbaum beginnt unter der virtuellen Maschine

Ein Kunde sieht eine Instanz, eine Adresse und einen Konsolenknopf. Der Dienstanbieter sieht eine Abhängigkeitskette. Ganz unten steht die Einrichtung: Stromeingang, Schaltanlage, unterbrechungsfreie Stromversorgung, Batterien, Generatoren, Kühlung, Brandschutzsysteme, physische Sicherheit und Wartungspersonal. Darüber liegen Racks, Stromverteilungseinheiten, Top-of-Rack-Switches, Server-Netzteile, Prozessoren, Arbeitsspeicher, lokale Datenträger, Speichernetzwerke und Verwaltungscontroller. Darüber liegen der Hypervisor, der Planer, das virtuelle Netzwerk, der Bilddienst, das Identitätssystem, das Abrechnungssystem und die Kundenkonsole.

Ein Ausfall auf jeder Ebene kann ein ähnliches Kundensymptom erzeugen. Eine tote virtuelle Maschine kann ein Problem des Gastbetriebssystems, ein erschöpfter Host, eine ausgefallene Festplatte, ein Switch-Ausfall, eine Speicherunterbrechung, ein Rack-Stromereignis oder eine Kontosperrung sein. Die Route kann während der meisten dieser Ausfälle sichtbar bleiben. Umgekehrt kann ein Router-Ausfall eine gesunde Maschine von außen als tot erscheinen lassen. Die Diagnose hängt daher von der Beobachtbarkeit auf jeder Ebene und einem Support-Team ab, das befugt ist, organisatorische Grenzen zu überschreiten.

Die Shanghaier Route fügt diesem Baum eine Betreiberabhängigkeit hinzu. AS9808 ist der öffentliche Ursprung für160.19.76.0/23. Wenn ein Kunde in diesem Block seine Konnektivität verliert, muss die Hosting-Seite entscheiden, ob der Ausfall innerhalb des virtuellen Netzwerks, am serverorientierten Switch, bei der Betreiberübertragung, im Betreiber-Backbone, in der Routenverbreitung oder in einem entfernten Zugangsnetz liegt. Wenn das Unternehmen die Ursprungsrouter nicht direkt kontrolliert, wird die Qualität der Eskalation zu einem Teil der Dienstqualität. Die praktischen Fragen sind, wer das Betreiberkonto hält, welche Priorität die Schaltung erhält, ob Ingenieure das Netzbetriebszentrum direkt anrufen können und ob dringende Routenänderungen eine geschäftliche Genehmigung erfordern.

Der Hardware-Bestand erzeugt einen weiteren Zweig. Das ECS-Versprechen der automatischen Migration setzt einen gesunden Zielort mit ausreichender CPU-, Speicher- und Festplattenkapazität voraus. Wenn mehrere Hosts einen Strom- oder Kühlungsausfall teilen, muss die Plattform mehr als eine Maschine auf einmal absorbieren. Wenn der Quellspeicher beschädigt oder isoliert ist, ist eine Live-Migration möglicherweise nicht möglich. Wenn der Zielort eine andere Prozessorgeneration oder ein anderes Geräteprofil hat, können einige Arbeitslasten möglicherweise nicht sauber starten.

Ein Anbieter kann die normale Verkaufsnachfrage bedienen, während ihm die konzentrierte Reserve fehlt, die während eines Standortereignisses benötigt wird.

Die Reparaturzeit ist nicht nur die Zeit, die benötigt wird, um ein Teil zu ersetzen. Sie umfasst Erkennung, Zugriffsgenehmigung, Anreise des Technikers, Fehlerisolierung, Identifizierung des Ersatzteils, Änderungsgenehmigung, physische Arbeit, Firmware oder Konfiguration, Datenwiederherstellung, Validierung und Wiederinbetriebnahme. Ein vierstündiger Hardwareaustausch kann zu einem viel längeren Kundenereignis werden, wenn das richtige Netzteil oder die richtige Festplatte nicht vor Ort ist. Die öffentlichen Daten geben den Bestand, das Personal vor Ort, die Ersatzteilpolitik oder die Zugangsvereinbarung von Sihe Cloud Shanghai nicht preis.

Diese Auslassungen sind kein Beweis für schlechte Praxis. Sie sind Grenzen dessen, was ein Kunde mit Vertrauen annehmen kann.

Redundanzbehauptungen müssen Tests auf gemeinsame Ursache überstehen

Die Behauptungen der Startseite zu drei Zonen, doppelter Stromversorgung, mehreren Leitungen und N+1 beschreiben die richtigen Resilienzkategorien. Der Test ist, ob sie eine gemeinsame Ursache ausschließen. Zwei Stromversorgungen sind nur nützlich, wenn ein einzelner Schutzschalter, automatischer Umschalter, Kabelweg oder Wartungsvorgang nicht beide außer Betrieb setzen kann. Zwei Betreiber sind nur nützlich, wenn sie nicht auf demselben Kabelkanal, demselben Eingang, demselben optischen Verteiler oder demselben vorgelagerten Backbone konvergieren.

N+1-Kühlung ist nur unter Auslegungslast nützlich und nur, wenn Strom, Steuerung und Wärmeabfuhr verfügbar bleiben.

Die Routing-Belege zeigen derzeit keine Multi-Operator-Peripherie für das Shanghaier Unternehmen. AS151217 ist still und hat keine beobachteten Nachbarn. Sein IPv4-Block hat einen einzigen Ursprung, AS9808. Sein IPv6-Block ist nicht geroutet. Dies widerlegt keinen zweiten Zugangsdienst, keine private Interkonnektion oder keinen Backup-Kreis. Es bedeutet, dass der Kunde die Diversität nicht überprüfen kann, indem er die öffentliche Route inspiziert. Der Anbieter müsste sie offenlegen oder auf einer anderen Ebene demonstrieren.

Der nützlichste Beleg wäre eine Standort-und-Schaltungs-Matrix. Für jede angekündigte Zone würde sie den Einrichtungsbetreiber, die Stadt, den Raum, die Stromversorgung, die Kühlgrenze, den Betreiber, die Schaltungsübertragung, die externe Herkunft, den internen Backbone-Pfad, die Speicherreplikation und die Abhängigkeit des Control Plane nennen. Sie würde aktive Aktiv-Kapazität von einer Kalt-Reserve oder einer kapazitätsbeschränkten Reserve unterscheiden. Sie würde angeben, ob das Shanghaier/23für Kundeninstanzen, Infrastrukturdienste, zukünftige Kapazität oder einen anderen Zweck verwendet wird. Sie würde auch angeben, ob das Failover dieselbe Kundenadresse beibehält oder DNS- und Adressänderungen erfordert.

Tests sind wichtiger als Diagramme. Ein kontrollierter Routenentzug kann zeigen, ob ein Backup-Pfad tatsächlich Verkehr transportiert. Eine Host-Evakuierung kann zeigen, ob ein Migrationspuffer existiert. Eine Wiederherstellungsübung kann zeigen, ob Backups lesbar sind und ob Anmeldeinformationen einen Control-Plane-Vorfall überleben. Ein Stromübertragungstest kann zeigen, ob der Rack mit Strom versorgt bleibt. Eine Support-Übung kann zeigen, ob die richtigen Personen innerhalb der versprochenen Zeit antworten. Ohne Ergebnisse bleibt Redundanz eine Designabsicht.

DieBGP-Spezifikationerklärt, wie Netzwerke Erreichbarkeit und AS-Pfade austauschen, während dieBetriebshinweise der RFC 7454Filterung, Sitzungsschutz und Kontrollen wie maximale Präfixgrenzen abdecken. Diese Praktiken reduzieren das Routing-Risiko, können aber nicht aus einer eingetragenen ASN abgeleitet werden. Die Stille von AS151217 bedeutet, dass es keinen öffentlich sichtbaren Betrieb gibt, an dem sie gemessen werden könnten. Für das aktive/23ist die relevante Richtlinie hauptsächlich die Richtlinie der Ursprungs-AS9808 und die kommerzielle Vereinbarung, die sie autorisiert und regelt.

Wiederherstellung ist ein Kapazitätsproblem, bevor sie eine Softwarefunktion ist

Die Produktseiten machen mehrere Wiederherstellungsbehauptungen: ECS-Host-Migration, Datenbanksicherung und -Migration bei Ausfall, Objektkopien auf verschiedenen Geräten und Rechenzentren, redundanter Dateispeicher, Snapshots und Images. Jede kann wertvoll sein. Keine entbindet von der Notwendigkeit zu fragen, wie viel Kapazität reserviert ist, wo sich die Kopien befinden und wie sich die Wiederherstellung unter Stress verhält.

Bei virtuellen Maschinen sollte eine Migrationsfunktion in geplante und ungeplante Fälle unterteilt werden. Die geplante Evakuierung kann Arbeitslasten verschieben, während der Quell-Host gesund bleibt. Ein plötzlicher Host-Ausfall kann erfordern, eine virtuelle Maschine anderswo von einem gemeinsam genutzten Speicher oder einer replizierten Festplatte aus neu zu starten. Dies erzeugt Ausfallzeiten, selbst wenn die Verschiebung als automatisch bezeichnet wird. Die Wiederherstellungszeit des Kunden hängt dann von der Fehlererkennung, der Planerkapazität, der Festplattenverfügbarkeit, dem Startverhalten und der Anwendungswiederherstellung ab.

Die ECS-Anweisung, den automatischen Start zu konfigurieren, ist ein nützlicher Hinweis darauf, dass die Kundenkonfiguration weiterhin Teil der Kontinuität ist.

Bei Datenbanken sind die wesentlichen Metriken der Wiederherstellungspunkt und die Wiederherstellungszeit. Eine Mehrknotenkonfiguration kann die Unterbrechung reduzieren, wenn die Replikate auf dem neuesten Stand sind und der Failover-Mechanismus einen sicheren Primärserver etablieren kann. Backups schützen vor einer anderen Klasse von Problemen, einschließlich versehentlichem Löschen oder Beschädigung, jedoch nur, wenn sie alt genug sind, um dem Schaden vorauszugehen, und ausreichend getrennt, um den Ausfall zu überstehen. Die öffentliche RDS-Seite beschreibt Hochverfügbarkeit und Backup in allgemeinen Begriffen.

Sie veröffentlicht keine kundenspezifische Topologie, keinen Aufbewahrungszeitplan, kein Ergebnis eines Wiederherstellungstests und keine Garantie für eine der beiden Metriken.

Bei Objektspeicher ist der S3-kompatible Zugang eine vielversprechende Portabilitätsfunktion. Die dokumentiertes3cmd-Methodebedeutet, dass Kunden vertraute Tools anstelle einer rein proprietären Schnittstelle verwenden können. Aber eine Schnittstelle ist kein Ausstiegsplan. Große Exporte hängen vom Auflistungsverhalten, der Objektanzahl, der Metadatenkompatibilität, Anmeldeinformationen, ausgehender Bandbreite, Drosselung und Gebühren ab. Ein Kunde, der theoretisch Hunderte von Terabytes kopieren kann, benötigt möglicherweise dennoch Wochen, dies über eine begrenzte Leitung zu tun.

Bei Dateispeicher kann die Anwendungskonsistenz schwieriger sein als das Kopieren von Blöcken. Eine offene Datenbank oder ein aktives gemeinsames Dateisystem können koordinierte Snapshots, Quiescen oder anwendungsebene Backups erfordern. Redundante Festplatten schützen vor einigen Hardwareausfällen, aber nicht unbedingt vor Bedienfehlern, böswilligem Löschen, Kompromittierung von Konten oder einem standortweiten Ereignis. Das richtige Wiederherstellungsdesign umfasst oft eine kontrollierte Kopie unter separaten Anmeldeinformationen und bei kritischen Arbeitslasten außerhalb der Fehlerdomäne des Anbieters.

Ein Kunde sollte eine externe Wiederherstellung testen, bevor er sie benötigt. Exportieren Sie ein repräsentatives VM-Image oder bauen Sie aus der Konfiguration neu auf. Stellen Sie eine Datenbank in einer unabhängig kontrollierten Umgebung wieder her. Kopieren Sie einen signifikanten Objektsatz mit Metadaten und überprüfen Sie Prüfsummen. Erstellen Sie Zugriffskontrollen neu. Messen Sie den Durchsatz zu normalen Zeiten und zu Spitzenzeiten. Notieren Sie, welche Schritte die Sihe-Konsole oder den technischen Support erfordern. Diese Tests verwandeln Portabilität von einer vertraglichen Hoffnung in eine beobachtete Eigenschaft.

Support, Abrechnung und Vertragsstatus können eine gesunde Infrastruktur stoppen

Cloud-Verfügbarkeit ist teilweise administrativ. DieSihe-Servicevereinbarungverspricht 365x24 Betriebssupport und gibt an, dass die Antwort innerhalb von 30 Minuten nach einem technischen Problem beginnt. Sie verspricht keine Lösung innerhalb von 30 Minuten. Dieser Unterschied ist sinnvoll, da die Reparatur vom Ausfall abhängt, aber Käufer sollten ihn in ihren eigenen Erwartungen explizit machen. Sie sollten wissen, welche Kanäle überwacht werden, wie die Schwere zugewiesen wird, wann ein Ingenieur statt des Kundendienstes eingreift und wie ein Betreibervorfall eskaliert wird.

Die Vereinbarung schließt mehrere Arten von Ausfallzeiten von ihrer Verfügbarkeitsberechnung aus, darunter routinemäßige Wartung, vom Benutzer verursachte Ursachen, Ursachen Dritter und höhere Gewalt. Sie gibt dem Dienstanbieter auch das Recht, den Dienst bei ausstehenden Zahlungen, bestimmten schädlichen Nutzungen, behördlichen Anforderungen und anderen Verstößen einzustellen. Im Falle einer Kündigung erlaubt sie dem Anbieter, Kundenressourcen zurückzugewinnen und zuvor vom Kunden genutzte Ressourcen oder Geräte zu entsorgen oder zu bereinigen. Diese Bedingungen machen den Kontostatus und die Zahlung zu einem Teil der Infrastrukturkette.

Diese Kette kann stillschweigend versagen. Eine an eine unbeaufsichtigte Adresse gesendete Zahlungsmitteilung kann zu einer Sperrung führen. Ein ausgeschiedener Mitarbeiter kann die einzigen Administratoranmeldeinformationen besitzen. Die Überprüfung des echten Namens oder behördliche Anfragen können Kontoänderungen blockieren. Eine Missbrauchsmeldung kann eine dringende Filterung auslösen. Eine vertragliche Meinungsverschiedenheit kann einen Export verzögern, während die Maschinen technisch gesund bleiben.

Kunden sollten Abrechnungs-, Sicherheits- und technische Kontakte trennen, gemeinsame Organisationsanmeldeinformationen verwenden, ein externes Asset-Inventar führen und einen Notfall-Datenrückgabepfad definieren, bevor ein Streit entsteht.

Die Grenze zwischen den Entitäten ist auch hier wieder wichtig. Die veröffentlichte Standardvereinbarung nennt Haining Sihe als Anbieter. Der portable IPv4-Block nennt das Shanghaier Unternehmen als Inhaber. AS9808 von China Mobile ist der Ursprung der Route. Wenn eine Kundenadresse in diesem Block gesperrt oder unzugänglich ist, muss bekannt sein, welcher Vertrag die Adresse regelt, welches Unternehmen das Konto kontrolliert, welches Unternehmen mit dem Betreiber spricht und welche Partei den Besitz an den datenhaltenden Geräten hat. Eine gemeinsame Marke ersetzt diese Verantwortungszuweisung nicht.

Die Zahl der monatlichen Verfügbarkeit von 99,9 % muss auch in operationelle Konsequenzen übersetzt werden. In einem Monat mit 30 Tagen entsprechen 0,1 % etwa 43 Minuten. Ausgeschlossene Wartung und Ereignisse Dritter können die vom Kunden erlebte Ausfallzeit erhöhen, ohne die vertragliche Berechnung zu reduzieren. Eine Gutschrift, falls verfügbar, stellt weder verlorene Transaktionen wieder her noch beschädigte Daten. Die nützliche Beschaffungsfrage ist nicht, ob der Prozentsatz vertraut klingt; es ist, ob die Dienstarchitektur, die Ausschlüsse, die Belege und der Wiederherstellungsplan dem tatsächlichen Verlustmodell des Kunden entsprechen.

Datenlokalität ist eine Kette von Kopien und Controllern

Alle identifizierten Unternehmens- und Netzwerkunterlagen befinden sich in China, aber „in China“ ist keine vollständige Datenlokalisierungsantwort. Der Eintrag des Shanghaier Unternehmens zeigt auf Minhang. Die Standard-Servicevereinbarung zeigt auf Haining. Die Peripherie der Website zeigt auf eine China Telecom Sichuan-Adresse und Deyang benannte Hosts. Der IPv4-Block wird von China Mobile getragen, ohne öffentlichen Einrichtungsstandort. Die Produktdokumentation beansprucht Speicherkopien auf mehreren Geräten und Rechenzentren.

Diese Fakten beschreiben mehrere Orte und Rollen, ohne die primären und sekundären Daten eines Kunden abzubilden.

Die Lokalität sollte nach Datentyp dokumentiert werden. Eine virtuelle Maschine hat System- und Datenfestplatten, Snapshots, Images, Protokolle, Konsolenmetadaten und Anmeldeinformationen. Eine verwaltete Datenbank hat Primärdaten, Replikate, Transaktionsprotokolle, Backups und Überwachungsaufzeichnungen. Objektspeicher hat Objekte, Metadaten, Indizes, Zugriffsprotokolle und möglicherweise zwischengespeicherte Kopien. Support-Interaktionen können Kundennamen, Adressen und Systemdetails enthalten. Abrechnung und Überprüfung des echten Namens fügen einen weiteren Satz persönlicher und unternehmerischer Aufzeichnungen hinzu.

Jeder kann einen anderen Controller, eine andere Aufbewahrungsfrist und einen anderen Standort haben.

DasGesetz zum Schutz personenbezogener DatenChinas schafft einen nationalen Rahmen für die Verarbeitung personenbezogener Informationen, und seinegrenzüberschreitenden Bestimmungenstellen Bedingungen, wenn personenbezogene Informationen außerhalb Chinas bereitgestellt werden. Die öffentlichen Belege zeigen nicht, dass das Shanghaier Unternehmen oder der Sihe-Dienst personenbezogene Daten von Kunden ins Ausland übermittelt. Das Gesetz ist hier relevant, da Kunden ihre eigenen Verpflichtungen nicht bewerten können, bis sie wissen, welche juristische Person welche Daten verarbeitet, wohin Kopien gehen und welche Unterauftragnehmer oder Betreiber darauf zugreifen können.

Dieoffizielle chinesische Klassifikation der Telekommunikationsdienstebeschreibt die IDC-Aktivität in physischen Begriffen: Einrichtungen, Platzierung und Wartung von Kundengeräten, gemieteten Servern und Speicher, Kommunikationsleitungen und Bandbreite. Diese Definition ist eine nützliche Korrektur der reibungslosen Cloud-Metapher. Selbst ein virtueller Dienst beruht auf einer lizenzierten und vertraglichen Kombination von Räumen, Hardware, Leitungen und Personen. Die öffentlichen Aussagen, dass das Haininger Unternehmen über relevante Lizenzen verfügt, legen nicht fest, welche Lizenz, Einrichtung oder operationelle Verantwortung dem Shanghaier Ressourceninhaber gehört.

Ein Kunden-Lokalitätsplan sollte daher die vertragsschließende Entität, den Einrichtungsbetreiber, die Stadt, die primäre Region, die Backup-Region, die Support-Zugriffsstandorte, die Netzwerkursprünge und den Exportpfad nennen. Er sollte angeben, ob Kundendaten jemals in den portablen Block des Shanghaier Unternehmens gelangen und ob der Verkehr des Blocks von einer anderen Partei verarbeitet oder protokolliert wird. Er sollte die rechtliche Grundlage und den Genehmigungsprozess für den Remote-Support identifizieren. Er sollte auch definieren, was nach der Kündigung mit Backups, Snapshots und Protokollen geschieht.

Wer ist betroffen, wenn die Kette versagt

Die unmittelbaren Opfer sind nicht auf Infrastrukturteams beschränkt. Ein kleines Unternehmen kann seine öffentliche Website, sein Bestandssystem und seine Personalakten auf einem einzigen Konto betreiben. Ein Softwareunternehmen kann Produktionscontainer, eine verwaltete Datenbank und einen Objektspeicher im selben Dienst platzieren und so eine korrelierte Abhängigkeit zwischen der Anwendung, dem Zustand und den Backups erzeugen. Ein Video- oder Industriesystem kann eine anhaltende Speicher- und Netzwerklast erzeugen, die sich nur schwer schnell verschieben lässt.

Ein einzelner Entwickler kann sich auf eine kostengünstige Instanz verlassen, ohne einen zweiten Anbieter oder lokales Backup.

Jedes Produkt versagt anders. Der Verlust der Betreiberroute trennt jede von außen erreichbare Adresse im betroffenen Block, selbst wenn die Hosts gesund sind. Der Verlust eines Racks oder einer Speicherstruktur kann eine Teilmenge von Instanzen beschädigen, während die Route sichtbar bleibt. Der Verlust des Control Plane blockiert Bereitstellung, Neustart und Änderungen von Anmeldeinformationen. Der Verlust des Objektspeichers kann Anwendungen unterbrechen, die noch funktionierende Rechenleistung haben. Der Verlust von RDS kann Transaktionen stoppen, während statische Seiten online bleiben.

Der Verlust des Abrechnungszugriffs oder eine Kontosperrung kann alle durchdringen.

Der Wirkungsradius hängt davon ab, ob die angekündigten Zonen unabhängig sind und ob Kunden Arbeitslasten bewusst verteilen. Automatische Migration kann einen einzelnen Host-Ausfall reduzieren, aber die Nachfrage auf die verbleibenden Hosts konzentrieren. Eine Mehrknoten-Datenbank kann einen Knoten überleben, aber nicht einen Ausfall des gemeinsam genutzten Speichers oder des Control Plane. Objektreplikation kann eine Festplatte überleben, aber nicht eine Löschung auf Kontenebene, wenn jede Kopie derselben Autorität folgt. Betreiberdiversität kann eine Schaltung schützen, aber nicht einen gemeinsam genutzten Routing-Richtlinienfehler.

Die Architektur muss der Bedrohung entsprechen.

Nachgelagerte Kunden erben auch die Betreibergrenze. Wenn ein Softwareunternehmen einen Dienst über einer von Sihe gehosteten Instanz verkauft, können seine eigenen Benutzer nie erfahren, dass die öffentliche Route von China Mobile stammt, dass der Standardvertrag Haining Sihe nennt oder dass die Adresse auf den Namen des Shanghaier Unternehmens registriert ist. Während eines Ausfalls wird der nachgelagerte Anbieter zum Übersetzer zwischen einer undurchsichtigen Infrastrukturkette und Benutzern, die klare Wiederherstellungsschätzungen benötigen. Aus diesem Grund ist die Beschaffung von kleiner Cloud nicht nur ein Preisvergleich.

Es ist eine Kontinuitätsplanung für alle weiter unten im Stapel.

Die Belege, die die Rolle von Shanghai klären würden

Die erste nützliche Offenlegung wäre eine kurze Erklärung von Sihe Cloud Shanghai Technology Co., Ltd. zu seiner aktuellen Rolle. Betreibt es Netzwerkressourcen für den Haininger Dienst, hält es Adressen im Namen eines verbundenen Unternehmens, stellt es Kapazität in Shanghai bereit, verwaltet es einen Betreibervertrag oder bereitet es zukünftige Infrastruktur vor? Welche Dienste verwenden160.19.76.0/23? Warum ist AS151217 nicht der Ursprung? Ist2401:9e20::/32für eine Bereitstellung vorgesehen? Klare Antworten würden die Fakten des Registers mit einem operationellen Zweck verbinden, ohne die Offenlegung sensibler Kundendetails zu erfordern.

Die zweite wäre ein Nachweis der Routenautorität und Resilienz. Eine gültige Route Origin Authorization für den beabsichtigten Ursprung würde das öffentliche Sicherheitssignal verbessern. Ein Autorisierungsschreiben oder ein gleichwertiger Betreiberdatensatz könnte bestätigen, dass die Ankündigung von AS9808 beabsichtigt ist. Ein Netzwerkdiagramm könnte die Demarkation, den Backup-Pfad, die Filterverantwortung und die Eskalationskette zeigen. Ein Routing-Überwachungsverlauf und ein Ergebnis eines kontrollierten Failovers würden zeigen, dass das Design funktioniert.

Die dritte wäre eine begrenzte Aussage zu Einrichtung und Kapazität. Sie muss nicht die genauen Rack-Koordinaten preisgeben. Sie sollte die Stadt und den Einrichtungsbetreiber für jede angekündigte Zone nennen, zwischen eigenem und gemietetem Raum unterscheiden, die in Betrieb genommene Leistung und die derzeit nutzbare Reserve in breiten Bändern angeben, identifizieren, ob sich Zonen ein Gebäude teilen, und die Anzahl der unabhängigen Betreibereingänge offenlegen. Sie sollte die Auslegungskapazität von der installierten Ausrüstung und die installierte Ausrüstung von der für den Kunden verfügbaren Failover-Kapazität trennen.

Die vierte wären Wiederherstellungsbelege. Veröffentlichen Sie oder stellen Sie unter Vereinbarung die Methode der Host-Evakuierung, die Reservekapazitätspolitik, die Aufbewahrung von Snapshots und Backups, die Datenbank-Wiederherstellungsziele, die Fehlerdomänen der Objektreplikation und die Ergebnisse aktueller Wiederherstellungstests zur Verfügung. Geben Sie Kunden eine gemessene Exportrate und erläutern Sie, ob der Export während der Sperrung oder Kündigung verfügbar bleibt. Geben Sie an, welche Aktionen die Konsole erfordern und welche über einen Notfall-Support-Pfad durchgeführt werden können.

Die fünfte wäre eine Verantwortungsmatrix zwischen dem Shanghaier Unternehmen, dem Haininger Anbieter, dem Betreiber und dem Einrichtungsbetreiber. Für Routing-Vorfälle, Hardware-Austausch, Sicherheitsmeldungen, Abrechnungssperrungen, behördliche Anfragen, Datenrückgabe und Vertragskündigung sollte sie die verantwortliche Partei und den Eskalationspfad nennen. Dieses einzige Dokument würde mehr für das Kundenvertrauen tun als eine lange Liste von Funktionen, da es die Übergänge offenlegt, bei denen normalerweise Zeit verloren geht.

Urteil: Eine geroutete Ressource mit ungelöster Dienstgrenze

Sihe Cloud Shanghai Technology Co., Ltd. ist mehr als ein Name in einer alten Akte. Sie besitzt AS151217, ein portables/23IPv4 und ein portables/32IPv6, alle mit konsistenten Kontakten in Shanghai undsihe.airegistriert. Ihr IPv4-Block ist öffentlich geroutet, weltweit sichtbar und stammt seit Juni 2024 von AS9808 von China Mobile. Dies ist eine greifbare Netzaktivität, die an eine Ressource gebunden ist, die das Unternehmen kontrolliert.

Dieselben Belege hören jedoch auf, bevor sie ein unabhängig betriebenes Shanghaier Netzwerk zeigen. AS151217 kündigt nichts an, hat keine beobachteten Nachbarn und keinen sichtbaren Präfixverlauf. Die IPv6-Zuteilung ist ruhend. Die IPv4-Route verwendet die ASN eines anderen Unternehmens und hat keine gültige Route Origin Authorization in der beobachteten RPKI-Ansicht. Keine öffentliche Einrichtung, kein Rack-Inventar, keine Betreiberübertragung, kein Support-Team und keine Kundenarbeitslast ist speziell mit dem Shanghaier Unternehmen verbunden.

Der aktive Sihe Cloud-Dienst fügt kommerzielle Substanz hinzu, aber keine klare Zuordnung. Seine Website, Konsole, Dokumentation und sein Vertrag belegen, dass Kunden Cloud-Produkte unter dem Namen Sihe kaufen und betreiben können. Sie identifizieren auch Haining Sihe Cloud Computing Technology Co., Ltd. als den öffentlichen Anbieter und verwenden eine kundenorientierte Web-Peripherie im China Telecom Sichuan-Raum. Die öffentlichen Dokumente erklären nicht, wie der Shanghaier Ressourceninhaber teilnimmt.

Die resultierende Beweislage ist schwach für die genaue Entitäts-Infrastruktur-Kette, trotz starker Belege für die einzelnen Register- und Routenfakten. Kunden sollten nicht ableiten, dass das Shanghaier Unternehmen ein Rechenzentrum besitzt, drei unabhängige Standorte betreibt, eine Multi-Operator-Peripherie unterhält oder die Einzelhandels-SLA übernimmt, nur weil sein/23aktiv ist und sein Name die Marke Sihe teilt. Sie sollten fragen, wer den Ursprung kontrolliert, wo die Adressen enden, welches Unternehmen die Racks besitzt oder mietet, wie viel Migrationsreserve existiert, wer die Support-Verpflichtung trägt und wie Daten unter Druck exportiert werden.

Dies ist die physische Bedeutung von gehosteter Kapazität. Eine virtuelle Maschine kann in Minuten bereitgestellt werden, aber ihre Kontinuität hängt immer noch von einem mit Strom versorgten Rack, einem verfügbaren Host, einem funktionierenden Speicherpfad, einem Betreiber ab, der die Route ankündigen will und kann, einem Techniker mit dem richtigen Ersatzteil und einem Vertrag, der Konto- und Exportrechte intakt hält. Für Sihe Cloud Shanghai Technology Co., Ltd. beweist die öffentliche IPv4-Route, dass ein Teil dieser Kette aktiv ist. Sie macht die nicht offengelegten Glieder unmöglich zu ignorieren.