Seite wählen

NETWAYS Blog

stackconf online 2021 | Help, My Datacenter is on Fire

This year’s stackconf is over and was a big success. The three-day conference last summer was all about open source infrastructures where trendsetting concepts, state-of-the-art technical expertise, top-level discussions and new perspectives have shaped the event.

Besides our 30 amazing experts sessions we were also excited about the large amount of participants from all over the world. Our audience included renowned infrastructure spezialists, industry leaders, experienced administrators and IT architects as well as a wild bunch of open source community enthusiasts.

For all of you who couldn’t join the Open Source Infrastructure Conference I’ve something awesome today.

Kris Buytaert has talked about his burning datacenter, how customers survived this outage and how culture, opensource tooling and automation saved the data. Be curious and enjoy his lecture!

 

YouTube player

 

stackconf 2022 will take place from July 19 – 20 in Berlin.

First confirmed speakers are already on our website. The final program will be announced soon.

So stay tuned!

Katja Kotschenreuther
Katja Kotschenreuther
Manager Marketing

Katja ist seit Oktober 2020 Teil des Marketing Teams. Als Manager Marketing kümmert sie sich hauptsächlich um das Marketing für die Konferenzen stackconf und OSMC sowie unsere Trainings. Zudem unterstützt sie das Icinga Team mit verschiedenen Social Media Kampagnen und der Bewerbung der Icinga Camps. Sie ist SEO-Verantwortliche für all unsere Websites und sehr viel in unserem Blog unterwegs. In ihrer Freizeit reist sie gerne, bastelt, backt und engagiert sich bei Foodsharing. Im Sommer kümmert sie sich außerdem um ihren viel zu großen Gemüseanbau.

HW group: Stark auf YouTube!

HW group ist einer der führenden Hersteller im Bereich Monitoring-Hardware, neben der auch das SensDesk Portal als Software-Monitoring-Lösung angeboten wird. Viele Einsatzszenarien für HW group Hardware stellt der Hersteller in anschaulichen Videos im eigenen Channel auf der Plattform YouTube vor. Für uns als NETWAYS ist dennoch immer noch die Überwachung von Rechenzentren und Serverräumen am interessantesten:

YouTube player

 

Im obigen Video werden Sensoren für die Erkennung und das Messen folgender Parameter vorgestellt:

  • Luftstrom
  • Luftfeuchtigkeit
  • Rauch
  • Wasserleckagen
  • Stromfluss
  • Bewegung
  • Türöffnung
  • Thermometer
  • Kameras
  • und vieles mehr

 

Diese Sensoren können an vielen der HW group Basis-Gerät angeschlossen werden. Als kleine Auswahl hier die beliebtesten Produkte unserer Kunden:

 

Die Geräte STE, STE2 und Ares12 sind hautpsächlich als Netzwerkthermometer gedacht wohingegen das WLD speziell für die Erkennung von Wasserleckagen dienen soll. Mithilfe dieser Messgeräte als Basis und den unterschiedlichen Sensoren und Detektoren können die auf YouTube vorgestellten Use Cases einfach realisiert werden. Da insbesondere das STE2 ein Verkaufsschlager ist, sollte man sich in der nachfolgenden Grafik die vielseitigen Optionen des Gerätes ansehen:

 

 

Für die im Video vorgestellte Software SensDesk bietet HW group auch Sensoren, die kein Basisgerät benötigen. Dabei handelt es sich um Funk-Sensoren, die dennoch zusätzlich mit einem RJ-45 Anschluss ausgestattet sind, aus der SD-Serie. Hier gibt es bislang folgende Typen:

  • Kombination aus Temperatur und Luftfeuchtigkeit
  • 2 x Digitale Ausgänge
  • 2 x Digitale Eingänge
  • Wasserleckage-Detektor

 

Wer nun Lust bekommen hat, sich auch die SensDesk Software mal anzusehen, dem sei die Demo-Umgebung dazu empfohlen: SensDesk Demo. Weitere Online Demos zu den unterschiedlichsten HW group Geräten finden Sie auch bei uns im Shop im HW group Demo Bereich. Und wer sich berieseln lassen möchte, findet auch eine Webinar-Reihe zu diesem Thema, die mit SensDesk IoT portal Tutorial 1 – Dashboard beginnt und sechs Teile umfasst.

Wir sind jederzeit für Euch erreichbar per Mail: shop@netways.de oder telefonisch unter der 0911 92885-44. Wer uns gerne bei der Arbeit ein bisschen über die Schulter schauen oder den Shop und die angebotenen Produkte verfolgen möchte, kann uns auch auf Twitter folgen – über @NetwaysShop twittert das NETWAYS Shop Team.

