Dotaz: jak rozdelit disky na server, jaký RAID a co pouzit btrfs nebo zfs

[chinook]

Zdravím, mám server, kde poběží KVM s virtuálkama pošta, samba, web a db. A je tam 6x1,2TB 10 000RPM a 2xSSD200GB. Terabytové disky chci dát do RAID 10 a SSD RAID 1. RAID mám HW. Nebo navrhuje rozdělení někdo jinak?

Pak nevím co použít za systém. Víc se mně líbí btrfs, ale zfs může použít ssd jako cache a co jsem četl, tak výkon by byl fakt velký. Tak nevím co zvolit.

Jsou tedy dvě varianty.

1. Použiji BTRFS a nad polem s terabytovými disky poběží pošta, samba, web a DB poběží na SSD.

2. Použiji ZFS SSD, bude jako cache a na poli poběží všechno.

3. Je nějaká třetí varianta?

Je možné použít nějkou deduplikaci? Má s tím někdo zkušenost? Třeba na poštu a sambu? Na poště je určitě hodně dat stejných. Dost se posílají hromadné emaily i s obrázkama.

---

---

Odpovědi

[Heron]

Jestli vyloženě netrváš na KVM, tak bych tam dal FreeBSD, ZFS (ssd jako slog, případně též jako cache, ale tam bych raději dal co nejvíc paměti) a ty programy mít v Jailech.

Btrfs ssd cache sám o sobě využít neumí, jestli jsou ty db malé, tak se dají dát celé na ssd, jinak tam lze dát WAL logy (binlogy) a data mít na rotačních diskách.

Deduplikace obecně nefunguje (je to pomalé, chce to hodně paměti), je vždy dobré to řešit na úrovni, kde ta data vznikají. Většinou je duplikovaných dat stejně velmi málo a více místa se získá třeba compresí na úrovni fs (třeba pro maily se to přímo nabízí).

[chinook]

Bohužel FreeBSD vůbec neznám, proto bych se držel debiana. A ani nemám zkušenosti s ZFS ani BTRFS. Takže jdu buď do Debiana nebo v krajním případě CENTOS. Není ZFS riziko, když není přímo v jádře? A také jsem vyčetl, že s HW raidem bývá problém.

Také budu mít servery dva. Takze LVM - DRBD - BTRFS a na DB nějaký EXT4? DB má nějakých 40GB, takže není problém ji hodit na SSD.

[petr]

2 servery znamena co? Aktiv aktiv? Nebo aktiv pasiv? Nebo druhy je proste jenom zalozni HW pro pripad ze odejde prvni? ZFS na linuxe je dle me porad takova devel verze (ano, videl jsem prezentaci kde maji 70tb dat i na linuxe pres zfs), pokud uvazujes nad ZFS a mas produkcni data, tak freebsd nebo solaris je dle me nutny. Pokud uvazujes nad betafilesystemem tak si precti zname FAIL situace ktere BTRFS ma popsane treba ve wiki aby jsi pak tady nebrecel nad tim ze se ti treba neco mountne readonly nebo ze budes mit caj a ruzne jine... Tech FAIL situaci najdes i tady hodne, ale udelej si to jak chces, ja mam ohledne BTRFS svuj nazor. Co se tyce ZFS a HW raidu tak je to tak, ze pokud chces vyuzit potencial ZFS tak je dobry nechat radic v HBA modu kdy ZFS vi o tvem disku co je to za disk, jakou ma velikost sektoru atd... Pokud tam narves HW raid, nekomu to chodi, nekomu se to sesype, takze rada obecne je nezkouset stesti a pouzivat HBA mod a nechat delat ZFS sve. Ja mam treba u vsech svych stroju v domech ZFS postavenou na HW raid radici od adaptecu ktery je v HBA modu a slape to x let bez problemu. Duvod proc mam HW raid adapter a ne pouhy HBA adapter je spolehlivost - s HBA adapterem se objevovali veci ktere me vedli k tomu investovat do kazdeho stroje +3000EUR vice nez se s tim s*at. Co se tyce deduplikace u ZFS, pokud nemas stroj s hodne RAM a tim myslim tera a vice, tak se na deduplikaci vy*er protoze lepsich vysledku dosahnes s kompresi. Mam usecase kde mam pouzitou na nekterych poolech deduplikaci a plni to v mem pripade svuj ucel, obecna rada je ale pokud se ti nechce experimentovat, vys*r se na deduplikaci a pust kompresi.

[chinook]

Experimentovat určitě nechci. Budou to produkční servery. Mám v plánu 2 servery. Oba Aktiv na kazdem pobezi 4 virtualy. Kdyz se jeden sesype da se to vse na jeden. Chci to propojit pres DRBD primary/secondary. Je lepsí varianta? Ideálně otestovana Primary/primary? ZFS není nutnost.

[Michal]

Pokud vyloženě nepotřebuješ virtualizaci, tak použij LXC/LXD kontejnery, ušetříš nějaký výkon a paměť. Vyzkoušej proxmox

https://www.proxmox.com/en/proxmox-ve

Je to takové distro spravované přes webové rozhraní přesně pro tento účel (KVM a kontejnery) udělané. Navíc instalace umí ZFS, zálohování použivají ZFS snapshoty atd.

ZFS deduplikace se na image virtuálních strojů moc nehodí. Komprese funguje dobře, zejména lz4.

Bez detailní znalosti workloadu je takřka nemožné odadnout zda bude lepší ty SSD použít jako

a) separatní RAID1 pool b) L2ARC (raid0) c) L2ARC + ZIL (pozor, v tomto uspořádání nelze mít na jednom SSD L2ARC a na druhém ZIL protože ZIL by měl mít mirror navíc na ZIL stačí podstatně menší kapacita)

Je vysoce pravděpodobné, že v a) promrháš kapacitu na studená data. Osobně bych sázel na b) nebo c) což má tu výhodu, že to můžeš zkoušet za chodu, L2ARC i ZIL lze za chodu přidávat/vyhazovat.

[chinook]

Mně přijde čistější řešení ta virtualizace. Budu tam mít max 8 mašinek, tak to by problém být neměl. Takže místo Debian a na něm KVM doporučuješ rovnou proxmox? Právě mezi proxmox a KVM se rozhoduji, nemám zkušenost ani s jedním. Ty kontejnery mně přijdou výhoda a že je to klikátko je také bonus. Přes consoli by to taky mělo jít ovládat pokud budu chtít něco nastavit. U KVM výhoda, že si nakonfiguruji cokoliv, ale asi nevýhoda, že musím vše sám.

K tomu ZFS není nevýhoda mít HW RAID s CACHE?

[petr]

pokud chces pouzit ZFS nad HW raid s cache, rozhodne na to zapomen, HW radic prepni do HBA modu, jinak riskujes ztratu celeho pole.

[chinook]

Pokud nepoužiji SSD jako cache, tak se mne víc líbí btrfs. Není škoda vypínat HW raid, když už jej tam mám? To je lepší nepoužívat ZFS, ne?

[Petr]

To je uhol pohledu, jestli duverujes treba firmware HW raid radice od adaptecu nebo kodu ZFS. Vse ma sve pro a proti, treba se ZFS muzes mit raidz-3 spolu s x kopiemi dat na poolu co s HW raidem neudelas. V usecase tazatele bych ale zfs nepouzil a sel bych do HW raidu pokud tam nejaky slusny radic a at si tam da co chce za fs.

[chinook]

Je tam toto: PERC H730 Integrated RAID Controller, 1GB Cache

Takže BTRFS?

A příště nekupovat HW raid? Myslel jsem, že je rychlejší a nevytěžuje systém.

[petr]

HW raid ma samozrejme sve vyhody (a nevyhody). Pokud ocekavas od nej RAID 0/1/5 tak samozrejme zatizeni systemu muze byt nizsi, tudiz to treba ma vyznam. Vse je ale o tom co chces a co potrebujes. Promin, ja ti btrfs nedoporucim, na produkcni data bych ji nikde nedal, ale je tady spousta lidi co ti btrfs doporuci.

[Sinuhet]

Proč? Já žiju v domnění, že HW RAID se chová transparentně, takže kromě toho, že ignoruju spousty výhod ZFS a ta cache se asi nebude chovat optimálně vůči jiným SW cache (včetně té ZFS SSD), tak by to nemělo nic rozbít, ne?

Kromě toho, že v provozování právě ZFS na HW poli nevidím žádný smysl...

[Petr]

HW raid se chova tak jak to nejaky cinan nakodil, o transparentnosti bych nemluvil. Kdyz jsem upgradoval firmware adaptecu tak jsem si tu transparentnost uzil. Problem nastava treba tehdy kdyz zapisujes a radic ti hlasi ze vse je zapsano ale tvych 256mb dat je jeste nekde v cache radice a tvuj system ti dovoli treba vypnout se. Je pak jenom na tom radici jak se s tim vysporada. Samozrejme provozovat ZFS na HW poli nema zadny smysl krome rare prikladu.

[chinook]

Asi nejvhodnější pro mě je tedy BTRFS ne? Mohu dělat snaphosty virtuálek, což je super a využiji HW raid. Nebo ne?

[Chytrex]

Taky bych nešel do btrfs. V bývalé práci se používalo řešení kdy na strojích běžel proxmox a data se ukládaly na další stroj s freenas do ZFS.. funguje to perfektně, nejsou s tím problémy a pod BSD je ZFS naprosto v pohodě.

[petr]

Michale, proxmox me dlouho zajima, mas ho nekde pouzity s vice nez 50TB dat? Idealne kdyby jsi mel vicero lokalit s timhletim.

[Aleš Kapica]

Proxmox je jenom "obchodní značka". Dělají to lidi co řeší podobné problémy, takže v jeho rámci najdeš i věco co by sis jinak musel napsat sám. Btrfs žádný HW raid nepotřebuje - pracuje s diskama. Být tebou, všecko zvirtualizuju. Zjednoduší se ti život.

[chinook]

Stále nejsem o nic chytřejší. Takže to shrňme: Máme 6x1,2TB 10 000RPM a 2xSSD 200GB. PERC H730 Integrated RAID Controller, 1GB Cache DB 40GB

1. Použiji HW raid10 a raid1 na SSD. KVM BTRFS a nad polem s terabytovými disky poběží pošta, samba, web a DB poběží na SSD.

2. Použiji Proxmox s ZFS a SSD bude jako cache a na poli poběží všechno. Nepoužiji HW raid

U BTRFS mám zapínat ten HW raid?

Proxmox s btrfs nefunguje?

[Heron]

Co na tom FS hodláš mít? Image disků KVM virtuálek? To bych nedělal, je lepší použít LV.

Pokud na tom FS budou přímo soubory, jak to bude připojené do těch virtuálek? (NFS, Samba, něco jiného?)

Asi je potřeba odpovědět tyto otázky, ať se trochu pohneme dál, z dosavadní diskuse mi není jasné, na co tam ten fs má vlastně být.

V případě použití ZFS lze mít image disků jako ZVOL (ale pořád je mi trochu proti srsti na linuxu zfs používat).

Pokud to nakonec nebudou virtálky ale kontejnery, hodí se mít BTRFS na linuxu (lxc, nspawn) nebo zfs na bsd (jaily). Tedy je potřeba nejdřív vědět, co se od toho systému očekává. Jestli je nutná plná virtualizace (v budoucnu může nastat potřeba virtualizovat jiný OS - potom tedy KVM a disky jako LV), nebo zda stačí kontejnery, potom je vhodný moderní fs typu BTRFS nebo ZFS.

[chinook]

Na FS chci mít image virtuálek, proč by si to tak nedělal? LV je logical volume? Tím myslíš co LVM? Jak pak řešit snapshoty?

Na FS přímo soubory nebudou, ty budou v těch virtuálkách.

Asi časem bude potřeba plná virtualizace, protože tam poběží asi i win. Ze začátku ne.

[Heron]

Ano, LV je logical volume. LVM umí snapshoty sám o sobě.

Pochopitelně lze mít image disků na nějakém fs, ale je to docela zbytečné (pokud se s tím neplánuje dělat něco speciálního). Soubor image se stejně do virtálky připojuje jako blokové zařízení, takže je výhodnější tam připojit rovnou blokové zařízení. Od toho je právě LV (nebo ZFS ZVOL, md apod.) Je to rychlejší, odpadá vrstva navíc (ten mezilehlý fs), snapshoty (pro konzistentní zálohu image) lze pořizovat stále.

[chinook]

Co jsem četl, tak v produkčním prostředí ty snapshoty zastaví server.

Jak to tedy doporučuješ?

Radíš nepoužívat HW raid, takže MD a nad tím LVM?

Nebo místo toho ZFS nad debianem?

[Heron]

Nezastaví. Rozhodně ne. Zápisy na LV se snapshotem jsou o něco pomalější (nutno vyzkoušet, zda to v produkci vadí), čtení dotčeno není, a jsou určeny jen na chvilku pro zálohu. Rozhodně ne na delší skladování.

Radíš nepoužívat HW raid, takže MD a nad tím LVM?

Z mého pohledu je md spolehlivější než hw řadič. Pokud není potřeba speciálních vlastností FS, tak pro KVM virtuálky je LVM a LV dobrá volba.

Nebo místo toho ZFS nad debianem?

Se ZFS na linuxu nemám žádné zkušenosti. Na BSD to používám pro jaily (kontejnery). Pokud by jsi šel do ZFS na linuxu, tak je vhodné použít ZVOL (já to používám zatím jen jako backend pro iscsi).

Možná ještě někdo poradí něco dalšího. Nevím, jak jsou na tom dneska formáty typu QCOW2 apod., mělo to umět různé stupně klonování a snapshotů a thin provisioning, ale jak je na tom dneska nevím.

[chinook]

Tvoje odpověď mě překvapila, ale tvého názoru si vážím.

Takže budu mít

MD->LVM->DRBD->LVM

a ve virtualce co?

Potřebuji teda vůbec btrfs?

A jak budu zálohovat virtuálky? U btrfs se mně právě líbily ty rychlé snapshoty.

[chinook]

Aha, ty tam chceš zakomponovat ještě DRBD. Tož to nevím, proč to strkat mezi dvě vrstvy LVM. Když už, tak MD - DRBD - LVM a LV pro disky virtuálek. Akorát teda DRBD není moc rychlé.

Ve virtuálce cokoliv co se pro ni hodí. Třeba BTRFS.

LVM má též rychlé snapshoty. Pořízení je atomické, odkopíruje se blokové zařízení, snapshot se smaže.

K tomu zálohování. Nám se celkem osvědčilo mít dvojí zálohování. Konzistentní zálohu celé virtálky (jejího blokového zařízení) a potom ještě logickou zálohu vnitřku virtuálky dle aplikace (tedy mít ještě dump db, zálohy souborů, export gitlabu apod.). Pokud to celé shoří, prostě se obnoví celé image virtuálek a pokud někdo jen něco smaže, tak se hodí logická záloha po souborech.

Tady místo pro FS příliš není. Ukládat image běžících virtuálek (ve kterých je rozdělený disk a nějaké fs), na další fs, není úplně nutné. Je to dvojí režie. Pro plnou virtualizaci se osvědčuje mít virtuálku nad blokovým zařízením. (Je to prostě nejrychlejší, odpadá mezivrstva dalšího fs.)

Existují i další varianty, ale ty nikomu doporučovat nebudu. Rok si hrajeme s cephem (kterej má vlastní blokové zařízení - RBD), ale podařilo se nám to pokaždé shodit. Nevím, jak je na tom SheepDog (distribuované úložiště, umí jen bloková zařízení, na rozdíl třeba od toho cephu, který umí i S3 objekty a FS).

[MP]

DRBD je rychle...ale vocad pocad - napr. nam jede mirror cca 7.5Gbps jako strop vlivem pomalejsiho cpu. Kazdopadne, ve 2 nodech asi ho jen tak neco neprekona. LVM rychle snapshoty? No nevim, vsude od toho odrazuji, je tam velky perfhit nad zatizenymi VM...

Jeste k te kombinaci DRBD a Proxmox. Proxmox dal od DRBD ruce pryc, takze uz to neni tak jednoduchy out of box a s veskerou podporou odkazuji na tvurce DRBD.

[Heron]

LVM rychle snapshoty?

Rychlé pořízení.

je tam velky perfhit nad zatizenymi VM

Má to pomalejší zápisy, ale pokud je dostatečná rezerva výkonu na storage, tak to pořád stačí. Tohle se musí vyzkoušet, zda to pro dané nasazení stačí.

Jeste k te kombinaci DRBD a Proxmox.

Já o kombinaci nehovořil, proxmox neznám. Nasazení DRBD bylo vždy easy.

[chinook]

Když už, tak MD - DRBD - LVM a LV

Vadí, když použiju MD - LVM - DRBD - LVM

Na serverech to takto mám. Měnil jsem tam velikost pole a s lvm to bylo v pohodě. Návod jsem opsal někde od tvůrc DRBD.

Jinak to nejspíš udělám tak jak píšeš.

[nanuk]

K čemu potřebuješ MD - chápu. K čemu potřebuješ LVM - chápu. K čemu potřebuješ DRBD - chápu. K čemu potřebuješ další LVM - nechápu. Můžeš to nějak přiblížit?

[Heron]

Nechápu význam toho dvojího LVM. Jinak to samozřejmně ničemu nevadí.

Ještě bych dokázal pochopit setup: MD - LVM - DRBD (s možností, že každé LV bude přes DRBD replikováno na jiný sekundární server).

[chinook]

Já to tak dělám pro případ, když bych chtěl resizenout velikost DRBD. A co na postgres? EXT3 či EXT4 nebo něco jiného?

[nanuk]

Takže ty máš na jednom serveru puštěné všechny ty virtuály a druhý server pouze zálohuje data pomocí drbd?

[Heron]

Já používám xfs. Ale ono to je celkem jedno, ty fs se výkonem příliš neliší.

[Aleš Kapica]

Používat dvojí LVM je konina, která akorát komplikuje situaci, když se něco rozbije.

Z praxe mohu říct, že nejstabilnější řešení s použitím DRBD bylo:

MD - umožní rychlou výměnu HDD když nějaký odejde do kytek

LVM - umožňuje rozsekat MD na LV pro virtuály

DRBD - pro každý virtuál a blokové zařízení samostatné.

[Aleš Kapica]

Proč to takhle udělat je jednoduché - když se ti rozesere DRBD, resynchronizuješ pouze jedno menší pole tzn. že to pak trvá kratší dobu. Když potřebuješ udělat DRBD resize, zvětšíš LV a každé straně a uděláš resize.

