ESXi 6.0 zu Proxmox Migration - Setup und Hardwarefragen

[BeMei]

Hallo zusammen,

ich muss unsere IT die nächsten Jahre noch ein wenig am Leben erhalten. Aktuell habe ich zwei HP Server DL 308 G6 (8x 300 GB SAS mit RAID Controller) und DL 385 G7 (8 x 500 GB ebenfalls mit RAID Controller) unter ESXi 6.0 am Laufen. Es sind jeweils zwei Platten im Raid gespiegelt wegen Ausfallsicherheit. Im Laufe der letzten Jahre musste ich auch durchaus die eine oder andere Platte tauschen.

Auf dem G7 ist ein Exchange Server 2016 unter Windows Server 2016 und ein Fileserver Windows Server 2019 als VM installiert,
auf dem G6 ein Terminalserver 2016 und einige Windows 10 VM, Dazu läuft auf jedem Host noch ein Domaincontroller.

Weder Terminalserver noch Exchange Server haben in Zukunft noch User die sie brauchen werden weil die Leute nicht mehr da sind,

Die Idee ist es eine vorhandene Workstation mit 2x Xeon Gold Prozessoren und 256 GB RAM mit Proxmox aufzusetzen. Dazu stehen 2 Seagate 8TB Ironwolf Platten zur Verfügung und zwei SSD mit 2 TB die als 24x7 gelabelt sind. Die Workstation hat keinen RAID Controller.

Ich hatte die Überlegung die beiden 8TB HDD mit ZFS aufzusetzen und alle VM da drauf zu packen. Es ist nicht mit viel Traffic zu rechnen ausser den notwendigen Backups.
Den Exchange Server würde ich gerne durch Gromox/Grommunio ersetzen und sobald das erledigt ist auch die Domänencontroller einmotten.

Meine Fragen:

Wäre es sinnvoll da ich ja kein Hardware RAID habe bei den Ironwolf Platten ZFS einzusetzen? Ich denke RAM wäre wohl genug da, oder?

Was ist mit dem System: Ich habe des öfteren gelesen das ZFS die SSD kaputt macht. Ist das aktuell so richtig? Gäbe es eine andere Möglichkeit ohne einen Hardware Raid Controller zu nehmen? Vielleicht LVM als Spiegel?

Habt ihr vielleicht Tips für ein anderes Setup?

 

[waltar]

(Wenn kein hw-raid vorhanden wie hier) Installier pve mit zfs mirror auf die 2x8TB hdd und anschliessend mach noch ein zfs mirror aus den 2x2TB ssd's für deine VM's. 256GB Ram ist gut. Die pve db kann somit die ssd's nicht "verbrauchen" und den hdd's macht das nicht soviel aus, zudem kannst du intern nochmal die VM's vom ssd mirror auf den hdd mirror spiegeln.

 

[Falk R.]

Hallo zusammen,

ich muss unsere IT die nächsten Jahre noch ein wenig am Leben erhalten. Aktuell habe ich zwei HP Server DL 308 G6 (8x 300 GB SAS mit RAID Controller) und DL 385 G7 (8 x 500 GB ebenfalls mit RAID Controller) unter ESXi 6.0 am Laufen. Es sind jeweils zwei Platten im Raid gespiegelt wegen Ausfallsicherheit. Im Laufe der letzten Jahre musste ich auch durchaus die eine oder andere Platte tauschen.

Auf dem G7 ist ein Exchange Server 2016 unter Windows Server 2016 und ein Fileserver Windows Server 2019 als VM installiert,
auf dem G6 ein Terminalserver 2016 und einige Windows 10 VM, Dazu läuft auf jedem Host noch ein Domaincontroller.

Weder Terminalserver noch Exchange Server haben in Zukunft noch User die sie brauchen werden weil die Leute nicht mehr da sind,

Die Idee ist es eine vorhandene Workstation mit 2x Xeon Gold Prozessoren und 256 GB RAM mit Proxmox aufzusetzen. Dazu stehen 2 Seagate 8TB Ironwolf Platten zur Verfügung und zwei SSD mit 2 TB die als 24x7 gelabelt sind. Die Workstation hat keinen RAID Controller.

