2 Node Multi-Site HA VPS Cluster Tippek és Trükkök

 ( unstar | 2012. július 13., péntek - 19:06 )

Sziasztok!

Szeretném kikérni a tapasztalataitokat, véleményeteket egy leendő 2 node-os HA és/vagy LB környezettel kapcsolatban. Egyelőre a koncepciót szeretném összerakni, hogy hogyan érdemes 2 node-ot felhasználni ilyen célokra, mit lehet kihozni belőlük.

A leendő környezetről:
1-1 Debian/Ubuntu alapú, közel vagy teljesen azonos konfigurációjú VPS-t bérelnénk, amely különböző szervertermekben lenne elhelyezve.

Kialakítandó, migrálandó szolgáltatások:
Apache 2 + PHP
Pure-FTPd (MySQL backend)
Dovecot (MySQL backend, maildir)
Postfix (MySQL backend)
MySQL
PostgreSQL

Cél:
A cél elsősorban a magas rendelkezésre állás (failover) elérése lenne és másodsorban a terheléselosztás. Ha a kettő találkozna az még jobb lenne.

A kérdésem, hogy milyen szoftverekkel, fájlrendszerrel, replikációs megoldássokal érnétek el a fenti célt.

Válaszaitokat előre is köszönöm!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

rsync vagy valamilyen cluster FS használata a jobb? Dovecot dsync replikációval van-e valakinek tapasztalata? Érdemes-e itt is a Heartbeat + DRBD kombót bevetni? Ha az IP cím átadása/átvétele nem megoldható, van-e valamilyen alternatív út a DNS TTL megoldáson túl?

Csak ötletelgetés szinten:
Szerintem szükség van egy "proxy" rendszerre is, ami a bejövő igényeket továbbküldi a master felé (HA) vagy szétdobálja a két szerver között (LB). Node, hol legyen a proxy? Ha vmelyik VPS mellett egy újabb VPS-ben van, akkor ha megborul a VPS szolgáltató, akkor a proxy is borul vele, tehát HA szempontból nem igazán vagy előrébb. Lehetne 3. site-on is a proxy, de akkor mar 3 szolgáltató nyűgjeivel kell foglalkoznod.

Biztos, hogy minden szolgáltatás esetében szükség van nagy rendelkezésre állásra? Nem elég csak a MySQL-nél biztosítani?
Szerintem linux alapokon aligha lehet ilyen fullos HA megoldást kivitelezni, ezekhez már hoszt oldali replikáció + közös storage szükséges. VPS bérlésnél nyilván nincsennek ilyen lehetőségeid.

Ha egyszerű megoldásra vágysz, akkor szerintem futtass óránként (vagy akár gyakrabban) egy rsyncet pri->sec irányba, az adatbázis tartalmát pedig kidumpolva másold át (konzisztencia miatt). Ha lehal a primary VPS, akkor a secondary gépen restore-olod az adatbázist és elindítod a szolgáltatásokat. Persze ez nem valós HA, de a domain IP cím módosítás is eltart egy ideig...

"Csak ötletelgetés szinten:
Szerintem szükség van egy "proxy" rendszerre is, ami a bejövő igényeket továbbküldi a master felé (HA) vagy szétdobálja a két szerver között (LB). Node, hol legyen a proxy? Ha vmelyik VPS mellett egy újabb VPS-ben van, akkor ha megborul a VPS szolgáltató, akkor a proxy is borul vele, tehát HA szempontból nem igazán vagy előrébb. Lehetne 3. site-on is a proxy, de akkor mar 3 szolgáltató nyűgjeivel kell foglalkoznod."

Ez a proxy jó elgondolás. Ki is felejtettem az alap koncepcióból. Egy ilyen forgalomirányító/monitor szerver esetén, milyen erőforrásigénnyel kell számolni? Milyen szoftvermegoldás javasolt 2+1 node esetén?

"Biztos, hogy minden szolgáltatás esetében szükség van nagy rendelkezésre állásra? Nem elég csak a MySQL-nél biztosítani?
Szerintem linux alapokon aligha lehet ilyen fullos HA megoldást kivitelezni, ezekhez már hoszt oldali replikáció + közös storage szükséges. VPS bérlésnél nyilván nincsennek ilyen lehetőségeid."

A levelezés és az adatbázisok elérése a legfontosabb.

"Ha egyszerű megoldásra vágysz, akkor szerintem futtass óránként (vagy akár gyakrabban) egy rsyncet pri->sec irányba, az adatbázis tartalmát pedig kidumpolva másold át (konzisztencia miatt). Ha lehal a primary VPS, akkor a secondary gépen restore-olod az adatbázist és elindítod a szolgáltatásokat. Persze ez nem valós HA, de a domain IP cím módosítás is eltart egy ideig..."

Két VPS-ből többet szeretnénk kihozni egy erős backup stratégiánál.

Ha abból indulunk ki, hogy nem lehet pillanatok alatt megváltoztatni a domainhez tartozó IP-t, akkor mindenképp kell egy proxy szerver, ami fogadja a kívülről érkező forgalmat. Már itt sérül a HA koncepció, hiszen ha a proxy borul, akkor semmi sem fog menni. Tehát a proxynak mindenképp vmi megbízható stabil VPS kell.

Foglalkozzunk a node-okkal:
- HA esetben mindenképp szinkronban kell tartanunk a storage-ot. Block device szinten megoldva (pl. drbd) a szinkron lassú lehet, belassíthatja az egész rendszert. Ráadásul speciális eseteket is le kell kezelni vhogy (split brain problémakör). Viszont nem lesz adatvesztés node leálláskor (RPO=0).
- Amennyiben nem ennyire szigorúak az elvárások, akkor megoldhatjuk a szinkront filerendszer szinten (pl. rsync). Így nem lassul le a primary node, viszont azon friss módosítások, amik még nem másolódtak át, azok bizony elvesznek (RPO>0). Ez egyúttal akár egyfajta backup rendszerként is szolgálhat.
- Viszont vannak applikációk, amiknél nem alkalmazható a file szinkron (pl. adatbázisok). Ekkor az adott szoftverrel kell megoldani a replikációt.

Tehát minden egyes szolgáltatásnál el kell dönteni, hogy melyik megoldás a célravezető. Ha egy applikáció nem replikálható hatékonyan, akkor azt a proxyn kell futtatni, és egy lentebbi rétegben megoldani a HA/LB dolgot.

Nem vagyok egy DNS guru, de annyit biztosan tudok hogy egy domain névhez lehet párosítani több IP címet.
Tehát a proxy rendszeredből létrehozhatsz többet is. Azt viszont nem tudom, és engem is érdekelne, hogy több IP esetéb a DNS és/vagy a kliens milyen módszerek alapján tud választan a több IP közül.

Ezzel megoldható a Proxy HA is, ha gyorsan el lehet érni, hogy a kiesett proxy címére már ne legyen névfeloldás.

Hát nem ez kell neked.
Pl: round robin. Bind esetén felveszed az összes ip-t egyenként. Ő pedig minden válaszra másikat fog visszaadni.
Ez azért nem jó, mert így két ip esetén a ~50% hálózati forgalom a passzív nodra esik, ami esetleg épp ki van kapcsolva, megdöglött, stb.

Linuxscripting

Én még csak olyat láttam, ahol a DNS szerver az összes címet visszaadja, csak a visszaadott címek sorrendje változik egy adott algoritmus szerint.
Most, hogy olyat egyáltalán szabad-e az RFC szerint, hogy csak egy címet ad vissza és az mindig másik azt nem tudom.
Ha ilyen lenne akkor a forwarder DNS szerverek már nem tudnák alkalmazni ugyanezt az algoritmust és az egész load-balance -olás lényege veszne el.
Pl. a UPC becachelne egy adott címet és az összes UPC-s ugyanazt a címet használná, kivéve persze, ha a TTL nulla.
Talán más célból, mondjuk helyi hálón használnak ilyet, de nem tudom, hogy ez mennyire szabványos.
Kérlek javítsatok ki, érdekelne a dolog.

Szerk.

♲♻♲

Köszi! Ez egy jól összerakott vélemény. Úgy gondolom, hogy egy rsync & dsync páros egy vállalható alternatíva lehet a mi esetünkben. Az adatbázis replikációs anyagokat még lapozgatom. Ha van tapasztalatod MySQL és PgSQL esetén, az is jöhet.

Ez kemény lesz, vps meg HA, ez a muhaha. Komolyan. Inkább minőségi vasat javasolnék, könnyen lesz magasabb rendelkezésre allasod egy saját vason saját virtualizalt környezettel.

A maildir és az fs jól elvan egy drdb eszkozon. A folyamatos tre a mysql és a postgres master slave cluster lesz, de arra nincs más megoldás ami jó is lenne.
A kérdés, hogy mekkora idő eshet ki, vagyis óránkénti szinkron elég lehet e. És hogy a dns szolgaltatasod szeretnéd e magadnak végezni, mert akkor a ttl és ip problémákat is megoldhatod.

Nem akarunk már saját vasat, hosztingot és saját virtualizált környezetet sem. Szeretnénk egy relatíve skálázható és a lehető legredundásabb környezetet kihozni a lehetőségekhez képest.

A DB replikációba még nem merültem bele, de MySQL felől még pár éve csak rosszat hallottam.
A DNS-t nem mi adnánk, szóval a TTL minimálisra állításával (5 perc) és figyelembe véve pl. a browser DNS cache-eket, akkor kb. fél óra kiesést jelentene a 2 node-os megoldás. Ennyi kompromisszum azt gondolom, hogy belefér, de erről még nem született döntés.

És az nem fordulhat elő, hogy túl olcsón akarsz elég nagy rendelkezésre állású rendszert építeni,
és a végén úgy jársz, hogy kisebb lesz a rendelkezésre állás, mintha egy sima egygépes rendszered lenne (akár egy hot backuppal, manuális átállással)?

♲♻♲

Ezt azért vedd komolyan, könnyen így járhatsz. Minden hekkezésnek csak több hekkezés lesz a vége.

Esetleg keress olyan OS-t ami már erre fel van készítve, ha van.

Egyébként egy vpsnél a HA már igen jól megvan oldva, ha cloud jellegűen kezelik a gépeket. Ha meg akkora a biznisz, hogy egy restartot sem bír ki akkor kibír pár frankó vasat.

Nezzuk hatulrol:
Nem rendszergazdi, inkabb fejleszto vagyok, szoval kicsit mas oldalrol latom a dolgokat.. meg a 8.3-as Postgres-el (aztan 8.4-el) csinaltunk par eve olyan rendszert, ahol a server egy helyi DB-ben tarolt mindent. A server mashol nem tarolt adatokat, igy el tudtuk erni, hogy 2 gepen egy master-slave modban futo PostgreSQL paros es mindket gepre feltett sajat progi el tudja latni a klienseket. Master-slave modban a masterhez csatlakozik a programod, az iras mindket gepen megtortenik, a nehany lekerdezesre a master valaszol, nehanyat meg tovabbit a slave-nek (szoval a DB kliens programodat nem kell felkesziteni kulon erre a modra). A konzisztenciat a DB lekezeli (lenyegeben a tranzakcios logokat viszi at).
Ha a master kiesik, a slave-et at kell billenteni master modba (lehet, hogy mar automatikusan tudja a DB, akkor meg nem volt olyan kenyelmes), es ettol kezdve a DB kliensed ehhez csatlakozik. (a javitas utani master-slave visszaallitas mar kicsit macerasabb) Ha a slave esik ki, amint magahoz ter, atkerulnek ra a tranzakcios logok, es magatol megjavul.
Szoval a DB szint mar magatol tud egy eleg jo elosztott mukodest.
Ha a PHP file-jaid nem modosulnak gyakran (gyakrabban, mint ahogy rsynceled), akkor az Apache2+PHP (ha nem irogat maganak kulon file-okba, es megoldhato a Postgres backend) lenyegi allitgatas nelkul menni fog a DB-ddel.

A tobbi szolgaltatasod ha megy PG-vel, akkor ott sincs kulon problema (bar az FTP-t valamilyen modon at kell vinni, DB-be gondolom csak metaadatokat tennel), egyebkent meg utana kell jarnod, hogy a MySQL lefaragott-e mar a lemaradasabol ezen a teren. (ha tudja, azt is beallitani, tesztelni, stb..)

Az FTP adat reszere es a maildirre meg jo az rsync (vagy valami elosztott filerendszer).

szerk: Az IP cim problemajat ugy oldottuk meg, hogy helyi halon egyszeruen ifconfiggal atvette a slave a master gep cimet, innentol a klienseink nem vettek eszre semmit az egeszbol. Halozat kiesesevel meg a feladat jellege miatt nem foglalkoztunk (telco cegek szamara volt egy speci halozati eszkoz monitorozo.. ha a servernel nincs net, nincs kliens sem, nincsenek uj adatok.. de legalabb megoldhatjak hazon belul a kiesest :) )

--
ezt tényleg ennyire nem értitek? - turdus :)