Sziasztok!
A 'Melyik a legjobb 10 magyar tárhely szolgáltató? ' témában indult vitát szeretném kiemelni onnan, egyrészt azért,
mert én oda nem szívesen írok, másrészt ennek a vitának nem ottvan a helye!
Kis emlékeztető: Felmerült a kérdés, hogy 1 millióból össze lehet-e rakni egy HA rendszert? Nemes
egyszerűséggel itt feltételezem azt, hogy tárhely kiszolgálás céljára.
Rögtön reagálnék Karesz hozzászólására:
http://entity.hu/tarhely/5428-melyik...tml#post297222
Karesz, teljesen igazad van az árakat tekintve, viszont a felvetést tekintve, miszerint HA rendszert
alkotunk, ha az a rendszer jól meg van alkotva, akkor hardware tekintetében nyerünk egy kis
szabadságot a minőséget illetően! Nagyon fontos tudni azt, hogy tárhelyek tekintetében legtöbbször
olyan rendszerekhez kell megalkotnod a hátteret, amik feltételezik, hogy egy szerveren futnak, a wordpress
kivételével szinte az összes CMS ilyen! Egy jó HA rendszer épp attól HA, hogy egy-egy hardware hibáját
képes áthidalni, példa erre a RAID, olcsó eszközökkel építünk nagy biztonságú adattárolót, hiszen egy-két
meghibásodott merevlemez nem jelent leállással járó problémát.
Egy HA rendszer megtervezése és kialakítása (üzemeltetése) során rengeteg olyan problémával fog szembesülni
az ember, ami egy egyszerveres megoldás esetén nem jellemző. Rötön csak pár dolog, ami eszembe jut:
- Storage kérdése, milyen filerendszert használjunk, hol tároljuk egyáltalán az adatokat? Hirtelen erre nincs
egyértelmű válasz. Központi tároló: egy valóban megbízható, esetleg redundáns tároló a fenti keretösszegünket
azonnal kimerítené, sőt többszörösére lenne szükégünk. Elosztott tárolás: vannak erre megoldások, de jelenleg
vagy nem túl jó teljesítménnyel dolgoznak, vagy nagyon experimantal a kód, tehát produktív rendszerekbe nem
javasolják.- Bármelyik storageot is választod, egy adott adat több helyen tárolása, vagy egyáltalán annak a lehetővé tétele,
hogy több gépről elérd hálózati forgalmat fog generálni, teljesen mindegy, hogy ez most FC, SAS, iSCSI, NFS, GFS, bármi,
azzal, hogy több gép/processz is hozzányúlhat egy adott állományhoz kénytelen leszel lemondani arról az előnyről,
hogy az adatok a memóriában gyórsítótárazhatóak. Egyszerű példa egy magento webáruház alapján, ez a webáruház
a tervezési átgondolatlanságokból adódóan hajlandó több, mint 100-120e lstat műveletet végrehajtani. Ez a művelet
lehet akár csak annyi, hogy megnézi, hogy egy adott file létezik-e vagy nem. Mivel a rendszer önmagában nem tudja
megállapítni, hogy egy adott file időközben egy másik node beavatkozása miatt megváltozott, odakerült, törölték,
ezért a helyi cache adatokat mindenképp kénytelen frissíteni. A frissítés többnyire hálózati művelettel fog járni,
mondanom sem kell, hogy ez kis késleltetést fog bevinni minden ilyen művelet végrehajtásába, érthető módon a memóriaművelethez
összehasonlítva ez tetemes késleltetést fog jelenteni. A valóságban egy ilyen kérés 10-100us, de felszorozva ezt a fenti
számmal, máris ottvagy, hogy az egyszerveres t... gazdaságos szolgáltatóhoz képest a TE nagy rendszeret handicap-pel
indul. Lehet, hogy HA meg minden, de rohadtul nem fogják megérteni az ügyfeleid! (mielőtt ebbe belekötne bárki is, valóban
vannak fejlett FS, amik képesek a cache adatokat is szinkronizálni, de ezek általában véve még nem terjedtek el a mindennapi
használatban, és akadhat kompatibilitási probléma is velük, arról nem beszélve, hogy hiba esetén foghatod a fejed, hogy
mit csinálj vele!)- Amióta több processz dolgozhat egy gépen, azóta szükség van arra, hogy egy-egy művelet során biztosra mehessünk, hogy
a módosítás közben az adott adat más részét nem változtatja meg valami időközben. Erre alkalmazzák a lock-okat, ennek
több megoldása is létezik fileműveleteknél, flock, lockf, lockfile, sorolhatnám még, jelen esetben nem megyek bele ezeknek
a taglalásába, lényeg az az, hogy ezeket a megoldásokat a php programok sokszor az egyszerűség miatt nem megfelelően
impelentálják, így akármilyen hálózati fs esetén komoly teljesítmény bajaid lehetnek! Normál esetben a zárolt fileok metaadatait
a kernel memóriában tárolja, de mivel több gépről beszélün ez a megoldás nem használható... Jelenleg nincs normál sebességre
alkalmas hálózati lock megoldás.- Nagyon fontos egyébként eljátszani a gondolattal, hogy mi történik a rendszerrel akkor, ha software hiba történik, például
kernel hiba! Bár sok elosztott rendszerű fs létezik, sajnos mindegyiknek van egy hátulütője, nevezetesen az az, hogy
egy kernel hiba az egyik nodeon olyan hibákat okozhat, ami alapján a teljes filerendszeret is ugorhat! Részemről egyébként
nagy reménységem a GFS, ZFS backenddel, de nagyon friss még a fejlesztés, tehát várhatóan nagyon kiforratlan is!- Újra kis hardware kérdés, mivel a gépeket össze kell kötnöd kézenfekvő dolog az olcsó ethernetet használni, de
láttunk mi már switch hibát (sajnos) ;( A gépeket más technológiával összekötni pedig lehet, hogy drágább lesz, mint
a fenti keretösszeg.- ...
Ne haragudjatok, de ezt a hozzászólást most nem tudom folytatni, mert el kell mennem, de addig is írjatok bátran és
folytatjuk!
Könyvjelzők