Hilfreiche allgemeine Kenntnisse zu HyperFlex
Inhalt
Einführung
In diesem Dokument werden allgemeine Informationen zu Cisco HyperFlex (HX) beschrieben, die Administratoren zur Hand haben sollten.
Häufig verwendete Abkürzungen
SCVM = Storage Controller Virtual Machine
VMNIC = Virtual Machine Network Interface Card
VNIC = Virtual Network Interface Card
SED = Self Encrypting Drive
VM = virtuelles System
HX = HyperFlex
HyperFlex VMware VMNIC-Bestellung
VMNIC-Platzierung wurde in HX Version 3.5 und höher überarbeitet.
Bestellung vor 3.5
Vor Version 3.5 wurden die VNICs basierend auf den VNIC-Nummern zugewiesen.
| VNIC | Virtueller Switch (vSwitch) |
| VNIC 0 und VNIC 1 | vSwitch-hx-inband-mgmt |
| VNIC 2 und VNIC 3 | vSwitch-hx-storage-data |
| VNIC 4 und VNIC 5 | vSwitch-hx-vm-netzwerk |
| VNIC 6 und VNIC 7 | vMotion |
Bestellung nach 3.5
In Version 3.5 und höher werden die VNICs basierend auf der MAC-Adresse (Media Access Control) zugewiesen. Daher gibt es keine bestimmte Abtretungsreihenfolge.
Wenn ein Upgrade von einer Version älter als 3.5 auf 3.5 oder höher durchgeführt wird, wird die VMNIC-Bestellung beibehalten.
SCVM auf konvergentem Knoten versus Computing-Knoten
SCVMs befinden sich sowohl auf konvergenten als auch auf Computing-Knoten, und es bestehen Unterschiede zwischen diesen Knoten.
Konvergenter Knoten
Reservierungen für CPU-Ressourcen
Da die SCVMs wichtige Funktionen der Cisco HX Distributed Data Platform bereitstellen, konfiguriert das HyperFlex-Installationsprogramm die CPU-Ressourcenreservierungen für die Controller-VMs. Diese Reservierung garantiert, dass die Controller-VMs über CPU-Ressourcen (Central Processing Unit) auf einer Mindestebene verfügen, in Situationen, in denen die physischen CPU-Ressourcen des ESXi-Hypervisor-Hosts in hohem Maße von den GastVMs genutzt werden. Dies ist eine unverbindliche Garantie, da in den meisten Fällen die SCVMs nicht alle CPU-Ressourcen verwenden, die reserviert sind, sodass die Gast-VMs diese Ressourcen verwenden können. In der folgenden Tabelle wird die CPU-Ressourcenreservierung der Speicher-Controller-VMs aufgeführt:
| Anzahl der vCPUs | Freigaben | Reservierung | Begrenzung |
| 8 | Niedrig | 10800 MHZ | Unbegrenzt |
Reservierungen für Speicherressourcen
Da die SCVMs wichtige Funktionen der Cisco HX Distributed Data Platform bereitstellen, konfiguriert das HyperFlex-Installationsprogramm die Reservierungen von Speicherressourcen für die Controller-VMs. Diese Reservierung garantiert, dass die virtuellen Controller-Systeme über mindestens Speicherressourcen verfügen, wenn die physischen Speicherressourcen des ESXi-Hypervisor-Hosts in hohem Maße von den virtuellen Gastsystemen genutzt werden. In der folgenden Tabelle wird die Speicherressourcenreservierung der Speicher-Controller-VMs aufgeführt:
| Servermodelle | Gastspeicher | Reservieren des Gastspeichers |
| HX 220c-M5SX HXAF 220c-M5SX HX 220c-M4S HXAF220c-M4S |
48 GB | Ja |
| HX 240c-M5SX HXAF 240c-M5SX HX240c-M4SX HXAF240c-M4SX |
72 GB | Ja |
| HX240c-M5L | 78 GB | Ja |
Computing-Knoten
Die reinen Knoten verfügen über ein einfaches SCVM. Es wird mit nur 1 vCPU mit 1024 MHz und 512 MB Speicherreservierung konfiguriert.
Der Zweck des Computing-Knotens besteht hauptsächlich darin, die vCluster Distributed Resource Scheduler™ (DRS)-Einstellungen beizubehalten, um sicherzustellen, dass die Benutzer-VMs nicht in konvergente Knoten zurückverschoben werden.
Ungesunde Cluster-Szenarien
Ein HX-Cluster kann in den folgenden Szenarien ungesund wiedergegeben werden.
Szenario 1: Knoten-Down
Ein Cluster wechselt in einen ungesunden Zustand, wenn ein Knoten ausfällt. Es wird erwartet, dass ein Knoten während eines Cluster-Upgrades oder wenn ein Server in den Wartungsmodus versetzt wird, nicht verfügbar ist.
root@SpringpathController:~# stcli cluster storage-summary --detail
<snip>
current ensemble size:3
# of caching failures before cluster shuts down:2
minimum cache copies remaining:2
minimum data copies available for some user data:2
current healing status:rebuilding/healing is needed, but not in progress yet. warning: insufficient node or space resources may prevent healing. storage node 10.197.252.99is either down or initializing disks.
minimum metadata copies available for cluster metadata:2
# of unavailable nodes:1
# of nodes failure tolerable for cluster to be available:0
health state reason:storage cluster is unhealthy. storage node 10.197.252.99 is unavailable.
# of node failures before cluster shuts down:2
# of node failures before cluster goes into readonly:2
# of persistent devices failures tolerable for cluster to be available:1
# of node failures before cluster goes to enospace warn trying to move the existing data:na
# of persistent devices failures before cluster shuts down:2
# of persistent devices failures before cluster goes into readonly:2
# of caching failures before cluster goes into readonly:na
# of caching devices failures tolerable for cluster to be available:1
resiliencyInfo:
messages:
----------------------------------------
Storage cluster is unhealthy.
----------------------------------------
Storage node 10.197.252.99 is unavailable.
----------------------------------------
state: 2
nodeFailuresTolerable: 0
cachingDeviceFailuresTolerable: 1
persistentDeviceFailuresTolerable: 1
zoneResInfoList: None
spaceStatus: normal
totalCapacity: 3.0T
totalSavings: 5.17%
usedCapacity: 45.9G
zkHealth: online
clusterAccessPolicy: lenient
dataReplicationCompliance: non_compliant
dataReplicationFactor: 3
Szenario 2: Disk Down
Ein Cluster wechselt in einen ungesunden Zustand, wenn ein Datenträger nicht verfügbar ist. Die Bedingung sollte gelöscht werden, wenn die Daten auf andere Datenträger verteilt werden.
root@SpringpathController:~# stcli cluster storage-summary --detail
<snip>
current ensemble size:3
# of caching failures before cluster shuts down:2
minimum cache copies remaining:2
minimum data copies available for some user data:2
current healing status:rebuilding/healing is needed, but not in progress yet. warning: insufficient node or space resources may prevent healing. storage node is either down or initializing disks.
minimum metadata copies available for cluster metadata:2
# of unavailable nodes:1
# of nodes failure tolerable for cluster to be available:0
health state reason:storage cluster is unhealthy. persistent device disk [5000c5007e113d8b:0000000000000000] on node 10.197.252.99 is unavailable.
# of node failures before cluster shuts down:2
# of node failures before cluster goes into readonly:2
# of persistent devices failures tolerable for cluster to be available:1
# of node failures before cluster goes to enospace warn trying to move the existing data:na
# of persistent devices failures before cluster shuts down:2
# of persistent devices failures before cluster goes into readonly:2
# of caching failures before cluster goes into readonly:na
# of caching devices failures tolerable for cluster to be available:1
resiliencyInfo:
messages:
----------------------------------------
Storage cluster is unhealthy.
----------------------------------------
Persistent Device Disk [5000c5007e113d8b:0000000000000000] on node 10.197.252.99 is unavailable.
----------------------------------------
state: 2
nodeFailuresTolerable: 0
cachingDeviceFailuresTolerable: 1
persistentDeviceFailuresTolerable: 1
zoneResInfoList: None
spaceStatus: normal
totalCapacity: 3.0T
totalSavings: 8.82%
usedCapacity: 45.9G
zkHealth: online
clusterAccessPolicy: lenient
dataReplicationCompliance: non_compliant
dataReplicationFactor: 3
Szenario 3: Keiner der Knoten oder kein Festplatten-Down
Ein Cluster kann in einen ungesunden Zustand wechseln, wenn weder ein Knoten noch ein Datenträger ausgefallen sind. Diese Bedingung tritt ein, wenn eine Wiederherstellung ausgeführt wird.
root@SpringpathController:~# stcli cluster storage-summary --detail
<snip>
resiliencyDetails:
current ensemble size:5
# of caching failures before cluster shuts down:3
minimum cache copies remaining:3
minimum data copies available for some user data:2
current healing status:rebuilding is in progress, 98% completed. minimum metadata copies available for cluster metadata:2
time remaining before current healing operation finishes:7 hr(s), 15 min(s), and 34 sec(s)
# of unavailable nodes:0
# of nodes failure tolerable for cluster to be available:1
health state reason:storage cluster is unhealthy.
# of node failures before cluster shuts down:2
# of node failures before cluster goes into readonly:2
# of persistent devices failures tolerable for cluster to be available:1
# of node failures before cluster goes to enospace warn trying to move the existing data:na
# of persistent devices failures before cluster shuts down:2
# of persistent devices failures before cluster goes into readonly:2
# of caching failures before cluster goes into readonly:na
# of caching devices failures tolerable for cluster to be available:2
resiliencyInfo:
messages:
Storage cluster is unhealthy.
state: 2
nodeFailuresTolerable: 1
cachingDeviceFailuresTolerable: 2
persistentDeviceFailuresTolerable: 1
zoneResInfoList: None
spaceStatus: normal
totalCapacity: 225.0T
totalSavings: 42.93%
usedCapacity: 67.7T
clusterAccessPolicy: lenient
dataReplicationCompliance: non_compliant
dataReplicationFactor: 3
So suchen Sie mithilfe der Befehlszeilenschnittstelle (CLI) nach einem SED-Cluster
Wenn kein Zugriff auf HX Connect möglich ist, kann die CLI verwendet werden, um zu überprüfen, ob der Cluster SED ist.
# Check if the cluster is SED capable
root@SpringpathController:~# cat /etc/springpath/sed_capability.conf sed_capable_cluster=False
# Check if the cluster is SED enabled root@SpringpathController:~# cat /etc/springpath/sed.conf sed_encryption_state=unknown
root@SpringpathController:~# /usr/share/springpath/storfs-appliance/sed-client.sh -l WWN,Slot,Supported,Enabled,Locked,Vendor,Model,Serial,Size 5002538c40a42d38,1,0,0,0,Samsung,SAMSUNG_MZ7LM240HMHQ-00003,S3LKNX0K406548,228936 5000c50030278d83,25,1,1,0,MICRON,S650DC-800FIPS,ZAZ15QDM0000822150Z3,763097 500a07511d38cd36,2,1,1,0,MICRON,Micron_5100_MTFDDAK960TCB_SED,17261D38CD36,915715 500a07511d38efbe,4,1,1,0,MICRON,Micron_5100_MTFDDAK960TCB_SED,17261D38EFBE,915715 500a07511d38f350,7,1,1,0,MICRON,Micron_5100_MTFDDAK960TCB_SED,17261D38F350,915715 500a07511d38eaa6,3,1,1,0,MICRON,Micron_5100_MTFDDAK960TCB_SED,17261D38EAA6,915715 500a07511d38ce80,6,1,1,0,MICRON,Micron_5100_MTFDDAK960TCB_SED,17261D38CE80,915715 500a07511d38e4fc,5,1,1,0,MICRON,Micron_5100_MTFDDAK960TCB_SED,17261D38E4FC,915715
HX-Servicemodus gegenüber ESXi-Servicemodus
Wenn Wartungsaktivitäten auf einem Server ausgeführt werden müssen, der Teil eines HX-Clusters ist, sollte statt des ESXi-Servicemodus der HX-Servicemodus verwendet werden. Das SCVM wird ordnungsgemäß heruntergefahren, wenn der HX-Servicemodus verwendet wird, während es bei Verwendung des ESXi-Servicemodus abrupt heruntergefahren wird.
Während sich ein Knoten im Wartungsmodus befindet, wird er als ausgefallen betrachtet, d. h. als ein Knotenausfall.
Vergewissern Sie sich, dass der Cluster als fehlerfrei angezeigt wird, bevor Sie einen anderen Knoten in den Wartungsmodus versetzen.
root@SpringpathController:~# stcli cluster storage-summary --detail
<snip>
current ensemble size:3
# of caching failures before cluster shuts down:3
minimum cache copies remaining:3
minimum data copies available for some user data:3
minimum metadata copies available for cluster metadata:3
# of unavailable nodes:0
# of nodes failure tolerable for cluster to be available:1
health state reason:storage cluster is healthy.
# of node failures before cluster shuts down:3
# of node failures before cluster goes into readonly:3
# of persistent devices failures tolerable for cluster to be available:2
# of node failures before cluster goes to enospace warn trying to move the existing data:na
# of persistent devices failures before cluster shuts down:3
# of persistent devices failures before cluster goes into readonly:3
# of caching failures before cluster goes into readonly:na
# of caching devices failures tolerable for cluster to be available:2
resiliencyInfo:
messages:
Storage cluster is healthy.
state: 1
nodeFailuresTolerable: 1
cachingDeviceFailuresTolerable: 2
<snip>
Häufig gestellte Fragen
Wo sind die SCVMs auf den Cisco HyperFlex M4- und M5-Servern installiert?
Der SCVM-Standort unterscheidet sich zwischen Cisco HyperFlex M4- und M5-Servern. In der folgenden Tabelle sind der Standort des SCVM und weitere nützliche Informationen aufgeführt.
| Cisco HX-Server | ESXi | SCVM sda |
SSD (Caching Solid State Drive) | SSD für die Organisation sdb1 und sdb2 |
| HX 220 M4 | Secure Digital (SD-Karten) | 3,5 G auf SD-Karten | Steckplatz 2 | Steckplatz 1 |
| HX 240 M4 | SD-Karten | Auf PCH-gesteuertem SSD (esxi hat die Kontrolle darüber) | Steckplatz 1 | Auf PCH-gesteuerter SSD |
| HX 220 M5 | M.2-Laufwerk | M.2-Laufwerk | Steckplatz 2 | Steckplatz 1 |
| HX 240 M5 | M.2-Laufwerk | M.2-Laufwerk | Rückseite SSD | Steckplatz 1 |
Wie viele fehlerhafte Knoten kann ein Cluster tolerieren?
Die Anzahl der Ausfälle, die ein Cluster tolerieren kann, hängt vom Replikationsfaktor und von der Zugriffsrichtlinie ab.
Cluster mit 5 oder mehr Knoten
Wenn der Replication Factor (RF) 3 ist und die Zugriffsrichtlinie auf Lenient festgelegt ist, befindet sich das Cluster bei Ausfall von zwei Knoten weiterhin im Lese-/Schreibstatus. Wenn drei Knoten ausfallen, wird der Cluster heruntergefahren.
| Replikationsfaktor | Zugriffsrichtlinie | Anzahl der fehlerhaften Knoten | ||
| Lesen/Schreiben | Schreibgeschützt | Herunterfahren | ||
| 1 | leuchtend | 2 | — | 1 |
| 1 | Strict | 1 | 2 | 1 |
| 2 | leuchtend | 1 | — | 2 |
| 2 | Strict | — | 1 | 2 |
Cluster mit 3 und 4 Knoten
Wenn die RF-Instanz 3 ist und die Zugriffsrichtlinie auf "Lenient" oder "Strict" festgelegt ist, befindet sich der Cluster bei Ausfall eines einzelnen Knotens weiterhin im Lese-/Schreibstatus. Wenn zwei Knoten ausfallen, wird der Cluster heruntergefahren.
| Replikationsfaktor | Zugriffsrichtlinie | Anzahl der fehlerhaften Knoten | ||
| Lesen/Schreiben | Schreibgeschützt | Herunterfahren | ||
| 1 | Lenient oder Strict | 1 | — | 2 |
| 2 | leuchtend | 1 | — | 2 |
| 2 | Strict | — | 1 | 2 |
Beispiel für ein Cluster mit 3 Knoten (RF: 3, Zugriffsrichtlinie: Lenient)
Beispiel für eine grafische Benutzeroberfläche
CLI-Beispiel
root@SpringpathController:~# stcli cluster storage-summary --detail
<snip>
current ensemble size:3
# of caching failures before cluster shuts down:3
minimum cache copies remaining:3
minimum data copies available for some user data:3
minimum metadata copies available for cluster metadata:3
# of unavailable nodes:0
# of nodes failure tolerable for cluster to be available:1
health state reason:storage cluster is healthy.
# of node failures before cluster shuts down:3
# of node failures before cluster goes into readonly:3
# of persistent devices failures tolerable for cluster to be available:2
# of node failures before cluster goes to enospace warn trying to move the existing data:na
# of persistent devices failures before cluster shuts down:3
# of persistent devices failures before cluster goes into readonly:3
# of caching failures before cluster goes into readonly:na
# of caching devices failures tolerable for cluster to be available:2
resiliencyInfo:
messages:
Storage cluster is healthy.
state: 1
<snip>
clusterAccessPolicy: lenient
Was passiert, wenn eine der SCVMs heruntergefahren wird? Funktionieren VMs weiterhin?
VMs funktionieren weiterhin normal. Im folgenden Beispiel wurde das SCVM heruntergefahren, die Datenspeicher blieben jedoch gemountet und verfügbar.
[root@node1:~] vim-cmd vmsvc/getallvms
Vmid Name File Guest OS Version Annotation
1 stCtlVM-F 9H [SpringpathDS-F 9H] stCtlVM-F 9H/stCtlVM-F 9H.vmx ubuntu64Guest vmx-13
[root@node1:~] vim-cmd vmsvc/power.off 1
Powering off VM:
[root@node1:~] vim-cmd vmsvc/power.getstate 1
Retrieved runtime info
Powered off
[root@node1:~] esxcfg-nas -l
Test is 10.197.252.106:Test from 3203172317343203629-5043383143428344954 mounted available
ReplSec is 10.197.252.106:ReplSec from 3203172317343203629-5043383143428344954 mounted available
New_DS is 10.197.252.106:New_DS from 3203172317343203629-5043383143428344954 mounted available
Die VMware-Hardwareversion auf dem SCVM wurde aktualisiert. Jetzt was?
Die Aktualisierung der VMware-Hardwareversion durch Bearbeiten der VM-Einstellungen unter Kompatibilität > Upgrade VM-Kompatibilität ist der vSphere Web Client auf einem SCVM NICHT unterstützt. Das SCVM meldet in HX Connect als Offline.
root@SpringpathController0 UE:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 2.5G 0 disk `-sda1 8:1 0 2.5G 0 part / sdb 8:16 0 100G 0 disk |-sdb1 8:17 0 64G 0 part /var/stv `-sdb2 8:18 0 24G 0 part /var/zookeeper root@SpringpathController0 UE:~# lsscsi [2:0:0:0] disk VMware Virtual disk 2.0 /dev/sda [2:0:1:0] disk VMware Virtual disk 2.0 /dev/sdb root@SpringpathController0 UE:~# cat /var/log/springpath/diskslotmap-v2.txt 1.11.1:5002538a17221ab0:SAMSUNG:MZIES800HMHP/003:S1N2NY0J201389:EM19:SAS:SSD:763097:Inactive:/dev/sdc 1.11.2:5002538c405537e0:Samsung:SAMSUNG_MZ7LM3T8HMLP-00003:S 98:GXT51F3Q:SATA:SSD:3662830:Inactive:/dev/sdd 1.11.3:5002538c4055383a:Samsung:SAMSUNG_MZ7LM3T8HMLP-00003:S 88:GXT51F3Q:SATA:SSD:3662830:Inactive:/dev/sde 1.11.4:5002538c40553813:Samsung:SAMSUNG_MZ7LM3T8HMLP-00003:S 49:GXT51F3Q:SATA:SSD:3662830:Inactive:/dev/sdf 1.11.5:5002538c4055380e:Samsung:SAMSUNG_MZ7LM3T8HMLP-00003:S 44:GXT51F3Q:SATA:SSD:3662830:Inactive:/dev/sdg 1.11.6:5002538c40553818:Samsung:SAMSUNG_MZ7LM3T8HMLP-00003:S 54:GXT51F3Q:SATA:SSD:3662830:Inactive:/dev/sdh 1.11.7:5002538c405537d1:Samsung:SAMSUNG_MZ7LM3T8HMLP-00003:S 83:GXT51F3Q:SATA:SSD:3662830:Inactive:/dev/sdi 1.11.8:5002538c405537d8:Samsung:SAMSUNG_MZ7LM3T8HMLP-00003:S 90:GXT51F3Q:SATA:SSD:3662830:Inactive:/dev/sdj 1.11.9:5002538c4055383b:Samsung:SAMSUNG_MZ7LM3T8HMLP-00003:S 89:GXT51F3Q:SATA:SSD:3662830:Inactive:/dev/sdk 1.11.10:5002538c4055381f:Samsung:SAMSUNG_MZ7LM3T8HMLP-00003:S 61:GXT51F3Q:SATA:SSD:3662830:Inactive:/dev/sdl 1.11.11:5002538c40553823:Samsung:SAMSUNG_MZ7LM3T8HMLP-00003:S 65:GXT51F3Q:SATA:SSD:3662830:Inactive:/dev/sdm
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)