Windows Fileserver - Pro / Contra für 2 Partitionen - System+FileServer

[XamBonX]

Ich suche gerade nach den Pro / Contras für folgenden Fall:

• Nutanix für VM Verwaltung
• VM mit Windows 2019
• 4 TB Volumen für diese VM aus einem gemeinsamen Volumen für alle VMs
• 1 vDisk 100GB, C:
• 1 vDisk rest, D:

Gesichert wird mit Veeam und Bandlaufwerken.

Man könnte das auch nur auf C: machen mit einem Ordner: FileServer und halt dort alles. Nun suche ich nach Pro / Contra 1 vs. 2 vDisks bei dieser Konstellation mit VM und Volumen aus der SAN. Macht nicht viel Sinn irgendwie 2 vDisks zu haben. Aber lass mal hören.

 

[tollertyp]

Ich persönlich würde Windows gar nicht auf die gleiche HDD/SSD legen, weil wenn der Speicher nicht reicht und die 4 TB durch 8 TB ersetzt werden sollen, spart man sich massig Aufwand.

Faustregel bei mir: Windows immer maximal von den persönlichen Daten trennen.

 

[cloudman]

Ich würde auch empfehlen für das OS eine seperate SSD zu verwenden. SATA reicht dafür
Kostet doch kaum etwas.
Vorteil ist, dass man die Datenträger einfach wechseln kann wenn einer zu klein wird oder einen Defekt hat.
Ergänzung
Übrigens ist Server 2022 released worden

 

[KillerCow]

Betriebssystem auf eine eigene Platte, für den produktiveren Einsatz ist das gerne ein Raid1. Datenhalde auf separate Platten.
Falls du nur eine Platte hast/willst, dann wenigstens auf eigene Partitionen legen, damit deine Datenhalde dir nicht das Windows "vollmüllt".

Das ist zumindest meine Denke... vielleicht gibts da schon neuere/sinnvollere Erkenntnisse. Lasse mich gerne aufschlauen

 

[XamBonX]

Ahjo...vergessen...das ganze ist eine VM, nicht ein eigener Rechner. Hab den Eröffnungsbeitrag geändert.

 

[cloudman]

Ist doch egal - dann würde ich erst recht nicht mit Partitionen hantieren sondern gleich 2 vdisks anlegen

 

[tollertyp]

Und gerade bei einer VM geht das ja noch einfacher mit der Trennung...

 

[t-6]

Dito; pro Volume eine vDisk statt separater Partition. Da gibt es kein "Contra".

Dann noch: Falls es sich bei der Virtualisierung um VMWare handelt: Nicht direkt mit 4TB VMDKs einsteigen. Lieber erst mal nur so groß wie nötig. Vergrößern kann man immer noch. Verkleinern hingegen ist nicht so einfach. Falls du also im Nachhinein feststellst dass du den ganzen Speicher doch nicht brauchst bzw. woanders besser gebrauchen kannst, wirds erst mal etwas eklig.
(von fixed vDisks ausgehend)

btw:

• 4 TB Volumen aus der SAN

Wie ist das zu verstehen? Ich hoffe nicht dass damit gemeint ist innerhalb der VM eine iSCSI-Verbindung zum SAN herzustellen.

 

[dauerbrutzler]

Und wenns absehbar windowsbasierend bleibt, stülp DFS drüber. Macht erweitern, verschieben, migrieren im Nachgang wesentlich entspannter und für den Anwender komplett transparent.

 

[XamBonX]

Leute, sagt mir auch WARUM ihr das so machen würdet. Ich mach dies oder das, aber kaum einer sagt mir hier WARUM.

Ich hab's jetzt konkretisiert und den 1. Post editiert: nicht 2 Partitionen, mein Fehler. Sondern 2 vDisks, eine C: und eine D: .

 

[KillerCow]

Leute, sagt mir auch WARUM ihr das so machen würdet.

Gründe für die saubere Trennung von OS und Daten wurden genannt. Für DFS wurden auch Gründe genannt. Für das "fang nicht direkt mit ner 4TB VMDK" an auch... Was fehlt dir jetzt genau?

 

[XamBonX]

Dito; pro Volume eine vDisk statt separater Partition. Da gibt es kein "Contra".

Weil?

Dann noch: Falls es sich bei der Virtualisierung um VMWare handelt: Nicht direkt mit 4TB VMDKs einsteigen. Lieber erst mal nur so groß wie nötig. Vergrößern kann man immer noch. Verkleinern hingegen ist nicht so einfach.

Ja, doch muss. Sind schon 3,6 TB belegt. Sonst geh ich den dynamischen Weg.

 

[tollertyp]

Ich dachte wir haben die Gründe genannt?

 

[dauerbrutzler]

Warum? Miesen Patch erwischt, OS tot. Template kopiert, konfiguriert und Data Volume angehangen, 5 Minuten. Deshalb z.B.
DFS? Neuer Cluster, neue SAN. Migration während normaler Arbeitszeit schön im Hintergrund, irgendwann Priorität geswitched, altes Zeug ausgeknippst, keiner hat's gemerkt.
Deshalb?

 

