Jitsi Best Practice und Skalierung

Seit nun mehr als zwei Wochen wird dort wo es möglich ist von Zu Hause aus gearbeitet. Home-Office für ALLE! Naja mindest für die die es können.

Damit ist auch von einem Tag auf den anderen der Bedarf an Kommunikations-Werkzeugen vor allem für Video-Konferenzen gestiegen.
Hierfür gibt es einige Plattformen welche mittels Jitsi Video- und Audiokommunikation als Service anbieten. Darunter auch NETWAYS Web Services
Jitsi ist eine Freie Software welche auch selbst betrieben werden kann.
Beim Betrieb von Jitsi jedoch zeigt sich das Jitsi sehr schwierig in der Skalierung ist. Es benötigt die richtigen Ressourcen und die richtigen Clients für die Nutzung, um nicht ab einer zweistelligen Zahl von Nutzern in einen reinen Ton- und Bildsalat zu enden. Die technischen Dokumentationen jedoch sind nicht sehr ausgeprägt und durch ihre Zerstreuung sehr schwer zu einem ganzen zusammen zu fügen.

Daher werden wir uns folgend mit den Punkten Anforderungen, Skalierung und Nutzung auseinander setzen.

Empfehlung für einen eigenen Jitsi Server/Videobridge

Nach meinen Tests und der Güte an vorhandenen Quellen zur Hilfe und Dokumentation komme ich zu folgendem Ergebnis:

  • Betriebssystem: Debian 10 oder Ubuntu 18.04.4 LTS
  • Soviel CPU wie geht
    (klingt komisch ist aber so)
    CPU: bei durchschnittlich 10 Teilnehmer pro Konferenz kommen ich mit 2vCPU für die Videobridge ganz gut klar. Mehr zur Skalierung der CPU findet ihr hier:
  • jitsi-videobridge-performance-evaluation

  • CPU Jitis/Jifico/Prosody: Hier würde auch eine (v)CPU ausreichen, hängt jedoch auch wieder von der Frequentierung ab.
  • RAM: 4-8 GB für beide Server-Varianten
  • Speicherplatz: max. 50 GB SSD für beide Server-Varianten
  • Eine hohe Bandbreite
  • Die Unstable Version von Jitsi:
# install the key
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
# add the unstable repo
sh -c "echo 'deb https://download.jitsi.org unstable/' > /etc/apt/sources.list.d/jitsi-unstable.list"
apt update

Eine gute Installations-Anleitung dazu gibt es zum einen von Jan Doberstein auf seinem Blog jalogisch.de
oder auch sehr hilfreich und weiterführend auf der Seite lw1.at guides

Skalierung einer Jitsi Infrastruktur

Ausgangslage

Wir haben einen vollständig installierten Jitsi Server Namens jitsi.example.com auf Basis von Debian. Jetzt wollen wir mehr mehr Ressourcen bereit stellen, so müssen wir weitere jitsi-videobridge Instanzen aufsetzen.
In der vollständigen Installation eines Jitsi-Servers auf Basis von Debian 10 sind folgende Pakete installiert:

ii jitsi-meet 1.0.4314-1 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.3914-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-web 1.0.3914-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.3914-1 all Configuration for web serving of Jitsi Meet
ii jitsi-videobridge2 1132-1 amd64 WebRTC compatible Selective Forwarding Unit (SFU)

Der Part jitsi-videobridge ist der Teil der den jtisi-meet mit der Video und Audio Übertragung versorgt. Er schließt sich an jitsi-meet und dem verwendeten prosody (XMPP-Server) an.

Anbindung einer Videobridge

Dazu binden wir die die Paketquellen auf dem zweiten Server vb1.example.com ein und installieren die Videobridge:

# install the key
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
# add the unstable repo
sh -c "echo 'deb https://download.jitsi.org unstable/' > /etc/apt/sources.list.d/jitsi-unstable.list"
apt update
apt install jitsi-videobridge2

Sollte eine Firewall auf dem Server jitsi.example.com aktiviert sein so müssen wir den Port 5222 für eingehende Kommunikation öffnen.

Auf dem zweiten Server vb1.example.com passen wir jetzt die Datei “/etc/jitsi/videobridge/config” an:

# Jitsi Videobridge settings

# sets the XMPP domain (default: none)
JVB_HOSTNAME=jitsi.example.com

