JTL-Wawi in der Cloud: Warum die Datenbank allein es nicht macht
Der häufigste Umzug ins Rechenzentrum ist der, bei dem nur die Datenbank umzieht. Genau der geht am häufigsten schief.
Die Frage kommt fast immer in derselben Form: „Kann man die Wawi nicht in die Cloud legen?” Gemeint ist damit selten dasselbe. Für die einen heißt es, dass der Server nicht mehr im Büro stehen soll. Für die anderen, dass man von zu Hause arbeiten will. Für wieder andere, dass sich jemand anders kümmern soll.
Das sind drei verschiedene Projekte. Und der Weg, der auf dem Papier am naheliegendsten aussieht — nur die Datenbank umziehen, der Client bleibt, wo er ist — ist der, der am häufigsten enttäuscht.
Warum die Wawi über eine Internetleitung zäh wird
JTL-Wawi ist eine klassische Client-Server-Anwendung. Der Client auf dem Arbeitsplatz enthält die Programmlogik, die Daten liegen in einer Microsoft-SQL-Server-Datenbank. Das Entscheidende dabei: Der Client ist gesprächig. Eine einzige Maske, ein Auftrag, eine Artikelsuche lösen nicht eine Abfrage aus, sondern viele.
Im lokalen Netz spielt das keine Rolle. Eine Abfrage über ein Gigabit-Netz ist in einem Bruchteil einer Millisekunde beantwortet, das merkt niemand. Über eine Internetstrecke zu einem Rechenzentrum liegt die Laufzeit je nach Anbindung bei 10 bis 30 Millisekunden — pro Abfrage.
Rechnen Sie das einmal durch: Bei einer Maske, die im Hintergrund zweihundert Abfragen absetzt, sind das im lokalen Netz Millisekunden und über die Fernstrecke mehrere Sekunden. Und zwar bei jedem Klick.
Das ist der Punkt, an dem Kunden mir sagen, der Server sei zu langsam. Ist er meistens nicht. Die CPU langweilt sich, der Speicher ist halb leer. Was langsam ist, ist der Weg dorthin — und daran ändert auch eine schnellere Leitung wenig, denn das Problem ist nicht die Bandbreite, sondern die Laufzeit. Eine dickere Leitung transportiert mehr gleichzeitig, aber nicht schneller.
Die drei Bauformen, und wann welche passt
Alles im Haus. Server im Büro, Clients im selben Netz. Schnell, günstig in der Anschaffung, und die gesamte Verantwortung für Strom, Klima, Hardware und Sicherung liegt bei Ihnen. Für einen Standort mit festen Arbeitsplätzen völlig in Ordnung.
Alles im Rechenzentrum. Datenbank und Arbeitsumgebung liegen dort, die Mitarbeiter verbinden sich per Remotedesktop. Der Client läuft damit direkt neben der Datenbank, die Gesprächigkeit fällt nicht ins Gewicht. Über die Leitung geht nur noch Bildschirminhalt, und der ist erstaunlich genügsam. Das ist der Weg, der „von überall arbeiten” tatsächlich einlöst.
Nur die Datenbank im Rechenzentrum. Genau die Variante aus der Überschrift. Sie hat einen schmalen sinnvollen Anwendungsfall — etwa, wenn der Client selbst auf einem Server im selben Rechenzentrum läuft und nur die Datenhaltung getrennt werden soll. Als Lösung für „mein Server soll weg, meine PCs bleiben” ist sie fast immer die falsche.
Die Frage lautet also nicht „Cloud oder nicht”, sondern: Wo steht der Client im Verhältnis zur Datenbank? Die beiden gehören ins selbe Netz. Alles andere ist eine Entscheidung gegen die Geschwindigkeit.
Was die Datenbank tatsächlich braucht
Wenn die Bauform steht, wird die Hardwarefrage überraschend einfach.
Arbeitsspeicher vor allem anderen. Der SQL Server nutzt freien Speicher als Cache. Passt die Datenbank hinein, kommen Abfragen aus dem Speicher; passt sie nicht, wird von der Platte gelesen. Der Unterschied ist keine Feinheit, sondern eine Größenordnung. Als Faustregel: genug Speicher, dass die Datenbank vollständig hineinpasst, plus Reserve für das Betriebssystem. Und unbedingt ein Maximum für den SQL Server konfigurieren — sonst nimmt er sich alles, und dem System bleibt nichts.
NVMe statt SATA-SSD. Bei Auswertungen und beim Neuaufbau von Indizes merkt man den Unterschied deutlich. Bei normaler Auftragsarbeit weniger.
Die richtige SQL-Server-Edition. Express ist kostenlos und deshalb verbreitet, hat aber zwei harte Grenzen: 10 GB pro Datenbank und rund 1,4 GB Cache. Die 10 GB sind der Punkt, an dem es irgendwann knallt — die Wawi nimmt dann schlicht keine Daten mehr an. Der kleine Cache dagegen bremst schon lange vorher, ohne dass eine Fehlermeldung erscheint. Wer ernsthaft damit arbeitet, plant Standard ein.
Ordentliche Wartung. Eine Datenbank, an der nie ein Indexpflege- oder Statistiklauf stattfindet, wird über Jahre langsamer, ohne dass sich sonst etwas ändert. Das ist kein Wawi-Thema, sondern ein SQL-Server-Thema, wird aber gern übersehen, weil es nirgends blinkt.
Der Worker ist kein Nebenschauplatz
Der JTL-Worker synchronisiert Shop und Marktplätze, verarbeitet Aufträge, aktualisiert Bestände. Er ist der Teil, der laufen muss, wenn niemand am Rechner sitzt — und genau deshalb hat er nichts auf einem Arbeitsplatz-PC verloren, der abends heruntergefahren wird.
Er gehört auf die Serverseite und dort als Windows-Dienst eingerichtet, nicht als Programm in einer angemeldeten Sitzung. Der Unterschied zeigt sich an dem Tag, an dem sich jemand per Remotedesktop anmeldet, seine Arbeit erledigt und sich sauber abmeldet: Ein Programm in dieser Sitzung endet mit ihr. Ein Dienst läuft weiter.
Zum Dienstbetrieb gehören zwei Dinge, an denen es in der Praxis regelmäßig hakt: Der Dienst braucht ein Konto mit den passenden Rechten, und er startet erst sinnvoll, wenn der SQL Server bereit ist. Wird die Startreihenfolge nicht abgebildet, läuft er beim Server-Neustart ins Leere und beendet sich — mit einer Meldung, die einem nicht verrät, dass es nur eine Frage von zwanzig Sekunden war. Wie sich das äußert, habe ich in einem eigenen Beitrag beschrieben.
Zwei Punkte, die keine Leistungsfrage sind
Der Datenbankport gehört nicht ins offene Internet. Ein SQL Server, der auf Port 1433 für alle erreichbar ist, wird gefunden — nicht vielleicht, sondern zuverlässig, und zwar von automatisierten Scannern innerhalb von Tagen. Zugriff nur über VPN oder eine enge Freigabe auf bekannte Adressen. Das ist kein Sonderwunsch für Sicherheitsbewusste, sondern Grundausstattung.
Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Ein Abbild der virtuellen Maschine ist keine Datenbanksicherung, und eine Datenbanksicherung, die noch nie einen Rückweg gesehen hat, ist ein Ordner mit Dateien. Der Ernstfall ist der falsche Zeitpunkt, um herauszufinden, wie lange ein Restore dauert. Auch dazu gibt es einen eigenen Beitrag.
Kurz gefasst
„JTL-Wawi in die Cloud” ist keine Produktentscheidung, sondern eine Frage der Anordnung. Client und Datenbank gehören zusammen — stehen sie auseinander, hilft keine Hardware. Steht beides zusammen im Rechenzentrum, ist der Rest Handwerk: genug Speicher, die passende SQL-Server-Edition, der Worker als Dienst, der Datenbankport zu und eine Sicherung, die schon einmal zurückgespielt wurde.
Wenn Sie unsicher sind, in welche der drei Bauformen Ihr Betrieb gehört: Die Antwort hängt seltener an der Größe des Sortiments als daran, von wo aus gearbeitet werden soll. Das lässt sich in zwanzig Minuten klären.
Häufige Fragen
Kann man einfach nur die JTL-Wawi-Datenbank in ein Rechenzentrum legen?
Technisch ja, praktisch selten sinnvoll. Der Wawi-Client spricht sehr häufig mit der Datenbank — eine einzige Maske löst oft dutzende Abfragen aus. Solange Client und Datenbank im selben lokalen Netz stehen, fällt das nicht auf. Liegt die Datenbank hinter einer Internetleitung, addiert sich jede einzelne Abfrage um die Laufzeit der Strecke, und die Wawi fühlt sich zäh an, obwohl der Server Langeweile hat.
Was ist der Unterschied zwischen SQL Server Express und Standard bei JTL-Wawi?
Express ist kostenlos, aber gedeckelt: 10 GB je Datenbank und rund 1,4 GB Arbeitsspeicher für den Cache. Für kleine Bestände reicht das. Wächst die Datenbank darüber hinaus, nimmt Express keine Daten mehr an — und weil der Cache so klein ist, wird vorher schon jede größere Auswertung von der Platte gelesen statt aus dem Speicher. Standard hebt beide Grenzen auf und ist bei ernsthaftem Betrieb der übliche Weg.
Wohin gehört der JTL-Worker beim Hosting?
Auf dieselbe Seite wie die Datenbank, nicht auf den Arbeitsplatz. Der Worker holt Aufträge, synchronisiert Shop und Marktplätze und muss laufen, wenn niemand im Büro ist. Er gehört als Windows-Dienst eingerichtet, nicht als Programm in einer angemeldeten Sitzung — sonst endet er mit dem Abmelden des Nutzers.
Wie viel Arbeitsspeicher braucht ein JTL-Wawi-Server?
Der SQL Server nimmt sich so viel, wie man ihm erlaubt, und nutzt ihn als Cache. Als Anhaltspunkt: Die Datenbank sollte möglichst vollständig in den Speicher passen. Bei einer 20-GB-Datenbank sind 32 GB im Server eine vernünftige Untergrenze, bei mehreren Mandanten entsprechend mehr. Wichtig ist außerdem, dem SQL Server ein Maximum zu setzen, damit dem Betriebssystem etwas übrig bleibt.
