White Paper Hyper-konvergente Systeme im Vergleich · 2015-11-19 · Hyper-Converged Fujitsu atlantis EMC2 Gluster hp nexenta pernixdata redhat Scale iO SUSE Windows Server Software-Based

White Paper Hyper-konvergente Systeme im Vergleich

Seite 1 von 12 www.fujitsu.com/de/EVORAIL

Einleitung 2Hyper-konvergente Infrastrukturen 3- Grundsätzlicher Aufbau und Unterscheidungsmerkmale 3- Installation und Betrieb 4- Ausfallsicherheit und Lastverhalten 5- Investitionen, Support und Lizenzierung 8- Skalierbarkeit, Performance und Energiebedarf 9Fazit 11

Inhalt

Hyper-konvergente Systeme finden bei der Weiterentwicklung von Rechenzentrumsinfrastrukturen zunehmend Beachtung. Dieses White Paper stellt verschiedene hyper-konvergente Lösungen und deren Funktionsweisen vor und diskutiert Unterschiede zwischen diesen.




VMware/Fujitsu NutanixScale Computing simplivity

Hyper-Converged

Fujitsuatlantis EMC2 Glusterhp nexenta

pernixdataredhatScale iOSUSEWindows Server

Software-Based

FujitsuDell EMC2 Hitachi

hpIBMNetApp

Traditional Storage

FujitsuCiscoFlexPod/NetAppVCE

Converged

Fujitsucoraidhpnimble storageTintri

Hybrid Arrays

FujitsuSanDiskFusion iONimbusdataEMC2

violin MemoryXtremIOPURESTORAGEWHIPTAIL

All Flash Arrays

Einleitung

Um Rechenzentren entsprechend den geschäftlichen Anforderungen weiterzuentwickeln, bietet der Markt verschiedenste Konzepte. Dieses White Paper konzentriert sich auf das Konzept der hyper-konvergenten Infrastruktursysteme. Charakteristisch für diese ist, dass alle erforderlichen Technologien nahtlos integriert und wie ein einziges System verwaltet werden. Hyper-konvergente Systeme verschmelzen somit, wie wir im nachfolgenden noch detaillierter sehen werden, bisherige Konzepte wie Converged, Traditional Storage und Software-Based zu einem sogenannten Serverized; also serverbasierten und technologisch abgestimmtem System. Auch sind mit entsprechenden Softwarenversionen zunehmend sogenannte All Flash-Systeme möglich, welche die Leistung einer hyper-konvergenten Infrastruktur nochmals anheben.

Die Grundidee dahinter ist somit einen Gerätetyp (Server) in unterschiedlicher Ausprägung und dessen Ressourcen Compute, Storage und Network zu nutzen. Benötigt man mehr Ressourcen, werden einfach weitere serverbasierte Systeme hinzugefügt. Man bezeichnet dies als sogenanntes Scale-Out-Scenario. Der deutliche Mehrwert besteht dabei aus Investi-tions- und Kostenvorteilen aufgrund von verringerter Komplexität und deutlich niedrigeren (auch Personal-)Aufwänden, die aus Installation, Betrieb und Wartung inklusive den hierfür notwendigen Services resultieren.

Nachfolgend werden die verschiedenen Architekturen für hyper-konvergente Infrastrukturen dargestellt und Unterschiede zwischen diesen herausgearbeitet.

Beispiele für Konzepte und Anbieter von Technologien für die Weiterentwicklung von Rechenzentren. (Unvollständige Auflistung, die lediglich der Orientierung dienen soll)



Lösung als Aufsatz auf bestehendem HypervisorAus Sicht des Hypervisors ist der sogenannte Controller des jeweili-gen Anbieters eine virtuelle Maschine (VM), die wie jede andere VM betrieben wird; mit allen Vor- und Nachteilen. Hierbei ist der Controller für die I/O-Operationen der virtuellen Maschinen zustän-dig; die Kommunikation zwischen Controller und Hypervisor erfolgt über vom Hypervisor festgelegte Schnittstellen. Durch dieses Konst-rukt ergibt sich prinzipiell der Vorteil eines leichteren Wechsels des Hyper-visors, ohne die grundsätzliche Tech-nologie in Frage stellen zu müssen.