Mít jedno velké DRBD pole je zvířecí, Jde to, funguje to, ale jakákoliv operace (např. kontrola FS) pak neskutečně dlouho trvá - ostatně, jako u každého velkého FS.

[dustin]

Nic proti tomu, ale zeptám se:

Mám 2 servery, tj. více drbd by replikovaly mezi stejnými servery. DRBD se může rozpadnout z nějakého hardwarového důvodu. Jaká je šance, že se jich rozpadne více, pokud všechny běží na stejném HW? IMO dost velká. Pak ovšem musím synchronizovat více polí - více admin práce.

Když potřebuješ udělat DRBD resize, zvětšíš LV a každé straně a uděláš resize

Když mohu zvětšit LV, mám již pod ním dost prostoru.

Varianta A:

zvětším disk X, disk Y, zvětším příslušná LV na straně X, na straně Y a zvětším DRBD pro jednotlivá LV

Varianta B:

zvětším disk X, disk Y, zvětším jedno drbd na obou stranách a poté na primary drbd zvětšuji LV dle potřeby.

Mně přijde varianta B jednodušší, ale možná jsem něco přehlédl...

Mít jedno velké DRBD pole je zvířecí, Jde to, funguje to, ale jakákoliv operace (např. kontrola FS) pak neskutečně dlouho trvá - ostatně, jako u každého velkého FS.

FS je věc LV, ne? Takže kontrola FS probíhá stejně jen na části drbd, kterou zabírá příslušné LV/FS. Jak více drbd tu kontrolu urychlí?

Mně pro dva stroje přijde více drbd nad LVM místo naopak zbytečné, ale jak říkám, třeba jsem něco přehlédl.

[Aleš Kapica]

DRBD není nic než síťový MD raid. Můžeš jich mít kolik chceš. Důležité je pouze to, aby mělo každé pole svoje vlastní číslo portu přes který mu lítají data.

DRBD pole se nerozpadá jen kvůli HW problému. Může se ti rozpadnout třeba kvůli tomu, že se nestíhá synchronizovat. Právě proto je lepší mít více samostaných DRBD polí - bude se ti pak rozpadat jen to problémové, takže snáz zjistíš kde se to musí ošetřit.

Pokud nastane problém na straně HW, tak se ti pochopitelně rozpadnou všechny, co s postiženým HW budou pracovat.

Více DRBD polí, možná více admin práce, ale rozhodně míň stresu.

FS není věc LV. Je to věc virtuálu co s ním pracuje. Když máš pro každý z nich samostatné DRBD oddíly, můžeš jednoduše škálovat výkon strojů. Když máš jedno DRBD může ti všechno běžet jen na jedné straně.

A vůbec. Mi je to jedno. Každý ať si to dělá jak chce. Já jsem tu prezentoval pouze to, co se ukázalo během uplynulých 5 let jako nejspolehlivější řešení u dvounodových clusterů s nimiž jsem měl co do činění.

[dustin]

DRBD taky používám na dvounodových clusterech (naprosto bezproblémově) roky, ale raději bych jich spravoval méně než více.

Samozřejmě možnost přehodit libovolné virtuály nezávisle na druhou stranu je zajímavé, to bych asi viděl jako hlavní argument pro rozdělení. Díky.

[chinook]

Zajímavá myšlenka. Asi do toho půjdu. Dost mně vadilo, že bych měl pole rozdělené na 2x1,8TB. Takhle si virtuálky mohu přesouvat dle libosti.

Takže je navěsím na zařízení /dev/drbd1 další na /dev/drbd2 atd.?

[Aleš Kapica]

Přesně tak.

[Aleš Kapica]

Ovšem aby to dávalo smysl a fungovalo automaticky, je třeba použít pacemaker, který se stará o nahazování DRBD polí a spouštění virtuálů a to už je vyšší dívčí.

Nicméně se to dá ošetřit i pomocí skriptů, pokud stačí manuální řešení.

[xxl]

Je lepší se prokousat nastavením pacemakeru, než to scriptovat.

[Aleš Kapica]

Jak kdy, jak pro koho a jak kde.

[trekker.dk]

DRBD - pro každý virtuál a blokové zařízení samostatné.

Akorát pozor na to, kdyby těch virtuálů mělo být hodně nebo měly víc oddělených disků - maximální počet DRBD zařízení na jednom stroji je AFAIK pořád 250.

[Aleš Kapica]

Dobrá připomínka. Ovšem pro takový počet by už mělo být dávno zvoleno vhodnější řešení – disklessové servery.

[GeorgeWH]

we need...

[Heron]

Jo jinak, co se týče použití HW raid řadiče, tak doporučuju to nepoužívat. Neznám jediný hw řadič bez bugů, my jsme si užili své s LSI, Adaptec, DELL (PERC), Areca. Lepší je to řešit v software.

[sigma]

Co tedy používáte pod SW raid-em (popř. ZFS/...), obyčejný HBA bez writeback cache? Já vnímám jako hlavní výhodu HW "RAIDu" (v uvozovkách, protože ho mohu přepnout do JBOD režimu, a nad tím si udělat třeba mdraid, tak to i někde používám) právě tu zálohovanou writeback cache.

Ve scénářích s větším množstvím malých zápisů (PostgreSQL s vyšší zápisovým provozem) má writeback cache naprosto zásadní vliv, fsync() nemusí čekat na potvrzení od disku, stačí uložení do RAM controlleru, který to pak může seskládat do větších transakcí. Časový rozdíl třeba při importu větší zálohy DB je více než 10 násobný. Pokud selže cache, přijdu o data, ale při výpadku napájení je tam záložní supercap a flash (dříve baterie), tak by k selhání nemělo nikdy dojí. Selhání může přijít i s s chybou firmwaru, ale na to mám zálohy, popř. u kritických systémů realtime replikaci.

Alternativní cesta k urychlení zápisů je asi ZFS a write intent log na flash úložišti, ale s tím zatím nemám zkušenost.

[Heron]

obyčejný HBA bez writeback cache

Ano.

právě tu zálohovanou writeback cache

Tak až (až, ne jestli) selže, tak good luck s opravou. Jeden řadič se neobtěžoval informovat o nedostatečné kapacitě baterky (takže po výpadku proudu prostě selhala), další 3 řadiče se baterkou odrovnaly sami do 14 dnů od zakoupení (naštěstí ve zkušebním režimu), protože dodavatel zkompletoval řadič tak, že baterku připojil projistotu s opačnou polaritou. (Ano, vůbec to nebylo ošetřeno na konektoru, jak by jeden čekal.) Jo a taky jednou přišel řadič už s dopředu s komplet vybitou a tedy zničenou baterkou (asi mu to leželo v regále dlouho).

Ve scénářích s větším množstvím malých zápisů (PostgreSQL s vyšší zápisovým provozem) má writeback cache naprosto zásadní vliv, fsync() nemusí čekat na potvrzení od disku, stačí uložení do RAM controlleru, který to pak může seskládat do větších transakcí.

Toho se dá docílit i jinak. Hned v prvním komentáři jsem hovořil o tom, že WAL lze umístit na SSD, u postgresu lze snadno umístit i jednotlivé objekty (tabulky, indexy) nad jednotlivé disky (rychlejší, pomalejší, podle potřeby). Nehledě na další optimalizace, pokud je lze použít (synchronous_commit, commit_siblings).

Alternativní cesta k urychlení zápisů je asi ZFS a write intent log na flash úložišti, ale s tím zatím nemám zkušenost.

V našich testech bylo ZFS s logem na SSD hodně rychlé, zkušenosti z produkce ale také nemám.

[MP]

Kez by. SW raidy maji stale nevyhody...a jedna z hlavnich je zajisteni redundantniho bootovani/update grubu atd...

[Jendа]

Zajímavé, mně to funguje. GRUB má podporu MD-RAID asi tak 8 let.

[MP]

Tak proc pri instalaci Debianu a vyberu, kam chci grub nainstalovat, to zobrazi pouze 1 disk a ne zrcadlo? A to nemluvim o tom, ze s UEFI je to jeste vetsi pakarna.

[dustin]

Grub instaluješ do místa, které je čitelné biosem. Ten určitě neumí mdraid.

Nicméně běžně se používá raid na root (/) a grub pak nainstaluješ na všechny disky, které jsou v raidu zapojené. Když jeden umře/vyndáš, nabootuješ z jiného.

[Heron]

Instalace Debianu na mdraid je trochu více o manuální práci, ten instalátor neumí vše. Ale třeba takový CentOS / RH to uměl už od roku 2007 (dál do minulosti nevím). Instalátor není všespásný. Debian na mirroru provozuju, bootuje to z libovolného ze dvou disků bez problémů.

[Jendа]

Mně zobrazí zaškrtávací seznam se všemi disky a v něm zaškrtnu všechny.

[MP]

A jak si s tim poradi aktualizace GRUBu?

[dustin]

Instalace grubu2 do MBR disku a aktualizace konfigurace v /boot/grub/grub.cfg jsou různé věci. Po změně konfigurace nemusíš grub do MBR znovu instalovat.

[Jendа]

Úplně stejně jako v případě s jedním diskem. Prostě to grub-install pustí na vybrané disky.

[Aleš Kapica]

Panenko skákavá - máme rok 2017. Tyhle dětské nemoci už má (doufám) grub dávno vyřešené – GRUB (proces zavedení systému). Celý vtip je v tom, že základní core.img musí obsahovat vše potřebné k tomu, aby byl GRUB schopen najít jádro. Tj. pokud použijete MD raid + LVM a na tom FS. Tak musí umět najít disky, detekovat diskové oddíly, z nich sestavit MD raid, pak rozpoznat LVM a nakonec přečíst FS, odkud si natáhne případně další moduly.

