Analyse der Konfigration bei Galera-MySQL-Cluster

Ich möchte in diesem Blog-Beitrag noch Ergänzungen zum Galera-Blog von Marius zum Thema Konfiguration-Check machen.

Zum Beispiel kann man bestimmte Statis abfragen, ob der Cluster synchronisiert ist oder wie viele Nodes der Cluster besitzt und noch einiges mehr.
Kurz zum Verständnis bei MySQL ist das Prozentzeichen(%) das Wildcard wie bei der Bash das Sternchen(*).
Das werde ich Anhand nachfolgender Beispiele erklären.

Die Anzahl der Nodes im Cluster:

mariaDB [(none)]> show status like 'wsrep_cluster_size%';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+

Wie man sehen kann sind hier 3 Nodes im Cluster.

Den aktuellen Sync-Status im Cluster wird so ermittelt:

MariaDB [(none)]> show status like 'wsrep_local_state_comment%';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+

Die Ausgabe sollte hier selbsterklärend sein.

Um alle Statis von dem Cluster abzurufen kann man dieses Kommando benutzen:
show status like 'wsrep_%';
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 25.3.19(r3667) |
| wsrep_ready | ON |
| wsrep_received | 56804 |
| wsrep_received_bytes | 2506329647 |
| wsrep_repl_data_bytes | 352492270

Das ist nur ein kleiner Ausschnitt aus dem Ouput der hier herauskommt

Jetzt kommen wir zur eingestellten Konfiguration, die man hier auch auslesen kann, um spätere Anpassungen vorzunehmen kann.
Die Werte dafür sind in Variablen bei MySQL gespeichert und können wie folgt abgerufen werden:

Die max_allow Variablen kann man so ermitteln:

MariaDB [(none)]> show variables like '%max_allow%';
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| max_allowed_packet | 536870912 |
| slave_max_allowed_packet | 1073741824 |
+--------------------------+------------+

Wenn man hier etwas herumspielt mit den Werten, kann man erstaunliches und informatives herausfinden.

So als kleiner Einstieg sollte dieser Beitrag ausreichen damit man die wichtigsten Einstellungen beim Galera-Cluster ausgegeben bekommt.
Lesenswert Link:
Galera Dokumtentation

Empfehlenswert sind natürlich unsere Schulungen im Bereich, die auf jeden Fall einen Blick wert sind.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Konvertierung des alten ext4 Dateisystems zum btrfs Dateisystem

Da das Datei-System Btrfs schon einige Zeit als “stable” (stabil) angesehen wird, möchte ich hier kurz beschreiben, wie man sein bestehendes ext4 Dateisystem zum btrfs Dateisystem konvertieren kann.

Bevor man mit der ganzen Prozedur anfängt, sollte man sein ext4 Dateisystem einem Filesystem-Check unterziehen um eventuelle Fehler auszumachen.
Ich boote dazu mein System mit einem Live-CD USB-Stick von einer beliebigen Linux Distribution, damit alle Partitionen nicht eingehängt (mounted) sind
So lassen sich alle Filesystem-Checks gut durchführen.
# fsck.ext4 -f /dev/sdX

Gehen wir jetzt mal von einem intakten ext4 Dateisystem aus, kann man jetzt (voraus man hat auch ein Backup erstellt) mit der Konvertierung zum neuen btrfs Dateisystem beginnen.

Wer so eine Konvertierung zum ersten Mal macht, sollte eine andere Partition als der root-Partition wählen, da bei dieser noch weitere Nacharbeiten zu erledigen sind.

Prüfen, ob die btrfs-tools installiert sind:
# # rpm -qa | grep btrfs --> rpm-based Linux Distros
btrfsprogs-4.5.3-6.3.x86_64

# dpkg -l | grep btrfs --> deb-based Linux Distros
ii btrfs-tools 3.12-1ubuntu0.1

