abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 17:00 | Nová verze

Po pěti letech vývoje byla vydána nová verze 2.6.0 svobodné tahové strategické počítačové hry Freeciv (Wikipedie) inspirované herní sérií Civilization. Přehled novinek v oznámení o vydání.

Ladislav Hagara | Komentářů: 0
21.7. 16:11 | Nová verze

Byla vydána verze 8.0 open source unixového operačního systému NetBSD (Wikipedie). Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
21.7. 12:33 | Zajímavý projekt

Uživatel denholmsdead již více než rok zveřejňuje na redditu své obrázky s linuxovou tématikou. Náhledy obrázků jsou k dispozici na linux.pictures. Obrázky v plném rozlišení na GitLabu.

Ladislav Hagara | Komentářů: 3
20.7. 18:55 | Zajímavý projekt

Společnosti Google, Microsoft, Twitter a Facebook společně představily open source platformu Data Transfer Project (DTP). Cílem platformy je zjednodušit uživatelům přechod a přenos dat mezi jednotlivými online službami. Podrobnosti v pdf a na GitHubu.

Ladislav Hagara | Komentářů: 6
20.7. 18:33 | Nová verze

Canonical a Microsoft společně oznámili, že PowerShell Core je nově dostupný také jako snap balíček na Snapcraftu. Microsoft uvolnil zdrojové kódy PowerShellu (Wikipedie, GitHub) v srpnu 2016 pod open source licencí MIT a naportoval je na Linux.

Ladislav Hagara | Komentářů: 2
20.7. 13:11 | Zajímavý projekt

Novinkou v minor aktualizaci webového prohlížeče Vivaldi je podpora vyhledávače Qwant (Wikipedie). Vývojáři Vivaldi zdůrazňují, že se jedná o evropský vyhledávač respektující soukromí uživatelů.

Ladislav Hagara | Komentářů: 7
20.7. 01:33 | Nová verze

Po šesti letech od vydání verze 1.0 byla vydána verze 2.0 multiplatformního editoru tagů MusicBrainz Picard (Wikipedie). Přehled novinek, vylepšení a oprav v changelogu.

Ladislav Hagara | Komentářů: 0
19.7. 16:22 | Nová verze Ladislav Hagara | Komentářů: 14
19.7. 15:00 | Komunita

Dnes končí podpora Ubuntu 17.10 Artful Aardvark. Uživatelům je doporučen přechod na Ubuntu 18.04 Bionic Beaver s prodlouženou podporou do roku 2023. Podpora standardních verzí Ubuntu je 9 měsíců. Verze 17.10 byla vydána 19. října 2017.

Ladislav Hagara | Komentářů: 12
19.7. 13:33 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 334 bezpečnostních chyb. V Oracle Java SE je například opraveno 8 bezpečnostních chyb. Všechny jsou vzdáleně zneužitelné bez autentizace. V Oracle MySQL je opraveno 31 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 7 z nich.

Ladislav Hagara | Komentářů: 0
Jak čtete delší texty z webových stránek?
 (77%)
 (20%)
 (5%)
 (7%)
 (2%)
 (10%)
