Gli ambienti ibridi, in cui una parte dell'infrastruttura del database si trova in locale e parte di essa si trova in un cloud pubblico non sono rari. Potrebbero esserci diversi motivi per utilizzare tale configurazione:scalabilità, flessibilità, disponibilità elevata, ripristino di emergenza. Come implementare questa configurazione in modo corretto? Questo potrebbe essere impegnativo in quanto devi considerare diversi pezzi di un puzzle che devono combaciare. Questo blog ha lo scopo di darti alcuni spunti su come potrebbe apparire una tale configurazione.
Connettività
Non entreremo nei dettagli qui perché ci sono molti modi per configurare la connettività tra la tua configurazione in loco e il cloud pubblico. Dipenderà dall'infrastruttura di cui disponi, dal cloud pubblico che desideri utilizzare e da molti altri fattori. La gamma di opzioni può iniziare con router abilitati BGP, tramite VPN hardware, VPN software che finisce su tunnel SSH come un modo per connettere temporaneamente la tua rete alle istanze in un cloud pubblico. Ciò che è importante, qualunque cosa tu faccia, il risultato finale dovrebbe essere una connettività completa e trasparente dalla tua rete locale alle istanze situate nel cloud pubblico.
Considerazioni sull'elevata disponibilità
La replica MySQL è un ottimo modo per creare sistemi ad alta disponibilità, ma presenta limitazioni significative. La cosa principale da considerare è lo scrittore - puoi avere solo un posto a cui inviare i tuoi scritti - il maestro. Non importa come vuoi progettare l'intero ambiente, devi considerare attentamente il posizionamento del master. Molto probabilmente vuoi che faccia parte dell'ambiente, che contiene gli host dell'applicazione. Consideriamo la seguente configurazione:
Abbiamo una configurazione in loco con tre nodi MySQL e due slave aggiuntivi situato nel cloud pubblico, fungendo da mezzo di ripristino di emergenza per l'azienda, è abbastanza chiaro che il nodo scrivibile dovrebbe essere collocato con gli host dell'applicazione nella parte privata del cloud. Vogliamo mantenere la latenza il più bassa possibile per le connessioni che contano di più.
Questo tipo di progettazione si concentra sulla disponibilità dei database - se i nodi localizzati in locale non saranno disponibili, gli host dell'applicazione potrebbero essere in grado di connettersi alla parte remota dell'installazione - i nodi del database individuati nel cloud pubblico. Idealmente, dovresti utilizzare una sorta di proxy per questo:ProxySQL è una delle soluzioni in grado di tracciare la topologia e riconfigurare secondo necessità in base alla catena di replica esistente.
Se vuoi considerare più di una configurazione attivo-attivo in cui hai nodi applicativi sia privati che pubblici, devi scendere a compromessi poiché le scritture dovranno essere trasferite sulla WAN, dal cloud pubblico al cloud privato (o viceversa, se la tua posizione principale in cui operi nel cloud pubblico).
Anche in questo caso, ProxySQL è il proxy preferito. La cosa fantastica è che ProxySQL può essere configurato come un cluster ProxySQL, assicurando che le modifiche alla configurazione introdotte in un nodo vengano replicate sui nodi ProxySQL rimanenti.
Gestione degli errori
Consideriamo un paio di scenari di errore. Prima di tutto, dobbiamo tenere a mente che la replica asincrona MySQL non è a conoscenza del cluster, quindi la divisione della rete è qualcosa che deve essere gestita manualmente:spetterà all'utente prendere la decisione e premere l'interruttore per promuovere uno dei gli schiavi nell'ambiente disponibile. Spetta inoltre all'utente garantire che l'ambiente, che ha perso la connettività di rete, si comporti come dovrebbe e non continui a funzionare.
Se la parte privata del cloud non sarà più disponibile, come accennato in precedenza, sarà necessaria un'azione manuale per promuovere uno degli slave a diventare un nuovo master. Quindi tutti i server di applicazioni Web rimanenti situati nel cloud pubblico, utilizzando ProxySQL locale, avranno il loro traffico reindirizzato al nuovo master e tutti gli slave rimanenti. D'altra parte, dato che abbiamo perso tre nodi MySQL su cinque, vogliamo aumentare la configurazione del cloud pubblico:ClusterControl può aiutarti ad aggiungere in modo efficiente nodi aggiuntivi al tuo cluster.
Un altro scenario potrebbe essere l'arresto anomalo dello scrittore mentre la connettività tra la nostra configurazione in locale e il cloud pubblico funziona correttamente.
In uno scenario del genere vogliamo promuovere uno degli schiavi a diventare un nuovo padrone. A seconda dei requisiti, potremmo anche voler promuovere il nuovo master tra i nodi in una determinata parte dell'ambiente. ClusterControl ha la capacità di inserire nella whitelist o nella blacklist i nodi per il failover, assicurandoti il pieno controllo del processo di failover e che puoi scegliere quali nodi devono essere considerati come candidati per un nuovo master e in quale ordine.
Ci auguriamo che questo blog ti abbia dato un'idea di come funziona la configurazione del cloud ibrido per la replica di MySQL e di come può proteggerti in caso di guasti al database o alla rete.
