Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 3

3.1.2015 14:30 | Přečteno: 1782× | Linux | | poslední úprava: 1.1.2015 14:34

Po po předvčerejším a včerejším díle následuje zakončení: Systemd a řízení zdrojů – KVM hosté a systemd-user – Squid proxy pro Pacmana – Transmission.

Maboroshi v3

Když nejde mít reálně grafiku v systému virtualizovaném, tak nezbývá než ji mít v systému virtualizujícím. Server od desktopu tak sice nebude tak čistě oddělen, ale co už…

KDE, systemd, cgroups a řízení zdrojů

No, a když už se dává desktop na takové nadupané železo, tak tam dáme v rámci sjednocení domácího prostředí rovnou KDEčka. Aby ale desktop příliš neomezoval virtualizovaný server, chtělo by to ho nějak omezit, ale jak? Máme přece ten systemd… Jeden jim všem vládne… pomocí cgroups.

O tom, jak to udělat, se rozepisuje sám ten, jehož jméno se nevyslovuje. Všechny procesy jednoho uživatele jsou zařazovány do jedné skupiny, z hlediska systemd jsou pak reprezentovány jako user-UID.slice. Tomu pak lze přiřadit limit využití paměti, nebo něčeho jiného:

# z ruky
systemctl set-property user-1000.slice MemoryLimit=2G

# nebo konfigurákem
#/etc/systemd/system/user-1000.slice.d/50-MemoryLimit.conf
[Slice]
MemoryLimit=2147483648
				

Za předpokladu, že na systému nebude naráz pracovat více uživatelů, což nebude, by to mělo rozumně fungovat. Jak to zrovna se zdroji vypadá, ukáže nástroj systemd-cgtop.

KVM hosté a systemd-user

Aby bylo funkci tohoto zápisku coby externí paměti učiněno zadost přidávám ještě službu, která spustí server Makoto:

#/home/qemu-makoto/.config/systemd/user/qemu-makoto.service 
[Unit]
Description=QEMU virtual makoto

[Service]
ExecStart=/usr/bin/env qemu-system-x86_64 -name makoto \
        -enable-kvm -m 4096 -cpu host -smp 2 -nographic \
        -device virtio-net-pci,netdev=net2,mac=52:54:00:12:34:01 \
        -netdev type=tap,id=net2,ifname=tap0,script=no,downscript=no \
        -drive file=/dev/maboroshi_ssd_lvm/makoto,index=0,media=disk,if=virtio \
        -drive file=/dev/sda,index=1,media=disk,if=virtio \
        -virtfs local,id=p9fs1,path=%h/boot,security_model=mapped,mount_tag=makoto_9p_boot \
        -monitor unix:%h/kvm-makoto.sock,server,nowait \
        -kernel "%h/boot/vmlinuz-linux" -initrd "%h/boot/initramfs-linux.img" \
        -append "root=/dev/disk/by-label/makoto_ssd_btrfs rootflags=subvol=makoto_root rw quiet systemd.unit=multi-user.target" 
ExecStop=/usr/bin/bash -c "/usr/bin/echo 'system_powerdown' | /usr/bin/nc -U %h/kvm-makoto.sock"
TimeoutStopSec=30
KillMode=none

[Install]
WantedBy=default.target
        #-drive media=cdrom,file=%h/archlinux-2014.09.03-dual.iso,readonly,index=1 \
				

A dodávám hlasitou mentální poznámku: Pozor na zakomentované řádky končící zpětným lomítkem! Mrcha se nepochopitelně interpretovala a v pozici před ExecStop způsobila, že se toto „záhadně“ nevykonávalo.

Makoto

Současná podoba Makoto je pouze holý systém a zmigrované dosud používané služby. Oproti původnímu záměru jsem CUPS hodil na Maboroshi, protože závislosti na X11. Na zatím nedůležitá data jsem zneužil kupodivu stále fungující SATA disk z prvního stolního počítače z roku 2004.

Squid proxy pro Pacmana

Toto jsem objevil, když jsem řešil zdlouhavou aktualizaci několika stejných Arších strojů na pomalé ADSL, pak jsem to nasadil i doma, i když tam je ADSL rychlejší. Popis na Arch Wiki, zde jen stručně:

pacman -S squid

# /etc/fstab
LABEL=makoto_hdd_btrfs  /mnt/proxy    btrfs     rw,noatime,space_cache,subvol=makoto_proxy      0 0

# /etc/systemd/system/squid.service.d/customization.conf 
[Unit]
RequiresMountsFor=/mnt/proxy

# /etc/squid/squid.conf
maximum_object_size 512 MB
cache_dir aufs /mnt/proxy 4096 16 256
shutdown_lifetime 1 seconds 

refresh_pattern \.pkg\.tar\.   0       20%     4320      reload-into-ims
refresh_pattern .              0       0%      0
					

Na straně klientů jsem pak nastavil aliasy:

# ~/.bashrc
alias yaourt="http_proxy='http://makoto:3128' yaourt"
alias pacman="http_proxy='http://makoto:3128' pacman"
					

A pro funkčnost pro uživatele využívajícího sudo:

# /etc/sudoers
Defaults env_keep += "http_proxy"
					

Transmission

I toto je rozumně popsané na Arch Wiki. Oproti ad-hoc slepenci na Kanashimi jsem zvolil provoz pod uživatelem transmission – konfigurace je pak ve /var/lib/transmission/, opět jen stručně:

# .config/transmission-daemon/settings.json
    "download-dir": "/mnt/torrent", 
    "incomplete-dir": "/mnt/torrent/incomplete", 
    "rpc-whitelist": "127.0.0.1,192.168.1.*",
    "umask": 23, #osmičková umask, obzvláště výživné

# /etc/fstab
LABEL=makoto_hdd_btrfs  /mnt/torrent  btrfs     rw,noatime,space_cache,subvol=makoto_torrent    0 0

# /etc/systemd/system/transmission.service.d/customization.conf 
[Unit]
Requires=network.target
RequiresMountsFor=/mnt/torrent

# aby se uživatel dostal ke staženým Linuxovým distribucím:
usermod -aG transmission nik
					

Šikovné je pak ovládání z řádky:

transmission-remote makoto -a "oblíbená-distribuce.torrent"

Závěr

Že bude fáze 1 nasazení domácího servříku trvat hrubého času 3 měsíce, jsem tedy nečekal. Čistá bilance by vypadala lépe, neb jsem se tomu krom Vánoc věnoval většinou jen jedno odpoledne týdně. Zas jsem si vyzkoušel pár zajímavých věcí, a ač to teda nedopadlo přesně podle mých představ, tak lze fázi 1 označit za úspěšně dokončenou.

Shrnuto: systemd potěšil (systemd-user, aktivace služeb na vyžádání, úprava existujících unit a řízení zdrojů), KVM s grafikou spíše zklamalo (zajímalo by mě, zda je to jen danou HW+SW konfigurací, nebo zda je to s grafikou v KVM hostech, vždy takto tragické), btrfs fajn, ale pro KVM vadí, že pododdíly nejsou bloková zařízení. Asi by se tomu dalo vyhnout, kdyby KVM hosti měli vlastní souborový systém, tam pak nevadilo přidat právo přes skupinu.

Asi budu pokračovat fází 1.5, kde ještě doladím využití btrfs – nějaké ty pravidelné snapshoty a snapshoty při aktualizaci systému.

PS Přístě si dělám zápisky průběžně.

       

Komentáře

[mimi.vx]

děláš to vše zbytečně složitě ....

[Nicky726]

V čem konkrétně?

[qqq]

Hlavně přestaň tapetovat. Seš horší než Jílek.

[pavlix]

Nebylo by lepší vyndat hlavu z řiti a jít se věnovat Jílkovi než obtěžovat u technicky zaměřených blogů?

[mimi.vx]

existence libvirt. Spoustu veci by ti ulehcila, dale bych zvazil pouziti dockeru ci systemd-nspawn

[Nicky726]

O libvirt vím, ale nechtěl jsem. Ten nspawn vypadá pro situaci, do které jsem se dopracoval, zajímavě.

[Aleš Kapica]

Klid. Nenech se tím rozhodit. Moje řešení rovněž nepoužívá libvirt.

Je ovšem pravda, že děláš hodně věcí složitě, ale to se dá pochopit, pokud se s tím teprve seznamuješ. Osobně mi přijde zajímavé, že se to pokoušíš řešit přes systemd. Na druhou stranu, řešit síťování přes bridge, když je k dispozici openvswitch, mi přijde poněkud humpolácké a nepružné.

[pavlix]

řešit síťování přes bridge, když je k dispozici openvswitch, mi přijde poněkud humpolácké a nepružné.

Jakou výhodu tedy poskytne openvswitch? Klasický bridge je v linuxu nativní nástroj, který se dá skládat s ledasčím.

[Aleš Kapica]

Jen tak letmo:

- Dynamické vytváření portů pro virtuální stroje

- Operativní práci s konfigurací vlan, aniž by si tím odstřelil hlavní konektivitu

- Vytváření interních sítí, tunelovaných na jiné virtuální switche, aj.

Jednou nastavený openvswitch znamená - alespoň pro mne - vyřešené problémy s konektivitou. Kupř. při blbnutí s testovacím sedmi nodovým clusterem, jsem měl nastavenou mimo hlavní síťovou konfiguraci paralelní servisní interní síť, takže když náhodou někde něco při konfiguraci neklaplo, stroj nezůstal nedostupný a mohl jsem to ihned opravit. A to vše na jednom fyzickém interface z každého stroje.

[pavlix]

Dynamické vytváření portů pro virtuální stroje

Operativní práci s konfigurací vlan, aniž by si tím odstřelil hlavní konektivitu

Vytváření interních sítí

tunelovaných na jiné virtuální switche

Máme tu čtyři různé body. Ani u jednoho nevím, proč by to nešlo se stávající kernelovou infrastrukturou.

Jednou nastavený openvswitch znamená - alespoň pro mne - vyřešené problémy s konektivitou.

To chápu. Stejně jako jakýkoli jiný vyhovující nástroj nebo sada nástrojů, která jde nakonfigurovat a dále používat.

[Aleš Kapica]

Máme tu čtyři různé body. Ani u jednoho nevím, proč by to nešlo se stávající kernelovou infrastrukturou.

Však já nikde nepsal, že to nejde řešit i jinak. Dotaz byl: "Jakou výhodu tedy poskytne openvswitch?"

[pavlix]

Dotaz byl: "Jakou výhodu tedy poskytne openvswitch?"

Obávám se, že to jsem se zatím nedozvěděl. Ale je klidně možné, že mi odpověď může nabídnout jenom člověk zkušený v řešení s openvswitch i bez něj a takoví se asi těžko hledají.

[Aleš Kapica]

