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