NETWAYS Blog

Edge-Cloud-Computing – Cloud to the Edge

by Sebastian Saemann | Feb 27, 2019 | OpenStack, Web Services, Network

Während man in Deutschland immer noch und immer wieder in Funklöchern sitzt und oftmals nur 2G als Datenübertragung nutzen kann, bereitet sich die Welt – auch Deutschland – auf den nächsten Standard vor: 5G. Die neue Generation besticht durch hohe Bandbreiten (~1-20Gbps), niedrige Latenzen und eine hohe mögliche Dichte von Geräten auf neuen Frequenzbändern, die natürlich heiß begehrt sind. Braucht man aber solch hohe Bandbreiten und niedrige Latenzen um seine E-Mails zu checken oder Social Media Inhalte zu betrachten? Wohl eher nicht. Diese neuen Anforderungen an das Netzwerk benötigen aber Anwendungen, die in Zukunft vermutlich nicht mehr wegzudenken sind und maßgeblich unsere Welt verändern könnten – so zumindest die Vision. Autonomes Fahren, künstliche Intelligenz, Augmented- und Virtual-Reality und Internet of Things sind nur einige Anwendungsbereiche, die durch den neuen Standard ihre Möglichkeiten besser ausschöpfen können.

Ein völlig autonom fahrendes Auto, gespickt mit mehreren hundert Sensoren und vielen Kameras, produziert eine gewaltige Menge an Daten, die in einer Cloud zum Beispiel zur Koordination anderer Fahrzeuge eingespeist und verarbeitet werden. Ein weiteres Beispiel wäre die Videoüberwachung in einer U-Bahn kombiniert mit den Aufzeichnungen der Kameras vom Bahnsteig, die in Echtzeit menschliche Verhaltensmuster analysiert oder gar erlernt und entsprechend entscheidet. Benötigt es eine Vollbremsung, weil ein Passant gerade am Bahnsteig mit böser Absicht geschubst wird oder ist es eher eine harmlose Situation unter Freunden? Damit das funktioniert, benötigt man nicht nur ein schnelles Mobilfunknetz sondern auch Edge-Cloud-Computing.

Edge-Cloud-Computing

Edge-Cloud-Computing ist zu Recht einer der letzten und heißesten Trends im Bereich Cloud-Computing. Dabei gilt es, seine zentrale Cloud an den Rand (Edge) zu bewegen – also näher an den Kunden. Mit anderen Worten eine verteilte Cloud. Was genau jetzt der Rand sein soll ist noch nicht so ganz klar, man nimmt einen Bereich an, der nicht weiter als 20ms vom Endgerät entfernt ist. An diesem Rand ist es also nun notwendig, seine Cloud-Compute-Ressourcen verfügbar zu haben und nutzen zu können, um entsprechende Workload darauf zu betreiben. Ob die Workload in Containern, VMs oder Bare-Metal betrieben wird ist eher nachrangig zu betrachten, der Mix wird es sein. Dabei stützt man sich auf bestehende Technologie-Komponenten wie etwa Ceph, Qemu, Kubernetes, DPDK, OpenVSwitch und so weiter. 5G alleine wird also ohne Edge-Computing vermutlich nicht reichen, um zukünftigen Anwendungen gerecht zu werden.

Die beiden Open-Source Cloud-Lösungen, OpenNebula und OpenStack, die wir auch bei NETWAYS im Einsatz haben, sind natürlich bereits auf den Hype-Train aufgesprungen. OpenNebula hat gleich ihr gestriges Release 5.8 dem Codenamen “Edge” verpasst und OpenStack hat mit StarlingX sein eigenes Projekt und ein “Edge Computing Group” Gremium ins Leben gerufen.

Man kann wirklich gespannt sein was die Zukunft bringen wird und wie die Herausforderungen technisch realisiert werden.

Anwendungen, die ohne 5G und Edge auskommen, können aber auch schon heute in unserer Cloud basierend auf OpenStack modern, zeitgemäß und zukunftssicher betrieben werden.

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.

