Clever Elements GmbH

Wir freuen uns, mit der Clever Elements GmbH unseren neuesten Kunden im Bereich Managed Service begrüßen zu dürfen. Clever Elements ist ein kleines Unternehmen unweit vom Moritzplatz direkt im Herzen Berlins. Namhaften Kunden wie z.B. Siemens, BMW und IBM bietet es eine Online-Software für E-Mail-Marketing, welche die Erstellung und Versendung von Newslettern so einfach und intuitiv wie nur möglich macht.
In den letzen Tagen haben wir die bestehenden Services auf ein neues HA-Cluster in unserem Rechenzentrum umgezogen. Ab sofort profitieren die Kunden von Clever Elements  von der damit verbunden Leistungssteigerung und können sich auf die hochverfügbare Umgebung 24×7 verlassen. Die vorhandene Architektur erlaubt zudem ein flexibles Wachstum in der Zukunft ohne Downtime.
Die Arbeit von Clever Elements kann man im Social Media-Zeitalter natürlich auch auf Facebook verfolgen.
Wir freuen uns auf eine weiterhin gute Zusammenarbeit mit der Clever Elements GmbH.

chive – eine Alternative zu phpMyAdmin?

Bei chive handelt es sich um ein relativ junges PHP-Projekt zur Verwaltung von Datenbanken. Die Entwickler scheuen auf ihrer Homepage auch nicht den Vergleich zu den weit verbreiteten Tools phpMyAdmin und SQLBuddy. Als Vorteile werden vor allem die erweiterten Möglichkeiten bei der Erstellung von Routinen, Triggern und Views genannt, aber auch der enthaltene Editor mit Syntax-Highlighting ist einen Blick wert.
Die einfache Installation, welche bei chive durch Entpacken des Archives erfolgt, ist ein weiterer Vorteil und erfordert darüber hinaus keine weiteren Anpassungen. Die Authentifizierung gegenüber der Datenbank geschieht direkt über ein Formular, dadurch kann auf die von phpMyAdmin bekannte Definition von Datenbanken verzichtet werden. Sensible Daten wie Passwörter und Server-Adressen sind somit auch nicht auf dem Server gespeichert.

Für die tägliche Arbeit bietet chive genug Komfort um auf ein Client-Tool wie MySQL Workbench oder Sequel Pro verzichten zu können. In den nächsten Monaten wird sich aufgrund der Weiterentwicklung, neuen Features und dem vermehrten Einsatz in der Community zeigen, ob chive das Zeug dazu hat, phpMyAdmin die Schau zu stellen. Das Zeug dazu hat es!

Jahr 2000-Problem die Zweite: Spamassassin und das Jahr 2010

In den Postfächern der meisten Admins sind seit dem Jahreswechsel sicher viele Anfragen zu verschollenen Mails eingegangen. So wurden seit dem Jahreswechsel viele Mails durch den Spamfilter Spamassassin aufgrund des Datums ausgefiltert. Schuld daran ist die Filterregel FH_DATE_PAST_20XX, der eigentlich Mails ausfiltern sollte die zu weit in der Zukunft liegen. Das Problem wurde von den Spamassassin-Machern schon relativ zeitig erkannt und bereits vor ca. 6 Monaten durch einen Patch “behoben”. In der aktuellen Fassung trifft uns dieses Problem jedoch am 1.1.2020 wieder, d.h. hier können sich die leidgeplagten Admins schonmal einen Kalendereintrag machen 😉
Trotz dem frühen Patch waren viele Systeme von diesem Fehler betroffen, unter anderem auch große Mail-Provider wie GMX und 1&1. Die Beseitigung des Fehlers ist relativ einfach durchzuführen, die Filterregel FH_DATE_PAST_20XX muss wie folgt modifiziert werden:
Alte Regel:

mailserver:/usr/share/spamassassin# grep DATE_PAST *
50_scores.cf:score FH_DATE_PAST_20XX 2.075 3.384 3.554 3.188 # n=2
72_active.cf:##{ FH_DATE_PAST_20XX
72_active.cf:header   FH_DATE_PAST_20XX    Date =~ /20[1-9][0-9]/ [if-unset: 2006]
72_active.cf:describe FH_DATE_PAST_20XX    The date is grossly in the future.
72_active.cf:##} FH_DATE_PAST_20XX

Neue Regel:

mailserver:/usr/share/spamassassin# grep DATE_PAST *
50_scores.cf:score FH_DATE_PAST_20XX 2.075 3.384 3.554 3.188 # n=2
72_active.cf:##{ FH_DATE_PAST_20XX
72_active.cf:header FH_DATE_PAST_20XX Date =~ /20[2-9][0-9]/ [if-unset: 2006]
72_active.cf:describe FH_DATE_PAST_20XX The date is grossly in the future.
72_active.cf:##} FH_DATE_PAST_20XX

In den nächsten Tagen sollten entsprechend aktualisierte Distributions-Pakete verfügbar sein. Bis dahin lässt sich die oben beschriebene Änderung selbst durchführen oder das Spamassassin-eigene Tool sa-update verwenden. Mit diesem Tool werden die Spamassassin-Dateien auf den aktuellsten Release-Stand gebracht.

IPv6 – die Zeit nutzen solange wir sie noch haben


Zwar ist schon seit Jahren bekannt, dass die IPv4-Addressen irgendwann zu neige gehen und die verbleibende Zeit wird immer kürzer, aber passiert ist eigentlich noch nicht viel. Schätzungen, wie der Counter dieser Counter gehen davon aus, dass die IPv4 Adressen noch etwa 2 Jahre ausreichen werden,  also eigentlich kein Grund zur Hektik werden sich viele denken. Allerdings sollte man so langsam doch in die Gänge kommen, da die Migration auf IPv6, bzw. die Einführung von IPv6 neben IPv4 nicht nach einigen Tagen durchgeführt ist.
Zwingende Vorraussetzung für die Einführung von IPv6 ist ein funktionierendes Monitoring, da nur so Falschmeldungen über nicht erreichbare Komponenten vermieden werden können. Auch sollte man sich von der gängigen Praxis abwenden nur eine IP pro Host zu prüfen. Mit IPv6 sind genügend Addressen verfügbar, so dass eine extra Addresse für das Monitoring und jede Applikation gewählt werden sollte. So lassen sich Applikationen bei Bedarf auch einfacher umziehen, da die IP-Addresse einfach mitgenommen werden kann, Abhängigkeiten zum DNS und dessen Aktualisierungsgeschwindigkeit entfallen somit größtenteils.
Vor einer anstehenden Migration sollte natürlich auch noch geprüft werden, ob alle eingesetzten Applikationen schon IPv6-Ready sind, hier bietet Deepspace6.net eine relativ umfangreiche Liste getesteter Software. Als vermutlich größte Fallstricke ist der fehlende IPv6-Support im Portmapper zu nennen, der für NFS-Exports benötigt wird und bei den meisten Linux-Distributionen Standard ist. Hier kann jedoch evtl. auf den RPCBind umgestellt werden wenn die Distribution entsprechende Pakete anbietet.
Einer Einführung von IPv6 steht daher nicht viel im Wege, so dass die noch verbleibende Zeit genutzt werden sollte um in Ruhe Erfahrungen im Umgang mit dem neuen Protokoll zu sammeln. Denn wie wir alle wissen ist nichts schlimmer als das Arbeiten unter Zeitdruck.

NetApp-Deduplication und Vorteile mit Virtualisierung

Der Virtualisierungs-Hype flacht zwar langsam wieder ab, aber immer mehr Firmen haben inzwischen virtualisierte Umgebungen im Einsatz. Um alle Vorteile der Virtualisierung zu nutzen muss auch eine zentrale Storage-Lösung vorgehalten werden, z.B. für Live-Migration einzelner Maschinen. Hier greift auch der Ansatz von NetApp mit der DeDuplication.