Mit folgendem Befehl startet man die Konvertierung:
ca. 20% freier Speicherplatz sollte für die Konvertierung vorhanden sein.
# btrfs-convert /dev/sdX
Es wird automatisch ein btrfs subvolume erstellt das sich ext4_saved nennt erstellt, das eine spätere Rückkonvertierung zum alten ext4 Dateisystem ermöglicht.

Nach erfolgreicher Konvertierung muss man diese Partition einhängen und noch den mountpoint Typ im der Datei ‘/etc/fstab’ abändern:
mount /dev/sdX /mnt
# vim /mnt/etc/fstab
z.B
UUID=e52d7524-230c-413e-9c26-8c94b94c34b2 /home btrfs defaults 0 0

Man ändert hier von ext4 auf btrfs und speichert die Datei wieder ab. Anschließend erfolgt eine Neustart des Systems
um abschließend die Funktion zu testen.

Mit folgendem Befehl wird die Rückkonvertierung zu ext4 ermöglicht:
# btrfs-convert -r /dev/sdX

So nun kann man das neue Datei-System auf Herz und Nieren testen, für mich hat es den Langzeittest schon bestanden, da ich es fast überall seit langem auf meinen Systemen einsetze, z.B RAID5 beim Server oder auch als home-Partition, die automatische Snapshot-funktion mit Snapper finde ich besonders gelungen. Bei SUSE Enterprise Server oder openSUSE-Leap/Tumbleweed ist es Standard als root-Filesystem.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Icinga Web 2 Modul fileshipper imports im Director

Es werden viele Importe im Icinga Web 2 Modul Director via Ldap / SQL-Ressource getätigt, aber viele übesehen eine einfache Möglichkeit bestehende Dateien mittels Icinga 2 Modul “fileshipper” in den Icinga Web 2 Director zu importieren. Wie man dieses umsetzt werde ich an einem einfachen Beispiel, einer CSV-Datei hier beschreiben.

Zuerst muss man sich das Fileshipper-Modul von Github per “git clone” oder .zip-Datei herunterladen und in dem Verzeichnis '/usr/share/icingaweb2/modules/' ablegen und anschießend das Verzeichnis in “fileshipper” umbennen, denn sonst erkennt es Icinga Web 2 als Modul nicht an.
# cd /usr/share/icingaweb2/modules/ && git clone https://github.com/Icinga/icingaweb2-module-fileshipper.git
oder
# cd /usr/share/icingaweb2/modules/ && unzip master.zip

Anschließend muss das neu installierte Modul noch aktiviert werden,  mit dem icingacli Kommando:
# icingacli module enable fileshipper
icingacli module list
MODULE VERSION STATE DESCRIPTION
director 1.3.1 enabled Director - Config tool for Icinga 2
doc 2.4.1 enabled Documentation module
fileshipper 1.0.0 enabled Fileshipper for Icinga Director
monitoring 2.4.1 enabled Icinga monitoring module

Es geht aber aber auch über die Icinga Web 2 –  Oberfläche siehe Screenshot:

Nachdem das Modul installiert und aktiviert ist kann es losgehen. Zuerst erstellt man das Verzeichnis “fileshipper” unter # mkdir /etc/icingaweb2/modules/fileshipper und erstellt eine import.ini Datei in der das Verzeichnis angeben wird, wo sich die zu importierenden Dateien (.csv) liegen.
[fileshipper files]
basedir = "/usr/local/share/"

Dann wird im Icinga Web 2 => Director => Automation => Add Import Source

ein Name des zukünftigen Imports z.B fileshipper-import-hosts vergeben und bei Source “Import from files (fileshipper) ausgewählt.

Jetzt muss die neue Import-Quelle noch modifiziert werden z.B. so:

Ich denke das Bild ist selbsterklärend und Bedarf keiner weiteren Erklärung.

Jetzt kann man einen Import run starten in dem man auf die Import-Source fileshipper-import-hosts und Trigger Import Run auswählt.

Nun sollte in der Voransicht (Preview) die importierten Hosts sichtbar werden.

Um jetzt aus diesen RAW-Daten Icinga 2 konforme Objekte werden zu lassen brauchen wir eine Sync-Rule die man z.B.so anlegt:


Hier wird in der Maske angeben, welcher Typ (Host-Objekt) daraus werden soll und ob bereits existierende Daten ersetzt (replace) oder zusammengeführt (merge) werden sollen.
Mit Purge können bereits existierende Daten gelöscht werde, JA oder NEIN.

Im Kartei-Reiter “Properties/Eigenschaften” werden die Felder vom Import (Source/Quelle) den Icinga 2 konformen Zielen (Destination) zugeordnet:

Danach kann der Sync-Run der erstellten Sync-Rule gestartet werden und bei erfolgreichen Lauf, werden Konfigurations-Dateien erstellt und sind bereit für den Director zu deployen.

Im Activity-Log kann der Vorgang nochmals überprüft werden, bevor man die Konfiguration per Director deploy übernehmen kann.

So jetzt sollten nach erfolgreichem Deployment die Hosts im Icinga Web 2 unter Hosts sichtbar sein.

 

Im Rahmen einer Icinga 2 Fundamentals Schulung, die wir anbieten, werden auch noch weitere Import-Quellen besprochen und praktisch vollzogen.

Unter anderem haben wir noch weitere Schulungen zu Open Source Themen im Portofolio, einen Überblick bekommen Sie hier bei NETWAYS-Schulungen.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

PNP4Nagios RRD Single/Multiple Storage

pnp4nagiosFür alle die das Nagios Plugin PNP4Nagios mit Icinga2 einsetzen, werden eventuell schon über folgende Fehlermeldung gestolpert sein,
oder noch stolpern:

/var/log/messages:
NPCD[65119]: ERROR: Executed command exits with return code '7'

/var/log/pnp4nagios/perfdata.log:
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Timeout after 15 secs. ***
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Deleting current file to avoid NPCD loops
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Please check your process_perfdata.cfg
Einstellung:
'/etc/pnp4nagios/process_perfdata.cfg'
Option
RRD_STORAGE_TYPE = SINGLE

Ab der PNP-Version 0.6 ist es möglich, die Performance-Daten nicht in einer einzelnen RRD-Datenbank (SINGLE), sondern in mehreren RRD Datenbanken (MULTIPLE) zu speichern.
Diese Einstellung in der Konfigurations-Datei sollte NICHT global verändert werden, da PNP4Nagios nach dieser Umstellung auf MULTIPLE sofort beginnt, neue RRD-Files anzulegen. Alte Daten gehen damit sofort verloren!

Auf Grund der Performance ist es nicht sinnvoll, global mit RRD_STORAGE_TYPE = MULTIPLE zu arbeiten, da die Anzahl der RRD-Datenbanken und somit auch der Disk-I/O während der Updates sich vervielfachen würde. Deshalb sollte man überlegen, welche Nagios Checks mit dieser Einstellung gefahren werden.
Bestehende RRD-Datenbanken können über einen Konverter (Perl-Skript) '/usr/libexec/pnp4nagios/rrd_convert.pl' konvertiert werden.

Folgende Ausgabe bekommt man bei Ausführung des Perl-Skriptes:

Usage: /usr/libexec/pnp4nagios/rrd_convert.pl --check_command=
--cfg_dir= [ --list_commands ]
[ --dry-run ]
[ --tmp_dir= ]
[ --no_structure_check ]

Schaut dann so in etwa aus:

rrd-convert

# sudo -su icinga /usr/libexec/pnp4nagios/rrd_convert.pl --cfg_dir=/etc/pnp4nagios/ --check_command=disk --dry-run

Search pattern disk
XML Files analyzed 129
XML Files found 7
XML Files without RRD 0
Old XML Files ignored 0
Number of unique check_commands 15
Dry run? [YES]
Temp Directory /tmp/rrd_convert

This is only a 'dry run'. The new RRD Files are stored in '/tmp/rrd_convert'

