Disaster Recovery usando Amazon AWS e NewRelic

Transcript

1. Proposta de Recuperação a Desastres em Sistemas Críticos Hugo Arraes Henley Saulo Reis Zimbaro Niterói - dez/ 2014
2. O Problema ❖ Dependência cada vez maior de sistema de computação em diversas áreas, em especial TI e Telecom ❖ A falta de disponibilidade pode levar a queda de prestígio das empresas e grande perda financeira ❖ A redundância/replicação de Data Centers nem sempre é possível, principalmente para empresas de pequeno e médio porte
3. Objetivos ❖ Redução de custos para soluções de Disaster Recovery ❖ Redução do downtime ❖ Permitir que empresas de menor porte tenham um serviço confiável de DR a sua disposição
4. Um caso recente: Black Friday
5. Referência: [1]
6. A Proposta ❖ Aplicação web capaz de realizar deploy de aplicações no ambiente de Cloud Computing da Amazon AWS para realizar DR ❖ Solução de baixo custo e desempenho aceitável para determinados tipos de acordo ❖ Solução que seja possível para empresas com menor capacidade de investimento em soluções de DR
7. A Solução ❖ Proposta de solução baseada em software capaz de monitorar o desempenho de aplicações web e utilizar infraestrutura de nuvem pública para lidar com Disaster Recovery de forma simples e eficaz.
8. Ferramentas
9. New Relic ❖ Ferramenta para monitoramento de sistemas de fácil instalação e com grande quantidade de métricas e relatórios ❖ Funciona no modelo SaaS (Software as a Service) ❖ API para consumo das métricas
10. New Relic
11. Amazon AWS ❖ Maior infraestrutura em cloud do mercado mundial. ❖ SLA garantido de 99,5%. ❖ Elastic Beanstalk com Docker como solução para deploy. ❖ Painel e APIs para criação de máquinas virtuais, banco de dados, storage e outros serviços. ❖ Modelo pay-as-you-go
12. Amazon AWS Referência: [3]
13. Amazon AWS Referência: [2]
14. Arquitetura da Solução
15. Solução Proposta
16. Vídeo
17. Hands-On
18. Custos
19. Custos Referência: [4]
20. Resultados
21. Resultados 1  CPU  e  1  GB  de  RAM 1  CPU,  3.75  GB  de  RAM 2  CPU,  7.5GB  de  RAM 4  CPU,  15  GB  de  RAM 8  CPU,  30  GB  de  RAM
22. Resultados 0.00# 2.00# 4.00# 6.00# 8.00# 10.00# 12.00# #$0.01300## #$0.07000## #$0.14000## #$0.28000## #$0.56000## Tempo&(min)&/&Custo&(dólares)& Tempo#(min)#/#Custo#(dólares)#
23. Análise dos Resultados ❖ Para um uptime de 99%, uma aplicação pode se tornar indisponível por 3 dias e meio, ou aproximadamente 85 horas. ❖ Considerando o DR sendo feito em máquinas de custo inferior a $0.14 por hora e o tempo médio de deploy nestas sendo 9 minutos e 53 segundos, seria possível o uso desta proposta 441 vezes durante o ano para que fosse cumprido este uptime. ❖ Para o teste realizado com aplicações em máquinas virtuais de custo superior a $0.14 por hora, e o tempo médio de deploy nestas sendo 6 minutos e 49 segundos, seria possível o uso desta proposta 746 vezes durante o ano para que fosse cumprido este uptime.
24. Análise dos Resultados Instância Horas de Serviço Preço por hora (dólares) Total (dólares) 1  CPU  e  1  GB  de  RAM 720 0.013 9.36 1  CPU,  3.75  GB  de  RAM 720 0.07 50.4 2  CPU,  7.5GB  de  RAM 720 0.14 100.8 4  CPU,  15  GB  de  RAM 720 0.28 201.6 8  CPU,  30  GB  de  RAM 720 0.56 403.2
25. Conclusões ❖ Foi possível obter resultados satisfatórios para a solução proposta. ❖ Essa solução ainda não é adequada para empresas que necessitam de 100% de uptime, sendo a Multi-Site Solution a mais adequada a estas, apresentando maior eficiência, porém maior gasto. ❖ A solução proposta apresenta um equilíbrio entre custo e disponibilidade que deve ser analisado caso a caso.
26. ❖ Disponibilização como SaaS (http://zerodowntime.so). ❖ Versão Mobile. ❖ Análise preditiva realizada através de Redes Neurais. ❖ Implementação de sistemas de alerta. ❖ Integração com LDAP para gestão de autenticação e controle de acesso. ❖ Alteração automática de DNS. ❖ Opções de escolha de local para fazer deploy da aplicação além daVirgínia. Trabalhos Futuros Versão Mobile
27. Trabalhos Futuros ❖ Opções de controle de tamanho de instância e auto-scaling. ❖ Definir deploy automático com base em métricas pré-determinadas (ex: 70% de CPU). ❖ Integração com sistemas de Service Desk para gestão de operação e relatórios de incidentes. ❖ Diminuir tempo de deploy para que o downtime seja ainda menor. ❖ Integração com outras clouds públicas além da Amazon.
28. Referências ❖ [1] http://www.techtudo.com.br/noticias/noticia/2014/11/black-friday- comeca-com-erros-durante-a-compra-sites-offline-e-reclamacoes.html ❖ [2] AWS Summit NYC 2012. Disaster Recovery with the AWS Cloud. ❖ [3] https://console.aws.amazon.com ❖ [4] http://aws.amazon.com/pt/ec2/pricing/
29. hugohenley@gmail.com saulozimbaro@gmail.com Obrigado
30. New Relic
31. Resultados (Python Web Application)
32. Resultados (NodeJS Hello World)