En databasebelastningsbalancer eller databaseomvendt proxy fordeler den indgående databasearbejdsbelastning på tværs af flere databaseservere, der kører bagved. Målene med at have databasebelastningsbalancere er at give et enkelt databaseslutpunkt til applikationer at oprette forbindelse til, øge forespørgselsgennemstrømningen, minimere latens og maksimere ressourceudnyttelsen af databaseserverne.
Der kan være to måder til database load balancer topologi:
- Centraliseret topologi
- Distribueret topologi
I dette blogindlæg skal vi dække begge topologier og forstå nogle fordele og ulemper ved hver opsætning. Ville det også være muligt at blande begge topologier sammen?
Centraliseret topologi
I en centraliseret opsætning er en omvendt proxy placeret mellem data- og præsentationsniveauet, som repræsenteret af følgende diagram:
For at eliminere et single-point-of-failure skal man indstille op to eller flere load balancer noder til redundansformål. Hvis din applikation kan håndtere flere databaseslutpunkter, f.eks. applikationen eller databasedriveren er i stand til at udføre sundhedstjek, hvis belastningsbalanceren er sund til forespørgselsbehandling, kan du sandsynligvis springe den virtuelle IP-adressedel over. Ellers skal begge belastningsbalancer noder være bundet sammen med et fælles værtsnavn eller virtuel IP-adresse for at give gennemsigtighed til databaseklienterne, hvor det blot skal bruge et enkelt databaseslutpunkt for at få adgang til datalaget. Det er også muligt at bruge DNS eller host mapping, hvis du vil springe over at bruge virtuelle IP-adresser.
Denne tier-baserede tilgang er langt enklere at administrere på grund af dens uafhængige statiske værtsplacering. Det er meget usandsynligt, at belastningsbalanceringsniveauet skaleres ud (tilføje flere noder) på grund af dets solide fundament i robusthed, redundans og gennemsigtighed til applikationsniveauet. Du er sandsynligvis nødt til at skalere værten op (føje flere ressourcer til værten), hvilket almindeligvis vil ske længe ude i fremtiden, efter at belastningsbalancer-arbejdsbelastningen er blevet mere krævende, efterhånden som din virksomhed vokser.
Denne topologi kræver et ekstra niveau og værter, hvilket kan være dyrt i en bare-metal-infrastruktur med fysiske servere. Denne opsætning er nemmere at administrere i et cloud- eller virtuelt miljø, hvor du har fleksibiliteten til at tilføje et ekstra niveau mellem applikations- og databaseniveauet, uden at det koster dig for meget på den fysiske infrastrukturomkostninger som elektricitet, rackplads og netværksomkostninger.
Distribueret topologi
I en distribueret topologi-opsætning er belastningsbalancerne placeret i præsentationsniveauet (applikation eller webservere), som forenklet ved følgende diagram:
Applikationer behandler databasebelastningsbalanceren på samme måde som en lokal databaseserver, hvor load balancer bliver repræsentationen af fjerndatabaserne fra applikationens perspektiv. Sædvanligvis vil belastningsbalanceren lytte til den lokale netværksgrænseflade som 127.0.0.1 eller "localhost", som vil strømline databasens slutpunkts databasevært for applikationerne.
En af fordelene ved at køre i denne topologi er, at du ikke har brug for ekstra værter til belastningsbalancering. Ved at kombinere belastningsbalanceringsniveauet i præsentationsniveauet kunne vi spare mindst to værter. I et bare-metal miljø kan denne topologi potentielt spare dig for mange penge gennem årene. Generelt er belastningsbalanceringsbelastningen langt mindre krævende sammenlignet med database- eller applikationsbelastningen, hvilket gør det berettiget at dele de samme hardwareressourcer med applikationerne.
Når den er placeret sammen med applikationsserveren, bringer du den omvendte proxy tættere på applikationen og eliminerer single-point-of-failure. Dette kan forbedre applikationens ydeevne betydeligt, når du har en geografisk adskillelse mellem applikationen og datalaget, især for databasebelastningsbalancere, der understøtter resultatsæt-cache som ProxySQL og MaxScale. På den anden side er antallet af databasebelastningsbalancere almindeligvis lig med antallet af applikationsknudepunkter, hvilket betyder, at hvis applikationsniveauet skaleres op, vil antallet af databasebelastningsbalancer stige, hvilket potentielt kan forringe ydeevnen for databasens sundhed tjek service. Bemærk, at load balancer-sundhedstjek er en smule mere chattere på grund af dets ansvar for at holde trit med databasenodernes korrekte tilstand.
Ved hjælp af IT-infrastrukturautomatiseringsværktøjer som Chef, Puppet og Ansible sammen med containerorkestreringsværktøjerne er det ikke længere en umulig opgave at automatisere implementeringen og styringen af flere load balancer-instanser til denne topologi. Der vil dog være en anden læringskurve for operationsteamet til at komme med en kamptestet, produktions-grade implementering og styringspolitik for at reducere det overdrevne arbejde, når de håndterer mange load balancer noder. Gå ikke glip af alle de vigtige administrationsaspekter for databasebelastningsbalancer som backup/gendannelse, opgradering/nedgradering, konfigurationsstyring, servicekontrol, fejlhåndtering og så videre.
Distribueret topologi kan blandes sammen med den centraliserede topologi for nogle understøttede databasebelastningsbalancere som ProxySQL, som illustreret i følgende diagram:
Backend-"serverne" af en ProxySQL-instans kan være et andet sæt af ProxySQL noder i stedet for. Med denne konfiguration er en virtuel IP-adresse ikke nødvendig for enkelt endepunktsadgang til databasenoderne, da den lokale ProxySQL-instans, der hostes lokalt på applikationsserveren, vil være den enkelte endepunktsadgang fra applikationssynspunktet.
Dette kræver dog to versioner af load balancer-konfigurationer - en, der ligger på applikationsniveauet, og en anden findes på load balancer-niveauerne. Det kræver også flere værter, undtagen behovet for at lære om virtuel IP-adresseteknologi, IP-failover og så videre. Fordelene og ulemperne ved både distribuerede og centraliserede opsætninger smelter sammen i denne topologi.
Konklusion
Hver topologi har sine egne fordele og ulemper og skal planlægges godt fra begyndelsen. Denne tidlige beslutning er kritisk og kan i høj grad påvirke din applikations ydeevne, skalerbarhed, pålidelighed og tilgængelighed i det lange løb.