5.5 CEO Utility Services
5.5.2 Serviço para Monitoramento de Recursos (RMS)
Informações sobre os recursos disponíveis na nuvem podem ser obtidas através do Serviço para Monitoramento de Recursos (Resource Monitor Service - RMS). O RMS opera de uma forma distribuída, mantendo uma instância em cada recurso computacional do am- biente, fornecendo informações sob demanda para todos os outros serviços. Com base nas informações do RMS, o escalonador indica onde executar os serviços de cada workflow de forma a reorganizar a distribuição de serviços no ambiente para melhorar o desempe- nho global. A instância RMS que opera junto ao CEO recebe informações das demais instâncias e atualiza os repositórios do sistema no CEO Controller.
O repositório de recursos (Apêndice A) contém as características de cada recurso computacional, sobre os serviços instalados, informações de desempenho e sobre ocupação. O repositório contém também todas as informações necessárias para a publicação dinâmica dos serviços. As informações coletadas pela RMS para cada recurso (físico ou virtual) inclui a memória RAM (total e disponível), a utilização da CPU, número de núcleos da
CPU, taxa de desempenho esperado, e assim por diante. Ele também fornece informações sobre a rede, como largura de banda disponível, e conectividade de recursos. Além disso, o RMS mantém informações detalhadas sobre os serviços disponíveis no recurso. Ele informa a URL de cada container, o protocolo, portas para acesso e mantém no repositório os tempos médios da execução de cada operação dos serviços já executados pelo recurso, já fazendo a normalização segundo a classe do hardware hospedeiro (Apêndice B, Seção B.5). O RMS cumpre função estratégica ao fornecer informações que permitem à gerência de recursos identificar situações de concorrência e gargalo. A gerência analisa de maneira combinada a carga de VMs locais ou oriundas da nuvem, e das máquinas físicas onde estão hospedadas identificando sobrecargas. Com informações sobre o estado atual dos recursos o escalonador pode evitar sobrecargas potencias associando VMs e seus hospe- deiros. Sem a correta associação entre VM e máquina hospedeira, o escalonador pode usar informações incorretas sobre o número de núcleos da CPU escalonando mais pro- cessos que o número de núcleos disponíveis no recurso. Outro gargalo é o escalonamento de processos concorrentes que fazem acesso intenso de entrada e saída no mesmo recurso físico causado pelo desconhecimento sobre VMs que estão em execução nesse recurso.
Monitoramento da Execução de Workflow
O CEO faz o acompanhamento detalhado das execuções de cada workflow. Para tal WES monitora os tempos de execução de cada seção especificada no workflow CEOL, incluindo o tempo gasto em cada operação invocada no processo, registrando-os em um arquivo de log exclusivo para cada workflow. Para ilustrar este procedimento, mostramos a seguir o fragmento <process> do workflow em que se aplica um filtro de mediana em um arquivo de imagem [16].
<ceo:workflow name="ip-A5000" met="31500"> ...
<process name="p-ip-A5000x5000">
(1) <invoke gsh="vm1" method="sliceFile" met="2500"> <!-- Split in 2 parts --> <argument variable="sliceIn" type="string"/>
<return variable="sliceOut" type="string"/> </invoke>
(2) <flow name="F-SCP-send" met="7500"> <!-- Send slices to resources --> <invoke gsh="vm1" method="runCommand" tagname="sendS1Tovm3">
<argument variable="S1Tovm3" type="string"/> <return variable="retCode" type="int"/> </invoke>
<invoke gsh="vm1" method="runCommand" tagname="sendS1Tovm4"> <argument variable="S2Tovm4" type="string"/>
(3) <flow name="F_medianFilter" met="13000"> <!-- Filter in parallel --> <invoke gsh="vm3" method="medianFilter" tagname="vm3MF">
<argument variable="mFIn-1" type="string"/>
<return variable="retCode" type="int"/> </invoke> <invoke gsh="vm4" method="medianFilter" tagname="vm4MF">
<argument variable="mFIn-2" type="string"/>
<return variable="retCode" type="int"/> </invoke> </flow>
(4) <!-- Receive slices from resources --> <flow name="F-SCP-receive" met="7500">
<invoke gsh="vm1" method="runCommand" tagname="rsf_vm3"> <argument variable="R1Fromvm3" type="string"/>
<return variable="retCode" type="int"/> </invoke> <invoke gsh="vm2" method="runCommand" tagname="rsf_vm4">
<argument variable="R1Fromvm4" type="string"/>
<return variable="retCode" type="int"/> </invoke> </flow>
(5) <invoke gsh="vm1" method="mergeFiles" met="700"> <!-- Merge slices --> <argument variable="mergeIn" type="string"/>
<return variable="mergeOut" type="int"/> </invoke>
<return variable="retCode" type="int"/> <!-- Return value to Run Service -->
</process> </workflow>
No exemplo são usadas quatro instâncias do serviço FactIPService (ISF), cujos nomes associados são vm1, vm2, vm3 e vm4. Em (1) usamos a ISF vm1 para dividir o arquivo em duas partes. As partes criadas são enviadas para o local onde estão as ISFs vm3 e vm4 de forma paralela para serem filtradas (2). Em (3) o filtro de mediana é aplicado simultaneamente pelas ISFs vm3 e vm4. Em (4) os arquivos filtrados são enviados para a VM onde a ISF vm1 faz o merge entre os arquivos gerando o arquivo filtrado final em (5). A cada execução desse workflow, o WES adiciona ao final do arquivo de log as seguintes informações:
... Maestro - WES Processing ip-A5000x5000.ceol at Wed Aug 08 10:23:02 BRT 2013 . Definitions Execution Time: 5
. ExecProcess: invoke vm1 sliceFile end - Time: 2378
. flow.ProcessInvoke: vm2 runCommand sendS2Tovm4 end - Time: 7050 . ExecProcess: flow F-SCP-send end - Time: 7051
. flow.ProcessInvoke: vm3 medianFilter vm3MF end - Time: 10202 . flow.ProcessInvoke: vm4 medianFilter vm4MF end - Time: 11958 . ExecProcess: flow F_medianFilter end - Time: 11958
. flow.ProcessInvoke: vm2 runCommand rsf_vm4 end - Time: 6701 . flow.ProcessInvoke: vm1 runCommand rsf_vm3 end - Time: 6797 . ExecProcess: flow F-SCP-receive end - Time: 6799
. ExecProcess: invoke vm1 mergeFiles end - Time: 617 . Process Execution Time: 28806
--- End of Process ip-A5000x5000.ceol Time: 32162
Esta execução mostra que foram usados 2378ms para dividir o arquivo em duas partes (sliceFile), usados 6246ms para enviar um slice para vm3 (sendS1ToVM3 ) e 7050 para enviar o outro slice para vm4 (sendS1ToVM4 ). A aplicação do filtro (medianFilter) consumiu 10202 ms em vm3 (vm3MF) enquanto vm4 usou 11958 (vm4MF). Para trazer o slice filtrado de vm3 para vm1 foram gastos 6797ms (rsf vm3 ) enquanto que de vm4 foram 6701ms (rsf vm4 ). A junção dos arquivos usou 617ms em vm1 (mergeFiles). Finalmente, o tempo total de processamento foi de 28806ms (Process Execution Time), que não é a soma de todos os tempos porque várias operações foram executadas em paralelo. Esse pequeno exemplo demonstra a importância das informações de desempenho. É possível notar que tanto no envio como no recebimento dos slices o enlace entre vm1 e vm3 é mais rápido que o enlace entre vm1 e vm4. Nota-se também que, apesar de serem hospedadas em máquinas da mesma classe (hostclass=“02”) e usarem o mesmo serviço FactIPService, vm3 foi mais rápida na aplicação do filtro de mediana.
Além de gerar o arquivo de log para cada workflow, o WES mantém essas informa- ções nos repositórios associados ao RMS em cada recurso da nuvem. Por usar recursos computacionais disponibilizados na forma de máquinas virtuais é importante normalizar as informações colhidas. Para tal, o Maestro obtém junto ao middleware da nuvem a classe do equipamento onde a VM foi hospedada. A união do tempo de execução e da classe do hospedeiro permite calcular médias que realmente possam apoiar o escalonador na escolha dos recursos computacionais. Cabe ao administrador da nuvem decidir como classificar os equipamentos, e manter essa informação atualizada no arquivo de configu- ração do domínio, de forma similar ao que está no Apêndice B.5. Uma opção para essa classificação pode ser a usada pelos provedores de nuvens públicas como a Amazon [145] que adota uma combinação de características (hardware, tipo de uso, opções, etc) para cobrar pelo uso de seus recursos.
A infraestrutura CEO disponibiliza aos escalonadores não só informações sobre os recursos computacionais, como capacidade de processamento, armazenamento e comu-
nicação, como também informações sobre o desempenho das operações dos serviços em cada VM onde foram executados pelo menos uma vez. A associação entre VM e a classe do hardware que a hospeda permite inferir o desempenho na nuvem sem identificar os recursos físicos. Além de acompanhar detalhadamente os tempos na execução das ativi- dades do processo, o RMS monitora todos os tempos envolvidos com as outras atividades do workflow. São medidos os tempos na criação de cada VM, os tempos da publicação dinâmica de cada serviço não disponível na imagem usada na criação da VM, os tempos para instanciar os containers envolvidos, os tempos para criação de cada instância dos serviços, todos os tempos envolvidos com a destruição das instâncias dos serviços e das VMs e o tempo gasto para enviar as informações colhidas ao CEO Controller.