Las soluciones IT completas y un ejemplo con infraestructura virtual vSphere

En este artículo cuento cómo en gral. las soluciones "completas" no lo son, y hay que completarlas para que realmente cumplan con el objetivo para el cual fueron pensadas. Hay además comentarios sobre los ámbitos de responsabilidad de provedores IT terceros y la relación de los proveedores IT internos de una organización con su cliente principal (la organización).


Soluciones buenas, pero parciales
Es común ver en infraestructura que al comprar una solución IT, la empresa acuerda el trabajo a realizar, viene a la empresa/organización, realiza el trabajo y luego se va. Dejando garantías vigentes, por un tiempo, bajo ciertas condiciones, etc.

Por ejemplo, la instalación de una infraestructura vSphere: se instalan los hipervisores, se monta el server vCenter, se agrega los hipervisores al vCenter, se deploya algunas máquinas virtuales - probablemente no?, y listo (hasta ahí es el trabajo acordado con el proveedor de servicios IT en este ejemplo). El cliente luego toma la posta desde ahí, administrando todo la infraestructura - virtual ahora. Instalando, migrando sistemas operativos de físico a virtual, etc. etc.

El precio de un trabajo puntual de infraestructura y sus límites son indispensables, sino la empresa proveedora va a hacerse cargo hasta el infinito de cualquier cuestión relacionada con lo que instaló/configuró inicialmente.


Soluciones IT completas
Ahora, el caso de las áreas de sistemas internas en la organización es bien diferente. Cada área IT interna en una organización tiene la obligación de sostener la continuidad de la infraestructura en el tiempo, a largo plazo. 

Lo que es muy diferente de la obligación de proveedor IT comercial, sin embargo es común encontrar el caso de que las soluciones IT internas en una organización se implementan "por única vez", y luego se las abandona "como están" y sin tomar en cuenta la prerrogativa de mantenimiento y mejora contínua (que es en gral. un requerimiento del puesto para los empleados del área IT interna por cierto).

Siguiendo el ejemplo de la infraestructura vSphere, algunos pasos posteriores a la "simple" instalación y configuración de una infra virtual vSphere podrían ser (más o menos en orden de importancia estratégica-técnica): 

1) Implementar backup automatizado de la configuración del vCenter (y su DB de backend)

2) Implementar backup automatizado de la configuración de los ESXi,

3) Deployar (comprar en gral.) una solución de backup virtual (Veem, etc.), para las máquinas virtuales en sí,

4) Implementar chequeo de configuraciones automatizado (extraer toda la configuración de vSphere, volcar a un GIT o similar, y luego ir haciendolo regularmente, para tener un registro centralizado exacto de cada cambio en la configuración), AKA "configuration management".

5) Implementar monitoreo de la infraestructura virtual (hay varias maneras)

6) Deployar un vSphere Update Manager (para mantener todos los hipervisores actualizados/parcheados), 

7) Implementar alta disponibilidad para vCenter (o sea, montar otro server vCenter, de alguna de las varias maneras posibles),

8) Implementar automatización en el mantenimiento necesario para vCenter (tip: la DB de backend necesita atención de a ratos).

9) Cómo proceder, y qué hacer exactamente desde lo técnico para recuperar la caída/cuelgue/fuera de servicio de cualquier componente de la infraestructura virtual vSphere (incluye tener instaladas y configuradas las herramientas necesarias, los planes, y que los que vayan a haber la recuperación, hayan realizado prácticas y pruebas de campo para saber que toda las políticas/procedimientos/herramientas funcionan realmente como deberían).

Etc.


Si se fijan, extrapolando la idea general del ejemplo, cualquier infraestructura necesita básicamente (además de la instalación, configuración y puesta en producción inicial): 

- Backup, 
- Configuration Management, 
- Monitoreo y Optimización/Mantenimiento/Mejora Contínua.
- Añadir redundancia/resiliencia adicional (como parte de la mejora contínua)
- Plan de acción de recuperación de desastres.

Sin todos esos detalles (y varios más no mencionados), la solución puede "estrellarse" con mucha facilidad y dejar de funcionar apropiadamente, y con algo de mala suerte además, inesperadamente (por ejemplo: madrugada de año nuevo, 3 de la mañana, llamada del dueño de la empresa al personal IT, cayendo a las 3.10 cuando el personal que usa el sistema le acaba de avisar de que no anda. "Casos de uso": clínica de guardia, farmacia de guardia, empresa de seguridad, polícia, etc.).


