2 aktív apache load balancer

Fórumok

Egy load balancing bevezetése előtt állok. Elkezdtem ezután kutakodni, olvasgatni.
Azt találtam, hogy kell (a példa szerint) 2 load balancer, 2 webszerver és 5 IP.
Innentől nem teljesen értem a dolgot. A 2 load balancer figyeli egymást kiesés esetére. Emiatt kell a +1 (virtual) IP. Így csak az egyik load balancer lesz aktív, a másik tartalék.
Miért nem jó megoldás, ha mindkét load balancer aktív? A 2 load balancer között round robin dns osztaná meg a terhelést, és tudomásom szerint megoldható az is, hogy az egyik gép átvegye a másik gép IPjét kiesés esetén.
Mi a baj ezzel az elképzeléssel?

Hozzászólások

Semmi baj nincs vele. Rakd össze, próbáld ki.

Nade a webszervereknek siman tudsz privat IP-t adni. Vagy ezt igy szamoltad?
Mar amennyiben az LB egy vmilyen proxy jellegu cucc, vagy LVS vagy hasonlo. Ha nem, az akkor meg legyen olyan.

Javaslom, h eloszor talald ki, h mi a celod (pl. akarsz egyaltalan az LB-k kozott failovert, vagy eleg beloluk 1 igy akar? akarsz egyaltalan HA-t?), utana azt, h mivel csinalod meg es ahhoz keress howto-t.

Bocs, ha tevedek, de nekem ugy tunik, h ezek nincsenek meg nalad.

t

Az első ilyen projektem lesz. Valahol el kell kezdeni.
Az IPket a howto-k szerint írtam. Azért is nem értettem teljesen.
LB mindenképpen kelleni fog, és azt sem szeretném, hogy annak kiesése esetén lehaljon az egész, tehát kelleni fog failover is.
LB-t mi alapján szoktak méretezni? Miből lehet megbecsülni, hogy 1 LB hány klienset fog tudni kiszolgálni?

Valahol el kell kezdeni.

Hát, akkor ha rám hallgatsz, akkor nézelődsz, letöltesz, összeraksz, próbálkozol.
Több különféle felállásban és konfigurációban. Ez kb. egy ezerváltozós egyenlet, senkinek nincs hozzá megoldókulcsa.

LB-t mi alapján szoktak méretezni? Miből lehet megbecsülni, hogy 1 LB hány klienset fog tudni kiszolgálni?

Kipróbálják, megnézik, hogy mit tud. Aztán ha kevés, megnézik, hogy hol lehet még csavarni rajta. Vagy néznek egy másikat.

Jo esellyel barmit csinalsz, nalad nem az lesz a szuk keresztmetszet. A loadbalancer-nek jellemzo modon nagyon minimalis terhelese szokott lenni. Igy en azt mondom, h annak a meretezese lesz neked a legkisebb gondod. Sot, mivel 2 geped van, amiket feltehetosen egyenlo modon akarod terhelni, LB-re sincs feltetlenul szukseged.

Tovabbra is attol fugg minden, hogyan akarod megoldani, az pedig attol, hogy konkretan mit, az alkalmazas mit kivan meg.

t

Nem azert van szukseg, mert egyenloen szeretned, hanem mert a roundrobin nem mgfelelo. Amugy az elejen kettot irtal.

Akkor en azt csinalnam, h ket gepre raknek haproxy-t vagy nginx-et, vagy vmi hasonlo alternativat.
Az pedig szepen szetosztana a terhelest a backendek kozott.

Az LB-k kozott pedig vhogy megoldani a failovert.

t

Ha nem sufni hostingba van a szervered akkor hanem pl. Dataplex akkor berjl a T-Com-tol loadbalancert sokkal jobban jarsz megbizhatosag szempontjabol mint ha itt Te elkezdesz faragni es latszolag fingod sincs a dolgokrol.
--
1 leszel vagy 0 élő vagy hulla!

Alapvetően semmi, addig, amíg statikus fájlokat szolgálsz ki. A gond akkor szokott lenni, amikor egy alkalmazáscluster előtt van a LB és feltétel (vagy ajánlott), hogy az adott kliens egy sessionon belül mindig ugyanahhoz a appserverhez csatlakozzon. Ekkor az LB fejben tartja, hogy ki kivel van párban. Több LB esetén ezt az információt meg kell osztani és közösen kell karbantartani.

DNS round robin nem a legprofibb megoldás ebben az esetben, mert akkor is vissza adja a hosztnévhez tartozó IP-t, ha az adott IP-n éppen nem elérhető a szolgáltatás.
DNS round robin akkor lenne jó, ha lenne párban 2-2 LB, és a DNS a 2 közös IP-t adná vissza. Így bármlyik párból lenn van egy LB, nincs szolgáltatáskiesés.

2 (egy subnetben lévő) gép esetén 1-1 LB-t és 1-1 HTTP szervert érdemes telepíteni.
Valamint az általad leírtak szerint 5 IP kell:
- 1 db amihez a szolgáltatás hosztneve fog tartozni, ez lesz bejegyezve a DNS-be, illetve ezt fogja felvenni az a gép, amin aktív a LB
- 1-1 db a webszerverhez
- 1-1 db (akár belsőhálózatos, amiken a gépek elérik egymást) a heartbeat-hez