3.3 Métrica de QoS para decisão
O escalonamento orientado por QoS tem como objetivo manter a QoS entregue para todas as requisições admitidas igual ou acima de seus respectivos SLOs. Além disso, a nova polí- tica também pretende promover provisionamento mais justo para requisições de uma mesma classe, particularmente em períodos com contenção de recursos. Nesse sentido, o meca- nismo de preempção da política proposta permite preempções de instâncias em benefício de outras instâncias de mesma classe, buscando reduzir a variância da QoS de suas requisições. No entanto, é inadequado utilizar diretamente a disponibilidade atual das requisições para decidir qual delas deve ter instância(s) alocada(s).
É possível ilustrar isso através de um exemplo simples. Suponha a existência de duas requisições j e k, cada uma associada com apenas uma instância e com o mesmo SLO de disponibilidade de 90%. Além disso, admita que o provedor considera que sempre que uma instância executa ela contribui para aumentar a disponibilidade de sua requisição. Em determinado instante no tempo, o provedor precisa escolher apenas uma dentre as requisições je k para ter recursos alocados à sua instância. A requisição j chegou no sistema 1 hora atrás e sua instância executou por 58 minutos. Com base na Equação 3.1, a disponibilidade de j é de 96, 6%. A requisição k está no sistema por 10 minutos e sua instância tem executado desde que k foi admitida (i.e. por 10 minutos). Portanto, a disponibilidade de k é 100%. Se apenas as disponibilidades das requisições forem consideradas para decidir qual delas deve ter sua instância pendente, a escolha seria a requisição k, visto que sua disponibilidade é maior. No entanto, após aproximadamente 1, 1 minuto na fila de espera, a requisição k teria disponibilidade de 10/11, 1 = 90, 09% e sua instância teria que voltar a executar, caso contrário seu SLO seria violado. Por outro lado, a instância de j poderia ficar na fila de espera por até 4, 4 minutos, antes que seu SLO fosse violado.
O exemplo acima é importante para ilustrar que quando as instâncias ficam pendentes, as disponibilidades de suas requisições são decrementadas em velocidades diferentes. Quanto mais tempo as instâncias de uma requisição tiverem executado e contribuído para sua dispo- nibilidade no passado, mais tempo a requisição pode receber uma determinada ou nenhuma contribuição para sua QoS antes de ter seu SLO não satisfeito.
3.3 Métrica de QoS para decisão 29 (TTV) de uma requisição. Esta métrica indica um intervalo de tempo em que uma requisi- ção j pode permanecer recebendo uma contribuição cj para sua QoS antes de ter seu SLO violado. Por exemplo, considerando que a requisição j está associada com apenas uma ins- tância, o TTV de j indica por quanto tempo j pode ficar sem receber nenhuma contribuição para sua disponibilidade antes de ter seu SLO não atendido. No caso de j estar associada com múltiplas instâncias (n, onde n > 1), as instâncias que já contribuem para melhorar a disponibilidade de j em um instante de tempo podem continuar contribuindo ao longo do TTV. Portanto, supondo que m instâncias de j (m < n) continuarão contribuindo para a QoS de j ao longo do TTV, o TTV resultará em um intervalo de tempo onde j poderá conti- nuar recebendo a contribuição das m instâncias para sua QoS (i.e. cj) antes ter seu SLO não atendido.
Portanto, para uma instância que está em execução, o TTV indica por quanto tempo ela pode, a partir do instante atual, ficar na fila de espera antes que sua requisição tenha seu SLO violado (i.e., caso a instância fosse preemptada neste instante). Para uma instância pendente, o TTV indica por quanto tempo a instância pode permanecer na fila sem que sua requisição tenha seu SLO violado. Assim sendo, o TTV associado às instâncias pendentes é monitorado e, idealmente, não deve atingir valores próximos de zero. Valores próximos de zero indicam que a requisição está próxima de não atender seu SLO.
Considere que j é uma requisição submetida para a classe de serviço i, cujo SLO de disponibilidade é Oi. Além disso, admita que vjr(t)e vjw(t)são, respectivamente, o número de instâncias da requisição j em execução e pendentes em um ponto no tempo t. O intervalo de tempo que j pode permanecer recebendo determinada contribuição para incrementar sua QoS sem que seu SLO seja violado é representado por Δtj(t). Nesse cenário, cj indica a contribuição que a requisição j estará recebendo para melhorar sua disponibilidade ao longo do intervalo Δtj(t). Essa contribuição cj é definida pelo número de instâncias de j que, ao longo de Δtj(t), continuarão efetivamente contribuindo para sua QoS. Assumindo que a disponibilidade atual de j no tempo t é maior ou igual à prometida (Aj(t) ≥ Oi), a Equação 3.1 pode ser utilizada para descobrir quando a meta de disponibilidade Oi da requisição j será alcançada.
Oi =
ej(t) + cjΔtj(t)
ej(t) + dj(t) + pj(t) + (vrj(t) + vjw(t))Δtj(t)
3.3 Métrica de QoS para decisão 30 Como observado acima, o numerador da Equação 3.1 é incrementado com o tempo que as instâncias da requisição j que estarão em execução ao longo de Δtj(t)estarão contribuindo efetivamente para aumentar sua disponibilidade. Já o denominador da mesma equação é incrementado pelo tempo que todas as instâncias de j permanecerão no sistema, estejam elas pendentes ou em execução. Assim, Δtj(t) pode ser calculado como apresentado na Equação 3.3 a seguir. Δtj(t) = ej(t)− Oi(ej(t) + dj(t) + pj(t)) (pr j(t) + pwj(t))Oi− cj ,∀j|Aj(t)≥ Oi. (3.3) Na prática, uma vez que uma instância de uma requisição j é escolhida para deixar a fila de espera, essa instância precisa ser alocada no servidor escolhido. Esta alocação requer, minimamente, o carregamento dos dados da instância para a memória. A instância de j estará pronta para ser executada apenas após esse tempo de alocação tiver decorrido. Assim, o cálculo do TTV deve levar em consideração esse tempo. O tempo de alocação de j pode ser mais longo ou mais curto a depender da instância já ter executado anteriormente no servidor escolhido ou não. Considere que αj é o tempo máximo de alocação esperado para preparar o servidor para executar uma instância de j. Idealmente, o escalonador deve remover a instância de j da fila de espera antes que Δtj(t)− αj = 0, caso contrário, a instância terá seu SLO momentaneamente não satisfeito. Assim o TTV de uma requisição j no tempo t, Δt∗j(t), é computado como definido na Equação 3.4.
Δt∗j(t) = Δtj(t)− αj. (3.4)
No entanto, quando o sistema estiver enfrentando temporariamente um pico de demanda, é possível que o provedor não consiga entregar a QoS prometida para algumas ou até mesmo todas as requisições. Nesse cenário, não faz sentido calcular o TTV para requisições que já estejam recebendo QoS abaixo da prometida, visto que elas já têm seus respectivos SLOs não satisfeitos. Para essas requisições (Aj(t) < Oi), uma outra métrica é definida, denominada recoverability da requisição. Esta métrica indica por quanto tempo as instâncias de uma requisição estiveram pendentes desde que seu SLO passou a não ser atendido (i.e. o tempo excedente em fila de suas instâncias), dando uma ideia de quão recuperável é a requisição.
No tempo t, Δrj(t)indica a quantidade de tempo que as instâncias da requisição j esti- veram pendentes desde que seu SLO passou a não ser satisfeito até t. De forma semelhante
3.3 Métrica de QoS para decisão 31 ao intervalo Δtj(t), a Equação 3.1 pode ser utilizada para descobrir quando a meta de dispo- nibilidade Oida requisição j foi alcançada.
Oi =
ej(t)
ej(t) + dj(t) + pj(t) + Δrj(t)
. (3.5)
Assim, Δrj(t)pode ser calculado como apresentado na Equação 3.6 a seguir. Δrj(t) =
ej(t) Oi − (e
j(t) + dj(t) + pj(t)),∀j|Aj(t) < Oi. (3.6) Destaca-se que Δtj(t)nunca assumirá valores negativos, enquanto Δrj(t)sempre assu- mirá valores negativos. Quanto maior o valor absoluto desta métrica, mais distante a requi- sição está de recuperar sua disponibilidade a fim de ter seu SLO atendido.
Como já discutido nesta seção, na prática, após um servidor ser escolhido para prover recursos para uma instância, a instância estará pronta para a execução no servidor após um tempo de alocação tiver decorrido. Portanto, mesmo que uma requisição esteja recebendo menos disponibilidade que a prometida (i.e. suas instâncias estiveram pendentes por mais tempo do que poderiam), suas instâncias necessariamente estarão pendentes por mais um tempo extra (o tempo de alocação das mesmas). Assim, faz sentido que a recoverability seja calculada de forma conservadora e leve em conta o tempo extra que é necessário para alocar a instância de uma requisição no servidor. Portanto, a recoverability de uma requisição j no tempo t, Δr∗
j(t), é computada como definido na Equação 3.7
Δrj∗(t) = Δrj(t)− αj. (3.7)
Por fim, conhecendo a disponibilidade Aj(t)de todas as requisições no sistema no tempo t, a métrica de QoS Qj(t)é calculada como segue:
Qj(t) = Δt∗ j(t), se Aj(t)≥ Oi Δr∗ j(t), caso contrário
Embora as métricas apresentadas estejam associadas com requisições ativas sistema, quando o escalonador é executado, ele decide sobre alocação e/ou preempção de instâncias. Por esta razão, ao executar o escalonador no tempo t, uma métrica Qj(t)é associada com
3.4 Política de Escalonamento 32