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

NetApp CIFS vs. Windows Server 2016 – wer ist der besserer File Server ? Bild0.png

 

Mit jedem neuen Windows Server Release stellen sich Kunden und Partner erneut dieselbe Frage in Bezug auf klassisches Windows File Service: „NetApp NAS oder nativ Windows Server 2016“. Aktuell bekomme ich vermehrt Anfragen, ob wir NetApp intern eine Art „Wettbewerbsvergleich NetApp NAS vs. Windows Server 2016“ haben und die Vor-/Nachteile der beiden Produkte gegenüberstellen.

 

Aus Sicht von NetApp ist Microsoft einer unserer wichtigsten Technologie Partner, insofern machen wir hier keine direkten Wettbewerbsvergleiche. Nichtsdestotrotz möchte ich im Rahmen einer Blog-Serie auf zehn Unterscheidungsmerkmale NetApp CIFS/SMB vs. Windows Server 2016 näher darauf eingehen und diese auch im Detail erörtern.

 

Ein weiterer Grund für mich diese Blog Serie zu schreiben, war, dass ich in den letzten Projekten durchaus festgestellt habe, dass in Bezug auf unsere Technologie sowie die der Microsoft, einfach Unsicherheit oder Unwissenheit besteht. Natürlich hoffe ich, dass diese Blog Serie in Bezug auf klassisches Windows File Services in vielerlei Hinsicht aufschlussreich ist.

 

1) Skalierbarkeit (Scale-Out File Server)

 

Aufgrund der rasch anwachsenden Datenmengen bekommt das Thema „Skalierung“ m.E. einen sehr hohen Stellenwert. Deshalb möchte ich auch mit diesem Punkt beginnen.

 

NetApp Clustered ONTAP

Ein wichtiger Bestandteil unseres Betriebssystems Clustered ONTAP ist die Scale-Up sowie Scale-Out Architektur über alle Protokolle (CIFS, NFS, FibreChannel, iSCSI) hinweg. Diese erlaubt aktuell eine Skalierung für die NAS Protokolle auf bis zu 24 Controller und kann damit eine Kapazität von bis zu 172PB (17.280 HDDs oder 5.760 SSDs) in einem System bereitstellen. Mehr Informationen zu den Spezifikationen finden Sie u.a. hier:

Natürlich spielt neben der Skalierung der Kapazität auch die Skalierung der Performance eine wichtige Rolle. Bereits vor 6 Jahren hatten wir im Rahmen eines SPECsfs2008 Benchmarks gezeigt, dass durch Hinzufügen weiterer NetApp Controller die Performance nahezu proportional zunimmt. Dies wird u.a. in nachfolgender Abbildung bei 4,8,12,16,20 und 24 Controller verdeutlicht.

 

Bild 1.png

 

Natürlich sehen die Werte in Bezug auf IOPs und Latenz mit aktueller Hardware und Software Architektur deutlich besser aus, wie der kürzlich erschienene SPC-1 Benchmark mit 2.4 Millionen IOPs und einer durchschnittlichen Latenz von 0,69ms im folgenden Bild verdeutlicht.

 

Bild 2.png

 

Microsoft Scale-Out File Server

Bereits mit Windows Server 2012 hat Microsoft den sogenannten Scale-Out File Server eingeführt. In Windows Server 2016 wurde der Scale-Out File Server mit weiteren Features z.B. den Storage Spaces Direct ergänzt. Aktuell erlebe ich in einigen Kundensituationen, dass der sogenannte Microsoft Scale-Out File Server mit den Storage Spaces Direct für klassische NAS-Zwecke den Kunden „schmackhaft“ gemacht wird. Aber, ein Microsoft Scale-Out File Server ist nicht für klassisches Windows File Service, also die Bereitstellung von Benutzerlaufwerken und/oder Projekt-/Abteilungsfreigaben geeignet. Folgender Blog Artikel von Microsoft geht nochmal im Detail auf die Gründe ein.

 

Ein Windows Scale-Out File Server mit den Storage Spaces Direct kann als „Converged“ oder „Hyper-Converged“ Lösung lediglich für die Nutzung von SMB3 Shares für Server-Virtualisierung mittels Hyper-V oder Applikationen wie Microsoft SQL Server genutzt werden. Um letztlich auf diesem System klassische File Services bereitstellen zu können, bleibt nur der Umweg über virtuelle Server, d.h. VMs in denen ein „Windows File Server bzw. Cluster“ zum Einsatz kommen. Also das, was man schon zu Windows NT/2000/2003 Zeiten gemacht hat. Somit sind jegliche Möglichkeiten der Skalierung in Bezug auf Kapazität und/oder Performance auf eine VM begrenzt.

 

