Archiv für die Kategorie ‘Storage’

Beispiel eines vmware High Availabe Stretched Clusters

Auch wenn dieses Thema schon weit ausgedehnt wurde, z.B. von Duncan Epping und Frank Denneman in Ihrem Deep Dive Buch , möchte ich ein Design Beispiel aus meiner Vergangenheit  hier gerne wiedergeben.

Beim Aufräumen alter Dokumente bin ich auf ein Konzeptpapier gestossen welches Grundlage dieses Artikels ist. Es diente damals dazu eine ältere vmware Produktionsumgebung die neu aufgebaut werden sollte so zu designen, das alle üblichen High Availability (HA) Fälle von der Umgebung möglichst automatisch bzw. mit geringem administrativen Eingriffen verfügbar bleibt. Also die üblichen Ziele: Hohe Verfügbarkeit mit möglichst minimalen Downtimes für alle Unternehmenswichtigen Services.

Ich denke das dieses Beispiel gut aufzeigt wie mit „normalen“, heute verfügbaren Mitteln, ohne Exorbitantem finanziellem Aufwand dieses Anforderung erfüllbar ist.

Ausgangssituation

Im genannten Umfeld war eine alte vmware 3.5 Umgebung sowohl Server- als auch Storage-seitig durch neues Equipment zu ersetzen. Um dem erwarteten Datenzuwachs Rechung zu tragen sollte goßzügig genug geplant werden. Ausserdem stand der Aspekt des möglichst einfachen, zeitlich kurzem und für die Anwender nicht spürbaren Umzugs auf die neue Umgebung im Anforderungs Katalog.

Die vmware 3.5 Umgebung war auf zwei Gebäude verteilt, die über Glasfaserleitungen miteinander verbunden sind (Distanz ca. 50 – 100 m). Somit kam das Konzept für einen sogenannten „Stretched Cluster“ zum Einsatz.

Bei einem Stretched Cluster sprechen wir von einer vmware vSphere Umgebung die sich auf zwei Räume / Gebäude / Brandabschnitte verteilt, aber von einem einzigen vCenter Server verwaltet wird.

 

Komplette Übersicht - vmware vSphere Stretched Cluster

Bild 1: Komplette Übersicht – vmware vSphere Stretched Cluster

Diese Bild zeigt den Architekturplan des gesamten Projektes und nimmt natürlich einige Elemente der Lösung vorweg.

Die Komponenten der Lösung

Wie man am Bild 1 sicher erkennen kann, besteht die Lösung aus folgenden Komponenten (ich nenne Hersteller nur dann wenn es für die Erklärung zwingend notwendig ist, anderfalls sind hier verschiedene Hersteller als Lieferanten einsetzbar):

  1. Auf Seite A und aus Seite B werden jeweils eine gleiche Anzahl gleicher Server als ESXi Hosts aufgesetzt.
  2. Auf beiden Seiten werden gleiche Storage Systeme installiert.
  3. Auf jeder Seite wird eine DataCore SDS mit SanSymphony V installiert

Zu den Details: In beiden Server Räumen der Seite A und Seite B werden praktisch indentische Hardware Umgebungen aufgebaut, beide Seiten sind autark betreibbar! Die Server und Storage Systeme sind so auszulegen das im Worst-Case eine Seite allein die gesamte Last tragen kann.

Verbunden sind hierbei die Storage Systeme via Fibre Channel (in diesem Fall 8GB, es könnte aber auch mit iSCSI gearbeitet werden. Da DataCore in der planten Version kein NFS unterstützte sähe eine NFS basierte Lösung etwas anders aus). Die DataStores werden jeweils via synchronem Spiegel auf die andere Seite gespiegelt und stehen auch dort zur Verfügung.

Bitte denken Sie daran auch das vSphere Management Netz so redundant auszulegen, das später alle Ausfall Scenarien abgedeckt werden (warum heiß der „Single Point of Failure“ nur so ;-))

Das die Storage Verbindungen und natürlich auch das Produktivnetz (im Bild Hausnetz) redundant ausgelegt werden ist sicher selbstverständlich.

Die ganze Lösung wurde als sog. Non-Uniform stretched vSphere Cluster realisiert.

Uniform stretched Cluster

Ein Uniform stretched Cluster bedeutet das alle Hosts und alle Storage Systeme so verbunden sind das alle alles zu jederzeit „sehen“. Das heisst die ESXi Hosts haben permanent Zugriff auf alle Datastores jeder Seite.

Non-Uniform stretched Cluster

