Megosztás a következőn keresztül:


Kapcsolati architektúra az Azure Database for MySQL-ben

A következőkre vonatkozik: Azure Database for MySQL – Önálló kiszolgáló

Fontos

Az önálló Azure Database for MySQL-kiszolgáló a kivonási útvonalon van. Határozottan javasoljuk, hogy frissítsen rugalmas Azure Database for MySQL-kiszolgálóra. További információ a rugalmas Azure Database for MySQL-kiszolgálóra való migrálásról: Mi történik az önálló Azure Database for MySQL-kiszolgálóval?

Ez a cikk bemutatja az Azure Database for MySQL kapcsolati architektúráját, valamint azt, hogy a forgalom hogyan irányítja az Azure Database for MySQL-példányra az Azure-on belüli és kívüli ügyfelekről.

Kapcsolati architektúra

Az Azure Database for MySQL-hez való csatlakozás egy átjárón keresztül jön létre, amely felelős a bejövő kapcsolatok átirányításáért a kiszolgáló fizikai helyére a fürtökben.

Amikor az ügyfél csatlakozik az adatbázishoz, a kiszolgálóhoz kapcsolati sztring feloldja az átjáró IP-címét. Az átjáró a 3306-os porton figyeli az IP-címet. Az adatbázisfürtön belül a forgalom a megfelelő Azure Database for MySQL-hez lesz továbbítva. Ezért a kiszolgálóhoz, például a vállalati hálózatokról való csatlakozáshoz meg kell nyitni az ügyféloldali tűzfalat, hogy a kimenő forgalom elérhesse az átjárókat. Alább megtalálja az átjárók által régiónként használt IP-címek teljes listáját.

Azure Database for MySQL-átjáró IP-címei

Az átjárószolgáltatás egy IP-cím mögött található állapot nélküli számítási csomópontok csoportján fut, amelyeket az ügyfél először érne el, amikor egy Azure Database for MySQL-kiszolgálóhoz próbál csatlakozni.

A folyamatos szolgáltatáskarbantartás részeként rendszeresen frissítjük az átjárókat üzemeltető számítási hardvereket, hogy a lehető legbiztonságosabb és legkiszolgalóbb élményt biztosíthassuk. Az átjáró hardverének frissítésekor először a számítási csomópontok új gyűrűje jön létre. Ez az új gyűrű az újonnan létrehozott Azure Database for MySQL-kiszolgálók forgalmát szolgálja ki, és eltérő IP-címmel fog rendelkezni az ugyanabban a régióban lévő régebbi átjárók gyűrűitől, hogy megkülönböztetje a forgalmat. Miután az új gyűrű teljesen működőképes, a meglévő kiszolgálókat kiszolgáló régebbi átjáróhardverek leszerelését tervezik. Az átjáróhardverek leszerelése előtt a kiszolgálókat futtató és a régebbi átjárógyűrűkhöz csatlakozó ügyfelek e-mailben és az Azure Portalon értesítést kapnak. Az átjárók leszerelése hatással lehet a kiszolgálókhoz való kapcsolódásra, ha

  • Az átjáró IP-címeit az alkalmazás kapcsolati sztring keményen kódozza. Ez nem ajánlott. A kiszolgáló teljes tartománynevét (FQDN) az alkalmazás kapcsolati sztring formátumában <servername>.mysql.database.azure.comkell használnia.
  • Az ügyféloldali tűzfalon nem frissíti az újabb átjáró IP-címeit, hogy a kimenő forgalom elérhesse az új átjárógyűrűket.

Fontos

Ha az ügyfélkapcsolati veremnek közvetlenül kell csatlakoznia az átjáróhoz az ajánlott DNS-névhasználat helyett, vagy engedélyeznie kell az átjárót az ügyfélinfrastruktúra felé irányuló kapcsolatok tűzfalszabályaiban, határozottan arra ösztönözzük az ügyfeleket, hogy az átjáró IP-cím alhálózatait használják, szemben a statikus IP-cím korlátozásával, hogy ne befolyásolják ezt a tevékenységet egy olyan régióban, amely miatt az IP-cím megváltozhat az alhálózati tartományon belül.

Az alábbi táblázat az Azure Database for MySQL-átjáró összes adatrégiójának átjáró IP-címét sorolja fel. Az átjáró IP-címeinek legfrissebb információit az alábbi táblázatban találja. Az alábbi táblázatban az oszlopok a következőket jelölik:

  • Átjáró IP-cím alhálózatai: Ez az oszlop az adott régióban található átjárógyűrűk IP-cím alhálózatait sorolja fel. A régebbi átjáróhardverek kivonása során azt javasoljuk, hogy nyissa meg az ügyféloldali tűzfalat, hogy engedélyezze a kimenő forgalmat a használt régió IP-cím alhálózatai számára.
  • Átjáró IP-címei: Rendszeres időközönként az egyes átjáró IP-címei ki lesznek vonva, és a forgalom át lesz migrálva a megfelelő átjáró IP-cím alhálózataiba.

Határozottan arra ösztönözzük az ügyfeleket, hogy ne támaszkodjanak az egyes átjáró IP-címeire (mivel ezek a jövőben megszűnnek). Ehelyett lehetővé teszi a hálózati forgalom számára az egyes átjáró IP-címeinek és az átjáró IP-cím alhálózatainak elérését egy régióban.

Régió neve Jelenlegi átjáró IP-címe Átjáró IP-cím alhálózatai
Ausztrália középső régiója 20.36.105.32 20.36.105.32/29, 20.53.48.96/27
Ausztrália középső régiója2 20.36.113.32 20.36.113.32/29, 20.53.56.32/27
Kelet-Ausztrália 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
Délkelet-Ausztrália 13.77.49.33 13.77.49.32/29, 104.46.179.160/27
Dél-Brazília 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
Délkelet-Brazília 191.233.48.2 191.233.48.32/29, 191.233.15.160/27
Közép-Kanada 13.71.168.32 13.71.168.32/29, 20.38.144.32/29, 52.246.152.32/29, 20.48.196.32/27
Kelet-Kanada 40.69.105.32 40.69.105.32/29, 52.139.106.192/27
Az USA középső régiója 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
Kelet-Kína 52.130.112.139 52.130.112.136/29, 52.130.13.96/27
Kelet-Kína 2. régiója 40.73.82.1, 52.130.120.89 52.130.120.88/29, 52.130.7.0/27
Észak-Kína 52.130.128.89 52.130.128.88/29, 40.72.77.128/27
Észak-Kína 2. régiója 40.73.50.0 52.130.40.64/29, 52.130.21.160/27
Kelet-Ázsia 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 keleti régiója 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 2. keleti régiója 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
Közép-Franciaország 40.79.129.1 40.79.128.32/29, 40.79.136.32/29, 40.79.144.32/29, 20.43.47.192/27
Dél-Franciaország 40.79.176.40 40.79.176.40/29, 40.79.177.32/29, 52.136.185.0/27
Észak-Németország 51.116.56.0 51.116.57.32/29, 51.116.54.96/27
Középnyugat-Németország 51.116.152.0 51.116.152.32/29, 51.116.240.32/29, 51.116.248.32/29, 51.116.149.32/27
Közép-India 20.192.96.33 40.80.48.32/29, 104.211.86.32/29, 20.192.96.32/29, 20.192.43.160/27
Dél-India 40.78.192.32 40.78.192.32/29, 40.78.193.32/29, 52.172.113.96/27
Nyugat-India 104.211.144.32 104.211.144.32/29, 104.211.145.32/29, 52.136.53.160/27
Kelet-Japán 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
Nyugat-Japán 40.74.96.6 20.18.179.192/29, 40.74.96.32/29, 20.189.225.160/27
Jio India Central 20.192.233.32 20.192.233.32/29, 20.192.48.32/27
Jio Nyugat-India 20.193.200.32 20.193.200.32/29, 20.192.167.224/27
Dél-Korea középső régiója 52.231.17.13 20.194.64.32/29, 20.44.24.32/29, 52.231.16.32/29, 20.194.73.64/27
Dél-Korea déli régiója 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 északi középső régiója 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
Észak-Európa 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
Kelet-Norvégia 51.120.96.0 51.120.208.32/29, 51.120.104.32/29, 51.120.96.32/29, 51.120.232.192/27
Nyugat-Norvégia 51.120.216.0 51.120.217.32/29, 51.13.136.224/27
Dél-Afrika északi régiója 102.133.152.0 102.133.120.32/29, 102.133.152.32/29, 102.133.248.32/29, 102.133.221.224/27
Dél-Afrika nyugati régiója 102.133.24.0 102.133.25.32/29, 102.37.80.96/27
USA déli középső régiója 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
Délkelet-Ázsia 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
Közép-Svédország 51.12.96.32 51.12.96.32/29, 51.12.232.32/29, 51.12.224.32/29, 51.12.46.32/27
Dél-Svédország 51.12.200.32 51.12.201.32/29, 51.12.200.32/29, 51.12.198.32/27
Észak-Svájc 51.107.56.0 51.107.56.32/29, 51.103.203.192/29, 20.208.19.192/29, 51.107.242.32/27
Nyugat-Svájc 51.107.152.0 51.107.153.32/29, 51.107.250.64/27
Egyesült Arab Emírségek középső régiója 20.37.72.64 20.37.72.96/29, 20.37.73.96/29, 20.37.71.64/27
Egyesült Arab Emírségek északi régiója 65.52.248.0 20.38.152.24/29, 40.120.72.32/29, 65.52.248.32/29, 20.38.143.64/27
Az Egyesült Királyság déli régiója 51.105.64.0 51.105.64.32/29, 51.105.72.32/29, 51.140.144.32/29, 51.143.209.224/27
Az Egyesült Királyság nyugati régiója 51.140.208.98 51.140.208.96/29, 51.140.209.32/29, 20.58.66.128/27
USA nyugati középső régiója 13.71.193.34 13.71.193.32/29, 20.69.0.32/27
Nyugat-Európa 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 nyugati régiója 13.86.216.212, 13.86.217.212 20.168.163.192/29, 13.86.217.224/29, 20.66.3.64/27
USA 2. nyugati régiója 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 3. nyugati régiója 20.150.184.2 20.150.168.32/29, 20.150.176.32/29, 20.150.184.32/29, 20.150.241.128/27

