Splunk + Gluster en el Red Hat Summit 2015

La semana pasada asistí al Red Hat Summit 2015 en Boston, MA.

No tenía muchas expectativas con esta Conferencia, dado que pensaba que sólo iba a ver temas relacionados con Red Hat Enterprise Virtualization (RHEV, que no ha podido posicionarse en el mercado), OpenStack (la misma gente de Red Hat indica que aún es temprano para pensar en llevarlo a ambientes Productivos) y OpenShift (aún lejano).

Grande fue mi sorpresa cuando escuché acerca de Linux Atomic Containers y Docker (mas info AQUI). Yo trabaje mucho con los containers en Solaris y los utilicé para consolidar varias plataformas antiguas, que corrían sobre versiones antiguas de Solaris en HW obsoleto y que no podían ser movidas a nuevo Hardware por el alto costo de la modificación del Aplicativo para hacerlo compatible con las nuevas versiones de Solaris (hay un par de post en el Blog respecto a esto). Ahora esta tecnología está disponible en Linux y con Docker veo que la solución es mucho más poderosa que en Solaris. En los próximos meses voy a trabajar con Red Hat y nuestro proveedor ITQ Latam para implementar una PoC (Proof of Concept) sobre Containers/Docker, para consolidar antiguos aplicativos en nuevos servidores con RHEL7, de tal forma de liberar espacio físico, Energía Eléctrica y diminuir OPEX.

Después de asistir a varias sesiones de Red Hat Atomic Containers, asistí a otras sesiones de Big Data & Analytics. Lo primero a rescatar es el siguiente diagrama de una presentación de Cisco:

Varias personas me preguntaban si nosotros teníamos algún Big Data y cuando yo les decía que utilizaba Splunk, me miraban extrañados y me preguntaban por Hadoop. En este diagrama se explica la diferencia entre las diferentes herramientas existentes para el mundo de Big Data.

Hadoop y repositorios NoSQL se utilizan para almacenar grandes volumenes de Datos Históricos (normalmente Petabytes hacia arriba). Estas herramientas son eficientes en el almacenamiento, pero no son buenas para manipular, correlacionar y generar Dashboards que permitan generar información de valor al negocio. Por otro lado, Splunk (y las otras) es una herramienta de Analytics (monitoreo y gestión de datos en línea o near real-time), Business Inteligence y Operational Intelligence (transformar los datos de máquinas o logs en información que genere valor al negocio). Splunk tiene una herramienta llamada Hunk, que permite las mismas funcionalidades (y más) de Splunk pero tomando los datos desde un Hadoop o NoSQL.

Pero las sesiones que más me llamaron la atención fueron aquellas donde se hablaba de Big Data, Analytics y la herramienta utilizada era Splunk. Esto quiere decir que nuestra decisión de embarcarnos con esta herramienta fue la correcta, dado que se está utilizando fuerte a nivel mundial y es uno de los referentes en el mundo de Inteligencia Operacional.

Lo otro interesante fue ver la experiencia de SaskTel, una empresa de Telecomunicaciones de Canadá, que utiliza Splunk y dado el crecimiento explosivo de los datos almacenados y a la gran cantidad de usuarios internos, tuvieron que implementar una solución basada en Gluster (Red Hat Storage), para asegurar la disponibilidad, capacidad y crecimiento de la plataforma.

A continuación les dejo 2 links con las presentaciones de Splunk y Gluster:

1) Experiencia SaskTel

2) Red Hat Gluster Storage as a hybrid storage solution for Splunk Enterprise

Saludos,

Rodrigo./

Detectando problemas de I/O en HP-UX

Voy a hacer un paréntesis y publicaré un artículo sobre análisis de Rendimiento en plataformas de Misión Crítica HP-UX, ya que es difícil encontrar información en la Red y a los que alguna vez nos ha tocado administrar este tipo de plataformas, sabemos lo doloroso que puede llegar a convertirse.

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./

De vuelta al Blog

Han pasado más de 7 años desde el último post y los cambios tecnológicos que han ocurrido durante este tiempo, junto con mi evolución profesional, han hecho que vuelva a utilizar esta plataforma para compartir tips que a más de alguno van a ayudar. Después de todo, de eso se trata Internet, o no?.

Comencé utilizando el Blog como una especie de bitácora online, para tener información que en ese momento era importante para el trabajo que estaba haciendo y que necesitaba poder tener accesible desde cualquier lado. Además, ponía a disposición de otras personas información que era difícil encontrar en manuales o en otros sitios de internet. 

Hoy, el problema de acceso a información en todo momento y sin importar la ubicación, lo tengo resuelto con dropbox, evernote y mi teléfono. 

