Wenn in einer Wirtschaftskanzlei die historische Text- und Projekt-Datenbank, die bislang in einer einzigen riesigen Datei untergebracht war, nicht mehr ausreicht, ist eine gründliche Veränderung - ein Umstieg - angesagt. Abhilfe schafft eine Datenbank auf der Basis einer SQL-Engine auf einem Netzwerk- Server mit speziellen vorgeschalteten lokalen Client- Programmen.

Bekannte kostengünstige oder gar freie SQL-Engines sind zum Beispiel "mysql" und "mariadb", wie sie in unseren über 50.000 Museenseiten hervorragend funktionieren. Andere Software-Ersteller präferieren oracle oder Informix oder die "MS-SQL" Engine von Microsoft - anfänglich in der kostenlosen Express Variante.

Nach unseren langjährigen Erfahrungen mit open source Software wird daher jetzt ein virtualisierter Linux-Server mit sowohl einer Linunx-VM als auch einer Win 10 VM installiert, um fundierte Informationen über die Installation, die Ablaufgeschwindigkeit, die Stabilität und den Komfort zu erhalten - und die Sicherheit nicht zu vergessen.
.

Ein Datenbankserver muß mindestens 1 Jahr in irgendeinem Server-Rack problemlos unbaufsichtigt laufen. Wird vom Softwarehaus bislang nur die MS-SQL Datenbank angeboten, die aber sowohl für Linux (Suse) als auch für Windows 10 verfügbar ist, starten wir mit der Linux Variante, lassen uns aber die WIN10 Variante offen. Dazu wird ein Hardware- Server (unser Esprimo E900) mit RAID1 gespiegelten SSD-Platten aufgesetzt und es werden diese 2 virtuellen Maschinen installiert. Wie das geht, steht auf der vorherigen Seite.
.
Hier nocheinmal rudimentär zusammengefaßt :

1. Steht der Server ohne Virtualisierung im EDV-Raum oder im Büro oder sonstwo, müsste der Admin bei jedem Problem direkt an die Tastatur der Hardware ran, das ist mühsam und nicht mehr zeitgemäß
2. Ist z.B. die WIN 10 Installation abgestürzt, geht keine Fernseelsorge mehr. Der Admin muss jetzt auch an die Tastatur ..... also müsste ein Windows Server 2022 her. Der erfordert noch mehr Lern-Aufwand incl. der geschwätzigen Abhängigkeit von MS-Gnaden.
3. Bei den virtualisierten Servern bleibt nach meiner Erfahrung das Linux- Grundsystem (die DOM-0) immer stabil verfügbar, das ist eminent wichtig, da kommt von draußen keiner dran.
4. Und was MS-SQL angeht, gibt es einige Schwächen laut der Foren, darum wollen wir beide Express-Varianten selbst testen, die varianten für opensuse Linux und WIN10.
5. Der von mir präferierte virtualisierte Server muß in der Lage sein, mindestens 1 Jahr ohne Admin auszukommen, täglich ausgeschaltet zu werden und am nächsten Morgen wieder hoch gefahren zu werden - ein stabiles und problemloses WakeOnLan ist zwingende Voraussetzung.
6. Die beiden virtuellen Maschinen müssen ohne Nachhilfe mit dem Grundsystem automatisch starten und die dort integrierten Dienste - also die MS-SQL Engine - muß dann ebenfalls in beiden VMs gestartet sein.
7. Der SQL-Client im Home-Office kennt daher nur die aktielle IPV4 Nummer des Ziel-Routers und den (bei uns abweichenden) Weiterleitungs-Port auf die SQL Engine und natürlich das MS-SQL Engine Passwort.
8. Der Router bekommt also zwei unterschiedliche Port-Weiterleitungen bei geicher IPV4 Nummer eingetragen, die auf jeweils eine der beiden VM1 und VM2 und den dort wartenden MS-SQL Server verweist.
9. Alles muß absolut logisch und dokumentiert sein, damit es nach Jahren immer wieder zeitnah nachvollzogen und repariert werden kann.

.

Ist der Server einmal erfolgreich eingerichtet und die SQL-Engines sind startklar installiert, braucht an diesen Server keiner mehr ran. Die SQL Engines laufen als Dienste im Hintergrund der Betriebssysteme .... und weiter wird dort nichts angefaßt. Hier prüft und konfiguriert nur der Admin.

Also weder auf dem Grundsystem (der DOM-0) sowie auf den beiden VMs (VM1 und VM2) werden irgendwelche Anwenderprogramme ausgeführt. Alleine die Werkzeuge zur Wartung sollen verfügbar sein.

Deshalb brauchen weder der Server noch eine der VMs einen Remote-Zugang von Ausserhalb. Auch werden auf den VMs keine SQL-Clients installiert. Alleine der Netzwerk-Port des jeweiligen SQL-Servers ist von ausserhalb ansprechbar.
.

Die Ports zum Administrieren sowohl des Linux-Grundsystems (der DOM-0 mit Port 22 und 80 und 443) sowie aller VMs sind in der Firewall geblockt bzw. in ganz andere Regionen verlegt.
.
Der SQL Port akzeptiert nur den passwortgeschützten Datenverkehr mit seinem passenden SQL-Client. Auch dieser Port ist in andere Regionen verlegt, sodaß es Gauner und Ganoven etwas schwerer haben werden.
.

