Manchmal ist die Praxis der beste Lehrmeister, vor allem wenn es einen selbst betrifft. So geschehen bei unserem hauseigenen Projekt mit dem Namen „Update Warenwirtschaftssystem“. So mussten wir trotz stabilen Betriebes wegen der vielen Änderungen bei Microsoft Windows auf die neue Software-Version umsteigen. Und da wir bei dem Update dieses kaufmännisch wichtigen Systems naturgemäß Unterbrechungen oder Störungen unbedingt vermeiden wollten, mussten wir einiges beachten. Daraus wurde dann ein „How to“-Lehrstück, welches Ihnen (hoffentlich) hilft, Updates trotz Widrigkeiten ebenfalls erfolgreich vorzubereiten und durchzuführen.
Der Sachverhalt
Die Debitoren-Buchhaltung der BB-ONE.net wird seit vielen Jahren mit einer Software erledigt, deren Hersteller quasi der Markführer für Warenwirtschafts- und Buchhaltungssysteme ist. Dem Ruf des Platzhirschen entsprechend sind Funktionalität des Systems und der Hersteller-Support aufgestellt. Aus einer gewissen Arroganz heraus schlichen sich im Laufe der Jahre dann immer wieder richtige Software-Fehler und funktionelle Macken ein. Diese führten in unserem Fall dazu, dass wir die für uns lebenswichtige Software nicht mehr korrekt updaten konnten. Wir wollten daher wieder einen sauberen, aktuellen Zustand herstellen, um eine sichere Funktion zu gewährleisten. Deshalb beschlossen wir den kompletten Neuaufsatz der Warenwirtschaft. Natürlich wollten wir diesen parallel zum Tagesbetrieb durchführen. Dabei ergaben sich naturgemäß einige zu erwartende Herausforderungen, aber auch diverse unangenehme Überraschungen.
Projekt „Update Warenwirtschaftssystem“? Ein guter Plan.
Unter normalen Umständen hätten wir folgende Vorgehensweise beim Update des Warenwirtschaftssystems gewählt und durchgezogen:
- Datensicherung des „alten“ Servers
- Sicherung/Export der kompletten Datenbank
- Einrichten des neuen Servers mit der aktuellen Fakturierungs-Software
- Einspielen/Import der Datenbank in das neue System
- notwendige weitere Anpassungen und Erweiterungen auf dem neuen System
Die Datenbank des alten Systems liess sich jedoch nicht in das neue System importieren. Also musste die alte Software temporär neu installiert werden. Als Zielserver wählten wir eine virtuelle Maschine (VM) in der gleichen Grössenordnung des alten Servers: Systemplatte 300 GB/250 GB frei, Platte für de Software 500 GB/450 GB frei). Die exportierte Datenbank mit ca. 75 GB Grösse als ZIP-Archiv wollten wir von einem gemappten Netzwerklaufwerk importieren. Der Plan war also, mit diesem System dann die Software auf aktuellen Stand zu bringen.
Überraschung!
Als ärgerlich erwies sich nun, dass der Import der Datenbank nicht von einem Netzwerklaufwerk, sondern nur von einem lokalen Laufwerk aus möglich war. In der Software-Dokumentation und anderen Quellen des Herstellers fanden wir darüber nichts. Und eine entsprechende Fehlermeldung kam erst nach ca. zwei Stunden.
Da es sich um eine VM (virtuelle Maschine) handelte, konnten wir kurzfristig eine weitere virtuelle Festplatte (200 GB) einrichten und einbinden. Die nächste Fehlermeldung kam jetzt noch später, nämlich nach ca. drei Stunden: nicht genügend Plattenspeicher. Leider fehlte der Hinweis, welches Laufwerk hier zu klein war. Denn rein rechnerisch waren alle drei Laufwerke groß genug. Um weitere Versuchsreihen abzukürzen, erweiterten wir die Kapazität der drei Laufwerke auf jeweils 1000 GB. Dank Virtualisierung stellte das kein Problem dar. Denn die genutzte Hardware, also der Host ist, unserer Philosophie entsprechend, derart überdimensioniert, dass wir „mal eben“ aus dem Vollen schöpfen konnten.
Auf dieser Basis wurde dann über Nacht der Datenbankimport fehlerfrei durchgeführt. Die Datenbankgröße reduzierte sich durch eine spezielle Software vom Hersteller deutlich auf nur noch knapp 15 GB.
Zwischentest
Nachdem allerlei Tests bestätigen konnten, dass die Datenbank und die Software einwandfrei arbeiteten, machten wir uns an die Einrichtung der drei Arbeitsplatz-Clients als VM. Um Arbeitszeit zu sparen, dazu ist Virtualisierung schließlich gut, kopierten wir den ersten Client zweimal. Dass dies gegenüber dem kompletten Neuaufsatz wesentlich schneller geht, zeigen die Zahlen: Die Einrichtung der ersten VM dauerte insgesamt 1,5 Arbeitstage, das Kopieren ging dann in knapp drei Stunden vor sich.
Damit hatten wir ein funktionierendes System mit vier Rechnern: einer VM mit Windows 2012 als Server, drei VM mit Windows 10 als Arbeitsplatz-Clients. Die beiden Originale ( 1 Server, 1 Client) wurden zunächst wiederum kopiert und auf einem getrennten Host gesichert.
Neue Herausforderung
Nun kam der Wunsch auf, die Speicherkapazität des Servers von den zwischenzeitlich 3 TB wieder auf eine vernünftige Grösse zu bringen. Die drei Laufwerke C,D,E liessen sich zwar aus Windowssicht verkleinern. Jedoch erwies es sich als unmöglich, die drei nicht zusammenhängenden Speicherbereiche „Systemplatte“, „Softwareplatte“ und „Datenbankspeicher“ wieder frei zu geben. Die verschiedenen empfohlenen Ansätze vom Herstellersupport führten sogar dazu, dass Windows nicht mehr stabil lief. Ob dies auf einen Fehler oder auf die Unmöglichkeit zurückzuführen war, liess sich unter Zeitdruck nicht mehr feststellen.
Abhilfe schafften wir dann durch das Hochfahren der vorher erzeugten Backup-Kopie der VM. Da trotzdem noch der Wunsch nach Verringerung der Speicherkapazität bestand, musste also noch einmal eine Schleife eingelegt werden.
