La gestión y seguimiento de la infraestructura de TI es una de las principales tareas del departamento de TI de cualquier empresa. Las soluciones de software HP simplifican la tarea de los administradores de sistemas y organizan un control efectivo de la red de la organización.

La infraestructura de TI moderna es una red heterogénea compleja que incluye soluciones de software, servidores y telecomunicaciones de diferentes fabricantes, que operan sobre la base de diferentes estándares. Su complejidad y escala determinan el alto nivel de herramientas de control y supervisión automatizadas que se deben utilizar para garantizar un funcionamiento confiable de la red. Los productos de HP Software lo ayudarán a resolver problemas de monitoreo en todos los niveles, desde la infraestructura (equipos de red, servidores y sistemas de almacenamiento) hasta el control de calidad de los servicios y procesos comerciales.

Sistemas de monitorización: ¿que son?

En las plataformas modernas para el monitoreo de TI, hay 3 direcciones para desarrollar y llevar el monitoreo a un nuevo nivel. El primero se llama "El Puente" ("Sistema paraguas", "Administrador de administradores"). Su concepto es utilizar inversiones en sistemas existentes que realizan las tareas de monitorear partes individuales de la infraestructura y convertir los propios sistemas en agentes de información. Este enfoque es un desarrollo lógico del monitoreo de infraestructura de TI convencional. Como requisito previo para la implementación de un sistema tipo "Puente", el departamento de TI puede tomar la decisión de consolidar sistemas de monitoreo dispares para la transición a los servicios / sistemas de monitoreo de TI en su conjunto, sistemas dispares que no pueden mostrar la imagen completa. , caso de no diagnosticar una falla grave de la aplicación, y gran cantidad de advertencias y alarmas, falta de cobertura uniforme, priorización e identificación de causalidad.

El resultado de la implementación será una recopilación automatizada de todos los eventos y métricas disponibles de la infraestructura de TI, la comparación de su estado y el impacto en la "salud" del servicio. En caso de una falla, el operador tendrá acceso a un panel que muestra la causa raíz de la falla con recomendaciones para resolverla. En caso de una falla típica, es posible asignar un script que automatice las acciones necesarias del operador.

La siguiente tendencia se llama Anomaly Analytics. Aquí, como en el primer caso, las métricas y los eventos se recopilan de varios sistemas de monitoreo de infraestructura y, además, se configura la recopilación de registros de seguridad y de TI. Por lo tanto, se acumula una gran cantidad de información cada minuto y la empresa quiere beneficiarse de su eliminación. Hay varias razones para la implementación de Anomaly Analytics: la complejidad de la recopilación, el almacenamiento y el análisis oportunos de todos los datos, la necesidad de eliminar de forma reactiva los problemas desconocidos, la incapacidad de identificar rápidamente información importante para la resolución de problemas, la complejidad de la búsqueda manual operaciones para registros individuales y la necesidad de identificar desviaciones y bloqueos repetitivos.

La implementación del sistema permitirá la recopilación automatizada de eventos, métricas y registros, el almacenamiento de esta información durante el período de tiempo requerido, así como el análisis de cualquier información, incluidos registros, información de rendimiento y datos del sistema. Además, será posible predecir y resolver cualquier tipo de problema y prevenir fallas conocidas.

Y finalmente - "Gestión del rendimiento de la aplicación", o identificación y reparación de fallos en las transacciones de los usuarios finales. Esta solución puede ser una adición útil, en estrecha colaboración con las dos anteriores. Además, un sistema de este tipo en sí mismo también puede dar un resultado rápido de la implementación. En este caso, la empresa tiene aplicaciones críticas para el negocio. Al mismo tiempo, es importante la disponibilidad y calidad del servicio, uno de cuyos elementos clave es la aplicación (banca por Internet, CRM, facturación, etc.). Cuando la disponibilidad o la calidad de la prestación de este servicio desciende, generalmente se reduce a la proactividad y la rápida recuperación. Este sistema generalmente se implementa cuando es necesario aumentar la disponibilidad de los servicios y el rendimiento de la aplicación, así como para reducir el tiempo medio de recuperación. Además, este enfoque es bueno para eliminar costos y riesgos innecesarios asociados con un acuerdo de nivel de servicio (SLA) y para prevenir el abandono del cliente (protección comercial).

Los resultados de la implementación pueden diferir según la tarea principal. En general, esto permite la implementación de acciones típicas del usuario por parte de un "robot" de diferentes regiones / segmentos de red, análisis del tráfico "reflejado", verificando la disponibilidad y calidad de los servicios con identificación de cuellos de botella, informando al operador sobre la necesidad de restaurar la operatividad. indicando el lugar de degradación. Si es necesario, es posible diagnosticar profundamente el funcionamiento de la aplicación para encontrar las razones del deterioro sistemático de los servicios.

Los enfoques anteriores se pueden implementar utilizando productos de software de HP, que se analizarán a continuación.

"Puente" de HP

HP Operations Bridge presenta la última generación de sistemas de supervisión generales. La solución combina datos de monitoreo de agentes propietarios, varios módulos de monitoreo de software de HP y herramientas de monitoreo de terceros. El flujo de eventos de todas las fuentes de información se superpone al modelo recurso-servicio, se le aplican mecanismos de correlación para determinar qué eventos son causas, síntomas y consecuencias.

Por separado, deberíamos detenernos en el modelo de servicio de recursos y, más precisamente, en los modelos, ya que puede haber un número ilimitado de tales modelos para analizar información desde diferentes ángulos. Su integridad y relevancia depende de la capacidad de la solución para realizar la correlación del flujo de eventos. Para mantener la relevancia de los modelos, se utilizan herramientas de inteligencia basadas en agentes y tecnologías sin agentes para obtener información detallada sobre los componentes del servicio, las relaciones entre ellos y la influencia mutua entre ellos. También es posible importar datos sobre la topología del servicio desde fuentes externas: sistemas de monitoreo.

Otro aspecto importante es la facilidad de manejo. En entornos complejos y que cambian dinámicamente, es importante asegurarse de que el sistema de monitoreo se ajuste cuando la estructura de los sistemas cambia y se agregan nuevos servicios. Operations Bridge incluye el componente de Automatización de monitoreo, que le permite configurar automáticamente los sistemas ingresados ​​en el perímetro de monitoreo, para los cuales se utilizan datos sobre modelos de recursos de servicio. Al mismo tiempo, se admite la configuración y el cambio de los ajustes de monitorización realizados anteriormente.

Mientras que anteriormente los administradores podían realizar la misma configuración para el mismo tipo de componentes de infraestructura (por ejemplo, métricas en servidores Windows, Linux o UNIX), lo que requería mucho tiempo y esfuerzo, ahora puede configurar de forma dinámica y centralizada valores de umbral para una métrica en el contexto de un servicio o servicio.

Analítica de aplicaciones

Usar el enfoque tradicional de monitoreo implica que inicialmente se sabe qué parámetros monitorear y qué eventos monitorear. La creciente complejidad y dinámica del desarrollo de las infraestructuras de TI hace necesario buscar otros enfoques, ya que se vuelve cada vez más difícil controlar todos los aspectos del funcionamiento del sistema.

HP Operations Analytics le permite recopilar y almacenar todos los datos sobre el funcionamiento de una aplicación: archivos de registro, telemetría, métricas comerciales y de rendimiento, eventos del sistema y más, y utilizar motores analíticos para identificar tendencias y pronósticos. La solución lleva los datos recopilados a un formato único y luego, haciendo una elección contextual, basada en los datos de los archivos de registro, muestra en la línea de tiempo lo que sucedió, en qué momento y en qué sistema. El producto proporciona varias formas de visualización de datos (por ejemplo, un "mapa de calor" interactivo y una topología de las relaciones entre archivos de registro) y utiliza la función auxiliar para encontrar el conjunto completo de datos recopilados durante un período específico en el contexto de un evento o mediante una consulta introducida en una barra de búsqueda. Esto ayuda al operador a comprender qué causó la falla (o, cuando se utilizan datos de HP SHA junto con datos de HP OA, hacer una predicción), así como a identificar tanto el culpable como la causa raíz de la falla. HP Operations Analytics ofrece la capacidad de reproducir una imagen del servicio y el entorno en el momento de la falla y aislarlo en contexto y tiempo.

Otra herramienta analítica es HP Service Health Analyzer. HP SHA detecta comportamientos anómalos de los elementos de la infraestructura monitoreada con el fin de evitar una posible denegación de servicios o violación de los parámetros especificados de su provisión. El producto utiliza algoritmos especiales para el análisis de datos estadísticos basados ​​en el modelo de recursos y servicios topológicos de HP BSM. Con su ayuda, es posible construir un perfil de valores normales de parámetros de rendimiento recopilados tanto de plataformas de software y hardware como de otros módulos BSM (por ejemplo, HP RUM, HP BPM) que caracterizan el estado de los servicios. Los valores típicos de los parámetros se introducen en dichos perfiles, teniendo en cuenta los días de la semana y la hora del día. SHA realiza un análisis histórico y estadístico de los datos acumulados (para comprender la esencia de los datos identificados) y también realiza una comparación con el perfil dinámico existente (línea de base).

Supervisión del rendimiento de la aplicación

Cuando se trata de supervisar el rendimiento de las aplicaciones, se deben destacar los siguientes componentes de la solución de HP:

• Supervisión de usuarios reales de HP (HP RUM): control del paso de transacciones de usuarios reales;
• Supervisión de procesos empresariales de HP (HP BPM): control de la disponibilidad de las aplicaciones mediante la emulación de las acciones del usuario;
• HP Diagnostics: supervisa el paso de solicitudes dentro de la aplicación.

HP RUM y HP BPM miden la disponibilidad de las aplicaciones desde la perspectiva del usuario final.

HP RUM analiza el tráfico de la red, identificando transacciones de usuarios reales. En este caso, puede controlar el intercambio de datos entre los componentes de la aplicación: la parte del cliente, el servidor de la aplicación y la base de datos. Esto hace posible rastrear la actividad del usuario, el tiempo de procesamiento de varias transacciones, así como determinar la relación entre las acciones del usuario y las métricas comerciales. Con HP RUM, los operadores de servicios de monitoreo podrán recibir instantáneamente notificaciones rápidas sobre problemas de disponibilidad del servicio e información sobre errores encontrados por los usuarios.

HP BPM es una herramienta de supervisión activa que realiza transacciones de usuario sintéticas que son indistinguibles de las reales para los sistemas supervisados. La monitorización de datos de HP BPM es útil para calcular un SLA real, ya que el "robot" realiza comprobaciones idénticas en los mismos intervalos de tiempo, lo que garantiza un control de calidad constante del procesamiento de las solicitudes típicas (o más críticas). Al configurar sondas para realizar transacciones sintéticas desde múltiples ubicaciones (por ejemplo, desde diferentes oficinas de la empresa), también puede evaluar la disponibilidad del servicio para diferentes usuarios, teniendo en cuenta su ubicación y canales de comunicación. HP BPM utiliza Virtual User Generator (VuGen) para emular la actividad, que también se utiliza en el popular producto de prueba de carga HP LoadRunner. VuGen admite una amplia gama de protocolos y tecnologías diferentes, por lo que puede controlar la disponibilidad de casi cualquier servicio, así como utilizar un único conjunto de scripts para pruebas y monitoreo.
Si la causa de las fallas o ralentizaciones del servicio se encuentra en tecnologías como Java, .NET, etc., HP Diagnostics puede ayudar.

La solución proporciona un control profundo sobre las plataformas Java, .NET, Python en Windows, Linux y Unix. El producto admite una variedad de servidores de aplicaciones (Tomcat, Jboss, WebLogic, Oracle, etc.), MiddleWare y bases de datos. Los agentes especializados de HP Diagnostics se instalan en los servidores de aplicaciones y recopilan datos específicos de la tecnología. Por ejemplo, para una aplicación Java, puede ver qué consultas se están ejecutando, qué métodos se están utilizando y cuánto tiempo lleva procesarlos. La estructura de la aplicación se dibuja automáticamente, queda claro cómo están involucrados sus componentes. HP Diagnostics rastrea las transacciones comerciales en aplicaciones complejas, identifica cuellos de botella y proporciona a los expertos la información que necesitan para tomar decisiones.

Distribución de soluciones HP en

27.06.2011 Nate McAlmond

Seleccioné tres candidatos: WhatsUp Gold Premium de Ipswitch, OpManager Professional de ManageEngine e ipMonitor de SolarWinds. Cada uno de estos escáneres de red no cuesta más de $ 3,000 (por cada 100 dispositivos), y cada uno tiene un período de prueba durante el cual puede probar el producto elegido de forma gratuita.

Trabajo para una empresa mediana y hemos estado usando el mismo sistema de monitoreo de red durante aproximadamente siete años. Proporciona a nuestros administradores información básica sobre la disponibilidad de servidores y servicios, y también envía mensajes de texto SMS a nuestros teléfonos móviles en caso de problemas. He llegado a la conclusión de que es necesario actualizar el sistema, o al menos agregar una herramienta eficaz que pueda proporcionar un mejor rendimiento y proporcionar información detallada sobre el estado de los servidores de terminal, los sistemas Exchange y los sistemas SQL alojados en su red. . ... Comparemos nuestros candidatos.

Proceso de descubrimiento

Para prepararse para la prueba, el primer paso fue habilitar el servicio SNMP en todos los dispositivos, incluidos los servidores de Windows. Al cambiar la configuración del servicio SNMP, configuré el acceso de solo lectura en todos los dispositivos que el proceso de monitoreo debería cubrir. En los sistemas Windows Server 2003/2000, SNMP se instala mediante el asistente de Componentes de Windows en el panel Agregar o quitar programas, y en Windows Server 2008, los componentes SNMP se agregan mediante el asistente del Administrador del servidor. Después de completar el asistente, debe iniciar el complemento Servicios ubicado en la carpeta del Panel de control y configurar el servicio SNMP; es fácil. Los dispositivos de red administrados, como firewalls, conmutadores, enrutadores e impresoras, también cuentan con administración de servicios SNMP, y el proceso de configuración suele ser bastante sencillo. Para obtener más información sobre SNMP, consulte el Protocolo simple de administración de redes (technet.microsoft.com/en-us/library/bb726987.aspx).

Luego, instalé los tres sistemas de monitoreo en uno de mis dos sistemas operativos con Windows XP SP3. Una vez instalado, cada sistema constaba de dos partes: una base de datos y un servidor web. Cada uno de los sistemas seleccionados puede ser administrado a través de la interfaz web por varios administradores, y usted tiene la capacidad de configurar cuentas con diferentes niveles de acceso. Los tres sistemas tienen en común que cada usuario tiene la capacidad de agregar, eliminar y mover paneles en su espacio de trabajo. Los paneles muestran datos del mismo tipo, como la carga de la CPU o el uso de memoria para diferentes dispositivos en la red.

Antes de comenzar el escaneo de la red (llamado proceso de descubrimiento), configuro los parámetros de cuenta que cada sistema debe usar para obtener acceso a los dispositivos descubiertos en la red. Como se muestra en la tabla de comparación, Ipswitch WhatsUp Gold Premium le permite configurar una cuenta para los servicios SNMP, WMI, Telnet, SSH, ADO y VMware. ManageEngine OpManager Professional admite SNMP, WMI, Telnet, SSH y URL, mientras que SolarWinds ipMonitor admite SNMP, WMI y URL.

Después de configurar el servicio SNMP en dispositivos y cuentas de red (Windows y SNMP) para cada uno de los sistemas de monitoreo de red, comencé el proceso de descubrimiento para un rango de direcciones IP en mi red local. Todos los sistemas detectaron alrededor de 70 dispositivos. Usando la configuración de escaneo predeterminada, los sistemas bajo prueba tuvieron un buen desempeño en la identificación de tipos de dispositivos y proporcionaron información detallada sobre el estado del dispositivo. Los tres sistemas contienen sensores para el rendimiento básico del dispositivo y del servidor, como la utilización de la CPU, la utilización de la memoria, la utilización / plenitud del disco, la pérdida / latencia de paquetes, el estado de los servicios de Exchange, Lotus, Active Directory y todos los servicios de Windows. Cada uno de los sistemas tenía la capacidad de agregar sensores tanto para dispositivos individuales como para grandes grupos de dispositivos.

OpManager y WhatsUp Gold tienen una interfaz para identificar y recopilar eventos de servicio de VMware de servidores e invitados. Además, ambos productos tienen una función de sondeo del administrador de puertos del conmutador que muestra qué dispositivos están conectados a diferentes puertos en los conmutadores administrados. La información obtenida lo ayudará a determinar qué puerto del conmutador se conecta a una aplicación comercial en particular, sin la necesidad de rastrear manualmente los cables en las salas de servidores. En el futuro, puede configurar alertas para puertos de conmutadores específicos. Cuando trabaje con el paquete OpManager, para obtener los resultados del sondeo de puertos, simplemente seleccione el conmutador y ejecute la herramienta Switch Port Mapper; el sistema devolverá los resultados en unos segundos. Una herramienta similar incluida con WhatsUp Gold se llama Dirección MAC y debe ejecutarse con la opción Obtener conectividad marcada. WhatsUp Gold tarda más en obtener un resultado, ya que intenta escanear dispositivos y recopilar información sobre las conexiones en toda la red.

Ipswitch WhatsUp Gold Premium

Ipswitch WhatsUp Gold Premium
POR: proporciona los resultados más precisos entre tres competidores, le permite crear sus propios sensores, proporciona herramientas de monitoreo integrales para sistemas VMware, se integra con AD.
CONTRA: menos sensores incorporados y mayor costo en comparación con la competencia (si compra una licencia para menos de 500 dispositivos).
CALIFICACIÓN: 4.5 de 5.
PRECIO:$ 7495 por 500 dispositivos, $ 2695 por 100 dispositivos, $ 2195 por 25 dispositivos.
RECOMENDACIONES: Recomiendo WhatsUp Gold a los departamentos de TI que prestan servicios en grandes entornos de VMware o que buscan construir sus propios sensores.
INFORMACIÓN DEL CONTACTO: Ipswitch, www.ipswitch.com

