Regionen
Prüfen Sie die IBM Cloud®-Regionen, die Sie zur Verwaltung Ihres Satellite-Standorts auswählen können. Die Hosts, die Sie der Standortsteuerebene Satellite zuordnen möchten, benötigen eine Verbindung mit niedriger Latenzzeit von weniger als oder
gleich 200 Millisekunden (<= 200ms
) (RTT) zur IBM Cloud-Region, von der Ihre Satellite-Position verwaltet wird. Eine steigende Latenz kann sich auf die Leistung auswirken, einschließlich dem Durchsatz des Satellite-Links, der
Bereitstellungszeit für den Satellite-fähigen IBM Cloud-Service, die Wiederherstellungszeit nach einem Hostfehler und in Extremfällen die Verfügbarkeit von Ressourcen, die in der Steuerebene des Satellite-Standorts ausgeführt werden, wie z.
B. Red Hat OpenShift-Cluster-Master. Weitere Informationen finden Sie in Latenz zwischen IBM Cloud und den Hosts der Steuerebene des Satellite-Standorts testen.
Red Hat CoreOS ist an allen unterstützten Satellite-Positionen und für Red Hat OpenShift Version 4.9 und höher verfügbar. Red Hat CoreOS-Hosts unterstützen nicht alle Services. Weitere Informationen finden Sie unter Supported Satellite-enabled IBM Cloud services.
Geografische Region | Land | Metropole mit mehreren Zonen | Standort | Bereich | Zone |
---|---|---|---|---|---|
Asien/Pazifik | Australien | Sydney | syd |
au-syd |
au-syd-1 au-syd-2 au-syd-3 |
Asien/Pazifik | Japan | Tokio | tok |
jp-tok |
jp-tok-1 jp-tok-2 jp-tok-3 |
Asien/Pazifik | Japan | Osaka | osa |
jp-osa |
jp-osa-1 jp-osa-2 jp-osa-3 |
Nordamerika | Kanada | Toronto | tor |
ca-tor |
tor-1 tor-4 tor-5 |
Nordamerika | Vereinigte Staaten | Dallas | dal |
us-south |
us-south-1 us-south-2 us-south-3 |
Nordamerika | Vereinigte Staaten | Washington, D.C. | wdc |
us-east |
us-east-1 us-east-2 us-east-3 |
Europa | Deutschland | Frankfurt † |
fra |
eu-de |
eu-de-1 eu-de-2 eu-de-3 |
Europa | Spanisch | Madrid | mad |
eu-es |
eu-es-1 eu-es-2 eu-es-3 |
Europa | Vereinigtes Königreich | London | lon |
eu-gb |
eu-gb-1 eu-gb-2 eu-gb-3 |
Südamerika | Brasilien | Sao Paulo | sao |
br-sao |
br-sao-1 br-sao-2 br-sao-3 |
†
Cloud-zertifizierte Standorte werden aus der Region Frankfurt verwaltet. Um diese zu bestellen, stellen Sie sicher, dass Sie fra
als Wert für die Option --managed-from
auswählen.
IBM Cloud-Regionen für Satellite-Häufig gestellte Fragen
Prüfen Sie einige der häufig gestellten Fragen dazu, warum und wie Sie eine IBM Cloud-Region zur Verwaltung Ihres Satellite-Standorts auswählen.
Warum wird mein Standort über eine IBM Cloud-Region verwaltet?
Zur Ausführung von IBM Cloud-Services in Ihrer eigenen Infrastruktur ist eine sichere Verbindung zu IBM Cloud erforderlich. Die Verbindung wird von IBM gesteuert, überwacht und verwaltet, um sicherzustellen, dass Sicherheits- und Compliance-Standards für jeden der Services erfüllt werden, und um Aktualisierungen an diesen Services bereitzustellen.
Jeder Satellite-Standort wird mit einer Steuerebene eingerichtet, die die sichere Verbindung wiederum zu IBM Cloud herstellt. Die Steuerebene besteht aus einer hoch verfügbaren Managementebene, die in der von Ihnen ausgewählten IBM Cloud-Region ausgeführt wird. IBM steuert und verwaltet diese Managementebene. Die Steuerebenenknoten werden auf Ihren eigenen Rechenhosts ausgeführt, die Sie an Ihre Satellite-Position angeschlossen haben.
IBM verwendet diese Verbindung, um Ihren Satellite-Standort zu überwachen, Kapazitätsprobleme automatisch zu erkennen und zu beheben, böswillige Aktivitäten zu überwachen und Aktualisierungen an den IBM Cloud-Services, die in Ihrer Infrastruktur ausgeführt werden, bereitzustellen.
Weitere Informationen finden Sie unter Satellite-Architektur.
Welche IBM Cloud-Metropole mit mehreren Zonen wähle ich für meinen Satellite-Standort aus?
Sie können eine der unterstützten IBM Cloud-Regionen für die Verwaltung Ihres Satellite-Standorts auswählen. Die Metropole bestimmt, wo der Masterknoten Ihrer Satellite-Steuerebene ausgeführt wird. Weitere Informationen finden Sie unter Satellite-Architektur. Wählen Sie zur Verringerung der Latenz zwischen der IBM Cloud-Region und Ihrem Satellite-Standort die Region aus, die der Position Ihrer physischen Recheninfrastruktur am nächsten liegt.
Können sich meine Hosts überall aufhalten?
Da Sie die eigene Rechenhostinfrastruktur in Ihren Satellite-Standort einbinden, können Sie diese Infrastruktur wahlweise an jedem gewünschten Ort hosten. Hosts können sich in Ihrem eigenen lokalen Rechenzentrum, in öffentlichen Cloud-Providern oder auf Edge-Computing-Einheiten befinden, wenn diese die Mindestvoraussetzungen für Hosts für Satellite erfüllen.
Wie kann ich an einem Cloud-zertifizierten Standort in der EU implementieren?
Cloud-zertifizierte Standorte werden aus der Region Frankfurt verwaltet. Um diese Typen von Positionen zu bestellen, müssen Sie fra
als Wert für die Option --managed-from
auswählen.
Beispielbefehl:
ibmcloud sat location create --name LOCATION_NAME --coreos-enabled --managed-from fra
oder
ibmcloud sat location create --name LOCATION_NAME --managed-from fra
Welche Latenzanforderungen sind zu beachten?
Berücksichtigen Sie bei der Auswahl Ihres Infrastrukturproviders die folgenden Latenzanforderungen. In Umgebungen, die diese Latenzanforderungen nicht erfüllen, kommt es zu verminderter Leistung.
- Zwischen IBM Cloud und dem Standort
- Die Hosts, die Sie der Standortsteuerebene Satellite zuordnen möchten, benötigen eine Verbindung mit niedriger Latenzzeit von weniger als oder gleich 200 Millisekunden (
<= 200ms
) (RTT) zur IBM Cloud-Region, von der Ihre Satellite-Position verwaltet wird. Eine steigende Latenz kann sich auf die Leistung auswirken, einschließlich dem Durchsatz des Satellite-Links, der Bereitstellungszeit für den Satellite-fähigen IBM Cloud-Service, die Wiederherstellungszeit nach einem Hostfehler und in Extremfällen die Verfügbarkeit von Ressourcen, die in der Steuerebene des Satellite-Standorts ausgeführt werden, wie z. B. Red Hat OpenShift-Cluster-Master. Weitere Informationen finden Sie in Latenz zwischen IBM Cloud und den Hosts der Steuerebene des Satellite-Standorts testen. - Zwischen Hosts an Ihrem Standort
- Ihre Hostinfrastrukturkonfiguration muss eine Verbindung mit niedriger Latenzzeit von maximal 100 Millisekunden (
<= 100ms
) Umlaufzeit (Round Trip Time, RTT) zwischen den Hosts, die für die Satellite-Workerknoten der Positionssteuerebene verwendet werden, und den Hosts, die für andere Ressourcen am Standort verwendet werden, wie z. B. Cluster oder Satellite-enabled IBM Cloud-Service aufweisen. Bei Cloud-Providern wie AWS bedeutet diese Konfiguration beispielsweise, dass alle Hosts am Satellite-Standort aus derselben Cloudregion wieus-east-1
stammen. Eine steigende Latenz kann sich auf die Leistung auswirken, z. B. auf die Bereitstellungs- und Wiederherstellungszeiten, reduzierte Workerknoten im Cluster, eine Verschlechterung des Satellite-fähigen IBM Cloud-Service, und in Extremfällen kann es zu Fehlern in Ihren Clusteranwendungen kommen.