Bursting und Throtteling in OpenStack

Wir haben die vergangenen Monate genutzt, um eine neue Cloud mit OpenStack aufzubauen. Im Zuge dessen, mussten wir eine Möglichkeit finden, die IOPS sowie die Bandbreite, die VMs zur Verfügung haben, zu limitieren.
Das Limitieren der Bandbreite sowie der IOPS erfolgt in OpenStack in sogenannten Flavors. In einem deutschsprachigen Interface von OpenStack werden diese “Varianten” genannt. Flavors werden hier als VM-Templates genutzt, mit denen sich VMs starten lassen. Es werden hier Ressourcen geregelt wie RAM, CPU und Firewallregeln aber eben auch die Limitierungen. Gesetzte Werte können nicht in laufenden VMs überschrieben werden. Möchte man diese ändern, muss die VM gelöscht und neu gebaut werden, nachdem die neuen Werte im Flavor angepasst wurden. Ein Rebuild reicht hier nicht aus.
Hier gibt es jedoch eine Ausnahme. Durch den Einsatz von beispielsweise libvirtd, können jene Beschränkungen mittels “virsh” angepasst werden.

Was sind IOPS und Bandbreite?

Bandbreite und IOPS geben an, wieviel Datendurchsatz sowie Lese und Schreiboperationen einer VM zugeteilt sind. Per Default sind diese unlimitiert, was unter gewissen Umständen zu Problemen führen kann.

Wieso sind Limitierungen sinnvoll?

In einer Cloud mit mehreren Virt-Systemen laufen mehrere VMs. Sind keine Limitierungen gesetzt, kann jede VM soviel Traffic und IOPS erzeugen, wie sie gerade braucht. Das ist natürlich für die Performance entsprechend gut, jedoch verhält es sich dadurch so, dass andere VMs auf dem gleichen Virt entsprechend unperformanter werden. Limitierungen werden daher dazu genutzt ein gleiches Niveau für alle VMs zu schaffen.

Bandbreite

Average

  1. quota:vif_inbound_average
  2. quota:vif_outbound_average

Wie der Name schon sagt, beschränkt man hier inbound (eingehenden) sowie outbound (ausgehenden) Traffic durch einen durchschnittlichen Wert, den diese beiden nicht überschreiten dürfen.

Peak

  1. quota:vif_inbound_peak
  2. quota:vif_outbound_peak

Die Bandbreite kann man auch mit Peak sowie Burst begrenzen. Peak gibt hierbei an, bis zu welchem Limit die Bandbreite genutzt werden darf, als absolutes Maximum. Dieser Wert funktioniert aber nur in Zusammenarbeit mit “Burst”.

Burst

  1. quota:vif_inbound_burst
  2. quota:vif_outbound_burst

Burst gibt nämlich an, wie lange die Bandbreite im Wert “Average” überschritten werden darf. Gemessen wird hier in KB. Setzt man also den Burst auf 1.048.576 KB, darf der Peak Wert solange genutzt werden, bis 1GB (1.048.576 KB) an Daten übertragen wurden. Zu Beachten ist aber, dass dieser Wert für jeden Zugriff neu gilt. Führt man also 3 Kommandos hintereinander aus (3x wget mit && verknüpft) greift der Burst für alle 3 gleichermaßen. Führt man die gleichen Kommandos ebenfalls hintereinander aus, aber verknüpft diese mit einem Sleep, greift der Burst für jedes Kommando neu.

 

IOPS

Throttle

  1. quota:disk_read_iops_sec
  2. quota:disk_total_iops_sec
  3. quota:disk_write_iops_sec

Die lesenden und schreibenden Prozesse der VMs können natürlich auch begrenzt werden. Hier gibt es zwei Möglichkeiten:

  • Limitierung von lesenden sowie schreibenden Prozessen separat
  • Limitierung auf absoluten Wert

Beides in Kombination geht nicht. Es nicht möglich zu konfigurieren, dass es 300 lesende, 300 schreibende und 700 insgesamte IOPS geben soll, würde aber auch keinen Sinn machen. Zu beachten ist, wenn alle 3 Werte gesetzt werden, können diese in einen Konflikt geraten und gegebenenfalls gar nicht greifen.

Burst

  1. quota:disk_write_iops_sec_max
  2. quota:disk_write_iops_sec_max_length