Cuando trabajaba con los sistemas IpMonitor y OpManager, de vez en cuando me encontraba con lecturas incomprensibles que me desconcertaban. En IpMonitor, los paneles de control podrían mostrar valores negativos cuando la utilización de la CPU se redujo significativamente. En otro caso, cuando la carga del procesador estaba cerca de cero, el sistema IpMonitor me envió una notificación de que el procesador se usó al 11.490%. El sistema OpManager, rastreando y enviándome la información correcta sobre el uso de disco de los controladores de dominio, en algunos casos no incluyó ninguno de los controladores en la lista de 10 servidores con el uso máximo de espacio en disco. Al mismo tiempo, el panel adyacente anunció que uno de mis controladores de dominio ni siquiera debería estar entre los diez primeros, sino entre los tres primeros. Al usar WhatsUp Gold, no me he encontrado con tales situaciones. WhatsUp Gold monitorea la utilización del núcleo del procesador en sus paneles, y cuando comparé los resultados de los paneles de WhatsUp Gold con el Monitor de rendimiento de Windows, coincidieron exactamente para cada núcleo. Asimismo, la información sobre el uso del disco duro se envió correctamente a todas las aplicaciones relevantes en el espacio de trabajo.

WhatsUp Gold tiene una biblioteca de sensores incorporada que le permite construir nuevos sensores a partir de los existentes. Las grandes organizaciones pueden encontrar útil esta capacidad porque le permite crear un solo conjunto de sensores para monitorear diferentes tipos de dispositivos, la forma más eficiente de configurar sensores para un grupo de dispositivos.

WhatsUp Gold no tiene sensores para fabricantes de dispositivos individuales (con la excepción del sensor para fuentes de alimentación UPS APC), a diferencia de la suite OpManager, que usa sus propios sensores para dispositivos Dell, HP e IBM, pero le permite crear sensores como Script activo. Este tipo le permite desarrollar sus propios procesos de monitoreo utilizando los lenguajes de programación VBScript y JScript. Los sensores de Active Script tienen un centro de soporte en línea donde los usuarios de WhatsUp Gold pueden recuperar y descargar scripts prediseñados.

La única mejora que me gustaría agregar a WhatsUp Gold es la interfaz (Figura 1), principalmente porque es demasiado lineal. Por ejemplo, se necesitarán hasta 5 clics en los botones Cancelar y Cerrar para volver de la ventana Biblioteca de monitores activos al área de trabajo. Además, el sistema WhatsUp Gold carece de un sensor (a menos que, por supuesto, lo escriba manualmente) que verifique el estado del sitio, y puede ser necesario, especialmente en los casos en que el sitio está alojado en un servidor de terceros y no no hay otras formas de acceder a él.

Figura 1: La interfaz premium de WhatsUp Gold

Para manejar situaciones en las que los dispositivos han estado inactivos durante algún tiempo, puede configurar notificaciones para que se envíen cada 2, 5 y 20 minutos. De esta manera, puede llamar la atención del administrador sobre la falta de respuesta de los nodos críticos durante un cierto período de tiempo.

WhatsUp Gold es el único sistema bajo revisión que tiene la capacidad de integrarse en un entorno LDAP; esto puede ser crucial al elegir una solución para redes grandes.

ManageEngine OpManager

ManageEngine OpManager
POR: la mejor interfaz de usuario entre los tres productos; más sensores integrados que los otros dos sistemas; el precio más bajo al comprar una licencia para 50 dispositivos o menos.
CONTRA: durante las pruebas, no todos los indicadores de los dispositivos se mostraron correctamente; la depuración puede llevar algún tiempo para que el sistema sea completamente funcional.
CALIFICACIÓN: 4.5 de 5.
PRECIO:$ 1995 por 100 dispositivos, $ 995 por 50 dispositivos, $ 595 por 25 dispositivos.
RECOMENDACIONES: Los departamentos de TI que buscan sacar el máximo provecho de la caja (excluyendo la integración de AD) apreciarán OpManager Professional. Cuando compra licencias en el rango de dispositivos 26-50, su costo es casi la mitad del costo de los otros dos productos.
INFORMACIÓN DEL CONTACTO: ManageEngine, www.manageengine.com

Después de instalar OpManager, descubrí que era fácil de configurar con una gran variedad de funciones y era fácil navegar entre ellas. OpManager brinda la capacidad de enviar (junto con correos electrónicos y SMS) Mensajes Directos a su cuenta de Twitter, una buena alternativa al correo electrónico. Usar las cuentas de Twitter de esta manera me permite estar al tanto de lo que sucede en la red, pero como mi teléfono no suena cuando se entregan mensajes desde el sistema de Twitter, quiero recibir simultáneamente notificaciones de texto sobre los eventos más importantes. Puedo ver la información de umbral en cualquier servidor usando mensajes de Twitter y así tener un registro de eventos actuales en la red, pero no necesito usar este esquema para enviar alertas sobre situaciones críticas.

Además de los sensores estándar, OpManager ofrece tecnologías de monitoreo de desempeño SNMP desarrolladas por proveedores para dispositivos como Dell Power-Edge, HP Proliant e IBM Blade Center. OpManager también se puede integrar con la API de Google Maps para que pueda agregar sus dispositivos al mapa de Google. Sin embargo, deberá comprar una cuenta de Google Maps API Premium (a menos que planee hacer que su mapa esté disponible públicamente) de acuerdo con los términos de licencia para la versión gratuita del sistema de API de Google Maps.

Para manejar situaciones en las que un administrador recibe una alerta pero no responde a ella dentro de un período de tiempo específico, OpManager se puede configurar para enviar una alerta adicional a otro administrador. Por ejemplo, un empleado generalmente responsable de manejar eventos críticos para un grupo particular de servidores puede estar ocupado o enfermo. En tal caso, tiene sentido configurar una advertencia adicional que atraiga la atención de otro administrador si la primera advertencia no se ha visto o borrado dentro de un número específico de horas / minutos.

Entre los tres productos bajo consideración, solo el sistema OpManager tenía una sección diseñada para monitorear la calidad de los intercambios VoIP en la red global. Para utilizar las herramientas de supervisión de VoIP, los dispositivos de las redes de origen y de destino deben admitir la tecnología Cisco IP SLA. Además, el sistema OpManager, como se muestra en la Figura 2, incluye más sensores y paneles de control que cualquier producto de la competencia.

Figura 2: Interfaz profesional de OpManager

IPMonitor de SolarWinds

IPMonitor de SolarWinds
POR: número ilimitado de dispositivos a un precio muy bajo; facilidad de uso.
CONTRA: no existe un mecanismo para coordinar las acciones de los administradores.
CALIFICACIÓN: 4 de 5.
PRECIO:$ 1995: la cantidad de dispositivos no está limitada (25 sensores son gratuitos).
RECOMENDACIONES: Si su presupuesto es ajustado y necesita monitorear una gran cantidad de dispositivos, si el proceso de monitoreo no requiere soluciones complejas y se siente cómodo con un enfoque no sistemático para coordinar las acciones del administrador, SolarWinds es su sistema.
INFORMACIÓN DEL CONTACTO: SolarWinds, www.solarwinds.com

Después de mi primera introducción a ipMonitor, la interfaz de la Figura 3 me resultaba confusa. Me tomó casi una eternidad encontrar un lugar donde esté configurada la frecuencia de las comprobaciones del sistema para los sensores individuales del sistema (de forma predeterminada, la encuesta se realizaba cada 300 segundos). Sin embargo, después de usar ipMonitor durante varias semanas, descubrí que este sistema es extremadamente fácil de usar y tiene suficientes capacidades para un monitoreo de red de alta calidad. Con ipMonitor, puede configurar el análisis predeterminado para que cualquier configuración de servicio o rendimiento siempre se incluya en análisis futuros. Además de los sensores estándar (y mencionados anteriormente), ipMonitor ofrece un sensor de registro de eventos de Windows que se puede usar para enviar alertas cuando se detectan eventos críticos.

Figura 3 Interfaz ipMonitor de SolarWinds

Por otro lado, ipMonitor no tiene mecanismos para rastrear / asignar destinos de alerta. No importa si la empresa tiene un administrador de red, pero es probable que los departamentos de TI más grandes encuentren una desventaja significativa que el sistema no pueda reconocer las alertas, asignar destinos y restablecer las alertas. Si los administradores olvidan coordinar fuera del sistema, es posible que varios administradores reciban la misma advertencia y comiencen a trabajar en el mismo problema. Sin embargo, para resolver tales conflictos, es suficiente desarrollar un algoritmo consistente para responder a las alertas; por ejemplo, si la responsabilidad de los dispositivos de red se divide entre los administradores, entonces no habrá preguntas sobre quién debe lidiar con un problema en particular.

Es hora de tomar una decisión

Ya he decidido por mí mismo cuál de los tres productos es más adecuado para mi entorno. Me decidí por ManageEngine OpManager con una licencia de 50 dispositivos por varias razones.

En primer lugar, necesito poder rastrear tantos parámetros de mi entorno como sea posible, ya que esta es la mejor manera de evitar fallas inesperadas. En este asunto, el sistema OpManager definitivamente está por delante de la competencia. La segunda razón es el presupuesto. Puedo seguir usando nuestras viejas herramientas de monitoreo de encendido / apagado para estaciones de trabajo e impresoras y así evitar el costo de licencias adicionales. Finalmente, me gustó mucho el enfoque que adoptó ManageEngine al desarrollar OpManager para aprovechar la nueva tecnología, y creo que vale la pena invertir en la compra de un paquete anual de mantenimiento y soporte para descargar actualizaciones a medida que se desarrolla el producto.

Nate McAlmond ( [correo electrónico protegido]) - Director de TI para una agencia de servicios sociales, MCSE, Security and Network +, se especializa en soluciones de cliente ligero y bases de datos médicas

ENSAYO

Este documento es un proyecto técnico para el desarrollo e implementación de un sistema de monitoreo de red para la red pública de transmisión de datos de la ciudad de Verkhnepyshminsk de Gerkon LLC. El proyecto investigó los sistemas de monitoreo de red existentes, analizó la situación actual en la empresa y fundamentó la elección de componentes específicos del sistema de monitoreo de red.

El documento contiene una descripción de las soluciones de diseño y las especificaciones del equipo.

El resultado del diseño son las soluciones desarrolladas para la implementación y uso del sistema:

§ Descripción completa de todas las etapas de diseño, desarrollo e implementación del sistema;

§ Guía del administrador del sistema, que incluye una descripción de la interfaz de usuario del sistema.

Este documento presenta soluciones de diseño completas y se puede utilizar para implementar el sistema.

LISTA DE FICHAS DE DOCUMENTOS GRÁFICOS

Tabla 1 - Lista de hojas de documentos gráficos

1Sistemas de monitoreo de red220100 4010002Estructura lógica de la red220100 4010003Algoritmo del núcleo de monitoreo y alertas de red220100 4010004Estructura de la carga del analizador de las interfaces de red220100 4010005La estructura del colector de registros de eventos del sistema220100 4010006Interfaz Nagios220100 4010001

LISTA DE SÍMBOLOS, SÍMBOLOS Y TÉRMINOS

Ethernet es un estándar de transmisión de datos emitido por IEEE. Determina cómo enviar o recibir datos desde un medio de transmisión de datos común. Forma la capa de transporte inferior y es utilizado por varios protocolos de alto nivel. Proporciona una tasa de transferencia de datos de 10 Mbps.

Fast Ethernet es una tecnología de transmisión de datos de 100 Mbps que utiliza el método CSMA / CD, al igual que 10Base-T.

FDDI - Interfaz de datos distribuidos por fibra - interfaz de fibra óptica para la transmisión de datos distribuidos - una tecnología de transmisión de datos a una velocidad de 100 Mbit / s utilizando el método de token ring.

IEEE - Instituto de Ingenieros Eléctricos y Electrónicos es una organización que desarrolla y publica estándares.

LAN - Red de área local - red de área local, LAN. dirección - Control de acceso a medios - número de identificación del dispositivo de red, generalmente determinado por el fabricante.

RFC - Solicitud de comentarios: una colección de documentos emitidos por la organización IEEE que incluye descripciones de estándares, especificaciones, etc.

TCP / IP - Protocolo de control de transmisión / Protocolo de Internet - Protocolo de control de transmisión / Protocolo de Internet.

LAN: red de área local.

SO: sistema operativo.

Software - Software.

SCS - Sistema de cableado estructurado.

DBMS - Sistema de gestión de bases de datos.

Tendencia: estadísticas a largo plazo que le permiten crear una tendencia.

Computadora - Computadora electrónica.

INTRODUCCIÓN

La infraestructura de información de una empresa moderna es un conglomerado complejo de redes y sistemas heterogéneos y de diferente escala. Para que sigan funcionando sin problemas y de manera eficiente, necesita una plataforma de gestión a escala empresarial con herramientas integradas. Sin embargo, hasta hace poco tiempo, la estructura misma de la industria de gestión de redes impedía la creación de tales sistemas: los "jugadores" en este mercado buscaban liderar lanzando productos de alcance limitado, utilizando herramientas y tecnologías que no son compatibles con sistemas de otros proveedores. .

Hoy en día, la situación está cambiando para mejor: hay productos que afirman ser flexibles en la gestión de toda la variedad de recursos de información corporativos, desde sistemas de escritorio hasta mainframes y desde redes de área local hasta recursos de Internet. Al mismo tiempo, se reconoce que las aplicaciones de control deben estar abiertas a soluciones de todos los proveedores.

La relevancia de este trabajo se debe a que en conexión con la proliferación de computadoras personales y la creación de estaciones de trabajo automatizadas (AWS) sobre su base, ha aumentado la importancia de las redes de computadoras locales (LAN), cuyo diagnóstico es el objeto de nuestro estudio. El tema de la investigación son los principales métodos de organización y diagnóstico de redes informáticas modernas.

El "diagnóstico de la red local" es un proceso de análisis (continuo) del estado de una red de información. En el caso de un mal funcionamiento de los dispositivos de red, se registra el hecho del mal funcionamiento, se determina su lugar y tipo. Se informa de la falla, el dispositivo se apaga y se reemplaza con una copia de seguridad.

El administrador de la red, que a menudo tiene la responsabilidad de realizar diagnósticos, debe comenzar a estudiar las características de su red ya en la etapa de su formación, es decir, conocer el diagrama de red y una descripción detallada de la configuración del software, indicando todos los parámetros e interfaces. Para el registro y almacenamiento de esta información, son adecuados sistemas de documentación de red especiales. Utilizándolos, el administrador del sistema conocerá de antemano todos los posibles "defectos ocultos" y "cuellos de botella" de su sistema, con el fin de saber en caso de una situación de emergencia cuál es el problema con el hardware o software, el programa está dañado o led a las acciones de un operador de error.

El administrador de la red debe recordar que desde el punto de vista de los usuarios, la calidad del software de aplicación en la red es decisiva. Todos los demás criterios, como el número de errores de transmisión de datos, el grado de utilización de los recursos de la red, el rendimiento del equipo, etc., son secundarios. Una "buena red" es una red cuyos usuarios no se dan cuenta de cómo funciona.

Empresa

La práctica previa al diploma se llevó a cabo en la empresa Gerkon LLC en el departamento de soporte como administrador del sistema. La compañía ha estado ofreciendo servicios de acceso a Internet en las ciudades de Verkhnyaya Pyshma y Sredneuralsk utilizando tecnología Ethernet y canales de acceso telefónico desde 1993 y es uno de los primeros proveedores de servicios de Internet en estas ciudades. Las reglas para la prestación de servicios están reguladas por oferta pública y normativa.

Tareas científicas y de producción de la división

El departamento de soporte resuelve la siguiente gama de tareas dentro de una empresa determinada:

§ Organización técnica y tecnológica de acceso a Internet a través de canales dedicados y de marcación;

§ organización técnica y tecnológica de acceso inalámbrico a Internet;

§ asignación de espacio en disco para almacenar y garantizar el funcionamiento de los sitios (alojamiento);

§ soporte para buzones de correo o servidor de correo virtual;

§ colocación del equipo del cliente en el sitio del proveedor (coubicación);

§ arrendamiento de servidores dedicados y virtuales;

§ copias de seguridad;

§ despliegue y soporte de redes corporativas de empresas privadas.

1. SISTEMAS DE MONITOREO DE RED

A pesar de los muchos trucos y herramientas para detectar y solucionar problemas de las redes informáticas, el terreno que tienen los administradores de redes sigue siendo frágil. Las redes de computadoras incluyen cada vez más componentes de fibra óptica e inalámbricos, lo que hace que no tenga sentido utilizar tecnologías y herramientas tradicionales diseñadas para cables de cobre convencionales. Además, a velocidades superiores a 100 Mbit / s, los métodos de diagnóstico tradicionales suelen fallar, incluso si el medio de transmisión es un cable de cobre normal. Sin embargo, quizás el cambio más significativo en las redes de computadoras que los administradores deben enfrentar fue el cambio inevitable de Ethernet de medios compartidos a redes conmutadas, en las que los servidores o estaciones de trabajo individuales a menudo actúan como segmentos conmutados.

Es cierto que con la implementación de transformaciones tecnológicas, algunos viejos problemas se resolvieron por sí mismos. El cable coaxial, que siempre ha sido más difícil de solucionar los problemas eléctricos que el cable de par trenzado, se está convirtiendo en una rareza en los entornos corporativos. Las redes Token Ring, cuyo principal problema era su diferencia con Ethernet (y no una debilidad en absoluto en términos técnicos), están siendo reemplazadas gradualmente por redes Ethernet conmutadas. Los protocolos como SNA, DECnet y AppleTalk que generan numerosos mensajes de error en los protocolos de la capa de red están siendo reemplazados por IP. La pila de IP en sí se ha vuelto más estable y más fácil de mantener, como lo demuestran millones de clientes y miles de millones de páginas web en Internet. Incluso los adversarios más acérrimos de Microsoft tienen que admitir que conectar un nuevo cliente de Windows a Internet es mucho más fácil y más confiable que instalar pilas TCP / IP de terceros y software de acceso telefónico por separado.

Dado que muchas tecnologías modernas dificultan la resolución de problemas y la gestión del rendimiento de la red, la situación podría ser aún peor si la ATM se generalizara a nivel de PC. También jugó un papel positivo el hecho de que a finales de los 90, sin tener tiempo de ganar reconocimiento, se rechazaron varias otras tecnologías de intercambio de datos de alta velocidad, incluyendo Token Ring con un ancho de banda de 100 Mbps, 100VG-AnyLAN y redes ARCnet avanzadas. . Finalmente, EE. UU. Rechazó una pila de protocolos OSI muy compleja (que, sin embargo, fue legalizada por varios gobiernos europeos).

Echemos un vistazo a algunos de los problemas de actualidad que enfrentan los administradores de redes empresariales.

