TMACUL

CA SDM Dicas de upgrade

Blog Post created by TMACUL Champion on Jul 8, 2016

Escrito por: Eduardo Paz

 

 

Olá, pessoal! Seguem meus 2%... algumas dicas baseadas em minhas primeiras experiências de upgrade. Já fiz SDM 12.7 -> 14.1 CUM1, SDM 12.6 -> 14.1 CUM2 e SDM 12.9 -> 14.1 CUM2:

 

 

* De maneira bem direta: utilize um ambiente swing para a upgrade! YES: Upgrade in-place can be a nightmare!

 

 

* Caso esteja pensando em ativar a disponibilidade avançada, avalie primeiramente as regras de segurança e firewalls entre os servidores: a questão das portas aleatórias utilizadas na conexão entre os processos, entre os servidores, é crítica. Firewalls locais também devem ser analisados, visando garantir a conectividade em portas aleatórias. Em tempo de projeto, não tive muito sucesso utilizando o parâmetro de portas fixas (NX_SLUMP_FIXED_SOCKETS).

 

 

* Se sua organização exige que as vulnerabilidades em application servers sejam eliminadas, ou minimizadas, conte com o apoio de um especialista no assunto para ajustar Tomcat, JBOSS e IIS.

 

 

* Nunca reutilize formulários de versões antigas na versão 14.1. Pode ser que num primeiro momento funcione, em seus testes unitários... ao longo do tempo e com o aumento da carga e utilização, esses formulários geram estresse nas webengines, derrubando o serviço. Seguindo a melhor prática da CA, reaplique suas customizações nos arquivos da nova versão. Ou melhor ainda: evite customizações, utilizando os modernos recursos da nova versão.

 

 

* Pode ser "chover no molhado", mas todos os post-steps das fixes e testfixes devem ser avaliados cuidadosamente e aplicados com muita atenção. Não ignore mensagens de warning nas logs da aplicação da fix. Em qualquer situação inesperada, entre em contato com o suporte CA.

 

 

* Ao parar um serviço CA Service Desk Manager Servidor em uma máquina Windows, atente-se para processos que nomeei "zumbis", que ficam ativos na memória do servidor (utilize o task manager). Esses processos vão disputar recursos com o serviço na próxima subida, e alguns deles indisponibilizam funcionalidades. Ex.: java.exe, sql_agent_nxd.exe (ou oracle_agent_nxd.exe) e sslump_nxd.exe.

 

 

* O alerta acima vale para implementações que utilizam restart automático do serviço do CA SDM. Essa é uma estratégia interessante para "refrescar" os processos do CA SDM e iniciar um dia de operação sem problemas porém, se você utiliza esse modelo, revise seus scripts para que tratem os processos "zumbi".

 

 

* Novamente: chuva no molhado... teste, teste, teste. Unitário, integrado, de carga, funcional com a área de negócio. Um plano de teste bem elaborado e abrangente pode evitar pesadelos.

 

 

* CUM2 para o CA SM 14.1: sem pensar muito, aplique!

 

 

* Replicação SQL para o Offline Reporting: verifique os procedimentos para criação de novas tabelas num ambiente CA SM 14.1 com replicação SQL ativada. Há indícios de que a replicação bloqueia alterações no modelo de dados do banco MDB. Avaliar com atenção. Esse alerta pode estar obsoleto, uma vez que o BOXI será substituído pelo JasperSoft... mas sem dúvida haverá algo nessa nova plataforma para evitar que extrações de relatório concorram com o ambiente acessado pelos usuários e clientes. Importante avaliarmos.

 

 

* Triggers e macros de ação: caso esteja avaliando a possibilidade de utilizar a disponibilidade avançada, cuidado com triggers customizados e macros de ação, em especial as executadas por eventos de SLA. No modelo CA SDM AA, o processamento é paralelo, ou seja, macros disparadas pelo ANIMATOR (agendadas) são executadas pelo Background Server, ao passo que os triggers em tempo de execução são disparados pelos servidores de aplicação - os semáforos devem ser criados por você! Outra situação: ao mesmo tempo, o usuário pode estar editando um ticket através da interface web, em um application server, e um evento agendado (que executa uma macro de ação) é disparado pelo ANIMATOR no Background Server... teremos bloqueio de tickets, colapso do processo ANIMATOR e queda gradual da aplicação no Background server, o que compromete toda a solução. Então, seguem os principais alertas: 1) crie com atenção semáforos em toda customização spel; 2) utilize retries em suas macros de ação e em spels em POST_CI; 3) e, sempre que possível, adapte suas macros utilizando o modelo das macros de ação padrão CA, que utilizam send_wait. Em ambientes com arquitetura convencional não percebi esse comportamento (é, fiz mais algumas atualizações...). Se me permitem, 4) evite customizações, executando profunda análise de aderência de seus processos frente as funcionalidades nativas da solução.

 

 

* CA SDM REST WebService: recomendo considerar um servidor dedicado para essa funcionalidade caso o volume de transações seja grande - algo acima de 10 transações por segundo (parece muito, mas dependendo do uso, só o Mobile APP for CA Service Management gera essa quantidade de transações em picos de acesso). Não se esqueça de implantar o logout da REST Session ao finalizar as transações em suas customizações que acessem o WebService REST.

 

 

* Há processos prontos para integração USS -> Catalog -> SDM. São excelente base para iniciar a utilização do PAM em sua implementação, possibilitando a desativação de customizações que seriam substituídas por capacidades nativas. Obviamente, esse é um trabalho pesado, que pode ser, inclusive, iniciado após seu primeiro GoLive 14.1. Vale a pena!

 

 

* Finalmente, arquitetura: aplique as melhores práticas para desenho da arquitetura sugeridas pela CA. Não tente fazer mágica utilizando menos recursos que o mínimo sugerido. Em último caso, vale a pena considerar a aquisição de um CA Expert Pack para desenho da arquitetura e para ajuda na definição da estratégia de upgrade.

 

Publicado Originalmente no facebook: CA SDM Brasil

por Eduardo Paz

em: 11/06/2016

 

CA SDM Upgrade tips from Eduardo Paz

Outcomes