Azure freischalten: So bauen Sie eine hochflexible SQL-Datenbank-Infrastruktur auf

Es ist kein Geheimnis, dass sich Infrastructure as a Service und Platform as a Service in den letzten Jahren aufgrund ihrer Möglichkeiten, insbesondere der Ressourceneffizienz und Flexibilität, in verschiedenen Projekten zunehmend durchgesetzt haben. Daher hat Microsoft viel Zeit und Mühe darauf verwendet, eine benutzerfreundliche Umgebung zu schaffen, in der SQL verwendet werden kann.

Das Team der Social Discovery Group nutzt eine Vielzahl von Datenbanken, einschließlich SQL, um unsere Produkte zu betreiben. Mit einem Portfolio von über 40 globalen Diensten, die dabei helfen, sich weltweit zu treffen und Kontakte zu knüpfen, umfasst unsere Nutzerbasis über 250 Millionen Menschen auf der ganzen Welt. Um die Zuverlässigkeit unserer Produkte für die Nutzer zu gewährleisten, halten wir einen Teil der Schlüsselinfrastruktur in der Cloud. Dies trägt dazu bei, die Widerstandsfähigkeit, Sicherheit und Flexibilität zu verbessern.

Wir haben große Erfahrung mit der Bereitstellung von Server- und Servicedatenbanken auf verschiedenen Plattformen, einschließlich Kubernetes-Clustern. Wir standen jedoch vor der Notwendigkeit, einen Teil der zugehörigen SQL-Datenbank-Infrastruktur in der Azure-Cloud so flexibel, effizient und zuverlässig wie möglich zu gestalten. Es gibt drei Möglichkeiten, SQL in der Microsoft Azure-Cloud zu verwenden:

• Azure SQL-Datenbank
• Azure SQL Managed Instance
• SQL Server auf Azure Virtual Machines

Nach der Recherche haben wir uns für die Verwendung von Azure SQL-Datenbanken entschieden. Nur zur Klarstellung für diejenigen, die noch nie von sogenannten Azure SQL-Datenbanken gehört haben: Dabei handelt es sich um verwaltete Cloud-Datenbanken, die als Teil von Microsoft Azure bereitgestellt werden.

Ich habe die folgenden Vorteile hervorgehoben:

• Sie müssen sich keine Gedanken über Updates oder End-of-Life-Support machen;
• Einfache Konfiguration und Bereitstellung;
• Geschwindigkeit der Bereitstellung (und damit der Entwicklung) und Skalierbarkeit;
• Hohe Verfügbarkeit;
• Fehlertoleranz;
• Einfache Sicherung;
• Kostenoptimierung;
• Ein integriertes Microsoft Azure-Überwachungssystem.

Lassen Sie uns nun Schritt für Schritt über die Dinge sprechen und einen Blick auf den Prozess der Bereitstellung und Erstellung einer Datenbank werfen. Dies kann über ein Power Shell-Skript oder die Azure CLI erfolgen, der Übersichtlichkeit halber betrachte ich den Vorgang jedoch über die grafische Oberfläche des Portals. Gehen Sie dazu zu Azure SQL, klicken Sie auf „Erstellen“ und wählen Sie „SQL-Datenbanken“.

Wir geben die Ressourcengruppe an, wählen aus, ob ein bestehender Server vorhanden ist oder ob ein neuer erstellt wird (unter Angabe des Namens und der Daten des Administrators) und legen einen Namen für die Datenbank fest. Ich würde empfehlen, DTU-basierte Paketpakete (Database Transaction Unit) mit einer ausgewogenen Mischung aus Rechen- und Speicherressourcen für unsere allgemeinen Arbeitslasten zu wählen.

Es gibt auch einige Registerkarten für Einstellungen: Netzwerk, Sicherheit, Zusätzliche Einstellungen und Tags; Bei einer minimalen Standardkonfiguration können diese standardmäßig unverändert bleiben. Dann warten wir darauf, dass die Datenbank erstellt wird. Damit ist die Mindesteinrichtung abgeschlossen und die Basis ist fertig.

Die Größe der Datenbankressourcen lässt sich supereinfach, buchstäblich mit einem Klick, ändern und bei unzureichenden Ressourcen können wir die Parameter einstellen, die wir in Bezug auf Größe und Leistung benötigen.

Anschließend können Sie von außen auf beliebige Weise eine Verbindung zu Ihrer Datenbank herstellen, ohne zu vergessen, Ihre IP-Adresse oder Ihr Subnetz hinzuzufügen oder alle Verbindungen in der Firewall des Servers zuzulassen, auf dem diese Datenbank gehostet wird.

Die Verbindung und weitere Verwaltung erfolgt bequem über SQL Server Management Studio (SSMS), es ist jedoch auch über andere Tools und das Azure-Portal selbst möglich.

