Das Erstellen einer hochverfügbaren relationalen Datenbank in AWS RDS erfolgt in weiten Teilen mit Hilfe von Assistenten. Die hier beschriebene Multi-Availability-Zone-Bereitstellung erfordert die Konfiguration von Subnet groups, bevor man einen Instanztyp wählt und danach die Einstellungen für die Datenbank festlegt.
Erste Anlaufstelle ist die RDS-Konsole in der AWS Management Console. Beim ersten Besuch landet man automatisch im Dashboard. Ist wie in unserem Beispiel ein Multi-AZ-Deployment geplant, klickt man weder auf Create database noch auf den einladenden Button Launch an Aurora DB Instance. Amazon möchte dem Nutzer damit seine eigene Enterprise-Variante einer MySQL-/PostgresQL-kompatiblen relationalen Datenbank andienen.
VPC und Subnetze
Zuerst benötigen wir vielmehr eine so genannte Subnet group, welche die gewünschten Availability Zones in der Ziel-VPC definieren. Dazu klickt man im Navigator links auf Subnet groups. Ist er eingeklappt, dann genügt ein Klick auf das Menü-Symbol oben links.
Zum Erstellen einer neuen Subnet group klickt man nach der Wahl der Zielregion (oben rechts) auf Create DB Subnet Group und legt im folgenden Dialog zunächst einen Namen, eine Beschreibung und die Ziel-VPC fest. Das Hinzufügen der Ziel-Subnetze erfolgt dann im Abschnitt Add subnets. Die Bedienung ist an dieser Stelle etwas umständlich.
Am schnellsten gelingt dies durch einen Klick auf Add all the subnets related to this VPC (was für einen schnellen Test schon ausreicht). Anschließend entfernt man in produktiven Setups alle öffentlichen Subnetze, damit die Datenbank nicht aus dem Internet zugreifbar ist, es sei denn, dies ist ausdrücklich erwünscht (siehe dazu auch: AWS Virtual Private Cloud: Subnetze, Gateways und Routing-Tabellen konfigurieren).
Wizard starten
Nun steht dem Bereitstellen der DB-Instanz nichts mehr im Wege. Dafür klickt man im Menü Instances auf Create dababase und wählt zunächst die gewünschte DB-Engine (Achtung: Amazon Aurora ist vorausgewählt!). Wir entscheiden uns hier für MySQL. Sie unterstützt bis zu 16 TB Instanz-Speicher, Instanzgrößen bis zu 32 vCPUs und 244 GB RAM.
Ein Klick auf Next erlaubt noch einmal das Auswählen eines so genannten Cases (also eines Anwendungs-typs), wobei AWS wiederum den Use Case Production – Amazon Aurora empfiehlt. Wir setzen uns aber darüber hinweg und entscheiden uns für Production – MySQL, um ein Multi-AZ-Deployment realisieren zu können, was mit Dev/Test – MySQL nicht klappen würde.
Wahl der DB-Engine
Schritt 3 des Deployment-Assistenten widmet sich dann dem Spezifizieren der eigentlichen DB-Details. Die Auswahl des License model ist bei MySQL natürlich hinfällig. Bei DB engine version hat man die Möglichkeit, auch eine ältere Version als die jeweils aktuelle (im Moment MySQL 5.7.22) auszuwählen. Damit lässt sich die Abwärtskompatibilität mit vorhandenen Applikationen gewährleisten.
Anschließend wählt man die Instanzgröße. Da eine relationale Datenbank, abgesehen von einigen Ausnahmen, immer nur auf einer Instanz läuft und im Prinzip auch nur vertikal skaliert, ist hier der recht leistungsfähige Instanztyp db.r4.xlarge mit 4 vCPUs und 30,5 GB RAM voreingestellt. Nur für Testzwecke oder das Nachstellen dieser Demo empfehlen wir ein Downsizing auf db.t2.micro.
Storage-Auswahl
Aufgrund der Use-Case-Auswahl Production ist Create replica in different zoneaktiviert, was wir auch so übernehmen. Beim Storage-Typ rüsten wir für den Test allerdings ab und ersetzen die Vorauswahl Provisioned IOPS (SSD) durch General Purpose SSD mit 20 GB Instanz-Speicher. Der Assistent weist dann freundlicherweise darauf hin, dass SSDs mit weniger als 100 GB zu Lasten des erzielbaren Durchsatzes gehen.
Die direkt darunter eingeblendete Kostenschätzung basiert auf den gewählten Werten und ist hilfreich, um die Datenbankbereitstellung mit dem verfügbaren Budget in Einklang zu bringen.
Schließlich vergibt man noch einen einprägsamen Namen für die DB-Instanz (das ist noch nicht der DB-Name!) und legt einen Namen für den DB-Master-User sowie dessen Passwort fest.
Erweitere Funktionen konfigurieren
Weiter geht es mit dem Konfigurieren der erweiterten Features durch einen Klick auf Next im Schritt 4. Unter dem Abschnitt Network & Security folgt die Auswahl der Ziel-VPC und der gewünschten Subnetze für Multi-AZ durch Angabe der oben erstellten Subnet group.
Ferner kann man an dieser Stelle bestimmen, ob ein öffentlicher Zugriff über das Internet und TCP/IP erlaubt sein soll. Ob ein solcher dann tatsächlich funktioniert, hängt aber auch von den konfigurierten Routen, Subnetz und Security Groups ab. Die Wahl der Availability Zone entfällt, da man sich zuvor bereits für Multi-AZ entschieden hat.
Zuweisung von Security-Groups
Eine DB-Instanz braucht eine Sicherheitsgruppe aber ganz genauso wie jede andere EC2-Instanz. Die vom Launch-Wizard auf Wunsch automatisch erstellte Security-Group erlaubt ausschließlich eingehenden Traffic auf Port 3306 sowie Antworten der DB-Instanz darauf (zur Erinnerung: Security Groups sind stateful).
In einem Praxis-Setup könnte man als Quelle die Security-Group der Frontend-Webservers oder der Middleware-Systeme angeben. Wir werden die Regel der Security-Group später noch erweitern, um die Konnektivität zur Datenbank testen zu können.
Danach geht es bei Database options darum, den Namen der eigentlichen Datenbank und den Ziel-Port (Default bei MySQL ist 3306) festzulegen. Bei DB parameter group übernehmen wir die Voreinstellung ebenso wie bei IAM DB authentication, welche wir für den ersten Test nicht nutzen. Die Datenbank-Verschlüsselung wird von der gewählten Datenbank-Engine (MySQL) nicht unterstützt.
Backup und Wartungsfenster
Im Abschnitt Backup schließlich wird die automatische Sicherung eingerichtet. Vorgabewert ist 7 Tage. Für Testzwecke setzen wir den Wert auf 0 und die Auswahl des Backup window auf No preference. Das Monitoring schalten wir aus Kostengründen für die Demo auf Disable enhanced monitoring, nachdem AWS CloudWatch die Standardmetriken ohnehin kostenfrei bereitstellt.
Schließlich muss noch das Wartungsfenster konfiguriert werden. Dabei kann man noch entscheiden, ob auch das Einspielen von Minor version updates der Datenbank-Engine automatisch erfolgen soll. Das Wartungsfenster selbst ließe sich mit Select window den eigenen Bedürfnissen anpassen.
DB-Instanz erzeugen
Mit einem Klick auf Create database wird die DB-Instanz schließlich erstellt, was je nach Instanztyp und Speichergröße mehrere Minuten dauern kann. Der Vorgang lässt sich mit einem Klick auf View DB instance details in der Instanzliste des RDS-Dashboards verfolgen.
Folgt man in der Instanzliste dem Link der markierten DB-Instanz, dann werden unten auch die Instanzdetails mit dem Status Creating eingeblendet. Den Datenbankendpunkt, der erst mit Fertigstellung der Instanz angezeigt wird, benötigen wir für den finalen Test. Er enthält einen von Route 53 generierten privaten DNS-Namen. Die IP-Adresse der Instanz ist nicht sichtbar und für einen Verbindungstest auch nicht erforderlich.
