Afinal, o que é Tuxedo?

Tuxedo é um monitor de processamento transacional (TPM), desenvolvido no início da década de oitenta pela AT&T’s Bell Laboratories para ser um gerenciador de transações baseado em sistema operacional UNIX e que garantisse uma performance superior a 1.000 (um mil) transações por SEGUNDO.

As características do produto foram estabelecidas como pilares tão sólidos que o batismo do mesmo não poderia ser tão menos criativa, TUXEDO significa em inglês “Transactions for Unix, eXtEnded for Distributed Operations”.

Uma década depois de sua criação e depois de ter mudado de casa uma vez, o produto é adquirido pela BEA Systems que empenha esforços para tornar o produto amplamente conhecido no mercado, em 1999 é destacado como a melhor plataforma de transações distribuídas para aplicações C/C++ e COBOL utilizando a arquitetura de serviços (você achava que SOA era novidade?).

 

Foco de Mercado

 

Não é de se estranhar, mesmo sendo um produto com características muito avançadas desde sua concepção o TUXEDO não é conhecido de maneira geral no Brasil.

Os principais clientes desse produto são operadoras de telefonia, bancos, operadoras de cartão de crédito, empresas de aviação e empresas de logística, a rigor, empresas que possuem um volume muito grande de transações em sistemas de missão crítica, quando fala-se em grande volume de transações os números são geralmente astronômicos, lembrando do requisito básico de mil transações por segundo.

Vale ressaltar, no Brasil mesmo não sendo muito conhecido, esse produto é encontrado em operadoras de cartão de crédito, operadoras de telefonia, entre outras.

Alguns dos grandes utilizadores do Tuxedo: FEDEX, MasterCard, Delta, Citi, CREDIT SUISSE e China Unionpay.

 

Visão Geral da Arquitetura

 

Tuxedo é essencialmente e trocando para termos mais comuns um servidor de aplicações. Possui características como ambiente clusterizado, comunicação entre ambientes, distribuição de carga entre os servidores, tolerância a falhas, coordenação transacional, sistema de mensageria e conectividade com outras plataformas.

Originalmente eram suportadas as linguagens C e C++, a evolução da plataforma fez com que fosse disponibilizado o suporte a COBOL, para atender clientes que pretendiam sair da plataforma Mainframe com o mínimo de impacto, atualmente, são suportadas também as linguagens Phyton, Ruby e PHP.

É interessante ressaltar uma característica que muitas vezes é ignorada, o Tuxedo é multi-plataforma, um cluster pode ser formado por máquinas de arquiteturas distintas, como por exemplo, Intel e SPARC, todo trabalho de garantir a comunicação correta entre esses servidores fica a cargo do servidor de aplicação.

 

Arquitetura Orientada a Serviços (SOA)

 

Atualmente muito se fala na área da arquitetura de sistemas sobre o desenho de soluções baseadas em serviços, por sua vez, Tuxedo é totalmente baseado nessas características desde o início, uma aplicação cliente ao invocar uma serviço Tuxedo, na verdade invoca o nome do serviço, não é necessário se preocupar com a localização do mesmo, muito menos precisa ter ciência de detalhes de implementação do serviço.

Com a consolidação da tecnologia de Webservices, bastou criar um módulo que extrai a assinatura original dos serviços do ambiente Tuxedo (SALT) e cria uma camada de conversão para XML, a partir disso todos serviços passaram a responder Webservice sem NENHUM tipo de modificação.

Modelo de Comunicação

 

Por mais que não pareça, a rigor toda comunicação na plataforma é assíncrona utilizando Unix/Linux IPC (Inter-process communication), essa característica é um importante recurso voltado a estabilidade, velocidade de resposta e garantia de ativação do serviço.

Mesmo que inerentemente as invocações sejam assíncronas, a plataforma permite que o cliente execute chamadas do tipo síncrona e assíncrona sem abrir mão de nenhum tipo de benefício citado acima. Um outro tipo de invocação permitida é a de encaminhamento (tpforward), não entrarei em detalhes a respeito pois pretendo manter esse material em um nível menos técnico.

