Ein Online-Shop zieht um

Online-Shop-Umzug für bessere Performance

Im Dezember letzten Jahres erhielten wir eine interessante Anfrage: Ein Noch-nicht-Kunde wollte seinen Online-Shop (Software SHOPWARE) im laufenden Betrieb umziehen. Er hatte gute Gründe für seine Entscheidung: mangelnde Performance bei den regelmässigen Neuindizierungen der Datenbank, aber auch im normalen Betrieb. Denn bisher stieg die Auslastung des dedizierten Servers oft auf 100% und blieb dann längere Zeit auf diesem Level, die Antwortzeit des Shops war während dessen extrem schlecht. Man fragte uns, ob wir hier helfen könnten. Unsere Anwort: Ja, wir können.

Die Herausforderung

Die größte Herausforderung war: Es durfte auf keinen Fall eine Downtime geben. Normaler Weise ist das für uns kein Problem, denn mit WebSite-Umzügen haben wir viel Erfahrung. Jedoch sind Online-Shops eine besondere Herausforderung, vor allem dann, wenn wir den gesamten Umzug vorbereiten und durchführen sollen.

Insbesondere eine Frage beschäftigte uns vorab: Wie finden wir heraus, wie viele Ressourcen tatsächlich während des Umzugs und danach notwendig sind. Und wie meistern wir die Herausforderung, im laufenden Betrieb einen gut frequentierten Online-Shop unbemerkt umzuziehen? Das wollen wir Ihnen in diesem Beitrag beschreiben.

Die Bestandsaufnahme

Der ungeliebte Server stand bei einem der „ganz Grossen“ im schönen Thüringen, genauer gesagt in Falkenstein. Der Server verfügte nominell über reichlich Ressourcen: 64 GB RAM, 2x 1 TB HD sowie eine schnelle Intel-E7-CPU. Der Online-Shop hatte einige tausend Artikel im Bestand. Die Zugriffszahlen lagen bei unter 1000 pro Tag.

Soviel wussten wir. Jedoch war uns zunächst unklar, mit welchem „Gegenangebot“ wir uns bewerben sollten. Denn eigentlich war der bisher gebuchte Server auf den ersten Blick überdimensioniert, aber beim genauen Hinschauen fiel dann doch dieses auf:

  • Die beiden Festplatten mit je 1 TB waren 3,5 “ SATA-Desktop-Platten mit 7200 U/min.
    • Die Schnittstellentechnik „SAS“ ist im Serverbetrieb „SATA“ vorzuziehen.
    • 2,5″-Platten haben eine bessere Zugriffszeit als 3,5″-Platten
    • 7200 U/min Platten auf SATA-Basis haben bei einem Shopserver nichts verloren.
  • Das angepriesene Raid war ein Software-Raid.
    • Das heißt, es wird von der CPU betrieben. Der im Mainboard integrierte Raid-Controller ist, verglichen mit einer externen Raid-Controller-Karte eine „Krücke“. Also wird die CPU unnötig belastet.
    • Es stand auch nur eine CPU zur Verfügung.
    • Die verfügbare Bandbreite lag mit 1,5 GBit/s auch am unteren Ende, verglichen mit 6 Gbit/s eines Hardware-Raid-Controllers.
  • Der Webserver war Apache. Ohne dem bewährten Apache weh tun zu wollen: NGINX IST schneller und skaliert deutlich besser.

Die Alternative

Bei der Analyse dieser Systemdaten erhielten wir die wichtigsten Hinweise, warum der Shop-Betreiber mit dieser Lösung unglücklich sein musste. Dadurch konnten wir ein Alternativ-Angebot kalkulieren. Allerdings wollten wir  nicht mit dem ganz grossen Hammer zuschlagen. Denn wir wollten ein passendes, aber kein überdimensioniertes Angebot abgeben.

Und so sah es aus: Wir ziehen den Shop wie gewünscht zu uns um. Das neue System statten wir am Start zunächst mit reichlich Reserven aus und beobachten dann einige Wochen, wie es reagiert. Danach passen wir die neue Umgebung dann exakt an die realen Bedürfnisse an.

Der Umzug des Online-Shops

Die Analyse der Systemumgebung

Zum Start stellten wir einen neuen Server mit 64 GB RAM, ein Hardware-Raid mit drei Server-SSD im Raid 5 und zwei aktuelle vCPU mit 4 Kernen von Intel mit E7-Technik zur Verfügung. Auf der WebServer-Umgebung verwendeten wir das bewährte Team aus NGINX, PHP 7.3 und MariaDB mit einer angepassten Konfiguration. Dazu gehörte das neue HTTP-Protokoll genau so wie einige Konfigurations-Feinheiten.

Die Domainübernahme

Vor dem eigentlichen Umzug holten wir die Verwaltung der zugehörigen Domain zu uns. Dadurch konnten wir den späteren Schwenk von Thüringen nach Berlin, genauer gesagt von einer IP-Adresse auf eine andere, besser vorbereiten und die sichere Funktion gewährleisten.

Die nächsten Schritte

Da wir direkten Serverzugriff per SSH hatten, konnten wir den Umzug optimal vorbereiten. Das ging so:

  • Wir kopierten das Dateisystem des Webservers sowie einige Logfiles 1:1 auf den neuen Server und achteten gleichzeitig darauf, dass die Datei- und Verzeichnisrechte nicht verändert wurden.
  • Wir sicherten die Datenbanken zunächst per SQL-Dump und übertrugen sie dann auf den neuen Server.

