cyon Blog

Eine hundertprozentige Verfügbarkeit ist etwas, was es in der Informatik nicht gibt. Ein Umstand der in 99.9% der Zeit, in der alles gut läuft, gerne in Vergessenheit gerät.

Ein Problem auf Server 35 hat uns und unsere Kunden, welche auf diesem System zu Hause sind, schmerzlich daran erinnert. An zwei Tagen im Dezember und drei Tagen im Januar war der Server während insgesamt knapp 3 Stunden nicht erreichbar. Einzelne Dienste wie Web oder E-Mail waren sogar noch etwas länger nicht verfügbar.

Das Beste aber gleich zu Beginn: Der Fehler ist inzwischen gelöst. Doch der Reihe nach:

Rien ne va plus

Am 12.12.2011 gab es einen Ruck auf unserem Server 35. Nichts ging mehr und die einzige Möglichkeit den Server wieder zum Laufen zu bewegen war es, diesen neu zu starten.

Wie bei uns üblich, wurde nach dem Vorfall sofort geprüft, was denn die Ursache für das Problem gewesen sein könnte. Nach einigem Nachforschen schien klar: Die Ursache war ein Fehler in der Hardware, genauer im sog. Disk Controller Cache. Oder doch nicht?

Neue Hardware im Eiltempo

Das Problem trat am nächsten Tag erneut auf. Zeit für unseren Notfallplan, das komplette System auf einen Standby-Server zu migrieren. Dank Bladeservern geht dies innert Minuten, es müssen lediglich die lokalen Disks in das neue System umgezogen werden.Doch auch auf dem neuen System währte die Ruhe nur kurz: Das neue System zeigte das gleiche Verhalten. Lag das Problem also doch an einer Softwarekomponente? Unsere Nachforschungen gingen nun in die verschiedensten Richtungen.

Entlasten

Die üblichen Massnahmen zur Problemfindung waren fürs erste ausgeschöpft und so begannen wir, Kunden von Server 35 weg zu transferieren. Dies gab uns die Möglichkeit, Server 35 zu entlasten und so möglicherweise dem Problem auf die Schliche zu kommen.
Und siehe da, das Problem trat nicht mehr auf. Zumindest vorerst. Der Fehlerteufel machte wohl Weihnachtsferien.

Externe Expertise

Im neuen Jahr zeigte sich das Problem dann plötzlich wieder: Der Server blieb stehen und liess sich nur durch einen Neustart wieder zur Arbeit zu bewegen. Unsere Köpfe rauchten, denn die Ursache war unklarer denn je.

Bei einer Störung holen wir uns sehr rasch auch externe Hilfe hinzu. Der Serverhersteller lieferte uns weitere Diagnosetools um die Hardware nochmals zu prüfen – doch hier war alles im grünen Bereich.

Ab und zu trägt auch ein frisches Paar Augen zur Lösungsfindung bei. Wir greifen deshalb gerne auf befreundete Experten zurück, um eine Zweitmeinung einzuholen. Doch leider beschränkte sich die Ausbeute auch hier auf ratloses Schulterzucken.

Als dritte Partie im Bunde belieferten wir den Hersteller unseres Betriebssystems mit Logdaten und Kerneldumps. Dieser versorgte uns wiederum mit modifizierten Kerneln, die wir auf unserem Testsystem ausprobierten. Doch eine schnelle Lösung lag nicht in Griffnähe.

Phantasie ist gefragt

Während der Problemsuche ist es stets oberste Priorität, die Systeme so verfügbar wie möglich zu halten. Und dabei ist manchmal auch ein Griff in die Trickkiste erforderlich.
In diesem Fall zeigte sich zum Beispiel, dass bei den ersten Anzeichen des Problems (was in diesem Fall ein erhöhter I/O Wait war) ein rechtzeitiger Neustart des Webservers den Totalabsturz des Servers verhindern konnte. Ein kleines Script übernahm diese Aufgabe und konnte das System so weitgehend stabil halten.

Endlich: Land in Sicht

Wir hatten wieder damit begonnen, Kunden vom Server weg zu transferieren. Und endlich kamen wir so auf die richtige Fährte. Denn plötzlich trat das Problem auf dem neuen Server auf, auf welchen diese Kunden transferiert wurden. Nun war klar: die Ursache musste durch einen bereits transferierten Kunden verursacht worden sein. So konnten wir nach Prüfung sämtlicher in Frage kommenden Kundenscripts den Fehler ausfindig machen.

Übeltäter mod_rewrite

