Wie sollte ich Ubuntu/Upstart für eine ungewöhnliche Netzwerkkonfiguration konfigurieren?

Question

Ich habe vor Kurzem Ubuntu Utopic 14.04 LTS auf einer neuen Server-Box installiert, die ich speziell zum Hosten einiger virtueller Maschinen gebaut habe. Die Netzwerkkonfiguration für diese Box, die zwei Netzwerkkarten enthält, stellt die beiden Netzwerkkarten nur über virtuelle Brücken bereit – eine zu einem privaten Netzwerk, eine zum öffentlichen Internet. Eine Gast-VM greift über Taps auf beide Brücken zu und dient als Firewall und Gateway für den Host im Besonderen und das private Netzwerk im Allgemeinen. Die andere VM ist einfach ein separater Gastserver im privaten Netzwerk. Der Host nimmt nur über die entsprechende private Brücke direkt am privaten Netzwerk teil.

Infolgedessen sind weder eth0 noch eth1 nur im Kontext ihrer entsprechenden virtuellen Brücken „aktiv“. Wenn Ubuntu jedoch bootet, geht Upstarts Failsafe meiner Meinung nach fälschlicherweise davon aus (besteht darauf?), dass zumindest eth0 unabhängig aktiv sein muss, bevor das System die von Failsafe auferlegten Verzögerungen von 20/40/60 Sekunden überwinden kann. Doch es besteht fast keine Hoffnung, dass die Verzögerungen behoben werden, bis der Bootvorgang abgeschlossen ist und die Gast-VMs ungehindert starten können! Sehen Sie das Paradoxon? Ehrlich gesagt bin ich mir nicht sicher, ob eth0 oder eth1 aktiv sein werden.immerDas Erreichen des ausfallsicheren Zustands ist anspruchsvoll.

Auf einer rohen, reaktionären Ebene möchte die frustrierte, nicht-Ubuntu-Seite von mir die Ausfallsicherheit herausreißen, weil jeder Neustart für eine Konfigurationsänderung mich zwingt, bis zu zwei Minuten auf eine Statusänderung zu warten, von der ich zu 99,9 % sicher bin, dass sie niemals stattfinden wird.von Entwurf. Fazit: keine Failsafe-Abhängigkeit. Ich möchte einfach die zusätzlichen Hürden beseitigen, die Failsafe mir auferlegt.

Aus demselben Grund versuche ich, zumindest einigermaßen unvoreingenommen zu sein, was Upstart mit Failsafe vorhat, da ich zum ersten Mal damit in Berührung komme. Ich habe einige (sehr vage) Informationen gesehen, dass ein Ansatz hierzu darin besteht, die Einrichtung von /etc/network/interfaces zu ändern und meine Bridge-Setups in ihre eigenen Upstart-Aufgaben zu verschieben, aber ich würde meine Schnittstellendefinitionen lieber so lassen, wie sie sind, und zwar in Ordnung und funktionsfähig.

Welche Möglichkeiten habe ich also? Kann ich die Failsafe-Aufgaben einfach eliminieren oder sie ändern, um ihre Bedingungen zu ändern? Und wenn ja, wie? Muss ich meine Schnittstellendatei hacken?

Answer 1

Lassen Sie mich zunächst dafür entschuldigen, dass ich meine eigene Frage beantworte.

Zweitens habe ich das Problem der Startverzögerung von failsafe.conf tatsächlich gelöst. Mir ist zwar klar, dass es zu dieser Frage keine große Aktivität gegeben hat, aber ich habe in verschiedenen anderen Threads zu ähnlichen Problemen mit Failsafe/Startverzögerung so viel Aktivität gesehen, dass ich meine Recherchen und Lösungen zum Nutzen anderer in einer ähnlichen Lage veröffentliche.

Überblick

Wie im ersten Beitrag erwähnt, bestand das Problem meiner Ansicht nach darin, dass der Failsafe-Upstart-Job beim Booten meines Systems eine unerwünschte Einschränkung auferlegte. Ich habe das Problem dann weiter untersucht und herausgefunden, warum sich Failsafe so verhielt.

Analyse

Standardmäßig definiert failsafe.conf eine Startbedingung, die es effektiv beim Booten auslöst (sobald das Dateisystem und die Loopback-Schnittstelle verfügbar sind), und definiert eine von zwei möglichen Stoppbedingungen:

start on filesystem and net-device-up IFACE=lo
stop on static-network-up or starting rc-sysinit

Failsafes Beharren auf den Verzögerungen entstand, weil keines der beiden „Stopp“-Ereignisse ausgelöst wurde. Die zweite Bedingung, rc-sysinit, ist eine der letzten Systeminitialisierungsaufgaben, die Upstart ausführt, und hat ihre eigene Startbedingung.

start on (filesystem and static-network-up) or failsafe-boot

Mit Failsafe nichtStoppen, es ist offensichtlich, dass rc-sysinit nichtbeginnend.Failsafe wird das Failsafe-Boot-Ereignis ausgeben, sobald seine Timeouts abgelaufen sind. Wenn Failsafe gestartet wurde, ist „Dateisystem“ impliziert, sodass die einzige verbleibende Bedingung, die beiden Ereignissen gemeinsam ist, „statisches Netzwerk aktiv“ ist. Failsafe wird ausgeführt, weil es glaubt, dass keine Netzwerkschnittstellen aktiv sind.

Die Ursache

Wenn man rückwärts durch /etc/network/if-up.d geht, wird ein Upstart-Skript definiert, das alle in /etc/network/interfaces definierten Netzwerkschnittstellen durchläuft, die mit einem „auto“-Qualifizierer definiert sind, was bedeutet, dass die Schnittstelle beim Booten aktiviert werden soll. Die Definition, wie eine Schnittstelle als „aktiv“ betrachtet wird, wird zu einem wichtigen semantischen Problem, das ich später beschreiben werde.

Genau dann, wenn alle „auto“-konfigurierten Schnittstellen aktiv sind, wird das Upstart-Skript das berühmte Ereignis „static-network-up“ auslösen. Dies würde wiederum rc-sysinit ermöglichen, zu starten und Failsafe zu beenden – also die eigentliche Ursache meines Problems. Keine meiner Netzwerkschnittstellen hat beim Booten eine IP-Adresse – so ist es vorgesehen. Aber „static-network-up“ unterstützt nicht die Idee, dass eine Schnittstelle aktiv ist.ohneeine IP-Adresse, daher bleibt die Ausfallsicherheit hängen, bis die Timeouts ablaufen.

In meiner Situation stelle ich die beiden physischen Netzwerkkarten in der Box als Slaves auf Bridges und stelle sie über Taps zwei verschiedenen VMs zur Verfügung. Eine VM stellt DHCP über einen Tap bereit, die andere ist nur ein Server im selben Netzwerk. Damit die Bridges richtig funktionieren, wenn sie von den VMs angezapft werden, müssen die Netzwerkkarten zumindest „UP“ sein und passiv Pakete durchlassen. Daher schien „auto“ in /etc/network/interfaces angemessen. Es warnichtAus Sicht von Failsafe war dies jedoch nicht angemessen, weshalb die einzige Lösung eine sein musste, die der Semantik von Failsafe entsprach.

Die Lösung meines Problems war also zweifach:

1. Entfernen Sie die „Auto“-Deklaration aus jeder Netzwerkschnittstelle, die ich definiert habe (außer Loopback).
2. Erstellen Sie Upstart-Jobs, um die zuvor „automatischen“ Schnittstellen „manuell“ aufzurufen.

Ich habe einen Job für jedes von vier Geräten definiert - zwei Taps und zwei virtuelle Bridges - indem ich eine bereitgestellte Lösung nachgeahmt habeHier.

In dieser Konfiguration ohne „Auto“-Schnittstellen sollte das Netzwerkskript jetzt sofort „static-network-up“ ausgeben und so die Beendigung von Failsafe erzwingen. Eine letzte Änderung erforderte, dass ich der Schnittstellendefinition jedes Taps eine „Post-up“-Klausel hinzufügte, um „brctl“ aufzurufen und die entsprechende virtuelle Brücke zu erstellen, was zuvor als Teil der „Auto“-Konfiguration erledigt wurde.

Meine /etc/network/interfaces sieht jetzt (teilweise) so aus:

#auto tpRED  (commented out)
  iface tpRED inet manual
  pre-up /usr/sbin/tunctl -t tpRED
  post-up /sbin/brctl addbr brRED

#auto brRED
  iface brRED inet manual
  bridge_ports eth1 tpRED
  bridge_hw xx:yy:aa:bb:cc:dd

Der Härtetest

Der Härtetest? Den Server neu starten. Und als ich das tat,das Failsafe-Timeout war weg, und mein Netzwerk wurde in einer funktional identischen Konfiguration gestartet. ES FUNKTIONIERT!! Ich wünschte nur, wir hätten die Semantik einer „UP“-Netzwerkschnittstelle besser im Griff!!