Obávám se, že se svým přístupem se uspokojivé odpovědi nedočkáš. O tom co je výhoda, má totiž každý svou vlastní představu. Já volím technologie pokud možno tak, aby jejich použití bylo výhodné pro dané použití. Tzn. že co může být výhodné pro mne, nemusí být výhodné pro někoho jiného. Na druhou stranu nasazení openvswitche usnadňuje především změny do budoucna. Klasické řešení, s využitím vlan a bridgů, takovou pružnost nenabízí.

[pavlix]

Obávám se, že se svým přístupem se uspokojivé odpovědi nedočkáš.

S možností, že se odpovědi nedočkám, celkem počítám, ale nevím, co jsem ti udělal tak zlého, že máš potřebu to svádět na můj přístup.

Na druhou stranu nasazení openvswitche usnadňuje především změny do budoucna. Klasické řešení, s využitím vlan a bridgů, takovou pružnost nenabízí.

Jenže to jsou stále jenom prázdné kecy jak z marketingového oddělení. Pokud se nedozvím alespoň jednu konkrétní věc a u ní konkrétní výhody, diskuze brzy ztratí smysl.

[Aleš Kapica]

Tvůj přístup je především vadný v tom, že nejsi schopen akceptovat, že jiní uživatelé mají jiné potřeby než ty. Pokud by tě zajímalo řešení nějaké konkrétní věci, tak bys především musel nejprve nastínit jak ji máš řešenou ty - tak jako to učinil autor tohoto blogpostu.

[pavlix]

nejsi schopen akceptovat, že jiní uživatelé mají jiné potřeby než ty.

Obávám se, že jsi si zde jen nastavil zrcadlo. Pokud vím, tak jsi to byl ty, kdo shazoval jedno ze dvou možných řešení, takže asi nedává smysl abys z výše uvedeného obviňoval kohokoli jiného než sebe.

Pokud by tě zajímalo řešení nějaké konkrétní věci, tak bys především musel nejprve nastínit jak ji máš řešenou ty

Nesmysl. Ty jsi prezentoval jedno řešení jako špatné a druhé jako dobré. Je tedy na tobě, abys to buď obhájil nebo nechal neobhájené. Jestli ti můžu poradit, tak je mnohem čistší přiznat, že ve skutečnosti nevíš, říct, že to asi neumíš vysvětlit, nebo se jednoduše vymluvit, že na to teď nemáš čas. Ale klidně si můžeš vycucat z prstu nějaký výrok shazující tazatele, pokud ti to dělá dobře.

[trekker.dk]

Obávám se, že problém je spíš v tom, že se pavlix ptal na výhody openvswitch oproti infrastruktuře v jádře, a jako odpověď dostal seznam věcí, které ta jaderná infrastruktra nabízí (tudíž ty věci nelze považovat za výhody.) Tím neříkám, že openvswitch je špatný, ale z popisů, které jsem viděl (většinou ve vašem blogu) mi spíš než co jiného přijde jako nástroj usnadňující nastavení a správu ostatních jaderných komponent.

[pavlix]

+1

Samozřejmě z pohledu uživatele lze za validní výhody označit i ty, které se jádra netýkají, ale je potřeba to rozlišit a je potřeba ty výhody nějak jasně definovat, pokud to nemá být jenom chvalozpěv.

[Aleš Kapica]

Openvswitch je v jádře, tudíž nejde o nástroj ke konfiguraci jiných komponent, nýbrž o komponentu, která je nahrazuje.

[trekker.dk]

No v tom odkazu níž píšou něco o tom, že se snažili použít co nejvíc existující infrastruktury, takže bych hádal, že s tím nahrazením to nebude tak žhavé. Ostatně když koukám na obrázky na jejich webu, tak je to tam samé VM - tap0 - br0, tedy přesně ten bridge, který jste nahoře zkritizoval jako humpolácké řešení.

Zkusil jsem projít jejich web, článek na LWN, ale nenašel jsem nic, o čem bych si řekl "jo, to by se hodilo". To, co obsahuje sekce "features", je v podstatě výčet věcí, které v jádře byly už před open vSwitch. Uznávám, jako konfigurační nástroj to vypadá pěkně, na první pohled o něco jednoduššeji než manipulace s jednotlivými komponentami přímo. Ale jiný přínos tam moc vidět není.

[Aleš Kapica]

Nejsem vývojářem Openvswitche, pouze uživatel a zaobíral jsem se jím jen do té míry abych mohl zdokumentovat svoje řešení. Takže k tomu mohu jen říct že názvy použité v dokumentaci jsou volené tak aby co nejvíc usnadnily pochopení jak to funguje a co nahrazuje. Tap zařízení se používá naprosto běžně i u jiných řešení - např. u vde2 switche který ovšem jinak běží v userspace. Já jsem jím nahradil zmíněný vde2 switch, a jaderné moduly pro vytvoření bridge a separaci vlan. Mimochodem, podobné řešení na bázi Openvswitche, jak jsem s překvapením zjistil, používá pro síťování i Citrix Xen server.

[trekker.dk]

Takže k tomu mohu jen říct že názvy použité v dokumentaci jsou volené tak aby co nejvíc usnadnily pochopení jak to funguje a co nahrazuje.

Takže chcete říct, že když na hostiteli, kde se tohle používá, pustíte brctl show, tak to nic neukáže?

Já jsem jím nahradil ... jaderné moduly pro vytvoření bridge a separaci vlan.

To je právě to, o čem dost pochybuju. Připouštím, že před vámi openvswitch může zkoušet leccos schovat, ale opravdu se mi nezdá, že by vývojářům při začlenění do jádra prošla duplikace kódu jak pro ten bridge, tak pro vlany.

