IBM Cloud Docs
Design der virtuellen Infrastruktur

Design der virtuellen Infrastruktur

Die virtuelle Infrastrukturschicht umfasst die VMware ® -Softwarekomponenten, die die in der physischen Infrastrukturschicht bereitgestellten Compute-, Speicher-und Netzressourcen virtualisieren: VMware vSphere ESXi ®, VMware NSX-T™, und optional VMware vSAN™.

caption-side=bottom"
Virtuelle

VMware vSphere-Design

Die vSphere ESXi-Konfiguration umfasst die folgenden Aspekte:

  • Bootkonfiguration
  • Zeitsynchronisation
  • Hostzugriff
  • Benutzerzugriff
  • DNS-Konfiguration

In der folgenden Tabelle sind die Spezifikationen für die einzelnen Aspekte aufgeführt. Nach der Konfiguration und Installation von ESXi wird der Host zu einem VMware vCenter Server ® hinzugefügt und von dort aus verwaltet.

Mit diesem Design können Sie über Direct Console User Interface (DCUI) und vSphere Web Client auf die virtuellen Hosts zugreifen. Als bewährtes Verfahren werden Secure Shell (SSH) und ESXi Shell nach der Bereitstellung inaktiviert.

Standardmäßig sind die Benutzer Root und ibmvmadmin für die physische Maschine des Hosts die einzigen Benutzer, die sich direkt anmelden können. Der Administrator kann Benutzer aus der Microsoft ® Active Directory™ (MSAD) -Domäne hinzufügen, um den Benutzerzugriff auf den Host zu ermöglichen. Alle Hosts im VMware Cloud Foundation for Classic – Automated sind so konfiguriert, dass sie mit einem zentralen NTP-Server synchronisiert werden.

vSphere ESXi-Konfiguration
Attribut Konfigurationsparameter
ESXi-Bootposition

Verschiedene Host-Konfigurationen können eingesetzt werden:

  • Lokale Festplatten, konfiguriert mit RAID-1
  • Ein Paar M.2-Boot-Laufwerke in einer gespiegelten Konfiguration
  • Ein einzelnes M.2-Boot-Laufwerk
Zeitsynchronisation Verwendet IBM Cloud®-NTP-Server.
Hostzugriff Unterstützt DCUI. SSH und ESXi Shell werden unterstützt, aber nicht standardmäßig aktiviert.
Benutzerzugriff Lokale Authentifizierung und MSAD.
Auflösung von Domänennamen Verwendet DNS wie in Design der allgemeinen Services beschrieben.
EVC-Modus Höchste verfügbare Ebene, die von der vSphere-Version unterstützt wird. Für einen Management-Cluster mit Intel® Cascade Lake-Prozessoren wird jedoch kein EVC festgelegt, wenn Cascade Lake EVC von vSphere nicht unterstützt wird.

vSphere beherbergt die virtuellen Maschinen (VMs), die VMware Cloud Foundation for Classic – Automated verwalten, sowie die Rechenressourcen für die Arbeitslasten der Benutzer.

  • Wenn VMware Cloud Foundation for Classic – Automated vSAN, verwendet, beträgt die Mindestanzahl an ESXi-Hosts bei der Erstbereitstellung vier.
  • Wenn VMware Cloud Foundation for Classic – Automated gemeinsam genutzten Speicher auf Datei- oder Blockebene verwendet, beträgt die Mindestanzahl von ESXi-Hosts bei der Erstbereitstellung drei.

Sie können bis zu 20 ESXi-Hosts in diesem Cluster während der ursprünglichen Implementierung implementieren. Nach der ersten Implementierung können Sie den Cluster bis zu maximal 50 Hosts in Inkrementen von bis zu 20 Hosts gleichzeitig skalieren.

Um mehr Benutzerworkloads zu unterstützen, können Sie die Umgebung skalieren, indem Sie die folgenden Aktionen ausführen:

  • Mehr Rechenhosts in vorhandenen Clustern implementieren
  • Es werden mehr Cluster implementiert, die von derselben vCenter Server-Appliance verwaltet werden.
  • Bereitstellung neuer VMware Cloud Foundation for Classic – Automated Instanzen mit eigener vCenter Server-Appliance.

VMware vSAN Design

In diesem Entwurf wird VMware vSAN in VMware Cloud Foundation for Classic – Automated eingesetzt, um gemeinsam genutzten Speicher für vSphere bereitzustellen.

Wie in der folgenden Abbildung zu sehen ist, fasst vSAN den lokalen Speicher über mehrere ESXi-Hosts in einem vSphere-Cluster hinweg zusammen und verwaltet den zusammengefassten Speicher wie einen einzelnen VM-Datenspeicher. In diesem Design enthalten die Rechenknoten lokale Plattenlaufwerke für das ESXi-Betriebssystem und den vSAN-Datenspeicher.

Es können verschiedene Host-Konfigurationen eingesetzt werden:

  • Lokale Festplatten konfiguriert mit RAID-1
  • Ein Paar M.2 Boot-Laufwerke in einer gespiegelten Konfiguration
  • Ein einzelnes M.2-Boot-Laufwerk

vSAN konzept
vSAN-Konzept

vSAN arbeitet mit den folgenden Komponenten:

  • vSAN-Design mit zwei Plattengruppen; jede Plattengruppe besteht aus zwei oder mehr Platten. Eine SSD (Solid State Disk) oder ein NVMe Laufwerk der kleinsten Größe in der Gruppe dient als Cacheschicht, während die übrigen SSDs als Kapazitätsschicht verwendet werden.
  • Der Onboard-RAID-Controller ist in einem RAID-0-Array für jedes einzelne Laufwerk konfiguriert, das für den vSAN-Cache oder die vSAN-Kapazität verwendet wird.
  • Aus allen Speicherressourcen wird ein einzelner vSAN Datenspeicher erstellt.

Einrichtung des virtuellen Netzes für vSAN

Bei diesem Design fließt der vSAN Datenverkehr zwischen ESXi Hosts über ein dediziertes privates VLAN. Die beiden Netzadapter, die mit dem Switch des privaten Netzes verbunden sind, werden in vSphere als vSphere Distributed Switch (vDS) mit beiden Netzadaptern als Uplinks konfiguriert. Eine dedizierte vSAN-Kernelportgruppe, die für das vSAN-VLAN konfiguriert ist, befindet sich in dem vDS. Jumbo Frames (MTU 9000) werden für den privaten vDS aktiviert.

vSAN führt keinen Lastausgleich für den Datenverkehr zwischen Uplinks aus. Daher ist ein Adapter aktiv, während sich der andere im Standby-Modus befindet, um eine hohe Verfügbarkeit zu gewährleisten. Die Netzrichtlinie für die Funktionsübernahme (Failover) für vSAN ist als explizites Failover (Explicit Failover) zwischen physischen Netzports konfiguriert.

Weitere Informationen zu physischen NIC-Verbindungen finden Sie im Abschnitt Physische NIC-Hostverbindungen.

Design der vSAN-Richtlinie

Wenn vSAN aktiviert und konfiguriert ist, werden Speicherrichtlinien konfiguriert, um die VM Speichermerkmale zu definieren. Speichermerkmale geben die verschiedenen Service-Level für verschiedene VMs an.

Die Standardspeicherrichtlinie in diesem Design toleriert ein einzelnes Feature. Die Standardrichtlinie wird mit Löschcodierung konfiguriert, wobei Fehlertoleranzmethode auf RAID-5/6 (Erasure Coding) - Kapazität und Primäre Fehlerebene auf 1 gesetzt ist. Die RAID 5 Konfiguration erfordert mindestens vier Hosts.

