Archiv pro měsíc: Únor 2013

Test rychlosti ZFS s kompresí a ZIL

Nějakou dobu se mi doma povalují disky ze starších serverů, povětšinou SAS 73GB 15k RPM. Pro tyhle disky už v dnešní době nemám moc využití, do serverů jsou prostě malé. Chtěl jsem ale vyzkoušet, zda by mohly efektivně sloužit alespoň jako ZIL u ZFS a být mi tak k něčemu dobré.

Testy jsem prováděl na náledujícím stroji s nainstalovaným SmartOS

Fujitsu-Siemens Primergy RX300 S3 D2119
2x Quad-core Xeon (bez HT, konkrétní typ ještě doplním)
12 Gb DDR2 FBDIMM
2x Fujitsu 146GB 10k RPM MAX3147RC (zpool)
2x Seagate 73GB 15k RPM ST373455SS (ZIL)

První sada testů probíhala nad mirrorem ze 146GB disků bez ZILu:

pool: zones
 state: ONLINE
  scan: resilvered 4.00G in 0h0m with 0 errors on Sun Feb 24 21:56:41 2013
config:

        NAME        STATE     READ WRITE CKSUM
        zones       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c0t0d0  ONLINE       0     0     0
            c0t1d0  ONLINE       0     0     0

errors: No known data errors

Druhá sada testů probíhala nad stejným poolem s přidaným mirrorem ze 73GB disků jako ZILem:

pool: zones
 state: ONLINE
  scan: resilvered 4.00G in 0h0m with 0 errors on Sun Feb 24 21:56:41 2013
config:

        NAME        STATE     READ WRITE CKSUM
        zones       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c0t0d0  ONLINE       0     0     0
            c0t1d0  ONLINE       0     0     0
        logs
          mirror-1  ONLINE       0     0     0
            c0t3d0  ONLINE       0     0     0
            c0t4d0  ONLINE       0     0     0

errors: No known data errors

První test v každé sadě probíhal s vypnutou kompresí:

zfs set compression=off zones

Druhý test v každé sadě probíhal se zapnutou kompresí GZIP na nejvyšší level:

zfs set compression=gzip-9 zones

Testoval jsem pomocí bonnie++ s následujícím nastavením:

bonnie++ -d /zones/bonnie -u 0 -n 256

Pro snadnější porovnání výsledků jsem sestavil přehlednou tabulku:

ZFS ZIL compression test results

Co si z toho všeho vyvodit?

  • Použít 15k RPM SAS jako ZIL pro 10k RPM SAS nemá cenu. Možná by výledky byly lepší, kdyby byl pool ze 7200 RPM SATA disků, ale pochybuju o tom. Možná by byly lepší, kdyby bylo více konkurentních zápisu, ale dělat další testy se mi už nechce.
  • To že komprese disku zrychluje jsem věděl už předtím, ale že je to o tolik, to jsem opravdu netušil. Ačkoliv z raw výsledků je patrný slušný nárůst využití CPU, komprimovat pool se jednoznačně vyplatí.
  • Pro někoho může být matoucí, že se komprimovaná data čtou a zapisují rychleji, než data nekomprimovaná. Je to z toho důvodu, že disk díky kompresi musí provést méně seeků, ať už při čtení nebo zápisu. Na dnešních CPU je overhead komprese opravdu malý, výkon serveru jako celku to tedy ovlivní spíše pozitivně.
  • Pozor na některá SSD, která by jste chtěli použít pro pool. Často si data komprimují samy, aby méně opotřebovávaly paměťové čipy. V takovém případě je komprese na poolu spíše kontraproduktivní.

ZIL: off, komprese: off

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
test            24G 69331  58 68951  14 26294   7 47317  45 55544   6  1362   5
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                256 13680  97 43499  68 10799  49 17940  97 42623  67 24912  98

ZIL: off, komprese: gzip-9

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
test            24G 118003 99 270385 56 104136 29 73052  69 197714 20  9246  40
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                256 14627  99 62096  99 26730  99 17557  99 73472  99 25722  99

ZIL: on, komprese: off

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
test            24G 69493  59 67928  14 26515   7 47986  46 55534   6 908.3   2
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                256 16239  99 42565  98 26451  99 17479  99 72271  99 25860  99

ZIL: on, komprese: off

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
test            24G 117788 99 272982 57 105002 30 73069  69 197627 20 10390  41
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                256 14035  98 69112  99 26849  99 18608  99 65876  93 25567  99

Jak do SmartOS dostat SSH authorized_keys pro roota

