5.4 CEO Maestro: a Gerência de Workflows
5.4.1 O Modelo para Integração entre Gerência de Workflows e Escalo-
A transformação do workflow abstrato fornecido pelo usuário em um workflow con- creto com os recursos computacionais devidamente identificados e localizados requer al- gumas etapas. Para formalizar essa transformação foi criado um conjunto de documentos e procedimentos para o seu preenchimento. O processo tem início com o usuário criando o primeiro documento o workflow abstrato descrito em CEOL (wrkfname.ceol). A partir do wrkfname.ceol recebido o WMS cria o arquivo intermediário (wrkfname.dgs) onde são acrescentadas as tarefas inicial CEO–SNI e final CEO–ENI bem como os tempos médios de execução de cada tarefa fornecidos pelo RMS. De posse do arquivo intermediário wrkf- name.dgs o DGS executa o algoritmo CEOL2DAG para gerar o DAG que será enviado ao escalonador (wrkfname.d2s). O WMS aciona o SIS que traduz wrkfname.d2s no dialeto do escalonador, submetendo-o e recebendo o mapa de alocação. Como o mapa de alocação recebido está no dialeto do escalonador, o SIS converte-o no formato “.am” reconhecido pelo WMS. WMS atualiza as informações do intermediário wrkfname.dgs com as indica- ções de wrkfname.am gerando o workflow concreto wrkfname.cceol. O wrkfname.cceol é então usado inicialmente pelo próprio WMS para requisitar a criação de instâncias ao ICS e, com todas as instâncias criadas, disparar a execução do workflow concreto através do WES.
Na sequência os documentos usados/gerados na execução são detalhados juntamente com os procedimentos para a sua criação/preenchimento. Todos os exemplos são referen-
(a) (b)
Figura 5.15: DAG original abstrato e DAG dgs.
tes ao workflow que aplica o filtro de mediana em um arquivo–imagem já discutido na Seção 4 cujos documentos completos estão no Apêndice C
Construção do arquivo intermediário wrkfname.dgs pelo WMS
Em um domínio de grade o CEO Controller tem localização fixada na instalação o que, em geral, não ocorre em um domínio de nuvem. Não é possível fixar a localização do CEO Controller em uma nuvem pública como a Amazon, por exemplo. Dessa forma o usuário não teria como referenciar no workflow ações que devam ser feitas no CEO Controller, como a cópia de um arquivo de sua área pessoal para uma VM da nuvem. Para resolver essa questão o WMS acrescenta automaticamente as tarefas CEO–SNI e CEO–ENI que são sempre “alocadas” no CEO Controller. Assim, o usuário pode usá-las sempre que necessitar tratar com informações de ou para o CEO Controller. Além disso, o WMS inclui em wrkfname.dgs os tempos de execução de cada atividade fornecidos pelo RMS. Os tempos são importantes servindo de baliza para que o escalonador possa escolher os melhores recursos computacionais.
Um workflow é geralmente representado por um grafo acíclico direcionado (DAG) G = {N, A}, onde cada nó ni ∈ N representa um serviço a ser executado e cada aresta ai,j ∈ A representa uma dependência de dados entre o serviço i e j, ou seja, aij representa os dados produzidos por ni e consumidos por nj. Com isso nj só pode iniciar a sua execução após ni finalizar e disponibilizar os dados necessários a nj. A Figura 5.15[a] mostra o DAG gerado pela interpretação do workflow abstrato que aplica o filtro de mediana dividindo o arquivo em duas partes para processá-lo em paralelo. Após as adicões feitas pelo WMS o DAG equivalente é apresentado pela Figura 5.15[b], onde estão incluídos os novos serviços (nós) inicial e final (CEO–SNI e CEO–ENI), os custos de processamento de cada serviço (nó) (cT0 a cT5) e os custos de comunicação das arestas (cA1 a cA6).
Basicamente, o WMS inclui duas instâncias do serviço FactCEOMSNService na declaração <services>, acrescenta as “tarefas” incial e final em <process> (<invoke
gsh=“CEO–SNI”...> e <invoke gsh=“CEO–ENI”...> respectivamente) e acrescenta os atributos de desempenho met e aet em todas as tarefas pertinentes. O fragmento de código abaixo mostra a declaração da instância do serviço FactCEOMSNService nomeada “CEO–SNI”. Neste exemplo o CEO Controller está na máquina artemis.
<ceo:gsh name=“CEO–SNI” gshid=“–1” hostid=“0” hostclass=“0” tsn=“http://artemis:8443/wsrf/services/CEOMSNFactory/FactCEOMSNService” type=“Factory”/>
O fragmento abaixo mostra a “nova tarefa inicial” do workflow (pid=“0”) nomeada de CEO–SNI (gsh=“CEO–SNI”). Por seu objetivo ser apenas sinalizar que a tarefa inicial do workflow está no CEO Controller, essa instância nada executa (method=“doNothing”). Por nada executar, seu custo é zero (met=“0”, aet=“0”).
<ceo:invoke gsh=“CEO–INI” method=“doNothing” pid=“0” tagname=“CEO–INI” met=“0” aet=“0”>
<ceo:argument value=“ ” type=“string”/>
<ceo:return value=“0” type=“int”/> </ceo:invoke>
Finalizando as inserções feitas por WMS, o fragmento de código a seguir mostra que foi usada a tarefa CEO–SNI para copiar o arquivo A–500x500.txt do CEO Controller (CEO- SNI) para o recurso computacional onde será executada a tarefa “imf1 ”. No fragmento é possível ver também os custos obtidos junto ao repositório e inseridos como informação no código. Os tempos mínimo e médio de execução (<met=“–1” e aet=“248”>) foram inseridos por WMS. Como não há informação para o tempo mínimo (–1) deve ser usado o tempo médio (248) como custo computacional para a tarefa “imf1 ”. WMS inclui o custo da aresta que liga as tarefas “CEO–SNI” e “imf1 ”, pois a cópia do arquivo A–500x500.txt entre as duas tarefas tem tamanho de 750010 bytes (fs=“750010” afs=“750010”). O repositório não contém informação sobre o custo computacional dessa cópia (met=“–1” aet=“–1”).
<ceo:invoke gsh=“imf1” method=“sliceFile” pid=“1” tagname=“imf1–slice” <met=“–1” aet=“248”>
<ceo:filein tagname=“FromStartNode”
<source=“user–01@CEO–SNI:A–500x500.txt” destination=“user–01@imf1:A–500x500.txt”
fs=“750010” afs=“750010” met=“–1” aet=“–1”/>
<ceo:argument variable=“sliceIn” type=“string”/>
Construção do CEO-DAG
A atividade do DGS é gerar o DAG no formato CEO a partir do arquivo intermediá- rio .dgs fornecido por WMS. O arquivo CEO-DAG contém dois atributos e cinco classes. Com exemplos extraidos da Seção C.3, é possível ver que os atributos são o nome do DAG (name=“ip–A500–2s–3rc”) e o seu custo de processamento (cost=“6249”). As classes são: • er: descreve os requisitos (environment requirements) que o recurso computacional deve oferecer para executar os serviços do workflow. Seus atributos são: os e version que indicam o sistema operacional e sua versão; memory a quantidade de memória mínima; disk a quantidade mínima para a área de trabalho em disco; vcpus o número de UCPs virtuais e o grupo de segurança secgroup. Um exemplo de uso para essa classe é:
<ceo:er os=“Ubuntu” version=“12.04 LTS 64” memory=“2GB” disk=“20GB” vcpus=“2” secgroup=“ceo–sg1”/>
• costofnodes: contém informações detalhadas sobre as tarefas a serem executadas. Ela é usada também para indicar a localização do recurso computacional. Tem um único atributo (numberofnodes) que indica quantas repetições da classe con (cost of node) estão declaradas em seu interior. Cada uma das declarações da classe con, onde é definido o custo da tarefa, contém como atributos a identificação da tarefa (nid), a identificação única do serviço que será exetado (gsh), o custo computacional dessa tarefa (cost), a identificação e classe do host hospedeiro (hostid, hostclass), a localização do host (hURL) e o domínio ao qual pertence (did). Para as tarefas CEO-SNI e CEO-ENI inseridas automaticamente os atributos já estão preenchidos, pois o CEO conhece a localização do CEO Controller. Para as demais tarefas depende do preenchimento que o usuário indicou. O usuário pode preencher todas as informações quando deseja usar recursos da grade. Uma vez indicados pelo usuário serão mantidos para que o escalonador respeite essa solicitação. As declarações de con cujos atributos de localização estiverem em branco indicam que o escalonador deve escolher. Exemplos de preenchimento para as duas opções comentadas são:
<ceo:con nid=“0” gsh=“CEO–SNI” cost=“0” hostid=“–1” hostclass=“0” hURL=“10.3.77.39” did=“lrc–g1”/>
<ceo:con nid=“1” gsh=“imf1” cost=“248” hostid=“1” hostclass=“ ” hURL=“ ” did=“ ”/>
• costofedges: essa classe informa o custo das arestas do DAG. Similar à con, ela tem um único atributo que indica o número de repetições para coe (cost of edge). Para casa aresta do DAG é necessário informar o seu custo através de uma declaração de coe. Ela contém como atributos a identificação da aresta (edgeid) que é preenchida de forma sequencial, os atributos que indicam a origem e o destino da aresta (snode, enode) e o custo da aresta (cost) que indica o tamanho de todos os arquivos que serão copiados entre os nós unidos pela aresta. A declaração a seguir descreve a aresta entre a tarefa CEO-SNI e a tarefa “imf1 ” que é a primeira aresta do DAG exemplo da Seção C.3.
<ceo:coe edgeid=“1” snode=“0” enode=“1” cost=“750010”/>
• domain: indica o domínio onde estão os recursos computacionais que o escalona- dor deve usar. Tem como atributos o nome do domínio (domain) e a localização do arquivo onde está a sua configuração (domainlocation). Um exemplo de preenchi- mento pode ser:
<ceo:domain name=“lrchybrid” domainlocation=“ceo–lrc–hybrid.xml”/>
• scheduler: indica o serviço escalonador. Tem como atributos a identificação do serviço (schId), o seu nome (schName), o algoritmo a ser usado (schAlgorithm) e a localização do serviço (schURL). Um exemplo dessa classe é:
<ceo:scheduler schld=“1” schName=“LocalRR” schAlgorithm=“RR” schURL=“http://10.3.77.39:8443/wsrf/services/FactSS1Service”/>
CEOL2DAG: algoritmo gerador do DAG conceitual para escalonamento
Para fazer a geração do DAG no formato CEO o serviço DGS usa o CEOL2DAG, um algoritmo que analisa as atividades executadas pelo processo do workflow (<ceo:process> ) acrescentando informações das definições (<ceo:definitions> ) para preencher as classes costofnodes e costofedges. O algoritmo é:
1.01: Criar o documento usando como raiz <d2s>; 1.02: Usar o nome do arquivo ceol no atributo name; 2.03: Se existir o elemento <er> incluí-lo;
3.04: Criar o elemento <costofnodes> preenchendo o atributo numberofnodes=“0”; 3.05: Enquanto houver próxima atividade no elemento <process> do workflowceol faça: 3.06: Criar um novo elemento <con>;
3.08: Incluir o atributo gsh;
3.09: Se existir o atributo met na atividade e NÃO for “–1” 3.10: Preencher o atributo cost com o valor de met; 3.11: Senão Se existir o atributo aet faça cost=aet;
3.12: Senão faça cost=“–1”;
3.13: Se o atributo hostid do gsh da atividade estiver preenchido 3.14: Incluir hostid como atributo;
3.15: Senão fazer hostid=“ ”;
3.16: Se o atributo hostclass do gsh da atividade estiver preenchido 3.17: Incluir hostclass como atributo;
3.18: Senão faça hostclass=“ ”;
3.19: Se houver um IP nos atributos host ou uri da atividade 3.20: Preencher o atributo hURL com o IP encontrado; 3.21: Senão faça hURL=“ ”;
3.22: Se o atributo hURL estiver preenchido com uma URI 3.23: Preencher o atributo dId com o domínio correspondente; 3.24: Senão faça o atributo dId=“ ”;
3.25: Ir para a próxima atividade;
3.26: Atualizar <costofnodes> com o número de atividades encontradas;
4.27: Criar o elemento <costofedges> preenchendo o atributo numberofedges=“0”; 4.28: Fazer atividade=pid da 2a. atividade de <process>;
4.29: Fazer nsn=0;
4.30: Enquanto encontrar atividade no elemento <process> do workflow ceol faça: 4.31: Se atividade anterior não é flow
4.32: Se não existir aresta entre atividade anterior e atividade faça:
4.33: Incrementa nsn;
4.34: Criar novo elemento <coe> com edgeid=nsn; 4.35: Faça snode=pid da atividade anterior;
4.36: Faça enode=pid da atividade;
4.37: Faça cost=”0“;
4.38: Senão
4.39: Faça atvflow=pid da 1a. atividade do flow; 4.40: Para cada atividade do flow:
4.41: Se não existir aresta entre atvflow e atividade faça:
4.42: Incrementar nsn;
4.43: Criar novo elemento <coe> com edgeid=nsn;
4.44: Faça snode=atvflow;
4.45: Faça enode=atividade;
4.46: Faça cost=“0”;
5.48: Para cada dependência de dados:
5.49: Se existe o atributo pidsource faça tsnode=pidsource;
5.50: Senão
5.51: Se “gsh de source” difere do “gsh da atividade”
5.52: Procurar a última ocorrência do “gsh de source” nas atividades acima; (*) 5.53: Se achou faça tsnode=pid da atividade onde achou “gsh de source”;
5.54: Senão tsnode=–1;
5.55: Senão fazer tsnode=pid da atividade;
5.56: Se existe o atributo piddestination faça tenod=piddestination; 5.57: Senão Se “gsh de destination” difere do “gsh da atividade” 5.58: Procurar a próxima ocorrência do “gsh de destination
nas atividades seguintes; (*)
5.59: Se achou faça tenode=pid da atividade onde achou “gsh de destination;
5.60: Senão fazer tenode=–1;
5.61: Senão tenode=pid da atividade;
5.62: Se tsnode == tenode vai para a próxima dependência de dados; 5.63: Procurar aresta que faça a ligação entre tsnode e tenode
5.64: Se achou aresta
5.65: Se o atributo fs está preenchido em atividade
faça cost=cost+fs na aresta encontrada;
5.66: Senão Se o atributo afs estiver preenchido
faça cost=cost+afs na aresta encontrada;
5.67: Senão
5.68: Incrementar nsn;
5.69: Criar novo elemento <coe> com edgeid=nsn;
5.70: Faça snode=tsnode;
5.71: Faça enode=tenode;
5.72: Se o atributo fs está preenchido em atividade faça cost=fs; 5.73: Senão Se o atributo afs estiver preenchido faça cost=afs;
5.74: Senão cost=“–1”;
5.75: Tratar a próxima dependência de dados; 5.76: Ir para a próxima atividade;
5.77: Atualizar <costofedges nsn...> com o número de arestas encontradas; 6.78: Criar e preencher o elemento <domain>;
7.79: Criar e preencher o elemento <scheduler>;
(*) Se a atividade em análise estiver dentro de um flow considerar como atividade anterior/seguinte a primeira ativi- dade fora do flow em análise.
No primeiro bloco de instruções (1.01–1.02), CEOL2DAG cria o documento dgs conforme as definições do XML Schema ceol2dag.xsd (XSD - XML Schema Definition) [261, 262]
criado para especificar o formato desse arquivo. A instrução do bloco 2 (2.03 ) trata os requisitos do ambiente. Essa informação é importante e indica quais os recursos mínimos necessários para a correta execução dos serviços do workflow. Com essa informação o esca- lonador pode escolher a melhor opção em custo x benefício entre os vários tipos (flavors) disponíveis nas nuvens. As instruções do bloco 3 (3.04–3.26) preenchem as informações da classe costofnodes onde são declaradas as tarefas do workflow, seus custos e quais os recursos computacionais onde devem ser processadas. Esse bloco percorre as atividades do processo (<process>) criando uma instância de (<con>) para cada uma delas. São inseridos os atributos de custo e classificação do recurso (hostid e hostclass) e avaliadas as informações sobre a localização do recurso (hURL e dId). Se o usuário fixou uma localização esta será mantida para que o escalonador a use como referência nas demais escolhas a serem feitas. O fragmento de código a seguir contém a descrição das tarefas (nós) geradas a partir do workflow ip–A500–2s–3rc.ceol mostrado no Apêndice C.1. A primeira tarefa nid=“0”, inserida automaticamente pelo WMS, já está alocada no CEO Controller (hostid=“–1” hostclass=“0” hURL=“10.3.77.39” dId=“lrc–g1” enquanto que a segunda nid=“1” os atributos hURL=“ ” dId=“ ” indicam que o escalonador deverá escolher onde serão executas.
<ceo:con nid=“0” gsh=“CEO–SNI” cost=“0” hostid=“–1” hostclass=“0” hURL=“10.3.77.39” dId=“lrc–g1”/>
<ceo:con nid=“1” gsh=“imf1” cost=“248” hostid=“1” hostclass=“ ” hURL=“ ” dId=“ ”/>
Após documentar os nós do DAG (tarefas do workflow), CEOL2DAG analisa todas as arestas que os interligam para preencher a classe <costofedges> com os respectivos custos. No preenchimento são analisadas a dependência de processamento (a ordem de execução das tarefas) e a dependência de dados (informações geradas por uma tarefa e consumidas por outra). O bloco 4 analisa a dependência de processamento. Se a tarefa anterior for uma tarefa simples, um <invoke> por exemplo, será criada apenas uma aresta (4.32– 4.37). No entanto, se a tarefa anterior for um <flow> será criada uma aresta ligando cada uma das tarefas do <flow> à tarefa seguinte (4.39–4.47).
A CEOL oferece atributos para o usuário registrar diretamente no código a depen- dência de dados. Os atributos pidsource e piddestination servem para essa finalidade. No entanto há uma outra forma de indicar a dependência mantendo a flexibilidade do código. Através do atributo <gsh> a dependência é declarada de forma abstrata sendo corretamente sincronizada pelo WMS na criação do workflow concreto. O fragmento de código a seguir exemplifica essa opção.
<ceo:invoke gsh=“imf1” method=“sliceFile” pid=“1” tagname=“imf1–slice” <met=“–1” aet=“248”>
<ceo:filein tagname=“FromStartNode”
<source=“user–01@CEO–SNI:A–500x500.txt” destination=“user–01@imf1:A–500x500.txt”
fs=“750010” afs=“750010” met=“–1” aet=“–1”/> <ceo:argument variable=“sliceIn” type=“string”/>
<ceo:return variable=“sliceOut” type=“string”/> </ceo:invoke>
Nesse <invoke> o arquivo A–500x500.txt é a dependência de dados entre a tarefa imf1 e a tarefa CEO–SNI. O arquivo original está no recurso computacional onde será executada a tarefa CEO–SNI, o que é informado através da declaradação feita em source por @CEO– SNI:. De forma análoga, a cópia deve ser feita no recurso computacional onde será execu- tada a tarefa imf1 conforme foi indicado por @imf1: em destination. Essa análise é feita pelo bloco 5 que pode atualizar os custos de uma aresta já inserida ou acrescentar novas arestas caso seja necessário. As instruções 5.49 e 5.56 tratam da dependência registrada no código pelos atributos pidsource e piddestination. Para as dependências sinalizadas pelo gsh a análise é mais elaborada. O bloco de instruções 5.51–5.55 avalia a dependên- cia de dados gerada por source percorrendo as tarefas que estão acima no workflow para identificar a tarefa que origina os dados. O bloco 5.57–5.61 avalia a dependência de dados gerada por destination percorrendo as tarefas abaixo no workflow para identificar a tarefa que irá consumir os dados. Encontradas a origem e o destino dos dados o bloco 5.63–5.74 atualiza os custos para o caso de já existir uma aresta entre as tarefas em análise ou caso não exita, criar uma aresta de ligação entre elas. O fragmento de código mostrado acima gera a aresta <ceo:coe edgeid=“1” snode=“0” enode=“1” cost=“750010”/>.
A instrução 6.78 inclui a identificação do domínio no qual o escalonador deve escolher os recursos computacionais e a instrução 7.79 indica qual é o serviço de escalonamento deve ser usado. É através de 7.79 que o WMS escolhe qual a implementação do SIS deve ser usada como inteface com o escalonador. O Apêndice C.3 contém o CEO-DAG (ip–A500–2s–3rc.d2s) completo gerado pelo DGS para o workflow ip–A500–2s–3rc.ceol descrito na Seção C.1.