Viele Male habe ich mit Kunden die Vor- und Nachteile von DataCore SANsymphony-V vs. $OTHERVENDOR diskutiert. Das ist für mich auf der einen Seite ein ziemlicher Eiertanz, da ich mit DataCore und HP arbeite, aber auch NetApp sehr mag, auf der anderen Seite kann ich ziemlich viel zu den Vor- und Nachteilen der Systeme sagen, ohne Silverbullets aus irgendwelchen Marketingpapieren zu zitieren. Erstaunlicherweise habe ich kaum Installation mit DataCore gemacht, bei der alten Storagesystemen durch Storage Virtualisierung neues Leben eingehaucht wurde. Häufigster Grund für den Einsatz von DataCore war der seamless Failover (oder wie jemand mal so schön sagte "German Failover"... ;) ). Interessanterweise war dieses Feature für viele DataCore Kunden das ausschlaggebende Argument für die Auswahl. Vergleicht man andere Lösungen zur Spiegelung (z.B. HP Continuous Access EVA oder XP), so ist der Failover hier wirklich ziemlich einfach, sauber und automatisiert. Bei HP Continuous Access muss ich schon etwas mehr Aufwand betreiben. Das NetApp Metro Cluster macht es ähnlich wie DataCore. Wie kommt das? Betrachten wir eine klassische DataCore SANsymphony-V Installation mit einem klassischen Dual-Controller System. Um zu abstrahieren führen wir ein paar allgemeine Begrifflichkeiten ein:
- DataCore Storage Server == Controller
- DataCore Server Group mit zwei Servern == Dual Controller
DataCore SANsymphony-VJeder Controller besitzt eigenen Speicher. Das Backendstorage ist über Backend-Ports angebunden und wird exklusiv von dem Controller genutzt. Die Vdisks werden über Mirror-Ports zwischen den Controllern gespiegelt. Die Applikationsserver sind an die Frontend-Ports angebunden. Jeder Controller verfügt i.d.R. über zwei Frontend-Ports, das Controller Paar verfügt damit über vier Frontend-Ports. Da die Vdisks zwischen den Controllern gespiegelt werden und beide Seiten aktiv sind, besitzt jeder Applikationsserver vier Pfade zu jeder LUN. Für den konsistenten Zustand der Vdisks sorgen die Controller. Fällt ein Controller aus, übernimmt der überlebende Controller die Arbeit und der Applikationsserver liest und schreibt die Daten auf die Vdisks des überlebenden Controllers. Nach dem Wiederanfahren werden die Vdisks synchronisiert. Jeder Ausfall eines Controllers, egal ob durch Neustart (Firmware, Updates etc.) oder andere Umstände, führt IMMER zu einem Site Failover, da der andere Controller die Arbeit übernimmt, aber nicht das Backendstorage des ausgefallenen Controllers nutzen kann. Das System kann problemlos auf verschiedene Sites verteilt werden, da das Backendstorage komplett redundant ist. Dies ist dem Umstand geschuldet, dass die Server sich ein Backendstorage nicht teilen können. Mittels Shared Multi-port Array Support lässt sich dieses Problem lösen. Der Preis dafür ist aber hoch: Kein Write Caching, kein CDP, nur Full Snapshots etc.
$OTHERVENDOR mit Dual Controller oder einem vergleichbaren KonzeptZwei Controller teilen sich das Backendstorage. Die Controller sind i.d.R. redundant an das Backendstorage angebunden. Eine Vdisks "gehört" i.d.R. einem Controller, welcher die IOs durchführt. IOs können aber von allen Controllern angenommen werden. Über einen Mirrorlink zwischen den Controllern wird der Write Cache gespiegelt. Über den gleichen Link werden Proxy IOs übertragen, also IOs die von einem non-owning Controller (der Controller, dem eine Vdisks NICHT zugewiesen ist) angenommen wurden. Jeder Controller hat i.d.R. zwei oder mehr Frontend-Ports. Da Vdisks von allen Controllern präsentiert werden haben Applikationsserver vier oder mehr Pfade (abhängig von der Anzahl der Frontend-Ports). Fällt ein Controller aus oder wird er neu gestartet, so übernimmt der verbleibende Controller die Kontrolle über die Vdisks. Bedingt durch das geteilte Backendstorage kommt es nicht zu einem Site Failover - das Storagesystem selber steht nur an einem Ort und kann nicht auf unterschiedliche Lokationen verteilt werden.
Zusammengefasst und vereinfacht kann man sagen: DataCore SANsymphony-V oder NetApp Metro Cluster arbeiten wie ein Dual Controller Array, welches man in der Mitte zerschnitten und jedem lokalen Speicher verpasst hat. Man muss sich als Kunde nun überlegen was man haben möchte und wie die Anforderungen definiert sind. Es gibt Konstellationen wo eine DataCore Installation deutlich teurer wird als z.B. eine HP 3PAR StoreServ 7400, eben da ich den Backendstorage doppelt vorhalten muss, aber die Maschinen im gleichen Datacenter stehen. Dazu kommen natürlich reichlich Systeme, die gänzlich anders arbeiten (klassiche Scale-Out Lösungen wie z.B. HP StoreVirtual oder Clustered Data ONTAP).
Am Ende sollte die Auswahl immer über definierte Anforderungen erfolgen.
Man sollte dazu aber verstanden haben wie die Systeme arbeiten und wo
die Vor- und Nachteile liegen.