La topología jerárquica de las redes informáticas con canales troncales Gigabit Ethernet y puertos de conmutación dedicados de 10 o incluso 100 Mbps para sistemas de clientes individuales ha aumentado el ancho de banda máximo potencialmente disponible para los usuarios en al menos 10-20 veces. Por supuesto, en la mayoría de las redes de computadoras, existen cuellos de botella a nivel de servidores o enrutadores de acceso, ya que el ancho de banda por usuario es significativamente menor a 10 Mbps. Por lo tanto, reemplazar un puerto de concentrador de 10 Mbps por un puerto de conmutador dedicado de 100 Mbps para un nodo final no siempre da como resultado un aumento significativo de la velocidad. Sin embargo, si consideramos que el costo de los conmutadores ha disminuido recientemente, y la mayoría de las empresas tienen un cable de categoría 5 que admite la tecnología Ethernet de 100 Mbps, y se instalan tarjetas de red que pueden operar a 100 Mbps inmediatamente después de reiniciar el sistema, resulta que lo es. claro por qué es tan difícil resistir la tentación de la modernización. En una LAN de medios compartidos tradicional, un analizador o monitor de protocolos puede examinar todo el tráfico en un segmento de red determinado.

Arroz. 1.1 - LAN tradicional con analizador de protocolos y medios compartidos

Aunque la ventaja de rendimiento de las redes conmutadas es a veces sutil, la proliferación de arquitecturas conmutadas ha tenido consecuencias desastrosas para los diagnósticos tradicionales. En una red altamente segmentada, los analizadores de protocolos solo pueden ver el tráfico de unidifusión en un solo puerto de conmutador, a diferencia de una red heredada en la que podrían examinar cualquier paquete en el dominio de colisión. En tales condiciones, las herramientas de supervisión tradicionales no pueden recopilar estadísticas sobre todos los "diálogos", porque cada par de puntos finales "parlantes" utiliza, en esencia, su propia red.

Arroz. 1.2 - Red conmutada

En una red conmutada, un analizador de protocolos solo puede "ver" un solo segmento en un punto si el conmutador no puede duplicar varios puertos al mismo tiempo.

Para mantener el control sobre redes altamente segmentadas, los proveedores de conmutadores ofrecen una variedad de herramientas para restaurar la “visibilidad” total de la red, pero existen muchos desafíos en el camino. Los conmutadores que se envían actualmente suelen admitir la duplicación de puertos, donde el tráfico de uno de ellos se duplica a un puerto no utilizado anteriormente al que se conecta un monitor o analizador.

Sin embargo, la "duplicación" tiene varias desventajas. Primero, solo un puerto es visible a la vez, por lo que es muy difícil identificar problemas que afectan a varios puertos a la vez. En segundo lugar, la duplicación puede degradar el rendimiento del conmutador. En tercer lugar, el puerto espejo generalmente no reproduce fallas de la capa física y, a veces, incluso se pierden las designaciones de VLAN. Por último, en muchos casos, es posible que los enlaces Ethernet dúplex completos no se reflejen por completo.

Una solución parcial para el análisis de los parámetros de tráfico agregados es utilizar las capacidades de supervisión de los agentes mini-RMON, especialmente porque están integrados en todos los puertos de la mayoría de los conmutadores Ethernet. Aunque los agentes mini-RMON no son compatibles con el grupo de objetos de captura de la especificación RMON II, que proporciona un análisis de protocolo completo, todavía proporcionan información sobre la utilización de recursos, las tasas de error y el volumen de multidifusión.

Algunas desventajas de la tecnología de duplicación de puertos pueden superarse instalando "derivaciones pasivas" como las producidas por Shomiti. Estos dispositivos son conectores en Y preinstalados y permiten monitorear la señal real con analizadores de protocolo u otro dispositivo.

El siguiente problema real es el problema con las características de la óptica. Los administradores de redes informáticas suelen utilizar equipos especializados de diagnóstico de redes ópticas solo para resolver problemas con cables ópticos. El software común de administración de dispositivos basado en SNMP o CLI disponible en el mercado puede diagnosticar problemas en conmutadores y enrutadores con interfaces ópticas. Pocos administradores de red se enfrentan a la necesidad de diagnosticar dispositivos SONET.

Con respecto a los cables de fibra óptica, las razones de la aparición de posibles fallos en ellos son significativamente menores que en el caso de los cables de cobre. Las señales ópticas no causan diafonía, que ocurre cuando la señal de un conductor induce una señal en el otro; este factor complica más el equipo de diagnóstico para cables de cobre. Los cables ópticos son inmunes al ruido electromagnético y a las señales inducidas, por lo que no es necesario ubicarlos lejos de los motores de los ascensores y las lámparas fluorescentes, lo que significa que todas estas variables pueden excluirse del escenario de diagnóstico.

La intensidad de la señal, o potencia óptica, en un punto dado es en realidad la única variable que debe medirse al solucionar problemas de redes ópticas. Si es posible determinar la pérdida de señal a lo largo de toda la longitud del canal óptico, será posible identificar casi cualquier problema. Los módulos adicionales económicos para probadores de cables de cobre permiten realizar mediciones ópticas.

Las empresas que implementan y mantienen una gran infraestructura óptica pueden necesitar comprar un reflectómetro óptico en el dominio del tiempo (OTDR), que realiza las mismas funciones para la fibra óptica que un reflectómetro en el dominio del tiempo (TDR) para el cobre. El dispositivo actúa como un radar: envía señales pulsadas a través del cable y analiza sus reflejos, a partir de lo cual detecta daños en el conductor o alguna otra anomalía, y luego le dice al experto dónde buscar el origen del problema.

Aunque varios proveedores de cables y conectores han facilitado la terminación y distribución de la fibra óptica, aún requiere un cierto nivel de habilidad especializada y, con una política prudente, una empresa con una infraestructura óptica avanzada tendrá que capacitar a sus empleados. No importa qué tan bien esté tendida la red de cable, siempre existe la posibilidad de daños físicos en el cable como resultado de algún incidente inesperado.

La resolución de problemas de WLAN 802.11b también puede causar problemas. El diagnóstico en sí es tan simple como en el caso de las redes Ethernet basadas en concentradores, ya que los medios inalámbricos se comparten entre todos los propietarios de los dispositivos de radio del cliente. Sniffer TechHlogies fue el primero en ofrecer una solución de análisis de protocolo para estas redes con un ancho de banda de hasta 11 Mbps, y desde entonces la mayoría de los principales proveedores de analizadores han introducido sistemas similares.

A diferencia de un concentrador Ethernet con conexiones por cable, la calidad de las conexiones inalámbricas de los clientes está lejos de ser estable. Las señales de radio de microondas utilizadas en todas las opciones de transmisión local son débiles y, a veces, impredecibles. Incluso pequeños cambios en la posición de la antena pueden afectar seriamente la calidad de las conexiones. Los puntos de acceso de LAN inalámbrica están equipados con una consola de administración de dispositivos, que a menudo es un método de diagnóstico más poderoso que visitar clientes inalámbricos y monitorear el rendimiento y las condiciones de error con un analizador portátil.

Si bien los problemas de sincronización de datos y configuración de dispositivos que enfrentan los usuarios de PDA están más naturalmente alineados con el equipo de soporte técnico que con el administrador de la red, no es difícil prever que en un futuro no muy lejano muchos de estos dispositivos evolucionarán desde ayudas independientes. para complementar las PC., en clientes de red completos.

Normalmente, los operadores de redes inalámbricas corporativas desalentarán (o deberían) el despliegue de sistemas demasiado abiertos en los que cualquier usuario dentro del alcance de la red con una tarjeta de interfaz compatible pueda acceder a todos los marcos de información del sistema. El protocolo de seguridad inalámbrico Wired Equivalent Privacy (WEP) proporciona autenticación de usuario, garantía de integridad y cifrado de datos, pero, como suele ser el caso, la seguridad perfecta dificulta el análisis de la causa raíz de los problemas de red. En redes WEP seguras, los diagnosticadores necesitan conocer las claves o contraseñas que protegen los activos de información y controlan el acceso al sistema. Al acceder en el modo de recibir todos los paquetes, el analizador de protocolos podrá ver todos los encabezados de las tramas, pero la información que contienen no tendrá sentido sin la presencia de claves.

Al diagnosticar enlaces de túnel, que muchos fabricantes denominan VPN de acceso remoto, los problemas encontrados son similares a los que se encuentran al analizar redes inalámbricas cifradas. Si el tráfico no pasa por el enlace tunelizado, la causa del problema no es fácil de determinar. Esto podría ser un error de autenticación, una falla en uno de los puntos finales o una congestión en la Internet pública. Tratar de utilizar un analizador de protocolos para detectar errores de alto nivel en el tráfico tunelizado sería un desperdicio de energía porque el contenido de los datos, así como los encabezados de la capa de red, transporte y aplicación están encriptados. En general, las medidas tomadas para mejorar la seguridad de las redes corporativas tienden a dificultar la identificación de problemas de resolución y rendimiento. Los cortafuegos, los servidores proxy y los sistemas de detección de intrusos pueden complicar aún más la localización de los problemas.

Por tanto, el problema del diagnóstico de redes informáticas es relevante y, en última instancia, el diagnóstico de averías es una tarea de gestión. Para la mayoría de los sistemas corporativos de misión crítica, las operaciones de recuperación prolongadas no son factibles, por lo que la única solución es utilizar dispositivos y procesos redundantes que puedan asumir las funciones necesarias inmediatamente después de que ocurra una falla. En algunas empresas, las redes siempre tienen un componente redundante adicional en caso de una falla primaria, es decir, n x 2 componentes, donde n es la cantidad de componentes primarios necesarios para proporcionar un rendimiento aceptable. Si el tiempo medio de reparación (MTTR) es lo suficientemente largo, es posible que se necesite incluso más redundancia. El punto es que el tiempo de resolución de problemas no es fácil de predecir y los costos significativos durante un período de recuperación impredecible son una señal de una mala gestión.

Para sistemas menos críticos, la redundancia puede no ser económicamente viable, en cuyo caso es prudente invertir en las herramientas más efectivas (y en capacitación) para acelerar el proceso de resolución de problemas y diagnóstico en la empresa. Además, el soporte subcontratado para sistemas específicos puede subcontratarse, ya sea subcontratado a la empresa, centros de datos externos o proveedores de servicios de aplicaciones (ASP) o proveedores de servicios de gestión. Además de los costos, el factor más importante que influye en la decisión de utilizar servicios de terceros es el nivel de competencia de su propio personal. Los administradores de red deben decidir si una función en particular está tan estrechamente ligada a las tareas específicas de la empresa que no se puede esperar que un especialista externo se desempeñe mejor que los empleados de la empresa.

Casi inmediatamente después de que se implementaron las primeras redes empresariales, cuya confiabilidad dejaba mucho que desear, los fabricantes y desarrolladores presentaron el concepto de "redes autorreparables". Las redes modernas son ciertamente más confiables que en los años 90, pero no porque los problemas comenzaran a resolverse por sí mismos. La eliminación de fallas de software y hardware en las redes actuales aún requiere la intervención humana, y no se prevé ningún cambio importante en esta situación en el corto plazo. Los métodos y herramientas de diagnóstico están en consonancia con la práctica y la tecnología actuales, pero aún no han alcanzado el nivel que ahorraría significativamente el tiempo de los administradores de red para tratar los problemas de red y la escasez de rendimiento.

1.1 Diagnóstico de software

Entre las herramientas de software para diagnosticar redes informáticas, se pueden destacar los sistemas especiales de gestión de red (Network Management Systems): sistemas de software centralizados que recopilan datos sobre el estado de los nodos y dispositivos de comunicación de la red, así como datos sobre el tráfico que circula en el la red. Estos sistemas no solo monitorean y analizan la red, sino que también realizan acciones de administración de red en modo automático o semiautomático - habilitando y deshabilitando puertos de dispositivos, cambiando los parámetros de puentes en las tablas de direcciones de puentes, conmutadores y enrutadores, etc. Ejemplos de sistemas de control son los sistemas populares HPOpenView, SunNetManager, IBMNetView.

Las herramientas de gestión del sistema realizan funciones similares a los sistemas de gestión, pero con respecto a los equipos de comunicación. Sin embargo, algunas de las funciones de estos dos tipos de sistemas de control se pueden duplicar, por ejemplo, los controles del sistema pueden realizar el análisis más simple del tráfico de la red.

Sistemas expertos. Este tipo de sistemas acumula conocimientos humanos sobre la identificación de las causas del funcionamiento anormal de las redes y las posibles formas de poner la red en un estado de funcionamiento. Los sistemas expertos a menudo se implementan como subsistemas separados de varias herramientas de análisis y monitoreo de redes: sistemas de administración de redes, analizadores de protocolos, analizadores de redes. La variante más simple de un sistema experto es un sistema de ayuda sensible al contexto. Los sistemas expertos más complejos son las llamadas bases de conocimiento con elementos de inteligencia artificial. Un ejemplo de tal sistema es el sistema experto integrado en el sistema de control Cabletron Spectrum.

1.1.1 Analizadores de protocolo

Durante el diseño de una red nueva o la modernización de una red antigua, a menudo es necesario cuantificar algunas características de la red, como la intensidad de los flujos de datos a través de las líneas de comunicación de la red, los retrasos que ocurren en varias etapas del procesamiento de paquetes, los tiempos de respuesta a las solicitudes. de un tipo u otro, la frecuencia de ocurrencia, ciertos eventos y otras características.

Para estos fines, se pueden utilizar varios medios y, en primer lugar, medios de monitoreo en los sistemas de gestión de red, que ya se han discutido anteriormente. Algunas mediciones en la red también se pueden realizar mediante medidores de software integrados en el sistema operativo, un ejemplo de lo cual es el componente Windows Performance Monitor. Incluso los probadores de cables modernos son capaces de capturar paquetes y analizar su contenido.

Pero la herramienta de exploración de redes más avanzada es un analizador de protocolos. El proceso de análisis de protocolo implica capturar y examinar los paquetes que están circulando en la red que implementan un protocolo de red en particular. Según los resultados del análisis, puede realizar cambios informados y equilibrados en cualquier componente de la red, optimizar su rendimiento y solucionar problemas. Evidentemente, para poder sacar alguna conclusión sobre el impacto de algún cambio en la red, es necesario analizar los protocolos tanto antes como después del cambio.

El analizador de protocolos es un dispositivo especializado independiente o una computadora personal, generalmente portátil, de la clase Нtebook, equipada con una tarjeta de red especial y el software apropiado. La tarjeta de red y el software utilizados deben corresponder a la topología de la red (anillo, bus, estrella). El analizador se conecta a la red de la misma forma que un nodo normal. La diferencia es que el analizador puede recibir todos los paquetes de datos transmitidos a través de la red, mientras que una estación ordinaria solo puede recibir aquellos dirigidos a ella. El software del analizador consta de un kernel que admite el funcionamiento del adaptador de red y decodifica los datos recibidos, y un código de programa adicional que depende del tipo de topología de la red bajo investigación. Además, se proporcionan varias rutinas de decodificación específicas del protocolo, como IPX. Algunos analizadores también pueden incluir un sistema experto que puede dar recomendaciones al usuario sobre qué experimentos deben realizarse en una situación determinada, qué pueden significar estos o aquellos resultados de medición y cómo eliminar algunos tipos de mal funcionamiento de la red.

A pesar de la relativa diversidad de analizadores de protocolos en el mercado, hay algunas características que son más o menos inherentes a todos ellos:

Interfaz de usuario. La mayoría de los analizadores tienen una interfaz fácil de usar bien desarrollada, generalmente basada en Windows o Motif. Esta interfaz permite al usuario: visualizar los resultados del análisis de la intensidad del tráfico; obtener una estimación estadística media e instantánea del rendimiento de la red; establecer eventos específicos y situaciones críticas para rastrear su ocurrencia; decodificar protocolos de diferentes niveles y presentar el contenido de los paquetes de forma comprensible.

Búfer de captura. Los tampones de los distintos analizadores difieren en tamaño. El búfer se puede ubicar en la tarjeta de red instalada o se le puede asignar espacio en la RAM de una de las computadoras de la red. Si el búfer está ubicado en una tarjeta de red, entonces se administra en hardware y, debido a esto, la velocidad de entrada aumenta. Sin embargo, esto conduce a un aumento en el costo del analizador. En caso de un desempeño insuficiente del procedimiento de captura, parte de la información se perderá y el análisis será imposible. El tamaño del búfer determina las capacidades de análisis para muestras más o menos representativas de los datos capturados. Pero no importa cuán grande sea el búfer de captura, tarde o temprano se llenará. En este caso, la captura se detiene o el llenado comienza desde el principio del búfer.

Filtros. Los filtros le permiten controlar el proceso de captura de datos y, por lo tanto, ahorrar espacio en el búfer. Dependiendo del valor de ciertos campos del paquete, especificado como condición de filtro, el paquete se ignora o se escribe en el búfer de captura. El uso de filtros acelera y simplifica enormemente el análisis, ya que excluye la visualización de los paquetes que no son necesarios en este momento.

Los conmutadores son algunas condiciones establecidas por el operador para iniciar y detener el proceso de captura de datos de la red. Estas condiciones pueden ser la ejecución de comandos manuales para iniciar y detener el proceso de captura, la hora del día, la duración del proceso de captura, la aparición de ciertos valores en los marcos de datos. Los interruptores se pueden usar junto con los filtros, lo que permite un análisis más detallado y sutil, así como un uso más productivo de un tamaño limitado del búfer de captura.

Buscar. Algunos analizadores de protocolos le permiten automatizar la visualización de información en el búfer y encontrar datos en él de acuerdo con criterios específicos. Mientras que los filtros verifican el flujo de entrada contra las condiciones de filtrado, las funciones de búsqueda se aplican a los datos ya acumulados en el búfer.

La metodología de análisis se puede presentar en las siguientes seis etapas:

Captura de datos.

Ver datos capturados.

Análisis de los datos.

Busque errores. (La mayoría de los analizadores facilitan esto al identificar los tipos de error e identificar la estación de la que proviene el paquete de error).

Investigación de desempeño. Se calcula la tasa de utilización del ancho de banda de la red o el tiempo medio de respuesta a una solicitud.

Un estudio detallado de secciones individuales de la red. El contenido de esta etapa se concreta a medida que se realiza el análisis.

Por lo general, el proceso de análisis de los protocolos lleva relativamente poco tiempo: entre 1 y 2 días hábiles.

