Cluster ötletelés

Linux-kezdő

Sziasztok,

elkezdtem építeni egy egyszerű kis rendszert mely jelenleg 6 gépből áll, redundáns webkiszolgálót szeretnék építeni(persze csak játszósba, hobbi célból):
2 load balancer
2 app server(itt jelenleg csak apache2 fut, jön majd nginx, MySQL és levelezés)
2 storage

Az első 4 gép szépen dolgozik együtt, ha kiesik valamelyik akkor sincs gond.

Most azt szeretném megoldani, hogy a 2 storage szinkronban legyen és az igy kapott tárhelyet szeretném felmountolni az app servereken, tehát az app serveren fut a mysql és az apache de a storage-n tárolom a hozzájuk tartozó adatokat.

Elsőre glusterfs-el akartam megoldani a dolgot de most rátaláltam a DRBD-re. Ahogy olvasom mind a kettővel megoldható a dolog.

Kérdésem az lenne, hogy szerintetek melyikkel járok jobban? Ilyen téren semmi tapasztalatom nincs, és így este 11-kor inkább megkérdelek Titeket mielőtt eltöltök ezzel még 3-4 órát :).

Köszönöm a segítséget.

( Dacr (nem ellenőrzött) | 2012. 06. 04., h – 23:00 )

Ha már játszós, tanulós project, miért nem próbálod ki mindkettőt? :)
De most tényleg, csak nyerhetsz vele.

( dbali | 2012. 06. 04., h – 23:23 )

glusterfs nem kajál annyi erőforrást, mint a drbd, és tapasztalatom szerint könnyebben is veszi az egyik node leállását. :) mivel annyira itt nem lesz fontos a teljesítmény, a drbd is tökéletes a feladatra, annál az egyetlen bökkenő, hogy blokk-eszközökkel dolgozik.. De ugye egy ilyen clusternél nem csak a hardware failower-re kell koncentrálni, hanem megeshet, hogy bebuggol a primary node, de mivel az ip még mindig él, és látszólag fut is, nem vált át a másikra magától. :)
Sok mindennel el lehet játszani azért ezen a téren :)
Bár ha már így akarsz clusterezni, az sql-t is szétszedném, abban még jobb móka a failover :)

Köszi, első lesz a glusterfs aztán kipróbálom a DRBD-t és a végén még az OCFS-t :).

Az SQL szétszedésről tudsz nekem pár kulcsszót adni amin eltudok indulni? Eddig mysql replikáció, mysql proxy(erről mikor utoljára hallottam akkor még nem volt kimondottan stabil) amit találtam vagy heartbeat + DRBD kombo.

Mi használunk drbd + ocfs2 t. Jó poén, és megy is. Hátrányai:
1: ha szétszakad a háló (config, vagy valami driver hiba), és split brain lesz, macerás helyrehozni.
2: nincs gond ha csak az egyik gép áll le, de ha mindkettő, utána az ocfs2 fsck ja hosszú hosszú percekig képes tekerni, és nem valami verbose. ilyenkor az emberben felmerül:
3: hogy recoveryzném az ocfs2t, ha nem mountolná föl? sehogy, gondolom maradna a backup. De az távol van, sok idő lehet visszamásolni.
4: elég mimóza az egész rendszer. dlm et mountolni kell fstabban, számít a kernel verzió (ocfs2), számít a drbd kliens, meg kernel verzió, minden. Van, hogy nem megy, ha túl nagy a verzió különbség. Szóval elég érzékeny az egész.

Tervezem a glusterfs re átállást, de én azt még nem ismerem ennyire se. De most itt feljebb is jókat olvasok róla. Ott nem lenne kernel szintű probléma, csak userspace. Az már egyszerűsíti a dolgot.

A mysql drbd/heartbeat re minden tutorial azt írja, hogy drbd n nem clusteres fs, egyik gépen mountolva, majd a gép pusztulásánál a másik mountolja a drbdt, és indítja a mysqlt. Gondolj bele:
1.: Szabálytalanul umountolt filerendszert fog mountolni, ami jó esetben auto fsck (journal replay stb), rossz esetben elhal, kézi fsck kell... fs függően. Persze itt is lehet még clusteres filerendszer, akkor ez nem probléma
2.: szabálytalanul leállított mysql (mert ugye lefagyott), tehát minden táblát repairezni kell, nehogy valami inkonzisztencia legyen. Persze adatvesztés is előfordulhat, gondolom tranzakciók, vagy ilyesmi...

A mysql clustert felejtsd el, nem igazán az, ami neked kell failoverhez. Van ahol biztos hogy jó, de ahhoz olyan alkalmazást kell fejleszteni, ami direkt kihasználja az előnyeit. (és számol a hátrányaival)

Marad a mysql replikálás, ha failover, akkor egyszerűen master-master replikálás, és egyszerre csak egyiket használod. Gond itt akkor van, ha az egyik gép lehal, de visszajön, a replikálás megszakad (valamilyen duplicate key miatt), és a heartbeat visszaadja az ipt a nem naprakész mysqlnek :D Szóval nem egyszerű, ezekre gondolni kell előre. Persze akármilyen tesztet csinálsz, az éles problémák mindig pont nem olyanok. :)

Köszi a választ, elég izgalmas lehet ha valami elromlik egy ilyen rendszerben :).

Tesztelésre én annyit gondoltam, hogy felrakok mondjuk 2-3 wordpress oldalt(mindenféle cache nélkül) ha elkészül az egész rendszer és megküldöm siege-el, közben persze kapcsolgatom le-fel valamelyik load balancer-t, app server-t vagy storage-t utána meg megnézem, hogy mi maradt a rendszerből :).

Tudtok tesztelésre esetleg valami kiforrottabb megoldást?

Mysql-hez:
http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-overview.html
- adatbázis nem MyISAM vagy InnoDB lesz, hanem NDB storage engine-t használ.
"All these programs work together to form a MySQL Cluster (see Section 17.4, “MySQL Cluster Programs”. When data is stored by the NDB storage engine, the tables (and table data) are stored in the data nodes. Such tables are directly accessible from all other MySQL servers (SQL nodes) in the cluster. Thus, in a payroll application storing data in a cluster, if one application updates the salary of an employee, all other MySQL servers that query this data can see this change immediately."
- ennek persze vannak limitációi, de ha megfelel akkor jó megoldást nyújthat az adatbázis szinkronizációra

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( szabek | 2012. 06. 05., k – 09:23 )

Egy összefoglalót nem akarsz írni róla? Biztos vagyok sokan örülnének neki... Én biztosan :)

