Virtualisierung stoppen!

Trotz der provokativem Überschrift werde ich einer der letzten sein, der dafür plädiert weniger zu virtualisieren – ganz im Gegenteil. In Zeiten von IaaS, PaaS, SaaS geht eigentlich nichts ohne Virtualsierung. Ob Vollvirtualsierung, Paravirtualisierung oder Container-based-Virtualisierung die Möglichkeiten sind nahezu grenzenlos, die aufsetzenden Frameworks unzählig.
In produktiven Umgebungen mit hoher und unterschiedlichster Workload und viel gemeinsam genutzten Infrastrukturkomponenten bzw. Ressourcen ist es deshalb umso wichtiger einzelne virtuelle Maschinen oder Container zu “stoppen” besser gesagt zu drosseln. Natürlich kann man mit mehr Hardware aufkeimende Engpässe entsprechend ausdehnen. Oft sind aber kleine und ungewollte Verhalten der Auslöser für querschießende Prozesse, die parallel ausgeführte Maschinen beeinflussen und somit die Qualität des generellen Services beeinflussen.
Drosseln kann man u.a. CPU Zeit, Memory, IO auf Blockdevices, IO auf NICs. Wie immer gibt es mehrere Möglichkeiten entsprechende Limits zu setzen. Pauschal lässt sich mit cgroups über die Virtualsierungstechnologien hinweg gut und effizient drosseln. Für KVM bzw. Qemu sind die eingebauten Features die effizientesten. Beim aktiven Drosseln muss der CPU des Hosts entsprechend arbeiten und ist laut IBM hier einen Tick effizienter bei Qemu-capped im Vergleich zu cgroup-capped.
KVM Prozesse können mit libvirt auch zur Laufzeit gedrosselt werden. Die Bandbreite der ersten Festplatte einer KVM-VM würde man mit Hilfe von virsh wie folgt auf 10MB/s und 50iops drosseln:
virsh blkdeviotune $virshid $name --live $total_bytes_sec $total_iops_sec
virsh blkdeviotune 123 vda --live 10240000 50

Das Cloud-Computing Framework OpenNebula wird in seiner nächsten Version ebenfalls Funktionen zur Drosselung bereitstellen.
Wem das alles zu umständlich ist, nutzt einfach das folgende funktionierende aber nicht ganz ernstgemeinte Command:
while true; do kill -STOP $ID; sleep 1; kill -CONT $ID; done

Sebastian Saemann
Sebastian Saemann
Head of 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.

ZFS Replikation mit zrep

Das Dateisystem ZFS wurde ursprünglich von der Firma “Sun Microsystems” entwickelt, die dann später bekanntermaßen von Oracle gekauft wurde. Das sind jetzt keine wirklichen Neuigkeiten und ZFS ist auch nicht neu, aber immer noch in seinen Bereichen das Maß der Dinge. Auf Linux muss man allerdings wegen Lizenzschwierigkeiten von Haus aus darauf verzichten und sich mit dem FUSE Modul oder dem zfsonlinux Kernel Modul Abhilfe schaffen. Für Linux steht ja schon seit langem BTRFS in den Startlöchern, was aber bis heute noch nicht als stable markiert ist.
ZFS ist ein Copy on Write Filesystem, das durch ein reiches Feature Set glänzen kann. Unter anderem unterstützt es Snapshots und kann diese Snapshots inkrementell versenden, um einen Datenzustand als Backup oder für höhere Verfügbarkeit auf einen weiteren Server vorhalten zu können. Das ganze ist denkbar einfach:
zfs snapshot tank/myzfs@1hourago
zfs snapshot tank/myzfs@now
zfs send -I tank/myzfs@1hourago tank/myzfs@now | ssh server2.domain zfs receive tank/myzfsbackup
Die drei Befehle erzeugen zwei Snapshots die dann dann mit “zfs send” inkrementell von “1hourago” bis “now” an den “server2” gesendet und dort empfangen werden. Die Schwierigkeit besteht jetzt darin, Snapshots auch wieder zu löschen und dafür zu sorgen, dass die Snapshots aufeinander aufbauen.
Hierfür gibt es ein KSH Script mit dem Namen zrep. Zrep sorgt sich genau darum und kann noch viel mehr. Neben dem initialen synchronisieren und dem Handling der Snapshots kann mit zrep auch auf den zweiten Server im Fehlerfall geschwenkt werden. Während des Schwenks werden die Filesysteme auf beiden Seiten readonly gesetzt, der letzte Zustand gesynced und anschließend läuft die Replikation in die andere Richtung weiter.
Mehr Informationen zu zrep findet man auf der Website zu dem Projekt.

