Fehler, die es nicht gibt….

Vergangene Woche ereignete sich ein ganz besonderes Fehlverhalten eines MySQL-Master-Master-Clusters. Das Setup besteht aus zwei MySQL-Servern, die über eine sogenannte Master-Master Konfiguration replizieren. Allerdings werden nicht beide Nodes aktiv verwendet, sondern jeweils nur der zur Zeit aktive. Das ganze ist relativ trivial realisiert und zwar über eine IP-Adresse, die mittels Heartbeat auf einem der beiden Server als Ressource genutzt wird und bei einem Ausfall auf den anderen Node schwenkt. Die Gründe für ein solches Setup sind die eingesetzten nicht replikationssicheren Anwendungen, welche für Inkonsistenzen sorgen würden, sobald sie auf beide Server zugreifen würden und zum zweiten natürlich die Hochverfügbarkeit im Fehlerfall.
Soviel zum Setup, passiert ist nun folgendes: Die Heartbeat IP-Adresse wurde von Server1 auf Server2 und wieder zurück geschwenkt. Anschließend kam es in der Datenbankreplikation zu Fehlern(“1062 Duplicate Key Entry” und “1032 Key not found”). Nach dem wir die fehlgeschlagenen Statements überprüft und auch in den Bin- und Relay-Logs nachgesehen haben, stellte sich heraus, dass auf beiden Servern Datensätze eingetragen bzw. manipuliert wurden. Wie kann das sein?
Die IP-Adresse war, nach einer Kontrolle mit “ip a”, wieder auf Server Server1 gebunden und aktiv. Mit “netstat” waren allerdings auf Server2 mehrere MySQL Verbindungen zu sehen. Ist die IP doppelt vergeben? Nein. Mit “ip a” auf dem zweiten Server gab es keine Spur der Heartbeat-IP. Was jetzt? Was passiert hier?
Es war Zeit für “tcpdump”. Mit “tcpdump port 1234” auf Server2 und einem “telnet server2 1234” von einem der Webserver wurde klar, Server2 nimmt Verbindungen für diese IP entgegen. Was kommt jetzt? Klar, vermutlich sind die lokalen ARP-Einträge krumm. In der Tat, die ARP-Tabelle auf einem der Webserver enthält die MAC-Adresse von Server2 für die entsprechende Heartbeat-IP, die ja eigentlich auf Server1 laufen sollte. Ok, das macht soweit Sinn. Der Ressource-Agent für die Heartbeat-IP Adresse gibt zwar mittels Gratuitous ARP seine neue MAC-Adresse via Broadcast bekannt, aber vielleicht hat es ja diese Webserver nicht erreicht. Die Frage jetzt lautet eigentlich: Warum nimmt Server2 diese IP-Verbindungen überhaupt für die offensichtlich nicht konfigurierte IP-Adresse Verbindungen entgegen. Nochmal “ip a” kontrolliert, ob die IP nicht doch konfiguriert ist. Nein. Mit “tcpdump -i any -n arp” auf Server2 kontrolliert, ob Server2 auf ARP Requests für diese IP-Adresse antwortet. Ja, da ist der Reply!
Mit einem gekonnten Blick in den Kernel-Source-Code ../net/ipv4/arp.c wird man fündig. Auf ARP-Requests wird geantwortet wenn es einen Lokalen Routing Table Eintrag gibt. (“inet_addr_type(net, tip) == RTN_LOCAL &&”). Die Ausgabe der lokalen Routing-Table “ip route show table local” beantwortet dann letztendlich auch die Frage, warum Server2 auf Pakete mit der vermeintlich nicht konfigurierten IP antwortet bzw. deren Verbindung akzeptiert.
Nach einem erneuten Schwenk auf Server2 und wieder zurück, verschwand auch dieser Eintrag und alles funktionierte wieder wie erwartet.

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sepp kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet zusammen mit Martin das Managed Services Team. Wenn er nicht gerade Server in MCollective einbindet, versucht er mit seinem Motorrad einen neuen Geschwindigkeitsrekord aufzustellen.

Live von der OSDC: Virtual consolidated HA

linbitFlorian Haas ist Partnermanager bei der Firma Linbit, und Spezialist für Hochverfügbarkeitsumgebungen unter Verwendung von DRBD, XEN, KVM uvm.
Schwerpunkt seines Vortrages um 11:30 Uhr war die Verwendung von etablierten Open-Source-Lösungen in konsolidierten, heterogenen Umgebungen. Dabei ging er auf die aktuellen Entwicklungen im Bereich Heartbeat, OpenAIS und Pacemaker ein. Die Teilnehmer bekamen mit diesem hochklassigen Vortrag einen guten Überblick über die aktuellen Entwicklungen. Gerade Pacemaker, welches als Weiterentwicklung des Heartbeat CRM antielig bei Novell weiterentwickelt wird, verspricht interessante Ansätze für zukünftige Projekte. In den aktuellen Kernel-Versionen wird Heartbeat nach und nach mit den “neuen Namen” OpenIAS und Pacemaker als Weiterentwicklung ersetzt.
Da auch wir diese Technologien in unseren Projekten einsetzen, werden wir hier natürlich auch am Ball bleiben und regelmässig über Neuigkeiten bloggen.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.