Estrat´egias de Escalonamento e Provisionamento

A eficiˆencia do Provider est´a relacionada com a forma como ele escalona e monitora as instˆancias OddCI delegadas para os Controllers do sistema OddCI. Ap´os receber uma solicitac¸˜ao de um Client, o Provider deve selecionar o subconjunto de Controllers capazes de lidar com os requisitos solicitados, e tamb´em definir quais deles devem ser escolhidos para atender a instˆancia OddCI, considerando tanto o cumprimento do SLA estabelecido, bem como garantir um melhor resultado operacional, ou seja, reduzindo a redundˆancia ne- cess´aria a um valor mais pr´oximo do m´ınimo exigido.

Quando um Client submete um pedido para criac¸˜ao de uma instˆancia OddCI, ele define os requisitos desejados para os recursos (tipo, quantidade, etc) em uma OIR (OddCI Instan- tiation Request).

No contexto OddCI, a estrat´egia usada pelo Provider para distribuir as OIR pelo conjunto de Controllers ´e chamada estrat´egia de escalonamento. Esta estrat´egia pode ser implemen- tada pragmaticamente atrav´es do uso de uma func¸˜ao de custo que ´e capaz de implementar uma avaliac¸˜ao dos crit´erios desejados sobre o conjunto de Controllers dispon´ıveis.

Sejaf (O, Ci) uma func¸˜ao que retorna verdadeiro ou falso, dependendo se o Controller

Cipode ou n˜ao pode atender a OIRO, e c(O, CI) seja a func¸˜ao de custo para a criac¸˜ao de O

emCi. O ControllerCi ´e escolhido se:

f (O, Ci) ^ 6 9 Cj | f (O, Cj) ^ c(O, Cj) < c(O, Ci).

Dependendo da estrat´egia para a selec¸˜ao do Controller, a func¸˜aoc pode ser definida de modo a refletir os crit´erios desejados. Por exemplo, o custo estimado pode refletir tanto um crit´erio mais direto, como o prec¸o a ser pago pelo Provider para cada slot de processamento usado em uma rede de broadcast espec´ıfica, e tamb´em pode considerar aspectos mais com- plexos, tais como o risco do Provider de incorrer no pagamento de eventuais sanc¸˜oes por n˜ao cumprir com a OIR ou o custo envolvido pela necessidade do Provider ter que usar um excedente de recursos para manter o tamanho da instˆancia nos n´ıveis adequados.

Por sua vez, o Controller deve tentar manter o n´ıvel real de paralelismo (PR), ou tamanho

da instˆancia, durante o seu ciclo de vida t˜ao perto quanto poss´ıvel do n´ıvel de paralelismo solicitado (PS) para evitar violac¸˜oes do SLA. O tamanho da instˆancia ´e definido pela quan-

5.4 Aspectos de Implementac¸˜ao 85

tidade de dispositivos ativos que ela cont´em em um dado momento. Baseando-se tanto em informac¸˜oes instantˆaneas enviadas pelos PNAs quanto em dados hist´oricos, o Controller precisa disparar as mensagens de controle necess´arias para coordenar esse equil´ıbrio. N´os chamamos este procedimento de estrat´egia de provisionamento.

Por suas caracter´ısticas ´unicas e considerando um cen´ario best-effort, o custo de migrac¸˜ao de recursos computacionais em um sistema OddCI ´e o mesmo, independentemente da quan- tidade de recursos computacionais que foram perdidos. Isto ocorre porque o esforc¸o envol- vido em um wakeup process ´e praticamente o mesmo, seja a WM destinada a alocar um ou um milh˜ao de dispositivos. A sua durac¸˜ao depende unicamente do tamanho da imagem da aplicac¸˜ao e da largura de banda do canal de broadcast. No entanto, essa caracter´ıstica traz consigo uma sobrecarga de coordenac¸˜ao potencial, porque qualquer excedente de dis- positivos ativado pela WM deve ser eliminado pelo Controller, e isto ´e realizado trocando mensagens atrav´es do canal direto. Esta operac¸˜ao consome recursos dos dispositivos, do canal direto, e do Controller. Tal sobrecarga deve ser minimizada.

Para o bom funcionamento das estrat´egias de provisionamento, ´e essencial que o Control- lertenha uma boa aproximac¸˜ao da populac¸˜ao de recursos `a disposic¸˜ao (_{Ω), da redundˆancia} necess´aria (R), e do n´umero total de recursos que ser˜ao potencialmente afetados pelo wa- keup process. Uma vez estimado o valor de _{|Ω| e definido o valor de P}S para incluir R,

ondePS+ R < |Ω|, ´e importante tomar cuidado para que somente PS+ R recursos respon-

dam a uma WM, apesar de todos os recursos conectados ao canal de broadcast de um dado Controllerreceberem a WM transmitida pelo canal. Este problema torna-se mais cr´ıtico nos casos em quePS+ R << |Ω|.

Uma estrat´egia simples para acionar apenas um subconjunto de tamanho aproximada- mente igual aPS + R numa populac¸˜ao alvo de tamanho |Ω| ´e enviar, com a WM, um fator

probabil´ıstico p de tal forma que cada recurso que recebe a WM a descarta com probabi- lidade 1 p. O valor de p pode ser inicialmente determinado pela raz˜ao entre PS e |Ω| e

ajustado em rodadas sucessivas, considerando tamb´em o n´umero de recursos que respondem a WM, o qual ser´a utilizado para melhorar a estimativa de_|Ω|.

Com o uso de ranqueamento, o crit´erio de elegibilidade do PNA primeiro verifica o rankingdo dispositivo e depois aplica o fator probabil´ıstico indicado emp, o qual deve ter sido calculado considerando uma estimativa da quantidade de dispositivos dispon´ıveis que

atendem ao alvo de ranqueamento desejado. Eventualmente, o Controller pode precisar diminuir o ranking-alvo para ajust´a-lo `a condic¸˜ao atual de ranqueamento dos dispositivos dispon´ıveis e conseguir obter a quantidade necess´aria de dispositivos para repor o tamanho da instˆancia.

Ap´os a criac¸˜ao da instˆancia, o Provider mant´em contato com os Controllers a fim de monitorar os requisitos solicitados. Se necess´ario e poss´ıvel, o Provider pode redistribuir instˆancias OddCI entre Controllers para refletir um novo estado do sistema causado pela criac¸˜ao e desmonte de outras instˆancias OddCI, a perda de dispositivos das v´arias redes de broadcastetc. Isto pode envolver a avaliac¸˜ao de escalonamento alternativo para a instˆancia, com a poss´ıvel selec¸˜ao de outros Controllers. Portanto, a estrat´egia de escalonamento deve ser cuidadosamente projetada para otimizar o uso dos recursos dispon´ıveis, levando em considerac¸˜ao o contexto em que o OddCI est´a sendo implantado de forma a minimizar os custos do Provider e maximizar a sua eficiˆencia.