Skalierung von Ressourcen in Azure Database for PostgreSQL – Flexibler Server
GILT FÜR: 
Azure Database for PostgreSQL – Flexibler Server
Azure Database for PostgreSQL – Flexible Server unterstützt sowohl vertikale als auch horizontale Skalierungsoptionen.
Vertikale Skalierung
Sie können Ihre Instanz vertikal skalieren, indem Sie Ihrer Azure Database for PostgreSQL – Flexibler Server-Instanz weitere Ressourcen hinzufügen. Sie können die Anzahl der zugewiesenen CPUs und des Arbeitsspeichers vergrößern oder verkleinern.
Der Netzwerkdurchsatz Ihrer Instanz hängt von den Werten ab, die Sie für CPU und Arbeitsspeicher auswählen.
Nachdem eine Azure Database for PostgreSQL – Flexibler Server-Instanz erstellt wurde, können Sie Folgendes unabhängig voneinander skalieren:
- Computeebene und -SKU
- Speicherebene und -größe
- Aufbewahrungszeitraum von Sicherungen
Die Computeebene kann zwischen „burstfähig“, „universell“ und „arbeitsspeicheroptimiert“ skaliert werden, um sich an die Anforderungen Ihrer Workload anzupassen. In jeder dieser Ebenen gibt es eine große Auswahl an vorkonfigurierter Hardware verschiedener Generationen und mit mehr oder weniger CPUs und mehr oder weniger installiertem Arbeitsspeicher. Aus dieser großen Auswahl können Sie jederzeit die Lösung wählen, die Ihren Ressourcenbedarf deckt und gleichzeitig Ihre Betriebskosten reduziert und an Ihre Bedürfnisse anpasst.
Die Anzahl virtueller Kerne und installiertem Arbeitsspeicher kann zentral hoch- oder herunterskaliert werden. Die Speicherebene kann auch nach oben oder unten konfiguriert werden, um den Anforderungen an Durchsatz und IOPS gerecht zu werden, die Ihre Arbeitslast erfordert. Die Speichergröße kann nur erhöht werden. Außerdem können Sie je nach Bedarf den Aufbewahrungszeitraum der Sicherungskopien zwischen 7 und 35 Tagen erhöhen oder verringern.
Diese Ressourcen können mithilfe mehrerer Schnittstellen skaliert werden. Sie können beispielsweise das Azure-Portal oder die Azure CLI verwenden.
Hinweis
Wenn Sie den Ihrer Instanz zugewiesenen Speicherplatz vergrößert haben, können Sie ihn nicht wieder verringern.
Horizontale Skalierung
Sie können Ihre Instanz horizontal skalieren, indem Sie Lesereplikate erstellen. Mit Lesereplikaten können Sie Ihre Leseworkloads auf separate flexible Serverinstanzen von Azure Database for PostgreSQL skalieren. Sie haben keinen Einfluss auf die Leistung und Verfügbarkeit der primären Instanz.
In einem horizontal skalierten Setup können die primäre Instanz und die Lesereplikate auch vertikal skaliert werden.
Wenn Sie die Anzahl der virtuellen Kerne oder die Computeebene ändern, wird die Instanz neu gestartet, damit die neu zugewiesene Hardware mit der Ausführung Ihrer Server-Workload beginnt. Währenddessen wechselt das System zum neuen Servertyp. Es können keine neuen Verbindungen hergestellt werden, und für alle nicht committeten Transaktionen wird ein Rollback ausgeführt.
Die insgesamt für den Neustart Ihres Servers benötigte Zeit hängt vom Absturzwiederherstellungsprozess und der Datenbankaktivität zum Zeitpunkt des Neustarts ab. Der Neustart dauert in der Regel höchstens eine Minute, kann jedoch mehrere Minuten in Anspruch nehmen. Die Dauer hängt von der Transaktionsaktivität ab, die zum Zeitpunkt der Einleitung des Neustarts stattfand.
Wenn Ihre Anwendung empfindlich auf den Verlust von In-Flight-Transaktionen reagiert, der bei der Skalierung der Datenverarbeitung auftreten kann, empfehlen wir die Implementierung eines Wiederholungsmusters für Transaktionen.
Die Skalierung des Speichers erfordert in den meisten Fällen keinen Serverneustart. Weitere Informationen finden Sie unter Speicheroptionen in Azure Database for PostgreSQL – Flexibler Server.
Die Änderung des Aufbewahrungszeitraums von Sicherungskopien ist ein Onlinevorgang.
Um die Neustartzeit zu verkürzen, empfehlen wir Ihnen, die Skalierung außerhalb der Hauptgeschäftszeiten durchzuführen. Dieser Ansatz verringert die Zeit, die für den Neustart des Datenbankservers benötigt wird.
Skalierung mit nahezu null Ausfallzeiten
Skalierung mit nahezu null Downtime ist ein Feature zur Minimierung von Downtime, wenn Speicher- und Computeebenen geändert werden. Wenn Sie die Anzahl von virtuellen Kernen oder die Computeebene ändern, wird der Server neu gestartet, um die neue Konfiguration anzuwenden. Während dieses Übergangs zum neuen Server können keine neuen Verbindungen hergestellt werden.
In der Regel kann dieser Vorgang bei normaler Skalierung zwischen 2 und 10 Minuten dauern. Mit dem Skalierungsfeature mit nahezu keiner Downtime wird dies auf weniger als 30 Sekunden reduziert. Durch diese Reduzierung der Downtime während der Skalierung von Ressourcen wird die Gesamtverfügbarkeit Ihrer Datenbankinstanz verbessert.
Funktionsweise
Wenn Sie Ihre Azure Database for PostgreSQL – Flexibler Server-Instanz bei Skalierungsszenarien aktualisieren, erstellt der Dienst eine VM für Ihren Server mit der aktualisierten Konfiguration. Anschließend wird sie mit der VM synchronisiert, auf dem ihre Instanz gerade ausgeführt wird, und wechselt dann mit einer kurzen Unterbrechung zur neuen VM. Anschließend beseitigt ein Hintergrundprozess die alte VM. Dieser gesamte Vorgang ist für Sie kostenlos.
Dieser Prozess ermöglicht nahtlose Updates, wobei Downtime minimiert und Kosteneffizienz sichergestellt werden. Dieser Skalierungsprozess wird durch Änderungen an den Speicher- und Computeebenen ausgelöst. Für die Nutzung dieser Funktion ist keine Kundenaktion erforderlich.
Bei horizontal skalierten Konfigurationen, die aus einem Primärserver und einem oder mehreren Lesereplikaten bestehen, müssen die Skalierungsvorgänge in einer bestimmten Reihenfolge erfolgen, um die Datenkonsistenz zu gewährleisten und Downtime zu minimieren. Ausführliche Informationen zu dieser Sequenz finden Sie unter Skalieren mit Lesereplikaten.
Hinweis
Die Skalierung mit nahezu keiner Downtime ist der Standardbetriebstyp. Wenn die folgenden Einschränkungen auftreten, schaltet das System jedoch auf eine reguläre Skalierung um, die mehr Downtime als die Skalierung mit nahezu keiner Downtime mit sich bringt.
Genaue Erwartungen bezüglich der Downtime
- Downtimedauer: In den meisten Fällen beträgt die Downtime zwischen 10 und 30 Sekunden.
- Andere Überlegungen: Nach einem Skalierungsereignis tritt eine inhärente DNS
Time-To-Live-Periode (TTL) von etwa 30 Sekunden auf. Dieser Skalierungsprozess steuert diesen Zeitraum nicht direkt. Er ist ein Standardbestandteil des DNS-Verhaltens. Aus der Anwendungsperspektive kann die gesamte Downtime während der Skalierung zwischen 40 und 60 Sekunden betragen.
Überlegungen und Einschränkungen
- Damit die Skalierung mit nahezu keiner Downtime funktioniert, müssen Sie alle ein- und ausgehenden Verbindungen zwischen den IP-Adressen im delegierten Subnetz zulassen, wenn Sie das integrierte VNet verwenden. Wenn diese Verbindungen nicht zugelassen wurden, funktioniert der Skalierungsprozess mit nahezu keiner Downtime nicht, und die Skalierung erfolgt über den Standardskalierungsworkflow.
- Die Skalierung mit nahezu keiner Downtime funktioniert nicht, wenn regionale Kapazitätsbeschränkungen oder Kontingentbeschränkungen für Ihr Abonnement gelten.
- Die Skalierung mit nahezu keiner Downtime funktioniert auf einem Replikationsserver nicht, da sie nur auf dem Primärserver unterstützt wird. Bei Replikatservern durchläuft der Skalierungsvorgang automatisch den regulären Prozess.
- Die Skalierung mit nahezu keiner Downtime funktioniert nicht, wenn ein in ein virtuelles Netzwerk eingebundener Server im delegierten Subnetz nicht über ausreichend verwendbare IP-Adressen verfügt. Wenn Sie einen eigenständigen Server haben, ist eine zusätzliche IP-Adresse erforderlich. Für eine Instanz, bei der Hochverfügbarkeit aktiviert ist, sind zwei zusätzliche IP-Adressen erforderlich.
- Logische Replikationsslots bleiben während eines Failoverereignisses mit nahezu null Downtime nicht erhalten. Um logische Replikationsslots beizubehalten und die Datenkonsistenz nach einem Failover zu gewährleisten, verwenden Sie die Erweiterung pg_failover_slot. Weitere Informationen finden Sie unter Aktivieren der pg_failover_slots-Erweiterung in einer Instanz von Flexibler Server.
- Downtime-Skalierung von fast null funktioniert nicht mit nicht protokollierten Tabellen. Wenn Sie für bestimmte Daten nicht protokollierte Tabellen verwenden, verlieren Sie nach der Skalierung mit nahezu keiner Downtime alle Daten in diesen Tabellen.