CentOS redundáns MySQL Cluster + PHP + Mail + Apache? megoldás?

Linux-haladó

Sziasztok!

Először is köszöntök mindenkit. Régóta olvasom a HUP-os írásokat, fórumot, nagyon örülök, hogy itt lehetek! \o/ :-)

Szeretném megtanulni, megérteni a redundáns megoldások működését.
Ha nagyon triviális dolgokat írok le, elnézést kérek előre is, csak szeretném, hogy biztosan elsőre értsétek.

Elmondom, hol tartok:
- Régóta használok Linux alapú szervereket különböző dolgokra, főként mint fejlesztő. Utóbbi időben CentOS-t, régebben Debian-t és néha Ubuntu-t. CentOS irányba akarok menni.
- Raktam már össze MySQL Cluster-t sikeresen manuálisan és a Severalnines féle ClusterControl Configurator For MySQL Cluster eszközzel is.
- Állítottam be MySQL alapú Postfix levelezést, spam szűréssel. DNS Failover-ről olvastam, de nem tudom, hogy tudnám megoldani. Van saját domain-em, hozzáférek a DNS szerverhez, bármit be tudok állítani rajta, az egy CPANEL-es gép. De itt tartok.
- Raktam fel Apache-ot és PHP-t MySQL támogatással.
- Használtam HA + DRBD alapú MySQL + Apache + PHP (LAMP) szervert, az jól működött, de ott nem volt MySQL Cluster. De nem én telepítettem, de értem a működését nagyvonalakban azt hiszem.
- Cacti-t és Nagios-t is használtam, Zabbix-ot sokan javasolják, de még nem teszteltem. Egyiket sem telepítettem még. Tetszik elviekben a Zabbix kliens támogatása és hw detektálása.

Olvastam többféle leírást, például:

- Zabbix (Failover Zabbix, MySQL, Apache and Postfix with DRBD-Pacemaker

Ami van:

- sikerült kölcsönbe kapnom sok hónapra 4 magos 6-8 éves Xeon alapú szervereket 8 GB memóriával, ezekkel tudnék "játszani", valamint van még 2-3 kisebb teljesítményű max 2-4 GB memóriás, 1-2 processzoros desktop gép, amivel bármit csinálhatok, össze vannak kötve gigabites switch-en, van több hálózati kártyám, ha kell.
- a gépek nincsenek kint a neten, de ha nagyon kell tudok netet adni nekik, például a telepítés idejére

Cél:

- Redundáns rendszer kiépítése: ha kihúzom az egyik gépet a konnektorból, minden szolgáltatás működjön, adatvesztés nélkül
- 1, esetleg 2 figyelő szerver felépítése, akár ezt is redundánsra, de ez későbbi lépés
- Az már csak extra lenne, ha közben a másik gépet is lehetne bizonyos dolgokra használni. Ami jó lenne, ha a passzív gépen is menne a web szerver, de ha nem bonyolítom túl, akkor azt úgy állítom be, hogy mindig menjen, és nem kell a HA-nak vagy bármi failover alkalmazásnak kapcsolgatnia, és kész.
- az apache+php-nek egész nagy lehet a memóriahasználata (persze a kódtól függ), ha van gyorsabb, kevesebb memóriát használó php-t futtató megoldás, az is jó lehet, nginx
- varnish használat akár, azt sem teszteltem még
- extra: akár másik php változatot is felrakni egy elkülönített részre, más port-ra (más web szerverként), tesztelni, de ez a legutolsó, ami kell, csak ez sem lenne rossz... ennek még nem néztem nagyon utána
- lehetőleg mindent package-ekkel megoldani, hogy minden frissíthető legyen. Például CentOS-re counter-imap-os postfix-et régebben csak manuális fordítással sikerült akkor megoldani, de már van dovecot-os package-es megoldás erre, ami működik (remélem, ezen nem röhögtök... nagyon... :)

Szolgáltatások a célhoz, ami mind a két szerveren folyamatosan menne:

- web szerver (nem ragaszkodok az Apache-hoz, csak a PHP minél gyorsabban fusson) + PHP, tehát a web szerver az mindkettőn mindig menne. Itt a web szerver konfigurációt DRBD-re raknám, hogy ugyanaz legyen mind a kettő helyen. Sőt, a /var/www -t is a DRBD-re, hogy ugyanaz legyen a tartalom. Tehát ha feltölt valaki egy file-t a DRBD alapú helyre, akkor ott legyen a másik szerverről is. NDB-nek köszönhetően az adatbázis bejegyzés is lesz, hogy van feltöltés, tehát elvileg jó lesz. Kihagytam valamit?

- MySQL Cluster. Rakhatom a management node-okat azonos gépre mint a data node-ok, vagy rakjam mindenképpen 1-2 külön gépre? (legutóbb 2 management node volt 2 data szerverhez, amikor próbálkoztam ezzel és jó volt). Jól gondolom, hogy az NDB-nek nyilván nincs szüksége a DRBD-re és semmi hasznosra nem tudom a DRBD-t használni az NDB-nél?
- Ha lenne használva a sima MySQL, hogy oldjam meg? Mi a legjobb, ha 2 irányú adatok jöhetnek, nem 1 irányú? De első körben mindenre NDB-t használnék.
- Galera MariaDB Cluster lesz + arbiter az egyik gépen, nem MySQL Cluster

Szolgáltatások a célhoz, aminek redundánsan mennie kellene: (szerver1 és szerver2)

- Redundáns levelezés megoldása. Postfix irányban indulnék el, az adatbázis NDB-ben Galera Clusterben lenne. MySQL-t használtam eddig postix-szel, gondolom működni fog. Valaki használt már NDB+postfix párost? Itt sok kérdés van, ha nem elérhető az egyik szerver, hogy fog bejönni a levél a másik szerverre? (közös/virtual IP? Ilyet még nem csináltam). Ha átveszi a szerver2 a szerver1 ip-jét a levelezés miatt, akkor mi lesz azzal a felhasználóval, aki a szerver2 ip-jére csatlakozott? Szóval itt homály van még...
- Hogy legyen megoldva, hogy átvegye az IP-jét vagy a domain nevét a passzív szerver az "eltűnt" szervernek? Mit csinálnék, ha ez egy hosting teremben lenne akár, és átvegye a kiesett gépet?

Management szerver (szerver3)
- valamilyen szerver felügyeleti szoftver használata, Zabbix-et gondoltam kipróbálni, de ez mehet erre vagy akár a erre és egy redundáns párjára is, külön, ahova az NDB management node is kerülne.

Még mielőtt félre értitek: nem azt várom, hogy valaki helyettem ezeket megoldja, vagy ilyesmi, csak iránymutatást, véleményt várnék, hogy jó irányban gondolkozom-e.
Új vagyok itt, de ha megoldható, akkor folyamatosan mondanám hol tartok és ha elakadok, azt is leírnám.
Ha van igény rá, le is írom, mi a megoldás erre. Én amiben tudok, segíteni szoktam mindenkinek, de ha ezt tudnám tökéletesen, nem kérdeznék itt... :-)

