Hraní s malým serverem III.- LUKS

29.3.2013 00:36 | Přečteno: 1260× | LittleServer | | poslední úprava: 29.3.2013 10:15

Takže opět nějaké informaci spadající do kategorie definované nadpisem. Srovnání „algoritmů“ při čtení a zápisu a i ve spojení s mdadm. Jako první zde mám dva grafy, test probíhal zápisem/čtením 4GiB souboru (dd if=/dev/shm/files of=… bs=1048576 oflag=sync), jako podklad byl RAID0 přes čtyři disky, čtení probíhalo i bez vyprázdnění cache, ale je zbytečné to prezentovat, protože to o ničem moc nevypovídá, rychlost byla mezi 1.1 a 1.3G B/sec. Uveden je tedy graf jen po „po vyprázdnění cache“ (sync && echo 3 > /proc/sys/vm/drop_caches && sleep 1). Během procesu bylo v druhém procesu sledováno vytížení procesoru pomocí 'mpstat 1 1' a průměrná hodnota je uvedena v grafu, jedná se o čtyřjádro HT, tedy 12.5 % znamená plně výtížené jádro. U prvního grafu (zápis) je vytížení CPU násobené 10, pro lepší čitelnost.
Grafy, zápis a čtení (červeně označený výchozí volba na CentOs 6.4).


V přílohách je k dispozici i graf čtení a zápisu v jednom.

Záznam průběhu zápisu je vidět na následujících dvou grafech, první bez „šifrování“ a druhý s přednastaveným.

Jak je vidět, průběh obsazování paměti je totožný (proč by neměl…), jen vytížení procesu je trochu vyšší.
„free“ v označení datové řady by se mohlo zdát zavádějící, protože se jedná o obsazenou paměť, ne o volnou, ale je to údaj zjišťovaný pomocí free (≈ každou sekundu).

Když se podíváme na dosažené vysoké hodnoty, tak to si asi uvědomíme, že rozdíly rychlosti nejsou zas tak důležité pokud to bude třeba na (mdadm) RAID6.
Zde jsou srovnané jednotlivé „level-y“ RAID, vytvářené pomocí mdadm (na 2+2 discích RED a SEA.). I RAID1 je přes čtyři disky, což není asi typická konfigurace.

Ze srovnání hodnot, zjistíme, že „ty nejrychlejší“ algoritmy šifrování, jen znatelně ovlivňují výkon úložiště. Zajímavé je vidět, že při čtení je dokonce šifrované rychlejší, ověřoval jsem to 2× a prostě to tak vychází, pravděpodobně při dešifrování dochází k více optimálnímu čtení vhdonějšímu pro RAID0 a dané disky.

Mám pár dalších údajů, ale (asi) nevím jak je správně vizualizovat, protože jsem se snažil zjistit i rychlost v různých kombinacích. Můžeme šifrovat „podklad pro LVM-ko“ a tím pádem máme všechny LV šifrované, ale na slabším více-jádrovém HW je někdy vhodnější, šifrovat jednotlivé LV protože se dosáhne vyššího výkonu, ale tady je to „rozpačité“. Mám ty údaje ve více grafech, ale komplexní informace z toho nevidím, vždy jen „nějaké konkrétní pro srovnání“