Ein 24/7 Label ist mehr Marketing als ein echter technischer Unterschied.

Ich hatte die Überlegung die beiden 8TB HDD mit ZFS aufzusetzen und alle VM da drauf zu packen. Es ist nicht mit viel Traffic zu rechnen ausser den notwendigen Backups.

Da die HDDs langsam drehende Disks (7k) sind wird das mit ZFS recht langsam werden. Die alten 300G Disks sind 10k SAS welche deutlich schneller sind.

Den Exchange Server würde ich gerne durch Gromox/Grommunio ersetzen und sobald das erledigt ist auch die Domänencontroller einmotten.

Meine Fragen:

Wäre es sinnvoll da ich ja kein Hardware RAID habe bei den Ironwolf Platten ZFS einzusetzen? Ich denke RAM wäre wohl genug da, oder?

Was ist mit dem System: Ich habe des öfteren gelesen das ZFS die SSD kaputt macht. Ist das aktuell so richtig? Gäbe es eine andere Möglichkeit ohne einen Hardware Raid Controller zu nehmen? Vielleicht LVM als Spiegel?

Du kannst ein md Raid bauen oder wenn du das OS da drauf installieren willst kannst du im Installer auch BTRFS Raid1 nehmen.

Da du eh nicht viele VMs hast könnte das schon funktionieren. Je nachdem was für Anschlüsse in der Workstation vorhanden sind, eventuell noch zwei gebrauchte Enterprise SSDs dazu kaufen. Damit könntest du die HDDs deutlich beschleunigen, wenn du Special Device (Metadaten) und Cache von den SSDs zur Verfügung stellst.

 

[Johannes S]

Wäre es sinnvoll da ich ja kein Hardware RAID habe bei den Ironwolf Platten ZFS einzusetzen? Ich denke RAM wäre wohl genug da, oder?

Ja, der RAM sollte ausreichen. Problematisch könnte höchstens die Performance sein, weil HDD natürlich nicht so schnell wie SSD sind.
Daher würde es sich in meinen Augen anbieten die SSDs so zu partitionieren, dass auf eine relativ kleinen Teil davon nur das Betriebssystem kommt und dann den Rest für die VMs zu nutzen. Die HDDs dann als Datengräber für die Anwendungen. Wie groß sind denn aktuell deine VMs und Daten?

Was ist mit dem System: Ich habe des öfteren gelesen das ZFS die SSD kaputt macht. Ist das aktuell so richtig? Gäbe es eine andere Möglichkeit ohne einen Hardware Raid Controller zu nehmen? Vielleicht LVM als Spiegel?

Naja, sowohl Proxmox selbst als auch ZFS haben eine höhere Schreiblast als ein normales Linux oder andere Dateisysteme. Bei Proxmox kommt das durch die Systemlogs und die Cluster-Funktionalitäten, bei ZFS durch dessen zusätzliche Features und Datensicherheit.

Das Problem betrifft dabei vor allen typische Consumer-Hardware, bei Festplatten mit Powerlossprotection (PLP) sollte das Problem nicht auftreten.

Generell wird empfohlen die Systeme mit Enterprise-SSDs oder Enterprise-NVMEs zu betreiben. NAS-Festplatten sind das im Regelfall nicht, das ist einfach Marketing (da da immer noch Sachen wie PLP fehlen).

Ein Kompromiss könnte sein, dass man ein Setup mit special devices macht: Dabei erzeugt man mit ZFS ein virtuelles Device, dass aus der HDD für die Daten und der SSD (bzw. einer Partition darauf) für die Metadaten und kleinen Dateien besteht. Die Performance wird damit natürlich nicht so gut sein, wie wenn man völlig auf SSD gesetzt hätte, aber immerhin besser als mit einer reinen HDD. Achtung: Geht das special device kaputt/verloren, sind alle Daten weg! Darum sollte man so ein Setup immer als Mirror aufbauen (also mindestens zwei HDDs für die Daten und zwei SSDs als specialdevice, die sich spiegeln). Und natürlich ist RAID kein Ersatz für ein Backup. Wie macht ihr die Backups gerade?
Hast du vielleicht eine konkrete Seriennummer/Device ID für deine Festplatten? Dann kann eher gesagt werden, ob sich das eignet oder nicht.

