Umzug IONOS -> HostEurope

Ich habe ca. 1998 mit der MSXFAQ angefangen und die ganze Zeit ist die Webseite durchweg bei 1&1, mittlerweile IONOS, auf einem "Shared Hosting" gelaufen. Die Seite war flott und gut erreichbar und einmal wurde ich sogar von 1&1 angerufen, weil meine Seite wohl verändert worden war (13. April 2006: msexchangefaq.de hacked). Es gab lange Zeit gar keinen Grund zu klagen. Wobei meine Nutzung natürlich auch für ein Shared Hosting sehr moderat war. Da ich auf PHP und andere Skript-Sprachen verzichte und nur statische HTML-Seiten bereitstelle, muss der Webserver nicht wirklich viel machen.

Diese positive Grundeinstellung hat sich im April/Mail 2020 aber derart geändert, dass ich die MSXFAQ von IONOS zu HostEurope umgezogen habe. Ob damit alles besser wird, muss die Zukunft zeigen, aber schlimmer sollte es nicht mehr werden. Ohne Vorwarnung oder Rückfrage hat IONOS nicht nur die Webseite www.msxfaq.de sondern auch alle anderen Webseiten im Vertrag (z.B. carius.de u.a.) unerreichbar gestellt. Während der erste vom Provider verursachte Ausfall noch schnell behoben wurde, ist die Störung im Mai nicht behoben worden. Details hierzu finden Sie auf MSXFAQ Offline 27.4.2020 + 11/12.05.

Notfallumzug statt Planung

