Nástroj pro vyrovnávání zatížení databáze nebo reverzní proxy databáze rozděluje zátěž příchozí databáze mezi více databázových serverů běžících za ním. Cílem vyvažování zátěže databáze je poskytnout aplikacím jediný koncový bod databáze, ke kterému se lze připojit, zvýšit propustnost dotazů, minimalizovat latenci a maximalizovat využití zdrojů databázových serverů.
Topologie nástroje pro vyrovnávání zatížení databáze může být dvěma způsoby:
- Centralizovaná topologie
- Distribuovaná topologie
V tomto blogovém příspěvku se budeme zabývat oběma topologiemi a pochopíme některé výhody a nevýhody každého nastavení. Bylo by také možné smíchat obě topologie dohromady?
Centralizovaná topologie
V centralizovaném nastavení je reverzní proxy umístěn mezi datovou a prezentační vrstvou, jak je znázorněno na následujícím diagramu:
Chcete-li odstranit jediný bod selhání, musíte nastavit nahoru dva nebo více uzlů load balanceru pro účely redundance. Pokud vaše aplikace dokáže zpracovat více koncových bodů databáze, například aplikace nebo ovladač databáze je schopen provádět kontroly stavu, pokud je nástroj pro vyrovnávání zatížení v pořádku pro zpracování dotazů, pravděpodobně můžete část virtuální adresy IP přeskočit. V opačném případě by oba uzly nástroje pro vyrovnávání zátěže měly být propojeny se společným názvem hostitele nebo virtuální IP adresou, aby byla zajištěna transparentnost pro databázové klienty, kde pro přístup k datové vrstvě stačí použít jeden koncový bod databáze. Použití DNS nebo mapování hostitele je také možné, pokud chcete přeskočit použití virtuálních IP adres.
Tento přístup založený na vrstvách je mnohem jednodušší na správu, protože má nezávislé statické umístění hostitele. Je velmi nepravděpodobné, že by se vrstva nástroje pro vyrovnávání zátěže škálovala (přidávání dalších uzlů), protože má solidní základ v odolnosti, redundanci a transparentnosti pro vrstvu aplikací. Pravděpodobně budete muset škálovat hostitele (přidat k hostiteli více zdrojů), k čemuž obvykle dojde dlouho v budoucnu, poté, co bude zátěž vyrovnávacího zátěže náročnější, jak vaše firma roste.
Tato topologie vyžaduje další vrstvu a hostitele, což může být v holé infrastruktuře s fyzickými servery nákladné. Toto nastavení se snáze spravuje v cloudovém nebo virtuálním prostředí, kde máte možnost přidat další vrstvu mezi aplikační a databázovou vrstvu, aniž by vás to stálo příliš mnoho nákladů na fyzickou infrastrukturu, jako jsou náklady na elektřinu, prostor v racku a síťové náklady.
Distribuovaná topologie
V nastavení distribuované topologie jsou nástroje pro vyrovnávání zátěže umístěny společně v rámci prezentační vrstvy (aplikační nebo webové servery), jak zjednodušuje následující diagram:
Aplikace zacházejí s nástrojem pro vyrovnávání zatížení databáze podobně jako s lokálním databázovým serverem, kde load balancer se stává reprezentací vzdálených databází z pohledu aplikace. Obvykle bude nástroj pro vyrovnávání zatížení naslouchat místnímu síťovému rozhraní, jako je 127.0.0.1 nebo "localhost", což zefektivní hostitele databáze koncového bodu databáze pro aplikace.
Jednou z výhod běhu v této topologii je, že nepotřebujete další hostitele pro účely vyrovnávání zátěže. Kombinací úrovně vyrovnávání zátěže v rámci prezentační vrstvy bychom mohli ušetřit alespoň dva hostitele. V prostředí prostého kovu by vám tato topologie mohla v průběhu let potenciálně ušetřit spoustu peněz. Obecně platí, že zátěž vyrovnávače zátěže je mnohem méně náročná ve srovnání s databází nebo zátěží aplikací, takže sdílení stejných hardwarových prostředků s aplikacemi je oprávněné.
Při společném umístění s aplikačním serverem přiblížíte reverzní proxy k aplikaci a eliminujete jediný bod selhání. To může výrazně zlepšit výkon aplikace, když máte geografické oddělení mezi aplikací a datovou vrstvou, zejména pro nástroje pro vyrovnávání zatížení databáze, které podporují ukládání do mezipaměti sady výsledků, jako je ProxySQL a MaxScale. Na druhou stranu se počet vyvažovačů zatížení databáze běžně rovná počtu uzlů aplikace, což znamená, že pokud se vrstva aplikace zvětší, počet vyvažovačů zatížení databáze se bude zvyšovat, což může potenciálně snížit výkon pro zdraví databáze. zkontrolovat službu. Všimněte si, že kontroly stavu nástroje pro vyrovnávání zátěže jsou o něco komplikovanější, protože je zodpovědný za udržování správného stavu uzlů databáze.
S pomocí nástrojů pro automatizaci IT infrastruktury jako Chef, Puppet a Ansible spolu s nástroji pro orchestraci kontejnerů již není nemožným úkolem automatizovat nasazení a správu více instancí nástroje pro vyrovnávání zatížení pro tuto topologii. Operační tým však čeká další křivku učení, aby mohl přijít s bitvě otestovanou politikou nasazení a správy na produkční úrovni, aby se snížila nadměrná práce při manipulaci s mnoha uzly pro vyrovnávání zatížení. Nenechte si ujít všechny důležité aspekty správy nástroje pro vyrovnávání zatížení databáze, jako je zálohování/obnova, upgrade/downgrade, správa konfigurace, řízení služeb, správa chyb a tak dále.
Distribuovanou topologii lze kombinovat s centralizovanou topologií pro některé podporované nástroje pro vyrovnávání zatížení databáze, jako je ProxySQL, jak je znázorněno na následujícím diagramu:
Backendové "servery" instance ProxySQL mohou být další sadou ProxySQL místo toho uzly. S touto konfigurací není pro přístup z jednoho koncového bodu k databázovým uzlům nutná virtuální IP adresa, protože lokální instance ProxySQL hostovaná lokálně na aplikačním serveru bude z hlediska aplikace jediným koncovým bodem.
To však vyžaduje dvě verze konfigurací nástroje pro vyrovnávání zatížení – jednu, která se nachází na aplikační vrstvě, a druhou na úrovních vyrovnávání zatížení. Vyžaduje také více hostitelů, s výjimkou nutnosti učit se o technologii virtuálních IP adres, IP failover a tak dále. Výhody a nevýhody distribuovaných i centralizovaných nastavení jsou v této topologii sloučeny.
Závěr
Každá topologie má své výhody a nevýhody a musí být od začátku dobře naplánována. Toto včasné rozhodnutí je zásadní a může z dlouhodobého hlediska výrazně ovlivnit výkon vaší aplikace, škálovatelnost, spolehlivost a dostupnost.