Sebastian Saemann
Sebastian Saemann
Head of 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.

Sflow Traffic mit Elasticsearch

Das Webinterface zu Elasticsearch “Kibana” wurde vor kurzem in der Version 3.0.0. GA released auch Elasticsearch selbst steht im neuen Glanz mit vielen neuen und nützlichen Features. Viele kennen bereits diese zwei Komponenten vermutlich unter anderem durch den Einsatz von Logstash. Dass man diese zwei Komponenten auch ohne Logstash für diverse Anwendungsfälle gut verwenden kann steht außer Frage.
Wir entwickeln aktuell an einer Ruby-Anwendung, die Sflow Daten empfängt, verarbeitet und an Elasticsearch sendet bzw. dort ablegt. Mit dem Kibana Webinterface lassen sich dann leicht Graphen über die gesammelten Daten auswerten und darstellen. Sflow ist ein Netzwerkprotokoll, dass u.a. Stichproben aus dem fließenden Traffic pickt und diese dann als sogenannte Samples an einen Collector sendet. Die Liste der Collectoren ist lang besteht allerdings meist aus kommerziellen closed-source Produkten.
Generell lassen sich daraus Informationen aufbereiten und ableiten, die zum Beispiel die Top 10 der IP-Adressen auf einem Switch, die den meisten Traffic verursachen oder VLANs die besonders viel Traffic verbrauchen und viele mehr.
Die Anwendung werden wir in den nächsten Wochen auf Github zur Verfügung stellen und in einem weiteren Blogpost darauf aufmerksam machen. Solange gibt es schon mal ein Sneak-Preview in Form von Screenshots 🙂
Bildschirmfoto 2014-03-25 um 14.46.24
Bildschirmfoto 2014-03-25 um 14.46.56

Sebastian Saemann
Sebastian Saemann
Head of 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 Retina

Das Opennebula Release 4.4 Codename “Retina” ist zwar schon einige Zeit verfügbar, aber jetzt hat es auch in unsere Private Cloud geschafft.
Opennebula? Opennebula ist ein Cloud-Framework mit dem man private, public und hybrid Clouds erstellen kann. Wir haben schon in mehreren Blogbeiträgen darüber berichtet.
In der neuen Ausgabe sind folgende neue Features und Verbesserungen hervorzuheben:
– Multiple System Datastores
Hiermit kann man virtuelle Maschinen auf verschiedenen Storage-Backends starten und laufen lassen, was zu einer besseren Lastverteilung in großen Umgebungen mit viel I/O führt.
– EC2 Support
Es gibt einige Verbesserungen was Cloud-Bursting Richtung Amazon anbelangt, vorallem das Template-Handling.
– Sunstone
Das Webinterface hat jetzt verbesserten Apache und Memcached Support und schließt einige Bugs. Auch viele kleine Änderungen wie das Starten des VNC Fensters als losgelösten Tab und ein grafischer Dialog für das Aktualisieren von Templates runden das Bild ab.
Darüber hinaus gibt es natürlich jede Menge Bugfixes und weitere Features die sich auf der Website von Opennebula nachlesen lassen.
Außerdem ist vorallem der problemlose Upgradeprozess einen Satz wert. Unsere produktive Umgebung wurde durchgehend seit Version 3.2 zeitnah aktualisiert und hat nie größere Probleme gehabt von einem Release auf das nächste, sofern man sich an die gute Upgrade-Dokumentation gehalten hat.
In den kommenden Wochen gibt es bei uns wieder ein Webinar zum Thema Opennebula, die genauen Termine folgen.