Durch das Bursting auf den Festplatten direkt, kann angegeben werden, mit welcher maximalen Anzahl an IOPS (quota:disk_write_iops_sec_max)eine VM die oben gesetzten Werte, für wie lange (quota:disk_write_iops_sec_max_length) überschreiten darf. Sinnvoll wäre dies, wenn bekannt ist, dass gewisse Prozesse kurzzeitig mehr IOPS benötigen, als freigegeben ist.

Beispiele

Um Limitierungen zu setzen, wird zunächst ein Flavor benötigt. Im Anschluss können die Werte gesetzt werden. Die Dokumentation zum Anlegen von Flavors gibts hier

openstack flavor set {$flavor} --property quota:{$param}={$value}
quota:disk_read_iops_sec='200'
(quota:disk_total_iops_sec='1000')
quota:disk_write_iops_sec='200'
quota:vif_inbound_average='10240'
quota:vif_inbound_burst='20480'
quota:vif_inbound_peak='15360'
quota:vif_outbound_average='10240'
quota:vif_outbound_burst='20480'
quota:vif_outbound_peak='15360'
quota:disk_write_iops_sec_max_length='10'
quota:disk_write_iops_sec_max='1000'

In diesem Beispiel würde man zum Beispiel die lesenden Prozesse auf 200 (quota:disk_read_iops_sec='200') beschränken, ebenso die schreibenden, bei einer eingehenden Brandbreite von 10MB(quota:vif_inbound_average='10240'). Peak liegt bei 20MB und darf für 15MB erreicht werden. Das ist natürlich ein sehr unrealistisch minimalistisches Begrenzungsbeispiel, jedoch sollte die Art und Weise wie es funktioniert verdeutlich worden sein.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Linux Netzwerkschnittstellen mit check_nwc_health überwachen

Quelle: 9gag.com

Olá!

Heute möchte ich euch zeigen wie ihr lokale Netzwerk Schnittstellen unter Linux ganz einfach mit dem Plugin check_nwc_health überwachen könnt. Für die Demonstration verwende ich eine VirtualBox Maschine mit CentOS Linux 7.5.1804 (Core) und Icinga 2.9.1.

Anmerkung: Zusätzliche Icinga 2 Plugins werden im besten Fall unter /usr/lib64/nagios/plugins/contrib installiert. Hierfür muss die Konstante PluginContribDir (/etc/icinga2/constants.conf) angepasst werden da diese per se auf /usr/lib64/nagios/plugins zeigt.

 

[root@centos7 ~]# mkdir -pv /var/lib64/nagios/plugins/contrib
[root@centos7 ~]# vi /etc/icinga2/constants.conf
- const PluginContribDir = "/usr/lib64/nagios/plugins"
+ const PluginContribDir = "/usr/lib64/nagios/plugins/contrib"

Dann kann es auch schon los gehen! Zunächst müssen fehlende Pakete installieren sowie das Plugin heruntergeladen und kompilieren werden:

[root@centos7 ~]# yum install -y perl-Net-SNMP perl-Data-Dumper perl-Module-Load
[root@centos7 ~]# cd /tmp
[root@centos7 tmp]# wget https://labs.consol.de/assets/downloads/nagios/check_nwc_health-7.2.tar.gz
[root@centos7 tmp]# tar -xvzf check_nwc_health-7.2.tar.gz
[root@centos7 tmp]# cd check_nwc_health-7.2
[root@centos7 check_nwc_health-7.2]# ./configure \
  --libexecdir=/usr/lib64/nagios/plugins/contrib \ 
  --with-statesfiles-dir=/var/cache/icinga2 \ 
  --with-nagios-user=icinga \
  --with-nagios-group=icinga
[root@centos7 check_nwc_health-7.2]# make
[root@centos7 check_nwc_health-7.2]# make install

Nun sollte man das Plugin im Verzeichnis /usr/lib64/nagios/plugins/contrib vorfinden. Im Endeffekt waren das jetzt auch schon alle Schritte. Nun können wir folgende Befehle einfach ausführen:

[root@centos7 check_nwc_health-7.2]# cd /usr/lib64/nagios/plugins/contrib
[root@centos7 contrib]# sudo -u icinga ./check_nwc_health --hostname localhost --servertype linuxlocal --mode interface-health

Ausgabe

Schnittstelle eth0

OK - eth0 is up/up, interface eth0 usage is in:0.00% (0.06bit/s) out:0.00% (0.00bit/s), interface eth0 errors in:0.00/s out:0.00/s , interface eth0 discards in:0.00/s out:0.00/s , interface eth0 broadcast in:0.00% out:0.00%

Schnittstelle eth1

