Consideraciones sobre CA Service Desk Manager

Para una correcta implementación de CA Service Desk Manager (CA SDM) en el entorno, consulte los temas siguientes antes de iniciar la instalación:
casm173
Revise los siguientes temas para implementar CA Service Desk Manager (CA SDM):
Al planificar la implementación de CA SDM desde una perspectiva de escalabilidad, asegúrese de que se cumpla el límite superior de 64 procesos en el servidor principal. Si el número de procesos en un servidor principal es superior a 64, es posible que se produzcan procesos adicionales en un servidor secundario de CA SDM. La instalación de CA SDM puede tener un máximo de 40 procesos en un único servidor. Tenga en cuenta que la adición de un nuevo domserver de motor web al entorno existente da lugar a la adición de 3 procesos más.
Asegúrese de reiniciar los servicios de la interfaz de xFlow cada vez que se reinicien los servicios de CA SDM. Esto es aplicable para un entorno en el que se instala CA SDM y la interfaz de xFlow.
Servidor de búsqueda
Se recomienda dedicar un servidor para instalar el servidor de búsqueda. El servidor de búsqueda incluye una función de agrupamiento en clústeres integrada y se puede instalar en una configuración independiente. Para configuraciones más grandes se recomienda instalar el servidor de búsqueda en tres o más servidores y configurarlo manualmente en un clúster que admita fallos.
Información del usuario predeterminado
La tabla siguiente muestra la información relativa a los usuarios predeterminados para una implementación típica de CA SDM:
SO
Usuario
Nombre de usuario predeterminado
Nivel de SO
Modo de creación
Windows
CA SDM
ServiceDesk
Automáticamente
CA EEM
EiamAdmin
No
Se crea durante la configuración de CA EEM.
Microsoft SQL Server
mdbadmin
No
Se crea en Microsoft SQL Server durante la configuración.
Oracle
mdbadmin
No
Se crea en la base de datos Oracle durante la configuración.
Usuario admin de
CA Service Management
CASMAdmin
No
Se crea manualmente.
Oracle
mdbadmin
No
Se crea en MDB durante la configuración.
Usuario admin de
CA Service Management
CASMAdmin
No
Se crea manualmente.
Linux
CA SDM
srvcdesk
Se crea manualmente.
Oracle
mdbadmin
No
Se crea en la base de datos durante la configuración.
Usuario admin de
CA Service Management
CASMAdmin
No
Se crea manualmente.
Política de contraseñas
La autenticación del usuario no funciona si el sistema está utilizando archivos Shadow y hay el signo
x
en el campo de contraseña del archivo /etc/passwd. Los usuarios no pueden iniciar sesión en CA SDM. La contraseña especificada para el usuario con privilegios de CA SDM debe cumplir con la política de contraseñas impuesta por el dominio de red. Si la contraseña cumple la política, solo funcionará la configuración de CA SDM.
Componentes compartidos
  • Al instalar CA SDM, no se deben instalar los componentes compartidos de CA en el mismo directorio que el directorio de instalación de CA SDM (
    NX_ROOT
    ).
  • Las referencias a NX_ROOT se relacionan con la variable de entorno que contiene la ruta de instalación de CA SDM. La variable NX_ROOT se configura en el archivo de configuración
    NX.env
    , que se utiliza para configurar variables de entorno de CA SDM.
    Ejemplo:
    Definición de NX_ROOT @NX_ROOT=C:\Archivos de programa (x86)\CA\Service Desk Manager
  • No especifique espacios en el nombre de la carpeta ni de la ruta de los medios de instalación para evitar un error de instalación.
Gestor de opciones
Si se instala CA Service Desk Manager por primera vez, la opción web
copy_inactive
del Gestor de opciones no se instalará de forma predeterminada. No se copian los vínculos a los objetos inactivos. Considere la información siguiente cuando no se instala la opción
copy_inactive
:
  • CA SDM copia las SREL que hacen referencia a los objetos inactivos cuando se requiera SREL.
    Por ejemplo, la organización org1 tiene una ubicación inactiva. Cuando se copia org1, la nueva organización no tiene ninguna ubicación. Sin embargo, si se requiere SREL, CA SDM ignora esta regla y copia la ubicación. Por ejemplo, cuando CA SDM ignora la regla, el usuario puede copiar un elemento de configuración con una clase inactiva.
  • CA SDM no copia relaciones LREL (muchos a muchos) en objetos inactivos. Por ejemplo, el elemento de configuración denominado
    CITest1
    tiene una relación con la organización inactiva org2. Cuando se copia
    CITest1
    , org2 no se vincula al nuevo elemento de configuración.
  • Estas reglas también se aplican cuando se copia un ticket, aunque se cree un ticket desde una plantilla. Aunque se haya instalado copy_inactive, la excepción a esta regla está dirigida a las áreas y categorías inactivas, las cuales ni se copian de tickets existentes ni se rellenan desde plantillas.
