Architecture de connectivité dans Azure Database pour MySQL

S’APPLIQUE À : Azure Database pour MySQL - Serveur unique

Important

Le serveur unique Azure Database pour MySQL est en voie de mise hors service. Nous vous conseillons vivement de procéder à une mise à niveau vers Azure Database pour MySQL – Serveur flexible. Pour obtenir plus d’informations sur la migration vers Azure Database pour MySQL – Serveur flexible, consultez Qu’en est-il du Serveur unique Azure Database pour MySQL ?

Cet article présente l’architecture de connectivité d’Azure Database pour MySQL, ainsi que la façon dont le trafic est dirigé vers l’instance Azure Database pour MySQL des clients dans Azure et en dehors.

Architecture de connectivité

La connexion à l’instance Azure Database pour MySQL est établie via une passerelle qui est responsable du routage des connexions entrantes vers l’emplacement physique de votre serveur dans nos clusters. Le schéma suivant illustre le flux de trafic.

Overview of the connectivity architecture

Lorsque le client se connecte à la base de données, la chaîne de connexion au serveur correspond à l’adresse IP de la passerelle. La passerelle écoute sur l’adresse IP sur le port 3306. À l’intérieur du cluster de bases de données, le trafic est transféré vers l’instance Azure Database pour MySQL appropriée. Par conséquent, pour vous connecter à votre serveur, notamment à partir de réseaux d’entreprise, il est nécessaire d’ouvrir le pare-feu côté client pour autoriser le trafic sortant à atteindre nos passerelles. Vous trouverez ci-dessous une liste complète des adresses IP utilisées par nos passerelles en fonction de la région.

Adresses IP de passerelle Azure Database pour MySQL

Le service de passerelle est hébergé sur un groupe de nœuds de calcul sans état situé derrière une adresse IP, que votre client doit atteindre en premier lors de la tentative de connexion à un serveur Azure Database pour MySQL.

Dans le cadre de la maintenance de service en cours, nous allons actualiser régulièrement le matériel de calcul hébergeant les passerelles pour nous assurer que nous proposons l’expérience la plus sûre et la plus performante. Lorsque le matériel de passerelle est actualisé, un nouvel anneau des nœuds de calcul est créé en premier. Ce nouvel anneau gère le trafic pour tous les serveurs Azure Database pour MySQL nouvellement créés. Il a une adresse IP différente des anneaux de passerelle plus anciens dans la même région pour différencier le trafic. Une fois que le nouvel anneau est entièrement fonctionnel, la mise hors service de l’ancien matériel de passerelle desservant les serveurs existants est planifiée. Avant de mettre hors service un matériel de passerelle, les clients qui exécutent leurs serveurs et se connectent à des anneaux de passerelle plus anciens sont avertis par e-mail et dans le portail Azure. La mise hors service des passerelles peut avoir un impact sur la connectivité de vos serveurs si

  • Vous codez en dur les adresses IP de la passerelle dans la chaîne de connexion de votre application. Cela n’est pas recommandé. Vous devez utiliser un nom de domaine complet (FQDN) de votre serveur au format <servername>.mysql.database.azure.com dans la chaîne de connexion de votre application.
  • Vous ne mettez pas à jour les adresses IP de passerelle les plus récentes dans le pare-feu côté client pour autoriser le trafic sortant à atteindre nos nouveaux anneaux de passerelle.

Important

Si la pile de connectivité client doit se connecter directement à la passerelle au lieu de l’approche de nom DNS recommandée, ou si la passerelle de liste verte dans les règles de pare-feu pour les connexions à l’infrastructure cliente, nous encourageons fortement les clients à utiliser l’adresse IP de passerelle sous-réseaux par rapport à l’adresse IP statique de codage en dur afin de ne pas être affectés par cette activité dans une région qui peut être susceptible d’être affectée par cette activité. entraîne la modification de l’adresse IP dans la plage de sous-réseaux.