Zusätzlich zu einem öffentlichen Verbindungspunkt können Sie auch einen privaten erstellen, indem Sie einen Server zum erforderlichen Subnetz hinzufügen und private DNS-Zonen konfigurieren.

Apropos Fehlertoleranz: Hier sehen wir eine sehr praktische und intuitive Implementierung von Failover, einer Gruppe von Schutzservern in verschiedenen Regionen.

In Azure ist es möglich, Datenbanken auf Servern in einer Failovergruppe, im erzwungenen Failover und im automatischen Failovermodus hinzuzufügen und zu entfernen.

Sie können dies im Screenshot unten sehen. Lassen Sie uns einen Namen für die Failover-Gruppe finden und den Server in den Failover versetzen. Die Synchronisierung der angegebenen Datenbanken wird automatisch gestartet. Der zweite Server befindet sich im schreibgeschützten Modus. Im Falle eines Ausfalls wird der Datenverkehr automatisch in die zweite Region umgeleitet und die primären und sekundären Server tauschen automatisch die Plätze.

Ein Failover hilft jedoch nicht, wenn in den Datenbanken selbst ein Problem auf Datenebene vorliegt. In diesem Fall müssen Sie unbedingt Backups erstellen. Es ist möglich, Sicherungen sowohl innerhalb des Portals als auch über Tools von Drittanbietern oder beispielsweise Azure DevOps zu konfigurieren (in der Pipeline können Sie die Aufgabe „SqlAzureDacpacDeployment + AzureFileCopy“ verwenden). Innerhalb des Portals werden Backups auf der Registerkarte Backups konfiguriert und die notwendigen Speicherrichtlinien festgelegt.

Wenn Sie lieber Sicherungstools von Drittanbietern verwenden möchten, würde ich empfehlen, Azure DevOps oder SQL-Pakettools in Betracht zu ziehen.

Der Wiederherstellungsprozess auf dem Portal selbst ist meiner Meinung nach nicht sehr praktisch. Das erste, was Ihnen auffällt, ist die lange Wiederherstellungszeit für einfache Testdatenbanken. Ich habe zum Beispiel mehr als eine halbe Stunde gebraucht, um eine 30-MB-Basisdatenbank aus dem gestrigen Backup wiederherzustellen! Nachdem ich den Microsoft Azure-Support kontaktiert hatte, wurde mir empfohlen, PowerShell-Skripte für die Wiederherstellung zu verwenden, und ich wurde darauf hingewiesen, dass die Datenbankgröße für den Wiederherstellungsprozess mindestens S3 betragen sollte und die Größe später reduziert werden könne. Im Folgenden werde ich einige meiner Skripte und Entwicklungen zu diesem Thema vorstellen. Sie können verbessert und erweitert werden, aber ich bin sicher, dass viele von Ihnen sie nützlich finden werden.

Ich begleite Sie Schritt für Schritt:

1. Falls Sie PowerShell ISE nicht unter Windows installiert haben, laden Sie es hier herunter: https://github.com/PowerShell/Pohell/releases/download/v7.3.0/PowerShell-7.3.0-win-x64.msi
   https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/PowerShell-7.3.0-win-x86.msi
2. Als nächstes müssen Sie das Azure-Modul installieren: Install-Module Az
3. Importieren Sie nach der Installation des AZ-Moduls das AZ-Modul: Import-Module Az
4. Nach dem Import können Sie eine Verbindung zu Ihrem Azure-Konto herstellen: Connect-AzAccount. Es erscheint ein Popup-Fenster, in dem Sie sich bei Ihrem Azure-Konto anmelden können. Anschließend werden Sie verbunden
5. Führen Sie das PowerShell-Skript selbst aus.

 “ #Variables in use $Database = Get-AzSqlDatabase -ResourceGroupName "Test" -ServerName "test-serv1" -DatabaseName "dbforscript" $TargetDB = "dbforscript_new" $PITRtimedate = "2022-12-02 10:00:00Z" ##вам нужно увидеть действительную дату и время на портале $PITRSLO = "S3" $PITRNEWSLO = "S0" $PITRedition = "Standard" $failoverGroupRG = "Test" $failoverGroupS = "test-serv1" $failoverGroupDB = "dbforscript" $removedbfromfgRG = "Test" $removedbfromfgS = "test-serv1" $removedbfromfgDB = "XXXXX" $dropreplicaRG = "Test" $dropreplicaS = "test-serv2" $dropreplicaDB = "dbforscript" $sourcedbRG = "Test" $sourcedbS = "test-serv1" $sourcedbDBname = "dbforscript" $sourcedbDBNEWname = "dbforscript_old" $TargetDBNEWname = "dbforscript" “