Bei mehreren Servern pro Export nimmt auch die Zahl der redundant abgelegten Informationen zu, z.B. Bibliotheken oder Konfigurationsdateien der einzelnen Server. Die DeDuplication-Technik analysiert hierbei den gesamten Datenteil eines Volumes auf doppelte Blöcke und organisiert das Filesystem entsprechend um, so dass diese Blöcke nur noch einmal abgelegt sind und der redundante Anteil als zusätzlicher Speicherplatz zur Verfügung steht. Umso homogener hierbei die Umgebung ist, desto größer ist auch das Einsparpotential. NetApp verspricht mindestens 50%-Einsparung in Verbindung mit VMWare-, Microsoft- oder Citrix-Umgebungen und unsere Werte für XEN liegen ebenfalls in diesem Bereich.

Die Einrichtung von DeDuplication ist relativ einfach durchzuführen:

  • Aktivieren des DeDuplication-Algorithmus:
    • sis on /vol/<VOLUME>
  • initialen DeDuplication-Lauf starten
    • sis start -s /vol/<VOLUME>
  • Abfrage des aktuellen Status
    • sis status /vol/<VOLUME>
  • Erfolg überprüfen
    • df -sh /vol/<VOLUME>
    • Filesystem                       used          saved            %saved
    • /vol/<VOLUME>/        536GB      253GB          32%

Wir möchten die DeDuplication bei unseren Projekten nicht mehr missen, da der vorhandene Storage so effektiver eingesetzt und für den Kunden kostengünstiger angeboten werden kann.

OpenVPN Access Server

OpenVPN dürfte den meisten Benutzern ein Begriff sein. Für diejenigen, denen die Installation und Konfiguration bisher zu kompliziert war, bietet die Firma OpenVPN Technologies seit kurzem mit dem OpenVPN Access Server eine Art Appliance an. Damit lässt sich auf einfache Weise ein vollwertiger OpenVPN-Server aufsetzen.

Die Installation beschränkt sich dabei auf einige wenige Fragen, die hauptsächlich die Erreichbarkeit des VPN-Servers betrefen: neben der IP-Adresse und dem Port für die Web-GUI ist nur noch der Administrator-Account zu benennen. Der Rest der Konfiguration kann über die übersichtliche Web-GUI geschehen.

Backend des OpenVPN AS

Die Web-GUI gliedert sich in vier Hauptpunkte: eine kurze Statusübersicht, die Netzwerk-Konfiguration, Beutzer-Authentifizierung und Tools. In der Statusübersicht sind dabei alle wichtigen Informationen auf einer Seite gebündelt: Aktive Verbindungen mit deren IP-Adressen, übertragene Datenmengen sowie die wichtigsten Einstellungen des aktuellen Profils. Die Netzwerk-Konfiguration beschränkt sich ebenfalls auf das Nötigste: IP-Adresse und Port des OpenVPN-Servers, Netzbereich für die VPN-Clients und die Regeln für den Zugriff auf lokale Netzbereiche stellen schon den Großteil der Konfigurationsmöglichkeiten dar.

Ebenfalls sehr übersichtlich ist der Bereich für die Benutzerauthentifizierung, hier ist die Anbindung an ein LDAP, einen RADIUS-Server oder die Verwendung einer lokalen Benutzerdatenbank über PAM möglich. Die Konfiguration beschränkt sich bei LDAP und RADIUS auf den zu verwendenden Server sowie den Suchpfad bei LDAP-Authentifizierung. Für PAM stehen keine Optionen zur Verfügung.

Frontend des OpenVP AS