OSDC: DevOps Culture meets Technology

It has been there for a decade. In this time it has grown up from a buzzword to a key-subject discussed in many companies. You know, what I mean!

They call it DevOps

It’s more than a group therapy for frustrated IT engineers with new fancy tools, says Arnold Bechtoldt, Senior Systems Engineer at inovex. What are the technical symptoms of the DevOps method? Which problems aren’t actually technical? How to approach these issues? Arnold’s talk at OSDC will guide you through the jungle!

Are containers the DevOps killer? Or is there still any hope left for this culture in a containerized world? Martin Alfke is CEO at example42 GmbH, located in Berlin. He is a long-term Puppet specialist and trainer. At OSDC Martin will let you know what kind of security borders we have at hand to work separately but with trust.

Prepared thus, we will finally empower you to go the five steps to transformational change. At OSDC you’ll learn the essential methods that Dan Barker used in real transformations at multiple companies! Dan is Chief Architect at RSA Security for cloud migration and an organizer of DevOps KC.

OSDC focuses on innovative strategies, trendsetting developments and new perspectives in dealing with large data centers. The event takes place in Berlin, May 14 – 15, 2019.

NEW at OSDC: Free Workshop

Mgmt Config: Autonomous, real-time systems“ with James Shubin on the pre-conference day, May 13, 2019.
Get your conference ticket and workshop add-on ticket at osdc.de.

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.

Netways Managed Services Status Page – Github is your friend

Unser neues Familienmitglied

Als neuestes Angebot für unsere Hosting-Kunden haben wir nun eine Wartungsseite ins Leben gerufen. Diese ist öffentlich sichtbar unter status.netways.de und soll über Wartungsintervalle unserer Systeme informieren.

Diese Informationen sind in Form eines Blogs aufbereitet und umfassen Meldungen zu Wartungsbeginn, Wartungsende, Verlaufsupdates sowie den betroffenen Systemen und Services.

Blick hinter die Kulissen

Es gibt natürlich sehr viele Varianten, eine Webseite mit Blog umzusetzen. Eines unserer Kriterien war, dass die Wartungsseite extern gehostet sein sollte, um auch bei Wartungen an Webservern oder eventuellen Ausfällen den Informationsfluss zum Kunden garantieren zu können. Des Weiteren sollten Posts schnell und mit Methoden erstellt werden, die das Team bereits im Einsatz hat. Recht schnell fiel die Entscheidung dann auf das Format Github Pages, das all dies nativ bietet.

Wie funktioniert Github Pages?

Github Pages bietet die Möglichkeit, in einem Repository eine Webseite zu erstellen, die unter der URL <username>.github.io online verfügbar ist. Die Struktur der Webseite ist frei wählbar und kann mit den üblichen Layout-Sprachen wie HTML und CSS erstellt werden. Änderungen an der Webseite und das Hinzfügen von Posts können zum einen über die Github-Webseite, aber auch wie gewohnt über die git-Kommandozeile durchgeführt werden.
Nun fragen sich wahrscheinlich viele, wo denn jetzt der Clou an Github Pages ist – Jekyll!
Jekyll ist die Engine, die für uns im Hintergrund den Blog erstellt und die Webseite aktualisiert, sobald ein neuer Post oder eine Änderung an einem bereits bestehenden Post erfolgt. Dies ist nativ in Github Pages eingebaut, so dass hier nichts installiert werden muss – es gilt nur, die von Jekyll erwarteten Konventionen einzuhalten. Dazu gehören z. B. die Directory-Struktur im Repository sowie die File-Namen der Blog-Posts. Damit Jekyll den Blog korrekt generieren kann, werden Layouts hinterlegt, so dass die Posts als schön formatierte Einträge auf der Webseite erscheinen. Mithilfe dieser Layouts kann Jekyll die in Markdown verfassten Inhalte der Posts interpretieren.
Github Pages steht jedem zur Verfügung, der einen Github-Account besitzt. Was man daraus macht, bleibt einem selbst überlassen – jedoch sollte man sich dieses Angebot nicht entgehen lassen.
Als Startpunkt für die Reise durch Github Pages ist das Tutorial von Jonathan McGlone sehr zu empfehlen:
Creating and Hosting a Personal Site on GitHub
Ich wünsche allen Interessierten viel Spaß beim Ausprobieren!