Bonding-Flapping mit Linux und Supermicro-IPMI

Dass jedes System irgendwann mal ausfällt, kommt natürlich vor. Neulich hatten wir einen Ausfall, welcher routinemäßig anfing, sich jedoch als sehr seltsam entpuppte.

Alles begann an einem Dienstagmorgen gegen halb drei. Einer der Switches im Rack fiel aus und das Monitoring klingelte die Bereitschafts-Admins wach, da nicht nur der Switch, sondern auch ein paar Server nicht mehr erreichbar waren. Der Ausfall selber wäre halb so wild, da die Server mithilfe eines Active-Passive Bondings an zwei verschiedenen Switches hängen. Jedoch wurde bei manchen Servern der Port, welcher an den defekten Switch angeschlossen war, immer wieder auf „Active“ gesetzt. Das dies ein falsches Verhalten ist, ist natürlich klar, jedoch die Ursache ein schönes Beispiel für das Zusammenspiel von mehreren unbekannten Standardparametern.

Wir betreiben die Linux-Bondings meist mit einem konfiguriertem arp_ip_target, welches auf den jeweiligen Core-Switch zeigt. Dies ist nötig, damit falls der Uplink des Rack-Switches ausfällt, eine Umschaltung auf den anderen Switch erfolgt. Was jedoch wenige wissen: Selbst wenn ein arp_ip_target konfiguriert ist, heißt das nicht, das dies der Auslöser für ein Failover ist. Sobald das Bonding auf dem Port Traffic sieht, wird dieser wieder auf aktiv gestellt. Dies lässt sich mit dem arp_validate Parameter konfigurieren, welcher im besten Falle auf „validate“ gestellt wird um nur auf die ARP Responses des Bonding Treibers zu reagieren.

Nun stellt sich die Frage welcher Traffic dort vom Bonding-Treiber gesehen wurde, da der Switch offline war. Wir betreiben hauptsächlich Server von Supermicro, welche ein IPMI besitzen. Diese haben entweder einen eigenen dedizierten Port für das Netzwerk oder nutzen einen mit dem System geteilten. Diese Modi heißen „dedicated“ bzw „shared“, jedoch gibt es auch einen Modus namens „failover“, welcher wenn der dedizierte Port offline ist automatisch auf „shared“ umstellt und darüber versucht eine IP zu bekommen. Dieser Modus ist die Werkseinstellung.

Diese beiden „interessanten“ Standardverhalten haben in Kombination den Bonding-Treiber dazu gebracht den Netzwerk Port kontinuierlich zwischen Aktiv und Passiv umzuschalten. Da der dedizierte IPMI-Port durch den Switch-Ausfall down war, hat das IPMI seine DHCP-Requests auf den Shared Port geschickt. Diese Pakete wurden vom Bonding-Treiber gesehen, welcher daraufhin den Port auf aktiv stellte, weil dort ja Traffic war. Nach ein paar Sekunden fiel jedoch auf, dass der Port down sein müsste, da kein Traffic mehr zu sehen war und das ARP Target failte und der Port wurde wieder abgeschaltet. Dass nur manche Server hiervon betroffen waren, lag daran, dass nicht alle Server ihren dedizierten IPMI-Port und primären Bonding-Port auf dem gleichen Switch hatten.

Falls dieser Artikel dein Interesse geweckt hat, we are hiring 😉

Featurebranches mit Gitlab auf gemeinsamer Stage-Umgebung testen

Im Hosting-Team von Babiel verwenden wir (natürlich) Git-Repos für unsere Anwendungen und Konfigurationen. Wir nutzen Gitlab um die Repos zu hosten. Dabei arbeiten wir stark mit Featurebranches, Merge Requests und CI-Pipelines, damit Änderungen vor dem Rollout einen Code-Review und automatische Tests durchlaufen können. Üblicherweise erlauben wir in unseren Repos nicht, direkt in den Hauptbranch (master/main) zu pushen, damit dort keine Änderungen ankommen, die die Pipeline für die Kolleg*innen kaputt machen würden.

Manchmal möchte man einen Branch tatsächlich deployen, um ihn bewerten zu können, bevor man ihn merget. Bei Gitlab gibt es dazu das Feature „Review Apps“, mit dem Branches in eine temporäre Umgebung ausgerollt werden können. Gitlab zeigt auch einen Link zu dieser Umgebung an, so dass man direkt dorthin springen kann. Wenn man den Branch löscht (was meistens automatisch beim Merge passiert), wird die temporäre Umgebung ebenfalls gelöscht.