Lösung integriert in den HypervisorDie I/O-Kontrolle ist existenzieller Bestandteil des Hypervisors (sog. Kernel) und unterliegt keinen Restriktionen, die vom Hypervisor gegenüber VMs in Bezug auf die Ressourcennutzung ausgeübt werden. Einen Controller als zusätzliche VM gibt es somit nicht. In Bezug auf Stabilität und Antwortzeitverhalten bietet diese Lösung aufgrund der hohen Integration die besten Vor-aussetzungen für den täglichen Betrieb.

Erweiterungen des Hypervisors im VergleichEine hyper-konvergente Infrastruktur besteht typischerweise aus 3 Basis-komponenten:

1. Die HardwareBasierend auf Standard-Servertechnologien kommen entsprechend ausgestattete serverbasierte Systeme zum Einsatz, welche für die Virtualisierung die Ressourcen Compute (CPU & Memory), Capacity (Plattenplatz) und Network (LAN-Adapter) zur Verfügung stellen. Die Geschwindigkeit der Netzwerkadapter liegt typischerweise bei 10 GBit/s, was auch im Netzwerk (Switches) berücksichtigt werden muss. Ge-schwindigkeiten unter 10 GBit/s werden herstellerseitig häufig nicht unterstützt und sind aus konzeptioneller Sicht auch nicht sinnvoll.

2. Der HypervisorDer Hypervisor ist die Basis für die Virtualisierung – die Plattform, die die Gastsysteme (virtuelle Maschinen) unter Berücksichtigung der vorhandenen Hardwareressourcen bedient. Typische Hypervisoren sind beispielsweise ESXi von VMware, Hyper-V (Microsoft) und KVM (Open Source/GPL).

3. Die Software zur Hyper-KonvergenzHierbei handelt es sich entweder um Erweiterungen des Hypervisors, die ein Hypervisor-Anbieter direkt vornimmt und integriert, oder um auf den Hypervisor aufgesetzte Module von Drittanbietern, die sich der gegebenen Schnittstellen des Hypervisors bedienen (müssen). Grundsätzlich hat ein Hersteller, der gleichzeitig Anbieter eines eigenen Hypervisors ist, weitaus mehr Möglichkeiten, zukünftige Entwicklungen zu gestalten und im Hypervisor zu berücksichtigen. Als Drittanbieter ist man dagegen auf vorhandene Schnittstellen angewiesen oder muss versuchen, sich im Open Source-Umfeld zu bedienen, um eigene Ent-wicklungen vornehmen zu können.

Hyper-konvergente Infrastrukturen Grundsätzlicher Aufbau und Unterscheidungsmerkmale

Eine direkt in den Hypervisor integrierte Lösung ist das FUJITSU Integrated System PRIMEFLEX for VMware EVO:RAIL, nachfolgend kurz EVO:RAIL genannt. EVO ist hierbei der Familienname und RAIL die Bezeichnung des Produktes. Aktuell verfügbar ist RAIL; RACK haben Fujitsu und VMware auf VMware-Partnermessen bereits als technische Vorschau präsentiert. Es handelt sich bei diesen Lösungen – in Verbindung mit den bereits seit Jahren etablierten VMware-Produkten – um ein Familienkonzept, das kontinuierlich ausgebaut wird.

Controller (I/O; VM)

Hypervisor

Hardware

CPU

RAM

SAS Controller

SSD

SSD

HD

D

HD

D

HD

D

HD

D

Abbildung 1

Hypervisor

I/O Control

Hardware

CPU

RAM

SAS ControllerSS

D

SSD

HD

D

HD

D

HD

D

HD

DAbbildung 2



Zu den Stärken von EVO:RAIL zählen die schnelle Installation, der verein-fachte Betrieb und die vereinfachte Wartung des Systems. VMware hat dazu einen Software-Stack entwickelt, der nur für EVO:RAIL zur Verfügung steht: die sogenannte EVO:RAIL Engine.

Die Installation wird mit dieser Software extrem vereinfacht. Die Ein-richtung einer IT-Infrastruktur zur Virtualisierung von Serversystemen und Desktops – inklusive Einbindung in die Unternehmens-ADDS und DNS-Dienste sowie Montage des Servers im Rack – ist in weniger als einer Stunde möglich; ein konfiguriertes Netzwerk vorausgesetzt.

Darüber hinaus stellt EVO:RAIL umfangreiche Software-Funktionen bereit, die bei folgenden, wichtigen Aufgaben unterstützen:

■ Monitoring der Appliance■ Aktualisierung des Systems■ Maintenance (auch dem Austausch von Hardwarekomponenten)■ Einfache und schnelle Bereitstellung von virtuellen Systemen

(VMs und VDIs)

All diese Funktionalitäten ermöglichen es beispielsweise dem Operating, Installation, Betrieb und Wartung selbstständig durchzuführen, während sich die Administratoren auf geschäftskritische Themen konzentrieren können.

Vergleicht man EVO:RAIL mit den Lösungen anderer Anbieter, dann zeigt sich: Auch andere Appliances können im Prinzip in wenigen Schritten installiert und betriebsbereit gemacht werden. Meistens sind allerdings weit mehr und komplexere Schritte erforderlich. Allein die Tatsache, dass bei Produkten anderer Anbieter häufig der VMware-Hypervisor zusätzlich betriebsbereit vorzuinstallieren ist, erhöht den Aufwand dafür nicht unerheblich. Die Installation muss dann vom Kunden selbst oder über Partner des Drittanbieters durchgeführt werden, wenn der vorgesehene Hypervisor von VMware kommen soll.

Installation und Betrieb

Abbildung 3: Ist die Appliance installiert und das Netzwerk konfiguriert, kann mit EVO:RAIL 15 Minuten nach dem Einschalten die erste VM installiert werden.

• Installiert• Verkabelt• Eingeschaltet

EVO:RAIL

Physical EVO:RAILAppliance Deployment

Basic Appliance Configuration:Hostnames, IP Address Pools, Globals und Passworte

EVO:RAIL enginekonfiguriert vCenter, ESXi, Virtual SAN & Log Insight

Ready for VMs!

Configure EVO:RAIL

Hostnames ESXi Hosts

VM Networks

Networking

Passwords Virtual SAN

Globals vCenter Server

Navigate between configuration

Configure networking for ESXi

Starting address for IP pool

192.168.10.1

Netmask

255.255.255.0

VLAN ID

Building EVO:RAIL

96%

vmwareEVOR A I L What size VM do you want?What size VM do you want?

Medium

Small

Large

Ideal for dedicated,larger serverapplications likedatabasees

32 GB

4 Processors

6 GB

1 Core

RAM



Ausfallsicherheit und Lastverhalten

Ein weiterer signifikanter Vorteil einer integrierten Lösung wie EVO:RAIL besteht im täglichen Betrieb in der Handhabung von gewollten oder ungewollten Zuständen. Dazu zählen beispielsweise der Umzug einer virtuellen Maschine auf einen anderen Knoten (Server bzw. auch Node genannt) oder das automatische Auslösen eines solchen Vorganges durch eine Fehlersituation.

Dabei verhält sich beispielsweise VSAN als der grundlegende Speicher-ort (sog. Distributed Objectstore; also der Ort, an dem virtuelle Systeme oder Daten liegen) von EVO:RAIL entsprechend lastneutral. Abbildung 4 zeigt, wie VSAN die Daten auf anderen Knoten (Servern) verteilt, um Redundanz und stabile Antwortzeiten zu gewährleisten.

Zu beachten ist, dass der Zugriff über das Netzwerk häufig performanter erfolgt als über lokale SSDs oder HDDs. Gerne wird hier von Mitbewer-bern das Thema Latenz (Verzögerung zwischen zwei I/O-Prozessen) ins Spiel gebracht, die im Netzwerk gegebenenfalls höher sein kann als auf einer SSD. Dazu muss festgestellt werden, dass auch die virtuelle Maschine (Controller genannt) einer aufgesetzten Lösung eine Latenz hat. Diese ist ebenso zu berücksichtigen und kann je nach Situation und Hersteller erheblich sein.

Die abgebildete „Storage witness“ hat übrigens die Aufgabe, im Falle eines sogenannten Split-Brain (also der ungewollten Trennung zwischen den Knoten durch beispielsweise den Ausfall von Netzkomponenten) zu entscheiden, welcher der verbliebenen, getrennten Speicherorte weiterhin als aktiver Speicherort verwendet werden soll.

Fällt nun ein Knoten aus (z. B. ESXi 2 in Abbildung 4), dann werden die Daten weiterhin vom verbliebenen Knoten ESXi3 zur Verfügung gestellt und der Ausfall gemeldet. Das System läuft weiter und toleriert den Ausfall für z. B. eine Stunde; in dieser Zeit sollte das System einer Diagnose unterzogen werden. Erst danach werden vom System Maß-nahmen ergriffen, um die Redundanz wiederherzustellen. Dieses Ver-halten ist ähnlich dem eines herkömmlichen Storage-Systems.

