Defragmentierung sinnvoll bei RAID Controllern (Windows Server NTFS)?? Und wie ist das bei virtuellen Maschinen? (WinServer unter VMWare)
Ist es sinnvoll an RAID Controllern angeschlossene Festplatten zu defragmentieren? Selbst wenn der RAID Controller viel Cache hätte, könnte ja trotzdem unmöglich alle Daten in einem Stream vorhalten. Zudem muss ja physisch immer noch die Platte mechanische Arbeit leisten um alle Fragmente zu lesen oder zu schreiben. Oder sehe ich das falsch? Es gibt ja Server, da ist die Fragmentierung ganz erheblich (DATEV, SFIRM Sicherungen mit 300000 kleinen Dateien usw.). Primär Windows Server.
Wie sieht das aus, wenn der (Windows) Server eine VM maschine ist? Die VMWare Maschine besteht dann ja aus einer Datei, aber innerhalb des WinServers sieht der ja die Fragmentierung dieser Datei. Es wird in meinem Umfeld kontrovers diskutiert, ob man hier innerhalb des virt. Servers defragmentieren soll.
Es ist in beiden Fällen klar, dass dies nur bei Serverwartungen außerhalb der Betriebszeiten der User bei Bedarf durchgeführt wird. Also bestenfalls ein paar Mal im Jahr und nur bei Notwendigkeit, die Platten werden also nicht durch geplante Defragtasks beansprucht.
Danke schon mal für Ihre Meinungen.
Wie sieht das aus, wenn der (Windows) Server eine VM maschine ist? Die VMWare Maschine besteht dann ja aus einer Datei, aber innerhalb des WinServers sieht der ja die Fragmentierung dieser Datei. Es wird in meinem Umfeld kontrovers diskutiert, ob man hier innerhalb des virt. Servers defragmentieren soll.
Es ist in beiden Fällen klar, dass dies nur bei Serverwartungen außerhalb der Betriebszeiten der User bei Bedarf durchgeführt wird. Also bestenfalls ein paar Mal im Jahr und nur bei Notwendigkeit, die Platten werden also nicht durch geplante Defragtasks beansprucht.
Danke schon mal für Ihre Meinungen.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 301200
Url: https://administrator.de/forum/defragmentierung-sinnvoll-bei-raid-controllern-windows-server-ntfs-und-wie-ist-das-bei-virtuellen-maschinen-301200.html
Ausgedruckt am: 17.04.2025 um 21:04 Uhr
3 Kommentare
Neuester Kommentar
Hallo Reiner.essig
das hängt vom Controller, bzw dem Mechanismus seines Array Aufbaus her ab. Grundlogik der meisten RAIDs ist es egal welchem Füllstand einen gleichen Durchsatz zu haben. Sofern du RAID3/4/5/6/7 benutzt sehe ich keinen Sinn darin, außer du willst dem Kontroller was zu tun geben. Bei diesen RAIDs werden immer von allen Membern gelesen, sprich die Latenz geht um die Wurzel-Memberzahl nach oben kommt aber dafür um die Memberzahl Vielfaches an Daten (abzüglich der/s Parities). Da dem RAID Controller meist einiges an Cache zur Seite steht sollten sich verteilte Zugriffe nicht so kräftig auswirken, solange ein System (Bei DBs z.B.) dahinter ist.
Bei VMware (evtl auch HyperV) ist es effektiv gleich da über dem Array auch noch ein Cachemanager sitzt. Im Besten Fall kann er auch komplette Neustarts komplett im Cache verarbeiten sofern der Hypervisor genug RAM hat. NTFS versucht von sich aus Fragmentierung zu vermeiden sofern du den Füllgrad der HD so unter dem Daumenwert von 80% liegt. Je nach Filesystem (UFS z.B.) wird Fragmentierung sogar gefördert um verteilte Zugriffe zu ermöglichen. Durch den stark verteilten (HD) Zugriff durch hunderte Threads kann das durchaus aufgehen. Auf Flashspeichern ist Defragmentierung auf jeden Fall unsinnig und konterproduktiv. Bei HDs.... kann man darüber diskutieren, bei Arrays sehe ich es ähnlich wie Flash. Durch die Abstraktion vom Realen Block zu einem logischen Disk, darüber dann zu einem log. Volumen verwischt jede Art von zugriffsbeschleunigender Wartung. Evtl bringt das auslagern (DB) auf einen Datenträger speziell dafür mehr. Ich hatte vor vier Jahren einmal so einen Fall mit einer MS SQL welche wir von einem RAID5 Flash System (also schon ganz ordentlich) in eine RAMdisk (mit Snapshots) überführten was die kleine DB (unterer GB Bereich) fast 20mal mehr IOPS liefern ließ. Ein ordentliches Designen am Anfang (RAID5 ist für DBs nicht unbedingt geeignet durch die Latenz, RAID1+0 oder simples Concatenating kommt da eher in Betracht).
Gruß
Sam
das hängt vom Controller, bzw dem Mechanismus seines Array Aufbaus her ab. Grundlogik der meisten RAIDs ist es egal welchem Füllstand einen gleichen Durchsatz zu haben. Sofern du RAID3/4/5/6/7 benutzt sehe ich keinen Sinn darin, außer du willst dem Kontroller was zu tun geben. Bei diesen RAIDs werden immer von allen Membern gelesen, sprich die Latenz geht um die Wurzel-Memberzahl nach oben kommt aber dafür um die Memberzahl Vielfaches an Daten (abzüglich der/s Parities). Da dem RAID Controller meist einiges an Cache zur Seite steht sollten sich verteilte Zugriffe nicht so kräftig auswirken, solange ein System (Bei DBs z.B.) dahinter ist.
Bei VMware (evtl auch HyperV) ist es effektiv gleich da über dem Array auch noch ein Cachemanager sitzt. Im Besten Fall kann er auch komplette Neustarts komplett im Cache verarbeiten sofern der Hypervisor genug RAM hat. NTFS versucht von sich aus Fragmentierung zu vermeiden sofern du den Füllgrad der HD so unter dem Daumenwert von 80% liegt. Je nach Filesystem (UFS z.B.) wird Fragmentierung sogar gefördert um verteilte Zugriffe zu ermöglichen. Durch den stark verteilten (HD) Zugriff durch hunderte Threads kann das durchaus aufgehen. Auf Flashspeichern ist Defragmentierung auf jeden Fall unsinnig und konterproduktiv. Bei HDs.... kann man darüber diskutieren, bei Arrays sehe ich es ähnlich wie Flash. Durch die Abstraktion vom Realen Block zu einem logischen Disk, darüber dann zu einem log. Volumen verwischt jede Art von zugriffsbeschleunigender Wartung. Evtl bringt das auslagern (DB) auf einen Datenträger speziell dafür mehr. Ich hatte vor vier Jahren einmal so einen Fall mit einer MS SQL welche wir von einem RAID5 Flash System (also schon ganz ordentlich) in eine RAMdisk (mit Snapshots) überführten was die kleine DB (unterer GB Bereich) fast 20mal mehr IOPS liefern ließ. Ein ordentliches Designen am Anfang (RAID5 ist für DBs nicht unbedingt geeignet durch die Latenz, RAID1+0 oder simples Concatenating kommt da eher in Betracht).
Gruß
Sam
Hi
sofern du VMFS meinst: da ist defrag nicht möglich und auch unsinnig; je nachdem ob du Thin Provisioning oder Thick benutzt hast ist ist Fragmentierung auf unterster Ebene sowieso normal und VMFS macht auch als kleinste Einheit 1MB Blöcke, also weit überhalb von den 4k Default von NTFS. Verteilte Blöcke werden im VMFS bevorzugt gecached. Ich würde nicht erwarten das dein System dadurch real schneller wird. Schlimm wird es bei nTFS nur wenn das System still voll läuft und Füllgrade ab 95% sind mit einem enormen Abfall der Performance verbunden; ab dem Punkt funktioniert aber Defrag sowieso nicht mehr. Der 80% Daumenwert ist da recht gut angesetzt und gilt auch für andere Dateisysteme (ZFS und XFS ganz vorne)
Gruß
Sam
sofern du VMFS meinst: da ist defrag nicht möglich und auch unsinnig; je nachdem ob du Thin Provisioning oder Thick benutzt hast ist ist Fragmentierung auf unterster Ebene sowieso normal und VMFS macht auch als kleinste Einheit 1MB Blöcke, also weit überhalb von den 4k Default von NTFS. Verteilte Blöcke werden im VMFS bevorzugt gecached. Ich würde nicht erwarten das dein System dadurch real schneller wird. Schlimm wird es bei nTFS nur wenn das System still voll läuft und Füllgrade ab 95% sind mit einem enormen Abfall der Performance verbunden; ab dem Punkt funktioniert aber Defrag sowieso nicht mehr. Der 80% Daumenwert ist da recht gut angesetzt und gilt auch für andere Dateisysteme (ZFS und XFS ganz vorne)
Gruß
Sam