Grid Anywhere Um 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 Conclusões 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

Execução e gerenciamento Grid Anywhere Escalonamento Transferência de arquivos Segurança Execução e gerenciamento Transporte de Aplicações Interoperabilidade Conectividade Programação

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: Todos Rede: Ninguém Rede: Maria (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ém Rede: Maria

Sam Dog: Regras em Cascata O instituto faz uso das regras estabelecidas pela universidade e depois especifica suas necessidades Disco: Todos Disco: Usuários da Universidade Rede: Todos Rede: Ninguém Rede: Maria

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

Sam Dog: Entidades e Grupos

Sam Dog: Tarefas Tarefas IO ... File System Network Aceitar conexões Solicitar conexõ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 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 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 Número de regras existentes na política de segurança 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íveis Link Velocidade do link Ethernet utilizado 10/100mbps Servidor e Relay Juntos Determina se o relay de classes está na mesma máquina que o servidor ativo Sim/Não Tamanho da Classe Tamanho da classe carregada 25k/50k Autenticado Utilização de autenticação Estabelecimento de Sessão Estabelecimento de sessão antes da carga da classe

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 Controle de Admissão Gerenciador de Mensagens Núcleo Adaptador de Middleware SOAP Engine Container Engine Monitor Adaptador de Middleware Comunicador Replicador Container Módulos dinâmicos

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 Criação do gateway para o container Sesiom Gateway gw = new Gateway(<containerRelayAddress>,<wsdlWSBCL>,<containerId>); Migração de Objeto <RemoteObject>ref=gw.migrateObject(<Object>,<wsbclRelayAddress>); Criação remota de objeto RemoteObject<Ref>=new RemoteObject(<Class>,<containerRelayAddress>,→ <wsbclRelayAddress>,<containerId>); Chamada de método remoto com referência remota do retorno RemoteObject<Ref>=(RemoteObject)<Ref>.execute(<Method>,true,<Par#1>,…,<Par#n>); Chamada de método remoto com retorno real <Class><Ref>=(<Class>)<Ref>.execute(<Method>,false,<Par#1>,…,<Par#N>); Recuperação de Objeto <Class><Ref>=(<Class>)<Ref>.getObject(); Destruição de Objeto <Ref>.kill();

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: Importação da API import br.usp.icmc.lasdpc.sesiom.client.RemoteObject;  Modificação da criação da rede neural de: NeuralNetwork nn = new NeuralNetwork(); Para: rcd = new RemoteObject("NeuralNetwork", “http://192.168.0.100:8080/sosweb/sos?wsdl”, "http://192.168.0.100:8080/wsbclweb/wsbclService?wsdl",12345);

Sesiom: Estudo de Caso Alterações de código necessárias: Aplicação distribuída novamente no thinclient: Treinamento realizado em 2.5 minutos Modificação da chamada do método de classificação de: classCode = nn.classify(salaryRange,bankTime, guarantor,jobTime,jobType); Para: classCode=(String)rcd.execute("classify",false,salaryRange,bankTime, guarantor,jobTime,jobType);

API GAW: Arquitetura de Camadas

API GAW: Arquitetura em Blocos Provedor Listener Consumidor Listener Gerenciador Arquivos Gerenciador Arquivos Núcleo Consumidor Núcleo Provedor Escalonador Provedor Escalonador Consumidor Listener Listener Adaptador Container Aplicação Listener Adaptador Middleware (Sesiom) Container (Sesiom) Controle Admissão (Sesiom) Gateway (Sesiom) Gerenciador Mensagens (Sesiom) Gerenciador Mensagens (Sesiom) Objeto Remoto Módulos estáticos Módulos do Grid Anywhere Aplicação do usuário Módulos acopláveis Módulos do Sesiom

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 SOAP Servidor Ativo Cliente HTTP SOAP Engine HTTP HTTP Engine SOAP Engine SOAP Envelope #1 Header #1 XML Stub (SOAP #1) Stub (SOAP #1) Body #1 XML SOAP Envelope #2 Gerenciador de Mensagens (Sesiom) Gerenciador de Mensagens (Sesiom) Header #2 XML SOAP Engine Sesiom (SOAP #2) Gateway Sesiom (SOAP #2) Body #2 XML Objetos Remotos Aplicação Cliente

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 XLet 6 5 7 Broadcast File Event 1 4 canal+sessão+seq.xml Broadcast File Listener Gerenciador de Mensagens (Sesiom) 5 7 Broadcast File Event Gerenciador de Mensagens (Sesiom) 1 Carrossel de Dados gaw.xml 4 Multiplexador 2 3 Middleware DTV Emissora Receptor

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?

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