VPLEX: El estado del servicio de volúmenes virtuales distribuidos se muestra como Desconectado

Versiones de código de GeoSincronía de VPLEX afectadas:
Software: GeoSynchony 6.0 Service Pack 1 parche 2

Hardware de VPLEX afectado:
Serie
VPLEX, VPLEX VS2
, VPLEX VS6
, VPLEX-Metro

Después de una actualización a GeoSynchrony 6.0 Service Pack 1 parche 2 (6.0.1.02.00.03), los volúmenes virtuales distribuidos tienen un estado de servicio de "desconectado". Esto no afecta las I/O, y el cliente no debería ver DU debido a este problema.

La marca AMF_REEXPORT_QD es una marca recién introducida en el firmware. Ayuda a realizar un seguimiento interno de las exportaciones pendientes en caso de que el maestro AMG se caiga. Se implementa en amf_flags, que es un campo visible para la CLI.

Cuando aparecen los segundos actualizadores durante la NDU, esta marca se establece como parte del funcionamiento normal. Por lo general, la marca se desactivará durante la reexportación del AMF. Sin embargo, durante el arranque, la primera reexportación omite esta fase. Esto hace que la marca permanezca establecida hasta la próxima reexportación. La marca en sí es benigna y no interfiere con la I/O ni con la configuración del sistema.

Cuando se ejecuta el resumen de volúmenes virtuales, los volúmenes tienen el estado de servicio "disconnected":

Virtual-volume health summary

virtual-volume name                health state  operational status  service status
---------------------------------  ------------  ------------------  --------------
<vvol name>                         ok            ok                  disconnected

El dispositivo distribuido subyacente también puede aparecer como desconectado o en ejecución.

Ejemplo de un dispositivo distribuido que se muestra como "desconectado":

/distributed-storage/distributed-devices/<distributed-device name>:

Attributes:
Name                    Value
----------------------  --------------------------------
application-consistent  false
auto-resume             true
block-count             536870912
block-size              4K
capacity                2T
clusters-involved       [cluster-1, cluster-2]
geometry                raid-1
health-indications      []
health-state            ok
locality                distributed<<--
operational-status      ok
rebuild-allowed         true
rebuild-eta             -
rebuild-progress        -
rebuild-status          done
rebuild-type            full
rule-set-name           cluster-1-detaches

service-status      -->>disconnected<<--

stripe-depth            -
system-id               <name>
thin-capable            true
transfer-size           128K
virtual-volume          <vvol name>

Ejemplo de un dispositivo distribuido que se muestra como "en ejecución":

/distributed-storage/distributed-devices/<distributed-device name>:

Attributes:
Name                    Value
----------------------  ------------------------------------------
application-consistent  false
auto-resume             true
block-count             536874240
block-size              4K
capacity                2T
clusters-involved
consistency-group
geometry                raid-1
health-indications      []
health-state            ok
locality                distributed
operational-status      ok
rebuild-allowed         true
rebuild-eta             -
rebuild-progress        -
rebuild-status          done
rebuild-type            full
rule-set-name           cluster-2-detaches
service-status          running        <<<<
storage-array-family    symmetrix
stripe-depth            -
system-id               <name>
thin-capable            true
transfer-size           128K
virtual-volume          <vvol name>

Un error en el código FLL del lado del servidor está causando que la marca reexport-qd se lea desde el AMF. En realidad, el código tiene la intención de leer la marca non-splitting-fail-all. Esto hace que la CLI informe el volumen como desconectado cuando se realiza una consulta con FLL.

FLL es una función presentada en GeoSynchrony 6.0 Service Pack 1 parche 2 (6.0.1.02.00.03). En esta función, algunas tareas del servidor de administración se descargan en los directores para aliviar el posible impacto en el rendimiento del servidor de administración.

Si este problema se observa después de una actualización a GeoSynchrony 6.0 Service Pack 1 parche 2 (6.0.1.02.00.03), comuníquese con el soporte al cliente de Dell y mencione el ID de este artículo de la base de conocimientos.