(agora com GigaSpaces)

Desde a chegada do Magic xpi versão 4, agora integrado ao GigaSpaces (XAP 9.1.2) – uma plataforma ‘cloud ready’ para aplicações (In-Memory DataGrid, Big Data, Clusters, etc…) – algumas novidades relativas a configurações passaram a exigir nossa atenção.

(veja este post sobre o Magic xpi 4) 

Uma delas é possibilidade de se montar um cluster de servidores. Um cluster significa ter duas ou mais máquinas trabalhando juntas como se fosse uma só.

As vantagens mais evidentes desta configuração são:

• Multiplicar a capacidade de processamento e dividir a carga entre todos os participantes do cluster (também chamado: load balance).
• Permitir que o sistema continue on-line. Em caso de falha de alguma das máquinas, as outras participantes do cluster devem seguir atendendo normalmente (também chamado: fail over).

Vamos verificar abaixo como montar/configurar um cluster de servidores Magic xpi versão 4.

Recomendamos utilizar a versão 4.0a ou superior, pois ela possui uma configuração facilitada.

Vamos a título de exemplo, montar um cluster (ou grid) de três servidores chamados: FZNOTE, Win764VMVBOX e WIN7GRID1.

Pré-Requisitos

 

• As máquinas participantes do cluster devem poder se “enxergar” umas as outras. Por isso, melhor que estejam na mesma rede.
• Elas precisarão conversar entre si via canal TCP. Então, não deve haver firewalls bloqueando as conexões entre elas.
• Deve existir uma pasta de rede (compartilhada) que seja acessível a todas as máquinas do cluster.
• Deve existir um logon (usuário) com acesso de leitura e escrita nesta pasta compartilhada. Este usuário será usado para executar o serviço do Magic xpi Agent. Pode ser um único usuário do domínio, ou um usuário específico de cada máquina. O importante é que ele também faça parte dos Administradores da máquina, para que além de acesso à pasta compartilhada também não restrição de acesso a algum recurso do próprio servidor.
• Cada máquina do cluster precisa ter a sua própria licença de Magic xpi. Não é possível utilizar uma mesma licença em mais de uma máquina, mesmo dividindo as threads entre elas.

 

Instalação

 

O Magic xpi deve ser instalado em cada máquina separadamente. Como se fossem instalações individuais. Isso inclui o seu próprio WSO2 (SystInet) e o seu banco de dados interno. E claro, a sua licença ativada.

Porém, no Unicast Locators você deve informar todas as máquinas que participarão do cluster. E também deve deixar assinalada a opção LUS:

 A lista de máquinas pode ser informada pelo seu nome ou pelo seu número IP. O IP é preferível, desde que ele seja estático (não mude a cada reinicialização da máquina).

NOTA: muitos LUS afetam a performance geral do grid. Num cluster de 5, 10 ou mais servidores, você pode deixar o LUS em apenas 2 ou 3 destas máquinas, se desejar.

É importante que se utilize as mesmas configurações no grupo Space Deployment do instalador, para que o arquivo <xpi4Home>\config\magicxpi_sla.xml fique igual em todas as máquinas.

Novamente: esta instalação deve ser repetida em cada uma das máquinas.

 

Configuração

 

Finalizada a instalação do Magic xpi nas máquinas do cluster, alguns arquivos precisam ser editados.

Os arquivos:

<xpi4Home>\MAGIC.INI

<xpi4Home>\MGREQ.INI

<xpi4Home>\scripts\config\MGREQ.INI

<xpi4Home>\GigaSpaces\bin\magicxpi-setenv.bat

devem todos possuir o mesmo conteúdo referente a LookupLocators e LookupGroupName:

O arquivo:

<xpi4Home>\GigaSpaces\bin\magicxpi-gs-agent.bat

deve ser ajustado para:

gsa.global.gsm N // onde ‘N’ é o total de máquinas no cluster

gsa.mgdeploy 0

Os ajustes nestes arquivos devem ser realizados em todas as máquinas do cluster. É importante que todas elas possuam estas mesmas configurações.