Completar la solución
Si una solución integral no incluye lo anterior, habría que ir preguntando al proveedor cuanto saldría implementar backup, config management, monitoreo, y disaster recovery...o pensar cómo se hace internamente para completar la solución de infraestructura. Normalmente esas tareas tercerizadas implica un precio mayor que la instalación/configuración inicial, ese precio más alto es realmente una mejor aproximación al TCO real de la solución.

TCO:
http://es.wikipedia.org/wiki/Coste_total_de_propiedad

* Esto es cuestión de opiniones, pero para completar más el TCO de la solución, se podría agregar la previsión/estimación de costos futuros del lifecycle management, por ejemplo, previendo una migración de plataforma. 

Siguiendo el ejemplo: preveer un posible/eventual path de migración de Vmware vSphere 5.1 (+ ESXi) hacia Microsoft Hyper-V 2012 + System Center 2012 Virtual Machine Manager .

Por ejemplo: tener que comprar una SAN "ahora":
- aumenta el TCO de la solución vSphere, pero 
- baja el TCO de la - posible a futuro - solución Hiper-V 2012, pero, 
- en gral. hace disminuir el TCO de la solución "Infraestructura Virtual" 
(que es lo que le interesa a la organización en realidad), y por lo tanto genera un "path de migración" aceptable, y se concluye que comprar la SAN "estaría bueno" :-)


Ambitos y tiempos limitados
Las áreas IT internas tienen un ámbito de injerencia y obligaciones para con la infraestructura IT por lejos mucho mayor que casi cualquier solución "llave en mano" que pueda proveer un tercero, ya que inclusive con el mejor presupuesto disponible, el ámbito de injerencia de un proveedor IT tercerizado siempre - pero siempre - está limitado a determinadas tareas y obligaciones, y a un rango de tiempo - contratado - durante el cual le va a responder al cliente. Y luego del cual, ya no va a tener obligación de responderle al cliente. 

El área IT interna por otra parte no está limitada en absoluto de sus obligaciones para con la organización, a la que debe responder por obligación organizacional (o sea, independientemente de quién/es estén integrando esa área como empleados/responsables), de modo contínuo, y tiene la responsabilidad de completar y subsanar cualquier limitación que exista en la infraestructura. 

Siguiendo el ejemplo: el que en la solucion "llave en mano" no haya previsto un mecanismo de backup para los hipervisores ESXi. Si no lo hace el proveedor, es obligación del área IT interna completar la solución.


La obligación contractual del proveedor IT, siempre tiene un límite práctico: el tiempo máximo contratado y qué tanto trabajo se puede hacer durante ese tiempo. Aunque y a pesar de que se suele contratar: 
- "soluciones completas", 
- "soluciones llave en mano", 
- "soluciones integrales", 

y demás buena jerga de vendedor IT, por más que esté "prometido" las soluciones provistas por un tercero nunca van a poder ser integralmente completas, sino solamente van a estar de acuerdo a lo contratado (una lista de tareas que figura en el contrato), cualquier tarea adicional, paga o no, es a discreción y buena voluntad del tercero proveedor. 

...A menos que directamente se los contrate permanentemente para hacer el trabajo del área interna IT...ooops, pero ese contrato también tiene una duración máxima, así que no, no es posible sostener la tercerización ilimitada, siempre va a haber que pagar más o contratar servicios adicionales para poder tener una tercerización ilimitada (por eso es tan buen negocio por cierto :-).


Conclusión
Es bastante seguro decir, falta de presupuestos infinitos mediante, que eventualmente toda organización/empresa se va a volver a hacer cargo de sus propias necesidades de informatización, y lo mejor es que sea lo antes posible y con el mejor grado de previsión y responsabilidad.

Administración de sistemas con Midnight Commander

El Norton Commander
http://en.wikipedia.org/wiki/Norton_Commander