U disků, které žádnou tabulku rozdělení disku nemají to udělat nejde (protože pro něj nemají na začátku disku místo). U disků co používají staré MS-DOS rozdělení které má ze startu k dispozici pouze 512 bajtů to udělat jde, ovšem pouze za předpokladu že celková velikost core.img nepřesáhne tuhle velikost. A u disků s MS-DOS formátovaných přes novější verze fdisku, které mají k dispozici ze startu 2048 bajtů, nebo u disků co používají GPT to jde už bez problémů.

[Aleš Kapica]

Mimochodem - to je jeden zdůvodů proč proč používám Btrfs v raid 1. Grub pak totiž nepotřebuje modul pro MD raid, LVM, ani žádný jiný FS. Stačí aby rozeznal disky (modul biosdisk), GPT (modul part_gpt) a Btrfs (modul btrfs). Zbytek už si dotáhne podle potřeby.

[dustin]

Kořenový filesystém mám také vždy jen na jednoduchém raid1. Vždycky jde jeho filesystém namontovat napřímo, kdyby člověk potřeboval.

[rats]

Ve skutečnosti žádné takové složitosti, o jakých píšete a píše se tady v diskusi, nepotřebujete. I průměrný HW řadič v serveru zvládne v dnešní době zapisovat rychlostí 600 - 900 MB/s v závislosti na prostředí, číst ještě rychleji. Testováno na Dell PowerEdge R730 (řadič H730 PERC mini, 4 x HGST HUH721010AL4200 v RAID6), na Dell PowerEdge R630 (řadič H730P mini, 4 x Seagate ST1000NX0453 v RAID10) a na Dell PowerEdge R430 (řadič PERC H730, 4 x ST2000NM0005 v RAID5), a za použití NFS exportu po 10GbE nebo 40GbE (tam teprve poznáte omezení pole, nikoliv sítě...)

 

Pokud chcete virtualizovat via KVM, mohu rozhodně doporučit kombinaci HW RAIDu a LVM s přímou propagací jednotlivých LV virtuálním strojům (přes virtio). Co do výkonu jsme nic lepšího pro KVM nenakonfigurovali, a nemusíte řešit žádnou vrstvu souborového systému - až tu ve virtuálních strojích.

Pokud nedůvěřujete jako někteří jiní diskutující HW RAIDu od renomovaných výrobců, pak byste pravděpodobně dle stejné logiky měl přestat důvěřovat brzdám ve vašem autě nebo výtahu ve vašem domě. Ano, obojí už v historii selhalo a občas selže i dnes, ovšem na počet uskutečněných jízd se jedná o naprosto zanedbatelné riziko.

Ne, SSD opravdu není kouzelná hůlka Harryho Pottera. Jsme u serverů, ne na desktopu. Tudíž pokud jsou vaše SSD připojené na SATA sběrnici, a HDD na SAS, tak SSD budou z principu zapisovat i číst pomaleji. Stále však mějte na paměti režii a omezení virtuálního hardware a ovladačů k němu - VirtIO nikdy nebude rychlé jako bare-metal instalace, a poznáte to zvlášť ve Windows virtuálních strojích (což se vás asi ale netýká).

Pokud máte čas a chuť experimentovat, vaše skladba disků přímo vybízí k tomu "odložit" OS hypervisoru na RAID 1 z těch SSD, a ze zbytku namísto RAID 10 stvořit 3x RAID 1, a "rozstripovat" si mezi ně všechno "ručně" pomocí 3 VG v LVM - ať už si rozdělíte jednotlivé virtuálky, nebo oddíly ve virtuálkách. Je to pro gurmány a fajnšmekry, ale v důsledku je možné, že dosáhnete mnohem vyššího výkonu než na hotovém RAID10 - a také efektivnější redundance. Nehledě na to, že zdaleka ne každý řadič umí adaptivně rozšiřovat RAID10 - kdybyste to někdy v budoucnu náhodou potřeboval.

K výkonu ještě pár obecných poznámek - pokud máte "heavy loaded" databázový stroj, nevirtualizujte ho. A už vůbec mu neemulujte disky pomocí COW souborů, tam je skutečně jediná možnost - RAW oddíly. Zkušenost říká, že pokud vám něco zcela obyčejného bude chodit ve virtuálu pomalu, nejsou problémem diskové operace (IOPS), ale CPU, paměť nebo samotná aplikace. A konečně - stále platí základní fyzika = chcete-li výkon, musíte si ho zaplatit v hardware - žádný zázračný typ RAIDu, souborového systému nebo čarodějného rozložení dat už na věci nic zásadního nezmění.

[chinook]

Dle Vás udělat tedy HW Raid na to LVM a na to DRBD? Asi ten HW raid použiji. Dám na vás.

A jaký máte názor na proxmox? Líbí se mně, že se tam dá vše naklikat. Nepotřebuji provozovat žádné složitosti. A nejspíš to spustím a víc nebudu upravovat. Bude tam asi 8 strojů.

Můžete prosím rozvést tu DB. Nepochopil jsem jak ji provozovat. Kvůli ní jsem kupoval SSD a vy tvrdíte, že to bude pomalejší. Ano jsou SATA :(

[dustin]

Rozumné SSD rozhodně nebude pro databázi pomalejší než 2-4xHDD hwraid10, protože má minimálně o řád kratší přístupovou dobu, spíš o víc. HW raid se zálohovanou write-cache má možná srovnatelně rychlý flush, ale seeky budou pořád stejně pomalé, když se netrefí do read keše. A 1 GB na řadiči není žádná podstatná read keš. SATA vs. SAS není zdaleka takový rychlostní rozdíl, aby to hrálo ve prospěch SAS HDD.

Pokud potřebuji vyšší výkon na DB, používám dvě slušnější SSD, na nich partišny ponechávající kousek volného místa, ty umístěné do md raid1. Mám jistotu, že i po zasynchronizování celé partišny do pole mi trim následně uvolní bloky nepoužívané filesystémem (starší HW raidy trim neprošíří)

[chinook]

Ok ok. A ty db stroje do kontejneru, když ne virtualizovat? Nebo kam s nimi?

[chinook]

Tak jsem to nakoneco udělal takto.

Použil HW raid 10 na terabitové disky a raid 1 na SSD disky. Tam vytvořil LVM na to dal DRBD a přes KVM rovnou na DRBD virtuálky. Ted nevím jak dál ve virtuálkách. Dát LVM a na oddíli BTRFS? Někde jsem čet, že to může být pomalé, ale byl jsem zvyklý mít dksky např. filmy s kapacitou 100G, fotky 50GB atd. Umí to BTRFS, nebo je nutno použít kvoty nebo jak to řešit?

Jinak jak tu někdo poznamenal, ty SSD jsou pomalejší než to pole s terabitových disků. Pole čte nějakých 650MB/s ssd pouze 450MB/s.

[dustin]

Jedna věc je rychlost čtení, druhá věc rychlost přístupu. Záleží, co potřebuješ víc, pro mě je důležitější >10x kratší přístupová doba, než 2 x rychlejší tok dat. Ale moje servery obvykle pracují se spoustou menších souborů.

[Heron]

Ted nevím jak dál ve virtuálkách. Dát LVM a na oddíli BTRFS? Někde jsem čet, že to může být pomalé, ale byl jsem zvyklý mít dksky např. filmy s kapacitou 100G, fotky 50GB atd. Umí to BTRFS, nebo je nutno použít kvoty nebo jak to řešit?

BTRFS má subvolumes. Pokud je nutno omezit velikost, tak na subvolume lze aplikovat quotu, ale s tím jsem si nikdy nehrál. Dávat btrfs na lvm je blbost, tj popírání jedné z vlastností btrfs. Se subvolumy lze dělat snapshoty, send; sdílí se volné místo (klasický problém s LVM, v oddílu na filmy je 50GB volného, ale ty jsou potřeba v oddílu na projekty). Takže na virtuálky bych dal už jen čisté BTRFS (pochopitelně se zamyšlením se nad využitím daného fs, třeba na db server bych to nedal, dělat cow nad cow (mvcc architektuře) je přece jen pomalejší - na druhou stranu se to ale dá vypnout pomocí chattr na konkretní adresář a instalátor pg v debu už to tak nastavuje automaticky).

Jinak jak tu někdo poznamenal, ty SSD jsou pomalejší než to pole s terabitových disků. Pole čte nějakých 650MB/s ssd pouze 450MB/s.

Tj sice hezké, ale sekvenční rychlost není vše. Klasický 7200rpm disk dá v náhodném přístupu nějakých 0.5MB/s (7200rpm / 60 = 120; 120*4kB = 480kB/s). I nejobyčejnější SSDkčo v náhodném přístupu dá 40MB/s, což je 80x tolik co rotační disk. Toto je hlavní výhoda SSD.

[lertimir]

Jak už bylo poznamenáno čtení není vše. Disky v současnosti mají cca 200-250MB/s rychlosti sekvečního přístupu. Při sekvenčním čtení RAID10 mohou všechny 4 disky číst současně jiná data, a řízení pole to nakonec sloučí do výsledného toku. Už sekvenční zápis bude pomalejší, protože zapisovat různá data mohou jen dva různé disky, druhé dva píšou přesnou kopii, což se v nárustu rychlosti neprojeví. Ale hlavně jde u SSD o množství jednotlivých zápisů za sekundu IOPS. Disk na 7200 rpm se otočí 120 krát za sekundu. což znamená, že když v náhodném čase dostane nějaký požadavek na čtení nebo zápis tak mu může trvat až 1/120 sec než se k datům dostane, když hlava zrovna minula radius kde data jsou (nebo se nestihla k nim včas přesunout) seek time je kolem 8-9ms a celé to znamená, že efektivně rotační disk má tak 100-120 IOPS za sekundu. SSD má 40 000 IOPS a více. To je ten hlavní rozdíl. Pokud při startu aplikace je naprogramováno, že se celkem 500 hrábne někam na disk (program, knihovny, data, konfigurace atd.), tak rotační disk ji dříve než za 5 sekund nespustí. Pokud databáze hrabe po disku, tak seeky jsou ten nejvetší čas, který spotřebovává.

Dělit disky na filmy a fotky pomocí LVM mi přijde zbytečné, BTRFS umí subvolumy a pak má společný datový prostor. Na LVM s BTRFS je třeba mít lepší důvod. Sám to používám kdy LVM je uvnitř LUKS kontaineru a dělení LVM je na swap oddíl a BTRFS oddíl se systémem a vším ostatním v subvolumech. Dokázal bych chápat mít samostatné LVM kontainery pro jednotlivé virtuály a na nich BTRFS se suboddíly pro ten konkrétní virtuál díky obavě, aby když se něco stane v jednou virtuálu a porušilo by se nějak BTRFS aby to neovlivnilo jiné virtuály. Mě se to sice zatím nestalo, ale občas tu jsou přibhy s restaurování dat s BTRFS. Rychlostně jsem žádné zásadní problém se stackováním LVM a BTRFS nezaznamenal.

[Aleš Kapica]

Mě se to sice zatím nestalo, ale občas tu jsou přibhy s restaurování dat s BTRFS.

Zpravidla od těch co s ním nemají absolutně žádnou zkušenost.

[k3dAR]

ja mam take 1 zkusenost s btrfs, prevod z ext4, nestacilo ~30% volneho a reklo to az na konci neuspesneho prevodu, pridal sem na ~75% free, konverze prosla, ale za tejden se btrfs komplet podelal, kontrola hlasila hromadu chyb a nepomahala zadna oprava, doslo na reformat zpatky na ext4 a od te doby zadny problem slo tusim o jadro 4.10 a v te dobe posledni btrfs-progs...
ono filesystem co potrebuje vystudovanou 7letou vysokou skolu se zamerenim na btrfs aby ho uzivatel mohl pouzivat, vedel jak zjistit priblizne volne misto a dokazal opravit pri poskozeni je opravdu idealni filesystem

[Aleš Kapica]

Exemplární příklad.

Ale nedělej si z toho hlavu. Můj kolega je na tom obdobně. Opravdu nechápu jak to děláte.

P.S.: Já na rozdíl od něj žádnou vysokou školu nemám, takže tvoje aproximace zvládnutí Btrfs s vysokoškolským vzděláním kulhá na obě nohy.

[k3dAR]

jasne, proto sem to napsal ze to byl exemplarni priklad ;)

