• Nenhum resultado encontrado

Negociação de Recursos Intra-domínio

Ao iniciar um experimento DiffServ a preparação do domínio é realizada de forma estática de acordo com a configuração específica do experimento. Dois ou mais experimentos Gerador de Fluxos podem ser acessados ao mesmo tempo. No entanto, a alocação de recursos é dinâmica, ou seja, um experimento apenas poderá ser iniciado caso haja recursos suficientes para que ele submeta os seus fluxos adequadamente.

As informações sobre quais fluxos e quais valores devem ser alocados são mantidos pelo BB. Logo, no início de cada experimento Gerador de Fluxos, este deve comunicar-se com o BB e soli- citar a alocação de recursos com base na configuração atual. Caso seja possível a alocação, o BB armazena essa informação na base de dados, reduz a porção de banda disponível e permite o início do experimento.

É interessante notar que o experimento Gerador de Fluxos pode submeter fluxos além do permi- tido para o seu PHB. Nesse caso, a própria configuração irá impedir que os agregados excedentes passem pelo domínio. A configuração DiffServ mantida pelas heurísticas do BB garante que dois ou mais experimentos submetam fluxos à rede dentro dos limites do PHB.

Dessa forma, o BB é capaz de oferecer a garantia de submissão com QoS para os fluxos do expe- rimento, evitando que muitos experimentos sejam iniciados e sobrecarreguem a rede. Um problema potencial é que a rede pode ser subutilizada caso nenhum fluxo seja submetido por um experimento, evitando que outros experimentos sejam iniciados. No entanto, uma vez que o experimento seja iniciado, existe a garantia de que a QoS oferecida não irá sofrer perda de desempenho em virtude do aumento ou diminuição da quantidade de experimentos. Essa característica é importante para o experimento Gerador de Fluxos porque assegura a coerência dos resultados. Uma alternativa para permitir que mais usuários utilizem a rede do WebLab é distribuir corretamente as porções da banda entre os experimentos. Isso permite que muitos experimentos sejam iniciados, mas com a garantia de vazão mínima dependente do número de experimentos admitidos ao mesmo tempo. O BB mantém,

de acordo com as alocações dinâmicas, a quantidade ideal de experimentos que podem ser iniciados sem sobrecarregar a rede. A Tab. 5.14 mostra um exemplo de SLA para dois experimentos agendados para o mesmo período.

IDSLA IDUsuario IDExp QOS

1 1 A AF11,0x28,1,MBps,3,MBps;

2 1 B AF11,0x28,1,MBps,3,MBps;

Tab. 5.14: SLA dos experimentos A e B.

A Tab. 5.15 ilustra um exemplo de negociação de recursos entre dois experimentos. O significado das colunas é descrito a seguir:

• Op: Índice da operação do experimento para a solicitação de alocação de largura de banda do PHB;

• ID Exp: Índice do experimento;

• Solic: Quantidade de largura de banda solicitada para alocação; • R2: Regra da heurística 2;

• iQoS: Elemento do BB que promove a realocação de largura de banda;

• Alocado: Valor mantido no BB (Tabela PHB) para indicar a alocação global e atual de recursos; • Ativo: Valor mantido no BB (Tabela PHB) para indicar a quantidade de operações de alocação

ativas;

• UsoReal: Valor máximo de largura de banda permitido para o PHB / quantidade de operações de alocação ativas. Esse valor é utilizado para consultar a distribuição real de recursos para cada agregado no experimento.

• Aceito: Indica se a operação de solicitação de recursos pelo experimento foi ou não aceita; • Aloc Exp: Indica a quantidade de recursos alocados para o agregado no experimento (Tabela

PHB_EXPERIMENTOS).

A quantidade de experimentos que podem utilizar a porção de banda do PHB com a garantia mínima de vazão é determinada dinamicamente de acordo com a alocação no BB e os valores de alocação mínimo e máximo permitidos para o PHB. Cada solicitação apresentada na Tab. 5.15 é feita para o PHB AF11 que reserva recursos de banda para uma vazão de até 3MBps com o uso das heurísticas.

Na operação 1, o experimento B solicita a alocação de 1MBps da largura de banda disponível de AF11. A regra da heurística 2 verifica que o valor solicitado é menor do que o máximo permitido para o PHB e que, com base na alocação atual, mais banda pode ser alocada para o experimento. Então, o BB armazena as informações sobre a alocação, a quantidade de operações de alocação ativas e o uso real da banda. Para apenas um fluxo toda a banda pode ser utilizada. A operação de alocação é aceita e o BB armazena a quantidade de banda alocada para o PHB no experimento.

Na operação 2 o mesmo procedimento anterior é adotado, mas agora os dois experimentos irão dividir a largura de banda disponível.

R2 iQoS Alocado Ativo UsoReal Aceito Aloc Exp Op ID Exp Solic - - 0 0 0 - 0 1 B 1 Sim - 1 1 3 Sim 1 2 A 2 Sim - 3 2 1.5 Sim 2 3 A 1 Não - - - - Não - 4 B -1 - - 2 1 3 - 0 5 A 1 Sim - 3 1 3 Sim 3 6 A -3 - - 0 0 0 - 0 7 B 3 Sim - 3 1 3 Sim 3 8 B -3 - - 0 0 0 - 0 9 B 1.5 Sim - 1.5 1 3 Sim 1.5

10 A 3 Não Sim 2.5 2 1.5 Sim 1

11 A 3 Não Não - - - Não -

Tab. 5.15: Exemplo de negociação de recursos intra-domínio.

Na operação 3 o experimento A não consegue alocar mais recursos porque a regra da heurística 2 não é satisfeita. As informações sobre os valores alocados anteriormente são mantidas, mas a alocação é recusada.

Na operação 4 o experimento B é encerrado e é liberado 1MBps de banda alocada.

Na operação 5 o experimento A repete a solicitação de alocação da operação 3 e consegue adquirir a banda solicitada. O BB registra mais 1MB alocado para o experimento. As operações de 6, 7, 8, 9 e 11 se comportam de forma semelhante às operações apresentadas anteriormente.

Na operação 10 a regra da heurística 2 não é satisfeita, mas ainda existem recursos disponíveis para a alocação. Nesse caso, o método iQoS atua e refaz a solicitação. O algoritmo verifica se a largura de banda disponível garante a quantidade de banda mínima que o experimento deve possuir para funcionar adequadamente. Caso essa premissa seja satisfeita, a banda mínima é alocada, mas o usuário pode ou não aceitar essa alocação. O algoritmo iQoS é um método implementado no BB que garante a realocação mínima de recursos quando a solicitação inicial não puder ser atendida. O trecho a seguir ilustra o funcionamento do algoritmo de negociação de recursos.

negociador_intra_dominio(){ //Heurística 2

//O valor solicitado é menor do que o máximo? if ( max_PHB - solicitado_PHB >= 0 )

//Heurística 2

//Com base no que está alocado, é possível alocar mais? if ( alocado_PHB + solicitado_PHB <= max_PHB )

aprovado = true; else

aprovado = iqos( solicitado_PHB ); if (aprovado){

//Atualiza a alocação do PHB no experimento alocado_PHB_Exp += solicitado_PHB;

alocado_PHB_BB += solicitado_PHB; ativo_PHB_BB++;

//Heurística 3: garantia mínima de recursos usoReal_PHB_BB = max_PHB / ativo_PHB_BB; }//fim if

}//fim negociador_intra_dominio boolean iqos ( solicitado_PHB ){

boolean aprovado = false; //Existem recursos mínimos?

if ( max_PHB - alocado_PHB >= min_PHB ){ solicitado_PHB = min_PHB;

aprovado = true; }//fim if

return aprovado; }//fim iqos