1 Gerenciamento de Recursos em Sistemas de Grande Escala Jeferson R. Marques Fabio Kon Departamento de Ciência da Computação IME-USP

Apresentação em tema: "1 Gerenciamento de Recursos em Sistemas de Grande Escala Jeferson R. Marques Fabio Kon Departamento de Ciência da Computação IME-USP"— Transcrição da apresentação:

1 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 2 Roteiro  Grades computacionais  Gerenciamento de recursos no 2K  Extensão do modelo original  Resultado de alguns experimentos  Trabalhos relacionados

3 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 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 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 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 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 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 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 10 O Serviço de Gerenciamento de Recursos no 2K  Global Resource Manager (GRM)  Local Resource Manager (LRM)  Component Repository

11 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 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 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 14 LRM Solaris UltraSPARC LRM Windows PC LRM Linux PC LRM Solaris UltraSPARC LRM Linux PC GRM Repositório de 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 5 4 7 8

15 15 A nossa contribuição Motivaçã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 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 17 Arquitetura inter-agrupamento

18 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 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 20 Utilização do processador - GRM Período de consulta local: 30sPeríodo de envio de atualização: 60s

21 21 Utilização do processador - GRM

22 22 Número de mensagens - LRM Período de consulta local: 30sPeríodo de envio de atualização: 60s

23 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 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 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 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 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 28 2K - Arquitetura geral