Adatbázis klaszter Drupalra

Linux-haladó

Valaki adhatna javaslatot arra, nginx mögött futó Drupal oldalahoz
milyen adatbázis klaszteresítési megoldásban gondolkodhatunk?
(a Drupal miden node gépen ugyanaz, adatbázisa ugyanannak kell lennie)

Tesztelt megoldás kellene, nem gugliból kivett vélemény....

Az már csak hab lenne a tortán, ha a db írási műveletek is irányítottan viselkednének
a db klaszter node-jain....

kösz,

  • 2176 megtekintés

( oszfer | 2011. 11. 03., cs – 23:32 )

Első kérdés, hogy alapvetően a teljesítmény miatt (nem bírod egy géppel ellátni a db-szerepkört), vagy a magas rendelkezésreállás végett kell a db klaszter?

Sejtésem, hogy esetedben leginkább az első (ti. a teljesítmény)miatt kell: Ebben az esetben aligha kapsz bárkitől "kész", ingyenes megoldást. Az a tendencia, hogy az adatbázist szerkezetében szokás szétdobni a DB-kiszolgálók között (ld. "database sharding", ami külön tervezést igényel) és ehhez hozzáírni az alkalmazást.

Persze vannak "alacsonyabb szintű", az alkalmazástól elvonatkoztató próbálkozások: a mysql proxy például ígéretesnek tűnik (nekem nincs vele tapasztalatom). Sőt vannak, akik azt ígérik, hogy a meglévő alkalmazások adatbázisait is képesek ilyenné tenni:
http://www.codefutures.com/dbshards/

( andrej_ v | 2011. 11. 04., p – 00:17 )

Ha jól emlékszem van olyan Drupal MySQL driver ami a write és read query-ket külön-külön tudja szétdobni. Értelem szerűen a slave replikált példányok kapják a read és a master kapja a write kéréseket. Ilyet még nem kellett összeszerelni, de több frontend és egy dbszerver felállásban már drupaloztunk. Azt is érdemes megnézned szerintem, hogy milyen cache megoldások (jsmin, boost és tsai) vannak hozzá. Nagyságrendet sikerült ugyanis a lighttpd (expire, mod_compress) és a cache beállítással gyorsítani sima egyszerű oldalakon is.

( vl v | 2011. 11. 04., p – 01:35 )

Valaki adhatna javaslatot arra, nginx mögött futó Drupal oldalahoz
milyen adatbázis klaszteresítési megoldásban gondolkodhatunk?

Mi a cél?
Ha lehal az adatbázis node, akkor is menjen tovább a verkli?
Erre vannak értelmes HA megoldások.

Vagy egy node teljesítménye nem elég?
Akkor rábasztál, mert az adatbázis klaszter csak csökkenteni fogja a teljesítményt...

Mondjuk segítek: akkor indexeket kell kreálni, meg több és gyorsabb diszket venni, és nem klaszterben gondolkodni.

Kicsit árnyalva: azon az eseteknél, amikor valaki azzal szembesül (és fordul a rendszere szállítójához segítségért), hogy az egygépes adatbáziskezelője nem elég gyors (nem nyújt elég teljesítményt), az esetek 98%-ában egy bekötött szemmel elvégzett klaszteresítéssel az eredmény nem javítható érdemben, sőt, ellenkezőleg: az esetek döntő hányadában a klaszteresítéssel inkább tovább romlanak az eredmények.
És ez azért szokott így lenni, mert az okok jellemzően máshol húzódnak meg, és ha a probléma gyökerét nem kezeljük, a klaszteresítés ellenére a problémák is fennmaradnak.

Köszönöm.
Azért azt meg kell említeni, hogy ott ahol tényleg "nagy" a terhelés,
azaz rengeteg olvasás történik adatbázisból ott elkerülhetetlen a klaszter használata és valóban segít,
sőt az egyetlen alternatíva lehet.
De elhiszem, hogy az átlag magyar weboldalnak nem feltétlen kell nekiugrania egy klaszternak,
hanem inkább máshol kell keresnie a problémát, ahogy említetted.

node-ok közti szinkronizáció lassítja a dolgot, ez pláne gáz, ha a progi tervezésekor nem volt figyelembe véve az, hogy esetleg cluster lesz alatta.
tfh beszúráskor egy trigger valamit művel, ezért a felület beszúrás után vissza is kérdezi az új rekordot. De ha masterre írsz, slave-ről olvasol, akkor -- hacsak nem szinkronizált --, megesik, hogy a slave-nél még nincs ott az új rekord és közli, hogy hopp ilyen id-jű sor nincs, admin meg néz, hogy afasz.

ha pl mysql cluster editiont használsz, az szinkronizál, cserébe rohadt lassú tud lenni, ha a telephelyek közti net lassú/szakadozik/szarakodik a vpn, ráfuthatsz akár egy timeoutra is, pedig csak lassan replikálódik.

