architettura Connessione ivity in Database di Azure per MySQL
SI APPLICA A:
Database di Azure per MySQL - Server singolo
Importante
Database di Azure per MySQL server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per MySQL server flessibile. Per altre informazioni sulla migrazione a Database di Azure per MySQL server flessibile, vedere Che cosa accade a Database di Azure per MySQL server singolo?
Questo articolo illustra l'architettura di connettività Database di Azure per MySQL e il modo in cui il traffico viene indirizzato all'istanza di Database di Azure per MySQL dai client sia all'interno che all'esterno di Azure.
Architettura della connettività
Connessione all'Database di Azure per MySQL viene stabilita tramite un gateway responsabile del routing delle connessioni in ingresso alla posizione fisica del server nei cluster. Il diagramma seguente illustra il flusso del traffico.
Quando il client si connette al database, il stringa di connessione al server viene risolto nell'indirizzo IP del gateway. Il gateway è in ascolto sull'indirizzo IP sulla porta 3306. All'interno del cluster di database, il traffico viene inoltrato alle Database di Azure per MySQL appropriate. Pertanto, per connettersi al server, ad esempio dalle reti aziendali, è necessario aprire il firewall lato client per consentire al traffico in uscita di raggiungere i gateway. Di seguito è riportato un elenco completo degli indirizzi IP usati dai gateway per area.
indirizzi IP del gateway Database di Azure per MySQL
Il servizio gateway è ospitato in un gruppo di nodi di calcolo senza stato che si trovano dietro un indirizzo IP, che il client raggiungerà per primo quando tenta di connettersi a un server Database di Azure per MySQL.
Come parte della manutenzione continua dei servizi, aggiorneremo periodicamente l'hardware di calcolo che ospita i gateway per garantire l'esperienza più sicura ed efficiente. Quando l'hardware del gateway viene aggiornato, viene creato un nuovo anello dei nodi di calcolo. Questo nuovo anello serve il traffico per tutti i server Database di Azure per MySQL appena creati e avrà un indirizzo IP diverso dagli anelli del gateway meno recenti nella stessa area per differenziare il traffico. Una volta che il nuovo anello è completamente funzionante, l'hardware del gateway precedente che serve i server esistenti è pianificato per la rimozione delle autorizzazioni. Prima di rimuovere un hardware del gateway, i clienti che eseguono i server e si connettono agli anelli di gateway meno recenti riceveranno una notifica tramite posta elettronica e nella portale di Azure. La rimozione delle autorizzazioni dei gateway può influire sulla connettività ai server se
- È necessario impostare come hardcoded gli indirizzi IP del gateway nella stringa di connessione dell'applicazione. Non è consigliabile. È consigliabile usare il nome di dominio completo (FQDN) del server nel formato
<servername>.mysql.database.azure.com, nella stringa di connessione per l'applicazione. - Non si aggiornano gli indirizzi IP del gateway più recenti nel firewall lato client per consentire al traffico in uscita di raggiungere i nuovi anelli del gateway.
Importante
Se lo stack di connettività dei clienti deve connettersi direttamente al gateway anziché all'approccio consigliato per il nome DNS o al gateway di elenco di indirizzi consentiti nelle regole del firewall per le connessioni all'infrastruttura del cliente, è consigliabile che i clienti usino subnet di indirizzi IP gateway rispetto all'uso dell'ip statico hardcoding per non essere interessati da questa attività in un'area che potrebbe causare modifiche all'interno dell'intervallo di subnet.
La tabella seguente elenca gli indirizzi IP del gateway del gateway del gateway Database di Azure per MySQL per tutte le aree dati. Nella tabella seguente vengono mantenute le informazioni più aggiornate degli indirizzi IP del gateway per ogni area. Nella tabella seguente le colonne rappresentano quanto segue:
- Nome area: questa colonna elenca il nome dell'area di Azure in cui è disponibile Database di Azure per PostgreSQL - Server singolo.
- Subnet degli indirizzi IP del gateway: questa colonna elenca le subnet degli indirizzi IP degli anelli del gateway che si trovano nell'area specifica. Quando si ritira l'hardware del gateway meno recente, è consigliabile aprire il firewall sul lato client per consentire il traffico in uscita per le subnet degli indirizzi IP nell'area in cui si sta operando.
- Indirizzi IP del gateway (rimozione delle autorizzazioni): questa colonna elenca gli indirizzi IP dei gateway ospitati in una generazione precedente di hardware che viene rimosso al momento. Se si esegue il provisioning di un nuovo server, è possibile ignorare questi indirizzi IP. Se si dispone di un server esistente, continuare a mantenere la regola in uscita per il firewall per questi indirizzi IP, perché non è ancora stata rimossa. Se si rilasciano le regole del firewall per questi indirizzi IP, è possibile che vengano visualizzati errori di connettività. Si prevede invece di aggiungere in modo proattivo i nuovi indirizzi IP elencati nella colonna Indirizzi IP del gateway alla regola del firewall in uscita non appena si riceve la notifica per la rimozione delle autorizzazioni. In questo modo, quando si esegue la migrazione del server all'hardware del gateway più recente, non si verificano interruzioni nella connettività al server.
- Indirizzi IP del gateway (rimozione delle autorizzazioni): questa colonna elenca gli indirizzi IP degli anelli del gateway, che vengono rimossi e non sono più in operazioni. È possibile rimuovere in modo sicuro questi indirizzi IP dalla regola del firewall in uscita.
| Nome area | Subnet degli indirizzi IP del gateway | Indirizzi IP del gateway (rimozione delle autorizzazioni) | Indirizzi IP del gateway (ritirati) |
|---|---|---|---|
| Australia centrale | 20.36.105.32/29 | ||
| Australia centrale 2 | 20.36.113.32/29 | ||
| Australia orientale | 13.70.112.32/29, 40.79.160.32/29, 40.79.168.32/29 | 13.75.149.87 | |
| Australia sud-orientale | 13.77.49.32/29 | 13.73.109.251 | |
| Brasile meridionale | 191.233.200.32/29, 191.234.144.32/29 | 104.41.11.5 | |
| Canada centrale | 13.71.168.32/29, 20.38.144.32/29, 52.246.152.32/29 | ||
| Canada orientale | 40.69.105.32/29 | 40.86.226.166 | |
| Stati Uniti centrali | 104.208.21.192/29, 13.89.168.192/29, 52.182.136.192/29 | 13.67.215.62 | |
| Cina orientale | 52.130.112.136/29 | ||
| Cina orientale 2 | 52.130.120.88/29 | ||
| Cina orientale 3 | 52.130.128.88/29 | ||
| Cina settentrionale | 52.130.128.88/29 | ||
| Cina settentrionale 2 | 52.130.40.64/29 | ||
| Cina settentrionale 3 | 13.75.32.192/29, 13.75.33.192/29 | ||
| Asia orientale | 13.75.32.192/29, 13.75.33.192/29 | ||
| Stati Uniti orientali | 20.42.65.64/29, 20.42.73.0/29, 52.168.116.64/29 | 40.121.158.30 | 191.238.6.43 |
| Stati Uniti orientali 2 | 104.208.150.192/29, 40.70.144.192/29, 52.167.104.192/29 | 52.177.185.181 | |
| Francia centrale | 40.79.136.32/29, 40.79.144.32/29 | ||
| Francia meridionale | 40.79.176.40/29, 40.79.177.32/29 | ||
| Germania centro-occidentale | 51.116.152.32/29, 51.116.240.32/29, 51.116.248.32/29 | ||
| India centrale | 104.211.86.32/29, 20.192.96.32/29 | ||
| India meridionale | 40.78.192.32/29, 40.78.193.32/29 | ||
| India occidentale | 104.211.144.32/29, 104.211.145.32/29 | 104.211.160.80 | |
| Giappone orientale | 13.78.104.32/29, 40.79.184.32/29, 40.79.192.32/29 | 13.78.61.196 | |
| Giappone occidentale | 40.74.96.32/29 | 104.214.148.156 | |
| Corea centrale | 20.194.64.32/29, 20.44.24.32/29, 52.231.16.32/29 | 52.231.32.42 | |
| Corea meridionale | 52.231.145.0/29 | 52.231.200.86 | |
| Stati Uniti centro-settentrionali | 52.162.105.192/29 | 23.96.178.199 | |
| Europa settentrionale | 13.69.233.136/29, 13.74.105.192/29, 52.138.229.72/29 | 40.113.93.91 | 191.235.193.75 |
| Sudafrica settentrionale | 102.133.120.32/29, 102.133.152.32/29, 102.133.248.32/29 | ||
| Sudafrica occidentale | 102.133.25.32/29 | ||
| Stati Uniti centro-meridionali | 20.45.121.32/29, 20.49.88.32/29, 20.49.89.32/29, 40.124.64.136/29 | 13.66.62.124 | 23.98.162.75 |
| Asia sud-orientale | 13.67.16.192/29, 23.98.80.192/29, 40.78.232.192/29 | 104.43.15.0 | |
| Svizzera settentrionale | 51.107.56.32/29, 51.103.203.192/29, 20.208.19.192/29, 51.107.242.32/27 | ||
| Svizzera occidentale | 51.107.153.32/29 | ||
| Emirati Arabi Uniti centrali | 20.37.72.96/29, 20.37.73.96/29 | ||
| Emirati Arabi Uniti settentrionali | 40.120.72.32/29, 65.52.248.32/29 | ||
| Regno Unito meridionale | 51.105.64.32/29, 51.105.72.32/29, 51.140.144.32/29 | ||
| Regno Unito occidentale | 51.140.208.96/29, 51.140.209.32/29 | ||
| Stati Uniti centro-occidentali | 13.71.193.32/29 | 13.78.145.25 | |
| Europa occidentale | 104.40.169.32/29, 13.69.112.168/29, 52.236.184.32/29 | 40.68.37.158 | 191.237.232.75 |
| Stati Uniti occidentali | 13.86.217.224/29 | 104.42.238.205 | 23.99.34.75 |
| West US 2 | 13.66.136.192/29, 40.78.240.192/29, 40.78.248.192/29 | ||
| Stati Uniti occidentali 3 | 20.150.168.32/29, 20.150.176.32/29, 20.150.184.32/29 |
reindirizzamento Connessione ion
Database di Azure per MySQL supporta criteri di connessione aggiuntivi, reindirizzamento che consente di ridurre la latenza di rete tra le applicazioni client e i server MySQL. Con il reindirizzamento e dopo aver stabilito la sessione TCP iniziale al server Database di Azure per MySQL, il server restituisce l'indirizzo back-end del nodo che ospita il server MySQL al client. Successivamente, tutti i pacchetti successivi vengono trasmessi direttamente al server, ignorando il gateway. Man mano che i pacchetti vengono trasmessi direttamente al server, la latenza e la velocità effettiva hanno prestazioni migliorate.
Questa funzionalità è supportata nei server Database di Azure per MySQL con versioni del motore 5.7 e 8.0.
Il supporto per il reindirizzamento è disponibile nell'estensione PHP mysqlnd_azure , sviluppato da Microsoft ed è disponibile in PECL. Per altre informazioni su come usare il reindirizzamento nelle applicazioni, vedere l'articolo sulla configurazione del reindirizzamento.
Importante
Il supporto per il reindirizzamento nell'estensione mysqlnd_azure PHP è attualmente in anteprima.
Domande frequenti
Cosa è necessario sapere su questa manutenzione pianificata?
Si tratta solo di una modifica DNS, che lo rende trasparente ai client. Mentre l'indirizzo IP per FQDN viene modificato nel server DNS, la cache DNS locale viene aggiornata entro 5 minuti e viene eseguita automaticamente dai sistemi operativi. Dopo l'aggiornamento dns locale, tutte le nuove connessioni si connetteranno al nuovo indirizzo IP, tutte le connessioni esistenti rimarranno connesse all'indirizzo IP precedente senza interruzioni fino a quando gli indirizzi IP precedenti non verranno completamente rimossi. L'indirizzo IP precedente richiederà circa tre-quattro settimane prima di essere rimosso; pertanto, non deve avere alcun effetto sulle applicazioni client.
Che cosa stiamo ritirando?
Vengono rimossi solo i nodi del gateway. Quando gli utenti si connettono ai server, il primo arresto della connessione è al nodo del gateway, prima che la connessione venga inoltrata al server. Gli anelli del gateway meno vecchi (non gli anelli tenant in cui è in esecuzione il server) fanno riferimento all'architettura di connettività per ulteriori chiarimenti.
Come è possibile verificare se le connessioni si trovano nei nodi del gateway precedenti o nei nuovi nodi del gateway?
Eseguire il ping del nome di dominio completo del server, ad esempio ping xxx.mysql.database.azure.com. Se l'indirizzo IP restituito è uno degli indirizzi IP elencati in Indirizzi IP del gateway (rimozione delle autorizzazioni) nel documento precedente, significa che la connessione passa attraverso il gateway precedente. Contrariamente, se l'indirizzo IP restituito è uno degli indirizzi IP elencati in Indirizzi IP del gateway, significa che la connessione passa attraverso il nuovo gateway.
È anche possibile eseguire il test tramite PSPing o TCPPing del server di database dall'applicazione client con la porta 3306 e assicurarsi che l'indirizzo IP restituito non sia uno degli indirizzi IP di rimozione delle autorizzazioni
Ricerca per categorie sapere quando la manutenzione è finita e riceverò un'altra notifica quando vengono rimossi gli indirizzi IP precedenti?
Riceverai un messaggio di posta elettronica per informarti quando iniziamo il lavoro di manutenzione. La manutenzione può richiedere fino a un mese a seconda del numero di server di cui è necessario eseguire la migrazione in tutte le aree. Preparare il client per connettersi al server di database usando il nome di dominio completo o usando il nuovo indirizzo IP della tabella precedente.
Cosa fare se le applicazioni client si connettono ancora al server gateway precedente?
Ciò indica che le applicazioni si connettono al server usando l'indirizzo IP statico anziché il nome di dominio completo. Esaminare le stringa di connessione e l'impostazione del pool di connessioni, l'impostazione del servizio Azure Kubernetes o anche nel codice sorgente.
C'è un impatto sulle connessioni dell'applicazione?
Questa manutenzione è solo una modifica DNS, quindi è trasparente per il client. Dopo l'aggiornamento della cache DNS nel client (eseguito automaticamente dal sistema operativo), tutte le nuove connessioni si connettono al nuovo indirizzo IP e tutte le connessioni esistenti continueranno a funzionare fino a quando l'indirizzo IP precedente non viene rimosso completamente, che si verifica diverse settimane dopo. E la logica di ripetizione dei tentativi non è necessaria per questo caso, ma è utile vedere che l'applicazione ha configurato la logica di ripetizione dei tentativi. Usare il nome di dominio completo per connettersi al server di database o abilitare l'elenco dei nuovi indirizzi IP gateway nell'applicazione stringa di connessione. Questa operazione di manutenzione non comporta l'eliminazione delle connessioni esistenti. Effettua solo le nuove richieste di connessione al nuovo anello del gateway.
È possibile richiedere un intervallo di tempo specifico per la manutenzione?
Poiché la migrazione deve essere trasparente e senza alcun impatto sulla connettività del cliente, ci si aspetta che non ci sarà alcun problema per la maggior parte degli utenti. Esaminare l'applicazione in modo proattivo e assicurarsi di usare il nome di dominio completo per connettersi al server di database o abilitare l'elenco dei nuovi "indirizzi IP gateway" nell'applicazione stringa di connessione.
Se si usa un collegamento privato, le connessioni verranno interessate?
No, si tratta di una rimozione dell'hardware del gateway e non ha alcuna relazione con il collegamento privato o gli indirizzi IP privati, influirà solo sugli indirizzi IP pubblici indicati negli indirizzi IP di rimozione delle autorizzazioni.