Gestión de Redes

La revolución del downsizing, el rightsizing y el proceso cliente/servidor ha resultado particularmente adversa para los responsables de redes y comunicaciones. En la mayoría de los casos, nadie les consulta antes de adquirir e instalar una nueva tecnología, pero todo el mundo espera que hagan que funcione todo y que ofrezcan la máxima calidad en soporte técnico.

En los últimos cinco años, se han producido extraordinarios desarrollos y acontecimientos en la gestión de redes que contribuyen a solucionar los problemas de los entornos de proceso distribuido actuales. Entre los ejemplos de productos de vanguardia pueden citarse los que se conocen generalmente como plataformas de gestión: OpenView de Hewlett-Packard, NetView/6000 de IBM, Spectrum de Cabletron Systems, NetLabs/Manager de NetLabs, SunNet Manager de SunConnect y el RelationalObject Data Manager del NetView/390 de IBM. A pesar de la indudable calidad de estos productos, ninguno realiza una función completa como sistema de gestión de red de un extremo al otro de una empresa, o simplemente sistema de gestión de empresa o enterprise manager. No obstante, esto no ha impedido que varios vendedores intenten posicionar sus productos como sistemas de gestión de empresa. Desafortunadamente, la mayor parte de los anuncios de estas empresas se basan más en la creatividad de sus departamentos de marketing que en la capacidad intrínseca del producto.

Esto no significa que no hayan tenido lugar grandes avances en estas plataformas de gestión. Las tareas que realizan, y que realizan bien estos sistemas son:

- Descubrir la topología de red automáticamente, visualizar gráficamente los componentes de red, y adaptar a medida las vistas o visiones gráficas.

- Visualizar alarmas de red en forma de mensajes y cambios de color en los iconos que representan elementos de red.

- Permitir al operador recoger información adicional sobre alarmas, con el fin de diagnosticar problemas de red.

- Recoger ciertos tipos de información estadística y representarla en forma de gráficos.

- Permitir a clientes y a terceros utilizar el producto para desarrollar sus propias aplicaciones de gestión e integrarlas con el resto de su sistema.

- Poner en marcha aplicaciones para tareas de gestión específicas y supervisarlas.

Sin embargo, es igualmente importante comprender lo que no pueden hacer estos productos. Más de una compañía ha adquirido un sistema de este tipo pensando en la gestión de red de la empresa y ha descubierto sus limitaciones y los elevados costos resultantes.

La elección de los protocolos

Los sistemas de gestión de red tienen una sensibilidad innata a los protocolos, y funcionan mejor con sus propios protocolos nativos. Sus arquitecturas de software interno, visualizaciones gráficas, lógica de análisis de alarmas e interfaces de programación y puesta a punto, están diseñados para funcionar mejor con un determinado protocolo. Por ejemplo, los sistemas de gestión SNMP (Simple Network Management Protocol) no gestionan los medios e instrumentos de la arquitectura SNA de IBM, de X.25, de Open Systems Interconnect, de Integrated Services Digital Network o de telecomunicaciones, tan bien como gestionan los dispositivos TCP/IP, incluso utilizando gateways y convertidores de gran alcance.

Tanto NetView/6000 como el OpenView de Hewlett-Packard disponen de soporte SNA añadido, pero ninguno de ellos puede ofrecer el mismo nivel de gestión SNA que el NetView/390 de IBM, que es un sistema para proceso SNA/Advanced Peer-to-Peer Networking (APPN), ni pueden manejar las grandes redes SNA (con más de 10.000 terminales) que puede manejar NetView/390.

No hay que esperar integración

Estos sistemas tampoco ofrecen una vista o visión integrada de la red de la empresa a nivel corporativo. Así, por ejemplo, una empresa no puede obtener una vista única de la interconectividad entre sus procesadores, controladores y terminales front-end IBM y sus routers, puentes y redes LAN.

La capacidad y el rendimiento son un problema para los sistemas de gestión en las grandes redes de empresa, especialmente aquellas con una gran población SNA. Esta es la queja más frecuente por parte de clientes con grandes redes. Incluso en las redes en las que dominan los dispositivos SNMP, los usuarios están comenzando a comprender que la detección selectiva o polling SNMP afecta considerablemente al rendimiento de la red. El SNMP Version 2 podría ayudar a resolver este problema, pero sólo en redes que funcionen bajo el protocolo TCP/IP.

Al pasar estos sistemas a arquitecturas de proceso distribuido, podrían resultar más capaces de manejar redes de gran tamaño. Sin embargo, esto sigue siendo una incógnita.

Una limitación alarmante

Aunque varios sistemas de gestión de los enunciados soportan múltiples protocolos, no hay forma de correlacionar las alarmas en los diversos protocolos, como resultado de la cual podrían eliminarse alarmas secundarias (a causa de un fallo de un componente de nivel superior). En realidad, la mayoría de los productos no pueden realizar correlación de alarmas dentro de su protocolo nativo.

Esto lo resolvería un sistema experto integrado en el producto, pero la mayor parte de los productos no tienen una extensión de sistema experto que sea digna de mención.

Resulta interesante que los vendedores de plataformas de gestión SNMP son los que con mayor fuerza proclaman la apertura de sus productos, y sin embargo estas plataformas se convierten en las más cerradas cuando se intenta extraer información de ellas. Este año se han anunciado capacidades verdaderamente distribuidas, permitiendo el uso compartido de información entre sistemas de gestión para un mismo vendedor. El mercado deberá ejercer una verdadera presión sobre los vendedores para que pueda ser posible el uso compartido de información entre sistemas de acumulación de diferentes vendedores.

Finalmente, ninguno de los sistemas ofrece aplicaciones de gestión integrada a nivel de empresa para gestión de problemas o gestión de configuración, contabilidad, seguridad o rendimiento. Francamente, resulta dudoso que los vendedores puedan ofrecer tales aplicaciones para grandes redes en sus plataformas actuales con sus arquitecturas no distribuidas actuales. Lo que sí es evidente es una preocupación creciente de todos los suministradores de este tipo de productos por ofrecer soluciones que satisfagan los requerimientos de los grandes usuarios corporativos.

Esquema piramidal

SISTEMAS DE INTEGRACION. Recogen información de los sistemas de gestión de red en los dos niveles siguientes, para obtener una visión y un control integrados de la red.

SISTEMAS DE ACUMULACION INTERMEDIOS. Integran información de gestión procedente de múltiples sistemas de gestión de elementos (un nivel por abajo) siempre que pertenezcan a la misma familia de protocolos. OpenView, NetView/6000 y SunNet Manager realizan esa función para SNMP. NetView/390 y NetMaster de System Center realizan una función similar para la arquitectura SNA de IBM.

SISTEMAS DE GESTION DE ELEMENTOS. Manejan subconjuntos específicos de elementos de red, tales como sistemas de gestión de LAN, modem y multiplexor.

ELEMENTOS DE RED. Son los hubs, el cableado, puentes, routers, modems, multiplexores y terminales que es necesario manejar y controlar.

Los costes de la gestión de red

En la gestión de redes, los agentes son las partes más caras. Por agentes se entienden aquellas cosas que manejan o gestionan los componentes individuales de la red. Por ejemplo, un módulo de gestión Ethernet para un núcleo o hub puede costar varios miles de dólares. Si uno tiene una red con 10 ó 20 de éstos, puede resultar bastante caro.

El siguiente es un problema int