Schuld am Ganzen waren am Ende eine dreizeilige, jedoch komplexe, Rewrite-Anweisung. Diese führte dazu, dass der gesamte Zwischenspeicher des Servers (immerhin 48 GB plus 10 GB Swap) durch eine Endlosschlaufe innert Sekunden gefüllt wurde und das System zum Erliegen brachte. Die eingebaute Loop-Protection des Webservers konnte diese Schlaufe nicht abfangen, da sich der entsprechende Wert bei jedem Schlaufendurchgang veränderte.

Eigentlich darf so etwas nicht passieren. Wir betrachten dieses Verhalten daher als Bug des Webservers. Da es sich um eine Anweisung handelt, die auch bei anderen Anbietern zu Problemen führen kann, möchten wir die genaue Anweisung hier nicht publizieren.

Fazit

Auch wenn wir ein Betriebssystem einsetzen, welches den grössten Teil aller Prozesse einkapseln und unter Kontrolle halten kann, gibt es Konstellationen, die Fehler auslösen. Wir arbeiten zusammen mit dem Hersteller unseres Betriebssystems daran, auch solche speziellen Konstellationen in Zukunft automatisch abfangen zu können. Das System wird also ständig verbessert und wir gehen davon aus, dass ein vergleichbares Problem in Zukunft nicht mehr auftaucht.

Bei allen betroffenen Kunden möchten wir uns noch einmal in aller Form für die Unannehmlichkeiten entschuldigen.

Bei Fragen steht Ihnen unser Support gerne via support@cyon.ch oder unter der kostenlosen Telefonnummer 0800 840 840 zur Verfügung.

Haben Sie schon einmal von unserem Remote Support gehört? Der cyon Remote Support ist ein kleines Helferlein, mit welchem wir Ihren Bildschirminhalt ansehen und sogar die Maussteuerung übernehmen können (natürlich nur, wenn Sie uns Zugang gewähren).

So lassen sich gewisse Aufgaben sehr viel effizienter lösen. Der Klassiker ist das Einrichten einer E-Mailadresse: Anstatt dass Sie uns alle Einstellungen vorlesen, können wir direkt sehen, was Sache ist.

Das Programm für den cyon Remote Support lässt sich kostenlos von unserer Webseite herunterladen und kann ohne Installation auf Windows oder Mac ausgeführt werden. Und so einfach geht's:

1. Sie rufen uns über unsere kostenlose Hotline 0800 840 840 an.
2. Sie öffnen das heruntergeladene Programm und lesen uns den angezeigten Code vor.
3. Schwupps, schon kann es losgehen.

Wir führen Ihnen den cyon Remote Support gerne bei Ihrem nächsten Anruf vor.

Mächtig ist sie, die Rewrite-Engine des Apache Webservers. Und dementsprechend auch nicht so einfach zu verstehen.Damit Sie sich nicht mit dem Lernen von Rewrite-Befehlen herumschlagen müssen, stellen wir Ihnen heute die drei Anweisungen vor, die unsere Supporter am häufigsten anwenden.

Die Anweisungen werden jeweils in einer Textdatei hinterlegt, die den Namen .htaccess trägt und sich im Verzeichnis public_html befindet.

Website aus einem Unterordner aufrufen

Damit die gewünschte Website aus einem Unterordner aufgerufen wird, tragen Sie folgende Anweisung in die Datei .htaccess ein:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^ihredomain.ch$ [OR]
RewriteCond %{HTTP_HOST} ^www.ihredomain.ch$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /unterordner/$1 [PT,L,QSA]

Und damit die Weiterleitung nicht in einer ewigen Schlaufe endet, fügen Sie folgende Anweisung in die .htaccess Datei im entsprechenden Unterordner ein:

RewriteEngine off

Domain A auf Domain B zeigen lassen

Falls Sie den Inhalt von Domain B anzeigen lassen möchten, ohne dass sich die URL in der Adresszeile ändert, verwenden Sie folgende Anweisung in Ihrer .htaccess-Datei:

RewriteEngine On
RewriteRule ^(.*)$ http://www.ihredomain.ch/$1 [P,L]

Anfragen ohne www. umleiten

Ihre Website ist in der Regel sowohl mit www. als auch ohne diesen Zusatz erreichbar. Damit Suchmaschinen erkennen, dass es sich bei beiden Varianten um den gleichen Inhalt handelt, können Sie Anfragen an Ihre Domain mit folgendem Befehl in der Datei .htaccess umleiten:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^ihredomain\.ch$ [NC]
RewriteRule ^(.*)$ http://www.ihredomain.ch/$1 [R=301,QSA,L]

