DEFAULT vmlinuz-6.8.12-9-pve
LABEL vmlinuz-6.8.12-9-pve
KERNEL server2\/vmlinuz-6.8.12-9-pve
INITRD server2\/initrd.img-6.8.12-9-pve
APPEND root=\/dev\/nfs nfsroot=192.168.3.11:\/mnt\/server2,rw ip=:::::bond0:dhcp bondslaves=eno1np0,eno2np1<\/code><\/p>\n\n\n\nDas Script selbst wurde als \/etc\/initramfs-tools\/scripts\/nfs-top\/00_bonding_init angelegt und hat die folgende Gestalt:<\/p>\n\n\n\n
PREREQS=\"\"
case<\/strong> $1<\/strong> in<\/strong>
prereqs) echo<\/strong> \"${PREREQS}<\/strong>\"; exit<\/strong> 0;;
esac<\/strong>
echo<\/strong> \"Network interfaces loaded: \"
echo<\/strong> `<\/strong>ls \/sys\/class\/net`<\/strong>
for<\/strong> x in<\/strong> $cmdline<\/strong>; do<\/strong>
case<\/strong> $x<\/strong> in<\/strong>
bondslaves=*)
bondslaves=\"${x#bondslaves=}<\/strong>\"
;;
esac<\/strong>
done<\/strong>
ip link add bond0 type<\/strong> bond
echo<\/strong> active-backup > \/sys\/class\/net\/bond0\/bonding\/mode
echo<\/strong> 1 > \/sys\/class\/net\/bond0\/bonding\/miimon
IFS=\",\"
for<\/strong> x in<\/strong> $bondslaves<\/strong>; do<\/strong>
echo<\/strong> \"+$x<\/strong>\" > \/sys\/class\/net\/bond0\/bonding\/slaves
done<\/strong><\/code><\/p>\n\n\n\nKein Hexenwerk, das System startete und lief. Die Simulation der Leitungsausf\u00e4lle (Ziehen einer Netzwerkverbindung, Auschalten eines Switches) funktionierte, alles wie gew\u00fcnscht.<\/p>\n\n\n\n
Der Ehrgeiz des Administrators<\/h2>\n\n\n\n
Wir hatten also eine sch\u00f6nes, redundantes und funktionierendes System. Und wir hatten ein „altes“ SAN mit vielen TB Kapazit\u00e4t. Viel zu schade, um es zu entsorgen. Es w\u00e4re prima geeignet als Datenablage, als Backupplatz etc…<\/p>\n\n\n\n
Die beste Anbindungsm\u00f6glichkeit f\u00fcr das SAN ist iSCSI, also die Bereitstellung von Blockdevices. Nun sollten diese Blockdevices direkt den VMs bereitgestellt werden. Der Virtualisierungshost w\u00fcrde unn\u00f6tig „aufgeblasen“, wenn er f\u00fcr diese Blockdevices als Initiator dienen und sie dann an die VMs weiter geben w\u00fcrde. Sinnvoller ist, es dann die VMs selbst Initiator werden. Nur dann k\u00f6nnen die VMs auch zwischen den verschiedenen Nodes verschoben werden.<\/p>\n\n\n\n
Die Probleme<\/h2>\n\n\n\n
Doch mit diesem guten Gedanken kommen die Probleme:<\/p>\n\n\n\n
\n- Damit die VMs auf die iSCSI-Targets zugreifen k\u00f6nnen, m\u00fcssen sie im selben Netzwerk liegen.<\/li>\n\n\n\n
- Dies bedeutet, dass die Netzwerkkarte, die auf dem Node an dem Netzwerk angebunden ist, eine Bridge bilden muss: Der Node und die VMs m\u00fcssen die Netzwerkkarte nutzen.<\/li>\n<\/ul>\n\n\n\n
Unter Proxmox ist die Bildung einer Bridge Standard. Normalerweise ist in der \/etc\/network\/interfaces z. B. wie folgt konfiguriert:<\/p>\n\n\n\n
auto lo
iface lo inet loopback
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.3.2\/24
gateway 192.168.3<\/code>.1
bridge-ports eno1
bridge-stp off
bridge-fd 0<\/code><\/p>\n\n\n\nDas System f\u00e4hrt hoch und konfiguriert das Netzwerk.<\/p>\n\n\n\n
Das Problem liegt in unserem Fall jedoch darin, dass diese Konfiguration im Root-Dateisystem liegt. Das hei\u00dft, die Netzwerkverbindung, die ge\u00e4ndert werden soll, wurde und wird zu dem Zeitpunkt der \u00c4nderung schon genutzt, um auf das Root-Dateiesystem zuzugreifen. Man z\u00f6ge in diesem Szenario also dem Node das Root-System weg. Die Folge ist ein gnadenloser Absturz.<\/p>\n\n\n\n
Der L\u00f6sungsgedanke: Bildung der Bridge in der initrd<\/h2>\n\n\n\n
Somit muss die Bridge analog zum Bonding schon in der initrd gebaut werden, dann die IP-Adresse per DHCP \u00fcber das Bridgeinterface geholt werden. Grunds\u00e4tzliche Anpassung an der pxelinux.cfg:<\/p>\n\n\n\n
ip=:::::vmbrX:dhcp<\/code><\/p>\n\n\n\nUnd Anpassung des Scriptes um die Zeilen der Bridgebildung:<\/p>\n\n\n\n
brctl addbr vmbrX
brctl addif vmbrX bond0<\/code><\/p>\n\n\n\nTrivial, oder? Die L\u00f6sung hat nur einen Nachteil: Sie funktioniert nicht. Das Debugging ergab: Es werden keine DHCP-Request abgesetzt. Die Codeanalyse, Funktion configure_networking in der Datei scripts\/functions der initrd f\u00fchrte nicht weiter. Alles wurde korrekt ausgef\u00fchrt, das Programm ipconfig in der initrd machte die korrekten DHCP-Anfragen (ja, in der initrd ist f\u00fcr die DHCP-Anfragen das Programm ipconfig zust\u00e4ndig), doch diese Anfragen tauchten nicht im Netzwerk auf. Was war anders, wo war das Problem?<\/p>\n\n\n\n
Die L\u00f6sung der fehlenden Anfragen<\/h2>\n\n\n\n
Die L\u00f6sung ist so banal wie versteckt. Wir arbeiten mit gestapelten Netzwerkinterfaces: Unten die physischen Interfaces, dar\u00fcber das Bonding-Interface und dar\u00fcber die Bridge. Ursache war, dass das o.g. Standardscript, configure_networking, das Bondiginterface zwar konfigurierte jedoch nicht startete. Ist nur das Bondinginterface vorhanden, wird es durch ipconfig bei der DHCP-Anfrage gestartet. Genauso startete ipconfig beim Stack die Bridge. Die unten liegende physischen Interfaces werden bei der Bonding-Konfiguration gestartet. Doch das Bondinginterface wurde beim Stack nicht „durch eine „nebenbei“ mitgestartet, so dass es ausdr\u00fccklich gestartet werden muss.<\/p>\n\n\n\n
Diesen Start eingebaut und siehe: Alles funktioniert: Der Node startet per PXE und NFS-Root \u00fcber das Bridgeinterface, diese steht dann den VMs zur Verf\u00fcgung, so dass diese iSCSI-Initiatoren sein k\u00f6nnen.<\/p>\n\n\n\n
Haben Sie Fragen zur L\u00f6sung, unserem Vorgehen beim Debugging, zum Netzwerkbridgeing und Bonding: Nehmen Sie mit uns, der ima GmbH, Kontakt<\/a> auf!<\/p>\n\n\n\n
<\/code><\/p>\n","protected":false},"excerpt":{"rendered":"Ein etwas technischerer Artikel \u00fcber die Problematik – und die L\u00f6sung – beim Betrieb einer Linux-Maschine, die \u00fcber PXE bootet, das Root-System \u00fcber NFS bekommt und dieses Root-System nicht nur \u00fcber ein Bonding-Interface bekommt, sondern dieses zus\u00e4tzlich als Bridge bereitgestellt wird. Die Problemstellung Die Problemstellung kam aus der Praxis: Es ging um den erweiterten Ersatz […]<\/p>\n","protected":false},"author":2,"featured_media":2088,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,53,141],"tags":[330,331,332,202,333],"class_list":["post-2086","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration","category-aus-dem-leben-eines-administrators","category-linux","tag-bonding","tag-bridges","tag-nfs-root","tag-proxmox","tag-pxe-boot"],"_links":{"self":[{"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/posts\/2086","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/comments?post=2086"}],"version-history":[{"count":6,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/posts\/2086\/revisions"}],"predecessor-version":[{"id":2095,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/posts\/2086\/revisions\/2095"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/media\/2088"}],"wp:attachment":[{"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/media?parent=2086"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/categories?post=2086"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/tags?post=2086"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}