HA Cluster SW Raid

UNIX haladó

Sziasztok!

Lenne 2 gép, gépenként 2 winyóval, erre csak sw raid tehető fel. Szeretnék ebből egy HA Clustert csinálni, úgy hogy egy nagy diskterület legyen közös a két gép között.

Nem túl nagy pervezség az, hogy csinálok minden winyón 2 particiót ezeket páronként összetükrözöm sw raid segítségével, majd ahova a system kerül oda teszek LVM-et, hogy szét lehessen szeparálni kisebb részekre, a maradék helyet pedig összetükrözöm a másik gép maradék helyével.

Ha valaki másképp tenné szívesen venném véleményét.

  • 12020 megtekintés

( cheeky v | 2011. 09. 21., sze – 15:51 )

A szó, amit keresel, clvm.

De hogy mennyire fedi majd az üzembiztonsági elképzeléseid, az egy más kérdés. YMMV.

( m4k3r | 2011. 09. 21., sze – 21:43 )

A szoftveres raid 1 az oké, de én nem biztos, hogy LVM-re tenném a rendszert.
____________________________
sorry for stupid questions!

( Elbandi v | 2011. 09. 21., sze – 22:11 )

diskeken ket particio: egy a rendszernek raid1-ben, egy meg a nagy diskteruletnek. ezt a teruletet drbd-vel osszerakod a ket gepben, arra teszel lvm-et. ha nem csak meleg tartaleknak kell, akkor drbd aktiv-aktiv modban, csak akkor olyan fs-t hasznalj amit ket helyen is lehet mountolni. de lehet a szokasos fs-ek is, csak akkor egy lv-t csak egy helyen hasznalhatsz!

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

VM-ek ala a 100MB/s eleg verszegeny, de a gond az volt, hogy meg ezt se lehetett neha kihajtani, ha a drbd ugy gondolta, hogy o akkor most sync.

De meg a sebesseg elviselheto, meg azon lehet novelni, azonban az allando szeteses sokkal inkabb orolte az idegeinket. Vegul Windows-os storage szofttal oldottuk meg, mert az merfoldekkel stabilabb volt, es szolidabban syncelt.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Miként jellemeznéd a VM-ek alatti terhelést? Szekvenciális nagy sávszélességűnek valószínűnek ritkán lesz mondható. "Sok" VM akár "kis" egyenkénti I/O terhelése összességében "magas" I/O terhelés lesz (véletlenszerű, azaz nem a sávszélesség lesz jó eséllyel mérvadó/szűk keresztmetszet).

"alatt": lemezen szoktam elhelyezni a vm-eket, ebből a relációból kifolyólag a lemez terhelés a VM-ek alatt képződik. Vagy?

Alatt/felett...stb, mindig mindenki mashogy hivja.

Igen, sok kis VM terheles mar osszead egy nagyobbat, de szerencses esetben ez nincs. Marpedig mindenki sajat szerencsejenek a kovacsa:)

Ezalatt azt ertem, hogy ha megfeleloen meretezed, akkor kepez nagy terhelest, ill. erdemes a feladatoknak megfeleloen valasztani a celeszkozt.

Az pedig vegkepp nem jelentheto ki, h nem a halozat lesz a szuk keresztmetszet, mert pl. egy GW eseten feltehetoleg az IO 0 lesz, a halozat viszont kerdeses lehet.

t

Az üzemeltetés ritkán tudja azt méretezni, hogy mekkora terhelése legyen 1-1 VM-nek... Ez tipikusan valamilyen adottság/igény. Vagy szerencséje van az üzemeltetésnek, mert nem jön össze nagy terhelés, vagy nincs szerencséje, ez esetben lehet azt méretezni, hogy mi tudja optimálisan kiszolgálni.

Sehol nem állítottam, hogy a hálózat nem lesz szűk keresztmetszet, mindössze azt a kijelentést cáfoltam meg, hogy 100MBps terhelés általános igényként mutatkozik. Vannak környezetek, ahol csak néhány VM futkos, de akár néhány tucatnál sem jön össze 100MBps átbocsátás.

Hol volt itt arról szó, hogy meg kell határozni egy feladat futtatásának a helyét (VM-ben vagy sem)?
Ha SAN jellegű dologról beszélünk (adatot konszolidálunk magas rendelkezésre állású rendszeren), akkor tároló teljesítmény/terhelés szempontjából majdnem mindegy, hogy az alkalmazások VM-ben futnak vagy sem.