Consideraciones de la base de datos
  • Si se ha configurado CA SDM con una base de datos y, a continuación, la configuración se ejecuta una segunda vez y se selecciona otro tipo de base de datos, la configuración no funcionará. Por ejemplo, se ha configurado primero Microsoft SQL Server y, a continuación, se ha vuelto a configurar una base de datos de Oracle. La solución temporal consiste en reiniciar el equipo antes de ejecutar la segunda configuración.
  • La información sobre la conexión de la base de datos, si es diferente, no se acepta en configuraciones posteriores. Si se necesita realizar una configuración más a raíz de un cambio efectuado en la información sobre la conexión de la base de datos, suprima el archivo $NX_ROOT\NX.env antes de continuar.
  • Para configurar una base de datos de Oracle 11g de 64 bits en un equipo de 64 bits, también se debe instalar el cliente de 32 bits de Oracle en el servidor. Cuando se configura la base de datos, la ruta de la biblioteca del sistema debe señalar a las bibliotecas de Oracle de 32 bits. Este paso es necesario tanto para la configuración como para el tiempo de ejecución. Asimismo, se puede crear un nombre de servicio de red en el cliente de Oracle para señalar a la instancia del servidor de base de datos de Oracle.
  • Supongamos que se está utilizando una base de datos de Oracle y se desea utilizar los espacios de tabla existentes. Se debe crear un espacio de tabla de datos que tenga al menos 400 MB y un espacio de tabla de índice de al menos 100 MB antes de configurar CA SDM.
  • Se deben establecer las variables de entorno de Oracle antes de instalar o migrar a CA SDM. Para ello, realice las acciones siguientes:
    • Verifique que la variable ORACLE_HOME esté configurada correctamente. Se debe exportar la variable TWO_TASK cuando se exportan las del cliente de Oracle de 32 bits en plataformas que no son Windows.
    • Incluya las bibliotecas de Oracle de 32 bits (normalmente $ORACLE_HOME/lib32 para Oracle de 64 bits) en la variable de la ruta de la biblioteca LD_LIBRARY_PATH.
Consideraciones de los servidores web
  • Tomcat se establece como el servidor web predeterminado de CA SDM durante la instalación del producto. También se pueden utilizar los siguientes servidores web en función de sus necesidades:
    • Internet Information Services (IIS)
      Aplicable solo en Windows. Si desea utilizar IIS como servidor web de CA SDM, se debe configurar IIS antes de instalar CA SDM. Para obtener más información sobre cómo configurar IIS, consulte Configuración de IIS.
    • Apache
      Solo aplicable en Linux y Solaris. Si se desea utilizar Apache como servidor web de CA SDM, se debe configurar Apache antes de instalar CA SDM.
  • Si se configura Tomcat con la autenticación externa en el servidor principal, se deberá configurar un servidor secundario con un motor web y un daemon del repositorio. Esta configuración permite a los usuarios que no se han autenticado utilizar los archivos adjuntos. La instalación de Tomcat en el servidor secundario no puede utilizar la autenticación externa.
  • La instalación de CA SDM utiliza el puerto de Tomcat
    8080
    . Otros productos de CA, tales como CA Asset Portfolio Management o el conjunto de productos Service Delivery, también utilizan el puerto de Tomcat 8080. Si se están instalando varios productos de CA en el mismo servidor, seleccione un número de puerto que no sea el 8080 para las siguientes instalaciones de productos de CA. La selección de un número de puerto diferente ayuda a los productos a funcionar juntos correctamente. Para cambiar el número del puerto de Tomcat a un valor distinto de 8080 para CA SDM, se debe instalar el producto, y si ya está instalado, se debe volver a ejecutar la configuración del producto y especificar un número de puerto disponible para Tomcat cuando se solicite.
  • Después de reiniciar CA SDM, es posible que el proceso de Tomcat de CA SDM no se inicie adecuadamente. Para iniciar Tomcat correctamente, detenga y reinicie Tomcat mediante los siguientes comandos:
    pdm_tomcat_nxd -c STOP
    pdm_tomcat_nxd -c START
