Architettura della connettività in Database di Azure per MariaDB
Importante
Database di Azure per MariaDB è in fase di ritiro. È consigliabile eseguire la migrazione a Database di Azure per MySQL. Per altre informazioni sulla migrazione a Database di Azure per MySQL, vedere Che cosa sta succedendo a Database di Azure per MariaDB?.
Questo articolo illustra l'architettura di connettività Database di Azure per MariaDB e il modo in cui il traffico viene indirizzato all'istanza di Database di Azure per MariaDB dai client sia all'interno che all'esterno di Azure.
Architettura della connettività
La connessione al Database di Azure per MariaDB 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, la stringa di connessione al server viene risolta nell'indirizzo IP del gateway. Il gateway è in ascolto sulla porta 3306 dell’indirizzo IP. All'interno del cluster di database, il traffico viene inoltrato alle Database di Azure per MariaDB appropriate. Pertanto, per connettersi al server, come 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 MariaDB
Il servizio gateway è ospitato in un gruppo di nodi di calcolo senza stato seduti dietro un indirizzo IP, che il client raggiungerà per primo quando tenta di connettersi a un server Database di Azure per MariaDB.
Nell’ambito della manutenzione continua dei servizi, aggiorneremo periodicamente l'hardware di calcolo che ospita i gateway per garantire l'esperienza più sicura ed efficace possibile. 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 MariaDB 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, è prevista la dismissione dell'hardware del gateway precedente che serve i server esistenti. 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 nei portale di Azure, tre mesi prima della rimozione delle autorizzazioni. La dismissione dei gateway può influire sulla connettività ai server se
- Gli indirizzi IP del gateway sono codificati nella stringa di connessione dell'applicazione. Si tratta di un'operazione non consigliata. È consigliabile usare il nome di dominio completo (FQDN) del server nel formato
<servername>.mariadb.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, è fortemente 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.
Nella tabella seguente sono elencati gli indirizzi IP del gateway del gateway Database di Azure per MariaDB 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:
- 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 lato client per consentire il traffico in uscita verso le subnet degli indirizzi IP nell'area in cui si sta operando.
- Indirizzi IP del gateway: periodicamente, i singoli indirizzi IP del gateway verranno ritirati e il traffico verrà trasferito alle subnet degli indirizzi IP del gateway corrispondenti.
Si consiglia vivamente ai clienti di evitare la dipendenza da qualsiasi singolo indirizzo IP del gateway (dal momento che questi verranno ritirati in futuro). Consentire invece al traffico di rete di raggiungere sia i singoli indirizzi IP del gateway sia le subnet degli indirizzi IP del gateway in un'area.
| Nome area | Indirizzo IP del gateway corrente | Subnet di indirizzi IP del gateway |
|---|---|---|
| Australia centrale | 20.36.105.32 | 20.36.105.32/29, 20.53.48.96/27 |
| Australia centrale 2 | 20.36.113.32 | 20.36.113.32/29, 20.53.56.32/27 |
| Australia orientale | 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 |
| Australia sud-orientale | 13.77.49.33 | 13.77.49.32/29, 104.46.179.160/27 |
| Brasile meridionale | 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 |
| Brasile meridionale | 191.233.48.2 | 191.233.48.32/29, 191.233.15.160/27 |
| Canada centrale | 13.71.168.32 | 13.71.168.32/29, 20.38.144.32/29, 52.246.152.32/29, 20.48.196.32/27 |
| Canada orientale | 40.69.105.32 | 40.69.105.32/29, 52.139.106.192/27 |
| Stati Uniti centrali | 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 |
| Cina orientale | 52.130.112.139 | 52.130.112.136/29, 52.130.13.96/27 |
| Cina orientale 2 | 40.73.82.1, 52.130.120.89 | 52.130.120.88/29, 52.130.7.0/27 |
| Cina settentrionale | 52.130.128.89 | 52.130.128.88/29, 40.72.77.128/27 |
| Cina settentrionale 2 | 40.73.50.0 | 52.130.40.64/29, 52.130.21.160/27 |
| Asia orientale | 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 |
| Stati Uniti orientali | 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 |
| Stati Uniti orientali 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 |
| Francia centrale | 40.79.129.1 | 40.79.128.32/29, 40.79.136.32/29, 40.79.144.32/29, 20.43.47.192/27 |
| Francia meridionale | 40.79.176.40 | 40.79.176.40/29, 40.79.177.32/29, 52.136.185.0/27 |
| Germania settentrionale | 51.116.56.0 | 51.116.57.32/29, 51.116.54.96/27 |
| Germania centro-occidentale | 51.116.152.0 | 51.116.152.32/29, 51.116.240.32/29, 51.116.248.32/29, 51.116.149.32/27 |
| India 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 |
| India meridionale | 40.78.192.32 | 40.78.192.32/29, 40.78.193.32/29, 52.172.113.96/27 |
| India occidentale | 104.211.144.32 | 104.211.144.32/29, 104.211.145.32/29, 52.136.53.160/27 |
| Giappone orientale | 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 |
| Giappone occidentale | 40.74.96.6 | 20.18.179.192/29, 40.74.96.32/29, 20.189.225.160/27 |
| Jio - India centrale | 20.192.233.32 | 20.192.233.32/29, 20.192.48.32/27 |
| India occidentale Jio | 20.193.200.32 | 20.193.200.32/29, 20.192.167.224/27 |
| Corea centrale | 52.231.17.13 | 20.194.64.32/29, 20.44.24.32/29, 52.231.16.32/29, 20.194.73.64/27 |
| Corea meridionale | 52.231.145.3 | 52.231.151.96/27, 52.231.151.88/29, 52.231.145.0/29, 52.147.112.160/27 |
| Stati Uniti centro-settentrionali | 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 settentrionale | 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 |
| Norvegia orientale | 51.120.96.0 | 51.120.208.32/29, 51.120.104.32/29, 51.120.96.32/29, 51.120.232.192/27 |
| Norvegia occidentale | 51.120.216.0 | 51.120.217.32/29, 51.13.136.224/27 |
| Sudafrica settentrionale | 102.133.152.0 | 102.133.120.32/29, 102.133.152.32/29, 102.133.248.32/29, 102.133.221.224/27 |
| Sudafrica occidentale | 102.133.24.0 | 102.133.25.32/29, 102.37.80.96/27 |
| Stati Uniti centro-meridionali | 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 |
| Asia sud-orientale | 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 |
| Svezia centrale | 51.12.96.32 | 51.12.96.32/29, 51.12.232.32/29, 51.12.224.32/29, 51.12.46.32/27 |
| Svezia meridionale | 51.12.200.32 | 51.12.201.32/29, 51.12.200.32/29, 51.12.198.32/27 |
| Svizzera settentrionale | 51.107.56.0 | 51.107.56.32/29, 51.103.203.192/29, 20.208.19.192/29, 51.107.242.32/27 |
| Svizzera occidentale | 51.107.152.0 | 51.107.153.32/29, 51.107.250.64/27 |
| Emirati Arabi Uniti centrali | 20.37.72.64 | 20.37.72.96/29, 20.37.73.96/29, 20.37.71.64/27 |
| Emirati Arabi Uniti settentrionali | 65.52.248.0 | 20.38.152.24/29, 40.120.72.32/29, 65.52.248.32/29, 20.38.143.64/27 |
| Regno Unito meridionale | 51.105.64.0 | 51.105.64.32/29, 51.105.72.32/29, 51.140.144.32/29, 51.143.209.224/27 |
| Regno Unito occidentale | 51.140.208.98 | 51.140.208.96/29, 51.140.209.32/29, 20.58.66.128/27 |
| Stati Uniti centro-occidentali | 13.71.193.34 | 13.71.193.32/29, 20.69.0.32/27 |
| Europa occidentale | 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 |
| Stati Uniti occidentali | 13.86.216.212, 13.86.217.212 | 20.168.163.192/29, 13.86.217.224/29, 20.66.3.64/27 |
| West US 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 |
| Stati Uniti occidentali 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 |
Reindirizzamento della connessione
Database di Azure per MariaDB supporta un altro criterio di connessione, il reindirizzamento che consente di ridurre la latenza di rete tra le applicazioni client e i server MariaDB. Con questa funzionalità, dopo aver stabilito la sessione TCP iniziale al server Database di Azure per MariaDB, il server restituisce l'indirizzo back-end del nodo che ospita il server MariaDB al client. In seguito, tutti i pacchetti successivi passano direttamente al server bypassando il gateway. Man mano che i pacchetti passano direttamente al server, la latenza e la velocità effettiva hanno prestazioni migliorate.
Questa funzionalità è supportata nei server Database di Azure per MariaDB con versioni del motore 10.2 e 10.3.
Il supporto per il reindirizzamento è disponibile nell'estensione PHP mysqlnd_azure sviluppata da Microsoft ed è disponibile in PECL. Per ulteriori 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 soltanto 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 dismessi. L'indirizzo IP precedente richiederà circa tre-quattro settimane prima di essere rimosso; pertanto, non deve avere nessun effetto sulle applicazioni client.
Che cosa stiamo dismettendo?
Vengono dismessi soltanto 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. Stiamo dismettendo i vecchi anelli del gateway (non gli anelli tenant in cui è in esecuzione il server). Consultare l'architettura della connettività per ulteriori chiarimenti.
Come è possibile verificare se le connessioni si trovano nei nodi del gateway precedenti o nei nuovi nodi del gateway?
Effettuare il ping del nome di dominio completo del server, come ad esempio ping xxx.mariadb.database.azure.com. Se l'indirizzo IP restituito è uno degli indirizzi IP elencati in Indirizzi IP del gateway (dismissione) 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 accertarsi che l'indirizzo IP restituito non sia uno degli indirizzi IP in fase di dismissione
Come faccio a sapere quando la manutenzione è finita e riceverò un'altra notifica quando vengono dismessi gli indirizzi IP precedenti?
Riceverai un'e-mail che ti informerà quando inizieremo 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 del 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 stringhe di connessione e l'impostazione del pool di connessioni, l'impostazione del servizio Azure Kubernetes o persino il codice sorgente.
C'è un impatto sulle connessioni dell'applicazione?
Questa manutenzione è solo una modifica DNS, quindi è trasparente per il client. Una volta che la cache DNS viene aggiornata nel client (eseguita automaticamente dal sistema operativo), tutte le nuove connessioni si connettono al nuovo indirizzo IP e tutte le connessioni esistenti continueranno a funzionare correttamente fino a quando l'indirizzo IP precedente non viene completamente rimosso, che si verifica diverse settimane dopo. E la logica di ripetizione dei tentativi non è necessaria in 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 del database nella stringa di connessione dell'applicazione. 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 accertarsi di usare il nome di dominio completo per connettersi al server del database o abilitare l'elenco dei nuovi "indirizzi IP gateway" nella stringa di connessione dell'applicazione.
Se si usa un collegamento privato, le connessioni verranno interessate?
No, si tratta di una dismissione dell'hardware del gateway e non ha nessun rapporto con il collegamento privato o con gli indirizzi IP privati; influirà soltanto sugli indirizzi IP pubblici indicati negli indirizzi IP in fase di dismissione.