Best Practice: Update Warenwirtschaftssystem

Best Practice und How To Update Warenwirtschaftssystem

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:

  1. Datensicherung des „alten“ Servers
  2. Sicherung/Export der kompletten Datenbank
  3. Einrichten des neuen Servers mit der aktuellen Fakturierungs-Software
  4. Einspielen/Import der Datenbank in das neue System
  5. 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.

Der Server wurde also noch einmal aufgesetzt, die Software eingerichtet und die Datenbank importiert. Es stellte sich heraus, dass für Windows 300 GB, die Software 500 GB, für die Datenbank beim Importieren 500 GB ausreichen waren. Damit hatten wir für den Server 1,5 TB statt 3 TB in Gebrauch.

Dies Resultat wurde nun wiederum kopiert und als Backup für Notfälle vorgehalten.

Das Resultat

Insgesamt wurden für den gesamten Prozess vier Arbeitstage benötigt. Obwohl es, speziell beim Importieren der Datenbank zu deutlichen Verzögerungen kam, kann man abschliessend sagen:

  • Projekt gelungen
  • Erfahrungen gemacht
  • Werkzeugauswahl war richtig

Projekt gelungen?

Die Fakturierungssoftware war aktualisiert, neue gewünschte Funktionen wurden hinzugefügt, ohne Datenverlust zu riskieren. Damit betrachten wir das Projekt „Update Warenwirtschaft“ zunächst einmal als gelungen.

Erfahrungen gemacht?

Das Verhalten der Fakturierung entsprach an einigen Stellen nicht der Dokumentation und Angaben des Herstellers. Dies betraf sowohl den eigentlichen Installationsprozess (z.B. Speicherbedarf beim Datenbankimport, Unmöglichkeit des Imports von einem Netzlaufwerk, einige Ungereimtheiten beim Zusammenspiel mit dem Betriebssystem und zusätzlichen Treibern) als auch versteckte Funktionsänderungen (z.B. Mailversand der Rechnungen angeblich nur noch über Outlook?!!!).

Die Vorgehensweise, viele Systeme zu virtualisieren, hat sich auch hierbei wieder bestätigt. Die weiteren Erfahrungen dokumentierten wir mit dem gesamten Prozess inklusive aller Probleme und deren Lösungen im internen Wiki. Dadurch hoffen wir das Thema „Update Warenwirtschaft“ in Zukunft schneller durchziehen zu können.

Werkzeugauswahl?

Wie bereits mehrfach angedeutet, laufen sowohl der Server als auch die Arbeitsplatz-Clients als virtuelle Windows Maschinen mit dem Hypervisor VMware vCenter. Denn es ist ein stabiles, flexibles und auch betriebswirtschaftlich akzeptables System. Auf die drei Client-VMs wird per RDP mit Netzwerk-Authentifizierung zugegriffen. Dadurch ergaben und ergeben sich sowohl für den Update-Prozess als auch für den laufenden Betrieb mehrere Möglichkeiten:

1. VMware als Zeitersparnis und Arbeitserleichterung

Durch das Anlegen von Komplett-Kopien sowohl der Clients als auch des Servers konnten wir unnötigen Stress vermeiden bzw. Zeit einsparen. Die Alternative wäre das Anlegen von Snapshots gewesen. Diese Vorgehensweise ist jedoch weder vergleichbar sicher noch vergleichbar flexibel. Das von uns verwendete Werkzeug ist der „VMware vCenter Converter Standalone Client“. Er ist ursprünglich dazu gedacht, einen physischen Rechner in eine VM zu konvertieren. Es ist jedoch auch möglich, eine vollständige Kopie einer Windows-VM im laufenden Betrieb anzulegen, dies sogar auf einem anderen Host in einem anderen Netzwerk. Diese Kopie hat üblicherweise identische Eigenschaften wie das Original. Allerdings kann man verschiedene Eigenschaften wie Speicher oder RAM während des Konvertierens beeinflussen.