Read more from Sebastian and meet the Team

SNMP Netzwerk Monitoring

by Max Deparade | Aug 31, 2018 | Virtualisierung, MySQL, Network, MariaDB, NETWAYS, Linux, Icinga, Team, Mac

Huhu!
Heute möchte ich euch ein wenig in die Welt von SNMP Monitoring mit Icinga 2 entführen. Da man leider nicht immer einen Switch mit SNMP zur Hand hat, verwende ich eine GNS3 Netzwerk Umgebung sowie eine CentOS 7 Maschine für Icinga 2.
Doch was ist den dieses SNMP überhaupt, was kann das? Zunächst SNMP steht für Simple Network Message Protocol (RFC 1157) und wurde mit dem Gedanken entwickelt Netzwerkgeräte wie Drucker, Router, Switche und vermutlich irgendwann auch Toaster per IoT von einem Zentralen Punkt im Netzwerk aus überwachen bzw. steuern zu können. SNMP an sich besitzt nicht wirklich viel Magie es beschreibt im Endeffekt wie Datenpakete aussehen können. Damit Icinga 2 (Managmentstation) den Switch (Agent) fragen kann, wie es ihm den heute so geht. Die eigentliche Magie ist die sogenannten Managment Information Base, umgangssprachlich auch MIB genannt.
Die MIB kann man sich wie einen großen Baum vorstellen, dessen Äste und Blätter mit Hilfe von eindeutigen OIDs gebildet werden. Die Blätter die an unseren Ästen hängen sind Objekte wie ein Lüfter, oder eine Festplatte und können als als OID so aussehen: 1.3.6.1.4.1.1.4.
Nach viel Techbabbel kommt nun wenig Kaboom (Practical Examples). An Hand des Beispiel möchte ich euch ein Grundgerüst an die Hand geben, wie man bequem und ohne Geräte spezifisches Plugin ein SNMP Monitoring unter Icinga 2 einfach realisieren kann.
Im ersten Schritt holen wir uns alle OIDs samt Beschreibung vom Gerät, in meinem Fall von einem VyOS Router:

snmpwalk -Os -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_desc
snmpwalk -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_oid

Für das Beispiel wähle ich drei OIDs aus:

.1.3.6.1.2.1.2.2.1.2.1

.1.3.6.1.2.1.2.2.1.2.2

.1.3.6.1.2.1.2.2.1.2.3

Mit dem Director hab ich ein Template und Service angelegt, welches auf das Check_Plugin/Kommando check_snmp zurückgreift. Die ausgewälten OIDs werden Kommasepariert per Costume Attribut “snmp_oid” mitgegeben:

template Service "snmp" {
    check_command = "snmp"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 20s
}

object Service "Interfaces" {
    host_name = "vyos"
    import "snmp"
    vars.snmp_label = "Interfaces"
    vars.snmp_oid = ".1.3.6.1.2.1.2.2.1.2.1,.1.3.6.1.2.1.2.2.1.2.2,.1.3.6.1.2.1.2.2.1.2.3"
}

Nach dem ausbringen der Konfiguration sollte das ganze folgendermaßen aussehen:

Tipp am Rande:
Falls euer Gerät nicht auf Öffentlichen MIBs aufbauen sollte, wie hier im Beispiel, bekommt ihr die im Regelfall vom Hersteller bereitgestellt. Die MIB wird einfach zu den bereits existierenden hinzugefügt und dann ist alles wie gehabt! 🙂
Damit verabschiede ich mich und wünsche wie immer viel Spass beim Implementieren!

SSL geknackt! Naja, fast.

by Alexander Klimov | Jul 26, 2018 | Icinga, Team, Network, Security