Ein Non-Uniform stretched Cluste bedeutet das die Hosts einer Seite auch nur „aktiv“ mit den Datastores der Storage Systeme dieser Seite verbunden sind. Im Fehlerfall muß nun eine, wie auch immer geartete Lösung dafür sorgen das auf die jeweils andere Seite geschwenkt wird. Die Daten werden also „nur“ auf Storage Ebene repliziert (synchron oder asynchron). Hier bieten viele große Storage Hersteller eigene Plugins für „gutes“ Geld an.

Ausfall Scenarien

Betrachten wir nun nacheinander die verschiedenen Ausfall Scenarien und wie sich die Umgebung dann jeweils verhalten soll.

Ausfall eines Hostes auf einer Seite

Fällt ein Host einer Seite des Clusters aus, so greift vmware vSphere HA und startet die gecrashten VMs auf den verbleibenden Hosts dieser Seite neu. Damit das funktioniert sollte via DRS Rules und den dort konfigurierbaren Affiniti Rules über Gruppen eine „Sollte immer auf dieser Hostgruppe laufen“ Regel definiert werden. Diese erkläre ich jetzt hier nicht, vielleicht in einem anderen Artikel irgendwann. Kurzgesagt bedeutet diese Regel, das VMs im Normalfall möglichst auf bestimmten ESXi Hosts einer Gruppe laufen sollen. DRS sorgt dann dafür das dieses so ist. In unserem Fall haben wir zwei Hostgruppe: Hosts der Seite A und Hosts der Seite B. Hintergrund: Wir arbeiten mit einem Non-Uniform Cluster und die VMs auf den Hosts der Seite A sollen auch das Storage der Seite A nutzen um z.B. mögliche Laufzeiten (und Latenzen) zur anderen Seite zu minimieren.

Bild 2: HA-Host einer Seite fällt aus

Bild 2: HA-Host einer Seite fällt aus

Ausfall eines Datastores einer Seite

Falls ein Datastore einer Seite ausfällt (siehe Bild 3) so kommt es darauf an was genau unter „Ausfall“ zu verstehen ist. Fällt „nur“ eine Platte des Storage Systems aus, so haben wir hoffentlich kein direktes Problem für unsere VMs da dort durch RAID usw. der Fehler für den Host und die VMs transparent abgefangen wird. Sollte es dagegen zu einem Totalausfall eines Storage Bereiches dieser Seite kommen, fallen die VMs herunter und vmware HA kann zum Einsatz kommen, allerdings nur dann, wenn jetzt auf die gespiegelten Daten der anderen Seite zugegriffen werden kann!

Dazu muss jetzt, wie vorher (unter Non-Uniform Cluster) beschrieben, jemand die Storage Pfade „umschalten“, sprich die gespigelten Datastores der Seite B nun als aktiv an die Seite A anbinden. Unsere Lösung die hier projektiert wurde basiert auf  DataCore SANsymphony, welches einen transparenten Failover bereitstellt. Dieser schaltet im Normalfall so schnell um, das vmware HA garnicht erst zum Einsatz kommen muss. DataCore sorgt in unserem Fall auch für den Synchronen Spiegel.

Bild 3: HA Datastore einer Seite fällt aus

Bild 3: HA Datastore einer Seite fällt aus

Ausfall einer gesamten Host Cluster Seite

Kommen wir nun zu dem Fall das uns eine gesamte vmware Cluster Seite ausfällt. Hier greift wieder vmware HA, denn wir haben ja in unserer DRS Rule gesagt „sollte“, nicht „darf nur“. HA versucht nun die VMs der Seite A die ja mit den Hosts gestorben sind auf der Seite B neu zu starten. Geht das? Tja in unserem Fall müssen die Synchronen Datastores die von Seite A auf Seite B gespiegelt wurden dort „aktiv“ sein, oder kurz gesagt müsste jemand die Datastores der Seite A auf den Hosts der Seite B „aktiv“ schalten! Somit haben wir zwei Möglichkeiten. Diese können gern im Anschluß diskutiert werden.

Bild 4: Komplette ESXi Cluster Seite fällt aus

Bild 4: Komplette ESXi Cluster Seite fällt aus

Bitte daran denken, daß in diesem Fall auch die vCenter Server VM betroffen sein kann. Das bedeutet allerdings nur, das für die Zeit des wideranstartens durch vmware vSphere HA kein DRS läuft! DRS ist eines der wenigen Funktionen die nur funktionieren wenn der vCenter Server läuft.