Ha bármi észrevételed van, szívesen várom.

UPDATE 1:

DRBD (primary-primary) helyett, ha mind a kettő szervert szeretném használni, de szükség lenne, hogy bizonyos fájlokat mind a két gépről lehessen írni, mi lehet a legjobb megoldás?
Tehát ha az egyik gépen felöltenek webről egy állományt, és lementődik a file rendszerre, akkor a másik gépről is olvasható legyen. Ez a cél.
A file kezelés szempontjából primary-primary modell kellene, és akkor mind a 2 gépen működhetne a webszerver.

- DRBD, de a hagyományos üzemmódban (active-passive), ha failover, akkor elindulnak a szolgáltatások a passzív szerveren. Így bukta a 2 gép egyidejű használata. De elvileg a legjobb adatbiztonságú (?). (lenne persze máshova mentés azért, stb)

- GlusterFS? Érdemes ebben az irányban elindulni?

- NFS / GFS2 / OCFS2

Ha DRBD active-passive, akkor milyen file rendszert rakjak rá? Centos 7-ben alapból XFS van. Legyen XFS, vagy EXT4? Vagy más?

UPDATE 2:
A héten fogok konkrétumokat csinálni, nem csak tervezni és agyalni... :)
DRBD + XFS lesz, leírom, mennyire vált be.
Apache helyett Nginx-et fogok felrakni és LXC-be a PHP CGI-ket.

  • 12046 megtekintés

( blackluck v | 2014. 08. 29., p – 20:22 )

- web szerver (nem ragaszkodok ...Kihagytam valamit?
A clusterelt file rendszert ami tudja kezelni ha egyszerre tobb helyrol tortenik iras.

- MySQL Cluster.
Ndb cluster helyett master-master replika is lehet elegendo ha nem feltetlenul a teljesitmeny miatt kell 2 adat node, esetleg galera cluster

- Redundáns levelezés megoldása.
Kozos ip-t beallitani egyszeru, ha az atkerul 1-es node-rol 2-esre akkor a kozos ip-n keresztul csatlakozott kliensek leszakadnak majd ujracsatlakoznak immar a 2-es node-ra.

A Galera Cluster-t fogom akkor kipróbálni az NDB helyett, ez ha jól gondolom jó lesz a Postfix-nek és az PHP alapú MySQL-es webalkalmazásoknak is.
Sőt, így akkor nem kell a MySQL-es adatbázisokat átkonvertálni NDB-re.
Azt olvastam, hogy a Galera-hoz 3 node javasolt a megbízható működéshez. Nekem 2 azonos, (célnak) megfelelő (régi) szerverem van, a 3. gép csak egy jóval gyengébb régi desktop, ami kéznél van.
Ha berakom ezt a desktop gépet, mint 3. szerver (persze azonos, 64 bites CentOS alapon), majd csak néha szinkronizáltatom össze, akkor jó lehet ez, mint "online mentés", a dump mellett?
Tehát a 3. gépen mondjuk éjfélkor elindítom cron-ból a Galera-t és akkor szinkronizálja majd össze magát.
Vagy nincs szükség a 3. gépre, csak javasolt?
Jól értem a Galera-val kapcsolatban, ha 1 node is megy, és azon van írás, majd visszaáll újra a 2. node, akkor szépen szinkronizálnak és újra redundáns lesz a rendszer?

Jelenlegi megoldás, ami változott akkor:
- NDB 2 node helyett 2 (3?) node-os Galera Cluster lesz. Néztem, ennek van Centos6 rpm-je, repo-ja is, és MySQL replacement-ként működik.

Sakk-matt,
KaTT :)

A 3-ra fel lehet tenni egy Galera Arbitrator nevű cuccot, ami csak azért van, hogy +1 szavazatot adjon (szóval a két igazi node közül az marad master, aki látja az arbitratort). Ha 1 node egyedül marad a 3-ból, akkor annak nem kéne engednie, hogy írhass bele. 2 node-os "cluster" nem tud multimaster lenni.
A masterek elé pedig lehet tenni haproxyt, bár nem tudom mennyit számít, lévén minden írás megtörténik az összes masteren.

Szuper, köszönöm, a Galera Arbitrator lesz a megoldás a monitor gépen.

Tehát ha a 2 valódi Galera Cluster node-ból kiesik valamelyik, akkor ha megy a 3. gép rajra a "Galera Arbitrator", vissza tud állni minden tökéletesen.
Ha a 3. node, a "Galera Arbitrator" áll le, akkor is 100% megfelelően működik a rendszer?
Ha a 3. node mégsem lenne olyan gyenge (de gyengébb, mint a 2 fő), és az is valódi node lenne (de nem lenne rajta semmi terhelés), van értelme még 4.-nek egy gyengébb gépet berakni mint "Galera Arbitrator" node?
Ha van 2 erősebb gép SQL terheléssel és egy gyengébb, de azon nincs SQL használat (csak azért van, hogy 3 legyen), akkor is ez a 3. gyengébbik gép lesz a szűk keresztmetszet elméletben?

Jól értem, hogy később bármikor bővíthető a Galera Cluster újabb node-dal? Tehát mondjuk egy dump-ot felrakok az új gépre, és a minimális változást pedig összeszinkronizálja szép lassan?
Vagy úgy a gyorsabb egy új, valódi node berakása a Calera-ba, hogy ő magának átrakja a teljes adatbázist?
Ez az utóbbi, +1 node berakása csak elméleti kérdés, hogy miért...

Sakk-matt,
KaTT :)

Arbitator vagy arbiter feladata csak annyi hogy meglegyen a 3 node, legyen quorum szavazat, de adatot nem tarol.
Amig 3 gepbol csak 1 all le (mind1 melyik) es masik ketto latja egymast addig mukodik tovabb.
Arbitator-ra nem szinkronizalodnak az adatbazisok, elegendo egy kis teljesitmenyu gep ahhoz, mas is mehet ra mellette nyugodtan, pl a monitoring.

4. gépet nincs értelme berakni, a lényege a quorumos clustereknek, hogy páratlan számú node legyen bennük, különben nincs többségi szavazat split-brain esetén. Ha bővíted új node-dal (vagy csak egy leállítottat indítasz újra), a wsrep_sst_method beállítással választhatsz egy módszert, hogy újraszinkronizálja.

Zsugabubus vagy blackluck:

Ha van Galera MariaDB Cluster a szerver1 és szerver2-n, valamint szerver3-on Galera Arbitrator, akkor lehet a szerver3 és szerver 4-re egy különböző Galera MariaDB Clustert tenni? Továbbá akár a szerver1 vagy inkább szerver2-re egy Galera Arbitratort a 2. cluster-hez? Nem fognak összeakadni, lehet más portra rakni?

Tehát:
- a szerver1 + szerver2 lenne az elsődleges szerver: itt mindkettőn menne az Apache és a Galera MariaDB Cluster is, de lenne master-master DRBD cluster FS-sel, például GFS2.

- mondjuk 2 gyengébb gép, a szerver3 + szerver4 redundáns monitorozó szerver (pacemaker+corosync+drbd), ez aktív/passzív, "hagyományos" drbd, csak az egyik üzemelne, kivéve a
Galera MariaDB Cluster szolgáltatást, az mindkettőn menne. A DRBD itt mehetne sima FS-en, nem kellene GFS2, de lehet ha már a fő szerveren az van, lehetne itt is? Hátránya a GFS2-nek, ha sima file rendszerként van használva?

Ez így kivitelezhető elvileg?

Sakk-matt,
KaTT :)

Be lehet allitani neki masik portot es masik mariadb clusteren elfer egy plusz arbiter.

Egyebkent master-master drbd-t, illetve foleg inkabb clusterelt file rendszert nem ajanlom ha nem akarsz sokat szivni. Konnyen ossze tudja halni magat egyideju lock-ok miatt ha nincs jol beallitva vagy akkor azokbol is 3 node-ot szamolj (megha egyik csak arbiter jelleggel van is) illetve fencing/stonith-ot is tudj allitani hozza.

Mit javasolsz akkor arra az esetre, ha 2 gépen kellene egy időben PHP+MySQL alapú rendszert futtatni, hogy a PHP kezel mentett fájlokat. Tehát a szerver1 gépen mentett fájlt a szerver2 gépről is tudni kell olvasni. Az adatbázis is mind a két gépről elérhetőnek kell lennie. Főként azért 2 gép, hogy elossza a terhelést, de azért is, hogy ha az egyik elromlik, elérhető legyen az összes szolgáltatás.

Mi a megoldás erre?

Vagy legyen a hagyományos DRBD megoldás, hogy 1 szerver aktív, a másik pedig passzív, és úgy megbízhatóbban működik? Tehát ha az aktív leáll, akkor a másik átveszi a helyét és ennyi. Csak jó lett volna elviekben, ha minimálisan ugyanarra használható a passzív szerver is.

(szerver1+szerver2 drbd gfs2, monitor1+monitor2 drbd gfs2)

Vagy ha úgy lenne, hogy a szerver1 és szerver2 mellett a monitor1 lenne a 3. node a DRBD-nek mint arbiter és lenne fencing/stonith is?
Valamint a monitor1 és monitor2 DRBD-je arbiter node a szerver2 lenne?

Nem akarok semmit túlbonyolítani, csak a megvalósítható megoldást keresem.

Sakk-matt,
KaTT :)

( ody42 v | 2014. 08. 29., p – 21:04 )


- MySQL Cluster. Rakhatom a management node-okat azonos gépre mint a data node-ok, vagy rakjam mindenképpen 1-2 külön gépre? (legutóbb 2 management node volt 2 data szerverhez, amikor próbálkoztam ezzel és jó volt). Jól gondolom, hogy az NDB-nek nyilván nincs szüksége a DRBD-re és semmi hasznosra nem tudom a DRBD-t használni az NDB-nél?

Nekem az a tapasztalatom, hogy a management node nem szereti az overload eseteket, pláne ha kicsi timeoutok vannak beállítva, így én nem pakolnék rá mást, vagy ha mégis, akkor annak korlátoznám az erőforrásait (pl. LXC)
Ha kevés a vas, akkor már inkább a data node mellé pakolnék sql nodeot.

Az NDB engine egy shared-nothing rendszer, így nem kell neki DRBD sem, hiszen a data nodeok között szinkron replikáció van.

( jupiter2005ster v | 2014. 08. 30., szo – 17:27 )

en esetleg egy HAproxy-val 'fuszereznem' a webservereket. Az HAproxy figyelne localhoston es az loadbalancingolna a kereseket a master-master MySQL fele.
valahogy igy:

apache+php ->localhost port:3306
HAproxy figyel a 3306 porton es az tovabbitja hol ide hol oda a kereseket.

ezutan nem kell bajlodnod a terheles eloszlassal.

meg valami, ha van vas akkor lehet kulon 'write' node (amicsak ir) es 'read' node (ahonnan csak olvasas tortenik) a MySQL-hez es tapasztalatom szerint nem lassul be. persze ez nem a legolcsobb (HW igeny) megoldas.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

ez alkalmazastol fugg. ha php webapp siman (HA es Fault Tolerance nelkul) kacsolodik azaz host=1.24.5.3 blabla
akkor nagyon egyszeru, csak lecserelled a host erteket a php alkalmazasban es kesz is.

csinalhatnal egy blogot a reszletes sw verziokrol es beallitasokrol amiket hasznalsz, ha van ra idod.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Köszönöm az infókat, haproxy majd később lesz. Most még a DRBD megbízható működése a kihívás, hogy primary-primary+arbiter (GFS2), vagy legyen hagyományos aktív-passzív...
Nem tudom megígérni, hogy csinálok blogot, de ide megírom, hogy mire jutottam, ha úgy megfelelő.

Sakk-matt,
KaTT :)

( KaTT v | 2014. 09. 03., sze – 23:31 )

Lásd első hozzászólás, lent: UPDATE1!

Sokat KaTTogott az agyam, mit rakjak ezekre a teszt szerverekre, milyen megoldást.

Elolvastam nagyon sok írást mindenféle redundáns megoldásról.
A DRBD primary-primary megoldást elvetem, mert nem érzem úgy, hogy a 8.x-es DRBD-t be tudom úgy állítani, hogy nagyon biztosan menjen.
(azért egy kis sikerélmény sem lenne rossz, hogy működik a failover...)