Besonders gut gelöst ist die Verteilung der Client-Konfigurationen. So kann in den Einstellungen des Servers festgelegt werden, dass die Web-GUI über die OpenVPN-Adresse getunnelt wird. Auf diese Weise kann sich jeder Benutzer mit seinen Benutzerdaten an der Web-GUI anmelden und erhält zwei Download-Optionnen: die reine OpenVPN-Konfiguration für Linux und/oder Mac-Benutzer sowie der fertig konfigurierte Client für Windows. Einfacher war die Verteilung von OpenVPN-Zugängen bisher noch nicht möglich.

Erweiterung unseres Storage-Angebotes

FAS 2020 vor dem Einbau

FAS 2020

Anfang letzter Woche haben wir eine zusätzliche NetApp in unserem Rechenzentrum eingebaut, um unseren Kunden weitere Storage-Möglichkeiten anbieten zu können. Diesmal handelt es sich um eine FAS 2020 mit zwei Köpfen, d.h. zwei Storage-Controller. Die beiden Köpfe sind jeweils über Fibre-Channel an die Platten-Shelves angebunden, so dass bei einem Kopfausfall der zweite Kopf alle Funktionen des ersten übernehmen kann.

Die interne Bestückung mit Festplatten wurde bewusst nicht gewählt, da so bei einem möglichen Engpass der Wechsel der Kopfeinheit genügt und die vorhandenen Platten-Shelves weiterverwendet werden können. Bei der Bestückung der Shelves wurde auf die unterschiedliche Performance von SAS- und SATA-Festplatten Rücksicht genommen.

Dadurch können unseren Kunden zwei Arten von Storage angeboten werden:

  • schneller Speicherplatz, z.B. für Auslieferung von Webseiten-Inhalten (SAS)
  • etwas langsamerer, dafür kostengünstiger und größerer Speicherplatz, z.B. für Backup-Zwecke (SATA)

Wir haben bereits mehrere NetApp-Systeme im Einsatz, aber wir sind jedesmal wieder beigeistert, wenn wir in diesem Bereich einen Zuwachs bekommen. Wie man oben auf dem Bild sehen kann, lockt dies sogar unsere Geschäftsleitung aus dem Büro. Aufgrund unserer sehr guten Erfahrungen mit den Systemen wird dies auch ganz sicher nicht unser letzter Filer sein.

Loadbalancing bei Geobasisinformation Brandenburg

Hochverfügbarkeit und Lastverteilung spielen bei Internet-basierenden Diensten eine immer größere Rolle. Der Einsatz von Open-Source Software schafft hierbei eine kostenkünstige Möglichkeit sowohl die Verfügbarkeit zu steigern, aber auch die Last eines einzelnen Systemes durch Clustering zu senken.

Bei Geobasisinformation Brandenburg werden verschiedene, auf Karten basierende, Dienste dem Kunden online zur Verfügung gestellt. Im Zuge des Projektes sollte die vorhandene Anwendung auf einen Loadbalancer migriert werden, welche bisher von einem einzelnen Server ausgeliefert wurden.

Die Basis hierfür war eine Kombination aus einem realen Server und einem virtualisierten Server, der im Fehlerfalle die Dienste übernehmen soll. Für die Ausfallsicherheit wurde Heartbeat auf beiden Servern installiert, und auf Basis von Version 2 für die grafische Administration konfiguriert.

Die Lastverteilung der eingehenden Anfragen wurde über das Linux Virtual Server Projekt gelöst. Hierbei werden alle Anfragen vom aktiven Director auf die dahinterliegenden Server www-1, www-2 … www-n verteilt. Die Synchronisation der Verbindungs-Tabellen zwischen den beiden Director-Knoten geschieht über eine dedizierte Netzwerkverbindung, so dass bei einem Ausfall keine Verbindungen verloren gehen.

Durch dieses Setup konnte nun sowohl die Ausfallsicherheit gesteigert, als auch eine Lastverteilung auf aktuell 2 Webserver geschaffen werden. Die Lastverteilung kann bei Bedarf ohne große Änderungen und Ausfallzeiten auf weitere Server ausgedehnt werden.

Zentrales Konfigurationsmanagement mit Puppet