Review Apps sind ein sehr nützliches Feature. Wir benutzen es für die meisten Services, die wir auf Kubernetes betreiben, denn dort können wir schnell zusätzliche Umgebungen erstellen und ebenso schnell auch wieder löschen. 

Aber für manche Anwendungen ist es nicht möglich oder praktikabel, kurzfristig eine temporäre Instanz zu starten. Vielleicht lässt sich eine Instanz nicht ohne Vorarbeit einfach erstellen. Vielleicht bräuchte man zum Testen bestehende Daten, die in einer frischen Instanz nicht zur Verfügung stünden. Für ausgiebige Tests oder iterative Entwicklung ist es hier sinnvoll, sich auf dem Client eine Bastelumgebung zu schaffen (z.B. mit Docker oder Vagrant). Aber für viele Änderungen wäre das Overkill — man möchte nur kurz eine Änderung verifizieren, bevor man sie merget und produktiv ausrollt.

Für solche Situationen haben wir einen Weg gefunden, der für uns gut funktioniert: Wir betreiben dauerhaft ein Staging-Environment, auf dem auf Knopfdruck ein Branch ausgerollt werden kann. Gitlab erzwingt keine feste Zuordnung zwischen Branch und Environment, d.h. das Environment kann von beliebigen Branches benutzt werden. 

Wir benutzen das Feature insbesondere für Monitoring, wo wir auf bestehende Daten zurückgreifen möchten wenn wir z.B. neue Alerts für Prometheus erstellen. 

Der Ansatz hat natürlich ein Bottleneck mit der gemeinsamen Stage-Umgebung, den dedizierte Review-Umgebungen nicht hätten. Es ist also möglich, dass man sich mit mehreren Branches ins Gehege kommt. Bei unserer Teamgröße haben wir bisher aber keine Probleme mit den Repos, wo wir diesen Ansatz fahren. Bei Bedarf kann man im Gitlab sehen, wann wer welchen Stand auf die Umgebung ausgerollt hat. 

Zusammengefasst ist dieser Ansatz für uns ein sehr nützlicher Kompromiss, der Review Apps auf Anwendungen überträgt, wo sie sonst nicht nutzbar wären. Damit erhöht er unser Vertrauen in Changes ohne viel zusätzlichen Aufwand. 

Falls dieser Artikel dein Interesse geweckt hat, we are hiring 😉

Hello world!

Willkommen zum technischen Blog der Babiel GmbH!

Hier schreiben häuptsächlich Kollegen aus dem Bereich des Managed Hostings – unsere HR bespielt Linkedin, Facebook und Instragram – hier sind die Techniker am Werk. 😉 Auf twitter sind wir diejenigen, die technische Dinge (re)tweeten und kennzeichnen dort unsere Beiträge durch unser jeweiliges Kürzel.

Wir hoffen, durch den Blog bessere Einblicke darauf geben zu können, wie wir arbeiten, welche Themen uns bewegen und hoffen, darüber auch in einen Austausch zu kommen. Pre-COVID19 fand man uns regelmäßig auf Meetups, z.B. beim „talk@babiel“ direkt bei uns vor Ort, aber z.B. auch bei DevOps Düsseldorf – dort ebenfalls mit Vorträgen. Da der Vor-Ort Austausch leider schon lange ruhen muss, sieht man sich nun vielleicht mal beim Infrafoo des Chaosdorf.

Zum Team: wir sind derzeit 22 Kollegen und dafür verantwortlich, die IT Services der Babiel zu betreiben. Das fängt an bei Grundlagen wie dem Betrieb unseres Autonomen Systems AS198913, geht weiter über Themen wie Virtualisierung, Storage, Betriebssysteme, Managed Hosting, Monitoring und umfasst auch den Betrieb der Applikationen; aber auch betriebsrelevante Tools werden in der Abteilung programmiert.

Themen die uns bewegen sind also:

  • Datacenter-Technologie im Netzwerkbereich, Loadbalancer, DDoS-Schutz, Virtualisierung
  • Automatisierung, CI/CD Pipelines, Puppet, Go
  • Kubernetes
  • Linux
  • Speziallösungen für IT-Probleme, die man mit der Zeit bekommt und für die es keine „off the shelf“ Lösung gibt

Enjoy our Blog!