Estratégias de migração

As estratégias de migração apresentadas nesta seção foram projetadas para atender aos requisitos e implementar os componentes das arquitetura das Figuras 5.1, 5.2, 5.3 e 5.4. Os dois principais componentes implementados já fazem parte também do simulador MyiFogSim e serão apresentados nas próximas seções 5.4.2 e 5.4.2.

Interface decisão de migração

A Figura 5.12 mostra o módulo MigrationDecision através de uma interface UML (Uni- fied Modeling Language) que implementa o padrão de projeto strategy. MigrationDecision contém um único método booleano chamado shouldMigrate e que deve ser implementado de acordo com a política escolhida.

CAPÍTULO 5. MIGRAÇÃO DE MÁQUINAS VIRTUAIS EM FOG COMPUTING 48

Para esta pesquisa foram consideradas três estratégias de escolha da próxima Clou- dlet1_{, a saber:}

• Menor distância entre o dispositivo do usuário e o AP: Esta estratégia irá escolher a próxima Cloudlet que estiver ligada ao próximo AP mais perto do usuário. • Menor distância entre o dispositivo do usuário o a Cloudlet: Esta estratégia irá

escolher a Cloudlet de menor distância com o usuário.

• Menor Latência: Esta estratégia irá escolher a Cloudlet com menor custo entre um conjunto de Cloudlets candidatas.

A Figura 5.13 mostra que essas estratégias podem escolher Cloudlets diferentes a depender do posicionamento geográfico do usuário ou ainda da carga de processamento de uma Cloudlet.

Figura 5.13: Possíveis escolhas das estratégias de migração.

Todas estas estratégias foram testadas com a permutação dos parâmetros da política de migração, como por exemplo, dois pontos diferentes de migração (estático e dinâmico - Seção 5.4.1), três tipos diferentes de migração (tradicional, container e ao vivo - Seção 2.2) e três capacidades diferentes de rede entre as Cloudlets (lenta, média e rápida). São 18 combinações para cada estratégia o que dá um total de 54 combinações. Alguns exemplos destas combinações são:

1_{Como mencionado anteriormente, CloudSim usa cloudlet com uma aplicação e para não haver dupli-}

cidade de nomes, na implementação de MyiFogSim todos os hospedeiros do tipo Cloudlet são chamados de serverCloudlet

CAPÍTULO 5. MIGRAÇÃO DE MÁQUINAS VIRTUAIS EM FOG COMPUTING 49

• Menor distância entre o dispositivo do usuário e o AP, ponto de migração estático, migração tradicional, rede lenta.

• Menor distância entre o dispositivo do usuário e a Cloudlet, Ponto de migração estático, migração de container, rede média.

• Menor latência, ponto de migração estático, migração ao vivo, rede rápida.

• Menor distância entre o dispositivo do usuário e o AP, ponto de migração dinâmico, migração de container, rede lenta.

• Menor latência, ponto de migração dinâmico, migração ao vivo, rede rápida. Interface Antes de migrar

A Figura 5.14 ilustra o módulo BeforeMigration com o mesmo modelo de implementa- ção de MigrationDecision. Esta interface tem três métodos para serem implementados de acordo com a estratégia escolhida pelo desenvolvedor: i) dataPrepare, ii) openConnec- tion e iii) tryOpenConnection

Figura 5.14: Padrão de projeto strategy para beforeMigration

dataPrepare é o principal método da interface beforeMigration e também deve ser implementado de acordo com a política e estratégia de migração escolhidas e para esta dissertação foram implementadas três classes distintas de preparação dos dados, a saber:

CAPÍTULO 5. MIGRAÇÃO DE MÁQUINAS VIRTUAIS EM FOG COMPUTING 50

• PrepareCompleteVM: É baseada na técnica tradicional de migração de máquinas virtuais. Durante sua execução 100% da máquina será entregue para o sistema de trasporte de dados. Assim que os dados forem entregues a máquina virtual entrará em downtime.

