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

serie VNX:

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

Septiembre de 2015

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

En los boletines anteriores, compartimos información con respecto a la primera versión de EMC del firmware mejorado para el disco SAS VNX de 600 GB, números de referencia 005049675 y 005049677, y también nos referimos a la introducción de un algoritmo de copia en disco proactivo y mejorado (PACO-R) para estas unidades en Block OE 05.32.000.5.217 para VNX. En el artículo KB195555 se proporciona más información sobre la FCO y se indica cómo se puede descargar el firmware e instalarlo mediante la herramienta ODFU de Unisphere Service Manager (USM).

Recomendamos que los clientes que poseen estas unidades instalen el código de Block OE más reciente para VNX (05.32.000.5.218), ya que este nuevo código implementa un algoritmo de copia en disco proactivo y mejorado (PACO-R) en todas las unidades, el cual ha demostrado agregar un beneficio gradual considerable a las mejoras de firmware.

Ahora, los clientes de VNX2 también pueden beneficiarse de la protección adicional que brinda PACO-R mejorado para estas unidades mediante la instalación de Block OE 05.33.006.5.119 o superior. Además, el siguiente service pack para VNX2 ofrecerá esta funcionalidad de PACO-R mejorado para todos los tipos de unidades, no solo para los modelos que se mencionan en este artículo.

EMC también evaluó y lanzó una segunda iteración del nuevo firmware para unidades (versión C840) para estos discos SAS de 600 GB que agrega un algoritmo verify after write para cualquier aparición de la función write same. La unidad emplea la función write same principalmente durante una operación de vinculación, en la cual el sistema de almacenamiento intenta dejar en cero todos los datos de un nuevo LUN. EMC detectó que es aquí donde se pueden producir muchas de las instancias de escrituras débiles que se ven en el campo. Este nuevo firmware eliminará las escrituras débiles durante la operación write same mediante la verificación de la integridad de cada una de las escrituras antes de que estas se consideren completadas correctamente. Con la sola adición de un algoritmo verify after write en esta instancia específica, el potencial impacto en el rendimiento se mantiene al mínimo.

La última versión lanzada de Unisphere Service Manager (USM) informará automáticamente cuando esté disponible el nuevo firmware para sus unidades. USM también se puede usar para descargar e instalar el nuevo firmware para las unidades como una actividad en línea. EMC recomienda contar con la versión más reciente disponible de Block OE para el sistema de almacenamiento VNX o VNX2, así como con el firmware más reciente disponible para estos discos SAS de 600 GB con el fin de aprovechar el potencial máximo de las mejoras en la confiabilidad optimizadas de EMC.

PACO-R para VNX2 y nuevo firmware para

las unidades

1

Mejores prácticas para NDU con reubicaciones

en curso

2

Comentarios de la

encuesta a los clientes 2

Actualización con mejoras de VAAI

y consejos

2

Revisiones del código de destino y reparaciones

clave

3

Actualización de Mission

Critical Center 4

Prevención de posibles problemas durante la actualización a

R32.217/R32.218

4

Algunas NDU pueden requerir actualizaciones manuales de la plantilla

de Call Home

4

Cuando se encienden los sistemas de almacena-

miento Unified VNX, es muy importante que el lado Block del sistema se encienda primero. Después de esperar hasta que el sistema Block esté completa-mente operacional y que todos sus LUN estén dis-ponibles, el lado File del arreglo de almacenamiento se puede encender con seguridad. Si un sistema

unificado no se enciende en este orden, se puede producir una falta de disponibilidad de datos del componente File. Los procedimientos de encendido/apagado correctos de VNX se pueden encontrar aquí: KB186307.

EMC planea implementar una actualización del

sistema de conectividad de ESRS considerable en el cuarto trimestre de 2015. Si usa ESRS, esté atento a

una carta de EMC dirigida al cliente que incluye más detalles sobre cómo puede aprovechar al máximo la actualización del sistema.

Estas recomendaciones se aplican a versiones de VNX OE dentro de las familias R31 y R32 si se actualizan desde las versiones 05.32.000.5.216 y anteriores, y a la familia R33 si se actualiza desde 05.33.000.X.081 y anteriores.

Las versiones de código de Block OE señaladas anteriormente eran vulnerables a una falla que permitía que un segmento de destino permaneciera asignado cuando la reubicación de FAST VP se anulaba en ciertas condiciones. Estos segmentos restantes no se limpian automáticamente y pueden dar lugar a reubicaciones fallidas con un mensaje similar al siguiente en los registros de eventos del SP:

“712d841a Could not complete operation Relocate 0xBxxxxxxxx failed CBFS status xxx because 0xe12d8417”

Cuando se actualiza a las versiones más recientes de R32 y R33, los LUN con estos segmentos restantes pueden quedar forzosamente offline si las reubicaciones ocurren durante la NDU.

Para impedir eventos de LUN offline y reducir la carga en el sistema durante una NDU, es necesario detener todas las reubicaciones antes de iniciar la actualización de software NDU. Esto se puede llevar a cabo mediante la ejecución del comando “naviseccli autotiering -relocation -stop -all -o” para impedir nuevas reubicaciones antes del inicio de la actualización. Las reubicaciones se reanudarán durante la ventana de reubicación calendarizada siguiente o cuando el usuario las inicie manualmente. Si antes de una actualización se observan eventos 0xE12d8417 en los registros, eleve el caso al servicio de soporte de EMC con referencia al artículo KB196650 para lograr que estos segmentos restantes se limpien de forma dinámica.

Problema: se han experimentado problemas para localizar documentos en la zona de soporte o en otros terminales de publicación. Este fue el principal problema planteado en la encuesta sobre la documentación.

Medida adoptada: el equipo de documentación de VNX desbloqueó nuestros archivos PDF (más de 8,000) y mejoró la optimización del motor de búsqueda

(SEO) de nuestro contenido. Los clientes pueden acceder a la mayor parte del contenido técnico de VNX en http://mexico.emc.com/ (visite el sitio web de su país correspondiente) sin tener que iniciar sesión.

Problema: se buscan otros tipos de terminales de publicación.

Medida adoptada: como resultado directo de la encuesta sobre la documentación y de una sesión Pregunte al experto, pretendemos implementar HTML5 y salidas de bibliotecas portátiles para nuestro mecanismo de distribución de contenido de última generación.

Problema: aproximadamente un tercio de los usuarios busca información adicional sobre la solución de problemas.

Medida adoptada: el contenido de preguntas frecuentes sobre la solución de problemas está orientado a las plataformas futuras.

Esté atento a las novedades: el equipo corporativo de experiencia total del cliente se complace en escuchar a los clientes a través de nuestras amplias encuestas sobre productos, así como mediante un proceso de seguimiento estructurado con los clientes que se toman el tiempo de enviar valiosos comentarios. Continuaremos con nuestro enfoque exacto en la experiencia total del cliente durante todo el viaje de un cliente con EMC.

Se planea que esta actualización de “Lo escuchamos” sea una sección habitual de los boletines sobre tiempo de actividad trimestrales de los productos principales.

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.

Soporte de todas las funciones de los nuevos

dispositivos mSATA internos que se usarán pronto para los reemplazos en sitio.

Esta versión contiene actualizaciones de

seguridad que se detallan en ESA-2015-023.

Soporte extendido de PACO-R para todas las

unidades. Con esto se logrará una reducción significativa de DU/DL debido a fallas de varias unidades.

Varias reparaciones clave al código de

LCC (CDES).

Las mejoras de rendimiento relacionadas con

VAAI que antes se ofrecían solo mediante un hot fix especial, ahora se ofrecen de manera estándar.

Solución de los problemas de rendimiento y los

SP alarmados asociados con el uso de la función “Describir extensiones” por parte de Trim/Unmap de Win2012 o RecoverPoint.

Incluye todas las reparaciones de

05.32.000.5.217 y lo siguiente:

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

dejar a cualquier sistema de almacenamiento que utiliza FIPS en un estado no administrado 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

soluciona un problema de regresión de la deduplicación de archivos que solo está presente en la versión 7.1.79.6.

Copia proactiva mejorada (PACO-R) para

unidades de 600 GB específicas con el fin de mejorar la confiabilidad.

Múltiples mejoras en la deduplicación.

Mejoras en el área de recuperación de espacio

de Savvol.

Se reparó el estado de alarma en un

administrador de transferencia de datos cuando se usa la función de descarga de operaciones de copia de CIFS.

Se mejoró la estabilidad del administrador de

transferencia de datos en condiciones de cargas altas de NFSv4.

Se mejoró el manejo de poco espacio en el LUN.

Mejoras relacionadas con la recuperación de

