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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

Puppet und sein Bauleiter: The Foreman

Foreman ist ein mächtiges Life-Cycle-Management-Tool, dass Puppet perfekt ergänzt. Es kümmert sich hierbei im Gegensatz zu Puppet nicht um die Konfiguration, sondern eher um den Lebenszyklus diverser Hosts, dabei ist nebensächlich ob es sich um virtualisierte Systeme oder echte Hardware handelt.
Foreman kann man auf verschiedene Weise nutzen. Als besseres Puppet-Dashboard, External-Node-Classifier, CMDB oder komplett mit Foreman-Proxys, die sich z.B. um DNS, DHCP, PXE und TFTP kümmern können.
In anderen Worten mit Foreman kann man über wenige Klicks einen neuen Host anlegen, welcher dann über PXE-Boot installiert wird und anschließend seine Pakete und Konfiguration via Puppet erhält. Um das ganze abzurunden werden bei Bedarf auch gleich noch DNS Einträge inklusive der oft vergessenen Reverse-Einträge erstellt und auf den konfigurierten DNS-Server gepushed.
Das ganze funktioniert mit allen gängigen Distributionen. Debian, Ubuntu, Suse, CentOS, RedHat.
Das geniale an Foreman ist, dass es sehr flexibel strukturiert ist, so dass man auch leicht Anpassungen vornehmen kann (Partitionslayout etc.) – für die gewisse Extrawurst 🙂

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.

Stolz wie Oskar

Immer wieder war OpenNebula auf unserem Blog oder Events ein Thema. Jetzt dreht sich der Spieß, denn wir sind Thema auf opennebula.org. Deshalb reiht sich Netways ganz standesgemäß in die Liste der OpenNebula-User neben “Telefonica”, “Dell”, der “European Organization for Nuclear Research” und der “European Space Agency” ein. Nicht schlecht, oder? 🙂
Einfach mal selbst gucken und sich überzeugen.
Ein stolzer OpenNebula User

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.