Tady jsem jen vybral dva grafy, ale asi nestojí za to :(. U variant končící 4× se jedná o šifrování až nad LV, poslední řádek, je dokonce 4x RAID10 nad oddíly, nad RAID-em je LUKS, a nad každým LUKS je LVM-ko s jednou LV (4× RAID, 4× LUKS, 4× VG), jinak se jedná vžy o RAID, LVM, LUKS.
V následujících grafech je na ose X vynesena rychlost MB/s, ne čas testu, jako v předchozích grafech.

Vidět je z toho jen, že při paralelním zápisu (4×) je v zásadě (na tomto HW) nevýhoda vytvářet více šifrovaných LV, ale raději šifrovat „podklad“, jen při čtení nad RAID10 by bybylo vhodnější šifrovat každou LV zvlášť.

A čím jsem sebe pobavil (naštval)?

1. Když jsem ty závěrečné „nic překvapivého neříkající“ testy, které jsem dělal jako první, a nemám je moc automatizované (trochu jo), provedl, udělal grafy, a hleděl na divná čísla a došlo mi, že jsem před testy nepočkal než se resync-nou pole.
2. U úvodních testů, které jsou plně automatizované a samy se monitorují a ukládají výstupy, tak údaje o vytížení procesoru byly dost divné, než mě došlo, že jsem mpstat použil bez parametrů…

       

Obrázky

Komentáře

[Nikt0]

Pekne :)

[Miloš Kozák]

Závěrečné doporučení?

[Šangala]

Pokud k těmto výše uvedeným informacím, tak:

• LUKS a „algoritmus“- tam bych dodržel pravidlo, „neměň přednastavený, pokud opravdu nevíš co děláš“ (toho se držím já)
• LUKS nahoře nebo dole - kydž je třeba šifrovat vše (což je pohodlné, bo disk lze v klidu reklamovat), tak to jsem napsal, na takovémto HW téměř jistě dole, je to pohodlnější a má to stejný nebo lepší výkon, s drobnou výjimkou a to je čteni na RAID10 a vzhledem k tomu, že u zápisu je výkon stejný, tak lze vyměnit pohodlí za lepší výkon (a šifrovat až jednotlivé LV) při paralelním čtení z různých LV (rozdíl je vidět v posledním grafu, jak světle modrá utekla zelené).
• RAID - Pokud se jde po výkonu a používá se RAID0, tak se není o čem bavit, ale pokud chcete mít data chráněná před zklamáním jednoho disku, tak je to složitější. V konfiguraci čtyř disků je , podle mě, RAID6 kravina, takže zbývá RAID5 a RAID10, pokud chceme být v klidu a mít i lepší výkon čtení je RAID10 jasná volba, pokud nás ovšem zajímá kapacita, tak je to RAID5 s nižší rychlostí zápisu. (Pro zajímavost, ještě není jasné jestli tam bude ve finále 5-ka nebo 10-ka, protože vlastně nevím, který požadavek převažuje kapacita vs. jistota)
• Obecně - LUKS téměř nesnižuje výkon (za určitých okolností i nepatrně zvýší). Takže určitě šifrovat, je to v důsledku levnější a snižuje to riziko nalezení „seznamu, komunikaci s chystaným upgrade manženlky nebo naopak fotky manželky s natáčkami“ na ftp-úschovně.
  Bohužel poslední dva testy/grafy jsou dělány s jinými parametry (dd s různým nastavím bs pro každý soubor, což vytvoří zásadní rozdíly) než předchozí, takže absolutní hodnoty posledních dvou grafů nelze srovnávat s ostatními grafy (předchozí mají stejné parametry i metodiku).

[pavlix]

Mně se RAID6 líbí i na čtyřech discích.

[Šangala]

TO samozřejmě může, a co se ti na něm přesně líbí?

[pavlix]

Že umožňuje pokračovat při výpadku libovolných dvou disků.

[Šangala]

Ju, ale synchronizace bude časově náročnější než u RAID10 (kde mohou vypadnou dva, ale jen ty správné) a to i na stávající disky, tak proti „libovolných“ může být „nenáročná synchronizace“ (která může ovlivnit ještě dobré disky).
Čekal jsem ten argument, bo jiný mě nenapadl, takže je určitě správný, nicméně „podle mě“ je RAID6 na 4 disky stejně kravina :).

[pavlix]

nicméně „podle mě“ je RAID6 na 4 disky stejně kravina :).

Chápu. Obrana proti výpadku dvou disků tě nezajímá :).

[Šangala]

Musíš tam dát to slůvko „libovolných“ jinak ti to neodkývnu :).

