Évolution de la surface de charge sous l’effet du phé-

plataformas e facilitem a sua portabilidade para diferentes ambientes. Por outro lado, as funcionalidades comuns às várias ferramentas devem ser oferecidas pelo sistema de monito- rização, permitindo a sua partilha e coordenação entre as várias ferramentas. Cada cenário de utilização definirá os requisitos dessa infraestrutura de monitorização ajustada a cada caso, poupando na utilização de recursos que em geral concorre com a da própria aplicação obser- vada, permitindo a sua fácil adaptação, por adição ou remoção de funcionalidades, consoante cada situação.

4.2

Primeira abordagem

A primeira abordagem a esta problemática, no âmbito dos trabalhos realizados no De- partamento de Informática da FCT/UNL, surgiu nos projectos SEPP [23] e HPCTI [22] do programa Copernicus, nos quais o autor participou. Nestes, identificou-se a necessidade de uma infraestrutura capaz de ser utilizada como suporte a diversas ferramentas que estavam sendo desenvolvidas para a depuração de programas distribuídos C/PVM. Uma primeira ex- periência onde se desenvolveu um sistema para controlo de depuradores distribuídos [34], motivou a investigação de uma arquitectura de suporte mais genérica e flexível, para poder responder aos diferentes requisitos das várias ferramentas.

A primeira instância desse conceito, a DAMS-1, visou cumprir os seguintes objectivos:

• Promover uma separação nítida entre os mecanismos de baixo nível, que dão acesso aos componentes executáveis da aplicação, através de dispositivos sensores e actuado- res, e as funcionalidades de monitorização de mais alto nível, isto é, próximo do nível das abstracções das interfaces de utilização e das funcionalidades suportadas pelas fer- ramentas de análise e controlo das aplicações (por exemplo, para depuração de erros, perfilar o comportamento, ou controlar a configuração das aplicações dinamicamente).

• Servir de base para a definição de uma arquitectura virtual1 distribuída, organizada segundo uma hierarquia de processos2_{, de modo a disponibilizar as funcionalidades}

pretendidas, ao nível global da arquitectura distribuída.

1_{Isto é, realizável independentemente dos mecanismos específicos de cada plataforma computacional}

específica.

• Promover a maior neutralidade possível, dos componentes da arquitectura de moni- torização, relativamente aos cenários de utilização específicos. Isto é, em vez de in- corporar na arquitectura, um conjunto de funcionalidades, definidas à partida, que se pensassem serem úteis, para a generalidade dos cenários de observação e controlo, preveu-se que a arquitectura que pudesse ser flexível para ser expandida com novas funcionalidades, quando necessário.

cli. nó A nó B Serv.Manag. proc. serv. driver Local Manag. S.Mod.

Figura 4.1: Arquitectura do primeiro modelo DAMS

Para suportar esta flexibilidade de expansão, definiu-se uma arquitectura a “duas dimen- sões” ou a “dois níveis”, como ilustrado na fig. 4.1:

1. Um nível básico de suporte à distribuição, neutro e genérico, organizado em termos de um coordenador central, designado por Service Manager (SM), e por uma colecção de representantes, ditos Local Managers (LM), um local a cada nó da arquitectura, sendo que, o SM e os LM não suportam quaisquer serviços específicos de monito- rização. As únicas funcionalidades do SM são a interacção com as ferramentas, e o encaminhamento dos pedidos destas para os respectivos LM, nos devidos nós, bem como a propagação das correspondentes respostas. As responsabilidades dos LM são as de servirem de representantes do SM, em cada nó, servindo de intermediários entre aquele e os sensores/actuadores, que interagem com os processos da aplicação locais ao nó. Para além disso, cada LM disponibiliza funções sobre o estado local dos re- cursos do seu nó, como sejam, acções para activação de processos, sua terminação e consulta dos processos existentes.

2. Sobreposto ao nível básico, a arquitectura DAMS-1 tem um nível de suporte especí- fico à monitorização, organizado em unidades funcionais, chamadas “serviços”. Cada um destes é realizado como um par (Service Module (SMod), Service Driver (SD),

4.2. Primeira abordagem 67

responsável por encapsular a funcionalidade de um determinado serviço específico de monitorização. O SMod define uma interface API, que o SM torna disponível do lado dos clientes da DAMS-1 (interfaces de utilização e ferramentas). O SD, sob o controlo do LM local, é o responsável pelas acções de baixo nível correspondentes às funções da API do serviço, tais como, coligir informação, se for do tipo sensor, ou aplicar co- mandos, se for do tipo actuador, a serem aplicadas aos processos da aplicação alvo, por pedido do SMod.

A flexibilidade deste modelo resulta do facto de as funcionalidades específicas de moni- torização só serem conhecidas dos pares (SMod,SD). A sua extensibilidade resulta da faci- lidade com que se podem adicionar novas funcionalidades a uma configuração, por simples inclusão de novos pares (SMod, SD) e pelo seu registo junto do SM. Todas as interacções en- tre um SMod e o(s) seu(s) SD associados, fazem parte da especificação do serviço. Torna-se, assim, possível ter múltiplos serviços coexistentes numa mesma configuração DAMS-1, mas aplicando diferentes estratégias de controlo ou de observação, ou interpretando a informação relevante a distintos níveis de abstracção.

Um primeiro protótipo, do modelo DAMS-1, foi realizado no contexto de um trabalho de alunos finalistas de Engenharia Informática [99], que o implementaram sobre a plataforma PVM, numa rede local de computadores Linux e mais tarde também em OSF/1. Sobre essa realização, definiu-se uma infraestrutura para a observação e o controlo de processos distribuídos, com um primeiro protótipo limitado ao suporte de funcionalidades de depuração de programas, onde:

• qualquer processo alvo tem um identificador global;

• existe um conjunto de comandos para controlar e inspeccionar individualmente cada processo: stop, continue, next, step, print, set, breakpoint, etc.;

• existe um conjunto de comandos para gerir a configuração da infraestrutura e os pro- cessos sobre o seu controlo: juntar ou remover máquinas do sistema, ligar ou desligar o controlo sobre cada processo nessas máquinas.

Este sistema foi utilizado com sucesso para a implementação de várias ferramentas, e foi sendo estendido com outros serviços, mais específicos, para outras utilizações. Exem- plos destas utilizações são discutidos no capítulo 6. Este trabalho abriu o caminho a novas

utilizações e permitiu obter experiência sobre a sua utilização, em particular nas vantagens identificadas:

• reutilização dos serviços, uma vez desenvolvidos;

• partilha desses serviços entre vários clientes;

• extensão do sistema com novas funcionalidades, pela adição de serviços.

Também permitiu identificar algumas limitações:

• esta arquitectura é demasiado rígida, ao possuir um processo servidor central (o SM) que suporta todos os SMod, e com o qual todos os clientes têm de interagir;

• tanto o SM como os LM possuem uma arquitectura monolítica fixa sem distinção ou separação entre a parte responsável pelas operações de gestão dos SMod e respectivos drivers, e as interacções via a plataforma que as suporta (este protótipo está intrinse- camente ligado à plataforma, o PVM no caso);

• os processos LM apenas servem de intermediários entre os Smod e os respectivos drivers, não podendo possuir mais competências, o que se revela uma limitação à extensibilidade deste modelo da DAMS; por outro lado, cada LM centraliza todos os pedidos e respostas envolvendo os drivers nesse nó;

• os diversos serviços seguem esta arquitectura (SMod—driver), não sendo possível outras organizações internas para os serviços.

Surgiu assim a ideia de um novo modelo que permitisse responder melhor a novas uti- lizações e novos requisitos, de uma forma mais geral e flexível, em particular relativamente à própria arquitectura interna do sistema. Este é o modelo que se apresenta a seguir nesta dissertação.