Ha visszaolvasol, Te húztál tombolát: "sok kis VM terheles mar osszead egy nagyobbat, de szerencses esetben ez nincs"

( eax | 2011. 09. 21., sze – 22:43 )

Ha mindenkepp ilyen iranyba akarsz elmenni, akkor drbd, viszont arra keszulj fel, hogy egyreszt ezzel szopni fogsz.
Ha jot akarsz, akkor a masikbol inkabb melegtartalekot csinalsz: eleg gyakran (pl. 15 percenkent) backupolsz ra (figyelsz, hogy konzisztens legyen), es ha az elessel valami gond van, akkor kezzel failoverelsz.

--
"You're NOT paranoid, we really are out to get you!"

Ha sz@r a hálózat, akkor azon a rendszeres távoli mentés is sz@r lesz. Ha elég közel van egymáshoz a két gép, akkor egy darab kábel a két szerver közé, vagy ha nagyon paranoid vagy és/vagy kell a sávszélesség, akkor n darab round robin-os bonding interfésznek...
A csendes memoár és/vagy diszkhiba szintén nem a drbd hibája, drbd-vel is, meg 15 percenkénti mentéssel is hibát visz a rendszerbe.

"Ha sz@r a hálózat, akkor azon a rendszeres távoli mentés is sz@r lesz."

Viszont akkor ott van az elozo mentes.

"Ha elég közel van egymáshoz a két gép, akkor egy darab kábel a két szerver közé"

Gondolom, te is lattal mar szar kabelt, szar halokartyat, szar halokartya-drivert, ...

"A csendes memoár és/vagy diszkhiba szintén nem a drbd hibája"

A hibakat ez nem erdekli. :)

"meg 15 percenkénti mentéssel is hibát visz a rendszerbe"

Naigen, de eletszerutlen lenne erre a problemara TMR-t javasolni. :)
Masfelol viszont messze nem ugyanaz a szitu: ha a master drbd node meghulyul, akkor minden tovabbi nelkul agyon tudja csapni a slave-et is. A melegtartalekos felallasban ez nem igaz, ott csak az a veszely, ha a bithiba az adatokban jelentkezik, es hosszabb ideig nem veszik eszre.

--
"You're NOT paranoid, we really are out to get you!"

Azért megnézném, hogy "a legfeljebb 15 perccel korábbi állapotból mehetünk tovább" hogyan adható el HA-megoldásként. Szerintem sehogy. Ráadásul jelentős diszk i/o és sok, gyorsan változó állomány esetén a sűrű backup terheli az éles kiszolgálót, ergo jelentősen túl kell méretezned. Nekem eddig (kop-kop-kop) nem volt bajom a drbd-vel - és a mintám -mondjuk úgy- elég nagy, darabszámra, terhelésre és össz méretre egyaránt.

"Azért megnézném, hogy "a legfeljebb 15 perccel korábbi állapotból mehetünk tovább" hogyan adható el HA-megoldásként."

Ahhoz kepest, hogy "hat gyerekek, beborult a cluster, a tegnapi backupra tudunk visszaallni ugy 10 ora alatt" szerintem egesz jol.
Amugy nyilvan nem azt mondom, hogy ez az egesz hulyeseg, csak azt, hogy eszkozok, penz, es szakertelem nelkul nem szokott jol elsulni.

"Nekem eddig (kop-kop-kop) nem volt bajom a drbd-vel - és a mintám -mondjuk úgy- elég nagy, darabszámra, terhelésre és össz méretre egyaránt."

Azt azert meseld mar el, hogy splitbraint hogy kezelsz.

--
"You're NOT paranoid, we really are out to get you!"

A drbd-s eszköz csak egy szerveren van használatban, a másik fele egy backup node-ról van kiosztva hozzá. Ha az éles node megsemmisül/elborul/nem javíthatóan le kell cserélni, akkor a backup node-ról visszaszinkronizálok az új/javított éles szerverre - vagy amíg az nincs, addig mehet a kiszolgálás a backup node-ról is, az ottani mount, fsck móka után.

Attól lesz HA, hogy automatikusan átveszi a terhelést? ha igen, és a Slave fizikailag lenyomja a Master-t (mondjuk HP ILO Power off) ott nem lesz split-brain, gondolom.
(persze feladat függő,hogy működhet-e de master->slave manuális átkapcsolás még mindíg gyorsabb mint backupból restore)