Celkem 376 hlasů
 Komentářů: 40, poslední 29.6. 10:21
    Rozcestník

    Zálohování KVM virtuálů

    16.8.2013 09:40 | Přečteno: 1911× | Výběrový blog

    Mám už několik produkčních hostů, všichni jsou typu qemu plná virtualizace s HW podporou, s image ve formátu qcow2 a jsou na cLVM svazcích. Hledal jsem, jak je efektivně zálohovat.

    Úvodem bych poznamenal, že zacházení s LVM svazky je trochu míň pohodlné než by bylo zacházení s image ve formě souborů. Jenže když mám image jako soubor, je přístup virtuálního hosta na disk o desítky procent pomalejší než ke stejnému disku přímo od hmotného hostitele. To jsem zjistil už před pár lety na XEN virtuálech a ověřil jsem, že to teď platí i pro KVM virtuály. Asi to bude tím, že když chce host něco udělat s n-tým diskovým blokem, vytvoří system call, ten dostane jádro hostitele a teď musí proběhnout seek v souborových službách hostitele. Oproti tomu LVM jde přímo na bloky.

    Nejasně jsem tušil, že správná záloha image znamená udělat snapshot image a ten nějak zazálohovat a poté smazat tak, aby se image běžícího hosta o ničem nedozvěděl. Moji hosté byli vytvořeni pomocí virt-install, takže k tvorbě a zpracování snapshotů máme na výběr qemu snapshoty třeba podle návodu tady, nebo virtlib snapshoty podle Kashyapa. Zkoušel jsem to oboje a podle určitých drobných rozdílností v chování bych hádal, že virtlib má svoje vlastní metody, jak zacházet se snapshoty, i když v podstatě musí používat stejné KVM konstrukce jako qemu. Pro uživatele je to vždycky takové, že doposud živý image se najednou zmrazí a je z něj snapshot, zatímco další změny páchané živým hostem jdou někam jinam, třeba do nového LVM svazku čerstvě vytvořeného. Není to copy-on-write, jen prosté zapisování do nového místa. Po zpracování snapshotu potřebuju zapsané bloky zkopírovat zpátky do původního image, k tomu slouží
    qemu-img commit <ten nový prostor>
    a následně se ten nový dočasný prostor může zlikvidovat. Jak se analogická operace udělá ve virsh jsem nějak nepochopil (což asi nebude vina virtlibu).

    Když mám vytvořený snapshot, rád bych se podíval, co v něm je. Na to ho musím napřed vyexportovat do jakoby blokového zařízení, a k tomu slouží
    qemu-nbd -c /dev/nbd0 <ten snapshot> .
    Pomocí fdisk se teď můžu podívat na strukturu virtuálního disku, a dopadne to např. takhle:

     # fdisk -u -l /dev/nbd0
    
    Disk /dev/nbd0: 21.5 GB, 21474836480 bytes
    255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x000ec934
    
         Device Boot      Start         End      Blocks   Id  System
    /dev/nbd0p1   *        2048    40136703    20067328   83  Linux
    /dev/nbd0p2        40136704    41940991      902144   82  Linux swap / Solaris
     # 
    
    Dobrá finta u fdisku je volbička -u , údaje o oblastech jsou potom spolehlivě v 512 B sektorech. Jestliže je na oblasti nbd0p1 souborový systém, třeba půjde namontovat read-only:
    mount -r -o offset=$((512*2048)) /dev/nbd0 /mnt
    Volba -r je důležitá, jinak si ve snapshotu něco změníme a jestli je ještě živý, zničíme si tím běžící image.

    Když se nechceme trápit s offsety, je tady podle jednoho návodu taková finta, která se mi líbí nejvíc ze všech vyguglených fint na tohle téma:
    modprobe -r loop && modprobe loop max_part=63
    mount -r /dev/nbd0p1 /mnt
    Česky řečeno, když si odloadujeme defaultně natažený modul pro loop zařízení a zase ho natáhneme s nenulovou hodnotou parametru max_part, tak nám losetup namapuje nejen zadané zařízení jako /dev/loop# , ale také všechny jeho oblasti jako bloková zařízení /dev/loop#p## .

    Až nás hrátky s obsahem snapshotu omrzí, je dobré nezapomenout všechno uklidit. Napřed všechny umount, potom všechny losetup -d a nakonec všechny qemu-nbd -d .

    Spolehlivost snapshoťáckých postupů jsem se snažil testovat tím, že jsem ve zkušebním hostovi pořád dělal manipulace se soubory a při tom jsem vytvářel, prohlížel a zase rušil snapshoty. Dvakrát mi při tom došlo k nevratnému narušení image, kdy mi ten host bez výstrahy spadnul. Mohlo to být chybou manipulace, ale podezření na chybu mechanismu snapshotů stejně mám. Nikomu ho nevnucuju, zkuste si to sami.

    Mount snapshotu zaživa není tak úplně nezbytná věc, ale bez něj je život o něco těžší. Takže se mi zdá důležité, že read-only mount popsaný výše se dost často nedá udělat. Není divu, virtualizační nástroj nic neví o filesystémech hosta a tak jsou file systémy ve snapshotu obecně v nekonzistentním stavu. fsck by to asi srovnal, ale to si na živém snapshotu nemůžeme dovolit. Snapshot můžeme zajisté někam zkopírovat a už v neživém stavu na něj udělat qemu-nbd -c a potom s ním pracovat už read-write. Když ale nepracujeme se soubory ale s LVM svazky, je to trochu nepraktické. A při tom právě při práci s LVM svazky, protože tam máme LVM 2, můžeme v poklidu použít LVM snapshoty. Má to samé výhody a nenapadla mě žádná nevýhoda. Takže to máme
    lvcreate --size 20g --snapshot --name debil.snap /dev/VIRTUALY/debil
    a po odzálohování zase
    lvremove VIRTUALY/debil.snap
    a to je všecko. Při testování jsem nezaregistroval žádný problém. Se živým LVM 2 snapshotem se dá klidně zacházet read-write a nic se tím nezkazí. Můžeme klidně i fsck, když na to máme náladu. Nebo to není potřeba, protože i samotný read-write mount si u některých filesystémů dokáže udělat recovery a to stačí. Tohle chování jsem pozoroval u ext3. Mount -r při intenzívním diskovém provozu na hostu většinou nešel, read-write mount mi šel vždycky. Takže na zálohování budu používat LVM snapshoty a qemu snapshoty tady budou na řešení problémů, kdy si potřebujeme schovat i obsah operační paměti.

           

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    16.8.2013 12:52 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Zálohování KVM virtuálů
    Tyhle hrátky už mám dávno za sebou a věnoval jsem jim docela dost hodně času a úsilí čti. Jak si lze všimnout, k poslední části zatím nic napsáno není, takže jen ve zkratce:

    Poslední řešení je opravdu blbuvzdorné a ustálo bez ztráty kytičky i hodně ošklivé výpadky. Pro diskless řešení je v naší wiki samostateně zpracovaný manuál.
    20.8.2013 08:39 Pev | skóre: 28
    Rozbalit Rozbalit vše Re: Zálohování KVM virtuálů
    Díky za odkazy na zajímavé čtení :-).
    17.8.2013 10:14 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Zálohování KVM virtuálů
    A reminder why you should never mount guest disk images on the host OS - snad není potřeba další komentář...
    Dobrá finta u fdisku je volbička -u , údaje o oblastech jsou potom spolehlivě v 512 B sektorech.
    platí u starších fdisků jako je ten v RHEL6, u novějších (IIRC rok a půl starých a novějších) už -u naopak zapíná kompatibilitu s DOSem.

    Ad pády - nainstalit debug balíčky, zapnout coredumpy, vytáhnout backtrace a do bugzilly s tím!

    Jinak podle libvirtích vývojářů bylo na první implementaci živých snapshotů znát, že byly spíchnuty horkou jehlou pro potřebu oVirta - třeba proto, že neuměly pracovat s trvalými doménami. :) Jinak v nadcházející verzi oVirtu by už živé snapshoty neměly být ochuzeny o RAM - viz.
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.