Happy Birthday NWS!

Es begann, wie so oft bei großen Dingen, in kleiner Runde. DevOpsDays 2015 in Ghent: Man sitzt zusammen, unterhält sich, lässt den Gedanken freien Lauf und plötzlich beginnen sie sich zu formen. In diesem Fall nehmen sie die Form einer Plattform an. Die NWS-Idee ist in den Köpfen!

Commit, Beta, live

Die NETWAYS Web Services (NWS) sollten ein SaaS Angebot sein, das seinen Nutzer*innen auf kürzestem und simpelstem Weg binnen weniger Minuten Zugang zu den passenden Open Source Anwendungen verschafft. Also machen sich die unerschrockenen NETWAYS Engineers im Oktober 2015 auf den Weg, und basteln, bauen, schrauben und testen…

  • 27.10.2015: Einer der Gründer erstellt den ersten Commit
  • OSMC 2016: Ein kleiner Kreis eingeweihter Experten sieht die Beta und gibt sein „Go“
  • März 2017: Es ist so weit: NWS geht live!

Zum Icinga 2 Satellite und Icinga 2 Master, zu Nextcloud und Rocket.Chat gesellen sich bald GitLab, RequestTracker, SuiteCRM, der Web Accelerator und 2018 zieht mit Pauken und Trompeten die Open Infrastructure Queen-OpenStack nach.

My favourite Engineers

Heute sitzen im NWS Team die Experten für alles: Programmieren, Betrieb, Rechenzentrum, Web Hosting, Storage Cluster, Cloud, DevOps, Hype. Sie bauen neue Setups und sind Support. Mehr noch: MyEngineers! Sie kümmern sich um Laufendes und künftige Software as a Service Angebote. Sie maßschneidern Open Infrastructures auf Basis von OpenStack.

Das heißt vor allem: NWS Kunden können sich voll auf ihr Business konzentrieren, ohne sich den Kopf über IT Dinge zu zerbrechen. Und haben immer einen Ansprechpartner, der sich auskennt. Wer’s nicht glaub kann sich selbst überzeugen: Die ersten 30 Tage NWS SaaS sind kostenfrei – kein Haken an der Sache. Isso.

Du willst gratulieren? Die Engineers freuen sich definitiv über deinen Besuch auf ihrer Plattform nws.netways.de und Glückwünsche auf Twitter @NetwaysCloud

Ein Hoch auf zwei Jahre NWS! Alles Gute und weiter so!

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

AJAX mit Ruby on Rails und :remote => true

Mit :remote => true bietet das das Ruby Webframework Rails eine sehr einfache Methode um mit Hilfe von AJAX eine Webseite zu aktualisieren. Dieses kann z.B. einfach zu HTML-Elementen wie Formulare, Buttons, Links und Checkboxen hinzugefügt werden. Dadurch werden z.B. gefüllte Formulare nicht mehr wie gewohnt an den Webserver gesendet, sondern mit AJAX. Man erspart dem Benutzer dadurch einen lästigen ggf. langwierigen Seitenaufbau. Im Gegenzug muss man sich aber selber um eine Aktualisierung der Webseite mit Hilfe von jQuery oder JavaScript kümmern.

Folgender Code in einem View erstellt eine Checkbox welche bei einem Klick mit Hilfe von AJAX einen HTTP Post an die angeben URL sendet:

check_box_tag( 
  "my_checkbox", "i_am_checked", false, 
  data: { 
    remote: true, 
    url: "my_checkbox/click", 
    method: "POST" 
  }
)

Der Request muss in diesem Fall vom my_checkbox Controller angenommen und verarbeitet werden. Um die Ansicht des Benutzers zu ändern schickt man mit den bekannten Rails Methoden Javascript an den Browser zurück. Im my_checkbox_controller.rb erweitert man z.B. die respond_to einfach um ein format.js:

def click
  respond_to do |format|
    format.js {}
  end
end

Der dazugehörigen View (click.js.erb) wird somit an den Browser zurück gesendet und man kann per JavaScript die Webseite aktualisieren:

console.log('I am the response!')
alert('You clicked the checkbox!')

