Terhelés megosztás, magas rendelkezésre állás.

Debian GNU/Linux

Üdv!

Belefutottam egy olyan problémába, amire nincsen pontos ötletem hogy miképp oldjam meg.
Van 2 gép, ezt a két gépet két külön szerverteremben fogom üzemeltetni, és ezáltal két publikus ip-je lesz.
A lényeg az, hogy ezen a 2 gépen a terhelés megosztást, adat szinkront meg kellene oldani valahogy, amikor pedig leáll valamelyik gép, akkor is minden elérhető legyen.
Hallottam a HeartBeat-ről, de nem teljesen tiszta, hogy ilyen felállásban hogyan tudnám működésre bírni.

Bármilyen ötlet érdekel, más programmal is, de 3.ik szervert nem tudok emiatt beszerezni.

A válaszokat előre is köszönöm!

Üdv,
djpety

  • 3273 megtekintés

( suckit | 2009. 09. 25., p – 19:45 )

Aggasztóan sok mostanában az ilyen jellegű kérdés itt. Már-már attól félek, hogy a közeljövőben felbukkanhat egy olyan levél, hogy:
"Egy atomerőmű bővítését, korszerűsítését kellene elvégeznem, de mivel nem értek hozzá, sosem foglalkoztam ilyennel, nincs tapasztalatom, nem tudom hogy kezdjek hozzá. Tudnátok segíteni?"

Ne vedd magadra, de ezek olyan problémák, amelyekre mások százmilliókat (milliárdokat, feladattól függően) költenek (persze meg lehet csinálni barkács módszerekkel is, adott esetben még jobbak is lehetnek, de mindenképpen félelemmel vegyes rekeszizom-görcs kerülget ezektől).

suckIT szopás minden nap! Szaros a gatya

Akkor olvass vissza egy kicsit itt a HUP-on.

Szerk.: (azok miatt akik fikáznák a post-ot.) Szóval, a HeartBeat-ről hallottál. Nade az IP-ről DNS-ről miket hallottál? Szerinted azzal kapcsolatban, ha két különféle ISP-nél lesz a PC-d akkor milyen problémák léphetnek fel a terhelés elosztás illetve a HA szemszögéből? Eddig ezzel kapcsolatban mit sikerült kideríteni/összeolvasni ? Mi a konkrét problémád?

( zeller | 2009. 09. 25., p – 21:02 )

Geocluster Linuxon? Ráadásul egy szál interfészen mindent? Nekem az sem igazán tetszik, ha a hb IP-n megy... (Megtörtént eset: a két node-on masszív csomagszűrés, több láb, dedikált fizikai interfész a hb forgalomnak, keresztkábel A conntrack tábla mérete nem lett feltornázva. Elkezdte valami töcskölni a vasat, conntrack tábla full, hb elhasalt, cluster borult, közben távolról se kép, se hang...)

( eax | 2009. 09. 25., p – 21:19 )

Ezt igy leginkabb sehogy.

Amit kiciocco eszkozokkel realisan lehet, az egy DR cucc, tehat mondjuk orankent sync-elsz az aktiv geprol a passzivra, es ha latod, hogy az aktiv megborult (== kuld sms-t a nagios, vagy ilyesmi), es nem is jon meg vissza egy darabig, akkor atiranyitod a dns-t a masikra.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( zeller | 2009. 09. 26., szo – 00:40 )

Hallottál a hb-ről, nagyszerű. Akkor olvass is róla. Sokat. Bár előtte azért a hálózati szolgáltatások működésével kapcsolatban a "hogyan találja meg a kliens a foo.bar.baz gépet a világhálón?" megismerése sem árt... Ha magadnak csinálod a DNS-t, akkor van esélyed sima round robin módon terhelést elosztani, bár ezt azért szolgáltatása válogatja -- egy szimpla ftp-szervernél egyszerűen mehet a dolog, míg egy webszervernél, ahova "fölfelé" is megy adat (amit egy rr dns-ezésnél nagyjából azonnal szinkronizálni kell) azért nem triviális, de megoldható.
Meg kell nézni, milyen és mekkora adatmenyiség szinkronizálására van szükség, mekkora lehet az adatvesztési időablak maximum, ebből lehet tervezni dedikált sávszélességet hozzá...

