Jak skamarádit openvswitch a systemd (diskuse)

[Peter]

Dakujem velmi pekne - práve také niečo riešim. Mimochodom - toho debila, čo "vymyslel v tom pridrbanom systemd tú nekonečnú smyčku" by som nechal umučiť tým najhrôzostrašnejším stredovekým spôsobom. Už sa mi nie raz stalo, že kvôly totálnej blbosti, absolútne nezaujímavej službe mi nenabehol systém a proste som musel chroot, ... Systemd je proste hnus fialový.

[pavlix]

Ty smyčky taky nechápu, většinou jsou to věci, které potřebuju nutně přeskočit a opravit z běžícího systému a CTRL+C nic!

[michich]

V systemd má každá služba nastavitelný timeout. LSB služby ho mají implicitně nastavený na 5 minut. V Debianu ale mají navíc patch, který službám z rcS.d nastavuje TimeoutSec=0, tj. nekonečný timeout.

[Aleš Kapica]

Otázka zní: Kde? Velmi bych uvítal možnost tuhle kravinu změnit.

[nyan]

No vida, stravils par hodin resenim problemu kterej by bez systemd neexistoval... a ja furt nechapu proc vsichni ten systemd nenavidi... dyt mame vsichni o praci postarano na dalsich par let

[Aleš Kapica]

Díváš se na to ze špatného konce. Díky řešení problému jsem se poučil jak má vypadat správně nakonfigurované síťové rozhraní openvswitche u Debianu. Učení není práce. Práce je aplikace učením získaných poznatků. Zaměstnání IT administrátora tvoří z 90% učení a pouhých 10% času zabírá vlastní práce.

[Jendа]

Mně zase systemd práci ušetřil. Například díky tomu, že na rozdíl od původního debianího initu umožňuje zakázat službu. Nestane se tak třeba, že se sám od sebe spustí DHCP server, který zahltí síť nefunkčními adresami.

[Heron]

Co? To samozřejmně Debian umí, to je docela podstatná vlastnost.

[Jendа]

Už se mi při upgrade zaply samba, ntpd a dnsmasq. Postinst skript prostě udělá /etc/init.d/služba restart a služba si to vyloží jako že se má spustit, i když neběží a byla zakázána (přes update-rc.d služba remove).

[pavlix]

To bych skoro viděl na bugreport, pokud se něco takového děje.

[pavlix]

Takže v čem přesně byl problém? Špatné pořadí služeb při bootu? Špatný obsah /etc/network/interfaces? Výslednou konfiguraci považuješ za korektní řešení nebo workaround?

[Aleš Kapica]

Výsledná konfigurace je vedlejší produkt hledání řešení jiného problému - povolení forwardingu pro virtuální interface. Z hlediska budoucí integrace systemd ji lze považovat za korektní řešení, protože s ním funguje. Více méně. Workaroundem je spíš ta původní konfigurace.

Jak řešit správným způsobem nastavení pořadí spouštění služeb při použití systemd je pro mne pochopitelně zajímavé téma - o tom, že momentálně nevím jak to správně udělat, se zmiňuji v následujícím blogpostu - Pacemaker - problém se integrací nodu. Bohužel, zatím jsem však na nějaké polopatické how-to nenarazil. Možná ale o něčem víte. Jak jsem z diskuze vyrozuměl, jste tady nejméně dva co do systemd pronikli natolik, že by o nějakém kloudném mohli vědět.

[David Jaša]

Výsledná konfigurace je vedlejší produkt hledání řešení jiného problému - povolení forwardingu pro virtuální interface.

to mi připomíná tenhle čerstvě spravenej bug - při dostatečně novým jádru a userlandu by to tím pádem už mohlo fungovat všude i bez zvláštních obezliček.

[Aleš Kapica]

Jo to bude nejspíš ono, až na ten drobný detail, že tahle oprava se týká pouze fedory, nikoliv Debianu. Ale díky. Jestli se v tom budu chtít pohrabat, budu alespoň tušit na co se podívat.

[Aleš Kapica]

Tak už jsem se dohrabal k jádru pudla. V instalačních balících pro openvswitch Debian aktuálně nemá nativní unitu pro systemd. Proto se zpracovává (nějak nevím jak) výchozí init skript. Ve zdrojáku ovšem tato unita je, ale pouze v adresáři pro rudé peklo, tudíž ji maintaner debianího balíku nepovažoval za nutné přibalit.

[pavlix]

Pak nezbývá než požádat upstream, aby konečně registroval, že systemd není RH-only.

[Aleš Kapica]

No, vzhledem k tomu, že u Debianu není nejmenší problém systemd vykopnout, bych řekl že se budou věci nejspíš ubírat trochu jiným směrem. Přinejmenším tedy v serverové oblasti. On totiž boot Debianu bez systemd je výrazně svižnější a přehlednější, nežli s ním. A navíc, pokud je v běhu Pacemaker, není nejmenší zájem na tom, aby mu do toho, co se má skrze něj spravovat kecal nějaký lokální systemd.

[pavlix]

Jo tahkle. Ty se chystáš provozovat Debian bez systemd, tudíž se tě to nebude týkat. Já jsem to pochopil tak, že jsi hledal řešení se systemd a narazil jsi na nedostatečnou podporu.