# sets the hostname of the XMPP server (default: domain if set, localhost otherwise)
JVB_HOST=jitsi.example.com
....

Dann kommen wir zu Datei für die SIP-Kommunikation. Diese sollte vom Hauptserver jitsi.example.com übernommen werden und die UUID sollte hierbei auf jedem Server unterschiedlich gesetzt sein.
Die Datei “/etc/jitsi/videobridge/sip-communicator.properties” wird wie folgt eingestellt:

org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true
org.jitsi.videobridge.ENABLE_STATISTICS=true
# Notwendig falls der Server hinter einem NAT steht.
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=local-ip
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=public-ip
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=jitsi.example.com
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.jitsi.example.com
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.jitsi.example.com
#UUID am besten mit "uuidgen" neu gernieren muss auf beiden Servern Einzigartig sein.
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=9a6187f0-6d3f-46df-b1ff-ce7d2d69513a
org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

Auf Debian 10 tritt mit Java 11 folgender Fehler auf:

VB 2020-03-21 19:29:23.687 SEVERE: [16] org.jitsi.utils.concurrent.RecurringRunnableExecutor.log() The invocation of the method org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.run() threw an exception.
java.lang.reflect.InaccessibleObjectException: Unable to make public long com.sun.management.internal.OperatingSystemImpl.getTotalPhysicalMemorySize() accessible: module jdk.management does not "opens com.sun.management.internal" to unnamed module @54ca3634
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
at org.jitsi.videobridge.stats.OsStatistics.getTotalMemory(OsStatistics.java:138)
at org.jitsi.videobridge.stats.VideobridgeStatistics.generate0(VideobridgeStatistics.java:703)
at org.jitsi.videobridge.stats.VideobridgeStatistics.generate(VideobridgeStatistics.java:450)
at org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.doRun(StatsManager.java:321)
at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)

Dieser kann beseitigt werden mittels folgender Ergänzung am Ende der Java System Properties in der Datei “/etc/jitsi/videobridge/config”:

JAVA_SYS_PROPS="-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi -Djava.util.logging.config.file=/etc/jitsi/videobridge/logging.properties --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED"

Nun können wir die Videobridge starten:

systemctl enable jitsi-videobridge && systemctl start jitsi-videobridge

An der Stelle geht auch ein Dank an Jan Doberstein der mich auf diese Spur gebracht hat und in seinem Blog-Folge Artikel zu Scaling Jitsi

Nutzung

Das Protkoll WebRTC, welches Jitsi nutzt, wird zur Zeit nur sauber von Google Chrome unterstützt. Somit sollte allen Nutzern dieser Browser, für die Anwendung am Notebook empfohlen werden. Für Androide und iOS Geräte gibt es Applikationen den jeweiligen App-Stores. Sehr schöne Zusammenfassung und eine ausführliche Benutzer-Anleitung hierzu gibt es auch auf der Seite des Freifunk München.

Sicherheit

Zum Thema Sicherheit empfiehlt es sich am Besten zuerst die Stunning-Server von Google in der Datei “/etc/jitsi/meet/jitsi.example.com-config.js zu ersetzen. Eine geeignete Stunning-Server Konfiguration kann wie folgt lauten:

stunServers: [
{ urls: 'stun:stun.schlund.de:3478' },
{ urls: 'stun:stun.t-online.de:3478' },
{ urls: 'stun:stun.1und1.de:3478' },
{ urls: 'stun:stun.hosteurope.de:3478' },
{ urls: 'stun:stun.gmx.de:3478' },
],

Zustätzlich wenn Ihr nicht eine gänzlich freie Plattform, sondern eine mit Moderaten oder sogennante Host per Raum gestützte Instanz betreiben wollt, empfiehlt es sich in prosody und jitsi-meet die Benutzerauthentifzierung für das erstellen von Räumen zu aktivieren.
In der Datei für die prosody-Konfiguration “/etc/prosody/conf.avail/jitsi.example.com.cfg.lua”, setzen wir den Wert für “authentication” auf “internal_plain” und fügen einen neuen VirtualHost darunter ein ein:

VirtualHost "jitsi.yourdomain.example"
-- enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
-- Properties below are modified by jitsi-meet-tokens package config
-- and authentication above is switched to "token"
--app_id="example_app_id"
--app_secret="example_app_secret"
-- Assign this host a certificate for TLS, otherwise it would use the one
-- set in the global section (if any).
-- Note that old-style SSL on port 5223 only supports one certificate, and will always
-- use the global one.
ssl = {
key = "/etc/prosody/certs/jitsi.yourdomain.example.key";
certificate = "/etc/prosody/certs/jitsi.yourdomain.example.crt";
}
-- we need bosh
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
c2s_require_encryption = false

