HOHE VERFÜGBARKEIT, DATENSCHUTZ UND INTEGRITÄT DER DATEN IN DER XtremIO-ARCHITEKTUR

White Paper HOHE VERFÜGBARKEIT, DATENSCHUTZ UND INTEGRITÄT DER DATEN IN DER XtremIO-ARCHITEKTUR Zusammenfassung Eine wichtige Funktion eines Speichersystems der Enterprise- Klasse ist es, Daten auf sichere und zuverlässige Weise zu hosten. Das Speichersystem muss kontinuierlichen, ununterbrochenen Zugriff auf die Daten ermöglichen, strenge Performanceanforderungen erfüllen und erweiterte Funktionsmerkmale zur Optimierung des Betriebs und Vereinfachung des Datenmanagements bieten. In diesem White Paper werden hohe Verfügbarkeit, Datensicherheit und Datenintegrität definiert. Zudem wird erläutert, wie das einzigartige Hard- und Softwaredesign von XtremIO es ermöglicht hat, eine Betriebszeit und Ausfallsicherheit von 99,999 % zu übertreffen. In diesem Dokument werden auch das Monitoring, die Redundanzstufen, die Integritätsprüfungen und die hohe Flexibilität der Architektur zum Aufrechterhalten der Systemperformance und Verfügbarkeit durch die Anpassung an Ausfälle beschrieben. April 2015

Copyright 2015 EMC Corporation. Alle Rechte vorbehalten. EMC ist der Ansicht, dass die Informationen in dieser Veröffentlichung zum Zeitpunkt der Veröffentlichung korrekt sind. Diese Informationen können jederzeit ohne vorherige Ankündigung geändert werden. Die Informationen in dieser Veröffentlichung werden ohne Gewähr zur Verfügung gestellt. Die EMC Corporation macht keine Zusicherungen und übernimmt keine Haftung jedweder Art im Hinblick auf die in diesem Dokument enthaltenen Informationen und schließt insbesondere jedwede implizite Haftung für die Handelsüblichkeit und die Eignung für einen bestimmten Zweck aus. Für die Nutzung, das Kopieren und die Verbreitung der in dieser Veröffentlichung beschriebenen Software von EMC ist eine entsprechende Softwarelizenz erforderlich. Eine aktuelle Liste der EMC Produktnamen finden Sie im Abschnitt zu Marken der EMC Corporation auf germany.emc.com. EMC2, EMC, das EMC Logo und das RSA-Logo sind eingetragene Marken oder Marken der EMC Corporation in den USA und anderen Ländern. VMware ist eine eingetragene Marke von VMware, Inc. in den USA und anderen Ländern. Alle anderen in diesem Dokument erwähnten Marken sind das Eigentum ihrer jeweiligen Inhaber. Copyright 2014 EMC Deutschland GmbH. Alle Rechte vorbehalten. Veröffentlicht in Deutschland Artikelnummer H13693-01 (Version 02) 2

Inhaltsverzeichnis Zusammenfassung... 4 Einführung... 5 Zielgruppe... 5 Hohe Verfügbarkeit... 6 Datenintegrität... 7 Die Architektur von XtremIO... 8 Hardwarearchitektur... 8 Softwarearchitektur... 11 Infrastrukturmodul... 11 Systemweites Managementmodul (SYM)... 11 Plattform-Manager-Modul... 12 I/O-Module... 13 Routing-Modul... 13 Steuerungsmodul... 13 Datenmodul... 14 Neustart von Modulen... 14 I/O-Fluss... 15 Sicheres verteiltes Journaling... 16 Unabhängige Software- und Hardwaremodule... 18 Konnektivitätsredundanz... 19 End-to-End-Verifizierung... 21 Hardwareverifizierung... 21 Kryptografischer Datenfingerabdruck... 22 Getrennte Nachrichtenpfade... 22 Fehlervermeidung, -erkennung und -begrenzung... 23 Serviceorientierte Architektur... 23 Fehlererkennung... 23 Erweiterte Fehlerkorrektur... 24 Unterbrechungsfreie Upgrades... 25 XtremIO-Betriebssystem (XIOS)-Upgrades... 25 Komponentenfirmware- und Linux-Kernel-Upgrades... 25 Online-Clustererweiterung... 25 Wiederherstellbarkeit des Systems... 26 Verlust der XMS-Kommunikation... 26 Verlust der Kommunikation zwischen Speicher-Controllern... 27 Fazit... 28 Weitere Informationen... 28 3

Zusammenfassung Ein wichtiges Ziel jedes Enterprise-Speichersystems ist es, Daten auf sichere und zuverlässige Weise zu hosten. Das Speichersystem muss kontinuierlichen, ununterbrochenen Zugriff auf die Daten ermöglichen, strenge Performanceanforderungen erfüllen und erweiterte Funktionsmerkmale zur Optimierung des Betriebs und Vereinfachung des Datenmanagements bieten. Ein Enterprise-Speichersystem liefert die beste Ausfallsicherheit und hat keine Single-Point-of-Failure, während es die Daten bei nahezu jedem denkbaren Ausfall schützt. In Hinblick auf den Ausfall von Komponenten muss das System auch hohe Servicelevel bereitstellen. Selbst spezialisierte Speichersysteme bauen auf Software- und allgemeinen Computerkomponenten auf, die allesamt ausfallen können. Manche Fehler sind sofort ersichtlich, wie beispielsweise der Ausfall einer Festplatte oder SSD. Andere können subtil sein, z. B. nicht genügend Arbeitsspeicher, was zu Performanceproblemen führt. Damit bei derartigen Ausfällen für hohe Verfügbarkeit und Datenintegrität gesorgt ist, bauen die besten Speichersysteme auf einer Architektur auf, die den I/O-Fluss solange aufrecht erhält, wie die Datensicherheit nicht gefährdet ist. Diese Systeme führen zudem verschiedene Datenintegritätsprüfungen aus, die allgemein für die Systemperformance optimiert sind. In diesem White Paper werden hohe Verfügbarkeit, Datensicherheit und Datenintegrität definiert. Zudem wird erläutert, wie das einzigartige Hard- und Softwaredesign von XtremIO es ermöglicht, eine Betriebszeit und Ausfallsicherheit von 99,999 % zu übertreffen. In diesem Dokument werden auch das Monitoring, die Redundanzstufen, die Integritätsprüfungen und die hohe Flexibilität der Architektur zum Aufrechterhalten der Systemperformance und Verfügbarkeit durch die Anpassung an Ausfälle beschrieben. 4

Einführung Die Systemarchitektur von XtremIO ist vollständig auf die Bereitstellung kontinuierlicher Verfügbarkeit ausgelegt. Das Array besitzt keinen Single-Pointof-Failure und bietet Sicherheit der Enterprise-Klasse, damit für die Daten auch in Katastrophenfällen kein Risiko besteht. Dank eines Scale-out-Designs kombiniert mit einer serviceorientierten und modularen Softwarearchitektur kann XtremIO als einheitliches System betrieben werden, das die Möglichkeit bietet, unabhängige Module bei unerwarteten Ausfällen der Hardware anzupassen. XtremIO hat sich bei über 1.000 Kunden in den anspruchsvollsten Enterprise Workloads mit einer Zuverlässigkeit von über 99,999 % bewährt, die sich in Kombination mit EMC VPLEX sogar noch auf 99,9999 % verbessert. Dank eines Scale-out-Designs kombiniert mit einer serviceorientierten und modularen Softwarearchitektur können XtremIO X-Bricks als einheitliches System betrieben werden, das die Möglichkeit bietet, unabhängige Module bei unerwarteten Ausfällen der Hardware anzupassen. Zielgruppe Dieses White Paper richtet sich an EMC Kunden, technische Berater sowie Partner und Mitglieder der Professional-Services-Community von EMC und EMC Partnern, die mehr über die XtremIO-Architektur wissen möchten, um hohe Verfügbarkeit, Datenintegrität und Datensicherheit zu erreichen. 5

Hohe Verfügbarkeit Bei einem System mit hoher Verfügbarkeit kann der jeweils bereitgestellte Service kontinuierlich und mit dem erwarteten Performancelevel bereitgestellt werden. Benutzer möchten, dass ihre Anwendungen zu jeder Zeit verfügbar sind. Zum Erreichen dieses Ziels ist ein hochverfügbares Speichersystem erforderlich. Ein gutes Design für hohe Verfügbarkeit hat genügend Redundanz, um zu verhindern, dass ein Single-Point-of-Failure die Nichtverfügbarkeit von Daten verursacht. Es muss auch genügend Redundanz zum Schutz gegen mehrere gleichzeitige Ausfälle bereitstellen. Enterprise-Speichersysteme müssen zudem so gestaltet sein, dass selbst unwahrscheinliche Ausfälle nicht zu einem physischen Datenverlust oder einer Datenbeschädigung führen. Die Fehlererkennung in Enterprise-Speichersystemen muss daher besonders leistungsfähig sein. Die Wiederherstellung einer ausgefallenen Komponente muss schnell und automatisch erfolgen oder es muss möglich sein, durch eine Änderung der Ressourcenzuweisung zu einem redundanten und ausgewogenen Status zurückzukehren. Werden beispielsweise zwei Array- Controller für die Bereitstellung von Daten genutzt und einer davon fällt aus, muss das System in der Lage sein, den I/O-Datenverkehr so schnell wie möglich über den verbleibenden Controller zu leiten. Es gibt zwei Arten von Redundanz: passive Redundanz und aktive Redundanz. Passive Redundanz stellt Zugriffskomponenten bereit, die sich im Leerlauf befinden und nicht funktionsfähig sind, es sei denn, die primäre Komponente fällt aus. Zwei Beispiele der passiven Redundanz in Enterprise-Speichersystemen sind aktive/passive Controller-Architekturen (bei denen ein Controller für die I/O genutzt wird und der andere Controller nicht, außer der Hauptcontroller fällt aus) und Hot-Spare -Laufwerke, die (innerhalb des Systems) als Ersatzlaufwerke designiert sind und den Betrieb erst bei Ausfall eines anderen Laufwerks aufnehmen. Passive Redundanz verursacht unnötigen Ressourcenbedarf und Kosten, da das System um zusätzliche Hardware erweitert werden muss, die jedoch nur selten zum Einsatz kommt. Bei der aktiven Redundanz bleiben alle Systemkomponenten aktiv und idealerweise wird die Last über die Komponenten verteilt. So kommt es zur besten Ressourcenauslastung und der Ausfall einer Komponente hat die geringsten Auswirkungen. Es ist sehr wünschenswert, ein aktives Redundanzsystem zu haben. Die Verfügbarkeit eines Speichersystems sollte beim Ausfall einer einzigen Komponente jederzeit sichergestellt sein, bei den besten Systemarchitekturen gehen jedoch auch keine Daten verloren, wenn es zu zwei Ausfällen gleichzeitig kommt. 6

Datenintegrität Die Hauptfunktion eines Enterprise-Speichersystems ist das zuverlässige Speichern von Benutzerdaten. Wenn ein Host Daten liest, muss das Speichersystem die richtigen Daten bereitstellen, die am entsprechenden Speicherort gespeichert werden. Die Datengenauigkeit muss beim Empfang der Daten vom Speichersystem und während der Verarbeitung im System verifiziert werden, bis die Daten auf das Back-end-Speichermedium geschrieben werden (End-to-End-Verifizierung). Zur Verifizierung, dass die Daten bei einem Lesevorgang korrekt sind, muss das System einen Fingerabdruck erstellen, der sich nach den gespeicherten Daten richtet, und diesen Fingerabdruck beim Lesen regelmäßig überprüfen. Der Fingerabdruck stellt sicher, dass die Daten weder bei der Übertragung (In Flight), noch während der Speicherung verändert wurden. Idealerweise sollte das Speichersystem voneinander unabhängige Speicherorte für die Daten und den Fingerabdruck verwenden. Dies reduziert die Wahrscheinlichkeit, dass eine einzelne Komponente die gleiche Auswirkung auf die Daten und den Fingerabdruck hat, was zu einer falschen Angabe führen könnte, dass die Daten intakt sind, selbst wenn dies nicht der Fall ist. Im schlimmsten Fall würde ein Speichersystem dem Host beschädigte Daten bereitstellen, ohne dass dies ersichtlich wäre. 7

Die Architektur von XtremIO Hardwarearchitektur XtremIO besteht aus X-Brick-Bausteinen. Ein hochverfügbarer Aktiv-Aktiv-X-Brick- Baustein verfügt über zwei voneinander unabhängige, fehlertolerante Speicher- Controller (Nodes). X-Bricks können zu Clustern vereinigt werden, um ein großes Scale-Out- System zu erstellen, das beim Hinzufügen weiterer X-Bricks linear in IOPSund Bandbreitenperformance und Kapazität zunimmt. Ein X-Brick-Baustein hat keinen Single-Point-of-Failure, wodurch die XtremIO-Cluster zunächst mit nur einem einzigen X-Brick eingerichtet werden. Jeder X-Brick-Baustein enthält zwei unabhängige Speicher-Controller und ein Array-Gehäuse für 25 SSD. Das Array-Gehäuse verfügt über zwei Serial Attached SCSI (SAS)-Controller mit zwei Verbindungen zu jedem Speicher-Controller. Jeder XtremIO-Cluster unterstützt mindestens zwei Batteriebackupeinheiten (BBU), damit noch ungespeicherte Daten bei einem Stromausfall so schnell wie möglich in den permanenten Speicher geschrieben werden können. Das gesamte XtremIO-Array basiert auf Standardkomponenten (zum Beispiel x86- Server, SSDs mit Standardformfaktor und herkömmliche Schnittstellenkarten), ohne dass proprietäre Hardware zum Einsatz kommt. Dank dieser Komponentenkombination kann XtremIO die hohe Qualität von Best-Of-Breed- Anbietern nutzen und von den allgemeinen Fortschritten der Komponentenzulieferer profitieren. Abbildung 1. XtremIO-Clusterhardware mit einem einzigen X-Brick-Baustein 8

Jeder XtremIO-Speicher-Controller und jedes Disk Array Enclosure ist mit zwei Netzteilen ausgestattet. Beide werden (gemäß bewährten Vorgehensweisen für die XtremIO-Installation) von zwei separaten Stromkreisen versorgt. Abbildung 2. Logisches Blockdiagramm der XtremIO-Hardware eines X-Brick-Bausteins Ein Cluster mit mehreren X-Brick-Bausteinen ist mit zwei InfiniBand-Switches ausgestattet. Zwei InfiniBand-Switches sind für Redundanz erforderlich und daher mit zwei separaten Stromkreisen verbunden. Jeder Speicher-Controller ist mit beiden InfiniBand-Switches verbunden. Die InfiniBand-Switches sind auch untereinander verbunden und bieten dadurch eine höhere Bandbreite und Redundanz. Abbildung 3. XtremIO-Hardware mit zwei X-Brick-Bausteinen 9

Abbildung 4. Logisches Blockdiagramm der XtremIO-Hardware mit zwei X-Brick-Bausteinen 10

Softwarearchitektur Die flexible Architektur von XtremIO sorgt dafür, dass jede Softwarekomponente auf jedem Speicher-Controller im Cluster ausgeführt werden kann. Durch diese Funktion wird ein unterbrechungsfreier Betrieb ermöglicht, selbst wenn ein Hardwarefehler auftritt. Die Softwarekomponenten in XtremIO werden Module genannt und alle XtremIO-Module werden im Benutzerbereich ausgeführt. Der zugrunde liegende Kernel basiert auf Linux. Die proprietäre Betriebsumgebung namens XtremIO OS (XIOS) ermöglicht die Planung und Nachrichtenübermittlung und stellt spezielle Dienstprogramme für die XtremIO-Module bereit. Es gibt sechs Hauptmodultypen innerhalb des Systems und mehrere Instanzen jedes Typs können unabhängig voneinander im System ausgeführt werden. Drei Modultypen sind Infrastrukturmodule, die für systemweites Management, Verfügbarkeit und Services für andere Module verantwortlich sind. Die anderen drei Modultypen sind I/O-Module, die für Datenservices mit der Array- und Host- Kommunikation verantwortlich sind. Infrastrukturmodul Systemweites Managementmodul (SYM) Das systemweite Managementmodul bietet einen umfassenden Überblick über die Hardware- und Softwarekomponenten. Es ist verantwortlich für die Verfügbarkeit des Systems und initiiert die Änderungen in der Systemkonfiguration, um eine maximale Verfügbarkeit und Redundanz zu erzielen. Das SYM-Modul legt fest, welche Module auf welchem Speicher-Controller ausgeführt werden, initiiert Failovers der Datenzuständigkeit von einem Speicher- Controller zu einem anderen sowie den erneuten Aufbau nach einem SSD-Ausfall. Ein einziges SYM-Modul ist die Einheit für aktives Management und die einzige Entität, die systemweite Entscheidungen zu jedem Zeitpunkt trifft. Fällt die Komponente, die das aktive SYM-Modul ausführt, aus, wird ein anderes SYM-Modul schnell aktiv und übernimmt diese Aufgaben. Eine zusätzliche Software-Logik wird auf jedem Speicher-Controller ausgeführt. Diese zusätzliche Software ist verantwortlich für die Überprüfung, dass ein, und nur ein, SYM im System aktiv ist. Dies ist ein einfacher Prozess, der die Möglichkeit ausschließt, dass kein laufendes SYM-Modul vorhanden ist. 11

Abbildung 5. Blockdiagramm der XtremIO-Speicher-Controller-Software Plattform-Manager-Modul Jeder Speicher-Controller verfügt über ein Plattform-Manager-Modul, das ausgeführt wird. Das Plattform-Manager-Modul ist verantwortlich für alle Aktivitäten im Speicher-Controller. Es überwacht die Integrität des Speicher- Controllers und kommuniziert diese an das SYM. Das Modul ist verantwortlich für die Überprüfung, ob alle Prozesse im Speicher-Controller ordnungsgemäß ausgeführt werden. Geplantes Herunterfahren und Neustarten des Moduls werden vom Plattform- Manager-Modul für das SYM-Modul ausgeführt. Das Plattform-Manager-Modul kommuniziert Hardwarefehler an das SYM-Modul. Es ermöglicht zudem das Replizieren (Journaling) wichtiger Datenstrukturen zwischen den Speicher- Controllern. Das Modul repliziert die Journalspeicher (Journal Memories) zwischen den Speicher-Controllern mithilfe von RDMA (Remote Direct Memory Access) über die InfiniBand-Fabric des Systems. Die Aktivität des Journaling ist wichtig für die Redundanz der Benutzer- und Systemmetadaten. Das Plattform-Manager-Modul initiiert das Herunterfahren des Speicher- Controllers nach der Erkennung eines Leistungsverlusts bzw. des vollständigen Verlusts der Kommunikation mit anderen Speicher-Controllern. 12

I/O-Module Die I/O-Module sind für die Speicherung der Daten von Hosts und das Abrufen der Daten auf Anfrage zuständig. Ein I/O-Modul wird auf jedem Speicher-Controller ausgeführt. Das SYM legt fest, welches Modul auf welchem Speicher-Controller ausgeführt wird. Alle I/Os laufen über alle drei I/O-Modultypen (Routing-Modul, Steuerungsmodul und Datenmodul). Routing-Modul Das Routing-Modul ist die einzige Systementität, die mit dem Host kommuniziert. Es akzeptiert SCSI-Befehle vom Host und analysiert sie. Das Routing-Modul ist zustandslos und wandelt die Anfragen einfach in Volumes und Logical Block Addresses (LBAs) um. Das Modul leitet eine Anforderung dann an das entsprechende Steuerungsmodul (und den Speicher-Controller) weiter, das die LBAs verwaltet. Das Routing-Modul gleicht die Last grundsätzlich im gesamten XtremIO- Clustersystem aus, indem es eine Content-basierte Fingerabdruck-Funktion ausführt, wodurch Daten gleichmäßig über alle X-Bricks im System verteilt werden. Eine detaillierte Erläuterung dieses Prozesses finden Sie in dem White Paper Einführung zum EMC XtremIO-Speicherarray. Steuerungsmodul Das Steuerungsmodul ist verantwortlich für die Übersetzung von Benutzer- Adressen des Hosts (LBA) in interne XtremIO-Zuordnungen. Es dient als Virtualisierungsebene zwischen dem Host-SCSI-Volume/LBA und dem deduplizierten XtremIO-Back-end-Speicherort. Diese Virtualisierungsebene bietet eine Möglichkeit, eine Reihe von umfangreichen Datenservices effizient zu implementieren. Auf XtremIO gespeicherte Daten sind Content-addressable. Der Array-Speicherort der Daten wird unter Zugrundelegung seines Inhalts bestimmt. Aus diesem Grund basiert er nicht auf seiner Adresse, wie es bei anderen Speichersystemprodukten der Fall ist. Die LBAs jedes Volume in einem XtremIO-Array sind auf viele Steuerungsmodule verteilt. 13

Datenmodul Das Datenmodul ist für die Datenspeicherung auf den SSDs verantwortlich. Es fungiert als Service für das Steuerungsmodul, indem das Steuerungsmodul einen Inhaltsfingerabdruck bereitstellt und das Datenmodul die Daten gemäß diesem Fingerabdruck schreibt oder liest. Das Datenmodul führt drei grundlegende Operationen durch: einen Block lesen, schreiben und löschen. Das Modul ist dabei so einfach wie möglich gestaltet, um ein robustes und zuverlässiges Systemdesign aufrechtzuerhalten. Das Steuerungsmodul muss sich nicht um die XDP-Zuweisung (XtremIO Data Protection) kümmern. Die Zentralisierung des XDP-Schemas im Datenmodul sorgt für systemweite Flexibilität und Effizienz. Das Datenmodul ordnet einen Inhaltsfingerabdruck genauso gleichmäßig einem physischen Speicherort auf einer SSD zu wie das Steuerungsmodul eine Hostadresse einem Inhaltsfingerabdruck gleichmäßig zuordnet. Dieser Prozess sorgt für die ausgewogene Verteilung der Daten nicht nur über alle Speicher- Controller, sondern auch über alle SSDs im Array. Dank dieser zusätzlichen Übersetzungsebene kann das Datenmodul die Daten optimal auf den SSDs verteilen. Selbst in außergewöhnlichen Situationen, zum Beispiel bei einem Komponentenausfall, Speicherplatzknappheit oder wenn Daten häufig überschrieben werden, kann XDP optimale Orte für die Datenspeicherung im System finden. Weitere Informationen darüber, wie XDP Redundanz und Flash-optimierte Datenplatzierung bereitstellt, entnehmen Sie dem White Paper EMC XtremIO-Datensicherheit. Neustart von Modulen Da alle XtremIO-Module im Benutzerbereich ausgeführt werden, kann XIOS Module nach Bedarf und schnell neu starten. Softwarefehler oder ungewöhnliches Modulverhalten resultieren in einem automatisierten Modulneustart. Neustarts erfolgen unterbrechungsfrei und in der Regel unmerklich für den Benutzer. Diese Fähigkeit ist auch die Grundlage für unterbrechungsfreie Upgrades. 14

I/O-Fluss Die Host-I/O geht ursprünglich beim Routing-Modul (R) ein, das SCSI parst. Das Modul berechnet für die Daten einen Fingerabdruck und leitet die I/O an das zuständige Steuerungsmodul (C) weiter. Das Steuerungsmodul und das Routing-Modul müssen sich physisch nicht auf demselben Speicher-Controller befinden. Das Steuerungsmodul übersetzt die Hostanfragen in das interne Datenmanagementschema von XtremIO und leitet die Daten an das entsprechende Datenmodul (D) weiter. Das Datenmodul verifiziert den Fingerabdruck und speichert die Daten mit Hilfe des Flash-optimierten und hochredundanten XDP-Datensicherheitsschemas von XtremIO auf SSDs. Der I/O-Pfad folgt immer exakt denselben Schritten, unabhängig von der Größe des XtremIO-Clusters. Daher bleibt auch die Latenz unabhängig von der Systemgröße konsistent. Abbildung 6. Beispiel für den Ablauf eines Hostschreibvorgangs 15

Sicheres verteiltes Journaling Wie für ein Enterprise-Speichersystem üblich, ist das Array nicht nur für die Datensicherheit zuständig, sondern benötigt für den Betrieb auch eigene Metadaten. Der Schutz dieser Metadaten und die Aufrechterhaltung von Kohärenz sind von größter Bedeutung. XtremIO verfügt über einen einzigartigen verteilten Journaling-Mechanismus zum Schutz der wichtigen Metadaten des gesamten Systems und seiner internen Datasets. Eine Kopie der Arraymetadaten wird im Arbeitsspeicher des Speicher-Controllers abgelegt. Die aktualisierten Metadaten werden über InfiniBand-RDMA (Remote Direct Memory Access) auf einen oder mehrere physische Speicher-Controller verteilt und synchron repliziert. Auf diese Weise wird jede Echtzeitänderung an mehreren Standorten geschützt. In einem Cluster, der aus mehr als einem X-Brick-Baustein besteht, werden die Journaldaten der einzelnen Speicher-Controller dank eines verteilten Replikationsprozesses auf allen Speicher-Controllern geschützt. Das systemweite Managementmodul (SYM) verwaltet die Journalreplikationsbeziehungen zwischen den Speicher-Controllern im Cluster. Aus Gründen der Ausfallsicherheit kann ein Speicher-Controller, der an keine Batteriebackupeinheit angeschlossen ist, nicht als Ziel für replizierte Journaldaten herangezogen werden. Falls der Speicher-Controller aus irgendeinem Grund die Journaldaten nicht auf einen anderen Speicher-Controller schreiben kann, werden die Daten in einer letzten Sicherheitsmaßnahme lokal auf die internen SSDs gespeichert. Fällt ein Speicher-Controller aus, dient das replizierte Journal als Vorlage für den Wiederaufbau der verloren gegangenen Inhalte des ausgefallenen Speicher-Controllers. Alle Journalinhalte werden regelmäßig auf nicht flüchtigem SSD-Speicher ausgelagert. Bei einem Stromausfall sorgen die Batteriebackupeinheiten des Systems dafür, dass diese Auslagerung erfolgen und der Cluster ordnungsgemäß heruntergefahren werden kann. Auf SSDs ausgelagerte Metadaten werden mit XDP sowie anderen Verfahren zum Schutz gegen SSD-Ausfälle geschützt. 16

Sicheres verteiltes Journaling ermöglicht die Systemwiederherstellung auch bei unwahrscheinlichen katastrophalen Ereignissen, wenn die Kommunikation zwischen allen Speicher-Controllern unterbrochen ist. Dabei wird jeder Speicher- Controller zu einer autarken Metadaten-Sicherheitslösung, die wieder hochgefahren und mit dem System verbunden werden kann, sobald die Kommunikation wiederhergestellt ist. Aufgrund der Bedeutung des Journalings ist der Code für den Journalmechanismus vollständig getrennt von jedem anderen Softwaremodul. Es handelt sich um ein eigenständiges, einfaches Softwaremodul, das sich designbedingt durch hohe Robustheit auszeichnet. Abbildung 7. Replikationsbeziehungen zwischen Speicher-Controllern in einem Cluster 17

Unabhängige Software- und Hardwaremodule Die flexible Architektur von XtremIO sorgt dafür, dass jede Softwarekomponente auf jedem Speicher-Controller im System ausgeführt werden kann. Diese Flexibilität bietet ein Höchstmaß an Verfügbarkeit und Ausfallsicherheit und sorgt zugleich für optimale Performance. Bei allen Änderungenen, die in die Hardwarekonfiguration auftreten, ändert sich die Anzahl der aktiven Softwaremodule auf dynamische Weise. Durch die dynamische Änderung ist eine optimale Nutzung aller verfügbaren Ressourcen durch das System sichergestellt. Ein aus vier Speicher-Controllern bestehender Cluster verfügt zum Beispiel über den doppelten Durchsatz und die zweifachen IOPS eines Clusters mit zwei Speicher-Controllern. Ein weiteres Beispiel ist SYM, das systemweite Managementmodul, das auf einem Speicher-Controller ausgeführt wird. Wenn eine Hardwarekomponente ausfällt, wird SYM aktiviert und ohne Benutzereingriff auf einem anderen Speicher-Controller ausgeführt. Sobald die ausgefallene Hardwarekomponente ausgetauscht wurde, stellt der Cluster schnell und automatisch den Zustand optimaler Verfügbarkeit und Performance wieder her. Die Tatsache, dass alle Softwaremodule nur locker miteinander verknüpft sind, erleichtert XtremIO das Verschieben von Ressourcen zusätzlich. Es besteht weder eine Affinität zwischen der Software und einem bestimmten Hardwareserver noch zwischen bestimmten Softwareinstanzen. Ein Datenmodul kann Anfragen von jedem Steuermodul empfangen und mit einer Transaktion antworten. Es gibt keinen Grund, sich eine Transaktion zu merken, und die nächste Transaktion ist unabhängig von den anderen. Diese Architektur ähnelt einer serviceorientierten Architektur (SOA). 18

Konnektivitätsredundanz Hinsichtlich der Konnektivität sorgt XtremIO zwischen jeder Systemkomponente für redundante Kommunikation (siehe Tabelle 1 und Tabelle 2). Jede Komponente stellt mindestens zwei Kommunikationspfade bereit und auch die Managementkommunikation erfolgt über ein vom Datenfluss getrenntes Netzwerk. Die Host-I/O erfolgt über Fibre-Channel- oder iscsi-ports, während für das Clustermanagement dedizierte Ethernetmanagementports der einzelnen Speicher-Controller verwendet werden. Dieses Design ermöglicht die Trennung von Steuer- und I/O-Pfad. Die Überwachung auf einem anderen Netzwerk ermöglicht die Korrelation von Ereignissen mit dem Systemzustand, unabhängig von Last oder I/O-Verhalten. Tabelle 1: Konnektivitätsredundanz von XtremIO Redundanz Jeder Speicher-Controller verfügt über zwei Fibre-Channel-Ports. Jeder Speicher-Controller verfügt über zwei iscsi-ports. Jeder Speicher-Controller verfügt über zwei InfiniBand-Ports. Es gibt zwei InfiniBand-Switches (wenn das System aus mehreren X-Brick-Bausteinen besteht). Es gibt zwei InfiniBand-Verbindungskabel (wenn das System nur aus einem X-Brick- Baustein besteht). Jedes DAE (Disk Array Enclosure) verfügt über zwei SAS-Controller-Module. Jedes DAE-SAS-Controller-Modul benötigt zwei SAS-Kabel. Anmerkung/Best Practice Jeder Port kann mit einem eigenen SAN-Switch verbunden werden. Jeder Port kann mit einem eigenen SAN-Switch verbunden werden. Jeder Port ist mit einer unabhängigen InfiniBand- Fabric verbunden. Das ermöglicht Fehlertoleranz gegenüber dem Ausfall von InfiniBand- Komponenten. Als Schutz vor einem InfiniBand-Switchausfall ist jeder Switch mit jedem Speicher-Controller verbunden. Zwischen den beiden Speicher-Controllern verlaufen redundante InfiniBand-Pfade. Der Ausfall eines SAS-Controller-Moduls hat keinen Verbindungsverlust zwischen dem DAE und den Speicher-Controllern zur Folge. Redundante SAS-Pfade stellen sicher, dass ein SAS-Portausfall oder ein defektes SAS-Kabel nicht zum Serviceverlust führt. 19

Tabelle 2: Auswirkung von XtremIO-Fehlern auf den Service Failure Aktion Serviceauswirkung Fibre-Channel- oder iscsi-port InfiniBand-Port InfiniBand-Switch Speicher-Controller Ethernet Netzteile von Speicher- Controller, DAE und InfiniBand- Switch Stromverlust in einem Stromkreis Stromverlust in beiden Stromkreisen SSD Die Multipathing-Software des Hosts nutzt die verbleibenden Ports. Das System nutzt den verbleibenden InfiniBand-Port für die Datenübertragung zwischen den Speicher- Controllern. Das System nutzt den verbleibenden InfiniBand- Switch für die interne Datenübertragung. Der Speicher-Controller-Partner im selben X-Brick-Baustein übernimmt die Verantwortung für alle Daten im Disk Array Enclosure. Die XMS kann mit einem Speicher-Controller nicht kommunizieren. Der Administrator wird vom System über den bzw. Die Ausfälle benachrichtigt. Ein Ersatznetzteil kann ohne Auswirkung auf den Service installiert werden. Der Administrator wird vom System über den Ausfall benachrichtigt. Das System bleibt über den zweiten, redundanten Stromkreis betriebsfähig. Das System lagert die Daten im RAM auf nicht flüchtigen Speicher aus und fährt ordnungsgemäß herunter. Das System benachrichtigt den Administrator. Automatisierter SSD-Wiederaufbau erfolgt (für bis zu zwei gleichzeitige SSD-Ausfälle). Keine Auswirkung Keine Auswirkung Keine Auswirkung Kein Serviceverlust. Ein geringer Performanceverlust tritt auf, weil insgesamt weniger aktive I/O-Verarbeitungskapazität zur Verfügung steht. Keine Auswirkung auf I/O oder Performance. Die Datenpfadkommunikation des Systems bleibt über InfiniBand online. Das Array kann nicht konfiguriert oder überwacht werden, bis die Konnektivität wiederhergestellt ist. Keine Auswirkung. Zwei Netzteile sorgen dafür, dass die Komponenten online bleiben. Keine Auswirkung Kein Service, bis die Stromversorgung wiederhergestellt ist. Ein geringer Performanceverlust, der von der Vollständigkeit und Auslastung des Arrays abhängig ist, tritt auf, bis die Wiederherstellung abgeschlossen ist. Weniger stark belegte und beschäftigte Arrays sind in geringerem Ausmaß von einer Performancebeeinträchtigung betroffen und werden schneller wiederaufgebaut. 20

End-to-End-Verifizierung Hardwareverifizierung Ein wichtiger Aspekt eines jeden Speichersystems ist der Erhalt einer Verifizierung bei jedem Schritt des Datenpfades. Die verschiedenen Mechanismen zur Datensicherheitsverifizierung auf Hardwareebene werden in Tabelle 3 beschrieben. Während der Datenübertragung zwischen Komponenten wird von der Senderhardwarekomponente ein CRC (Cyclic Redundancy Check) generiert, der vom Empfänger verifiziert wird. Für Data at Rest (im Arbeitsspeicher oder auf SSD) werden beim Schreiben in den Arbeitsspeicher ein ECC (Error- Correcting Code) sowie der CRC generiert und beim Lesen verifiziert. Tabelle 3: XtremIO Mechanismen zur Datensicherheitsverifizierung auf Hardwareebene Hardwarekomponente Datenübertragungen Fibre-Channel, Ethernet, InfiniBand, PCIe, SAS Data at Rest im Arbeitsspeicher Data at Rest auf SSD Verifizierungstyp Hardwarebasierter CRC DRAM-ECC SSD-ECC, SSD-CRC, XtremIO-XDP XtremIO basiert auf normalen x86-servern, Schnittstellenkarten, InfiniBand- Komponenten und emlc-ssds. Jede dieser Komponenten bietet ausgereifte, robuste Hardwareverifizierungsschritte. EMC XtremIO vermeidet die Verwendung von kundenspezifischen Hardwaremodulen im Array; kundenspezifische Hardware erfordert umfangreiche technische Anpassungen, um dieselbe Ausfallsicherheit zu erreichen, die reguläre Enterprise-Komponenten bereits von Haus aus bieten. 21

Kryptografischer Datenfingerabdruck Nicht nur verfügt jede XtremIO-Komponente im Datenpfad über ihren eigenen Datenverifizierungsmechanismus, XtremIO nimmt zusätzlich eine unabhängige Datenüberprüfung vor, die andere Speichersysteme nicht zu bieten haben. Bei Eingang einer I/O von einem Host errechnet das XtremIO Routing-Modul (R-Modul) einen eindeutigen kryptografischen Fingerabdruck basierend auf den vom Host empfangenen Inhalten. Der kryptografische Fingerabdruck ist eindeutig und passt zu einem ganz bestimmten Datenmusterblock. Sowohl die inhaltsbasierten Datenplatzierungsalgorithmen des Arrays als auch der Inlinededuplizierungsprozess nutzen den kryptografischen Fingerabdruck. Die gesamte Fingerabdruckbibliothek wird im Arbeitsspeicher des Speicher- Controllers vorgehalten. Der kryptografische Datenfingerabdruck wird bei jedem Lesevorgang durch einen Host anhand der ausgehenden Daten neu berechnet und mit dem Originalfingerabdruck verglichen. Damit ist sichergestellt, dass die vom Host empfangenen Originalinformationen sicher auf SSDs gespeichert, nicht versehentlich verändert und auf Anfrage wieder ordnungsgemäß an den Host zurückgesendet werden. Getrennte Nachrichtenpfade Die berechneten Fingerabdruckinformationen werden als separate Nachricht auf einem anderen Pfad als die eigentlichen Daten an das Datenmodul gesendet. Diese Trennung sorgt dafür, dass keine Komponente Daten und Fingerabdruck während der Übertragung auf dieselbe Weise verändern kann. Das verhindert eine unbemerkte Datenbeschädigung. Kurz gesagt, bei jedem Dateneingang in das System wird ein Fingerabdruck berechnet und dann bei jedem Lesevorgang von SSD sowie bei der Datenübertragung an den Host neu berechnet und verglichen. Der spezifische Fingerabdruck durchläuft das XtremIO-System getrennt von den eigentlichen Daten, woraus sich eine effiziente, unabhängige Überprüfungsmethode ergibt. 22

Fehlervermeidung, -erkennung und -begrenzung Serviceorientierte Architektur XtremIO verhindert kaskadierende Fehlerszenarien, wie sie bei Systemen mit gemeinsam genutztem Arbeitsspeicher auftreten können. XtremIO baut auf verschiedenen Services auf, die miteinander kommunizieren. Jeder Service verfügt über einen eigenen Satz von Datenstrukturen. Wenn ein Fehler in einem Service oder in Daten vorhanden ist, ist er auf diesen Service bzw. diese Daten begrenzt. Speichersysteme mit großen, gemeinsam genutzten Speichern. und Datenstrukturen sind grundsätzlich anfälliger für Softwarefehler und benötigen daher mehr Ressourcen, um kaskadierende Ausfälle zu vermeiden. XtremIO hat von Beginn an auf eine serviceorientierte Architektur gesetzt, um ein skalierbares System zu schaffen, das robuster ist als die großen monolithischen Architekturen, die für andere leistungsfähige Speichersysteme typisch sind. Fehlererkennung Das systemweite Managementmodul (SYM) kontinuierlich überwacht und erkennt Hardware- und Softwarefehler im System. Es überwacht kontinuierlich Speicher- Controller, DAEs (Disk Array Enclosures), Fibre-Channel-HBAs, Ethernet-NICs, InfiniBand-HCAs, InfiniBand-Switches und Batteriebackupeinheiten (BBUs). Das SYM überwacht außerdem kontinuierlich SCSI-Treiber, HBA-Controller-Treiber, Linux-Kernel und Softwarekomponenten zur Batteriekommunikation. Jede Komponente und jeder Datenpfad, die/der im XtremIO-System verwendet wird, verfügt über eine eigene Fehlererkennungsmethode (wie in End-To-End- Verifizierung auf Seite 21 beschrieben). Beispielsweise haben die emlc SSDs in XtremIO ein LBA-Seeding von 32-Bit-CRC, das zur ECC-Fehlererkennung und zur sofortigen Korrektur verwendet wird. Die SSDs bieten außerdem als Schutz vor internen Flash-Modulfehlern eine 22-Bit-Korrektur für jeden 512-Byte-Sektor und hardwarebasiertes RAID-5 in jeder SSD selbst. Dies erfolgt getrennt von der XtremIO-XDP-Technologie und ergänzt sie. Dadurch steigt die Ausfallsicherheit im Vergleich zu typischen Verbraucher-MLC-SSDs (cmlc) ganz erheblich. 23

Erweiterte Fehlerkorrektur Das SYM startet ausgefallene Softwarekomponenten automatisch neu (wie unter Plattform-Manager-Modul auf Seite 12 beschrieben) und kann außerdem nach einem Hardwareausfall Software anderen Speicher-Controllern zuweisen. Wenn das SYM beispielsweise erkennt, dass der Service für den I/O-Empfang von Hosts (das R-Modul) nicht läuft, startet es den Service automatisch neu. Diese Funktion sorgt für ein Höchstmaß an Verfügbarkeit und optimierte Servicelevels zu jeder Zeit. Das XtremIO-Array identifiziert unerwartete Datenunterschiede infolge der Fingerabdruckprüfung, die beim Lesen des SSD ausgeführt wird. Wird eine solche Inkonsistenz entdeckt, erstellt XtremIO die fehlenden Daten aus allen möglichen Quellen automatisch neu. Dies kann so einfach sein wie das erneute Lesen der Daten auf dem SSD, falls das Problem temporär ist. Sollte das System die Daten nicht lesen können (oder wenn der erneute Leseprozess ebenfalls falsche Ergebnisse liefert), baut das Array die Daten aus den anderen SSDs in der XDP-Redundanzgruppe auf. Das Journaling und die Metadaten im System sind wichtig für die Wiederherstellung nach Katastrophen. Aufgrund der Wichtigkeit solcher Datasets werden die Journale per CRC für jeden geschriebenen Block geschützt. 24

Unterbrechungsfreie Upgrades XtremIO wurde für die kontinuierliche Verfügbarkeit konzipiert und entwickelt. Gelegentlich wird neuer Firmwarecode bereitgestellt, um Funktionen hinzuzufügen, vorhandene Funktionen zu verbessern oder bekannte Probleme zu beheben. Es gibt zwei Arten von Upgrades: XtremIO-Betriebssystem (XIOS)-Upgrades Komponentenfirmware- und Linux-Kernel-Upgrades Beide Upgrade-Typen werden ohne Ausfallzeit ausgeführt, wenn das System online mit dem Host ist. XtremIO-Betriebssystem (XIOS)-Upgrades XtremIO-System-Updates sind in der Regel auf XIOS beschränkt und dienen nur zur Änderung des ausführbaren Codes, der im Benutzerbereich ausgeführt wird. Ein Upgrade des XIOS-Codes wird durchgeführt, indem der neue Code in den residenten Arbeitsspeicher auf einzelnen Speicher-Controllern geladen wird. Auch werden alle Speicher-Controllers konvertiert, um den neuen Code auszuführen. Dabei gibt es keine Auswirkung auf die Host-Anwendung und das System ist während des Upgrades vollständig verfügbar. Komponentenfirmware- und Linux-Kernel-Upgrades Einzelne Hardwarekomponenten können einzeln aktualisiert werden. Beispielsweise kann ein Fibre-Channel-HBA aktualisiert werden, indem es offline zum Host gesetzt wird, die Firmware aktualisiert wird und es dann wieder online mit dem Host gebracht wird. Sobald dieses Fibre-Channel-HBA online ist, kann das System das nächste Fibre- Channel-HBA aktualisieren. Durch die Nutzung von Host-Multipathing gemäß den Best Practices für XtremIO, hat der Host keine Ausfallzeiten und bleibt verfügbar. Dies gilt auch für alle anderen Firmwareupgrades, ob es sich dabei um die SAS-Controller, InfiniBand, SSD-Firmware oder eine andere Firmwarekomponente handelt. In einigen Fällen muss der Linux-Kernel des Speicher-Controller aktualisiert werden. Dieses Upgrade wird auf dieselbe Weise wie die Firmware durchgeführt. Die Speicher- Controller werden einzeln nacheinander ohne Auswirkungen auf die Verfügbarkeit aktualisiert. Online-Clustererweiterung Wenn zusätzliche Performance oder Kapazität gefordert sind, ist ein Scale-out des XtremIO-Speichersystems durch das Hinzufügen weiterer X-Bricks möglich. Mehrere X-Bricks werden über ein InfiniBand-Netzwerk kombiniert, das sich durch Redundanz, hohe Verfügbarkeit und äußerst geringe Latenzzeiten auszeichnet. Bei einer Erweiterung des Systems bleibt die Ressourcenverteilung ausgeglichen und die im Array befindlichen Daten werden auf alle X-Bricks verteilt. Dies bringt konsistente Performance und eine gleichmäßige Beanspruchung des Flashspeichers. Die Systemerweiterung erfordert keine spezielle Konfiguration oder manuelles Verschieben von Volumes. Dank des konsistenten Fingerabdruckalgorithmus von XtremIO lassen sich Neuzuordnungen minimieren. Ein neuer X-Brick wird zum internen Plan für den Lastenausgleich hinzugefügt und von den vorhandenen gespeicherten Daten werden nur die relevanten an das neue DAE übertragen. 25

Wiederherstellbarkeit des Systems Aufgrund des anwenderfreundlichen Designs des Systems ist das Hoch- und Herunterfahren von XtremIO risikolos. Das Herunterfahren ist ein ordnungsgemäß ablaufender Prozess, der bei einem externen Stromausfall oder auf Benutzeranfrage hin initiiert wird. Die BBUs verfügen über genügend Kapazität, um das System zweimal ordnungsgemäß herunterzufahren. Nach Wiedereinschalten des Systems überprüft es, ob die Batterien über genügend Kapazität für ein komplettes ordnungsgemäßes Herunterfahren bei einem Stromausfall verfügen. Jeder Speicher-Controller kann sich selbst herunterfahren, während er dauerhaft in der Lage ist, in einem Notfall zum Beispiel, wenn (aus irgendeinem Grund) die Kommunikation des Clusters unzureichend wird, die Datenkonsistenz zu wahren, bis die Stromversorgung wiederhergestellt ist. Jeder Speicher-Controller verfügt über zwei lokale Vault-Laufwerke. Bei einem Kommunikationsverlust oder Stromausfall speichert der Speicher-Controller Kopien aller Benutzerdaten und Systemmetadaten. Der lokale Speicher und das Journal werden in die Vault-Laufwerke abgelegt. Bei Wiederherstellung der Stromversorgung und Kommunikation gleicht der Speicher-Controller die Journalinformationen und den Rest des Systems wieder miteinander ab. Verlust der XMS-Kommunikation Das XtremIO-Management-System (XMS) ist die Anwendung zur Verwaltung des XtremIO-Systems. Der XMS bietet die grafischen, Befehlszeilen- und Programmschnittstellen, die zur Konfiguration, Bereitstellung und Überwachung des Systems erforderlich sind. Das System wird über die dedizierten Ethernetmanagementports verwaltet. Das System funktioniert jedoch weiterhin, selbst wenn die Kommunikation zum XMS verloren gegangen ist. Das interne SYM ist Teil des Arrays und wird auf den Speicher-Controllern ausgeführt. I/O-Anforderungen werden kontinuierlich verarbeitet, Hardware wird weiterhin überwacht und für etwaige ausgefallene SSDs wird ein Wiederaufbau initiiert und komplette Redundanz wiederhergestellt. Es werden nur vom Benutzer initiierten Aktivitäten und Überwachungsaktivitäten (z. B. die Erstellung von Volumes) angehalten, aber Host-I/O- und Kundenanwendungen sind nicht betroffen. 26

Verlust der Kommunikation zwischen Speicher-Controllern XtremIO-Speicher-Controller arbeiten in einer lose gekoppelten Architektur. Jeder Speicher-Controller fungiert als Service für die anderen Speicher-Controller, orchestriert durch das SYM. Jeder Speicher-Controller ist jedoch eine unabhängige Einheit mit der Möglichkeit, die darin gespeicherten Daten zu schützen und Konsistenz aufrechtzuerhalten, wenn die Kommunikation mit anderen Speicher-Controllern verloren gegangen ist. Bei Verlust der Kommunikation mit allen Speicher-Controllern schreibt der Speicher-Controller alle Metadaten und Journal-Informationen auf zwei lokale redundante Vault-Laufwerke und hält seine Services an. Dies ähnelt einem Notabschaltverfahren. Wenn die Kommunikation wiederhergestellt wurde und der Speicher-Controller wieder Teil des Systems ist, gleicht er die Journaldaten ab und wird erneut zu einer Systemressource. Das SYM-Modul integriert ihn dann erneut in das System und verwendet ihn für I/O, Caching und als Data Facility. Bei einem einzigen X-Brick-Baustein verarbeitet der verbleibende Speicher-Controller weiterhin die I/O-Anforderungen. 27

Fazit Das Hardware- und Software-Design des XtremIO-Systems stellt einen enormen Fortschritt in Speicher-Array-Technologie dar und ermöglicht neue Funktionen für die wichtigsten Workload-Konsolidierungen, z. B. Datenbanken, Analysen und Geschäftsanwendungen. Mehrere gemeinsam orchestrierte Tiers sorgen für hohe Systemverfügbarkeit, Datenintegrität und Datensicherheit für alle Systemkomponenten. Die Hardware bietet Redundanz für jede Verbindung des Hosts und den Weg zu den ruhenden Daten. Die XIOS-Betriebsumgebung stellt robuste Sicherheit für den gesamten Softwarestack des Arrays bereit: durch Fingerabdruckgenerierung beim Dateneingang, separate Pfade für Daten und Metadaten und ein modulares Softwaredesign in einer serviceorientierten Architektur. Die verschiedenen Softwaremodule werden unabhängig voneinander ausgeführt, aber agieren dennoch als einheitliches System. Das Gesamtsystemmanagement ist kohärent und redundant und kann Softwaremodule auf verschiedenen Hardwarekomponenten instanziieren. XtremIO erreicht mehr als 99,999 % hohe Verfügbarkeit, Datenintegrität und Datenschutz durch den Einsatz der folgenden Funktionen: Hardwareredundanz für jede Komponente Eindeutige Fingerabdrücke des Inhalts, während die Daten geschrieben werden Separate Pfade vom Systemeingang bis zu den SSDs für Benutzerdaten und den begleitenden Fingerabdruck Gesichertes Journaling zum Schutz vor unerwartetem Herunterfahren des Systems, Komponentenausfällen oder Kommunikationsfehlern Lose verknüpfte Softwaremodule, die in einer serviceorientierten Architektur zusammenarbeiten Zentrales redundantes Management Redundanz für bis zu zwei gleichzeitige SSD-Ausfälle Unterbrechungsfreie Systemsoftwareupgrades Weitere Informationen Für eine ausführliche Vorstellung der Funktionen des XtremIO-Speicherarrays und eine Erläuterung dazu, inwiefern XtremIO Storage Array die Performance, betriebliche Effizienz, Bedienung und die Gesamtkosten verbessert, wenden Sie sich bitte an XtremIO unter XtremIO@emc.com. Gerne vereinbaren wir mit Ihnen einen Termin für ein persönliches Treffen oder ein Webmeeting. XtremIO bietet Vorteile in vielen Umgebungen und gemischten Workload-Konsolidierungen, einschließlich virtuelle Server, Cloud, virtuelle Desktops, Datenbank, Analysen und Geschäftsanwendungen. 28