Le tableau suivant répertorie les adresses IP de la passerelle Azure Database pour MySQL pour toutes les régions de données. Les informations les plus récentes des adresses IP de la passerelle pour chaque région sont indiquées dans le tableau ci-dessous. Dans le tableau ci-dessous, les colonnes représentent les éléments suivants :

  • Sous-réseaux d’adresses IP de passerelle : Cette colonne liste les sous-réseaux d’adresses IP des anneaux de passerelle situés dans la région particulière. Lorsque nous mettons hors service le matériel de passerelle plus ancien, nous vous recommandons d’ouvrir le pare-feu côté client pour autoriser le trafic sortant pour les sous-réseaux d’adresses IP dans la région que vous utilisez.
  • Adresses IP de passerelle : régulièrement, les adresses IP de passerelle individuelles seront mises hors service et le trafic sera migré vers les sous-réseaux d’adresse IP de passerelle correspondants.

Nous encourageons vivement les clients à cesser de dépendre de toute adresse IP de passerelle individuelle (car celles-ci seront supprimées à l’avenir). À défaut, permettez au trafic réseau d’atteindre à la fois les adresses IP de passerelle individuelles et les sous-réseaux d’adresses IP de passerelle dans une région donnée.

Nom de la région Adresse IP de la passerelle actuelle Sous-réseaux d’adresses IP de la passerelle
Centre de l’Australie 20.36.105.32 20.36.105.32/29, 20.53.48.96/27
Australie Centre 2 20.36.113.32 20.36.113.32/29, 20.53.56.32/27
Australie Est 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
Sud-Est de l’Australie 13.77.49.33 13.77.49.32/29, 104.46.179.160/27
Brésil Sud 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
Brésil Sud-Est 191.233.48.2 191.233.48.32/29, 191.233.15.160/27
Centre du Canada 13.71.168.32 13.71.168.32/29, 20.38.144.32/29, 52.246.152.32/29, 20.48.196.32/27
Est du Canada 40.69.105.32 40.69.105.32/29, 52.139.106.192/27
USA Centre 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
Chine orientale 52.130.112.139 52.130.112.136/29, 52.130.13.96/27
Chine orientale 2 40.73.82.1, 52.130.120.89 52.130.120.88/29, 52.130.7.0/27
Chine du Nord 52.130.128.89 52.130.128.88/29, 40.72.77.128/27
Chine Nord 2 40.73.50.0 52.130.40.64/29, 52.130.21.160/27
Asie Est 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 Est 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 Est 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
France Centre 40.79.129.1 40.79.128.32/29, 40.79.136.32/29, 40.79.144.32/29, 20.43.47.192/27
France Sud 40.79.176.40 40.79.176.40/29, 40.79.177.32/29, 52.136.185.0/27
Allemagne Nord 51.116.56.0 51.116.57.32/29, 51.116.54.96/27
Allemagne Centre-Ouest 51.116.152.0 51.116.152.32/29, 51.116.240.32/29, 51.116.248.32/29, 51.116.149.32/27
Inde centrale 20.192.96.33 40.80.48.32/29, 104.211.86.32/29, 20.192.96.32/29, 20.192.43.160/27
Inde Sud 40.78.192.32 40.78.192.32/29, 40.78.193.32/29, 52.172.113.96/27
Inde Ouest 104.211.144.32 104.211.144.32/29, 104.211.145.32/29, 52.136.53.160/27
Japon Est 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
OuJapon Est 40.74.96.6 20.18.179.192/29, 40.74.96.32/29, 20.189.225.160/27
JIO Inde Centre 20.192.233.32 20.192.233.32/29, 20.192.48.32/27
Inde Ouest Jio 20.193.200.32 20.193.200.32/29, 20.192.167.224/27
Centre de la Corée 52.231.17.13 20.194.64.32/29, 20.44.24.32/29, 52.231.16.32/29, 20.194.73.64/27
Corée du Sud 52.231.145.3 52.231.151.96/27, 52.231.151.88/29, 52.231.145.0/29, 52.147.112.160/27
Centre-Nord des États-Unis 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
Europe Nord 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
Norvège Est 51.120.96.0 51.120.208.32/29, 51.120.104.32/29, 51.120.96.32/29, 51.120.232.192/27
Norvège Ouest 51.120.216.0 51.120.217.32/29, 51.13.136.224/27
Afrique du Sud Nord 102.133.152.0 102.133.120.32/29, 102.133.152.32/29, 102.133.248.32/29, 102.133.221.224/27
Afrique du Sud Ouest 102.133.24.0 102.133.25.32/29, 102.37.80.96/27
États-Unis - partie centrale méridionale 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
Asie Sud-Est 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
Suède Centre 51.12.96.32 51.12.96.32/29, 51.12.232.32/29, 51.12.224.32/29, 51.12.46.32/27
Suède Sud 51.12.200.32 51.12.201.32/29, 51.12.200.32/29, 51.12.198.32/27
Suisse Nord 51.107.56.0 51.107.56.32/29, 51.103.203.192/29, 20.208.19.192/29, 51.107.242.32/27
Suisse Ouest 51.107.152.0 51.107.153.32/29, 51.107.250.64/27
Émirats arabes unis Centre 20.37.72.64 20.37.72.96/29, 20.37.73.96/29, 20.37.71.64/27
Émirats arabes unis Nord 65.52.248.0 20.38.152.24/29, 40.120.72.32/29, 65.52.248.32/29, 20.38.143.64/27
Sud du Royaume-Uni 51.105.64.0 51.105.64.32/29, 51.105.72.32/29, 51.140.144.32/29, 51.143.209.224/27
Ouest du Royaume-Uni 51.140.208.98 51.140.208.96/29, 51.140.209.32/29, 20.58.66.128/27
Centre-USA Ouest 13.71.193.34 13.71.193.32/29, 20.69.0.32/27
Europe Ouest 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 Ouest 13.86.216.212, 13.86.217.212 20.168.163.192/29, 13.86.217.224/29, 20.66.3.64/27
USA Ouest 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 Ouest 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