1 – Dieser Code initiiert eine Datenbankwiederherstellung mit einem anderen Namen. Wenn der ursprüngliche Name der wiederherzustellenden Datenbank „dbforscript“ lautet, lautet der Name der wiederhergestellten Datenbank dbforscript_new. Bei der wiederhergestellten Datenbank handelt es sich um die SLO-Version S3 oder höher. Dies ist die empfohlene Methode zum Ausführen dieser Aktion. Die Variable dafür lautet $PITRSLO = „S3“. Sie können S3 oder höher verwenden. Danach werden wir den SLO-Level auf den ursprünglichen Wert zurücksetzen. Dies dient nur der Wiederherstellung.

 “Restore-AzSqlDatabase -FromPointInTimeBackup -PointInTime $PITRtimedate -ResourceGroupName $Database.ResourceGroupName -ServerName $Database.ServerName -TargetDatabaseName $TargetDB -ResourceId $Database.ResourceID -Edition $PITRedition -ServiceObjectiveName $PITRSLO”

2 – Dieser Code entfernt die Quelldatenbank aus der Failover-Gruppe: Quelldatenbank: dbforscript.

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $failoverGroupdb | Remove-AzSqlDatabaseFromFailoverGroup -ResourceGroupName $removedbfromfgRG -ServerName $removedbfromfgS -FailoverGroupName $removedbfromfgDB”

3 – Dieser Code entfernt die Replikatdatenbank von dem Server, auf dem sie sich befindet: dbforscript auf dem test-serv2-Server.

 “Remove-AzSqlDatabase -ResourceGroupName $dropreplicaRG -ServerName $dropreplicaS -DatabaseName $dropreplicaDB”

4 – Dieser Code benennt die ursprüngliche Datenbank in einen anderen Namen um: Nach der Umbenennung lautet dbforscript dbforscript_old.

 “Set-AzSqlDatabase -ResourceGroupName $sourcedbRG -DatabaseName $sourcedbDBname -ServerName $sourcedbS -NewName $sourcedbDBNEWname”

5 – Dieser Code benennt die wiederhergestellte Datenbank in den ursprünglichen Datenbanknamen um und benennt dbforscript_new in dbforscript um.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDB -ServerName $Database.ServerName -NewName $TargetDBNEWname”

6 – Dieser Code setzt den SLO-Level Ihrer Datenbank auf den vorherigen (ursprünglichen) S0-Wert zurück. Wenn Ihre Datenbank einfach ist, können Sie später im Portal ein Upgrade von S0 auf Basis durchführen.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDBNEWname -ServerName $Database.ServerName -Edition $PITRedition -RequestedServiceObjectiveName $PITRNEWSLO -MaxSizeBytes 10737418240”

7 – Der letzte Code fügt die wiederhergestellte Datenbank der Failover-Gruppe hinzu, die bereits den ursprünglichen Namen hat (da wir ihn im vorherigen Code geändert haben).

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $TargetDBNEWname | Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -FailoverGroupName $removedbfromfgDB”

Sie können erwägen, den Parameter „-ErrorAction Stop“ nach dem Befehl hinzuzufügen. Dadurch wird verhindert, dass die folgenden Befehle im Fehlerfall ausgeführt werden und es zu keinem Schneeballeffekt kommt.

Außerdem können Sie Get-Date am Anfang und Ende des Skripts hinzufügen, um die Ausführungszeit zu berechnen. In meinem Fall wurde eine Datenbank von etwa 3,3 GB durch ein solches Skript in weniger als 6 Minuten wiederhergestellt.

Wenn Sie möchten, können Sie das Skript sicherlich optimieren, es über Azure DevOps hinzufügen, die Anzahl der Variablen reduzieren oder etwas fest codieren, aber ich habe versucht, es so detailliert wie möglich und für jeden verständlich zu beschreiben.

Besondere Aufmerksamkeit verdienen die Datenbanküberwachung auf Azure und die Möglichkeit der Integration mit verschiedenen Systemen wie Datadog. Die Überwachung ist recht praktisch, aber nicht ohne Nuancen (zum Zeitpunkt des Schreibens konnten schreibgeschützte Benutzer beispielsweise nur die Überwachung für eine Datenbank sehen, nicht für alle auf einmal ... nun, hier sind die Nuancen).

Zusammenfassend lässt sich sagen, dass unser Team die Ausgaben erfolgreich optimiert und gleichzeitig Bedenken im Zusammenhang mit Aktualisierungen und der Einstellung des Supports ausgeräumt hat. Wir haben Verbesserungen bei Leistung, Belastbarkeit, Entwicklungsgeschwindigkeit und Flexibilität erzielt. Darüber hinaus hat die Implementierung von Skripten unsere Fähigkeit, bei Bedarf schnell wiederherzustellen, erheblich verbessert.

Geschrieben von Pavel Shapurau, leitender DevOps-Ingenieur bei der Social Discovery Group.