A solução In-Memory Data Grid computing (IMDG) é cada vez mais utilizada por empresas para implantação de um recurso computacional rápido e robusto. Tendo sido anteriormente utilizado apenas por grandes companhias, como instituições financeiras e gigantes da internet, os custos da tecnologia, atualmente, foram reduzidos ao ponto que a solução pode servir de apoio à integração de aplicativos de empresas. As soluções In-Memory Data Grids são a forma ideal para garantir a transmissão de mensagens em projetos de integracão, com menor latência, capacidade para alto volume de transações e facilitadores para ambientes distribuídos. Clustering, Recuperação, Escalabilidade e Gerenciamento são tópicos abordados nessa sessão, para ajudar seu projeto de integração se tornar ainda melhor.

1. Arquitetura IMDG (In Memory Data Grid) do
Magic xpi 4
Magic Sem Segredos – S1E4 – 24 Janeiro 2014

2. Agenda
Magic Sem Segredos
• Magic Software
• Nova Arquitetura do Magic
•
•
xpi
Magic em Ação
Perguntas e Respostas
(Comentários do Blog)
http://mss.magicsoftware.com.br

3. Magic Software
Um fornecedor global de plataformas de desenvolvimento e integração
de aplicações
• 30+ anos de Experiência
• Destaque em Tecnologia e
Inovação
• Foco em Necessidades de
Negócios
•
•
•
•
NASDAQ (MGIC)
14 Escritórios mundialmente
Presente em mais de 50 países
Parceiros +3.000

4. Plataforma de Integração Magic xpi 4

5. Revisão Inicial da Versão iBOLT 3
– Fase Concluída
Melhoria na
tolerância a falhas,
recuperação de erros,
escalabilidade e
performance

6. Segunda Revisão – Fase em
Andamento
Novas capacidades e
novos adaptadores
Inclusão capacidades
BAM e Monitoramento
Visual
Abertura e suporte para
padrões

7. Capacidades Básicas Existentes –
Magic xpi 4.0
Biblioteca de
conectores préconstruídos
Adaptadores prontos de protocolos empresariais com os principais
fornecedores de TI (SAP, Salesforce, Oracle, Microsoft ..) para onpremise, nuvem e integração de aplicações e dados móveis
Livre de Código /
GUI Intuitiva
Sem necessidade de códigos e desenvolvimentos complexos – uma
única interface gráfica intuitiva visual (mapeador de dados, ...)
Outras
capacidades
técnicas
Tecnologia e vendedor agnóstico, classe empresarial (segurança
embutida), SOA compatível, ....
Viabilizadores do
Sucesso da
Integração
Grande rede de parceiros, serviços profissionais, 30 anos de
experiência

8. Novas Capacidades do
Magic xpi 4.0
Clustering
Capacidades
Prontas para
clustering e
Tolerância a
Falhas
(failover)
Recuperação
Melhoria na
Recuperação
de erros e
Garantia na
Entrega de
Mensagens
Escalabilidade
Gerenciamento
Escalabilidade
Elástica e
Processamento
Paralelo
Melhores
facilidades no
sistema de
Gerenciamento

9. Benefícios do Magic xpi 4.0
Magic xpi 4.0 traz recursos prontos em nível premium de
robustez, normalmente difíceis de implantar e oferecida apenas a grandes
projetos, possibilitando novos cenários de integração para
mobilidade, nuvem e big data
Capacidades de
Robustez
premium
Disponibilidade 24/7 embutida via
clustering, escalabilidade, gerenciamento melhorado
Baixo Custo de
Propriedade
(TCO)
Automatizado, pré-construídos, as novas capacidades diminuem
ainda mais o custo total de propriedade da Solução Magic
Livre de Risco
100% Compatível com versões anteriores, sem habilidades
específicas de TI necessários – Sem alteração no
Desenvolvimento
À Prova de
Futuro
A nova arquitetura do Magic xpi 4.0 facilitada futuros cenários de
integração com baixa latência (mobilidade, nuvem, big data)

10. Magic em
Ação
Coloque suas perguntas
nos comentários do Post no
Blog para respondermos ao
vivo

11. Arquitetura baseada em
Space

12. Arquitetura tradicional baseada
em camadas
• Foi construída sob o pressuposto de que a
•
capacidade de rede é um gargalo e
memória é cara e limitada
• Uso intensivo de I/O
• Não distribuído por natureza, pois a rede
foi assumida como sendo um gargalo
Complicado para Escalar
• Todos os níveis precisam de escalar
juntos
• Cada camada é um middleware com
hardware
dedicado, licenciamento, protocolos, API
s ...

13. Arquitetura Baseada em Camadas
– Continuação

14. Solução Dispatcher (Broker)
•
•
•
•
•
Ponto único de falha
Status e Controle Centralizados
Todos os táxis devem se registrar
Dispatcher precisa ser bem organizado e
ordenado
Os passageiros podem desaparecer se o
táxi não estiver disponível

15. Arquitetura Baseada em Space
• Middleware é virtualizado
• Tanto a lógica de aplicação quanto a camada de
mensagens são executadas em cada partição
juntamente com os dados
• Os dados são armazenados em memória
• Ultra rápido, baixa latência de acesso
• Os dados são particionados entre os processos
• para suportar grandes conjuntos de dados
• Os dados são replicados para fornecer resiliência
• A perda de uma partição não afeta os dados

16. Arquitetura Baseada em Space Continuação

17. Solução em Space
• Nova área de espera
• Escalável - novo táxi
•
•
•
•
pode se juntar
facilmente
Sem dispatcher, Sem
ponto único de falha
Pode deixar sua Mala
e ir (assíncrono)
Área de Espera é
protegida e segura
(sem desaparecimento
de malas)
Entrega garantida

18. Conceitos do GigaSpaces XAP

19. Conceitos Básicos do GigaSpaces
XAP
• In-Memory Data Grid - Software middleware
composto por vários processos de servidores
que trabalham em conjunto para armazenar e
processar grandes quantidades de dados em
memória
• Space – um serviço de lógica em
memória, em execução na grade de dados
(data grid), que pode armazenar entradas de
informação

20. Topologias Space clustering
• Particionado:
• Replicado:
• Ambos:

21. Arquitetura Magic xpi 4.0

22. Arquitetura do Magic xpi 4.0 Conceitos
• Magic Space
• Um space que contém parte da lógica do Magic
xpi
• Workers
• Threads genéricas num processo de Magic xpi
que executa qualquer fluxo do projeto.
• Constantemente em execução e predefinidos
na inicialização do servidor.
• Metadados do Projeto no Space
• Os metadados do projeto que são gerenciado
no space.
• Unidade de Processamento (PU)
• A lógica que é executada no Magic Space

23. Nova Arquitetura do Magic xpi 4.0
Magic xpi 4.0 é construído sobre de uma tecnologia In-Memory
Data Grid, que substitui o Magic Broker e fornece tolerância a
falhas, redundância e escalabilidade
Múltiplos Servidores – Múltiplos Motores – Múltiplos Workers
Servidor
ServerServidor Servidor Servidor
Gerenciamento
e
Monitoramento
Motor
Magic Engine
Magic Engine
Magic Engine Magic Engine Magic
Space
(In-Memory Data Grid)
23
Magic PU

24. Arquitetura Magic xpi 4.0
Escreve
Lógica (PU)
Motor Magic xpi 4.0
Lê/obtém
Gerenciador
Metadados dos Servidores
Metadados do Projeto
Mensagens
do Work
Triggers
Mensagens do
Gerenciador
Worker
Worker
Worker
Escreve
Triggers
Externas
Entidades
Compartilhadas

25. Workers
• Threads Genéricas que são executadas
sob um processo do Magic xpi
• Sua quantidade é predefinida na
worker
inicialização do servidor
• Define a quantidade máxima de processos
paralelos que o servidor Magic xpi pode ser
executar
• Pode executar qualquer fluxo do projeto
• Pode executar qualquer ramo paralelo ou stand-alone
• Constantemente buscando novas mensagens no
space
• Atualiza o objeto de metadados correspondente no
space com o status estou-vivo. (I’m-alive)

26. Gerenciador de Threads
• Uma thread em execução sob o processo do
•
•
•
Magic xpi
Manipula mensagens de comando:
• Encerramento (Shutdown)
• Workers status
Monitora a saúde dos workers
Recupera workers com falha.
Gerenciador

27. Mensagem de “Work”
• Uma mensagem armazenada no space
• Contém instruções de execução do fluxo
•
(BP/fluxo)
Colocado no space por:
•
•
•
•
Mensagens do
Triggers
Work
Scheduler
Auto-Start, Auto-Repeat, PSS
Ramos Paralelos ou stand-alone
• Seu ciclo de vida passa por vários estados de
•
"Pronto para uso" para "em andamento" para
"Falha" ou "Concluído”
Mensagem de Root é removida do space
apenas após um processamento bem
sucedido

28. Magic Space PU
• A lógica do Magic xpi que é executada em
•
cada partição do space
Responsável pela:
• Inicialização e Encerramento do Projeto
• Recuperação
• Monitoração da Saúde do Projeto
• Transformação de Mensagens (triggers
externos)
Lógica (PU)

