Mar 02 2010

Překlad utility SysBench na Debianu Lenny

Tag: Debian,English,HW Tunning,Linux,MySQLJens @ 23:00

Tento článke je k dispozici pouze v jazyce English.


Jan 08 2010

Ceny pevných disků po novém roce

Tag: HW Tunning,ZprávičkyJens @ 01:30

Pokud někdo odložil nákup nového disku na „po vánocích“ či dokonce „po novém roce“, tak by ho mohla zajímat následující tabulka. Jsou v ní uvedeny ceny přepočítané ceny disků na jejich kapacitu — tedy, kolik korun českých zaplatíte za 1GB kapacity (desetinný údaj v tabulce tedy udává Kč/1GB).

kapacita HDD 3.5″ (7200) HDD 3.5″ (5400) HDD 2.5″ (5400) USB 3.5″ (7200) USB 2.5″ (5400)
320 GB 2.99 3.85 5.22
500 GB 2.24 2.28 3.95 3.63 4.70
640 GB 2.16 2.07 3.73 4.30
750 GB 2.55 2.18 4.62 2.49 4.68
1000 GB 2.19 2.05 5.07 2.40 4.79
1500 GB 2.04 1.76 2.17
2000 GB 3.36 2.13 2.23

Disky jsem rozdělil do pěti kategorií:

  1. HDD 3.5″ (7200): interní 3.5″ pevný disk, SATA 2, 7200 otáček
  2. HDD 3.5″ (5400): interní 3.5″ pevný disk, SATA 2, 5400 otáček, úsporný (zde lze zvolit ještě levnější kousek od výrobce Samsung a dostanete se na bezkonkurenční cenu 1.55 Kč/1 GB)
  3. HDD 2.5″ (5400): interní 3.5″ pevný disk, SATA 1/2, 5400 otáček, do notebooku
  4. USB 3.5″ (7200): externí 3.5″ pevný disk, USB 2.0, 7200 otáček, přenosný (vlastní zdroj)
  5. USB 2.5″ (5400): externí 2.5″ pevný disk, USB 2.0, 5400/5200 otáček, ultra přenosný (napájení z USB)

A jak to dopadlo?

  • Vítězem v kategorii cena/kapacita se jednoznačně stává „zelený“, interní 3.5″ disk s kapacitou 1.5TB.
  • V kategorii výkon/kapacita je dobrou koupí rychlý interní, 3.5″ disk s kapacitou 1.5TB.
  • A v kategorii přenosných disků opět vede disk, s kapacitou 1.5TB a o rozměru 3.5″. Pokud zvažuje nákup opravdu kapesního disku, šáhněte po tom s kapacitou 640GB.

Vítězství dnes tedy patří kapacitě 1.5TB … Všechny disky jsou od výrobce Western Digital, ceny jsou přebrány z eshopu Alfacomp (platné k 8.1.2010). Pozn.: 1000GB = 1TB.


Aug 12 2009

Není RAID jako RAID – díl 1. Úvod

Tag: HW Tunning,Linux,RAIDJens @ 21:00

Tímto článkem bych chtěl odstartovat sérii několik článků, které budou věnovány diskovým polím RAID a konfiguraci souborového systému (filesystému) v Linuxu vzhledem k maximálnímu výkonu, dostatečné bezpečnosti a minimální ceně. V seriálu se zaměřím především na softwarový RAID vytvořený pomocí utility mdadm, jeho konfiguraci na úrovni fyzických disků a operačního systém, budou popsány metodiky testování a jednotlivé testy, kterým se bude daná konfigurace testovat. Dalším aspektem bude i výběr souborového systému a jeho nastavení – zde se bude volit mezi systémy ext3, ReiserFS a XFS.

Nebude zde popisovat základní typy RAIDu, to už udělali dávno jiní a lépe, viz třeba česká stránka na Wikipedii o RAID, nebo ještě lépe anglická Wikipedia a RAID a mnoho dalších. Zaměřím se spíše na konkrétní konfigurační postupy a testy, na základě kterých bude možné vybrat konkrétní variantu pro konkrétní aplikaci – tou aplikací bude v našem případě databázový server MySQL, jehož výkonnost je mimo jiné silně spjata s výkonem souborového systému úložiště tabulek a dočasných souborů.

Hardwarový RAID