Szívesen írok róla, mikor RAID5 + RAID1-t pakoltam össze 3 diszkre akkor is gondoltam rá, hogy felrakom valahova, hátha jól jön valakinek, de mivel csak hobbi rendszergazda vagyok ezért úgy gondoltam, hogy nem biztos, hogy nekem kellene ilyen témáról írnom, mivel én csak nagy körvonalakban tudom leírni, hogy miért is működik a rendszer úgy ahogy :). Ha megfelel így is akkor viszont szivesen megosztom a tapasztalataimat.

( Dudu94 | 2012. 06. 05., k – 10:08 )

+1

az összefoglaló engem is érdekel : )

( tompos v | 2012. 06. 05., k – 10:16 )

DRBD:
- ket node-ot tudsz osszekotni block device szinten, tobbet nem
- ha primary/secondary felallasban hasznalod, barmilyen FS-t rakhatsz ra, aamivel stabilan megy is, relativ gyorsan

Glusterfs:
- ahogy a neveben szerepel, egy masik layer-en dolgozik annak osszes hatranyaval es elonyevel egyutt
- nem teljesen posix komppatibilis, legalabbis a lock-olas
- vannak vele gondok, nem mindig mukodik popecul, plane ha replikaciot is hasznalsz, sokat fejlodott az utobbi idoben, de van is meg hova, nezd meg a levlistajukat
- tamogatottsaga egyre inkabb tolodik a redhat iranyaba, plane miota megvette a redhat
- sql-t en nem raknek ra

OCFS: tudtommal ez onmagaban nem elosztott fs, csak pl. rarakhatod egy dual-primary DRBD setup-ra, de cafoljatok meg

tompos

Sajnálattal olvasom amit a glusterfs ről írsz, bízok benne, nem olyan rossz a helyzet. Ami nekünk ténylegesen egyidőben kell, és esetleg lock számíthat, az a session fileok, a többinél elfogadható, ha a konkurencia nincs kezelve, úgyhogy nem félek. (sql marad a replikált, sima helyi fs ekkel)

Az ocfs2 t egyszerre mountolod a két primary drbd n, és egyszerre írhatod olvashatod. Mi így használjuk. Különben mi értelme lenne dual primary re rakni? Dual primaryre rakhatsz reiserfst is, csak ne mountold egyszerre két helyen. :)

OCFS:
En ez alapjan ugy ertelmeztem, hogy a replikaciot akarja megoldani vele:
http://hup.hu/node/115142?comments_per_page=9999#comment-1466339

Glusterfs:
Kicsit talan lehuzos, amit irtam, de annyira azert nem rossz a helyzet. Megvan a maga felhasznalasi terulete, es sokan hasznaljak produktiv kornyezetben, mindenfele modon.
VM-ek ala pl. meg nem ajanljak, de az RH egyertelmu celja az, hogy VM image-ek ala biztositsanak egy jol skalazodo, megbizhato elosztott fs-t.

A lock-olasnal ne azt ertsd, hogy nem kezelte le rendesen a lock-ot, hanem hogy egyaltalan:)
Samba-n bizonyos programok nem tudtak megnyitni file-okat: Photoshop, MS Office (vagy OOo, mar nem emlekszem), Adobe Premiere meg ilyesmi eszkozok.
Ezek csak vmi nagyon legyatrsitott samba configgal mentek. Minden mas viszont rendben.
Lock file-oknal neked ezek nem fognak gondot okozni.

En distributed mode-ban hasznalom, viszonylag jol mukodik, de neha elojonnek hibak. Azt remelem, most mar azok is eltunnek. Egy biztos, replikaciot en meg nem biznek ra, fel-egy ev mulva talan. Egy levlistas level szerint VM image-ek megfelelo tamogatottsagara a 3.4-es sorozatban lehet szamitani (a 3.3-ast most adtak ki, kb. ezt a celt elokeszitendo).

tompos

ui.: Ha jo elosztott FS-t keresel es megfeleloen nagy cluster-t epitesz, akkor a MooseFS-t ajanlom.

( janoszen v | 2012. 06. 05., k – 10:49 )

Tesztelt le a felepitett rendszeredet majd packet lossos korulmenyek kozott is. Tippem szerint az eloszor osszerakott rendszer ugy fog osszedolni mint a kartyavar, szoval gyakorolhatod a recovery scenariot is.

( hccoder | 2012. 06. 05., k – 13:31 )

Véleményre lenne szükségem, kicsit gondolkodtam, hogy a MySQL-t hogy replikáljam. Általam kigondolt megoldás:

- A 2 app serveren fut MySQL server ami a storage-re dolgozik.
- A 2 MySQL multi-master replikációval van beállítva.
- A 2 load balanceren felveszek egy uj virtuális IP-t a MySQL-nek.
- A load balanceren Galera/garbd elvileg megoldja, hogy ne legyen "split brain" problémám.
- Az app serveren a MySQL kapcsolatoknak az új virtuális IP-t adom meg, haproxy meg eldönti, hogy melyik app serveren lévő MySQL-hez kapcsolódik.

Ha ezek megvannak elkezdek sorokat szurni az adatbázisba és kapcsolgatom le-fel a servereket és meglátom mi lesz az eredmény.

Szerintetek ez így életképes lehet?

Köszi

storage-re dolgozni felesleges, elvégre mindkét szerver külön-külön adatbázis file-okba dolgozik, mindkettőt hálózaton szinkronizálni nagy felelőtlenség, mert ha a storage kiesik, nagyon csúnya dolgokat művelhet :)
a 2 db két külön szerveren, akár mmm-el akás master-slave-el, és script-el kezet master-cserével, de itt lehetnek nagyobb gondok, így inkább mmm :)
haproxy+ldirectord tökéletes, be tudod lőni emlékeim szerint, hogy csak host kiesés esetén váltson a másik sql-re, így nem kavarodhat semmi ha épp sokat írsz rájuk :)

A storage 2 storage-t jelent nálam - az app serverek egynek látják. Azt szeretném elérni, hogy az app servereken ne legyen semmi az appokon kívűl, minden adat a storage-eken legyen, ha kiesik az egyik storage, akkor még megy a rendszerem, lehet, hogy rossz az elképzelésem, de gondoltam ha így szét van szeparálva minden az nem lehet rossz :).

az úgy oké, csak úgy értettem, hogy csak az adatbázis file-okat akarod a közös storage-en tárolni, annak nem láttam értelmét :) Ha a két külön storage-en van két külön db, ami nem a failover-ben lévő mappákba dolgozik, az úgy oké (bár alapesetben a storage is csak storage, hogy szép legyen :) )