Sebastian Saemann
Sebastian Saemann
Head of 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.

Docker

Die Devops-Tool-Chain hat seit einiger Zeit ein sehr interessantes neues Tool mit dem Namen “Docker”. Docker erfährt einen regelrechten Hype um sich, wobei die Meinungen um das Tool durchaus gemischt sind. Einen Blick ist es auf jeden Fall Wert. Aber was ist Docker eigentlich?
Docker ist ein Open-Source-Framework, das leichtgewichtige, portable, LXC-Container bereitstellt und steuert, die praktisch überall laufen können. Eine Anwendung kann also problemlos auf einem Laptop des Entwicklers, oder in großen Produktionsumgebungen auf Bare-Metal oder in der Cloud laufen. Das mit dem überall beschränkt sich dann aber doch auf einen Linux-Kernel mit LXC, aber das wiederum kann praktisch überall laufen. Die Use-Cases sind die Automatisierung von Deployments, das Bereitstellen von PaaS/SaaS Services, automatisierte Continuous-Integration-Tests und die Skalierung von Anwendungen. Spätestens jetzt ruft der erste “Bingo” beim Buzzword-Bingo.
In anderen Worten ist Docker ein Tool, vergleichbar mit Vagrant, mit dem sich Anwendungen einfach über Umgebungen hinweg portieren lassen.
docker run ubuntu /bin/echo hello world
Tatsächlich ist das aufgezeigte Beispiel vielleicht etwas ernüchternd: es gibt bei Erfolg lediglich “hello world” auf einer neuen Zeile zurück. Tatsächlich passiert aber viel mehr. Das Image ‘ubuntu’ wird heruntergeladen – wenn es nicht bereits lokal vorhanden ist – und in einem LXC-Container gestartet. In diesem wiederum wird /bin/echo ausgeführt und anschließend beendet sich der Container wieder.
Ein Container wird immer aus einem Image erzeugt und läuft so lange die Anwendung läuft – wird diese beendet, beendet sich auch der Container. Images sind über Repositories, bei Bedarf auch eigenen Repositories, verfügbar. Ähnlich wie mit Git lassen sich diese Images steuern. docker commit, docker pull, docker push erstellen neue Images und laden diese hoch bzw. runter.
docker run -i -t ubuntu /bin/bash
docker commit $ID my_fancy_app
docker run -p 80:3000 my_fancy_app rails server

In dem Beispiel wird ein LXC-Container mit Ubuntu gestartet mit einer interaktiven Shell. In der Sitzung installiert man seine Anwendung. Eleganter ist ein Dockerfile, dass das automatisch vornimmt. In dem Beispiel wird eine Ruby-on-Rails-Anwendung installiert und mit dem commit Befehl anschließend ein neues Image erzeugt. Nebenbei bemerkt: docker diff zeigt den Unterschied zum initialen Container. Abschließend wird das neue Image in einem neuem Container mit einer Portweiterleitung von 80 auf 3000 und der Anwendung (Webrick) gestartet. Die Anwendung ist dann unter der $IP:80 auf dem System, dass den Container hosted, verfügbar. Die Anwendung bzw. der Container kann jetzt beliebig oft sekundenschnell gestartet werden, solange der Netzwerkport natürlich nicht doppelt belegt wird. Der Container ist jetzt in der Lage auf jedem System gestartet zu werden, dabei ist es egal ob es eine Amazon AWS VM, KVM/XEN VM, Bare-Metal oder Virtualbox(Vagrant) ist.
Seine Container kann man auch mit Puppet steuern, verteilen und starten.
docker::run { 'my_app':
image => 'my_fancy_app',
command => 'rails start',
ports => ['80', '443'],
}

