Verbindungsarchitektur in Azure Database for MariaDB
Wichtig
Azure Database for MariaDB wird demnächst eingestellt. Wir empfehlen Ihnen dringend, zu Azure Database for MySQL zu migrieren. Weitere Informationen zum Migrieren nach Azure Database for MySQL finden Sie unter Was geschieht mit Azure Database for MariaDB?.
In diesem Artikel wird die Verbindungsarchitektur von Azure Database for MariaDB beschrieben, und Sie erfahren, wie Datenverkehr von Clients innerhalb und außerhalb von Azure an Ihre Azure Database for MariaDB-Instanz weitergeleitet wird.
Verbindungsarchitektur
Die Verbindung mit Ihrer Azure Database for MariaDB-Instanz wird über ein Gateway hergestellt, das eingehende Verbindungen an den physischen Ort weiterleitet, an dem sich Ihr Server in unseren Clustern befindet. Das folgende Diagramm veranschaulicht den Datenverkehrsfluss.
Wenn der Client eine Verbindung mit der Datenbank herstellt, wird die Verbindungszeichenfolge für den Server in die Gateway-IP-Adresse aufgelöst. Das Gateway lauscht an Port 3306 auf die IP-Adresse. Innerhalb des Datenbankclusters wird der Datenverkehr an die entsprechende Azure Database for MariaDB-Instanz weitergeleitet. Für die Verbindungsherstellung mit Ihrem Server (etwa von Unternehmensnetzwerken aus) muss daher die clientseitige Firewall geöffnet werden, damit ausgehender Datenverkehr unsere Gateways erreichen kann. Weiter unten finden Sie eine vollständige, nach Region aufgeschlüsselte Liste der IP-Adressen, die von unseren Gateways verwendet werden.
IP-Adressen des Azure Database for MariaDB-Gateways
Der Gatewaydienst wird in einer Gruppe von zustandslosen Serverknoten gehostet, deren IP-Adresse der Client beim Herstellen einer Verbindung mit einem Azure Database for MariaDB-Server zuerst erreichen würde.
Im Rahmen der kontinuierlichen Dienstwartung wird die Computehardware, auf der die Gateways gehostet werden, regelmäßig aktualisiert, um eine möglichst sichere und leistungsfähige Umgebung bereitzustellen. Bei einer Aktualisierung der Gatewayhardware wird zuerst ein neuer Ring von Serverknoten erstellt. Dieser neue Ring dient dem Datenverkehr für alle neu erstellten Azure Database for MariaDB-Server. Er verfügt über eine andere IP-Adresse als frühere Gatewayringe in derselben Region, damit der Datenverkehr unterschieden werden kann. Sobald der neue Ring voll funktionsfähig ist, wird für die ältere Gatewayhardware, die für die vorhandenen Server genutzt wurde, die Außerbetriebnahme geplant. Kunden, die ihre Server auf der Gatewayhardware ausführen und eine Verbindung mit älteren Gatewayringen herstellen, werden drei Monate vor der Außerbetriebnahme der Gatewayhardware per E-Mail und im Azure-Portal benachrichtigt. Die Außerbetriebnahme von Gateways kann sich in den folgenden Fällen auf die Konnektivität Ihrer Server auswirken:
- Sie codieren die Gateway-IP-Adressen fest in die Verbindungszeichenfolgen Ihrer Anwendung ein. Dies wird nicht empfohlen. Sie sollten den vollqualifizierten Domänennamen (FQDN) Ihres Servers im Format
<servername>.mariadb.database.azure.comin der Verbindungszeichenfolge für Ihre Anwendung verwenden. - Sie aktualisieren die neueren Gateway-IP-Adressen nicht in der clientseitigen Firewall, sodass ausgehender Datenverkehr die neuen Gatewayringe nicht erreichen kann.
Wichtig
Wenn der Kundenkonnektivitätsstapel anstelle des empfohlenen DNS-Namensansatzes eine direkte Verbindung mit dem Gateway oder dem Gateway in den Firewallregeln für Verbindungen zu\von der Kundeninfrastruktur herstellen muss, empfehlen wir Kunden dringend, Gateway-IP-Adresssubnetze zu verwenden, anstatt statische IP-Adressen zu codieren, damit diese Aktivität in einer Region, die dazu führen kann, dass sich die IP-Adresse innerhalb des Subnetzbereichs ändert, nicht beeinträchtigt wird.
Die folgende Tabelle enthält die Gateway-IP-Adressen des Azure Database for MariaDB-Gateways für alle Datenregionen. In dieser Tabelle werden immer die aktuellsten Informationen zu den Gateway-IP-Adressen für die einzelnen Regionen aufgeführt. Die Spalten in der folgenden Tabelle stellen Folgendes dar:
- Gateway-IP-Adresssubnetze: In dieser Spalte werden die IP-Adresssubnetze der Gatewayringe aufgelistet, die sich in der jeweiligen Region befinden. Da ältere Gatewayhardware eingestellt wird, wird empfohlen, die clientseitige Firewall zu öffnen, um ausgehenden Datenverkehr für die IP-Adresssubnetze in der Region zuzulassen, die Sie betreiben.
- Gateway-IP-Adressen: In regelmäßigen Abständen werden einzelne Gateway-IP-Adressen eingestellt, und Datenverkehr wird zu entsprechenden Gateway-IP-Adresssubnetzen migriert.
Wir empfehlen unseren Kunden dringend, sich nicht mehr auf einzelne Gateway-IP-Adressen zu verlassen (da diese in Zukunft nicht mehr verwendet werden). Stattdessen kann der Netzwerkverkehr sowohl die einzelnen Gateway-IP-Adressen als auch die Gateway-IP-Adressensubnetze in einer Region erreichen.
| Regionsname | Aktuelle Gateway-IP-Adresse | Gateway-IP-Adresssubnetze |
|---|---|---|
| Australien, Mitte | 20.36.105.32 | 20.36.105.32/29, 20.53.48.96/27 |
| Australien, Mitte 2 | 20.36.113.32 | 20.36.113.32/29, 20.53.56.32/27 |
| Australien (Osten) | 13.70.112.32 | 13.70.112.32/29, 40.79.160.32/29, 40.79.168.32/29, 40.79.160.32/29, 20.53.46.128/27 |
| Australien, Südosten | 13.77.49.33 | 13.77.49.32/29, 104.46.179.160/27 |
| Brasilien Süd | 191.233.201.8, 191.233.200.16 | 191.234.153.32/27, 191.234.152.32/27, 191.234.157.136/29, 191.233.200.32/29, 191.234.144.32/29, 191.234.142.160/27 |
| Brasilien, Südosten | 191.233.48.2 | 191.233.48.32/29, 191.233.15.160/27 |
| Kanada, Mitte | 13.71.168.32 | 13.71.168.32/29, 20.38.144.32/29, 52.246.152.32/29, 20.48.196.32/27 |
| Kanada, Osten | 40.69.105.32 | 40.69.105.32/29, 52.139.106.192/27 |
| USA (Mitte) | 52.182.136.37, 52.182.136.38 | 104.208.21.192/29, 13.89.168.192/29, 52.182.136.192/29, 20.40.228.128/27 |
| China, Osten | 52.130.112.139 | 52.130.112.136/29, 52.130.13.96/27 |
| China, Osten 2 | 40.73.82.1, 52.130.120.89 | 52.130.120.88/29, 52.130.7.0/27 |
| China, Norden | 52.130.128.89 | 52.130.128.88/29, 40.72.77.128/27 |
| China, Norden 2 | 40.73.50.0 | 52.130.40.64/29, 52.130.21.160/27 |
| Asien, Osten | 13.75.33.20, 13.75.33.21 | 20.205.77.176/29, 20.205.83.224/29, 20.205.77.200/29, 13.75.32.192/29, 13.75.33.192/29, 20.195.72.32/27 |
| USA, Osten | 40.71.8.203, 40.71.83.113 | 20.42.65.64/29, 20.42.73.0/29, 52.168.116.64/29, 20.62.132.160/27 |
| USA (Ost) 2 | 52.167.105.38, 40.70.144.38 | 104.208.150.192/29, 40.70.144.192/29, 52.167.104.192/29, 20.62.58.128/27 |
| Frankreich, Mitte | 40.79.129.1 | 40.79.128.32/29, 40.79.136.32/29, 40.79.144.32/29, 20.43.47.192/27 |
| Frankreich, Süden | 40.79.176.40 | 40.79.176.40/29, 40.79.177.32/29, 52.136.185.0/27 |
| Deutschland, Norden | 51.116.56.0 | 51.116.57.32/29, 51.116.54.96/27 |
| Deutschland, Westen-Mitte | 51.116.152.0 | 51.116.152.32/29, 51.116.240.32/29, 51.116.248.32/29, 51.116.149.32/27 |
| Indien, Mitte | 20.192.96.33 | 40.80.48.32/29, 104.211.86.32/29, 20.192.96.32/29, 20.192.43.160/27 |
| Indien (Süden) | 40.78.192.32 | 40.78.192.32/29, 40.78.193.32/29, 52.172.113.96/27 |
| Indien, Westen | 104.211.144.32 | 104.211.144.32/29, 104.211.145.32/29, 52.136.53.160/27 |
| Japan, Osten | 40.79.184.8, 40.79.192.23 | 13.78.104.32/29, 40.79.184.32/29, 40.79.192.32/29, 20.191.165.160/27 |
| Japan, Westen | 40.74.96.6 | 20.18.179.192/29, 40.74.96.32/29, 20.189.225.160/27 |
| Jio Indien, Mitte | 20.192.233.32 | 20.192.233.32/29, 20.192.48.32/27 |
| Jio Indien, Westen | 20.193.200.32 | 20.193.200.32/29, 20.192.167.224/27 |
| Korea, Mitte | 52.231.17.13 | 20.194.64.32/29, 20.44.24.32/29, 52.231.16.32/29, 20.194.73.64/27 |
| Korea, Süden | 52.231.145.3 | 52.231.151.96/27, 52.231.151.88/29, 52.231.145.0/29, 52.147.112.160/27 |
| USA Nord Mitte | 52.162.104.35, 52.162.104.36 | 52.162.105.200/29, 20.125.171.192/29, 52.162.105.192/29, 20.49.119.32/27 |
| Nordeuropa | 52.138.224.6, 52.138.224.7 | 13.69.233.136/29, 13.74.105.192/29, 52.138.229.72/29, 52.146.133.128/27 |
| Norwegen, Osten | 51.120.96.0 | 51.120.208.32/29, 51.120.104.32/29, 51.120.96.32/29, 51.120.232.192/27 |
| Norwegen, Westen | 51.120.216.0 | 51.120.217.32/29, 51.13.136.224/27 |
| Südafrika, Norden | 102.133.152.0 | 102.133.120.32/29, 102.133.152.32/29, 102.133.248.32/29, 102.133.221.224/27 |
| Südafrika, Westen | 102.133.24.0 | 102.133.25.32/29, 102.37.80.96/27 |
| USA Süd Mitte | 20.45.120.0 | 20.45.121.32/29, 20.49.88.32/29, 20.49.89.32/29, 40.124.64.136/29, 20.65.132.160/27 |
| Südostasien | 23.98.80.12, 40.78.233.2 | 13.67.16.192/29, 23.98.80.192/29, 40.78.232.192/29, 20.195.65.32/27 |
| Schweden, Mitte | 51.12.96.32 | 51.12.96.32/29, 51.12.232.32/29, 51.12.224.32/29, 51.12.46.32/27 |
| Schweden, Süden | 51.12.200.32 | 51.12.201.32/29, 51.12.200.32/29, 51.12.198.32/27 |
| Schweiz, Norden | 51.107.56.0 | 51.107.56.32/29, 51.103.203.192/29, 20.208.19.192/29, 51.107.242.32/27 |
| Schweiz, Westen | 51.107.152.0 | 51.107.153.32/29, 51.107.250.64/27 |
| VAE, Mitte | 20.37.72.64 | 20.37.72.96/29, 20.37.73.96/29, 20.37.71.64/27 |
| Vereinigte Arabische Emirate, Norden | 65.52.248.0 | 20.38.152.24/29, 40.120.72.32/29, 65.52.248.32/29, 20.38.143.64/27 |
| UK, Süden | 51.105.64.0 | 51.105.64.32/29, 51.105.72.32/29, 51.140.144.32/29, 51.143.209.224/27 |
| UK, Westen | 51.140.208.98 | 51.140.208.96/29, 51.140.209.32/29, 20.58.66.128/27 |
| USA, Westen-Mitte | 13.71.193.34 | 13.71.193.32/29, 20.69.0.32/27 |
| Europa, Westen | 13.69.105.208,104.40.169.187 | 104.40.169.32/29, 13.69.112.168/29, 52.236.184.32/29, 20.61.99.192/27 |
| USA (Westen) | 13.86.216.212, 13.86.217.212 | 20.168.163.192/29, 13.86.217.224/29, 20.66.3.64/27 |
| USA, Westen 2 | 13.66.136.192 | 13.66.136.192/29, 40.78.240.192/29, 40.78.248.192/29, 20.51.9.128/27 |
| USA, Westen 3 | 20.150.184.2 | 20.150.168.32/29, 20.150.176.32/29, 20.150.184.32/29, 20.150.241.128/27 |
Verbindungsumleitung
Azure Database for MariaDB unterstützt eine weitere Verbindungsrichtlinie: die Umleitung, mit der die Netzwerklatenz zwischen Clientanwendungen und MariaDB-Servern reduziert werden kann. Bei diesem Feature gibt der Server die Back-End-Adresse des Knotens, auf dem der MariaDB-Server gehostet wird, an den Client zurück, nachdem die erste TCP-Sitzung mit dem Azure Database for MariaDB-Server eingerichtet wurde. Anschließend werden alle nachfolgenden Pakete direkt an den Server übertragen, wobei das Gateway umgangen wird. Wenn Pakete direkt an den Server übertragen werden, wird die Leistung von Latenz und Durchsatz verbessert.
Dieses Feature wird von Azure Database for MariaDB-Servern mit den Engine-Versionen 10.2 und 10.3 unterstützt.
Die Umleitungsunterstützung steht in der von Microsoft entwickelten Erweiterung PHP mysqlnd_azure und in PECL zur Verfügung. Weitere Informationen zur Verwendung der Umleitung in Ihren Anwendungen finden Sie im Artikel Konfigurieren der Umleitung.
Wichtig
Die Umleitungsunterstützung in der PHP-Erweiterung mysqlnd_azure befindet sich derzeit in der Vorschauphase.
Häufig gestellte Fragen
Was müssen Sie über diese geplante Wartung wissen?
Es handelt sich um eine reine DNS-Änderung. Damit ist die Wartung transparent für Clients. Während die IP-Adresse für den vollqualifizierten Domänennamen im DNS-Server geändert wird, wird der lokale DNS-Cache innerhalb von fünf Minuten aktualisiert. Dieser Vorgang wird automatisch vom Betriebssystem ausgeführt. Nach der Aktualisierung des lokalen DNS erfolgen alle neuen Verbindungen mit der neuen IP-Adresse. Für alle vorhandenen Verbindungen wird die alte IP-Adresse ohne Unterbrechung beibehalten, bis die Außerbetriebnahme der alten Adressen vollständig abgeschlossen ist. Es dauert etwa drei bis vier Wochen, bis die alte IP-Adresse vollständig außer Betrieb gesetzt ist. Daher sollte dies keine Auswirkung auf die Clientanwendungen haben.
Was wird außer Betrieb gesetzt?
Nur Gatewayknoten werden außer Betrieb gesetzt. Wenn Benutzer eine Verbindung mit Servern herstellen, ist der Gatewayknoten das erste Ziel der Verbindung. Von dort aus wird sie an den Server weitergeleitet. Alte Gatewayringe (keine Mandantenringe, in denen Server ausgeführt werden) werden außer Betrieb gesetzt. Weitere Informationen finden Sie unter Verbindungsarchitektur.
Wie können Sie überprüfen, ob Ihre Verbindungen an alte oder neue Gatewayknoten geleitet werden?
Pingen Sie den vollqualifizierten Domänennamen Ihres Servers, z. B. ping xxx.mariadb.database.azure.com. Wenn die zurückgegebene IP-Adresse in der Tabelle oben in diesem Dokument unter „Gateway-IP-Adressen (Außerbetriebnahme)“ aufgeführt ist, bedeutet das, dass Ihre Verbindung das alte Gateway verwendet. Wenn Ihre IP-Adresse jedoch unter „Gateway-IP-Adressen“ aufgeführt wird, bedeutet dies, dass Ihre Verbindung über das neue Gateway führt.
Sie können auch per PSPing oder TCPPing den Datenbankserver von Ihrer Clientanwendung aus über Port 3306 testen und sich vergewissern, dass die zurückgegebene IP-Adresse nicht zu den Adressen gehört, die außer Betrieb gesetzt werden.
Woher weiß ich, wann die Wartung abgeschlossen ist, und erhalte ich eine Benachrichtigung, wenn alte IP-Adressen außer Betrieb gesetzt wurden?
Sie werden per E-Mail darüber informiert, wann der Wartungsprozess gestartet wird. Die Wartung kann bis zu einen Monat dauern, je nachdem, wie viele Server wir in allen Regionen migrieren müssen. Bereiten Sie Ihren Client darauf vor, die Verbindung zum Datenbankserver über den vollqualifizierten Domänennamen oder über die neue IP-Adresse (siehe Tabelle oben) herzustellen.
Was kann ich tun, wenn meine Clientanwendungen weiterhin eine Verbindung mit dem alten Gatewayserver herstellen?
Dies ist ein Hinweis darauf, dass Ihre Anwendungen eine statische IP-Adresse anstelle des vollqualifizierten Domänennamens verwenden, um eine Verbindung mit dem Server herzustellen. Überprüfen Sie die Verbindungszeichenfolgen, die Einstellungen des Verbindungspools, die AKS-Einstellungen und ggf. sogar den Quellcode.
Gibt es Auswirkungen auf meine Anwendungsverbindungen?
Diese Wartungsmaßnahme ist nur eine DNS-Änderung und damit transparent für den Client. Sobald der DNS-Cache im Client aktualisiert ist (erfolgt automatisch über das Betriebssystem), werden alle neuen Verbindungen über die neue IP-Adresse hergestellt. Alle bestehenden Verbindungen funktionieren weiterhin, bis die alte IP-Adresse vollständig außer Betrieb gesetzt wurde. Das erfolgt einige Wochen später. Wiederholungslogik ist hierbei zwar nicht erforderlich, es ist aber dennoch empfehlenswert, sie für die Anwendung zu konfigurieren. Verwenden Sie zum Herstellen der Verbindung mit dem Datenbankserver den vollqualifizierten Domänennamen in die Verbindungszeichenfolge Ihrer Anwendung. Durch diesen Wartungsvorgang werden bestehende Verbindungen nicht gelöscht. Der Vorgang sorgt nur dafür, dass neue Verbindungsanforderungen an den neuen Gatewayring geleitet werden.
Kann ich ein bestimmtes Zeitfenster für die Wartung anfordern?
Da die Migration transparent ist und sich nicht auf die Konnektivität auf Kundenseite auswirkt, ist davon auszugehen, dass für die meisten Benutzer keinerlei Probleme entstehen. Überprüfen Sie Ihre Anwendung proaktiv, und vergewissern Sie sich, dass entweder der vollqualifizierte Domänenname für die Verbindung mit dem Datenbankserver verwendet wird oder die neuen Gateway-IP-Adressen in Ihrer Verbindungszeichenfolge enthalten sind.
Ich verwende eine private Verbindung. Sind meine Verbindungen betroffen?
Nein. Hierbei geht es um die Außerbetriebnahme von Gatewayhardware. Dies steht in keiner Beziehung zu privaten Verbindungen oder privaten IP-Adressen. Es sind nur öffentliche IP-Adressen betroffen, die unter „Gateway-IP-Adressen (Außerbetriebnahme)“ aufgeführt sind.