Computação em Nuvem: Conceitos, Tecnologias, Aplicações e Desafios

Transcript

1. Computação em Nuvem: Conceitos, Tecnologias, Aplicações e Desafios Flávio R. C. Sousa Leonardo O. Moreira Javam C. Machado ERCEMAPI 2009 Universidade Federal do Ceará
2. Agenda  Introdução  Conceitos  Definição e Modelos  Tecnologias  Aplicações  Desafios  Conclusão
3. Computação em nuvem Billing Storage Web 2.0 Utility Computing Uhm, I am not quite clear…Yet another buzzword..?
4. Computação em nuvem  Serviços básicos e essenciais que são todos entregues de uma forma completamente transparente  Serviços de utilidade pública  Água, gás, eletricidade e telefone  Modelo de pagamento baseado no uso  Cobrança de acordo com as diferentes políticas para o usuário final
5. Computação em nuvem  A mesma idéia de utilidade tem sido aplicada no contexto da informática  Cloud Computing ou Computação em Nuvem
6. Computação em nuvem  Uma tendência recente de tecnologia  Proporcionar serviços de TI sob demanda com pagamento baseado no uso  Tendências anteriores à computação em nuvem foram limitadas:  A uma determinada classe de usuários  Focadas em tornar disponível uma demanda específica de recursos de TI, principalmente de informática
7. Computação em nuvem  Pretende ser global e prover serviços para as massas  Usuário final que hospeda seus documentos pessoais na Internet  Empresas que terceirizarão toda a parte de TI para outras empresas  Nunca uma abordagem para a utilização real foi tão global e completa  Não apenas recursos de computação e armazenamento são entregues sob demanda  Mas toda a pilha de computação pode ser aproveitada na nuvem
8. Computação em nuvem  Nuvem  É uma metáfora para a Internet ou infra- estrutura de comunicação entre os componentes arquiteturais, baseada em uma abstração que oculta a complexidade de infra-estrutura  Cada parte desta infra-estrutura é provida como um serviço  Estes serviços são normalmente alocados em datacenters, utilizando hardware compartilhado para computação e armazenamento.
9. Computação em nuvem SLAs Web Services Virtualization
10. Computação em nuvem  Para utilizarem os serviços, os usuários necessitam:  Um navegador e acesso a Internet  Os recursos estão disponíveis na Internet  As máquinas dos usuários não necessitam ter altos recursos computacionais  Todo hardware pode ser utilizado para realizar alguma tarefa que seja adequada ao seu poder de processamento  Novos recursos podem ser adicionados a fim de aumentar o poder de processamento e cooperar com os recursos existentes
11. CONCEITOS
12. Computação em nuvem  Evolução dos serviços e produtos de TI sob demanda  Utility Computing  Objetivo da Utility Computing  Fornecer os componentes básicos como: armazenamento, CPUs e largura de banda de uma rede como uma mercadoria através de provedores especializados com um baixo custo unitário
13. Utility Computing  Os usuários não precisam se preocupar:  Escalabilidade  A capacidade fornecida é praticamente infinita  Disponibilidade  Acesso a qualquer momento  Desempenho  Tempos de resposta são quase constantes  Backups  Responsabilidade do provedor
14. Utility Computing  Pagamento pela utilização  Sem investimentos iniciais em TI  O custo cresce de forma linear e previsível com o uso  Dependendo do modelo do negócio  O provedor de serviços pode repassar o custo de armazenagem, computação e de rede para os usuários finais  Já que é realizado a contabilização do uso
15. Utility Computing  Suponha que você tenha um requisito para operar 100 servidores por três anos  Opções: alugar ou comprar?  Alugar  0.40 dólares por instância/horas  Cálculo:  100 servidores * $ 0.40 por instância/horas * 3 anos * 8760 horas/ano = $ 1.051.200
16. Utility Computing  Comprar  Custo para comprar cada servidor: $ 750 dólares  Dois funcionários para administrar os servidores pagando 100.000 dólares por ano.  Os servidores exigem 150 watts cada e o custo da eletricidade é de 0.10 por quilowatt-hora  O custo anual para operar os 100 servidores é de 13.140 dólares
17. Utility Computing  Comprar e “administrar”:  Cálculo  100 servidores * $ 750 + 3 anos * $ 13.140 eletricidade/ano + 3 anos * 2 funcionários *  $ 100.000 salários/ano = $ 714.420  Comparativo  Alugar: $ 1.051.200  Comprar: $ 714.420
18. Utility Computing  Comparativo  Se a utilização for de 100%  Melhor comprar  Se a utilização for de 68% ou menor  Melhor alugar  Mesmo considerando que  Os números apresentados são apenas estimativas  Nem todos os custos foram considerados  Pode-se verificar que modelo de Utility Computing é preferível em muitos casos
19. Computação em nuvem  O NIST (National Institute of Standards and Technology) define computação em nuvem como um paradigma em evolução  Definições, casos de uso, tecnologias, problemas, riscos e benefícios sobre nuvem serão redefinidos e evoluirão com o tempo  Modelo de nuvem do NIST é composto:  Cinco características essenciais  Três modelos de serviço  Quatro modelos de implantação
20. Computação em nuvem  Definição (NIST)  Computação em nuvem é um modelo que possibilita acesso, de modo conveniente e sob demanda, a um conjunto de recursos computacionais configuráveis que podem ser rapidamente adquiridos e liberados com mínimo esforço gerencial ou interação com o provedor de serviços  Definição (Berkeley)  A computação em nuvem é um conjunto de serviços de rede ativados, proporcionando escalabilidade, qualidade de serviço, infra-estrutura barata de computação sob demanda e que pode ser acessada de uma forma simples e pervasiva
21. Modelos de Serviços
22. SaaS  O modelo de SaaS proporciona softwares com propósitos específicos que são disponíveis para os usuários através da Internet  Os softwares são acessíveis a partir de vários dispositivos do usuário por meio de uma interface thin client como um navegador Web
23. SaaS  O usuário não administra ou controla a infra-estrutura subjacente  Rede, servidores, sistemas operacionais, armazenamento, ou mesmo as características individuais da aplicação  Exceto configurações específicas  Os desenvolvedores se concentram em inovação e não na infra-estrutura  Possibilita o desenvolvimento rápido de softwares
24. SaaS  O Software está na Web  Pode ser acessado pelos usuários de qualquer lugar e a qualquer momento  Permite mais integração  Entre unidades de uma mesma empresa  Outros serviços de software  Novos recursos podem ser incorporados automaticamente aos softwares sem que os usuários percebam estas ações  Torna a evolução e atualização transparente dos sistemas.
25. SaaS  O SaaS reduz os custos  Dispensa a aquisição de licenças de softwares  Exemplos de SaaS  CRM (Customer Relationship Management) on- line do Salesforce  Google Docs
26. PaaS  Oferece uma infra-estrutura de alto nível de integração para implementar e testar aplicações na nuvem  O usuário não administra ou controla a infra-estrutura subjacente  Rede, servidores, sistemas operacionais ou armazenamento  Mas tem controle sobre as aplicações implantadas e as configurações de aplicações hospedadas nesta infra-estrutura
27. PaaS  A PaaS fornece:  Sistema Operacional  Linguagens de Programação  Ambientes de Desenvolvimento  Auxilia na implementação de softwares  Contém ferramentas de desenvolvimento  Colaboração entre desenvolvedores.
28. PaaS  Os desenvolvedores dispõem de ambientes escaláveis  Mas eles têm que aceitar algumas restrições sobre o tipo de software que se pode desenvolver  Limitações que o ambiente impõe na concepção das aplicações  Utilização de banco de dados do tipo chave- valor ao invés de banco de dados relacionais.
29. PaaS  Permite aos usuários utilizarem serviços de terceiros:  Uso do modelo de suporte no qual os usuários se inscrevem para solicitações de serviços de TI ou de resoluções de problemas pela Web  Pode-se descentralizar uma certa carga de trabalho e responsabilidades nas equipes de TI das empresas  Exemplos de PaaS  Google App Engine  Aneka
30. IaaS  Responsável por prover toda a infra- estrutura necessária para a PaaS e o SaaS  O principal objetivo é tornar mais fácil e acessível o fornecimento de recursos:  Servidores, rede, armazenamento  Recursos de computação fundamentais para construir um ambiente de aplicação sob demanda  Podem incluir Sistemas Operacionais e Aplicativos
31. IaaS  Possui algumas características:  Interface única para administração da infra- estrutura  API para interação com hosts, switches, balanceadores e roteadores  Suporte para a adição de novos equipamentos de forma simples e transparente
32. IaaS  O usuário não administra ou controla a infra-estrutura da nuvem  Tem controle sobre os sistemas operacionais, armazenamento e aplicativos implantados  seleciona componentes de rede, tais como firewalls  Virtualização  A infra-estrutura pode escalar dinamicamente, aumentando ou diminuindo os recursos de acordo com as necessidades das aplicações
33. IaaS  Do ponto de vista de economia e legado  Ao invés de comprar novos servidores e equipamentos de rede para a ampliação de serviços, pode-se aproveitar os recursos ociosos disponíveis  Adicionar novos servidores virtuais à infra- estrutura existente de forma dinâmica  Exemplos de IaaS:  O Amazon EC2 (Elastic Cloud Computing)  Eucalyptus (Elastic Utility Computing Architecture Linking Your Programs To Useful Systems)
34. Modelos de Implantação  Privado  Público  Híbrido  Comunidade
35. Privado  A infra-estrutura de nuvem é utilizada exclusivamente para uma organização  Nuvem local ou remota  Administrada pela própria empresa ou por terceiros  São empregados políticas de acesso aos serviços  Gerenciamento de redes  Configurações dos provedores de serviços  Utilização de tecnologias de autenticação e autorização
36. Público  A infra-estrutura de nuvens é disponibilizada para o público em geral  Acessível por qualquer usuário que conheça a localização do serviço.  Não podem ser aplicadas restrições de acesso  Gerenciamento de redes ou aplicar técnicas de autenticação e autorização
37. Comunidade  Ocorre o compartilhamento por diversas empresas de uma nuvem  A nuvem é suportada por uma comunidade específica que partilhou seus interesses  A missão, os requisitos de segurança, política e considerações sobre flexibilidade  Este modelo de implantação  Pode existir localmente ou remotamente  Pode ser administrado por alguma empresa da comunidade ou por terceiros
38. Híbrido  Existe uma composição de duas ou mais nuvens  Privadas  Pública  Comunidade  Nuvens híbridas são consideradas como entidades únicas  Ligadas por uma tecnologia padronizada ou proprietária  Permite a portabilidade de dados e aplicações
39. Características Essenciais  Self-service sob demanda  Amplo acesso  Pooling de recursos  Elasticidade rápida  Serviço medido
40. Self-service sob demanda  O usuário pode adquirir unilateralmente recursos computacionais  Tempo de processamento no servidor ou armazenamento na rede  Na medida em que necessite  Sem precisar de interação humana com os provedores de cada serviço
41. Self-service sob demanda  O hardware e o software dentro de uma nuvem  Podem ser automaticamente reconfigurados e orquestrados  Modificações são apresentadas de forma transparente para os usuários com perfis diferentes  Podem personalizar seus ambientes computacionais  Instalação de software e configuração de rede para a definição de determinados privilégios
42. Amplo acesso  Recursos são disponibilizados por meio da rede e acessados através de mecanismos padronizados possibilitam o uso por plataformas Thin ou Thin Client  Celulares, Laptops e PDAs
43. Amplo acesso  A interface de acesso a nuvem não obriga os usuários a mudar suas condições e ambientes de trabalho  Linguagens de Programação e Sistema Operacional  Os softwares clientes instalados localmente para o acesso à nuvem são leves  Como um navegador de Internet
44. Pooling de recursos  Os recursos computacionais do provedor são organizados em um pool para servir múltiplos usuários  Modelo multi-tenant  Diferentes recursos físicos e virtuais são dinamicamente atribuídos e ajustados de acordo com a demanda dos usuários
45. Pooling de recursos  Os usuários não precisam ter conhecimento da localização física dos recursos computacionais  Podendo somente especificar a localização em um nível mais alto de abstração  País, estado ou datacenter
46. Elasticidade rápida  Recursos podem ser adquiridos de forma rápida e elástica  Em alguns casos automaticamente  Escalável com o aumento da demanda  Liberados na retração dessa demanda  Os recursos disponíveis para uso  Parecem ser ilimitados  Podem ser adquiridos em qualquer quantidade e a qualquer momento
47. Elasticidade rápida  A virtualização ajuda na característica de elasticidade rápida na computação nuvem  Cria várias instâncias de recursos requisitados utilizando um único recurso real  A virtualização é uma maneira de abstrair características físicas de uma plataforma computacional dos usuários  Exibe outro hardware virtual e emula um ou mais ambientes que podem ser independentes ou não
48. Serviço medido  Sistemas em nuvem automaticamente controlam e otimizam o uso de recursos por meio de uma capacidade de medição  A automação é realizada em algum nível de abstração apropriado para o tipo de serviço  Armazenamento, processamento, largura de banda e contas de usuário ativas  O uso de recursos pode ser monitorado e controlado  Transparência para o provedor e o usuário
49. Serviço medido  Para garantir o QoS (Quality of Service)  Níveis de acordo de serviço  SLA (Services Level Agreement)  O SLA tem informações sobre os níveis  Disponibilidade  Funcionalidade  Desempenho  Faturamento  Penalidades
50. Papéis na nuvem
51. Arquitetura  Baseada em camadas  Cada uma trata de uma particularidade  Divide logicamente os componentes  Hardware  Software  Agrupa componentes por interesse  Gerenciamento e monitoramento independente
52. Arquitetura  Fornece:  Escalabilidade  Reusabilidade  Flexibilidade  Substitui ou adiciona recursos sem afetar outras camadas  Independência
53. Arquitetura
54. Infra-estrutura física  Contém:  Datacenters  Clusters  Desktops  Outros recursos de hardware  Recursos heterogêneos  Flexibilidade de agregação de novos recursos a medida que se tornem necessários
55. Camada de middleware  Gerencia a infra-estrutura física  Fornece o núcleo lógico da nuvem  Contém:  Negociações de QoS  Gerenciamento dos SLA  Serviços de cobrança  Preço  Serviços de virtualização  Outros serviços
56. Camada de desenvolvimento  Fornece suporte para a construção das aplicações  Contém:  Ferramentas  Ambientes de desenvolvimento  Os ambientes possuem:  Interfaces Web 2.0  Marshups  Suporte a workflows  Bibliotecas  Linguagens de programação  Camada utilizada por usuários “experientes”
57. Outras camadas  Camada de aplicação  Camada utilizada pelos usuários finais  Disponibiliza as aplicações implantadas na nuvem  Camada de gerenciamento e adaptações  Camada opcional  Fornece adaptação as soluções em nuvem  automática  semi-automática  Diminui esforços humanos para gerenciar arquiteturas de nuvem
58. TECNOLOGIAS
59. MapReduce
60. Programação Funcional Operações funcionais não modificam as estruturas de dados Sempre criam novas Os dados originais permanecem na forma não modificada Os fluxos de dados estão implícitos no programa workflows Ordem de operações não importa
61. Programação Funcional fun foo(l: int list) = sum(l) + mul(l) + length(l) A ordem de sum(), mul() e length(), não importa e não modifica I
62. Paralelismo Implícito no Map Os elementos de uma lista a ser calculada pelo mapa, não podem ver os efeitos dos cálculos sobre outros elementos Isolamento Se a ordem de aplicação de f para elementos na lista é comutativa, podemos reordenar ou paralelizar a execução Este é o “segredo” que explora MapReduce
63. Processamento em Larga Escala Processamento em grandes quantidades de dados (> 1 TB) Fornecer paralelismo em centenas e milhares de CPU MapReduce  Paralelização automática e distribuição  Tolerante a falhas  Fornece ferramentas de status e acompanhamento  Abstração para programadores
64. Map Registros da fonte de dados linhas de arquivos, linhas de um banco de dados, etc São alimentados em função do mapa como pares chave * valor  Por exemplo(nome do arquivo, linha) map() produz um ou mais valores intermediários, juntamente com uma chave de saída
65. Reduce Após a fase de map, todos os valores intermediários para uma dada chave de saída são combinadas em uma lista reduce() que combina os valores intermediários em um ou mais valores para a mesma chave de saída
66. MapReduce
67. Paralelismo  map() funções em paralelo, criando diferentes valores intermediários a partir de conjuntos de dados de entrada diferentes  reduce() funções que também funcionam em paralelo, cada uma trabalhando em uma chave de saída diferente  Todos os valores são tratados de forma independente  Gargalo: a fase reduce pode não ser iniciada até a fase map está completamente terminada
68. Localidade Programa Master Divide as tarefas com base na localização de dados Tenta ter map das tarefas na mesma máquina como dados de arquivo físico, ou, pelo menos, mesmo rack
69. Tolerância a Falhas Master detecta falhas do trabalhador (worker) Re-executa tarefas map() concluídas e em progresso Re-executa tarefas reduce() em andamento Avisos notificam chaves de entrada/valores que causam falhas no map(), e ignora os valores na re-execução
70. Otimizações Não pode começar a reduce() até o map() está completo Um controlador de taxa lenta de disco único pode limitar todo o processo Master redundante executa tarefas map “lentas”
71. Amazon EC2 Amazon Elastic Compute Cloud
72. Objetivos Infra-estrutura como Serviço (IaaS)  Concebido para tornar a computação na Web escalável e fácil para os desenvolvedores  Utiliza instâncias de máquina virtual  Reduzir o tempo necessário para obter e inicializar novas instâncias de um servidor  Balanceamento de carga  Altera a economia da computação:  Pague apenas pela capacidade que você realmente usar
73. Conceitos  Amazon Machine Image (AMI):  Inicializável a partir do root  Catálogo de usuários AMIs  S.O.: Fedora, CentOS, Gentoo, Debian, Ubuntu, Windows Server  Pilha de Aplicação: LAMP, mpiBLAST, Hadoop  Instância:  Executando uma cópia da AMI  Lançamento em menos de 2 minutos  Inicia/pára de forma programada  Modelo de Segurança da Rede:  Controle de acesso explícito  Grupos de segurança
74. Infra-estrutura como Serviço Compute Store Message Elastic Compute Cloud Simple Storage Service Simple Queue Service
75.  Criação da Amazon Machine Image (AMI)  Upload da AMI no Amazon S3.  Configuração de segurança e acesso a rede  Escolha os tipos de instâncias que você quer executar  Cria, termina e monitora várias instâncias de seu AMI conforme necessário, utilizando as APIs de serviços Web  Paga por horas de instâncias e largura de banda que você realmente consome.  Conexão com a AMI através de SSH Simplicidade de Uso
76. Atribuição de Preços  Pagamento pelo uso  O preço é por instância/horas consumido para cada tipo de instância  Instância/hora consumida, parcialmente, são tarifadas como hora completa  $0.10 - Small Instance (Default)  1.7 GB de memória, 1 EC2 unid. de computação (1 virtual core com 1 EC2 unid. de computação), 160 GB de instâncias de armazenamento, plataforma 32-bit  $0.40 - Large Instance  7.5 GB de memória, 4 EC2 unid. de computação (2 virtual cores com 2 EC2 unid. de computação cada), 850 GB de instâncias de armazenamento, plataforma 64-bit  $0.80 - Extra Large Instance  15 GB de memória, 8 EC2 unid. de computação (4 virtual cores com 2 EC2 unid. de computação cada), 1690 GB de instâncias de armazenamento, plataforma 64-bit
77. Estratégia de Virtualização  Utiliza o Xen – como máquina virtual  Diferente do Vmware e VPC ele usa “paravirtualization” onde os SOs são modificados para o uso especial de hypercalls  Ilusão de estar sendo executado diretamente sobre o hardware  Alto desempenho  Suporte de hardware da Intel e AMD  Suporta “Live Migration” de uma máquina virtual entre hosts
78. Problemas Local de armazenamento não é persistente  Quando você desligar, seus dados são perdidos  Necessidade de escrevê-los em outro lugar, mas S3 é grátis! DHCP atribuição de endereços IP  Então muda IP quando reiniciado instância  Difícil de usar como um servidor público
79. Amazon SQS  Oferece disponibilidade, escalabilidade e uma fila para armazenamento de mensagens entre computadores  Transfere dados facilmente entre componentes distribuídos  Por meio de uma API simples  Útil para desenvolvedores  Garantia de entrega  Replicação  Fornece segurança contra acessos não autorizados a fila e suas mensagens
80. Amazon Simple Storage Service (S3)  Um sistema de arquivos distribuído  Armazenamento ilimitado  Pagamento pelo uso  $0.20 por GB de dados transferidos  $0.15 por GB/mês para armazenamento utilizado  Fornece um repositório seguro e confiável para armazenar as AMIs  Armazena e recupera resultados intermediários dos processos
81. S3  Não é como um sistema típico (raiz única)  Os usuários podem ter até 100 “buckets”  Unidade fundamental de armazenamento  Nomes dos bucket são globais!  Um bucket possui armazenamento ilimitado de arquivos  Acesso por REST/SOAP
82. Amazon SimpleBD  É um WS que disponibiliza funcionalidades de BD em nuvem  Escalável  API simples para armazenamento e acesso  Sintonia automática na indexação  S3 armazena dados brutos  Cria índices em múltiplas dimensões  Permite a rápida consulta de dados  Utilizado para guardar o estado global do sistema  Armazena os metadados referentes aos objetos contidos no S3
83. Eucalyptus
84. Eucalyptus  Projeto Eucalyptus  Elastic Utility Computing Architecture Linking Your Programs To Useful Systems  É uma infra-estrutura de software de livre para implementação de sistemas de computação em nuvem  Compatível com o Amazon EC2
85. Componentes  Cloud Controller (CLC)  Cluster Controller (CC)  Node Controller (NC)  Storage Controller (SC)  Walrus (put/get storage)
86. Client-side API Translator Cloud Controller Cluster Controller Amazon EC2 Interface Arquitetura Node Controller
87. Representação
88. Cloud Controller  É o ponto de entrada na nuvem para:  administradores, projetistas, desenvolvedores e usuários finais  É responsáveis pelas consultas aos nodes e decisões de escalonamento por meio de requisições aos cluster- controllers
89. Cluster Controller  Geralmente é executado na máquina front-end ou em alguma máquina que tem conexão com todos os nodes  São responsáveis por tomar informações sobre as maquinas virtuais ou sobre o tempo de execução das VMs
90. Node Controller  É executado em todo Node que hospeda uma maquina virtual  É responsável por gerenciar a execução, inspeção e finalização das máquinas virtuais
91. Storage Controller  Implementa um bloco de armazenamento na rede  É capaz de interagir com diversos sistemas de armazenamento (NFS, ISCSI, etc)  Um bloco de armazenamento elástico é um dispositivo de bloco que pode ser conectado a uma máquina virtual
92. Walrus (put/get storage)  Permite aos usuários armazenar dados persistentes organizados como registros e objetos  Cria e apaga listas de registros  Retorna e apaga objetos  Controla política de acesso
93. Benefícios  Expansibilidade  Arquitetura simples e APIs internas  Interface para o cliente  Interface e funcionalidades do Amazon EC2  Rede  Redes privadas virtuais por nuvem  Segurança  Deve ser compatível com as regras de segurança locais  Virtualização  Servidores, rede, armazenamento, etc
94. Microsoft Azure
95. Microsoft Azure  A Plataforma de Serviços Azure da Microsoft é um grupo de tecnologias da nuvem  Fornece um conjunto específico de serviços para desenvolvedores de aplicativos  Pode ser usada tanto por aplicativos em execução na nuvem quanto por aqueles executados em sistemas locais
96. Microsoft Azure
97. Principais Componentes  Windows Azure:  Fornece um ambiente baseado no Windows para executar aplicativos e armazenar dados nos servidores dos centros de dados da Microsoft  Microsoft .NET Services:  Oferece serviços de infra-estrutura distribuídos para aplicativos baseados em nuvem e locais  Microsoft SQL Services:  Fornece serviços de dados na nuvem baseados no SQL Server  Live Services:  Fornece acesso aos dados a partir de aplicativos Live da Microsoft e outros.
98. Windows Azure  Sistema Operacional para serviços na nuvem  Utilizado no ambiente para:  Desenvolvimento  Hospedagem  Gerenciamento dos serviços
99. .NET Services  Fornece serviços baseados em nuvem que podem ser usados por:  Aplicativos locais  Aplicativos na nuvem  Conjunto de serviços:  Escaláveis  Orientados ao desenvolvedor  Componentes reutilizáveis na nuvem  Possibilita o desenvolvimento focado na lógica da aplicação  Abstrai a construção e disponibilização do serviço na infra-estrutura  Oferece serviços de infra-estrutura distribuídos para aplicações
100. Componentes .NET Services  Controle de Acesso:  Faz com que cada usuário forneça ao aplicativo um token contendo algum conjunto de declarações  Identidade  Barramento de Serviço:  Expõe os serviços de um aplicativo na Internet  extensibilidade, flexibilidade e reuso  Fluxo de Trabalho:  Cria aplicativos compostos, como na integração de aplicativos corporativos  requer lógica que coordena a interação entre as várias partes  Orquestração
101. Live Services  Conjunto de componentes dentro do Azure para o tratamento de:  Dados do usuário  Recursos da aplicação  Possibilita a construção de aplicações ricas que podem conectar com usuários do Windows Live  Fornece a sincronização de dados dos usuários  Possibilita a extensão de aplicações Web entre múltiplos dispositivos
102. SQL Services  Conjunto de serviços baseados em nuvem para armazenar e trabalhar com muitos tipos de dados, de não-estruturados a relacionais  Expõe tanto interfaces SOAP como REST  Construído sobre o Microsoft SQL Server  Não expõe uma interface relacional tradicional  Fornece um modelo de dados hierárquico que não exige um esquema pré-definido  Cada item de dados armazenado nesse serviço é mantido como uma propriedade com seu próprio nome, tipo e valor
103. Google App Engine
104. Objetivos  Permite a execução de aplicativos da web na infra-estrutura do Google  Fácil de criar, manter e escalar à medida que o tráfego e armazenamento de dados precisa crescer  Simplicidade  Elasticidade  Confiabilidade
105. Características  Não há necessidade de manter servidores  Somente enviar seu aplicativo e ele está pronto para atender a seus usuários  Suporta aplicativos criados em várias linguagens de programação  Java  Phyton  Ruby
106. Lado Comercial  Pagamento pelo que usar  Não há preços predefinidos nem taxas recorrentes  Cobranças por recursos usados pelo seu aplicativo, como:  Armazenamento  Largura de banda  Medidos em GB e cobrados a taxas competitivas  O usuário controla a quantidade máxima de recursos que o aplicativo pode consumir  Controle adequado ao orçamento
107. Recursos  Serviço de Web dinâmico  Suporte completo a tecnologias Web  Armazenamento persistente  Consultas, classificação e transações (BigTable)  Ajuste e balanceamento de carga automáticos  APIs para autenticação e envio de e-mails através do Google  Ambiente de desenvolvimento local com todos os recursos disponíveis no Google  Esquema de tarefas programadas
108. Ambientes de Execução  O aplicativo pode ser executado em um dos dois ambientes de execução:  Java  Python  Cada ambiente oferece:  protocolos padrão  tecnologias comuns para o desenvolvimento de aplicativos Web
109. Sandbox  Um ambiente seguro que fornece acesso limitado ao sistema operacional  Isola o aplicativo em seu próprio ambiente  Seguro e confiável  independentemente de hardware, sistema operacional e localização física do servidor da Web  Algumas restrições  Um aplicativo não pode gravar no sistema de arquivos  Limitações de Resposta: deve retornar dados de resposta em 30 segundos
110. O ambiente de execução Java  Conjunto de ferramentas comuns de desenvolvimento da Web e padrões de APIs  Inclui a plataforma JRE 6 e as suas bibliotecas  As restrições do ambiente do sandbox são implementadas na JVM  Otimização  Um aplicativo pode usar qualquer bytecode JVM ou recurso da biblioteca  Desde que não exceda as restrições do sandbox
111. O ambiente de execução Java  Para o armazenamento de dados inclui implementações das interfaces  JDO (Objetos de dados Java)  JPA (API persistente Java)  Os serviços também incluem APIs de nível inferior  Para implementar adaptadores adicionais  Para serem usadas diretamente do aplicativo
112. O ambiente de execução Phyton  É possível implementar o aplicativo e executá-lo em um interpretador otimizado  Inclui APIs avançadas e ferramentas para desenvolvimento de aplicativos:  Modelagem de dados, gerenciamento e acesso aos dados de forma simples  O ambiente fornece APIs abrangentes:  Armazenamento de dados, e-mail, ...  Uso de biblioteca de terceiros desde que  Implementadas em Python puro  Não exijam nenhum módulo de biblioteca padrão não suportado
113. Armazenamento de dados  Fornece um poderoso serviço de armazenamento de dados distribuído que contém:  Um mecanismo de consultas  Transações  O armazenamento de dados não é um banco de dados relacional tradicional (BigTable)  Os objetos de dados, ou “entidades”, têm um tipo e um conjunto de propriedades  As consultas recuperam entidades de um tipo determinado, filtradas e classificadas segundo os valores das propriedades
114. Armazenamento de dados  As entidades do armazenamento de dados não possuem esquema  A estrutura das entidades de dados é fornecida e aplicada pelo código do seu aplicativo  O aplicativo pode acessar os dados diretamente  Garantia de consistência, integridade e controle de concorrência otimista  Uma atualização de entidade ocorre em uma transação com um número fixo de tentativas  Caso outros processos estejam tentando atualizar a mesma entidade simultaneamente  Confiabilidade  Seu aplicativo pode executar diversas operações de armazenamento de dados em uma única transação
115. Aneka
116. Objetivos  Plataforma única de apoio a vários modelos de programação paralela e aplicações distribuídas  Arquitetura flexível e extensível  QoS corporativo  Os aplicativos podem negociar a capacidade necessária
117. Recursos  Caracterização  Middleware para Grids/Clouds corporativos  Arquitetura orientada a serviços  Baseado em ambiente .NET/Mono  Linguagens:  C#, C++, VB, Delphi, Java/IKVM…  … e mais de 20 linguagens  Plataformas:  Windows XP/2000/2003  Linux e Mac OS X
118. Recursos  Múltiplos modelos de programação/implantação  Múltiplos estratégias de escalonamento  Múltiplos modelos de autenticação  Múltiplos mecanismos de persistência  Múltiplos plataformas e SOs Projetado para ser um middleware configurável com o objetivo de apoiar uma duração indeterminada a um conjunto de abstrações para computação distribuída e implantação cenários
119. Arquitetura  Overview do sistema Executor Scheduler Executor Executor Executor Manager work units internet internet Aneka enterprise Cloud Manager work units Manager(s) Client Applications Workers Aneka Container
120. Arquitetura  Serviços  Scheduling Services:  Serviços básicos de escalonamento  Suporte para:  Pacotes independentes de escalonamento de tarefas  Diferentes e acopláveis algoritmos de escalonamento  Escalonamento para reservas avançadas  Re-sumissão automática/configurada de tarefas diante de falhas  Execution Services:  Básico do sandboxing  Suporte para execução de código legado (PSM)  Storage:  Múltiplos protocolos baseados em serviços de armazenamento (FTP)
121. Componentes  Ao iniciar, o container carrega:  Mandatory Services  MembershipCatalogue Service: serviço de descoberta  Allocation Manager: alocação de recurso  HeartBeat Service: notifica o status do container  Security infrastructures  AuthenticationProvider e AuthorisationProvider  MessageDispatcher  Para tratar a chegada e saída de mensagens para os serviços  Outros serviços (Executors, Schedulers, etc.)  Baseado na configuração de arquivos, e iniciar esses serviços via IoC (Inversion of Control)
122. Modelos de Programação  Suportado atualmente:  Modelo de programação em Tarefas  Modelo de programação em Thread  Modelo de programação em MapReduce  Modelo Parameter Sweeping  .. Implementações suas..
123. Modelos de Programação  Modelo de programação em Tarefas  Usado para pacotes independentes de tarefas de aplicações (BoT)  A aplicação é uma coleção de unidade de execução  Cada unidade de execução não está relacionada com os outras  Não há nenhuma ordem na execução das unidades  Se houver qualquer ordenação ou seqüência isso é realizada através da aplicação cliente e não pelo middleware
124. Modelos de Programação  Modelo de Programação em Thread  Baseado no conceito de thread distribuída  Como uma thread local, mas executado remotamente  Implementa um subconjunto de operações comuns da thread  Iniciar, Parar, Estado da consulta, Junção  Fornece uma maneira rápida de portabilidade em um middleware distribuído, aplicações multi-threaded
125. Modelos de Programação  Modelo de Programação em MapReduce  Desenvolvimento de aplicações baseadas no MapReduce  Definir as operações de map e reduce  Fornecer os dados  Executar o motor MapReduce Input data map & reduce MapReduce engine Map & Reduce network Execution: -File staging -Task scheduling -Failed task resubmission -Replication and Fault tolerance -Collection of result
126. Modelos de Programação  Extensibilidade  A implementação de um novo modelo de programação  Definir as abstrações do usuário  Fornecer a implementação para:  Execution Service (middleware)  Scheduling Service (middleware)  Application Manager (componente cliente)  Onde começar:  Aneka.Entity.*, Aneka.Data.Entity*;  Aneka.Execution.*;  Aneka.Runtime.Scheduling.*;
127. Como utilizar  Passos  Desenvolvendo aplicações com Aneka  Escolhendo o modelo de programação  Definindo a lógica da aplicação  Implementação do código  Instalação e execução
128. APLICAÇÕES
129. Aplicações  Diversos tipos de aplicações estão sendo disponibilizadas como serviços  Serviços de webmail  Sites  SaaS  Soluções de bioinformática  Processamento de imagens
130. Aplicações  Jornal NY Times utilizou EC2 e S3 para converter 15 milhões de artigos para PDF  Em minutos  A bolsa de Nasdaq usa S3 para disponibilizar informações sobre histórico de ações
131. CloudAV  Um novo modelo para detecção de vírus em máquinas como SaaS  Utiliza a técnica “N-version protection”  Múltiplos mecanismos de detecção  Paralelismo  Apresenta resultados satisfatórios com relação as soluções tradicionais
132. Arquitetura  Componentes arquiteturais  Agente  Serviço de rede
133. CloudAV  Executado em máquinas virtuais  Escalabilidade  Utilizado em diversos ambientes  Windows, Linux, FreeBSD, etc  Trabalha com 10 aplicativos antivírus  Avast, AVG, BitDefender, Kaspersky, McAfee, Symatec, TredMicro, ...  Trabalha com 2 softwares para detecção de comportamento  Normam Sandbox e CWSandbox
134. Avaliação  Utilizou-se dados reais coletados  Período de 6 meses  Um banco de dados de 7220 amostras de vírus  Com base em experimentos, conclui-se que o CloudAV é:  35% superior na detecção de ameaças  Possui uma taxa de 98% de detecção em relação a todos os dados
135. Benefícios  Não há a necessidade de se preocupar com atualizações  As máquinas dos usuários não desperdiçam CPU  Combina diversas estratégias para a solução  Confiabilidade  Segurança
136. DESAFIOS
137. Desafios  Segurança  Gerenciamento de Dados  Autonomia  Disponibilidade de Serviços  Escalabilidade e Desempenho
138. Desafios  Descrição, Descoberta e Composição de Serviços  Licenciamento de Software  Integração de Serviços  Padronização  Avaliação de Serviços
139. Segurança  A computação em nuvem utiliza a Internet  Dados são processados fora das empresas  Os provedores devem garantir:  Autenticidade  Confidencialidade  Integridade
140. Segurança  Confiabilidade  Os provedores devem fornecer recursos confiáveis  Especialmente se a computação a ser realizada é crítica  Responsabilidade  Deve existir uma delimitação bem definida de responsabilidade
141. Gerenciamento de Dados  Ponto crítico em computação em nuvem  SGBDs relacionais não possuem escalabilidade quando milhares de sítios são considerados  Novas abordagens são flexíveis para garantir a escalabilidade:  Armazenamento de dados  Processamento de consultas  Controle transacional
142. Gerenciamento de Dados  Trade-off entre funcionalidades e custos operacionais:  Os serviços em nuvem para dados oferecem:  APIs mais restritas do que os SGBDs relacionais  Uma linguagem minimalista de consulta  Possuem garantia de consistência limitada  Exige mais esforço de programação dos desenvolvedores  Mas permite aos provedores construírem serviços com garantias de SLA
143. Gerenciamento de Dados
144. Autonomia  A computação em nuvem é um sistema autônomo  Gerenciado de forma transparente para os usuários  Hardware e software dentro de nuvens podem ser automaticamente:  Reconfigurados  Orquestrados  Estas modificações são apresentadas ao usuário como uma imagem única
145. Autonomia  Reduz o custo de equipe de monitoramento do sistema tanto no âmbito centralizado quanto distribuído  Comparados com sistemas tradicionais é possível identificar três fatores complexos:  Intervenção humana limitada  Alta alternância na carga de processamento  Variedade de infra-estruturas compartilhadas
146. Autonomia  Intervenção Humana Limitada  Na maioria dos casos, não existem administradores de sistemas para ajudarem os desenvolvedores que acessam a nuvem  Plataforma automatizada ao máximo  Alta alternância de carga  Os usuários podem variar suas cargas de trabalho habituais  Alocação dinâmica de recursos  Virtualização a principal técnica neste contexto
147. Autonomia  Variedade de infra-estruturas compartilhadas  Gerência eficaz  Desenvolvimento de tecnologia de auto-sintonia  Técnicas adaptativas e on-line
148. Disponibilidade  Permite aos usuários acessar e utilizar a nuvem onde e quando desejarem  Nuvem utiliza a Internet  Pode ocorrer atrasos  Sistemas indisponíveis  A computação em nuvem deve fornecer ambientes com alta disponibilidade
149. Disponibilidade  Pode-se utilizar técnicas:  balanceamento dinâmico de carga  Composição de nuvens  Exemplo:  Podem-se construir aplicações altamente disponíveis com a implantação de duas ofertas de nuvem diferentes. Caso uma das nuvens falhe, a outra nuvem continua a apoiar a disponibilidade das aplicações
150. Escalabilidade  Grande aumento no número de usuários  Os serviços devem suportar uma quantidade variável de requisições  Os serviços oferecidos podem ser dimensionados por vários fatores:  Localizações geográficas  Desempenho  Configurações  Desenvolver sistemas escaláveis é complexo
151. Desempenho  As soluções de computação em nuvem devem fornecer elevado desempenho mesmo com:  Limitações de rede  Segurança  Ambientes de computação em nuvem possuem acesso público  Imprevisível e variável a quantidade de requisições realizadas  Torna-se complexo fazer estimativas e garantias de QoS
152. Descrição, Descoberta e Composição  Na computação em nuvem vários modelos evoluíram rapidamente para aproveitar:  Tecnologias de software  Plataformas de programação  Armazenamento de dados e infra-estrutura de hardware como serviços  Estes modelos se referem ao núcleo dos serviços de computação em nuvem  Suas inter-relações têm sido ambíguas  A viabilidade de sua interoperabilidade é questionável
153. Descrição, Descoberta e Composição  Cada serviço da nuvem tem interfaces e protocolos diferentes  Diversos serviços dispersos no ambiente  Características diferentes  Necessidade de desenvolver técnicas eficazes:  Descrever, descobrir e compor estes serviços
154. Licenciamento de Software  Pesquisas em computação tem investigado vários modelos econômicos de infra-estrutura computacional  Computação em nuvem  Tem uma abordagem mais aplicada aos negócios e relacionada ao custo  A computação em nuvem apresenta diversos modelos de preço:  Preço diferenciado  Preços por unidade  Assinatura de serviços básicos
155. Licenciamento de Software  Preço diferenciado  Os serviços são oferecidos em vários níveis de especificações, tais como: alocação de memória e tipo de CPU, informações de SLA  O valor cobrado é um preço específico por unidade de tempo  Modelo adotado pela Amazon
156. Licenciamento de Software  Preço por unidade  Normalmente aplicado a dados transferidos ou ao uso de memória  Este modelo é mais flexível do que o de preço diferenciado  Permite aos usuários personalizarem a alocação de memória de seus sistemas baseados nas necessidades de aplicações específicas
157. Licenciamento de Software  Assinatura de serviços básicos  Modelo de preço mais amplamente utilizado  Permite aos usuários preverem suas despesas na utilização de um serviço  Não tem a precisão em cobrar dos usuários o que eles têm realmente utilizado
158. Integração de Serviços  Diversos serviços disponíveis  Recursos heterogêneos  Fornecer interoperabilidade  Adaptações:  Tecnologias de integração de dados  Serviços e linguagens
159. Padronização  As empresas têm interesse que aplicações possam ser transferidas para a nuvem de forma simples  Essas empresas também esperam que exista interoperabilidade entre diferentes serviços de nuvem:  Armazenamento  Acesso  Gerenciamento
160. Padronização  Exemplo:  As APIs da Amazon estão se tornando um padrão de fato para serviços sob demanda  A quantidade de tecnologias envolvidas é muito grande  Padronizar as diversas interfaces e serviços é um desafio
161. Avaliação de Nuvem  Existem muitos serviços disponíveis em nuvem  Algumas iniciativas para avaliar serviços específicos  Necessidade de desenvolvimento de um benchmark de propósito geral  Permita avaliar diversos tipos de serviços
162. Avaliação de Nuvem  Este benchmark deve ser composto de:  Ferramentas para gerar cargas de trabalho, monitorar o desempenho  Métricas para calcular o custo por usuário em uma determinada unidade de tempo  Outra alternativa para a avaliação de nuvem  Desenvolvimento de sistemas de simulação  Exemplo: CloudSim
163. Conclusões  A informática como um serviço está finalmente emergindo  Serviços estão sendo fornecidos aos usuários através da Internet sob demanda  A computação em nuvem está se desenvolvendo rapidamente  Empresas e a comunidade científica tem apresentado iniciativas  Ainda não existe uma definição clara e completa para a computação em nuvem  Existe um grande esforço neste sentido
164. Conclusões  Este minicurso apresentou:  Conceitos  Tecnologias  Aplicações  Desafios  A superação dos desafios apresentados possibilitará que a computação em nuvem seja amplamente aceita e utilizada por todos
165. Obrigado! Questões? Flávio R. C. Sousa flaviosousa@ufc.br @flaviosousa www.es.ufc.br/~flavio