"Attól lesz HA, hogy automatikusan átveszi a terhelést?"

Szukseges, de nem elegseges feltetel.

"ha igen, és a Slave fizikailag lenyomja a Master-t (mondjuk HP ILO Power off) ott nem lesz split-brain, gondolom."

... mar ha feltetelezzuk, hogy mindig a jo gep nyomja le a rosszat, es nem forditva. :)
ILO power off-nal meg me'g az is elofordulhat, hogy mindketto lenyomja a masikat, es a vegen ott allunk mukodo gep nelkul.

"persze feladat függő,hogy működhet-e de master->slave manuális átkapcsolás még mindíg gyorsabb mint backupból restore"

Igen, ezt probaltam en is javasolni a problemara, annyi modositassal, hogy a replikacio aszinkron, es konzisztens allapotbol konzisztens allapotba visz, meg esetleg meg lehet tartani 1-2 regebbi allapotot is. Ez nyilvanvaloan bealdozza a masodpercekben merheto RPO-t a hulyebiztossag erdekeben, de ha jol sejtem, itt az elsore kevesbe lesz szukseg... :)

--
"You're NOT paranoid, we really are out to get you!"

hogyan adható el HA-megoldásként.

adatvesztési időtartam: a káresemény elötti idő, az az időszak, aminek adatai elvesznek a káresemény esetén. RPO
Szolgáltatás-helyreállítási idő: a káresemény utáni idő, amíg a szolgáltatás szünetel. RTO

Namármost az a helyzet, hogy az RPO gyakorlatilag soha sem nulla. Gyakorlatilag nullává tehető, ha saját fejlesztésű alkalmazás igen okosan használja fsync()/fdsync()-et, vagy az alkalmazás teljes mértékben egy tranzakciókezelő DB-n alapszik, ami okosan használ fsync()/fdsync()-et. Az adatokhoz nem használsz LVM-et és MD-t (mert ezek nem barrier proof-ok).
Ha csak úgy lazán file-okat irogatsz egy átlag c/php/perl/python/bash cuccal, akkor simán vegyél hozza 8 másodpercet, t.i. amíg az adat biztosan kiér a háttértárolóra a gép memóriájából.

Namármost az is a helyzethez tartozik, hogy az RTO meg aztán tényleg nem nulla. Lesz neked linux, heartbit cluster, gyors cpu, aztán az elindíott második gépen elketyeg néha az fsck pár percig.
Lehet csinálni active-active _alkalmazást_ alkalmazásszintű clusteringgel, egy átlag KKT teljes évi forgalmát rááldozva az implementációra, na akkor lesz neked 10 sec alatt az RTO erre az egy alkalmazásra.

Ekkor jön elő az a helyzet, hogy odaállítasz a T. megrendelőhöz a szolgáltatásoddal, mondod, hogy RPO=0s, RTO=5s, meg odaállok én, és az első pár órában csak kérdezősködöm, hogyaszondja "mi a nagyobb kár, az szolgáltatás-leállás, vagy az adatvesztés?", esetleg "mi a nagyobb kár, az adatvesztés, vagy az adatkompromittálódás" Ha nem tud válaszolni, akkor segítek, egy-két napon belül megvan, hogy mi kell a cégnek.
Ha véletlenül ez ugyanaz a cég, akkor a T. megrendelő megkérdi, hogy "miért van az, hogy tőled csak a felmérés drágább, mint a Zeller által nyújtott teljes HW+SW?" Akkor kénytelen vagyok feltenni mindenféle egyéb gusztustalan kérdéseket, hogyaszondja "honnan tudja az egyik node, hogy a másik elesett? mi van, ha az alkalmazás elesett, de a kernel pingik? mi történik, ha véletlenül duál mountolt lesz egy ext3? mi lesz a security kernelfixekkel, ha időközben sokat változott a drbd?"

Rengeteg linux-only HA működik az országban, egyik gépterem egyik gép, másik gépteremben a párja, külön ISP, md+lvm+drbd, és a megrendelő meg van róla győzödve, hogy RPO=0s, hiszen a szolgáltató ezt vállalta. És tényleg működnek is, és rengeteg féle hibalehetőség ellen védettek is. És rengeteg ellen meg nem.

