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 😉