Damit hatten wir ein lauffähiges System, genauer gesagt eine exakte Kopie des Shops bei uns laufen und konnten in aller Ruhe die Funktion prüfen und optimieren. Letzteres brachte auch tatsächlich einen spürbaren, wenn auch noch nicht wesentlichen Performance-Schub. Das wichtigste war aber: der Online-Shop würde bei uns einwandfrei laufen.

Mehrfache Synchronisierung notwendig

Nun legten wir zwei Skripte an, die per Rsync sowohl das Dateisystem des Webservers als auch die wesentlichen Datenbank-Tabellen von alt nach neu syncronisieren sollten. Da beide Server sehr breitbandig angebunden waren, gab es hierbei keine Probleme, die Datenbank blieb konsistent.
Für den Fall, dass es zu Inkonsistenzen gekommen wäre, hätten wir den Shop für einige Sekunden in den Wartungsmodus schalten müssen und dann die Datenbanktabellen syncronisiert.

Diese Syncronisierung wiederholten wir mehrfach. Dann waren wir uns recht sicher, dass es dabei auch zum eigentlichen geplanten Schwenktermin keine Probleme geben würde.

Die letzten Handgriffe

Bevor wir den geplanten Schwenk durchführten, zogen wir noch das vorhandene SSL-Serverzertifikat um und verbesserten die SSL-Einrichtung. Damit wurde dann nach dem Schwenk bei der SSL-Validierung ein sattes A+ statt des vorherigen A erreicht.

Da wir die Domainverwaltung zu uns geholt hatten, konnten wir die Zonendaten, genauer gesagt, die Adress-Records nach unseren Zielen vorbereiten. Die sogenannte TTL (Time to live) wurde zeitweise auf den kleinstmöglichen Wert gesetzt: 3 Minuten. Dies war also die geplante maximale Übergangszeit für den eigentlichen Schwenk.

Der Schwenk

Den Schwenk setzten wir auf einen Zeitpunkt, der für diesen Shop optimal war. Und dann ging alles ganz schnell: wir änderten die IP-Adresse für den Shop , starteten zusätzlich unseren Master-DNS sowie den ersten von vier Slaves neu. Das war dank Virtualisierung in jeweils knapp fünf Sekunden erledigt. Gleichzeitig beobachteten wir über ein externes DNS-Monitoring, dass sich innerhalb von weniger als 15 Sekunden beinah alle 50 Mess-Stationen die neue IP-Adresse gezogen hatten. Damit war auch der IP-Umzug erledigt.

Zur Sicherheit schalteten wir auf dem alten Server den http-Dienst ab, damit nicht versehentlich jemand im alten Shop eine Bestellung absetzen konnte. Im Logfile des neuen Servers sahen wir nach weniger als einer Minute die ersten Shop-Abfragen und dann auch die ersten Bestellungen.

Der Feinschliff

Während der letzten 14 Tage vor dem anstehenden Schwenk erfassten wir die relevanten Leistungsdaten mit unserem Monitoring-System. Und dann kam die Überraschung: Direkt nach dem Schwenk konnte eine deutliche Geschwindigkeits-Steigerung festgestellt werden. Der Kunde bestätigte die guten Messwerte unseres Monitorings.

Das Resultat

Nach den ersten 60 Tagen inclusive Weihnachtsgeschäft konnten wir ein klares Resumée ziehen:

  • Der eigentliche Schwenk, der Umzug des kompletten laufenden Shop-Systems erfolgte wie gewünscht problemfrei. Dabei war der gesamte Vorgang war für den Kunden transparent.
  • Der Betrieb war nach dem Umzug deutlich stabiler, es gab keinerlei Schwankungen oder Aussetzer mehr.
  • Durch die laufenden Messwerte unseres Monitorings konnten wir die wirklich benötigten Ressourcen eindeutig quantifizieren.

Die Vorteile der passgenauen Serverkonfiguration

Unsere Langzeitbeobachtung ergab, dass real 8 bis 12 GB RAM und vier schnelle vCPU-Kerne mit 2.4 GHz Taktfrequenz benötigt wurden. Die oben bereits beschriebenen Unterschiede zwischen alt und neu waren wohl ausschlaggebend. Und im Vergleich „billig gegen günstig“ gewann „günstig“. Zum Ergebnis beigetragen haben aber auch der bessere Webserver und die Konfiguration von Hand.

Der neue Kunde ist glücklich. Was will man mehr?

Der Kunde bekam mit dem ActiveBackup der BB-ONE.net zusätzlich eine gehörige Portion Betriebssicherheit. So können zukünftige Software- und Betriebssystem-Updates gefahrlos und ohne Stress getestet und dann auch im Live-Betrieb umgesetzt werden. Das sorgt für einen sicheren Shop-Betrieb. Unterstützt wurden wir durch eine befreundete Agentur, die sich auf Shopware spezialisiert hat.

Daran sehen Sie, was wir unter Managed Hosting verstehen: Als erfahrene Spezialisten sorgen wir dafür, dass Sie sich um IHR Geschäft kümmern können.