Carga Automatica de Servidores Tuxedo

A capacidade do Tuxedo de gerenciar as instâncias de servidores ativas é possivelmente um dos recursos mais mal explorados pelos clientes com que tive contato, isso por que, a configuração do recurso não é obvia como a maioria dos demais e depende do entendimento de outros recursos para seu uso.

O bom funcionamento de um ambiente é (entre outras coisas) diretamente ligado a capacidade desse ambiente atender a um volume de trabalho que lhe é conferido, quando capacidade de resposta é referência ao número disponível de um determinado recurso, temos nas mãos um paradigma de gestão, pois no ambiente computacional todo recurso possui limitações.

A definição de valores fixos para um determinado recurso pode ocasionar comportamentos distintos:

  • Os valores serem superiores ao necessário e gerar o consumo desnecessário de recursos no ambiente computacional.
  • Os valores serem inferiores ao necessário e gerar lentidão e ou indisponibilidade do recurso. Obrigando a alocação de recursos operacionais extras para gestão da indisponibilidade.

Em ambos os casos o resultado não será satisfatório, pois leva ao uso descomedido de recursos escassos, na busca de um uso racional, o Tuxedo nos oferece uma alternativa muito atraente.

 

Definição de Demanda x Capacidade de Resposta

Conhecer a demanda de um determinado servidor é um requisito não funcional que deve(ria) ser conhecido no momento da construção dos serviços. Uma vez que se conhece a demanda e é aferida a performance dos serviços no momento dos testes, é possível definir a performance do servidor e o número de instâncias necessárias para atender a demanda linear.

Sendo, R tempo de resposta média do servidor, D demanda diária de requisições e I o número de instâncias, podemos realizar o seguinte cálculo, divide-se as requisições diárias pelo número de segundos de um dia e multiplica-se pelo tempo de resposta do serviço.

Se R = 2s e D = 500.000, precisamos de 11.5 instâncias ativas para podermos atender a carga linear de requisições. A rigor, são muito raros os cenários onde um serviço atende a demanda regular de invocações, é comum haver variações durante o período, podendo gerar um ou mais momentos de pico e consequentemente momentos de vales.

A variação de demanda obriga o administrador do ambiente Tuxedo a pensar nos valores adequados de instâncias que vão atender a demanda de pico, a demanda média, a demanda de vale do serviço e qual tempo de resposta é considerado aceitável para um pequeno nível de retenção das chamadas.

Tendo em conta o seguinte cenário:

O serviço X é uma operação transacional com o SLA é de 5s, o tempo médio de resposta em ambiente operacional é de 1.3s e será invocado 200.000 vezes durante o dia, sendo que, 40% dessas chamadas serão concentradas no período das 12pm-14-pm e 18h-20h.

É necessário se preocupar com a demanda de pico e a demanda regular, não há informação suficiente para avaliar a demanda de vale para o serviço, dessa forma, o volume de pico é:

  • 40% das transações: 80.000
  • Período do volume: 4 horas
  • Transações por segundo: 5.6
  • Instâncias necessárias: (5.6 x 1.3) = 8 (como não existe meia instância, arredonda-se para cima)

Demanda regular:

  • 60% das transações: 120.000
  • Período do volume: 20 horas
  • Transações por segundo: 1.7
  • Instâncias necessárias (1.7 x 1.3) = 3

Requisições Previstas x Instâncias Necessárias

Os números acima são valores absolutos, indicam a média absoluta de requisições no momento de baixa demanda e o máximo absoluto no momento de pico, no entanto, existe uma variação entre os dois momentos, o ambiente pode estar operando em um regime abaixo da média no momento A e com o aumento da carga, no momento alcança o pico após 1 hora de trabalho, isso indica que não é necessário ocupar antecipadamente os recursos necessários para atender uma demanda esperada, sendo que, esse volume poderá levar uma hora para ser alcançado.

