Sziasztok,
egy uj adatbázisszervert szeretnénk üzembe helyezni;
A napi oldalletöltés a hozzá tartozó weboldalon 10-14 millio/24h; így meglehetősen adatintenzív a dolog (ez jelenleg is így van; azonban a jelenlegi gép már igencsak csereérett).
Amennyiben hddre esik a választás, az 4 db SEAGATE HDD Server Savvio 10K.5 (2.5" ,300GB,64MB,SAS) lenne; raid10 -ben; azonban SSD -vel nincs tapasztalatunk.
Mennyire tartjátok megbízható megoldásnak az SSD -t, egyáltalán milyen márkát válasszunk?
Pro és kontra érvekre is kíváncsi volnék.
Előre is köszönöm mindenkinek!
Update:
OCZ Vertex VTX3-25SAT3-240G lett kinézve SSD meghajtónak.
Update2:
A választás a lent leírtak és a bizonytalanságfaktor miatt az SAS hddkre esett; mindenkinek köszönöm a hozzászólásokat és véleményeket; több szempontból is tanulságos volt!
Hozzászólások
Intel drágább szériája? Az 520-ra gondolok.
Kissé zavaró benne, hogy nem mer senki 36 hónapnál több garit vállalni...
mire? a 'túlírásra' nincsen garancia - legalábbis intelnél.
valamint a szerver kategóriás SSD-t jó eséllyel úgyis cseréled 3 év múlva...
#define tuliras
előre meghatározott, h egy adott blokk hányszor írható. A jófajta SSD-k megpróbálják az írásokat nagyjából jól elosztani. ezért mondjuk úgy van definiálva, hogy egy 120G SSD-re nagyjából 5TB-t írhatsz. ha ezt felírtad, akkor onnantól "kopik". Viszont - mivel 5TB felírására van hitelesítve - nem reklamálhatsz, hogy a 6. TB-t már nem tudod felírni.
Ahh, koszi! Műveletlen vagyok ssd tárgykörben...
Ez a limit hol van feltüntetve az ssdnél, és a smartból melyik értéket kell figyelni ezzel kapscolatban, hogy lássuk a (várható?) garantált élettartamát?
Ezek alapján 42x tudom teli írni az SSD-t hivatalosan? Ez nekem kicsit kevésnek tűnik. A fél éves 120GB-s SSD-men már 1,5TB írt mennyiség van, akkor ez alapján igen csak rövid élettartamú lesz a hivatalos forma szerint.
Bocs, hogy kicsit regi hozzaszolasra reagalok, de ez az 5 TB nagysagrendileg hulyeseg. 64GB-os jobb minosegu SSD-knel inkabb 500TB korul van ahol kifarad a medium, de most is vannak tesztben olyanok, amik mar 1 PB korul jarnak. 128 GB-os kapacitasnal varhato, hogy ennek duplaja lesz az elettartam.
A gyartok szoktak egy Media Wear Indicator attributumot felvenni a smart-ba, amikor ez az 1-et eleri, akkor ert veget a "garantalt" elettartam. Jobb gyartoknal nem ritka, hogy ezutan meg kb 5-7x ennyit lehet irni az SSD-re, es csak ekkor kezdenek el nagyon felszaporodni az irasi/torlesi hibak, amik az elettartam tenyleges veget jelentik.
---
Internet Memetikai Tanszék
itten mi jól elvetettük a (nem kifejezetten szervercélra tervezett) SSD használatát...
http://hup.hu/node/111176#comments
Hát igen... mondjuk itt nagyságrendi eltérés van az árakban...
http://meta.stackoverflow.com/questions/10369/which-tools-and-technolog…
Ez talán majd segít.
(Náluk Intel 710 van, ~240k HUF normál boltokban.)
sub
++;
+1
+1
Én nem javaslom az SSD-t. Ennek oka a minőségi SSD ára. Ha SSD-ben gondolkodsz, akkor ott az enterprise kategóriás eszközöket nézd. Márpedig azok jóval drágábbak.
Ha tényleg nagyforgalmú az adatbázis, akkor többet nyersz optimalizációval ár/minőség mutatót nézve. A helyedben nem 4, hanem 8 vagy 10 darab, de kisebb merevlemezt tennék be. Szépen szétosztva a feladatokat a tömbök között.
Például 2 db RAID-1: oprendszer, 2 db RAID-1 adatbázis log, 2 db RAID-1 adatbázis data, 2 db RAID-1 linuxnál naplók, swap/pagefile, adatbázis temp, 2 db RAID-1 adatbázis redo log.
ennél jobban jársz IOPS szempontjából, ha a sok diszkből inkább egy nagy RAID5/6-ot csinálsz. akkor eloszlik a seekelés a diszkek között...
sw raid6 alatt már borult a rendszer egyszer (IO terhelés miatt); ezért esett a választás a raid10 -re.
Esetleg akkor egy rendes hw-es raid vezérlőbe beruházni? Elég sokat tud számítani ha ki kell hajtani minden iops-ot.
Egy Areca ARC-1680ix-16 áll rendelkezésre. (Megjegyzem, aki a CLI -jét csinálta, while(true) l..ném fejbe)
Mi a baj a CLI interfészével? Szerintem inkább a webes felülete egy agyfasz.
Kidolt diszk eseten smart requestre segfaultol; raid set az nem raid, helyette a volume set a raid, whatever...
Sajnos mar kinlodtunk egy ilyennel anno; nem feher embernek valo...(itt is van valohol nyoma a HUP-on)
UPD: Hasonlítsd össze a 3ware tw_cli -vel...
Areca vezérlővel csak rossz tapasztalatok vannak, egy kártyavár stabilitásával vetekszik.
Én ugyanezt tudom mondani az LSI Megaraidekre. Szvsz mindegyiknek megvan az eléőnye és a hátránya is...
Én csak arra akartam célozni, hogy érdemes jó hardverbe befektetni. Sokszor inkább kispórolják a jóféle Raidvezérlőt a gépből, hogy utána egy borulás miatt többszörösét kifizessék.
Dolgoztam már olyan helyen, ahol a rendszergazdának olyan céges notebookja volt, amiből hiányoztak a csavarok és takarófedelek, néha futott a képernyő is. Egy-egy borulásnál az előbb említett hibák miatt nem egy új notebook árát bukták el. De már sajnos nem emlékszem, hogy hol volt :>
areca majdnem a legjobb az osszes kozul _szerintem_
Hát Windows Server alatt volt, hogy eltűnt az egész diszk alrendszer, de anno 5.1-es MySQL is meg-meg borult vele (bár az nem feltétlen az areca hibája volt) :)
Szerk.: Lehet, hogy konkrétan az az egy volt rossz széria, amivel próbálkoztunk.
Egy 1220-as már nálunk is elborult; reboot óta azóta is működik...:)
DB alá nem teszünk RAID5/6-ot - kivéve, ha nagyon sok(>~8) lemezünk van. Egyébként én is RAID5/6-ot szoktam ajánlani.
> DB alá nem teszünk RAID5/6-ot
De teszünk, ha van kellően sok komponensünk :)
De akkor is csak abban az esetben, ha az olvasás:írás arány 8:2 vagy még több az olvasás javára.
Két esetben teszünk:
- ha nincs apró, random írás (OLTP adatbázisoknál sajnos vannak)
- ha abszolút lényegtelen a performancia.
És természetesen a SW raid5/6, az nem raid, az csak a megbízhatóság csökkentésére alkalmas.
> És természetesen a SW raid5/6, az nem raid, az csak a megbízhatóság csökkentésére alkalmas.
Na, ezt most kinyomtatom A3-asban, és bekeretezve megy a falra :)))
Nekem jo tapasztalataim vannak az SW raid-del, linuxon. Egyszeruen menedzselheto, jo a teljesitmenye (plane a 8+ magos CPUk koraban, gyakorlatilag ugyse tudod leterhelni az osszes magot), es nem gond, ha kicsereled felette a vezerlot vagy a komplett rendszert, csak muxik tovabb.
És milyen marha jó is az a rengeteg alacsony szintű I/O...
2006 óta többször tesztelek sw raidet 3ware és LSI vezérlőkkel. Nem tapasztaltam eget verő különbséget. A HW raid javára pedig végképp nem.
Ennek ellenére, ha nem akarok látni 16 diszket az fdisk -l alatt, vagy blackbox jellegű OS kerül telepítésre, HW raid kerül felhasználásra.
De van, hogy 16 portos 3ware-n SW raidben vannak a vinyók, mert így dobott jobb teljesítményt. Kb mindig eljátszom a tesztet, de sosem győzött meg úgy komolyabban.
Igen, igazad van alacsony kihasználtság esetén. Csak amikor elkezdenek jönni a megmagyarázhatatlan hibák, mert az io teljesítmény elfogy, akkor jön a fejvakarás. A mai hagyományos rendszereknek(x86/x64) pont ez a legnagyobb bajuk: gyorsan elfogy az io. A nagygépek ebben is jobbak.
Na meg mondjuk számtalan olyan környezet van, amikor hw raid kell. Pl: ESX telepítés.
Nem ugyanezt írtam a >~8 kitétellel? :)
Jelenleg egy 6 diszkes (2.5") 1 unitos eszköz határozza meg a keretet; ezzel kell dolgoznom.
A session db külön szerveren van; +1 szerver InnoDB alapú adatbázist szolgál ki; ez a konfig pedig csak MyISAM alapu kiszolgálásra lesz.
Ez alapján egy raid10 és egy raid1 kerül be; binlog + rendszer a raid1; db pedig raid10.
Az OS raid1-nél mindenképp megfontolandó egy olcsóbb MLC SSD pár.
Miért? Az OS-nek nem hiszem, hogy akkora szüksége lenne az IOPS-re.
Igen, de a binlog is ott lesz...:)
Igen, de ha rendes BBWC van, akkor ez nem hiszem, hogy akkora gondot okoz.
Az ellen nem véd...:) Redundáns táp már talán jobban; két külön betápról.
Legalább az OS legyen fürge , ha már a DB nem az.:)
Ott várhatóan , az SSD-k túlélik a DB diszkjeit.:)
Ezeket az olcsó MLC SSD-ket ilyen céllal ajánlják a gyártók , és nem nagy írás terhelésű DB-k alá.
Az adatbázis alá az OCZ Vertex EX 120 GB-os SLC SSD-k valók , arany árában (1300$).
Arany ár? Akkor nézd meg az enterprise meghajtókat (deneva 2, talos 2)
Az bizony ,az arany gramm ára pont a duplája.:)
6 lemez, akkor gondolkodj 3 db raid-1-ben. Egyik tömb OS+DB szoftver, másik tömb db adat, harmadik tömb binlog. Így a rendszer eléggé kiegyensúlyozott lesz a párhuzamos olvasás-írás műveletekben. Pl: binlog írás nem tartja fel a data írást vagy a swapelés nem lassítja a db-ből az adat olvasást. Lemezhiba esetén gyorsabb a helyreállítás is ebben a felállásban.
A szimpla tükörbe rakott diszk miért jobb, mint a tükörbe rakott ssd? Van két slot, abból kell főznie a DB alá valami gyors storage-ot.
Ha jól olvastam, akkor nem 2, hanem 6 slot van. Továbbá a minőségi ssd drága + nehezen beszerezhető. Nem beszélve arról, hogy nagy teljesítmény esetén érdemes több tömböt definiálni más-más vezérlőre. Ezt 6 lemezzel meg tudja tenni, 2-vel nem.
Nem lenne jobb a session-öket memcached-ben tartani?
Történtek próbálkozások erre is, de a session eddig jobbnak tűnt db -ben (tmpfs + 2 replikalas); a repcached pedig még nem eléggé kiforrott.
Redis pedig elvérzett a bevezetés pillanatában.
A redis elverzeset ki tudod fejteni? Mit tapasztaltatok?
Konkrétan majd kollégám fogja tudni a részleteket, én csak a sűrű k.anyázásra emlékszem...:)
Meg fogom írni.
Hat igen aki nem tudja hasznalni annak nem valo. Sessiont DB-be tarolni jo nagy tervezei bug bar ez nalatok meno.
--
1 leszel vagy 0 élő vagy hulla!
Kifejtened, miert?
Erdekelne, hogy vajon hany szajbavert konneksont nyissunk egy tetves oldalletolteshez? (Ez nem a jozsikbt gumiaruhaza; )
Memcached van _normalisan_es_stabilan_ perzisztens konneksonnel php-hez? Nincs. (A memleakes verzio (memcache es memcached pecl extensionok) annyira nem erdekelnek)
Tehat:
Mivel te tudod hasznalni, kerlek, most oszd meg velunk, tudatlan halandokkal, vajon hogyan oldanad meg a dolgot (uzembiztosan, tehat replikalva, mivel fizetos a futo szolgaltatas egy resze).
Koszi elore is!
:D:D hat Ti vagytok a benak az tuti amugy semmi extra ficsor nem kell mert mukodik attol.
Amugy alexa ~TOP50 oldal alatt uzemel stabbilan. :)
Szoval a hiba bennetek van.
--
1 leszel vagy 0 élő vagy hulla!
Köszönöm, kb. ennyire számítottam.
Csinaljam meg helyeted vagy mit varsz?:D
--
1 leszel vagy 0 élő vagy hulla!
Igen, lécci, tetszettek a szakmai jellegű érveid :)
Ezen mit kell ervelni? Mukodik azon sok mindent sajnos nem lehet :(. De csak sirjal.
--
1 leszel vagy 0 élő vagy hulla!
Tudod, az a baj, hogy mondtál valamit, amit nem tudtál érvekkel alátámasztani.
Értem én, hogy az Alexa TOP50 oldalaknál ezt jól tudják használni, de nekem/nekünk még nem sikerült. Mivel @ságnak állítottad be ezt a részünkről (és nem kizárt, hogy igazad van), gondoltam, alá tudod támasztani; esetleg konkrét esettanulmányokkal, ez sajnos azonban nem sikerült. Pusztán szóbeszéd alapján migrálni egy szolgáltatást nagyobb @ság lenne a részemről, mint dedikált sql instance -ket használni session adatokhoz.
Nálunk a monitoring rendszer alá került SSD a mysqlnek elég nagy terhelése volt már, 4-6 load, majd 2 ocz vertex3 SSD raid1 ben azóta .5 load.
Kiváncsi leszek mert 97% ban csak írás történik kb 10e iops, hát elválik mikor hullik ki.
Randomban verhetetlen, szerintem 2 SSD + sűrű/jó backup és nagy gond nem lehet.
Raid10 lehet még esetleg 4-8 diskkel, de randomban nem lesz ott mint a 2 SSD.
Fedora 16, Thinkpad x61s
Ez mióta megy így?
Írás, vagy felülírás is van? (Mondjuk monitoring szervernél sok felülírás nem lehet...)
január 17. kb csak írás ugye, jelenleg a mysql táblában 115 milló sor van, kb 4G.
Ez tavaly január óta gyűlik, idén kapott SSD-t.
Fedora 16, Thinkpad x61s
Hmmm, reméltem, hogy minimum 12 hónapot írsz...:)
Az SSD elvileg számolja, hogy mennyi írás történt rá (Host Writes, a SMART-ban), az mennyi most? Itt a HUP-on egyszer linkeltek egy fórumot (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm/page160, ahol emberek nem csinálnak mást, csak folyamatosan írják az SSD-t, és mérik, hogy mennyi idő alatt hogy csökken a sebességük, állapotuk. Azzal a módszerrel pár TB-ot kibírnak. Azt mondjuk nem tudom, hogy ez adatbázis alatti használat esetén hogyan módosul.
Ilyen host writes ot nem találtam.
http://fpaste.org/MYzO/
Fedora 16, Thinkpad x61s
Ez alapján az F1 (241) mező (Total_LBAs_Written) értéke 20385 GB.
Az előző linkem alapján még egy darabig el tudna menni... (De kétszer sem biztos, hogy így lesz :))
Monitoring rendszer alatt mit kell érteni? Nagios? Vagy valami más de hasonló?
Centreon + nagios, Aircontrol, kvm-ben win2k3 alatt dude szerver, valamint IrMon az sflow adatokhoz.
Fedora 16, Thinkpad x61s
cegen belul mi betettunk ket raid1 be rakott intel ssdt az adatbazis server (es hardveres intel raid kartya) ala, es meglepoen jol birjak a strapat. Mivel az ssdk "faradaskor" nem hibazni kezdenek hanem lelassulnak, ezert az io wait novekedesen idoben eszre lehet venni ha az ssdk a veguket jarjak.
Az ultimate megoldas egy opensolarisos zfs ala bepakolt mysql server lenne ssdken (szigoruan raidz1 / 0 / 10 felhasznalastol fuggoen) mivel a zfs hacsak teheti nem ir ugyanarra a teruletre (pontosabban ciklikusan vegigmegy a merevlemezen az irasokkal, igy egyetlen szektort se farast el az ssdn) ... kar hogy ez linux alatt gyerekcipoben jar nagyon...
hint: static/dynamic wear leveling alacsonyabb szinten
Intel SSD-re +1.
6x 15k-s diszk vagy 4x SSD, de mindenképp RAID1+0 szerintem. Ha sok írás van, akkor rögtön +1 SSD-t rendeljetek biztos ami biztos alapon, hogy legyen a polcon is egy.
Mindenképp kell +1 alkatrészt tartanunk mindenből, így ez nem probléma.
Diszknél nem mindenki tart mert sokszor a géphez járó 4-6-8 órás reakcióidős garival számolnak. Szerintem attól függetlenül jó dolog a hidegtartalék a polcon. :)
Vasárnap éjjel 2kor elszállt már hdd...:)
Az laza, akkor már mindjárt hétfő :) Az igazi nyomor pénteken szokott beütni, lehetőleg olyankor, amikor már minden döntéshozó elérhetetlen, és természetesen jó esetben hosszú hétvége is jön :( Pl.: http://hup.hu/node/114048
Persze disket venni viszonylag hamar lehet, de a hibák nagyon leleményesek tudnak lenni :D
Átéltem veled együtt; ügyeletben voltam...:)
Az ISZT is természetesen ekkor szórakozott... és igen, volt ekkor diszk (pontosabban kontroller) hiba is...:)
IT életem egyik legszebb hétvégéje volt; első nap bekaptunk 3 FE -re is massziv DDoS -t.
24/7-es gariknál van ilyen reakció idő és ha hívod jönnek. :) Ha következő munkanapi (NBD) vagy egyéb garid van akkor nyilván musthave megfelelő számú coldspare.
subs
Az aktualis geprol egy `iostat -dk` es egy `uptime` sokat segitene
Nehany altalanos eszrevetel:
1) Ha fontosak az adatok, es a normal ugymenetnek nem resze aramszunet (vagy hasonlo disk energiaellatast erinto hiba) utan mentesbol adatbazist visszaallitani, akkor mersekelten celszeru olyan ssd, amelyben nincs power loss protection. Vagy ki kell kapcsolni az write cachet - de ilyenkor meg a normal diskeket is alulmuljak tipikusan az ssdk.
2) Az ssdk megbizhatosaga igen valtozatos:
http://www.hardware.fr/articles/862-7/ssd.html
Az sda,sdb és sdc mind hwraid (areca 1220); ebből az sda raid1+0; mind sata2 diszkekkel (nem véletlen vár cserére)
Ez gyakorlatilag a legalacsonyabb terhelésnél készült (kb. 400 belépett user+ a guestek, utóbbinál minimális az erre a szerverre jutó lekérdezések száma és ez esetben írás nincs)
Egyebkent caching reverse proxy is sokat tud dobni a betoltesi idon es mersekelni az adatbazis lekerdezesek szamat a backenden.
Pl. egy Varnish a weboldal ele valoszinuleg sokkal olcsobban tudna nektek eroforrast sporolni mint az SSD-k. Meg egy masszivan dinamikus weboldalnal is 10 masodperces cache expire mellett is latvanyos javulast lehet tapasztalni, mikozben az oldal dinamikus jellege megorzodik.
Hasznaltok valami hasonlot?
Az oldal teljesen dinamikus; soha egyetlen eleme sem ismétlődik (direktben) by design; Varnish -ról a legutóbbi tapasztalat a Guru meditation volt ennél az esetnél...:) (3 frontend van egyébként rotálva; php-fpm backendekkel)
.
Mekkora az adatbázis mérete? Mekkora a növekedési arány?
Adatbázis kiszolgalonak két dolog kell, cpu és memória, kivéve ha nagyon irasintenziv a használat, de ez most nem áll fenn. Ha a lekerdezeseket hattertarrol kell kiszolgálni, vagyis a db nem fér el a memoriaban akkor mindegy mit teszel alá.
120 GB; havi 1-2G növekedés; illetve:
Mindezt 16 G RAM mellett.
Az új gépbe különösebb extra nélkül tudtok 32 vagy akár 64GB memót is tenni, mert elég sok slot van már az alaplapokon és a modulok ára se vészes.
Így is lesz; ez van tervben (konkrétan 32 első körben)
Én 64 GB-ot tennék bele. Mi 2009-ben nem hasonlóan nagy méretű(20 GB) adatbázisszerverbe tettünk 48 GB-ot. Nagyon szerette az Oracle.
Tetszőlegesen sok memóriát szeretnek a db szerverek, főleg ha ekkora a DB. Azért írtam a 32/64-et, mert nem tudom mit enged meg a költségvetés, itt nyilván a minnél több, annál jobb. Ha dual xeonos gép akkor ráadásul 6-asával érdemes venni a modulokat, mondjuk 12x8GB-ot ami 96GB. Minden esetre érdemes lehetne a mysqltuner.pl -t is ráereszteni kezdetnek, hogy a buffer méretekre adjon tippet.
Már hogy lenne mind1 mit teszel alá. Mivel fel kell olvasni blockokat a diszkről nem mind1 milyen sebességgel teszed azt.
Ha csak a a redo logokat ki tudod tenni ssdre 10-15% teljesitmény növekedést jelentene. (oracle szinten a mysqlt nem ismerem de nagyot néznék ha ott ez másképp lenne.)
Láttál már méretesebb DB-t?
egyetertek ebben az elottem szoloval, ha lehetseges akkor mindenkeppen kell annyi memoria az sql serverbe mint amekkorak a leggyakrabban hasznalt tablak. Ellenben nagyon kell vigyazni, tapasztalataink szerint van egy mysql memoriakezelesi hiba (feltetelezem mysql, es ez a test ugy fel eve volt, nem vagyok benne biztos hogy meg megvan a hiba, de figyelni mindenkeppen erdemes) ami ha a mysql server max memoria cachet 8G fele rakod (akar egy kilobyte-al is), akkor jon elo. Drasztikus lassulast beragadt szalakat, akkumulativ modon csokkeno teljesitmenyt eredmenyezett nalunk.
Nalunk ezert valahogy ugy van, hogy 7.8G a mysql memoriacache, es a tobbi 24G linux disc cache.
Syslog-ng nem jó erre? Vagy ott is ioban fogy el a gép?
Adatok SAS HDD-ken raid10-ben, SSD-re cache kerulne.
Regebben nezegettem ezt, azota talan vannak ujabb tapasztalatok:
http://www.facebook.com/note.php?note_id=388112370932&_fb_noscript=1
Én használom és bevált (Flashcache).
Bármilyen blokkeszközre ráültethető transzparens módon.
Load negyedére, ötödére esett, amióta megy és szépen javítja a statisztikát azóta is.
Vertex3 van beüzemelve és nem ritka a 30k IO.
Elsőként azt kéne tisztázni, hogy milyen adatbázis?
---
http://youtu.be/mzycLGudWTw
Egy működő mysql (MYISAM) migrálásáról van szó tulajképp.