La mayoría de los analizadores modernos le permiten analizar varios protocolos WAN a la vez, como X.25, PPP, SLIP, SDLC / SNA, frame relay, SMDS, ISDN, protocolos de puente / enrutador (3Com, Cisco, Bay Networks y otros). Dichos analizadores le permiten medir varios parámetros de protocolos, analizar el tráfico de red, conversión entre protocolos LAN y WAN, retrasos en los enrutadores durante estas conversiones, etc. Los dispositivos más avanzados brindan la capacidad de simular y decodificar protocolos WAN, pruebas de "estrés", mediciones ancho de banda máximo, probando la calidad de los servicios prestados. En aras de la versatilidad, casi todos los analizadores de protocolo WAN implementan pruebas de LAN y todas las interfaces principales. Algunos instrumentos son capaces de analizar protocolos de telefonía. Y los modelos más avanzados pueden decodificar y representar convenientemente las siete capas OSI. La llegada de ATM ha llevado a los fabricantes a suministrar a sus analizadores herramientas de prueba para estas redes. Estos instrumentos pueden realizar pruebas completas de redes ATM E-1 / E-3 con soporte de monitoreo y simulación. El conjunto de funciones de servicio del analizador es muy importante. Algunos de ellos, por ejemplo, la capacidad de controlar remotamente el dispositivo, son simplemente insustituibles.

Así, los analizadores modernos de protocolos WAN / LAN / DTM pueden detectar errores en la configuración de enrutadores y puentes; establecer el tipo de tráfico enviado a través de la WAN; determinar el rango de velocidades utilizado, optimizar la relación entre el ancho de banda y el número de canales; localizar la fuente del tráfico incorrecto; realizar pruebas de interfaz en serie y pruebas ATM completas; realizar un seguimiento completo y decodificación de los principales protocolos en cualquier canal; analizar estadísticas en tiempo real, incluido el análisis del tráfico de la red de área local a través de redes globales.

1.1.2 Protocolos de monitoreo

SNMP (Protocolo simple de administración de redes) es un protocolo de administración de redes de comunicación basado en la arquitectura TCP / IP.

Basado en el concepto TMN en 1980-1990 varios organismos de normalización han desarrollado una serie de protocolos para la gestión de redes de datos con un espectro diferente de implementación de funciones de la RGT. Un tipo de protocolo de gestión de este tipo es SNMP. SNMP se desarrolló para probar la funcionalidad de enrutadores y puentes de red. Posteriormente, el alcance del protocolo se extendió a otros dispositivos de red como hubs, puertas de enlace, servidores de terminales, servidores LAN Manager, máquinas con Windows NT, etc. Además, el protocolo permite la posibilidad de realizar cambios en el funcionamiento de estos dispositivos.

Esta tecnología está diseñada para proporcionar administración y control sobre dispositivos y aplicaciones en una red de comunicación mediante el intercambio de información de control entre agentes ubicados en dispositivos de red y administradores ubicados en estaciones de control. SNMP define una red como una colección de estaciones de administración de red y elementos de red (hosts, puertas de enlace y enrutadores, servidores de terminales) que colectivamente proporcionan enlaces administrativos entre las estaciones de administración de red y los agentes de red.

Con SNMP, existen sistemas administrados y supervisados. Un sistema administrado incluye un componente llamado agente que envía informes al sistema de administración. Esencialmente, los agentes SNMP transmiten información de gestión a los sistemas de gestión como variables (como "memoria libre", "nombre del sistema", "número de procesos en ejecución").

El agente SNMP es un elemento de procesamiento que proporciona a los administradores ubicados en las estaciones de administración de la red acceso a los valores de las variables MIB y, por lo tanto, les permite implementar las funciones de administración y monitoreo del dispositivo.

Un agente de software es un programa residente que realiza funciones de gestión, además de recopilar estadísticas para transferirlas a la base de información de un dispositivo de red.

Agente de hardware: hardware integrado (con procesador y memoria) que almacena agentes de software.

Las variables accesibles a través de SNMP están organizadas en una jerarquía. Estas jerarquías y otros metadatos (como el tipo y la descripción de una variable) son descritos por las bases de información de gestión (MIB).

Hoy en día existen varios estándares para las bases de datos de información de control. Los principales son los estándares MIB-I y MIB-II, así como la versión RMON MIB de la base de datos para gestión remota. Además, existen estándares para dispositivos MIB específicos de un tipo particular (por ejemplo, MIB para concentradores o MIB para módems), así como MIB patentados de fabricantes de equipos específicos.

La especificación MIB-I original solo definía operaciones de lectura en valores variables. Las operaciones de cambiar o establecer los valores de un objeto son parte de las especificaciones MIB-II.

La versión MIB-I (RFC 1156) define hasta 114 objetos, que se clasifican en 8 grupos:

Sistema: información general sobre el dispositivo (por ejemplo, ID de proveedor, hora de la última inicialización del sistema).

Interfaces: describe los parámetros de las interfaces de red del dispositivo (por ejemplo, su número, tipos, tipos de cambio, tamaño máximo de paquete).

AddressTranslationTable: describe la correspondencia entre la red y las direcciones físicas (por ejemplo, utilizando el protocolo ARP).

InternetProtocol: datos relacionados con el protocolo IP (direcciones de puertas de enlace IP, hosts, estadísticas sobre paquetes IP).

ICMP: datos relacionados con el protocolo de intercambio de mensajes de control ICMP.

TCP: datos relacionados con el protocolo TCP (por ejemplo, sobre conexiones TCP).

UDP: datos relacionados con el protocolo UDP (número de datagramas UPD transmitidos, recibidos y erróneos).

EGP: datos relacionados con el protocolo de intercambio de enrutamiento de ExteriorGatewayProtocol utilizado en Internet (la cantidad de mensajes recibidos con y sin errores).

De esta lista de grupos de variables, se puede ver que el estándar MIB-I se desarrolló con un enfoque rígido en la administración de enrutadores que admiten los protocolos de pila TCP / IP.

En la versión MIB-II (RFC 1213), adoptada en 1992, el conjunto de objetos estándar se amplió significativamente (a 185) y el número de grupos aumentó a 10.

Agentes RMON

La última incorporación a la funcionalidad SNMP es la especificación RMON, que proporciona comunicación remota con la MIB.

El estándar RMON surgió en noviembre de 1991 cuando el Grupo de trabajo de ingeniería de Internet emitió el RFC 1271 titulado "Base de información de administración de monitoreo de red remota". Este documento contenía una descripción de RMON para redes Ethernet: un protocolo de monitoreo de redes informáticas, una extensión SNMP que, como SNMP, se basa en la recopilación y análisis de información sobre la naturaleza de la información transmitida a través de la red. Al igual que en SNMP, la recogida de información la realizan agentes hardware y software, cuyos datos se envían al ordenador donde está instalada la aplicación de gestión de red. La diferencia entre RMON y su predecesor radica, en primer lugar, en la naturaleza de la información recopilada: si en SNMP esta información caracteriza solo los eventos que ocurren en el dispositivo donde está instalado el agente, entonces RMON requiere los datos recibidos para caracterizar el tráfico entre la red. dispositivos.

Antes de RMON, SNMP no se podía usar de forma remota, solo permitía la administración local de dispositivos. El RMON MIB tiene un conjunto mejorado de propiedades para la gestión remota, ya que contiene información agregada sobre el dispositivo, que no requiere la transferencia de grandes cantidades de información a través de la red. Los objetos RMON MIB incluyen contadores de errores de paquetes adicionales, análisis de estadísticas y tendencias gráficas más flexibles, herramientas de filtrado más poderosas para capturar y analizar paquetes individuales y condiciones de alerta más complejas. Los agentes RMON MIB son más inteligentes que los agentes MIB-I o MIB-II y realizan gran parte del trabajo de procesamiento de la información del dispositivo que solían hacer los gerentes. Estos agentes se pueden ubicar dentro de varios dispositivos de comunicación y también se pueden ejecutar en forma de módulos de software separados que se ejecutan en PC y portátiles universales (un ejemplo es LANalyzerНvell).

La inteligencia de los agentes RMON les permite realizar acciones simples para diagnosticar fallas y alertar sobre posibles fallas; por ejemplo, utilizando la tecnología RMON, puede recopilar datos sobre el funcionamiento normal de la red (es decir, realizar la llamada línea base), y luego, emite alertas cuando el modo de funcionamiento de la red se desvía de la línea de base; esto puede indicar, en particular, que el equipo no está completamente operativo. Al reunir información de los agentes RMON, la aplicación de gestión puede ayudar a un administrador de red (ubicado, por ejemplo, a miles de kilómetros del segmento de red analizado) a localizar un problema y desarrollar un plan de acción óptimo para solucionarlo.

La recopilación de información RMON se lleva a cabo mediante sondas de hardware y software que están conectadas directamente a la red. Para realizar la tarea de recopilación y análisis primario de datos, la sonda debe tener suficientes recursos informáticos y la cantidad de RAM. Hay tres tipos de sondas actualmente en el mercado: integradas, basadas en computadora y autónomas. Un producto se considera compatible con RMON si implementa al menos un grupo RMON. Por supuesto, cuantos más grupos de datos RMON se implementen en un producto determinado, más caro será, por un lado, y, por otro lado, más información completa sobre el funcionamiento de la red que proporciona.

Las sondas integradas son módulos de expansión para dispositivos de red. Estos módulos están disponibles en muchos fabricantes, incluidas empresas importantes como 3Com, Cabletron, Bay Networks y Cisco. (Por cierto, 3Com y Bay Networks adquirieron recientemente Axon y ARMON, líderes reconocidos en el diseño y fabricación de controles RMON. El interés en esta tecnología de los principales fabricantes de equipos de red demuestra aún más la cantidad de monitoreo remoto que necesitan los usuarios). Los módulos RMON en concentradores parecen naturales, porque es a partir de la observación de estos dispositivos que uno puede formarse una idea del funcionamiento del segmento. La ventaja de tales sondas es obvia: permiten obtener información sobre todos los principales grupos de datos de RMON a un precio relativamente bajo. La desventaja, en primer lugar, no es un rendimiento muy alto, que se manifiesta, en particular, en el hecho de que las sondas integradas a menudo no son compatibles con todos los grupos de datos RMON. 3Com anunció recientemente su intención de lanzar controladores compatibles con RMON para adaptadores de red Etherlink III y Fast Ethernet. Como resultado, será posible recopilar y analizar datos RMON directamente en las estaciones de trabajo de la red.

Las sondas basadas en computadora son simplemente computadoras en red que tienen instalado el agente de software RMON. Estas sondas (que incluyen, por ejemplo, Cornerstone Agent 2.5 de Network General) ofrecen un mejor rendimiento que las sondas integradas y generalmente admiten todos los conjuntos de datos RMON. Son más caras que las sondas integradas, pero mucho menos caras que las sondas independientes. Además, las sondas basadas en computadora son bastante grandes, lo que a veces puede limitar su aplicabilidad.

Las sondas independientes son las de mejor rendimiento; como es fácil de entender, son a la vez los productos más caros de todos los descritos. Normalmente, una sonda independiente es un procesador (clase i486 o procesador RISC) equipado con suficiente RAM y un adaptador de red. Los líderes del mercado en este sector son Frontier y Hewlett-Packard. Las sondas de este tipo son de tamaño pequeño y muy móviles; son muy fáciles de conectar y desconectar de la red. A la hora de resolver el problema de gestionar una red de escala global, esto, por supuesto, no es una propiedad muy importante, pero si se utilizan herramientas RMON para analizar el funcionamiento de una red corporativa de tamaño medio, entonces (dado el alto coste de dispositivos) la movilidad de las sondas puede jugar un papel muy positivo.

El objeto RMON tiene el número 16 en el conjunto de objetos MIB, y el objeto RMON en sí está empaquetado de acuerdo con RFC 1271, consta de diez grupos de datos.

Estadísticas: estadísticas acumuladas actuales sobre las características de los paquetes, el número de colisiones, etc.

Historial: datos estadísticos guardados a intervalos regulares para el análisis posterior de las tendencias en sus cambios.

Alarmas: umbrales estadísticos por encima de los cuales el agente RMON envía un mensaje al gerente. Permite al usuario definir un número de niveles de umbral (estos umbrales pueden referirse a una variedad de cosas - cualquier parámetro del grupo de estadísticas, su amplitud o tasa de cambio, y mucho más), al excederlo se genera una alarma. El usuario también puede determinar en qué condiciones la superación del valor de umbral debe ir acompañada de una señal de alarma; esto evitará generar una señal "por bagatelas", lo cual es malo, en primer lugar, porque nadie presta atención a la luz roja que se enciende constantemente. y, en segundo lugar, porque la transmisión de alarmas innecesarias a través de la red conduce a una congestión innecesaria de las líneas de comunicación. Por lo general, una alarma se transmite a un grupo de eventos, donde se determina qué hacer con ella a continuación.

Host: datos sobre los hosts de la red, incluidas sus direcciones MAC.

HostTopN es una tabla de los hosts más ocupados de la red. La tabla de hosts Host N (HostTopN) contiene una lista de los N hosts principales con el valor más alto de la estadística especificada para el intervalo especificado. Por ejemplo, puede solicitar una lista de 10 hosts que han experimentado el número máximo de errores en las últimas 24 horas. Esta lista será compilada por el propio agente, y la aplicación de gestión recibirá solo las direcciones de estos hosts y los valores de los parámetros estadísticos correspondientes. Se puede ver hasta qué punto este enfoque ahorra recursos de red.

TrafficMatrix: estadísticas sobre la intensidad del tráfico entre cada par de hosts de la red, ordenadas en una matriz. Las filas de esta matriz se numeran de acuerdo con las direcciones MAC de las estaciones - las fuentes de los mensajes y las columnas - de acuerdo con las direcciones de las estaciones receptoras. Los elementos de la matriz caracterizan la intensidad del tráfico entre las respectivas estaciones y el número de errores. Una vez analizada dicha matriz, el usuario puede averiguar fácilmente qué pares de estaciones generan el tráfico más intenso. Esta matriz, nuevamente, está formada por el propio agente, por lo que no es necesario transferir grandes cantidades de datos a una computadora central responsable de la gestión de la red.

Filtro: condiciones de filtrado de paquetes. Los criterios por los cuales se filtran los paquetes pueden ser muy diversos; por ejemplo, puede solicitar que se filtren como erróneos todos los paquetes cuya longitud sea menor que un cierto valor especificado. Podemos decir que la instalación del filtro corresponde, por así decirlo, a la organización del canal de transmisión del paquete. El usuario determina a dónde conduce este canal. Por ejemplo, todos los paquetes erróneos se pueden interceptar y enviar al búfer apropiado. Además, la aparición de un paquete que coincida con el filtro establecido puede verse como un evento al que el sistema debe reaccionar de una manera predeterminada.

PacketCapture: condiciones para capturar paquetes. Un grupo de captura de paquetes incluye búferes de captura, donde se envían paquetes cuyas características satisfacen las condiciones establecidas en el grupo de filtro. En este caso, no se puede capturar todo el paquete, sino, digamos, solo las primeras decenas de bytes del paquete. El contenido de los búferes de interceptación se puede analizar posteriormente utilizando varias herramientas de software, revelando una serie de características muy útiles de la red. Al reorganizar los filtros para ciertos signos, es posible caracterizar diferentes parámetros del funcionamiento de la red.

Evento: condiciones para registrar y generar eventos. El grupo de eventos define cuándo enviar una alarma a la aplicación de gestión, cuándo interceptar paquetes y, en general, cómo responder a ciertos eventos que ocurren en la red, por ejemplo, si se superan los umbrales establecidos en el grupo de alarmas: si establecer se notifica a la aplicación de control, o simplemente debe registrar este evento y continuar trabajando. Los eventos pueden o no estar relacionados con la transmisión de alarmas; por ejemplo, enviar un paquete al búfer de captura también es un evento.

Estos grupos están numerados en el orden que se muestra, por lo que, por ejemplo, el grupo Hosts tiene el nombre numérico 1.3.6.1.2.1.16.4.

El décimo grupo consta de objetos especiales del protocolo TokenRing.

En total, el estándar RMON MIB define alrededor de 200 objetos en 10 grupos, registrados en dos documentos: RFC 1271 para redes Ethernet y RFC 1513 para redes TokenRing.

Una característica distintiva del estándar RMON MIB es su independencia del protocolo de capa de red (a diferencia de los estándares MIB-I y MIB-II, orientados a los protocolos TCP / IP). Por lo tanto, es conveniente utilizarlo en entornos heterogéneos utilizando diferentes protocolos de capa de red.

1.2 Sistemas de gestión de redes populares

Sistema de administración de red: herramientas de hardware y / o software para monitorear y administrar nodos de red. El software del sistema de gestión de red consta de agentes localizados en dispositivos de red y que transmiten información a la plataforma de gestión de red. El método de comunicación entre las aplicaciones de gestión y los agentes en los dispositivos está determinado por protocolos.

Los sistemas de gestión de redes deben tener una serie de cualidades:

verdadera distribución de acuerdo con el concepto cliente / servidor,

escalabilidad

apertura para hacer frente a hardware dispar, desde computadoras de escritorio hasta mainframes.

Las dos primeras propiedades están estrechamente relacionadas. Se logra una buena escalabilidad gracias al sistema de control distribuido. Distribuido significa que un sistema puede incluir varios servidores y clientes. Los servidores (administradores) recopilan datos sobre el estado actual de la red de los agentes (SNMP, CMIP o RMON) integrados en el equipo de red y los acumulan en su base de datos. Los clientes son consolas gráficas ejecutadas por administradores de red. El software del cliente del sistema de gestión acepta solicitudes para realizar cualquier acción del administrador (por ejemplo, construir un mapa detallado de una parte de la red) y solicita la información necesaria del servidor. Si el servidor tiene la información necesaria, inmediatamente la transmite al cliente, si no, intenta recopilarla de los agentes.

Las primeras versiones de los sistemas de control combinaban todas las funciones en una computadora, que estaba a cargo de un administrador. Para redes pequeñas o redes con una pequeña cantidad de equipos controlados, dicha estructura resulta bastante satisfactoria, pero con una gran cantidad de equipos controlados, la única computadora a la que fluye la información de todos los dispositivos de la red se convierte en un cuello de botella. Y la red no puede hacer frente al gran flujo de datos, y la propia computadora no tiene tiempo para procesarlos. Además, una red grande generalmente es administrada por más de un administrador, por lo tanto, además de varios servidores en una red grande, debe haber varias consolas para administradores de red, y cada consola debe proporcionar información específica correspondiente a las necesidades actuales de una red. administrador particular.

El soporte para equipos diferentes es una característica deseable más que una característica de la vida real de los sistemas de control actuales. Los productos de gestión de red más populares incluyen cuatro sistemas: Spectrum de CabletronSystems, OpenView de Hewlett-Packard, NetView de IBM y Solstice de SunSoft, una división de SunMicrosystems. Tres de cada cuatro empresas producen ellos mismos equipos de comunicación. Naturalmente, Spectrum administra mejor los equipos de Cabletron, OpenView controla los equipos de Hewlett-Packard y NetView controla los equipos de IBM.