Außerdem: Habt ihr vor, die alten Server dann wegzuschmeißen und nur noch mit dem neuen Proxmox-Server zu arbeiten? Kapazitätsmäßig sollte das ja passen, aber trotzdem wäre es ja ärgerlich bei einen Fehler des Servers dann "nackt" dazustehen. Habt ihr euch dazu schon Gedanken gemacht? Prinzipiell kann man einen Proxmox-Cluster auch mit zwei Knoten aufbauen, man sollte dann aber noch ein drittes Gerät (wofür ein Raspberry oder alter Desktop-PC reicht) als quroum-device hinzufügen (da sonst bei einen Ausfall der Cluster mangels Stimmenmehrheit einen um die Ohren fliegt). Mit ZFS können diese beiden Knoten dann sich gegenseitig ihre VMS replizieren, sodass dann beim Ausfall eines Knotens der andere übernehmen kann. Siehe: https://pve.proxmox.com/wiki/Cluster_Manager und https://pve.proxmox.com/wiki/Storage_Replication
Standardmäßig werden die Daten dann alle 15 Minuten repliziert, das kann auf bis zu eine Minute reduziert werden (daraus ergibt sich dann auch der schlimmstmögliche Datenverlust im Fehlerfall).

 

[BeMei]

Wie groß sind denn aktuell deine VMs und Daten?

Exchange und Fileserver haben etwa 450 GB, die VM jeweils etwa 80-120 GB und die DC denke ich sind mit 100GB zugeteilt, brauchen aber nicht soviel. Der Terminalserver ist unter 300 GB mit allem.

Ein Kompromiss könnte sein, dass man ein Setup mit special devices macht: Dabei erzeugt man mit ZFS ein virtuelles Device, dass aus der HDD für die Daten und der SSD (bzw. einer Partition darauf) für die Metadaten und kleinen Dateien besteht. Die Performance wird damit natürlich nicht so gut sein, wie wenn man völlig auf SSD gesetzt hätte, aber immerhin besser als mit einer reinen HDD. Achtung: Geht das special device kaputt/verloren, sind alle Daten weg! Darum sollte man so ein Setup immer als Mirror aufbauen (also mindestens zwei HDDs für die Daten und zwei SSDs als specialdevice, die sich spiegeln). Und natürlich ist RAID kein Ersatz für ein Backup. Wie macht ihr die Backups gerade?

Fileserver, Terminalserver und VM werden regelmässig von der Nakivo Backup Software auf unser Synology NAS gesichert. Exchange und DC mittels Windows Backup. Ebenso Fileserver und Terminalserver noch mal zusätzlich per Windows Backup, ist aber eigentlich doppelt gemoppelt.

Hast du vielleicht eine konkrete Seriennummer/Device ID für deine Festplatten? Dann kann eher gesagt werden, ob sich das eignet oder nicht.

Ich schaue mal und reiche das nach.

Außerdem: Habt ihr vor, die alten Server dann wegzuschmeißen und nur noch mit dem neuen Proxmox-Server zu arbeiten?

Ja, das ist der Plan, die beiden alten Server machen einen Höllenlärm und ich würde gerne etwas mehr Ruhe haben

Kapazitätsmäßig sollte das ja passen, aber trotzdem wäre es ja ärgerlich bei einen Fehler des Servers dann "nackt" dazustehen. Habt ihr euch dazu schon Gedanken gemacht?

Ja, ich habe noch eine weitere kleiner Workstation da die aushelfen könnte. Aber sie ist eigentlich als Workstation gedacht.

