ourgrid grids computacionais: da computação de alto desempenho a serviços sob demanda walfredo...

OurGrid

Grids Computacionais: Da Computação de Alto Desempenho a Serviços sob Demanda

Walfredo Cirnewalfredo@dsc.ufcg.edu.br

Elizeu Santos-Netoelizeu@dsc.ufcg.edu.br

Laboratório de Sistemas Distribuídos - LSDUniversidade Federal de Campina Grande - UFCG

2

Grids Computacionais• A metáfora da Rede Elétrica

Grid Computacional(fonte de serviços e

recursos)

3

Para que serve um Grid?

4

Para que serve um Grid?

5

Para que serve um Grid?

6

Para que serve um Grid?

7

O Impacto de Grids

VR Simul

Grid Auditing

MegaCiclos

Databank Inc.

Mastercard

Embratel

8

Histórico de Grids

• A idéia de Grid surgiu na comunidade de Computação de Alto Desempenho há pouco menos de 10 anos– Agora os primeiros Grids para Alto Desempenho

começam a entrar em produção

• Há 3 anos, o mainstream da computação percebeu a possibilidade de usar tecnologia Grid para transformar computação em serviço– A tecnologia Grid está se fundindo com Web Services

• Grids para Alto Desempenho = Grids de Serviço + Serviço de Execução Remota

9

Agenda

• Histórico

• Grids de Serviços– Aspectos Fundamentais

• Grids para Alto Desempenho– Desafios adicionais

10

Serviços Computacionais

• Definição de Serviço– Mercadoria imaterial provida por uma entidade

legal para satisfazer as necessidades de outra entidade

• Arquiteturas Orientadas a Serviços (SOA)• Já existiam tecnologias para SOA

– Ex.: CORBA, RMI, etc...

• Interoperabilidade é muito importante– Padronização– Fraco acoplamento– Web Services

11

Grids de Serviços

• Infra-estrutura de Serviços sob Demanda

• Características– Heterogeneidade– Dispersão– Controle Distribuído– Vários Domínios Administrativos

• Interoperabilidade– Padronização

12

Aspectos Fundamentais

• Descoberta de Serviços

• Autenticação e Autorização

• Auditoria de Serviços

• Composição de Serviços

• Incentivos para Disponibilização de Serviços

• Padronização

13

Descoberta de Serviços

• Fundamental para Serviços sob Demanda

• Uma visão simples da arquitetura“Catálogo”

Cliente Provedor de Serviços

requisição

resposta

publicaconsulta

14

Descoberta de Serviços

• Universal Description, Discovery and Integration (UDDI)

15

UDDI

• Baseado em padrões– HTTP, XML, XML Schema e SOAP

• Tipos de buscas– Encontrar implementações que seguem uma

dada interface– Determinar os protocolos de segurança e

transporte suportados por um dado serviço– Por palavra chave

• Permite esquema publish/subscribe

16

MDS

• Monitoring and Discovery System– Index Service– Trigger Service– Aggregator Service

• Utilização – Escalonamento e seleção de réplicas– Avaliar estado dos serviços– Notificação sobre a situação de serviços e

recursos

• Globus Toolkit 4 (MDS4)

17

Pesquisa em Descoberta de Serviços• Abordagem P2P

– WSPDS – Web Service P2P Discovery Service

• Baseado na especificação do protocolo Gnutella

• Provê busca semântica– Semantic-annotated WSDL é tendência

• Não permite esquema de publish/subscribe

• Não provê um esquema semelhante ao Trigger Service

18

Aspectos Fundamentais

• Descoberta de Serviços

• Autenticação e Autorização

• Auditoria de Serviços

• Composição de Serviços

• Incentivos para Disponibilização de Serviços

• Padronização

19

Autenticação e Autorização

• Com vários domínios administrativos, como se dá a autenticação e autorização?

• Idealmente gostaríamos de ter um login único

• Segurança é um aspecto muito importante

• Algumas especificações– WS-Security

• Mensagens SOAP assinadas e criptografadas

– WS-SecureConversation• Contexto seguro para troca de mensagens