[pavlix]

Pokud nemáš dar předpovídat, které disky nevypadnou, zůstanu u formulace, kterou jsem použil.

[Semo]

Obecně - LUKS téměř nesnižuje výkon

Len aby to niekto nevzal uplne dogmaticky: existuje hw, kde vykon s LUKSom je 1/3 vykonu bez neho. Pred par mesiacmi som instaloval OpenSUSE 12 na netbook (rotacny disk, CPU Intel Atom 1-core). Vykon disku priamo cca 60MB/s, cez LUKS cca 20MB/s. Vzhladom na vyssiu moznost nechceneho opustenia hw v takto mobilnom stroji to ale bolo majitelkou vyzadovane. Je to ale nieco, co sa rozhodne neda nazyvat "malym serverom".

[Šangala]

Omlouvám se za mystifikaci, to „obecně“ jsem myslel ve vztahu k uvedenému a podobnému HW.
LUKS určitě snižuje výkon vždycky a pokud je to atom, tak ten ho nemá nazbyt, takže to jde do háje.

[Jimmy]

Hlavní rozdíl dnes bude v tom zda daný procesor má HW podporu pro šifrování AES nebo ne. Jako malý server jsem do minulého týdne používal stroj s VIA C7 a přestože je C7 určitě slabší než Atom, tak rychlost čtení ze šifrovaného disku byla limitována diskem a např. po síti nebyl problém přes FTP dosahovat přes 90 MB/s. Když jsem hledal náhradu, tak jsem hledal něco s podporou AES-NI a skončil jsem u téměř nejslabšího dvoujádrového AMD A4-5300. Čtení přímo z disku jsem tam zatím netestoval, ale hashovaní obsahu šifrovaných disků probíhalo rychlostí až 145 MB/s, což byl opět limit disku.

Pokud ale člověk chce za procesor něco od Intelu, tak má problém. Atom AES-Ni neumí, Core i3 to neumí, některé i5 také ne, takže výběr levných a úsporných procesorů se rapidně zmenšuje.

[Šangala]

Ju, levných chápu, úsporných mám trochu vnitřní problém do této skupiny řadit běžná AMD-čka, bo sestavy v idle žerou zbytečně moc. Ale je fakt, že jsem vůči AMD CPU zaujatý (díky zkušenostem „jak šel čas“; první odpálené CPUs při výpadku chladiče, pak jsem se i jednou o něj popálil :), pak obráceně řízení otáček ventilátoru, pak nepoužitelná čtyř-jádra, na kterých když se spustili čtyři výpočty, tak už nešlo snad ani pohnout myší (oproti Core2 Duo) a na konec zklamání z odběrů v idle…).
Jen pro zajímavost nevíte kolik to (sestava) žere v idle a v běžné zátěži (AMD A4-5300), ať si zlepším názor…

[Jimmy]

Spotřebu jsem řešil a sledoval. Přestože TDP té A4 je 65W, tak jsem naměřil následující: 2x 2,5" disk + 1x 3,5" 7200 ot/min, 2x4 GB RAM, deska s chipsetem A85.

Při idle je spotřeba 40W, při hashování disku, kdy 3,5" disk běžel na plno a procesor jel na 50% byla spotřeba 65-67W. Při startu se objevují i vyšší čísla cca 70-80W. Při takto malé spotřebě už hodně záleží i na zdroji. Mám tam nějaký starší 350W, který má dokonce jen 20pin ATX konektor a k tomu 4 pin pro CPU (takže všechny konektory na desce nejsou zapojené !). Když jsem zkoušel jiný, který byl ale moc hlučný, tak spotřeba v idle byla o cca 5W výše. Předpokládám, že nový zdroj s 80+ by se zas dostal o 5 W níže.

Se spotřebou jsem tedy spokojen. Předchozí VIA C7 s TDP 15W měla spotřebu stejnou, při neporovnatelném výkonu. Vzhledem k tomu, že server tráví většinu času blízko idle stavu, tak mě spotřeba ve špičkách, které trvají celkem krátce nijak netrápí.

