[eldöntve] SSD adatbázisszerverbe

( wladek1 | 2012. 05. 29., k - 19:00 )
Merevlemezek, vezérlők

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!

( elod v | 2012. 05. 29., k - 19:49 )

Intel drágább szériája? Az 520-ra gondolok.

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.

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

( n.balazs v | 2012. 05. 29., k - 20:35 )

É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.

É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 :>

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.

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.

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$).

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.

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!

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.

( _ventura_ v | 2012. 05. 29., k - 20:54 )

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

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.

( denke v | 2012. 05. 29., k - 22:02 )

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...

( andrej_ v | 2012. 05. 29., k - 23:40 )

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.

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

( handler | 2012. 05. 30., sze - 02:13 )

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 

server:~# iostat -dk
Linux 2.6.32-5-amd64 (server) 	05/30/2012 	_x86_64_	(8 CPU)

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             189.19       310.84       864.76  718813295 1999753872
sdb               0.59       169.39         0.77  391709338    1785788
sdc               0.53       169.39         0.77  391725403    1785788
md0               0.17         0.68         0.37    1571177     865620
md1               0.11         0.19         0.23     439228     541160


server:~# uptime
 06:41:40 up 26 days, 18:22,  1 user,  load average: 0.47, 0.23, 0.19

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)

( meepmeep v | 2012. 05. 30., sze - 03:49 )

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?

( freeoli v | 2012. 05. 30., sze - 08:38 )

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á.

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.)

( denke v | 2012. 05. 30., sze - 09:06 )

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.

( pityulaman1983 v | 2012. 05. 30., sze - 09:09 )

Syslog-ng nem jó erre? Vagy ott is ioban fogy el a gép?