Da jeder PC und damit auch jeder Server ein BIOS zum Booten haben muß, damit er überhaupt sein Betriebssystem startet, ist auch hier bereits ein Blick wichtig. Alle moderneren "Basic Input Output Systeme" lassen die Verbindung zu den Festplatten - den SATA Mode - von "IDE" auf "AHCI" einstellen. Zusätzlich wollen wir später unter Linux 2 solcher SSDs spiegeln. Das ist erprobt und sehr schnell.
.
Dennoch stolpert der Admin beim Installieren über so viele Kleinigkeiten, die das Leben schwer machen.

Zum Beispiel startet die VM1 (Linux mit Ext4)) auf einmal nicht mehr normal, sondern im Rescue-Modus, ein Filesystem Error sei aufgetreten. Es hatte doch 5 Male einwandfrei geklappt. Man solle "fdisk" laufen lassen. Doch im Rescue-Modus gibt es kein fdisk. Und warum dieser Fehler auf einmal auftrat, ist auch nicht herauszufunden.

Das mit dem reparieren mit fdisk wiederum geht bei der inzwischen wieder abgeschalteten VM1 aus der DOM-0 heraus. Und so reiht sich eine Kleinigkeit an die andere.

.

Bei der ach so einfachen Installation sind fast schon zu viele merkwürdige Fehler aufgetreten.

Zum Verständnis der Vorbereitung der Festplatten :

Die DOM-0 (unser Grundsystem) bekommt immer 3 Subpartitionen :

│ └─md0         9:0    0    30G  0 raid1
│   ├─md0p1   259:0    0   512M  0 part  /boot/efi
│   ├─md0p2   259:1    0     2G  0 part  [SWAP]
│   └─md0p3   259:2    0  27.3G  0 part  /

die VM1 (Linux) bekommt gezielt händisch 4 Subpartitionen :

│ └─md126       9:126  0    80G  0 raid1
│   ├─md126p1 259:5    0     8M  0 part
│   ├─md126p2 259:6    0     2G  0 part
│   ├─md126p3 259:7    0    30G  0 part
│   └─md126p4 259:8    0    48G  0 part

und die VM2 (Win 10) bekommt automatisch 2 Subpartitionen :

  └─md127       9:127  0 113.6G  0 raid1
    ├─md127p1 259:11   0   500M  0 part
    └─md127p2 259:12   0 113.1G  0 part

.

Und wenn Sie glauben, die beiden VMs laufen endlich (Sie machen mit der DOM-0 einfach einen Kaltstart - KEIN soft-reboot), startet die VM1 (Linux) auf einmal mit Win 10 und endet in einer Reparaturschleife, auf ewig ......

und die VM2 (Win10) startet mit Opensues Linux. Zuerst sind Sie nur verblüfft und glauben das alles nicht mehr.

Da auch die Namen/Typen der Partitionen nicht mehr aussagefähig sind, prüfen Sie hilfsweise die Anzahl der Sub-Partitionen der VM1 und der VM2, ob das noch passt und kommen so dem Fehler auf die Schliche.

Offensichtlich hat in der DOM-0 nach einem Kaltstart etwas nicht geklappt, es muß ein Bug sein. Da wir in unserem anderen Muster-Server nur Linux VMs haben, scheint es nicht aufzufallen.

Auch das muß man erstmal wissen. Im Virt-Manger auf der DOM-0 sind bei uns die Kopfzeilen der VMs sauber beschrieben, außer, ich habe mich spät Nachts vertippt.

DateninhalteNach genauerer Recherche kann man das ändern. Man löscht in den beiden VM-Konfiguration die aktuelle virtuelle SSD-Partition einfach weg, ohne die zu löschen. Dann legt man in der "richtien" VM die "richtige" Partition als neue virtuelle Platte an und auf einal startet sowohl die Linux VM mit Linux und die Windows VM mit WIN10. Diese Nacht war also auch rum.
.

Damit dieser Server vorest transportabel ist, werden alle Netwzerke auf DHCP eingestellt. Damit sind die DOM-0 und die beiden VMs über die neuen DHCP-IP Nummern auch in einem neuen EDV-Umgebung sofort sichtbar (geprüft mit dem "angryIPscanner")

Bei der DOM-(Linux) klappt das, bei der VM2 (WIN 10) klappt das auch, bei der VM1 (Linux) bekommt diese VM keine IP Nummer. Nach der Umstellung auf eine feste IP samt Gateway funktioniert alles wie gewohnt, bei der Zurückstellung auf DHCP klappt es nicht mehr. Es hatte aber mal geklappt. Der DHCP Client der VM1 ist nicht mehr da. Auf die idee kommen sie so schnell nicht. Und wieder mit Umstellung auf eine feste IP ist der DHCP Client dann nachinstalliert, er funktioniert aber immer noch nicht ....... ein Rätsel. Wenn soetwas in der DOM-0 passiert, dann installieren Sie besser nochmal von vorne.
.