Abbildung 5 stellt dies dar: Zu sehen ist das Lastverhalten einer virtuellen Maschine mit VSAN, während diese online verschoben wird (per vMotion). Es ist dabei kein Einbruch des Lastverhaltens erkennbar.

Distributed I/O

~50% of I/O ~50% of I/O

UserVM(s)

Storagewitness

(multiple with policy >1)

Storage

vSANESXi 1 vSANESXi 2 vSANESXi 3 vSANESXi 4

StorageVMDK

StorageVMDK

Abbildung 4

vMotion

Konsistente Performance trotz Umzugs der VM

Zeit

Durchsatz

vMotion

Abbildung 5



Integrierten Lösungen wie EVO:RAIL gegenüber stehen Konzepte von Drittanbietern mit Modulen, die auf dem Hypervisor aufsetzen. Hierbei wird sehr häufig der Ansatz gewählt, dass die Daten einer virtuellen Maschine sich auch physisch auf dieser Maschine befinden sollen. Man bezeichnet dies auch als Data Locality. Entsprechend aufwändig stellt sich der Prozess dar (siehe Abbildung 6).

Aufgrund der Vorgabe der lokalen Datenhaltung ist das System ge-zwungen, bei einem Umzug der virtuellen Maschine auch die Daten umzuziehen bzw. sicherzustellen, dass benötigte Daten sich auf den lokalen Festplatten befinden. Um die Lastspitzen über das Netz ent-sprechend abzufedern, werden die Daten daher häufig erst dann kopiert, wenn sie wirklich benötigt werden; typischerweise also beim Lesezugriff.

Abbildung 7 gibt dies schematisch wieder; deutlich sichtbar ist das Nachlassen der Workload-Performance. Hierin besteht ein signifikan-ter Unterschied zwischen Lösungen von VMware und denen anderer Anbieter. Es ist daher ratsam, sich vor einer Entscheidung für einen bestimmten Hersteller die Auswirkungen eines solchen Falles auf die eigentliche Produktivumgebung deutlich zu machen und ausgiebig zu testen.

Abbildung 7

Abbildung 6

Workload Performance ist reduziert

Zeit

Durchsatz

Nach Wiederherstellung des Originalzustandesweiterhin Degradierung der Performance

vMotion

vMotion

vSphere

Controller VM (Distributed File System)

Storage

vSphere

Controller-VM

1. Normal VM I/O 3a. Resume I/O

UserVM(s)

UserVM(s)

2. Migration or HA event

StorageController-VM

3b. New data iswritten locally

4. Data movement for I/O localityDone on read for efficiency Pre-existing (now local) VM data will not be moved



vSphere Virtualization Layer

VMI/O

Controller (Virtual Appliance)

10 GB/s Local Area Network

Storage I/O

Storage I/O

Network I/O

vSphere Virtualization Layer

VMI/O VMware

10 GB/s Local Area Network

Storage I/O

Storage I/O (vSAN)

Network I/O

Ein weiterer, aus unserer Sicht wichtiger Aspekt: Bei einer Lösung, die auf einen bestehenden Hypervisor aufsetzt, unterliegt der sogenannte Controller als letztlich virtuelle Maschine allen Steuerungsmechanismen – und somit auch Restriktionen – des darunter liegenden Hypervisors. Dies ist auch logisch, denn dieser muss dafür Sorge tragen, dass die Ressourcen der technischen Plattform (Serverknoten) somit allen vir-tuellen Gastsystemen zur Verfügung stehen (siehe Abbildung 8).

Abbildung 8

Dies bedeutet aber auch, dass im Falle einer höheren Last der sog. Controller mehr Aufgaben erledigen muss. Zu erwarten ist, dass der Hypervisor (bzw. dessen sog. Scheduler-Prozess) ab einem bestimmten Zeitpunkt Limitierungen vornehmen muss, damit die vorhandene technische Ressource allen virtuellen Maschinen zugänglich bleibt. Konkret bedeutet dies, dass die Ressourcen pro virtueller Maschine reduziert bzw. die Leistung gedrosselt werden muss, um die Lauffähig-keit noch sicherstellen zu können. Prüfen Sie daher diesen Aspekt

