Cluster com Magic xpa Server e GigaSpaces

Veja como montar um cluster de servidores de aplicações (Enterprise, RIA ou Web) com o Magic xpa

e GigaSpaces, e aproveite o melhor do Load Balance e Fail Over na plataforma Magic.

Há algum tempo atrás, publicamos um artigo que mostrava como usar e como montar um cluster de servidores Magic xpi 4x.

Acabou por não ser muito comentado depois disso, mas desde o lançamento do Magic xpa 3, quando toda a plataforma Server* do xpa passou a contar com o GigaSpaces como mais uma opção de middleware, o Magic xpa também ganhou o recurso de formatação em cluster nas suas instalações:

*Nota: Magic xpa Enterprise Server, Magic xpa RIA Server e Magic xpa Web Server.

 

E agora, vamos ver como como tornar uma instalação ‘simples‘ de Magic xpa + GigaSpaces em um ambiente ‘clusterizado‘ de Magic xpa + GigaSpaces.

 

Nosso exemplo será baseado em uma topologia de 2 máquinas (servidores) + o Magic xpa Enterprise Server (licença MGENT1) 4.7 64Bits*.

*Nota: Funciona com qualquer versão a partir da 3x, incluindo as de 32Bits.

 

Nós teremos 2 servidores, o “FZDELL(Server 1, Win-10) e o “MSBJACWIN764(Server 2, Win-7):

 

Em cada um dos servidores (individualmente), nós temos uma instalação do Magic xpa Enterprise Server 4.7 64Bits:

*Nota: Cada máquina precisa ter uma licença válida do Magic xpa. Como o site de ativação de licenças "Server" permite informar até 2 HOSTIDs, você pode ativar a mesma licença para ambos os servidores, por exemplo.

 

Na pasta “GigaSpaces-xpa\bin” da instalação do Magic xpa tem um arquivo chamado “setenv.bat“, que precisaremos editar:

*Nota: Esta edição tem ocorrer, neste caso, nas duas máquinas

 

Nele, precisaremos alterar as configurações de “DISCOVERY_PORT“, “LRMI_PORT_RANGE” e “XAP_LOOKUP_LOCATORS“:

 

Devemos “descomentar” as linhas “DISCOVERY_PORT” e “LRMI_PORT_RANGE” para fixar as portas de comunicação a utilizar.

Além disso, “XAP_LOOKUP_LOCATORS” tem o nome da máquina da instalação (por padrão). Para um cluster, precisamos listar (separadas por vírgula) as máquinas que fazem parte deste cluster e que tem o GS LUS habilitado nelas. No nosso caso, são as duas: FZDELL , MSBJACWIN764

Em última análise, é esta a configuração que faz as máquinas se “enxergarem” umas às outras para formar o cluster.

*Nota: Todas as portas configuradas (ex: 4174, 7102-7120) precisam estar liberadas no firewall das máquinas envolvidas, para fluir a comunicação entre elas.

 

Desta forma, quando o serviço do GigaSpaces é iniciado nos dois servidores, eles “se encontram” e formam um único IMDG:

*Nota: A tela do Management Center (Console do GigaSpaces), em qualquer dos servidores, mostrará a mesma topologia.

 

Então agora temos 2 servidores trabalhando em conjunto, como se fossem um só.

Outra configuração que iremos ajustar, é a inicialização automática de aplicações (Enterprise, RIA ou Web).

Na pasta “GigaSpaces-xpa\config” tem um arquivo de nome “projectsStartup.xml” que é onde configuramos as aplicações que devem ser carregadas e servidas automaticamente quando o GS é iniciado na máquina.

Nós vamos definir uma aplicação de carga inicial automática, e na seção <Servers> deste arquivo, vamos enumerar em quais dos servidores do cluster desejamos que tenha um runtime xpa (Enterprise Server, RIA Server ou Web Server) “servindo” esta aplicação:

*Nota: Esta edição tem ocorrer, neste caso, nas duas máquinas

 

Isto é chamado “SLA“. Nós estamos pedindo ao GigaSpaces que mantenha (neste exemplo) uma instância do Magic xpa Server na máquina “FZDELL” e também uma na máquina “MSBJACWIN764“, para atender demandas da aplicação que nomeamos como “SimpleRESTService“.


Podemos confirmar este SLA programado, tanto pelo “Process Explorer” de ambos os servidores:

quanto pelo próprio Magic xpa GigaSpaces Monitor do xpa:

 

Porque um Cluster?

Todo programa Magic xpa que executa em um Enterprise Server, RIA Server ou Web Server é um rotina que que precisa consumir tempo e CPU, memória RAM e recursos externos (File Server, DB Server, conexões internet/intranet e etc…). Com um cluster, nós estamos falando de escalabilidade horizontal da plataforma, e podemos destacar 2 de seus benefícios:

Load Balance: é a distribuição da carga de trabalho (execução das rotinas/programas) entre as máquinas participantes deste cluster. Isso é automático no GigaSpaces. Como toda demanda de execução de rotinas (requisições) passa antes por ele, o GS vai analisar e direcionar para, dentre as máquinas capazes de atender àquele pedido, a que parecer em melhor condição de dar a resposta mais rápida.

Fail Over: Neste exemplo, temos 2 servidores atuando. Caso ocorra problema em um deles o outro pode seguir atendendo as demandas que chegam, ainda que com menor capacidade de resposta (menor performance), enquanto este primeiro tem seu problema sanado e volta a juntar-se ao cluster novamente.

 

Testando o Cluster

Vamos testar o Load Balance do nosso cluster, de forma simples, mas eficiente.

Criamos uma aplicação chamada “SimpleRESTService“, e nela, um programa (batch) chamado “getServerTime“:

 

Como vimos, ela está debaixo de um “MgxpaRutime.EXEServer, em cada uma das duas máquinas.

Por padrão, ambas as máquinas possuem também um IIS:

 

onde o Magic xpa (InstallShield dele) instalou um web Alias que dá acesso ao seu Web Requester (MgWebRequester.DLL):

 

Mas nós precisamos de um somente, não de dois. Então vamos escolher para nosso plano de testes o da máquina MSBJACWIN764, que é o servidor mais “fraco” do nosso cluster.

*Nota: O IIS da outra máquina (FZDELL) não será usado aqui.

 

O nosso programa de testes (getServerTime) é muito simples, e quando ele é chamado já retorna imediatamente devolvendo a data/hora da máquina e também (importante aqui) seu nome e versão do seu SO:

 

Então como já temos:

Servidor IIS: MSBJACWIN764

Web Alias Magic xpa: Magic47x64Scripts

Aplicação Magic xpa: SimpleRESTService

Programa Magic xpa: getServerTime

Formamos a url abaixo:

http://MSBJACWIN764/Magic47x64Scripts/MgWebRequester.dll?appname=SimpleRESTService&prgname=getServerTime

para acessar este programa (executá-lo e obter seu retorno).

 

Por fim, em um loop de 60 segundos, vamos continuamente invocar este programa (sequencialmente mesmo), e confirmar que resposta recebemos.

Este é o nosso código de testes:

 

e esta foi a saída da execução:

 

Podemos ver que algumas das chamadas foram atendidas pelo Magic xpa Enterprise Server que rodava na máquina FZDELL (Win10 6.2), enquanto outras foram pelo Magic xpa E/S da máquina  MSBJACWIN764 (Win7 6.1), quase numa proporção* de 50% a 50%.

*Nota: Esta não é uma regra fixa. O algorítmo de balanceamento do GS é afetado por muitas variáveis, como carga comprometido da RAM e CPU de cada servidor.

 

No Magic xpa GigaSpaces Monitor do Magic, também podemos verificar esta distribuição:

 

E assim podemos comprovar o Load Balance em ação.

Caso uma das duas máquinas fosse removida do cluster, os consumidores da aplicação seguiriam sendo atendidos.

 

Manoel Frederico Silva – Gerente de Tecnologia e Evangelista MAGIC – Magic Brasil
Manoel Frederico Silva – Evangelista MAGIC – Magic Brasil

 

Para receber os artigos do Blog Magic Brasil em primeira mão no seu email, registre-se aqui

Deixe um comentário

O seu endereço de e-mail não será publicado.