Grupo Fleury utilizou o System Center Orchestrator para evoluir seu Landscape de Arquitetura de Sistemas

Confira o caso de sucesso do Grupo Fleury, empresa de grande porte de medicina e saúde do País com 90 anos no mercado. A empresa possui alto foco em serviços ao cliente, inovação e qualidade técnica. Além de contar com um total de 55 milhões de exames de análises clínicas, 4 milhões de imagem, 138 unidades e outras linhas de negócio espalhadas pelo Brasil.

 

Cenário inicial

O Fleury não tinha em seu Landscape de Sistemas uma ferramenta de Workload/JobScheduler. E então, as soluções que demandassem mecanismos de tarefas agendadas seriam atendidas com Windows Services/Jobs agendados Windows Server, ou Crontab na plataforma Linux.

 

A Arquitetura de Solução de Enterprise Application Integration Custom desenhada para a integração entre sistemas transacionais e o SAP sob o projeto de maior impacto para a empresa (Projeto Panamá), demandou uma quantidade nunca antes vivenciada de tarefas agendadas com suas respectivas agendas, taxa de vazão e criticidade para o negócio considerando Volumetria, Disponibilidade, Performance, Confiabilidade e Operabilidade entre os ambientes Transacional/Legado e SAP.

 

Dados os cenários de complexidade para os requisitos arquiteturalmente significantes que o projeto demandou, se provou insustentável considerar a adoção dos mecanismos que dispúnhamos – até então – para gerenciamento de tarefas agendadas, que chegaram à proporção de uma centena, ao menos.

 

Primeiro passo: prova de conceito do System Center Orchestrator

Num dado momento durante o processo de desenho da Arquitetura de Solução do Projeto, a equipe do grupo Fleury descobriu na suíte do System Center o Orchestrator. E então, decidiu fazer uma breve prova de conceito que num primeiro momento, se mostrou um sucesso.

 

No entanto, em um teste posterior com maior carga de processamento e quantidade de jobs em paralelo, sob a estrutura de implementação com Runbooks sendo instanciados dinamicamente, para uma quantidade elevada de jobs em paralelo e em alta frequência, com seu último step executando requisições HTTP/SOAP contra um farm IIS balanceado via F5 (Roundrobin) de Web Services WCF, O Orchestrator começou a enfileirar a execução dos steps até o ponto de não responder mais a qualquer comando.

 

Segunda passo: revisão da implementação

Neste momento, com o suporte da Microsoft, a equipe identificou que a topologia de instalação do cluster Orchestrator estava inadequada. Feito seu ajuste, tentou executar o cenário anterior de carga e teve o mesmo resultado negativo.

 

Foi então que a equipe revisou a implementação de instância dinâmica de Runbooks para cada requisição HTTP. A empresa teve conhecimento do SDK Orchestrator e seu poder para criação de addins e fácil deploy dentro do farm Orchestrator. A partir de então, a equipe criou uma Custom Activity em .Net C# com a responsabilidade de disparar requisições HTTP contra um endpoint informado por meio de canais em paralelo que executam essas requisições maximizando o poder de escalabilidade.

 

A equipe do Grupo Fleury reestruturou o runbook de modo a entregar efetivamente um nível maior de orquestração sob quatro processos elementares: 1. Consulta de agenda de Execução; 2. Verifica semáforo de runbooks; 3. Obtém quantidade de requisições simultâneas e demais parâmetros; 4. Executa Custom Activity.

 

 Terceiro passo: teste de performance

Já no momento de Teste de Performance do projeto foi possível aferir que sob esta nova topologia de instalação e estrutura de implementação, os KPI’s de performance da plataforma de integração foram atingidos com sucesso. Com especial destaque para um dos steps onde a Custom Activity abriu 100 canais paralelos de request e conseguimos integrar em 40 minutos 37 mil mensagens com zero enfileiramento no Orchestrator.

 

A equipe do Grupo Fleury estudou mais ainda o produto e com o suporte da Microsoft teve acesso a demais componentes para suporte à monitoria, entregando mais robustez à solução.

 

Próximos passos

Sabendo do Roadmap deste produto para a plataforma Azure, ainda que ele não esteja no Magic Quadrant do Gartner para Workload Automation, a empresa diz estar segura em expandir o Cluster Orchestrator para o utilizar neste momento como solução de Workload Automation/Job Scheduler. E já tem definido não criar mais Windows Services/Job Scheduler/Crontabs e também já prevê a migração de alguns sistemas que façam uso desta tecnologia para dentro do Orchestrator.

 

Resultado

Com esta ação, o grupo reduziu o custo de projeto, melhorou a gestão de Operação/Datacenter e evoluiu o Landscape de Arquitetura de Sistemas.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *


*