Hardwarový RAID je speciální kus hardware, který umožní vašemu počítači konfigurovat a spravovat diskové pole bez nutnosti instalace jakýkoliv ovladačů a zcela nezávisle na operačním systému.
Hardwarový RAID lze definovat takto:

  • má vlastní speciální procesor a vlastní paměť (ta může být navíc zálohována speciální baterií pro případ výpadku napájení),
  • je naprosto nezávislý na ovladačích a operačním systému, pro operační systém se tváří jako jeden disk (případně více disků v případě konfigurace více logických RAID svazků),
  • jeho cena je typicky dosti vysoká a pohybuje se v našich končinách na spodní hranici kolem 10 tisíc Kč.

Pokud vám tedy někdo bude tvrdit, že jeho deska za 4 000 Kč má hardwarový RAID, tak se tomu můžete klidně zasmát, protože je to zcela jistě nesmysl. Současné desky totiž mají pouze jednoduchou RAID utilitu na definici RAID pole, nicméně bez ovladačů a operačního systému z toho opravdové diskové pole nikdy nedostanete. Navíc ovladače pro takovéto „fake RAIDy“ existují pouze pro Windows a to často ještě v podivné kvalitě. Integrovaný RAID přímo na desce tedy není nic jiného než marketingový tah a podvod na uživatele, kteří problému příliš nerozumí a jsou ochotní připlatit za něco, co dostanou pouze při splnění speciálních požadavků. Navíc v případě problému s ovladačem takovéhoto RAIDu se vám diskové pole rozpadne, v lepším případě přijdete o data, v horším pak ani do systému nenabootujete.

Opravdový hardwarový RAID je však sofistikovaný kus hardware, který obsahuje vlastní procesor pro výpočet paritních dat (které jinak počítá CPU), zajišťuje rozložení výkonu v rámci zvolené úrovně RAID na fyzické disky. Dále řeší sestavení, obnovu a rozšiřování diskového pole v případě přidání fyzického disku, případně v případě výpadku či havárie havarují disků atd. Dále obsahuje speciální paměť – takzvanou „read/write cache”, do které jsou ukládán data před fyzickým zápisem na disky v případě zápisu (operační systému si tak myslí, že data jsou skutečně zapsána na disku a posílá další, kdežto oni jsou ve skutečnosti pouze v rychlé paměti a zapíší se až v okamžiku, kdy má „fyzický disk volno“ – toto je velmi jednoduše řečeno, celé je to mnohem sofistikovanější a podstatně složitější) a v případě čtení jsou zde uloženy před-načtené bloky dat, u kterých se předpokládá že o ně systém požádá v rámci čtení většího bloku dat. Takováto vyrovnávací paměť řadiče je obvykle v rozmezí 64MB512MB a často bývá zálohována speciální baterií (obvykle volitelná komponenta řadiče), která je schopna data ve vyrovnávací paměti udržet i v případě výpadku napájení. To znamená, že data jsou po celou dobu v paměti udržována a v momentě kdy je počítač znovu spuštěn, řadič zajistí jejich zapsání na disk (ještě před zavedením systému).

Toto vše je schopen hardwarový RAID bez potřeby jakéhokoliv operačního systému nebo ovladače. Operační systém pak vidí celé diskové pole jako fyzický disk a není třeba žádných speciálních aplikací na jeho inicializaci a správu. Takovýto řadič se pak stává na operačním systému zcela nezávislý a je možné ho provozovat bez nutnosti podpory ovladačů od výrobce hardware.

Softwarový RAID

Do této kategorie patří tedy i řadiče pevných disků, které si na hardwarový RAID pouze hrají (a zdá se, že výrobcům těchto předražených „akcelerátorů“ tento trik poměrně vychází) a ve skutečnosti vyžadují speciální ovladače, které instaluje do operačního systému – nazývají se „fake RAID”. Bez nich vám diskové pole fungovat nebude a utilita, která se spouští typicky po ukončení BIOSu počítače tak slouží pouze k tomu, abyste do operačního systému poslali informaci o tom, jak by měl váš RAID vypadat.

Jedná se tedy konkrétně o řadiče/čipsety dodávané přímo na základní desce:

  • Intel: (jižní můstky) ICH7R, ICH8R, ICH9R a ICH10R
  • nVidia: (čipsety) nForce4, nForce 500, nForce 600
  • AMD: (jižní můstky) SB450 (čipsety Radeon Xpress 200, Radeon Xpress 1150), SB600 (čipsety AMD 480/570/580)

