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