Versión 4 Release 2 Network Manager IP Edition - IBM...Versión 4 Release 2 Guía de configuración...

Network Manager IP Edition4.2

Guía de configuración e instalación

IBM

2021-4212-01

Nota

Antes de utilizar esta información y el producto que soporta, lea la información de “Avisos” en la página225.

Esta edición se aplica a la versión 4.2 de IBM Tivoli Network Manager IP Edition (número de producto 5724-S45) y atodos los releases y las modificaciones posteriores hasta que se indique lo contrario en nuevas ediciones.© Copyright International Business Machines Corporation 2006, 2021.

Contenido

Acerca de esta publicación...................................................................................viiPublicaciones..............................................................................................................................................viiAccesibilidad..............................................................................................................................................viiiFormación técnica de Tivoli......................................................................................................................... xInformación de soporte y comunidad..........................................................................................................x

Capítulo 1. Descargar Network Manager.................................................................1

Capítulo 2. Planificación para la instalación........................................................... 3Despliegue de Network Manager.................................................................................................................3

Situaciones de despliegue..................................................................................................................... 3Consideraciones sobre el despliegue.................................................................................................. 14Ejemplos de despliegue....................................................................................................................... 16

Comprobación de los requisitos del sistema............................................................................................ 21Dominios de red......................................................................................................................................... 21

Recopilación de sucesos utilizando varios dominios por ObjectServer............................................. 22Visualización de ejemplo de la topología desde varios dominios.......................................................23

Requisitos de hardware............................................................................................................................. 24Pautas de selección del procesador.................................................................................................... 24Requisitos para ejecutar el instalador................................................................................................. 25Requisitos para los componentes principales.....................................................................................25Requisitos para los componentes de la GUI....................................................................................... 27Requisitos para el servidor de base de datos de topología................................................................ 27Espacio de disco para sucesos e interfaces........................................................................................ 28Requisitos del espacio de intercambio (UNIX)....................................................................................28Requisitos de la memoria de descubrimiento.....................................................................................28

Requisitos de software.............................................................................................................................. 29Requisitos de compatibilidad para otros productos........................................................................... 29Bases de datos de topología soportadas.............................................................................................31Sistemas operativos soportados..........................................................................................................31Navegadores soportados para las aplicaciones web.......................................................................... 33Herramientas del sistema operativo....................................................................................................33Requisitos de usuario de UNIX............................................................................................................ 33Requisitos del directorio de instalación.............................................................................................. 34Requisitos del descriptor de archivos..................................................................................................34Requisitos de contraseña.....................................................................................................................35

Requisitos de red....................................................................................................................................... 35Lista de puertos utilizados por el producto......................................................................................... 35requisitos de DNS.................................................................................................................................37Requisitos de ancho de banda para el descubrimiento...................................................................... 37

Acerca de DNCIM.......................................................................................................................................38Instalaciones de FIPS 140-2.....................................................................................................................38

Capítulo 3. Preparación para la instalación...........................................................41Ejecución de la instalación y procedimientos de mantenimiento como root o no root...........................41Configuración de Red Hat Linux Enterprise Edition.................................................................................. 41Tareas previas a la instalación para AIX................................................................................................... 41

Configuración de SSH...........................................................................................................................42Instalación de un programa de utilidad zip....................................................................................... 42Comprobación de los valores de puerto de terminación de E/S (IOCP).............................................42

iii

Capítulo 4. Instalación de Network Manager y productos relacionados..................45Lista de comprobación para la instalación................................................................................................45Instalación y configuración de IBM Installation Manager........................................................................48

Instalación de IBM Installation Manager descargando los archivos del producto............................ 48Instalación de IBM Installation Manager conectando directamente con Passport Advantage........ 49

Instalación y configuración de una base de datos de topología.............................................................. 51Instalación y ejecución de los scripts de base de datos de Network Manager..................................52Configuración de bases de datos Db2 existentes en UNIX.................................................................52Instalación y configuración de bases de datos de Oracle en UNIX.................................................... 54Configuración de NCIM para usar caracteres multibyte..................................................................... 56

Instalación y configuración de Tivoli Netcool/OMNIbus.......................................................................... 57Opciones de línea de mandatos para ConfigOMNI............................................................................. 58

Instalación de los componentes principales de Network Manager......................................................... 59Instalación de WebSphere Application Server......................................................................................... 63Instalación de Dashboard Application Services Hub................................................................................64Instalación de GUI web de Tivoli Netcool/OMNIbus................................................................................67Instalación de los componentes de la GUI de Network Manager............................................................68Instalación y configuración de Cognos Analytics..................................................................................... 71

Instalación de informes de Network Manager.................................................................................... 73Instalación del Panel de instrumentos de estado de red (sólo clientes de Netcool Operations

Insight)..................................................................................................................................................75Instalación y desinstalación de fixpacks.................................................................................................. 75Tareas posteriores a la instalación............................................................................................................75

Capítulo 5. Desinstalación de Network Manager................................................... 79Aplicaciones de la GUI...............................................................................................................................79Informes.....................................................................................................................................................80Componentes principales de Network Manager y Tivoli Netcool/OMNIbus............................................81WebSphere Application Server..................................................................................................................82

Capítulo 6. Instalación y desinstalación de fixpacks............................................. 83Instalación de fixpacks..............................................................................................................................83

Aplicación de actualizaciones de esquema.........................................................................................85Comprobación de actualizaciones de esquema..................................................................................86

Desinstalación de fixpacks........................................................................................................................ 86

Capítulo 7. Integración........................................................................................ 89Tivoli Netcool/OMNIbus............................................................................................................................ 90

Configuración de ObjectServer para su uso con los procesos principales de Network Manager......90Configuración del repositorio de usuarios...........................................................................................91Configuración del nombre de origen de datos de GUI web de Tivoli Netcool/OMNIbus...................92Configuración de los tipos de sucesos de topología........................................................................... 92Instalación y configuración de sondas................................................................................................ 93Instalación de Knowledge Library....................................................................................................... 93Referencia de integración de Tivoli Netcool/OMNIbus.......................................................................93

Netcool Configuration Manager...............................................................................................................108CCMDB, TADDM y TBSM.......................................................................................................................... 109

Requisitos previos..............................................................................................................................109Configuración del DLA........................................................................................................................110Creación de un libro de biblioteca de descubrimiento..................................................................... 116Ajuste preciso de la exportación de datos........................................................................................ 117Carga de los libros de biblioteca de descubrimiento y habilitación del inicio bidireccional............123Configuración de TADDM para iniciar Network Manager.................................................................. 123Configuración de Network Manager para iniciar TADDM.................................................................. 124Importación de los GUID de TADDM en la base de datos NCIM...................................................... 126Integración con TBSM........................................................................................................................127

iv

Configuración de Dashboard Application Services Hub ........................................................................ 127IBM Tivoli Monitoring...............................................................................................................................127

IBM Tivoli Monitoring for IBM Tivoli Network Manager IP Edition................................................... 127Instalación y configuración................................................................................................................128

Acceso a datos de descubrimiento desde dNCIM..................................................................................136

Capítulo 8. Actualización y migración................................................................. 137Acerca de la actualización.......................................................................................................................137

Vías de acceso de actualización y limitaciones.................................................................................137Ubicaciones predeterminadas para las distintas versiones del producto....................................... 137Qué datos se migran.......................................................................................................................... 138

Actualización de Network Manager........................................................................................................ 140Preparación para la actualización......................................................................................................140Actualización de la base de datos..................................................................................................... 140Migración de los componentes principales.......................................................................................141Migración de los componentes de GUI............................................................................................. 147Migración de topología de red........................................................................................................... 151

Capítulo 9. Configuración...................................................................................157Configuración de las propiedades de conexión NCIM............................................................................157Configuración de la longitud y el tipo de cifrado.................................................................................... 157Configuración de Network Manager para los sistemas operativos UNIX.............................................. 158

Configuración de permisos root/no root........................................................................................... 159Carga de información de MIB actualizada.........................................................................................161

Configuración de Cognos Analytics.........................................................................................................162Configuración de informes para las instalaciones existentes...........................................................163

Habilitación del sondeo histórico............................................................................................................163Habilitación de la migración tras error....................................................................................................163

Acerca de la migración tras error.......................................................................................................164Sobre la alta disponibilidad de base de datos de topología NCIM................................................... 164Arquitecturas de migración tras error............................................................................................... 166Funcionamiento de migración tras error........................................................................................... 174Limitaciones de la migración tras error............................................................................................. 181Configuración de migración tras error............................................................................................... 182Solución de problemas de la migración tras error............................................................................ 200

Configuración de la seguridad.................................................................................................................205Configuración de cookies...................................................................................................................205Protección contra clickjacking........................................................................................................... 206

Cambio de la dirección IP y el nombre de host de la instalación de Network Manager........................206Para Network Manager.......................................................................................................................206En el servidor OMNIbus..................................................................................................................... 207Actualización de Network Manager para una dirección IP de OMNIbus modificada...................... 208Actualización de DASH para una dirección IP de OMNIbus modificada.......................................... 208En el servidor DASH........................................................................................................................... 209Actualización de Network Manager para el nombre de host DASH modificado.............................. 209Configuración de Network Manager para una dirección IP modificada del servidor de Db2 NCIM 210

Establecimiento de variables de entorno............................................................................................... 210Estructura de directorios predeterminada............................................................................................. 211Configuración de los dispositivos de Juniper PE.................................................................................... 215Configuración de dominios......................................................................................................................215

Adición de dominios de red............................................................................................................... 215Enlace de un dominio a un controlador de interfaz de red (NIC)..................................................... 217

Configuración de una base de datos dNCIM en Linux on IBM z Systems..............................................218Configuración del ayudante de SNMP.....................................................................................................219

Configuración de la regulación del ayudante de SNMP.................................................................... 219Configuración del soporte de GetBulk para SNMP v2 y v3............................................................... 220

Configuración de la autenticación...........................................................................................................222

v

Cambio del método de autenticación de usuario..............................................................................223Configuración de la autenticación del Proveedor de servicios de OQL............................................ 223

IBM Support Assistant (ISA)................................................................................................................... 224Instalación del recopilador de IBM Support Assistant Lite.............................................................. 224

Avisos............................................................................................................... 225Marcas registradas.................................................................................................................................. 227

vi

Acerca de esta publicación

La publicación IBM Tivoli Network Manager IP Edition: Guía de instalación y configuracióndescribe cómoinstalar Network Manager. También describe tareas obligatorias y opcionales de configuración posterioresa la instalación. Esta publicación está destinada a administradores que deben instalar y configurarNetwork Manager.

PublicacionesEsta sección lista publicaciones en la biblioteca de Network Manager y documentos relacionados. Lasección también describe cómo acceder a publicaciones de IBM en línea y cómo solicitar publicaciones.

Su biblioteca de Network ManagerLa siguiente documentación está disponible en la biblioteca de Network Manager:

• El IBM Tivoli Network Manager IP Edition Release Notes proporciona información importante y de últimahora sobre Network Manager. Esta publicación está destinada a gestores de despliegue yadministradores y debe leerse primero.

• La publicación IBM Tivoli Network Manager IP Edition: Guía de instalación y configuracióndescribe cómoinstalar Network Manager. También describe tareas obligatorias y opcionales de configuraciónposteriores a la instalación. Esta publicación está destinada a administradores que deben instalar yconfigurar Network Manager.

• El IBM Tivoli Network Manager IP Edition Administration Guide describe tareas de administración comoiniciar y detener el producto, descubrir la red, sondear la red, gestionar sucesos, administrar procesos yconsultar bases de datos. Esta publicación está destinada a administradores responsables delmantenimiento y disponibilidad de Network Manager.

• El Referencia de IBM Tivoli Network Manager tiene información de referencia, inclusive el lenguaje delsistema, las bases de datos, y el API de Perl utilizado por Network Manager. Esta publicación estádestinada a usuarios avanzados que necesitan personalizar el funcionamiento de Network Manager.

Publicaciones de requisito previoPara utilizar la información de esta publicación de forma efectiva, debe tener algún conocimiento derequisito previo, que puede obtener desde las siguientes publicaciones:

• IBM Tivoli Netcool/OMNIbus Installation and Deployment Guide

Incluye procedimientos de instalación y actualización, y describe cómo configurar la seguridad y lascomunicaciones de componentes. La publicación también contiene ejemplos de las arquitecturas deTivoli Netcool/OMNIbus y describe cómo implementarlas.

• IBM Tivoli Netcool/OMNIbus User's Guide

Proporciona una visión general de las herramientas de escritorio y describe las tareas del operadorrelacionadas con la gestión de sucesos utilizando estas herramientas.

• IBM Tivoli Netcool/OMNIbus Administration Guide

Describe cómo realizar tareas administrativas utilizando la GUI de administrador de Tivoli Netcool/OMNIbus, herramientas de la línea de mandatos y control de procesos. Esta publicación tambiéncontiene descripciones y ejemplos de sintaxis y automatizaciones de ObjectServer SQL.

• IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide

Contiene información de introducción y referencia acerca de sondas y pasarelas, lo que incluye lasintaxis de archivo de reglas de sonda y mandatos de pasarela.

• IBM Tivoli Netcool/OMNIbus Web GUI Administration and User's Guide

© Copyright IBM Corp. 2006, 2021 vii

Describe cómo realizar tareas administrativas y de visualización de sucesos mediante la GUI web deTivoli Netcool/OMNIbus.

Acceso a la terminología en líneaEl sitio web de terminología de IBM consolida la terminología desde las bibliotecas de productos de IBMen una ubicación conveniente. Puede acceder al Sitio web de terminología en la siguiente dirección web:

http://www.ibm.com/software/globalization/terminology

Acceso a las publicaciones en líneaIBM publica publicaciones para este y todos los demás productos, en cuanto están disponibles y siempreque se actualizan, en el sitio web de IBM Knowledge Center en:

http://www.ibm.com/support/knowledgecenter/

La documentación de Network Manager está ubicada en el nodo Cloud & Smarter Infrastructure en esesitio web.

Nota: Si imprime documentos PDF en papel distinto a tamaño de carta, establezca la opción en la ventanaArchivo > Imprimir que permite a su aplicación de lectura de PDF imprimir páginas de tamaño de cartaen su papel local.

Solicitud de publicacionesPuede solicitar muchas publicaciones de IBM en línea en el siguiente sitio web:

http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss

También puede pedir por teléfono llamando a uno de estos números:

• En Estados Unidos: 800-879-2755• En Canadá: 800-426-4968

En otros países, póngase en contacto con el representante de cuentas de software para pedirpublicaciones de IBM. Para ubicar el número de teléfono de su representante local, realice los pasossiguientes:

1. Vaya al siguiente sitio web:

http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss2. Seleccione el país en la lista y pulse Go (Ir). La página Bienvenido al Centro de publicaciones de IBM

se muestra para su país.3. En el lado izquierdo de la página, haga clic en Acerca de este sitio para ver una página de información

que incluya el número de teléfono de su representante local.

AccesibilidadLas características de accesibilidad ayudan a los usuarios con una discapacidad física, como movilidadrestringida o visión limitada, para utilizar productos de software satisfactoriamente.

Características de accesibilidadNetwork Manager incluye las siguientes funciones de accesibilidad principales:

• Operaciones que utilizan un lector de pantalla.

Network Manager utiliza IBM Installation Manager para instalar el producto. Puede obtener informaciónacerca de las funciones de accesibilidad para IBM Installation Manager en https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html.

viii Acerca de esta publicación

http://www.ibm.com/software/globalization/terminology

http://www.ibm.com/support/knowledgecenter/



https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html


Network Manager utiliza el último estándar W3C, http://www.w3.org/TR/wai-aria/, para garantizar elcumplimiento de http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards) y http://www.w3.org/TR/WCAG20/. Para aprovecharlas funciones de accesibilidad, utilice el release más reciente de su lector de pantalla en combinación conel navegador web más reciente que admita este producto.

La documentación del producto en línea Network Manager en IBM Knowledge Center está habilitada parala accesibilidad. Las funciones de accesibilidad de IBM Knowledge Center se describen en https://www.ibm.com/support/knowledgecenter/v1/content/about/releasenotes.html#accessibility.

Navegación por tecladoEste producto utiliza teclas de navegación estándar.

Información de interfazNetwork Manager proporciona las siguientes características adecuadas para usuarios con poca visión:

• Todo el contenido no textual utilizado en la GUI tiene texto alternativo asociado.• Los usuarios de visión baja pueden ajustar los valores de visualización del sistema, incluida la

modalidad de alto contraste, y pueden controlar los tamaños de fonts utilizando los valores delnavegador.

• El color no se utiliza como el único medio visual para transmitir información, indicar una acción, solicitaruna respuesta o distinguir un elemento visual.

Network Manager proporciona las siguientes características adecuadas para usuarios epilépticosfotosensibles:

• Las interfaces de usuario de Network Manager no tienen contenido que parpadee más de dos veces enun periodo de un segundo.

La interfaz de usuario de web de Network Manager incluye puntos de referencia de navegación WAI-ARIA,que puede utilizar para navegar rápidamente a áreas funcionales en la aplicación.

Pasos extra para configurar Internet Explorer para la accesibilidadSi utiliza Internet Explorer como su navegador web, puede que necesite realizar pasos de configuraciónextra para habilitar las características de accesibilidad.

Para habilitar la modalidad de alto contraste, realice los pasos siguientes:

1. Haga clic en Herramientas > Opciones de Internet > Accesibilidad.2. Marque todos los recuadros de selección de la sección Formato.

Si al hacer clic en Vista > Tamaño del texto > El más grande no aumenta el tamaño de la font, haga clicen Ctrl + y Ctrl -.

Información relacionada sobre accesibilidadAdemás de los sitios web de soporte y atención al cliente de IBM estándar, IBM ha establecido un serviciode teléfono de texto (TTY) especial para personas sordas o con deficiencias auditivas, para que puedanacceder a los servicios de soporte y ventas:

Servicio TTY800-IBM-3383 (800-426-3383)(en Norteamérica)

IBM y la accesibilidadPara obtener más información sobre el compromiso de IBM con la compatibilidad, consulte https://www.ibm.com/able.

Acerca de esta publicación ix

http://www.w3.org/TR/wai-aria/

http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards

http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards

http://www.w3.org/TR/WCAG20/

https://www.ibm.com/support/knowledgecenter/v1/content/about/releasenotes.html#accessibility

https://www.ibm.com/support/knowledgecenter/v1/content/about/releasenotes.html#accessibility

https://www.ibm.com/able

https://www.ibm.com/able

Formación técnica de TivoliPara obtener más información sobre la formación técnica de Tivoli, consulte el siguiente sitio web deeducación de IBM Tivoli:

https://www.ibm.com/training/search?query=tivoli

Información de soporte y comunidadUtilice el soporte de IBM, Service Management Connect y los grupos de usuarios de Tivoli para conectarcon IBM y obtener la ayuda y la información que necesita.

Soporte de IBMSi tiene un problema con el software de IBM, debe resolverlo lo antes posible. IBM proporciona lassiguientes maneras para que obtenga el soporte que necesita:

En líneaVaya al sitio web de Soporte de software de IBM en https://www.ibm.com/support/home/ y siga lasinstrucciones.

IBM Support AssistantEl IBM Support Assistant (ISA) es un área de trabajo gratuita de facilidad de mantenimiento desoftware local que ayuda a resolver preguntas y problemas con los productos de software de IBM. ElISA proporciona un acceso rápido a herramientas de facilidad de mantenimiento y a informaciónrelacionada con el soporte para la determinación de problemas. Para instalar el software ISA, vaya ahttps://www.ibm.com/support/knowledgecenter/SSLLVC/welcome/isa_welcome.html.

Service Management ConnectAcceda a Service Management Connect en https://www.ibm.com/developerworks/community/groups/service/html/communitystart?communityUuid=cdd16df5-7bb8-4ef1-bcb9-cefb1dd40581. UtiliceService Management Connect de las siguientes maneras:

• Implíquese en el desarrollo transparente, para fomentar la participación abierta y continua de otrosusuarios y desarrolladores de IBM de productos de Tivoli. Puede acceder a diseños preliminares,demostraciones rápidas, hojas de ruta de productos y código previo al release.

• Póngase en contacto de forma privada con los expertos para colaborar y trabajar en red con Tivoli y lacomunidad.

• Lea los blogs para beneficiarse de la experiencia de otros.• Utilice los wikis y foros para colaborar con la comunidad de usuarios más amplia.

x IBM Tivoli Network Manager IP Edition: Guía de configuración e instalación

https://www.ibm.com/training/search?query=tivoli

https://www.ibm.com/support/home/

https://www.ibm.com/support/knowledgecenter/SSLLVC/welcome/isa_welcome.html

https://www.ibm.com/developerworks/community/groups/service/html/communitystart?communityUuid=cdd16df5-7bb8-4ef1-bcb9-cefb1dd40581

https://www.ibm.com/developerworks/community/groups/service/html/communitystart?communityUuid=cdd16df5-7bb8-4ef1-bcb9-cefb1dd40581

Capítulo 1. Descargar Network ManagerEl procedimiento para descargar el producto difiere para lanzamientos de Disponibilidad general (GA) y fixpacks.

Antes de empezarNota: Si utiliza Network Manager como parte de una solución, también debe verificar la compatibilidad delas versiones de todos los productos componentes en la documentación de la solución. Por ejemplo, siutiliza Netcool Operations Insight, compruebe la matriz de versión de producto y componente para suversión de Netcool Operations Insight en https://www.ibm.com/support/knowledgecenter/en/SSTPTP.

Acerca de esta tareaPara descargar el producto, ubique su versión en la siguiente tabla:

Tabla 1. Ubicaciones de descarga

Versión del producto Ubicación de descarga Más información

4.2 Fix Pack 12 Fix Central

https://www.ibm.com/support/fixcentral/

https://www.ibm.com/support/docview.wss?uid=ibm16364949















http://www.ibm.com/support/docview.wss?uid=ibm10886151






http://www.ibm.com/support/docview.wss?uid=swg24044739

© Copyright IBM Corp. 2006, 2021 1

https://www.ibm.com/support/knowledgecenter/en/SSTPTP

































Tabla 1. Ubicaciones de descarga (continuación)

Versión del producto Ubicación de descarga Más información




4.2 Fix Pack 3 Passport Advantage

http://www.ibm.com/software/howtobuy/passportadvantage/pao_customers.htm




https://www.ibm.com/support/docview.wss?uid=swg24042981




4.2 Passport Advantage



2 IBM Tivoli Network Manager IP Edition: Guía de configuración e instalación























Capítulo 2. Planificación para la instalaciónLea las consideraciones sobre despliegue y los requisitos del sistema para Network Manager.

Antes de empezarConsulte la documentación de planificación de todos los productos que desea integrar con NetworkManager. Por ejemplo, si está instalando IBM Tivoli Netcool Configuration Manager, consulte lapublicación IBM Tivoli Netcool Configuration Manager Integration Guide.

Nota: Si utiliza Network Manager como parte de una solución, también debe verificar la compatibilidad delas versiones de todos los productos componentes en la documentación de la solución. Por ejemplo, siutiliza Netcool Operations Insight, compruebe la matriz de versión de producto y componente para suversión de Netcool Operations Insight en https://www.ibm.com/support/knowledgecenter/en/SSTPTP.

Despliegue de Network ManagerUtilice esta información para obtener una guía sobre cómo configurar el despliegue físico de suinstalación de Network Manager.

Situaciones de despliegueEl despliegue de Network Manager depende de su entorno, incluidos factores como el tamaño y lacomplejidad de su red y el número de personal de operaciones que requiere el acceso al sistema.

A continuación se muestran situaciones de despliegue de Network Manager típicas:

• Pequeña demostración o despliegue del sistema educativo• Pequeña red de clientes• Red de clientes mediana• Red de clientes de grandes dimensiones• Red de clientes de muy grandes dimensiones

Un escenario de despliegue más detallado sería el siguiente: Empresa de telecomunicaciones o red deproveedor de servicios

Nota: La migración tras error se puede aplicar a cada uno de estos despliegues de Network Manager.

Esta sección proporciona una guía general para ayudarle a decidir cómo desplegar Network Manager.Para obtener información más detallada, consulte la publicación IBM Tivoli Network Manager IP Edition:Guía de instalación y configuración y las IBM Tivoli Network Manager IP Edition Release Notes.

Comparaciones de la red y del despliegueUtilice esta información para comparar las redes de clientes de ejemplo y para comparar los desplieguesde Network Manager para cada una de las redes de clientes de ejemplo.

Redes de cliente comparadasUtilice esta información para comparar las redes de clientes de ejemplo y para identificar qué ejemplocoincide más acertadamente con su red.

La tabla siguiente lista características típicas para cada una de las redes de clientes de ejemplo. Estosvalores son únicamente valores de ejemplo. Sus valores de red específicos pueden variar. En particular,debería tener en cuenta lo siguiente:

• Con respecto a los valores para Número medio de interfaces por dispositivo especificado en esta tabla,los recuentos de interfaz reales pueden variar considerablemente desde el recuento de interfaz medio.Un ejemplo de esto se encuentra en las redes MPLS, donde el número de interfaces por dispositivo es



muy alto en la red principal, pero podría ser tan bajo como de 2 a 3 interfaces por dispositivo para losdispositivos del cliente.

• Con respecto al número de dispositivos para una empresa de telecomunicaciones, el valor especificado(15.000) es un valor medio. Una empresa de telecomunicaciones nacional tendrá un número muchomás grande de dispositivos, una empresa de telecomunicaciones local pequeña tendrá muchos menos.

Tabla 2. Ejemplo de redes de clientes comparadas

Característica

Demostración

Empresa Empresa detelecomun.Pequeña Mediana Grande Muy grande

Número dedispositivos

25 De 150 a 300 De 250 a5.000

De 5.000 a15.000

De 15.000 a30.000

15.000

Númeromedio deinterfaces pordispositivo

1-2 3-5 20-30 30 o más 30 o más 1.200

Ubicacionesde red

Ubicaciónúnica

Ubicaciónúnica

Distribuida Red global Red global,gestióndistribuida

Una o másubicaciones

Infraestructura de red

Sin formato Sin formato Sin formato Compleja Compleja Compleja

Número declientes de laGUI activos

De 1 a 3 3 De 5 a 20 De 5 a 20 De 5 a 20 De 5 a 20

Ejemplos desondeo deping de chasis

Valoresestablecidospara fines dedemostración

Intervalos de2 minutos

De 2 a 5minutos

De 2 a 5minutos

De 2 a 5minutos

De 2 a 5minutos

Ejemplos desondeo deSNMP

Valoresestablecidospara fines dedemostración

De 3 a 6valores enintervalos de30 minutos

Intervalos de5 a 15minutos

Intervalos de10 a 15minutos.

Intervalos de15 minutos omás

5 valores enintervalos de5 minutos

Sondeo de SNMP v1, 2c o 3 en cualquiera de los entornos listados

Sondeos de dispositivo e interfaz en cualquiera de los entornos listados.

Integracionesde productosde Tivoli

Ninguno Ninguno Ninguno NetcoolOperationsInsight

TADDM

NetcoolOperationsInsight

TADDM

NetcoolOperationsInsight

TADDM

Despliegues de Network Manager comparadosUtilice esta información para comparar los despliegues de Network Manager para cada una de las redesde clientes de ejemplo.

La tabla siguiente lista la configuración requerida para los despliegues de Network Manager para cadauna de las redes del cliente de ejemplo. Estos valores son únicamente valores de ejemplo. Los valoresque son apropiados para su despliegue específico pueden variar.

Nota: Con respecto a los valores para Despliegue especificados en esta tabla, estos valores no tienen encuenta los servidores de migración tras error.


Tabla 3. Ejemplo de despliegues de Network Manager comparados

Configuración

Demostración

Empresa Empresa detelecomun.Pequeña Mediana Grande Muy grande

Plataforma Linux® x86 Cualquierplataformasoportada

Cualquierplataformasoportada

Linux Linux Cualquierplataformasoportada

Despliegue Servidor único Servidor único 1- 2servidores

3-4servidores

4 o másservidores

3 servidores

Sistema delcliente

Procesador único

2 GB de DRAM mínimos, o 4 GB de DRAM para redes de gran tamaño

JRE y navegador de Internet soportados

Base de datosde topología

Base de datospredeterminada

Base de datospredeterminada

RDBMS Db2 uOracle

RDBMS Db2 uOracle

RDBMS Db2 uOracle

RDBMS Db2 uOracle

Número dedominios dered

1 1 1 - 2 2 o más 2 o más 1 - 2

Número demotores desondeobasados en eltamaño de lared

1 1 Tenga encuenta másde unsondeador

Tenga encuenta másde unsondeador



Motivos para dominios múltiplesHay un número de motivos por los que necesita particionar su red en varios dominios.

Puede que sea necesario que particione su red en varios dominios por uno de los siguientes motivos:

• Su red supera un cierto tamaño. Consulte la sección Pautas para un número de dominios de red paradeterminar si su red requiere varios dominios.

• El descubrimiento lleva mucho tiempo. Puede reducir sus tiempos de descubrimiento particionando sured en varios dominios.

• Los límites operativos dictan la necesidad de varios dominios. Algunos ejemplos de límites operativosincluyen límites geográficos y límites de seguridad.

• Su red contiene direcciones IP que se solapan.

Consejo:

Si tiene pensado ejecutar descubrimientos de dominios cruzados para visualizar enlaces entre losdistintos dominios, debe tener en cuenta cómo afectan los límites entre dominios a los enlaces dedominios cruzados. En concreto, asegúrese de elegir límites de dominio con un número mínimo deenlaces de dominios cruzados.

Pautas para un número de dominios de redSi su red supera un tamaño determinado, puede que sea necesario descomponer la red en variosdominios. Utilice esta información para detectar el número de dominios de red necesarios para sudespliegue.

Según el sistema operativo, un único dominio de Network Manager puede dar soporte aaproximadamente 1.000.000 entidades de red creadas durante una operación de descubrimiento. Lasentidades de red incluyen los puertos, las interfaces (incluidos los elementos de interfaz lógica), las

Capítulo 2. Planificación para la instalación 5

tarjetas, las ranuras y los chasis. En teoría, es posible incluir más entidades de red en un único dominio,pero el descubrimiento podría tardar mucho en completarse.

En Linux de 64 bits, la cantidad máxima de memoria permitida para un proceso de Network Managerindividual no está limitada de forma arbitraria, pero depende de cuánta memoria se instale en el servidor.

Normalmente, el proceso de descubrimiento (ncp_disco) y el proceso del modelo de topología(ncp_model) utilizan la máxima memoria.

El número de entidades de red que crea una operación de descubrimiento depende de una serie defactores que podrían necesitar que cree y configure dominios de red adicionales. Estos factores incluyenlos siguientes:

• Tipos de dispositivo: por ejemplo, un direccionador Cisco NEXUS o Juniper con instancias dedireccionador virtuales puede aportar cientos o miles de entidades de red (puertos, interfaces, tarjetas,ranuras, etc.) por chasis.

• Tipo de red: por ejemplo, una operación de descubrimiento realizada en una red de área local (LAN)normalmente aporta más entidades de red que una red de área amplia (WAN) de un tamaño similar.

• Tipo de los agentes de descubrimiento habilitados: por ejemplo, los agentes de descubrimiento Entity yJuniperBoxAnatomy son agentes de descubrimiento basados en inventario que normalmente creanentidades de red adicionales que otros agentes no crean.

• Red direccionada o conmutada: por ejemplo, las redes conmutadas tienden a generar más entidades dered que las redes direccionadas, ya que contienen VLAN, que contienen varias entidades.

El tamaño de un dominio de Network Manager puede estar sujeto a requisitos de negocio. Por ejemplo, uncliente podría necesitar que un descubrimiento de red se complete dentro de periodos de mantenimientodiario definidos. En este caso de ejemplo, aunque un único dominio de Network Manager que se ejecuteen sistemas UNIX puede soportar aproximadamente 1 millón de entidades de red, la cantidad de tiempoque se tarda en completar un descubrimiento de ese tamaño podría no ajustarse al periodo demantenimiento diario. En consecuencia, harán falta dos dominios acotados, cada uno de ellos con unas500.000 entidades de red, para dar soporte a este requisito empresarial.

Utilice el procedimiento siguiente para determinar el número de dominios requeridos. Para obtenerinformación sobre cómo crear y configurar dominios de red extra, consulte la publicación IBM TivoliNetwork Manager IP Edition: Guía de instalación y configuración.

Nota: Los cálculos presentados aquí proporcionan únicamente cifras aproximadas. El número real dedominios necesario varía en función de diversos factores, incluyendo los factores descritosanteriormente.

1. Recopile los datos siguientes:

• Número de dispositivos en la red• Número medio de interfaces por dispositivo

Nota: Los recuentos reales de una interfaz en un dispositivo determinado pueden variarconsiderablemente del recuento de interfaz medio. Un ejemplo de esto se encuentra en las redesMPLS, donde el número de interfaces por dispositivo es muy alto en la red principal, pero podría sertan bajo como de 2 a 3 interfaces por dispositivo para los dispositivos del cliente.

2. Aplique la siguiente ecuación para determinar un número aproximado de entidades de red:

Número de entidades de red = Número de dispositivos * Recuento de interfaces medio * multiplicador

Donde:

• multiplicador = 2 para una red direccionada• multiplicador = 3,5 para una red conmutada

Nota: Las redes conmutadas tienden a generar más entidades de red dado que contienen VLAN, quecontienen varias entidades.

3. Aplique la siguiente ecuación para determinar el número sugerido de dominios de red:

Número de dominios necesarios = (Número de entidades de red) / 1.000.000


Nota: El número máximo sugerido de entidades de red no es más que una estimación para eldimensionamiento de dominios. El número real de entidades de red por dominio varía en función dediversos factores, incluyendo los factores descritos anteriormente.

Cliente centrado en un direccionador

Los datos para este cliente son como siguen:

• Número de dispositivos en la red 60.000• Número medio de interfaces por dispositivo 20

La red del cliente producirá aproximadamente 2.400.000 entidades de red:

Número de entidades de red = 60.000 * 20 * 2 = 2.400.000

Basado en el siguiente cálculo, esta red requiere tres dominios de red:

Número de dominios necesarios = 2.400.000 / 1.000.000 > 2

Cliente centrado en el conmutador

Los datos para este cliente son como siguen:

• Número de dispositivos en la red 1.000• Número medio de interfaces por dispositivo 24

Esta red de cliente producirá aproximadamente 84.000 entidades de red:Número de entidades de red = 1.000 * 24 * 3,5 = 84.000

Basándose en el siguiente cálculo, esta red requiere un dominio de red:Número de dominios requeridos = 84.000 / 1.000.000 < 1

Conceptos relacionadosDominios de redAntes de la instalación, tiene que tener en cuenta si partirá su red en dominios, o si tendrá un únicodominio para toda la red. Un dominio de red es una colección de entidades de red preparadas para serdescubiertas y gestionadas.

Demostración o despliegue del sistema educativoEsta es una instalación de reducido tamaño para su utilización como un sistema de demostración o parafines de formación y educativos.

Las siguientes secciones describen esta red en mayor detalle y proporcionan sugerencias para undespliegue de Network Manager para que cumpla las necesidades de esta red.

DescripciónEste entorno consta de cerca de 25 dispositivos de red y de servidores clave combinados. Todos losdispositivos se encuentran en una ubicación, en la misma subred de red que los dispositivos que segestionarán. Hay una sesión de cliente de GUI local soportado por la misma máquina que aloja loscomponentes del producto de Network Manager. Puede haber una o dos sesiones del cliente de la GUI enotras máquinas. Los dispositivos de red vienen de varios proveedores. La arquitectura de red no tieneformato. Todos los dispositivos están adjuntos a una LAN y tienen conexiones de Fast Ethernet.Únicamente para fines de demostración, un número de dispositivos de red tienen SNMPv3, y un númerode estaciones de trabajo tienen IPv6.

Dentro de este entorno se aplican las siguientes condiciones de ejemplo:

• De 1 a 3 clientes de la GUI activos.• Se requiere el sondeo de ping de chasis y alguna actividad de sondeo de SNMP.• No se integrarán productos mayores de Tivoli con el sistema, a excepción del Tivoli Netcool/OMNIbus

requerido.


• Se requieren los informes de rendimiento para los periodos cortos de recopilación de datos(normalmente, de 1 a 5 días) para hacer coincidir la longitud del curso de formación.

Despliegue de Network ManagerUn despliegue de un único servidor es suficiente para este tipo de entorno. Además de la descripción deldespliegue de servidor único proporcionada en otro lugar, los siguientes valores de despliegue sonapropiados para este tipo de entorno.

• El sistema es una máquina de clase de estación de trabajo de entrada, con 8 GB de memoria, conprocesador de núcleo dual preferido, de núcleo único aceptable, velocidad de procesador actualrazonable y capacidad de Fast Ethernet.

• La base de datos predeterminada utilizada para la base de datos de NCIM.• Sistema del cliente: procesador único, 4 GB de memoria, JRE soportado y navegador de Internet• El soporte de pila dual IPv6 es requerido si las estaciones de trabajo o los dispositivos de red tienen

IPv6.

Pequeña red de clientesEste cliente es una empresa con una red que consta de alrededor de 150-300 dispositivos de red yservidores clave. El fin de esta instalación es gestionar esta red de cliente alertando al personal deoperaciones de fallos graves.


DescripciónLos usuarios principales del producto son el personal de operaciones de red. Todos los dispositivos seencuentran en una ubicación y se gestionan mediante un pequeño grupo de operaciones de pocaspersonas. Los dispositivos de red vienen de varios proveedores. Está presente una mezcla de losdispositivos de red de capa 2 y de capa 3. Están definidos aproximadamente de 20 a 30 VLAN. Lainfraestructura de red es relativamente simple y no tiene formato. Todos los dispositivos que segestionarán se ubican en la misma red que el sistema de Network Manager y tienen conexiones de FastEthernet. Las conexiones de Internet se pasan a través de un cortafuegos y el acceso a los sistemasdentro de la red protegida está disponible mediante un VPN de la empresa. El personal de operaciones dered tiene clientes adjuntos mediante uno de los siguientes métodos: una LAN local, conexiones WiFi o pormedio de una VPN establecida mediante un proveedor de servicio de telecomunicaciones. Los cambiosde red se realizan una vez al mes y se anticipa un nuevo descubrimiento esta vez.


• 3 clientes de la GUI activos.• Sondeo de ping de chasis en intervalos de dos minutos. Sondeo de SNMP en intervalos de 30 minutos.

Normalmente, de 3 a 6 valores de MIB de SNMP requieren el sondeo.• No se integrarán productos mayores de Tivoli con el sistema, a excepción del Tivoli Netcool/OMNIbus

requerido.

Despliegue deNetwork ManagerUn despliegue de un único servidor es suficiente para este tipo de entorno. Además de la descripción deldespliegue de servidor único proporcionada en otro lugar, los siguientes valores de despliegue sonapropiados para este tipo de entorno.

• Un único dominio de red es suficiente para este tamaño de red.• El sistema puede ser cualquiera de las plataformas soportadas. El sistema requiere 16 GB de memoria,

un procesador de cuatro núcleos y varios discos físicos en la configuración de RAID 5.• Sistema del cliente: procesador único, 4 GB de memoria, JRE soportado y navegador de Internet• La base de datos predeterminada utilizada para la base de datos de NCIM.


• Un único motor de sondeo de ncp_poller es suficiente para este entorno.• El soporte de pila dual IPv6 es requerido si las estaciones de trabajo o los dispositivos de red tienen

IPv6.

Red de clientes medianaEste cliente es una empresa con un centro de datos importante central y conexiones a varios sitiosremotos. El fin de esta instalación es gestionar esta red de cliente alertando al personal de operacionesde fallos graves.


DescripciónEsta red tiene entre 250 y 5.000 dispositivos de red y servidores clave de interés. Las estaciones detrabajo, mientras se numeren entre los miles, no se gestionarán. Los dispositivos de red vienen de variosproveedores. Todos los dispositivos de la ubicación central tienen conexiones de Fast Ethernet o deGigabit Ethernet. Los sitios remotos están conectados mediante conexiones WAN. Los dispositivos yservidores que se gestionarán y distribuirán entre los sitios centrales y remotos.


• Hay de 5 a 20 clientes de la GUI activos.• Sondeo de ping de chasis en intervalos de dos a cinco minutos. Sondeo de SNMP en intervalos de 5 a 15

minutos.• Otros productos de Tivoli importantes integrados con el sistema, distintos al Tivoli Netcool/OMNIbus

requerido:

Despliegue deNetwork ManagerCada entorno de cliente con este tipo de red es distinto. La clave para el éxito es una memoria adecuada yuna comprensión cuidadosa de los destinos de sondeo, tasas de sondeo combinadas y las tasas desondeo. La configuración del despliegue siguiente es apropiada para este tipo de entorno.

• Se requieren uno o más dominios de red, en función del tamaño de la red.• Despliegue de servidor único (hasta 250 dispositivos de red y de 5 a 10 usuarios simultáneos).

Cuatro procesadores.Hasta 32 GB de memoria.Varios discos físicos en la configuración de RAID 5.

• Despliegue de dos servidores (hasta 5.000 dispositivos de red y de 10 a 20 usuarios simultáneos).

Cuatro procesadores para el sistema con Network Manager.Cuatro procesadores para el sistema con Tivoli Netcool/OMNIbus y Dashboard Application ServicesHub.Hasta 32 GB de memoria para cada servidor.Varios discos físicos en la configuración de RAID 5.

• El sistema puede ser cualquiera de las plataformas soportadas.• Sistema del cliente: procesador único, 4 GB de memoria, JRE soportado y navegador de Internet• RDBMS Db2 u Oracle utilizado para la base de datos de NCIM en el servidor con 4 procesadores y 32 GB

de RAM.• Número de motores de sondeo:

Despliegue de servidor único: 1Despliegue de dos servidores: Un sondeador para los pings de chasis, uno o más sondeadores parasondeos de SNMP.


• El soporte de pila dual IPv6 es requerido si las estaciones de trabajo o los dispositivos de red tienenIPv6.

Red de clientes de grandes dimensionesEste cliente es una empresa de grandes dimensiones con una red globalmente desplegada. El fin de estainstalación es gestionar esta red del cliente alertando al personal de operaciones de fallos graves ysoportar los últimos dispositivos de red e infraestructura de red.


DescripciónLa arquitectura de la red es compleja y contiene la tecnología más actualizada. Por ejemplo, la redcontiene redes principales de MPLS. El recuento del dispositivo de red va desde 5.000 a 15.000dispositivos, y la complejidad de la red se refleja en el hecho de que hay 30 o más puertos por dispositivode media. Las operaciones de red se realizan desde una ubicación central con personal de operacionesconstantemente supervisando la red principal. Los dispositivos de red vienen de varios proveedores.


• Hay normalmente de 5 a 20 clientes de la GUI activos de forma simultánea.• Sondeo:

Sondeo de ping de chasis en intervalos de dos a cinco minutos.Sondeo de SNMP a los 10-15 minutos.Sondeo de SNMPv3 de dispositivos de red clavesSondeo de SNMPv1 para la creación de gráficos en tiempo real así como del almacenamiento parainformes de rendimiento.

• Otros productos de Tivoli importantes integrados con el sistema, distintos al Tivoli Netcool/OMNIbusrequerido:

IBM® Tivoli Business Service Manager (TBSM)IBM Tivoli Application Dependency Discovery Manager (TADDM)

Despliegue deNetwork ManagerLas opciones de despliegue varían según el tamaño de la red. Para la red de 5000 dispositivos en esterango de clientes, la opción va desde un despliegue de servidor único a uno de dos servidores. Losfactores claves para el éxito incluyen el tiempo de respuesta de red para los destinos (dado que es uncondado o una distribución global de dispositivos de destino), la disponibilidad de la memoria en losservidores de soporte, el sondeo seleccionado y las tasas de sondeo.

Para la parte final superior de la red (aproximadamente 15.000 dispositivos), se requiere un desplieguede varios dominios distribuido. Además de la descripción de despliegue de varios servidoresproporcionada en otro lugar, los valores de despliegue siguientes son apropiados para este tipo deentorno.

• Desplegar dos dominios.• Despliegue de un servidor de base de datos dedicado.• Cada uno de los servidores requiere lo siguiente:

8 procesadores.Hasta 128 GB de memoria.3 discos, matriz de discos múltiple de RAID 5

• Para los sistemas utilizados, realice el despliegue según se indica a continuación:

Servidor 1: Network Manager con 36 GB de memoria.Servidor 2: Tivoli Netcool/OMNIbus y Dashboard Application Services Hub con hasta 12 GB dememoria.


Servidor 3: un RDBMS seleccionado por el cliente (Db2 u Oracle) con hasta 84 GB de memoria.• Sistemas que se desplegarán en la plataforma Linux o UNIX.• RDBMS Db2 u Oracle utilizado para la base de datos de NCIM.• Dos motores de sondeo:

Utilice el proceso predeterminado de ncp_poller para el ping de chasis.Cree un ncp_poller separado para los sondeos de SNMP.

• Sistema del cliente: procesador único, 4 GB de memoria, JRE soportado y navegador de Internet• El soporte de pila dual IPv6 es requerido si las estaciones de trabajo o los dispositivos de red tienen

IPv6.

Red de clientes de muy grandes dimensionesEste cliente es una empresa global de muy grandes dimensiones con una arquitectura de red sencillapero un número muy elevado de dispositivos. El fin de esta instalación es gestionar esta red del clientealertando al personal de operaciones de fallos graves y para soportar la planificación de la capacidad acorto plazo.


DescripciónLa gestión de red se realiza desde una ubicación central y desde ubicaciones regionales. La red es de muygrandes dimensiones y contiene más de 15.000 dispositivos de red y servidores críticos. Los dispositivosde red vienen de varios proveedores. Los dispositivos están dentro de dos categorías:

• La infraestructura de dispositivos de red con recuentos de interfaces en el rango de 30 o más pordispositivo.

• Dispositivos gestionados con 1-2 interfaces por dispositivo.

La mayor parte de los dispositivos se encuentran en la segunda categoría, dispositivos gestionados. Paragestionar una red de este tamaño, la red se parte para su gestión en una base geográfica.

En este entorno, se aplican las siguientes condiciones de ejemplo:

• Hay de 5 a 20 clientes de la GUI activos.• Sondeo:

Sondeo de ping de chasis en intervalos de dos a 5 minutos.Sondeo de SNMP a los 15 minutos o un tiempo superior.Recopilación de datos de SNMPv1

• Otros productos importantes de Tivoli que están integrados con el sistema, distintos a Tivoli Netcool/OMNIbus que es necesario:

IBM Tivoli Business Service ManagerIBM Tivoli Application Dependency Discovery Manager

Despliegue de Network ManagerPara un despliegue correcto, se recomienda utilizar la ayuda de un grupo de servicios de IBMexperimentado o de un IBM Business Partner cualificado. Son necesarios varios dominios, soportados poruna recopilación de servidores individuales, o en ejecución juntos en un sistema de muy grandesdimensiones. Tras investigar la red que se ha de gestionar, divida la red en secciones que se puedangestionar y, a continuación, asigne cada una de las secciones a un dominio. Además de la descripción dedespliegue de varios servidores proporcionada en otro lugar, los valores de despliegue siguientes sonapropiados para este tipo de entorno.

• Varios dominios de red.• Selecciones de plataforma: Linux y UNIX


• Los sistemas de gran tamaño (muchos procesadores y grandes cantidades de memoria) pueden alojarvarios dominios, si las asignaciones de memoria y los recuentos del procesador son aceptables.

Memoria: De 32 a 64 GB por dominioProcesadores: De 4 a 8 por dominio, en función de las cargas de trabajo

• RDBMS Db2 u Oracle utilizado para la base de datos de NCIM.• Dos motores de sondeo para cada dominio:


• Las limitaciones de la memoria del proceso individual son un factor de este entorno. Si está utilizandoAIX, habilite el acceso a memoria de gran volumen.


IPv6.

Red de empresa de telecomunicacionesEste cliente es una empresa de telecomunicaciones y un proveedor de servicios de Internet. El fin de estainstalación es gestionar esta red de cliente alertando al personal del centro de operaciones de red entodo momento de fallos graves.


DescripciónLa red que se gestionará tiene alrededor de 600 dispositivos de red; con un recuento de interfaz mediopor dispositivo de 500. Esta es una red MPLS y, por lo tanto, los dispositivos de red son “grandes” entérminos de sus recuentos y complejidad de la interfaz. Los dispositivos de red vienen de variosproveedores. Todos los dispositivos se encuentran en una o más ubicaciones y se gestionan mediante unpequeño grupo de operaciones de red. Todos los dispositivos que se gestionarán están conectadosmediante Fast Ethernet o Gigabit Ethernet.


• Número de clientes de activos simultáneamente: 5-20• Requisitos de sondeo: pings de chasis en intervalos de 2 a 5 minutos; sondeo de SNMP de 5 valores en

intervalos de 5 minutos.• Algún sondeo de SNMPv3 está en el lugar.• Otros productos de Tivoli importantes integrados con el sistema, distintos al Tivoli Netcool/OMNIbus

requerido:

IBM Tivoli Business Service Manager (TBSM)IBM Tivoli Application Dependency Discovery Manager (TADDM)

• Informes de rendimiento realizados una vez al día para dispositivos clave, utilizados para agruparinformes de capacidad semanal.

Despliegue deNetwork ManagerEs necesario un despliegue de tres servidores para este tipo de entorno. Además de la descripción dedespliegue de varios servidores proporcionada en otro lugar, los valores de despliegue siguientes sonapropiados para este tipo de entorno.

• De uno a dos dominios.• Se recomienda un despliegue de tres servidores.• Especificaciones del sistema:


Sistema 1 (donde está instalado Network Manager): cuatro procesadores, de 32 a 64 GB dememoria, dos o más discos. Tenga en cuenta que, con más de cuatro procesadores o núcleos deprocesador, la velocidad del reloj del núcleo y la memoria caché en chip pueden ser más grandesque los núcleos adicionales. La regla general es la siguiente: seleccione los cuatro núcleos másrápidos antes que núcleos adicionales.Sistema 2: (donde están instalados Dashboard Application Services Hub y Tivoli Netcool/OMNIbus)cuatro procesadores, 16 GB de memoria, dos o más discosSistema 3: servidor de bases de datos; 4 procesadores, 16 GB de memoria

• RDBMS Db2 u Oracle utilizado para la base de datos de NCIM.• Dos motores de sondeo:



IPv6.

Red de empresa de telecomunicaciones inalámbrica 4G LTEEste cliente es una empresa de telecomunicaciones inalámbrica de gran tamaño que proporcionaservicios de telefonía inalámbricos 4G a través de su infraestructura LTE (Long term Evolution). El fin deesta instalación es gestionar esta red de cliente alertando al personal del centro de operaciones de red entodo momento de fallos graves.

En las secciones siguientes se proporcionan sugerencias para que un despliegue de Network Managercumpla las necesidades de esta red.

DescripciónLa red a gestionar tiene unos 5000 eNodeBs, junto con 3000 dispositivos adicionales que se encuentranen la red Evolved Packet Core (EPC) asociada, o que funcionan como dispositivos direccionadoresbackhaul móviles. El recuento de entidades Network Manager descubierto para esta red sería como sigue:

• Para dispositivos eNodeB: del orden de 20 a 25 entidades por eNodeB.• Para los dispositivos de equipo backhaul y red EPC: del orden de 10 a 15 entidades por dispositivo.

El eNodeB LTE y el equipo asociado se proporciona por varios proveedores que pueden variar encomplejidad y escala. Estos dispositivos se distribuyen entre varias ubicaciones, como es lo corriente enuna red móvil 4G. Todos los dispositivos a gestionar se conectan mediante Fast Ethernet o GigabitEthernet. La topología y los datos de inventario de red descubiertos por Network Manager se recibendesde sistemas EMS específicos del proveedor, y se procesan por parte de los recopiladores NetworkManager correspondientes específico del proveedor.

Dentro de este entorno, se suelen aplican las condiciones siguientes:

• Número de clientes de GUI activos simultáneamente: De 5 a 20• Requisitos de sondeo: ninguno, ya que los datos de topología se reciben del EMS, por lo que no se

asume sondeo de dispositivos.

Despliegue deNetwork ManagerEs necesario un despliegue de tres partes para este tipo de entorno.

1. Componentes principales de Network Manager2. Dashboard Application Services Hub y Cognos Analytics.3. Base de datos de topología NCIM.


Estas tres partes se pueden desplegar en servidores (únicos o múltiples) o en máquinas virtuales (únicaso múltiples). Un único dominio es suficiente para este tipo de entorno. Además, son adecuados losvalores de despliegue siguientes:

• Componentes principales de Network Manager

– de 4 a 6 procesadores– unos 20 GB de memoria– 50 GB de espacio en disco

• Dashboard Application Services Hub y Cognos Analytics

– de 4 a 6 procesadores– de 6 a 8 GB de memoria– 20 GB de espacio en disco

• base de datos de topología NCIM

– 4 procesadores– 10 GB de memoria– 50 GB mínimos de espacio en disco en una configuración de RAID adecuada, para proporcionar el

nivel de tolerancia a errores, fiabilidad y rendimiento necesarios.– Db2 u otra plataforma de base de datos soportada.

Además, el sistema cliente de GUI siguiente es adecuado:

• procesador único• 3 GB de memoria• JRE y navegador Internet soportados

Consideraciones sobre el desplieguePuede desplegar toda su instalación de Network Manager en un servidor único o como una instalacióndistribuida.

Durante una instalación de Network Manager, instale varios componentes de Network Manager, incluidoslos siguientes:Componentes principales de Network Manager

Este componente consta de los procesos principales de Network Manager: descubrimiento de red,sondeo, análisis de causa raíz y enriquecimiento de sucesos.

base de datos de NCIMEsta base de datos almacena datos de la topología.

Tivoli Netcool/OMNIbusEste componente consta del software de gestión de sucesos de Tivoli Netcool/OMNIbus. Muchosclientes eligen tener un sistema de informe de problemas integrado con Tivoli Netcool/OMNIbus.

Componentes de la GUI de Network ManagerEste componente incluye la infraestructura de la GUI de Dashboard Application Services Hub, loscomponentes de GUI web, Jazz for Service Management y Java™.

Otros componentesOtros componentes incluyen Cognos Analytics y los informes de Network Manager.

El objetivo de la instalación es colocar estos componentes en uno o varios servidores.

Restricción: No está permitido usar diferentes versiones de los mismos productos o componentes juntos,a menos que se indique lo contrario en las instrucciones en IBM Knowledge Center o en el Soporte deIBM. Si necesita varias instancias de un producto o componente, debe instalarlas o actualizarlas a lamisma versión y fixpack. También es necesario comprobar que se instale el mismo conjunto decorrecciones de prueba, si las hubiera. Por ejemplo, si necesita varias instancias de los Componentes de


GUI Network Manager en una implementación, asegúrese de que sean la misma versión, fixpack ycorrecciones de prueba.

A continuación se muestran configuraciones de despliegue de Network Manager típicas:

• Despliegue de servidor único• Despliegue distribuido: dos servidores o más

Los factores que requieren un número incrementado de servidores en un despliegue distribuido incluyenlo siguiente:

• Tasas de sucesos activas• Cantidad y tasa de datos de sondeo almacenados• Tasas de sondeo del estado de los dispositivos y número de destinos de sondeo• Tiempos de respuesta de red para los destinos sondeados• Frecuencia de descubrimiento y• Tamaño de la red que se descubrirá (para cada dominio, donde hay varios dominios)

Nota: Estas configuraciones de despliegue no tienen en consideración requisitos para otras integracionesde productos.

Además, debe pensar en el despliegue de sistemas adecuados para soportar las sesiones de los clientesde la GUI.

Además, se necesita el soporte de pila dual IPv6 si las estaciones de trabajo o los dispositivos de redtienen IPv6.

Despliegue de servidor únicoLos despliegues de servidor único son adecuados para demostraciones de pequeñas dimensiones osistemas educativos, y para sistemas para soportar redes de clientes de pequeñas a medianas.

Restricción: Una limitación de un despliegue de un único servidor es que Tivoli Netcool/OMNIbus yNetwork Manager deben actualizarse al mismo tiempo. Todas las actualizaciones para los releasesprincipales deben realizarse al mismo tiempo para evitar problemas de compatibilidad. Un releaseprincipal es un release que tiene su propio conjunto de documentación, por ejemplo Tivoli Netcool/OMNIbus V8.1.0. Los fixpacks pueden aplicarse a horas diferentes.

Despliegue distribuido: dos servidores o másEn despliegues distribuidos, los componentes de Network Manager están distribuidos en variosservidores, es decir, en dos servidores o más. A continuación se ofrecen algunas pautas para losdespliegues distribuidos:

• Los despliegues de dos servidores son adecuados para la parte final superior de las redes de rango declientes medios.

• Los despliegues pueden necesitar tres servidores o más en situaciones donde haya varios dominios dered.

• Los despliegues de tres servidores pueden desplegarse igualmente donde se determine que se necesitaun servidor separado para soportar un producto de base de datos relacional que proporcione elalmacenamiento de datos de la topología. Además, un servidor de base de datos separado habilita labase de datos relacional para soportar varias aplicaciones, además de Network Manager.

Despliegue de dos servidores

Un ejemplo de un despliegue de dos servidores consta de la siguiente asignación de estaciones de trabajode host:


• Servidor 1: Componentes principales de Network Manager,Tivoli Netcool/OMNIbus, y la base de datosde NCIM. Los componentes principales son el descubrimiento de red, el sondeo, el análisis de causaraíz y los componentes de enriquecimiento de sucesos.

• Servidor 2: Dashboard Application Services Hub con aplicaciones web de Network Manager asociadas.

Despliegue de tres servidores

Un ejemplo de un despliegue de tres servidores consta de la siguiente asignación de estaciones detrabajo de host:

• Servidor 1: componentes principales de Network Manager.• Servidor 2: Tivoli Netcool/OMNIbus• Servidor 3: Dashboard Application Services Hub con aplicaciones web de Network Manager asociadas,

junto con la base de datos de NCIM.

Sistemas del clienteDebe pensar en el despliegue de sistemas adecuados para soportar sesiones de clientes de la GUI.

La siguiente especificación del sistema proporciona soporte para una amplia gama de actividades deusuario final en sesiones de clientes de la GUI:

• Una pantalla más grande soporta una visualización cómoda a una resolución más alta como 1280x1024• Velocidad actual del procesador de núcleo único o dual• 3 GB de memoria• JRE y navegador de Internet soportados• Fast Ethernet.• Especificación del procesador:

Para visualizaciones de topología normal o visualizaciones de sucesosProcesador único con las siguientes velocidades: 1 GHz o superior, como se encuentra en muchosportátiles, 2.4 GHz, como se encuentra en muchas estaciones de trabajo

Tiempo mejorado para mostrar mapas de topología de mayor tamaño o más complejos y unavisualización mejorada de gráficos MIB

Un procesador muy actual (3,0 GHz o superior) normalmente disponible en los sistemas de clase deestación de trabajo más actualizados.

Ejemplos de despliegueUtilice estos ejemplos de Network Manager para ayudarle a planificar su arquitectura de despliegue.

Ejemplo de arquitectura de despliegue simpleUtilice este ejemplo para familiarizarse con la arquitectura de un despliegue simple de Network Manager.

ComponentesEste ejemplo de despliegue simple consta de los componentes siguientes:

• Un par virtual de ObjectServer.• Un servidor de Dashboard Application Services Hub.• Una instalación de Network Manager que ejecuta un dominio con migración tras error.• Una instancia de la base de datos de topología de NCIM.

La cifra siguiente muestra la arquitectura para este despliegue.


Figura 1. Arquitectura de despliegue sencilla

Asignación de estaciones de trabajo de hostLa cifra siguiente muestra una asignación de ejemplo de estaciones de trabajo de host para estedespliegue.

Nota: Si tiene una topología de un tamaño particularmente grande, puede que desee instalar la base dedatos de topología en su propio servidor. Esta decisión depende de la especificación de sus máquinas yde cómo desee dispersar la carga entre ellas.

Figura 2. Asignación sencilla de máquina host


Pasos para instalar un despliegue simpleLos pasos siguientes proporcionan una visión general de las tareas necesarias para este despliegue yayudan a planificar un despliegue similar. .

Para instalar el despliegue descrito anteriormente, realice los pasos siguientes:

1. Instale la base de datos de topología en la máquina host 3, cree las tablas necesarias e inicie la basede datos.

Nota: La base de datos de topología debe instalarse e iniciarse antes de que inicie los componentesprincipales de Network Manager para que los datos de descubrimiento se puedan guardar.

2. Instale los siguientes ObjectServers y componentes relacionados:

a. Instale el ObjectServer principal y la Pasarela bidireccional en la máquina host 1.b. Instale el ObjectServer de copia de seguridad en la máquina host 2.

3. Configure y ejecute los ObjectServers.

Nota: Los ObjectServers deben estar en ejecución antes de que se inicien los componentes principalesde Network Manager.

4. Instale los componentes principales de Network Manager en la máquina host 2.5. Instale los componentes de principales de copia de seguridad de Network Manager en la máquina host

1.6. Instale la infraestructura de la GUI de Network Manager en la máquina de host 3. La infraestructura de

la GUI incluye el software siguiente:

• WebSphere Application Server• Dashboard Application Services Hub• Componentes de la GUI de Network Manager• GUI web de Tivoli Netcool/OMNIbus• Cognos Analytics

Consejo: Si instala el Dashboard Application Services Hub en una máquina sin ningún otro producto,es probable que el rendimiento sea mejor que si lo instala en una máquina con otros productos.

Nota: Los componentes principales de Network Manager deben instalarse antes de la infraestructurade la GUI de Network Manager.

7. Configure el Network Manager principal para la migración tras error e inícielo.8. Configure el Network Manager de copia de seguridad para la migración tras error e inícielo.

Ejemplo de arquitectura de despliegue de gran tamañoUtilice este ejemplo para familiarizarse con la arquitectura de un despliegue de Network Manager de grantamaño.

ComponentesEste despliegue de ejemplo consta de:

• Un ObjectServer y una instalación de Network Manager en Londres. El dominio de Londres envíasucesos y topología a San Francisco.

• Un ObjectServer y una instalación de Network Manager en Nueva York. El dominio de Nueva York envíaigualmente sucesos y topología a San Francisco.

• Un ObjectServer y una instalación de Dashboard Application Services Hub en San Francisco. ElObjectServer de San Francisco consolida los sucesos de Londres y Nueva York. El servidor deDashboard Application Services Hub de San Francisco puede acceder a topología tanto desde Londrescomo Nueva York, pero no consolida las topologías. Los clientes de cualquier parte del mundo pueden


conectarse al servidor de Dashboard Application Services Hub y ver topología desde Londres y NuevaYork.

La cifra siguiente muestra la arquitectura para este despliegue.

Nota: Para un despliegue de gran tamaño de este tipo, debe tenerse en cuenta la latencia de red en todala WAN. Esto es de especial importancia si se espera que el sondeador almacene una gran cantidad dedatos históricos.

Figura 3. Arquitectura de despliegue de gran tamaño

Asignación de estaciones de trabajo de hostLa cifra siguiente muestra una asignación de ejemplo de servidores para este despliegue.


Figura 4. Asignación sencilla de máquina host de gran tamaño

Pasos para instalar un despliegue de gran tamañoLos pasos siguientes proporcionan una visión general de las tareas necesarias para este despliegue yayudan a planificar un despliegue similar. .

Nota: Si está instalando componentes principales de Network Manager distribuidos y servidores deaplicaciones web en diferentes zonas horarias, debe establecer la misma zona horaria en todos losservidores, lo que incluye tanto el servidor de base de datos como los servidores principales y losservidores de la GUI. Esto garantiza que Network Manager pueda realizar comparaciones de indicación defecha y hora precisas en los procesos de los distintos servidores. También debe avisar a los usuariosfinales, tales como operadores de red, que es posible que el sistema muestre horas distintas a la hora desus ubicaciones.

Para instalar este despliegue, realice los pasos siguientes:

1. Instale la base de datos de topología en la máquina host San Francisco 3, y cree las tablas de base dedatos necesarias.

Nota: La base de datos de topología debe instalarse e iniciarse antes de que inicie los componentesprincipales de Network Manager para que los datos de descubrimiento se puedan guardar.

2. Instale los siguientes ObjectServers y componentes relacionados:

• Instale el ObjectServer en la máquina host San Francisco 2.• Instale el ObjectServer y la pasarela unidireccional en la máquina host Londres 2.• Instale el ObjectServer y la pasarela unidireccional en la máquina host Nueva York 2.

3. Configure y ejecute los ObjectServers.

Nota: Los ObjectServers deben estar en ejecución antes de que se inicien los componentes principalesde Network Manager.

4. Instale los componentes principales de Network Manager en la máquina host Londres 1.


Nota: Los componentes principales de Network Manager deben instalarse antes de las aplicacionesweb.

5. Instale los componentes principales de Network Manager en la máquina host Nueva York 1.6. Instale la infraestructura de la GUI de Network Manager en la máquina de host 3. La infraestructura de

la GUI incluye el software siguiente:

• WebSphere Application Server• Dashboard Application Services Hub• Componentes de la GUI de Network Manager• GUI web de Tivoli Netcool/OMNIbus• Cognos Analytics

Consejo: Si instala el Dashboard Application Services Hub en una máquina sin ningún otro producto,es probable que el rendimiento sea mejor que si lo instala en una máquina con otros productos.

Nota: Los componentes principales de Network Manager deben instalarse antes de la infraestructurade la GUI de Network Manager.

Comprobación de los requisitos del sistemaDebe comprobar los requisitos previos de sistema antes de instalar Network Manager o productosrelacionados.

Acerca de esta tareaPuede lleva a cabo una comprobación preliminar del entorno de hardware y software en los servidoresdonde desea instalar Network Manager o productos relacionados sin descargar dichos productos. Puedeutilizar IBM Prerequisite Scanner, un componente independiente de software, para realizar estacomprobación. Esta comprobación inicial le indica si necesita actualizar el hardware o configurar elsistema operativo antes de instalar los productos.

Además de las comprobaciones realizadas por IBM Prerequisite Scanner, el instalador de NetworkManager realizará sus propias comprobaciones cuando se intente instalar los productos. IBM PrerequisiteScanner Puede comprobar los requisitos previos de varios productos. El instalador de Network Managercomprueba únicamente los requisitos previos de los productos seleccionados para su instalación.

Importante: Las comprobaciones automáticas no son un sustituto para comprender el hardware, elsoftware y otros requisitos previos descritos en la documentación. Algunos requisitos previos dependende su red o del despliegue y no se pueden automatizar.

Para comprobar los requisitos previos del sistema para los componentes de GUI y los componentesprincipales de Network Manager 4.2, debe descargar el explorador y el archivo de configuraciónactualizado. Consulte las instrucciones en la ubicación siguiente: https://www.ibm.com/support/pages/node/727673

Para obtener instrucciones sobre el uso de IBM Prerequisite Scanner con otros productos, consulte ladocumentación de instalación de los otros productos.

ResultadosAparecen en pantalla los resultados de la comprobación de los requisitos previos del sistema que indicansi el servidor actual es adecuado para la instalación de su elección de componentes.

Dominios de redAntes de la instalación, tiene que tener en cuenta si partirá su red en dominios, o si tendrá un únicodominio para toda la red. Un dominio de red es una colección de entidades de red preparadas para serdescubiertas y gestionadas.


https://www.ibm.com/support/pages/node/727673


Restricción: Utilice únicamente caracteres alfanuméricos y subrayados (_) para los nombres de dominio.Todos los demás caracteres, como el guión (-), están prohibidos.

Motivos para particionar su red en varios dominiosParticionar su red en dominios permite al usuario descubrir su red en secciones. Los motivos paraparticionar su red incluyen:

• Escalabilidad: Su red puede ser demasiado grande para ser descubierta de una vez.• Geografía: Puede que desee descomponer la red en regiones geográficas, y hacer que cada región se

corresponda con un dominio.• Límites de red lógica: Puede que desee descubrir y gestionar la red según los límites de red concretos.

Los dominios descubiertos se pueden supervisar de forma separada.

Puede ejecutar varios dominios para realizar varios descubrimientos de red, y se pueden ejecutar variosprocesos de Network Manager de forma independiente de cada uno en el mismo servidor si pertenecen adominios distintos.

Identificación del dominio de un sucesoLa identificación del dominio de un suceso permite a las vistas de red y a la vista de salto generar lacorrelación de topología correcta para ese suceso.

El dominio en el que se origina un suceso se puede identificar de las formas siguientes:

• Utilizando un dominio por ObjectServer y utilizar el nombre del ObjectServer para identificar el dominiodesde el que se origina el suceso.

• Si utiliza varios dominios por ObjectServer, los analizadores en cada dominio deben configurarse parapermitir que el suceso contenga información que identifique al dominio. Este enfoque permite quevarios dominios de Network Manager se conecten a un único ObjectServer.

Conceptos relacionadosPautas para un número de dominios de redSi su red supera un tamaño determinado, puede que sea necesario descomponer la red en variosdominios. Utilice esta información para detectar el número de dominios de red necesarios para sudespliegue.Tareas relacionadasCreación y configuración de dominios de red adicionalesPara añadir más dominios de red, configure el control de procesos para los dominios y registre losdominios con la base de datos de topología de NCIM. Es posible copiar configuraciones y sondeos dedominios existentes. Configure o reconfigure las vistas de red para que muestren los dispositivos en losnuevos dominios.

Recopilación de sucesos utilizando varios dominios por ObjectServerPuede conectar varios dominios de Network Manager a un único ObjectServer.

En esta configuración, las sondas de Tivoli Netcool/OMNIbus recopilan información sobre el nombre deldominio cuando se genera un suceso y rellena el campo NmosDomainName para guardar este nombre dedominio.

Para implementar esta configuración, primero debe modificar todos los archivos de reglas del analizadorTivoli Netcool/OMNIbus para garantizar que cada suceso contiene un campo NmosDomainName . Estecampo se utiliza para almacenar el nombre del dominio asociado con el suceso. Esto también aseguraque el suceso se procese mediante la Pasarela de sucesos.

Nota: El filtro de suceso de entrada de la Pasarela de sucesos maneja los sistemas tanto de dominioúnico como de varios dominios de forma predeterminada. Para obtener más información consulte IBMTivoli Network Manager IP Edition Administration Guide.


Nota: Este es un enfoque menos caro, ya que sólo requiere un único ObjectServer. La escalabilidad debeser un problema cuando cada nuevo dominio requiera configuración de la sonda extra.

La cifra siguiente muestra una arquitectura de ejemplo que utiliza varios dominios por ObjectServer.

Figura 5. Gestión de pertenencia de sucesos: arquitectura para ObjectServer de varios dominios

Visualización de ejemplo de la topología desde varios dominiosLos clientes web que utilizan un única Dashboard Application Services Hub pueden ver la topología desdemás de un dominio de Network Manager.

Varios dominios almacenados en una base de datos de topologíaPara habilitar la visualización de topología desde varios dominios, cada dominio de Network Managerreenvía información de topología a la base de datos de topología NCIM (Network Connectivity andInventory Model - Modelo de inventario y conectividad de red). Cuando tenga varios dominios, latopología de cada dominio se guardará en NCIM.

Vinculación de dominios descubiertosPuede encontrar enlaces entre dispositivos en distintos dominios configurando y ejecutando undescubrimiento de dominios cruzados.

La siguiente cifra muestra un ejemplo de los datos de alimentación de tres dominios de descubrimientoen una sola base de datos de topología de NCIM. Todos los clientes web conectados a DashboardApplication Services Hub podrán ver mapas de topología en cualquiera de los dominios seleccionando unúnico dominio del menú de dominios.


Figura 6. Visualización de topología de varios dominios

Si se han ejecutado descubrimientos de dominios cruzados, se creará un dominio agregado en la base dedatos de topología que incluye recopilaciones de dispositivos de todos los dominios descubiertos. Todoslos clientes web conectados a Dashboard Application Services Hub podrán ver mapas de topología entodos los dominios seleccionando el dominio AGGREGATION en el menú de dominios.

Para obtener más información sobre la visualización de la topología, consulte la publicación NetworkManager Topology Visualization Guide.

Requisitos de hardwareLos requisitos de hardware varían según el tamaño y la composición de su red y las características deNetwork Manager que desee utilizar.

Asegúrese de que sus servidores cumplen con los requisitos de hardware antes de instalar NetworkManager.

Importante: No ejecute ninguna otra aplicación de utilización intensiva de recursos durante la instalaciónde Network Manager.

Pautas de selección del procesadorLea acerca de las pautas para los requisitos del procesador antes de seleccionar el servidor correcto en elque instalar Network Manager.

Las pautas tratadas aquí son para servidores que se espera que soporten únicamente componentes deNetwork Manager. Las pautas suponen el despliegue de otros productos de Tivoli, como por ejemplo IBMTivoli Monitoring e IBM Tivoli Business Service Manager en otros servidores. Para combinar el desplieguede varios productos importantes en un único servidor, agregue los requisitos mínimos para cada productojuntos (consulte la documentación del producto individual para obtener más información).


Para la demostración y redes de clientes de pequeñas dimensiones o despliegues del sistema educativo,utilice al menos dos procesadores en todas las plataformas. Los despliegues de redes de clientesmedianos o de grandes dimensiones requieren cuatro procesadores o más.

Nota: Para varios procesadores principales, la velocidad del núcleo individual puede ser más importanteque el número de núcleos. Aunque se pueden utilizar procesadores de cualquier velocidad, la selecciónde la mayor velocidad de núcleo y de la mayor memoria caché en chip supone una diferencia significativaen función del tamaño de la red que se descubra y que se sondee.

Para valores virtualizados (soportados por AIX LPARS, VMWare ESX, etc.), utilice tanto recursos dememoria como de procesador fijados a un sistema virtual que de soporte a Network Manager.

Para los valores de Linux on IBM z Systems, utilice la asignación de CPU equivalente a aquella de dosprocesadores modernos, desde cualquiera de las plataformas nativas de UNIX o Windows soportadas porNetwork Manager.

Para obtener más detalles sobre la selección de procesadores y otras consideraciones de despliegue,consulte “Despliegue de Network Manager” en la página 3.

Requisitos para ejecutar el instaladorPara instalar los componentes de Network Manager, su servidor debe cumplir los requisitos de hardwarepara IBM Installation Manager.

Para obtener más información sobre puertos específicos, consulte la documentación de la versión de IBMInstallation Manager en: https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html.

Requisitos de espacio de disco para instalar como usuario rootNecesita una cierta cantidad de espacio libre en ciertos directorios para poder ejecutar el instalador, sintener en cuenta qué componentes se estén instalando. Si está instalando Network Manager como usuarioroot, se deben cumplir los siguientes requisitos:

• Al menos 1 GB de espacio en el directorio /tmp en el servidor de componentes de la GUI.• Al menos 1 GB de espacio en el directorio /var.• Si instala Network Manager en una ubicación distinta de /opt, debe tener al menos 50 MB de espacio

en el directorio /opt.• Al menos 10 GB de espacio en la ubicación de datos para IBM Installation Manager. Elija la ubicación de

datos durante la instalación de IBM Installation Manager. Esta ubicación es el lugar donde los paquetesse desempaquetan durante la instalación y donde los paquetes se almacenan para retrotraerse.

Requisitos de espacio de disco para instalar como un usuario no rootSi está instalando Network Manager como usuario root, se deben cumplir los siguientes requisitos:

• Al menos 1 GB de espacio en el directorio /tmp en el servidor de componentes de la GUI.• Al menos 350 MB de espacio libre en su directorio inicial.• Al menos 10 GB de espacio en la ubicación de datos para IBM Installation Manager. Elija la ubicación de

datos durante la instalación de IBM Installation Manager. Esta ubicación es el lugar donde los paquetesse desempaquetan durante la instalación y donde los paquetes se almacenan para retrotraerse.

Requisitos para los componentes principalesPara instalar y ejecutar los componentes principales de Network Manager, sus servidores deben cumplirlos requisitos mínimos de hardware.




Requisitos de memoriaAsegúrese de que el servidor donde desea ejecutar Network Manager cumple los siguientes requisitos dememoria.

• Para un despliegue de servidor único, en el que los componentes principales de Network Manager,aplicaciones web, base de datos de topología y Tivoli Netcool/OMNIbus están todos en el mismoservidor, necesita un mínimo de 16 GB DRAM.

• Para un despliegue distribuido, donde únicamente los componentes principales de Network Managerestén instalados en el servidor, necesita un mínimo de 8 GB DRAM.

Estos son los requisitos mínimos y la cantidad de memoria necesaria variará dependiendo del tamaño dela red que se va a gestionar y de cómo se despliegue Network Manager. Para obtener más información,consulte “Despliegue de Network Manager” en la página 3.

Requisitos de espacio de discoAsegúrese de que el servidor donde desea instalar Network Manager cumple los siguientes requisitos deespacio de disco.

• 5 GB de espacio en disco duro para almacenar el software• 4 GB de espacio de disco duro pro dominio para el almacenamiento de memoria caché• Como cálculo orientativo para los archivos de registro, suponiendo que cada archivo de registro tenga 1

GB de tamaño y se establezcan seis procesos en el nivel de depuración completo, necesitará 24 GB deespacio de disco. (6 procesos x 4 archivos de registro o rastreo cada uno = 24 archivos de registro orastreo x 1 GB = 24 GB).

• 50 GB de espacio libre de disco para ejecutar Network Manager.

Estos son los valores mínimos de referencia y la cantidad de espacio de disco necesario variarádependiendo del tamaño de la red que se va a gestionar y de cómo se despliegue Network Manager. Paraobtener más información, consulte “Despliegue de Network Manager” en la página 3.

Nota:

Para un sistema de producción que pretende utilizar a plazo largo, debe tener suficiente espacio de discoadicional para almacenar archivos generados por operación de producto, como archivos de retrotracción.Si instala los componentes principales de Network Manager y Tivoli Netcool/OMNIbus, necesita al menos400 GB de espacio en la partición donde están instalados los productos.

Requisitos de ancho de bandaEl servidor de Network Manager requiere una conexión de Ethernet de alta velocidad dúplex completa de100 Mbps (o equivalente) con el servidor DNS.

Es obligatorio que los sistemas que admiten componentes de Network Manager estén colocados en elcentro de datos con conexiones de velocidad LAN de Gigabit Ethernet o de Ethernet de alta velocidad de100 Mbps en el sistema DNS y los dispositivos de red principales a ser descubiertos y gestionados. Lasvelocidades de conexión más lentas se pueden utilizar, pero pueden producir un impacto en los tiemposde respuesta de la sesión del cliente y deben ser factorizados en cargas de trabajo claves como el sondeo(incluidos los tiempos de respuesta, el total de reintentos y el total de tráfico de red introducido).

Nota: Durante el descubrimiento de un dispositivo de red, se realizan muchas consultas de SNMP dedicho dispositivo. Tras el descubrimiento, el sondeo rutinario (ICMP y SNMP) puede introducir tráficosignificativo a la red. Con la red de soporte alojada por velocidades de LAN modernas, estas cargas detrabajo se pueden mostrar.

Para obtener más detalles sobre los requisitos de descubrimiento del ancho de banda, consulte“Requisitos de ancho de banda para el descubrimiento” en la página 37.


Otros requisitosTambién necesita una unidad DVD, si no está instalando el software desde una descarga.

Requisitos para los componentes de la GUIEl servidor en el que instale los componentes de GUI de Network Manager deben cumplir los siguientesrequisitos de hardware.

Orientación sobre el espacio de disco a largo plazo para todos los componentes deGUI y productos relacionadosPara un sistema de producción que pretende utilizar durante algún tiempo, debe tener suficiente espaciode disco adicional para almacenar archivos generados por la operación del producto, como archivos deretrotracción. Si instala los componentes de GUI de Network Manager, Dashboard Application ServicesHub, Cognos Analytics y GUI web de Tivoli Netcool/OMNIbus, necesita al menos 100 GB de espacio en lapartición donde se instalan los productos.

Requisitos de hardware para instalar componentes de GUI de Network ManagerPara instalar los componentes de GUI de Network Manager, el servidor debe cumplir los siguientesrequisitos:

• Espacio de disco duro de 5.5 GB.• Un mínimo de 4 GB de DRAM.

Nota: El instalador comprueba para asegurar que esté disponible un mínimo de 3 GB de DRAM para quese muestren los despliegues de demostración y de sistema educativo. Sin embargo, se necesita unmínimo de 4 GB DRAM en los entornos de producción.

• 500 MB en el directorio /tmp.• La unidad de DVD no está instalando desde la descarga.

Requisitos de hardware para instalar Cognos AnalyticsPara habilitar los informes de gestión de red, debe tener instalado Cognos Analytics. Cognos Analytics esun componente opcional que debe instalarse por separado para poder utilizar la característica decreación de informes de Network Manager.

Revise los requisitos de hardware para Cognos Analytics para asegurarse de que cumple sus requisitos derendimiento.

Importante: Asegúrese de que tiene al menos 17 GB de espacio libre en la ubicación donde deseainstalar Cognos Analytics.

Para obtener información detallada, consulte la información acerca de los requisitos de hardware para suversión de Cognos Analytics en el Centro de conocimiento de Cognos Analytics en: https://www.ibm.com/support/knowledgecenter/SSEP7J.

Requisitos para el servidor de base de datos de topologíaLea acerca de los requisitos de base de datos de topología de Network Manager.

Requisitos de espacio de discoPara almacenar datos de Network Manager, asegúrese de que tiene al menos el siguiente espacio dedisco mínimo disponible para su base de datos de topología:

• 3 a 5 GB para Db2.• 3 a 5 GB para Oracle.


https://www.ibm.com/support/knowledgecenter/SSEP7J


Nota: Estas cifras son valores mínimos. El espacio de disco real requerido depende del tamaño de su redy de la cantidad de datos almacenados. El almacenamiento de datos de rendimiento puede requerir unagran cantidad de espacio de disco. Si está planificando almacenar tales grandes cantidades de datos,piense en 50 GB para el espacio de disco relacionado con Network Manager.

Para una red grande contenida en un dominio individual, debe tener 5 GB para los datos de topología y untotal de 50 GB para cubrir también el almacenamiento de datos. Para obtener más información sobre laplanificación del despliegue deNetwork Manager en la red y las consideraciones de tamaño y dominios,consulte “Despliegue de Network Manager” en la página 3.

Asegúrese de que el servidor donde desea ejecutar la base de datos de topología cumple los siguientesrequisitos de disco:

• Tres discos en la configuración RAID 1 (más discos para RAID 5)• SATA de alta velocidad o discos SCSI

Espacio de disco para sucesos e interfacesDebe calcular y permitir espacio de disco adicional para el número de sucesos e interfaces de suinstalación.

Los requisitos de hardware adicionales para Network Manager son los siguientes:

• 4 KB de espacio de disco para cada suceso esperado, por día de almacenamiento requerido• 4 KB de espacio de disco para cada interfaz o puerto en un dispositivo gestionado

Por ejemplo, si tiene 5000 puertos en dispositivos de su red, espera 3000 sucesos cada día y requiereque los sucesos se almacenen durante 30 días, requerirá:

3000 * 30 * 4 KB = 360 MB

El espacio de disco total requerido es, por lo tanto:

512 MB + 512 MB memoria caché + 360 MB + (4 KB * 5000) = 1,4 GB

Requisitos del espacio de intercambio (UNIX)En las plataformas de UNIX, debe asegurarse de que tiene un espacio de disco libre adecuado que seconfigure para utilizarse como espacio de intercambio.

La cantidad exacta de espacio de intercambio necesaria depende del tamaño y la composición de su red ydel tipo de descubrimiento. Para cantidades más reducidas de RAM física, necesita cantidadesproporcionalmente mayores de espacio de intercambio. Las cifras siguientes muestran la cantidadaproximada de espacio de intercambio en función de la cantidad de RAM física.

4 GB de RAMConfigure 10 GB de espacio de intercambio.



Para cantidades de RAM mayores de 12 GB, configure la misma cantidad de espacio de intercambio. Porejemplo, para 24 GB de RAM, configure 24 GB de espacio de intercambio.

Requisitos de la memoria de descubrimientoAl descubrir redes muy grandes, el proceso de descubrimiento (ncp_disco) y el proceso del modelo detopología (ncp_model) utilizan la máxima memoria. Si la red es muy grande, piense en dividirla en variosdominios.

Conceptos relacionadosPautas para un número de dominios de red


Si su red supera un tamaño determinado, puede que sea necesario descomponer la red en variosdominios. Utilice esta información para detectar el número de dominios de red necesarios para sudespliegue.

Requisitos de softwareLos requisitos de software varían según el sistema operativo, los productos y las características deNetwork Manager que desee utilizar.

Requisitos de compatibilidad para otros productosAsegúrese de que cumple los requisitos para los productos que están integrados con Network Manager.

Productos que requiere Network ManagerNetwork Manager requiere los siguientes productos y componentes. Network Manager requiere versionesespecíficas de estos productos.


JRE (Java Runtime Environment)

Network Manager no instala un JRE. Utiliza el JRE instalado por otros productos, como WebSphereApplication Server. Debe usar el JRE apropiado para la combinación de productos o componentes queestán instalados en cualquier servidor.

Network Manager , requiere Java 8 o posterior, para la versión 4.2 Fix Packs 8 y 9. Cambia el Javapredeterminado utilizado por WebSphere Application Server a Java 8. Para Network Manager, laversión 4.2 Fix Pack 10 o posterior, el Java Development Kit necesario está disponible en el paqueteque se va a utilizar WebSphere Application Server.

Si no tiene la versión correcta de Java, es posible que vea un mensaje de error similar al siguiente:

ERROR IBM WebSphere SDK Java Technology Edition is not installed or selected to be installed.

Antes de instalar Network Manager Fix Pack 8 o 9, asegúrese de que Java 8 esté instalado enWebSphere. Enumere los Java Development Kits disponibles ejecutando el siguiente mandato:

/opt/IBM/WebSphere/AppServer/bin/managesdk.sh -listAvailable

Si la salida de mandato no incluye una línea similar a la siguiente: CWSDK1005I: SDK name:1.8_64, descargue Java 8 aquí: https://www.ibm.com/support/pages/ibm-websphere-java-sdks-websphere-application-server-v85514#SDK80, agregue el archivo zip como repositorio a IBMInstallation Manager y utilice la opción Instalar para instalar la nueva versión de JDK.

Tivoli Netcool/OMNIbus

Network Manager necesita Tivoli Netcool/OMNIbus. Da soporte a las siguientes versiones de TivoliNetcool/OMNIbus:

• V7.4• V8.1 FixPack 23 o posterior

GUI web de Tivoli Netcool/OMNIbus

Network Manager da soporte a GUI web de Tivoli Netcool/OMNIbus V8.1 Fixpack 20 oposterior.



https://www.ibm.com/support/pages/ibm-websphere-java-sdks-websphere-application-server-v85514#SDK80

https://www.ibm.com/support/pages/ibm-websphere-java-sdks-websphere-application-server-v85514#SDK80

Dashboard Application Services Hub

Network Manager requiere Dashboard Application Services Hub Versión 3.1.3.8 o posterior.

IBM Websphere Application ServerNetwork Manager requiere IBM Websphere Application Server versión 8.5.5.17 (versión 8) o 9.0.5.5(versión 9) o posterior.

Nota: Si desea utilizar la versión 9 de WebSphere Application Server, debe tener instalado la nuevaversión 9 de WebSphere Application Server, Network Manager Fix Pack 11 o la GUI web de TivoliNetcool/OMNIbus versión 8.1.0.20 o posterior. Esto se debe a que la ruta de actualización no estádisponible para WebSphere Application Server de la versión 8 a la 9.

IBM Websphere SDK

Network Manager requiere IBM Websphere SDK Java Technology Edition Versión 8.

IBM Installation Manager

Network Manager requiere IBM Installation Manager V1.9.1.3 o posterior. En SuSE Linux V11 y V12for System z, solo se admitirá la versión de 32 bits de IBM Installation Manager.

Jazz for Service Management

Network Manager requiere Jazz for Service Management V1.1.3.8 o posterior.

Versiones anteriores de Network ManagerInstale Network Manager 4.2 en un directorio diferente en Network Manager V4.1.1 o anterior.

Requisitos para productos compatibles con Network ManagerImportante: Estos requisitos se agregan a cualquier otro hardware, software, directorio de instalación,usuario u otro requisito tratado en la documentación individual del producto. Asegúrese de que estéfamiliarizado con todos los requisitos y requisitos previos antes de instalar ningún producto.

Cognos AnalyticsSi desea ejecutar informes e instalar Informes de Network Manager, también necesitará la CognosAnalytics V11.

• A partir de 4.2 Fix Pack 11, Tivoli Common Reporting no es compatible. Usted debeutilizar Cognos Analytics.

• Para el 4.2 Fix Pack 1, Tivoli Common Reporting V3.1.3.0. Jazz for Service ManagementLa V1.1.3.0 incluye Tivoli Common Reporting V3.1.3.0.

• Para la versión 4.2 GA, Tivoli Common Reporting V3.1.2 Fix Pack 1. Jazz for Service ManagementLaV1.1.2.1 incluye Tivoli Common Reporting V3.1.2.

Importante: Asegúrese de que tiene al menos 17 GB de espacio libre en la ubicación donde deseainstalar Cognos Analytics.

IBM Tivoli Netcool Configuration Manager

Network Manager da soporte a IBM Tivoli Netcool Configuration Manager 6.4.2 o posterior.

IBM Tivoli Monitoring

Network Manager es compatible con IBM Tivoli Monitoring versión 6.3 FP 2 o posterior en AIX, Linux oWindows. El propio agente (IBM Tivoli Monitoring for IBM Tivoli Network Manager IP Edition) solo seejecuta en Linux y AIX, ya que Windows no es una plataforma soportada para Network Manager 4.2.

Nota: IBM Tivoli Monitoring versión 6.3 Fixpack 2 se incluye en el paquete de Network Manager V4.2.

IBM Tivoli Business Service Manager

Network Manager da soporte a IBM Tivoli Business Service Manager 6.1.1.


IBM Tivoli Application Dependency Discovery Manager y IBM Tivoli Change and ConfigurationManagement Database

Network Manager da soporte a IBM Tivoli Application Dependency Discovery Manager y a IBM TivoliChange and Configuration Management Database 7.2.1 o posterior.

Tareas relacionadasConfiguración de integraciones con otros productosPuede configurar Network Manager para trabajar con productos de ®Tivoli. Consulte las tareas deconfiguración necesarias para configurar las integraciones disponibles.

Bases de datos de topología soportadasLa base de datos de topología predeterminada para Network Manager es IBM Db2 10.5 Enterprise ServerEdition.

Network Manager soporta las siguientes bases de datos de topología:

• IBM Db2 versión 10.1 Enterprise Server Edition• IBM Db2 versión 10.5 Workgroup Server Edition• IBM Db2 versión 10.5 Enterprise Server Edition• IBM Db2 versión 11.1 Enterprise Server Edition• IBM Db2 versión 11.5 Enterprise Server Edition

• IBM Db2 versión 11.1 Advance Enterprise Server Edition• Oracle Database versión 11g, Enterprise Edition con opción de partición (soporte añadido en Network

Manager 4.2 Arreglo temporal 2)• Oracle Database versión 12c, Enterprise Edition con opción de partición• Oracle Database versión 19c, Enterprise Edition con opción de partición

Importante: Todos los sistemas de base de datos anteriores incluyen la prestación de particionamientode tabla. Los sistemas de base de datos Oracle requieren que se incluya la opción de particionamiento. Elparticionamiento de tabla es necesario para que Network Manager funcione correctamente.

Cuando se configura una migración tras error, puede configurar Network Manager para que opere en laRecuperación tras desastre de alta disponibilidad (HADR) de Db2, o en el entorno Oracle Real ApplicationClusters (RAC), dependiendo de la base de datos. Para obtener más información, consulte “Configuraciónde migración tras error” en la página 182.

Para obtener una matriz de las bases de datos y los sistemas operativos soportados, consulte eldocumento de requisitos del sistema detallado en:

https://www.ibm.com/software/reports/compatibility/clarity/

Importante: Asegúrese de que la base de datos tenga todos los parches recomendados aplicados,incluidos los últimos niveles de parches.

Tareas relacionadasInstalación y configuración de una base de datos de topologíaEl administrador de base de datos debe instalar y configurar una base de datos de topología soportadaantes de poder instalar Network Manager.

Sistemas operativos soportadosNetwork Manager se soporta en los siguientes sistemas operativos.

Para obtener la información más actualizada acerca de los sistemas operativos soportados, consulte eldocumento de los requisitos del sistema detallado en:





Importante: Asegúrese de que su sistema operativo tenga todos los parches recomendados instalados,incluidos los últimos niveles de parches.

En sistemas basados en IBM PowerPC, se admiten las versiones siguientes:

• AIX 6.1 iSeries y pSeries• AIX 7.1 iSeries y pSeries• AIX 7.2 iSeries y pSeries

En los procesadores Intel y Advanced Micro Devices (AMD) x86, están soportadas lassiguientes versiones:

• Red Hat Enterprise Linux Server 6 (x86-64)• Red Hat Enterprise Linux Server 7 (x86-64)

• Red Hat Enterprise Linux Server 8 (x86-64)• SuSE Linux Enterprise Server (SLES) 11.0 (x86-64) SP2 y SP3

• SuSE Linux Enterprise Server (SLES) 12.0 (x86-64)

• SuSE Linux Enterprise Server (SLES) 12.0 (x86-64) SP4


Desde el Fix Pack 3 al Fix Pack 5, se admiten las siguientes versiones en Linux en IBM zSystems:

• Red Hat Enterprise Linux Server 7.3 en IBM z Systems (s390x, 64 bits)• SuSE Linux Enterprise Server (SLES) 12.0 SP1 en IBM z Systems (s390x, 64 bits)

Desde el Fix Pack 6 en adelante, se admiten las siguientes versiones en Linux en IBM zSystems:

• Red Hat Enterprise Linux Server 7.3 en IBM z Systems (s390x, 64 bits)• SuSE Linux Enterprise Server (SLES) 12.0 SP2 y SP3 en IBM z Systems (s390x, 64 bits)



Están soportados el siguiente hipervisor y combinaciones de sistemas operativos:

• VMware ESX 5.0, 5.5, 6.0:

– Red Hat Enterprise Linux Server 7 (x86-64)– SuSE Linux Enterprise Server (SLES) 11.0 (x86-64) SP2 y SP3

– SuSE Linux Enterprise Server (SLES) 12.0 (x86-64)

Requisitos adicionales de AIX

Asegúrese de tener los programas de utilidad unzip o GNU tar instalados para poder descomprimir elarchivo de instalación. Para instalar estos programas de utilidad, vaya a: http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html.

Asegúrese de que GTK2 está instalado. Para instalar GTK2, consulte la siguiente nota técnica: http://www.ibm.com/support/docview.wss?uid=swg21631478.

Requisitos de biblioteca para sistemas Linux


http://www.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html

http://www.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html



Los componentes de Network Manager necesitan las bibliotecas siguientes y las dependencias de dichospaquetes. Asegúrese de que tiene estas bibliotecas en el sistema en el que quiere instalar NetworkManager, o instale los paquetes correspondientes para obtener dichas bibliotecas.

Además de las bibliotecas siguientes, asegúrese de que tiene todas las bibliotecas necesarias para lasversiones adecuadas de cualquier producto integrado. Específicamente, compruebe los requisitos para suversión de Jazz for Service Management en la Jazz for Service Management documentación en: https://www.ibm.com/support/knowledgecenter/SSEKCU, y para Cognos Analytics en el Centro de conocimientode Cognos Analytics en https://www.ibm.com/support/knowledgecenter/SSEP7J.

Tabla 4. Requisitos de biblioteca para sistemas Linux

Biblioteca Paquete de Red Hat Paquete de SuSENecesario porcomponente

libstdc++.so.6 (64-bit)

libstdc++-4.4.4-13+libstdc++-4.8.2+

libstdc++46-4.6.1+Network Manager Core

libpam.so.0 (64-bit) pam-1.1.1 pam-64bitTivoli Netcool/OMNIbus

Navegadores soportados para las aplicaciones webAsegúrese de que los clientes utilicen uno de los navegadores web soportados. Si su navegador web noestá soportado, una aplicación web podría colgarse o bloquearse.

La resolución mínima de pantalla para usar las aplicaciones web es 1536 x 864.

Los siguientes exploradores de internet son compatibles:

• Google Chrome• Internet Explorer 10, 11• Mozilla Firefox 38 Extended Support Release (ESR)

• Mozilla Firefox 45 Extended Support Release (ESR)

• Mozilla Firefox 52 Extended Support Release (ESR)

Herramientas del sistema operativoAsegúrese de tener disponibles las versiones correctas de las herramientas de sistema operativonecesarias.

Dado que la estabilidad del proceso de instalación depende de la estabilidad de las herramientas delSistema operativo (SO), asegúrese de que las versiones de SO de las herramientas estándar estánincluidas en su vía de acceso antes que versiones que no sean del SO de las mismas herramientas (porejemplo, programas de utilidad de GNU).

En Linux, Network Manager necesita que se instale la versión 2.6.6 o posterior de Python 2 (no Python 3)en el servidor donde están instalados los componentes principales. En AIX, Network Manager necesita laversión 2.7.5 o superior de Python 2 (no Python 3).

Asegúrese de que el shell Bash se haya instalado en el servidor en el que se van a instalar loscomponentes principales de Network Manager.

Requisitos de usuario de UNIXEn los sistemas operativos UNIX, asegúrese de cumplir todos los requisitos relacionados los usuarios desistema operativo necesarios y las instalaciones root y no root.


https://www.ibm.com/support/knowledgecenter/SSEKCU



Usuario de agregación de sondeadorSi está instalando Network Manager como usuario root, debe crear un usuario no root antes de instalarNetwork Manager para ejecutar el motor de agregación de sondeador. Este usuario de sistema operativodebe tener permisos de escritura en el directorio de instalación. Si instala Network Manager como usuariono root, se utilizará el usuario de instalación para ejecutar el motor de agregación de sondeador.

Restricciones de usuario root y no rootSi instala las aplicaciones web de Network Manager como el usuario root, Network Manager no seintegrará con IBM Tivoli Business Service Manager.

Si desea utilizar Network Manager con TBSM, debe crear un usuario distinto para instalar y gestionartodos los productos de Tivoli en este servidor.

Si instala Network Manager como un usuario no root, debe realizar pasos de configuración extraposteriores a la instalación para ejecutar los componentes principales como el usuario root.

Nota: Siempre debe utilizar el mismo usuario para instalar, iniciar o detener todos los productosinstalados mediante IBM Installation Manager. No puede utilizar un usuario diferente, incluso si losproductos se han instalado en modalidad de grupo. Este usuario debe ser un usuario administrativo paratodos los productos instalados en dicho servidor.

Si instala y ejecuta Network Manager como un usuario no root, no es posible tener dos versiones deNetwork Manager instaladas en el mismo servidor.

Tareas relacionadasConfiguración de permisos root/no rootEn UNIX, si ha instalado Network Manager como usuario no root, debe realizar una configuraciónadicional.

Requisitos del directorio de instalaciónEl directorio donde instale Network Manager debe cumplir ciertos requisitos.

Requisitos en todos los sistemas operativosLa vía de acceso completa al directorio de instalación debe contener únicamente caracteresalfanuméricos (A-Z, a-z, 0-9), guiones, guiones bajos, puntos, dos puntos, barras o espacios.

Requisitos en los sistemas operativos UNIXEl usuario que instala Network Manager debe tener permiso de escritura en el directorio de instalación ylos directorios /opt, /var y /tmp.

Referencia relacionadaEstructura de directorios predeterminadaUtilice esta información para entender la estructura de directorios de Network Manager.

Requisitos del descriptor de archivosEn los sistemas operativos UNIX y Linux, asegúrese de que hay suficientes descriptores de archivospermitidos.

Si está instalando Network Manager en un sistema operativo UNIX o Linux, asegúrese de que el númerode archivos abiertos para procesos se establece en un valor correcto en todos los entornos para elusuario que ejecuta Network Manager. Establezca el número de archivos abiertos en 512 como mínimoen el servidor donde se hayan instalado los componentes principales y 8192 para el servidor de la GUI.Puede comprobar este valor emitiendo el mandato siguiente como usuario que está ejecutando NetworkManager: ulimit -n


Asegúrese también de que tiene el número de procesos por usuario establecido en un mínimo de 16384.Puede comprobar este valor utilizando el mandato siguiente: ulimit -u. El valor de 16384 es un valormínimo y es posible que tenga que ajustarse para el entorno basado en las necesidades.

Si el valor es demasiado bajo, póngase en contacto con su administrador de sistemas para aumentar elvalor para su usuario.

Nota:

Si está utilizando la rotación de archivos de registro con un tamaño de agrupación establecido, tenga encuenta que el número de archivos abiertos puede aumentar significativamente. Al habilitar unaagrupación de registro se añade un número adicional de archivos abiertos equivalente al número deprocesos de Network Manager en ejecución multiplicados por el número de archivos de registro de laagrupación. Asegúrese de que el límite en los archivos abiertos es suficientemente alto para que losprocesos no tengan problemas al abrir los archivos de registro.

Cambio de los valores en Linux

Para cambiar el valor de ulimit, modifique el archivo /etc/security/limits.conf. Comoadministrador del sistema (usuario root), puede añadir las líneas siguientes al final del archivo /etc/security/limits.conf:

* soft nproc 16384* hard nproc 16384* soft nofile 8192* hard nofile 8192

Cambio de los valores en AIX

Los valores actuales aparecen en el archivo /etc/security/limits, en las líneas que contienen losparámetros nofiles y nproc. Como administrador del sistema (usuario root), puede utilizar el mandatoulimit para cambiar estos valores. Para obtener más información, busque los detalles del mandatoulimit en https://www-01.ibm.com/support/knowledgecenter/ssw_aix/welcome.

Requisitos de contraseñaCualquier contraseña que elija para su uso en Network Manager debe ajustarse a las políticas decontraseñas del servidor o del entorno del sistema.

Requisitos de redAsegúrese de que la red cumple los requisitos antes de instalar Network Manager.

El soporte de pila dual IPv6 es requerido si las estaciones de trabajo o los dispositivos de red tienen IPv6.

Lista de puertos utilizados por el productoNetwork Manager utiliza diferentes puertos de comunicación: algunos fijos, algunos definidos porarchivos de configuración y otros asignados por el sistema operativo.

La siguiente tabla describe los puertos predeterminados que utiliza Network Manager.

Tabla 5. Puertos predeterminados utilizados por Network Manager

Puerto Protocolo Descripción

22 SSH através deTCP/IP

Si se habilita el soporte de SSH, el ayudante de telnet utiliza este puertopara comunicarse con dispositivos de red.


https://www-01.ibm.com/support/knowledgecenter/ssw_aix/welcome

Tabla 5. Puertos predeterminados utilizados por Network Manager (continuación)


23 Telnet através deTCP / IP

Si no se habilita el soporte de SSH, el ayudante de telnet utiliza este puertopara comunicarse con dispositivos de red.

161 SNMP El puerto 161 es el puerto predeterminado de los dispositivos de red a losque se envían consultas SNMP durante los procesos de descubrimiento ysupervisión.

Se encuentra definido en la columna m_SnmpPort de la tabla de base dedatos snmpStack.verSecurityTable.

162 UDP Puerto de condición de excepción predeterminado. Utilizado por el agentede sondeo de condiciones de excepción. Si varios procesos o aplicacionesnecesitan acceder a este puerto, el multiplexor de condiciones de excepciónSNMP, ncp_trapmux, se puede utilizar para reenviar condiciones deexcepción. El multiplexor de condiciones de excepción SNMP, el agente dedescubrimiento de condiciones de excepción y el agente de sondeo decondiciones de excepción se pueden configurar para utilizar un puertodistinto cada uno de ellos.

1883 Transportedetelemetrías de colasdemensajes(MQTT)

Puerto predeterminado que utiliza Really Small Message Broker con lascomunicaciones entre procesos.

4100 TCP/IP Puerto predeterminado de ObjectServer. Debe especificarse en el momentode la instalación. Se define en interfaces.Arch en la estación de trabajode ObjectServer. Este puerto lo utiliza el proceso ncp_g_event paracomunicarse con ObjectServer.

7968 TCP/IP Puerto predeterminado de acceso al servidor de Network Manager desdeDashboard Application Services Hub. Lo utiliza la GUI de configuración dedescubrimiento y se define en el archivo de configuraciónServiceData.cfg. Si desea cambiar este puerto, edite el archivo deconfiguración ServiceData.cfg y reinicie los procesos ncp_model yncp_config mediante CTRL.

16310 HTTP Puerto predeterminado de Dashboard Application Services Hub. DashboardApplication Services Hub Asigna los siguientes trece puertos a partir elpuerto especificado para Dashboard Application Services Hub durante lainstalación para su propio uso. De forma predeterminada, este puertoredirige a 16316.

16311 HTTPS Puerto seguro predeterminado de Dashboard Application Services Hub.

33000 TCP/IP De forma predeterminada, la dirección IP multidifusión 225.13.13.13 y elpuerto 33000 se utilizan para habilitar los ayudantes de descubrimiento ylos agentes de descubrimiento para ubicar el servidor ayudante.

Esta dirección de multidifusión se especifica en el archivo $NCHOME/etc/precision/ServiceData.cfg.

Cuando un proceso ha ubicado el servidor ayudante, se establece unaconexión TCP en un puerto asignado por el sistema operativo.


Tabla 5. Puertos predeterminados utilizados por Network Manager (continuación)


50000 TCP/IP Puerto de bases de datos Db2 predeterminado.

Asignado porSO

TCP/IP Los puertos TCP son asignados por el sistema operativo para lacomunicación TCP entre procesos; por ejemplo, la comunicación entre losagentes de descubrimiento y el servidor de ayuda. Si esto es un problema,debe asegurarse de que su cortafuegos sea externo al servidor NetworkManager y que todos los procesos de descubrimiento se ejecuten en elmismo host.

1521 TCP/IP Puerto predeterminado de bases de datos Oracle

Requisitos de DNS (Servicio de nombre de dominio)Asegúrese de que sus servidores tengan DNS configurado correctamente antes de instalar NetworkManager.

Nombres de dominioAsegúrese de que todos los servidores en los que desee instalar componentes de Network Managertengan el nombre de host definido como un nombre de dominio completo (FQDN). La configuración deDNS incompleta o incorrecta puede ocasionar problemas al instalar o utilizar Network Manager.

En plataformas UNIX, el nombre de host se define en el archivo /etc/hosts.

En la máquina en la que instale los componentes de Network Manager, asegúrese de incluir la direcciónIP, FQDN y un nombre abreviado en el archivo /etc/hosts antes de instalar Network Manager, yasegúrese de que el FQDN y el nombre abreviado sólo se resuelvan en la misma dirección IP y laresolución inversa en el FQDN o el nombre abreviado.

El formato es dirección IP FQDN nombre abreviado. Por ejemplo, en /etc/hosts, añada unalínea parecida a la siguiente:9.10.11.12 suServidor.nombreDominio.com suServidor

Así se asegura que el FQDN se establece como entrada Hostname cuando se instale Network Manager.

Restricción: No utilice guión bajo al especificar los nombres de host. El uso de guiones bajos como partede un nombre de host hace que la instalación del Dashboard Application Services Hub falle.

Requisitos de ancho de banda para el descubrimientoLas operaciones de descubrimiento de red requieren un mínimo de velocidad de conexión de ancho debanda.

No intente los descubrimientos en velocidades de conexión de acceso telefónico. Si la velocidad deconexión no es suficiente, los paquetes se pueden perder debido a la cantidad de tráfico SNMP que segenera por las operaciones de supervisión y de descubrimiento predeterminadas. Incluso sobre unaconexión de banda ancha, el número de hebras del ayudante SNMP debe ser bajo. Esto puede ocasionarque el descubrimiento lleve mucho tiempo.

Los descubrimientos deben ejecutarse utilizando una conexión Ethernet (o de velocidad similar). Lavelocidad requerida de la conexión Ethernet depende del tamaño de su red:

• La velocidad de dúplex completo de 10 Mbps se requiere para soportar hasta hebras de ayudante de100 SNMP y un número relativamente pequeño de dispositivos. Si está utilizando Telnet con SSH paraacceder a muchos dispositivos del descubrimiento, el número de hebras del ayudante de SNMP deberíareducirse debido al ancho de banda utilizado por el Ayudante de Telnet.

• La conexión Ethernet de alta velocidad dúplex completa de 100 Mbps (o equivalente) se requiere paradescubrir una gran red. El ancho de banda no debería ser un problema en una conexión de 100 Mbps


sin tener en cuenta el número de hebras del ayudante de SNMP utilizadas, a menos que haya otrasaplicaciones que necesiten el ancho de banda y que compartan el enlace.

Las cifras anteriores suponen un tiempo de ida y vuelta medio para un paquete de SNMP de 10milisegundos, y el tamaño del paquete de SNMP medio está entorno a los 125 bytes. Esto significa quecada hebra del ayudante de SNMP podría transmitir 12.500 bytes por segundo, y recuperar 12.500 bytespor segundo, lo que da como resultado 100.000 bits por segundo. Si hay 20 hebras, entonces 20multiplicado por 100.000 es igual a 2.000.000 bits por segundo, que es 2 Mbps. Para 100 hebras, la cifraserá 10 Mbps. De forma predeterminada, el ayudante de SNMP ejecutará 120 hebras.

Estas estimaciones suponen que cada hebra del ayudante de SNMP se encuentra en completofuncionamiento al mismo tiempo, lo que generalmente no es el caso. Sin embargo, si no hay suficienteancho de banda, los paquetes UDP utilizados para transportar SNMP podrían perderse, o los paquetespodrían hacer cola en la red y llegar con retraso.

Para obtener más información sobre la configuración del ayudante de SNMP, consulte la publicación IBMTivoli Network Manager IP Edition Administration Guide.

Acerca de DNCIMEl motor de descubrimiento, ncp_disco, utiliza una base de datos relacional incluida, conocida comoDNCIM (Discovery NCIM).

Durante el proceso de descubrimiento, los datos se recopilan desde la red y la topología de red se creautilizando estos datos. Durante la recopilación de datos y el procesamiento en una topología de red, losdatos de topología de red se almacenan en bases de datos diferentes. Una vez que se compila el modelode red final, incluyendo la conectividad y la contención, los datos de topología de red se almacenan enDNCIM. DNCIM tiene la misma estructura que la base de datos de topología NCIM.

Para obtener más información acerca de DNCIM, consulte IBM Tivoli Network Manager IP EditionAdministration Guide.

Instalaciones de FIPS 140-2FIPS (Federal Information Processing Standard) 140–2 es un estándar criptográfico federal de losEstados Unidos. Puede instalar Network Manager con un conjunto restringido de algoritmoscriptográficos.

Network Manager no se puede decir que sea compatible con el estándar FIPS 140–2, y nada de estainformación ni del producto debería entenderse como que lo estipule. Sin embargo, Network Manager sepuede instalar de una forma que se haya diseñado teniendo en cuenta las especificaciones de FIPS 140–2.

Restricción: Si la conformidad con FIPS 140–2 es importante para el usuario, debe instalar NetworkManager con un conjunto restringido de algoritmos criptográficos deseleccionando la característicaRecopiladores adicionales y rutinas criptográficas en el instalador. Si instala estas rutinas adicionales,la instalación utilizará las rutinas criptográficas no compatibles con FIPS 140-2.

Si los requisitos cambian o realiza un error durante la instalación, puede instalar o desinstalar lacaracterística Rutinas criptográficas adicionales tras la instalación, ejecutando el instalador de nuevo yseleccionando Modificar.

Integración con otros productosSi la compatibilidad con FIPS 140–2 es importante, también debe asegurarse de que todos los productosque se integran con Network Manager, como, por ejemplo, IBM Tivoli Netcool/OMNIbus, tienen unamodalidad FIPS. También debe configurar los productos, si es necesario. También debe comprobar quesu sistema operativo utilice únicamente módulos compatibles con FIPS 140–2.


Diferencias en una instalación FIPS 140–2 de Network ManagerUna instalación con rutinas criptográficas restringidas que se ha diseñado para usarse en un entornocompatible con FIPS 140-2 difiere de una instalación normal de las siguientes formas:

• Los agentes de descubrimiento de Telnet no utilizan SSHv1 para interrogar los dispositivos. Este usopuede hacer que no se pueda conectar de forma segura a un dispositivo si el dispositivo soportaúnicamente SSHv1 o si el dispositivo soporta únicamente algoritmos SSHv2 no compatibles con FIPS140-2.

• El Ayudante de SNMP y el navegador de MIB no pueden configurarse para utilizar MD5 o el cifrado deDES. El Ayudante de SNMP y el navegador de MIB admiten algoritmos SHA y SHA1 para resumen demensaje, y 3-DES y AES 128 para el cifrado.


Capítulo 3. Preparación para la instalaciónAntes de empezar a instalar Network Manager, debe realizar tareas adicionales, en función del entorno.

Ejecución de la instalación y procedimientos de mantenimientocomo root o no root

Puede ejecutar la instalación como un usuario no root. Sin embargo, ciertas acciones de configuración deNetwork Manager deben realizarlas el usuario root. Un panel de asistente al final del asistente deinstalación recordará al usuario iniciar sesión como root y realizar estas configuraciones manualmente.

Nota: Siempre debe utilizar el mismo usuario para instalar, iniciar o detener todos los productosinstalados mediante IBM Installation Manager. No puede utilizar un usuario diferente, incluso si losproductos se han instalado en modalidad de grupo. Este usuario debe ser un usuario administrativo paratodos los productos instalados en dicho servidor.

Conceptos relacionadosInstalación root y no rootEn UNIX, Network Manager se puede instalar como usuario root o como usuario no root.Tareas relacionadasConfiguración de los componentes principales para ejecutarlos como rootEn UNIX, si ha instalado Network Manager como usuario no root, debe realizar una configuraciónadicional para ejecutar los componentes principales como el usuario root.

Configuración de Red Hat Linux Enterprise EditionAntes de instalar en Red Hat Linux, debe inhabilitar SELinux.

Acerca de esta tareaCuando Red Hat Enterprise Linux está instalado, SELinux se habilita de forma opcional. Para inhabilitarSELinux, desactive la aplicación de SELinux completando los siguientes pasos:

Procedimiento1. Abra el siguiente archivo:

/etc/sysconfig/selinux

2. Busque la siguiente línea:

SELINUX=enforcing

3. Cámbiela a SELINUX=disabled.4. Reinicie el servidor.

Tareas previas a la instalación para AIXPara instalar Network Manager en los sistemas operativos AIX, debe realizar tareas adicionales para quelos servidores estén preparados para la instalación.

Acerca de esta tareaEstas tareas no son necesarias si está utilizando otros sistemas operativos.


Configuración de Secure Shell (SSH) para AIXSi está planificando instalar como usuario no root en AIX y utilizar SSH para acceder al servidor de AIX,debe realizar algunos pasos de configuración adicionales antes de acceder el servidor de AIX.

Acerca de esta tareaConsejo: Si utiliza rlogin o telnet para acceder al servidor de AIX, no tendrá que realizar los siguientespasos.

Para asegurarse de que la instalación funciona, realice los siguientes pasos:

Procedimiento1. Abra el archivo /etc/ssh/sshd_config en el servidor AIX en el que desea instalar Network

Manager.2. Asegúrese de que el archivo contiene la siguiente línea:

UseLogin yes

3. Guarde y cierre el archivo.4. Ahora puede utilizar SSH para acceder al servidor e instalar Network Manager.

Instalación de un programa de utilidad zipEs necesario instalar un programa de utilidad zip para comprimir archivos antes de exportar laspersonalizaciones de la GUI con los scripts nmGuiExport.

Antes de exportar los datos de personalización de la GUI utilizando el script nmGuiExport, asegúrese deque instala un programa de utilidad zip en cada servidor en el que estén instalados los componentes dela GUI de su sistema anterior. Si no hay un programa de utilidad zip instalado en el servidor de susistema anterior, el script nmGuiExport fallará, no se creará el archivo upgradeData.zip y el scriptmostrará un mensaje de error.

Comprobación de los valores de puerto de terminación de E/S (IOCP)Si está instalando Network Manager en AIX y tiene previsto conectarse a una base de datos Oracle,asegúrese de que el valor de IOCP sea correcto.

Acerca de esta tareaDebe realizar estos pasos como usuario root.

Procedimiento1. Emita el siguiente mandato

/usr/sbin/lsdev -c iocp -F status

Proceda como se explica a continuación:

• Si este mandato devuelve el resultado Available, no necesita realizar ningún paso más de estatarea.

• Si el mandato devuelve un resultado distinto de Available, por ejemplo, Defined, siga el resto depasos de esta tarea.

2. Emita el mandato siguiente:

smitty iocp2

3. Seleccione Change/Show Characteristics of I/O Completion Ports.4. Cambie State to be configured at system restart de Defined a Available.


5. Reinicie el servidor de AIX.

Capítulo 3. Preparación para la instalación 43

Capítulo 4. Instalación de Network Manager yproductos relacionados

Instale los requisitos previos, los productos asociados y los componentes de Network Manager en elorden en que se presentan aquí.

Antes de empezarAntes de instalar los productos, revise los requisitos previos y los requisitos en Capítulo 2, “Planificaciónpara la instalación”, en la página 3 y complete las tareas previas a la instalación necesarias en Capítulo 3,“Preparación para la instalación”, en la página 41.

Acerca de esta tareaEl instrucciones que siguen son para instalar un componente a la vez. Para instalar dos o máscomponentes en un orden concreto en el mismo servidor, selecciónelos para que se instalen al mismotiempo y IBM Installation Manager los instala en el orden correcto.

Lista de comprobación para la instalaciónAntes de iniciar la instalación, compruebe que tiene preparada toda la información necesaria. Durante lainstalación, anote la información que necesitará más adelante.

Información a recopilar antes de la instalaciónRecopile toda la información siguiente que sea relevante para el despliegue antes de iniciar la instalación.Puede imprimir esta lista de comprobación.

Información de IBM Installation Manager

Ubicación de instalación: ______________________________ Donde piensa instalar IBMInstallation Manager. Por ejemplo, /opt/IBM/netcool/im/. Debe iniciar IBM Installation Managerdesde esta ubicación después de haberlo instalado.

Ubicación de datos: ______________________________ Ubicación donde IBM InstallationManager desempaqueta los paquetes y almacena los paquetes para retrotraerlos. Asegúrese de queesta ubicación tiene al menos 10 GB de espacio libre. Este directorio no debe contener o estar contenidoen la subcarpeta eclipseIM o la ubicación compartida de IBM Installation Manager. Una ubicaciónpara los datos es, por ejemplo, la ubicación /opt/IBM/netcool/IBMIMData.

Ubicación compartida: ______________________________ Se le solicita esta ubicación cuandoinstala el primer producto en IBM Installation Manager, no durante la instalación del propio IBMInstallation Manager. Este directorio no debe contener o estar contenido en la subcarpeta eclipseIM ola ubicación de datos de IBM Installation Manager. Una ubicación compartida es, por ejemplo, laubicación /opt/IBM/netcool/IBMIMShare.

Información deDb2 u Oracle

Recopile la siguiente información para su opción de base de datos antes de instalar Network Manager.

Directorio donde está instalado Db2 u Oracle: ______________________________

Si utiliza Db2, nombre de un usuario de sistema operativo y de Db2 que se debe utilizar paraconectarse a la base de datos de Db2:______________________________


Si utiliza Oracle, asegúrese de que tiene permiso para utilizar la característica de particionamiento.

El nombre de la base de datos Db2 o el Nombre de servicio Oracle:______________________________

Nombre de host del servidor donde está instalada la base dedatos:______________________________

Información de ObjectServer

Si desea utilizar un ObjectServer existente para los datos de sucesos de Network Manager, anote losdetalles aquí. Necesita estos detalles al instalar los componentes principales de Network Manager.

Nombre de ObjectServer: ______________________________

Nombre de host donde está instalado este ObjectServer:______________________________

Puerto configurado para conexiones a este ObjectServer:______________________________

ID de superusuario para el ObjectServer: ______________________________

Contraseña para este usuario: ______________________________

Información de los componentes principales de Network Manager

Recopile la siguiente información para los componentes principales antes de instalar Network Manager.

Vía de acceso de Python:______________________________ La vía de acceso completa a unaversión compatible de Python es necesaria para instalar los componentes principales de NetworkManager.

Usuario de agregación de sondeador: ______________________________ Si está instalandoNetwork Manager como usuario root, necesita un usuario no root para ejecutar el motor de agregaciónde sondeador. Este usuario de sistema operativo debe existir y debe tener permisos de escritura en eldirectorio de instalación.

Grupo de agregación de sondeador: ______________________________ Grupo al que pertenece elusuario de agregación del sondeador. El usuario de agregación del sondeador debe existir comomiembro de este grupo antes de que se lleve a cabo la agregación.

Información a recopilar durante la instalaciónDurante la instalación, debe definir diversos parámetros de configuración. Algunos de estos parámetrosson necesarios más adelante en la instalación. Anote la siguiente información mientras instala NetworkManager y los componentes relacionados.

Información de ObjectServer

Si crea un ObjectServer durante la instalación de los componentes principales de Network Manager,anote los detalles aquí.

Nombre del ObjectServer creado para utilizarlo con Network Manager:______________________________

Nombre de host donde está instalado este ObjectServer:______________________________


Puerto configurado para conexiones a este ObjectServer:______________________________

ID de superusuario para el ObjectServer: ______________________________

Contraseña para este usuario: ______________________________

Otra información relativa a los componentes principales de Network Manager

El nombre del usuario que ejecuta el instalador de Network Manager:______________________________ Este usuario también debe ejecutar los scripts de actualización almigrar a una nueva versión.

Contraseña para los usuarios de Network Manager predeterminados itnmadmin eitnmuser:______________________________

Nombre de dominio de red: ______________________________ Este es el nombre que ha elegidodurante la instalación de los componentes principales de Network Manager.

Información de WebSphere Application Server

Recopile la información siguiente mientras instala WebSphere Application Server:

Ubicación de instalación de WebSphere Application Server: ______________________________

Nombre de servidor de WebSphere Application Server: ______________________________

Nombre de usuario de WebSphere Application Server: ______________________________

Contraseña de WebSphere Application Server: ______________________________

Puerto de transporte HTTP: ______________________________

Puerto de transporte seguro HTTPS: ______________________________

Puerto de consola administrativa: ______________________________

Puerto seguro de consola administrativa: ______________________________

Raíz de contexto: ______________________________

Información de Dashboard Application Services Hub

Recopile la información siguiente mientras instala Dashboard Application Services Hub.

Directorio de instalación de Dashboard Application Services Hub:______________________________

Información relativa a los componentes de la GUI de Network Manager

Recopile la siguiente información mientras instala los componentes de GUI de Network Manager.

Contraseñas para los usuarios de Network Manager: ______________________________ Lacontraseña para los usuarios itnmadmin e itnmuser.

Capítulo 4. Instalación de Network Manager y productos relacionados 47

Instalación y configuración de IBM Installation ManagerAntes de instalar o actualizar Tivoli Netcool/OMNIbus, Network Manager o cualquier otro producto deIBM, instale o actualice IBM Installation Manager y configúrelo para utilizarlo.

Acerca de esta tareaTiene dos opciones para obtener el software de IBM Installation Manager y de Network Manager.

• Descargue IBM Installation Manager en el servidor de destino y conecte IBM Installation Manager aibm.com o a un repositorio local. IBM Installation Manager puede descargar otros productos.

• Descargue un paquete de software comprimido que contiene IBM Installation Manager y NetworkManager y cópielo en el servidor de destino.

Instalación de IBM Installation Manager descargando los archivos delproducto

Si desea instalar IBM Installation Manager y Network Manager en un servidor que no está conectado aInternet, descargue el software en otro servidor desde Passport Advantage. A continuación, cópielo en elservidor donde desee instalar el software.

Antes de empezarCree un ID de IBM en http://www.ibm.com. Necesita un ID de IBM para descargar software de PassportAdvantage.

Acerca de esta tareaNetwork Manager requiere IBM Installation Manager V1.9.1.3 o posterior. En SuSE Linux V11 y V12 forSystem z, solo se admitirá la versión de 32 bits de IBM Installation Manager.

Puede descargar un archivo comprimido desde Passport Advantage que contiene IBM InstallationManager, Network Manager y los scripts de creación de la base de datos.

Para instalar y configurar IBM Installation Manager, realice las siguientes tareas:

Procedimiento1. Localice el número de componente del componente Network Manager en el documento de descarga

en la ubicación siguiente:http://www.ibm.com/support/docview.wss?uid=swg24043360

2. Siga las instrucciones en el documento de descarga para descargar el software.3. Descomprima el paquete que ha descargado.4. Si desea utilizar los scripts de creación de base de datos de Network Manager sin ejecutar IBM

Installation Manager, puede copiarlos desde el nivel superior del paquete de instalacióndescomprimido.

5. Instale IBM Installation Manager en modalidad de grupo (se soportan todas las modalidades, peropara tener el mayor control de dónde se crean los archivos, utilice la modalidad de grupo (en lugar dela modalidad de no administrador o la modalidad de administración) utilizando las instrucciones de"Instalación o actualización de Installation Manager" para la versión adecuada de la información en:https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html

Nota: Siempre debe utilizar el mismo usuario para instalar, iniciar o detener todos los productosinstalados mediante IBM Installation Manager. No puede utilizar un usuario diferente, incluso si losproductos se han instalado en modalidad de grupo. Este usuario debe ser un usuario administrativopara todos los productos instalados en dicho servidor.


http://www.ibm.com/



Cuando IBM Installation Manager finaliza la instalación, se reinicia y continúa con la instalación deNetwork Manager. Instale Network Manager tal como se describe en “Instalación de los componentesprincipales de Network Manager” en la página 59 y en “Instalación de los componentes de la GUI deNetwork Manager” en la página 68.

Qué hacer a continuaciónLa próxima vez que utilice esta instalación de IBM Installation Manager, configure los repositorios quenecesite.

1. Pulse Archivo > Preferencias.2. Si se ha configurado un repositorio automáticamente, haga clic en Repositorios y asegúrese de que se

han seleccionado los repositorios correctos.3. Si no se han configurado repositorios automáticamente y desea configurar un repositorio, consulte la

información sobre cómo utilizar IBM Packaging Utility en la documentación de IBM InstallationManager: https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html

4. Si desea conectarse directamente al repositorio en línea de IBM para acceder a los productos para losque tiene autorización, haga clic en Passport Advantage, seleccione Conectar a Passport Advantage yhaga clic en Aplicar. Haga clic en Aceptar. Al instalar o actualizar un producto, se le solicitan lascredenciales para acceder a IBM Passport Advantage.

Instalación de IBM Installation Manager conectando directamente conPassport Advantage

Si desea instalar IBM Installation Manager y Network Manager en un servidor que se pueda conectar aibm.com, instale IBM Installation Manager y conéctelo a Passport Advantage.

Antes de empezarCree un ID de IBM en http://www.ibm.com. Necesita un ID de IBM para descargar software de PassportAdvantage.

Acerca de esta tareaNetwork Manager requiere IBM Installation Manager V1.9.1.3 o posterior. En SuSE Linux V11 y V12 forSystem z, solo se admitirá la versión de 32 bits de IBM Installation Manager.

Nota:

Si hay alguna diferencia entre estas instrucciones y la documentación para la versión de IBM InstallationManager debido a cambios o actualizaciones, la documentación de IBM Installation Manager tieneprioridad y se puede encontrar en: https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html

Para instalar y configurar IBM Installation Manager, realice las siguientes tareas:

Procedimiento1. Si ya tiene instalado IBM Installation Manager, compruebe que tiene la versión más reciente. Los

mandatos siguientes suponen que el servidor en el que está instalando está conectado a Internet, queel usuario está conectado a los repositorios de ibm.com y que se está utilizando la modalidad deasistente. Para todos los demás escenarios, consulte la documentación de IBM Installation Manager:https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.htmla) Inicie IBM Installation Manager cambiando el directorio de instalación. De forma predeterminada,

el directorio de instalación para las tres modalidades de instalación es:Modalidad de grupo

/user_home_directory/IBM/InstallationManager_Group/eclipse



http://www.ibm.com/




Modalidad de no administrador

/user_home_directory/IBM/InstallationManager/eclipse

Modalidad de administrador

/opt/IBM/InstallationManager/eclipse

y ejecute el siguiente mandato:

./IBMIM

b) Pulse Archivo > Preferencias.c) Si puede acceder a ibm.com desde este servidor, en el separador Repositorios, seleccione Buscar

repositorios de servicio durante la instalación y las actualizaciones.d) Si puede acceder a ibm.com desde este servidor, en el separador Repositorios, no seleccione

Buscar repositorios de servicio durante la instalación y las actualizaciones. Sin acceso aibm.com, la actualización se superará el tiempo de espera. En su lugar, descargue las últimasactualizaciones para IBM Installation Manager en el repositorio local y asegúrese de que elrepositorio está configurado en Repositorios. Si no se han configurado repositoriosautomáticamente y desea configurar un repositorio, consulte la información sobre cómo utilizarIBM Packaging Utility en la documentación de IBM Installation Manager: https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html

e) Pulse Actualizaciones y seleccione la opción Buscar actualizaciones de Installation Manager.f) Pulse Aceptar para cerrar la página Preferencias.g) Pulse uno de estos asistentes: Instalar o Actualizar.

Installation Manager busca las actualizaciones para sí mismo. Si se encuentra una versión másreciente, se le solicitará que actualice Installation Manager.

h) Para obtener información sobre la versión, pulse Detalles.i) Pulse Sí para actualizar Installation Manager.

2. Si no ha instalado IBM Installation Manager, instálelo ahora.a) Descargue la versión más reciente de IBM Installation Manager para su plataforma desde el

siguiente sitio web: https://www.ibm.com/support/pages/node/609575b) Instale IBM Installation Manager en modalidad de grupo (se soportan todas las modalidades, pero

para tener el mayor control de dónde se crean los archivos, utilice la modalidad de grupo (en lugarde la modalidad de no administrador o la modalidad de administración) utilizando las instruccionesde "Instalación o actualización de Installation Manager" para la versión adecuada de la informaciónen: https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html

Nota: Siempre debe utilizar el mismo usuario para instalar, iniciar o detener todos los productosinstalados mediante IBM Installation Manager. No puede utilizar un usuario diferente, incluso si losproductos se han instalado en modalidad de grupo. Este usuario debe ser un usuario administrativopara todos los productos instalados en dicho servidor.

3. Conéctese a un repositorio que contenga los productos que desea instalar:Un repositorio puede estar en un servidor local o en línea.a) Pulse Archivo > Preferencias.b) Si se ha configurado un repositorio automáticamente, pulse Repositorios y asegúrese de que se

han seleccionado los repositorios correctos.c) Si no se han configurado repositorios automáticamente y desea configurar un repositorio, consulte

la información sobre cómo utilizar administrar paquetes con IBM Packaging Utility en ladocumentación de IBM Installation Manager: https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html








d) Si desea conectarse directamente al repositorio en línea de IBM para acceder a los productos paralos que tiene autorización, haga clic en Passport Advantage, seleccione CConectar a PassportAdvantage y haga clic en Aplicar. Haga clic en Aceptar.Al instalar o actualizar un producto, se le solicitan las credenciales para acceder a IBM PassportAdvantage.

Instalación y configuración de una base de datos de topologíaEl administrador de base de datos debe instalar y configurar una base de datos de topología soportadaantes de poder instalar Network Manager.

Acerca de esta tareaNetwork Manager necesita utilizar una base de datos para almacenar la topología de red.

Network Manager soporta las siguientes bases de datos de topología:

• IBM Db2 versión 10.1 Enterprise Server Edition• IBM Db2 versión 10.5 Workgroup Server Edition• IBM Db2 versión 10.5 Enterprise Server Edition• IBM Db2 versión 11.1 Enterprise Server Edition• IBM Db2 versión 11.5 Enterprise Server Edition

• IBM Db2 versión 11.1 Advance Enterprise Server Edition• Oracle Database versión 11g, Enterprise Edition con opción de partición (soporte añadido en Network

Manager 4.2 Arreglo temporal 2)• Oracle Database versión 12c, Enterprise Edition con opción de partición• Oracle Database versión 19c, Enterprise Edition con opción de partición

Importante: Todos los sistemas de base de datos anteriores incluyen la prestación de particionamientode tabla. Los sistemas de base de datos Oracle requieren que se incluya la opción de particionamiento. Elparticionamiento de tabla es necesario para que Network Manager funcione correctamente.

Importante: Asegúrese de que la base de datos tenga todos los parches recomendados aplicados,incluidos los últimos niveles de parches.

Para instalar y configurar una base de datos, complete los siguientes pasos:

Procedimiento1. Instale una de las bases de datos soportadas:

• Instale Db2 desde Passport Advantage: http://www.ibm.com/software/howtobuy/passportadvantage/pao_customers.htm.

• Instale Oracle desde el proveedor de software.2. Instalar los scripts de creación de base de datos de topología de Network Manager utilizando IBM

Installation Manager.3. Configure la base de datos utilizando la información de las siguientes secciones.

Tareas relacionadasConfiguración de Cognos AnalyticsRealice estas tareas para configurar Cognos Analytics.Referencia relacionadaBases de datos de topología soportadasLa base de datos de topología predeterminada para Network Manager es IBM Db2 10.5 Enterprise ServerEdition.




Instalación y ejecución de los scripts de base de datos de Network ManagerDespués de que se haya instalado una base de datos soportada, debe instalar y ejecutar los scripts debase de datos para configurar la base de datos de topología para que Network Manager la utilice. Debeejecutar los scripts antes de instalar Network Manager.

Acerca de esta tareaSi ha descargado el paquete de software comprimido desde Passport Advantage, como se describe en“Instalación de IBM Installation Manager descargando los archivos del producto” en la página 48, losscripts de creación de base de datos están incluidos en el nivel superior del archivo de softwaredescomprimido. Copie los scripts en el servidor de base de datos y utilícelos.

De lo contrario, instale los scripts de creación de base de datos de la topología de Network Managerrealizando las tareas siguientes.

Procedimiento1. Inicie IBM Installation Manager:

a) Cambie al directorio en el que se ha instalado IBM Installation Manager.b) Ejecute el siguiente mandato:

./IBMIM

IBM Installation Manager se inicia en modalidad con asistente. Para utilizar la modalidad de líneade mandatos, silenciosa, de consola o de navegador web, consulte la información en Gestión deinstalaciones con Installation Manager en la documentación de IBM Installation Manager en:https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html. No todos losproductos y componentes soportan todas las modalidades de instalación.

2. Pulse Instalar.3. En la pantalla Instalar paquetes donde puede seleccionar los paquetes que desea instalar, seleccione

la última versión disponible de los scripts de creación de base de datos de topología de NetworkManager.

4. Pulse Siguiente, acepte los términos del acuerdo de licencia y pulse Siguiente de nuevo.5. Seleccione el grupo de paquetes IBM Netcool Core Server y pulse Siguiente.6. En la pantalla Instalar paquetes donde puede seleccionar características a instalar, seleccione los

scripts apropiados para el tipo de base de datos.7. Pulse Siguiente e Instalar.

ResultadosLos scripts de base de datos adecuados se instalan ahora de forma predeterminada en el directorioprecision/scripts/ del directorio de instalación (de forma predeterminada, /opt/IBM/netcool/core/precision/scripts/). Para su comodidad, también se crea un archivo comprimido que contiene los mismosscripts de base de datos en el directorio de instalación. Si ha instalado los scripts en un servidor diferenteal servidor de base de datos, copie el archivo comprimido en el servidor de base de datos y, acontinuación, descomprímalo para utilizar los scripts de base de datos. Utilice la información de losapartados siguientes para configurar la base de datos de topología utilizando los scripts.

Configuración de bases de datos Db2 existentes en UNIXPara utilizar una base de datos Db2 existente como base de datos de topología en UNIX, debe tener unainstancia de Db2 disponible antes de instalar Network Manager.



Antes de empezarLa base de datos para Network Manager la crean los scripts instalados en el precision/scripts/ deldirectorio de instalación (de forma predeterminada, /opt/IBM/netcool/core/precision/scripts/). Debetener instalados los scripts antes de intentar crear la base de datos. Para obtener más información acercade cómo instalar los scripts de base de datos en el servidor de base de datos, consulte Instalación yejecución de los scripts de base de datos del Network Manager en IBM Tivoli Network Manager IP Edition:Guía de instalación y configuración.

Acerca de esta tareaDurante la instalación de Network Manager, la base de datos de NCIM está instalada en la base de datosDb2 que ha creado.

Para obtener información acerca de cómo instalar y configurar Db2, consulte la documentación de Db2 enhttp://www.ibm.com/support/knowledgecenter/SSEPGG/welcome

Procedimiento1. Asegúrese de que tiene una instancia de Db2 en la que el proceso de instalación puede crear la base

de datos de NCIM. Varios dominios de Network Manager pueden compartir la misma instancia2. Vaya al directorio en el que se ha instalado la instancia y, a continuación, vaya al subdirectoriosqllib.

3. Configure el entorno utilizando el siguiente mandato:Shell Mandato

Bourne . ./db2profile

C source db2cshrc

Los scripts del derivador de la aplicación de Network Manager configuran de forma automática elentorno de Db2.

4. Cambie a precision/scripts/ del directorio de instalación (de forma predeterminada, /opt/IBM/netcool/core/precision/scripts/).

5. Como usuario, administrativo, por ejemplo, el usuario db2inst1, ejecute el scriptcreate_db2_database.sh como el usuario administrativo de Db2 escribiendo el mandato siguienteen el servidor Db2:./create_db2_database.sh nombre_base_datos nombre_usuario -force

Donde:

nombre_base_datosEs el nombre de la base de datos.

nombre_usuario

Es el usuario de Db2 que se ha de utilizar para conectar con la base de datos.

Importante: Este usuario no debe ser el usuario de administración. Este usuario debe ser unusuario de un sistema operativo existente y de Db2.

-forceEs un argumento que fuerza la salida de cualquier usuario de Db2 de la instancia antes de que secree la base de datos.

Por ejemplo, para crear una base de datos Db2 denominada ITNM para el usuario de Db2 ncim,escriba:

./create_db2_database.sh ITNM ncim

Después de ejecutar create_db2_database.sh, reinicie la base de datos como el usuarioadministrativo de Db2 de la siguiente manera: ejecute db2stop y, a continuación, ejecute db2start.


http://www.ibm.com/support/knowledgecenter/SSEPGG/welcome

6. Al ejecutar el instalador de Network Manager más adelante, asegúrese de que selecciona la opción deconfigurar una base de datos Db2 existente. El instalador de Network Manager puede crear las tablasde la base de datos en el host local o en un host remoto, dependiendo de dónde esté instalada la basede datos.

El instalador rellena las propiedades de conexión en los archivos siguientes, puede consultar estosarchivos para ver si existe algún problema con la conexión a la base de datos. Para obtener másinformación sobre la edición de los archivos siguientes, consulte Configuración de Network Managerpara una dirección IP cambiada del servidor Db2 NCIM en IBM Tivoli Network Manager IP Edition: Guíade instalación y configuración.

• Los archivos DbLogins.DOMAIN.cfg y MibDbLogin.cfg en NCHOME/etc/precision. Estosarchivos se utilizan en los procesos principales de Network Manager.

• El archivo tnm.properties en $NMGUI_HOME/profile/etc/tnm. Estos archivos se utilizan en laGUI de Network Manager.

Conceptos relacionadosArquitectura de migración tras error de Network Manager (procesos principales)La migración tras error de los procesos principales de Network Manager se puede implementarestableciendo las instalaciones principales y de copia de seguridad de Network Manager que se ejecutanen distintos servidores. Ambas instalaciones pueden conectarse a un único ObjectServer de TivoliNetcool/OMNIbus o a un par virtual de ObjectServers.

Instalación y configuración de bases de datos de Oracle en UNIXPara utilizar una base de datos de topología en UNIX, debe instalar Oracle, configurar un esquema y crearuna base de datos antes de instalar Network Manager. Durante la instalación, la base de datos detopología NCIM está instalada en la base de datos de Oracle que ha creado.

Antes de empezarLa base de datos para Network Manager la crean los scripts instalados en el precision/scripts/ deldirectorio de instalación (de forma predeterminada, /opt/IBM/netcool/core/precision/scripts/). Debetener instalados los scripts antes de intentar crear la base de datos.

Necesita acceso a un indicador de mandatos que pueda utilizar el cliente de Oracle SQL*Plus paraacceder a la base de datos.

Acerca de esta tareaAntes de instalar Oracle, asegúrese de que tiene permiso para utilizar la característica departicionamiento. Esta característica adicional es necesaria para que Network Manager funcionecorrectamente.

Para obtener información sobre la instalación y configuración de Oracle, consulte la documentación deOracle en http://docs.oracle.com/en/database/.

El script de creación de bases de datos crea usuarios para varios usuarios de Oracle. Solo al usuario ncimse le otorga permiso para conectarse a la base de datos. Al usuario ncim también se le otorga permisopara acceder a los esquemas de los otros usuarios. La contraseña predeterminada para el usuario ncimque ha creado este script es también ncim.

Procedimiento1. Instale Oracle, incluyendo la característica de particionamiento, y configure un esquema en el

proceso de instalación pueda crear la base de datos de NCIM.2. Asegúrese de que no existen conflictos de puertos con el servicio HTTP de la base de datos Oracle

XML.El servicio HTTP de la base de datos Oracle XML está configurado para utilizar el puertopredeterminado 8888.


http://docs.oracle.com/en/database/

3. Asegúrese de que se está ejecutando el escuchador Oracle TNS en el servidor de Oracle escribiendoel siguiente mandato: $ORACLE_HOME/bin/lsnrctl status.

4. Si no se está ejecutando el escuchador Oracle TNS, escriba el siguiente mandato para iniciarlo:$ORACLE_HOME/bin/lsnrctl start.

5. Como administrador de base de datos de Oracle, cambie a precision/scripts/ del directorio deinstalación (de forma predeterminada, /opt/IBM/netcool/core/precision/scripts/).

6. Si ha instalado Oracle en un servidor diferente a Network Manager, copie el archivooracle_creation_scripts.tar.gz en dicho servidor y extraiga todos los archivos.

7. Ejecute el script create_oracle_ncadmin_user.sh en el servidor donde está instalada la basede datos. Inicie sesión en el host de Oracle como administrador de base de datos de Oracle y ejecuteel script create_oracle_ncadmin_user.sh proporcionando el usuario sys y la contraseña.Ejecute el script como en el ejemplo siguiente:

$NCHOME/precision/scripts/sql/oracle/create_oracle_ncadmin_user.sh sys password [-pdb pluggable_database_name]

Donde se aplican los parámetros siguientes:

contraseñaEspecifica la contraseña del usuario sys.

-pdb nombre_basedatos_conectableOpcional: Si está ejecutando Oracle 12c con RAC, debe utilizar una base de datos conectable. Eneste caso, utilice este parámetro para especificar el nombre de la base de datos conectableOracle 12c.

8. Para crear la base de datos, ejecute el script ./create_oracle_database.sh. Comoadministrador de base de datos de Oracle, ejecute el script ./create_oracle_database.shproporcionando el usuario system y la contraseña. En el servidor de Network Manager, el script seencuentra en el directorio $ITNMHOME/scripts/sql/oracle. Ejecute el script en el servidordonde se ha instalado la base de datos. Ejecute el script como en el ejemplo siguiente:

./create_oracle_database.sh system password [-asm] [-pdb pluggable_database_name]

Donde se aplican los parámetros siguientes:

contraseñaEspecifica la contraseña del usuario system.

-asmEspecifique -asm si la base de datos de Oracle utiliza ASM.

-pdb nombre_basedatos_conectableOpcional: Si está ejecutando Oracle 12c con RAC, debe utilizar una base de datos conectable. Eneste caso, utilice este parámetro para especificar el nombre de la base de datos conectableOracle 12c.

9. Cuando ejecute el instalador de Network Manager posteriormente, asegúrese de que selecciona laopción para conectar a una base de datos Oracle existente. El instalador de Network Manager puedecrear las tablas de la base de datos en el host local o en un host remoto, dependiendo de dónde estéinstalada la base de datos.

El instalador rellena las propiedades de conexión en los archivos siguientes, puede consultar estosarchivos para ver si existe algún problema con la conexión a la base de datos. Para obtener másinformación sobre la edición de los archivos siguientes, consulte Configuración de Network Managerpara una dirección IP cambiada del servidor Db2 NCIM en IBM Tivoli Network Manager IP Edition:Guía de instalación y configuración.

• Los archivos DbLogins.DOMAIN.cfg y MibDbLogin.cfg en NCHOME/etc/precision. Estosarchivos se utilizan en los procesos principales de Network Manager.


• El archivo tnm.properties en $NMGUI_HOME/profile/etc/tnm. Estos archivos se utilizan enla GUI de Network Manager.

Nota: Si está instalando Network Manager en un entorno Oracle de alta disponibilidad que utiliza RAC(Real Application Clusters), instale Network Manager antes, con una conexión directa a un nodo únicoen el clúster de Oracle. Una vez instalado Network Manager correctamente, puede configurar la altadisponibilidad para Network Manager utilizando una dirección SCAN (Single Client Access Name) deOracle, como se describe en Configuración de Network Manager para trabajar con Db2 HADR u OracleRAC en IBM Tivoli Network Manager IP Edition: Guía de instalación y configuración.

10. Opcional: Tras instalar Network Manager, ejecute el script $NCHOME/precision/scripts/sql/oracle/restrict_oracle_privileges.sh como usuario con privilegios del sistema. Ahora quese han creado todas las bases de datos y esquemas, se puede utilizar este script para revocar losprivilegios de creación de base de datos del usuario de base de datos de NCIM. Únicamente seguiráteniendo permisos para aquellas operaciones que sean necesarias para Network Manager durante eltiempo de ejecución.

11. Opcional: Para habilitar el cifrado de red Oracle Network Encryption, configure el cifrado comoREQUERIDO en el servidor de la base de datos.No es necesario configurar Network Manager para el cifrado Oracle Network Encryption. Consulte ladocumentación de Oracle para obtener detalles sobre cómo habilitar el cifrado Oracle NetworkEncryption.

Configuración de NCIM para usar caracteres multibyteSi desea que la base de datos NCIM almacene datos multibyte, debe configurar la base de datos NCIMpara utilizar caracteres multibyte, como caracteres chinos simplificados. Esta configuración es útilcuando, por ejemplo, necesita especificar caracteres multibyte en el campo de descripción de unadefinición de sondeo.

Acerca de esta tareaAsegúrese de que tiene los siguientes valores de configuración para la base de datos NCIM:Db2

Si está ejecutando Network Manager en un entorno local que soporta caracteres multibyte, no esnecesario realizar ningún cambio de configuración. Por ejemplo, los dos siguientes entornos localessoportan caracteres multibyte cuando NCIM se está ejecutando en Db2:

• LANG=zh_CN.gb18030LC_ALL=zh_CN.gb18030

• LANG=en_US.utf8LC_ALL=en_US.utf8

Configuración de NCIM para manejar caracteres multibyte en una base dedatos de OracleUtilice esta información para configurar la base de datos NCIM que se ejecuta en Oracle para manejarcaracteres multibyte.

Acerca de esta tareaPara configurar NCIM para manejar caracteres multibyte en una base de datos de ORACLE:

Procedimiento1. Defina la variable de entorno NLS_LANG de Oracle a un valor adecuado.

Por ejemplo, si el sistema se está ejecutando bajo el entorno local zh_CN.gb18030, cambie el valorNLS_LANG al siguiente valor: SIMPLIFIED CHINESE_CHINA.ZHS32GB18030.


Un conjunto completo de valores de variable de entorno NLS_LANG para diferentes entornos localesestá disponible en el sitio web de Oracle.

2. Establezca el entorno Network Manager para seleccionar los cambios después de la instalación.

• Vaya al directorio de $NCHOME y emita el siguiente mandato: source env.sh.

Instalación y configuración de Tivoli Netcool/OMNIbusDebe instalar Tivoli Netcool/OMNIbus antes de instalar Network Manager.

Acerca de esta tareaNetwork Manager necesita Tivoli Netcool/OMNIbus. Da soporte a las siguientes versiones de TivoliNetcool/OMNIbus:

• V7.4• V8.1 FixPack 23 o posterior

Si aún no ha instalado Tivoli Netcool/OMNIbus y piensa instalarlo en el mismo servidor que NetworkManager, no tiene que hacer nada.

Al instalar Network Manager, instale Tivoli Netcool/OMNIbus al mismo tiempo seleccionando loscomponentes principales de Tivoli Netcool/OMNIbus y Network Manager del paquete IBM Netcool CoreComponents.

El instalador de componentes principales de Network Manager configura Tivoli Netcool/OMNIbusautomáticamente durante la instalación.

Si no ha instalado Tivoli Netcool/OMNIbus y tiene previsto instalarlo en un servidor que no es NetworkManager, instale Tivoli Netcool/OMNIbus antes que Network Manager.

Consulte la información sobre la instalación de la versión de Tivoli Netcool/OMNIbus en: http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

A continuación instale Netcool/OMNIbus Knowledge Library y Probe for SNMP. Consulte la informaciónsobre cómo instalar Netcool/OMNIbus Knowledge Library en http://www.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/nckl/wip/concept/nckl_intro.html y la información sobre lainstalación de Probe for SNMP en http://www.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/snmp/wip/concept/snmp_introduction_c.html.

Si ya ha instalado Tivoli Netcool/OMNIbus, Netcool/OMNIbus Knowledge Library y Probe for SNMP, ahorapuede instalar Network Manager.

El instalador de Network Manager configura Tivoli Netcool/OMNIbus automáticamente durante el procesode instalación.

Si ya ha instalado y configurado Network Manager y Tivoli Netcool/OMNIbus pero alguien ha modificadoel ObjectServer después de la instalación, debe volver a integrar el ObjectServer con Network Manager.Para volver a integrar el ObjectServer, debe estar informado de las siguientes áreas.

• Núcleo de Network Manager. Si el nombre de ObjectServer, el puerto o el nombre de host cambia, sedeben realizar cambios manuales en el núcleo de Network Manager.

• Integración con el origen de datos de GUI web. Para obtener más información sobre la integración conel origen de datos de GUI web, consulte “Configuración del nombre de origen de datos de GUI web deTivoli Netcool/OMNIbus” en la página 92.

• Script config_object_server_for_itnm.sh. Se ha añadido soporte para este script en NetworkManager 4.2 Arreglo temporal 2; si tiene el Arreglo temporal 2, este script sustituye al scriptConfigOMNI. Permite configurar un ObjectServer de Windows o UNIX existente para ejecutarse conNetwork Manager. El script se ejecuta en el servidor principal de Network Manager y puede utilizarsepara configurar un ObjectServer en el servidor local o en un servidor remoto.

• Script ConfigOMNI. Utilice el script ConfigOMNI para crear y configurar un ObjectServer para que seejecute con Network Manager. El script crea los activadores de Network Manager. Si el ObjectServer


http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html


http://www.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/nckl/wip/concept/nckl_intro.html

http://www.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/nckl/wip/concept/nckl_intro.html

http://www.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/snmp/wip/concept/snmp_introduction_c.html

http://www.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/snmp/wip/concept/snmp_introduction_c.html

está en un servidor remoto, copie el script $NCHOME/precision/install/scripts/ConfigOMNI yel script de soporte $NCHOME/precision/scripts/create_itnm_triggers.sql y póngalos en elmismo directorio del ObjectServer remoto. Si el ObjectServer es local para Network Manager, puedeutilizar ambos scripts tal cual.

Tareas relacionadasConfiguración de ObjectServer para su uso con los procesos principales de Network ManagerSólo para los usuarios con Network Manager 4.2 Arreglo temporal 2, puede utilizar el scriptconfig_object_server_for_itnm.sh para configurar un ObjectServer para su uso con los procesosprincipales de Network Manager. Este script da soporte a un ObjectServer ejecutándose en Windows yUNIX. El script configura la conexión con el ObjectServer y puede utilizarse para configurar unObjectServer local o remoto. También ejecuta varios mandatos SQL que crean y configuran en elObjectServer las tablas y los usuarios que necesita Network Manager.

Opciones de línea de mandatos para ConfigOMNIUtilice el script $NCHOME/precision/install/scripts/ConfigOMNI, con argumentos avanzadosopcionales, para configurar Tivoli Netcool/OMNIbus para su uso con Network Manager.

El script ConfigOMNI se inicia mediante el uso de la siguiente línea de mandatos; los argumentosopcionales se muestran dentro de corchetes.

ConfigOMNI -o name -p password [ -a ] [ -c ] [ -e ] [ -h directory ] [ -n portnumber ] [ -u password ] [ -z PA authentication ]

El ejemplo siguiente ejecuta el script en ObjectServer DIAMOND con la contraseña de administraciónp3w0d. Si ObjectServer DIAMOND no existe, se creará. Utilizando las opciones adecuadas, puede utilizarel script para añadir los usuarios itnmadmin e itnmuser, a ObjectServer, activar el cifrado AES y activarel control de procesos para Objectserver.

Nota: El script ConfigOMNI no realiza ninguna configuración a menos que se faciliten las opciones delínea de mandatos adecuadas, o que responda a las preguntas adecuadas.

ConfigOMNI -o DIAMOND -p p3w0d

Nota: El script ConfigOMNI se ha diseñado para ser utilizado cuando se configura por primera vez unObjectServer. Si se ejecuta varias veces el mismo script ConfigOMNI en el mismo host, es posible quesea necesario editar los archivos siguientes:

1. El archivo nco_p_mttrapd.props para eliminar las propiedades duplicadas Server,ServerBackup, RulesFile, MIBFile y QuietOutput al final del archivo.

2. El archivo nco_pa.conf para cambiar cualquier nombre nco_process duplicado, ya que el scriptsiempre proporcionará entradas con los nombres MasterObjectServer y Mttrapd. Para obtenermás información acerca de cómo editar este archivo, consulte la documentación de Tivoli Netcool/OMNIbus en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html, y busque el tema "Definición de procesos en el archivo de configuración delagente de procesos".

La tabla siguiente describe las opciones de línea de mandatos para el script ConfigOMNI.

Tabla 6. Opciones de línea de mandatos para ConfigOMNI

Opciones de línea de mandatos Descripción

-o nombre El nombre del ObjectServer que desea crear oconfigurar.

-p contraseña La contraseña de administración del ObjectServerque desea crear o configurar.

-a Opcional. Ejecuta el script en modalidadinteractiva, lo que solicita toda la información.




Tabla 6. Opciones de línea de mandatos para ConfigOMNI (continuación)

Opciones de línea de mandatos Descripción

-c Opcional. Configura el ObjectServer para que seejecute bajo el control de proceso Tivoli Netcool/OMNIbus.

-e Opcional. Establece cifrado de AES para lacontraseña de ObjectServer.

-h directorio Opcional. El directorio que contiene la instalaciónde Tivoli Netcool/OMNIbus (OMNIHOME).

-n númeropuerto Opcional. El número de puerto del ObjectServerque desea crear o configurar.

-u contraseña Opcional. Cree los usuarios itnmadmin eitnmuser en ObjectServer.

-z autenticación_agente_proceso Opcional. Proporciona autenticación para el agentede procesos de Tivoli Netcool/OMNIbus, NCO_PA,para el inicio de NCO_PA. Si no especifica un valor,se utiliza el valor predeterminado PAM.

Instalación de los componentes principales de Network ManagerDebe instalar los componentes principales de Network Manager antes o al mismo tiempo que lainstalación de los componentes de GUI.

Antes de empezarAntes de instalar los componentes principales de Network Manager, debe instalar y configurar una basede datos de topología, instalar IBM Installation Manager e instalar e iniciar Tivoli Netcool/OMNIbus.

Asegúrese de que se ha instalado una versión compatible de Python en este servidor antes de empezar.En Linux, Network Manager necesita que se instale la versión 2.6.6 o posterior de Python 2 (no Python 3)en el servidor donde están instalados los componentes principales. En AIX, Network Manager necesita laversión 2.7.5 o superior de Python 2 (no Python 3).

Acerca de esta tarea

Importante: Si desea utilizar la versión 9 de WebSphere Application Server, debe tener instalado la nuevaversión 9 de WebSphere Application Server y el Network Manager Fix Pack 11. Esto se debe a que la rutade actualización no está disponible para WebSphere Application Server de la versión 8 a la 9.

Importante: La instalación del Fixpack 6 o una versión posterior elimina los archivos MIB existentes.Network ManagerEstos Fix Packs no contienen la Base de datos de información de administración(archivos MIB). Network Manager Fix Pack 5 sí contiene los archivos MIB. Los MIB son necesarios para ladetección de redes.

Si está actualizando desde el Fix Pack 5 o anterior, complete los siguientes pasos para obtener losarchivos MIB:

1. Localice un archivo zip llamado com.ibm.tivoli.netcool.ncp.mibs.all.any_*.zip dentro dela ubicación compartida de IBM Installation Manager que contiene los archivos MIB de la instalacióndel Fix Pack anterior. La ruta exacta puede ser distinta en su instalación. Una ruta de ejemploes: /opt/IBM/IBMIM/native/


2. Descomprima este archivo.3. Cargue las MIB en la base de datos ejecutando el mandato ncp_mib, como se describe en Carga de

información actualizada de MIB en IBM Tivoli Network Manager IP Edition: Guía de instalación yconfiguración.

Si está instalando Fix Pack 6, 7, 8 o 9 sin actualizar, o no puede localizar los archivos MIB utilizando elprocedimiento anterior, complete los siguientes pasos para obtener los archivos MIB:

1. Ejecute el comando ncp_mib, como se describe en: Cargando información actualizada de MIB en elIBM Tivoli Network Manager IP Edition: Guía de instalación y configuración.

2. Si tiene instalado Network Manager 4.2 Fix Pack 5, realice una copia de seguridad del contenido deldirectorio $NCHOME/precision/mibs/ en un directorio de copia de seguridad fuera de $NCHOME.Por ejemplo, /mibs_backup/.

3. Si tiene instalada una versión anterior a la 4.2 de Fix Pack 5, realice los pasos siguientes:

a. Realice una copia de seguridad del contenido del directorio $NCHOME/precision/mibs/ en undirectorio de copia de seguridad fuera de $NCHOME. Por ejemplo, /old_mibs/. Conserve estedirectorio y sus archivos en caso de que desee volver a esta versión más adelante.

b. Descargue los archivos de Network Manager Fix Pack 5 (4.2.0.5) desde IBM Fix Central: https://www.ibm.com/support/fixcentral/

Importante: Descargue los archivos para Linux x86, independientemente de la plataforma queesté utilizando.

c. Expanda el paquete de Network Manager en un directorio temporal.d. Expanda el archivo repositories/disk1/ad/native/file000876 en un directorio de copia

de seguridad fuera de $NCHOME, por ejemplo, /mibs_backup/. Este directorio contiene ahora losarchivos MIB predeterminados.

e. Si ha personalizado o agregado archivos MIB, copie los archivos MIB personalizados o nuevos de /old_mibs/ sobre los archivos predeterminados en /mibs_backup/.

4. Independientemente de la versión de Network Manager que haya instalado, el directorio /mibs_backup/ contiene ahora el conjunto más actual de archivos MIB de Fix Pack 5, además de lasadiciones y personalizaciones.

Después de obtener los archivos MIB, instale la versión más reciente de Network Manager.

1. Instale Network Manager Fix Pack 6 o posterior con las instrucciones de este procedimiento.2. Copie los archivos MIB del directorio /mibs_backup/ a la siguiente ubicación dentro de la

instalación: $NCHOME/precision/mibs/3. Ejecute el comando ncp_mib, como se describe en: Cargando información actualizada de MIB en el

IBM Tivoli Network Manager IP Edition: Guía de instalación y configuración.

Para desinstalar o Fix Pack 6 o posterior y utilizar una versión anterior, siga los siguientes pasos:

1. Copie los archivos MIB del directorio siguiente a un directorio temporal: $NCHOME/precision/mibs/

2. Elimine todos los archivos del directorio $NCHOME/precision/mibs.3. Desinstale Network Manager Fix Pack 6 o posterior con las instrucciones en: Desinstalación de fix

packs en el IBM Tivoli Network Manager IP Edition: Guía de instalación y configuración.4. Si va a regresar a la versión 4.2 de Fix Pack 5, copie los archivos MIB desde el directorio temporal al

directorio MIB: $NCHOME/precision/mibs/5. Si va a volver a una versión anterior a 4.2 Fix Pack 5, copie los archivos MIB del directorio de copia de

seguridad /old_mibs/ al directorio MIB: $NCHOME/precision/mibs/6. Ejecute el comando ncp_mib, como se describe en: Cargando información actualizada de MIB en el

IBM Tivoli Network Manager IP Edition: Guía de instalación y configuración

Para instalar los componentes principales de Network Manager, complete las tareas siguientes.






./IBMIM


2. Pulse Instalar.3. En la siguiente pantalla Instalar paquetes, donde puede seleccionar los paquetes que desea

instalar, seleccione la última versión disponible de los Componentes principales de NetworkManager.Se evalúan los requisitos previos para instalar el paquete.

4. Si se muestran problemas con requisitos previos, resuélvalos utilizando la información proporcionadaantes de continuar.

5. Pulse Siguiente, acepte los términos del acuerdo de licencia y pulse Siguiente de nuevo.6. Seleccione el grupo de paquetes IBM Netcool Core Components y pulse Siguiente.

Restricción: Si está instalando Network Manager en el mismo servidor que Tivoli Netcool/OMNIbus,debe instalar los componentes principales del mismo grupo de paquetes que Tivoli Netcool/OMNIbus.

7. Seleccione los Componentes principales que se deben instalar.8. Seleccione Rutinas criptográficas adicionales si desea utilizar todas las opciones criptográficas que

proporciona Network Manager. Borre esta opción si la conformidad con FIPS 140-2 es importante,porque algunos de los componentes no son compatibles con este estándar. Para obtener másinformación, consulte “Instalaciones de FIPS 140-2” en la página 38.

9. En las siguientes pantallas Instalar paquetes, proporcione información de configuración para lospaquetes que se están instalando. Utilice Siguiente y Atrás para pasar por las opciones deconfiguración.

10. Opcional: Si está instalando Network Manager al mismo tiempo que Tivoli Netcool/OMNIbus, o en elmismo grupo de paquetes que una instalación de Tivoli Netcool/OMNIbus que no se ha configuradopara utilizarse con Network Manager, crea un nuevo ObjectServer de agregado. Configure el nuevoObjectServer:Nombre

Acepte el nombre predeterminado de NCO_AGG_P o especifique un nuevo nombre para elObjectServer. Si este ObjectServer está pensado para utilizarse en una arquitectura con múltiplesObjectServers, mantenga el sufijo _AGG_P en el nombre. Por convención, los nombres deObjectServer están en mayúsculas. Necesitará este nombre más adelante para iniciar y detenerel ObjectServer. Anote el nombre en la “Lista de comprobación para la instalación” en la página45.

HostEntre el nombre de host del servidor donde está instalado Tivoli Netcool/OMNIbus.

PuertoEntre un puerto a utilizar para la conexión con el ObjectServer o acepte el valor predeterminado.

ID de superusuarioLa instalación utiliza el usuario root Tivoli Netcool/OMNIbus .

ContraseñaEscriba la contraseña del usuario root.



Confirmar contraseñaEntre la contraseña de nuevo.

11. Opcional: Si está instalando Network Manager en un servidor diferente de Tivoli Netcool/OMNIbus,Network Manager se conecta con un ObjectServer existente. El ObjectServer debe estar en ejecucióny accesible desde este servidor. Especifique los detalles del ObjectServer al que Network Manager sedebe conectar.Nombre

Entre el nombre de ObjectServer.Host

Entre el nombre de host del servidor donde está instalado Tivoli Netcool/OMNIbus.Puerto

Entre un puerto a utilizar para la conexión con el ObjectServer o acepte el valor predeterminado.ID de superusuario

Entre el nombre de un usuario con los permisos administrativos para Tivoli Netcool/OMNIbus.Contraseña

Entre la contraseña para este usuario.Los detalles de las conexiones se comprueban con el ObjectServer en ejecución. Seleccione Omitir laconfiguración y verificación de detalles de conexión de ObjectServer si actualmente no puedeverificar los detalles, por ejemplo, si el ObjectServer no está accesible. Si omite este proceso, deberealizar los cambios posteriormente de forma manual.

12. Configure los usuarios predeterminados de Network Manager. Los usuarios itnmadmin y itnmuserlos crea el instalador en ObjectServer. Se utiliza la misma contraseña para ambos usuarios.Contraseña

Especifique una contraseña para estos usuarios. Anote la contraseña.Confirmar contraseña

Confirme la contraseña.13. Entre un nombre para el dominio de red. Este nombre es visible para los operadores de red y

administradores de producto. También puede añadir, eliminar y cambiar los dominios más tarde.Anote el nombre que prefiera. Necesita este nombre para iniciar los componentes de NetworkManager.

14. Entre los detalles de la base de datos de topología que se ha instalado. Tome nota de estos detalles.Necesita los mismos detalles al instalar los componentes de GUI.a) Seleccione el tipo de base de datos.b) Entre los detalles de conexión de base de datos:

Si ha seleccionado Db2 como el tipo de base de datos, especifique los siguientes detalles:Nombre de la base de datos

Entre el nombre de la base de datos.Host de servidor

Entre el nombre de host del servidor donde está instalada la base de datos.Puerto de servidor

Entre el número de puerto para conectarse a la base de datos.ID de usuario

Introduzca el ID de un usuario de Db2 existente que tenga permisos para crear tablas.Contraseña

Entre la contraseña para este usuario.

Si ha seleccionado Oracle como el tipo de base de datos, entre los siguientes detalles:Nombre de servicio Oracle

Escriba el nombre de servicio de la base de datos.


Host de servidorEntre el nombre de host del servidor en el que está instalada la base de datos.

ID de usuarioEntre el ID de un usuario de Oracle existente que tenga permisos para acceder a las tablasNCIM. El ID de usuario predeterminado es ncim.

ContraseñaEntre la contraseña para este usuario.

c) Seleccione Crear tablas para mantener los datos de topología en la base de datos creada paracrear las tablas de base de datos que son necesarias para Network Manager. Si ya ha creado lastablas de base de datos utilizando los scripts de creación de base de datos, no es necesarioseleccionar esta opción. Si ya ha creado las tablas y selecciona la opción para crearlas de nuevo,recibirá un error al final de la instalación. Este error indica que las tablas no se han creado.

d) Seleccione Omitir verificación d detalles de conexión de base de datos si no desea verificar laconexión, si la base de datos es inaccesible o por otras razones.

15. Configure los detalles para la agregación de sondeador:Vía de acceso de Python

Entre la vía de acceso completa a una versión compatible de Python.Usuario de agregación de sondeador

Si está realizando ala instalación como un usuario root, debe especificar el nombre de usuario deun usuario no root aquí. Este usuario es necesario para ejecutar el motor de agregación desondeador. Si está realizando la instalación como un usuario no root, se utiliza el usuario deinstalación para ejecutar el motor de agregación de sondeador y no ve esta opción en elinstalador. Este usuario se debe crear antes de que se lleve a cabo una agregación del sondeador.

Usuario de grupo de agregaciónEscriba el grupo al que pertenece el usuario de agregación del sondeador. Si el usuario pertenecea un grupo diferente al del usuario de instalación, el instalador cambia los permisospredeterminados en los archivos y carpetas, de modo que funcione la agregación del sondeador.El usuario debe existir como miembro de este grupo antes de que se lleve a cabo la agregación.

16. Revise la información de resumen y pulse Instalar.

ResultadosSe instalan los componentes principales de Network Manager. Los errores se graban en el archivo deregistro de instalación, que puede ver pulsando Ver archivo de registro. Los archivos de registro semantienen en el directorio /logs/ en la ubicación de datos de IBM Installation Manager.Tareas relacionadasHabilitación del sondeo históricoSi ha instalado Network Manager como usuario root, deberá ejecutar el scriptsetup_run_storm_as_non_root.sh para permitir que se ejecuten los procesos de datos de sondeohistórico. No es necesario que ejecute este script si ha instalado Network Manager como usuario no root.

Instalación de WebSphere Application ServerDebe instalar los componentes de WebSphere Application Server necesarios antes de instalar Jazz forService Management.

Antes de empezarDebe instalar WebSphere Application Server en el servidor donde desea instalar los componentes de GUIde Network Manager.

Acerca de esta tareaNota:


Si hay alguna diferencia entre estas instrucciones y la documentación para la versión de WebSphereApplication Server debido a cambios o actualizaciones, la documentación de WebSphere ApplicationServer tiene prioridad y se puede encontrar en: https://www.ibm.com/support/knowledgecenter/SSEQTP/mapfiles/product_welcome_was.html

Procedimiento1. En el servidor donde desea instalar los componentes de GUI de Network Manager, asegúrese de que

IBM Installation Manager está instalado.2. Inicie IBM Installation Manager:


./IBMIM



instalar, seleccione los siguientes componentes y pulse Siguiente:

• IBM Websphere Application Server.

Nota: Si desea utilizar la versión 9 de WebSphere Application Server, debe tener instalado la nuevaversión 9 de WebSphere Application Server, Network Manager Fix Pack 11 o la GUI web de TivoliNetcool/OMNIbus versión 8.1.0.20 o posterior. Esto se debe a que la ruta de actualización no estádisponible para WebSphere Application Server de la versión 8 a la 9.

• IBM Websphere SDK Java Technology Edition. Para Network Manager Fix Pack 9 y versionesanteriores, este componente debe instalarse por separado y se requiere la versión 8. Para NetworkManager Fix Pack 10 y versiones posteriores, este componente se instala con WebSphereApplication Server y no es necesario seleccionarlo aquí.

• Extensión de Jazz for Service Management para IBM Websphere. Utilice la versión que secorresponde a la versión de IBM Websphere Application Server.

Se evalúan los requisitos previos para instalar el paquete.5. Si se muestran problemas con los requisitos previos, resuélvalos utilizando la información

proporcionada antes de continuar.6. Pulse Siguiente, acepte los términos del acuerdo de licencia y pulse Siguiente de nuevo.7. Seleccione el grupo de paquetes de IBM Websphere Application Server.8. Especifique un directorio de instalación para el grupo de paquetes, por ejemplo, un directorio /was/

bajo el directorio de instalación para los productos de IBM y haga clic en Siguiente.9. Seleccione todas las características de IBM Websphere Application Server que se deben instalar

excepto las Aplicaciones de ejemplo.10. Seleccione la versión de 64 bits de IBM Websphere SDK Java Technology Edition.11. Seleccione la extensión de JazzSM Websphere a instalar y pulse Siguiente.12. Después de instalar los componentes, se le preguntará qué programas que desea iniciar. Seleccione

Ninguno.

Instalación de Dashboard Application Services HubDebe instalar Dashboard Application Services Hub antes de instalar los componentes de GUI de NetworkManager.


https://www.ibm.com/support/knowledgecenter/SSEQTP/mapfiles/product_welcome_was.html



Acerca de esta tareaDashboard Application Services Hub es un componente de Jazz for Service Management.

Antes de instalar cualquier componente de Jazz for Service Management, debe ejecutar IBM PrerequisiteScanner y comprobar los requisitos previos de todos los componentes de Jazz for Service Managementque desea instalar. Consulte “Comprobación de los requisitos del sistema” en la página 21 para obtenermás información.

Nota:

Si no hay ninguna diferencia entre estas instrucciones y la documentación de la versión de loscomponentes de Jazz for Service Management debido a cambios o actualizaciones, la documentación deJazz for Service Management tiene prioridad y se puede encontrar en: https://www.ibm.com/support/knowledgecenter/SSEKCU

Procedimiento1. En el servidor donde desea instalar los componentes de GUI de Network Manager, asegúrese de que

IBM Installation Manager está instalado.2. Inicie IBM Installation Manager:


./IBMIM



instalar, seleccione IBM Dashboard Application Services Hub y pulse Siguiente.Se evalúan los requisitos previos para instalar el paquete.

5. Si se muestran problemas con los requisitos previos, resuélvalos utilizando la informaciónproporcionada antes de continuar.

6. Pulse Siguiente, acepte los términos del acuerdo de licencia y pulse Siguiente de nuevo.7. Seleccione el grupo de paquetes Servicios principales en Jazz for Service Management.8. Especifique un directorio de instalación para el grupo de paquetes, por ejemplo, un directorio /jazz/ bajo el directorio de instalación para los productos de IBM y haga clic en Siguiente.

9. Seleccione la versión de 64 bits de IBM Dashboard Application Services Hub.10. Seleccione todas las características de IBM Dashboard Application Services Hub que se deben

instalar.11. En las siguientes pantallas Instalar paquetes, proporcione información de configuración para los

paquetes que se están instalando. Utilice Siguiente y Atrás para navegar por las opciones deconfiguración.

12. Opcional: Configure detalles para WebSphere Application Server.

Si este es el primer componente que se debe instalar en WebSphere Application Server en esteservidor, debe configurar todos los detalles. Si ya se ha instalado otro componente en WebSphereApplication Server, se utilizan los detalles existentes. Los detalles de que se han configuradoanteriormente se muestran sombreados y debe reconfirmar sólo el nombre de usuario y lacontraseña.

Ubicación de instalación de WebsphereEntre la ubicación donde estaba instalado WebSphere Application Server.





Tipo de despliegue del perfilSeleccione Crear perfil de Websphere. Un perfil es una forma de agrupar aplicaciones enWebSphere Application Server. Si tiene un despliegue de WebSphere Application Server de grantamaño, consulte al administrador para averiguar qué perfil utilizar.

Ubicación del perfilDeje la ubicación predeterminada o entre una nueva ubicación para el perfil. Los caracteressiguiente no se pueden utilizar en la vía de acceso del perfil de WebSphere Application Server.

` ! # $ % ˆ & * + = { } [ ] | ; " < > , ? @ ˜ .

Nombre de perfilEntre un nombre descriptivo exclusivo para el perfil.

Nombre de nodoEntre un nombre descriptivo exclusivo para el nodo.

Nombre de servidorEntre un nombre descriptivo exclusivo para el servidor lógico que se creado en WebSphereApplication Server y se ha asociado con este perfil. Anote esta información; la necesitará cuandoinstale otras aplicaciones en WebSphere Application Server.

Nombre de usuarioDeje el nombre de usuario predeterminado smadmin. Este usuario se creará en WebSphereApplication Server. Anote esta información; la necesitará cuando instale otras aplicaciones enWebSphere Application Server

ContraseñaEspecifique una contraseña para este usuario. Anote esta información; la necesitará cuandoinstale otras aplicaciones en WebSphere Application Server

Confirmar contraseñaConfirme la contraseña.

13. Opcional: Configure los puertos para WebSphere Application Server.

Si este es el primer componente que se debe instalar en WebSphere Application Server, debeconfigurar los puertos. Si ya se ha instalado otro componente en WebSphere Application Server, nose muestra este panel. Deje los valores de puerto en los valores predeterminados a menos que hayaun conflicto con otras aplicaciones.

Puerto de transporte HTTPPuerto utilizado para acceder a WebSphere Application Server.

Importante: Tome nota de este valor. Lo necesitará para acceder a las aplicaciones instaladas enWebSphere Application Server.

Puerto de transporte seguro HTTPSPuerto utilizado para acceder a WebSphere Application Server utilizando HTTPS.

Importante: Tome nota de este valor. Lo necesitará para acceder a las aplicaciones instaladas enWebSphere Application Server si utiliza HTTPS.

Puerto de programa de arranquePuerto utilizado para aplicaciones que se ejecutan fuera del servidor de aplicaciones paraconectarse al bus de mensajes.

Puerto de conector SOAPPuerto utilizado para realizar conexiones de Java Management Extensions (JMX) con el servidorutilizando Simple Object Access Protocol (SOAP).

Puerto de conector IPCPuerto utilizado para realizar conexiones de Java Management Extensions (JMX) con el servidorutilizando las Comunicaciones entre procesos (IPC).

Puerto de consola administrativaPuerto para acceder a la consola administrativa de WebSphere Application Server.


Importante: Tome nota de este valor. Lo necesitará para acceder a la consola administrativa deWebSphere Application Server.

Puerto seguro de consola administrativaPuerto para acceder a la consola administrativa de WebSphere Application Server utilizandoHTTPS.

Puerto de comunicación de High Availability ManagerPuerto utilizado para acceder a High Availability Manager.

Puerto de escucha de ORBPuerto utilizado por el Object Request Broker (Intermediario para solicitudes de objetos).

Puerto de autenticación del servidor SSL de SASPuerto de autenticación Secure Authentication Service (Servicio de autenticación segura).

Puerto de escucha de autenticación del cliente CSIV2Puerto de escucha para el cliente de Common Secure Interoperability Specification, Versión 2(CSIv2).

Puerto de escucha de autenticación del servidor CSIV2Puerto de escucha para el servidor de Common Secure Interoperability Specification, Versión 2(CSIv2).

Puerto de notificación RESTPuerto de notificación de Representational State Transfer (REST) que está asociado con lasaplicaciones instaladas en el perfil WebSphere de Jazz for Service Management.

Para obtener más información sobre puertos específicos, consulte la documentación de la versión deWebSphere Application Server en: https://www.ibm.com/support/knowledgecenter/SSEQTP/mapfiles/product_welcome_was.html

14. Entre un valor para la raíz de contexto para Dashboard Application Services Hub en el campo Raíz decontexto.

Dashboard Application Services Hub es una aplicación alojada en WebSphere Application Server.

La raíz de contexto para Dashboard Application Services Hub define el directorio en el contexto deWebSphere Application Server en el que se ejecuta Dashboard Application Services Hub.

Por ejemplo, si el URL raíz para WebSphere Application Server es http://nombre_host:16310 yestablece una raíz de contexto de /ibm/console/ para Dashboard Application Services Hub, el URLpara acceder a Dashboard Application Services Hub es http://nombre_host:16310/ibm/console/. El URL para acceder a las aplicaciones alojadas en Dashboard Application Services Hub,será http://nombre_host:16310/ibm/console/nombre_aplicación.

15. Pulse Validar para validar los valores de configuración y, a continuación, pulse Siguiente.16. Revise la información de resumen y pulse Instalar.17. Después de instalar los componentes, se le preguntará qué programas que desea iniciar. Seleccione

Ninguno.

Instalación de GUI web de Tivoli Netcool/OMNIbusDebe instalar GUI web antes de instalar los componentes de GUI de Network Manager.

Antes de empezarAntes de instalar GUI web de Tivoli Netcool/OMNIbus, debe instalar WebSphere Application Server y Jazzfor Service Management.

Acerca de esta tareaDebe instalar GUI web en el servidor donde desea instalar los componentes de GUI de Network Manager.

Si hay alguna diferencia entre estas instrucciones y la documentación de la versión de componentes deGUI web de Tivoli Netcool/OMNIbus debido a cambios o actualizaciones, la documentación de GUI web




de Tivoli Netcool/OMNIbus tiene prioridad y se puede encontrar en: http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.



./IBMIM


2. Pulse Instalar.3. En la siguiente pantalla Instalar paquetes donde puede seleccionar los paquetes a instalar,

seleccione GUI web de IBM Tivoli Netcool/OMNIbus y pulse Siguiente.Se evalúan los requisitos previos para instalar el paquete.


5. Pulse Siguiente, acepte los términos del acuerdo de licencia y pulse Siguiente de nuevo.6. Seleccione el grupo de paquetes de IBM Netcool.7. Especifique un directorio de instalación para el grupo de paquetes, por ejemplo, un directorio /gui/

bajo el directorio de instalación para los productos de IBM y haga clic en Siguiente.8. Seleccione Instalar las características básicas, otras características que son necesarias para las

integraciones de productos que tenga.9. En las siguientes pantallas Instalar paquetes, proporcione información de configuración para los


10. Configure propiedades para WebSphere Application Server y Jazz for Service Management.Directorio de instalación de WebSphere Application Server

Entre el directorio donde está instalado WebSphere Application Server.INTERFAZ DE USUARIO DE Jazz for Service Management

Entre el directorio donde está instalado Dashboard Application Services Hub.Nombre de servidor

Entre el nombre del servidor lógico que se ha creado en WebSphere Application Server.Nombre de usuario

Entre el nombre de usuario que está configurado para acceder a este servidor lógico.Contraseña

Entre la contraseña para este usuario.11. Revise la información de resumen y pulse Instalar.

Instalación de los componentes de la GUI de Network ManagerInstale los componentes de la GUI de Network Manager solo después de instalar los componentesprincipales. Instale los componentes de la GUI en el servidor que tiene Jazz for Service Management yainstalado.

Acerca de esta tareaPara instalar los componentes de la GUI de Network Manager, realice las tareas siguientes:







./IBMIM


2. Pulse Instalar.3. En la siguiente pantalla Instalar paquetes, donde puede seleccionar los paquetes a instalar,

seleccione la última versión disponible de los Componentes de la GUI de Network Manager.Se evalúan los requisitos previos para instalar el paquete.


5. Pulse Siguiente, acepte los términos del acuerdo de licencia y pulse Siguiente de nuevo.6. Seleccione el grupo de paquetes de IBM Netcool GUI Server y pulse Siguiente.

Restricción: Debe instalar los componentes de la GUI del mismo grupo de paquetes que GUI web deTivoli Netcool/OMNIbus.

7. Seleccione los Archivos de producto que se deben instalar y pulse Siguiente.8. En las siguientes pantallas Instalar paquetes, proporcione información de configuración para los


9. Confirme las propiedades de la instancia de Jazz for Service Management en la que desea instalar.Detalles de directorio de instalación

Vía de acceso completa a la instancia de Dashboard Application Services Hub.Nombre de usuario

Entre el nombre de usuario para un usuario con permisos administrativos en DashboardApplication Services Hub. Si no se ha modificado, puede utilizar el usuario predeterminadosmadmin con la contraseña netcool.

10. Network Manager se conecta a un ObjectServer existente. El ObjectServer ya debe existir y debeestar en ejecución y ser accesible desde este servidor. Especifique los detalles del ObjectServer alque Network Manager se debe conectar. Estos detalles deben coincidir con los detalles entrados alinstalar los componentes principales.Nombre

Entre el nombre de ObjectServer.Host

Entre el nombre de host del servidor donde está instalado Tivoli Netcool/OMNIbus.Puerto

Entre un puerto a utilizar para la conexión con el ObjectServer o acepte el valor predeterminado.ID de superusuario

Entre el nombre de un usuario con los permisos administrativos para Tivoli Netcool/OMNIbus.Contraseña


Seleccione Omitir la verificación y configuración de detalles de conexión de ObjectServer si seaplica alguna de las condiciones siguientes:



• Tivoli Netcool/OMNIbus WebGUI ya se ha configurado con un origen de datos y un origen deautenticación. Si configura detalles diferentes, la instalación sobrescribe la configuración existente.

• No ha podido verificar los detalles en este momento, por ejemplo, si ObjectServer no estáaccesible. Si omite este proceso, debe realizar los cambios posteriormente de forma manual.

Jazz for Service Management se ha configurado para utilizar este ObjectServer para autenticación.11. Configure los usuarios predeterminados de Network Manager. Los usuarios itnmadmin y itnmuser

los crea el instalador en ObjectServer. Se utiliza la misma contraseña para todos los usuarios. Si yaexisten uno o varios de estos usuarios, la contraseña no cambia.Contraseña

Especifique una contraseña para estos usuarios. Anote la contraseña.Confirmar contraseña

Confirme la contraseña.12. Entre los detalles de la base de datos de topología que se ha instalado. Estos detalles deben coincidir

con los detalles entrados al instalar los componentes principales.a) Seleccione el tipo de base de datos.b) Entre los detalles de conexión de base de datos:








Escriba el nombre de servicio de la base de datos.Host de servidor

Entre el nombre de host del servidor en el que está instalada la base de datos.ID de usuario

Entre el ID de un usuario de Oracle existente que tenga permisos para acceder a las tablasNCIM. El ID de usuario predeterminado es ncim.


c) Seleccione Crear tablas para mantener los datos de topología en la base de datos creada paracrear las tablas de base de datos que son necesarias para Network Manager. Si ya ha creado lastablas de base de datos utilizando los scripts de creación de base de datos, no es necesarioseleccionar esta opción. Si ya ha creado las tablas y selecciona la opción para crearlas de nuevo,recibirá un error al final de la instalación. Este error indica que las tablas no se han creado.

d) Seleccione Omitir verificación d detalles de conexión de base de datos si no desea verificar laconexión, si la base de datos es inaccesible o por otras razones.

13. Revise la información de resumen y pulse Instalar.


ResultadosLos componentes de la GUI de Network Manager se han instalado. Los errores se graban en el archivo deregistro de instalación, que puede ver pulsando Ver archivo de registro. Los archivos de registro semantienen en el directorio /logs/ en la ubicación de datos de IBM Installation Manager.

Instalación y configuración de Cognos AnalyticsA partir de Network Manager Fix Pack 11, Tivoli Common Reporting no es compatible. Para utilizarinformes, debe instalar y configurar Cognos Analytics.

Acerca de esta tareaLa documentación para su versión de Cognos Analytics contiene la información más actualizada ycompleta sobre la configuración de producto. Si hay alguna diferencia entre la siguiente información y ladocumentación de Cognos Analytics, esta última tiene preferencia. Consulte la información de en https://www.ibm.com/support/knowledgecenter/SSEP7J

Realice las siguientes tareas para configurar Cognos Analytics.

Procedimiento1. Descargue el último fixpack disponible para Cognos Analytics V11.2. Instale Cognos Analytics.

Utilice los requisitos previos y pasos de instalación detallados en la documentación sobre CognosAnalytics.a) Instale como usuario root.b) Cuando se le solicite instalar algún componente, seleccione los servicios de aplicación y de

pasarela opcional.3. Establezca la variable de entorno COGNOS_HOME en el directorio donde ha instalado Cognos

Analytics.La vía de acceso debe terminar en análisis.

4. Si utiliza Db2 como base de datos de topología, copie los siguientes archivos desde el servidor debases de datos Db2 en el servidor de Informes Cognos.

• Copie $Db2_HOME/sqllib/java/db2jcc.jar en $COGNOS_HOME/webapps/p2pd/WEB-INF/lib/.

• Copie $Db2_HOME/sqllib/java/db2jcc_license_cu.jar en $COGNOS_HOME/webapps/p2pd/WEB-INF/lib/.

• Copie $Db2_HOME/sqllib/java/db2jcc.jar en $COGNOS_HOME/drivers/.5. Configure los orígenes de datos para elaborar informes.

a) Inicie IBM Cognos Configuration con el mandato correspondiente.Por ejemplo: $COGNOS_HOME/bin64/cogconfig.sh

b) Seleccione Acceso a datos > Gestor de contenidos > Almacén de contenido. Especifique losdetalles de la base de datos NCIM.

c) Pulse Acciones > Iniciar para iniciar el servidor Cognos.El servidor puede tardar algún tiempo en iniciarse.

d) Inicie la sesión en la GUI de Cognos Analytics.De forma predeterminada, el URL de inicio de sesión es http://host:9300/bi.

e) Pulse Gestionar > Administración de la consola para iniciar la consola de administración.f) Pulse Configuración > Conexión de origen de datos > Origen de datos nuevo para añadir las

conexiones de base de datos.

Añada las siguientes conexiones:




Tabla 7. Conexiones de base de datos

Producto Nombre Tipo Parámetros de conexiónJDBC

ITNM IBM_TRAM IBM Db2 currentSchema=NCIM;

NCIM currentSchema=NCIM;

NCMONITOR currentSchema=NCMONITOR;

NCPGUI currentSchema=NCPGUI;

NCPOLLDATA currentSchema=NCPOLLDATA;

PARAMETERS currentSchema=NCPOLLDATA;

g) Pruebe las conexiones pulsando el botón Probar en la barra de herramientas.h) Si recibe un error relacionado con libdb2.so, añada el directorio que contenga la versión de 32

bits de esta biblioteca a su LD_LIBRARY_PATH.i) Detenga el servidor Cognos desde la GUI de IBM Cognos Configuration haciendo clic en Acciones

> Detener.j) Reinicie la interfaz gráfica de usuario de IBM Cognos Configuration.

k) Reinicie el servidor Cognos pulsando Acciones > Iniciar.6. Instale informes de Network Manager mediante IBM Installation Manager.7. Importe informes de Network Manager .

a) Copie los informes de Network Manager desde $ITNM_HOME/precision_gui/reports/itnmcognos.zip en el directorio $COGNOS_HOME/deployment del servidor Cognos.

b) Importe los informes pulsando Configuración > Administración de contenidos > Nuevaimportación y seleccionando el paquete ITNM Reports.

8. Configure Cognos Analytics para que utilice HTTPS.9. Configure Cognos Analytics para utilizar la autenticación LDAP.

Si lo hace, para mantener todas las cuentas de usuario en un lugar, configure Tivoli Netcool/OMNIbuspara utilizar la autenticación LDAP. Consulte la información sobre Configuración de autenticación deusuario en la documentación de Tivoli Netcool/OMNIbus. Por ejemplo, consulte el temaConfiguración de autenticación de usuario en el IBM Knowledge Center para Tivoli Netcool/OMNIbushttp://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

10. Edite el archivo $NMGUI_HOME/profile/etc/tnm/reporting.properties. Siga lasinstrucciones en la parte superior del archivo para editar las propiedades siguientes:

reporting.useCognos=truereporting.host=hostnamereporting.ui.path=/bireporting.path=/bi/v1/disp

11. Añada el rol de usuario ncp_reporting_user al grupo de usuarios de Network Managercorrespondiente.La opción de menú Informes Cognos se muestra solo a los usuarios que tienen este rol.

12. Reinicie los componentes de GUI de Network Manager.13. Inicie sesión en la GUI de Cognos Analytics como un usuario con los permisos adecuados y ejecute

un informe de Network Manager en Contenido de equipo > Gestor de red.



ResultadosLos informes están disponibles para ejecutar en el menú Informes > Informes Cognos.Tareas relacionadasConfiguración de Cognos AnalyticsRealice estas tareas para configurar Cognos Analytics.

Instalación de informes de Network ManagerAntes de instalar los informes específicos de Network Manager, debe tener instalado Cognos Analytics.

Acerca de esta tareaPara instalar los informes de Network Manager, realice las tareas siguientes en el servidor en que hainstalado Cognos Analytics.



./IBMIM


2. Pulse Instalar.3. En la siguiente pantalla Instalar paquetes donde puede seleccionar los paquetes que desea instalar,

seleccione la última versión disponible de Network Manager Reports. El paquete de informes deNetwork Manager instala informes específicos para Network Manager.Se evalúan los requisitos previos para instalar el paquete.


5. Pulse Siguiente, acepte los términos del acuerdo de licencia y pulse Siguiente de nuevo.6. Seleccione el grupo de paquetes de IBM Netcool.7. Seleccione la versión de 64 bits y pulse Siguiente.8. Seleccione todas las características de los paquetes de informes de Network Manager que se deben

instalar.9. En las siguientes pantallas Instalar paquetes, proporcione información de configuración para los


10. Confirme las propiedades de la instancia de Jazz for Service Management en la que desea instalar.Detalles de directorio de instalación

Vía de acceso completa a la instancia de Dashboard Application Services Hub.Nombre de usuario

Entre el nombre de usuario para un usuario con permisos administrativos en Jazz for ServiceManagement. Si no se ha modificado, puede utilizar el usuario predeterminado smadmin con lacontraseña netcool.




11. Confirme los detalles de la base de datos de topología de Network Manager que se ha instalado. Losinformes recuperan datos de esta base de datos.a) Seleccione el tipo de base de datos.b) Entre los detalles de conexión de base de datos:








Escriba el nombre de servicio de la base de datos.Host de servidor

Entre el nombre de host del servidor en el que está instalada la base de datos.ID de usuario


Entre la contraseña para este usuario.c) Seleccione Omitir verificación de detalles de conexión de base de datos si no desea verificar la

conexión en este momento, por ejemplo, si la base de datos está actualmente inaccesible.12. Revise la información de resumen y pulse Instalar.

Qué hacer a continuaciónDespués de instalar los informes de Network Manager, deberá realizar las tareas de configuraciónsiguientes antes de utilizar los informes.

1. Configurar el nivel de aislamiento para orígenes de datos de Network Manager (pasosobligatorios).

Cambie el nivel de aislamiento a Read uncommitted para todos los orígenes de datos de NetworkManager NCPOLLDATA, PARAMETERS, NCPGUI, NCOMONITOR, NCIM, IBM_TRAM. Los pasos deconfiguración de orígenes de datos siguientes son obligatorios para evitar problemas de punto muertode base de datos. Realice los siguientes pasos.

a. Abra Dashboard Application Services Hub, especificando un URL similar a https://itnm7.hursley.ibm.com:16311/ibm/console/logon.jsp.

b. Inicie sesión en Dashboard Application Services Hub as como el usuario smadmin.c. Haga clic en el icono Informes y seleccione Informe de Cognos. Dentro del widget, seleccione

Administrar > consola de administración.d. En el separador Configuración, seleccione un origen de datos.e. Abra Propiedades.f. En el separador Conexión, cambie el nivel de aislamiento a Lectura no confirmada.

2. Ampliar la visibilidad de la función de informes al usuario itnmadmin.

Después de completar la instalación, debe iniciar la sesión como smadmin para ver la función deinformes; si inicia la sesión como itnmadmin no puede ver la función de informes. Para obtener


información acerca de cómo ampliar la visibilidad de la función de informes para el usuarioitnmadmin, consulte http://www-01.ibm.com/support/docview.wss?uid=swg21963430.

Instalación del Panel de instrumentos de estado de red (sóloclientes de Netcool Operations Insight)

Si tiene titularidad para Network Manager como parte de Netcool Operations Insight, puede instalar elpanel de instrumentos adicional para Network Manager conocido como el Panel de instrumentos deestado de red.

Acerca de esta tareaEl Panel de instrumentos de estado de red supervisa una vista de red seleccionada y visualiza ladisponibilidad de dispositivo e interfaz dentro de esa vista de red. También informa sobre el rendimientopresentando gráficos, tablas y rastreos de datos KPI para dispositivos supervisados e interfaces. Unalínea temporal de panel de instrumentos informa sobre los cambios de configuración de dispositivo y losrecuentos de sucesos, permitiéndole correlacionar sucesos con cambios de configuración. El panel deinstrumentos incluye el visor de sucesos, para obtener información de sucesos más detallada.

Consulte la información sobre cómo instalar el Panel de instrumentos de estado de red en ladocumentación de Netcool Operations Insight en: http://www.ibm.com/support/knowledgecenter/SSTPTP/welcome.

Al instalar el Panel de instrumentos de estado de red, se instalan los roles siguientes, que permiten alos usuarios trabajar con el Panel de instrumentos de estado de red:

• ncp_networkhealth_dashboard• ncp_networkhealth_dashboard_admin• ncp_event_analytics

Instalación y desinstalación de fixpacksUn fixpack implica mover de un release menor a otro dentro de una versión de punto, por ejemplo, de4.2.0.1 a 4.2.0.2. Estas versiones se denominan V4.2 fixpack 1 y V4.2 fixpack 2. Puede instalar losfixpacks yretrotraer a una versión anterior, utilizando IBM Installation Manager.

Acerca de esta tareaDebe instalar la versión GA de Network Manager antes de instalar un fixpack.

Tareas posteriores a la instalaciónDespués de instalar Network Manager, tendrá que realizar algunas tareas posteriores a la instalación.

Acerca de esta tareaPara realizar las tareas posteriores a la instalación:

Procedimiento1. Asegúrese de que la instalación de Network Manager se ha completado.

Puede comprobar que la instalación ha sido satisfactoria visualizando los paquetes que IBMInstallation Manager ha instalado correctamente utilizando los siguientes mandatos:a) En IBM Installation Manager pulse Archivo > Historial de instalación.b) Revise el estado de los paquetes instalados.

La columna Nombre de grupo de paquetes lista los paquetes instalados y la columna Estado listalos resultados de la instalación de dicho paquete.



http://www.ibm.com/support/knowledgecenter/SSTPTP/welcome

http://www.ibm.com/support/knowledgecenter/SSTPTP/welcome

c) Pulse Ver registro para ver el archivo de registro para cualquier paquete seleccionado.2. Si se está integrando con Netcool Configuration Manager, ahora debe instalarlo y luego instalar el

Netcool Configuration Manager Integration Pack. Para obtener instrucciones sobre la instalación deestos componentes, consulte la documentación de integración en: http://www.ibm.com/support/knowledgecenter/SS7UH9/welcome

3. En función de los valores adicionales necesarios, complete los pasos en los siguientes temas:Opción Descripción

Configuración deLDAP para laautenticación deusuarios

Después de una instalación satisfactoria de Network Manager, puedeconfigurar LDAP para la autenticación de usuario, como se describe en“Cambio del método de autenticación de usuario” en la página 223.

Configuración delnombre de origen dedatos de GUI web deTivoli Netcool/OMNIbus

Si ha instalado los componentes de GUI de Network Manager y ha elegidono crear un nuevo origen de datos de GUI web, debe configurar NetworkManager para que utilice un origen de datos existente. Consulte lasinstrucciones en “Configuración del nombre de origen de datos de GUI webde Tivoli Netcool/OMNIbus” en la página 92.

Tareas posteriores ala instalación no root(sólo UNIX)

• Puede configurar qué usuario gestiona los procesos de Network Manager,como se describe en “Configuración de permisos root/no root” en lapágina 159

• Para las instalaciones no root, puede configurar los procesos de NetworkManager para que se inicien automáticamente cuando se inicie o sereinicie el sistema, como se describe en “Configuración del inicioautomático de procesos en una instalación no root” en la página 161.

Nota: No es necesario que realice estos pasos si ha instalado NetworkManager como usuario root. El reinicio automático se configura comoparte de la instalación root sin necesidad de este paso posterior a lainstalación.

Configuración de unabase de datos detopología después dela instalación paraNetwork Manager.

Para obtener detalles sobre cómo crear los esquemas de base de datosmanualmente después de la instalación, consulte las tareas acerca de lacreación de esquemas de base de datos de topología en el IBM TivoliNetwork Manager IP Edition Administration Guide.

Habilitación de laagregación de datosde sondeo si hainstalado NetworkManager como root

Si ha instalado Network Manager como usuario root, debe ejecutar el scriptsetup_run_storm_as_non_root.sh para habilitar los procesos dedatos de sondeo históricos. Para obtener detalles sobre cómo hacer esto,consulte “Habilitación del sondeo histórico” en la página 163.

Actualización a partirde una versiónanterior de NetworkManager

Siga los pasos en Capítulo 8, “Actualización y migración”, en la página 137.

Instalación del agentede supervisión

Si desea utilizar IBM Tivoli Monitoring for IBM Tivoli Network Manager IPEdition, siga los pasos de “Integración con IBM Tivoli Monitoring” en lapágina 127

Configuración deNetwork Managerpara diferentes husoshorarios.

Si está instalando componentes principales de Network Managerdistribuidos y servidores de aplicaciones web en diferentes zonas horarias,debe establecer la misma zona horaria en todos los servidores, lo queincluye tanto el servidor de base de datos como los servidores principales ylos servidores de la GUI. Esto garantiza que Network Manager pueda


http://www.ibm.com/support/knowledgecenter/SS7UH9/welcome


Opción Descripción

realizar comparaciones de indicación de fecha y hora precisas en losprocesos de los distintos servidores. También debe avisar a los usuariosfinales, tales como operadores de red, que es posible que el sistemamuestre horas distintas a la hora de sus ubicaciones.

Configuración derutinas criptográficasadicionales para laGUI

De forma predeterminada, la GUI no utiliza ninguna rutina criptográfica queesté excluida de una instalación de FIPS140-2, independientemente delestado de instalación del servidor central. Si desea configurar opciones dedescubrimiento SNMP para habilitar MD5 y DES, establezcatnm.fips.mode=false en el archivo tnm.properties.

Configuración delmantenimientoautomático de la vistade red

Si tiene varios servidores GUI, debe configurarlos de modo que solo unservidor realice el mantenimiento automático de la vista de red y de la vistade ruta. Si tiene solo un servidor GUI, no necesita realizar esta tarea. Paraobtener más información, consulte Configuración del mantenimientoautomático de la vista en el Guía del usuario de IBM Tivoli Network Manager.

4. En función de sus necesidades, puede que necesite realizar tareas de configuración adicionales.Consulte la información de Capítulo 9, “Configuración de Network Manager”, en la página 157.

5. Después de instalar y configurar correctamente Network Manager, consulte las secciones de iniciaciónPara obtener más información, consulte las tareas en Guía del usuario de IBM Tivoli Network Manager.


Capítulo 5. Desinstalación de Network ManagerSi desea eliminar por completo el producto o retrotraer a una versión anterior, debe utilizar IBMInstallation Manager. Al desinstalar el producto eliminando los archivos y los directorios se producenproblemas cuando se vuelven a instalar los componentes.

Acerca de esta tareaDebe desinstalar los productos y componentes en el orden que se especifica aquí. IBM InstallationManager No elimina los archivos que se han creado ejecutando los productos o mandatos deconfiguración, que incluyen registros, archivos de configuración actualizados, datos persistentes omemoria caché.

Si desinstala componentes en un orden diferente, es posible que no pueda eliminar algunoscomponentes.

Tareas relacionadasEliminación de informesAntes de desinstalar Network Manager, debe eliminar los informes de Network Manager y los orígenes dedatos para los informes. También puede desinstalar Cognos Analytics al mismo tiempo.

Desinstalación de las aplicaciones de GUIPuede desinstalar uno o todos los productos siguientes al mismo tiempo: Componentes de la GUI deNetwork Manager, GUI web de Tivoli Netcool/OMNIbus y Dashboard Application Services Hub.

Antes de empezarEl usuario itnm_user debe estar presente en el ObjectServer. El ObjectServer debe estar ejecutándose.No desinstale WebSphere Application Server hasta que se hayan desinstalado todos los productosinstalados en WebSphere Application Server.

Acerca de esta tareaPara desinstalar las aplicaciones de GUI, complete los siguientes pasos:



./IBMIM


2. Pulse Desinstalar.3. Seleccione uno o varios de los componentes siguientes a desinstalar y pulse Siguiente:

• GUI web de IBM Tivoli Netcool/OMNIbus• Componentes de GUI de Network Manager• IBM Dashboard Application Services Hub. No puede desinstalar Dashboard Application Services

Hub a menos que desinstale primero todos los componentes que están instalados en el mismo.



4. Se le solicitarán los detalles de WebSphere Application Server y Jazz for Service Management. Si estosdetalles no han cambiado desde la instalación, puede dejar los valores predeterminados.

5. Revise la información de resumen y pulse Desinstalar.

ResultadosLos paquetes seleccionados se desinstalan.

Eliminación de informesAntes de desinstalar Network Manager, debe eliminar los informes de Network Manager y los orígenes dedatos para los informes. También puede desinstalar Cognos Analytics al mismo tiempo.

Acerca de esta tareaRestricción: Si elimina Cognos Analytics, los informes de Network Manager no funcionarán. Si deseautilizar los informes de Network Manager, no desinstale Cognos Analytics.

Para eliminar los informes de Network Manager y los valores de origen de datos, realice las tareassiguientes:

Procedimiento1. Inicie una sesión en la GUI de Network Manager en un navegador soportado como un usuario con

permisos de administrador.2. Haga clic en Common reporting en el panel de navegación de la izquierda de la ventana.3. Marque el recuadro de selección situado junto a Network Manager.4. Haga clic en el icono de supresión para eliminar los informes de Network Manager.5. Haga clic en el menú Lanzar en la parte superior derecha del menú. Haga clic en Administración de

Cognos en la lista y haga clic en el separador Configuración.6. Seleccione los recuadros de selección junto a los siguientes orígenes de datos:

• IBM_TRAM• NCIM• NCMONITOR• NCPGUI• NCPOLLDATA• PARAMETERS

7. Haga clic en el icono de supresión para eliminar los orígenes de datos seleccionados.8. Inicie IBM Installation Manager:


./IBMIM


9. Pulse Desinstalar.10. Seleccione Informes de Network Manager y Cognos Analytics y pulse Siguiente.11. Revise la información de resumen y pulse Desinstalar.




Desinstalación de los componentes principales de NetworkManager y Tivoli Netcool/OMNIbus

Puede desinstalar los componentes principales de Network Manager y Tivoli Netcool/OMNIbus al mismotiempo, si están instalados en el mismo servidor.

Antes de empezarAntes de desinstalar Network Manager, elimine los informes de Network Manager y Cognos Analytics,como se describe en “Eliminación de informes” en la página 80.

Acerca de esta tareaPara desinstalar Network Manager y Tivoli Netcool/OMNIbus, realice los siguientes pasos:

Procedimiento1. Opcional: Si ha instalado como usuario no root y luego ha ejecutado create_all_control.sh -auto_only como una tarea posterior a la instalación para configurar sus procesos de NetworkManager para que se arranquen automáticamente al iniciar o reiniciar el sistema, ejecutecreate_all_control.sh con la opción -deinstall como el usuario de instalación para eliminardel sistema los scripts de arranque.

2. Detenga los componentes principales de Network Manager para cada dominio utilizando el mandatosiguiente: itnm_stop ncp -domain DOMINIO.Por ejemplo, para detener el dominio NCOMS, escriba: itnm_stop ncp -domain NCOMS

Nota: Si no especifica un nombre de dominio con el mandato itnm_stop, éste detiene el dominiopredeterminado creado durante la instalación.

Asegúrese de que todos los procesos que comienzan con ncp_ se han detenido antes de continuar.Detenga los procesos de Network Manager restantes si es necesario.

3. Inicie IBM Installation Manager:a) Cambie al directorio en el que se ha instalado IBM Installation Manager.b) Ejecute el siguiente mandato:

./IBMIM


4. Pulse Desinstalar.5. Seleccione uno o varios de los componentes siguientes a desinstalar y pulse Siguiente:

• IBM Tivoli Netcool/OMNIbus• Componentes principales de Network Manager

6. Revise la información de resumen y pulse Desinstalar.


Capítulo 5. Desinstalación de Network Manager 81


Qué hacer a continuaciónSi ha instalado como un usuario no root, es posible que algunos archivos y directorios aún esténpresentes. Un usuario con los permisos adecuados puede eliminar estos archivos de forma manual. Noelimine los archivos si Tivoli Netcool/OMNIbus o Probes están instalados en la misma ubicación.

Desinstalación de WebSphere Application ServerDespués de desinstalar los productos que se han instalado en WebSphere Application Server, puededesinstalar WebSphere Application Server.

Acerca de esta tareaPara desinstalar WebSphere Application Server, siga los siguientes pasos:

Procedimiento1. Elimine el perfil de WebSphere Application Server creado por Jazz for Service Management:

a) Detenga el perfil de WebSphere Application Server utilizando el mandato siguiente:

stopServer.sh server_name -username smadin -password password

b) Liste los perfiles para obtener el nombre del perfil, utilizando el mandato siguiente:/opt/IBM/netcool/was/bin/manageprofiles.sh -listProfiles

c) Suprima el perfil utilizando el mandato siguiente:/opt/IBM/netcool/was/bin/manageprofiles.sh -delete -profileNamenombre_perfil

2. Inicie IBM Installation Manager:a) Cambie al directorio en el que se ha instalado IBM Installation Manager.b) Ejecute el siguiente mandato:

./IBMIM


3. Pulse Desinstalar.4. Seleccione WebSphere Application Server y todos los subcomponentes y pulse Siguiente.5. Revise la información de resumen y pulse Desinstalar.



Capítulo 6. Instalación y desinstalación de fixpacksUn fixpack implica mover de un release menor a otro dentro de una versión de punto, por ejemplo, de4.2.0.1 a 4.2.0.2. Estas versiones se denominan V4.2 fixpack 1 y V4.2 fixpack 2. Puede instalar losfixpacks yretrotraer a una versión anterior, utilizando IBM Installation Manager.

Acerca de esta tareaDebe instalar la versión GA de Network Manager antes de instalar un fixpack.

Instalación de fixpacksUn fixpack implica mover de un release menor a otro dentro de una versión de punto, por ejemplo, de4.2.0.1 a 4.2.0.2, o V4.2 Fixpack 1 y V4.2 Fixpack 2.

Antes de empezarDebe instalar la versión GA de Network Manager antes de instalar un fixpack.

Antes de instalar un fixpack, debe hacer una copia de seguridad de los productos y los datos, segúncorresponda. Por ejemplo, si ejecuta Network Manager en una máquina virtual, realice una instantánea dela máquina virtual.

Acerca de esta tareaRestricción: No está permitido usar diferentes versiones de los mismos productos o componentes juntos,a menos que se indique lo contrario en las instrucciones en IBM Knowledge Center o en el Soporte deIBM. Si necesita varias instancias de un producto o componente, debe instalarlas o actualizarlas a lamisma versión y fixpack. También es necesario comprobar que se instale el mismo conjunto decorrecciones de prueba, si las hubiera. Por ejemplo, si necesita varias instancias de los Componentes deGUI Network Manager en una implementación, asegúrese de que sean la misma versión, fixpack ycorrecciones de prueba.

Debe actualizar los componentes principales de Network Manager antes o al mismo tiempo que laactualización de los componentes de GUI. Por ejemplo, instale el fixpack en el servidor principal deNetwork Manager y después en el servidor de la GUI.

Importante: La instalación del Fixpack 6 o una versión posterior elimina los archivos MIB existentes.Network ManagerEstos Fix Packs no contienen la Base de datos de información de administración(archivos MIB). Network Manager Fix Pack 5 sí contiene los archivos MIB. Los MIB son necesarios para ladetección de redes.

Si está actualizando desde el Fix Pack 5 o anterior, complete los siguientes pasos para obtener losarchivos MIB:

1. Localice un archivo zip llamado com.ibm.tivoli.netcool.ncp.mibs.all.any_*.zip dentro dela ubicación compartida de IBM Installation Manager que contiene los archivos MIB de la instalacióndel Fix Pack anterior. La ruta exacta puede ser distinta en su instalación. Una ruta de ejemploes: /opt/IBM/IBMIM/native/

2. Descomprima este archivo.3. Cargue las MIB en la base de datos ejecutando el mandato ncp_mib, como se describe en Carga de

información actualizada de MIB en IBM Tivoli Network Manager IP Edition: Guía de instalación yconfiguración.

Si está instalando Fix Pack 6, 7, 8 o 9 sin actualizar, o no puede localizar los archivos MIB utilizando elprocedimiento anterior, complete los siguientes pasos para obtener los archivos MIB:


1. Ejecute el comando ncp_mib, como se describe en: Cargando información actualizada de MIB en elIBM Tivoli Network Manager IP Edition: Guía de instalación y configuración.

2. Si tiene instalado Network Manager 4.2 Fix Pack 5, realice una copia de seguridad del contenido deldirectorio $NCHOME/precision/mibs/ en un directorio de copia de seguridad fuera de $NCHOME.Por ejemplo, /mibs_backup/.

3. Si tiene instalada una versión anterior a la 4.2 de Fix Pack 5, realice los pasos siguientes:

a. Realice una copia de seguridad del contenido del directorio $NCHOME/precision/mibs/ en undirectorio de copia de seguridad fuera de $NCHOME. Por ejemplo, /old_mibs/. Conserve estedirectorio y sus archivos en caso de que desee volver a esta versión más adelante.

b. Descargue los archivos de Network Manager Fix Pack 5 (4.2.0.5) desde IBM Fix Central: https://www.ibm.com/support/fixcentral/

Importante: Descargue los archivos para Linux x86, independientemente de la plataforma queesté utilizando.

c. Expanda el paquete de Network Manager en un directorio temporal.d. Expanda el archivo repositories/disk1/ad/native/file000876 en un directorio de copia

de seguridad fuera de $NCHOME, por ejemplo, /mibs_backup/. Este directorio contiene ahora losarchivos MIB predeterminados.

e. Si ha personalizado o agregado archivos MIB, copie los archivos MIB personalizados o nuevos de /old_mibs/ sobre los archivos predeterminados en /mibs_backup/.

4. Independientemente de la versión de Network Manager que haya instalado, el directorio /mibs_backup/ contiene ahora el conjunto más actual de archivos MIB de Fix Pack 5, además de lasadiciones y personalizaciones.

Después de obtener los archivos MIB, instale la versión más reciente de Network Manager.

1. Instale Network Manager Fix Pack 6 con las instrucciones de este procedimiento.2. Copie los archivos MIB del directorio /mibs_backup/ a la siguiente ubicación dentro de la

instalación: $NCHOME/precision/mibs/3. Ejecute el comando ncp_mib, como se describe en: Cargando información actualizada de MIB en el

IBM Tivoli Network Manager IP Edition: Guía de instalación y configuración.

Para instalar un fixpack, realice los siguientes pasos:

Procedimiento1. Instale el fixpack en todos los servidores de Network Manager; por ejemplo, en el núcleo y en el

servidor GUI, a menos que se indique otra cosa en el fixpack Notas del release o el archivo README.2. Detenga los procesos Network Manager que se están ejecutando.3. Inicie IBM Installation Manager:


./IBMIM

: Si las versiones de software actuales están formadas por un Network Manager versión 4.2 anterioral Fix Pack 1 con Jazz for Service Management V1.1.2.1 y está actualizando a Network Manager 4.2Fix Pack 1 y Jazz for Service Management V1.1.3.0 al mismo tiempo, debe iniciar IBM InstallationManager al ejecutar el script JazzSMgrpModeUpgrade.sh y especificar dos parámetrosobligatorios, como se describe en la nota técnica en https://www.ibm.com/support/pages/node/283105.

No es necesario iniciar IBM Installation Manager ejecutando el scriptJazzSMgrpModeUpgrade.sh si su versión de software actual es un Network Manager versión 4.2






anterior al Fixpack 1 con Jazz for Service Management V1.1.3.0 y sólo está actualizando a 4.2Fixpack 1 sin cambiar la versión de Jazz for Service Management.


4.Configure los repositorios de IBM Installation Manager para que apunten a las ubicaciones de lospaquetes actualizados.

5. Pulse Actualizar.6. Seleccione el grupo de paquetes para el que desee instalar un fixpack. De forma alternativa,

seleccione Actualizar todos los paquetes con actualizaciones recomendadas y arreglosrecomendados. Haga clic en Siguiente.

7. Seleccione las actualizaciones que desea instalar y pulse Siguiente.8. Revise la información de resumen y pulse Actualizar.9. Después de una actualización de Fix Pack con una instalación sin privilegios, debe ejecutar las

siguientes secuencias de comandos como usuario root para habilitar los procesos centrales querequieren acceso root para funcionar con normalidad:

• $NCHOME/precision/scripts/setup_run_as_setuid_root.sh• $NCHOME/precision/scripts/setup_run_storm_as_non_root.sh

Aplicación de actualizaciones de esquema para un fixpackEjecute el script de actualizador de esquema, update_db_schemas.pl, para aplicar todas lasactualizaciones de esquema de base de datos de topología NCIM necesarias para uno o varios fixpacks oarreglos temporales.

Antes de empezarPara poder ejecutar el script update_db_schemas.pl, primero debe haber instalado el fixpack o elarreglo temporal para el que desea aplicar las actualizaciones de esquema.

Acerca de esta tareaA partir de Network Manager V4.2, cuando descarga un nuevo fixpack o arreglo temporal, la descargaincluye update_db_schemas.pl y los archivos de actualización asociados. Estos archivos deactualización incluyen todos los cambios de esquema de base de datos de topología NCIM para todos losfixpacks y arreglos temporales hasta el arreglo actual.

Para actualizar su base de datos de topología NCIM con todos los cambios de esquema para el fixpack oarreglo temporal actual, ejecute el script update_db_schemas.pl. El script también aplicará loscambios de esquema para varios fixpacks o arreglos temporales. Por ejemplo, si para un determinadorelease principal no ha instalado el fixpack 1 y ahora está instalando el fixpack 2, la ejecución del scriptupdate_db_schemas.pl actualizará la base de datos de topología NCIM con todos los cambios deesquema para el fixpack 1 y el fixpack 2.

Para obtener más información sobre el script update_db_schemas.pl, consulte IBM Tivoli NetworkManager IP Edition Administration Guide.

Procedimiento1. Obtenga su entorno.

En el servidor en el que se han instalado los componentes principales de Network Manager, el scriptde entorno es directorio_instalación/netcool/core/env.sh.

Capítulo 6. Instalación y desinstalación de fixpacks 85


Por ejemplo, en los shells Bash, Bourne y Korn, obtenga el script env.sh mediante un mandato similaral siguiente:

. /opt/IBM/netcool/core/env.sh

2. Ejecute el script en modalidad de vista previa para listar las actualizaciones de esquema que seaplicarán.

$NCHOME/precision/bin/ncp_perl $NCHOME/precision/scripts/sql/update_db_schemas.pl -domain DOMAIN_NAME -preview

Este mandato imprime los cambios de esquema que se realizarán en un archivo; puede revisarlosantes de aplicarlos a la base de datos. De forma predeterminada, este archivo se encuentraen /tmp/nm-update.sql. Para darle otro nombre al archivo, especifique un nombre después de laopción -preview. Si lo hace, la vista previa se graba en un archivo con ese nombre en el directorioactual.

3. Ejecute el script para aplicar las actualizaciones de esquema.

$NCHOME/precision/bin/ncp_perl $NCHOME/precision/scripts/sql/update_db_schemas.pl -domain DOMAIN_NAME

Nota: Cuando el actualizador de esquema aplica satisfactoriamente todos los cambios para undeterminado fixpack, graba una fila en la tabla ncim.schemaAudit, que proporciona el nombre delarchivo que contenía esos cambios y la indicación de fecha y hora de cuando se aplicaron.

Comprobación de actualizaciones de esquemaPuede comprobar qué actualizaciones esquema de arreglo temporal y fixpack se han aplicado a la basede datos de topología NCIM.

Acerca de esta tareaPuede realizar esta comprobación de varias formas:

• Ejecutando la siguiente sentencia select en la base de datos de topología NCIM:

SELECT * FROM ncim.schemaAudit ORDER BY lastTraced;

• Ejecutando el script list_applied_updates.pl. Para ello, obtenga primero el entorno y ejecute elscript mediante un mandato similar al siguiente:

$NCHOME/precision/bin/ncp_perl $NCHOME/precision/scripts/sql/list_applied_updates.pl -domain DOMAIN_NAME

Nota: Si tiene más de un dominio que comparte los mismos detalles de inicio de sesión, sólo necesitaráejecutar el script para uno de los dominios. La ejecución del script para los otros dominios que utilizanlos mismos detalles de inicio de sesión sólo producirá el mismo resultado.

Desinstalación de fixpacksPuede desinstalar un fixpack instalado anteriormente. Este se conoce como retrotracción a una versiónanterior.

Acerca de esta tareaIBM Installation Manager almacena archivos de instalación en la ubicación de datos. Estos archivos seutilizan para retrotraer a una versión anterior.

Si ha suprimido los archivos de retrotracción necesarios, consulte la información sobre retrotracción ytitularidad en la documentación de IBM Installation Manager en: https://www.ibm.com/support/knowledgecenter/SSDV2W/im_family_welcome.html




Importante: Network Manager Fix Pack 6 no incluye la base de información gestionada (archivos MIB).Los MIB son necesarios para la detección de redes.

Para desinstalar el Fix Pack 6 y usar una versión anterior, complete los siguientes pasos:

1. Copie los archivos MIB del directorio siguiente a un directorio temporal: $NCHOME/precision/mibs/

2. Elimine todos los archivos del directorio $NCHOME/precision/mibs.3. Desinstale Network Manager Fix Pack 6 con las siguientes instrucciones.4. Si va a regresar a la versión 4.2 de Fix Pack 5, copie los archivos MIB desde el directorio temporal al

directorio MIB: $NCHOME/precision/mibs/5. Si va a volver a una versión anterior a 4.2 Fix Pack 5, copie los archivos MIB del directorio de copia de

seguridad /old_mibs/ al directorio MIB: $NCHOME/precision/mibs/6. Ejecute el comando ncp_mib, como se describe en: Cargando información actualizada de MIB en el

IBM Tivoli Network Manager IP Edition: Guía de instalación y configuración

Para desinstalar un fixpack, realice los siguientes pasos:

Procedimiento1. Detenga los procesos Network Manager que se están ejecutando.2. Inicie IBM Installation Manager:


./IBMIM


3. Pulse Retrotraer.4. En la lista Nombre de grupo de paquetes, seleccione el grupo de paquetes que contiene los paquetes

que desea retrotraer. Haga clic en Siguiente.5. Seleccione la versión del paquete a la que desea retrotraer y pulse Siguiente.6. Revise la información de resumen y pulse Retrotraer.

Capítulo 6. Instalación y desinstalación de fixpacks 87


Capítulo 7. Configuración de integraciones con otrosproductos

Puede configurar Network Manager para trabajar con productos de ®Tivoli. Consulte las tareas deconfiguración necesarias para configurar las integraciones disponibles.

Acerca de esta tareaNetwork Manager se puede integrar con los siguientes productos IBM:IBM Netcool Operations Insight

Network Manager es un componente clave dentro de dicha solución, donde está también fuertementeintegrado con Netcool/Impact y IBM Operations Analytics - Log Analysis.

IBM Netcool Configuration Manager

Netcool Configuration Manager proporciona amplias prestaciones de gestión de la configuración paralos dispositivos de red, así como funciones de umbrales de políticas de red.

Si se integra con Network Manager, puede usar Línea temporal de sucesos y configuración en Panelde instrumentos de estado de red para correlacionar los datos de configuración con los datos dealertas.

Netcool Configuration Manager también se puede integrar con Network Manager y con Tivoli Netcool/OMNIbus para proporcionar funciones de diagnóstico más potentes a los operadores de red.

IBM Cognos AnalyticsLa integración con Cognos Analytics proporciona informes listos para utilizar, incluidos los informessobre la información de configuración de red.

IBM Tivoli Application Dependency Discovery ManagerIBM Tivoli Application Dependency Discovery Manager proporciona la siguiente funcionalidad:

• Importa la información de topología de red que descubre Network Manager a IBM Tivoli ApplicationDependency Discovery Manager para completar la vista de las dependencias de las aplicaciones conla red.

• El informe de inventario de Network Manager está disponible en IBM Tivoli Application DependencyDiscovery Manager.

• Permite a los usuarios el inicio contextual en las vistas de red para investigar qué problemas de lainfraestructura pueden estar afectando al rendimiento de la aplicación.

• Network Manager también puede realizar el inicio contextual en IBM Tivoli Application DependencyDiscovery Manager para mostrar la vista Historial de cambios y la vista de detalles asociadas con losdispositivos.

IBM Tivoli MonitoringIBM Tivoli Monitoring proporciona la siguiente funcionalidad:

• Supervisa el estado de la aplicación de Network Manager y muestra las situaciones y métricas claveque ayudan a los administradores a supervisar la salud y el estado de Network Manager.

• Puede utilizarse para supervisar recursos dentro de la red de Network Manager.• Es posible iniciar desde IBM Tivoli Monitoring directamente a Network Manager, aunque no es un

inicio en contexto.

IBM Tivoli Business Service ManagerIBM Tivoli Business Service Manager proporciona la siguiente funcionalidad:

• Rellena el modelo de servicio de negocio utilizando la información de red descubierta por variasaplicaciones, incluyendo Network Manager


• Correlaciona sucesos desde varias fuentes a los sucesos de IBM Tivoli Business Service Manager,incluyendo los recursos descubiertos en Network Manager. En este caso, los recursos hacenreferencia a dispositivos, interfaces, etc.

• Soluciona los problemas en la infraestructura iniciando el contexto desde las vistas de servicio IBMTivoli Business Service Manager en una de varias vistas de topología de Network Manager.

Referencia relacionadaRequisitos de compatibilidad para otros productosAsegúrese de que cumple los requisitos para los productos que están integrados con Network Manager.

Configuración de Tivoli Netcool/OMNIbus para su uso con NetworkManager

Si ha instalado Tivoli Netcool/OMNIbus sin utilizar la instalación de Network Manager, tendrá que realizaralgunas tareas de configuración.

Acerca de esta tareaTivoli Netcool/OMNIbus utiliza sucesos que proporciona Network Manager y otros orígenes de sucesos, ytambién se puede utilizar como un origen de autenticación. Consulte la información relacionada acontinuación para obtener enlaces a temas relevantes.

Para utilizar Tivoli Netcool/OMNIbus, debe modificar una tabla en el ObjectServer. Si está ejecutandoNetwork Manager en una instalación de FIPS 140–2, debe realizar alguna configuración adicional en elJRE de Tivoli Netcool/OMNIbus.

Para obtener más información sobre Tivoli Netcool/OMNIbus, incluida la configuración posterior a lainstalación y las consideraciones FIPS 140–2, consulte la publicación IBM Tivoli Netcool/OMNIbusInstallation and Deployment Guide e IBM Tivoli Netcool/OMNIbus Administration Guide.

Tareas relacionadasConfiguración de la migración tras error de origen de datos para la GUI web de Tivoli Netcool/OMNIbusSi tiene un par de migración tras error de ObjectServers a los que se debe conectar la GUI web, puedeconfigurar la migración tras error de origen de datos utilizando el archivo de configuración de origen dedatos ncwDataSourceDefinitions.xml en su instalación de la GUI web.

Configuración de ObjectServer para su uso con los procesos principales deNetwork Manager

Sólo para los usuarios con Network Manager 4.2 Arreglo temporal 2, puede utilizar el scriptconfig_object_server_for_itnm.sh para configurar un ObjectServer para su uso con los procesosprincipales de Network Manager. Este script da soporte a un ObjectServer ejecutándose en Windows yUNIX. El script configura la conexión con el ObjectServer y puede utilizarse para configurar unObjectServer local o remoto. También ejecuta varios mandatos SQL que crean y configuran en elObjectServer las tablas y los usuarios que necesita Network Manager.

Antes de empezarAntes de ejecutar el script config_object_server_for_itnm.sh, asegúrese de que el ObjectServeresté activo y en ejecución.

Debe ejecutar el script config_object_server_for_itnm.sh en el servidor donde se han instaladolos procesos principales de Network Manager.

Acerca de esta tareaPara configurar el ObjectServer para su uso con los procesos principales de Network Manager, siga estospasos:


Procedimiento1. Obtenga las variables de entorno principales de Network Manager.2. Cambie al siguiente directorio:

$NCHOME/precision/scripts

3. Emita el siguiente mandato para ejecutar el script config_object_server_for_itnm.sh:

./config_object_server_for_itnm -o OS_name -u OS_admin_user -p OS_admin_password -I itnm_account_password

Donde:

• OS_name es el nombre del ObjectServer que se va a configurar.• OS_admin_user es el identificador de usuario del usuario administrativo del ObjectServer.• OS_admin_password es la contraseña del usuario administrativo del ObjectServer.• itnm_account_password es la contraseña de las cuentas de usuario itnmadmin e itnmuser de

Network Manager que se crearán en el ObjectServer.

Durante la ejecución del script, se le solicitará si desea utilizar una conexión de ObjectServer existentedefinida en el archivo de configuración $NCHOME/etc/omni.dat. Responda a la pregunta de lasiguiente manera:

• y para utilizar una conexión ya definida en el archivo de configuración $NCHOME/etc/omni.dat.• n para proporcionar los siguientes nuevos detalles de la conexión de ObjectServer:

– Nombre de host.– Puerto.– Si la conexión utiliza SSL.

Nota: Si selecciona esta opción, cuando finalice la ejecución del script, los detalles de la conexión segraban en el archivo de configuración $NCHOME/etc/omni.dat.

ResultadosCuando finaliza, el script le recomienda configurar un analizador para ObjectServer.Tareas relacionadasInstalación y configuración de sondasSi no ha instalado Tivoli Netcool/OMNIbus como parte de la instalación de Network Manager y estáutilizando una instalación existente de Tivoli Netcool/OMNIbus, debe configurar algunas sondas.

Configuración del repositorio de usuariosSi desea utilizar un ObjectServer como repositorio de usuarios y no lo ha instalado durante la instalaciónde Network Manager, debe ejecutar scripts para configurar los usuarios y asignar roles a estos usuarios.

Acerca de esta tareaPara configurar ObjectServer como el repositorio de usuarios, siga estos pasos:

Procedimiento1. Inicie una sesión en la máquina donde se encuentran los componentes de la GUI de Network Manager.2. Obtenga las variables de entorno de la GUI de Network Manager.3. Vaya al directorio $WAS_HOME/bin.4. Cree los usuarios ejecutando el siguiente mandato:

./wsadmin.sh -conntype SOAP -user jazz_admin_name -password jazz_admin_password -lang jython -f $NMGUI_HOME/bin/scripts/users.py itnmadmin_password

Capítulo 7. Configuración de integraciones con otros productos 91

Donde:

• jazz_admin_name es el nombre del usuario administrador de Jazz for Service Management. Deforma predeterminada, es smadmin.

• jazz_admin_password es la contraseña del administrador de Jazz for Service Management.• itnmadmin_password es la contraseña de las cuentas itnmadmin y itnmuser.

5. Asigne roles a los usuarios y a los grupos de usuarios ejecutando el siguiente mandato:

$NMGUI_HOME/bin/assigns_users_to_roles -u jazz_admin_name -p jazz_admin_password -r

Donde:

• jazz_admin_name es el nombre del usuario administrador de Jazz for Service Management.• jazz_admin_password es la contraseña del administrador de Jazz for Service Management.• -r es un distintivo para volver a crear la lista de identificadores de usuario. La especificación de este

distintivo indica al script que debe asignar roles al usuario administrador de Jazz for ServiceManagement (de forma predeterminada, smadmin), así como a todos los usuarios y grupos deNetwork Manager.

Configuración del nombre de origen de datos de GUI web de Tivoli Netcool/OMNIbus

Si ha instalado los componentes de GUI de Network Manager y ha elegido no crear un nuevo origen dedatos de GUI web, debe configurar Network Manager para que utilice un origen de datos existente.También puede seguir estas instrucciones si desea cambiar el origen de datos.

Acerca de esta tareaUn origen de datos es otro término para un par de migración tras error de ObjectServer u ObjectServerutilizado por el GUI web para la información de sucesos. Algunos despliegues contienen muchosObjectServers, y la GUI web puede contener sucesos desde varios ObjectServers distintos. Para mostrarel estado del dispositivo, las Vistas de red y la Vista de saltos se correlacionan con el registro de topologíapara un dispositivo con cualquier suceso en dicho dispositivo. Para realizar esta correlación, lasaplicaciones web deben tener acceso al nombre de un origen de datos utilizado por la GUI web.

Si desea añadir un nuevo origen de datos en GUI web, utilice las instrucciones sobre la configuración deorígenes de datos en la documentación de GUI web en la siguiente ubicación:


Asegúrese de que Network Manager está configurado para utilizar un origen de datos de GUI webexistente completando los pasos siguientes.

Procedimiento1. Realice una copia de seguridad del archivo NCHOME/etc/precision/ModelNcimDb.NOMBRE_DOMINIO.cfg y edítelo.

2. Cambie la propiedad WebTopDataSource al nuevo nombre de origen de datos.3. Guarde y cierre el archivo.4. Reinicie el proceso ncp_model.

Configuración de los tipos de sucesos de topologíaPara integrar las vistas de topología y las vistas del Visor de sucesos filtradas, el nombre y el tipo de vistadeben coincidir. Si cambia los valores predeterminados en el Visor de sucesos, debe configurar elnombre y el tipo en Network Manager.



Acerca de esta tareaEn una vista del Visor de sucesos filtrada, puede configurar el nombre y el tipo de vista. Si cambia elnombre y el tipo de vista de los valores predeterminados de NetworkManagementEvents y global,Visor de sucesos no puede comunicarse con las Vistas de red y las herramientas de clic con el botónderecho.

Si los valores predeterminados han cambiado, debe cambiar los valores en el servidor de NetworkManager para que coincidan.

Para editar el nombre y el tipo de vista que se utilizan para comunicarse con el Visor de sucesos, sigaestos pasos:

Procedimiento1. Haga una copia de seguridad y edite el archivo $NMGUI_HOMEprofile/etc/tnm/topoviz.properties.

2. Cambie los valores de las siguientes propiedades:

topoviz.webtop.view.name=NetworkManagementEventstopoviz.webtop.view.type=global

Instalación y configuración de sondasSi no ha instalado Tivoli Netcool/OMNIbus como parte de la instalación de Network Manager y estáutilizando una instalación existente de Tivoli Netcool/OMNIbus, debe configurar algunas sondas.

Acerca de esta tareaPara asegurarse de que la instalación de Tivoli Netcool/OMNIbus recibe sucesos de la red, debeconfigurar las sondas de Tivoli Netcool/OMNIbus relevantes. En concreto, para asegurarse de que puedeprocesar las interrupciones SNMP de su red, debe instalar y configurar el analizador SNMP (conocidotambién como el analizador mttrapd).

Para obtener más información sobre la instalación y configuración del analizador, consulte la guía dereferencia del analizador correspondiente, disponible en el Information Center en http://www.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/common/kc_welcome-444.html.

Instalación de Knowledge LibraryDebe instalar Netcool/OMNIbus Knowledge Library para poder habilitar Network Manager de modo quepueda procesar por completo los sucesos de red.

Acerca de esta tareaNetcool/OMNIbus Knowledge Library Es un conjunto de archivos de reglas escritas en un estándar comúny están disponibles con la instalación de Tivoli Netcool/OMNIbus.

Referencia de integración de Tivoli Netcool/OMNIbusLea acerca de la configuración para una interacción adicional entre Network Manager y Tivoli Netcool/OMNIbus.

Configuración de la Sonda para Tivoli Netcool/OMNIbusLa Sonda para Tivoli Netcool/OMNIbus (nco_p_ncpmonitor) adquiere y procesa los sucesos quegeneran los sondeos y los procesos de Network Manager, y reenvía estos sucesos al ObjectServer.

La Sonda para Tivoli Netcool/OMNIbus se instala en el directorio $NCHOME/probes/arch, donde archrepresenta un directorio del sistema operativo. Puede configurar la sonda utilizando sus archivos deconfiguración, que son los siguientes:


http://www.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/common/kc_welcome-444.html

http://www.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/common/kc_welcome-444.html

• Archivo de propiedades: nco_p_ncpmonitor.props• Archivo de reglas: nco_p_ncpmonitor.rules

Nota: El archivo ejecutable (o mandato nco_p_ncpmonitor) para la sonda también se instala en eldirectorio $NCHOME/probes/arch. La sonda se configura, sin embargo, para ejecutarse bajo elcontrolador de proceso del dominio CTRL, de forma predeterminada, y el mandato nco_p_ncpmonitordebería ejecutarse manualmente únicamente para fines de resolución de problemas.

Los sucesos generados en Network Manager son específicos del dominio. Cuando Network Manager seejecuta en modalidad de migración tras error, la sonda utiliza el nombre del dominio virtual de formapredeterminada, suponiendo que el nombre esté configurado en el archivo $NCHOME/etc/precision/ConfigItnm.cfg.

Para obtener más información acerca de los conceptos de la sonda, consulte la publicación IBM TivoliNetcool/OMNIbus Probe and Gateway Guide de la información de Tivoli Netcool/OMNIbus en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

Tareas relacionadasConfiguración de la migración tras error utilizando el archivo ConfigItnm.cfgCuando utiliza el archivo $NCHOME/etc/precision/ConfigItnm.DOMAIN.cfg para configurar lamigración tras error, los procesos de Network Manager leerán el archivo en el inicio para identificar si seestán ejecutando en el dominio primario o de copia de seguridad.

Acerca del archivo nco_p_ncpmonitor.propsEl archivo $NCHOME/probes/arch/nco_p_ncpmonitor.props define el entorno en el que se ejecutala Sonda para Tivoli Netcool/OMNIbus.

El archivo de propiedades se forma de pares de nombre-valor que están separados por dos puntos. Elarchivo de propiedades predeterminado lista una subred de las propiedades que soporta la sonda; aestas propiedades se les quita el comentario con un signo de número (#) al inicio de la línea. El conjuntoestándar de propiedades de sonda comunes, que son aplicables para la versión de Tivoli Netcool/OMNIbus en ejecución, se puede especificar para la Sonda para Tivoli Netcool/OMNIbus, donde searelevante.

Una práctica sugerida para cambiar los valores predeterminados de las propiedades es que agregue unalínea de nombre-valor para cada propiedad requerida al final del archivo. Para especificar una propiedad,asegúrese de que la línea no está comentada y, a continuación, modifique el valor como sea necesario.Los valores de cadena deben encerrarse en comillas; otros valores no requieren comillas. Por ejemplo:

Buffering : 1BufferSize : 15

Para fines de resolución de problemas, puede configurar de forma alternativa las propiedades de la sondapara la línea de mandatos ejecutando el mandato nco_p_ncpmonitor con las opciones relevantes de lalínea de mandatos.

Nota: Las propiedades siguientes tienen valores predeterminados estándar:Servidor

Toma como valor predeterminado el ObjectServer identificado en el esquema ConfigItnm, lo quegarantiza la coherencia con la pasarela de Network Manager.

PropsFileToma como valor predeterminado $NCHOME/probes/platform/nco_p_ncpmonitor.props.

RulesFileToma como valor predeterminado $NCHOME/probes/platform/nco_p_ncpmonitor.rules.

MessageLogToma como valor predeterminado $NCHOME/log/precision/nco_p_ncpmonitor.domain_name.log.




RawCaptureFileToma como valor predeterminado $NCHOME/var/precision/nco_p_ncpmonitor.domain_name.cap.

Para obtener más información acerca de las propiedades comunes a las sondas, consulte la publicaciónIBM Tivoli Netcool/OMNIbus Probe and Gateway Guide en el centro de información de Tivoli Netcool/OMNIbus en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

Referencia de configuración de nco_p_ncpmonitor.rulesEl archivo $NCHOME/probes/arch/nco_p_ncpmonitor.rules define cómo Sonda para TivoliNetcool/OMNIbus debe procesar los datos de sucesos de Network Manager para crear un sucesosignificativo de Tivoli Netcool/OMNIbus.

En la práctica, el archivo de reglas correlaciona los datos de sucesos de Network Manager en los camposde ObjectServer, y se puede utilizar para personalizar el comportamiento del analizador. Es necesarioconocer la sintaxis de las reglas del analizador de Tivoli Netcool/OMNIbus para configurar el archivo dereglas.

La sonda utiliza señales y elementos, y aplica reglas, para transformar los datos del origen de sucesos deNetwork Manager en un formato que el ObjectServer pueda reconocer. Los datos del origen de sucesossin formato se convierten a señales, que se analizarán en elementos. El archivo de reglas se utilizará pararealizar el proceso condicional de los elementos, y para correlacionarlos en los campos de alerts.statusde ObjectServer. En el archivo de reglas, los elementos se identifican mediante el símbolo $ y los camposde alerts.status se identifican mediante el símbolo @. La configuración del archivo de reglas correlacionaelementos en campos, como se muestra en el siguiente código de ejemplo:

@Summary=$Description

En este ejemplo, @Summary identifica el campo alerts.status, y $Description identifica el campo deentrada de Network Manager.

Donde el campo ExtraInfo de Network Manager se utiliza con campos anidados para almacenar datosadicionales en entidades (por ejemplo, ExtraInfo->ifIndex), estos campos estarán disponibles en elformato siguiente del archivo de reglas:

$ExtraInfo_variable

Donde variable representa una variable de la MIB (base de información de gestión) (por ejemplo, ifIndex),u otros datos (por ejemplo, nombres de la columna en las tablas de NCIM). Las variables de MIB estánespecificadas en caracteres en mayúscula y minúscula mezcladas, y otros datos, en caracteres enmayúscula. Por ejemplo:

$ExtraInfo_ifIndex$ExtraInfo_MONITOREDENTITYID

Para configurar el archivo de reglas para la Sonda para Tivoli Netcool/OMNIbus, es necesario comprenderlo siguiente:

• Los datos de origen de sucesos de Network Manager que están disponibles para su uso en el archivo dereglas de la sonda

• El conjunto de campos de alerts.status que se pueden rellenar con datos de sucesos desde NetworkManager

• La correlación de datos entre los campos de Network Manager y de alerts.status

Para obtener más información acerca de la sintaxis utilizada en los archivos de reglas de la sonda,consulte la publicación IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide en el centro de informaciónde Tivoli Netcool/OMNIbus en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.






Ejemplo de proceso de archivos de reglasEste ejemplo muestra cómo procesa el archivo de reglas los datos de origen de Network Manager paragenerar los datos de salida que se insertarán en la tabla alerts.status.

El código de ejemplo siguiente muestra un registro de datos de sucesos de Network Manager que se pasaa la Sonda para Tivoli Netcool/OMNIbus para su proceso. En este registro, se creó un suceso deresolución cuando ncp_ctrl inició el proceso ncp_store.

{ EventName='ItnmServiceState'; Severity=1; EntityName='BACKUP'; Description='ncp_store process [15299] has started'; ExtraInfo={ EVENTTYPE=2; SOURCE='ncp_ctrl'; ALERTGROUP='ITNM Status'; EVENTMAP='ItnmStatus'; SERVICE='ncp_store'; PID=15299; };}

El siguiente extracto del archivo de reglas de la sonda muestra la sintaxis utilizada para procesar ycorrelacionar estos campos de entrada en los campos de alerts.status:

... # # populate some standard fields # @Severity = $Severity @Summary = $Description @EventId = $EventName @Type = $ExtraInfo_EVENTTYPE @AlertGroup = $ExtraInfo_ALERTGROUP @NmosEventMap = $ExtraInfo_EVENTMAP @Agent = $ExtraInfo_SOURCE

if (exists($ExtraInfo_ACCESSIPADDRESS)) { @Node = $ExtraInfo_ACCESSIPADDRESS } else { @Node = $EntityName }

# # Stamp the event with the name of its originating domain # @NmosDomainName = $Domain @Manager = "ITNM" @Class = 8000

# # populate fields for RCA # @LocalNodeAlias = @Node

...

# # Now set the AlertKey and Identifier # if (match(@AlertGroup, "ITNM Status")) { switch ($EventName) { case ...... case "ItnmServiceState": @LocalPriObj = $ExtraInfo_SERVICE... case ....... } }


# # Both the Identifier and the AlertKey contain the domain name. This ensures # that in a multi-domain setup, events are handled on a per-domain basis #

# # Include the LocalPriObj in the AlertKey or the link-downs on # all interfaces will cleared by a link-up on any interface # @AlertKey = $EntityName + @LocalPriObj + "->" + $EventName + @NmosDomainName

# # Set up deduplication identifier and include the LocalPriObj # so we can correctly handle de-duplication of events raised on interfaces # @Identifier = $EntityName + @LocalPriObj + "->" + $EventName + @Type + @NmosDomainName}

Cuando el proceso del archivo de reglas se complete, los datos de salida que se reenvían al ObjectServertoman la forma siguiente:

CMonitorProbeApp::ProcessStatusEvent{ AlertGroup='ITNM Status'; EventId='ItnmServiceState'; Type=2; Severity=1; Summary='ncp_store process [15299] has started'; Node='BACKUP'; NmosDomainName='PRIMARY'; LocalNodeAlias='BACKUP'; LocalPriObj='ncp_store'; LocalRootObj=''; RemoteNodeAlias=''; AlertKey='BACKUPncp_store->ItnmServiceStateVIRTUAL'; Identifier='BACKUPncp_store->ItnmServiceState2VIRTUAL'; Class=8000; Agent='ncp_ctrl'; LastOccurrence=1267122089;}

Según el proceso del archivo de reglas de este ejemplo, se puede ver que los campos de entrada deNetwork Manager se correlacionan con los campos alerts.status como sigue:

campo Network Manager campo alerts.status

EventName EventId

Gravedad Gravedad

EntityName Nodo

Descripción Resumen

ExtraInfo->EVENTTYPE Tipo

ExtraInfo->SOURCE Agente

ExtraInfo->ALERTGROUP AlertGroup

ExtraInfo->EVENTMAP NmosEventMap

ExtraInfo->SERVICE LocalPriObj

Nota: A continuación, se pueden ver la entrada y salida completas de las reglas del analizador en elarchivo de rastreo del analizador. Establezca el rastreo en depuración 4. El archivo de rastreo delanalizador se puede encontrar en: $NCHOME/log/precision. Para obtener más información sobre elestablecimiento de niveles de registro, consulte IBM Tivoli Network Manager IP Edition AdministrationGuide.

Referencia relacionadacampos alerts.status utilizados por Network Manager


La tabla alerts.status en ObjectServer contiene información de estado sobre problemas que handetectado las sondas.

Campos de los datos de sucesos de Network ManagerCuando se generen los sucesos en Network Manager, los datos de sucesos se insertarán en un número decampos (o columnas) de las tablas de Network Manager. Aunque cada suceso utiliza únicamente unsubconjunto de los posibles campos, son comunes un número de campos para todos los tipos desucesos.

La tabla siguiente lista todos los nombres de campos de Network Manager que están disponibles para suuso en el archivo de reglas de sonda, y describe los datos de sucesos almacenados en cada campo. Latabla identifica igualmente cual de los campos de Network Manager son comunes para todos los sucesosy, por lo tanto, siempre estarán disponibles en el archivo de reglas.

Tabla 8. Campos de Network Manager que rellenan los sucesos

Nombre del campo de NetworkManager Contenido del campo

¿Disponible en todomomento?

Descripción Una descripción breve del suceso. Sí

Dominio El dominio actual.

Si Network Manager está configurado parala modalidad de migración tras error, ésteserá el dominio principal.

Sí (suponiendo que elarchivo de correlación noesté modificado)

EntityName Para sucesos de red, este es el campo deentityName desde la tabla de entityData deNCIM para la entidad en la que el sucesose genera.

Para sucesos de estado, este es siempre elnombre del dominio sobre el que se generael suceso.

Sí

EventName El identificador del suceso. Por ejemplo,ItnmDiscoPhase.

Sí

ExtraInfo_ACCESSIPADDRESS Si el nodo principal o la entidad de lainterfaz identificada por el campo deentrada de EntityName tiene una direcciónIP accesible de forma directa (el campoaccessIPAddress desde la interfaz deNCIM o las tablas de chasis), se facilitaráaquí. Aplicable únicamente a sucesos dered.

No

ExtraInfo_AGENT El agente responsable de un suceso delagente de descubrimiento(ItnmDiscoAgentStatus).

Sí (para sucesos deItnmDiscoAgentStatus)

ExtraInfo_ALERTGROUP El grupo de alerta del suceso. Para lossucesos de estado de Network Manager, elgrupo de alerta es ITNM Status y, paralos sucesos de red, el valor es ITNMMonitor.

Sí

ExtraInfo_ENTITYCLASS El nombre de la clase asignada a laentidad, como se identifica en las tablasentityClass y classMembers de NCIM.

Sí (para sucesos de red yde ItnmEntityCreation)


Tabla 8. Campos de Network Manager que rellenan los sucesos (continuación)



ExtraInfo_ENTITYTYPE El tipo de la entidad, como se define en latabla entityType de NCIM.

Sí (para sucesos de red)

ExtraInfo_LocalPriObj Proporciona un valor para el campoLocalPriObj en el registro alerts.status.Este campo tiene el mismo valor que elcampo en desusoExtraInfo_EventSnmpIndex, a excepciónde que tiene el prefijo de un identificadorpara la entidad de MIB que se sondeará;por ejemplo ifEntry, bgpPeerEntry.


ExtraInfo_EVENTTYPE El tipo de suceso generado por NetworkManager. Los valores son los siguientes:

• 1: Problema• 2: Resolución• 13: Información

Sí

ExtraInfo_FINDER El buscador responsable de un suceso debuscador de descubrimiento(ItnmDiscoFinderStatus).

Sí (para sucesos deItnmDiscoFinderStatus)

ExtraInfo_ifIndex Para sucesos generados en una interfazcon un valor de ifIndex en la tabla de lainterfaz de NCIM, dicho valor se otorgaaquí. Aplicable únicamente a sucesos dered en interfaces.

No

ExtraInfo_IFALIAS Para sucesos generados en interfaces, estecampo contiene el valor ifAlias, si seconoce. Aplicable únicamente a sondeosde interfaz de red.

No

ExtraInfo_IFDESCR Para sucesos generados en interfaces, estecampo contiene el valor ifDescr, si seconoce. Aplicable únicamente a sondeosde interfaz de red.

No

ExtraInfo_IFNAME Para sucesos generados en interfaces, estecampo contiene el valor ifName, si seconoce. Aplicable únicamente a sondeosde interfaz de red.

No

ExtraInfo_IFTYPESTRING Para sucesos generados en interfaces, estecampo contiene la representación decadenas del valor ifType. Aplicableúnicamente a sondeos de interfaz de red.

No

ExtraInfo_MAINNODEADDRESS La interfaz de gestión del nodo principalque contiene la entidad, como se identificamediante el campo accessIPAddress de latabla de chasis de NCIM. Aplicableúnicamente a sucesos de red y deItnmEntityCreation.






ExtraInfo_MAINNODEENTITYID El campo entityId de la tabla entityData deNCIM para el nodo principal, como seidentifica mediante el campoaccessIPAddress de la tabla de chasis deNCIM. Aplicable únicamente a sucesos dered.


ExtraInfo_MAINNODEENTITYNAME El campo entityName de la tabla entityDatade NCIM para el nodo principal, como seidentificó en NCIM. Aplicable únicamente asucesos de red.


ExtraInfo_MONITOREDENTITYID El campo de entityId de la tabla entityDatade NCIM para la entidad en la que segenera el suceso. Aplicable únicamente asucesos de red y de ItnmEntityCreation.

No

ExtraInfo_MONITOREDINSTID Un registro en la tablancpolldata.monitoredInstance.

No

ExtraInfo_NEWPHASE La fase de descubrimiento que se hainiciado. Aplicable únicamente a lossucesos de la fase de descubrimiento(ItnmDiscoPhase).

Sí (para sucesos de la fasede descubrimiento)

ExtraInfo_OLDPHASE La fase de descubrimiento que hafinalizado. Aplicable únicamente a lossucesos de la fase de descubrimiento(ItnmDiscoPhase).

Sí (para sucesos de la fasede descubrimiento)

ExtraInfo_POLICYNAME El nombre de la política de sondeo que diolugar al suceso.


ExtraInfo_PID El ID de proceso del servicio de NetworkManager afectado. Aplicable únicamentepara los sucesos de ItnmServiceState.

Sí (para sucesos delestado de servicio)

ExtraInfo_REMOTEDOMAIN El nombre del dominio remoto. Aplicableúnicamente para sucesos deItnmFailoverConnection.

Sí (para sucesos deconexión de migracióntras error)

ExtraInfo_sysContact Si está disponible, el valor sysContact seotorga únicamente para los sucesos deItnmEntityCreation.

No

ExtraInfo_sysLocation Si está disponible, el valor sysLocation seotorga únicamente para los sucesos deItnmEntityCreation

No

ExtraInfo_sysObjectId Si está disponible, el valor sysObjectId seotorga únicamente para sucesos deItnmEntityCreation

No

ExtraInfo_SERVICE El nombre del servicio de NetworkManager afectado. Aplicable únicamentepara los sucesos de ItnmServiceState.

Sí (para sucesos delestado de servicio)





ExtraInfo_SNMPSTATUS Un código de estado de SNMP numérico. Sí (para sucesos deNmosSnmpPollFail)

ExtraInfo_SNMPSTATUSSTRING Una indicación legible por humanos delestado de fallo de SNMP.

Sí (para sucesos deNmosSnmpPollFail)

ExtraInfo_SOURCE El nombre del proceso desde el que seoriginó el suceso.

Sí

ExtraInfo_STITCHER El agrupador responsable de un suceso deagrupador de descubrimiento(ItnmDiscoStitcherStatus).

Sí (para sucesos deItnmDiscoStitcherStatus)

Gravedad El nivel de gravedad del suceso. Lagravedad es un valor distinto a cero.

Sí

campos alerts.status utilizados por Network ManagerLa tabla alerts.status en ObjectServer contiene información de estado sobre problemas que handetectado las sondas.

Un subconjunto de campos alerts.status estándar se llena con datos de sucesos de NetworkManager. De forma adicional, se reserva un conjunto de campos dedicados alerts.status para retenerdatos que son específicos para Network Manager. Los nombres de campo alerts.status dedicadosson identificables por el prefijo Nmos.

La siguiente tabla describe los campos alerts.status que llenan los campos de Network Manager. Aalgunos de estos campos alerts.status se les asignan valores predeterminados desde dentro delarchivo de reglas de sonda. (Intente no modificar estos valores predeterminados.)

Tabla 9. campos alerts.status utilizados por Network Manager

campo alerts.statusTipo dedatos Descripción

Nombre/valor predeterminado decampo de Network Manager en elarchivo de reglas

Agente varchar(64) Nombre del proceso que ha generadoel suceso. Puede utilizar este campopara filtrar el Visor de sucesos paramostrar solo los sucesos de un tipoespecífico; por ejemplo, solo sucesosde descubrimiento (con un valor dencp_disco).

ExtraInfo_SOURCE

AlertGroup varchar(255)

Utilizado para agrupar sucesos portipo. Los valores proporcionados deforma predeterminada desde lossucesos de Network Manager sonITNM Monitor para sucesos de redo ITNM Status para sucesos deestado.

ExtraInfo_ALERTGROUP


Tabla 9. campos alerts.status utilizados por Network Manager (continuación)



AlertKey varchar(255)

Una cadena de texto que concatenadiferentes elementos relacionadoscon el suceso. Los elementos puedenincluir el ID de suceso, dominio, fasey nombre de proceso. Permite que lossucesos de problemas y deresolución sean coincidentes.

Este valor es generado desde laentrada para asegurar unacoincidencia apropiada de lossucesos de problemas y deresolución en ObjectServer.

Clase integer La clase de alerta asignada a laSonda para Tivoli Netcool/OMNIbus.

Se reserva un valor de 8000 paralos sucesos generados porNetwork Manager.

EventId varchar(255)

El tipo de suceso (por ejemplo,SNMPTRAP-linkDown). La pasarelade sucesos utiliza este valor parabuscar la correlación de sucesos ypara determinar la precedencia delos sucesos.

EventName

ExpireTime integer La fecha de caducidad del suceso enla base de datos. Network Manager,no lo utiliza actualmente.

FirstOccurrence time Una indicación de fecha que señalacuando tuvo lugar por primera vez.

Identificador varchar(255)

Un valor exclusivo para cada tipo desuceso en una entidad determinada(por ejemplo, un suceso LinkDown enuna interfaz de dispositivoespecífico). Este identificadorcontrola la optimización delalmacenamiento.

Este valor se genera desde laentrada para asegurar unaoptimización del almacenamientode los sucesos apropiada enObjectServer. En el archivo dereglas, el identificador se construyecomo una concatenación devalores de campo.

LastOccurrence time Una indicación de fecha que señalacuando tuvo lugar por última vez.

LocalNodeAlias varchar(64) La dirección IP o DNS del dispositivo.Este valor se refiere normalmente alchasis, pero solo para pingFails,puede corresponderse con lainterfaz.

Para sucesos de red, este campose establece en el mismo valor queel campo Nodo.

No se define ningún valor parasucesos de estado, paraasegurarse de que no seretroalimentan en NetworkManager mediante la pasarela desucesos.





LocalPriObj varchar(255)

La entidad específica para la cual segenera el suceso; por ejemplo, elvalor de campo ifIndex, ifDescr oifPhysAddress.

ExtraInfo_AGENT oExtraInfo_FINDER oExtraInfo_ifIndex oExtraInfo_NEWPHASE oExtraInfo_SERVICE oExtraInfo_STITCHER

El valor ExtraInfo_ifIndex semuestra utilizando la sintaxisifEntry.<ifIndex>. Porejemplo, ifEntry.12.

LocalRootObj varchar(255)

El contenedor de la entidadreferenciada en el campoLocalPriObj. No tiene por qué ser elchasis, pero podría ser, por ejemplo,la ranura en un chasis. El chasistodavía se puede identificarutilizando LocalNodeAlias.

LocalSecObj varchar(255)

El objeto secundario referenciado porel suceso.

ExtraInfo_OLDPHASE

Manager varchar(64) Un nombre descriptivo que identificael sistema que enviaba los sucesos.

Un valor de ITNM se utiliza para lossucesos generados por NetworkManager V3.8 o posterior.

Un valor de Omnibus se utiliza enversiones anteriores.

NmosCauseType integer El estado de suceso. Rellenado por lapasarela NMOS. Los posibles valoresson los siguientes:

• 0: Desconocido• 1: Causa principal• 2: Síntoma

NmosDomainName varchar(64) El nombre del dominio de red deNetwork Manager que ha generado elsuceso. El nombre del dominioprimario se utiliza en modalidad demigración tras error.

De forma predeterminada, se rellenaeste campo solo para sucesosgenerados por Network Manager.Para rellenar este campo para otrosorígenes de sucesos, como las deotras sondas, debe modificar losarchivos de reglas para esas sondas.

La pasarela de sucesos rellena estecampo si un suceso es coincidentecon una entidad en un dominio.

Dominio





NmosEntityId integer El ID de objeto exclusivo queidentifica la entidad de topología conla que el suceso está asociada. Estecampo es similar al campoNmosObjInst pero contieneinformación más detallada. Porejemplo, este campo puede incluir elID de una interfaz dentro de undispositivo.

El campo NmosEntityId se rellena enel archivo de reglas de la sonda. Paralos demás sucesos, la pasarelarellena este campo cuando seidentifica la entidad.

ExtraInfo_MONITOREDENTITYID

NmosEventMap varchar(64) El nombre de correlación del sucesoy la precedencia opcional para elsuceso, que indica cómo NetworkManager debe procesar el suceso;por ejemplo,PrecisionMonitorEvent.910. Elnúmero de precedencia opcional sepuede concatenar al final del valor,después de un punto (.) Si no seproporciona la precedencia, se defineen 0.

Nota: Este valor se puede sustituirpor una inserción explícita en la tablaconfig.precedence de la pasarela desucesos, que proporciona los mismosdatos.

NmosManagedStatus

integer El estado gestionado de la entidad dered para el que el suceso se hagenerado. Cuando una entidad de redno está gestionada, se suspenden lossondeos de Network Manager y lossucesos de otros orígenes se marcancomo no gestionados. Este campo lepermite filtrar sucesos desdeentidades no gestionadas. Losposibles valores para este campo sonlos siguientes:

• 0: Managed• 1: Operador no gestionado• 2: Sistema no gestionado• 3: Fuera de ámbito





NmosObjInst integer El ID de objeto exclusivo queidentifica la entidad de chasis detopología contenida con la que elsuceso está asociado. Rellenado porla pasarela NMOS.

Consejo: Este campo se puedeutilizar para detectar si el suceso seha pasado para el enriquecimiento desucesos.

NmosSerial integer El número de serie del suceso quesuprime el suceso actual. Rellenadopor la pasarela NMOS.

Nodo varchar(64) El dispositivo a partir del cual se haoriginado el suceso. Si se origina unsuceso en un entidad con unadirección IP accesible, se utiliza estadirección IP. En caso contrario, seutiliza el valor entityName de NCIM.De forma predeterminada, Nodotiene el mismo valor queLocalNodeAlias.

ExtraInfo_ACCESSIPADDRESS oEntityName

El valor EntityName se correlacionacon el campo Nodo solo si elcampo de entradaExtraInfo_ACCESSIPADDRESS estávacío.

NodeAlias varchar(64) La dirección IP del nodo principal, siestá disponible.

ExtraInfo_MAINNODEADDRESS

RemoteNodeAlias varchar(64) La dirección de red de un nodoremoto, donde sea relevante. Porejemplo:

• Un valor en blanco (cuando unainterfaz deja de funcionar)

• Una dirección cercana (en la queuna interfaz conectada ha dejadode funcionar)

• La estación de sondeo (para unsuceso de error de ping)

Serial incr Un ID exclusivo por suceso y porinstancia de ObjectServer.

En donde se configuranObjectServers primarios y derespaldo, ObjectServers tendránúmeros de serie diferentes para elmismo suceso.

ServerName varchar(64) El nombre del ObjectServeroriginario.





ServerSerial integer El número de serie del suceso en elObjectServer originario.

En donde se configuranObjectServers primarios y derespaldo, ObjectServers tendránúmeros de serie diferentes para elmismo suceso. Si el suceso se haoriginado en el ObjectServer actual,el valor ServerSerial es el mismo queel valor de serie.

Gravedad integer El nivel de gravedad del sucesoalmacenado en ObjectServer. Losvalores predeterminados son lossiguientes:

• 0: Despejado (VERDE)• 1: Indeterminado (PÚRPURA)• 2: Aviso (AZUL)• 3: Menor (AMARILLO)• 4: Grave (NARANJA)• 5: Crítico (ROJO)

Gravedad

StateChange time Una indicación de fecha que señalacuando se ha modificado por últimavez el suceso. Este campo se puedeutilizar para determinar si un procesoestá modificando un suceso despuésde que se haya agregado aObjectServer.

Resumen varchar(255)

Una descripción textual del suceso. Descripción

Cuadrar integer Un recuento del número de vecesque un suceso ha tenido lugar. Estevalor se muestra en la columnaRecuento en la lista de sucesos o elVisor de sucesos, y en la columnaProducidos en la tablamojo.events.

Tipo integer El tipo de alerta. Los valores derelevancia particular para NetworkManager son

• 1: Problema• 2: Resolución• 13: Información

ExtraInfo_EVENTTYPE


Para obtener más información sobre la tabla alerts.status, consulte la publicación IBM Tivoli Netcool/OMNIbus Administration Guide del centro de información de Tivoli Netcool/OMNIbus en IBM TivoliNetcool/OMNIbus - Información sobre el producto.

Automatizaciones de Tivoli Netcool/OMNIbus agregadas por NetworkManagerNetwork Manager proporciona un número de automatizaciones de Tivoli Netcool/OMNIbus. Cadaautomatización realiza distintas tareas dentro de la instalación de Network Manager.

Para habilitar una automatización, utilice la GUI del administrador de Tivoli Netcool/OMNIbus.

La tabla siguiente describe las automatizaciones de Tivoli Netcool/OMNIbus instaladas por NetworkManager.

Tabla 10. Automatizaciones de Tivoli Netcool/OMNIbus agregadas por Network Manager

Automatización Descripción

¿Se agregódurante lainstalación?

Estadopredeterminado

severity_from_causetype

Establece la gravedad de los sucesos enla tabla alerts.status de ObjectServersegún el valor de NmosCauseType, uncampo enumerado que contiene losresultados de los cálculos del análisis decausa raíz (RCA) de Network Manager.Los valores posibles para el campoNmosCauseType son:

• 0 - desconocido• 1 - causa raíz• 2 - síntoma

Sí Habilitado


http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html

Tabla 10. Automatizaciones de Tivoli Netcool/OMNIbus agregadas por Network Manager (continuación)

Automatización Descripción

¿Se agregódurante lainstalación?

Estadopredeterminado

suppress_cross_domain_connections

Suprime los sucesos de los dispositivosconectados donde el dispositivoconectado se encuentra en un dominiodistinto. Esta automatización sedesencadena siempre que un suceso seactualice mediante la Pasarela desucesos.

Restricción: Network Managerúnicamente modela las conexiones endominios de red en redes de MPLS entredispositivos de cliente y de proveedor yen redes de BGP entre iguales de BGP.

Para que la automatización funcione, losdos dispositivos de red deben estarconectados a la capa 3 en unasubred /30, es decir, una subred conúnicamente dos hosts. Cada dispositivodebe estar también descubierto en undominio de red distinto y la existencia desu dispositivo compañero debe habersido detallada durante eldescubrimiento. Ello significa que encada dominio se debe haber creado undispositivo detallado de cliente o unaentidad detallada de igual de BGP.

Sí Inhabilitado

update_service_affecting_events

Genera sucesos afectados por el servicio(SAE) cuando se encuentra con sucesosde red en entidades de soporte alservicio. Siguiendo cada descubrimiento,los conectores de SAE a la Pasarela desucesos analizan la topología actualizaday actualizan el ObjectServer con la listade entidades que soportan los servicios.Esta información habilita laautomatización para generar sucesosafectados por el servicio cuando seencuentra con sucesos de red enentidades que soportan el servicio.

No No aplicable

Configuración de la integración con Netcool Configuration ManagerPara añadir la configuración de red y las capacidades de gestión de políticas a su solución de gestión dered, configure Network Manager y Tivoli Netcool/OMNIbus para trabajar con IBM Tivoli NetcoolConfiguration Manager.

Acerca de esta tareaPuede configurar la integración entreNetwork Manager, Tivoli Netcool/OMNIbus y Netcool ConfigurationManager.


Debe instalar Network Manager antes de instalar Netcool Configuration Manager. Debe instalar NetcoolConfiguration Manager utilizando determinadas opciones de configuración.

Para obtener más información sobre cómo configurar la integración, seleccione su versión de NetcoolConfiguration Manager del Knowledge Center en http://www.ibm.com/support/knowledgecenter/SS7UH9/welcome, y consulte los temas de Integración de Netcool Configuration Manager con NetworkManager y Tivoli Netcool/OMNIbus. Si no, puede descargar la versión PDF, titulada IBM Tivoli NetcoolConfiguration Manager Integration Guide.

Nota: En el Knowledge Center de Netcool Configuration Manager también encontrará los detallescompletos sobre cómo eliminar la integración con Netcool Configuration Manager.

Exportación de datos de descubrimiento a CCMDB, TADDM y TBSMConfigure y utilice el adaptador de biblioteca de descubrimiento (DLA) para recopilar datos sobrerecursos de red y relaciones desde Network Manager para importarlos a otros sistemas.

Acerca de esta tareaEl DLA recopila datos de Network Manager y crea libros de biblioteca de descubrimiento XML (tambiénconocidos como libros IdML) que contienen datos sobre los recursos descubiertos y sus relacionesconocidas para el sistema. Los libros están en conformidad con Tivoli Common Data Model (CDM) versión2.10.10. Para obtener más información sobre Tivoli CDM, vaya a http://www.redbooks.ibm.com/abstracts/redp4389.html.

Los libros de la biblioteca de descubrimiento se pueden importar a otros sistemas para los que existe unLector de biblioteca de descubrimiento. El DLA soporta IPv4 e IPv6.

Nota: Para cargar los libros de la biblioteca de descubrimientos (IdML) que contienen información sobrelas máquinas virtuales en TADDM, debe tener TADDM 7.2.1 Fix Pack 1 o posterior.

El DLA está instalado de manera predeterminada con Network Manager en el servidor GUI. Está instaladoen el siguiente directorio: $NCHOME/precision/adapters/ncp_dla.

Requisitos previos para utilizar el DLAAntes de configurar y utilizar el adaptador de biblioteca de descubrimiento (DLA), asegúrese de que secumplen los requisitos previos.

• Se ha realizado una red de descubrimiento satisfactoria de Network Manager y se ha rellenado la basede datos de NCIM (Network Connectivity and Inventory Model).

• El DLA utiliza el sondeo de conexión del servidor de la GUI de forma predeterminada. Si desea utilizaruna base de datos de NCIM distinta a la proporcionada durante la instalación, debe tener lascredenciales de acceso para dicha base de datos de NCIM.

• Debe ejecutar el script ncp_dla.sh con un JRE de IBM Java en su variable de entorno $PATH. Paracomprobar su versión de Java, ejecute el siguiente mandato: java -version. Si la versión de Java noes de IBM, ubique un JRE de IBM y agregue el directorio que lo contiene al inicio de la variable deentorno $PATH. Hay un archivo JRE apropiado en este directorio: $WAS_HOME/java/bin.

• Debe tener un conocimiento práctico de cómo se despliega el producto con el que desea integrarse.

– Para obtener más información acerca de IBM Tivoli Application Dependency Discovery Manager,visite IBM Knowledge Center en la siguiente dirección web:

http://www.ibm.com/support/knowledgecenter/SSPLFC/welcome– Para obtener más información acerca de IBM Tivoli Business Service Manager, visite IBM Knowledge

Center en la siguiente dirección web:

http://www.ibm.com/support/knowledgecenter/SSSPFK/welcome




http://www.redbooks.ibm.com/abstracts/redp4389.html


http://www.ibm.com/support/knowledgecenter/SSPLFC/welcome

http://www.ibm.com/support/knowledgecenter/SSSPFK/welcome

– Para obtener más información acerca de IBM Tivoli Change and Configuration ManagementDatabase, visite IBM Knowledge Center en la siguiente dirección web: http://www.ibm.com/support/knowledgecenter/SSPLFC/welcome

Configuración del DLAEl adaptador de biblioteca de descubrimiento (DLA) requiere un archivo de propiedades de configuraciónpara determinar el origen de datos al que conectarse, el dominio que consultar, el directorio de destinopara los libros de la biblioteca de descubrimiento y los parámetros de registro.

Acerca de esta tareaTiene que configurar las propiedades de DLA si tiene un servidor de GUI separado o si desea utilizar elDLA con una instancia NCIM diferente de la predeterminada que se proporciona durante la instalación.

Se proporciona un archivo de configuración ncp_dla.properties preconfigurado en el directorio deinstalación de DLA en $NMGUI_HOME/adapters/ncp_dla. La presencia de 'XXXXXX' o <'word'> en elarchivo de configuración indica que el usuario debe especificar el parámetro. El archivo de configuraciónproporciona valores predeterminados útiles para la mayoría de opciones pero asegúrese de sustituirloscon valores adecuados para su entorno.

Nota: De manera predeterminada, los parámetros de acceso de NCIM necesarios para utilizar el DLA sederivan del sondeo de acceso de la GUI de Network Manager. Este valor lo especifica el parámetroncp.dla.datasource.autoConnect en el que el valor predeterminado es "true". Si cambia este valora "false", debe especificar valores para los parámetros enumerados en el paso “6” en la página 111. Laconfiguración de cómo conectarse a la base de datos NCIM de forma manual es útil cuando no se puedeacceder al sondeo de conexión o si desea utilizar una instancia NCIM diferente de la que se proporcionade manera predeterminada durante la instalación.

Procedimiento1. Vaya a$NMGUI_HOMEadapters/ncp_dla y copie el archivo ncp_dla.properties en una versión

específica de dominio agregando el nombre del archivo con el nombre del dominio, por ejemplo,ncp_dla.properties.NCOMS.

2. Especifique el dominio de Network Manager asignando un valor a la propiedadncp.dla.precisionDomain.El nombre de dominio predeterminado es "NCOMS."

3. Opcional: Puede definir la vía de acceso a un directorio temporal que el DLA debería utilizar algenerar la salida si no desea que utilice el directorio temporal predeterminado del sistema operativo.Utilice el parámetro ncp.dla.scratchDirectory para definir la vía de acceso completa a undirectorio temporal escribible, por ejemplo ncp.dla.scratchDirectory=/opt/space/temp.

4. Establezca los objetos CDM para los que desea generar datos. Utilice el parámetroncp.dla.generationFilter para especificar los valores en una lista separada por comas. Losposibles valores son los siguientes:

• ComputerSystem: genera los siguientes datos para dispositivos:

– ComputerSystem– SnmpSystemGroup– OperatingSystem– IpInterface para IpDevice, dispositivos sin acceso SNMP– Direccionador– Puente

• LTE: genera los siguientes datos para las clases LTE:

– Función– HomogeneousCollection




– Zona– Tarjeta– NetworkInterface

• Networking: genera los siguientes datos para redes:

– L2Interface– IpInterface– IpV4Address– IpV6Address– IpNetwork

• Physical: genera los siguientes datos para las clases físicas:

– PowerSupply– Ventilador– Chasis– Sensor– PhysicalPackage– Tarjeta– Tarjeta hija

Para generar datos, debe añadir un valor mediante el siguiente formato para el parámetroncp.dla.generationFilter parameter:

ncp_dla.generationFilter=ComputerSystem[,data]

Donde data es uno de los tipos específicos de datos enumerados en este paso.

Ejemplos:

• Para generar datos del sistema, añada los siguientes valores al parámetro:

ncp_dla.generationFilter=ComputerSystem

Nota: Cómo mínimo, debe especificar este valor. Si no especifica ningún valor en el parámetroncp.dla.generationFilter, el DLA no generará datos.

• Para generar datos LTE y de sistema, añada los siguientes valores al parámetro:

ncp_dla.generationFilter=ComputerSystem,LTE

• Para generar datos relacionados con la conectividad de red y de sistema, añada los siguientesvalores al parámetro:

ncp_dla.generationFilter=ComputerSystem,Networking

5. Opcional: Puede definir el URL para utilizar con el inicio contextual en otros sistemas. Defina elparámetro ncp.dla.contextualLaunchURL con el valor de topología que desea iniciar yespecifique el nombre de host y el puerto para el servidor de topología Topoviz. El valorpredeterminado es iniciarlos en la Vista de saltos.Por ejemplo, para configurar el inicio contextual en el Navegador de estructura:

ncp.dla.contextualLaunchURL=https://hostname:16316/ibm/console/ncp_structureview/Launch.do?entityId=

6. Opcional: Si cambia el valor de ncp.dla.datasource.autoConnect a "false", especifique losdetalles de acceso de RDBMS editando los siguientes parámetros que definen la base de datos a laque se conecta el DLA para generar libros de biblioteca de descubrimiento:


ncp.dla.datasource.typeEspecifique el tipo de RDBMS, el valor predeterminado es Db2:

• Db2

• Oracle

ncp.dla.datasource.driverEspecifique el controlador JDBC que se va a utilizar:

• com.ibm.db2.jcc.Db2Driver

• oracle.jdbc.driver.OracleDriver

ncp.dla.datasource.urlEspecifique el URL de JDBC para conectarse a la base de datos NCIM:

• jdbc:db2://nombre_host:número_puerto/nombre_basedatos

• jdbc:oracle:thin:@//nombre_host:número_puerto/nombre_serviciodonde nombre_servicio es el nombre del servicio de Oracle que hace referencia a la instancia debase de datos de Oracle que se ejecuta en el servidor.

ncp.dla.datasource.schemaEl nombre del esquema de la base de datos de NCIM, normalmente "ncim"

ncp.dla.datasource.ncpgui.schemaEl nombre del esquema de la base de datos de NCPGUI, normalmente "ncpgui"

ncp.dla.datasource.usernameEl nombre de usuario de la base de datos, normalmente "ncim"

ncp.dla.datasource.passwordLa contraseña de usuario de la base de datos

ncp.dla.datasource.encryptedSi la contraseña de la base de datos está cifrada [true|false]Si se establece en true, debe especificar un valor válido para ncp.dla.datasource.keyFile ydebe utilizar la contraseña cifrada a la que se hace referencia en su archivo$NMGUI_HOMEprofile/etc/tnm/tnm.properties.

ncp.dla.datasource.keyFileEspecifique la vía de acceso completa y el nombre del archivo de claves criptográficas que seutiliza en el archivo $NMGUI_HOMEprofile/etc/tnm/tnm.properties.

ncp.dla.datasource.loginTimeoutTiempo de espera de inicio de sesión, el valor predeterminado es 5 segundos

7. Utilice el parámetro ncp.dla.refresh.book para especificar si DLA debe renovar los libros debiblioteca de descubrimientos o crear unos nuevos. La opción predeterminada es true; esta opciónpredeterminada actualiza las instancias existentes y crea nuevas, si es necesario.

ncp.dla.refresh.book=true

8. Utilice el parámetro ncp.dla.lte.topology para exportar el control LTE y la topología a nivel deusuario. Esta opción puede producir grandes cantidades de datos para redes grandes. El volumen dedatos generados puede tener un efecto adverso en el despliegue de TADDM. La opciónpredeterminada es false.

ncp.dla.lte.topology=false

9. Opcional: Puede limitar el ámbito de la recopilación de datos a una o más vistas de red configurandoel parámetro ncp.dla.network.view para filtrar únicamente los datos de las vistas de redseleccionadas.Con los operadores SQL estándar, defina un segmento SQL que esté agregado al camponetworkView.name durante la consulta de DLA. El parámetro debe tener un valor que empiece poruno de los siguientes operadores SQL:


• =• <>• !=• IN• NOT IN• LIKE• NOT LIKE

Por ejemplo, el siguiente valor define el ámbito para utilizar únicamente la vista de red Redes deBGP para el ámbito de la recopilación de datos:

ncp.dla.network.view=='BGP Networks'

Nota: El DLA no admite comillas dobles. Todo lo que se encuentra después del signo igual inicial enel ejemplo anterior es parte del valor definido, incluso el segundo signo igual (=).

Otro ejemplo es el siguiente, en el que el ámbito para la recopilación de datos se define comocualquier vista de red que contenga el nombre Cisco (observe el carácter comodín SQL estándar %utilizado):

ncp.dla.network.view=LIKE 'Cisco%'

10. Utilice el parámetro ncp.dla.entity.details para especificar si DLA debe consultar datos dedetalles de entidad y exportar estos datos como un atributo ampliado. La opción predeterminada esfalse.

ncp.dla.entity.details=false

11. Utilice el parámetro ncp.dla.signatureGenExcludeMAC para excluir determinadas direccionesMAC del algoritmo de generación de firma.Esto es útil cuando las direcciones MAC presentes en los dispositivos de red se duplican a través dela red y desea impedir que el proceso de generación de firma genere innecesariamente la mismafirma varias veces.

Para utilizar esta prestación, en cada dirección MAC potencialmente duplicada de la red, debe entraruna propiedad signatureGenExcludeMAC. El formato de esta propiedad es el siguiente:ncp.dla.signatureGenExcludeMAC.n=MAC

Donde:

• n es un número incrementado para cada exclusión comenzando desde 1.• MAC es la dirección MAC delimitada por comas a excluir del proceso de generación de firma.

Por ejemplo, los valores predeterminados en el archivo ncp_dla.properties especifican que se debenexcluir las siguientes direcciones MAC del proceso de generación de firma:

• 00:00:00:00:00:00, que es una dirección MAC predeterminada de todo ceros.• 02:00:00:00:00:04, que es una dirección MAC de interfaz interna Juniper fpx1.• 00:0B:CA:FE:00:00, que es una dirección MAC de interfaz de gestión Juniper bme0.

ncp.dla.signatureGenExcludeMAC.1=00:00:00:00:00:00ncp.dla.signatureGenExcludeMAC.2=02:00:00:00:00:04ncp.dla.signatureGenExcludeMAC.3=00:0B:CA:FE:00:00

12. Utilice el parámetro ncp.dla.signatureOverride para configurar manualmente la firma utilizadapor DLA por dispositivo, ignorando de esta manera la generación de firma automatizada.Esto es útil cuando los dispositivos exportados por DLA no están reconciliados adecuadamentedentro de TADDM, como cuando el atributo de firma es diferente para el mismo dispositivo.

Para utilizar esta prestación, para cada dispositivo cuya firma desee sobrescribir, debe conocer lasiguiente información:


a. Network ManagerentityNameb. Firma de TADDMc. Propiedad SignatureOverride

El formato de esta propiedad es el siguiente:ncp.dla.signatureOverride.n=entityName=signature

Donde:

• n es un número incrementado para cada sustitución comenzando desde 1.• entityName es el Network Manager entityName del dispositivo al que se va a aplicar la firma.• signature es una firma de CDM válida de la dirección IP de formulario (dirección MAC) o dirección

IP.

Nota: Debe asegurarse de que elige una dirección MAC e IP de firma relacionada con el dispositivoespecificado cuando utilice esta prestación.

Por ejemplo, para sustituir la firma para los dispositivos "fred" y "barney", añada las siguientespropiedades de configuración:

ncp.dla.signatureOverride.1=fred=172.20.1.6(00:21:28:FF:1A:3A)ncp.dla.signatureOverride.2=barney=172.20.1.7(00:21:EE:6B:1A:2A)

13. Especifique cómo se deben transferir los libros de la biblioteca de descubrimiento generados por elDLA especificando el siguiente parámetro:ncp.dla.datasink.type

Cómo se transfieren los libros de la biblioteca de descubrimiento. Las opciones son lassiguientes:ARCHIVO

Los libros de la biblioteca de descubrimiento se copian de forma local en el directorio dedestino /opt/IBM/netcool/core/var/precision/ccmdb. Si especifica esta opción,omita el paso “14” en la página 114 y siga con el paso “17” en la página 115.

FTPLos libros de la biblioteca de descubrimiento se transfieren a un servidor remoto medianteFTP. Si especifica esta opción, debe completar el paso “14” en la página 114

ncp.dla.datasink.targetDirectoryEl directorio de destino para los archivos de libros de biblioteca de descubrimiento

Nota: Si está ejecutando el DLA en un servidor diferente del servidor de la GUI y desea situar loslibros generados por ese servidor, puede especificar los parámetros de conexión en el archivoncp_dla.properties eliminando los comentarios y editando los parámetros enncp.dla.datasink.targetDirectory.

14. Opcional: Si ha especificado la opción FTP para la propiedad ncp.dla.datasink.type,especifique los siguientes parámetros adicionales:ncp.dla.datasink.server

La dirección IP o el nombre de host del servidor FTP remoto.ncp.dla.datasink.port

El puerto TCP que se va a utilizar, valor predeterminado 21ncp.dla.datasink.binary

Si se deben utilizar las transferencias FTP binarias [true|false]ncp.dla.datasink.passive

Si se deben realizar las transferencias FTP pasivas [true|false]ncp.dla.datasink.username

El nombre de usuario de FTP que se va a utilizarncp.dla.datasink.password

La contraseña de usuario de FTP que se va a utilizar


ncp.dla.datasink.encryptedSi la contraseña FTP está cifrada o no [true|false]

ncp.dla.datasink.keyFileEspecifique la vía de acceso completa y el nombre del archivo de claves criptográficas que seutiliza en el archivo $NMGUI_HOMEprofile/etc/tnm/tnm.properties.

15. Opcional: Puede limitar el ámbito de la recopilación de datos filtrando los resultados poridentificadores de chasis. Realice esta tarea especificando una consulta SQL con el parámetroncp.dla.chassis.ids.

La especificación de un filtro utilizando la propiedad ncp.dla.chassis.ids le permite recuperarsolamente los registros de ComputerSystem que coinciden con el ID de entidad devueltos por laconsulta SQL.

Nota: Este método de filtrado es preferible a filtrar utilizando el parámetroncp.dla.network.view, ya que le permite especificar con más precisión el chasis de interés.

El siguiente ejemplo muestra una consulta SQL que devuelve los identificadores de chasis que se hancodificado en el límite de la red.

Nota: Para facilitar la lectura, esta consulta SQL se presenta sangrada en varias líneas. Sin embargo,en el archivo de configuración ncp_dla.properties, toda la consulta SQL debe aparecer en unasola línea; de lo contrario la operación devolverá un error.

ncp.dla.chassis.ids=SELECT e.mainNodeEntityId FROM entity e INNER JOIN domainMgr d ON d.domainMgrId = e.domainMgrId WHERE d.domainName = 'NCPPUP' AND EXISTS (SELECT ed.entityId FROM entityDetails ed WHERE ed.entityId = e.entityId AND ed.keyName = 'NetworkEdge' AND ed.keyValue = 1) GROUP BY e.mainNodeEntityId

16. Opcional: Puede excluir la información de modelo y fabricante de la salida utilizando los parámetrosncp.dla.ExcludeModel y ncp.dla.ExcludeManufacturer.

El formato de estos parámetros es el siguiente:

ncp.dla.ExcludeModel.N=MODEL_NAMEncp.dla.ExcludeManufacturer.N=MANUFACTURER_NAME

Donde:

• N es un número que se incrementa para cada exclusión, empezando desde 1.• NOMBRE_MODELO es un nombre de modelo a excluir.• NOMBRE_FABRICANTE es un nombre de fabricante a excluir.

Los valores coincidentes se suprimen de la salida.

El ejemplo siguiente muestra cómo excluir los fabricantes Windows y net-snmp.

ncp.dla.ExcludeManufacturer.1=Windowsncp.dla.ExcludeManufacturer.2=net-snmp

17. Especifique el nivel de depuración del DLA especificando un valor para la propiedadlog4j.rootLogger.Los siguientes valores están permitidos; el valor predeterminado es FATAL:

• DEBUG• INFO• WARN• ERROR• FATAL


18. Especifique la vía de acceso completa y el nombre del archivo de registro del DLA especificando unvalor para la propiedad log4j.appender.FILE.file.El valor predeterminado es dla.log. El archivo de registro se escribe en el directorio de instalaciónde DLA.

19. Opcional: La propiedad ncp.dla.validateComputerSystemFqdn en desuso define si validar losnombres de entidades descubiertos por Network Manager como nombres de dominio completos.

PRECAUCIÓN: No cambie el valor. Esta propiedad ha caído en desuso y ya no se utiliza enNetwork Manager versiones 3.9 y posteriores.

Esta propiedad puede llevar uno de los siguientes valores:Verdadero

Este es el valor predeterminado. Los nombres de entidad son validados. El DLA agrega atributosFqdn a las instancias de ComputerSystem solo si el nombre de dispositivo es un nombre dedominio completo válido.

FalsoNo se produce ninguna validación. El DLA agrega atributos Fqdn a las instancias deComputerSystem sin tener en cuenta si el nombre de dispositivo es un nombre de dominiocompleto válido.

20. Cree una copia del archivo de configuración editado y póngale un nombre al archivo de su elección.21. Cree una copia de la configuración para cada dominio de Network Manager para el que desea crear

libros de biblioteca de descubrimiento.

Recuerde: Cree un archivo de configuración para cada dominio de Network Manager para el quedesee generar libros de biblioteca de descubrimiento y agregue el nombre del archivo deconfiguración con el nombre del dominio (por ejemplo, ncp_dla.properties.NCOMS).

Qué hacer a continuaciónSi desea iniciar las GUI de IBM Tivoli Application Dependency Discovery Manager desde NetworkManager, complete las tareas de configuración adicionales para agregar una opción de menú a las GUI deNetwork Manager y agregue el informe de inventario JSP a TADDM.

Creación de un libro de biblioteca de descubrimientoPara crear un libro de biblioteca de descubrimiento, ejecute el adaptador de biblioteca de descubrimiento(DLA) con el archivo de propiedades DLA adecuado.

Antes de empezarAntes de que pueda ejecutar el DLA, se debe configurar correctamente el archivo de propiedades del DLA

Acerca de esta tareaEl DLA tiene dos modalidades de funcionamiento:Modalidad principal

Genera libros de biblioteca de descubrimiento realizando consultas de la base de datos NCIM(Network Connectivity and Inventory Model) para el dominio identificado en el archivo deconfiguración especificado.

Modalidad de importaciónProporciona un medio de importación de los GUID de IBM Tivoli Application Dependency DiscoveryManager de vuelta a la base de datos NCIM, para que la UI de TADDM se pueda abrir desde NetworkManager.

Procedimiento1. Vaya al directorio de instalación del DLA en el servidor de componentes de la GUI de Network

Manager; el valor predeterminado es $NCHOME/precision/adapters/ncp_dla.


2. Ejecute el adaptador de biblioteca de descubrimiento (DLA) y haga referencia al archivo depropiedades DLA adecuado de su dominio para crear un libro de biblioteca de descubrimiento:

./ncp_dla.sh ncp_dla.properties.domain_name [ -getmore ]

Nota: El indicador -getmore es opcional. Genera todas las entidades, incluidos los conmutadoresapilados para los filtros CDM de ComputerSystem.

Consulte “Ejemplo” en la página 117 para obtener un ejemplo de ejecución de mandato y la respuestadel sistema.

Ejemplo

El siguiente ejemplo muestra cómo ejecutar el DLA y la respuesta del sistema:

[[email protected]]# ./ncp_dla.sh ncp_dla.properties.NCOMSncp_DLA ( IBM Tivoli Network Manager IP Edition - Discovery Library Adapter )Copyright (C) 1997 - 2013 By IBM Corporation. All Rights Reserved.See product license for details.

[IDML Generation Mode]Initializing...WARNING: user.install.root not defined, using /opt/IBM/netcool/core/precision/profiles/TIPProfileLoading properties from /opt/IBM/netcool/core/precision/profiles/TIPProfile/etc/tnm/tnm.propertiesFINE: database.type = db2FINE: database.dbname = ITNMFINE: database.jdbc.url = nullFINE: database.host = abc.test.ibm.comFINE: database.port = 50000FINE: database.username = ncimFINE: database.connection.defaultFetchSize = nullFINE: database.connection.propertiesFile = nullFINE: Getting encrypted passwordJun 3, 2013 9:15:09 AM DbConnectionPool getJdbcURLFINE: JDBC URL = jdbc:db2://abc.test.ibm.com:50000/ITNMINFO: HNMXB0006I=JDBC Driver: com.ibm.db2.jcc.Db2DriverINFO: HNMXB0007I=JDBC URL : jdbc:db2://abc.test.ibm.com:50000/ITNMINFO: HNMXB0007I=JDBC URL : jdbc:db2://abc.test.ibm.com:50000/ITNMJun 3, 2013 9:15:10 AM DbConnectionPool getConnectionFINEST: Connection Pool READ has size 0Working on ITNM domain 'NCOMS'...Processing 142 ComputerSystem(s)...% Complete: 0...10...20...30...40...50...60...70...80...90...100Writing IDML Book to '/tmp/dla/ITNMIP39.9.42.16.62.2013-06-03T13.15.11.579Z.refresh.xml'...Shutting down...Finished.

Tareas relacionadasCarga de los libros de biblioteca de descubrimiento y habilitación del inicio bidireccionalTiene que cargar el libro de la Biblioteca de descubrimiento (IdML) enTADDM para que la información dellibro esté disponible para TADDM. La importación del libro también habilita el inicio contextualbidireccional.

Ajuste preciso de la exportación de datosPara proporcionar un conjunto de recursos y relaciones consumibles con otros sistemas desde NetworkManager, puede realizar un ajuste preciso de la recopilación de datos de DLA y exportar. Un ajuste precisode la exportación de datos de Network Manager permite a TADDM y otros consumidores de libros debiblioteca de descubrimiento (IdML) importar solo los recursos y las relaciones necesarias para crear lavinculación adecuada entre los recursos gestionados de forma común. Además, tener solo los datosnecesarios puede facilitar de forma significativa el proceso de exportación-importación.

Acerca de esta tareaPara configurar una exportación y recopilación de datos más con un ajuste más preciso, realice lossiguientes pasos:


Procedimiento1. Descubra la red utilizando Network Manager.2. Ejecute el programa de utilidad de marcado itnmTagNetworkEdgeEntities.pl para identificar las

entidades de límite de red, como se describe en “Identificación de las entidades de límite de red” en lapágina 118.

3. Cree una vista de red filtrada que muestre solo el límite de la red, como se describe en “Creación de unvista de red filtrada para el límite de la red” en la página 119.

4. Edite el archivo de propiedades de DLA ncp_dla.properties.nombre_dominio para incluir elnombre de la vista de red filtrada que ha creado y para asegurarse de que ha definido el parámetroncp.dla.generationFilter como se describe en “Edición del archivo de propiedades DLA paralas entidades de límite” en la página 120.

5. Ejecute el adaptador para crear un libro de biblioteca de descubrimiento, como se describe en“Creación de un libro de biblioteca de descubrimiento para los datos de límite de red” en la página121.

Identificación de las entidades de límite de redUtilice el programa de utilidad itnmTagNetworkEdgeEntities.pl para marcar entidadesdescubiertas como los puertos e interfaces que se encuentran en el límite de la red. Para la mayoría delos casos, puede ejecutar el programa de utilidad para marcar de forma automática las entidades que seconsideran situadas en el límite de la red, lo que a continuación identifica los nodos finales como hosts oservidores que proporcionan o consumen servicios.

Antes de empezarAsegúrese de que Network Manager ha descubierto de forma satisfactoria su red. Los nodos finales sedeben descubrir antes de que pueda utilizar la opción -autoEndNodeTags con el programa de utilidaditnmTagNetworkEdgeEntities.pl.

Acerca de esta tareaPara ejecutar el programa de utilidad para marcar de forma automática las entidades que se consideransituadas en el límite de la red en un dominio:

Procedimiento1. Vaya a NHCOME/precision/scripts/perl/scripts.2. Ejecute itnmTagNetworkEdgeEntities.pl con la opción de línea de mandatos -autoEndNodeTags para el dominio en el que desea que se marquen las entidades. Esto incluye deforma automática nodos finales y los direccionadores y conmutadores conectados directamente a losnodos finales. Por ejemplo, para marcar de forma automática las interfaces que se consideran situadasen el límite de la red en el dominio denominado NCOMS, especifique:

• $NCHOME/precision/bin/ncp_perl itnmTagNetworkEdgeEntities.pl -domain NCOMS-autoEndNodeTags

3. Opcional: Puede utilizar la opción -includeNextHop con la opción -autoEndNodeTags para ir unsalto más adelante con respecto a las entidades del límite. Al utilizar la opción -includeNextHop deforma automática se incluyen las entidades del límite que han sido incluidas al utilizar únicamente -autoEndNodeTags, además de direccionadores o conmutadores conectados directamente a lasentidades del límite. Por ejemplo, para marcar de forma automática estas interfaces, especifique:

• $NCHOME/precision/bin/ncp_perl itnmTagNetworkEdgeEntities.pl -domain NCOMS-autoEndNodeTags -includeNextHop

4. Opcional: También puede determinar qué dispositivos desea que el programa de utilidad considerecomo dispositivo de límite de red basándose en el número de conexiones que tiene el dispositivo.Utilice la opción -autoDegreeTags para marcar dispositivos que se encuentran en el límite de la redsi tiene un determinado número de conexiones. Si solo utiliza la opción -autoDegreeTags por sí


sola, el valor predeterminado es considerar todos los dispositivos con una conexión que se encuentraen el límite de la red.

Si desea especificar un número de conexión mayor, utilice la opción -autoDegreeTags y la opción -degree n al mismo tiempo, donde n es el número máximo de conexiones. Por ejemplo, al ejecutar elsiguiente valor se marcan todos los dispositivos como menor o igual que 2 conexiones:

• $NCHOME/precision/bin/ncp_perl itnmTagNetworkEdgeEntities.pl -domain NCOMS-autoDegreeTags -degree 2

Nota: La opción -autoDegreeTags no se puede utilizar junto con la opción -autoEndNodeTags. Lamodalidad de opción -autoDegreeTags le permite incluir dispositivos como parte de límite de la redque no son considerados dispositivos de nodo final por la opción -autoEndNodeTags. Tambiénproporciona la flexibilidad de filtrar e identificar dispositivos que tienen un número específico deconexiones.

5. Opcional: Puede refinar el marcado estableciendo un número de opciones, como excluir o incluirdispositivos específicos para que no sean marcados o incluir dispositivos que no tengan acceso SNMPpero que tengan conexiones de Capa 2. Para obtener más información sobre todas las opcionesdisponibles, vea la ayuda del programa de utilidad escribiendo:

• $NCHOME/precision/bin/ncp_perl itnmTagNetworkEdgeEntities.pl -help

ResultadosEl programa de utilidad añade un atributo entityDetails->NetworkEdge=1 en la base de datosncimCache.entityData.

Qué hacer a continuaciónAhora, puede crear un vista de red filtrada que solo muestre el límite de su red.

Creación de un vista de red filtrada para el límite de la redCree una vista de red filtrada que muestre únicamente el límite de la red en el dominio basado en elmarcado realizado por el programa de utilidad itnmTagNetworkEdgeEntities.pl.

Antes de empezarConsejo: También puede utilizar esta vista de red filtrada para visualizar y supervisar el límite de la red yver qué datos se exportan utilizando DLA.

Acerca de esta tareaPara crear una vista filtrada del límite de la red:

Procedimiento1. Pulse el icono Incidencia y seleccione Disponibilidad de red > Vista de red > Bibliotecas.

2. Haga clic en Nueva vista .3. Cumplimente el separador General tal como se muestra a continuación:

NombreEscriba un nombre para la vista de red, vista dinámica o contenedor de vista de red.

Importante: Es recomendable usar los nombres de vista de red que contengan caracteres latinos.Los nombres de vistas de red que contienen caracteres no latinos (por ejemplo, cirílicos) no estánadmitidos porque no se pueden importar ni exportar cuando se migran a una nueva versión deNetwork Manager.

PadreSeleccione el nodo en el que aparece la vista en la jerarquía en el Árbol de navegación. Paramostrar la vista en el nivel superior, seleccione Ninguno.


TipoSeleccione Filtrada.

DiseñoSeleccione el diseño Ortogonal, Circular, Simétrico, Jerárquico o Tabular.

Icono de mapaSi desea un icono distinto del icono predeterminado para representar la vista, haga clic en

Examinar para buscar un icono.Icono de árbol

Si desea un icono distinto del icono predeterminado para representar la vista, haga clic en

Examinar para buscar un icono.Imagen de fondo

Haga clic en Examinar para navegar en busca de una imagen que utilizar para la vista.Estilo de fondo

Especifique si la imagen de fondo debe aparecer centrada o en mosaico.Estado de línea

Especifique cómo se deben representar las líneas que representan los enlaces entre dispositivos.Puede seleccionar no mostrar ningún estado, o mostrar el valor predeterminado del sistema. Deforma alternativa, las líneas se pueden colorear según el suceso del Visor de sucesos asociadocon la gravedad más alta, y pueden aparecer con un icono adicional de gravedad.

4. Configure el filtro de la siguiente manera:a) Haga clic en el separador Filtro.b) Desde la lista de Dominio, seleccione el dominio en el que ha ejecutado el programa de utilidad de

marcado.c) En la columna Tabla, seleccione el atributo entityDetailsd) En la columna Filtro, escriba keyName = 'NetworkEdge' and keyValue = '1'.

5. Defina los Nodos finales como Incluir6. Defina la Conectividad como Capa2.7. Haga clic en Aceptar y después en Guardar.

Qué hacer a continuaciónAhora debe incluir el nombre de esta vista de red en el archivo de propiedades DLA para el dominio.

Edición del archivo de propiedades DLA para las entidades de límiteEdite el archivo ncp_dla.properties para el dominio en el que va a incluir el nombre de la vista de redfiltrada que ha creado y asegúrese de que ha configurado los parámetros de generación de datoscorrectos.

Acerca de esta tareaPara editar el archivo:

Procedimiento1. Vaya al archivo de configuración ncp_dla.properties en el directorio de instalación de DLA en$NCHOME/precision/adapters/ncp_dla o donde se encuentre su archivo de propiedades de DLApara el dominio.

2. Abra el archivo ncp_dla.properties.nombre_dominio.


3. Ubique el parámetro ncp.dla.network.view y añada el nombre de la vista de red filtrada que hacreado. Por ejemplo, la vista filtrada denominada "Edge" se tendría que añadir a esta propiedad de lasiguiente manera: ncp.dla.network.view=='Edge'

Nota: El uso del signo igual doble (==) como operador relacional es deliberado.4. Defina el parámetro ncp.dla.generationFilter como ComputerSystem y Networking.

Especifique los valores en una lista separada por comas de la siguiente manera:

ncp_dla.generationFilter=ComputerSystem,Networking

5. Guarde y cierre el archivo.

Qué hacer a continuaciónAhora, puede ejecutar el DLA con el archivo de propiedades DLA actualizado para exportar unsubconjunto de datos de Network Manager.Tareas relacionadasConfiguración del DLAEl adaptador de biblioteca de descubrimiento (DLA) requiere un archivo de propiedades de configuraciónpara determinar el origen de datos al que conectarse, el dominio que consultar, el directorio de destinopara los libros de la biblioteca de descubrimiento y los parámetros de registro.

Creación de un libro de biblioteca de descubrimiento para los datos de límitede redPuede utilizar el adaptador de biblioteca de descubrimiento (DLA) para crear el libro de biblioteca dedescubrimiento que contiene solo los datos para las entidades de límite de red.

Antes de empezarAsegúrese de que ha editado el archivo ncp_dla.properties del dominio para incluir el nombre de lavista de red filtrada que contiene las entidades de límite de red.

Acerca de esta tareaPara crear un libro de DLA que contenga los datos de límite de red:

Procedimiento1. Vaya al directorio de instalación del DLA en el servidor de componentes de la GUI de Network

Manager; el valor predeterminado es $NCHOME/precision/adapters/ncp_dla.2. Ejecute el adaptador de biblioteca de descubrimiento (DLA) para generar el archivo XML del libro con

los datos de las entidades de límite de red marcadas:

./ncp_dla.sh ncp_dla.properties.domain_name [ -getmore ]

Nota: El indicador -getmore es opcional. Genera todas las entidades, incluidos los conmutadoresapilados para los filtros CDM de ComputerSystem.

Por ejemplo, para ejecutar el adaptador para el dominio denominado NCOMS, especifique losiguiente: ./ncp_dla.sh ncp_dla.properties.NCOMS

Ejemplo

El siguiente ejemplo muestra la respuesta del sistema para ejecutar el adaptador para el dominio deNCOMS:

ncp_DLA ( IBM Tivoli Network Manager IP Edition - Discovery Library Adapter )Copyright (C) 1997 - 2011 By IBM Corporation. All Rights Reserved. See product license for details.

[IDML Generation Mode]


Initializing...Will use the following Network View(s) filter : ='FILTER'Working on ITNM domain 'NCOMS'...Processing 1148 IP Network(s)...% Complete: 0...10...20...30...40...50...60...70...80...90...100Processing 772 ComputerSystem(s)...% Complete: 0...10...20...30...40...50...60...70...80...90...100Processing 1 Topology(s)...Processing 2535 Connection(s)...% Complete: 0...10...20...30...40...50...60...70...80...90...100Writing IDML Book to '/opt/netcool/itnm39017/netcool/var/precision/ccmdb/ITNMIP39.9.180.209.195.2010-10-05T13.33.37.314Z.refresh.xml'...Shutting down...Finished.

El resultado es un archivo XML que contiene los dispositivos que participan en la vista de red filtradapreviamente creada y especificada en el archivo ncp_dla.properties para el dominio. El contenido delarchivo XML depende de la configuración del archivo de propiedades de DLA.

El archivo XML contiene los segmentos de Common Data Model (CDM) que describen cómo estánconectados los dispositivos desde la perspectiva de un puerto o interfaz de Network Manager dado. Elproceso elimina los duplicados y normaliza los detalles de conexión. Para obtener más información sobrelos segmentos, consulte la documentación de Tivoli Common Data Model (CDM) disponible en http://www.redbooks.ibm.com/abstracts/redp4389.html.

Los siguientes ejemplos muestran partes de la salida del archivo XML. La interfaz elegida para ser laidentidad de segmento está resaltada en negrita, incluida cada instancia a la que se hace referencia.

• Ejemplo de una conexión de punto a multipunto desde la perspectiva de una interfaz elegida para ser elpunto de inicio de un segmento:

<cdm:net.Segment id="SegmentVia_359525_L2Interface" > <cdm:Name>Layer 2 Segment via 359525_L2Interface</cdm:Name> <cdm:ManagedSystemName>itnmSgmnt:359525_L2Interface</cdm:ManagedSystemName> </cdm:net.Segment> <cdm:networks source="SegmentVia_359525_L2Interface" target="359525_L2Interface" /> <cdm:networks source="SegmentVia_359525_L2Interface" target="358156_L2Interface" /> <cdm:networks source="SegmentVia_359525_L2Interface" target="404607_L2Interface" /> <cdm:networks source="SegmentVia_359525_L2Interface" target="358221_L2Interface" /> <cdm:networks source="SegmentVia_359525_L2Interface" target="358185_L2Interface" /> <cdm:networks source="SegmentVia_359525_L2Interface" target="404595_L2Interface" /> <cdm:networks source="SegmentVia_359525_L2Interface" target="358107_L2Interface" /> <cdm:networks source="SegmentVia_359525_L2Interface" target="357775_L2Interface" /> <cdm:networks source="SegmentVia_359525_L2Interface" target="358232_L2Interface" /> <cdm:networks source="SegmentVia_359525_L2Interface" target="404589_L2Interface" /> <cdm:networks source="SegmentVia_359525_L2Interface" target="358300_L2Interface" />

• Ejemplo de una conexión punto a punto simple:

<cdm:net.Segment id="SegmentVia_355664_L2Interface" > <cdm:Name>Layer 2 Segment via 355664_L2Interface</cdm:Name> <cdm:ManagedSystemName>itnmSgmnt:355664_L2Interface</cdm:ManagedSystemName></cdm:net.Segment> <cdm:networks source="SegmentVia_355664_L2Interface" target="355664_L2Interface" /> <cdm:networks source="SegmentVia_355664_L2Interface" target="357336_L2Interface" />




Carga de los libros de biblioteca de descubrimiento y habilitación del iniciobidireccional

Tiene que cargar el libro de la Biblioteca de descubrimiento (IdML) enTADDM para que la información dellibro esté disponible para TADDM. La importación del libro también habilita el inicio contextualbidireccional.

Acerca de esta tareaAdemás de ser capaz de iniciar elIBM Tivoli Application Dependency Discovery Manager GUI deNetworkManager, también puede configurarTADDM para iniciar la GUI deNetwork Manager.

Para cargar los libros de la biblioteca de descubrimiento en TADDM y establecer el inicio contextualbidireccional:

Procedimiento1. Cree un libro de biblioteca de descubrimiento.2. Si es necesario, transfiera el archivo del libro de biblioteca de descubrimiento a su servidor de TADDM.3. Como usuario de TADDM, ejecute el proceso de carga masiva para importar el libro de la biblioteca de

descubrimiento.Por ejemplo:

user@host% cd $COLLATION_HOME/binuser@host% ./loadidml.sh -x -f full path to and full name of discovery library book file

Atención: Debe incluir la vía de acceso completa al archivo del libro de biblioteca dedescubrimiento, junto con el nombre de archivo completo solo si el libro se encuentra en undirectorio diferente.

4. Importe los GUID de TADDM en la base de datos de NCIM (consulte las tareas relacionadas más tardeen esta sección).

Tareas relacionadasCreación de un libro de biblioteca de descubrimientoPara crear un libro de biblioteca de descubrimiento, ejecute el adaptador de biblioteca de descubrimiento(DLA) con el archivo de propiedades DLA adecuado.Importación de los GUID de IBM Tivoli Application Dependency Discovery Manager en la base de datosNCIMOpcional: Para permitir que los usuarios abran la UI de IBM Tivoli Application Dependency DiscoveryManager desde Network Manager, importe los GUID de TADDM a la tabla entityGUIDCache de la base dedatos NCIM (Network Connectivity and Inventory Model).

Configuración de IBM Tivoli Application Dependency Discovery Managerpara iniciar Network Manager

Opcional: Para ver un resumen de los recursos que Network Manager exporta a IBM Tivoli ApplicationDependency Discovery Manager y abrir Network Manager desde allí, debe agregar un informe JSP.

Acerca de esta tareaImportante: Si está utilizando una versión anterior de TADDM a 7.2.1 Fixpack 1, siga estas instruccionespara instalar y configurar el informe de JSP. Sin embargo, si está utilizando la versión 7.2.1 Fixpack 1 oposterior, ignore estos pasos. En la versión 7.2.1 Fix Pack 1 y posterior, está instalado el informe paramostrar el inventario de Network Manager e iniciar en contexto (o actualizado si ya existe) por lainstalación de TADDM. Para obtener más información, consulte la documentación de en http://www.ibm.com/support/knowledgecenter/SSPLFC/welcome.




Se proporciona el informe de JSP; para utilizar el informe, los archivos se tienen que copiar a la ubicacióncorrecta en su servidor TADDM.

Procedimiento1. Inicie la sesión en el servidor de TADDM.2. Asegúrese de que la variable de entorno $COLLATION_HOME esté establecida correctamente.3. Copie el archivo directorio_instalación_dla/integration/itnm_inventory.jsp del

servidor de componentes GUI de Network Manager al directorio $COLLATION_HOME/deploy-tomcat/reports/WEB-INF/view en el servidor TADDM.

4. Copie los dos archivos GIF (tivoli.gif e ibm_logo.gif) del directoriodirectorio_instalación_dla/integration/itnm_images del servidor de componentes GUIde Network Manager al directorio $COLLATION_HOME/deploy-tomcat/images en el servidor deTADDM.

5. Detenga el servidor de TADDM.6. Edite el archivo $COLLATION_HOME/etc/cdm/xml/reports.xml y agregue la siguiente sección

antes de la etiqueta de cierre </beans>:

<bean class="com.collation.cdm.reports.viewer.JspReportViewer" id="ITNMInventoryReport"> <property name="reportGroup"> <value>Inventory Reports</value> </property> <property name="reportName"> <value>ITNM IP Inventory Report</value> </property>  <property name="jsp"> <value>/WEB-INF/view/itnm_inventory.jsp</value>

</property> </bean>

7. Reinicie el servidor de TADDM.

ResultadosEl Network Manager Informe de inventario se muestra en la consola de TADDM Domain Manager. Elinforme consta de las secciones siguientes:

• Resumen de servidor: Proporciona información sobre las instancias instaladas del producto NetworkManager, incluidas las versiones de Network Manager instaladas, las direcciones de host de losservidores donde se ha instalado Network Manager y los URL para acceder a la GUI de NetworkManager.

• Resumen de recursos: Muestra todos los recursos de Network Manager que tienen una relación con unComputerSystem, incluida la información sobre su dirección IP, fabricante, tipo de recurso (por ejemplo,direccionador) y un identificador exclusivo en la base de datos de Network Manager.

Configuración de Network Manager para iniciar IBM Tivoli ApplicationDependency Discovery Manager

Opcional: Para habilitar los operadores de red para iniciar la GUI de IBM Tivoli Application DependencyDiscovery Manager desde Network Manager, debe configurar las opciones de menú de TADDM enNetwork Manager.

Antes de empezarLos pasos siguientes dan por sentado que el adaptador de biblioteca de descubrimiento (DLA) estáinstalado en el mismo servidor que Dashboard Application Services Hub y que los componentes de la GUIde Network Manager. Si el DLA está instalado en otro lugar, debe copiar el directorio de instalación deDLA y su contenido en el servidor donde están instalados Dashboard Application Services Hub y loscomponentes de GUI de Network Manager.

Para obtener más información sobre IBM Tivoli Application Dependency Discovery Manager, consulte:http://www.ibm.com/support/knowledgecenter/SSPLFC/welcome

Procedimiento1. Configure los puntos de inicio del menú para la instalación de TADDM:

a) Edite el archivo siguiente: $NMGUI_HOMEprofile/etc/tnm/tnm.properties

i) Actualice la propiedad tnm.taddm.serverName a la dirección IP o al nombre de host delservidor TADDM.

ii) Actualice la propiedad tnm.taddm.serverPort al puerto TCP en el que está escuchando elservidor TADDM.

iii) Actualice las propiedades tnm.taddm.username y tnm.taddm.password con el nombre deusuario y la contraseña (sin codificar) para acceder a su servidor TADDM.

b) Opcional: Para configurar TADDM y que se inicie en la misma ventana que Network Manager, editeel campo de destino de la propiedad url en cada archivo de definición de la herramienta.De forma predeterminada, TADDM se inicia en una nueva ventana.Por ejemplo, para visualizar los detalles de CCMDB en la misma ventana, edite la propiedad en elarchivo ncp_wt_ccmdb_details.xml de la siguiente manera:

target="ccmdbDetails'"

2. Compruebe que el submenú de TADDM se haya agregado a Network Manager:a) Inicie sesión en Network Manager.b) Haga clic en Disponibilidad de red > Vistas de redc) Seleccione una vista de red y haga clic con el botón derecho en un dispositivo.

En el menú contextual, los siguientes elementos de menú de TADDM se deben mostrar bajo Iniciaren... > TADDM/CCDMB:

Ver detallesVer historial

Nota: Puede tardar algunos minutos para que los cambios surtan efecto. Si los cambios no surtidoefecto en 5 minutos, cierre sesión, reinicie el navegador y vuelve a iniciar sesión de nuevo.

Qué hacer a continuaciónAhora deberá importar los GUID de TADDM a la base de datos de NCIM.Tareas relacionadasImportación de los GUID de IBM Tivoli Application Dependency Discovery Manager en la base de datosNCIMOpcional: Para permitir que los usuarios abran la UI de IBM Tivoli Application Dependency DiscoveryManager desde Network Manager, importe los GUID de TADDM a la tabla entityGUIDCache de la base dedatos NCIM (Network Connectivity and Inventory Model).



Importación de los GUID de IBM Tivoli Application Dependency DiscoveryManager en la base de datos NCIM

Opcional: Para permitir que los usuarios abran la UI de IBM Tivoli Application Dependency DiscoveryManager desde Network Manager, importe los GUID de TADDM a la tabla entityGUIDCache de la base dedatos NCIM (Network Connectivity and Inventory Model).

Procedimiento1. Ejecute el DLA para que los recursos y relaciones de Network Manager se importen a TADDM.2. Inicie sesión en el servidor en el que están instalados los componentes de Network Manager y copie el

directorio de integración de DLA y el contenido de ITNMHOME/adapters/ncp_dla/integrationen el servidor de TADDM (por ejemplo, $COLLATION_HOME/sdk/dla/integration). Asegúrese deque los permisos estén establecidos para que el usuario de TADDM pueda acceder a los archivos.

3. En el servidor de TADDM, vaya al directorio en el que ha copiado los archivos.4. Como usuario de TADDM, utilice la API de TADDM para consultar el CCMDB para los datos de

ComputerSystem y canalizar los resultados a un archivo XML denominado itnm_guids.xml.Por ejemplo:

user@host% $COLLATION_HOME/sdk/bin/api.sh -u user_name -p password find ComputerSystem > itnm_guids.xml

5. Asegúrese de que los archivos itnm_guids.xsl e itnm_guids.xml existen en el directorio actual.6. Como usuario de TADDM, utilice el procesador XLST para extraer los entityId y los GUID y canalizarlos

a un archivo CSV denominado itnm_guids.csv.Por ejemplo:

user@host% $COLLATION_HOME/sdk/bin/xslt.sh -XSL ./itnm_guids.xsl > itnm_guids.csv

7. Copie el archivo itnm_guids.csv de nuevo en el servidor GUI de Network Manager en el directoriode inicio o en el directorio de ITNMHOME/adapters/ncp_dla.

8. Ejecute el DLA en modalidad de importación para importar los archivos CSV a la base de datos NCIMde Network Manager.Consulte “Ejemplo” en la página 126 para obtener un ejemplo de cómo ejecutar en modalidad deimportación y de cómo es la respuesta del sistema.

Ejemplo

El siguiente ejemplo muestra cómo ejecutar el DLA en modalidad de importación y cómo responde elsistema.

user@host% cd /opt/IBM/DiscoveryLibrary/ITNMuser@host% [./ncp_dla.sh | ncp_dla.bat ] -import-file integration/itnm_guids.csv ncp_dla.properties.Db2ncp_DLA ( IBM Tivoli Network Manager IP Edition - Discovery Library Adapter )Copyright (C) 1997 - 2007 By IBM Corporation. Reservados todos los derechos. See product license for details.

[GUID Import Mode]Initializing...Importing GUIDs from 'integration/itnm_guids.csv'Imported 15 GUID(s) into NCIM.Shutting down...Finished.user@host%

Tareas relacionadasCarga de los libros de biblioteca de descubrimiento y habilitación del inicio bidireccionalTiene que cargar el libro de la Biblioteca de descubrimiento (IdML) enTADDM para que la información dellibro esté disponible para TADDM. La importación del libro también habilita el inicio contextualbidireccional.


Integración con TBSMNetwork Manager está integrado con IBM Tivoli Business Service Manager de manera predeterminadautilizando la Sonda para Tivoli Netcool/OMNIbus (nco_p_ncpmonitor).

Antes de empezarDebe tener IBM Tivoli Network Manager IP Edition e IBM Tivoli Business Service Manager instalados yconfigurados.

ResultadosLa sonda proporciona IBM Tivoli Business Service Manager con señales BSM_Identity para NetworkManager.

La señal BSM_Identity es utilizada de forma predeterminada por TBSM para asociar sucesos conrecursos. Al utilizar el DLA de Network Manager, TBSM es consciente de los recursos de NetworkManager.

Los sucesos de Network Manager tendrán el campo BSM_Identity agregado en el siguiente valor delarchivo de $NCHOME/probes/arch/nco_p_ncpmonitor.rules:

@BSM_Identity = "ITNMIP:" + $ExtraInfo_MONITOREDENTITYID + "&domain=" + $Domain

Referencia relacionadaRequisitos previos para utilizar el DLAAntes de configurar y utilizar el adaptador de biblioteca de descubrimiento (DLA), asegúrese de que secumplen los requisitos previos.

Configuración de Dashboard Application Services HubDespués de la instalación, puede configurar la seguridad de Dashboard Application Services Hub orealizar un inicio de sesión único. Puede encontrar información acerca de la configuración de DashboardApplication Services Hub en el Knowledge Center de Jazz for Service Management.

Acerca de esta tareaEl Knowledge Center de Jazz for Service Management está ubicado en https://www.ibm.com/support/knowledgecenter/SSEKCU

Integración con IBM Tivoli MonitoringPuede instalar IBM Tivoli Monitoring for IBM Tivoli Network Manager IP Edition para supervisar el estadode la instalación de Network Manager.

Antes de empezarDebe tener instalado Network Manager antes de instalar IBM Tivoli Monitoring for IBM Tivoli NetworkManager IP Edition.

Acerca de esta tareaPara obtener instrucciones sobre cómo instalar y configurar IBM Tivoli Monitoring for IBM Tivoli NetworkManager IP Edition, consulte la Guía del usuario de IBM Tivoli Monitoring for IBM Tivoli Network ManagerIP Edition.

IBM Tivoli Monitoring for IBM Tivoli Network Manager IP EditionIBM Tivoli Monitoring for IBM Tivoli Network Manager IP Edition es un agente que se ejecuta en elservidor donde está instalado Network Manager.




El agente funciona con IBM Tivoli Monitoring y proporciona las siguientes funciones:

• Supervisar IBM Tivoli Network Manager IP Edition (Network Manager) para ver si se producen alertas enlos sistemas que esté gestionando mediante el uso de situaciones predefinidas o personalizadas.

• Establecer sus propios umbrales de rendimiento.• Rastrear las causas que han ocasionado una alerta.• Recopilar información completa sobre las condiciones del sistema.• Utilizar políticas para realizar acciones, planificar trabajos y automatizar tareas manuales.

El agente se gestiona de la misma forma y mediante las mismas GUI que otros agentes de IBM TivoliMonitoring.

Tivoli Enterprise Portal Es la interfaz de los productos IBM Tivoli Monitoring. Puede utilizar la vistaconsolidada de su entorno que proporciona Tivoli Enterprise Portal para supervisar y resolver problemasde rendimiento.

Instalación y configuraciónInstale IBM Tivoli Monitoring, aplique el soporte de aplicaciones a los componentes de IBM TivoliMonitoring y, a continuación, instale y configure IBM Tivoli Monitoring for IBM Tivoli Network Manager IPEdition.

Acerca de esta tareaTo install and configure IBM Tivoli Monitoring for IBM Tivoli Network Manager IP Edition, complete thefollowing steps in order:

Procedimiento1. Instale y configure una versión compatible de IBM Tivoli Monitoring. Utilice los procedimientos

incluidos en IBM Tivoli Monitoring: Guía de instalación y configuración.2. Compruebe los requisitos del agente de IBM Tivoli Monitoring for IBM Tivoli Network Manager IP

Edition. Utilice la información incluida en “Requisitos para la instalación del agente de supervisión” enla página 132.

3. Aplique soporte de aplicaciones en todos los servidores donde se hayan instalado los componentes deIBM Tivoli Monitoring. Utilice los procedimientos descritos en la sección “Instalación de soporte deaplicaciones ” en la página 128.

4. Instale el agente de IBM Tivoli Monitoring for IBM Tivoli Network Manager IP Edition.Utilice losprocedimientos descritos en “Instalación del agente de supervisión ” en la página 132.

Qué hacer a continuaciónConfigure el agente de IBM Tivoli Monitoring for IBM Tivoli Network Manager IP Edition. Utilice losprocedimientos descritos en “Configuración del agente de supervisión ” en la página 134.

Instalación de soporte de aplicacionesEl soporte de aplicaciones garantiza la comunicación entre IBM Tivoli Monitoring for IBM Tivoli NetworkManager IP Edition y IBM Tivoli Monitoring.

Antes de empezarLa aplicación del soporte de aplicaciones implica la detención y el reinicio de componentes de IBM TivoliMonitoring. Trabaje con el administrador de IBM Tivoli Monitoring para elegir un momento adecuado parahacerlo.


Acerca de esta tareaInstale el soporte de aplicaciones en los siguientes componentes de IBM Tivoli Monitoring, quealmacenan y analizan los datos recibidos desde el agente.

• Tivoli Enterprise Monitoring Server• Tivoli Enterprise Portal Server• Cliente de escritorio de Tivoli Enterprise Portal• Navegador de Tivoli Enterprise Portal (se aplica a la versión UNIX del navegador)

Esta tarea describe cómo instalar el soporte de aplicaciones en un servidor local. Para obtenerinformación acerca de la configuración del soporte de aplicaciones en servidores remotos, consulte IBMTivoli Monitoring: Guía de instalación y configuración.

Instalación del soporte de aplicaciones en Linux y AIXLa instalación de soporte de aplicaciones en Linux y AIX implica distintos pasos para otras plataformas.

Acerca de esta tareaEl soporte de aplicaciones se soporta en las mismas versiones de Linux y AIX que soporta NetworkManager.











Para aplicar el soporte de aplicaciones para componentes IBM Tivoli Monitoring en sistemas Linux y AIX,complete los siguientes pasos.

Procedimiento1. En el servidor donde está instalado IBM Tivoli Monitoring, descargue el paquete de instalación de

IBM Tivoli Monitoring for IBM Tivoli Network Manager IP Edition.2. Descomprima el paquete de instalación.3. Inicie el asistente de instalación utilizando el script install.sh en el directorio ITMAgent.4. Acepte el directorio de instalación sugerido.


La instalación encuentra el directorio de instalación de IBM Tivoli Monitoring y lo muestra. Pordefecto, la ubicación es /opt/IBM/ITM, pero podría ser diferente si IBM Tivoli Monitoring se hainstalado en una ubicación diferente.

5. Confirme que todo es correcto para reiniciar los procesos existentes.6. Seleccione Instalar productos en el host local.7. Acepte la clave predeterminada, IBMTivoliMonitoringEncryptionKey, a menos que utilice una

clave diferente para cada producto.8. Acepte el acuerdo de licencia.9. Especifique un paquete de soporte de aplicación para instalarlo. La lista de paquetes de soporte varía

en función de su sistema operativo y de los componentes de IBM Tivoli Monitoring instalados. Instaletodos los paquetes de soporte de la muestra.

10. Si Tivoli Enterprise Portal Server, Tivoli Enterprise Monitoring Server, Tivoli Enterprise Portal Desktopy Tivoli Enterprise Portal Browser están instalados en la misma máquina, configure el soporte deagente para todas estas aplicaciones mediante un script.

Restricción: Utilice esta opción sólo si todos los componentes están instalados en el mismo servidor.

a) Vaya al directorio IBM Tivoli Monitoring.b) Si no utiliza el /opt/IBM/ITM predeterminado, establezca CANDLE_HOME en el directorio de

instalación de IBM Tivoli Monitoring.c) Ejecute el script setupITNMAgentSupport.sh.

11. Si algunos de los componentes de IBM Tivoli Monitoring están instalados en distintos servidores,complete los siguientes pasos en los servidores correspondientes:

12. Si Tivoli Enterprise Monitoring Server está instalado en un servidor diferente, ejecute los siguientesmandatos en el servidor desde el directorio $ITMHOME/bin, donde ITMHOME es el directorio dondeestá instalado IBM Tivoli Monitoring:a) Si no lo ha iniciado todavía, inicie el servidor de supervisión utilizando el siguiente mandato,

donde nombre_tems es el nombre del servidor de supervisión. Puede averiguar el nombre delservidor de supervisión buscando el valor de Nombre de TEMS en la pantalla de configuracióndel servidor de supervisión.

./itmcmd server start tems_name

b) Active el soporte de aplicación en el servidor de supervisión utilizando el mandato siguiente.

./itmcmd support -f install -t tems_name np

c) Detenga el servidor de supervisión utilizando el mandato siguiente:

./itmcmd server stop tems_name

d) Reinicie el servidor de supervisión utilizando el mandato siguiente:

./itmcmd server start tems_name

13. Si Tivoli Enterprise Portal Server está instalado en un servidor diferente, ejecute los siguientesmandatos en el servidor desde el directorio $ITMHOME/bin, donde ITMHOME es el directorio dondeestá instalado IBM Tivoli Monitoring.a) Detenga el servidor de portal con el siguiente mandato:

./itmcmd agent stop cq

b) Configure el servidor del portal con la nueva información de agente utilizando el mandatosiguiente:

./itmcmd agent stop cq

c) Reinicie el servidor de portal utilizando el mandato siguiente:


./itmcmd agent start cq

14. Si Tivoli Enterprise Portal Desktop está instalado en un servidor diferente, ejecute los siguientesmandatos en el servidor desde el directorio $ITMHOME/bin, donde ITMHOME es el directorio dondeestá instalado el cliente de escritorio.a) Detenga el servidor de cliente utilizando el mandato siguiente:

./itmcmd agent start cq

b) Configure el cliente de escritorio con la nueva información de agente utilizando el mandatosiguiente:

./itmcmd config -A cj

c) Reinicie el cliente de escritorio utilizando el mandato siguiente:

./itmcmd agent start cj

d) Reinicie cualquier cliente de Web Start Tivoli Enterprise Portal para ver los espacios de trabajo delagente nuevo.

Instalación del soporte de aplicaciones en WindowsLa instalación del soporte de aplicaciones en Windows implica distintos pasos respecto de otros sistemasoperativos.

Acerca de esta tareaEl soporte de aplicaciones se soporta en las mismas versiones de Windows que soporta IBM TivoliMonitoring. Consulte la documentación para su versión de IBM Tivoli Monitoring para obtener másinformación sobre las versiones soportadas de Windows.

Para aplicar el soporte de aplicaciones para componentes IBM Tivoli Monitoring en sistemas Windows,complete los siguientes pasos.

Procedimiento1. En el servidor donde está instalado IBM Tivoli Monitoring, descargue el paquete de instalación de IBM

Tivoli Monitoring for IBM Tivoli Network Manager IP Edition.2. Descomprima el paquete de instalación.3. Cambie al directorio ITMagent/windows/ y ejecute el archivo setup.exe al iniciar el agente.4. Acepte la recomendación para la versión de JRE.5. Acepte el directorio de instalación sugerido. Por defecto, la ubicación es /opt/IBM/ITM, pero podría

ser diferente si IBM Tivoli Monitoring se ha instalado en una ubicación diferente.6. Si no tiene una clave personalizada del producto, acepte la clave predeterminada,IBMTivoliMonitoringEncryptionKey.

7. Seleccione uno o más de los siguientes componentes para aplicar el soporte de aplicaciones. Loscomponentes solo se muestran si están instalados en el servidor actual.

• Tivoli Enterprise Monitoring Server• Tivoli Enterprise Portal Server• Cliente de escritorio de Tivoli Enterprise Portal

Seleccione IBM Tivoli Network Manager para cada opción que haya seleccionado. Si lainfraestructura no está instalada en el sistema, seleccione también el Infraestructura de agenteTEMA para cada opción que ha seleccionado.


Instalación del agente de supervisiónInstale el agente de supervisión en el servidor en el que están instalados los componentes principales deNetwork Manager.

Acerca de esta tareaInstale el agente una vez. Configure una instancia del agente para cada dominio de Network Manager.

Requisitos para la instalación del agente de supervisiónAdemás de los requisitos descritos en la documentación de instalación de IBM Tivoli Monitoring, IBMTivoli Monitoring for IBM Tivoli Network Manager IP Edition tiene los siguientes requisitos.

Software de requisito previoInstale el siguiente software de requisito previo antes de instalar el agente de supervisión:

• IBM Tivoli Monitoring V6.3 Fix Pack 1 o posterior• Tivoli Enterprise Portal V6.3 Fix Pack 1 o posterior

Requisitos de tamañoUn servidor único que aloje el servidor de supervisión, el servidor de portal y un agente de supervisiónprecisa de unos 300 MB de espacio.

Un servidor que albergue únicamente el agente de supervisión precisa de unos 30 MB de espacio,incluido el código de habilitación específico para el agente de supervisión. Se necesita más espacio paracada agente de supervisión adicional que se despliegue en el sistema de supervisión.

Sistemas operativos soportadosEl agente de supervisión se puede instalar en cualquier de los sistemas operativos compatibles conNetwork Manager 4.2.









Desde el Fix Pack 3 al Fix Pack 5, se admiten las siguientes versiones en Linux en IBM zSystems:







Están soportados el siguiente hipervisor y combinaciones de sistemas operativos:

• VMware ESX 5.0, 5.5, 6.0:

– Red Hat Enterprise Linux Server 7 (x86-64)– SuSE Linux Enterprise Server (SLES) 11.0 (x86-64) SP2 y SP3

– SuSE Linux Enterprise Server (SLES) 12.0 (x86-64)

Requisitos para realizar búsquedas en la ayuda en líneaPara poder utilizar la función de búsqueda con la ayuda en línea de este agente de supervisión, asegúresede marcar la casilla Servidor de ayuda de IBM Eclipse al instalar Tivoli Enterprise Portal Server.

El tema "Ayuda del agente de búsqueda" de la ayuda en línea para este agente de supervisión contiene unenlace a la ayuda de Eclipse, en la que la función de búsqueda está habilitada. En la tabla de contenidosdel panel situado a la izquierda de la ayuda, seleccione el tema "Búsqueda de la ayuda del agente" parabuscar el enlace a la ayuda de Eclipse en el panel que se encuentra a la derecha.

Instalación del agente de supervisión en un servidor localComplete estos pasos para instalar y configurar el agente de supervisión en el servidor de NetworkManager.

Antes de empezarSi está utilizando Red Hat Enterprise Linux 7 o SuSE Linux Enterprise Server 12, ejecute el siguientemandato antes de instalar, desinstalar, iniciar o detener el agente de supervisión:

setarch $(uname -m) --uname-2.6

Procedimiento1. En el servidor donde desee instalar el agente de supervisión, descargue el paquete de instalación

para IBM Tivoli Monitoring for IBM Tivoli Network Manager IP Edition.2. Descomprima el paquete de instalación.3. Inicie el asistente de instalación utilizando el script install.sh en el directorio ITMAgent.4. Acepte el directorio de instalación sugerido.

La instalación encuentra el directorio de instalación de IBM Tivoli Monitoring y lo muestra. Pordefecto, la ubicación es /opt/IBM/ITM, pero podría ser diferente si IBM Tivoli Monitoring se hainstalado en una ubicación diferente.

5. Seleccione Instalar productos en el host local.6. Acepte el acuerdo de licencia.7. Acepte la clave predeterminada, IBMTivoliMonitoringEncryptionKey, a menos que utilice una

clave diferente para cada producto.8. Si ejecuta el instalador como usuario no root, especifique la contraseña root para que el agente

pueda reiniciarse automáticamente.


9. Especifique un sistema operativo o un paquete de soporte de aplicaciones para instalarlo. Esta listavaría en función de su sistema operativo y de si está instalado o no algún componente de IBM TivoliMonitoring. Acepte el valor predeterminado o elija el sistema operativo de la lista.

10. Seleccione Todas las anteriores de las opciones listadas a continuación.

• IBM Tivoli Network Manager• Interfaz de usuario de Tivoli Enterprise Services• Todas las anteriores

11. Cuando se le soliciten productos adicionales, seleccione No para salir de la instalación.

Qué hacer a continuaciónConfigure una instancia del agente para cada dominio.

Configuración del agente de supervisiónInstale el agente sólo una vez, pero configurw una instancia del agente para cada dominio NetworkManager.

Acerca de esta tareaConsulte la documentación de IBM Tivoli Monitoring para obtener información acerca de la configuracióndel agente de supervisión utilizando el mandato itmcmd config; la interfaz de usuario Manage TivoliMonitoring Services; o Tivoli Enterprise Portal.

Para configurar el agente desde la línea de mandatos, complete los siguientes pasos:

Procedimiento1. Ejecute el mandato siguiente para crear una instancia del agente:

$ITMHOME/bin/itmcmd config -A np

Donde ITMHOME es la vía de instalación del agente.2. Elija un nombre para cada agente de supervisión y entre el nombre en el campo Nombre de

instancia. Defina una instancia de agente nueva para cada dominio Network Manager.

El nombre de instancia puede ser cualquier nombre exclusivo significativo. Por ejemplo, el nombre deinstancia de cada agente puede incluir el nombre del sondeador con el que está asociado.

Nota:

Si utiliza varios sondeadores y desea supervisar los sondeadores de forma individual utilizando elespacio de trabajo Disponibilidad, debe definir un nombre exclusivo para los sondeadores editando elarchivo knp.ref. Para obtener más información sobre cómo editar el archivo knp.ref para ponernombre a los sondeadores, consulte la siguiente nota técnica: http://www-01.ibm.com/support/docview.wss?uid=swg21600387

3. Especifique un valor para Vía de acceso de NCHOME. El valor predeterminado es /opt/IBM/netcool/core.

4. Especifique un nombre de dominio de Network Manager. El valor predeterminado es NCOMS.5. Especifique un valor para el nombre del sondeador de Network Manager. Si deja este campo en

blanco, el agente se correlaciona con el sondeador predeterminado. Si tiene más de un sondeador,debe especificar un valor. Este campo está vacío si no está utilizando un sondeo distribuido.

6. Especifique un nombre de usuario para la base de datos OQL de Network Manager. De formapredeterminada, el nombre de usuario es admin.

7. Especifique un nombre de usuario para la base de datos OQL de Network Manager. Esta contraseñaestá vacía de forma predeterminada.




8. Especifique un intervalo de actualización en minutos. El valor predeterminado es 10. Este númeroespecifica el intervalo máximo de tiempo, en minutos, antes de que los datos se almacenen enmemoria caché. Si especifica un valor de cero, se realiza una consulta de base de datos cada vez quese solicitan datos. De lo contrario, la consulta de base de datos se realiza en el intervalo de tiempoespecificado. La especificación de un número inferior puede afectar al rendimiento del servidor deNetwork Manager, ya que algunas consultas requieren una cantidad considerable de tiempo deproceso.

9. Seleccione Yes para conectar el agente a un Tivoli Enterprise Monitoring Server.10. Especifique el nombre DNS para el Tivoli Enterprise Monitoring Server cuando se le solicite para el

nombre de host de Tivoli Enterprise Monitoring Server.

Nota: No especifique el nombre del Tivoli Enterprise Monitoring Server. Especifique el nombre DNS.11. A menos que el administrador de IBM Tivoli Monitoring le proporcione unos valores diferentes,

acepte los valores predeterminados de las siguientes opciones:

• Protocolo de red. El valor por omisión es ip.pipe.• Seleccione el protocolo siguiente entre las opciones siguientes:

– sna– ip.spipe– 0 (none)– Protocolo de red 2 (el valor predeterminado es 0)– Número de puerto IP.PIPE (el valor predeterminado es: 1918)

• KDC_PARTITION (el valor predeterminado es null.)• ¿Desea configurar la conexión para un TEMS secundario? [1=SÍ, 2=NO] (El valor predeterminado es

2.)• Nombre de red primaria opcional (el valor predeterminado es 0 o ninguno.)

12. Opcional: Sólo para una instalación no root, debe realizar las siguientes tareas adicionales:a) Especifique la contraseña de root para actualizar los scripts de reinicio automático.b) Como usuario raíz, ejecute ITMHOME/bin/SetPerm desde el directorio donde está instalado IBM

Tivoli Monitoring.c) Como usuario raíz, ejecute el script ITMHOME/bin/UpdateAutoRun.sh desde el directorio

donde está instalado IBM Tivoli Monitoring.

Si está ejecutando el programa de utilidad SetPerm en AIX 6.X o 7.X, debe seleccionar lasopciones de AIX 5.X..

13. Repita el procedimiento entero para configurar una instancia del agente para cada dominio deNetwork Manager. Utilice distintos nombres de sondeador para cada instancia de agente.

Qué hacer a continuaciónUna vez configurado IBM Tivoli Monitoring for IBM Tivoli Network Manager IP Edition, puede habilitar lasvistas de estado y el inicio en contexto desde el portal de Tivoli Enterprise.

Inicio del agente de supervisiónUtilice un mandato para iniciar el agente de supervisión.

Antes de empezarSi está utilizando Red Hat Enterprise Linux 7 o SuSE Linux Enterprise Server 12, ejecute el siguientemandato antes de instalar, desinstalar, iniciar o detener el agente de supervisión:

setarch $(uname -m) --uname-2.6


Acerca de esta tareaAl instalar el agente de supervisión, se configuran automáticamente los archivos utilizados para iniciar elagente cuando se arranca el sistema. El archivo utilizado para reiniciar el agente es /etc/init.d/ITMAgents2. Si instala otro agente, el valor 2 se incrementa; por ejemplo, el siguiente agente que seinstale será ITMAgents3.

Ejecute el siguiente mandato para iniciar el agente: ./ITMAgents2

Acceso a datos de descubrimiento desde dNCIMPuede sacar partido de las difusiones de dNCIM postdescubrimiento para recuperar actualizaciones en latopología de red una vez finalizado cada uno de los descubrimientos. Los procesos internos de NetworkManager leen esta información al completar un descubrimiento. También puede configurar sistemas deterceras partes (basados en Tivoli o externos) para acceder a estos datos de topología para que tenganlas últimas actualizaciones de topología.

Acerca de esta tareaEjemplos de estos sistemas de terceras partes que puede configurar para leer datos dNCIM incluyen lossiguientes:

• TADDM puede utilizar estos datos para alimentar el descubrimiento de la aplicación. Los datos dedNCIM indican a TADDM qué hosts están presentes en la red, que es un primer paso para eldescubrimiento de aplicaciones en esos hosts.

• IBM Director puede utilizar estos datos para soportar el descubrimiento de dispositivos dealmacenamiento

• Una base de datos de activos puede utilizar estos datos para cargar la información de activos.• Un sistema de seguridad puede utilizar los datos para identificar posibles intrusiones.

Existen las siguientes diferencias entre obtener datos desde dNCIM en vez de utilizar el DLA.

• Los datos están en un formato diferente al de DLA.• Los datos de dNCIM no se han enviado todavía al gestor de topología, ncp_model, por lo que los datos

no se consolidan con los descubrimientos anteriores:• Los datos son más ligeros que los datos que se pueden recuperar utilizando el DLA.• Las difusiones de dNCIM tienen un formato idéntico al de las difusiones NCMI que transmite ncp_model

y a los archivos de memoria caché NCIM.

Para configurar sistemas de terceras partes para acceder a datos de descubrimiento desde dNCIM, debeescribir un script para configurar la API de Java o Perl para escuchar mensajes con el asuntoDNCIM2NCIM en el bus de mensajes.

Para obtener información sobre el formato de las difusiones de dNCIM, consulte Referencia de IBM TivoliNetwork Manager.


Capítulo 8. Actualización y migraciónLa actualización desde una versión anterior de Network Manager implica la instalación de la versión másreciente y la migración de las configuraciones y personalizaciones existentes.

Acerca de la actualizaciónConocer qué opciones están disponibles para actualizar y qué implica la actualización.

Vías de acceso de actualización y limitacionesPuede actualizar a Network Manager V4.2 desde determinadas versiones anteriores, con limitaciones.

Puede migrar desde cualquiera de las siguientes versiones a Network Manager V4.2:

• V3.9 Fixpack 3 o posterior• V4.1• V4.1.1

Si tiene una versión de Network Manager anterior a la V3.9, actualice a la V3.9 Fixpack 3 antes de laactualización.

También puede utilizar el procedimiento de migración para copiar una instalación V4.2 en otro servidor. Elprocedimiento para todas estas versiones es el mismo.

Nota:

Si tiene instalado IBM Netcool Operations Insight V1.2 o V1.3 y está actualizando a IBM NetcoolOperations Insight V1.4, ejecute IBM Installation Manager y desinstale el componente NetworkManagement Integration para OMNIbus 8.1 antes de instalar Network Manager V4.2.

Se aplican las limitaciones siguientes a la actualización;

• Solo puede migrar a un servidor de 64 bits.• La migración desde los sistemas Windows no está soportada.• Las máquinas de origen y destino deben utilizar el mismo tipo de base de datos. Las únicas excepciones

son las siguientes:

– V3.9: se soporta la migración del origen predeterminado anterior de Informix a la base de datos Db2predeterminada o una base de datos Oracle en la V4.2 en el sistema de destino.

• Los sistemas de origen y de destino deben ser las instalaciones FIPS o que no sea FIPS. La migracióndesde una instalación de FIPS a una instalación que no sea de FIPS, o al revés, no es admitida.


Tareas relacionadasDesinstalación de Network ManagerSi desea eliminar por completo el producto o retrotraer a una versión anterior, debe utilizar IBMInstallation Manager. Al desinstalar el producto eliminando los archivos y los directorios se producenproblemas cuando se vuelven a instalar los componentes.

Ubicaciones predeterminadas para las distintas versiones del productoLas diferentes versiones de Network Manager y los componentes relacionados utilizan diferentesestructuras de directorio y tienen archivos de configuración en diferentes ubicaciones.



Si está buscando un archivo u otro componente de sistema que esperaba encontrar basándose en laubicación del sistema antiguo, utilice la siguiente tabla para determinar dónde encontrar el elemento enNetwork Manager 4.2. Como referencia, la siguiente tabla contiene una visión general de cómo laubicación predeterminada de los archivos de configuración ha cambiado en las diferentes versiones.

Tabla 11. Ubicaciones predeterminadas de los archivos de configuración

Elemento Versiones 3.9, 4.1 y 4.1.1 Versión 4.2

NCHOME /opt/IBM/tivoli/netcool /opt/IBM/netcool/core

ITNMHOME /opt/IBM/tivoli/netcool/precision

Nota: De forma predeterminada,PRECISION_HOME se establece en lamisma ubicación que ITNMHOME, pero loutilizan otras partes del producto.

/opt/IBM/netcool/core/precision

Nota: De forma predeterminada,PRECISION_HOME se establece en lamisma ubicación que ITNMHOME, pero loutilizan otras partes del producto.

TIPHOME /opt/IBM/tivoli/tipv2 Ya no es aplicable. Tivoli Integrated Portalse ha sustituido por Dashboard ApplicationServices Hub

JazzSM_HOME No aplicable Consulte el Knowledge Center de Jazz forService Management para obtenerdetalles.

Archivos depropiedades de laGUI

ITNMHOME/profiles/TIPProfile/etc/tnm

$NMGUI_HOMEprofile/etc/tnm/

Nota: $NMGUI_HOME es la ubicación en laque se instalan los componentes de la GUIde Network Manager. De formapredeterminada, es /opt/IBM/netcool/gui/precision_gui.

Plantillas de vistadinámica

ITNMHOME/profiles/TIPProfile/etc/tnm/dynamictemplates

$NMGUI_HOME/profile/etc/tnm/dynamictemplates/

Haga clic con elbotón derecho delratón en los archivosde definición deherramientas ymenú

ITNMHOME/profiles/TIPProfile/etc/tnm/menus

$NMGUI_HOME/profile/etc/tnm/menus/

ITNMHOME/profiles/TIPProfile/etc/tnm/tools

$NMGUI_HOME/profile/etc/tnm/tools/

Archivos de iconosde la GUI

ITNMHOME/profiles/TIPProfile/etc/tnm/resource

$NMGUI_HOME/profile/etc/tnm/resource/

Archivos deconfiguraciónWebTools

ITNMHOME/profiles/TIPProfile/etc/tnm/tools

$NMGUI_HOME/profile/etc/tnm/tools/

Qué datos se migranNetwork Manager migra la mayoría de archivos y resalta los archivos que debe migrar manualmente.

Los archivos que se han cambiado pueden clasificarse de los dos maneras siguientes.


Cambios de configuración

Los valores estándares para procesos, configuración de descubrimiento y supervisión y vistas detopología se pueden migrar siguiendo los directorios de este documento. La persona que realiza lamigración debe ser el administrador o tener un nivel similar de conocimiento de Network Manager.Los archivos de configuración se migran total o parcialmente mediante el proceso de migración. Losarchivos que se deben migrar de forma manual aparecerán resaltados.

Cambios de personalización

Network Manager puede personalizarse ampliamente para añadir una nueva prestación o integrarsecon el entorno existente. A continuación se muestran algunos ejemplos de cambios de configuración:

• Soporte de dispositivo adicional• Datos adicionales de dispositivos y orígenes de datos de propietario de clientes para la visualización

y supervisión• Lógica modificada para crear conexiones dentro y entre dispositivos de red y colecciones para

agrupar dispositivos• Creación de conjuntos de vistas de red utilizando la API de plantilla dinámica• Enriquecimiento de sucesos a través de la Pasarela de sucesos y del archivo de reglas de analizador

nco_p_ncpmonitor• Pulse el botón derecho en las herramientas de mapa de topología utilizando las Herramientas web y

otras tecnologías• Ampliación del sistema Service Affecting Events para otras colecciones• Integraciones con otros productos, incluyendo LDAP y TADDM

Todos los cambios de personalización requieren un nivel de conocimientos del flujo de datos deproducto y de las API, además de habilidades de programación. Estas mismas habilidades sonnecesarias para migrar correctamente las mismas personalizaciones. También debe tener en cuentalos cambios de lógica nuevos que puedan requerir cambios en el código personalizado existente.

Los cambios de personalización no se migran automáticamente. El proceso de actualización resaltalos archivos que han cambiado y se deben migrar manualmente.

Datos que no se migranLas siguientes clases de datos no se pueden migrar:

• Los archivos de memoria caché de NCIM no se migran entre distintas versiones de Network Manager.Los archivos de memoria caché NCIM se copian de una instalación a otra sólo si copia una instalaciónV4.2 existente en otra instalación V4.2.

• Archivos de memoria caché de descubrimiento• La topología de red no se migra. Debe ejecutar un nuevo descubrimiento en la instalación de destino.

Datos que se migranSe migran las siguientes clases de datos.

• Archivos de configuración.• Vistas de red.• Datos de configuración de descubrimiento.• Varios dominios. Los dominios se vuelven a crear de forma automática y las vistas de red y las políticas

de supervisión se importan.• Contraseñas y nombres de comunidad de SNMP. Estos datos no están cifrado, se importan y se volverán

a cifrar automáticamente.• Políticas de sondeo y definiciones de sondeo.

Capítulo 8. Actualización y migración 139

• MIB. Los MIB SNMP se han movido del servidor de GUI al servidor de componentes principales deNetwork Manager 4.2.

• Recopiladores de descubrimiento nuevos o personalizados

Actualización de Network ManagerComplete las tareas de actualización en el orden en que se proporcionan.

Acerca de esta tareaEn estas instrucciones, la instalación o el servidor de "origen" hace referencia a la instalación o el servidorde Network Manager a partir del cual realiza la actualización. Normalmente, esta versión es una versiónanterior más antigua.

El servidor de "destino" o la instalación hace referencia al servidor de Network Manager o a la instalaciónque está actualizando. Normalmente, esta versión es la versión actual, 4.2.

Importante: Una actualización de Fix Pack implementa un nuevo archivo .war para cada aplicación web,como Vistas de red, Navegador de estructuras, vistas geográficas, etc. Se sobrescriben los archivosmodificados en el mismo directorio que el archivo WAR. Debe realizar una copia de seguridad de loscambios que haya realizado en los archivos dentro de la ubicación de implementación del archivo WAR.

Preparación para la actualizaciónDebe preparar los sistemas de destino antes de empezar la actualización.

Acerca de esta tareaPara prepararse para la actualización, complete las tareas siguientes:

Procedimiento1. Instalar los componentes principales de Network Manager.2. Inicie los componentes principales de Network Manager.

No realice ninguna configuración adicional del dominio primario, ya que esto limitará la migraciónautomática de la configuración.

3. Instale los componentes de GUI de Network Manager.4. Asegúrese de que puede iniciar la sesión en la GUI de Network Manager.5. Vuelva a crear todos los usuarios de Network Manager de la instalación de origen en la instalación de

destino. Cree los usuarios en el repositorio adecuado: LDAP u ObjectServer. Si se han creado usuariosen Tivoli Integrated Portal, cree estos usuarios de nuevo. Network Manager 4.2 no utiliza TivoliIntegrated Portal. Anote los nombres de usuario y las contraseñas. Necesita estas credenciales almigrar roles de usuario.

6. Opcional: Si está realizando la migración desde una instalación de Network Manager que estáintegrado con IBM Tivoli Netcool Configuration Manager, exporte los informes personalizados antes deactualizar. Si no exporta los informes personalizados, es posible que se sobrescriban durante laactualización. Consulte la información en Exportar informes personalizados para la versión de NetcoolConfiguration Manager en: http://www.ibm.com/support/knowledgecenter/SS7UH9/welcome.

7. No inicie un descubrimiento o empiece a trabajar con Network Manager. Empiece la actualización.

Actualización de la base de datosDebe identificar las personalizaciones que ha hecho en la base de datos de topología de NCIM y actualizarla base de datos nueva con esas personalizaciones.



Antes de empezarComo parte de la instalación del sistema de destino, debe instalar la nueva base de datos y ejecutar losscripts de creación de esquema de base de datos de Network Manager para configurar las tablas y losesquemas.

Nota: Solo tiene que ejecutar el script ncp_ncim_diff.pl si ha personalizado los cambios en la base dedatos de origen.

Asegúrese de que los archivos DbLogins.DOMAIN.cfg de la instalación anterior están disponibles.Estos archivos contienen la información para conectarse a la base de datos de NCIM.

Acerca de esta tareaPara actualizar el esquema de base de datos de topología, complete los siguientes pasos:

Procedimiento1. Inicie una sesión en la instalación de Network Manager de origen.2. Cambie al directorio $NCHOME/precision/scripts/perl/scripts y ejecute el siguiente

mandato:

./ncp_ncim_diff.pl -domain DOMAIN -password NCIM_database_password

Donde DOMAIN es necesario para identificar un archivo DbLogins.DOMAIN.cfg que contiene lasopciones para conectarse a la base de datos de NCIM. Este mandato informa en todos los dominios ysólo necesita ejecutarse una vez.

Para obtener más información sobre el script Perl ncp_ncim_diff.pl, consulte la publicación IBMTivoli Network Manager IP Edition Administration Guide.

El script indica las diferencias entre el esquema de base de datos de NCIM y el esquema de base dedatos de NCIM predeterminado para la versión de Network Manager.

3. Actualice manualmente el esquema de base de datos de topología NCIM con las personalizacionesindicadas por el script.

Es posible que el script informe sobre tablas nuevas que se han introducido con un fixpack. Estoscambios ya están presentes en el nuevo sistema y no necesitan migrarse. Tenga cuidado cuandoaplique personalizaciones en el nuevo esquema NCIM, ya que los nombres de tabla y los nombres decampo pueden cambiar entre versiones.

Tareas relacionadasInstalación y configuración de una base de datos de topologíaEl administrador de base de datos debe instalar y configurar una base de datos de topología soportadaantes de poder instalar Network Manager.

Migración de los componentes principalesMigre los componentes principales exportando datos del servidor de origen e importándolos al servidorde destino. Inicie y detenga todos los procesos, importe los datos, defina varios sondeadores, averigüetodas las políticas de sondeo y complete los pasos manuales necesarios.

Acerca de esta tareaSi los componentes principales y los componentes de GUI están en el mismo servidor, debe migrarlos detodas formas por separado siguiendo los pasos adecuados.

Realice los pasos siguientes para migrar los componentes principales.


Procedimiento1. En el servidor de destino donde están instalados los componentes principales, ejecute el siguiente

script:

$ITNMHOME/install/scripts/makeExportPackageCore

El script crea un paquete que contiene los scripts que se utilizan para exportar datos de la instalaciónde origen. El paquete se denomina ExportPackageCore.tar.

2. Copie el archivo ExportPackageCore.tar en una ubicación temporal en el servidor de destinodonde están instalados los componentes principales.

Nota: La ubicación no debe estar en el directorio de instalación $NCHOME ni contenerlo.3. Descomprima el archivo ExportPackageCore.tar.4. En el directorio scripts que se crea al descomprimir el archivo, ejecute el script nmExport.

Proporcione la información necesaria y seleccione una ubicación para que se guarde el archivo deexportación.

Restricción: Debe ejecutar el script como el mismo usuario que ha instalado el producto.

El script crea un archivo .pkg que contiene datos de configuración de descubrimiento, vistas de red,políticas y definiciones de sondeo, otros archivos de configuración y archivos de registro quecontienen información sobre la exportación satisfactoria. Si la exportación se realiza de formasatisfactoria, los archivos de registro se guardan en el directorio /itnmExportLogs/ del directoriode inicio.

5. Copie el archivo .pkg que se ha creado en el servidor de destino.6. En el servidor de destino, asegúrese de que todos los procesos de Network Manager están en

ejecución utilizando el mandato siguiente:

itnm_start ncp -domain DOMAIN

Ejecute este mandato para todos los dominios que existen en el servidor de destino. Especifique elnombre de dominio de forma explícita cada vez.

7. Ahora detenga todos los procesos de Network Manager utilizando el mandato siguiente:

itnm_stop ncp -domain DOMAIN

Ejecute este mandato para todos los dominios. Especifique el nombre de dominio de forma explícitacada vez. Al iniciar y detener los procesos, se asegura de que se llenen las tablas de base de datosapropiadas.

Si ha configurado la migración tras error, detenga también todos los dominios en el servidor de copiade seguridad.

8. En el servidor de destino, vaya a la ubicación $NCHOME/precision/install/data/ y extraiga elpaquete ExportPackageCore.tar.

9. Como el mismo usuario que ha instalado el producto, ejecute el script nmImport desde elsubdirectorio scripts.

10. Proporcione la información necesaria para el script cuando se le solicite. Proporcione la vía de accesoal archivo .pkg que contiene los datos de personalización que ha exportado del servidor de origen.

11. Opcional: Si está migrando la base de datos de topología NCIM a una base de datos Oracle que utilizala tecnología de agrupación en clúster de Oracle, proporcione la información relevante de Oracle,prestando atención a las siguientes solicitudes:a) Después de la solicitud que lista los valores de servidor de base de datos actuales, responda n a la

siguiente pregunta:

¿Son correctos los valores de servidor [s | n]?

b) Responda s a la pregunta siguiente:


¿Es este un nombre de servicio de Oracle [s|n] ?

c) Cuando el script muestre los valores de servidor de base de datos actuales, compruebe que sevisualice el valor siguiente: oracleService = 1.

12. Cuando se le solicite si desea asignar nuevos ID de entidad, que son identificadores de dispositivoexclusivos, durante la importación, responda N para conservar los enlaces con otros productos queutilizan datos de Network Manager como TADDM, IBM Tivoli Business Service Manager, IBM ControlDesk.

Si ya tiene datos de topología en la instalación de destino, por ejemplo de una importación o undescubrimiento de red anteriores, no puede conservar los ID de entidad anteriores y debe responderS. Si responde N, el script devuelve un error que indica que los datos de entidad ya existen.

Si tiene un dominio en el sistema de destino que tiene el mismo nombre que en el sistema de origen,asegúrese de que el dominio en el sistema de destino no contiene datos de topología. Los nombresde dominio no se pueden cambiar durante el proceso de migración.

13. Revise las vistas de red para los duplicados. Se pueden crear vistas de red duplicadas si, por ejemplo,se ha ejecutado un descubrimiento antes de la actualización. Puede suprimir las vistas duplicadas omover secciones de las vistas a las vistas existentes.

14. Cambie el dominio predeterminado, si lo desea, estableciendo la variable de entornoPRECISION_DOMAIN en el dominio predeterminado que desee.

El dominio predeterminado es el dominio que se crea durante la instalación. Cuando se utilizan losscripts de control, por ejemplo, itnm_start sin un argumento -domain, las acciones especificadasen los scripts se aplican al dominio predeterminado.

ResultadosEl script de importación importa los datos de configuración de la instalación de origen a la instalación dedestino. Los siguientes archivos de registro se graban en el directorio $NCHOME/log/precision:ITNMDataImport.log, get_policies.domain name.log, e ITNMImportNetworkViews.log.

Qué hacer a continuaciónAhora debe revisar los resultados de la importación y realizar los pasos de migración manual necesarios.

Migración de sondeoMigrar las políticas de sondeo y, si corresponde, varios sondeadores.

Acerca de esta tareaDebe definir el ámbito para cada política de sondeo que desea utilizar. Asegúrese de que todas laspolíticas están asociadas con el sondeador mencionado apropiado.

Procedimiento1. Configure las políticas de sondeo en la instalación de destino completando los siguientes pasos para

cada política de sondeo que ha migrado:a) Inicie la sesión en las aplicaciones web de la nueva instalación.b) Asegúrese de que las vistas de red existen para su sistema. Pulse el icono Incidencia y seleccione

Disponibilidad de red > Vistas de red.c) Pulse el icono Administración y seleccione Red > Sondeo de redes.d) Seleccione una política que estuviese disponible en el sistema de origen pulsando en el nombre de

la política de sondeo.Se visualiza el Editor de políticas de sondeo para la política que ha seleccionado y los valores secargan automáticamente en los campos.

e) Si es necesario, vuelva a asignar la política al sondeador mencionado apropiado.


f) Seleccione el separador Vistas de red y seleccione la vista de red que se ha utilizado en el sistemade origen.

g) Seleccione el separador Filtro de dispositivo y configure el filtro como estaba en el sistema deorigen.

h) Edite cada definición de sondeo y asegúrese de que el filtro de clase y el filtro de interfaz se hanestablecido como esperaba. Es posible que se hayan añadido o eliminado clases entre versiones.

2. Opcional: Las políticas para un único sondeador en el sistema de origen se asignan automáticamenteal nuevo sondeador ncp_poller_default en la instalación de destino. Si ha utilizado variossondeadores en la instalación de origen, configure varios sondeadores en la instalación de destinocompletando los pasos siguientes:a) Edite el archivo CtrlServices.cfg en la instalación de destino con las entradas del sistema de

origen. Si utiliza el nuevo sondeador ncp_poller_default, las políticas de sondeo toman deforma predeterminada ese sondeador automáticamente.

b) Repítalo para cada dominio en la instalación de destino.

Migración manual de archivos de componentes principalesAlgunos archivos que contienen cambios de configuración no se pueden migrar automáticamente. Revisela lista recomendada de archivos y migrar los cambios manualmente.

Acerca de esta tareaEl proceso de migración actualiza la configuración en el sistema de destino tanto como es posible. Loscambios se manejan de las siguientes maneras:

• Si un archivo de configuración se ha modificado respecto al valor predeterminado en el sistema deorigen, ese archivo se copia automáticamente en el archivo equivalente del sistema de destino. Elproceso de migración aplica los cambios automáticamente, siempre y cuando no haya conflictos.

• Si un archivo de configuración se ha modificado respecto al valor predeterminado en el sistema deorigen, pero el valor predeterminado para la versión del producto del sistema de destino es diferente dela del sistema de origen, hay un conflicto entre el cambio y un cambio en el producto. Si no se puederesolver la diferencia automáticamente con los scripts de migración, el archivo se marca para revisión.

• Si un archivo de configuración no se ha cambiado en el sistema de origen, no se migra.• Si un archivo de configuración ya no es necesario en la instalación de destino, no se migra.

Para migrar archivos manualmente, complete las siguientes tareas:

Procedimiento1. Revise el archivo de registro $NCHOME/log/precision/NMCoreFilesForManualReview.txt.

Por ejemplo, /opt/IBM/netcool/log/precision/NMCoreFilesForManualReview.txt. Estearchivo tiene una entrada para cada elemento que necesita atención. Si una entrada indica que unarchivo requiere pasos de migración manuales, debe revisar cada archivo y decidir cómo incorporarlas diferencias en los archivos en la instalación de destino.

2. Opcional: Revise el archivo de registro NMCoreFilesMigrated.txt para ver todos los archivos quese han migrado y qué archivos no se han migrado. Es probable que no sea necesario realizar ningunaacción para los archivos que no se han migrado. Algunos archivos no necesitan migrarse. Si consideraque un archivo de este tipo contiene información de configuración importante que desea conservar,revise el archivo. Revise el archivo de registro $NCHOME/log/precision/NMCoreConfigFileAutoMigrationReport.txt para obtener información adicional acerca de losarchivos que no se han podido migrar correctamente.

3. Para los archivos que necesitan migración manual, localice las versiones apropiadas de los archivos arevisar.

• Para los archivos cambiados por un usuario, compare la versión original de la instalación de origencon la versión modificada de la instalación de origen. Estos archivos se copian en el servidor de


destino para su comodidad. Las ubicaciones difieren según el tipo de archivo y se listan en elarchivo NMCoreFilesForManualReview.txt.

• Para los archivos modificados por IBM entre versiones, compare la versión de la instalación deorigen con la versión de la instalación de destino. Los archivos del servidor de origen se copian en elservidor de destino para su comodidad. Las ubicaciones difieren según el tipo de archivo y se listanen el archivo NMCoreFilesForManualReview.txt.

• Para los archivos modificados por un usuario y por IBM entre versiones, compare las tres versiones.Los archivos del servidor de origen se copian en el servidor de destino para su comodidad. Lasubicaciones difieren según el tipo de archivo y se listan en el archivoNMCoreFilesForManualReview.txt.

4. Ejecute el programa de utilidad ncp_mib si ha personalizado los MIB en el sistema de origen.Los MIB personalizados de la instalación de origen se copian en el directorio $NCHOME/precision/mibs/. Los archivos MIB se han movido de la GUI al servidor de componentes principales en la V4.2.

5. Revise el archivo DbEntityDetails.cfg y sustituya &ExtraInfo por &m_ExtraInfo.Este cambio es necesario debido a los cambios de base de datos entre la V3.9 y la V4.1 y posterior.

6. Revise los archivos DbLogins.cfg específicos de dominio en la instalación de destino con losnuevos detalles de conexión de base de datos para la instalación de destino.Los scripts de migración crean archivos DbLogins.cfg específicos de dominio para cada dominio dela instalación de origen.

7. Opcional: Si ha utilizado recopiladores de descubrimiento en la instalación de origen, copie losarchivos .cfg y .drv en la instalación de destino y asegúrese de que los recopiladores se hanconfigurado correctamente.

8. Opcional: Si ha creado nuevos recopiladores de descubrimiento en la instalación de origen, consultela publicación EMS Collector Guía del desarrollador para obtener las instrucciones de migración.

9. Si ha utilizado los archivos fuente en el servidor de origen, copie los archivos fuente en la ubicaciónequivalente del servidor de destino. Cuando ejecute un descubrimiento, actualice la referencia delarchivo fuente en el separador Fuente de la GUI de configuración del descubrimiento.

10. Si ha utilizado los archivos DNS para el descubrimiento en el servidor de origen, copie los archivos enla ubicación equivalente del servidor de destino. Cuando ejecute un descubrimiento, actualice lareferencia del archivo DNS en el separador DNS de la GUI de configuración del descubrimiento.

11. Revise la lista de archivos que no se migran a “Referencia de archivos de componentes principales”en la página 146 y decida si es necesario migrar algún cambio de personalización.

12. Revise los cambios que ha realizado en los archivos NcoGateInserts.DOMAIN.cfg, que están endesuso en Network Manager 4.2, y migre los cambios:a) Vaya al directorio que aparece para la entrada NcoGateInserts.DOMAIN.cfg en el archivo$NCHOME/log/precision/NMCoreFilesForManualReview.txt.

b) Localice los archivos NcoGateInserts.DOMAIN.cfg para cada dominio para el que ha realizadopersonalizaciones.

c) Localice las personalizaciones. Sólo es necesario migrar las personalizaciones que ha realizadouno mismo. Todas las personalizaciones predeterminadas se han movido del archivoNcoGateInserts.cfg a las reglas de analizador en Netcool/OMNIbus Knowledge LibraryV4.4.3.

d) En el servidor donde está instalado Netcool/OMNIbus Knowledge Library, localice el archivo dereglas que corresponde al ID de suceso del tipo de sucesos que desea personalizar. Para reglasespecíficas de proveedor, los archivos de reglas se colocan bajo el directorio de proveedor, porejemplo, include-snmptrap/cisco.

e) Localice el archivo de reglas apropiado con el sufijo user.include.rules. Por ejemplo /include-snmptrap/adtran/adtran-ADTRAN-ACTDAXL3-MIB.user.include.snmptrap.rules. Si las personalizaciones se ponen en un archivoindependiente, es más fácil identificarlas y realizar copias de seguridad de las mismas másadelante.


f) Edite el archivo y localice la sección que corresponde al tipo de interrupción que deseapersonalizar.Por ejemplo, para alterar temporalmente las reglas predeterminadas de la interrupciónadACTDAXL3systemHdwFailureClear, añada las reglas personalizadas en la siguientesección:

case "906": ### adACTDAXL3systemHdwFailureClear

g) Establezca el campo @NmosEventMap utilizando el formato siguiente:nombre_correlación_sucesos.valor_prioridad.

Por ejemplo:

@NmosEventMap = "LinkDownIfIndex.910"

13. Opcional: Si desea revisar la lista de archivos que se han migrado correctamente, revise los archivoslistados en NCHOME/log/precision/NMCoreFilesMigrated.txt.

Referencia de archivos de componentes principalesLos scripts de migración de componentes principales procesan los archivos dentro de su ámbito.

Archivos en el ámbito de los scripts de migración de componentes principalesLos scripts de migración de componentes principales examinan los archivos de configuración de losdirectorios siguientes y los procesan como se describe en “Migración manual de archivos decomponentes principales” en la página 144.

• $NCHOME/precision/aoc/*.aoc• $NCHOME/precision/disco/stitchers/*.stch• $NCHOME/precision/disco/stitchers/DNCIM/*agnt• $NCHOME/precision/disco/agents/*• $NCHOME/precision/adapters/ncp_dla/ncp_dla.properties.*• $NCHOME/precision/eventGateway/stitchers/*• $NCHOME/probes/plataforma/nco_p_ncpmonitor.rules*• $NCHOME/precision/mibs/*.mib• $NCHOME/etc/precision/*.cfg• $NCHOME/precision/storm/conf/*.cfg, *.conf, *.yaml, *.properties

Archivos no migrados por los scripts de migración de componentes principalesLos scripts de migración no migran los siguientes archivos:

• $NCHOME/precision/scripts/webtools.

Debe guardar manualmente estos archivos en la instalación de origen y volver a implementarlos en lainstalación de destino. Un ejemplo de esta personalización son los valores que se inician en IBM TivoliApplication Dependency Discovery Manager.

• $NCHOME/etc/omni.dat.

Estos valores no son necesarias porque los detalles de conexión se establecen durante la instalacióndel sistema de destino.

• $NCHOME/etc/interfaces.<arch>• $NCHOME/precision/collectors. Si utiliza recopiladores de descubrimiento, debe migrar

manualmente cualquier cambio de configuración para el recopilador.• $NCHOME/etc/precision/ConfigSchema.cfg• $NCHOME/etc/precision/DbLogins.cfg


• $NCHOME/etc/precision/DiscoDncimDb.cfg. Este archivo está obsoleto en V4.2.• $NCHOME/etc/precision/DncimDbEntityDetail.cfg. Este archivo está obsoleto en V4.2.• $NCHOME/etc/precision/MibDbLogin.cfg• $NCHOME/etc/precision/NcoLogin.cfg• $NCHOME/etc/precision/ServiceData.cfg

Migración de los componentes de GUIMigre los componentes de GUI exportando los datos de la instalación de origen a la instalación dedestino. Importe los datos, asigne usuarios a grupos y revise el archivoNMGUIFilesForManualReview.txt para ver si son necesarios pasos manuales.

Acerca de esta tareaMigre los datos para la GUI de Network Manager utilizando las instrucciones siguientes.

Para obtener instrucciones sobre cómo migrar GUI web, consulte la información de la versión de GUI weben: http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

Procedimiento1. En el servidor de destino donde están instalados los componentes de la GUI, asegúrese de que las

variables de entorno para Network Manager estén establecidas ejecutando el script de entorno. Elscript de entorno se encuentra en la ubicación siguiente: directorio_instalación/nmgui_profile.sh, por ejemplo, /opt/IBM/netcool/nmgui_profile.sh.

2. En el servidor de destino donde están instalados los componentes GUI, ejecute el mandato siguiente:

$NMGUI_HOME/install/scripts/makeExportPackageGUI -j $JazzSM_HOME -n $NMGUI_HOME

Donde:

• $NMGUI_HOME es la variable de entorno que define dónde está instalada la GUI de NetworkManager. De forma predeterminada, es /opt/IBM/netcool/gui/precision_gui.

• $JazzSM_HOME es el directorio de instalación de Jazz for Service Management. De formapredeterminada, esta ubicación es /opt/IBM/JazzSM.

Por ejemplo, utilizando las ubicaciones de instalación predeterminadas, ejecute el mandatosiguiente:

/opt/IBM/netcool/gui/precision_gui/install/scripts/makeExportPackageGUI -j /opt/IBM/JazzSM -n /opt/IBM/netcool/gui/precision_gui

El script crea un paquete que contiene los scripts que se utilizan para exportar datos de la instalaciónde origen. El paquete se denomina ExportPackageGUI.tar.

3. Copie el archivo ExportPackageGUI.tar en una ubicación temporal en el servidor de destinodonde están instalados los componentes de GUI. Si tiene componentes de GUI instalados en variosservidores, sólo necesita exportar los datos de uno de los servidores, a menos que los hayaconfigurado de forma diferente.

Nota: La ubicación no debe estar en el directorio de instalación ni contenerlo.4. En el servidor de origen, descomprima el archivo ExportPackageGUI.tar.5. Asegúrese de que las variables de entorno para Network Manager estén establecidas en el servidor

de origen ejecutando el script de entorno adecuado.

En Network Manager 4.2, existen dos scripts de entorno.

En el servidor en el que se han instalado los componentes de la GUI De Network Manager, el script esdirectorio_instalación/nmgui_profile.sh, por ejemplo, /opt/IBM/netcool/nmgui_profile.sh.




En las versiones anteriores de Network Manager, el script está almacenado en el directoriodirectorio_instalación/netcool.

6. El archivo ExportPackageGUI.tar contiene un archivo denominado Preupgrade.tar. Extraiga elarchivo Preupgrade.tar en la ubicación siguiente del servidor de origen: $TIPHOME/profiles/TIPProfile.

7. En el directorio scripts creado al descomprimir el archivo, ejecute el script nmGuiExportutilizando el siguiente mandato:

nmGuiExport -u tipadmin|smadmin -p password

Donde:

• -u toma el nombre de usuario administrativo de Tivoli Integrated Portal (tipadmin de formapredeterminada) para las versiones de Network Manager anteriores a la V4.2 o el nombre deusuario administrativo de Jazz for Service Management (smadmin de forma predeterminada).

• contraseña es la contraseña de ese usuario.


El script crea un archivo data.zip en uno de los siguientes directorios: $TIPHOME/profiles/TIPProfile/output/ o $JazzSM_HOME/ui/upgrade/data/. El archivo contiene datos deconfiguración, roles de usuario y páginas, vistas y roles de Tivoli Integrated Portal personalizados.Cualquier error se guardará en uno de los directorios siguientes: $TIPHOME/profiles/TIPProfile/logs/tipcli.log o $JazzSM_HOME/ui/logs/consolecli.log.

8. Cree el directorio $JazzSM_HOME/ui/input/ en el servidor de la GUI de destino y copie el archivode exportación data.zip en el mismo. Si va a instalar varios servidores de Dashboard ApplicationServices Hub, copie el archivo de exportación en cada servidor.

9. Asegúrese de que Dashboard Application Services Hub está en ejecución.10. Asegúrese de que las variables de entorno para Network Manager, en el servidor de destino estén

establecidas, ejecutando el script de entorno directorio_instalación/netcool/gui/precision_gui/nmgui_profile.sh.

11. En el directorio scripts del servidor de destino, ejecute el script nmGuiImport utilizando elmandato siguiente:

nmGuiImport -u smadmin -p password [ -f path_to_zip_file ]

Donde:

• -u toma el nombre de usuario administrativo de Jazz for Service Management (smadmin de formapredeterminada).

• contraseña es la contraseña de ese usuario.• vía_acceso_archivo_zip es la vía de acceso al archivo de exportación data.zip que contiene los

datos de GUI. Si no se especifica la opción -f, el script busca el archivo data.zip en la ubicaciónpredeterminada: $JazzSM_HOME/ui/input/.


Los datos de la GUI exportados se importan en la nueva instalación. Si existen los mismos usuariosen la instalación de Dashboard Application Services Hub de destino que en la instalación de origen,se añaden los mismos roles de usuario a ellos. Los resultados de la importación se registran en elarchivo siguiente: $JazzSM_HOME/ui/logs/consolecli.log

12. Añada manualmente usuarios a los grupos de usuarios apropiados en el nuevo sistema. Laimportación de datos de la GUI no incluye los datos de pertenencia a grupo de usuarios.

13. Revise cualquier página personalizada de la instalación de origen que contenga el Visor de sucesos.Sustituya cada widget del Visor de sucesos por un widget del Visor de sucesos.


El widget del Visor de sucesos no está disponible en Network Manager V4.2. Para obtenerinformación sobre cómo editar páginas, consulte el tema Desarrollo de paneles de instrumentospersonalizados en Guía del usuario de IBM Tivoli Network Manager.

14. Si ha utilizado el Adaptador de biblioteca de descubrimiento en el servidor de origen, migre losvalores.a) Vaya a la ubicación del servidor de origen donde se almacenan las propiedades de DLA. Para las

versiones de Network Manager anteriores a la versión 4.2, la ubicación es $NCHOME/precision/adapters/ncp_dla/. Para Network Manager Versión4.2, la ubicación es $NMGUI_HOME/adapters/ncp_dla. Localice los archivos de propiedades de DLA. Cada dominio tiene un archivoncp_dla.properties.nombre_dominio. Utilice los archivos de propiedades de DLA de cadadominio para volver a crear los mismos valores de DLA en su nueva instalación.

b) Vaya a $NMGUI_HOME/adapters/ncp_dla.c) Utilizando el archivo ncp_dla.properties, cree un archivo de propiedades DLA equivalente

basado en cada archivo DLA del dominio anterior, nombrando los archivos después de cadadominio, por ejemplo, ncp_dla.properties.NCOMS.

d) Abra el archivo de propiedades DLA de cada dominio y configure el nuevo archivo específico deldominio correspondiente con los mismos valores que los del archivoncp_dla.properties.nombre_dominio anterior y, de este modo, volverá a crear el archivoDLA para cada dominio correspondiente en el nuevo sistema.

Restricción: No copie-pegue el contenido del archivo anterior tal como está en el nuevo archivo,pero copie los valores que se han modificado en el sistema anterior. El nuevo archivo contienenuevos parámetros que no existían en versiones anteriores y no funcionarán de forma adecuada siel contenido se altera temporalmente.

15. Revise los resultados de la importación en el archivo NMGUIFilesForManualReview.txt y realicelos pasos de migración manual necesarios.

Referencia relacionadaSistemas operativos soportadosNetwork Manager se soporta en los siguientes sistemas operativos.

Migración manual de archivos de componentes de GUIAlgunos archivos que contienen cambios de configuración no se pueden migrar automáticamente. Revisela lista recomendada de archivos y migrar los cambios manualmente.

Acerca de esta tareaEl proceso de migración actualiza la configuración en el sistema de destino tanto como es posible. Loscambios se manejan de las siguientes maneras:

• Si un archivo de configuración se ha modificado respecto al valor predeterminado en el sistema deorigen, ese archivo se copia automáticamente en el archivo equivalente del sistema de destino. Elproceso de migración aplica los cambios automáticamente, siempre y cuando no haya conflictos.

• Si un archivo de configuración se ha modificado respecto al valor predeterminado en el sistema deorigen, pero el valor predeterminado para la versión del producto del sistema de destino es diferente dela del sistema de origen, hay un conflicto entre el cambio y un cambio en el producto. Si no se puederesolver la diferencia automáticamente con los scripts de migración, el archivo se marca para revisión.

• Si un archivo de configuración no se ha cambiado en el sistema de origen, no se migra.• Si un archivo de configuración ya no es necesario en la instalación de destino, no se migra.

Procedimiento1. Revise el archivo de registro $NMGUI_HOME/../log/install/NMGUIFilesForManualReview.txt, que se encuentra en el directorio de instalación decomponentes de la GUI. Por ejemplo, /opt/IBM/netcool/gui/log/install/


NMGUIFilesForManualReview.txt. Este archivo tiene una entrada para cada elemento quenecesita atención.a) Si una entrada indica que un archivo se ha fusionado automáticamente, no es necesaria ninguna

acción.b) Si una entrada indica que un archivo no se ha migrado, es probable que no es necesaria ninguna

acción. Algunos archivos no necesitan migrarse. Si considera que un archivo de este tipo contieneinformación de configuración importante que desea conservar, revise el archivo.El archivo de configuración $NMGUI_HOME/integration/properties/mergeDefinition.json controla qué archivos se migran. No necesita editar este archivo.

c) Si una entrada indica que un archivo requiere pasos de migración manuales, debe revisar cadaarchivo y decidir cómo incorporar las diferencias en los archivos en la instalación de destino.

2. Para los archivos que necesitan migración manual, localice las versiones apropiadas de los archivos arevisar.

• Para los archivos cambiados por un usuario, compare la versión original de la instalación de origencon la versión modificada de la instalación de origen. Estos archivos se copian en el servidor dedestino para su comodidad. Las ubicaciones varían según el tipo de archivo y se listan en el archivoNMGUIFilesForManualReview.txt.

• Para los archivos que ha cambiado IBM entre versiones, compare la versión de la instalación originalcon la versión de la instalación de destino. Los archivos del servidor de origen se copian en elservidor de destino para su comodidad. Las ubicaciones varían según el tipo de archivo y se listan enel archivo NMGUIFilesForManualReview.txt.

• Para los archivos modificados por un usuario y por IBM entre versiones, compare las tres versiones.Los archivos del servidor de origen se copian en el servidor de destino para su comodidad. Lasubicaciones varían según el tipo de archivo y se listan en el archivoNMGUIFilesForManualReview.txt.

Referencia de archivo de GUILos scripts de migración de GUI procesan algunos archivos e ignoran otros.

Archivos en el ámbito de los scripts de migración de GUILos scripts de migración de GUI examinan los archivos de configuración de los directorios siguientes y losprocesan como se describe en “Migración manual de archivos de componentes de GUI” en la página 149.

• $NMGUI_HOME/profile/etc/tnm/autoprovision/*• $NMGUI_HOME/profile/etc/tnm/dynamictemplates/*• $NMGUI_HOME/profile/etc/tnm/*• $NMGUI_HOME/profile/etc/tnm/menus/*• $NMGUI_HOME/profile/etc/tnm/tools/*• $NMGUI_HOME/profile/etc/tnm/resource/*

Archivos ignorados por los scripts de migración de GUILos scripts de migración ignoran los siguientes archivos de GUI:

• tnm.properties• ncpolldata.properties. Este archivo está obsoleto en Network Manager 4.2.• etc/tnm/locale/*


Migración de topología de redPara asegurarse de que tiene topología de red en el sistema de destino, ejecute un descubrimientocompleto. Opcionalmente, migre el estado gestionado para dispositivos y cualquier topologíapersonalizada creada manualmente.

Acerca de esta tareaPara migrar la topología de red, realice los pasos siguientes para cada dominio de descubrimiento:

Procedimiento1. Detenga e inicie todos los procesos de Network Manager en la instalación de destino para asegurarse

de que el dominio se ha actualizado con los cambios de personalización.2. Ejecute un descubrimiento completo en la instalación de destino.3. Si ha creado la topología manual en la instalación de origen, complete los pasos siguientes. Si no ha

añadido o eliminado manualmente ningún dispositivo en la topología de red en la instalación deorigen, vaya al paso 7.

4. En la nueva instalación, vaya a la siguiente ubicación $NCHOME/var/precision/export/manualtopology.Este directorio contiene los archivos XML que listan los dispositivos y las conexiones añadidosmanualmente a cada dominio en el sistema anterior. Hay un archivo para cada dominio. Cada archivose denomina de la siguiente manera:

ManualTopology.DOMAIN.xml

Donde DOMAIN es el nombre del dominio correspondiente.5. Abra el archivo XML para el dominio que desee actualizar con los datos de topología creados

manualmente.6. Aplique los cambios al nuevo descubrimiento utilizando los asistentes de gestión de topología de la

Vista de saltos de red.

• Puede añadir dispositivos manualmente desde cualquier ventana de la Vista de saltos de red.• Para añadir conexiones manualmente, se recomienda apuntar la ventana de la Vista de saltos de

red al dispositivo del extremo a (especificado utilizando el atributo fromdevice en la conexión) ycrear una conexión manual con el dispositivo del extremo b (especificado utilizando el atributotodevice).

Para obtener más información sobre la edición de la topología de red utilizando los asistentes degestión de topología, consulte la publicación Guía del usuario de IBM Tivoli Network Manager.

Siga estos pasos para utilizar los asistentes de gestión de topología para añadir los dispositivos y lasconexiones del fragmento de código XML de ejemplo a la topología.

a) Pulse el icono Incidencia y seleccione Disponibilidad de red > Vista de saltos de red.b) Seleccione un dominio de red en la lista desplegable Dominio correspondiente a la línea 2 en el

código XML de ejemplo siguiente.c) Siga estos pasos para añadir todos los dispositivos especificados en el archivo XML:

i) Haga clic con el botón derecho en cualquier lugar de la Vista de saltos de red y, a continuación,haga clic en Gestión de topología > Añadir dispositivo.

ii) En el asistente Añadir dispositivo, añada el dispositivo aog.dom39.1 especificando losatributos listados en las líneas de la 21 a la 35 del archivo XML.

Nota: Tenga en cuenta lo siguiente:

• Los atributos en el archivo XML aparecen en orden alfabético. El orden en el que los solicita laGUI es otro.


• El archivo XML puede que no muestre todos los atributos solicitados por la GUI para undispositivo o una conexión específica. Si faltan atributos, no especifique ningún valor en laGUI.

Complete todas las pantallas del asistente y haga clic en Finalizar y Cerrar. El dispositivo queha añadido aparece en la Vista de saltos de red.Para obtener más información sobre la ediciónde la topología de red utilizando los asistentes de gestión de topología, consulte la publicaciónGuía del usuario de IBM Tivoli Network Manager.

iii) Haga clic con el botón derecho en cualquier lugar de la Vista de saltos de red y, a continuación,haga clic en Gestión de topología > Añadir dispositivo y añada el dispositivo aog.dom39.2especificando los atributos listados en las líneas de la 36 a la 42 del archivo XML. Completetodas las pantallas del asistente y haga clic en Finalizar y Cerrar. El dispositivo que ha añadidoaparece en la Vista de saltos de red.

iv) Haga clic con el botón derecho en cualquier lugar de la Vista de saltos de red y, a continuación,haga clic en Gestión de topología > Añadir dispositivo y añada el dispositivo aog.dom39.3especificando los atributos listados en las líneas de la 43 a la 48 del archivo XML. Completetodas las pantallas del asistente y haga clic en Finalizar y Cerrar. El dispositivo que ha añadidoaparece en la Vista de saltos de red.

d) Siga estos pasos para añadir todas las conexiones especificadas en el archivo XML:

i) En la Vista de saltos de red, vaya a la vista de salto que contiene el dispositivoaog.dom39.1.Para obtener más información sobre cómo buscar un dispositivo en la Vista desaltos de red, consulte la publicación Guía del usuario de IBM Tivoli Network Manager.

ii) Haga clic con el botón derecho en el dispositivo aog.dom39.1 y haga clic en Gestión detopología > Añadir conexión.

iii) En el asistente Añadir conexión, añada una conexión del dispositivo aog.dom39.1 al dispositivoaog.dom39.2 especificando los atributos listados en las líneas de la 4 a la 8 del archivo XML.Complete todas las pantallas del asistente y haga clic en Finalizar y Volver a centrar y Cerrar.La conexión que ha añadido aparece en la Vista de saltos de red.Para obtener más informaciónsobre la edición de la topología de red utilizando los asistentes de gestión de topología, consultela publicación Guía del usuario de IBM Tivoli Network Manager.

iv) En la Vista de saltos de red, asegúrese de que está en la vista de salto que contiene eldispositivo aog.dom39.2 y, a continuación, haga clic con el botón derecho en el dispositivoaog.dom39.2 y haga clic en Gestión de topología > Añadir conexión. Añada una conexión deldispositivo aog.dom39.2 a la interfaz [ GigabitEthernet0/1/0/1 ] en el dispositivo 172.20.1.3especificando los atributos listados en las líneas de la 9 a la 13 del archivo XML. Complete todaslas pantallas del asistente y haga clic en Finalizar y Volver a centrar y Cerrar. La conexión queha añadido aparece en la Vista de saltos de red.

v) En la Vista de saltos de red, asegúrese de que está en la vista de salto que contiene eldispositivo 172.20.1.3 y, a continuación, haga clic con el botón derecho en el dispositivo172.20.1.3 y haga clic en Gestión de topología > Añadir conexión. Añada una conexión de lainterfaz [ Null0 ] en el dispositivo 172.20.1.3 a la interfaz [ Nu0 ] en el dispositivo 172.20.3.3especificando los atributos listados en las líneas de la 14 a la 20 del archivo XML. Completetodas las pantallas del asistente y haga clic en Finalizar y Volver a centrar y Cerrar. Laconexión que ha añadido aparece en la Vista de saltos de red.

7. Si tenía dispositivos en la instalación de origen que no se han gestionado, complete los siguientespasos para cada dominio. Network Manager No sondea los dispositivos no gestionados y éstos no seincluyen en RCA. Si se han gestionado todos los dispositivos, no es necesario que realice los pasossiguientes.

8. En la instalación de destino, cambie al directorio siguiente: $NCHOME/precision/bin9. Ejecute el script de UnmanageNode.pl para el dominio que desea actualizar con los datos de estado

gestionados.Utilice un mandato similar al siguiente:

ncp_perl UnmanageNode.pl -domain DOMAIN_NAME -user ncim -pwd password -noMainNodeLookup -file


$NCHOME/var/precision/export/managedstatus/UnmanagedEntities.DOMAIN_NAME.dat

Donde:

• NOMBRE_DOMINIO es el dominio que está actualizando CON los datos de estado gestionado.• contraseña es la contraseña del usuario de ncim.• El archivo .dat es una lista de entidades no gestionadas generada por el proceso de exportación.

Hay una lista para cada dominio.

Para obtener más información sobre el script UnmanageNode, consulte la publicación IBM TivoliNetwork Manager IP Edition Administration Guide.

El script muestra los nombres de los nodos principales y las interfaces que se han colocado en unestado no gestionado. Por ejemplo:

'aaa-11-12345.core.test.lab[ Lo0 ]' unmanaged.'bbb-22-12345.core.eu.test.lab' unmanaged.

Adición de un dispositivo añadido manualmente y conexión a la topología de redEl siguiente ejemplo muestra cómo añadir un dispositivo y una conexión utilizando un fragmento decódigo XML de un archivo XML generado por el script de importación. El siguiente fragmento de códigoXML representa tres muestra tres dispositivos añadidos manualmente y tres conexiones añadidasmanualmente.

Nota: Aparecen entradas de etiqueta para las conexiones antes de las entradas para los dispositivos en elarchivo XML. No obstante, cuando vuelve a aplicar la topología manual utilizando el editor de topologías,primero debe añadir todos los dispositivos especificados en el archivo y, posteriormente, añadir lasconexiones.


Tabla 12. Fragmento de código XML del archivo de topología manual

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849

<?xml version='1.0' standalone='yes'?><ManualTopology domain="DOMAIN_39" version="3.9" > <Connection connectivity="Layer 3 Meshed Topology" fromdevice="aog.dom39.1" reason="reas" speed="1111" todevice="aog.dom39.2" /> <Connection connectivity="Layer 3 Meshed Topology" fromdevice="aog.dom39.2" reason="" todevice="172.20.1.3" tointerface="[ GigabitEthernet0/1/0/1 ]" /> <Connection connectivity="Layer 2 Topology" fromdevice="172.20.1.3" frominterface="[ Null0 ]" reason="" speed="2345" todevice="172.20.3.3" tointerface="[ Nu0 ]" /> <Device entityname="aog.dom39.1" accessipaddress="192.168.11.1" accessprotocol="IPv4" classname="Cisco" description="aog.dom39.1 desc" displaylabel="aog.dom39.1" ipforwarding="forwarding" modelname="aog.dom39.1 modelname" reason="aog.dom39.1 reason" serialnumber="ser.123" syscontact="aog.dom39.1 syscont" sysdescr="aog.dom39.1 sysdesc" syslocation="aog.dom39.1 sysloc" sysname="aog.dom39.1 sysname" typename="Chassis" /> <Device entityname="aog.dom39.2" accessipaddress="192.168.11.2" accessprotocol="IPv4" classname="Cisco" displaylabel="aog.dom39.2" reason="" typename="Chassis" /> <Device entityname="aog.dom39.3" accessprotocol="IPv4" classname="Cisco" displaylabel="aog.dom39.3" reason="" typename="Chassis" /></ManualTopology>

En la siguiente tabla se resumen los elementos y los atributos XML en este fragmento de código XML:

Tabla 13. Descripción del fragmento de código XML de un archivo de topología manual

Número delínea Descripción

2 Dominio al que se aplica esta topología manual.

4 - 8 Conexión manual entre el dispositivo añadido manualmente "aog.dom39.1" y otrodispositivo añadido manualmente "aog.dom39.2".

9 - 13 Conexión manual entre el dispositivo añadido manualmente "aog.dom39.2" y unainterfaz [ GigabitEthernet0/1/0/1 ] en el dispositivo descubierto 172.20.1.3.

Nota: El dispositivo 172.20.1.3 no aparece en una etiqueta <Device> en este archivodebido a que no es un dispositivo añadido manualmente y, por lo tanto, debe ser undispositivo descubierto.


Tabla 13. Descripción del fragmento de código XML de un archivo de topología manual (continuación)

Número delínea Descripción

14 - 20 Conexión manual entre la interfaz [ Null0 ] en el dispositivo descubierto 72.20.1.3 y lainterfaz [ Nu0 ] en el dispositivo descubierto 172.20.3.3.

Nota: El dispositivo 172.20.3.3 no aparece en una etiqueta <Device> en este archivodebido a que no es un dispositivo añadido manualmente y, por lo tanto, debe ser undispositivo descubierto.

21 - 35 Dispositivo añadido manualmente aog.dom39.1.

36 -42 Dispositivo añadido manualmente aog.dom39.2.

43 - 49 Dispositivo añadido manualmente aog.dom39.3.


Capítulo 9. Configuración de Network ManagerUna vez instalado Network Manager, debe configurar Network Manager para su entorno y requisitos. Si suentorno o requisitos cambian más adelante o si desea integrar Network Manager con otros productos,tendrá que realizar tareas de configuración adicionales.

Configuración de las propiedades de conexión NCIMPuede configurar las propiedades específicas del proveedor para el administrador de controladores JDBCdespués de instalar la base de datos de topología NCIM y los componentes de la GUI.

Acerca de esta tareaPara establecer propiedades específicas del proveedor, para el administrador de controladores JDBC,complete los siguientes pasos:

Procedimiento1. Cree un archivo de propiedades Java con las propiedades y valores que desee.

Consulte la documentación del proveedor de su base de datos sobre JDBC para obtener detalles sobrelas propiedades disponibles.

2. Guarde el archivo a un directorio en el servidor donde los componentes de la GUI estén instalados:$NMGUI_HOMEprofile/etc/tnm/

3. Edite el archivo $NMGUI_HOME/profile/etc/tnm/tnm.properties y agregue una línea que diga:tnm.database.connection.propertiesFile=properties_file

Donde properties_file es el nombre del archivo de propiedades que acaba de crear.

Configuración de la longitud y el tipo de cifradoDesde Network Manager Fix Pack 9, puede utilizar claves de cifrado de entre 128 y 256 bits. Tambiénpuede elegir el cifrado CBC o EBC. Después de actualizar a Fix Pack 9, debe completar algunos pasos deconfiguración posteriores a la instalación para cambiar el valor predeterminado de 128 bits.

Acerca de esta tareaPara utilizar el cifrado predeterminado de 128 bits no es necesario realizar ningún cambio. Para utilizar elcifrado de 192 bits o 256 bits, debe configurar los componentes principales Network Manager o loscomponentes de la GUI manualmente. El cifrado de los componentes principales y la GUI esindependiente y puede ser diferente. Cerciórese de que Storm utilice el mismo archivo y tipo de cifradoque los componentes principales.

ProcedimientoConfigure los componentes principales Network Manager.

1. Cierre todos los procesos Network Manager.Puede utilizar el comando itnm_stop.

2. Si desea cambiar la longitud del código de cifrado, edite el archivo $NCHOME/etc/precision/ConfigSchema.cfg y cambie el valor que se inserta en config.settings.m_KeyLength por lalongitud del nuevo código en bits. Los valores permitidos son 128, 192 y 256.

3. Si desea configurar el tipo de cifrado, cambie el valor de m_EncryptAlgorithm a AES_CBC oAES_EBC.


4. Utilice el programa de utilidad nco_keygen para generar una nueva clave de cifrado. Asegúrese deque especifica el archivo de salida como $NCHOME/etc/security/keys/conf.key.

Para obtener más información, consulte el tema Generar un código en un archivo de código dentro deIBM Knowledge Center para IBM Tivoli Netcool/OMNIbus en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

5. Reinicie todos los procesos Network Manager.Puede utilizar el comando itnm_start.

6. Con el nuevo código de cifrado, vuelva a cifrar todas las contraseñas que se utilizan actualmente enlos archivos de configuración utilizando la utilidad ncp_crypt al escribir el siguiente comando.

ncp_crypt -password password

Donde password es la contraseña a cifrar.Si cambió la ubicación del archivo de código o el tipo de cifrado de los componentes principales, configureStorm para que coincida.

7. Edite el archivo $NCHOME/precision/storm/conf/NMStormTopology.properties.8. Configure la ubicación del archivo del código editando la siguiente propiedad:

tnm.fips.key.location=/opt/IBM/tivoli/netcool/etc/security/keys/conf.key

9. Para cambiar el modo de cifrado, edite la siguiente propiedad y establézcala en CBC o EBC:

nm.cipher_mode=CBC

Configure los componentes de la GUI.10. Detenga los procesos de la GUI.

Puede utilizar el comando itnm_stop.11. Utilice el programa de utilidad nco_keygen para generar una nueva clave de cifrado. Asegúrese de

especificar el archivo de salida como $NMGUI_HOME/profile/etc/tnm/encryption/keys/conf.key. Puede sobrescribir el archivo existente de código o utilizar un nombre nuevo.

12. Si es necesario, ajuste la propiedad del archivo de código para que sea propiedad del usuario delsistema operativo que ejecuta la GUI, y ajuste los permisos de archivo del archivo de código para quesolo ese usuario tenga permiso de lectura sobre este.

13. Si otorgó un nuevo nombre al archivo de código, edite el archivo $NMGUI_HOME/profile/etc/tnm/tnm.properties y cambie tnm.fips.key.location para que apunte a él.La ubicación es relativa a $NMGUI_HOME/profile/etc/tnm.

14. Reinicie los procesos de la GUI.Puede utilizar el comando itnm_start.

15. Inicie sesión en la GUI como administrador.16. Seleccione Administración > Configuración de acceso a la base de datos en el menú.17. Ingrese la contraseña de la base de datos de topología en los cuadros Contraseña y Confirmar

contraseña.18. Haga clic en el icono Guardar.19. Cierre sesión.20. Reinicie la GUI nuevamente.

Configuración de Network Manager para los sistemas operativosUNIX

En los sistemas UNIX, es posible que tenga que realizar tareas de configuración extra antes de utilizar elproducto.




Configuración de permisos root/no rootEn UNIX, si ha instalado Network Manager como usuario no root, debe realizar una configuraciónadicional.

Acerca de esta tareaAlgunos componentes de Network Manager requieren permisos root para ejecutarse. Debe realizardiferentes acciones dependiendo de si quiere ejecutar Network Manager como usuario root o no root.

Instalación root y no rootEn UNIX, Network Manager se puede instalar como usuario root o como usuario no root.

Si ha instalado cualquier otro producto de IBM Tivoli en el mismo directorio de instalación, debe instalarNetwork Manager como el mismo usuario que instaló el resto de los productos.

Las aplicaciones web de Network Manager siempre se deben ejecutar como el usuario que ha instalado elproducto.

Tras la instalación, puede configurar los componentes principales de Network Manager para que seejecuten como un usuario distinto. Por ejemplo, si instaló como el usuario root, puede configurar loscomponentes principales para que se ejecuten como un usuario no root.

Restricción: Cuando Network Manager se instala y ejecuta como root, los scripts instalados reinicianNetwork Manager y los procesos Tivoli Netcool/OMNIbus cuando se vuelve a arrancar el servidor. CuandoNetwork Manager se instala y ejecuta como un usuario no root, Network Manager y los procesos deTivoliNetcool/OMNIbus no se reinician automáticamente cuando se vuelve a arrancar el servidor. No obstante,como tarea de posterior a la instalación para las instalaciones no root, puede configurar los procesos paraque se inicien automáticamente cuando reinicie el sistema, como se describe en “Configuración del inicioautomático de procesos en una instalación no root” en la página 161.

Restricción: IBM Tivoli Business Service Manager debe ejecutarse como no root. Al instalar NetworkManager e IBM Tivoli Business Service Manager en el mismo servidor, asegúrese de que instala y ejecutalos dos como usuario no root.

Configuración de los componentes principales para ejecutarlos como rootEn UNIX, si ha instalado Network Manager como usuario no root, debe realizar una configuraciónadicional para ejecutar los componentes principales como el usuario root.

Antes de empezarLas aplicaciones web de Network Manager siempre se deben ejecutar como el usuario que ha instalado elproducto.

Acerca de esta tareaDebe ejecutar un script que actualice los permisos de archivo para asegurarse de que el usuario root tieneacceso a todos los archivos necesarios.

Si ha instalado Network Manager como usuario root, no tendrá que realizar ninguna configuración paraejecutar los componentes clave como el usuario root.

Procedimiento1. Inicie sesión en el servidor de Network Manager en el que están instalados los componentes. Inicie

sesión como usuario root.2. Ejecute el script NCHOME/precision/scripts/setup_run_as_root.sh.

Capítulo 9. Configuración de Network Manager 159

Configuración de los componentes principales para ejecutar como no rootEn UNIX, si ha instalado Network Manager como un usuario no root y desea que los permisos de usuarioejecuten los componentes principales, debe iniciar sesión como root y realizar una configuraciónadicional.

Antes de empezarAtención: Instale y ejecute únicamente como usuario no root en los servidores en los que losusuarios de confianza sean los únicos usuarios que pueden iniciar sesión.

Las aplicaciones web de Network Manager siempre se deben ejecutar como el usuario que ha instalado elproducto.

Acerca de esta tareaPara otorgar a un usuario no root estos permisos, debe ejecutar un script. No es posible instalar y ejecutarNetwork Manager sin haber iniciado sesión alguna vez como el usuario root. Como mínimo, deberá iniciarsesión como root de forma temporal para ejecutar este script.

Importante: En Linux on IBM z Systems, debe instalar el software de GSKit antes de ejecutar el scriptsetuid.

Instalación de GSKit en AIXAntes de configurar los componentes principales para ejecutarlo como no root en AIX, debe instalar IBMGlobal Secure ToolKit (GSKit).

Antes de empezarAsegúrese de que tiene la versión 8.0.50.87 o posterior de GSKit, un software de criptografía de IBM quepermite la comunicación SSL (Secure Socket Layer). GSKit está incluido en el paquete de instalación deNetwork Manager.

Acerca de esta tareaAntes de ejecutar el script setup_run_as_setuid_root.sh, debe instalar GSKit en eldirectorio /usr/lib. Los procesos que se ejecutan como setuid no utilizan la variable de entornoLIBPATH y, de esta manera, no se puede utilizar GSKit si está instalado en un subdirectorio de $NCHOME.

Para instalar GSKit en AIX en /usr/lib utilizando el mandato installp, complete las siguientes tareas.

Procedimiento1. Inicie sesión como usuario root.2. Cambie al directorio siguiente: $NCHOME/precision/scripts/.3. Abra un indicador de mandatos y especifique los siguientes mandatos.

installp -acgXd . GSKit8.gskcrypt64.ppc.rteinstallp -acgXd . GSKit8.gskssl64.ppc.rte

Donde -a representa aplicar, -c representa confirmar, -g instala de forma automática o confirmacualquier producto de software necesario, -X expande el sistema de archivos si es necesario y -despecifica la ubicación del soporte de instalación.

Configuración de los componentes principales para ejecutar como no rootComplete los siguientes pasos de configuración para ejecutar los componentes principales como usuariono root.



Procedimiento1. Inicie sesión como usuario root.2. Ejecute el script NCHOME/precision/scripts/setup_run_as_setuid_root.sh.3. Si está utilizando el analizador mttrapd (también conocido como el analizador SNMP) en el mismo

servidor que Network Manager, realice una se está ejecutando adicional para habilitar que elanalizador se ejecute con permisos de root:

• Configure el analizador como usuario no-root utilizando las instrucciones en Ejecución deanalizadores como root SUID en la guía IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide.

• En AIX, también debe seguir las instrucciones que se proporcionan en esta URL: http://www.ibm.com/support/docview.wss?uid=swg21296292

Importante: Tenga en cuenta que ya que estas instrucciones implican la copia de bibliotecasSybase en el directorio /usr/lib, puede afectar al funcionamiento de cualquier instalación deSybase que se encuentre en el mismo servidor que la sonda mttrapd.

ResultadosUna vez haya finalizado este script, el usuario que ha realizado la instalación de Network Manager puedeiniciar sesión y ejecutar los componentes principales de Network Manager.

Configuración del inicio automático de procesos en una instalación no rootEn los sistemas UNIX, como una tarea posterior a la instalación para las instalaciones no root, puedeconfigurar los procesos de Network Manager para que se inicien automáticamente cuando se inicia oreinicia el sistema.

Antes de empezarSu instalación de Network Manager debe haberse completado correctamente antes de realizar los pasossiguientes.

Nota: No es necesario que realice estos pasos si ha instalado Network Manager como usuario root. Elreinicio automático se configura como parte de la instalación root sin necesidad de este paso posterior ala instalación.

Acerca de esta tareaPara configurar los procesos de Network Manager para que se inicien automáticamente:

Procedimiento1. Inicie sesión en el servidor de Network Manager en el que están instalados los componentes. Inicie

sesión como usuario root.2. Ejecute el script NCHOME/precision/install/scripts/create_all_control.sh -auto_only.

Carga de información de MIB actualizadaPara asegurar que el navegador de MIB refleje la información de MIB más actualizada, cargue lainformación de MIB actualizada ejecutando la aplicación de línea de comandos ncp_mib.

Acerca de esta tareaTiene que ejecutar la aplicación de línea de mandatos ncp_mib únicamente cuando los nuevos MIB seagreguen al directorio NCHOME/precision/mibs. Se ejecuta una vez durante la instalación, por lo que sino agrega nuevos MIB, no tiene que ejecutarla de nuevo.




Importante: Todos los MIB deben ser válidos para que se puedan analizar correctamente. El mandatoncp_mib es sensible a mayúsculas y minúsculas y espera un sufijo .mib (no .MIB). El prefijo puede seruna combinación de mayúsculas o minúsculas.

Cuando se ejecute, ncp_mib rellena el esquema de ncmib en la base de datos de NCIM paraproporcionar un almacenamiento central de toda la información de MIB que Network Manager puedaconsultar. El esquema de ncmib dentro de la base de datos NCIM se define en NCHOME/etc/precision/MibDbLogin.cfg; el valor predeterminado es MIB.

Sólo hay una base de datos de MIB para todos los dominios. La opción -domain, if si se especifica,configura ncp_mib para que utilice un archivo MibDbLogin.domain.cfg específico del dominio. Si nose especifica la opción -domain, se utiliza el archivo MibDbLogin.cfg genérico. No hay dependenciasde proceso para este mandato.

En una instalación distribuida, ncp_mib se instala en el servidor de Dashboard Application Services Hub,es decir, en el mismo servidor que las aplicaciones web de Network Manager.

Si su base de datos de MIB se corrompe o si desea importar un nuevo MIB que entre en conflicto con unoque se importara anteriormente, tenga en cuenta las diversas opciones de línea de mandatos ejecutandoncp_mib -help.

Consejo: Si no está seguro de cuál será el resultado de la ejecución de ncp_mib, ejecútelo con la opción-dryrun. Puede ver los resultados, pero la base de datos no se alterará.

Para actualizar la información de MIB, realice los pasos siguientes en el servidor donde está instalado elDashboard Application Services Hub.

Procedimiento1. Copie cualquier archivo MIB nuevo en el directorio NCHOME/precision/mibs.2. Asegúrese de que las credenciales de inicio de sesión de base de datos son correctas.

Los únicos parámetros de configuración requeridos para la aplicación de línea de mandatos dencp_mib son las credenciales de inicio de sesión de base de datos para la base de datos ncim. Estasse almacenan en un archivo de configuración, NCHOME/etc/precision/MibDbLogin.cfg. Tengaen cuenta que, debido a que ncp_mib depende de un dominio, este archivo no tiene variantesespecíficas del dominio como otros archivos de configuración.

3. Inicie el proceso de ncp_mib emitiendo el mandato ncp_mib.

Qué hacer a continuaciónPara verificar que un MIB se haya cargado satisfactoriamente, consulte la tabla de la base de datosncmib.mib_modules escribiendo el mandato siguiente desde la solicitud de la base de datos NCIM(este ejemplo supone que NCIM se está ejecutando en Db2):

select * from ncmib.mib_modules where moduleName ='RFC1213-MIB';

Si el MIB está cargado, se mostrará una tabla que contiene un moduleName de RFC1213-MIB.

También puede verificar que los MIB estén cargados ejecutando el mandato ncp_mib con la opción -messagelevel info. Un mensaje similar al siguiente le informará de que se están procesando los MIB:

09/10/08 12:41:08: Información: I-MIB-001-013: [1096571552t] Resolving references for module 'RFC1213-MIB'

Cuando el proceso se complete, un mensaje mostrará que los MIB se han confirmado en la base de datos.

Consejo: Para obtener información sobre la utilización del navegador de MIB de SNMP y la creación degráficos de variables de MIB, consulte la publicación Guía del usuario de IBM Tivoli Network Manager.

Configuración de Cognos AnalyticsRealice estas tareas para configurar Cognos Analytics.


Tareas relacionadasInstalación y configuración de una base de datos de topologíaEl administrador de base de datos debe instalar y configurar una base de datos de topología soportadaantes de poder instalar Network Manager.Instalación y configuración de Cognos AnalyticsA partir de Network Manager Fix Pack 11, Tivoli Common Reporting no es compatible. Para utilizarinformes, debe instalar y configurar Cognos Analytics.

Configuración de informes para las instalaciones existentesPuede configurar los informes de gestión de red proporcionados por Network Manager para utilizarlos conCognos Analytics.

Antes de empezarPara habilitar los informes de gestión de red, debe tener instalado Cognos Analytics. Si ha instalado loscomponentes de la GUI de Network Manager en una máquina donde ya estaba presente CognosAnalytics, no es necesario realizar estos pasos.

Acerca de esta tareaPara configurar los informes de gestión de la red, utilice la información que aparece en el Centro deconocimiento de Cognos Analytics en https://www.ibm.com/support/knowledgecenter/SSEP7J.

Habilitación del sondeo históricoSi ha instalado Network Manager como usuario root, deberá ejecutar el scriptsetup_run_storm_as_non_root.sh para permitir que se ejecuten los procesos de datos de sondeohistórico. No es necesario que ejecute este script si ha instalado Network Manager como usuario no root.

Acerca de esta tareaComo usuario root, ejecute el script setup_run_storm_as_non_root.sh en el servidor donde estáninstalados los componentes principales de Network Manager. Ejecute el script como en el ejemplosiguiente:

$NCHOME/precision/scripts/setup_run_storm_as_non_root.sh -g group_name

Donde group_name es el nombre del grupo de agregación de sondeador que haya especificado al instalarlos componentes principales de Network Manager.

Nota: Cuando instaló los componentes principales de Network Manager, especificó valores para el grupode agregación del sondeador y para el usuario de agregación del sondeador, que es un miembro del grupode agregación del sondeador. El usuario de agregación del sondeador aparece en el archivo deconfiguración $NCHOME/precision/storm/conf/supervisor.conf, dentro del campo user de lasección [supervisord] de dicho archivo.

Para obtener más información sobre el script setup_run_storm_as_non_root.sh, consulte IBM TivoliNetwork Manager IP Edition Administration Guide.

Tareas relacionadasInstalación de los componentes principales de Network ManagerDebe instalar los componentes principales de Network Manager antes o al mismo tiempo que lainstalación de los componentes de GUI.

Habilitación de la migración tras errorPuede habilitar la migración tras error en el entorno de Network Manager para asegurarse de que losdiferentes componentes sean ejecutables y estén disponibles.



Acerca de la migración tras errorEn su entorno de Network Manager, una arquitectura de migración tras error se puede utilizar paraconfigurar su sistema para una alta disponibilidad, minimizando el impacto de fallos de sistema o de red.

La migración tras error se puede implementar para cada uno de los siguientes productos y componentes,que se pueden instalar cuando ejecuta el instalador de Network Manager:

• Los componentes principales de Network Manager, incluidos el motor de sondeo y la pasarela desucesos (que incorpora el componente de análisis de causa raíz)

• La base de datos de topología NCIM• Tivoli Netcool/OMNIbus, incluido el ObjectServer (para la gestión de sucesos)• El Tivoli Netcool/OMNIbus GUI web, que se instala en la infraestructura del servidor Dashboard

Application Services Hub

Restricción: Network Manager no soporta la característica de equilibrio de carga de DashboardApplication Services Hub que hace GUI web de Tivoli Netcool/OMNIbus .

Debe decidir para qué componentes desea implementar la migración tras error, y el número de sistemasrequeridos para una alta disponibilidad.

Sobre la alta disponibilidad de base de datos de topología NCIMNetwork Manager permite configurar la base de datos de topología NCIM (Network Connectivity andInventory Model) para una alta disponibilidad, minimizando el impacto de fallos de sistema o de red. Enlas secciones siguientes se proporciona una visión general de la alta disponibilidad de la base de datos detopología NCIM y se explica cómo configurarla.

La alta disponibilidad hace referencia a un entorno informático donde los componentes de hardware ysoftware permanecen operativos durante las paradas planificadas (por ejemplo, operaciones demantenimiento regular) y las paradas no planificadas (por ejemplo, errores inesperados de hardware, redy software). Un componente que debe estar operativo todo el tiempo es la base de datos de topologíaNCIM.

Nota: En los releases anteriores de Network Manager, los usuarios podían incluir una configuración demigración tras error de base de datos de topología NCIM utilizando la réplica de NCIM (tambiéndenominada réplica de base de datos de topología NCIM). La característica de réplica de NCIM se hasustituido por la característica de alta disponibilidad que proporciona la base de datos soportada:

• Si tiene una base de datos Db2, puede utilizar la característica HADR (recuperación tras desastre de altadisponibilidad) para configurar la migración tras error para NCIM.

• Si tiene una base de datos de Oracle, puede utilizar la característica Real Application Clusters (RAC)para configurar la migración tras error para NCIM.

Para configurar la migración tras error para la base de datos de topología NCIM y proporcionar a losusuarios un entorno de alta disponibilidad para ejecutar las aplicaciones de la base de datos y acceder ala información almacenada en la base de datos de topología NCIM, deberá estar familiarizado con lossiguientes temas y tareas relacionadas:

• Estrategias de alta disponibilidad proporcionadas por la base de datos• Arquitectura de migración tras error de la base de datos de topología NCIM y los procesos principales

de Network Manager• Tareas asociadas con la instalación de la base de datos

Alta disponibilidad utilizando Db2Puede utilizar la característica HADR de Db2 para configurar la réplica de datos de una base de datosprimaria a una base de datos de copia de seguridad. Normalmente, la base de datos primaria procesatoda o la mayoría de la carga de trabajo de la aplicación, mientras que la base de datos de copia deseguridad puede encargarse de la carga de trabajo si la base de datos primaria falla, permitiendo que la


base de datos siga estando disponible para las aplicaciones del usuario. En un entorno de HADR de Db2,la base de datos de copia de seguridad se conoce como base de datos en espera.

Mediante el uso de la característica HADR, la ACR (redirección automática de cliente) de Db2 proporcionala redirección de las conexiones de cliente de Network Manager al servidor de NCIM primario adecuado.

Puede utilizar IBM Tivoli System Automation for Multiplatforms (SA MP) para ascender un servidor de Db2en espera para que pase a ser el primario cuando falle el que actúa como primario.

Nota: Db2 proporciona las herramientas necesarias para instalar y configurar la base de datos detopología NCIM (y los procesos principales) para que utilice la característica HADR de Db2. Para obtenerinformación sobre cómo instalar y configurar Db2, consulte Información relacionada más adelante paraver los enlaces al Information Center de Db2.

Agrupación en clústeres y alta disponibilidad utilizando RAC de OracleOracle proporciona la función Real Application Clusters (RAC) para la agrupación en clústeres y altadisponibilidad en entornos de base de datos Oracle. Mediante RAC de Oracle, puede crear unaconfiguración de alta disponibilidad para su base de datos de topología NCIM. Para obtener informaciónsobre cómo instalar y configurar RAC de Oracle, consulte la información relacionada más adelante, paraver un enlace a la documentación de Oracle.

Arquitectura de migración tras error de la base de datos de topología NCIM y losprocesos principales de Network ManagerLa migración tras error de los procesos principales de Network Manager se puede implementarestableciendo las instalaciones principales y de copia de seguridad de Network Manager que se ejecutanen distintos servidores y dominios. Ambas instalaciones pueden conectarse a un único ObjectServer deTivoli Netcool/OMNIbus o a un par virtual de ObjectServers. Se puede implementar migración tras errorde Network Manager con alta disponibilidad de base de datos de topología NCIM o sin alta disponibilidadde base de datos de topología NCIM. Si elige implementar la migración tras error con la altadisponibilidad de base de datos de topología NCIM, deberá hacerlo con la característica de altadisponibilidad que proporciona la base de datos soportada. Por ejemplo, para establecer unaconfiguración de migración tras error para la base de datos de topología NCIM si tiene una base de datosDb2, puede utilizar la función de recuperación tras desastre de alta disponibilidad (HADR) de DB2. De lamisma forma, si tiene una base de datos de Oracle, puede utilizar la función Real Application Clusters(RAC) para la migración tras error de NCIM.

Tareas asociadas con la instalación de la base de datosUna base de datos Db2 se puede instalar y configurar mediante Network Manager. Para utilizar una basede datos Db2 u Oracle independiente, configúrela tal como se describe en “Instalación y configuración deuna base de datos de topología” en la página 51.

Conceptos relacionadosArquitectura de migración tras error de Network Manager (procesos principales)La migración tras error de los procesos principales de Network Manager se puede implementarestableciendo las instalaciones principales y de copia de seguridad de Network Manager que se ejecutanen distintos servidores. Ambas instalaciones pueden conectarse a un único ObjectServer de TivoliNetcool/OMNIbus o a un par virtual de ObjectServers.Host de migración tras error de ejemplo con alta disponibilidad de base de datos de topología NCIMEste es un ejemplo de host de migración tras error donde la configuración de migración tras error incluyeuna copia de la base de datos de topología de NCIM en la instalación de copia de seguridad.Tareas relacionadasInstalación y configuración de una base de datos de topologíaEl administrador de base de datos debe instalar y configurar una base de datos de topología soportadaantes de poder instalar Network Manager.


Arquitecturas de migración tras errorLa migración tras error de Network Manager se implementa independientemente de la migración traserror en los productos y componentes con los que se integre. Antes de configurar la migración tras error,debe comprender las arquitecturas de migración tras error que se pueden implementar para ayudar aasegurar la alta disponibilidad de su instalación de Network Manager.

Una instalación de migración tras error de Network Manager contiene un servidor principal y de copia deseguridad de Network Manager en el que se instalan los componentes principales. Si el servidor principalfalla como consecuencia de los problemas con el hardware o el software, el servidor de copia deseguridad supone el rol del servidor principal. Para un entorno más sólido, puede incluir de formaadicional una o varias de las configuraciones de migración tras error siguientes:

• Un ObjectServer principal o de copia de seguridad de Tivoli Netcool/OMNIbus• Migración tras error de origen de datos de GUI web de Tivoli Netcool/OMNIbus• Una configuración de alta disponibilidad de base de datos de topología NCIM


– Si tiene una base de datos Db2, puede utilizar la característica HADR (recuperación tras desastre dealta disponibilidad) para configurar la migración tras error para NCIM.

– Si tiene una base de datos de Oracle, puede utilizar la característica Real Application Clusters (RAC)para configurar la migración tras error para NCIM.

Esta configuración de alta disponibilidad de base de datos de topología NCIM garantiza que el sondeode la red pueda continuar en la instalación de copia de seguridad, y que se repliquen las vistas de latopología.

Para acomodar el fallo del hardware o del software, y para el rendimiento óptimo de su entorno,implemente su solución de migración tras error en más de un sistema.

Arquitectura de migración tras error de ObjectServerPuede desplegar Tivoli Netcool/OMNIbus mediante el uso de una arquitectura de varios niveles escalable,para que el sistema pueda continuar funcionando en su capacidad completa (y con mínima pérdida desucesos) en el caso de un fallo de ObjectServer, Pasarela de ObjectServer o servidor de proxy.

Los componentes de la arquitectura se encuentran dentro de tres niveles (o capas): recopilación,agregación y visualización. La configuración de migración tras error básica consta de un ObjectServerprincipal y de un ObjectServer de copia de seguridad que están conectados mediante una Pasarela deObjectServer bidireccional en la capa de agregación, sin capas de recopilación ni visualizaciónconectadas. El diseño modular de la arquitectura de varios niveles significa que cualquier sistema puedecomenzar con un par sencillo de ObjectServers de agregación y, a continuación, tener componentes derecopilación o de visualización agregados en cualquier momento del futuro.

La cifra siguiente muestra un ejemplo de la configuración de migración tras error básica en la capa deagregación.


Figura 7. Arquitectura de migración tras error de ObjectServer

Para minimizar el impacto del fallo informático, el ObjectServer principal (AGG_P) y el ObjectServer decopia de seguridad (AGG_B) se ejecutan en dos sistemas separados. La Pasarela de ObjectServerbidireccional (AGG_GATE) se ejecuta en el sistema de ObjectServer de copia de seguridad, y sincronizalos ObjectServers. Los ObjectServers principal y de copia de seguridad se configuran como un par deagregación virtual (AGG_V) al que las sondas y otros clientes, como por ejemplo la Pasarela de sucesos,se pueden conectar directamente. El concepto de un par virtual ayuda a facilitar una migración tras erroruniforme al ObjectServer de copia de seguridad si el ObjectServer principal se vuelve no disponible, y unaconmutación por recuperación cuando el ObjectServer principal está activo de nuevo. En la cifra, tambiénse muestran los destinos de ejemplo a las alertas a las que se pueden reenviar desde la capa deagregación.

Para obtener información completa acerca de la configuración de la migración tras error de ObjectServeren las capas de recopilación, agregación y visualización de la arquitectura de varios niveles, consulte lapublicación IBM Tivoli Netcool/OMNIbus Installation and Deployment Guide en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.





Tareas relacionadasConfiguración de la migración tras error de ObjectServerLa manera en la que configure la migración tras error de ObjectServer depende de la versión de TivoliNetcool/OMNIbus.

Acerca de los archivos de configuración de migración tras error de Tivoli Netcool/OMNIbusTivoli Netcool/OMNIbus V7.3 o posterior, proporciona un conjunto de archivos de configuración quepuede aplicar a ObjectServers y Pasarelas de ObjectServer para implementar la arquitectura de variosniveles.

Estos archivos están disponibles en el directorio $NCHOME/omnibus/extensions/multitier, eincluyen:

• Los archivos de importación de SQL que se pueden aplicar a cada ObjectServer, para actualizar elesquema de base de datos con la configuración requerida; por ejemplo, las columnas adicionales, lasconversiones y las automatizaciones

• Los archivos de Pasarela de ObjectServer que se pueden utilizar para configurar las pasarelas de laarquitectura

Importante:

• Al utilizar los archivos de configuración facilitados en Tivoli Netcool/OMNIbus V7.3 o posterior, debeadherirse a la convención de denominación definida para los componentes de cada capa de laarquitectura de varios niveles. Para implementar la migración tras error en la capa de agregación, utilicelas convenciones de denominación representadas en la Figura 7 en la página 167; es decir, AGG_P parael ObjectServer principal, AGG_B para el ObjectServer de copia de seguridad, AGG_V para el par virtualy AGG_GATE para la Pasarela de ObjectServer bidireccional.

• En versiones anteriores de Tivoli Netcool/OMNIbus, no se facilita ningún archivo de configuración, y noes obligatorio que esté en conformidad con estas convenciones de denominación.

Para obtener más información sobre los archivos de configuración de varios niveles y las convenciones dedenominación para los componentes en la arquitectura de varios niveles, consulte la publicación IBMTivoli Netcool/OMNIbus Installation and Deployment Guide en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

Arquitectura de migración tras error de Network Manager (procesosprincipales)La migración tras error de los procesos principales de Network Manager se puede implementarestableciendo las instalaciones principales y de copia de seguridad de Network Manager que se ejecutanen distintos servidores. Ambas instalaciones pueden conectarse a un único ObjectServer de TivoliNetcool/OMNIbus o a un par virtual de ObjectServers.

Cuando se conecte a un servidor de Network Manager, el dominio asociado bajo el que las ejecuciones delos procesos necesitan identificarse. Network Manager Proporciona un dominio virtual que se puedeutilizar al ejecutar en la modalidad de migración tras error. Cualquier conexión a este dominio virtual sedirecciona hasta la instalación de Network Manager que se ejecuta como el servidor principal en laarquitectura de migración tras error. Esta función de direccionamiento se proporciona mediante elcomponente de Dominio virtual.

La cifra siguiente muestra la arquitectura de migración tras error de alto nivel para los procesosprincipales y de copia de seguridad de Network Manager, que se configuran en dos dominios separados.




Figura 8. Arquitectura de migración tras error de Network Manager

En la cifra, tanto las instalaciones primarias como de copia de seguridad se conectan a un par virtual deObjectServers.

En cada dominio:

• El componente Dominio virtual (ncp_virtualdomain) gestiona la migración tras error, y crea sucesosde comprobación de estado para indicar si el dominio está sano.

• La Sonda para Tivoli Netcool/OMNIbus (nco_p_ncpmonitor) se conecta al par virtual de ObjectServery reenvía los sucesos de comprobación de estado.

• La Pasarela de sucesos (ncp_g_event) se conecta al par virtual ObjectServer, lee en todos los sucesosde comprobación de estado y, a continuación, pasa los sucesos a un componente Dominio virtual.

Estos sucesos de comprobación de estado se utilizan para desencadenar la migración tras error.

Se requiere una conexión de socket de TCP entre los procesos de Dominio virtual para copiar datos desdeel dominio principal hasta el dominio de copia de seguridad. Esto asegura que la topología estésincronizada cuando se produzca la migración tras error.

Nota: Si implementa una migración tras error, tiene que asegurarse de que las instalaciones primaria y decopia de seguridad están utilizando claves de cifrado idénticas. Si las claves de cifrado no son idénticas, elsondeador de copia de seguridad no funciona correctamente durante la migración tras error. Paraasegurarse de que las instalaciones primaria y de copia de seguridad están utilizando claves de cifradoidénticas, copie el archivo siguiente del servidor primario a la misma ubicación en el servidor de copia deseguridad: $NCHOME/etc/security/keys/conf.key. Si entra todas las cadenas de comunidad SNMPen la línea de mandatos y no las cifra, no tiene que realizar esta tarea. Para obtener más informaciónsobre cómo cambiar la clave de cifrado, consulte IBM Tivoli Network Manager IP Edition AdministrationGuide. Además, para actualizar las contraseñas de NCIM y ObjectServer, utilice el script de Perlncp_password_update.pl. Para obtener más detalles sobre el script Perlncp_password_update.pl, consulte IBM Tivoli Network Manager IP Edition Administration Guide.

Implementaciones de NCIM para la migración tras errorPuede configurar la migración tras error de Network Manager con la alta disponibilidad de la base dedatos de topología de NCIM. Esta configuración de migración tras error protege contra la pérdida de datosal replicar los cambios de datos de la base de datos de topología de NCIM de origen del dominio de


Network Manager primario en una o varias bases de datos de NCIM de destino en el dominio de NetworkManager de copia de seguridad. La base de datos de topología NCIM de origen se conoce como la base dedatos primaria y la base de datos de topología NCIM de destino se conoce como la base de datos enespera. Este enfoque elimina el punto único de anomalía, ya que los dominios de Network Managerprimario y de copia de seguridad se conectan a la base de datos que actúe como base de datos primaria.

En cualquier configuración de migración tras error, los dominios de Network Manager primario y de copiade seguridad se conectan a la misma base de datos, incluso si está configurada la alta disponibilidad de labase de datos. La diferencia principal es que, con la alta disponibilidad, la base de datos se replica en elservidor de base de datos en espera.




Independientemente de si la migración tras error está configurada con o sin la alta disponibilidad de labase de datos de topología de NCIM, todas las entidades de la topología se almacenarán en el nombre deldominio principal, y todas las políticas de sondeo se configurarán para el dominio principal. No hayninguna entrada en la tabla de domainMgr para el dominio de copia de seguridad. Como resultado, elcampo NmosDomainName para un suceso de la tabla alerts.status siempre se rellenará con el nombredel dominio principal cuando se configure la migración tras error.

Nota: Para configurar la alta disponibilidad de base de datos de topología NCIM utilizando Db2 HADR,configure el entorno HADR siguiendo las instrucciones que se proporcionan en la documentación de Db2.Consulte Información relacionada más adelante para obtener enlaces al Information Center de Db2.Realice luego las tareas para configurar Network Manager para que funcione con Db2 HADR. Si tiene unabase de datos Oracle, configure el entorno RAC de Oracle utilizando las instrucciones que se proporcionanen la documentación de Oracle. Para ver un enlace a la documentación de Oracle, consulte los enlacesrelacionados más adelante. Realice luego las tareas para configurar Network Manager para que funcioneen el entorno RAC de Oracle.

Conceptos relacionadosArquitectura de migración tras error de ObjectServerPuede desplegar Tivoli Netcool/OMNIbus mediante el uso de una arquitectura de varios niveles escalable,para que el sistema pueda continuar funcionando en su capacidad completa (y con mínima pérdida desucesos) en el caso de un fallo de ObjectServer, Pasarela de ObjectServer o servidor de proxy.Migración tras error en la instalación de copia de seguridadTodos los procesos de la instalación de copia de seguridad apuntan a la base de datos de topología deNCIM en la instalación primaria. La base de datos de topología NCIM en la instalación primaria puede seruna base de datos autónoma o una configurada para la alta disponibilidad.Sobre la alta disponibilidad de base de datos de topología NCIMNetwork Manager permite configurar la base de datos de topología NCIM (Network Connectivity andInventory Model) para una alta disponibilidad, minimizando el impacto de fallos de sistema o de red. Enlas secciones siguientes se proporciona una visión general de la alta disponibilidad de la base de datos detopología NCIM y se explica cómo configurarla.Host de migración tras error de ejemplo con alta disponibilidad de base de datos de topología NCIMEste es un ejemplo de host de migración tras error donde la configuración de migración tras error incluyeuna copia de la base de datos de topología de NCIM en la instalación de copia de seguridad.Tareas relacionadasConfiguración de la migración tras error de los procesos principales de Network ManagerConfiguración de bases de datos Db2 existentes en UNIX


Para utilizar una base de datos Db2 existente como base de datos de topología en UNIX, debe tener unainstancia de Db2 disponible antes de instalar Network Manager.Configuración de Network Manager para que funcione con HADR de Db2, o RAC de Oracle

Migración tras error de origen de datos de GUI web de Tivoli Netcool/OMNIbusLa GUI web implementa la migración tras error del origen de datos. Si están disponibles un ObjectServerprincipal y de copia de seguridad, puede configurar conexiones con ambos ObjectServers para que si fallael ObjectServer principal, la GUI web migre tras error y utilice el ObjectServer de copia de seguridad comoel origen de sus sucesos.Tareas relacionadasConfiguración de la migración tras error de origen de datos para la GUI web de Tivoli Netcool/OMNIbusSi tiene un par de migración tras error de ObjectServers a los que se debe conectar la GUI web, puedeconfigurar la migración tras error de origen de datos utilizando el archivo de configuración de origen dedatos ncwDataSourceDefinitions.xml en su instalación de la GUI web.

Asignación de servidor para migración tras errorCualquier sistema principal debe instalarse en un host distinto al sistema de copia de seguridad, para quesi el host principal falla, el host de copia de seguridad no esté afectado.

Idealmente, el ObjectServer principal, el ObjectServer de copia de seguridad, el servidor de NetworkManager principal, el servidor de Network Manager de copia de seguridad y el servidor de DashboardApplication Services Hub se instalarán en hosts distintos. Sin embargo, no será práctico.

Host de migración tras error de ejemplo sin alta disponibilidad de base de datos detopología NCIMEste es un ejemplo de host de migración tras error donde la configuración de migración tras error noincluye una copia de la base de datos de topología de NCIM en la instalación de copia de seguridad.

En cualquier configuración de migración tras error, los dominios de Network Manager primario y de copiade seguridad se conectan a la misma base de datos, pero en una migración tras error configurada con laalta disponibilidad de la base de datos de topología de NCIM no hay réplica de la base de datos en unservidor en espera.

La cifra siguiente muestra un ejemplo de ObjectServer de host y migración tras error de Network Managerutilizando cuatro máquinas host.


Figura 9. Host de migración tras error de ejemplo

Por motivos de rendimiento, la base de datos de topología de NCIM requiere una conexión de ancho debanda alto al servidor de Dashboard Application Services Hub. Si la máquina host 3 tiene varias CPU ymemoria suficiente, puede instalar el NCIM en la máquina host 3.

Instale los componentes principales tanto en las máquinas host 1 como 2, e instale las aplicaciones weben la máquina host 3. Instale la base de datos de topología NCIM en la máquina host 4.


Conceptos relacionadosSobre la alta disponibilidad de base de datos de topología NCIMNetwork Manager permite configurar la base de datos de topología NCIM (Network Connectivity andInventory Model) para una alta disponibilidad, minimizando el impacto de fallos de sistema o de red. Enlas secciones siguientes se proporciona una visión general de la alta disponibilidad de la base de datos detopología NCIM y se explica cómo configurarla.Host de migración tras error de ejemplo con alta disponibilidad de base de datos de topología NCIMEste es un ejemplo de host de migración tras error donde la configuración de migración tras error incluyeuna copia de la base de datos de topología de NCIM en la instalación de copia de seguridad.

Host de migración tras error de ejemplo con alta disponibilidad de base de datos detopología NCIMEste es un ejemplo de host de migración tras error donde la configuración de migración tras error incluyeuna copia de la base de datos de topología de NCIM en la instalación de copia de seguridad.


En cualquier configuración de migración tras error, los dominios de Network Manager primario y de copiade seguridad se conectan a la misma base de datos, pero en una configuración de migración tras errorcon la alta disponibilidad de la base de datos configurada, la base de datos se replica en el servidor debases de datos en espera.




La cifra siguiente muestra un ejemplo de ObjectServer de host y migración tras error de Network Managerutilizando cinco máquinas host.

Figura 10. Host de migración tras error de ejemplo con base de datos de topología de NCIM de copia deseguridad

Por motivos de rendimiento, la base de datos de topología de NCIM requiere una conexión de ancho debanda alto al servidor de Dashboard Application Services Hub. Si la máquina host 3 tiene varias CPU ymemoria suficiente, puede instalar el NCIM principal en la máquina host 3.

Instale los componentes principales tanto en las máquinas host 1 como 2, e instale las aplicaciones weben la máquina host 3. Instale la base de datos de topología NCIM principal en la máquina host 4 y la basede datos de topología de NCIM de copia de seguridad en la máquina host 5.

Conceptos relacionadosMigración tras error en la instalación de copia de seguridadTodos los procesos de la instalación de copia de seguridad apuntan a la base de datos de topología deNCIM en la instalación primaria. La base de datos de topología NCIM en la instalación primaria puede seruna base de datos autónoma o una configurada para la alta disponibilidad.Host de migración tras error de ejemplo sin alta disponibilidad de base de datos de topología NCIMEste es un ejemplo de host de migración tras error donde la configuración de migración tras error noincluye una copia de la base de datos de topología de NCIM en la instalación de copia de seguridad.


Arquitectura de migración tras error de Network Manager (procesos principales)La migración tras error de los procesos principales de Network Manager se puede implementarestableciendo las instalaciones principales y de copia de seguridad de Network Manager que se ejecutanen distintos servidores. Ambas instalaciones pueden conectarse a un único ObjectServer de TivoliNetcool/OMNIbus o a un par virtual de ObjectServers.Sobre la alta disponibilidad de base de datos de topología NCIMNetwork Manager permite configurar la base de datos de topología NCIM (Network Connectivity andInventory Model) para una alta disponibilidad, minimizando el impacto de fallos de sistema o de red. Enlas secciones siguientes se proporciona una visión general de la alta disponibilidad de la base de datos detopología NCIM y se explica cómo configurarla.

Funcionamiento de migración tras error de los procesos principales deNetwork Manager

La migración tras error de los procesos principales de Network Manager está gestionada por el proceso deDominio virtual, ncp_virtualdomain. Utilice esta información para comprender cómo se desencadenanla migración tras error y la conmutación por recuperación de Network Manager.

Sucesos de comprobación de estado y migración tras errorLa migración tras error se rige por las comprobaciones de estado, que se configuran para que se ejecutenperiódicamente a fin de evaluar el estado de los dominios principales y de copia de seguridad de NetworkManager.

En el entorno de migración tras error, todos los procesos de los dominios principal y de copia deseguridad se inician mediante el controlador del proceso maestro, ncp_ctrl. En cada dominio,ncp_ctrl también supervisa regularmente los procesos que están bajo su control, y almacena su estadoen la tabla state.services. El proceso de Dominio virtual aplica filtros (que se definen en la tablastate.filters) en los registros de estado de algunos de los procesos, y genera sucesos de comprobación deestado para indicar si un dominio está sano. Los filtros se aplican a:

• ncp_poller, el Motor de sondeo

Se pueden definir varios filtros para el Motor de sondeo, uno para cada sondeador definido en el archivoCtrlServices.cfg.

• ncp_g_event, la Pasarela de sucesos• ncp_model, el gestor de topología

Los sucesos de comprobación de estado se generan localmente dentro de cada dominio, y también sepueden generar de forma remota mediante un dominio en nombre del otro:

• Dominio local: Si cada registro de estado pasa los filtros, el servidor de Network Manager se considerarásano, y el Dominio virtual generará un suceso de resolución de comprobación de estado para dichodominio. Cada dominio indica al otro que está sano, enviando un suceso de resolución, que sedirecciona mediante el ObjectServer. Un dominio espera recibir un suceso de resolución en un intervaloconfigurado en el archivo de esquema del proceso de Dominio virtual ($NCHOME/etc/precision/VirtualDomainSchema.cfg).

Si falla uno o varios filtros, lo que indica el fallo de uno o varios procesos locales, el Dominio virtualgenerará un suceso de problema de comprobación de estado y de forma adicional direccionará elsuceso del problema al otro dominio.

• Dominio remoto: Si un dominio local detecta que su equivalente remoto no generó un suceso deresolución de comprobación de estado en el intervalo configurado, el dominio local generará un sucesode problema de comprobación de estado sintético para el dominio remoto. Por ejemplo, si el dominio decopia de seguridad no recibe un suceso de resolución de comprobación de estado desde el dominioprincipal, el dominio de copia de seguridad generará un suceso de problema de comprobación deestado para el dominio principal.

Los sucesos de comprobación de estado también se generan cuando se pierde la conectividad a la basede datos de NCIM.


Los sucesos de comprobación de estado tienen el identificador de sucesos "ItnmHealthChk" en el campoEventId de la tabla alerts.status.

Conceptos relacionadosMigración tras error y conmutación por recuperación de Network ManagerTareas relacionadasConfiguración de parámetros para las comprobaciones de estadoSi es necesario, puede configurar las condiciones que prefiera bajo los sucesos de comprobación deestado, especificando inserciones OQL idénticas en el archivo de esquema del proceso de dominio virtual(VirtualDomainSchema.cfg) tanto en el servidor primario como el de copia de seguridad.

Flujo de proceso para sucesos de comprobación de estadoLos sucesos de resolución de comprobación de estado los genera cada servidor de Network Manager paraindicar que está en buen estado. Un suceso de problema de comprobación de estado es uno de losdesencadenantes para la migración tras error de Network Manager.

La cifra siguiente muestra la progresión mediante el sistema de un suceso de comprobación de estadoque genera el servidor principal de Network Manager.

Figura 11. Flujo de proceso de un suceso de comprobación de estado

1 Informe de estadoEl proceso de ncp_ctrl informa sobre el estado de sus servicios gestionados.

2 Diagnóstico de estadoEl proceso del Dominio virtual utiliza sus filtros para realizar un diagnóstico de comprobación deestado:

• Si el sistema está en buen estado, el Dominio virtual generará un suceso de resolución decomprobación de estado y lo enviará a la Sonda para Tivoli Netcool/OMNIbus. De formapredeterminada, los sucesos de comprobación de estado se envían a la sonda cada 60 segundos.

• Si el sistema está en mal estado, el Dominio virtual Domain generará un suceso de problema decomprobación de estado y lo enviará a la Sonda para Tivoli Netcool/OMNIbus.


3 Suceso de comprobación de estado reenviado al ObjectServerLa Sonda para Tivoli Netcool/OMNIbus reenvía el suceso de comprobación de estado al ObjectServer.

4 Suceso de comprobación de salud reenviado a la Pasarela de sucesos principal y de copia deseguridad

El ObjectServer envía el suceso de comprobación de estado a la Pasarela de sucesos de los servidoresprincipales y de copia de seguridad.

5 Suceso de comprobación de estado enviado al Dominio virtual principal y de copia de seguridadLa Pasarela de sucesos principal envía el suceso de comprobación de estado de vuelta al Dominiovirtual del servidor principal. La Pasarela de sucesos de copia de seguridad también envía el sucesode comprobación de estado al Dominio virtual en el servidor de copia de seguridad.

Para un suceso de resolución de comprobación de estado, el Dominio virtual comprueba la indicaciónde fecha y hora en el suceso para asegurar que el suceso no sea más antiguo de 5 minutos y queactualice su tabla state.domains para que muestre que el servidor principal está en buen estado. (LaPasarela de sucesos también escucha sucesos de comprobación de estado desde el servidor de copiade seguridad. La tabla state.domains registra el estado actual tanto de los servidores principal comode copia de seguridad).

Para un suceso de problema de comprobación de estado, el Dominio virtual actualiza su tablastate.domains para mostrar que el servidor principal está en mal estado. El Dominio virtual conmutaráel servidor de copia de seguridad a la modalidad activa, y el servidor principal se volverá a estado enespera.

6 Fallo de comprobación de estado generado en nombre del dominio principalSi el servidor de copia de seguridad no recibe un suceso de resolución de comprobación de estadodesde el servidor principal dentro del intervalo configurado de 5 minutos, indicará que el servidorprincipal no está funcionando adecuadamente o no está comunicándose adecuadamente con elObjectServer. El Dominio virtual de copia de seguridad envía un suceso de problema de comprobaciónde estado a la Sonda para Tivoli Netcool/OMNIbus en nombre del servidor principal. El Dominio virtualactualizará su tabla state.domains para mostrar que el servidor principal está en mal estado.

7 , 8 , y 9 Migración tras error desencadenadaLa sonda envía el suceso de problema de comprobación de estado a ObjectServer, que reenviará elsuceso de problema de comprobación de estado a la Pasarela de sucesos tanto en los servidoresprincipales como de copia de seguridad de Network Manager:

• La Pasarela de sucesos del servidor de copia de seguridad enviará el suceso de problema decomprobación de estado al Dominio virtual, que conmutará el servidor de copia de seguridad a lamodalidad activa.

• Si la Pasarela de sucesos principal está operativa, reenviará el suceso de problema decomprobación de estado al Dominio virtual principal. Si el Dominio virtual está operativo, conmutaráel servidor principal a la modalidad en espera.

Cuando el servidor de copia de seguridad genere un suceso de resolución de comprobación de estado, elflujo de proceso será idéntico al del servidor principal. Los sucesos de resolución de comprobación deestado actualizados con regularidad para los servidores principales y de copia de seguridad se guardan enObjectServer y se pueden visualizar utilizando, por ejemplo, el Visor de sucesos.

Si el suceso de problema de comprobación de estado se genera mediante el servidor de copia deseguridad para indicar que el servidor de copia de seguridad está en mal estado, se aplican los mismosprocesos, a excepción de que el servidor principal no se pone en espera y que el servidor de copia deseguridad no se conmuta a la modalidad activa. El suceso de problema de comprobación de estado parael servidor de copia de seguridad está presente en el ObjectServer y se puede visualizar utilizando, porejemplo, el Visor de sucesos.

Nota: La Sonda para Tivoli Netcool/OMNIbus y la Pasarela de sucesos en ambos dominios se debenconfigurar para acceder al mismo ObjectServer, para que los sucesos de comprobación de estado sedireccionen satisfactoriamente en torno al sistema.


Migración tras error y conmutación por recuperación de Network ManagerLa migración tras error se puede iniciar mediante el dominio principal o de copia de seguridad, y sedesencadena cuando se genera un suceso de problema de comprobación de estado para el dominioprincipal. La conmutación por recuperación se desencadena mediante un suceso de resolución decomprobación de estado para el dominio principal.

Un suceso de ItnmFailover se genera mediante ncp_virtualdomain cuando un dominio de NetworkManager migra tras error o se conmuta por recuperación.

Migrar tras errorCuando se produce la migración tras error, el dominio principal de Network Manager se pasa a lamodalidad en espera (si sigue en ejecución), y el dominio de copia de seguridad se hace activo.

Se producen los cambios siguientes cuando el dominio de copia de seguridad se convierte en activo:

• La Pasarela de sucesos sincroniza los sucesos con el ObjectServer.• El proceso ncp_poller reanuda el sondeo.• La Pasarela de sucesos conmutará del filtro en espera (StandbyEventFilter) al filtro de sucesos

entrantes (EventFilter).• Network Manager continúa supervisando la red y realizando RCA. Sin embargo, no se realizará el

descubrimiento de red, y la topología de red permanecerá estática.

Cuando un servidor principal de Network Manager se convierta a la modalidad en espera, se produciránlos siguientes cambios:

• La Pasarela de sucesos conmutará del filtro de sucesos entrantes (EventFilter) al filtro en espera(StandbyEventFilter).

• El proceso ncp_poller suspende todos los sondeos.

Para obtener más información acerca del filtro en espera y del filtro de sucesos entrantes, consulte lapublicación IBM Tivoli Network Manager IP Edition Administration Guide.

El sistema de cálculo en tiempo real de Apache Storm, que se utiliza para agregar datos de sondeo sinformato a los datos de sondeo históricos, migra tras error de un modo diferente al de los otros procesosprincipales de Network Manager. En una configuración de migración tras error cada Network Managertiene un servidor Apache Storm con todas las funciones que agrega los datos de sondeos, pero solo unode estos servidores Apache Storm está activo al mismo tiempo. Cuando se inicia en primer lugar unservidor Apache Storm, éste comprueba la base de datos para ver si otro servidor Apache Storm ya estáprocesando los datos de sondeo.

• Si es así, el primer servidor Apache Storm pasa a estado de espera.• si no es así, el servidor Storm asume la responsabilidad de procesar los datos de sondeo.

Cuando se produce una migración tras error, el servidor Apache Storm no detiene sus procesos. Lamigración tras error del servidor Apache Storm solo se lleva a cabo si el usuario lo detiene o si no puedeactualizar la base de datos. Para obtener más información acerca de cómo funciona la agregación dedatos de sondeo en una configuración de Network Manager múltiple, consulte la publicación IBM TivoliNetwork Manager IP Edition Administration Guide.

Conmutar por recuperaciónCuando un servidor principal de Network Manager en modalidad en espera reanuda su funcionamientonormal, generará un suceso de resolución de comprobación de estado.

El suceso de resolución de comprobación de estado pasará por el sistema, y el servidor recuperado deNetwork Manager se convertirá en activo de nuevo.

Cuando el proceso del Dominio virtual en el servidor de la copia de seguridad de Network Manager recibael suceso de resolución de comprobación de estado, el Dominio virtual conmutará el servidor de copia deseguridad a la modalidad en espera.


La automatización de GenericClear en ObjectServer se desencadena mediante el suceso de resolución decomprobación de estado, y borra el suceso de problema de comprobación de estado existente.

Conceptos relacionadosSucesos de comprobación de estado y migración tras errorLa migración tras error se rige por las comprobaciones de estado, que se configuran para que se ejecutenperiódicamente a fin de evaluar el estado de los dominios principales y de copia de seguridad de NetworkManager.

Migración tras error en la instalación de copia de seguridadTodos los procesos de la instalación de copia de seguridad apuntan a la base de datos de topología deNCIM en la instalación primaria. La base de datos de topología NCIM en la instalación primaria puede seruna base de datos autónoma o una configurada para la alta disponibilidad.




La cifra siguiente muestra una arquitectura de migración tras error de Network Manager de ejemplo,donde la base de datos de topología NCIM se ha configurado para la alta disponibilidad.


Figura 12. Ejemplo de arquitectura de migración tras error con alta disponibilidad NCIM

La siguiente figura varía de la anterior en que la base de datos de topología NCIM no está configuradapara la alta disponibilidad.


Figura 13. Ejemplo de arquitectura de migración tras error sin alta disponibilidad NCIM

DescubrimientoAunque el Motor de descubrimiento (ncp_disco) y el servidor Ayudante de SNMP(ncp_d_helpserv) se ejecuten, el servidor de Network Manager de copia de seguridad no seutilizará para el descubrimiento de red. Cuando el dominio de copia de seguridad esté activo, latopología no cambiará.

Pasarela de sucesosCuando el dominio de copia de seguridad esté en modalidad en espera, la Pasarela de sucesos norealiza el enriquecimiento de sucesos en el ObjectServer. Cuando el dominio de copia de seguridad sehaga activo, la Pasarela de sucesos conmutará del filtro en espera (StandbyEventFilter) al filtro desucesos entrantes (EventFilter).

NCIMEl proceso de copia de seguridad ncp_model no actualiza la base de datos de topología NCIM. Sinembargo, el proceso de ncp_model continúa facilitando servicios de topología a procesos tales comola Pasarela de sucesos. La base de datos de topología NCIM utilizada por las Vistas de red y la Vista desaltos continúa guardando la versión más actual de la topología de red hasta que se restaure elservidor principal de Network Manager y el sistema se conmute por recuperación.

SondeoCuando el dominio de copia de seguridad esté en modalidad en espera, se ejecutará el Motor desondeo, pero con los sondeos suspendidos. Cuando el dominio de copia de seguridad se active, suproceso ncp_poller comienza el sondeo y utiliza las políticas de sondeo y los detalles de destino deSNMP desde el dominio principal.


El proceso ncp_poller leerá la configuración de SNMP directamente desde su archivo deconfiguración en lugar de basarse en el ayudante de SNMP de descubrimiento para leer este archivo.

Dominio virtualEl componente del Dominio virtual de copia de seguridad abre una conexión de socket en el Dominiovirtual del servidor principal de Network Manager. Los datos de topología y cualquier actualización dela topología posterior se copiará desde el proceso ncp_model servidor primariodel servidor principalal proceso ncp_model del servidor de copia de seguridad.

Conceptos relacionadosArquitectura de migración tras error de Network Manager (procesos principales)La migración tras error de los procesos principales de Network Manager se puede implementarestableciendo las instalaciones principales y de copia de seguridad de Network Manager que se ejecutanen distintos servidores. Ambas instalaciones pueden conectarse a un único ObjectServer de TivoliNetcool/OMNIbus o a un par virtual de ObjectServers.Sobre la alta disponibilidad de base de datos de topología NCIMNetwork Manager permite configurar la base de datos de topología NCIM (Network Connectivity andInventory Model) para una alta disponibilidad, minimizando el impacto de fallos de sistema o de red. Enlas secciones siguientes se proporciona una visión general de la alta disponibilidad de la base de datos detopología NCIM y se explica cómo configurarla.Host de migración tras error de ejemplo con alta disponibilidad de base de datos de topología NCIMEste es un ejemplo de host de migración tras error donde la configuración de migración tras error incluyeuna copia de la base de datos de topología de NCIM en la instalación de copia de seguridad.Referencia relacionadaLimitaciones del proceso de migración tras error de Network ManagerSe aplica un número de limitaciones para el proceso de migración tras error.

Limitaciones del proceso de migración tras error de Network ManagerSe aplica un número de limitaciones para el proceso de migración tras error.

El proceso de descubrimiento (ncp_disco) realiza el descubrimiento de red únicamente en el dominioprimario.

El dominio de copia de seguridad no se utiliza para el descubrimiento de red, por lo que, cuando eldominio de copia de seguridad esté activo, no intente configurar un descubrimiento. Además, cuando eldominio de copia de seguridad esté activo, no edite la topología de red descubierta para añadir o eliminarmanualmente dispositivos y conexiones.

Las WebTools no funcionan cuando el servidor de copia de seguridad está en modalidad primaria.

Las aplicaciones web no se conectan al servidor de copia de seguridad cuando se convierte en el servidorprimario durante la migración tras error. Algunas aplicaciones web como, por ejemplo, el navegador deMIB de SNMP y el gráfico de MIB de SNMP no funcionan cuando el servidor de copia de seguridad está enmodalidad primaria.

Restricción: Network Manager no soporta la característica de equilibrio de carga de DashboardApplication Services Hub que hace GUI web de Tivoli Netcool/OMNIbus .

Si está ejecutando más de un servidor de Dashboard Application Services Hub, cada uno se ejecutaráindependientemente. Si uno de los servidores de Dashboard Application Services Hub falla, cualquierservidor restante continuará ejecutándose como una entidad individual. Para minimizar el efecto de unservidor que falla:

• Una sesión de usuario en un servidor de Dashboard Application Services Hub no se puede transferir ocontinuar en otro. Si el primer servidor de Dashboard Application Services Hub falla, los usuarios debeniniciar la sesión en otro servidor de Dashboard Application Services Hub activo.

• Asegúrese de que cada uno de los servidores esté configurado con el mismo conjunto de usuarios,roles, grupos, perfiles de preferencias y recursos tales como páginas, vistas, widgets e informes.


• Configure los servidores según los requisitos de alta disponibilidad de la base de datos. Por ejemplo,para Db2, deberá configurar los servidores según los requisitos de la característica HADR de Db2. De lamisma forma, si tiene una base de datos Oracle, podría configurar los servidores según los requisitos dela característica Real Application Clusters (RAC).

Nota: Los agentes de supervisión ITM no soportan la migración tras error en la arquitectura de migraciónde error de Network Manager.

Tareas relacionadasConfiguración de la migración tras error de los procesos principales de Network Manager

Configuración de migración tras errorUtilice esta información para configurar la migración tras error en las instalaciones primarias y de copia deseguridad de Network Manager. También se ofrecen unas pautas para configurar opcionalmente lamigración tras error de los productos y componentes de integración. Debe utilizar la documentación paraestos productos y componentes como el primer punto de referencia.

Antes de empezarAntes de empezar a configurar la migración tras error, determine si desea implementar una solución demigración tras error completa para todos los componentes, o la migración tras error para NetworkManager y un subconjunto de componentes. Decida también el número de equipos y las opciones dedespliegue.

Acerca de esta tareaComo requisito previo para la configuración de la migración tras error:

Procedimiento• Debe tener instalado y configurado IBM Tivoli Netcool/OMNIbus. Si intenta ejecutar un ObjectServer

primario y de copia de seguridad en la modalidad de migración tras error.

Consejo: Si está utilizando IBM Tivoli Netcool/OMNIbus V7.3 o posterior, con los archivos deconfiguración de migración tras error que se proporcionan, asegúrese de seguir las convenciones denomenclatura para las pasarelas ObjectServers y ObjectServer.

• Debe tener instalada una base de datos de topología. Para la alta disponibilidad de base de datos detopología NCIM, necesitará dos bases de datos de topología.


– Si tiene una base de datos Db2, puede utilizar la característica HADR (recuperación tras desastre dealta disponibilidad) para configurar la migración tras error para NCIM.

– Si tiene una base de datos de Oracle, puede utilizar la característica Real Application Clusters (RAC)para configurar la migración tras error para NCIM.

• Debe tener instalada y configurada la GUI web y las aplicaciones web de Network Manager dentro dela infraestructura del servidor de Dashboard Application Services Hub.

• Debe tener instalados los procesos principales de Network Manager en los servidores primarios y decopia de seguridad designados, bajo dos dominios separados.

Conceptos relacionadosAcerca de los archivos de configuración de migración tras error de Tivoli Netcool/OMNIbusTivoli Netcool/OMNIbus V7.3 o posterior, proporciona un conjunto de archivos de configuración quepuede aplicar a ObjectServers y Pasarelas de ObjectServer para implementar la arquitectura de variosniveles.


Configuración de la migración tras error de ObjectServerLa manera en la que configure la migración tras error de ObjectServer depende de la versión de TivoliNetcool/OMNIbus.

Antes de empezarEn una instalación de Tivoli Netcool/OMNIbus, cada equipo en el que los componentes de Tivoli Netcool/OMNIbus se ejecutan debe ser configurado con información de comunicación de servidor que habilite loscomponentes en la arquitectura para que se ejecuten y se comuniquen entre ellos. Configure los archivosde datos de conexiones con todos los detalles de componente, de la siguiente manera:

• Actualice la información de comunicación para todos los componentes de servidor de TivoliNetcool/OMNIbus en el despliegue editando de forma manual el archivo de datos de conexiones$NCHOME/etc/omni.dat, que se utiliza para crear el archivo de interfaces.

Una práctica recomendada es agregar todos los componentes en todo el despliegue a un único archivoomni.dat, que puede ser distribuido en el directorio $NCHOME/etc en todos los equipos deldespliegue. Puede generar el archivo de interfaces desde cada equipo ejecutando el mandato$NCHOME/bin/nco_igen. (Los archivos de interfaces se denominan $NCHOME/etc/interfaces.arch, en donde arch es el nombre del sistema operativo).

Configuración de ejemplo para la arquitectura de migración tras error básica (solo capa deagregación)

La siguiente configuración de ejemplo muestra los detalles de comunicación del servidor para laarquitectura de migración tras error en el archivo $NCHOME/etc/omni.dat, donde:

• AGG_P es el nombre del ObjectServer primario.• AGG_B es el nombre del ObjectServer de copia de seguridad.• AGG_V es el nombre del par de ObjectServer virtual.• AGG_GATE es el nombre de la pasarela de ObjectServer bidireccional.• NCO_PA representa el nombre predeterminado para el agente del proceso. (Si ha configurado los

agentes de proceso para gestionar los procesos de Tivoli Netcool/OMNIbus y ejecutar procedimientosexternos, se debe agregar cada agente de proceso con nombre exclusivo con el nombre de host y elnúmero de puerto adecuados).

• NCO_PROXY representa el nombre predeterminado para el servidor proxy. (Si ha configurado uno o másservidores proxy para reducir el número de conexiones de sonda directas a ObjectServers, se debeagregar cada servidor proxy con nombre exclusivo con el nombre de host y el número de puertoadecuados).

[AGG_P]{ Primary: primary_host.ibm.com 4100}

[AGG_B]{ Primary: backup_host.ibm.com 4150}

[AGG_V]{ Primary: primary_host.ibm.com 4100 Backup: backup_host.ibm.com 4150}

[AGG_GATE]{ Primary: backup_host.ibm.com 4105}

[NCO_PA]{


Primary: primary_host.ibm.com 4200}

[NCO_PROXY]{ Primary: primary_host.ibm.com 4400}

Para obtener más detalles sobre la configuración de la información de comunicación del servidor, agentesde proceso y servidores proxy, consulte la documentación de Tivoli Netcool/OMNIbus en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

Conceptos relacionadosArquitectura de migración tras error de ObjectServerPuede desplegar Tivoli Netcool/OMNIbus mediante el uso de una arquitectura de varios niveles escalable,para que el sistema pueda continuar funcionando en su capacidad completa (y con mínima pérdida desucesos) en el caso de un fallo de ObjectServer, Pasarela de ObjectServer o servidor de proxy.

Configuración de ObjectServers y pasarelas para la migración tras errorLos siguientes procedimientos proporcionan orientación para configurar la migración tras error deObjectServer en Tivoli Netcool/OMNIbus.

Acerca de esta tarea“Tivoli Netcool/OMNIbus V7.3 o posterior” en la página 184: Configuración de migración tras error“Tivoli Netcool/OMNIbus V7.2.1 o anterior” en la página 185: Configuración de migración tras error

Para obtener la información más reciente y completa sobre la migración tras error de ObjectServer,consulte la documentación de Tivoli Netcool/OMNIbus en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html. La documentación de Tivoli Netcool/OMNIbus debe ser siempre el primer punto de referencia y tiene prioridad sobre la información queaparece en la documentación de Network Manager.

Tivoli Netcool/OMNIbus V7.3 o posterior

Acerca de esta tareaPara configurar la migración tras error:

Procedimiento1. Si todavía no lo ha hecho, cree el ObjectServer de agregación primario AGG_P en el equipo designado

y aplique la personalización de SQL ejecutando el mandato nco_dbinit con el archivo de importaciónaggregation.sql proporcionado:

$NCHOME/omnibus/bin/nco_dbinit -server AGG_P -customconfigfile $NCHOME/omnibus/extensions/multitier/objectserver/aggregation.sql

Si el ObjectServer ya está instalado y se está ejecutando, aplique el archivo de importaciónaggregation.sql en el ObjectServer, de la siguiente manera:

$NCHOME/omnibus/bin/nco_sql -server AGG_P -user user_name –passwordpassword < $NCHOME/omnibus/extensions/multitier/objectserver/aggregation.sql

2. Inicie el ObjectServer primario (si es necesario):

$NCHOME/omnibus/bin/nco_objserv -name AGG_P &

Si ha instalado Tivoli Netcool/OMNIbus utilizando el instalador de Network Manager, puede, comoalternativa, ejecutar el mandato itnm_start en el directorio $NCHOME/precision/bin:

itnm_start nco3. Cree (o actualice) el ObjectServer de agregación de copia de seguridad AGG_B en otro equipo y

aplique la personalización SQL, como se describe en el paso “1” en la página 184.






Cuando aplique la personalización de SQL, la propiedad BackupObjectServer se define de formaautomática como TRUE y se habilitan las automatizaciones que solicita el ObjectServer de copia deseguridad.

4. Inicie el ObjectServer de copia de seguridad (si es necesario), como se describe en el paso “2” en lapágina 184.

5. En el equipo en el que está instalado el ObjectServer de copia de seguridad, configure la pasarela delObjectServer de agregación bidireccional AGG_GATE:a) Copie los archivos de propiedades de varios niveles para la pasarela desde la ubicación de$NCHOME/omnibus/extensions/multitier/gateway, a la ubicación predeterminada($NCHOME/omnibus/etc) en la que se mantienen los archivos de configuración y propiedades:

• AGG_GATE.map• AGG_GATE.props• AGG_GATE.tblrep.def

b) Inicie la pasarela AGG_GATE:

$NCHOME/omnibus/bin/nco_g_objserv_bi -propsfile $NCHOME/omnibus/etc/AGG_GATE.props &

Tivoli Netcool/OMNIbus V7.2.1 o anterior

Acerca de esta tareaPara configurar la migración tras error:

Procedimiento1. Si todavía no lo ha hecho, cree el ObjectServer primario en el equipo designado ejecutando el mandatonco_dbinit:

$NCHOME/omnibus/bin/nco_dbinit -server nombre_servidor

Donde nombre_servidor es el nombre designado; por ejemplo, NETCOOLPRI.2. Inicie el ObjectServer primario (si es necesario):

$NCHOME/omnibus/bin/nco_objserv -name server_name &3. Si todavía no lo ha hecho, cree el ObjectServer de copia de seguridad en otro equipo, como se describe

en el paso “1” en la página 185.4. Configure ObjectServer de copia de seguridad editando su archivo de propiedades ($NCHOME/omnibus/etc/nombre_servidor.props), y defina la propiedad de BackupObjectServer comoTrue.

5. Inicie el ObjectServer de copia de seguridad, como se describe en el paso “2” en la página 185.6. En el equipo en el que está instalado el ObjectServer de copia de seguridad, configure la pasarela de

ObjectServer bidireccional para intercambiar datos de alerta entre los ObjectServers primario y decopia de seguridad:a) Cree el directorio $NCHOME/omnibus/gates/nombre_pasarela, para los archivos de

configuración de la pasarela.b) Copie todos los archivos en $NCHOME/omnibus/gates/objserv_bi en el directorio de$NCHOME/omnibus/gates/nombre_pasarela.

c) Cambie el nombre del archivo $NCHOME/omnibus/gates/nombre_pasarela/objserv_bi.map a nombre_pasarela.map.

d) Cambie el nombre del archivo $NCHOME/omnibus/gates/nombre_pasarela/objserv_bi.props a nombre_pasarela.props.

e) Edite las siguientes entradas en el archivo nombre_pasarela.props:

# Common Netcool/OMNIbus Properties.MessageLog : '$OMNIHOME/log/gateway_name.log'


# Common Gateway Properties.Gate.MapFile : '$OMNIHOME/gates/gateway_name/gateway_name.map'Gate.StartupCmdFile : '$OMNIHOME/gates/gateway_name/objserv_bi.startup.cmd'

# Bidirectional ObjectServer Gateway Properties.Gate.ObjectServerA.Server : 'primary_ObjectServer'Gate.ObjectServerA.Username : 'user_name'Gate.ObjectServerA.Password : 'password'Gate.ObjectServerA.TblReplicateDefFile: '$OMNIHOME/gates/gateway_name/objserv_bi.objectservera.tblrep.def'

Gate.ObjectServerB.Server : 'backup_ObjectServer'Gate.ObjectServerB.Username : 'user_name'Gate.ObjectServerB.Password : 'password'Gate.ObjectServerB.TblReplicateDefFile: '$OMNIHOME/gates/gateway_name/objserv_bi.objectserverb.tblrep.def'

Sustituya nombre_pasarela por el nombre asignado a la pasarela, ObjectServer_primario yObjectServer_copiaseguridad por los nombres de los ObjectServer y especifique el nombre deusuario y la contraseña para la conexión con los ObjectServers.

f) Copie el archivo $NCHOME/omnibus/gates/nombre_pasarela/nombre_pasarela.props en$NCHOME/omnibus/etc/nombre_pasarela.props.

g) Inicie la pasarela:

$NCHOME/omnibus/bin/nco_g_objserv_bi &

Conexión a un par de migración tras error de ObjectServerCada instalación de Network Manager que se conecta a un ObjectServer necesita una copia del archivo deinterfaces de Tivoli Netcool/OMNIbus .

Acerca de esta tareaSuponiendo que la información de comunicación de servidor se haya configurado en las instalaciones deTivoli Netcool/OMNIbus, el archivo $NCHOME/etc/interfaces.arch (donde arch representa elnombre del sistema operativo) deben estar disponibles en la ubicación de la instalación de NCHOME.

Procedimiento• Cuando se instale Tivoli Netcool/OMNIbus en el mismo servidor que Network Manager, ambos deben

instalarse en la misma ubicación de NCHOME. En tales casos, no es necesario realizar ninguna acciónadicional para garantizar que los procesos de Network Manager puedan conectarse con un par demigración tras error de ObjectServer.

• Si Network Manager y Tivoli Netcool/OMNIbus se instalan en servidores distintos, realice los pasossiguientes en los servidores de Network Manager primario y de copia de seguridad:

Copie el archivo $NCHOME/etc/interfaces.arch desde la ubicación de Tivoli Netcool/OMNIbusNCHOME a la ubicación de la instalación de NCHOME del servidor donde está instalado NetworkManager.

Para obtener más información sobre la configuración de la información de comunicación del servidor ysobre cómo generar el archivo de Tivoli Netcool/OMNIbus interfaces.arch file, consulte ladocumentación relativa a Tivoli Netcool/OMNIbus en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

Nota: El nombre del par ObjectServer virtual debe especificarse en el archivoConfigItnm.DOMAIN.cfg.

Tareas relacionadasConfiguración de la migración tras error de ObjectServerLa manera en la que configure la migración tras error de ObjectServer depende de la versión de TivoliNetcool/OMNIbus.Configuración de la migración tras error utilizando el archivo ConfigItnm.cfg




Cuando utiliza el archivo $NCHOME/etc/precision/ConfigItnm.DOMAIN.cfg para configurar lamigración tras error, los procesos de Network Manager leerán el archivo en el inicio para identificar si seestán ejecutando en el dominio primario o de copia de seguridad.

Configuración de la migración tras error de origen de datos para la GUI webde Tivoli Netcool/OMNIbusSi tiene un par de migración tras error de ObjectServers a los que se debe conectar la GUI web, puedeconfigurar la migración tras error de origen de datos utilizando el archivo de configuración de origen dedatos ncwDataSourceDefinitions.xml en su instalación de la GUI web.

Acerca de esta tareaEste archivo está ubicado en webgui_home_dir/etc/datasources, donde webgui_home_dir es eldirectorio de instalación para la GUI web, por ejemplo, $NCHOME/omnibus_webgui.

Para configurar la migración tras error de origen de datos:

Procedimiento1. En el servidor de Dashboard Application Services Hub en el que está instalada la GUI web, edite el

archivo de configuración de origen de datos de la siguiente manera:a) Utilice el atributo de name del elemento <ncwDataSourceEntry> para especificar una etiqueta para

el par de migración tras error de ObjectServers; por ejemplo, VirtualObjectServerPair.b) Defina los detalles de conexión para los ObjectServers primarios y de copia de seguridad mediante

el elemento <ncwDataSourceDefinition> y sus elementos hijo.

Nota: Los valores del atributo name de los elementos <ncwDataSourceEntry> y<ncwDataSourceDefinition> deben ser idénticos. También debe definir las conexiones deObjectServer utilizando los nombres de host y los números de puerto, en vez de los nombres deObjectServer que están configurados en el archivo omni.dat o en el sql.ini.

Para obtener un ejemplo de la configuración necesaria, consulte el código de ejemplo en“Configuración de ncwDataSourceDefinitions.xml de ejemplo para la migración tras error de origende datos” en la página 188.

c) Reinicie el servidor de Dashboard Application Services Hub para que los cambios surtan efecto.Utilice el siguiente mandato:

• startServer.sh server1

Para obtener la información más reciente y completa sobre la configuración de la migración traserror de origen de datos en la GUI web, consulte la documentación de GUI web en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

La documentación de GUI web debe ser siempre el primer punto de referencia y tiene prioridadsobre la información que aparece en la documentación de Network Manager.

2. Debe definir también el valor WebTopDataSource en el archivo ModelNcimDb.domain_name.cfgcon el mismo valor con el que <ncwDataSourceEntry> está definido en el archivoncwDataSourceDefinitions.xml. Al utilizar los valores de “Configuración dencwDataSourceDefinitions.xml de ejemplo para la migración tras error de origen de datos” en lapágina 188, el siguiente ejemplo muestra qué cambios necesita realizar:a) Vaya al archivo NCHOME/etc/precision/ModelNcimDb.nombre_dominio.cfg y ábralo para

que pueda editarlo.b) Busque la inserción que define la propiedad WebTopDataSource:

insert into dbModel.access(EnumGroupFilter,TransactionLength,ValidateCacheFile,




WebTopDataSource)values("enumGroup in ('ifAdminStatus', 'ifOperStatus', 'sysServices', 'ifType','cefcFRUPowerAdminStatus', 'cefcFRUPowerOperStatus', 'TruthValue','entSensorType', 'entSensorScale', 'entSensorStatus','cefcModuleAdminStatus', 'cefcModuleOperStatus', 'ipForwarding','cefcPowerRedundancyMode', 'EntityType', 'ospfIfState', 'ospfIfType','dot3StatsDuplexStatus', 'accessProtocol')",500,0,"OS");

c) Cambie el valor de WebTopDataSource en la siguiente consulta de inserción para ajustar losorígenes de datos configurados en el elemento <ncwDataSourceEntry> (en este caso, cambie elvalor OS a VirtualObjectServerPair):

insert into dbModel.access(EnumGroupFilter,TransactionLength,ValidateCacheFile,WebTopDataSource)values("enumGroup in ('ifAdminStatus', 'ifOperStatus', 'sysServices', 'ifType','cefcFRUPowerAdminStatus', 'cefcFRUPowerOperStatus', 'TruthValue','entSensorType', 'entSensorScale', 'entSensorStatus','cefcModuleAdminStatus', 'cefcModuleOperStatus', 'ipForwarding','cefcPowerRedundancyMode', 'EntityType', 'ospfIfState', 'ospfIfType','dot3StatsDuplexStatus', 'accessProtocol')",500,0,"VirtualObjectServerPair");

Nota: El nombre de origen de datos de la GUI web es el nombre para la conexión y debe ser lamisma que la que está definida en la GUI web. El nombre puede que no sea siempre el mismo queel nombre del ObjectServer.

d) Realice este cambio en los servidores primario y de copia de seguridad de Network Manager.e) Restart ncp_ctrl.

Configuración de ncwDataSourceDefinitions.xml de ejemplo para la migración tras error de origen dedatos

En el siguiente código de ejemplo, el texto en negrita identifica los valores que son aplicables a lamigración tras error del origen de datos.

<ncwDefaultDataSourceList> <ncwDataSourceEntry name="VirtualObjectServerPair"/></ncwDefaultDataSourceList>

...

<ncwDataSourceDefinition type="singleServerOSDataSource" name="VirtualObjectServerPair" enabled="true"> <ncwFailOverPairDefinition>  <ncwPrimaryServer> <ncwOSConnection host="AGG_P_hostname" port="AGG_P_port" ssl="false" minPoolSize="5" maxPoolSize="10"/> </ncwPrimaryServer>  <ncwBackUpServer> <ncwOSConnection host="AGG_B_hostname" port="AGG_B_port" ssl="false" minPoolSize="5" maxPoolSize="10"/>

</ncwBackUpServer></ncwFailOverPairDefinition>

</ncwDataSourceDefinition>

Configuración de la autenticación de ObjectServerSi está utilizando un ObjectServer como el registro de usuario central para la gestión y autenticación deusuarios y desea que el ObjectServer se encuentre en un repositorio federado, debe utilizar el script quese proporciona con Dashboard Application Services Hub para configurar el adaptador del gestor demiembros virtuales para el ObjectServer. Configure el adaptador para ambos ObjectServers en el par demigración tras error.

Acerca de esta tareaEn cada servidor de Dashboard Application Services Hub en el que las aplicaciones web de NetworkManager y la GUI web están instalados:

Procedimiento1. Vaya al directorio $WAS_HOME/bin.2. Especifique el siguiente mandato en la línea de mandatos:

./confvmm4ncos dir_perfil_jazzsm usuario contraseña dirección puertodirección2 puerto2

Donde:

• dir_perfil_jazzsm es el directorio del perfil de Jazz for Service Management.• usuario es el ID de un usuario con privilegios administrativos para los ObjectServers.• contraseña es la contraseña para el ID de usuario.• dirección es la dirección IP del ObjectServer primario.• puerto es el número de puerto utilizado por el ObjectServer primario.• dirección2 es la dirección IP del ObjectServer de copia de seguridad.• puerto2 es el número de puerto utilizado por el ObjectServer de copia de seguridad.

3. Reinicie el servidor Dashboard Application Services Hub.

Configuración de la migración tras error de los procesos principales deNetwork ManagerPuede configurar la migración tras error de los procesos principales de Network Manager utilizando elarchivo $NCHOME/etc/precision/ConfigItnm.cfg para habilitar la migración tras error.

También debe utilizar el archivo $NCHOME/etc/precision/ServiceData.cfg para configurar unaconexión de socket TCP entre los dominios primario y secundario de Network Manager.


Configuración de la migración tras error utilizando el archivo ConfigItnm.cfgCuando utiliza el archivo $NCHOME/etc/precision/ConfigItnm.DOMAIN.cfg para configurar lamigración tras error, los procesos de Network Manager leerán el archivo en el inicio para identificar si seestán ejecutando en el dominio primario o de copia de seguridad.


Acerca de esta tareaLos contenidos del archivo ConfigItnm.DOMAIN.cfg deben ser idénticos en los servidores de dominioprimario y de copia de seguridad.

Para configurar la migración tras error utilizando el archivo ConfigItnm.DOMAIN.cfg:

Procedimiento1. En el servidor primario de Network Manager, edite el archivo $NCHOME/etc/precision/ConfigItnm.PRIMARY_DOMAIN.cfg de la siguiente manera:a) Habilite la migración tras error y especifique los nombres de dominio primario, de copia de

seguridad y virtual para los procesos de Network Manager. Puede insertar los valores requeridos enla tabla itnmDomain.failover editando la siguiente sección del archivo:

insert into itnmDomain.failover( FailoverEnabled, PrimaryDomainName, BackupDomainName, VirtualDomainName)values ( 0, "NCOMS_P", "NCOMS_B", "NCOMS_V");

Complete la sección de values de la siguiente manera, en el orden listado:

Columna Valor requerido

FailoverEnabled Especifique 1 para habilitar la migración para los dominiosprimarios y de copia de seguridad definidos.

El valor predeterminado 0 significa que la migración tras errorestá inhabilitada.

PrimaryDomainName Sustituya NCOMS_P por el nombre real del dominio primario deNetwork Manager en el par de migración tras error.

Nota: El PrimaryDomainName es el único que se almacena enNCIM y, por tanto, es el único nombre que se muestra en la GUI.El nombre de dominio de copia de seguridad no se utilizan enNCIM y, por tanto, tampoco se muestra en la GUI.

BackupDomainName Sustituya NCOMS_B por el nombre real del dominio de copia deseguridad de Network Manager en el par de migración tras error.

VirtualDomainName Sustituya NCOMS_V por un nombre designado para el dominiovirtual de Network Manager en el par de migración tras error.

b) Especifique el nombre de ObjectServer al que la Sonda para Tivoli Netcool/OMNIbus y la pasarelade sucesos se conectarán. Inserte el valor requerido en la tabla itnmDomain.objectServereditando la siguiente sección del archivo:

insert into itnmDomain.objectServer( ServerName)values (


"NCOMS" );

Complete la sección values de la siguiente manera:

Columna Valor requerido

ServerName Si está utilizando Tivoli Netcool/OMNIbus V7.3 o posterior y haconfigurado la migración tras error de ObjectServer utilizandolos archivos de configuración de varios niveles que seproporcionan y las convenciones de nomenclatura para laconfiguración de varios niveles, especifique AGG_V como elnombre del par de agregación virtual. El valor inicial que aparecees el nombre de ObjectServer que ha instalado el instalador deNetwork Manager o NCOMS si no se ha instalado ningúnObjectServer.

Para versiones anteriores de Tivoli Netcool/OMNIbus,especifique el nombre alternativo definido para el par virtual deObjectServer.

Si no está configurada la migración tras error de ObjectServer,especifique el nombre del único ObjectServer que se estáutilizando.

Nota: No es necesaria ninguna configuración adicional de migración tras error en el archivo depropiedades de la sonda. La configuración predeterminada de las propiedades de la sondaproporciona el soporte adecuado para la migración tras error cuando se está ejecutando la sonda.

2. Guarde el archivo.3. Copie todo el contenido del archivo $NCHOME/etc/precision/ConfigItnm.PRIMARY_DOMAIN.cfg del servidor primario en el archivo $NCHOME/etc/precision/ConfigItnm.BACKUP_DOMAIN.cfg del servidor de copia de seguridad.

Configuración la conexión de socket TCP entre los dominiosEs necesaria un conexión de socket TCP entre los procesos de dominio virtual en los dominios primario yde copia de seguridad para que los datos de topología y las actualizaciones de topología se puedan copiaren el dominio de copia de seguridad.

Acerca de esta tareaPara configurar la conexión TCP:

Procedimiento1. En el servidor de Network Manager primario, inicie de forma manual el proceso ncp_virtualdomain

desde el directorio $NCHOME/precision/bin:

ncp_virtualdomain -domain NOMBRE_SERVIDORPRIMARIO

Cuando el proceso ncp_virtualdomain se inicia por primera vez, escribe una línea en el archivo$NCHOME/etc/precision/ServiceData.cfg, que lista la información de conexión TCP ymultidifusión para los procesos de Network Manager. Esta línea hace referencia ancp_virtualdomain e incluye el puerto en el que el componente de dominio virtual del servidorprimario acepta las conexiones TCP del servidor de copia de seguridad. Por ejemplo:

SERVICE: ncp_virtualdomain DOMAIN: VIRTUAL ADDRESS: 127.123.209.55 PORT: 1234 SERVERNAME: myhostname DYNAMIC: NO

Consejo: El valor DYNAMIC:NO fuerza al proceso de ncp_virtualdomain a utilizar la mismadirección y puerto la próxima vez que se inicie.


2. Guarde el archivo.3. Detenga el proceso ncp_virtualdomain.4. Copie la línea SERVICE: ncp_virtualdomain DOMAIN: VIRTUAL ... desde el archivo en el

servidor principal $NCHOME/etc/precision/ServiceData.cfg al archivo en el servidor de copiade seguridad $NCHOME/etc/precision/ServiceData.cfg. Asegúrese de que solo haya una únicalínea SERVICE: ncp_virtualdomain DOMAIN: VIRTUAL ... en el archivo.

Importante: La línea SERVICE: ncp_virtualdomain DOMAIN: VIRTUAL ... debe ser idénticaen el archivo $NCHOME/etc/precision/ServiceData.cfg en ambos dominios.

Para obtener más información sobre la comunicación entre procesos y sobre el archivoServiceData.cfg, consulte la publicación IBM Tivoli Network Manager IP Edition AdministrationGuide.

Tareas relacionadasDefinición de un puerto fijo para la conexión de socket TCPPara evitar problemas de cortafuegos o conflictos de puerto, puede definir un puerto fijo para la conexiónde socket TCP que permite al proceso de dominio virtual en el servidor de copia de seguridad que seconecte al proceso en el servidor primario.

Definición de un puerto fijo para la conexión de socket TCPPara evitar problemas de cortafuegos o conflictos de puerto, puede definir un puerto fijo para la conexiónde socket TCP que permite al proceso de dominio virtual en el servidor de copia de seguridad que seconecte al proceso en el servidor primario.

Acerca de esta tareaDurante el inicio, el proceso ncp_virtualdomain en el servidor primario agrega una línea al archivoNCHOME/etc/precision/ServiceData.cfg, con información sobre sus detalles de conexión,incluido el número de puerto. Para definir un puerto fijo, debe sustituir el número de puerto inicial por elvalor requerido.

Para configurar un puerto fijo para la migración tras error:

Procedimiento1. Edite el archivo $NCHOME/etc/precision/ServiceData.cfg en el servidor primario de la

siguiente manera:a) Ubique la línea que hace referencia a ncp_virtualdomain.

Por ejemplo:

SERVICE: ncp_virtualdomain DOMAIN: VIRTUAL ADDRESS: 127.123.209.55 PORT: 1234 SERVERNAME: myhostname DYNAMIC: NO

En este ejemplo, el proceso primario ncp_virtualdomain acepta conexiones del servidor decopia de seguridad en el puerto 1234.

b) Cambie el valor PORT al valor requerido.c) Anote el número de puerto y guarde y cierre el archivo ServiceData.cfg.

2. En el servidor de copia de seguridad, edite el archivo $NCHOME/etc/precision/ServiceData.cfgactualizando el número de puerto especificado en la línea que hace referencia ancp_virtualdomain.

Importante: Esta línea debe ser idéntica en el archivo $NCHOME/etc/precision/ServiceData.cfg de ambos dominios.

Para obtener más información sobre el archivo ServiceData.cfg, consulte la publicación IBM TivoliNetwork Manager IP Edition Administration Guide.

Tareas relacionadasConfiguración la conexión de socket TCP entre los dominios


Es necesaria un conexión de socket TCP entre los procesos de dominio virtual en los dominios primario yde copia de seguridad para que los datos de topología y las actualizaciones de topología se puedan copiaren el dominio de copia de seguridad.

Conmutación a la configuración de migración tras error con alta disponibilidad debase de datos de topología NCIMPuede modificar una arquitectura de migración tras error existente para que incluya la alta disponibilidadde base de datos de topología NCIM.

Acerca de esta tareaNota: En los releases anteriores de Network Manager, los usuarios podían incluir una configuración demigración tras error de base de datos de topología NCIM utilizando la réplica de NCIM (tambiéndenominada réplica de base de datos de topología NCIM). La característica de réplica de NCIM se hasustituido por la característica de alta disponibilidad que proporciona la base de datos soportada:



Para configurar la alta disponibilidad de base de datos de topología NCIM:

Procedimiento1. Configure la alta disponibilidad de base de datos de topología NCIM utilizando la característica de alta

disponibilidad que proporciona la base de datos soportada.

Si tiene una base de datos Db2, siga los procedimientos descritos en la documentación deDb2 para establecer una configuración de migración tras error para la base de datos de topologíaNCIM mediante la función HADR. Consulte Información relacionada más adelante para obtenerenlaces al Information Center de Db2.

Si tiene una base de datos Oracle, siga los procedimientos descritos en la documentación deOracle para configurar el entorno de alta disponibilidad de Real Application Clusters (RAC). MedianteRAC de Oracle, puede crear una configuración de alta disponibilidad para su base de datos detopología NCIM. Para obtener información sobre cómo instalar y configurar RAC de Oracle, consulte lainformación relacionada más adelante, para ver un enlace a la documentación de Oracle.

2. Configure Network Manager para que funcione con la base de datos soportada según se describe en“Configuración de Network Manager para que funcione con HADR de Db2, o RAC de Oracle” en lapágina 194.

Conceptos relacionadosSobre la alta disponibilidad de base de datos de topología NCIMNetwork Manager permite configurar la base de datos de topología NCIM (Network Connectivity andInventory Model) para una alta disponibilidad, minimizando el impacto de fallos de sistema o de red. Enlas secciones siguientes se proporciona una visión general de la alta disponibilidad de la base de datos detopología NCIM y se explica cómo configurarla.Tareas relacionadasConfiguración de la migración tras error utilizando el archivo ConfigItnm.cfgCuando utiliza el archivo $NCHOME/etc/precision/ConfigItnm.DOMAIN.cfg para configurar lamigración tras error, los procesos de Network Manager leerán el archivo en el inicio para identificar si seestán ejecutando en el dominio primario o de copia de seguridad.Configuración de Network Manager para que funcione con HADR de Db2, o RAC de Oracle


Configuración de Network Manager para que funcione con HADR de Db2, oRAC de OraclePuede configurar los procesos principales de Network Manager para que utilicen el catálogo de Db2 y laGUI de Network Manager para que funcione en el entorno de recuperación tras desastre de altadisponibilidad (HADR) de Db2. De la misma forma, también puede configurar los procesos centrales y laGUI de Network Manager y la GUI de Network Manager para que funcionen en el entorno Oracle RealApplication Clusters (RAC).

Para ver los métodos recomendados para la implementación de una solución de altadisponibilidad mediante HADR de Db2, consulte Productos de IBM Db2 High Availability for Tivoli Netcool -Prácticas recomendadas en https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Tivoli%20Netcool%20OMNIbus/page/Best%20Practices.


Conceptos relacionadosSobre la alta disponibilidad de base de datos de topología NCIMNetwork Manager permite configurar la base de datos de topología NCIM (Network Connectivity andInventory Model) para una alta disponibilidad, minimizando el impacto de fallos de sistema o de red. Enlas secciones siguientes se proporciona una visión general de la alta disponibilidad de la base de datos detopología NCIM y se explica cómo configurarla.Arquitectura de migración tras error de Network Manager (procesos principales)La migración tras error de los procesos principales de Network Manager se puede implementarestableciendo las instalaciones principales y de copia de seguridad de Network Manager que se ejecutanen distintos servidores. Ambas instalaciones pueden conectarse a un único ObjectServer de TivoliNetcool/OMNIbus o a un par virtual de ObjectServers.

Configuración de Network Manager para utilizar Db2HADR o un servicio RAC de OracleUtilice esta información para forzar a los procesos principales de Network Manager a que utilicen el aliasde Db2 o para que se conecten a un nombre de servicio RAC de Oracle, según su tipo de base de datos.

Antes de empezarPara las bases de datos Db2, los procesos principales de Network Manager deben utilizar el

alias de Db2 para obtener información sobre el servidor de Db2 alternativo. Para forzar a los procesosprincipales de Network Manager a que utilicen el alias Db2, edite dos archivos de configuración(DbLogins.Dominio.cfg y MibDbLogin.cfg) y, a continuación, edite el archivo de controlador:

$NCHOME/precision/platform/linux2x86/db2-version-number/odbc_cli/clidriver/ cfg/db2dsdriver.cfg

Donde version-number es el número de versión de Db2; por ejemplo, 10.5.0.5.

Para bases de datos Oracle, los procesos principales de Network Manager necesitan conectarseal nombre de servicio utilizado por el RAC de Oracle. Para configurar los procesos principales de NetworkManager de modo que utilicen un SID en lugar de un nombre de servicio, edite los archivos deconfiguración DbLogins.Dominio.cfg y MibDbLogin.cfg.


https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Tivoli%20Netcool%20OMNIbus/page/Best%20Practices

https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Tivoli%20Netcool%20OMNIbus/page/Best%20Practices

Acerca de esta tareaLos archivos de configuración DbLogins.Dominio.cfg y MibDbLogin.cfg forman parte de lainstalación principal de Network Manager. Estos archivos se almacenan en el servidor de NetworkManager. Si ha configurado la migración tras error de Network Manager, edite estos archivos deconfiguración en los servidores de Network Manager primarios y de copia de seguridad.

Procedimiento1. En el servidor principal de Network Manager, abra el archivo $NCHOME/etc/precision/DbLogins.Domain.cfg y realice los cambios siguientes, según el tipo de base de datos:Opción Descripción

Para basesde datosDb2

a. Busque el atributo denominado m_PortNum.b. Establezca el valor de todos los atributos m_PortNum en 0 (cero).c. Grabe y abandone el archivo de configuración.

Si fuera necesario, realice los mismos pasos en el servidor de seguridad de NetworkManager.

Para basesde datos deOracle

a. Busque el atributo m_OracleService y añada tras el m_PortNum, si aún noestuviera.

b. No cambie el valor del atributo m_OracleService para "DNCIM",. Establezca elvalor de todos los demás atributos m_OracleService en 1.

c. Asegúrese de que m_DbName está establecido en Oracle SERVICE_NAME, según seespecifica en $ORACLE_HOME/network/admin/tnsnames.ora

d. Asegúrese de que m_Hostname está establecido en el nombre de host de OracleRAC SCAN.

e. De manera opcional, puede definir su propia serie de conexión Oracle RACpersonalizada utilizando el atributo m_ConnectionString, como se describeaquí. Esta serie de conexión se puede utilizar para conectarse a un clúster OracleRAC, o para otros propósitos.

f. Grabe y abandone el archivo de configuración.


2. En el servidor principal de Network Manager, abra el archivo $NCHOME/etc/precision/MibDbLogin.cfg y realice los cambios siguientes, según su tipo de base de datos:Opción Descripción

Para basesde datosDb2

a. Busque el atributo denominado m_PortNum.b. Establezca el valor del atributo m_PortNum en 0 (cero).c. Grabe y abandone el archivo de configuración.


Para basesde datos deOracle

a. Busque el atributo m_OracleService y añada tras el m_PortNum, si aún noestuviera.

b. Establezca el valor del atributo m_OracleService en 1.c. Asegúrese de que m_DbName está establecido en Oracle SERVICE_NAME, según se

especifica en $ORACLE_HOME/network/admin/tnsnames.ora



d. Asegúrese de que m_Hostname está establecido en el nombre de host de OracleRAC SCAN.

e. Opcionalmente, puede definir su propia serie de conexión de Oracle personalizadautilizando el atributo m_ConnectionString, como se describe aquí. Esta serie deconexión se puede utilizar para conectarse a un clúster Oracle RAC, o para otrospropósitos.

f. Grabe y abandone el archivo de configuración.


3.Para bases de datos de Db2, también necesita llevar a cabo el siguiente procedimiento:a) Copie el siguiente archivo de controlador de ejemplo en la misma ubicación con un nuevo nombre

de archivo, como se indica a continuación:

cp $NCHOME/precision/platform/linux2x86/db2-version-number/odbc_cli/clidriver/cfg/db2dsdriver.cfg.sample $NCHOME/precision/platform/linux2x86/db2-version-number/odbc_cli/clidriver/cfg/db2dsdriver.cfg

Donde número-versión es el número de versión de Db2; por ejemplo 10.5.0.5

Nota: Si ya está utilizando este archivo de controlador, haga una copia de seguridad del archivo yedite el archivo de controlador directamente en lugar de copiar el archivo de controlador deejemplo.

b) Busque la sección <configuration> del archivo de controlador.c) Actualice la sección <configuration> de esta manera:

<configuration> <dsncollection> <dsn alias="Database_alias" name="Primary_ database_name" host="Primary_database_host" port="Primary_database_port"/> </dsncollection> <databases> <database name="Primary_database_name" host="Primary_database_host" port="Primary_database_port"/> <wlb> <parameter name="enableWLB" value="true"/> <parameter name="maxTransports" value="50"/> </wlb> <acr> <parameter name="enableAcr" value="true" /> <parameter name="maxAcrRetries" value="10" /> <parameter name="acrRetryInterval" value="5" /> <parameter name="enableAlternateServerListFirstConnect" value="true" /> <alternateserverlist> <server name="server1" hostname="Standby_database_host" port="Standby_database_port" /> </alternateserverlist> </acr> <database name="Standby_database_name" host="Standby_database_host" port="Standby_database_port"/> </databases></configuration>

Donde los elementos siguiente se listan todos en el archivo de configuraciónDbLogins_DOMAIN.cfg:

• Alias_base_datos es el nombre de la base de datos primaria.

Nota: Para su comodidad, el nombre de la base de datos primaria también se utiliza como el aliasde base de datos.


• Nombre_base_datos_primaria es el nombre de la base de datos primaria.• Host_base_datos_primaria es el nombre de host del servidor de bases de datos primario.• Puerto_base_datos_primaria es el puerto de la base de datos primaria.• Nombre_base_datos_en_espera es el nombre de la base de datos en espera• Host_base_datos_en_espera es el nombre de host del servidor de base de datos en espera.• Puerto_base_datos_en_espera es el puerto para la base de datos en espera.

d) Guarde el archivo de controlador db2dsdriver.cfg.

Tareas relacionadasEstablecimiento de un URL de conexión personalizado para identificar los servidores de Db2 o RAC deOracleUtilice esta información para establecer un URL de conexión personalizada para identificar los servidoresprimario y de seguridad de Db2, o para identificar el servicio RAC de Oracle. Esta conexión permitirá a laGUI de Network Manager trabajar en el entorno de Db2 HADR o el entorno RAC de Oracle, según el tipode base de datos.

Serie de conexión ORACLE personalizadaPuede definir una serie de conexión ORACLE personalizada. Esta serie de conexión se puede utilizar paraconectarse a un clúster Oracle RAC, o para otros propósitos.

Para definir una serie de conexión ORACLE personalizada, edite el archivo de configuración$NCHOME/etc/precision/DbLogins.Domain.cfg y configure la inserción dentro del archivo paraincluir un campo m_ConnectionString para que la inserción se parezca a:

insert into config.dbserver( m_DbId, m_Server, m_DbName, m_Schema, m_Hostname, m_Username, m_Password, m_PortNum, m_ConnectionString, m_EncryptedPwd, m_OracleService)values( "NCIM", "oracle", "ORATEST", "ncim", "server1.location1.acme.com", "ncim", "ncim", 1521, "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=server1.location1.acme.com3)(PORT=1521))(CONNECT_DATA=(SID=ORATEST)))", 0, 1);

Utilizando el atributo m_ConnectionString de esta manera, puede sustituir de forma efectiva losvalores de m_DbName, m_Hostname and m_PortNum. Debe proporcionar estos valores, de lo contrario, sesustituirán por el valor especificado en el atributo m_ConnectionString cuando se conecte a la base dedatos.

Establecimiento de un URL de conexión personalizado para identificar los servidoresde Db2 o RAC de OracleUtilice esta información para establecer un URL de conexión personalizada para identificar los servidoresprimario y de seguridad de Db2, o para identificar el servicio RAC de Oracle. Esta conexión permitirá a laGUI de Network Manager trabajar en el entorno de Db2 HADR o el entorno RAC de Oracle, según el tipode base de datos.


Acerca de esta tareaPara establecer una URL de conexión personalizada para identificar los servidores principales y copias deseguridad Db2, o para identificar los servidores Oracle RAC, edite los archivos de propiedades relevantesy especifique la conexión URL a los servidores. Especifique la misma conexión de URL en cada uno de losarchivos de propiedades.

El siguiente archivo de propiedades es aplicable a la GUI de Network Manager:

• $NMGUI_HOMEprofile/etc/tnm/tnm.properties

El archivo de propiedades siguiente es parte de la instalación central de Network Manager: $NCHOME/precision/platform/java/lib/ncp_topoviz/etc/tnm/tnm.properties

Para establecer un URL de conexión personalizado:

Procedimiento1. Abra los archivos $NMGUI_HOMEprofile/etc/tnm/tnm.properties y $NCHOME/precision/platform/java/lib/ncp_topoviz/etc/tnm/tnm.properties para editarlos

2. Realice los cambios siguientes en ambos, dependiendo del tipo de base de datos:Opción Descripción

Parabases dedatosDb2

Especifique la conexión de URL de los servidores primario y de seguridad de Db2,mediante la sintaxis siguiente:

tnm.database.jdbc.url=jdbc:db2://primary_db2_server:primary_db2_port_number/dbname:clientRerouteAlternateServerName=backup_db2_server;clientRerouteAlternatePortNumber=backup_db2_port;

donde:

• servidor_db2_primario: especifica el nombre del servidor primario donde se ejecuta labase de datos Db2.

• número_puerto_db2_primario: especifica el número de puerto del servidor primariodonde se ejecuta la base de datos Db2.

• dbname Especifica el nombre de la base de datos Db2.• servidor_db2_seguridad: especifica el nombre del servidor de seguridad en el que se

ejecuta la base de datos Db2.• puerto_db2_seguridad: especifica el número de puerto del servidor de seguridad en el

que se ejecuta la base de datos Db2.

Parabases dedatos deOracle

Especifique la conexión de URL a los servidores RAC de Oracle utilizando la sintaxissiguiente:

tnm.database.jdbc.url=jdbc:oracle:thin:@Oracle_RAC_SCAN_hostname:Oracle_RAC_port_number/Oracle_RAC_service_name

donde:

• nombreHost_Oracle_RAC_SCAN: especifica la dirección de Single Client Access Name(SCAN) de Oracle en la que se ejecuta la base de datos RAC de Oracle.

• número_puerto_Oracle_RAC: especifica el número de puerto en el que se ejecuta labase de datos RAC de Oracle.



• nombre_servicio_Oracle_RAC: especifica el nombre del servicio en el que se ejecuta labase de datos RAC de Oracle.

3. Guarde y cierre los archivos.

Tareas relacionadasConfiguración de Network Manager para utilizar Db2HADR o un servicio RAC de OracleUtilice esta información para forzar a los procesos principales de Network Manager a que utilicen el aliasde Db2 o para que se conecten a un nombre de servicio RAC de Oracle, según su tipo de base de datos.

Configuración de parámetros para las comprobaciones de estadoSi es necesario, puede configurar las condiciones que prefiera bajo los sucesos de comprobación deestado, especificando inserciones OQL idénticas en el archivo de esquema del proceso de dominio virtual(VirtualDomainSchema.cfg) tanto en el servidor primario como el de copia de seguridad.

Acerca de esta tareaEl componente de dominio virtual utiliza dos bases de datos (configuración y estado) para dar soporte a lamigración tras error de Network Manager. Los filtros y los registros de estado de comprobación de estadoestán almacenados en estas tablas, que se pueden actualizar utilizando el archivoVirtualDomainSchema.cfg. Para obtener más información sobre las tablas de base de datosconfiguración y estado, consulte la publicación Referencia de IBM Tivoli Network Manager.

Para cambiar los valores predeterminados de los parámetros de comprobación de estado:

Procedimiento1. En el servidor de Network Manager primario, edite el archivo $NCHOME/etc/precision/VirtualDomainSchema.cfg especificando las siguientes inserciones OQL:

• Actualice los valores de columna en la tabla config.defaults para especificar diferentes periodos detiempo para las comprobaciones de estado de la migración tras error.

Por ejemplo, pueden utilizar la columna m_HealthCheckPeriod para cambiar el intervalo de tiempoentre cada comprobación de estado. O puede utilizar la columna m_FailoverTime para cambiar elintervalo después del cual el dominio de copia de seguridad desencadena la migración tras error,cuando el dominio primario se considera que está en mal estado. Los valores predeterminados sonlos siguientes:

insert into config.defaults( m_SocketKeepAlivePeriod, m_HealthCheckPeriod, m_FailoverTime, m_DirectoryScanPeriod, m_AutoTopologyDownload)values( 60, 60, 300, 100, 1);

• Si es necesario, actualice la tabla state.filters para definir filtros individuales para cada sondeadorconfigurado en el archivo $NCHOME/etc/precision/CtrlServices.cfg. Por ejemplo, para unsondeador configurado de forma adicional, PingPoller:

insert into state.filters( m_ServiceName,


m_Filter, m_Description)values( "PingPoller", "m_ChangeTime > eval(time,'$TIME - 300') and m_CtrlState <> 7", "The Poller has been running within the last 300 seconds");

2. Guarde y cierre el archivo.3. Realice cambios idénticos en el archivo $NCHOME/etc/precision/VirtualDomainSchema.cfg

del servidor de copia de seguridad.

Conceptos relacionadosSucesos de comprobación de estado y migración tras errorLa migración tras error se rige por las comprobaciones de estado, que se configuran para que se ejecutenperiódicamente a fin de evaluar el estado de los dominios principales y de copia de seguridad de NetworkManager.

Configuración de dependencias de proceso para la migración tras errorAl ejecutar Network Manager en modalidad de migración tras error, debe iniciar los procesos de NetworkManager utilizando el proceso ncp_ctrl. El orden en el que se inician los procesos es importante y estádefinido por las dependencias de proceso que están configuradas en el archivo $NCHOME/etc/precision/CtrlServices.cfg.

Acerca de esta tareaEl componente de dominio virtual (ncp_virtualdomain), que gestiona la migración tras error, dependede todos los procesos que está supervisando porque no puede determinar correctamente su estado hastaque se estén ejecutando los procesos. En el archivo CtrlServices.cfg tanto en el dominio primariocomo en el de copia de seguridad, la entrada para el proceso ncp_virtualdomain tiene la siguienteconfiguración predeterminada:

dependsOn=[ "ncp_poller_default", "ncp_g_event" ];

No es necesaria ninguna configuración adicional para definir las dependencias de proceso para lamigración tras error, siempre que se mantenga este valor predeterminado.

Para obtener información sobre la gestión de dependencias de proceso, consulte la publicación IBM TivoliNetwork Manager IP Edition Administration Guide.

Solución de problemas de la migración tras errorRevise esta información para obtener ayuda sobre la resolución de problemas que puede encontrar con lamigración tras error.

Solución de errores de la base de datos después de la conmutación por errorEn el caso de que, después de la conmutación por error, vea errores en los registros de la GUIrelacionados con la tabla NETWORKVIEWSUMR o networkViewSumr, debe eliminar y volver a crear estatabla.

Acerca de esta tareaEl procedimiento para eliminar y volver a crear la tabla difiere en DB2 y Oracle.

Procedimiento1. Para DB2, complete los siguientes pasos:

a) Ingrese los siguientes comandos en la línea de comandos de DB2.


SET SCHEMA ncpgui;DROP TABLE networkViewSumr;

b) Busque la sección de $PRECISION_HOME/scripts/sql/db2/createPrecisionGUIDb.sqlque crea networkViewSumr y cópiela en la línea de comandos de DB2.

c) Ingrese el siguiente comando en la línea de comandos de DB2:

COMMIT;

d) Salga de la línea de comandos de DB2.2. Para Oracle, complete los siguientes pasos:

a) Ingrese los siguientes comandos en la línea de comandos de Oracle.

ALTER SESSION SET CURRENT_SCHEMA = ncpgui;DROP TABLE networkViewSumr;

b) Busque la sección de $PRECISION_HOME/scripts/sql/oracle/createPrecisionGUIDb.sql que crea networkViewSumr y cópiela en la línea de comandos deOracle.

c) Salga de la línea de comandos de Oracle.

Verificación de la configuración de migración tras error de los ObjectServersde Tivoli Netcool/OMNIbusSi está configurada la migración tras error de ObjectServer, puede que encuentre útil verificar laconfiguración de migración tras error de los ObjectServers.

1. Una vez iniciados ambos ObjectServers, compruebe que los sucesos reenviados al ObjectServerprincipal se muestran en el Visor de sucesos.

2. Detenga el ObjectServer principal y compruebe el archivo de registro de ObjectServer ($NCHOME/omnibus/log/NOMBRE_PRINCIPAL.log) en busca de mensajes de migración tras error.

3. Compruebe el Visor de sucesos para confirmar que se muestran los sucesos reenviados alObjectServer de copia de seguridad.

4. Restaure el ObjectServer principal a un estado en ejecución y verifique que la conmutación porrecuperación se ha producido comprobando su registro de registro.

Para obtener más información acerca del uso de los mandatos de Tivoli Netcool/OMNIbus para iniciar ydetener el ObjectServer, consulte la documentación de Tivoli Netcool/OMNIbus en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

Para obtener más información acerca de cómo iniciar y detener el ObjectServer utilizando los mandatosde Network Manager, consulte la publicación IBM Tivoli Network Manager IP Edition Administration Guide.

Rastreo de la migración tras error de los procesos principales de NetworkManagerPuede realizar un número de acciones y comprobaciones para verificar si la migración tras error de losprocesos principales de Network Manager están funcionando como se esperaba.

Rastreo de la migración tras error al inicioPara asegurarse de que el dominio principal se inicia ejecutándose como el dominio activo, inicie eldominio principal y su proceso de Dominio virtual antes de iniciar el dominio de copia de seguridad. Si eldominio de copia de seguridad se ha iniciado antes de que el proceso de Dominio virtual principal se hayainiciado, el dominio de copia de seguridad se puede volver activo, iniciar el sondeo de la red, y generarsucesos de problemas de comprobación de estado acerca del dominio principal. Este problema, sinembargo, se resuelve por sí mismo una vez que se inicie el Dominio virtual principal y los sucesos decomprobación de estado se transmitan entre los dominios.




En el inicio, la topología y las políticas se copian desde el dominio principal al dominio de copia deseguridad. El dominio de copia de seguridad, sin embargo, no puede convertirse en activo (en la migracióntras error) hasta que se haya inicializado su topología. Para verificar que la topología se ha inicializado:

• Busque un archivo de memoria caché de topología de tamaño distinto de cero(Store.Cache.ncimCache.entityData.domain) en el directorio $NCHOME/var/precision deldominio de copia de seguridad, donde domain es el nombre del dominio actual.

Event generation for startup: Supervise en el Visor de sucesos los sucesos ItnmServiceState eItnmFailoverConnection de Network Manager, para verificar que se están ejecutando los procesos deldominio virtual y que la conexión del socket TCP se ha establecido:

• Una vez que se inicie cada proceso local ncp_virtualdomain, el proceso ncp_ctrl generará unsuceso de resolución ItnmServiceState.

• Cuando se establezca una conexión TCP entre los procesos del Dominio virtual, se generará un sucesode resolución ItnmFailoverConnection.

Rastreo de la migración tras error cuando el sistema está en un estado estableEl comportamiento de migración tras error normal, de estado estable se puede lograr únicamente una vezque los procesos del Dominio virtual de los dominios principales y de copia de seguridad se hayaniniciado y conectado. El comportamiento de estado estable se puede definir como sigue:

• El dominio principal está activo, y funcionando como si fuera el único dominio. El proceso dedescubrimiento descubre la red, que se supervisa mediante el sondeador, y los sucesos estánenriquecidos mediante la Pasarela de sucesos.

• El dominio de copia de seguridad está en modalidad en espera. El descubrimiento no se inicia, y elsondeador realiza el seguimiento de las políticas configuradas en el dominio principal, pero no sondeaningún dispositivo. La Pasarela de sucesos tampoco actualiza sucesos en el ObjectServer.

Puede ejecutar consultas de OQL en cada dominio para comprobar en el estado de los procesos:

• Puede comprobar el estado de procesos individual de Network Manager consultando la base de datosdel proceso ncp_ctrl. Todos los procesos que se ejecutan son ningún problema deberían tener elvalor serviceState = 4 en la tabla de base de datos services.inTray, para indicar que el servicio está"conectado y en ejecución".

• Los procesos ncp_poller y ncp_g_event tiene cada uno una tabla de base de datos asociadaconfig.failover, que identifica su estado de migración tras error actual. Al ejecutarse satisfactoriamenteen un estado estable, estos procesos tienen el valor FailedOver = 0 en la tabla de OQLconfig.failover en ambos dominios. (El proceso del Dominio virtual actualiza periódicamente el campoFailedOver).

Para obtener más información acerca de la ejecución de consultas de OQL, consulte la publicaciónReferencia de IBM Tivoli Network Manager. Para obtener más información acerca de cómo identificarqué procesos están en ejecución, consulte la publicación IBM Tivoli Network Manager IP EditionAdministration Guide.

Event generation while in a steady state: Cada dominio genera sucesos acerca de su estado, según losfiltros del archivo $NCHOME/etc/precision/VirtualDomainSchema.cfg. Estos sucesos se generanen un intervalo configurado en el campo m_HealthCheckInterval. Supervise el Visor de sucesos para lossucesos ItnmHealthChk e ItnmDatabaseConnection de Network Manager para comprobar si los dominiosprincipales y de copia de seguridad están en buen estado:

• Cada dominio genera sucesos de resolución ItnmHealthChk mientras esté sano.• El dominio principal generará un suceso de problema ItnmDatabaseConnection si la conexión a la base

de datos principal de NCIM se ha perdido. Si la conexión no se restablece dentro del intervalo de tiempodefinido para la entrada state.filters de NCIM del archivo VirtualDomainSchema.cfg, el dominioprincipal generará un suceso de problema ItnmHealthChk, acerca del dominio principal.


• Si el dominio de copia de seguridad no recibe un suceso de resolución ItnmHealthChk desde el dominioprincipal dentro del intervalo m_FailoverTime configurado, el dominio de copia de seguridad generaráun suceso de problema ItnmHealthChk sintético en nombre del dominio principal.

Si el dominio principal o el de copia de seguridad genera un suceso de problema ItnmHealthChk para eldominio principal, se desencadena la migración tras error, y el dominio de copia de seguridad se vuelveactivo. Si el dominio principal sigue en ejecución, se pasará a la modalidad en espera.

Consejo: Para sucesos de comprobación de estado, el campo de Nodo identifica el dominio para el quese genera el suceso de comprobación de estado. El campo Resumen identifica el dominio que genera elsuceso y el dominio al que se refiere el suceso.

Rastreo de migración tras error y de conmutación por recuperaciónCuando se produzca la migración tras error, el dominio de copia de seguridad se volverá activo, elsondeador de copia de seguridad supervisará la red, y la Pasarela de sucesos actualizará los sucesos deObjectServer. Puede ejecutar consultas de OQL para consultar el estado de los procesos ncp_poller yncp_g_event. Estos procesos tienen una tabla de base de datos config.failover asociada, que identificasu estado de migración tras error actual. Cuando el dominio de copia de seguridad esté activo, estosprocesos tendrán el valor FailedOver = 1 en la tabla config.failover, para indicar que están en unestado de migración tras error. (Si el dominio principal sigue en ejecución, los procesos asociados tendrántambién asignados el valor de FailedOver = 1).

Cuando se produzca la conmutación por recuperación, el dominio de copia de seguridad se pondrá enespera, y el dominio principal se volverá activo de nuevo. Esto es análogo al inicio.

Event generation on failover and failback: Supervise en el Visor de sucesos los sucesos ItnmHealthChke ItnmFailover de Network Manager, para confirmar el comportamiento de migración tras error yrestablecimiento:

• Un suceso de problema ItnmHealthChk acerca del dominio principal indica que se ha desencadenado lamigración tras error. Un suceso de resolución ItnmHealthChk posterior acerca del dominio principalindica que se ha desencadenado la conmutación por recuperación.

• Los sucesos ItnmFailover se generan para indicar cuándo migra tras error o conmuta por recuperaciónun dominio de Network Manager. La descripción de sucesos indica si el dominio es el principal o el decopia de seguridad, y si se ha vuelto activo o se ha puesto en modalidad en espera.

Investigación de la causa de la migración tras errorDado que la migración tras error se puede iniciar mediante el dominio principal o el de copia deseguridad, es importante identificar qué dominio inició la migración tras error.

Realice cualquiera de las siguientes acciones:

• Revise el archivo de registro de Dominio virtual ($NCHOME/log/precision/ncp_virtualdomain.DOMAIN.log) y el archivo de registro de Pasarela de sucesos ($NCHOME/log/precision/ncp_g_event.DOMAIN.log).

• Revise los sucesos ItnmHealthChk e ItnmFailover en la Lista de sucesos activos. (Este es el enfoquemás simple).

Si el dominio principal inició la migración tras error, esto indica un fallo de uno de los procesos de dominioprincipal. Puede comprobar el estado de los procesos consultando la base de datos del procesoncp_ctrl. El campo serviceState de la tabla de base de datos services.inTray muestra el estadooperativo actual para cada uno de los procesos. Para obtener más información acerca de cómo identificarqué procesos están en ejecución, consulte la publicación IBM Tivoli Network Manager IP EditionAdministration Guide.

Si el dominio de copia de seguridad inició la migración tras error, esto indicará un fallo para direccionar lossucesos de comprobación de estado por todo el sistema debido a uno de los siguientes motivos:

• El dominio principal no generó un suceso de comprobación de estado (por ejemplo, debido a que elservidor principal estaba inactivo).


• La Sonda para Tivoli Netcool/OMNIbus o los procesos de la Pasarela de sucesos en ambos dominios noestán configurados para acceder al mismo ObjectServer.

• El conector de Migración tras error de la pasarela de sucesos no está habilitado.• El archivo de reglas de la Sonda para Tivoli Netcool/OMNIbus se ha modificado de tal forma que el

suceso de comprobación de estado no contiene la información requerida.• La Pasarela de sucesos de copia de seguridad no está permitiendo que pasen los sucesos de

comprobación de estado por el filtro nco2ncp.

Para obtener más información acerca de la habilitación del conector de migración tras error y acerca delos filtros de sucesos, consulte la publicación IBM Tivoli Network Manager IP Edition AdministrationGuide.

Igualmente, asegúrese de que esté configurado el Dominio virtual (en el archivo $NCHOME/etc/precision/CtrlServices.cfg) para tener una dependencia en todos los procesos listados en elarchivo $NCHOME/etc/precision/VirtualDomainSchema.cfg.

Tareas relacionadasConfiguración de la migración tras error utilizando el archivo ConfigItnm.cfgCuando utiliza el archivo $NCHOME/etc/precision/ConfigItnm.DOMAIN.cfg para configurar lamigración tras error, los procesos de Network Manager leerán el archivo en el inicio para identificar si seestán ejecutando en el dominio primario o de copia de seguridad.

Investigación de problemas de conexión de TCPSe requiere una conexión de socket TCP entre los procesos de Dominio virtual en los dominios principalesy de copia de seguridad para que los datos de topología y las actualizaciones de topología se puedancopiar desde el dominio principal al dominio de copia de seguridad.

Si se pierde la conexión de TCP:

• Compruebe que está configurado el Dominio virtual (en $NCHOME/etc/precision/CtrlServices.cfg) para tener una dependencia en todos los procesos listados en el archivo$NCHOME/etc/precision/VirtualDomainSchema.cfg.

• Compruebe que el proceso ncp_config está en ejecución. Puede comprobar el estado dencp_config consultando la base de datos del proceso ncp_ctrl. Si se ejecuta sin ningún problema,ncp_config debería tener el valor serviceState = 4 en la tabla de base de datos services.inTray.Para obtener más información acerca de cómo identificar qué procesos están en ejecución, consulte lapublicación IBM Tivoli Network Manager IP Edition Administration Guide.

Si la conexión de TCP no se ha establecido:

• Compruebe que los archivos $NCHOME/etc/precision/ServiceData.cfg en ambos dominiostienen la misma entrada para el proceso de Dominio virtual.

• Compruebe que los cortafuegos de límite entre los dominios permiten la conexión de TCP en el puertode servidor definido.

• Compruebe que el puerto definido está disponible para su uso en el dominio principal.

Tareas relacionadasConfiguración de dependencias de proceso para la migración tras errorAl ejecutar Network Manager en modalidad de migración tras error, debe iniciar los procesos de NetworkManager utilizando el proceso ncp_ctrl. El orden en el que se inician los procesos es importante y estádefinido por las dependencias de proceso que están configuradas en el archivo $NCHOME/etc/precision/CtrlServices.cfg.Configuración la conexión de socket TCP entre los dominiosEs necesaria un conexión de socket TCP entre los procesos de dominio virtual en los dominios primario yde copia de seguridad para que los datos de topología y las actualizaciones de topología se puedan copiaren el dominio de copia de seguridad.


Secuencia para reiniciar los procesos del servidor en una configuración demigración tras errorUtilice esta información como guía para reiniciar los procesos del servidor si su entorno de migración traserror de Network Manager requiere un rearranque de todos los servidores.

Inicie los procesos en el orden siguiente:

1. Inicie el ObjectServer principal. En función de su configuración de instalación y configuración, podráutilizar uno de los siguientes métodos:

• Control de procesos de Tivoli Netcool/OMNIbus en UNIX y Linux• El mandato Tivoli Netcool/OMNIbus nco_objserv

Para obtener más información acerca del uso de los mandatos de Tivoli Netcool/OMNIbus para iniciarel ObjectServer, consulte la documentación de Tivoli Netcool/OMNIbus en http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html.

Para obtener más información acerca del inicio de ObjectServer utilizando los mandatos de NetworkManager, consulte la publicación IBM Tivoli Network Manager IP Edition Administration Guide.

2. Inicie el ObjectServer de copia de seguridad.3. Inicie la base de datos de topología si no está aún en ejecución.4. Inicie el servidor principal de Network Manager en el que están instalados los procesos principales,

utilizando el mandato itnm_start o iniciando el controlador del proceso maestro, ncp_ctrl.

Igualmente, verifique que el proceso del Dominio virtual del dominio principal se ha iniciado,ejecutando el mandato itnm_status en el directorio $NCHOME/precision/bin.

Para obtener más información acerca del inicio del servidor y de los procesos de Network Manager,consulte la publicación IBM Tivoli Network Manager IP Edition Administration Guide.

5. Inicie el servidor de copia de seguridad de Network Manager en el que están instalados los procesosprincipales.

Consejo: El servidor de Dashboard Application Services Hub, en el que están instaladas las aplicacionesweb de Network Manager y la GUI web de Tivoli Netcool/OMNIbus, se inicia automáticamente siempreque se inicia el sistema.

Configuración de la seguridadPara proteger la instalación ITNM de ataques maliciosos de intrusos, debe realizar las siguientes tareas.

Configuración de cookiesLas aplicaciones web Network Manager utilizan cookies para realizar seguimiento a los usuarios a travésde las solicitudes. Aunque estas cookies no distinguen entre mayúsculas y minúsculas, un intruso puedeutilizarlas para suplantarle en el sistema. Dado que el tráfico de red a menudo viaja por redes no fiables,estas cookies deben cifrarse utilizando SSL


Configuración de las cookies de Dashboard Application Services HubEn el caso de las comunicaciones que implican a Dashboard Application Services Hub, la cookie másimportante es la cookie de sesión HTTP; por lo tanto, debe configurarse para enviarse únicamente através de SSL.

Acerca de esta tareaPara limitar la cookie de sesión HTTP para comunicarse utilizando únicamente el protocolo HTTPS,realice los pasos de la nota técnica ubicada en: https://www.ibm.com/support/pages/node/250915





Configuración de la cookie WebSphere LTPAEl mecanismo Lightweight Third Party Authentication (LTPA) está asociado con roles y autenticación entoda la sesión de inicio de sesión. Si un intruso puede interceptar la cookie LTPA pueden suplantarle. Paraprotegerse contra esto, debe asegurarse de que la cookie LTPA se transmite sólo a través de SSL.


Procedimiento1. Pulse Seguridad > Seguridad global.2. Pulse Autenticación > Seguridad de web > Inicio de sesión único (SSO).3. Pulse Requiere SSL.4. Haga clic en Aceptar.5. Reinicie el servidor Dashboard Application Services Hub.

Protección contra clickjackingSi integra aplicaciones web Network Manager en su producto, tenga en cuenta que la integración nopodrá mostrar la GUI de acceso de bases de datos y la GUI de configuración de descubrimiento, debido aun filtro protector implementado dentro de Network Manager. Estas dos GUI contienen informaciónconfidencial; impedir la integración de estas dos GUI le protege contra clickjacking, por medio del cual unintruso crea una superposición de la GUI para capturar datos. Puede inhabilitar el filtro; sin embargo, estono es recomendable.

Acerca de esta tareaEl filtro se implementa utilizando la propiedad tnm.enableClickjackProtection en el archivotnm.properties.

Nota: Si esta propiedad no está presente en el filtro, el filtrado está habilitado de forma predeterminada.

Procedimiento1. Haga una copia de seguridad y edite el archivo $NMGUI_HOMEprofile/etc/tnm/tnm.properties.2. Busque la entrada tnm.enableClickjackProtection=true.3. Cambie la entrada a tnm.enableClickjackProtection=false.

Nota: Si esta propiedad no está presente en el filtro, escriba:tnm.enableClickjackProtection=false.

Cambio de la dirección IP y el nombre de host de la instalación deNetwork Manager

Si cambia la dirección IP y el nombre de host del servidor donde se han instalado los componentes deNetwork Manager o los productos integrados, debe configurar Network Manager y los productos ycomponentes asociados.

Cambio de la dirección IP y el nombre de host para Network ManagerSi desea cambiar la dirección IP y el nombre de host para el servidor donde se han instalado loscomponentes principales de Network Manager, debe realizar algunas tareas de configuración.

Acerca de esta tareaSiga estos pasos para cambiar la dirección IP y el nombre de host en el servidor de Network Manager.


Procedimiento1. Vaya al siguiente directorio: NCHOME/etc/.2. Edite el archivo de configuración: itnm.cfg.3. Cambie el siguiente parámetro: ncp. Actualícelo al nuevo nombre de host del servidor de Network

Manager: por ejemplo: ncp=myhost.4. Guarde el archivo itnm.cfg.5. Vaya al siguiente directorio: NCHOME/etc/precision/.6. Edite el archivo: ServiceData.cfg.7. Cambie la línea siguiente:

SERVICE: ncp_config DOMAIN: NCOMS ADDRESS: Network_Manager_server_IP_address PORT: port_number SERVERNAME: Network_Manager_server_hostname DYNAMIC: NO

Donde:

• dirección_IP_servidor_Network_Manager es la nueva dirección IP del servidor de Network Manager.• nombre_host_servidor_Network_Manager es el nuevo nombre de host del servidor de Network

Manager.8. Guarde el archivo ServiceData.cfg.

Cambio de la dirección IP y el nombre de host en el servidor de TivoliNetcool/OMNIbus

Si desea cambiar la dirección IP y el nombre de host en el servidor de Tivoli Netcool/OMNIbus, deberealizar algunas tareas de configuración.

Acerca de esta tareaSiga estos pasos para cambiar la dirección IP y el nombre de host en el servidor de Tivoli Netcool/OMNIbus:

Procedimiento1. Vaya al siguiente directorio: NCHOME/etc/.2. Edite el archivo: omni.dat.3. Busque las líneas que contengan el servidor de Tivoli Netcool/OMNIbus. Estas líneas serán parecidas a

las siguientes:

[NCOMS]{ Primary: OMNIbus_server_hostname 4100}[NCO_PA]{ Primary: OMNIbus_server_hostname 4200}

Donde:

• nombre_host_servidor_OMNIbus es el nombre de host del servidor de Tivoli Netcool/OMNIbus.

Cambie el nombre de host del servidor de Tivoli Netcool/OMNIbus en cada una de estas líneas.4. Ejecute el programa de utilidad NCHOME/bin/nco_igen para aplicar los cambios.5. Repita los pasos anteriores en cada uno de los host que se conectan al servidor de Tivoli Netcool/

OMNIbus; por ejemplo, realice estos cambios en los analizadores, las pasarles y los ObjectServersconectados.


Actualización de Network Manager para un nuevo nombre de host o unanueva dirección IP de Tivoli Netcool/OMNIbus

Si actualiza la dirección IP y el nombre de host del servidor de Tivoli Netcool/OMNIbus, debe configurarNetwork Manager para que utilice la nueva dirección IP y el nuevo nombre de host.

Acerca de esta tareaSiga estos pasos para actualizar Network Manager para que reconozca los cambios en el nombre de hostdel servidor de Tivoli Netcool/OMNIbus:

Procedimiento1. Actualice los componentes principales de Network Manager editando el archivo de configuración:NCHOME/etc/itnm.cfg.

2. Cambie el siguiente parámetro: nco. Actualícelo al nuevo nombre de host del servidor de TivoliNetcool/OMNIbus: por ejemplo: nco=omnihost.

3. Guarde el archivo itnm.cfg.4. Actualice los componentes de la GUI de Network Manager editando el archivodir_instalación_webgui/etc/datasources, donde dir_instalación_webgui es eldirectorio de instalación de la GUI web; por ejemplo, $NCHOME/omnibus_webgui.

5. Actualice las aplicaciones web de Network Manager para configurarlas para que utilicen el nombre dehost del servidor de Tivoli Netcool/OMNIbus modificado:a) Edite el archivo siguiente:

NCHOME/omnibus_webgui/etc/datasources/ncwDataSourceDefinitions.xml

b) Cambie los valores de host y puerto en las siguientes secciones para que coincidan con laconfiguración actualizada:

• <ncwPrimaryServer>• <ncwBackUpServer>

Nota: Cambie sólo esta sección si se ha configurado un ObjectServer de Tivoli Netcool/OMNIbusde copia de seguridad.

c) Guarde el archivo ncwDataSourceDefinitions.xml modificado.

Actualización de Dashboard Application Services Hub para un nuevo nombrede host o una nueva dirección IP de Tivoli Netcool/OMNIbus

Si el servidor de Dashboard Application Services Hub se ha configurado originalmente para utilizar elObjectServer de Tivoli Netcool/OMNIbus como repositorio de usuarios primario, y actualiza la dirección IPy el nombre de host del servidor de Tivoli Netcool/OMNIbus, debe configurar Dashboard ApplicationServices Hub para que utilice la nueva dirección IP y el nuevo nombre de host.

Acerca de esta tareaSiga estos pasos para configurar Dashboard Application Services Hub para que utilice el nuevo nombre dehost del servidor de Tivoli Netcool/OMNIbus:

Procedimiento1. Edite el archivo siguiente:

$JazzSM_HOME/profile/config/cells/JazzSMNode01Cell/wim/config/wimconfig.xml


2. Cambie las propiedades host1 y port1 para que coincidan con la configuración actualizada en elarchivo siguiente:

config:repositories adapterClassName="com.ibm.tivoli.tip.vmm4ncos.ObjectServerAdapter"

3. Guarde el archivo wimconfig.xml modificado.

Cambio de la dirección IP y el nombre de host en el servidor de DashboardApplication Services Hub

Si desea cambiar la dirección IP y el nombre de host de Dashboard Application Services Hub, debeconfigurar Dashboard Application Services Hub.

Acerca de esta tareaSiga estos pasos para cambiar la dirección IP y el nombre de host en el servidor de Dashboard ApplicationServices Hub:

Procedimiento1. Vaya al siguiente directorio: $JazzSM_HOME/profile/bin/.2. Utilice el comando wsadmin para cambiar el nombre de host y la dirección IP de Dashboard

Application Services Hub:

wsadmin.sh -user smadmin -password password -c "\$AdminTask changeHostName {-hostName new_hostname -nodeName new_node}" -c "\$AdminConfig save"

Proporciona una salida similar a la siguiente:

WASX7209I: Conectado al proceso "server1" en el nodo Nodename mediante el conector SOAP; El tipo de proceso es: UnManagedProcess

3. Reinicie el servidor Dashboard Application Services Hub.

Actualización de Network Manager para el nombre de host cambiado delservidor de Dashboard Application Services Hub

Si cambia el nombre de host del servidor de Dashboard Application Services Hub, debe configurarNetwork Manager para que utilice el nuevo nombre de host.

Acerca de esta tareaPara configurar Network Manager para que utilice el nuevo nombre de host, siga estos pasos:

Procedimiento1. Actualice los componentes principales de Network Manager editando el archivo de configuración:NCHOME/etc/itnm.cfg.

2. Cambie el siguiente parámetro:

tip

Actualícelo al nuevo nombre de host del servidor de Dashboard Application Services Hub; por ejemplo:

tip=tiphost

3. Guarde el archivo itnm.cfg.


Configuración de Network Manager para una dirección IP modificada delservidor de Db2 NCIM

Si cambia la dirección IP o el nombre de host del servidor de Db2 que aloja la base de datos de topologíaNCIM, debe configurar Network Manager para que utilice los nuevos detalles.


Procedimiento1. En el servidor donde se ha instalado Network Manager, edite el siguiente archivo:

NCHOME/etc/precision/DbLogins.DOMAIN.cfg

2. Cambie los valores de nombre de host en este archivo y guárdelo.3. Edite el archivo siguiente:

NCHOME/etc/precision/MibDbLogin.cfg

4. Cambie los valores de nombre de host en este archivo y guárdelo.5. En el servidor donde se han instalado las aplicaciones web de Network Manager, edite el siguiente

archivo:

$NMGUI_HOME/profile/logs/tnm/tnm.properties

6. Cambie los valores de nombre de host en este archivo y guárdelo.

Establecimiento de variables de entornoAntes de iniciar cualquier componente o de trabajar con un archivo de configuración, establezca lasvariables de entorno adecuadas ejecutando los scripts del entorno.

Acerca de esta tareaLos scripts de entorno establecen las siguientes variables de entorno necesarias. Los scripts de entornose configuran automáticamente con las ubicaciones correctas en las que se han instalado loscomponentes. Otras variables del entorno se establecen automáticamente cuando es necesario mediantecomponentes de Network Manager.

$NCHOMELa ubicación de inicio de Netcool que se establece de forma predeterminada en el directorio netcooldebajo del directorio de instalación:

• /opt/IBM/netcool/core

$NMGUI_HOMELa ubicación en la que se han instalado los componentes de la GUI de Network Manager. De formapredeterminada, esta ubicación es /opt/IBM/netcool/gui/precision_gui.

$ITNMHOME y $PRECISION_HOMELa ubicación de inicio de Network Manager toma como valor predeterminado $NCHOME/precision:

• /opt/IBM/netcool/core/precision

Nota: El script también establece $PRECISION_HOME. De forma predeterminada,$PRECISION_HOME se establece en la misma ubicación que $ITNMHOME, pero la utilizan otroscomponentes del producto.

$DASH_HOMELa ubicación de instalación de Dashboard Application Services Hub. De forma predeterminada, estaubicación es /opt/IBM/JazzSM/ui.


$JazzSM_HOMELa ubicación de instalación de Jazz for Service Management. De forma predeterminada, estaubicación es /opt/IBM/JazzSM.

Para establecer las variables de entorno de Network Manager, ejecute el script adecuado para loscomponentes que ha instalado. Existen scripts diferentes en el servidor en el que se han instalado loscomponentes principales y el servidor en el que se han instalado los componentes de la GUI.

Importante: Si ha instalado los componentes principales y los componentes de la GUI en un servidor,ejecute ambos scripts.

Procedimiento• Ejecute el script de entorno adecuado:


Por ejemplo, en los shells Bash, Bourne y Korn, obtenga el script env.sh mediante un mandato similaral siguiente:

. /opt/IBM/netcool/core/env.sh

En el servidor en el que se han instalado los componentes de la GUI De Network Manager, el script esdirectorio_instalación/nmgui_profile.sh, por ejemplo, /opt/IBM/netcool/nmgui_profile.sh.

Por ejemplo, en los shells Bash, Bourne y Korn, obtenga el script nmgui_profile.sh mediante unmandato similar al siguiente:

. /opt/IBM/netcool/nmgui_profile.sh

Qué hacer a continuaciónUna vez que haya establecido las variables de entorno, inicie Network Manager y asegúrese de que seesté ejecutando correctamente.

Estructura de directorios predeterminadaUtilice esta información para entender la estructura de directorios de Network Manager.

Estructura de directorios de nivel superiorEn el directorio en el que está instalado Network Manager, se crea el subdirectorio netcool. A su vez, eldirectorio netcool contiene los subdirectorios siguientes:

• core: contiene archivos de configuración para los procesos de programa de fondo de Network Manager.• gui: contiene archivos de configuración para los procesos de GUI:

– omnibus_gui: Si está presente, contiene los archivos de GUI web de Tivoli Netcool/OMNIbus.– precision_gui: contiene archivos de GUI de Network Manager.

Para obtener más información acerca de los directorios de instalación para Tivoli Netcool/OMNIbus y GUIweb de Tivoli Netcool/OMNIbus, consulte la publicación IBM Tivoli Netcool/OMNIbus Installation andDeployment Guide.

Directorios utilizados por el instaladorEl instalador instala archivos en NCHOME y en otros directorios, en función del sistema operativo que seinstale y del usuario que realice la instalación. La tabla siguiente lista los directorios extra utilizados por elinstalador.


Nota: Desde la versión 4.2 en adelante, NCHOME es directorio_instalación/netcool/core; porejemplo, opt/ibm/netcool/core.

Tabla 14. Directorios utilizados por el instalador

Instalación Directorios utilizados por los archivos de instalación

sistemas operativos UNIX,usuario root

/usr/ibm/common/acsi

/var/ibm/common/acsi

sistemas operativos UNIX,usuario no root

~/.acsi_$HOSTNAME

~/tivoli

~/.cit (es decir, en el directorio inicial del usuario)

Contenido del directorio netcoolLa tabla siguiente describe el contenido del directorio netcool/core. Todas las vías de acceso semuestran relativas a NCHOME. En esta tabla, arch denota un directorio del sistema operativo. El nombre deeste directorio varía según el sistema operativo en el que está instalado el software:

• Linux – linux2x86• AIX – aix5• zLinux - linux2s390

Si ha instalado otros productos de IBM Tivoli, como por ejemplo IBM Tivoli Business Service Manager, enel mismo servidor que Network Manager, puede que haya directorios y archivos extra presentes. Consultela documentación para cualquier otro producto que haya instalado para obtener más información sobresus directorios y archivos.

Tabla 15. Directorios de NCHOME

Directorio Descripción

bin Contiene scripts de derivador que establecen el entorno y ejecutan losarchivos binarios para el producto o componentes facilitados con NetworkManager.

etc Contiene archivos de configuración para productos o componentesfacilitados con Network Manager.

etc/precision Archivos de configuración para todos los componentes de NetworkManager.

license Contiene el texto del acuerdo de licencia de producto en varios idiomas.

registro Contiene archivos de registro.

log/install Contiene archivos de registro para la instalación.

log/precision Contiene archivos de registro creados por los procesos de NetworkManager.

omnibus Si está presente, contiene los archivos de IBM Tivoli Netcool/OMNIbus.

platform/arch Contiene los archivos de Java Development Kit (JDK) y Java RuntimeEnvironment (JRE).

Nota: Dashboard Application Services Hub utiliza el JRE de WebSphereApplication Server.

precision Contiene archivos para Network Manager. Consulte más adelante en estetema.


Tabla 15. Directorios de NCHOME (continuación)


probes Contiene archivos para la Sonda para IBM Tivoli Netcool/OMNIbus, elproceso nco_p_ncpmonitor.

properties Contiene archivos utilizados por el proceso de instalación. No deberíanecesitar alterar el contenido de este directorio.

var Contiene datos de aplicación persistente.

var/install Contiene archivos de la base de datos para el proceso de instalación.

var/precision Utilizado por el proceso ncp_store para guardar información en caché quese pueda utilizar para restaurar las bases de datos, en caso de que unproceso finalice de forma inesperada.

Contenido del directorio precisionLa tabla siguiente describe el contenido del directorio NCHOME/precision. Todas las vías de acceso semuestran relativas a NCHOME/precision.

En esta tabla, arch denota un directorio del sistema operativo. El nombre de este directorio varía según elsistema operativo en el que está instalado el software:

• Linux – linux2x86• AIX – aix5• zLinux - linux2s390

Nota: NCHOME/precision es la vía de acceso establecida de forma predeterminada paraPRECISION_HOME e ITNMHOME.

Tabla 16. Directorios de NCHOME/precision


adapters/ncp_dla Contiene archivos para el adaptador de biblioteca utilizado para laintegración con productos como por ejemplo IBM Tivoli ApplicationDependency Discovery Manager.

aoc Contiene los archivos de AOC (Active Object Class) utilizados por la gestiónde clase dinámica y el sistema de distribución, CLASS.

bin Contiene scripts de derivadores para todos los archivos ejecutables. Losarchivos ejecutables se guardan en la ubicación siguiente: platform/arch/bin

collectors/perlCollectors

Contiene archivos para las integraciones de sistema de gestión deelementos.

contrib Contiene programas de utilidad no soportados para la gestión de NetworkManager. Igualmente utilizado por Netcool para la solución de gestión deactivos para contener informes de ejemplo de SQL*Plus.

cshrc Únicamente en los sistemas operativos UNIX. Utilizado para configurar elentorno para su shell C.

disco Contiene archivos utilizados por DISCO. Contiene los archivos de definicióndel agente, los agentes de descubrimiento, el buscador, los archivos delayudante y los agrupadores.

embeddedDb Contiene archivos para dNCIM.


Tabla 16. Directorios de NCHOME/precision (continuación)


eventGateway Contiene agrupadores para la pasarela de sucesos y RCA.

integración Contiene archivos para la integración de la GUI de componentes.

install Contiene archivos utilizados por el proceso de instalación.

java_api Contiene el API de JAVA para desarrollar aplicaciones Java que se integrancon componentes de Network Manager.

mibs Contiene archivos MIB (base de información de gestión).

PD Cualquier archivo principal generado mediante Network Manager se escribeen subdirectorios del directorio PD. Los archivos principales se puedenutilizar para ayudar a diagnosticar la causa de un problema.

perl Contiene archivos perl utilizados en Network Manager.

platform/arch Contiene subdirectorios particulares al sistema operativo en el que hainstalado Network Manager.

platform/arch/bin Contiene archivos ejecutables para los componentes de Network Manager.Los archivos se agregan a su entorno PATH.

Los scripts de derivadores para todos estos archivos ejecutables se guardanen la ubicación siguiente: NCHOME/precision/bin.

platform/arch/jre Contiene el entorno de ejecución JAVA utilizado por Network Manager.

platform/arch/lib Contiene las bibliotecas de objeto utilizadas por todos los componentes deNetwork Manager.

platform/java/lib La instalación de la GUI de la configuración del supervisor.

La instalación de la Herramienta de configuración del usuario.

products Contiene los archivos de la GUI para productos integrados.

perfil Únicamente en los sistemas operativos UNIX. Utilizado para configurar elentorno para su shell Bash.

profiles Contiene los archivos relacionados con la GUI.

Nota: Todos los archivos específicos de Network Manager previamenteubicados en TIPHOME/profiles están ahora ubicados en ITNMHOME/profiles.

scripts Contiene scripts facilitados con los productos de Network Manager. Serecomienda guardar cualquier script definido por el usuario en estedirectorio para que se pueda gestionar de forma sencilla.

storm Contiene scripts de Apache Storm.

system Contiene archivos para el funcionamiento de los productos.

systemApps Contiene archivos para las aplicaciones web.

Referencia relacionadaRequisitos del directorio de instalaciónEl directorio donde instale Network Manager debe cumplir ciertos requisitos.


Configuración de los dispositivos de Juniper PEUno de los sondeos de dispositivo habilitados de manera predeterminada es el sondeo de ping remoto deJuniper. Para asegurarse de que este sondeo es capaz de recuperar datos, debe configurar cadadispositivo de Juniper PE para proporcionar acceso a algunas tablas en el dispositivo.

Las operaciones de sondeo de ping remoto en dispositivos Juniper requieren acceso a las tablaspingCtlTable y jnxPingCtlTable en los dispositivos de Juniper PE. Esto se logra utilizando elmodelo de control de acceso basado en vista (VACM) de SNMP para visualizar PrecisionIP.

Asegúrese de que ha configurado cada dispositivo de Juniper PE para proporcionar acceso a estas tablaspara visualizar PrecisionIP antes de habilitar la política de sondeo de ping remoto de Juniper.

El siguiente ejemplo muestra cómo un dispositivo de Juniper PE se puede configurar para proporcionaracceso para visualizar PrecisionIP a las tablas necesarias para el sondeo de ping remoto.

Configuración del acceso utilizando VACM

Para proporcionar acceso a las tablas pingCtlTable y jnxPingCtlTable para visualizarPrecisionIP en un dispositivo de Juniper PE, haga lo siguiente:

1. Utilice el mandato telnet para iniciar sesión en el dispositivo PE.2. Especifique configure para iniciar la línea de mandatos de edición.3. Escriba edit snmp y pulse Intro.4. Escriba edit view PrecisionIP y pulse Intro.5. Escriba set oid 1.3.6.1.2.1.80 include y pulse Intro.6. Escriba set oid 1.3.6.1.4.1.2636.3.7 include y pulse Intro.7. Escriba up y pulse Intro.8. Escriba edit community watermelon y pulse Intro, donde watermelon es la nueva cadena de

comunidad de escritura.9. Escriba set view PrecisionIP y pulse Intro.

10. Escriba set authorization read-write y pulse Intro.11. Escriba commit y pulse Intro.12. Escriba exit y pulse Intro. Se crean nuevas entradas para visualizar PrecisionIP en la tabla de

MIB vacmViewTreeFamilyTable en el dispositivo PE.

Para visualizar el resumen de la sección insertada, puede escribir show configuration snmp ypulsar Intro. Aparece la siguiente pantalla:

view PrecisionIP {oid 1.3.6.1.2.1.80 include;oid 1.3.6.1.4.1.2636.3.7 include;}community watermelon {view PrecisionIP;authorization read-write;}

Los valores anteriores proporcionan acceso a las tablas necesarias para las operaciones de sondeode ping remoto utilizando la cadena de comunidad watermelon.

Configuración de dominiosPuede configurar los dominios de red para que coincidan con el entorno.

Creación y configuración de dominios de red adicionalesPara añadir más dominios de red, configure el control de procesos para los dominios y registre losdominios con la base de datos de topología de NCIM. Es posible copiar configuraciones y sondeos de


dominios existentes. Configure o reconfigure las vistas de red para que muestren los dispositivos en losnuevos dominios.

Acerca de esta tareaUtilice una instancia del proceso ncp_ctrl para ejecutar y gestionar cada dominio. Si no hay un procesoncp_ctrl en ejecución para un dominio, el dominio no se podrá configurar en la GUI.

Puede ejecutar el script domain_create.pl para copiar los datos de configuración desde un dominioexistente. El script no copia la topología desde el dominio original.Para obtener directrices sobre elnúmero de dominios de red necesarios en un despliegue, consulte Guía del usuario de IBM Tivoli NetworkManager.

Procedimiento1. Realice una copia de seguridad del archivo $NCHOME\etc\precision\CtrlServices.cfg para el

dominio que se creó durante la instalación del producto.2. Realice una copia del archivo CtrlServices.cfg y cambie su nombre aCtrlServices.DOMINIO.cfg, donde DOMINIO es el dominio.

Restricción: Utilice únicamente caracteres alfanuméricos y subrayados (_) para los nombres dedominio. Todos los demás caracteres, como el guión (-), están prohibidos.

Por ejemplo, CtrlServices.MASTER.cfg.A continuación, edite el archivo CtrlServices.DOMINIO.cfg según sea necesario.

3. Para configurar un descubrimiento para el dominio:a) Realice una copia de seguridad y cree versiones específicas de dominio de los archivos de

configuración del descubrimiento.Por ejemplo, DiscoPingFinderSeeds.MASTER.cfg

b) Configure los valores en los archivos específicos del dominio.

4. Realice una copia de seguridad y construya una versión específica del dominio del archivo$NCHOME/etc/precision/ConfigItnm.cfg.Por ejemplo, ConfigItnm.MASTER.cfg.A continuación, especifique los detalles de conexión del ObjectServer en dicho archivo.

5. Para registrar el nuevo dominio con la base de datos de topología de NCIM, realice una copia deseguridad y cree una versión específica del dominio del archivo $NCHOME/etc/precision/DbLogins.cfg. A continuación, edite la información de conexión de base de datos en dicho archivo.

6. Para establecer la conexión a un origen de datos de GUI web de Tivoli Netcool/OMNIbus distinto:a) Realice una copia de seguridad y cree una copia específica del dominio del archivo$NCHOME/etc/precisionModelNcimDb.cfg.Por ejemplo, ModelNcimDb.MASTER.cfg

b) En el archivo específico del dominio, cambie la propiedad m_WebTopDataSource al nombre delorigen de datos.

7. Para copiar los sondeos de red y configuración desde un dominio existente, ejecute el scriptdomain_create.pl.El ejemplo siguiente crea un dominio denominado MASTER con la contraseña PASSWORD.

$NCHOME/precision/bin/ncp_perl $NCHOME/precision/scripts/perl/scripts/domain_create.pl -domain MASTER -password PASSWORD

8. Inicie los procesos de Network Manager en el dominio.Por ejemplo:

itnm_start ncp -domain MASTER

9. Cree nuevas vistas de red en el nuevo dominio, o modifique las vistas de red existentes.


En el separador Filtro, seleccione el nuevo dominio. Si no especifica el nuevo dominio en las vistas dered, no podrá ver los dispositivos de dicho dominio. Si ha ejecutado anteriormente scripts desuministro automático para crear vistas de red automáticamente, debe volver a ejecutarlosespecificando el nuevo dominio. Cuando se ejecuta un descubrimiento de red en el nuevo dominio,las nuevas vistas de red se rellenan con dispositivos. Para obtener más información sobre vistas dered, consulte Guía del usuario de IBM Tivoli Network Manager.

10. Repita los pasos para configurar todos los dominios.

Qué hacer a continuaciónUna vez iniciado ncp_ctrl en el dominio, podrá configurar el dominio. Por ejemplo, configure eldescubrimiento en la GUI Descubrimiento de red o edite archivos de configuración, o configure el sondeode red. Seleccione el dominio antes de configurar el descubrimiento o sondeo.

Para obtener más información sobre la configuración del descubrimiento, consulte la publicación IBMTivoli Network Manager IP Edition Administration Guide. Para obtener más información sobre laconfiguración del sondeo de red, consulte la publicación IBM Tivoli Network Manager IP EditionAdministration Guide.

Dado que el descubrimiento de red es un proceso que utiliza muchos recursos, los descubrimientos seejecutan por el general en un solo dominio al mismo tiempo. Para ejecutar descubrimientos para variosdominios simultáneamente, asegúrese de tener suficientes recursos disponibles. Las comprobacionestípicas son las siguientes:

• Asegúrese de que se han configurado suficientes conexiones de base de datos.• Asegúrese de que los dispositivos de red no se sobrecargan con el tráfico.• Asegúrese de que hay suficiente memoria disponible en el host para ejecutar el descubrimiento, por

ejemplo, mediante la comprobación del uso de memoria de los procesos de Network Manager.

Conceptos relacionadosDominios de redAntes de la instalación, tiene que tener en cuenta si partirá su red en dominios, o si tendrá un únicodominio para toda la red. Un dominio de red es una colección de entidades de red preparadas para serdescubiertas y gestionadas.

Enlace de un dominio a un controlador de interfaz de red (NIC)Enlazar dominios de cliente diferentes a NCI diferentes puede resolver problemas con direccionamientode dispositivo. Por ejemplo, si dos de los dominios de cliente tienen direcciones IP solapadas y estáutilizando Network Manager en un único servidor para gestionar ambas redes, enlazando estos dosdominios de cliente para separar NCI, habilita Network Manager para direccionar de forma exclusivaestas direcciones IP.

Acerca de esta tareaPor ejemplo, suponga que tiene dos clientes A y B, y estos dos clientes tienen rangos de dirección IPsolapados. Por ejemplo, suponga que tienen un direccionador con dirección IP 192.168.1.1. Estáutilizando Network Manager en un único servidor para gestionar ambas redes de clientes. El problema es:cómo pueden los procesos de Network Manager distinguir entre estos dos dispositivos. Por ejemplo, sihace ping en la dirección IP 192.168.1.1, ¿a qué direccionador de cliente se hace ping?

Para resolver este problema y problemas similares, realice los pasos siguientes:

Procedimiento1. Instale los dos NIC independientes en el servidor Network Manager.

El cable desde el NIC A lleva a la red del cliente A y el cable desde el NIC B lleva a la red del cliente B.

Nota: Es posible que tenga que instalar más de dos NIC. Los pasos dados aquí son con finesilustrativos y se aplican al ejemplo proporcionado anteriormente en este tema.


2. Asigne el NIC A al dominio del cliente A y el NIC B al dominio del cliente B añadiendo las siguienteslíneas al archivo de configuración $NCHOME/etc/precision/ServiceData.cfg configuration file.

-SERVICE: IPv4BindAddress DOMAIN: CUST_A_DOMAIN ADDRESS: NIC_A_IP_ADDR PORT: 0 SERVERNAME: itnmserver DYNAMIC: NOSERVICE: IPv4BindAddress DOMAIN: CUST_B_DOMAIN ADDRESS: NIC_B_IP_ADDR PORT: 0 SERVERNAME: itnmserver DYNAMIC: NO

Donde:

• CUST_A_DOMAIN es un nombre de dominio para el cliente A.• CUST_B_DOMAIN es un nombre de dominio para el cliente B.• NIC_A_IP_ADDR es la dirección IP del NIC asignado al dominio del cliente A.• NIC_B_IP_ADDR es la dirección IP del NIC asignado al dominio del cliente B.

Esto garantiza que cada dominio utilizará un NIC diferentes y los paquetes de cada dominio irán alcliente adecuado.

3. Guarde el archivo de configuración de $NCHOME/etc/precision/ServiceData.cfg.

Configuración de una base de datos dNCIM en Linux on IBM zSystems

En Linux on IBM z Systems, debe realizar algunos cambios de configuración en la base de datos dNCIM.De forma predeterminada, la base de datos dNCIM se implementa utilizando la base de datos SolidDB.Esta base de datos se instala automáticamente y no es necesario realizar ninguna tarea de configuración.Sin embargo, SolidDB no se admite en Linux on IBM z Systems. Si está trabajando en Linux on IBM zSystems y desea utilizar dNCIM, deberá instalar una base de datos alternativa, , y configurarla para quefuncione con el motor de descubrimiento, ncp_disco.

Acerca de esta tareaPara configurar una base de datos dNCIM en Linux on IBM z Systems realice las tareas siguientes:

Procedimiento1. Cree una entrada para la base de datos en el archivo DbLogins.domain.cfg, donde domain es el

nombre de su dominio.Por ejemplo:

insert into config.dbserver( m_DbId, m_Server, m_DbName, m_Schema, m_Hostname, m_Username, m_Password, m_PortNum, m_EncryptedPwd m_EmbeddedProcess m_ScriptTimeoutSecs)values( "DNCIM", "Db2", "ITNM", "dncim", "localhost", "user", "password", 50000, 1 "ncp_disco"


100);

En esta inserción, el argumento m_ScriptTimeoutSecs establece un tiempo de espera en segundospara los scripts SQL que se ejecutan en esta base de datos. Puede ser necesario un tiempo de esperasi la base de datos dNCIM es lenta; por ejemplo, cuando la base de datos no está insertada enncp_disco o con un servidor de datos lento.

Nota: En este ejemplo, la base de datos es local para el motor de descubrimiento, ncp_disco, por loque el atributo m_Hostname se establece en localhost. Mantener la base de datos local para elproceso de descubrimiento garantiza descubrimientos más rápidos.

2. Rellen el esquema de la base de datos usando el script $NCHOME/precision/scripts/sql/create_db_schemas.pl de Perl.Por ejemplo:

./create_db_schemas.pl -server oracle|db2|| -dbname dbname -schema schema -host hostName -username username -password password -port port -action ncim

Donde:

• El atributo -server es el tipo de base de datos.• El atributo dbname varía con el tipo de base de datos.

– En Oracle, utilice el valor SID.– En Db2, use el valor m_DbId procedente de la inserción DbLogins.domain.cfg.

• El valor schema coincide con el argumento m_Schema procedente de la inserciónDbLogins.domain.cfg. Por ejemplo, establezca schema en dncim para que coincida con lainserción de ejemplo del paso 1.

Nota: Puede asignar cualquier nombre al esquema de datos. El valor que utiliza para m_Schema enla inserción DbLogins.domain.cfg debe coincidir con el valor que utilice con el argumento -schema en el script create_db_schemas.pl.

• El atributo -action toma el valor ncim porque las bases dNCIM y NCIM son idénticas en formato.

Configuración del ayudante de SNMPEl descubrimiento y el sondeo utilizan el ayudante de SNMP para enviar solicitudes SNMP a losdispositivos de red. Puede configurar cómo el ayudante de SNMP envía las solicitudes SNMP y cómoprocesa los resultados de las solicitudes SNMP.

Acerca de esta tareaPara obtener información sobre dónde se utiliza el ayudante de SNMP en el descubrimiento y el sondeo,consulte las siguientes publicaciones:

• Para el descubrimiento, consulte IBM Tivoli Network Manager IP Edition Administration Guide.• Para el sondeo, consulte IBM Tivoli Network Manager IP Edition Administration Guide.

Configuración de la regulación del ayudante de SNMPPuede activar la regulación en el ayudante de SNMP. La activación de la regulación aumenta el retardoentre las solicitudes SNMP de Network Manager a un dispositivo de red. Esto disminuye la carga en eldispositivo de red. De forma predeterminada, la regulación está desactivada en el ayudante de SNMP.

Acerca de la regulación del ayudante de SNMPLa regulación del ayudante de SNMP establece un retardo entre las solicitudes SNMP enviadas por elayudante de SNMP mediante una fórmula que utiliza los parámetros GeneralSlowdown,GetNextBoundary y GetNextSlowdown.


A continuación, se muestra cómo el ayudante de SNMP envía las solicitudes sin regulación (valorpredeterminado) y con regulación:

• Cuando la regulación está desactivada, las operaciones GetNext de SNMP funcionan de la siguientemanera: el ayudante de SNMP envía la primera solicitud Get de SNMP y cuando Network Managerobtiene una respuesta, el ayudante de SNMP envía inmediatamente la solicitud GetNext.

• Cuando la regulación está activada, se introduce un retardo entre las solicitudes GetNext. El retardopuede ser un retardo más breve definido de forma general o un retardo más largo. El sistema realiza unseguimiento del número de solicitudes GetNext que se envían a un dispositivo de red y, cuando esenúmero excede un determinado valor, se aplica el retardo más largo; de lo contrario, se aplica el retardomás breve. El sistema utiliza los parámetros GeneralSlowdown, GetNextBoundary yGetNextSlowdown definidos en la tabla de base de datos snmpStack.accessParameters paradeterminar qué retardo se aplica. Para obtener más información sobre la tabla de base de datossnmpStack.accessParameters, consulte IBM Tivoli Network Manager IP Edition Administration Guide.

Activación de la regulación del ayudante de SNMPPuede activar la regulación de ayudante de SNMP.

Acerca de esta tareaPara activar la regulación del ayudante de SNMP, siga estos pasos:

Procedimiento1. Edite el siguiente archivo de configuración: NCHOME/etc/precision/NcPollerSchema.cfg.

Nota: Puede hacer el dominio del archivo NcPollerSchema.cfg específico copiándolo a NCHOME/etc/precision/NcPollerSchema.DOMAIN_NAME.cfg, donde DOMAIN_NAME es el nombre deldominio.

2. Añada la línea siguiente al final del archivo:

update config.properties set EnableThrottling = 1;

3. Guarde el archivo NCHOME/etc/precision/NcPollerSchema.cfg.4. Active los cambios realizando una o ambas de las acciones siguientes:

• Iniciar o planificar un nuevo descubrimiento completo. El descubrimiento utilizará ahora laregulación.

• Reiniciar el Motor de sondeo, ncp_poller, con la opción de línea de comandos -readsnmpconfigespecificada.

Configuración del soporte de GetBulk para SNMP v2 y v3Puede configurar el Ayudante de SNMP para utilizar la operación GetBulk cuando se utiliza SNMP v2 o v3.El uso de la operación GetBulk mejora la eficiencia del sondeo y la velocidad del descubrimiento. Deforma predeterminada, el ayudante de SNMP no utiliza GetBulk.

Acerca de GetBulkEl mandato SNMP v2 y SNMP v3 GetBulk permite una transferencia de datos más eficiente. Cuando elAyudante de SNMP está habilitado para utilizar GetBulk, ello reducirá el tiempo que lleva las fases derecopilación de datos de descubrimiento. La utilización de GetBulk también aumenta la eficiencia delsondeo.

La configuración del Ayudante de SNMP para utilizar GetBulk reduce la cantidad de recursos de NetworkManager de las siguientes formas:

• Reduce el impacto en la gestión de red debido a un menor intercambio de paquetes SNMP.• Reduce el impacto en dispositivos gestionados debido a un menor proceso de paquetes SNMP.


• Reduce el tiempo de CPU requerido por los procesos de Network Managercomo el motor dedescubrimiento, ncp_disco y el motor de sondeo, ncp_poller, debido a sobrecargas reducidas.

El uso de GetBulk reduce el tiempo que llevan las fases de recopilación de datos de descubrimiento, yaque un gran porcentaje del tiempo necesario para la recopilación de datos se utiliza esperando paquetespara atravesar la red. Ello reduce significativamente el tiempo que lleva la recopilación de datos paratablas grandes, como las tablas de direccionamiento o de interfaz.

Configuración de Network Manager para utilizar GetBulkPuede configurar el Ayudante de SNMP para utilizar GetBulk. También puede excluir dispositivosespecíficos desde el soporte de GetBulk.

Acerca de esta tareaSi configura el Ayudante de SNMP para utilizar GetBulk, esto se aplicará a todos los sondeadores deldominio actual. El Ayudante de SNMP también utilizará GetBulk para todos los dispositivos del dominio alos que se acceda utilizando SNMP v2 o SNMP v3, a menos que excluya dispositivos específicos como sedescribe en los pasos siguientes.

Nota: Cuando GetBulk esté habilitado, para cada dispositivo habilitado para GetBulk, se enviará siempreuna solicitud de GetBulk en lugar de una solicitud de GetNext.

Para configurar el Ayudante de SNMP para utilizar GetBulk, realice los pasos siguientes:

Procedimiento1. Edite el siguiente archivo de configuración: NCHOME/etc/precision/NcPollerSchema.cfg.

Nota: Puede hacer el dominio del archivo NcPollerSchema.cfg específico copiándolo a NCHOME/etc/precision/NcPollerSchema.DOMAIN_NAME.cfg, donde DOMAIN_NAME es el nombre deldominio.

2. Busque la inserción en la base de datos de config.properties y establezca el valor para lapropiedad UseGetBulk en 1.

3. Guarde el archivo NCHOME/etc/precision/NcPollerSchema.cfg.4. Opcional: Si tiene dispositivos de red que no soporten GetBulk, puede excluir estos dispositivos de red

en una base de dispositivo por dispositivo realizando los pasos siguientes:a) Edite el archivo de configuración siguiente: NCHOME/etc/precision/SnmpStackSecurityInfo.cfg.

Nota: Puede hacer el dominio del archivo SnmpStackSecurityInfo.cfg específico copiándolo aNCHOME/etc/precision/SnmpStackSecurityInfo.DOMAIN_NAME.cfg, dondeDOMAIN_NAME es el nombre del dominio.

b) Para cada dispositivo que desee excluir del soporte de GetBulk, agregue una inserción en el archivode configuración de SnmpStackSecurityInfo.cfg, similar al ejemplo siguiente:La siguiente inserción de ejemplo excluye el dispositivo 10.0.13.74 del soporte de GetBulk.

insert into snmpStack.accessParameters ( m_NetAddress, m_UseGetBulk )values ( '10.0.13.74', 0 );

c) Una vez que haya agregado inserciones para cada uno de los dispositivos a excluir, guarde elarchivo NCHOME/etc/precision/ SnmpStackSecurityInfo.cfg.

5. Active los cambios realizando una o ambas de las acciones siguientes:

• Iniciar o planificar un nuevo descubrimiento completo. El descubrimiento hará ahora uso de GetBulk.• Reiniciar el Motor de sondeo, ncp_poller, con la opción de línea de comandos -readsnmpconfigespecificada.


Configuración del número máximo de repeticiones para solicitudes deGetBulkEl mandato GetBulk se utiliza para recuperar todas las filas de una tabla desde un recurso de red como,por ejemplo, para recuperar todas las filas en una tabla de direccionamiento desde un direccionador. Elparámetro max-repetitions indica cuántas filas de la tabla se recuperarán en una única operación deGetBulk. Puede ajustar los valores de configuración de GetBulk para minimizar el número de paquetesintercambiados como parte de la operación de GetBulk.


El Ayudante de SNMP determina el valor del número máximo de repeticiones para solicitudes de GetBulk(el parámetro max-repetitions) según el siguiente cálculo:

max-repetitions = DefaultGetBulkMaxReps / #varbinds

Donde:

• La propiedad DefaultGetBulkMaxReps se define en el archivo $NCHOME/etc/precision/NcPollerSchema.cfg. El valor predeterminado es 20. Esta propiedad define el número asignado alcampo max-repetitions en solicitudes GetBulk emitidas por procesos de Network Manager. El valor20 se utiliza cuando la solicitud GetBulk contiene un único varbind. Si están incluidos varios varbinds, elvalor se ajusta de forma acorde (dividido por el número de varbinds), por lo que las respuestas siemprecontienen un número similar de varbinds.

• #varbinds es el número de enlaces variables que se solicitan. En el Ayudante de SNMP, este valor esnormalmente 1. Sin embargo, el valor puede variar en función de dónde se despliegue el Ayudante deSNMP y de los siguientes factores:

– En el Motor de descubrimiento, ncp_disco, el valor #varbinds puede variar según el código en elagente de descubrimiento.

– En el Motor de sondeo, ncp_poller, el valor #varbinds puede variar según qué objetos de MIB esténincluidos en la definición de sondeo.

Procedimiento1. Edite el siguiente archivo de configuración: $NCHOME/etc/precision/NcPollerSchema.cfg.

Nota: Puede hacer el dominio del archivo NcPollerSchema.cfg específico copiándolo a $NCHOME/etc/precision/NcPollerSchema.DOMAIN_NAME.cfg, donde DOMAIN_NAME es el nombre deldominio.

2. Busque la línea que define el valor de la propiedad DefaultGetBulkMaxReps.

3. Cambie la asignación del valor para la propiedad DefaultGetBulkMaxReps.4. Guarde el archivo $NCHOME/etc/precision/NcPollerSchema.cfg.5. Reinicie el Motor de sondeo, ncp_poller, para activar los cambios de configuración.

Configuración de la autenticaciónPuede configurar los distintos componentes de Network Manager para utilizar distintos métodos deautenticación.

Acerca de esta tareaPara obtener más información sobre el inicio de sesión único, consulte Configuración de Jazz for ServiceManagement for SSO en el Jazz for Service Management IBM Knowledge Center en https://www.ibm.com/support/knowledgecenter/SSEKCU.




Cambio del método de autenticación de usuarioAl instalar Network Manager puede elegir autenticar a los usuarios de Network Manager en un sistema deautenticación basado en archivos o en Tivoli Netcool/OMNIbus ObjectServer.

Acerca de esta tareaSi desea cambiar el método de autenticación después de la instalación, por ejemplo para utilizar LDAP,siga las mismas instrucciones que para cambiar el método de autenticación para Tivoli Netcool/OMNIbus.Consulte la información sobre Configuración de autenticación de usuario Consulte el tema Configuraciónde la autenticación de usuario de la publicación IBM Tivoli Netcool/OMNIbus Installation and DeploymentGuide.

Configuración de la autenticación del Proveedor de servicios de OQLLas consultas en las bases de datos del componente Network Manager se pueden ejecutar desde la líneade mandatos utilizando el proceso del Proveedor de servicios de OQL, ncp_oql. Puede configurar ncp_oqlpara autenticar en la base de datos de NCIM o en el ObjectServer de Tivoli Netcool/OMNIbus.Alternativamente, puede configurar ncp_oql para permitir que las consultas se ejecuten sin necesidad deautenticación.

Acerca de esta tareaEl motor de autenticación del Proveedor de servicios de OQL, ncp_auth, no se sigue utilizando en NetworkManager versión V3.9 y posteriores. De forma predeterminada, no hay autenticación para consultas dencp_oql desde la línea de comandos. Puede configurar el Proveedor de servicios de OQL para autenticaren la base de datos de NCIM o en el ObjectServer, como sigue:

• Autenticación en la base de datos de NCIM: fuerza al Proveedor de servicios de OQL a autenticarutilizando el nombre de usuario y la contraseña de la base de datos de NCIM, como se especificó en elmomento de la instalación y se configuró en el archivo de configuración DbLogins.cfg.

• Autenticación en el ObjectServer: fuerza al Proveedor de servicios de OQL a autenticarse utilizando lacontraseña y el nombre de la cuenta del administrador de Tivoli Netcool/OMNIbus, como se especificóen el momento de la instalación.

La autenticación del Proveedor de servicios de OQL se controla mediante el valor dem_OQLAuthenticationMode dentro de la tabla config.settings. El campo toma los valores siguientes:

• 0: Sin autenticación. El nombre de usuario y la contraseña no son necesarios y, si se especifican en lalínea de mandatos, se ignoran.

• 1: Autenticación en la base de datos de NCIM.• 2: Autenticación en el Tivoli Netcool/OMNIbus ObjectServer.

Para configurar la autenticación del Proveedor de servicios de OQL:

Procedimiento1. Edite el archivo de configuración ncp_config, $NCHOME/etc/precision/ConfigSchema.cfg.2. Configure una de las siguientes inserciones en la tabla config.settings:

• Configure la autenticación en la base de datos de NCIM.

insert into config.settings( m_OQLAuthenticationMode,)values( 1,);

• Configure la autenticación en el ObjectServer.


insert into config.settings( m_OQLAuthenticationMode,)values( 2,);

IBM Support Assistant (ISA)IBM Support Assistant es una herramienta que ayuda a buscar y encontrar soporte e información deformación de productos.

Si necesita abrirse un PMR (Problem Management Record), IBM Support Assistant puede ahorrar tiemporecopilando automáticamente información de soporte. IBM Support Assistant proporciona los serviciossiguientes:

• Acceso mejorado a información de soporte de IBM, grupos de noticias de IBM y otros recursosmediante una interfaz de búsqueda federada (una búsqueda en varios recursos)

• Fácil acceso a materiales educativos y hojas de ruta de educación de productos de IBM• Fácil acceso a páginas de inicio de productos, páginas de soporte de productos y foros de productos o

grupos de noticias de IBM mediante enlaces convenientes• Tiempo de PMR mejorado en resolución recopilando información de sistema clave y enviando los datos

a IBM mediante la creación electrónica de un PMR

Un conector de Network Manager está disponible para el IBM Support Assistant. IBM Support Assistantnecesita el conector para poder diagnosticar problemas de Network Manager.

Para obtener más información acerca de IBM Support Assistant, consulte el siguiente sitio web de IBM:https://www.ibm.com/support/knowledgecenter/SSLLVC/welcome/isa_welcome.html

Instalación del recopilador de IBM Support Assistant LiteEl recopilador de IBM Support Assistant (ISA) Lite para Network Manager recopilación de datosautomatizada en los sistemas en los que está instalado Network Manager. Puede recopilar informaciónsobre registros, archivos de reglas, datos de configuración, etc.

Acerca de esta tareaPara instalar el recopilador de ISA Lite, realice los siguientes pasos:

Procedimiento1. Instale Network Manager.2. Abra la nota técnica siguiente: http://www.ibm.com/support/docview.wss?uid=swg270158673. Siga los pasos en la nota técnica para configurar y utilizar el recopilador de ISA Lite para Network

Manager.


https://www.ibm.com/support/knowledgecenter/SSLLVC/welcome/isa_welcome.html


Avisos

Esta información se aplica al conjunto de documentación en PDF para IBM Tivoli Network Manager IPEdition.

Esta información se ha desarrollado para productos y servicios ofrecidos en Estados Unidos.

IBM puede no ofrecer los productos, servicios o características tratados en esta documentación en otrospaíses. Consulte con el representante local de IBM para obtener información acerca de los productos yservicios que actualmente están disponibles en su localidad. Las referencias hechas a productos,programas o servicios de IBM no pretenden afirmar ni dar a entender que únicamente puedan utilizarsedichos productos, programas o servicios de IBM. Puede utilizarse en su lugar cualquier otro producto,programa o servicio funcionalmente equivalente que no vulnere ninguno de los derechos de propiedadintelectual de IBM. Sin embargo, es responsabilidad del cliente evaluar y verificar el funcionamiento decualquier producto, programa o servicio que no sea de IBM.

IBM puede tener patentes o solicitudes de patente pendientes de aprobación que cubran alguno de lostemas tratados en esta documentación. La entrega de este documento no le otorga ninguna licencia sobredichas patentes. Puede enviar sus consultas sobre licencias por escrito a:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785Estados Unidos

Para consultas sobre licencias en las que se solicite información sobre el juego de caracteres de doblebyte (DBCS), póngase en contacto con el departamento de Propiedad intelectual de IBM de su país oenvíe las consultas, por escrito, a:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan, Ltd.19-21, Nihonbashi-Hakozakicho, Chuo-kuTokyo 103-8510, Japón

El párrafo siguiente no se aplica al Reino Unido ni a ningún otro país donde estas disposiciones seanincompatibles con la legislación vigente: INTERNATIONAL BUSINESS MACHINES CORPORATIONPROPORCIONA ESTA PUBLICACIÓN "TAL CUAL", SIN GARANTÍAS DE NINGUNA CLASE, NI EXPLÍCITASNI IMPLÍCITAS, INCLUYENDO, PERO SIN LIMITARSE A, LAS GARANTÍAS IMPLÍCITAS DE NOINFRACCIÓN, COMERCIALIZACIÓN O ADECUACIÓN A UN PROPÓSITO DETERMINADO. Algunos paísesno permiten la renuncia a garantías explícitas o implícitas en determinadas transacciones, por lo quepuede que esta declaración no sea aplicable en su caso.

Esta información puede incluir imprecisiones técnicas o errores tipográficos. Periódicamente se efectúancambios en la información aquí contenida; estos cambios se incorporarán en nuevas ediciones de lapublicación. En cualquier momento y sin previo aviso, IBM puede hacer mejoras y/o cambios en losproductos y/o programas descritos en esta publicación.

Cualquier referencia incluida en esta información a sitios web que no sean de IBM sólo se proporcionapara su comodidad y en ningún modo constituye una aprobación de dichos sitios web. Los materiales deestos sitios Web no forman parte de los materiales destinados a este producto de IBM, y el usuario seráresponsable del uso que se haga de estos sitios Web.

IBM puede utilizar o distribuir cualquier información que se le proporcione en la forma que considereadecuada, sin incurrir en ninguna obligación para con el remitente.


Los titulares de licencias de este programa que deseen obtener información sobre el mismo con el fin depermitir: (i) el intercambio de información entre programas creados independientemente y otrosprogramas (incluido éste) y (ii) el uso mutuo de la información intercambiada, deberían ponerse encontacto con:

IBM Corporation958/NH04IBM Centre, St Leonards601 Pacific HwySt Leonards, NSW, 2069Australia

IBM Corporation896471/H128B76 Upper GroundLondresSE1 9PZReino Unido

IBM CorporationJBF1/SOM1 294Route 100Somers, NY, 10589-0100Estados Unidos de América

Dicha información puede estar disponible, sujeta a los términos y condiciones correspondientes, incluido,en algunos casos, el pago de una tarifa.

IBM proporciona el programa bajo licencia descrito en esta documentación, así como todo el materialbajo licencia disponible, según los términos del Acuerdo de Cliente de IBM, del Acuerdo Internacional deProgramas bajo Licencia de IBM o cualquier acuerdo equivalente entre nosotros.

Los datos de rendimiento incluidos aquí se determinaron en un entorno controlado. Por lo tanto, losresultados que se obtengan en otros entornos operativos pueden variar significativamente. Puedenhaberse realizado algunas mediciones en sistemas a nivel de desarrollo y no existe ninguna garantía deque estas mediciones vayan a ser equivalentes en sistemas disponibles generalmente. Además, esposible que algunas mediciones se hayan estimado mediante extrapolación. Los resultados realespueden variar. Los usuarios de este documento deben verificar los datos aplicables a su entornoespecífico.

La información concerniente a productos no IBM se ha obtenido de los proveedores de dichos productos,de sus anuncios publicados o de otras fuentes de información pública disponibles. IBM no hacomprobado dichos productos y no puede afirmar la exactitud en cuanto a rendimiento, compatibilidad uotras características relativas a productos no IBM. Las consultas acerca de las posibilidades de losproductos no IBM deben dirigirse a los proveedores de los mismos.

Este documento contiene ejemplos de datos e informes que se utilizan diariamente en la actividad de laempresa. Para que parezcan verídicos, los ejemplos incluyen nombres de personas, compañías, marcas yproductos. Todos los nombres son ficticios y cualquier parecido con nombres y direcciones utilizados poruna empresa real son simple coincidencia.

LICENCIA DE COPYRIGHT:

Esta información contiene programas de aplicación de ejemplo en el lenguaje de origen, que muestrantécnicas de programación en diversas plataformas operativas. Puede copiar, modificar y distribuir estosprogramas de ejemplo en cualquier formato sin abonar ninguna cantidad a IBM, con intención dedesarrollar, utilizar, comercializar o distribuir programas de aplicación que estén en conformidad con lainterfaz de programación de aplicación de la plataforma operativa para la que están escritos losprogramas de ejemplo. Los ejemplos no se han probado minuciosamente bajo todas las condiciones. Por

226 Avisos

lo tanto, IBM no puede garantizar ni dar por sentada la fiabilidad, la facilidad de mantenimiento ni elfuncionamiento de los programas.

Marcas registradasLos términos de la Tabla 17 en la página 227 son marcas registradas de International Business MachinesCorporation en Estados Unidos y/o en otros países:

Tabla 17. Marcas registradas de IBM

AIX Informix PR/SM

BNT iSeries System p

ClearQuest Jazz System z

Cognos Lotus Tivoli

Db2 Netcool WebSphere

Db2 Universal Database NetView z/OS

developerWorks OMEGAMON z/VM

DS8000 Passport Advantage zSeries

Servidor dealmacenamientoempresarial

PowerPC

IBM PowerVM

Adobe, Acrobat, Portable Document Format (PDF), PostScript y todas las marcas registradas de Adobeson marcas registradas de Adobe Systems Incorporated en los Estados Unidos y/o en otros países.

Intel, logotipo de Intel, Intel Inside, logotipo de Intel Inside, Intel Centrino, logotipo de Intel Centrino,Celeron, Intel Xeon, Intel SpeedStep, Itanium y Pentium son marcas registradas de Intel Corporation o desus filiales en Estados Unidos y en otros países.

Java y todas las marcas registradas y logotipos basados en Java son marcas registradas de Oracle y/o desus filiales.

Linux es una marca registrada de Linus Torvalds en Estados Unidos y/o en otros países.

UNIX es una marca comercial registrada de The Open Group en los Estados Unidos y otros países.

Microsoft, Windows, Windows NT y el logotipo de Windows son marcas registradas de MicrosoftCorporation en Estados Unidos y/o en otros países.

Consideraciones sobre política de privacidadLos productos de IBM Software, incluidas las soluciones de software como servicio, ("Software Offerings")pueden utilizar cookies u otras tecnologías para recopilar información de uso del producto, para ayudar amejorar la experiencia del usuario final, para adaptar las interacciones con el usuario final o para otrosfines. En muchos casos, las ofertas de software no recopilan información de identificación personal.Algunas Ofertas de software pueden ayudarle a recopilar información identificable personalmente. Si estaoferta de software utiliza cookies para recopilar información de identificación personal, la informaciónespecífica sobre el uso de cookies de esta oferta se expone a continuación.

Esta oferta de software puede recopilar direcciones IP, nombres de usuario y contraseñas con el objetivode ejecutar el descubrimiento de red. Si no habilita la recopilación de esta información, probablemente seeliminarán funciones importantes proporcionadas por la oferta de software. Como cliente, debe buscarasesoría legal sobre la legislación aplicable a este tipo de recopilación de datos, incluidos los requisitosde avisos y consentimiento.

Avisos 227

Para obtener más información sobre el uso de distintas tecnologías, incluidas las cookies, a estos efectos,consulte la política de privacidad de IBM en http://www.ibm.com/privacy y la declaración Online PrivacyStatement de IBM en http://www.ibm.com/privacy/details, y las secciones tituladas "Cookies, WebBeacons and Other Technologies" y "IBM Software Products and Software-as-a-Service PrivacyStatement" en http://www.ibm.com/privacy.


http://www.ibm.com/privacy

http://www.ibm.com/privacy/details

http://www.ibm.com/privacy

IBM®

Número Pieza:

Printed in the Republic of Ireland

2021-4212-01

(1P) P

/N:

Versión 4 Release 2 Network Manager IP Edition - IBM...Versión 4 Release 2 Guía de configuración...

Documents

Transcript of Versión 4 Release 2 Network Manager IP Edition - IBM...Versión 4 Release 2 Guía de configuración...