Prinzipiell kann man einen Proxmox-Cluster auch mit zwei Knoten aufbauen, man sollte dann aber noch ein drittes Gerät (wofür ein Raspberry oder alter Desktop-PC reicht) als quroum-device hinzufügen (da sonst bei einen Ausfall der Cluster mangels Stimmenmehrheit einen um die Ohren fliegt). Mit ZFS können diese beiden Knoten dann sich gegenseitig ihre VMS replizieren, sodass dann beim Ausfall eines Knotens der andere übernehmen kann. Siehe: https://pve.proxmox.com/wiki/Cluster_Manager und https://pve.proxmox.com/wiki/Storage_Replication
Standardmäßig werden die Daten dann alle 15 Minuten repliziert, das kann auf bis zu eine Minute reduziert werden (daraus ergibt sich dann auch der schlimmstmögliche Datenverlust im Fehlerfall).

Ich fürchte das wäre schon zu komplex für mich.

 

[Falk R.]

Also wenn du es auch leise haben möchtest, da gibt es auch extra leise Server von einigen Herstellern. Kommt natürlich auch darauf an ob du etwas Budget dafür hast.

 

[BeMei]

(Wenn kein hw-raid vorhanden wie hier) Installier pve mit zfs mirror auf die 2x8TB hdd und anschliessend mach noch ein zfs mirror aus den 2x2TB ssd's für deine VM's. 256GB Ram ist gut. Die pve db kann somit die ssd's nicht "verbrauchen" und den hdd's macht das nicht soviel aus, zudem kannst du intern nochmal die VM's vom ssd mirror auf den hdd mirror spiegeln.

Das ist genau umgedreht wie ich mir das ursprünglich gedacht hatte aber dann gehen die SSD nicht so schnell kaputt hoffe ich. Danke für den Tip!

Ich habe derzeit eine Testinstallation auf der Workstation um mit Proxmox warm zu werden und ein wenig zu üben.
Mein Versuch ist es die ganze Sache möglichst einfach zu halten. Das Backup würde ich gerne weiter mit Nakivo machen.

@Falk R.
Das Budget ist quasi nicht existent. Ich muss quasi mit den Bordmitteln in alter MacGyver Manier was basteln

@Johannes S

Hast du vielleicht eine konkrete Seriennummer/Device ID für deine Festplatten? Dann kann eher gesagt werden, ob sich das eignet oder nicht.

Ich schaue und reiche die nach.

 

[ivenae]

Hätte ich nicht so gemacht.

Ich würde VMs ausschließlich auf SSDs installieren, weil niemand will mit Schnarchnasen VMs auf klassischen Festplatten noch arbeiten. (Ich lache immer über die Spinner, die heute noch 7.000 € Server mit teurem RAID Controller und klassischen SAS Platten machen. An den Kunden verdient man dann besonders gut.)
Die Menge an geschriebener Daten eines Proxmox mit ZFS sind höher als erwartet, aber nicht so hoch, dass gute SSDs das nicht innerhalb der üblichen Lebenszyklen von 5 - 6 Jahren locker wegschaffen würden.
Mein Heim-Server schreibt ca. 1 TB / Monat. Bei einer 2 TB SSD ist das ein halber Zyklus. Wenn die SSD 72 Monate halten soll, hat sie 36 Zyklen am Ende ihrer Lebensdauer.
Selbst billigster QLC (den man NICHT für ZFS nimmt!) schafft 400 Zyklen, TLC schafft eher 4.000 Zyklen.
TLC vorausgesetzt, ist Faktor 100 mehr ggü. meinem Heimserver immer noch OK.

HDDs würde ich gar nicht mehr nutzen. Wenn es nicht anders geht, weil du den Speicher benötigst, binde virtuelle Festplatten als Laufwerk D: in die VM und lege sie auf dem Pool ab, der auf den HDDs liegt. Ansonsten mach auf die Dinger eher ein nächtliches Backup der SSDs.

 

[ivenae]

