En databaslastbalanserare, eller databasomvänd proxy, fördelar den inkommande databasarbetsbelastningen över flera databasservrar som körs bakom den. Målen med att ha databasbelastningsutjämnare är att tillhandahålla en enda databasslutpunkt till applikationer att ansluta till, öka sökgenomströmningen, minimera latensen och maximera resursutnyttjandet av databasservrarna.
Det kan finnas två sätt för databasbelastningsutjämnartopologi:
- Centraliserad topologi
- Distribuerad topologi
I det här blogginlägget kommer vi att täcka både topologier och förstå några för- och nackdelar med varje installation. Skulle det också vara möjligt att blanda båda topologierna tillsammans?
Centraliserad topologi
I en centraliserad konfiguration finns en omvänd proxy placerad mellan data- och presentationsnivån, som representeras av följande diagram:
För att eliminera en single-point-of-failure måste man ställa in upp två eller flera lastbalanseringsnoder för redundansändamål. Om din applikation kan hantera flera databasslutpunkter, till exempel kan applikationen eller databasdrivrutinen utföra hälsokontroller om belastningsutjämnaren är bra för frågebehandling, kan du förmodligen hoppa över den virtuella IP-adressdelen. Annars bör båda belastningsutjämnarnoderna knytas ihop med ett gemensamt värdnamn eller virtuell IP-adress, för att ge insyn till databasklienterna där den bara behöver använda en enda databasslutpunkt för att komma åt datanivån. Att använda DNS eller värdmappning är också möjligt om du vill hoppa över att använda virtuella IP-adresser.
Denna nivåbaserade metod är mycket enklare att hantera på grund av dess oberoende statiska värdplacering. Det är mycket osannolikt att lastbalanseringsnivån skalas ut (lägger till fler noder) på grund av dess solida grund i elasticitet, redundans och transparens till applikationsnivån. Du behöver antagligen skala upp värden (lägga till mer resurser till värden), vilket vanligtvis kommer att hända långt borta i framtiden, efter att arbetsbelastningen för belastningsbalanseraren har blivit mer krävande när ditt företag växer.
Den här topologin kräver en extra nivå och värdar, vilket kan vara kostsamt i en infrastruktur av ren metall med fysiska servrar. Den här installationen är enklare att hantera i en moln eller virtuell miljö, där du har flexibiliteten att lägga till en extra nivå mellan applikationen och databasnivån, utan att det kostar dig för mycket på den fysiska infrastrukturkostnaden som el, rackutrymme och nätverkskostnader.
Distribuerad topologi
I en distribuerad topologiinställning är lastbalanserarna samlokaliserade inom presentationsnivån (applikation eller webbservrar), vilket förenklas av följande diagram:
Applikationer behandlar databasens belastningsbalanserare på samma sätt som en lokal databasserver, där load balancer blir representationen av fjärrdatabaserna ur applikationens perspektiv. Vanligtvis kommer belastningsutjämnaren att lyssna på det lokala nätverksgränssnittet som 127.0.0.1 eller "localhost" som kommer att effektivisera databasens slutpunktsdatabasvärd för applikationerna.
En av fördelarna med att köra i denna topologi är att du inte behöver extra värdar för lastbalansering. Genom att kombinera lastbalanseringsnivån inom presentationsnivån kunde vi spara minst två värdar. I en barmetallmiljö kan denna topologi potentiellt spara dig mycket pengar genom åren. I allmänhet är belastningsutjämnarens arbetsbelastning mycket mindre krävande jämfört med databas- eller applikationsarbetsbelastningar, vilket gör det motiverat att dela samma hårdvaruresurser med applikationerna.
När den är samlokaliserad med applikationsservern, tar du den omvända proxyn närmare applikationen och eliminerar den enda felpunkten. Detta kan avsevärt förbättra applikationens prestanda när du har en geografisk separation mellan applikationen och datanivån, särskilt för databasbelastningsutjämnare som stöder resultatuppsättningscache som ProxySQL och MaxScale. Å andra sidan är antalet databaslastbalanserare vanligtvis lika med antalet programnoder, vilket betyder att om programnivån skalas upp kommer antalet databaslastbalanserare att öka vilket potentiellt kan försämra prestandan för databashälsan kontrollera service. Observera att hälsokontrollerna för lastbalanseraren är lite mer pratsamma på grund av dess ansvar att hålla jämna steg med databasnodernas korrekta tillstånd.
Med hjälp av automationsverktyg för IT-infrastruktur som Chef, Puppet och Ansible tillsammans med containerorkestreringsverktygen är det inte längre en omöjlig uppgift att automatisera distributionen och hanteringen av flera lastbalanseringsinstanser för denna topologi. Det kommer dock att finnas en annan inlärningskurva för operationsteamet att komma med en stridstestad, produktionsklassad implementering och hanteringspolicy för att minska det överdrivna arbetet vid hantering av många belastningsutjämnarnoder. Missa inte alla viktiga hanteringsaspekter för databaslastbalanserare som säkerhetskopiering/återställning, uppgradering/nedgradering, konfigurationshantering, servicekontroll, felhantering och så vidare.
Distribuerad topologi kan blandas med den centraliserade topologin för vissa stödda databaslastbalanserare som ProxySQL, som illustreras i följande diagram:
Backend-"servrarna" för en ProxySQL-instans kan vara en annan uppsättning av ProxySQL noder istället. Med den här konfigurationen är en virtuell IP-adress inte nödvändig för åtkomst till en enda ändpunkt till databasnoderna, eftersom den lokala ProxySQL-instansen som är värd lokalt på applikationsservern kommer att vara den enda ändpunktsåtkomsten från applikationssynpunkt.
Detta kräver dock två versioner av lastbalanseringskonfigurationer - en som finns på applikationsnivån och en annan finns på lastbalanseringsnivåerna. Det kräver också fler värdar, exklusive behovet av att lära sig om virtuell IP-adressteknik, IP-failover och så vidare. Fördelarna och nackdelarna med både distribuerade och centraliserade inställningar är sammansmälta i denna topologi.
Slutsats
Varje topologi har sina egna fördelar och nackdelar och måste vara välplanerad från början. Detta tidiga beslut är avgörande och kan i stor utsträckning påverka din applikations prestanda, skalbarhet, tillförlitlighet och tillgänglighet på lång sikt.