intensiv insbesondere unter dem Aspekt des tatsächlich geplanten Endausbaus unter hoher Last und rechnen Sie die dann vermutlich benötigten Hardwarekomponenten entsprechend hoch.

Läuft ein solches System produktiv, sind weitere Änderungen im Zweifel nur durch Anschaffung weiterer Komponenten machbar. Somit können sich mit der Zeit die Aufwände für Investitionen und laufende Kosten deutlich schlechter darstellen, als ursprünglich kalkuliert.

Bei EVO:RAIL ist dieser Mechanismus in den Kern der Software inte-griert und unterliegt keinem direkten Verteilungsprozess, der sich um die Hardwareressourcen kümmern muss (siehe Abbildung 9). Daraus ergibt sich für Kunden ein wichtiger Vorteil in Bezug auf die Skalierbarkeit.

Auch sollte man sich die tatsächlichen Aufwände für Installation, Betrieb und Wartung ansehen und die bisherige IT-Landschaft in die Betrachtung mit einbeziehen. Denn die Technologie als solche ist (verglichen beispielsweise mit traditionellen Ansätzen wie Server-Netzwerk-Storage als eigene Systeme) noch verhältnismäßig jung. Insofern betreiben die Hersteller entsprechend viel Marketing, um die Produkte, deren Leistungsfähigkeit und Funktionalitäten heraus-zustellen. Anders ist dies bei EVO:RAIL. Hier werden ausgereifte, seit Jahren im Produktivbetrieb bewährte Softwarelösungen wie vSphere® und vCenter®, ergänzt um neue Module wie die EVO:RAIL Engine, eingesetzt.

Schauen Sie sich daher die Funktionen in Ruhe an und prüfen Sie auch, welche Entwicklungen geplant sind und wie valide dieser Zeitplan für Ihr Business tatsächlich ist oder ob es sich dabei eher um Ankündi-gungen handelt, welche erst zukünftig verfügbar sein werden. Lassen Sie sich die geplanten Funktionalitäten bestätigen, sodass Sie eine valide IT-Strategie in Bezug auf Software-definierte Lösungen aufbauen können.

Abbildung 9



Ein weiterer Vorteil einer in den Hypervisor integrierten Lösung besteht in den notwendigen Investitionen für Technik, Softwarelizenzen und den Kosten für die Wartung.

Investitionen, Support und Lizenzierung

Aufsatz auf HypervisorBei einer auf einem bestehenden Hypervisor, z. B. VMware, aufgesetzten Lösung sieht dies beispielsweise in der Regel wie in Abbildung 10 dar-gestellt aus.

WICHTIG: Häufig obliegt es dem Kunden (Anwender) zu entscheiden, welche Komponenten entsprechend wie zu handhaben sind; beispiels-weise, ob er im Support-Fall die Aussteuerung der beteiligten Partner im Zweifel selbst vornimmt bzw. anstößt. Dies setzt möglicherweise entsprechende Organisationsstrukturen und Kenntnisse voraus.

Hypervisor-integrierte LösungIm Gegensatz dazu wird bei einem integrierten Konzept der Vorteil reduzierter Aufwände für Support, Lizenzen und Wartung sofort er-sichtlich (siehe Abbildung 11).

Fujitsu stellt in diesem Fall aus Kundensicht den Single Point of Contact (SPoC) dar, um den Aufwand für Support und Wartung zu minimieren und zu vereinfachen. Dies hilft, die auf Kundenseite notwendigen Organisationsstrukturen optimal und effektiv zu gestalten.

VMware

SupportLizenzenWartung

3rd Party Software Vendor

SupportLizenzenWartung

3rd Party Hardware Vendor

SupportWartung

Controller (I/O; VM)

Hypervisor

CPU

Hardware

SAS Controller

SSD SSD HDD HDD HDD HDD

RAM

Abbildung 10

Fujitsu und VMware

Support, SPOC FujitsuLizenzenWartung

Hypervisor

I/O Control

CPU

Hardware

SAS Controller

SSD SSD HDD HDD HDD HDD

RAM

Abbildung 11



Jede EVO:RAIL-Appliance besteht aus 4 Knoten und kann für bis zu 100 virtuelle Server (VMs) bzw. 250 virtuelle Desktops (VDIs) genutzt werden (Abbildung 12). Die Angaben verstehen sich als Leitfaden, die VMware basierend auf Erfahrungswerten und Kundeninformationen errechnet hat. Die exakte Anzahl hängt von der tatsächlichen Größe der jeweiligen virtuellen Server und Desktops ab.