– WS-Policy• Define políticas de uso do serviço

20

Autenticação e Autorização

• Globus GSI – Grid Security Infrastructure– Transport-level security

• Privacidade no canal de comunicação

– Message-level security• Proteção das mensagens SOAP

• Autenticação baseada em:– Certificados X.509 / Login

• Autorização baseada em:– grid-mapfile – SAML – Security Association Markup

Language

21

Autenticação e Autorização

Mensagem

Autorização

SOAP SOAP SOAP

SAML/gridmap gridmap SAML/gridmap

Message LevelX.509 Certificates

Delegação

Autenticação

WS-SecurityWS-SecureContext

X.509 WS-Trust

X.509 login

Proteção daMensagem

WS-Security TLS (a.k.a. SSL)

Transport LevelX.509 Certificates

Message LevelLogin

X.509 WS-Trust

X.509

22

Aspectos Fundamentais

• Descoberta de Serviços

• Autenticação e Autorização

• Auditoria de Serviços

• Composição de Serviços

• Incentivos para Disponibilização de Serviços

• Padronização

23

Auditoria de Serviços

• Clientes e Provedores desejam garantias

• SLA – Service Level Agreements (contrato)

• Falta de confiabilidade entre as partes– Provedor pode não fornecer o serviço como

prometido no contrato– Cliente pode não cumprir o contrato de

utilização do serviço

• Mecanismos de Auditoria

• Monitoração de Serviços e Clientes

24

Auditoria de Serviços

• O consumidor pode confirmar o cumprimento através de um inspetor

25

Auditoria de Serviços

• Ainda é necessário um auditor para tornar o processo de verificação completo

• A intervenção pode ser indesejada

26

Auditoria de Serviços

• Reduzindo a possibilidade de intervenção

• Auditor pode sugerir mudanças– Ex.: bloqueio na comunicação

27

Aspectos Fundamentais

• Descoberta de Serviços

• Autenticação e Autorização

• Auditoria de Serviços

• Composição de Serviços

• Incentivos para Disponibilização de Serviços

• Padronização

28

Composição de Serviços

• Construção de novos serviços através da agregação de funcionalidades

• Novos serviços baseados em serviços mais básicos

• Uma agência de turismo fornece o serviço de venda de pacotes de viagens compondo serviços de reserva em hotéis, locadora de carros, consulta em administradoras de cartões de crédito, etc...

29

Composição de Serviços

• Vantagens– Abstração da Complexidade– Reutilização de funcionalidades

• Paradigmas de composição– Orquestração– Coreografia

• Linguagens para composição– Definem um fluxo para integração de serviços– XLANG, WSFL, BPEL– BPEL = WSFL (IBM) + XLANG (Microsoft)

30

Algo mais sobre BPEL

• BPEL é baseada no paradigma de Orquestração

• Exemplo de elementos da sintaxe

<invoke>, <receive>, <reply>, <assign><throw>, <wait>, <terminate>

<sequence>, <flow>, <switch>, <while>, <pick>

31

Aspectos Fundamentais

• Descoberta de Serviços

• Autenticação e Autorização

• Auditoria de Serviços

• Composição de Serviços

• Incentivos para Disponibilização de Serviços

• Padronização

32

Incentivando Participação

• Um Grid é composto por vários sites, de domínios administrativos distintos

• Usuários querem garantias sobre seus serviços e recursos locais

• Usuários querem mais serviços e recursos além dos seus locais

• Como incentivar sites a disponibilizar serviços em um Grid?

33

Modelos Econômicos

• Alguns Modelos:– Commodity Market, Posted Price Market,

Auction, etc

• Ex.: GRACE - GRid Architecture for Computational Economy– Baseado em Posted Price Market

• Depende de uma infra-estrutura pesada:– Moeda digital, bancos, etc...

• Nem todas aplicações precisam de garantias de QoS

34

OurGrid: Um Grid Best Effort

• Será que todas aplicações exigem Qos?

• Será que é possível incentivar a criação de grids sem a motivação financeira?

• OurGrid: Uma Rede de Favores – Usuários locais sempre têm prioridade nos

recursos locais– Recursos ociosos são doados para

comunidade– A grande questão é como fazer esta doação de

forma justa

35

Evitando free riders

• É fundamental ter um mecanismo que incentive os participantes a doarem recursos ociosos– Em sistemas como KaZaA, a maioria é free rider

• OurGrid usa um sistema de reputação peer-to-peer– Todos os peers mantém um balanço local de todos os

peers conhecidos

– Peers com maior balanço têm prioridade

– O comportamento emergente do sistema como um todo é “quanto mais você doa, mais você recebe”

– Isso funciona sem requerer infra-estrutura adicional

36

cliente A

B

C

D

E

Rede de Favores [1]

ConsumerFavorProviderFavorReport

*

*

* = sem recursos ociososB 60

D 45

37

Rede de Favores [2]

A

B

C

D

E

B 60

D 45

E 0

ConsumerQuery

ProviderWorkRequest

*

* = sem recursos ociosos

*

cliente cliente

38

E o free rider?

• Epsilon é a fração dos recursos consumida por free riders

39

Equidade entre colaboradores

40

Aspectos Fundamentais

• Descoberta de Serviços

• Autenticação e Autorização

• Auditoria de Serviços

• Composição de Serviços

• Incentivos para Disponibilização de Serviços

• Padronização

41

Padronização

• Open Grid Services Architecture – OGSA– Define padrões arquiteturais e requisitos para a

infra-estrutura– OGSA = O que?

• Open Grid Services Infrastructure – OGSI– Define o comportamento e relacionamento dos

componentes da arquitetura– OGSI = Como?– Globus Toolkit 3

• Alinhamento com Web Services– Web Service Resource Framework - WSRF

42

WSRF• Stateless ou Stateful• OGSI define:

– Stateful Web Services = Grid Services

• WSRF evoluiu de OGSI– Stateful Web Services = Web Service + Stateful

Resources– Introdução do conceito WS Resource– Quem possui estado agora é um “Recurso” controlado

pelo Serviço– Padronização no gerenciamento de estados– Recurso tem uma conotação diferente daquela usada

pela comunidade de Alto Desempenho, o que torna esta discussão um pouco confusa

43

Esclarecendo...

Apache ApolloGlobus Toolkit 4

Apache Muse

Apache Addressing

Apache Hermes

HTTP Server

Application Server

SOAP Engine

Web Service

End Point Reference

Web Service

WSRFWS-NotificationWSDM

Apache HTTP ServerMicrosoft IIS

TomCatWebSphere

Apache Axis

WS-Addresing

44

Agenda

• Histórico

• Grids de Serviços– Aspectos Fundamentais

• Grids para Alto Desempenho– Desafios Adicionais

45

Grids para Alto Desempenho

• Grids surgiram como plataformas de execução de aplicações paralelas– São os grids para alto desempenho

• Grids para alto desempenho necessitam do serviço de execução remota– Maior flexibilidade

• Serviço pode ser convertido em qualquer outro

– Maior complexidade• Segurança• Escalonamento

46

Plataformas de Execução de Aplicações Paralelas

• SMPs acoplamento

• MPPs

• NOWs

• Grids distribuição

47

SMP: Symmetric MultiProcessor

Memória

CPU

CPU

...

CPU

48

MPP: Massive Parallel Processor

CPU

Mem.

CPU

Mem.

CPU

Mem.

...

Escalonador

requisições

49

NoW: Network of Workstations

CPU

Mem.

CPU

Mem.

CPU

Mem.

...

requisições requisições requisições

50

Grids

CPU

Mem.

CPU

Mem.

CPU

Mem.

...

Internet

51

Características das Plataformas de Execução

  SMPs MPPs NOWs Grids

Conectividade excelente muito boa boa média/ruim

Heterogeneidade nula baixa média alta

Compartilhado não não sim sim

Imagem única comum comum múltipla

Escala 10 1.000 1.000 100.000

52

Grids podem diferir bastante