eth1 is up/up, interface eth1 usage is in:0.00% (0.00bit/s) out:0.00% (0.00bit/s), interface eth1 errors in:0.00/s out:0.00/s , interface eth1 discards in:0.00/s out:0.00/s , interface eth1 broadcast in:0.00% out:0.00%

Schnittstelle lo

lo is up/up, interface lo usage is in:0.00% (0.00bit/s) out:0.00% (0.00bit/s), interface lo errors in:0.00/s out:0.00/s , interface lo discards in:0.00/s out:0.00/s , interface lo broadcast in:0.00% out:0.00%

Performancedaten

'eth0_usage_in'=0%;80;90;0;100 'eth0_usage_out'=0%;80;90;0;100 'eth0_traffic_in'=0.06;0;0;0;0 'eth0_traffic_out'=0.00;0;0;0;0 'eth0_errors_in'=0;1;10;; 'eth0_errors_out'=0;1;10;; 'eth0_discards_in'=0;1;10;; 'eth0_discards_out'=0;1;10;; 'eth0_broadcast_in'=0%;10;20;0;100 'eth0_broadcast_out'=0%;10;20;0;100 'eth1_usage_in'=0%;80;90;0;100 'eth1_usage_out'=0%;80;90;0;100 'eth1_traffic_in'=0.00;0;0;0;0 'eth1_traffic_out'=0.00;0;0;0;0 'eth1_errors_in'=0;1;10;; 'eth1_errors_out'=0;1;10;; 'eth1_discards_in'=0;1;10;; 'eth1_discards_out'=0;1;10;; 'eth1_broadcast_in'=0%;10;20;0;100 'eth1_broadcast_out'=0%;10;20;0;100 'lo_usage_in'=0%;80;90;0;100 'lo_usage_out'=0%;80;90;0;100 'lo_traffic_in'=0.00;0;0;0;0 'lo_traffic_out'=0.00;0;0;0;0 'lo_errors_in'=0;1;10;; 'lo_errors_out'=0;1;10;; 'lo_discards_in'=0;1;10;; 'lo_discards_out'=0;1;10;; 'lo_broadcast_in'=0%;10;20;0;100 'lo_broadcast_out'=0%;10;20;0;100

Icinga Web 2

check_nwc_health hält noch viele andere Möglichkeiten bereit die vom Umfang her, aber den Rahmen dieses Blogposts sprengen würden. Daher würde ich euch gerne auf die Dokumentation verweisen. In diesen Sinne verabschiede ich mich auch schon wieder und wünsche euch viel Spaß beim implementieren und basteln 🙂

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

NWS | Neuerungen und Updates

Die letzten Wochen hat sich auf unserer NWS Plattform sehr viel getan. Wir möchten uns an dieser Stelle auch bei unseren Nutzern bedanken, die Verbesserungsvorschläge der Apps an uns reported haben. Aufgrund dieser Aussagen ist es uns möglich, uns und NWS selbst stetig zu verbessern und so schließlich auch das Erlebnis der User zu verbessern! Im Folgenden möchte ich etwas darauf eingehen, welche Neuerungen die letzten Wochen vorgenommen wurden.

Migration der NWS Plattform auf OpenStack

Ein sehr großer Teil, wenn nicht sogar der größte Teil, war die Migration unserer Server auf das neue OpenStack Setup an unserem neuem RZ-Standort. Neue Server, neue Technologie und ein neues Rechenzentrum. All das ermöglicht uns eine Performance-Steigerung der Produkte sowie unserer Anwendung selbst. Es wurde hier eine komplett neue Umgebung aufgebaut, auf der nun auch NWS läuft. Die alte Umgebung wurde komplett abgeschaltet.

Gitlab-CE / Gitlab-EE

Natürlich haben wir auch Updates eingespielt. Gitlab-CE sowie Gitlab-EE wurde auf die Version 11.0.4 angehoben. Diese Version bringt AutoDevOps mit sich und diverse andere Neuerungen.

Icinga2 Satellite

Unsere Satelliten wurden auf die aktuelle Icinga2 Version angehoben, welche aktuell die 2.9.0-1 ist.

Icinga2 Master

Die Master App wurde ebenso auf die 2.9.0-1 angehoben. Wir haben hier auch das eingesetzte Grafana aktualisiert auf die Version 5, welches ein komplett neues Interface mit sich bringt. Ein Update für das neue icinga2-Web steht noch aus!

SuiteCRM