Além da comunicação por meio de memória compartilhada, outra forma de comunicação tão poderosa quanto o IPC é a comunicação por mensagens, para isso o Tuxedo fornece o sistema de mensagens conhecido por /Q, esse produto garante a persistência das mensagens e a garantia de entrega e consumo por meio de transação distribuída (XA). Originalmente esse módulo somente permitia a tramitação de mensagens persistidas em meio físico, no entanto, a partir da versão 8 foi disponibilizado o recurso de mensagens em memória para atender requisitos de performances que aceitavam abrir mão da garantia de persistência em caso de falha do servidor.

Altíssima Disponibilidade

 

A grande maioria das aplicações corporativas são desenvolvidas para que estejam constantemente disponíveis, seja para atender uma grande rede de consumidores, seja para suportar um grande volume de transações ou para atender demandas oriundas de regiões distintas do globo, garantir a disponibilidade esperada é muito mais complicado na prática do que na teoria.

Todo desenho da solução Tuxedo leva em conta equipamentos de arquitetura distinta, coordenação de transação distribuída, localização remota de servidores/serviços, persistência de informação e distribuição de comunicação.

Um exemplo básico da arquitetura de alta disponibilidade diz respeito a comunicação entre máquinas. O administrador do ambiente pode definir a maneira como os servidores do cluster devem se relacionar quanto a comunicação de rede, uma das características é a ativação de canais paralelos de comunicação entre máquinas, sempre que uma máquina enviar pacotes para outra máquina, ela utilizará em paralelo placas de redes e/ou infraestrutura de redes distintas, garantindo que a mensagem enviada alcance seu destino da melhor forma possível, ultrapassando possíveis dificuldades de infraestrutura.

Indisponibilidade de sistemas é algo muitas vezes negligenciado, 99,99% de disponibilidade significa uma indisponibilidade superior a 52 minutos em um ano, para uma operadora de cartões de crédito que processa algo em torno de 400 transações por segundo, significa a perda de 1.248.000 transações, agora multiplique isso pelo valor médio das compras e é possível chegar no impacto financeiro da indisponibilidade. Aplique esse exemplo para o volume de transações que originou o Tuxedo, 1.000 transações por segundo, são 3.120.000. Por fim, multiplique esse tempo de indisponibilidade por 50.000.000 transações por segundo (156.000.000) e não estou falando de um caso hipotético, existe relatos de clientes com performance muito superior a essa.

Ambientes Tuxedo desenhados corretamente e administrados da maneira correta tendem a alcançar 99.999% de disponibilidade, o que significar uma indisponibilidade máxima de pouco mais de 5 minutos ao ano, sem dúvida uma prazo administrável.

 

Performance Imbatível

 

Quando o assunto  é performance novamente estamos falando de Tuxedo, serviços são desenvolvidos para operar na escala de nanosegundos, comunicação é desenhada para ser super performática, assim por diante.

Velocidade é algo tão marcante que é esperada para as próximas versões do produtos a capacidade de definição de limite de tempo de resposta (timeout) na escala de nano segundos, não cabe mais esperar um segundo por um serviço que leva 30 nanosegundos para executar.

Para colocar o termo “performance imbatível” em um novo patamar, em Dezembro de 2010 foi anunciado o recorde mundial de transações por minuto pela Oracle, utilizando Tuxedo e hardware Exalogic, o recorde anterior do mês de agosto do mesmo ano era da IBM com um valor próximo a 10 milhões de transações por minuto, a Oracle conseguiu junto com o Tuxedo o módico valor de mais de 30 milhões de transações por minuto. Vale ressaltar que esses testes seguem uma metodologia e são certificados, ou seja, a comparação entre eles é válida.

É muita pretensão querer colocar tudo sobre Tuxedo em uma única postagem, dessa forma, nos próximos posts teremos mais sobre esse produto…

 

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.