Grid AnywhereUm Middleware Extensível para Grades Computacionais

Fabiano Costa Teixeira (fabianocosta.txa@gmail.com)

Orientador: Prof. Dr. Marcos José Santana (mjs@icmc.usp.br)

Roteiro

• Introdução• Grid Anywhere– Sam Dog– WSBCL– Sesiom– API Grid Anywhere

• Conclusões

Introdução

• Indústria de hardware necessita acompanhar a indústria de software.

• A forma de ofertar computação vem sendo alterada com o passar dos anos

Grades Computacionais• Permitem o compartilhamento de recursos entre

participantes heterogêneos e distribuídos• Formação de organizações virtuais– Instituições conhecidas– Regras de uso– Poucos provedores muitos consumidores

• Diversos tipos de recursos– Processamento– Armazenamento– Software– Entre outros

Grades Computacionais

Traduzido de: Foster, "The Grid: A New Infrastructure for 21st Century Science," Physics Today, vol. 55, pp. 42-47, 2002

Grades Computacionais Desktop

• Formadas por computadores pessoais• Voluntários “trabalham” para um projeto de

uma determinada instituição: modelo “mestre/trabalhador”

• Muitos provedores e poucos consumidores• Bag of Tasks• Middlewares:– BOINC– QADPZ– SKTAKI

Computação em Nuvem• Realizar a oferta de recursos computacionais

como serviço• Modelos:– Infraestrutura como serviço (IaaS)– Software como serviço (SaaS)– Plataforma como serviço (PaaS)

• Algumas características– Contabilização e cobrança pelos recursos– Qualidade de serviço– Monitoramento e gerenciamento

Computação em Nuvem

Traduzido de: R. Buyya, S. Pandey, and C. Vecchiola, "Cloudbus toolkit for market-oriented cloud computing," Cloud Computing, pp. 24-44, 2009

Motivação

• Computação em grade tem tido uma aplicação fortemente voltado para a área científica

• Computação em nuvem é aplicada aos usuários convencionais, com ampla utilização de provedores comerciais

• Aplicação de um modelo hibrido viabiliza a utilização de recursos remotos gratuitos por usuários comuns

Motivação

Traduzido de: I. Foster, Y. Zhao, I. Raicu, and S. Lu, “Cloud computing and grid computing 360-degree compared," in Grid Computing Environments Workshop, 2008, pp. 1-10

Motivação

• Middlewares atuais são voltados para a solução de arquiteturas específicas

• O tempo para adequar a novas demandas é relativamente alto

• Necessidade de um middleware com alta adaptabilidade

Objetivos

• Disponibilizar um modelo e uma implementação de middleware flexível

• Permitir a participação de usuários comuns como consumidores em uma grade

• Aumentar a oferta de potência computacional em grades desktop

• Muitos provedores e muitos consumidores!

Grid Anywhere• Middleware extensível para grades

computacionais

• Núcleo principal permite que funcionalidades sejam acopladas para que seja possível se adequar a novas arquiteturas

Grid Anywhere

Segurança

Escalonamento

Interoperabilidade

Transporte de Aplicações

Conectividade

Execução e gerenciamento

Programação

Transferência de arquivos

Sam Dog• Arquiteturas das grades atuais

não tem um número muito grande de consumidores

• O aumento desse número e a pouca experiência dos provedores são um “gargalo”

• Sam Dog é um ambiente seguro de execução de aplicações (SandBox)

Sam Dog: Regras em Cascata

Disco: Todos Disco: Usuários da Universidade

Rede: MariaRede: Todos Rede: Ninguém

(USP) (ICMC) (LASDPC)

Sam Dog: Regras em Cascata

• LASPDC não tem condições de gerenciar todas as suas regras, mas ele confia na administração feita pelo instituto

Disco: Usuários da Universidade

Rede: NinguémRede: Maria

Sam Dog: Regras em Cascata

• O instituto faz uso das regras estabelecidas pela universidade e depois especifica suas necessidades

Disco: Todos

Rede: Todos

Disco: Usuários da Universidade

Rede: NinguémRede: Maria

Sam Dog: Gerenciadores de Domínio de Segurança

Sam Dog: Entidades e Grupos

Sam Dog: Tarefas

Tarefas

...IO

File System Network

Aceitarconexões

Solicitarconexões

Sam Dog: Composição de Entidades e Tarefas

• Estruturas de tarefas e entidades são compostas no momento de estabelecer uma regra

– regra(aceitar,usp.icmc.lasdpc,tarefas.io);

– regra(rejeitar,usp.icmc.lasdpc.alunos.joao,tarefas.io.network.solicitarconexoes);

Sam Dog: Composição de Entidades e Tarefas

Para a=S(G)-1 até 0, faça Para b=S(E)-1 até 0, faça Para c=S(T)-1 até 0, faça ProcureRegraGSD(G[a], I(E,b), I(T,c)) Se a regra for encontrada Execute a ação especificada Pare FimSe FimPara FimParaFimPara

• G: Identificador do GSD• E: Identificador da entidade• T: Identificador da tarefa• S(X): Número de níveis no identificador X• I(X,Y): Identificador X parcial. Do nível 0 até Y

Regras encontradas são armazenadas em uma cache!

Sam Dog: Contexto de Execução

• Para cada tarefa são informadas as possíveis variáveis de contexto

• Ao definir uma regra essas variáveis podem ser organizadas em uma sentença lógica

• São suportados operadores:– Relacionais: =, <, <=, >, >=, !=– Lógicos: and, or

Sam Dog: Documento de Regras

<sam> <rule> <entity>usp.icmc.lasdpc.professores.daniel</entity> <task>tarefas.io.network.aceitarconexoes</task> <if> <expression> @porta=8080 and @hora>=0 and hora<7) </expression> <then> <command>accept()</command> </then> <else> <command>reject()</command> </else> </if> </rule><sam>

Sam Dog: GUI

Sam Dog: Java Security

Sam Dog: Avaliação de Desempenho

• Planejamento dos experimentos

Fator Níveis

Número de GSDs 2 e 3

Número de níveis na identificação de identidade da regra 5 e 10

Número de níveis na identificação de tarefa da regra 5 e 10

Número de regras existentes na política de segurança 5 e 10

Taxa de acerto de cache (%) 30 e 50

Sam Dog: Avaliação de Desempenho

Sam Dog: Avaliação de Desempenho

Sam Dog: Avaliação de Desempenho

WSBCL: Web Services Based Class Loader

• Classes Java são carregadas sob demanda

• Uma aplicação grande pode possuir muitas classes– Pode haver classes não utilizadas na execução– Levar todas as classes para o destino é complexo

em função do tamanho e da determinação das classes utilizadas

WSBCL: Web Services Based Class Loader

• Possibilidade de heterogeneidade das aplicações

• Classes podem estar localizadas em ambientes desfavoráveis– Conexões oriundas do ambiente externo podem

não ser viáveis– Equipamento que hospeda as classes pode possuir

capacidade limitada.

WSBCL: Arquitetura Básica

WSBCL: Relay

WSBCL: Flexibilidade de localização do Relay

WSBCL: Arquitetura do Relay

WSBCL: Avaliação de Desempenho

• Planejamento dos Experimentos

Fator Descrição NíveisLink Velocidade do link Ethernet utilizado 10/100mbpsServidor e Relay Juntos Determina se o relay de classes está na

mesma máquina que o servidor ativoSim/Não

Tamanho da Classe Tamanho da classe carregada 25k/50kAutenticado Utilização de autenticação Sim/NãoEstabelecimento de Sessão Estabelecimento de sessão antes da carga

da classeSim/Não

WSBCL: Avaliação de Desempenho

• Link de 10 MBPS

WSBCL: Avaliação de Desempenho

• Link de 100 MPBS

WSBCL: Avaliação de Desempenho

Sesiom

• Ambiente de hospedagem de objetos distribuídos• Problemas “atacados”:– Dinamismo das aplicações

– Segurança

– Persistência de estado de forma transparente ao programador

– Conectividade

Sesiom: Arquitetura em Camadas

Sesiom: Arquitetura em Blocos

SOAP Engine

Núcleo

Container Engine

Container

Controle de Admissão

Módulos dinâmicos

Monitor Adaptador deMiddleware Comunicador Replicador

Adaptador deMiddleware

Gerenciador de Mensagens

Sesiom: Arquitetura do Container

Sesiom: Chamada de Métodos

• Uso do protocolo SOAP• Header possui dois elementos:– OID (Object ID):• Atributo ID determina o identificador do objeto

– ReturnType:• Atributo RemoteReference define a forma de retorno

do método:– true: Armazena o objeto no container e retorna um novo ROI– false: Serializa e retorna o próprio objeto

Sesiom: SesiomLet

• Sesiom suporta qualquer tipo de objeto• SesiomLets são tipos de objetos que podem

interagir com o container:– Receber e enviar mensagens para outros

SesiomLets (locais ou remotos)– Realizar o tratamento de eventos:• Criação• Chegada • Migração• Destruição

Sesiom: Características Básicas da API

Gateway gw = new Gateway(<containerRelayAddress>,<wsdlWSBCL>,<containerId>);

<RemoteObject>ref=gw.migrateObject(<Object>,<wsbclRelayAddress>);

RemoteObject<Ref>=new RemoteObject(<Class>,<containerRelayAddress>,→<wsbclRelayAddress>,<containerId>);

