Select Page

NETWAYS Blog

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
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 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
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.

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
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.

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
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.

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
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.