Rails bietet mit :remote=>true somit eine wirklich einfach Methode um AJAX für seine Webseite einzusetzen!

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Monthly Snap November


 
Remember one month ago? The first talks were about to start soon, you had your first coffee, enjoyed the rich Holiday Inn breakfast, took your journal, in which you had your plan for the day scetched, you were happy to meet an old friend in the hallway on your way to Saal Jacobi, where Bernd Erk was preparing to kick-off OSMC. …
OSMC – good times! Take some of its spirit with you into the cold and dark december days and let it warm your heart like a cup of hot Christkindlesmarkt mullet wine.

Form OSMC to Open Infrastructure

How? Make yourself a cup of hot wine and read through OSMC 2018 – Day 1 and OSMC 2018 – Day 2 by Dirk, or OSMC 2018 – or: The Thirteen-Star Conference, in which our attendees share their experiences. Read Michi’s Hackathon stories and Dirk’s report about OSCAMP on Puppet. You’re more of a visual type?  Browse through our OSMC Archive and find all the videos, pics and slides.
Right after OSMC our NWS-Team hit the road to Berlin for OpenStack Summit. Check out their managed Open Infrastructure service at nws.netways.de – now with MyEngineer support!

Icinga Seminar & Berlin Camp

Lennart Betz continues his blogpost-seminar Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile and Teil 10: Profile Part II. Join the Icinga community in 2019: Icinga Camp Berlin: Call for Papers is running until Decemeber 31! Find all November Icinga updates here.

For the tech hearts

Achim tell you to Get your RadosGW metrics into Ceilometer. Loei explains the use and functionality of RFID & NFC. Niko shares Neuheiten beim IntelliJ-Update. Tim knows Ceph Mimic | Using loop devices as OSD
In git gud! Henrik tells the story of: How I Learned to Stop Worrying and Love my Code. Noah introduces you with GitKraken to a nearly perfect Git-Client, while Johannes shares another useful tool: PDF manipulieren mit pdftk.

Presents

In November Silke announced Black Friday mal ganz in Orange – Es darf gespart werden und Die neue Generation der SMSEagle NXS-97xx Linie stellt sich vor. It‘s always a good idea to check our Shop for special offers. Especially if you are looking for Christmas presents. In that sense: Entschleunigung vom Weihnachtsstress bei Netways!
Have a wonderful December and Christmas season! Stay tuned!

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

DevOpsDays Berlin 2018 Recap

The sixth iteration of DevOpsDays Berlin is almost over and we would like to give you a little recap of what was offered.
This years conference was divided into two parts. The first half of both days focused on the single track talks and the second half was dedicated to Open Spaces and workshops.
We’ll only go over the 8 main talks that where presented on the single track stage, because we could not visit all the Open Spaces and workshops.

Day 1

Peter Chestna – Full Spectrum Engineering – The new Full Stack for 
Developers need to adapt – was the core idea of Peters talk. He explained how the typical software dev of the past has to evolve into a specialist in full spectrum development. Now a developer must become fluent in software testing, deployment, telemetry and even security. We have to adapt both in mind- and skillset in order to improve in our ever changing IT world.
Jessica Ulyate – Platform: How to Product?
The keyword in this talk was: product management (in DevOps).
She described in which ways to structure the communication flow between the developers and the stakeholders to efficiently get to a successful product.
Philip Smyth – Shifting ownership of code quality to developers
In short he talked about how developers should do more QA; and QA should get more into development and how his company basically merged those two departments. He described how this practice improves the workflows and makes working towards a product more efficient and focused.
Subhas Dandapani – DevOps as a Contract
Subhas talked about different areas in infrastructure and how they tried to remodelled everything into contracts. He showed us some approaches his company tried out, how they improved and where they are still struggling.
Ignite talks:

Day 2