RemoteObject<Ref>=(RemoteObject)<Ref>.execute(<Method>,true,<Par#1>,…,<Par#n>);

<Class><Ref>=(<Class>)<Ref>.execute(<Method>,false,<Par#1>,…,<Par#N>);

<Class><Ref>=(<Class>)<Ref>.getObject();

<Ref>.kill();

Destruição de Objeto

Recuperação de Objeto

Chamada de método remoto com retorno real

Chamada de método remoto com referência remota do retorno

Criação remota de objeto

Migração de Objeto

Criação do gateway para o container Sesiom

Sesiom: Estudo de Caso• Desenvolvimento de aplicação para classificação

de perfil de um cliente• Utilização de rede neural artificial multilayer

perceptrons (utilização da API Weka)• Treinamento realizado com base em:– Tipo de trabalho– Tempo de trabalho– Tempo de conta bancária– Garantia de fiador

• Cada cliente é classificado como uma classe de pontualidade A, B ou C.

Sesiom: Estudo de Caso

• Diagrama de classes já prevendo objetos remotos

Sesiom: Estudo de Caso

• Treinamento da rede com um banco de dados sintético contendo 30.000 clientes

• Implementação realizada em um notebook:– Processador Turion 64 bits de 2.2GHz– 2GB memória RAM

• Fase de treinamento no notebook: 4.5 minutos

Sesiom: Estudo de Caso• Ambiente de produção onde o cliente é um thinclient:

– Cyrix 266– 128 Ram– Linux Slitaz

• Não tem capacidade para realizar o treinamento da rede

Sesiom: Estudo de Caso• Utilização do Sesiom com o container em

execução em um I7 com 4GB RAM• Alterações de código necessárias:

import br.usp.icmc.lasdpc.sesiom.client.RemoteObject; 

NeuralNetwork nn = new NeuralNetwork();

rcd = new RemoteObject("NeuralNetwork", “http://192.168.0.100:8080/sosweb/sos?wsdl”,"http://192.168.0.100:8080/wsbclweb/wsbclService?wsdl",12345);

Importação da API

Modificação da criação da rede neural de:

Para:

Sesiom: Estudo de Caso• Alterações de código necessárias:

• Aplicação distribuída novamente no thinclient:– Treinamento realizado em 2.5 minutos

classCode = nn.classify(salaryRange,bankTime, guarantor,jobTime,jobType);

Modificação da chamada do método de classificação de:

Para:

classCode=(String)rcd.execute("classify",false,salaryRange,bankTime, guarantor,jobTime,jobType);

API GAW: Arquitetura de Camadas

API GAW: Arquitetura em Blocos

Container(Sesiom)

Gateway(Sesiom)

Provedor

Núcleo Provedor

Consumidor

Núcleo Consumidor

ControleAdmissão(Sesiom)

AdaptadorMiddleware

(Sesiom)

Escalonador Provedor

GerenciadorArquivos

AdaptadorContainer

GerenciadorMensagens

(Sesiom)

GerenciadorArquivos

Escalonador Consumidor

GerenciadorMensagens

(Sesiom)

Aplicação

ObjetoRemoto

Listener

Listener

Listener

Listener

Módulos estáticos

Módulos acopláveis

Módulos do Grid Anywhere

Módulos do Sesiom

Aplicação do usuário

Listener

API GAW: Notificações

• Arquivo XML descreve a política de notificações requisitada

• Núcleos enviam as notificações para os adaptadores que tem a função de propagá-las de acordo com o descritor

API GAW: SOAP Over SOAP

• Para disponibilizar uma grade computacional como infraestrutura de PaaS os problemas de conectividade devem ser observados

• De forma parecida com o WSBCL, o SOS (Soap Over SOAP) permite que os participantes sejam sempre “ativos”

API GAW: SOAP Over SOAP

API GAW: SOAP Over SOAPServidor Ativo

SOAP Engine Sesiom(SOAP #2)

Stub(SOAP #1)

SOAPEngine

HTTPEngine

HTTP

SOAP Envelope #1

Header #1

XML

Body #1

Cliente

Gateway Sesiom(SOAP #2)

HTTP Engine

SOAP Engine

Objetos Remotos

SOAP Envelope #2

XMLHeader #2

XML

Body #2

Aplicação Cliente

Stub(SOAP #1)

Gerenciador de Mensagens (Sesiom)

Gerenciador de Mensagens (Sesiom)

XML

API GAW: SOAP Over DTV

• TV Digital Interativa permite o envio de fluxo de dados juntamente com áudio e vídeo

• Receptor digital é um computador

• Carrossel de dados

• Até 2016 são esperados 80 milhões de aparelhos de TV

API GAW: SOAP Over DTV

API GAW: SOAP Over DTV

API GAW: SOAP Over DTV

Carrossel de DadosMultiplexador

Gerenciador de Mensagens

(Sesiom)

Middleware DTV

gaw.xml

Broadcast File Event

canal+sessão+seq.xml

Gerenciador de Mensagens

(Sesiom)

EmissoraReceptor

Broadcast File Listener

XLet

1

24

5

6

7

3

GAW: SOAP Over DTV

• Integração não depende de alterações do middleware

• Qualquer middleware JavaDTV pode ser utilizado– AstroTV (TOTVS)– Ginga

GAW: SOAP Over DTV

Conclusões• Módulos são independentes, podendo ser

aplicados em outros tipos de sistemas distribuídos

• Flexibilidade de composição dos módulos permite que o Grid Anywhere seja utilizado em cenários distintos de forma simplificada

• Implementação dos modelos oferece um produto em operação

Conclusões: Trabalhos Futuros

• Melhorar (criar) documentação

• Módulos de gerenciamento e instalação

• Permitir a execução de aplicativos existentes sem a necessidade de intervenção:– Java– Android

Perguntas?

Muito obrigado!(fabianocosta.txa@gmail.com)