Distributed Computing in
Practice: The Condor
Experience
Apresentado por Walfredo Cirne
[Baseado nos slides de Marcelo Iury]
Projeto Condor



2
Situado na Universidade de WisconsinMadison
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, …
Equipe
3
Motivação




4
Computação científica e problemas computeintensive
High-Throughput Computing (HTC) (diferente
de High Performance Computing)
Custo
Wait-While-Idle
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
5
existe funcionamento ideal sempre
Condor


Explorar a capacidade de execução de recursos
distribuídos considerando longos períodos de
tempo.
High Throughput e Opportunistic Computing


Provê:





Recursos dedicados e não dedicados
Gerenciamento de aplicações
Escalonamento
Esquemas de prioridade
Monitoração e gerenciamento de recursos
Aplicações são Bag of Tasks
CONDOR
6
Planejar × Escalonar

Tipicamente escalonamento é monolítico




Planejar é fazer com que o job do usuário rode mais
rápido
Escalonar é o gerenciamento do recurso pelo seu
dono
Planejar sobre escalonamento


7
Mas não em Condor, pois há multiplos donos de recurso
Posso melhorar o meu planejamento através de informações
do escalonamento
Escalonar dentro do planejamento
Estrutura do Condor
Matchmaker
ClassAds
User
Problem Solver
Plan of
jobs
Agent
job
Resource
claim
Shadow
Sandbox
Details of the
job
Job
8
ClassAds




Esquema extensível
Entradas são do tipo (atributo, valor)
Requirements e Rank
Representa de políticas e requisitos




O algoritmo de matching está disponível em C++
e Java

9
Usuário
Recurso
Comunidade
Open Source
Formando uma comunidade
AgentB
Match!
Resource4
Resource1
Mem=10
Mem=10
& Windows
& Windows
Matchmaker
Mem=200
Mem=100
& BSD
AgentA
Linux & Rank Mem
Resource5
Mem=100
& BSD
Mem=20
& Unix
Resource2
Mem=20
& Unix
Mem=50
& Linux
Resource4
Resource3
Mem=50
& Linux
10
Mem=150
& Linux
Mem=150
& Linux
Condor - protocolo
MatchMaker
Faz um casamento
entre o contexto de J
e da Executora
contexto da máquina
contexto de J
identificação de E
Resource
Agent
fork
Shadow
requisitos de J
ok, E J
SandBox
J
Solicitante
11
Executora
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,

O sandbox é responsável por oferecer um
lugar seguro para a aplicação rodar
 Proteger
12
argumentos, arquivos de entrada,...
o recurso
Universo de Execução


Ambiente de execução
Condor provê:
 Universo
padrão
 Universo Java
13
Universo Padrão




14
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
Universo Java




15
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)
Chamadas de Sistema Remotas





16
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-systemcall
A idéia é a de reforçar a segurança no lado
remoto
Porém, dificulta a execução de aplicações
data-intensive.
Checkpoint


Provê tolerância a falhas
Exige a recompilação da aplicação


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

17
Nem toda aplicação pode ser checkpointable
Também é possível ter um servidor de checkpoint
Flocking: Agrupando
comunidades


Centralização?
Novas diretivas:




Abordagens


18
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
Agrupamento por gateway
Agrupamento direto
Agrupamento por gateway
Comunidade Sobralense
Gateway
Gateway
Comunidade Judaica
19
Agrupamento - funcionamento
MatchMaker
MatchMaker
contexto de J
Contexto
contexto de J
GW
E
GW-Startd
Agent
Shadow
Solicitante
Resource
contexto de J
OK, E
GW-Startd
contexto de J
GWSimulate
Shadow
Startd
child
GW
J
20
E
OK,E
GW
J
Agrupamento direto
Comunidade Sobralense
Comunidade Judaica
21
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
22
Condor + Globus
23
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


Fornece:




24
PBS, LSF, Sun Grid Engine…
Acesso a recursos remotos
Gerenciamento de computação
Ambiente de execução remota
Casamento do Condor com o Globus
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)



Acopla alocação de recurso com execução de aplicação
GridFTP

25
Armazena informação sobre aplicações ativas no agente
Transferência de arquivos
Funcionamento básico
GRAM
26
GRAM
GRAM
Protocolo GlideIn
27
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


28
acyclic graph manager (DAGMan)
Execução de aplicações com dependências
Permite execução de programas antes e após uma
aplicação
Condor no Mundo
29
NUG30 - Solved!!!
Sender: [email protected]
Subject: Re: Let the festivities begin.
Hi dear Condor Team,
you all have been amazing. NUG30 required
Condor Time. In just
seven days !
10.9 years of
More stats tomorrow !!! We are off celebrating !
condor rules !
cheers,
JP.
30
Áreas de pesquisa





31
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)
Considerações finais




32
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.