…or the day before the Conf – depending on how you count.
We started the day early to get from the NETWAYS headquater in Nuremberg to the conference hotel Berlin. Our friends from OpenNebula were already there and we could make all preparations for the workshops very smoothly. There was even enough time to take a snack.
Exactly at 2:00 pm (just like expected when dealing with pettifogging Germans) the workshops started. Now the next thing we are looking forward to is dinner. 🙂
Tomorrow the actual conference will start and will officially be opened with Ignacio M. Llorentes kick off “State and Future of OpenNebula”. We can also look forward to David Lutterkort talking about what an enchanting match Puppet and OpenNebula are.
The early afternoon will then be filled with enlightening talks by Carlo Daffara and Daniel Molina until it’s time for dinner again. 🙂
Late afternoon (or pre evening event time slot, as we call it) will start with another highlight: Armin Deliomini will tell us how Runtastic switched from commercial products to Open Source only. Now, about one year later, he will give us an insight to the Status Quo where the private infrastructure for more than 40 000 000 registered users for Runtastic is implemented.
Also the talks of Jose Angel Diaz (CENATIC), Jordi Guijarro (CSUC) Tino Vazquez (OpenNebula) and many more will sweeten the time until the evening event finally starts. This year we will be at the restaurant “Alte Meierei”.
And then we just have to wake up once again, until the next Conf day, with even more highlights starts. 🙂
NETWAYS Blog
Drei Wege um virtuelle Maschinen zu migrieren
Neue Storage-Lösungen sprießen wie Tulpen im Frühling aus dem Boden. Jede einzelne ist flexibler, schlanker und hochverfügbarer.
Da kommt meine Cloud ins Spiel, die eigentlich gut läuft aber so ein schnelleres Storage ist eine willkommene Abwechslung.
So ein neues Storage ist schnell aufgesetzt, was uns dann aber vor eine neue Aufgabe stellt,
denn unsere VMs laufen… nur nicht auf unserem hippen Storage.
Nun gibt es diverse Methoden um eine virtuelle Maschine in ein neues Image bzw. neues Storage zu transferieren.
Da haben wir zum einen die altbewährte Methode, mit dem Urgestein aller blockorientierten Kopiervorgänge dd.
Dazu muss die virtuelle Maschine komplett ausgeschaltet sein. Da sich der Zustand der VMs nicht mehr ändert, kann man beruhigt die VM kopieren.
dd if=/path/to/input/file of=/path/to/output/file bs=4096
Zum anderen die Methode ein qcow2 Image in ein Blockdevice zu schreiben.
In Worten gesagt: das Image wird mit “qemu-img convert” in Raw umgewandelt und danach mit dd auf das neue Blockdevice kopiert. (Auch hier sollte die VM nicht mehr laufen!)
qemu-img convert -p -f qcow2 -O raw /path/to/input/file /path/to/outputfile.raw && dd if=/path/to/outputfile.raw of=/path/of/device bs=4M
Da die beiden genannten Arten eine lange Downtime benötigen, sind sie nur für VMs geeignet die nicht zeitkritisch sind.
Ein UNIX System kann mit guten Kenntnissen, mit relativ kurzer Ausfallszeit migriert werden. Ein hilfreiches Werkzeug dabei ist Rsync.
Leider kann ich hierzu kein fixes Beispiel vorzeigen, da die einzelnen Schritte von System zu System unterschiedlich ausfallen.
Die essentiellen Schritte sind:
1. Neues Device in der VM mounten und das gewünschte Filesystem erstellen.
2. Systemverzeichnisse auf dem neuen Device erstellen.
3. Das komplette System mit Rsync auf das neue Device kopieren. Hier muss man natürlich etwas aufpassen und Verzeichnisse wie /proc oder ggf. /mnt exkludieren. Auch auf bind Mounts sollte man achten, damit man Daten nicht ausversehen doppelt kopiert.
4. Die grub.cfg natürlich im neuen /boot Pfad aktualisieren. (grub-install und update-grub sind hierfür hilfreich)
5. Das “alte Device” als read-only einbinden und die neue fstab anpassen.
6. Und last but not least, einen weiteren Rsync in dem die restlichen Files auf das neue Image übertragen werden. (auch hier bitte das Exkludieren von wichtigen Pfaden nicht vergessen. z.B.: /etc/fstab oder auch /boot !!)
Der Vorteil hierbei ist: die Downtime erstreckt sich dabei nur über den zweiten Rsync, bei dem die Festplatte im “read-only” Modus ist.
Habt Ihr weitere coole Möglichkeiten einen VM zu migrieren?
Dann dürft ihr euch in den Kommentaren dazu äußern.
Oder seid Ihr interessiert an dem Thema Cloud und alles was damit zu tun hat? Dann besucht uns einfach auf der OpenNebula Conf 2014
Thilo Wening
Manager Consulting
Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.
Mesos
Mit Mesos hat das Apache Projekt ein Cluster-Manager geschaffen, der sich um das Ausführen verteilter Applikationen kümmert.
Der Mehrwert ist, dass mit dem Framework ein Standard geschaffen werden soll, der das komplexe “Rad neu erfinden” für solche Zwecke abgeschafft werden soll und auf bereits funktionierende Software gesetzt werden kann. Ein Beispiel ist z.B. das managen eines Quorum in einem Cluster. Jeder Clusterstack wie Pacemaker/Corosync etc. hat seine eigene Logik. Mesos setzt hierfür auf das ebenfalls aus dem Hause Apache stammende Zookeeper. Das wiederum kann dann modular für Mesos, SolR, eigene Entwicklungen usw. genutzt werden.
Was macht jetzt Mesos? Mesos besteht aus mind. einem Master und einem Slave. Der Master verteilt Jobs oder Anwendungen und die Slaves führen diese aus. Die Slaves melden außerdem regelmäßig ihre aktuelle Auslastung, so dass der Mesos-Master weiß wohin er die neuen Aufgaben verteilen soll. In dieses Konstrukt kann sich ein weiteres Framework, dass für die unterschiedlichsten Zwecke verwendet werden kann, registrieren. Es gibt die wildesten Frameworks genannt Marathon, Aurora, Chronos und viele mehr. Jedes nutzt als Basis Mesos, aber eben für seine eigenen Zwecke.
Chronos ist z.B. für das Ausführen von zeitgesteuerten Jobs entwickelt worden. Also ein Crond, nur eben, dass die Cronjobs nicht nur auf einem Host sondern auf vielen ausgeführt werden können. Mit Marathon werden Commands oder ganze Anwendungen am laufen gehalten. Einmal gestartet, sorgt es dafür dass es immer mind. xmal gestartet ist. Ein Job kann z.B. ein “/usr/sbin/apachectl -d /etc/apache2 -f apache2.conf -e info -DFOREGROUND”. Das setzt natürlich die installierte Software auf dem Slave voraus, also Apache2.
Noch abstrakter geht es indem man Mesos konfiguriert einen externen containerizer zu nutzen: Docker. Obiges Beispiel würde also nicht auf dem Slave direkt gestartet werden, sondern ein Docker Container starten und in diesem das Command ausführen. Betrieben werden kann das ganze auf physischen oder in virtuellen Servern oder beidem.
Wozu man so etwas verwenden kann muss man letztendlich selbst entscheiden. Die Lösung verfolgt den SaaS/PaaS Ansatz und stellt im wesentlichen Hardwareressourcen aus einem Pool(IaaS) zur Verfügung und bietet Bibliotheken, Frameworks und APIs um sie zu steuern. Das Buzzword nennt sich ganz allgemein Cloudcomputing 🙂
Für Docker werden wir übrigens noch dieses Jahr Schulungen anbieten.
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.
OpenNebula Conf 2014: Das schönste Programm das man nur haben kann
Eigenlob stinkt natürlich, aber das Programm für die OpenNebula Conf ist eines der schönsten, die man so haben kann. Diesmal wird uns David Lutterkort, von unserem Partner Puppet Labs, beehren und vom äußerst fruchtbaren Zusammenspiel von Puppet und OpenNebula berichten.
Außerdem gibt es mit Armin Deliomini von Runtastic auch den richtigen Referenten zur Feier unserer unlängst errungenen sportlichen Erfolge. Selbstverständlich werden aber auch die Jungs von OpenNebula selbst Teil unserer illustren Runde sein und uns an ihrem wertvollen Insiderwissen teilhaben lassen.
Und nu?
Ticket sichern, würd‘ ich sagen 🙂
Ceph Datastore, OpenNebula und Authentifizierung mit CephX
OpenNebula kann Ceph bereits seit Release 4.0 als Datastore einbinden. Wie man die beiden Systeme integriert wird in der OpenNebula Dokumentation beschrieben. Natürlich benötigt man einen laufenden Ceph Cluster und einen Hostsystem der kompatibel dazu ist. Im Augenblick eignet sich hier Ubuntu LTS, da die Kernelversionen neu genug sind um aktuelle Features von Ceph zu unterstützen und zudem ist auch eine aktuelle Version von Ceph in den Repositories.
Neben der gewohnten Installation und Konfiguration eines OpenNebula Nodes muss man noch das Paket ceph installieren, was in den Abhängigkeiten die Libraries für rados und rbd mit sich bringt. Damit man den Ceph Cluster vom Hostsystem ansprechen kann, muss man noch die ceph.conf und den Keyring des gewünschten Users kopieren. Der folgenden Befehl erstellt einen User one mit Zugriff auf den Pool one.
$ ceph auth get-or-create client.one mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=one'
[client.one]
key = aAaaaLaaKaaQaaRaaAaaYaaZaaBaaaaaaaaa==
Als Ausgabe sieht man den Key des Users. Dieser muss in der Datei /etc/ceph/ceph.client.one.keyring auf dem Hostsystem abgelegt werden. `rados -p one –id=one df` sollte jetzt den freien Speicherplatz im one Pool anzeigen. Der User oneadmin sollte lesend auf den Keyring zugreifen dürfen.
Bevor OpenNebula eine VM deployed, wird überprüft ob im Datastore genügend Speicherplatz frei ist. Dazu wird der Befehl `rados df` aufgerufen, komplett ohne Parameter, weshalb der Benutzer client.admin anstatt client.one verwendet wird. Ein Pull Request [1] welcher dies ändert hat es bisher leider nicht in das offizielle Repo geschafft.
Als Workaround kann man entweder zusätzlich den Keyring des client.admin auf dem Hostsystem ablegen oder im Monitor Skript [2] die Parameter des rados Aufrufs um “-p one –id=one” erweitern (angenommen der verwendete Ceph Pool heißt one).
Das alles nur um zu überprüfen ob genügend Speicherplatz im Datastore frei ist. Damit man VMs im Ceph Datastore erstellen kann muss sich auch libvirt gegen CephX authentifizieren. Dies ist aber bereits in der OpenNebula Dokumentation beschrieben.
[1] https://github.com/OpenNebula/one/pull/27
[2] src/datastore/ceph/monitor
Achim Ledermüller
Senior Manager Cloud