Wer kennt das nicht: Da sitzt man beim Kunden (oder auch remote) und debugt ein Programm wie bspw. Icinga 2. Alle Stricke reißen und man ist dazu genötigt, den Netzwerk-Verkehr zu inspizieren… Ach ja, das ist ja alles SSL-verschlüsselt. Und dies ist auch nicht abschaltbar, selbst wenn man es dürfte. Und jetzt?
Genau in dieser Zwickmühle befand sich neulich ein Kollege und wandte sich kurzerhand an einen der Sicherheitsfanatiker hier in der Firma – mich.
Als solcher kenne ich die Maschen der dunklen Seite der Macht. So auch bspw. diese hier:

Wireshark, den Netzwerk-Verkehr und den privaten Schlüssel von Icinga 2 Du brauchst: /var/lib/icinga2/certs/HOST_FQDN.key
Den Schlüssel in Wireshark Du hinterlegst: Preferences (Command + Komma) / Protocols / SSL / RSA key list / Edit
Den Netzwerk-Verkehr automatisch Wireshark entschlüsselt

So jedenfalls die Theorie ist…

In der Theorie sind Theorie und Praxis gleich – in der Praxis nicht. So wurden auch wir davon überrascht, dass sich am mitgeschnittenen Kauderwelsch nichts geändert hat. “Stimmt…”, fiel mir wieder ein, “da war was…”

Das DH macht den Unterschied

Zu Beginn einer SSL-Verschlüsselten Verbindung handeln Client und Server u.a. den konkreten Verschlüsselungsalgorithmus aus. In diesem Fall waren die beiden besonders schlau und wählten einen “Diffie Hellman” Algo. Schön für den Sysadmin, doof für uns. Der Zweck von Diffie Hellman ist es nämlich, genau solche Machenschaften der dunklen Seite der Macht dumm aus der Wäsche schauen zu lassen.
Zum Glück hatte ich noch ein Ass im Ärmel. Icinga 2 gibt dem Admin nämlich die Möglichkeit, die zu verwendenden Algorithmen einzuschränken:

--- /etc/icinga2/features-available/api.conf
+++ /etc/icinga2/features-available/api.conf
@@ -7,4 +7,6 @@
   //accept_commands = false
   ticket_salt = TicketSalt
+
+  cipher_list = "AES256-SHA256"
 }

Im konkreten Fall habe ich mich der Einfachheit halber auf einen einzigen nicht-DH Algorithmus beschränkt:

openssl ciphers |tr : \\n |grep -vFe DH

Es aber gingen theoretisch auch alle:

openssl ciphers |tr : \\n |grep -vFe DH |paste -sd : -

Nach einem Neustart von Icinga 2 und einer Wiederholung der HTTP-Anfragen hatten wir dann endlich Transparenz à la DSGVO (die grün markierten Pakete):

Fazit

Viel Spaß beim debuggen (lasst euch nicht vom Datenschutzbeauftragten erwischen) und vergesst nicht, die Lücke hinterher abzudrehen.
Und wenn bei euch wirklich alle Stricke reißen, helfen wir euch gerne weiter.

Alexander Klimov

Senior Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Read more from Alexander and meet the Team

Road to OpenStack

by Sebastian Saemann | May 23, 2018 | Web Services, Network