Auch in Bezug auf Skalierbarkeit stößt man m.E. bei einem Scale-Out File Server mit Storage Spaces Direct für das klassische NAS sehr schnell an seine Grenzen. Stand heute unterstützt ein Microsoft Scale-Out File Server mit Storage Spaces Direct maximal 16 Server mit je nur 26 Disken. D.h. die Gesamtanzahl der Disken wird auf 416 begrenzt. Aufgrund der Funktionsweise der Storage Spaces Direct ist die effektiv nutzbare Kapazität, nach Abzug des entsprechenden Overheads, auch nur noch sehr gering.

 

Fazit:

Insofern lautet mein persönliches Fazit: Eine Scale-Out Lösung für klassisches File Service gibt es nur mit NetApp.

 

2) Unterbrechungsfreier Betrieb Bild 7.png

 

Sicherlich „alter Kaffee“ für jeden NetApp Administrator. Clustered ONTAP wurde entwickelt, um viele der leidigen Storage Aufgaben wie Datenmigrationen oder Kapazitäts-/ Performanceanpassungen zu eliminieren.

Schon immer können und konnten wir mit clustered ONTAP im laufenden Betrieb…

  • Volumes automatisch vergrößern und verkleinern,
  • Volumes zwischen verschiedenen Disk Pools (also unseren Aggregaten) oder Storage Controller verschieben,
  • Storage Controller zu einem Cluster hinzufügen bzw. entfernen (z.B. für den Austausch der Hardware ohne Downtime und Datenmigration).
  • zur besseren Lastverteilung virtuelle Netzwerk Interfaces zwischen den Controllern verschieben.

Werden Windows File Server heute virtualisiert, kann man sicherlich die ein oder andere Aktivität ebenfalls unterbrechungsfrei durchführen. Kommen hingegen physikalische Windows File Server zum Zug, wird es schon wieder schwieriger.

 

Fazit:

Mein Fazit dazu lautet wie folgt: Unterbrechungsfreier Betrieb mit NetApp „Ja“, mit virtuellen File Servern „Ja, vielleicht mit Einschränkungen“ und im Falle physikalischer File Server definitiv „Nein“.

 

3) Mandantenfähigkeit

 

Nicht selten sehen wir, dass Unternehmen die Daten isolieren wollen/müssen, d.h. eine strikte Trennung beispielsweise der Personal-, Finanz- und/oder Entwicklungsdaten. Auch eine Separierung der Daten von Unternehmensorganisationen sehen wir häufig als Anforderung.

 

NetApp Clustered ONTAP

Auch hier zeigen sich die Vorteile der NetApp Architektur. Mittels der sogenannten Storage Virtual Machines (kurz SVM) ist es möglich, mehrere Mandanten auf einem NetApp Speichersystem gleichzeitig und sicher zu betreiben. Dabei kann jede SVM einer anderen Active Directory oder LDAP Domäne angehören. Auch die Bereitstellung dedizierter SVMs, z.B. für die DMZ, ist bedenkenlos machbar.  Technisch ist es nicht möglich, dass ein Mandant aus der SVM-1 auf Daten der SVM-2 zugreifen kann.

 

Durch die Flexibilität im Betriebssystem ist es zu jeder Zeit möglich, die Ressourcen in Bezug auf Kapazität bzw. Performance zwischen den Mandanten anzupassen. Getreu dem Motto: „Wer mehr haben will, bekommt auch mehr…“ 

 

NetApp Kunden, egal aus welchen Segmenten (z.B. Mittelstand, Enterprise oder Service Provider) nutzen genau diese Funktionalität für deren Mandantentrennung.

 

Bild 8.png

 

Windows Server 2016

Ein Windows File Server Cluster bietet diese Möglichkeit nicht. Jeder Windows File Server Cluster kann somit nur einer AD und damit einem Mandanten angehören. Besteht der Bedarf nach zwei oder mehreren Mandanten, werden dementsprechend auch mehrere separate Systeme benötigt. Dies erhöht natürlich die Anzahl der zu betreibenden Windows File Server Cluster und setzt bereits im Vorfeld eine exakte Planung in Bezug auf Ressourcen voraus. In vielen Fällen lassen sich Ressourcen nur schwer oder aufwendig anpassen.

 

Fazit:

Windows File Server Cluster bieten keine Mandantenfähigkeit. Über eine Vielzahl an Systemen wird das Problem umgangen. Meines Erachtens führt dieser Windows File Server „Sprawl“ zu enormen Betriebsaufwänden.

 

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