Ausfall einer Seite ohne virtuelle Storage Pools

Betrachten wir im Anschluß an den vorhergehenden Failure Fall nun den Ausfall einer ganzen Seite, sowohl Hosts als auch Storage. Was hier passiert ist etwas aufwändiger. In diesem Fall haben wir keine virtuellen Storage Pools, sondern „klassische“ Anbindung. Es läuft so ähnlich wie unter „Ausfall eines Datastores einer Seite“ ab. Irgendjemand (z.B. via Skript) muß die Synchon gespiegelten Datastores der Seite A auf Seite B den Hosts der Seite B „aktiv“ schalten. Nun sehen diese Hosts die VMs und vSphere HA kann mit dem Restart der VM beginnen. Knackpunkt ist hier die Umschaltung der Storage Pfade. Wie gesagt „Irgendjemand“ muss das tun! Nur ist der Irgendjemand dann auch da und sieht das Chaos kommen ;-( ?

 

Bild 5: Ausfall einer kompletten Seite - Hosts und Storage

Bild 5: Ausfall einer kompletten Seite – Hosts und Storage

Ich selbst bin KEIN Freund von solchen „Desaster-Skripten“ denn die wollen gepflegt sein (bei jedem Storage Umbau usw. muss nachgepflegt werden). Storage Pfade sind auch nicht gerade „lesefreundlich“ und entsprechendes KnowHow sollte vorrätig sein.

Ausfall einer Seite mit virtuellen Storage Pools

Aus den genannten Gründen im letzten Abschnitt habe ich damals die Lösung mit sogenannten virtuellen Pools favorisiert. Hierbei sollte in diesem Konzept, DataCore einer der Pioniere der Storage Virtualisierung zum Einsatz kommen. DataCore stellt den angebunden ESXi Hosts virtuelle Datastores zur Verfügung die auf virtuellen Storage Pools beruhen. Diese virtuellen Pools bestehen aus Storage Bereichen beider Seiten und beinhalten unter anderem den Synchronen Spiegel von Seite A auf Seite B. Somit ist für die ESXi Host der komplette Storage Aufbau intransparent. Sie sehen nur den Pool. Fällt uns nun das Storage System einer Seite, oder die gesamte Seite aus, so sorgt DataCore dafür das die ESXi Hosts weiter den Pools so sehen als sei alles in Ordnung! Im Fall des Ausfalls der gesammten Seite muss allerdings vSphere HA auch noch arbeiten. Da dieses aber, bei korrekter Implementierung (siehe z.B. hier) absolut zuverlässig arbeitet, sollte die tatsächliche Downtime selbst in diesem Extrem-Fall relativ kurz sein. Das Schöne dabei ist, das eigentlich niemand „geweckt“ werden muss. Das System arbeitet alleine an der Wiederherstellung.

 

Bild 6: Totalausfall einer Seite mit virtuellen Pools

Bild 6: Totalausfall einer Seite mit virtuellen Pools

Abschussbemerkungen

Auch wenn ich selbst hier DataCore präferiere, kann das gezeigte Scenario auch mit anderen Storage Lösungen ähnlich aufgebaut werden. Ausserdem sollte trotz solch einer Lösung NIE auf ein funktionierendes Backup Konzept mit entsprechender Lösung verzichtet werden (soll es tatsächlich geben 😉 )

Übrigens kann DataCore durch seine „Proxied Volume“ Funktion auch beim Umzug einer alten- auf eine neue Storage Lösung sehr gute Dienste leisten.

Über eine Diskussion dieser Lösung würde ich mich freuen, denn soweit mir bekannt ist wurde diese Konzept aus verschiedenen Gründen nie umgesetzt. Schade oder?

Somit ist es mir gelungen durch ein paar „Nachteinsätze“ doch wieder einen Artikel zu erstellen.

 

Online Project Management

Advertisements

VMware WebClient PlugIn von Tinitri: Eines der ersten PlugIns für den neuen WebClient! Erste Eindrücke

In diesem Beitrag möchte ich einen ersten Eindruck vom neuen Trinitri PlugIn für den VMware WebClient weitergeben. Die ScreenShots sind mir dankenderweise von Tintri selbst zur Verfügung gestellt worden. Wann dieses PlugIn verfügbar ist kann ich leider nicht sagen. Mit diesem Beitrag möchte ich an den Artikel (Trintri Global Center) anschließen.

Ausblick

Tinitri zeigt sich z.Z. hoch innovativ, besonders was die Weiterentwicklung und Neuentwicklung von Management Tools und deren Integration betrifft. Ich persönlich sehe schon lange einen wachsenden Bedarf an guten und trotzdem einfach zu handhabenden Management Lösungen. Das Tinitri Global Center ist hier sicher ein guter Ansatz.

Die Integration der Tintri Storage Systeme dirket in den vCenter Server bzw. den WebClient als zentrales Management ist da nur naheliegend und mehr als sinnvoll.

Tinitri hat mir hierzu einen ersten Einblick in das zu erwartende PlugIn gewährt und auch einige illustrierende Screenshots zur Verfügung gestellt. Besonderen Dank hier zu an die hilfsbereiten Tinitri Kollegen.

PlugIn -Screenshots

Das PlugIn integriert sich nahtlos in den WebClient von VMware und bietet eine Reihe von Möglichkeiten die nun keinen extra Zugriff auf die Tintri Management Konsole notwendig macht. Das fängt z.B. bei der Anbindung der Tintri Lösung an vSphere und der Bereitstellung von DataStores an:

Bild 1: Add VMware Storage

Bild 1: Add VMware Storage

 

Virtual Machine Infos

Auch der Summary Tab einzelner VMs die auf der Tinitri Box liegen wird mit wichtigen und nützlichen Infos angereichert (ähnlich dem was der vCenter Operations Manager macht):

Bild 2: VM Summary mit Tintri Infos

Bild 2: VM Summary mit Tintri Infos

Auch eine Anzeiger welche VMs denn die Top Konsumenten sind ist sicher oft sehr hilfreich (auch für Optimierungen!)

Bild 4: Top Latency VMs

Bild 3: Top Latency VMs

 

Tinitri Storage Infos

Da die Tinitri Systeme sich ja mit dem vCenter Server verbinden und es dem Administrator möglich ist hier steuernd einzugreifen (z.B. das eine VM mit mehr % auf den SSDs verbleicht usw.) bietet das PlugIn Optimierungsmöglichkeiten direkt an:

Bild 4: Best Practice Übersicht

Bild 4: Best Practice Übersicht

Und im Detail:

Bild 5: Best Practice Detail

Bild 5: Best Practice Detail

DataStore Summy Tab mit Tintri Infos:

Bild 6: Tintri DataStore Summary

Bild 6: Tintri DataStore Summary

SAN Snapshots

Das PlugIn bietet die Möglichkeit VMs mit der Tintri SAN SnapShot abzusichern:

Bild 7: VM SAN SnapShots

Bild 7: VM SAN SnapShots

Und im Detail:

Bild 8: Schedule Snapshots

Bild 8: Schedule Snapshots

 Fazit

Ich hoffe das ein guter erster Eindruck dieses sehr nützlichen PlugIns vermittelt wird. Jeder der eine oder mehrere Tinitri Boxen betreibt sollte sich das PlugIn und gegebenenfalls auch das Global Center näher ansehen!

(Alle Grafiken, sofern nicht anders angegeben © by Tintri)

Das neue Tinitri Global Center – zentrales Management einer oder mehrerer Tintri Appliances

Nachdem ich sehr lange nichts mehr über Tintri geschrieben haben (Letzter Beitrag) sollen endlich mal wieder einige sehr interessante Neuigkeiten dieses Herstellers vorgestellt werden.

Tintri, als einer der innovativen, relativ neuen, Storage Anbieter speziell für den Virtualisierungs-Markt hat schon zur VMWorld 2013 seine neue Management Lösung Tintri Global Center vorgestellt.

Diese stellt mit der Version 1.0 einen ersten Schritt in Richting zentrales Management, erweitertes Management und auch später mehr Mandanten Management (Multi Tenancy) dar.

Global Center - Übersicht

Global Center – Übersicht

Es handelt sich dabei um eine virtuelle Appliance die einfach in bestehende VMware vSphere Umgebungen integiert werden kann (OVF). Diese koppelt sich an den vCenter Server und an die vorhandenen Tintri Boxen. Anschließend werde in der aktuellen Version 1.0 rein informativ eine Menge nützlicher Informationen bereitgestellt.

Der verwendete „Kachellook“ sieht, ohne Wertung ;-), ein wenig wie Windows 8 aus, ist aber durchaus sehr informativ und praktikabel zu nutzen.