Hacia 1988 estaba dando mis primeros pasos en IT, y había un pequeño team de proto-administradores con los que nos pasábamos todo el día desformateando diskettes (para ver qué tenían que los profes no querían que viéramos!), luego de un tiempo empezamos a necesitar desfragmentar y editar los filesystem a nivel de bloque, y descubrimos unas herramientas tremendas, las Norton Utilities. Así nos enteramos que existía el nc (Norton Commander, la evolución del primitivo "NCD" Norton Change Directory), resulta que los profes usaban usaban esta herramienta asiduamente (todos teníamos la misma pregunta "¿qué herramienta DOS permite que la cierres apretando una sola tecla?", la tecla era F10 por cierto), y no nos querían contar cual era, la cerraban rápido cuando aparecían los alumnos y no podíamos ver cual era, nos decían algo como "no les va a servir, es muy avanzada". En fin. Sí que servía, en vez de tener que estar tipeando comandos DOS, con nc podíamos simplemente teclear una o dos veces y realizar tareas 
habituales de adm. de archivos, pero a una velocidad mucho mayor.


El administrador de archivos Midnight Commander (mc) 
mc es básicamente una copia fiel del viejo nc de DOS pero para Linux, con características avanzadas y tuneadas al año 2000 (y no más allá de esos años, no se preocupen, no hace falta más).

