Archiv der Kategorie: Linux

Mixed Linux Loadbalancer für VMware Horizon (View) und Alcatel OmniPCX

Erstes Einsatzszenario: Um die Redundanz unserer VMware Horizon (View) Umgebung zu gewährleisten, wurde ein Setup mit zwei View Connection Servern gewählt. Diese werden auf den VSphere Servern mit einer „Anti Affinity Rule“ betrieben. Somit ist sichergestellt, daß die beiden Connection Server nie auf dem gleichen ESX Host laufen.
Linux-Loadbalancer-01
Selbst erlebt: Viele Systemhäuser und Adminstratoren verwenden bei mehreren Connection Servern DNS Round Robin. Zum Beispiel: view.domaine.local wird auf die beiden A-Records view1.domaine.local und view2.domaine.local aufgelöst. Somit bekommen die Clients bei jeder DNS Anfrage den nächsten DNS Eintrag zu view.domaine.local. Zur Lasterverteilung kann man das gelten lassen, aber ansonsten: Geht gar nicht! Wenn ein Server ausfällt sind 50% der Clients nicht mehr erreichbar. Man stelle sich das bei über 300 virtuellen PCs vor. Das sind 150 Anrufe bei der EDV Abteilung 🙂 Also: Ein Loadbalancer muss her. Da hat man zwei Dinge auf einmal: Lastverteilung und Redundanz, denn wenn ein „Realserver“ ausfällt, wird dieser sofort von der Lastverteilung ausgeschlossen. Ich habe mich für den Keepalived entschieden, denn dieser arbeitet perfekt mit IPVSadm zusammen. Hier die Config für die VMware View Server als Realserver:

Die Anfragen werden mittels Direkt Routing weitergeleitet. Kein NAT! Hierzu muß auf dem Windows Realserver ein Loopbackdevice mit der Shared IP installiert werden. Im Loadbalancer Blog wird ganz gut erklärt wie das bei Server 2008 gemacht wird.
Linux-Loadbalancer-02
Der Client wird über den Loadbalancer zum Realserver weitergeleitet, arbeitet aber nach dem Verbindungsaufbau direkt mit dem Realserver weiter. Genau das wollen wir.
Linux-Loadbalancer-03
Nun zum zweiten Einsatzszenario: Unsere Telefonanlage besteht aus zwei Knoten an zwei Standorten mit zwei unterschiedlichen IP Subnetzen. Nur die aktive Knoten stellt den TCP/IP Connector auf Port 2555 für Estos bereit. Schwenkt bei einem Netzwerkausfall die Anlage den aktiven Knoten, ist Estos bis zur manuellen Anpassung der Konfiguration offline. In diesem Anwendungsfall kann man den Loadbalancer super zur Redundanz „missbrauchen“, denn er erkannt ja wenn ein Realserver ausgefallen ist und benutzt diese Verbindung nicht mehr. In unserem Fall wird somit immer der aktive Knoten angesprochen. Wegen den beiden unterschiedlichen Subnetzen und weil ich ungerne ein Loopback im Linux von Alcatel einrichten will (Supportverlust) kommt nur NAT in Frage. Hier muß man einige Dinge unter Linux beachten. Im Linuxkernel (Sysctl) müssen folgende Einträge aktiviert werden:
net.ipv4.ip_forward=1
net.ipv4.vs.conntrack=1

In den meisten Dokus wird das MASQUERADING global auf dem Interface aktiviert:
iptables -t nat -A POSTROUTING -o eth0

Diese Einstellung würde aber das Direct Routing sofort unbrauchbar machen. Es dürfen lediglich die Pakete zu den Realservern mit NAT maskiert werden:
iptables -t nat -A POSTROUTING -o eth0 -d <realserver1-ip> -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -d <realserver2-ip> -j MASQUERADE

Diesen folgenden Abschnitt einfach unter die Einträge vom Direkt Routing in der bestehenden Konfigurationsdatei kopieren und anpassen:

Sieht leicht aus, aber ich musste einige Zeit in die Recherche und Tests inverstieren. Aber hat man dieses Setup einmal eingerichtet und verstanden, kann man es immer wieder für sicherlich viele weitere Anwendungsfälle implementieren. Bei uns wird durch den Loadbalancer die Round Robin Verteilung der Anfragen auf die Realserver und Redundanz gewährleistet. Redundanz – gutes Stichwort: Die so konfigurierte Master Linux-VM muss man einfach clonen und mit der gleichen Konfiguration als Backup laufen lassen. Dafür einfach den Hostnamen und die IP-Adresse von Loadbalancer-1 inkrementieren und den Eintrag „Master“ durch „Backup“ in der Konfigurationsdatei ersetzen. Die beiden Loadbalancer sollten ebenfalls mit einer „Anti Affinity Rule“ betrieben werden. Damit ist der Loadbalancer mittels VRRP ebenfalls hochverfügbar. Linux. Einfach. Kostet nix. Geht. Sie können ja mal Preise für einen redundanten Hardware-Loadbalancer anfragen 😉

Ubuntu: fehlerhafter Cronjob für Amavis/Razor2 sa-sync

Ubuntu/Debian führt folgenden Cronjob aus:
Cron <amavis@mail> test -e /usr/sbin/amavisd-new-cronjob && /usr/sbin/amavisd-new-cronjob sa-sync

Sie erhalten folgende Fehlermeldung:
Use of uninitialized value $type in concatenation (.) or string at /usr/lib/perl5/Mail/SpamAssassin/Conf/Parser.pm line 699.
config: unknown conf type ! at /usr/lib/perl5/Mail/SpamAssassin/Conf/Parser.pm line 699.

