NetApp MetroCluster over IP? Manche NetApp Enthusiasten mögen jetzt aufschreien. War es doch seit Jahr und Tag immer eine Art Gesetzesmäßigkeit, dass ich für den NetApp MetroCluster entweder lange SAS Kabel benötige oder eine Fabric im Backend stehen habe, welche ausschließlich nur für den MetroCluster zur Verfügung steht.
Wie kommt DerSchmitz nur auf den ketzerischen Gedanken, dass es einen NetApp MetroCluster over IP geben könnte?
Ganz einfach. Habt ihr schon Mal einen Blick auf das aktuelle Top-Modell von NetApp geworfen? Die A700S ? So sieht die A700S von hinten aus. Genug freie PCI Slots für FC-VI Cards und FC Karten zur Verkabelung an die ATTO Bridges. Passt also!
Und jetzt gucken wir uns das Schätzchen mal von Vorne an:
Oooops. Interne Platten! Das ging und geht bei heutigen Metro Clustern nicht. Um den Zugriff auf die Remote Disks zu gewährleisten waren die Controller Nodes des NetApp Fabric Metro Clusters nie direkt mit den Diskshelfs verbunden sondern über ATTO Bridges und eine Fabric im Hintergrund.(Hier als Beispiel ein 2 Node Fabric MetroCluster)
Mhh also wenn die Controller im NetApp Fabric Metro Cluster nie direkt mit den Diskshelfs verbunden sind, sondern eine Fabric und ATTO Bridges (oder SAS Kabel) nutzen, wie soll das dann mit der AFF A700S funktionieren? Korrigiert mich bitte falls ich falsch liege, aber zwischen die internen Platten der AFF A700S eine Fabric zu basteln und ATTO Bridges scheint mir technisch etwas abwegig.
Daher stelle ich folgende Vermutungen an:
- Für die AFF A700S wird es keine Metro Cluster Funktionalität geben
- Mhh kann natürlich sein. Aber das Flaggschiff nicht mit dieser Möglichkeit auszustatten halte ich für etwas abstrus. „Klar kannste das geilste und schnellste Storage von NetApp haben, aber leider nicht als Metro Cluster, geh bitte auf ein anderes Modell lieber Kunde“ <- Neee wird NetApp nicht machen.
- Wenn ich eine AFF A700S als MetroCluster betreiben möchte, darf ich keine internen Platten verwenden sondern muss externe Diskshelfs anhängen
- Also das würde für potenzielle MetroCluster Kunden, die eine AFF A700S brauchen, dem Fass den Boden ausschlagen. „Ja klar lieber kunde, da hast du zwar 24 SFF Steckplätze drin, musst aber trotzdem shelfs kaufen“ <- Nee glaub ich nicht, dass NetApp das macht.
- NetApp baut einen MetroCluster over IP
Meine Vermutungen 1 und 2 halte ich persönlich für sehr unwahrscheinlich. Daher möchte ich mich mal ein Bisschen auf den Gedanken einschießen, dass es einen NetApp MetroCLuster over IP geben könnten.
Wie könnte ein NetApp MetroCluster over IP funktionieren?
Zuerst sollten wir uns vor Augen führen, was NetApp mit seinem Betriebssystem Clustered DataONTAP in den letzten Jahren geleistet hat. Man ist von physikalischen Storage Controller-Abhängigkeiten zu voll virtualisierten Storage Systemen umgestiegen. Clustered DataONTAP enthält auch schon das Wort Cluster. Habe ich zwei Storage Controller Köpfe in einem Chassis, so ist dies meist ein „Switchless-Cluster“. Habe ich mehr als zwei Nodes in einem NetApp Cluster, so wird daraus ein „Switched Cluster“. Für diesen „Switched Cluster“ hat NetApp dann auch eigene Switche geliefert. 10 GbE / 40 GbE versteht sich.
Ja aber was hat das mit einem MetroCluster over IP zu tun ?
Ganz einfach. Heute reden wir über 10 Gb Ethernet, 25 Gb Ethernet, 40GbE und 100 GbE! Das was NetApp mit 10 GbE/ 40 GbE Switches im Cluster hinbekommt, kann ja noch nicht das Ende der Fahnenstange sein. Stellen wir uns nun vor, dass wir beispielsweise die Clusterinterconnect Switche von NetApp nutzen könnten, um sowohl den IntraCluster Traffic, als auch den InterCluster Traffic „abzufackeln“. Auch in Hinsicht auf die Cloud Aktivitäten von NetApp passt es einfach ins Bild, wenn man vom FC Protokoll weg geht und auf ein Ethernet-Protokoll setzt.
Ich stelle mir daher einen MetroCluster over IP wie folgt vor:
Die Controller Nodes sind per 10GbE an die NetApp ClusterSwitche angeschlossen und diese dann an das Kundennetzwerk. Der Kunde wäre damit für die Verbindung zwischen den Seiten mit seiner vorhandenen Infrastruktur verantwortlich. Und damit auch für die Verfügbarkeit und Performance.
Wer sich jetzt an die Architekturen von HPE, EMC, DATACORE, etc erinnert fühlt… Ja das sieht bei denen auch so aus. Metro Cluster over IP mit allen vor und Nachteilen.
Wie und ob NetApp das „Problem“ des geteilten NVRAMS zwischen den Seiten und Controllern lösen könnte weiß ich nicht. Denn gegenüber den meisten SyncMirror Anbietern hat NetApp immer ein Synchron gespiegeltes NVRAM zwischen den Köpfen der einzelnen Seiten gehabt. Wettbewerber haben meist „einfach nur“ die Daten auf den Platten gespiegelt.
Um die eigentliche MetroCluster Funktion abzubilden, also das Schreiben auf Remotedisks in großer Entfernung könnte ich mir allerdings vorstellen, dass NetApp vielleicht auf das iSCSI Protokoll setzt.
Grundlage hierfür könnten die Erfahrungen sein, die NetApp mit „ONTAP Select“ gemacht hat. Hier wird schließlich auch per iSCSI eine „SyncMirror“ Replikation in einem HA Paar gemacht. Zwar nur local, aber wer weiß?
Und was ist, wenn es so kommt ?
- Also wenn ich keine dedizierten Platten mehr für Root Aggregrate brauche und für die „Remote Plexe“, dann kann ja rein theoretisch ADP auch im MetroCluster funktionieren. ALSO Mehr Netto vom Brutto. Das macht den MetroCluster aus meiner Sicht noch wettbewerbsfähiger.
- Hooray ich spare mir ein Haufen von Hardware. FC-Backend Switche, ATTO Bridges, Kabel, etc.
Ich bin gespannt auf Eure Kommentare.