Noch eine Sache zum Reserveserver: Ich lebe ohne Reserveserver beim Kunden ganz gut. Im Zweifel hab ich als Dienstleister Hardware hier, womit ich zumindest einen Notbehelf generieren kann, d.h. einen Server, der zumindest die VMs mit reduziertem RAM und schmaler CPU oder unter Einbau (einer) der alten Festplatten schonmal booten kann.

Im optimalen Fall fällt der Server während der 5 Jahre Nutzung natürlich nicht aus, oder wird zwar in einem Notfalltermin getauscht, aber gleich mit neuer, ausreichend flotter Hardware.

Dank nächtlicher Backups ist das i.d.R. in einem halben Tag ohne großen Datenverlust oder ganz ohne Datenverlust gemacht, je nachdem was kaputt ist (beide Platten sind ja doch eher unwahrscheinlich).

Gegenfrage: Wenn der neue Server jetzt 5 Jahre hält und dann spontan verreckt: Würdest du ernsthaft deine Zeit verschwenden, die 10 Jahre alte Hardware als Notbehelf nochmal anzuschließen? Ich würde lieber schnell einen neuen Rechner kaufen, wenn ich keinen auf Lager hätte. Und wenn es im Mediamarkt ist. Ich meine: Das ist Linux mit RAID-Mirror. Wenn eine Platte kaputt geht, läuft der weiter. Wenn der Rechner kaputt geht, baust du zumindest eine SSD einfach in einen beliebigen anderen Rechner. Das wird booten. Da findet sich doch was unter Kollegen, was man bis zum Eintreffen der neuen Hardware nutzen kann, ohne jetzt Elektroschrott aufzubewahren, oder nicht?

 

[cwt]

Wie @Falk R. schon schrieb: gebrauchte Enterprise SSDs für einen schmalen Taler wären empfehlenswert. Da reichen auch kleine Modelle, vielleicht 100-120€ Kosten. Diese könntest Du als ZFS-Mirror für PVE nehmen, die beiden anderen für VMs. Ggf. die HDDs noch als wenig frequentiertes Datengrab.
Und die alten HP in die Ecke stellen und in ein paar Jahren als Reserve ausbuddeln würde ich nicht machen. Alte Hardware, die nicht unter Strom steht, macht beim Wiederanfahren nach langer Zeit gerne die Grätsche. Dann sind Bauteile ggf. endgültig ausgetrocknet und es macht pöff.

 

[Falk R.]

Hätte ich nicht so gemacht.

Ich würde VMs ausschließlich auf SSDs installieren, weil niemand will mit Schnarchnasen VMs auf klassischen Festplatten noch arbeiten. (Ich lache immer über die Spinner, die heute noch 7.000 € Server mit teurem RAID Controller und klassischen SAS Platten machen. An den Kunden verdient man dann besonders gut.)
Die Menge an geschriebener Daten eines Proxmox mit ZFS sind höher als erwartet, aber nicht so hoch, dass gute SSDs das nicht innerhalb der üblichen Lebenszyklen von 5 - 6 Jahren locker wegschaffen würden.
Mein Heim-Server schreibt ca. 1 TB / Monat. Bei einer 2 TB SSD ist das ein halber Zyklus. Wenn die SSD 72 Monate halten soll, hat sie 36 Zyklen am Ende ihrer Lebensdauer.
Selbst billigster QLC (den man NICHT für ZFS nimmt!) schafft 400 Zyklen, TLC schafft eher 4.000 Zyklen.
TLC vorausgesetzt, ist Faktor 100 mehr ggü. meinem Heimserver immer noch OK.

HDDs würde ich gar nicht mehr nutzen. Wenn es nicht anders geht, weil du den Speicher benötigst, binde virtuelle Festplatten als Laufwerk D: in die VM und lege sie auf dem Pool ab, der auf den HDDs liegt. Ansonsten mach auf die Dinger eher ein nächtliches Backup der SSDs.

