… und warum uns „indirect IO“ fast nicht interessiert.
Kennt ihr das? Da stehste vor nem NetApp 4Node Cluster und weißt nicht mehr wie die Cluster-Interconnects zu verkabeln sind? Sind ja schließlich viele Ports und viele Kabel. NetApp hat es uns da eigentlich sehr einfach gemacht. Node 1 immer auf Port 1, Node 2 auf Port 2, Node 3 auf Port 3 und Node 4 auf Port 4. Wenn Ihr mehr nodes im Cluster habt könnt ihr das Ganze bis zu Port 12 einfach weiter spielen.
Nun haben die Biester ja zwei Cluster-Interconnect Ports. Im Falle der hier dargestellten FAS 2650 die Ports e0a und e0b. Das Schöne ist, dass wir die e0a und e0b Ports in der FAS 2650 exklusiv für den Cluster-Interconnect zur Verfügung haben. Wir „verschwenden“ also keine potenziellen Frontend Ports mehr. Wir sehen hier zwei FAS 2650 mit SSD only Ausstattung!
e0a geht dabei immer auf den Cluster SwitchNr.1. e0b geht immer auf Cluster SwitchNr.2.
Schwer zu erkennen? Hier ein Verkabelungsbeispiel bei der Verwendung von NetApps CN1610 Switchen:
Na wird es jetzt einfacher? Fehlen nur noch die Verbindungen zwischen den Cluster Switchen. Hierbei verbinden wir einfach Port 13 mit Port 13, 14 mit 14, 15 mit 15 und 16 mit 16.
An dieser Stelle haben wir die Cluster Switche mit vier 10GbE Kabeln verbunden! <- Merken!
So nun kommen wir zu der Situation, dass wir vier Nodes im Cluster haben. Jeder Node hat seine eigenen Platten in seinem eigenen Aggregat.
Jeder Node hat seine eigenen FrontendPorts, aber die Storage Virtual Machine (SVM) hat nur ein Logical Interface (LIF) auf einem Node. Das heißt, dass die SVM beispielsweise einen Port auf Node 1 „besitzt“. Muss sie nun Speicher „ansteuern“ welcher von Node 3 oder Node 4 im Besitz ist, so muss das über die Cluster-Interconnect Kabel geschehen. Das ist „böser“ Indirect IO! Also Der Node wird nicht direkt angesprochen sondern die Anfrage kommt über einen anderen Node und muss über den Cluster-Interconnect zum „richtigen“ Node weitergeleitet werden.
Wir haben jetzt zwei Möglichkeiten: (Auf Möglichkeit drei pNFS gehe ich hier nicht ein, da VMWare das noch nicht kann)
- Wir geben der SVM für jeden Node eine eigene LIF, die auf dem jeweiligen Node „zuhause“ ist.
- Wir machen nix!!!
Und welche Möglichkeit ist jetzt für mich die Richtige?
- Wenn eure Server gerade das El Nino Phänomen berechnen, die exakte Position unseres Planeten im Universum in Bezug auf unsere Galaxie bestimmen, das menschliche Genom entschlüsseln oder Bilder vom MARS Rover auswerten, dann würde ich auf jeden Fall zu Möglichkeit EINS raten.
- Betreibt ihr eine „normale“ Infrastruktur mit vielleicht einhundert oder zweihundert VMs, dann hätte ich keinen Schmerz mit Möglichkeit ZWEI.
Warum Möglichkeit Zwei ? Da geht doch alles über den Cluster-Interconnect?
Wir haben uns ja oben gemerkt, dass wir hier vier 10 GbE Kabel für den Cluster-Interconnect benutzen.
Machen wir eine einfache Rechnung auf:
Wir haben 4 x 10GB = 40 GB, teilen diese durch 8Bit damit wir auf die GB/s kommen. Das ergibt dann 5 GB/s. Um auf die KB/s zu kommen, nehmen wir die 5 GB * 1024 * 1024 und das ergibt dann 5.242.880 KB/s. Das teilen wir dann durch eine angenommene Blocksize von 8KB und kommen auf 655.360 IOPS.
4x 10 GbE / 8 Bit = 5 GBs *1024 *1024 = 5.242.880 KBs / 8K = 655.360 IOPS
Also Leute, wenn ihr 655.360 IOPS über eine FAS 2650 bekommen wollt, habt ihr eh den falschen Controller Kopf für euren Anwendungszweck. Und bevor ihr die 655.360 IOPS über den Cluster-Interconnect durchbekommt hat der Controller Kopf von der FAS 2650 schon längst dicht gemacht 😉
Also am Cluster-Interconnect wirds bei Eurer FAS sicherlich nicht liegen, wenn „etwas zu langsam erscheint“. Daher kümmert uns der „indirect IO“ kaum.
Kritik, Lob und Fragen dürft ihr gerne wieder im Kommentarbereich hinterlassen.
Gruß
DerSchmitz