Seit bereits sieben Jahren betreiben wir bei NETWAYS eine Private Cloud Installation auf Basis von OpenNebula. Damals starteten wir gerade einmal mit drei Hypervisor Servern und einem NFS-Datastore, bereitgestellt aus einer Netapp 3140. Bis heute hat sich daran natürlich einiges verändert. Die Technologien haben sich geändert, als auch die notwendigen Ressourcen sind deutlich gestiegen. Heute laufen zum Beispiel unsere virtuellen Maschinen nicht mehr auf NFS sonder auf Ceph RBDs. Das Ceph-Cluster, verteilt über zwei Standorte, umfasst aktuell knapp ein halbes Petabyte Storage Kapazität.
OpenNebula hat uns während dieser Zeit der Transformation immer gut und zuverlässig zur Seite gestanden. Sämtliche Upgrades verliefen meist tadellos. Deshalb ist es fast ein bisschen Schade, diesem tollem Open-Source-Projekt den Rücken zu kehren und von nun an mit dem Platzhirsch OpenStack zu liebäugeln. Einer der Hauptgründe diesen Schritt zu gehen – neben beispielsweise der oft besseren und breiteren Verfügbarkeit an Integrationen und Tools von Dritten (z.B. Foreman, Puppet, Terraform usw.) – ist Software Defined Networking. Kurz SDN. Natürlich gibt es hierfür auch gute Ansätze und eine Basis-Unterstützung im OpenNebula Projekt. Theoretisch gibt es sogar die Möglichkeit fast jeden SDN Provider in OpenNebula, dank seiner Erweiterbarkeit, zu integrieren, aber leider nicht ohne selbst vorher ordentlich Pionierarbeit leisten zu müssen. Bei OpenStack hat man eher die Qual der Wahl, welcher SDN Provider für sein Setup passt.
Mit SDN virtualisiert man in einem Overlay Netzwerk ein künstliches und unabhängiges Netzwerk, ohne dass man das Underlay, die tatsächliche Hardware z.B. Switches und Router, auf die jeweiligen Umstände und Anforderungen anpassen muss. Die Vorteile liegen dabei auf der Hand: Im Underlay hat man ein stabiles Trägernetzwerk, dass man im Prinzip nur noch skalieren und robust betreiben muss und im Overlay werden die Anforderungen der Kunden realisiert. Wir setzen hierbei im Underlay auf Cumulus Linux in Kombination mit Mellanox Hardware und im Overlay auf die SDN Lösung von Midonet. Beides harmoniert gut miteinander und kann entsprechend verknüpft werden.
In unserer neuen Cloud-Installation ist es für uns und unsere Kunden dann dadurch möglich im Self-Service sich Netzwerke, Router, VPNs, Load-Balancer und Firewall-Regeln zu erstellen, ohne hierfür vom Administrator Hilfe und Beistand einzufordern. Auch überlappende private Netzwerke sind dann kein Problem und eine Pflege und penible Vergabe von IPs und Subnetzen bzw. VLANs fallen somit vom Tisch.
Klar ist, der Self-Service Part könnte mit OpenNebula in unserer bisherigen Installation ebenfalls gelöst werden, allerdings beeindruckt insbesondere die technische Umsetzung und das sehr raffinierte und intelligente Konzept der SDN Lösung von Midonet. Wie das ganze technisch funktioniert erklären wir im Blog in einem unserer nächsten Artikel.

Sebastian Saemann

CEO Managed Services

Read more from Sebastian and meet the Team

Der kleine Ping erkundet die Welt

by Thomas Gelf | Nov 17, 2017 | Icinga, Team, Network

