OSDC 2017 – What a great week full of open source!

Over the weekend, we caught up on missed sleep and we were really happy about the successful Open Source Data Center Conference last week in Berlin.

The OSDC 2017 began with our workshop day on Tuesday with „Graylog-Centralized Log Management“, „Mesos Marathon – Orchestrating Docker Containers“ and „Terraform – Infrastructure as Code“.

On Wednesday and Thursday attendees could join 23 interesting talks on case studies, the latest developments and best practices. CONTAINERS AND MICROSERVICES | CONFIGURATION MANAGEMENT | TESTING, METICS AND ANALYSIS and TOOLS&INFRASTRUCTURE were forming the core of the conference! Details about the talks, you can get in Michi’s and Dirk’s Blogposts.

On Wednesday evening, we went to the Umspannwerk Ost. There was much sun, and so we could all sit outside and discuss the exciting days. Furthermore, it was enough time for networking, establishing contacts and becoming more familiar with the open source community!

After the conference was gone on Thursday, we were happy to meet you all in Berlin and also a little bit sad, because three exciting conference days came to an end.

At this point, it is time to say a cordial THANK YOU!

Thanks to our speakers who made us laugh and who gave us so much knowledge!
Thanks to our sponsors for the wonderful support and your confidence!
Thanks to our attendees for making the OSDC unique!

We’ll hope to see you all next year! The date for 2018 is already fixed.

The pictures, slides and videos of the OSDC will be available soon!

OSDC 2018 | June 14 – 16, 2018 | Berlin

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

Einbinden von NWS Icinga 2 Satelliten

Über unsere SaaS Plattform NWS bieten wir seit Beginn die Möglichkeit, Icinga 2 Satelliten Systeme zu betreiben und diese in die eigene Icinga 2 Monitoring Infrastruktur zu integrieren.
Dadurch wird ermöglicht, dass bspw. Webseiten oder andere externe Dienste (Mail, DNS, FTP, etc.) von außen überwacht werden können und die Ergebnisse in das Hausinterne Monitoring übertragen werden.

Hosted man bspw. einen Webshop wie wir (shop.netways.de), reicht es nicht nur zu überprüfen ob die MariaDB oder Apache Dienste funktionieren und die virtuelle Maschine in unserer Cloud verfügbar ist, sondern es ist auch wichtig die externe Sicht der Kunden zu überwachen. Somit erfährt man gleich ob eine externe Erreichbarkeit sichergestellt ist und Kunden bspw. einkaufen können.
In diesem Blogartikel möchte ich beschreiben, wie man den Icinga 2 Satelliten aufsetzt und per Icinga 2 Cluster Protokoll in das eigene Monitoring integriert.

Hat man sich in der NWS Plattform angemeldet, erreicht man über den oberen Reiter “Apps” alle von uns angebotenen Produkte. Nachdem man einen Icinga 2 Satelliten gestartet hat, klickt man auf diese App und folgender Bildschirm erscheint:

(more…)

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

OSDC 2017 als Shop-Event

Letzte Woche haben wir vom NETWAYS Online Store bereits unseren Newsletter live von der OSDC 2017 verschickt. Die Open Source Data Conference fand vom 16.5.-18.5. in Berlin statt und war allgemein ein großer Erfolg. Gut besuchte Workshops, interessante Vorträge und Präsentationen rund um das Thema Rechenzentren und Open Source waren wie immer der Kern der Veranstaltung. Aber auch das Rahmenprogramm, zu dem auch immer eine Abendveranstaltung gehört, konnte sich sehen lassen!

 

 

Der NETWAYS Shop auf der OSDC 2017

Ich selbst durfte zum ersten Mal die Konferenzluft schnuppern und war sofort begeistert von der sehr gut gewählten und zentral gelegenen Location. Das Mercure Hotel MOA in Moabit ist einfach ein sehr besonderes Hotel mit umsichtigem und durchweg freundlichem Service. Unser Eventsteam, geführt von Markus N. hat diese Veranstaltung mit viel Geduld und Spucke einfach gerockt! Vielen Dank für die tolle Unterstützung vor und während der OSDC. So macht Arbeit Spaß!

Wir haben die Gelegenheit bekommen unser Projekt, den NETWAYS Monitor erstmals zu präsentieren. Hardware Made by NETWAYS – das ist neu! Wir haben zum NETWAYS Monitor gute Resonanz erhalten und mit viel Input sind wir wieder in den Büroalltag zurückgekehrt. Jetzt gibt es noch Vieles zu erledigen, bevor der Startschuss zum Verkauf ertönen kann. Hier aber einmal der aktuelle Stand auf einen Blick:

NETWAYS Monitor – Der Netzwerkmonitor zur Umweltüberwachung Ihrer Serverräume und Rechenzentren

  • 4 Anschlussmöglichkeiten für Sensoren über RJ45
  • Sensoren für Temperatur und Luftfeuchte
  • voll SNMP-fähig
  • Webinterface
  • E-Mail Alarmierungen (Login über TLS möglich)
  • weitere Sensoren geplant
  • voraussichtlicher Start des Vorverkaufs im Juni 2017

Braintower auf der OSDC 2017

Ein weiteres Highlight aus Shop-Sicht war die Anwesenheit des Herstellers unserer Braintower SMS Gateways. Ausgestattet mit dem Gateway in beiden Variationen, luden Herr Wiethoff und Herr Hassdenteufel an zwei Tagen dazu ein, das SMS Gateway einmal zu testen. Es gab für uns und die Kunden die Gelegenheit, sich über Neuerungen und anstehende Releases der Software zu informieren. Gemeinsam konnten wir uns zu den Workshopzeiten über die Zukunft der Partnerschaft und aktuelle Kundenprojekte austauschen. Eine Win-Win-Situation für alle Beteiligten!

Isabel Salampasidis

Autor: Isabel Salampasidis

Isabel ist seit Februar zurück bei NETWAYS. Bis 2009 war sie unsere Office Managerin und verstärkt nun ab sofort das Sales Team. Hier ist sie für alle Belange des Online Stores verantwortlich. Der Ein- und Verkauf der Monitoring Hardware sowie die Weiterentwicklung des Shops und seines Portfolios wird sie mit ihrem bekannten Tatendrang gehörig vorantreiben. Privat verbringt die halbgriechische Ruhrpott-Fränkin sehr gerne so viel Zeit wie möglich mit ihren bald 4-jährigen Patensöhnen oder schreit sich für den Club - als stolze Dauerkartenbesitzerin! - die Seele aus dem Leib.

Graphite entlasten mit Carbon Relay (NG)

Graphite ist eine der beiden häufig genutzten Lösungen zum Erstellen von Graphen durch (nicht nur) Icinga 2. Im Gegensatz zu PNP4Nagios, das zusätzliche Software braucht, bringt Graphite mit dem Carbon Cache schon von Haus aus eine Lösung mit, die Daten zwischenspeichern kann, bevor sie auf Platte geschrieben werden. Während eine einzelne Graphite Installation so etliche Datenpunkte in kurzer Zeit “verdauen” kann, so stösst auch Graphite irgendwann an seine Grenzen.

Eine Lösung, die sich bei einigen Setups bewährt hat, ist ein Carbon Relay. Eigentlich dafür gedacht, Daten auf mehrere Carbon Cache Instanzen aufzuteilen, bietet ein solches Relay auch die Möglichkeit, eine weitere Pufferinstanz einzuführen und so noch besser Lastspitzen abzufangen. Sollte das Relay nicht als Pufferinstanz ausreichen, ist damit schon die Grundlage gelegt, Graphite in der Breite zu skalieren.

Zur Auswahl stehen zwei Implementierungen des Carbon Relay, wobei der neuere, Carbon Relay NG genannte, Rewrite in “Go” bisher deutlich bessere Ergebnisse gebracht hat. Zur Installation werden Pakete angeboten, die auch über Repositories zu beziehen sind. Leider stehen keine einfachen Repo-Files, die die Repositories in den Package Manager konfigurieren, zur Verfügung. Statt dessen wird man gezwungen, ein Script auszuführen, das erst Abhängigkeiten installiert und dann ein passendes Repofile zusammenbaut und ablegt. Da ich nicht gern einfach irgendwelche Scripts auf meinen Hosts laufen lassen, habe ich die Anleitung auf einer Wegwerf-VM befolgt, die Schritte auf den eigentlichen Hosts nachempfunden und das Repofile kopiert. Danach reicht auf CentOS 7 ein yum install carbon-relay-ng um das Relay zu installieren.

Leider scheint das Paket noch nicht ausreichend für CentOS 7 angepasst zu sein, weshalb ein paar Nacharbeiten nötig sind: Die beiden Verzeichnisse /var/spool/carbon-relay-ng und /var/run/carbon-relay-ng müssen angelegt werden. Ausserdem braucht die Konfigurationsdatei /etc/carbon-relay-ng/carbon-relay-ng.conf noch ein paar kleinere Anpassungen. Sehr wichtig dabei ist, zwei Leerzeichen in der addRoute Zeile vor dem Empfänger zu verwenden.