• PrepareContainerVM: É baseada na técnica de migração de containers. Durante sua execução 60% dos dados serão entregues para a migração, porém é introduzido um custo a mais para o processamento da imagem do container. Assim que os dados forem entregues a máquina virtual entrará em downtime.

• PrepareLiveMigration: É baseada na técnica de migração ao vivo de pós-cópia. Durante sua execução os dados são entregues em duas etapas, i) dados de sistema e de usuário que não estão carregados na memória principal e ii) os dados que estão em execução na memória principal. O serviço só entrará em downtime quando o usuário atingir o limite para o início do handoff.

A arquitetura, os algoritmos e a técnica de migração apresentados neste capítulo con- tém uma série componentes que necessitam ser testados e validados. O próximo capítulo descreve os testes baseados em simulações, mostra os resultados encontrados e faz uma discussão sobre estes resultados.

Capítulo 6

Simulações

Após estabelecidas as arquiteturas (topológica e em camadas), os algoritmos de migração, as políticas de migração, as estratégias de migração e finalizada a implementação do simulador MyiFogSim, iniciou-se o processo de testes e validação através de duas etapas de simulações. Inicialmente, foi verificado se realmente um processo de migração na névoa melhora ou não a QoE do usuários. A configuração e resultados desta Etapa 1 encontram- se na Seção 6.1. Após análise, passou-se então para a Etapa 2, que compara diretamente as permutações de parâmetros das políticas de migração discutidas no final da Seção 5.4.2, bem como são comparadas as estratégias de migração. Os aspectos da Etapa 2 são apresentados na Seção 6.2.

As duas etapas utilizaram as mesmas configurações básicas para montar o ambiente de simulação. Estas configurações são:

• Sementes da simulação: Foram utilizadas 30 sementes para cada cenário da simulação.

• Tamanho do mapa: um quadrado de 40km por 40km, sem obstáculos e sem caminhos definidos.

• Modelo de mobilidade: Os usuários sempre andam em linha reta, na mesma direção e em velocidade constante até o final do mapa, quando então são removidos da simulação. Para a Etapa 1 um único usuário foi posicionado em uma das extre- midades do mapa e foi atribuída a velocidade máxima no escopo desta simulação (19 m/s) e a direção para a extremidade oposta do mapa (o usuário percorreu uma hipotenusa do mapa). Para a Etapa 2, mais de um usuário estavam presentes na simulação e cada um deles recebeu uma posição, uma direção e uma velocidade aleatoriamente conforme detalhes abaixo. Nas duas etapas, a posição do usuário é atualizada a cada loop da simulação de acordo com sua velocidade e direção. • Velocidades: Cada usuário recebeu uma velocidade aleatoriamente de uma distri-

buição uniforme entre 1 m/s e 19 m/s, inclusive.

• Posições no mapa: Cada posição no mapa é equivalente a 1 metro.

• Direções: As direções variam entre as oito direções cardinais descritas anterior- mente na Seção 5.4.1.

CAPÍTULO 6. SIMULAÇÕES 52

• Posicionamento das Cloudlets: As Cloudlets foram distribuídas uniformemente no mapa num total de 16 servidores.

• Redes entre as Cloudlets: Para simplificar, como topologia de rede escolheu-se uma full mesh (Rede em malha completa) onde todas as Cloudlets estão conectadas entre elas em um grafo completo. Para os testes foram escolhidos três grupos de intervalos de velocidade de taxa de transmissão dos links. Cada link de um par de Cloudlets recebeu aleatoriamente numa distribuição uniforme

1. valores entre 10Mbps e 20Mbps para uma rede lenta; ou 2. valores entre 90Mbps e 100Mbps para uma rede média; ou 3. valores entre 990Mbps e 1Gbps para uma rede rápida.

