Anslutningsarkitektur i Azure Database for MySQL
GÄLLER FÖR: 
Azure Database for MySQL – enskild server
Viktigt!
Azure Database for MySQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till en flexibel Azure Database for MySQL-server. Mer information om hur du migrerar till en flexibel Azure Database for MySQL-server finns i Vad händer med Azure Database for MySQL – enskild server?
Den här artikeln beskriver anslutningsarkitekturen för Azure Database for MySQL och hur trafiken dirigeras till din Azure Database for MySQL-instans från klienter både inom och utanför Azure.
Anslutningsarkitektur
Anslutningen till Din Azure Database for MySQL upprättas via en gateway som ansvarar för att dirigera inkommande anslutningar till serverns fysiska plats i våra kluster. Följande diagram illustrerar trafikflödet.
När klienten ansluter till databasen matchar niska veze till servern gatewayens IP-adress. Gatewayen lyssnar på IP-adressen på port 3306. I databasklustret vidarebefordras trafiken till lämplig Azure Database for MySQL. För att kunna ansluta till servern, till exempel från företagsnätverk, är det därför nödvändigt att öppna brandväggen på klientsidan så att utgående trafik kan nå våra gatewayer. Nedan hittar du en fullständig lista över DE IP-adresser som används av våra gatewayer per region.
IP-adresser för Azure Database for MySQL-gateway
Gatewaytjänsten finns på en grupp tillståndslösa beräkningsnoder bakom en IP-adress som klienten når först när du försöker ansluta till en Azure Database for MySQL-server.
Som en del av det pågående tjänstunderhållet uppdaterar vi regelbundet beräkningsmaskinvaran som är värd för gatewayerna för att säkerställa att vi ger den säkraste och mest högpresterande upplevelsen. När gatewaymaskinvaran uppdateras skapas först en ny ring av beräkningsnoderna. Den här nya ringen hanterar trafiken för alla nyligen skapade Azure Database for MySQL-servrar och har en annan IP-adress än äldre gatewayringar i samma region för att särskilja trafiken. När den nya ringen är fullt fungerande planeras den äldre gatewaymaskinvaran som betjänar befintliga servrar för inaktivering. Innan du inaktiverar en gatewaymaskinvara meddelas kunder som kör sina servrar och ansluter till äldre gatewayringar via e-post och i Azure-portalen. Inaktiveringen av gatewayer kan påverka anslutningen till dina servrar om
- Du hårdkodar gatewayens IP-adresser i programmets niska veze. Det rekommenderas inte. Du bör använda fullständigt kvalificerat domännamn (FQDN) för servern i formatet
<servername>.mysql.database.azure.com, i niska veze för ditt program. - Du uppdaterar inte de nyare gateway-IP-adresserna i brandväggen på klientsidan så att utgående trafik kan nå våra nya gatewayringar.
Viktigt!
Om kundens anslutningsstack behöver ansluta direkt till gatewayen i stället för rekommenderad DNS-namnmetod, eller tillåta-lista gateway i brandväggsreglerna för anslutningar till\från kundinfrastruktur, rekommenderar vi starkt att kunderna använder gateway-IP-adressundernät jämfört med hårdkodning av statisk IP för att inte påverkas av den här aktiviteten i en region som kan leda till att IP-adressen ändras inom undernätsintervallet.
I följande tabell visas gatewayens IP-adresser för Azure Database for MySQL-gatewayen för alla dataregioner. Den senaste informationen om gateway-IP-adresserna för varje region finns i tabellen nedan. I tabellen nedan representerar kolumnerna följande:
- Gateway-IP-adressundernät: I den här kolumnen visas IP-adressundernäten för gatewayringarna som finns i den specifika regionen. När vi drar tillbaka äldre gatewaymaskinvara rekommenderar vi att du öppnar brandväggen på klientsidan för att tillåta utgående trafik för IP-adressundernäten i den region som du använder.
- Gateway-IP-adresser: Med jämna mellanrum dras enskilda GATEWAY-IP-adresser tillbaka och trafiken migreras till motsvarande gateway-IP-adressundernät.
Vi rekommenderar starkt att kunderna flyttar från att förlita sig på en enskild gateway-IP-adress (eftersom dessa kommer att dras tillbaka i framtiden). Tillåt i stället nätverkstrafik att nå både de enskilda gateway-IP-adresserna och gateway-IP-adressundernäten i en region.
| Regionnamn | Aktuell GATEWAY-IP-adress | Gateway-IP-adressundernät |
|---|---|---|
| Australien, centrala | 20.36.105.32 | 20.36.105.32/29, 20.53.48.96/27 |
| Australien, centrala 2 | 20.36.113.32 | 20.36.113.32/29, 20.53.56.32/27 |
| Australien, östra | 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 |
| Sydöstra Australien | 13.77.49.33 | 13.77.49.32/29, 104.46.179.160/27 |
| Brasilien, södra | 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, sydöstra | 191.233.48.2 | 191.233.48.32/29, 191.233.15.160/27 |
| Kanada, centrala | 13.71.168.32 | 13.71.168.32/29, 20.38.144.32/29, 52.246.152.32/29, 20.48.196.32/27 |
| Östra Kanada | 40.69.105.32 | 40.69.105.32/29, 52.139.106.192/27 |
| Centrala USA | 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 |
| Kina, östra | 52.130.112.139 | 52.130.112.136/29, 52.130.13.96/27 |
| Östra Kina 2 | 40.73.82.1, 52.130.120.89 | 52.130.120.88/29, 52.130.7.0/27 |
| Kina, norra | 52.130.128.89 | 52.130.128.88/29, 40.72.77.128/27 |
| Norra Kina 2 | 40.73.50.0 | 52.130.40.64/29, 52.130.21.160/27 |
| Asien, östra | 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, östra | 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, östra 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 |
| Centrala Frankrike | 40.79.129.1 | 40.79.128.32/29, 40.79.136.32/29, 40.79.144.32/29, 20.43.47.192/27 |
| Södra Frankrike | 40.79.176.40 | 40.79.176.40/29, 40.79.177.32/29, 52.136.185.0/27 |
| Tyskland, norra | 51.116.56.0 | 51.116.57.32/29, 51.116.54.96/27 |
| Tyskland, västra centrala | 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, centrala | 20.192.96.33 | 40.80.48.32/29, 104.211.86.32/29, 20.192.96.32/29, 20.192.43.160/27 |
| Södra Indien | 40.78.192.32 | 40.78.192.32/29, 40.78.193.32/29, 52.172.113.96/27 |
| Västra Indien | 104.211.144.32 | 104.211.144.32/29, 104.211.145.32/29, 52.136.53.160/27 |
| Japan, östra | 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 |
| Västra Japan | 40.74.96.6 | 20.18.179.192/29, 40.74.96.32/29, 20.189.225.160/27 |
| Jio, Indien, centrala | 20.192.233.32 | 20.192.233.32/29, 20.192.48.32/27 |
| Jio Västra Indien | 20.193.200.32 | 20.193.200.32/29, 20.192.167.224/27 |
| Sydkorea, centrala | 52.231.17.13 | 20.194.64.32/29, 20.44.24.32/29, 52.231.16.32/29, 20.194.73.64/27 |
| Södra Korea | 52.231.145.3 | 52.231.151.96/27, 52.231.151.88/29, 52.231.145.0/29, 52.147.112.160/27 |
| Norra centrala USA | 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 |
| Europa, norra | 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 |
| Norge, östra | 51.120.96.0 | 51.120.208.32/29, 51.120.104.32/29, 51.120.96.32/29, 51.120.232.192/27 |
| Västra Norge | 51.120.216.0 | 51.120.217.32/29, 51.13.136.224/27 |
| Sydafrika, norra | 102.133.152.0 | 102.133.120.32/29, 102.133.152.32/29, 102.133.248.32/29, 102.133.221.224/27 |
| Sydafrika, västra | 102.133.24.0 | 102.133.25.32/29, 102.37.80.96/27 |
| USA, södra centrala | 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 |
| Sydostasien | 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 |
| Sverige, centrala | 51.12.96.32 | 51.12.96.32/29, 51.12.232.32/29, 51.12.224.32/29, 51.12.46.32/27 |
| Södra Sverige | 51.12.200.32 | 51.12.201.32/29, 51.12.200.32/29, 51.12.198.32/27 |
| Schweiz, norra | 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, västra | 51.107.152.0 | 51.107.153.32/29, 51.107.250.64/27 |
| Förenade Arabemiraten, centrala | 20.37.72.64 | 20.37.72.96/29, 20.37.73.96/29, 20.37.71.64/27 |
| Förenade Arabemiraten, norra | 65.52.248.0 | 20.38.152.24/29, 40.120.72.32/29, 65.52.248.32/29, 20.38.143.64/27 |
| Södra Storbritannien | 51.105.64.0 | 51.105.64.32/29, 51.105.72.32/29, 51.140.144.32/29, 51.143.209.224/27 |
| Västra Storbritannien | 51.140.208.98 | 51.140.208.96/29, 51.140.209.32/29, 20.58.66.128/27 |
| Västra centrala USA | 13.71.193.34 | 13.71.193.32/29, 20.69.0.32/27 |
| Västeuropa | 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 |
| Västra USA | 13.86.216.212, 13.86.217.212 | 20.168.163.192/29, 13.86.217.224/29, 20.66.3.64/27 |
| Västra USA 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, västra 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 |
Omdirigering av anslutning
Azure Database for MySQL stöder en extra anslutningsprincip, omdirigering som hjälper till att minska nätverksfördröjningen mellan klientprogram och MySQL-servrar. Med omdirigering och när den första TCP-sessionen har upprättats till Azure Database for MySQL-servern returnerar servern serverdelsadressen för noden som är värd för MySQL-servern till klienten. Därefter flödar alla efterföljande paket direkt till servern och kringgår gatewayen. När paket flödar direkt till servern har svarstiden och dataflödet förbättrat prestandan.
Den här funktionen stöds i Azure Database for MySQL-servrar med motorversionerna 5.7 och 8.0.
Stöd för omdirigering finns i PHP-mysqlnd_azure-tillägget som utvecklats av Microsoft och är tillgängligt på PECL. Mer information om hur du använder omdirigering i dina program finns i artikeln konfigurera omdirigering.
Viktigt!
Stöd för omdirigering i PHP-mysqlnd_azure-tillägget finns för närvarande i förhandsversion.
Vanliga frågor och svar
Vad behöver du veta om det här planerade underhållet?
Detta är endast en DNS-ändring, vilket gör den transparent för klienter. Ip-adressen för FQDN ändras på DNS-servern, men den lokala DNS-cachen uppdateras inom 5 minuter och görs automatiskt av operativsystemet. Efter den lokala DNS-uppdateringen ansluter alla nya anslutningar till den nya IP-adressen. Alla befintliga anslutningar förblir anslutna till den gamla IP-adressen utan avbrott tills de gamla IP-adresserna har inaktiverats helt. Den gamla IP-adressen tar ungefär tre till fyra veckor innan den tas ur bruk. Därför bör det inte ha någon effekt på klientprogrammen.
Vad tar vi ur drift?
Endast gatewaynoder inaktiveras. När användarna ansluter till sina servrar är det första stoppet för anslutningen till gatewaynoden innan anslutningen vidarebefordras till servern. Vi inaktiverar gamla gatewayringar (inte klientringar där servern körs) finns i anslutningsarkitekturen för mer förtydligande.
Hur kan du kontrollera om dina anslutningar går till gamla gatewaynoder eller nya gatewaynoder?
Pinga serverns FQDN, till exempel ping xxx.mysql.database.azure.com. Om den returnerade IP-adressen är en av ip-adresserna som anges under Gateway IP-adresser (inaktivering) i dokumentet ovan innebär det att anslutningen går via den gamla gatewayen. Tvärtom, om den returnerade IP-adressen är en av ip-adresserna som anges under Gateway IP-adresser innebär det att anslutningen går via den nya gatewayen.
Du kan också testa med PSPing eller TCPPing databasservern från klientprogrammet med port 3306 och se till att retur-IP-adressen inte är en av de inaktiverade IP-adresserna
Hur vet jag när underhållet är över och får ett nytt meddelande när gamla IP-adresser har inaktiverats?
Du får ett e-postmeddelande som informerar dig när vi påbörjar underhållsarbetet. Underhållet kan ta upp till en månad beroende på hur många servrar vi behöver migrera i al-regioner. Förbered klienten för att ansluta till databasservern med hjälp av FQDN eller med hjälp av den nya IP-adressen från tabellen ovan.
Vad gör jag om mina klientprogram fortfarande ansluter till den gamla gatewayservern?
Detta indikerar att dina program ansluter till servern med statisk IP-adress i stället för FQDN. Granska inställningen för niska veze och anslutningspooler, AKS-inställningen eller till och med i källkoden.
Påverkar det mina programanslutningar?
Det här underhållet är bara en DNS-ändring, så det är transparent för klienten. När DNS-cachen har uppdaterats i klienten (utförs automatiskt av åtgärdssystemet) ansluter alla nya anslutningar till den nya IP-adressen och alla befintliga anslutningar fungerar fortfarande bra tills den gamla IP-adressen har inaktiverats helt, vilket inträffar flera veckor senare. Och logiken för återförsök krävs inte för det här fallet, men det är bra att se att programmet har konfigurerat logiken för omprövning. Använd FQDN för att ansluta till databasservern i ditt program niska veze. Den här underhållsåtgärden släpper inte befintliga anslutningar. Det gör bara att de nya anslutningsbegäranden går till en ny gateway-ring.
Kan jag begära ett visst tidsfönster för underhållet?
Eftersom migreringen bör vara transparent och inte påverka kundens anslutning förväntar vi oss att det inte kommer att bli några problem för de flesta användare. Granska programmet proaktivt och se till att du antingen använder FQDN för att ansluta till databasservern eller aktivera listan med de nya "Gateway IP-adresserna" i ditt program niska veze.
Jag använder privat länk, kommer mina anslutningar att påverkas?
Nej, det här är en inaktiv gatewaymaskinvara och har ingen relation till privata länkar eller privata IP-adresser. Det påverkar bara offentliga IP-adresser som anges under avaktiverings-IP-adresserna.