Fujitsu liefert EVO:RAIL von Anfang an mit dem neuen, performanteren Haswell-Prozessor von Intel® und zählt damit zu den technologisch führenden Anbietern. Die Skalierung von EVO:RAIL erfolgt durch Hinzu-nahme weiterer Appliances – bis zu 8 Appliances bzw. 32 physische Knoten können miteinander als Cluster verschaltet werden. Die Appli-ance skaliert linear, sodass EVO:RAIL in der aktuell höchsten Ausbau-stufe für bis zu ca. 2.000 VDIs bzw. 800 VMs geeignet ist. Zu erwarten ist, dass mit Einführung von vSphere 6 und VSAN 6 die Skalierungs-grenze auf 64 Knoten und damit den maximal möglichen Ausbau bei VSAN 6 angehoben wird. Entsprechend erhöht sich dann auch die Zahl der möglichen VDIs und VMs pro Cluster.

Auch andere Anbieter bieten Lösungen mit 32 Knoten oder mehr an. Vergleichen Sie vor einer Kaufentscheidung neben der grundsätzlichen Technologie (integrierte oder aufgesetzte Lösung) deshalb zumindest auch folgende Parameter:

■ Maximal (sinnvoll) skalierende Anzahl an Knoten pro Cluster■ Anzahl möglicher virtueller Server und Desktops■ Größe des Arbeitsspeichers je Knoten■ Typ des Prozessors■ Netzwerkanbindung■ Möglichkeit der Einbindung existierender Speichersysteme

Insbesondere in Bezug auf den letzten Punkt sehen wohl einige Her-steller keine Notwendigkeit mehr für den Einsatz traditioneller Speicher-systeme wie z. B. SAN oder NAS. Wir von Fujitsu glauben, dass es trotz der dynamischen Entwicklung in Richtung Software-definierter Lösungen in der Praxis auch künftig häufig Anwendungen wie etwa Datenbanken geben wird, die zentrale Speichersysteme benötigen. Deshalb sind wir der Ansicht, dass diese auch weiterhin integriert werden müssen.

Skalierbarkeit, Performance und Energiebedarf

Abbildung 12

2HE 4-Knoten-Hardwareplattform, optimiert für EVO:RAIL

Designed für 250 VDIs bzw. 100 VMs pro Appliance

VDI-Spezifikationen: 2 vCPU, 2 GB vMEM, 30 GB vDisk

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VDI

VM-Spezifikationen: 2 vCPU, 6 GB vMEM, 60 GB vDisk

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM

VM



Fujitsu betreibt selbst weltweit über 150 Rechenzentren; die Heraus-forderungen im täglichen Betrieb sind uns deshalb bestens bekannt. Kunden profitieren von diesen Erfahrungen bei der Optimierung der Prozesse in ihren eigenen Rechenzentren. Neben den Themen Energie-effizienz und Automation gehört dazu auch die Unterstützung von Not-fallmanagern mit automatisierten Notfallprozessen gemäß ITIL-Standard. Mit solchen automatisierten Notfallhandbüchern optimieren bereits heute viele unserer Kunden den Betrieb in ihren Rechenzentren und minimieren die Auswirkungen von ungeplanten Ausfällen schnell und effektiv.

Auch hierfür bietet Fujitsu ein entsprechende Assessment an, um interessierte Kunden bestmöglich zu unterstützen.

Alles das gilt auch für Software-definierte Lösungen und insbesondere dann, wenn der Systembetrieb mit Rund-um-die-Uhr-Verfügbarkeit erfolgen soll.

2010/2011 2012 2013 2014 Cores

24

32

40

48

60

64

72

80

96

120

128

144

160

240

512

Fujit

suO

ther

s

VMmark 2.x Benchmark

2015

288

Abbildung 13

Ein weiterer wichtiger Aspekt im Hinblick auf Skalierbarkeit ist die Performance. Wussten Sie, dass Fujitsu im wichtigen VMmark-Benchmark im Hinblick auf Cloudpower und Virtualisierung weltweit führend ist (siehe Abbildung 13)? Im Vergleich zu anderen Herstellern bedeutet das für unsere Kunden: Mehr Leistung bei gleicher Ausstattung.