A DRBD hagyományos aktív/passzív üzemmódban megbízhatónak tűnik, de nem vagyok biztos benne, hogy kell blokk szintű szinkronizáció nekem, ha van más megoldás, amivel tudnám egy időben használni az azonos adatokat, persze főleg olvasni.

Bevallom, nem egyértelmű számomra, hogy melyik út a legmegfelelőbb.

Szempontok:
1. Legfontosabb: a minél nagyobb adatbiztonság, megbízhatóság és rendelkezésre állás, hogy a 2 gépből az egyik biztosan menjen, és rajta a web szerver és az adatbázis.
2. Második szempont: hogy mind a 2 gép egy időben használható legyen (web szerver+adatbázis + közös file rendszer, mind a 2 webszerver ugyanazokat az állományokat lássa).

Ha választani kell, akkor az 1. út. Ha mind a kettő megoldható, akkor a 2. ... :-)

Mi a legjobb a szempontok alapján szerintetek?

A. DRBD (aktív/passzív) + valamilyen hagyományos file system? XFS? EXT4? FAT16??? :-D
B. DRBD (aktív/passzív) + valamilyen clustered file system? GFS2? GPFS? OCFS2? (elvileg lassabb és van valami előnye? megbízhatóbb?)
C. clustered file system megoldás?
D. Shared-disk / storage area network megoldás?
E. Distributed file system megoldás? GoogleFS?

Sakk-matt,
KaTT :)

Szervusz!

Én is beszállok.
2 gépből soha nem fogsz üzembiztos fürtöt építeni:
Csak próbáld ki, építsd egy 2 node-os clustert drbd-vel, és rántsd le a két gép között a hálózatot. A cluster azonnal kettéhasad, és mindkét gép azt fogja hinni, hogy a másik megállt, és azonnal oda rántják a drbd kötet magukhoz -és lőttek az adataidnak. (split brain)
Rendes clustert 2-nél több páratlan számú node-ból szokás építeni, hogy minden esetben biztosított legyen a szavazattöbbség (quorum) DE ezt már szerintem leírták előttem.

IMHO sem az 1-es pontot nem teljesül sem pedig a 2-es páros node szám esetén.
Kukázz egy gépet amire nem teszel erőforrást, és nincs más dolga mint szavazni, így ha 1 géped elhullik akkor is meg lesz a szavazattöbbséged a fürtben.

Addig míg nincs meg a páratlan számú node-od, fejleszd a kettős látásodat.
-a cluster kommunikációt két független ringen csináld, így ha lemegy az egyik ring akkor sincs akkora para;
-vagy kösd őket össze soros porton és azon alakíts ki egy ringet;
-A drbd szinkront tedd aggregált interface-re
-stb

Ha mindkét gépet aktívan akarod használni, akkor konfiguráld úgy fel, hogy a webszerver és az adatbázisszerver külön node-on fussanak, és ha elesik az egyik csak akkor költözzenek össze, de ha visszatér a lehalt node akkor újra terhelje szét.

Konfgurálj fel fencing device-t néz meg mi történik egy kiszavazásnál.

Ha gyakorolni akarsz akkor szerintem ezeket próbálgasd. Mert tényleg nagyon vagány, hogy aktív aktív üzemben van húú meg hááá, de szerintem azért vannak itt érdekes dolgok amiket érdemes jól körbe járni, hogy tényleg stabil környezetet tudj építeni.

Üdv!

Tisztelt Sherpa! :)

Köszönöm a hozzászólásodat, nagyon konstruktív volt.
Azt nem írtam le egyértelműen, hogy azóta van másik 2 gép is, nem 100% hasonló, de egész hasonló konfigurációk, persze gyengébbek, mint a fő játék szerverek.
Tehát úgy fogom megcsinálni, hogy az elsődleges szerver 2 x 1 gép (s1,s2), valamint a monitorozó szerver is 2 x 1 gép (s3,s4).
Zabbix-et fogok rakni a monitorozó gépre.
Az arbiter (quorum?) az s1-s2 páros esetén az s4 gép lesz, az s3-s4 páros esetén az s2 lesz.
Alapból az s1 és s3 gép fog menni.

Még ott nem tartok, hogy hogy oldom meg az arbitert a DRBD-hez, hogy a passzív gépen legyen, de lehet egyszerűbb, ha az aktív gépek lesznek az arbiterek is. Tehát ha lehal az s1, amint fut az s3-s4 arbitere, akkor passzívból aktív lesz az s2, és az lesz az arbiter.

Jól megoldás az arbiter gépnek, hogy a VIP-et (virtuális IP-t) adom meg? Vagy erre mi a leginkább ésszerű megoldás?

Az adatbázis Galera MariaDB Cluster lesz, ami az s1-s2 gépen fog futni, és arbiter pedig az s3-s4 közül valamin, lehet akkor itt is az aktív gépen.
Itt is az a kérdés, hogy lehet-e az arbiter gép redundáns szerveren? 2 ip legyen az arbiternek (s3 és s4), vagy csak az s3 és s4 VIP-je?