A melhor forma de gerir o número de instâncias disponíveis é avaliar a demanda de requisições e a capacidade de resposta de forma dinâmica, elevando o número de instâncias disponíveis de acordo com o aumento de demanda e reduzindo a capacidade disponível sempre que aferida disponibilidade ociosa, liberando recursos para outros componentes do ambiente.

Ativação dinâmica de Instâncias

 

O gráfico acima apresenta o comportamento do Tuxedo quando definida a adequação dinâmica de recursos, no período de 2 minutos, um determinado serviço teve um aumento de invocações, sendo que, o número de instâncias ativas não eram capazes de atender adequadamente, para isso, levando em conta os parâmetros definidos, o Tuxedo ativou instâncias extras do servidor para que fosse possível adequar a capacidade de resposta, em seguida, desabilitou algumas instâncias por não serem mais necessárias.

 

Definindo o Comportamento do Servidor Tuxedo

Para ativação e desativação dinâmica de servidores no Tuxedo, é necessário definir o número médio requisições retidas por um determinado período de tempo no ambiente, por exemplo:

  • Sempre que o servidorX tiver uma média de 4 requisições ou mais retidas por um tempo superior a 3 segundos, deve ser ativada uma nova instância, até que se alcance o valor máximo de instâncias prevista ou que o número de mensagens retidas fique abaixo do valor definido.
  • Quando o servidorX tiver 2 requisições ou menos em média retidas por mais de 30 segundos, deve ser desativada uma instância do servidor até que se alcance o número mínimo de instâncias previstas.

Uma vez que se prevê a demanda e faz-se a definição da adequação da capacidade, não é necessário executar nenhum tipo de ação operacional para que seu serviço atenda de forma correta a variações de volume de requisições.

Como dito no inicio do post, para que funcione a capacidade de adequação de carga no Tuxedo, é necessário conhecer uma série de características distintas que unidas permite tirar o melhor da plataforma, nesse momento, iremos abstrair o conhecimento claro dessas outras características e vamos nos focar na configuração do recurso de gestão dinâmica, para isso devem ser definidos os seguintes parâmetros.

Parâmetros do Servidor

  • MIN – Número mínimo de servidores, número de instâncias que devem ser carregadas ao ativar o servidor.
  • MAX – Número máximo de instâncias do servidor.
  • RQADDR – Nome de identificação da fila de requisições do servidor.
  • REPLYQ – Indica se o servidor necessita de fila de resposta.
  • CLOPT – Parâmetros de ativação do servidor.
O parâmetro CLOPT é onde indica-se os parâmetros para ativação e desativação de instâncias, usando como base os valores do exemplo acima, obtemos a seguinte configuração:
CLOPT="-A -p 2,30:4,3"

Detalhe:

-p – Indica a opção de controle do número de instâncias.

<carga regular> , <período> : <carga superior> , <período> – Indica as características da carga regular para desativação de instâncias e da carga superior para ativação de novas instâncias.

Cada servidor deve usar uma fila exclusiva, não pode ser feita a definição de uma mesma fila para serviços distintos.

Uma visão um pouco mais ampla da configuração nos apresenta:

ServidorX
    SRVID=100 SRVGRP=APGR101
    MIN=3  MAX=10
    RQADDR=SERVXRQ  REPLYQ=Y
    CLOPT="-A -p 2,30:4,3"

 

Antes de Encerrar…

… algumas considerações finais, não foi discutido aqui detalhes básicos da arquitetura Tuxedo, como por exemplo, ipc, computação distribuída, load-balance e peso de invocação, esses temas ficam para um momento oportuno.

Instâncias do servidor?

Para quem é novo no mundo Tuxedo, entender alguns termos e algumas características é fundamental para conseguir extrair o máximo dessa plataforma transacional.

  • Servidor – Aplicação de negócio (binário) que é executado associado ao Tuxedo.
  • Serviço- Interface ou interfaces providas por um servidor.
  • Máquina – Equipamento físico onde é executado o ambiente transacional.

