Server Side Caching


[DE] PernixData FVP 3.5 und Architect 1.1 verfügbar 1

Diese Woche wurden die neuesten Updates für die Architect als auch für die FVP Software veröffentlicht, damit erhöht sich die FVP Versionsnummer auf 3.5 und die von Architect entsprechend auf 1.1.

 

PernixData Management Server als virtual Appliance

Die wohl wichtigste Neuerung betrifft beide Lösungen gleichermaßen, denn der PernixData Management Server ist ab sofort als virtual Appliance verfügbar. Somit entfällt die Anforderung an einen Windows Server samt SQL (Express) Datenbank. Dies Lösung kann von nun an noch bequemer und vor allem schneller installiert werden.

Einen direkten Migrationspfad der Windows basierten Variante auf die Linux Appliance, existiert derzeit noch nicht. Jedoch ist es grundsätzlich möglich, über ein paar manuelle Schritte, die bisherigen Performance Daten auf die Appliance zu migrieren.

In einem extra Post zeige ich, wie man die Appliance ausrollt und einrichtet.

 

FVP – Unterstützung für Raw Device Mappings (RDMs)

Mit diesem Update erhält FVP die Unterstützung für virtual als auch physical RDMs. Somit ist es zukünftig möglich, auch virtuelle Maschinen mit RDMs lesend (WT) sowie schreibend (WB) zu beschleunigen. Einzige Einschränkungen, die RDMs dürfen nicht gleichzeitig an mehrere VMs angehängt (Multi-Writer) sein.

  • Hin und wieder gibt es Use Cases, bei denen z.B. in-Guest iSCSI Disks verwendet werden, z.B. um innerhalb von VMs Tools wie SnapManager for Oracle zu verwenden. Somit bietet sich jetzt die Möglichkeit, diese weiterhin unter Verwendung von RDMs zu nutzen und parallel von der aktiven Beschleunigung durch FVP zu profitieren.

 

Architect – PDF Performance Reports & UI Optimierungen

Der recht kleine Versionssprung auf 1.1 deutet an, dass es sich hierbei um kleinere Optimierungen handelt. Wichtigste Neuerung, ist die Einführung von PDF Performance Reports. Diese erlauben viele Werte der Architect Software bequem als Report zu exportieren. Dabei ist der Start als auch Endzeitpunkt, also der zu exportierende Zeitraum, frei wählbar.Architect1.1CreatePerfReportArchitect1.1PerfReport

Zusätzlich gibt es noch ein paar Optimierungen am User Interface, welche das navigieren und analysieren noch weiter vereinfachen. Beispielsweise gibt es jetzt neue Breakdowns, in Form einer Read oder Write Analyse. Architect1.1Breakdowns

D.h. diese Breakdowns beinhalten automatisch alle Metriken welche für die Read oder Write Performance relevant sind.

BreakdownOverviewZusätzlich wird jetzt die Acceleration Rate für Read und Write I/Os gesondert dargestellt, was einen besseren Überblick gewährleistet. Denn sonst würde eine VM im Write-Through Modus, mit 0% Acceleration Rate für Write I/O, den Gesamtwert verfälschen.ReadWriteAccelRate

Neben weiteren kleineren Optimierungen, kann man jetzt vom VM Performance Plot aus, direkt zur jeweiligen VM navigieren und diese im Detail analysieren.

Architect1.1PerformancePlot


[DE] Rollout des PernixData Management Servers als virtual Appliance

Dieser Artikel beschreibt, wie einfach sich die PernixData virtual Appliance ausrollen und in Betrieb nehmen lässt. Die Appliance und der damit verbundene Management Server, ist die Grundlage zur Verwendung der FVP als auch Architect Software und in der Regel der erste Schritt bei einem Rollout der Softwarelösung.

Das folgende Video zeigt, wie die Appliance in rund 3 Minuten ausgerollt ist und für die finale Konfiguration zur Verfügung steht. Generell sollte dieser Prozess den meisten ohnehin bekannt sein, daher gehe ich hier nicht im Detail darauf ein.

Einzig eine Option gibt es währen des initialen Deployments des ova Templates zu beachten, die Größe (vCPU & RAM) der Appliance. Wie der Screenshot aus dem vSphere Client zeigt, benötig die kleinste Variante 2 vCPUs und 4 GB RAM. Die zu wählende Größe richtet sich nach der jeweiligen Größe der vSphere Umgebung (Anzahl Hosts & VMs).ApplianceconfigSize

Appliance Konfiguration & Größe der Umgebung RAM vCPUs
Tiny (1-5 Hosts oder 1-50 VMs) 4 GB 2
Small (6-100 Hosts oder 51-1000 VMs) 8 GB 4
Medium (101-400 Hosts oder 1001- VMs) 12 GB 8
Large (400 Hosts+ oder 4000 VMs+) 16 GB 16

Die VDMK ist dabei erst einmal in allen Varianten auf 100GB limitiert.

Nach erfolgreichem Rollout, ist die Appliance unter der angegeben IP Adresse per Browser erreichbar: https://<IP>/config

Die folgenden Schritte zeigen, was dann abschließend noch zu tun ist.

ApplianceEULA ApplianceFirstTimeLoginDefault Username: pernixdata

Default Passwort: pernixdataappliance

AppliancevCenterConnect

Der hier verwendete Benutzer muss über administrative Berechtigungen auf Ebene des vCenter verfügen. Generell ist es auch möglich, vor ab eine Custom Rolle anzulegen, welche nur über die nötigsten Berechtigungen verfügt. Hier verweise ich auf die Knowledgebase.

ApplianceNetworkSettings

Wer zukünftig die proaktiven Support Funktionalitäten von PernixPlus verwenden möchte, sollte sichergehen, dass die Appliance mit dem Internet (ggf. über Proxy) kommunizieren kann.

AppliancePassword ApplianceNTP

Jetzt kann ist es möglich, über den grünen Button die eigentliche PernixData UI anzusteuern, diese ist ebenfalls per Browser über https://<IP oder FQDN>:60002 erreichbar und führt nach dem Login zum PernixData Hub. Für den Login können die gleichen Benutzerkonten verwendet werden, wie auch für den Login in den vSphere Client, da die Appliance alle Login Anfragen an den vCenter Server weiterleitet und dieser letztlich über den Zugriff entscheidet.

PernixDataHub


[DE] Installation der PernixData Host Extension

Ein Punkt den ich bislang hier noch nicht im Detail beschrieben habe, ist die eigentliche Installation der PernixData Host Extension.

Die Host Extension, kommt in Form eines VIB Modules, welches den ESXi Host um die jeweiligen FVP & Architect Funktionalitäten ergänzt und bequem über zwei Methoden eingespielt werden kann.

Installation via esxcli (SSH)

Installation via Update Manager

Dazu habe ich jeweils ein Video vorbereitet, welche die Installation zeigt. Vor allem diejenigen, die bereits Treiber oder Patches über die beiden Verfahren installieren haben, wissen wie einfach dies geht. Wer darüber hinaus noch mehr Informationen und Details benötigt, der kann gerne einen Blick in die Installationsdokumentation werfen.


[DE] PernixData FVP – Cluster konfigurieren

Mit diesem Post möchte ich zeigen, wie man schnell & einfach man PernixData FVP konfiguriert denn dazu sind lediglich 3 Schritte nötig:

  1. FVP Cluster erstellen
  2. Beschleunigungsressourcen hinzufügen
  3. Virtuelle Maschinen für die Beschleunigung konfigurieren

Der Einstieg in die Konfiguration beginnt mit dem FVP Tab.FVPTab

Mit + Create legt man im ersten Schritt ein neues FVP Cluster an, vergibt einen Namen, wählt das Ziel vSphere Cluster und fügt optional noch eine Beschreibung an.

NoFVPClusters CreateFVPCluster Ein FVP Cluster ist letztlich ein logisches Konstrukt, welches die Beschleunigungsmedien, die zu beschleunigenden virtuellen Maschinen und deren entsprechende Beschleunigungsrichtlinie zusammenführt.  Es werden automatisch alle Hosts des vSphere Cluster dem FVP Cluster zugeordnet.

Wie bereits hier beschrieben, ist es grundsätzlich möglich, pro vSphere Cluster mehre solcher FVP Cluster zu erstellen und diese mit verschiedenen Medien wie z.B. RAM oder Flash zu konfigurieren. Dies erlaub es Workloads in Form von virtuellen Maschinen den geeigneten Medien zuzuweisen.

MultipleFVPClustersKlickt man entsprechend auf den Namen des Clusters, öffnet sich dessen Übersichtsseite, welche an dieser Stelle natürlich noch keine Konfiguration und folglich noch keine Daten enthält.FVPClusterOverviewPage

Über den Configuration Tab werden im zweiten Schritt die gewünschten Medien über den Punkt Add Acceleration Resources hinzugefügt. Hier werden entsprechend alle lokal im ESXi Host verbauten Ressourcen aufgelistet. In diesem Fall füge ich exemplarisch eine zu definierte Menge RAM, welche jeweils pro ESXi Host exklusiv reserviert wird, dem FVP Cluster hinzu.FVPClusterAddResourcesRAM

FVPClusterAccelerationResourcesOverviewRAM

Im dritten und letzten Schritt, müssen nur noch die zu beschleunigende VMs ausgewählt und deren Beschleunigungsrichtlinie zugewiesen werden. Dies geschieht über den Menüpunkt Datastores / VMs gefolgt von Add Datastore oder Add VMs.

Der folgende Screenshot zeigt exemplarisch das hinzufügen einer einzelnen VM.FVPClusterAddVMs

Fügt man einen Datastore hinzu, wendet FVP automatisch die ausgewählte Richtlinie auf alle virtuellen Maschinen an, welche Ihr Hauptverzeichnis inkl. .vmx Datei auf diesem Datastore gespeichert haben. Dies ist zum Beispiel im VDI Umfeld nützlich, wenn man sicherstellen möchte, dass automatisch alle neu provisionierten VMs beschleunigt werden.

Sowie die VM(s) hinzugefügt wurde, beginnt die Konfiguration. Die Spalte Write Policy gibt die konfigurierte Richtlinie an, während die Spalte Status die tatsächlich angewendete Richtlinie anzeigt.WritePolicyStatus

Sollte in beiden Spalten nicht die gleiche Richtlinie angezeigt werden, bedeutet das schlicht, das die gewünschte Richtlinie nicht angewendet werden konnte. Über das ? erhält man mehr Informationen zur Ursache.WritePolicyExplantion.Korrigiert man die Ursache, so wechselt der Status automatisiert in den gewünschten Zustand.WritePolicyStatusFixed

Den Menü Punk, oder besser gesagt das Feature Fault Domains, habe ich bereits hier genauer beschrieben. Daher gehe ich hier nicht genauer darauf ein.

Über den Punkt Advanced bieten sich darüber hinaus noch folgende Möglichkeiten:

  • Blacklist – VMs werden unter keinen Umständen beschleunigt und auch in der Architect Software zukünftig nicht mehr bei den Sizing Funktionalitäten berücksichtigt.
  • VADP – Ermöglicht es FVP mit dem Backup zu integrieren. Mehr dazu hier.
  • Network Configuration – Erlaubt es einen VMKernel Port zu definieren, über welchen die Daten zwischen den Hosts ausgetauscht werden. Alles Wissenswerte dazu, hier.