2. Mehrstufiges Datensicherungskonzept

Da die BB-ONE.net den Großteil der Rechnungen zum Monatswechsel erzeugt, ist folgende Vorgehensweise sinnvoll für die Datensicherungsprozedur:

  1. Vor dem Rechnungslauf, also kurz vor Monatsende werden die drei Clients und der Server mit dem oben beschriebenen Tool „VMware vCenter Converter Standalone Client“ auf einen zweiten Hypervisor-Host kopiert. Damit ist gewährleistet, dass regelmässig eine funktionsfähige Kopie der vier VMs vorhanden ist, die in sehr kurzer Zeit (ca. 5 Minuten) einsatzbereit ist.
  2. Die Fakturierung verfügt über eine automatische Datenbank-Sicherungsroutine, welche die Datenbank regelmässig (täglich, sieben Generationen) auf ein Netzlaufwerk sichert.
    Die Sicherung erfolgt auf einer getrennten VM, in der ein Linux-System mit einem SAMBA-Server läuft. Diese VM wird täglich auf getrennte Hardware gesichert (3 Generationen: Mo/Mi/Fr bzw. Di/Do/Sa, sowie So). Täglich wird dieser Datenbestand per Rsync mit einem identischen virtuellen Server in unserem Datacenter abgeglichen.
    Zusätzlich wird am Monatswechsel eine Vollkopie auf eine dritte Hardware an einem dritten Ort gezogen, die nur dann am Netz ist.
    Als Hypervisor für die Linux-bezogenen Virtuellen Maschinen dient bei BB-ONE.net OpenVZ.

3. Großzügige Dimensionierung der Ressourcen

Dimensionierung ist stets ein wichtiges Kriterium für den sicheren Betrieb von beliebiger IT. Grundsätzlich verhält sich nämlich jede Hardware unnormal, wenn sie über eine bestimmte Grenze hinaus belastet wird. Router und Switche beispielsweise erzeugen dann Paketverluste.

Für den Speicherplatz eine optimale Dimensionierung zu definieren, ist deutlich schwieriger. Denn hier kommen neben persönlichen Erfahrungswerten auch unterschiedliche Vorgehensweisen zum Tragen. Bei der BB-ONE.net arbeiten wir stets mit dem dreifachen Speicherbedarf gegenüber der ersten Planung.
Das ermöglicht uns, schnell und flexibel auf temporäre Speicherbedürfnisse zu reagieren.

Fazit

Halten wir fest: Wir konnten zwar der Prozess „Update des Warenwirtschaftssystems“ abschließen, aber den Ärger mit der schlechten und Praxis-fremden Dokumentation und dem wenig hilfreichen Support hätten wir uns gerne erspart. Auch die Tatsache, dass sich der Hersteller mehrfach quasi als Wiederverkäufer von Microsoft hervor tat, kam bei uns nicht positiv an. Wir können durchaus hinnehmen, dass die Software nur für Windows verfügbar ist. Inakzeptabel ist jedoch, dass der Hersteller der Warenwirtschaft immer wieder auf die Verwendung von Microsoft-Softwares in der Systemumgebung bestand. Das ist in der heutigen Zeit weder softwaretechnisch sinnvoll noch kundenfreundlich.

Unsere Arbeitsauffassung ist hier entgegengesetzt und eindeutig: Die Wahl der Umgebungssoftware sollte für den Kunden offen sein. Und wenn man keine saubere Dokumentation vorweisen lann, dann sollte der Support sich wenigstens im seinem System auskennen. Aber wir haben nicht zuletzt deshalb aus unserem Projekt „Update Warenwirtschaftssystem“ wieder viel gelernt. Und wir fühlen uns bestätigt. Wir bleiben bei unserer Philosophie, nach Möglichkeit mit Open Source Software zu arbeiten und unseren Kunden bei Technikproblemen immer aktiv zur Seite zu stehen.