NOTA: nesta abordagem (gsa.mgdeploy 0) é preciso aguardar até que o grid esteja ‘pronto’ (todas as máquinas participantes tenham subido e se conectado), para então fazer o deploy manual do MAGIC_SPACE (Magicxpi_deploy.bat). Para manter tudo “automático”, deixe (gsa.mgdeploy 1). A primeira máquina do cluster terá sucesso neste ‘deployment’, as demais acusarão erro em seus logs (já que o deploy só pode ser feito uma vez), mas estes erros podem ser tranquilamente ignorados.

O serviço do GSA (Grid Service Agent) deve ter suas credenciais ajustadas cfe. descrito anteriormente: usar um usuário que tenha acesso irrestrito à pasta compartilhada e também aos recursos da máquina onde ele está rodando:

Pode até ser o LocalSystem, desde que garantidas as premissas acima.

Como já dito, deve existir uma pasta compartilhada acessível a todas as máquinas participantes do cluster:

Nesta pasta, serão copiados todos os projetos que se deseja executar nesta arquitetura. Neste exemplo, o projeto “WSOnClusterCheck” está copiado na pasta compartilhada “\\FZNOTE\SharedProjects”. Todos os projetos que se deseja executar no cluster, devem ser copiados para esta pasta.

Após a cópia, em cada um dos projetos deve ser realizado um ajuste no arquivos Start.lnk e Start.xml:

No arquivo Start.lnk, deve-se informar o caminho compartilhado do Start.xml. Ex:

<…>MgxpiCmdl.bat start-servers -startup-config-file “\\FZNOTE\SharedProjects\WSOnClusterCheck\start.xml” -space-name “MAGIC_SPACE”

No Start. xml, deve-se informar em quais servidores do cluster se deseja executar o projeto, além de qual a pasta compartilhada que está sendo utilizada. Ex:

Podemos definir para alguns projetos executarem em apenas alguns dos servidores, ou para todos executarem em todos os servidores.

Novamente: esta revisão deve ser aplicada em todos os projetos copiados para este local compartilhado.

Por último, e não menos importante, o arquivo <xpi4Home>\IFM.INI precisa ser ajustado também. A chave “MPSProjects” da seção [MAGIC_IBOLT] e a chave “projects” da seção [MAGIC_LOGICAL_NAMES] precisam apontar para a pasta compartilhada descrita acima. Observe que uma termina com “\” e a outra, não:

Lembrando: este ajuste deve ser em todos os IFM.INI das instalações dos Magic xpi participantes do cluster.

 

Inicialização

 

Finalizada a configuração do Magic xpi nas máquinas do cluster, os serviços do GSA (Grid Service Agent) podem ser iniciados em todas elas:

Usando-se o GigaSpaces UI, podemos verificar que o IMDG foi criado com a união de todas as máquinas participantes do cluster:

Isto é porque elas compartilham os mesmos valores de LookupLocators e LookupGroupName. E obviamente, porque conseguem se enxergar na rede.

Em qualquer das máquinas do cluster em que se abrir o GigaSpaces UI:

será exibida a mesma estrutura do IMDG.

 

Entendendo o MAGIC_SPACE

 

Ter o IMDG montado, não é suficiente para poder se executar os projetos Magic xpi. É preciso que haja uma entidade chamada MAGIC_SPACE montada (deployed) dentro do IMDG.

Isso normalmente é uma ação automática, por conta com comando “gsa.mgdeploy 1” que existe no arquivo <xpi4Home>\GigaSpaces\bin\magicxpi-gs-agent.bat.

Mas como visto acima, nós reajustamos este comando para: “gsa.mgdeploy 0”. E o motivo é o seguinte:

No momento em que o MAGIC_SPACE é montado (deployed), ele só reconhece as máquinas que estão no cluster naquele momento. No nosso exemplo, se no deployment do MAGIC_SPACE somente as máquinas FZNOTE e WIN7GRID1 tivessem concluído a sua inicialização do GigaSpaces, a estrutura ficaria assim:

As máquinas que entrassem depois seriam ignoradas. Existem duas maneiras de se resolver essa situação:

A)     Deixar uma das máquinas do cluster com “gsa.mgdeploy 1” e garantir que ela entrará por último no cluster.

