The Ninja Architecture for Robust InternetScale Systems and Services
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
Roteiro
•
•
•
•
•
Introdução
Arquitetura
Implementação
Resultados
Conclusões
2
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;
3
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
4
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
5
Arquitetura Ninja – Visão Geral
6
Bases – Serviços e estágios
• Condicionando o Serviço...
• Processamento dos serviços divido em
Estágios
– Distribuição
– Paralelismo
funcional
7
Bases – Estágios
• Design Patterns
– compôr e condicionar estágios
8
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;
9
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;
10
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??
11
Bases – Persistência
• DDS.
12
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 (???)
13
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;
14
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;
The SDS
Where is a
color printer?
czerwin@cs
<query>
<type> io.printer </type>
<color> yes </color>
</query>
443 Phaser
<service>
<name> 443 Phaser </name>
<type> io.printer </type>
<location> Soda/443 </location>
<color> yes </color>
<postscript> yes </color>
</service>
15
SDS - funcionamento
Queries do cliente:
SDS
Server
• Endereço SDS do servidor
• Envia especificação do serviço
• Recebe descrição e URL
Anúncios do Servidor
• Periódico para detecção de
falhas
• Provê todos os parametros
Backup
SDS
Server
Client
Anúncio dos serviços
• Endereço do multicast recebido
• Periódico
• Contém descrição
Printer
Music
Server
16
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 ?
17
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;
18
SDS - Funcionamento
Berkeley, US
UC Berkeley
UCB Physics
<type>fax
</type>
<color>yes
Soda Hall
ISRG
Kinko’s #123
Color Fax
SDS servers
</color>?
Room 443
czerwin@cs
IRAM
Hearst St
Services
Clients
19
SDS - Funcionamento
Berkeley, US
UC Berkeley
UCB Physics
<type>fax
</type>
<color>yes
Soda Hall
ISRG
Kinko’s #123
Color Fax
SDS servers
</color>?
Room 443
czerwin@cs
IRAM
Hearst St
Services
Clients
20
SDS - Funcionamento
Berkeley, US
UC Berkeley
Soda Hall
UCB Physics
<type>fax
</type>
<color>yes
ISRG
Kinko’s #123
Color Fax
SDS servers
</color>?
Room 443
czerwin@cs
IRAM
Hearst St
Services
Clients
21
SDS - Funcionamento
Berkeley, US
UC Berkeley
UCB Physics
<type>fax
</type>
<color>yes
Soda Hall
ISRG
Consistência x
Perfomance...
Kinko’s #123
Color Fax
SDS servers
</color>?
Room 443
czerwin@cs
IRAM
Hearst St
Services
Clients
22
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.
23
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
24
Caminhos - criação
Caminhos possíveis
Escolha de um
caminho
Instanciação real.
Monitoração
25
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
26
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
27
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;
28