Conocimiento general útil de HyperFlex

Introducción

Este documento describe los conocimientos generales sobre Cisco HyperFlex (HX) que los administradores deben tener al alcance de su mano.

Acrónimos utilizados habitualmente

SCVM = Máquina virtual del controlador de almacenamiento

VMNIC = Tarjeta de interfaz de red de máquina virtual

VNIC = Tarjeta de interfaz de red virtual

SED = AutoCifrado Unidad

VM = Máquina virtual

HX = HyperFlex 

Pedidos de HyperFlex VMware VMNIC

La ubicación de VMNIC se ha revisado en HX versión 3.5 y posteriores.

Pedidos anteriores a 3.5

Antes de la versión 3.5, las VNIC se asignaban en función de los números VNIC.

VNIC	Switch virtual (vSwitch)
VNIC 0 y VNIC 1	vSwitch-hx-inband-mgmt
VNIC 2 y VNIC 3	vSwitch-hx-storage-data
VNIC 4 y VNIC 5	vSwitch-hx-vm-network
VNIC 6 y VNIC 7	vMotion

Publicación 3.5 Pedidos

En la versión 3.5 y posteriores, las VNIC se asignan en función de la dirección MAC (Control de acceso a medios). Por lo tanto, no hay un orden particular de asignación.

Si se realiza una actualización de una versión anterior a 3.5 a 3.5 o superior, se mantiene el pedido de VMNIC. 

Nota: Para HX Hyper-V, esto no será aplicable, ya que Hyper-V utiliza el nombre uniforme de dispositivo (CDN).

 

SCVM en nodo convergente frente a nodo informático

Las SCVM residen tanto en los nodos convergentes como en los de cálculo y hay diferencias entre ellos.

Nodo convergente

Reservas de recursos de la CPU

Dado que las SCVM proporcionan una funcionalidad crítica de la plataforma de datos distribuidos Cisco HX, el instalador de HyperFlex configurará las reservas de recursos de la CPU para las VM del controlador. Esta reserva garantiza que las VM del controlador tengan recursos de unidad de procesamiento central (CPU) en un nivel mínimo, en situaciones en las que las VM invitadas consumen en gran medida los recursos físicos de la CPU del host del hipervisor ESXi. Se trata de una garantía de software, lo que significa que en la mayoría de las situaciones las SCVM no utilizan todos los recursos de CPU reservados, lo que permite que las VM invitadas las utilicen. La siguiente tabla detalla la reserva de recursos de CPU de las VM del controlador de almacenamiento:

Número de vCPU	Recursos compartidos	Reserva	Límite
8	Bajo	10800 MHZ	Ilimitado

Reservas de recursos de memoria

Dado que las SCVM proporcionan una funcionalidad crítica de la plataforma de datos distribuidos Cisco HX, el instalador de HyperFlex configurará las reservas de recursos de memoria para las VM del controlador. Esta reserva garantiza que las VM del controlador tengan recursos de memoria en un nivel mínimo, en situaciones en las que las VM invitadas consumen en gran medida los recursos de memoria física del host del hipervisor ESXi. La siguiente tabla detalla la reserva de recursos de memoria de las VM del controlador de almacenamiento:

Modelos de servidor	Cantidad de memoria de invitado	Reservar toda la memoria de invitado
HX 220c-M5SX HXAF 220c-M5SX   HX 220c-M4S HXAF220c-M4S	48 GB	Yes
HX 240c-M5SX HXAF 240c-M5SX HX240c-M4SX HXAF240c-M4SX	72 GB	Yes
HX240c-M5L	78 GB	Yes

Nodo de cálculo

Los nodos sólo informáticos tienen una SCVM ligera. Está configurado con sólo 1 vCPU de 1024 MHz y 512 MB de reserva de memoria.

El propósito de tener el nodo de cálculo es principalmente mantener la configuración de vCluster Distributed Resource Scheduler™ (DRS), para asegurarse de que DRS no mueva las VM de usuario a nodos convergentes.

Escenarios de clúster insalubres 

Un clúster HX puede convertirse en insalubre en los siguientes escenarios.

Escenario 1: Nodo Abajo

Un agrupamiento pasa a un estado no saludable cuando un nodo se desactiva. Se espera que un nodo esté inactivo durante una actualización del clúster o cuando un servidor se pone en modo de mantenimiento.

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

Escenario 2: Disco inactivo

Un agrupamiento pasa a un estado no saludable cuando un disco no está disponible. La condición debe despejar cuando los datos se distribuyen a otros discos. 

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

Escenario 3: Ni nodo ni disco inactivo

Un clúster puede entrar en un estado no saludable cuando ni un nodo ni un disco están inactivos. Esta condición se produce si la reconstrucción está en curso.

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

Cómo buscar un clúster SED mediante la interfaz de línea de comandos (CLI)

Si el acceso a HX Connect no está disponible, la CLI se puede utilizar para verificar si el clúster es SED. 

# 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

Modo de mantenimiento de HX frente al modo de mantenimiento de ESXi

Cuando las actividades de mantenimiento deben realizarse en un servidor que forma parte de un clúster de HX, se debe utilizar el Modo de mantenimiento de HX en lugar del Modo de mantenimiento de ESXi. El SCVM se apaga con elegancia cuando se utiliza el Modo de Mantenimiento de HX mientras se cierra abruptamente cuando se utiliza el Modo de Mantenimiento de ESXi.

Mientras un nodo se encuentra en modo de mantenimiento, se considerará inactivo, es decir, una falla de nodo.

Asegúrese de que el clúster se muestra como saludable antes de mover otro nodo al modo de mantenimiento.

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>

Preguntas Frecuentes

¿Dónde están instaladas las SCVM en los servidores Cisco HyperFlex M4 y M5?

La ubicación de SCVM es diferente entre los servidores Cisco Hyperflex M4 y M5. En la tabla siguiente se muestra la ubicación del SCVM y se proporciona otra información útil.

Servidor Cisco HX	ESXi	SCVM               sda	Almacenamiento en caché de unidades de estado sólido (SSD)	SSD de mantenimiento de la casa   sdb1 y sdb2
HX 220 M4	Secure Digital(tarjetas SD)	3,5G en tarjetas SD	Ranura 2	Ranura 1
HX 240 M4	Tarjetas SD	En la SSD controlada por PCH (esxi controla esto)	Ranura 1	En la SSD controlada por PCH
HX 220 M5	Unidad M.2	Unidad M.2	Ranura 2	Ranura 1
HX 240 M5	Unidad M.2	Unidad M.2	SSD de ranura trasera	Ranura 1

¿Cuántos nodos fallidos puede tolerar un clúster?

El número de fallas que un clúster puede tolerar dependerá del Factor de Replicación y la Política de Acceso.

Clústeres con 5 o más nodos

Cuando el factor de replicación (RF) es 3 y la política de acceso se establece en indulgente, si 2 nodos fallan, el clúster seguirá en estado de lectura/escritura. Si 3 nodos fallaran, el clúster se cerrará.

Factor de replicación	Política de acceso	Número de nodos fallidos
		Lectura/escritura	Sólo lectura	Apagado
3	indulgente	2	—	3
3	Estricto	1	2	3
2	indulgente	1	—	2
2	Estricto	—	1	2

Clústeres con 3 y 4 nodos

Cuando el RF es 3 y la política de acceso se establece en Lenient o Strict, si falla un solo nodo, el clúster aún se encuentra en estado de lectura/escritura. Si 2 nodos fallan, el clúster se apagará.

Factor de replicación	Política de acceso	Número de nodos fallidos
		Lectura/escritura	Sólo lectura	Apagado
3	Leniente o estricto	1	—	2
2	indulgente	1	—	2
2	Estricto	—	1	2

Ejemplo de un clúster de 3 nodos (RF: 3, Política de acceso: Lenient) 

Ejemplo de interfaz gráfica de usuario (GUI)

Ejemplo de CLI

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

¿Qué sucede si se apaga una de las SCVM? ¿Siguen funcionando las VM?

Advertencia: Esta no es una operación soportada en una SCVM. Esto es sólo con fines de demostración.

Nota: Asegúrese de que sólo una SCVM esté inactiva a la vez. Además, asegúrese de que el clúster esté en buen estado antes de que se cierre una SCVM. Esta situación solo pretende demostrar que se espera que las VM y los almacenes de datos funcionen incluso si SCVM no está disponible o no está disponible.

Las VM seguirán funcionando normalmente. A continuación se muestra un ejemplo de salida donde se cerró el SCVM, pero los almacenes de datos permanecieron montados y disponibles.

[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

Se ha actualizado la versión de hardware de VMware en el SCVM. ¿Ahora qué?

Advertencia: Esta no es una operación soportada en una SCVM. Esto es sólo con fines de demostración.

La actualización de la versión de hardware de VMware mediante la edición de la configuración de VM en Compatibilidad > Compatibilidad de VM de actualización es el vSphere Web Client NO es una operación soportada en una SCVM. El SCVM informará como Desconectado en HX Connect.

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

Precaución: Si se ha realizado esta operación accidentalmente, póngase en contacto con el servicio de asistencia de Cisco para obtener más ayuda. El SCVM tendrá que ser reimplementado.