Azure Database for MySQL
In dieser Lerneinheit untersuchen Sie, wie Azure Database for MySQL Ihnen dabei helfen kann, einen resilienten, leistungsfähigen und einfach zu wartenden Datenspeicher für Ihre webbasierte App zu erstellen. In Anbetracht der zu erwartenden Geschäftskritikalität und der hohen Nachfrage sind Sie an der Fähigkeit interessiert, Rechen- und Speicherressourcen zu skalieren. Außerdem möchten Sie sicherstellen, dass Azure Database for MySQL als verwalteter Dienst den Verwaltungs- und Wartungsaufwand minimiert, sodass Sie sich stattdessen auf die Softwareentwicklung konzentrieren können.
Was sind die wichtigsten Eigenschaften von Azure Database for MySQL?
Azure Database for MySQL – Flexibler Server wurde für vollständige Kompatibilität mit Ihren bestehenden MySQL-Anwendungen entwickelt und unterstützt die weit verbreiteten MySQL Community Server-Versionen 5.7 und 8.0. Dieses Hosting ist besonders effektiv für Szenarios, die Folgendes erfordern:
- Differenzierte Kontrolle über die Compute- und Speicherkonfiguration
- Durchgängig hohe Leistung
- Zuverlässigkeit, Hochverfügbarkeit und Geschäftskontinuität
- Strategien für effizientes Kostenmanagement
Darüber hinaus verbessert Flexible Server dank der integrierten Firewall für öffentliche Endpunkte die Sicherheit und unterstützt private Konnektivität über eine Integration mit Azure Virtual Network (virtuelles Netzwerk) und Azure Private Link, die Ihre Daten vor unbefugtem Zugriff schützt.
Compute
Azure Database for MySQL – Flexibler Server ist in drei Computetarifen verfügbar, wobei jeder Tarif auf einen bestimmten Anwendungsfall ausgerichtet ist:
- Burstfähig: Ideal für die Entwicklung oder befristete Projekte mit unregelmäßigen Leistungsanforderungen
- Universell: Geeignet für eine breite Palette von Produktionsworkloads, die eine ausgewogene Compute- und Arbeitsspeicherressourcen erfordern
- Unternehmenskritisch: Am besten geeignet für Anwendungen, die eine hohe Computeleistung und Resilienz benötigen
Der genaue Name der Dienstebene leitet sich aus dem Seriennamen der Azure-VM-SKU ab, die die verwaltete MySQL Server-Bereitstellung hostet. Innerhalb der einzelnen Dienstebenen können Sie zwischen verschiedenen VM-Größen auswählen, die jeweils eine unterschiedliche Anzahl von virtuellen Kernen (von 1 bis 96) und eine unterschiedliche Menge an Arbeitsspeicher (von 4 GB bis etwa 700 GB) bieten.
Die Computeebene „Burstfähig“ verwendet VMs der B-Serie. „Universell“ basiert auf VMs der Dadsv5-Serie (AMD) und der Ddsv4-Serie (Intel) und „Unternehmenskritisch“ läuft auf VMs der Standard Eadsv5-Serie (AMD) und Edsv5-Serie (Intel).
Im Azure-Portal können Sie während der Servererstellung auf der Seite „Allgemeine Informationen“ unter „Details zum Server“ oder unter „Flexibler Server“ auf der Seite „Compute + Speicher“ unter „Rechnen“ die Dienstebenenoption auswählen.
Speicher
Bei der Bereitstellung eines Servers oder zu einem beliebigen anschließenden Zeitpunkt können Sie die Menge an zugewiesenem Speicherplatz bis auf 16.384 Gibibyte (GiB) erhöhen. Für die Dienstebenen „Burstfähig“ und „Universell“ beträgt der Grenzwert 16 Tebibyte (TiB) und für „Unternehmenskritisch“ 32 TiB. Der untere Grenzwert (20 GiB) ist unabhängig von der ausgewählten Computeebene und -größe identisch. Außerdem ist die Dimensionierung des Speichers nicht von der von Ihnen gewählten Computeebene und der Größe abhängig, und Sie können die automatische Vergrößerung des Speichers aktivieren.
Hinweis
Nachdem Sie die Speichergröße erhöht haben, können Sie sie nicht verringern.
Unabhängig von der Speichergröße können Sie auch den gewünschten Grenzwert für die E/A-Vorgänge pro Sekunde (IOPS) hoch- oder herunterskalieren. Die Obergrenze der verfügbaren IOPS hängt von der Computeebene und der Größe ab, wobei für die größte verfügbare Größe der SKU „Unternehmenskritisch“ 80.000 IOPS erreicht werden. Dank dieser Funktionalität für skalierbare IOPS können Sie jederzeit den dynamischen Ressourcenanforderungen gerecht werden und ermöglichen, dass IOPS basierend auf Workloadanforderungen automatisch angepasst und automatisch skaliert werden.
Netzwerkkonnektivität
Azure Database for MySQL – Flexibler Server unterstützt drei Verbindungsmethoden: den öffentlichen und den privaten Zugriff sowie Private Link.
Öffentlicher Zugriff
Bei öffentlichem Zugriff, der über einen externen Endpunkt bereitgestellt wird, müssen Sie den Zugriff explizit mithilfe von Firewallregeln zulassen:
- Für externen Datenverkehr müssen Sie eine einzelne IP-Adresse oder einen IP-Adressbereich angeben, von dem aus der Datenverkehr zugelassen wird.
- Für den von Azure ausgehenden Datenverkehr müssen Sie den öffentlichen Zugriff von jedem Azure-Dienst erlauben.
Wichtig
Da der öffentliche Zugriff Verbindungen von IP-Adressen zulässt, die beliebigen Azure-Ressourcen zugeordnet sind, einschließlich Verbindungen aus den Abonnements anderer Kunden, wird diese Option nur für Entwicklungs- und Testszenarios empfohlen.
Privater Zugriff
Verwenden Sie Unterstützung für die Integration virtueller Netzwerke für den privaten Zugriff über bestimmte virtuelle Azure-Netzwerke. Sie können den privaten Zugriff verwenden, um eine sichere Verbindung mit einem flexiblen MySQL-Server innerhalb desselben VNet, von einem anderen VNet mithilfe von Peering oder sogar über eine lokale Verbindung über eine ExpressRoute- oder VPN-Verbindung herzustellen. Wenn Sie diese Option aktivieren, blockiert der Server automatisch Verbindungen, die aus dem Internet stammen.
Hinweis
Bevor Sie den privaten Zugriff aktivieren, muss die Auflösung benutzerdefinierter DNS-Namen implementiert werden. Weitere Informationen finden Sie unter Privater Netzwerkzugriff mit der VNet-Integration für Azure Database for MySQL – Flexible Server.
Private Link
Private Link stellt einen privaten IP-Adressendpunkt in einem VNet-Subnetz bereit, um eine direkte Verbindung mit dem flexiblen MySQL-Server herzustellen. Azure Private Link bringt im Wesentlichen Azure-Dienste in Ihrem privaten VNet über eine IP-Adresse wie jede andere VNet-Ressource. Sie können mehrere private Endpunkte erstellen, z. B. eine pro Verbindungsanwendung oder Azure PaaS-Ressource. In Kombination mit NSG-Firewallregeln bieten private Links eine differenzierte Kontrolle darüber, welche Dienste auf die Datenbank zugreifen können.
Der Server erzwingt standardmäßig Transport Layer Security (TLS 1.2), um die im Netzwerk eingehende Kommunikation zu schützen.
Wichtig
Sie können unverschlüsselte Verbindungen nach der Serverbereitstellung zwar zulassen, dies wird jedoch nicht empfohlen.
Hochverfügbarkeit
Azure Database for MySQL – Flexibler Server unterstützt Hochverfügbarkeit mit automatischem Failover, um sicherzustellen, dass committete Daten aufgrund lokaler Fehler nie verloren gehen. Wenn Sie diese Funktionalität aktivieren, stellt die Plattform automatisch ein Standbyreplikat bereit und verwaltet dieses.
Je nach Platzierung des Replikats gibt es zwei Modelle der Hochverfügbarkeitsarchitektur.
Zonenredundante Hochverfügbarkeit
Um die Resilienz zu erhöhen, positioniert das zonenredundante Hochverfügbarkeitsmodell die primäre Datenbank in einer Verfügbarkeitszone und das Standbyreplikat in einer separaten Zone. Diese Konfiguration soll vor Rechenzentrumsfehlern schützen und bietet eine höhere Datenschutzgrad, indem sichergestellt wird, dass die primäre Datenbank und die Sicherungsdatenbank nicht den gleichen lokalen Risiken unterliegen. Dieses Modell wird für kritische Anwendungen empfohlen, bei denen Kontinuität und Datenintegrität von größter Bedeutung sind, da der Dienst auch dann verfügbar bleibt, wenn ein gesamtes Rechenzentrum offline ist.
Hochverfügbarkeit in gleicher Zone
Im Modell für Hochverfügbarkeit in gleicher Zone werden die primäre Datenbank und ihr Standbyreplikat innerhalb derselben Verfügbarkeitszone platziert. Eine Bereitstellung in derselben Zone ist für Szenarios von Vorteil, in denen minimale Latenz von entscheidender Bedeutung für die Anwendungsleistung ist. Durch die Bereitstellung der primären Instanz und des Replikats in unmittelbarer physischer Nähe wird sichergestellt, dass sich das Failover nicht erheblich auf die Reaktionszeiten auswirkt. Dieses Setup eignet sich ideal für Anwendungen, bei denen sich sogar minimale Latenzunterschiede auf Funktionalität oder Benutzererlebnis auswirken können.
Geschäftskontinuität
Azure Database for MySQL – Flexible Server erstellt automatisch Zeitpunktsicherungen von Datenbanken. Bei einer Langzeitaufbewahrung werden diese für bis zu 35 Tage oder 10 Jahre in lokal redundantem Speicher aufbewahrt. Beim Konfigurieren der Sicherung können Sie lokal redundante, zonenredundante oder georedundante Sicherungen auswählen, die Ihnen die Wiederherstellung nach Ausfällen ermöglicht, die sich auf eine gesamte Azure-Region auswirken. Darüber hinaus können Sie jederzeit On-Demand-Sicherungen ausführen, um eine Sicherungsmomentaufnahme außerhalb des regulären Sicherungszeitplans zu erstellen.
Azure Database for MySQL unterstützt auch verwaltete Wartungsfenster für automatisierte Serverpatches, was die Geschäftskontinuität erhöht. Indem Sie einen benutzerdefinierten Zeitplan für das Patchen angeben, können Sie die Auswirkungen einer vorübergehenden Downtime infolge eines Serverneustarts minimieren.
Kostenoptimierung
Azure Database for MySQL – Flexible Server bietet zahlreiche Optionen zur Kostenoptimierung.
Differenzierte Kontrolle über die Compute- und Speicherkonfiguration: Sie können die meisten Optionen für die Serverkonfiguration unabhängig voneinander anpassen, sodass Sie die Bereitstellungskosten auf der Grundlage Ihrer Ziele und des beabsichtigten Anwendungsfalls optimieren können. Folgende Optionen können Sie z. B. separat anpassen:
- Compute-SKU
- Speichermenge
- IOPS
- Aufbewahrungszeitraum für Sicherungen
Darüber hinaus können Sie die IOPS-Funktion der automatischen Skalierung aktivieren, um IOPS basierend auf den Anforderungen der Workload automatisch anzupassen. Im Gegensatz zu vorab bereitgestellten IOPS, bei denen ein fester IOPS-Grenzwert angegeben und unabhängig vom Verbrauch abgerechnet wird, bezahlen Sie bei automatisch skalierbaren IOPS nur für die tatsächlich verbrauchten E/A-Vorgänge.
Die Möglichkeit, den Server bei Bedarf zu beenden und zu starten: Die Abrechnung für die Computeebene wird beendet, sobald Sie den Server beenden. Dies kann helfen, Kosten während der Entwicklung, beim Testen und für Produktionsworkloads mit einem zuverlässig vorhersehbaren Zeitplan zu minimieren.
Die Computeebene „Burstfähig“: Nutzen Sie die Computeebene „Burstfähig“, um wettbewerbsfähige Preise für Workloads zu erhalten, die eine niedrige CPU-Auslastung mit gelegentlichen CPU-Auslastungsspitzen aufweisen.
Rabatt für reservierte Instanzen: Sie können sich für einen ein- oder dreijährigen erwerbsplan verpflichten, um den Rabatt für reservierte Instanzen zu erhalten, mit dem Sie mehr als 60 Prozent der ursprünglichen, nicht rabattierten Kosten sparen. Diese Option sollten Sie für Workloads mit vorhersehbaren, langfristigen Anforderungen an die Computekapazität in Betracht ziehen.
Ein kostenloses Azure-Konto: Sie können Flexible Server mit einem kostenloses Azure-Konto 12 Monate lang kostenlos testen. Dabei gelten die folgenden monatlichen Grenzwerte:
- 750 Stunden burstfähige B1MS-Instanz – genügend Stunden zur kontinuierlichen Ausführung einer Datenbankinstanz jeden Monat.
- 32-GB-Speicher und 32-GB-Sicherungsspeicher.
Hinweis
Wenn Sie eine Instanz von Azure Database for MySQL Flexible Server mit Ihrem kostenlosen Azure-Konto erstellen, werden weiterhin geschätzte monatliche Kosten auf dem Blatt Compute + Speicher: Kostenübersicht und auf der Registerkarte Überprüfen + Erstellen angezeigt. Solange Sie jedoch ein kostenloses Azure-Konto verwenden und Ihre Dienstnutzung innerhalb der zugehörigen monatlichen Grenzwerte bleibt, werden Ihnen für den Dienst keine Kosten in Rechnung gestellt.