Zum Inhalt

Region-Erweiterung

Wie du entscheidest, ob du der Plattform eine Azure-Region hinzufügst, und welche. Die technischen Schritte stehen in Region hinzufügen. Diese Seite behandelt die Entscheidung.

Wann du eine neue Region in Betracht ziehen solltest

Typische Auslöser:

  • die aktuelle Region hat Kapazitätsengpässe, die Deployments oder Verfügbarkeit beeinträchtigen,
  • der Wunsch nach besserer geografischer Redundanz oder einem Disaster-Recovery-Ziel,
  • Anforderungen eines Workloads an Datenresidenz oder Latenz,
  • ein Service, den du brauchst, ist in den aktuellen Regionen nicht verfügbar.

Kriterien

Vergleiche die Kandidatenregionen anhand derselben Liste. Nutze für jede die aktuellen Informationen von Microsoft.

Kriterium Fragen
Service-Verfügbarkeit und Reife Sind die Services, die du nutzt, verfügbar, jetzt und auf der Roadmap? (Prüfe die Services, die deine Workloads nutzen, zum Beispiel Kubernetes, Datenbanken und die Application-Gateway-SKU.)
Kapazität und Wachstum Hat die Region einen Kapazitätsausbau gezeigt, und ist mehr geplant?
Latenz Latenz innerhalb der Region und zu deinen bestehenden Regionen. Niedrige Latenz zwischen Regionen ist für Disaster Recovery und synchrone Replikation wichtig.
Redundanz Gibt es Availability Zones (drei oder mehr)? Ist die Region geografisch unabhängig genug von den bestehenden, um vor einem regionalen Ausfall zu schützen?
Netzwerkkosten Datenausgang und Gebühren für Übertragung zwischen Regionen für den erwarteten Verkehr
Konnektivität Qualität der Anbindung an deine On-Premises-Standorte und ans Internet
Plattformkosten Ein neuer virtual hub, eine firewall und Gateways verursachen feste monatliche Kosten

Leitlinien

  • Füge eine Region nach der anderen hinzu, neben den bestehenden, statt eine Region auf einmal zu ersetzen. So kannst du ausgewählte Workloads schrittweise verschieben und hältst die Kosten niedrig.
  • Platziere Workloads in der neuen Region, wenn die Anforderungen an Kapazität und Services erfüllt sind. Nutze sie nur dann als Failover-Ziel, wenn sie unabhängig genug von den anderen ist.
  • Halte die firewall-Regeln über Regionen hinweg konsistent, damit ein Failover funktioniert. Siehe Organisation der Firewallregeln.
  • Weise die Adressbereiche aus dem IP-Plan zu, bevor du beginnst, und halte sie frei von Überschneidungen mit anderen Regionen und spokes.
  • Wähle den Region-Kurznamen sorgfältig. Er wird in jedem Ressourcennamen und in den state-Keys verwendet, und manche Ressourcennamen haben ein Längenlimit (Namen und Tags).

Folgen

Auswirkung Detail
Kosten Ein neuer virtual hub im Virtual WAN mit firewall, DNS Resolver und optionalen Gateways. Mögliche Kosten für die Datenübertragung zwischen Regionen bei Workloads, die regionsübergreifend kommunizieren.
Komplexität Der Betrieb von drei Regionen ist komplexer als von zwei: mehr Routing, mehr Regelsätze, mehr Stellen für drift
Routing Das Routing muss eventuell angepasst werden, damit der Verkehr korrekt fließt, auch zu On-Premises-Netzwerken
Platzierung Gibt dir einen zusätzlichen Ort für Workloads

Beispiel

Eine Plattform lief in zwei Regionen (einer primären und einer für Failover). Wegen Kapazitätsengpässen in der primären Region und dem Wunsch nach besserer Redundanz verglich das Team mehrere Kandidatenregionen anhand der obigen Kriterien und wählte eine zusätzliche Region mit zentraler Lage, einem kürzlichen Kapazitätsausbau, einem breiten Service-Portfolio, drei oder mehr Availability Zones und etwa 10 bis 15 ms Latenz zur primären Region. Sie wurde neben den bestehenden Regionen hinzugefügt, sodass Workloads schrittweise umziehen konnten. Das ist ein Beispiel für die Überlegungen, keine Empfehlung für eine bestimmte Region.