Select Page

NETWAYS Blog

OpenNebula – Wild Duck

by | May 15, 2012 | , , , ,

OpenNebula ist seit kurzem in der Version 3.4 mit dem Codenamen “Wild Duck” verfügbar. Auf dem OpenNebula Workshop der OSDC hatte ich die Gelegenheit mir die neuen Features von Constantino Vazquez Blanco zeigen zu lassen.
Meiner Meinung nach ist das beste neue Feature, die Möglichkeit mehrere Storage-Systeme parallel nutzen zu können. Diese Möglichkeit nennt sich bei OpenNebula “Datastores”. In den vorherigen Versionen wurden Images im Image-Repository gepflegt. Das Repository konnte als Storage-Backend auf diversen Lösungen betrieben werden: NFS, OCFS2, GFS, Lustre oder auch auf lokalen Dateisystemen.
Mit den Datastores kann man ab sofort mehrere dieser Technologien auf verschiedener Hardware nutzen und daraus, wenn man so will, ein flexibles und großes Image-Repository erzeugen. Ein Blick unter die Haube erklärt das ganze ggfs. etwas leichter:
Image-Repository vor der Migration auf 3.4:
tree /var/lib/one/images/
/var/lib/one/images/
├── 2341e70a117db762c7511ce4dc8f5fba
├── 732000391bc93d78fb133a39bf7a3d28
└── d64ab94792642c40667c8532807a1a89
Datastores nach der Migration:
tree /var/lib/one/datastores/
/var/lib/one/datastores/
├── 0
│   ├── 11
│   │   ├── deployment.0
│   │   └── disk.0 -> /var/lib/one/images/732000391bc93d78fb133a39bf7a3d28
│   ├── 12
│   │   ├── deployment.0
│   │   ├── disk.0 -> /var/lib/one/images/732000391bc93d78fb133a39bf7a3d28
│   │   └── disk.1 -> /var/lib/one/images/d64ab94792642c40667c8532807a1a89
│   ├── 13
│   │   ├── deployment.0
│   │   └── disk.0 -> /var/lib/one/images/732000391bc93d78fb133a39bf7a3d28
│   └── 14
├── 1
│   ├── 2341e70a117db762c7511ce4dc8f5fba
│   ├── 732000391bc93d78fb133a39bf7a3d28
│   └── d64ab94792642c40667c8532807a1a89
└── 100
├── a9cf96dc09868a390bae2d1041aac4d9
Hier ist gut zu sehen, dass die Images aus /var/lib/one/images in den default-Datastore /var/lib/one/datastores/1 verschoben bzw. während der Migration versymlinkt wurden. Der Datastore 0 ist das Verzeichnis in dem die gestarteten VMs mit ihrer jeweiligen ID erzeugt und abgelegt werden. Der Datastore 100 ist ein optionaler weiterer Datastore exemplarisch auf einen weiteren physichen Storage.
Der Vorteil dieser neuen Funktionalität liegt ganz eindeutig darin, flexibel auf I/O Utilization reagieren zu können. Auch das Hinzufügen weiterer Datastores macht die Skalierbarkeit einfacher. Außerdem kann man VMs auf ‘langsameren’ oder ‘schnelleren’ Storages laufen lassen.
Natürlich bringt die ‘Wilde Ente’ noch viele weitere Features mit sich, die ggfs. in kommenden Blogposts oder auf opennebula.org zu finden sind.

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.
Read more from Sebastian and meet the Team

Auf die Größe kommt es an

by | Apr 4, 2012 | , ,

Immer wieder ist es notwendig auf einem bestehenden Setup das “Partitionslayout” zu ändern. Zum Beispiel sind die zu Beginn eines Projekt definierten Volumes falsch dimensioniert oder ein Service benötigt mehr bzw. weniger Platz wie angedacht.
Mit LVM und ext3/ext4 ist das auch meist kein Problem. Beim Verkleinern würde man zuerst das Dateisystem ‘shrinken'(verkleinern) und anschließend das Logical Volume entsprechend anpassen. Das Vergrößern geht online und noch einfacher. Zuerst das LV auf die Größe vergrößern und anschließend das Dateisystem wachsen lassen.
lvresize -l+10G /dev/lv/volume; resize2fs /dev/lv/volume;
Allerdings unterstützen das nicht alle Dateisysteme. Zum Beispiel kann man mit XFS zwar das Dateisystem vergrößern, allerdings nicht verkleinern. Zumindest nicht ohne größeren Aufwand. In der Regel weiß man im Voraus, welche Daten bzw. Services auf diesen Dateisystemen abgelegt werden. Möchte man z.B. die Datenpartition von MongoDB in einem Replica-Set verkleinern, fährt man den Daemon herunter, verkleinert das Volume, formatiert das Volume mit XFS neu und anschließend startet man den MongoDB-Daemon ohne Daten wieder. Für den Datenabgleich sorgt dann MongoDB selbst. Cool, oder? 🙂 Ähnliche Möglichkeiten besitzt auch PostgreSQL mit pgpool2 und Online-Recovery.
Zum Thema MongoDB gibt es auf der kommenden Open Source Data Center Conference ebenfalls spannende Vorträge!

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.
Read more from Sebastian and meet the Team

Fehler, die es nicht gibt….

by | Mar 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.
Read more from Sebastian and meet the Team

MySQL Sicherung mit LVM

by | Feb 8, 2012 | ,

Auch die robusteste MySQL-Replikation kann einmal zerbrechen, besonders wenn der Faktor Mensch einen nicht ganz unerheblichen Teil dazu beiträgt. Glücklich schätzen können sich also im Fehlerfall welche, die das DataDir auf einem Volume oder Dateisystem mit Snapshot-Funktionalität installiert haben.
Hat man einen konsistenten Master kann man mit folgenden Kommandos ein Backup erstellen und dieses zum Aufsetzen inkonsistenter,defekter oder neuer Slaves verwenden.
mysql> flush tables with read lock;
mysql> flush logs;
mysql> show master status;
bash# lvcreate -s -n snap -L5G vg/lv
mysql> unlock tables;
Innerhalb weniger Sekunden ist das Backup erstellt. Allerdings wartet das “flush tables” die gerade aktiven Statements ab. Solange hier kein Ausreißer dabei ist, bleibt es auch beim sekundenschnellen Backup.
Das Snapshot-LV kann anschließend wie gewöhnlich eingehängt und die Daten auf das Zielsystem kopiert werden. “reset slave” und “change master to ….” auf dem Slave runden das Vorgehen ab.

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.
Read more from Sebastian and meet the Team

Neues Jahr – Neue Herausforderungen

by | Jan 3, 2012 | , , , ,

Das neue Jahr ist eingeläutet, der ‘Neujahrskater’ ist bei den meisten auskuriert, die Urlauber kehren nach und nach zurück und das neue Geschäftsjahr nimmt langsam wieder fahrt auf. Zeit wird es also mit den neue Projekten fürs neue Jahr zu beginnen.
Ganz oben auf der Agenda steht die Realisierung einer Private-Cloud für uns und unsere Hosting-Kunden. Unsere Wahl ist eine Lösung mit OpenNebula.
OpenNebula ist ein Open-Source Cloud-Framework zur Bereitstellung von Public-, Hybrid- und Private-Clouds. Das Framework zeichnet sich unter anderem durch seine Flexibilität, Skalierbarkeit, Vielfältigkeit, Anpassungsfähigkeit und Stabilität aus. Es ist z.B. möglich, je nach Vorliebe oder Notwendigkeit, diverse Hypervisor zu wählen oder sogar zu mischen: KVM, XEN, VMware ebenso Containerbasierte Virtualisierungslösungen wie LXC. Das eingesetzte Storage/Repository ist ebenfalls sehr flexibel und kann z.B. aus lokalem Storage auf den einzelnen Hosts bestehen, aus einer Shared Storage Lösung mit NFS, GFS, OCFS2, iscsi etc. oder auch mit Hilfe von LVM bzw. Clustered LVM.
Wie immer ist die Wahl der eingesetzten Technologien abhängig vom Einsatzszenario, könnte aber bei Bedarf mit mehr oder weniger Aufwand jederzeit migriert oder gemischt werden.
Die Verwaltung der virtuellen Maschinen, Hosts, Images und Benutzern der Cloud erfolgt über mehrere einfach zu bedienende CLI-Tools. Alternativ gibt es auch ein Webinterface mit der die Steuerung für nicht Kommandozeilen versierte Nutzer leicht von der Hand geht. Allerdings sind hier einige Funktionen noch nicht ganz zuverlässig, aber das wird sich vermutlich in den nächsten Versionen merklich bessern.
Bei Fehlern kann man sich mit dem meist sehr aussagekräftigen Logs behelfen. Auch die Dokumentation lässt meist keine Wünsche offen. Sie könnte natürlich, wie so oft, noch präziser sein, weshalb die ein oder andere längere Fehlersuche einem wohl nicht erspart bleibt.
Mehr Informationen zum Thema wird es in zukünftigen Posts auf unserem Blog geben. Auch auf der diesjährigen Open Source Data Center Conference wird Constantino Vazquez Blanco, Mitglied des OpenNebula Projekts, einen Vortrag und einen intensiv Workshop am Vortag zum Thema halten.
Wir wünschen ein gesundes und erfolgreiches neues Jahr!

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.
Read more from Sebastian and meet the Team

Trainings

Web Services

Events