[Aleš Kapica]

Ne. TY jsi exemplární případ.

[lertimir]

No já jsem před 4 lety začal používat btrfs na SSD, protože to byl (a je) v podstatě jediný systém, který má vědomí o ssd a COW jim vyhovuje. od té doby jsem tak cca před 2 lety přešel na btrfs na všem včetně rotačních disků o xTB objemech, zu hlediska BTRFS, vše jede bez problému. I s tím, že po krátkou dobu byly některé disky zaplněné až na 98% kapacity (ale v té době se z nich jen četlo a zapisovaly větší soubory v celku) a vše bylo bez problémů. Jediné místo, kde mi zůstává ext4 je z historického důvodu md RAID 10 obsahující oddíl pro BackupPC zálohovací systém všech domácích počítačů. A nikdy nebyl přímo s btrfs žádný problém a několikrát mi snapshoty na systém zachránily data. Takže také nevím, s čím je takový problém.

[k3dAR]

to rad slysim, samozrejme ze COW me laka, stejne tak snapshoty (vyuzivam normalne LUKS->LVM->EXT4, kde snapshoty sice take, ale z principu okrajove a jen pri nejakem zasadnim zasahu do systemu, nikoliv pro bezne snapshotovani stovek ruznych historickych stavu(+ pri kazdem apt upgrade/install) ktere v pripade BTRFS je brano za samozrejmost), to ze subvolume sdilej spolecny prostor (pri nepouziti kvot) mi naopak idealni neprijde, minimalne (mozna jako neuzivatele BTRFS), ze bych nemel prehled o volnem mistu, takze pokud bych BTRFS zacal pouzivat, dost mozna misto subvolumes, stale nad jednotlivejma LV (tam absolutne nemam problem s zvetsovanim/zmensovanim, nechavanim volneho mista v VG atd)...

nakonec uznavam, ze zvniknuje vice nez mozne, ze muj popsanej problem byl dan prave tou online konverzi z EXT4, ale proste sem v to neziskal duveru a dal tomu zas nejaky cas nes to znovu zkusim ;)

[k3dAR]

s/zvniknuje/je/,s/nes/nez/ ;)

[chinook]

Problém je v tom, že server používá asi 150lidí. A jsou tam složky přístupné pro třeba 50 uživatelů. A potřebuji jim nějak omezit velikost disku, jinak může být velký jakkoliv a stejně jej zaplní. Dosud jsem to řešil přes LV, kde jsem nastavil velikost např. 100GB a dál je nepustil. Dřív jsem měl kvóty, ale nakonec se mně více líbila velikost LV. Sdílené místo mezi subvolumes tedy vidím jako nevýhodu. Protože přeteče složka filmy a ta zaplní i videa. A kdybych měl na stején partition i systém, tak i ten.

Takže v současnosti jsem nainstaloval systém na LVM a pro data vyhradil parttition s btrfs a tam dal subvolumes. Ale nevím jak dál s omezením té velikosti subvolumes.

[Josef Kufner]

Nejde o sdílené místo, ale o kvóty. Sdílené místo je fajn, že nemusíš řešit problémy kdy jeden oddíl je trochu menší, než je potřeba. Kvóty vyřeší to, že subvolume nepřeroste pevně danou mez (btrfs qgroup limit …). Když pak někdo přijde s dobrým důvodem, že potřebuje 50 GB navíc, tak mu hejbneš kvótou a všichni jsou spokojení.

[chinook]

Už jsem pronikl do btrfs a super systém. Kvóty tedy použiji. Jen jsem asi nevhodně rozdělil disk ve virtuálce.

mám:

/dev/sda1 - boot /dev/sda2 - lvm, ktere je rozdeleno na lv-root, lv-log a lv-swap a pak /dev/sda3 - btrfs na data

Asi by bylo lepší disk rozdělit takto, kvůli resize, ne?

/dev/sda - lvm, kde bude lv-root, lv-log, lv-swap a lv-data

na lv-data nasadím btrfs a rozdělím na subvolume

V tom druhém řešení mohu jednodušeji resizovat velikost sda a tím jednotlivých partition.

V prvním je to složitější musím přes nějakej gpart a ne vždy to půjde je to tak?

[Aleš Kapica]

Být tebou, tak se snažím o minimum mezivrstev. Rozhodně ale použij diskový oddíl. Takže. Udělal bych dva diskové oddíly - jeden velký /dev/sda1 pro Btrfs a za ním menší /dev/sda2 pro swap - můžeš žoglovat se souborovým systémem a nerozjebeš si pořadí diskových oddílů - začátek na 2048 - nebudeš mít problém s umístěním zavaděče pro grub.

LVM v tomto případě vůbec nedává smysl!!

[Aleš Kapica]

Jo a pokud máš rád svoje data, použij multidevice system se třemi disky. Vyhneš se trablům co tuhle řešil jeden co udělal btrfs raid1 jen ze dvou disků a pak se děsně divil, a zároveň minimalizuješ ztrátu dat když ti chcípne disk. V poslední době jich v mém okolí chcíplo hned několik. A žáden z majitelů nedbal na mé rady, takže bez výjimky přišli o data.

[Josef Kufner]

Pokud máš rád svoje data, tak v první řadě zálohuj! Nejlépe denně a automaticky.

[Aleš Kapica]

Zálohy jsou samozřejmě vysouce žádoucí - řeší situaci kdy vám někdo štípne notebook, nebo celý počítač. Ale jinak se postavte nohama na zem, a optejte se jak to kdo se zálohováním zvládá.

[trekker.dk]

U produkčních serverů každodenní záloha všech dat a databází, jednou za měsíc se ta záloha přeleje do jiného datacentra. U svého desktopu zálohuju jednou za čas ručně na domácí server, děkuji za optání

[Aleš Kapica]

Dobrá. To jsi ty. Teď se optej ještě kolem sebe.

Nicméně, sám jsi naťuk jádro pudla:

U svého desktopu zálohuju jednou za čas ručně na domácí server,..

Pokud si myslíš, že to je vyhovující řešení, tak ti nebudu brát iluzi. Jenom si zkus dělat na papír čárky pokaždé, co si na to vzpomeneš a odzálohuješ. Zákon schválnosti je v tom, že ti to zdechne just těsně předtím co si na to po delší době vzpomeneš.