Da hast du aber die Rechnung ohne den Cache Algorithmus des SSD Herstellers gemacht. Die TB Written welche vom Hersteller angegeben werden sind reiner TLC/QLC Traffic. Damit die Schreibraten nicht unter HDD Niveau fallen, werden die Zellen wie SLC beschrieben, als Cache. Dann wird umkopiert. Bei einer TLC SSD hast du somit für 1 MB schnelles schreiben, erst 3 MB Zellen mit nur SLC Daten beschrieben und dann wird das umkopiert und du hast nachher 4 MB Verschleiß für den 1 MB Write.
Wie viel gecached werden muss ist schwer vorherzusagen, aber bei QLC ist es deutlich mehr.
Deshalb sterben die QLC so extrem schnell, wenn VMs drauf sind.

 

[Johannes S]

Exchange und Fileserver haben etwa 450 GB, die VM jeweils etwa 80-120 GB und die DC denke ich sind mit 100GB zugeteilt, brauchen aber nicht soviel. Der Terminalserver ist unter 300 GB mit allem.

Ok, mir ging es um die Gesamtgröße, wenn du unter 2 TB bleibst, könntest du (wie ja auch von Waltar vorgeschlagen) die SSD für die VMs nutzen, was mit deutlich besserer Performance verbunden wäre. Oder wie von Falk voregeschlagen dir dafür Enterprise-SSDs zulegen, entweder als Datenspeicher für die VMs statt der HDDs oder um die HDDs mit einen ZFS special device zu beschleunigen.

Fileserver, Terminalserver und VM werden regelmässig von der Nakivo Backup Software auf unser Synology NAS gesichert. Exchange und DC mittels Windows Backup. Ebenso Fileserver und Terminalserver noch mal zusätzlich per Windows Backup, ist aber eigentlich doppelt gemoppelt.

Ich schaue mal und reiche das nach.

Das ist schon mal gut, mir geht es darum, wie man im Fehlerfall möglichst schnell die Systeme wieder ans laufen kriegt. Da ja eurer Budget zunächst keinen Reserveserver hergibt und dafür im Notfall die zweite Workstation für herhalten müsste, würde ich mir Gedanken machen, wie man die Systeme schnell wieder ans Laufen kriegt. Daher halte ich es für sinnvoll zusätzlich die VMS über die proxmox-eigene Backup-Funktion auf der NAS zu sichern. Dann muss man nicht erst Windows neu installieren, sondern kann erst die VM wiederherstellen und danach dann mit Nakivo und Windows-Backup die Daten. Noch besser wäre natürlich ein Proxmox-Backup-Server, kann eure Synology selbst VMS laufen lassen oder wird das bei ihr nicht unterstützt? Falls es möglich ist, würde ich da eine PBS-VM laufen lassen und das als Backup der VMs nutzen (eben um im Bedarfsfall schnell wieder die VMs laufen zu kriegen, nachdem Proxmox VE auf der Reserveworkstation installiert wurde). Ansonsten könnte man auch noch einen alten Büro-PC dafür nehmen, sofern man da mindestens zwei SSDs für ein RAID eingebaut kriegt. Wenn du dafür keine Extrahardware hast und/oder mit der Synology auskommen willst oder musst, kannst du natürlich auch direkt via nfs oder cifs auf die NAS sichern, die Backups werden dann allerdings mehr Platz fressen, muss man halt öfter aufräumen.

Ja, das ist der Plan, die beiden alten Server machen einen Höllenlärm und ich würde gerne etwas mehr Ruhe haben

Nachvollziehbar, hast du dein Büro direkt in euren Serverschrank? Ansonsten stimmt es natürlich, was zur Sinnhaftigkeit der alten Hardware als Reserve geschrieben wurde.

Ich fürchte das wäre schon zu komplex für mich.

Ich fürchte eher, dass ich mich zu kompliziert ausgedrückt habe und eurer Budget das aktuell nicht hergibt

Grundsätzlich ist die Einrichtung des eigentlichen Clusters über die GUI relativ straightforward, das qdevice (und wie gesagt das kann auch ein Raspberry, alter DesktopPC o.ä. sein) muss halt einmalig auf der Konsole eingerichtet werden, aber das ist in der Doku eigentlich ziemlich gut erklärt.

