OpenVZ: disk na virtuálním serveru

Jan Tomášek 25. 9. 2012

Ve čtvrtém dílu seriálu o OpenVZ se podíváme, jak přidělit virtuálnímu serveru diskovou kapacitu ze souborového systému hostitele a probereme výhody a nevýhody tohoto přístupu. Podíváme se také, jak virtuálnímu serveru přidělit dedikované zařízení, na kterém je možno vytvořit souborový systém na míru.

Předchozí díl jsem zakončil tím, že jsem vás nechal vyřešit uživatele CT 1001, který zbytečně vytěžoval procesory počítáním dnetc. Jedním z možných řešení je cílené ukončení procesů buď přímo z hostitele, nebo vstoupením do CT a ukončením procesů uvnitř containeru. Např. takto:

root@ve0:~# vzctl exec 1001 'killall dnetc; chmod -x /usr/local/dnetc/dnetc'

Možnost podívat se přímo na procesy virtuálního serveru je výbornou vlastností OpenVZ. Správce hostitele virtuálních serverů má tak možnost zasáhnout a nemusí nutně omezovat provoz celého containeru. Obdobně příjemný přístup má správce k souborům containeru.

Soubory containeru naleznete v adresáři /vz/root/<CTID>, tedy na defaultní instalaci. U containeru, který běží, je tento diskový prostor k dispozici i v adresáři /vz/private/<CTID>, kam je třeba připojovat i případné další svazky. Proces startu containeru poodhalím později, teď se zastavím u přidělování diskové kapacity přímo z disku hostitele, což je nejpohodlnější metoda.

Disková kapacita z disku hostitele

V případě, že virtuální server využívá diskovou kapacitu z disku hostitele, je její navýšení opravdu snadné. V prvním dílu seriálu jsme vytvořili virtuální server CT 1000, který má k dispozici 1 GB diskového prostoru:

root@ve0:~# vzctl exec 1000 df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/simfs            1.0G  377M  648M  37% /

Je-li nutné navýšit diskovou kapacitu, lze to provést příkazem:

vzctl set <CTID> --diskspace <softlimit>:<hardlimit> [--quotatime <graceperiod>]

kde <CTID> je číslo virtuálního serveru. Parametr softlimit je přidělený diskový prostor, po jehož překročení se aktivuje přechodné období (graceperiod [sekundy]), během něhož může server čerpat disk až do hodnoty hardlimit. Po překročení hardlimit anebo uplynutí graceperiod období, které se nastavuje parametrem, nebude žádný další požadavek virtuálního serveru o disk uspokojen, a to do doby, než dojde k poklesu využití disku pod hodnotu softlimit. Pro zobrazení stavu quoty virtuálního serveru lze použít příkaz:

vzquota stat <CTID>

Prakticky to předvedu na následujících příkladech. Nejprve vypíšu diskovou kapacitu hostitele, následně navýším přidělenou kapacitu CT 1000. Vypíšu diskovou kapacitu hostitele, aby bylo vidět, že přidělování je dynamické až podle potřeby. Nakonec zobrazím informace o čerpání diskové kapacity containerem.

root@ve0:~# df /
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             63331236   3322768  56791420   6% /
root@ve0:~# vzctl set 1000 --diskspace 1500M:2048M --quotatime 300 --save
Saved parameters for CT 1000
root@ve0:~# df /
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             63331236   3322768  56791420   6% /
root@ve0:~# vzquota stat 1000
   resource          usage       softlimit      hardlimit    grace
  1k-blocks         386232         1536000        2097152
     inodes          15491          200000         220000

Vstoupím do virtuálního serveru a zobrazím diskovou kapacitu. Nechám vytvořit soubor o velikosti 1300 MB. Zkontroluji čerpání diskové kapacity, chvilku počkám a zkusím, jestli limit opravdu funguje.

root@ve0:~# vzctl enter 1000
root@deb6:/# df /
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/simfs             1536000    386232   1149768  26% /
root@deb6:/# dd if=/dev/zero of=soubor bs=1M count=1300
root@deb6:/# exit
root@ve0:~# vzquota stat 1000
   resource          usage       softlimit      hardlimit    grace
  1k-blocks        1718736*        1536000        2097152    00:05
     inodes          15492          200000         220000
root@ve0:~# sleep 30
root@ve0:~# vzquota stat 1000
   resource          usage       softlimit      hardlimit    grace
  1k-blocks        1718736*        1536000        2097152     none
     inodes          15492          200000         220000
root@ve0:~# vzctl enter 1000
root@deb6:/# dd if=/dev/zero of=dalsi-soubor bs=1M count=1
dd: writing `dalsi-soubor': Disk quota exceeded

Právě jsem vám demonstroval fungování tzv. quoty první úrovně, tedy quoty aplikované na celý container. Pokud chcete používat quotu i uvnitř containeru (quota druhé úrovně) pro omezování jednotlivých uživatelů či skupin, musíte ji zapnout. To se provádí nastavením parametru quotaugidlimit (prostřednictvím programu vzctl), tato změna vyžaduje restart containeru. Budete-li potřebovat další informace o quotách, nahlédněte do dokumentace.

Disková kapacita z dedikovaného zařízení

Při přidělování diskové kapacity containerům ze společného souborového systému hostitele se můžete setkat s tím, že všem společné parametry souborového systému nevyhoví účelu všech cointainerů. Příkladem, který každého asi napadne, je provoz nějaké velké databáze v jednom containeru a většího poštovního serveru ukládajícího statisíce malých souborů v druhém containeru. V takovém případě je vhodnější přidělit každému virtuálnímu serveru dedikovanou partition se souborovým systémem vyrobeným na míru.

Dalším dobrým důvodem, proč zvažovat použití dedikované partition pro každý virtuální server, je čas kontroly jednoho velkého souborového systému. Kontrola několika terabytů ext3 může zabrat i jednotky hodin. Když rozdělíte prostor mezi jednotlivé containery, hostitel nastartuje rychle, a pak můžete řídit pořadí startu jednotlivých containerů s ohledem na jejich důležitost a očekávanou dobu běhu fsck.

Příkaz vzctl při startu a zastavování containeru spouští řadu skriptů nazývaných action scripts. Celá sekvence je dobře patrná na obrázku z OpenVZ User's Guide na straně 89.

Pro použití dedikované partion pro FS containeru je nutné použít buď global mount script, anebo VPS mount script. Výhodou globálního skriptu je, že udržujete jen jeden soubor, ten musí být pojmenován /etc/vz/conf/vps.mount. Rozhodnete-li se pro mount skript vytvářený extra pro každý jeden cointainer, získáte větší flexibilitu a stejné soubory můžete vyřešit pomocí symbolických linků. Jméno skriptu dedikovaného každému jednomu containeru musí odpovídat schématu /etc/vz/conf/<CTID>.mount.

Skripty jsou spouštěny programem vzctl v průběhu startu/zastavování containeru a vzctl skriptům předává v prostředí proměnné $VEID, což je číslo containeru (staré označení, v seriálu se snažím, kde to jde, používat nové CTID), a pak $VE_CONFFILE, to je konfigurační soubor příslušící containeru, na disku je jako /etc/vz/conf/<CTID>.conf. Z konfiguračního souboru získáte cestu k privátní oblasti virtuálního serveru (default je /vz/private/<CTID>) a také provozní mount point (default je /vz/root/<CTID>).

Mount skript musí zajistit identifikaci zařízení, na němž je uložen souborový systém CT. Já úspěšně používám label přiřazený programem e2label. Pro zajímavost níže uvádím skript, který používám. Funkce get_disk_device () zajišťuje identifikaci zařízení se souborovým systémem containeru. Dělá to právě díky porovnávání labelu ext3/4 souborového systému a CTID. Druhá část skriptu pak provede kontrolu souborového systému, a když je vše v pořádku, připojí ho do privátní oblasti, a následně pomocí bind mountu i do provozní oblasti. Důležitý je návratový kód skriptu - pokud je nenulový, container se nespustí.

#!/bin/bash

. $VE_CONFFILE

# try to locate which device belongs to CT
get_disk_device () {
  cat /proc/partitions | sed "s/  */ /g" | sed "s/^ //" |\
  cut -d " " -f 4 | grep -v 'name' | grep -v '^$' |\
  while read DEVICE
  do
    DEVICE="/dev/$DEVICE"
    if `grep "^$DEVICE " /proc/mount >/dev/null 2>&1`
    then
      echo $DEVICE is already mounted
    else
      LABEL=`e2label $DEVICE 2>/dev/null`
      if [ $? == 0 ]
      then
        if [ "$LABEL" == "$VEID" ]
        then
          echo "$DEVICE"
          return 0;
        fi
      fi
    fi
  done

  return 1;
}

DEVICE=`get_disk_device`;

if [ "x$DEVICE" == "x" ]
then
  echo "Failed to find disk device for VE=$VEID"
  exit 1;
else
  echo "Checking device $DEVICE"
  e2fsck -p $DEVICE
  RET=$?
  if [ $RET -ge 2 ]
  then
    echo "e2fsck returned $RET, terminating."
    exit 1;
  fi
fi

mount $DEVICE $VE_PRIVATE && mount -n -o bind $VE_PRIVATE $VE_ROOT

Typy dedikovaných zařízení pro disky CT

diskový oddíl
Vytvoření dedikované partition na lokálním disku umožní vhodně kalibrovat parametry souborového systému, ale pro budoucnost představuje potenciální potíže při potřebě diskovou kapacitu navýšit.
LVM diskový oddíl
LVM není o mnoho složitější než dedikovaná partition, ale navíc umožňuje změny diskové kapacity, tedy pokud to umožní zvolený souborový systém. Na root.cz vyšly dva články od Adama Štraucha, kde se s LVM můžete seznámit: Úvod do LVMLVM: Praktické ukázky. Ale ani LVM nedovede vyřešit dobu odstávky nutné k přestěhování virtuálního serveru na jiného hostitele. U velkých virtuálních serverů to může být i značná doba, navíc kopírování zbytečně zatěžuje celou infrastrukturu.
iSCSI úložiště
Pro větší nasazení OpenVZ je rozumné zvážit nějaké síťové úložiště. Pro virtualizační platformu, kterou provozuji v CESNETu, používám DELL PowerValut MD3000i. Disky pro jednotlivé virtuální servery vytvářím jako samostatné LUNy a jejich název odpovídá CTID. Díky síťovému poli je zajištěna rychlá migrace souborového systému mezi hostiteli. Bohužel pole neumožňuje zvětšení LUNu, takže navýšení diskové kapacity není zrovna příjemná práce. Častou námitkou proti iSCSI byla rychlost propojení pole a hostitelů, to je 1 Gbps, ale v praxi je mnohem důležitější počet IOPS. Pokud bych vybíral nějaké řešení dnes, chtěl bych u iSCSI zůstat i nadále, ale snažil bych se najít pole, které by umožňovalo velikost LUNu změnit.

Preference každého administrátora budou asi jiné, OpenVZ díky své architektuře umožňuje nasadit téměř cokoli, co administrátor zvládne na Linuxu hostitele uchodit. Budu rád, když se o své osobní zkušeností podložené názory podělíte v diskuzi pod článkem.

Ploop - cointainer v jediném souboru

Alternativou k dedikovaným zařízením pro disky se souborovým systémem pro každý jeden virtuální server je Ploop. V kostce je to cointainer v jediném souboru. Řeší problémy, které jsem zmínil v úvodu předchozí sekce, myslí na podporu snapshotů a živé migrace. Pokud uvažujete o nasazení OpenVZ, pak Ploop rozhodně stojí za zvážení. Doporučuji prezentaci Maxima Patlasova. Já s tím nemám žádné zkušenosti a bez nich se mi nechce opisovat dokumentaci. Pokud by někdo ze čtenářů zkušenosti měl, rád si je v diskuzi pod článkem přečtu.

Zálohování

Používáte-li LVM anebo Ploop, můžete využít snapshotů. Je pravděpodobné, že snapshot bude umět i síťové pole. Ve všech případech je však třeba mít na paměti, že uvnitř containeru může běžet nějaká databáze, nebo obecně cokoli, co drží velké množství dat v paměti, a jejich obraz disku nemusí být konzistentní. Před vytvořením snapshotu je nutné zajistit sync databází na disk a uzamčení pro zápis po dobu vytváření snapshotu. Pokud nemáte data na ničem, co umí snapshot udělat, nezoufejte. Mnohdy postačí, aby správce virtuálního serveru udělal před započetím zálohování dump databází.

Pro zálohování je užitečné, že soubory containeru jsou přístupné hostiteli. Není až tak podstatné, jestli se zálohuje ze snapshotu nebo přímo ze živého FS cointaineru, i když ta první varianta je rozhodně lepší. Pro samotné zálohování můžete použít jakýkoliv mechanizmus, který používáte pro fyzické servery.

Pokud zatím žádný mechanizmus nemáte, je použití inkrementálního režimu progamu GNU tar zajímavá možnost. Nevýhodou je, že pokud se na souborovém systému často mění velké soubory, budou i inkrementální zálohy značně velké. Další nevýhodou je obtížná obnova do okamžiků mimo plné zálohy, v tyto momenty je nutno řešit, které soubory byly od poslední plné zálohy smazány. Výhodou je velká flexibilita a naprostá kontrola nad celým procesem.

Pokud je pro vás tar příliš hloupý, zvažte duplicity, nedávno o něm zde na Rootu psal kolega Caletka. duplicity umožňuje snadnou obnovu souboru, adresáře anebo celého souborového systému. Zálohuje pouze změněné bloky souborů, a tak oproti inkrementálnímu taru ušetříte diskovou kapacitu. Zálohy jsou šifrovány a mohou být nahrávány téměř na libovolné úložiště. Pokud vás vyděsí množství přepínačů duplicity, můžete sáhnout po nadstavbě duply, která použití duplicity docela zjednoduší.

widgety

Zálohování můžete spouštět buď vně virtuálního serveru, anebo uvnitř. Pokud zálohy spouštíte uvnitř, berete na sebe riziko s řešením problémů v případě, že uživatel nějak zálohovací systém poškodí, např. deinstalací komponent, na kterých systém závisí. Výhodou tohoto přístupu je, že uživatel má k zálohám přístup a pokud si něco smaže, může si to i sám obnovit.

V příštím dílu seriálu se podíváme na síťování.

Našli jste v článku chybu?
Lupa.cz: Jak se prodává firma za miliardu?

Jak se prodává firma za miliardu?

Vitalia.cz: Opuncie je plod kaktusu. Pozor na trny

Opuncie je plod kaktusu. Pozor na trny

Vitalia.cz: dTest odhalil ten nejlepší kečup

dTest odhalil ten nejlepší kečup

Podnikatel.cz: Takhle se prodávají mražené potraviny

Takhle se prodávají mražené potraviny

Vitalia.cz: Tahák, jak vyzrát nad zápachem z úst

Tahák, jak vyzrát nad zápachem z úst

DigiZone.cz: Mordparta: trochu podchlazený 87. revír

Mordparta: trochu podchlazený 87. revír

DigiZone.cz: Wimbledon na Nova Sport až do 2019

Wimbledon na Nova Sport až do 2019

Podnikatel.cz: Udělali jsme velkou chybu, napsal Čupr

Udělali jsme velkou chybu, napsal Čupr

DigiZone.cz: Numan Two: rozhlasový přijímač s CD

Numan Two: rozhlasový přijímač s CD

Vitalia.cz: Jaký je rozdíl mezi brambůrky a chipsy?

Jaký je rozdíl mezi brambůrky a chipsy?

Vitalia.cz: 5 pravidel proti infekci močových cest

5 pravidel proti infekci močových cest

Podnikatel.cz: Znáte už 5 novinek k #EET

Znáte už 5 novinek k #EET

Podnikatel.cz: Instalatér, malíř a elektrikář. "Vymřou"?

Instalatér, malíř a elektrikář. "Vymřou"?

Podnikatel.cz: Babišovi se nedá věřit, stěžovali si hospodští

Babišovi se nedá věřit, stěžovali si hospodští

DigiZone.cz: Koncesionářské poplatky pro RTVS

Koncesionářské poplatky pro RTVS

Vitalia.cz: Voda z Vltavy před a po úpravě na pitnou

Voda z Vltavy před a po úpravě na pitnou

Vitalia.cz: Jak Ondra o astma přišel

Jak Ondra o astma přišel

Podnikatel.cz: Byla finanční manažerka, teď cvičí jógu

Byla finanční manažerka, teď cvičí jógu

Lupa.cz: Patička e-mailu závazná jako vlastnoruční podpis?

Patička e-mailu závazná jako vlastnoruční podpis?

Vitalia.cz: Tohle jsou nejlepší česká piva podle odborníků

Tohle jsou nejlepší česká piva podle odborníků