[XamBonX]

Warum? Miesen Patch erwischt, OS tot. Template kopiert, konfiguriert und Data Volume angehangen, 5 Minuten. Deshalb z.B.

Vor dem Patch: Snapshot. Nach dem Patch: Ins Nutanix einloggen, Snapshot wiederherstellen, weiter geht's in 5 min.

 

[t-6]

Weil?

Weil einzelne vDisks pro Partition/Volume flexibler sein.
Beispiel: Eine vDisk, 500 GB groß. C: ist 100 GB groß. D: ist 400 GB groß.
Jetzt stellt sich raus dass die 100 GB für C: aus irgendeinem Grund doch nicht ausreichen.
Bei einer separaten vDisk kannst du die einfach erweitern (bei Hyper-V & VMware in laufendem Betrieb möglich).
Bei einer gemeinsamen vDisk hingegen darfst du jetzt ein Tool hernehmen um die Partitionen offline umzukonfigurieren.

Andersherum, am Beispiel von Hyper-V:
Es stellt sich raus dass 100 GB für C: doch zu groß waren. 50 GB würden auch ausreichen.
Also C: in Windows auf 50 GB verkleinern.
Anschließend die VHDX bearbeiten --> komprimieren. Und schon sind auf dem Datastore wieder 50 GB frei zur freien Verwendung für andere VMs.
Bei einer geteilten Partition hättest du jetzt 50 GB "toten" Speicher zwischen C: & D: den du ohne Partitionierungssoftware nicht wieder raus bekommst.

Ja, doch muss. Sind schon 3,6 TB belegt. Sonst geh ich den dynamischen Weg.

Ja gut, dann würd ich auch direkt mit 4 TB anfangen.
Dynamisch würde ich im KMU-Bereich eher nicht empfehlen. Zu schnell verliert man den Überblick über dien zugeteilten Speicherplatz. Ein Robocopy eines Fileserver und zack ist das SAN voll und alle VMs halten an.
Immer statisch/fix´; da weiß man was man (verbraucht) hat.

Und noch mal die Frage: Hast du vor innerhalb der VM eine iSCSI-Verbindung o.Ä. zum SAN herzustellen, nur für den "Daten"-Datenträger des Fileserver?

 

[dauerbrutzler]

Meister - mir ist das völlig egal. Du hast gefragt und den Best-Practice Ansatz bekommen. Und wenns nur der unbedarfte mal schnell klick klick Kollege war oder man dem Filer ein Inplace spendieren möchte. Mittlerweile hab ich recht viel gesehen. Mach wie du meinst. Soll übrigens auch schon Snapshots gegeben haben, die den Gast bügeln. Oder der Fileserver muss eben noch einen für einen weiteren Dienst herhalten, weil wegen "müssen sparen, gibt nicht mehr Hosts und oder etc. pp" und der wars im Betrieb. Besser haben und nicht brauchen, als andersherum. Und wenn du dann mal eben schnell schnell 4T+ umkopierst oder vom Backup ziehst, dass dann vielleicht sogar durch ein fertiges LTO Band glänzt... auch ok für mich ^^ In dem Sinne Grüße von einer Scalar, der es bei so einer Aktion das ganze Laufwerk gerissen hat. Warum man sich gegen zusätzliche easypeasy Sicherheitsmaßnahmen wehren möchte, geschenkt. Happy Wartungswochende Wünsche ich

 

[snaxilian]

Vor dem Patch: Snapshot. Nach dem Patch: Ins Nutanix einloggen, Snapshot wiederherstellen, weiter geht's in 5 min.

Betrifft nur den Fall, dass du einen potentiellen Fehler sofort merkst. Wenn längere Zeit dazwischen liegt brauchst nur die vDisk mit dem OS zurück spielen aus dem Backup aber die vDisk mit den Daten und damit auch die zwischenzeitlich gemachten Änderungen an Daten, bleiben erhalten.
Der Grundsatz "Trennung von Anwendung und Nutzdaten" hat sich nicht grundlos durchgesetzt und ein OS ist nur ein notwendiges Mittel zum Zweck damit $Anwendung läuft. Ansonsten würde ich es auch hinter einem DFS verstecken, das erleichtert die Migration in Zukunft enorm und macht es stressfreier, vor allem für den Admin.

 

[nosti]

Wenn dir die Kollegen die restlichen 400GB "mal eben" vollknallen, verabschiedet sich dein OS, sobald es keine Daten mehr schreiben kann. Wenn die Daten auf einer separaten Partition liegen, läuft das Basissystem einfach weiter.
Zusätzlich können Schreib/Leseoperationen auf verschiedenen (v)Disks verteilt werden, so kenne ich es auch von Datenbankservern.
Die zusätzliche Platte kannst du bei Bedarf auch in einen neuen Server einhängen und spart dir ein Inplace Upgrade. Selbst ein OS-Wechsel ist theoretisch möglich.

Was noch interessant ist sind IOPS Limits/Quotas/sHARES für einzelne vDisks.