[Jimmy]

Ještě mě napadá, že něco přes 1W žere větrák, který chladí disky a který bych asi mohl odpojit, vzhledem k tomu, že po přesunutí do sklepa server hlásí teploty disků +15°C, +16°, +20° a CPU 0°C , což je blbost, ve sklepě je teplota vzduchu +9°C. Takže 1-2W by ještě šlo ušetřit.

[Šangala]

No a když to srovnám s tím co popisuji výše, tak v idle, když usnou 4 disky je příkon 39.7 W a s těmi 4 disky (celkem 6-ti) je to 55-56 W a už jsou v tom 2× 120-ka a 1× 140-ka ventilátor (a dva 1TB disky a 32GiB RAM). A zatím, i když jsem to zatěžoval na všech jádrech jsem nedosáhl 100W.
Abych předešel, ano cenový rozdíl tam je…

[Jimmy]

Když mě usnou všechny disky (což se kvůli běžícímu DC nikdy nestane), tak se dostanu o cca 10-15 W níže, tedy na nějakých 25-30W, tedy na nějakých cca 65% spotřeby systému výše na asi tak 10 let starém zdroji. Když bych koupil nový zdroj tak budu na nějakých 55-60%. To je přeci jen trochu jiná liga, samozřejmě včetně výkonu. V každém případě lze i na AMD vytvořit úsporný a rozumně výkoný mini server, i když to při pohledu na udávané TDP tak nevypadá.

Když přežil původní server na půdě, kde v zimě i mrzne, tak bych se kondenzace vlhkosti nebál. Hned po plynovém kotli to bude v tom sklepě druhý nejteplejší objekt, takže není důvod aby tam něco kondenzovalo .

[Šangala]

To není fér, počty mám jiné, pokud vyjdu z vámi uváděného, tj. ventilátor 1-2W tak by to bylo o 3-6W méně, tj. 34-37W, když vypnu poslední dva disky tak ubude 7.4W a to je 26.6 - 29.6.
Navíc by bylo možné vypnout BMC, což by hádám tak 2W ubralo (ve vypnutém stavu a aktivním BMC to má odběr 3.5W, ale něco bere síťovka).
Kdyby bylo první kritérium spotřeba, tak by to byl E3-1220LV2 (TDP 17W), jako jediný z řady má výrazně nižší spotřebu v idle, takže by to možná lízlo 20W.
Se zdrojem je to otázka, pro tu sestavu by stačil 350W zdroj (ale holt blbě se shání „lepší zdroj“ s nižším výkonem) a ztráty zdrojů jsou v % a v minimálním zatížení obvykle vyšší než ve středním zatížení, takže na tom ty „naše“ zdroje v daném režimu mohou být i stejně.
Nechci nijak shazovat vaši sestavu a vychavlovat uvedenou, cenově je to jinde, ale stále to vidím tak, že o úspornosti AMD mě to nepřesvědčilo ani nemohlo, muselo by se to srovnávat k adekvátnímu CPU. Každopádně díky za informace.

[Jimmy]

OK, každý jsme si koupili co jsme chtěli dle předpokládaných potřeb.

Co se týká zdroje, tak jsem zkoušel i účinější pasivní zdroj typu picoPSU podobný tomuto. Účinnost byla dobrá, spotřeba šla o pár wattů níže plus to ticho, ale po cca roce a půl provozu se ukázal fatální problém s tím, že to nebylo stavěné na trvalý provoz. Doslova tam vyhořel vstupní konektor, kde trvale tekly cca 3A a konektor to nevydržel. Sice jsem to opravil, ale už k tomu nemám důvěru to někam zapojit na trvalý provoz.

[Šangala]

Jo a dle hodnot teploty sklepa mě napadá „…teplota, tlak, rosný bod…“, tedy ventilátor bych neodpojoval