Erweiterte Möglichkeiten mit dem Global Center

In dieser Version 1.0 ist das Global Center, wie bereits gesagt, als reiner erweiterter View zu sehen. Dabei werden aber z.B. die Daten der Tintri Boxen nun nicht nur 7 Tage zurück, sondern per default 30 Tage zurück auswertbar. Ein kleiner, aber manchmal entscheidenter Zeitgewinn.

Übersicht VMs - Messwerte aus vCenter Server und Tintri

Übersicht VMs – Messwerte aus vCenter Server und Tintri

Informationen aus dem vCenter Server werden dabei mit Informationen aus den Tintri Boxen zusammen bereitgestellt. Diese kann beim Troubleshooting sehr nützlich sein.

Global Center - verfügbare Metricen für VMs

Global Center – verfügbare Metricen für VMs

Zukunft

In den nächsten Versionen sollen auch Aktionen direkt über das Global Center ausführbar sein. Dieses betreffen z.B. die Mandantenfähigkeit, Snapshot Erstellung usw.

Im Bereich Mandantenfähigkeit soll es dann möglich werden z.B.:

  • Quotas für VMs zu vergeben
  • Bestimmten Usern nur bestimmte VMs bzw. Datastores zugänglich zu machen (Usermanagement)
  • virtuelle DataStores anzulegen die verschiedene Einstellungen beinhalten
  • z.B. min/max IOPS und anderes für VMs bereitzustellen

