Post on 17-Apr-2015
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)