Portál AbcLinuxu, 2. května 2024 01:22
HW Raid/dev/vg/lv-image-virtual/DRBD0
Teď ještě někdo nadhodil, že by to mohlo běžet nad QCOW2, ale druhý, že je to zase další vrstva FS. Obou názorů si hodně vážím, tak nevím co zvolit. Zatím mně vyhovuje to řešení co jsem zvolil. Ale hlavní otázka zní, jaký systém dát do těch virtuálek. Hodně se mně líbí BTRFS. Operační systém mám debian 9. Mně by se nejvíce líbilo mít virt. disk, tam LVM a pod tím BTRFS. Vypadalo by to nějak takto:/dev/vg/lv-root/btrfs, se subvolumes.
Někdo, ale namítá, že je tam zbytečně další vrstva a i sám tvůrce píše, že se sníží výkon. Jak moc se sníží, ví to někdo? Zase pak se strašně pohodlně resizuje disk na jakoukoliv stranu. Druhá varianta je to udělat rovnou na blokovém zarířzení. Tedy:/dev/sda1 - swap
a/dev/sda5 - btrfs se subvolumes (root,data, home, log a tmp)
Tady si myslím, že nebude tak pohodlný resize disku. Mám image o velikosti 10GB a běžně jej zvětšuji na 1000GB a pak třeba potřebuji zmenšit jen na 800GB. A nebo vůbec BTRFS ve virtuálce nepoužívat a mít LVM a tam ext4? A nebo dát data do BTRFS na fyzický server a přistupovat tam z virtuálky přes NFS? Do toho se mně už vůbec nechce. A jak se řeší DB? Někdo tu psal, že DB ve virtuálce je pomalé. Jak to tedy virtualizovat či jak to řešit? Přes nějaký kontejner? To se mně moc nechce, ale asi by to šlo udělat.Řešení dotazu:
15.10.2017 14:47
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Za mě: swap do virtuálky nepatří. Pokud nějaká virtuálka začne swapovat, spolehlivě tím zabije diskový výkon pro všechny ostatní na stejném disku (nebo poli). Osobně nedávám swap nikam, ani na fyzický stroj. Na produkci nemáme swap nikde. (Na druhou stranu dovedu si představit, že s dnešními cenami rychlých ssd disků by už tento názor šlo přehodnotit a porovnat cenu za RAM vs. cenu za swap na ssd. A nějak do toho zakalkulovat životnost takového disku.)
Mně by se nejvíce líbilo mít virt. disk, tam LVM a pod tím BTRFS.V čem vidíš výhody? Já tam furt nevidím význam toho LVM. Udělal bych to /dev/sda1 - boot, /dev/sda2 - btrfs. A potom přidávat další disky /dev/sdb1, /dev/sdc1 a přidávat je do toho btrfs. Stejně tak to lze ubírat (nechat z btrfs odstranit device a odebrat jej z virtuálky). (Oddělený boot oddíl proto, že jsem na to zvyklý a netuším, jak je na tom boot z btrfs multidevice jiného typu, než raid1. GRUB by s tím neměl mít problém.)
A jak se řeší DB? Někdo tu psal, že DB ve virtuálce je pomalé.Ze všech hledisek je rychlost virtuálky stejná jako rychlost HW. V CPU je podpora, výkon cpu je prakticky nerozeznatelný (pokud se nepočítá něco hodně speciálního optimalizovaného přímo na daný CPU a jeho velikost cache a pipeline). Netřeba řešit. Výkon disků v případě použití virtio ovladače (což bych považoval už za naprostou samozřejmost) je stejná jako výkon HW. Je potřeba si dát pozor na to, aby virtuální diskový subsystém nezahazoval fsync a taky na různé kombinace bariery a nebariery apod. Je taky dobré nastavit ve virtuálce elevator na noop, protože ten io scheduler stejně nemá info o tom, co se s tím io požadavkem děje na nižších vrstvách. To si přeskládá až OS na fyzickém železe nebo řadič. Jinak co se týče optimalizace běhu DB, tak to je na samostatný seriál. Můžeš mít oddělený wal, oddělené indexy a i třeba jednotlivé tabulky. Jestli to není nějaká ultra zatížená db pro něco extra důležitého, tak bych to neřešil a prostě bych to nechal na té virtuálce. Debian má v instalačním skriptu už rovnou vypnutí COW pro daný adresář (v případě instalace na BTRFS), takže je to slušně rychlé. Já PG provozuju na XFS.
Z toho nakonec vznikne seriálAle konečně se dobírám řešení a asi díky tobě :)
Za mě: swap do virtuálky nepatří.Vidíš, toto mě nenapadlo dobrý postřech. Ještě jsem přemýšlel hodit swap na ssd disky, ale nechtělo se mně kvůli tomu přidávat další zařízení. Dám na tebe a swap vypnu. Možná kdyby bylo málo RAM hodím to na ty SSD.
Mně by se nejvíce líbilo mít virt. disk, tam LVM a pod tím BTRFS.
V čem vidíš výhody? Já tam furt nevidím význam toho LVM. Udělal bych to /dev/sda1 - boot, /dev/sda2 - btrfs. A potom přidávat další disky /dev/sdb1, /dev/sdc1 a přidávat je do toho btrfs. Stejně tak to lze ubírat (nechat z btrfs odstranit device a odebrat jej z virtuálky). (Oddělený boot oddíl proto, že jsem na to zvyklý a netuším, jak je na tom boot z btrfs multidevice jiného typu, než raid1. GRUB by s tím neměl mít problém.)Toto je pravda, lze to i tak. Asi jsem více na LVM zvyklý a furt mně ten resize přijde pohodlnější. Např u LVM bych nemusel vytvářet další blokové zařízení v podobě DRBD. Jen bych zvětšil LV kde je DRBD u DRBD dal resize a to stejné ve virtuálce. Výsledek mám jedno blokové zařízení na fyz. železe k jedné virtuálce. S BTRFS při každé úpravě velikosti disku musím přidat další blokové zařízení.
Výkon disků v případě použití virtio ovladače (což bych považoval už za naprostou samozřejmost) je stejná jako výkon HW. Je potřeba si dát pozor na to, aby virtuální diskový subsystém nezahazoval fsync a taky na různé kombinace bariery a nebariery apod. Je taky dobré nastavit ve virtuálce elevator na noop, protože ten io scheduler stejně nemá info o tom, co se s tím io požadavkem děje na nižších vrstvách. To si přeskládá až OS na fyzickém železe nebo řadič.použití virtio ovladače ten je standardně v debianu nebo se musí doinstalovat? nebo myslíš nastavení virtio při vytvoření disku ve virtualce? Elevator=noop nastavím přímo v oper. systému virtuálky?
16.10.2017 11:51
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Asi jsem více na LVM zvyklý a furt mně ten resize přijde pohodlnější. Např u LVM bych nemusel vytvářet další blokové zařízení v podobě DRBD. Jen bych zvětšil LV kde je DRBD u DRBD dal resize a to stejné ve virtuálce.Pokud bys měl ve virtuálce BTRFS, tak po zvětšení oddílu stačí dát
btrfs filesystem resize max / a bylo by to. A lze to i zmenšit, tedy btrfs fi resize na menší velikost, zmenšit oddíl ve virtuálce a potom zmenšit ten block device na fyzickém stroji.
Btrfs lze zvětšovat jak přidáváním dalších device, tak upravou velikostí jednotlivých device. Dokonce lze nechat zmenšit libovolnou device v btrfs i pokud je jich tam víc. Nebo ji úplně odebrat.
Takže dávat do virtuálky LVM pro "snadnější resize" nedává s btrfs smysl, protože stejně se po zvětšení daného LVčka udělá totéž, co při zvětšení oddílu. Tedy btrfs fi resize max.
Takže v podstatě záleží jen na tom, jak to chce člověk dělat. V jednom čistě experimentálním setupu mám danou fixní velikost disků pro virtuálku (16GB) a další místo přidávám jen přidáním dalšího virtuálního disku (opět jen 16GB) a zmenšování opět jen odebráním celých disků. Cílem tohoto experimentu je pokus o co nejednodušší blokovou vrstu (GPT umí 128, resp. 124 oddílů, takže tímto lze alokovat 124*16GB = necelé 2TB z diskového zařízení).
použití virtio ovladače ten je standardně v debianu nebo se musí doinstalovat? nebo myslíš nastavení virtio při vytvoření disku ve virtualce?Za posledních několik let jsem neviděl distro, které by to nemělo by default. Je to v kernelu. Takže pokud se v kvm virtualizuje linux, je to ok. V virsh (libvirt) je to definované jako
<source file='/dev/mapper/VGData-mx'/> <target dev='vda' bus='virtio'/>a (pokud paměť slouží), tak virt-install to takhle nachystá automaticky při vytvoření kvm vmka. U Windows bylo potřeba virtio nainstalovat zvlášť (ale widle jsem virtualizoval fakt hodně dávno).
Elevator=noop nastavím přímo v oper. systému virtuálky?Dá se to nastavit jako parametr jádra (tedy v konfiguraci zavaděče),
elevator=noop. Aktuální io scheduler lze zjistit a změnit i za chodu OS voláním (aktuální elevátor je uveden v [] ):
#cat /sys/block/sda/queue/scheduler noop [deadline] cfq #echo "noop" > /sys/block/sda/queue/scheduler
Dá se to nastavit jako parametr jádra (tedy v konfiguraci zavaděče),Elevator noop se mně nedaří změnit. Nemůže to být tím, že to běží na HW raidu? Stále to ukazuje nonoe. Změnil jsem v zavaděči i přes:elevator=noop. Aktuální io scheduler lze zjistit a změnit i za chodu OS voláním (aktuální elevátor je uveden v [] ):#cat /sys/block/sda/queue/scheduler noop [deadline] cfq #echo "noop" > /sys/block/sda/queue/scheduler
echo "noop" > /sys/block/vda/queue/scheduler cat /sys/block/vda/queue/scheduler none
16.10.2017 16:32
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
17.10.2017 10:24
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Jen bych chtěl upozornit, že to, co píšu a radím je můj pohled na to, jak by se daná věc měla dělat. Nemám patent na pravdu a už jsem se setkal s tím, že jsem sice něco postavil dle nejlepšího vědomí a svědomí, ale potom s tím přišel pracovat člověk, který se o to až tak moc nezajímal, snažil se aplikovat staré vědomosti a nedopadlo to úplně dobře.
Pro mě osobně (stejně to vnímám třeba u Aleše) je důležité rozumět tomu (alespoň do nějaké míry, zdrojáky nestuduju), s čím pracuju. Potom mě to nepřekvapí.
A tohle vnímám jako problém u lidí, kteří třeba btrfs nasadí (ale to se týká i dalších věcí), snaží se k tomu chovat stejně jako ke starému systému, ještě navíc odmítají používat ty novinky (viz. tato diskuse), neví jak to funguje (viz nekonečné diskuse o volném místu) a potom jsou překvapeni.
Takže nejdřív vyzkoušet, nacvičit, pochopit a potom se do toho pustit (jinými slovy z mého pohledu to děláš správně )
Dobry den.
Dlouho jsem to resil, az jsem dospel k tomuto:
Idealne kazde virtualce minimalne dva disky.
jeden s mbr a partisnou na boot, protoze to tak ma rad grub.
Druhy pripojeny bez jakehokoli deleni jako /.
Pripadne dalsi pripojovane zase bez jakehokoli deleni.
Vyhodou je, ze pri zmene velikosti disku to jde napric distribucema bez restartu. Jinak jakmile tam je rozdeleni na partisny, odmita to casto po zmene velikosti kernel vzit u disku na kterem je / na vedomi.
Vsude co nejjednodusi filesystem.
Swap ano, pokud chcete baloonovani.
Akorat nevim o distribuci, ktera by to umela pri instalaci naklikat a spousta nastroju, ktere maji pocit ze disk se proste musi delit.
marek
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.