Neste cap´ıtulo foram apresentados resultados que avaliam como diferentes t´ecnicas de virtualiza¸c˜ao apresentadas na Se¸c˜ao 3.2 afetam o desempenho de um servidor Web para transmiss˜ao de v´ıdeo. Os resultados obtidos atrav´es dos experimentos mostram
que em termos de utiliza¸c˜ao efetiva do hardware, em rela¸c˜ao `a banda passante de rede em Mbps ou n´umero de clientes atendidos pela mesma m´aquina f´ısica, apenas o LXC consegue ter um desempenho compar´avel com o Linux sem virtualiza¸c˜ao quando ´e utilizada apenas uma m´aquina virtual. Contudo, um resultado interessante ´e o fato do KVM ter conseguido utilizar melhor o hardware quando se executam mais m´aquinas virtuais, chegando ao mesmo desempenho de rede do Linux sem virtualiza¸c˜ao a partir de quatro m´aquinas virtuais, isso ´e consequˆencia dos processos em n´ıvel de usu´ario, descritos na Se¸c˜ao 3.2.2, que conseguem assim fazer uso efetivo da largura de banda dispon´ıvel.
´E poss´ıvel observar com base nos resultados apresentados nas Se¸c˜oes 5.2.3 e 5.2.4, que mesmo em um cen´ario onde apenas um servidor f´ısico ´e utilizado, o uso de uma aplica¸c˜ao de transmiss˜ao de v´ıdeo permite diferenciar as t´ecnicas de virtualiza¸c˜ao utilizadas. Esses resultados mostram ainda que apesar do aumento no n´umero de m´aquinas virtuais sobre o mesmo n´o computacional, o ambiente com KVM consegue utilizar 100% da largura de rede dispon´ıvel, o que n˜ao ocorre para o Xen. Este resultado corrobora inicialmente a hip´otese levantada na Se¸c˜ao 4.1.1 de que um servi¸co de v´ıdeo consegue diferenciar, por exemplo, um ambiente computacional de IaaS usando Xen de outro que utiliza KVM.
Os resultados apresentados na Se¸c˜ao 5.3 mostram que a aplica¸c˜ao ElasticMovie consegue aferir quantitativamente as diferen¸cas entre os ambientes de IaaS avaliados. Tamb´em, os experimentos tamb´em mostram que a utiliza¸c˜ao de valores elevados no parˆametro Fator de Paciˆencia reduz a efic´acia do ElasticMovie como benchmark para ambientes de IaaS. Por fim, a Se¸c˜ao 5.5 quantifica o custo energ´etico do ambiente experimental e discute brevemente como a elasticidade das aplica¸c˜oes pode ser um caminho para aumentar a eficiˆencia energ´etica do ambiente computacional.
Cap´ıtulo 6
Rel´ogio Global de Alta Precis˜ao
Neste cap´ıtulo ´e abordado inicialmente o problema para temporiza¸c˜ao estrita- mente crescente e precisa para cluster computadores. Em particular, uma solu¸c˜ao previamente proposta ´e adaptada para essas arquiteturas que garante a propriedade ECP, e sobre esse novo rel´ogio de sistema ´e apresentada a solu¸c˜ao para constru¸c˜ao e manuten¸c˜ao de rel´ogio global, o Rel´ogio Global de Alta Precis˜ao (RGAP). O RGAP difere dos mecanismos em software existentes para a manuten¸c˜ao de rel´ogio global por n˜ao utilizar etapas de ressincroniza¸c˜ao.
6.1
Rel´ogio Virtual Estritamente Crescente
O principal objetivo no design do Rel´ogio Virtual Estritamente Crescente (RVEC) [112, 113] ´e evitar desvios de tempo de um sistema de computacional, tornando-o aderente `a propriedade Estritamente Crescente e Preciso (ECP), sem incorrer em ru´ıdo adicional no sistema. O uso do Time Stamp Counter (TSC) como referˆencia para o contador de tempo ECP atende estas demandas, dado que ele fun- ciona sem o uso de interrup¸c˜oes, ´e interno ao n´ucleo de processamento, opera na frequˆencia do n´ucleo e pela alta estabilidade do oscilador [2] [114] [115]. A escolha do TSC faz com que as ´unicas duas fontes potenciais de desvios de tempo sejam: gerenciamento de execu¸c˜ao sobre os m´ultiplos n´ucleos e altera¸c˜oes na frequˆencia destes n´ucleos.
C´odigo fonte 6.1: Estrutura de dados do RVEC
s t r u c t tb {
u64 base counter ; u64 age time ns ; }
A solu¸c˜ao RVEC ´e baseada no conceito de construir um rel´ogio virtual, de modo que sua estrutura armazene dois valores, o da ´ultima leitura do TSC realizada pela l´ogica de controle do RVEC e o valor da passagem de tempo consolidado at´e o instante desta ´ultima opera¸c˜ao de leitura. Assim, o RVEC ´e representando em um sistema computacional pela estrutura de dados struct tb apresentada no C´odigo 6.1, onde o campo base counter armazena o ´ultimo valor lido do TSC e o campo age time nsarmazena o tempo consolidado que ´e mantido pela l´ogica representada no C´odigo 6.2, a ser explicada posteriormente neste cap´ıtulo.
C´odigo fonte 6.2: Procedimento de atualiza¸c˜ao do RVEC
void update rvec ( struct tb ∗ptb , u64 CoreHZ ) {
aux tsc = g e t c o u n t e r ( ) ;
ptb−>age time ns += ( aux tsc − ptb−>base counter ) /CoreHZ ; ptb−>base counter = aux tsc ; }
A Figura 6.1 ilustra a contagem de tempo utilizando o RVEC. No instante A, uma instˆancia de RVEC ´e criada, armazenando o valor atual do TSC 10 no campo base counter do RVEC e o valor 0 no campo age time ns. No instante B, a frequˆencia do n´ucleo ´e alterada de 2 para 1, o que obriga a execu¸c˜ao do C´odigo 6.2 para atualizar os valores dos campos base counter e age time ns para 20 e 5∗109 (5
segundos), respectivamente. Sendo importante observar que a instˆancia do RVEC n˜ao pode ser lida durante o intervalo B-B’ pois o fluxo de execu¸c˜ao no sistema com rela¸c˜ao a esta instˆancia do RVEC est´a executando o procedimento descrito no C´odigo 6.2.
Figura 6.1: Contagem de tempo utilizando o RVEC: Inicializa¸c˜ao (tick A) and atualiza¸c˜ao (tick B)
Portanto, RVEC permite a cria¸c˜ao de uma abstra¸c˜ao de contagem de tempo espec´ıfica para o processo, desde o instante da sua cria¸c˜ao. Especificamente, os pontos de atualiza¸c˜ao s˜ao os instantes em que ou o n´ucleo tem sua frequˆencia alterada
ou quando um processo migra para outro n´ucleo. ´E extremamente importante que esses pontos de atualiza¸c˜ao sejam inseridos nos lugares apropriados de um sistema operacional para que, durante a sua execu¸c˜ao, todas as instˆancias de RVEC estejam protegidas de poss´ıveis desvios de tempo.
6.1.1
RVEC no Linux
No Linux, RVEC ´e integrado com os subsistemas de gerenciamento do n´ucleo e de escalonamento de tarefas do kernel. Para esta finalidade, a cria¸c˜ao de RVEC para os m´ultiplos n´ucleos de processamento ´e integrada ao procedimento de inicializa¸c˜ao do Linux. Al´em disso, essa integra¸c˜ao permite ao sistema oferecer simultaneamente suporte RVEC para threads tanto no n´ıvel de kernel como no n´ıvel de usu´ario. Portanto, o mecanismo resultante n˜ao imp˜oe limites com rela¸c˜ao ao n´umero de instˆancias de RVEC que podem ser criadas no sistema.
C´odigo fonte 6.3: Procedimento de leitura do RVEC para um n´ucleo pr´e-selecionado
return u64 r v e c c o r e g e t t i m e ( void ) {
aux tsc = ( g e t c o u n t e r ( ) − ptb−>base counter ) ;
return ptb−>age time ns + aux tsc /get CoreHZ ( ) ; }
A integra¸c˜ao inicial do RVEC dentro do kernel ´e feita atrav´es da inser¸c˜ao da estrutura de dados struct tb na fila de execu¸c˜ao de cada n´ucleo de processamento, representada no Linux pela estrutura de dados struct struct rq. Deste modo, o RVEC vinculado a um n´ucleo de processamento deve ter sua estrutura de dados atualizada sempre que um n´ucleo tem a sua frequˆencia de opera¸c˜ao alterada, as- sim garantindo a corretude da instˆancia do RVEC. Esta garantia ´e dada atrav´es da atualiza¸c˜ao dos campos base counter e age time ns realizada pelo C´odigo 6.2, implementado no driver Dynamic Voltage and Frequency Scaling (DVFS) do Linux (CPUFreq). A estrutura do RVEC tamb´em mant´em o tempo consolidado desde a inicia¸c˜ao de um n´ucleo de processamento, o qual ´e calculado a partir dos valores das leituras TSC atrav´es da passagem do tempo, a frequˆencia atual da unidade do n´ucleo, e os campos RVEC que est˜ao associados com o n´ucleo.
O RVEC tamb´em ´e instanciado para todas as tarefas (threads) dentro de um sistema Linux, realizado atrav´es da integra¸c˜ao de struct tb com a estrutura de dados struct task structdo kernel do Linux. Especificamente, ap´os a inicializa¸c˜ao de uma nova tarefa a executar em um n´ucleo espec´ıfico, o valor corrente de RVEC associado com este n´ucleo ir´a ser copiado e armazenado no campo base counter do RVEC que est´a associado com a nova tarefa. Assim, uma atualiza¸c˜ao de base counter deve ser realizada sempre que a tarefa sofre uma migra¸c˜ao entre n´ucleos de processamento, garantindo assim que o RVEC mantenha a propriedade ECP. Mais importante ainda,
este controle de atualiza¸c˜ao ´e executado pelo escalonador de tarefas do Linux, de modo que o RVEC est´a protegido de uma potencial fonte de desvios de tempo.
Entretanto, observe que a opera¸c˜ao de atualiza¸c˜ao causada por um evento de migra¸c˜ao gera uma chamada a um n´ucleo remoto, o que em sistemas Linux sobre- carregados pode fazer com que o sistema pare de funcionar (Kernel PANIC). Esta falha ocorre devido ao aumento na quantidade de chamadas a n´ucleos remotos que faz com que a temporiza¸c˜ao do escalonador de tarefas seja violada. Como forma de evitar esta situa¸c˜ao irrecuper´avel, o controle de migra¸c˜ao do RVEC posterga a atualiza¸c˜ao dos campos base counter e age time ns, como descrito em [113].
Esta implementa¸c˜ao RVEC permite que diferentes threads no sistema possam verificar os seus RVECs atrav´es da chamada de sistema clock gettime(), que vai diretamente para o subsistema temporiza¸c˜ao (timekeeping) do Linux. Neste caso, uma aplica¸c˜ao chama esta fun¸c˜ao com o identificador do rel´ogio CLOCK RV EC como o parˆametro de entrada do rel´ogio desejado.