Al construir un mapa de red, que consta de equipos de otros fabricantes, estos sistemas comienzan a cometer errores y toman un dispositivo por otro, y al administrar estos dispositivos, solo admiten sus funciones básicas y muchas funciones adicionales útiles que distinguen a este dispositivo de el resto, el sistema de control es simple, no los entiende y por tanto no los puede utilizar.

Para remediar esta deficiencia, los desarrolladores de sistemas de gestión incluyen soporte no solo para las MIB estándar I, MIB II y RMON MIB, sino también para numerosas MIB patentadas de los fabricantes. El líder en esta área es el sistema Spectrum, que admite alrededor de 1000 MIB de varios fabricantes.

Otra forma de brindar un mejor soporte a un hardware específico es utilizar una aplicación basada en una plataforma de control de la empresa que produce este hardware. Compañías líderes - fabricantes de equipos de comunicación - han desarrollado y suministran sistemas de control altamente sofisticados y multifuncionales para sus equipos. Los sistemas más famosos de esta clase incluyen Optivity de BayNetworks, CiscoWorks de CiscoSystems, Transcend de 3Com. Optivity, por ejemplo, le permite monitorear y administrar redes de enrutadores, conmutadores y concentradores de BayNetwork, aprovechando al máximo sus capacidades y características. Los equipos de otros fabricantes se mantienen al nivel de las funciones de control básicas. Optivity se ejecuta en OpenView y SunNetManager de Hewlett-Packard (predecesor de Solstice) de SunSoft. Sin embargo, ejecutar en cualquier plataforma de administración con múltiples sistemas, como Optivity, es demasiado complejo y requiere que las computadoras en las que se ejecutará tengan procesadores muy potentes y mucha RAM.

Sin embargo, si la red está dominada por equipos de un solo fabricante, la disponibilidad de aplicaciones de gestión de ese fabricante para una plataforma de gestión popular permite a los administradores de red resolver con éxito muchos problemas. Por lo tanto, los desarrolladores de plataformas de control envían con ellos herramientas que simplifican el desarrollo de aplicaciones, y la disponibilidad de dichas aplicaciones y su número se considera un factor muy importante en la elección de una plataforma de control.

La apertura de la plataforma de gestión también depende de cómo se almacenan los datos de estado de la red recopilados. La mayoría de las plataformas líderes permiten que los datos se almacenen en bases de datos comerciales como Oracle, Ingres o Informix. El uso de DBMS universal reduce la velocidad del sistema de control en comparación con el almacenamiento de datos en los archivos del sistema operativo, pero permite procesar estos datos por cualquier aplicación que pueda trabajar con estos DBMS.

2. EXPOSICIÓN DEL PROBLEMA

De acuerdo con la situación actual, se decidió desarrollar e implementar un sistema de monitoreo de red que resolvería todos los problemas anteriores.

2.1 Términos de referencia

Desarrollar e implementar un sistema de monitoreo que permita monitorear tanto conmutadores, enrutadores de diferentes fabricantes, como servidores de diferentes plataformas. Céntrese en el uso de protocolos y sistemas abiertos, con el máximo aprovechamiento de los desarrollos prefabricados del fondo de software libre.

2.2 Términos de referencia actualizados

En el curso de la formulación adicional del problema y la investigación del área temática, teniendo en cuenta las inversiones económicas y de tiempo, se aclaró la tarea técnica:

El sistema debe cumplir los siguientes requisitos:

§ requisitos mínimos de recursos de hardware;

§ códigos de fuente abierta de todos los componentes del complejo;

§ extensibilidad y escalabilidad del sistema;

§ medios estándar para proporcionar información de diagnóstico;

§ disponibilidad de documentación detallada para todos los productos de software utilizados;

§ capacidad para trabajar con equipos de diferentes fabricantes.

3. SISTEMA PROPUESTO

1 Elección de un sistema de monitoreo de red

De acuerdo con los términos de referencia actualizados, el sistema Nagios es el más adecuado como núcleo del sistema de monitoreo de red, ya que tiene las siguientes cualidades:

§ se encuentran disponibles herramientas para generar diagramas;

§ existen herramientas de informes;

§ existe la posibilidad de agrupación lógica;

§ hay un sistema incorporado para registrar tendencias y predecirlas;

§ es posible agregar automáticamente nuevos dispositivos (Autodiscovery) usando el complemento oficial;

§ existe la posibilidad de un seguimiento avanzado del host mediante un agente;

§ Compatibilidad con el protocolo SNMP a través de un complemento;

§ Compatibilidad con el protocolo Syslog a través de un complemento;

§ soporte para scripts externos;

§ soporte para complementos auto-escritos y la capacidad de crearlos rápida y fácilmente;

§ activadores y eventos integrados;

§ interfaz web con todas las funciones;

§ la posibilidad de monitoreo distribuido;

§ inventario a través de un complemento;

§ la capacidad de almacenar datos tanto en archivos como en bases de datos SQL, lo cual es muy importante al aumentar los volúmenes;

§ Licencia GPL y, por lo tanto, entrega básica gratuita, soporte y códigos de fuente abierta del núcleo del sistema y los componentes que lo acompañan;

§ mapas dinámicos y personalizables;

§ control de acceso;

§ lenguaje incorporado para describir hosts, servicios y comprobaciones;

§ la capacidad de rastrear usuarios.

El sistema de monitoreo de red Zabbix tiene un conjunto similar de parámetros, pero en el momento de la implementación tenía mucha menos funcionalidad que Nagios y tenía un estado de versión beta. Además, un estudio de foros temáticos y fuentes de noticias mostró que Nagios es más frecuente entre los usuarios, lo que significa la presencia de documentación escrita por el usuario y la descripción más detallada de los puntos difíciles en la configuración.

Nagios le permite monitorear servicios de red como SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP y muchos otros. Además, puede supervisar el uso de los recursos del servidor, como el consumo de espacio en disco, la memoria libre y la utilización del procesador. Es posible crear sus propios controladores de eventos. Estos controladores se ejecutarán cuando se produzcan determinados eventos desencadenados por comprobaciones de servicios o servidores. Este enfoque le permitirá responder activamente a los eventos en curso e intentar resolver automáticamente los problemas que hayan surgido. Por ejemplo, puede crear un controlador de eventos que reiniciará automáticamente un servicio pendiente. Otra ventaja del sistema de monitoreo de Nagios es la capacidad de controlarlo de forma remota utilizando la interfaz wap de un teléfono móvil. Utilizando el concepto de hosts "principales", es fácil describir la jerarquía y las dependencias entre todos los hosts. Este enfoque es extremadamente útil para redes grandes porque permite diagnósticos complejos. Y esta cualidad, a su vez, ayuda a distinguir los hosts que no funcionan de los que no están disponibles en este momento debido a fallas en el funcionamiento de los enlaces intermedios. Nagios puede construir gráficos de sistemas monitoreados y mapas de infraestructura de red monitoreada.

A partir de su práctica de trabajar con Nagios, el autor puede dar un ejemplo que muestre lo útil que fue para su práctica personal. La pérdida de paquetes comenzó en la interfaz de red externa del firewall a intervalos de varias horas. Debido a un mal funcionamiento, se perdió hasta el 20 por ciento del tráfico que pasaba. Después de un minuto, la otra interfaz comenzó a funcionar nuevamente como se esperaba. Debido a la naturaleza flotante de este problema, no fue posible durante varias semanas averiguar por qué ocurren las interrupciones intermitentes al usar Internet. Sin Nagios, la resolución de problemas llevaría mucho tiempo.

Muchos administradores están familiarizados con el ancestro NetSaint de Nagios. Aunque el sitio del proyecto NetSaint todavía está en funcionamiento, los nuevos desarrollos se basan en el código fuente de Nagios. Por lo tanto, se recomienda a todos que se pasen lentamente a Nagios.

La documentación suministrada con Nagios indica que funcionará de forma estable con muchos otros sistemas similares a Unix. Para mostrar la interfaz web de Nagios, necesitamos un servidor Apache. Puede utilizar cualquier otro, pero en este trabajo consideraremos a Apache como el servidor web más extendido en plataformas Unix. Es posible instalar un sistema de monitoreo sin una interfaz web en absoluto, pero no lo haremos, porque esto reduce significativamente la usabilidad.

4. DESARROLLO DE SOFTWARE

Como parte del hardware del sistema que se está implementando, puede usar una computadora normal compatible con IBM, sin embargo, teniendo en cuenta la posibilidad de aumentar aún más la carga y los requisitos de confiabilidad y MTBF, así como GosvyazNadzor, se incluyó un equipo de servidor certificado de Aquarius. comprado.

La red existente utiliza activamente el sistema operativo Debian basado en el kernel de Linux, tiene una amplia experiencia en el uso de este sistema, depuró la mayoría de las operaciones para administrar, configurar y asegurar su estabilidad. Además, este SO se distribuye bajo la licencia GPL, lo que significa que es libre y de código abierto, lo que corresponde a los términos de referencia actualizados para el diseño de un sistema de monitoreo de red. ́ nux ", también en algunos lenguajes" GNU + Linux "," GNU-Linux ", etc.) es el nombre general para sistemas operativos tipo UNIX basados ​​en el kernel del mismo nombre y bibliotecas y programas de sistema compilados para él, desarrollados en el marco del proyecto GNU. / Linux se ejecuta en sistemas compatibles con PC de la familia Intel x86, así como en IA-64, AMD64, PowerPC, ARM y muchos otros.

El sistema operativo GNU / Linux también incluye a menudo programas que complementan este sistema operativo y aplicaciones que lo convierten en un entorno operativo multifuncional completo.

A diferencia de la mayoría de los otros sistemas operativos, GNU / Linux no viene con un solo paquete "oficial". En cambio, GNU / Linux viene en una gran cantidad de las denominadas distribuciones en las que los programas GNU están vinculados al kernel de Linux y otros programas. Las distribuciones GNU / Linux más famosas son Ubuntu, Debian GNU / Linux, Red Hat, Fedora, Mandriva, SuSE, Gentoo, Slackware, Archlinux. Distribuciones rusas: ALT Linux y ASPLinux.

A diferencia de Microsoft Windows (Windows NT), Mac OS (Mac OS X) y los sistemas comerciales tipo UNIX, GNU / Linux no tiene un centro geográfico de desarrollo. No hay ninguna organización que sea propietaria de este sistema; ni siquiera hay un solo punto focal. El software Linux es el resultado de miles de proyectos. Algunos de estos proyectos están centralizados, otros se concentran en empresas. Muchos proyectos reúnen a piratas informáticos de todo el mundo que solo conocen por correspondencia. Cualquiera puede crear su propio proyecto o unirse a uno existente y, si tiene éxito, los resultados del trabajo serán conocidos por millones de usuarios. Los usuarios participan en las pruebas de software gratuito, se comunican directamente con los desarrolladores, lo que les permite encontrar y corregir errores rápidamente e implementar nuevas funciones.

La historia del desarrollo de sistemas UNIX. GNU / Linux es compatible con UNIX, pero se basa en su propio código fuente

Es este sistema de desarrollo flexible y dinámico que es imposible para proyectos de código cerrado lo que determina la excepcional rentabilidad de [fuente no especificada 199 días] GNU / Linux. El bajo costo del desarrollo libre, los mecanismos de prueba y distribución optimizados, la participación de personas de diferentes países con diferentes visiones de los problemas, la protección del código bajo la licencia GPL, todo esto se ha convertido en la razón del éxito del software libre.

Por supuesto, una eficiencia de desarrollo tan alta no podía dejar de interesar a las grandes empresas que comenzaban a abrir sus proyectos. Así apareció Mozilla (Netscape, AOL), OpenOffice.org (Sun), un clon gratuito de Interbase (Borland) - Firebird, SAP DB (SAP). IBM ha sido fundamental en la adaptación de GNU / Linux a sus mainframes.

Por otro lado, el código abierto reduce significativamente el costo de desarrollo de sistemas cerrados para GNU / Linux y le permite reducir el costo de la solución para el usuario. Es por eso que GNU / Linux se ha convertido en la plataforma recomendada a menudo para productos como Oracle, DB2, Informix, SyBase, SAP R3, Domino.

La comunidad GNU / Linux mantiene la comunicación a través de grupos de usuarios de Linux.

La mayoría de los usuarios utilizan distribuciones para instalar GNU / Linux. Un kit de distribución no es solo un conjunto de programas, sino una serie de soluciones para diversas tareas de usuario, unidas por sistemas uniformes para instalar, administrar y actualizar paquetes, configurar y dar soporte.

Las distribuciones más extendidas en el mundo son: - un kit de distribución de rápida popularidad que se centra en la facilidad de aprendizaje y uso - una versión de distribución gratuita del kit de distribución SuSE, propiedad de Novell. Es fácil de configurar y mantener gracias al uso de la utilidad YaST. - Apoyado por la comunidad y la corporación RedHat, es anterior a la versión comercial de RHEL. GNU / Linux es una distribución internacional, desarrollada por una extensa comunidad de desarrolladores para fines no comerciales. Sirvió como base para muchas otras distribuciones. Se diferencia en un enfoque estricto para la inclusión de software no libre. - Distribución franco-brasileña, una fusión de la antigua Mandrake y Conectiva (inglés). - Una de las distribuciones más antiguas, caracterizada por un enfoque conservador de desarrollo y uso. - Una distribución que se construye a partir de códigos fuente. Permite una configuración muy flexible del sistema final y la optimización del rendimiento, por lo que a menudo se denomina metadistribución. Dirigida a expertos y usuarios avanzados: orientada hacia el software más reciente y constantemente actualizada, compatible con binarios y con la instalación desde la fuente y basada en la filosofía de simplicidad de KISS, esta distribución está dirigida a usuarios expertos que desean plena potencia y capacidad de modificación de Linux, pero no sacrificando el tiempo de mantenimiento.

Además de las enumeradas, hay muchas otras distribuciones, ambas basadas en las enumeradas y creadas desde cero y, a menudo, diseñadas para realizar un número limitado de tareas.

Cada uno de ellos tiene su propio concepto, su propio conjunto de paquetes, sus propias ventajas y desventajas. Ninguno de ellos puede satisfacer a todos los usuarios, por lo que otras firmas y asociaciones de programadores conviven felizmente con los líderes, ofreciendo sus soluciones, sus distribuciones y sus servicios. Hay muchos LiveCD construidos sobre GNU / Linux, como Knoppix. LiveCD le permite ejecutar GNU / Linux directamente desde un CD, sin instalarlo en un disco duro.

Para aquellos que quieran comprender a fondo GNU / Linux, cualquiera de las distribuciones es adecuada, sin embargo, con bastante frecuencia se utilizan para este propósito las denominadas distribuciones basadas en fuentes, es decir, aquellas que implican el autoensamblaje de todo (o parte) de los componentes de los códigos fuente, como LFS, Gentoo, ArchLinux o CRUX.

4.1 Instalación del kernel del sistema

Nagios se puede instalar de dos formas: desde el código fuente y desde los paquetes compilados. Ambos métodos tienen ventajas y desventajas, veámoslos.

Ventajas de instalar un paquete de sus códigos fuente:

§ la capacidad de configurar el sistema en detalle;

§ alto grado de optimización de la aplicación;

§ la presentación más completa del programa.

Contras de instalar un paquete de sus códigos fuente:

§ se requiere tiempo adicional para ensamblar el paquete, a menudo excediendo el tiempo para su configuración y puesta en servicio;

§ la imposibilidad de eliminar el paquete junto con los archivos de configuración;

§ la imposibilidad de actualizar el paquete junto con los archivos de configuración;

§ imposibilidad de control centralizado sobre las aplicaciones instaladas.

Cuando instala Nagios desde un paquete prediseñado, las ventajas de un método de instalación sin formato se convierten en desventajas y viceversa. Sin embargo, como ha demostrado la práctica, un paquete preensamblado cumple con todos los requisitos del sistema y no tiene sentido perder el tiempo construyendo el paquete manualmente.

Dado que ambos métodos de instalación se probaron inicialmente, consideraremos cada uno de ellos con más detalle.

4.1.1 Descripción de la instalación del kernel del sistema y los códigos fuente

Paquetes requeridos.

Debe asegurarse de que los siguientes paquetes estén instalados antes de implementar Nagios. Una consideración detallada del proceso de su instalación está más allá del alcance de este trabajo.

· Apache 2

· PHP

· Bibliotecas para desarrolladores y compiladores de GCC

· Bibliotecas para desarrolladores de GD

Puede usar la utilidad apt-get (mejor aptitud) para instalarlos de la siguiente manera:

% sudo apt-get install apache2

% sudo apt-get install libapache2-mod-php5

% sudo apt-get install build-essential

% sudo apt-get install libgd2-dev

1) Cree una nueva cuenta de usuario sin privilegios

Se crea una nueva cuenta para ejecutar el servicio Nagios. También puede hacer esto con la cuenta de superusuario, lo que supondrá una seria amenaza para la seguridad del sistema.

Conviértete en superusuario:

Cree una nueva cuenta de usuario de nagios y asígnele una contraseña:

# / usr / sbin / useradd -m -s / bin / bash nagios

# passwd nagios

Cree un grupo de nagios y agregue el usuario de nagios a él:

# / usr / sbin / groupadd nagios

# / usr / sbin / usermod -G nagios nagios

Creemos un grupo nagcmd para permitir la ejecución de comandos externos enviados a través de la interfaz web. Agregue usuarios de nagios y apache a este grupo:

# / usr / sbin / groupadd nagcmd

# / usr / sbin / usermod -a -G nagcmd nagios

# / usr / sbin / usermod -a -G nagcmd www-data

2) Descarga Nagios y sus complementos

Cree un directorio para almacenar archivos descargados:

# mkdir ~ / descargas

# cd ~ / descargas