espacio de archivos.

2.4.3.21980 17/11/14 Destino

2.4.4.22283 19/08/15 Última versión

3.1.1.5803064 19/08/15 Destino

3.1.1.5803064 19/08/15 Ú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.218 (VNX for Block) 26/05/15 Destino

05.32.000.5.218 (VNX for Block) 26/05/15 Última versión

8.1.6.101 (VNX for File) 12/05/15 Destino

8.1.8.119 (VNX for File) 10/08/15 Última versión

05.33.000.5.102 (VNX for Block) 12/05/15 Destino

05.33.006.5.119 (VNX for Block) 10/08/15 Ú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, septiembre de 2015.

El quinto proyecto de Mission Critical Center (MCC), Project Hubble, se centró en dos actividades orientadas al cliente fundamentales:

Validación de la pila objetivo de VPLEX versión1

Reto de 100 días de MCC

Validación de la pila objetivo de VPLEX versión1: MCC, que está a la vanguardia del impulso de mejoras continuas en los productos y de la experiencia del cliente, dio inicio a un proyecto denominado VPLEX y la pila objetivo del ecosistema mediante la asociación con el equipo Project-A. La pila objetivo de VPLEX fue un conjunto de las versiones de productos de EMC en el mercado que mostraron la más alta confiabilidad. Estos productos se sometieron a validaciones de resistencia en un ambiente exigente altamente acelerado que se verificó con inyecciones de fallas. Se recomendó a los clientes usar la pila objetivo para lograr una disponibilidad mejorada. Consulte la sección VPLEX y la pila objetivo del ecosistema del Boletín sobre tiempo de actividad de EMC

VPLEX del tercer trimestre para obtener más información.

Reto de 100 días de MCC: este reto consistió en un esfuerzo por demostrar la resistencia del portafolio de EMC para empresas a gran escala que están centralizando sus centros de datos. Durante este reto, MCC simuló casos de uso del ciclo de vida de la TI que se ejecutaron en ambientes hiperconsolidados y estableció la meta de moderar los problemas que se detectaron en la pila de almacenamiento de EMC en un máximo de 30 días del descubrimiento. Fue un esfuerzo combinado de MCC, el servicio al cliente e ingeniería de escalación, junto con los grupos de productos VPLEX, RecoverPoint, VMAX y VNX.

MCC simuló casos de uso del almacenamiento, como el de empresas a gran escala, con la implementación de un VPLEX Metro adicional en el centro de datos. Dos VPLEX Metro, en ejecución en distintos niveles de código, compartieron los arreglos VNX y VMAX de back-end. Se ejecutaron cargas de trabajo de aplicaciones empresariales a través del ambiente virtualizado VMware, las cuales se centraron en volúmenes locales de VPLEX con un objetivo de 25,000 IOPS por motor. Este reto sobreexigió al portafolio de EMC mediante diversas operaciones de falla y degradadas, y con distintas versiones de software de VPLEX, VNX y VMAX.

A final del día 100, MCC completó correctamente 25 años de tiempo de ejecución con más de 18 NDU en VNX y 50,000 IOPS en un único motor VPLEX Metro, lo cual demostró la solidez del portafolio de EMC y de la solución.

Las actualizaciones no disruptivas de VNX a VNX OE for Block R32.217 o R32.218 pueden causar la falla de un gabinete de arreglos de discos DAE-60 (DAE7S), la falla de las unidades o una alarma en un procesador de almacenamiento de VNX Block, lo cual puede dar origen a datos inaccesibles. La causa raíz de este problema tiene relación con el tiempo que tarda la carga del nuevo CDES (código de LCC). Se están haciendo mejoras en los CDES más recientes para evitar este problema. El plan es lanzar este CDES más reciente en el service pack principal siguiente para la familia R32. Los clientes que poseen gabinetes de 60 unidades y que postergan la actualización a R32.217 o R32.218 deberán actualizar a la versión principal siguiente en la familia R32 cuando esté disponible. En el momento de la publicación de este boletín, no hay una fecha estimada para la versión del código de Block OE R32 siguiente; sin embargo, se está preparando una nueva versión de 32.218 con la reparación específica para este problema. Consulte la ETA 206342 para obtener más detalles.

EMC lanzará una FCO el 27/08/2015 para tratar los arreglos afectados. Consulte detalles en la base de conocimientos https://support.emc.com/kb/196060.