Mimochodem, podobné řešení na bázi Openvswitche, jak jsem s překvapením zjistil, používá pro síťování i Citrix Xen server.

No nevím jak Citrix Xen server, ale normální server s Xenem se taky bude tvářit, že síť je hogofogo cosi, načež se ukáže, že síťovka peth0 je přejmenované eth0 a eth0 je bridge, který se nejmenuje br0.

[pavlix]

Nešlapej mu po jeho modlách, vždyť vidíš, jak je z toho nešťastný.

[trekker.dk]

No já bych se rád dobral toho, jak ten openvswitch funguje, co přesně dělá a jestli má cenu, abych tomu věnoval pozornost (tj. jestli mi použití něco přinese.) Jestli vás to nezajímá, tak si klidně rýpejte, ale mě do toho netahejte.

[pavlix]

To chápu, ale já vím jenom málo a z Aleše těžko dostaneš nějaké technické detaily. Co vím, tak do jisté míry využívá stávající moduly, slyšel jsem hlavně o bondingu, nevím, jak moc se to týká vlan a bridge, nicméně se to neprojevuje navenek. Ten návrh je takový víc monolitický, že openvswitch je vlastně kernel i userspace, ne jako jednotlivé moduly v kernelu, poskládané pomocí userspace nástroje. Zatím pro mě nebyl dost zajímavý, abych ho zkoumal blíže. Uvažoval jsem o tom jenom kdyby se mi chtělo hledat výnosnější zaměstnání, protože buzzword, ale to byly skutečně jen úvahy.

[Aleš Kapica]

Stroj snoopy je jeden z nejstarších strojů mého clusteru, které ještě mají původní síťovou konfiguraci bez openvswitche. Což je bohužel jediná příčina, proč tyto stroje nemohou současně fungovat i jako virtualizační. Původně se na nich pro tento účel využívaly vde2 switche - viz KVM (networking) v naší wiki

snoopy (DATASERVER) :~# lsmod | grep -E '(bridge|8021q)'
8021q                  23895  0 
garp                   13148  1 8021q
mrp                    13325  1 8021q
bridge                 81844  0 
stp                    12437  2 garp,bridge
llc                    12783  3 stp,garp,bridge
snoopy (DATASERVER) :~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.4061868d10df       no              eth0
br17            8000.4061868d10de       no              vlan17
br202           8000.4061868d10de       no              vlan202
br223           8000.4061868d10de       no              vlan223
br226           8000.4061868d10de       no              vlan226
br5             8000.4061868d10de       no              vlan5

Infrastruktura strojů lucy a patty již využívá openvswitch. Každý z nich může fungovat jak datový stroj, tak virtualizační, proto pro rálnou představu v následujícím výpisu uvádím výpis konfigurace openvswitche pro oba stroje

patty (DATASERVER) :~# lsmod | grep -E '(bridge|8021q)'
patty (DATASERVER) :~# brctl show
bridge name     bridge id               STP enabled     interfaces
patty (DATASERVER) :~# ovs-vsctl show
458eb0ea-1825-40de-8e3b-028ea61c0faf
    Bridge main
        Port "main5"
            tag: 5
            Interface "main5"
                type: internal
        Port "nfs-k328"
            tag: 54
            Interface "nfs-k328"
                type: internal
        Port main
            Interface main
                type: internal
        Port "main-aa4cc-5"
            tag: 5
            Interface "main-aa4cc-5"
        Port "nfs-k23"
            tag: 223
            Interface "nfs-k23"
                type: internal
        Port "nfs-k2"
            tag: 202
            Interface "nfs-k2"
                type: internal
        Port "nfs-k26"
            tag: 226
            Interface "nfs-k26"
                type: internal
        Port "eth2"
            trunks: [1, 4, 5, 17, 54, 202, 223, 226]
            Interface "eth2"
        Port "nfs-k9"
            tag: 17
            Interface "nfs-k9"
                type: internal
    Bridge interni
        Port interni
            Interface interni
                type: internal
        Port "eth3"
            Interface "eth3"
        Port "interni-aa4cc"
            Interface "interni-aa4cc"
    ovs_version: "2.1.0"
patty (DATASERVER) :~# ip tuntap
patty (DATASERVER) :~# 

Jak je z výpisu zřejmé, bridge se nemusí nutně jmenovat br.. a jak je zřejmé z předchozího výpisu, port nemusí být nutně připojen na tap zařízení.

