Jak skamarádit openvswitch a systemd

19.11.2014 13:23 | Přečteno: 1290× | Za vším hledej Linux | | poslední úprava: 19.11.2014 13:23

Původně se měl tento blogpost jmenovat: "Proč spolu openvswitch a systemd neka..?", ale podařilo se mi to lousknout, tak bych tady chtěl popsat v čem spočíval problém, než to - jako obvykle - zapomenu.

Jak jsem to dělal dřív..

U "staršího" clusteru Peanuts, na kterém jsem rozjížděl openvswitch zhruba před necelým rokem, jsem řešil konfiguraci sítě takto...

root@stroj:~# cat /etc/network/interfaces
auto eth0
iface eth0 inet manual
    up ip link set $IFACE up
    down ip link set $IFACE down

auto interni
iface interni inet static
    pre-up service openvswitch-switch start
    address 10.0.0.214
    netmask 255.255.255.0
    broadcast 10.0.0.255

Vyžaduje to však aby již byl předem vytvořený bridge interni se "zapojeným" síťovým zařízením eth0:

root@stroj:~# ovs-vsctl show
458eb0ea-1825-40de-8e3b-028ea61c0faf
    Bridge interni
        Port interni
            Interface interni
                type: internal
        Port "eth0"
            Interface "eth0"
    ovs_version: "2.1.0"

U strojů clusteru Schrot jsem ale narazil na problém, že s touto konfigurací systém vůbec nenajížděl. Při startu končilo spouštění při konfiguraci sítě v nekonečné smyčce - viz snímek:

Nezbylo, než přidat do parametrů jádra při zavádění break, najet do ramdisku, namountovat systémový disk a laborovat se souborem /etc/network/interfaces.

Jak se metodou pokus/omyl ukázalo, příčinou problému byl následující řádek v souboru /etc/network/interfaces:

...
    pre-up service openvswitch-switch start
...

Po jeho zakomentování systém normálně najel, ale bez nahozeného portu interni.

Vrtalo mi hlavou proč, až mě napadlo podívat se, zda-li je u systémů staršího clusteru Peanuts nainstalován systemd. Samo že nebyl. Odinstaloval jsem ho, a voilá! Začalo to fungovat.

Síťová konfigurace Schrotu je ale oproti staršímu clusteru Peanuts složitější v tom směru, že jeho stroje lezou ven pouze prostřednictvím jediného nodu. Aby je bylo možné spravovat přes Puppet, musí mít nastavenou maškarádu a povolený forwarding na vnější a vnitřní síťové rozhraní.

Vytvořil jsem tedy jednoduchý skript /etc/network/if-up.d/iptables, který se stará o zavedení pravidel pro iptables a do souboru /etc/sysctl.conf přidal následující dva řádky:

net.ipv4.conf.eth0.forwarding=1
net.ipv4.conf.interni.forwarding=1

Ale ouha! Při startu je akceptováno pouze nastavení pro eth0. Nikoliv pro port interni. Mohl bych sice forwarding povolit jedním parametrem pro všechna rozhraní najednou, to však nepovažuji řešení. Také jsem nebyl spokojen s odinstalováním systemd což nelze považovat za vyřešení problému. Když je s ním schopen koexistovat Pacemaker, tak to musí být řešitelné pro openvswitch.

Při hledání řešení pro NAT jsem narazil v ukázkové konfiguraci souboru /etc/network/interfaces na parametr allow-ovs. Nakouknul jsem tedy do souboru /usr/share/doc/openvswitch-switch/README.Debian.gz, upravil podle něj příslušným způsobem konfiguraci, doinstaloval systemd a restartoval.

Konfigurace při které se openvswitch kamarádí se systemd..

root@stroj:~# cat /etc/network/interfaces
allow-ovs interni
iface interni inet static
    address 10.0.0.214
    netmask 255.255.255.0
    broadcast 10.0.0.255
    ovs_type OVSBrid
    ovs_ports eth0

allow-interni eth0
iface eth0 inet manual
    ovs_bridge interni
    ovs_type OVSPort

Jak už jsem poznamenal - při konfiguraci rozhraní virtuálního switche je klíčový parametr allow-ovs, kterým se aktivuje síťové rozhraní bridge v ukázkovém příkladu s názvem interni. Kromě obvyklé síťové konfigurace, může obsahovat každá příslušná položka virtuálního switche parametr ovs_type, jimž se implicitně říká, o jaký typ zařízení jde (zda bridge nebo port). A v případě, že se u bridge mají hned po startu nahodit i některé porty parametr ovs_ports s jejich seznamem.

U konfigurace portu (síťového rozhraní) se parametrem allow-interni implicitně řekne, do kterého bridge port patří a tím dojde při spuštění bridge i k jeho nahození.

       

Obrázky

Komentáře

[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.