[DE] PernixData Architect Software 1.0 – Details zum Launch


Nach der Ankündigung im Sommer, während des Virtualization Field Day 5, ist es jetzt soweit, die neue „PernixData Architect Software“ erblickt offiziell das Licht der Welt und ist somit ab heute GA.

Man hat vielleicht PernixData bis dato nur mit der FVP Software und somit einer einzigen Lösung identifiziert. Es sei aber gesagt, dass es sich bei der Architect Software grundsätzlich um ein völlig eigenständiges Produkt handelt.

Natürlich gibt es zwischen den beiden Lösungen FVP & Architect eine entsprechende Integration und Synergien, auf die ich im Laufe der Zeit noch tiefer eingehen werde.

 

Zunächst mal die wichtigste Frage – Was ist PernixData Architect?

Bei der Architect Software handelt es sich um eine Lösung zum Storage Management. Soll heißen, dass hier VM und Storage Intelligenz vereint werden umso das Storage Design, Deployment und den Betrieb effizienter zu gestalten. Ziel ist es, auf VM Ebene völlig neue Einsichten in Sachen I/O Profil & Verhalten zu schaffen, dazu gleich mehr.

Dabei ist die Lösung komplett Hardware unabhängig, egal auf welcher Server & Storage Plattform eine virtuelle Maschine betrieben wird.

 

Das heißt jetzt was genau? Wo kann der Architect helfen?

Schauen wir doch mal etwas genauer hin. Storage ist nach wie vor ein forderndes Thema, vor allem, wenn man exakte Designs realisieren möchte, Troubleshooting betreiben muss oder einfach nur verstehen möchte, was einzelne Applikationen so tun.

Interessiert einem da die Welt aus Sicht des Storage Arrays als Ganzes oder einer einzelnen LUN? Eher weniger. Viel interessanter ist doch, was einzelne VMs und damit die darin laufenden Applikationen machen. Denn nur so kann man klassischen Problemen wie „Mein SQL Server ist langsam“ mit Präzision zu Leibe rücken. Interessant ist doch welches I/O Profile einzelne VMs (oder natürlich einer ganzen Infrastruktur) aufweisen und wie dieses sich auf die Performance auswirken.

Ich stelle einfach mal ein paar Gegenfragen und denke dann wird es langsam klar:

Wie viele Durchsatz? Wieviel IOPS, in welchen Intervallen? Bei wie viel Latenz? Welchen Einfluss hat das Lese- / Schreibverhältnis? In welchen Blockgrößen? Wie trägt die Blockgröße zur Performance/Latenz der VM bei? Welche I/O Eigenschaften weißt die eigene Infrastruktur auf und welche Anforderungen stellt diese somit an die Storage Infrastruktur?

Der bisherige Ansatz wäre die Daten verschiedener Tools und verschiedener Stellen zu sammeln, sofern diese Verfügbar sind und sinnvoll zu korrelieren. Allzu oft scheitert dies auf Grund der fehlenden VM-Awareness, Tools, Zeit, etc.

Und genau hier setzt die Software an. All diese Fragen (und noch mehr) mit Leichtigkeit, individuell auf VM Ebene zu beantworten.ArchitectVMWorkloadArchitectVMWorkloadRWBlockSizeArchitectWorkloadOverview

Einzelne Features werde ich in einer Serie kurzer Blog Post individuell beschreiben.

 

Woher kommen die Daten?

FVP als auch Architect basieren auf der gleichen Host Extension (VIB Modul) und somit ist es möglich, die Messpunkte & Informationen direkt aus dem I/O Pfad der einzelnen virtuellen Maschinen zu sammeln.

In diesem Zusammenhang kann man sagen, dass eine Art Big Data Analyse auf dem Management Sever betrieben wird, damit man die Fülle an Informationen in ein userfreundliches und konsumierbares Format bringt. D.h. während das Herzstück von FVP direkt im Host lebt, so kann man sagen, lebt der Architect im Management Server (welcher der gleiche wie bei FVP ist) um dort die Verarbeitung und die Visualisierung vorzunehmen.

 

Welchen langfristigere Nutzen gibt es?

Hier sei gesagt, dass es meines Erachtens nach drei wichtige Punkte gibt, warum Architect einen langfristigen Nutzen bietet:

  1. Ohne den Architect ist es umso schwerer im Betrieb Storage seitiges Troubleshooting zu betreiben und Fragen des Business wie z.B. „Warum dauert die Auswertung xy so lange“ schnell und präzise beantworten zu können.
  2. I/O Profile von Applikationen unterstehen ständigem Wandel durch Updates, Anpassungen der Applikation, Skalierung wie z.B. Anzahl der User etc. Somit variiert natürlich auch die Performance und es ist wichtig dies kontinuierlich auf den Prüfstand zu stellen und zu optimieren.
  3. Dies Führt mich zur „Recommendation Engine“. Diese überwacht das I/O Verhalten und die Performance der VMs und wenn es hier zu negativen Veränderungen kommt, zeigt diese die Lösung an und gibt entsprechend mögliche Ursachen & Lösungsvorschläge für deren Lösung vor.

ArchitectRecommendations

 

Wie komme man an die Architect Software?

Dies ist entsprechend leicht. Für FVP Bestandskunden genügt ein Upgrade von FVP 2.5 bzw. 3.0 auf 3.1 welches automatisch die Option zur Trial der Architect Software mitbringt und einfach via UI aktiviert werden kann. Interessenten müssen lediglich das neuste 3.1 Softwarepaket installieren und können dann individuell die Trial von FVP und/oder Architect aktivieren.

 

Was ist PernixData Architect (aus meiner Sicht) nicht?

Um gleich zu Beginn zu vermeiden, dass man die Lösung in die falsche Schublade steckt. Architect …

  • … ist kein Monitoring Tool im klassischen Sinne, um z.B. anzuzeigen ob etwas online oder offline ist
  • … nutzt daher auch nicht das Prinzip, Kacheln/Lichter grün oder rot leuchten zu lassen um Probleme anzuzeigen
  • … Ist kein reines Sizing Tool und kein Ersatz des vROPS, sondern komplementär dazu.
  • … nutzt aktuell keinerlei Performance Daten aus dem vCenter, sondern sammelt alle Daten aus der Host Extension
Print Friendly, PDF & Email

Related Post

It's only fair to share...Tweet about this on TwitterShare on LinkedInEmail this to someone

Leave a comment

Your email address will not be published. Required fields are marked *