Na kezdek belezavarodni :).

Tehát van 2 storage ami egynek látszik az app servereken. Legyen /data/ mappába mountolva mondjuk, itt lenne egy /data/db1/ és /data/db2/ mappa, az első app server1 mysql a másik pedig a másik app server mysql. Itt megy a replikáció oda-vissza. Így mindkét storage-n rajta van mindkét db, ha lehal az egyik storage-m akkor elvileg semmi gond nincsen, az app serverek dolgoznak az Ő mappájukban, azt Ők nem tudják, hogy épp melyik storage-rol kapják az adatot.

Ha ez így hülyeség akkor bocsi, hogy fárasztalak :)

a clapf-nal pl. meg lehet azt oldani, hogy ha tobb gepen dolgozod fel a szemetet, akkor van 2 (vagy meg tobb, ha kell) geped, amin a mysql replikak (slave-ek) futnak, es a clapf azokat read-only modban kerdezgeti le, mig pl. a tanitas (=iras) mehet a 3. gepre, amirol majd a replikacio szetteriti a modositasokat a clapf-ot futtato gepekre.

Ha lenne ilyen igeny, akkor akar azt is bele lehetne kalapalni a clapf kodba, hogy (ahogy zeller irta) 2 db sql handler-t nyit, es ami iras, azt a mysql master fele kuldi. Mivel a clapf mellett (ugyanazon a gepen) futo mysql "read-only", ezert brutalis optimalizaciot lehet rajta vegezni, igy nagyon gyors tud lenni az sql lekerdezes es igy a spamszures is azon a gepen.

Szoval az egeszbol azt akartam kihozni, hogy letezhet olyan felhasznalas, ahol jol tud egy ilyen felallas szolni.

Miert kell nekem sajnalnom a Klubradiot?

Hát nekem elég nehézkes a dolog, de ez a hiányos tudásom miatt van, pedig ma elég sokat olvastam utána ezeknek a dolgoknak :).

"hagyod a francba ezt az master-master DB-s megoldást és failover-re támaszkodsz?"
Itt mire gondolsz pontosan? Bocsi de este 10:30 van, elég lassan forog az agyam már :)

Csinálhatsz master/slave megoldást ahol valahogy replikálódnak a változások (oracle-nél DataGuard-nak hívják a megoldást, csak ott primary/standby és nem master/slave, de az elve az, hogy a keletkező archive logok átkerülnek a standby DB node-jára, ahol a nem megnyitott DB (nem open hanem mountolt) magára görgeti /van Active Dataguard is már de nem akarom nagyon bonyolítani léven nem oracle irányba indultál/),ennél külön storage-a van a 2 DB-nek, ahogy eredetileg akartad.
De csinálhatsz olyat, hogy lesz egy közös storageod amin a DB fileok vannak, azt kapcsolgatod a node-k közt mint egy szolgáltatást, és host based mirroringal oldod meg a storage kiesést (de megoldhatod storage mirroringal is, nem ismerem a storageod, így lehet ilyen funkciója nincs is, de én ezt nagyobb szopásnak érzem, föleg a céges tapasztalatokból, a gatekeeperre nincs ACL beállítva az adott node-ra, nem engedi megfordítani a szinkront stb./persze ez lehet csak nálunk ennyire macerás/ ).
Van aktiv-aktiv megoldás ami tényleg jól működik, de eddig tudtommal csak az oracle-nek van rá megoldása (RAC), ahol nem kell az alkalmazást ilyenre felkészíteni. De ebben nem vagyok biztos, mert nem minden gyártó megoldását ismerem.

Multimaster esetén lehet kettőnél több master géped is, legfeljebb körbereplikálnak és ezzel növelik a hibalehetőséget, mert ha egy kiesik, akkor megáll az egész, mint a token-ringnél. Célszerű megoldás, hogy a HA miatt 2 mastered van, amikből ténylegesen csak egyet használsz írásra (hiba esetén azonnal válthatsz a másikra; egyszerűbb az online schema change) és ezek mőgé tetszőleges számú slavet raksz és tök egyszerűen bővítheted is őket horizontálisan. Replikácinál monitorozni kell az io es slave threadet és hiba esetén csak kiveszed a kiszolgálásból az adott gépet, odamásolod a masterről az adatot és megy tovább az élet. Arra, hogy hogy dobod szét az írás és olvasás forgalmat a gépek között pedig halom megoldás van.

Ez így igaz... Master-slave esetén jóval egyszerűbben és hatékonyabban lehet konfigolni (persze ha az alkalmazás is támogatja). Alapelv: írás és "real-time" adatok olvasása Masteren történik, további olvasás slav(ek)en, így bővíthető a rendszer, szűk keresztmetszet irás/real-time olvasás a masteren. Ha az alkalmazás nem támogatja akkor jöhet master-master, de ez kényes téma (lsd fenn)
upd: multi master nem támogatott hivatalosan, de működik (orosz rulett)

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

Konkrétan mentésre használtunk régebben slave-et és adatbányászatra (120GB db, myisam táblák), amely idejére a replikációt leállítottuk. Azért használtuk ezt a megoldást, hogy myisam esetén konzisztens dump készüljön és hogy az éles db terhelését csökkentsük. A slave csúszásban van a master-hez képest, de pl statisztikai cronok futtatása, mentés esetén jól használható.

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

Na most szogezuk le a master arra van ,hogy irjak nem arra ,hogy folyamatosan olvassak.

"Alapelv: írás és "real-time" adatok olvasása Masteren történik" -> ez nemtom honnan jott... az mar regen rossz ha egy clusterbe elkesnek a slavek ott valami hiba van.

Az mondjuk myisam meg 120GB az mondjuk GG... a masik nagy hiba ha ezt mysqldumppal csinalja valaki...Akkor mar inkabb ez

"upd: multi master nem támogatott hivatalosan, de működik (orosz rulett)" -> failed percona mmm

--
1 leszel vagy 0 élő vagy hulla!

Pedig bizony akad késedelem, bár nem órák/percek

Ez egy örökölt db, myisam volt alatta akkor, ami tábla szinten lockol mentés közben, ami egy 30G+ tábla esetén eléggé nagy idő, ebből volt nekünk 3 db is, és non-stop ügyfélszolgálatunk. kb 5 óra volt a mentés.

Upd: És mit teszel splitbrain esetén ha kiesnek a szinkronból, és össze kell rakni a db-t? Inkább alszom nyugodtan mint n darab master-master mysql-t üzemeltessek. Lehet kakiból várat építeni, de büdös lesz benn, és ha jön az eső...

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

Én úgy emlékszem, hogy a mysql replikáció aszinkron. Illetve atomi műveletek esetén a másik szerveren (ahová a replikáció megy) nincs (tábla) lock. Ha pl. időegységen belül elegendő számú insert megy mindkét szerverre akkor nagyon könnyen állhat elő adat duplikáció ami a replikáció leállásást vonja maga után. A leállt replikáció miatt előáll a két különböző adatbázis.

--
maszili

Ebben az esetben is nagyon könnyen előállhat split-brain. Ha pl. olyan tranzakció adódik amit hiba miatt nem tud végrahajtani az elsődleges szerver akkor szintén megáll a replikáció miközben az elsődleges szerver megy tovább. Nagyon egyszerűen kipróbálhatod pl. egy DROP TABLE nincs_ilyen_tabla; esetén megáll a replikáció és kézzel kell beavatkozni. Ha a replikáció leállása után áll meg az elsődleges szerver akkor hiányozni fognak adatok a másik szerverről a replikáció hiánya miatt. Az adathiány mennyisége egyenesen arányos a hiba után eltelt idő alatt keletkezett datmennyiséggel.

--
maszili

"hot swap" kent szolgal. Viszont ugyan ugy megkapja az adatokat mint a master1.

Én egy példát írtam arra az esetre amikor ez nem így van.
Reggel egy hibás tranzakció miatt megáll a replikáció aztán egy délutáni hiba miatt átállsz a hotswap-ra. És akkor a reggeli adatokat találod az adatbázisban.

--
maszili

Mo-ni-to-ro-zás. Lassan írtam, hogy értsd :-D Ha a replikációs thread elhasal, akkor bele kell nyúlni, és rendet kell csinálni. Mivel tudod, hogy miben halt el, mit nem tudott a slave végrehajtani, el lehet dönteni, hogy a slave mehet tovább minden probléma nélkül, avagy kuka, és újra kell rakni az egészet.

Értem. És 0-24 ott ül egy ember egy gép előtt, hogy amikor megáll a replikáció akkor _azonnal_ rúg rajta egyet, hogy _késlekedés_nélkül_ folytatódjon a replikáció ha esetleg pont akkor állna meg az elsődleges szerver... mert ha nem így van akkor 10 perc alatt is keletkezhet annyi adat, hogy ha átáll a tartalék adatbázis szerverre akkor az gondot okozhat.

--
maszili

Nagios, Zabbix, sms van már, elég jól lehet velük dolgozni :-) Ja, ha a replikációs is áll, ÉS a master is elhasal, akkor valóban sz@r van a palacsintában - automatice nem illendő a slave-re átállni ilyen esetben - aztán hogy lesz-e adatvesztés, vagy sem, az jó kérdés. De ez a két esemény (slave-en elakad a replikálás ÉS utána a master is elhasal) azért nem túl valószínű állapot szerintem...

1. Bármilyen egyéb hibára futott tranzakció esetén megáll a replikáció nem csak nemlétező tábla törlése esetén. Én csak egy egyszerű példát mondtam a tábla törléssel.
2. Go to 1.
3. Ez esetben nem a rendszer felépítése adja a magas rendelkezésre állást (holott az lenne a feladata) hanem az ember. Akkor meg mi értelme?

--
maszili

Mondjuk úgy, hogy volt néhány mmm-clusterhez közöm, és elég nagy forgalmat vittek a site-ok, ami mögött pörögtek. De user (fejlesztő/admin) illetve hardver hibán kívül nem volt szerencsém széthulló replikához - olyanhoz igen, hogy egy karbantartó script mindkét node-on lefutott, és egy "delete from..." megfogta a szinkront, de ezt -mivel ismert volt az ok- egy skip megoldotta.

1. Miért te egy 7/24-es rendszert mikor frissítesz ha nem munkaidő után?
2. egyetértek
3. ezt így nem állítanám, szerinted az internet bankoknál van aki 0-24-be felügyeli ? A monitoring rendszer riaszt vagy, ha olyan a baj, hogy az nem veszi észre akkor a telecenternek úgyis bejelentik és felfognak hívni.

Akkor felvilágosítalak, hogy az operátor a napi zárásokat csinálja (plusz szalag csere, fileok megérkezésének ellenőrzése, stb), és nem 0-24-ben monitorozás a fő feladata. Az ügyfél hamarabb bejelenti a hibát és a telecenter hamarabb felhív mint, hogy az opi észreveszi hogy az ott piros és fel kéne hívni valamelyik ügyeletest, így ez az állításod miszerint "Komolyabb rendszerek eseten 0-24-be ul ott ember aki felugyeli a dolgot." nem teljesen helytálló. Tök fölöslegesen ilyen rendszerre a monitorozó ember, aki ember lévén hibázhat is és elfelejtheti nézni az eseményeket, erre van a telecenter, hogy hiba esetén az ügyfél bejelentse a hibát és ők tudják kit kell hívni ilyenkor, de nekik sem a rendszer felügyelete a feladatuk, továbbá jön sms a monitorozó rendszertől, ha baj van, és az gyorsabb mint az opi valaha is lesz.

Ez melyik bank? Az ügyésznél ott kell legyen az SMS, amint pirosodik valami a monitorozó rendszerben. Persze hogy mitől pirosodik egy host vagy szolgáltatás a monitoringban, azt jól meg kell válogatni, de hogy a kritikus eseményekről NEM humán interfészen keresztül kell értesíteni az illetékest, az biztos.

Amelyik "szolgáltató" az üf.-től (akiből él) várja azt, hogy bejelentse a hibát (jó kérdés, hogy egy belső rendszer elhasalásával mi lesz?), azt a szolgáltatót ott kel hagyni a búsba, pláne, ha kiló krumplinál komolyabb dolgokra vonatkozóan szolgáltat.

Ne csak a mondatom egyik részét értelmezd. Ott az SMS értesítés olyan hibáról amit egy operátor is tudna monitorozni, (minek is kell az operátor ilyenkor?, mert a monitorozó rendszer gyorsabban ki fogja küldeni az sms-t, plusz nem fog annyi mindenre figyelni mint a rendszer ) az olyan hiba amit meg nem tud a monitorozó rendszer észrevenni azt az ügyfél fogja bejelenteni és nem fogja neked egy opi folyamatosan tesztelgetni. Ezt próbáltam elmagyarázni. Az megint egy másik dolog, hogy az opi monitorozza azt, hogy az sms küldő megy-e, vagy hogy a monitorozó rendszer él-e.