No a pak se ještě zamysli nad tím, co všechno by ve tvém případě znamenalo dostat se do původního stavu, jak dlouho by to trvalo a kolik by to tak cca stálo času a peněz.

[trekker.dk]

To je v pohodě, na desktopu toho zase moc nemám, respektive nemění se to. Nejvíc se mění zdrojáky, ty jsou v gitu (tj. na několika počítačích.) Ale uznávám, že systém nezálohuju a dostat ho do stavu bez hovadin, které se v linuxovém exkosystému objevily za posledních pět let, to by nějaký čas zabralo.

[Aleš Kapica]

A přesně o tom to je. Aby ses pak nedostal do situace, kdy zjistíš že něco ti někde chybí a zaboha si nemůžeš vzpomenout co a kde. Nedejbože ještě v situaci, kdy se k tomu nemáš jak dostat.

[Heron]

Tak já si myslím, že v místní dlouhodobé partě lidí na abíčku se o tom fakt nemusíme bavit. Že to má každý vyřešeno způsobem, který mu vyhovuje.

Já třeba desktopy a ntb apod. věci nezálohuju, protože veškerou práci mám na gitu. Když ten stroj selže, tak ho nainstaluju znovu a udělám git clone toho, co zrovna potřebuju.

Gitlab zálohuju denně. Stejně jako všechny ostatní kontejnery, jaily, nspawny. Zálohuje se to na jiný stroj, než to běží (jinak to není záloha). Jednou za čas (jednou za 14 dnů, případně i častěji, pokud dělám na něčem o co nechci přijít), to strčím na externí disky. Které rotují, takže každá věc je na minimálně dvou externích diskách.

Možná otázka na /etc apod. Snažím se, aby systémy, které běží přímo na HW, byly v nějaké dobře definované minimální konfiguraci. Takže linux + zprovoznit nspawny. Done. bsd + jaily. Done. To je tak na 10 minut max od čistého železa. Obnoví se subvolumy / datasety a pustí se to.

S desktopem je to trochu horší, tam /etc/ sice zálohuju (bacula), ale při další instalaci se jedná spíš o inspiraci, než že bych to kopírovat znova celé. Nedávno jsem desktop instaloval znovu (ne že bych musel, ale i z důvodů, o kterých píšeš - jak dlouho, zda to půjde apod.) a všechny věci jsem si řešil ve chvíli, až jsem je potřeboval. Nakonec se to ukázalo jako nejefektivnější. Nainstalovat balíček lze kdykoliv, je to hned a skončil jsem opět s lehčím desktopem, než před tím.

Ale zálohování vychází z toho, co chci obnovit. Takže to každý může mít jinak.

O produkci v práci jen v krátkosti. Každých x hodin záloha na disky, každých x dnů záloha na pásky a na externí servery mimo danou lokalitu. Pásky se jednou za čas odnesou a strčí do trezoru.

[Petr]

V praci vsechny produkcni i testovaci prostredi kazdou hodinu, u databazi mame zalohy k jakemukoliv okamziku. Tohle vsechno se synchronizuje navzajem mezi ruznymi DC. Jednou denne to jde ze zalohovaciho storage na pasky, jednou tydne to jde do sejfu. Domaci storage systemy se synchronizuji mezi sebou v ruznych lokalitach (kde bydlim), zalohovani kazdeho je vzdy na dva dalsi + nektera data na amazon glacier, nektera na amazon s3, v obou pripadech geograficky jine 2x glacier a 2x s3). Krom toho dulezita data mam na blu ray discich ve 3 kopiich, 2 v ruznych lokalitach, 1 v sejfu v bance. Domace pocitace zalohuji pres timemachine vzdy na dva disky a data z lokalnich i externich (usb, thunderbolt) disku na storage v siti a tam se to uz synchronizuje dal jak jsem psal. Ano, stoji to penize, stalo me to spoustu casu k setupu ale data mam v relativnim bezpeci.

A tvoje pracovní pozice se jmenuje Data Storage Manager .

[Petr]

Se storage v praci nemam nic spolecnyho, ale v zivote jsem si profesne prosel pozici kde backup byl #1, tudiz to zdeformovalo muj pohled na zalohovani. ;)

[Josef Kufner]

Notebook se mi zálohuje každý večer na domácí server.

Pořídit NAS a nastavit si nějaké udělátko na zálohování je to nejlepší, co běžný uživatel může pro svá data udělat. Čas od času je dobré pak zálohu hodit na offline disk a ten mít někde jinde, aby požár/zloděj nevzal všechno.

[chinook]

Tak raid mám na serveru kde běží virtuálky, nemusím tedy další stavět ve virtuálce nebo ano?

[Aleš Kapica]

Můžeš, ale je to zbytečné.

[k3dAR]

ano, dalsi pripad, kdo by cekal ze kdyz udela raid mirror na 2 disky, tak pri chcipnuti 1 disku to znamena ztratu dat, ten co vystudoval vysokou skolu btrfsackou ;)

[chinook]

Sice to není můj případ, ale nechápu to, když budu mít btrfs dva disky v raid 1 a jeden odejde, přišel jsem o data i když metadata i data budou rovnoměrně na obou discích?

[Aleš Kapica]

Ne. Ale musíš ho ihned nahradit. Když máš tři, tak to ihned řešit nemusíš.

[vandrovnik]

O data nepřijdete, ale dost možná dopadnete jako já, že je budete mít v režimu read-only Byla tady na toto téma nedávno výživná diskuze, ze které v podstatě vyplynulo, že btrfs raid 1 není určený pro pouze 2 disky, chce to disků víc a ještě udržovat hodně volného místa, aby si btrfs při výpadku disku mohlo data přeskládat na ty zbývající.

[k3dAR]

taky to nechapu, jeden (resp. vsichni neabsolventi Vysoke skoly Btrfsacke), by rekl ze kdyz udela raid mirror, tak se to zrcadli a pri vypadku jednoho ma readwrite vsechna data z druheho a muze to mit tak jak dlouho chce, dokud tento druhej disk take nechcipne :)

[chinook]

A co když budu chtít sda1 zvětšit?

Zvětším celý disk ve virtuálce přidam /dev/sda3 a přidám do btrfs jako další zařízení?

[Aleš Kapica]

Pokud chceš na tom používat virtuální disky, tak na btrfs zapomeň. Pro tenhle účel se nehodí. To tam raději dej to LVM.

[karlik]

No konečně to někomu došlo.

[chinook]

Proč? Nikde jsem to nečetl, pouze že kvůli fragmentaci se nehodí na virtuálky a databáze. Nikoliv pro provoz ve virtuálce.

[Aleš Kapica]

Tak se prosím zamysli a přečti si co znamená COW.

Virtuální disk je soubor, do kterého zapisuje virtuál. Pokud zajímá FS pouze jeho délka a obsah je mu ukradený, musí řešit konzistenci obsahu virtuál. Jenže Btrfs je souborový systém, kterého zajímá i konzistence obsahu. Logicky mu tedy bude vadit, když mi do toho počítání bude kecat nějaký virtuál.

[chinook]

Ale já na něm nechci provozovat virtuálku, tu provozuji na LV, tedy blokovém zařízení. A až ve virtuálce mám btrfs.

[Aleš Kapica]

V tom případě jsi to nenapsal pro mne dost srozumitelně.

Ve virtuálu je to v zásadě jedno co použiješ. Pokud budeš uvnitř provozovat kontejnerovou virtualizaci, tak se Btrfs nejspíš vyplatí, pokud v něm budeš mít nějaký databázový server, tak já bych asi spíš použil ext3. Ale já už dávno virtuály s klasickým blokovým zařízením nepoužívám.

[chinook]

Já si říkal, že každý mluvíme o něčeme jiným :)

a co používáš QCOW2? nebo něco jiného?

[Aleš Kapica]

Používám diskless, v kombinaci se zaváděním z malé (cca 200MB) image s jádrem, natažené přes NFS. Na ní je teda Btrfs.

[Josef Kufner]

Pokud nešifruješ, tak udělej na začátku malý EFI odddíl a všechno ostatní sesypej dohromady. Pokud chceš uspávat na disk, tak pár GB dej na swapovací oddíl.

Pokud šifruješ, tak vedle malého EFI udělej trochu větší /boot. Zbytek do luks a v tom LVM pro / a swap. (Tak to má Debian.)

Rozdělovat to nějak víc nemá moc smysl.

Pokud na / použiješ btrfs, tak si šikovně navyráběj subvolume, aby se dalo dobře snapshotovat.

[chinook]

Jak tedy rozdělit ten disk? Nějak jsme odbočili kvůli zálohvání...

[karlik]

Prostě použij klasiku, nad RAID dej LVM a můžeš si hrát s různými fs do alelujá...

Já mám třeba nad RAID vyhrazený jeden diskový oddíl a fs a v něm sparse soubory pro KVM a samostatný disk jen na zálohy a taky to jede.

[chinook]

Tak bych to nejraději udělal, ale na stránkách BTRFS jsem četl, že když bude nad LVM, tak je pomalejší. Proto bych radějí rovnou nad SDA, ale nevím jak ten disk rozdělit, abych jej pak pohodlně resizoval.

Pokud rozdíl rychlosti nebude výrazný asi to hodím nad LVM. Má někdo zkušenost ve virtuálce LVM a na to BTRFS?

Klidně mít jen jedno LV a tam dát btrfs a udělat si subvolumy.