Haben Sie Fragen zu diesen Anweisungen? Oder eine eigene Regel, die Sie immer wieder verwenden? Dann hinterlassen Sie uns doch einen Kommentar. Wir freuen uns.

Das Thema Strom ist nicht zuletzt aufgrund der Ereignisse in Japan erneut in die Schlagzeilen gerückt. Der von vielen geforderte Atomausstieg bedingt auch ein Umdenken jedes einzelnen zu seinem persönlichen Stromverbrauch.

Wir betreiben einiges um den Stromverbrauch unserer Infrastruktur zu senken. So wird unser Strom im Rechenzentrum und in unseren Büros beispielsweise aus erneuerbaren Energien produziert bzw. mit Wasserkraftzertifikaten aufgewertet.
Wenn Sie mögen, können Sie mit folgenden Tipps den Stromverbrauch für Ihre Website senken.

E-Mail

• Verlängern Sie die Intervalle der E-Mail-Abholung in Ihrem E-Mail-Programm. Meistens genügt ein Intervall von 10-15 Minuten. Die Abholung der E-Mails alle 60 Sekunden ist meist nur in Ausnahmefällen nötig und kann daher auch manuell ausgeführt werden.
• Löschen Sie nicht mehr benötigte E-Mails auf dem Server und leeren Sie den Papierkorb regelmässig. Dadurch verringert sich der Stromverbrauch, der durch unsere nächtlichen Backups verursacht wird.

Website

• Löschen Sie nicht mehr benötigte Dateien und deinstallieren Sie Scripts wie Gästebücher oder Foren, falls diese nicht mehr benötigt werden.
• Laden Sie Backups auf Ihren lokalen Computer und löschen Sie die Archive danach vom Server. Ansonsten werden diese in einem neuen Backup eingeschlossen und verursachen so doppelten Speicherverbrauch.
• Vergrössern Sie die Intervalle Ihrer Cron Jobs
• Verzichten Sie in Applikationen wie z.B. Wordpress auf Plugins die nicht benutzt werden.

Für Fortgeschrittene

• Optimieren Sie Ihre selbst geschriebenen PHP-Scripts und verringern Sie dadurch deren Ausführungsdauer.
• Vereinfachen Sie Ihre Datenbankstruktur und verringern Sie so die Zugriffszeiten und den Speicherverbrauch.

Bonustipp

• Ändern Sie in Ihrem my.cyon die Versandart von Post auf PDF. Dies verringert zwar nicht zwingend den Stromverbrauch, wirkt sich aber positiv auf die Gesamtbilanz aus, da Ressourcen wie Papier und Transport eingespart werden.

Haben Sie weitere Tipps, wie man den eigenen Stromverbrauch im Internet minimieren kann? Dann hinterlassen Sie uns doch einen Kommentar. Wir freuen uns.

Wenn Sie schon einmal mit uns Kontakt hatten, sei es via Telefon, E-Mail, Social Media oder herkömmlichen Postverkehr, dann kennen Sie ihn: Unseren Support.

Unser Support ist unser Gesicht nach aussen. Wir verfügen nicht über ein Ladengeschäft oder Verkäufer, die bei Ihnen vorbei kommen. Und genau deshalb ist unser Support eine äusserst wichtige Abteilung in unserem Unternehmen.
Unser Support ist Ihre erste Anlaufstelle, wenn es um technische Probleme, Buchhaltungsfragen oder sonstige Angelegenheiten geht. Deswegen arbeitet bei uns jeder neuer Mitarbeiter die ersten zwei Wochen in der Support-Abteilung. Egal ob er als Techniker, Entwickler oder eben Supporter angestellt ist.

Diese Einführungsphase wird von neuen Mitarbeitern geschätzt, denn so erlebt man als Neuling den Kontakt mit unseren Kunden quasi an der Basis mit. Ausserdem kann jeder Mitarbeiter in Ausnahmefällen als Supporter eingesetzt werden.

Wir sehen also den Kundensupport als eine unserer Kernkompetenzen. Es kommt für uns darum niemals in Frage, den Support auszulagern. Vielmehr möchten wir unseren Support noch mehr ausbauen und auf die Bedürfnisse unserer Kunden optimieren. Dazu haben wir bereits einige Neuerungen in petto, die wir in den nächsten Wochen präsentieren können. Sie dürfen also gespannt sein.

Uns nimmt es Wunder, was Sie von unserem Support halten. Gibt es aus Ihrer Sicht Dinge, die man ändern oder verbessern sollte? Wir freuen uns über jeden Kommentar.