Dirk Lehmann – Trust as foundation of DevOps
The one of the most important things when it comes to working together is – trust, according to Dirk Lehmann. In his talk he explained the principles you should strive for when working together in an organisation, be it big or small – in one location or spread over the globe.
Yuwei Ren – Mentorship: From the receiving end
In her talk she elaborated how to improve mentorship – both from the sides of the mentor and the mentee. She took us on her journey from starting university, over several internships to becoming a professional developer. The focus was on what she did, could have done better and what her advice would be for the mentors.
Ken Mugrage – Want to successfully adopt DevOps? Change Everything.
It’s usually not enough to rename a team, you should also think about restructuring the organisation itself. He stressed the different definitions of DevOps and the variety of approaches – in order to make us, the audience, think about how we could improve our systems.
Tiago Pascoal – Don’t make the same mistakes we made in our Devops journey
Tiago gave us brief overview over the past developments in DevOps culture at Microsoft Azure. He highlighted the pros and cons of the approaches Microsoft tried out, including: team structure, balance of alignment and automation, CI/CD, development cycles and many more.
Ignites of the day:

As always, DevOpsDays Berlin was an awesome event with very informative talks and a meet-up of wonderful people with the same mindset.
We hope everyone who was here with us enjoyed it as much as we did and would be happy to see the community again next year.
If you want to be part of this community, feel free to join us in 2019!
For more information on the event visit the DevOpsDays Berlin homepage.
 
Written in collaboration with Noah Hilverling 🙂

Bursting und Throtteling in OpenStack

Wir haben die vergangenen Monate genutzt, um eine neue Cloud mit OpenStack aufzubauen. Im Zuge dessen, mussten wir eine Möglichkeit finden, die IOPS sowie die Bandbreite, die VMs zur Verfügung haben, zu limitieren.
Das Limitieren der Bandbreite sowie der IOPS erfolgt in OpenStack in sogenannten Flavors. In einem deutschsprachigen Interface von OpenStack werden diese “Varianten” genannt. Flavors werden hier als VM-Templates genutzt, mit denen sich VMs starten lassen. Es werden hier Ressourcen geregelt wie RAM, CPU und Firewallregeln aber eben auch die Limitierungen. Gesetzte Werte können nicht in laufenden VMs überschrieben werden. Möchte man diese ändern, muss die VM gelöscht und neu gebaut werden, nachdem die neuen Werte im Flavor angepasst wurden. Ein Rebuild reicht hier nicht aus.
Hier gibt es jedoch eine Ausnahme. Durch den Einsatz von beispielsweise libvirtd, können jene Beschränkungen mittels “virsh” angepasst werden.

Was sind IOPS und Bandbreite?

Bandbreite und IOPS geben an, wieviel Datendurchsatz sowie Lese und Schreiboperationen einer VM zugeteilt sind. Per Default sind diese unlimitiert, was unter gewissen Umständen zu Problemen führen kann.

Wieso sind Limitierungen sinnvoll?

In einer Cloud mit mehreren Virt-Systemen laufen mehrere VMs. Sind keine Limitierungen gesetzt, kann jede VM soviel Traffic und IOPS erzeugen, wie sie gerade braucht. Das ist natürlich für die Performance entsprechend gut, jedoch verhält es sich dadurch so, dass andere VMs auf dem gleichen Virt entsprechend unperformanter werden. Limitierungen werden daher dazu genutzt ein gleiches Niveau für alle VMs zu schaffen.

Bandbreite

Average

  1. quota:vif_inbound_average
  2. quota:vif_outbound_average

Wie der Name schon sagt, beschränkt man hier inbound (eingehenden) sowie outbound (ausgehenden) Traffic durch einen durchschnittlichen Wert, den diese beiden nicht überschreiten dürfen.

Peak

  1. quota:vif_inbound_peak
  2. quota:vif_outbound_peak

Die Bandbreite kann man auch mit Peak sowie Burst begrenzen. Peak gibt hierbei an, bis zu welchem Limit die Bandbreite genutzt werden darf, als absolutes Maximum. Dieser Wert funktioniert aber nur in Zusammenarbeit mit “Burst”.

Burst

  1. quota:vif_inbound_burst
  2. quota:vif_outbound_burst

