vSphere Content Libraries verstehen und einsetzen

Vor vSphere 6.0 dienten in der Regel Datastores als Speicherort. Verfügen Unternehmen über mehrere Standorte mit jeweils eigener Storage-Infrastruktur und verknüpften vCentern, dann garantiert ein Speicher-Backend allein aber noch keine konsistente Datenhaltung. Außerdem ist die mehrfache Speicherung an unter­schiedlichen Standorten nicht sonderlich effizient.

Konzept von Content Libraries

Bei Content Libraries spielen die drei Aspekte Sharing/Consistency, Storage Effciency und Secure Subscription eine wichtige Rolle.

Die Idee dabei: Physisch speichert jeder Standort die Vorlagen­elemente lokal in seinem Storage-Backend, sprich einem Datastore-Objekt. Logisch hingegen werden die Objekte an einem zentralen "Ort", dem Content-Library-Objekt abgelegt. Allerdings hat jeder Standort ein eigenes Content-Library-Objekt in seinem vCenter.

Der Clou dabei: Ein Benutzer legt ein Content Library-Objekt vom Typ local an und veröffentlicht dieses für den Internet-Zugriff via HTTPS (published).

Optional kann der Zugriff auf eine Content Library mit einem Passwort geschützt werden, womit auch der Sicherheits­aspekt der oben genannten drei Stufen erfüllt ist. Im nächsten Schritt muss man das logische Content Library Objekt an ein Speicher-Backend binden, hier in Form von Datastores.

Die Veröffentlichungs-URL sieht man, wenn man danach in die Summary-Ansicht des fertig erstellten neuen Content-Library-Objekts wechselt. Diese kann dann dem jeweils anderen Standort in irgendeiner Form übermittelt werden, etwa durch eine verschlüsselte E-Mail.

Die Gegenseite kann dann mit Hilfe der URL ebenfalls ein eigenes Content-Library-Objekt, allerdings von Typ abonniert (subscribed) anlegen, wobei der Inhalt dann über das Internet (ggf. auch automatisch) synchronisiert wird.

Die besondere Speicher­effizienz ergibt sich dadurch, dass ein Subscriber den synchro­nisierten Inhalt zwar in seiner Content Library sieht, dieser aber nicht notwendiger­weise sofort in seinem Speicher-Backend abgelegt wird. Voraussetzung dafür ist, dass er beim Abonnieren die Option zur Speicher-Effizienz Download Content => when needed wählt.

Die Zusammen­fassung vor dem Erstellen zeigt dann noch einmal die Subscription-URL mit dem darin enthaltenen JSON-File an.

Insgesamt gewährleistet das Publisher/Subscriber-Modell mit der eingebauten Synchronisation die Konsistenz der Inhalte, egal ob diese sofort oder nur bei Bedarf lokal heruntergeladen werden.

Verändert beispielweise eine Partei ein Objekt, dann tut sie das mittels Zugriff auf die Inhalte ihres eigenen logischen Content-Library-Objekts und nicht durch direktes Anfassen von Objekten im Datastore.

Die Gegenseite bekommt dann das geänderte Objekt (beispielsweise OVF) beim nächsten Zugriff auf sein Content-Library-Objekt bei aktivierter Funktion Download Content when needed automatisch. Wenn Inhalte dagegen bereits beim Erstellen der Content Library abgeglichen werden, erfolgt dies durch einen Klick auf den Synchronize-Befehl.

Nach dem Erstellen der Content-Library können berechtigte Nutzer jederzeit über die entsprechend angepassten Inventory-Kontextmenüs folgende Aktionen ausführen:

In jedem Fall muss bei diesen Aktionen die Ziel-Library ausgewählt werden. Aus dem Template in der Library kann dann jederzeit wieder eine VM entstehen.

Je nachdem, wie auf der Abonnenten­seite der Download der Inhalte konfiguriert ist (bei Bedarf oder sofort), steht das replizierte Objekt auf der Gegenseite entweder sofort oder nach Abschluss des Downloads zur Verfügung.

Übrigens werden hochgeladene vApps intern in OVFs konvertiert. Außerdem kann der Nutzer ISOs, VMDKs oder MF-Dateien hochladen. Nur für echte VM-Templates gilt, dass sich diese einzeln markieren und mit Pubish auf einer gewünschten Content Library veröffentlichen lassen.

Außerdem sind Content Libraries inzwischen auch für kleine Umgebungen nützlich. So lässt sich zum Beispiel eine ISO-Datei direkt aus der Content Library mounten. Dadurch kann man das Speichern von ISO-Images auf einem eigenen Datastore umgehen.