Sima, egyszerű, egymás mellé/közelébe lerakott HA megoldások tervezéséről van valahol egy rakat doksim (IBM-es anyag, nagyjából 50-70centiméter, mármint az elfoglalt polc hossza ennyi...). Nem véletlenül ilyen terjedelmes, igen-igen sok dolog van, amin nem elcsúszni, hanem pofára esni igen könnyű.

( janoszen v | 2009. 09. 26., szo – 10:50 )

Na nézzük akkor sorban technológiákat. Van két géped, ami feltételezem a DNS kiszolgáló is szeretne lenni. Ez esetben a következő megoldás tud(na) működni:

DNSben fölveszed a megfelelő A rekordot, ami az elsődleges szerverre mutat. A másodlagos folyamatosan nézi, hogy az elsődleges gép megvan-e még. Amennyiben elmúlik, átlöki az A rekordot.

Problémák:

  • Kibakicsit TTL kell, de 10 percnél kissebbet nem minden resolver fogad el.
  • Van egy vagon resolver, aki az RFC ellenében szarik a másodlagos DNS szerveredre, ha az elsődleges nem megy, akkor nem megy a site.
  • Olvasd el a split brain fogalmát a Heartbeat kapcsán.

Konklúzió: az általad megálmodott konstrukció csak nagyon döcögősen tudna működni és valszeg több leállást okoz, mint ha veszel egy normális vasat és behostolod normális helyre.

Javaslat: vegyél inkább normális szolgáltatótól, akiről tudod, hogy van HA megoldása, VPS-t. Esetleg többet.

Jó dolog a HA, csak elég magas a tanulópénz.

Nekem akkorát hasalt a heartbeat Debian Etches stable változatban, hogy öröm volt nézni. Eldobta az összes resourcet. Hál' Istennek az elsődleges gépen maradt minden, de úgy nézett ki, mintha legalább egyszer megpróbálta volna elindítani a másodlagos gépen őket. Szóval óvatosan a heartbeattel, nem annyira stabil szoftver az. Esetleg inkább OpenAIS.

Az a gond, hogy nem natívan kernel-szinten megy a dolog, az IP-t teljesen kihagyva szerintem megbízhatóbb lenne a működés (Nem néztem, de van valami soros kommunikációra is lehetőség, tippelem, hogy ott így működik a dolog)

( skynetpro | 2009. 09. 26., szo – 11:07 )

a HA és a LB elég bonyolultan működik egyszerre...

( turdus | 2009. 10. 09., p – 18:49 )

Szerintem max az jöhet szóba,ha te vagy a DNS admin is. Leveszed a SOA-ban a ttl-t kicsire (hogy gyakran frissüljön), és hegesztesz egy scriptet, ami a 2 gépen fut, és lejelentik magukat a DNS-nek ttl időnként (pl cronból). A DNS szerveren egyszerűen berakod bind-ba, amelyiktől kaptál jelentést. Ez a szinkronizálást nem oldja meg, azt neked kell a nem publikus interfészeken!

1. eset, mindkét gép aktív, mindkettő lejelenti magát a dns-nek, ekkor a zóna:
publicname IN A s1
publicname IN A s2
Ebben az esetben load balancerként működik, round rubin osztja a klienseknek az ip-ket

2. eset, az egyik gép elhasal, ekkor nem jelenti le magát ttl időn belül, ekkor a zóna:
publicname IN A s[12]
Failover üzemmód, a kettő lehetséges ip-ből egyszerre csak egy van hozzárendelve.

3. eset, egyik gép sem jelenti le magát, ekkor érdemes egy "nem műxik" vhost-ra dobni
publicname IN A s3

A megoldás hátránya, hogy maximálisan ttl időnyi kiesést tapasztalhatnak a userek. Ha ennél profibb megoldást akarsz, akkor JÓ MÉLYEN nyúlj a pénztárcádba, vagy felejtsd el az egészet, imho. Ha olyan a helyzet, hogy 3. gépet nem engedhetsz meg, vagy nem te vagy a dns admin, akkor mindenképp felejtő.

Akkor valszin semmit, max átírod a zónát. Egyébként ez azért működik, mert ugye a TTL szerint az A rekordot a szolgáltatók kesselik, majd megint lekérik. A session kezelést pedig pl. MySQL-ben lehet kiválóan megtenni közös vagy replikált DB-vel. Egy kis gondolkodással lehet olyan dblayert írni, ami intelligens módon kezeli a két replikált SQL szervert.

Igen, a MySQL replika az csodákra képes, volt néhány hét amíg mindenféle eldőléseket teszteltem FreeBSD/CARP/MySQL master-master replikációval. Néha jól visszajött a "kidőlt" node, néha nem. Ebben az esetben néhány 10 perces kiesés még elfogadható volt, de az applikációt a node változáskor újra kellett indítani hogy a MySQL kapcsolat helyreálljon. Ez még mindíg sokkal vállalhatóbb, mint egy félnapos vagy egynapos totális leállás hw vagy hálózati hiba miatt. A gyakorlatban olyan 2-3 perc alatt sikerült a teljes node-nak átállnia.

(A master-master replikáció azért kellett, hogy ha átállás van, akkor a visszaálláskor remélhetőleg automatikusan "felvegye a ritmust" a másik sql szerver is.)

"Akkor valszin semmit, max átírod a zónát."

Ja, addig meg az egesz "HA" motyo a sajat taknyaban forog.

"Egyébként ez azért működik, mert ugye a TTL szerint az A rekordot a szolgáltatók kesselik, majd megint lekérik."

Nem ertettel meg. Nem azzal van a gond elsosorban, hogy a juzerek nem erik el a pri dns-t (jobb esetben azert vannak secondaryk is), hanem hogy a szervereknek vagy sikerul bejelentkezniuk, vagy nem, es igy percenkent mas hulyeseg lesz a zonafileban.

"A session kezelést pedig pl. MySQL-ben lehet kiválóan megtenni közös vagy replikált DB-vel."

2 tavoli gep kozott? Az szep lesz. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Távoli gépek között eleve nem nyerő a loadbalance, csak kb. egymás mellettiek esetén. A HA ÉS Loadbalance clustert 2-2 vassal tudom elképzelni, ha földrajzilag is eltérő helyen mennek.

A gépeknek miért kell bejelentkeznie és miért hosztnév alapján? A DNS-t kezelő szervernek bőven elég monitoroznia a node-okat és ha az egyik off (megfelelő timeouttal), akkor módosít a zónán és kész.

Egy HA cluster nem biztos, hogy attól HA mert félperc alatt észrevétlenül átáll. Általában egy 30-60 perces kiesés elfogadható, ahol nem ott úgy soktízmilliót költenek ilyenre, amíg a kézi átírás sikerül. Ez mindenképp egy rövidebb kiesés, mintha bármilyen hw vagy full hálózati kiesés esetén elő kell keríteni a pótalkatrészt vagy 4 órán belül elkezdi a T. hw szállító a javítást. Még azt is megkockáztatom, hogy ilyen egyszerű HA -nál bőven jó a next business day garancia a gépre és nem kell a tűkön ülő hwsupportos miatt kemény pénzeket fizetni.

"Távoli gépek között eleve nem nyerő a loadbalance, csak kb. egymás mellettiek esetén."

Igy van. Lassan csak sikerul felfognod, amit mondani akarok, csak igy tovabb.

"A gépeknek miért kell bejelentkeznie és miért hosztnév alapján?"

Dunno, igy talalta ki a kollega kicsivel feljebb (azt nem tudom, honnan vetted, hogy "hosztnév alapján").

"A DNS-t kezelő szervernek bőven elég monitoroznia a node-okat és ha az egyik off (megfelelő timeouttal), akkor módosít a zónán és kész."

Tok mindegy, hogy melyik oldal nezegeti a masikat, a lenyeg az, hogy egy igen egyszeru es nem is tul ritka halozati anomalia oskaoszba dontheti az egeszet.

"Általában egy 30-60 perces kiesés elfogadható, ahol nem ott úgy soktízmilliót költenek ilyenre (...)"

Nem mondod. Komolyan?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