Domovský adresář roota je ve SmartOS na ramdisku, veškeré změny v něm tedy budou po rebootu serveru ztraceny. Naštěstí má ale SmartOS mechanismus, jak do SHH dostat alespoň authorized_keys pro roota.

mkdir /usbkey/config.inc
# Vložte public svůj ssh klíč
vim /usbkey/config.inc/authorized_keys
echo "root_authorized_keys_file=authorized_keys" >>/usbkey/config

Jak zprovoznit htop ve SmartOS global zóně

Docela jsem si zvykl na htop a ačkoliv ve SmartOS zónách funguje, v globální zóně tomu tak není. Pro svůj chod htop potřebuje linuxový /proc filesystém, který v globální zóně není. S trochou snahy jej ale můžeme dodat.

Pokud jste ještě do globální zóny nenainstalovali pkgin, je právě čas. Návod najdete na wiki smartosu. Samotný htop pak snadno nainstalujeme pomocí příkazu:

pkgin in htop

Nyní vytvoříme shell shkript, který nám namountuje lxproc a umístíme jej do souboru /opt/custom/method/fs-lxproc.

#!/sbin/sh

. /lib/svc/share/smf_include.sh

if smf_is_globalzone; then
    mkdir /system/lxproc
    mount -F lxproc lxproc /system/lxproc
fi

exit $SMF_EXIT_OK

Adresář /op/custom a jeho podadresáře ještě pravděpodobně vytvořeny nemáte, založte je tedy. Budeme pokračovat vytvořením XML definice pro SMF, aby se náš mount skript spouštěl automaticky. Skript uložíme do souboru /opt/custom/smf/lxproc-fs.xml. Do tohoto adresáře lze uložit i jiné definice SMF služeb, SmartOS je při bootu načte a spustí.



    

        
        

        
            
        

        
        

        
            
        

        

        
    

Nakonec XML definici načteme do SMF.

svccfg import /opt/custom/smf/lxproc-fs.xml

Solaris + ZFS + KVM = SmartOS

Stabilní KVM na Solarisu? Je to tak! Projekt Illumos dostal díky Joyentu vlastní port KVM. SmartOS je na Illumos založená distribuce spojující ZFS, DTrace, Solaris zóny a ano, KVM!

Distribuce je to trochu nezvyklá, neinstaluje se na disk, ale spouští se z USB flash disku nebo bootuje pomocí PXE ze sítě. Většina filesystému je read-only, samotné služby se instalují až v zónách, pro jejichž správu Joyent přidal spoustu nástrojů.

Měl bych upozornit že KVM ve SmartOS funguje jen na serverech, jejichž procesory podporují EPT. Není to tedy virtualizační platforma pro starší stroje, ale 55xx a 56xx Xeony už EPT mají. Dokonce i bez podpory EPT SmartOS stojí za vyzkoušení. Dle mých testů jde 90% služeb které provozuji na Linuxu bez problému rozchodit i v Solaris zóně.

Za zmínku stojí ještě tyto věci:

  • „apt-like“ binární balíčkovací systém pkgin
  • SMF (Service Management Facility) jako advanced náhrada rc skriptů
  • Virtuální ethernet rozhraní, virtuální switche a virtuální routery – dá se s tím kouzlit 🙂
  • Nástroj imgadm pro práci s šablonami vps, spoustu předpripravených konfigurací vps
  • Perfektní správa zdrojů přidělených zónám a vps

Pokud spravujete vps na na Linux hostu, doporučuji SmartOS alespoň vyzkoušet.

Možnosti nasazení CEPH s ProxmoxVM a Ubuntu VPS

CEPH je velice zajímá technologie kombinujcí object storage, block storage a filesystem.

One Object Storage: The Ceph Object Store, called RADOS, is the object storage component for CephFS filesystems, Ceph RADOS Gateways, and Ceph Block Devices.

Many Storage Interfaces: You can use CephFS, Ceph RADOS Gateway, or Ceph Block Devices in your deployment. You may also use all three interfaces with the same Ceph Object Store cluster! There’s no reason to build three different storage clusters for three different types of storage interface!

Use Commodity Hardware!: You can deploy Ceph with commodity hardware. You don’t need to purchase proprietary storage or networking hardware commonly used in SAN systems.

Při testech jsem zjistil následující:

  • Pro testy je potřeba minimálně dvou OSD (nodů pro ukládání dat)
  • ProxmoxVE 2.2 kernel nemá modul rbd
  • Ubuntu virtual kernel nemá modul rbd
  • Proxmoxu ještě nějakou chvíli potrvá, než CEPH zařadí do svých balíků, zdali vůbec