Der Vorteil ist nun folgender: Wenn man die VMS vom Hauptserver auf den anderen replizieren lässt (was proxmox, sobald man das einmal eingerichtet hat, dann automatisch für eine nerledigt) , kann man im Fall eines Ausfalls direkt die VMs auf den zweiten Host weiterlaufen lassen, wenn man Hochverfügbarkeit (was allerdings das qdevice voraussetzt) eingerichtet hat, auch völlig automatisch. Das ist nicht nur bei Ausfällen aufgrund von Hardwaredefekten o.ä. praktisch, sondern auch für Wartungen: Wenn du z.B. eine Festplatte beim Hauptserver tauschen möchtest, packst du den Hauptknoten in den Wartungsmodus, darauf werden die VMs dann zum Reserveknoten migriert und laufen dort (ggf. mit reduzierzter Performance) weiter, ohne dass der Betrieb für die User groß unterbrochen wurde. Bei Wartungen geht das natürlich dann auch ohne Datenverlust (die wurden ja vor der Downtime noch auf den Reserveknoten migriert), bei einen Ausfall des Hauptknotens halt mit einen Verlust von einigen Minuten. Ich finde das eine sehr praktische Funktion, damit der Betrieb weiterläuft, falls mal der Hauptserver ausfällt oder man ihn warten muss und dafür abschalten muss.
Wenn du dir das so nicht zutraust, würde sich anbieten, dass du dir in deinen alten Exsi-Servern bzw. den neuen Proxmox-Server erstmal zwei Proxmox-VMs plus eine Debian- oder PBS-VM fürs qdevice klickst und dir da versuchsweise einen Cluster zusammenbaust. Sofern deine Hardware nested Virtualisierung unterstützt, könntest du in diesen VMs in der VM auch deine Windows-VMs laufen lassen. Falls das nicht geht (oder aus Lizens- oder Performancegründen nicht sinnvoll ist), richtest du dir halt einige Linux-VMs oder Container ein und stellst damit dann die Ausfall-/Wartungsszenarien nach. Um das Grundprinzip zu verstehen, sollte das ausreichen.

Momentan (so habe ich dich verstanden) habt ihr ja eh kein Geld für mehr Hardware, bzw. solltest du das (da kann ich mich den Vorrednern nur anschließen) eher in Enterprise-SSDs investieren. Aber für die nächsten Jahre würde ich mir an eurer Stelle vornehmen, dafür Geld einzuplanen, der entsprechende Reserveserver muss ja auch nicht unbedingt die gleiche Power wie der Hauptserver haben, solange die VMs nur überhaupt laufen (sofern die dann eingeschränkte Performance für euch tragbar ist). Wie lange könnt und wollt ihr ohne eure IT-Infrastruktur auskommen?

 

[ivenae]

Da hast du aber die Rechnung ohne den Cache Algorithmus des SSD Herstellers gemacht. Die TB Written welche vom Hersteller angegeben werden sind reiner TLC/QLC Traffic. Damit die Schreibraten nicht unter HDD Niveau fallen, werden die Zellen wie SLC beschrieben, als Cache. Dann wird umkopiert. Bei einer TLC SSD hast du somit für 1 MB schnelles schreiben, erst 3 MB Zellen mit nur SLC Daten beschrieben und dann wird das umkopiert und du hast nachher 4 MB Verschleiß für den 1 MB Write.
Wie viel gecached werden muss ist schwer vorherzusagen, aber bei QLC ist es deutlich mehr.
Deshalb sterben die QLC so extrem schnell, wenn VMs drauf sind.

Danke für deine Anmerkung.
Ich lese die Informationen mit smartctl direkt von der Platte. Ich gehe daher davon aus, dass das in der Statistik schon berücksichtigt ist. Würde dann allerdings auch erklären, warum der Wert so hoch ist.

Für mich klingt das übrigens eher danach, als ob das Geld nie wieder da ist. Da werden wohl nur gesetzliche Aufbewahrungspflichten erfüllt, die Firma ist dicht und wird kein Geld mehr erwirtschaften.

 