Burst gibt nämlich an, wie lange die Bandbreite im Wert “Average” überschritten werden darf. Gemessen wird hier in KB. Setzt man also den Burst auf 1.048.576 KB, darf der Peak Wert solange genutzt werden, bis 1GB (1.048.576 KB) an Daten übertragen wurden. Zu Beachten ist aber, dass dieser Wert für jeden Zugriff neu gilt. Führt man also 3 Kommandos hintereinander aus (3x wget mit && verknüpft) greift der Burst für alle 3 gleichermaßen. Führt man die gleichen Kommandos ebenfalls hintereinander aus, aber verknüpft diese mit einem Sleep, greift der Burst für jedes Kommando neu.
 

IOPS

Throttle

  1. quota:disk_read_iops_sec
  2. quota:disk_total_iops_sec
  3. quota:disk_write_iops_sec

Die lesenden und schreibenden Prozesse der VMs können natürlich auch begrenzt werden. Hier gibt es zwei Möglichkeiten:

  • Limitierung von lesenden sowie schreibenden Prozessen separat
  • Limitierung auf absoluten Wert

Beides in Kombination geht nicht. Es nicht möglich zu konfigurieren, dass es 300 lesende, 300 schreibende und 700 insgesamte IOPS geben soll, würde aber auch keinen Sinn machen. Zu beachten ist, wenn alle 3 Werte gesetzt werden, können diese in einen Konflikt geraten und gegebenenfalls gar nicht greifen.

Burst

  1. quota:disk_write_iops_sec_max
  2. quota:disk_write_iops_sec_max_length

Durch das Bursting auf den Festplatten direkt, kann angegeben werden, mit welcher maximalen Anzahl an IOPS (quota:disk_write_iops_sec_max)eine VM die oben gesetzten Werte, für wie lange (quota:disk_write_iops_sec_max_length) überschreiten darf. Sinnvoll wäre dies, wenn bekannt ist, dass gewisse Prozesse kurzzeitig mehr IOPS benötigen, als freigegeben ist.

Beispiele

Um Limitierungen zu setzen, wird zunächst ein Flavor benötigt. Im Anschluss können die Werte gesetzt werden. Die Dokumentation zum Anlegen von Flavors gibts hier
openstack flavor set {$flavor} --property quota:{$param}={$value}
quota:disk_read_iops_sec='200'
(quota:disk_total_iops_sec='1000')
quota:disk_write_iops_sec='200'
quota:vif_inbound_average='10240'
quota:vif_inbound_burst='20480'
quota:vif_inbound_peak='15360'
quota:vif_outbound_average='10240'
quota:vif_outbound_burst='20480'
quota:vif_outbound_peak='15360'
quota:disk_write_iops_sec_max_length='10'
quota:disk_write_iops_sec_max='1000'
In diesem Beispiel würde man zum Beispiel die lesenden Prozesse auf 200 (quota:disk_read_iops_sec='200') beschränken, ebenso die schreibenden, bei einer eingehenden Brandbreite von 10MB(quota:vif_inbound_average='10240'). Peak liegt bei 20MB und darf für 15MB erreicht werden. Das ist natürlich ein sehr unrealistisch minimalistisches Begrenzungsbeispiel, jedoch sollte die Art und Weise wie es funktioniert verdeutlich worden sein.

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Wie überwache ich eine Cluster-Applikation in Icinga 2?

Vor dieser Frage stand ich neulich bei einem Kunden. Und dank dem Rat netter Kollegen kam sogar eine ansehnliche Lösung hervor. Wer kennt das nicht – Applikationen, die in einem Linux-HA Cluster laufen worauf über eine Cluster-Virtual-IP zugegriffen wird. An diese VIP-Ressource sind der Applikationsprozess und womöglich eingehängter Speicher als weitere Cluster-Ressource angeknüpft. Somit sprechen wir von zwei Cluster-Ressourcen, die mit einer Cluster-Ressource der VIP verknüpft sind. Diese Abhängigkeit definiert, dass die Anwendung immer nur auf einem aktiven Cluster-Node im zugewiesener VIP laufen kann. Dies ergibt einen Active und einen Passive Node (in unserem Fallbeispiel!)
 

Was bedeutet das genau?