[karlik]

Proto LVM nemám, mám jen RAID, nad ním diskový oddíl a v něm sparse soubory s KVM obrazy disků.

Ovšem v tomto případě vidím vyšší flexibilitu s LVM.

Jak již bylo řečeno, na virtualizaci se btrfs (zatím) moc nehodí. Fandím tomuto fs.

Mám ale příliš rád firemní data a v mém případě vychází stabilita a jednoduchost před nespornými výhodami btrfs.

[chinook]

Ale proč se nehodí? Chápu, že se nehodí na prostor na kterém poběží virtuálka, kvůli fragmentaci, ale nechápu proč se nehodí na chod ve virtualce. Kvůli resize, stabilitě nebo kvůli čemu?

Pokud tu řeknete, že BTRFS není stabilní, použiji LVM a EXT4 a na zálohy dám btrfs a snapshoty budu vytvářet tam. Ale líbí se mně ještě komprese dat, např. na mail si myslím, že by se hodně ušetřilo.

[chinook]

Mám takový pocit, že v tomto vlákně došlo k záměně toho, co má být na fyzickém stroji a co má být ve virtuálce.

Pokud se bavíme o plné virtualizaci, tak ve virtuálce může běžet libovolný OS a tedy i různé FS. Když tam budou widle, tak tam bude ntfs apod, takže v některých případech si fs stejně nevybereme.

Ve virtuálce s linuxem rozhodně btrfs nevadí, naopak, dá se použít s velkou výhodou. Navíc se tím i současně vyhneme i jedné nepříjemné vlastnosti, kterou má btrfs multidevice, a to chování při výpadku disku. (Nutnost umount / mount do degraded, odstranit chybějící disk, přidat nový disk, umount / mount do normálu). Virtuálka nikdy nezažije výpadek disku, takže toto tam nenastane. Takže lze snadno online přidat místo přidáním dalšího disku do virtuálky a připojením do btrfs. A lze ho i odebrat, btrfs umí online shrink a disk lze odebrat za běhu i z toho kvm virtuálu.

Jak už jsem psal, na fyzické železo bych žádný fs nedával (pro virtuálky) a ty bych měl přímo na blokovém zařízení. Logicky se nabízí se LVM, ale klidně se tam dají strkat i jednotlivé oddíly třeba z GPT. Prostě tuhle vrstvu vyřešit co nejjednodušeji.

[Aleš Kapica]

na stránkách BTRFS jsem četl, že když bude nad LVM, tak je pomalejší

To je pěkná kravina. LVM ti akorát rozdělí disk na logické bloky. Na rychlost FS, co bude nad ním to nemá žádný vliv. Leda že bys snad měl to LVM v nějakém raidu. Pak ti to bude logicky brzdit replikace dat.

[chinook]

Pišou tam toto:

Performance raw partitions are slightly faster than logical volumes btrfs does write optimisation (sequential writes) across a filesystem subvolume write performance will benefit from this algorithm creating multiple btrfs filesystems, each on a different LV, means that the algorithm can be ineffective (although the kernel will still perform some optimization at the block device level)

Navíc jak píše Heron je to vrstva navíc. Docela mě přesvědčil, že vše co udělám přes lvm udělám i BTRFs. Už jsem tedy nainstaloval na virtuálku pouze 1 partition s BTRFS, ale to lze stále ještě změnit.

[Aleš Kapica]

Ano, to je také jedna z věcí co si málokdo uvědomuje jako výhodu Btrfs:

..lze stále ještě změnit

Když jsem zrovna nedávno stěhoval taliánovi data, tak jsem nejprve na externí mašině překopíroval jeden jeho disk, ale zbytek (přesun ostatních dat a následně konverze na raid1) se už pak realizoval za běhu u něj na kompu, aniž by ho to rušilo v práci. Akorát byl nutný restart, protože ty původní disky bylo nutné postupně z té jeho bedny vykuchat a nahradit – neměl šuplíky, ani koš.

[dustin]

Nic proti btrfs, ale proč by to samé nešlo za běhu dělat třeba na mdraidu?

[Aleš Kapica]

Protože ho nesložíš z různých disků, ani ho za běhu nepřetransformuješ na jiný typ.

[dustin]

mdraid ze svého principu vskutku použije z disku/partišny jen nejmenší společnou velikost všech prvků raidu. Stejně jako třeba raid v ZFS. Osobně mi to tak vyhovuje víc, ale každý má jiné potřeby.

mdraid online konverzi levelu podporuje a běžně se používá, bohužel neumí všechny kombinace:

convert between RAID1 and RAID5, between RAID5 and RAID6, between RAID0, RAID4, and RAID5, and between RAID0 and RAID10 (in the near-2 mode).

Nic proti btrfs (ač jej nepoužívám, vyhovuje mi víc zfs). Jen aby nedošlo k nedorozumění..

[trekker.dk]

Pišou tam toto:

To není nic specifického pro btrfs, podobné optimalizace mají i ostatní filesystémy.

[Aleš Kapica]

Viz odstavec o kvótách.

[Max]

Překvapuje mně, že jen jeden člověk zde zmínil qcow2. Já bych už virtuál jako raw disk v podobě LVM asi nepoužíval. Jasně, qcow2 má nějaké diskové režie, ale ty jsou díky dobrému cachování zanedbatelné a má spoustu fcí navíc.
Podporuje snapshoty na lepší úrovni, jak lvm, jelikož implementuje copy on write, podporuje kompresy, šifrování, je jednoušeji přenositelný a prostě se z něj stává standard pro kvm.
Zdar Max

[Heron]

Mě se použití qcow2 nelíbí z toho důvodu, že to přidává další dvě vrstvy navíc. Musí tam být fs (nebo lze mít qcow2 formát na block device?) potom ten qcow2 soubor a nad tím virtuálka (ve které bude opět další fs). Tím, že se virtuálka postaví přímo nad block device se toto eliminuje.

Spíše než přidávat další vrstvy by se mi líbilo mít blockdevice manager už s přímo podporou funkcí, které umí qcow2 (nebo v zásadě jakýkoliv jiný cow systém (btrfs, zfs)). S CEPHem to moc nedopadlo (ale tohle jsme teda přímo netestovali), nevím, jak je na tom v tomto ohledu sheepdog.

Ty máš qcow2 nasazený? Jaký pod to používáš fs?

[trekker.dk]

Mě se použití qcow2 nelíbí z toho důvodu, že to přidává další dvě vrstvy navíc.

Souhlas. (Až na ten pravopis teda.)

[Max]

Ahoj, mé zkušenosti jsou malé. Měl jsem virtuály nasazeny v kvm a samotné vm byly v lvm. Takto jsem to provozoval delší dobu, ale jen pár strojů, protože to byl workaround na oracle licence. Provozoval jsem v tom aplikační server a testovací databázi.

Celkově mi nevyhovovalo používání LVM a snapshotů. Přišlo mi to nepřehledné a spíš to byl voser. Ze začátku jsem používal web virt manager, který podporoval snapshoty a další věci jen s qcow, na což jsem přišel až později. Když se dívám na současný stav, je to podobné, nikdo lvm moc nepodporuje (z mgmt hlediska).

Aktuálně provozuji na qcow2 dva Oracle RAC servery. Mám starý Oracle 11, který umí běžet jen na OEL5, maximálně nepodporovaně na OEL6. HW je podporován od OEL6, nebo 7, takže mám na dvou serverech OEL7, pod ním kvm s OEL5 a qcow2. Až otestuji upgrade na Oracle12, tak VM zruším a z těch hypervisorů udělám primární db. Databázi a transakční logy mám ale na nfs (společném ssd netapp storage, vše připojeno přes 2x10Gbit a v linuxu používám team, né bond).
Dělal jsem nějaké výkonnostní testy ohledně náhodných i sekvenčních zápisů, ale né lokálně, ale na nfs disky. Dělal jsem testy rychlosti sítě z těch kvm pomocí iperf a ok. Poté jsem dělal testy zápisů na nfs, jak z fyzického stroje, tak z kvm. to jsem dělal pomocí fio.
Pro mgm jsem použil libvirt, vytvořil jsem tedy vm takto :

virt-install --name rac1-2 --ram 16384 \
--os-type=linux \
--os-variant=ol5.11 \
--disk path=/vm/rac1-2_01.qcow2,format=qcow2,bus=virtio,size=60 \
-c /mnt/iso/Oracle/OEL/OEL-5U11-V47133-01.iso \
--network bridge=br0-lan,model=virtio,mac=RANDOM \
--network bridge=br1-ha,model=virtio,mac=RANDOM \
--graphics vnc,password=heslo,listen=0.0.0.0,port=5900 --noautoconsole \
-v --vcpus=12 \
--boot cdrom,hd

# NFS3 (host OEL7) :

192.168.0.3:/vol_ssd_rac on /mnt/ssd type nfs (rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.3,mountvers=3,mountport=635,mountproto=udp,local_lock=none,addr=192.168.0.3)

[root@hv-rac1 ssd]# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.2.8
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [m(1)] [100.0% done] [22596KB/7440KB/0KB /s] [5649/1860/0 iops] [eta 00m:00s] 
test: (groupid=0, jobs=1): err= 0: pid=3681: Fri Sep 22 01:01:27 2017
  read : io=3071.7MB, bw=23706KB/s, iops=5926, runt=132681msec
  write: io=1024.4MB, bw=7905.6KB/s, iops=1976, runt=132681msec
  cpu          : usr=1.31%, sys=3.78%, ctx=414454, majf=0, minf=26
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: io=3071.7MB, aggrb=23706KB/s, minb=23706KB/s, maxb=23706KB/s, mint=132681msec, maxt=132681msec
  WRITE: io=1024.4MB, aggrb=7905KB/s, minb=7905KB/s, maxb=7905KB/s, mint=132681msec, maxt=132681msec

NFS3 (guest OEL5)

192.168.0.3:/vol_ssd_rac on /mnt/ssd_rac type nfs (rw,nfsvers=3,addr=192.168.0.3)

[root@back-rac1 ssd_rac]# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio 1.57
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [m] [100.0% done] [38436K/13025K /s] [9384 /3180  iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=3540
  read : io=3072.9MB, bw=32867KB/s, iops=8216 , runt= 95736msec
  write: io=1023.2MB, bw=10944KB/s, iops=2735 , runt= 95736msec
  cpu          : usr=1.04%, sys=4.54%, ctx=1503280, majf=0, minf=20
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued r/w/d: total=786645/261931/0, short=0/0/0



Run status group 0 (all jobs):
   READ: io=3072.9MB, aggrb=32867KB/s, minb=33656KB/s, maxb=33656KB/s, mint=95736msec, maxt=95736msec
  WRITE: io=1023.2MB, aggrb=10943KB/s, minb=11206KB/s, maxb=11206KB/s, mint=95736msec, maxt=95736msec

Takže nejedná se o test výkonu těch qcow2, to nemám. Navíc test výkonu toho nfs je přes agregovanou linku, resp. NetApp QoSí na 2,5Gbit.
Ale budu dělat komplexnější testy, větší soubory, jak 4GiB, testy lokálu atd. Takže pak to kdyžtak zveřejním.
Zdar Max

[Heron]

Ze začátku jsem používal web virt manager, který podporoval snapshoty a další věci jen s qcow, na což jsem přišel až později.

No všem těmhle věcem se ze zásady vyhýbám a snažím se to dělat na tak nízké vrstvě, na které jsem ještě schopen. Protože všechna takhle klikátka jsou hrozně fajn a to přesně to chvíle, než člověk narazí na něco, co to neumí a nebo to chvíle, kdy se něco pokazí. Takže potom u některých adminů nastavá fáze "toto udělat přes klikátko a toto už ručně" a v případě pokažení se to většinou pokazí tak důkladně, že už to nejde opravit.

A abych okamžitě porušil to, co jsem teď tvrdil, tak používám virsh na cli. Ale to jen z lenosti, protože jsem si ještě pořádně nevyzkoušel spouštění přímo pomocí qemu-kvm (dneska qemu-system-x86_64).

Na LVM snapshotech nevidím nic zvláštního. Prostě máš blokové zařízení ve stavu v jakém bylo v době pořízení snapshotu. Původní LV běží bez problémů dál (akorát o něco pomalejší zápisy).

[Max]

Web virt jsem používal ze začátku na seznámení se, jak by to mělo fungovat. Teď používám virsh a nevidím důvod přejít ještě o úroveň níž.
Zdar Max

[Aleš Kapica]

QCOW2 je výhodný pokud používáš Sheepdog, který vypadá v jádru podobně jako Btrfs. Ceph si s ním prý moc nerozumí.

Proč je výhodný. Inu. Data se sypou do kontejneru, a pokud používáš QCOW2, tak se moc nemění. Když dojde k situaci že ti stroj exne, tak sjedeš kontrolu kontejneru, pak můžeš využít toho že pro QCOW2 je k dispozici opravný mechanismus, a ve virtuálu už nic neřešíš přijde maximálně jen o to co se nestihlo uložit.

U RAW kontejneru ti naopak virtuál furt někam hrabe, takže když exne, musíš zkontrolovat konzistenci celého kontejneru, ale i tak ti FS virtualizovaného systému najede nabouraný a musíš ještě řešit jeho konzistenci ve virtuálu.

Jenže Sheepdog není LVM. Sheepdog má podobně jako Ceph data rozeseta jako soubory. Logicky je pak tím pádem výhodné mít tyto soubory umístěné na Btrfs (což Ceph vyloženě nesnáší), protože to významně urychluje kontrolu konzistence VDI kontejneru (kontrolní součty jsou ihned k dispozici). Navíc se zde výhodně uplatňuje komprese na úrovni FS. Je-li v raid1, tak je to úplně cajk. Poškozený blok se zahodí a rovnou obnoví z repliky. Navíc lze využít snaphotování na úrovni VDI, nejenom uvnitř COW2 souboru.

Ovšem aby to fungovalo spolehlivě, musí komunikace sheepdogu probíhat po nezávislé síti, jinak se to bude rozpadat, když někdo ucpe síťové připojení.

[chinook]

Jen info pro někoho, kdo by řešil stejný problém, píši kam jsem pokročil.

Nakonec jsem se rozhodl pro HW raid. RAID 10 na 6X1,2TB 10 000RPM a raid 1 na SSD. Vím, že tu bylo dosti názorů, že v hw raidu je vždy chyba, ale podle mě jich tam je tak málo, že je nepravděpodobné, že se to se sype. Navíc windowsáři používají jen to :) (nechci zakládat flame o HW raidu...)

Nad to jsem dal LVM a virtuálky zprovoznil na blokovém zařízení /dev/vg/lv-virtual-machine Virtuálka má velikost 8GB a k tomu pak přidávám disk na data formou /dev/vg/lv-virtual-machine-disk. Je to z důvodu, abych dělal snapshoty jen virtuálek. Data zálohuji zvlášt. Zatím přes rdiff-backup, ale udělám to pak tak, že na zálohovací server si dám BTRFS, tam přes rsync odliji data a udělám tam snapshot. Velká výhoda, že mám všechny zálohy živé.

Měl jsem strach, že nepůjdou dělat snapshoty na zálohy, kvůli vytížení systému, ale je to pohoda. Dělám tedy jen v noci. Udělám snapshot virtuálky, přes dd udělám zálohu a zazipuji, poté zkopíruji na jiný stroj a snapshot smazu.

Někde jsem na to dal ještě DRBD. Někdo tu zmínil, že to je pomalé či nespolehlivé, měl jsem z toho strach, nakonec to mám jen na webovém serveru a serveru, kde běží samba. Postgres má svoji replikaci, ta funguje skvěle, dovecot taky a ldap taky. To si myslím, že bude méně vytěžovat linku než DRBD. A pokud by se mně sesypal BTRFS systém, ke kterému ještě nemám důvěru, tak díky replikaci se nesesype na druhém serveru narozdíl od stavu který by nastal s DRBD.

Pak ještě nevím jak dělat snapshot virt. machine, která běží na DRBD. Udělám snapshot na lvm, ale pak při obnově se k virt. machině musím dostat zase přes DRBD? Nezkoušel jsem, ale samotné LVM mně přijde pohodlnější, proto se snažím DRBD vyhnout. Ještě mě napadlo, držet jen data v DRBD, ale zase upravovat každou konfiguraci 2x se mně taky nechce.

Každopádně díky KVM a snapshotům není problém předělat server na jinou strukturu vůbec problém a je to celkem rychlé. PošŤáka jsem insaloval snad 5x a nebylo to nic pracného diky virtualizaci.

Jo a na serveru mám 4 síťovky, nevěděl jsem jak to využít, tak jsem 1 připojil do switche pro uživatele a zbylé tři spojil na přímo s druhým serverem a dal do bondu. Rychlost co jsem měřil kolem 2,8Gbps. Zatím vše funguje spolehlivě. Přes bond mně běhá DRBD a replikace.

Jinak doteď jsem na virtualizaci používal ESXi, obrovská nevýhoda pro mě, že na serverech, kde nemám HW raid běží bez raidu. Další nevýhoda je, že to je černá bedna a když se tam něco rozbije horko těžko to zprovozním. Už to nechci vidět. Nezkoušel jsem na KVM tedy ještě rozběhat windows, ale co jsem čet, jedou tam pěkně.

Pak jsem zkoušel proxmox, je to klíkátko postavené nad KVM, mně se to moc nelíbilo a nějak se mně nedařilo si dělat úpravy jak jsem chtěl, moc jsem se tím nezabýval.

Pak jsem zkusil KVM a už nic jiného nechci. I když jsem to předtím nikdy neviděl, začal jsem přes virtmanagera a již to vesměs ovládám přes příkazy. Když chci nastavit server, udělám clone image, který mám vytvořený a za minutu mám předchystaný server s klíčema, nagiosem, balíkama adod. Pak stačí jen nainstalit službu jakou potřebuji. Bez KVM už server nebudu instalovat :) A kde mám ESXi předělám na KVM. Machine z esxi lze celkem jednodušše hodit na kvm, takže jak dodělám toto zbavím se esxi.

Snad jsem popsal všechno a někdo to taky využije. Pročetl jsem toho hodně i hodně názorů, ale tato řešení mně přišla nejlepší :)

Všem děkuji za pomoc hlavně díky tomtu foru jsem zvolil daná řešení.

[vakus]

Takto to robim aj ja. Esx uz nechcem ani vidiet. Akurat ze som z KVM presiel z pohodlnosti na Proxmox. Vyhodou je zabudovany backup (na NASko) a pouzitie LXC kontajnerov.

[k3dAR]

s virt-manager lze pouzit jak KVM, tak LXC...