Skip to content

HP 3PAR StoreServ: Funktionen & Features (Teil 2 – “Speichervirtualisierung, a.k.a. HP tri-level mapping”)

by Michael Koch on Juli 16th, 2013

Nachdem wir uns im ersten Teil detailliert mit den Controllern und deren Funktion „Persistent Cache“ beschäftigt haben, soll es in diesem Beitrag um die zweitwichtigste Komponente eines Storage-Systems gehen: den Datenspeicher. Was genau passiert eigentlich mit den Festplatten? Wie werden diese vom System verwendet? Zusammenfassen lässt sich dies am einfachsten mit dem Begriff „Speichervirtualisierung“. Mittels der Abstraktion von physikalischem Speicher über mehrere Ebenen erreicht HP bei den 3PAR-Systemen eine sehr hohe Flexibilität im Umgang mit den einzelnen Speicherbereichen – und dies erhöht schlussendlich ein weiteres Mal die Verfügbarkeit der Daten.

Wie funktioniert’s?

Was man überall lesen kann im Zusammenhang mit den StoreServ-Systemen ist das sogenannte „wide-striping“-Verfahren:

  • Alle verfügbaren physikalischen Festplatten im Speichersystem werden je Kategorie (NearLine SAS 7.2k / Enterprise SAS 15k / SSDs) in einen RAID0-Verbund an den Controller-Knoten zusammengefasst (Brutto-Speicherkapazität).
  • Über alle diese physikalischen Festplatten wird eine Art „Verwaltungsraster“ gelegt: Sogenannte „Chunklets“ oder auch „chunks“. Hierbei handelt es sich um 1GB kleine Blöcke (bei den Enterprise-Lösungen der StoreServ 10000er Serie werden 256MB kleine Blöcke verwendet).
  • Das „wide-striping“ stellt die erste Abstraktions-/Virtualisierungsschicht der physikalischen Festplatten dar.
  • Auf dieser Ebene wird der mehrseitige Zugriff von Controller-Knoten auf eine Festplatte/ein Chunklet realisiert (dual pathing), d.h. die Daten auf dem Speicher sind zu jeder Zeit für das gesamte System erreichbar.

Dieses „wide-striping“-Verfahren findet sich auch bei anderen Herstellern. Allerdings bleiben viele auch an genau dieser ersten Stufe stehen. HP geht bei den StoreServ-Systemen jedoch weiter und nennt das Gesamtkonstrukt seiner Speichervirtualisierung „tri-level mapping“.

In einer zweiten Stufe werden diese einzelnen „chunks“ zu logischen Einheiten zusammengefasst: Sogenannte „logical discs“.

  • Ein Beispiel: 100 „chunks“, welche sich über diverse physikalische Festplatten verteilen, bilden nun einen 100GB kleinen internen Speicherbereich.
  • Eine „logical disc“ ist somit nicht an die Speicherkapazität einer physikalischen Festplatte gebunden (wie bspw. in herkömmlichen RAID-Arrays der Fall).
  • Somit können Festplatten unterschiedlicher Speichergrößen für einen RAID-Level verwendet werden, ohne dabei überschüssige Speicherkapazität zu verlieren (Optimale Speicherausnutzung).
  • Einzelne „logical discs“ können über mehrere physikalische Festplatten verteilt werden.
  • Dadurch wird die Gesamtperformance einer „logical disc“ stark optimiert, da nun die Performance (IOPS) der einzelnen Festplatten innerhalb der „logical disc“ gebündelt werden (Zusammenspiel aus Stufe 1 & 2).
  • Mittels dieser Grundlage werden ebenfalls Spare-Bereiche über mehrere physikalische Festplatten erzeugt. Dedizierte einzelne Spare-Festplatten entfallen. Ein möglicher RAID-Rebuild erfolgt somit wesentlich schneller, da auch hier die Performance nicht auf eine einzelne physikalische Festplatte limitiert ist. Erworbene Hardware-Ressourcen werden optimal ausgelastet und laufen nicht ungenutzt im Standby (ökonomischer Vorteil).

In der dritten Stufe werden „logical discs“ zusammengefasst und bilden nun ein sogenanntes „virtual volume“.

  • Ein „virtual volume“ kann auf einer einzelnen „logical disc“ liegen.
  • Es kann auf einem Teil einer „logical disc“ liegen.
  • Oder aber es verteilt sich über mehrere „logical discs“.
  • „Virtual volumes“ bilden die Grundlage für Storagekapazitäten, welche nach außen an Serversysteme gegeben werden können.

In Summe also drei Ebenen, auf denen der physikalische Speicher abstrahiert / virtualisiert wird. Und gleichzeitig auch der erste Teil in der Bezeichnung „tri-level mapping“. Aber wie wird dieser Speicher nun an die externen Serversysteme bereitgestellt? Damit befasst sich der zweite Teil im Begriff „tri-level mapping„: Die Zuordnung (mapping) von Speicher.

Ein „virtual volume“ kann über beliebig viele System-Ports (FibreChannel, FCoE oder iSCSI) als sogenannte VLUN nach Extern präsentiert und bereitgestellt werden. Oder eben auch über so wenige Ports wie irgend möglich. Hierzu arbeiten die 3PAR-Systeme mit einer sogenannten „mapping table“. Diese Tabelle besteht aus Verknüpfungen zwischen System-Ports & „virtual volumes“. Die Verknüpfungen beziehen sich dabei immer auf 32MB kleine Bereiche eines „virtual volumes“.

Das Zusammenspiel von mehreren Speicherebenen und kleinen verknüpften Datenbereichen ermöglicht eine sehr feine Speicher-Granularität. Daraus ergibt sich wiederum eine sehr hohe Flexibilität bei der Verlagerung & Bereitstellung von Speicherbereichen.
Und dies ermöglicht in Summe ein Maximum an Datenverfügbarkeit, da fast alle Datenbewegungen online, d.h. unterbrechungsfrei, durchgeführt werden können. Speicherbereiche, die für produktive Serversysteme bereitgestellt wurden, müssen für Wartungs-/Optimierungsarbeiten nicht vollständig abgeschaltet werden, da die einzelnen Bestandteile dieser „virtual volumes“ / VLUNs („chunks“, „logical discs“, mapping-Bereiche und Ausnahme-Blöcke) unabhängig von einander durch das Storage-System verarbeitet werden können.

Dank der intelligenten Speicherverwaltung innerhalb der HP 3PAR Storage-Systeme ergeben sich für Ihre geschäftskritischen Daten folgende Vorteile:

  1. Performanceoptimierung (effektive Nutzung aller physikalischen Festplatten-Ressourcen)
  2. Feinkörniges Speicher-Management (schnelle Datenverarbeitung auf Grund kleinster einzelner Speicherblöcke)
  3. Maximale Verfügbarkeit des Storage (unterbrechungsfreie Speicher-Operationen)

Zusätzlich profitieren weitere Funktionen und Features der StoreServ-Systeme von dieser Art der Speichervirtualisierung. Hierzu zählen Mechanismen wie bspw. „dynamic optimization“, „adaptive optimization“, „thin provisioning“ oder auch „persistent port“.

Mit diesen und weiteren Besonderheiten der StoreServ-Systeme werden wir uns im kommenden dritten Teil ausführlich beschäftigen.

From → Storage