Die Cluster-VIP kann von Active zum Passive Host anhand von Fehler-Kriterien geschwenkt werden. Somit schwenkt der gesamte Betrieb der Applikation vom aktiven Host auf den passiven Host. Dort wird der Applikationsprozess gestartet und die Disk eingehängt. Würden wir jetzt einfach auf beiden Servern neben den System-Standards noch die Applikation gezielt überwachen, würden wir auf einem der beiden Nodes für den fehlenden Prozess und die fehlende Disk immer den Status “Critical”  bzw. den Status “Unknown” beim Ausführen des Disk-Checks zurückbekommen.
 

Lösung!

Um eine Überwachung über die Cluster-VIP zu realisieren, verwenden wir ein eigenes Plugin welches als Wrapper fungiert. Der Check verwendet die Cluster-VIP als Parameter und überprüft ob diese an einem lokalen Interface konfiguriert ist. Wird an einem Interface die Cluster-VIP-Ressource zugewiesen, führt das Plugin den eigentlichen Check aus. Dieser wird als zweiter Parameter übergeben und entspricht dem Namen des Checks, z.B. “check_disk”. Durch den Aufruf des Kommandos mit dem Argument “$@” werden alle Parameter des Wrapper-Scripts an das Plugin übergeben.
 

Plugin-Skript

#!/bin/bash
#
# License: GPLv2, Copyright: info@netways.de NETWAYS GmbH
#
#
plugin_dir=${0%/*}
VIP="$1"
vip_exists=`ip a|grep " inet ${VIP}/"`
echo $vip_exists
shift
command="$1"
shift
if [ ! "$vip_exists" ]; then
  echo "YES! VIP down & I'm STANDBY" && exit $OK
fi
exec ${plugin_dir}/${command} "$@"

Sollte auf einem Cluster-Node die Cluster-VIP nicht zugewiesen sein, gibt der Check den Status “OK” und den Plugin-Output “YES! VIP down & I’m STANDBY” zurück.
 

Einrichten des Check-Commands

Nun können wir dieses Plugin im PluginDir-Pfad auf dem zu überwachenden Host ablegen. Zusätzlich benötigen wir noch ein CheckCommand, welches das Wrapper-Script aufruft und dann die Parameter von “disk” erwartet. Dies kann man so lösen, dass mittels “import” das bestehende “disk” CheckCommand importiert wird und lediglich das auszuführende “command” mit dem Wrapper-Script überschrieben wird. Die Einbindung des CheckCommands sollte am Icinga-2-Master erfolgen, statisch in “commands.conf” oder im Director.
Im  folgenden sind die Beispiele für eine Disk, Prozess und Logfile-Check aufgeführt. Dieses Set könnte einer typischen Cluster-Applikation entsprechen. Wir definieren einen Service-Prozess und einen Filesystem-Mount/Disk die als Cluster-Ressource an die Cluster-VIP gebunden sind. Diese Applikation schreibt auch Log-Dateien, die möglicherweise zu überwachen sind.

object CheckCommand "vip-disk" {
  import "plugin-check-command"
  import "disk"
  command = [ PluginDir + "/check_vip_app", "$app_vip$", "check_disk" ]
}
object CheckCommand "vip-procs" {
  import "plugin-check-command"
  import "procs"
  command = [
   PluginDir + "/check_vip_app",
   "$app_vip$",
   "check_procs"
  ]
}
object CheckCommand "vip-logfiles" {
  import "plugin-check-command"
  import "check_logfiles"
  command = [
    PluginDir + "/check_vip_app",
    "$app_vip$",
    "check_logfiles"
  ]
  timeout = 1m
}

Die zugehörigen Service-Definitionen könnten so definiert werden:

apply Service "vip-disk" {
  check_command = "vip-disk"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
apply Service "vip-procs" {
  check_command = "vip-procs"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
apply Service "vip-logfiles" {
  check_command = "vip-logfiles"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
Und hier ein Auszug zur Darstellung im icingaweb2:

Service-List Icingaweb2


Service – Plugin Output Icingaweb2



Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das Netways Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner...