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.
![Manoel Frederico Silva – Gerente de Tecnologia e Evangelista MAGIC – Magic Brasil](http://www.repullo.com.br/blogmagic/wp-content/uploads/2015/02/fred21-150x150.jpg)
Para receber os artigos do Blog Magic Brasil em primeira mão no seu email, registre-se aqui