"-a cluster kommunikációt két független ringen csináld, így ha lemegy az egyik ring akkor sincs akkora para; "

Erre én is gondoltam, hiszen a gépek switch-en és direkt kábel kapcsolattal is össze lesznek kapcsolva.
Hogy lehet 2 független ring-et megadni? Bevallom, erről még nem olvastam/láttam sehol megoldást, de nagyon logikus.
Ez úgy működne, hogy alapból a direkt kábelen keresztül kommunikálnak, aztán ha azon nem tudnak valami miatt, megpróbálják switch-en keresztül, és ha ott sem jó, akkor lesz failover?

Apropó, kábel: mennyire van jelentősége, hogy milyen minőségű a kábel (sebesség, loss, stb)? Mármint hogy mennyire márkás. A másik, hogy CAT5, CAT5E, CAT6-os kábelt rakjak a 2 gép közé, gigabites hálózati kártya esetén? Úgy tapasztalom, hogy sima, nem crosslink kábellel is látják egymást a normálisabb hálókártyák. Hol vásároljak ilyet? Van több gyári, ilyen-olyan kábelem, látszólag tökéletes velük minden, összeállnak a gépek gigabiten mindig.

Ha a fő gépes DRBD-hez akarok mentést is az aktív monitor gépre, ha a monitor gép is drbd-s lesz, van értelme még egy drbd blokkot definiálni, hogy online oda készüljön másolat, vagy legyen iSCSI? Van értelme ebbe belekeverni az arbitert? Ha már úgy is arbiter, lehetne +1 másolat akár... De ha nagyon bonyolítja a dolgokat, akkor marad a jól bevált cron-os x naponta tar+gzip/7zip mentés... :)

DM-RAID + DRBD?
A monitor gépekre DM-RAID mirror lett. Működik megfelelően, azon fut a CentOS. Hagytam helyet a DRBD-nek, még nem raktam fel.
Soha nem használtam ez előtt DM-RAID-et, csak hardvereset, ami transparent, azaz nem látja az operációs rendszer a RAID-et. Úgy könnyű megadni a DRBD-nek a dolgokat.

Hogy oldjam meg, hogy DM-RAID-es legyen a DRBD? Most ott van X GB mindkét lemezen üresen, mindkét monitor gépen.
Lesz a szabad helyen még egy RAID 1 MIRROR, majd az XFS helyett DRBD, és az XFS?
Vagy érjem el, hogy elsírjátok magatokat, méretezzem át a teljes kapacitásra a DM-RAID-et, majd 1-1 file-ba dolgozzon a DRBD? :-D

dd if=/dev/zero of=/var/izgalmas/es/szereny.drbd bs=1k count=100000000
mknod /dev/loop123 b 7 255
losetup /dev/loop123 /var/izgalmas/es/szereny.drbd

Ennek az lenne az előnye, hogy könnyű lenne mentést csinálni a DRBD-ről, valamint ha gyorsan kell a hely valami másnak, elég 1 file-t letörölni... ;-)

Sakk-matt,
KaTT :)

Szervusz!

Az igazat megvallva az arbiter nem ismerem, sőt egészen idáig nem is hallottam róla (ez nyilván engem minősít és nem az arbitert), úgyhogy ebben sokat nem fogok tudni segíteni.
Sőt fokozom a Galerát sem használtam még éles környezetben, így messze menő tapasztalatom azzal sincs, de felsejlik a doksiból néhány dolog, mint pl hogy érdemes minimum 3 node-ra telepíteni meg ilyenek :)

A több ringes kommunikáció beállítása az cluster suit függő, bevallom elvesztettem a fonalat, hogy mit fogsz használni, én Heartbeat - Pacemaker tengelyen mozgok, így onnét tudok csak példát hozni. Ott egyszerűen a kommunikációs rétegnél meg tudsz adni többet pl:

interface {
ringnumber: 0
bindnetaddr: 10.0.0.0
mcastaddr: 226.94.1.1
mcastport: 5405
ttl: 1
}
interface {
ringnumber: 1
bindnetaddr: 172.16.0.0
mcastaddr: 226.94.1.2
mcastport: 5407
ttl: 1
}

Mindkét ring-en folyamatos a kommunikáció, és ha az egyik leszakad akkor beindul a logban a hiszti.

Kábel:
Jelen körülmények között teljesen mindegy milyet használt, hálókártyát meg "a legelső sarki fűszeresnél" tudsz venni. Mivel játszóteret építesz ezt a részét nem lihegném túl... esetleg arra figyelj legyen rajta RJ45 :)