VirtualHost "guest.jitsi.example.com"
authentication = "anonymous"
c2s_require_encryption = false

In der Datei “/etc/jitsi/meet/jitsi.example.com-config.js” geben wir nun den neuen VirtualHost an:

var config = {
hosts: {
// XMPP domain.
domain: 'jitsi.yourdomain.example',

// When using authentication, domain for guest users.
anonymousdomain: 'guest.jitsi.yourdomain.example',
}
}

Nun müssen wir noch jifico dazu veranlassen auch eine Authentifizierung durchzuführen und die Klasse in der “/etc/jitsi/jicofo/sip-communicator.properties” laden:

org.jitsi.jicofo.auth.URL=XMPP:jitsi.example.com

Danach müssen die Dienste neu gestartet werden:

sudo systemctl restart prosody.service
sudo systemctl restart jicofo.service

Für die Anbindung einer Authentifizierung in Prosody gibt es auch Enterprise fähige Funktionen für LDAP und Co. Die obige Lösung beschreibt es für ein überschaubares Setup, denn die Benutzer hier müssen dann im Anschluss mit der prosodctl generiert werden:

prosodyctl register  jitsi-meet.example.com

Abschließend bleibt zusagen…

Es ist nicht leicht gute Dokumentationen zu Jitsi und dessen Betrieb zu finden, eben so wie für das Scalling. Eine einheitliche Dokumentation gibt es nicht und somit macht es einen Gesamtüberblick nicht sehr leicht.
Neben der Jitis-Community und der Docs auf GitHub gibt es eine paar bereits schon erwähnte Artikel aber auch die sind rah. Daher die Bitte wenn jemand verbesserungen hat, meldet euch gerne!

Wenn Ihr eine Instanz dringend benötigt und euch nicht mit dem Betrieb ausseinandersetzen könnt oder naja vielleicht nicht wollt, dann schaut doch einfach bei unseren Kollengen von NWS vorbei. Dort bekommt Ihr aktuell mit dem Code #StayAtHome eine kostenlose Jitsi-Instanz für drei Monate und das ganz ohne Abo-Falle!

Also bleibt Zuhause und fragt euch gerade in diesen Tagen doch mindestens einmal am Tag:

1. Ist es wahr?
2. Ist es fair für alle Beteiligten?
3. Wird es Freundschaft und guten Willen fördern?
4. Wird es dem Wohl aller Beteiligten dienen?”

(Das sollten wir uns bei allem Fragen, was wir denken, sagen oder tun IMHO!)

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...
Vom Messwert zur Alarmierung

Vom Messwert zur Alarmierung

Unternehmen können heutzutage gar nicht von Überwachungsmaßnahmen ihrer Umgebung entkommen, da wir als Menschen den aktuellen Stand von hunderten von Geräten nicht im Griff haben können. Deshalb werden Tools und Equipment im Überwachungsbereich dauernd entwickelt. Aus dem vorherigen erwähnten Bedarf möchte ich ein paar Informationen über zwei Geräte teilen und zwar AKCP sensorProbe2+ und SMSEagle.

AKCP sensorProbe2+

Das AKCP sensorProbe2+ ist ein Messgerät, an das verschiedene Arten von Sensoren angeschlossen werden können. Beispielhaft sind Bewegungs-, Gas-, Schall-, Temperatur, Feuchtigkeit- und Spannungssensoren. Stecken Sie einen beliebigen Sensor in die sensorProbe2+ und eine Autosense-Funktion erkennt den Typ und konfiguriert ihn automatisch. Standardmäßig hat das SP2+ die IP-Adresse 192.168.0.100. Es ist über einen Webbrowser konfigurierbar – sogar die IP-Adresse lässt sich ändern unter Einstellungen  => IP-Einstellungen. Aber der angeschlossene PC muss im gleichen Netz wie der SP2+ sein, um die Verbindung herstellen zu können. Das Gerät kann in einem beliebigen Intervall sowohl seine Verfügbarkeit als auch sämtliche Messwerte durch SMS, Mail oder SNMP Trap mitteilen.