Configuración de Internet Information Services (IIS)
Siga estos pasos:
  1. Inicie
    Administrador del servidor
    en el servidor instalado de IIS.
    Se abre la pantalla
    Cuadro de mandos
    del Administrador del servidor.
  2. Vaya a
    Servidor local
    y a la sección
    ROLES Y CARACTERÍSTICAS
    .
  3. Seleccione la opción
    Agregar roles y características
    de la lista desplegable
    TAREAS
    .
    Se abrirá el asistente para agregar roles y funciones.
  4. Haga clic en
    Siguiente
    en la pantalla
    Antes de comenzar
    .
    Aparece la pantalla Seleccionar tipo de instalación.
  5. Seleccione el botón de opción
    Instalación basada en características o en roles
    y haga clic en Siguiente.
    Se abrirá la pantalla Select destination server (Seleccionar servidor de destino).
  6. Seleccione el botón de opción
    Seleccionar un servidor del grupo de servidores
    y asegúrese de que el servidor local aparezca en la sección Grupo de servidores. Haga clic en
    Siguiente
    .
  7. Aparecerá la pantalla
    Seleccionar roles de servidor
    .
  8. Seleccione
    SERVIDOR WEB (IIS)
    en la lista Roles.
    Se abre la ventana Add features that are required for Web Server (IIS)? (¿Desea agregar las funciones necesarias para el servidor web [IIS]?)
  9. Haga clic en
    Agregar características
    y, a continuación, haga clic en
    Siguiente
    .
    Aparecerá la página Seleccionar funciones.
  10. Seleccione las características de IIS adicionales según sea necesario y haga clic en
    Siguiente
    .
    Aparecerá la pantalla de rol del servidor web (IIS).
  11. Haga clic en
    Siguiente
    .
    Se abrirá la página Servicios de roles.
  12. Seleccione lo siguiente en
    Servicios de rol
    y haga clic en
    Siguiente
    . Opcionalmente, se pueden seleccionar los servicios de rol si es necesario.
    • Servidor web
    • Características HTTP comunes
    • Documento predeterminado
    • Exploración de directorios
    • Errores de HTTP
    • Contenido estático
    • Estado y Diagnósticos
    • Registro HTTP
    • Rendimiento
    • Compresión de contenido estático
    • Seguridad
    • Filtrado de solicitudes
    • Herramientas de gestión
    • Consola de gestión de IIS
    • Desarrollo de aplicaciones
    • CGI
    • Inclusiones del servidor
      Si se selecciona CGI, solo el explorador web iniciará CA Service Desk Manager. El explorador web intenta abrir el archivo PDMWEB.EXE.
    Aparecerá la pantalla de secciones Confirmar instalación.
  13. Revise las características y los roles seleccionados que deben instalarse y haga clic en
    Instalar
    .
  14. Haga clic en
    Cerrar
    cuando se haya completado la instalación.
  15. Inicie la
    Interfaz de la línea de comandos
    y ejecute el siguiente comando:
    pdm_configure
    Para ejecutar el comando pdm_configure, se debe tener acceso de usuario con privilegios o acceso raíz en el servidor de CA SDM.
