Egy szerverbe tennék SSD-t. Napok óta azon töröm a fejem, hogy kell-e nekem a raid-1 vagy sem (szoftveres, mdadm).
Nem egyértelmű nekem, hogy mennyit dob az üzembiztonságon az SSD raid-1 a sima SSD-hez képest. Hátrányai viszont vannak:
- nincs TRIM, valószínűleg(*) lassabb
- kétszer drágább v. 1 db. kétszer akkora SSD sokkal gyorsabb
Szóval volt-e valakinek olyan tapasztalata, hogy az SSD-re húzott RAID-1 mentette meg a rendszert?
*: próbálom kimérni az otthoni SSD-men, eddig ellentmondó eredmények születtek.
- 25608 megtekintés
Hozzászólások
Meglátásom szerint függetlenül a lemez fajtájától a hibatűrő kiépítés alapvető fontosságú akkor, ha szolgáltatásban vállal részt a rendszer. Mindegy, milyen lemez, ha csak egy van belőle, ami meghal éppen, a rendszered le fog borulni. Mentés okvetlen kell, de az sem mindegy, vissza kell-e állni mentésből, és mikor, valamint mennyi idő alatt teheted ezt meg... Ezt a kérdést vizsgálnám én inkább...
/etc/lib/lu/plugins/lupi_bebasic
- A hozzászóláshoz be kell jelentkezni
"Mentés okvetlen kell ..."
Backup az van, helyben is, távoli szerveren is.
"... de az sem mindegy, vissza kell-e állni mentésből ..."
És pont ez az ami nem világos, hogy van-e reális esélye annak, hogy az egyik SSD feldobja a talpát, a másik meg állva marad, így megmentve a rendszert.
Hangosan gondolkozom: lehet két hasonló teljesítményű/méretű de külön márkájú és eltérő vezérlővel rendelkező SSD-ben kéne gondolkodni. Sajnos ez lerontja a teljesítményt, mert minden írás akkor lesz kész, amikor a lassabb SSD végez.
- A hozzászóláshoz be kell jelentkezni
Ssd-t beteszed rendszernek.Bekonfigolod utána mented.
Ha bedöglik kicseréled felhúzod mentésből és megy minden.Nem 99% rendelkezésre állás de szerintem bőven jó.
Hdd raid értelmesebb viszon az meg tárhely rovására megy.
- A hozzászóláshoz be kell jelentkezni
"bedöglik kicseréled felhúzod mentésből és megy minden"
Ne haragudj, de ez az otthoni nas fölött már nem megengedhető, főleg nem pénzkereső eszköznél amire majd nagyon sokan fognak várni ha Te éppen még húzogatod a dolgokat...
- A hozzászóláshoz be kell jelentkezni
"Egy szerverbe tennék SSD-t. Napok óta azon töröm a fejem, hogy kell-e nekem a raid-1 vagy sem (szoftveres, mdadm).
Nem egyértelmű nekem, hogy mennyit dob az üzembiztonságon az SSD raid-1 a sima SSD-hez képest. Hátrányai viszont vannak:
- nincs TRIM, valószínűleg(*) lassabb
- kétszer drágább v. 1 db. kétszer akkora SSD sokkal gyorsabb
Szóval volt-e valakinek olyan tapasztalata, hogy az SSD-re húzott RAID-1 mentette meg a rendszert?
*: próbálom kimérni az otthoni SSD-men, eddig ellentmondó eredmények születtek."
Itt hol írja hogy nem otthoni NAS ba kell neki.Szevasz nem kell kirohanni.
"Nem 99% rendelkezésre állás de szerintem bőven jó."
Itt nem írtam hogy éles produce rendszernek ajánlot..Szal még mindig nem értem.
- A hozzászóláshoz be kell jelentkezni
"Egy szerverbe tennék" <--- itt
/etc/lib/lu/plugins/lupi_bebasic
- A hozzászóláshoz be kell jelentkezni
NAS az nem szerver, jah várj server csak produce server lehet értem az más.
Nem kell okoskodni.
- A hozzászóláshoz be kell jelentkezni
"csak produce server lehet"
Ouch.
- A hozzászóláshoz be kell jelentkezni
Na, hát az egy terméskiszolgáló. Ott van benne a mindenféle zöldség meg gyümölcs, és azokat szolgálja ki kliensek számára...
Hol itt a gond? ;-)
- A hozzászóláshoz be kell jelentkezni
Like gyumolcstarhely? :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. - A hozzászóláshoz be kell jelentkezni
Bocsi, nem kell kirohanni, de a kiszolgálókra is igaz ami a sörre is, vagyis ha csak egy van, az olyan mintha nem is lenne.
- A hozzászóláshoz be kell jelentkezni
Nah azért mindjárt más.
1sör nem sör.2sör fél sör....
De az igazi produce környezetbe szánt raid igazán 5-10nél kezdődik.
- A hozzászóláshoz be kell jelentkezni
Elég az 1 is, mindig a célhoz kell méretezni. Backup meg minimum 2. Legközelebb szerverhez ne a gány minimumot ajánlj, a végén még megfogadja valaki. ... Egy régi munkahelyemen mielőtt odakerültem egy új sbs kiszolgáló megrendelése a vez ig elé került, aki meglátta, hogy 2 hdd lett beírva, nagyokosan az egyiket gyorsan kihúzta, majd jött a vas, anyu meg csuklott..
- A hozzászóláshoz be kell jelentkezni
Tegyük Off-ossá a hozzászólásomat, mert nem akarok hitvitát indítani. De szerintem meg a HW RAID-nél kezdődik... ;)
- A hozzászóláshoz be kell jelentkezni
A vicces az hogyha csak 99%-os rendelkezesre allast celzol, az meg akkor is eves szinten 3.65 nap lehetseges kimaradast jelent. Ebbe akar full reinstall is belefer (akar meg 5x is)
- A hozzászóláshoz be kell jelentkezni
> És pont ez az ami nem világos, hogy van-e reális esélye annak, hogy az egyik SSD feldobja a talpát, a másik meg állva marad, így megmentve a rendszert.
Miert merul fel benned, h nincs?
> lehet két hasonló teljesítményű/méretű de külön márkájú és eltérő vezérlővel rendelkező SSD-ben kéne gondolkodni.
Bizonyos korulmenyek kozott ez alap.
Ez a tema nagyreszt fuggetlen az SSD-ktol.
tompos
- A hozzászóláshoz be kell jelentkezni
Nyilván van erre is ipari best practice és/vagy gyártói ajánlás. Csak a saját hobby-rendszeremen használok ilyen megoldást, ott is csak saját kútfőből, de eddig nincs bajom vele. Elhiszem a ZFS-nek, hogy a megfelelő módon kezeli a lemezeket; adott körülmények között elég nekem ennyi - menni pedig megy szépen. Nálam egyébként pont úgy adódott (hangsúlyozom, hogy nem tudatosan/szándékosan), hogy a két lemez gyártástechnológiája és tárolókapacitása egyaránt eltér, noha a gyártó ugyanaz. Ez további következtetések alapjául is szolgálhat, amennyiben valamelyik feladja majd, de jelenleg works as designed. Nem nevezném követendő példának, de egy általános példának elmegy ez is.
/etc/lib/lu/plugins/lupi_bebasic
- A hozzászóláshoz be kell jelentkezni
Szóval te ZFS-t használsz SSD-ken? Vajon így használja a TRIM-et? MLC vagy SLC lemezeket használsz? Mi a tapasztalatod vele?
- A hozzászóláshoz be kell jelentkezni
Így van. A TRIM-ről nem tudok nyilatkozni; nem foglalkoztam vele eddig. Mindkét típusból van a gépben; eddig nem észleltem problémát egyikkel sem - mi több, ahogy fentebb említettem, az rpool alatti tükör még ilyen tekintetben is hibrid. Jelenleg az NC360T kártya e1000g driverével küzdök; ZFS problémám mindezidáig nem adódott.
UPDATE: utánanéztem, néhány hónapja a helyzet úgy állt: a lemezkezelés már egy ideje igen, de a ZFS nem tudta, de nem nyomoztam komolyabban az azóta beállt esetleges fejleményeit.
/etc/lib/lu/plugins/lupi_bebasic
- A hozzászóláshoz be kell jelentkezni
flashcache a kulcsszó.
nekem nagyon bejött eddig, bár csak pár hete használom.
facebook is ezt használja, nagyon szar nem lehet :)
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
még egyszer mondanám: flashcache writethrough módban, és az adataid biztonságban vannak (100%)
ha writeback mód, akkor a biztonság kisebb de az írás is cachelve van
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Köszi, lehet, hogy nekem kell majd, de még elfér minden ramban.
- A hozzászóláshoz be kell jelentkezni
Mi van abban az esetben ha ugyanúgy meghal az 1 db SSD amire a FlashCache dolgozik?
- A hozzászóláshoz be kell jelentkezni
bocs, de pont kihangsúlyozta a két módot, mit nem értettél belőle?
- A hozzászóláshoz be kell jelentkezni
Szerintem nem egyértelmű, hogy mi van ha kiesik az SSD.
A flashcache 3 módban tud dolgozni, a különböző módok azt szabályozzák hogy írás esetén mikor/milyen módon kerüljön az adat a HDD-re. A "writethrough" esetén mindig minden írás a HDD-re történik, majd onnan visszaolvasva az SSD-re. (ebből adódik, hogy az SSD-k gyors írási képessége így gyak. nem létezik).
Viszont a fentiek semmit nem mondanak arról, hogy mi történik ha mondjuk kiég az SSD elektronika, vagy elkezd hibás adatokat visszaadni.
- A hozzászóláshoz be kell jelentkezni
Processzorból is kettő különbözőt teszel a gépekbe, amiből az egyik ellenőrzi a másikat?
A HDD raid azért terjedt el mert a HDD fizikai meghibásodása egy gyakori probléma. Ha olyan magas üzembiztonság kell, hogy az elektronika hibáját is eltűrd, akkor oda két gépet kell felállítani, mert tönkremehet éppen a hálókártya vagy az alaplapi busz is...
- A hozzászóláshoz be kell jelentkezni
Ha létezne olyan szerver (nem tudom van-e ilyen) ami tovább tud működni akkor, ha megsül egy CPU, és egyszerre tudna kezelni különböző CPU-kat, akkor igen, lenne értelme különbözőket beletenni. Szerintem.
Flashcache: amit a flashcache és a writethrough mód működéséről írtam, az nettó hülyeség. Akit érdekel, hogy működik, az olvassa el a leírásokat, az a tuti:
https://github.com/facebook/flashcache/blob/master/doc/flashcache-doc.t…
https://github.com/facebook/flashcache/blob/master/doc/flashcache-sa-gu…
- A hozzászóláshoz be kell jelentkezni
Nempécé kategóriában van ilyen: minden műveletet több cpu hajt végre, komparátor a kimenetre, ha azonos jó, ha nem, akkor újra, ha akkor sem, akkor egy másik párosra átpakol mindent, az aktuálisat meg kukázza, és beszól a supportnak, hogy hiba van, jöhetnek cserélni.
Mondjuk megsülni csak akkor sül meg egy félvezető, ha megdöglik a hűtés. Normális szerverekben minimum redundáns, monitorozott fordulatszámú ventilátorok vannak, bónuszként ha nagyon melege van, a megsülés előtt leállítja magát a gép, ergo megsülni nem igazán tud, legfeljebb többszörös hiba esetén.
- A hozzászóláshoz be kell jelentkezni
Nempécé kategóriában van ilyen
Úgy hívják, hogy repülőgép. :)
Viccet félretéve, valóban van ilyen mainframe-ben is, nemcsak beágyazott rendszerekben csinálják.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Az utóbbira gondoltam :-)
- A hozzászóláshoz be kell jelentkezni
Meg volt olyan is, hogy Netra ft 1800 :)
- A hozzászóláshoz be kell jelentkezni
A két módból egyértelmű kellene hogy legyen számomra hogy a működését a FlashCachenek hogyan befolyásolja ha kiesik az SSD amit használ?
- A hozzászóláshoz be kell jelentkezni
Milyen környezetben használod?
Én Linux alatt 3 megoldást nézegettem "SSD-vel gyorsítjuk a HDD-t" témakörben:
- flashcache
- bcache
- zfsonlinux zil + l2arc
Nyilván ez eléggé almát krumplival összehasonlítás, de végül a ZFS mellett döntöttem, mert bár az is experimentalnak tekinthető Linux alatt, a többi feature kárpótol valamelyest, és nagyon kényelmes "apt-get install" módon telepíthető. Mielőtt Linux + zfs lett, próbáltam FreeNAS-t. Ugyanazon a HW-n a Linuxos ZFS sokkal gyorsabban muzsikált nekem, ráadásul a FreeNAS-ban régebbi a ZFS, és pl. ZIL eltávolítás emiatt nehézkes ott.
A célgép egy HP N40L MicroServer, 4 HDD + 2*60GB SSD. A 2 SSD így van partícionálva:
10 GB system, mdadm RAID 1 a 2 SSD
16 GB ZIL, mirrorként hozzáadva a poolhoz (állítólag elég kevesebb is, de inkább lötyögjön benne az adat mint kevés legyen)
maradék, L2ARC nem tükrözve hozzáadva.
Teljesítményben ugyanazt hozza, mint a NexentaStor itt: http://blog.xorp.hu/hp-microserver-es-nexentastor
Megbízhatóságról nem nyilatkoznék, még tesztüzemben megy, eddig leállás nem volt.
Üdv,
Gergely
- A hozzászóláshoz be kell jelentkezni
> Szóval volt-e valakinek olyan tapasztalata, hogy az SSD-re húzott RAID-1 mentette meg a rendszert?
csak olyan friss elmenyem van, ahol ennek hianya boritotta be. szoval ha csak a raid1-nemraid1 között kene döntenem, elöbbit valasztanam.
- A hozzászóláshoz be kell jelentkezni
Fontos lenne definiálni, hogy:
Mi a cél az adott kiszolgálóval?
Miért is kiszolgáló az adott gép?
Miért kéne SSD HDD helyett?
RAID1 minimum mindenképpen.
Brand server mindenképpen.
HW raid mindenképpen.
A TRIM működni fog.
- A hozzászóláshoz be kell jelentkezni
Ha azt hiszed, hogy az SSD megbízhatóbb, mint a HDD, akkor ki kell ábrándítsalak. Innentől kezdve, az SSD-alapú RAID1-nek pont ugyanakkora a létjogosultsága, mint a HDD-s RAID1-nek.
- A hozzászóláshoz be kell jelentkezni
En azt hiszem ertem mi a problemaja.
SSD-nel sokkal konnyebben elofordulhat, hogy 2 egyforma darab pont egyszerre doglik meg, mint HDD-nel.
Egyreszt, determinisztikusabban "kopik" a flash, mint a mechanika, ugyanazzal az irasi terhelessel nagyjabol egyszerre fognak az eletuk vegere erni.
Masreszt a gyakorlatban az SSD elhalalozasok tulnyomo tobbsege nem a flash kikopasa, hanem firmware bug miatt tortenik, az meg valoszinuleg tokeletesen pontosan egyszerre fog triggerelodni mindket peldanyon, ha ugyanazokat a parancsokat kapjak.
Tehat igen, szerintem van ertelme ket kulonbozo gyarto SSD-jebol epiteni RAID-1-et.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Ennek tolok egy +1-et.
- A hozzászóláshoz be kell jelentkezni
Így van, tulképp erre gondoltam én is.
- A hozzászóláshoz be kell jelentkezni
Igen, de a FW bug esetére jó a flashcache is, nem? Én egy FW hibáról tudok, ott áramszünet után eltűnt a fájlrendszer az SSD-ről. Szerintem az olyan fajta hibákat flashcache-sel (vagy hasonlóval) ki lehet védeni.
Tud valaki egyáltalán olyan FW hibáról, amelyik miatt normál üzemben (azaz nem áramszünet után) pusztult el az SSD? Mert arra tényleg nem lenne jó a flashcache.
- A hozzászóláshoz be kell jelentkezni
+1 okos gondolat, köszönöm!
- A hozzászóláshoz be kell jelentkezni
"Masreszt a gyakorlatban az SSD elhalalozasok tulnyomo tobbsege nem a flash kikopasa, hanem firmware bug miatt tortenik, az meg valoszinuleg tokeletesen pontosan egyszerre fog triggerelodni mindket peldanyon, ha ugyanazokat a parancsokat kapjak.
"
Nagyon jó meglátás, ez egy nagyon hasznos gondolat, adom a +1-et
- A hozzászóláshoz be kell jelentkezni
Mindenképpen javasolnám a RAID1-et, legalábbis saját szerverben semmiképpen sem tennék másképp.
Minden további nélkül előfordulhat, hogy megadja magát egy SSD de ekkor a RAID1 teszi a dolgát, a szerver egy pillanatra sem áll le, gond nélkül megy tovább a másik SSD-ről.
- A hozzászóláshoz be kell jelentkezni
OKé, látom egyöntetű a vélemény a RAID1 mellett, akkor is ha lassabb. Szerintetek érdemes két külön típusú SSD-vel megoldani, vagy jó az azonos is, és az egyiket "bejáratom" néhány napig előtte.
gabrielakos: a flashcache már nekem is ezsembe jutott, de még nem mélyedtem el benne. Azt be lehet lőni szoftveres RAID1 HDD-k elé is (1 SSD cache és 2 HDD raid1-ben)?
- A hozzászóláshoz be kell jelentkezni
Mindenképp jóféle SSD-t válassz. Ha Linux vagy BSD és software RAID-el tükrözöl, akkor simán add hozzá 2-3-4 héttel később a második diszket. A normálisabb SSD-ken van egy Wear Leveling Count (ez speciel a Samsungon van), ami megmondja hogy a P/E ciklusokból épp mennyinél tart.
--
Apache Solr Druplahoz és Wordpresshez: http://solr.vpspro.hu
- A hozzászóláshoz be kell jelentkezni
Minden további nélkül mehet két azonos, még az sem baj, ha nagyon hasonló az SN#.
Nagyon-nagyon kicsi az esélye, hogy a két eszköz pontosan egyidőben megy majd tönkre.
Amit viszont tényleg érdemes lenne: tartani egy tartalék SSD-t a fiókban. Tudom, drága. De tuti, hogy mikor gyorsan cserélni kéne, biztos nem lesz azonnal elérhető: hétvége van, nincs raktáron, pont elfogyott, stb...
- A hozzászóláshoz be kell jelentkezni
Az első részével (kicsi az esély, hogy pont egyszerre megy tönkre) nem értek egyet.
Már HDD-nél is mindig úgy építettem RAID-et, hogy legalább különböző időben, külön boltból vettem a winyót. Gondold el: bemész a boltba, kérsz két winyót. Eladó hátrafordul, a polcról leemel kettőt. Fizetsz, hazaviszed, örülsz. De ez a két winyó valószínűleg egy csomagban jött, egy szállítmánnyal, egy gyárból, egy futószalagról, ugyanazon forrásból származó nyers alapanyagok felhasználásával készült. Közben a szállításnál egymás mellett voltak, ugyanaz a sugárzás/rázkódás/stb érte őket. Majd fogod és beteszed egy raid1-be, ahol bitre ugyanazokat az adatokat kell ki/be olvasniuk (minimális eltéréssel, a superblock-ok eltérőek). Igen, szerintem nagyon is megdobják az egyszerre meghibásodás esélyét a fentiek.
A neten sok ilyen sztori van, főleg raid5 esetén, ahol N winyóból (N sok, akár 6-8, vagy mégtöbb) egy kiesését elviselné még a rendszer, mégis gyakran kiesik a második, sőt akár 3. is.
- A hozzászóláshoz be kell jelentkezni
+1
Én is láttam már egyidős winyókat gyakorlatilag egyszerre meghalni, 12 egyforma gépből 8 olyat aminek pár hét eltéréssel halt meg a tápja, 14 monitorból olyat amiből kettő él már csak a többi pár hónap alatt sorra megdöglött, stb....
- A hozzászóláshoz be kell jelentkezni
Ha mar van egy het elteres a ket halal kozott, akkor nem egyszerre tortentek. Az egyszerre ebben az esetben azt jelenti, hogy egyazon napon.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Az egyszerre ebben az esetben azt jelenti, hogy egyazon napon.
Pontosabban a RAID tömb újraépítésének idején belül.
- A hozzászóláshoz be kell jelentkezni
Ha itthon veszel vinyót kb. ugyanakkor akkor marhára jó esélyed van hasonlóak megvételére, hacsak nem raktárról jön. Szervervinyóknál a raktárkészlet elég ismeretlen fogalom itthon, ha meg van, akkor A és B bolt is ugyanabból a nagykerből fogja neked hozni. Elég sok vinyóval és RAID tömbbel találkozom nap mint nap és teljesen véletlenszerűen jönnek diszk halálók, amik egyébként bőven nem olyan sűrűek, mint ahogy várnám. Például van olyan SCA diszkünk üzemben ami már 65e óra felett jár és nem unatkozik és volt olyan 600GB-os 15k-s SAS diszk, ami egy év után kidölt a 9 hasonló mellől.
A rendes mentést semmiképpen sem úszod meg, csak a rendelkezésre állást tudod növelni mondjuk RAID6-al vagy hot/coldspare második szerverrel. A RAID5 vs. RAID6-nál ha sok diszk van, akkor inkább a RAID6-ot ajánlják, mert tömb újraépítéskor nagyobb az esélye egy második diszk kihalásának.
--
Apache Solr Druplahoz és Wordpresshez: http://solr.vpspro.hu
- A hozzászóláshoz be kell jelentkezni
anno volt olyan nekünk, hogy 8bol (2x4 raid5) 5 halt meg egy hetvegen :)
- A hozzászóláshoz be kell jelentkezni
<troll>
Ezért kellett volna RAID1-e húzni mind a nyolc winyóra, akkor akár 7 is kieshetett volna :D
</troll>
- A hozzászóláshoz be kell jelentkezni
+1 :D
/* Signature
while true; do echo -e "cat your_reply > /dev/null"; done;
Signature */
- A hozzászóláshoz be kell jelentkezni
utana par nappal kiesett meg 2, szoval eletszerü is lett volna az ötlet :)
- A hozzászóláshoz be kell jelentkezni
Na akkor képzeld el azt a szituációt, hogy 8-an vannak raid1-ben, és sorban mind a 8 elpukkan... Szerintem a diszkfarm gazdája simán szívinfarktust kapna :D
- A hozzászóláshoz be kell jelentkezni
Be lehet. Tulképp nem más, mint a device-mapper infrastruktúrában még egy réteget "húz" a diszkek elé.
Maga a "flashcache device " is lehet egy raid akármi (persze raid 0 is :) ) tömb, amit a másik device (tipikusan egy md) elé húzol.
Nálam a vm-ek klónozásának idejét kb. tizedére csökkentette, mindezt úgy, hogy a rendszer persze teljesen reszponzív maradt. Gyakorlatilag lassúzik az ssd, mert a 4 sata diszk raid10-ben nem bírja azt a tranzakciós sebességet amit emez tudna. Mondjuk egy OCZ Vertex4-ről van szó, szóval nem gagyi :)
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Köszi az infókat, egyre inkább hajlok a flashcache megoldás felé. Azt még meg tudnád mondani, hogy van-e valami eszköz/tool amivel azt tudod ellenőrizni, hogy az ssd mérete mennyire van kihasználva? Mondjuk valami hit/miss arány amiből látod, hogy elbírna egy nagyobb SSD-t is.
- A hozzászóláshoz be kell jelentkezni
Ilyen van:
dmsetup status cachedev
0 293601280 flashcache stats:
reads(100203238), writes(21143227)
read hits(85554886), read hit percent(85)
write hits(15052800) write hit percent(71)
dirty write hits(1893242) dirty write hit percent(8)
replacement(96681), write replacement(781635)
write invalidates(0), read invalidates(1)
pending enqueues(57326), pending inval(57326)
metadata dirties(19195486), metadata cleans(19982901)
metadata batch(36369382) metadata ssd writes(2809005)
cleanings(19982895) fallow cleanings(818380)
no room(164) front merge(17046867) back merge(1613826)
disk reads(14648695), disk writes(20037533) ssd reads(105537785) ssd writes(38543554)
uncached reads(2858), uncached writes(54632), uncached IO requeue(0)
uncached sequential reads(0), uncached sequential writes(0)
pid_adds(0), pid_dels(0), pid_drops(0) pid_expiry(0)
Általában nem a nagyobb ssd a kérdés, hanem a flashcache "aggresszivitásának" tuningolása, de ehhez még nem értek eléggé, teljesen alap beállításokkal használom. Futás közben az iostat figyelése mutatja gyönyörűen, hogy mikor "dolgozza ki" az ssd az adatokat ténylegesen a diszkre.
Itt pl:
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 39.20 0.00 3209.60 0 16048
sdb 39.00 0.00 3209.60 0 16048
sdc 36.60 0.00 3174.40 0 15872
sdd 38.20 0.00 3174.40 0 15872
sde 147.40 4923.20 17753.60 24616 88768
látszik, hogy az sde az ssd, és miközben kapja az ívet a filerendszer, szépen tolja ki a diszkekre (kicsit lassabban mint ahogy lehetne, mert 80 tps-t is bírnának a diszkek, de csak 40-et tol) de amit kap azt meg írja fel magának, bőven többet mint amit a diszkek valaha is tudni fognak.
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
gabrielakos: köszi az eddigi infókat, most már nagyon úgy néz kis flashcache lesz, de kérdés még foglalkoztat.
Melyik módban használjátok a 3 közül (back, thru vagy around)? CPU-t mennyire zabálja, vmi overhead biztos van. Esetleg nem próbáltad ki az SSD-t önmagában mit tud és ez milyen viszonyban van azzal amit a flashcache tol ki magából?
- A hozzászóláshoz be kell jelentkezni
Az az adat, ami egy eszközön van meg, az nincs meg. Neked kell eldöntened, hogy mennyit állhat a cucc, mennyi az az idő, aminek az adatai elveszhetnek - ha nem lehet sokat ácsorogni, nem veszhet el mondjuk egy napi változás, akkor kell a raid. Ha elég az, hogy a tegnapi állapotra bármikor vissza tudsz állni, miután beraktál egy új SSD-t a régi, döglött helyére, akkor csak az a kérdés, hogy a mentés napi teljes legyen-e (ekkor gyorsabb és egyszerűbb visszatölteni, ellenben naponta sok adatot kell ki/áttolni a mentőeszközre/másik gépre), vagy x naponta teljes, közben pedig inkrementális mentés is jó.
Természetesen a mentés is adat, tehát ha egy eszközön van meg - akkor nincs meg :-D
- A hozzászóláshoz be kell jelentkezni
kicsit offtopic kerdes: mdadm attolja mar a TRIM-et? LKML-t nezegettem, de nem talaltam friss infokat, se kernelnewbieson.
van egy uj jatszos gepem SSD-s RAID10-el, jol megy, de azert nem bannam, ha lenne TRIM.
- A hozzászóláshoz be kell jelentkezni
Hivatalos infót nem találtam, 3.2-es kernellel próbáltam, az még nem viszi át TRIM-et.
Vicces volt kisakkozni :) A házi SSD-mre két partícióra raktam raid1-et, majd teleraktam a winyót 0xFF-el. hdparm-mal keretem pár sectort, ahol látszik a csupa 1111. Majd töröltem az adott fájlt. Mivel nem tűntek el az 1111-ek, ezért nincs trim. Hasonló módon ext4-en eltűnnek az 1111-ek.
- A hozzászóláshoz be kell jelentkezni
Egyébként a trim-nél előírászerűen azonnal "el kell tűnnie" az adatnak (értsd: az SSD kontroller csupa 0x00-kat vagy 0xff-eket kell, hogy visszaadjon, függetlenül, hogy fizikailag mi van a flashen), vagy egyszerűen csak nemdeterminisztikus, hogy mit ad vissza, ha ráolvasunk (akár az eredeti adat is lehet)?
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Az SSD-k nem fizikailag nem tudják felülírni az adatot, csak akkor ha 0x00 van a flash memóriában. És sajnos a legkisebb átírható egység elég nagy, általában 512Kib. Ezért felülíráskor nem oda írják vissza ahonnan olvasták, hanem keresnek egy üres helyet. Így sokkal gyorsabb, mert megspórolják a törlést. De az üres helyek elfogynak, mert nem régi verziót nem törlik le, hanem otthagyják a szemetet. Erre jó a TRIM, üresjáratban gyorsan nullázza a régi pozíciót, hogy aztán gyorsan bele lehessen írni.
Tehát igen, 0x00-át kell visszaadjon a kontroller. Itt egy jó cikk, amiben le van írva hogy lehet tesztelni:
http://askubuntu.com/questions/18903/how-to-enable-trim
Csak sajnos ez raid fölött nem ilyen egyszerű, mert a hdparm -i nem tud egy fájlhoz sector számot mondani. Ezért kell kell egy 0xff-es fájlllal teleírni a winyót, akkor próbálgatva könnyű találni sectort.
- A hozzászóláshoz be kell jelentkezni
Igen, tudom, hogy hogyan mukodik az SSD belul. Az viszont szerintem nem feltetlen igaz, hogy a TRIM muvelet hatasara azonnal vagy legalabbis zaros hataridon belul fizikailag torlodik a regi pozicion levo adat. Csak valami belso page tablaban feljegyzi a kontroller, hogy az ott levo szemetet nem kell megmenteni, amikor legkozelebb indokolt lesz a teljes erase block torlese, de ez lehet, hogy csak nagyon sokara tortenik meg. Amig van ures hely _vagy_ van masik kevesebb irasi ciklust kapott torlerse kijelolt blokk, addig nem fogja bantani. Egyebkent lehet, hogy te is erre gondoltal, csak a mondataidbol nem volt egyertelmu.
A kerdes arra vonatkozott, hogy egeszen biztos-e, hogy a kontroller firmware "elrejti" az esetleg fizikailag meg ott levo szemetet az olyan blokkokbol, amire TRIM-et adtunk ki, vagy elofordulhat, hogy megis lathato marad a szemet a host felol? Nem szuksegszeru, hogy az elobbi legyen, bar ketsegkivul igy lenne korrekt. Amilyen szir-szar firmware-ek forognak a piacon, nem mernek merget venni ra, hogy nem tudsz olyan tipussal osszefutni, amelyik igenytelenul implementalja a TRIM utani READ-et.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Én úgy tudom hogy a flash memóriára ráírni nem lehet, előtte fizikailag törölni kell. Ergó fel sem merül, amit kérdeztél.
Biztosat egy típusról tudok állítani: Intel X25-M G2. Itt a TRIM után biztosan 0x00 jön vissza. Egészen pontosan így teszteltem:
rm randfile && hdpram --read-sector 123456789 /dev/sda && sync && hdpram --read-sector 123456789 /dev/sda
Ez az első sector kiolvasásra még visszaadta a random értékeket, sync után már 0x00 jött.
- A hozzászóláshoz be kell jelentkezni
Ilyet láthatsz akkor is, ha az XMI által leírtak szerint működik az SSD...
--
zsebHUP-ot használok!
- A hozzászóláshoz be kell jelentkezni
http://thread.gmane.org/gmane.linux.raid/39660 ?
csak talaltam, nem tudom, mi lett a sorsa vegül.
- A hozzászóláshoz be kell jelentkezni
Igazából vissza a kályhához.
Milyen kiszolgálón miért szeretnél gyorsítani ssdvel? Milyen kiszolgálást végzel rajta? Virtualizálnál? Lamp? Db? Cache? Proxy? Smb?
Nagyon nem biztos, hogy az ssd az ami kell neked a célhoz.
- A hozzászóláshoz be kell jelentkezni
Ez már egy meglévő szerver, a CPU magok unatkoznak, a 8GB ram 3/4 csak file cache-re van használva, viszont az MySQL InnoDB műveletek elég lassuak. Ráadásul a winyók már öregek is, így mindenképpen megértek a cserére.
Nagyon köszönöm mindenkinek a tanácsokat, azt hiszem most már fogok tudni dönteni.
Sok lehetőséget felvázoltam magamnak:
a) 1 db. SSD
b) 2 db. SSD RAID1-ben
c1) 2 db. HDD RAID1-ben 10K Velociraptorokkal
c2) 2 db. HDD RAID1-ben 7200-as normál winyókkal
d) Flashcache (1 SSD + HDD RAID1-ben)
Majd felírtam mindegyiknél, hogy
- gyors-e (ssd igen/hdd nem/raptor közepes)
- megbízható-e (raid1 van/nincs)
- nagy tárkapacitás van-e (normál hdd igen/ssd és raptor nem)
- mennyibe kerül (saját zsebre megy a játék, nem más pénzét költöm)
A Flashcache tetszik a legjobban, mert ez az egyetlen, ahol mind a 4 paraméter adott. Elég olcsó a kiépítése is: ha a háttérben egy jó RAID1-es HDD pár ül, akkor elé akár a leggányabb SSD-t is be lehet tenni. Ha kiesik az SSD minimális config állítgatással és 1 reboot-tal azonnal át lehet állni a HDD RAID1 párosra.
A flashcache egyik hátránya lehet, hogy nem elég érett. Mondjuk cukorhegy elég sok gépen futtatja. Igaz, náluk nem akkora gond egy adatvesztés.
A flashcache másik hátránya, hogy új tekknologia, amit tanulni kell.
Rövid távra szimpatikus még az a) opció is, mert b)-re és d)-re is továbbfejleszthető.
Most ott tartok, hogy a Flashcache-t próbálom VirtualBox-ban összehegeszteni. Nem vagyok egy device mapper/mdadm/initramfs/grub guru, így egyelőre elakadtam. Ha nagyon nem megy, majd kérdezek.
Mégegyszer köszönöm mindenkinek a segítséget!
- A hozzászóláshoz be kell jelentkezni
Ha a buherálás mellet döntöttél, akkor esetleg nézd meg a bcache-t is:
http://bcache.evilpiepirate.org/
Van Flashcache vs bcache összehasonlítás is a lap alján.
Szerk: Persze ez még inkább experimental mint a flashcache.
Üdv,
Gergely
- A hozzászóláshoz be kell jelentkezni
Nezd meg a mysqltuner.pl-el, hogy mit ajanl az innodb-hez es 3-4 nap mulva ujra. Ha ennyire csak cache-el a memoria, akkor tuti lesz mit ugykodni. Ha nem hasznalod az innodbfilepertable opciot akkor erdemes atallni arra is.
Ha megtobb kraft kell es nem bizol az ssd-ben, akkor vennek egy 4 portos sas hba-t es Raid1-be vagy raid 1+0-ba kotnek 10 vagy 15k-s vinyokat, amik akar hasznaltak is lehetnek.
--
Apache Solr Druplahoz és Wordpresshez: http://solr.vpspro.hu
- A hozzászóláshoz be kell jelentkezni
Szerintem a SSD jobb megoldás :>
Nekünk a monitorozó szerver alatt 4G ram dual QC xeon meg 2 db 15k rpm sas disk volt.
Volt már mikor 15 másodpercig is generálta a weboldalt. mysql adatbázisában 115 millió sor van. Cseréltem 2 db 128G-s OCZ vertex-re raid1-ben. Azóta az oldal generálás. 0.1-0.3 másodperc. Többszörösére gyorsult. Szóval inkább 2 SSD mint 4 db SAS szerintem.
Fedora 16, Thinkpad x61s
- A hozzászóláshoz be kell jelentkezni
Lásd a "ha az ssd-ben nem bízol" kitételt. :) Az SSD viszont elég hamar le fog fáradni, ha sokszor újrageneráltok vele ilyesmit. Minden esetre mielőtt MySQL ügyben bármerre indul valaki tényleg érdemes a mysqltuner.pl -el megnézni, hogy mi a helyzet, mert aztán csodálkozás jön fejlesztés után is.
--
Apache Solr Druplahoz és Wordpresshez: http://solr.vpspro.hu
- A hozzászóláshoz be kell jelentkezni
Az igazság az, hogy sw oldalon bőven van mit optimalizálni, nem csak a mysql-nél hanem a két fő alkalmazásban is bőven van még tartalék.
De először a HW-t akarom rendbetenni, mert a mostani két HDD már tényéeg nagyon csereérett, és egyértelmű hogy az IO a szűk keresztmetszet.
A mysqltuner-t ismerem és használom, de vetek rá egy újabb pillantást, néha tényleg 5-10 perc "munkával" csodákat lehet elérni.
Annyi friss infóm van a flashcahce-ről, talán érdekel valakit, hogy ha a root particiót akarod így használni (én így szeretteme volna) akkor az "apt-get dist-upgrade" el fognak hasalni, az update-grup nem megy (oldal alja):
https://github.com/facebook/flashcache/blob/master/README-DKMS
Egyébként azért szimpatikus ez a flashcache nekem, mert pont az innodb műveletek gyorsítása volt a fő céljuk a készítőinek. És nekem is pont ez kell.
Vetek majd egy pillantást a bcache-re is, az is ígéretesnek tűnik.
- A hozzászóláshoz be kell jelentkezni
Csodát nem lehet tenni, de jó tippeket ad. Szerintem fordítva ülsz a lovon. :) Elsőre azt kéne látni, hogy optimális esetben mekkora erőforrás igénye van a cuccnak és utána tudsz diszk cserét meg bármit kitűzni. :)
--
Apache Solr Druplahoz és Wordpresshez: http://solr.vpspro.hu
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Normál esetben ez így is van, én is tolnám a +1 -et. De jelen esetben az app ami fut rajta, folyamatosan változik, bővül. Méghozzá gyorsan. Az új funkciók pedig a vas különböző részeit izzasztják. Elég nehéz így előre tervezni.
- A hozzászóláshoz be kell jelentkezni
Írod, hogy van mit optimalizálni az alkalmazásban. Attól, hogy egyre több sz@rul megírt modul/kódrészlet kerül bele, attól még az optimalizálásra IS kell erőforrás a fejlesztői oldalon is. (Ha nem így tesztek, akkor a sz@rkupac is növekedni fog...) Sajnálatos tapasztalat, hogy a sz@r kód alatt ha vasat cserél az ember, és meglódul a teljesítmény, akkor a fejlesztés nem fog erőforrást szánni az optimalizálásra, hiszen az elvárt performanciát hozza az egész cucc - közben meg te, mint OS/DB admin szívsz, mint ama szibériai fehér farkú torkos borz.
Alkalmazástól is függ, hogy mit lehet teljesítményfokozásra bevetni - néha egy-egy apró memcahed vagy redis rendszerbe állítása is csodákra képes, bár az lehet, hogy jóval több fejlesztői munkát igényel, mint a jelenleg használatos query-halmazt és DB-struktúrát gatyába rázni.
- A hozzászóláshoz be kell jelentkezni
+1 :) Én sokszor szélmalom harcnak érzem a T. Fejlesztőket rávenni arra, hogy értelmes kódot írjanak, mert nem a vas gyenge, hanem a kód szar. :) Természetesen kb. képtelenség a vas erősségéről meggyőzni őket, mert sokszor elfelejtik, hogy attól hogy a teszt gépen (ami mondjuk akár még erősebb is, mint a szerver) egy szálon, egy klienssel remek a sebesség, de amikor 5-en rámozdulnak akkor jön a pofára esés.
--
Apache Solr Druplahoz és Wordpresshez: http://solr.vpspro.hu
- A hozzászóláshoz be kell jelentkezni
Láttam én olyan fejlesztőt, aki panaszkodott, hogy a notebookján prímán hasít az Oracle-höz taknyolt alkalmazása, az AIX-es szerveren meg csak döcög. Igaz, azt elfelejtette, hogy az S70 picivel több felhasználót meg alkalmazást szolgál ki, mint a saját gépe...
- A hozzászóláshoz be kell jelentkezni
zeller, andrej_: átérzem a problémát :) Bár én általában a túl oldalon ülök, kódolni szoktam, mindig ügyelek arra hogy ne legyen erőforrás pazarló amit írok.
Jelen esetben viszont one-man-army van: én bütykölöm a szervert, én is veszem meg, és az appokat is én írom rá. Így ha lassú, akkor biztos én vagyok a hibás :D
Egyébként a redis-sel fején találtad a szöget, tervben van egy DB intenzív funkció átírása redis alapokra. Tökéletes lenne rá, hasítana mint állat.
- A hozzászóláshoz be kell jelentkezni
Aztán, ha az one-man-army elmegy két hétre nyaralni és beüt a gebasz, akkor a cég meg szívja a fogát.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Az még a jobbik eset, ha csak a fogát szívja... :-D
- A hozzászóláshoz be kell jelentkezni
A prioritások eldöntése szerintem nem a rendszergazda dolga, hanem a projektmanageré.
Rendszergazdaként pl. annyit tehetsz (bár ez sem feltétlenül a te dolgod), hogy írsz egy jó kis jmeter-es tesztet (esetleg egy kis seleniummal megtűzdelve) aztán rádobod a tesztszerverre és nézitek együtt ahogy összedől.
Aztán lehet magyarázkodni a fejlesztő uraknak ... :)
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Hat, ram is WTF fejjel neztek, amikor megemlitettem, hogy nem lenne rossz dolog ab-vel/apache flood-dal merni a teszt oldalak teljesitmenyet.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
en megcsinaltam. volt orom!
/* Signature
while true; do echo -e "cat your_reply > /dev/null"; done;
Signature */
- A hozzászóláshoz be kell jelentkezni
Mi is tettük, aztán az ahhoz képest harmatgyenge tesztgép többet sajtolt ki magából, mint az éles oldal, ugyanazokkal az adatokkal.
Aztán kiderült, hogy nem a mi rendszerünk a rossz, hanem a másik, ami még mellette futott. (Sors iróniája, hogy azt is nekem kellett helyrepofozni. :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ezt hivjak ugy akkor azt hiszem hogy a sors ironiaja :D
Szerencsere mi szolgaltato ceg vagyunk foleg, uzemeltetes nagyon keves helyen van.. Bar a ddosznak nem orultek :D
/* Signature
while true; do echo -e "cat your_reply > /dev/null"; done;
Signature */
- A hozzászóláshoz be kell jelentkezni
Azt még azért hozzátenném, hogy nem triviális tényleg jó (a valóságot tükröző) teszteket összehozni. Hogy mást ne mondjak, az "ab" pl. engem először csúnyán átvert (2005-ben :) ), mert ugyan lekérte a HTML headert, de a tartalmat már nem várta meg, így persze jóval nagyobb számokat mondott mint amit a rendszer ténylegesen a userek felé szolgáltatni tudott. Aztán persze erre rájöttem, és onnan kezdődött az igazi munka :)
--
Gábriel Ákos
http://i-logic.hu
- A hozzászóláshoz be kell jelentkezni
Az apache flood utility-je mindent leker. Cserebe eleg szarul lehet konfigolni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Az ab sajna nem general valos teljesitmenyt akkor inkabb siege+random url-k :).
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
Hogy én is írjak valamit, ami talán hasznos: a jmeterrel meg vagyok elégedve, egész épeszű teszteket lehet benne összekattogni.
- A hozzászóláshoz be kell jelentkezni
Igen, egyetértek. Egy dolgot hiányolok (vagy még nem találtam meg) belőle, a javascript futtatás. Erre pl. a Selenium jó.
Bár a Selenium meg inkább funkcionális tesztre való szerintem.
Én is most ismerkedem behatóbban ezekkel az eszközökkel, eddig még csak éppenhogy használtam ... :)
--
Gábriel Ákos
http://i-logic.hu
- A hozzászóláshoz be kell jelentkezni
Jo tippek, majd megnezegetem oket.
Jo lenne valami olyasmi, ami konzolosan is indithato...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
A siege ilyen.
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
Ranezek mindkettore majd. Koszonom.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Ha a 8 Gb RAM-d nagyreszet csak filecache-nek hasznalod, akkor az innodb_buffer_pool_size parametert vedd fel a mysqlben, adj neki annyi RAMot, ami nem megy a tobbi alkalmazas rovasara. Szarnyakat kap (gyakorlatilag mindent elintez memoriaban, es csak syncelget diszkre.)
- A hozzászóláshoz be kell jelentkezni
subscribe
- A hozzászóláshoz be kell jelentkezni
Én csak annyit tudok hozzátenni, hogy mint minden eszköz esetében az ssd is meghibásodhat. Ismerősöm hozott egy ssd-t hogy nem tud vele mit kezdeni, nézzem már meg. A disket felismerte a rendszer, de íráskor mindenféle baja volt. Mondtam neki, hogy nem jó. Később hívott, hogy kicsit megmelegítette a lábakat a panelen és elndult, megy. Majd két hónap múlva, hogy megint meghibásodott és elmentek az adatai. :( Egyébként nem gagyi ssd-ről van szó, de nem említek márkanevet, mert szerintem ez csak egy véletlen, ezerből egy.
---
OS: Fedora 17
- A hozzászóláshoz be kell jelentkezni
Raid1 1db SSD-vel és 1db hdd-vel. Olvasás -> ssd sebesség, írás hdd sebesség. Egyszer próbáltam, működik, látványos.
- A hozzászóláshoz be kell jelentkezni
Szerintem raid1 esetén - ha csak másképp nem rendelkezel - felváltva olvas a diszkekről.
- A hozzászóláshoz be kell jelentkezni
Jah, de szerencsére ennél okosabb a szoftverraid. ;) (Oké, annyi trükk volt a dologban, hogy a HDD-t megjelöltem a "--write-mostly" kapcsolóval.)
Próbáld ki, elég jó sztem. ;)
- A hozzászóláshoz be kell jelentkezni
Írtam, hogy "ha másképp nem rendelkezel".
- A hozzászóláshoz be kell jelentkezni
FreeBSD-n pld. a legkisebb terhelésű (amely itt nyilván az SSD lesz) eszközről olvas alapból, azaz kb. annyival több olvasás lesz az SSD-n, amennyivel az gyorsabban teljesíti a kéréseket.
Általánosságként ezt kijelenteni nem igazán lehet.
--
zsebHUP-ot használok!
- A hozzászóláshoz be kell jelentkezni
A gmirror-nak is megmondhatod a read-policy-t: http://www.freebsd.org/cgi/man.cgi?query=gmirror
--
Apache Solr Druplahoz és Wordpresshez: http://solr.vpspro.hu
- A hozzászóláshoz be kell jelentkezni
Az alapértelmezésről volt szó, és arról a kijelentésről, hogy A RAID1 "felváltva" (ami nekem a round robint jelenti) olvas. Igen, lehet állítani.
--
zsebHUP-ot használok!
- A hozzászóláshoz be kell jelentkezni
+1 így használom itthon is, és van ahol szerverben is. Az ssd az olvasás miatt jó, a raid a biztonság miatt, a hdd fél az olcsóság miatt :)
- A hozzászóláshoz be kell jelentkezni
Sub
- A hozzászóláshoz be kell jelentkezni
Hamár így felbukkant ez a topic, jelzem (bár off) hogy végül raid mirrorba tettem két hdd-t és elé bepakoltam egy ssd-t facebook féle flashcache-sel. Eddig maximálisan elégedett vagyok, nagyon gyors, és nagy a tárhely is.
Valószínűleg elég hamar el fog használódni az ssd, de könnyű kicserélni, és távolról kiiktatható az ssd amíg nem viszem be a cserét.
- A hozzászóláshoz be kell jelentkezni
Kiváncsi lennék hogy amikor elromlik a flash az hogy jelentkezik. Én azt gondolnám ha nem tudja írni akkor keres másik helyet a flashen amíg van tartalék. Keletkezik ilyenkor hibajelzés vagy s.m.a.r.t.-tal észrevehető? A flashcache ki tudja magát kapcsolni ha write error van, továbbmegy kiesés nélkül?
- A hozzászóláshoz be kell jelentkezni
A flashcache 3 féle módban tud működni, a leggyorsabb módban íráskor csak ssd-re ír, de van olyan mód is amivel hdd-re is és ssd-re is ír.
Automatikusan nem fog továbbmenni szerintem ha az ssd elpukkan. Viszont ha kiszedem a flashcache-t, a mögötte lévő hdd mirror simán fel lehet mountolni, a flashcache is csak annyit lát belőle, hogy egy block device.
- A hozzászóláshoz be kell jelentkezni
jól hangzik...
- A hozzászóláshoz be kell jelentkezni
Én most nézegetem az SDD+mdadm+trim témakört és nem látok konkrétumot, hogy az mdadm már támogatja-e. Van erről valakinek infója?
- A hozzászóláshoz be kell jelentkezni
https://github.com/Cyberax/mdtrim
Az 'lsblk -D' -vel tudod megnezni, h engedi-e a block device.
Ill. ubuntuban van egy 'fstrim' parancs is, az is ezt csinalja.
A kernelbe vmikor mar bekerult, de nem talalom, mikor.
Viszont ha nem supported a tiedben meg, akkor ki kell irnia vmi ilyet:
EXT4-fs warning (device md1): ext4_issue_discard:2619: discard not supported, disabling
Vhol itt kezdtek el hozzaadni:
http://lkml.indiana.edu/hypermail/linux/kernel/1203.2/00049.html
- A hozzászóláshoz be kell jelentkezni
Én úgy tudom, hogy ha natív trimes SSD-t veszel akkor az oprendszernek nem kell vele foglalkozni. A monitorozó szerver már több mint másfél éve megy sw raid1-el, és OCZ vertex3 SSD-kkel, jellemzően főleg írás történik rajta.
Fedora 19, Thinkpad x61s
- A hozzászóláshoz be kell jelentkezni
+1 bezony. Natív trim, ahol csak lehet.
- A hozzászóláshoz be kell jelentkezni
[like]
- A hozzászóláshoz be kell jelentkezni
FYI:
Sangwhan Moon, A. L. Narasimha Reddy: Don’t Let RAID Raid the Lifetime of Your SSD Array
"Abstract
Parity protection at system level is typically employed to compose reliable storage systems. However, careful consideration is required when SSD based systems employ parity protection. First, additional writes are required for parity updates. Second, parity consumes space on the device, which results in write amplification from less ef- ficient garbage collection at higher space utilization. This paper analyzes the effectiveness of SSD based RAID and discusses the potential benefits and drawbacks in terms of reliability. A Markov model is presented to estimate the lifetime of SSD based RAID systems in different environments. In a single array, our preliminary results show that parity protection provides benefit only with considerably low space utilizations and low data access rates. However, in a large system, RAID improves data lifetime even when we take write amplification into
account."
- A hozzászóláshoz be kell jelentkezni