Distributed Computing in Practice: The Condor Experience Apresentado por Walfredo Cirne [Baseado nos slides de Marcelo Iury]

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, …

Equipe

Motivação Computação científica e problemas compute-intensive 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 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 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 Tasks CONDOR

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

Estrutura do Condor Matchmaker ClassAds User Problem Solver Agent Resource job Plan of jobs claim Shadow Sandbox Details of the job Job

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

Formando uma comunidade AgentB Match! Resource4 Resource1 Mem=10 & Windows Mem=20 & Unix Mem=50 & Linux Mem=150 Mem=100 & BSD Mem=10 & Windows Matchmaker Mem=200 AgentA Resource5 Linux & Rank Mem Mem=100 & BSD Resource2 Resource4 Mem=20 & Unix Resource3 Mem=150 & Linux Mem=50 & Linux

Condor - protocolo Faz um casamento entre o contexto de J e da Executora MatchMaker contexto de J contexto da máquina identificação de E Resource Agent requisitos de J ok, E SandBox Shadow fork J J Solicitante 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, argumentos, arquivos de entrada,... O sandbox é responsável por oferecer um lugar seguro para a aplicação rodar Proteger o recurso

Universo de Execução Ambiente de execução Condor provê: Universo padrão Universo Java

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

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)

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.

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

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

Agrupamento por gateway Comunidade Sobralense Gateway Comunidade Judaica

Agrupamento - funcionamento MatchMaker MatchMaker contexto de J GW Contexto contexto de J E GW-Startd GW GW-Startd GW Agent Solicitante Resource E contexto de J contexto de J Startd child GW-Simulate Shadow Shadow J J OK, E OK,E

Agrupamento direto Comunidade Sobralense Comunidade Judaica

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

Condor + Globus

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

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

Funcionamento básico GRAM GRAM GRAM

Protocolo GlideIn 1 2 3

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

Condor no Mundo

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.

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

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.