Az opi, mármint az, aki az OC-ben ül, az igenis figyelje a ződ/sárga/piros jelzéseket, figyelje a kritikus paramétereket (illendően összelapátolva a grafikonokat egy képernyőre), ezen kívül legyen képben, hogy ha a trendek azt jelzik, hogy gáz lehet, akkor nézzen utána, a kapott sillabusz alapján intézkedjen (tesztelés, leírtak szerinti hibakezelés, illetve ügyeletes mérnök/rendszergazda/DBA/etc értesítése.)

"Akkor felvilágosítalak, hogy az operátor a napi zárásokat csinálja "

Meséld el nekem kérlek hogyan működik az pár bank, telco cég stb. ahol eddig dolgoztam, vagy épp most is dolgozok.

Légyszives közöld azzal az operátorral, hogy ő nem létezik, aki ma hajnalban azzal ébresztett, hogy a leállási időkereten túl már 10 perce áll egy rendszer.

Valóban nincs mindenütt operátor, aki lesi a monitoringot, de legalábba annyi helyen van.
Nem mindíg operátornak hívják, de a lényeg az, hogy valaki van aki 0-24 ben lesi a Nagiost, Tivolit, akármit.

SMS ügyben: Egy telco cégben az sms küldő rendszer leállásáról légyszi küldj értesítést SMS-ben. :)

Anno 1999 december végén volt szerencsém ilyen jellegű felkészüléshez - az sem volt mindegy, hogy adott (felsőbb) szinten intézkedésre jogosultak közül vezetékesen kinek, milyen telefonközpontból volt kihúzva a vonal, illetve a központi ügyeletnek is ki lett alakítva többféle elérhetőség (vezetékes ha jól tudom kétféle központból, illetve mobilból is több).

ok, rossz volt a példa.
Olyasmire gondoltam, amit egyszer már láttam, hogy a monitoring rendszerből kimenő SMS-eket kezelő szoftverkomponens elpusztulása miatt nem mentek ki a riasztásos SMS-ek. (Az, hogy ez a hiba pont egy telco cégnél jött elő, tényleg irreleváns.)
Mindenesetre ilyenkor jól jött az opi, aki 10 percen belül csörgött, hogy öreg megpusztult valami sms-nevű cucc ezen és ezen a szerveren. :)

Te se csak a mondatom egyik felét értelmezd. Nem azt állítottam, hogy sehova nem kell a monitorozó ember, de ahol lehet valamit monitorozni és eseményeket beállítani (sms küldés) arra fölösleges az operátor, mint monitorozó ember. Az, hogy a monitorozó rendszert vagy az sms küldő részt monitorozza az oké, sőt másodlagosként meg is kaphatja a riasztást, és ha nem ébredne fel az ügyeletes az sms-re értesítse, de nem ő fogja az üzleti alkalmazásod monitorozni.

"Légyszives közöld azzal az operátorral, hogy ő nem létezik, aki ma hajnalban azzal ébresztett, hogy a leállási időkereten túl már 10 perce áll egy rendszer."

Elég szomorú, hogy nem a monitoring rendszer sms-e ér ki hozzád hamarabb, hanem egy operátor értesít arról, hogy baj van. Ez alól kivétel, a monitorozó rendszer és az sms küldő.

"Elég szomorú, hogy nem a monitoring rendszer sms-e ér ki hozzád hamarabb, hanem egy operátor értesít arról, hogy baj van."

Éjszaka 10 perc belefér. Több óra nem.
Egyébként sem csak gyorsaságról van szó.
Az operátorok többsége (nem mindegyik) intelligensebb az automata SMS küldésnél, és vannak olyan helyzetek, amikor ez szükséges.
Az éjszaka közepén nem biztos, hogy mindenki felébred az SMS-re legyen az bármilyen hangos, vagy előfordulhat, hogy lemerül a telefon, vagy bármi más hiba miatt nem jut célba az SMS.
Az operátor addig próbálkozik amíg az ügyeletes fel nem veszi, és ha kell 2-3 másik számot is felhív, a lényeg, hogy addig nem adja fel, amíg valaki tuti nem foglalkozik a problémával.

"de nem ő fogja az üzleti alkalmazásod monitorozni. "
Neki egyetlen feladata van: lesse a dashboardot, aztán ha valami piros, hívja fel azt az ügyeleti számot, ami a piros kockán belül van, aztán ha arra nincs válasz, hívja egyenként az alatta levő neveket.

Az SMS jó dolog, de ahol egyébként is adott az operátor, akkor miért ne tudna időnként rápillantani egy plusz monitorra.
Tudok olyan helyről, ahol SMS-only riasztás van, és elismerték, hogy pár kellemetlenséget elkerülhettek volna, ha van az SMS mellett operátor is, aki tényleg meg tud győződni arról, hogy a riasztást vette is valaki.

Sz@r dolog az sms-only riasztás, de azért meg lehet szokni, de egy idő után (lehet, hogy a korral meg a család meglétével jár) kezd széthullani tőle az ember (alvászavar, családi gondok), úgyhogy hosszú távon sem a dolgozónak, sem a cégnek (ha van esze a dolgozónak elhúz máshova) nem jó.

Egy jó sms riasztás csak az éppen aktuális ügyeletesnek küld üzenetet.

Egyébként az sms-el kapcsolatban nekem speciel pont ellenkező problémám van: nem tudom olyan hangosra állítani a telefonomat, hogy tuti felébredjek rá.

Régebben előfordult, hogy akkor sem ébredtem fel, mikor az asszony elfelejtette kikapcsolni a kiskrapek légzésfigylőjét, mikor éjszaka kivette megetetni.
(5 percen keresztül sípolt az a szar a fejemtől 2 méterre - de aludtam békésen.)

Van igazság abban amit mondasz, de akkor is elsődlegesen az sms és mellette az operátor mint backup a meglátásom.
"Éjszaka 10 perc belefér. Több óra nem."
Csak nem ez a tapasztalat, legjobb esetbe is egy óra után hívtak fel, mikorra én már nagyban dolgoztam a problémán, vagy épp már meg is oldottam. De nekik nem a monitorozás az elsődleges feladatuk.
"Neki egyetlen feladata van: lesse a dashboardot, aztán ha valami piros, hívja fel azt az ügyeleti számot, ami a piros kockán belül van, aztán ha arra nincs válasz, hívja egyenként az alatta levő neveket."
Na ezt egy olyan operátornak akinek a napi zárások, szalag cserék, stb a feladatai nem fogja normálisan tudni csinálni. Persze ha olyan opiról beszélünk akinek csak a monitorozás a feladata akkor teljesen igazad van a leírt kritériumokkal kapcsolatban, csak ezt luxusnak érzik nálunk.
Két különböző opiról csoportról beszélünk, és ezért értettük mi egymást félre.

