Wir setzen in unseren ESX vSAN Farmen SAS SSDs ein.
In dem Fall HP DL385 Gen10 V2.
So nen vSAN Cluster hat was zwischen 100 und 200 SSDs. (davon haben wir mehrere)
Wir haben SAS genommen, weil NVMe zu der Zeit, sagen wir mal "interessant" war, was das Thema Anbindung angeht. Da SAS hier der aktuelle Standard ist, wird so auch weiter ausgerollt. Die Gen10 laufen aber Mitte des Jahres aus. Die Gen11 sind, was die Anbindung angeht, etwas moderner unterwegs.
Auf diesen speziellen Systemen laufen hunderte VMs, im Regelfall mit wenig Workload. DC, Exchange, ERP oder vergleichbares allerdings nicht.
Bei unserer Workload langweilt sich das Storage zu Tode, aber sowas von. Da ist quasi nix los.
Wir haben irgendwas um 100MB/s an dauerhafter Datenrate und mittlere vierstellige IOPS.
Dieses Lastverhalten in Kombination mit dem Mehrpreis zu NVMe war für mich der Grund "SAS" also völlig OK zu bewerten.
Auf der anderen Seite haben wir gerade DB-Cluster Hardware beschafft. Da sind in den Gen11 Server NVMe SSDs drin, aus dem einfachen Grund, dass wir zum einen weniger Laufwerke haben und zu anderen etwas mehr Reserven haben. (ob wir das wirklich brauchen, wird sich zeigen)
Das Preislich bei der geringen Menge an Laufwerke nicht zu sehr ins Gewicht fällt.
Einen RAID-Controller hat man in dem Fall noch immer an der Backe, da anders nicht möglich ist.
Weiterhin haben wir HPE Primera beschafft, in dem Fall mit internen SAS SSDs. Das hat den einfachen Hintergrund, dass wir das als Standardstorage haben und man mit den LFF-Enclosures mit SAS einfacher erweitern kann. FC ist absoluter Müll, gerade bei der Anbindung von Enclosures. Das wird erst besser, wenn NVMe-oF aus den Kinderschuhen rausgewachsen ist.
Grundsätzlich könnte man in der Primera die Laufwerke auch Mischen, da die HDD und SSD Arrays erstmal voneinander getrennt sind.
Im Idealfall würde ich erstmal ein paar KPIs vom aktuellen Storage nehmen. Wenn da nicht irgendwelche abstrusen Zahlen auftauchen, würde ich sagen, das SAS völlig ausreicht.
Die von
@gea genannten Daten, sollte man sich bei "seinen" Laufwerken genau anschauen.
Grundsätzlich ist Enterprise NVMe schneller als SAS. Da sind manchmal Zahlen dabei, dass einem Schwindelig wird.
Nen Bugatti ist auch schneller als nen Golf. in 99,99999999999999999999999% kommste mit dem Golf denn hin.
NVMe macht meiner Meinung nur dann Sinn, wenn man extreme Anforderungen an Storage hat und das in einem möglichst kleinen footprint. Das scheint hier absolut nicht der Fall zu sein.
Ob man nun 100gbit braucht, muss man wissen. Unsere vSAN Cluster laufen alle mit 10GBE. (altes vSAN)
Und mehr ist, siehe Workload, auch absolut nicht nötig. Klar sind die SSDs schneller, aber ob nun die SSDs sich langweilen oder noch zusätzlich die NICs und Switche, ist am Ende auch egal.
Da kommt es eher auf den Rest der Infrastruktur an.
Die 10GBE werden auch noch ne ganze Weile reichen, in unserem Umfeld.
Die NICs sind btw dennoch schon 25GBE, auch aus dem Grund, dass die alten 10GBE Müll waren und die Hersteller eh nix anderes anbieten.
100GBE machen meiner Meinung nur dann sinn, wenn der ganze Rest im Core und Co eh schon 100GBE ist und man für die Server jetzt komplett andere Switche beschafft, die man sonst nicht braucht.
Auch hier sehe ich es eher so, dass 100GBE, was den Bandbreitenbedarf angeht, in dem Fall nur in sehr sehr speziellen Bereichen notwendig ist.
vSAN begnügt sich in der aktuellen Version mit 25GBE. Mehr ist natürlich immer besser.
Wenn neue Switche beschafft werden, und eine Standardisierung nichts anderes erfordert, würde ich auf 25GBE gehen. Sind die aktuellen (10GBE) Switche noch an sich OK (Laufzeit Support und Co.) kann man diese durchaus wiederverwenden. Bei so nem Konstrukt würde ich mir eher Gedanken um die Robustheit des NWs machen.
Wenn man kein echtes Leaf/Spine machen will (was man nicht immer muss, auch wenn gerade hip ist), dann eher mit klassischen Aufbauten, aber in jedem Fall würde ich pro Seite nen MC-LAG Konstrukt fahren.
Also kein Stack oder sowas.
Man braucht für sowas also 2x 2 Switche. (in der Annahme, dass es 2 sites gibt) Kann man isolated laufen lassen oder aber übers Routing angebunden. Da muss man sich dann überlegen, ob man die Router nur links und rechts drauflegt oder ob man ne art Leaf/Spine für Arme macht.
Im Storage machen wir ersteres, in den Frontendnetzen machen wir zweiteres.
Mit den 2x2 Switches hat man zum einen, wegen der LACP, doppelte Bandbreite (also 20 bzw. 50GBE) und zum anderen neben der Robustheit auch die Chance die Dinger, während das Storage weiterläuft, regelmäßig zu patchen. Bei den modernen Switchen ist es leider so, dass die bald so häufig geupdatet werden wie Windows, leider. Das sollte man über die Lebenszeit im Hinterkopf behalten. Und die Baustellen in den Firmwares werden auch immer krasser. Letztens gab es bei Aruba z.B. ein Problem im dem Radius Daemon. Das will man also nicht ungepatcht lassen.
Spanning Tree würde ich grundsätzlich von den Listen streichen und im Storage eh.
PS: Im Titel steht was von SATA, das sollte sicher SAS heißen?!
PPS: Und die Leute, die sagen, dass SAS nicht mehr zeitgemäß ist, haben absolut keine Ahnung. Auf deren Meinung sollte man daher in Zukunft mit sehr viel Skepsis reagieren. Ja, NVMe ist moderner, in der Spitze schneller etc. NVMe gehört ganz klar die Zukunft. NVMe wird nur gerade gehypt, weil die Leute (auch im Businessumfeld) meist spielgeile Kinder sind, die glauben, dass neuer = besser ist. Das Problem ist, dass besser nicht gleich sinnvoller bedeutet. Siehe die Ausführung von mir oben.
Es gibt hier kein schwarz und weiß. Selbst SATA hat noch seine (kleine) Berechtigung im Enterpriseumfeld. Dazu hatte ich in einem anderen Thread vor kurzem mal was geschrieben. Und das Geld mit der Schubkarre ausm Unternehmen rausfahren, muss man auch nicht, egal ob sich die Schubkarren stapeln. Dafür kann man ggf. auch andere Sachen kaufen. In so nem RZ oder Serverraum kann man immer was optimieren. Auch Sachen wo nicht Dell oder HPE dransteht. (Stichwort el. Sicherheit z.B.)