Kapcsolat átirányítása

Az Azure Database for MySQL támogatja az extra kapcsolati szabályzatot, az átirányítást, amely segít csökkenteni az ügyfélalkalmazások és a MySQL-kiszolgálók közötti hálózati késést. Az átirányítással és a kezdeti TCP-munkamenetnek az Azure Database for MySQL-kiszolgálóra való létrehozása után a kiszolgáló visszaadja a MySQL-kiszolgálót üzemeltető csomópont háttércímét az ügyfélnek. Ezt követően az összes további csomag közvetlenül a kiszolgálóra áramlik, megkerülve az átjárót. Mivel a csomagok közvetlenül a kiszolgálóra áramlanak, a késés és az átviteli sebesség jobb teljesítményt eredményez.

Ezt a funkciót az Azure Database for MySQL-kiszolgálók támogatják az 5.7-ös és a 8.0-s motorverzióval.

Az átirányítás támogatása a Microsoft által kifejlesztett PHP mysqlnd_azure bővítményben érhető el, és a PECL-en érhető el. Az átirányítás alkalmazásbeli használatáról további információt az átirányítás konfigurálásáról szóló cikkben talál.

Fontos

A PHP mysqlnd_azure bővítmény átirányításának támogatása jelenleg előzetes verzióban érhető el.

Gyakori kérdések

Mit kell tudnia erről a tervezett karbantartásról?

Ez csak DNS-módosítás, ami átláthatóvá teszi az ügyfelek számára. Bár az FQDN IP-címe módosul a DNS-kiszolgálón, a helyi DNS-gyorsítótár 5 percen belül frissül, és az operációs rendszerek automatikusan elvégzik. A helyi DNS-frissítés után az összes új kapcsolat csatlakozik az új IP-címhez, az összes meglévő kapcsolat megszakítás nélkül csatlakozik a régi IP-címhez, amíg a régi IP-címek teljesen le nem lesznek szerelve. A régi IP-cím nagyjából 3-4 hetet vesz igénybe a leszerelés előtt; ezért nincs hatása az ügyfélalkalmazásokra.

