Anleitung: Datenbank auf AWS RDS einrichten

    Relationale Datenbanken anlegen in AWS RDSDas Erstellen einer hoch­verfüg­baren rela­tionalen Daten­bank in AWS RDS er­folgt in weiten Teilen mit Hilfe von Assi­stenten. Die hier be­schriebene Multi-Availability-Zone-Bereit­stellung er­fordert die Konfi­guration von Subnet groups, bevor man einen Instanz­typ wählt und danach die Ein­stellungen für die Daten­bank fest­legt.

    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 ein­geklappt, 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.

    Subnet groups und Subnetze für die DB-Instanz anlegen

    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 öffent­lichen Subnetze, damit die Daten­bank 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 Bereit­stellen 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 voraus­gewählt!). Wir entscheiden uns hier für MySQL. Sie unterstützt bis zu 16 TB Instanz-Speicher, Instanz­größen bis zu 32 vCPUs und 244 GB RAM.

    Ein Klick auf Next erlaubt noch einmal das Aus­wählen eines so genannten Cases (also eines Anwen­dungs-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) auszu­wählen. Damit lässt sich die Abwärts­kompatibilität mit vor­handenen Applikationen gewähr­leisten.

    Auswahl der Datenbank-Engine

    Anschließend wählt man die Instanz­größ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 leistungs­fähige Instanztyp db.r4.xlarge mit 4 vCPUs und 30,5 GB  RAM vorein­gestellt. Nur für Testzwecke oder das Nach­stellen dieser Demo empfehlen wir ein Downsizing auf db.t2.micro.

    Storage-Auswahl

    Aufgrund der Use-Case-Auswahl Production ist Create replica in different zone aktiviert, was wir auch so über­nehmen. 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 freund­licher­weise darauf hin, dass SSDs mit weniger als 100 GB zu Lasten des erzielbaren Durchsatzes gehen.

    Die direkt darunter eingeblendete Kosten­schätzung basiert auf den gewählten Werten und ist hilfreich, um die Daten­bank­bereit­stellung mit dem verfügbaren Budget in Einklang zu bringen.

    Festlegen des Namens für die DB-Instanz

    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 Konfi­gurieren 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 Sicherheits­gruppe 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).

    Sicherheitseinstellungen für die DB-Instanz konfigurieren

    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 Konnek­tivität zur Daten­bank 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) fest­zulegen. Bei DB parameter group übernehmen wir die Vorein­stellung ebenso wie bei IAM DB authentication, welche wir für den ersten Test nicht nutzen. Die Datenbank-Ver­schlüsselung wird von der gewählten Datenbank-Engine (MySQL) nicht unter­stü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 Kosten­gründen für die Demo auf Disable enhanced monitoring, nachdem AWS CloudWatch die Standard­metriken ohnehin kostenfrei bereit­stellt.

    Backup und Wartungsfenster definieren

    Schließlich muss noch das Wartungs­fenster konfiguriert werden. Dabei kann man noch entscheiden, ob auch das Einspielen von Minor version updates der Datenbank-Engine automatisch erfolgen soll. Das Wartungs­fenster 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 Speicher­größe mehrere Minuten dauern kann. Der Vorgang lässt sich mit einem Klick auf View DB instance details in der Instanz­liste des RDS-Dashboards verfolgen.

    Vorgang zum Erzeugen einer DB-Instanz starten

    Folgt man in der Instanz­liste dem Link der markierten DB-Instanz, dann werden unten auch die Instanz­details mit dem Status Creating eingeblendet. Den Daten­bank­endpunkt, 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.

    Keine Kommentare