Descargue la fuente comprimida para Nagios y sus complementos (# "justify"> # wget # "justify"> # wget # "justify"> 3) Compile e instale Nagios

Analicemos los códigos fuente comprimidos de Nagios:

# cd ~ / descargas

# tar xzf nagios-3.2.0.tar.gz

# cd nagios-3.2.0

Ejecutamos el script de configuración de Nagios, pasándole el nombre del grupo que creamos anteriormente:

# ./configure --with-command-group = nagcmd

Lista completa de parámetros del script de configuración:

#. / configure --help

`configure" configura este paquete para adaptarse a muchos tipos de sistemas.: ./configure ... ... asignar variables de entorno (por ejemplo, CC, CFLAGS ...), especificarlas como = VALUE. Consulte a continuación las descripciones de algunos de las variables útiles. para las opciones se especifican entre paréntesis.:

h, --help mostrar esta ayuda y salir

Ayuda = opciones de visualización breves específicas de este paquete

Ayuda = muestra recursiva la ayuda breve de todos los paquetes incluidos

V, --version muestra la información de la versión y sale

q, --quiet, --silent no imprime mensajes `comprobando ..."

Cache-file = FILE resultados de la prueba de caché en FILE

C, --config-cache alias para `--cache-file = config.cache"

n, --no-create no crea archivos de salida

Srcdir = DIR encuentra las fuentes en los directorios DIR:

Prefix = PREFIX instalar archivos independientes de la arquitectura en PREFIX

Exec-prefix = EPREFIX instalar archivos dependientes de la arquitectura en EPREFIX por defecto, `make install" instalará todos los archivos en `/ usr / local / nagios / bin", `/ usr / local / nagios / lib", etc. prefijo de instalación que no sea `/ usr / local / nagios" usando `--prefix", por ejemplo `--prefix = $ HOME" .Mejor control, use las siguientes opciones.

Bindir = ejecutables de usuario DIR

Sbindir = ejecutables de administrador del sistema DIR

Libexecdir = ejecutables del programa DIR

Datadir = DIR datos independientes de la arquitectura de solo lectura

Sysconfdir = DIR datos de una sola máquina de solo lectura

Sharedstatedir = datos independientes de la arquitectura modificables de DIR

Localstatedir = DIR datos de una sola máquina modificables

Libdir = bibliotecas de código de objeto DIR

Incluidoir = Archivos de encabezado DIR C

Oldincludedir = Archivos de encabezado DIR C para no gcc

Infodir = documentación de información de DIR

Tipos de documentación de Mandir = DIR man:

Build = BUILD configurar para construir en BUILD

Host = HOST compilación cruzada para crear programas que se ejecuten en HOST Características:

Disable-FEATURE no incluye FEATURE (igual que --enable-FEATURE = no)

Habilitar-FEATURE [= ARG] incluir FEATURE

Disable-statusmap = deshabilita la compilación del mapa de estado CGI

Disable-statuswrl = deshabilita la compilación de statuswrl (VRML) CGI

Enable-DEBUG0 muestra la entrada y salida de la función

Enable-DEBUG1 muestra mensajes de información general

Enable-DEBUG2 muestra mensajes de advertencia

Enable-DEBUG3 muestra los eventos programados (verificaciones de servicio y host ... etc.)

Enable-DEBUG4 muestra notificaciones de servicio y host

Enable-DEBUG5 muestra consultas SQL

Enable-DEBUGALL muestra todos los mensajes de depuración

Enable-nanosleep permite el uso de nanosleep (en lugar de dormir) en la sincronización de eventos

Enable-event-broker permite la integración de las rutinas del agente de eventos

Enable-embedded-perl habilitará el intérprete de Perl integrado

Enable-cygwin permite la construcción en el entorno CYGWIN.

Con-PACKAGE [= ARG] usar PACKAGE

Sin-PAQUETE no use PAQUETE (igual que --con-PAQUETE = no)

Con-usuario-nagios = establece el nombre de usuario para ejecutar nagios

Con-grupo-nagios = establece el nombre del grupo para ejecutar nagios

Con-comando-usuario = establece el nombre de usuario para el acceso a los comandos

Con-grupo-de-comando = establece el nombre del grupo para el acceso al comando

Con correo = Establece la ruta al programa equivalente al correo

Con init-dir = Establece el directorio para colocar el script de inicio en

Con-lockfile = Establece la ruta y el nombre de archivo para el archivo de bloqueo

With-gd-lib = DIR establece la ubicación de la biblioteca gd

With-gd-inc = DIR establece la ubicación de los archivos de inclusión de gd

Con-cgiurl = establece la URL para los programas cgi (no use una barra al final)

Con-htmurl = establece la URL para html público

With-perlcache activa el almacenamiento en caché de scripts de Perl compilados internamente, variables de entorno influyentes: comando de compilador de C, indicadores de compilador de C, indicadores de enlace, p. -L si tiene bibliotecas en un directorio Indicadores del preprocesador C / C ++, p. Ej. -I si tiene en un directorio no estándar C procesa previamente estas variables para anular las elecciones hechas por `configure '' o para ayudar a encontrar bibliotecas y programas con nombres / ubicaciones no estándar.

Compilando el código fuente de Nagios.

Instalemos binarios, un script de inicialización, ejemplos de archivos de configuración y establezcamos permisos en el directorio de comandos externos:

# make install-init

# make install-config

# make install-commandmode

) Cambiar la configuración

Los archivos de configuración de muestra se instalan en el directorio / usr / local / nagios / etc. Deberían estar funcionando de inmediato. Solo necesita hacer un cambio antes de continuar.

Editemos el archivo de configuración /usr/local/nagios/etc/objects/contacts.cfg con cualquier editor de texto y cambiemos la dirección de correo electrónico asociada con la definición de contacto de nagiosadmin a la dirección a la que vamos a recibir mensajes de error.

# vi /usr/local/nagios/etc/objects/contacts.cfg

5) Configuración de la interfaz web

Instale el archivo de configuración de frontend de Nagios en el directorio conf.d de Apache.

# make install-webconf

Cree una cuenta de nagiosadmin para iniciar sesión en la interfaz web de Nagios

# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Reinicie Apache para que los cambios surtan efecto.

# /etc/init.d/apache2 recarga

Es necesario tomar medidas para fortalecer la seguridad del CGI para evitar el robo de esta cuenta, ya que la información de seguimiento es bastante sensible.

) Compile e instale los complementos de Nagios

Analicemos los códigos fuente comprimidos para los complementos de Nagios:

# cd ~ / descargas

# tar xzf nagios-plugins-1.4.11.tar.gz

Compile e instale complementos:

# ./configure --with-nagios-user = nagios --with-nagios-group = nagios

#make install

) Inicie el servicio de Nagios

Configuremos Nagios para que se inicie automáticamente cuando el sistema operativo esté encendido:

# ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Comprobemos la corrección sintáctica de los archivos de configuración de ejemplo:

# / usr / local / nagios / bin / nagios -v /usr/local/nagios/etc/nagios.cfg

Si no hay errores, inicie Nagios:

# /etc/init.d/nagios start

) Ingrese a la interfaz web

Ahora puede iniciar sesión en la interfaz web de Nagios utilizando la siguiente URL. Se le pedirá que ingrese el nombre de usuario (nagiosadmin) y la contraseña que establecimos anteriormente.

# "justificar">) Otras configuraciones

Para recibir recordatorios por correo electrónico sobre los eventos de Nagios, debe instalar el paquete mailx (Postfix):

% sudo apt-get install mailx

% sudo apt-get install postfix

Necesita editar los comandos de recordatorio de Nagios en el archivo /usr/local/nagios/etc/objects/commands.cfg y cambiar todos los enlaces de "/ bin / mail" a "/ usr / bin / mail". Después de eso, debe reiniciar el servicio de Nagios:

# sudo /etc/init.d/nagios reiniciar

La configuración detallada del módulo de correo se describe en el Apéndice D.

4.1.2 Descripción de la instalación del kernel del sistema desde el repositorio

Como se muestra arriba, la instalación de Nagios desde la fuente toma una cantidad significativa de tiempo y tiene sentido solo si necesita una optimización cuidadosa de la aplicación o si desea comprender a fondo cómo funciona el sistema. En producción, la mayor parte del software se instala desde los repositorios como paquetes precompilados. En este caso, la instalación se reduce a ingresar un comando:

% sudo aptitude install nagios

El administrador de paquetes satisfará independientemente todas las dependencias e instalará los paquetes necesarios.

4.2 Configuración del kernel del sistema

Antes de configurar en detalle, debe comprender cómo funciona el kernel de Nagios. Su descripción gráfica se muestra a continuación en la ilustración 6.2.

4.2.1 Descripción del kernel del sistema

La siguiente figura muestra un diagrama simplificado de cómo funciona el servicio de Nagios.

Arroz. 4.1 - Núcleo del sistema

El servicio Nagios lee el archivo de configuración principal, que, además de los parámetros básicos del servicio, contiene enlaces a archivos de recursos, archivos de descripción de objetos y archivos de configuración CGI.

El algoritmo y la lógica del kernel de monitoreo de red se muestran a continuación.

Arroz. 4.2 - Algoritmo de alerta de Nagios

2.2 Descripción de la interacción de los archivos de configuración

El directorio /etc/apache2/conf.d/ contiene el archivo nagios3.conf, del cual el servidor web apache toma la configuración para nagios.

Los archivos de configuración de nagios se encuentran en el directorio / etc / nagios3.

El archivo /etc/nagios3/htpasswd.users contiene contraseñas para los usuarios de nagios. El comando para crear un archivo y establecer la contraseña predeterminada para el usuario de nagios se da arriba. En el futuro, será necesario omitir el argumento "-c" al especificar una contraseña para un nuevo usuario, de lo contrario, el nuevo archivo sobrescribirá al anterior.

El archivo /etc/nagios3/nagios.cfg contiene la configuración básica para el propio nagios. Por ejemplo, los archivos de registro de eventos o la ruta al resto de los archivos de configuración que lee nagios al inicio.

Los nuevos hosts y servicios se definen en el directorio / etc / nagios / objects.

4.2.3 Completar las descripciones de hosts y servicios

Como se muestra arriba, puede configurar el kernel del sistema usando un archivo de descripción para hosts y servicios, pero este método no será conveniente a medida que aumente la cantidad de equipos monitoreados, por lo que debe crear una especie de directorio y estructura de archivos con descripciones de hosts y servicios.

La estructura creada se muestra en el Apéndice H.

Archivo Hosts.cfg

Primero, debe describir los hosts que serán monitoreados. Puede describir tantos hosts como desee, pero en este archivo nos limitaremos a los parámetros generales para todos los hosts.

El host descrito aquí no es un host real, sino una plantilla en la que se basan todas las demás descripciones de host. El mismo mecanismo se puede encontrar en otros archivos de configuración cuando la configuración se basa en un conjunto predefinido de valores predeterminados.

Archivo Hostgroups.cfg

Aquí es donde se agregan los hosts al grupo de hosts. Incluso en una configuración simple, cuando solo hay un host, aún debe agregarlo al grupo para que Nagios sepa qué grupo de contactos usar para enviar notificaciones. Más detalles sobre el grupo de contacto a continuación.

Archivo contactgroups.cfg

Hemos definido un grupo de contacto y agregado usuarios a este grupo. Esta configuración asegura que todos los usuarios sean alertados si algo anda mal con los servidores de los que el grupo es responsable. Sin embargo, debe tenerse en cuenta que las configuraciones individuales para cada usuario pueden anular estas configuraciones.

El siguiente paso es proporcionar información de contacto y configuraciones de alerta.

Archivo Contacts.cfg

Además de proporcionar información de contacto adicional para los usuarios en este archivo, uno de los campos, contact_name, tiene otro propósito. Los scripts CGI utilizan los nombres dados en estos campos para determinar si el usuario tiene derecho a acceder a un determinado recurso o no. Debe configurar la autenticación basada en .htaccess, pero aparte de eso, debe usar los mismos nombres utilizados anteriormente para que los usuarios trabajen a través de la interfaz web.

Ahora que los hosts y los contactos están configurados, puede proceder a configurar el monitoreo de los servicios individuales que deben monitorearse.

Archivo services.cfg

Aquí, como en el archivo hosts.cfg para los hosts, establecemos solo parámetros generales para todos los servicios.

Hay una gran cantidad de módulos de Nagios adicionales disponibles, pero si aún no hay verificación, siempre puede escribirlo usted mismo. Por ejemplo, no hay ningún módulo que compruebe si Tomcat se está ejecutando o no. Puede escribir un script que cargue una página jsp desde un servidor Tomcat remoto y devuelva el resultado dependiendo de si la página cargada contiene algo de texto en la página o no. (Cuando agregue un nuevo comando, asegúrese de mencionarlo en el archivo checkcommand.cfg, que no tocamos).

Además, para cada host individual, creamos nuestro propio archivo de descripción, en el mismo archivo almacenaremos las descripciones de los servicios que monitorearemos para este host. Esto se hace por conveniencia y organización lógica.

Vale la pena señalar que los hosts de Windows se monitorean a través de SNMP y NSClient a que se envía con Nagios. A continuación se muestra un diagrama de su trabajo.

Arroz. 4.3 - Esquema de monitoreo de hosts de Windows

Al mismo tiempo, los hosts * nix también se monitorean a través del complemento SNMP y NRPE. El esquema de su trabajo se muestra en la figura.

Arroz. 4.4 - Esquema de monitoreo de hosts * nix

2.4 Complementos de escritura

Además de escribir scripts de inicialización, definir hosts y servicios, se utilizaron los siguientes complementos:

├── comprobar_disco

├── check_dns

├── check_http

├── check_icmp

├── check_ifoperstatus

├── check_ifstatus

├── check_imap -> check_tcp

├── check_linux_raid

├── comprobar_carga

├── check_mrtg

├── check_mrtgtraf

├── check_nrpe

├── check_nt

├── check_ping

├── check_pop -> check_tcp

├── comprobar_sensores

├── check_simap -> check_tcp

├── check_smtp

├── check_snmp

├── check_snmp_load.pl

├── check_snmp_mem.pl

├── check_spop -> check_tcp

├── check_ssh

├── check_ssmtp -> check_tcp

├── check_swap

├── check_tcp

├── check_time

La mayoría de ellos vienen con el paquete Nagios. Los textos fuente de los complementos no incluidos en el paquete de entrega y utilizados en el sistema se presentan en el Apéndice I.

4.2.5 Configuración de SNMP en hosts remotos

Para poder monitorear usando el protocolo SNMP, primero debe configurar los agentes de este protocolo en el equipo de red. El diagrama de funcionamiento de SNMP junto con el núcleo del sistema de monitoreo de red se muestra en la figura siguiente.

Arroz. 4.5 - Esquema de monitorización mediante protocolo SNMP

Los parámetros de configuración de los hosts se presentan en el Apéndice H. La seguridad se lleva a cabo configurando individualmente el filtro de paquetes en cada uno de los hosts por separado y organizando subredes seguras del sistema a las que solo el personal autorizado de la empresa tiene acceso. Además, la configuración se realiza de tal manera que utilizando el protocolo SNMP solo puede leer los parámetros, no escribirlos.

4.2.6 Configuración del agente en hosts remotos

Para obtener un monitoreo avanzado de hosts y servicios, debe instalar un agente de Nagios llamado nagios-nrpe-server en ellos:

# aptitude install nagios-nrpe-server

La configuración del agente se muestra en el Apéndice K. El flujo de trabajo del agente se muestra en la Figura 4.5 anterior.

4.4 Instalación y configuración del módulo de seguimiento de descargas

MRTG (Multi Router Traffic Grapher) es un servicio que permite utilizar el protocolo SNMP para recibir información de varios dispositivos y mostrar en la ventana de su navegador los gráficos de la carga del canal (tráfico entrante, saliente, máximo, promedio) con pasos en minutos, horas. , días y por año.

requerimientos de instalación

Las siguientes bibliotecas son necesarias para que MRTG funcione:

§ gd - biblioteca de dibujo de gráficos. La biblioteca responsable de la formación de gráficos (# "justificar"> § Se requiere libpng - gd para crear gráficos en formato png (# "justify"> En nuestro caso, la instalación se reduce a la ejecución de un comando, ya que se ha seleccionado el método de instalación del paquete precompilado desde el repositorio:

# aptitude install mrtg

Puede crear archivos de configuración manualmente o puede utilizar los generadores de configuración incluidos en el paquete:

# cfgmaker @ >

Después de generar el archivo de configuración, se recomienda verificarlo, porque puede contener descripciones de interfaces que no necesitamos analizar para la carga de trabajo. En este caso, ciertas líneas del archivo se comentan o se eliminan. En el Apéndice M se proporciona un archivo de configuración MRTG de ejemplo. Debido al gran tamaño de estos archivos, solo se proporciona un ejemplo de un archivo.

# indexmaker >

Las páginas de índice son archivos html ordinarios y su contenido no es de particular interés, por lo que no tiene sentido dar ejemplos de ellos. El Apéndice H muestra un ejemplo de visualización de gráficos de carga de interfaz.

Finalmente, es necesario organizar una verificación de la carga en las interfaces en un horario. La forma más sencilla de conseguirlo es mediante el sistema operativo, es decir, los parámetros crontab.

4.5 Instalación y configuración del módulo para recopilar registros de eventos del sistema

Se eligió el paquete syslog-ng.ng (syslog next generation) como módulo para recopilar registros de eventos del sistema; este es un servicio multifuncional para registrar mensajes del sistema. En comparación con el servicio syslogd estándar, tiene varias diferencias:

§ diagrama de configuración mejorado

§ filtrar mensajes no solo por prioridad, sino también por su contenido

§ soporte de expresiones regulares (expresiones regulares)

§ manipulación y organización más flexible de los registros

§ la capacidad de cifrar el canal de transmisión de datos utilizando IPSec / Stunnel

La siguiente tabla enumera las plataformas de hardware compatibles.

Tabla 4.1 - Plataformas de hardware compatibles

x86x86_64SUN SPARCppc32ppc64PA-RISCAIX 5,2 y 5.3NetNetNetDaPo zaprosuNetDebian etchDaDaNetNetNetNetFreeBSD 6,1 * Sistema 11iNetNetNetNetNetDaIBM Dapo zaprosuPo zaprosuNetNetNetHP-UNET iNetNetNetDaNetNetRed Sombrero ES 4 / CentOS 4DaDaNetNetNetNetRed Sombrero ES 5 / CentOS 5DaDaNetNetNetNetSLES 10 / openSUSE 10.0DaPo zaprosuNetNetNetNetSLES 10 SP1 / openSUSE 10.1DaDaNetNetNetNetSolaris 8NetNetDaNetNetNetSolaris 9Po zaprosuNetDaNetNetNetSolaris 10Después zaprosuDaDaNetNetNetWindowsDaDaNetNetNetNet Nota: * No se admite el acceso a la base de datos de Oracle

En el Apéndice A se ofrece una comparación detallada de las características técnicas.

Los archivos que describen las reglas y los filtros, así como la configuración de los hosts remotos, se proporcionan en el Apéndice P.

Existe un documento RFC que describe en detalle el protocolo syslog, en general, el funcionamiento del módulo colector syslog se puede representar mediante el siguiente diagrama

Arroz. 4.6 - Diagrama del módulo para recopilar logs del sistema

En el host del cliente, cada aplicación individual escribe su propio registro de eventos, formando así una fuente. Además, el flujo de mensajes para los registros pasa por la determinación de la ubicación de almacenamiento, luego a través de los filtros, se determina su dirección de red, después de lo cual, al llegar al servidor de registro, se determina nuevamente la ubicación de almacenamiento para cada mensaje. El módulo seleccionado tiene una gran escalabilidad y una configuración complicada, por ejemplo, los filtros pueden ramificarse para que los mensajes de eventos del sistema se envíen en varias direcciones dependiendo de varias condiciones, como se muestra en la figura siguiente.

Arroz. 4.7 - Filtros de ramificación

La escalabilidad implica que para distribuir la carga, el administrador desplegará una red de servidores de filtrado auxiliares, el llamado relé.

Arroz. 4.8 - Escalado y equilibrio de carga

En última instancia, de la manera más simplificada, el funcionamiento del módulo se puede describir de la siguiente manera: los hosts del cliente transmiten mensajes desde los registros de eventos de diferentes aplicaciones a los servidores de descarga, que, a su vez, pueden transmitirlos a lo largo de una cadena de relés, y así sucesivamente. a los servidores centrales de recolección.

Arroz. 4.9 - Esquema generalizado del módulo

En nuestro caso, el flujo de datos no es tan grande para implementar un sistema de descarga de servidores, por lo que se decidió utilizar un esquema de operación cliente-servidor simplificado.

Arroz. 4.10 - Esquema de trabajo aceptado

5. GUÍA DEL ADMINISTRADOR DEL SISTEMA

En general, se recomienda al administrador del sistema que se adhiera a la jerarquía existente de ubicación de los archivos y directorios de configuración. Agregar nuevos hosts y servicios al sistema de monitoreo se reduce a crear nuevos archivos de configuración y scripts de inicialización, como se mostró en la Sección 5 - Desarrollo de software, por lo que no tiene sentido volver a describir los parámetros y principios de configuración del sistema en este trabajo. , pero vale la pena detenerse en la descripción con más detalle de las interfaces de los módulos individuales del sistema.

5.1 Descripción de la interfaz web del sistema

Para realizar un seguimiento interactivo de los servicios, era más conveniente integrar una interfaz web en el sistema. La interfaz web también es buena porque ofrece una imagen completa del sistema gracias al hábil uso de herramientas gráficas y al suministro de información estadística adicional.

Cuando inicie sesión en la página web de Nagios, se le pedirá el nombre de usuario y la contraseña que configuramos durante el proceso de configuración. La página de inicio de la interfaz web se muestra en la siguiente figura.

Arroz. 5.1 - Página de inicio de la interfaz web del sistema

A la izquierda está el panel de navegación, a la derecha están los resultados de varias vistas de datos sobre el estado de la red, los hosts y los servicios. Estaremos principalmente interesados ​​en la sección de Monitoreo. Echemos un vistazo a la página de descripción general táctica.

Arroz. 5.2 - Página de inicio de la interfaz web del sistema

Esta página contiene información resumida sobre todos los parámetros de monitoreo y el estado de los hosts y servicios, aunque no se proporcionan detalles; sin embargo, si surge algún problema, se resalta en un color especial y se convierte en un hipervínculo que conduce a una descripción detallada del problema que ha surgido. En nuestro caso, de momento, entre todos los hosts y servicios, hay un problema sin resolver, seguiremos este enlace (1 Problemas no manejados).

Arroz. 5.3 - Problema de servicio detectado

Aquí, en forma tabular, observamos en qué host surgió el problema, qué servicio lo causó (en nuestro caso, esta es una gran carga de procesador en el enrutador), el estado de error (puede ser normal, umbral y crítico), la hora de la última verificación, la duración del problema, el número de verificación de la cuenta en el bucle e información detallada con valores específicos devueltos por el complemento que se está utilizando.

Arroz. 5.4 - Descripción detallada del estado del servicio

Aquí vemos una descripción completa del problema, esta página es útil para un análisis en profundidad del problema, cuando la causa de su ocurrencia no es del todo clara, por ejemplo, puede estar en valores de umbral establecidos de manera demasiado rígida del problema. criticidad del estado o parámetros configurados incorrectamente para iniciar el complemento, que también serán evaluados por el sistema como un estado crítico ... Además de la descripción, desde esta página es posible ejecutar comandos en el servicio, por ejemplo, deshabilitar verificaciones, establecer otro horario para la siguiente verificación, aceptar datos de forma pasiva, aceptar el problema para su consideración, deshabilitar alertas, enviar una alerta manual , programe un cierre del servicio, desactive la detección de estado inestable y escriba un comentario.

Vayamos a la página de detalles del servicio.

Arroz. 5.5 - Vista detallada de todos los servicios

Aquí vemos una lista de todos los hosts y servicios, independientemente de su estado actual. Esta función puede ser útil, pero no es muy conveniente examinar una larga lista de hosts y servicios y es más bien necesario representar visualmente la cantidad de trabajo realizado por el sistema de vez en cuando. Aquí, cada host y servicio, como en la Figura 6.3, es un enlace que conduce a una descripción más detallada del parámetro.

Arroz. 5.6 - Lista completa de hosts detallada

Esta tabla proporciona una lista detallada completa de hosts, sus estados, la hora de la última verificación, la duración del estado actual e información adicional. En nuestro sistema, se acepta que el estado de un host se verifique verificando la disponibilidad del host usando el protocolo ICMP (8), es decir, usando el comando ping, pero en el caso general, la verificación puede ser cualquier cosa. te gusta. Los iconos de la columna a la derecha del nombre de host indican el grupo al que pertenece; esto se hace para facilitar la lectura de información. Un semáforo es un enlace que conduce a una lista detallada de servicios para un host determinado, no tiene sentido describir esta tabla por separado, es exactamente igual que en la Figura 10.4, solo se presenta información sobre un solo host.

Los siguientes enlaces de la lista son varias modificaciones de las tablas anteriores y no será difícil comprender su contenido. La característica más interesante de la interfaz web es la capacidad de crear un mapa de red en modo semiautomático.

Arroz. 5.7 - Mapa de red circular completo

A través del parámetro padre de cada host y servicio, podemos crear una estructura o jerarquía de nuestra red, que determinará la lógica del kernel de monitoreo de red y la presentación de hosts y servicios en el mapa de la red. Hay varios modos de visualización, además de circular, los más convenientes son árbol equilibrado y esférico.

Arroz. 5.8 - Mapa de red - Modo de árbol equilibrado

Arroz. 5.9 - Mapa de red - Modo bola

En todos los modos, la imagen de cada host es un enlace a su tabla de servicios y sus estados.

La siguiente parte importante de la interfaz del motor de monitoreo es el generador de tendencias. Con su ayuda, puede planificar la sustitución de equipos por uno más productivo, le daremos un ejemplo. Haga clic en el enlace Tendencias. Seleccionamos el tipo de informe - servicio.

Paso 1: seleccione el tipo de informe: servicio

El tercer paso es seleccionar el período de conteo y generar un informe.

Arroz. 5.10 - Tendencia

Hemos generado una tendencia en la utilización del procesador en el enrutamiento. De ella podemos concluir que dentro de un mes este parámetro se está deteriorando constantemente y es necesario tomar medidas ya sea para optimizar el funcionamiento del host o prepararse para reemplazarlo por uno más productivo.

5.2 Descripción de la interfaz web del módulo de seguimiento de carga de la interfaz

La interfaz web del módulo de seguimiento de carga de la interfaz es una lista de directorios que contienen páginas de índice de hosts monitoreados con gráficos de la carga de cada interfaz.

Arroz. 5.11 - Página de inicio del módulo de seguimiento de carga de la interfaz

Al hacer clic en cualquiera de los enlaces, obtenemos los gráficos de descarga. Cada gráfico es un enlace que lleva a las estadísticas de la semana, el mes y el año.

5.3 Descripción del módulo para recopilar registros de eventos del sistema

Por el momento, no se requiere un filtrado mejorado de los registros del sistema y la capacidad de buscar en ellos a través de una única interfaz web. los problemas que requieren ver estos registros son raros. Por lo tanto, se pospuso el desarrollo de una base de datos para estas revistas y la interfaz web. Actualmente, se accede a ellos a través de ssh y la exploración de directorios en el administrador de archivos mc.

Como resultado del trabajo de este módulo, obtuvimos la siguiente estructura de directorios:

├── apache2

├── asterix

├── bgp_router

├── dbconfig-common

├── instalador

│ └── cdebconf

├── len58a_3lvl

├── seguimiento

├── nagios3

│ └── archivos

├── cliente-ocsinventory

├── servidor-ocsinventory

├── quagga

├── router_krivous36b

├── router_lenina58a

├── router_su

├── router_ur39a

├── modelador

├── ub13_router

├── univer11_router

└── voip

Cada directorio es un repositorio de registros de eventos para cada host individual.

Arroz. 5.13 - Visualización de datos recopilados por el módulo de recopilación de registros de eventos del sistema

6. PRUEBA DEL TRABAJO

Durante la implementación del sistema, se realizaron pruebas graduales del funcionamiento de cada componente, comenzando por el núcleo del sistema. La expansión de la funcionalidad se llevó a cabo solo después del ajuste final de los niveles inferiores de los módulos del sistema de monitoreo de red en la jerarquía debido a las muchas dependencias de varios subsistemas. Paso a paso, en general, puede describir el proceso de implementación y prueba de la siguiente manera:

) Instalación y depuración del kernel basado en Nagios;

) Configurar el monitoreo de hosts remotos con la funcionalidad básica de Nagios;

) Configuración del módulo para monitorear la carga de interfaces de red mediante MRTG;

) Ampliación de la funcionalidad del núcleo del sistema y su integración con el módulo MRTG;

) Ajuste del módulo para la recolección de registros del sistema;

) Escribir un script para inicializar el filtro de paquetes del sistema de monitoreo con el fin de garantizar la seguridad del sistema.

7. Seguridad de la información

1 Características del lugar de trabajo

Los factores dañinos que afectan el trabajo cuando se usa una PC incluyen:

· aumento del valor del voltaje de la corriente eléctrica;

· ruido;

· radiación electromagnética;

· campo electrostático.

Para garantizar las mejores condiciones para un trabajo eficiente y seguro, es necesario crear condiciones de trabajo que sean cómodas y minimicen el impacto de estos factores nocivos. Es necesario que los factores nocivos enumerados sean consistentes con las reglas y regulaciones establecidas.

7.2 Seguridad laboral

2.1 Seguridad eléctrica

La herramienta de software proyectada se crea con la expectativa de trabajar en un servidor existente ubicado en una sala técnica especialmente equipada. Está equipado con conductos de cables para el enrutamiento de cables. Cada servidor se suministra con una fuente de alimentación de ~ 220 V, 50 Hz, con una conexión a tierra. Antes de ingresar la fuente de alimentación en la habitación, se instalan dispositivos automáticos que cortan la fuente de alimentación en caso de un cortocircuito. La conexión a tierra de protección se realiza por separado.

Al conectar una computadora, es necesario conectar la caja del equipo al conductor de puesta a tierra de protección para que, en caso de falla del aislamiento o por alguna otra razón, el voltaje peligroso de la fuente de alimentación, cuando una persona toca la caja del equipo, no pueda crear un corriente peligrosa a través del cuerpo humano.

Para hacer esto, use el tercer contacto en los enchufes eléctricos, que está conectado al conductor de tierra de protección. Los gabinetes del equipo se conectan a tierra a través del cable de alimentación mediante un conductor dedicado.

Se aplican medidas técnicas para garantizar la protección contra descargas eléctricas al tocar el cuerpo de una instalación eléctrica en caso de ruptura del aislamiento de partes vivas, que incluyen:

· puesta a tierra de protección;

· puesta a tierra de protección;

· parada de protección.

7.2.2 Protección contra el ruido

Las investigaciones muestran que la pérdida auditiva es el factor más importante en el ruido. Pero el efecto del ruido no se limita al efecto solo en la audición. Provoca cambios notables en una serie de funciones mentales fisiológicas. El ruido tiene un efecto nocivo sobre el sistema nervioso y reduce la velocidad y precisión de los procesos sensoriomotores, y aumenta el número de errores en la resolución de problemas intelectuales. El ruido tiene un efecto notable en la atención de una persona y provoca emociones negativas.

La principal fuente de ruido en las salas donde se ubican las computadoras son los equipos de aire acondicionado, los equipos de impresión y fotocopiadora, y en las propias computadoras, los ventiladores de refrigeración.

Las siguientes medidas de control del ruido se utilizan activamente en el área de producción:

· el uso de mecanismos de enfriamiento silenciosos;

· aislamiento de las fuentes de ruido del medio ambiente mediante aislamiento acústico y absorción acústica;

· el uso de materiales fonoabsorbentes para el revestimiento del local.

Las siguientes fuentes de ruido están presentes en el lugar de trabajo en el trabajo:

· unidad del sistema (enfriador (25dB), disco duro (29dB), fuente de alimentación (20dB));

· impresora (49dB).

El ruido total L emitido por estos dispositivos se calcula mediante la fórmula:

donde Li es el nivel de ruido de un dispositivo, dB = 10 * log (316,23 + 794,33 + 100 + 79432,82) = 10 * 4,91 = 49,1 dB

Según SN 2.2.4 / 2.1.8.562-96, el nivel de ruido en el lugar de trabajo de matemáticos-programadores y operadores de video no debe exceder los 50 dB.

7.2.3 Protección contra radiación electromagnética

La protección contra las interferencias electromagnéticas la proporcionan pantallas con superficie eléctricamente conductora y el uso de monitores equipados con un sistema de Baja Radiación, que minimiza el nivel de radiación nociva, así como monitores de cristal líquido en los que no hay radiación electromagnética en absoluto.

7.2.4 Protección contra campo electrostático

Para protegerse contra cargas electrostáticas, se utilizan un filtro protector con conexión a tierra, humidificadores de aire y los pisos están cubiertos con un revestimiento antiestático. Para mantener los valores normalizados de la concentración de iones positivos y negativos en habitaciones con computadoras, se instalan aires acondicionados, dispositivos de ionización de aire y se realiza ventilación natural durante al menos 10 minutos después de cada 2 horas de funcionamiento.

Para evitar el efecto nocivo de las partículas de polvo con aeroinos en el cuerpo de las personas trabajadoras, la limpieza en húmedo del local se realiza a diario, y al menos 1 vez por turno, se elimina el polvo de las pantallas cuando el monitor está apagado.

7.3 Condiciones de trabajo

3.1 Microclima del área de producción

El equipo considerado en este proyecto de diploma no genera ninguna sustancia nociva durante su funcionamiento. Por lo tanto, el ambiente del aire en la habitación donde se utilizan no tiene ningún efecto nocivo en el cuerpo humano y cumple con los requisitos de la categoría I de trabajo, de acuerdo con GOST 12.1.005-88.

Las normas óptimas de temperatura, humedad relativa y velocidad del aire en el área de trabajo de las instalaciones industriales están estandarizadas por GOST 12.1.005-88 y se muestran en la Tabla 7.1.

Tabla 7.1 - Parámetros del microclima

Parámetro estandarizado Valor Óptimo Permitido Temperatura del aire real, C20 - 2218 - 2020 Humedad,% 40 - 60 No más de 8045 Velocidad del aire, m / s 0,20,30..0,3

El microclima corresponde a las condiciones óptimas.

3.2 Iluminación industrial

Para el cálculo, seleccionamos el departamento de soporte de Gerkon LLC en la ciudad de Verkhnyaya Pyshma, donde tuvo lugar el desarrollo de este proyecto:

· el área de la habitación es de 60m2;

· área de aberturas de luz 10 m2;

· Se instalaron 4 estaciones de trabajo automatizadas.

El cálculo de la iluminación natural se realiza de acuerdo con la fórmula SNiP 23.05-95:

S0 = Sп * en * Кз * N0 * KZD / 100% * Т0 * Т1 (7.2)

Donde S0 es el área de las aberturas de luz, m2;

Sп - área del piso de la habitación, m2, 60;

e - coeficiente de iluminación natural, 1.6;

Кз - factor de seguridad, 1,5;

N0 - característica de luz de las ventanas, 1;

KZD - coeficiente teniendo en cuenta el oscurecimiento de las ventanas por edificios opuestos, 1.2;

T0 es el coeficiente general de transmisión de luz, 0,48;

T1 - coeficiente de reflexión de la superficie de la habitación, 1.2.

Los valores de todos los coeficientes se toman en SNiP 23.05.-95.

Como resultado del cálculo, obtenemos: el área requerida de las aberturas de luz de las ventanas S0 = 3.4m2. El área real de las aberturas es de 10m2, que excede el área mínima permitida de aberturas de luz para este tipo de habitación y es suficiente durante las horas del día.

Cálculo de iluminación artificial para una habitación iluminada por 15 lámparas fluorescentes del tipo LDTs-60 con una potencia de 60W cada una.

Según SNiP 23.05-95, la cantidad de iluminación de las lámparas fluorescentes debe ser de al menos 300lm en el plano horizontal, para un sistema de iluminación general. Teniendo en cuenta el trabajo visual de alta precisión, el valor de iluminación se puede aumentar hasta 1000lm.

El flujo luminoso de una lámpara fluorescente se calcula utilizando la fórmula de SNiP 23.05.-95:

Phi = En * S * Z * K / N * η (7.3)

dónde En - iluminación de la habitación normalizada, lux, 200;

S - área del piso de la habitación, m2, 60;

Z - coeficiente teniendo en cuenta la relación entre la iluminación media y la mínima, 1,1;

K es el factor de seguridad teniendo en cuenta la contaminación del aire, 1,3;

N - número de lámparas, 15;

η - factor de utilización del flujo luminoso, 0,8.

Como resultado, obtenemos Phi = 1340lm, el flujo luminoso total de todas las lámparas es de 3740lm, por lo tanto, la iluminación del laboratorio es superior al mínimo permitido.

7.4 Ergonomía del lugar de trabajo

4.1 Organización del lugar de trabajo

De acuerdo con SanPiN 2.2.2 / 4.2.1340-03, VDT (terminal de pantalla de video) debe cumplir con los siguientes requisitos técnicos:

· brillo de iluminación no inferior a 100 cd / m2;

· el tamaño mínimo del punto de luz no es más de 0,1 mm para una pantalla a color;

· el contraste de la imagen del letrero no es inferior a 0,8;

· frecuencia de exploración vertical no inferior a 7 kHz

· el número de puntos no es inferior a 640;

· revestimiento antirreflectante de la pantalla;

· tamaño de la pantalla no menos de 31 cm en diagonal;

· la altura de los caracteres en la pantalla no es inferior a 3,8 mm;

· la distancia entre los ojos del operador y la pantalla debe ser de unos 40-80 cm;

El RCCB debe estar equipado con un plato giratorio que le permita moverse en planos horizontal y vertical dentro de 130-220 mm y cambiar el ángulo de inclinación de la pantalla en 10-15 grados.

El proyecto del diploma se llevó a cabo en una computadora con un VDT ​​ViewSonic de 39 cm. Este monitor está fabricado de acuerdo con los estándares globales y cumple con todos los requisitos técnicos anteriores.