Internacionalización
  • Caracteres multibyte:
    No se pueden utilizar caracteres multibyte para el usuario con el que se ha iniciado sesión o para el nombre de usuario con privilegios de CA SDM. Esto se aplica cuando se está llevando a cabo la instalación en sistemas operativos de varios bytes como, por ejemplo, chino simplificado y japonés. Las búsquedas de conocimiento que contienen caracteres de varios bytes de japonés solo funcionan correctamente con SQL Server cuando se instala SQL Server con la intercalación de Windows. Asegúrese de que se especifica la opción de intercalación para los datos durante la instalación de SQL Server.
    No especifique caracteres de varios bytes en los nombres de las rutas de archivos durante la instalación y configuración. De hacerlo, se produciría un fallo.
  • UTF-8:
    En las plataformas UNIX y Linux, CA SDM debe ejecutarse en una configuración regional UTF-8.
  • Intervalo de tiempo:
    Los nombres de los símbolos proporcionados con la instalación predeterminada de CA SDM (ficha
    Administración
    ,
    Service Desk
    ,
    Datos de la aplicación
    ,
    Códigos
    ,
    Intervalos de tiempo
    ) están en inglés. Por ejemplo, TODAY (HOY), YESTERDAY (AYER), THIS MONTH (ESTE MES)
    .
    Para las versiones localizadas del producto, los administradores pueden definir nuevos intervalos de tiempo localizados. No se deben suprimir ni modificar los intervalos de tiempo predeterminados.
  • Formatos de fecha:
    En CA SDM, no son compatibles con los especificadores internacionales como los especificadores de imagen-fecha localizados. Por ejemplo, "jj/MM/AAAA" para francés. La sintaxis se limita a los especificadores genéricos como "DD/MM/YYYY". No obstante, muchos de los patrones internacionales de fecha y hora cortos se pueden crear a partir de estos especificadores genéricos (por ejemplo, "YYYY.MM.DD" sería un formato de fecha corto válido para japonés).
    Es posible que los usuarios internacionales deseen ajustar la propiedad
    DateFormat
    del archivo
    web.cfg
    para poder utilizar la fecha y los formatos de fecha y hora.
  • Para las notificaciones salientes de correo electrónico de texto sin formato, es posible que se deban ajustar las opciones
    NX_SMTP_HEADER_CHARSET
    y
    NX_SMTP_BODY_CHARSET
    en el archivo NX.env. El ajuste de las opciones facilita el etiquetado correcto de los mensajes de correo electrónico con la codificación de caracteres utilizada por el entorno operativo internacional. Los valores predeterminados para estas opciones se configuran en UTF-8 en todas las plataformas.
  • Es posible que los usuarios internacionales deseen cambiar la configuración regional predeterminada para el léxico de la revisión ortográfica a otra configuración regional. Utilice la opción
    LEX_LANG
    del Gestor de opciones.
  • Nombres de archivo cortos:
    Si se han desactivado los nombres de archivo cortos en el sistema operativo Windows, se deben volver a activar antes de instalar CA SDM. Se deben establecer las variables de entorno
    TEMP
    y
    TMP
    en un nombre de archivo corto. Por ejemplo,
    c:\temp
    , después de activar los nombres de archivo cortos. Para obtener más información, consulte el artículo 121007 de Microsoft Knowledge Base.
  • Interfaz web e Internet Information Services (IIS):
    Para configurar la interfaz web con IIS 7.0 en Windows 2008, se deben instalar los componentes CGI y Compatibilidad con la metabase de IIS 7.0. Se pueden agregar estos componentes a través de la sección Roles de Server Manager después de instalar los módulos de IIS Management Compatibility.
  • Además, las versiones localizadas de CA SDM solo son compatibles con el correspondiente entorno operativo localizado de Windows Server. En todos estos casos, se debe configurar
    Idioma para programas no Unicode
    para que el sistema admita el idioma certificado objetivo. Este valor de configuración está disponible en la ventana
    Configuración regional y de idioma
    del Panel de control.
    Para obtener más información sobre las versiones localizadas de los sistemas operativos de Windows Server, consulte Global Development and Computing Portal de Microsoft.
Consideraciones sobre la Automatización de soporte
Puede utilizar la siguiente información para investigar y puede recopilar información para ayudarle a planificar una configuración de la automatización de soporte correcta.
  • Servidor y red
    • Servidor principal
      Automatización del soporte utiliza el servidor de aplicaciones principal. El servidor proporciona comunicaciones basadas en HTTP y en socket.
    • Servidor proxy de socket
      Automatización del soporte utiliza un proxy de socket en el mismo nivel que el servidor web. El servidor web que descarga el procesamiento de encriptación/desencriptación del servidor principal para conexiones de socket directas para ser compatible con la escalabilidad.
    • Servidor de enrutamiento de mensajes (MRS)
      Automatización de soporte segrega el ancho de banda alto y el tráfico imprevisible del servidor de aplicaciones principal. La segregación facilita la escalabilidad del servidor y proporciona un atajo para el enrutamiento de la red para la escalabilidad geográfica mediante conexiones de control remoto.
  • Tamaño del servidor
    • Características de red de las conexiones de analista y usuario final
      La carga del servidor es directamente proporcional a los datos del componente de enrutamiento de mensajes. La banda ancha baja, la latencia alta y la pérdida de paquetes alta contribuyen significativamente a bajar la carga en el servidor. Cuando las condiciones de red son óptimas (banda ancha alta, latencia baja, pérdida de paquetes baja), la velocidad del servidor es mucho más alta. El número total de usuarios analistas simultáneos e inicios de sesión de usuario final por minuto, incluyendo usuarios de autoservicio, puede poner una fuerte carga en el servidor.
    • Tipo de conexión
      El número de conexiones de socket en contraposición al número de conexiones HTTP afecta a los servidores de la siguiente manera:
      • Cuando se conecta predominantemente a través de conexiones de socket, la carga en los servidores es mínima. Si se supone que se cuenta con un hardware potente, la aplicación está ligada a la red más que a la CPU. El hardware no limita el número de conexiones simultáneas sino que la red puede limitar las conexiones.
      • Cuando se conecta mediante HTTP, la carga en los servidores de red y de aplicaciones es más alta y la aplicación se liga a la CPU a menos que se escale significativamente.
    • Uso de CA Remote Control
      CA Remote Control utiliza un ancho de banda de red significativo y constante siempre que está en ejecución. Todo el tráfico enviado entre usuarios finales y analistas fluye por el servidor. El número de conexiones de Remote Control simultáneas tiene un rol significativo en todas las evaluaciones de tamaño.
      CA Remote Control es la única herramienta de ancho de banda alto en el conjunto de herramientas Asistencia en vivo. La conversación y la automatización son de banda ancha baja. La captura de pantalla y la transferencia de archivos pueden usar banda ancha alta durante períodos breves mientras se transfieren archivos.
  • Red y ancho de banda
    La cantidad de ancho de banda que consume un sistema depende de las herramientas que se empleen.
    • Para las opciones Conversación y Automatización, el ancho de banda necesario es pequeño. Un módem de acceso telefónico de 56 kbps o menos es adecuado para soportar estas funciones.
    • Para la función
      Control remoto
      , se requiere más ancho de banda. Sin embargo, Remote Control de Asistencia en vivo se adapta automáticamente a entornos de banda ancha baja reduciendo la calidad de imagen y la velocidad de regeneración de la sesión de Remote Control.
    • La cantidad de ancho de banda también depende del modelo de conexión empleado. Hay dos modelos de conexión disponibles:
      • Conectividad HTTP: Se debe utilizar HTTP cuando el sistema está detrás de un cortafuegos restrictivo que solamente permite conexiones HTTP con el servidor.
      • Socket SSL directo: Se debe utilizar cuando se establece una conexión con el servidor mediante una conexión en el puerto SSL
        443
        .
    El gráfico siguiente ilustra el ancho de banda requerido en función de las herramientas utilizadas:
    Herramientas/Banda ancha
    Conversación/Automatización
    Remote Control
    < 3 KBps (28,8 kbps de acceso telefónico)
    Muy rápido y sensible
    Lento
    < 5 KBps (< 56 kbps de acceso telefónico)
    Muy rápido y sensible
    Adecuado con degradación de imagen
    < 50 KBps (Cable/ADSL)
    Muy rápido y sensible
    Muy rápido y sensible
    < 100 KBps (LAN)
    Muy rápido y sensible
    Muy rápido y sensible
Componentes del servidor de CA SDM
CA SDM incluye componentes que funcionan juntos y que se ejecutan en diferentes servidores, en función de la configuración de CA SDM. Antes de empezar la implementación, revise la información básica sobre los componentes siguientes:
Nombre de los componentes del servidor de SDM
Descripción
Gestor de daemon (pdm_d_mgr)
Inicia los conjuntos de procesos tal y como se definen en el archivo de inicio, pdm_startup. De forma predeterminada, el gestor de daemon intenta iniciar un componente con errores hasta 10 veces. Para comprobar el estado de todos los componentes de CA SDM, utilice la utilidad
pdm_status
. La utilidad
pdm_d_refresh
indica al gestor de daemon que inicie un nuevo ciclo de 10 intentos para iniciar cualquier proceso marcado previamente como con errores.
El gestor de daemon se ejecuta en todos los servidores de CA SDM.
Distribuidor de mensajes (sslump_nxd)
Funciona como un sistema de transferencia de mensajes o bus común. Los componentes que deben comunicarse el uno con el otro primero se registran en el distribuidor de mensajes. Cuando un componente envía un mensaje, el distribuidor de mensajes entrega ese mensaje a los componentes que se registraron para recibir ese tipo de mensaje. Si dos componentes se comunican tanto que la transferencia de mensajes a través del distribuidor de mensajes resulta ineficaz, se crea un canal rápido entre ellos. Puede ver una lista de componentes registrados que utilizan la utilidad slstat.
El distribuidor de mensajes se ejecuta en los siguientes servidores, en función de la configuración de CA SDM:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Todos los servidores
Agente de base de datos (platform_agent)
Realiza consultas de Microsoft SQL Server en la base de datos. Los agentes de bases de datos siguen el esquema lógico de CA SDM y traducen el SQL de este nivel al SQL de la plataforma de la base de datos física.
El agente de base de datos detecta las consultas de error y desconexión momentánea, e intenta volver a establecer la conexión y comunicarse con la base de datos. Esta función está destinada solamente a cortes de poca duración, como un corte de red breve o una desconexión momentánea. No está destinada a interrupciones prolongadas, como el cierre de un servicio de la base de datos para su mantenimiento, entre otras. El agente solamente intenta establecer la conexión un determinado número de veces (el valor predeterminado es 3 veces) y únicamente durante un intervalo de tiempo de algunos minutos. Si la interrupción dura más de varios minutos, el agente deja de intentar establecer la conexión. CA SDM debe reciclarse una vez que la base de datos está disponible de nuevo.
El agente de base de datos se ejecuta en los siguientes servidores, en función de la configuración de CA SDM:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Todos los servidores
Base de datos virtual (bpvirtdb_srvr)
Habilita el funcionamiento de múltiples gestores de objetos. Todos los gestores de objetos que se ejecutan en servidores primarios o secundarios conectan a la base de datos virtual, que arbitra su acceso a los agentes de base de datos. Por ejemplo, al recuperar un nuevo intervalo de números de referencia de tickets, la base de datos virtual garantiza que solo un gestor de objetos a la vez tenga acceso a la tabla que contiene los números de referencia. La base de datos virtual también realiza el almacenamiento en memoria caché de la información de base de datos para los gestores de objetos.
La base de datos virtual se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Todos los servidores
Borrado definitivo y archivado continuo (arcpur_srvr)
Ejecuta las reglas de archivado y borrado definitivo según las ha configurado el administrador de CA SDM.
El borrado definitivo y el archivado continuo se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de fondo
Monitor de base de datos (dbmonitor_nxd)
Monitoriza los cambios en las tablas comunes de CA MDB; por ejemplo, ca_contact.
La monitorización de la base de datos se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de fondo
Mail Daemon (pdm_mail_nxd)
Envía notificaciones por correo electrónico salientes.
El Daemon de correo se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Todos los servidores
Mail Eater (pdm_maileater_nxd)
Acepta correos electrónicos entrantes para las actualizaciones y la creación de tickets.
El daemon del Receptor de correo se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de fondo
Gestor de notificaciones (bpnotify_nxd)
Gestiona las notificaciones en un entorno de Windows.
El Gestor de notificaciones se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de aplicaciones, servidor de fondo y servidor en espera
Spell Checker (lexagent_nxd)
Ejecuta las solicitudes de revisión de la ortografía de los usuarios. El corrector ortográfico se ejecuta en todos los servidores de CA SDM.
Text API Daemon (pdm_text_nxd)
Crea y actualiza los tickets de las interfaces externas, como la línea de comandos y el correo electrónico. El daemon de la API de texto se ejecuta en todos los servidores de CA SDM.
Evento temporizado (animator_nxd)
Ejecuta los tiempos de retraso de los eventos. Si una implementación tiene un gran número de tipos de servicio o contratos, el motor de Evento temporizado realiza un seguimiento de los eventos activos. Se debe dedicar el Gestor de objetos del servidor principal por completo al motor de Evento temporizado. Puede configurar otros gestores de objetos en los servidores primarios o secundarios para el acceso del producto según sea necesario.
El daemon de Evento temporizado se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de fondo
Tiempo hasta la infracción (ttv_nxd)
Calcula los tiempos de incumplimiento previstos para los tipos de servicios.
El daemon de Tiempo hasta el incumplimiento se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de fondo
Proctor Daemon (pdm_proctor_nxd)
(Solo Windows) Inicia y reinicia los componentes de CA SDM en los servidores principal y secundario según las instrucciones del Gestor de daemons. Cuando se instala un servidor secundario, el proceso
pdm_proctor_nxd
se instala como el servicio CA SDM Remote Daemon Proctor. Cuando el servidor principal se inicia, el gestor de daemon instruye al supervisor de daemon remoto que conecte con el distribuidor de mensajes. A continuación, Daemon Manager indica a Remote Daemon Proctor que inicie los componentes en el servidor secundario. Los conjuntos de procesos definen el proceso de inicio de los componentes en el archivo de inicio
pdm_startup
.
El daemon del supervisor se ejecuta en todos los servidores de CA SDM en la configuración de disponibilidad avanzada.
Gestor de objetos (domsrvr).
Actúa como el proceso del servidor de CA SDM. Cuando se instala un servidor primario, de forma predeterminada se instalan dos gestores de objetos: uno para las conexiones al producto, y otro dedicado a Web Screen Painter. Contar con varios gestores de objetos le ayuda a probar sus modificaciones sin que afecte al entorno de producción. Cuando se instala un servidor secundario, es posible configurar gestores de objetos adicionales.
Siempre debe haber un gestor de objetos predeterminado ejecutándose en el servidor primario para que clientes como el motor de eventos temporizados se puedan conectar a él.
El gestor de objetos también almacena en memoria caché distintos registros y tablas para clientes. Si se utiliza
pdm_userload
para manipular estos registros, también se puede utilizar la utilidad
pdm_cache_refresh
para hacer que el Gestor de objetos recupere los nuevos datos.
El gestor de objetos se ejecuta en todos los servidores de CA SDM en la configuración de disponibilidad avanzada.
Se han agregado los gestores de objetos dedicados para el daemon de tiempo y temperatura y para el daemon de recordatorio.
Motor de métodos (spel_srvr)
Ejecuta las macros, los eventos, el código SPEL y demás elementos para un gestor de objetos. Se recomienda ejecutar cada gestor de objetos con su propio motor de métodos.
El motor de métodos se ejecuta en todos los servidores de CA SDM.
Servidor de inicio de sesión (boplgin)
Gestiona sesiones de usuario autenticadas.
El Servidor de inicio de sesión se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Todos los servidores
Base de datos virtual LDAP.
Se conecta con un directorio LDAP.
El Motor de métodos se ejecuta los servidores siguientes:
  • Convencional:
    Servidor principal o servidor secundario
  • Disponibilidad avanzada:
    Servidor de fondo o servidor de aplicaciones
