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 LVM a LVM: 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ší.
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í.
