Select Page

NETWAYS Blog

NWS bekommt einen neuen Anstrich

Harte Arbeit, “Blut” und Schweiß und ein Ergebnis, das sich sehen lässt: Nach unserer Website erscheint nun auch das Kundeninterface in neuem Glanz!

Neben purer Ästhetik für Farben und Formen ging es uns natürlich auch darum, die Bedienung komfortabler und intuitiver zu gestalten. Zudem wurde es mit dem ein oder anderen neuen Feature beschenkt. Geburtstag wurde schließlich auch gefeiert. Aber der Reihe nach. Seit dem Start unserer NWS-Plattform im März 2017 sind ziemlich genau 4 Jahre vergangen.

 

Happy Birthday NWS!

 

 

Nun zum Kundeninterface:

 

Die Idee

Wie bei einem Kleinkind in diesem Alter sind viele – nicht alle – Kinderkrankheiten bereits überstanden und die ersten Gehversuche liegen hinter uns. Die Welt wird neugierig und furchtlos erkundet. Um in dieser Bildsprache zu bleiben: Wir haben unsere Kinderschuhe nun zur Seite gelegt und unser erstes Paar neue Sneakers geschnürt. Nachdem unsere Website bereits vor geraumer Zeit komplett überarbeitet wurde, war es letztendlich nur die logische Konsequenz, auch das Kundeninterface anzupassen. Neben unseren eigenen Ideen wurden unsere Erkenntnisse aus den letzten Jahren – und das wertvolle Feedback unserer immer größer werdenden Kundschaft – umgesetzt.

 

Bedienung

Die Navigation und das Bedienungskonzept standen zu Beginn im Vordergrund. Die größte Herausforderung war sicher, alle unterschiedlichen Produkte unter einen Hut zu bekommen. Eher einfache Produkte wie Jitsi – auf der einen Seite – und eher komplexe wie Managed Kubernetes oder unsere Cloud auf Basis von OpenStack, auf der anderen: Alle Produkte sollten einem Prinzip folgen und sich in der Bedienung und im Konzept ähnlich verhalten. Viele Stunden Brainstorming und einige Diskussionen später stand unsere Entscheidung fest: Sämtliche Produkte organisieren sich in unserer Hauptnavigation – egal, ob es bereits gebuchte oder neue Produkte sind. Gebuchte Produkte ordnen sich allerdings zuerst ein, da sie schließlich das Wichtigste für den Bedienenden sind. Wählt man eines aus, erhält man eine zweite Navigationsleiste, die nur Menüpunkte für das Produkt beinhaltet. Die dritte und letzte Ebene ist der jeweilige ausgewählte Inhalt. Durch die klare und nicht allzu tiefe Hierarchie ist es einfach und nachvollziehbar, wo man sich gerade in der Applikation befindet. Zusätzlich verliert man – durch die beiden stillstehenden Navigationen – seinen Fokus nicht und wird nicht unnötig abgelenkt.

 

 

Farben und Formen

Der neue Stil ist clean und simpel. Unsere Farbpalette der NETWAYS Web Services wurde übernommen und rundet das Erscheinungsbild ab. Die gewählte Schriftart “Montserrat” wirkt modern. Wiederkehrende Elemente wurden im Backend durch dynamische Templates gestaltet und helfen dem einheitlichen Erscheinungsbild. Die Icons unserer Produkte wurden per Hand neu gezeichnet.

 

 

 

Features

Neben der neuen Benutzerführung gibt es viele kleine Verbesserungen für bereits etablierte Elemente. Unser MyEngineer-Service hat einen omnipräsenten Navigationspunkt bekommen, um stets Zugriff auf seine Tickets, Zeiten und den Kontakt zu unseren Kollegen zu haben. In der Übersicht gibt es neben einem “Activitiy Log”, das die letzten Nutzeraktivitäten darstellt, außerdem Informationen über anstehende oder akute Wartungsarbeiten oder Ausfälle und weitere Informationen, wie beispielsweise hilfreiche Tutorials. Jedes Produkt hat jetzt eine Übersicht, in der die wichtigsten Schritte, weiterführende Links oder teilweise kurze und prägnante Tipps für die Verwendung des Produkts zu lesen sind.

 

 

 

