Administrando
los Ambientes Distribuidos
Primera Parte: Parte 1 de 4
Por: Ulises Castillo
Introducción
Uno
de los lados negativos del crecimiento de las PCs, las redes e
incluso de Internet, es que ha venido aparejado de un desorden
creciente (el principio de la entropía y la teoría del caos dirían
los teóricos).
En
general, entre mayor es la cantidad de usuarios y/o mayor es la
complejidad de las aplicaciones y servicios que se atienden a través
de los sistemas distribuidos, mayor es la problemática de
administrarlos. Podemos decir, que no sabemos bien a bien lo que está
pasando “allá afuera”. La gente instala nuevas PCs, software de
diversos tipos, reconfigura dispositivos y servidores, modifica los
niveles de autorización de las bases de datos y muchas de estas
tareas se realizan sin el conocimiento ni la aprobación del área
de sistemas, sin documentar las actividades hechas y bajo ninguna guía
o procedimiento formal.
Planteemos
algunas preguntas que nos podrían ayudar a saber que tan
organizados tenemos nuestros sistemas distribuidos :
 |
|
|
¿
Estamos monitoreando el uso de servidores, enlaces y redes y
podemos anticipar cuellos de botella –y por tanto tomar
decisiones- antes de que causen problemas? |
|
¿
Instalamos las nuevas versiones de software –a nivel de PCs
o de servidores- de manera ágil y eficiente ? (una buena
forma de medir su respuesta es tomando en cuenta la opinión
de los usuarios). |
|
Cuando
sucede un problema ¿siempre logramos dar con la causa raíz
en forma rápida, o en ocasiones nos toma varias horas (o días)
y es un proceso desgastante en que cada área le echa la culpa
a otra ? |
Por cierto, incluimos en el término ambientes o sistemas distribuidos a todos los equipos, dispositivos y software que conforman las redes corporativas. En particular quedan excluidos los mainframes (aunque hoy día es frecuente que el mainframe juegue también el papel de servidor de la red y esté igualmente conectado con los demás elementos a través de los protocolos TCP/IP).
¿Qué
consecuencias tiene esta falta de administración?
Dentro
de todas las implicaciones que existen, hay una en particular que ha
tomado importancia creciente en los últimos años, y es el costo de
tenerlos y mantenerlos. Comúnmente llamado “Costo Total de
Propiedad” o TCO (por sus siglas en inglés), se pone de moda
cuando algunos analistas del mercado (como Forrester Research o
Gartner Group) deciden calcular cuánto gasta una empresa por cada
PC que tiene.
Antes
de esos análisis, la respuesta parecía ser muy simple : el costo
de la PC (amortizado generalmente a dos años) más el costo del
software y el mantenimiento anual. Sin embargo, los analistas
agregaron rubros como el costo de soporte técnico y del personal de
la mesa de ayuda, el costo de las horas hombre desperdiciadas cuando
un equipo no funciona adecuadamente (tanto el tiempo del mismo
usuario, como el que le hace perder a otros cuando les pide ayuda )
además de los costos relacionados a la red : tarjetas, cableado,
servidores, administradores.
De
todas las cifras anteriores, el TCO por cada PC en los Estados
Unidos anda en un rango entre los 7,000
y 12,000 dólares anuales.
No,
no sobraron ceros ni estamos inventando para crear pánico en el
mercado. Probablemente algunos lectores no crean la cifra anterior,
pero eso es lo que resulta de los análisis realizados por las
empresas mencionadas; ciertamente podemos esperar que el TCO en países
latinoamericanos sea menor, pues todos los costos asociados con mano
de obra son bastante inferiores a los correspondientes americanos.
No
importa si el TCO está en 7,12 o 4 mil dólares, lo que es un hecho
es que mucho de este costo está asociado con el desorden en los
ambientes distribuidos y con el poco nivel de administración que
tenemos en ellos. En
otras palabras, si a través de una buena administración las redes
no dieran tantos problemas y los pocos que hubiera los resolviéramos
mucho más rápido, y si además muchas tareas se pudieran hacer en
forma remota y centralizada, requeriríamos menos personal de
soporte técnico (probablemente el mismo que hoy tenemos, pues en
general falta personal y de ahí también muchos problemas), las
horas perdidas de los usuarios serían menos y bajaríamos el costo
total o TCO drásticamente.
Sin embargo, bajar el costo total de propiedad no es la única motivación para administrar correctamente los sistemas. Entre otras están :
|
Crecientemente
hay aplicaciones importantes, incluso de Misión Crítica
corriendo en ambientes distribuidos (NT, Unix y Windows-2000)
que necesitan de una alta disponibilidad. |
|
Para
redes muy dispersas geográficamente, es difícil –sino
imposible- tener personal de soporte con los conocimientos
necesarios, en todas y cada una de las localidades. |
|
Hay
algunas tareas, como controlar los inventarios y
configuraciones, o instalar software, que son una verdadera
pesadilla cuando tenemos cientos o miles de PCs. |
|
Es
difícil planear la capacidad de los sistemas y enlaces. Comúnmente
se cae en uno de los dos extremos : o nos esperamos hasta que
algún elemento está saturado (situación que puede ocasionar
caídas de la red o los servidores) o tratamos de ser
previsores y ponemos capacidad de sobra (pero como no sabemos
bien a bien donde requerimos más capacidad, entonces
incrementamos las capacidades de servidores, enrutadores y
switches, enlaces, etc.). |
Por todo lo anterior, las empresas e instituciones han querido administrar sus redes y ambientes distribuidos desde hace muchos años. ¿Los resultados? Veámoslos en la siguiente sección.
¿Qué
ha pasado con la Administración de Redes y Sistemas?
Gartner
Research (antes Gartner Group) señala que más del 70% de los
proyectos de Administración de Redes y Sistemas (NSM por sus siglas
en inglés) han fracasado, ¿por qué?
Aunque algunas de las razones de fracaso y sus respectivas recomendaciones para evitarlo las estaremos viendo durante el desarrollo de las cuatro partes de este artículo, mencionemos muy brevemente las principales :
|
El
proyecto pretendió abarcar “todo”
y realizarse en 12 o 15 meses (enfoque de “big-bang”,
haciendo alusión a la gran explosión que se supone originó
el universo). |
|
Le
creímos todo al proveedor.
No probamos que tuviera historias de éxito similares a
nuestro caso. En otras palabras, el proveedor aprendió con
nosotros. |
|
Sólo
tomamos en cuenta la tecnología.
Se nos olvidaron los procesos y procedimientos, y la gente que
los utilizará. |
|
Nunca
se involucró al personal de operación.
Cuando se empezó a implementar, ellos eran los primeros en
contra. |
|
No
se hizo una evaluación de riesgos permanente.
Por lo tanto, se nos fueron “apareciendo” diversas
sorpresas durante la ejecución del proyecto. |
¿De
qué hablaremos?
En
esta primera parte del artículo nos enfocaremos a platicar un poco
de SNMP, el protocolo más usado en la administración de redes, así
como algunos conceptos generales.
En
el siguiente número, hablaremos de diversas herramientas que
existen en el mercado, proponiendo una clasificación y abarcando
–entre otras cosas- tanto las que están enfocadas a administración
de redes como aquellas enfocadas a sistemas.
Los
niveles de servicio así como los procesos que se deben abarcar al
administrar ambientes distribuidos, los tocaremos en el número tres
de esta serie, en donde también hablaremos de los modelos de
procesos y administración como ITIL (IT Information Library,
originado en la Gran Bretaña) o de modelos derivados de éste (como
ITSM de Hewlett-Packard o el nuevo MOF de Microsoft).
Para
terminar la serie, en el último artículo hablaremos de las
diversas consideraciones para la realización de un proyecto de
Administración de Ambientes Distribuidos, y de las últimas
novedades tecnológicas (cosas como SNMP versión 3, por ejemplo).
Bien,
entremos ahora de lleno a nuestro tema de hoy.
Nota : Este artículo resultó un poco más técnico de lo que acostumbro, por lo que si usted no tiene tendencias “nerdziles” (sin ofender a nadie), le recomiendo leer sin detenerse las secciones que le puedan parecer poco claras (o incluso aburridas). Sin embargo, es importante establecer algunos términos y conceptos para los siguientes artículos.
¿
Qué es la administración de ambientes distribuidos ?
Las 5 tareas
Hace
ya algunos años, la Organización Internacional de Estándares
(ISO) definió cinco tareas fundamentales para la administración de
redes y sistemas :
1.-Manejo de fallas (Fault
management) .-
Tiene que ver con tener los mecanismos para saber qué elemento está
presentando problemas, poderlo aislar, reparar y reintegrar con el
menor impacto posible. En forma ideal los mecanismos deben ser cada
vez más proactivos : avisarnos del problema antes de que ocurra (¡!).
Cuando hablamos de sistemas de mesa de ayuda (help-desk)
o del proceso de manejo de problemas o de manejo de incidentes de
seguridad, estamos hablando de particularidades del manejo de fallas.
Igualmente cuando algún tipo de software nos avisa que el disco
duro está a punto de llenarse, estamos hablando de manejo de fallas.
2.-Manejo
de configuraciones (Configuration
Management) .-
Aquí se incluyen las actividades orientadas a poder contar con un
inventario actualizado de todos los elementos de nuestras redes, así
como el detalle de sus configuraciones. En una visión ampliada, no
solamente es el control de las configuraciones sino todo el control
de cambios (proceso que comentamos en nuestro último artículo y
del que hablaremos mucho en el último número de esta serie).
3.-Contabilidad
de recursos (Accounting
Management) .-
Esta tarea se relaciona con la capacidad de poder contabilizar qué
usuarios usan qué recursos. Curiosamente, en los ambientes
distribuidos esta ha sido la tarea en evolucionar más lentamente
que las demás.
4.-Administración
del desempeño (Performance
Management) .- Muchas de las funciones de la operación
cotidiana de los sistemas se encuentran en este grupo. El objetivo
es tener implementados una serie de procesos y herramientas, de
forma que el personal de operaciones pueda tener en forma permanente,
una serie de mediciones que le indican si la operación de las redes
y los sistemas está desarrollándose de manera normal. Por
desgracia, esta tarea se limita muchas veces a monitorear la red, y
hacerlo a través de “un montón” de gráficas. Lo que podemos
decir por ahora es que –en general- entre más se grafica menos se
administra (¡ojo!).
5.-Administración de la seguridad (Security
Management) .- Aquí se incluyen todas las actividades encaminadas a brindar una
adecuada seguridad a nuestros sistemas. Desde el punto de vista de
la operación diaria, el monitoreo de la seguridad está asociado
con los eventos que se reflejan en las consolas de el o los Firewalls, detectores de intrusos y herramientas de control de
accesos (se incluye aquí tanto las de autentificación como las de
autorización).
Como es difícil recordar perfectamente las cinco tareas, alguien inventó el orden : FCAPS (por sus siglas en inglés : Fault, Configuration, Accounting, Performance y Security ), que es el mismo orden con el que las hemos descrito.
El modelo general de administración
|
Elementos
de la red .-
Esquematizados como cuadros, y representando : servidores,
PCs, elementos de software (manejadores de bases de datos,
sistemas operativos), dispositivos de conectividad (enrutadores,
switches, hubs) o cualquier otro hardware o software que forme
parte de dicha red. |
|
Agente
.- Es una pieza de software que está “vigilando” a cada
uno de los elementos administrados, y lleva el registro de lo
que dicho elemento realiza así como de variables relacionadas
con él. De esta forma, si estamos hablando de un agente en un
router, éste estará llevando la cuenta de todos los paquetes que
entran y salen, cuántos han pasado por cada puerto del router, cuántos han sido paquetes erróneos, etc.
Pero dicho agente también controla otros datos como
características del dispositivo, configuración actual e
incluso podría llevar el control de la temperatura interna o
del status de los ventiladores (que –por cierto- son
variables muy importantes para asegurarnos que el router
está en condiciones ambientales adecuadas). |
|
Consola de
administración .- Aquí
es donde el administrador puede ver lo que sucede en su red y
realizar tareas como revisar la configuración de algún
dispositivo, distribuir un nuevo software a diversas PCs o
tomar el control de alguna de ellas. El software de la consola
se instala típicamente en una estación de trabajo poderosa y
bajo un ambiente gráfico (puede ser una PC con NT o
Windows-2000, o una estación Unix. En ambos casos es común
que el equipo tenga una buena cantidad de memoria, muy buena
velocidad y un monitor de alta resolución y de mayor tamaño).
Cuando concentramos las diversas consolas y sus
operadores en una sola instalación, tenemos un Centro de
Operación de Red o NOC (por sus siglas en inglés de Network
Operation Center). |
|
Diálogo
.- A través de algún protocolo (como SNMP, del que
hablaremos más adelante) es necesario que se establezca un diálogo
entre la consola y los agentes. De esta forma, la consola
puede “consultar” información que llevan los agentes, o
éstos le pueden avisar a la consola sobre eventos relevantes. |
Existen dos formas básicas y distintas de
que ocurra el diálogo consola-agente :
|
Por encuestamiento
(en inglés : pooling)
.- En esta variante, la consola pregunta permanentemente el
status a cada uno de los agentes. Es como si dijera a cada uno
: “¿estás bien? ”Y al poco tiempo nuevamente preguntará
a cada uno : “¿estás bien?”. |
|
Por evento
.- A diferencia de la anterior, aquí la consola no inicia
ningún diálogo, más bien cada agente tiene definidas reglas
o criterios, para activar eventos de aviso a la consola. Así
por ejemplo, un agente puede tener definido que cada vez que
un enlace llegue al 70% de uso del ancho de banda total, envíe
un evento a la consola, avisando de la situación. |
Como
veremos después, el manejar una red compleja por encuestamiento,
puede hacer que el tráfico de administración sea en sí mismo un
problema.
SNMP : El protocolo para la administración.
Un poco de historia
Las
siglas SNMP vienen del inglés Simple Network Management Protocol, o
Protocolo Sencillo para la Administración de Redes.
Surge a finales de los 80s como una derivación de otro
protocolo llamado SGMP.
Es
curioso como en esos años, SNMP se vio como una solución temporal,
pues muchas personas pensaban que sería reemplazado por otros
protocolos “más poderosos” como CMIP (después convertido en el
protocolo X.700). La verdad es muy distinta, pues hasta hoy en día,
SNMP es –por mucho- el protocolo más utilizado para la
administración de redes y sistemas.
También
es digno de mención que desde su diseño, según asegura su
inventor principal el Dr. Jeoffrey Case, SNMP se concibió como un
protocolo de encuestamiento (pooling) y orientado a la administración
de dispositivos (routers, hubs, etc.) más que a la administración
de sistemas (PCs, servidores, aplicaciones, bases de datos).
El
modelo general aplicado a SNMP
Las
observaciones más importantes son las siguientes :
Agentes
.-
Llamados en este caso, agentes SNMP. Hoy en día hay un sinfín de
elementos que ya integran un agente SNMP. Desde fuentes de poder
ininterrupibles (UPS o no-breaks) o simples concentradores de red
económicos hasta manejadores de bases de datos o conmutadores telefónicos.
Diálogo
.- El diálogo se lleva a cabo usando los comandos o “verbos” de
SNMP. La simplicidad del protocolo se muestra aquí, pues existen
tan sólo 5 verbos. Tres de ellos son iniciados por la consola :
Pedir un dato (Get-request),
Pedir el siguiente dato (GetNext-Request)
y Poner un valor a una
variable (Set-Request).
Todos estos tres verbos se contestan con : Get-Response.
Por último, el quinto verbo lo inicia el agente cuando sucede algo
importante y se denomina : Trap.
Escenarios
de uso.
Para
entender mejor la forma de trabajo de SNMP, veamos un ejemplo. Con
letras itálicas escribiremos el trabajo que realiza SNMP para cada
paso.
Usted
está usando un software de administración que le permite ver en la
consola, el mapa de su red, en estos momentos usted ve todos los
nodos en color verde, lo que significa que no hay problemas con la
red.
Para que usted vea el estado de su red, periódicamente –de acuerdo al tiempo que se la configurado- la consola emite un comando Get-request preguntando por alguna variable de status (¿estas bien?), por cada elemento de la red (la consola previamente tiene las direcciones IP de cada elemento). El agente SNMP respectivo, contesta con un status=OK a través del comando Get-response.
A
los pocos minutos, usted decide darle un “clic” al ícono que
representa el enrutador que tiene en la red de Monterrey. Al hacerlo
y después de pocos segundos, la consola abre una ventana en donde
se ve la configuración de dicho router.
Lo anterior se logra porque la consola emite un comando Get-Request solicitando un dato referente a la configuración del router, seguido de varios comandos GetNext-Request para pedir los datos restantes de la configuración. El agente SNMP del router responde al primer comando y a todos los restantes con Get-Response, enviando en cada paquete, el valor para cada una de las variables que ha solicitado la consola (Get-Response variable=valor).
Como
se puede observar, en general el trabajo de SNMP quedá “oculto”
a través de la interfaz gráfica de la consola y las operaciones
que realiza el administrador al mover el mouse y seleccionar las
diferentes opciones que le permite el software.
Las variables MIB
En
el ejemplo anterior, hemos hablado de que la consola pregunta un
dato o una variable. Para hacer el trabajo de la consola más
sencillo, la forma en que estas variables se agrupan y se les asigna
su identificación obedecen a un estándar. El estándar establece
–entonces- que las variables se agruparán en un árbol, con ramas
distintas para cada grupo y subgrupo. A todo el árbol se le
denomina MIB (Management Information Base) y a las ramas que definen
los grupos de variables básicas se les denominó MIB-I,
posteriormente actualizado a MIB-II.
Dado que la explicación detallada de las variables MIB
requeriría todo un artículo en sí mismo, y que este tema puede
resultar un poco áspero para algunos, resumamos los elementos más
importantes de las variables MIB :
|
Todas
están organizadas en un árbol, con diferentes ramas y
subramas de acuerdo a su agrupación. |
|
Los
primeros niveles del árbol están estandarizados. Así –por
ejemplo- la segunda rama es la que le corresponde a los
esfuerzos de las organizaciones ISO y CCITT. |
|
Dentro
del árbol, las variables que han sido estandarizadas se
denominan MIB-I/II. |
|
Además
de MIB-I y II, cada fabricante puede extender el árbol de
acuerdo con variables que necesite (por ejemplo, si uno de
ellos necesita variables especiales para su router, usará una
rama distinta a la de los demás. Dentro de esta subrama específica,
puede definir –digamos- una variable para medir temperatura,
suponiendo que tiene un sensor que alimenta dicha variable). |
|
Las
variables MIB son definidas con un lenguaje específico
llamado ASN.1 (Abstract Syntax Notation). |
Veamos
un ejemplo que muestra la utilidad de las variables MIB y la
necesidad de leer archivos en ASN.1 .
Supongamos que el fabricante de varios switches y routers que usted tiene es TaiwaNet (marca inventada, espero). Ahora bien, usted acaba de adquirir una consola de administración genérica, digamos HP-OpenView NNM (para simplificar lo escribiremos como HP-OV). Después de instalar su producto, usted quiere empezar a administrar sus routers, pero se da cuenta de que muchas funcionalidades que se comentan en el manual, no las puede utilizar desde la consola. En otras palabras, las variables MIB de los dispositivos TaiwaNet no están “visibles” todavía para el HP-OV.
¿Qué
hacer?
La
respuesta es relativamente sencilla : los fabricantes nos brindan la
definición de sus variables MIB específicas (esta definición
viene en ASN.1) , grabándolas en un archivo de texto. Usted debe
ubicar dicho archivo (viene en un CD, diskette o vía Web) y
alimentarlo en la opción de compilación de variables MIB de su
consola, y ya está.
Si
usted ha compilado las variables MIB, su producto de administración
es capaz de reconocer las particularidades de sus dispositivos
TaiwaNet, y dialogar con ellos.
Ojo,
lo que todavía su consola no es capaz de hacer es dibujar una
representación de su router y que usted pueda ver en ella las
características de su router : número de puertos, status de cada
puerto, etc. Para ello
es necesaria que el fabricante (o alguien más) desarrolle un
software complementario al de su consola (en este caso algo
“adicional” a HP-OV) que interpreta todas las variables MIBs del
dispositivo y las asocia con una representación gráfica. A estas
adiciones de software se les conoce como aplicaciones. En otras
palabras, si queremos “ver” y administrar a detalle los
dispositivos TaiwaNet, y dado que nuestra plataforma de administración
es HP-OV, entonces requerimos de una aplicación de TaiwaNet para
HP-OV.
Hasta
aquí hemos visto la funcionalidad general de SNMP y las variables
MIB. Sin embargo no hemos comentado las ventajas y desventajas de su
uso, ni tampoco hemos hablado de extensiones importantes de las MIB
como el estándar RMON y RMON-2 para monitoreo remoto de redes.
De estos y otros temas estaremos hablando en los siguientes
artículos.
¡
Hasta Pronto ! .
Para mayor información favor de contactar vía e-mail a: