Webserver 100% verfügbar

Zur Qualitätssicherung unserer „Hostingangebote“:http://fairhost24.de wird die Erreichbarkeit der Webserver getestet. Zwei unabhängige Providerportale rufen hierbei definierte Dateien ab und führen eine Statistik. Der Test ergibt keine Ausfallzeiten. Was jedoch bemerlenswert ist: Die Ergebnisse unterscheiden sich ein wenig.

Die „Webhostlist“:http://www.webhostlist.de/provider/webhoster/3206/Meinungen.html ermittelt z.B. im Monat Oktober 05 100% Verfügbarkeit, „Homepagekosten“:http://www.homepage-kosten.de/ProviderShow0_929.html nur 99,83 % Verfügbarkeit. Woher diese Differenz kommt, ist ungewiss. Immerhin würde das einen Ausfall von mehr als einer Stunde bedeuten. Ich tippe hier eher auf eine Unzulänglichkeit im Messverfahren zumal Webhostlist der zuverlässigere Anbieter ist.

Die Testergebnisse im Detail

* „fairHOST24 bei Webhostlist“:http://www.webhostlist.de/host/data/zuverlaessigkeit.php?aid=3206
* „fairHOST24 bei Homepagekosten“:http://www.homepage-kosten.de/ProviderShow4_929.html

Update 16.30

Kurz nachdem ich dieses Post fertig hatte der GAU. Die Server im Berliner „Rechenzentrum SEC“:http://de.sec-contract.de/sec/Datacenter/?a=site;mpoint=33 sind nicht erreichbar. Ein traceroute funktioniert, kein Shell, kein Mail, kein http. 🙁

Kurze Recherche ergibt das es nicht alle Kunden betrifft. Offensichtlich gibt es gerade massive Routingprobleme seitens „Lambdanet“:http://lambdanet.de. Aus dem „RZ Düsseldorf (Level3)“:http://www.level3.com/2577.html kann ich wenigstens Shell machen. Ich sehe das auf den Berliner Servern doch noch Leute sind. Die Seiten von Lambdanet sind ebenfalls nicht erreichbar…

Update 5. März, 13.57

Nachricht vom RZ:
die Störung lag laut Lambdanet an einem Peering-Punkt zur Telekom in Hannover. Es war daher nur ein Teil des Datentransfers betroffen. Aus anderen Netzen waren wir regulär erreichbar. Da nur Pakete ab einer bestimmten Größe blockiert wurden, konnten alle Systeme per Ping erreicht werden, während die Pakete von anderen Anfragen auf Grund der größeren Pakete nicht durchgeleitet wurden.

Wir haben nach Kenntnis der Problematik das Routing entsprechend geändert und konnten zwischenzeitlich, nach Behebung des Problems durch Lambdanet, wieder auf die Default-Route umstellen.