"amennyiben az alkalmazás is támogatja ezt"

Ez az, amiről eddig semmit nem árult el a kérdező, pedig itt van az eb elhantolva elsődlegesen -- hálózati forgalom ide/oda tologatására van nem egyz megoldás, a kiválasztást viszont igencsak befolyásolja, hogy milyen szolgáltatás lesz az elképzelt aktív/aktív fürtre rápakolva.

( tovis v | 2009. 10. 11., v – 13:29 )

Van még egy-két fehér folt.
A két IP cím külön-külön hozzáféréssel rendelkezik? - ha nem akkor a sávszélesség máris bekorlátoz.
Amennyiben nincs egy harmadik gép, akkor ki dönti el, hogy az adott kiszolgálás kérést ki kapja meg?
A pusztán IP címen alapuló "heartbeat" nem mindig célravezető, van úgy, hogy csak egyes szolgáltatások "rohadnak" le de az IP cím és illetve a TCP/IP réteg még él és virul, azaz egy olyan kis mütyüri applikáció mint a "hearbeat" röhögve fut.
Ha kiejtem a terhelés megosztás című igényt, azt mondom ez egy 100% -os meleg tartalékolás, a tartalékos gép, figyeli hogy a fő gép megy-e, és ha nem akkor lép a helyébe. A megfigyelést pedig szolgáltatás meglétével figyelném, nem pedig IP pingeléssel, vagy "heartbeat" -el.

* Én egy indián vagyok. Minden indián hazudik.

Load balance, azaz aktív/aktív felállás kellene, amit harmadik eszköz nélkül normálisan max. round-robin DNS-sel tudna megoldani.
A HB-nek meg kell mondani, hogy mikor borítson, és boruláskor mit csináljon, de ezt első körben a figyelendő alkalmazásokkal, hálózati környezettel, kommunikáció módjával együtt papír-ceruza alapon alaposan meg kell tervezni, és ésszel implementálni, valamint tesztelni.

( Fisher v | 2009. 10. 11., v – 14:14 )

Eszembe jutott valami, amivel nem lebeszélni akarlak a dologról, csak nem árt figyelembe venni. Egyszerre szeretnél HA-t és LB-t, amit kicsit nehézkes megcsinálni. Viszont ha tényleg kell a LB akkor egy gép teljesítménye kicsi, kell a kettő. Ha egy gépé nem kicsi, akkor meg nem kell LB. Csak a HA-t megcsinálni sokkal könnyebb mint a kettőt együtt. Ilyenkor persze a standby gép kihasználatlan.

Megjegyzés a sokkal könnyebbhez: nem az a lényeg, hogy könnyű megcsinálni, hanem az, hogy könnyű - érts egyszerű, biztonságos - üzemeltetni. És én lehet, hogy kihagynám az egészből Heartbeat cluster-t. Ugyanis az automatizmus egy ilyen környezetben esetleg többet árthat mint használhat. Külső figyeléssel, sms-es riasztással pár másodpercen belül értesülhetsz, ha valami nyomor van, és akkor kézzel átállhatsz. Saccra a HB át tud állni mondjuk fél percen belül (sokkal rövidebbre nem érdemes venni a timeout-ot mint 10sec), te, kézzel mondjuk 10 perc alatt. A HB bármikor tévedhet, pláne ha rosszul van konfigva (ez utóbbi csak akkor derül ki, amikor tényleg hiba van :)), te kevésbé.

De ezek csak gondolatok :)

"Csak a HA-t megcsinálni sokkal könnyebb mint a kettőt együtt. Ilyenkor persze a standby gép kihasználatlan."
Még egy gondolat, ha HA -t csinálsz akkor is érdemes mondjuk 24 óránként átváltani az egyik gépről a másikra, így biztos lehetsz benne hogy a tartalékod is működőképes.
Az LB megvalósításában az a gond, hogy annak eldöntése, hogy az adott kiszolgálási kérelmet ki szolgálja ki, sokszor nem kisebb feladat mint kiszolgálni a kérést. Azaz amit nyersz a vámon, elveszted a réven. Korrektül szerintem csak egy a megosztást vezérlő gép segítségével lehet ezt megoldani, és akkor annak is HA kell lennie. Kicsit olyan mint a RAID 10 két-két strippelt egy tükörbe, hogy megkapd egy sima disk sebességét.
Talán, még azt lehetne, ha mindegyik gépen két virtuális gépet futtatsz, az egyik a kiszolgáló a másik a felügyelő és forrásmegosztó, de ehhez olyan erős gép kell, hogy nem éri meg.

