5.1 Principais componentes
A arquitetura CEO, baseada no paradigma SOC, tem suas funcionalidades providas atra- vés de grupos de serviços. O CEO Portal é composto pelo Dashboard e pelo Run Service. Ele é personalizado junto aos softwares da grade e da nuvem de acordo com a caracterís- tica do domínio. O CEO Controller, responsável pela gerência da execução de workflows, é formado pelo Maestro, pelo Utility Services e pelo Assistant Maestro. O CEO Compute contém os serviços Assistant Maestro e Utility Services e deve estar em todos os recursos computacionais de trabalho no ambiente (worker nodes). Todos os recursos computacio- nais contêm o software da grade, pois este suporta o paralelismo em atividades como a execução concorrente dos serviços do workflow, o monitoramento distribuído, a publica- ção dinâmica dos serviços nos recursos computacionais, enfim, o software da grade oferece suporte a todas as tarefas concorrentes feitas pela infraestrutura CEO.
A Figura 5.2 mostra a distribuição dos componentes de software do CEO conforme a atividade de cada host do ambiente híbrido da Figura 5.1. O CEO Inter Domain Control Protocol (CIDCP) define como deve ser feita a troca de informações entre os Controllers que compõem a camada de gerência multidomínio. Maiores informações sobre o CIDCP serão apresentados na Seção 5.6.1. A seguir são apresentados detalhes funcionais dos cinco componentes, o Dashboard, o Run Service, o Maestro, o Assistant Maestro e o Utility Services.
CEO Dashboard: é uma interface Web para acesso ao sistema CEO. Ele deve ser
personalizado na instalação conforme o ambiente ao qual estará integrado, seja grade ou nuvem. Através do portal o usuário faz a sua autenticação para ter acesso aos recursos do sistema. O portal recebe as informações do workflow bem como os arquivos relacionados (upload) e aciona o CEO Run Service para disparar a execução. Os detalhes sobre o Dashboard estão na Seção 5.2.
Figura 5.3: Os serviços do CEO Portal.
CEO Run Service: O CEO Run Service trabalha com notificação e libera o Dash-
board para continuar atendendo os usuários de forma independente da execução. O CEO Run Service (CEORS) usa o conceito de Fábrica de Serviços e cria uma instância para executar as ações que envolvem o processamento do workflow garantindo dessa forma a escalabilidade do sistema. Basicamente são três as ações feitas. Uma instância CEORS (iCEORS) cria uma instância do CEO Maestro (iCEOM) no CEO Controller. iCEORS transfere o workflow e os arquivos vindos do usuário (upload) para o CEO Controller e aciona a iCEOM para gerenciar a execução. Após acionar a iCEOM, a iCEORS entra em estado de “dormência” até ser notificada com o resultado da execução. Ao receber a notificação, iCEORS faz a transferência dos arquivos resultantes da execução do workflow para a área de download do usuário, atualiza o CEO Dashboard com os resultados da execução e encerra o seu processamento eliminando a iCEOM usada. Os detalhes sobre o Run Service estão na Seção 5.3. A Figura 5.3 mostra o relacionamento entre o Dashboard e o Run Service, componentes do CEO Portal e a ligação entre o Portal e o Control- ler estabelecida pelo relacionamento entre o componente Run Service e o componente Maestro.
CEO Maestro: concebido segundo o conceito de Fábrica de Serviços, para cada
a troca de informações com o escalonador para que este possa indicar a melhor alternativa para a execução. Com as indicações do escalonador, a iCEOM transforma o workflow abstrato em concreto criando as instâncias dos serviços envolvidos. Sempre que neces- sário o Maestro cria novas instâncias de máquinas virtuais na nuvem, publica dinamica- mente os serviços não disponíveis nos recursos computacionais (tanto na grade como na nuvem) e trata das transferências dos arquivos envolvidos. Ao final da execução, elimina as instâncias criadas (serviços e máquinas virtuais) e notifica o Run Service.
Figura 5.4: Macro arquitetura do CEO Maestro.
Como pode ser visto na Figura 5.4, estão sob a coordenação do Maestro o gerente de workflows (Workflow Manager Service), o serviço de execução de workflows (Workflow Execution Service), o serviço gerador de DAGs (DAG Generator Service), a interface com o escalonador (Scheduler Interface Service), o Instance Creator Service que cria as instâncias dos serviços do workflow e o serviço de gerência de interfaceamento com nuvens (Cloud Manager Service). Na Seção 5.4 o Maestro e todos os serviços por ele coordenados são detalhadamente descritos.
CEO Assistant Maestro: em sistemas multidomínios, híbridos ou não, é impor-
tante manter a independência de acesso aos recursos em cada um dos domínios. De maneira geral as nuvens disponibilizam seus serviços através de um portal que é a prin- cipal forma de acesso aos recursos internos. Essa concepção oferece elasticidade com segurança, permite ao provedor total independência no controle dos seus recursos, libe- rando o usuário de qualquer obrigação relativa ao gerenciamento dos recursos da nuvem.
No entanto, essa independência requer um nível adicional de distribuição do gerente de execução de workflows. Para situações onde os recursos computacionais de um domínio não podem ser acessados diretamente por processos externos, o CEO dispõe do Assitant Maestro, um serviço para interligação de domínios.
Figura 5.5: CEO Assitant Maestro.
Se durante a execução do workflow o CEO Maestro identifica a necessidade do uso de recursos em outro domínio de nuvem, ele cria uma instância do CEO Assistant Maestro junto ao CEO Controller do domínio externo e passa a usá-lo para executar as tarefas nos recursos desse domínio (Figura 5.5). As ações são comandadas pelo CEO Maestro mas executadas pelo CEO Assistant Maestro dentro de cada domínio mantendo a inde- pendência entre os mesmos. A troca de informações entre o Maestro e as instâncias do Assistant Maestro é feita através do CEO Inter Domain Control Protocol (CIDCP) que define todas as operações envolvidas (Seção 5.6.1). Dessa forma o CEO oferece a facili- dade de execução entre domínios sem alterar a segurança dos sistemas, uma vez que a comunicação é feita dentro das regras de cada domínio. Além disso, o CIDCP adiciona uma camada extra de segurança pois usa operações internas de seus serviços. Os detalhes sobre o Assistant Maestro estão na Seção 5.6.
CEO Utility Services: nesse grupo estão os serviços que são usados tanto no CEO
Controller como também no CEO Compute. Fazem parte do grupo o serviço de moni- toramento (Resource Monitor Service), o serviço de publicação dinâmica (Dynamic De- ployment Service), a interface com redes virtuais (Virtual Network Interface Service) e serviços utilitários (Figura 5.6).
Os serviços desse grupo tem como principal característica trabalharem de forma dis- tribuída trocando ações e informações entre si. Um exemplo desse modo operacional é o
Figura 5.6: Os serviços do CEO Utility Services.
serviço de monitoramento. Todo recurso computacional tem uma instância desse serviço responsável pela coleta das informações do recurso, informações estas que são enviadas sob demanda ao CEO Controller e usadas no apoio às decisões e na confecção de médias e estatísticas de todo o ambiente. Os detalhes sobre o Utility Services estão na Seção 5.5. A Figura 5.7 apresenta em detalhes a arquitetura CEO, destacando os serviços e como eles interagem uns com os outros.
Um exemplo de execução de workflow em um sistema híbrido
Várias aplicações complexas de e-Ciência e e-Negócio podem ser modeladas como work- flows, compondo um conjunto de serviços a serem processados em uma determinada or- dem. A ordem de execução pode causar dependência pois um serviço pode depender de dados computados por outros serviços. Essa caracterítica permite que workflows sejam frequentemente modelados como gráficos acíclicos direcionados (directed acyclic graphs - DAGs). Para mostar o relacionamento entre os serviços durante uma execução usamos um workflow simples com quatro atividades, cuja execução será feita no ambiente híbrido mostrado na Figura 5.2. A execução é iniciada pela atividade 1 que prepara a execução em paralelo das atividades 2 e 3. Após a execução completa das atividades 2 e 3, a ativi- dade 4 é executada encerrando o processamento. O DAG equivalente a um workflow com essas características está representado à esquerda na Figura 5.8.
Figura 5.8: O relacionamento entre os serviços durante a execução do workflow. A execução do workflow simplificado tem início com o usuário usando o Dashboard para indicar o workflow e os arquivos necessários para a sua execução, como pode ser visto na Figura 5.8. Após a inclusão das informações, o usuário pressiona o botão para iniciar a execução, momento no qual o Dashboard cria uma instância do Run Service (iCEORS) para executá-la. O Run Service copia os arquivos relacionados ao workflow colocando-os no Grid CEO Controller (GCEOCr) na área exclusiva do usuário. Arquivos copiados, a iCEORS cria uma instância do CEO Maestro (iCEOM) e entra em estado de dormência esperando as sinalizações da iCEOM sobre a execução. A iCEOM gera o DAG equivalente ao workflow e envia ao escalonador para que este possa indicar os recursos computacionais
(RC) adequados ao processamento. Neste exemplo é suposto que o escalonador indica que as atividades 1 e 4 devem ser executadas em um RC da grade, enquanto que as atividades 2 e 3 devem ser executadas em paralelo usando RCs providos pela nuvem privada. Seguindo essa orienteção a iCEOM cria instâncias dos serviços que executam as atividades 1 e 4 em um dos recursos da grade (G–CR–1 ). Se os serviços não estiverem disponíveis em G–CR– 1, iCEOM consulta os repositórios do CEO, copia os arquivos necessários para G–CR–1 e faz a publicação dinâmica dos mesmos preparando-os para a criação das instâncias que serão necessárias para executar o workflow.
Para as atividades 2 e 3 o procedimento envolve outros passos. A iCEOM cria uma instância do Assistant Maestro (iCEOAM) e usa essa instância para criar duas máquinas virtuais (iVM) onde serão processadas as atividades 2 e 3. Na Figura 5.8 essas iVMs estão identificadas como PrC–iVM–1 e PrC–iVM–2 cuja criação é feita pela iCEOAM usando as imagens disponíveis na nuvem sempre seguindo as indicações feitas pelo usuário no workflow. Conforme já mencionado anteriormente os recursos que estão no domínio da nuvem privada não podem ser acessados diretamente pela iCEOM pois esta pertence ao domínio da grade. De forma análoga ao que foi feito no recurso da grade, a iCEOM usa as facilidades da iCEOAM para criar as instâncias dos serviços necessários para a execução das atividades 2 e 3. Se os serviços não estiverem disponíveis nas iVMs eles serão publicados dinâmicamente. A iCEOM coordena as ações (cópia dos arquivos para as iVMs, publicação dos serviços e criação das instâncias) que são executadas pela iCEOAM. Quando as instâncias dos serviços são criadas, tem início a execução. A iCEOM copia os arquivos necessários que estão em GCEOCr para G–CR–1 e dispara a execução de S1. Ao término de S1, iCEOM em conjunto com iCEOAM copia os arquivos necessários para PrC–iVM–1 e PrC–iVM–2. Com os requisitos prontos, iCEOM pede a iCEOAM que dispare simultaneamente S2 e S3 e aguarde até que ambos terminem o trabalho. Encerradas as execuções de S2 e S3, iCEOAM em conjunto com iCEOM transferem os arquivos gerados por S2 e S3 e que serão necessários na execução de S4 para G–CR–1. Esses arquivos também são copiados para a área do usuário em GCEOCr. Como PrC– iVM–1 e PrC–iVM–2 não serão mais usadas no processamento, iCEOAM destrói ambas encerrando a bilhetagem na nuvem privada. Dessa forma a iCEOM volta a trabalhar de forma isolada em GCEOCr disparando a execução de S4 em G–CR–1. Após o término de S4, a iCEOM transfere os arquivos gerados para a área do usuário em GCEOCr e elimina todas as instâncias dos serviços criados liberando os recursos de G–CR–1 para outros processamentos. Após a “limpeza” dos serviços, a iCEOM “desperta” a iCEORS notificando-a sobre o término da execução. iCEORS copia os arquivos de GCEOCr para a área do usuário no CEO Grid Portal e notifica o Run Service com as informações sobre o processamento. O workflow exemplo é simples mas ilustra todas as etapas envolvidas na execução do workflow em um ambiente híbrido.
(a) (b)
Figura 5.9: CEO Dashboard - Interface com o usuário.
(a) (b)
Figura 5.10: CEO Dashboard - Navegando nas três áreas do usuário.
Nas próximas seções os serviços da infraestrutura CEO e seus relacionamentos (Fi- gura 5.7) são apresentados em detalhes.