Hallo zusammen.
Und willkommen zurück.
In diesem Video erhalten Sie einen Überblick über die Amazon-Ideen für die Bereitstellung mehrerer Verfügbarkeitszonen,
die auch als Mehrfachbereitstellungen bezeichnet werden.
Bevor wir nun näher darauf eingehen, wollen wir uns eine typische Herausforderung ansehen.
Nehmen wir also an, dass Sie eine Datenbank haben, die in der Verfügbarkeitszone Nummer eins läuft.
Wenn nun aus irgendeinem Grund diese Verfügbarkeitszone 1 ausfällt oder vielleicht die Hardware, auf der die Datenbank
läuft, ausfällt, dann fällt Ihre gesamte Anwendung aus, weil das Herzstück der Anwendung, in dem
die Daten hauptsächlich gespeichert sind, die Datenbank ist.
Wenn die Datenbank ausfällt, kann auch die gesamte Website ausfallen.
Und das ist etwas, das Sie in Produktionsumgebungen nicht wirklich wollen.
Aus diesem Grund ist es sehr wichtig, dass Sie, wenn Sie Ideen für die Produktion verwenden, die Bereitstellung
auf der Grundlage einer einzigen Verfügbarkeitszone vermeiden sollten.
Und die bessere Architektur ist die Verwendung von Bereitstellungen mit mehreren Verfügbarkeitszonen.
In einer Multi-AC-basierten Bereitstellungsarchitektur gibt es also eine primäre Datenbank
und eine sekundäre Datenbank, die in einer anderen Verfügbarkeitszone derselben Region läuft, und
es findet eine Replikation zwischen diesen beiden Datenbanken statt.
Nun, aus irgendeinem Grund, sagen wir mal, die primäre Datenbank fällt in solchen Fällen aus, werden die Ideen alle
Anfragen an die Stand-by-Instanz umleiten.
Also gut.
Dies ist also der automatisierte Prozess.
Als Nutzer oder als Anwendung müssen Sie sich darüber keine Gedanken machen.
Nun stellt sich die Frage, in welchem Szenario dieses automatische Failover von der primären
zur Standby-Instanz stattfindet.
Bevor wir uns mit den Bedingungen befassen, sollten wir noch einmal kurz darauf hinweisen, dass im Falle eines geplanten
oder ungeplanten Ausfalls Ihrer Datenbankinstanz automatisch auf das Standby-Replikat in einer anderen Verfügbarkeitszone in
Multi-AC-Bereitstellungen umgeschaltet wird.
Das ist etwas, das wir gesehen haben.
Schauen wir uns nun einige der Bedingungen an.
Erstens, wenn die Verfügbarkeit in der primären Verfügbarkeitszone ausfällt.
Zweitens: Wenn die Netzwerkverbindung zur primären Instanz unterbrochen wird und eine Recheneinheit
auf der primären Instanz ausfällt, findet wiederum ein Failover statt.
Kommt es in solchen Fällen zu einem Speicherausfall auf der primären Datenbankinstanz, findet auch das automatische
Failover statt.
Und wenn wir uns die Failover-Zeit ansehen, liegt sie in der Regel zwischen 60 und 1 bis 20 Sekunden.
Lassen Sie uns eine Sache tun.
Lassen Sie uns fortfahren und dies aus der Perspektive der Demo verstehen, damit unser Konzept klar ist.
In der heutigen Demo habe ich eine Datenbank, die auf der Grundlage einer Multi-AC-Bereitstellung erstellt wurde.
Der Name der Datenbank ist Demo DB, Multi AC.
Wenn Sie sich nun diese spezielle Datenbank ansehen, lassen Sie mich zur Konfiguration gehen.
Gehen wir ein Stück weiter runter.
Sie sehen, dass es heißt, dass Multi AC aktiviert ist, also wird es als ja angegeben.
Schauen wir uns also einmal an, wie genau das funktioniert.
Wir gehen hier also zur Konnektivität über.
Lassen Sie mich den Endpunkt der IDs-Instanz kopieren.
Lassen Sie uns schnell nachschauen, welche IP-Adresse hier zurückgegeben wird.
Die IP-Adresse ist eine 7231 37. 32.
Wenn ich Ihnen dies in einem Diagramm zeigen soll, können Sie davon ausgehen, dass die IP-Adresse,
die zurückgegeben wurde, die der primären Instanz hier ist.
Zur Veranschaulichung führen wir nun ein Failover durch und sehen, wie sich die IP-Adresse in die der sekundären
Instanz ändert.
Lassen Sie uns also eine Sache tun.
Starten wir nun die Datenbankinstanz neu.
Jetzt haben Sie bei jedem Neustart die Möglichkeit, mit Failover neu zu starten.
Lassen Sie uns also fortfahren und eine Bestätigung vornehmen.
Dies ist also nur ein einfacher Weg, um herauszufinden, wie der Multi-AC-Einsatz in realen Szenarien funktioniert.
Falls es Probleme mit dem Netzwerk gibt und die Ausfallsicherung automatisch erfolgt, brauchen Sie sich darüber
keine Gedanken zu machen.
Lassen Sie mich also schnell eine Bestätigung vornehmen.
Also gut.
Der Wiederaufbau ist also im Gange.
Lassen Sie uns also einen Moment warten.
Nach der Aktualisierung ist unser Status nun verfügbar.
Wenn Sie jetzt die NSS-Suche erneut durchführen, um die mit der Datenbankinstanz verbundene IP-Adresse zu finden,
werden Sie feststellen, dass die IP-Adresse diesmal eine andere ist.
Früher war es eine 7231 3732, jetzt ist es eine 7231 79. 1 47.
Hinter den Kulissen hat RDC die Anfrage also automatisch an die Standby-Instanz weitergeleitet.
Eine wichtige Sache, die beachtet werden muss, ist, dass die Endpunkt-URL, über die wir
hier sprechen, die gleiche bleibt.
Selbst wenn also die primäre Datenbank ausfällt und die Anfragen an diesen Endpunkt gehen, leiten die Ideen die
Anfrage automatisch an die Standby-Instanz weiter.
Dies ist der Grund, warum die mündliche Hochverfügbarkeit in einer Multi-AC-basierten Architektur funktioniert.