B)      Deixar todas as máquinas com “gsa.mgdeploy 0” e montar (deploy) o MAGIC_SPACE manualmente.

Neste nosso exemplo, optamos pela “B”.

Todos os arquivos <xpi4Home>\GigaSpaces\bin\magicxpi-gs-agent.bat já foram definidos com “gsa.mgdeploy 0”.

Agora temos duas opções:

O menu GigaSpaces Deployment:

Ou o arquivo de comando <xpi4Home>\GigaSpaces\bin\Magicxpi_deploy.bat:

Observe que após o deployment, os contêineres que formam o MAGIC_SPACE se espalham entre todas as máquinas do cluster:

Isso só ocorreu porque todas as máquinas já estavam no cluster na hora da montagem do MAGIC_SPACE.

 

Execução

 

Finalizada a montagem do cluster e do MAGIC_SPACE, os projetos já podem iniciar a executar nesta estrutura.

Como já mostrado em outras oportunidades, um projeto Magic xpi versão 4 pode iniciar a executar de 4 formas diferentes:

• Através da opção debugger do Magic xpi Studio.
• Através do atalho Start.lnk do projeto.
• Através do botão START do Magic xpi Monitor.
• Automaticamente

Para iniciar automaticamente, todos os projetos devem estar listados no arquivo <xpi4Home>\config\projectsStartup.xml:

Mas é importante observar que o “projectsStartup.xml” que interessa é o que está localizado na máquina que montou o MAGIC_SPACE (seja de forma manual ou não), pois é no momento do deployment do MAGIC_SPACE que este arquivo xml é lido.

Em nosso exemplo, vamos escolher a 3a. opção:

Observe que como o Start.xml deste projeto define que deve haver um Magic xpi Server em cada uma das três máquinas do cluster:

então temos efetivamente um processo MgxpiServer.exe em cada uma destas máquinas, dedicados a executar fluxos deste projeto:

E assim se repetiria para cada um dos projetos salvos na pasta compartilhada, cfe. as configurações do seu Start.xml e/ou projectsStartup.xml. O total de processos MgxpiServer.exe será então a soma das instâncias, de todos os servidores atribuídos a todos os projetos:

Na configuração acima, temos então um MgxpiServer.exe em cada uma das três máquinas do cluster, todos dedicados ao projeto “WSOnClusterCheck”. Cada um destes MgxpiServer.exe pode atender no máximo 10 requisições simultâneas. Vale o que for menor: o número de Workers definidos por processo MgxpiServer.exe, ou o número de threads na licença em uso. As requisições que excederem este limite, ficam “em fila” aguardando oportunidade para serem atendidas.

 

Testando o Cluster

 

Relembrando os propósitos de um cluster com Magic xpi versão 4, descritos lá no início, vamos analisar este pequeno projeto exemplo. O projeto “WSOnClusterCheck” publica um webService SOAP simples:

que na sua resposta informa o nome da máquina que executou o fluxo:

Construiremos então um cliente (consumidor) para este webService. Veja que nesta configuração de cluster, nós possuímos três WSO2 (SystInet). Nós podemos ter todos on-line ou não.

É indiferente .

Não importa por qual WSO2 (SystInet) a requisição chegar. Ela irá gerar uma WorkMessage no MAGIC_SPACE, que será tratada por algum Worker de algum Magic xpi Server dedicado a projeto, em qualquer das máquinas onde ele esteja executando.

Seguindo em nosso exemplo, vamos encaminhar todas as requisições para um único WSO2 (SystInet): o que está na máquina FZNOTE.

Com todos os Magic xpi Servers a postos, ao executar este cliente (consumidor) do webService, teremos este resultado:

Cada demanda de execução do fluxo é direcionada para algum Worker em alguma das máquinas do cluster reconhecidas pelo MAGIC_SPACE, cfe. algoritmo interno.

Com este resultado, o load balance se comprovou.

Se removermos alguma das máquinas do cluster, como a Win764VMVBOX por exemplo:

 

O cliente do webService continua sendo atendido, agora pelas duas máquinas que restaram:

Com este resultado, o fail over se comprovou.