Start Converter [n|y]?:y
File 1/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk__.dump
Manipulating /tmp/rrd_convert/icinga2-disk__.dump
............ done 47999 lines
Restoring File
/tmp/rrd_convert/icinga2/disk____.rrd
... done
File 2/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk.dump
Manipulating /tmp/rrd_convert/icinga2-disk.dump
............ done 48424 lines
Restoring File
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_manifests-a11d1078b1b1f2e3bdea27312f6ba513.rrd
/tmp/rrd_convert/icinga2/disk__vagrant.rrd
/tmp/rrd_convert/icinga2/disk__.rrd
/tmp/rrd_convert/icinga2/disk__boot.rrd
/tmp/rrd_convert/icinga2/disk__home.rrd
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_modules-41d422e93c9413f221fcbaa64a7964b7.rrd
... done
DONE

Schauen Sie doch einfach mal auf unserer Webseite vorbei, wir biete Schulungen zu vielen interessanten OpenSource-Themen an.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Vagrant-Box mit Icinga2 mit Icingaweb2 aufsetzen

Vagrant-Box mit Icinga2 mit Icingaweb2 aufsetzen

virtualboxAls Entwickler und Systemadministrator kommt man öfters nicht um eine Testmöglichkeit herum.
Eine VM mit einem Hypervisor seiner Wahl aufzusetzen ist meistens sehr zeitaufwendig um kleinere Tests nachzustellen.
Eine einfache und schnelle Möglichkeit bietet hier sich eine Vagrant-Box vom Internet herunter zu laden oder sich ein Git-Repositoriy mit einem vorgefertigten Image zu clonen.
Wie man sich so eine Vagrant-Box per Git cloned werde ich hier beschreiben.

 

Vorraussetzung: Virtualbox-Pakete + GIT sollten installiert sein (Virtualbox wird hier als Provider benutzt):

~ # rpm -qa | grep virtualbox
virtualbox-5.0.18-216.2.x86_64
virtualbox-guest-tools-5.0.18-216.2.x86_64
virtualbox-host-kmp-default-5.0.18_k4.1.12_1-216.2.x86_64
virtualbox-qt-5.0.18-216.2.x86_64
virtualbox-guest-kmp-default-5.0.18_k4.1.12_1-216.2.x86_64
git-2.6.6-7.1.x86_64

Info: Die Version kann von den verschiedenen Distributionen variieren.

Als nächsten müssen wir das Git-Repository lokal clonen
Dazu ins home – Verzeichnis in der Shell seiner Wahl wechseln
Ein Verzeichnis seiner Wahl anlegen:
mkdir git z.B

und in diesem Verzeichnis folgendes Kommando ausführen als user versteht sich:

~ # git clone https://github.com/Icinga/icinga-vagrant
Klone nach 'icinga-vagrant' ...
remote: Counting objects: 5172, done.
remote: Total 5172 (delta 0), reused 0 (delta 0), pack-reused 5172
Empfange Objekte: 100% (5172/5172), 1.53 MiB | 569.00 KiB/s, Fertig.
Löse Unterschiede auf: 100% (1929/1929), Fertig.
Prüfe Konnektivität ... Fertig.

So das wars auch fast schon 🙂

Jetzt z.B in das Verzeichnis Icinga2x-cluster wechseln
~ # cd icinga-vagrant/icinga2x-cluster/

Anschließend nur noch die Vagrant-Box starten:
~ # vagrant up

Nun kann es eine Weile dauernd bis die Box gebaut wird, wenn keine Fehler aufgetreten sind kann man sich per ssh connecten.
~ # vagrant ssh
[vagrant@icinga2 ~]$

Weitere vagrant Kommandos:

vagrant help    -> Listet weitere Kommandos von vagrant auf
vagrant halt  -> fährt  die Vagrant-Box herunter  (shutdown)
vagrant reload -> starten die Vagrant-Box neu (reboot)

Login-Information bekommt man direkt auf:
https://github.com/Icinga/icinga-vagrant/

Icingaweb2 nach erfolgreichen Login:

Screenshot_20160603_105621

Viel Spaß beim testen, basteln und herumspielen 🙂

Es lohnt sich auch immer mal unser Schulungsangebot sich anzuschauen.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren