KVM - disk, jako image u virtualniho serveru

[Slávek Banko]

On Thursday 04 of August 2016 21:43:28 Petr Podrabsky wrote:
> Je to bohuzel zdedena konfigurace. Moc lidi v okoli nemam, kteri s KVM
> pracuji a tak se snazim cist, jak maji ostatni KVM nainstalovane, abych
> to zlepsil. Mozne by stalo zato shrnout stavajici konfiguraci KVM
>
>
> 1 KVM server + 3 VM
>
> virtual mail server
> - image file pro OS
> - image file pro data
> virtual web server
> - image file pro OS
> - image file pro data
> virtual db server
> - image file pro OS
> - image file pro data
>
> Co jsem zatim zjistoval, tak komunikace v ramci VM mezi OS a bude mit
> vliv na IO operace. Dale si myslim, ze web by mohl byt dohromady s mail
> serverem (dalsi uspora IO operaci), jelikoz je potreba z webu posilat
> emaily. Zde je to mezi VM reseno pomoci ssh redirectu portu 25 na mail
> server. To jsou ve zkratce ty nejzasadnejsi veci, ktere si myslim, ze
> by se daly vylepsit. Vzhledem k IO operacim si myslim, ze nema smysl
> mit specialni image pro vsechny virtualy pro data.
>
> Zvetseni velikosti je vsude doporucovane pri vypnuti VM, coz pro
> klienty znamena vypadek sluzby. Pokud by se kopirovaly data o velikosti
> stovek GB, jednalo by se o hodinovy vypadek a to nejde.
>
> Budu vdecny za pripadna doporuceni nebo popostrceni, jakym zpusobem s
> virtualy zachazite.
>
> Petr
>

Pokud mohu konstatovat ze svých zvyklostí:

1) Na hostiteli místo image disků v souborech používat LVM a disky strojů 
mít coby LV. Odpadne tím režie souborového systému na hostiteli. A jako 
bonus získáte velmi jednoduchý způsob navyšování disků pro virtuální 
stroje - spuštění lvextent je tak snadné... :)

2) Je výhodné mít ve virtuálních strojích oddělený disk pro systém a disk 
(nebo disky) pro data => systémový a datový disk lze díky tomu zvětšovat 
nezávisle na sobě. Když si rozumně stanovíte velikost disku pro systém, 
tak obvykle není potřeba navyšovat jeho velikost. Zato u disku pro data 
může být navyšování dost běžné.

3) Na datovém disku vynechat MBR/GPT tabulku. Je zbytečnou překážkou při 
navyšování velikosti disku. Bez MBR/GPT tabulky nebude třeba po navýšení 
velikosti disku měnit i tabulku. A co především - nebude potřeba řešit 
reload tabulky po její změně, což jádro dělá nerado, pokud jsou oddíly 
připojené = používané. Pokud na datovém disku potřebujete více oddílů - 
typicky tmp, var, home, srv, jsou dvě cesty, jak to řešit bez MBR/GPT 
tabulky.

Buď můžete pro každý takový oddíl udělat na hostiteli samostatný image 
disku (tedy LV) a v hostech pak formátovat přímo disk jako celek = bez 
MBR/GPT tabulky. Po navýšení disku na hostiteli pak stačí hostovi poslat 
signál, že se disk zvětšil, a v hostovi poté už jen roztáhnout souborový 
systém - spuštění xfs_growfs je tak snadné... :) Nevýhodou ale je, že na 
hostiteli by byl přehršel oddílů všech hostů.

A nebo můžete v hostovi na jeho datovém disku udělat jeho vlastní LVM - 
opět přímo na disku jako celku = místo MBR/GPT tabulky bude LVM. Po 
navýšení disku na hostiteli pak stačí hostovi poslat signál, že se disk 
zvětšil, v hostovi poté provedete pvresize a z nově navýšeného LVM můžete 
hned navyšovat kapacitu jednotlivých LV hosta - spuštění lvextent && 
xfs_growfs je tak snadné... :)

V obou těchto způsobech lze navyšování velikosti disků / oddílů provádět 
plně za provozu = bez restartů, odstávek, zastavování služeb, odpojování 
souborových systémů.

Výjimkou je jen navyšování systémového disku. Za předpokladu, že hosté 
mají zavaděč systému na svém disku, je dobré mít na systémovém disku 
běžnou MBR/GPT tabulku, aby si hosté mohli svůj zavaděč bez obtíží na 
disk zapsat. Bohužel to ale přináší potřebu měnit tabulku po navýšení 
disku a stejně tak i problém s reloadem tabulky používaného disku. 
Prozatím bohužel nemám rozumnou cestu, jak se MBR/GPT vyhnout i na 
systémovém disku.

-- 
Slávek