KVM - disk, jako image u virtualniho serveru

[Jan Hrach]

Ideálně vůbec, preferuji synchronizaci na úrovni souborů, tj. rsync vnitřku virtuálu. Takto synchronizované soubory potom držím pomocí rdiff-backup (staré stroje nastavené než bylo stabilní btrfs) nebo na btrfs snapshotech (nové stroje).

On 10.8.2016 12:21, Petr Podrabsky wrote:
> 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
>>
> 
> 
> 


-- 
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E