Redirection de connexion

Azure Database pour MySQL prend en charge une stratégie de connexion supplémentaire, redirection qui permet de réduire la latence réseau entre les applications clientes et les serveurs MySQL. Avec la redirection, une fois la session TCP initiale établie sur le serveur Azure Database pour MySQL, le serveur renvoie au client l'adresse principale du nœud qui héberge le serveur MySQL. Par la suite, les paquets suivants sont directement acheminés vers le serveur, en ignorant la passerelle. Étant donné que les paquets vont directement au serveur, la latence et le débit améliorent les performances.

Cette fonctionnalité est prise en charge dans les serveurs Azure Database pour MySQL avec les versions 5.7 et 8.0 du moteur.

La prise en charge de la redirection est disponible dans l’extension PHP mysqlnd_azure, développée par Microsoft et est disponible sur PECL. Pour plus d’informations sur l’utilisation de la redirection dans vos applications, consultez l’article configuration de la redirection.

Important

La prise en charge de la redirection dans l’extension mysqlnd_azure PHP est actuellement disponible en préversion.

Forum aux questions

Que devez-vous savoir sur cette maintenance planifiée ?

Il s'agit simplement d'un changement de DNS ; elle est donc transparente pour les clients. Bien que l’adresse IP du nom de domaine complet soit modifiée dans le serveur DNS, le cache DNS local est actualisé dans les 5 minutes, et il est automatiquement effectué par les systèmes d’exploitation. Après l'actualisation du DNS local, toutes les nouvelles connexions s'effectuent avec la nouvelle adresse IP et toutes les connexions existantes sont maintenues avec l'ancienne adresse IP (jusqu'à la mise hors service complète des anciennes adresses IP). La mise hors service de l'ancienne adresse IP intervient dans les trois à quatre semaines ; elle ne doit donc avoir aucun effet sur les applications clientes.

Que mettons-nous hors service ?

Seuls les nœuds de passerelle sont mis hors service. Lorsque les utilisateurs se connectent à leurs serveurs, le premier arrêt de la connexion s'effectue au niveau du nœud de passerelle, avant que la connexion ne soit transférée vers le serveur. Nous mettons hors service les anciens anneaux de passerelle (et non les anneaux de locataire sur lesquels le serveur est en cours d'exécution). Pour plus de précisions, reportez-vous à l'architecture de connectivité.

Comment déterminer si vos connexions sont dirigées vers d'anciens ou de nouveaux nœuds de passerelle ?

Effectuez un test ping sur le nom de domaine complet de votre serveur, par exemple ping xxx.mysql.database.azure.com. Si l'adresse IP renvoyée est l'une de celles qui sont répertoriées sous Adresses IP de passerelle (en cours de mise hors service) dans le document ci-dessus, cela signifie que votre connexion passe par l'ancienne passerelle. En revanche, si l’adresse IP retournée est l’une des adresses IP répertoriées sous adresses IP de passerelle, cela signifie que votre connexion passe par la nouvelle passerelle.

Vous pouvez également effectuer un test PSPing ou TCPPing sur le serveur de base de données à partir de votre application cliente avec le port 3306 et vous assurer que l’adresse IP renvoyée ne correspond pas à l'une des adresses IP en cours de mise hors service.

Comment savoir quand la maintenance est terminée ? Et recevrai-je une autre notification lorsque les anciennes adresses IP seront mises hors service ?

Vous recevez un e-mail qui vous informe du début des travaux de maintenance. La maintenance peut prendre jusqu'à un mois en fonction du nombre de serveurs que nous devons migrer dans toutes les régions. Préparez votre client pour qu'il se connecte au serveur de base de données à l'aide du nom de domaine complet ou en utilisant la nouvelle adresse IP figurant dans le tableau ci-dessus.

Que dois-je faire si mes applications clientes se connectent toujours à l'ancien serveur de passerelle ?

Cela indique que vos applications se connectent au serveur en utilisant une adresse IP statique au lieu du nom de domaine complet. Examinez les chaînes de connexion et le paramètre de regroupement de connexions, le paramètre AKS, voire le code source.

Y a-t-il un impact sur les connexions de mes applications ?

Cette maintenance n'est qu'un changement de DNS ; elle est donc transparente pour le client. Une fois le cache DNS actualisé dans le client (automatiquement effectué par le système d’opération), toutes les nouvelles connexions se connectent à la nouvelle adresse IP et toutes les connexions existantes fonctionnent toujours correctement jusqu’à ce que l’ancienne adresse IP soit entièrement désactivée, ce qui se produit plusieurs semaines plus tard. Dans ce cas, la logique de nouvelle tentative n'est pas nécessaire. Cela dit, il est intéressant de savoir qu'elle a été configurée pour l'application. Utilisez le FQDN pour vous connecter au serveur de base de données dans la chaîne de connexion de votre application. Cette opération de maintenance ne supprime pas les connexions existantes. Elle se contente de diriger les nouvelles demandes de connexion vers le nouvel anneau de passerelle.

Puis-je demander une fenêtre de temps spécifique pour la maintenance ?

Étant donné que la migration doit être transparente et sans impact sur la connectivité du client, la plupart des utilisateurs ne devraient être confrontés à aucun problème. Examinez votre application de manière proactive, et veillez à utiliser le nom de domaine complet pour vous connecter au serveur de base de données ou à activer la liste des nouvelles « Adresses IP de passerelle » dans la chaîne de connexion de votre application.

Non, il s'agit d'une mise hors service du matériel de passerelle qui n'a aucun rapport avec les liaisons privées ou les adresses IP privées. Elle n'affectera que les adresses IP publiques mentionnées sous les adresses IP en cours de mise hors service.

Étapes suivantes