Busque Boletín sobre tiempo de actividad en la página

de la serie VNX:

https://support.emc.com/products/12781

Marzo de 2016

QUISIÉRAMOS CONOCER SUS COMENTARIOS ACERCA DEL

BOLETÍN SOBRE TIEMPO DE ACTIVIDAD. ENVÍENOS

SUS IDEAS PARA FUTUROS

TEMAS A:

UptimeforVNX@emc.com

https://mydocuments.emc.com/

VNX

http://emc.com/vnxesupport

Todos los ambientes operativos de VNX2 (desde 05.33.006.5.096 hasta 05.33.008.5.119, inclusive) son vulnerables a un problema muy raro cuando se promueven datos a FAST Cache mientras una unidad experimenta errores de medios. EMC observó que, en los Sistemas de almacenamiento que ejecutan la gama de código antes apuntada, se producía un número muy reducido de instancias en que se promovía un error a FAST Cache antes de que RAID lo resolviera. Este error tiene pocas probabilidades de producirse y solo en escenarios muy concretos.

Esta situación solo puede producirse durante la reconstrucción o el repuesto proactivo de una unidad con errores de medios. En circunstancias normales, cuando se produce un error de medios, RAID consulta la CRC para buscar los datos no válidos y los reconstruye a partir de la paridad. Si se produce una lectura de host en una fracción que tiene un error de medios mientras una unidad con errores de medios está realizando una actividad de repuesto o reconstrucción, el algoritmo de promoción de FAST Cache promueve la fracción con el error directamente a FAST Cache en paralelo al proceso normal y RAID corrige el error y devuelve los datos corregidos al host. En este raro escenario, el host recibía los datos correctos, pero los datos invalidados se promovían directamente a FAST Cache antes de corregirlos. Se trata de un error.

Si se produce esta situación, las lecturas subsiguientes en la misma fracción de datos intentarán realizarse en FAST Cache, de modo que quizá encuentren los datos invalidados que se promovieron. En ese caso, los datos no serán válidos, por lo que el sistema de almacenamiento devolverá un error al host o la aplicación que solicitó la lectura. Es lo que se denomina un error imposible de corregir; para obtener más información sobre esta situación concreta, consulte la solución KB477140 de la base de conocimientos.

En el improbable caso de que se produzca este escenario, suele ser beneficioso vaciar FAST Cache cuanto antes e iniciar una verificación de fondo de solo lectura (ROBV) en el pool que contiene la unidad que estaba reconstruyéndose en el momento en que se promovieron los datos a FAST Cache. Como FAST Cache solo vuelve a escribir los datos de páginas sin sincronizar en los LUN del pool subyacente cuando se vacía FAST Cache, es posible que, si la página en cuestión ya está sincronizada, nunca vuelva a escribirse el error en ningún LUN del pool. Dada la posibilidad de que la eliminación de FAST Cache vuelva a escribir los datos invalidados en el LUN del pool, es preciso ejecutar ROBV en los LUN del pool subyacente después de vaciar FAST Cache a fin de determinar si se vio afectado algún dato. FAST Cache puede habilitarse de nuevo antes de que se complete ROBV, ya que esta verificación suele demorar bastante en VNX2; ahora bien, la reparación descrita en la solución de la base de conocimientos debe aplicarse, si es posible, antes de volver a habilitar FAST Cache para evitar la reaparición del problema. La reparación recomendada para este problema consiste en actualizar a la última versión del ambiente operativo de VNX2: R33.155.

R33.155 resuelve el problema de los errores promovidos a FAST Cache

1

Problema de latencia de VNX o VPLEX al agregar o quitar LUN

2

R33.155 resuelve el problema de NDU con los LUN deduplicados

2

Importancia de registrar el sistema

2

Consejos del día 2

Últimas versiones de código y reparaciones importantes

3

Problema de pérdida de memoria de VNXe2

4

Recuperación de espacio en VMware

4

Actualización de MCC 4

Chat en línea: el chat en línea de EMC es el

método recomendado de la mayoría de los

clientes para obtener acceso rápido y directo

a los expertos de soporte técnico de EMC. El

chat en línea acelera la solución de problemas,

