4.2 Carga de Trabalho
As cargas de trabalho submetidas nos experimentos de simulação são amostras retiradas de rastros de execução de um cluster em produção da Google6. Esses rastros abrangem um período de 29 dias de maio de 2011 e consistem em mais de 25 milhões de requisições por recursos do provedor [43], onde cada requisição está associada com uma instância. Apesar de existir outros rastros de execução mais recentes disponíveis publicamente, tais como os da Azure7, nenhum deles é tão completo (de informações) quanto o da Google. Por exemplo, nos rastros da Azure, não há informação sobre a infraestrutura do cluster. Devido ao grande número, diversidade e maturidade das aplicações que executam na Google, acredita-se que esses dados são uma amostra representativa e relevante de ambientes de provedores de nu- vem. Análises mais detalhadas sobre os rastros são apresentadas nos trabalhos de Reiss et al. [42] e Abdul-Rahman e Aida [6].
Os rastros da Google possuem informações sobre jobs que foram submetidos ao longo dos 29 dias de sua abrangência. Cada job é composto por uma ou mais requisições, cada uma associada com uma instância e definida por suas demandas por recursos (CPU e memória), sua duração (i.e. por quanto tempo sua instância precisa estar em execução para que a requi- sição seja terminada) e suas restrições de alocação e/ou afinidade (opcionais). Quando um job é composto por múltiplas requisições, tipicamente elas possuem as mesmas demandas, duração e restrições (se definidas). Neste trabalho, cada requisição pertencente a um job é considerada como uma requisição independente submetida para o sistema e escalonada de tal forma pelo escalonador.
Os rastros da Google também incluem as capacidades dos servidores da infraestrutura. Essas capacidades são normalizadas como um percentual da capacidade do servidor “mais poderoso” para o recurso em questão. O servidor “mais poderoso” sob o ponto de vista de um recurso é aquele que contém a maior quantidade deste recurso. A requisições nos rastros também usam a mesma escala normalizada para descrever as quantidades de CPU e memória solicitadas, portanto, o escalonamento pode ser executado de forma realista.
6Os rastros de execução da Google estão disponíveis para download em https://github.com/google/cluster-
data/blob/master/ClusterData2011_2.md.
7Os rastros de execução da Azure estão disponíveis para download em
4.2 Carga de Trabalho 49 As requisições podem ser classificadas de acordo com 12 prioridades que podem ser associadas a cada uma delas (0 a 11). Essas prioridades são usadas para definir as diferentes classes de serviço consideradas nos experimentos de simulação. Com base na descrição dos rastros [43] e em trabalhos anteriores [42; 16] é possível agrupar as requisições em três classes de serviço. Os SLOs de disponibilidade estabelecidos para as classes são os mesmos utilizados por Carvalho et al. [16] quando utilizaram o mesmo rastro da Google para avaliação de um modelo de controle de admissão. As classes de serviço consideradas neste trabalho e seus respectivos SLOs de disponibilidade são descritos abaixo:
• A classe A é associada às requisições com prioridades maiores que 8. Essas são as requisições mais importantes na carga de trabalho, visto que supõe-se que suas instân- cias nunca são preemptadas. Por esta razão, esta classe promete uma QoS de 100% de disponibilidade em seu SLO. Esta é a classe mais exigente em termos de QoS, por- tanto, o escalonador baseado em prioridades associa a prioridade mais alta para esta classe, enquanto que o escalonador orientado por QoS considera esta como a classe mais importante (i.e. i = 1);
• A classe B está relacionada com as requisições com prioridades intermediárias (maior que 1 e menor que 9 – [2, 8]). Esta classe tem seu SLO de disponibilidade estabelecido em 90%. O escalonador baseado em prioridades associa a segunda prioridade mais alta para esta classe, enquanto o escalonador orientado por QoS estabelece um valor intermediário para sua importância (i = 2);
• A classe C é a menos exigente em termos de QoS. As requisições com prioridades menores que 2 são associadas com esta classe. As instâncias desta classe são frequen- temente preemptadas em benefício de instâncias com prioridades mais altas [42]. Seu SLO de disponibilidade é definido em 50%. Esta é a classe de menor prioridade para o escalonador baseado em prioridade como também a classe menos importante para o escalonador orientado por QoS (i = 3).
Simular todo o rastro da Google é muito caro em termos de tempo de processamento e recursos necessários. Por esta razão, 10 amostras de cargas de trabalho foram geradas a partir do rastro original.
4.2 Carga de Trabalho 50
4.2.1 Geração de amostras da carga de trabalho
As amostras da carga de trabalho foram geradas da seguinte forma. Inicialmente, uma aná- lise de agrupamento dos usuários da Google foi realizada. Esta análise aplicou o algoritmo de agrupamento k-means, levando em consideração, para cada usuário, o número de requi- sições submetidas e a variância das durações e quantidades de CPU e memória solicitadas nessas requisições. Esta investigação resultou em 6 grupos de usuários. Com o intuito de gerar uma amostra da carga de trabalho, 10% dos usuários de cada um dos grupos foram selecionados aleatoriamente. A amostra da carga resultante consiste de todas as requisições submetidas pelos usuários selecionados. Esse processo foi repetido dez vezes, gerando as 10amostras utilizadas neste trabalho. Todas as cargas foram geradas a partir das requisições presentes no rastro original, i.e. requisições selecionadas para uma amostra também podem ser selecionadas para outras amostras.
As Figuras 4.2 e 4.3 apresentam, respectivamente, as quantidades de CPU e memória alocadas ao longo do tempo (medidas em intervalos de 1 minuto) para cada amostra, quando submetidas em uma infraestrutura hipotética com um único servidor com capacidade infinita para CPU e memória. Em ambas as figuras, a unidade do recurso alocado é o valor norma- lizado presente no rastro. Por exemplo, uma alocação de 90 CPU ou memória significa que a demanda para o recurso no tempo específico é 90 vezes maior que a capacidade do melhor servidor da infraestrutura para o recurso em questão. Nesses gráficos a demanda da carga de trabalho também é diferenciada pelas três classes de serviço consideradas.
As 10 amostras da carga8 possuem requisições de todas as classes de serviço e diferem substancialmente entre si; suas formas, a combinação de requisições por classe de serviço, as demandas dos picos de requisições e suas intensidades são diferentes. Essa heterogeneidade das amostras se deve ao fato de diferentes subconjuntos de usuários reais levarem a diferen- tes agrupamentos de requisições. Ademais, esta variabilidade é importante para analisar o escalonador sob diferentes (e ainda verossímeis) cargas de trabalho.
8As amostras da carga utilizadas nos experimentos de simulação e medição ao longo deste trabalho es-
tão disponíveis para download em https://github.com/giovannifs/qos-driven-scheduling-experiments/tree/phd- thesis/workloads. Além disso, instruções sobre como executar os experimentos são apresentadas no Apên- dice A.