Zusammenfassend ist Docker ein geniales Framework für einige bestimmte Anwendungsfälle. Ich bin begeistert.
Mehr Information findet man auf docker.io

Sebastian Saemann
Sebastian Saemann
Head of 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.

Sekundengenaue Graphen mit Quickstatd und Graphite

Für die Analyse von Performance-Werten bzw. der Auslastung von Linux-Servern greift man meist unter anderem auf die “Sysstat”-Sammlung zurück, um sich einen raschen Überblick der Stati von Netzwerk,CPU und Co. zu verschaffen: iostat, vmstat, sar usw.
Für eine Momentaufnahme ist der Aufruf über die Kommandozeile auf einem Server auch übersichtlich genug, um sich ein Urteil bilden zu können. Vergleicht man jedoch Werte über einen oder mehrere Zeiträume hinweg und ggfs. auch noch auf mehreren Servern, da sie gemeinsam ein Cluster, eine Cloud, ein Storage bilden oder sonst in irgendeiner Abhängigkeit stehen, wird es umständlich und eine andere Lösung muss her. Ein Graph!
In der Regel werden Performance-Daten über das Monitoring-System und dessen Checks gesammelt und zu einem Graphen visualisiert, den man dann ansehen und für sich interpretieren kann. Der Informationsgehalt ist meist ausreichend, da man über einen längeren Zeitraum betrachtet Änderungen oder Abweichungen, z.B. einen Anstieg, leicht erkennen kann. Bei schnellen Änderungen in kürzeren Zeiträumen kann ohne Anpassungen die eine benötigte Information leicht untergehen und im Durchschnitt verschwinden.
Für eine sekundengenaue- und einer Live-Ansicht von Performance-Graphen habe ich gestern eine leichtgewichtige Lösung ausprobiert: Quickstatd. Quickstatd ist ein kleines und einfaches Tool, bestehend aus Bash- und Gawk-Skripts, dass Sysstat-Daten parsed und direkt an Graphite weiterreicht. Damit ist der Funktionsumfang auch schon gänzlich beschrieben 🙂 Im Prinzip ist die Funktionsweise ein Aufruf wie folgt:
"sar -n DEV 1 | gawk -f /script/in/dem/die/Werte/geparsed/werden | nc mein.graphite.host 2003"
Mit Sar werden jede Sekunde, im vorangegangen Beispiel die Netzwerkaktivität, an gawk gepiped. Das wiederum parsed die Werte und schreibt sie im Graphite-Format (Bezeichnung Wert Timestamp) an Stdout bzw. piped es weiter an Netcat. Netcat wiederum schickt den String an den Graphite-Collector. In Graphite muss nur noch das Storage-Schema auf die sekundengenaue Speicherung der Werte angepasst werden und et voilà hat man sekundengenau Live-Graphen.
Bildschirmfoto 2013-08-09 um 12.42.37

Sebastian Saemann
Sebastian Saemann
Head of 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.

Kölner Puppenkiste

Letzte Woche habe ich als Trainer der “Puppet Fundamentals” Schulung drei Tage in Köln verbracht. Das Training wurde im sehr zentral gelegenen und gut zu erreichenden “Hotel am Augustinerplatz” durchgeführt. In dem Zimmer, das ich zur Verfügung gestellt bekommen habe, gab es sogar einen exklusiven Blick auf das Kölner Wahrzeichen.

Kölner Dom

Kölner Dom


