Hlavní navigace

SSD na serveru: výhody, zkušenosti a mýty

13. 3. 2015
Doba čtení: 9 minut

Sdílet

SSD se už velmi dobře etablovaly v desktopových počítačích a noteboocích. Dostávají se ale také do serverů, kde mohou při správném použití přinést celou řadu výhod, zejména výkonnostních. Panuje kolem nich ale také několik mýtů, které často adminům brání v nasazení. Co mohou SSD na serveru přinést?

Na konferenci InstallFest přednesl Pavel Šnajdr ze spolku vpsFree.cz přednášku na téma SSD na serveru. Začal krátkou historií SSD a také tím, jak tyto disky funguji. Myslím si, že když chcete nějakou technologii používat, měli byste ji znát, řekl. Nejde přitom o nijak novou technologii, NAND čipy uvedla na trh společnost Toshiba už v roce 1989 a SanDisk na jejich základu vyrobil první SSD o dva roky později. První klasické 3,5" disky pak přišly na trh v roce 1999. Reálně se mezi uživatele rozšířila SSD okolo roku 2008 a druhá generace přisla o rok později. Byla o 60 % levnější.

Klesající ceny přispěly k rozšíření SSD

Výběr správného SSD

Centrálním mozkem SSD je řadič, ke kterému jsou připojené jednotlivé NAND čipy, SDRAM pro cache a hlavně komunikační rozhraní. Čipy se pak liší množstvím bitů, které je možné uložit do jedné buňky. U SLC je to jeden bit, MLC umožňuje uložit dva a TLC pak tři bity. Více bitů na buňku ale znamená menší životnost a nižší rychlost.

Buňky jsou pak organizovány do stránek o velikosti mezi 4 kB a 16 kB. Stránky jsou pak shlukovány do bloků o velikosti 128 až 512 stránek. Zapsat data je možné pouze do prázdné stránky, smazat je zase možné jenom celý blok najednou. Pro přepsání už naprogramované stránky se data zapíší tedy do nové prázdné stránky a původní stránka se označí jako neplatná. Neplatné stránky průběžně uklízí firmware SSD tak, že přemístí platná data stránek z čištěného bloku do nového prázdného bloku a původní blok se potom smaže.

SLC MLC TLC
Bitů na buňku 1 2 3
Životnost (cyklů) 100 000 3 000 1 000
Čas čtení 25 µs 50 µs 75 µs
Čas zápisu 200–300 µs 600 – 900 µs 900 – 1300 µs
Čas mazání 1,5 – 2 ms 3 ms 4,5 ms

Z toho plyne, že je potřeba mít nějaký sofistikovaný management, který se stará o organizaci dat na čipech. Pokud se systém nechce starat o nízkoúrovňovou komunikaci s čipy, musí existovat firmware řešící správu flash pamětí. Ten si vede informace o vadných blocích, řeší rozkládání zátěže (wear leveling) a uklízení pomoci garbage collectoru.

Existuje několik různých provedení SSD:

  • PCIe
    • PCIe-to-SAS/SATA – FP/LP karta
    • NVMe – 2,5" disk/karta
  • 3,5"/2,5"/1,8" disk
    • SATA3, SAS2 (6 Gbps)
    • SAS3 (12 Gbps)
  • mSATA
  • M.2

Při výběru SSD je třeba sledovat několik různých parametrů. Kapacitu, množství náhradních bloků, životnost a výkon v IOPS. Také nás zajímá, jak konzistentní je výkon SSD pro zápis v čase. Výrobci to šidí tak, že SSD má skvělé parametry v prvních sekundách zápisu a pak výkon klesne. Výborným zdrojem nezávislých testovacích dat je web AnandTech.com. Na serveru nás také zajímá, jak se SSD chová při ztrátě napájení, zda nemůže přijít o část nezapsaných dat.

Blokové schéma SSD

Pokud kupujete do serveru běžné domácí SSD, měli byste se mít na pozoru. Většina z nich není odolná proti ztrátě napájení. Podle Šnajdra jsou v pořádku Crucial MX100, MX200, M500 a M550. Ideální je podle něj Intel 530. TLC mají velmi malou životnost, což je na serveru dost velký problém. Životnost se dá zvýšit tím, že disk nikdy úplně nezaplníme. Levné disky totiž mívají vyhrazenou jen velmi malou část náhradních bloků – při nejlepším okolo 7 %. Doporučuji si vytvořit oddíly tak, aby na konci zbyl kus volného místa, které nikdy nepoužijeme. Disk pak bloky zařadí do wear levelingu.

Pavel Šnajdr také doporučil konkrétní modely vhodné do datacenter:

  • 2,5" SATA3
    • Intel 730
    • Intel DC S3500/S3700 (S3610/S3710)
  • NVMe SFF
    • Samsung XS1715
    • Intel DC P3600/P3700 (i ve formě PCIe karet)
  • SAS2/SAS3
    • Hitachi, Seagate, Toshiba
  • Fusion-IO – pokud máte hodně peněz