instance = "default"
max_procs = 2
listen_addr = "0.0.0.0:2003"
pickle_addr = "0.0.0.0:2013"
admin_addr = "0.0.0.0:2004"
http_addr = "0.0.0.0:8081"
spool_dir = "/var/spool/carbon-relay-ng"
pid_file = "/var/run/carbon-relay-ng.pid"
log_level = "notice"
bad_metrics_max_age = "24h"
validation_level_legacy = "medium"
validation_level_m20 = "medium"
validate_order = false
init = [
     'addRoute sendAllMatch carbon-default  192.168.5.20:2003 spool=true pickle=false',
]
[instrumentation]
graphite_addr = "localhost:2003"
graphite_interval = 1000  # in ms

Dabei ist natürlich 192.168.5.20 durch die IP der Carbon Cache Instanz zu ersetzen.

Leider ist die Dokumentation des carbon-relay-ng aktuell noch etwas dürftig, weshalb einiges an Probiererei gefragt ist, wenn man die Funktionen ausreizen möchte. Zum Probieren und Testen habe ich Vagrant Boxen gebaut, die aktuell nicht viel mehr sind als Prototypen. Wer Erfahrung mit Vagrant und Puppet hat, kann die aber ganz gut als Ausgangsposition nehmen. Wenn sie mal ein bissl ausgereifter sind, wandern die auch aus meinem privaten Github Account in einen “offizielleren”.

Ein grosser Vorteil des Carbon Relay NG ist, dass es nicht nur puffern, sondern die Daten auch sehr einfach auf mehrere Carbon Cache Instanzen verteilen kann. Dazu ändert man einfach den init Teil der Konfigurationsdatei auf folgende Version (auch hier wieder zwei Leerzeichen vor jedem Ziel):

init = [
        'addRoute consistentHashing carbon-default  192.168.5.20:2003 spool=true pickle=false  192.168.5.30:2003 spool=true pickle=false',
]

Dabei wird der cosistentHashing Algorithmus von Graphite verwendet, der Metriken anhand ihres Namens auf verschiedene Instanzen verteilt. Somit kann man ganz einfach die Schreiblast auf beliebig viele Carbon Caches verteilen und stellt sicher, dass die Metriken immer am gleichen Cache ankommen. Am besten funktioniert das, wenn man die Verteilung konfiguriert, bevor zum ersten mal Daten in die Carbon Caches geschrieben werden. Sollte man eine bestehende Installation umziehen wollen, muss man alle bereits angelegten Whisper Files auf alle Carbon Caches verteilen. Also eigentlich nicht alle, da es aber nicht einfach nachvollziehbar ist, welche Metriken der Hashing-Algorithmus wo hin schreibt, ist es sicherer, alle zu kopieren und nach einiger Zeit mit find diejenigen zu suchen und zu löschen, in die schon länger nicht mehr geschrieben wurde. Das sollte man ohnehin regelmässig machen, da Whisper Files von Hosts und Services, die man in Icinga 2 umbenennt oder entfernt, liegen bleiben.

Hat man mehrere Carbon Cache Instanzen als Ziel konfiguriert, muss man sie auch für Graphite-Web nutzbar machen. Viele Addons wie Grafana nutzen die API von Graphite-Web, um auf die in Graphite gespeicherten Daten zuzugreifen, weshalb es naheliegend ist, sämtliche Datenquellen dort zu hinterlegen. Graphite-Web lässt in seiner Konfiguration mehrere Datenquellen zu, wobei 3 davon für uns relevant sind:

  1. lokale Whisper Files
  2. Andere Graphite-Web APIs
  3. Andere Carbon Caches (hier sollten nur die angegeben werden, die auf dem selben Host liegen, wie Graphite-Web, sonst lieber den Umweg über Lösung 2)

Da Graphite-Web üblicherweise so konfiguriert ist, dass es die lokalen Whisper Files verwendet, muss in local_settings.py nur mehr die zusätzliche Graphite Instanz auf dem hinzugekommenen Host konfiguriert werden. (Port 8003 ist hier aus den oben genannten Vagrant Boxen entnommen. Natürlich muss hier konfiguriert werden, wie das andere Graphite Web erreicht werden kann)

CLUSTER_SERVERS = ["192.168.5.30:8003"]

So erreicht man zwar keine Hochverfügbarkeit, aber das liesse sich relativ einfach erreichen, in dem man mehrere Graphite Webs anlegt, die jeweils ihre lokalen Whisper Files und die APIs aller anderen Instanzen konfiguriert haben. Davor einen Loadbalancer, fertig. Auf jeden Fall hat man auf diese Weise aber Carbon Cache in die Breite skaliert, was für grosse Installationen, die vielleicht nicht nur aus Icinga 2, sondern auch aus dem Elastic Stack und collectd Daten erhalten, einige Probleme lösen kann.

Wer jetzt Lust bekommen hat, mehr über Graphite zu erfahren, der sollte sich mal unser Schulungsangebot dazu ansehen.