* Én egy indián vagyok. Minden indián hazudik.

Imádom az automatizmusok helyett az "sms és majd te megoldod a borítást" hozzáállást... Ez ugyanis feltételez 7x24-ben elérhető, és azonnali beavatkozásra képes admin meglétét -- 4-6 fővel neki lehet állni, de a reakcióidőt még így sem lehet 30-60 percnél(!) rövidebbre számolni. Ha belefér a legalább 30-60 perces kiesés, akkor fölösleges a HB, elég egy melegtartalék, amire kézimunkázva átálltok, ha szükséges. Ha ennél rövidebb kiesés van csak megengedve, akkor automatizmus kell, vagy 7x24 órás on-line ügyelet.

Vannak szituációk, ahol ez pont elegendő. Ha valaki Budapesten lakik, akkor az egy óra vállalható. Feltételezve, hogy normális vasat vesz, normális helyre hostolja be és normálisan fölkonfigurálja, kevés olyan eseménye lesz, amire reagálni kell. A HA egyébként sem megoldás mindenre. (Sőt, inkább meglepően kevés dologra megoldás.) Én üzemszerűen vagyok ügyeletben egy elég méretes géphalmazra és amióta megcsináltuk a triviális dolgokat (monit indíccsamáújra az apacsot ha lerohad a terheléstől) azóta pár havonta van egy event (és azért a monitnak sincs túl sok dolga).

Én is masszírozok pár tucat vasat, eléggé kritikus a szolgáltatás, épp ezért jórészt aktív/passzív fürt dolgozik. HA borulás van, akkor jön a riasztás, és neki kell állni az probléma behatárolásának/elhárításának, annak ellenére, hogy a szolgáltatás maga megy tovább.

HA mint HA megy tovább. Ha nem volt még olyan borulásod, hogy mindent vitt magával, akkor szerencsés vagy. Splitbrain, szoftverhiba, adatinkonzisztencia csak a kezdet. A rendszerszintű HA állatorvosi ló Linux alatt, mit meg lehet alkalmazásból csinálni azt meg is kell alkalmazásból csinálni.

Hogy csak egy példát mondjak, SCSI-3 PR és multipath.

Persze, jo dolog az automatizmus, de ha az illeto valami elront (ami ha a huprol gyujti a tudast, nem tunik lehetetlennek), akkor rossz esetben nem az lesz a kerdes, hogy 60 perc, vagy 60 mp a kieses, hanem hogy 2 het alatt ossze tudja-e legozni az adatokat.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

A tervezésbe bele kell érteni a részletes tesztelési terv elkészítését is, amit az implementáció során szigorúan végre is kell hajtani. Ezért is volt kérdés, hogy milyen alkalmazások, szolgáltatások kerülnek erre a tervezett fürtre, mert tényleg nem mindegy, hogy miről van szó.

"A tervezésbe bele kell érteni a részletes tesztelési terv elkészítését is, amit az implementáció során szigorúan végre is kell hajtani."

Ahogy mondani szoktam, a hibak ravaszak, es direkt ki akarnak szurni az emberrel. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Ha a háttértár lehet shared, akkor szerintem megoldás lehet egy heartbeat jellegű hardware is, azaz ami "A" gép
nem működése esetén lekapcsolja "A" gépet a hálózatról és/vagy áramról, és beindítja helyette "B" gépet.

Persze a fenti megoldható HP (ill egyéb iLO v hasonlót használó) szerver és Nagios event handler alkalmazásával.

Így van. 30 perc kell minimum az átálláshoz, ha készületlenül ér - azaz ahogy általában. Ha csak ennél rövidebb kiesés van megengedve, akkor azt nem bíznám - már elnézést - házilag barkácsolt megoldásra. Ahogy eax írta: "Ahogy mondani szoktam, a hibak ravaszak, es direkt ki akarnak szurni az emberrel. :)"