ez a hozzászólás igazából nem teljesen neked szolt, csak te tettél fel jó inditó kérdést :-)

Ez azert igy nem korrekt, mivel fogalmad nincs, o milyen kerdeseket rakott fel, plane arrol nem, mi a megrendelo igenye. Ha neki az HA, hogy a supportos elintezi a failovert, akkor az a HA.
Ahhoz kepest tuti H-bb, mint rsync-elgetni ide meg oda. Mondom ezt ugy, hogy van eset, amikor az lehet a megfelelo megoldas.

tompos

Az a baj, hogy a drbd-nek nincs ugymond alternativaja, vagyis egy masik olyan project, ami funkcionalitasaban ugyanezt hozna. A drbd viszont instabil, vagy ha epp stabil, akkor az IO sebessegenel a banyabeka is beerdeklodik az ajton. Magat a feladatot kell ujraertelmezni valahogyan.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nekem még sose tűnt fel, hogy a DRBD instabil lenne. Igaz, nem is használom allow-two-primaries módban. Akkor most szar a drbd vagy nem? És ha igen, akkor mit helyette? Mert ha jól értem nincs helyette semmi?

A feladat meg általában nem olyan, hogy találd ki magadnak, meg van adva, hogy mit kell megoldani. Speciel nálunk kacagva viszi a terhelést a DRBD.

Ha nincs percenkent kurvasok io, akkor rohogve, egy weboldal terheleset ra lehet rakni. Mondjuk, talan tobbet is. Nalunk virtualis gepek alatt verzett el, meghozza nagyon csunyan, vagy szethullott, vagy amikor nem hullott szet, akkor meg olyan i/o teljesitmenyt produkalt, mintha az adatparkban lett volna a cucc egy 256 kbites vonalon (tulzok, de kegyetlen lassu volt).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Akkor most szar a drbd vagy nem?"

Abbol a szempontbol nem szar, hogy amit ebbol a helyzetbol (2 node, shared-nothing, block device szintu replikacio) ki lehet hozni, azt kihozza.
Abbol a szempontbol szar, hogy ez a helyzet rengeteg lehetoseget ad a szivasra, ami pl. egy rendes SAN-al, vagy egy rendes elosztott halozati filerendszerrel elkerulheto. Persze ezek meg nem mukodnek az adott peremfeltetelek mellett.

De a dolognak csak egy kis resze a drbd, a cluster manager legalabb ennyire benne van a dologban - nem is ertem, hogy miert erre akaszkodott ra mindenki.

--
"You're NOT paranoid, we really are out to get you!"

hat ezzel valahogy en is igy vagyok... az a csoda hogy mukodik: 


ls: ./f/e/fee71306-orig.jpg: Transport endpoint is not connected
ls: ./f/e/fe036416-orig.jpg: Invalid argument
ls: ./f/e/fe27387f-orig.jpg: Invalid argument
ls: ./f/e/fe4c4e40-orig.jpg: Invalid argument

erdekes a ./f/e/fe497265-orig.jpg fajl le tudja olvasni...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( freeoli v | 2011. 09. 22., cs – 14:49 )

Glusterfs-el is tudsz egyszerűen két különálló területet egybe rántani.

( wyx v | 2011. 09. 22., cs – 22:32 )

Ötletes megoldás lehet:

mindkét gépen egyenként sw raid1, majd az md0-t kiosztani iscsi targettel,a másikon iscsi kliens, amely az előző iscsi-s md0-t mint fizikai meghajtót beteszi a saját lvm-jébe.

így: iscsi raid1 + raid1 -> lvm

(stabilitást tesztelni kell a hálón!)

( macroharddoors v | 2011. 09. 24., szo – 14:18 )

Mivel nem irtad hogy csak linux, nezd meg ezt is googleban, freebsd + hastd + gvinum + gmirror + ggated + carp.

persze, rövid legyek? Szar :)

na a viccet félretéve, a carp-al van probléma, init alatt amikor beáll a carp vmilyen állapotba, a devd.conf-ban bekonfolt up/down script nem hajtódik végre, tehát:

devd.conf:
notify 100 {
match "system" "IFNET";
match "subsystem" "carp0";
match "type" "LINK_DOWN";
action "/root/hast_ucarp_down.sh";
};

notify 100 {
match "system" "IFNET";
match "subsystem" "carp0";
match "type" "LINK_UP";
action "/root/hast_ucarp_up.sh";
};

