NetApp CIFS vs. Windows Server 2016 – wer ist der besserer File Server ? (Teil2)

Willkommen zu Teil 2 meiner Blog Serie: "NetApp CIFS/SMB vs. Windows Server 2016"

 

4) Filesystem und Volumes

 

Das Herzstück eines jeden File Servers ist sicherlich sein Filesystem.

 

NetApp WAFL Bild 9.png

Unser File System WAFL gehört, ähnlich wie NTFS, sicherlich zu den älteren File Systemen. Aber Alter hat auch etwas mit Reife zu tun. 😉 Seit über 20 Jahren im Einsatz wurde WAFL stetig weiterentwickelt und durch den Einzug einer Virtualisierungsschicht, den sogenannten Aggregaten bzw. FlexVolumes, vor etwa 15 Jahren maßgeblich verändert. Vor allem die vielen Speichereffizienz Technologien, gepaart mit der intelligenten Snapshot bzw. Cloning Funktionalität, sind auch bis heute noch einzigartig am Markt. Aber dazu mehr in Punkt 5 und 6 meiner Blog Serie. Heute unterstützen NetApp FlexVolumes Filesysteme bis zu 100TB.

 

Aber, das extreme Wachstum der NAS Daten erforderte auch für NetApp eine Neugestaltung der Volume Architektur. D.h. um den heutigen als auch zukünftigen Anforderungen unserer Kunden gerecht zu werden, wurden die sogenannten FlexGroups entwickelt. FlexGroups wurden aktuell mit Filesystemgrößen von bis zu 20PB und 400 Milliarden Files getestet und sorgen mit der Verteilung der Daten über alle Ressourcen, d.h. Controller, Netzwerk-Ports, Disken auch in vielen Workloads für eine enorme  Performancesteigerung. Im folgenden Blog hatte ich bereits näher über das Thema FlexGroups geschrieben.

 

Bild 10.pngMicrosoft NTFS

Mit Windows Server 2012 hat Microsoft sehr viele Optimierungen und Features in das NTFS File System gepackt. Vor allem das Thema Downtime nach einer Filesystembeschädigung (auch gerne als CHKDSK bezeichnet) wurde drastisch verbessert – ich denke, man kann auch sagen, das Problem wurde eliminiert.

 

In der Theorie können NTFS File Systeme bis zu 265TB groß werden. Aber, und auch das ist scheinbar vielen nicht bekannt, kommen u.a. Volume Shadow Copy Services oder DeDuplizierung zum Einsatz, wird das NTFS File System auf 64TB limitiert. Auch mit Windows Server 2016 hat sich das Limit nicht verändert.

 

Microsoft ReFS

Persönlich bin ich ein Fan des ReFS Filesystems. Nicht nur, weil es sehr viele Ähnlichkeiten zu unserem WAFL hat. Nein, genau aus diesem Grund, den der folgende Blog sehr schön beschreibt:

 

 „The Resilient File System (ReFS) is Microsoft's newest file system, designed to maximize data availability, scale efficiently to large data sets across diverse workloads, and provide data integrity by means of resiliency to corruption.”

 

Das ist das Filesystem, das man sich für Windows File Service eigentlich wünschen würde und mit einer Filesystemgröße von bis zu 4.7ZB (Zeta Byte) sicherlich ausreichend für die nächsten Jahre. Aber, ReFS ist für klassisches Windows File Service nicht geeignet. Auch in Windows Server 2016 hat ReFS für klassisches Windows File Service, wie die folgende Tabelle zeigt, folgende Einschränkungen:

 

Bild 3.png

 

Fazit:

Um auch zukünftig den rasch wachsenden Datenvolumen im Tagesbetrieb begegnen zu können, sind skalierbare Volumes mit den entsprechenden File Systeme das A und O. Ein 64TB NTFS Volume wird in vielen Umgebungen m.E. nicht ausreichen.

 

5) Speichereffizienz

 

Um die Investitions- als auch Betriebskosten (z.B. Strom, Klima, etc.) für die Datenspeicherung zu senken, helfen in der Regel Speichereffizienz-Technologien.

 

NetApp clustered ONTAP