Daemon de búsqueda de gestión del conocimiento (bpebr_nxd)
Ejecuta búsquedas de base de conocimiento. Durante el inicio de CA SDM, el daemon
bpebr_nxd
almacena los datos de los documentos de conocimiento que proceden de la base de datos en su memoria caché. Con una base de documentos extensa, es posible que experimente problemas de recursos de memoria. El daemon
bpebr_nxd
presenta los siguientes requisitos de tamaño:
Búsqueda para la gestión del conocimiento
  • 100.000 documentos
  • Tamaño de memoria = 332.000 KB
El daemon de Gestión del conocimiento se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal o servidor secundario
  • Disponibilidad avanzada:
    Servidor de fondo
Daemon de la gestión del conocimiento/indexado de las palabras clave (bpeid_nxd)
Indexa la base de conocimiento.
El daemon del Indexado de palabras clave se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal o servidor secundario
  • Disponibilidad avanzada:
    Servidor de fondo
Daemon de clasificación de preguntas frecuentes de la gestión del conocimiento (bu_daemon)
bu_daemon se ejecuta en los servidores siguientes:
    • Convencional:
      Servidor principal o servidor secundario
    • Disponibilidad avanzada:
      Servidor de fondo
Daemon de Tarjeta de informes de conocimiento (krc_daemon)
Realiza los cálculos para la función Tarjeta de informe del conocimiento de Gestión del conocimiento. Esta función permite a los analistas y gestores obtener diferentes vistas en forma de matriz de sus contribuciones de conocimiento y proporcionar una evaluación sobre los documentos más efectivos. La información proporcionada puede utilizarse para mejorar los procesos de creación de documentos de conocimiento y proporcionar el mejor soporte posible a los clientes.
El daemon de Tarjeta de informe del conocimiento se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal o servidor secundario
  • Disponibilidad avanzada:
    Servidor de fondo
