La historia es la siguiente. Una plataforma que realiza la Tasación del Tráfico de Voz Móvil en Línea, comenzó a presentar un leve aumento en los tiempos de respuesta para las transacciones de Control de Tráfico provenientes desde la Red, que son ejecutadas en tiempo real por la Plataforma, que corría sobre un par de Servidores HP rx7400, sobre HP-UX 11iv3 (11.31) y HP Service Guard para implementar un Cluster Activo-Pasivo, conectado a un Storage HP XP20000.
La utilización de CPU no superaba el 50%, pero los procesos que manejan el Control de Tráfico en Tiempo Real, son CPU-Bound, por lo cual cada proceso (12 en total) utilizaba 1 Core de manera dedicada, estaban llegando al 100% de utilización de CPU cada uno. Esto implicaba que el resto de Cores (4) fueran utilizados por el Sistema Operativo y todos los otros procesos que forman parte del Sistema. Dado que el tráfico iba en aumento, se necesitaba levantar nuevos procesos de Control de Tráfico ya que de otra manera no se podría realizar un control en linea y por lo tanto, se produciría una perdida importante de ingresos. Dado que no era factible asignar mas Cores para esta función sin generar otro tipo de Problemas en la Plataforma, se tomo la decisión de migrar todo el ambiente Operativo a una plataforma más grande con crecimiento Vertical.
El Proyecto consistió en migrar el ambiente a un HP Superdome 2 conectado a un Storage HP 3PAR 10400 (v400) de última Tecnología. De esta manera, eliminaríamos los problemas de Capacidad de la Infraestructura anterior y mejoraríamos la disponibilidad de la plataforma al movernos a un sistema de Misión Crítica High-End. En términos simples, la migración consistió en generar un Clone de la Data Productiva en el Storage XP20000, se presentó esta copia al Superdome, se levantó la copia del servidor y se instalaron los parches necesarios para poder subir el sistema en esta nueva plataforma y tener acceso al nuevo Storage. Después de realizar todas las pruebas funcionales y validar la correcta Operación del nuevo ambiente, se tomó la decisión de pasar a Producción la nueva arquitectura.
El paso a Producción se realizó sin problemas durante una ventana nocturna. Se realizaron todas las validaciones, se revisaron los distintos KPIs y finalmente se dejó en Producción. Todo estuvo operando en óptimas condiciones hasta que cerca de las 10am se reportaron problemas de lentitud en algunos procesos que extraen datos a través de FTP, junto con algunos timeout en los procesos de control de tráfico.
El problema estuvo presente por cerca de 1 hora y después desapareció "mágicamente". Dado que esta plataforma no puede tener un comportamiento errático y debido al hecho que yo había impulsado el mover el sistema hacia la Plataforma Superdome, solicité a los Ingenieros abrir ticket Urgente a Soporte HP y determinar que había ocurrido, ya que esto podría ocasionar la vuelta atrás de la migración (lo que no era una opción para mí). Cerca de las 22 hrs, recibimos feedback de HP donde nos indicaban lo siguiente:
"Revise el servidor a la hora que me indicaron y se observe contención de algunos LV (vg involucrados Vg01, vg04,vg06, vg07 y vg14) que pasaron más tiempo en espera de lo permitido. Estos filesystem están configurados con Bsize 1K. La capacidad que hoy tiene este servidor es mayor y aumenta en velocidad de los requerimientos. Estos Filesystem no usa concurrente IO y los procesos se comienzan a encadenar en algunos bloques, Aumentando espera, debido a la velocidad de requerimiento que hoy tiene el servidor, que a diferencia del servidor antiguo eran diferentes más lentos."
Se presentaba el siguiente gráfico y finalmente se acusaba un problema a nivel aplicativo, por lo que la recomendación era Modificar la estructura de los Filesystem (no era opción modificar el Block Size a 8Kbytes, ya que para esto se requería una ventana de indisponibilidad de al menos 8 hrs ya que no se puede hacer en línea) o volver atrás la aplicación.
Lo que me llamó la atención fue que todos los VGs presentaron un aumento excesivo en la Utilización de discos (%busy). Un detalle importante, es que los Discos de Sistema Operativo y SWAP también son del Storage 3PAR y tienen Block Size de 8Kbytes, por lo cual la teoría de HP de que el problema de rendimiento se debía al bsize=1Kbyte comenzaba a desmoronarse.
El paso siguiente fue determinar que había ocurrido con el acceso a los Discos del Storage en el horario indicado. Afortunadamente el utilitario sar estaba configurado y pude ver el comportamiento histórico, llegando a la siguiente conclusión:
El servidor esta utilizando 2 HBAs, pero por una de ellas se veía un pobre rendimiento, lo que afectó la performance general del sistema durante el período de tiempo con problemas. Finalmente, los Ingenieros fueron a realizar una inspección visual del Superdome y encontraron que la Fibra Optica de la HBA "problemática" no estaba bien conectada, lo cual era la causa del problema.
Por último, les dejo a continuación 5 pasos que les permitirán en HP-UX 11iv3 determinar cómo está funcionando el Subsistema de I/O y detectar si tienen algún cuello de botella.
Recuerden siempre tener %busy bajo 50 y los tiempos de servicio (svc_time o avgsvc) menores a 5msec en discos de SAN, o sino pueden estar teniendo algún grado de contención o lo tendrán en el futuro.
Pronto publicaré otro articulo de análisis de Rendimiento en HP-UX, donde se muestra que el tamaño de Bloque del Filesystem puede jugar un rol fundamental en el Performance del Sistema.
Saludos,
Rodrigo./