Wie die folgende Abbildung zeigt, liefert NetApp clustered ONTAP heute eine Vielzahl an Speichereffizienz Technologien. Angefangen bei einem hocheffizienten und sicheren Raid-Level, der auch den gleichzeitigen Ausfall von drei Festplatten problemlos übersteht. Einer sicherlich am Markt einzigartigen Snapshot Technologie mit intelligenter Cloning Funktionalität. Wie das alles im Kontext Backup und ODX zusammenspielt, folgt in Punkt 6.

Bild 4.png

Der Windows Server 2016 als auch NetApp clustered ONTAP bietet heute Speichereffizienz Technologien wie DeDuplizierung und Compression. Auf Papier sieht eigentlich alles gleich aus, aber wie immer steckt der Teufel im Detail.  Die Funktionsweise der Effizienztechnologien ist, wie man im Folgenden erkennen kann, bei den NetApp Speichersystemen völlig unterschiedlich.

 

Bild 5.png

 

Bereits „Inline“ werden die „Nullen“ der ankommenden Daten erkannt und rausgefiltert. Anschließend erfolgt die Komprimierung und Deduplizierung der Daten bereits im Controller. Entstehen dadurch Lücken in den Filesystemblöcken, sorgt die sogenannte Compaction (eine neue von NetApp patentierte Innovation) für eine bessere Auslastung der eigentlichen Filesystemblöcke (Ja, auch Millionen 4k Blöcke in denen nur 1 oder 2k genutzt wird, können viel Geld sparen).

Anschließend werden die verbleibenden Blöcke auf die Disken übertragen. D.h. es werden auch hier deutlich weniger IOPs auf den Festplatten oder SSD erzeugt und bereits initial weniger Kapazität benötigt.

 

Heute arbeitet die DeDuplizierung in den NetApp Systemen auf Basis unserer FlexVolumes, d.h. nur die Duplikate innerhalb eines Volumes werden erkannt. Aber, nicht mehr lange! Bereits im kommenden ONTAP Release werden Sie hier nochmal deutliche Optimierungen sehen. Mehr darf ich aktuell noch nicht verraten. 😉

 

Bei dem Thema Speichereffizienz spielt u.a. auch ThinProvisioning eine wichtige Rolle. Werden in einem Volume Einsparungen erzeugt, werden diese dem gesamten Speicherpool (in unserem Fall dem Aggregate) zurückgewiesen und können so von anderen Volumes wieder konsumiert werden.

 

Natürlich sind alle Speichereffizienztechnologien unabhängig von den Applikationen und den jeweiligen Speicherprotokollen, also ob NAS oder SAN spielt keine Rolle. Auch unsere Volume basierte Verschlüsselung, die sogenannte NetApp Volume Encryption, hat keinerlei negative Auswirkung auf die Speichereffizienz.  

 

Windows Server 2016

Auch in Windows Server 2016 gibt es einige Optimierungen in Bezug auf DeDuplizierung. Vor allem das Performanceproblem bei Server 2012 mit den Single-Threads beim DeDup-Postprocess scheint in Windows Server 2016 behoben zu sein. Nichtsdestotrotz gibt es bei Windows Server 2016 mit DeDuplizierung aus meiner Sicht noch folgende Schwachstellen beim Einsatz im klassischen File Service:

  • DeDuplizerung nur Post-Processing (nicht Inline),
  • Minimum File Alter 3 Tage, d.h. erst nach dieser Zeit wird das File dedupliziert
  • nur mit NTFS unterstützt, maximal File Systemgröße 64TB
  • kein Support für ReFS
  • Einsparung nur auf Volume Ebene
  • Inkompatibilitätsprobleme mit Quotierung auf Root-Folder Ebene
  • Inkompatibilitätsprobleme mit RoboCopy
  • Inkompatibilitätsprobleme mit Windows Suche
  • Inkompatibilitätsprobleme mit ODX

Mehr dazu finden Sie u.a. hier. Dass Microsoft auch keine Windows DeDuplizierung unter Hyper-V für laufenden VMs unterstützt, ist allseits bekannt – oder nicht?

 

Warum halte ich u.a. das Thema „Inline DeDuplizierung“ für sehr wichtig. Stellen Sie sich vor, Sie haben ein Volume mit 40TB. Durch die DeDuplizerungs konnten Sie enorme Einsparungen erzielen und haben statt den 40TB nun effektiv 70TB gespeichert. Aus irgendeinem Grund – sagen wir mal Ransomware-Befall müssen Sie nun einen kompletten Restore ihres Volumes durchführen. D.h. es kommen 70TB statt 40TB zurück. Wie machen Sie das, bedenkt man u.a. die 64TB Limitierung? Hätten Sie die zusätzlich benötigten Kapazitätsressourcen ad hoc überhaupt verfügbar?

 

