Maratona JBoss 2010 - JBoss AS Amazon EC2

1,737 views
1,624 views

Published on

Maratona JBoss 2010:
Estudo de caso sobre projeto Amazon EC2 (Elastic Compute Cloud).

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,737
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Maratona JBoss 2010 - JBoss AS Amazon EC2

  1. 1. Deploying JBoss AS on the Cloud Setembro de 2010 Fábrica de Software Sistemas e aplicações sob medida para as necessidades do seu negócio.
  2. 2. Amazon EC2 Amazon EC2 (Elastic Compute Cloud) IaaS – Infrastructure as a Service Elástico Controle completo (acesso de root) Flexível (hardware, SO, etc) Confiável (SLA de 99,95%) Seguro ● Firewall – Security Groups ● Amazon VPC Economia ● Baixo custo para demandas sazonais
  3. 3. Aplicação Envolvida Camada web desenvolvida usando Ruby on Rails Dois módulos desenvolvidos usando Java EE: Módulo de Acompanhamento – acessado via JavaScript via HTTP/REST e JSON Módulo de Lançamento - acessado pelo Módulo de Acompanhamento via JMS ● Filas para o processamento dos lançamentos Módulos totalmente stateless
  4. 4. Dimensionamento Estimativa de aproximadamente 150 mil usuários cadastrados Estimativa de carga muito alta durante alguns períodos do dia Durante os períodos de pico, foram estimados 100 mil usuário simultâneos Fora dos períodos de pico, os módulos Java EE não são acessados
  5. 5. Dimensionamento Elastic Compute Cloud Possibilidade de aumentar ou diminuir a capacidade de hardware de acordo com a variação da demanda durante o dia De alguns poucos servidores a até 200 servidores nos períodos de pico Redimensionamento automático do ambiente utilizando API WebServices da Amazon EC2 ● Linha de comando / totalmente scriptable
  6. 6. Principais Desafios Elasticidade do ambiente Muitos nós instanciados e desligados em um curto período de tempo Automatização total do processo Registro automático de nós em clusters, load balancers, etc Restrições da Amazon Sem multicast ● Impossibilita protocolo UDP no cluster IPs dinâmicos
  7. 7. Arquitetura Final
  8. 8. Arquitetura Final Amazon HTTP Load Balancer Sticky session usando Cookie Configuração manual (adição de nós) Health Check Mongrel Cluster Apache2 e mod_proxy_balancer Cada cluster Mongrel possui 5 nós
  9. 9. Arquitetura Final Gossip Router – JGroups Permite a atribuição de nomes às máquinas com IP dinâmico O nome atribuído vale enquanto a máquina estiver ativa Gossip Router configurado em todas as máquinas Apache Os nós dos clusters Frontend e Backend se registram durante o startup ● O registro é realizado em todos os Gossip Routers ativos no momento do startup ● Ao criar as máquinas JBoss, são informados os IPs das máquinas onde estão instalados os Gossip Routers Cron + Script atualiza o /etc/hosts da máquina Apache para que ela possa encontrar os nós do JBoss de Frontend O mesmo ocorre nas máquinas de Frontend para que consigam encontrar os nós do JBoss de Backend
  10. 10. Arquitetura Final Balanceamento via mod_jk Foram pré-configurados 150 workers, apontando para 150 hostnames diferentes (frontend1, frontend2, ...) Todos estão previamentre desabilitados Cron + Script habilitam os workers que possuem um IP atribuído pelo Gossip Router da máquina em questão A habilitação é realizada dinamicamente através do módulo JKStatusManager Balanceamento Round Robin sem sticky session
  11. 11. Arquitetura Final Frontend Nós do JBoss 5.1.0.GA independentes (não configurados em cluster) Cada nó se registra em todos os Gossip Routers ativos durante o startup Cron + Script atualiza o /etc/hosts da máquina para que ela possa encontrar os nós do JBoss de Backend Integração com o Backend via JMS
  12. 12. Arquitetura Final Backend Cluster JBoss 5.1.0.GA com filas JMS (JBoss Messaging) para distribuição do trabalho Cada nó também se registra em todos os Gossip Routers ativos durante o startup JGroups – TCP Gossip Routing
  13. 13. Outras Abordagens Testadas mod_cluster × mod_jk mod_cluster ● Nós se registram automaticamente ● Não segue o padrão de configuração do Apache 2 – Virtual Hosts ● Conflitos de bibliotecas com mod_proxy_balancer mod_jk ● Nós são registrados manualmente, mas podem ser ativados, inativados e ter seus dados atualizados via JkStatusManager ● Segue o padrão de configuração Apache 2 ● Sem conflitos com outros módulos
  14. 14. Monitoramento Uso do RHQ 3.0.0 Monitoramento do Sistema Operacional (Ubuntu) das principais máquinas envolvidas (Apache, pelo menos uma máquina JBoss de Frontend / Backend e Postgres) Monitoramento do JBoss em pelo menos uma máquina Frontend e uma Backend Foi necessária alteração do plugin JBoss AS para identificar e monitorar corretamente o JBoss 5.1.0.GA Foi criado um plugin que permite monitorar o tempo de resposta da aplicação a partir, por exemplo, de um test case Jmeter Problema: ● Nome do agente atrelado ao IP da máquina
  15. 15. Monitoramento
  16. 16. Monitoramento
  17. 17. Caminhos Futuros Rails on JBoss Realizar o deploy da aplicação no JBoss e remover o cluster Mongrel Facilidade de administração e escalabilidade Alternativas para o deploy ● Warbler – cria um WAR a partir de uma aplicação Rails ● JBoss 5 Rails Deployer – nativo Apoio à evolução do RHQ 3.0.0 Melhor suporte a ambientes elásticos / cloud
  18. 18. Obrigado! www.dextra.com.br contato@dextra-sw.com (11) 2824-6722 (19) 3256-6722

×