lucy (DATASERVER) :~# ovs-vsctl show
c66d1285-ef67-4c03-9bca-57e387bb0ff1
    Bridge main
        Port "nfs-k328"
            tag: 54
            Interface "nfs-k328"
                type: internal
        Port "main-samba-4"
            tag: 4
            Interface "main-samba-4"
        Port "nfs-k2"
            tag: 202
            Interface "nfs-k2"
                type: internal
        Port "main-poste-17"
            tag: 17
            Interface "main-poste-17"
        Port "main-media-1"
            tag: 1
            Interface "main-media-1"
        Port "main-k2-223"
            tag: 223
            Interface "main-k2-223"
        Port "main-redmi-5"
            tag: 5
            Interface "main-redmi-5"
        Port main
            Interface main
                type: internal
        Port "main-k2-226"
            tag: 226
            Interface "main-k2-226"
        Port "nfs-k23"
            tag: 223
            Interface "nfs-k23"
                type: internal
        Port "main-k2-54"
            tag: 54
            Interface "main-k2-54"
        Port "nfs-k26"
            tag: 226
            Interface "nfs-k26"
                type: internal
        Port "main-suppo-1"
            tag: 1
            Interface "main-suppo-1"
        Port "nfs-k9"
            tag: 17
            Interface "nfs-k9"
                type: internal
        Port "main-k2-1"
            tag: 1
            Interface "main-k2-1"
        Port "main-boura-54"
            tag: 54
            Interface "main-boura-54"
        Port "main5"
            tag: 5
            Interface "main5"
                type: internal
        Port "main-x32bi-4"
            tag: 4
            Interface "main-x32bi-4"
        Port "main-moodl-1"
            tag: 1
            Interface "main-moodl-1"
        Port "main-git-1"
            tag: 1
            Interface "main-git-1"
        Port "main-k2-202"
            tag: 202
            Interface "main-k2-202"
        Port "main-mapse-5"
            tag: 5
            Interface "main-mapse-5"
        Port "main-felk--5"
            tag: 5
            Interface "main-felk--5"
        Port "main-drupa-1"
            tag: 1
            Interface "main-drupa-1"
        Port "main-poste-5"
            tag: 5
            Interface "main-poste-5"
        Port "eth2"
            trunks: [1, 4, 5, 17, 54, 202, 223, 226]
            Interface "eth2"
        Port "main-k2-17"
            tag: 17
            Interface "main-k2-17"
        Port "main-build-5"
            tag: 5
            Interface "main-build-5"
        Port "main-aa4cc-5"
            tag: 5
            Interface "main-aa4cc-5"
        Port "main-k2-5"
            tag: 5
            Interface "main-k2-5"
    Bridge interni
        Port "interni-x32bi"
            Interface "interni-x32bi"
        Port interni-drupa
            Interface interni-drupa
        Port interni-moodl
            Interface interni-moodl
        Port interni
            Interface interni
                type: internal
        Port interni-build
            Interface interni-build
        Port interni-git
            Interface interni-git
        Port interni-suppo
            Interface interni-suppo
        Port interni-redmi
            Interface interni-redmi
        Port interni-felk-
            Interface interni-felk-
        Port "eth3"
            Interface "eth3"
        Port interni-mapse
            Interface interni-mapse
        Port interni-samba
            Interface interni-samba
        Port "interni-aa4cc"
            Interface "interni-aa4cc"
        Port "interni-k2"
            Interface "interni-k2"
    ovs_version: "2.1.0"
lucy (DATASERVER) :~# ip tuntap
main-poste-5: tap vnet_hdr
main-build-5: tap vnet_hdr
main-k2-17: tap vnet_hdr
main-k2-54: tap vnet_hdr
main-git-1: tap vnet_hdr
interni-git: tap vnet_hdr
interni-k2: tap vnet_hdr
main-moodl-1: tap vnet_hdr
main-aa4cc-5: tap vnet_hdr
main-suppo-1: tap vnet_hdr
main-k2-1: tap vnet_hdr
main-k2-5: tap vnet_hdr
main-poste-17: tap vnet_hdr
main-felk--5: tap vnet_hdr
main-mapse-5: tap vnet_hdr
main-x32bi-4: tap vnet_hdr
main-drupa-1: tap vnet_hdr
main-k2-226: tap vnet_hdr
main-k2-223: tap vnet_hdr
main-k2-202: tap vnet_hdr
main-samba-4: tap vnet_hdr
interni-suppo: tap vnet_hdr
interni-aa4cc: tap vnet_hdr
interni-build: tap vnet_hdr
interni-drupa: tap vnet_hdr
interni-felk-: tap vnet_hdr
interni-mapse: tap vnet_hdr
interni-moodl: tap vnet_hdr
interni-redmi: tap vnet_hdr
interni-samba: tap vnet_hdr
interni-x32bi: tap vnet_hdr
main-redmi-5: tap vnet_hdr

Jak snad jistě i pavlix uzná, spravovat něco podobného klasicky přes /etc/network/interfaces by bylo poněkud vražedné.

[trekker.dk]

Infrastruktura strojů lucy a patty již využívá openvswitch. Každý z nich může fungovat jak datový stroj, tak virtualizační, proto pro rálnou představu v následujícím výpisu uvádím výpis konfigurace openvswitche pro oba stroje

Ok, žádné kernelové bridge, které by se tak hlásily.

Už jsem to psal, fakt se mi nezdá, že by vývojářům openvswitch prošla tak velká duplikace kódu, jakou by bezesporu byla reimplementace bridge. Bezesporu píšu, protože linuxový bridge se v rámci jednoho hostitele chová jako switch - spravuje si porty, ať už fyzické či virtuální síťovky, drží se seznam MAC adres na jednotlivých portech apod. Furt mám zato, že využívají stejný kód.

Jak snad jistě i pavlix uzná, spravovat něco podobného klasicky přes /etc/network/interfaces by bylo poněkud vražedné.

Tak to uzná asi každý, kdo používá zdravý rozum. Pokud člověk potřebuje víc než "síťovce xyz nastav adresu a.b.c.d/e a k tomu bránu a.s.d.f", je práce s tímhle souborem - zejména strojové zpracování - totální katastrofa. Už jsem se několikrát podivoval, že se v Debianu nikdo neobtěžoval tenhle otřes předělat. Rejp, asi neměli čas, protože se věnovali mnohem důležitějšímu a potřebnějšímu systemd.

