Vlákno názorů k článku Velká řešení otevřeně: spolehlivá a škálovatelná síť od rpajik - Ale rozbalancovat provoz na oba lodbalancery přes DNS...
-
A mohl byste navrhnout vhodnejsi reseni? Prijde mi, ze delat pomoci DNS load-balancing jen a pouze samotnych load-balanceru (ktere pak jiz podle aktualni zateze smeruji traffic na samostatne aplikacni servery) je koser reseni, i kdyz ano, je potreba nejak ohlidat, ze soucet provozu na obou uzlech neni vetsi nez je kapacita libovolneho z nich.
-
lojzak (neregistrovaný)
@bez přezdívky
Load balancing má dělat (ne zcela překvapivě) load balancer, nikoli DNS server.
DNS server nemá žádné informace o vytížení serverů, na které by se měla zátěž rozkládat, nesleduje zda fungují či ne a nerespektuje to, že jednoho klienta by měl obsluhovat po dobu trvání session stále jedn server.
DNS load balancing se nehodí ani na rozdělování provozu podle lokalit, to jde dělat mnohem lépe pomocí BGP.
-
lojzak (neregistrovaný)
Failover se dělá pomocí floating IP (jak bylo popsáno v článku). Pro více load balancerů nevidím význam. Pokud nejsou nastavena extrémně složitá pravidla, tak samotný loadbalancing nepředstavuje velkou zátěž. Ostatně stackoverflow funguje pouze na 2 loadbalancerec, které jsou v režimu failover.
Jestli výkon loadbalancerů nestačí, tak se bude pravděpodobně jednat o službu s velkým traffickem, kde nebude problém si zařídit load balancing pomocí BGP.
Pokud by výkon loadbalancerů nestačil z důvodu složitých pravidel, tak je možné využívat dvě úrovně. jeden (nebo 2 v režimu failover) loadbalancer na základní rozdělení mezi třeba 10 dalších, co budou zpracovávat složitá pravidla.
-
Při dvou loadbalancerech nerozdělovat požadavky na oba dva. Kapacita toho balanceru je totiž neznámá, se kterou nemůžete efektivně pracovat. Loadbalancer nebude škálovat lineárně, takže 20% zátěž na procesoru a síťových kartách rozhodně neznamená, že máte ještě 80% rezervu. Na to abyste znal přesné limity loadbalanceru, musel byste mít naprosto totožný kus HW v labu a při každém upgradu jádra, balancovacího SW, rekonfiguraci nějaké hodnoty,... provést nové měření abyste znal přesný limit. A i když přesnou hranici znáte ( resp. myslíte si, že jí znáte ), tak je to nebezpečné, protože v praxi se budete řidit především grafy, kde při sebelepší použité technologii nemáte všechny peaky - a je jedno jakou máte frekvenci sběru dat.
Proto je praktičtější mít aktivní pouze jeden node, když na něm bude výkonostní problém, tak je to hned vidět a switchnutí na popsaný active-active může být rychlý a funkční workaround, nicméně s vědomím, že komponenta je v tu chvíli bez redundance a je třeba situaci začít ihned řešit. Když se dostanete do stejného stavu se 2 aktivními nody, tak jste bez redundance a nevíte o tom ... Neřeší to ani pravidelné testy redundance - na těch se typicky ověřují funkčnosti failover mechanizmů, ale v praxi se to nikdy neděla v době nejvetší špičky - zákazník to prostě nedovolí.
Pokud je třeba mít z výkonostních důvodů víc jak jeden balancer, je třeba to provozovat v režimu alespoň N+1, aby to mělo smysl.
