Un servizio di bilanciamento del carico del database, o proxy inverso del database, distribuisce il carico di lavoro del database in ingresso su più server di database in esecuzione dietro di esso. Gli obiettivi di disporre di sistemi di bilanciamento del carico del database consistono nel fornire un unico endpoint del database alle applicazioni a cui connettersi, aumentare la velocità effettiva delle query, ridurre al minimo la latenza e massimizzare l'utilizzo delle risorse dei server di database.
Esistono due modi per la topologia del servizio di bilanciamento del carico del database:
- Topologia centralizzata
- Topologia distribuita
In questo post del blog, tratteremo entrambe le topologie e comprenderemo alcuni pro e contro di ciascuna configurazione. Inoltre, sarebbe possibile mescolare entrambe le topologie insieme?
Topologia centralizzata
In una configurazione centralizzata, un proxy inverso si trova tra i dati e il livello di presentazione, come rappresentato dal diagramma seguente:
Per eliminare un singolo punto di errore, è necessario impostare su due o più nodi di bilanciamento del carico per scopi di ridondanza. Se la tua applicazione può gestire più endpoint di database, ad esempio, l'applicazione o il driver di database è in grado di eseguire controlli di integrità se il sistema di bilanciamento del carico è integro per l'elaborazione delle query, probabilmente puoi saltare la parte dell'indirizzo IP virtuale. In caso contrario, entrambi i nodi del servizio di bilanciamento del carico dovrebbero essere collegati insieme a un nome host o un indirizzo IP virtuale comune, per fornire trasparenza ai client del database in cui è sufficiente utilizzare un singolo endpoint del database per accedere al livello dati. È anche possibile utilizzare il DNS o la mappatura dell'host se si desidera saltare l'utilizzo di indirizzi IP virtuali.
Questo approccio basato su livelli è molto più semplice da gestire grazie al posizionamento indipendente dell'host statico. È molto improbabile che il livello del servizio di bilanciamento del carico venga ridimensionato (aggiungendo più nodi) a causa delle sue solide basi in termini di resilienza, ridondanza e trasparenza al livello dell'applicazione. Probabilmente dovrai aumentare la scalabilità dell'host (aggiungendo più risorse all'host), cosa che in genere accadrà a lungo in futuro, dopo che i carichi di lavoro del sistema di bilanciamento del carico saranno diventati più impegnativi man mano che la tua azienda cresce.
Questa topologia richiede un livello e host aggiuntivi, che potrebbero essere costosi in un'infrastruttura bare metal con server fisici. Questa configurazione è più facile da gestire in un ambiente cloud o virtuale, dove hai la flessibilità di aggiungere un livello aggiuntivo tra il livello dell'applicazione e quello del database, senza costi eccessivi sui costi dell'infrastruttura fisica come elettricità, spazio rack e costi di rete.
Topologia distribuita
In una configurazione di topologia distribuita, i sistemi di bilanciamento del carico sono posizionati insieme all'interno del livello di presentazione (applicazione o server Web), come semplificato dal diagramma seguente:
Le applicazioni trattano il sistema di bilanciamento del carico del database in modo simile a un server di database locale, dove il load balancer diventa la rappresentazione dei database remoti dal punto di vista dell'applicazione. In genere, il sistema di bilanciamento del carico ascolterà l'interfaccia di rete locale come 127.0.0.1 o "localhost" che semplificherà l'host del database dell'endpoint del database per le applicazioni.
Uno dei vantaggi dell'esecuzione in questa topologia è che non sono necessari host aggiuntivi per scopi di bilanciamento del carico. Combinando il livello di bilanciamento del carico all'interno del livello di presentazione, potremmo salvare almeno due host. In un ambiente bare metal, questa topologia potrebbe potenzialmente farti risparmiare molti soldi nel corso degli anni. In genere, il carico di lavoro del sistema di bilanciamento del carico è molto meno impegnativo rispetto ai carichi di lavoro di database o applicazioni, il che rende giustificabile condividere le stesse risorse hardware con le applicazioni.
Quando si trova insieme al server delle applicazioni, avvicini il proxy inverso all'applicazione ed elimini il singolo punto di errore. Ciò può migliorare significativamente le prestazioni dell'applicazione quando si dispone di una separazione geografica tra l'applicazione e il livello dati, in particolare per i servizi di bilanciamento del carico del database che supportano la memorizzazione nella cache del set di risultati come ProxySQL e MaxScale. D'altra parte, il numero di sistemi di bilanciamento del carico del database è comunemente uguale al numero di nodi dell'applicazione, il che significa che se il livello dell'applicazione viene ampliato, il numero di sistemi di bilanciamento del carico del database aumenterà, il che potrebbe potenzialmente ridurre le prestazioni per l'integrità del database servizio di controllo. Tieni presente che i controlli di integrità del sistema di bilanciamento del carico sono un po' più chiacchieroni a causa della sua responsabilità di tenere il passo con lo stato corretto dei nodi del database.
Con l'aiuto di strumenti di automazione dell'infrastruttura IT come Chef, Puppet e Ansible insieme agli strumenti di orchestrazione dei container, automatizzare la distribuzione e la gestione di più istanze di bilanciamento del carico per questa topologia non è più un compito impossibile. Tuttavia, ci sarà un'altra curva di apprendimento per il team operativo per elaborare politiche di distribuzione e gestione di livello di produzione testate in battaglia per ridurre il lavoro eccessivo durante la gestione di molti nodi di bilanciamento del carico. Non perdere tutti gli aspetti di gestione importanti per il bilanciamento del carico del database come backup/ripristino, aggiornamento/downgrade, gestione della configurazione, controllo del servizio, gestione degli errori e così via.
La topologia distribuita può essere combinata con la topologia centralizzata per alcuni sistemi di bilanciamento del carico di database supportati come ProxySQL, come illustrato nel diagramma seguente:
I "server" di back-end di un'istanza ProxySQL possono essere un altro insieme di ProxySQL nodi invece. Con questa configurazione, non è necessario un indirizzo IP virtuale per l'accesso a un endpoint singolo ai nodi del database, poiché l'istanza ProxySQL locale ospitata localmente sul server delle applicazioni sarà l'accesso a un endpoint singolo dal punto di vista dell'applicazione.
Tuttavia, ciò richiede due versioni delle configurazioni del servizio di bilanciamento del carico:una che risiede nel livello dell'applicazione e un'altra che risiede nei livelli del servizio di bilanciamento del carico. Richiede inoltre più host, escludendo la necessità di conoscere la tecnologia degli indirizzi IP virtuali, il failover IP e così via. I vantaggi e gli svantaggi delle configurazioni distribuite e centralizzate sono la fusione in questa topologia.
Conclusione
Ogni topologia ha i suoi vantaggi e svantaggi e deve essere ben pianificata dall'inizio. Questa decisione precoce è fondamentale e può influenzare enormemente le prestazioni, la scalabilità, l'affidabilità e la disponibilità delle applicazioni a lungo termine.