"ezt egy olyan operátornak akinek a napi zárások, szalag cserék, stb a feladatai nem fogja normálisan tudni csinálni"

wtf? Napi rendszerességű szalagcsere a tape libek korában? :) :)

5-10 percenként 1-szer rá tud pillantani, hogy piros -e. Sőt, láttam már olyan megoldást ia, hogy a nagyon kritikus eseményeket hangjelzéssel is jelezte a monitoring cucc (üvöltött mint sakál. :) )
Persze munkahelye válogatja. Ha alapból túl van terhelve az opi, mert pl. egyedül van és az kevés, akkor az tényleg szívás.

"wtf? Napi rendszerességű szalagcsere a tape libek korában? :) :)"

A páncélszekrénybe nem megy magától, plusz a távoli telephelyre se. Arról nem is beszélve, hogy van olyan rendszer ami annyira el van szeparálva mindentől, hogy saját tape-je van és ott bizony kézzel kell cserélni.

"5-10 percenként 1-szer rá tud pillantani, hogy piros -e."
Jah csak ha épp a páncélszekrénybe van akkor nem fogja látni :), plusz ha elkezd egy zárást akkor arra koncentráljon és ne mással foglalkozon, mert ha elbassza azt, akkor a reggeli nyitás veszélyben is kerülhet. Az utóbbi időben egyre többször elbaszák az esti betöltéselet és kezd már elegem lenni abból, hogy visszallítgassuk. ( ezt hála a jó égnek egy belső rendszernél csináljták, így az ügyfélre nem hat ki)

"A páncélszekrénybe nem megy magától, plusz a távoli telephelyre se"

Páncélba tényleg nem, viszont távoli telephelyre simán (pool replikáció). :)
de ne rugózzunk rajta, értem, hogy mit akarsz mondani, és ebben igazad is van: Túlterhelt opikra nem lehet érdemi monitorozást alapozni.

az hogy egy hibas parancs miatt megall a slave sql thread nemhatja meg a slave io szalat, az szepe szivja at a binlogot. szal ha az nem all le, akkor adat nem veszik el, csak epp "nem elerheto". persze utana visszahozni tobboras lemaradast nem egy gyors dolog.

es ha jol emlexem, mmm nem esznelkul pakolgat, hanem meggyozodik rola, hogy a masik gepben bennvan-e minden a binlogbol.

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

az hogy egy hibas parancs miatt megall a slave sql thread nemhatja meg a slave io szalat, az szepe szivja at a binlogot. szal ha az nem all le, akkor adat nem veszik el, csak epp "nem elerheto". persze utana visszahozni tobboras lemaradast nem egy gyors dolog.

Ez igaz. De szerintem az elég nagy baj, hogy a binlog feldolgozás alatt amig utól nem éri magát a szerver egy "régebbi" adatbázist lát a kliens. Az egy másik kérdés, hogy a kliensektől érkező adatok és a binlogból olvasott adatok milyen esetleges duplikációt vagy más bonyodalmat okoznak.

--
maszili

Maradjunk annyiban, hogy elég nagy forgalmú (témájában piacvezető) webes szolgáltatás mögött láttam ilyet, és köszöni szépen, prímán működik (rw és ro kérések szeparálásával). A kérések elenyésző része insert/update/delete - az adatfeltöltés/frissítés alacsony forgalmú időszakban kényelmesen elvégezhető.

( hccoder | 2012. 06. 06., sze – 11:07 )

Sziasztok,

köszönöm az eddig rengeteg segítséget, tegnap továbbfejlesztettem a rendszert, úgyhogy halad a dolog, ma este remélhetőleg feltudom majd tenni az itteni blogomba az eddigi tapasztalatokat(2 load balancer megy 1 virtuális IP-vel mögötte 2 webserver és tegnap azok mögé beállítottam 2 storage-t glusterfs-el).

Egyedül a MySQL(azért ragaszkodok a MySQL-hez mivel az volt az alapötletem, hogy megbízható shared hostingot készítsek) fájdítja a fejemet, rengeteg forum, blog bejegyzést, tutorialt olvastam az elmult pár napban ezzel kapcsolatban, és úgy döntöttem, hogy leegyszerűsítem a tudásomhoz mérten a dolgot.

Megoldás amit tegnap éjfélkor találtam ki:
- telepítek bindet 2 külön serverre master-slave(ezt mindenképp szeretném mert bindet még nem konfiguráltam)
- mysql-t master-slave megoldással konfigurálom
- a dns serveren beallitom mondjuk a db.localdomain-t a master mysql-re
- ha lehal a master mysql akkor megy egy mail a root-nak, hogy "bajvan, állítsuk át a slave-t masterre valamint a hozzátartozó DNS rekordot"
- lelövöm a master-t és elvileg kapom róla a mail-t, átállítom a slave-t + a dns-t és minden megy tovább

Így lesz kiesés, de ha automatikusan kapcsolgatom át a slave-t masterbe és visszajön a régi master akkor az szívás gyanús, valamint multimasternel ugyancsak jöhetnek mindenféle split-brain problémák(plusz gondolom egy csomó olyan amiről nem is tudok:)).

Ha ez így működik akkor megpróbálok rá írni scriptet, hogy ha kiesik a master akkor slave-bol csináljon mastert és magátol írja át a DNS-t. Aztán kinyomozom, hogy miért halt le a régi master, megjavítom, visszaállítom a régi felállást és minden megy tovább :). Ez így persze marha jól hangzik, elméletben :).

Szerintetek ez így milyen elgondolás?

Köszi

Kar, hogy nem mondtad a shared hostingot korabban, akkor kicsit tobb tippet tudtam volna adni. Ez egeszen mas tema, mint egy jol definialt alkalmazast futtatni, ugyanis a felhasznalok random cuccai egeszen erdekes helyzeteket tudnak produkalni. Ha ebbol uzleti szolgaltatast csinalnal, akkor erosen el kellene gondolkoznod azon, hogy mennyiert adod a tarhelyet, mert a low cost kategoriaban (eves 20k HUF-ig) egyszeruen nem eri meg clustert tenni a userek ala, mert akkor nem tudsz eleg usert tenni egy gepre ahhoz, hogy megerje.

Ha szeretned, akkor vegyel fel skypeon, elmondok par tapasztalatot az elmult evekbol.