• TeraGrid – 4 centros de supercomputação norte-americanos

– Cada centro com milhares de processadores dedicados ao TeraGrid

– Canais de altíssima velocidade (40 GBits/s)

– Poder agregado de 13,6 TeraFlops

• SETI@home– Ciclos ociosos de 3.6 milhões de processadores

espalhados em 224 países

– Computa em média a uma velocidade de 14 Teraflops

53

Desafios Adicionais em Grids para Alto Desempenho• Execução Remota e Identidade Local

• Imagem do Sistema

• Proteção dos Recursos e das Aplicações

• Escalonamento

54

Globus GRAM e GSI

• Mapeamento seguro da identificação GSI global para um userid local– Global: C=US, O=University of California San

Diego, OU=Grid Computing Lab, CN=Walfredo Cirne

– Local: walfredo (em thing1), u15595 (em bh)

• Submissão e controle de tarefas via GRAM– Independência do escalonador de recurso– Proxy para delegação de autenticação

55

Globus GRAM e GSI

56

Imagem do Sistema

• Imagem do sistema são as abstrações que nos permite lidar com um sistema computacional– Arquivo, diretório, processo, usuário, grupo, etc

• Com vários domínios administrativos, a imagem do sistema é heterogênea– Complica tremendamente o uso do Grid

• Soluções– Imagem do sistema implementada a nível de usuário

[exemplo: Condor]

– Novas abstrações para se lidar com o Grid [exemplo: MyGrid]

57

Redirecionamento de System Calls do Condor

58

Abstrações OurGrid

• Máquina base máquina do grid

• Tarefa = inicial + remota + final– inicial e final rodam na máquina do grid– remota roda na máquina do grid

• Armazenamento– Playpen– Storage– Transferência de arquivos/Espelhamento

59

Fatorando com OurGrid

task:init: put ./Fat.class $PLAYPENremote: java Fat 3 18655 34789789799 output-$TASKfinal: get $PLAYPEN/output-$TASK results

task:init: put ./Fat.class $PLAYPENremote: java Fat 18656 37307 34789789799 output-$TASKfinal: get $PLAYPEN/output-$TASK results

task:init: put ./Fat.class $PLAYPENremote: java Fat 37308 55968 34789789799 output-$TASKfinal: get $PLAYPEN/output-$TASK results

....

60

Segurança

• Autenticação e Autorização– Requisito de qualquer grid, porém insuficiente

quando há execução remota

• Proteção do Recurso– Recurso roda código de terceiros

• Proteção da Aplicação– Aplicação roda em recurso de terceiros

• Privacidade dos Dados– Dado é processado em recurso de terceiros– Problema muito complexo!!

61

Proteção ao Recurso

• Política por aplicação através de interceptação de system call– Fácil de instalar, suporta qualquer linguagem,

difícil de configurar para garantir segurança

• Virtualização específica: Java– Fácil de instalar, suporta linguagem específica,

fácil de configurar

• Virtualização geral: VMWare, Virtual PC, Xen– Difícil de instalar (especialmente Xen), suporta

qualquer linguagem, fácil de configurar

62

GridBox: Interceptação de System Call

• Interceptação pela substituição de shared libraries

• Define política de acesso por aplicação#Allow read-write access#to "input.txt"and "output.txt"rule fopen allow input.txtrule fopen allow output.txt#Allow read-only access to#/etc/hosts filerule fopen readonly /etc/hosts#Disable all other accessesrule fopen deny *#Limit maximum file sizelimit FILE_SIZE 1000000

#Allow connections to trusted machinesrule connect allow 200.18.98.120:80rule connect allow 200.18.98.132:80rule connect allow 200.18.99.221:80#Allow SSH connectionrule connect allow 200.18.98.22:22#Disallow any other connectionrule connect deny *:*

63

SWAN: Segurança no OurGrid

• Aplicações Bag-of-Tasks só precisarem se comunicar para receber a entrada e devolver a saída – Isto é feito pelo próprio OurGrid