Daemon de la gestión del conocimiento (bpebr_nxd)
Gestiona la administración de bases de conocimiento y la lógica de gestión de conocimiento. También gestiona las notificaciones y el proceso de aprobación de documentos.
El daemon de la gestión del conocimiento se ejecuta en todos los servidores de CA SDM.
Repository Daemon (rep_daemon)
Gestiona los repositorios de archivos adjuntos de CA SDM y el daemon de búsqueda de palabras clave/gestión del conocimiento.
El Daemon del repositorio se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal o servidor secundario
  • Disponibilidad avanzada:
    Todos los servidores
Daemon de control de versiones (pdm_ver_nxd)
Sincroniza los archivos de esquema entre un servidor primario y uno secundario para asegurar que están utilizando el mismo esquema.
El Daemon de control de versiones se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de fondo
Servidor Web de Apache Tomcat (javaw)
Permite la implementación de ciertas funciones, independientemente de que Microsoft Internet Information Server (IIS) se utilice como el servidor web para acceder a CA SDM. Estas funciones incluyen Elementos de gráfica, Archivos adjuntos y Servicios web.
El servidor web de Apache Tomcat se puede administrar con el controlador de Apache Tomcat (
pdm_tomcat_nxd
).
El servidor web de Apache Tomcat se ejecuta en todos los servidores de CA SDM.
Motor Web (webengine)
Se conecta con exploradores web a través de un pdmweb cgi que se ejecuta en un servidor Microsoft Internet Information Server (IIS) o en un servidor web de Apache Tomcat. Debe haber al menos un motor web para Web Screen Painter en los siguientes servidores.
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de aplicaciones, servidor en espera y servidor de fondo
Este proceso garantiza que el diseñador de esquemas de Web Screen Painter pueda escribir los archivos de esquema. Los motores web son los verdaderos clientes de un gestor de objetos, que utiliza el explorador de web para acceder al producto. El motor web utiliza los formularios web cache.htmpl para los usuarios conectados. Se puede manipular la memoria caché mediante la utilidad
pdm_webcache
y se pueden visualizar las estadísticas de conexión mediante la utilidad
pdm_webstat
.
El motor web se ejecuta en todos los servidores de CA SDM.
Agente de RF (pdm_rfbroker_nxd)
(Solo aplicable a la configuración de disponibilidad avanzada). gestione los roles de los servidores y contrólelos mediante la configuración. Este daemon se ejecuta en todos los servidores de configuración de disponibilidad avanzada y realiza las siguientes tareas:
  • Adquiere información sobre los servidores de fondo y los servidores en espera.
  • Actualiza la información (como el ID de slump, el nombre del nodo o el tipo de servidor) en la clase del monitor de estado del servidor.
  • Recibe mensajes de retransmisión de los cambios producidos en el estado del servidor.
  • Active el modo de inactividad de las solicitudes. Registre mensajes
    SLUMP_NODE_GONE
    que se envían a objetos ServerStatusMonitor cuando el nodo que produce un fallo es el servidor de fondo.