Na druhou stranu když odhlédnu od jednodušší konfigurace, tak mi pořád uniká, v čem má openvswitch výhodu nad použitím bridge. U našich virtualizačních strojů je síť řešená tak, že co virtuál, to tap síťovka, všechny jsou spojené do bridge společně s fyzickým ethernet rozhraním, které je připojené do internetu. VLANy se tam nepoužívají, ale kdyby to bylo potřeba, tak na hostiteli stačí pro každou VLAN vytvořit samostatný bridge, do toho nacpat tap rozhraní jenom těch virtuálů, které do ní mají být zapojené, a do fyzické sítě to zapojit přes fyzické něco jako eth0.10 (ip link add link eth0 name eth0.10 type vlan id 10). Live migrace mezi hostiteli není problém - co jsem si všiml, tak se qemu postará o aktualizaci ARP tabulek bez nějakého dalšího snažení a pak už mě nenapadá nic, co by se ještě mohlo hodit.

Zajímavější by to bylo, kdybych chtěl vytvořit něco jako distribuovaný switch, do kterého by byly zapojené virtuály přes několik hostitelů, ale jejich provoz by nebyl vidět na fyzické síti. Nicméně i to by asi nějak šlo buď přes separátní vlan, nebo nějakým (gre?) tunelem, tj. furt nic, co by bez openvswitch nešlo.

---

Jen tak mimochodem, nakoukl jsem na tu wiki stránku networking a trochu mě zaujalo/zmátlo opakované povídání o té KVM vlan. Pak jsem to dohledal v dokumentaci a pokud to dobře chápu, tak když místo net-net použijete netdev-device, nemusíte žádné vlan=x řešit.

[Aleš Kapica]

Už jsem to tady několikrát zmiňoval - to jsou ty z Pavlixova pohledu nic neříkající kecy - že moje pro moje virtuály se zakládají a ruší porty na virtuálním Openvswitchi podle potřeby. Proto mi vyhovuje, že konfigurace v /etc/network/interfaces řeší pouze základní nastavení fyzických rozhraní. O všechno ostatní se mi stará Pacemaker a fakt to poslední co potřebuji je nějaký network manažer, který mi v tom svou autodetekcí bude dělat bordel. Ta základní síťová konfigurace slouží pouze k tomu, aby se byl schopen stroj domluvit s ostatními nody v clusteru. Asi by to bylo zřejmé kdybych sem nakopíroval i jejich obsah, ale nemusí zase naše interní ip viset všude.

Co se týče toho, jak to je uvnitř Openvswitche tak soudím, že bezpochyby využívá kódu zmíněných modulů, ale k tomu je přeci nepotřebuje mít samostaně zavedené. Je to zcela identická situace jako u Btrfs, které také používá kusy kódu z md raidu, ale funguje trochu jinak.

[pavlix]

fakt to poslední co potřebuji je nějaký network manažer,

A proto máš openvswitch :).

[Aleš Kapica]

Překvapuje mne, že zrovna ty nechápeš rozdíl mezi switchem a konfigurátorem síťových zařízení.

[pavlix]

Pobavilo.

[trekker.dk]

Už jsem to tady několikrát zmiňoval - to jsou ty z Pavlixova pohledu nic neříkající kecy - že moje pro moje virtuály se zakládají a ruší porty na virtuálním Openvswitchi podle potřeby.

Teď si nejsem jistý, jestli je to odpověď na tu výhodu oproti bridge. Ale jestli jo, tak to přece bridge umí taky:

tunctl -t tapx
ip link set tapx up
brctl addif brx tapx

brctl delif brx tapx
ip link set tapx down
tunctl -d tapx

Co se týče toho, jak to je uvnitř Openvswitche tak soudím, že bezpochyby využívá kódu zmíněných modulů, ale k tomu je přeci nepotřebuje mít samostaně zavedené.

Tak jasně že ne, ale pak je otázka, jak moc přesné je tvrzení "nepoužívám linuxový bridge", když tu použitou funkcionalitu v openvswitch interně zajišťuje stejný kód.

[Aleš Kapica]

Tak jasně že ne, ale pak je otázka, jak moc přesné je tvrzení "nepoužívám linuxový bridge", když tu použitou funkcionalitu v openvswitch interně zajišťuje stejný kód.

Tak tady už se dostáváme k onomu klasickému "já o voze, on o koze". Pokud napíšu, že nepoužívám bridge, tak tím mám na mysli, že nemám zavedený jaderný modul bridge a nevyskytuje se mi ani v konfiguraci /etc/network/interfaces. Zda-li s ním má Openvswitch něco společného z hlediska kódu je pro mne naprosto nezajímavá informace. Nevylučuji tím, že pro někoho jiného může "použití" znamenat i využití určité části kódu.

..to přece bridge umí taky

Jenže tohle vytvoření tap zařízení a jeho zapojení do bridge je pouze jedna, relativně marginální část o kterou se Openvswitch vůbec nestará. Tohle mi řeší skript který si při spouštění volá qemu. Openvswitch je virtuální switch se vším všudy, který umožňuje stejné opičky jako fyzické zařízení. Z jedné strany, přes fyzický interface mi do něj leze trunk a VLAN se nastavují až při zavedení portu, předtím, než se na něj připojí tap interface virtuálního stroje.

Můžu tak bez problému v rámci clusteru přesunout virtuály na libovolný stroj, na kterém musí běžet pouze openvswitch. V podstatě by to může být i bezdiskový stroj s výkoným CPU a dostatkem RAM a , bez ohledu na to co dalšího je na něm z hlediska sítě nakonfigurované. Můžu dělat i zcela izolované vnitřní sítě. Škrtit porty dle libosti, aj.

