| Artículos | 01 MAY 2007

Microsoft System Center Operations Manager 2007

Tags: Histórico
Daniel Matey.
Para un buen administrador, sólo hay una cosa peor que un servicio caído, y es enterarse de ello por la llamada de un usuario. Para evitar este tipo de situaciones Microsoft ha liberado recientemente la nueva versión de su sistema de centro de operaciones, que analizamos a continuación.

Cuando suena el teléfono y coge esa llamada, el administrador ve inexorablemente cómo, a la vergüenza de un fallo, hay que sumarle la de no ser consciente de lo que pasa en nuestra infraestructura, provocando que nos tengamos que enterar por otra persona del incidente.
Por supuesto, se pueden esgrimir muchos atenuantes; como que hay muchos servidores y pocos administradores, que las cosas cada vez son más complicadas o que no hubo tiempo de hacerlo bien, ente otros. De hecho, seguramente todos estos argumentos tendrán algo de cierto hoy en día, pero lo que también es cierto es que, según las últimas encuestas, los departamentos de TI (Tecnologías de la Información) dedican más del 70 por ciento de sus esfuerzos a mantener, y aun así, en muchas ocasiones, este mantenimiento no alcanza las cotas de calidad que las empresas requieren. Por lo tanto, es hora de poner soluciones. Contar con los recursos adecuados puede ser difícil, pero tener buenas herramientas es más fácil de lo que pensamos, y en muchos casos puede mejorar notablemente la situación.
Lógicamente, partimos de la base de que nadie puede tener un ojo puesto en cada servidor y, desde luego, los administradores no tienen una bola de cristal que les deje ver qué servicio dará problemas o qué servidor está cerca de su límite de capacidad. Por esa razón, Microsoft ofrece Operations Manager 2007, una completa herramienta que nos permitirá ver y saber todo lo necesario acerca de nuestra red, servidores y servicios, con el fin de evitar esas llamadas tan incomodas de las que hablábamos con anterioridad, así como reducir el tiempo requerido para el mantenimiento, lo que nos permitirá elevar nuestras cotas de calidad de servicio incluso por encima de nuestros objetivos.
SCOM no nace ahora, hace ya varios años Microsoft licencio la tecnología de monitorización de NetIQ, dando lugar a un nuevo producto llamado MOM 2000 (Microsoft Operations Manager). Aquel producto, con sus limitaciones, permitió a Microsoft adentrarse en el mercado de la monitorización y demostrar a sus competidores y clientes que nadie podía monitorizar mejor un producto de Microsoft como la propia Microsoft.
Después, el Service Pack 1 de MOM 2000 aportó estabilidad y muchas mejoras, pero el producto seguía estancado en infraestructuras puramente Microsoft. Entonces MOM hacía un gran trabajo, pero para aquellos clientes que ya disponían de sistemas de monitorización, como Tivoli u OpenView, MOM estaba siempre bajo ellos.
En el año 2005 salió a la luz una nueva versión, MOM 2005, que posteriormente tendría también un Service Pack. El producto dio un buen cambio, mucho más seguro, escalable, y con el apoyo de más socios que le permitían monitorizar desde Oracle a Linux, o dispositivos de red.
Pero aunque todo el mundo estaba convencido de que MOM 2005 ya era un competidor muy serio y su cuota de mercado crecía y crecía, aún tenía un fallo, ya que, aunque la visión de MOM 2005 de la infraestructura siempre estaba basada en servicios y servidores (y ya entonces la monitorización de SQL Server, Exchange o cualquiera de los demás productos de Microsoft era de las mejores del mercado), los clientes también tienen sus propias aplicaciones, y deseaban un producto que les permitiera monitorizar, no sólo sus servicios y servidores, sino también sus soluciones, y además de la forma más completa posible.
Así nació System Center Operations Manager 2007 (o SCOM 2007, llamado también MOM v3 durante la fase beta), un producto renovado completamente en el que Microsoft ha realizado un gran esfuerzo de desarrollo.

La arquitectura de SCOM 2007
Para ejecutarse correctamente, SCOM requiere de un motor de base de datos SQL Server 2005, donde se albergarán varias bases de datos: la del propio MOM, la del servidor de informes y el Data Warehouse, donde se guardarán los históricos de rendimiento y demás información que tengamos interés en quedarnos a largo plazo. Por último está la base de datos del sistema de recolección de auditorías de seguridad (Audit Collection Database). Estas bases de datos se pueden montar en un sólo servidor, o repartidos en varios, según el numero de servidores a monitorizar y de otros parámetros. La cantidad de datos que se almacenará en estas bases de datos será tremenda, SCOM puede recoger miles de contadores de cada uno de los servidores, y en muchos casos recogerá esta información cada pocos minutos (o incluso segundos). Por su parte, es normal que el número de eventos en cada servidor sea bastante alto (y, por supuesto, el de eventos de seguridad puede llegar a ser enorme). Por otra parte, intentar obtener informes en tiempo real de esta información puede ser un proceso muy exigente, así que conviene dimensionar correctamente el hardware en el que montemos estas bases de datos.
Cuando está en funcionamiento, un proceso interno, denominado (grooming), se encargará de eliminar de la base de datos toda la información que no necesitemos, y otros procesos moverán y transformarán la información a la base de datos de Data Warehouse, de forma que podamos disponer de estos datos a largo plazo, y poder, por ejemplo, visualizar informes que nos digan cómo ha evolucionado el uso de una aplicación a lo largo de un año, o si nuestro hardware será capaz de seguir dando una buena calidad de servicio a lo largo de los próximos meses.
Los servidores que queramos monitorizar tendrán que tener instalado un agente, y dicho agente es el encargado de recoger la información de los eventos, rendimiento e información generada por los scripts de SCOM, así como comprimirla, encriptarla y mandarla al servidor de SCOM, denominado Management Server. Los Management Servers están agrupados en Management Groups. A su vez, podemos tener varios Management Servers en modo tolerancia a fallos, porque nuestro diseño lo requiera, o por otros motivos, como las limitaciones en las comunicaciones, segmentación de la administración o distribución geográfica, por ejemplo.
Igualmente es posible monitorizar servidores sin tener que instalarles un agente. Este tipo de monitorización es más limitada, requiere de más ancho de banda y tiene algún requisito adicional a nivel de seguridad. En redes que cuenten con cortafuegos, es posible configurar un servidor específico como gateway o pasarela, de forma que todos los servidores monitorizados en esa red manden su información a ese gateway, y sea éste quien la mande al Management Server, reduciendo así las reglas a introducir en el firewall y, por lo tanto, los riesgos y requisitos.
Como no podía ser de otra manera, SCOM confía en la plataforma de informes de Microsoft, Reporting Services, para diseñar, renderizar y mostrar los informes. Tanto la base de datos de Reporting Services, como los servicios y la web de este producto se pueden instalar todas en el mismo servidor. Asimismo, las bases de datos, los Reporting Servicices, y el Management Server, también pueden estar en un sólo servidor, y esta configuración, montada sobre un buen hardware, puede ser válida para sistemas que monitorice

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información