Als der kleine Ping vor bald 34 Jahren geboren wurde, war die Welt noch übersichtlich und in Ordnung. Jeder kannte jeden und man lernte schnell neue Freunde kennen. Diese Freunde bleiben einem dann häufig auch lange treu. Ein offenherziger Kerl wie der kleine Ping lernte damals sehr schnell sehr viele Freunde kennen.
Gut erzogen und treu wie er war, besuchte er die meisten davon immer wieder und wieder. War jemand krank, dann war Ping schon mal länger unterwegs oder kam gar nicht mehr zurück. Aber langsam von vorn.
Seinen Namen bekam der kleine Ping vermutlich, weil sein Vater Mike zu viele Kriegsfilme im Fernsehen schaute. Oder weil seine Arbeit bei der US Army ihn so faszinierte. Ping, so hört sich nämlich der Sonar ein einem U-Boot an. Wie ein Klopfen. Irgendwie fanden seine Eltern das wohl sehr spannend. Also die Tatsache dass da Schallsignale gesendet und wieder zurück reflektiert wurden.
Das wäre doch auch ein schöner Job für unseren Ping, dachten sie. Also wurde der kleine Ping schon sehr früh losgeschickt, um unsere Welt zu erkunden. Da war er noch ganz klein, gerade mal 1000 Zeilen hoch. Dennoch fühlte er sich wie ein ganz Großer. Ständig auf Reisen kannte er sehr bald jede Straße, jede Autobahn und jeden Weg wie seine Westentasche. Das fand er unglaublich spannend.
Sein Vater war aber sehr streng. Jedesmal wenn Ping das Haus verließ notierte er auf die Millisekunde genau, wie spät es war. Und als der Ping dann wieder zurückkam, wurde auch das notiert. Aus Start- und Endzeit errechnete sein Vater dann, wie lange der kleine Ping unterwegs war.
Als der kleine Ping älter wurde, machte er sein Hobby zum Beruf. Wenn jemand wissen wollte, wie lang man auf einer Strecke unterwegs war, dann ging er zum kleinen Ping. Wollte ein LKW-Fahrer wissen, ob sein fetter Brummi unter einer Brücke Platz hätte – unser Ping konnte das klären.
Manchmal war es freilich ein wenig langweilig. Als Berufspendler war er hauptsächlich auf immer denselben Strecken unterwegs. Zu den Stoßzeiten im Stau zu sein war auch kein Vergnügen. Ping nahm sich dann ab und an andere Texte zum Lesen mit, das sorgte für gute Unterhaltung. Sein Vater prüfte übrigens immer, ob er auch wirklich mit denselben Texten wieder nach Hause kam. Fehlten Buchstaben oder waren falsche dabei, dann ließ er ihn unter Umständen gar nicht mehr ins Haus. Ping musste dann auf der Straße übernachten.
Ab und an erlaubte Ping sich einen Spaß. Da packte er ein Vielfaches an Ladung drauf um zu sehen, ob auch wirklich alle Tunnel-Decken und Brücken hoch genug waren. Er war halt so ein richtig nerviger Besserwisser. Und ab und an krachte es dabei natürlich ganz heftig. Ping bekam dann aber nicht etwa Stress. Das lief dann einfach als “Prüfung des Maximalen Tunnel Umfangs”, kurz MTU-Test. Ping hatte seinen Spaß – und die Polizei war froh, dass sie von jemandem auf Verletzungen der Bauvorschriften hingewiesen wurden.
Die richtig wichtigen Jobs bekamen andere. Einige seiner Brüder arbeiteten bei der Polizei, das hätte dem kleinen Ping gefallen. Bei welcher Einheit wäre ihm egal gewesen, zur Not auch bei den lahmen Kerlen von der “Ruhigen Inneren Polizei”, dem RIP. Das sind die Verkehrspolizisten in den kleinen Käffern auf dem Land.
Im Grunde machten die nicht viel mehr als die Leute nach links und rechts zu dirigieren. Aber dennoch. Betrachtete man das Geschehen vom Kirchturm aus, dann sah das schon beeindruckend aus. Alles floss schön links und rechts an den Polizisten vorbei – genau wie die sich das gerade so vorstellten. Ganz großes Kino!
Die richtig coolen Jungs hingegen arbeiteten bei der “Beindruckend Großen Polizei”, dem BGP. Das ist die Autobahnpolizei, irre was bei denen abging. Schon bei der Aufnahmeprüfung musste jeder von denen ein paar hunderttausend Routen im Kopf haben. Das klang irre anspruchsvoll und stressig. So weit wollte der kleine Ping dann doch nicht hinaus. Aber ab und an davon zu träumen, das war schon schön.
Der kleine Ping war zufrieden mit seinem Job. Er war es, der dieses Berufsbild erfunden und geformt hatte. Tausende hatten es ihm im Laufe der Jahre nachgemacht. Und heute ist er nicht zuletzt wichtiger Bestandteil einer jeden Monitoring-Umgebung. Auch wir haben kaum irgendwo eine Icinga-Umgebung am Laufen, in welchem er nicht zuverlässig seinen Dienst verrichten würden. Darum sei ihm an dieser Stelle mal ein Lob ausgesprochen: er macht seinen Job ausgezeichnet, ist zuverlässig und unauffällig.
Weiter so, lieber kleiner Ping!

Thomas Gelf

Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Read more from Thomas and meet the Team