Como controlar a versão das personalizações do sistema em todos os servidores do CA SDM

O controle de versão do CA SDM ajuda a gerenciar as personalizações do sistema em todos os servidores do CA SDM (cliente e servidores). Dependendo da configuração do CA SDM, os clientes e servidores a seguir são usados:
casm173
O controle de versão do CA SDM ajuda a gerenciar as personalizações do sistema em todos os servidores do CA SDM (cliente e servidores). Dependendo da configuração do CA SDM, os clientes e servidores a seguir são usados:
  • Configuração convencional,
    • Cliente: servidor secundário
    • Servidor: servidor principal
  • Configuração de disponibilidade avançada
    • Cliente: servidor de aplicativos e servidor em espera
    • Servidor: servidor em segundo plano
Exemplo: como administrador do sistema, você adicionou um campo na página detail_usp_server.htmpl do CA SDM. Agora, você deseja sincronizar esta alteração no cliente e servidores. Este exemplo é usado em todo o cenário para explicar como a personalização é sincronizada.
O diagrama a seguir mostra como controlar a versão das personalizações do sistema em todos os servidores do CA SDM:
Diagrama mostrando como controlar a versão das personalizações do sistema em todos os servidores do CA SDM
Siga estas etapas:
Verifique os pré-requisitos
Verifique os seguintes pré-requisitos:
  • Certifique-se de que a opção ver_ctl esteja definida para o valor
    atualizar
    . Quando uma discrepância de versão é detectada, uma tentativa de atualização dos componentes afetados é feita no cliente. Se a atualização for bem-sucedida, a conexão do cliente com o servidor continuará; caso contrário, a conexão será encerrada. Para obter mais informações sobre a opção ver_ctl, consulte a
    Ajuda online
    .
  • Certifique-se de que o arquivo server_secondary_custom.ver foi criado no diretório $NX_ROOT\site\mods do servidor principal ou servidor de segundo plano (dependendo da configuração do CA SDM). Todas as personalizações para um componente de controle de versão devem ser realizadas neste arquivo. Se o arquivo não existir, certifique-se de criá-lo no mesmo local.
Modifique o arquivo de controle de versão do servidor
Depois de concluir a personalização, (por exemplo, adicionar um campo na página HTPML) adicione ou atualize os componentes de controle de versão no arquivo de controle de versão do servidor. Um componente de controle de versão pode representar um arquivo, diretório ou o arquivo de variável de ambiente client_nx.env.
Siga estas etapas:
  1. Efetue logon no servidor a seguir, dependendo da configuração do CA SDM:
    • Convencional: servidor principal
    • Disponibilidade avançada: servidor em segundo plano
  2. Vá até o seguinte diretório:
    $NX_ROOT\site\mods
  3. Abra o arquivo server_secondary_custom.ver.
  4. Adicione os seguintes componentes:
    [ MY_USP_SERVERS_HTMPL ] directory="$NX_ROOT/site/mods/www/htmpl/web/analyst/Analyst" filename="detail_usp_servers.htmpl" version="2.0 , 20121119" o_mode="RW" g_mode="RW" w_mode="RW" file_ctl
    Para obter mais informações sobre como adicionar ou atualizar componentes de controle de versão, consulte o tópico Componente de controle de versão.
  5. Salve o arquivo server_secondary_custom.ver.
    O componente de controle de versão é adicionado ao arquivo de controle de versão.
Componentes de controle de versão
Para definir um novo componente,
  • use a seguinte sintaxe. Itens com letras em
    itálico
    representam dados fornecidos por você. O
    nome_do_componente
    e os parâmetros de versão são sempre exigidos. Outros parâmetros podem ser exigidos, dependendo do valor do
    tipo de controle
    . Todos os outros itens representam palavras-chave que você deve digitar exatamente como mostrado no exemplo a seguir:
    [ component-name ] version = "x.x, yyyymmdd" control-type filename = "filename" directory = "directory" link = "link-directory" source = "source-directory" effectivity = "effect-spec" checksum min_release = "release" max_release = "release" component_type = "file-type" o_mode = "owner-mode" g_mode = "group-mode" w_mode = "world-mode"
    Para obter mais informações sobre os parâmetros, consulte o tópico Parâmetros de controle de versão. Para obter mais informações sobre a estrutura e a sintaxe de arquivos de controle de versão, consulte os arquivos .ver instalados no diretório $NX_ROOT/site. Esses arquivos têm comentários úteis e configurações de exemplo que podem ajudá-lo.