Az automatizmus... cluster esetén kerülendő az SPF, mert ha ilyen van benne, akkor nem cluster a cluster (ezért se nagyon szeretem a shared tárolókat, mert vagy nagyon drágák, vagy nem valók clusterbe). És épp ilyen SPF az egy darab rendszergazdi, aki összerakja a működő clustert, megírja a scripteket, hogy a szolgáltatások minden lehetséges hiba esetén biztonságosan viselkedjenek. Vagy többen csinálják ugyanezt, naprakész dokumentációval... ez se olcsó.

Egyébként nekem van két "egyforma" clusterem. Az egyik többszolgáltatós, két külön kerületben, az kézzel átállós (pl. egy ilyen matávos hiba esetén ami most volt, véletlenül se szabad magától csinálnia bármit is), a másik "mobil", két kicsi gépből áll, le lehet dobni az ellenséges vonalak mögé és megy. Ott mindent én tartok kézben (belső hálózat, dns, switchek, miegyéb), össze vannak kötve pl. soros kábellel is, ez tök automatán átáll, ha úgy gondolja. Persze ez utóbbi ráadásul olyan, hogy lehet, hogy nem tudok hozzáférni 7x24-ben. A két clusteren ugyanaz az alkalmazás fut, ezért "egyformák".

Ja igen, amit ebből ki akartam hozni. A "kicsi" cluster ledokumentálása jóval több munka, mint a "nagyé", mert az alap DRBD mellé kellett venni a HA és az automata scriptek ismertetését is.

No mindegy, nem akarok senkit se megtéríteni, mindenkinek magának kell eldönteni, hogy melyik az inkább megfelelő megoldás - vagy inkább melyik a kevésbé rossz :D

A 30perc az a jó eset, ha viszont a távoli elérés valami miatt nem működik, akkor szinte esélytelen ennyi idő alatt bármit kezdeni. (max. az operátort (ha van) fel lehet hívni, hogy nyomjon ctrl-alt-delt mindkét gépen (aztán scriptből lekezelni, hogy épp az adott gépen mit kell csinálni...)

Én a dokumentációba azt írtam, hogy ilyen esetben mérlegelni kell, hogy tegyen-e bármit is az aktuális rendszergazda:

- egyáltalán, elérhető lesz-e a szolgáltatás (áll az egész net, a szolgáltatás fut, csak épp senki nem éri el)
- biztonságosan át lehet-e állni annyi idő alatt, amennyi idő alatt várhatóan megszűnik a probléma
- ha a cluster átáll, akkor jobb lesz-e

Pl. ha leáll a bix (konktétan az a core router amiben a peering megy), akkor én semmit se csinálok, mert miért is? Ha az IW routere döglik el, akkor se, mert várhatóan hamarabb hozzák rendbe, mint ahogy én átállnék. Ha mégis nagyon lepusztul, akkor esetleg átállok.
Volt, hogy az ország bgp dampling miatt szívott, akkor se lett volna értelme semmit se csinálnom. Szóval egy csomó olyan hiba van, amikor jobb ha én nem teszek semmit. Hacsak azt nem, hogy ha azt látom, hogy a DRB uptodate/uptodate és nem dirty senki (meg meg kéne nézni még hogy mik :)), akkor inkább leállok mindkét lábbal, hogy ne legyen baj később se :D

( Kayapo | 2009. 10. 11., v – 19:23 )

Had legyen itt az én story-m is:
Két gép (hála az égnek) egymás melletti RACK-ekben, 2-2 LAN kártya, az egyiken keresztül direkt összekötve a két gép.
Az adatterületet DRBD "C" protokollal szinkronban tartja Pacemaker-OpenAIS toszogatja a HA-t.

A fentebbi problémát hasonlóan oldanám meg, tehát:
- Egy-egy IP a két node fizikai eléréséhez
- Egy harmadik a szolgáltatás üzemeltetéséhez
- Egy-egy IP (a közvetlen kábellel összekötött) második NIC-ekhez
- OpenAIS a Pacemaker indításához és a kommunikációs réteg megvalósításához
- Pacemaker a HA vezérléséhez
- A drbd kommunikáljon a mésodik NIC-en keresztül, de
- Egy okos scriptecske segítségével probléma esetén váltson konfigot és használja az első NIC-et, de
- Ha ez sem működik => Split Brain
- A pacemaker indítsa a szolgáltatást.

Indítás:
1. Húza fel primary módba a drbd kötetet
2. Ellenőrizze, van-e file rendszer a disken
3. Mountolja fel a drbd disket
4. Húzza fel a publikus IP-t
5. Indítsa el a szolgáltatást

Leállítás:
1. Állítsa le a szolgáltatást
2. publikus IP-t le
3. umount
4. drbd disk secondary

Aztán persze felmerülhet egy csomó kérdés, meg ötlet...

----
概略情報

Amennyire én tudom, Kayapo elég sokat szívott, amíg pont ezt a kombót sikerült összeraknia működőre és nem azért, mert nem értett hozzá. (Ezt az egyet tényleg nem lehet elmondani róla.) Az a baj ezekkel a szuperszoftverekkel, hogy a szervezetlen opensource sajátosságait halmozottan hordozzák magukban, azaz kicsit bugos, kicsit néha regression van, kicsit néha az új release összeszarja magát, amíg meg nem patchelik...

Hát ha a xen-es mókáról van szó az cirka 2hónap kőkemény hanyattszopásba került!!!
Ez egy kicsit egyszerűb, a teljes ismeretlenség állapotából indulva szvsz olyan 3-4hét alatt precízre összecsiszolva előállítható

----
概略情報

( nikin v | 2009. 10. 11., v – 21:39 )

Tartok tőle, hogy ez a téma azért van annyit a felszínen, mert az embereknek minden,mindíg,és most azonnal kell. Szerintem elég kevés olyan dolog van aminél egy 1-2 órás kiesés akkora anyagi kárt okoz, mint amennyibe kerül egy rendes HA rendszer kiépítése.
Főleg ha megbízható vas van alatta. Mert ugye akkor olyan dolgok is szóba jönnek már, hogy különböző OS eket kéne használni, meg alkalmazásokat.
A vége meg az lesz, mint pár napja, hogy a T csoport úgy en block megadta magát egy órácskára. (T-home, T-mobile) 18. ker. Az ügyfél oldalán.
Most evvel kezdj valamit.
Valami hozzáértő emberkének egyszer írnia kéne arról, hogy mik a reális elvárások (üzletileg) adott szegmensekben. Zöld szerver? hö? Amikor mindenből 3db -t futtatnak, hogy azonnal belépjen a kieső gép helyére? vicc! Minden Realtime motanság. De elég sokminden minek?

A vicc, hogy erre még adott határokon belül szánnak is pénzt. Persze a könyvelést futtató gépbe egy Raid1 már túl drága. Backup dettó.

Legyek én a hülye... kössetek fel.

### ()__))____________)~~~ ###
#"Ha én veletek, ki ellenetek?"
#ASUS eee 900 //Puppy 4.3b3

Jó ötlet Amúgy kiterjeszthető lessz több gépre is?
Erőforrásigény? Főleg hálózat tekintetében.
Én mostanság Green computingon agyalok sokat. Konkrétabban azon, hogy webprogramozási szempontból miként lehet a legtöbb lapot kiszolgálni a legkevesebb Wattból.

### ()__))____________)~~~ ###
#"Ha én veletek, ki ellenetek?"
#ASUS eee 900 //Puppy 4.3b3

nem alakul ki igazi split-brain, mert az egesz rendszer redundans (a ket gepen a szoftver teljesen ugyanazt latja; ha azt hiszik a masikrol meghal, semmi gond, majd mikor online lesz, akkor replikalodnak).

a szoftver teljesen bovitheto, linearisan skalazodik akarhany gepen, meg ilyenek. es mindezt kenyelmes, kontener formaban kapod a segged ala java alatt majd, ha egyszer befejeztem a diplomamunkat. :)

amugy kesobb nem ket gep lesz, hanem feladat szerint lehet groupolni a dolgokat, groupon belul replikacio, etc.