[BeMei]

Ich habe eben mal die Seriennummer von einer SSD ausgelesen: BC640732095301278674 white label, es sollen Kingston chips verbaut sein, 2TB. Ich habe aber nichts darüber gefunden ob es TLC, MLC oder QLC ist.

@ivenae
Deine Vermutung trifft fast zu. Tatsächlich muss ich Aufbewahrungspflichten beachten und Kunden noch Daten zur Verfügung stellen können. Nebenbei produziere ich noch moderat.

Ich brauche daher kein Hochverfügbarkeitssystem und habe auch kein Problem wenn es mal ein, zwei Tage nicht läuft, etwas schieben kann man immer. Aber ich will mir das ganz grosse Update Kino ersparen und gerne auf OpenSource und Community gehen.
Die Alternative wäre es einen Hyper-V Server 2019 aufzusetzen...

 

[BeMei]

Wie kann ich denn für die Seriennummer feststellen was das für eine SSD ist?
Ich habe mal hdparm -I /dev/sdc für die Festplatte ausgeführt aber da ist nichts aussagekärftiges bei rausgekommen.

Wäre eine Samsung PM983 eine Alternative?

 

[Falk R.]

Wie kann ich denn für die Seriennummer feststellen was das für eine SSD ist?
Ich habe mal hdparm -I /dev/sdc für die Festplatte ausgeführt aber da ist nichts aussagekärftiges bei rausgekommen.

Wäre eine Samsung PM983 eine Alternative?

Bei dem hdparm sollte dir eine Zeile model numberangezeigt werden.

 

[BeMei]

Ich habe das Ergebnis aus hdparm -I /dev/sdc hier eingefügt falls es noch einmal jemand in anderem Kontext benötigt:

/dev/sdc:

ATA device, with non-removable media
        Model Number:       SATA SSD                               
        Serial Number:      BC640732095301278674
        Firmware Revision:  SHFM60.0
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Used: unknown (minor revision code 0x005e)
        Supported: 11 10 9 8 7 6 5
        Likely used: 11
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:  4000797360
        Logical  Sector size:                   512 bytes
        Physical Sector size:                   512 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:     1953514 MBytes
        device size with M = 1000*1000:     2048408 MBytes (2048 GB)
        cache/buffer size  = unknown
        Form Factor: 2.5 inch
        Nominal Media Rotation Rate: Solid State Device
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Advanced power management level: 254
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    DOWNLOAD_MICROCODE
           *    Advanced Power Management feature set
                SET_MAX security extension
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Gen3 signaling speed (6.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Phy event counters
           *    Device automatic Partial to Slumber transitions
           *    READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
           *    DMA Setup Auto-Activate optimization
                Device-initiated interface power management
           *    Software settings preservation
           *    DOWNLOAD MICROCODE DMA command
           *    SET MAX SETPASSWORD/UNLOCK DMA commands
           *    WRITE BUFFER DMA command
           *    READ BUFFER DMA command
           *    DEVICE CONFIGURATION SET/IDENTIFY DMA commands
           *    Data Set Management TRIM supported (limit 4 blocks)
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
                frozen
        not     expired: security count
                supported: enhanced erase
        20min for SECURITY ERASE UNIT. 60min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 0000000000000000
        NAA             : 0
        IEEE OUI        : 000000
        Unique ID       : 000000000

@Falk R. Ich finde da drin nichts was aussagekräftig wäre. Vielleicht kannst Du was erkennen.

 

[Falk R.]

Das ist eine NoName SSD, welche gern von Intenso oder anderen kleinen Anbietern verkauft werden. Gute Qualität ist da Glückssache und Specs bekommst du nur wenn du weißt, wo die gekauft wurde.
Vermutlich ist das eine Silicon Power TLC.

 

[BeMei]

Ok, wäre eine Samsung PM983 eine Alternative?

 

[Falk R.]

Ok, wäre eine Samsung PM983 eine Alternative?

Ja klar, die PM Reihe ist Enterprise und bisher noch nie Probleme mit denen gehabt.