ya que elimina los tiempos de espera telefónica

y la necesidad de que EMC lo vuelva a llamar.

Es el canal de comunicación de soporte más

rápido para iniciar solicitudes de servicio

de EMC de cualquier gravedad con respecto

a problemas tanto técnicos como no técnicos.

Mire en el siguiente video de YouTube la

demostración del uso del chat en línea:

https://www.youtube.com/watch?

v=d5Yt5XPJU7M&list=PLbssOJyyvHuXJyAmhI1SQZ

T-1icaH9FGl&index=1

¿Alguna vez se planteó cómo administra VNX,

VNX2 o VNX2e la recuperación de espacio del pool? Consulte la base de conocimientos: 479495.

En los ambientes operativos de VPLEX, versiones 5.3P4 o posteriores y 5.4.1P1 o posteriores, los usuarios pueden observar latencia después de agregar LUN al grupo de almacenamiento de VPLEX en VNX o quitarlos de él. Cuando se produce un cambio en la configuración en el grupo de almacenamiento de VPLEX en VNX, VNX publica un mensaje de atención a la unidad en todos los ITL (rutas) de cada uno de los LUN del grupo de almacenamiento. El efecto secundario no deseado de la reparación crítica incluida en las versiones de VPLEX antes señaladas es que, ahora, se demora más el borrado de todas las atenciones a la unidad de todos los ITL y, durante este periodo, toda la I/O permanece en pausa. Como consecuencia, la acción se completa en hasta 30 o 40 segundos, durante los cuales se agota el tiempo de espera de los hosts o las aplicaciones.

Corrección disponible: VPLEX recomienda mantener la conexión de back-end entre VNX y los directores de VPLEX en un máximo de 4 rutas primarias disponibles y 4 rutas alternativas. Tanto VPLEX como VNX están trabajando en cambios de código para solucionar este problema. Consulte el artículo 478940 de la base de conocimientos para conocer la información más reciente sobre este problema, así como el estado actual de las iniciativas de corrección del código.

Es importante informar a EMC sobre la instalación y la actualización de sistemas nuevos. EMC necesita la información de configuración del sistema y los datos de contacto a fin de ofrecer la máxima satisfacción al cliente. Este proceso es muy fácil y rápido gracias a la herramienta de registro incluida en Unisphere Service Manager (USM). La herramienta debe ejecutarse al instalar el sistema por primera vez y después de cada actualización. La herramienta de registro del sistema de almacenamiento recopila información del sistema y la envía al proveedor de servicios por un canal seguro.

Para registrar el sistema:

Inicie Unisphere Service Manager (USM) mediante alguno de estos métodos: Haga clic en el ícono de Unisphere Service Manager del escritorio o elija Inicio > Todos los programas > EMC > Unisphere > Unisphere Service Manager.

Inicie sesión en el sistema que desea registrar para que aparezca en la lista de sistemas.

Seleccione el sistema que desea registrar en la lista de sistemas.

Elija Registro > Registrar sistema de almacenamiento. De esta manera, se iniciará Asistente de registro del sistema de almacenamiento, que guía por los pasos necesarios.

Se descubrió en sitio un problema que implicaba las NDU a R33, parche 119, de los clientes que utilizaban la deduplicación. Durante la NDU de cualquier versión R33 a R33.119, los LUN deduplicados pueden quedar offline sin marcarse para la recuperación. La naturaleza de este error producía incoherencias con los LUN, que quedaban offline sin la marca de recuperación correcta. Si más adelante se ejecuta la recuperación para volver a poner en línea el LUN, se encuentran incoherencias que, al repararse, provocan la pérdida de datos. La pérdida de datos ya es permanente en este punto, por lo que requerirá la restauración de datos a partir del respaldo.

Se implantaron políticas y procedimientos para evitar que el equipo de servicio al cliente ejecute la recuperación con los LUN deduplicados en esta situación. Se creó un hot fix para resolver la situación en el caso de los clientes que ya habían aplicado la actualización y tenían offline los LUN deduplicados. Se publicó un artículo en la base de conocimientos, en el cual se recomienda que los clientes que tengan LUN deduplicados dejen en espera todas las actualizaciones a R33.119.

R33.155 ya resuelve por completo este problema y quita la restricción a las actualizaciones para los clientes con LUN deduplicados.

A fin de garantizar ambientes estables y confiables, EMC establece revisiones de destino para cada producto. Como mejor práctica, EMC recomienda trabajar en los niveles de código de destino o superiores para aprovechar las últimas mejoras y reparaciones disponibles. Busque el término “tasas de adopción” en http://support.emc.com para obtener las tasas de adopción de código de destino actuales de VNX/VNXe.

Consulte las notas de la versión del producto para ver una lista completa de las mejoras de

cada versión nueva del código.

Reparación del problema por el que, en

ocasiones, el procesador de almacenamiento se reiniciaba después de más de 300 días

de actividad ininterrumpida.

Resolución del problema por el que, en

ocasiones, el procesador de almacenamiento se reiniciaba si había estado en ejecución

ininterrumpida durante más de 300 días.

Inclusión de todas las reparaciones

de 05.32.000.5.217 y lo siguiente:

Reparación de un error de regresión que podría

dejar a cualquier sistema de almacenamiento que utiliza FIPS en un estado inmanejable

después de la actualización del sistema a la versión 05.32.000.5.217.

El código de archivo 7.1.79.8 asociado repara

un problema de deduplicación de archivos

únicamente presente en la versión 7.1.79.6.

Versión menor que se basa en las reparaciones

de R32.217 y R32.218 e incluye también una reparación para los problemas relacionados con

la inactividad de las unidades de los gabinetes de 60 unidades durante las actualizaciones no

disruptivas.

Resolución del problema por el que, en raras

ocasiones, los datos invalidados se promovían a FAST Cache durante la operación de

reconstrucción o de copia proactiva de la unidad.

Reparación de los raros problemas relacionados

con uDoctor que, en ocasiones, desencadenaban

el reinicio del procesador de almacenamiento poco tiempo después de que la unidad informe

sobre errores de medios.

Reparación del raro problema con uDoctor que,

en ocasiones, provocaba que aumentara de forma poco habitual la utilización del procesador de almacenamiento.

Reparación del problema que, en raras

ocasiones, generaba la alarma del Data

Mover o del procesador de almacenamiento y provocaba que el LUN mapeado directamente

(DLU) dejara de aceptar la I/O del host desde el vencimiento de la ventana de reubicación

del almacenamiento automático en niveles.

Disponibilidad de PACO-R para todos los tipos

de unidad.

Priorización de USM de las actualizaciones

disponibles de firmware de las unidades en

“urgentes” o “normales”.

Actualización de firmware de las unidades

en todos los números de referencia de forma

automática.

Tiempo de reconstrucción de las unidades

reducido a la mitad.

Rastreo del tiempo de actividad de los

procesadores de almacenamiento en múltiples ubicaciones.

Compatibilidad con el uso de discos flash de

10 WPD y 400 GB (SAS Flash 2) para FAST Cache en VNX5400 y posteriores (no compatible

con los modelos VNX5200).

Replicación de sincronización de VDM para MV.

2.4.4.22283 19/08/2015 Destino

2.4.4.22417 04/03/2016 Última versión

3.1.5.6801782 27/01/2016 Destino

3.1.5.6801782 27/01/2016 Última versión

7.1.79.8 (VNX for File) 26/05/15 Destino

7.1.79.8 (VNX for File) 26/05/15 Última versión

05.32.000.5.219 (VNX for Block) 29/09/2015 Destino

05.32.000.5.219 (VNX for Block) 29/09/2015 Última versión

8.1.8.121 (VNX for File) 19/10/2015 Destino

8.1.9.155 (VNX for File) 10/03/2016 Última versión

05.33.008.5.119 (VNX for Block) 10/08/2015 Destino

05.33.009.5.155 (VNX for Block) 10/03/2016 Última versión

EMC considera que la información de esta publicación es precisa en el momento de su publicación. La información está sujeta a cambios sin previo aviso.

LA INFORMACIÓN DE ESTA PUBLICACIÓN SE PROPORCIONA “TAL CUAL”. EMC CORPORATION NO SE HACE RESPONSABLE NI OFRECE GARANTÍA DE NINGÚN TIPO CON RESPECTO A LA INFORMACIÓN DE ESTA