Thomas Widhalm

Autor: Thomas Widhalm

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool.

OSDC 2017: Community connects

After a fully packed and entertaining first day at OSDC, we really enjoyed the evening event at Umspannwerk Ost. Warm weather, tasty food and lots of interesting discussions, just relaxing a bit and preparing for day 2 🙂

 

Warming up

Grabbed a coffee and started with Julien Pivotto on Automating Jenkins. Continuous integration matters these days and there’s not only Jenkins but also GitLab CI and more. Julien told us why automation for Jenkins is needed. Likewise, “XML Everywhere” makes configuration a bit tad hard. Same thing goes for plugins, you literally can’t run Jenkins without. Julien also told us “don’t edit XML”, but go for example for Groovy and the Jenkins /script API endpoint. The Jenkins pipeline plugin even allows to use YAML as config files. In terms of managing the daemon, I learned about “init.groovy.d” to manage and fire additional Groovy scripts. You can use the Job DSL Groovy plugin to define jobs in a declarative manner.

Julien’s talk really was an impressive deep dive leading to Jenkins running Docker and more production hints. After all an amazing presentation, like James said 🙂

I decided to stay in MOA5 for the upcoming talks and will happily await the conference archive once videos are uploaded in the next couple of days.

Casey Calendrello from CoreOS led us into the evolution of the container network interface. I’m still a beginner with containers, Kubernetes and also how networks are managed with it, so I learned quite a lot. CNI originates from rkt and is now built as separate project and library for Go-built software. Casey provided an impressive introduction and deep dive on how to connect your containers to the network – bridged, NAT, overlay networks and their pros and cons. CNI also provides many plugins to create and manage specific interfaces on your machine. It’s magic, and lots of mentioned tool names certainly mean I need to look them up and start to play to fully understand the capabilities 😉

Yesterday Seth Vargo from HashiCorp had 164 slides and promised to just have 18 today, us moving to lunch soon. Haha, no – it is live demo time with modern secrets management with Vault. We’ve also learned that Vault was developed and run at HashiCorp internally for over a year. It received a security review by the NCC group before actually releasing it as open source. Generally speaking it is “just” an encrypted key value store for secrets. Seth told us “our” story – create a database password once, write it down and never change it for years. And the process to ask the DBA to gain access is so complicated, you just save the plain-text password somewhere in your home directory 😉

Live demo time – status checks and work with key creation. Manage PostgreSQL users and credentials with vault – wow, that simple? That’s now on the TODO list to play with too. Seth also released the magic Vault demo as open source on GitHub right after, awesome!

 

Enjoying the afternoon

We had tasty lunch and were glad to see Felix Frank following up with “Is that an Ansible? Stop holding it like a Puppet!” – hilarious talk title already. He provided an overview on the different architecture and naming schemas, community modules (PuppetForge, Ansible Galaxy) and also compared the configuration syntax (Hash-Like DSL, YAML). Both tools have their advantages, but you certainly shouldn’t enforce one’s mode onto the other.

Puh, I learned so many things today already. I’ve unfortunately missed Sebastian giving an introduction about our very own NETWAYS Web Services platform managed with Mesos and Marathon (I rest assured it was just awesome).

After a short coffee break we continued to make decisions – previously Puppet vs. Ansible, now VMware vs. Rudder, location-wise. I decided to listen to Dr. Udo Seidel diving into “VMware’s (Open Source) way of Container“. VMWare is traditionally not very open source friendly, but things are changing. Most likely you’ve heard about Photon OS serving as minimal container host. It was an interesting talk about possibilities with VmWare, but still, I left the talk with the “yet another platform” feeling.

Last talk for a hilarious day about so many learnt things is about containerized DBs by Claus Matzinger from Crate.io. CrateDB provides shared nothing architecture and includes partitioning, auto-sharing, replication. It event supports structured and unstructured data plus SQL language. Sounds promising after all.

Dirk talked about Foreman as lifecycle management tool in MOA4, too bad I missed it.

 

Conclusion

Coffee breaks and lunch unveiled so many interesting discussions. Food was really tasty and I’m sure everyone had a great time, so did I. My personal highlights this year: Follow-up Seth’s talk and try Consul and Vault and do a deep dive into mgmt and tell James about it. Learn more about Ansible and put it into context with Puppet, like Felix has shown in his talk. As always, I’m in love with Elastic beats and will follow closely how to log management evolves, also on the Graylog side of life (2.3 is coming soon, Jan and Bernd promised).

Many thanks to our sponsor Thomas Krenn AG for being with so long. And also for the tasty Linzer Torte – feels like home 🙂

Thanks for a great conference, safe travels home and see you all next year!

Save the date for OSDC 2018: 12. – 14.6.2018!

 

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