Aussichten

Auf dem Partner Channel Update letzte Woche wurde zusätzlich ein echter Knaller als Beta präsentiert.

Ein VMware WebClient Plugin, welches all die schönen neuen Funktionen des Global Centers direkt in den WebClient integriert! Leider habe ich noch keine Möglichkeit gehabt das live auszuprobieren, werde die Infos aber gern nachreichen sobald möglich. Das währe eine echte Innovation, da die verfügbaren Plugins der großen Hersteller für den WebClient doch leider noch sehr spärlich sind. Hier besteht die Möglichkeit für Tintri Vorreiter zu sein.

NAKIVO Backup and Restore : Update der virtuellen Appliance auf Version 3.9.1

In diesem Blog zeige ich wie einfach man eine NAKIVO virtuel Appliance (Linux Basis) auf eine neue Version updaten kann.
Für alle „Nicht Linuxer“ habe ich einige Screenshots erstellt, die Schritt für Schritt die Anleitung von NAKIVO „plastisch“ darstellen.

Step 1: Kopieren des „Linux Installers“ auf die Appliance per WinSCP

Als erstes muß man sich von der NAKIVO Webseite (Download-Trial) den „Linux Installer“  downloaden. Leider muß man sich jedes mal neu registrieren. Die Datei die ich verwendet habe heißt „NAKIVO_Backup_&_Replication_v3.9.1.5085_Installer-Linux.sh

Diese nun per WinSCP z.B. in das /tmp Verzeichnis der Appliance kopieren.

WinSCP Upload

WinSCP Upload

Step 2:Installation der neuen Version als Update auf Kommandozeile

Nun an der Appliance als root anmelden (Putty lässt grüßen)

Putty: Login als root

Putty: Login als root

Jetzt in das /tmp Verzeichnis wechseln und mal nachsehen wie unsere Datei heißt.

ls -a NAKIVO*

ls -a NAKIVO*

Anschließend müssen wir den Installer ausführbar machen. Da der Dateiname ein „&“ enthält muß der Dateiname bei allen Kommandos in Hochkomma gesetzt werden!

Ausführbar machen: chmod -x

Ausführbar machen: chmod -x

Im Putty kann man schön per Maus kopieren 🙂 und anschießend durch die „grüne“ Farbe sehen das dieser Installer jetzt ausführbar ist.

Bleibt nur noch das Ausführen des Installers:

Ausführen des Installers

Ausführen des Installers

Bestätigen einiger Fragen mit „Y“:

Bestätigen der Fragen beim Update

Bestätigen der Fragen beim Update

Das wars schon!

Fazit

Nach meinem Dafürhalten auch hier eine denkbar einfache Aktion, die auch von allen Kommandozeilen „Neulingen“ bewerkstelligt werden kann. – Viel Spaß damit

NAKIVO Backup and Restore für vmware – Installation OVA Appliance

Wie bereits angekündigt möchte ich hier eine Installationsanleitung für die NAKIVO Backup and Restore Lösung vorstellen. Ich verwende dazu die angebotene virtuelle Appliance (OVA-Format).

Diese virtuelle Maschine basiert auf UBUNTU 12 und lässt sich wie gewohnt sehr einfach in eine vmware vSphere Umgebung einspielen. Anschließend ist die VM noch zu konfigurieren. Dieses ist zwar teilweise Linux Shell basiert, aber recht einfach zu handhaben und in der Anleitung gut dokumentiert. Ich denke mit diesem Blog Eintrag sollte jeder Interessierte schnell und einfach zu einer lauffähigen Installation kommen. In der genutzten Demoumgebung auf Basis vmware vSphere 5.1 habe ich INKLUSIV erstem (wenn auch kleinen) Backup Job ganze 20min benötigt. Für mich spricht das schon mal für die Lösung, zumindest was die Installation betrifft.

Grundkonfiguration virtuelle Appliance

Auf die Beschreibung des Imports einer OVA-Format Appliance möchte ich an dieser Stelle verzichten und als bekannt voraussetzen.

Kommen wir also zur Grundkonfiguration bezüglich Netzwerk.

Netzwerkkonfiguration der Appliance

Dieses ist der einzige Installationsschritt der eine direkte Berührung mit LINUX und der Shell benötigt. Etwas VI-Editor Kenntnisse helfen, sind aber nicht wirklich notwendig, da selbst die wenigen Editor Kommandos in der Anleitung angegeben werden.

Also erste  mal einloggen:   USER: root     Passwort: root

NAKIVO: Login Screen OVA Appliance

NAKIVO: Login Screen OVA Appliance

So nun müssen wir leider noch den LINUX Editor VI bemühen um die Netzwerk – IP Konfiguration vorzunehmen.

Aufruf /etc/networks/interfaces mit dem VI

Aufruf /etc/network/interfaces mit dem VI (Editor)

Ein paar Kurze VI Kommandos:

  • VI Kennt zwei Modi, Ansehen und Bearbeiten. Aus dem Bearbeitungsmodus kommt man mit „ESC“
  • in den Bearbeitungsmodus auf verschieden Wege:mit „x“ kann man ein Zeichen Löschen
    • „i“ für „insert“
    • „o“ für „Zeile anfügen“
  • mit „r“ ein Zeichen erstetzen
  • mit „:wq“ den Editor beenden und speichern
Editieren mit VI

Editieren mit VI

Nach dem Editieren der Werte wie angegeben mit „:wq“ die Datei spechern. Nun muss der Network Daemon neu gestartet werden.

Networking Daemon neu starten

Networking Daemon neu starten

Dabei werden die Services neu konfiguriert und gestartet:

restart Networking

restart Networking

Nun sind wir hier fertig und können die Appliance unter Ihrer IP-Adresse per Browser erreichen.

Grundkonfiguration per Browser

Aufruf im Browser:

URL von NAKIVO

URL von NAKIVO

Und einloggen (nach dem Hinweis das der User und das Passwort gesetzt werden sollen):

Beim ersten Einloggen wird KEIN User und Passwort benötigt

Beim ersten Aufruf!

Beim ersten Aufruf!

vCenter Server Verbindung einstellen

Nun die vCenter Server Verbindung einstellen

vCenter Server KonfigurationvCenter Server Konfiguration

Nun discovert NAKIVO die angegebene vCenter Server Umgebung.

vCenter Server Discover

vCenter Server Discover

Jetzt wird die vCenter Server Umgebung angezeigt.

vCenter Server Umgebung

vCenter Server Umgebung

Lizenz einspielen nicht vergessen!

Lizenz

Lizenz

Weitere Konfiguration: Repository und Notification

Als Zielverzeichnisse der Backup bzw. Replikationsjobs können nun noch verschiedene Repositories konfiguriert werden.

ON Board Repository der Appliance

ON Board Repository der Appliance

Unter „Configuration“ > „Backup repositories“ am unteren Bildschirmrand den Button

Add Backup Repository

Add Backup Repository

und konfigurieren!

Beispiel: CIFS Share als Repository

Beispiel: CIFS Share als Repository

Nun noch die Notification Infos hinterlegen.

E-Mail Notification Konfiguration

E-Mail Notification Konfiguration

Jetzt sind wir fertig und es kann der erste Backup Job angelegt werden. Dazu die „Configuration“ Webseite über den Button „Exit Configuration“ verlassen (siehe Screenshot oben)

Backup Job anlegen

Auf der Startseite von NAKIVO kann jetzt ein Backup Job angelegt werden.

Startseite (Home Screen)

Startseite (Home Screen)

Ein Wizard leitet durch das Anlegen des Backup Jobs.

Fazit

