Mittwoch, 7. Oktober 2015

N-Tec Workshop-Tour: »Aufpassen auf die Knoten-Architektur!«

speicherguide im Gespräch mit Robert Thurnhofer, Marketing Manager Central Europe bei DataCore

Datacore empfiehlt: »Aufpassen auf die Knoten-Architektur!«

Converged- und Hyperconverged-Lösungen werden vermehrt in Rechenzentren eingesetzt. Doch was sind die Besonderheiten der verschiedenen Lösungen? Der Storage-Systemehersteller N-Tec will hier auf seiner N-Tec Workshop-Tour nächste Woche (13. bis 15. Oktober) intensiver darauf eingehen. Wir sprachen im Vorfeld mit Robert Thurnhofer, Marketing Manager Central Europe bei Datacore Software, über das Thema. Datacore ist einer der strategischen Partner von N-Tec.

Wie genau definiert sich der Unterschied zwischen Converged- und Hyperconverged-Storage?

Thurnhofer: Bei konvergenten Systemen werden Anwendungen auf Server-Systemen in einem Rack ausgeführt, und zwar mit separatem, externem SAN für einen gemeinsam genutzten Speicher. Beispiele wären hier »vBlock« von VCE oder »Flexpod« von Cisco/Netapp. Bei hyperkonvergenten Systemen werden die Anwendungen auf Knoten ausgeführt, die sowohl die Rechenleistung als auch einen gemeinsam genutzten Speicher liefern. Hierbei gibt es kein externes SAN.
[...]
Und wie sieht dann der Ansatz von DataCore aus?

Thurnhofer: Bei uns geht es um ein Modell mit flexibler Hardware-Auswahl, wobei eine Arbeitsverteilung mit mehreren Hypervisoren bzw. auch ohne Server-Virtualisierung unterstützt wird. Unser Lösungsmodell bietet also Speichermöglichkeiten sowohl für eine virtualisierte als auch für eine nicht virtualisierte Arbeitsverteilung. Dies ist insbesondere für Unternehmen wichtig, die mehrere Hypervisoren einsetzen und gleichzeitig nicht virtualisierte Anwendungen betreiben, wie etwa Hochleistungsdatenbanken zur Transaktionsabwicklung. Führende Analysten gehen davon aus, dass diese Mischung aus virtualisierter und nicht virtualisierter Arbeitsverteilung in manchen Unternehmen bis mindestens zum Ende des Jahrzehnts zum Einsatz kommen wird. Im Rahmen von Planungen sollte dieser Punkt unbedingt berücksichtigt werden, da sich hieraus unmittelbare Auswirkungen auf die kurz- und langfristige technische Eignung der gewählten hyperkonvergenten Lösung wie auch deren Investitionserträge ergeben.
[...]

Ein wesentliches Kriterium einer hyperkonvergenten Infrastruktur ist die Mehrfachknoten-Architektur. Was gibt es hier zu beachten?

Thurnhofer: Hier kann man den Anwendern nur empfehlen, wirklich auf die Knoten-Architektur aufzupassen. Denn einige namhafte Anbieter von Server-Hypervisoren bieten hyperkonvergente Speichermodelle an, die bereits in der Grundausstattung mindestens drei (oder sogar mehr) Cluster-Knoten benötigen. Ein Knoten benötigt üblicherweise einen physischen Server, eine Lizenz für die Speichersoftware, Cluster-Software (ob als Teil eines Hypervisor-Software-Pakets, des Betriebssystems oder einer spezialisierten Drittanbieter-Software), Flash-Speichergeräte sowie eine Speichereinheit oder ein JBOD-System. Gemäß einem kürzlich veröffentlichten Bericht belaufen sich die Kosten pro Knoten für die hyperkonvergente Software eines führenden Hypervisor-Anbieters (auch bekannt unter der Produktbezeichnung »vSAN«) auf 8.000 bis 11.000 US-Dollar für die Software-Lizenzen und auf 8.000 bis 14.000 US-Dollar für die Server- und Speicher-Hardware. Diese Zahlen sind dann mit der Anzahl der Knoten zu multiplizieren, die für den Aufbau einer hyperkonvergenten Infrastruktur erforderlich sind. Im Mindestfall sind dies drei Knoten, aber aus Gründen der Verfügbarkeit und der Leistung werden vier Knoten empfohlen. Darauf wollen wir auch nächste Woche auf der N-Tec Workshop-Tour deutlich hinweisen.

Im Gegensatz dazu erfordern hyperkonvergente Server-Speicher-Systeme von Datacore in der Grundausstattung lediglich zwei physische Knoten und ermöglichen zudem die Nutzung weniger kostenintensiver Hardware (beispielsweise SATA- statt SAS-Festplatten). Außerdem ist Flash bei uns eine Option als hochperformanter Primärspeicher, aber nicht zwingend erforderlich. Stattdessen nutzen wir ohnehin vorhandenen DRAM für das Caching, was erheblich schneller ist und die Anfangsinvestition in die Gesamtlösung deutlich senkt, ohne einen Wachstumspfad für Flash zu verbauen.



Keine Kommentare: