Projeto Experimental

Os experimentos de simulação seguem um projeto fatorial completo com três fatores: a polí- tica de escalonamento utilizada, a carga de trabalho e o valor configurado para a otimização relaxed randomization. O primeiro tem dois níveis: o escalonamento baseado em priori- dade e o escalonamento orientado por QoS. O segundo fator possui três níveis que serão descritos adiante nesta seção. O terceiro fator possui cinco níveis: 5%, 10%, 25%, 50% e 100%. Quanto maior o valor deste fator, maior a quantidade de servidores que precisam ser verificados. Na prática, o valor de 100% indica que esta otimização está “desligada”. Este valor estabelece que o escalonador pare de verificar servidores quando encontrar um total de servidores elegíveis equivalente a 100% dos servidores da infraestrutura , o que obriga o escalonador a verificar todos os servidores da infraestrutura. Obviamente, mesmo que nem todos os servidores sejam elegíveis para a alocação da requisição, todos os servidores da infraestrutura são verificados.

A partir desses experimentos, analisa-se para cada escalonador qual a configuração da relaxed randomization resulta no melhor custo/benefício. Quanto menor o valor configurado, menor a quantidade de operações necessárias, portanto, sob este ponto de vista, busca-se diminuir ao máximo o valor configurado. Por outro lado, a avaliação de um número menor

7.1 Análise de Desempenho 88 de servidores pode trazer impactos à QoS do escalonador. Por esta razão, examina-se como esses valores impactam na QoS provida por cada escalonador. Neste estudo, a QoS provida é analisada através da satisfação do SLO e do custo das penalidades. Uma vez que a “melhor” configuração seja identificada para cada escalonador, as quantidades de operações executadas são contabilizadas e comparadas.

Cada um dos testes do experimento foi executado 25 vezes e as análises são feitas atra- vés dos intervalos de confiança de 95% das métricas de interesse. As subseções a seguir descrevem a definição das amostras (infraestrutura e carga de trabalho) analisadas.

Infraestrutura

A infraestrutura utilizada consistiu de um conjunto de servidores selecionados aleatoria- mente (sem reposição) dos rastros da Google. Um servidor por vez foi sorteado até que a capacidade agregada da infraestrutura sorteada atingisse 5% da capacidade total dos rastros da Google. Esse processo resultou em 620 servidores heterogêneos.

Carga de Trabalho

A geração das amostras da carga ocorreu através da utilização de um controle de admissão simples. O controle implementado funciona de forma offline, ou seja, a carga foi gerada sem a necessidade de execução do simulador. As entradas para este controle são: as requisições do rastro da Google, os servidores da infraestrutura utilizada e um percentual indicando o limite dos recursos da infraestrutura a ser considerado para alocação. Como resultado, o controle entrega um subconjunto das requisições capaz de ser escalonado na infraestrutura informada. Neste modelo, o controle de admissão não considera fragmentação de recursos, i.e. examina a capacidade agregada da infraestrutura como se fosse um único servidor, ao invés de um conjunto de servidores menores.

O controle de admissão filtra as requisições dos rastros, admitindo ou rejeitando as mes- mas. A ideia é que o controle admita as requisições até que as requisições ativas no sistema alcancem um limite (configurável) da capacidade da infraestrutura — o percentual infor- mado como entrada do controle. Uma vez que uma requisição é admitida, ela é considerada ativa no sistema ao longo de seu tempo de duração a partir do momento de sua admissão. Isso indica que este controle não considera possíveis períodos da requisição em fila. Uma

7.1 Análise de Desempenho 89 requisição que passa algum período na fila de espera necessariamente estará no sistema por uma quantidade de tempo maior que sua duração. Isso ocorre porque ela levará mais tempo para alcançar a quantidade de tempo desejada com recursos alocados. Uma nova requisição é admitida se: (i) existir servidor na infraestrutura que atende suas restrições de alocação e afinidade (se definidas); e, (ii) as quantidades de recursos por ela solicitadas somadas às quantidades agregadas das requisições ativas não excederem o limite de alocação para ne- nhum tipo de recurso.

Com o intuito de gerar cargas com diferentes demandas, o controle de admissão foi utilizado com três limites de alocação distintos:

(i) 100% da capacidade da infraestrutura (maior contenção): o controle admite requisi- ções enquanto a demanda das requisições ativas não exceder a capacidade da infraes- trutura. Visto que o controle de admissão não considera o tempo das requisições em fila nem o desperdício com a fragmentação de recursos, considerar 100% da capaci- dade da infraestrutura já leva a uma carga com nível de contenção considerável. Este foi o maior limite analisado, portanto, gerou a carga com maior nível de contenção; (ii) 95% da capacidade da infraestrutura (média contenção): o controle admite requisi-

ções enquanto a demanda das requisições ativas não exceder 95% da capacidade da infraestrutura. Este foi o segundo maior limite examinado, portanto, gerou a carga com o nível de contenção médio;

(iii) 90% da capacidade da infraestrutura (menor contenção): o controle admite requisi- ções enquanto a demanda das requisições ativas não exceder 90% da capacidade da infraestrutura. Este foi o menor limite analisado, gerando a carga com menor nível de contenção.

Para permitir que as simulações executassem rapidamente (no máximo 1, 5 hora) com os recursos disponíveis e viabilizar a execução de uma maior quantidade de repetições para cada teste, esta análise se deu considerando a primeira 1 hora dos rastros de execução. Portanto, o conjunto de requisições submetidas ao longo da primeira hora do rastros foi submetido ao controle de admissão. Este controle filtrou as cargas considerando os limites acima menci- onados. É importante destacar que o realismo da carga de trabalho é mais importante para

7.1 Análise de Desempenho 90 as questões relacionadas com avaliação da QoS provida pelo escalonador. O objetivo desta análise é entender como um escalonador se compara ao outro (em termos de número de ope- rações) em diferentes níveis de contenção. Portanto, apenas a configuração da otimização relaxed randomization (que pode afetar a QoS do escalonador) poderia ser potencialmente afetada caso uma carga de trabalho menos realista fosse utilizada nesta análise.

Ainda é importante destacar algumas características dos rastros da Google [43]. Pri- meiramente, a Google realiza overbooking, portanto, as quantidades de recursos solicitadas pelas requisições nos rastros são maiores que as capacidades da infraestrutura descrita no mesmo. Além disso, o primeiro tempo disponível nos rastros (tempo 0) contém todas as requisições que estavam executando no sistema antes do início do mesmo. Algumas dessas estão associadas com tarefas de longa duração e permanecem no sistema até o final do ras- tros de execução. Caso o controle de admissão considere o limite total para alocação desde o tempo 0, as requisições admitidas neste instante já ocupam toda a infraestrutura durante o período completo de análise. Consequentemente, novas requisições não seriam admitidas ao longo do tempo. Como o objetivo deste estudo é analisar o desempenho dos escalonadores em um cenário onde requisições são admitidas e terminadas ao longo do tempo, o controle de admissão tem um tratamento especial para o início do trace. Particularmente no tempo 0, o controle admite requisições enquanto a quantidade agregada de recursos solicitados não exceder o limite de alocação reduzido em 20%. Em outras palavras, no tempo 0, o controle de admissão considera 80%, 75% e 70% da capacidade como limites para admissão nos ce- nários com maior, média e menor contenção, respectivamente. Isso garante que ao menos 20%da capacidade alocável da infraestrutura esteja destinada às requisições submetidas ao longo do tempo.

Por fim, as requisições das cargas geradas são categorizadas nas classes de serviço A, B e C seguindo o mesmo método descrito na Seção 4.2.