Mit szerelünk le?

Csak az átjárócsomópontok lesznek leszerelésre. Amikor a felhasználók a kiszolgálóikhoz csatlakoznak, a kapcsolat első állomása az átjárócsomópont lesz, mielőtt a rendszer a kiszolgálóra továbbítja a kapcsolatot. A régi átjárók gyűrűinek leszerelését (nem a kiszolgálót futtató bérlői köröket) a kapcsolati architektúrára hivatkozva részletesebben is bemutatjuk.

Hogyan ellenőrizheti, hogy a kapcsolatok régi átjárócsomópontokra vagy új átjárócsomópontokra fognak-e csatlakozni?

Pingelje például ping xxx.mysql.database.azure.coma kiszolgáló teljes tartománynevét. Ha a visszaadott IP-cím a fenti dokumentumban az átjáró IP-címei (leszerelése) alatt felsorolt IP-címek egyike, az azt jelenti, hogy a kapcsolat a régi átjárón halad keresztül. Ezzel párhuzamosan, ha a visszaadott IP-cím az átjáró IP-címei között felsorolt IP-címek egyike, az azt jelenti, hogy a kapcsolat az új átjárón halad keresztül.

PsPing vagy TCPPing használatával is tesztelheti az adatbázis-kiszolgálót az ügyfélalkalmazásból a 3306-os porton, és győződjön meg arról, hogy a visszaadott IP-cím nem tartozik a leszerelési IP-címek közé

Hogyan tudom, mikor van vége a karbantartásnak, és kapok egy újabb értesítést a régi IP-címek leszereléséről?

A karbantartási munka megkezdésekor e-mailt kap, amely tájékoztatja Önt. A karbantartás az alrégiókban migrálandó kiszolgálók számától függően akár egy hónapot is igénybe vehet. Készítse elő az ügyfelet, hogy csatlakozzon az adatbázis-kiszolgálóhoz a teljes tartománynévvel vagy a fenti táblázat új IP-címével.

Mit tegyek, ha az ügyfélalkalmazásaim továbbra is a régi átjárókiszolgálóhoz csatlakoznak?

Ez azt jelzi, hogy az alkalmazások az FQDN helyett statikus IP-címmel csatlakoznak a kiszolgálóhoz. Tekintse át a kapcsolati sztring és a kapcsolatkészletezési beállítást, az AKS-beállítást vagy akár a forráskódot is.

Hatással van az alkalmazáskapcsolataimra?

Ez a karbantartás csak DNS-módosítás, ezért az ügyfél számára átlátható. Miután a DNS-gyorsítótár frissül az ügyfélben (az operációs rendszer automatikusan végrehajtja), az összes új kapcsolat csatlakozik az új IP-címhez, és az összes meglévő kapcsolat továbbra is jól működik, amíg a régi IP-cím teljesen le nem lesz szerelve, ami néhány héttel később történik. Az újrapróbálkozáshoz nincs szükség az újrapróbálkozáshoz, de jó látni, hogy az alkalmazás újrapróbálkozott logikával rendelkezik. Az FQDN használatával csatlakozzon az alkalmazás adatbázis-kiszolgálójához kapcsolati sztring. Ez a karbantartási művelet nem fogja elvetni a meglévő kapcsolatokat. Az új kapcsolatkérések csak az új átjárógyűrűre kerülnek.

Kérhetek egy adott időkeretet a karbantartáshoz?

Mivel a migrálásnak transzparensnek kell lennie, és nincs hatással az ügyfél kapcsolatára, várhatóan a felhasználók többsége nem fog problémát tapasztalni. Tekintse át proaktívan az alkalmazást, és győződjön meg arról, hogy teljes tartománynévvel csatlakozik az adatbázis-kiszolgálóhoz, vagy engedélyezi az új átjáró IP-címeinek listáját az alkalmazás kapcsolati sztring.

Nem, ez egy átjáróhardver leszerelése, és nincs kapcsolata a privát kapcsolattal vagy a privát IP-címekkel, csak a leszerelési IP-címek alatt említett nyilvános IP-címekre lesz hatással.

Következő lépések