• Posicionamento dos APs: Os APs foram distribuídos uniformemente no mapa num total de 39 torres. Cada AP foi conectado apenas à Cloudlet mais próxima. Uma Cloudlet pode ter vários APs conectados a ela.

• Cobertura dos APs: A cobertura máxima de cada AP é de 5km de raio, similar- mente ao ideal para uma célula LTE.

• Política e ponto de handoff: Para simplificar o modelo de handoff, foi utilizado um ponto fixo máximo para o início do processo de troca de APs baseado na distância entre o usuário e o AP. A distância máxima é de 40 metros antes do usuário atingir o limite de cobertura. O tempo de handoff foi atribuído aleatoriamente de uma distribuição uniforme num intervalo de 700 ms à 1200 ms.

• Tamanho da máquina virtual: O tamanho das máquinas virtuais está compre- endido entre 100 MB e 200 MB e são atribuídos aleatoriamente em uma distribuição uniforme.

• Tamanho da imagem do container: Para simplificar foi estabelecido um tama- nho fixo de 60% do tamanho da máquina virtual do usuário.

• Ponto de migração estático: Nas duas etapas o ponto fixo é estabelecido na distância de 30% antes ao ponto de handoff, ou seja, o ponto fixo é de 52 metros antes do limite de cobertura do AP.

• Ponto de migração dinâmico: Não foi utilizado para a Etapa 1. Para a Etapa 2, este ponto baseou-se na velocidade do usuário, no tamanho a máquina virtual e na capacidade do link entre as Cloudlets. A ideia é que, a depender dos valores, a migração iniciará antes ou depois do ponto estático, porém, não menos que o ponto limite para o handoff. A hipótese é que este ponto dinâmico diminua o downtime da aplicação.

• Envio de tuplas para processamento: Foi utilizada a aplicação EEG Tractor Beam Game de exemplo que já está implementada no iFogSim [15]. Esta aplicação é um jogo em que os jogadores usam um dispositivo que captura ondas cerebrais atra- vés de um headset conectado a um smartphone e dependendo de sua concentração,

CAPÍTULO 6. SIMULAÇÕES 53

objetos (virtuais) são atraídos em sua direção. A Figura 6.1 ilustra a implementação deste jogo em iFogSim, contendo cinco AppModules e sete AppEgdes para simular o comportamento original apresentado em [33]. Os AppModules são: i) um sensor, ii) um smartphone, iii) um calculador de concentração, iv) um coordenador e v) um atuador. O sensor, o atuador e o smartphone são os dispositivos do usuário. O calculador de concentração e o coordenador são implementados em uma névoa. A tuplas são geradas a cada 10 ms pelo sensor e parte delas são processadas no smartphone e outra parte na névoa. O resultado do processamento é executado pelo atuador.

• Tempo de simulação: O tempo de simulação foi 30 minutos.

Figura 6.1: Aplicação utilizada na simulação. Adaptado de [15]

6.1

Etapa 1: Diferença entre não migrar e migrar uma

máquina virtual

As simulações para esta etapa foram divididas em duas partes. Primeiro foram reali- zadas simulações em que um único usuário percorria todo o mapa fazendo os processos de handoff necessários, porém sem realizar nenhuma migração. Até o fim do mapa, a máquina virtual permaneceu na primeira Cloudlet que o usuário se conectou. Segundo, as simulações ocorreram similarmente às anteriores, no entanto agora as máquinas virtu- ais foram migradas de acordo com as políticas e estratégias escolhidas. Para este último cenário de migração considerou-se somente o ponto de migração estático e a estratégia de migração tradicional (migrar a máquina virtual completa). Nestas duas partes, somente uma semente foi executada.

A Figura 6.2 mostra o gráfico obtido a partir de todas as latências que a aplicação sofreu durante o percurso sem haver o processo de migração. Os três tipos de redes (lenta, média e rápida) foram simuladas.

CAPÍTULO 6. SIMULAÇÕES 54

Figura 6.2: Comparação das latências entre as capacidades de redes quando o usuário não migra

Observa-se que toda a simulação está presente (1.800 s - 30 min) no gráfico. Em todas as redes houve o mesmo comportamento das latências e por esse motivo, a latência na rede rápida sobrepõe as outras redes. Os resultados indicam que no início do percurso do usuário a latência se manteve estável, com variações em torno de 20 ms a 29 ms (alternadamente). Isso explica porque há uma “única linha” espessa nesta primeira parte do gráfico. Logo após 200 s da simulação, há um salto para uma latência constante com variações entre aproximadamente 119 ms e 128 ms (alternadamente), que também explica a “linha” espessa formada. O próximo salto acontece um pouco antes de 800 s e a latência se mantém estável em torno de 160 ms sem alternar com outros valores, o que explica uma “única linha” mais fina no gráfico. Outros saltos de latência acontecem até o fim da simulação. É possível afirmar que nestes saltos de latência haveria a necessidade de serem realizadas as migrações. No final da simulação, o usuário estava acessando sua máquina virtual a seis Cloudlets de distância de rede.

A Figura 6.3 mostra um gráfico da comparação entre as latências quando não há migração e quando há. Em ambos, as simulações ocorreram em uma rede lenta.

CAPÍTULO 6. SIMULAÇÕES 55

Figura 6.3: Comparação das latências para uma rede lenta entre não migrar e migrar O início das curvas de latência em ambos os cenários, obviamente, permaneceram idênticas, pois o usuário estava acessando sua máquina virtual na primeira Cloudlet que se conectou. Igualmente como no gráfico anterior, há o salto de latência no cenário de não migração, porém nota-se que neste mesmo ponto houve o primeiro processo de migração e após o processo ter terminado, a latência voltou a ficar em torno de 20 ms. O mesmo acontece para os gráficos das Figuras 6.4 e 6.5 que representam, respectivamente, os cenários de rede média e rápida.

CAPÍTULO 6. SIMULAÇÕES 56

Figura 6.5: Comparação das latências para uma rede rápida entre não migrar e migrar As Figuras 6.6, 6.7 e 6.8 mostram, respectivamente para redes lentas, médias e rápidas, os gráficos das latências entre: i) Não migrar, ii) migrar com a estratégia de menor latência, iii) migrar com a estratégia de menor distância entre o SmartThing e o ServerClouldlet e iv) migrar com a estratégia de menor distância entre o SmartThing e o AccessPoint.

Figura 6.6: Comparação das latências para uma rede lenta entre não migrar e migrar com e todas as estratégias

CAPÍTULO 6. SIMULAÇÕES 57

Figura 6.7: Comparação das latências para uma rede média entre não migrar e migrar com e todas as estratégias

Figura 6.8: Comparação das latências para uma rede rápida entre não migrar e migrar com e todas as estratégias

Cada uma das estratégias implementadas apresenta comportamento distinto. Uma análise mais detalhada destes comportamentos é descrita e apresentada na Seção 6.3.

A Figura 6.9 mostra o gráfico com as médias das latências do usuário sem migração e utilizando os mecanismos de migração propostos. Nota-se que quando não há migração da máquina virtual, a média é maior que 200 ms o que degrada a QoE do usuário.

CAPÍTULO 6. SIMULAÇÕES 58

Figura 6.9: Média das latências de um usuário da primeira semente em diferentes no cenário de não migração e nos cenários de migração.

Entre as estratégias de migração, algumas também se mostram melhores do que outras. Na próxima etapa há gráficos semelhantes com as médias das latências para os grupos de cinco e dez usuários.

Após a análise destes resultados, pode-se afirmar que mesmo havendo tempo em que máquina virtual fica inacessível (downtime), obtém-se uma melhor QoE em cenário onde as névoas oferecem o serviço de migração de máquinas virtuais.