[Aleš Kapica]

Chtěl jsem tomu dát šanci, protože jinak proti systemd vcelku nic nemám. Jenže za současného stavu by to znamenalo jen další opruz navíc. Už tak jsem s tím zabil víc času než jsem chtěl. Potřebuji totiž testovací vícenodový asymetrický cluster pro přepsání agenta Pacemakeru pro DRBD. Ten stávající od Linbitu totiž není pro víc jak dvounodový cluster dělaný. A kromě toho si chci také osahat CEPH. Jenže zatím jsem se místo toho pachtil s takovýma blbostma jako správné nahození sítě, služeb, aj. Být to jeden stroj, tak je to brnkačka, ale identickou konfiguraci sedmi hardwarově odlišných nodů je už lepší spravovat přes puppet. To ovšem sebou nese zase další zpoždění, neboť se snažím ze svých stávajících masterů postupně vydestilovat univerzálně použitelné moduly.

No a do toho ty uhnívající disky. Dneska chcípnul systémový disk zase v jiném nodu. Nejspíš se vrátím k osvědčenému řešení, s modifikací pro Btrfs - systémové subvolume v rámci Btrfs typu raid6.

[pavlix]

Chtěl jsem tomu dát šanci, protože jinak proti systemd vcelku nic nemám. Jenže za současného stavu by to znamenalo jen další opruz navíc.

Já tomu trochu času navíc věnuju, protože používám systemd na gentoo, kde taky ještě zdaleka není doma.

To ovšem sebou nese zase další zpoždění, neboť se snažím ze svých stávajících masterů postupně vydestilovat univerzálně použitelné moduly.

Jo to dává smysl.

[michich]

pre-up service openvswitch-switch start

Hádám, že tímto vzniknul deadlock. Jelikož systemd dodržuje závislosti služeb mezi sebou, tak spouštění služby z jiné služby je k tomu náchylné. Příkaz service čekal, až openvswitch-switch nastartuje. Ten ale místo startování čekal ve frontě, až doběhne jiná služba, na níž má pořadní závislost. Pokud je skutečně zapotřebí spouštět služby z jiných služeb, hodí se použít systemctl s parametrem --no-block nebo --ignore-dependencies.

[pavlix]

Pokud je skutečně zapotřebí spouštět služby z jiných služeb, hodí se použít systemctl s parametrem --no-block nebo --ignore-dependencies.

Za --no-block jsem dostal od Michala Sekletára vynadáno a měnil jsem to na --ignore-dependencies. Na druhou stranu takové neblokující volání už nebude ani v nejmenším pre-up, takže to nejde použít. Ale --ignore-dependencies normálně blokuje, ne, takže to by mělo případně fungovat, že?

[Martin Matějek]

Občas je veselo i s openvswitchem samotným, netřeba do toho motat init systém. Na Gentoo s openrc jsem zažil případ, kdy se ovs-vswitchd dostal do nekonečné smyčky v případě, že se mu něco nezdálo - třeba že jsem chtěl nastavit LACP pro bridge a ve switchi na druhém konci kabelů nebyl LACP zapnutý, nebo něco podobného. Nevím jestli je to bug nebo feature, ale doufám, že už to opravili. Nebýt toho, že kombinace bonding + linux bridge + iSCSI je magická a spíš nefunguje než funguje, tak jsme vážně uvažovali o tom openvswitch zahodit, dokud tohle upstream neopraví.

[pavlix]

Nevím jestli je to bug nebo feature, ale doufám, že už to opravili.

Hláška dne.

[Aleš Kapica]

Já teda po něm nechci vcelku žádná kouzla, takže jsem dosud na žádný problém nenarazil. Mé připojení si ovšem vystačí se dvěma bridgi - jedním co propojuje privátní subnet a druhým co zajišťuje vnější konektivitu asi 10 virtuálům do šesti VLAN.

[pavlix]

Jakou výhodu má pro tebe použít openvswitch?

[Aleš Kapica]

Virtuální infrastruktura.

Takhle kupříkladu vypadá konfigurace, jakou můj agent pro Pacemaker zpracovává když spouští virtuální disklessový stroj postel.felk.cvut.cz

primitive postel ocf:dce:kvm \
        params workdir="/root" binfile=qemu-system-x86_64 \
        ifup="/etc/openvswitch/ovs-ifup" \
        ifdown="/etc/openvswitch/ovs-ifdown" \
        cpu=kvm64 memory=4096 monitor="/tmp/7013.monitor" \
        nic="00:0f:b0:46:23:89,virtio,tap,main,17 00:0f:b0:47:23:89,virtio,tap,main,5" \
        serial="file:/var/log/postel.serial" logfile="/var/log/postel.log" \
        pidfile="/var/run/kvm_postel.pid" \
        errlogfile="/var/log/postel.err" \
        meta target-role=Started is-managed=true \
        op monitor interval=20 \
        op start interval=0 timeout=30 \
        op stop interval=0 timeout=30

Skript /etc/openvswitch/ovs-ifup se stará o nahození virtuálního portu a skript /etc/openvswitch/ovs-ifdown zase o jeho zrušení, když Pacemaker stroj vypne. Zařazení virtuálního portu do příslušného bridge a vlan se řeší zpracováním záznamů v parametru nic.