Sziasztok HUPperek!
Tanulási/gyakorlási céllal elhatároztam, hogy beállítok 2 gépet és megpróbálok egy házilag is összedobható (kissé "paranoid") Magas rendelkezésre állású clustert összeállítani a műhelyemben.
OpenSuSE alatt próbálkozok, mert azt szeretem. ;-)
HDD-k már RAID-ben mennek.
A cél, hogy a gépen a DNS(djbdns), Apache szerver, MySQL SQL szerver, Postfix, qpopper szolgáltatások minnél folyamatosabban elérhetőek legyenek.
Szívesen fogadok cikkeket (linkeket), ötleteket, tapasztalatokat (buktatókról, sikerekről) a kérdéskörben. (Kérlek, ne küldj "gugli" post-ot, folyamatosan keresek, gyűjtögetek a gugliból - bár az angolom gyengus.) Most épp a www.linux-ha.org-ot boncolgatom.
Ilyeneken agyalok még a tervezési fázisban (segítsetek kérlek együtt gondolkodni):
1) az rsync-kel vajon milyen könyvtárakat is tükrözzek a két gép között?
2) vajon a MySQL adatbázis is probléma nélkül rsync-elhető?
3) dupla hálókártyát tegyek mindkettőbe, vagy kössem össze őket FireWire porton a Heartbeat és az rsync megvalósításához?
4) van egy fix ip címem és egy domain-em is ;-) Egyáltalán megoldható-e az, hogy ha kiesik az internetszolgáltatóm egy időre, átvegye a helyét egy másik (pl. beteszek tartalékba egy modemes netet), és minimális legyen a kiesés a domain elérés viszonylatában? (A domain gondozását egy harmadik cég végzi.)
Egyenlőre itt tartok. Minden jószívű HUPpernek előre is köszönöm.
- 2825 megtekintés
Hozzászólások
rsync helyet DRBD szerintem.
Core2Duo T7100, 2.5G, Ubuntu 8.04, 2.6.27.6
- A hozzászóláshoz be kell jelentkezni
Ezt több helyen is javasolják más oldalakon. Van tapasztalatod? Biztonságosabb, vagy csak egyszerűbb a konfigurálása?
- A hozzászóláshoz be kell jelentkezni
igen van, ugyanis ez amolyan hálózati raid1. röviden állandoan sync ben van a két gép, és ha az egyik lehal a heartbeat átkapcsol a másikra, aztén ott indulnak a szolgáltatások, ha a master visszajön akkor meg a drbd syncel
Core2Duo T7100, 2.5G, Ubuntu 8.04, 2.6.27.6
- A hozzászóláshoz be kell jelentkezni
Alapveto kulonbsegek vannak a ketto kozott. Az rsync kb. egy okos file-masolo cucc, a drbd pedig 2 block device halozaton keresztuli szinkronizaciojat biztositja. Ha dual-primary modban hasznalod, akkor tavolrol emlekeztet egy shared storage-re (pl. lehet tenni ra GFS-t).
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Ha jól értem a DBRD-vel értelmetlenné válik pl. a MySQL cluster/nem cluster kérdés is, hiszen mindent 1:1-ben "tükröz" a két gép között?
- A hozzászóláshoz be kell jelentkezni
A replikacio resze igen, de azert erdemes vele vigyazni, mert ha elhasal a gep, akkor eloszeretettel hagyja a filerendszert, meg a rajta levo db fileokat inkonzisztens allapotban, ami eleg kellemetlen lehet, ha csak metadata journal-od van.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Ha nem egy darab gep lesz ugyse (ilyen szinten nem erdemes egy gepre tervezni a mysql-t meg az apache-t), akkor nezd meg a MySQL beepitett cluster szolgaltatasat. En ugyan csak probalkoztam vele, de nagyon jol mukodik, es teljesen transzparens, raadasul minimalis a szopas vele, majdnem automatan all ossze.
Legalabb harom gep kell hozza, en ugy csinaltam, hogy a management szerver volt az SQL node.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Teljesen masra valo. Ha egy sql es 1 memory nodeod van, az meg nem cluster. Ahhoz, hogy egy mysql cluster redundans legyen, 4 gep kell: 2-n sql es memory node, 2n pedig management. Az is jo, amit te mondassz, lenyeg, hogy 2 gep nem eleg, mivel a management es a memory nodeot nem lehet egy gepre tenni.
- A hozzászóláshoz be kell jelentkezni
2 gép esetén tehát érdemes kihagyni a dologból a MySQL cluster megoldását? Illetve ki lehet egyáltalán hagyni???
- A hozzászóláshoz be kell jelentkezni
Persze, olvasd el a mysql cluster dokumentacionak legalabb az elso 2 oldalat, es vilagos lesz, hogy nem erre van kitalalva.
- A hozzászóláshoz be kell jelentkezni
De még mindig fenn marad a kérdés, hogy ki lehet-e hagyni _egyáltalán_?
Ahogy figyelgettem, a backup megoldások szinte kivétel nélkül egy SQL alapú, export típusú dump-olásra épülnek. Gondolom, nem véletlen, hogy nem egy "mappabecsomagolós" módszert vettek alapul.
A DBSD talán áthidalja ezt a kérdést, de egy "hirtelen halál"-nál lehet, hogy még nem történt meg a szinkronizáció. Persze tökéletes biztonságot - gondolom - csak céleszközökkel lehet elérni. (A problémát erősen befolyásolja, hány darab kilencest akar elérni az ember. :-)
- A hozzászóláshoz be kell jelentkezni
Kilehet a mysql cluster teljesen mas dolgokra valo nem a tipikus LAMP environment resze. Folleg mert egymillio mas mdoszer letezik. mysql proxy csak hogy egyet emlitsek de fentebb/lentebb irtam mar hogy MMM peldaul nagyon jol mukodik , de sajat kezeddel sem kaland lekodolni.
Ha a hirtelen halaltol rettegsz akkor innodb tablak, replikacio es esetleg google patch mysql hez aminek a nevet nemtom es amugyis csak <5.0.5x verziokhoz csinaltak meg talan pont 5.0.36hoz ami lassan kioregszik, a lenyeg hogy addig nincs commit egy tranzakciora amig le nem replikalta legalabb egy masik node.
ndb (a mysql cluster) amugy eleg lassucska es lomha sok gepbol es mint irtam, van sok jobb megoldas ha kicsit ert hozza az ember.
drk
- A hozzászóláshoz be kell jelentkezni
A lassusagaval nem ertek egyet. Azok szoktak mondani, hogy lassu, akik ugy hasznaljak, mint egy disk based adatbazist (pl. a btree indexek nyilvan nem lesznek hatekonyak egy in memory adatbazis eseten). Ha arra gondolsz, hogy az ndbd single threaded, es lehetne gyorsabb is, akkor abban igazad van, 6.4es mysql clusterben majd jon az ndbmtd.
- A hozzászóláshoz be kell jelentkezni
Lokalisan is kulon retegben valositod meg a redundanciat, aminek koszonhetoen teljesen atlatszatlan es tranzakcio biztos lesz. Ertsd: a ket lokalis diszket RAID-el es nem rsync-el tartod konzisztens allapotban. Valamint ez a reteg gyakran rogton load-balancingot is automatikusan elvegzi.
Ezt a logikat erdemes kovetni az absztaktabb szolgaltatasoknal is, azaz halozati filerendszert, ill. mysql eseten beepitett cluster funckiot ajanlott hasznalni.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
A RAID-et szoftveresen oldottam meg, a gépen belül nem is terveztem mást. A MySQL Cluster oldalakat már bogarászom az előző hozzászóló nyomán. :-)
Hálózati fájlrendszert tudnál ajánlani a tapasztalataid alapján? (pl. egy NFS+DBRD páros?)
- A hozzászóláshoz be kell jelentkezni
Az nem relevans, hogy szoftveres vagy hardveres ebbol a szempontbol. Mindket esetben nem az eredeti devicet hasznalod (hardveres esetben az nem is latszik), hanem a kozottes reteg (a raid vezerlo vagy raid modul) altal meghajtot virtualis devicet.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
A netkiesést csak úgy tudod áthidalni, ha a domained egy proxyra van irányítva és azon keresztül megy a forgalmad.
Ennek a legrandább megoldása, ha a domain egy dinamikus dns- szolgáltatónak a címére van irányítva és ez utóbbit frissíted annak függvényében, hogy melyik hálózati kapcsolatod az aktív.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "
- A hozzászóláshoz be kell jelentkezni
"A netkiesést csak úgy tudod áthidalni, ha a domained egy proxyra van irányítva és azon keresztül megy a forgalmad."
Akkor már a proxy-t is biztosítani kellene kiesés ellen, ugyebár? ;-)))
Azon gondolkodom, (persze csak elméletben), hogy a domain szolgáltatóm valyon képes lenne-e valami "dinamikus DNS"-szerűt szolgáltatni, ha akarna? - Egyébként épp a dinamikus DNS szolgáltatók szolgáltatásain elgondolkodva kezdtem el az egészen törni az agyam. :-) Tetszik a módszerük. Vajon rájuk lehet/érdemes bízni a választott domain nevemet?
- A hozzászóláshoz be kell jelentkezni
Nem.
Az dns adatbázisok általában több órás eltérésekkel frissülnek, ezért mégha azonnal is képes lennél a dns bejegyzést módosítani, az nem fog mindenhol azonnal megjelenni.
A dinamikus dns szolgáltatók, általában proxy szolgáltatók. Ez azt jelenti, hogy az ő fix-ipjű gépükre va irányítva a domained, amire befutó kéréseket aztán továbbpasszol az általad megadott dynamikus IP-re.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "
- A hozzászóláshoz be kell jelentkezni
Negativ. A dinakmikus DNS par perc alatt frissul. Az emlitett proxy teljesen ertelmetlen, mert kb. a HTTP az egyetlen protokoll, ami ugy ahogy proxyzhato. Ha csatlakoznal a lolwut.my-ip.com 4242-es portjara, es az emlitett hostnev a szolgaltato proxyjara menne, akkor honnan a halalbol tudna egy nem HTTP lekeres eseten, hogy az a lolwut.my-ip.com-hoz tartozik, es kinek az IP-je fele kell tovabbitani?? (Ugyebar IP cimekhez csatlakozunk, es nem hostnevekhez.)
A DNS frissites annyi ideig tart, amekkora a TTL (time to live) ertek a rekorjaban. Ha ez mondjuk egy perc, es a DDNS kliensed is percenkent frissiti az IP cimed, akkor max ket percig tart a frissites, mert utana a koztes DNS szerverek mind ujra lekerik a hozza tartozo IP cimet a DDNS szolgaltatol.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
"A DNS frissites annyi ideig tart, amekkora a TTL (time to live) ertek a rekorjaban."
A helyzet ennel bonyolultabb. Egyreszt a kulonfele caching dns-ek felulbiralhatjak a ttl-t, masreszt pl. a webbongeszok mar nem tudnak a ttl-rol, ezert ok fix ttl-el dolgoznak. Ez emlekeim szerint IE-knel a 6-ost kiveve 30 perc, a 6-os egyaltalan nem cache-el A rekordot, csak CNAME-et. A firefox 1 percig cache-el.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Szerintem úgy oldhatod meg, hogy mindkét gép ip-jét felveteted sima A rekorddal. Így a dns load balance-olni fog a kettő között round-rubin módon, az inaktívon meg csinálsz egy http redirektet a másikra. Így mindig az aktívra lesz irányítva a látogató. Ezt csinálja a google is (csak ott geoip szerinti átirányítás történik).
- A hozzászóláshoz be kell jelentkezni
Ez alapján akkor ugyebár nem lehet olyan internet kapcsolat a tartalék, ami dinamikus IP címet oszt ki. Annál a szolgáltatónál is fix-et kell kérni. (Ami nem baj, csak a tisztánlátás kedvéért.)
Akkor még mindig érdemes azon agyalnom, hogy lehetne "szépen" bevonni a DDNS-t a képbe...
- A hozzászóláshoz be kell jelentkezni
Szia,
Valamennyi gyakorlatom van ezekben a temakban igy megosztanek _sajat_ tapasztalatot.
Amit az ilyesmi clusterekrol tudok alapvetoen a helyzet hogy a HA megoldasoknal nem konkret teljes servert probalsz HA modba kapcsolni hanem a szolgaltatast. Rendszerint ezekre is epulnek a megoldasok (egyaltalan nem kizarolagosan).
A legaltalanosabb amit 2 geppel megtudsz valositani az lvs (http://www.linuxvirtualserver.org/). Ehhez pedig nagyon jo leirast ad az ultramonkey.org .
Amugy eleve el az-az iratlan szabaly, hogy ha igazan HA szolgaltatast akarsz akkor a gep amin futtatod ha lehet massal ne foglalkozzon. Leven ha anyira fontos a szolgaltatas csak nem kar raaldozni egy gepet. Nade ez inkabb mellebeszeles.
- DNS : A dns servereknek eleve nem kell HA modban menniuk, eleg ha 2 van beloluk mindegyik gepen 1-1 es a clienseknek meg nyilvan mind2ot megadod :)
- Apache laza. HA van egy LVS-ed, akkor egyszeruen ldirectord-vel dobalhatod a kapcsolatokat. A tartalmat erdemes egy 3. helyrol syncelni rsync-el. DRBD-t ehhez nagyon nem javaslom. Elosszor is mert alapvol csak az egyik node mountolhato. Force-olhatod persze, de ha rendes munkat akarsz vegezni, ne csinald. Az iras meg vegkep csak 1ik helyen hasznalhato. Szoval ami nekem bevalt az lvs,ldirectord,rsync a clusteren kivuli geprol.
- Postfix/qpopper. Ezek nekem kimaradtak teljesen tippem sincs de igy ahogy fentebb is irtambiztos nem jo :) Vegul is gondolj bele 2 smtp-d van kapsz egy emailt localba valamelyik lerakja sajat magan az imap a masik serverre csatlakozik es maris buktad. A nagyobbak tobb mx serverrel oldjak meg a tobbit tenyleg nem lattam meg.
- mysql a vegere es a szemelyes kedvencem. Itt mar eleve rengeteg opcio kozul kell kezdo hozza allast valasztanod. Elosszor is az egyik standard a drbd+heartbeat. Itt 1 aktiv es egy passive geped van. A passiv nem csinal semmit csak drbd syncel. Ez egyreszt pazarlas, masreszt lvm (nem lvs, lvm) particiokrol lehet backupolni online. Viszont volt eddig 3 drbd clusterem, ebbol 2 folyamatosan osszeesett es nagyon nem ajanlom. Folleg mert heartbeat ugye nem alkalmazas szinten figyel tehat nem a mysql allapotabol itelkezik masreszt pedig mert drbd nagyon konyen a multe tudja tenni az utolso nehany irast vagy rosz esetben a particiod. Amit javasolnek neked az a mysql standard replikacio. Erdemes megtanulni jodolog. Ha tenyleg durva mysql HA-t akarsz akkor mysql proxy nem rosz kezdemenyezes az MMM pedig kifejezetten production readynek tartom (sot) bar erdemes hozza tudni perl -t es kello melysegig ismerni a replikaciot.
1. rsyncel tukrozhetsz konyvtarakat. De ez se tul HA :D
2. storage engine fuggo, myisam tablakat tudod, ha nincs ra iras. Es amugy erre van a replikacio
3. ha lessz akkor forgalmad aminek kell a sajat halokartya akkor igen. drbdhez szinten nemart, viszont ha csak siman "jatszol" a HA clusterekkel, akkor felesleges szvsz
4. ezt azert teljesen nem ertem. Vegul is igen. minden megoldhato. Ha egy megoldas nincs meg, akkor lekell kodolni :D A forgalom attereleset egy-egy isp eseten mashogy szoktak ami gondolom neked nemopcio. Viszont a domain atiranyitas lehet akar 1 ora is . Az meg sok minden csak nem HA ha mar 1 ora kiesest beleszamolsz. Az isp rendszerint elobb megoldja :D
Sok sikert;)
Ha osszejottek dobj pm-t hatha van munka :)
drk
- A hozzászóláshoz be kell jelentkezni
"- Apache laza."
Viszont ha valami dinamikus dolog fut rajta, akkor nem art valamit csinalni a session-okkel. Vagy replikalni kell a session dirt, vagy behajtani oket adatbazisba.
"Ezek nekem kimaradtak teljesen tippem sincs de igy ahogy fentebb is irtambiztos nem jo"
Alapvetoen de, csak a maileket tarolo konyvtar kozos elereset kell megoldani (a lockolas a legtobb programban meg van oldva). Pl. shared storage, master-master modban futo drbd, valami distributed fs, vagy esetleg ez is megoldhato sql-el keves hackeles aran.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
törölve :) hülyeség volt
- A hozzászóláshoz be kell jelentkezni
Önkritikát nem vártam :D
- A hozzászóláshoz be kell jelentkezni
jujj :D
köszi amúgy a levelet az infókkal :P
elvileg márciusban kezdek
_______________________________
http://gugli.uw.hu/
http://fuckinggoogleit.com/
- A hozzászóláshoz be kell jelentkezni
Köszönöm mindenki hozzászólását, segítségét és az anyagot is ;-) Felkészülök, barkácsolok, és a végén szívesen beszámolok. :-)
- A hozzászóláshoz be kell jelentkezni
novell doksik storage és heartbeat témában
CHASF előzetes és HASI guide (ezek együtt egész jók)
a sles11-nél pedig már szét is lesz bombázva az os és a hasi rész, eléggé rágyúrnak. majd nézd meg.
- A hozzászóláshoz be kell jelentkezni
További lehetőség: Open High Availability Cluster, the open-source code base of Solaris Cluster, a high availability (HA) clustering solution from Sun.
- A hozzászóláshoz be kell jelentkezni