FlexPod-Definition
Lösungsvalidierung – Virtualisierung
Änderungen vorschlagen
PDFs
In der FlexPod SM-BC Lösung an mehreren Standorten managt ein einzelnes VMware vCenter die Ressourcen der virtuellen Infrastruktur für die gesamte Lösung. Die Hosts in beiden Datacentern Teil des einzelnen VMware HA Clusters, der beide Datacenter umfasst. Die Hosts haben Zugriff auf die NetApp SM-BC Lösung, bei der auf Storage mit definierten SM-BC-Beziehungen von beiden Standorten aus zugegriffen werden kann.
Der Storage für SM-BC Lösung entspricht dem einheitlichen Zugriffsmodell in der VMware vSphere Metro Storage Cluster (vMSC) Funktion zur Vermeidung von Ausfällen und Ausfallzeiten. Für eine optimale Performance der Virtual Machines sollten die Virtual-Machine-Festplatten auf den lokalen NetApp AFF A250 Systemen gehostet werden, um die Latenz und den Datenverkehr über WAN-Links im normalen Betrieb zu minimieren.
Im Rahmen der Design-Implementierung muss die Verteilung der Virtual Machines auf die beiden Standorte ermittelt werden. Sie können die Standortaffinität dieser Virtual Machine und die Applikationsverteilung über die beiden Standorte entsprechend den Vorlieben Ihres Standorts und den Applikationsanforderungen festlegen. Die VMware Cluster VM/Host Groups und VM/Host Rules werden verwendet, um die VM/Host-Affinität zu konfigurieren, um sicherzustellen, dass die VMs auf den Hosts am gewünschten Standort ausgeführt werden.
Konfigurationen, mit denen die VMs an beiden Standorten ausgeführt werden können, stellen jedoch sicher, dass VMs durch VMware HA an den Remote-Hosts neu gestartet werden können, um die Stabilität der Lösung zu gewährleisten. Damit die Virtual Machines auf beiden Seiten ausgeführt werden können, müssen alle gemeinsam genutzten iSCSI-Datenspeicher auf allen ESXi Hosts eingebunden werden, um einen reibungslosen vMotion Betrieb der Virtual Machines zwischen den Standorten sicherzustellen.
Die folgende Abbildung zeigt eine allgemeine Virtualisierungsansicht einer FlexPod SM-BC Lösung mit VMware HA- und vMSC-Funktionen für eine hohe Verfügbarkeit von Computing- und Storage-Services. Die aktiv/aktiv-Architektur für Datacenter-Lösungen ermöglicht Workload-Mobilität zwischen Standorten und bietet DR/BC-Schutz.
Umfassende Netzwerkkonnektivität
Die FlexPod SM-BC Lösung umfasst FlexPod-Infrastrukturen an jedem Standort, Netzwerkkonnektivität zwischen Standorten und den ONTAP Mediator, der an einem dritten Standort implementiert wird, um die erforderlichen RPO- und RTO-Vorgaben zu erfüllen. Die folgende Abbildung zeigt die End-to-End-Netzwerkkonnektivität zwischen den Cisco UCS B200M5 Servern an jedem Standort und dem NetApp Storage mit SM-BC Funktionen innerhalb eines Standorts und über mehrere Standorte hinweg.
Die FlexPod Implementierungsarchitektur ist bei dieser Lösungsvalidierung an jedem Standort identisch. Die Lösung unterstützt jedoch asymmetrische Implementierungen und kann, wenn sie die Anforderungen erfüllen, auch zu vorhandenen FlexPod Lösungen hinzugefügt werden.
Die erweiterte Layer-2-Architektur dient einer nahtlosen Multi-Site-Data-Fabric-Architektur, die eine Konnektivität zwischen dem Port-gechannelten Cisco UCS-Computing und NetApp Storage in jedem Datacenter sowie Konnektivität zwischen Datacentern bietet. Die Port-Channel-Konfiguration und gegebenenfalls die Konfiguration des virtuellen Port-Kanals werden für die Bandbreitenaggregation und Fehlertoleranz zwischen den Computing-, Netzwerk- und Storage-Ebenen sowie für die standortübergreifenden Links verwendet. Das Ergebnis: Konnektivität und Multipath-Zugriff auf lokalen und Remote NetApp Storage sind die UCS Blade Server.
Virtuelle Netzwerke
Jeder Host im Cluster wird unabhängig vom Speicherort für identische virtuelle Netzwerke bereitgestellt. Das Design trennt die verschiedenen Traffic-Typen mit VMware Virtual Switches (vSwitch) und VMware Virtual Distributed Switches (VdS). Der VMware vSwitch wird hauptsächlich für die FlexPod-Infrastrukturnetzwerke und VdS für Applikationsnetzwerke verwendet, ist aber nicht erforderlich.
Die virtuellen Switches (vSwitch, VdS) werden mit zwei Uplinks pro virtuellen Switch bereitgestellt; die Uplinks auf der ESXi Hypervisor-Ebene werden als VMkernel und virtuelle NICs (vNICs) auf der Cisco UCS Software bezeichnet. Die vNICs werden auf dem Cisco UCS VIC Adapter in jedem Server mit Cisco UCS Service-Profilen erstellt. Sechs vNICs sind definiert, zwei für vSwitch0, zwei für vDS0, zwei für vSwitch1 und zwei für die iSCSI-Uplinks wie in der folgenden Abbildung dargestellt.
VSwitch0 wird während der VMware ESXi Host-Konfiguration definiert. Es enthält das FlexPod Infrastruktur-Management-VLAN und die ESXi Host VMkernel (VMK)-Ports für das Management. Für alle erforderlichen kritischen Virtual Machines für das Infrastrukturmanagement wird zudem eine VM-Portgruppe für vSwitch0 hinzugefügt.
Es ist wichtig, solche Management-Infrastruktur-Virtual Machines auf vSwitch0 statt auf den VdS zu platzieren, da wenn die FlexPod-Infrastruktur heruntergefahren oder aus- und wieder eingeschaltet wird und Sie versuchen, diese Management-Virtual Machine auf einem anderen Host als dem Host zu aktivieren, auf dem sie ursprünglich ausgeführt wurde, Es startet gut im Netzwerk auf vSwitch0. Dieser Prozess ist besonders wichtig, wenn VMware vCenter die Management-Virtual Machine ist. Wenn vCenter auf dem VdS wäre und zu einem anderen Host verschoben und dann gestartet wurde, wäre es nicht mit dem Netzwerk nach dem Booten verbunden.
In diesem Design werden zwei iSCSI Boot vSwitches verwendet. Beim Booten von Cisco UCS iSCSI sind separate vNICs für iSCSI erforderlich. Diese vNICs verwenden das iSCSI-VLAN des entsprechenden Fabric als natives VLAN und sind an den entsprechenden iSCSI-Boot-vSwitch angeschlossen. Optional können Sie auch iSCSI-Netzwerke auf VdS bereitstellen, indem Sie einen neuen VdS oder eine vorhandene einsetzen.
VM-Host-Gruppen und Regeln
Damit Virtual Machines auf jedem ESXi Host an beiden SM-BC-Sites ausgeführt werden können, müssen alle ESXi Hosts die iSCSI-Datenspeicher von beiden Standorten aus mounten. Wenn die Datastores von beiden Standorten ordnungsgemäß von allen ESXi Hosts eingebunden werden, können Sie eine Virtual Machine zwischen beliebigen Hosts mit vMotion migrieren, und die VM bleibt weiterhin Zugriff auf alle ihre virtuellen Festplatten, die aus diesen Datastores erstellt wurden.
Bei einer virtuellen Maschine, die lokale Datenspeicher verwendet, wird der Zugriff auf virtuelle Festplatten Remote, wenn sie zu einem Host am Remote-Standort migriert wird und somit die Verzögerung beim Lesevorgang aufgrund der physischen Entfernung zwischen den Standorten erhöht. Daher empfiehlt es sich, die Virtual Machines auf lokalen Hosts aufzubewahren und den lokalen Storage am Standort zu nutzen.
Mithilfe eines Mechanismus zur VM-/Hostorientierung können Sie VM-/Host-Gruppen verwenden, um eine VM-Gruppe und eine Host-Gruppe für Virtual Machines und Hosts zu erstellen, die sich an einem bestimmten Standort befinden. Mithilfe von VM-/Host-Regeln können Sie die Richtlinie für die folgenden VMs und Hosts festlegen. Um eine standortübergreifende Migration virtueller Maschinen während einer Standortwartung oder eines Notfallszenarios zu ermöglichen, verwenden Sie die Richtlinienspezifikation „sollte auf Hosts in der Gruppe ausgeführt werden“, um diese Flexibilität zu gewährleisten.
Der folgende Screenshot zeigt, dass zwei Host-Gruppen und zwei VM-Gruppen für Hosts und VMs an Standort A und Standort B erstellt werden
Zusätzlich zeigen die folgenden beiden Abbildungen die VM/Host Regeln, die für Standort A und Standort B VMs erstellt werden, um auf den Hosts auf ihren jeweiligen Seiten mit der "sollte auf Hosts in der Gruppe laufen"-Politik zu laufen.
Ha-Herzschlag von vSphere
VMware vSphere HA verfügt über einen Heartbeat-Mechanismus zur Validierung des Hoststatus. Der primäre Heartbeat-Mechanismus wird über das Netzwerk durchgeführt. Der sekundäre Heartbeat-Mechanismus erfolgt über den Datenspeicher. Wenn keine Herzschläge empfangen werden, entscheidet sie dann, ob sie vom Netzwerk isoliert wird, indem sie das Standard-Gateway oder die manuell konfigurierten Isolationsadressen pingen. Beim Herzschlag des Datenspeichers empfiehlt VMware, die Heartbeat-Datenspeicher für ein dehnbares Cluster von mindestens zwei auf vier zu erhöhen.
Für die Lösungsvalidierung werden die beiden ONTAP-Cluster-Management-IP-Adressen als Isolationsadresse verwendet. Darüber hinaus die empfohlene vSphere HA Advanced Option ds.heartbeatDsPerHost Mit einem Wert von 4 wurde hinzugefügt, wie in der folgenden Abbildung dargestellt.
Geben Sie für den Heartbeat-Datenspeicher die vier gemeinsam genutzten Datenspeicher aus dem Cluster an und ergänzen Sie sie automatisch, wie in der folgenden Abbildung dargestellt.
Weitere Best Practices und Konfigurationen für VMware HA Cluster und VMware vSphere Metro Storage Cluster finden Sie unter "Erstellen und Verwenden von vSphere HA-Clustern", "VMware vSphere Metro Storage-Cluster (vMSC)" Und der VMware KB für "NetApp ONTAP mit NetApp SnapMirror Business Continuity (SM-BC) und VMware vSphere Metro Storage Cluster (vMSC)".