29. Triggers externas
• Triggers que não estão rodando sob um
•
•
processo do Magic xpi:
• Web Requester (IIS)
• Provedor de Web Service (WSo2)
Coloca Mensagens do Work no Space
Espera por mensagens de respostas
Triggers
Externa
s

30. Entidades Compartilhadas
• Entidades do Space
• Todas as entidades usadas no vínculo com
um projeto Magic xpi a um único servidor:
•
•
•
•
•
Locking
Max Instance
Global and BP variables
Disableenable
Recovery information
Entidades
Compartilhadas

31. Entidade de Metadados
• Entidades do Space
• Estas entidades são a representação do
space das entidades de processos do Magic
xpi:
• WorkerData, ServerData, FlowData, TriggerDat
a, ProjectData….
• Estas entidades do space são parte do es
• Apenas estas entidades do space controlam
•
o status do projeto (Motores são sem status)
Usado pelo Monitor para ganhar visão em
tempo real do projeto.
Metadados

32. Execução do Projeto

33. GSA como agente inicializador do
Magic xpi
• Também é um agente de gestão de processos
• Pode facilmente gerenciar outros processos
• Pode ser totalmente controlado a partir da Admin
API
• Confiável e robusto
• Pode ser exposto como um serviço do SO

34. Configurações de Inicialização
• Definido em um arquivo XML
• O nome do arquivo é controlado por uma
propriedade no Magic.ini
• O processo de build cria um XML padrão de
início na pasta do projeto
• O Monitor, o Debugger e o “Start link” usam
este XML.

35. Configurações de Inicialização Continuação
<Magicxpi_Startup xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Projects>
<Project Name="recoveryExample" ProjectsDirPath=“Magic xpi 4 GS
22_11projects">
<Servers>
<Server host="AVIW-7-LP">
<NumberOfWorkers>5</NumberOfWorkers>
<NumberOfInstances>1</NumberOfInstances>
<Triggers load="true"/>
<Scheduler load="true"/>
<AutoStart load="true"/>
</Server>
</Servers>
</Project>
<Magicxpi_Startup/>

36. Arquitetura do Processo de
Inicialização
Monitor
Debugger
Start Link
Ma
XML
ServerData
ServerData
ServerData
Magic PU
GSA
GSA
Magic
xpi
Magic
xpi

37. Processo de Encerramento
(Shutdown)
• Operação de desligamento do projeto cria uma mensagem
de "shutdown project" no space. Como resultado:
• Mudanças de estado do projeto para estado de
desligamento
• Triggers estão bloqueando novas mensagens
• A mensagem de desligamento é distribuída a todos os
servidores que executam (mensagem de gerenciamento)
• A PU monitora o estado dos servidores em execução e
garante que eles desligarão corretamente após um período de
carência
• O tempo de carência permite que os servidores completem
quaisquer mensagens novas ou em processo no space
• Se um servidor não conseguiu desligar, ele vai ser
eliminado pelo GSA

38. Mecanismo de
Licenciamento

39. Atualização de Licença
• Magic xpi 4.0 não funciona com licenças da
V3
• Clientes precisam atualizar a licença para a
v4
• A nova licença contém versão MAGIC 2.000
e um flag VERSION=4.0 como parte do
vendor String

40. Nova Arquitetura de
Licenciamento
• Licença é sempre flutuante, mas com a opção de
•
•
•
•
reservar licenças a um determinado projeto
O pool de licenças é feito no space que serve
como servidor de licença
Workers antes de executar um fluxo, vai tentar
fazer o check-out de uma licença da pool
No caso de o projeto estar definido para reservar
licenças, alguns de seus workers irão verificar
licenças no pool e nunca vão liberá-los.
O restantes dos workers vão tentar fazer o checkout de uma licença e farão o check-in da licença
uma vez que o fluxo tenha terminado (flutuante)

41. Monitor - Licenças
• A partir do menu de “Ajuda” da visão de
•
vários projetos, é possível ver a licença
carregada no space.
A partir do console de monitoramento
avançado, é possível ver o seguinte:
• Uso total de licenças
• Fixed / floating
• License feature usado por cada Servidor

42. Execução em Cluster

43. Migração

44. Plano de Migração
• Ver documentação de migração
• Não há alteração em desenvolvimento, somente na execução
• Migração suave & tranquila – Rebuild do Projeto

45. Perguntas e Respostas

46. Obrigado e até o próximo
http://mss.magicsoftware.com.br