[pavlix]

Popravdě řečeno jsem před časem testoval přesuny s klasickým linuxovým bridgem. Proto jsem se taky v diskuzi ptal na konkrétní výhody, ale už jsem celkem smířený s tím, že se o tom budu muset pobavit s někým jiným. A koncem měsíce budu mít i příležitost ;).

[Aleš Kapica]

Hodně štěstí! Pro Maxe bylo rychlejší zabrousit na Karlovo náměstí.

[pavlix]

Tak já zabrousím do Bruselu, no :).

[Aleš Kapica]

Pohádka na cestu.

[trekker.dk]

Nevylučuji tím, že pro někoho jiného může "použití" znamenat i využití určité části kódu.

Tady je tenhle pohled důležitý proto, že tam, kde se používá stejný kód, je stejná i poskytovaná funkcionalita.

Openvswitch je virtuální switch se vším všudy, který umožňuje stejné opičky jako fyzické zařízení.

Jenže to infrastruktra v kernelu (myslím bez openvswitch) taky. Jaderný bridge zastává stejnou funkctionalitu jako switch. Sasmozřejmě různá fyzická zařízení mají různé schopnosti, ale...

Z jedné strany, přes fyzický interface mi do něj leze trunk a VLAN se nastavují až při zavedení portu, předtím, než se na něj připojí tap interface virtuálního stroje.

...tohle umí jaderná infrastruktura taky. Fyzická síťovka se rozdělí na virtuální podle VLAN ID (ip link add výše), ty virtuální se pak vloží jako port do bridge (jeden bridge pro každou VLAN). Když se pak vytvoří tap zařízení, přidá se do bridge podle toho, ve které VLAN ten virtuál má být.

Můžu tak bez problému v rámci clusteru přesunout virtuály na libovolný stroj

To také jde bez openvswitch. Před spuštěním virtuálu se vytvoří tap zařízení, osadí se do bridge, pak se ten virtuál (qemu proces) spustí a začne se na něj migrovat. Výpadek konektivity toho virtuálu po dokončení migrace je minimální (v podstatě čím větší provoz, tím menší.)

Můžu dělat i zcela izolované vnitřní sítě.

Taktéž jde bez openvswitch - bridge v rámci jednoho hostitele, tap zařízení jako porty pro jednotlivé virtuály, propojení mezi hostiteli třeba pomocí tunelu (tuším GRE), přičemž gre rozhraní také zapojím do toho bridge. Na ostatních hostitelích, jejichž virtuály mají být do té izolované sítě také zapojeny, udělám to samé a o předávání rámců mezi hostiteli - když je to potřeba - se už postarají kernely obou hostitelských strojů

Škrtit porty dle libosti

Taky - stačí pro daný port nastavit traffic shaper v jádře. Tohle všechno jde samozřejmě nastavit za běhu, aniž bych to musel mít v interfaces.

Jinak nevykládejte si to tak, že bych vás chtěl přesvědčovat, že openvswitch nemáte používat. Spíš by ale bylo dobré mít na paměti, že - podle toho, co jste zatím popsal - vám jako jedinou přidanou hodnotu poskytuje zjednodušení konfigurace (jeden příkaz místo hodně příkazů.) A že to tedy není žádné zázračné řešení, které vám poskytuje něco navíc, co by kernel jinak neměl. A v neposlední řadě že není dobré označovat použití bridge jako "humpolácké řešení", když vlastně používáte totéž (stejný kód), akorát nakonfigurované jiným způsobem.

[Aleš Kapica]

Však já nikde neříkám, že to nejde. Pro mne je podstatné, že jsem to potřeboval udělat tak, abych mohl veškerou správu infrastruktury přenechat na Pacemakeru. A pro tento účel se ukázalo nejvýhodnější použít openvswitch. Pro cokoliv jiného bych musel psát nějaké vlastní obslužné skripty a na tohle fakt nemám čas. Pokud něco označím za "humpolácké" řešení, tak tím rozhodně nemám na mysli, že by to nebylo funkční. Ostatně, více viz

[SAM:]

A nebo třeba takto, je li libo LACP bonding. Kernelu není potřeba nic, z bridge, vlan, bond atd. Chová se to vlastně jako fyzické switch.

ares3 ~ # ovs-vsctl show
4de59ac4-58da-4f23-92d8-b7cf17c8eacb
    Bridge "ovsbr0"
        Port "ovsbr0"
            tag: 1
            Interface "ovsbr0"
                type: internal
        Port "vnet0"
            tag: 4
            Interface "vnet0"
        Port "bond0"
            Interface "eno1"
            Interface "eno2"

[trekker.dk]

Kernelu není potřeba nic, z bridge, vlan, bond atd.

Jak jsem psal o něco výš, nevěřím tomu - to by znamenalo veškerou funkcionalitu, která v jádře byla, znovu napsat. A taky by to znamenalo nějak přesvědčit vývojáře mainline, aby si při začleňování nevšimli toho, že openvswitch duplikuje funkcionalitu. Což si všimli - pokud dobře překládám, při zaslání k začlenění to duplikovalo mechanismus pro klasifikaci a řízení paketů - reimplementace bridge, vlan, bond atd. by asi pozornosti neunikla.

[pavlix]

Osobně jsem si vždycky myslel, že openvswitch prošel jen díky velkému tlaku z komerční sféry. Co jsem se bavil s kerneláři co do něj fušují, tak mimo záznam neměli problém říct, že je to z pohledu vývoje linuxu hrozná sračka. Pohled uživatele je samozřejmě od takových technických detailů značně odstíněný.

