NETWAYS Blog

Cluster unter Proxmox virtual environment

von Afeef Ghannam | Jul 17, 2020 | NETWAYS

Man kann aus verschiedenen Nodes ein Cluster aufbauen, so dass die Hochverfügbarkeit der Gäste und Lastverteilung gesichert ist (mindestens 3 Nodes werden empfohlen). Pve-cluster ist der wichtigste Service im Proxmox VE. Er ermöglicht den Zugriff auf Hauptkonfigurationsdateien bei jedem Node unter /etc/pve, deshalb muss dieser Service auch bei Single-Node-Installationen eingeschaltet sein, ansonsten funktioniert Proxmox VE nicht mehr. Die anderen zwei Services, pve-ha-lrm und pve-ha-crm, unterstützen pve-cluster. LRM steht für local resource manager, der die gewünschten Status aller lokalen Services unter /etc/pve/nodes/<nodename>/lrm_status liest und die entsprechenden Befehle an alle betroffenen Services schickt. CRM steht für „cluster resource manager“, der Entscheidungen über Cluster trifft. Er sendet Befehle zu allen LRMs, verarbreitet die Ergebnisse und schiebt VMs und Container zu einem anderen Node, falls etwas schief geht z.B ein Node ausfällt.

Anforderungen

Freigabe von UDP-Ports 5404 und 5405 für Corosync-Kommunikation auf allen Nodes
Zeitsynchronisation
SSH tunnel auf port 22 für alle Hosts
Mit Hochverfügbarkeit sollte der Cluster aus mindestens drei Hosts aufgebaut werden
Eigenes Netzwerk für Cluster-Verkehr besonders mit der Nutzung von geteiltem Speicherplatz
Root-Passwort vom Cluster-Node um Nodes hinzufügen

Cluster erstellen

Nachdem ein eigenes Netzwerk für Cluster unter Node => Netzwerk eingerichtet wurde, kann man eine Cluster erstellen unter Datacenter => Cluster => Create Cluster. Link0 ist das Cluster-Netzwerk. Link1 ist für Netzwerk-Redundanz falls Link0 ausfällt oder umgekehrt. Gesetzte Priorität bestimmt welches Interface im normalen Fall aktiv ist.

Node zum Cluster einschließen

Vorsicht: Ein neuer Gast muss keine VMs haben, da alle Konfigurationen unter /etc/pvc überschrieben werden. Dies macht Proxmox VE als Schutzmaßnahme gegen Konflikt der Vms-IDs. Als Umweg muss ein Backup für VMs des neuen Nodes gemacht werden.

Vom Cluster-Node durch Datacenter => Cluster => Join Information, holt man Cluster-Information, die bei neuen Nodes gebraucht werden.
Wenn man bei einem neuen Node auf Datacenter=> Cluster => Join Cluster, geht und dann kopierte Informationen einfügt, werden Peer Address und Fingerprint automatisch befüllt. Root-Passwort des Cluster-Nodes und Link0 bzw. Link0 und Link1 müssen noch eingegeben werden.

Afeef Ghannam

Systems Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kolleg:innen im Operations Team der NETWAYS Professional Services bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

Lies mehr von Afeef und triff unser Team

Vom Messwert zur Alarmierung

von Afeef Ghannam | Dez 9, 2019 | Hardware, Monitoring, Network

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

Systems Engineer

Lies mehr von Afeef und triff unser Team

Zentraler Director mit verschiedenen Director-Datenbank als Backend

von Afeef Ghannam | Okt 11, 2019 | Icinga

Man kann von einem Director auf andere verschiedene getrennte Icinga-Umgebungen zugreifen und dorthin deployen, die auch mit Director gepflegt werden. In diesem Szenario haben wir unterschiedliche getrennte Masters. Allerdings ist dies fehleranfällig, da das falsche Director-Backend ausgewählt werden könnte und damit nicht in die gewünschte Umgebung konfiguriert wird. Deshalb stellt sich die Frage “ ist es nicht vernünftiger sich bei dem gewünschten Master einzuloggen und den lokalen Director zu benutzen? „. Meiner Meinung nach ist das richtig, aber ich will die Aufmerksamkeit an dieser Stelle auf die Vorzüge des Directors lenken. Vielleicht wird es in der Zukunft nützlich sein.

Was braucht man, um dieses Szenario umsetzen zu können?

Zuerst müssen wir dem lokalen Director Zugriff auf die entfernte Director-Datenbank erlauben. Zusätzlich brauchen wir einen Api-User, der den entfernten Icinga-Core ansprechen kann und uns remote deployment ermöglicht.

Unter /etc/icingaweb2/resources.ini tragen wir die entfernte Director-Datenbank ein:

[director_customer1] type = "db" db = "mysql" host = "ip" dbname = "director" username = "username" password = "password" charset = "utf8" use_ssl = "0"

Unter /etc/icingaweb2/modules/director/config.ini machen wir die neue Resource dem Director bekannt:

[db] resource = "director_db" // unsere lokale Director-Datenbenk resources = director_customer1, director_customer2 // Remote Director-Datenbank

So bekommen wir ein drop down menu oben rechts im Director-Interface. Wir können z.B director_customer1 auswählen und unter Icinga Infrastruktur => Endpoints überprüfen, ob der Api-User eingetragen ist. Ab diesem Moment können wir Konfigurationen auf dem entfernten Master verwalten, die Director spezifisch sind.

Afeef Ghannam

Systems Engineer

Lies mehr von Afeef und triff unser Team

Podman vs Docker

von Afeef Ghannam | Mai 31, 2019 | NETWAYS

Als ich über Podman las, habe ich mir immer die Frage gestellt, wieso hat Redhat ihr eigenes Projekt gestartet, das im Grunde wie Docker ist, anstatt Pull Requests mit Verbesserungen an das Docker Projekt zu schicken? Die Antwort erhielt ich mit der Geschichte von Skopeo.

Skopeo :

Skopeo ist die Inspiration und der Anfang von Podman. Skopeo bedeutet „Remote-Suchen“ in der griechischen Sprache. Das Redhat-Team hat sich gefragt, wieso zuerst ein Image mit hunderten von MB von der Registery heruntergeladen werden muss, um nachschauen zu können, ob man das gewollte Image hat? Wenn ja, behält man es und wenn nein, schmeißt man es weg. Aufgrund dessen hat Redhat ein Pull Request an das Docker-Project geschickt. Das Docker-Team sich geweigert die Pull Request anzunehmen und hat gemeint, das schadet der API und dem CLI von Docker. Deshalb hat das Redhat-Team sein eigenes Tool entwickelt. So kamen Skopeo und die nachträglichen Gedanken vom Podman-Project zur Welt. Skopeo bot am Anfang die Möglichkeit die JSON Datei von einem Image herunterzuladen. Scopeo kann mittlerweile folgendes: Images pullen, pushen, kopieren zwischen Registeries ohne dazwischen lokal pullen zu müssen. Alles passiert ohne Root-Rechte.

$ mkdir fedora-24
$ skopeo copy docker://fedora:24 dir:fedora-24
$ tree fedora-24
fedora-24
├── 7c91a140e7a1025c3bc3aace4c80c0d9933ac4ee24b8630a6b0b5d8b9ce6b9d4.tar
├── f9873d530588316311ac1d3d15e95487b947f5d8b560e72bdd6eb73a7831b2c4.tar
└── manifest.json

Woher kommt der Name

Der Name Podman ist ein Kürzel für Pod Manager. Die Container-Orchestrierung Kubernetes hat den Begriff Pod geprägt. Er beschreibt eine Gruppe von Containern, die sich bestimmte Ressourcen teilen und nicht völlig isoliert voneinander laufen. Während Docker Pods nur indirekt über Kubernetes unterstützt wird, sind sie ein integraler Bestandteil von Podman. Eine Gruppe von – bedeutet „pod“, deshalb hat sich Redhat für drei Robben als Logo für Podman entschieden.

Ein Infra-Container verrichtet keine Arbeit, sorgt aber dafür, dass bestimmte Ressourcen des Pods wie Namespaces, CGroups und Netzwerk-Ports am Leben bleiben. Obwohl Podman dem Fork-Exec-Modell folgt und damit nicht als Server läuft, benötigen wir dennoch einen Prozess, der Container überwacht, um etwa Logs- und Exit-Codes zu sichern. Dies ist die Aufgabe von Conmon, ein kleines, in C geschriebenes Monitoring-Werkzeug, dass jedem Container angehängt wird. Neben dem Monitoring hält Conmon das Terminal des Containers offen, um per podman exec zu einem späteren Zeitpunkt das Terminal verwenden zu können.

Aus der Grafik ist ebenfalls die runc zu entnehmen. Runc ist für die Ausführung eines Container-Prozesses zuständig und implementiert die Runtime-Spezifikation der OCI (Open Containers Initiative). Redhat, IBM, Google, Microsoft, Docker und andere Unternehmen haben sich 2015 ausgetauscht und definiert “ was ein Image eines Containers bedeutet und wie dies ausschauen soll“. Den Konsens haben sie als Standards für den Image-Aufbau für die Industrie genommen und OCI (Open Containers Initiative) genannt.

Afeef Ghannam

Systems Engineer

Lies mehr von Afeef und triff unser Team

Config Management Camp Ghent 2019

von Afeef Ghannam | Feb 22, 2019 | NETWAYS, Automation, Puppet, Foreman, Ansible

Ich habe dieses Jahr die erste Gelegenheit bekommen, mich mit meinen Kollegen und meinem Chef am Configuration Management Camp im Ghent zwischen 4. und 6. Februar zu beteiligen. Wir sind am 3. Februar am Abend in Ghent angekommen und durch die Stadt spazieren gegangen. Ghent hat uns sehr beeindruckt: Nicht nur die Sauberkeit der Straßen, sondern auch die Verbindung von alten und neuen Gebäuden haben Ghent besonders schön wirken lassen.

DevOps und Konfigurationsmanagement

Aber der Höhepunkt war das Camp: Es gab fast 1000 Teilnehmer aus der ganzen Welt. Die Vorträge waren sehr informativ und gingen hauptsächlich um DevOps und Konfigurationsmanagement ( Puppet, Ansible, Chef, Foreman). Viele Referenten haben sowohl ihre Erfahrungen sowie zuletzt aufgekommene und gelöste Probleme in ihrer Firma geteilt, als auch neue Features im Automation- und Konfigurationsmanagement-Feld vorgestellt. Am dritten Tag nahm ich mit meinem Kollegen und Ausbilder auf dem Foreman Construction Day Workshop teil. Wir haben uns in Gruppen praktisch mit „Foreman“ beschäftigt. Am Ende des Tages haben einige Foreman-Entwickler und Teilnehmer über Wünsche, Verbesserungen und kommende Features gesprochen.

Ich empfehle jedem, der Interesse am Konfigurationsmanagement hat, das nächste Camp zu besuchen und belgische Waffeln und Bier auf jeden Fall zu probieren. Die sind sehr, sehr lecker.