itt látszik ugye, hogy a carp master/slave állapotváltozásának függvényében leszalad vmelyik script, ezek konrétan a HAST role-t állítják be, hogy primary vagy slave legyen.

Namost, amikor elindulnak a storage szerverek, ezek a scriptek nem futnak le, ebből adódik, hogy a HASTD role az init state-ben beragad, tehát semmi sem történik. Kézivezérléssel kell vmelyik gépet slavénak vagy masternak meglökni. Van erről vmi diskurzus a levlistákon, hogy reszelni kellene/fognak vmit a carp-al. Viszont ha nem carp-al oldod meg a HA-t, hanem vmi mással, pl. VRRP, HeartBeat akkor minden ok, megy rendesen.

itt van erről néhány szó:
http://blather.michaelwlucas.com/archives/224

Ha részletesebben érdekel a full konfig akkor a többit privátba.

update: a gebasz konkretan ott van hogy a devd a carp utan indul el devd utan meg hast az init alatt, es addigra mar a carp beallt egy allapotba...szoval ez igy impossible mission.

update2 igy hajnalba:
problema megoldva, az init sorrendben a hastd-t a devd elé raktam + belereszeltem egy kicsit a gyari carp up/down scriptbe es minden franko :) Ha erdekel a megoldas majd mashol leirom reszletesen. Tobbiektol elnezest az off-ert.

( E-Medve v | 2011. 09. 24., szo – 19:13 )

subscribe (a téma érdekessége miatt)

( wladek1 | 2011. 09. 25., v – 21:31 )

Erdekelne a tema engem is, de mast se latok, csak hogy szar a drbd meg hogy nem szar, mer' jo.
Remelem, hamarosan kiderul valamelyik; lehet ki kellene ra irni szavazast...:)

Konkretan a drbd-t weboldalak es mail szerver alatt hasznalom master-slave felallasban, nincs gond.
A lustre alatt hasznaltam a lustre doksijaban megadott modon, oda szornyu rossz volt, az IO-t megolte, idonkent pedig panikolt is. Amikor kikerult a kepletbol jelentosen csokkent a panikok mennyisege. Ez jo reg volt (~ v0.7), azota sokminden valtozhatott, de azert a sebessegben drasztikusan nem valoszinu.

glusterfs: Replikacio nelkul hasznaljuk, a replikacio megolte itt is az IO-t, de persze feltehetoleg nem annyira, mint drbd+akarmilyen clusterfs eseten a master-master mod (soha nem probaltam szemelyesen, csak munkatars mereseit olvasgattam regebben). Itt viszont nincs szo semmilyen webes kornyezetrol, a terheles fontos, igy vegulis teljesit, kisebb nagyobb hibakkal. Mostanaban voltak nagy lazongasok a community reszerol az sw silanysaga miatt (ahelyett, h egyszer stabilizalnak, mindig raknal bele uj feature-oket is). Az utobbi idoben aztan rafekudtek a temara, talan lassan jobb lesz a helyzet.

Nem lehet altalanossagban osszehasonlitani oket amugy, mivel mint korabban irtam, mas layer-en dolgoznak. Az adott feladat szempontjabol erdemes megvizsgalni.

Van meg ilyen is, h moosefs: A gemius fejleszti, erdekes elgondolasokkal. A felhasznaloi szerint leginkabb abban kulonbozik a glusterfs-tol, h mukodik. Valo igaz, h a replikacio neki nem olyan nagy problema. De a meta szerveres megoldasukat azert erdemes vegiggondolni, hogy lehet biztositani a tutit.
Szubjektiv, de nekem bejott.

Igy jo lesz?:D

t

rövidre fogtad :) Írhattad volna akár a Glustert, az LVM-et, a RAID X-et, bármit.... mert ahogy én átfutottam a topikot sorra jönnek a pro/kontra dolgok. Csak tudnám, hogy én mint Gluster és DRBD használó/adminisztráló mikor kezdek majd el panaszkodni!? Mert én elfogadtam, hogy egyik se tuti, de mivel jobbat meg nem találtam, így mondhatni elvagyok velük :P

( ody42 v | 2011. 09. 26., h – 20:45 )

Az ILO power off-nak nem pont az a lenyege, hogy az SP egyfajta quorumkent mukodik? (hogy ne legyen split brain allapot)