1

Gerenciamento de Recursos em

Sistemas de Grande Escala

Jeferson R. Marques Fabio Kon

Departamento de Ciência da Computação IME-USP

http://gsd.ime.usp.br

2

Roteiro

Grades computacionais Gerenciamento de recursos no 2K Extensão do modelo original Resultado de alguns experimentos Trabalhos relacionados

3

Cenário atual

Computadores de alto poder de processamento exigem altos investimentos.

Empresas e instituições de ensino possuem redes locais com poder computacional equivalente.

Uma organização pode não possuir todos os recursos de que necessita.

Diminuição acentuada do custo de largura de banda.

4

Conseqüências (novos rumos)

Desenvolvimento de sistemas para computação paralela e distribuída. Computação em Agrupamentos (Cluster Computing) Computação em Grade (Grid Computing)

Estruturas capazes de gerenciar ambientes computacionais heterogêneos. Pioneiros: Globus Legion

Aplicações acessam os recursos: Sob demanda; Transparentemente, independendo da sua localização física.

5

Grades computacionais(Grid computing)

Computadores em diferentes localidades Rede de grande área Apropriados para computação intensiva, alto-desempenho Ambiente colaborativo Grande quantidade de dados Diferentes organizações

6

Grades computacionais(Grid computing)

Permitem compartilhar, agregar e escolher recursos computacionais dos mais variados tipos: supercomputadores dispositivos especiais - telescópios, radares, etc sistemas de armazenamento bancos de dados computadores comuns

7

Dificuldades

Localização dos recursos Reserva de recursos Capacidade para adaptar-se a mudanças no ambiente Criação e escalonamento das tarefas Autonomia de cada grupo participante para definir sua

próprias políticas de segurança Recursos requisitados podem estar em diferentes

localidades Qualidade de serviço exigida por cada aplicação

8

Futuro das grades computacionais

Aplicações baseadas na web vão usufruir dos benefícios das grades

Evolução de agrupamentos locais para os acessíveis mundialmente

Aluguel de recursos computacionais, principalmente daqueles relacionados a processamento

9

2K -Um sistema operacional distribuído para ambientes heterogêneos e dinâmicos

Illinois, 2000. Funcionalidades:

Gerenciamento de recursos em redes heterogêneas; Adaptação dinâmica; Configuração de aplicações distribuídas baseadas em

componentes. Destinado a facilitar o trabalho de:

Usuários; Administradores de sistema; Desenvolvedores.

Middleware reflexivo. CORBA

10

O Serviço de Gerenciamento de Recursos no 2K

Global Resource Manager (GRM) Local Resource Manager (LRM) Component Repository

11

O Serviço de Gerenciamento de Recursos do 2K

GRM (Global Resource Manager) 1 por agrupamento (2 a 100 máquinas) Mantém informações aproximadas sobre a

disponibilidade de recursos nas máquinas do agrupamento

Encaminha requisições para os nós apropriados de acordo com a qualidade de serviço solicitada

12

O Serviço de Gerenciamento de Recursos do 2K

LRM (Local Resource Manager) 1 por máquina do agrupamento Monitora os recursos da máquina Informa periodicamente o GRM de seu agrupamento

de eventuais alterações na disponibilidade de recursos da máquina

Responsável por executar localmente as componentes solicitadas por clientes

13

O Serviço de Gerenciamento de Recursos do 2K

Repositório de componentes (Component Repository) Armazena as componentes disponíveis no

sistema Se uma componente recém-iniciada depender

de outra, será do repositório que o sistema a carregará

14

LRM

Solaris

UltraSPARC

LRM

Windows

PC

LRM

Linux

PC

LRM

Solaris

UltraSPARC

LRM

Linux

PC

GRM Repositóriode Componentes

1. Cliente faz requisição especificando as condições para execução.2. LRM verifica se pode atender condições. Se não for possível, remete a requisição para o GRM do agrupamento.3. GRM procura por um candidato em seu banco de dados. GRM encaminha requisição para o candidato.

4, 5. LRM consulta a disponibilidade dos recursos pedidos. LRM carrega a componente do repositório de componentes.6. LRM executa a componente.7, 8. Envia resultado para o requisitante.

1

2

3

6

54

7

8

15

A nossa contribuiçãoMotivação

Estender o sistema a fim de permitir: formação de grades hierárquicas mundiais maior disponibilidade de recursos maior variedade de recursos escalabilidade

Dificuldades Incluir e remover agrupamentos com o mínimo de impacto no

sistema Identificar as informações relevantes que devem estar em cada nó Criar uma estrutura como base para o inter-relacionamento dos

agrupamentos

16

Abordagem

LRMs ficam inalterados. Mantém-se sua função original de comunicar-se com o GRM de seu agrupamento somente

GRM é estendido de forma que, além de lidar com requisições dos LRMs de seu agrupamento, sejam capazes de lidar com requisições de GRMs de outros agrupamentos da grade

GRM passa a armazenar também informações aproximadas sobre as condições dos recursos em agrupamentos vizinhos

17

Arquitetura inter-agrupamento

18

Procura por candidatos

Se uma requisição não puder ser atendida dentro do agrupamento: ela é encaminhada para o GRM do nível

imediatamente superior o GRM verifica em quais das suas sub-árvores é mais

provável que o recurso seja encontrado se não encontrar, o processo é repetido até que

encontre ou percorra toda a árvore

19

Dados armazenados no GRM

Média aritmética e desvio-padrão dos valores de cada recurso fornecido pelas subárvores Conseqüências

Diminui o período de latência para uma requisição percorrer a árvore

Aumenta a escalabilidade Torna o processo menos preciso, pois os dados são somente

uma dica da melhor sub-árvore

20

Utilização do processador - GRM

Período de consulta local: 30s Período de envio de atualização: 60s

21

Utilização do processador - GRM

22

Número de mensagens - LRM

Período de consulta local: 30s Período de envio de atualização: 60s

23

Globus Argonne National Laboratory, USA Globus Metacomputing Toolkit - serviços básicos:

alocação de recursos gerenciamento de recursos segurança outros

Limitações Não é orientado a objetos Baseado em bibliotecas em linguagem C Protocolos proprietários para comunicação Sem suporte para aplicações baseadas em componentes

24

Legion Virginia, 1993-hoje É uma arquitetura integrada, não uma soma de

serviços Orientado a objetos ORB ~ run-time system para invocações remotas Limitações:

“ORB” proprietário, não-padrão Sem suporte para consolidação de informações (???

não lembro...)

25

Trabalho em andamento

Propagação de informação na inclusão ou remoção de novos agrupamentos

Testes iniciais para execução de componentes entre os agrupamentos

26

Conclusão

Componentes do sistema causam pouco impacto nas máquinas, isto é, pouca sobrecarga

Protocolo de disseminação minimiza tráfego de mensagens intra-agrupamentos e inter-agrupamentos

27

Jeferson R. Marques(jmarques@ime.usp.br)

Fabio Kon(kon@ime.usp.br)

Para maiores informações

http://gsd.ime.usp.br/software/ResourceManagement

28

2K - Arquitetura geral