CEPH si určitě zaslouží sledovat a testovat dál, ale v současném stavu bych jej v kombinaci s Proxmoxem nedoporučoval, pokud nechcete sami kompilovat a udržovat balíky.

Test rychlosti úložišť KVM – qcow2 vs raw

Pro virtualizaci na Linuxu už delší dobu používám výbornou platformu založenou na debianu – ProxmoxVE. Ačkoliv jsem v Proxmoxem velice spokojen, některé věci mi v něm vadí a tak jsem chtěl vyzkoušet postavit platformu vlastní nad Ubuntu, které mám daleko raději. Před stavbou samotnou jsem chtěl udělat test, jak je na tom Ubuntu a libvirt s výkonem IO operací.

Aby to bylo trochu zajímavější, chtěl jsem otestovat jak diskové obrazy qcow2, tak i raw. Qcow2 image byl před testem „nafouknut“ pomocí dd, abychom testovali reálnou výkonnost, ne rychlost alokace místa pro image. VPS image byly umístěny na LVM2 nad RAID1 polem.

Test jsem po prvních výsledcíh z Ubuntu přerušil a nechtělo se mi pokračovat, dám tedy k dispozici alespoň výledky testů qcow2 vs raw. Je mi jasné že tohle nejsou moc relevantní testy, ale pro mé účely posloužily a pár závěrů se z nich vyvodit dalo:

  1. Obrazy qcow2 jsou jednoznačně rychlejší než raw obrazy. Přisuzuji to nějaké cache, kterou qcow2 obrazy musejí mít.
  2. Tohle neplatí pro Ubuntu s libvirt, tam to vyjde skoro nastejno.
  3. Na Ubuntu s libvirt jsou qcow2 obrazy oproti Proxmoxu pomalejší.

Pro test byl použit následující stroj

  • Dell PowerEdge 1950 G4V183J
  • 2x Quad Core Xeon E5335 @ 2 Ghz
  • 24GB DDR2 FB-DIMM 667 MHz
  • LSI SAS1068 PCI-X Fusion-MPT SAS
  • 2x FUJITSU MAX3073RC 15000rpm 73GB

Nafouknutí qcow2 obrazu

