“Examinando os os IBM MQ Uniform Clusters"

Os IBM MQ Uniform Clusters resolvem uma fraqueza comum nos designs de clusters tradicionais: as aplicações conseguem reconectar-se após uma interrupção, mas não se redistribuem automaticamente de forma a manter a capacidade de consumo alinhada com a colocação de mensagens.

Num Uniform Cluster, os queue managers são configurados para se comportarem como um único serviço lógico. O IBM MQ utiliza então o balanceamento ao nível das aplicações para mover ligações de clientes em direção a uma distribuição uniforme, o que constitui a diferença fundamental em relação ao encaminhamento de mensagens num cluster tradicional.

Este artigo explica os conceitos fundamentais por detrás dos Uniform Clusters e aponta para um laboratório de referência, uma demo baseada em Docker mantida no GitHub onde é possível observar o comportamento do balanceamento.

1. O que este artigo aborda

• Porque existem os Uniform Clusters e como diferem dos clusters tradicionais
• As condições arquiteturais que requerem
• O que não resolvem por si só
• Onde executar o laboratório prático

2. Porque os Uniform Clusters são importantes

Para compreender os Uniform Clusters, é útil contrastá-los com o clustering IBM MQ tradicional.

2.1 Encaminhamento em clusters tradicionais

Num cluster tradicional, o balanceamento de carga incide principalmente sobre o encaminhamento de mensagens.

Se uma aplicação ligada ao QM1 abre uma cluster queue como APP.QUEUE, o IBM MQ decide para onde vai cada operação de put. Se a queue existir tanto no QM1 como no QM2, as mensagens são distribuídas de acordo com as regras de workload do cluster MQ, resultando frequentemente numa divisão equitativa.

Isto parece correto até que a colocação dos consumidores muda.

Considere esta sequência:

1. Quatro consumidores estão ligados ao QM1 e quatro ao QM2.
2. O QM2 fica indisponível para manutenção.
3. Os seus consumidores reconectam-se ao QM1.
4. O QM2 regressa.
5. Os produtores começam a enviar metade das mensagens de volta para o QM2.

Nesta altura, todos os consumidores podem ainda estar ligados ao QM1, enquanto algumas mensagens residem agora no QM2. Essas mensagens ficam efetivamente retidas até que os consumidores se reconectem lá ou um administrador intervenha.

2.2 O que os Uniform Clusters mudam

Os Uniform Clusters resolvem isso ao re-balancear aplicações, não apenas mensagens.

Em vez de assumir que os consumidores acabarão por se reconectar ao lugar certo, o IBM MQ trabalha ativamente para distribuir de forma equitativa as aplicações cliente com capacidade de reconexão pelos membros do cluster. O balanceador regista quais as aplicações ligadas a cada queue manager e move-as uma a uma em direção a uma distribuição uniforme.

2.3 O que significa "balanceado" na prática

A definição de cluster balanceado no IBM MQ não é necessariamente uma divisão estritamente igual. Não avalie o balanceamento apenas pelo número bruto de ligações por queue manager. O BALANCED(YES) na saída do DISPLAY APSTATUS é o indicador que deve considerar.

3. Requisitos arquiteturais fundamentais

Os Uniform Clusters dependem de alguns pré-requisitos:

3.1 Configuração de auto-clustering

Duas stanzas do qm.ini conduzem a configuração automática de um queue manager num Uniform Cluster: AutoCluster e AutoConfig. Ambas são aplicadas a cada arranque do queue manager e são utilizadas com os Uniform Clusters.

AutoCluster define a participação no cluster. Os atributos Repository1Name e Repository2Name identificam dois repositórios completos que servem de pontos de contacto de bootstrap: um queue manager em arranque contacta-os para descobrir e aderir ao cluster. Qualquer um dos atributos pode nomear o próprio queue manager em arranque. Todos os queue managers do cluster partilham a mesma stanza:

AutoCluster:
   Type=Uniform
   ClusterName=UNICLUS
   Repository1Name=QM1
   Repository1Conname=QM1(1414)
   Repository2Name=QM2
   Repository2Conname=QM2(1414)

Quando um queue manager arranca com esta stanza, o IBM MQ cria automaticamente os canais de cluster necessários. Não são necessárias definições de canais manuais.

AutoConfig trata da aplicação automática de scripts MQSC e definições ini suplementares em cada arranque. Aceita um caminho para um ficheiro ou para um diretório onde todos os ficheiros .mqsc ou .ini são aplicados:

AutoConfig:
   MQSCConfig=/etc/mqm/config.mqsc
   IniConfig=/etc/mqm/config.ini
   ConfigTimeout=120

É assim que filas, canais e outros objetos são definidos de forma consistente em todos os queue managers do cluster, particularmente em deployments em containers onde a configuração tem de ser reproduzida a cada arranque.

O ficheiro MQSC referenciado por MQSCConfig tem de conter pelo menos uma definição de canal receptor de cluster (CLUSRCVR). Esta definição descreve como os restantes membros do cluster se ligam a cada queue manager e serve de modelo para ligar a qualquer membro. Um único ficheiro pode funcionar de forma idêntica em todos os queue managers através de variáveis de substituição que o IBM MQ resolve no arranque:

Um exemplo mínimo:

DEFINE CHANNEL('+AUTOCL+_+QMNAME+') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('+CONNAME+') CLUSTER('+AUTOCL+') REPLACE

Como +QMNAME+ é substituído em tempo de execução, o nome do canal é único por queue manager mesmo que o ficheiro seja partilhado. +AUTOCL+ e +CONNAME+ tornam igualmente genéricos o nome do cluster e o endereço de ligação.

ConfigTimeout define quanto tempo (em segundos) o queue manager aguarda pela conclusão da auto-configuração antes de aceitar ligações de aplicações. O comportamento por defeito é sem timeout: o queue manager não fica disponível enquanto todos os comandos de configuração não estiverem concluídos. A IBM desaconselha definir um timeout salvo quando necessário, pois as aplicações poderiam ligar-se antes de os objetos de que dependem existirem.

3.2 Criar os queue managers

Cada queue manager é criado com um único comando crtmqm que configura tudo no momento da criação. As flags referenciam os ficheiros definidos na secção 3.1:

Todos os queue managers do cluster usam um comando quase idêntico — apenas o nome do queue manager e o respetivo CONNAME diferem:

crtmqm -p 1414 -ii /shared/uniclus.ini -ic /shared/uniclus.mqsc -iv CONNAME=QMA.host(1414) QMA
strmqm QMA

crtmqm -p 1414 -ii /shared/uniclus.ini -ic /shared/uniclus.mqsc -iv CONNAME=QMB.host(1414) QMB
strmqm QMB

Quando cada queue manager arranca, o IBM MQ executa três passos automaticamente:

1. O ficheiro ini é aplicado ao qm.ini, adicionando a stanza AutoCluster.
2. O IBM MQ verifica se este queue manager está nomeado na stanza AutoCluster como um dos repositórios completos. Se estiver, converte-o em repositório completo (equivalente a ALTER QMGR REPOS(NomeCluster)); caso contrário, torna-se repositório parcial (ALTER QMGR REPOS(' ')).
3. Quando a definição do canal CLUSRCVR é processada, o IBM MQ define automaticamente canais sender de cluster deste queue manager para cada repositório completo na stanza AutoCluster (excluindo o queue manager local se ele próprio for um repositório completo). Os canais sender herdam os seus atributos do canal receiver de cluster local.

3.3 As ligações de cliente são obrigatórias

As aplicações têm de utilizar ligações de cliente sobre TCP/IP. Não podem participar no balanceamento do Uniform Cluster através de ligações locais porque estas fixam a aplicação ao mesmo espaço de processo que o queue manager, impedindo a movimentação transparente para outro queue manager.

3.4 As aplicações têm de suportar reconexão

O balanceador funciona desligando uma aplicação do seu queue manager atual e permitindo que se reconecte a um diferente. Para que isso seja transparente, a aplicação deve:

• Ser construída com o comportamento de reconexão ativado, por exemplo usando MQCNO_RECONNECT
• Ter um nome de aplicação definido, por exemplo através de MQAPPLNAME
• Manter as transações suficientemente curtas para que o cliente possa mover-se com segurança numa fronteira de transação

Se estas condições não forem satisfeitas, a aplicação pode ainda ligar-se e funcionar, mas comportar-se-á como uma ligação legada fixada e o balanceador não a moverá.

3.5 Client Channel Definition Table

As aplicações cliente ligam-se ao cluster através de uma Client Channel Definition Table (CCDT). A CCDT lista todos os queue managers do cluster para que o cliente tenha alternativas caso um queue manager fique indisponível. O exemplo abaixo mostra uma CCDT definida em JSON para um cluster de três nós:

{
  "channel": [
    {
      "name": "UNI.SVRCONN",
      "type": "clientConnection",
      "connectionManagement": {
        "defaultReconnect": "yes",
        "affinity": "none"
      },
      "clientConnection": {
        "connection": [
          {"host": "qm1-host", "port": 1414},
          {"host": "qm2-host", "port": 1414},
          {"host": "qm3-host", "port": 1414}
        ],
        "queueManager": "*UNICLUS"
      }
    }
  ]
}

Definir affinity como none garante que o cliente não se fixa ao primeiro queue manager ao qual se conecta, o que é necessário para que o balanceador o possa mover posteriormente.

4. Monitorização do balanceamento de aplicações

O IBM MQ disponibiliza o comando DISPLAY APSTATUS para observar o estado do balanceamento num Uniform Cluster. A documentação de referência completa está em Monitoring application balancing.

4.1 Vista ao nível do cluster

Execute este comando em qualquer queue manager do cluster para obter uma visão agregada:

DISPLAY APSTATUS('NomeDaAplicacao') TYPE(APPL) BALANCED CLUSTER COUNT MOVCOUNT

4.2 Perspectiva de queue manager

Execute este comando para ver o número de ligações e a mobilidade das instâncias num queue manager específico:

DISPLAY APSTATUS('NomeDaAplicacao') TYPE(LOCAL) CONNS MOVABLE IMMREASN IMMCOUNT

4.3 Porque é que uma aplicação não está a ser rebalanceada

Se BALANCED(NO) persistir ou MOVCOUNT for inferior ao esperado, verifique IMMREASN em cada queue manager. Os valores mais comuns são:

As causas mais comuns em novas implementações de Uniform Clusters são RECONNECT e APPNAME. Ambas indicam que a aplicação não foi construída ou configurada para participar no balanceamento. Consulte Applications not balancing correctly na documentação IBM MQ para a lista completa de códigos de motivo e passos de resolução.

5. O que os Uniform Clusters não resolvem sozinhos

Os Uniform Clusters melhoram a conectividade e o balanceamento das aplicações, mas não eliminam a fronteira de armazenamento entre queue managers.

Cada queue manager continua a ter os seus próprios dados de mensagens. Se o QM1 falhar, as aplicações podem reconectar-se noutro lugar, mas as mensagens persistentes que estavam apenas no QM1 ficam inacessíveis até que esse nó regresse ou uma tecnologia de alta disponibilidade separada proteja o seu armazenamento.

É por isso que os Uniform Clusters são frequentemente combinados com:

• Multi-Instance Queue Managers: duas instâncias do mesmo queue manager partilhando um sistema de ficheiros de rede, com failover automático
• Native HA: um grupo de queue managers com replicação tripartida onde um standby assume automaticamente

Os Uniform Clusters melhoram o balanceamento dos aplicativos no cluster. Não tornam, por si só, o armazenamento local de mensagens de cada nó instantaneamente disponível a partir de outros nós.

6. Executar o laboratório prático

Utilize o repositório de demonstração de Uniform Clusters no GitHub:

github.com/ibm-messaging/mq-uniform-clusters

O repositório inclui várias demos, inclusive a que nos interessa (https://github.com/ibm-messaging/mq-uniform-clusters/tree/master/demo/Docker) que arranca um Uniform Cluster de três nós e inclui aplicações cliente de exemplo para demonstrar o balanceamento.

7. Conclusão

Os clusters MQ tradicionais são eficazes no encaminhamento de mensagens ao nível da mensagem, mas deixam a colocação das aplicações largamente fora do âmbito do próprio cluster. Os IBM MQ Uniform Clusters fecham essa lacuna ao combinar clientes com capacidade de reconexão, identidade de aplicação e queue managers auto-agrupados numa plataforma de mensagens que reequilibra ligações à medida que o cluster se expande ou recupera de uma interrupção.

Isso torna os Uniform Clusters particularmente atrativos em ambientes elásticos como o Kubernetes, onde as alterações no layout da infraestrutura são esperadas e não excecionais.

8. Documentação IBM útil

• IBM MQ Uniform Clusters overview
• How automatic balancing uses automatic reconnect
• Influencing application re-balancing in uniform clusters
• Monitoring application balancing
• MQ clients: Client Channel Definition Table (CCDT)
• JSON CCDT examples
• IBM MQ Uniform Clusters GitHub repository