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;