Es handelt sich um einen Schreibfehler in der Datei „Razor2.pm“. Einfach mit einem Editor den Fehler in Zeile 118 korrigieren „DURATION“:
vi /usr/lib/perl5/Mail/SpamAssassin/Plugin/Razor2.pm

razor2_typo

Amavisd-new nach SpamAssassin Update neu starten

Nach einem erfolgreichen Update mit „sa-update“ muß man Amavisd neu starten damit das Update auch angewendet werden kann. Amavis läd aus Performancegründen den Spamassassin komplett in den Speicher. Ich habe ein kleines Script geschrieben das den Dienst Amavis neu startet wenn es ein erfolgreich durchgeführtes Update gegeben hat. Die Updates werden von Apache.org und Heinlein Support gezogen. Wenn einer dieser Channels ein Update angeboten hat greift der Neustart.

Einfach in „/opt/sa-update.sh“ speichern und über einen Cronjob aufrufen.

AT&T Blacklist – Die Antispam Profis ;-)

Das muß man gesehen haben: AT&T blockiert eine Email unserer Domain weil der zuständige SMTP Server (Postfix) auf deren Blacklist eingetragen ist:

Aug 3 07:49:54 mfs-cl-mx1 postfix/smtp[17810]: 4E4D1804D7: to=<xx@bellsouth.net>, relay=gateway-f1.isp.att.net[204.127.217.16]:25, delay=140981, delays=140980/0.02/0.86/0, dsn=4.0.0, status=deferred (host gateway-f1.isp.att.net[204.127.217.16] refused to talk to me: 550-213.135.x.y blocked by ldap:ou=rblmx,dc=att,dc=net 550 Error – Blocked for abuse. See http://att.net/blocks)

AT+T Antispam

Unter der Domain http://att.net/blocks soll man nun den Postmaster kontaktieren. Kennt man ja, Also rufe ich die URL auf, gebe meine Daten ein und dann mußte ich voller erstaunen folgende Zeile in meinem Logfile lesen:

Aug 3 07:54:56 mfs-cl-mx1 postfix/smtpd[18095]: connect from mail.swh.bellsouth.net[65.83.225.15]
Aug 3 07:54:57 mfs-cl-mx1 postfix/smtpd[18095]: NOQUEUE: reject: RCPT from mail.swh.bellsouth.net[65.83.225.15]: 550 5.1.8 <apache@rblremreq02.localdomain>: Sender address rejected: Domain not found; from=<apache@rblremreq02.localdomain> to=<postmaster@komplet.com> proto=ESMTP helo=<mail.swh.bellsouth.net>
Aug 3 07:54:57 mfs-cl-mx1 postfix/smtpd[18095]: disconnect from mail.swh.bellsouth.net[65.83.225.15]

Absolute Profis: Der SMTP Server von AT&T meldet sich mit „.localdomain„. Unglaublich. Pflegen Blacklisten und können selbst nicht mal ihre eigenen Server richtig konfigurieren 😉

Temperatursensor mit EnOcean und Raspberry PI für Nagios / Icinga

Auf der Suche nach Temperatursensoren für Nagios oder Icinga findet man immer kleine Appliances die mit Ethernet verbunden werden müssen und dementsprechend teuer sind. Eine kostengünstige, aber auch wesentlich skalierbare Möglichkeit, ergibt sich durch die Nutzung von EnOcean. Oliver Quien und meine Wenigkeit haben ein kleines System assembliert, mit dem jeder Admin eine fast unbegrenzte Anzahl von Sensoren in Nagios einbinden kann:
Enocean_Raspberry_Temperatur_Nagios
Enocean sendet Datagramme aus, die von einem Empfänger verarbeitet werden. In unserem Fall befindet sich der Empfänger in einem kleinen USB Stick. Den Stick kann man direkt an das Nagiossystem anschliessen. Um die Reichweite zu erhöhen, haben wir uns für einen kleinen Repeater entschieden. Der sehr günstige Raspberry PI ist für die Realisierung ideal. Ein kleines Skript auf dem Raspberry empfängt die Datagramme und sendet diese direkt per TCP/IP-Stream an einen kleinen Wrapper auf dem Nagiossystem weiter. Es ergeben sich zwei Vorteile dieser Konstellation: Die Werte können auch in ein virtuelles Nagios übertragen werden und es können mehrere Repeater dezentral in Außenstellen und zur Reichweitenerhöhung eingesetzt werden. Neben Temperatursensoren gibt es viele weitere Sensoren für Luftfeuchtigkeit, Feuermelder, digitale Ein- und Ausgänge für z.B. Klimageräte, Einbruchmeldesysteme usw. Der Fantasie sind da fast keine Grenzen gesetzt. Es müssen KEINE Stromleitungen oder Ethernetkabel bereitgestellt werden! Die Sensoren werden Nagios bekannt gemacht und können einfach verteilt werden. Egal ob im Serverrack, an der Wand oder an der Decke. Vollkommen Wireless!
Enocean_Raspberry_Temperatur
Das Checkscript, den Raspberrysender und den Wrapper für Nagios werden von uns als OpenSource zur Verfügung gestellt. Wer Interesse hat sollte Kontakt zu uns aufnehmen. Günstiger und schneller kann man die Überwachung von z.B. Serverräumen in Nagios oder Icinga nicht mehr realisieren!