Dále se pak prodávají speciální karty (to už je však opravdu vrchol zlodějiny a podvodů na neznalé), především od firmy Adaptec (Adaptec jim říká „HostRAID”), které jsou jakési „hardwarové akcelerátory“ pro RAID pole – které však bez OS a speciálních ovladačů nefungují nebo pouze částečně, přičemž jejich cena je poměrně vysoká.

Jedná se konkrétně o tyto produkty:

  • Adaptec 1220SA (cca 1700 Kč),
  • Adaptec 1225SA (cca 1500 Kč),
  • Adaptec 1420SA a 1430SA (cca 3000 Kč),
  • Adaptec 2405 (cca 6-7 tis. Kč !!!)
  • Adaptec 2410SA a 2420SA (cca 7-8 tis. Kč !!!)

Další softwarové RAIDy, které se však vydávají za RAIDy hardwarové naleznete například na stránce Linux SATA RAID FAQ.

mdadm

Základem softwarového RAIDu pro Linux je utilita mdamd (dříve mdctl), která je součastí linuxového jádra od verze 2. Ta vytváří v systému „md“ (multiple devices) zařízení, které se skládají z jednotlivých blokových zařízení (především fyzických disků a jejich oddílů — /dev/hda, /dev/sda atd.). Tato utilita umí vytvářet (bez potřeby jakéhokoliv „fake RAIDu”) RAID 0, RAID 1, RAID 4, RAID 5, RAID 6 a RAID 10 (a další speciální režimy: LINEAR, MULTIPATH a FAULTY).

Další díly seriálů se budou věnovat především práci s utilitou mdamd, popíšu v nich jednotlivé použitelné režimy RAID pro dosažení našeho cíle (maximálnímu výkon, dostatečná bezpečnost a minimální cena), jejich konfiguraci a sestavení na konkrétním hardware pro který budeme diskové pole optimalizovat. To je pro dnešek vše, můžete se těšit na další pokračovaní, které na sebe nedá dlouho čekat.


May 06 2009

mdadm: RebuildStarted event na Debianu

Tag: Debian,HW Tunning,LinuxJens @ 21:30

Na několikati Debianích strojích, které mám možnost spravovat jsem si až nedávno všiml velmi pozoruhodného úkazu — každou první neděli v měsíci okolo prvním hodiny ráno vyletí zatížení stroje na poměrně vysoké hodnoty, přičemž převažují především iowaity. V zápětí jsem zjistil že to má nastarost softwarový RAID a démon mdadm, který právě v tuto dobu spouští „kontrolu“ softwarového diskového RAIDu — utilita checkarray.

Příčinu jsem našel v souboru /etc/cron.d/mdadm:

#
# cron.d/mdadm -- schedules periodic redundancy checks of MD devices
#
# Copyright © martin f. krafft <madduck@madduck.net>
# distributed under the terms of the Artistic Licence 2.0
#

# By default, run at 00:57 on every Sunday, but do nothing unless the day of
# the month is less than or equal to 7. Thus, only run on the first Sunday of
# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
# hack (see #380425).
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet

Předpokládal bych, že tato utilita „nějak“ zkontroluje příslušný MD oddíl a v případě zjištění nedostatků, spustí jeho synchronizaci. Realita je však jiná, na všech strojích spustila tato utilita kompletní synchronizaci všech oddílů.

May  3 00:57:01 localhost /USR/SBIN/CRON[22337]: (root) CMD ([ -x /usr/share/mdadm/checkarray ] && [ $(date +%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet)
May  3 00:57:02 localhost kernel: [141056.924658] md: data-check of RAID array md0
May  3 00:57:02 localhost kernel: [141056.924663] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
May  3 00:57:02 localhost kernel: [141056.924666] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
May  3 00:57:02 localhost kernel: [141056.924670] md: using 128k window, over a total of 97659008 blocks.
May  3 00:57:02 localhost kernel: [141056.926736] md: delaying data-check of md1 until md0 has finished (they share one or more physical units)
May  3 00:57:02 localhost kernel: [141056.928064] md: delaying data-check of md2 until md1 has finished (they share one or more physical units)
May  3 00:57:02 localhost kernel: [141056.928070] md: delaying data-check of md1 until md0 has finished (they share one or more physical units)
May  3 00:57:02 localhost mdadm[2769]: RebuildStarted event detected on md device /dev/md0
...

Nevím jestli je možné, že za měsíc provozu libovolného stroje se MD svazky tak rozhodí, že je třeba provést pravidelnou synchronizaci, ale přijde mě minimálně divné, že se to dělej na všech vzájemně nezávislých strojích měsíc co měsíc — vždy kompletní synchronizace pro všechny svazky.

May  3 00:57:02 localhost mdadm[2769]: RebuildStarted event detected on md device /dev/md0
May  3 01:00:02 localhost mdadm[2769]: Rebuild20 event detected on md device /dev/md0
May  3 01:04:02 localhost mdadm[2769]: Rebuild40 event detected on md device /dev/md0
May  3 01:07:02 localhost mdadm[2769]: Rebuild60 event detected on md device /dev/md0
May  3 01:10:02 localhost mdadm[2769]: Rebuild80 event detected on md device /dev/md0
May  3 01:12:11 localhost mdadm[2769]: RebuildStarted event detected on md device /dev/md1
May  3 01:12:11 localhost mdadm[2769]: RebuildFinished event detected on md device /dev/md0
May  3 01:18:11 localhost mdadm[2769]: Rebuild20 event detected on md device /dev/md1
May  3 01:24:11 localhost mdadm[2769]: Rebuild40 event detected on md device /dev/md1
May  3 01:30:11 localhost mdadm[2769]: Rebuild60 event detected on md device /dev/md1
May  3 01:36:11 localhost mdadm[2769]: Rebuild80 event detected on md device /dev/md1
May  3 01:41:31 localhost mdadm[2769]: RebuildStarted event detected on md device /dev/md2
May  3 01:41:31 localhost mdadm[2769]: RebuildFinished event detected on md device /dev/md1
May  3 01:48:31 localhost mdadm[2769]: Rebuild20 event detected on md device /dev/md2
May  3 01:54:31 localhost mdadm[2769]: Rebuild40 event detected on md device /dev/md2
May  3 02:02:31 localhost mdadm[2769]: Rebuild60 event detected on md device /dev/md2
May  3 02:09:31 localhost mdadm[2769]: Rebuild80 event detected on md device /dev/md2
May  3 02:18:00 localhost mdadm[2769]: RebuildFinished event detected on md device /dev/md2, component device mismatches found: 128

Z výsledku logu přitom jasně vyplýva, že problém byl nalezen pouze na svazku md3, ale všechny ostatní byly v pohodě.

Proto doporučuji, pokud používate mdadm a váš stroj poskytuje nějakou důležitou službu, jejíž chod by mohlo omezit přílišné zatížení systému v době synchronizace, tuto kontrolu vypnout a spouštět příkazem /usr/share/mdadm/checkarray --cron --all --quiet raději ručně v době, kdy vám to více vyhovuje.


Apr 27 2009

Rozdíl mezi ST3500418AS a ST3500410AS

Tag: HW TunningJens @ 21:30

Jak se liší tyhle dva Seagaty? Naprosto stejná kapacita (500GB), naprosto stejné fyzické uspořádání (1 plotna, 2 hlavy), naprosto stejné téměř všechny ostatní parametry … téměř, jediný rozdíl je ve vydávaném „hluku“ :) viz specifikace:

Drive acoustics, | ST3500418AS         | ST3500410AS
sound power      |                     |
-----------------------------------------------------------
Idle**           | 2.6 bels (typical)  | 2.3 bels (typical)
                 | 2.7 bels (max)      | 2.5 bels (max)
-----------------------------------------------------------
Quiet Seek       | 2.75 bels (typical) | 2.5 bels (typical)
                 | 3.10 bels (max)     | 2.7 bels (max)

Cenový rozdíl? V Softcom je o necelých 30 Kč dražší hlučnější disk ST3500418AS, zajímavé :) V Alfacomp se již tichý model neprodává (prodával se jen několik měsíců, cena 1375 Kč) a hlučnější model je zase o cca 20 Kč dražší :)

Proč se tichý model ST3500410AS tak rychle stáhl z obchodů? A proč je hlučnější model dražší a nahradil tichý? A jak se vůbec vyrábí disk, tak že bude o 0.3 db hlučnější nebo tiší a přitom má úplně stejné všechny parametry?

