SANsymphonyV realisiert einetransparente Virtualisierungsschicht über verschiedene Speichergeräte hinweg. Das Systemsorgt damit für hohe Leistungund Verfügbarkeit. Darüber hinaus optimiert das Produkt dieNutzung der Speicher und Prozessorkapazitäten. Zum Leistungsumfang gehören neben denbereits erwähnten Neuerungenauch Funktionen zum Datenschutz, zum Caching, zum Provisioning, zur Replikation, zurRealisierung von Hochverfügbarkeitsszenarien und zur Migrationvon Daten.Alle Features lassen sich unabhängig von der verwendetenTechnologie über verschiedeneSpeicherprodukte unterschiedlicher Hersteller hinweg nutzen.Auf diese Art und Weise könnendie ITVerantwortlichen bestehende Speicherkomponenten inUnternehmen weiter einsetzen,während es gleichzeitig möglichist, die Speicherumgebungen umneue Technologien wie SSDs zuergänzen. Daraus ergibt sich unter anderem die Option, Speicherumgebungen stets währenddes laufenden Betriebs im Hintergrund zu aktualisieren und soalle Devices effizient zu nutzen.
FunktionsweiseSANsymphonyV unterstützt alleauf WindowsServern lauffähigen Speichergeräte und bietetden ITAbteilungen damit dieMöglichkeit, HighEndKomponenten und kostengünstige Lösungen bedarfsgerecht zu kombinieren. Dabei spielt es keineRolle, ob es sich dabei um DAS,SAN oder SSDSpeicher handelt.Die Verwaltung der Lösung läuftüber eine Managementkonsoleab, über die die zuständigen Mitarbeiter virtuelle Disks aus demphysikalischen Speicherpool erzeugen und den Hosts im Netzzuweisen können. Die Hosts "sehen" dabei immer nur die Ressourcen, die ihnen explizitzugewiesen wurden. In Clusternsind mehrere Hosts allerdings dazu in der Lage, virtuelle Disksgemeinsam zu nutzen. Das giltauch dann, wenn die dazugehörigen physikalischen Komponenten diese Funktionalität nichtunterstützen. Die Hosts verbinden sich über iSCSI oder FibreChannel mit den virtuellen DataCorePlatten. Zu den unterstützten Konfigurationen gehörenauch virtuelle iSCSISANs invirtuellen Servern. Deswegen ist
es möglich, praktisch alle Betriebssysteme und virtuellen Umgebungen in Verbindung mitSANsymphonyV einzusetzen.Das System lässt sich zudemkomplett über die Powershellsteuern.Der TestIm Test spielten wie SANsymphonyV auf zwei verschiedenenServern ein, die unter WindowsServer 2012 liefen. Das eine System verfügte über zwei CPUKerne, acht GByte RAM und
Im Test: SANsymphonyV R9
Volle Flexibilität beim SpeichereinsatzDr. Götz Güttich
DataCore erweitert den Leistungsumfang seiner SpeichervirtualisierungssoftwareSANsymphonyV R9 und wendet sich mit der aktuellen Version vor allem anmittlere und große Unternehmen. Zu den Neuerungen gehören umfassendeStorageTieringFunktionen, Disk und HostGruppen, Speicherprofile,die Option, die Leistung der Speicherkomponenten aufzuzeichnen undeine Vielzahl von ReportingFeatures. IAIT hat sich das Produktim Testlabor genau angesehen.
1
SSD, SATA und USBSpeicherkomponenten. Das andere arbeitete mit einer QuadCoreCPUund ebenfalls acht GByte RAM,darin kamen aber SASPlatten ineiner RAID0Konfiguration zumEinsatz. DataCore gibt übrigensals Hardwarevoraussetzung an,dass SANsymphonyV mindestens zwei 64Bitfähige SingleCore oder einen 64BitfähigenDualCoreProzessor mit 2,0GHz Taktfrequenz, 4 GByteRAM, 20 GByte Festplattenplatz
und zwei Fibre Channel HBAsoder zwei EthernetAnschlüssefür iSCSI benötigt.Nach dem Abschluss der Installation richteten wir eine Replikation von Daten vom ersten auf denzweiten Server ein und machtenuns mit dem Leistungsumfangvon SANsymphony vertraut. Anschließend führten wir PerformanceTests mit verschiedenenTieringKonfigurationen durchund analysierten die Leistungsunterschiede. Darüber hinausgingen wir auch im Detail auf dieanderen neuen Funktionen wie
Disk und HostGruppen, Speicherprofile, das Performance Recording und die Reports ein. ZumSchluss überprüften wir, ob sichdurch die Datenreplikation zwischen den beiden Servern irgendwelche Latenzen ergaben.InstallationUm die Leistung von SANsymphonyV zu optimieren, deaktivierten wir auf den betroffenenServern vor der Installation imBIOS das Hyperthreading und al
le Energiesparfunktionen. Nachdem diese vorbereitendenSchritte erledigt waren, genügtees, die SetupDatei aufzurufenund den dann erscheinenden Assistenten abzuarbeiten. Im Wesentlichen fragt dieser nach deneinzuspielenden Komponenten(wir führten jeweils eine Komplettinstallation durch) und demPasswort für das Verwaltungskonto. Danach läuft die Installation durch.Getting StartedNach dem Abschluss des Setupsverbanden wir uns mit Hilfe der
Verwaltungskonsole mit demSANsymphonyServer. Nachdemdie Verbindung zustandegekommen war, empfing uns eine "Getting Started"Seite, über die diezuständigen Mitarbeiter diegrundlegende Konfiguration vornehmen können. Sie besteht ausinsgesamt acht Schritten, die sichnacheinander abarbeiten lassen.Der erste Schritt besteht darin,die Benutzerkonten anzulegen,die für die Administration derSpeicherkonfiguration erforderlich sind. Hier unterscheidet dieSoftware zwischen so genanntenOwners, die alle Rechte besitzenund "Readers", die lediglich überLeserechte verfügen.Sobald die Benutzerkonten existieren, können die Administratoren das gerade installierte Systemmit einem anderen DataCoreServer verbinden und so eineServergruppe anlegen. Die andieser Gruppe teilnehmendenServer müssen per iSCSI oderFibre Channel miteinander verbunden sein und sind dazu in derLage, virtuelle Disks zu spiegeln.Die Angabe des Spiegelserverserfolgt einfach über den Namenoder die IPAdresse des betroffenen Systems. Um einen Mirror zurealisieren, müssen die beteiligten Server nicht identisch sein. Esist noch nicht einmal erforderlich, auf beiden Systemen diegleiche Speicherkonfigurationbereit zu stellen. In der Praxisgibt allerdings das langsamsteSystem die Geschwindigkeit desganzen Mirrors vor.Nach der Konfiguration des Mirrorings geht es daran, den aufdem Server vorhandenen NetzwerkPorts Rollen zuzuweisen.FrontendPorts stellen den ClientSystemen Speicherplatz zur
2
Die Getting StartedSeite unterstützt die Administratoren bei der Konfiguration des Speichersystems
Verfügung, über Managementports lässt sich das System verwalten und MirrorPorts übernehmen die Datenspiegelung aufandere Systeme.Mittels "Register a Host" könnendie zuständigen Mitarbeiter ClientSysteme in ihre SANsymphonyVUmgebung einfügen,die den virtuellen Speicher, dendie DataCoreSoftware bereitstellt, nutzen. Dazu müssen sielediglich den Computernamenangeben, definieren, welches Betriebssystem auf dem Host zum
Einsatz kommt (AIX, HPUX,Linux, Solaris, Windows oder dieVirtualisierungsumgebungen Citrix XenServer und VmwareESX), und festlegen, ob Multipath und ALUASupport (Asymmetric Logical Unit Access)aktiviert werden sollen. Danachsteht der Host in der HostsÜbersicht zur Verfügung und es können ihm Ports und virtuelle Diskszugewiesen werden. Im Test verwendeten wir als Hosts Windows8 und Vmware ESXi5.1
Update1Systeme. Dabei tratenkeine Probleme auf und es warmit den von SANsymphonyVbereit gestellten virtuellen Diskssogar möglich, während des Betriebs die VmwareHardwarebeschleunigungsfunktion zu nutzen,obwohl die zugrundeliegendeHardware diese gar nicht unterstützte.Nach dem Anlegen der Hostswenden sich die Administratorender Konfiguration eines DiskPools zu. Hierbei vergeben sienicht nur einen Namen, sondern
legen auch den zu verwendendenServer, die Menge der in demPool erlaubten Tiers und die maximale Poolsize fest.Sobald der Pool existiert, kann esan das Erzeugen der ersten virtuellen Disk gehen. Diese erhält eine Bezeichnung, abgesehendavon können die ITMitarbeiterauch ihren Typ festlegen. An Typen stehen "Single" (eine Diskauf einem Server mit einer Speicherquelle), "Dual" (eine Disk
auf zwei Servern mit einer geteilten Speicherquelle, sorgt fürFehlertoleranz auf Serverebene)und "Mirrored" (eine Disk aufzwei Servern mit gespiegeltenSpeicherquellen, sorgt für Fehlertoleranz auf Server und Storageebene) zur Verfügung.Parameter wie die Größe der virtuellen Disk und des reserviertenSpeichers schließen die DiskKonfiguration gemeinsam mitder Wahl der Speicherquelle ab.Die virtuellen Disks in einemPool lassen sich jederzeit im laufenden Betrieb hinzufügen oderentfernen. Es ist zudem auchmöglich, den einzelnen Disksunterschiedliche Tiers zuzuweisen. So können die Verantwortlichen Szenarien realisieren, indenen "Hot Data" auf schnellerenDatenträgern abgelegt werden,als die restlichen Daten. Im Testwiesen wir der SSD in unseremStoragePool den Tier 1 zu, während die externe USBPlatte denTier 2 erhielt. SANsymphonyüberprüfte dann im laufendenBetrieb, welche Daten besondersoft Verwendung fanden (die ebenangesprochenen "Hot Data") undkopierte diese dann auf die SSD,während die "normalen" Datenweiterhin auf der USB verblieben. Da beide physikalischenSpeicherkomponenten Teil derselben virtuellen Disk waren,blieben alle damit zusammenhängenden Vorgänge für die Anwender völlig transparent.Nach der Konfiguration derDisks war es an der Zeit, sie denClientSystemen zuzuweisen.Dazu wählen die Administratorenerst einmal den Host aus, der diejeweilige Disk nutzen soll undselektieren dann den betroffenenvirtuellen Speicher. Im Anschlussdaran legen sie fest, ob der Zu
3
Die Leistung der Speicherkomponenten lässt sich aufzeichnen und später auswerten
griff auf den Server über einenSinglePath oder einen redundanten Pfad abläuft und definierenbei Bedarf auch noch die zu verwendenden Ports. Anschließendsteht der virtuelle Speicher aufden ClientSystemen zur Verfügung.Zum Abschluss des GettingStartedWizards kommt die Konfiguration des Performance Recordings an die Reihe. Hier legendie zuständigen Mitarbeiter fest,welche Komponenten sie überwachen möchten (DataCore Server, Disk Pools, Hosts, physikalische Disks, virtuelle Disksund vieles mehr) und welcheCounter zum Einsatz kommensollen (Total Bytes Read, TotalBytes Written, Cache Read Hits,Total Operations pro Sekundeund so weiter). Anschließendlässt sich das Recording starten.Nach dem ersten Start fragt dasSystem die Anwender noch nachdem für die Aufzeichnung zuverwendenden SQLServer (daskann ein Microsoft SQL ServerExpress auf der gleichen Maschine oder ein SQLServer im Netzsein), danach startet das Recording und die Erstkonfigurationder Software ist abgeschlossen.DataCore hat sich sichtlich großeMühe gegeben, die Einrichtungder Speichervirtualisierungslösung einfach zu machen undauch Administratoren ohne großeErfahrung mit virtuellen Speicherlösungen werden ohneSchwierigkeiten dazu in der Lagesein, die Erstkonfiguration durchzuführen.Im BetriebNachdem wir uns durch den Getting StartedWizard durchgearbeitet hatten, war unsereTestumgebung fast vollständig.Es verblieb nur die Aufgabe, die
Replikation einer virtuellen Diskauf unseren zweiten SANsymphonyServer einzurichten. DieReplikationsfunktion dient dazu,eine asynchrone Sicherheitskopievon Daten an einem entferntenOrt anzulegen, zum Beispiel fürDesaster RecoveryMaßnahmen.Damit unterscheidet sie sich vondem im Rahmen der Beschrei
bung des Getting StartetWizardsbereits erwähnten synchronenSpiegel. Die MirroringFunktionrealisiert eine Hochverfügbarkeitskonfiguration und benötigtvergleichsweise schnelle Verbindungen zwischen den beteiligtenSystemen. Die Replikation stelltim Gegensatz dazu eine reine Datensicherungsmaßnahme dar. Dafür kommt sie aber auch mitvergleichsweise langsamenWANVerbindungen klar.Zum Anlegen des Replikationsverhältnisses zwischen unserenMaschinen war es erforderlich,zunächst einmal PufferPlatten zudefinieren, auf denen das Systemdie zu replizierenden Informationen lokal zwischenspeichernkonnte. Als das erledigt war,klickten wir mit der rechtenMaustaste im Konfigurationswerkzeug auf der linken Seite in
den Bereich "DataCore Servers"und riefen den Befehl "Partnerwith Replication Group" auf.Daraufhin öffnete sich ein Konfigurationsdialog, der nach demNamen oder der IPAdresse desRemote Servers und den Credentials für den lokalen und den entfernten Server fragte. Nachdemwir diese Angaben gemacht hat
ten, ließ sich die Verbindung problemlos herstellen.Als die Replication Group aktivwar, erzeugten wir auf beidenServern eine gleich große virtuelle Disk, die wir für die Replikation verwenden wollten.Anschließend riefen wir auf unserem Quellsystem den Eintragdieser Disk auf, wechselten aufden Reiter "Replication" und gaben dort an, mit welchem Serverund welcher Disk die Softwaredie Replikation durchführen sollte. Damit war die Konfigurationvollständig.Bestehende Replikationen lassensich jederzeit umkehren, so dassdie DestinationSite zur SourceSite wird und umgekehrt. Außerdem ist es auch möglich, einenTestmodus zu nutzen, um auf derRemote Site zu prüfen, ob die
4
Der Aufbau einer Replikation auf einen entfernten SANsymphonyVServer.Unter "Performance" finden sich die noch zu transferierenden Daten.
Clients bei einem Ausfall desQuellsystems dazu in der Lagewären, mit den replizierten Datenweiter zu arbeiten. Das stellt eineunserer Meinung nach sehr sinnvolle Funktion dar, da sie dabeihilft, unliebsame Überraschungen im Fehlerfall zu vermeiden.Die virtuellen Disks von SANsymphony lassen sich übrigensnicht nur spiegeln und auf andereServer replizieren, sondern es besteht auch die Möglichkeit,Snapshots anzulegen, mit denendie zuständigen Mitarbeiter in
der Lage sind, die Disks bei Bedarf später wieder in ihren Ausgangszustand zurückzuversetzen.Diese Snapshots können – genauwie Replikationen – optional aufanderen Tiers gespeichert werden, als die QuellDaten. Auchdas dürfte in den meisten Umgebungen sinnvoll sein, da die Kopien in der Regel eine deutlichniedrigere Priorität haben, als dieProduktivdaten und deswegenauch nicht auf schnellen Medienvorliegen müssen.
Reports und weitere neueFunktionenDataCore hat der aktuellen Version von SANsymphony eine Vielzahl an Reports mitgegeben, diesich mit Disk Pools, Hosts, Pfaden physikalischen Disks, Ports,der System Health und virtuellenDisks befassen. Diese Reportsumfassen beispielsweise die Größe der Disks, den Status der Anschlüsse oder auch die tatsächliche Größe virtueller Disks.Damit haben die Administratorendie Möglichkeit, sich jederzeit
genau über den Status ihres Speichernetzes zu informieren. Fallsnötig lässt sich das Erstellen derReports auch über PowershellCommandlets automatisieren.Ebenfalls neu in SANsymphonyV R9: die Disk und HostGruppen. Mit ihnen lassen sich mehrere Datenträger und Hosts zuGruppen zusammenfassen, umfür mehr Übersichtlichkeit beider Verwaltung der vorhandenenSysteme zu sorgen. Da die IT
Verantwortlichen dazu in der Lage sind, DiskGruppen per DragandDrop HostGruppen zuzuweisen und Operationengleichzeitig auf allen Gruppenmitgliedern durchzuführen, vereinfachen die Gruppen in großenUmgebungen die Arbeit mit denSystemen deutlich.Die StorageProfile dienen dazu,Speichergeräten bestimmte Leistungsparameter zuzuweisen. Sogibt es innerhalb der Speicherprofile beispielsweise die Leistungsklassen "Archive", "Low","Normal", "High" und "Critical".Wird eine virtuelle Disk derLeistungsklasse "Archive" zugeordnet, so verwendet sie im Betrieb immer nur Speicher derniedrigsten Leistungsebene, diees gibt. In den höheren Speicherklassen kommen dann unter anderem immer mehr derschnelleren Systeme der höherenTiers hinzu. Neben der Leistungsklasse definieren die Speicherprofile auch Replikationsprioritäten und Mirror RecoveryPrioritäten (jeweils "Low", "Regular", "High" und "Critical").Zusammen mit den Tiers sind dieStorageProfile das Herzstück derSANsymphonyVFunktionalitätzum effizienten Ausnutzen heterogener Speichersysteme. Fallsnötig, können die Anwender jederzeit auch eigene Speicherprofile definieren.Eine weitere Neuigkeit ist dasbereits angesprochene Performance Recording. Mit ihm lässtsich nicht mehr nur eine Echtzeitüberwachung der Speichersysteme durchführen, sondern dieAdministratoren können sichjetzt die Performance einzelnerKomponenten auch jederzeit imNachhinein ansehen und so zumBeispiel bei Benutzerbeschwer
5
Die "Allocation Map" zeigt unter anderem an, welche Daten auf welchen Devices "heiß" sind und welche nicht
den wegen langsamer Anwendungen eventuelle Probleme direkt im Speichersystem analysieren. Im Test funktionierte dasPerformance Recording bestensund versorgte uns mit allen benötigten Informationen.Das StorageTieringUm zu Testen, welche Auswirkungen das StorageTiering konkret auf die Leistung einervirtuellen Festplatte hat, legtenwir im Test ein neues virtuellesDrive an und wiesen es derSpeicherklasse "Archive" zu, also der Speicherklasse, die nurden Speicher mit der geringstenLeistungsfähigkeit nutzt. In unserem Testsystem handelte es sich
dabei um die externe USBFestplatte. Dieses virtuelle Drive verbanden wir mit unseremESXiServer und setzten es dortals zusätzlichen Datastore ein.Für den Test verwendeten wir eine virtuelle Maschine (VM) unterWindows XP Professional mitService Pack 3, die auf dem gleichen ESXIHost lief. Dieser VMwiesen wir eine neue virtuelle
Festplatte zu, die auf dem SANsymphonyVbasierten Datastoregespeichert wurde. Anschließendinstallierten wir auf dem Clientdie PerformanceTestSoftware"Iometer" (www.iometer.org) undführten mehrere PerformanceTests der eingebundenen virtuellen Testplatte aus. Der Client undder DataCoreServer hingen dabei gemeinsam an einem gemeinsamen GBitEthernetSwitch.Während des Tests ließen wir Iometer jeweils fünf Minuten laufen und testeten dabei verschiedene WorkloadGrößen. Dieerste davon betrug 8 KByte, wasExchangeVerkehr, diversen VmwareWorkloads und OLTPDa
tenbankIOs entspricht. Diezweite Größe, 64 KByte, repräsentierte einen Datenbank ReadPrefetch und die dritte Größe(256 KByte) sollte eine BackupOperation simulieren. Bei derersten Workload verwendeten wir50 Prozent Lese und 50 ProzentSchreibzugriffe sowie 50 Prozentzufällige Schreib/Leseoperationund 50 Prozent sequentielle
Schreib/Leseoperationen. Bei derzweiten und dritten arbeiteten wirjeweils mit extra Läufen fürSchreiben und Lesen (umBackups und Restores abzubilden) und bearbeiteten die Datensequentiell. Dabei kamen wir zufolgenden Ergebnissen: Auf unserem System erreichen wir beieiner Workload von 8 KByte insgesamt 76.312 IOs. Beim Lesenmit einer Workload von 64KByte betrug die Zahl der ReadIOs 59.717 und die Zahl der WriteIOs 140.462.Der Grund für den niedrigen Lesewert liegt im CacheVerhalten.Bei einem Lesevorgang fragt dasSystem zunächst den Cache, derden gesuchten Wert bei einem Hitzurückgibt. Befindet sich derWert aber nicht im Cache, sosendet er die Aussage zurück,dass er nicht über den Wert verfügt, woraufhin eine zweite Anfrage an das StorageDevicegesendet wird, das den Wert dannliefert. Je nach WorkloadGrößeund verwendetem Speichergerätkann dieser Effekt das Lesen vonDaten relativ stark ausbremsen.Bei den WorkloadGrößen von256 KByte lagen die Werte fürdas Lesen bei 41.248 IOs, beimSchreiben kamen wir auf 34.949IOs.Nachdem wir diese Werte ermittelt hatten, wechselten wir mitder virtuellen Testplatte in dieSpeicherklasse "normal", dieauch schnelleren Speicher nutzendarf. Danach führten wir dengleichen Test mehrmals durch,damit die DataCoreLösung den"Hot Data"Anteil bestimmenund die betroffenen "heißen" Daten in unseren SSDSpeicher verschieben konnte. Dabei wurdedie Leistung immer besser, bissich alle Hot Data auf der SSD
6
Die virtuellen DataCorePlatten stellen VmwareHardwarebeschleunigungauch dann zur Verfügung, wenn die zugrundeliegende Speicherhardware diesegar nicht unterstützt
befanden. Die Performance, diewir nach der Migration der "heißen" Daten in den SSDSpeichererreichten, betrug bei derWorkload von 8 KByte 471.036IOs, bei 64 KBite Lesevorgängenwaren es 300.843 IOs und bei 64KByte Schreibvorgängen kamenwir auf 223.746 IOs. Beim Lesenvon 256 KByteWorkloads erreichten wir 99.844 IOs, beimSchreiben kamen wir auf denWert von 95.354 IOs.Damit lässt sich zusammenfassend sagen, dass die Leistungssteigerung in unserer Testumgebung bei 517,25 Prozent für8 KByte Workloads lag. Bei den64 KByte Workloads betrug dieVerbesserung beim Lesen 403,78Prozent und beim Schreiben59,29 Prozent. Bei 256 KByteWorkloads lagen die entsprechenden Werte beim Lesen bei142,06 Prozent und beim Schreiben bei 172,84 Prozent.Die Leistung der ReplikationAbgesehen davon führten wir zusätzliche Analysen durch, umfestzustellen, ob die Replikationfür irgendwelche Latenzen imlaufenden Betrieb sorgt. Hierbeistellten wir fest, dass leichte Latenzen messbar waren, wenn siegerade besonders aktiv war.Diese sind aber bei der praktischen Arbeit – wir verwendetendas Replikationslaufwerk übermehrere Tage hinweg als Speicher für Office und MultimediaDateien und arbeiteten intensivdamit – nicht spürbar. Der Grunddafür liegt in einer doppeltenRAMPufferung zum Minimieren des Einflusses von NTFSLaufzeitschwankungen, großenPayloads und einem optimiertenHandling von Linkfehlern beziehungsweise slowdowns.
FazitSANsymphonyV R9 konnte inunserem Test voll überzeugen.Die Software ist sehr leistungsstark und flexibel einsetzbar. DieBedienerführung wurde durchdacht gestaltet und sollte keinenSpeicheradministratoren vor unüberwindbare Schwierigkeitenstellen. Die Replikation, die Arbeit mit den Disk und HostGruppen und das PerformanceRecording funktionierten bei uns
auf Anhieb und alle genanntenFunktionen brachten die erwarteten Ergebnisse.Auch die Reports lassen keineWünsche offen und sorgen dafür,dass die zuständigen Mitarbeiterstets bestens über den Status ihres Speichernetzes im Bilde sind.Besonders überzeugen konnteuns aber die TieringFunktion inKombination mit den Speicherprofilen, da diese beiden Featuresgemeinsam dafür sorgen, dassschnelle und langsame sowie alteund neue Speicherkomponenten
in einer Infrastruktur nahtlos zusammenarbeiten ohne sich gegenseitig auszubremsen.Weitere erwähnenswerte Funktionen, die die Software unterstützt und die uns im Test positivauffielen, sind SNMPTraps zurIntegration von SANsymphonyin Managementlösungen, TaskSchedulingWizards zur Automatisierung wiederkehrender Arbeitsschritte, EMailBenach
richtigungsfunktionen und Leistungscharts zur Anzeige der LivePerformance. All diese Featuresmachen die Arbeit mit virtuellenSpeicherinfrastrukturen vergleichsweise einfach und tragenzu dem positiven Gesamtbild derLösung bei. Administratoren mitheterogenen Speichernetzen undITVerantwortliche, die Wert darauf legen, verschiedene Speichersysteme flexibel kombinierenzu können, sollten sich auf jedenFall mit der Lösung vertraut machen, da sie ihnen ihre Arbeitdeutlich erleichtern kann.
Das PerformanceRecording kann eine Vielzahl von Parametern überwachen
7