Archiv pro rubriku: Úložiště

Instalace (migrace) SmartOS na RAIDZ2

RADZ2 je alternativa Linux RAID6. Na checksum jsou tedy použity dva disky. Nejmenší počet disků, pro které lze tuto konfiguraci použít jsou 4. V takovém případě ale počítejte s tím, že pole bude mít jen poloviční kapacitu součtu kapacit disků.

Další problém pouze 4 disků (pokud ke stroji nemůžete dočasně připojit další) je ten, že SmartOS při instalaci RAIDZ2 pole vytvořit neumí. A když systém nainstalujete jen na jeden disk, ze zbylých 3 disků RAIDZ2 pole nevytvoříte. Jeden disk vám bude chybět. Jak tento nedostatek obejít?

Začneme instalací. Nejprve si systém nainstalujeme pouze na jeden disk.

c0t0d0

Když máme instalaci hotovou, nabootujeme SmartOS bez importu zfs poolů.

Live 64-bit (noinstall)

Importujeme pool zones pod názvem zones2

zpool import zones zones2

Odmountujeme dataset zones2/cores.

Smažeme složku /zones, aby nepřekážela až budeme vytvářet pool zones.

Zjistíme, kolik zabírá celý pool zones2.

zfs list

Vytvoříme pomocí dd prázný sparse soubor větší než velikost poolu zones2.

dd if=/dev/zero of=/disk.img bs=1 seek=40G count=1

Vytvoříme RADZ2 pole ze zbylých 3 disků a soubor z předešlého kroku použijeme jaho čtvrtý disk. Parametr -f je nutný aby příkaz zpool neřval kvůli rozdílným velikostem disků a že mixujeme jednotky a soubory.

zpool create -f zones raidz2 /disk.img c0t1d0 c0t2d0 c0t3d0

Soubor použitý u poolu jako jeden z disků převedeme do offline stavu. Tento krok je důležitý. Bez něj by při přenášení dat mezi pooly došlo na SmartOS ramdisku místo.

zpool offline zones /disk.img

Volitelně můžeme před přenosem zapnout kompresi disku. Soubory se nám pak během přenosu budou ukládat zkomprimované.

Vytvoříme rekurzivní snapshot poolu zones2.

zfs snapshot -r zones2@current

Přemigrujeme data z poolu zones2 do zones. Přepínač -R u zfs send říká, že pošleme rekurzivně i podřízené datasety. Přepínač -p posílá i properties datasetů (např. nastavenou kompresi). Přepínač -F u zfs recv zajistí, že se v cílovém poolu promaže vše, co tam nemá být.

zfs send -Rp zones2@current|zfs recv -F zones

Smažeme snapshot current v cílovém poolu

Pokud vše proběhlo v pořádku, můžeme nyní zrušit pool zones2

Nahradíme soubor použitý při vytváření poolu zones diskem, který se nám nyní uvolnil

zpool replace zones /disk.img c0t0d0

Po chvíli máme data sesynchronizována a pool zones už jede na plnohodnotném RAIDZ2 poli.

zpool status

Nyní je ještě potřeba pool rozšířit na celou kapacitu disků.

zpool set autoexpand=on zones

Projistotu provedeme export poolu.

A uděláme reboot. Po najetí SmartOS s importem poolů vše pojede z právě vytvořeného RAIDZ2 pole. Enjoy!

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

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

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

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

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

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

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

ZIL: off, komprese: gzip-9

ZIL: on, komprese: off

ZIL: on, komprese: off

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

Informace o qcow2 obrazu

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

Konfigurace VPS pro test raw

Test pomocí hdparm na qcow2

Test pomocí hdparm na raw

Test pomocí bonnie++ na qcow2

Test pomocí bonnie++ na raw

Ubuntu 12.04 LTS na qcow2

Ubuntu 12.04 LTS na raw