[Aleš Kapica]

Co jsem se bavil s kerneláři co do něj fušují, tak mimo záznam neměli problém říct, že je to z pohledu vývoje linuxu hrozná sračka.

To je možné. Já si to rovněž o některých věcech myslím a přesto je používám, protože jiná, lépe udělaná alternativa k dispozici není. Ale není reálné si všechno napsat sám. Krom toho, tohle je open source, takže ještě vcelku dobrý. Třeba se někdo najde, kdo to v budoucnu udělá lépe. Jenže když vidím čuňačiny, za které něž se některé firmy nestydí inkasovat nehorázné peníze, tak to bych teprv blil.

[pavlix]

Však jsem ti ani v nejmenším nevyčítal, že openvswitch používáš. Kdo jsem já, abych rozhodoval o tom, co mají profesionální admini používat. Sám jsem byl vždycky spíš experimentátor a posledních několik let se snažím adminování omezit jen na svoji vlastní nekritickou infrastrukturu.

[Aleš Kapica]

Vžyť nic neříkám. Jinak i když jsem to nijak explicitně nezmínil, tak není problém se k nám zastavit a případně si pohovořit o tom, jak některé veci řešíme. Konec konců jsme veřejná instituce. Mou hlavní parketou jsou stroje virtualizované v prostředí Pacemakeru. Síť a infrastrukturu kolem ní řeší můj kolega od vedlejšího stolu MarSarK.

[pavlix]

Ale jo, někdy určitě pohovoříme, to není úplně špatný nápad už jen proto, že se v diskuzích vídáme víc než dost, takže spojit si diskuzi s reálným ksichtem nemusí být úplně od věci. Konkrétně k openvswitch mě ale v první zajímá spíše takový méně uživatelský a více vývojářský pohled. Když už jsme u toho, nechystáš se na nějaký ze srazů?

[Aleš Kapica]

No na jednom nedávném srazu jsem se zastavil, ale účast nebyla nejhojnější, takže jsem překočoval do Šumavské kde jsem se měl sejít ještě s jedním kámošem. Obecně však srazy v restauračních zařízeních moc nemiluju. Sice se na nich lidé názorově sbližují, ale z praktického hlediska je to o ničem.

Dokud jsem byl ještě hlavně v OV (do r. 2008) tak jsme se občas sešli. I když oficiálně ty akce organizoval kolega Stopka - tehdy to byl ještě takový mladý tukan . Pak mu ale stouplo do hlavy, že začal dělat v korporačce a hodil na to bobek. Nicméně tvrdé jádro tvořené mými kolegy a kamarády se pak ještě občas sešlo v Narcisu. Teď během pobytu v OV jen tak tak stíháme obrazit dědečky a babičky, a jsem rád, když mi vyjde čas alespoň na to, abych se viděl s kámošem co mě na úřadě nahradil.

Mnohem lepší jsou akce typu LinuxAlt, Installfest nebo Linux Days, jenže ani na tohle moc času nezbývá.

[pavlix]

Tak si zkus naplánovat návštěvu InstallFestu, akorát budu potřebovat, abys mě tam odchytil a řekl mi, kdo jsi, protože toho asi jinak budu mít trochu moc.

[pavlix]

Teď mě napadá, je stále otevřený CFP a to včetně tracku o sítích, takže jestli ty nebo nějaký kolega něco máte, tak tím líp.

[VSi]

Umožňuje OVS realizovat víceúrovňový bonding? Kernelový bonding to totiž neumí, nebo aspoň mě to nefunguje. Mám 2 LACP trunky do 2 switchů, a nad nimi bych chtěl udělat active-failover bond. Alternativa je v druhé úrovni udělat bridge, ale linuxový umí jen obyčejné STP, kde jsou konvergenční časy dost nepříjemné. Jde to realizovat na OVS? A umí OVS RSTP/MSTP?

Nemá někdo zkušenost s používání OVS a DRBD zároveň? Od doby co je v XenServeru výchozí OVS, tak ho musím vypínat, protože jinak v kombinaci s DRBD dochází k zátuhům kernelu... http://openvswitch.org/pipermail/dev/2013-March/026334.html

[Aleš Kapica]

Tak pokud jde o DRBD, tak to se vždy snažím připojit zcela nezávisle na zbylé síťové infrastruktuře. I když na testovacím clusteru ho mám i nad openvswitchem. Ale pravda také je, že používám aktuální verze jak openvswitche (2.1), tak drbd (8.4).

[citanus]

http://openvswitch.org/support/dist-docs/WHY-OVS.md.txt

[Nicky726]

Díky, povědomí o openvswitch by se mohlo hodit pro nějaká větší nasazení.

[Max]

Zajímavé, možná mně něco podobného bude čekat, ale v širším měřítku.
Zdar Max

[Migi]

Pěkné, ale přijde mi to moc práce za málo muziky. Přijde mi to jako takové dítko vztahu Docker s OpenVZ.

[otmar]

Dobře, že ses tu objevil. Napiš a hoď sem prosím tě nějaký pořádný blogpost, nebo tu bude jenom dalších deset dílů těch ptákovin !

[Aleš Kapica]

Si zablokuj autora, pokud tě jeho blogy nebaví. A úplně nejlépe uděláš, když sám přispěješ vlastním hodnotným blogem místo blbých keců v diskuzi.

[gunar]

A ty by si nenapsal něco novýho ?

[Aleš Kapica]

Dělá se na tom.