Non SED Found in 3PAR Management Console

Wer sich nach dem Update der 3PAR StoreServ Management Console auf Version 4.4.1 über diesen Anblick wundert oder sich Sorgen um sein Storage macht:

 

Keine Sorge, man hat nichts zu befürchten! Der Anzeigefehler taucht nur auf wenn keine Encrypted Disks eingebaut sind.

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

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.

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

HP 3PAR StoreServ: Funktionen & Features (Teil 1 – „Persistent Cache“)

Überall bekommt man Artikel zum jüngsten Storage Produkt von Hewlett Packard, der HP 3PAR StoreServ 7000er Serie, zu lesen. Jeder zitiert darin eifrig die Schlagworte findiger Marketing-Schreiberlinge zu neuen Funktionen & Features. Und als Höhepunkt findet sich eine rasche Auflistung der Hardware-Spezifikationen.

Aber reicht das aus? Bekommt man so tatsächlich eine Übersicht oder gar ein Gefühl dafür was einem da eigentlich angeboten wird?

Kaufen Sie ein neues Paar Schuhe, weil der Verkäufer Ihnen sagt „Das ist das neueste Modell auf dem Markt mit Funktion A, B und natürlich auch C“? Oder interessiert es Sie vielleicht doch was genau Sie hier eigentlich für Ihr Geld bekommen – was sich hinter einem vertrieblichen Schlagwort im Detail verbirgt, wo und wie die Funktion zum Einsatz kommt und vor allem ob man diese Funktion überhaupt benötigt?

Wir geben Auskunft und erklären die Funktionen und Möglichkeiten der neuen Speicherlösung im Detail. Interessiert? Dann begleiten Sie uns.

Continue reading „HP 3PAR StoreServ: Funktionen & Features (Teil 1 – „Persistent Cache“)“

HP 3PAR StoreServ 7000 DemoPoint

Andere versprechen es ohne Grundlage – bei uns können Sie tatsächlich eine HP 3PAR StoreServ 7000 in Aktion erleben und auch anfassen. Besuchen Sie unser DemoCenter – der einzige HP 3PAR StoreServ 7000 DemoPoint in der Region Hannover und Umgebung!

Kontaktieren Sie uns unter 0511 – 260 911 514 oder per Mail an due[at]michael-wessel.de (Deniz Ünal) und wir sagen Ihnen, was Sie noch alles in unserem DemoCenter erwartet.

HP P4000 stolpert über Umlaute in Volume Beschreibung

Ein Freitextfeld zur „Beschreibung“ eines Volumes. Welche Relevanz kann das für den Betrieb, die Arbeit mit dem Storage Cluster insgesamt haben? Wie ein Kollege sowie der HP Support gemeinsam feststellen mussten, eine deutlich größere als man vermuten sollte:

Volume X hat eine Beschreibung, die einen Umlaut enthält. Volume Y soll auf einem Server neu verbunden werden (DSM deinstalliert, Sessions müssen neu hergestellt werden). Die Sessions verschwinden aber einfach nicht. Beim manuellen Session Reset über die CLI bekommt man eine Fehlermeldung, die irgendwas zum Thema Encoding und UTF-8 moniert. Ohne den Umlaut in der Beschreibung des Volumes, das überhaupt nichts mit diesem Vorgang zu tun hat (auch nicht mit dem Server verbunden ist), klappt es dann.

Stick to English. Oder programmiert eure Software so, dass sie vollständige Plausibilitätsprüfungen durchführt.

HP P4000 zulässige Zeichen im Passwort mit v9.0 geändert

Die Centralized Management Console (CMC) für HPs P4000 Storage Systeme kontrolliert bei der Passwortver- und -eingabe auf zulässige Zeichen. In Version 8.5 war zum Beispiel der Slash („/“) nicht zulässig. In Version 9.0 ist nun auf einmal auch der Punkt („.“) nicht mehr zulässig. War er vorher aber.

Doch, wirklich.

Und was ist nun, wenn ich ein Passwort mit einem Punkt gesetzt habe? Ich kann mich an die entsprechende Management Group nicht mehr anmelden. Also deinstalliere ich die CMC in Version 9 wieder, installiere wieder Version 8.5, ändere das Passwort und installiere wieder 9.0 (inkl. Deinstallation 8.5)? Besser: ich nutze das lokale Menü auf einem der Knoten und ändere das Passwort dort.

Oder ich weiß das vorher und spare mir die Fragezeichen. Da es nicht in den Papieren von HP steht, weiß ich es entweder nach dem ersten Mal oder nach dem Lesen dieses Artikels. 😉

Über Speichervirtualisierung

Virtualisierung ist in aller Munde. Alles und jeder wird virtualisiert – nur das mit der Cloud ist noch schlimmer (Cloud-Salat). So ist der Begriff der Virtualisierung im Storage-Bereich auch schon länger angekommen, lässt aber ebenfalls schon länger keine Rückschlüsse darauf zu, was eigentlich gemeint ist.