Se imponen los siguientes requisitos en el teclado:

· pintura corporal en colores suaves y tranquilos con difusión de luz difusa;

· superficie mate con una reflectividad de 0.4 - 0.6 y no tiene partes brillantes que puedan crear deslumbramiento;

El proyecto se llevó a cabo en un teclado de la marca Logitech que cumple con todos los requisitos anteriores.

Las unidades del sistema se instalan en el lugar de trabajo con fácil acceso a unidades de disquete y fácil acceso a conectores y controles en la parte posterior. Los disquetes de uso frecuente se almacenan cerca de la unidad del sistema en una celda protegida contra el polvo y electromagnéticamente. Impresora ubicada a la derecha del usuario. El texto impreso es visible para el operador cuando se encuentra en la posición principal de trabajo. El papel en blanco y otros suministros esenciales se almacenan cerca de la impresora en compartimentos dedicados.

Los cables de conexión se colocan en conductos especiales. La disposición de los canales debe ser tal que los conectores no impidan la extracción de los cables.

Para un manipulador como "ratón" a la derecha del usuario sobre la mesa hay un área libre, que debe ser idéntica en forma y tamaño a la superficie de la pantalla.

El lugar de trabajo del operador cumple con los requisitos de GOST 12.2.032-78 SSBT.

La organización espacial del lugar de trabajo asegura una postura de trabajo óptima:

· la cabeza está inclinada hacia adelante de 10 a 20 grados;

· la espalda tiene un soporte, la relación entre el hombro y el antebrazo, y también entre el muslo y la parte inferior de la pierna es un ángulo recto.

Los principales parámetros del lugar de trabajo deben ser ajustables. Esto asegura la posibilidad de crear condiciones de trabajo favorables para un individuo, teniendo en cuenta las características geoantropométricas.

Los principales parámetros del lugar de trabajo y muebles equipados con una computadora personal (Fig. 7.1)

Arroz. 7.1 - Estación de trabajo del operador de la computadora

· altura del asiento 42 - 45 cm;

· la altura del teclado desde el suelo es de 70 a 85 cm;

· el ángulo de inclinación del teclado desde la horizontal de 7 a 15 grados;

· distancia entre el teclado y el borde de la mesa 10-26 cm;

· distancia desde el centro de la pantalla hasta el suelo 90 - 115 cm;

· ángulo de inclinación de la pantalla desde la vertical de 0 a 30 grados (óptimo 15);

· distancia de la pantalla desde el borde de la mesa 50 - 75 cm;

· altura de la superficie de trabajo para discos 74 - 78 cm;

El lugar de trabajo está provisto de un reposapiés recomendado para todo tipo de trabajos relacionados con la conservación a largo plazo en una posición sentada.

Según SanPiN 2.2.2.542-96, la naturaleza del trabajo de un operador de computadora se considera fácil y pertenece a la categoría 1A.

Hay pausas después de 2 horas desde el inicio del turno de trabajo y 2 horas después de la pausa para el almuerzo, cada una con una duración de 15 minutos. Durante los descansos regulados, para reducir el estrés neuroemocional, la fatiga y eliminar la influencia de la hipodinámica, se realizan complejos de ejercicios.

7.5 Seguridad contra incendios

La sala donde se llevó a cabo el trabajo en este proyecto, la categoría de riesgo de incendio se estableció en NPB 105-03: líquidos inflamables y no inflamables, sustancias y materiales sólidos inflamables y no inflamables, incluidos polvo y fibras, sustancias y materiales capaces de interactuar con agua, oxígeno aire o entre sí solo para quemarse, siempre que el local en el que se disponga o se forme no pertenezca a las categorías A o B. Edificio para local de I grado de resistencia al fuego según SNiP 21- 01-97.

Se observan las siguientes reglas de seguridad en el área de producción:

· los pasajes, las salidas de las instalaciones, el acceso a los medios de extinción de incendios son gratuitos;

· el equipo en funcionamiento está en buen estado de funcionamiento y se revisa cada vez que se inicia el trabajo;

· al final del trabajo, se examina la sala, se desenergiza la fuente de alimentación, se cierra la sala.

El número de salidas de evacuación de los edificios desde las instalaciones es dos. El ancho de la salida de emergencia (puerta) es de 2 m. Las rutas de escape utilizan escaleras normales y puertas batientes. Las escaleras carecen de locales, comunicaciones tecnológicas, salidas de ascensores y montacargas. Las rutas de escape están equipadas con iluminación de emergencia tanto natural como artificial.

Como medio principal de extinción de incendios en la habitación, hay dos extintores portátiles de dióxido de carbono en la habitación.

Para detectar la etapa inicial de encendido y alertar al servicio de bomberos, se utiliza un sistema automático y de alarma contra incendios (APS). Activa de forma independiente las instalaciones de extinción de incendios hasta que el fuego alcanza un gran tamaño y notifica al servicio de bomberos de la ciudad.

Los objetos del recinto ferial, a excepción del APS, deberán estar equipados con instalaciones fijas de extinción de incendios. Aplicaciones de la instalación de incendios de extinción de incendios, cuya acción se basa en el llenado rápido del local con una sustancia de gas extintor, como resultado de lo cual disminuye el contenido de oxígeno en el aire.

7.6 Emergencias

Un incendio es la emergencia más probable en esta sala. En caso de incendio, es necesario evacuar al personal y reportar el incidente a los bomberos. El plan de evacuación se muestra en la Figura 7.2.

Arroz. 7.2 - Plan de evacuación de incendios

8. SECCIÓN ECONÓMICA

Esta sección analiza los costos de desarrollar un sistema de monitoreo de red, su implementación y mantenimiento, así como los materiales y equipos relacionados.

El costo del proyecto refleja el costo de los medios y objetos de mano de obra consumidos en el proceso de desarrollo y producción (depreciación, el costo de equipos, materiales, combustible, energía, etc.), una parte del costo de la mano de obra (mano de obra remuneración), el costo de los módulos comprados del sistema.

En el proceso de actividad y un aumento en el volumen de la oferta de servicios, surgió el problema de la detección proactiva de puntos débiles y defectuosos en la organización de la red, es decir, la tarea fue implementar una solución que permita predecir la necesidad de reposición o modernización. secciones de red antes de que las fallas afecten al funcionamiento de los nodos de abonado.

Con el crecimiento de la base de clientes y, como resultado, la cantidad de equipos activos, se hizo necesario monitorear con prontitud el estado de la red en su conjunto y sus elementos individuales en detalle. Antes de la implementación del sistema de monitoreo de red, el administrador de la red tenía que conectarse usando los protocolos telnet, http, snmp, ssh, etc. a cada nodo de red de interés y utilice las herramientas de diagnóstico y monitoreo integradas. Por el momento, la capacidad de la red es de 5.000 puertos, 300 conmutadores de capa 2, 15 enrutadores y 20 servidores internos.

Además, la congestión de la red y las fallas flotantes se detectaron solo cuando surgieron problemas graves de los usuarios, lo que hizo imposible hacer planes para las actualizaciones de la red.

Todo ello condujo, en primer lugar, a un constante deterioro de la calidad de los servicios ofrecidos y a un aumento de la carga sobre los administradores de sistemas y soporte técnico a los usuarios, lo que conllevó pérdidas colosales.

De acuerdo con la situación actual, se decidió desarrollar e implementar un sistema de monitoreo de red que solucionara todos los problemas anteriores, que, resumido, se pueden expresar de la siguiente manera:

Es necesario desarrollar e implementar un sistema de monitoreo que permita monitorear tanto conmutadores, enrutadores de diferentes fabricantes, como servidores de diferentes plataformas. Foco en el uso de protocolos y sistemas abiertos, con el máximo aprovechamiento de desarrollos prefabricados del fondo de software libre, que desde un punto de vista económico reduce a cero el coste de licenciar el sistema final.

El sistema debe cumplir los siguientes requisitos económicos:

· requisitos mínimos para los recursos de hardware (conduce a menores costos para la parte de hardware del proyecto);

· códigos de fuente abierta de todos los componentes del complejo (le permite cambiar de forma independiente el principio del sistema sin recurrir a la ayuda de desarrollos de propiedad de terceros y reduce el costo de la licencia del producto);

· extensibilidad y escalabilidad del sistema (le permite ampliar el alcance de la aplicación sin recurrir a la ayuda de desarrollos de terceros y propietarios y reduce el costo de la licencia del producto);

· medios estándar para proporcionar información de diagnóstico (le permite reducir el costo de mantenimiento del sistema);

· disponibilidad de documentación detallada para todos los productos de software utilizados (permite capacitar rápidamente a un nuevo empleado);

· la capacidad de trabajar con equipos de diferentes fabricantes (permite utilizar un producto de software). (Consulte el Apéndice B para obtener una lista completa de equipos).

En general, el desarrollo del proyecto tomó 112 horas (2 semanas). La implementación de este proyecto tomará 56 horas (1 semana).

1 Cálculo de los costos de desarrollo del proyecto

Los costos de desarrollo del proyecto consisten en:

· costos de nómina;

· costos de depreciación de equipos y productos de software;

· el costo de pagar la electricidad;

· gastos generales.

Gastos de nómina.

Al calcular el costo de los salarios, tenemos en cuenta que este proyecto fue desarrollado por una persona: un ingeniero de sistemas.

El salario promedio de mercado de un ingeniero de sistemas del nivel requerido en la región es de 30,000 rublos.

Calculemos el costo de 1 hora de trabajo de un ingeniero, basándonos en los siguientes datos:

· prima 25%;

· coeficiente regional 15%;

· el fondo de jornada laboral en 2010, de acuerdo con el calendario de producción, es de 1988 horas;

Así, la tasa, teniendo en cuenta el coeficiente regional, será:

RF = 30.000 * 1,25 * 1,15 * 12/1988 = 260 rublos

Al calcular el costo de los salarios, se tienen en cuenta las deducciones pagadas de los salarios acumulados, es decir, el valor total de la tasa de la prima del seguro será igual a la tasa máxima de UST: 26%, que incluye:

· Fondo de pensiones: 20%;

· FSSR - 2,9%

· FFOMS: 1,1%;

· GFOMS: 2%;

· Seguro social obligatorio contra accidentes - 0,2%.

En total, las deducciones serán:

CO = RF * 0.262 = 260 * 0.262 = 68 rublos

Teniendo en cuenta el tiempo de trabajo del ingeniero (112 horas de desarrollo y 56 horas de implementación), calcularemos los costos salariales:

ZP = (112 + 56) * (RF + CO) = 168 * 328 = 55104 rublos

Gastos de depreciación de equipos y productos de software.

Se utilizó una computadora personal y un servidor AQUARIUS SERVER T40 S41 como equipo principal en la etapa de desarrollo del proyecto de red. El costo de una computadora en este momento es de aproximadamente 17,000 rublos, mientras que un servidor es de 30,000 rublos.

Por lo tanto, el costo de una inversión única en equipo será:

РВА = 47000 rublos

Durante la vida de la computadora y el servidor, se permite su modernización, este tipo de costo también se tiene en cuenta en el cálculo. Ponemos el 50% de la RV para modernización:

РМА = РВ * 0.5 = 23500 rublos

La computadora se utilizó en los siguientes pasos:

· busqueda de literatura;

· búsqueda de soluciones para el diseño de un sistema de monitoreo de redes;

· desarrollo de estructuras y subsistemas;

· diseñar un sistema de monitoreo de red;

· registro del documento.

El servidor se utilizó durante la implementación del sistema y el trabajo directo con el sistema.

Los productos de software utilizados en el desarrollo se obtuvieron bajo licencias libres, lo que indica su costo cero y la ausencia de la necesidad de su depreciación.

Así, el costo total del equipo, teniendo en cuenta la depreciación, será:

OZA = РВА + РМА = 47000 + 23500 = 70500 rublos

Se asume que la vida útil es de 2 años. El costo de una hora de trabajo es (asumiendo que la cantidad de días hábiles en un mes es 22 y con una jornada laboral de 8 horas):

SOCHR = OZA / BP = 70500/4224 = 16.69 rublos

En el momento del desarrollo y la implementación, el costo de las deducciones por depreciación será en consecuencia:

SACHRV = SOCHR * TRV = 16.69 * 168 = 2803.92 rublos

Costos de electricidad.

Los costos de electricidad son la suma de los consumidos por la computadora y los utilizados para la iluminación. Costo de electricidad:

SEN = 0,80 rublos / kW * h (Por acuerdo con el propietario del local)

Рк, с = 200 W - la energía consumida por la computadora o el servidor.

Trk = 168 horas - tiempo de operación de la computadora en la etapa de desarrollo e implementación del sistema.

Trs = 52 horas: tiempo de funcionamiento del servidor en la etapa de desarrollo e implementación del sistema.

Así, el costo de la electricidad en la etapa de desarrollo e implementación del proyecto será:

SENP = Rk * Trk * SEN + Rk * Trc * SEN = (200 * 168 * 0,80 + 200 * 52 * 0,80) / 1000 = (26880 + 8320) / 1000 = 35,2 rublos

El puesto de trabajo donde se realizó este trabajo está equipado con una lámpara de 100 W. Calculemos el costo de la electricidad consumida por el dispositivo de iluminación durante el desarrollo e implementación del sistema:

SENO = 100 * Trk * SEN = (100 * 168 * 0,80) / 1000 = 13,44 rublos

Los costos totales de electricidad fueron:

OZEN = SENP + SENO = 35.2 + 13.44 = 48.64 rublos

8.2 Cálculo de gastos generales

Esta partida de costo cubre el costo de otros equipos y consumibles, así como los gastos imprevistos.

Los costos generales en el presupuesto de la empresa son el 400% de los salarios acumulados:

NR = salario * 4 = 55104 * 4 = 220416 rublos.

Así, los costos para el desarrollo e implementación del proyecto fueron:

SRV = ZP + SARV + OZEN + NR = 55104 + 2803.92 + 48.64 + 220416 = 278372.56 rublos

3 Eficiencia

Como resultado de los cálculos económicos, el precio mínimo para el desarrollo e implementación del sistema de monitoreo de red se estableció en 278372.56 rublos.

Como puede verse en los cálculos, la gran parte del costo de los gastos recae en materiales y equipos. Esto se debe al hecho de que los principales fabricantes de equipos son empresas extranjeras y, en consecuencia, los precios de estos productos se cotizan en dólares estadounidenses al tipo CBRF + 3%. Y el aumento de los derechos de aduana sobre los productos importados también afecta negativamente el precio para los clientes finales.

Para justificar el desarrollo independiente del sistema, comparemos su costo con las soluciones listas para usar disponibles en el mercado:

· D-Link D-View - 360.000 rublos

Los equipos de red activos deben garantizar el funcionamiento ininterrumpido y a largo plazo de la red corporativa. La identificación y eliminación oportuna de fallas es la clave para el trabajo exitoso y eficiente de la empresa. Por eso es muy importante prestar especial atención al sistema de monitoreo, que rastrearía el estado de los equipos activos y notificaría al administrador del sistema sobre las desviaciones de los indicadores normales por SMS, correo electrónico u otro medio de notificación.

Sistema de monitoreo Es un conjunto de medios técnicos que monitorean y recolectan información de manera continua en una red de área local en base al análisis de datos estadísticos con el fin de identificar nodos defectuosos o que operan incorrectamente y notificar a los responsables. La funcionalidad de los sistemas de monitoreo modernos le permite monitorear el estado de servicios como:

1) Disponibilidad del anfitrión

Enviando periódicamente ICMP Echo-Request a la dirección del dispositivo de red

2) Disponibilidad del servidor web

Al enviar una solicitud HTTP para obtener la página

3) Disponibilidad de servicios de correo

Mediante el envío periódico de mensajes SMTP de diagnóstico

Además, puede medir el tiempo de respuesta de estos servicios.

Los controles periódicos de este tipo le permiten determinar rápidamente en qué nivel se ha producido el problema y comenzar a solucionarlo de inmediato.

La figura anterior muestra el ejemplo más simple de implementación de un sistema de monitoreo que monitorea solo cuatro dispositivos. En condiciones reales, una flota de equipos activos puede tener muchos más nodos. Para llevar a cabo una supervisión competente, se combinan diferentes tipos de nodos en grupos, por ejemplo, un grupo de servidores web o un grupo de enrutadores. Este tipo de separación ayuda a organizar la información estadística y facilita el proceso de observación.

La mayoría de los sistemas de monitoreo permiten automatizar la verificación y el diagnóstico de dispositivos SNMP utilizando varios complementos (incluidos los creados manualmente).

SNMP (Protocolo simple de administración de redes): fue creado específicamente para las necesidades de monitoreo de equipos de red. Todos los dispositivos activos L2 y L3 contienen la denominada Base de información de gestión (MIB), que contiene los principales parámetros del estado del equipo. Por ejemplo, carga de la CPU, estado de la interfaz, espacio libre, etc. Cada uno de estos registros corresponde a un OID único (Oject IDentifier). Teniendo el identificador requerido, puede obtener información sobre el parámetro de interés utilizando el protocolo SNMP. Los sistemas de monitorización modernos permiten automatizar este proceso. El sistema, utilizando el protocolo SNMP, se conecta al dispositivo, lo sondea en busca del OID de interés, obtiene el valor del parámetro y lo compara con el especificado. Si se detecta una discrepancia entre estos dos valores, el sistema de monitoreo reacciona e inicia el proceso de notificación.

Antes de la implementación directa del sistema de monitoreo, es necesario realizar una encuesta LAN, cuyo resultado debe ser una lista de equipos monitoreados, parámetros y un algoritmo aprobado para escalar eventos de monitoreo. A partir del análisis de la infraestructura de red del cliente, se forman las primeras decisiones que determinan la arquitectura del futuro sistema de monitoreo.

En la siguiente etapa, se elaboran especificaciones y un paquete de documentación de diseño, teniendo en cuenta los deseos del cliente.

La etapa final es escalar el sistema de monitoreo, es decir, expandir el volumen de la infraestructura de TI monitoreada al requerido por el cliente.

La implementación del sistema de monitoreo es un paso importante hacia la automatización completa de la infraestructura de TI, lo que conduce a un aumento en la eficiencia de su uso. Los especialistas de nuestra empresa han desarrollado repetidamente soluciones que satisfacen las expectativas de los clientes y han estado trabajando de manera confiable durante varios años.

¿Te ayudó este artículo?

¿Por favor dime porque?

Lamentamos que el artículo no te haya sido útil: (Por favor, si no te lo dificulta, indica por qué? Estaremos muy agradecidos por una respuesta detallada. ¡Gracias por ayudarnos a mejorar!