Ausblick

Mit dem Ergebnis sind wir wirklich zufrieden und stolz. Ich denke, unsere Kunden werden es ebenso mögen. In den nächsten Wochen stehen bereits die nächsten geplanten Releases an, die unter anderem die Bedienung unserer Cloud betreffen. Mehr soll aber jetzt noch nicht verraten werden.

 

Sebastian Saemann
Sebastian Saemann
Head of 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.

Edge-Cloud-Computing – Cloud to the Edge

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
Sebastian Saemann
Head of 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.

Road to OpenStack

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
Sebastian Saemann
Head of 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 Overlay Network

In den letzten Versionen von Docker hat sich im Bereich Netzwerk einiges getan. Man konnte sich zwar schon seit längerem mit Projekten wie Calico, Flannel oder Socketplane ein Multihost Docker Netzwerk schaffen, aber seit dem Zusammenschluss von Docker und Socketplane und dem daraus gewachsenem libnetwork gibt es jetzt Multihost Docker Networking out of the box.
Damit man es nutzen kann benötigt man neben einer sehr aktuellen Docker Version auch einen zentralen Key-Value Store wie Zookeeper, Etcd oder Consul. Sofern alles richtig konfiguriert ist, erstellt man ein Netzwerk vom Typ ‘Overlay’ mit dem Docker-CLI oder wer es braucht über die Docker API.
docker network create --driver overlay --subnet=10.0.9.0/24 my-net

Ein Container, der sich diesem Netz anschließen soll wird dann ebenfalls wie gewohnt gestartet, jedoch zusätzlich mit dem Zusatz --net, der das entsprechende Netzwerk bestimmt.
docker run -itd --name=web --net=my-net nginx

Ein zweiter, dritter oder x-ter Container auf anderen Hosts wird nach dem gleichem Schema gestartet und schon hat man in dem angegeben IP-Subnetz ein eigenes und neues isoliertes Netzwerk über mehrere Hosts hinweg, über das die Container direkt miteinander kommunizieren können, ohne Umwege wie z.B. über einen Service-Discovery Loadbalancer machen zu müssen.
Das ganze wirkt fast schon magisch und ist für ein so komplexes Thema super leicht zu konfigurieren und zu nutzen. Hinter den Kulissen wird über den VxLAN Standard ein Layer2 Netzwerk (10.0.0.9/24) über Layer4 (UDP) hinweg getunnelt. Das Virtual extensible LAN verhält sich ähnlich zu einem gewöhnlichen Layer2 VLAN, hat jedoch in sehr großen Umgebungen seinem etabliertem VLAN Namensvetter einiges voraus. Die Anzahl der möglichen VLANs wächst von 4094 auf über 16 Millionen. Broadcast Traffic wird zu Multicasts gemapped und vieles mehr.
Wer mehr zu dem Thema wissen will und in entspannter Atmosphäre und isolierten Testumgebung ausprobieren möchte, dem sind unsere Docker Trainings und auch der Docker Workshop vor der OSDC sehr zu empfehlen.

Sebastian Saemann
Sebastian Saemann
Head of 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.

CoreOS und etcd

Im zweiten Teil der Serie wird eine Kernkomponente von CoreOS beschrieben: etcd. Etcd ist ein distributed Key-Value-Store, der für die Konfiguration und das Service-Discovery innerhalb eines CoreOS Clusters verantwortlich ist. Wie viele Tools im Docker Umfeld ist auch etcd in Go geschrieben. Es zeichnet sich durch seine Geschwindigkeit, Verlässlichkeit, Sicherheit und Einfachheit aus. Für sein Konsens verwendet es das Raft Protokoll. Etcd kann man über API (HTTP+JSON) sowie über ein Command Line Interface (etcdctl) steuern.
Ein Beispiel verdeutlicht sehr schnell und einfach, wie etcd verwendet werden kann, um Daten zu schreiben bzw. sie wieder auszulesen:
$ etcdctl set /message Hello
Hello

