HAProxy und SQL Grants

In diesem kurzen Beitrag will ich auf einen Fallstrick im Bezug von HAProxy und SQL Backends wie MySQL oder MariaDB eingehen. Speziell geht es um Grants und die damit verbunden Quell Hosts. Diese werden bei einem Standard Setup mit HAProxy durch die IP des Proxys ersetzt. Solange man sich in dem selben Netz wie die DB Server und dem Proxy befindet und die Host-Beschränkungen nicht all zu streng sind, kann es gut sein, das man dieses Szenario nicht erreicht. Sobald die Verbindungen aber Netz übergreifend erfolgen und die Grants damit umso wichtiger sind, kommt das Detail zum Tragen und stellt einen vor neue Herausforderungen. Dafür gibt es an sich schon etwas länger das Proxy Protokoll, welches aber erst nach und nach in mögliche Backend Software implementiert wurde/wird. Bei MariaDB war es mit der 10.3.1 z.B. erst Ende letzten Jahres soweit.
Die Arbeitsweise des Protokolls beschreibt sich einfach gesagt so, dass mit dem Aufbau der Verbindung zuerst ein zus. Header geschickt wird, in dem die IP des Quell Hosts bekannt gegeben wird. Dazu muss das Backend jedoch von der IP des HAProxys das Proxy Protokoll erlauben. Das Ganze drum rum kann mit Seiten über weitere Details und Sicherheit befüllt werden. Damit verschone ich Euch aber und weise nur auf eine schlichte Zusammenfassung im Blog von HAProxy hin.

Linux Kernel first meta block group too large

Das Thema von Spectre und Meltdown hat uns ebenfalls gut beschäftigt, aber heute wollen wir nicht darüber reden. Viel mehr gehen wir auf einen Bug im Linux Kernel ein, welcher uns bei den Upgrade-Aktionen über den Weg gelaufen ist und zuerst für Verwirrung sorgte.
Im Detail betrifft es den Mount Vorgang von Ext4 Filesystemen, welche in der Vergangenheit vergrößert oder verkleinert wurden. Dies quittiert sich mit der Fehlermeldung ‘first meta block group too large’. Das Ganze trat im Kernel 4.4.48 das erste mal auf und zieht sich leider durch die Reihe. ( z.B. hier und hier ). Die Behebung ist für Stable Releases geplant, aber unsere Tests mit einem recht aktuellen 4.13er Kernel zeigten noch das gleiche Verhalten. In den genannten Links existiert auch schon ein Patch für einen manuellen Kernel Build, falls Bedarf besteht.
Die Lösung des Problems lässt sich leider nur mit einem neueren/selbst gebauten Kernel oder einer Portierung der Daten mittels altem Mount und neuem Filesystem beheben. Wir hoffen Euch mit dieser Information ein paar graue Haare und Zeit zu ersparen.
Und wem all das Ganze zu viel wird, der kann sich von uns gern unterstützen lassen.

Graphite vs. IOPS – experience exchange

Last year, Blerim told us how to benchmark a Graphite and now we want to share some experience on how to handle the emerging IOPS with its pro and contra. It is important to know that Graphite can store its metrics in 3 different ways (CACHE_WRITE_STRATEGY). Each one of them influences another system resource like CPU, RAM or IO. Let us start with an overview about each option and its function.

max

The cache will keep almost all the metrics in memory and only writes the one with the most datapoints. Sounds nice and helps a lot to reduce the general and random io. But this option should never be used without the WHISPER_AUTOFLUSH flag, because most of your metrics are only available in memory. Otherwise you have a high risk of losing your metrics in cases of unclean shutdown or system breaks.
The disadvantage here is that you need a strong CPU, because the cache must sort all the metrics. The required CPU usage increases with the amount of cached metrics and it is important to keep an eye on enough free capacity. Otherwise it will slow down the processing time for new metrics and dramatically reduce the rendering performance of the graphite-web app.

naive

This is the counterpart to the max option and writes the metrics randomly to the disk. It can be used if you need to save CPU power or have fast storage like solid state disk, but be aware that it generates a large amount of IOPS !

sorted

