Camada Resource: Partilha de Recursos Individuais

A camada resource é responsável por denir protocolos, APIs (Application programming interface) e SDKs (Software development kit). Os protocolos denidos por esta camada são, negociação de segurança, inicialização de tarefas, monitorização, controlo e contabi- lidade. Para que isto seja possível, os protocolos desta camada chamam funções denidas na camada fabric para aceder e controlar recursos. Os protocolos desta camada podem ser divididos em duas categorias [76]:

• Protocolos de informação: Estes são usados essencialmente para obter informação sobre a estrutura e o estado de um recurso. (por exemplo, carga corrente, congu- ração etc).

• Protocolos de gestão: Estes são usados, mais especicamente para negociar o acesso a recursos. Eles são usados na criação de ambientes de execução nos diversos recursos e também fornecem suporte à monitorização de estado e controle.

Como vimos, esta camada é a responsável pela denição de alguns protocolos de comu- nicação, mais precisamente para obter informação e para alocar recursos. A camada resource disponibiliza algumas APIs e SDKs, normalmente C e JAVA, para a utilização destas tecnologias o que facilita a integração de vários recursos na grid.

2.4.4 Camada Collective: Coordenar múltiplos recursos

Ao contrário da camada resource, que gere todos os recursos individualmente, a camada collective gere um conjunto de recursos como um todo. Esta camada, tal como a anterior, fornece protocolos e serviços que gerem os recursos, mas de uma forma global. Eis alguns comportamentos adicionados a esta camada [76].

• Serviços de diretório: Este serviço permite que os utilizadores de uma VO, possam perguntar por recursos pelo nome, tipo, etc.

• Co-alocação, escalonamento e serviços brokering: Permite que os utilizadores façam alocação de vários recursos para um dado propósito e escalonar as tarefas para os recursos alocados.

• Monitorização e serviços de diagnóstico: Suporta a monitorização dos recursos e faz alertas para casos de falhas, intrusões e sobrecarga.

• Serviços de replicação de dados: Gere os recursos de armazenamento de uma VO, maximizando a performance de acesso.

• Sistema de programação Grid-Enable: Ativam o suporte para modelos de progra- mação familiares a serem usados na grid, como por exemplo MPI (Message Passing Interface). MPI é uma biblioteca de parelização de programas de forma distribuída (memória distribuída) [61].

A camada collective é responsável pela gestão de protocolos e serviços que gerem os recursos como um todo. Tal como a camada resource, esta também fornece SDKs e APIs que podem ser utilizadas na interligação com as aplicações. As componentes desta camada podem ser adaptadas conforme as necessidades, por isso a disponibilização de SDKs e APIs [76].

2.4.5 Aplicação

A camada aplicação contém as aplicações dos utilizadores que operam dentro de uma VO. Esta camada não é nada mais nada menos que a chamada de serviços denidos pelas camadas inferiores [76].

2.5 Infraestrutura EGI (European Grid Iniciatives)

EGI é uma infraestrutura de grid, nanciada com dinheiros públicos europeus, com o objetivo de oferecer aos cientistas europeus um conjunto de recursos computacionais poderosos por forma a que estes possam conduzir as suas pesquisas com sucesso. Esta infraestrutura é constituída por supercomputadores, dispersos geogracamente, ligados através de redes de alta performance. A infraestrutura EGI permite aos investigadores

vez irá ser o motor para o crescimento económico das nações. A Figura 2.3 mostra todos os países que contribuem com recursos computacionais para a infraestrutura EGI.

Figura 2.3: Países pertencentes à infraestrutura EGI [11].

A infraestrutura EGI é coordenada através do esforço das várias organizações pertencentes ao projeto. Estas são responsáveis pela supervisão da informação, suporte à comunidade, suporte à gestão avançada de rede, interoperabilidade entre diferentes middlewares e estatísticas. A gura 2.4 ilustra a forma como são organizadas as diferentes funções por cada instituição. Sendo assim, cada instituição é responsável pela conguração e gestão de determinados serviços. Esta cooperação é importante para que a infraestrutura esteja sempre funcional, visto que está dispersa por vários países da Europa.

2.5.1 Infraestrutura de serviços

Existe um conjunto de indivíduos responsáveis pela manutenção e coordenação de alguns serviços, para que toda a infraestrutura esteja funcional 24 horas por dia 7 dias por semana. Eis alguns serviços geridos diariamente pela comunidade:

• Monitorização da infraestrutura: Serviço responsável pela monitorização de todo o trabalho da grid. Este periodicamente faz teste de nível de funcionalidade à infraestrutura e gera relatórios sobre a atividade.

• Portal de operações: Portal responsável por monitorizar a infraestrutura de forma gráca. O tipo de informação que este monitoriza é, por exemplo vericar as VOs que estão ativas ou não e em que local, falhas existentes, etc.

• Staged rollout: Serviço responsável por todas as atualizações, testes e vericação de software.

• Infraestrutura de segurança: Conjunto de membros responsáveis pela deteção de falhas de segurança e vulnerabilidades. Periodicamente fazem vericação de software em cada centro individualmente. Cada centro é escolhido de forma aleatória. • Serviços core: Serviço responsável pela gestão dos principais serviços grid, como

gestão de utilizadores numa VO, BDII (Berkeley Database Information Index) de topo, WMS (Workload Management System), catálogo de cheiros central entre outros.

2.5.2 Serviços Técnicos

Este serviço tem como objetivo melhorar o uso de utilização da infraestrutura e de dar suporte técnico à comunidade. Eis então, alguns serviços:

• Serviços organização virtual: Serviço responsável por dar informação a toda a comunidade, tal como, documentação, ferramentas existentes, serviços.

• Serviços de software: Serviço responsável pelo repositório central de software. Todo o software submetido para este repositório é validado, pois este tem de passar por um conjunto de critérios de qualidade antes de poder ser colocado em staged rollout. Esses critérios são denidos pela Technology Coordination Board (http://go.egi.eu/ QualityCriteria-1).

• Base de dados de aplicações  AppDB: É uma base de dados que guarda um conjunto de aplicações sobre os mais diversos campos da ciência. Isto é útil para que os cientistas não tenham que despender tempo na realização de seu próprio software e também é útil para aqueles que não têm conhecimentos de programação.

A Figura 2.5 ilustra as diferentes áreas de investigação existentes e o seu respetivo uso, utilizando a infraestrutura EGI.

Figura 2.5: Áreas de investigação [88].

2.5.3 Recursos EGI

A Figura 2.6 mostra os recursos disponíveis na infraestrutura EGI.