Stai cercando di iniziare con il database open source più famoso al mondo e ti stai chiedendo come dovresti configurare il tuo hosting MySQL? Così tanti utilizzano Amazon RDS per impostazione predefinita, quando MySQL si comporta eccezionalmente bene su Azure Cloud. Sebbene Microsoft Azure offra una soluzione gestita, Database di Azure, la soluzione presenta alcune limitazioni importanti che dovresti conoscere prima di migrare le distribuzioni MySQL. In questo post descriviamo il modo migliore per ospitare MySQL in Azure, incluse soluzioni gestite, tipi di istanza, replica ad alta disponibilità, backup e tipi di dischi da utilizzare per ottimizzare le prestazioni del database cloud.
MySQL DBaaS vs. MySQL autogestito
La prima cosa da considerare quando si valuta tra l'autogestione e una soluzione MySQL Database-as-a-Service (DBaaS) è quali risorse interne si hanno a disposizione. Se stai leggendo questo, probabilmente conosci già l'entità delle attività operative associate al mantenimento di un'implementazione di produzione, ma per un breve riepilogo, ci sono provisioning, deprovisioning, configurazioni master-slave, backup, ridimensionamento, aggiornamenti, rotazioni dei log, patch del sistema operativo e monitoraggio per citarne alcuni.
Un esperto MySQL interno, o un team di DBA a seconda delle dimensioni dell'applicazione, può sicuramente gestirli con la tua organizzazione per te, ma la domanda diventa dove vuoi concentrare gli sforzi del tuo team . Molti decidono di passare a un DBaaS MySQL per automatizzare queste attività che richiedono tempo in modo da potersi concentrare maggiormente sullo sviluppo e sull'ottimizzazione dei database delle loro applicazioni. Un buon esempio potrebbe essere l'analisi lenta della query. Sebbene quasi tutti i DBaaS offrano uno strumento MySQL Slow Query Analyzer per aiutare a identificare le query problematiche, questa attività richiede comunque abilità e intuizione umane per determinare come ottimizzare quelle query che influiscono sulle prestazioni delle loro applicazioni.
Che tu sia una startup o un'azienda Fortune 500, scoprirai che molte organizzazioni scelgono di sfruttare un DBaaS per ottimizzare il tempo del proprio DBA, mentre le stesse tipologie e dimensioni di attività scegli anche di attenersi all'autogestione interna. Per molte aziende, la decisione si riduce in gran parte alla personalizzazione e al controllo. Questo è il motivo per cui mettiamo in guardia contro l'impostazione predefinita del database di Azure, o del suo concorrente AWS, Amazon RDS, in quanto non consentono di mantenere l'accesso ai superuser MySQL o persino l'accesso SSH alle tue macchine. Inoltre, la possibilità di personalizzare la configurazione della distribuzione è molto limitata, ad esempio i tipi di istanza, la RAM, le dimensioni del disco o gli IOPS che puoi utilizzare. Scoprirai di più sui migliori tipi di istanze e dischi da utilizzare di seguito e puoi consultare questo confronto dei provider MySQL per vedere i vantaggi e i limiti delle prime quattro soluzioni MySQL gestite, ScaleGrid, Compose, Database di Azure e Amazon RDS.
Distribuzione ad alta disponibilità
Se stai implementando in produzione, dovresti sempre configurare MySQL come distribuzione master-slave. Le distribuzioni standalone sono un singolo nodo senza alcuna replica e dovrebbero essere utilizzate solo per ambienti di sviluppo o test. Con le implementazioni master-slave, puoi configurare l'alta disponibilità, quindi se uno dei tuoi nodi si interrompe, puoi eseguire il failover su uno slave senza tempi di inattività. Questo è in genere impostato come quorum master-slave-slave a 3 nodi o quorum master-slave a 2+1 nodi. Il vantaggio dell'utilizzo di un quorum è che è un'alternativa a basso costo, ma lo svantaggio è che hai solo 2 nodi portanti dati poiché l'altro funge da nodo quorum per determinare il miglior corso di failover. Se la tua applicazione è in grado di leggere dallo slave, devi eseguire il ridimensionamento della lettura in modo che restituiscano gli stessi dati dal volume del cluster con un ritardo minimo.
Il modo migliore per ospitare MySQL su Azure CloudClick To Tweet
Quando si utilizza una configurazione MySQL master-slave, si consiglia di impostare la replica semisincrona per migliorare l'integrità dei dati con la ridondanza dei dati. Ciò garantisce che quando un commit viene restituito correttamente, i dati esistono sia nel master che nello slave, quindi nel caso in cui un datacenter si interrompa, il tuo master MySQL può eseguire il failover su uno slave senza alcuna perdita di dati. Puoi farlo con la replica asincrona o semisincrona e saperne di più nel nostro post sul blog Spiegazione dell'elevata disponibilità di MySQL - Parte II.
Quindi, come configuriamo la disponibilità elevata per MySQL in Azure? Dobbiamo distribuire le nostre istanze slave tra diverse zone di disponibilità di Azure (AZ). Pertanto, vogliamo assicurarci di scegliere un'area di Azure con almeno 3 AZ, inserendo ogni istanza in un'AZ diversa. Lo facciamo perché le garanzie di disponibilità sono tra le AZ, quindi se 1 zona si interrompe, il database dell'applicazione è ancora in grado di rimanere online attraverso le altre 2 AZ. Le zone di disponibilità sono abbastanza nuove per Azure, quindi se lavori in un'area che non offre AZ, hai la possibilità di usare i set di disponibilità. Questi sono leggermente più deboli degli AZ, ma assicurati di essere distribuito su diversi domini e rack per proteggerti da una potenziale interruzione. C'è anche la possibilità di distribuire in più regioni, ma questa è una configurazione più complicata, quindi ti consigliamo di contattarci per discutere prima dell'implementazione.
Reti virtuali di Azure
Il modo migliore per proteggere il database da Internet è implementarlo in una sottorete privata per assicurarsi che non sia esposto. Azure semplifica la configurazione tramite l'uso di una rete virtuale (VNET) che può essere configurata per i server MySQL. Con una rete virtuale di Azure per MySQL, puoi configurare comunicazioni sicure tra i tuoi server, Internet e persino la tua rete di cloud privato locale. Questi sono in genere configurati per comunicare su una singola rete, ma se devi connettere più di un'area, puoi creare più reti virtuali per comunicare tramite peering di rete virtuale.
Inoltre, puoi gestire il controllo dell'accesso MySQL tramite le regole dei gruppi di sicurezza di rete (NSG) senza dover gestire le whitelist IP. Questo non è disponibile tramite Database di Azure per MySQL, ma sia VNET che NSG possono essere configurati tramite i nostri piani MySQL Bring Your Own Cloud (BYOC) in Azure, dove puoi ospitare i tuoi cluster tramite il tuo account cloud.
Tipi di istanza di Azure
Un altro aspetto importante da considerare sono le prestazioni delle tue istanze MySQL nel cloud pubblico. Il cloud di Azure offre più tipi di istanze che possono essere usati per l'hosting MySQL, inclusi Es2 v3, Ds2, v2 e Ls4.
Ti consigliamo di iniziare con un tipo di istanza ottimizzato per la memoria poiché i database richiedono molta RAM e cercano la velocità del disco più veloce possibile per le migliori prestazioni. La serie Es2 è in genere un buon punto di partenza per la maggior parte delle applicazioni dei carichi di lavoro MySQL. Da lì, puoi eseguire alcuni test delle prestazioni per vedere se hai bisogno di più CPU, nel qual caso, tipi di istanza bilanciati o tipi di istanza ad alta intensità di CPU potrebbero soddisfare meglio le tue esigenze MySQL, come i tipi di istanza Dv3. I tuoi test delle prestazioni potrebbero anche mostrare che hai bisogno di più I/O (input/output), puoi passare a un tipo di istanza a uso intensivo del disco.
Se prevedi di sfruttare Azure come provider di servizi cloud MySQL per i prossimi 1-3 anni e di mantenere configurazioni di distribuzione abbastanza coerenti, puoi anche considerare le istanze riservate. Si tratta essenzialmente di istanze prepagate che consentono di ottenere notevoli risparmi sui costi per l'hosting MySQL. In media, puoi risparmiare dal 20% al 30% circa per le istanze riservate di un anno e dal 40% al 50% sulle istanze riservate di 3 anni.
Tipi di dischi di Azure
La prima determinazione da prendere quando si tratta di scegliere un tipo di disco di Azure per le distribuzioni MySQL è se scegliere un disco gestito o non gestito. I dischi non gestiti sono i dischi legacy offerti da Azure in cui è necessario configurare l'account di archiviazione, eseguire il mapping del disco all'account di archiviazione e monitorare l'uso IOPS e i limiti per tale account di archiviazione. Ti consigliamo vivamente di utilizzare i dischi gestiti e, se stai ancora distribuendo con dischi non gestiti, dovresti considerare di passare a quelli gestiti.
Ambiente di sviluppo/test MySQL:dischi standard
Sono disponibili più tipi di dischi gestiti tramite Azure, l'impostazione predefinita sono i dischi standard. I dischi standard possono supportare fino a 500 IOPS (operazioni di input/output al secondo) e sono utili per le operazioni di sviluppo e test in quanto possono essere ridimensionati dinamicamente, ma non devono essere utilizzati per le implementazioni di produzione MySQL.
Distribuzioni di produzione MySQL:dischi Premium
Per i server di produzione MySQL, consigliamo vivamente di sfruttare i dischi di Azure Premium. Ci sono un'ampia varietà di dischi premium tra cui puoi scegliere. Per ogni disco premium, puoi scegliere la dimensione migliore e ogni dimensione include IOPS con provisioning diversi in modo da poter selezionare quello più adatto alle tue esigenze applicative.
Distribuzioni di produzione MySQL:SSD locale
Gli SSD locali di Azure sono un'alternativa ad alte prestazioni ai dischi premium, in genere più adatti per cluster di grandi dimensioni. Gli SSD locali offrono prestazioni di I/O molto più elevate e la migliore velocità effettiva in Azure. Tuttavia, hanno uno svantaggio in quanto sono dischi effimeri, non un archivio permanente, quindi se interrompi l'istanza, i dati scompaiono. Raccomandiamo la serie Ls v2 che è molto veloce, ma attenzione che la CPU è molto debole e può causare colli di bottiglia della macchina.
Backup MySQL in Azure
Il modo migliore per eseguire il backup dei dati MySQL in Azure consiste nell'usare snapshot del disco gestiti. Uno snapshot è una versione point-in-time di sola lettura di un disco. Questi backup possono essere letti, copiati o eliminati, ma tieni presente che non possono essere modificati. È una buona idea eseguire backup completi in modo che tutti i database, gli utenti e le impostazioni vengano sottoposti a backup sull'istanza nel caso in cui sia necessario ripristinare un database MySQL. È anche una buona idea crittografare gli snapshot di backup in modo che il backup possa essere ripristinato solo sul computer in cui è stato eseguito il backup.
I tuoi backup MySQL comporteranno costi aggiuntivi per l'archiviazione dei dati di Azure, a meno che tu non stia sfruttando una soluzione MySQL su Azure all-inclusive come i nostri piani di hosting dedicato su ScaleGrid. Per controllare i costi, è una buona idea automatizzare i backup attraverso una pianificazione personalizzabile che ti consente di configurare la frequenza dei backup, il numero massimo di backup da conservare e la destinazione del backup. Questo ovviamente ti aiuta anche a garantire che i tuoi dati MySQL vengano regolarmente sottoposti a backup in caso di perdita di dati nella tua distribuzione di produzione in modo da poterli ripristinare rapidamente con un backup recente.
Se hai domande sul modo migliore per ospitare MySQL su Azure, lasciaci un commento qui sotto o contattaci all'indirizzo support@scalegrid. io. Puoi anche iniziare una prova gratuita di 30 giorni per esplorare i vantaggi dell'utilizzo di un servizio MySQL completamente gestito per migliorare le prestazioni delle tue implementazioni.