• A tarefa remota roda dentro de uma máquina virtual Xen, sem acesso a rede, e com acesso a disco limitado “por hardware” a uma partição especifica

64

Uma segunda linha de defesa

• Nós podemos também reiniciamos a máquina para adicionar uma segunda linha de defesa

• Isto também tem a vantagem extra de possibilitar o uso de um SO diferente– Ou seja, mesmo que a máquina seja Windows,

nós ainda podemos ter Linux

• Retornar ao Windows é muito rápido graças a hibernação

65

Arquitetura SWAN

reboot

Guest OS

Grid OS

Grid Middleware

Grid Application

Host OS

NativeApplication

reboot

Guest OS

Grid OS

Grid Middleware

Grid Application

Guest OS

Grid OS

Grid Middleware

Grid Application

Host OS

NativeApplication

Host OS

NativeApplication

66

Escalonamento de Aplicação

• Não é possível ter um escalonador controlando o Grid– Tamanho e dispersão– Múltiplos domínios administrativos

• Escalonadores de recurso– Controlam alguns recursos no Grid

• Escalonadores de aplicação– Escolhem quais recursos usar– Particionam o trabalho da aplicação

67

Escalonamento de Aplicação

...

Application Scheduler

Application Scheduler

Resource Scheduler

...

...

Resource Scheduler

Resource Scheduler

...

Escalonador de Aplicação

Escalonador de Aplicação

Escalonador de Recurso

Escalonador de Recurso

Escalonador de Recurso

68

Escalonador de Aplicação

• Necessita de informações sobre o Grid– Sistemas de monitoramento: NWS, Remos– Informações de monitoração são usadas em

previsões de performance

• Necessita de um modelo de performance da aplicação– Portanto, funciona apenas para uma classe de

aplicações

69

Distribuição de Trabalho Jacobi para um MPP

70

Jacobi AppLeS• Escalonador pioneiro para Jacobi 2D

• Escolhe quais processadores usar

• Distribui o trabalho entre os processadores escolhidos

• Usa predições NWS

• Usa um modelo de performance de Jacobi– Ti = Ai Pi + Ci, onde:

– Ti é o tempo para o processador i executar uma iteração

– Ai é a área da submatriz alocada ao processador i

– Pi é o tempo que o processador i leva para computar um elemento

– Ci é o tempo que o processador i leva para comunicar suas

fronteiras

71

Distribuição de Trabalho AppLeS Jacobi

72

Work Queue with Replication

• Solução de escalonamento para aplicações Bag of Tasks

• Não depende de informação sobre o Grid ou sobre as tarefas

• Envia uma tarefa para cada máquina disponível

• Quando não há mais tarefas para enviar, as ainda em execução são replicadas

• Eficiente, mas desperdiça ciclos • Escalonador do OurGrid

73

Desempenho do WRQ

76

Usando o Grid contra a AIDS

B,c,F

HIV-2HIV-1

M

O ABCD FGHJK

N?prevalent in Europe and Americasprevalent in Africa

majority in the world

18% in Brazil

77

HIV protease + Ritonavir

Subtype B

Subtype F

78

OurGrid da luta contra AIDS

• 55 máquinas em 6 sites no Brasil e EUA

• Tarefa = 3.3 MB entrada, 1 MB saída, 4 a 33 minutos de execução dedicada

• Rodou 60 tarefas em 38 minutos

• Speed-up = 29.2 (com 55 máquinas)

79

http://status.ourgrid.org

80

Conclusões e Tendências

• Grids de Alta Performance estão se consolidando

• Grids de Serviços fazem parte do futuro da computação distribuída– Interoperabilidade e Padronização são

palavras de ordem– WSRF e padrões correlatos tendem a se tornar

um padrão de fato

81

Algumas Referências

• http://www.ourgrid.org

• http://www.globus.org

• http://www.cs.wisc.edu/condor/

• http://ggf.org

• http://gridcafe.web.cern.ch/gridcafe/

82

Muito Obrigado!

Slides em http://walfredo.dsc.ufcg.edu.bre http://www.lsd.ufcg.edu.br/~elizeu

83

Fim