Netzwerk und Storage in VMware-Umgebungen absichern (3)

Lesezeit
4 Minuten
Bis jetzt gelesen

Netzwerk und Storage in VMware-Umgebungen absichern (3)

19.06.2023 - 07:20
Veröffentlicht in:

Eine virtuelle Maschine allein bietet kaum einen Mehrwert. Vielmehr fließen zwischen VMs und auch zur Außenwelt hin fleißig Daten. Hierfür ist eine passende wie sichere Netzwerkarchitektur notwendig. Wie diese und auch ein richtig administrierter Daten-Storage im Fall von ESXi aussieht, zeigt dieser Workshop. Im dritten und letzten Teil beschäftigen wir uns unter anderem mit dem Virtual Machine File System und den Besonderheiten der speicherrichtlinienbasierten Verwaltung.

Wenn ESX-Datastores zum Einsatz kommen, die Sie auf Block-Storage-Arrays via iSCSI oder FC ansteuern, wird das native VMFS-Format (vSphere Virtual Machine File System) verwendet. Es handelt sich dabei um ein spezielles Hochleistungs-Dateisystemformat, das für die Speicherung von VMs optimiert ist.

Virtual Machine File System
ESXi enthält auch VMFS, ein verteiltes Dateisystem und einen Volume-Manager, der virtuelle Volumes zusätzlich zu den LUNs erstellt und verwaltet, die dem ESXi-Host angezeigt werden. Diese virtuellen Volumes, normalerweise als virtuelle Datenträger bezeichnet, werden bestimmten virtuellen Maschinen zugewiesen. VMFS findet für SAN-basierten Blockspeicher und iSCSI Verwendung.

Eine VM hat dabei keinen Einblick in den World Wide Name (WWN), die physischen Fiber-Channel-HBAs, die Ziel-ID oder andere Informationen zu den LUNs, auf denen sich ihre virtuellen Festplatten befinden. Die VM ist so isoliert, dass Software, die in der virtuellen Maschine läuft, nicht erkennen kann, dass sie auf einem anderen Computer ausgeführt wird.

Betrachten wir das Beispiel von Windows in einer virtuellen VMware-Maschine. Die VM erkennt nur bestimmte virtuelle Festplatten: diejenigen, die vom ESXi-Administrator zum Zeitpunkt der Konfiguration der virtuellen Maschine ausgewählt wurden. Eine solche Operation ist effektiv eine LUN-Maskierung in der virtualisierten Umgebung. Es bietet die gleichen Sicherheitsvorteile wie die LUN-Maskierung in der physischen Welt, jedoch mit einem anderen Satz von Tools.

Software, die in der virtuellen Maschine läuft, einschließlich des Windows-Betriebssystems, erkennt nur die an die virtuelle Maschine angeschlossenen virtuellen Festplatten. Selbst wenn Windows versucht, einen SCSI-Befehl auszugeben, um andere Ziele zu ermitteln, verhindert ESXi, dass SCSI-Informationen erkannt werden, die für die isolierte und virtualisierte Ansicht der Speicherumgebung nicht nötig sind.

Zusätzliche Komplexität in der Speicherumgebung tritt auf, wenn ein Cluster von ESXi-Hosts auf gemeinsame Targets oder LUNs zugreift. VMFS stellt sicher, dass alle Hosts im Cluster zusammenarbeiten, um korrekte Berechtigungen und einen sicheren Zugriff auf die VMware-Volumes zu gewährleisten. File-Locks werden als Teil der Volume-Metadaten auf der Festplatte gespeichert, und alle ESXi-Hosts, die die Volumes verwenden, erkennen den File-Lock-Owner. Das Ownership an VMDK-Dateien und verschiedenen verteilten Dateisystemaktivitäten geschieht durch die Verwendung von Standard-SCSI-Reservierungsprimitiven exklusiv und granular.

Zugriff per Network File System
In ESXi integrierte NFS-Clients verwenden das Network File System (NFS) über TCP/IP, um auf ein NFS-Volume auf einem NAS-Server zuzugreifen. Der ESXi-Host kann das Volume mounten und es als NFS-Datenspeicher verwenden. Der Eigentümer von NFS-Verbindungen ist root. Die Lese-Schreib-Synchronisierungseinstellungen für "no_root_squash" sind aktiviert, damit root Dateien auf der NFS-Freigabe erstellen oder löschen kann.

Bei der NFS-Sperrung unter ESXi kommt das NLM-Protokoll nicht zum Einsatz. VMware hat vielmehr ein eigenes Protokoll eingerichtet. Die NFS-Sperren werden implementiert, indem Sie Sperrdateien auf dem NFS-Server erstellen. Um ESXi-Hosts darüber zu informieren, dass eine Sperre noch aktiv ist, sendet VMware nach dem Erstellen regelmäßig Aktualisierungen an die Sperrdatei. Dies generiert kleine 84-Byte-Write-Anforderungen an den NFS-Server.

Software-defined Storage
Zu der bei traditionellen Speichermodellen durchgeführten Abstrahierung von zugrundeliegenden Speicherkapazitäten von VMs abstrahiert Software-defined Storage (SDS) die Speicherfunktionen weiter. Das softwaredefinierte Speichermodell macht eine virtuelle Maschine zu einer Speicherbereitstellungseinheit und lässt sich über einen flexiblen, richtlinienbasierten Mechanismus verwalten. Das Modell umfasst die folgenden vSphere-Technologien:

  • VMware vSphere Virtual Volumes: Durch vVols wird bei der Speicherverwaltung nicht mehr der Speicherplatz innerhalb von Datenspeichern verwaltet, sondern es werden abstrakte, von Speicher-Arrays gehandhabte Speicherobjekte verwaltet. Mit vVols wird eine einzelne VM (nicht der Datenspeicher) ein Teil der Speicherverwaltung. Die Speicherhardware gewinnt somit die vollständige Kontrolle über den Inhalt der virtuellen Festplatten, das Layout und die Administration.
  • VMware vSAN: Bei vSAN handelt es sich um eine Software-Ebene, die im Rahmen des Hypervisors ausgeführt wird. vSAN fasst lokale oder direkt angeschlossene Storage-Devices eines ESXi-Hostclusters zusammen und erstellt einen einzelnen Speicherpool, der von allen Hosts im vSAN-Cluster verwendet wird. Der vSAN-Cluster und der ESXi-Cluster sind hierbei identisch.

Speicherrichtlinienbasierte Verwaltung
Das Storage Policy Based Management (SPBM) ist ein Framework und eine Abstraktionsebene, die als Unified Control Plane, als Steuerungskomponente für verschiedene Datendienste und Storage-Lösungen wie etwa vSAN und vVols angesprochen werden kann. SPBMs passen den Anwendungsbedarf der VM an die von den Storage-Entitäten bereitgestellten Funktionen an. So unterstützen externe Storage-Hersteller vVols für VMware und stellen ihre Storage-Fähigkeiten den VMs transparent als Managementobjekt zur Verfügung.

Dies vereinfacht die Handhabung zwischen Storage-Spezialisten und vSphere-Verantwortlichen erheblich, da die Fähigkeiten des Speichersystems transparent an die VM durchgereicht werden und sich dann direkt aus dem vCenter heraus für die VM verwenden lassen. SPBM bietet dabei die folgenden Mechanismen:

  • Anzeige von Storage-Fähigkeiten und Datendiensten, die Storage-Arrays und andere Entitäten wie etwa I/O-Filter bereitstellen.
  • Bidirektionale Kommunikation zwischen ESXi und vCenter Server auf der einen Seite und Speicher-Arrays und Entitäten auf der anderen Seite.
  • Bereitstellung von virtuellen Maschinen auf Basis von VM-Storage-Richtlinien.

Eine VM-Storage-Policy kann einen oder mehrere wiederverwendbare und austauschbare Bausteine enthalten. Diese werden als Storage-Policy-Komponenten bezeichnet. Jede beschreibt einen bestimmten Data-Dienst, der für die VM bereitstehen muss. Sie können die Policy-Komponenten im Voraus definieren und mehreren VM-Storage-Policies zuordnen. Allerdings lässt sich die vordefinierte Storage-Policy-Komponente einer virtuellen Maschine oder einer virtuellen Festplatte nicht direkt zuweisen. Stattdessen müssen Sie die Komponente der VM-Storage-Policy hinzufügen und dann die Policy der VM zuweisen.

Beim Provisionieren der VM oder beim Konfigurieren ihrer virtuellen Festplatten wenden Sie dann die Storage-Policy an. Je nach Typ und Konfiguration dient die Richtlinie unterschiedlichen Zwecken. Sie kann den am besten geeigneten Datastore für die VM auswählen und den erforderlichen Service-Level erzwingen. Oder sie kann bestimmte Datendienste für die VM und ihre Festplatten aktivieren. Die Dienste können je nach genutzten Anbietern unterschiedlich sein, gehören jedoch generell zu einer der folgenden Kategorien:

  • Komprimierung
  • Caching
  • Verschlüsselung
  • Replizierung

Die generische Standard-Storage-Policy, die ESXi anbietet, gilt für alle Datastores und enthält keine spezifischen Regeln für einen Storage-Typ. Darüber hinaus bietet ESXi die Default-Storage-Policies für objektbasierte Datastores, vSAN oder Virtual Volumes. Diese Policies garantieren die optimale Platzierung der VM-Objekte innerhalb des objektbasierten Storage. VMFS- und NFS-Datastores haben keine spezifischen Standard-Policy und können die generische Standardrichtlinie oder eine von Ihnen definierte benutzerdefinierte Richtlinie verwenden.

Der vSphere-Storage-Stack ist dabei durchaus hochentwickelt, was die Performance und Sicherheit angeht und unterliegt ständiger Verbesserung. vSphere-Storage-Typen sollen auch zukünftig allen Anwendungen und der Lokation der Daten gerecht werden, wie die Storage-Vision von VMware zeigt. So soll der Speicher im HCI-Stack von vCloud Foundation (VCF) besser skalieren und sich gleichzeitig einheitlich zwischen on-premises und der VMware-Cloud verwalten lassen. Zudem soll sich damit Data-Protection-as-a-Service realisieren lassen. Kubernetes wird mit Storage-Control-Plane-Funktionen privilegiert behandelt und vollkommen transparent integriert. Machine Learning soll für ständige wie automatische Storage-Optimierungen für die VMs und Container sorgen.

Fazit
Das Netzwerk und der Storage spielen bei virtuellen Umgebungen eine enorm wichtige Rolle. Einerseits müssen VMs mit ihrer Umwelt kommunizieren können, doch sollte der Traffic abgesichert und gesteuert sein. Andererseits bedürfen VMs eines ausreichenden, verfügbaren und sicheren Speichers für ihre Daten. Für beide Fälle bietet VMware die passenden Technologien, die wir Ihnen in diesem Beitrag vorgestellt haben.

ln/dr/Stephan Bohnengel und Christoph Buschbeck

Im ersten Teil der Workshop-Serie haben wir uns mit der Konfiguration von Portgruppen beschäftigt und den Unterschied zwischen einem vSphere-Standard-Switch und einem vSphere-Distributed-Switch erklärt. Im zweiten Teil haben wir den richtigen Umgang mit physischen Netzwerkkarten erläutert und gezeigt, wie die Architektur des Storage in VMware-Umgebungen aussieht.

Ähnliche Beiträge

VMware Aria Automation Orchestrator im Praxiseinsatz (3)

In Sachen Automatisierung ist Wiederverwendbarkeit das Ziel – etwa Skripte an verschiedenen Stellen erneut einzusetzen. Zu diesem Zweck stellt VMware Aria Automation Orchestrator (vormals vRealize Orchestrator) sogenannte Actions bereit. Dies umfasst etwa das Ausführen von Skripten in virtuellen Maschinen, das Registrieren einer VM im DNS oder die Integration ins Active Directory. Im dritten Teil der Workshopserie schildern wir Ausführen von Workflows mittels REST-API und widmen uns dem Verwalten von DNS-Einträgen.

VMware Aria Automation Orchestrator im Praxiseinsatz (2)

In Sachen Automatisierung ist Wiederverwendbarkeit das Ziel – etwa Skripte an verschiedenen Stellen erneut einzusetzen. Zu diesem Zweck stellt VMware Aria Automation Orchestrator (vormals vRealize Orchestrator) sogenannte Actions bereit. Dies umfasst etwa das Ausführen von Skripten in virtuellen Maschinen, das Registrieren einer VM im DNS oder die Integration ins Active Directory. Im zweiten Teil zeigen wir, wie Sie mithilfe des Guest Script Manager Skripte in einer VM ausführen.

VMware Aria Automation Orchestrator im Praxiseinsatz (1)

In Sachen Automatisierung ist Wiederverwendbarkeit das Ziel – etwa Skripte an verschiedenen Stellen erneut einzusetzen. Zu diesem Zweck stellt VMware Aria Automation Orchestrator (vormals vRealize Orchestrator) sogenannte Actions bereit. Dies umfasst etwa das Ausführen von Skripten in virtuellen Maschinen, das Registrieren einer VM im DNS oder die Integration ins Active Directory. Im ersten Teil schauen wir uns an, wie Sie Logging und Fehlerbehandlung betreiben.