Entendendo Listeners e Handlers

Falando um pouco mais sobre o que se ganha com o Tuxedo e que se não souber usar só vai atrapalhar, vamos discutir rapidamente sobre Listeners e Handlers.

 

Um pouco de feijão com arroz

Tuxedo é uma plataforma que possui uma série de características próprias, por exemplo, controle de acesso, protocolo de comunicação e controle de threads. Existe também a definição de tipos de clientes entre clientes locais e clientes remotos.

Clientes locais são aqueles que acessam o ambiente transacional a partir de uma máquina que faça parte do ambiente, sem a necessidade de uso de rede. Esses clientes utilizam a memória compartilhada (via IPC) para se comunicar.

Cliente remoto é todo aquele que acessa o ambiente transacional por meio de um canal de rede.

 

Listener, o porteiro

Para que clientes remotos possam acessar o ambiente transacional é necessário que exista uma porta de acesso, na arquitetura Tuxedo uma das portas mais conhecidas é o Workstation Listener, que em poucas palavras é um dos São Pedros da plataforma, é ele quem decide quem entra e quem fica de fora e quando entra, quais seus direitos.

Como todo bom chefe, o Listener delega o trabalho para os Workstation Handlers, esses sim fazem o trabalho sujo de ligar o cliente aos serviços que desejam utilizar.

Mas chega de metáforas ruins, vamos ver como isso funciona na prática e com que temos que nos atentar.

 

Abra una porta e ganhe uma peneira

O Workstation Listener (WSL) é o servidor que disponibiliza uma porta de acesso ao Tuxedo, a definição de qual será a porta que o servidor deverá abrir é uma decisão tomada no momento da configuração.

WSL     SRVGRP="SG1110"   SRVID=3
        RESTART=Y GRACE=0 MAXGEN=100
        CLOPT="-A -- -n //hostname:10000 -m 2 -M 2"

No exemplo de configuração acima é indicado endereço de rede “//hostname:10000″, informando que a porta “10000” deve ser usada para acesso dos clientes externos, como é nos detalhes que mora o perigo, o que faz os administradores de ambientes Tuxedo muitas vezes quebrarem a cabeça é o que vem logo em seguida, os parâmetros “-m 2 -M 2″.

Os parâmetros m e M indicam qual o número mínimo e o número máximo de  Workstation Handlers devem ser ativados associado ao servidor WSL em questão, no exemplo são fixos dois servidores.

Workstation Handler é um delegado do cliente remoto, ele recebe os comandos enviados pelo cliente remoto e executa em seu nome no ambiente local Tuxedo, acessando diretamente a memória compartilhada. Para que seja possível receber os comandos do cliente remoto, o Handler abre uma porta de conexão para que possa ser realizada a comunicação, diferente do WSL onde se conhece a porta que se abrirá, as portas abertas pelo Handler são de conhecimento do Listener, sendo assim, ao carregar o ambiente podemos ter algo parecido com a imagem abaixo.

 

Delegação de responsabilidade

O processo de acesso do cliente ao ambiente Tuxedo é executado seguindo uma série de ações, como o único endereço de acesso conhecido é o do WSL (o endereço declarado na configuração), o cliente se conecta a esse servidor e executa a autenticação no ambiente, concluída essa etapa, o WSL delega a responsabilidade de tratar as operações do cliente para um dos WSH disponível.

Ao final, o WSL responde para o cliente o endereço de rede do Handler que deve ser invocado nas chamadas, o cliente por sua vez, se conecta ao servidor WSH indicado.

Se os parágrafos acima ficaram confusos, não se preocupe, aqui embaixo temos mais um diagrama ilustrativo para ajudar.

Sequência de ações:

  1. O cliente é autenticado no WSL;
  2. O cliente é delegado para o WSH disponível;
  3. É informado ao cliente o WSH de conexão;
  4. O cliente se conecta ao WSH indicado.

Passando pelo muro de fogo

Como comentado anteriormente, a única porta conhecida previamente é a do servidor WSL, por outro lado, a comunicação entre o cliente e o ambiente Tuxedo utiliza ao menos duas portas, fazendo as contas, sobra uma porta que não se conhece, além disso, não é possível definir empiricamente qual porta o WSH utilizará, em cada carga do ambiente são selecionadas portas distintas.

Após a carga do servidor:

tcp    0   0 127.0.0.1:10000         0.0.0.0:*           LISTEN      24706/WSL
tcp    0   0 127.0.0.1:26055         0.0.0.0:*           LISTEN      24707/WSH
tcp    0   0 127.0.0.1:26056         0.0.0.0:*           LISTEN      24708/WSH

Após o reinicio do servidor:

tcp    0   0 127.0.0.1:10000         0.0.0.0:*           LISTEN      24706/WSL
tcp    0   0 127.0.0.1:30458         0.0.0.0:*           LISTEN      24707/WSH
tcp    0   0 127.0.0.1:30459         0.0.0.0:*           LISTEN      24708/WSH

Em ambientes corporativos, por questões de segurança toda comunicação entre equipamentos é doutrinada por firewall, faz parte da doutrina definir quais portas podem ser acessadas em determinado servidor, se não é conhecida a porta que o WSH utilizará o cliente conseguirá acessar o WSL mas não conseguirá completar a conexão com o WSH pois será impedido pelo firewall.

Para se conhecer as portas que serão utilizadas pelo WSH é necessário declarar na configuração servidor WSL, no entanto, deve-se ter muito cuidado com essa questão, caso as portas declaradas estejam em uso no momento da carga do servidor, o ambiente não será carregado adequadamente.

WSL     SRVGRP="SG1110"   SRVID=3
        RESTART=Y GRACE=0 MAXGEN=100
        CLOPT="-A -- -n //hostname:10000 -m 4 -M 10 -p 10001 -P 10010"

Como evolução da configuração original, são usados o parâmetros p e P para a carga do servidor WSL, esses parâmetros indicam a menor e a maior porta a serem alocadas pelos WSH quando carregados, os valores padrão são “-p 2048 -P 65535″.

Portas alocadas pelos WSH quando definida a faixa permitida:

tcp    0   0 127.0.0.1:10000         0.0.0.0:*          LISTEN      28559/WSL       
tcp    0   0 127.0.0.1:10001         0.0.0.0:*          LISTEN      28562/WSH       
tcp    0   0 127.0.0.1:10002         0.0.0.0:*          LISTEN      28563/WSH       
tcp    0   0 127.0.0.1:10009         0.0.0.0:*          LISTEN      28560/WSH       
tcp    0   0 127.0.0.1:10010         0.0.0.0:*          LISTEN      28561/WSH

Agora que se conhece as portas pelas quais o cliente irá se comunicar com o WSH, é possível cadastrar as regras no firewall para que a comunicação possa ocorrer sem problemas.

 

Quando fucinho não é tomada

Permitir o acesso de clientes remotos significa que esses clientes podem estar em qualquer lugar, como por exemplo em outra rede, caso a comunicação entre as redes envolva o mascaramento dos endereços internos por meio de NAT (Network Address Translation), além de indicar o IP/DNS interno e a porta que o servidor utilizará na máquina, é necessário indicar o IP/DNS e a porta pública que os clientes devem utilizar fora da rede interna para acessar o WSL.

Para indicar a configuração de acesso via rede pública utiliza-se o parâmetro H.

WSL     SRVGRP="SG1110"   SRVID=3
        RESTART=Y GRACE=0 MAXGEN=100
        CLOPT="-A -- -n //hostname:10000 -m 4 -M 10 -p 10001 -P 10010
                     -H //publicname:10000"

No exemplo acima a configuração indica que o servidor irá abrir a porta local 10000 no IP associado ao nome hostname e que receberá comunicação pelo IP associado ao nome publicname.