Para atualizar uma entrada de componente existente:
  • Altere o parâmetro. Por exemplo, pode-se alterar o número da versão.
Para remover o controle de um componente,
  • Edite os campos da seguinte maneira:
    ! uncontrol component-name
Parâmetros de controle de versão
Os seguintes parâmetros se aplicam ao controle de versão:
  • [ nome do componente ]
    Especifica o nome de um item sob controle de versão. O nome deve ser exclusivo e colocado entre colchetes. O
    nome do componente
    não diferencia maiúsculas de minúsculas. Esse parâmetro é obrigatório para iniciar uma definição componente.
  • version="x.x. yyymmd"
    Especifica um número de versão (
    x.x
    ) e uma data (
    yyymmdd
    ) que definem a versão do componente. Esse parâmetro é exigido, e deve ser incluído com aspas duplas. O controle de versão verifica a versão de um componente ao comparar o número da versão e sua data no servidor com o número de versão e data no cliente. Tanto o número da versão quanto a data devem corresponder nos componentes para que sejam considerados sincronizados entre cliente e servidor. Opcionalmente, se a propriedade checksum estiver habilitada, o arquivo será verificado pela soma de verificação antes de ser atualizado.
  • tipo de controle
    Especifica o tipo de controle de versão para esse componente. As configurações a seguir são válidas para o tipo de controle:
Definição
Descrição
dir_ctl
Especifica que o componente representa um diretório. Você deve fornecer o parâmetro de diretório para especificar o caminho ao diretório. É possível também fornecer o parâmetro de nome de arquivo para especificá-lo para filtrar um conjunto de arquivos no diretório. Os subdiretórios não são atualizados no UNIX ou Windows.
file_ctl
Especifica que o componente representa um arquivo. Você deve fornecer o diretório e os parâmetros de nome de arquivo para especificar o caminho ao arquivo.
Nxenv_ctl
Especifica que esse componente representa o arquivo client_nx.env, que é usado para armazenar variáveis de ambiente internas do CA SDM. O controle de versão do CA SDM e o Gerenciador de opções mantêm este arquivo automaticamente. Há um componente nxenv_ctl, e seu nome de componente deve ser CLIENT_NXENV.
ver_ctl
Esse é o tipo de controle padrão. Ele especifica que o componente é genérico; isto é, ele não está associado a qualquer objeto externo específico. É possível usar um componente genérico para fornecer controle de versão para o cliente como um todo ou para um arquivo ou diretório grande demais para uma atualização automática. Os componentes com um tipo de controle ver_ctl não podem ser atualizados; a falta de correspondência entre versões de um componente ver_ctl quando o servidor está em modo ATUALIZAR causa a falha da conexão do cliente.
  • filename="nome de arquivo"
    Especifica o nome de um arquivo sob controle de versão. Não contém especificações de diretório. Esse parâmetro é exigido para componentes file_ctl, mas é opcional para componentes de controle de diretório (dir_ctl). Quando usado com componentes de diretório, o parâmetro de nome de arquivo age como uma máscara de arquivo para restringir os arquivos associados ao componente dir_ctl. Por exemplo, se o nome de arquivo de um componente dir_ctl for *.README, então uma atualização desse diretório incluirá apenas arquivos terminados em “.README.”.
  • directory="diretório"
    Especifica o caminho do diretório dos componentes dir_ctl, ou do diretório contendo o arquivo para componentes file_ctl. Esse parâmetro é ignorado em componentes ver_ctl e nxenv_ctl. O caminho do diretório deve ser incluído entre aspas e pode conter referências a variáveis de ambiente precedidas por $.
    Sempre use barras de data (e não barras invertidas) para separar subdiretórios no nome do caminho, mesmo em um servidor Windows.
  • link="diretório de link"
    Especifica um diretório de link no cliente no mesmo formato descrito previamente para o parâmetro de diretório. Esse parâmetro é opcional para componentes file_ctl e dir_ctl, e é ignorado em componentes ver_ctl e nxenv_ctl. Se for especificado, uma atualização a um cliente Linux pode fazer com que um link simbólico seja colocado no diretório de link, apontando para o arquivo real copiado ao local especificado pelo parâmetro de diretório. Uma atualização a um cliente Windows faz com que o arquivo real seja copiado aos locais do link e de diretório.
  • source="diretório de origem"
    (Opcional) Especifica um diretório diferente no servidor onde o servidor pode recuperar arquivos a serem fornecidos. Esse parâmetro tem o mesmo formato descrito previamente para o parâmetro de diretório. Isto é útil se os arquivos que devem ser entregues ao cliente são diferentes dos mesmos arquivos que se encontram no local de diretório no servidor. Esse parâmetro é usado para instruir o servidor a recuperar o arquivo do
    diretório de origem
    e entregá-lo ao local no cliente especificado pelo parâmetro de diretório. O parâmetro de diretório é necessário quando você especifica o parâmetro de origem.
  • effectivity="especificação de efetividade"
    (Opcional) Especifica se o cliente deve receber esse componente. Permite excluir alguns clientes do download. Se um cliente não for incluído na especificação de efetividade, ele não receberá o componente. Se este parâmetro for omitido, todos os clientes receberão o componente. A especificação de efetividade usa os seguintes símbolos:
    • + (sinal de adição)
      Indica a adição de um grupo de cliente.
    • - (sinal de subtração)
      Indica a exclusão de um grupo de cliente.
