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.EXE” Server, 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.
Para receber os artigos do Blog Magic Brasil em primeira mão no seu email, registre-se aqui