Avance rápido a 1999, empecé a usar Linux de corrido por fin (luego de estar tonteando desde el 96'), ya podía hacer la mayoría de las cosas de las que hacía en Win98, pero me faltaba una herramienta como el Explorador de Archivos, rápida, efectiva; no había nada así de bueno y gráfico en Linux todavía, así que me puse a ver esta herramienta modo texto, mc, que ya conocía, pero no le había prestado atención:

http://es.wikipedia.org/wiki/Midnight_Commander
http://www.atareao.es/ubuntu/software-para-tu-ubuntu/midnight-commander-un-gestor-de-dos-paneles-para-el-terminal/

Me resultaba un tanto shockeante estar en la consola y estar usando una herramienta gráfica (creo que mc era la única que conocía, todavía había muy pocas herramientas usando Ncurses - http://es.wikipedia.org/wiki/Ncurses ).


Arma secreta nro. 1: mc para sysadmins
Mc es ciertamente una herramienta top level para mi workflow como sysadmin. Cuando la descubrí, empecé a utilizarla principalmente para ahorrarme el tener que aprenderme uno o dos comandos (find, ln, chown y chmod recursivos), cuando estaba apurado tratando de "activar" mi placa de sonido.

mc no tuvo un equivalente en modo gráfico hasta muchos años después, con la aparición de Krusader (www.krusader.org), que fue el primer adm. de archivos que podía replicar exactamente el workflow usual dentro de mc (y por ende su utilidad).


Más allá de las obvias ventajas, hace unos años atrás noté que algunos sysadmins en Corrientes dejaban de "mostrar" mc durante las charlas en eventos, o cuando me estaban mostrando algo en algun Linux, directamente no lo usaban, ni sabían que existía en gral. Es insufrible (y muy antiproductivo), esperar durante una charla por ejemplo, que cualquiera tipee "a mano" su camino con el comando "cd" entre, por ej. /var/www/sitio/imagenes, luego a /var/www/cgi-bin, luego a /etc/apache2, luego de vuelta a /var/www/sitio, y cometiendo 5 errores de tipeo en el camino (al final los tipos terminaban abriendo una interfaz gráfica, abrían luego 5 consolas, y se metía a cada directorio que iban a usar). En mc podés tener dos directorios abiertos, uno en cada panel, y usar dos (2) teclas para llegar rápidamente a cualquier directorio, sin necesidad de levantar los dedos de las teclas < y >.


De hecho tuve varios conocidos y compañeros de trabajo que eran sysadmins con un año o dos de experiencia de trabajo real, y no conocían mc. El origen de este issue parece ser el que estas personas se habían iniciado como sysadmins con algunos cursos, principalmente basados en Ubuntu, y en esos cursos nadie les mostró que existía mc (ni idea del por qué). Los mismos sysadmins novatos, al no estar familiarizados con el ambiente de administración (www.planetsysadmin.com por ejemplo), ni siquiera tenían idea de que existiera algo tan útil como mc.

En realidad, un sysadmin experimentado puede replicar parte de la funcionalidad de mc, e inclusive tener la misma velocidad al trabajar con archivos (al trabajar, pero NO al tener que moverse y explorar directorios continuamente). En cambio, para los sysadmins novatos mc es una facilidad que no deberían dejar de aprovechar, ya que normalmente están a años de poder trabajar con la misma precisión y velocidad que les brinda mc desde la interfaz gráfica modo texto.


Hay varios motivos por los cuales uso mc para administrar sistemas:

- Bajar la tendencia a errores humanos accidentales (solamente por esto vale la pena usar un file manager gráfico en consola),

- Velocidad de navegación por los filesystems, usando una característica bastante esotérica de activar: "navegación en modo lynx", básicamente podés navegar el filesystem usando solamente las teclas de flechas < y >, y así "subir" y "bajar" por el arbol de directorios, muy rápido (es 100% imposible moverse en consola tan rápido con el comando cd, como uno se puede mover con el modo lynx en mc, no importa si tenés 1 año o 10 años de administrador de sistemas),

El modo de navegación lynx no estuvo activado por default en ningun mc que haya instalado desde 1999 en adelante, lo tenés que configurar, según la versión de mc: 

(en versiones viejas, la instalan Debian/Ubuntu) F9 > Configuracion > y en la ventana "Configuración" tildar - con la barra espaciadora - "Navegación al estilo Lynx"

(en versiones nuevas, la instalan Fedora/Opensuse) F9 > Paneles > y en la ventana "Opciones de los paneles" tildar - con la barra espaciadora - "Navegación al estilo Lynx"

[* tip: activen el "drop-down menu", así al apretar F9 los menúes aparecen sin necesidad de hacer F9 y luego flecha abajo ]

- Awareness: sin necesidad de estar corriendo "pwd" y "ls" cada dos o tres comandos "cd", en todo momento sé, sin duda alguna en qué directorio estoy ubicado y qué archivos y directorios existen allí (no necesito tampoco correr ls -la para ver permisos, fechas, y propietarios de los archivos, en mc los tengo a la vista todo el tiempo),

- Velocidad y facilidad de administración (por ej. si tengo que elegir 14 archivos de entre 35 para moverlos de un directorio a otro: me sitúo en el directorio origen, tab, me situo en el directorio destino, tab, vuelvo al directorio origen, y con la tecla INS selecciono los archivos que quiero mover; 14 de 35 no parece mucho? Si tengo que mover 200 archivos de entre 400, es un trabajo de 10 minutos, incluso si los nombres no son secuencias - tipo file1,file2,file3, etc.)


- mc te permite tener el filesystem local en un panel, y en el otro podés conectarte a otro linux (vía SSH, FTP) o Windows (Samba). Así que las tareas de adm. de archivos remotos se facilitan y aceleran de modo exponencial. 

Respecto a esto último ví varias veces como sysadmins ya con un par de años de experiencia montando LAMPs y cosas similares, se logueaban vía SSH a un server remoto y se ponían a configurar un server FTP para poder copiar archivos a ese server desde un cliente FTP gráfico (porque tenían que trabajar con un par de centenares de files y sin nombre contigûos). Se sorprendían al ver que luego de un "apt-get install mc", podíamos directamente usar mc para conectarnos al server vía SSH y elegir a mano los files en el server de origen y copiarlos fácilmente al server destino (mc brinda la clásica barrita de progreso, y tiene facilidades extendidas, ya que cuando mc encuentra un file con el mismo nombre en el directorio de destino da opciones, y luego continúa con las tareas en ejecución, lo mismo si encuentra algun problema de acceso y no puede escribir/leer algun file/directorio).


Para tareas habituales y avanzadas de adm. de archivos en Linux y desde una consola, básicamente no encontré una manera más rápida, efectiva y segura de hacer muchas (un montón) tareas en poco tiempo y con alta precisión (más aún cuando trabajo con centenares a miles de archivos y tengo que copiarlos/moverlos).

En Debian/Ubuntu

apt-get install mc

En Fedora / Red Hat

yum install mc

En Opensuse:

zypper in mc


Arma secreta nro. 2: mcedit

En una consola tipear "mcedit", apretar F9, y acceden al menú de este editor de texto. Viendo lo que se puede hacer, se pueden imaginar la utilidad de este editor y su facilidad de uso.

Un plus tremendo de mc, es su editor de texto, mcedit. Disponible típicamente haciendo F4 (Editar), sobre un archivo. Tenemos resaltado de sintaxis para Bash cuando codeamos scripts, copiar/pegar texto (se banca muy bien el workflow de: "copiar texto en Windows (desde un notepad)" > "pegar en un archivo abierto en mcedit con la tecla INS"). Y muchas cosas más.

El otro día estaba trabajando con Nano, y un log me indicaba que tenía que editar desde la línea 39 hasta la 54 de un archivo de configuración. Nano no tiene feedback visual de en qué linea estoy ubicado, mcedit sí la tiene (arriba, se ve la cant. de líneas del file, y la línea actual, que cambia si subimos o bajamos por el file), cambié a mcedit hice ALT+l, escribí el nro. de línea 39, salté ahí, luego ALT+l, escribí 54 y ya ví todo el bloque de texto a editar (luego hice F3 y - sin tener que alejar el dedo de F3 - marqué el bloque con las teclas de flechas, F3 de vuelta y terminé de marcar el bloque, luego con F8 lo borré).

En realidad si sabés usar bien Nano, más o menos tenés casi todo lo básico (entrar, editar, guardar y salir), y un poco más (CTRL+g), que también tiene mcedit.

Pero en mcedit tenés feedback visual (eleva el awareness y baja la tendencia a errores humanos) - en Nano no tenés feedback visual directamente - , resaltado de sintaxis para un par de lenguajes (se puede desactivar/activar desde la GUI), nros. de línea a la izq. de cada línea, líneas actuales en la barra superior, menues visuales sin necesidad de recordar/revisar a cada rato los atajos de teclado, etc. 

Es un misterio para mi por qué los cursos para sysadmins novatos enseñan Nano (como editor fácil de usar, pero tenés que memorizar muchos shortcuts), y no enseñan mcedit (tenés un menú gráfico a mano, ahí están las opciones y herramientas del editor, y si te gustan los shortcuts, tambien los tenés a la vista), incluso aunque a veces enseñen algo de uso de mc.

Siempre recomiendo mcedit por sobre Nano, más allá de que mcedit tiene más funcionalidad que Nano, me parece un buen equilibrio entre Nano (editor básico), y vi (editor avanzado). Deberías probarlo y ver.


En Ubuntu, Nano viene como editor por defecto, podeś cambiar a mcedit (luego de instalar mc), con:

sudo update-alternatives --config editor


Links:

Midnight Commander / MC Tutorial
http://www.trembath.co.za/mctutorial.html

Resolución proactiva de problemas

El trabajo de administrar sistemas consiste en un buen porcentaje en resolver problemas en la infraestructura.

Resolución de problemas reactivo vs. proactiva
La visión de décadas anteriores, cuando las infraestructuras informáticas no eran tan importantes para las organizaciones como las de ahora, era actuar reactivamente, resolver los problemas a medida que iban ocurriendo, intentando rastrear la fuente del error (la fatídica "causa raíz", root cause), mediante RCA (Root Cause Analisys, "Análisis de Causa Raíz").

En algun momento hace no tantos años las infraestructuras añadieron el requerimiento de tener que estar funcionales el 100% del tiempo (online), es decir, ímplicitamente, es el requerimiento no poder fallar nunca.

La forma de trabajo anterior al 100% de tiempo online era: montar la infraestructura lo mejor posible, luego ir reparandola según era necesario; es decir resolver los problemas de forma reactiva.

Si hacía falta sacarla de línea (apagarla), durante varios %MEDIDA_DE_TIEMPO% (segundos, minutos, horas, días, etc.), se consideraba ello un fallo catastrófico y se procedía implementar planes más drásticos de resolución del problema (DR - Disaster Recovery).

Avance rápido al 2012 y las medidas de DR son anatema, nadie quiere oír hablar de no tener en servicio un sistema con requisito de 100% de tiempo online, mucho menos de tener que implementar acciones para restaurarlo a un estado funcional. Hay que tener esas medidas, pero se aspira, se planea y se diseña las infraestructuras para nunca tener que usar planes de Disaster Recovery.

Claro, la resolución reactiva de los problemas implica la existencia de "causas raíz" que estaban ahí en la infraestructura previo a la existencia del problema a resolver. Lo necesario para evitar caídas de servicio que impliquen implementar planes de DR es resolver los problemas proactivamente, en otras palabras, resolver los problemas antes de que ocurran, y por ende, buscar y encontrar las causas que van a crear problemas.


Predicción de problemas + resolución proactiva
La idea de que los problemas deben resolverse antes de que ocurran se vuelve viable mediante diferentes herramientas, claro, la información útil que esas herramientas producen debe estar disponible a los administradores. En general, podemos mencionar al típico Nagios, con un buen nivel de provisión de información (vía agente local por ejemplo), sumando algun soft de recogida de métricas y otro de análisis de esas métricas.

La información clave para el administrador está en la vista del análisis de las métricas, en gral. y como mínimo serán una gráficas a revisar al menos semanalmente para verificar que la "imagen" es la típica de una buena performance.

En realidad un buen análisis predictivo se puede realizar operando - programando una aplicación, implementando un software prearmado que lo haga - sobre las métricas, extrayendo y mostrando los valores fuera de promedios usuales. Los promedios usuales son una buena manera de crear código "template" para analizar métricas en gral., de ese modo se evita tener que depender de valores threshold hardcodeados server por server.

Por ejemplo, si tenemos un server "Caño" donde el consumo promedio de memoria está en un 80% diario de la capacidad disponible, y otro server "Pareto" donde el mismo recurso solo se consume a un 15% diario, usar promedios nos va a evitar tener que "explicar" en el código que hace el análisis que en Caño el 80% de consumo de ram está OK, pero en Pareto si vemos un 80% de consumo de ram, algo no anda muy bien.

Y eso se realiza automáticamente, no hay que depender de valores hardcodeados que pueden cambiar de un día para otro.

Si nuestra app de análisis tiene un buen código para dumpear los resultados significativos, al menos en forma de texto, el resultado final podría llegar a ser desde un simple logfile en un server (de análisis), con el resumen de lo extraído por la app, hasta un mail enviado a diario al sysadmin, que dependiendo de si encontró o no valores fuera de los promedios puede llegar a modificar el subject del correo desde un [Valores Normales] a un [Valores Extraños], o incluso un [Valores Críticos Confirmados] > si es que acaso llegara a encontrar cualquier cosa con 90% a 100% de valores. Idealmente tendríamos todo lo anterior, más una interfaz gráfica con algun rutilante mensaje en color rojo indicandonos que algo no anda tan bien, al parecer.

Diferencia con alertas activas
En Nagios y otros software de monitoreo tenemos interfaces gráficas que van a mostrar en "rojo rutilante" los errores actuales en la infraestructura. No me refiero a este tipo de herramientas ni resultados al hablar de avisos previos a la ocurrencia de errores y outages (el error/outage ya ha ocurrido cuando vemos esos mensajes).

Fuentes de datos
La información base en la cual se puede realizar ese análisis puede ser casi cualquiera: se puede configurar Nagios para que dumpee datos históricos a un registro, se puede operar sobre los logfiles de sistema de los servers (el resultado de syslog en Linux, y/o el de Event Log en Windows Server), idealmente esos logs deberían ser automáticamente enviados a un log server para poder trabajar sobre ellos con facilidad. Otra opción para Linux es operar sobre los registros de soft como SAR por ejemplo.

Como se ve, en el párrafo anterior los datos necesarios para la resolución proactiva de problemas están disponibles por defecto, y sin mayor customización de la configuración de los servers en gral., sin importar la plataforma (win, linux). Lo necesario es montar software que se encargue de aprovechar esas fuentes de datos.


Conclusiones
La resolución reactiva de problemas en una infraestructura que tiene el requerimiento de permanecer funcional el 100% del tiempo no es el modo ni la práctica correcta.

La consecuencia probable de trabajar con práctica de resolución reactiva de problemas es que la infraestructura pueda fallar, no lograndose el 100% de funcionalidad requerida (y casi de seguro necesaria e indispensable), llegando en casos extremos a la necesidad de implementar Disaster Recovery.

Se necesita cambiar la práctica para implementar la resolución proactiva de los problemas y esto implica el montaje de más infraestructura, que permita adquirir los datos necesarios y analizarlos convenientemente, de modo que generen y además comuniquen oportunamente - luego de que ya no se pueda evitar que ocurra el problema es demasiado tarde - esos datos a los encargados de solucionar proactivamente los problemas (los administradores de sistemas).