Beim Umzug einer Webseite möchte man natürlich eine minimale Downtime. Ds kann man auch bei einem geplanten Umzug sehr gut realisieren, wenn man eigene Server mit IP-Adressen hat. Dann würde man in etwa folgende Schritte durchlaufen:

  1. Neuer Webserver konfigurieren
    Man würde erst einmal den Server im Ziel bereitstellen, die Webseiten und ggfls. Datenbanken einrichten und die generelle Funktion testen. Hier hatte ich Glück, dass die Domain msxfaq.net schon im Ziel vorhanden war und ich nach dem Upload eine alternative URL anbieten konnte. Ideal wäre, wenn der Hoster auch eine Domain mit Zertifikat einrichten könnte die noch nicht übertragen wurde. Das sollten sie aber bei keinem Massen-Provider erwarten, da das Provisioning und die Selbstadministration das meist nicht hergeben und individuelle Unterstützung eben nicht mit einer "Geiz ist Geil"-Mentalität zusammen passen.
    Die Umstellung wird noch etwas knifflig wenn Sie "HTTP Strict Transport Security" konfiguriert haben.
  2. Frozen Zone und Datenübernahme
    Irgendwann muss man dann natürlich die Daten der Quelle einfrieren, damit eine Änderungen passieren und den Inhalt aktuell auf das Ziel kopieren. Bei mir was einfach, da ih eh nur statischen Inhalt habe und einfach per SFTP meine lokale Seite erneut hochgeladen habe
  3. DNS-Umstellung
    Wenn man die Zeit hat, dann kann man beim alten Provider schon die DNS-Einträge auf den neuen Webserver umstellen. Dazu muss der abgebende Provider natürlich eine Übersteuerung der A-Records zulassen. Es wird einige Stunden dauern, bis diese neue Konfiguration in der Welt bekannt ist. In der Zeit bekommt die neue Seite nach und nach mehr Last und die alte Seite weniger Aufrufe. Perfektionisten setzen vorab auch den TTL herunter, damit solche Änderungen noch schneller propagiert werden, so es denn möglich ist.
  4. Domain Umzug
    Final kann man dann die DNS-Zone zum neuen Provider umziehen. Das ist in der Regel in wenigen Minuten passiert. Allerdings müssen Sie dann auch zusätzliche DNS-Einträge  (SPF, Office365-Einträge etc. nachführen, denn ein Domainumzug heißt nicht, dass die Zone komplett kopiert wird.

So ein Umzug erfordert aber schon einige Tage Vorplanung und selbst dann müssen die Provider mitspielen. Leider hatte ich im Ziel z.B. anfangs noch keine eigene IP-Adresse und die wenigsten Provider erlauben die Konfiguration eines Servers für eine Domain, die dem Vertrag noch nicht zugeordnet ist. Auf der anderen Seite entfernt der abgebende Provider die Konfiguration in der Regel direkt nach dem Umzug der Domain. Vielleicht können Sie nun eher verstehen, das die diversen Aussetzer auch nach dem Umzug weder durch den Provider noch durch mich verursacht sind, sondern einfach an der Natur von DNS im Internet und der ungeplanten Umstellung liegen.

Sizing ermitteln

Den Reinfall mit einer wegen "Überschreitung unbekannter Grenzwerten" deaktivieren Webseite möchte ich nicht noch einmal erleben. Aber vor 22 Jahren war ja nicht abzusehen, welches Ausmaß eine Webseite erlangen kann und mir waren die Grenzen ja nicht bekannt. Eher im Gegenteil, denn das Marketing und die Leistungsbeschreibung war weit über meinen gefühlten Anforderungen. Wäre die MSXFAQ auf Basis eines CMS oder Wordpress gelaufen, dann hätte es wohl schon früher geknirscht. So war es dann im April/Mai 2020 der Fall. Auf der Seite MSXFAQ Offline 27.4.2020 habe eine ausführliche Analyse dokumentiert aus denen ich die Anforderungen an das nächste Hosting abgeleitet habe.

IONOS stell neben den Apache-Logs auch einen ersten Überblick als Verkehrsstatistik bereit. Diese Werte scheint ein Skript für jede Webseite anzulegen und ich kenne das Aussehen schon seit dem Beginn der MSXFAQ. Sie sehen hier die übertragene Datenmenge und die Anzahl der Requests:

Sie sehen gut, dass das Volumen schon längere Zeit hoch ist. Es lässt sich aber noch mehr daraus ablesen:

Kennzahl Beschreibung

750.000 Requests/Tag

Ich habe den Wert aus den 15.000.000 Zugriffe/Monat durch 20 Arbeitstage geteilt. Es sind tatsächlich so viele Zugriffe pro Tag. Wobei das die Zeilen im Apache-Log sind und nicht einzelne "Personen". Der Abruf einer Seite generiert durch Bilder und CSS einige Zeilen mehr und auch Suchmaschinen und RSS-Reader erscheinen genauso wie DoS-Attacken.

6 GB/Tag Volumen

Aus den 120GB/Monat komme ich über 20 Tage auf 6 GB/Tag oder bei 8h eine durchschnittlichen Durchsatz von 2 Megabit/Sek. Gerade beim Shared Hosting gibt es "Fair Use" Policies, d.h. der Server hat vielleicht einen 1 Gigabit-Link aber die durchschnittliche Belastung muss natürlich deutlich drunter liegen oder wird gedrosselt.

30 parallele Requests

Eine genaue Auswertung habe ich noch nicht angestellt aber wenn ich die 750.000-Requests auf 7,5h Arbeitsstunden verteile, dann komme ich auf 100.000 Requests/h oder fast 30 Anforderungen/Sek. Das ist bei Shared Hosting ein Thema aber bei den meisten virtuellen Servern geht es bei 128 Prozessen oder mehr los.

20.000 statische HTML-Seiten mit 5 GB Gesamtvolumen

Die meisten Hostings fangen aber bei 50GB oder 100 GB an. Einige Anbieter beschränken aber die Anzahl und das Wachstum der Dateien ohne es auf der Produktbeschreibung aufzuführen. Bei IONOS finde ich in den AGBs die Werte: 262144 Dateien bei Linux Hosting, 500.000 bei Windows

Das sind die Mindestwerte und da ich ein weiteres Wachstum erwarte, sollte die neue Heimstätte noch genug Reserven haben.

Tschüss Shared Hosting

Für das Nutzerprofil der MSXFAQ ist ein Shared Hosting definitiv nicht mehr der richtige Platz. Zumindest wenn ein Provider seine Produkte so auslegt, dass diese Kunden eben auch nur eine gewisse Last erzeugen. Insofern ist der Erfolg der MSXFAQ nun auch damit verbunden, dass ich beim Hosting andere Wege gehen muss.

Es reicht hier vermutlich nicht, einfach einen anderen Provider zu wählen, da diese natürlich auch beim Shared Hosting ähnliche Techniken verwenden. Es ist zudem sehr schwer genau diese Stolpersteine und Einschränkungen zuverlässig zu ermitteln. Bei einem "eigenen Server" gibt die Hardware die Performance vor.

Der Weg war damit vorgezeichnet, dass ich ein größeres Paket bei einem Hoster einkaufen muss, der mit dem Volumen zurecht kommt. Es sollte aber auf jeden Fall ein "managed Server" sein, der vom Hoster mit dessen Expertise betrieben wird. Schließlich möchte ich mich nicht mit Updates des Betriebssystems und des Webservers, Backup/Restore, SSL-Zertifikate u.a. herum schlagen. Damit stellt sich dann aber die Frage, von wem dieser Server gehostet wird. Es ist ja "nur" die Domain "msxfaq.de" und nicht all die anderen Domains. Und da ich keine Datenbanken o.ä. nutze, kann ich den Inhalt ganz schnell von einer Plattform auf eine andere Plattform übertragen.

Ein Wechsel meines aktuellen Webhosting-Pakets bei IONOS habe ich verworfen, da es nicht nur die MSXFAQ-Webseiten sondern auch andere Domains mit mehreren Postfächern enthält. Bei einem Wechsel wären diese z.B. von 50GB auf 2GB beschnitten worden, so dass ich hier erst umschichten müsste. Bei einem Providerwechsel des Gesamtpakets müsste ich auf vielen vielen Endgeräten die Zugangsdaten anpassen. Daher verbleibt das bisherige Webhosting noch bis auf weiteres bei IONOS aber für die MSXFAQ ist der Wechsel ausgemacht.

Provider Umfrage

Ich muss zugeben, dass ich aufgrund der kurzen Zeit keine umfassende Analyse aller Provider gemacht habe. Ich habe mich jahrelang nicht damit befassen müssen und musste feststellen, dass der Markt sich etwas bereinigt und verändert hat. Strato und 1&1/IONOS gehören zur gleichen Holding "United Internet". Andere mir bekannte Hoster haben ganz neue Produkte erschlossen aber zumindest laut Webseite das klassische Webhosting nicht mehr aktiv im Verkauf.

Ich habe daher im Bekanntenkreis (andere MVPs, Net at Work Kollegen etc.) rumgefragt, wo sie ihre Webseiten und Dienste betreiben und welche Erfahrungen sie damit haben. Interessanterweise haben mehrere auch schon den Umzug von IONOS zu einem anderen Provider hinter sich. Mein MVP Kollege Günther Born (https://www.borncity.com/blog/) nutzt z.B. HostEurope und hat ein ähnliches Lastprofil, womit ich für das Sizing schon einmal einen wichtigen Hinweis hatte.

Ich habe alle Hoster versucht per Telefon zu erreichen, was mir zugleich auch einen Stichprobe der Erreichbarkeit geliefert hat. Ich habe gezielt mit meinem Kennzahlen gearbeitet und wollte von den Ansprechpartnern eine Aussage, welches Produkt sie mit empfehlen. Ich erwarte von seinem Hoster, dass er mit den Angaben zu Dateianzahl/Größe, Request/Tag und der Plattform "Statisches HTML" ein einfaches Sizing machen kann. Wer, wenn nicht ein Hoster, kann solche Erfahrungswerte von eigenen Kundeninstallationen vorweisen. Ich habe auch das aktuelle Problem der Vollabschaltung bei Überschreitung von unbekannten Grenzwerten hingewiesen. Leider sind ja die ganzen Marketing-Seiten gerade hinsichtlich dieser viel wichtigeren Parameter ungeeignet.

Insgesamt habe ich mehrere Stunden am Telefon verbracht und ich bitte um Nachsicht, wenn ich nicht weitere Provider angerufen habe und genau den wichtigsten Hoster übersehen haben sollte. Es ist eine Momentaufnahme und die Beschreibung ist auch nur eine Kurzfassung und sollte nicht als Wertung verstanden werden:

Provider Beschreibung

HostEurope

Es gibt keine kommunizierten Limits aber ein Shared Hosting dürfte nicht ausreichend sein. Basierend auf den Werten würde aber der kleinste managed WebServer locker ausreichen. Angeblich gibt es Kunden mit 1Mio Requests/Tag. Damit kann man schon mal was anfangen.

https://www.hosteurope.de/WebServer/

OVH

Ich habe schon einen Vertrag bei OVH um DNSSEC zu testen. Die Server stehen natürlich in Frankreich aber das ist ja EU. Allerdings habe ich den Anruf nach 20 Min in der "Vertriebs-Warteschlange" abgebrochen. Ich habe schon früher die Erreichbarkeit kritisch gesehen und daher hier nicht weiter geforscht.

Manitu

Keine Erreichbarkeit des Vertriebs per Telefon.
Laut Webseite bieten sie aber eh nur Shared Hosting und richtige Root Server an. Ich suche eigentlich einen "Managed Server" und habe den Weg nicht weiter verfolgt.

Hetzner

Per Telefon wurde mit relativ schnell gesagt, dass meine Workload nicht für "Shared Hosting" geeignet ist und auch Hetzner bei Überlast Webseiten sperrt. Auf die Frage, was denn "Überlast" bedeutet, konnte der Ansprechpartner nichts sagen. Auch zur Auswahl eines passenden Managed Server wurde keine Lösung skizziert.

AllInkl

All-Inkl hat mir aber zumindest gleich gesagt, dass diese Workload nicht auf einem Shared Hosting funktionieren wird

IONOS

Ich habe mir die Angebote natürlich vorab schon angeschaut und sie sind durchaus "nach Aktenlage" attraktiv. Mit den Erfahrungen vom 12. Mai (Siehe MSXFAQ Offline 27.4.2020 + 11/12.05) habe ich dies aber sprichwörtlich zu den Akten gelegt.

Da alle Provider eine "hohe Verfügbarkeit" versprechen, aber ich nicht im Hintergrund nachschauen kann, habe ich hier nicht weiter nachgebohrt. Letztlich kann ich die MSXFAQ ja überall und zu jeder Zeit aus meiner lokalen Instanz auf jedem beliebigen Service bereitstellen. Sollte der Server ausfallen, muss vom Hoster nur eine Ersatzmaschine (auch virtuell) mit der gleichen IP-Adresse bereit gestellt werden.

Mit etwas mehr Zeit hätte ich neben all den "Fakten" auf den Werbeseiten noch einige Punkte hinterfragt, die mir wichtig wären:

  • Domain "Preregistrieren" mit SSL-Zertifikat
    Damit der Umzug ohne Unterbrechung läuft, müsste der Zielserver schon anfragen auf die Domain annehmen und ausliefern, auch wenn der Provider nicht für den DNS-Namen zuständig ist. Natürlich auch mit SSL-Zertifikat. Nur so könnte man im DNS schon die neue IP-Adresse eintragen und beide Server parallel vorhalten.
  • Zugriff auf Logs
    Die wenigsten Administratoren schauen sich die Apache-Logs an. Ich mache es aber schon manchmal und dazu braucht man einen Zugriff. Jeder Provider stellt diese Logs bereit aber nicht alle sind einfach per FTP automatisiert erreichbar.
  • Abschaltverhalten
    Ich habe aktiv seit dem Problem mit IONOS gesucht aber auch andere Provider schreiben nicht wirklich fest, wie viele Request/Sek oder Abrufe/Tag zugesichert werden.
  • Performance Monitoring
    Ich leiste mir den Luxus die Webseite per PRTG zu überwachen. Allerdings sehe ich nur den HTTPS-Zugriff. Ein Abruf der CPU-Last, Anzahl an Thread, Freier/Belegter Speicherplatz stellt kein Anbieter bereit. Schade, denn so kann ich als Kunde gar nicht ermitteln, wann ich ein Upgrade kaufen sollte. Die Provider meldet sich wohl nicht alleine sondern schalten einfach ab.

All die anderen Faktoren wie Speicherplatz, "Unlimited" Traffic, Aktuelle PIP-Versionen, Wordpress&Co als Installationspaket etc. sind in der Regel überall da.

Was ist mit Azure?

Mich haben mehrere Hinweise zu Azure erreicht und natürlich kenne ich auch das Produktangebot von Microsoft. Über Azure kann ich Webseiten hosten (Azure Blog Storage), Last per CDN verteilen, eigene DNS-Zonen verwalten und vieles mehr. Die Frage ist dabei nur, ob ich als Einzelperson mir die Mühe machen möchte, all diese Komponenten zusammen zu setzen, mir zu überlegen, wie ich die Daten bereitstelle, in welcher Form Zugriffslogs verfügbar sind. Natürlich könnte ich auch eine virtuelle Maschine mit Linux/Apache oder Windows/IIS konfigurieren.

Vielleicht schaue ich mir das in Zukunft mal an aber so eine Entscheidung fällt man nicht unter Zeitdruck und ich suche ein "selbst laufendes System". Daher vertraue ich auf die Administration, das Provisioning u.a. von klassischen Hosting Providern, die ein fertiges Produkt anbieten anstatt in der jetzigen Situation aus einem Baukasten eine Webplattform nach eigener Überlegung bereit zu stellen.

Umzug

Nachdem die Entscheidung gefallen ist, musste ich handel. Mein Plan war:

  • Upgrade des Hostingpakets
    Durch den Wechsel von einem "Web Pack 4 L" auf "Webserver Basic SSD" sollte die Plattform die Last bedienen können und in dem größeren Paket ist das SSL-Zertifikat und eine statische IP-Adresse enthalten. Der Umzug wurde mit der Option "sofort" gegen 18:30 im Dialog mit einem HE-Mitarbeiter ausgelöst.
  • Umzug der Domain
    Damit ich aber unter "msxfaq.de" bei HostEurope arbeiten kann, musste ich die Domain umziehen. Es war ja schon wieder Abends. Also bei IONOS schnell den AuthCode für die msxfaq.de abgerufen und bei HostEurope eingegeben und den Umzug gestartet
  • SSL u.a. konfigurieren
    Einige Einstellungen konnte ich schon vorher vornehmen aber das SSL-Zertifikat konnte ich erst nach dem Upgrade des Webhostings machen

So ganz ist der Plan leider nicht aufgegangen, weil sie das Upgrade des Hostings verzögert hat. Ich gehe davon aus, dass hier immer noch ein Mensch drüber schaut und den Konvertierungsprozess freigibt. Technisch ist es ja schon etwas aufwändiger eine Webseite im Shared Hosting-Paket in eine eigene VM zu verschieben. Da dürften schon Webdateien aber auch Mailbox-Inhalte zu kopieren sein und natürlich ändert sich im DNS dann nochmal die IP-Adresse. Erst dann kann ich auch SSL aktivieren. HostEurope hat mich automatisiert per Mail auf dem Laufenden gehalten:

Grün sehen Sie das zuerst beauftrage Upgrade des Vertrags der aber erst am nächsten Vormittag aktiv wurde. Das ist schlecht gelaufen. Der Umzug der DNS-Zone msxfaq.de hingegen war nach 5 Minuten erfolgt und auch das SSL-Zertifikat war einfach und schnell bereitgestellt.

Für einen Sachverhalt kann aber kein Provider etwas, wenn der Umzug so forciert erfolgt:

Schon die IP-Adress-Änderung mit dem Domain-Umzug sorgt in der Regel für eine "Offline"-zeit von mehreren Stunden, denn der abgebende Provider IONOS entfernt die umgezogene Domain sofort aus seinem System und beantwortet auch keine Anfragen mehr. Die DNS-Server der Welt haben aber einen Cache und erst wenn der TTL abgelaufen ist, fragen sie neu nach. Sie können ja den SOA-Record ihrer Domäne vor dem Umzug abfragen:

C:> nslookup -q=SOA msxfaq.de

msxfaq.de
        primary name server = ns1121.ui-dns.biz
        responsible mail addr = hostmaster.schlund.de
        serial  = 2016112501
        refresh = 28800 (8 hours)
        retry   = 7200 (2 hours)
        expire  = 604800 (7 days)
        default TTL = 300 (5 mins)

Nicht alle DNS-Server halten sich an den Default TTL und es kann auch noch abweichende TTLs pro Host geben. Erst die Debug-Ausgabe mit NSLookup liefert die Info, dass der Autoritative Nameserver noch deutlich länger gehalten. 8 Stunden sind ziemlich lange, wenn Sie auf eine Änderung warten.

    QUESTIONS:
        msxfaq.de, type = NS, class = IN
    ANSWERS:
    ->  msxfaq.de
        nameserver = ns1121.ui-dns.biz
        ttl = 11454 (3 hours 10 mins 54 secs)
    ->  msxfaq.de
        nameserver = ns1121.ui-dns.org
        ttl = 11454 (3 hours 10 mins 54 secs)
    ->  msxfaq.de
        nameserver = ns1121.ui-dns.de
        ttl = 11454 (3 hours 10 mins 54 secs)
    ->  msxfaq.de
        nameserver = ns1121.ui-dns.com
        ttl = 11454 (3 hours 10 mins 54 secs)

Wenn ich aber direkte das DENIC frage, dann steht dort schon der neue DNS-Server aber auch mit einem TTL von eine Tag.

> msxfaq.de.
Server:  s.de.net
Addresses:  2003:8:14::53
          195.243.137.26

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 12, rcode = NOERROR
        header flags:  response, want recursion
        questions = 1,  answers = 0,  authority records = 2,  additional = 0

    QUESTIONS:
        msxfaq.de, type = NS, class = IN
    AUTHORITY RECORDS:
    ->  msxfaq.de
        nameserver = ns1.hans.hosteurope.de
        ttl = 86400 (1 day)
    ->  msxfaq.de
        nameserver = ns2.hans.hosteurope.de
        ttl = 86400 (1 day)

Das erklärt natürlich, dass der Umzug der DNS-Domain im schlimmsten Fall bis zu 24 Stunden dauert, dass der letzte DNS-Server endlich versteht, dass die Delegierung hier von IONOS zu HostEurope verschoben wurde. Nach dem Umzug wusste das DENIC sofort, dass neue Nameserver für diese Domain zuständig sind.

Mit NSLOOKUP konnte ich dann schön beobachten, wie nach und nach die DNS-Server der Welt die Änderung übernommen haben. Dabei muss man natürlich aufpassen, da genau so eine Frage den DNS-Server dazu bringt, vielleicht einen veralteten Stand von seinem UpStream-DNS Server zu laden und nun erst recht im Cache zu halten. Die DNS-Dienste Quad9 (9.9.9.9) als auch Google (8.8.8.8) haben die Änderung erstaunlich schnell übernommen. Ob die Konfguration dort den TTL ignoriert, um aktuellste Daten zu liefern?

Interessanterweise haben gerade die DNS-Server der Telekom-DSL-Anschlüsse (hh-lb-a01.isp.t-ipnet.de (217.237.150.205) und h-dnslb-a01.isp6.t-ipnet.de (2003:180:2:4000::53) die MSXFAQ ab 12. Mai 22:00 Uhr gar nicht mehr auflösen können. Die Server in Dortmund do-nxr-a01.isp.t-ipnet.de (217.0.43.17) hingegen konnte die Adresse auflösen. Gesehen habe ich das nur, weil PRTG das als Fehler gesondert gemeldet hat:

Insofern konnte ich es nicht abkürzen, dass die MSXFAQ auch am 13.5 noch von dem ein oder anderen Client nicht erreichbar war.

Performance

Auch mein Überwachung hat ohne Umkonfiguration nach einiger Zeit wieder. ich habe aber dennoch mein Monitoring um weitere Sensoren erweitert, dass ich nun auch die PING-Laufzeit und parallel noch HTTP und HTTPS-Zugriffe prüfe.

Interessant ist aber schon nach wenigen Stunden der direkte Vergleich. der Responsezeit eines HTTP-Requests. Die letzten 30 Tage vor dem Ausfall bei IONOS kam ich auf Mittelwerte bei ca. 110ms mit einigen Peak.

Für den Betrieb bei HostEurope habe ich noch nicht so lange Daten aber der Mittelwert ist hier eher bei 82ms.

Nun hören sich 30ms Unterschied nicht viel an aber es ist schon merklich. Interessant finde ich, dass heute nochmal etwas "passiert" sein muss, denn seit 20:00 ist die Antwortzeit noch mal schneller geworden.

Da muss ich mal ein Auge drauf haben. Allerdings kann ich hier nicht sehen, wie weit die Entfernung von meinem DSL-Anschluss zum Webserver ist und welche Rolle ob das Netzwerk spielt. Da aber meine "carius.de"-Seite immer noch bei IONOS liegt, habe ich ja zwei Gegenstelle, die ich per HTTP: PING und Traceroute ansprechen kann.

Einen Tag später hatte ich dann auch mehr Daten im direkten Vergleich. Obwohl meine MSXFAQ nun nicht mehr auf dem IONOS Shared Server läuft und damit viel Last entfallen sein müsste, ist die carius.de-Seite immer noch deutlich langsamer:

Die Bilder sehen sehr ähnlich aus aber PRTG skaliert dynamisch die Daten. Sie müssen links die Skala in Millisekunden im Blick behalten. Links ist die neue MSXFAQ mit Antwortzeiten zwischen 50-60 Millisekunden. Rechts dann der IONOS Server mit Werten im Bereich 90-100 Millisekunden. Schade, das Provider solche Daten selbst vielleicht erheben aber nicht den Kunden zur Verfügung stellen oder zumindest dem Kunden einen Tipp geben, wenn Server langsam sind.

In dem Zuge ist natürlich auch der Weg von meiner Messstation zu den Servern interessant. Daher habe ich am 13.5.2020 mit PING/TRACERT eine kleine Serie erstellt:

Gegenstelle IONOS HostEurope
Ping 19:00
C:\>ping www.carius.de

Ping wird ausgeführt für www.carius.de [217.160.0.234] mit 32 Bytes Daten:
Antwort von 217.160.0.234: Bytes=32 Zeit=13ms TTL=58
Antwort von 217.160.0.234: Bytes=32 Zeit=13ms TTL=58
Antwort von 217.160.0.234: Bytes=32 Zeit=13ms TTL=58
Antwort von 217.160.0.234: Bytes=32 Zeit=13ms TTL=58
C:\>ping www.msxfaq.de -4

Ping wird ausgeführt für www.msxfaq.de [178.77.117.98] mit 32 Bytes Daten:
Antwort von 178.77.117.98: Bytes=32 Zeit=24ms TTL=58
Antwort von 178.77.117.98: Bytes=32 Zeit=23ms TTL=58
Antwort von 178.77.117.98: Bytes=32 Zeit=23ms TTL=58
Antwort von 178.77.117.98: Bytes=32 Zeit=23ms TTL=58
Traceroute
19:00
C:\>tracert www.carius.de

Routenverfolgung zu www.carius.de [217.160.0.234]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2     4 ms     5 ms     5 ms  62.155.242.220
  3    15 ms    14 ms    14 ms  f-ee1-i.F.DE.NET.DTAG.DE [62.154.14.54]
  4    11 ms    11 ms    11 ms  62.157.249.74
  5    14 ms    16 ms    16 ms  ae-9.bb-b.bs.kae.de.oneandone.net [212.227.120.168]
  6    14 ms    14 ms    14 ms  port-channel-2.gw-distd-sh-1.bs.kae.de.oneandone.net [212.227.116.221]
  7    13 ms     *        *     217-160-0-234.elastic-ssl.ui-r.com [217.160.0.234]
  8    13 ms     *       14 ms  217-160-0-234.elastic-ssl.ui-r.com [217.160.0.234]
C:\>tracert www.msxfaq.de

Routenverfolgung zu www.msxfaq.de [2a01:488:42:1000:b24d:7562:25:6783]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  fritz.box [2003:ea:a716:7000:cece:1eff:fe34:3d04]
  2     8 ms     5 ms     5 ms  2003:0:8504:d000::1
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4    12 ms    12 ms    11 ms  ae0.cr-polaris.fra1.bb.godaddy.com [2003:0:1304:8007::2]
  5    24 ms    23 ms    18 ms  ae0.cr-antares.fra10.bb.godaddy.com [2a01:488:bb03:100::3]
  6    24 ms    24 ms    24 ms  ae0.cr-vega.sxb1.bb.godaddy.com [2a01:488:bb03:101::3]
  7    25 ms    22 ms    23 ms  ae0-v100.sr-helios.sxb1.mass.systems [2a01:488:bb00:102::3]
  8    24 ms    23 ms    24 ms  xh1153.webpack.hosteurope.de [2a01:488:42::a5c:213d]
  9    24 ms    23 ms    24 ms  vwp17599.webpack.hosteurope.de [2a01:488:42:1000:b24d:7562:25:6783] 

Gut zu sehen, dass zwischen Polaris und Antares am Hop 5 eine Verzögerung auftritt

TraceRT
20:45
C:\>tracert www.carius.de

Routenverfolgung zu www.carius.de [217.160.0.234]
über maximal 30 Hops:

  1     2 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2     6 ms     8 ms     5 ms  62.155.242.220
  3    18 ms    13 ms    14 ms  f-ee1-i.F.DE.NET.DTAG.DE [62.154.14.54]
  4    12 ms    11 ms    11 ms  62.157.249.74
  5    13 ms    13 ms    13 ms  ae-9.bb-b.bs.kae.de.oneandone.net [212.227.120.168]
  6    14 ms    13 ms    14 ms  port-channel-2.gw-distd-sh-1.bs.kae.de.oneandone.net [212.227.116.221]
  7    13 ms    13 ms     *     217-160-0-234.elastic-ssl.ui-r.com [217.160.0.234]
  8    13 ms     *       14 ms  217-160-0-234.elastic-ssl.ui-r.com [217.160.0.234]

Diese Verzögerung ist aber wenige Stunden später nicht mehr da.

C:\>tracert www.msxfaq.de

Routenverfolgung zu www.msxfaq.de [2a01:488:42:1000:b24d:7562:25:6783]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  fritz.box [2003:ea:a716:7000:cece:1eff:fe34:3d04]
  2     6 ms     6 ms     5 ms  2003:0:8504:d000::1
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4    12 ms    11 ms    12 ms  ae0.cr-polaris.fra1.bb.godaddy.com [2003:0:1304:8007::2]
  5    12 ms    11 ms    11 ms  ae0.cr-antares.fra10.bb.godaddy.com [2a01:488:bb03:100::3]
  6    24 ms    23 ms    23 ms  ae0.cr-vega.sxb1.bb.godaddy.com [2a01:488:bb03:101::3]
  7    14 ms    14 ms    14 ms  ae4.cr-nunki.sxb1.bb.godaddy.com [2a01:488:bb::b2]
  8    14 ms    15 ms    14 ms  ae0-v100.sr-sol.sxb1.mass.systems [2a01:488:bb00:101::3]
  9    14 ms    14 ms    14 ms  xh1153.webpack.hosteurope.de [2a01:488:42::a5c:213d]
 10    15 ms    15 ms    14 ms  vwp17599.webpack.hosteurope.de [2a01:488:42:1000:b24d:7562:25:6783] 
C:\>tracert -4 www.msxfaq.de

Routenverfolgung zu www.msxfaq.de [178.77.117.98]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2     5 ms     5 ms     4 ms  62.155.242.220
  3    14 ms    14 ms    13 ms  217.239.40.178
  4    14 ms    14 ms    14 ms  ae8.cr-nunki.sxb1.bb.godaddy.com [62.157.249.226]
  5    15 ms    14 ms    14 ms  ae0-v100.sr-sol.sxb1.dcnet-emea.godaddy.com [87.230.112.3]
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7    15 ms    14 ms    15 ms  vwp17599.webpack.hosteurope.de [178.77.117.98]

Zum Zeitpunkt des ersten Vergleichs der HTTP-Response-Time ist der einfache ICMP-Ping von IONOS mit 13ms schon schneller als HostEurope mit 23ms. Dennoch ist die HTTP-Zeit insgesamt mit 82ms im Mittel bei HostEurope besser. Man könnte versucht sein, die Serverzeit durch die Differenz zu bilden. Dann wäre mein neuer "WebServer Basic SSD" mit ca. 49ms ja fast doppelt so schnell als der vorherige IONOS-Server mit 110ms - 13ms = 97ms. Die Rechnung ist so aber nicht legitim, denn sie beruht auf einem einzelnen Ping und auch der Inhalte der msxfaq.de ist sicher größer als von carius.de. Erste mit einer kontinuierlichen Test-Serie könnte man hier ein besseres Bild bekommen.

Sie sehen aber auch, wie essentiell ein Monitoring von solchen Diensten ist. Es geht nicht nur um den Alarm beim Ausfall oder den Belegt von Aussetzern sondern auch um Basis-Werte zur Erkennung von

Um 20:45 habe ich mich auch dran erinnert, dass meine neue Webseite ja sowohl statische IPv4- als auch IPv6-Adressen hat. Da liegt ein Vergleich der Routen schon auf der Hand.

IPv4 IPv6
C:\>tracert -4 www.msxfaq.de

Routenverfolgung zu www.msxfaq.de [178.77.117.98]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2     5 ms     5 ms     4 ms  62.155.242.220
  3    14 ms    14 ms    13 ms  217.239.40.178
  4    14 ms    14 ms    14 ms  ae8.cr-nunki.sxb1.bb.godaddy.com [62.157.249.226]
  5    15 ms    14 ms    14 ms  ae0-v100.sr-sol.sxb1.dcnet-emea.godaddy.com [87.230.112.3]
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7    15 ms    14 ms    15 ms  vwp17599.webpack.hosteurope.de [178.77.117.98]
C:\>tracert www.msxfaq.de

Routenverfolgung zu www.msxfaq.de [2a01:488:42:1000:b24d:7562:25:6783]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  fritz.box [2003:ea:a716:7000:cece:1eff:fe34:3d04]
  2     6 ms     6 ms     5 ms  2003:0:8504:d000::1
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4    12 ms    11 ms    12 ms  ae0.cr-polaris.fra1.bb.godaddy.com [2003:0:1304:8007::2]
  5    12 ms    11 ms    11 ms  ae0.cr-antares.fra10.bb.godaddy.com [2a01:488:bb03:100::3]
  6    24 ms    23 ms    23 ms  ae0.cr-vega.sxb1.bb.godaddy.com [2a01:488:bb03:101::3]
  7    14 ms    14 ms    14 ms  ae4.cr-nunki.sxb1.bb.godaddy.com [2a01:488:bb::b2]
  8    14 ms    15 ms    14 ms  ae0-v100.sr-sol.sxb1.mass.systems [2a01:488:bb00:101::3]
  9    14 ms    14 ms    14 ms  xh1153.webpack.hosteurope.de [2a01:488:42::a5c:213d]
 10    15 ms    15 ms    14 ms  vwp17599.webpack.hosteurope.de [2a01:488:42:1000:b24d:7562:25:6783] 

Ich hatte eigentlich erwartet, dass die WAN-Strecken heute schon alle IPv4 und IPV6-Routen und daher der Weg für die Pakete identisch wäre. Dem ist aber nicht so. Der IPv4-Weg ist 3 Hops kürzer aber von der Geschwindigkeit vergleichbar. Sie sehen hier aber auch, dass es wohl ein direktes Peering der Telekom mit dem Carrier "GoDaddy" gibt, der zugleich Gesellschafter von HostEurope ist.

Nacharbeiten

An sich läuft die MSXFAQ so erst mal wieder. Es bleiben aber noch einige Punkte offen, die ich etwas später angehen möchte:

  • HTACCESS-Datei
    Aktuell sind noch die Umleitungen von HTTP auf HTTPS als auch von msxfaq.* auf msxfaq.de deaktiviert. Solange kein Zertifikat vorhanden war oder DNS die Werte falsch geliefert hat, sollte ich den Zugang nicht über alternative URLs erschweren. Google und Co mögen es aber nicht so gerne, wenn der gleiche Inhalt unter mehreren URLs erreichbar ist. Ich habe daher ein zweites Verzeichnis angelegt, auf die die alternativen URLs leite und über eine Redirect-Umleitung auf die MSXFAQ.DE lenke. So sieht das in KIS aus:

    Das diese andere Seite nicht per HTTPS erreichbar ist, sollte es auch keine Zertifikatswarnungen mehr geben. In der ".htaccess" steht dazu einfach:
RewriteEngine On
RewriteCond %{REQUEST_URI} (.*)
RewriteRule ^(.*)$ http://www.msxfaq.de/$1 [L,R=301]
  • Besseres Monitoring
    Ich habe ja nun einen aktiven eigenen Server, wenngleich auch nur virtuell. Dennoch wären ein paar Infos zu CPU-Last, Apache Prozess-Last etc. interessant. Vielleicht ist so etwas ja per SSH möglich. PRTG hat schon zwei passende Sensoren eingebaut. Leider ist die SSH-Shell aber eine stark beschränkte Bash, die eigentlich nur Veränderungen an den Dateien zulässt. Damit fallen die beiden Sensoren erst einmal weg
    PRTG Manual: SSH Load Average Sensor: https://www.paessler.com/manuals/prtg/ssh_load_average_sensor
    PRTG Manual: SSH Disk Free Sensor: https://www.paessler.com/manuals/prtg/ssh_disk_free_sensor
    PRTG Manual: SSH Meminfo Sensor https://www.paessler.com/manuals/prtg/ssh_meminfo_sensor
    Aber da bin ich wohl eher eine Ausnahme mit meinen Wünschen.
  • Aktuelle Logfiles
    Bei IONOS habe ich die AccesLogs per SFTP herunter geladen und mit Powershell und PowerBI analysiert. Ich habe ja eine Liste der gültigen URLs und wenn ich die alle rauswerfe, dann sehe ich die verschiedenen Angriffsmuster auf nicht vorhandene Wordpress-URLs, Backdoors etc. Eigentlich erschreckend, dass die die Provider nicht automatische Gegenmaßnahmen einleiten und sich untereinander abstimmen.
    Mit HostEurope muss ich nun erst mal selbst dran denken, die Logs einmal in der Woche per Browser zu laden, solange ich keine API gefunden habe.
  • Alte Logfiles
    Interessant fand ich aber auch die noch vorhandenen Logfiles, denn "eigentlich" sollte niemand die bisherige Web-Präsenz aktiv nutzen. Alle Zugriffe wurden ja per HTACCESS auf die msxfaq.de bei IONOS umgeleitet. Dennoch gab es einige Zugriffe, die ich später mal vorstelle.

Weitere Links