O CA SDM inclui componentes que funcionam juntos e são executados em servidores diferentes dependendo da configuração do CA SDM. Antes de iniciar a implementação, é necessário ter um entendimento básico dos componentes a seguir:
Inicia conjuntos de processo conforme foi definido no arquivo de inicialização, pdm_startup. Por padrão, o daemon manager tenta iniciar um componente com falha até 10 vezes. Para verificar o status de todos os componentes do CA SDM, use o utilitário pdm_status. O utilitário pdm_d_refresh instrui o daemon manager a iniciar um novo ciclo de 10 tentativas para começar qualquer processo marcado como tendo anteriormente falhado.
O gerenciador de daemons é executado em todos os servidores do CA SDM.
Age como um barramento comum ou sistema de passagem de mensagem. Os componentes que precisam se comunicar entre si, primeiro, se registram com o Message Dispatcher. Quando um componente envia uma mensagem, o Message Dispatcher a entrega àqueles componentes que se registraram para receber aquele tipo de mensagem. Se dois componentes se comunicarem tanto que seja ineficiente passar as mensagens através do Message Dispatcher, eles criarão um canal rápido entre eles. É possível exibir uma lista de componentes registrados usando o utilitário slstat.
O expedidor de mensagem é executado nos seguintes servidores, dependendo da configuração do CA SDM:
Executa consultas SQL no banco de dados. Os agentes de banco de dados aderem ao esquema lógico do CA SDM e convertem o SQL neste nível para o SQL de plataforma de banco de dados física.
Observação: o agente de banco de dados detecta desconexão momentânea e consultas com falha, e tenta se reconectar e comunicar com o banco de dados. Isto só se destina a interrupções curtas, tais como uma breve queda da rede e desconexão momentânea. Não se destina a interrupções longas tais como desligamento de um serviço de banco de dados para manutenção, e assim por diante. O agente só tentará novamente a conexão por um número definido de vezes (o padrão é 3 vezes), e só por alguns minutos. Se a interrupção for superior a alguns minutos, o agente deixará de tentar conectar, e o CA SDM deverá ser reciclado após o banco de dados ter sido disponibilizado novamente.
O agente de banco de dados é executado nos seguintes servidores, dependendo da configuração do CA SDM:
Inicia ou interrompe os agentes de banco de dados. Por padrão, um número de agentes está sendo executado. Se forem necessários mais para manipular o número de consultas de banco de dados, o Agent Provider os iniciará. Se o sistema não precisar mais de tantos agentes de banco de dados, o Agent Provider encerrará os desnecessários.
O provedor do agente é executado nos seguintes servidores, dependendo da configuração do CA SDM:
Ativa a operação de múltiplos Gerenciadores de objetos. Todos os Gerenciadores de objetos em execução em servidores principais ou secundários se conectam ao Banco de dados virtual, que administra seu acesso aos agentes de banco de dados. Por exemplo, ao recuperar um novo intervalo de números de referência de ticket, o Banco de dados virtual ajuda a garantir que apenas um Gerenciador de objetos de cada vez acesse a tabela que contém os números de referência. O Banco de dados virtual também permite o armazenamento em cache das informações do banco de dados para os Gerenciadores de objetos.
O banco de dados virtual é executado nos seguintes servidores, dependendo da configuração do CA SDM:
Executa suas regras de arquivo morto e limpeza conforme configuradas pelo administrador do CA SDM.
O arquivamento e eliminação contínua são executados nos seguintes servidores dependendo da configuração do CA SDM:
Monitora as alterações nas tabelas comuns do CA MDB como, por exemplo, ca_contact.
O monitor de banco de dados é executado nos seguintes servidores dependendo da configuração do CA SDM:
Envia notificações de email de saída.
O mail daemon é executado nos seguintes servidores dependendo da configuração do CA SDM:
Aceita email de entrada ou criação de ticket e atualizações.
O mail eater é executado nos seguintes servidores dependendo da configuração do CA SDM:
Administra notificações no ambiente Windows. O Notification Manager é executado nos seguintes servidores, dependendo da configuração do CA SDM:
Executa verificação ortográfica conforme solicitado pelos clientes. O verificador ortográfico é executado em todos os servidores do CA SDM.
Cria e atualiza tickets por interfaces externas, tais como linha de comando e email. O daemon de API de texto é executado em todos os servidores do CA SDM.
Executa os tempos de atraso de eventos. Em uma implementação que possui muitos tipos ou contratos de serviço, pode haver muitos eventos ativos que o mecanismo Timed Event precisa rastrear. Nesta situação, você deve dedicar o Gerenciador de objetos do servidor principal totalmente ao mecanismo Timed Event. Você pode configurar outros Gerenciadores de objeto nos servidores principal ou secundário para acessos de produto, conforme apropriado.
O daemon Timed Event é executado nos seguintes servidores dependendo da configuração do CA SDM:
Calcula tempos de violação projetada para tipos de serviço. O daemon Tempo-para-violação é executado nos seguintes servidores dependendo da configuração do CA SDM:
(Windows somente) Inicia e reinicia componentes do CA SDM, conforme instruído pelo Daemon Manager, nos servidores principal e secundário. Ao instalar um servidor secundário, o processo de pdm_proctor_nxd é instalado como o serviço Remote Daemon Proctor do CA SDM. Quando o servidor principal iniciar, o Daemon Manager instrui o Remote Daemon Proctor a se conectar ao Message Dispatcher. O Daemon Manager instrui o Remote Daemon Proctor a iniciar componentes no servidor secundário conforme definido por Process Sets no arquivo de inicialização pdm_startup.tpl. O Proctor Daemon é executado em todos os servidores do CA SDM na configuração de disponibilidade avançada.
Age como processo de servidor do CA SDM. Ao instalar um servidor principal, por padrão, são instalados dois Gerenciadores de objetos: um para as conexões com o produto, e outro dedicado ao Pintor de telas da web. Isto permite testar as modificações sem afetar o ambiente de produção. Ao instalar um servidor secundário, é possível configurar Gerenciadores de objetos adicionais.
Pode sempre haver um Gerenciador de objetos padrão em execução no servidor principal com o qual clientes, tais como o mecanismo Timed Event, podem se conectar.
O Object Manager também armazena em cache diversos registros e tabelas para os clientes. Se usar pdm_userload para manipular estes registros, é possível também usar o utilitário pdm_cache_refresh para fazer o Gerenciador de objetos recuperar os novos dados.O gerenciador de objetos é executado em todos os servidores do CA SDM na configuração de disponibilidade avançada.
Executa código SPEL, evento, macros, e assim por diante, para um Gerenciador de objetos. Recomendamos que cada Gerenciador de objetos seja executado com seu próprio mecanismo de método.
O Method Engine é executado em todos os servidores do CA SDM.
Gerencia sessões de usuários autenticados.
O servidor de logon é executado nos seguintes servidores dependendo da configuração do CA SDM:
Faz interface com um diretório LDAP. O Method Engine é executado nos seguintes servidores, dependendo da sua configuração do CA SDM:
Executa pesquisas na base de conhecimento. No início do CA SDM, o daemon bpebr_nxd coloca os dados do Documento de conhecimento em cache na memória a partir do banco de dados. Com uma grande base de documentos, você pode ter problemas com recurso de memória. O daemon bpebr_nxd possui os seguintes requisitos de tamanho:
Pesquisa do Gerenciamento de conhecimento
O daemon de gerenciamento de conhecimento é executado nos seguintes servidores dependendo da configuração do CA SDM:
Indexa a base de conhecimento.
O daemon de indexação de palavra-chave é executado nos seguintes servidores dependendo da configuração do CA SDM:
Calcula as classificações de perguntas frequentes para o Gerenciamento de conhecimento. Ele é executado nos seguintes servidores dependendo da configuração do CA SDM:
Executa cálculos para o recurso Ficha de relatório de documento de conhecimento (KRC) do Gerenciamento de conhecimento. Este recurso permite que os analistas e gerenciadores mostrem diferentes exibições de matriz de suas contribuições de conhecimento e forneçam feedback sobre quais documentos são mais eficientes. As informações fornecidas podem ser usadas de diversos modos para aprimorar os processos de criação de documentos de conhecimento e fornecer o melhor suporte aos clientes.
O daemon de ficha de relatório de conhecimento é executado nos seguintes servidores dependendo da configuração do CA SDM.
Gerencia a administração da base de conhecimento e a lógica de gerenciamento do conhecimento. Também gerencia notificações e o processo de aprovação de documento. O daemon de gerenciamento de conhecimento é executado em todos os servidores do CA SDM.
Gerencia os repositórios de anexos para o CA SDM e o Gerenciamento de conhecimento/Daemon de pesquisa por palavra-chave. O daemon de repositório é executado nos seguintes servidores dependendo da configuração do CA SDM:
Sincroniza os arquivos de esquema entre servidor principal e secundário para garantir que estejam usando o mesmo esquema. O daemon de controle de versões é executado nos seguintes servidores dependendo da configuração do CA SDM:
Ativa certos recursos a serem implementados, independentemente de o Microsoft IIS (Internet Information Server) ser usado ou não como servidor web para acesso ao CA SDM. Esses recursos incluem o CA Workflow, itens de gráfico, anexos e serviços web.
O servidor web Apache Tomcat pode ser administrado com o controlador do Apache Tomcat (pdm_tomcat_nxd). O servidor web Apache Tomcat é executado em todos os servidores do CA SDM.
Conecta-se aos navegadores web através de um pdmweb cgi que é executado em um servidor web Microsoft IIS ou Apache Tomcat. Deve haver pelo menos um web engine para o WSP no seguintes servidores, dependendo da sua configuração do CA SDM.
Convencional: servidor principal
Disponibilidade avançada: servidor de aplicativos, servidor em espera e servidor de segundo plano
Esse processo garante que o Designer de esquemas do WSP possa gravar arquivos de esquema. Os mecanismos da web são o verdadeiro cliente de um Gerenciador de objetos usado pelo navegador web para acessar o produto.
Os mecanismos da web armazenam em cache os formulários da web .htmpl para os usuários conectados. É possível manipular o armazenamento em cache usando o utilitário pdm_webcache, e visualizar as estatísticas de conexão usando o utilitário pdm_webstat. O web engine é executado em todos os servidores do CA SDM.
(Aplica-se somente à configuração de disponibilidade avançada). Gerenciar as funções dos servidores e controlá-las em toda a configuração. Esse daemon é executado em todos os servidores na configuração de disponibilidade avançada. Ele é responsável por adquirir informações sobre servidores de segundo plano e servidores em espera, além de atualizar as informações (como a ID do slump, o nome do nó, o tipo de servidor) na classe ServerStatusMonitor. Ele recebe mensagens de difusão sobre alterações de status do servidor e solicitações de desativação, além de registrar mensagens do SLUMP_NODE_GONE que são encaminhadas aos objetos ServerStatusMonitor quando o nó que falhou for o servidor de segundo plano. Esse daemon não é aplicável à configuração convencional.
Executa a validação da conta de usuário no sistema operacional e pesquisas de registro de contato usando o campo Logon no sistema para combinar um usuário com um tipo de acesso.
Se seu negócio fornece o CA SDM a outros negócios de clientes, você pode colocar o servidor de logon em um servidor secundário, em um único local de cliente. A autenticação externa pode, então, ser ativada em tipos de acesso. Isto evita a criação de contas de usuário para seus clientes nos sistemas do negócio. Ele é executado nos seguintes servidores dependendo da configuração do CA SDM:
Coleta as informações sobre depuração para a depuração do sistema. Ele é executado em todos os servidores do CA SDM.
Executa consultas SQL para atualizar os indicadores principais de desempenho no banco de dados. O daemon QRY KPI é executado nos seguintes servidores, dependendo da configuração do CA SDM:
Coleta os principais indicadores de desempenho do tipo de sistema e grava-os no banco de dados. O daemon SYS KPI é executado nos seguintes servidores, dependendo da configuração do CA SDM:
Um utilitário para verificar o acesso ao banco de dados. Ele é executado em todos os servidores do CA SDM.
Um utilitário para criar o dicionário de dados. Ele é executado em todos os servidores do CA SDM.
Um utilitário para exibir ou definir os limites de tamanho do arquivo de log. Ele é executado em todos os servidores do CA SDM.
Um utilitário para a geração de relatórios PC. Ele é executado em todos os servidores do CA SDM.
Usado para fazer chamadas de saída do serviço web SOAP. Ele é executado em todos os servidores do CA SDM.
O CA SA Tomcat é usado para executar a automação de suporte. É configurado em qualquer servidor do CA SDM.
Instância do Tomcat utilizada para executar o CA Workflow. Ela pode ser configurada em qualquer servidor do CA SDM.
Instância do Tomcat usada para executar o Visualizador. Ela pode ser configurada nos seguintes servidores dependendo da configuração do CA SDM:
O Event Manager gerencia eventos oriundos do CA NSM. O Event manager é executado nos seguintes servidores dependendo da configuração do CA SDM:
Responsável pela indexação de documentos de conhecimento. Ele é executado nos seguintes servidores dependendo da configuração do CA SDM:
Um agente para lidar com solicitações de registro do MDB. Ele é executado nos seguintes servidores, dependendo da configuração do CA SDM:
|
Copyright © 2013 CA.
Todos os direitos reservados.
|
|