Die Version von SuiteCRM selbst, welche bisher bei NWS im Einsatz war, hatte leider einige wenige Bugs. Diese konnten wir mit der neuen Version 7.10.7 beheben und so die Produktivität der App verbessern. Wir haben hier auch kleinere Änderungen am Aufbau und Konfiguration der Container vorgenommen, welche die Start-Zeit enorm verkürzt haben. Hierzu beigetragen haben auch die Ressourcen, wovon wir den Containern mehr zuteilen.

Rocket.Chat

Rocket.Chat wurde mit der Version 0.66.3 auf die aktuellste verfügbare Version erhöht. Wir haben hier auch den Begrüßungstext, der in der Instanz angezeigt wird durch ein kleines “HowTo” ersetzt, um einen leichteren Einstieg in diese App zu ermöglichen.

WordPress

Auch WordPress wurde mit einem Update versehen. Wir haben hier die Version 4.9.7 aktiviert. Diese Version ist ebenso wie 4.9.6 DSGVO konform.

Nextcloud Verbesserungen

Wir haben einige Reports bekommen, dass die Performance unserer Nextcloud App noch verbesserungsfähig ist. Wir haben aufgrund dieser, gewisse Verhalten nachstellen können und konnten so die dafür verantwortlichen Fehler finden und beheben. Unsere Arbeiten resultierten in einer wesentlichen Performance-Steigerung der App, vor allem im Bereich der Dokumente, der Foto Galerie, sowie des Logins.

Diverse Fehlerbehebungen / Verbesserungen

Wie oben bereits erwähnt, haben wir unter anderem durch die Reports unserer Nutzer Fehlerstellen gefunden und konnte diese beheben. Daraus resultierend hat sich die Start-Zeit der Apps verkürzt, was wir auch bei den Restarts und bei den Updates beobachten konnten. Dies erleichtert uns natürlich die Wartungsarbeiten aber auch die Downtimes für unsere Nutzer, sofern ein Restart einmal nötig sein sollte. Wir haben ebenso falsche/hängende Flows gefunden, welche bisher dafür gesorgt haben, dass Container innerhalb eines Setups gelegentlich die Connection zueinander verlieren konnten. Dieser Fehler wurde behoben und tritt derzeit nicht mehr auf. Wir sind stets dabei weitere Verbesserungen vorzunehmen und Neuerungen zu testen. Um hier Up-to-date zu bleiben, kann ich unseren Twitter Account empfehlen. Hier werden alle Updates regelmäßig veröffentlicht!

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Microsoft and GitHub – merge conflict?

For some time it has become clear that Microsoft is going to take over GitHub. As far as official sources can be trusted, GitHub will stay independent although a new CEO (Nat Friedman) will be introduced after the Microsoft takeover.

This question over GitHub’s future independence has raised a lot of skepticism within the developer community and many are considering moving their projects away from GitHub to a different location.

One alternative in this case could be GitLab. GitLab does not only have an online platform but it can as well be installed on your own hardware. Furthermore, it is an extremely solid piece of Open Source software you can fully rely on. This is also shown by the makers of GitLab themselves as they release updates each month – rolling out bug fixes, security updates and many recommendations regarding the use and configuration of your instance.

For those who would like to have their own GitLab instance, NETWAYS offers two options:

First one is available on our NETWAYS Web Services platform where we offer user-managed, hosted GitLab instances as Community or Enterprise Edition. The user does not need to take care of anything regarding installation or maintenance of his GitLab, but can directly go into production in no time with only a few steps needed. You as a customer are also free to decide for how long you would like to run your instances as any app is monthly callable. Furthermore, we regularly update these container based apps and monitor their health  for you. As a customer, you can register on NWS and try all the apps we offer 30 days for free.

The second product we offer is done by NETWAYS Managed Services which is exactly what it is called: With managed hosting you can get a virtual machine in our cloud or rented hardware running a full GitLab, either as Community or Enterprise Edition. You can choose the underlying ressources and we will do the rest for you, like installation with individual parameters and health monitoring. With managed hosting, our customers also have the choice to go full 24/7 support with “emergency” calls.

Nicole Lang

Autor: Nicole Lang

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 Bücher und zockt auch mal gerne.

For a Handful of (Vagrant) Boxes

Servus alle miteinand,

Wer kennt das folgende Szenario nicht? Mit viel neuer Software, welche gerade (manuell) getestet werden muss, dachte ich mir, ich baue mal schnell eine Vagrant Box auf Basis von Debian 9, um Tests unter einem Stretch durchzuführen.

Falsch gedacht !!

