KVM - disk, jako image u virtualniho serveru

Jan Hrach jenda na yakumo.hrach.eu
Pátek Srpen 5 04:14:27 CEST 2016


> 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


Další informace o konferenci Linux