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.