test1# dd if=/dev/urandom of=temp bs=10485760 count=2560
dd: writing `temp': No space left on device
1909+0 records in
1908+0 records out
20010160128 bytes (20 GB) copied, 2141.45 s, 9.3 MB/s

Informace o qcow2 obrazu

proxmox# qemu-img info test1.qcow2
image: test1.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 20G
cluster_size: 65536

ProxmoxVE balíky

  • bonnie++ 1.96
  • lvm2 2.02.95-1pve2
  • pve-kernel-2.6.32-16-pve 2.6.32-80
  • pve-qemu-kvm 1.2-7
  • qemu-server 2.0-64

Konfigurace VPS pro test qcow2

-smp sockets=1,cores=4
-m 4096
-device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200
-drive file=test1.qcow2,if=none,id=drive-virtio0,aio=native
-device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100

Konfigurace VPS pro test raw

-smp sockets=1,cores=4
-m 4096
-device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200
-drive file=test2.raw,if=none,id=drive-virtio0,aio=native,cache=none
-device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100

Test pomocí hdparm na qcow2

test1# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads:   6028 MB in  2.00 seconds = 3015.90 MB/sec
Timing buffered disk reads: 994 MB in  3.00 seconds = 331.18 MB/sec
test1# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads:   5878 MB in  2.00 seconds = 2941.77 MB/sec
Timing buffered disk reads: 2022 MB in  3.00 seconds = 673.72 MB/sec
test1# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads:   5574 MB in  2.00 seconds = 2789.37 MB/sec
Timing buffered disk reads: 2000 MB in  3.00 seconds = 666.18 MB/sec

Test pomocí hdparm na raw

test2# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads: 5978 MB in 2.00 seconds = 2991.25 MB/sec
Timing buffered disk reads: 314 MB in 3.06 seconds = 102.48 MB/sec
test2# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads: 5622 MB in 2.00 seconds = 2813.29 MB/sec
Timing buffered disk reads: 316 MB in 3.00 seconds = 105.23 MB/sec
test2# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads: 5498 MB in 2.00 seconds = 2750.66 MB/sec
Timing buffered disk reads: 320 MB in 3.02 seconds = 105.99 MB/sec

Test pomocí bonnie++ na qcow2

test1# bonnie -d bonnie -u 0:0 -n 256
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -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
test1 8G 479 98 39390 6 34188 7 2110 97 885118 85 1666 33
Latency 19228us 57581ms 33761ms 13406us 4360us 60788us
Version 1.96 ------Sequential Create------ --------Random Create--------
test1 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
256 31812 69 355396 99 2622 4 17141 36 451849 99 1706 3
Latency 318ms 640us 11725ms 7707ms 114us 7031ms
1.96,1.96,test1,1,1356636922,8G,,479,98,39390,6,34188,7,2110,97,885118,85,1666,33,256,,,,,31812,69,355396,99,2622,4,17141,36,451849,99,1706,3,19228us,57581ms,33761ms,13406us,4360us,60788us,318ms,640us,11725ms,7707ms,114us,7031ms

Test pomocí bonnie++ na raw

test2# bonnie -d bonnie -u 0:0 -n 256
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -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
test2 8G 477 98 39592 10 24128 4 2083 96 99561 9 606.1 17
Latency 16865us 1188ms 725ms 26275us 35302us 135ms
Version 1.96 ------Sequential Create------ --------Random Create--------
test2 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
256 27477 56 349979 97 1115 1 28242 55 453860 99 857 1
Latency 779ms 631us 15595ms 785ms 79us 14245ms
1.96,1.96,test2,1,1356639819,8G,,477,98,39592,10,24128,4,2083,96,99561,9,606.1,17,256,,,,,27477,56,349979,97,1115,1,28242,55,453860,99,857,1,16865us,1188ms,725ms,26275us,35302us,135ms,779ms,631us,15595ms,785ms,79us,14245ms

Ubuntu 12.04 LTS na qcow2

test1# bonnie -d bonnie -u 0:0 -n 256
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -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
test1 8G 476 98 37107 5 29894 6 2132 96 878243 82 1365 40
Latency 16726us 1467ms 822ms 4232us 5511us 73827us
Version 1.96 ------Sequential Create------ --------Random Create--------
test1 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
256 26194 53 354900 99 1013 1 26470 52 453667 98 813 1
Latency 851ms 617us 15240ms 888ms 51us 16378ms
1.96,1.96,test1,1,1356655754,8G,,476,98,37107,5,29894,6,2132,96,878243,82,1365,40,256,,,,,26194,53,354900,99,1013,1,26470,52,453667,98,813,1,16726us,1467ms,822ms,4232us,5511us,73827us,851ms,617us,15240ms,888ms,51us,16378ms

Ubuntu 12.04 LTS na raw

test2# bonnie -d bonnie -u 0:0 -n 256
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -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
test2 8G 476 98 37935 10 24315 4 2202 98 896357 84 1310 39
Latency 16929us 827ms 856ms 3895us 1821us 70495us
Version 1.96 ------Sequential Create------ --------Random Create--------
test2 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
256 26764 55 359721 99 1052 1 27046 53 457961 98 803 1
Latency 806ms 641us 16137ms 858ms 66us 17820ms
1.96,1.96,test2,1,1356657989,8G,,476,98,37935,10,24315,4,2202,98,896357,84,1310,39,256,,,,,26764,55,359721,99,1052,1,27046,53,457961,98,803,1,16929us,827ms,856ms,3895us,1821us,70495us,806ms,641us,16137ms,858ms,66us,17820ms

Jak se přestat vymlouvat a založit si blog

Už poměrně dlouhou dobu jsem se chystal že si založím blog. Důvody a motivaci jsem měl, ale chuť dotáhnout tu myšlenku nějak chyběla. Dnes se konečně podařilo a tak mám pro vás pár tipů.

  1. Když máte pocit že by něco stálo za sepsání, napište si to do Wordu nebo něčeho podobného co máte po ruce. Pokud zrovna nevíte jak to celé sepsat nebo formulovat, napište si alespoň poznámky, ať se k tomu můžete vrátit později.
  2. Když už se vám to začne hromadit, začnete přemýšlet že už by to teda fakt chtělo někam ven. Chce to doménu. Během času jsem mnohokrát klidně i pár hodin seděl nad ověřovačem domén a zkoušel co mě napadne. Nenapadla mě žádná, co by ještě nebyla obsazená. Dejte tomu čas. Když vás semtam něco napadne, napište si to, ověřit to můžete později. Nemá cenu nad tím trávit hodiny.
  3. Možná byste taky jako já rádi blog svůj vlastní. Nedělejte to. Nainstalujte WordPress, je to za pár minut a nevypadá to špatně. Ono vždycky půjde nějak přejít na vlastní řešení. Stejně tak se nezabývejte šablonou. Na to bude čas až bude chuť. Čtenáři vám na blog nebudou chodit kvůli vzhledu.