Das “Puppet Fundamentals” Training umreißt über drei Tage folgende Themen und ist für Puppet Einsteiger wie auf den Leib geschnitten:
Tag 1
• Courseware Overview
• About Puppet
• Why Puppet
• The Classroom Environment
• Modules and Classes
• Puppet Agent & Puppet Master
• Reporting
Tag 2
• Resources
• Resource Relationships
• Language Constructs
• ERB Templates
• Defined Resources
Tag 3
• Advanced Classes
• Puppet Forge
• Puppet Enterprise
• Live Management
• Troubleshooting & Best Practices
• Capstone Lab
• Future Visions
• Course Conclusion
Neben knallharter Puppet Theorie und dazu aufbauenden praktischen Übungen gab und gibt es natürlich, wie bei jedem Netways Event, reichlich und gutes Essen. In dem benachbarten Steakhouse wurde für alle Teilnehmer jeweils ein Tisch für Mittag- und Abendessen reserviert. Die Abendveranstaltung fand im “Gaffel am Dom”, einem traditionellen Kölner Kölsch Brauhaus, statt. Unser dortiger Köbes hat seinen Job sehr ernst genommen und solange Kölsch bei einem gerade erst leer gewordenen Glas nach serviert bis man seinen Bierdeckel auf das leere Glas gelegt hat.
Das Feedback meiner Teilnehmer war nach den drei Tagen auch durchweg positiv und hoffentlich nicht nur wegen dem guten Essen. Mehr Schulungen und auch weiterführende Puppet Schulungen findet man auf unserer Homepage.

Sebastian Saemann
Sebastian Saemann
Head of 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.

Train the Trainer

Letzte Woche war ich zusammen mit meinem Kollegen Thomas in Amsterdam zur Puppetlabs Schulung “Train the Trainer”. In fünf Tagen wurden uns die neuen Schulungen und Schulungsunterlagen gezeigt, sowie viele technische Raffinessen Rund um Puppet und dessen Erweiterung.
Die Schulungen, die uns im Fast-Forward Modus – Tom meinte dazu “Druckbetankung” oder im lokalen Amsterdamer Jargon ausgedrückt “Soviel Stoff bis einem der Kopf raucht” – gezeigt wurden, sind:
Puppet Fundamentals
Puppet Advanced
Extending Puppet using Ruby
Alle drei Schulungen sind natürlich bei uns auch im Schulungsangebot zu bestaunen und vor allem zu buchen. Die nächste Schulung findet in Köln vom 23. – 25. April statt. Die Nachfrage ist groß also schnell zugreifen. Man sieht sich dann in Köln!

Sebastian Saemann
Sebastian Saemann
Head of 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.

London Calling

Heute und morgen ist die Cloud Expo Europe in London. Bernd und ich sind vor Ort und folgen den vielen interessanten Vorträgen. Bernd hatte seinen Vortrag als einer der ersten und stellte unsere private Cloud auf Basis von OpenNebula dem Publikum vor und demonstrierte die Weboberflächen (Sunstone,Ozones,SelfService) mit abschließenden Live-Migrate einer produktiven virtuellen Maschine.
cloudexpo
Aktuell nutzen wir die Gelegenheit bei einem der Gründer, Chris C. Kemp, von Openstack mehr über dessen Lösung zu erfahren.

Sebastian Saemann
Sebastian Saemann
Head of 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.

Rückblick auf ein Jahr mit der Cloud

Laut den Mayas geht 2012, also schon in ein paar Tagen, die Welt unter! Bevor es zu spät ist möchte ich deshalb noch die Gelegenheit nutzen über das vergangene Jahr, insbesondere über die Erfahrungen mit OpenNebula als private Cloud, zu berichten.
Zum Jahresbeginn starteten wir mit dem Ziel eine private Cloud für uns und unsere Kunden in unserem Rechenzentrum betreiben zu können. Am Ende der Evaluierungsphase stellte sich OpenNebula für uns als die richtige Lösung dar und bis jetzt haben wir die Entscheidung noch nicht bereut. OpenNebula ist ein starkes Open-Source Projekt, dass sich besonders durch seine stetige und rasante Weiterentwicklung auszeichnet. Mittlerweile ist das Projekt auch regelmäßiger Gast auf unseren Konferenzen und OpenNebula wurde mit in unser Schulungsportfolio aufgenommen. Die gute Partnerschaft zwischen uns und OpenNebula hält für das kommende Jahr voraussichtlich noch einige Überraschungen parat. Selbstverständlich erfährt man auf unserem Blog als Erster davon – solange die Gerüchteküche nicht schneller ist.
Unsere private Cloud ging mit der Version 3.2 in den Produktivbetrieb. Das Setup ist so ausgelegt, dass jeder Host sowohl ein Wirt-System als auch das OpenNebula-Frontend als Rolle übernehmen kann. Die Logik übernimmt hierfür Pacemaker auf Basis von Corosync. Das zentrale Storage war zu Beginn ein iSCSI-Export mit OCFS2, das in der Betaphase auch jeden Failover-Fall mitgemacht hat, sobald es allerdings produktiv war, kam es zu nicht deterministischen Problemen, weshalb wir in einer nächtlichen Wartung das OCFS2 durch NFS ersetzt haben.
Ein weiteres Problem trat auf als der Dienst libvirtd, mit dem OpenNebula die VMs auf den Hosts überwacht und bei Bedarf auf einem anderen Node neustartet, seinen Dienst auf einem Host mit Segfault quittiert hat. Daraufhin hat OpenNebula die vermeintlich als down deklarierten VMs doppelt auf den anderen Hosts gestartet. Aufgrund dessen haben wir uns einen Ressource Agent zur Überwachung von libvirtd geschrieben und diesen mit in die Kontrolle von Pacemaker übergeben. Würde das Problem wieder auftreten würde Pacemaker den entsprechenden Host mit allen VMs und Diensten mit Hilfe von STONITH hart neustarten (Strom aus).
Auf die Resource Agents ist leider auch nicht immer Verlass. Nach einem System Update wurde der RA, der sich um das STONITH kümmert, vom Paketbetreuer mit einem Syntaxfehler im Bash-Skript ausgerollt, was natürlich erst auffiel, als ein Host gefenced werden sollte.
Zu guter Letzt gab es natürlich immer noch das berühmte Layer 8 Problem. Auf Details verzichte an dieser Stelle aber lieber 🙂
Zusammenfassend kann man also sagen, OpenNebula hat sich verhalten wie es soll und es hat eher die Infrastruktur drum herum bzw. die Software Probleme gemacht. Nach der Fehlerbeseitung der Kinderkrankheiten läuft unsere private Cloud nun performant und sehr zuverlässig. Auch das Update auf 3.4, mit dem die multiplen Datastores eingezogen sind, und später auf 3.6 waren ohne größeren Komplikationen möglich.
Mittlerweile hat sich die Anzahl unserer Wirt-System verdoppelt und auch die Anzahl an produktiven VMs nimmt stetig zu. Die Erweiterung der Cloud um weitere Host-Systeme ist dank Puppet und den hierfür geschriebenen Puppetmodulen einfach und schnell möglich. Hosts von VMs via Livemigration zu befreien, um Wartung am Host-System vornehmen zu können (Livemigration), Ressourcen-Allozierung (CPU,Memory,Quotas) und die sekundengenau Berechnung der benötigten Ressourcen für das Accounting sind nur einige herausstechende Funktionen, die uns die Arbeit erleichtern und neue Möglichkeiten zur Administration bereitstellen.
Unser Auszubildender Marcus hat uns für seine Abschlussprüfung eine kleine Cloud als Staging-Umgebung und Spielwiese zur Verfügung gestellt, so dass wir zukünftig Updates und Features vorher ausgiebig testen können. Mit Ozones ist dann auch die zentrale Steuerung mehrerer Clouds möglich.
Zukünftig stehen natürlich weitere Updates aus, sowie die Möglichkeit unseren Kunden Zugriff zu gewähren und hoffentlich auch der stetige Ausbau der Cloud-Infrastruktur durch Neukunden und Wachstum unserer bestehenden. Die Aussichten sehen jedenfalls gut aus.
Insgesamt und trotz der anfänglichen Schwierigkeiten ist das Projekt “private Cloud” ein voller Erfolg und OpenNebula hat sich für uns als eine sehr gute Wahl entpuppt.

Sebastian Saemann
Sebastian Saemann
Head of 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.