Köszi, nem szeretnék egy újabb hosting szolgáltató lenni. Az egész projekt abból indult, hogy láttam párszor itt olyan topicot, hogy "vettem egy server-t, hogyan csináljak ebből webserver-t + tárhelyet + email server-t + etc-t...", tehát vesz mondjuk 100k-ért egy használt server-t 2-4 vinyoval, berakja havi 15k-ért egy terembe és eladja x Forintért havonta, a weboldalára meg akár ki is írhatja, hogy "szerverparkunk 60 über gépből áll, minden tuti gyere 200 Forintért havonta".

Rendszergazdának tanultam mert nagyon tetszik a téma, de fejlesztőként dolgozok mivel már nagyon régóta fejlesztek, ezért határoztam el, hogy magamnak otthon megpróbálom összeállítani a "a megbízható shared hosting szolgáltatót" csak mert szeretek tanulni.

Nagyon kedves tőled a skype-os lehetőség, gondolkodtam már rajta, hogy itt keresek "mentort" akivel esetleg pár sör mellett(természetesen én állom a sört) lehet tanulni, persze nem egyetemi szinten érdekel engem a dolog, csak, hogy mondjuk egy ilyen rendszert nagy körvonalakban, hogy kell megtervezni(ez gondolom 4-5 sör alatt megbeszélhető) :). De ha nem szereted a sört, vagy nem tudsz időt szakítani ilyenre akkor a skype is nagyszerű :).

Sajnos nem a megfelelő cluster technológiák összeépítésében van a kutya elásva.

Ha csak a műszaki követelményeket nézed, akkor rendszeruser szinten el kell szeparálnod a felhasználókat (ezért), meg kell oldanod, hogy egy user ne tudja beborítani a szervert, ne tudjon róla spamelni és kell lennie tisztességes mentésnek és recovery plannek is. Ezen felül persze még legalább 20 apróság van, amit még össze tudnék szedni.

Ha a műszaki követelményeken túlmutató dolgokat nézel, akkor ott van az a probléma, hogy a felhasználónak lövése nincs arról, hogy a megvásárolt Webgalamb nevű foshalmaz miért nem jó hírlevél küldésre. (És ez maximálisan szigorúan a magánvéleményem, mielőtt valaki még messzemenő következtetéseket vonna le.) Namost az ilyen felhasználók kedvéért kell feltelepítened Perlt is a gépre és meg kell oldanod, hogy a mailszervered lassítsa a levélforgalmat ha a user floodol. Vagy a másik díszpéldány, aki filerendszeren működtet adatbázist aminek lockolás kell a normális működéshez és nem lehet elmagyarázni neki, hogy nem POSIX filerendszer van alatta, mert ő sok pénzért iratta a szuper tákolmányát és a hosting szolgáltató márpedig oldja meg.

A shared hosting radikálisan kűlönbözik bármilyen egyéb webes rendszertől, mert beengeded a felhasználót rendszer szinten a gépedre, nem csak egy HTTP-n elérhető szolgáltatást nyújtasz. Gyönyörű szép projekt, én 4-5 évet fordítottam rá az életemből és tényleg szerettem csinálni, de egy vastag adag programozást is fog tartalmazni, nem csak scriptelést.

Na ezekről mind szívesen mesélek, de a sörnek váratnia kell magára, mert csak ritkán vagyok Budapesten ugyanis Bécsben élek. Skype-on cseveghetünk viszont szinte bármelyik este.

- ha lehal a master mysql akkor megy egy mail a root-nak, hogy "bajvan, állítsuk át a slave-t masterre valamint a hozzátartozó DNS rekordot"

Nem jó koncepció. A DNS rekord megváltoztatása általában nem definiált időn belül fejti ki csak a hatását. Kivéve, ha minden gépedet és/vagy a rajta levő kliens alkalmazásokat újraindítod.
A helyes technológiát úgy hívják, hogy IP failover. Azaz a szolgáltatáshoz IP címet rendelsz, azt pedig átrakod arra a gépre, amin a szolgáltatás lakik. Van erre a témára egy másik variáció is (ha van erre a célra használható, megbízható load-balancered, vagy ilyen üzemmódban használható DNAT-ot tudó Linuxos tűzfalad), de az általában több szívást is felvet.

Egy kis javaslat finomításra: squid, statikus/dinamikus forgalom szétválasztása, apache mellett képkiszolgáló telepítése

Vagy inkább sörözz egyet ebben a melegben :)

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

ahogy a webserverek load balance-olását megoldottam haproxyval, de azt MySQL-el összehozni meghaladja a képességeimet :).

Nem csoda, mivel a mysql általános esetben sehogy sem load balance-olható.
Felvetettek itt jobbnál jobb replikálásokat meg egyebeket (valaki még a mysql clustert is bedobta :), csak azt felejtették el hozzátenni, hogy egy triviális esetet kivéve ezekhez mind hozzá kell igazítani az alkalmazást, ergó nem működnek random alkalmazások alatt, ha azokon nem változtatsz. A triviális eset az, amikor van egy darab éles mysql-ed, oda dolgozik az alkalmazás, és ebből készítesz backup (mentés/tartalék) céljából replikációt, amit majd éléssé léptethetsz elő (manuálisan), ha az élest elüti a villamos. Ez minden, csak nem load balancing, ugye.

akkor olvass utána a HA clustereknek....
Az IP failover elég általános és stabil megoldás sok helyzetben.

Szerintem az a vicces dolog, amikor kritikusnak gondolt adatokat raknak egyesek mindenféle tákolt-foltozott multimaster csoda megoldásokra, és el is hiszik, hogy húdestabil hibatűrő megoldást csináltak.

Nem annyira vicces, sokkal inkább használható. Az adott szolgáltatás a cluster ip-n figyel, ha elhal valamin a heartbeat átdobja a kiszolgálást a másikra úgy, hogy A node-ról cluster ip le, B node-ra cluster ip fel.

Egy példa: squid loadballancing, van 2 cluster, clusterenként 2 webserver és 1 cluster ip-vel. Ha a clusterben kiesik a webserver heartbeat átdobja a cluster ip-t és megy folyamatosan. További előnye a dolognak, hogy szabadon bővíthető további clusterekkel. Megjegyzem shared ocfs esetén tud szépeket produkálni, ha a heartbeat és az ocfs mást lát a másik node-ból

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

És ezzel a "szuper" megoldással mit kezdesz azzal a géppel, amelyik az immáron nem nála levő szolgáltatás IP címéről még bele-beleköhög az éterbe packetokat? Hiszen neki fingja sincs arról, hogy szabad-e ezt, az IP cím nála (is) van, a routingról meg más valaki dönt valahol máshol.