With this option the cache will sort all metrics according to the number of datapoints and write the list to the disk. It works similar to max, but writes all metrics, so the cache will not get to big. This helps to keep the CPU usage low while getting the benefit of caching the metrics in RAM.
All the mentioned options can be controlled with the MAX_UPDATES_PER_SECOND, but each one will be affected in its own way.

Summary

At the end, we made use of the sorted option and spread the workload to multiple cache instances. With this we reduced the amount of different metrics each cache has to process (consistent-hashing relay) and find the best solution in the mix of MAX_UPDATES_PER_SECOND per instance to the related IOPS and CPU/RAM usage. It may sound really low, but currently we are running 15 updates per second for each instance and could increase the in-memory-cache with a low CPU impact. So we have enough resources for fast rendering within graphite-web.
I hope this post can help you in understanding how the cache works and generates the IOPS and system requirements.

Puppet 5 – how new is that!


Have you heard? In July this year Puppet released its’ new software stack of the agent, server and db package to manage, control and orchestrate your IT infrastructure. Enough time has passed for us to test, upgrade and implement it in our environment. With this series we want to introduce some of the new features and inform you about the tasks you need to know or be aware of should you wish to upgrade.
Let us start with the basic changes in the new version. These are for example the switch from PSON to JSON encoding if the agent downloads his information, catalogues or metadata. This will help you to better integrate Puppet in your setup when it needs to communicate with other tools. You can also see an improved performance in handling facts and reports, especially when it matters to process larger quantities.
Another point to mention is the usage of the newer Ruby in version 2.4. Since version 4, Puppet ships all it needs in its’ packages, so you need to reinstall your manually added Puppet agent gems.
And the last point for today should be the version numbering of the new packages. Puppet focuses on keeping all major versions of agent, server and db in one counter and follows the Semantic Versioning as closely as possible. Which is one of the reason for the huge jump in the Puppet server version.
Stay tuned to learn more. And if you need further help or want to learn more about Puppet take a look at our products or training course .

Icinga 2 – Multi-Zonen Notifications

Komplexe Monitoring Umgebungen mit Icinga 2 kennt man ja schon und auch was sich alles mit den Satelliten und zus. Zonen-Mastern anstellen lässt. Aber wisst ihr auch, dass sich gezielte Benachrichtigungen für einzelne Zonen definieren lassen? Die meisten nutzen wahrscheinlich schlicht nur die Haupt/Master Zone für Notifications; aber gehen wir doch von einem nicht unüblichen Beispiel aus : Der externen Überwachung des eigenen Monitorings.
Wir wollen, dass der externer Satellit uns autark kontaktiert sobald das Monitoring ausfällt und im Sinne des Directors, ebenso wenig eine manuell Konfiguration pflegen. Jetzt muss er die Benachrichtigung nur irgend wie zu uns bekommen. Das Wissen über die Objekte sollte bei solchen Setups vorhanden sein, daher werde ich keine Screens oder Config-Auszüge einfügen, sondern nur das Vorgehen beschreiben.
Wie einfach das Ganze mit Zonen-Verzeichnissen und einem Parameter realisiert werden kann, zeigt sich wie folgt. Wir generieren das entsprechende Notification-Command für den Satelliten und stellen sicher, das er es, sowie die betreffenden Kontakte, in seiner Zone finden kann. Anschließend folgt auch schon das Notification Objekt, welches a.) einfach mit in das Zonen-Verzeichnis des Satelliten geschoben, oder b.) global um den Parameter “zone” erweitert wird. Und schon kann es los gehen.
All das lässt sich übrigens auch wunderbar in einem NWS Satelliten abbilden. Probiert es einfach mal aus.

WLAN in deutschen ICEs

WIFIinICE

WLAN im Zug


Seit Anfang diesen Jahres wurde die Angebotspalette in den deutschen ICE Zügen um ein kostenloses WLAN in allen Klassen erweitert. Das kommt den viel reisenden Kollegen von Netways zu gute, welche oft im Zug unterwegs sind. Sei es jetzt unser Consulting Team, der Vertrieb auf dem Weg zum Kundentermin oder unsere Event Abteilung unterwegs zum nächsten Highlight.
Wir wollen das Ganze aber mal etwas genauer unter die Lupe nehmen und schauen, warum es besser ist als ein Hotspot per Handy oder Tablet mit seinem eigenen Mobil-Provider. Hintergrund ist die Technik, welche mit dem Partner Icomera aus Schweden zum Einsatz kommt. Sie koppelt sich parallel zu den 3 großen Anbietern (Telekom, Vodafone, Telefónica) um eine stabile und dauerhafte Verbindung herzustellen und zu gewährleisten. Damit werden Unterbrechungen auf ein Minimum reduziert und treten meist nur in langen Tunnelfahrten auf. Man bleibt aber verbunden und kann im Anschluss sofort weiter surfen.
Zu erwähnen ist noch ein Datenvolumen von 200 MB pro Tag in der 2. Klasse. Ist das Volumen aufgebraucht, wird die Geschwindigkeit reduziert, damit alle Passagiere eine gleichbleibenden Qualität nutzen können. Die Geschwindigkeit nach der Drosselung ist aber noch höher als man sie von Mobilanbietern kennt. Jedoch sollten 200 MB in den meisten Fällen pro Fahrt für eine normale Nutzung ausreichen. Es ist daher zu empfehlen, die WLAN Verbindung als ‘getaktet’ zu markieren um Hintergrundaktivitäten seiner Geräte zu mindern. Unnötige Downloads, Updates oder Streams sollten ebenfalls vermieden werden.
Werfen wir noch einen Blick auf die Sicherheit. Dabei kommen viele moderne Umsetzungen und bekannte Technologien wie z.B. die Client Isolation zum Einsatz. Jedoch ist das ganze immer noch ein HotSpot Angebot und ein Abfangen von Informationen kann nicht grundsätzlich ausgeschlossen werden. Nutzern mit sensiblen Daten wird daher die Verwendung einer VPN Verbindung und das surfen per HTTPS empfohlen.
Als Schlusswort kann ich die Nutzung nur empfehlen und begrüße das neue WLAN in den ICEs. Da ich selbst jede Woche sehr oft 5-6 Stunden pro Fahrt unterwegs bin, kann ich so mein Büro mitnehmen und die Zeit sinnvoll nutzen.
Bei weiterem Interesse, kann man sich auf den Portalen der Deutschen Bahn informieren (hier und hier)

Windows Key im Bios

Diese Ansicht hat fast ausgediehnt
Wir setzen bei unseren Lösungen für das Hosting zwar primär auf Open Source und Linux, aber ab und zu wird doch mal ein Windows Server für einen Kunden benötigt. Und da es seit einiger Zeit Änderungen an der Lizenz oder Install-Medium Mitgabe gab, wollen wir mit diesem Post auf die Besonderheiten in diesem Fall eingehen.
In den betreffenden Fällen (meist OEM Server) wird der Key im Bios hinterlegt und von Windows direkt ausgelesen. Gedanklich klingt dies alles gut und erspart sicher auch einigen Aufwand. Wer solch ein System aber besitzt, wird beim ersten Start und der Grundinstallation dann höflich auf die Generierung eines Recover-Mediums hingewiesen. Da man nicht ohne weiteres an den Key heran kommt oder im Fehlerfall keine CD/DVD mehr hat, raten wir jedem Nutzer/Admin dazu, diese Recover-Medien direkt nach der Grundinstallation anzulegen. Einige Vertreiber bestehen sogar darauf, bevor man das System nutzen kann.
Es sollte aber auch nicht vergessen werden, die Medien von Zeit zu Zeit einmal zu erneuern. Anhand der Größe wird oft ein USB Stick genutzt, und diese können ja auch mal Fehler haben. Soviel dazu für heute. Mögen Euch spätere Probleme damit erspart werden.

Windows und Remote Verbindungen – die 2.

windows-mac-or-linuxVor langer, langer Zeit (zumindest im IT Wesen), hatte ich einmal über die Verwaltung verschiedener Remote Verbindungen unter Windows geschrieben und Achim hat im Gegenzug eine Erklärung für Linux zusammengetragen. Seit dem hat sich einiges geändert und es gibt auch immer was neues, aber im Bereich der Verbindungs-Verwaltung scheint der Trend zu stagnieren. Der Fork mRemoteNG oder Tools wie Terminals scheinen einen Punkt erreicht zu haben, wo alle Bedürfnisse erreicht sind. Letzte Aktivitäten/Updates sind zumindest länger her, aber sie laufen ohne Probleme. Alternativen unter Windows per SSH lassen sich z.B. via PowerShell derzeit realisieren, falls jemand nativ in der PS unterwegs ist.
Man muss und kann also gespannt in die Zukunft schauen und evtl. sogar hoffen, dass sich irgend wann einmal ein Protokoll auf allen Systemen durchsetzt. SSH z.B. kommt unter Windows auch immer stärker zum Einsatz und wäre ein Kandidat hierfür, lassen wir uns überraschen.

Never ending Spam

nospamHeute halten wir uns schlicht und einfach und möchten die Allgemeinheit und die IT-Welt mal wieder vor den ganzen Spam-Wellen warnen. Derzeit kommen diese mit ZIP Files in unterschiedlichsten Zusammenhängen.
Beispiele sind Nachrichten von Ihrer freundlichen Apotheke, der Post/DHL wegen einer Sendung, dem Telefonbetreiber zwecks Rechnung oder Kündigung oder dem Klassiker der Bank. Wer bei seinem Filter Zip als Anhang durchlässt wird es aber auch schwer haben diese Spams derzeit zu filtern. Wieder ein Grund mehr ZIPs nicht als Anhang zuzulassen, E-Mails sind nicht zum File-Transfer entworfen worden 🙂
Es gibt sicher eine Person im Kreis der Verwandten von jedem, wo man sicher ist, das dieser derartige Nachrichten samt Anhang öffnet. Hier kann man nur noch einmal warnen, das z.B. die o.g. Absender einem nicht ohne weiteres eine Mail mit dubiosem Anhang schicken.
Daher bitte weitersagen, das man vor dem öffnen der Anhänge erst einmal die Nachrichten genau prüfen soll. Bin ich überhaupt Kunde, hat der Absender eigentlich die Adresse, wird man direkt angesprochen (Name, Vorname).
Und wer Hilfe bei Setup seines Mailservers braucht kann gern auf unsere Unterstützung zurückgreifen oder den Service direkt bei uns nutzen.

Tools und ihre Begeisterung

AmbitionsbarometerHeute möchte ich mal einen kleinen Rückblick über die von uns genutzten Tools geben und wie der Enthusiasmus sich im laufe der Zeit geändert hat. Denn wer kennt es nicht, kaum gibt es ein neues Tool oder eine Erweiterung und schon denkt man sich “Man, das hätte ich schon immer gebrauchen können. Warum erst jetzt?” oder anders gesagt “Cool” 🙂 Und schon beginnen dann auch die ersten Tests, man setzt sich damit auseinander und versucht den Rest der Belegschaft davon zu überzeugen es auch zu mögen.
Als kleines Beispiel einmal die Tätigkeit des Admins die Server und deren Logs zu prüfen. Fangen wir damit an einzelne Logs zu prüfen und ggf. mit eigenen Checks auf bestimmte Inhalte zu prüfen. Das ganze kommt dann in der nächsten Stufe per Remote-Log schon mal auf einen zentralen Server, wo dies leichter ‘durchgegrast’ werden kann. Immer wieder denkt man sich “Ja, so geht es besser”, aber in der heutigen Zeit steht am Ende ELK und ist wohl auch noch auf längere Sicht das muss dafür.
Oder die Installation und Pflege der Systeme. Ich denke das ‘golden image’ den meisten ein Begriff ist und er durchaus auch heute noch seine Berechtigung hat. Aufgesetzt dazu konnte man mit Verwaltungen wie ClusterShell und Updian schon mal etwas weiter kommen und sich die Arbeit erleichtern. Einen Schub bekam das ganze dann mit Automatisierungen wie Puppet und aktuell lernen die Server mit OpenNebula und Foreman schon das laufen und überrennen uns bald 😀
Kurzum, im Laufe der Zeit wird sich das Barometer der Begeisterung zu den genutzten Tools immer wieder ändern, das hängt von den Anforderungen und Innovationen im Netz ab. Aber es ist interessant sich mal den Wandel dann rückwirkend anzuschauen.