Os seguintes grupos de clientes são válidos:
  • SUN4SOL
  • AIX
  • LINUX
  • LINUX390
  • HP
  • WINDOWS_CLIENTS
  • UNIX_CLIENTS
Por exemplo, a seguinte especificação indica que apenas os clientes UNIX devem receber os arquivos:
effectivity = "+ UNIX_CLIENTS"
  • checksum
    Determina a atualização do componente se a soma de verificação do componente no cliente não corresponder à soma de verificação no servidor. Quando aplicado a um diretório, a soma de verificação é aplicada a cada arquivo.
  • min_release=“release” e max_release="release"
    Especifica o cliente mais antigo e o mais recente aos quais esse componente deve ser distribuído. As declarações no arquivo server_default.ver definem as versões. Esses parâmetros estão no seguinte formato, onde Ga
    xx
    indica a versão e os valores subsequentes são genlevels associados à versão.
    ! Release GA50 50MVV000900 50W7T000900 ! Release GA45 45MW000900 50WTT000900
    A requisição indica que GA50 é mais recente do que GA45.
  • component_type
    Especifica o tipo de componente utilizado. Os seguintes tipos de componentes são usados:
Definição
Descrição
arquivo
Esse é o tipo de componente padrão. Especifica que os arquivos copiados ao cliente devem ser obtidos diretamente do local no servidor indicado pelo parâmetro de diretório.
exe_file
Especifica que os arquivos copiados ao cliente devem ser obtidos de um local no servidor que depende do sistema operacional do cliente, como mostrado a seguir:
windows (Windows)
sun4Sol (Solaris)
hp (HP-UX)
aix -- AIX)
linux (Linux)
linux390 (Linux390)
Os locais para esses subdiretórios dependem do configuração de parâmetro de diretório. Se esse parâmetro estiver definido, os subdiretórios estarão localizados sob o
diretório
indicado. Do contrário, eles estarão localizados sob o diretório bin do diretório de instalação principal do CA SDM.
  • o_mode="modo-proprietário"
    Especifica as permissões de acesso do arquivo para o proprietário do arquivo.
  • g_mode="modo-grupo"
    Especifica as permissões de acesso do arquivo para usuários no grupo do proprietário do arquivo (usados apenas com clientes UNIX).
  • w_mode="mode-mundial"
    Especifica as permissões de acesso do arquivo para usuários que não fazem parte do grupo do proprietário do arquivo (usados apenas com clientes UNIX).
    Os três parâmetros de modo permitem que versões diferentes do mesmo executável sejam mantidas no servidor. Eles especificam controles de acesso ao arquivo quando ele é copiado ao cliente. Esses parâmetros são usados apenas durante uma operação de atualização. Eles consistem de um a três caracteres, que significam o seguinte:
Definição
Descrição
R
Read (Leitura)
W
Write (Gravação)
v
Execute
Os clientes de PC ignoram as permissões de Gravação e Execução.
Você pode especificar qualquer combinação de um ou mais modos de acesso de arquivo. Em clientes UNIX, o arquivo apresenta o modo de acesso especificado. Em clientes de PC, o arquivo é gravável ou somente leitura, dependendo da especificação de w_mode.
Reinicie o CA SDM no cliente
Reinicie o CA SDM em servidores cliente para atualizar os arquivos de controle de versão de cliente com as personalizações.
Selecione
Iniciar
,
Configurações
,
Painel de controle
,
Ferramentas administrativas
,
Serviços
. Clique com o botão direito do mouse no
Servidor do CA SDM
e selecione
Iniciar
para reiniciar ou iniciar um servidor.
Siga estas etapas:
  1. Para a configuração convencional, reinicie o servidor secundário.
  2. Para a configuração de disponibilidade avançada, execute as seguintes etapas:
    1. Reinicie todos os servidores em espera.
    2. Reinicie o servidor de aplicativos menos ativo.
    3. Inicie o servidor de aplicativos.
    4. Executa as etapas d e e para mais servidores de aplicativos.
    O cliente se conecta ao servidor para enviar uma lista de seus componentes controlados. O servidor compara a lista a sua própria lista mestra. Os componentes afetados no cliente são atualizados.
Selecione o servidor de aplicativos menos ativo
Selecione um servidor de aplicativos com o mínimo de atividade do usuário. Execute o comando a seguir em cada servidor de aplicativos para selecionar um com poucas ou nenhuma sessão ativa.
pdm_webstat
Esse comando não captura as sessões de serviço web REST ou SOAP.
Interromper outro servidor de aplicativos
É necessário informar todos os usuários ativos em um servidor de aplicativos para mover para o servidor de aplicativos menos ativo antes de interrompê-lo. Certifique-se de que tenha reiniciado o servidor de aplicativos menos ativo antes de mover todos os usuários para ele.
Siga estas etapas:
  1. (Recomendado) informe todos os analistas ativos de Automação de suporte no servidor de aplicativos que você deseja interromper, para criar um ticket no CA SDM com suas informações de sessão. Esse processo garante que as informações sobre sessões não sejam perdidas. Por exemplo, o analista de Automação de suporte está em uma sessão com um cliente para solucionar um problema de hardware. Nesse caso, o analista de Automação de suporte pode criar uma ocorrência no CA SDM com as informações da sessão antes do encerramento do servidor de aplicativos.
  2. Envie uma notificação (por exemplo, uma notificação de email) para todos os usuários ativos no servidor de aplicativos para mover para o servidor de aplicativos menos ativo que acabou de ser reiniciado. Esta notificação pode incluir os detalhes do servidor de aplicativos atualizado.
  3. Execute o comando a seguir no servidor de aplicativos:
    pdm_server_control [-h] -q interval -s server_name
    • -h
      Exibe a página de ajuda.
    • -q interval -s server_name
      Notifica um servidor de aplicativos local ou remoto para ficar inativo em um intervalo de tempo especificado. Este intervalo é o número de segundos antes que o servidor fique offline. Ao usar essa opção sem um server_name, o servidor local é notificado para ficar inativo. Esta opção não pode ser usada para um servidor de segundo plano ou um servidor em espera.
    Uma mensagem pop-up é exibida para todos os usuários ativos no servidor de aplicativos para notificá-los sobre o encerramento do servidor e o tempo restante para o encerramento. Os usuários devem salvar seu trabalho e efetuar logoff naquele horário. O servidor de aplicativos é interrompido após o horário especificado. Os usuários devem efetuar logon em outro servidor de aplicativos para retomar seu trabalho. O analista de Automação de suporte pode fazer referência ao ticket e retomar seu trabalho.
    O servidor de aplicativos foi interrompido com êxito.
Verifique as personalizações no cliente
É preciso verificar o arquivo de controle de versão no cliente para verificar se todas as personalizações foram sincronizadas.
Siga estas etapas:
  1. Efetue logon no cliente a seguir dependendo da configuração do CA SDM:
    • Convencional: servidor secundário
    • Disponibilidade avançada: servidor em espera e servidor de aplicativos
  2. Abra o arquivo stdlog no seguinte local:
    $NX_ROOT\log
  3. Verifique se todas as personalizações feitas no servidor foram aplicadas no cliente.