Eine weitere Frage, die mich immer wieder beschäftigt, wie können andere Volumes oder Datenbereiche von den Einsparungen profitieren? D.h. das was NetApp heute mittels ThinProvisioning ermöglicht, ist mit Windows Boardmitteln m.E. in keiner Weise umsetzbar.

 

Fazit:

Insofern lautet mein Fazit im Thema „Speichereffizienz“: Die Windows Server 2016 DeDuplizierung ist aufgrund der vielen Einschränkungen nur bedingt im klassischen File Service einsetzbar. Ob sich dadurch Kosten einsparen lassen, bezweifle ich. 

 

6) ODX aka Offload Data Transfer ODX.png

 

ODX, auch gerne als „Offload Data Transfer“ bezeichnet, ist eine Funktion, die Microsoft bereits in Windows Server 2012 eingebaut hat. Vielen ist bis heute diese Funktion gänzlich unbekannt.  Hinter der Idee von ODX steckt, Kopiervorgänge von Daten direkt von dem darunterliegendem Storage Array ausführen zu lassen. Damit wird das Netzwerk sowie die Windows Clients bzw. Windows Server Ressourcen entlastet.

 

Windows Server 2016

Heute gibt es eine Vielzahl an SAN Arrays, die diese ODX Funktion unterstützen. Allerdings sehe ich sehr häufig folgende Einschränkungen unserer Mitbewerber in Bezug auf ODX:

  • kein Support für virtualisierte Windows Server File
  • kein Support bei Scale-Out File Servern
  • kein Support für Windows DeDuplizierung

NetApp clustered ONTAP

Mit clustered ONTAP 8.2 wurde die ODX Unterstützung eingeführt. Hier war es uns wichtig, eine Cross-Funktionale-Protokollfähigkeit zu implementieren, d.h. egal ob die Daten per Blockprotokoll wie FC/iSCSI abgefragt werden und/oder der Datenaustausch via dem CIFS/SMB3 Protokoll erfolgt. Sobald das Client- bzw. Serverbetriebssystem eine ODX Anfrage stellt, findet ein Offloading des Datentransfers statt.

 

Mit unserem neuesten Betriebssystem geht dies inzwischen (bei Nutzung der Blockprotokolle) auch Speichersystem übergreifend, d.h. zwischen zwei NetApp Cluster Systemen.

 

Ein weiteres Alleinstellungsmerkmal bei ODX mit NetApp ist die eingebaute SIS-Cloning Technologie. Wird beispielsweise durch einen Windows Client ein Kopiervorgang eines Files innerhalb eines Volumes gestartet, wird diese Datei nicht über die herkömmliche Methode kopiert, diese wird über den sogenannter SIS-Clone Prozess „gecloned“. Dies hat zwei entscheidende Vorteile:

  1. das kopierte File benötigt keinen zusätzlichen Speicherplatz (ist sozusagen ein bereits deduplizertes File)
  2. der Kopiervorgang ist extrem schnell, da keine Bits über Netzwerk oder auf die eigentliche Festplatte transferiert werden müssen.

Fazit:

ODX ist eine coole Sache, die vor allem mit Windows 10 Clients in Verbindung mit NetApp clustered ONTAP eine File Cloning Technologie etabliert, die man nicht mal konfigurieren muss. Ist einfach per Default an. Man sieht es aber sehr schnell an den Kapazitätseinsparungen in clustered ONTAP.

 

7) Backup und Recovery

 

Bild 11.pngDie heutigen bzw. zukünftigen Datenmengen im klassischen File Service bereiten vielen Unternehmen vor allem in Bezug auf die Datensicherung bzw. Wiederherstellung extremes Kopfzerbrechen. Gutgemeinte Ansätze wie HSM oder ILM haben i.d.R. in der Vergangenheit häufig versagt.

 

NetApp clustered ONTAP