PUBLICACIÓN Y ESPECÍFICAMENTE RENUNCIA A TODA GARANTÍA IMPLÍCITA DE COMERCIABILIDAD O CAPACIDAD PARA UN PROPÓSITO DETERMINADO.

El uso, la copia y la distribución de cualquier software de EMC descrito en esta publicación requieren una licencia de software correspondiente. EMC2, EMC, E-Lab, Powerlink, VNX, VMAX, VPLEX, VNXe, Unisphere, RecoverPoint y el

logotipo de EMC son marcas registradas o marcas comerciales de EMC Corporation en los Estados Unidos y en otros países. Todas las demás marcas comerciales incluidas/utilizadas en este documento pertenecen a sus respectivos

propietarios. Copyright © 2015 EMC Corporation. Todos los derechos reservados. Publicado en México, marzo de 2016.

Este trimestre, se publicó la ETA 207482 para informar a los clientes sobre la pérdida de memoria existente en la plataforma VNXe3200 específica de la versión 3.1.1.x del ambiente operativo. La pérdida de memoria se produce en el área de creación de informes sobre el estado del sistema de archivos. VNXe Operating Environment es responsable de la creación de informes sobre el estado del sistema de archivos, tanto CIFS como NFS. Con el tiempo y según el número de sistemas de archivos, la pérdida de memoria puede consumir toda la memoria disponible. Cuando se produce esto, uno de los procesadores de almacenamiento o ambos pueden generar una alarma y reiniciarse. Si da la casualidad de que ambos procesadores de almacenamiento se reinician al mismo tiempo, puede producirse un breve periodo de falta de disponibilidad de datos.

El problema descrito en esta ETA se soluciona en VNXe3200 Operating Environment versión 3.1.1.6297002; EMC recomienda a los clientes que tengan este problema instalar esa reparación (o una versión posterior) en cuanto sea posible. Es posible descargar el software desde el servicio de soporte en línea de EMC. Si lo prefiere, comuníquese con el Centro de Servicio al Cliente de EMC o con un representante de servicio de EMC para solicitar ayuda y mencione como referencia la ETA 207482.

En respuesta a comentarios de los clientes, el equipo de ingeniería de VPLEX proporcionó un “paquete de discos objetivo” que incluye VPLEX y otros componentes de EMC. Los clientes empresariales pueden utilizar este código validado por EMC como recopilación en toda su infraestructura. En el paquete de discos objetivo se enumeran las versiones de firmware de los productos de infraestructura de VPLEX y EMC (VNX, RecoverPoint, VMAX, etc.) cuyo uso conjunto como paquete de discos de punto a punto se validó en un ambiente acelerado y extremadamente exigente. Este paquete de discos objetivo se actualiza cada trimestre para proporcionar sus versiones de firmware más recientes para VPLEX y para el ecosistema.

MCC validó las versiones siguientes de los productos de infraestructura de EMC para la versión del cuarto trimestre de 2015 del paquete de discos objetivo:

ESXi 6.0 Express, parche 1

RecoverPoint 4.1 SP2, parche 1

VPLEX 5.4 SP1, parche 3

VMAX 5876.272.177

VMAX3 5977.596.583

VNX 05.33.006.5.102

ViPR SRM 3.6 SP4

Procedimiento de corrección cuando el consumo de espacio de VMFS de LUN delgados es mayor del esperado en función del uso de ESX.

Desde ESXi 5.x, se envían comandos UNMAP de VAAI a los LUN delgados para recuperar espacio eliminado de VMFS a fin de cubrir las necesidades continuas de almacenamiento. La recuperación de espacio puede afectar el rendimiento del arreglo y requerir más tiempo antes de que el espacio esté disponible para la reutilización en las demás librerías de cintas del pool. En ESXi500-201112001 (ESXi 5.0, parche 02) y ESXi 5.0, actualización 1, la operación está deshabilitada de manera predeterminada. Debe iniciarse manualmente.

Consulte kb.vmware.com/kb/2014849 para obtener información sobre este tema y aprender a recuperar espacio de forma manual.