Esta es una
historia de éxito donde BVQ ayudó a solucionar problemas de rendimiento en un
entorno empresarial de virtualización de Red Hat (RHEV) con almacenamiento de
IBM Storwize V7000. Este documento describe cómo el equipo de BVQ dio solución
a un problema de rendimiento en una situación específica de un cliente.
Los pasos individuales que llevaron a la solución fueron elegidos en base a este entorno específico. Estos pasos varían de acuerdo a cada situación y no pueden utilizarse en otros entornos sin antes un análisis de causa raíz.
Los pasos individuales que llevaron a la solución fueron elegidos en base a este entorno específico. Estos pasos varían de acuerdo a cada situación y no pueden utilizarse en otros entornos sin antes un análisis de causa raíz.
Contenido:
- Historia de éxito BVQ
- Rendimiento inaceptable del RHEV (Red Hat Enviroment Virtualization)
- Proyecto de optimización de rendimiento. Inicio – día 1
- Puesta en marcha del proyecto de optimización
- Paso a paso trasladando los volúmenes a descomprimir
- Resultado de la intervención: Mejora de los tiempos de respuesta
- El desempeño también se beneficia gracias a IBM Easy Tier
- Resumen del equipo de BVQ
- Resumen del cliente
Historia de éxito BVQ
Rendimiento inaceptable del RHEV (Red Hat Enviroment Virtualization)
El entorno
de Red Hat está configurado por seis volúmenes de almacenamiento con Thin
provisioning y comprimidos para optimizar la eficiencia de la capacidad.
La
eficiencia de capacidad que se logra es alta, resulta en una reducción de 16 TB
a 5 TB. La reducción del espacio con el algoritmo de compresión fue de
aproximadamente 50%! la reducción del espacio con el uso de Thin Provisioning
se dio dependiendo de la edad-periodo del volumen - entre el 50% y el 70%.
Imagen 1: El monitor del Storwize-IBM muestra muy malas latencias de volúmenes. Esto dio a la primera impresión de que el mal desempeño de RHEV fue causado por el almacenamiento. Pero este monitor no puede mostrar los detalles más útiles para resolver el problema. (Foto fue tomada después).
La situación
en el principio del proyecto fue que el rendimiento del entorno RHEV se redujo
debido a las altas latencias de los volúmenes IBM Storwize. Como resultado el
RHEV estaba funcionando por debajo de los niveles de rendimiento aceptables –
las fases que experimentaban los usuarios de largos tiempos de respuesta, que
no están necesariamente relacionadas con la carga real de trabajo del sistema.
El sistema de monitoreo de Storwize mostró muy malos tiempos de respuesta de
volúmenes. El primer paso fue eliminar este cuello de botella más obvio para
averiguar si esta era la única causa del mal rendimiento del RHEV.
El cliente ya
había experimentado una fase de análisis anterior para averiguar las causas
fundamentales en el rendimiento de los volúmenes, sin grandes alcances. El
objetivo de esta intervención con el equipo de BVQ era averiguar la razón y,
finalmente, encontrar una manera de mejorar la situación.
Todo el proyecto de optimización del rendimiento duró un poco más de una semana.
Todo el proyecto de optimización del rendimiento duró un poco más de una semana.
Proyecto de optimización de
rendimiento. Inicio – día 1
El cliente contactó al equipo de BVQ y solicitó una instalación de la licencia Demo de BVQ. Algunos mensajes habían ya sido intercambiados y se envió la licencia de demostración (Demo) de BVQ. La licencia Demo le permite al cliente instalar BVQ por sí mismo y en el mismo día. Una llamada con el equipo BVQ fue programada para el día 3.
Día 5.En este momento el equipo BVQ fue capaz de dar un
primer vistazo al entorno de
almacenamiento del cliente. El
equipo encontró que el caché del
grupo de discos que sirven al RHEV
estaban totalmente agotados, demasiado llenos. Esto dio lugar a situaciones en las que los volúmenes fueron retirados de caché
y comenzaron a responder con
muy malas latencias. Cuanto más analizaba el equipo de BVQ más clara era la evolución de la imagen que daba a conocer, que la compresión
tenía que ser la causa de las
condiciones inaceptables de trabajo en el entorno del
cliente.
Junto con el cliente se estableció un plan paso a paso para eliminar la compresión del sistema. Además se decidió activar también el mecanismo Easy Tier dentro del IBM Storwize, dado a que la carga de trabajo del sistema era alta y frecuentemente áreas Swap en los volúmenes pueden ser tratadas mejor con almacenamiento SSD.
La decisión para Easy Tier también
fue tomada debido al hecho de que para soportar la carga de trabajo por debajo de la memoria caché V7000, el cliente debía utilizar más de 50 discos
para ofrecer el rendimiento necesario.
Con Easy Tier, el equipo BVQ vio viable la probabilidad
de que los SSD puedan manejar una gran cantidad de la alta
frecuencia en la carga de trabajo
Swap y el número de discos necesarios
podría reducirse. La decisión de
utilizar Easy Tier nos guiaba de
nuevo a la necesidad de cambiar de
compresión, ya que, Easy Tier no optimiza las
escrituras en volúmenes
comprimidos en el código V7.1.0.3 de Storwize.
- Día 7 a día 10: La compresión se ha sustituido paso a paso utilizando la copia de volúmenes y añadiendo la herramienta Easy Tier de administración de discos.
- A primeras horas del día 10 (por la mañana) se había completado el proyecto.
Inicio del Proyecto de Optimización
Los
usuarios de RHEV estaban
experimentando demasiadas latencias
independientemente de si las cargas de trabajo eran altas o
bajas. Esto se reflejó en las
mediciones al supervisar IOPS con respecto a la
latencia de los discos RHEV.
Imagen 2: Estos gráficos muestran las altas latencias (rojo)
los momentos en que la Red Hat Enterprise Virtualization (RHEV)
accede al sistema Storwize. La carga de trabajo es alta, con más de 3.500 IOPS
(verde), que son en su mayoría escrituras IOPS en esta
situación específica del cliente. La latencia máxima (rojo)
medida fue de 575 ms el día 5
Analizando la
carga de trabajo, se hacer notar que los volúmenes RHEV están
haciendo muchas más escrituras
que lecturas. La
eficiencia del caché Storwize
en este entorno es alta para lectura y
escritura, pero, la disponibilidad
del caché no es estable. Los tamaños de transferencia son muy diferentes y pueden cambiar en cada momento. En las
fases de tamaños más altos de
transferencia de escritura (mayor
índice de datos) más datos se transfieren del RHEV al Storwize que a
menudo causa un colapso del caché
debido a un exceso de memoria caché requerida para este proceso.
Imagen
3: Esta imagen muestra una
reacción típica de los MDG (Managed disk group) situación "uso máximo de
la capacidad del caché". El MDG caché (imagen superior) está totalmente utilizado
y ahora comenzará a
recuperarse. La capacidad de la memoria caché, que pertenece a este volumen (imagen inferior), se
reducirá a 0. Ahora el
volumen no posee caché de escritura y el
tiempo de respuesta (rojo) explota desde
menos de 1 ms hasta 60
ms durante más de una hora. En
medio de la situación descubrimos un período
de tiempo corto (en líneas discontinuas amarillas) donde
el sistema fue capaz de reducir la
cantidad de caché mínimo, claramente por
debajo del 80%. Esta fue la primera vez, que
los volumen recibieron algo de memoria caché para
su funcionamiento.
Observando la partición de los grupos de caché de disco manejados, se hizo evidente que la memoria caché estaba completamente llena y en exceso. Una razón para esto podía ser que Storwize con el código 7.x está utilizando la memoria caché para calcular la compresión. Un indicador adicional de esto es que el indicador de la cantidad de caché Mínimo, nunca fue por debajo de un cierto nivel (en este caso 55%). Con la compresión, este nivel de cantidad mínimo de caché podría trasladarse a un valor más alto y por lo tanto menos caché estaría disponible para las operaciones. Esto pone en relieve la situación que el caché máximo estaba antes alcanzando el punto de desbordamiento de memoria.
Algo que no podíamos medir aún en ese momento con el código de BVQ era el poder real de CPU necesario para la compresión. Este estaría disponible con la versión BVQ 3.0.
Imagen 4: La memoria caché del grupo de discos administrados está completamente llena. La totalidad de la memoria caché máxima está en 100%
o incluso mayor por lapsos de tiempo muy
largos. Lo que es peor, es que
nunca se recupera. Es muy típico en compresiones que el porcentaje
de la memoria caché Mínima
nunca este por debajo de un cierto
límite. Lo cual necesita ser comprobado antes de que uno puede decir que este es un problema con una causa fundamental en la compresión.
Paso
a paso trasladando los volúmenes a descomprimir
Con un poco de
espacio de almacenamiento adicional era
fácil utilizar la operación espejo
de los volúmenes, creando así copias
sin comprimir de los mismos. En nuestro
caso tuvimos una buena condición, ya que cierta capacidad adicional estaba disponibles para las operaciones de copia.
Imagen 5: La única manera de desactivar la compresión es crear una copia sin
comprimir del volumen. Posteriormente
es suficiente con eliminar la parte comprimida del espejo.
Esto nos ha permitido
crear una nueva administración de
grupo de discos siendo punto
clave para las operaciones
de copia. De cualquier manera hay
que tener cuidado cuando se
descomprimen los volúmenes. Se necesita de más capacidad con volúmenes sin comprimir. Se utilizaron las hojas de propiedades
de BVQ para obtener cifras exactas de la capacidad adicional necesaria para los volúmenes sin
comprimir. (Pict.6)
Después del inicio de la operación de
copia (Pict.5) el sistema mostró un tiempo de sincronización
estimado de más de 500 horas! Este número se
veía aterrador al principio, pero
mejoró muy poco después de iniciar el proceso.
Imagen 6: Las propiedades de BVQ proporcionan una
buena conjetura respecto de la capacidad necesaria para mover un volumen de comprimido ha descomprimido.
En este caso el volumen de 4 TB esta comprimido y con thin provisioner, necesitando un total de 721GB de capacidad. Después
de la descompresión de este volumen
de necesitará 1.16TB de capacidad de almacenamiento.
Para
acelerar aún más la operación de copia,
aumentamos la velocidad de sincronización espejo a 100, lo que no era un problema en esta situación ya que el almacenamiento es menos utilizado en fines de semana (tiempo en el que se hizo las descompresión de los
volumenes).
Al final, la copia
de un volumen necesitaba cinco a ocho horas.
En esta situación específica decidimos descomprimir todos los volúmenes. La base de esta decisión fue que teníamos suficiente espacio de almacenamiento disponible y todos los volúmenes estaban diseñados para proporcionar el mismo rendimiento. RHEV estaba utilizando estos volúmenes como un stripe-set, lo que destacó aún más esta decisión. En otras situaciones sólo se decide descomprimir algunos volúmenes en función de su rendimiento y el consumo de memoria caché. Uno puede ahorrar una gran cantidad de capacidad (y dinero) con un análisis adecuado antes de iniciar este proceso.
Resultado de la intervención: Mejora de los tiempos de respuesta
Las siguientes dos imagines muestran la diferencia (antes y después del proceso) en el rendimiento del sistema. Fueron tomadas con exactamente una semana de diferencia.
Imagen7: Día 5 - antes de que se inició la
optimización. Las peores medidas
de latencias encontradas en los volúmenes del RHEV,
fueron de 575 ms como valor medio. Esto significa
mucha más latencia en los otros 5
volúmenes. Las latencias
son muy dependientes de los tamaños de
transferencia de volumen, lo que
es una buena prueba para decir que es un
problema de desbordamiento de memoria
caché. (Índices mayores de datos conducen
a desbordamiento de memoria cache)
Imagen 8: Día 12 después de terminada la primera fase de optimización (el reequilibrio del grupo de mdisk todavía se estaba ejecutando en este momento). Las peores latencias en volumen medidas son de 1,5 ms y 2,5 ms. La escala para la latencia y IOPS son las mismas en la imagen 7 y 8.
El desempeño también se beneficia gracias a IBM Easy Tier
Las siguientes dos imágenes muestran la contribución de los dos mdisks SSD de 200GB a la gestión de la administración de los grupos de discos.
Imagen 9:
Cuando comparamos la totalidad de IOPS backend
con la IOPS de
los SSDs, nos
encontramos con que los SSDs
se hicieron cargo de casi la mitad de
la IOPS realizada. Este es un buen resultado cuando se tiene en cuenta que la mayoría de la IOPS son IOPS de escritura. En
otros casos, que se orienta más a
lectura, el efecto de Easy Tier puede
ser mucho más alto.
Imagen10: Cuando comparamos el tiempo de respuesta medio de los MDG con el tiempo de respuesta de las unidades individuales de SAS nos damos cuenta que Easy Tier mejora la latencia de los MDG de 14,11 ms a 7,89ms.
En
este caso, la mejora del rendimiento
gracias a Easy Tier es prácticamente la reducción de los discos
necesarios para lograr el mismo
rendimiento. Cuando calculamos la
necesidad de ejecutar 2000
IOPS en el
almacenamiento backend, necesitaríamos 41 discos de 10k. Con
Easy Tier los SSDs cubren casi el 50%
de esta carga. En otras palabras, sólo teníamos que planificar el backend con 1000 IOPS para las unidades SAS,
que se pueden manejar con 20 ejes, lo cual es más de un 50% menos de la capacidad requerida.
Resumen
del equipo de BVQ
Fue un gran placer trabajar con este cliente - hemos aprendido mucho de estas condiciones de trabajo y vamos a por seguro agregar algunos de los nuevos aspectos en nuestro software. Una gran ventaja era que podíamos ayudar al cliente en los pasos individuales y ver las mejoras.
Resumen
del cliente
Habíamos estado buscando durante unos meses en la página de rendimiento y los mapas de calor del V7000, tratando de averiguar cuál era la causa de nuestros problemas de rendimiento, analizábamos cada uno de los volúmenes del V7000. Contactamos el equipo de BVQ para ver si su herramienta podría ayudarnos a identificar los problemas. Lo que obtuvimos fue el contacto con un equipo que sabía exactamente qué buscar y dónde encontrarlo. Nos dieron una visión más clara de nuestra plataforma durante un recorrido de dos horas que la que hemos tenido desde que incorporamos el equipo V7000. Trabajamos a través de llamadas telefónicas y sesiones de acceso remoto, estamos seguros que nuestro V7000 está trabajando en la mejor de sus condiciones, agregando también que tenemos un entorno con requisitos particulares.
Si usted tiene o está pensando en implementar un equipo V7000, debería considerar seriamente la implementación de BVQ junto a él!
Eamon, Arquitecto TI.
Clic aquí para conocer más sobre el proceso de descarga
Deja un comentario sobre el problema que tienes con
tu red de almacenamiento, permite que otros usuarios te brinden soporte técnico
a la vez que nuestros expertos en BVQ.
Contáctanos,
1 comentario:
El hosting web compartido es el tipo de servicio en el que se comparten los recursos tanto de software como de hardware de un servidor.
Publicar un comentario