Dotaz: ssd disky na server

[marcelius]

Dobry den.

Mam otazku ohledne SSD disku a jejich vhodnosti nasadeni na servery. Planuji LAMP server s velkym provozem, cca 20 webu. Na disky planuji hodne read/write operaci a nejsem si jist, jestli je volba SSD v poradku. Rozmyslim mezi SAS 15K a SSD hdd. Server bude predpokladam HP PL ML/DL...

Mate nejake skusenosti s SSD hdd na serverech? Jak je to se zivotnosti? Vydrzi vysokou cetnost R/W operaci po cca 3-4 roky? Moc SSD hdd neznam, tak se ptam na vase nazory, zkusenosti.

Diki.

---

---

Odpovědi

[Filip Jirsák]

Před rokem a půl se tu psalo, že někde SSD nevydržely v serveru ani 2 měsíce.

[marcelius]

Dekuji, to sem cetl. To bylo pred cca rokem a neco.

[robertK]

Pokud si koupis ty SSD disky přímo od HP, tak bych se toho nebál - nebudou prodávat něco čemu sami moc nevěří a kdyžtak budou v "rozumný záruce".

Jen si připrav hooodně velký prasátko, který rozbiješ - 100GB SSD za 30k je pěkná cena:) Třeba tady

[marcelius]

No ale prave HP zatim nenabizi servery s SSD. Koukal sem dnes na 3 modeli a zatim sou tam SATA a SAS hdd.

[bigBRAMBOR]

byli u nas od HP, na servery jedine SAS. SSD vubec nedoporucovali. Chteli jsme to na vetsi SQL server.

[mess]

Do SSD bych nešel. Už jenom proto, že vydrží málo přepisů. Maximálně bych to dal jako systémový disk, ze kterého se bude bootovat, ale všechny operace, které budou často něco zapisovat bych směřoval na disky klasické konstrukce.

Co se týče životnosti, tak větší výdrž by měly mít SSD, které používají SLC (single-level cells).

[ondro]

Presne tak jedine SSD s SLC pametami ale aj tak zivotnost takehoto riesenia je otazna. Skusenosti su s tym dost male a cena vysoka za taketo SSD. Z pohladu ceny, vykonu a zivotnosti je na tom stale lepsie klasicky disk.

[Michal Fecko]

Maximálně bych to dal jako systémový disk, ze kterého se bude bootovat

Zase server casto nebootuje..

[mess]

No vidíš Anebo by se na to daly dát obrázky, javascripty a podobné statické věci k webovkám (ostatně to už tu někdo psal).

[vandrovnik]

A co udělat RAID 1, kde bys měl 1xSSD a 2xHDD a nastavit, že z SSD se bude číst prioritně?

[Ĺupex]

SSD je super pro export statického kontentu do webserveru, takže v tomhle použití to není problém, adresář kde je write dát na SAS nebo skusit RAM disk.

[Ĺupex]

ad SAS, rychlost přichází pouze v kombinaci s dobrým řadičem s cache a baterkoum, takže pozor na levné servery s SAS řadičem, bývá bez cache a bez baterky což je dalších 5-8k, typicky jsem to viděl u HP DL 160 G6, řadič P410 a 300GB SAS, pod vmware výkon naprosto tristní.

[Michal Fecko]

Videl som server (podotykam ze sice produkcny ale testovaci) 2xSSD 240GB 550/500 (niečo podobné ako som testoval ja sám, akurát že RAID1) s 32GB RAM (4x8GB RAM) a do RAM skrz ramfs pripojene /tmp /var/log a /var/lib/mysql do ktoreho bola pri starte masiny exportovana zlozka /var/lib/mysql_ssd (asi 16GB). Pri vypinani bola zase ukladana do /var/lib/mysql_ssd.

[Šangala]

Klidně byc je tam dal, mít na to prachy, Intel disky mají i 5let záruku (vhodná řada 710 tři roky) a asi tam budete mít minimálně mirroring když né 5/6-ku.
V pracovních stanicích (DELL) je to nesrovnatelný výkon (výrazně lepší) oproti 15K disku.

[Filip Jirsák]

Pochybuju o tom, že by se záruka vztahovala na to, že disk vydrží 5 let soustavného zapisování. Bude tam úplně stejný limit na počet zápisů, jako u každého jiného SSD disku. Takže když ten disk přestane fungovat z důvodu, že do paměťových buněk nepůjde zapisovat, záruka se na to nevztahuje.

[Šangala]

Bude tam úplně stejný limit na počet zápisů, jako u každého jiného SSD disku

Spousta disků to má různě…

Uváděná životnost u 710 a velikosti 300GB je 1.5PB což je 3 roky při zápisu přes 1TiB denně - to už ať si už každý zváží sám, jestli tohoto limitu dosáhne.

[Lazar]

Přeloženo, to asi znamená hranici pouhých 5000 přepisů buněk (což se zmiňuje v souvislosti s MLC 25nm) při optimálním wear levelingu.

[Šangala]

Je irelevantní co to znamená, ale důležité je, co to prakticky vydrží a jak rychlé je to.
Bohužel nemám možnost to zkoušet v serveru, ale v notebocích už dlouho a nechápu proč někdo ještě chce normální disk. Nejvytíženější je asi 16GB v netbooku neustále zaplněný tak na 14+GB, denně v provozu 6-12 hodin po dobu téměř 4 let a furt naprosto bez chyby, což je už statisticky téměř průměr životnosti běžných disků co mi prošli rukama…

[Lazar]

Se zmenšujícím se výrobním procesem flash se počet přepisů zmenšuje, navíc srovnávat charakter/množství zápisů na disku v desktopu(notebooku) a serveru asi dost dobře nejde. Jak bylo již uvedeno výše podle typu zátěže může SSD v serveru sloužit úspěšně roky, nebo taky měsíce.

[Šangala]

A proto: …což je 3 roky při zápisu přes 1TiB denně - to už ať si už každý zváží sám, jestli tohoto limitu dosáhne.
Ale i obráceně! Přijde na to co na tom desktopu děláte a co je to za server, mám server (pro cca. nenáročných 25 lidí all-in-one db/file/intranet/atd.), který nezapíše tolik za týden, co kolegův desktop za 8 hodin.
Ano teoreticky:
(1.5PB * 1000 * 1000 * 1000)MB / (100MB/s * (60*60*24)sec/den)MB/den = 6 měsíců trvalého nepřetržitého sekvenčního zápisu docela super rychlostí… a kdy budeme číst zapsaná data? - takže s těmi měsíci je to trochu na štíru, co?

[Lazar]

Ty měsíce jsou ze zmínky o praktických zkušenostech v předchozích příspěvcích(odkazovaných vláknech na podobné téma). Doporučuji přečíst si článek/debatu pozorněji.

Je otázkou nakolik se wear leveling dlouhodobě vypořádá s četnými atomickými zápisy na omezeném prostoru. Storage exponovaného OLTP serveru může odbavovat stovky transakcí/sec, což nelze srovnávat s ojedinělou, převážně sekvenční, zátěží.

[Šangala]

Zaprvé doba pokročila a za druhé nebavíme se o „nějakých“ SSD discích, ale o konkrétních Intel SSD discích (určených pro data centra).
Ano nelze srovnávat, zápis bude mnohonásobně nižší…
wear leveling na omezeném prostoru je blbost. A když bude zapisovat málo, tak máte moc buněk a když budete zapisovat moc, tak máte zas moc dat k zápisu, takže přepisujete efektivně, pokud nemáte disk z 98% full.

[lertimir]

Současné dobré disky dělají wear leveling po celé ploše disku. tedy, když na začátku nainstaluji systém do buněk, které mají tím pádem počet zápisů 1 a používám disk, takže že se zbylé buňky dostanou v počtu zápisů na vysokou hodnotu přesune disk systém do již "částečně zápisově opotřebovaných" buněk a buňky s nízkou hodnotou počtu zápisů uvolní pro opakované psaní.

[Šangala]

No a právě proto wear leveling na omezeném prostoru je blbost - nebo si nerozumíme?

[Lazar]

Měl jsem tím na mysli, že vysoká aktivita na malém prostoru atomickými operacemi povede k postupné "saturaci" opotřebení v celém prostoru SSD. Řádově nižší velikost zapisovaného bloku (proti jednotce uvažované wear levelingem) může zniňovaná čísla o celkově zapsatelných datech (PB) řádově snížit. Například tento dokument zmiňuje v souvislosti s W-L velikost bloku 128KB (tj. 16x více než např. 8kB DB blok). http://authors.library.caltech.edu/26125/1/etr094.pdf

[lertimir]

