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.com
kell 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.com
a 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.
Privát kapcsolatot használok, hatással lesznek-e a kapcsolataim?
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.