Microsoft empfiehlt die schlanke Instal­lations­variante von Windows Server für die meisten Infra­struktur­dienste und mittler­weile auch für Anwen­dungen wie Exchange 2019. Auch SQL Server lässt sich auf Server Core betreiben. Die Instal­lation erfor­dert dort aber einige Schritte auf der Kom­mando­zeile.

Microsoft gab kürzlich SQL Server 2019 als GA frei. Während diese Ver­sion zahl­reiche neue Features bringt, vor allem für das Verar­beiten von Big Data, bleibt es bei den von 2016 und 2017 be­kannten Editionen. Änderungen gab es da­gegen bei den Nutzungs­rechten über die Soft­ware Assurance.

Die meisten Instal­lationen der Windows Server Update Services laufen auf der Windows Internal Data­base (WID). Möchte man nach­träglich auf SQL Server um­stellen, dann kann man dies relativ einfach mit den Kommando­zeilen-Tools sqlcmd und wsusutil tun. Der Weg zurück ist damit eben­falls möglich.

Zu den Wartungs­aufgaben bei den Windows Server Update Services (WSUS) kann gehören, dass die herunter­gela­denen Updates oder die SUSDB-Daten­bank in ein anderes Ver­zeichnis um­ziehen müssen. Dies lässt sich voll­ständig von der Kommando­zeile erledigen, so dass dieses Vorgehen auch unter Server Core klappt.

Eine SQL-Daten­bank erweist sich nicht nur bei der klassischen Anwen­dungs­ent­wicklung als prak­tisch, sondern kann auch den Scripts der System­verwaltung als Speicher dienen. Microsoft stellt daher für SQL Server ein PowerShell-Modul zur Verfügung, mit dem man in die Daten­bank schreiben und daraus lesen kann.

Relationale Daten­banken skalieren nor­maler­weise nicht hori­zontal, wenn man vom Multi-AZ-Feature absieht, einer speziellen Eigen­schaft von AWS-RDS-Instanzen. Anders hingegen ist die Lage bei Read-Replikaten. Das Feature stellt eine Art von horizon­talem Cluster dar, der einzig einer Erhöhung der Lese-Performance dient.

RDS operiert hinsichtlich der Management-Ebene deutlich näher an normalen EC2-Instanzen, als dies etwa der voll verwaltete Datenbank-Service DynamoDB tut. Daher erfor­dern Datenbank-Instanzen so wie jede physische Instal­lation eine regel­mäßige Wartung. Dazu zählen Updates für das Betriebs­system und die Daten­bank selbst.

Wenn man erfolg­reich eine neue DB-Instanz auf Basis des AWS Relational Database Service (RDS) er­stellt hat, möchte man wahr­schein­lich testen, ob die Daten­bank für Anwen­dungen von außen er­reich­bar ist. Ver­läuft dieser Test posi­tiv, dann kann der Nutzer sein Daten­modell ent­wickeln und die benö­tigten Tabellen erstellen.

Das 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.

Amazon bietet mit RDS alle gän­gigen rela­tionalen Daten­banken als Cloud-Service an. Wie bei anderen Diensten rech­net AWS auch hier nach Ressourcen­verbrauch ab. Bei Daten­banken betrifft das nicht nur Rechen­leistung und den Speicher­verbrauch, sondern je nach Modell auch IOPS und über­tragenes Daten­volumen.