Trefft unser NETWAYS Web Services Team auf der DOST!

Die DOST hat sich nachhaltig als anerkannte Fachkonferenz rund um den Betrieb modularer Cloud-Plattformen etabliert. Da dürfen unsere Kollegen von NETWAYS Web Services natürlich nicht fehlen! Wir werden als Konferenzteilnehmer vor Ort vertreten sein, aber auch als Sponsor mit einem Stand in der Sponsorenausstellung. Egal ob nach oder vor einem Vortrag oder an unserem Stand – sprecht uns an!

Wir freuen uns auf interessante Gespräche zu Cloud und Co.!

Erzählt uns von euren Systemen und Lösungen und erfahrt von uns alles, was es zur NETWAYS Cloud auf OpenStack-Basis zu wissen gibt!

Das Programm, Tickets und alles weitere zur DOST: https://openstack-tage.de/

Alles zur NETWAYS Cloud: https://nws.netways.de/de/cloud/

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.

Über Physik, Erdnuss-Snacks und Schlangenöl aka Datenbanken

Achtung ein Hinweis in eigener Sache, dieser Artike kann Spuren von Polemik und rant enthalten!

Neal Stephenson hat in seinem wunderbaren Roman Cryptonomicon eine kleine Randgeschichte über eine Bandsäge eingebaut. Der für mich schönste Satz darin ist:

Anecdotes about accidents involving the bandsaw were told in hushed voices and not usually commingled with other industrial-accident anecdotes.

An diesen Satz muss ich immer denken, wenn es auf PostgreSQL-Konferenzen in den abendlichen War-Story-Runden zu Geschichten über MySQL oder MariaDB kommt, zugegeben hauptsächlichen deren Migration zu PostgreSQL.
Bei Entity–Attribute–Value (EAV) Schemas, nicht getesteten Backups, Prozeduren, die nicht maskierte Benutzereingaben als Tabellennamen für dynamisches SQL hernehmen etc. kann man sagen sie hätten es wissen können bzw. müssen. (Halt die üblichen Katastrophen, die man sich in gemütlicher Runde so erzählt, Datenbanker sind halt schon ein komischer Haufen.)

Das ist bei MySQL wie auch diversen anderen Datenbanken irgendwie anders, und ich frage mich immer wieder, warum ist das so?

Es hat evtl. etwas mit einer grundsätzlichen Bereitschaft zu tun, über physikalische Gegebenheiten nachzudenken.

Wenn jemand eine PostgreSQL-Mailingliste anschreibt und erklärt, dass Oracle eine Anfrage in 0,009 ms beantwortet, für die PostgreSQL über zwei Minuten benötigt, dann ist diese Frage erst einmal legitim.

Wenn dann aber nach und nach herauskommt, dass es um eine Tabelle mit 9.649.110 Zeilen und rund 3,5GB geht, die mittels SELECT * FROM table1; komplett gelesen wird, müsste einem doch sofort klar sein, das Ersteres nicht sein kann? Das brandneue DDR5-RAM schafft gerade mal 5,2 GT/s (Megatransfer), und da ist noch keine Netzwerkverbindung im Spiel. In 0,000009 Sekunden schafft selbst Licht “nur” rund 2,7km.

Wie können solche offensichtlichen Mess- oder Denkfehler nicht sofort auffallen? Die 2,7 km muss man ja nicht parat haben, aber dass 0,000009 Sekunden ein sehr kurzer Zeitraum sind, um 3,5GB Daten zu übertragen, liegt doch eigentlich für ITler nah?

Was mich zum Thema MM (Multi-Master-Replication) oder politisch korrekt Multi-Primary, Write-Anywhere etc. bringt…

PostgreSQL-Umsteiger von MySQL, MariaD, CockroachDB, Oracle,… fragen immer wieder (z.B. im Telegram-/Slack-Channel, den Mailinglisten, Seminaren), wie man denn einen MM-Cluster aufbaut.

Der Dialog läuft üblicherweise so ab:
Q: “Ich komme von und habe dort einen Multimaster-Cluster. Wie baue ich dasselbe mit PostgreSQL auf?”
A: “Gar nicht. Wahrscheinlich willst du das aber auch gar nicht.”
Q: “Doch, doch. Ich brauche die Hochverfügbarkeit und die Performance (ein Knoten allein schafft meine Schreiblast nicht)!”
A: “MM kostet Performance und verbessert deine Verfügbarkeit nicht wirklich. Benutze einfach eine klassische Replikation, ggfs. mit Lese-Lastverteilung.”

Verdeutlichen wir uns kurz, was es für eine Datenbank bedeutet, auf mehr als einem Clusterknoten schreibenden Zugriff zu erlauben:

  • Sequenzen (für Primärschlüssel bzw. “auto-increment/identity” Spalten) müssen synchronisiert werden, damit keine IDs doppelt vergeben werden
  • es muss sichergestellt werden, dass bei z.B. DELETE-Statements die referentielle Integrität erhalten bleibt; es muss also die Möglichkeit geben,
    clusterweit Datensätze oder sogar ganze Tabellen zu LOCKen
  • wenn auf mehreren Knoten derselbe Datensatz verändert wird, muss eine Konfliktbehandlung erfolgen. Wenn die nicht dem Zufall, sprich dem Replikations-Lag überlassen werden soll, werden clusterweite Transaktions-IDs benötigt
  • und zum Thema Schreiblast: Ziel ist es ja weiterhin, einen einheitlichen und konsistenten Datenbestand zu haben, die Schreiblast pro Knoten bleibt also unverändert!

Je mehr Knoten beteiligt sind, desto mehr Koordination ist erforderlich. Und jede dieser Aktivitäten benötigt Zeit, mindestens 1-2 Netzwerk-Roundtrips.

Je weiter meine Knoten voneinander entfernt sind, desto mehr Zeit und damit Performance geht allein schon durch pure Physik verloren!

Für PostgreSQL gibt bzw. gab es einige FOSS-Varianten, die MM beherrschen (Postgres-XC, Postgres-XL, BDR). Und 2ndQuadrant, deren derzeitiger Maintainer, sagt sinngemäß:

Die Einschränkungen und zusätzlichen Maßnahmen, die MM mit sich bringt bzw. erfordert, sind so eklatant, dass MM wahrscheinlich nie Einzug in den PostgreSQL-Core kommen wird. Und so ein Cluster ist explizit nicht für Hochverfügbarkeit gedacht, sondern um z.B. logisch weitgehend voneinander getrennte Datenbestände, z.B. Verkäufe und Lagerbestände in verschiedenen Ländern, in den jeweils anderen Standorten verfügbar zu machen.

Der Aufwand ist also durchaus erheblich, und mit ein klein wenig Nachdenken sollten sich die Zusammenhänge und Gründe auch jedem Interessenten erschließen.

Oder man macht sich einfach keine Gedanken und setzt bidirektionale Replikation auf, “was soll schon passieren” und “war ganz einfach, mit diesem Tutorial aus dem Netz”…

Multimaster-Clustering ist ein wenig wie im Dunkeln, bei Regen, mit 250 km/h über die Autobahn zu fahren. Als Beifahrer…

  1. Man wünscht sich auf jeden Fall, dass die Person am Steuer nicht nachtblind (sprich: “has RTFM”) ist
  2. das Auto und seine Grenzen sehr genau kennt (pun intended!)
  3. ein oder besser mehrere Fahrsicherheitstrainings hinter sich hat.

Und trotzdem ist man letztlich Faktoren überlassen, auf die man keinen Einfluss hat. Meist geht es ja auch gut…

Hier schließt sich der Kreis zur Bandsäge von oben, denn gewisse DBMS (Datenbank Management Systeme) stehen ja schon ohne bidirektionale Replikation nicht unbedingt im Ruf, Datenintegrität besonders hoch zu bewerten (https://bugs.mysql.com/bug.php?id=11472).

Zur Performance:

Ich erinnere mich, dass Oracle seinerzeit für ihr RAC angegeben hat, dass jeder neue Knoten 90% der Leistung des vorherigen Knotens bringt*. Was ein sensationell guter Wert wäre, aber eben alles andere als lineare Skalierung (linear steigt lediglich der Preis…):


WITH perf AS (
SELECT nodes, 0.9^(nodes-1) AS nextnodes_performance
FROM generate_series(1,8) AS nodes
)
SELECT *
,avg(nextnodes_performance) OVER (ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
AS average_performance
,nodes * avg(nextnodes_performance) OVER (ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
AS overall_performance
FROM perf;
┌───────┬───────────────────────┬────────────────────────┬────────────────────────┐
│ nodes │ nextnodes_performance │ average_performance │ overall_performance │
├───────┼───────────────────────┼────────────────────────┼────────────────────────┤
│ 1 │ 1.0000000000000000 │ 1.00000000000000000000 │ 1.00000000000000000000 │
│ 2 │ 0.9000000000000000 │ 0.95000000000000000000 │ 1.90000000000000000000 │
│ 3 │ 0.8100000000000000 │ 0.90333333333333333333 │ 2.70999999999999999999 │
│ 4 │ 0.7290000000000000 │ 0.85975000000000000000 │ 3.43900000000000000000 │
│ 5 │ 0.6561000000000000 │ 0.81902000000000000000 │ 4.09510000000000000000 │
│ 6 │ 0.5904900000000000 │ 0.78093166666666666667 │ 4.68559000000000000002 │
│ 7 │ 0.5314410000000000 │ 0.74529014285714285714 │ 5.21703099999999999998 │
│ 8 │ 0.4782969000000000 │ 0.71191598750000000000 │ 5.69532790000000000000 │
└───────┴───────────────────────┴────────────────────────┴────────────────────────┘

* vielleich waren es auch 80% oder 95% oder die Aussage war einfach kompletter Humbug?

Zur Verfügbarkeit:

Ein anderes gerne vorgebrachtes Argument, z.B. auf galeracluster.com ist “Transparent to Applications: Required no or minimal changes to the application”.

Ich habe mich immer gefragt, wie Oracle beim RAC das TCP-Protokoll aushebelt, eine Netzwerkverbindung bricht nun einmal ab, wenn der Host offline geht. Bis mir mal jemand gesteckt hat, dass man auf ein RAC mit einer anderen Client-Bibliothek zugreift. Mit anderen Worten: der Verbindungsabbruch wird nicht an das Programm durchgereicht, sondern das Statement (bzw. die Transaktion?) wird auf einer neuen Verbindung wiederholt. Ich unterstelle einfach mal, dass Galera etc. ähnlich arbeiten.

Können das die modernen Connection-Pools, ORMs etc. nicht auch alle schon mehr oder weniger selbsttätig oder mit “minimal changes”? Eine Applikation sollte es auf jeden Fall können. Aber gut, es sollte auch keine Applikationen mehr geben, die mehr als ein Statement außerhalb einer Transaktion durchführen…!

Auf jeden Fall rücken solche Aussagen die entsprechenden Produkte m. E. in die Nähe eines Worts, das im Titel dieses Beitrags steht…

Der klassische Ansatz:

Der Vollständigkeit halber sei noch kurz umrissen, wie eine hochverfügbare Cluster-Lösung mit PostgreSQL oder auch anderen DBMS aussehen kann.

  • ein Knoten (“Primary” oder non-PC “master”, P) erlaubt lesende und schreibende Zugriffe (R/W)
  • n andere Knoten (“Secondaries” oder “slaves”, S1,…,Sn) erhalten die Änderungen von P und erlauben lesende Zugriffe (RO)
  • zusätzlich landen alle Änderungen in einem Archiv, aus dem jeder beliebige Zeitpunkt wieder hergestellt werden kann (PITR)
  • Sn können synchron oder asynchron replizieren (bei synchroner Replikation sollte n > 1 sein!)

Der Zugriff auf den Knoten P kann auf verschiedene Arten erfolgen:

  • Clients erhalten die IPs aller Knoten und können selbst festlegen, ob sie Schreib-Lesezugriff benötigen
  • P hat eine zusätzliche virtuelle IP-Adresse, unter der er angesprochen wird (gerne zusammen mit P in einer Resource-Group der eingesetzten HA-Lösung)
  • ein vorgeschaltetes Tool, z.B. HAProxy weiß, welcher Knoten gerade P ist

Zusätzlich können Clients entscheiden, ob ihre jeweilige Aktivität nur lesend oder schreibend ist und sich entsprechend mit P oder einem Sn unterhalten, um die Gesamt-Performance zu verbessern.

Manche Pooler, z.B. PGPool-II können diese Unterscheidung sogar selber mehr oder weniger gut treffen. Vorsicht aber mit z.B. schreibenden Triggern!

Dass eine Client-Software eine halbwegs funktionale Fehlerbehandlung haben sollte, vielleicht sogar mit ein wenig Wartezeit vor’m retry, versteht sich von selbst.

Multi-Master-Datenbankcluster bringen einige Aspekte mit, die zu wenig oder zumindest selten beachtet werden. Manche sind ausgesprochen gefährlich!

Eine klassische Replikationslösung bietet annähernd dieselbe Verfügbarkeit, i.A. deutlich bessere Performance und bereitet auf Dauer wesentlich weniger Kopfschmerzen.

Wie man ein solches Cluster aufbaut, lernt man in unserem Kurs PostgreSQL Fundamentals.

Gunnar “Nick” Bluth hat seine Liebe zu relationalen Datenbanken Ende des letzten Jahrtausends entdeckt. Über MS Access und MySQL 3.x landete er sehr schnell bei PostgreSQL und hat nie zurückgeschaut, zumindest nie ohne Schmerzen. Er verdient seine Brötchen seit beinahe 20 Jahren mit FOSS (Administration, Schulungen, Linux, PostgreSQL). Gelegentlich taucht er auch tiefer in die Programmierung ein, so als SQL-Programmierer bei der Commerzbank oder in App-Nebenprojekten.

Kick Off für die neue Webinar-Reihe “Monitoring Hardware”

Am 10.10.2019 möchten wir alle Interessierten zum Kick Off unserer neuen Webinar-Reihe “Monitoring Hardware” einladen!

Auf folgendes darf sich unser Publikum in den kommenden Webinaren freuen:

  • Vorstellung unserer Hersteller der Produkte aus dem Shop
  • Vorstellung von Hardware-Produkten aus den Bereichen Monitoring, Sensorik und Alarmierung
  • Vorstellung von Weboberflächen der Produkte und zusätzlicher Software
  • Updates zu neuen Produkten und Features bestehender Produkte
  • Integrationen von Hardware in die Monitoring-Lösung Icinga 2

Starten möchten wir mit unserem Hersteller GUDE und dessen Expert Sensor Box 7213/14. Dabei freuen wir uns sehr, dass wir Herrn Philipp Gude, seines Zeichens Account Manager im Hause GUDE, als Gast im Webinar begrüßen dürfen. In den Webinaren möchten wir unseren Zuschauern unsere Hardware-Hersteller und deren Produkte vorstellen. Im ersten Webinar geht es um eine Sensor Box, die – wie der Name es vermuten lässt – Temperatur, Luftfeuchtigkeit und auch den Luftdruck messen, verarbeiten und bewerten kann. Daraus lassen sich dann Nachrichten generieren, die unter anderem per E-Mail versendet werden können. Im Anschluss wird uns Herr Gude durch das Webinterface der Geräte führen und für die Fragen unserer Zuschauer zur Verfügung stehen.

Um nicht zu viel zu verraten, verweisen wir hier nun auf unsere Webinar-Anmeldung.

Wer sich auch für unsere anderen Webinare interessiert, der findet hier nicht nur die kommenden Webinare, sondern auch unser Archiv. Aktuell laufen Webinare zum Thema Graylog, in vergangenen Webinaren sind aber unter anderem auch Serien zu den Themen OpenStack, Icinga 2, NETWAYS Web Services und Icinga Director zu finden. Wir würden uns auf jeden Fall freuen, Sie in einem der kommenden Webinare begrüßen zu dürfen.

Bildquelle: https://unsplash.com/photos/VCFxt2yT1eQ by Austin Distel

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

OSMC | Take a glance back

This entry is part 8 of 28 in the series OSMC | glance back

… and get excited about the future!

Today’s video-goodie for you: OSMC 2018 | Smart Home Monitoring mit openHAB 2 by Marianne Spiller

 #OSMC 2019 will take place November 04 – 07.

Check out who is speaking this year! And don’t forget to grab your Ticket!

See you!

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.

Managing your Ansible Environment with Galaxy

Ansible is known for its simplicity, lightweight footprint and flexibility to configure nearly any device in your infrastructure. Therefore it’s used in large scale environments shared between teams or departments. This leads to even bigger Ansible environments which need to be tracked or managed in version control systems like Git.

Mostly environments grow with their usage over time, in this case it can happen that all roles are managed inside one big repository. Which will eventually lead to quite messy configuration and loss of knowledge if roles are tested or work the way they supposed to work.

Ansible provides a solution which is called Galaxy, it’s basically a command line tool which keeps your environment structured, lightweight and enforces your roles to be available in a specific version.

First of all you can use the tool to download and manage roles from the Ansible Galaxy which hosts many roles written by open-source enthusiasts. 🙂


# ansible-galaxy install geerlingguy.ntp -v
Using /Users/twening/ansible.cfg as config file
 - downloading role 'ntp', owned by geerlingguy
 - downloading role from https://github.com/geerlingguy/ansible-role-ntp/archive/1.6.4.tar.gz
 - extracting geerlingguy.ntp to /Users/twening/.ansible/roles/geerlingguy.ntp
 - geerlingguy.ntp (1.6.4) was installed successfully

# ansible-galaxy list
# /Users/twening/.ansible/roles
 - geerlingguy.apache, 3.1.0
 - geerlingguy.ntp, 1.6.4
 - geerlingguy.mysql, 2.9.5

Furthermore it can handle roles from your own Git based repository. Tags, branches and commit hashes can be used to ensure it’s installed in the right version.


ansible-galaxy install git+https://github.com/Icinga/ansible-icinga2.git,v0.2.0
 - extracting ansible-icinga2 to /Users/twening/.ansible/roles/ansible-icinga2
 - ansible-icinga2 (v0.2.0) was installed successfully

It’s pretty neat but how does this help us in large environments with hundreds of roles?

The galaxy command can read requirement files, which are passed with the “-r” flag. This requirements.yml file can be a replacement for roles in the roles path and includes all managed roles of the environment.


# vim requirements.yml
- src: https://github.com/Icinga/ansible-icinga2.git
  version: v0.2.0
  name: icinga2

- src: geerlingguy.mysql
  version: 2.9.5
  name: mysql

Then run ansible-galaxy with the “–role-file” parameter and let galaxy manage all your roles.


# ansible-galaxy install -r requirements.yml
 - icinga2 (v0.2.0) is already installed, skipping.
 - downloading role 'mysql', owned by geerlingguy
 - downloading role from https://github.com/geerlingguy/ansible-role-mysql/archive/2.9.5.tar.gz
 - extracting mysql to /Users/twening/.ansible/roles/mysql
 - mysql (2.9.5) was installed successfully

In case you work with Ansible AWX, you can easily replace all your roles with this file in the roles directory and AWX will download and manage your roles directory automatically.

A example project could look like this.


awx_project/
├── example_playbook.yml
├── group_vars
├── host_vars
├── hosts
└── roles
    └── requirements.yml

In summary, in large environments try to keep your code and configuration data separated, try to maintain your roles in their own repository to avoid conflicts at the main project.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.