A mentésnek sem kerítenék túl nagy feneket, ha egyszerűen akarsz menteni akkor használj rsnapshot ssh-n gyönyörűen tud menteni, és olyan egyszerű mint a faék.
Ha komolyabb backup megoldást szeretnél akkor meg érdemes megismerkedni a bacula-val vagy az amanda-val, (meg ne kérdezd, hogy melyik a jobb! :) ) DE szerintem haladj apránként.

Nincs különbség a drbd-nél, hogy egy mezei diskpartíciót adsz meg neki, raid kötetet, vagy LVM-et, megeszi mindent és boldogan használja.
A filerendszeren lévő image drbd mirror-ba szervezése tesztre jó, játszani tökéletes, DE éles környezetben ne használd!
Magát az image-et menteni valóban egyszerűbb, de nem fogsz konzisztens állapotot kapni, és egyáltalán nem lesz garantál az sem, hogy utána fel tudod éleszteni!
Szóval ha rám hallgatsz akkor LVM kötetekre teszel drbd-t, kellően flexibilis ugyan egy kicsit lassít, de tekintve, hogy nem éles környezetről beszélünk nincs jelentősége.
A drbd mentését meg a cluster címen csinálnám, mert az mindig ott van ahol a kötet Primary fele.

De kövesd a fokozatosság elvét, nem kell mindent megcsinálni egyszerre, türelem!!!

Üdv!

"Legfontosabb: a minél nagyobb adatbiztonság, megbízhatóság és rendelkezésre állás, hogy a 2 gépből az egyik biztosan menjen, és rajta a web szerver és az adatbázis."

Akkor ne (L)AMP legyen. Vagy ha mégis (L)AMP, akkor ne az legyen fontos az, ami a legfontosabb...

Bevallom, többször elolvastam amit írtál, de ott mindig elakadok, hogy:

"ha mégis (L)AMP, akkor ne az legyen fontos az, ami a legfontosabb".

Ha esetleg úgy csinálnám, hogy felrakok 2 alap CentOS 7-et, minimum install, internet kapcsolat nélkül a helyi hálózatra, rakok a gépekbe 4 darab duál gigabit hálókártyát, így lesz 10 port/gép, majd összekötöm mind a 9 kábellel külön subneteken (1-1 megy a switch-be), 2 Wi-Fi kártyát (11 ring, ebből 9 kábel, egyik csak jó lesz), rakok RAID6-ba 4 darab új 2 milliós SDD-t gépenként (HP 741159-B21), megcsinálom aktív/passzív DRBD + Corosync + Pacemaker, majd lecsupaszítom a szervert a nem szükséges alkalmazásoktól és szolgáltatásoktól, és nem futna rajta SEMMI más. Majd ha adatot akarok tárolni, akkor rámásolom, hátha nem veszik el. De nem futtatok rajta semmi egyebet, mert akkor már növekszik a hibalehetőség. Majd kiírom papírra a fontosabb biteket és elvégzem a számításokat a szolgáltatások helyett, így megbízhatóbb lesz az adattárolás.

Így már lehet fontos az, ami a legfontosabb és (L)AMP? Remélem érted, _Franko_. :)
Akkor mi legyen, mit javasolsz? VxWorks? VMS? Solaris? Menni fog az őskövület Xeon-on? :)

Sakk-matt,
KaTT :)

"adatbiztonság, megbízhatóság és rendelkezésre állás"

Ha neked tényleg ez a három a legfontosabb, akkor nem (L)AMP-ot használsz, mert van egy feladatod és megfelelő eszközt keresel hozzá. Ha (L)AMP-ot használsz, akkor valószínűleg van egy (egyedüli) jól ismert eszközöd és azzal próbálsz megoldani egy feladatot, akkor is, ha az eszközöd alkalmatlan a feladat megoldására.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"_Franko_ javaparti,"

Feladathoz szoktam keresni eszközt és szakembert, nem pedig eszközhöz és pillanatnyi (szak)tudáshoz igazítani a feladatot... :)

"h o php-val nem tudna megoldani, ezert egyszerubb beletrollkodni.."

PHP-val egy teljesen hétköznapi session replikációt is csak 3rd party eszközökkel tudsz kényelmetlenül és erős fejlesztői fegyelemmel megoldani, egy aktív-passzív "cluster" pedig eléggé messze van a (!) "legfontosabb a minél nagyobb adatbiztonság, megbízhatóság és rendelkezésre állás" (!) igénytől (és nem is skálázható költséghatékonyan), de felőlem azzal töltitek az időtöket, ami jólesik.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Elore szolok en se ertek hozza, de a stilusod sokat dobott azon hogy ilyen hangulatu lett a szal.
Valaki feltett egy kerdest hogy miert szamit, amire ahelyett hogy kifejtetted volna tapasztalatod alapjan mi az elonye/hatranya egyik vagy masik megoldasnak, kornyezetnek inkabb nekiestel...es csodalkozol, hogy leszolnak.

"Valaki feltett egy kerdest hogy miert szamit, amire ahelyett hogy kifejtetted volna tapasztalatod alapjan mi az elonye/hatranya egyik vagy masik megoldasnak, kornyezetnek"

Ahja... amikor ez a kérdező a közvetlenül megelőző hozzászólásában trollnak tart, akkor utána nekem zokszó nélkül ki kellett volna fejtenem a tapasztalataim alapján az előnyeit és hátrányait az egyéb megoldásoknak és környezeteknek?

"inkabb nekiestel...es csodalkozol, hogy leszolnak."

Nem csodálkoztam. Ha én beszólok valakinek, utána nem várom el Tőle, hogy udvariasan és előzékenyen kifejtse a szakmai véleményét és én se fogom udvariasan és előzékenyen kifejteni a szakmai véleményemet, ha előzőleg trollnak tartanak... és ezzel tényleg lezárom a témát, további jó szórakozást.

Ha meg valakit _valóban_ érdekel a téma, akkor jövő hét szerdán lehet beszélgetni és kérdezni a Java EE 8 tervezett újdonságairól: http://www.meetup.com/javaforum-hu/events/188677712/

Így már értem, köszönöm.

Akkor értsd úgy, hogy LAMP-os környezetből próbálom a maximumot kihozni, ahol az L = Centos 7, az A vagy Apache vagy más, a MySQL inkább Galera vagy Percona XtraDB Cluster az InnoDB miatt, a PHP meg adott, mert azt ismerem... :)

Nincs tapasztalatom JAVA irányban jelentős, így azt elvetettem.

Sakk-matt,
KaTT :)

( KaTT v | 2014. 09. 14., v – 23:23 )

A héten fogok konkrétumokat csinálni, nem csak tervezni és agyalni... :)
DRBD + XFS lesz, leírom, mennyire vált be.
Az arbitert nem tudom még hogy oldom meg a DRBD-nek, de leírom, hogy mi lett.Erre mi a legjobb?
Mármint hogy legyen egy 3. node is, ami csak abban segít, ha mondjuk kihúzom az összekötő kábelt, hogy el tudják dönteni, hogy ki az elsődleges.
Tehát használni akarom a stonith és quorum funkciókat. Ha jól tudom, ezek kellenek és hasznosak, ha 3 node van és 1 aktív fél, 1 passzív és egy "eldöntő".

Adatnak: MySQL Galera/Percona XtraDB Cluster/MariaDB Cluster.
Van értelme a Galera Cluster node-okat LXC-be rakni? Én első körben nem teszem.
Apache helyett Nginx-et fogok felrakni és LXC-be a PHP CGI-ket.
Majd megmérem, hogy mennyi memóriát esznek a PHP CGI-k és próbálom beosztani a memóriát, csak ki kell találnom, hogy mivel szimulálok terhelést.
Javaslat, hogy Nginx-ből hívott PHP CGI-nek mennyi memóriát adjak?

4 gépnek (1-1 fő, 1-1 monitor gép, 1-1 direkt kábellel a 2 hálózati kártyán)
IP cím kiosztás:

szerver1 - szerver2 között, direkt kábel:
172.16.17.1
172.16.17.2

szerver3 - szerver4 között, direkt kábel:
172.16.18.1
172.16.18.2

Virtuális IP címekkel kapcsolatban több minden nem tiszta.

Ha mondjuk ezt a 4 szervert elméletben beraknám egy net szolgáltatóhoz, de csak 2 ip publikus címet kérnék, akkor ha jól gondolom tökéletesen megoldható, hogy a szerver1 - szerver2 közül az aktívé legyen a publikus ip 1, mint virtuális ip, és a 2 monitor szerver közül is csak az aktívnak legyen publikus ip címe (ip 2), azt is úgy kezelje, mint virtuális ip. Tehát ha kiesik a szerver3, azaz a monitor1 gép, akkor átveszi a publikus ip címét a szerver4, azaz a monitor2.
De a belső címük mondjuk nem változik, az 192.168.12.1 - 2. - 3. - 4. a 4 gépnek, tehát ha SSH-val belépek az egyikre, akkor bármelyikre át tudok lépni, még ha nincs publikus címe, akkor is. Gondolom ez így lenne (ha egy switch-en vannak és engedélyezett ez, vagy azonos VLAN-ban vannak).

Ha VIP lesz a publikus IP, és úgy SSH-zom rá, akkor nem fogja az SSH kliens írni, hogy váltott a szerver1 a szerver2-re például, hogy más az IP-hez elfogadott fingerprint? Erre van-e megoldás, vagy kell-e, hogy legyen?

Redundáns OpenVPN...
Ha nagyon vicces kedvemben akarnék OpenVPN-t is rárakni (aztán később a létező összes Linux szolgáltatást :-D ), akkor jól gondolom, hogy meg lehet oldani, ha DRBD-ről olvassa az OpenVPN a kulcsokat, akkor a kliensek nem veszik észre, hogy melyik szerver üzemel? Persze ha közben nincs csere.

Sakk-matt,
KaTT :)