Eine Variante von Speicher-„Virtualisierung“ hat HP schon lange im Programm (schon bevor es zum Buzzword wurde, behaupte ich mal): EVA. Enterprise Virtual Array. Da wird innerhalb der Speichermaschine virtualisiert. Bei den klassischen Arrays, seien es EMC² AX, CX oder HP MSA oder NetApp FAS oder oder… sieht der Admin Controller und Platten, baut RAID-Sets (Aggregates bei NetApp) mit einem RAID-Level aus von ihm bestimmten Platten zusammen, legt Volumes an und stellt sie als LUNs zur Verfügung. Dazu muss er wissen, was auf den Volumes laufen wird, um die RAID-Level richtig zu wählen und die Anzahl der Platten passend zu bestimmten für die geforderte Performance und Verfügbarkeit – was dann für die Zukunft auch statisch so ist und bleibt. Bei einer EVA sieht der Admin die einzelnen Platten nur zur Information über den Hardware Status und um Speicher Pools zu definieren. Innerhalb eines Pools gibt der Admin Eigenschaften bzw. Anforderungen wie das Redundanz-Niveau vor. Dann legt er Volumes innerhalb der Speicher Pools an, für die er wiederum das Redundanz-Niveau und die gewünschte Größe definiert. Wie die EVA dann intern tatsächlich die Daten über die Platten verteilt, weiß der Admin nicht. Das ist dynamisch und abhängig davon, wie viele Volumes mit welchen Anforderungen es gibt. So ändert sich auch mit der Zeit die Menge des verfügbaren Speichers in einem Pool, denn die EVA balanciert und striped die Volumes dynamisch über den gesamten Pool. Das ermöglicht prinzipiell, dass sie die Verteilung auf Spindeln aus Performance- oder Platz-Sicht optimiert. Angeblich tut sie das auch – unmittelbar nachvollziehbar ist das im Detail aber nicht, ist halt virtualisiert.

SAN-Virtualisierung im Sinne von DataCore und anderen sieht hingegen so aus, dass man einen Windows Server braucht, auf dem die DataCore Software installiert wird. Was immer an Storage dem Server zur Verfügung steht – sei es Direct Attached (DAS) oder unterschiedliche SAN-Arrays im Backend, erst mal muss es der Windows Server erreichen können – kann dann als Basis für die Funktionalität verwendet werden. D.h. es wird das tatsächliche Backend virtualisiert/abstrahiert und nach vorne einheitlich per iSCSI präsentiert (das kann mit kleinerem Feature-Set auch mit einem Windows Storage Server erreicht werden).

SANmelody ist dabei auf ein HA-Pärchen limitiert, SANsymphony unterstützt N+1 Redundanz. Loadbalancing findet nur zu den Backends statt (wobei auch erst SANsymphony Multipathing-Arrays unterstützt), d.h. die Anwendungsserver (iSCSI Initiators) sprechen immer mit einem Target (DataCore Server). Andere Vertreter dieser Gattung sind OpenFiler, aber auch – in anderem Maßstab – HP SVSP.

Dann taucht in dem Zusammenhang auch noch ein HP Produkt auf, das allerdings weniger selbst virtualisiert als dass es wirklich optimal als Storage für Virtualisierungsumgebungen geeignet ist: HP P4000 (the artist formerly known as „Lefthand“). Was dort virtualisiert wird, ist eigentlich nur die Anzahl der Knoten; es wird ein Cluster gebildet aus N Knoten, der von allen iSCSI Initiators über eine Cluster-IP angesprochen wird und die tatsächlichen Verbindungen dann auf die beteiligten Knoten verteilt. Es entsteht ein „hyperredundanter“ Speicher-Cluster, der immer gleichzeitig Platz und Performance skaliert, sehr performant und praktisch immer Feature-complete ist (einmal kaufen, nichts nachlizensieren). Die Redundanz bis hoch zur Knoten-Ebene (Ausfall eines kompletten Speicherknotens) ist transparent für die iSCSI Clients, ein aufwändiges, fehleranfälliges und möglicherweise sogar manuelles Failover zwischen Sites ist nicht nötig.

Allerdings können P4000 Speicherknoten auch virtuell sein – als Virtual SAN Appliance (VSA) für VMware ESX(i), die wiederum das komplette Feature-Set zur Verfügung stellt. Betrachtet man nun also den ESX-Host als Vergleich zum o.g. Windows Server, der als Basis für z.B. DataCore SANsymphony dient, dann kann man mit einer P4000 VSA alle dem Host zur Verfügung stehenden Storage Backends nutzen und einheitlich, mit dem gesamten P4000 Funktionsumfang, präsentieren, mithin also virtualisieren. In diesem Konstrukt sind allerdings schon so viele Ebenen beteiligt, durch die ein Datenblock zum Lesen oder Schreiben wandern muss, dass das Szenario seine Grenzen haben sollte.

Bevor ich jetzt noch in Diskussionen oder Vergleiche einsteige (das hebe ich mir für einen anderen Beitrag auf), sage ich nur noch: Welches Schweinderl hätten’s denn gern? Nur weil ein Produkt oder Angebot das Label „Virtualisierung“ trägt, sagt das alleine noch nichts über seine tatsächliche Beschaffenheit oder Funktionsweise aus. Nicht von den Verkäufern einlullen lassen, immer hinterfragen und auf kompetente Beratung bestehen (und darin investieren), um herauszufinden, was für meine konkreten Anforderungen die passende Lösung ist!