Carregar apresentação
A apresentação está carregando. Por favor, espere
1
Steven D. Gribble, Matt Welsh, Rob von Behren, Eric A. Brewer, David Culler, N. Borisov, C. Czerwinski, R. Gummadi, J. Hill, A, Joseph, R.H. Katz, Z.M. Mso, S. Todd, B. Zao The University of California at Berkeley Apresentado por Nazareno Andrade The Ninja Architecture for Robust Internet- Scale Systems and Services
2
2 Roteiro Introdução Arquitetura Implementação Resultados Conclusões
3
3 Introdução - cenário Grande número de clientes com capacidades limitadas e características diversas acessando serviços compostos de outros serviços na Web. –Conectividade entre dispositivos diversos e serviços e entre serviços;
4
4 Introdução - requisitos Serviços com fortes garantias operacionais –alta disponibilidade –alto Throughput –escalabilidade –alta demanda Clientes diversificados –capacidade computacional –limitações de conexão –interface
5
5 Arquitetura Ninja – Visão Geral Base -> Estrutura na qual roda o núcleo de um serviço –Por que apenas clusters? Unidades -> Dispositivos clientes, Input/Output, atuadores/sensores Proxies Ativos ->”ajuste de impedância”, adaptatividade, adequação, nível de indireção Path -> Composição de serviços horizontal, usa um SDS
6
6 Arquitetura Ninja – Visão Geral
7
7 Bases – Serviços e estágios Condicionando o Serviço... Processamento dos serviços divido em Estágios –Distribuição –Paralelismo funcional
8
8 Bases – Estágios Design Patterns –compôr e condicionar estágios
9
9 Bases - vSpace Ambiente de execução para serviços em escala de Internet que opera em clusters; Abstração de detalhes de escalabilidade, tolerância a falhas e composição de serviços; Upload dinâmico de serviços por terceiros, confiáveis ou não;
10
10 Bases - vSpace Implementa cada estágio como um worker; –Pool de threads + fila de eventos + implementação da lógica do worker Definição de serviços formal; Publicação de serviços em versões; Clonagem de workers –Balanceamento de carga; –Tolerância a falhas; –Escalabilidade;
11
11 Bases – I/O Biblioteca de I/O nonblocking Jaguar – Especialização do bytecode para executar operações de baixo-nível diretamente. –Prover acesso eficiente a interfaces especializadas??
12
12 Bases – Persistência DDS.
13
13 Unidades Cada Unidade tem seus mecanismos de I/O e interface; Enfoque em unidades com fortes limitações de recursos –Sensor como unidade mínima; Aplicação exemplo (???)
14
14 Proxies Ativos Adaptação dinâmica de Serviços –Tradução de protocolos e tipos de dados; –Adequação de protocolos; –Adequação da apresentação; Acesso seguro a serviços de clientes diversos –Adaptar necessidades de segurança do serviço a capacidades do cliente; Fusão de múltiplos dispositivos –Composição de recursos, capacidades e confiabilidades;
15
15 Serviço de Detecção de Serviços Permite que serviços se anunciem e que sejam localizados; Repositório escalável, tolerante a falhas e seguro; 443 Phaser io.printer Soda/443 yes czerwin@cs Where is a color printer? The SDS 443 Phaser “443 Phaser” io.printer yes XML Query Service Description
16
16 SDS - funcionamento SDS Server Client Printer Music Server Backup SDS Server Anúncios do Servidor Periódico para detecção de falhas Provê todos os parametros Anúncio dos serviços Endereço do multicast recebido Periódico Contém descrição Queries do cliente: Endereço SDS do servidor Envia especificação do serviço Recebe descrição e URL
17
17 SDS - Segurança Controle de acesso –Serviços definem quem pode “descobrí-los” Certificate Authority; –Autenticação de mensagens Cabability Manager; –Acceess control lists Defesas contra DOS ?
18
18 SDS – wide-area Hierarquização –Critérios diversos (topologia, domínios administrativos...); –Divisão de carga; –Roteamento das queries; –Um mesmo servidor em diversas hierarquias; Filtragem da informação a ser propagada acima;
19
19 SDS - Funcionamento Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ?
20
20 SDS - Funcionamento Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ? Room 443
21
21 SDS - Funcionamento Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ?
22
22 SDS - Funcionamento Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ? Consistência x Perfomance...
23
23 SDS – Performance Para um único Servidor SDS... Latência vem principalmente de conexões de transporte autenticadas e checagem de capacidades usando Cryptix. Estimativa de que 1 Servidor pode servir cerca de 500 usuários adequadamente.
24
24 Caminhos Mecanismo de criação automática de caminhos; Conectores –Canal para transmissão de dados –Esconde diferenças de protocolos Operadores –Fazem computações nos dados –Descrição incluindo requisitos, capacidades e dados de performance –Long-lived e criados dinamicamente Caminhos – Coleção de operadores e conectores que provê um serviço
25
25 Caminhos - criação Caminhos possíveis Escolha de um caminho Instanciação real. Monitoração
26
26 Ninja - Aplicações Ninja Jukebox –Exemplo de facilidade na adição de novos serviços; NinjaMail –Workers para diferentes tipos de interação Kereitsu –Composição horizontal de serviços
27
27 Trabalhos relacionados CORBA e DCOM não suportam diretamente composição e agregação de componentes; Jini não é escalável para WANs App Servers não utilizam programação baseada em eventos nem DDS
28
28 Questões Futuras Como gerenciar recursos em uma rede descentralizada e dinâmica de proxies ativos; Novos modelos de negócios baseados na disponibilização de serviços e recursos; Automaticamente compôr serviços;
Apresentações semelhantes