Alternativ können Sie die RAID 6 Konfiguration mit dem Wert RAID-5/6 (Erasure Coding) - Capacity für die Option Failure tolerance method (Fehlertoleranzmethode) und dem Wert 2 für die Option Primary level of failures (Primäre Fehlerebene) auswählen. Die RAID 6 Konfiguration erfordert mindestens sechs Hosts. Deduplizierung und Komprimierung sind normalerweise in der Standardspeicherrichtlinie aktiviert, können aber bei Bedarf inaktiviert werden.

Eine Instanz verwendet die Standardrichtlinie, sofern nichts anderes über die vSphere Konsole angegeben wird. Wenn eine angepasste Richtlinie konfiguriert ist, garantiert vSAN sie nach Möglichkeit. Wenn die Richtlinie jedoch nicht garantiert werden kann, ist es nicht möglich, eine VM bereitzustellen, die die Richtlinie verwendet, sofern sie nicht zur erzwungenen Bereitstellung eingerichtet ist.

Speicherrichtlinien müssen nach dem Hinzufügen neuer ESXi-Hosts oder nach der Aktualisierung der ESXi-Hosts erneut angewendet werden.

vSAN-Einstellungen

vSAN Einstellungen werden nach bewährten Verfahren für die Bereitstellung von VMware Lösungen in IBM Cloud konfiguriert. Zu den VSAN-Einstellungen gehören SIOC-Einstellungen, Einstellungen für die Portgruppe für explizites Failover und Plattencacheeinstellungen.

  • Einstellungen für den SSD-Cache-Einstellungen-Nein Lesen Sie vorwärts, Schreiben durch, Direct (NRWTD)
  • Einstellungen der E/A-Netzsteuerung
    • Management - 20 gemeinsam genutzte Ressourcen
    • Virtuelle Maschine - 30 gemeinsam genutzte Ressourcen
    • vMotion - 50 gemeinsam genutzte Ressourcen
    • vSAN - 100 gemeinsam genutzte Ressourcen
  • vSAN-Kernel-Ports- Expliczites Failover

Über NFS zugeordnete Speichereinheit

NFS-Server-LIF-Migrationen können zu einer übermäßigen Latenzzeit führen, wenn sie NFS v4.1 verwenden. Wenn Sie NFS-NAS verwenden, schreibt diese Architektur die Verwendung von NFS v3 anstelle von NFS v4.1 vor. Jeder vSphere-Host wird unter Verwendung seines Hostnamens mit dem NFS-Speicher verbunden.

Ein 2-TB-NFS-Datenspeicher wird einem Cluster zugeordnet, der von Verwaltungskomponenten mit einem Leistungstier von 4 IOPS/GB verwendet werden kann. Weitere Datenspeicher können einem Cluster für den Verarbeitungsprozess zugeordnet werden; dabei können verschiedene Größen und Leistungstiers verwendet werden.

Darüber hinaus ist für diese Architektur erforderlich, dass alle Hosts über eine Teilnetzroute verfügen, die für das Teilnetz erstellt wird, in dem sich der NFS-Speicher befindet. Der Zweck dieser Teilnetzroute besteht darin, den gesamten NFS-Datenverkehr so weiterzuleiten, dass die Portgruppe, das Teilnetz und das VLAN verwendet werden, die durch dieses Design für den NFS-Datenverkehr bestimmt sind. Sind mehrere NFS-Datenspeicher angehängt, müssen möglicherweise mehrere Routen konfiguriert werden, da sich diese Datenspeicher in unterschiedlichen fernen Teilnetzen befinden können.

Die Management-VMs können sich auf einem NFS-Datenspeicher befinden. Dieser Ansatz führt zu einem Bootstrapping-Problem, da einige der Management-Maschinen für DNS-Services verantwortlich sein könnten, die zur Auflösung des NFS-Hostnamens verwendet werden. Daher gibt diese Architektur an, dass mindestens eine der IP-Adressen für den Managementdatenspeicher auf jedem der Hosts fest in /etc/hosts codiert ist.