$ etcdctl get /message
Hello

oder per HTTP-API
$ curl -L -X PUT http://127.0.0.1:4001/v2/keys/message -d value="Hello"
{"action":"set","node":{"key":"/message","value":"Hello","modifiedIndex":4,"createdIndex":4}}

$ curl -L http://127.0.0.1:4001/v2/keys/message
{"action":"get","node":{"key":"/message","value":"Hello","modifiedIndex":4,"createdIndex":4}}

Neben der erwähnten Konfiguration des CoreOS Clusters selbst ist es möglich seine gestarteten Container mit Hilfe von etcd wieder zu finden. Das Schlüsselwort ist “Service-Discovery”. Hierfür wird meist ein Sidekick Prozess gemeinsam mit dem eigentlichen Anwendungscontainer gestartet. Der Sidekick kümmert sich hierbei um das Registrieren der Anwendung. Wie im ersten Teil bereits beschrieben, startet man Container und Services über Fleet, das sich wiederum auf Unit-Files stützt.
[Unit]
Description=Announce myawesomeapp
BindsTo=myawesomeapp@%i.service
After=myawesomeapp@%i.service
[Service]
ExecStart=/bin/sh -c "while true; do etcdctl set /services/myawesomeapp/%i/status/current 'started' --ttl 60; etcdctl set /services/myawesomeapp/%i/status/expected 'started' --ttl 60; etcdctl set /services/myawesomeapp/%i/status/alive 'started' --ttl 60;etcdctl set /services/myawesomeapp/%i/location \"{\\\"host\\\": \\\"%H\\\", \\\"port\\\": \"`docker inspect --format='{{(index (index .NetworkSettings.Ports \"8080/tcp\") 0).HostPort}}' myawesomeapp`\"}\" --ttl 60; etcdctl set /domains/myawesomeapp.netways.de/type 'service' --ttl 60;etcdctl set /domains/myawesomeapp.netways.de/value 'myawesomeapp' --ttl 60;sleep 45;done"
ExecStop=/usr/bin/etcdctl rm /services/website/myawesomeapp@%i
[X-Fleet]
MachineOf=myawesomeapp@%i.service

Das Beispiel zeigt ein Unit-File, das für den Anwendungscontainer (myawesomeapp@.service) einen Sidekick startet. Der Sidekick schreibt verschiedene Informationen des Anwendungscontainers mit einer Gültigkeit (ttl) von 60 Sekunden in etcd unter anderem zum Beispiel seine Location: “etcdctl set /services/myawesomeapp/%i/location”
Das ist wichtig, da in einem Container Cluster die Container auf beliebigen Nodes mit beliebigen Ports gestartet werden können. Ein geeigneter Loadbalancer bzw. geeignete Software kann so dynamisch die aktuelle Umgebung auslesen und Requests an die laufenden Applikationen bzw. Container weiterleiten.
In den nächsten Teilen der Serie wird auf Loadbalancer und Fleet genauer eingegangen.

Sebastian Saemann
Sebastian Saemann
Head of 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.

Veranstaltungen

Tue 27

Elastic Stack Training | Online

April 27 @ 09:00 - April 29 @ 17:00
Tue 27

Graylog Training | Online

April 27 @ 09:00 - April 28 @ 17:00
May 04

GitLab Fundamentals Training | Online

May 4 @ 09:00 - May 5 @ 17:00
May 04

InfluxDB & Grafana | Online

May 4 @ 09:00 - May 5 @ 17:00
May 18

Icinga 2 Fundamentals Training | Online

May 18 @ 09:00 - May 21 @ 17:00