Respecto al trabajo, desde el 2007 a la fecha pasaron muchos cambios y se presentaron muchas oportunidades, donde tuve distintos cargos de jefatura en áreas de Operaciones TI, que me llevaron a cambiarme de trabajo el año 2010 al Operador Móvil Lider de Chile. Aquí tuve que poner en práctica todo lo que había aprendido en Movistar y después de 5 años en esta empresa, de una fusión de compañías, de un par de reestructuraciones y de un proceso constante de aprendizaje, ha llegado el momento de volver a compartir experiencias que puedan ser de utilidad para los que están buscando nuevos desafíos en el liderazgo de equipos en ambientes exigentes y competitivos.

Saludos,

Rodrigo./

Solaris 8 dentro de un Container de Solaris 10?

Googleando encontré una página donde se mostraba como utilizar S8MA (Solaris 8 Migration Assistant), el cual permite levantar un ambiente Solaris 8 dentro de un container de Solaris 10.

Esto no se podía hacer con las primeras versiones de Solaris Container, pero como se ve, está evolucionando y esto es demasiado útil, ya que existen muchos sistemas que corren en Solaris 8 que es demasiado caro migrarlos a Solaris 10, no porque sea difícil o caro instalar Solaris 10, sino porque las aplicaciones que corren en Solaris 8 no son compatibles y no están certificadas para Solaris 10 y los fabricantes del Software cobran un ojo de la cara para "hacerlas migrables".

Lo malo parece es que hay que pagar por las licencias de S8MA (estoy averiguando con Sun y cuando tenga más información actualizaré el post).

El web donde sale el ejemplo de S8MA es el siguiente:
http://solaris.reys.net/english/2007/11/solaris-8-migration-assitant

Más información en el sitio de Sun:
http://www.sun.com/download/products.xml?id=470c4a45

Saludos,
ChaZcaZ./

Unix Administratosphere

Link que encontré googleando donde aparecen Tips y News de varios Sabores de UNIX:

http://administratosphere.wordpress.com/

ChaZcaZ./

HP-UX: Mover discos entre 2 máquinas

Esto fue un ejercicio que hicimos en un Workshop de HP que asistí en Marzo del 2007 en Houston, Texas. El instructor fue Matias Vidal, Argentino que trabaja en una empresa partner de HP.

La configuración que utilizamos era un Superdome, en la cual teniamos 2 NPAR (2 servidores) conectadas a un Storage EVA5000.

Se creó una Lun en el EVA y se presentó a la npar1. Se creó un vgPrueba (Volume Group) y un Lvol (Logical Volume) dentro. Se montó (obviamente se creó un filesystem en el Lvol antes de montarlo) y se copió la data del directorio /etc en él. Después, se deportó y se presentó la Lun a la npar2. Se hizo un import del grupo, se activó y se montó. Esto fue lo que se hizo:

En Npar1
strings /etc/lvmtab # para ver como está actualmente
ll /dev/vgPrueba # con esto se saca la configuración y se ve el group, para
# llevar un orden y “tratar” de utilizar el mismo minor en el
# otro lado, si es posible.
umount /mnt # se desmonta el Lvol
vgchange –a n vgPrueba # Se desactivan los lvol y el vg
vgexport –s –m /tmp/vgPrueba.map vgPrueba # Se exporta el vgPrueba y se guarda la
# configuración en el archivo vgPrueba.map, el cual se debe
# traspasar a npar2.

En Npar2
Se presenta la Lun a través de Eva, se ejecuta ioscan y después insf.
mkdir /dev/vgPrueba
ll /dev/*/group # Se busca un Minor number disponible (suponemos el 0x030000)
mknod /dev/vgPrueba/group c 64 0x030000 #
vgimport –s –m /tmp/vgPrueba.map vgPrueba
vgchange –a y vgPrueba
mount /dev/vgPrueba/lvol01 /mnt

Eso es todo!.

Para más información, ver página 584 (Moving Disks Across Systems
) de “Managing Systems and Workgroups_ A Guide for HP-UX System Administrators.pdf” (http://www.docs.hp.com/en/B2355-90950/index.html)

Saludos,
ChaZcaZ./

A retomar las clases de Saxo!

Aún estoy de vacaciones, pero acabo de hablar con Marcos Aldana (mi profesor de saxo) y le conté que voy a retomar las clases cuando vuelva a Santiago (en realidad, después del viaje a Houston).

Marcos es seco y la hija (Melissa) es más seca aún (http://www.revistafibra.cl/gruesa/nro30/pdf/Melissa_Aldana.pdf). Espero poder aprender mucho en este regreso y ojalá que pueda continuar un buen tiempo.

Saludos,
ChaZcaZ./