Podle vyjádření Seagate, které získal server xcpus.com je varianta ST3500410AS více šetrná k životnímu prostředí … viz článek Seagate Barracuda 7200.12 500GB Drive Review (ST3500410AS):

The 410AS model adheres to industry standard „low halogen“ specs and thus is more environmentally friendly than 418AS. The 410AS model also produces less noise than the 418AS model. That’s about all we know, and to date Seagate has done little to distinguish these models from each other in their marketing material, which is odd.


Mar 22 2009

bonnie++: linux filesystem benchmark

Tag: Debian,HW Tunning,LinuxJens @ 01:00

Jak otestovat výkonnost souborového systému na linuxu? Je lepší ext3, ReiserFS, JFS nebo XFS? Jaký RAID použít a jako ho nastavit? Odpověď není jednoduchá, vždy záleží na konkrétní situaci a na konkrétních požadavcích. Jedno je ale jasné, většina z nás chce dosáhnout maximálního výkonu při zachování bezpečnosti uložených dat. To jak otestovat výkonnost filesystému na linuxu je předmětem tohoto článku.

Utilita bonnie++

Tato jednoduchá utilitka testuje zvolený filesystém tím že na něj vytvoří různými způsoby poměrně velké souboru (ve výchozím stavu 2 * velikost RAM po 1 GB — tedy 8 GB RAM = 16 * 1GB souborů), které následně čte a přepisuje. Toto všechno měří a počítá rychlosti jednotlivých operací, navíc v dalších testech umí vyvářet různé (volitelné) množství souborů a adresářů, ke kterým různě přistupuje (mazání a čtení). Otestuje tedy i schopnost filesystému rychle přistupovat k adresářům a souborům.
Instalace bonnie je na Debianu velmi jednoduchá, i ve stable existuje balíček bonnie++:

# apt-get install bonnie++

Spuštění je téměř stejně jednoduché jako instalace, vytvoříte si na testovaném FS nějaký adresář (například /var/bonnie):

# mkdir -m 0777 /var/bonnie
# bonnie++ -d bonnie -u root:root

a už to jede …, výsledek testu se pak zobrazí v textovém formátu přibližně takto (důležitý pro další zpracování je poslední řádek):

jens,16G,62748,98,180566,53,79826,14,71269,94,230871,21,614.8,0,16,31768,100,+++++,+++,+++++,+++,31162,99,+++++,+++,+++++,+++

Tomuto bonnie říká CSV formát, zároveň s utilitou bonnie++ se vám taky nainstalují bon_csv2html a bon_csv2txt. První převádí CSV formát do přehledné HTML tabulky a druhý generuje textovou tabulku.
bon_csv2html lze použít následovně:

# echo "jens,16G,62748,98,180566,53,79826,14,71269,94,230871,21,614.8,0,16,31768,100,+++++,+++,+++++,+++,31162,99,+++++,+++,+++++,+++" | bon_csv2html > bonnie.html

Výsledný soubor bonnie.html je výsledková tabulka s popisky a s výsledky (ke každému testu rychlost a zatížení CPU), pokud provedeme více testování, pak si všechny výsledné řádky dáme do jednoho souboru, např. bonnie.txt a vygenerujete si výsledkovou tabulku pro všechny testy:

# cat bonnie.txt | bon_csv2html > bonnie.html

Při použiti bon_csv2txt získáváte textový výstup:

Version  1.03e      ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
jens            16G 62748  98 180566  53 79826  14 71269  94 230871  21 614.8   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
jens             16 31768 100 +++++ +++ +++++ +++ 31162  99 +++++ +++ +++++ +++

Je důležité říci, co znamenají hodnoty ++++ a +++ ve výsledku benchmarku: tento výsledek znamená, že test proběhl tak rychle (méně jako 500ms), že nebylo možně vyhodnotit správnou hodnotu a proto raději nevypíše nic, než nevypovídající číslo. Z tohoto důvodu je třeba parametry spuštění ještě lehce upravit tak, aby benchmark vyvořil více souborů a aby naměřil nějaké relevantní hodnoty. Vetšinou se s tím setkáte u create testů, které vytváří soubory a adresáře. Proto nastavte parametr -n například takto:

# bonnie++ -d bonnie -u root:root -n 16:10000:16:64

Důležité odkazy na bonnie++: