Distributed Computing in Practice: The Condor

Experience

Apresentado por Walfredo Cirne[Baseado nos slides de Marcelo Iury]

2

Projeto Condor

Situado na Universidade de Wisconsin-Madison

Objetiva desenvolver, implementar, implantar, e evoluir mecanismos e políticas para Computação de Alta Vazão (HTC) numa infra-estrutura distribuída e heterogênea.

Financiado pelo Governo Americano (DoD, DoE, NASA, NSF, NIH), AT&T, IBM, INTEL, Microsoft, …

3

Equipe

4

Motivação

Computação científica e problemas compute-intensive

High-Throughput Computing (HTC) (diferente de High Performance Computing)

Custo Wait-While-Idle

5

Diretiva de design: Flexibilidade Deixe o dono com o controle do recurso

Uso de políticas Donos felizes -> mais recursos

Deixe as comunidades crescerem naturalmente Requisitos e relacionamentos mudam Contratos não são precisos

Planeje sem ser exigente Não existe funcionamento ideal sempre

6

Condor

Explorar a capacidade de execução de recursos distribuídos considerando longos períodos de tempo.

High Throughput e Opportunistic Computing Recursos dedicados e não dedicados

Provê: Gerenciamento de aplicações Escalonamento Esquemas de prioridade Monitoração e gerenciamento de recursos

Aplicações são Bag of TasksCONDOR

7

Planejar × Escalonar

Tipicamente escalonamento é monolítico Mas não em Condor, pois há multiplos donos de recurso

Planejar é fazer com que o job do usuário rode mais rápido

Escalonar é o gerenciamento do recurso pelo seu dono

Planejar sobre escalonamento Posso melhorar o meu planejamento através de

informações do escalonamento Escalonar dentro do planejamento

8

Estrutura do Condor

User Problem Solver Agent Resource

Matchmaker

Shadow Sandbox

Job

Plan of jobs

job

ClassAds

claim

Details of the job

9

ClassAds

Esquema extensível Entradas são do tipo (atributo, valor) Requirements e Rank Representa de políticas e requisitos

Usuário Recurso Comunidade

O algoritmo de matching está disponível em C++ e Java Open Source

10

Formando uma comunidade

Matchmaker

Resource1

Resource3

Resource5

Resource2Resource4

AgentA

AgentB

Linux & Rank Mem

Mem=200

Match!Resource4

Mem=20& Unix

Mem=50& Linux

Mem=150& Linux

Mem=100& BSD

Mem=10& Windows

Mem=20

& Unix

Mem=50

& Linux

Mem=150

& Linux

Mem=100

& BSD

Mem=10

& Windows

11

Condor - protocolo

Agent

Solicitante

MatchMaker

Resource

Executora

contexto de J contexto da máquina

Faz um casamento entre o contexto de J

e da Executora

identificação de E

Shadow

forkrequisitos de J

ok, ESandBox

J

J

12

Execução Particionada

Cooperação entre o agente e a recurso Shadow e Sandbox

O shadow provê absolutamente tudo necessário para execução da aplicação Executável, argumentos, arquivos de entrada,...

O sandbox é responsável por oferecer um lugar seguro para a aplicação rodar Proteger o recurso

13

Universo de Execução

Ambiente de execução Condor provê:

Universo padrão Universo Java

14

Universo Padrão

Reproduz o ambiente do usuário

Chamadas I/O remota e redirecionamento System Calls sobre RPC seguro

Checkpoint Compilar a aplicação

com a biblioteca Condor C

15

Universo Java

Passado: Envio da JVM Ambiente de execução

Java Operações Java I/O

chama um proxy I/O gerenciado pelo sandbox

O proxy permite que ultrapassar obstáculos (e.g. firewalls)

16

Chamadas de Sistema Remotas O Condor provê a ilusão de execução na

máquina que submete a aplicação Tal ilusão conta com a ajuda do Remote Unix

(RU) RU provê um mecanismo de remote-system-

call A idéia é a de reforçar a segurança no lado

remoto Porém, dificulta a execução de aplicações

data-intensive.

17

Checkpoint

Provê tolerância a falhas Exige a recompilação da aplicação

Nem toda aplicação pode ser checkpointable Copia as informações necessárias em um arquivo

Segmentos de dados e pilha Registradores Arquivos abertos são salvos no segmento de dados do

programa O estado é escrito em um arquivo de checkpoint

(executável) na máquina que submeteu o job através do mecanismo de remote system call Também é possível ter um servidor de checkpoint

18

Flocking: Agrupando comunidades Centralização? Novas diretivas:

A instalação e manutenção de quaisquer mecanismos adicionais deve ser fácil

Adicionar e retirar uma comunidade de um agrupamento deve ser fácil

Deve ser fácil definir acordos de compartilhamento de recursos entre os donos das comunidades

Abordagens Agrupamento por gateway Agrupamento direto

19

Agrupamento por gateway

Gateway

Gateway

Comunidade Judaica

Comunidade Sobralense

20

Agrupamento - funcionamento

Agent

Solicitante

MatchMaker

GW-Startd

GW

Contextocontexto de J

GW

contexto de J

Startd child

Resource

E

MatchMaker

GW-Startd

GW

Shadow

contexto de J

contexto de J

E

GW-Simulate Shadow

OK,E

OK, E

J

J

21

Agrupamento direto

Comunidade Judaica

Comunidade Sobralense

22

Agrupamento: Considerações

Agrupamento por gateway Provê benefícios imediato e transparente para

todos os usuários Requer acordos organizacionais Administração complexa Não sobreviveu a evolução do Condor

Agrupamento direto Acordo entre um individuo e outra organização Benefício para o individuo que tomou a iniciativa

23

Condor + Globus

24

Condor-G

Permite usuários utilizarem recursos de múltiplos domínios como se ele pertencessem a um domínio pessoal.

Submissão de aplicações para vários tipos de sistemas batch PBS, LSF, Sun Grid Engine…

Fornece: Acesso a recursos remotos Gerenciamento de computação Ambiente de execução remota

Casamento do Condor com o Globus

25

Serviços usados no Condor-G

Grid Security Infrastructure (GSI) Prover uma autenticação única Mapeia as credenciais de acesso para mecanismos locais de

autenticação Gerenciamento das credenciais

Grid Resource Allocation & Management (GRAM) Acesso remoto de recursos e submissão de requisição Two-phase commit (Projeto Condor) Tolerância a falhas (Projeto Condor)

Armazena informação sobre aplicações ativas no agente Acopla alocação de recurso com execução de aplicação

GridFTP Transferência de arquivos

26

Funcionamento básico

GRAM GRAMGRAM

27

Protocolo GlideIn

28

Solucionador de Problemas

É um serviço de alto nível construído em cima do agente

Modelo de programação para gerenciar um grande número de aplicações master-worker

Ideal para Bag-of-tasks

directed acyclic graph manager (DAGMan) Execução de aplicações com dependências Permite execução de programas antes e após uma

aplicação

29

Condor no Mundo

30

NUG30 - Solved!!!

Sender: goux@dantec.ece.nwu.edu Subject: Re: Let the festivities begin.

Hi dear Condor Team,

you all have been amazing. NUG30 required 10.9 years of Condor

Time. In just seven days !

More stats tomorrow !!! We are off celebrating !

condor rules !

cheers,

JP.

31

Áreas de pesquisa

Serviços de gerenciamento de tarefas para aplicações Grid (Condor-G, Stork)

Serviços para gerenciamento de recursos (Condor, GlideIns, NeST)

Tecnologia de I/O distribuído (Parrot, Kangaroo, NeST)

Workflow para tarefas (DAGMan, Condor, Hawk) Monitoração e gerenciamento distribuído (HawkEye)

32

Considerações finais

Artigo bem organizado Apresenta a evolução do

sistema Estrutura permaneceu a

mesma, apesar da evolução

Várias soluções que podem ser usadas por outros sistemas.