Physische Entfernung

Wenn eine Anwendung eine Anforderung an COS stellt, muss sie eine gewisse physische Entfernung überschreiten.  Mit zunehmender Entfernung erhöht sich auch die Latenzzeit der Anforderung. Um die Latenzzeit durch die physische Entfernung zu verringern, ist es optimal, Rechenressourcen und Objektspeicher nach Möglichkeit gemeinsam zu lokalisieren. Wenn Ihre Anwendung in der IBM Cloud in der us-south -Region ausgeführt wird, wäre es zur Optimierung der Leistung am besten, Daten aus einem Bucket zu lesen und in ein Bucket zu schreiben, das sich ebenfalls in der us-south -Region befindet.

Workloads, die den Zugriff auf Daten an weit reichenden Stellen erfordern, können von der Verwendung von IBM Asperaprofitieren, insbesondere, wenn ein erheblicher Paketverlust auftritt.  Weitere Informationen zur Verwendung von IBM Aspera High-Speed Transfer und COS finden Sie im Handbuch Aspera .

Anwendungen mit globaler Reichweite profitieren von der Verwendung eines Content Delivery Network zum Zwischenspeichern von Assets, die in COS an Standorten gespeichert sind, die näher an ihren Endbenutzern liegen.  Die ursprünglichen Dateien werden weiterhin in ihrem Bucket gehostet, aber Kopien können an verschiedenen Positionen auf der Welt zwischengespeichert werden, an denen Benutzer Ursprungsanforderungen sind.

Anforderungen an die Ausfallsicherheit

Einige Workloads erfordern möglicherweise die zusätzlichen Ebenen der Ausfallsicherheit, die mit dem Schreiben von Daten in regionsübergreifende Buckets verbunden sind, während andere auf die erhöhte marginale Leistung in einem Single-Data-Center-Bucket angewiesen sind.  Jede Anwendung muss ein Gleichgewicht zwischen höherer Verfügbarkeit und schnellerer Leistung erreichen.

Bei Verwendung eines regionsübergreifenden Endpunkts ist es möglich, eingehenden Datenverkehr an einen bestimmten Zugriffspunkt zu leiten, während die Daten weiterhin über alle drei Regionen verteilt werden. Beim Senden von Anforderungen an einen einzelnen Zugriffspunkt erfolgt keine automatisierte Funktionsübernahme, wenn diese Region nicht mehr verfügbar ist. Anwendungen, die den Datenverkehr an einen Zugriffspunkt anstelle des geo Endpunkts leiten, müssen intern entsprechende Failover-Logik implementieren, um die Verfügbarkeitsvorteile des regionsübergreifenden Speichers zu erreichen.

Ein Grund für die Verwendung eines Zugriffspunkts besteht darin, zu steuern, wo Datenein-und -ausgänge auftreten, während die Daten weiterhin über den größtmöglichen Bereich verteilt werden. Stellen Sie sich eine Anwendung vor, die in der us-south -Region ausgeführt wird und Daten in einem regionsübergreifenden Bucket in den USA speichern, aber sicherstellen möchte, dass alle Lese-und Schreibanforderungen im Bereich Dallas verbleiben:

1. Die Anwendung erstellt einen Client mit dem Endpunkt https://s3.private.dal.us.cloud-object-storage.appdomain.cloud .
2. Der COS-Service in Dallas ist ausgefallen.
3. Die Anwendung erkennt einen persistenten Fehler bei der Verwendung des Zugriffspunkts.
4. Die Anwendung erkennt, dass ein Failover auf einen anderen Zugriffspunkt wie San Jose erforderlich ist.
5. Die Anwendung erstellt einen neuen Client mit dem Endpunkt https://s3.private.sjc.us.cloud-object-storage.appdomain.cloud .
6. Die Konnektivität wird wieder aufgenommen und der Zugriff kann nach der Wiederherstellung des Service an Dallas weitergeleitet werden.

Stellen Sie sich dagegen eine andere Anwendung vor, die den normalen regionsübergreifenden Endpunkt in den USA verwendet:

1. Die Anwendung erstellt einen Client mit dem Endpunkt https://s3.us.cloud-object-storage.appdomain.cloud .
2. Der COS-Service in Dallas ist ausgefallen.
3. Alle COS-Anforderungen werden automatisch an San Jose oder Washington weitergeleitet, bis der Service wiederhergestellt ist.

Netztyp

Datenverkehr, der an COS geleitet wird, kann aus einem von drei Netzen stammen: Public, Private oder Direct. Das Zielnetz wird durch den COS-Serviceendpunkt definiert, der für den Zugriff auf ein Bucket verwendet wird. Während ein Bucket an einem einzelnen Standort erstellt wird (sei es regionsübergreifend, regional oder Single Site), ist es weiterhin möglich, über einen der drei beschriebenen Netztypen auf dasselbe Bucket zuzugreifen.

Öffentlicher Datenverkehr durchläuft das öffentliche Internet, bis er die IBM Cloud erreicht, und wird an eine Lastausgleichsfunktion weitergeleitet, die Datenverkehr an das verteilte COS-Speichernetz weiterleitet. Privater Datenverkehr stammt aus der IBM Cloud und berührt nie das öffentliche Internet.  Der direkte Datenverkehr stammt aus einer Virtual Private Cloud, die sowohl lokale Rechenzentren als auch IBM Cloud -Ressourcen enthalten könnte. Diese Architektur erfordert IBM Direct Linkund ermöglicht es Benutzern, eine direkte Verbindung zum privaten IBM Cloud -Netz über das Rechenzentrum eines Benutzers (über einen Reverse Proxy) herzustellen, ohne das öffentliche Internet zu berühren.

Da das private Netz alle Abweichungen, Engpässe oder Sicherheitslücken im öffentlichen Internet beseitigt, wird empfohlen, dass alle Workloads das private Netz verwenden, wann immer dies möglich ist.