Anstelle eines libvirt install auf der Kommandozeile und eines tar-Befehls zum Packen des eigentlichen Box-Images,
musste ich mit einer kleinen Widrigkeiten im Bereich der Netzwerkkonfiguration kämpfen.

Aber eins nach dem anderen.
Fangen wir mit dem Image für die libvirt Maschine an:

virt-install --name=linuxconfig-vm \
--vcpus=1 \
--memory=1024 \
--cdrom=/tmp/debian-9.4.0-amd64-netinst.iso \
--disk size=10 \
--os-variant=debian9

Dies war noch der unproblematische Teil der Installation.
Danach erfolgt in der VM das nachziehen von Berechtigungen für den Vagrant User.

sudo visudo -f /etc/sudoers.d/vagrant
vagrant ALL=(ALL) NOPASSWD:ALL

Hinzufügen des Vagrant public Keys:

mkdir -p /home/vagrant/.ssh
chmod 0700 /home/vagrant/.ssh
wget --no-check-certificate \
https://raw.github.com/mitchellh/vagrant/master\/keys/vagrant.pub \
-O /home/vagrant/.ssh/authorized_keys
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown -R vagrant /home/vagrant/.ssh

Wenn man nicht so Wach war, um rechtzeitig im Installationsmenü schon SSH mitzuinstallieren, muss es per Hand nachgeholt werden:

sudo apt-getinstall -y openssh-server
sudo nano /etc/ssh/sshd_config
AuthorizedKeysFile %h/.ssh/authorized_keys

Danach kann das System so präpariert werden, wie man es benötigt.

Das Image der VM noch verkleinern und in box.img umbenennen:

qemu-img convert -c -O qcow2 debian9.qcow2 small.qcow2
mv small.qcow2 box.img

Alles handlich verpacken und dem Vagrant Box Store hinzufügen:

tar czvf debian9.box ./metadata.json ./Vagrantfile ./box.img
vagrant box add --name debian9 debian9.box

Hier allerdings fingen meine Probleme an.
Nach dem Packen der Box, dem Hinzufügen zum Boxstore und einem Erwartungsvollen “vagrant up” erhielt ich “==> default: Waiting for domain to get an IP address…”, was zu keinem Erfolg führte und ich wahrscheinlich jetzt immer noch warten würde.

Nach einem erneuten Hochfahren der VM mit dem virt-manager und nachschauen, ob das network device fehl konfiguriert ist, konnte ich keinen Fehler feststellen.

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Gefühlte Jahrtausende von Recherche später, wurde mir folgendes klar:

Debian hat in neuen Versionen eine Änderung der Device-Namen vorgenommen.
Vagrant wartet vergeblich auf “eth0”, weil ein network device Namens “ens21” existiert, wenn ich die VM mit “vagrant up” starte.

Also zurück in die VM und das folgende Kommandos abgesetzt:

sudo nano /etc/default/grub

Im Editor dann folgende Anpassungen vornehmen:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

Damit das auch greift, muss abschließend die Konfiguration für den Grub-Bootmanager neu erstellt werden:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Reboot. “vagrant up” und Tada … Spannung Trommelwirbel => Tusch ! Die VM erhält eine IP und startet wie man es schon von Anfang an erwartete.

Ich hoffe ich konnte damit den ein oder anderen vor dem Verlust von allzuviel Lebenszeit bewahren.

Ein sonniges WE wünscht

David Okon

Autor: David Okon

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Konfiguration mit Lsyncd synchronisieren

Hallo!

Heute möchte ich euch ein Tool vorstellen mit dem man relativ einfach, sicher und in nahezu realzeit Konfiguration auf andere Systeme und umgekehrt synchronisieren kann. Das Tool hoert auf den Namen Live Syncing (Mirror) Daemon, oder kurz gefasst Lsyncd.

Als erstes möchte ich etwas auf die Magie von Lsyncd eingehen, damit man einen Eindruck bekommt wie das Tool arbeitet und was für Möglichkeiten sich ergeben. Lsyncd verwendet unter Linux inotify und unter MacOS FSEvents um Änderungen am Verzeichnissbaum zu beobachten. Anhand dieses “Monitorings” kann Lsyncd feststellen, ob Änderungen im zur synchronisation bestimmten Verzeichnis passiert sind. Ist dies der Fall, startet Lsyncd die synchronisation mit den zuvor entsprechend gesetzten Parametern. Die Parameter sind z.B. welches Verzeichniss von soll wohin repliziert werden und welches Protokoll soll dafür genutzt werden z.B. rsync.

Kommen wir zum interessanteren Teil die Installation und Konfiguration von Lsyncd. In den meisten Distributionen ist Lsyncd bereits als fertiges Paket vorzufinden. Für die demonstration verwende ich eine CentOS 7.x Maschine in VirtualBox auf einem Laptop.

Vorbereitung/Installation (CentOS 7.x)

Zunächst installieren wir das lsyncd Paket mittels YUM und generieren bzw. verteilen anschließend unseren SSH-Key den wir später für Lsyncd nutzen.

[root@lsyncdemo ~]# yum install lsyncd
[root@lsyncdemo ~]# ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519): /root/.ssh/id_lsync
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_lsyync.
Your public key has been saved in /root/.ssh/id_lsyync.pub.
The key fingerprint is:
SHA256:ntsHfyqPkwffQ3IPMUkZ6kIOMdSBqVhREwgag7V1TgI root@lsyncdemo
The key's randomart image is:
+--[ED25519 256]--+
| oE.+.+=B=.. .o |
|. * =o o+. .o |
| o o... . .. . |
| . . + . + |
| S o . o |
| . .o.. + |
| o * = o |
| o+.= + .|
| . o*oo . |
+----[SHA256]-----+
[root@lsyncdemo ~]# ssh-copy-id -i /root/.ssh/id_lsync i2node01

Konfiguration

Nun kommen wir zur Konfiguration unseres Lsyncd, hierfür existiert genau eine Konfigurationsdatei unter /etc/ (equivalenter pfad osx) mit dem Namen lsyncd.conf. Für unser Beispiel synchronisiere ich Verzeichnis mit Konfiguration auf meinen Icinga2 Master (i2node01).

[root@lsyncdemo ~]# vi /etc/lsyncd.conf
<...
- sync{default.rsyncssh, source="/var/www/html", host="localhost", targetdir="/tmp/htmlcopy/"} //Beispiel Konfiguration entfernen

+ sync{ //Icinga Configuration
+  default.rsync, //Wir nutzen rsync zum Synchronisieren
+  source="/home/mdeparade/icinga2/scripts", //Das Quellverzeichnis
+  target="i2node01:/etc/icinga2/scripts", //Das Zielverzeichnis
+  rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,}
+ }
...>

Kurze Erläuterung: Die letzte Zeile unserer Konfiguration gibt rsync noch ein paar Informationen mit: Wir bauen einen SSH-Tunnel als Benutzer root auf, mit dem SSH-Key “id_lsync”, anschließend sagen wir noch das alle Berechtigungen der Dateien/Verzeichnisse erhalten bleiben sollen.

Abschluss

Nachdem wir Lsyncd mit Konfiguration versorgt haben, können wir diesen direkt starten und Überprüfen ob unser Synchronisation auch ordnungsgemaess funktioniert:

[root@lsyncdemo ~]# cat /etc/lsyncd.conf
----
-- User configuration file for lsyncd.
--
-- Simple example for default rsync, but executing moves through on the target.
--
-- For more examples, see /usr/share/doc/lsyncd*/examples/
--
sync{
default.rsync,
source="/home/mdeparade/icinga2/scripts",
target="i2node01:/etc/icinga2/scripts",
rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,} 
}
[root@lsyncdemo ~]# systemctl enable lsyncd --now
[root@lsyncdemo ~]# systemctl status lsyncd
● lsyncd.service - Live Syncing (Mirror) Daemon
 Loaded: loaded (/usr/lib/systemd/system/lsyncd.service; enabled; vendor preset: disabled)
 Active: active (running) since Fri 2018-04-09 10:49:36 BST; 1s ago
 Main PID: 1477 (lsyncd)
 CGroup: /system.slice/lsyncd.service
 └─1477 /usr/bin/lsyncd -nodaemon /etc/lsyncd.conf

Apr 09 10:49:36 lsyncdemo systemd[1]: Started Live Syncing (Mirror) Daemon.
Apr 09 10:49:36 lsyncdemo systemd[1]: Starting Live Syncing (Mirror) Daemon...
[root@lsyncdemo ~]# ll /home/mdeparade/icinga2/scripts
total 4
-rw-r--r--. 1 root root 5 Apr 09 10:52 test.conf
[root@lsyncdemo ~]# ssh -i /root/.ssh/id_lsync -l root 192.168.56.11 ls /etc/icinga2/scripts
test.conf
[root@lsyncdemo ~]# exit
logout
Connection to blog.netways.de closed.

Eindrücke aus Bayern: Die Alpen

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.