Alles in allem eine recht einfache Angelegenheit, die in wenigen Minuten erledigt ist. Ich hoffe dieser Beitrag reicht zur einfachen Konfiguration für alle die NAKIVO einmal testen wollen.

NAKIVO Backup and Restore für vmware

Heute möchte ich ein recht interessante neue Backup und Restore Lösung für vmware vSphere vorstellen. Es handelt sich um die Lösung der Firma NAKIVO. Diese ist sicher den wenigsten bekannt, dahinter stehen aber bekannte (oder auch wenigerbekannte 😉 ) Personen aus dem vmware Periferiebusiness mit vielen Jahren Erfahrung.

Webseite: NAKIVO

Einige der NAKIVO Mitarbeiter und der Gründer waren früher bei vizioncore – Quest – jetzt DELL und hatten dort z.B. die Lösungen vControl oder vSRM entwickelt.

Higlights der Lösung

Die NAKIVO Lösung ist äussert schnell implementiert und besitzt einige Fähigkeiten welche diese Lösung vom Mitbewerb unterscheidet.

I. Installationsmöglichkeiten

NAKIVO kann nativ unter Windows und Linux (z.Z. Ubuntu und SLES) installiert werden. Ausserdem existiert eine fertige Ubuntu basierte Virtuelle Appliance (OVA).

Das Deployment der Lösung ist in 15-20min erfolgt! (selbst ausprobiert) Also eine äusserst schnelle und einfache Implementierung.

II. Besondere Features

NAKIVO ist von der Bedienungsoberfläche vollständig Web basiert mit einer modernen und übersichtlichen Oberfläche.

NAKIVO WebInterface

NAKIVO WebInterface

a) Mandantenfähigkeit

Hochinteressant wird die Lösung durch die Möglichkeit Mehrmandanten Umgebungen zu sichern und den einzelnen Mandanten Zugriff per Webinterface auf die eigenen VMs zu bieten! Dieses ist sicher besonders für Hoster und Provider sehr interessant. Hier können auf Anbieter- und Kundenseite Mehrwerte geschaffen werden.

© Screenshot NAKIVO: Mandantenfähig - Admin Sicht

© Screenshot NAKIVO: Mandantenfähig – Admin Sicht

b) Backup mit kurzen Zyklen – Replikation

Des weitere besteht die Möglichkeit Backup Jobs praktisch ähnlich wie Replikationen mit sehr kurzen Zyklen zu schedulen. Dadurch können wichtige VMs mit sehr geringem Zeitversatz zurückgesichert werden (siehe rote Markiertung im Bild unten).

NAKIVO Scheduler / encrypion

NAKIVO Scheduler / Encryption

Des weiteren bietet die Lösung die Möglichkeit die Repositories zu verschlüsseln (siehe grüne Markierung im Bild oben).

Ebenso kann eine „Network acceleration“ aktiviert werden. Dazu werden die Backup Daten komprimiert um z.B. Bandbreite zu sparen und Backup Daten auch über WAN Strecken auf Kundenrepositories zu sichern!

Des weiteren nutzt NAKIVO selbstverständlich Funktionen wie vmware Change Block Tracking (CBT).

c) Repositories

Als Repositories können ein internes Repository (ca. 400 GB) und natürlich auch externe wie CIFS und NAS Shares sowie Cloud Dienste (z.B. Amazon Cloud und andere) genutzt werden. Die Repositorys können, wie schon gesagt verschlüsselt und dedupliziert werden.

III. Preismodell

