KVM - disk, jako image u virtualniho serveru

[Petr Podrabsky]

Jeste jsem se chtel zeptat, jak resite zalohy/snapshoty image-í? LVM-em
nebo necim nad filesystemem (btrfs snapshoty)?

Jinak moc diky za zajimave tipy.

Dne 5. srpna 2016 4:14 Jan Hrach <jenda na yakumo.hrach.eu> napsal(a):

> > A jako bonus získáte velmi jednoduchý způsob navyšování disků pro
> virtuální stroje
>
> Jak už jsem psal, tohle lze triviálně i se soubory přidáním nul na konec
> (cat /dev/zero >> file), případně pomocí truncate(1).
>
> On 5.8.2016 03:44, Slávek Banko wrote:
> > 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.
> >
>
>
> --
> Jan Hrach | http://jenda.hrach.eu/
> GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
> _______________________________________________
> Linux mailing list
> Linux na linux.cz
> http://www.linux.cz/mailman/listinfo/linux
>



-- 
-------------------------------
Petr Podrabsky
e : petrpo @ gmail . com