Vyrovnávání zátěže zvyšuje výkon systému, zejména z hlediska aplikace, a umožňuje několika počítačům obsluhovat stejná data. Funguje to tak, že zatížení je distribuováno mezi klientské dotazy na replikované uzly kromě jeho primárního nebo hlavního uzlu, zatímco změny databáze jsou směrovány pouze do hlavního uzlu. Jakékoli úpravy hlavního uzlu jsou následně přeneseny do každé repliky pomocí PostgreSQL Streaming Replication.
Jak mohou nástroje Load Balancers ovlivnit PostgreSQL?
Využití vyvažování zátěže nasměruje klientské aplikace k připojení k serveru pro vyrovnávání zátěže a distribuuje zahájená připojení k dostupným uzlům PostgreSQL v závislosti na typu požadavků dotazu. To pomáhá zdůraznit mimořádné zatížení na konkrétním serveru PostgreSQL a podporuje paralelní vyvážení zatížení mezi dostupnými uzly v clusteru.
Pomocí PostgreSQL již existuje několik existujících řešení, aby to fungovalo. Tato řešení mohou fungovat hladce nebo vyvažování zátěže může fungovat se současnou topologií – s primárními a pohotovostními uzly – ale vyvažování zátěže je implementováno v samotné aplikační vrstvě. Vyrovnávání zátěže čelí problémům se synchronizací, což je základní problém pro servery, které spolupracují. Protože neexistuje jediné řešení, které by eliminovalo dopad problému se synchronizací pro všechny případy použití, existuje několik řešení. Každé řešení řeší tento problém jiným způsobem a minimalizuje jeho dopad na konkrétní pracovní zátěž.
V tomto blogu se podíváme na tyto nástroje pro vyrovnávání zátěže a porovnáme je a jak přínosné jsou pro vaši zátěž PostgreSQL.
HAProxy Load Balancing pro PostgreSQL
HAProxy je událostmi řízený, neblokující engine kombinující proxy s velmi rychlou I/O vrstvou a vícevláknovým plánovačem založeným na prioritách. Jelikož je navržen s ohledem na cíl předávání dat, jeho architektura je navržena tak, aby fungovala v odlehčeném procesu, který je optimalizován pro co nejrychlejší přesun dat s co nejmenším počtem operací. Zaměřuje se na optimalizaci efektivity mezipaměti procesoru tím, že připojení ke stejnému procesoru zůstane co nejdéle. Jako takový implementuje vrstvený model nabízející mechanismy přemostění na každé úrovni zajišťující, že data nedosáhnou vyšších úrovní, pokud to není nutné. Většina zpracování se provádí v jádře. HAProxy se ze všech sil snaží pomoci jádru dělat práci co nejrychleji tím, že dává nějaké rady nebo se vyhýbá určitým operacím, když se domnívá, že by mohly být seskupeny později. Ve výsledku typické údaje ukazují 15 % doby zpracování strávené v HAProxy oproti 85 % v jádře v režimu uzavření TCP nebo HTTP a asi 30 % u HAProxy oproti 70 % u jádra v režimu udržování HTTP.
HAProxy má také další funkce vyrovnávání zátěže. Například funkce TCP proxying nám umožňuje používat ji pro databázová připojení, zejména pro PostgreSQL, pomocí vestavěné podpory kontrolní služby. I když existuje podpora databázových služeb, nedostačuje požadované kontrole stavu, zejména pro typ replikace clusteru. Standardním přístupem při nasazování do produkčního prostředí je použití kontroly TCP a poté závislost na xinetd s HAProxy.
Výhody použití HAProxy pro PostgreSQL
Nejlepší na HAProxy je jeho lehkost, snadná konfigurace a použití a funguje podle očekávání. Použití HAProxy nad clusterem PostgreSQL bylo implementováno a nasazeno několikrát od velkých organizací po různé malé a střední podniky/malé a střední podniky pro jejich produkční použití. Dlouhodobě se osvědčil pro produkční a vysokou kapacitu zátěže nejen pro databáze, ale dokonce i s dalšími síťovými službami, jako jsou webové aplikace nebo pro geo-load balancing (distribuce provozu mezi více datových center). Díky HAProxy nad PostgreSQL umožňuje uživatelům omezit nebo omezit odezvy za účelem paralelizace a správné distribuce zátěže na všechny dostupné uzly v clusteru. Vestavěný mechanismus s HAProxy také umožňuje uživateli plynule nastavit vysokou dostupnost a snadněji škálovat, pokud je potřeba zatížení, a vyhnout se selhání jednoho bodu (SPOF).
Nevýhody použití HAProxy pro PostgreSQL
HAProxy neposkytuje filtrování dotazů ani analýzu dotazů k identifikaci typu požadovaných příkazů. Postrádá schopnost provádět rozdělení čtení/zápisu na jednom portu. Nastavení load balanceru nad HAProxy vyžaduje, abyste museli alespoň nastavit různé porty pro vaše zápisy a jiné pro vaše čtení. To vyžaduje změny aplikace, aby vyhovovaly vašim potřebám.
HAProxy také poskytuje velmi jednoduchou podporu funkcí s PostgreSQL pro kontrolu stavu, ale to pouze určuje, zda je uzel aktivní nebo ne, jako by právě pingnul na uzel a čekal na odpověď. Neidentifikuje, jakou roli se uzel pokouší předat požadovaná připojení z klienta na požadovaný uzel. Proto nerozumí nebo žádná funkce v HAProxy porozumět topologii replikace. Uživatel sice může vytvořit samostatné posluchače založené na různých portech, ale přesto přidává změny v rámci aplikace, aby uspokojil potřeby vyrovnávání zátěže. To znamená, že buď použití externího skriptu s xinetd může být řešením pro splnění požadavků. Přesto není integrován do HAProxy a může být náchylný k lidské chybě.
Pokud musí být jeden uzel nebo skupina uzlů uvedena do režimu údržby, budete také muset provést změny ve svém HAProxy, jinak to může být katastrofální.
Pgpool-II pro vyrovnávání zátěže vašeho PostgreSQL
Pgpool-II je software s otevřeným zdrojovým kódem a je podporován masivní komunitou PostgreSQL pro implementaci vyvažování zátěže a její použití jako jejich middleware od aplikace až po vrstvu proxy a poté distribuuje zátěž poté, co plně analyzuje typ požadavku na dotaz nebo připojení k databázi. Pgpool-II je tam tak dlouho od roku 2003, který se původně jmenoval Pgpool, až se z něj v roce 2006 stal Pgpool-II, který slouží jako důkaz velmi stabilního proxy nástroje nejen pro vyrovnávání zátěže, ale také spoustu skvělých funkcí. .
Pgpool-II je známý jako švýcarský armádní nůž pro PostgreSQL a je to proxy software, který je umístěn mezi servery PostgreSQL a databázovým klientem PostgreSQL. Základní myšlenkou PgPool-II je, že sedí na klientovi, poté se dotazy na čtení musí doručovat do pohotovostních uzlů, zatímco zápis nebo úpravy jdou přímo do primárního. Jedná se o velmi inteligentní řešení vyvažování zátěže, které nejen vyrovnává zátěž, ale také podporuje vysokou dostupnost a poskytuje sdružování připojení. Inteligentní mechanismus umožňuje vyvážení zátěže mezi master a slave. Zápisy se tedy načítají do hlavního serveru, zatímco zpracování čtení je směrováno na dostupné servery pouze pro čtení, což jsou vaše údajně horké pohotovostní uzly. Pgpool-II také poskytuje logickou replikaci. I když se jeho použití a význam snížily s tím, jak se zlepšily možnosti vestavěné replikace na straně serveru PostgreSQL, stále zůstává cennou možností pro starší verze PostgreSQL. Kromě toho také poskytuje sdružování připojení.
Pgpool-II má pokročilejší architekturu než PgBouncer, aby podporoval všechny funkce, které má. Protože oba podporují sdružování připojení, druhý jmenovaný nemá žádné funkce pro vyrovnávání zátěže.
Pgpool-II může spravovat více serverů PostgreSQL. Použití funkce replikace umožňuje vytvoření zálohy v reálném čase na 2 nebo více fyzických disků, takže služba může pokračovat bez zastavení serverů v případě selhání disku. Vzhledem k tomu, že Pgpool-II je také schopný sdružování připojení, může poskytnout omezení překročení počtu připojení. Existuje limit na maximální počet souběžných připojení s PostgreSQL a po tomto počtu připojení jsou připojení odmítnuta. Nastavení maximálního počtu připojení však zvyšuje spotřebu prostředků a ovlivňuje výkon systému. pgpool-II má také limit na maximální počet připojení, ale další připojení budou zařazena do fronty namísto okamžitého vracení chyby.
Při vyvažování zátěže Pokud je databáze replikována, provedení SELECT dotazu na libovolném serveru vrátí stejný výsledek. pgpool-II využívá funkci replikace ke snížení zátěže každého PostgreSQL serveru distribucí SELECT dotazů mezi více serverů, čímž zlepšuje celkovou propustnost systému. V nejlepším případě se výkon zvyšuje úměrně počtu serverů PostgreSQL. Vyvážení zatížení funguje nejlépe v situaci, kdy mnoho uživatelů provádí mnoho dotazů současně.
Pomocí funkce paralelního dotazu lze data rozdělit mezi více serverů, takže dotaz lze provádět na všech serverech současně, čímž se zkrátí celková doba provádění. Paralelní dotaz funguje nejlépe při vyhledávání rozsáhlých dat.
Výhody používání Pgpool pro PostgreSQL
Je to funkčně bohatý typ softwaru nejen pro vyrovnávání zátěže. Základní funkce a podpora tohoto nástroje je vysoce na vyžádání a poskytuje sdružování připojení, alternativní go PgBouncer, nativní replikaci, online obnovu, ukládání do mezipaměti dotazů v paměti, automatické převzetí služeb při selhání a vysokou dostupnost s jeho dílčím procesem využívajícím watchdog. Tento nástroj je tak starý a je neustále masivně podporován komunitou PostgreSQL, takže řešení problémů nemůže být těžké vyhledat pomoc. Dokumentace je zde vaším přítelem při hledání otázek, ale hledání pomoci v komunitě není obtížné a skutečnost, že tento nástroj je open-source, takže jej můžete volně používat, pokud dodržujete licenci BSD.
Pgpool-II má také analyzátor SQL. To znamená, že je schopen přesně analyzovat SQL a přepsat dotaz. To umožňuje Pgpool-II zvýšit paralelismus v závislosti na požadavku dotazu.
Nevýhody použití Pgpool pro PostgreSQL
Pgpool-II nenabízí STONITH (vystřelí druhý uzel do hlavy), který poskytuje mechanismus oplocení uzlu. Pokud PostgreSQL server selže, zachová dostupnost služby. Pgpool-II může být také jediným bodem selhání (SPOF). Jakmile dojde k výpadku uzlu, připojení k databázi a dostupnost se od tohoto bodu zastaví. Ačkoli to lze napravit redundancí s Pgpool-II a nutností použít watchdog ke koordinaci více uzlů Pgpool-II, přidává to práci navíc.
Pokud jde o sdružování připojení, bohužel pro ty, kteří se zaměřují pouze na sdružování připojení, to, co Pgpool-II příliš nedělá, je sdružování připojení, zejména pro malý počet klientů. Protože každý podřízený proces má svůj vlastní fond a neexistuje způsob, jak kontrolovat, který klient se připojuje ke kterému podřízenému procesu, příliš mnoho je ponecháno na štěstí, pokud jde o opětovné použití připojení.
Použití ovladače JDBC pro vyrovnávání zatížení vašeho PostgreSQL
Java Database Connectivity (JDBC) je aplikační programovací rozhraní (API) pro programovací jazyk Java, které definuje, jak může klient přistupovat k databázi. Je součástí platformy Java Standard Edition a poskytuje metody dotazování a aktualizace dat v databázi a je orientován na relační databáze.
Ovladač PostgreSQL JDBC (zkráceně PgJDBC) umožňuje programům Java připojit se k databázi PostgreSQL pomocí standardního kódu Java nezávislého na databázi. Je open source ovladač JDBC napsaný v Pure Java (typ 4) a komunikuje v nativním síťovém protokolu PostgreSQL. Z tohoto důvodu je ovladač nezávislý na platformě; jakmile je zkompilován, lze ovladač použít na jakémkoli systému.
Není srovnatelné s řešeními pro vyrovnávání zátěže, na které jsme poukázali dříve. Tento nástroj je tedy vaším aplikačním programovacím rozhraním API, které vám umožňuje připojit se z vaší aplikace pro jakýkoli typ programovacího jazyka, který je napsán, který podporuje JDBC nebo má alespoň adaptér pro připojení k JDBC. Na druhou stranu u Java aplikací je to příznivější.
Vyrovnávání zátěže pomocí JDBC je docela naivní, ale může to udělat. Tento nástroj je vybaven parametry připojení, které mohou spustit mechanismus vyvažování zátěže,
- targetServerType - umožňuje otevírání připojení pouze k serverům s požadovaným stavem/rolí v souladu s definujícím faktorem pro servery PostgreSQL. Povolené hodnoty jsou any, primary, master (zastaralé), slave (zastaralé), sekundární, preferSlave a preferSecondary. Stav nebo role se určuje sledováním, zda server umožňuje zápisy nebo ne.
- hostRecheckSeconds – řídí, jak dlouho v sekundách jsou informace o stavu hostitele ukládány do globální mezipaměti JVM. Výchozí hodnota je 10 sekund.
- loadBalanceHosts – umožňuje konfigurovat, zda je vždy zkoušen první hostitel (při nastavení na hodnotu false) nebo zda jsou připojení vybrána náhodně (při nastavení na hodnotu true)
Takže pomocí loadBalanceHosts, který přijímá booleovskou hodnotu. loadBalanceHosts je ve výchozím režimu zakázán a hostitelé jsou připojeni v daném pořadí. Pokud je povoleno, hostitelé jsou vybíráni náhodně ze sady vhodných kandidátů. Základní syntaxe při připojování k databázi pomocí jdbc je následující,
- jdbc:postgresql:database
- jdbc:postgresql:/
- jdbc:postgresql://host/database
- jdbc:postgresql://host/
- jdbc:postgresql://host:port/database
- jdbc:postgresql://host:port/
Vzhledem k tomu, že loadBalanceHosts a připojení přijímá více hostitelů nakonfigurovaných stejně jako níže,
jdbc:postgresql://host1:port1,host2:port2,host3:port3/databaseTo umožňuje JDBC náhodně vybírat ze sady vhodných kandidátů.
Výhody použití PgJDBC pro PostgreSQL
Není třeba vyžadovat middleware nebo proxy jako nástroje pro vyrovnávání zatížení. Tento proces přidává další zvýšení výkonu z aplikačního frontendu, protože neexistuje žádná další vrstva pro každý požadavek, který by mohl projít. Pokud máte připravené aplikace a jsou napsány tak, aby podporovaly propojení s JDBC, může to být výhodné a pokud nepotřebujete další middleware, zejména pokud je váš rozpočet omezený a chcete omezit pouze procesy věnované jeho jedinému účelu a funkci. Na rozdíl od aplikací s vysokým provozem a velkou poptávkou může vyžadovat proxy servery fungující jako vaše vyrovnávače zátěže a může vyžadovat další zdroje pro správné zpracování vysokých požadavků na připojení, což také vyžaduje nároky na procesor a paměť.
Nevýhody použití PgJDBC pro PostgreSQL
Musíte nastavit kód pro každé připojení, které má být požadováno. Jedná se o aplikační programovací rozhraní, což znamená, že je potřeba se s tím vypořádat, zvláště pokud je vaše aplikace velmi náročná na odeslání každého požadavku na správné servery. Neexistuje žádná vysoká dostupnost, automatická škálovatelnost a má jediný bod selhání.
Co takhle Wrappers nebo nástroje implementované pomocí libpq pro vyrovnávání zátěže vašeho PostgreSQL?
libpq je rozhraní aplikačního programátora jazyka C k PostgreSQL. libpq je sada funkcí knihovny, která umožňuje klientským programům předávat dotazy na backend server PostgreSQL a přijímat výsledky těchto dotazů.
libpq je také základním motorem pro několik dalších aplikačních rozhraní PostgreSQL, včetně těch napsaných pro C++, PHP, Perl, Python, Tcl, Swift a ECPG. Takže některé aspekty chování libpq pro vás budou důležité, pokud použijete jeden z těchto balíčků.
libpq neautomatizuje vyvažování zátěže a nelze ji považovat za nástroj pro řešení vyvažování zátěže. Přesto se dokáže připojit k dalším dostupným serverům, pokud předchozí servery uvedené pro připojení selžou. Máte-li například k dispozici dva aktivní pohotovostní uzly, pokud je první uzel příliš zaneprázdněn a nereaguje na odpovídající hodnotu časového limitu, připojí se k dalšímu dostupnému uzlu v daném připojení. Závisí na tom, jaký typ atributů relace jste zadali. To závisí na parametru target_session_attrs.
Parametr target_session_attrs přijímá hodnoty pro čtení i zápis a jakékoli, které jsou výchozí hodnotou, pokud nejsou zadány. Parametr target_session_attrs spočívá v tom, že pokud je nastaven na čtení-zápis, pouze připojení, ve kterém jsou během připojení přijímány transakce čtení-zápis. Dotaz SHOW Transaction_read_only bude odeslán při každém úspěšném připojení. Pokud je výsledek zapnutý, připojení bude uzavřeno, což znamená, že uzel je identifikován jako replika nebo nezpracovává zápisy. Pokud bylo v připojovacím řetězci zadáno více hostitelů, budou všechny zbývající servery vyzkoušeny, jako kdyby se pokus o připojení nezdařil. Výchozí hodnota tohoto parametru je any, což znamená, že všechna připojení jsou přijatelná. Ačkoli spoléhání se na target_session_attrs nestačí pro vyrovnávání zátěže, možná budete schopni simulovat kruhovou obměnu. Viz můj příklad kódu C níže pomocí libpq,
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>
#include <libpq-fe.h>
const char* _getRoundRobinConn() {
char* h[2];
h[0] = "dbname=node40 host=192.168.30.40,192.168.30.50";
h[1] = "dbname=node50 host=192.168.30.50,192.168.30.40";
time_t t;
//srand((unsigned)time(&t));
sleep(1.85);
srand((unsigned)time(NULL));
return h[rand() % 2];
}
void
_connect()
{
PGconn *conn;
PGresult *res;
char strConn[120];
snprintf(strConn, 1000, "user=dbapgadmin password=dbapgadmin %s target_session_attrs=any", _getRoundRobinConn());
//printf("\nstrConn value is: %s\n", strConn);
conn = PQconnectdb(strConn);
res = PQexec(conn, "SELECT current_database(), inet_client_addr();");
if ( PQresultStatus(res)==PGRES_TUPLES_OK )
{
printf("current_database = %s on %s\n", PQgetvalue(res, 0, 0),
PQhost(conn));
} else {
printf("\nFailed... Message Code is: %d\n", PQresultStatus(res));
}
PQclear(res);
PQfinish(conn);
}
int main(void)
{
int i;
for (i=0 ; i<5 ; i++)
_connect();
return 0;
}Výsledek odhaluje,
[email protected]:/home/vagrant# gcc -I/usr/include/postgresql -L/usr/lib/postgresql/12/lib libpq_conn.c -lpq -o libpq_conn; ./libpq_conn
current_database = node40 on 192.168.30.40
current_database = node40 on 192.168.30.40
current_database = node50 on 192.168.30.50
current_database = node40 on 192.168.30.40
current_database = node50 on 192.168.30.50Uvědomte si, že pokud dojde k výpadku uzlu .40 (primární uzel), vždy nasměruje připojení k .50, pokud je vaše hodnota target_session_attrs jakákoliv.
V tom případě si můžete jednoduše vytvořit svůj vlastní volně pomocí libpq. Přestože proces spoléhání se na libpq a/nebo jeho obaly je příliš hrubý na to, abychom řekli, že to může poskytnout požadovaný mechanismus vyvažování zátěže s rovnoměrnou distribucí do uzlů, které máte. Tento přístup a kódování lze rozhodně vylepšit, ale myšlenka je taková, že se jedná o bezplatný a otevřený zdroj a můžete kódovat, aniž byste se spoléhali na middleware a volně navrhovali způsob, jakým bude vaše vyrovnávání zátěže fungovat.
Výhody používání libpq pro PostgresQL
Knihovna libpq je aplikační rozhraní programátora postavené v programovacím jazyce C. Přesto byla knihovna implementována v různých jazycích jako obaly, takže programátoři mohou komunikovat s databází PostgreSQL pomocí svých oblíbených jazyků. Můžete si přímo vytvořit vlastní aplikaci pomocí svých oblíbených jazyků a poté vypsat seznam serverů, na které chcete zasílat dotazy, ale pouze po druhém, pokud dojde k selhání nebo vypršení časového limitu, odešlete svou zátěž na dostupné uzly, kterým chcete zátěž distribuovat. Je k dispozici v jazycích jako Python, Perl, PHP, Ruby, Tcl nebo Rust.
Nevýhody použití libpq pro PostgresQL
Implementace paralelního zatížení není dokonalá a musíte si napsat svůj vlastní mechanismus vyrovnávání zatížení pomocí kódu. Neexistuje žádná konfigurace, kterou byste mohli použít nebo upravit, protože je to celé pouze programovací rozhraní k databázi PostgreSQL pomocí parametru target_session_attrs. To znamená, že při sestavování databázového připojení musíte mít sérii čtených připojení směřujících do vašich replikových/pohotovostních uzlů, pak psát dotazy, které jdou do zapisovacího nebo primárního uzlu ve vašem kódu, ať už je to ve vaší aplikaci, nebo musíte vytvořit vaše vlastní API pro správu řešení vyrovnávání zátěže.
Použití tohoto přístupu rozhodně nepotřebuje ani se nespoléhá na middleware z pohledu front-endové aplikace k databázi jako backendu. To je samozřejmě nenáročné, ale při odesílání seznamu serverů po připojení to neznamená, že zatížení je pochopeno a odesláno rovnoměrně, pokud pro tento přístup nemusíte přidat svůj kód. To jen přidává potíže, přesto již existují řešení, tak proč je potřeba znovu vynalézat kolo?
Závěr
Implementace vašich load balancerů pomocí PostgreSQL může být náročná, ale závisí na typu aplikace a nákladech, se kterými máte co do činění. Někdy kvůli požadavku na vysokou zátěž vyžaduje middleware fungující jako proxy, aby bylo možné správně distribuovat zátěž a také dohlížet na stav nebo stav jeho uzlu. Na druhou stranu může vyžadovat serverové zdroje, buď musí být spuštěn na dedikovaném serveru, nebo vyžaduje extra CPU a paměť, aby uspokojil potřeby, což zvyšuje náklady. Existuje tedy také jednoduchý způsob, který je časově náročný, ale nabízí rozložení zátěže na dostupné servery, které již máte. Vyžaduje to však programátorské dovednosti a porozumění funkcím API.