Gleichzeitig bieten wir unseren Kunden äußerst energieeffiziente Systeme, die regelmäßig Top-Positionen in angesehenen Benchmarks belegen, und dies seit Jahren. Die technische Plattform von EVO:RAIL macht hier als „Made in Germany“-Produkt keine Ausnahme.

Vor allem steigende Energiekosten machen für Betreiber von Rechen-zentren das Energiemanagement zu einem Top-Thema; Kostensenkung ist hier seit Jahren das Gebot der Stunde.

Über die technische Architektur hinaus (die auch bei EVO:RAIL eine wichtige Rolle spielt) bietet Fujitsu daher auch Energiemanagement-Lösungen für die Messung und Optimierung der Energieeffizienz von Rechenzentren an. Diese Lösungen umfassen:

■ Herstellerneutrale Identifizierung (Energie-Assessment) energetisch ineffizienter Systeme im laufenden Rechenzentrumsbetrieb

■ Basierend auf diesen Messergebnissen: Entwicklung eines Maß-nahmenkatalogs für die Senkung der Betriebskosten bzw. die signifi-kante Verbesserung der Energieeffizienz

■ Zusätzliche Kostensenkung und Effizienzsteigerung durch Management und Automation der Rechenzentren

Weiterführende Informationen: http://www.fujitsu.com/de/Energiemanagementhttp://www.fujitsu.com/de/Notfallhandbuch

Stand: 07/2015



Fazit

Wir sehen „Software-definiert“ als ein Konzept mit großer Perspektive und Zukunft an. Es erfordert aus unserer Sicht jedoch auch eine Strategie für IT-Entscheidungen und Geschäftsprozesse, die über das reine „Zusammenstecken“ einzelner, serverbasierter Module hinausgeht.

Nicht die technologischen Möglichkeiten allein, sondern vor allem die Ge-schäftsanforderungen werden zukünftig immer stärker die Auswahl und den Einsatz von Technologien bestimmen. Software-definiert als Konzept hilft hierbei, IT-Herausforderungen durch Standardisierung der Technologie und mit hoher Flexibilität, das heißt schneller Anpassbarkeit an die Geschäfts-prozesse, zu meistern.

Praktisch gesehen bedeutet das: Installationen in Stunden statt Tagen, einfa-ches Hinzufügen statt neuem Design oder auch die Umsetzung übergreifender Plattformkonzepte unter einer Software-basierten Schicht mit geringerem Aufwand als heute, wird im Rechenzentrumsbetrieb der künftige Standard werden. Ausgehend vom bekannten VMware Software-Stack sind EVO:RAIL und das als technische Vorschau präsentierte EVO:RACK hierfür wegweisend.

Kurzum: Das tägliche Business wird künftig nicht nur durch eine einzelne Lösung, sondern das effiziente Zusammenspiel verschiedener Technologien sinnvoll und effektiv unterstützt werden. Familienkonzepte auf Basis effizienter Technologien – wie zum Beispiel VMware-Lösungen – spielen hierbei eine entscheidende Rolle.

Wir nennen dies das Business-Centric Data Center.



Fujitsu und das Fujitsu Logo sind Marken oder eingetragene Marken von Fujitsu Limited in Japan und anderen Ländern. Andere Firmen-, Produkt- und Servicebezeichnungen können Marken oder eingetragene Marken der jeweiligen Eigentümer sein. Änderungen bei den technischen Daten vorbehalten. Lieferung unter dem Vorbehalt der Verfügbarkeit. Haftung oder Garantie für Vollständigkeit, Aktualität und Richtigkeit der Daten und Abbildungen ausgeschlossen. Wiedergegebene Bezeichnungen können Marken und/oder Urheberrechte der jeweiligen Hersteller sein, deren Benutzung durch Dritte für eigene Zwecke die Rechte der Eigentümer verletzen kann.

Herausgegeben durchFujitsu Technology SolutionsCopyright © 2015 Fujitsu Technology SolutionsBestell-Nr.: 10939-8-0715-DE

www.fujitsu.com/de/EVORAIL

FUJITSU Integrated System PRIMEFLEX for VMware EVO:RAIL

Documents

White Paper Hyper-konvergente Systeme im Vergleich · 2015-11-19 · Hyper-Converged Fujitsu atlantis EMC2 Gluster hp nexenta pernixdata redhat Scale iO SUSE Windows Server Software-Based