Ohne direkt auf Preise eingehen zu wollen, halte ich das Preismodell für attraktiv. (Siehe http://nakivo.com/quote.htm )

Es gibt z.B. ein extra Preismodell für vmware Essentials Plus (ca. 150€)

Fazit

Aus meiner Sicht als ehemaliger vizioncore vRanger Kenner, sehe ich diese Lösung als durchaus interessante Alternative zu den etablierten Lösungen aus dem vmware Umfeld. Besonders für Hoster und MSPs bietet NAKIVO so einige Alleinstellungsmerkmale.

Durch die schnelle Implementierung (auch als OVA) steht einem kurzen Test in vielen Bereichen sicher nichts entgegen.  Daher mein Tipp „selbst ausprobieren“. Ich werde demnächst in einem weiteren Artikel die Installation und Konfiguration der OVA vorstellen.

Berufsbedingt muss ich mich z.Z. auch mit einem, für mich etwas weniger geläufigen Thema auseinandersetzen. Storage war für mich früher etwas das ich angefordert habe 😉

  • Ich brauche soviel Storage folgender Güte bzw. Kapazität.

Nicht das mir die Grundlagen von iSCSI, FC, NFS oder auch FCoE nicht geläufig währen (allein mein VCI Job benötigt das Wissen), aber jeder hat so seine Schwerpunkte, und Storage gehört nicht zu meinen ;-( Trotzdem, oder gerade deswegen hat mich der Ansatz den Tintri mit ihrer VMstorage Appliance geht interessiert und bis jetzt auch fasziniert.

Tintri

Tintri.com

Tintri VMstorage – was ist anders und besser, was ist es nicht?

Ich möchte hier keine umfassende Ausführung über die Lösung geben, sondern einfach ein paar Dinge aufführen die mir aufgefallen sind und die ich persönlich erwähnenswert halte. Ich beschränke mich auch auf den Einsatz in vmware vSphere Umgebungen.

Weitere Infos findet man z.B. hier:

Was ist Tintri nicht?

Fangen wir mit dem „was ist Tintri nicht“ an. Tintri ist kein sogenanntes „unified Storage“, also ein Storage welches für jede Art von Anwendungsfall passt, sondern eine Lösung, die speziell auf die Bedürfnisse einer virtualisierten Umgebung eingeht. Dabei wird z.Z. vmware wohl am optimalsten bedient. Dieses scheint im Moment ein wenig Trend zu werden.

Was ist Tintri?

Tintri ist auf den ersten Blick eine einfach zu installierende Storage Appliance die NFS Storage für vmware vSphere bereitstellt.

Was ist „normal“?

Tintri besteht aus einer physikalischen Appliance mit 3U Bauhöhe (T540). Diese beinhaltet 8 SSDs und 6 HDD im RAID6. Alle wichtigen Baugruppen sind redundant bzw. Hot-Plug fähig.

T540_-_front_with_bezel_-_1k_width72ppi-300x86

Frontansicht

T540_rearRückansicht mit redundaten Netzteilen und Controllern

Soweit gibt es noch nichts „besonderes“ zu sehen, was andere nicht auch bieten würden. Interessant wird es wenn man sich die Software bzw. das Betriebssystem der Appliance ansieht.

Was ist nun das besondere daran?

vmware vSphere Integration

Bei der Installation bzw. Erstkonfiguration der T540 fällt auf, das die Appliance direkt an einen, oder mehrere vCenter Server gekoppelt wir! Dazu wird ein min. „read only“ Account benötigt.

Genau an dieser Stelle fangen meiner Meinung nach die Tintri Spezialitäten an. Andere Lösungen liefern Daten an einen vCenter Server (z.B. via VASA oder VAAI) und geben so vmware die Möglichkeit aktiv über Schnittstellen zu agieren bzw. dem Admin mehr Infos über das Storage.

Tintri unterstützt auch VAAI (vmware Array Integration) mit den Funktionen VAAI-NFS Primitives:

  • extended statistics feature
  • Reserve Space primitive
  • File Cloning primitives

(siehe dazu den Beitrag von Cormac Hogan)

geht aber weit darüber hinaus.

Die Spezialität von Tintri ist die, das Tintri vCenter Server Metriken aktiv abfragt und so einzelne VMs identifiziert und VM spezifisch agieren kann!!!

Dieses halte ich für einen sehr interessanten Ansatz. Das Storage System stellt sich auf den Hypervisor bzw. die Virtualisierungsplattform ein und analysiert das Verhalten der gespeicherten VMs, nicht nur an Hand von IOPS und Kapazitäten, sondern auch an Hand von Informationen die der Virtualisierer liefert.

Resulatat aus der aktiven Verbindung zum Virtuellen Management

Die Tintri Appliance kann sehr granular auf die Bedüfnisse und Anforderungen einer VM reagieren. Der Administrator erhält detaillierte Informationen über das Verhalten der Umgebung und zwar VM spezifisch.

virtual-disk-screenshot-large

Diese Idee finde ich sehr interessant und auf jeden Fall beachtenswert. Mal sehen wir sich diese Lösung im praktischen Betrieb bewährt. Wir warten z.Z. auf eine Appliance um diese in einer Demo Umgenbung zu impelementieren und zu teste, dabei aber auch Interessierten in Demos bereitzustellen.

Weitere Fratures:

  • Inline Deduplication
  • Datenkompression
  • Cloning von VMs via VAAI
  • spezielle Tintri Snapshots
  • uvm.

(Alle Grafiken, sofern nicht anders angegeben © by Tintri)