V tomto příspěvku se vám pokusíme představit naše technické řešení diskového pole po hardwarové i softwarové stránce. Pole je připojeno k serveru Anxur, který ostatním strojům (např. serveru Aisa nebo stanicím Nymfe) poskytuje přístup přes síťové souborové systémy NFS a Samba.
Původní pole
Původní konfigurace sestávala ze dvou polic, každá byla osazena 24 rotačními disky velikosti 2 TB. Disky podporovaly protokol SAS-2, tedy teoreticky datový přenos rychlostí 6 Gbit/s. Celková surová kapacita byla 96 TB. Připojení k serveru bylo realizováno pomocí dvou PCIe 2.0 řadičů zapojených v x8 slotech. Řadiče mají dva externí SAS porty, takže by šlo použít jen jeden řadič. Tím, že jsme každou polici připojili do zvláštního řadiče, jsme zdvojnásobili propustnost systému, což se projevilo při přenosech velkého množství dat.
Nad tímto polem byly vytvořeny dva linuxové RAID10 svazky (md0, md1), každý čítající 20 disků. Mohli jsme použít jen jeden svazek přes všechny disky, ale při iniciálním testování jsme si všimli, že synchronizace disků je limitována CPU, protože ji realizuje jedno vlákno na svazek. Použití dvou svazků znamenalo zdvojnásobení rychlosti synchronizace.
Jednotlivé rotační disky rychlosti 7200 RPM zvládají zhruba 75 vstupních nebo výstupních operací za sekundu (IOPS). RAID10 pole si lze představit jako sestavené ze dvojic zrcadlících se disků, celkem tedy bylo k dispozici asi 1500 IOPS (2 pole * 10 dvojic disků * 75).
Pro flexibilnější vytváření diskových oddílů jsme oba svazky vložili do LVM volume group (VG) a samotné logical volume (LV) oddíly jsme vytvářeli z obou RAID svazků – vždy první polovinu z md0 a druhou polovinu z md1. V případě souborového systému ext4 to jednoznačně znamenalo nerovnoměrné rozdělení zátěže – jeho začátek se nacházel na md0 a tam směřovala většina provozu. V případě XFS jsme počítali s lepším rozložením díky mechanismu allocation groups, kdy je celý diskový prostor rozdělen na menší celky, z nichž je místo přidělováno rovnoměrně. Podle našich měření k rozdělování docházelo, ovšem stále šlo na md0 asi o 50 % více provozu.
Zpětně jsme zhodnotili, že úzké místo jednoho synchronizačního vlákna RAIDu (typicky v případě výpadku disku a nahrazení za nový kus) se stejně za běžného provozu neprojevovalo, protože přístup k diskům byl v zásadě náhodný a rotační disky nejsou v takovém případě schopny vygenerovat tak velký datový tok. Spojením disků do jednoho RAID10 svazku by se zajistilo lepší rozložení zátěže na jednotlivé disky a navíc by se zjednodušila správa pole. Proto jsme tento přístup u nové konfigurace opustili.
Nové pole
Nová konfigurace pole je z hardwarového hlediska komplexnější. Základem jsou 3 police, v každé je celkem 44 slotů na 3.5" disky (24 vpředu a 20 vzadu). V policích jsou zapojeny jednak rotační disky o kapacitě 12 TB používané pro data, na která nejsou kladeny velké nároky ohledně latence, a jednak SSD disky o kapacitě 3840 GB. Všechny podporují protokol SAS-3, tedy teoretickou propustnost 12 Gbit/s.
V serveru Anxur jsou celkem 3 PCIe 3.0 x8 řadiče, každý má 2 externí SAS-3 porty. Každá police má dva řadiče, každý se dvěma porty. Bylo tedy možné propojit pole takovým způsobem, že při výpadku libovolného z řadičů bude mít server stále přístup na všechny disky v policích:
ANXUR
+---------+ +---------+ +---------+
| radic_1 | | radic_2 | | radic_3 |
+-+++-+++-+ +-+++-+++-+ +-+++-+++-+
|1| |2| |1| |2| |1| |2|
| | | | | |
+------------+ , | | | | |
+ police_1 p1:<--- | | | | |
+ p2: | | | | ,
+ p3:<-------|-------|---|-------|---
+ p4: | | | |
+------------+ | | | |
| | | |
+------------+ , | | |
+ police_2 p1:<------- | | |
+ p2: , | |
+ p3:<--------------- | |
+ p4: | |
+------------+ | |
| |
+------------+ , |
+ police_3 p1:<------------------- |
+ p2: ,
+ p3:<---------------------------
+ p4:
+------------+
SAS disky umožňují operačnímu systému přistupovat k nim po dvou nezávislých cestách. Pomocí Multipath jsme nad těmito cestami vytvořili virtuální zařízení, které je odolné proti výpadku jedné z těchto cest. Navíc se tok dat rozloží algoritmem round-robin mezi obě cesty, což zvyšuje propustnost.
SSD disků je zapojeno celkem 16 a to tak, aby se maximalizovalo využití datových cest – v každé polici 4 disky a 4 disky zapojeny přímo do serveru Anxur. Nad všemi disky (přesněji nad disky v Anxurovi a nad multipath zařízeními) je vytvořen RAID10 svazek, který je zařazen do LVM. Používá se pro uložení dat v domovských adresářích (/home).
Tyto SSD disky mají specifikovánu propustnost 195000 IOPS v případě čtecích operací a 31000 IOPS v případě zápisových operací velikosti 4 KiB. Celkem se tedy v RAID10 svazku dostáváme na 8*195000 = 1560000 čtecích a 8*31000 = 248000 zápisových IOPS.
Migrace, zajímavé problémy
Naší ambicí bylo provést migraci s co nejmenšími výpadky. Nevyhnutelný byl výpadek při montáži nových řadičů do serveru Anxur, který trval necelou hodinu.
Pak jsme již mohli za běhu systému zapojit disky a po jejich otestování (včetně reklamace jedné z polic) přidat nové svazky do stejné LVM volume group, ve které bylo původní pole. To umožnilo přesunovat data svazků mezi disky starého a nového pole za běhu systému pomocí příkazu pvmove.
Přesun menších svazků proběhl bez problémů, k těm došlo až při přesunu o dva řády většího svazku /home. Z nám neznámého důvodu i přesun jen jediného bloku dat začalo staré diskové pole generovat velké množství zápisů, což způsobovalo jeho zpomalení a velmi nepříjemný uživatelský zážitek. Vzhledem k tomu, že by toto zpomalení trvalo celou dobu přesunu odhadovaného na více než týden, byli jsme nuceni od původního plánu, po neúspěšném pátrání po příčině, ustoupit.
Použili jsme tedy osvědčený způsob: pomocí programu rsync jsme za běhu vytvořili ne zcela konzistentní kopii /home a pak během nočního výpadku dokopírovali zbytek dat. Finální kopírování jsme zahájili v pátek večer po 8. hodině, dokončilo se v sobotu ráno po 6. hodině.
Testovací restart serveru odhalil problém se sestavováním RAID pole během bootu systému. Zjistili jsme, že v implicitním nastavení dobíhá v systemd detekce LVM physical volume příliš brzo a nestihnou se inicializovat RAID svazky vytvořené nad multipath zařízeními. Vyřešili jsme to přidáním explicitní závislosti služby lvm2-activation-early.service na zařízeních dev-md2.device a dev-md3.device, která odpovídají RAID svazkům.
Zhodnocení
Hlavní motivací upgrade bylo krom obnovy dosluhujícího HW také zvýšit rychlost přenosu dat mezi disky a koncovým uživatelem. Jako úzké místo jsme vnímali právě diskové pole a po zkušenostech z posledních dvou měsíců můžeme konstatovat, že cíl byl splněn. Zatímco minulý rok docházelo na začátku více obsazených cvičení vyučovaných v Linuxových učebnách k neúnosným prostojům při přihlašování uživatelů, letos jsme nic takového nezaznamenali. Stejně tak graf zatížení serveru Anxur indikuje pozitivní změnu (čas migrace /home na nové pole je vyznačen zeleně):
Zajímavé je také porovnat latence původních svazků md0 a md1 (světle červeně je maximální, tmavě je průměrná):
s daty pro nový SSD svazek:
Můžeme si všimnout, že md0 byl pod větší zátěží než md1. A zatímco maximální latence se pohybovala v řádu desítek až stovek milisekund, u SSD to jsou jednotky. Průměrná latence je v případě SSD v milisekundách neměřitelná.
Občas je užitečné, když si studenti informatiky na vlastní kůži vyzkouší, co znamená přístup mnoha procesů ke sdílenému zdroji. Ovšem nic se nesmí přehánět. Za unix@fi přejeme příjemné a ničím nerušené užívání nového diskového pole.