1) a drupal eleg jol indexelt, ha az keves, nem gondolom, hogy a db lesz a szuk keresztmetszet.
2) a drupal alapvetoen CMS, vagyis keves write - sok read alkalmazas. Ezen talan az elosztott db talan tud valamennyit gyorsitani.
-- 

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

( Nyosigomboc v | 2011. 11. 04., p – 04:17 )

Nem Drupal, hanem C++, es nem MySQL, hanem Postgres volt az adott rendszer, aminel ilyennel foglalkoztam, de azert leirom, mert ha a Drupal tudja hasznalni ezt is, akkor mazlid van.
Van ugyanis egy master-slave modja, gyakorlatilag at kell hozza masolnod a DB-t (meg a tranzakcio logokat), meg beallitani a config file-okat. A slave kapcsolodik a masterre, a programod is a masternek ad lekereseket. Az iras nyilvan mindketton vegbemegy, az olvasast meg - ha a slave-en kisebb a terheles - tovabb tudja adni, szoval a DB gyorsul. Ha a master kiesik, akkor viszonylag keves maceraval on-the-fly at tudsz terni a slave-re (ha a slave esik ki, elvileg amikor magahozter, az xlogokbol magatol megjavul), visszaallni mar macerasabb, kezi beavatkozast igenyel (odafele annyi, hogy beallitod a slave-et, hogy mostantol onallo (1 rm/touch, mar nem emlekszem), es vagy atveszed a master ip-jet (nyilvan LAN-on), vagy beallitod a programodat, hogy mostantol mas a DB kiszolgalo).

--
Az emberek azt állítják, hogy múlik az idő, az idő viszont csak mosolyog, mert látja, hogy az emberek múlnak. - tibeti közmondás

( mrmartin v | 2011. 11. 04., p – 10:12 )

Mi csináltunk és üzemeltettünk ilyet, első körben a tényleges igényeket kéne megfogalmaznod. Miért van szükséged db clusterre, teljesítmény vagy rendelkezésre állás miatt? Milyen adatbázis szervert használtok, mysql vagy pgsql?

Ha a failover miatt kell akkor én azt mondanám, hogy két erős szerver (HP DL580+8db SAS RAID6+0, vagy hasonló) és közöttük heartbeat + drbd az adat és log területnek. Ha teljesítmény kell akkor az előbbi párhoz, adj minden drupal frontenden egy-egy replikát. Az olvasás történjen a replikából az írás a master serveren. Ezen kívül használj memcached -t, kezd el a sysctl -t tekergetni különös tekintettel a tcp_keepalive* direktívákra. Szervezd ki a statikus tartalmakat (js, css, image/*, swf) nginx -alá. A js, css text/* tartalmakat gzip-eld.

Ha ezek is megvannak na akkor lehet nekiesni egy pgpool -os, multi-master-mysql -es clusternek, azért csak ezek után, mert jó eséllyel nem kettő, de nem is négy, hanem valószínűleg több server kell ahhoz, hogy teljesítményt lehessen nyerni.

----
올드보이
http://molnaristvan.eu/

Azt nem kétlem, hogy a mysql master-master támogatás létező dolog. Az üzemeltetése sokkal nagyobb feladat. Amíg a Heartbeat+DRBD -vel nem kell a slavelag -al számolni, addig a mysql mmr esetében igen.

1. Fogalmam sincs
2. Fogalmam sincs
3. A http://www.drbd.org/ -ról idézve: DRBD® refers to block devices designed as a building block to form high availability (HA) clusters. This is done by mirroring a whole block device via an assigned network. DRBD can be understood as network based raid-1. Nem értem miért lenne kockázatos két node -al (sok, kevés???) DRBD -t üzemeltetni.

----
올드보이
http://molnaristvan.eu/

A HA failover cluster shared storage-al lenne az igazi.
Bár biztos a DRBD is jó megoldás, de belevisz még egy komolyabb hibalehetőséget a rendszerbe.

Mysql master-slave + innodb manuális átállással egy elég megbízható megoldás lehet.
Ha az olvasást esetleg el kell osztani a két node között, akkor valami egyszerű IP cluster (UCARP) vagy mmm segítség lehet.

Remélem nem mondtam hülyeséget.

( lzskiss | 2011. 11. 04., p – 10:46 )

subs

OpenBSD 4.9/i386 theo for the prezident:D

( o_O v | 2011. 11. 04., p – 12:46 )

Heartbeat(vagy valamilyen CARP megoldas) + Mysql master-master replikacio
--
1 leszel vagy 0 élő vagy hulla!

( hrgy84 | 2011. 11. 05., szo – 01:36 )

Kellene meg info:
- Meretezes
- Mekkora rendelkezesre allas kell
- Mennyire kritikus adatok vannak benne (pl. ubercart/webbolt)
- Hanyas Drupal (6/7)?
- Postgres szoba jon-e?

Az utolso foleg azert kerdes, mert a 7-es mar tobb db backendet tamogat, mint a 6-os.
-- 

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