Grid Anywhere Um Middleware Extensível para Grades Computacionais

Apresentação em tema: "Grid Anywhere Um Middleware Extensível para Grades Computacionais"— Transcrição da apresentação:

1 Grid Anywhere Um Middleware Extensível para Grades Computacionais
Fabiano Costa Teixeira Orientador: Prof. Dr. Marcos José Santana

2 Roteiro Introdução Grid Anywhere Conclusões Sam Dog WSBCL Sesiom
API Grid Anywhere Conclusões

3 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

4 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

5 Grades Computacionais
Traduzido de: Foster, "The Grid: A New Infrastructure for 21st Century Science," Physics Today, vol. 55, pp , 2002

6 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

7 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

8 Computação em Nuvem Traduzido de: R. Buyya, S. Pandey, and C. Vecchiola, "Cloudbus toolkit for market-oriented cloud computing," Cloud Computing, pp , 2009

9 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

10 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

11 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

12 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!

13 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

14 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

15 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)

16 Sam Dog: Regras em Cascata
Disco: Todos Disco: Usuários da Universidade Rede: Todos Rede: Ninguém Rede: Maria (USP) (ICMC) (LASDPC)

17 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

18 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

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

20 Sam Dog: Entidades e Grupos

21 Sam Dog: Tarefas Tarefas IO ... File System Network Aceitar conexões
Solicitar conexões

22 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);

23 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!

24 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

25 Sam Dog: Documento de Regras
<sam> <rule> <entity>usp.icmc.lasdpc.professores.daniel</entity> <task>tarefas.io.network.aceitarconexoes</task> <if> and hora<7) </expression> <then> <command>accept()</command> </then> <else> <command>reject()</command> </else> </if> </rule>

26 Sam Dog: GUI

27 Sam Dog: Java Security

28 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

29 Sam Dog: Avaliação de Desempenho

30 Sam Dog: Avaliação de Desempenho

31 Sam Dog: Avaliação de Desempenho

32 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

33 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.

34 WSBCL: Arquitetura Básica

35 WSBCL: Relay

36 WSBCL: Flexibilidade de localização do Relay

37 WSBCL: Arquitetura do Relay

38 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

39 WSBCL: Avaliação de Desempenho
Link de 10 MBPS

40 WSBCL: Avaliação de Desempenho
Link de 100 MPBS

41 WSBCL: Avaliação de Desempenho

42 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

43 Sesiom: Arquitetura em Camadas

44 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

45 Sesiom: Arquitetura do Container

46 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

47 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

48 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();

49 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.

50 Sesiom: Estudo de Caso Diagrama de classes já prevendo objetos remotos

51 Sesiom: Estudo de Caso Treinamento da rede com um banco de dados sintético contendo 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

52 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

53 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", “ "

54 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);

55 API GAW: Arquitetura de Camadas

56 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

57 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

58 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”

59 API GAW: SOAP Over SOAP

60 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

61 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

62 API GAW: SOAP Over DTV

63 API GAW: SOAP Over DTV

64 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

65 GAW: SOAP Over DTV Integração não depende de alterações do middleware
Qualquer middleware JavaDTV pode ser utilizado AstroTV (TOTVS) Ginga

66 GAW: SOAP Over DTV

67 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

68 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

69 Perguntas?

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