SMSEagle

SMSEagle ist ein SMS Gateway, das SMS und Mails schickt bzw. empfängt. Mails können in SMS umgewandelt werden und umgekehrt. Darüber hinaus gibt es eine eingebaute Überwachungsfunktion, die die Verfügbarkeit von Geräten und Ports überprüft (ICMP, SNMP, TCP, UDP) und beim Ausfall eine SMS oder Mail sendet. SMS können sogar weitergeleitet werden mit Nutzung von Filtern oder ohne. Zusätzlich können wir eine automatische Antwortregel konfigurieren. LDAP-Autentifizierung kommt auch als Feature mit.

Kombination von beiden Geräten:

Beide Geräte müssen nicht im gleichen Netzwerk sein, sondern es reicht, wenn beide einander anhand von einem SMTP-Server sehen. SMSEagle besitzt sogar einen integrierten SMTP-Server, der dafür benutzt werden kann. Dessen IP-Adresse habe ich beim SP2+ eingetragen. SMSEagle akzeptiert nur Mails, die an ihn gesendet sind und lehnt den Rest ab. In SMSEagle muss “Mail to sms” Plugin aktiviert werden, um eingehende Benachrichtigungsmails von SP2+ in SMS zu wandeln und an die gewünschte Nummer zu senden. Im SensorProbe2+ muss man eine Mail-Aktion unter Hauptmenü erstellen, in dem man Zieltelefonnumme@SMSEgale-FQDN als Zielmail einträgt. Zieltelefonnummer könnte man durch gespeicherte Kontaktnamen im Telefonbuch vom SMSEagle ersetzen, wenn es keine Leerzeichnen enthält. SP2+ akzeptiert nur FQDN als Zieladresse. Deswegen muss man folgende Konfigurationseinträge durchführen plus einen DNS-Eintrag für SMSEagle :

[ NXS Geräte unter]
/etc/postfix/main.cf

[NPE Geräte unter]
/mnt/nand-user/postfix/etc/postfix/main.cf

1. folgende Zeile finden “myhostname = localhost.localdomain” und ändern in “myhostname = yourdomain.com”

2. Konfiguration von  Postfix reloaden
postfix reload

Wir können eine Testmail von SP2+ schicken und im Eventslog nachschauen, ob sie versendet werden konnte , oder ob es eine Fehlermeldung gibt. Außerdem können wir unter “notification rules” einstellen, bei welchem erreichten Schwellenwert eine Mail geschickt werden soll. Hier haben wir fünf einstellbare Schwellenwerte Normal, High Warning, High Critical, Low Warning und Low Critical. Wir können auf der anderen Seite in den Maillog von SMSEagle unter /etc/var/log/mail.info, in Systemlog oder unter Einstellungen => sysinfo nachschauen, ob die gesendeten Mails vom SP2+ angekommen sind und als SMS weitergeschickt wurden.

Man kann SP2+ mit Icinga 2 verbinden, wofür man lediglich das entsprechende Plugin benötigt: check_sensorProbe2plus

Ansonsten helfen wir bei Fragen rund um die Hardware von AKCP und SMSEagle gerne weiter – wir sind erreichbar per Mail 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 seit kurzem auch auf Twitter folgen – über @NetwaysShop twittert das NETWAYS Shop Team!

 

 

Afeef Ghannam
Afeef Ghannam
Support Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kollegen im Support und bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

Ü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.

Lessons learned – how not to make beginner’s mistakes: Migrating server

At Netways we try to learn all the time. Often you can simply read man pages, change logs, or even tabtab through your shell command at hand.

Trainings and conferences are a bit more time consuming, but can offer you one priceless advantage: the direct communication with someone, who has seen several sides of the topic at hand. I think, you learn best from other peoples experiences – even more from the situations where failure ensued. Here it is critical to not only look at the failure itself, but why it occured and how it was finally resolved.

Using other persons failure as a mean to learn  might seem a bit cynically at first. In an ideal world, however, the same failure would only ocurr once.

So let’s begin with my contribution to a better world, maybe even as a start of a series. This entry is not meant as full post-morten per se, it only describes mistakes you can make and should avoid.

As many might know, our office moved. Having been 10ish years in our “old” office, you might figure that quite a lot “historical infrastructure” can grow in this time. Especially in an IT environment where everybody wants to try something new, better, and undocumented.

Being in the distinguished situation of having direct access to our DC via 1GBit-Fiber, it was possible to use some of our external IPs in our office. VLAN-Tagging, firewall policies, iptables rules – all well known and understood best practices. The services got installed, used and worked flawlessly for all the time and have lived happily ever after.

With the announcement of moving to the new premises, the blue sky became a bit hazy. We had to move all needed hardware devices (NASA could tell you how small and well hidden some of them can be) and also separate them from the unneeded devices. Todays story is about two specific systems, each consisting of two 1U server. Those were some of the systems which used external IPs to provide services to the public. They have been running flawlessly for quite some time and given their age, had started to develop some adorable quirks.

It was my task to move these “dear old ladies” out of the cozy office into the cold, professional DC downstairs.

What harm can 4 old and lovable server possibly do, you might ask? The answer is: None, if you treat them the way they were used to.

First things first: How can you gain access to the DC? Is there a registration process, which has to be followed? How long does this take? Can you access the DC after business hours easily? (Hints: yes, long, no)

Also don’t try to rush things when it comes to shutdown the machines for moving  them. The machines owners like to what is going to happen.

Grab all the tools you will need to remove the server from your previous rack and install them in their new home (cordless screwdriver, all bits you can find)

Are all installation material available? This is not only referring to rack rails, but also cage nuts, screws (size matters) and front covers for feng-shui and air flow. (depends, mostly: no)

Cables! Just collect all the cables you need and then some. Usually, they will be too short. Too long is not an issue you can’t fix with zip ties (you will forget these)

Do you have network access in the DC for debugging, communication etc.? (Hint: depends)

Do you want to move more than one server? Be cautios and do them step by step. You’re absolutely allowed to install them all at the same time. Be aware you might experience crooked rails, incorrect cabling and other time consuming things.

When you have installed the machines, definitely take your time to check these with a KVM device. Whichever is in reach. (you guessed it: there won’t be any when you need them the most). Don’t rely on the machine and its fancy blinkenlights: Some may flash when everything is ok, some flash to indicate errors, some don’t flash at all.

Check all your cabling at least twice, give them a gentle pull – if they come lose, you have to start over again.

Take breaks between different machines. Either try to find a cool spot in the DC (haha) or get outside, have something to drink and return refreshed. The noise (ear plugs, ANC Headphones), temperature, confinement while working in the rack will wear you out eventually.

If you route the machines traffic through several VLANs, make sure all needed switch ports are tagged (or untagged? You decide!) and firewall policies applied for the new location.

Always have a piece of paper and a (working!) pen with you – it’s faster to scribble something on paper than to crawl through yor rats nest of cabling, climb over all the machines you’re up to install and then find your trusty notebook with dead battery.

Before you finally leave, make sure to give everything one last check and, if possible, communicate with the owners of the respective machines. Collect all the tools you brought with you. If you didn’t bring them but “found” them somewhere and used them: make sure to return them.

If you run into any issues, make sure all colleagues you could ask for assistance are currently at the party you’re rushing to attend.

Also make sure to communicate only via phone, so you don’t leave any paper trail when it comes to DC access, network config or time accounting.

When you don’t experience some of these mistakes because of this post, this post was a success. Of course some points are missing (feel free to comment), but I hope the overall pattern is visible:

be prepared, double check and take your time

 

Oh, and don’t forget the key to your racks. There is just one key, right?

Tim Albert
Tim Albert
Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...

TLS: Eine kleine Übersicht

Der durschnittliche Internetbenutzer benutzt TLS (Transport Layer Security) mittlerweile auf fast allen größeren Websiten – ohne, dass sich dieser darüber bewusst wäre, in den allermeisten Fällen. Auch in meiner Ausbildung bei NETWAYS darf ich mich nun intensiv mit TLS beschäftigen. Doch was ist TLS? Dieser Text soll einen groben Umriss um die zugrunde liegenden Prinzipien und Techniken hinter TLS legen.

Warum brauchen wir TLS?

TLS wird benötigt, um drei Probleme zu lösen. Unsere Kommunikationen sollen verschlüsselt sein – wir wollen nicht, dass Pakete oder Informationen, die wir übertragen, abgehört werden. Außerdem wollen wir sicher gehen, dass der andere Teilnehmer dieser Kommunikation auch derjenige ist, mit dem wir diesen Austausch an Informationen vollziehen wollen. Darüber hinaus wäre es auch gut, sich darauf verlassen zu können, dass das, was von der einen Seite losgeschickt wurde, auch das ist, was der andere erhält. Um diese drei Probleme kümmert sich TLS. Doch wie macht es das?

Eine Beispielverbindung:

1. ClientHello

Ein Client verbindet sich mit einem Server und verlangt eine gesichertete Verbindung. Dazu wird die Version von TLS übertragen, und eine Chiffrensammlung, aus denen sich der Server die Verschlüsselungsmethode aussuchen kann.

2. ServerHello & Certificate & ServerKeyExchange

Der Server antwortet, welches Chiffre verwendet werden soll, und einem Zertifikat, welches den Server authentifizieren soll und einen öffentlichen Schlüssel enthält.

3. ClientKeyExchange

Dieses Zertifikat wird von dem Client verifiziert, und der öffentliche Schlüssel des Servers wird vom Client benutzt, um ein pre-master secret zu erstellen, welcher dann wieder an den Server geschickt wird.

Der Server entschlüsselt das pre-master secret, und beide Parteien nutzen es, um einen geheimen, geteilten Schlüssel zu erstellen, welcher als shared secret bezeichnet wird.

4. ChangeCipherSpec

Der Client versendet die erste, mit dem shared secret verschlüsselte Nachricht, welche der Server entschlüsseln soll, damit geprüft werden kann, ob die Verschlüsselung richtig initialisiert wurde. Wenn diese Verifizierung erfolgreich abgelaufen ist, kommunizieren dann der Client und der Server verschlüsselt untereinander. Dieser ganze Prozess wird als TLS-Handshake bezeichnet.



Geschichte: TLS wurde unter dem Vorläufernamen SSL (Secure Sockets Layer) in 1994 von Netscape für den damals sehr populären Browser Mosaic vorgestellt. Version 2.0 und 3.0 folgten jeweils ein Jahr später. 1999 wurde SSL 3.1 bei der Aufnahme als Standart von der Internet Engineering Task Force in TLS 1.0 umbenannt. 2006 folgte Version 1.1, 2008 1.2 und 2018 die heutige Version 1.3.


Asymmetrische & Symmetrische Verschlüsselung: TLS ist zunächst asymmetrisch, dann symmetrisch verschlüsselt. Was bedeutet das? Nun, hier kommen die Schlüsselpaare ins Spiel. TLS benötigt einen öffentlichen und einen privaten Schlüssel. Der öffentliche Schlüssel wird benutzt, damit der Gegenpart einen Vorschlüssel erstellen kann, welcher dann von dem privaten Schlüssel wieder decodiert wird. Das ist eine asymmetrische Verschlüsselung – welche allerdings deutlich kostenintensiver und aufwändiger ist, und sich dementsprechend nicht für die zahlreichen Anwendungsmöglichkeiten für eine TLS-Verbindung eignet. Dank’ dem Vorschlüssel können allerdings beide Seiten des Austausches einen gemeinsamen, geheimen Schlüssel berechnen, mit Hilfe dessen die verschlüsselten Nachrichten auf jeweils beiden Seiten entschlüsselt werden können. Somit ist der Kern von TLS eine symmetrische Verschlüsselung; der Austausch der tatsächlichen Information passiert über diesen Kanal. Um aber an diesen Punkt zu kommen, sind asymmetrische Verschlüsselungsprinzipien im Einsatz.


Zertifikate: Wie in dem TLS-Handshake betrachtet, sind Zertifkate elementar zur Ausweisung und Identifikation von Server und Client – und wohl der kritischste Punkt in dem ganzen TLS-Ablauf. Damit ein Kommunikationspartner identifiziert werden kann, muss er sein Zertifikat ausweisen, welches seine Identiät beweist. Ausgestellt wird ein Zertifikat von einer certificate authority, einem vertrauenswürdigen Aussteller dieser Zertifikate, was verschiedenste Dinge bedeuten kann: Viele multinationale Konzerne stellen kommerziell Zertifikate aus, darunter fallen Firmen wie IdenTrust, Sectigo und DigiCert Group. Es existieren allerdings auch einige non-profit organisations, wie CAcert und Let’s Encrypt, die als Zertifizierungsstelle auftreten. Darüber hinaus gibt es natürlich auch jede Menge Zertifikatsaussteller innerhalb von Netzen, welche in der Hand von einem vertrauenswürdigen Admin liegen.


Chiffrensammlung: Eine Chiffrensammlung ist eine Auflistung aus den Verschlüsselungsmethoden, die bei einer TLS-Verbindung eingesetzt werden können. Beispiele dafür wären RSA, MD5, SHA. Bei einer TLC-Verbindung wird in ClientHello und ServerHello unter den beiden beteiligten Parteien kommuniziert, welche dieser Methoden zur Verfügung für den Aufbau der Verbindung stehen.


https: Doch was hat es nun mit https auf sich? Ganz einfach: https (HyperText Transfer Protocol Secure) ist eine Extension von http, bei der http über eine verschlüsselte TLS-Verbindung versendet wird, was sie im Gegensatz zu Klartext-http vor unerwünschten Abschnorchelungen und sonstigen Attacken schützt.


Verbreitung: Laut der regelmäßig auf einen neuen Stand gebrachten Auswertung von SSL Labs von rund 140.000 Webpages bieten gerade mal 67.2% eine adequate TLS-Ausstattung. Das mag im ersten Moment etwas niedrig erscheinen, man darf aber auch nicht vergessen, dass diese Lage vor nicht allzu langer Zeit noch deutlich, deutlich schlimmer war, und durch Maßnahmen wie einer automatischen Warnung von Chrome verbessert wurde. So hat sich auch laut Firefox Telemetry die Anzahl der per https aufgerufenen Websiten sich von 25% auf 75% erhöht. Ebenso bemerkenswert: Einem Jahr nach Einführung von TLS 1.3 unterstützen gerade mal 15% den aktuellen Standart, der absolut überwiegende Teil bietet noch hauptsächlich TLS 1.2 an. Man darf gespannt sein, wie lange es dauert, bis der Großteil den Wechsel vollzogen hat. Auf der anderen Seite bieten 7.5% der Webpages noch Unterstüztung für SSL 3.0 an, einem Standart, der mittlerweile fast so alt ist wie ich selbst, und als nicht sicher gilt.

 

 

 

Henrik Triem
Henrik Triem
Junior Developer

Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.

Finde den Weg mit mtr und traceroute

Zum prüfen der Routing Pfade durch das eigene Netzwerk war bisher mtr mein bevorzugtes Tool. Mit  mtr -u 10.10.10.10 werden anstatt icmp udp Pakete/Pings verwendet wodurch man nach und nach alle Pfade durch das eigene Netzwerk findet.

Da sich aber seit Version 3.6 immer wieder das Verhalten des Linux Kernels bezüglich des ECMP Hashing geändert hat, kommt es auf Hosts mit mehreren Pfaden zum ersten Hop/Router immer häufiger vor, dass mtr nur einen Pfad anzeigt (je nach Kernel Version des Hosts). Dies kann sowohl an dem verwendeten Tool als auch an dem sysctl Parameter net.ipv4.fib_multipath_hash_policy liegen. Per default steht dieser auf 0 und bewirkt, dass nur die IP Adressen des Senders und des Empfängers zur Berechnung des Pfades verwendet werden. Setzt man die Hash Policy hingegen auf 1, werden zusätzlich die Ports von Sender und Empfänger mit in die Berechnung aufgenommen.

Da mtr die Ports nicht mit jedem Ping/Paket wechselt, findet man leider wieder nicht die Pfade zum ersten Hop. traceroute hingegen wechselt Sender- und Empfängerport mit jedem Paket wodurch nun alle Pfade gefunden werden. Leider ist traceroute nicht gleich traceroute. Unter Ubuntu findet man dies z.B. in den beiden Paketen inetutils-traceroute und traceroute, in zwei verschiedenen Implementationen mit unterschiedlichem Verhalten. Um unter Ubuntu alle Pfade zu finden sollte man sicherstellen, dass man die Binary aus dem Paket traceroute verwendet.

Kurz zusammengefasst gibt es für nicht angezeigte Pfade also mehrer Ursachen:

  • unterschiedliches ECMP Hashing im Linux Kernel (in Abhängigkeit der Version)
  • nicht explizit aktivierte Multipath Hash Policy
  • Verwendung von mtr oder einer unpassenden traceroute Implementation

Ich für meinen Teil werde bei mtr bleiben und einfach Sender und Empfänger vertauschen, der Router vor dem Empfänger macht ja schon immer alles richtig und berücksichtig auch Layer4.

 

 

 

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.