Je größer die Anzahl der Server wird, desto schwieriger wird es alle Systeme synchron zu halten. Bei der Installation ist dies noch über einen zentralen Installationsserver möglich der einen fest definierten System und Paketzustand abbildet. Bei Konfigurationsänderungen oder Paketinstallationen vergisst man allerdings sehr leicht alle Systeme des gleichen Typs z.B. alle Knoten eines Mailserverclusters mit anzupassen.
Eine zentrale Stelle für Konfigurationsdateien verhindert diesen Wildwuchs. Die Konfigurationen oder Paketlisten werden einmal an einer Stelle geändert und alle Systeme, die zum Erhalt der Dateien oder Pakete konfiguriert sind erhalten die neue Ausführung kurze Zeit später.
Ein Open-Source-Tool für diesen Zweck ist Puppet, das auf allen Unix-artigen Systemen lauffähig ist. Die Konfigurationsmöglichkeiten erstrecken sich somit z.B. auch auf Apple-Rechner mit MacOS X. Im Gegensatz zum bisherigen Platzhirsch cfengine ist Puppet noch nicht so verbreitet und bekannt, allerdings bietet es viele Features die mit cfengine nicht oder nur umständlich zu realisieren sind.
Unter anderem ist es cfengine in folgenden Punkten überlegen:

  • (wahlweise zentrales) Backup geänderter Dateien
  • Verwaltung von Benutzern und Gruppen
  • Erweiterbarkeit durch eigene Plugins, die vom Server verteilt werden
  • integrierter Fileserver für Konfigurations-Dateien

Leider lassen sich mit Puppet aktuell noch keine Windows-Server verwalten. Dafür sind die Konfigurationsdateien für den unbedarften Admin aber auch leichter lesbar als die (mehr oder weniger) kryptische Konfiguration von cfengine.
In unserer Server-Umgebung konnten so die Zeiten zum Abgleichen der Systeme, Aktivieren neuer Konfigurationen oder Installation von Paketen auf ein Minimum reduziert werden. Gerade bei lastverteilten oder hochverfügbaren Systemen bei denen Konfigurationsfehler auf einem einzelnen Server unter Umständen erst einige Zeit später auffallen, wird die Installation und Wartung sehr vereinfacht zusätzlich lässt sich durch das zentrale Konfigurationsmanagement die Qualität der erbrachten Dienstleistungen steigern.
Update: Inzwischen haben wir auch auf unseren Webseiten Infos zu Puppet online

Virtualisierung im Zeichen von GreenIT

Xen ist eine freie Software zur Virtualisierung verschiedenster Gast-Betriebssysteme. Durch den Einsatz einer Virtualisierungslösung lassen sich die vorhandenen Ressourcen effektiver nutzen und auch dynamisch verteilen. Zusätzlich bietet Virtualisierung den Vorteil, dass bei einer beschränkten Anzahl an Servern trotzdem jeder Serverdienst in einer eigenen Umgebung läuft, und so andere Dienste nicht beeinflussen kann.
Aktuell sind bei uns 5 Xen Systeme im Einsatz, die zusammen 31 virtuelle Maschinen bereitstellen. Das Spektrum der virtuellen Maschinen reicht dabei von einfachen Dingen wie Syslog- oder DNS-Servern bis hin zu lastintensiven Datenbank- oder Nagios-Servern. Alle wichtigen System haben wir doppelt ausgelegt und auf verschiedene Wirte verteilt. Durch einen vorgeschalteten Loadbalancer verteilen wir die Last auf mehrere virtuelle Maschinen. Selbst bei nicht geclusterten Systeme beschränkt sich ein Ausfall auf ein Minimum an Zeit, da die Gastsysteme ohne größere Probleme auf einen anderen Wirt verlagert werden können. Zusammenfassend bleibt zu sagen, dass die Virtualisierung uns einen Leistungsgewinn bei gleichzeitiger Platz- und Stromersparnis bietet.