Miért köhögne erről az IP címről is bármit is a terheléselosztó, akármi?

Meg, mi az, hogy nem nála lévő? Minden terheléselosztón ott van a lo if-en a vip ip, amire érkező forgalmakat (amit a router routol a terheléseloszto publikus lábára) 1:1-be routol/nat-ol/akármi a cél géphez, az meg majd válaszol a kliensnek. a terheléselosztón nem megy a kliens felé forgalom.

Az, hogy melyik terheléselosztón éri el ezt a címet a router, azt meg valami dinamikus routing megoldással kel tudatni a routerrel értelemszerűen, nem kézzel bedrótozni.

Nem igazán értem miért lenne hosszabb idő a routing állítása mint az arpolás, stb.

Mint irtam, nem statikus routeokat használsz, hanem valami routing daemont, ami dinamikusan állítja a routeingot, tudja az összes útvonalat, és ha valamelyik kiesik, azonnal állítja a gépben, routeren, stb az új útvonalat.

mert az ARP az megkap, feldolgoz. OSPF/BGP etc az pedig megkap, feldolgoz, ujraszamol.

Akkor erdemes routingot hasznalni ha az arp nem oldja meg a problemadat a KISS alapelv szerint. Ha olyan a halozat, hogy nincs benne routing azon a szinten ahol te vagy, akkor nem kell bekavarni a quaga es tarsait, mert ami bonyolultan mukodik, az meg bonyolultabban szarodik el.

Noigen, de te nem veszed hozzá azt, ami az arp megkap előtt történik. Kiesik egy gép. Valami, amivel figyeled észreveszi ezt, majd végrehajt egy parancsot (húzd fel az ip-t) és eztán jön csak az arpolás.
másik esetben kiesik a gép, hirdetés megszűnik, új routing számolódik (vagy sem, mert ha backup routerként megy akkor nem számol sokat), beállítódik.

Dehogynem lehet, jó rég óta van ilyen feature: http://www.cisco.com/en/US/docs/ios/ios_xe/iproute_ospf/configuration/g…

Na várjál, a health checket végezze az LVS, annak semmi köze az ospf-hez. Most mi az internet és a saját terhelés elosztó közti kapcsolatról beszélünk nem? Mert a lerohadás meg a terheléselosztó meg a saját belső géped között van.


Dehogynem lehet, jó rég óta van ilyen feature: http://www.cisco.com/en/US/docs/ios/ios_xe/iproute_ospf/configuration/g…

idezem magam: "Dead timer", nem hello timer. kuldhetsz te ezredmasodpercenkent is hellot ha 1 masodperc alatt fog eldolni, hogy halott-e vagy se.


Most mi az internet és a saját terhelés elosztó közti kapcsolatról beszélünk nem?

Most arrol beszelunk, hogy ha nem muszaj ne bonyolitsd a dolgot ospf-el (mert hajnal kettokor szar troubleshootolni azt, hogy most miert "ragadt be" az egyik LSA es mit kell csinalni ahhoz, hogy eltunjon) meg arrol, hogy az arp gyorsabban at fog valtani mint az ospf.

Mar csak azert is, mert ahhoz, hogy ARPot tudjal hasznalni egy l3 domainben kell lenni igy kevesebb eszkoznek kell konvergalnia, valamint a gratuitous arp-ot nagyjabol mindenki egyszerre fogja feldolgozni (first hop router/switch).

Persze ez mind topologia fuggo es adodhat ugy, hogy ospfet kell hasznalni, mert nem azonos az l2 domain, nem egyezik a first-hop-router, esetleg nem akarsz atswitchelni, egy kocka designban stb, stb, stb.

Ismetlem en csak annyit mondtam, hogy az arp hamarabb atall es joval egyszerubb mint az egyeb routing protocollos megoldas es ha mindketto alternativa akkor az egyszerubb, legtobb esetben jobban szokott mukodni.

Kb. 2 éve próbálkoztam mysql master-slave replikációval. Akárhogy erőlködtem, a szinkron random szétesett egy tartalék MTA lett volna felépítve, spam adatbázissal és miegyébbel. A vége mindíg az lett, hogy a slave egy idő után nem frissűlt, kézzel való beavatkozást igényelt... Végül csináltam egy switch app-ot c-ben ami annyit csinált, hogy a konfigjában felsorolt adatbázisoknak tovább küldte az SQL kéréseket. Treveztem hogy megcsinálok valami failover loadbalance funkciót is ami a lekérdezéseket osztja szét, de erre még nem volt szükségem, lévén minden MTA csak a lokális adatbázisához fohászkodik válaszért most még.
---
http://youtu.be/mzycLGudWTw

Ez érdekes, nagyon sok mysql DB-t láttam igen masszív terheléssel ketyegni master-slave felállásban, és nem volt ilyen lerohadás, legfeljebb néhány perces lemaradás fordult elő - de akkor már dobta a warningot a monitoring, hogy figyeljünk oda. Beavatkozni viszont nem igazán kellett soha.

Nem a masszív terhelésen van a hangsúly, hanem azon hogy a két node kb. 15.000km-re (TX USA, és VH IW) volt/van egymástól (hálózatilag akár több is lehet) eltérő disztrókkal (debian és centos) és eltérő mysql verziószámokkal stb... és "valamilyen" 100-as (de inkább 6mbps-os) internetkapcsolattal. Persze ha béreltvonal, és földrajzi közelség adott lenne, akkor nyilván ment volna replikáció. Én próbálkoztam vele vagy 0.5 évig, de nem jött össze.

---
http://youtu.be/mzycLGudWTw

( janoszen v | 2012. 06. 06., sze – 21:00 )

Másik tipp: ha összeraktad, adj innen mindenkinek user accountokat a hosting clusteredre és nézd, mi történik. Kíváncsi vagyok, mennyi idő alatt lehet megborítani. Szintén hasznos tapasztalat.

Jó ötlet, de kicsit módosítottam a koncepción, most egyetlen weboldal lesz csak a rendszeren, hogy kicsit egyszerűsítsek a dolgon, viszont ha ezzel a rendszerrel kész leszek valaha lehet megpróbálom a shared hosting kivitelezését, de hol van az még :).

( hccoder | 2012. 06. 07., cs – 09:02 )

Tegnap este sikerült összekomponálnom az első bejegyzést a clusterrel kapcsolatban, akit érdekel az itteni blogomban megtalálja, ha minden jól megy 2-3 naponta tudok majd friss tapasztalatokat megosztani.