Ich denke, es steht außer Frage, dass NetApp, als „Erfinder“ der Snapshots das Thema ganz gut beherrscht. Von vielen Kunden und Partnern wissen wir, dass unsere „Snapshot-Technologie“ mit den Produkten wie SnapRestore, SnapVault, SnapMirror, etc. weiterhin das Unterscheidungsmerkmal zu vielen unserer Mitbewerber ist, u.a. auch dem Windows Server 2016.

 

Natürlich ruhen wir uns hier nicht auf unseren Lorbeeren aus. Eine der Herausforderungen in größeren NAS Umgebungen war das Thema Sicherung per NDMP – also „Medienbruch“ bzw. „Langzeitarchivierung“. Mit unserer neuen Data Fabric Cloud Backup Lösung können wir genau das Ziel einer zukunftssicheren Ende-zu-Ende Sicherungs- bzw. Wiederherstellungsplattform für NAS Daten umsetzen.

 

Durch die vielen Technologie Partnerschaften zu Herstellern wie CommVault, Veeam, Symantec, etc. können wir Kunden helfen, unsere Technologien bzw. Snap* Funktionen in bekannte bzw. bestehende Backup bzw. Recovery-Prozesse besser zu integrieren.

 

Aufgrund der zunehmenden Bedrohung durch beispielsweise Ransomware (Crypto-Trojaner) gewinnt das Thema Backup und vor allem schnelles Recovery zunehmend an Bedeutung. Auch hier arbeiten wir intensiv mit Technologie Partnern wie u.a. der Firma Cleondris zusammen. Auch an dieser Stelle nochmal der Link auf die gemeinsamen Lösungen.

 

Windows Server 2016

Wenn es um das Thema Backup und Recovery klassischer Windows File Services geht, erlebe ich häufig zwei verschiedene Kundenwelten:

  1. Kunden, die eine Anpassung der Backup Infrastruktur an die produktive File Service Umgebung machen und u.a. unsere Snapshot Technologien dafür verwenden oder
  2. Kunden, die eine Anpassung der produktiven File Server Umgebung an das Backup machen.

Leider sehe ich sehr häufig, dass bei Verwendung von Windows File Server eher letzteres zum Tragen kommt. D.h. Kunden passen häufig die Größe der Filesysteme respektive Windows File Server Cluster an die Wiederherstellungsgeschwindigkeit des Backups an.

 

Erst kürzlich erzählte mir ein Kunde, dass die maximale File System Größe auf wenige TBs limitiert wird, da man sonst keinen Restore innerhalb von 4-8 Stunden für den Windows File Server Cluster gewährleisten könne. Als Folge dieser Maßnahme müssen die Administratoren dieses Kunden regelmäßige Überstunden für etwaige Datenmigrationen leisten. Denn kleine Filesysteme laufen nun mal schneller voll. Und da sind wir wieder bei der Herausforderung zum Thema „Windows File Server Sprawl“.

 

Alternativ bietet der Windows Server 2016 natürlich auch die sogenannten Volume Shadow Copy Services an. Aber auch diese sind, wie bereits mehrfach erwähnt, auf 64TB und auf das Filesystem NTFS limitiert. Aufgrund der Funktionsweise (Copy-on-Write) der Volume Shadow Copy Service brachte dies in der Vergangenheit einige „unschöne“ Effekte mit sich. Vor allem Windows File Server, die höhere IO Lasten und Änderungen verursachen, hatten oft mit „plötzlich gelöschten oder verschwundenen“ Snapshots zu kämpfen. Aus diesem Grund hat Microsoft sicherlich u.a. folgende BestPractices in Bezug auf Volume Shadows Copy publiziert:

 

Shadow Copies of Shared Folders is not a replacement for performing regular backups. Use a backup utility in coordination with Shadow Copies of Shared Folders as your best preparation for restoring.

 

Fazit:

Auch bei Windows Server 2016 gibt es keine Optimierungen/Neuerungen zur Sicherung von klassischen File Service. Kunden müssen weiterhin auf die altbewährten Backup/Restore Mechanismen der Backup Software Hersteller zurückgreifen. Eine vergleichbare Funktion wie NetApp SnapVault ist mit Windows Server 2016 oder 3rd Party Produkten nicht möglich und bleibt weiterhin ein Alleinstellungsmerkmal von NetApp.

 

Ich hoffe, Ihnen hat mein Blog bis hier her gefallen - hier geht´s weiter zu Teil 3