Autenticación de usuarios de inicio de sesión (bopauth_nxd)
Este daemon lleva a cabo la validación de la cuenta del usuario del sistema operativo. Para asignar un usuario con un tipo de acceso, se realizan las búsquedas de registro de contacto mediante el campo Clave de inicio de sesión en el sistema.
Si su negocio proporciona CA SDM a otras empresas cliente, puede colocar el servidor de inicio de sesión en un servidor secundario de una sola ubicación cliente. A continuación se puede activar la autenticación externa en los tipos de acceso. El daemon se ejecuta en los siguientes servidores según la configuración de CA SDM:
  • Convencional:
    Servidor principal o servidor secundario (si está configurado)
  • Disponibilidad avanzada:
    Servidor de fondo o de aplicaciones (si está configurado)
Registrador de intervalos (pdm_intrvlog_nxd)
El daemon del registrador de intervalos recopila la información de depuración para depurar el sistema. Se ejecuta en todos los servidores de CA SDM.
Daemon de indicador clave de rendimiento QRY (kpi_qry_daemon)
Ejecuta consultas de SQL para actualizar los indicadores clave de rendimiento en la base de datos. El Daemon del indicador clave de rendimiento QRY se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de fondo
Daemon de indicador clave de rendimiento SYS (kpi_sys_daemon)
Daemon que recopila indicadores clave de rendimiento del tipo de sistema y escribe en la base de datos. El Daemon de indicador de clave de rendimiento SYS se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Todos los servidores
Confirmación de la base de datos (confirm_db)
Una utilidad para comprobar el acceso a la base de datos que se ejecuta en todos los servidores de CA SDM.
Diccionario de datos (ddictbuild)
Una utilidad para crear el diccionario de datos que se ejecuta en todos los servidores de CA SDM.
Establecer LogFile (pdm_logfile)
Una utilidad para mostrar o establecer los límites de tamaño del archivo de registro. El daemon
pdm_logfile
se ejecuta en todos los servidores de CA SDM.
Gestor de informes (pcrpt_nxd)
Una utilidad de generación de informes de los equipos que se ejecuta en todos los servidores de CA SDM.
Servidor RPC (rpc_srvr)
Utilizado para hacer llamadas del servicio web SOAP saliente que se ejecuta en todos los servidores de CA SDM.
Tomcat de CA SA (sa_tomcat)
Tomcat de CA SA para ejecutar la automatización de soporte y se puede configurar en cualquier servidor de CA SDM.
Visualizador de Tomcat (viz_tomcat)
La instancia de Tomcat para ejecutar el visualizador y se puede configurar en los siguientes servidores:
  • Convencional:
    Todos los servidores
  • Disponibilidad avanzada:
    Servidor de aplicaciones
Gestor de eventos (ehm_nxd)
El gestor de eventos gestiona eventos que proceden de CA NSM. El Gestor de eventos se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de fondo
Daemon de indexado de la gestión del conocimiento (bpeid_nxd)
Responsable del indexado de los documentos de conocimiento y se ejecuta en los siguientes servidores:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Servidor de fondo
Servidor de registro (mdb_registration_nxd)
Un agente para gestionar las solicitudes de registro de MDB. El Servidor de registro se ejecuta en los servidores siguientes:
  • Convencional:
    Servidor principal
  • Disponibilidad avanzada:
    Todos los servidores
Daemon de búsqueda (es_ebl)
Responsable de la sincronización de datos de CA SDM con el servidor de Elasticsearch.
Catalog_sync
El daemon sincroniza los nuevos archivos adjuntos y comentarios del registro con CA.
Solo produce una sincronización de las incidencias y órdenes de cambio creadas por el catálogo.
Daemon de telemetría de SDM
(
sdmtelemetry
)
Nuevo proceso de singleton que leerá los datos del KPI y los forzará en el segmento para la telemetría.
Daemon de tiempo y de temperatura (pdm_hw_nxd)
Calcula la temperatura de los tickets y el tiempo para los analistas.
El daemon solo se ejecuta cuando se activa xFlow.
Daemon de recordatorio (reminder_nxd)
Responsable de activar los recordatorios de seguimiento de los tickets.
El daemon solo se ejecuta cuando se activa xFlow.