Seite wählen

NETWAYS Blog

Schulung Clusterbau mit Pacemaker

von | Jul 26, 2013 | , , ,

images
Ich bin dabei eine neue Schulung vorzubereiten, Clusterbau mit Pacemaker. Die Schulung wird einen Umfang von zwei oder drei Tagen haben. Sie ist soweit fertig und bietet im groben, folgende Gliederung:

  • Grundlagen
  • Installation
  • Aufbau eines Active/Passive-Clusters
  • Hinzufügen weiterer Services
  • Active/Active Cluster
  • Storage-Replikation mit DRBD
  • Fencing

Die bisher berücksichtigten Dienste sind neben einer IP-Adresse, der Apache-Webserver, MySQL und DRBD. Natürlich existiert auch schon ein Abschnitt über Icinga, ob der es allerdings in die Endfassung schafft steht noch nicht fest. Für Vorschläge bin ich allerdings offen und hoffe von euch einige per Kommentar zu erhalten.
Auch für den Fall, dass jemandem noch interessante angrenzende Themen zu Pacemaker hat, was beim Clusterbau sonst noch interessant sein könnte, einfach als Kommentar zu diesem Blockpost.

Lennart Betz
Lennart Betz
Senior Consultant
Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.
Lies mehr von Lennart und triff unser Team

MySQL-Queries mit Wireshark analysieren

von | Jun 20, 2013 | , ,

Für MySQL gibt es zwar etliche Tools zur Performance-Analyse, aber auch mit einfachen Mitteln wie tcpdump/Wireshark kann man sich behelfen.
Zunächst schneiden wir mit tcpdump die Daten der MySQL-Verbindung mit:

# tcpdump -s 0 -w mysql.pcap -i any port 3306

Zu beachten ist dabei, dass MySQL standardmäßig auf seinen Unix-Socket verbindet, wenn man als MySQL-Host „localhost“ verwendet. Dieses Problem lässt sich umgehen, indem man stattdessen zu „127.0.0.1 verbindet.
Nachdem wir unsere Queries mitgeschnitten haben, können wir die .pcap-Datei in Wireshark öffnen. Über Statistics -> IO Graph lassen sich dann entsprechende Graphen generieren:
mysql-wireshark
Über die Filter können wir uns Graphen zu bestimmten Queries generieren. Beispielsweise:

  • mysql.query matches „SELECT*“
  • mysql.query matches „INSERT*“
  • mysql.query matches „UPDATE*“
  • mysql.query matches „SELECT*FROM „
  • mysql.query == „BEGIN“ || mysql.query == „COMMIT“

OSDC 2013: Der Countdown läuft! Nur noch 51 Tage bis zur OSDC

von | Feb 25, 2013 | , , , ,

Heute läuten wir den baldigen Start der OSDC 2012 mit Kennys Vortrag auf der OSDC 2012 ein. Er berichtet uns davon, wie man ganz schnell MySQL-Probleme löst.

OSDC? Noch nie gehört…
Das ist aber schade und fast schon ein unentschuldbares Versäumnis!
Aber wir holen das nach:
Die Open Source Data Center Conference (kurz OSDC) ist unsere internationale Konferenz zum Thema Open Source Software in Rechenzentren und großen IT-Umgebungen. 2013 findet sie zum fünften Mal statt und bietet mit dem Schwerpunktthema Agile Infrastructures ganz besonders erfahrenen Administratoren und Architekten ein Forum zum Austausch und die Gelegenheit zur Aneignung des aktuellsten Know-Hows für die tägliche Praxis.
Workshops am Vortag der Konferenz und das im Anschluss an die Veranstaltung stattfindende Puppet Camp komplettieren dabei das Rundum-sorglos-Paket für Teilnehmer, die gar nicht genug Wissen in sich aufsaugen können.

OSDC 2013: Der Countdown läuft: Nur noch 72 Tage bis zur OSDC

von | Feb 4, 2013 | , , ,

Um uns die Wartezeit zur diesjährigen OSDC zu versüßen tritt heute Erkan auf den Plan und erhellt uns in Sachen MySQL Cluster.


 

OSDC? Noch nie gehört…
Das ist aber schade und fast schon ein unentschuldbares Versäumnis!
Aber wir holen das nach:
Die Open Source Data Center Conference (kurz OSDC) ist unsere internationale Konferenz zum Thema Open Source Software in Rechenzentren und großen IT-Umgebungen. 2013 findet sie zum fünften Mal statt und bietet mit dem Schwerpunktthema Agile Infrastructures ganz besonders erfahrenen Administratoren und Architekten ein Forum zum Austausch und die Gelegenheit zur Aneignung des aktuellsten Know-Hows für die tägliche Praxis.
Workshops am Vortag der Konferenz und das im Anschluss an die Veranstaltung stattfindende Puppet Camp komplettieren dabei das Rundum-sorglos-Paket für Teilnehmer, die gar nicht genug Wissen in sich aufsaugen können.

Fehler, die es nicht gibt….

von | Mrz 28, 2012 | , , ,

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
CEO Managed Services
Sebastian 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 das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.
Lies mehr von Sebastian und triff unser Team

Trainings

Web Services

Events