steven d. gribble, matt welsh, rob von behren, eric a. brewer, david culler, n. borisov, c....
TRANSCRIPT
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
Roteiro
• Introdução• Arquitetura• Implementação• Resultados• Conclusões
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
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
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
Arquitetura Ninja – Visão Geral
7
Bases – Serviços e estágios
• Condicionando o Serviço...• Processamento dos serviços divido em
Estágios– Distribuição– Paralelismo
funcional
8
Bases – Estágios
• Design Patterns
– compôr e condicionar estágios
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
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
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
Bases – Persistência
• DDS.
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
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
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;
<service> <name> 443 Phaser </name> <type> io.printer </type> <location> Soda/443 </location> <color> yes </color> <postscript> yes </color></service>
czerwin@cs
Where is a color printer?
The SDS
443 Phaser“443 Phaser”
<query> <type> io.printer </type> <color> yes </color></query>
XML Query
Service
Description
16
SDS - funcionamento
SDSServer
Client
Printer MusicServer
BackupSDS
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
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
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
SDS - Funcionamento
Room 443
ISRG
UCB Physics
IRAM
UC Berkeley
Soda Hall Kinko’s #123
Berkeley, US
Hearst St
SDS serversServicesClients
czerwin@cs
Color Fax<type>fax</type><color>yes</color>?
20
SDS - Funcionamento
Room 443
ISRG
UCB Physics
IRAM
UC Berkeley
Soda Hall Kinko’s #123
Berkeley, US
Hearst St
SDS serversServicesClients
czerwin@cs
Color Fax<type>fax</type><color>yes</color>?
Room 443
21
SDS - Funcionamento
Room 443
ISRG
UCB Physics
IRAM
UC Berkeley
Soda Hall Kinko’s #123
Berkeley, US
Hearst St
SDS serversServicesClients
czerwin@cs
Color Fax<type>fax</type><color>yes</color>?
22
SDS - Funcionamento
Room 443
ISRG
UCB Physics
IRAM
UC Berkeley
Soda Hall Kinko’s #123
Berkeley, US
Hearst St
SDS serversServicesClients
czerwin@cs
Color Fax<type>fax</type><color>yes</color>?
Consistência x Perfomance...
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
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
Caminhos - criação
Caminhos possíveis
Escolha de um caminho
Instanciação real. Monitoração
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
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
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;