Hlavní výhodou SSD je okamžitá přístupová doba, která umožní data zpracovat bez zbytečného čekání. IO operace jsou velmi často úzkým hrdlem serveru. Často zbývá dost paměti i procesorového výkonu, ale aplikace čeká na zápis dat na disk. SSD se pak dá výhodně použít jako cache před rotačními disky nebo může obsahovat data přímo. Nejvíce to ocení databáze, které jsou kvůli konzistenci nucené čekat na provedení zápisu. Tam SSD pomůže dramaticky.

SSD v Linuxu

Pokud nasazujete SSD pod Linuxem, je dobré nastavit některé vlastnosti systému. Výchozí I/O plánovač CFQ řadí požadavky v závislosti na fyzickém umístěni na disku. To je pro SSD zbytečné a zvyšuje to latenci. Doporučuji nastavit deadline/noop, které se chovají lepe. Pozor ovšem na to, že nastavení není perzistentní a musíte ho zapsat třeba do udevu. Popis naleznete například na wiki.archlinux.org.

Stejně tak je důležité používat TRIM, což je ATA příkaz informující SSD o uvolněných blocích. Ty mohou být fyzicky smazány a jsou pak připraveny k okamžitému zápisu bez nutnosti složitě data načítat, modifikovat a opět zapisovat. Implementace v Linuxu není dokonalá, protože posílá příkaz TRIM pro každý blok zvlášť, doporučuje se spíše používat příkaz s více bloky naráz. Posílání mnoha požadavků s jednotlivými bloky může u levných SSD vést ke zpomalení disku. Někteří správci tvrdí, že na serveru je TRIM zbytečný a lepší je zvýšit overprovisioning už zmíněným zachováním části prázdného místa zhruba o 25 %. Další variantou je TRIM volat hromadně jen jednou za čas – doporučuje se jednou týdně.

Zapnutí nativní podpory TRIM přímo v souborovém systému může způsobovat zpomalení zápisů právě v nejkritičtější dobu – ve špičce. Proto je podle mě skutečně nejvýhodnější volat příkaz fstrim jednou týdně pomocí cronu. Ideálně v době, kdy je na serveru nejmenší zátěž.

Pavel Šnajdr, InstallFest 2015

Při instalaci nového disku je zásadní zarovnat oddíly na stránky. Pokud si nejste jisti, zarovnejte na 1 MB. Stejně tak by měl být souborový systém vytvářen s velikostí bloku rovnou stránce. Bohužel SSD neumožňuje jednoduše zjistit, jakou má velikost stránky. Je třeba hledat v datasheetu disku, nejkrajnější možností je pak disk rozebrat, zjistit typ čipů a vyhledat si jejich datasheet. TRIM na Linuxu podporují souborové systémy: Btrfs, Ext4, JFS, VFAT a XFS. Podpora pro ZFSonLinux je na cestě, ale vypadá to, že po ní není příliš velká poptávka, takže se na ni nespěchá.

Reálně využitelné jsou RAID1 nebo RAID10, pokročilejší RAID5 nebo RAID6 podle Pavla Šnajdra na SSD nedávají smysl. Opotřebení NAND bude podobné a disky začnou umírat najednou. Problém navíc přichází v kombinaci s TRIM, kdy disk pro smazané bloky vrací samé nuly a přestanou sedět parity.

SSD jako cache

Pro nasazení SSD na linuxovém serveru je možné využít technologii Flashcache, kterou vyvinul Facebook v roce 2010. Jde podle mě o nejpokročilejší cache, má mnoho konfiguračních voleb a může být použita k zápisům i čtení. Jde o modul pro device mapper a ze dvou zařízení (rotačního disku a SSD) skládá zařízení jedno. Má tři módy:

  • write-back – data jdou nejdřív na SSD, později na úložiště
  • write-through – data jdou naráz na SSD i úložiště
  • write-around – data jdou jen na úložiště a SSD se používá jen jako read cache

Bohužel Flashcache nepodporuje TRIM a není v linuxovém jádře, protože Facebook nejeví zájem jej tam dostat.

Další možností je EnhanceIO, který vznikl jako fork Flashcache v roce 2012. Má přepsaný write-back režim, který komprimuje metadata – uvádí se asi trojnásobné zmenšení velikosti. Na rozdíl od Flashcache nepoužívá device mapper a umožňuje manipulaci s cachovacím zařízením za běhu.

Až na tyto dvě vlastnosti je dnes proti Flashcache pozadu. Také není součástí linuxového jádra.

V jádře od verze 3.10 je bcache, který je jednodušší a umí toho méně. Má dva režimy: write-through a write-back a má jen dva konfigurovatelné parametry. Se zařízeními by mělo být možné manipulovat za běhu.

Od verze 3.9 je v jádře modul device mapperu s názvem dm-cache, který umí používat oddělené zařízení na metadata. To například umožňuje metadata zdvojit, ale samotná data nechat na discích jen jednou. Dlouhodobé zkušenosti s write-back režimem ukazují, že se chová dobře, pokud nedojde k zaplnění caching device. Pak je dm-cache v koncích a výkon rapidně klesá.

Další variantou je souborový systém ZFS, který umí sám řešit celou správu disků včetně cache. Používá třívrstvý model: v RAM je ARC, na SSD je možné dát L2ARC a na rotačních discích jsou všechna data. ARC se na servery hodí nejlépe ze všeho, co jsem zatím potkal. Dělí data nejen podle toho, kdy byla naposledy použita, ale také podle četnosti použití (most recently used a most frequently used).

ZFS také umožňuje obejít problém pomalých synchronních zápisů na copy-on-write souborových systémech. Používá k tomu mechanizmus ZIL, kdy se na speciální oblast zapisuje log záměrů. V případě výpadku je pak přečten a data z něj se přepíší na úložiště. ZIL je možné přesunout na SSD, kterému se pak říká dedicated SLOG device. V případě požadavku na sychrnonní zápis (typicky z databáze) se zápis provede velmi rychle na SSD a až později se může přepsat na pomalé úložiště. Databáze tak nemusí na zápis čekat.

Zkušenosti za čtyři roky

Ve vpsFree.cz jsou SSD nasazené od roku 2011, původně to byly Intel 320 a OCZ Vertex 2. Dobíhají nám OCZ Vertex 3, které se už nevyrábí. To jsou velmi dobré SSD, které snad jako jediné nepoužívají vyrovnávací SDRAM, takže nemají problém se ztrátou napájení. Od roku 2013 pak Pavel Šnajdr do serverů kupuje Intel DC S3700 200 GB, které doporučuje díky vysoké životnosti právě pro zapisovací cache a výborné odolnosti proti výpadku napájení.

Správci se často SSD bojí kvůli údajné nižší životnosti, která je ale podle Pavla Šnajdra mýtem. Nejstarší disky OCZ Vertex 3 mají ve vpsFree.cz zapsáno 70 TB dat a jejich Media Wearout Indicator poklesl jen o jedno procento. Mnoho lidí testuje SSD pod trvalým zápisem a životnost je překvapivě vysoká a několikrát překračuje hodnotu udávanou výrobcem.

# smartctl -a /dev/sda
[... výpis zkrácen...]
Model Family:     SandForce Driven SSDs
Device Model:     OCZ-VERTEX3 MI
Serial Number:    OCZ-15AI56EGB9220T94
[... výpis zkrácen...]
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   090   090   050    Pre-fail  Always       -       0/133654816
  5 Retired_Block_Count     0x0033   100   100   003    Pre-fail  Always       -       0
  9 Power_On_Hours_and_Msec 0x0032   071   071   000    Old_age   Always       -       25801h+29m+01.190s
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       16
171 Program_Fail_Count      0x0032   000   000   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   000   000   000    Old_age   Always       -       0
174 Unexpect_Power_Loss_Ct  0x0030   000   000   000    Old_age   Offline      -       7
177 Wear_Range_Delta        0x0000   000   000   000    Old_age   Offline      -       8
181 Program_Fail_Count      0x0032   000   000   000    Old_age   Always       -       0
182 Erase_Fail_Count        0x0032   000   000   000    Old_age   Always       -       0
[... výpis zkrácen...]
195 ECC_Uncorr_Error_Count  0x001c   120   120   000    Old_age   Offline      -       0/133654816
196 Reallocated_Event_Count 0x0033   100   100   003    Pre-fail  Always       -       0
201 Unc_Soft_Read_Err_Rate  0x001c   120   120   000    Old_age   Offline      -       0/133654816
204 Soft_ECC_Correct_Rate   0x001c   120   120   000    Old_age   Offline      -       0/133654816
230 Life_Curve_Status       0x0013   100   100   000    Pre-fail  Always       -       100
231 SSD_Life_Left           0x0013   091   091   010    Pre-fail  Always       -       0
[... výpis zkrácen...]
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       77758
242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   Always       -       78566
[... výpis zkrácen...]

Příklad výpisu SMART pro SSD (popis jednotlivých položek)

root_podpora

Do půlky roku 2014 se na serverech používala Flashcache, pote došlo k plnému přechodu na ZFS. Flashcache má nevýhodu v tom, že na začátku cachuje pěkně, ale po čase je zavalena náhodnými zápisy z MySQL a výkon rapidně klesá. U současného ZFS jsou největší benefity z dedicated SLOG device, které přineslo výrazné zrychlení. L2ARC také máme a používáme, ale k jejímu využití nedojde, pokud něco nevylije cache z RAM.

Životnost disků tedy podle Šnajdra není vůbec problém, v praxi se vám na ně nepodaří zapsat tolik dat, že byste zničili samotné flash čipy. Zbytek už je jen otázkou kvality výroby desky a jednotlivých součástek. Za celou dobu nám odešly jen tři SSD disky a všechny kvůli elektronice – konkrétně napájecí části. Nikdy to nebylo kvůli ‚oježdění NAND‘.

Byl pro vás článek přínosný?

Autor článku

Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. Studoval počítače a média, takže je rozpolcen mezi dva obory. Snaží se dělat obojí, jak nejlépe umí.