Takhle se to počítat nedá. SSD dísk má reálný zápisový blok mnohem větší než HDD, současnosti tuším je velikost na 512kB a jakýkoliv atomární zápis do SSD má za následek přečtení 512kB modifikace dat, výmaz celého bloku a opětovné zapsání 512kB dat. To i v případě že jen zapíšu nějakých pár bytů do jako jeden textový řádek do logu, nebo comit jednoho řádku do databáze. Pro 300GB SSD disk to znamená 300x2000 bloků x 5000 zápisů do bloku = 3 000 000 000 atomárních zápisů. Budu-li na tom serveru dělat cca 100 zápisů za sekundu, tak to je 8 640 000 zápisů za den a za 347 dnech jsem na konci životnosti(pro 1000 zápisů za sekundu jsem na konci za měsíc a kousek) Je jasné, že cache, může počet zápisů snížit, ale reálné snižení atomárních operací nastane jen tehdy, pokud více zápisů padne do jednoho bloku a následně je do SSD zapsáno v jedné atomární operaci, a to se obávám, že pořád se neděje, pořád se SSD tváří pro systém jako něco o velkosti 512b nebo 4kB, ale ne jako blokové zařízení o velikosti fyzického bloku 512kB nad níž by OS mohl lépe optimalizovat write operace.

[Šangala]

Každý výpočet kulhá. Ano, uvádí se, že tato jednotka je obvykle 512kB (co jsem se natrápil s nastavením všeho na svém ntb, abych měl vše nastaveno na zarovnání do těchto bloků, od partition, přes LVM a LUKS a mohl mít dobrý pocit a třeba kluky od DELLu to vůbec nezajímá prskají to jak na stanice ze SDD tak na NTB jak je napadne :( ). Ale zmínil jsi to, cache při aktivním nepřetržitém zápisu zmírní tento dopad.
Jediná možnost je koupit jeden disk a vyzkoušet to. :)

[Lazar]

U náhodného přístupu (typicky u OLTP systému .. např. měním x00 záznamů/sec z x000000..) cache pro zápis moc nepomůže, pravděpodobnost fyzicky společného uložení měněných záznamů bude nízká a čekat s dirty blocks delší čas nelze. Z tohoto důvodu je v řešeních pro špičkový TPC-C výkon storage tvořena řádově tisíci HDD (asi ne z důvodu kapacity, benchmark je snad definován nad DB v řádu TB, ale pro dosažení nízkých latencí).

[Lazar]

Jak je to v případě zapojení SSD do RAID(1,5,6). Očekával bych, že operace nad RAIDem povedou k relativně uniformímu zápisu na všech členech a tudíž ve výsledku vystavení se riziku "relativně současného" opotřebení. Nebo se v algoritmu wear levelingu uplatňuje nějaký prvek náhody?

[lertimir]

RAID (zvláště 5,6) nad SSD disky bych byl velmi opatrný. Z pohledu bloku 512kB na SSD mě připadá, že nemá cenu vytvářet menší strip, než 512kB, jinak dramaticky zvyšuji opotřebení SSD disků, protože třeba při velikosti stripu 8kB se mi např 32 kB soubor zapíše do 4 stripů a tím pádem se přepíše alespon 2MB a případně něco na paritu.

Na druhou stranu strip 512kB je obrovský, pro 4 diskový RAID 5 jakýkoliv soubor menší než 1,5 MB nevyužije vlastnosti RAIDu a výkonově bude tratit (viz diskuse asi z před měsíce o optimalizaci raidu a LVM - tazatel měl velkou hodnotu stripu a s malými soubory pracoval velmi pomalu) Takže v podstatě jediné náročná sekvenční práce z velkými soubory bude mít profit.

Ale ještě to promyšlené moc nemám a nedělal jsem si nějaký matematický model.

Uniformní opotřebení bych očekával, ale na druhou stranu větší opotřebení, protože vždy dělám dva zápisy. hodnotu a paritu.

[Milan Beneš]

Dobrý den, používáme SSD na databáze a do Solarisu na ZIL(2x ssd mirror) a do ostatních serverů jako systémové disky(2x ssd mdraid 1), po předchozích zkušenostech jedině od Intelu. Starší máme X-25M, ty jedou přes rok nonstop v db serverech v mdraidu (RAID-1) 3x1 + hot-spare, datový tok na jednotlivých DB je cca 500Mbps do sítě. Všude jinde používáme řadu 320. Zajímavé by také bylo zkusit konfiguraci 2xHDD + 2xSSD, oboje v raid1 a dohromady na tom zpojezdnit flashcache se strategií write-back. Jinak co se týká serveru, koukněte se v Asbisu nebo Abacusu na Supermicra, jsem s nimi velmi spokojen, obzvláště s twiny a quady.