arquitetura e mecanismos para migração de máquinas ... · virtuais entre servidores que estejam...

Universidade Estadual de CampinasInstituto de Computação

INSTITUTO DECOMPUTAÇÃO

Márcio Moraes Lopes

Arquitetura e Mecanismos para Migração de MáquinasVirtuais na Computação em Névoa

CAMPINAS2017


Arquitetura e Mecanismos para Migração de Máquinas Virtuaisna Computação em Névoa

Dissertação apresentada ao Instituto deComputação da Universidade Estadual deCampinas como parte dos requisitos para aobtenção do título de Mestre em Ciência daComputação, na área de Sistemas deComputação.

Orientador: Prof. Dr. Luiz Fernando Bittencourt

Este exemplar corresponde à versão final daDissertação defendida por Márcio MoraesLopes e orientada pelo Prof. Dr. LuizFernando Bittencourt.

CAMPINAS2017

Agência(s) de fomento e nº(s) de processo(s): CAPES, 1522210

Ficha catalográficaUniversidade Estadual de Campinas

Biblioteca do Instituto de Matemática, Estatística e Computação CientíficaAna Regina Machado - CRB 8/5467

Lopes, Márcio Moraes, 1983- L881a LopArquitetura e mecanismos para migração de máquinas virtuais na

computação em névoa / Márcio Moraes Lopes. – Campinas, SP : [s.n.], 2017.

LopOrientador: Luiz Fernando Bittencourt. LopDissertação (mestrado) – Universidade Estadual de Campinas, Instituto de

Computação.

Lop1. Computação em nuvem. 2. Máquinas virtuais. 3. Algoritmos. 4.

Qualidade de serviço (Redes de computadores). 5. Dispositivos móveis. I.Bittencourt, Luiz Fernando,1981-. II. Universidade Estadual de Campinas.Instituto de Computação. III. Título.

Informações para Biblioteca Digital

Título em outro idioma: Architecture and mechanisms for virtual machine migration in fogcomputingPalavras-chave em inglês:Cloud computingVirtual machinesAlgorithmsQuality of service (Computer networks)Mobile devicesÁrea de concentração: Ciência da ComputaçãoTitulação: Mestre em Ciência da ComputaçãoBanca examinadora:Luiz Fernando Bittencourt [Orientador]Eduardo Coelho CerqueiraEdmundo Roberto Mauro MadeiraData de defesa: 12-07-2017Programa de Pós-Graduação: Ciência da Computação

Powered by TCPDF (www.tcpdf.org)

Universidade Estadual de CampinasInstituto de Computação

INSTITUTO DECOMPUTAÇÃO


Arquitetura e Mecanismos para Migração de Máquinas Virtuaisna Computação em Névoa

Banca Examinadora:

• Prof. Dr. Luiz Fernando BittencourtUniversidade Estadual de Campinas

• Prof. Dr. Eduardo Coelho CerqueiraUniversidade Federal do Pará

• Prof. Dr. Edmundo Roberto Mauro MadeiraUniversidade Estadual de Campinas

A ata da defesa com as respectivas assinaturas dos membros da banca encontra-se noprocesso de vida acadêmica do aluno.

Campinas, 12 de julho de 2017

Agradecimentos

Agradeço primeiro a Deus por esta oportunidade e peço a Ele que continue sempre fazendoo melhor para mim e para minha família, mas que acima de tudo “seja feita a Tua vontade”.

Imensamente, quero também agradecer minha esposa Jaqueline (Linda, como tão ca-rinhosamente a chamo, mesmo nos momentos de estresse) e minhas tão amadas filhas AnaJúlia e Marcela por terem me dado o suporte emocional necessário nos momentos difíceise por terem suportado minha ausência durante esta jornada. Muito obrigado. Tudo quefaço é pensando no bem estar de vocês. “Se amar é viver, vivo porque amo vocês”!

Aos meus pais Leonísio e Sheila, pelos princípios éticos transferidos mim e pelo in-centivo de continuar o aperfeiçoamento nos meus estudos. Muito obrigado também peloamor e suporte dado à minha família quando estive ausente. Aos meus irmãos Luciane eCésar (carinhosamente chamados de Tia Lu e Tucésá) pelo amor e doação a mim e minhafamília. Amo vocês S2.

Aos meus pais de coração (sogro e sogra) Adão e Dirce, ao meu cunhado Frederico esua esposa Renata, à minha cunhada Valquíria e seu noivo Fábio e às minhas sobrinhasLuanna, Talyta, Yasmin, Bianka e Milena, um super obrigado e um super abraço do Tio.

Ao meu orientador, Luiz Fernando, meu especial agradecimento pela confiança emmim depositada, pelos ensinamentos, paciência e excelente suporte intelectual sempreque necessitei. Também gostaria de agradecê-lo pelo esforço no meu processo de ida oCanadá para executar parte desta pesquisa, pois certamente foi um fator decisivo para aaceitação no intercâmbio.

À professora Miriam Capretz, por ter supervisionado meus trabalhos na Western Uni-versity e pelo suporte que recebi da universidade e do laboratório. Aos novos amigos quefiz no Laboratório deixo também meu obrigado e abraço. Em especial ao meu amigo Wil-son, primeiro pelas valiosíssimas contribuições a este trabalho e segundo, pela excelenteconvivência com juntamente com sua esposa Ana.

Agradeço também a minha locatária Laurie, que tornou-se minha amiga, pela suapaciência, atenção e carinho enquanto estive hospedado em seu lar.

Ao Governo canadense pelo financiamento através do programa ELAP.Aos novos amigos que fiz em Campinas dentro e fora do IC, meu especial abraço.Aos colegas do LRC pela amizade e descontração nos momentos de tensão que a

pesquisa acadêmica gera.Agradeço também à UFG pela liberação para minha qualificação. E também agradeço

aos colegas professores do BCC em Jataí pelo incentivo e apoio.À CAPES pelo suporte financeiro.Por fim, obrigado todo mundo!

Resumo

Nos últimos anos, novas demandas, paradigmas e conceitos surgiram para o oferecimentode recursos computacionais aos usuários finais. Dentre eles, a mobilidade de serviços eaplicações disparou um gatilho para o desenvolvimento da Fog Computing juntamente coma Internet das Coisas. Essa mobilidade pode ser suportada pela migração de máquinasvirtuais entre servidores que estejam próximos ao usuário, uma vez que as aplicaçõespara estes usuários devem estar disponíveis onde eles estiverem, mantendo assim umserviço que ofereça baixa latência para aplicações. No entanto, o processo de migraçãonão é trivial e envolve algoritmos, comunicação de dados, políticas e estratégias eficientespara minimizar o tempo que os usuários percebem uma degradação da qualidade deserviço da aplicação. Neste trabalho propomos uma arquitetura e algoritmos de migraçãode máquinas virtuais em Fog Computing com o foco na qualidade de experiência dousuário durante sua mobilidade. A arquitetura e os algoritmos são baseados em políticase estratégias que aproveitam o tempo de handoff da rede para minimizar o tempo deparada da aplicação durante uma migração. Através de simulações, os resultados dostestes mostram que após a migração das máquinas virtuais a qualidade de experiênciados usuários foi mantida ou melhorada. Os testes mostram ainda que há políticas eestratégias melhores para atender os requisitos desses serviços.

Abstract

In the last years, new demands, paradigms, and concepts became available to offer compu-tational resources to end users. Among them, service and applications mobility triggeredthe development of Fog Computing and Internet of Things. This mobility can be sup-ported through migration of virtual machines between servers that are close to the user,since their applications should be available wherever they are for offering low latencyservice to these applications. However, the migration process is not straightforward andinvolves algorithms, data communication, and efficient strategies to avoid quality of ser-vice degradation. In this research, we propose a virtual machine migration architectureand algorithms in fog computing focused in the user’s quality of experience during theirmobility. The architecture and algorithms are based on policies and strategies that uti-lizes the network handoff time to minimize the application’s downtime in the migration.Simulations show that after the virtual machine migration the user’s quality of experiencehas been maintained or improved. The results show that some policies and strategies arebetter than others to meet the requirement of these services.

Lista de Figuras

2.1 Hierárquica dos tipos de serviços oferecidos pela nuvem . . . . . . . . . . . 162.2 Arquitetura hierárquica entre Cloud e Fog Computing. . . . . . . . . . . . 182.3 Arquitetura de Fog Computing com Cloudlets. . . . . . . . . . . . . . . . . 192.4 Conceito de virtualização de servidores . . . . . . . . . . . . . . . . . . . . 212.5 Migração de máquina virtual de Cloudlet em Cloudlet. . . . . . . . . . . . 22

4.1 Núcleo da arquitetura do MyiFogSim . . . . . . . . . . . . . . . . . . . . . 30

5.1 Arquitetura topológica para migração de máquinas virtuais . . . . . . . . . 335.2 Arquitetura em camadas para migração de máquinas virtuais . . . . . . . . 345.3 Fluxograma simplificado da arquitetura de migração em Fog Computing . . 365.4 Fluxograma detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.5 Cenário normal para uma migração de máquinas virtuais em Fog Computing 405.6 O pior cenário para migração de máquinas virtuais em Fog Computing . . 425.7 O melhor cenário para migração de máquinas virtuais em Fog Computing . 435.8 Cenário com problemas de rede . . . . . . . . . . . . . . . . . . . . . . . . 445.9 APs, usuários e migração de acordo com a direção do deslocamento. . . . . 455.10 Exemplo de um ponto de migração estático. . . . . . . . . . . . . . . . . . 465.11 Exemplo de um ponto de migração dinâmico. . . . . . . . . . . . . . . . . 465.12 Padrão de projeto strategy para MigrationDecision . . . . . . . . . . . . . 475.13 Possíveis escolhas das estratégias de migração. . . . . . . . . . . . . . . . . 485.14 Padrão de projeto strategy para beforeMigration . . . . . . . . . . . . . . . 49

6.1 Aplicação utilizada na simulação. Adaptado de [15] . . . . . . . . . . . . . 536.2 Comparação das latências entre as capacidades de redes quando o usuário

não migra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.3 Comparação das latências para uma rede lenta entre não migrar e migrar . 556.4 Comparação das latências para uma rede média entre não migrar e migrar 556.5 Comparação das latências para uma rede rápida entre não migrar e migrar 566.6 Comparação das latências para uma rede lenta entre não migrar e migrar

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

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

com e todas as estratégias . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.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. . . . . . . . . . . . . 586.10 Comparação dos tempos de downtime e tempo de migração entre as políti-

cas e estratégias de migração em uma rede lenta com cinco usuários (pontoestático). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.11 Comparação dos tempos de downtime e tempo de migração entre as políti-cas e estratégias de migração em uma rede lenta com cinco usuários (pontodinâmico). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.12 Comparação dos tempos de downtime e tempo de migração entre as po-líticas e estratégias de migração em uma rede média com cinco usuários(ponto estático) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.13 Comparação dos tempos de downtime e tempo de migração entre as po-líticas e estratégias de migração em uma rede média com cinco usuários(ponto dinâmico). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.14 Comparação dos tempos de downtime e tempo de migração entre as po-líticas e estratégias de migração em uma rede rápida com cinco usuários(ponto estático) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.15 Comparação dos tempos de downtime e tempo de migração entre as po-líticas e estratégias de migração em uma rede rápida com cinco usuários(ponto dinâmico). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.16 Comparação entre todos os tempos de downtime para 5 usuários . . . . . . 646.17 Média das latências de todos os usuários em uma rede lenta. . . . . . . . . 656.18 Média das latências de todos os usuários em uma rede média. . . . . . . . 666.19 Média das latências de todos os usuários em uma rede rápida. . . . . . . . 666.20 Comparação entre todos os tempos de downtime para 10 usuários . . . . . 676.21 Média das latências de todos os usuários em uma rede lenta para dez usuários. 686.22 Média das latências de todos os usuários em uma rede média para dez

usuários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.23 Média das latências de todos os usuários em uma rede rápida para dez

usuários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.24 Comparação entre todos os tempos de downtime para 15 usuários . . . . . 706.25 Comparação entre todos os tempos de downtime de todos os cenários com

a rede lenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.26 Comparação entre todos os tempos de downtime de todos os cenários com

a rede média . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.27 Comparação entre todos os tempos de downtime de todos os cenários com

a rede rápida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.28 Latências para um usuário que não realizou handoff e nem migração. . . . 736.29 Comparação das latências para um usuário em uma rede lenta, com ponto

de migração estático e migração tradicional. . . . . . . . . . . . . . . . . . 746.30 Latências para um usuário em todas as redes e estratégias em um ponto de

migração estático escolhendo a mesma Cloudlet de destino. . . . . . . . . . 756.31 Latências para um usuário em todas as redes e estratégias em um ponto de

migração estático escolhendo Cloudlets de destino diferentes. . . . . . . . . 75

Lista de Tabelas

2.1 Comparação das características entre Cloud Computing e Edge Computing 172.2 Comparação das características dos paradigmas edge . . . . . . . . . . . . 20

3.1 Comparação dos principais trabalhos relacionados . . . . . . . . . . . . . . 27

5.1 Componentes implementados da arquitetura . . . . . . . . . . . . . . . . . 35

6.1 Resumo sobre as políticas de migração. . . . . . . . . . . . . . . . . . . . . 77

Sumário

1 Introdução 12

2 Conceitos Básicos 152.1 Cloud vs Fog Computing (Edge Computing) . . . . . . . . . . . . . . . . . 152.2 Virtualização e migração de máquinas virtuais . . . . . . . . . . . . . . . . 20

3 Trabalhos Relacionados 23

4 MyiFogSim 284.1 Visão geral sobre CloudSim e iFogSim . . . . . . . . . . . . . . . . . . . . 28

4.1.1 Cloud Computing Simulator . . . . . . . . . . . . . . . . . . . . . . 284.1.2 Fog Computing Simulator . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Arquitetura do MyiFogSim . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Migração de máquinas virtuais em Fog Computing 325.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1.1 Arquitetura topológica . . . . . . . . . . . . . . . . . . . . . . . . . 325.1.2 Arquitetura em camadas . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2 Algoritmo base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2.1 Fluxogramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Cenários com migração e handoff . . . . . . . . . . . . . . . . . . . . . . . 405.3.1 Comentários gerais e outros cenários . . . . . . . . . . . . . . . . . 41

5.4 Técnica de migração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.4.1 Políticas de migração . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4.2 Estratégias de migração . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Simulações 516.1 Etapa 1: Diferença entre não migrar e migrar uma máquina virtual . . . . 536.2 Etapa 2: Comparação entre as políticas e estratégias de migração . . . . . 58

6.2.1 Sub-etapa 2.1: Ambiente com 5 usuários . . . . . . . . . . . . . . . 586.2.2 Sub-etapa 2.2: Ambiente com 10 usuários . . . . . . . . . . . . . . 676.2.3 Sub-etapa 2.3: Ambiente com 15 usuários . . . . . . . . . . . . . . 70

6.3 Latências após as migrações . . . . . . . . . . . . . . . . . . . . . . . . . . 726.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7 Considerações finais 797.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Referências Bibliográficas 81

Capítulo 1

Introdução

Os seres humanos têm cada vez mais se tornado dependentes dos serviços que a Internetoferece. Tais serviços vão desde simples pesquisas cotidianas feitas por algum dispositivode usuário (por exemplo smartphone) até o envio maciço de dados para processamento emgrandes data centers para serem executados em milhares de servidores. Esta dependênciafaz com que pesquisadores no mundo inteiro produzam conhecimento para melhorar astécnicas de acesso, armazenamento, busca, otimização e fluxo na transmissão dos dados.

Um modelo eficiente que tem sido bastante pesquisado para prover armazenamento,gerenciamento privado em data centers e processamento de aplicações pela Internet é oconceito de Cloud Computing (Computação em Nuvem) [8]. Este modelo pode ser descritocomo um serviço prestado por grandes data centers que oferecem parte de sua infraes-trutura, tanto de hardware como de software para terceiros (corporações e/ou pessoasfísicas). Uma vez que estes clientes aderem a este tipo de serviço, elas passam a ter recur-sos computacionais com capacidade computacional crescente sem que haja a necessidadede grandes investimentos de capital financeiro para a aquisição, manutenção e gestão detais recursos [5].

Complementar a este conceito, Fog Computing (Computação em Névoa) é um para-digma que estende os serviços de acesso à rede formada por uma Cloud Computing [9][24]. Fog Computing tem como principais características a baixa latência, uma maiordistribuição geográfica dos dados, mobilidade, grande número de nós na rede, acesso pre-dominantemente wireless, execução de aplicações em tempo real e heterogeneidade dosdispositivos [9].

Apesar de Cloud Computing e Fog Computing oferecerem serviços similares, existemdiferenças ao se considerar o contexto de névoa. Dentre estas diferenças, destaca-se que anévoa está mais próxima aos usuários finais (assim como uma neblina), está densamentedistribuída geograficamente e ainda suporta mobilidade de seus dispositivos [24]. Por essarazão, algumas aplicações/serviços, que não teriam um bom resultado quando executadospela nuvem (alta latência no tempo de resposta de aplicações), podem ter um comporta-mento mais adequado no fornecimento de dados e informações nas respostas geradas dasrequisições de usuários e sistemas finais. Neste sentido, pode-se dizer que Fog Computingatende melhor aos requisitos de aplicações de tempo real que são sensíveis a latência. Poroutro lado, o processamento de grandes massas de dados de sistemas complexos que nãonecessitam de uma resposta em tempo real tem a Cloud Computing como um paradigma

12

CAPÍTULO 1. INTRODUÇÃO 13

mais apropriado para realizar este tipo de tarefa.Uma das razões para o surgimento e implementação da Fog Computing foi a neces-

sidade de criação de uma plataforma que suportasse o recente paradigma herdado dacomputação ubíqua1, que é a Internet of Things (IoT – Internet das Coisas) [1], ondequaisquer objetos (coisas) podem atuar como nós sensores e/ou que possuam algum tipode processamento oferecendo algum tipo de serviço [1]. Nessa direção, os autores de [22]apresentam o conceito de Cloudlet como parte integrante de uma arquitetura hierárquicaem três camadas, a saber: i) Dispositivos móveis, ii) Cloudlet e iii) Nuvem, onde asCloudlets são formadas por um ou vários computadores que disponibilizam recursos aosdispositivos de usuários geograficamente próximos.

Normalmente os dispositivos móveis dos usuários não têm grande capacidade de com-putação e/ou armazenamento e contêm limitações de bateria. Para contornar essa si-tuação, o uso de máquinas virtuais (do inglês Virtual Machine - VM) na nuvem é umaalternativa para as aplicações que demandam mais recursos de hardware. Neste sentido, autilização de máquinas virtuais no contexto de Fog Computing também pode ser exploradocom o objetivo de fornecer aos usuários um mecanismo capaz de oferecer a infraestruturanecessária para a execução de aplicações com o processamento em tempo real e baixalatência.

As máquinas virtuais em nuvem também são usadas para evitar desperdício de recursosde hardware neste tipo de infraestrutura, no entanto, muitas vezes os recursos de algunsservidores (ou todos) em uma determinada nuvem pode chegar ao limite e com isso surgea necessidade de migração para outros servidores (na mesma nuvem ou em outra) sem quehaja perda de serviço ou de operabilidade de aplicações que estavam em execução de umadeterminada máquina virtual [5]. Do ponto de vista de um ambiente de Fog Computing,onde há maior mobilidade dos usuários, a migração de máquinas virtuais é necessária,pois os dados desses usuários devem acompanhá-los durante sua locomoção para que alatência seja mantida em níveis aceitáveis para determinadas aplicações.

A distância geográfica entre diferentes hospedeiros pode ser um complicador para amigração de máquinas virtuais, uma vez que o tempo em que uma aplicação fica sem acessoà sua máquina virtual (downtime) será mais longo, quando comparado, por exemplo, commigrações entre servidores de um mesmo data center.

Pensando nesse contexto, onde Fog Computing mantém Cloudlets geograficamentedistantes, um usuário móvel pode ter dentro da névoa uma ou mais máquinas virtuaspara “segui-lo” de Cloudlet-em-Cloudlet, através de migrações, durante o seu caminho emelhorar sua qualidade de experiência (Quality of Experience - QoE) atendendo assim,aos requisitos de baixa latência e execução em tempo real, uma vez as máquinas virtuaisdeverão estar a um salto (de rede) de distância do dispositivo do usuário. Em resumo,pergunta-se: Como estabelecer um algoritmo que seja capaz de adaptar, de forma es-calável, uma infraestrutura de Fog Computing a um contexto de migração de máquinasvirtuais para usuários móveis? Quais requisitos de QoS estabelecer para aplicações que

1Computação ubíqua: O termo Computação Ubíqua, foi definido pela primeira vez pelo cientista-chefedo Centro de Pesquisa Xerox PARC, Sr. Mark Weiser, através de seu artigo “O Computador do Século21” (The Computer for the 21st Century). Fonte: http://www.hardware.com.br/artigos/computacao-ubiqua/ Acessado em mai/2017.

CAPÍTULO 1. INTRODUÇÃO 14

necessitam de baixa latência? Quais dados migrar? A hipótese é que um algoritmo demigração ao vivo de máquinas virtuais em Fog Computing melhora o atendimento dequalidade de experiência do usuário de aplicações com requisitos de baixa latência e deexecução em tempo real.

Esta pesquisa traz três principais contribuições:

1. Uma arquitetura de migração de máquinas virtuais em Fog Computingque atenda às necessidades de usuários móveis: os módulos propostos naarquitetura são capazes de atender aos requisitos de aplicações que necessitam deQoS, de controle remoto dos dados, de baixa latência e de sincronismo para a trocade dados entre os usuários, a névoa e a nuvem em um ambiente de respostas detempo real.

2. Algoritmos de migração de máquinas virtuais que atuam em um ou maismódulos da arquitetura: são usados para a tomada de decisão de quando epara onde uma máquina virtual deve migrar. Estes algoritmos assumem que há nosistema de Fog Computing mecanismos para receber os dados que serão migrados eassim fazer a migração.

3. Um simulador para validar a arquitetura e os algoritmos criados: implantaalguns componentes da arquitetura projetada, bem como executa os algoritmos etestes do sistema de migração proposto. Este simulador é baseado em CloudSim[10] e também em iFogSim [15].

Após a criação da arquitetura e algoritmos, os testes foram realizados em duas prin-cipais etapas:

• Comparação entre não migrar e migrar uma máquina virtual.

• Comparação entre as técnicas de migração.

Esta dissertação está dividida como segue: no Capítulo 1 é apresentada uma introdu-ção para motivar o trabalho e mostrar os aspectos de uma pesquisa, como: i) PerguntasProblema, ii)Hipóteses, iii) Contribuições. O Capítulo 2 traz os conceitos básicos doselementos desta pesquisa. O Capítulo 3 apresenta os trabalhos da literatura que estãorelacionados e alinhados com esta pesquisa. O simulador é descrito no Capítulo 4. OCapítulo 5 descreve em detalhes a arquitetura e os algoritmos propostos. O Capítulo6 descreve o ambiente dos testes e simulações e por fim, no Capitulo 7 são feitas asconsiderações finais ao trabalho.

Capítulo 2

Conceitos Básicos

Este capítulo tem como objetivo apresentar os conceitos básicos que serão discutidosdurante esta dissertação. Esses conceitos são: Cloud Computing, Fog Computing, Clou-dlets, Edge Computing, Mobile Edge Computing, Mobile Cloud Computing, virtualizaçãoe migração de máquinas virtuais.

2.1 Cloud vs Fog Computing (Edge Computing)

Ao longo da última década, Cloud Computing foi um dos paradigmas que tem ganhadodestaque tanto no mundo empresarial quanto no meio acadêmico. Este conceito é capazde suportar o crescente processamento de dados que a Internet gerou todos esse anos,principalmente após o acesso à rede ter sido facilitado em todo o mundo. No mundoempresarial, grandes corporações que mantém data centers, com uma grande fazenda deservidores, oferecem seus serviços para outras empresas utilizarem como parte de suasinfraestruturas em um modelo pay-per-use (pague pelo uso), onde o cliente paga pelo queusou dentro da nuvem, obtendo assim flexibilidade e elasticidade no uso dos recursos. Poroutro lado, no mundo acadêmico, muitas pesquisas são apresentadas anualmente com oobjetivo de otimizar plataformas, conceitos, serviços, acesso, consumo de energia, alocaçãode recurso etc.

Cloud Computing é um paradigma da computação distribuída que tem alcançado umaadoção em larga escala. Ela provê capacidade de armazenamento e processamento sobredemanda pela alta capacidade dos data centers e acesso através da Internet, onde estasconfigurações habilitam os usuários a acessar quaisquer tipos de dados e/ou quaisqueraplicações disponíveis na Internet.[4]

Muitos podem ser os serviços que uma nuvem oferece. Estes serviços são basados emalgum tipo de nível ou hierarquia no formato XaaS (Anything as a Service - Qualquercoisa como um Serviço). Os três principais tipos são:

1. IaaS - Infrastructure as a Service (Infraestrutura como um Serviço)

• Oferecimento de infraestrutura computacional como serviço para clientes doprovedor, tais como: i) Servidores, ii) Armazenamento e iii) Rede.

2. PaaS - Platform as a Service (Plataforma como um Serviço)

15

CAPÍTULO 2. CONCEITOS BÁSICOS 16

• O serviço oferecido é um nível intermediário para proporcionar capacidade dedesenvolvimento de aplicações sem que os administradores de sistemas tenhamque se preocupar com camadas mais abaixo, com por exemplo infraestrutura esistemas gerenciadores de banco de dados.

3. SaaS - Software as a Service (Software como um Serviço)

• Está no nível mais alto dos serviços oferecidos pela nuvem, onde os usuáriosnão necessitam configurar suas aplicações para o uso. Normalmente, este tipode serviço pode ser contratado por usuários comuns, sem a necessidade depertencerem a alguma organização.

A Figura 2.1 mostra o modelo dos principais tipos de serviços oferecidos pela CloudComputing. Na parte mais abaixo está o IaaS, onde é possível perceber que os principaisatores são os administradores de redes. No nível intermediário, PaaS, os atores são osdesenvolvedores de aplicações. No mais alto nível está o SaaS e os principais atores sãoos usuários finais.

Figura 2.1: Hierárquica dos tipos de serviços oferecidos pela nuvem

Lopez et al. [14] apresentam Edge-centric Computing “como um paradigma inovadorque colocará a computação de aplicações, de dados e de serviços longe dos nós centraliza-dos para a periferia da rede”. Os autores elencam características semelhantes a da névoae, com esse princípio, Ismail et al. [17] fundamentam que os dados que seriam executa-dos de forma centralizada dentro de uma nuvem podem passar a ser processados em umparadigma descentralizado chamado de Edge Computing, que basicamente consiste emtrazer os dados para processamento para borda da rede. Neste sentido, nota-se que FogComputing é uma instância de Edge Computing.

Os autores de [17] fazem ainda algumas comparações entre o paradigma de CloudComputing e Edge Computing que é apresentada na Tabela 2.1, onde é possível observarque cada um dos conceitos tem a maioria dos aspectos diferente entre eles.


Tabela 2.1: Comparação das características entre Cloud Computing e Edge Computing.Adaptado de [17]

Requisitos Cloud Computing Edge ComputingLatênica Alta Baixa

Atraso Jitter Alto Muito baixoLocalização do Serviço Dentro da Internet Na borda

Distância entre Clientes e servidores Múltiplos saltos Um saltoOnisciência na Localização Não Sim

Geo-distribuição Centralizada DistribuídaSuporte a mobilidade Limitado Suportado

Interação em tempo real Suportado Suportado

Bonomi et al. [9] propuseram o conceito de Fog Computing como uma extensão doparadigma de Cloud Computing na borda da rede, permitindo assim uma nova geraçãode aplicações e serviços. Em resumo, os autores descrevem um conjunto de característicasque uma nuvem próxima aos usuários deve ter. Estas características estão enumeradas aseguir:

1. Localização na borda da rede

2. Geograficamente distribuído

3. Sensores de rede em larga escala

4. Grande número de nós

5. Suporte à mobilidade

6. Interações em tempo real

7. Predominantemente wireless

8. Heterogeneidade

9. Interoperabilidade

10. Suporte de análise e troca de dados com a nuvem

Os autores de [9] definem ainda Fog Computing como:

“uma plataforma altamente virtualizada que tipicamente provê serviços decomputação, armazenamento e rede entre os dispositivos e a tradicional CloudComputing em data centers, mas não exclusivamente localizada na borda darede.”

Dadas essas características, muitas pesquisas começaram a ser desenvolvidas com FogComputing. Essas pesquisas herdam, sobre tudo, muitos paradigmas aplicados à nuvense adaptados para a névoa, como por exemplo a virtualização de servidores e a migraçãode máquinas virtuais, que são uma das contribuições desta dissertação e são discutidas na


Seção 2.2. A Figura 2.2 ilustra a relação entre a nuvem e a névoa. A nuvem está no topode uma infraestrutura hierárquica, de forma centralizada, onde são disponibilizados di-versos recursos como processamento de alto desempenho e armazenamento. A névoa, porsua vez, está distribuída e oferece serviços que usualmente demandam menor capacidadecomputacional e menor tempo de resposta.

Figura 2.2: Arquitetura hierárquica entre Cloud e Fog Computing.

É possível observar, na parte inferior dessa hierarquia, que as névoas estão direta-mente ligadas via wireless em alguns objetos móveis (notebook, smartphone, automóveis)e também fixos (semáforos). Esses objetos ilustram e exemplificam alguns cenários e con-textos de como o conceito de Fog Computing atua oferecendo serviços de computação aosdispositivos de IoT, que muitas vezes são heterogêneos.

Verbelen et al. [28] consideram que todos os dispositivos de uma LAN (Local AreaNetwork - Rede Local) podem cooperar com a Cloudlet e o autor de [23] afirma que asCloudlets atuam com uma camada intermediária entre a nuvem e os dispositivos móveiscom o objetivo de trazer os serviços mais próximo aos usuários. Com isso, nota-se que FogComputing e Cloudlet tem contextos muito semelhantes e para simplificar, esta pesquisaconsiderará que um conjunto de Cloudlets formam uma única névoa e também que estãono mesmo nível hierárquico.

A Figura 2.3 mostra um conjunto de Cloudlets formando uma Fog Computing. AsCloudlets são as responsáveis diretas pelos serviços oferecidos aos dispositivos de IoT.Elas são conectadas entre si para que possam trocar vários tipos de informações, comopor exemplo estado da rede, carga de processamento computacional, mecanismos para amigração de máquinas virtuais etc.


Figura 2.3: Arquitetura de Fog Computing com Cloudlets.

Importante ressaltar que cada névoa tem seu conjunto de Cloudlets e cada um dessesconjuntos é responsável por algum tipo de serviço oferecido aos usuários finais. As Figuras2.2 e 2.3 ilustram diferentes serviços para usuários finais. Na Figura 2.2 os dispositivos sóinteragem com suas respectivas névoas. Na Figura 2.3 todos os dispositivos integrantes danévoa interagem com uma ou mais Cloudlets e por isso as aplicações de usuários devemser disponibilizadas em todas elas. No entanto, esta disponibilização não precisa sernecessariamente simultânea, ou seja, os serviços de usuário podem estar ativos somentena Cloudlet a qual este usuário está diretamente conectado, uma vez que disponibilizare sincronizar todos os dados de todos os usuários em todas as Cloudlets geraria um altocusto computacional e financeiro.

Por conta da mobilidade observada na Figura 2.3 e pela impraticabilidade de replicaçãoe sincronização de todos os dados, a migração de máquinas virtuais é uma importantetécnica para ser empregada no oferecimento de serviços por uma Fog Computing.

Conceitos semelhantes a Fog Computing e Cloudlet também são encontradas na litera-tura, como por exemplo Mobile Edge Computing (MEC) [6] [3] e Mobile Cloud Computing(MCC) [12]. Estes conceitos também são uma abstração de Edge Computing.

Como recentemente os dispositivos móveis passaram a rodar diversos tipos de apli-cações (m-health-care, m-learning, m-gaming, m-governance etc) e considerando suas li-mitações de hardware, quando comparado com computadores pessoais (desktops), para[3] MEC oferece os serviços essenciais de uma nuvem na borda da rede. Ou seja, MECconsidera somente os dispositivos móveis fazendo o uso da Edge Computing. No mesmosentido, [12] em 2009 introduz MCC como um paradigma que move o poder de processa-mento e armazenamento dos dispositivos móveis dos usuários e entrega para uma nuvemcentralizada (não para a borda) executar tais tarefas. Porém, segundo [21], mais tardeoutros pesquisadores expandiram o escopo de MCC e em sua nova visão as tarefas execu-tadas na nuvem também são delegadas para borda da rede. [21] enfatizam que ambas asvisões co-existem atualmente, porém eles focam sua pesquisa na visão mais atual.

Desta forma, Roman et al. [21] trazem uma visão geral sobre Fog Computing, MECe MCC chamando-os de emergentes paradigmas edge. Os autores fazem ainda uma com-paração entre eles com o objetivo de, holisticamente, analisar as ameaças em segurança,os desafios e os mecanismos inerentes a todos eles. A Tabela 2.2 mostra um resumo do


estudo apresentado pelos autores onde é possível verificar as diferenças e semelhançasentres estes conceitos, incluindo Cloud Computing.

Tabela 2.2: Comparação das características dos paradigmas edge. Adaptado de [21]

MEC Névoa MCC Nuvem

Propriedade Telecoms Empresas privadas, individuais EmpresasPrivadas

Desenvolvimento Borda da Rede Próximo à borda, borda Borda da rede, dispositivos Núcleo da redeHardware Servidores heterogêneos Servidores, dispositivos de usuários ServidoresServiço Virtualização Virtualização, outros Virtualização

Arq. da rede N-camadas, descentralizado, distribuído CentralizadoMobilidade Sim Não

Latência, Jitter Baixa MédiaOnisciência Sim Não

Disponibilidade AltaEscalabilidade Alta Média

Na primeira coluna observa-se as características estudadas e na primeira linha osparadigmas analisados. Muitas destas características já foram discutidas em sessões an-teriores. Nota-se que todos estes conceitos não são exatamente iguais, mas apresentamdiversas similaridades.

2.2 Virtualização e migração de máquinas virtuais

Em 1960 a IBM Corporation desenvolveu uma tecnologia de virtualização de recursoscomputacionais com o objetivo de otimizar a utilização do hardware físico em mainframes.O processo de virtualização consiste em criar uma camada software intermediária chamadade Hypervisor entre o hardware físico e serviço virtualizado com o objetivo de controlara execução, por exemplo, de vários sistemas operacionais simultaneamente em uma únicamáquina física. Ou seja, a virtualização de recursos computacionais cria a possibilidade deisolamento da carga de trabalho para que diferentes aplicações compartilharem os mesmosrecursos de hardware sem que haja interferência direta entre elas.

A Figura 2.4 mostra a diferença entre um servidor não virtualizado e outro virtuali-zado. É possível observar que o servidor não virtualizado suporta somente um sistemaoperacional que controla o hardware diretamente. No modelo virtualizado existe a camadade virtualização (Hypervisor) que separa o hardware físico de vários sistemas operacionaisem execução simultaneamente. Os sistemas operacionais enviam/recebem os comandospara/do Hypervisor que por sua vez controla a máquina física diretamente.


Figura 2.4: Conceito de virtualização de servidores

Do ponto de vista de um sistema operacional sobre um Hypervisor ele controla ohardware virtualizado da mesma forma que faria se fosse uma máquina física real. Estehardware virtualizado é conhecido como máquina virtual. Um sistema de virtualizaçãodentro de data centers deve ser bem gerenciado para que os recursos da infraestruturacomputacional sejam bem utilizados. A migração de máquinas virtuais entre servidoresé uma das técnicas para prover uma boa utilização de recursos e consiste no processo decopiar de uma máquina virtual de um servidor físico para outro. Neste sentido, Voorsluyset al. [29] argumentam que uma máquina virtual pode ser usada para um melhor controlede dados, e que ao usar as técnicas de migração para outra localização (hardware) há apossibilidade de oferecer um serviço que melhora a capacidade de gerenciamento, desem-penho e aspectos de tolerância a falhas, garantindo assim flexibilidade, adaptabilidade eeficiência para as aplicações dos clientes.

Segundo Clark et al. [11] processos de migração de máquinas virtuais que disponibili-zam serviços ao vivo necessitam considerar dois aspectos importantes: i) o downtime damáquina virtual e ii) o tempo total de migração. O downtime é o tempo em que uma má-quina virtual fica inacessível durante o processo de migração. O balanceamento entre estesdois tempos também é importante para manter os recursos utilizados e disponibilizadosequilibrados por um provedor.

Muitas podem ser as técnicas de migração de máquinas virtuais. As principais são:

• Parada e cópia: É a tradicional técnica de migração de máquinas virtuais. Deforma simples, uma máquina virtual é desligada do servidor de origem, a sua imagemtransferida e ligada novamente em outro servidor. De acordo com [11] esta técnicatem como vantagem sua simplicidade, porém pode gerar tempos indesejáveis dedowntime e de migração.

• Migração sob demanda: É considerada como uma parada e cópia curta, poissomente os dados essenciais serão migrados pela rede e, portanto o tempo de down-time e migração serão menores, porém um custo computacional extra é adicionadopara a separação dos dados. Esses dados essenciais são conhecidos por containersde máquinas virtuais.

• Migração ao vivo: É uma técnica em que durante o processo de migração a má-quina virtual permanece em execução, continua ofertando serviços e contém três


fases: i) Fase de envio (push phase), ii) Fase de parada e cópia e iii) Fase de rece-bimento (pull phase) (não necessariamente nesta ordem). Em algum momento, otempo de downtime existirá, porém segundo [11], este tempo será muito menor secomparado com o tempo de parada de serviços da técnica tradicional simples. Hátrês principais abordagens de migração ao vivo, a saber:

– Pré-cópia

– Pós-cópia

– Híbrida

A migração de máquinas virtuais na névoa segue um princípio semelhante ao da mi-gração na nuvem. Na névoa, pelo fato dos usuários finais terem dispositivos móveis,uma máquina virtual responsável pela disponibilização de recursos a estes usuários deve“segui-los” por onde forem. Em outras palavras, como a névoa é densamente distribuídae cada Cloudlet está centralizada, uma máquina virtual deve ficar disponível em outraCloudlet sempre que o usuário mudar sua região geográfica e, consequentemente, mudarde cobertura. A Figura 2.5 ilustra este cenário.

Figura 2.5: Migração de máquina virtual de Cloudlet em Cloudlet.

Capítulo 3

Trabalhos Relacionados

Muitas pesquisas têm sido realizadas em torno de Fog Computing e IoT, principalmente apartir de 2012, onde pode-se destacar um grande número de publicações de 2014 até hoje.Muitas outras publicações podem ser encontradas em relação à migração de máquinasvirtuais em Cloud Computing com diferentes contextos. Nesta seção serão apresentadosalguns trabalhos para posicionar esta pesquisa em relação aos trabalhos presentes naliteratura.

Em [9] são mostradas em detalhes as principais características de Fog Computing, asquais já foram listadas anteriormente. Mostra-se ainda uma relação intrínseca entre FogComputing e IoT em três abordagens: i) Veículos conectados , ii) Grades inteligentes eiii) Redes de sensores em fio e atuadores. Como principal contribuição os autores trazemuma arquitetura de interação entre névoa e nuvem. Destaca-se que este artigo é um dosprimeiros textos de referência para o início das pesquisas em Fog Computing.

Stojmenovic e Wen [24] inciam a abordagem de questões relacionadas à segurançaem Fog Computing e também exploram cenários como as grades inteligentes, rede desensores sem fio, IoT e Software Defined Networks (SDN – Redes Definidas por Software).Outro ponto importante destacado é que enfatizam a necessidade dos usuários finais teremserviços que provejam baixa latência, a localização de conhecimento e a incorporação deQoS para aplicações de tempo real.

Em [1] é abordado um outro conceito similar à Fog Computing, chamado de Cloud ofThings (CoT), que é uma integração/interligação entre IoT e Cloud Computing. O artigoapresenta um desafio envolvendo: i) o envio de dados para a nuvem, ii) os dispositivos deIoT, iii) um método de envio chamado Smart Gateway e iv) Fog Computing. Os autoresafirmam ainda que o processamento dados não pode estar somente sob a responsabilidadedos dispositivos que integram a IoT e que esses dados devem, de alguma forma eficiente,serem enviados para a nuvem.

Yannuzzi et al. [30] tratam a Fog Computing como um promissor desafio no cenário deIoT e mostram uma pesquisa baseada em uma relação entre mobilidade, controle confiávele atuação e escalabilidade, focalizando no cenário de IoT em grandes áreas geográficas ena decisão da análise de dados em tempo real.

Em [27] os autores destacam que a névoa é considerada como uma nuvem que está des-locada para as redes de acesso e está diretamente ligada à virtualização da infraestruturade roteadores. São expostos alguns cuidados que devem ser tomados com o surgimento de

23

CAPÍTULO 3. TRABALHOS RELACIONADOS 24

novas tecnologias, pois segundo os autores, existe uma tendência em se vulgarizar essasnovas tecnologias sem que haja estudos mais elaborados sobre uma determinada temática.Com isso, uma das principais contribuições observadas é a definição sólida e ampla de FogComputing, sua situação atual e uma série de desafios futuros. Os autores de [27] definementão que:

“Fog Computing é um cenário onde um enorme número de dispositivos hete-rogêneos (sem fio e algumas vezes autônomos), ubíquos e decentralizados, secomunicam e potencialmente cooperam entre si e com a rede para executartarefas para atuar no armazenamento e processamento sem a intervenção departes terceiras. Estas tarefas podem ser para suportar funções básicas de re-des ou novos serviços e aplicações que executam em ambientes de ‘sandboxed’.Usuários alugam seus dispositivos para hospedar e receber incentivos para fazerestes serviços.”

Outro ponto a se destacar em [27] é que os autores trazem aspectos importantes quepouco foram discutidos em outros trabalhos, como o gerenciamento de redes e serviços nocontexto da névoa. Mostram ainda um neologismo semântico que é a “Softwareisation”(como tradução livre: Softwarização) da rede, que superficialmente pode ser tratado comouma forma de produzir o gerenciamento de uma rede bem como dos serviços por elaoferecidos utilizando a produção de software.

Em [16] é apresentado um modelo de programação para Mobile Fog que tem como ob-jetivo o desenvolvimento para aplicações de IoT levando em consideração sua distribuiçãogeográfica, aplicações de larga escala e aplicações que sejam sensíveis à latência. Outroponto importante, considerado na pesquisa, é o conceito de PaaS que deve ser utilizado nomodelo de programação com o objetivo de simplificar a abstração e suporte à aplicaçõesescaláveis que estejam em execução.

Ainda, os estudos em [16] fazem uma comparação com a pesquisa apresentada em[9], afirmando que trata-se de um complemento envolvendo os benefícios, em termos deeficiência, para o desenvolvimento de aplicações no modelo de programação proposto.

Em [19] os autores discutem sobre os benefícios da mobilidade de servidores virtuaissem o interrompimento de serviços usando técnicas de migração ao vivo de máquinasvirtuais. No trabalho são apresentados problemas relacionados ao custo de migraçãoconsiderando o desempenho e consumo de energia, tanto em termos teórico, como emtermos práticos. As principais contribuições desse trabalho incluem a criação de ummodelo para redução dos custos de migração das máquinas virtuais tanto para redescabeadas como para redes sem fio. Os resultados encontrados mostram que a eficiênciado modelo reduz em até 72,9% o custo de migração usando o modelo cabeado e até 73,6%o consumo de energia. É destacado que a quantidade de memória, taxa de alteração damemória na origem (memória suja) e taxa de transmissão da rede são os fatores de maiorinfluência na migração ao vivo de máquinas virtuais.

Aspectos conceituais importantes (algoritmos) devem ser bem definidos para usar téc-nicas de migração ao vivo de máquinas virtuais, tais como a pré-cópia, a pós-cópia e ohíbrido. Na pesquisa de [25] os autores destacam cinco propriedades e critérios fundamen-tais para a migração ao vivo de máquinas virtuais, a saber: i) Serviço contínuo, ii) Baixo


consumo de recursos, iii) Robustez, iv) Previsibilidade e v) Transparência. Sobre essescritérios, os autores argumentam ainda que “fornecem um meio para descrever e compararalgoritmos de migração ao vivo” através de uma avaliação de desempenho de migração emalgoritmos de pré-cópia, pós-cópia e híbrido. Após os testes e avaliações realizadas em al-guns algoritmos, os autores afirmam que o modelo pré-cópia só deve ser utilizado quandoa maior preocupação for a Robustez, caso contrário, os modelos pós-cópia e híbrido sãoaltamente recomendados.

A migração ao vivo de máquinas virtuais traz ainda um problema sobre a mobilidadede endereço IP (Internet Protocol) entre infraestrutura de redes distintas. Em [18] osautores propõem um serviço chamado HyperMIP (Hypervisor controlled Mobile IP) parasolucionar a perda de conectividade durante o processo de migração de aplicações queexecutam em tempo real. Os autores ressaltam ainda que a arquitetura do HyperMIPé baseada em IPv4 (Internet Protocol version 4) e que, para considerar IPv6 (InternetProtocol version 6) deverá ser feita uma nova abordagem, pois apesar de terem conceitose precedimentos semelhantes, esses protocolos tem uma implementação diferente.

Em [2] um dos tópicos pesquisados pelos autores é o risco à segurança durante amigração ao vivo de máquinas virtuais entre os servidores de uma nuvem. O fato damigração ao vivo fornecer flexibilidade na transferência de dados de um servidor paraoutro, ainda são necessários alguns requisitos como disponibilidade e confiabilidade. Nesseartigo os autores mencionam que existem muitas vulnerabilidades referentes ao contextode migração ao vivo de máquinas virtuais e destacam a falta de mecanismos criptográficosdurante esse processo.

Taleb et al. [26] propõem Follow Me Edge (FME) que é uma abordagem que baseia-seem um serviço que está hospedado na Cloudlet (Edge) mais próxima do usuários em umcenário para cidades inteligentes. Eles mencionam que os serviços devem sempre seguir osusuários e com isso, a proposta é focada na criação autônoma de serviços de MEC parapermitir o acesso dos usuários de qualquer lugar e qualquer momento otimizando o QoEe a redução de latência. Os autores mostram dois estudos de caso para exemplificar osrequisitos que FME pode suportar. Além disso, FME considera o uso de uma tecnologiade virtualização leve e também introduz o conceito de migração ao vivo de containerscom foco nos aspectos de mobilidade em edge. FME é validado usando um testbed davida real e os cenários de mobilidade na edge são testados usando diferentes tipos dearmazenamento, diferentes tamanhos de containers e diferentes recursos de edge.

Em [20] são pesquisados alguns aspectos de virtualização em Fog Computing queincluem questões de segurança e privacidade nos serviços e recursos disponíveis. Maisainda, uma revisão sobre migração de máquinas virtuais na névoa é feita e também éapresentado um framework conceitual para uma abordagem inteligente de pré-cópia namigração ao vivo de máquinas virtuais. Este framework faz uma adaptação do algoritmode pré-cópia de Xen. Os autores apresentam uma taxonomia para caracterizar dois tiposde aplicações em Fog Computing, a saber: i) aplicações em tempo real, ii) aplicaçõespróximas a tempo real.

Aspectos conflitantes sobre aplicações sensíveis ao atraso são expostos em [13]. Osautores mencionam que para se ter um tempo de resposta ultra curto em aplicações deusuários móveis, uma rápida realocação de recurso entre os nós de uma edge deve ser


considerada. Nestes sentido, eles elencam que uma replicação de serviços proativa é umaestratégia promissora de migração para reduzir o tempo de downtime e garantir umaQoE satisfatória. No entanto, o provisionamento de réplicas em múltiplos nós aumentao consumo de recursos e este custo torna-se um aspecto relevante a ser considerado.Com base nestes aspectos os autores propõem dois esquemas baseando em otimização deproblemas lineares inteiros para minimizar a degradação de QoE devido a migração e ocusto de implantação de réplicas nos nós da edge.

Yao et al. [31] introduzem Road Side Cloudlet (RSC) com o objetivo de resolver umproblema de baixo tempo de resposta e alto custo de comunicação do modelo VehicularCloud Computing (VCC1) apresentado em [32], pois [31] consideram que pode haver umcusto de execução muito alto usando VCC uma vez que o tráfego em uma rede de longadistância pode ser elevado. Neste sentido, os autores de [31] propõem uma heurística deduas fases para minimizar o custo de migração de máquinas virtuais entre RSCs durante amovimentação dos veículos. A fase um consiste em um algoritmo para encontrar o menorcaminho até o próximo nó sem violação da capacidade do link e a fase dois consiste emoutro algoritmo baseado no custo de alocação da máquina virtual em uma RSC a partirdo resultado da execução do algoritmos da fase um.

Com base em todo do estudo realizado para a caracterização do problema que é apre-sentado nesta dissertação, nós inicialmente propusemos uma arquitetura em alto nívelpara estabelecer os principais tópicos que devem ser considerados em um ambiente de mi-gração de máquinas virtuais. Utilizamos o tempo de handoff para minimizar o tempo emque uma máquina virtual fica indisponível. Dentro do escopo da arquitetura projetada,alguns algoritmos foram construídos para atuarem em alguns módulos propostos. Para atomada de decisão de quando uma máquina virtual deve migrar, nós utilizamos uma po-lítica que baseia-se em uma zona de migração e em um ponto de migração de acordo coma mobilidade do usuário. Durante os testes, nós levamos em consideração os três tiposprincipais de migração: migração tradicional (parada e cópia), migração de containers emigração ao vivo. Mais detalhes serão apresentados nos próximos capítulos.

A grande maioria dos trabalhos apresentados discutem conceitos, desafios e futurasdireções para novos trabalhos em Fog Computing (ou nos outros paradigmas similares),no entanto, alguns estão mais fortemente relacionados com esta pesquisa em termos deresultados. A Tabela 3.1 mostra um quadro comprativo entre estes principais trabalhosmais fortemente relacionados com esta dissertação.

1VCC é um paradigma similar a primeira visão de MCC, onde o processamento das aplicações éretirado dos veículos e enviado a uma nuvem


Tabe

la3.1:

Com

paraçãodo

sprincipa

istrab

alho

srelacion

ados

Par

adig

ma

Mob

ilid

ade

Mec

anis

mo

de

dec

isão

Téc

nic

ade

mig

raçã

oA

plica

ção

Pró

-ati

voTaleb

etal

.[26]

MEC

Sim

Latêncialim

ite

Aovivo

decontainers

Video

stream

ing

Sim

Osana

iye

etal

.[20]

Fog

Genérico

Regressão

linear

Aovivo

(pré-cóp

ia)

Em

tempo

real/p

rox.

tempo

real

Genérico

Farris

etal

.[13]

MEC

Sim

Otimização

deprob

lemas

linearesinteiros

Con

tainers

Sensível

aoatraso

Sim

Yao

etal

.[31]

RSC

Sim

Custosdo

linkealocação

Tradicion

alNão

espe

cificad

oSim

Estetrab

alho

Fog

Sim

Pon

tode

migração/zona

deMigração

Con

tainers,

trad

iciona

leao

vivo

Em

tempo

real

Sim

Capítulo 4

MyiFogSim

Este capítulo apresenta os componentes de CloudSim e iFogSim que dão a base paraa execução do simulador MyiFogSim, os detalhes de seu projeto e implementação e osdetalhes da integração com uma arquitetura para migração de máquinas virtuais emnévoa.

4.1 Visão geral sobre CloudSim e iFogSim

4.1.1 Cloud Computing Simulator

Em 2009 Calheiros et al. [10] implementaram um framework generalista e expansível parasimular ambientes de infraestrutura de Cloud Computing e serviços de aplicações, Cloud-Sim. Os autores de [10] dizem que com este simulador pesquisadores e desenvolvedoresna indústria podem facilmente testar o desempenho de novos serviços e verificar se há ounão a necessidade de aperfeiçoá-los com base nos resultados gerados.

Segundo Calheiros et al. [10], CloudSim é um simulador de eventos discretos que su-porta várias funcionalidades como: i) enfileirar e processar eventos; ii) criação de entidadesde uma nuvem (serviços, hospedeiros, máquinas virtuais etc); iii) comunicação entre com-ponentes e iv) gerenciamento do clock (relógio) da simulação. Além disso, CloudSim estáprojetado em camadas para flexibilizar a implementação de diversas políticas de nuvensde acordo com a necessidade do pesquisador/desenvolvedor.

A comunidade científica mundial tem avaliado CloudSim positivamente como princi-pal referência para a simulações de Cloud Computing. Além disso, a expansibilidade deCloudSim fez com que muitos outros simuladores fossem baseados neste framework, comopor exemplo iFogSim [15], que será discutido na próxima Seção 4.1.2.

Uma observação envolvendo nomenclaturas deve ser colocada neste momento. Cloud-Sim usa em suas classes o conceito de cloudlet, porém para os criadores de CloudSim,uma cloudlet é uma aplicação que é executada por uma máquina virtual dentro de umhospedeiro. Ou seja, o termo cloudlet em CloudSim não tem nenhuma relação com oparadigma de Cloudlet já discutida neste trabalho e adotada no contexto de computaçãoem névoa.

28

CAPÍTULO 4. MYIFOGSIM 29

4.1.2 Fog Computing Simulator

Com o surgimento recente de paradigmas como Fog Computing e IoT, surgiu tambéma necessidade de criação de uma plataforma de avaliação de desempenho de recurso queestes conceitos oferecem. Pensando nisso, Gupta et al. [15] desenvolveram iFogSim, umsimulador criado sobre CloudSim que é capaz de modelar uma névoa e dispositivos de IoTcom o objetivo de medir o impacto das técnicas de gerenciamento de recursos em termosde latência, utilização de rede, consumo de energia e custo [15].

iFogSim mantém o núcleo da implementação de CloudSim para o processamento doseventos entre os componentes de uma névoa e como contribuição, os desenvolvedores criamtais componentes neste novo simulador. Os principais componentes são instanciados pelasclasses:

• FogDevice: Contém as especificações de hardware de uma névoa ou um disposi-tivo de IoT. Esta classe estende a classe PowerDatacenter de CloudSim. Memória,processador, tamanho do armazenamento e largura de banda de uplink e downlinksão os principais atributos de FogDevice. Os métodos desta classe realizam tarefasespecíficas de uma névoa ou dispositivo de IoT responsáveis pelo processamento dastuplas recebidas.

• Tuple: Estende a classe Cloudlet1 de CloudSim. É a tupla gerada por um sensor eque será enviada para processamento em algum AppModule.

• Application: É projetada conforme um grafo acíclico direcionado (DAG - DirectedAcyclic Graph) onde os vértices são os módulos de execução de chegada de umatupla e as arestas são as dependências dos dados entre esses módulos. Esta classecria objetos das seguintes classes:

– AppModule: São os vértices que realizam o processamento das tuplas de che-gada. Esta classe estende PowerVm de CloudSim.

– AppEdge: São as aresta criadas para ligar um par de vértices (AppModule) egerar a dependência entre estas entidades.

– AppLoop: É o fluxo do grafo desde o vértice inicial até o vértice final.

• Sensor: Projetada para ter características de sensores de IoT. Os objetos instanci-ados por esta classe são responsáveis pela criação das tuplas.

• Actuator: Projetada para características de atuadores de IoT. As tuplas processa-das por um AppModule são recebidas pelo objeto instanciado por esta classe.

Como é possível notar, iFogSim já implementa componentes importantes para o con-ceito de Fog Computing, porém até a versão estudada deste simulador, não foi implemen-tado suporte a: i) mobilidade dos dispositivos de usuário, ii) posicionamento geográficoem um mapa, iii) access points, iv) migração das AppModule (máquinas virtuais), v)estratégias e políticas de migração. Neste sentido, para testar e validar a arquitetura e os

1Aplicação que executa por uma máquina virtual de CloudSim


algoritmos de migração proposto nesta dissertação, foi necessária a implementação do su-porte a essas características, resultando em um simulador que foi chamado de MyiFogSim,que será descrito na próxima seção.

4.2 Arquitetura do MyiFogSim

Conforme exposto na seção anterior, uma série de características sobre mobilidade e migra-ção de máquinas virtuais não estão implementadas no iFogSim. Partindo deste princípio eda necessidade um ambiente de simulação com estas características, durante esta pesquisafoi implementado o MyiFogSim.

MyiFogSim mantém tanto o núcleo de CloudSim como o de iFogSim. No entanto,é criado um novo núcleo de execução com novas classes e métodos para representar osaspectos necessários para obter mobilidade dos dispositivos dos usuários, migração demáquinas virtuais (AppModule) e mecanismos de handoff de rede. Os detalhes destenovo núcleo são descritos a seguir.

A Figura 4.1 ilustra um diagrama de classes do núcleo de MyiFogSim. As classesescuras são providas por CloudSim e iFogSim e as classe claras são as principais classescriadas neste novo simulador.

Figura 4.1: Núcleo da arquitetura do MyiFogSim

Estas classes são descritas a seguir:

• Coordinate: Esta classe atua como um mapa de coordenadas (X,Y) de um planocartesiano para posicionar todas as entidades instanciadas de uma simulação. Estasentidades podem ser os servidores de uma névoa, as antenas (access points) e osdispositivos dos usuários ou IoT. Os limites deste mapa podem ser configuradospelo desenvolvedor.


• ApDevice: Esta classe estende FogDevice do iFogSim e acrescenta característicase responsabilidade de um access point de uma rede sem fio, como por exemplo osistema de gerenciamento de handoffs e conexão e desconexão de dispositivos.

• MobileDevice: Também é uma classe que estende FogDevice do iFogSim. Oprincipal objetivo com a criação desta classe é separar conceitualmente os servidoresde uma névoa e os dispositivos de usuário ou IoT, pois em iFogSim ambos sãoinstanciados por FogDevice. Com essa separação é possível manter característicaspeculiares dos dispositivos de usuários ou IoT.

• MobileSensor: Um dispositivo de usuário pode ter mais de um sensor acopladoao hardware e neste sentido esta classe estende Sensor de iFogSim. Em iFogSimo desenvolvedor necessita, caso necessário, criar vários objetos do tipo Sensor paracompor um hardware. MobileSensor já mantém um conjunto de sensores bastandoo desenvolvedor instanciar um único objeto e adicionar, quando necessário, maissensores ao hardware.

• MobileActuator: É uma classe com a abstração semelhante à do MobileSensor.Esta classe estende Actuator do iFogSim.

• MigrationStrategy: Seguindo o padrão de projeto estratégia (design pattern stra-tegy) MyiFogSim está preparado para receber a estratégia de migração desejadapelo pesquisador/desenvolvedor. As subclasses de MigrationStrategy são exemplosde classes abstratas criadas para o uso nesta dissertação e serão descritas em detalhesno Capítulo 5.

• MigrationPolicy: Esta classe é responsável por receber a implementação das po-líticas de migração propostas pelo pesquisador/desenvolvedor.

MyiFogSim faz a migração dos AppModules similarmente ao mecanismo de migraçãode máquinas virtuais do CloudSim. Um método dentro da classe FogDevice é responsávelpor: i) desvincular todos os mapeamentos entre tuplas, AppModule, SmartThing e Ser-verCloudlet de origem e ii) vincular novamente os novos mapeamentos no ServerCloudletde destino.

Durante um processo de migração ou de handoff, novas tuplas geradas pelos sensoresneste período não são processadas pelo dispositivo do usuário e nem pela Cloudlet. Noentanto, a depender dos requisitos de uma aplicação, estas tuplas devem ser armazenadasem um buffer para serem processadas posteriormente.

Após a implementação dos componentes principais do MyiFogSim, que atendem aosrequisitos de mobilidade de usuário, outros componentes foram desenvolvidos em confor-midade com a arquitetura e algoritmos apresentados no próximo capítulo, os quais sãodescritos detalhadamente.

Capítulo 5

Migração de máquinas virtuais em FogComputing

Este capítulo apresenta detalhadamente a arquitetura e os algoritmos de migração pro-postos nesta dissertação.

5.1 Arquitetura

Após o estudo sobre os conceitos de Fog Computing ter sido feito, foi constada a necessi-dade de uma plataforma de migração de máquinas virtuais entre Cloudlets de uma névoapara que a baixa latência na resposta de aplicações dos usuários móveis seja mantida e aQoE permaneça em níveis aceitáveis a medida em que esses usuários se movimentam.

Pensando neste contexto e após a elaboração da hipótese para esta pesquisa, um pro-jeto Top-down foi proposto para atender aos requisitos de baixa latência para os usuáriosmóveis. Esta seção apresenta todos os componentes da arquitetura proposta em duasprincipais abordagens: i) uma arquitetura topológica de alto nível e ii) uma arquiteturaem camadas complementar.

5.1.1 Arquitetura topológica

Seguindo o conceito de hierarquização dos paradigmas de Cloud Computing, Fog Compu-ting e Cloudlets, e os dispositivo de IoT, a Figura 5.1 apresenta o primeiro estágio de umprojeto Top-Down, uma topologia hierárquica completa em três camadas principais. Notopo da hierarquia está a nuvem gerenciada por um NOC (Network Operations Center)oferecendo diversos serviços e aplicações aos seus clientes. Para o escopo desta pesquisa,esta nuvem implementa uma central de localização para monitorar, aprender e ter onis-ciência de toda a rede. A ideia é que a central de localização mantenha informaçõessuficientes para a otimização de futuras migrações das máquinas virtuais.

32

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

Figura 5.1: Arquitetura topológica para migração de máquinas virtuais

Para o bom gerenciamento da infraestrutura de uma Cloud Computing, há uma camadade software para separação dos contextos das diversas aplicações que executam sobre anuvem mantendo middlewares com interface para a névoa. Cada um destes middlewaresé responsável pelo controle de uma névoa e está diretamente ligado à Cloudlet.

Observando ainda a Figura 5.1, no nível intermediário da hierarquia estão as Cloudletsassociadas à névoa. Estas Cloudlets oferecem algum serviço ao dispositivos de IoT emantém uma central de migração que é um dos focos trabalhados nesta dissertação.A central de migração é responsável pelo controle, gestão e estratégia de migração dasmáquinas virtuais. Os principais componentes desta central de migração serão detalhadosna Seção 5.4.

Na parte inferior desta topologia estão os dispositivos de usuários e de IoT que inte-ragem com a névoa através de access points (AP) com um canal de comunicação sem fio.Alguns destes APs podem ser caracterizados como APs de borda, significando que umusuário móvel pode fazer um processo de handoff para um outro AP que está conectadoa outra Cloudlet e, neste caso, pode ser iniciado um processo de migração.

5.1.2 Arquitetura em camadas

Dando sequência ao processo Top Down para esta pequisa, com a sintetização da arqui-tetura topológica (Fig. 5.1) foi criada uma arquitetura em camadas com os componentesnecessários para um serviço de migração de máquinas virtuais em Fog Computing. Os con-ceitos desta arquitetura foram publicados no artigo [7]. A Figura 5.2 ilustra as camadasdesta arquitetura, a saber: i) Dispositivos móveis, ii) Cloudlets e, iii) Nuvem


Figura 5.2: Arquitetura em camadas para migração de máquinas virtuais

No topo desta arquitetura está a Aplicação Fog habilitada, que é uma aplicação emexecução nos dispositivos móveis que se comunicam com as camadas inferiores (Cloudletse Cloud). Os componentes desta arquitetura são descritos em aspectos gerais e de altonível.

Na camada dos Dispositivos Móveis há a API (Application Programming Interface)Fog que é formada por:

1. Offloading : Consiste em onde os dados devem ser organizados, armazenados e tra-fegados.

2. Monitoramento: Responsável por verificar e acompanhar as ações das funcionalida-des dos componentes referentes às migrações.

3. Descoberta de Cloudlet e Sincronização: Encarregado pela escolha das Clodulets,de acordo com parâmetros estabelecidos, bem como oferecer a funcionalidade desincronização entre a replicação, criação e/ou exclusão de dados durante o processode migração.

4. Migração de Aplicação: Move os dados de aplicações das máquinas virtuais para aCloudlet selecionada na fase de Descoberta de Cloudlet.

No nível intermediário está a camada de Cloudlets e tem como os principais compo-nentes:


1. Comportamento de mobilidade e análise de handoff : Responsável pela detecção,monitoramento e análise do deslocamento dos usuários.

2. Migração de Máquinas Virtuais : Principal módulo que forma a Central de Migraçãoe é responsável pelas decisões de mobilidade entre as Cloudlets aptas a receber asmáquinas virtuais.

3. Monitoramento de QoS : Por se tratar de uma arquitetura para aplicações em temporeal, este módulo é responsável por verificar se a comunicação está ou não dentrodos parâmetros estabelecidos.

4. Análise de custo: Baseado em um Modelo de Negócios com características parao oferecimento de infraestrutura de Fog Computing e de Cloudlets por parte deempresas privadas.

5. Sincronização: Comportamento similar ao módulo Sincronização na camada dosdispositivos móveis.

6. Descoberta de Cloudlet : Montagem da topologia em que as Cloudlets estão organi-zadas para tornar mais eficiente o processo de migração.

A camada de Cloud, que está no último nível, é um modelo mais maduro ao se compararcom as recentes pesquisas de Fog Computing. Os diferentes tipos de serviços implemen-tados em uma nuvem (XaaS) podem ser oferecidos às névoas para suporte às Cloudlets.

Para limitar o escopo desta dissertação, foi necessário escolher somente alguns com-ponentes para serem trabalhados, testados e validados. A Tabela 5.1 mostra quais foramos componentes implementados.

Tabela 5.1: Componentes implementados da arquiteturaComponentes Proporção da implementação

Offloading ParcialMonitoramento Parcial

Descoberta de Cloudlets e sincronização MínimoMigração de aplicação Parcial

Comportamento de mobilidade TotalMigração de máquinas virtuais Total

Monitoramento de QoS MínimoAnálise de custo MínimoSincronização Mínimo

Descoberta de Cloudlets Total

A coluna Proporção da Implementação mensura o quanto um componente foi im-plementado. Mínimo significa que somente partes básicas mínimas para que outros com-ponentes funcionassem corretamente foram implementadas. Parcial significa que alémdo mínimo, foi necessário algo mais elaborado, mas ainda faltam partes a implementar.Total significa que o componente foi implementando em sua totalidade.


5.2 Algoritmo base

Os algoritmos propostos nesta dissertação foram baseados em um fluxograma com a ideiageral sobre o que um sistema de migração em Fog Computing deve conter. Este fluxo-grama é apresentado seguindo a proposta Top-down e está descrito na Seção 5.2.1. Apósesta elaboração, imaginou-se cenários que podem ocorrer em um ambiente real que serãodescritos na Seção 5.3. Os algoritmos são propostos por meio de técnicas de migração quesão expostas na Seção 5.4.

5.2.1 Fluxogramas

Inicialmente foi proposto um fluxograma em alto nível para expor a ideia geral de umalgoritmo de migração em Fog Computing. A Figura 5.3 mostra os componentes para atomada de decisão sobre quando, para onde e como uma máquina virtual deve migrar.

Figura 5.3: Fluxograma simplificado da arquitetura de migração em Fog Computing

Os componentes deste fluxograma (Fig. 5.3) são elencados a seguir:

1. Migration Decision: Este módulo contém métodos para fazer a tomada de decisãode migração de acordo com as políticas e estratégias estabelecidas.

2. Before Migration: Em caso de decisão pela migração, este módulo prepararáos dados que necessitam ser migrados. Estes dados devem ser entregues a algumsistema que faz migração propriamente dita (transmissão através da rede).


3. During Migration: Responsável por verificar, gerenciar e sincronizar o processode migração entre duas Cloudlets. Caso ocorra algum erro durante a migração, osistema de gerência pode tentar solucionar o problema em tempo de execução ouabortar o processo de migração se necessário.

4. After Migration: Este módulo encerrará a conexão entre a antiga Cloudlet e anova Cloudlet.

Para se ter uma especificação mais detalhada, um segundo fluxograma baseado noprimeiro foi proposto. A Figura 5.4 mostra os detalhes incorporados ao modelo.

Cada um dos componentes são descritos, em alto nível, a seguir:

• mobileUser: Verifica se o usuário está ou não se movendo.

• noMigration: A decisão sobre a migração foi negativa.

• locationDiscover: Verifica e retorna qual a posição do usuário em relação ao APconectado.

• migrationZone: Verifica se o usuário está em uma zona de migração.

• flowDirection: Verifica se na direção em que o usuário está existem Cloudlets.

• chooseCloudlet: Da lista de Cloudlets que estão na direção do caminho do usuário,é escolhida uma Cloudlet.

• networkState: Verifica a carga da rede entre a Cloudlet de origem e a possívelCloudlet de destino.

• availableCloudlet: Verifica se a Cloudlet de destino está disponível para receberuma nova máquina virtual.

• serviceOffer: Verifica o tipo de serviço oferecido pela Cloudlet de destino (públicoou privado).

• getValue: Verifica se o valor cobrado é aceito pelo usuário.

• toMigrate: A decisão de migração foi positiva.

• dataPrepare: Verifica e prepara as instâncias de dados que devem ser migrados.

• replicaVM: Verifica que tipo de estratégia de migração será utilizada.

• completeVM: Toda a máquina virtual deve ser migrada em um processo de mi-gração não ao vivo.

• containerVM: Somente alguns dados da máquina virtual serão migrados. Os dadosserão selecionados de acordo com dataPrepare

• liveMigration: Toda a máquina virtual deve ser migrada em um processo demigração ao vivo.


• networkStatus: Estabelece uma conexão entre a Cloudlet de origem e de destino.

• startMigration: Os dados são entregues para o sistema que irá fazer o transportedos dados da Cloudlet de origem até a Cloudlet de destino.

• managementBetweenCloudlets: Controle de gerenciamento central do processode migração.

• userLocation: Verifica a posição do usuário no mapa e em que AP ele está conec-tado.

• handoffStart: Verifica se o processo de handoff já iniciou.

• handoffError: Verifica se há erro durante o processo de handoff.

• handoffStatus: Verifica se o handoff foi bem sucedido.

• abortMigration: Interrompe o processo de migração caso algum erro irrecuperávelocorra.

• synchronismStart: Inicia no destino os processos para recebimento da uma novamáquina virtual.

• startBootVM: Inicia o processo de boot de uma máquina virtual já existente nodestino para receber os dados de um container.

• allowNewVM: Um novo ambiente para a máquina virtual será criado para receberuma máquina virtual completa.

• dataRecive: Verifica os dados da migração.

• synchronismStatus: Monitora como está o recebimento dos dados na Cloudlet dedestino.

• migrationOk: Fim do processo de migração.

• desconnectCloudlets: Desconexão de rede entre a antiga Cloudlet e a nova Clou-dlet.


Figura5.4:

Fluxo

gram

adetalhad

o


5.3 Cenários com migração e handoff

Na vida real, alguns cenários podem ocorrer durante a locomoção dos usuários. Consi-derando um ambiente onde exitem mecanismos de migração de máquinas virtuais parausuários móveis em uma névoa e também processos de handoff de redes sem fio ativos,uma linha do tempo pode haver várias possibilidades de configurações envolvendo: i)Cloudlets, ii) rede entre as cloudlets e conexão sem fio, iii) eventos em uma linha dotempo.

A Figura 5.5 mostra um dos cenários mais simples que podem ocorrer durante umamovimentação de um usuário. Para esta pesquisa, um ponto para o início do processo demigração será quando um usuário estiver próximo de realizar o handoff. A ideia para usarum ponto de migração desta forma é que como o handoff inevitavelmente já causará umdowntime na aplicação do usuário, o processo de migração deve “aproveitar” este período einiciar a migração, desta forma o tempo de downtime de handoff estará contido dentro dotempo de downtime da migração. Detalhes sobre este ponto de migração serão discutidosna Seção 5.4.

Figura 5.5: Cenário normal para uma migração de máquinas virtuais em Fog Computing

A Cloudlet de origem está hospedando e executando a máquina virtual do usuárioantes de ocorrer a migração e o handoff e o usuário está conectado através de um linksem fio. A Cloudlet de destino hospedará e executará a máquina virtual do usuáriodepois dos processos de migração e handoff. O ideal é que depois que o usuário cruzar deuma fronteira geográfica para uma outra região, a máquina virtual já esteja habilitada nodestino para receber as novas requisições do usuário.

Uma Rede entre as cloudlets (WAN) é um meio físico em que as Cloudlets secomunicam. Este meio físico pode ser de vários tipo de rede, como por exemplo: i) fibra


óptica, ii) Wi-Fi de longa distância, iii) link de satélite, iv) PLC (Power Line Communi-cation), entre outras.

A Conexão sem fio do usuário é o meio físico sem fio em que o dispositivo dousuário se conecta à Cloudlet através de um AP. Este link pode ser provido por váriostipos de redes sem fio, como por exemplo: i) 4G/LTE, ii) 5G, iii)Wi-Fi ou iv) Bluetooth.Neste cenário, um usuário está conectado a uma Cloudlet de origem antes da migração eestará conectado na Cloudlet de destino após a migração.

A Linha do tempo a mobilidade tem vários instantes onde os eventos relacionadosa esta arquitetura ocorrem. Estes instantes são os Tx se serão descritos a seguir:

• T1 Decisão da migração: É o instante em que o algoritmo de migração decidepositivamente pela migração de acordo com os mecanismos descritos nos fluxogramasdas Figuras 5.3 e 5.4.

• T2 Preparando a migração: Neste momento deve ocorrer a preparação dos dados edas instâncias de migração. É também neste momento em que deve ser estabelecidaa conexão entre as Cloudlets. A maior parte deste tempo foi descrita no fluxogramada Figura 5.4 (BeforeMigration).

• T3 Início do processo de migração: Instante em que será iniciado o envio dos dadospara a Cloudlet de destino. A depender da estratégia de migração, a VM entraráem downtime neste momento. Este processo é a parte final de BeforeMigration naFigura 5.4.

• T4 Início do handoff de rede: Este tempo é definido pela política de handoff derede e, neste caso, como um cenário básico, tem que ocorrer depois do início doprocesso de migração.

• T5 Fim do handoff de rede: Se tudo ocorreu bem, neste momento o mecanismode handoff esterá completo. O usuário terá uma nova conexão com a rede e iráaguardar até que a migração da máquina virtual seja finalizado.

• T6 Fim do processo de migração: Se tudo ocorreu bem, neste momento o processode migração da máquina virtual estará completa. A máquina virtual deverá estarpronta para receber as novas requisições do usuário.

• T7 Envio de requisição para a Cloudlet: Neste momento o usuário envia para anova Cloudlet requisições para usar os recursos da máquina virtual novamente.

• T8 Acessando a máquina virtual: Tudo certo! O usuário usa sua aplicação normal-mente em sua nova Cloudlet.

5.3.1 Comentários gerais e outros cenários

Uma permutação pode ocorrer entre os Tx quando leva-se em consideração aspectosreais. Quatro cenários dos muito possíveis serão apresentados a seguir. Dentre eles estãoinclusos os considerados nesta pesquisa como o pior e o melhor caso.


O pior cenário

Durante o caminho do usuário, atrasos em ambos os processos (migração e handoff )podem ocorrer. Quando algum atraso ocorre no processo de migração (por exemplo: lentadecisão de migração) a linha do tempo proposta para o cenário simples poderá mudar.Para o pior caso, o início e o fim do processo de handoff (T4/T5) acontecem antes doinício do processo de migração (T3). A Figura 5.6 ilustra o pior cenário considerado nestadissertação.

Figura 5.6: O pior cenário para migração de máquinas virtuais em Fog Computing

O usuário acessará sua máquina virtual na antiga Cloudlet através da nova Cloudlet(no mínimo dois saltos de rede) porque o mecanismo de handoff está finalizado. O novoacesso está acontecendo através da nova conexão sem fio e as requisições e resposta serãotrafegadas por este caminho de rede. Quando o processo de migração terminar, o usuáriodeverá acessar sua máquina virtual normalmente como em um cenário simples. Nestepior cenário, os tempos de downtime do handoff e da migração serão somados e isso podeocasionar a degradação na QoE do usuário. Neste sentido, durante a implementação domodelo no simulador, este cenário está previsto e tratado.


O melhor cenário

Um outro cenário que pode acontecer é quando o mecanismo de handoff de rede e oprocesso de migração iniciam e terminam juntos. A Figura 5.7 ilustra esta situação.

Figura 5.7: O melhor cenário para migração de máquinas virtuais em Fog Computing

Nota-se que, diferentemente do cenário simples apresentado na Figura 5.5, a máquinavirtual não precisa esperar por um logo tempo entre T5 e T6.

Congestionamento na Rede entre Cloudlets

Neste cenário, o início do processo de migração e o início do handoff de rede ocorremnormalmente como no cenário simples, mas o handoff é finalizado muito antes do fim doprocesso de migração. A Figura 5.8 mostra um cenário com problemas na rede WANentre as Cloudlets.


Figura 5.8: Cenário com problemas de rede

O processo de migração demora iniciar

É o cenário onde o handoff de rede é iniciado antes do processo de migração. Diferentespermutações podem ocorrer entre os finais do handoff e da migração na linha do tempo.Algumas possíveis linha do tempo seriam: i) T1, T2, T4, T3, T5, T6, T7 e T8; ii) T1,T2, T4, T3, T5 e T6 juntos, T7 e T8; iii) T1, T2, T4, T3, T6, T5, T7 e T8.

5.4 Técnica de migração

Baseada nas arquiteturas apresentadas anteriormente nas seções 5.1.1 e 5.1.2, uma novatécnica de migração foi projetada. O núcleo desta nova técnica é composta por:

• Política de Migração: Uma política de migração deve considerar os aspectosreferentes ao ambiente geográfico em que um usuário está imerso, como por exemplo:

– Ponto para migração

– Zona para migração

– Velocidade do usuário

– Direção do usuário

– Posição geográfica no mapa

• Estratégia de Migração: Uma estratégia de migração deve considerar como umsistema escolhe a próxima Cloudlet para receber uma máquina virtal de usuário.


5.4.1 Políticas de migração

A política de migração examina quando a máquina virtual deve ser migrada de acordo osaspectos físicos do cenário. A Figura 5.9 mostra os elementos que devem ser monitoradosdurante o caminho de um usuário e também mostra uma topologia simples com um accesspoint e sua área de cobertura.

Figura 5.9: APs, usuários e migração de acordo com a direção do deslocamento.

UmUsuário tem uma posição, uma velocidade e uma direção para suas característicasna topologia. A cada laço do algoritmo é verificado se a máquina virtual deve migrar ounão. Além disso, o sistema verifica a distância entre o usuário e o AP.

O Ponto de migração é um ponto do mapa onde a migração da máquina virtual deveser iniciada antes que o mecanismo de handoff aconteça. Para que o algoritmo funcionemelhor, o estabelecimento deste ponto de migração deve estar alinhado com a política dehandoff, ou seja, o projetista de um sistema final para a migração deve conhecer quaissão as a políticas de handoff de rede em que o dispositivo de usuário estará conectado,pois a arquitetura proposta nesta dissertação presume que a migração ocorra antes desteprocesso. Dois tipos de ponto de migração foram utilizados durante a fase de teste: i)Ponto de migração estático e ii) Ponto de migração dinâmico. A escolha do ponto demigração será discutido no Capítulo 6. A Figura 5.10 exemplifica a escolha de um pontode migração estático. Um ponto estático sempre será o mesmo para qualquer tipo desituação em que os usuários estejam. Neste exemplo, o ponto foi fixado a uma distância


30% anterior à distância de ocorrência do handoff. A Figura 5.11 exemplifica um ponto demigração dinâmico. A depender da mobilidade de um usuário e da quantidade de dadosque necessitam migrar, o ponto de migração poderá variar de um processo de migraçãopara outro.

Figura 5.10: Exemplo de um ponto de migração estático.

Figura 5.11: Exemplo de um ponto de migração dinâmico.

A Zona de migração é o cone resultante da combinação entre: i) as regiões adjacentes


da direção do usuário e ii) a região geográfica relativa entre o AP e o usuário (estabelecidapor um angulo theta θ de 135◦). Por exemplo, o Usuário 1, que está na direção leste,tem como suas regiões adjacentes sudeste e nordeste e ele está posicionado na regiãoleste do AP. Esta combinação forma a zona de migração para este usuário, assim comoapresentada na Figura 5.9. Um usuário estará apto a migrar quando ele estiver dentro dazona de migração e atingir (ou ultrapassar) o ponto de migração. Já o Usuário 2 estána região noroeste do AP e suas adjacências em relação à sua direção são as regiões lestee sul, não correspondendo assim, a formação de uma zona de migração.

Uma direção é baseada nas oito direções cardinais: leste, nordeste, norte, noroeste,oeste, sudoeste, sul e sudeste.

Todos os componentes desta topologia são parâmetros para a tomada de decisão demigração e deve se relacionar com as estratégia de migração, uma vez que um ponto demigração para uma estratégia ABC será melhor do que para uma estratégia XYZ. ASeção 5.4.2 detalha as estratégias de migração consideradas nesta dissertação.

5.4.2 Estratégias de migração

As estratégias de migração apresentadas nesta seção foram projetadas para atender aosrequisitos 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 simuladorMyiFogSim 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óduloMigrationDecision através de uma interface UML (Uni-fied Modeling Language) que implementa o padrão de projeto strategy. MigrationDecisioncontém um único método booleano chamado shouldMigrate e que deve ser implementadode acordo com a política escolhida.

Figura 5.12: Padrão de projeto strategy para MigrationDecision


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á escolhera 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 umconjunto de Cloudlets candidatas.

A Figura 5.13 mostra que essas estratégias podem escolher Cloudlets diferentes adepender do posicionamento geográfico do usuário ou ainda da carga de processamentode 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íticade 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 18combinações para cada estratégia o que dá um total de 54 combinações. Alguns exemplosdestas combinações são:

1Como 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 chamadosde serverCloudlet


• 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çãoestá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 implementadosde 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 serimplementado de acordo com a política e estratégia de migração escolhidas e para estadissertação foram implementadas três classes distintas de preparação dos dados, a saber:


• PrepareCompleteVM: É baseada na técnica tradicional de migração de máquinasvirtuais. Durante sua execução 100% da máquina será entregue para o sistema detrasporte 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. Durantesua execução 60% dos dados serão entregues para a migração, porém é introduzidoum custo a mais para o processamento da imagem do container. Assim que os dadosforem 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 ede usuário que não estão carregados na memória principal e ii) os dados que estãoem execução na memória principal. O serviço só entrará em downtime quando ousuá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ítulodescreve os testes baseados em simulações, mostra os resultados encontrados e faz umadiscussã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 dosimulador MyiFogSim, iniciou-se o processo de testes e validação através de duas etapasde simulações. Inicialmente, foi verificado se realmente um processo de migração na névoamelhora 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 diretamenteas permutações de parâmetros das políticas de migração discutidas no final da Seção5.4.2, bem como são comparadas as estratégias de migração. Os aspectos da Etapa 2 sãoapresentados na Seção 6.2.

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

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

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

• Modelo de mobilidade: Os usuários sempre andam em linha reta, na mesmadireção e em velocidade constante até o final do mapa, quando então são removidosda 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 umahipotenusa do mapa). Para a Etapa 2, mais de um usuário estavam presentes nasimulação e cada um deles recebeu uma posição, uma direção e uma velocidadealeatoriamente 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.

51

CAPÍTULO 6. SIMULAÇÕES 52

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

• Redes entre as Cloudlets: Para simplificar, como topologia de rede escolheu-seuma full mesh (Rede em malha completa) onde todas as Cloudlets estão conectadasentre elas em um grafo completo. Para os testes foram escolhidos três grupos deintervalos de velocidade de taxa de transmissão dos links. Cada link de um par deCloudlets 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 mapanum 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 utilizadoum ponto fixo máximo para o início do processo de troca de APs baseado na distânciaentre o usuário e o AP. A distância máxima é de 40 metros antes do usuário atingiro limite de cobertura. O tempo de handoff foi atribuído aleatoriamente de umadistribuiçã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çãouniforme.

• 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 nadistância de 30% antes ao ponto de handoff, ou seja, o ponto fixo é de 52 metrosantes do limite de cobertura do AP.

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

• Envio de tuplas para processamento: Foi utilizada a aplicação EEG TractorBeam 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,


objetos (virtuais) são atraídos em sua direção. A Figura 6.1 ilustra a implementaçãodeste jogo em iFogSim, contendo cinco AppModules e sete AppEgdes para simularo 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 nosmartphone e outra parte na névoa. O resultado do processamento é executadopelo 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 umamá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 processosde handoff necessários, porém sem realizar nenhuma migração. Até o fim do mapa, amá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 últimocenário de migração considerou-se somente o ponto de migração estático e a estratégia demigração tradicional (migrar a máquina virtual completa). Nestas duas partes, somenteuma semente foi executada.

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


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

Observa-se que toda a simulação está presente (1.800 s - 30 min) no gráfico. Em todasas redes houve o mesmo comportamento das latências e por esse motivo, a latência narede rápida sobrepõe as outras redes. Os resultados indicam que no início do percursodo 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 partedo gráfico. Logo após 200 s da simulação, há um salto para uma latência constante comvariações entre aproximadamente 119 ms e 128 ms (alternadamente), que também explicaa “linha” espessa formada. O próximo salto acontece um pouco antes de 800 s e a latênciase mantém estável em torno de 160 ms sem alternar com outros valores, o que explicauma “única linha” mais fina no gráfico. Outros saltos de latência acontecem até o fim dasimulação. É possível afirmar que nestes saltos de latência haveria a necessidade de seremrealizadas as migrações. No final da simulação, o usuário estava acessando sua máquinavirtual 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.


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, permaneceramidênticas, pois o usuário estava acessando sua máquina virtual na primeira Cloudlet quese conectou. Igualmente como no gráfico anterior, há o salto de latência no cenário de nãomigração, porém nota-se que neste mesmo ponto houve o primeiro processo de migraçãoe após o processo ter terminado, a latência voltou a ficar em torno de 20 ms. O mesmoacontece para os gráficos das Figuras 6.4 e 6.5 que representam, respectivamente, oscenários de rede média e rápida.

Figura 6.4: Comparação das latências para uma rede média entre não migrar e migrar


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 eiv) 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 come todas as estratégias


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

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

Cada uma das estratégias implementadas apresenta comportamento distinto. Umaaná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çãoe utilizando os mecanismos de migração propostos. Nota-se que quando não há migraçãoda máquina virtual, a média é maior que 200 ms o que degrada a QoE do usuário.


Figura 6.9: Média das latências de um usuário da primeira semente em diferentes nocená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 decinco e dez usuários.

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

6.2 Etapa 2: Comparação entre as políticas e estraté-gias de migração

A Etapa 2 executou as simulações de todas as combinações entre as estratégias, os pontosde migração, os tipos de migração e as capacidades de rede para 5 usuários. Para verificara escalabilidade da arquitetura e algoritmos propostos, os testes foram repetidos para 10e 15 usuários.

6.2.1 Sub-etapa 2.1: Ambiente com 5 usuários

A Figura 6.10 mostra o gráfico1 obtido a partir dos resultados encontrados dos temposde downtime e de migração em uma rede lenta usando o ponto de migração estático. Na

1Na legenda, o tempo sem máquina virtual é o tempo de downtime referido no texto


parte superior das barras encontra-se o intervalo de confiança de 95%. Este intervalo éusado para todos os gráficos.

Figura 6.10: Comparação dos tempos de downtime e tempo de migração entre as políticase estratégias de migração em uma rede lenta com cinco usuários (ponto estático).

Neste conjunto de combinações, pode-se observar que nas migrações tradicionais e decontainers o tempo de downtime está muito próximo ao tempo de migração, indicandoque houve um bom comportamento dos algoritmos, onde o tempo de handoff foi realmenteaproveitado, porém pelo fato de ser uma rede lenta, o tempo sem a máquina virtual éalto (cerca de 80 s para tradicional e cerca de 50 s para containers). É possível observarainda que nos resultados das migrações ao vivo, os tempos de downtime são maiores queos tempos de downtime de containers. Isto indica que um ponto de migração estático nãoé uma boa política com migrações ao vivo quando há redes lentas, porém ainda assim,considerando somente os tempos das migrações ao vivo, o tempo de downtime é cerca de80% do tempo de migração.

A Figura 6.11 mostra o gráfico com os resultados dos testes usando um ponto demigração dinâmico em uma rede lenta. Observa-se que nas migrações tradicionais e decontainers, os tempos de migração são menores que os tempos de downtime, o que significaum custo extra de processamento foi adicionado ao tempo de downtime das máquinasvirtuais durante as migrações. Para as migrações ao vivo, o comportamento dos algoritmosbeneficia os tempos de downtime uma vez os tempos das migrações foram equivalentesaos tempos das migrações tradicionais, pois os tamanhos das máquinas virtuais são osmesmos. O tempo de downtime nas migrações ao vivo foi cerca de 40% do tempo demigração.


Figura 6.11: Comparação dos tempos de downtime e tempo de migração entre as políticase estratégias de migração em uma rede lenta com cinco usuários (ponto dinâmico).

Mudando o cenário das simulações, a Figura 6.12 mostra o gráfico com os resultadosobtidos em redes médias usando um ponto de migração estático.


Figura 6.12: Comparação dos tempos de downtime e tempo de migração entre as políticase estratégias de migração em uma rede média com cinco usuários (ponto estático)

Obviamente, ao aumentar a capacidade dos links das redes entre as Cloudlets e nãoinserindo mais requisições de redes, pode-se observar que a média dos tempos tanto dedowntime quanto do tempo de migração são menores que 13 segundos. Em contraste comuma rede lenta, as migrações ao vivo utilizando um ponto de migração estático tiveram umbom desempenho no tempo de downtime. Quando comparamos com proporcionalidadedos resultados de uma rede lenta (80%), neste cenário o downtime nas migrações ao vivosão cerca de 47% do tempo de migração.

A Figura 6.13 mostra o gráfico com os resultados no cenário de uma rede média eponto de migração dinâmico.


Figura 6.13: Comparação dos tempos de downtime e tempo de migração entre as políticase estratégias de migração em uma rede média com cinco usuários (ponto dinâmico).

Ao analisar os resultados, nota-se que em ambos os pontos de migração em uma redemédia, nas migrações tradicional e de containers, os tempos de downtime e de migração sãosimilares, porém nas migrações ao vivo o ganho usando um ponto de migração dinâmicoé ligeiramente melhor que no ponto de migração estático.

As Figuras 6.14 e 6.15 mostram os resultados obtidos para uma rede rápida e pontode migração estático e dinâmico, respectivamente.


Figura 6.14: Comparação dos tempos de downtime e tempo de migração entre as políticase estratégias de migração em uma rede rápida com cinco usuários (ponto estático)

Figura 6.15: Comparação dos tempos de downtime e tempo de migração entre as políticase estratégias de migração em uma rede rápida com cinco usuários (ponto dinâmico).


Por se tratar de uma rede rápida, em ambos os cenários todos os tempos ficaramabaixo de 1,8 segundos. No entanto, nas migrações tradicional e de containers os temposde downtime em com ponto de migração estático foram maiores que os tempos em umponto de migração dinâmico. Isso ocorre porque as migrações usando um ponto estáticoiniciaram os processos antes do necessário e, neste caso, as migrações das máquinas vir-tuais finalizaram primeiro que o processo de handoff. Observa-se ainda que tanto paramigração de containers quanto para as migrações ao vivo, os tempos de downtime sãosimilares quando usam um ponto de migração dinâmico e são, em média, um pouco maisde 1 segundo.

A Figura 6.16 mostra o gráfico com a compilação dos resultados de todos os cenáriosjuntos para o tempo de downtime.

Figura 6.16: Comparação entre todos os tempos de downtime para 5 usuários

Enquanto os tempos de downtime e os tempos de migração são adequados para analisaras políticas de migração, as latências tem o mesmo efeito para as estratégias de migração.A Figura 6.17 mostra o gráfico com os resultado das médias de todas as latências e detodos os cinco usuários durante toda a simulação em uma rede lenta.


Figura 6.17: Média das latências de todos os usuários em uma rede lenta.

Nota-se que as latências mais baixas são as latências da estratégia que escolhe o APmais próximo ao usuário.

As Figuras 6.18 e 6.19 mostram, respectivamente, os gráficos com todas as latênciaspara as redes média e rápida. É possível perceber que apresentam o mesmo comporta-mento de uma rede lenta.


Figura 6.18: Média das latências de todos os usuários em uma rede média.

Figura 6.19: Média das latências de todos os usuários em uma rede rápida.



Os resultados referentes às simulações com 10 usuários tiveram o mesmo comportamentoapresentado pelos resultados com 5 usuários. A Figura 6.20 mostra o gráfico com osresultados condensados dos tempo de downtime para o ambiente com 10 usuários.


As médias das latências podem ser observadas no gráfico da Figura 6.21. Os valoressão as médias de todas as latências para os dez usuários durante toda a simulação emuma rede lenta.


Figura 6.21: Média das latências de todos os usuários em uma rede lenta para dez usuários.

Assim como nas médias para cinco usuários, a estratégias que escolhe o AP maispróximo ao usuário obteve as melhores médias das latências.

As Figuras 6.22 e 6.23 mostram, respectivamente, os gráficos com todas as latênciaspara as redes média e rápida. É possível perceber que apresentam o mesmo comporta-mento de uma rede lenta. Ambos são para dez usuários.


Figura 6.22: Média das latências de todos os usuários em uma rede média para dezusuários.

Figura 6.23: Média das latências de todos os usuários em uma rede rápida para dezusuários.



Como esperado, os resultado obtidos para um ambiente com 15 usuários manteve o mesmopadrão dos resultados dos ambientes anteriores (5 e 10 usuários). A Figura 6.24 mostra ográfico com a média dos resultados para os tempos de downtime obtidos neste ambiente.


Para comparar as três sub etapas de testes as Figuras 6.25, 6.26 e 6.27 mostram osgráficos com os percentuais relativos ao aumento ou redução do tempo de downtime emrelação ao tempo de migração para as redes lentas, médias e rápidas, respectivamente.


Figura 6.25: Comparação entre todos os tempos de downtime de todos os cenários com arede lenta

Figura 6.26: Comparação entre todos os tempos de downtime de todos os cenários com arede média


Figura 6.27: Comparação entre todos os tempos de downtime de todos os cenários com arede rápida

É possível notar que somente nas migrações ao vivo houve a redução do tempo dedowntime em relação ao tempo de migração. No entanto, em alguns casos a arquitetura epolíticas propostas mesmo havendo um pequeno aumento nesta relação, é possível manterum bom nível de QoE dependendo da capacidade do links entre as Cloudlets.

Após as comparações e rápidas conclusões sobre políticas de migração, foram feitasalgumas análises sobre as latências após a ocorrência das migrações com o objetivo decomparar as estratégias de migração propostas.

6.3 Latências após as migrações

Como cada estratégia de migração pode escolher distintamente a próxima Cloudlet quereceberá uma máquina virtual, esta seção, similarmente à Etapa 1 dos testes, tem comoobjetivo analisar as latências de uma aplicação após a migração (ou não) da máquinavirtual.

Usuário permanece no mesmo AP

A depender da posição inicial, da velocidade e da direção, é possível que um usuário nãonecessite fazer nem handoff e nem migração e com isso sua latência deve oscilar somenteem relação à sua distância do AP em que está conectado.

A Figura 6.28 mostra o gráfico com as latências de um único usuário durante toda a


simulação. Este usuário não efetuou nenhum handoff e, consequentemente, também nãohouve a necessidade de migrar sua máquina virtual.

Figura 6.28: Latências para um usuário que não realizou handoff e nem migração.

Como este usuário permaneceu conectado a um único AP, a diferença nas latênciasé somente em relação à distância do AP, ou seja, quanto mais distante do AP, maior foia latência da aplicação. O ponto mais baixo é quando o usuário está mais próximo doAP. Nota-se que há uma parte mais espessa entre aproximadamente 700 s e 1200 s. Estecomportamento é idêntico ao comportamento descrito anteriormente na Etapa 1.

As estratégias escolhem a mesma Cloudlet

O estado da rede, a carga de processamento e capacidade de uma Cloudlet ou a distânciaentre um usuário e uma Cloudlet podem influenciar na escolha da próxima Cloudlet quereceberá a máquina virtual de um usuário.

A Figura 6.29 mostra o gráfico com os resultados das latências após dois handoffs euma migração. Para este caso, todas as estratégias de migração escolheram a mesmaCloudlet de destino e por isso não é possível observar diferenças entre elas. O primeirohandoff ocorreu antes de 400 s, a migração iniciou após 700 s e finalizou logo após 800 se o segundo handoff ocorreu aproximadamente em 1.100 s. Os cenários em que o usuárioestava era em uma rede lenta, com ponto de migração estático e fazendo uma migraçãotradicional.


Figura 6.29: Comparação das latências para um usuário em uma rede lenta, com pontode migração estático e migração tradicional.

A observação do intervalo de tempo da última tupla que executou em uma Cloudletde origem e a primeira tupla executada na Cloudlet de destino é uma outra forma deverificar o tempo de downtime pelas latências. O gráfico da figura anterior mostra que odowntime da máquina virtual durante a migração que ocorreu é de aproximadamente 80s.

A Figura 6.30 mostra o gráfico com as latências para o mesmo usuário da figuraanterior, porém agora mostrando os resultados com todas as redes e todas as estratégiasde migração. Os handoffs ocorreram igualmente aos tempos anteriores, porém nota-seagora que em redes mais rápidas, o downtime é menor que em redes mais lenta.


Figura 6.30: Latências para um usuário em todas as redes e estratégias em um ponto demigração estático escolhendo a mesma Cloudlet de destino.

As estratégias escolhem Cloudlet distintas

A Figura 6.31 mostra o gráfico com as latências de outro usuário (simulação diferente)em diversos cenários com um total de três migrações. Desta vez, algumas estratégiasdiferentes escolheram Cloudlets diferentes para receber a máquina virtual do usuário.Nota-se que a depender da escolha, é possível manter, aumentar ou diminuir a latênciado usuário.

Figura 6.31: Latências para um usuário em todas as redes e estratégias em um ponto demigração estático escolhendo Cloudlets de destino diferentes.


Uma discussão mais detalhada dos resultados dos testes é apresentada na próximaseção.

6.4 Discussão

Nesta seção são apresentados os principais pontos que devem ser destacados com in-terpretação dos resultados dos testes realizados e também discuti-los de acordo com aarquitetura e algoritmos propostos e os conceitos sobre Fog Computing.

A primeira etapa dos testes se mostrou muito importante para dar um bom fundamentose é ou não necessário que ocorram migrações de máquinas virtuais para manter umaQoE aceitável durante a mobilidade do usuário. Este teste foi proposto pensando que,se após um handoff de um APx conectado a uma Cloudletx para um APy conectadoa uma Cloudlety a latência da aplicação se mantivesse próxima ou levemente maior aoque estava anteriormente, a migração de uma máquina virtual não seria necessária, poisos custos associados às migrações poderiam ser muito alto para se ter um baixíssimoganho posteriormente. No entanto, os testes mostraram que se não houver a migraçãoda máquina virtual, com o decorrer do afastamento de usuários realizando handoffs semque haja a troca de acesso de Cloudlet, a QoE poderá atingir níveis inaceitáveis paraaplicações que necessitam executar em tempo real.

A Etapa 1 mostrou também que ao se realizar migrações haverá períodos de downtime,e nestes momentos, a aplicação perderá o acesso à máquina virtual. Conforme propostopela arquitetura, a máquina virtual só deveria fazer a migração quando um handoff fosserealizado. Neste sentido, os algoritmos de migração funcionaram de acordo com o espe-rado, ou seja, nenhum processo de migração ocorreu fora da expectativa de realização dehandoff.

Observou-se ainda na Etapa 1, que a estratégia de escolha da próxima Cloudlet parareceber uma máquina virtual é fundamental para que a latência seja mantida de acordocom o esperado. Já nesta etapa, os resultados das médias das latências do usuário em umaúnica semente de simulação revelam que a estratégia de escolha da próxima Cloudlet peloAP mais próximo mostrou ter vantagens em relação como as demais e, principalmente, emrelação ao cenário que não houve migrações. No caso da Etapa 1, não foram executadostestes sobre as combinações das políticas de migração e neste sentido, foram propostos ostestes da Etapa 2.

A segunda etapa executou testes como todas as combinações entre as políticas e es-tratégias e a capacidade de rede. Para complementar estas combinações, foram propostoscenários que aumentassem gradualmente o número de usuários. Até o momento da reda-ção desta dissertação, só foi possível a simulação com no máximo 15 usuários devido aoalto custo de simulação com mais usuários. Estes custos são discutidos mais a seguir.

Os testes realizados na Etapa 2 mostram que muitos fatores podem influenciar oscustos de um processo de migração em uma névoa. Na Tabela 6.1 pode ser observadauma sumarização dos testes sobre as políticas de migração e quais são as consideraçõesem relação aos resultados apresentados.


Tabela 6.1: Resumo sobre as políticas de migração.Politicas Relação Tempo Mig. x Downtime AvaliaçãoTradicional Leve aumento RuimEstáticoLenta

Tradicional Leve aumento RuimEstáticoMédia

Tradicional Aumento BomEstáticoRápida

Tradicional Leve aumento RuimDinâmicoLenta

Tradicional Leve aumento RuimDinâmicoMédia

Tradicional Aumento BomDinâmicoRápida

Container Leve aumento RuimEstáticoLenta

Container Leve aumento RazoávelEstáticoMédia

Container Aumento BomEstáticoRápida

Container Leve Aumento RuimDinâmicoLenta

Container Leve Aumento RazoávelDinâmicoMédia

Container Aumento BomDinâmicoRápidaAo vivo Redução RuimEstáticoLentaAo vivo Forte Redução RazoávelEstáticoMédiaAo vivo Redução BomEstáticoRápidaAo vivo Forte redução RuimDinâmicoLentaAo vivo Forte Redução BomDinâmicoMédiaAo vivo Redução BomDinâmicoRápida

A coluna Relação Tempo Mig. x Downtime agrupa e sintetiza os resultadosexpressos pelos gráficos que apresentam os percentuais relativos ao aumento ou reduçãodo tempo de downtime em relação ao tempo de migração (gráficos 6.25, 6.26 e 6.27). Acoluna Avaliação foi preenchida com base nos tempos médios de downtime durante o


processo de migração.A partir desta tabela é possível perceber que a hipótese desta pesquisa está em con-

formidade com os resultados apresentados, pois mesmo quando o tempo de downtimeainda é alto, por exemplo em uma migração ao vivo, com ponto dinâmico e rede lenta,a redução acentuada em relação ao tempo de migração melhora a QoE do usuário casosó exista essa possibilidade. No entanto, o melhor comportamento dos algoritmos se deuquando são executados em cenários com ponto de migração dinâmico e em redes rápi-das independentemente do tipo de migração escolhida. Vale destacar que a arquiteturaproposta é de fundamental importância para o bom funcionamento dos algoritmos. Deacordo com os testes, outras políticas e estratégias também mantém um bom nível deque QoE, princialmente as que são combinadas às redes rápidas, como por exemplo namigração de container, com ponto de migração estático e rede rápida.

Para as políticas com resultados não tão bons, a arquitetura prevê um mecanismo depré-migração para redes lentas ou com alta utilização, porém para fechar o escopo destadissertação, este mecanismo não foi implementado.

As estratégias utilizadas de escolha da próxima Cloudlet também apresentam bons emaus comportamentos. Os resultados das médias das latências de cinco usuários e tambémde todas as latências de um deles (quando as estratégias escolhem Cloudlets distintas)mostram que ao contrário do que se imaginava, uma estratégia com escolha da Cloudletque oferece menor latência não foi considerada muito boa. Isso se dá porque pode serescolhida uma Cloudlet a mais de um salto de rede, pois no momento da escolha todos oscustos associados a execução da aplicação poderiam estar melhor, porém isso pode mudarcaso, por exemplo esta mesma Cloudlet receba mais requisições. E corroborando com aliteratura, um único salto de rede seria melhor para manter o QoE em níveis aceitáveis eneste caso, os resultados encontrados para uma semente e um usuário na Etapa 1 foramconfirmados na etapa 2, ou seja, a estratégia que melhor se apresentou foi a escolhada próxima Cloudlet conectada ao AP mais perto do usuário, que possivelmente será aescolha do handoff.

Ao tratar do simulador MyiFogSim, pode-se dizer que sua implementação ainda de-pende da execução do CloudSim e iFogSim e que a sincronização de todos dos eventosnão é trivial, porém obteve-se um ambiente simples para executar as simulações.

Pensando ainda em fazer uma análise mais aprofundada nos aspectos que envolvem arede e a comunicação de dados, sugere-se que MyiFogSim execute de maneira integrada oNS-3 (Network Simulator 3) para se ter melhores parâmetros e resultados mais completosno final dos testes.

Capítulo 7

Considerações finais

Usuários e seus dispositivos móveis trouxeram um grande desafio para pesquisadores e em-presas provedoras de serviços de tecnologia nos últimos anos. Neste sentido, Fog Compu-ting estabelece uma infraestrutura que pode solucionar muitos destes desafios, oferecendoa infraestrutura capaz de suportar a alta demanda de processamento e tráfego geradospor diversos tipos de aplicações.

Esta dissertação trouxe como proposta uma arquitetura que suporte migrações de má-quinas virtuais dentro de uma névoa com o objetivo de manter a qualidade de experiênciade usuários alta durante sua mobilidade. A partir desta proposta inicial, foi desenvolvidoum estudo sobre os requisitos de migrações de máquinas virtuais, sobre os requisitos deusuários e quais destes requisitos uma névoa pode atender.

Os estudos trouxeram base teórica para a formulação das arquiteturas aqui propos-tas (topológica e em camadas) e para a criação dos algoritmos. No entanto, ainda eranecessário um simulador que suportasse esta estrutura, e partindo desta necessidade, Myi-FogSim foi implementando sobre CloudSim e iFogSim que já atendiam os componentesbásico para uma névoa, porém não atendiam os aspectos de migração máquinas virtuaisem névoa e nem sobre a mobilidade dos usuários.

Os primeiros testes confrontaram um cenário no qual um usuário móvel não tinha oserviço de migração ativo com um cenário em que as migrações ocorriam de acordo comsua necessidade. Os resultados obtidos a partir das latências durante a simulação e dasmédias destas latências confirmaram que se não houver a migração das máquinas virtuais,com o distanciar do usuário de sua conexão de origem, uma degradação das latências iriamocorrer durante este percurso.

A realização dos testes da segunda etapa tinha como objetivo a comparação entreas políticas e entre as estratégias de migração. Os resultados apontaram que em algunscasos, o processo de migração foi satisfatório para atender aos requisitos de baixa latênciade aplicações que executam em tempo real. Os melhores políticas são quando há redesrápidas e a utilização de pontos de migração dinâmico usando nas migrações ao vivo enas migrações de containers.

A escolha da próxima Cloudlet baseada na escolha do próximo AP após o handoffmanteve a média das latências em níveis baixos deixando a QoE dos usuários dentro doesperado. Além disso, esta estratégia se mostrou mais estável dentre as demais, pois elasempre manteve a máquina virtual a um salto de rede de distância, em oposição às outras

79

CAPÍTULO 7. CONSIDERAÇÕES FINAIS 80

estratégias que poderiam fazer escolhas de Cloudlets com mais de um salto para acesso àmáquina virtual.

Muitos outros aspetos e desafios desta arquitetura devem ainda ser implementadoscomo objetivo de se ter uma infraestrutura escalável que suporte de forma robusta e eficazas migrações de máquinas virtais, atendendo assim aos exigentes requisitos de aplicaçãode usuários que executam em tempo real.

7.1 Trabalhos Futuros

Para trabalhos futuros sugere-se:

• Inclusão de aspectos de segurança na arquitetura.

• A implementação dos componentes da arquitetura que ainda não estão prontos,como por exemplo: o mecanismo de pré-migração. A ideia é que, se o dispositivomóvel do usuário estiver em um AP de borda, a nuvem, com sua onisciência, enviariaum sinal para a possível próxima Cloudlet. Neste caso, as Cloudlets juntamente coma nuvem podem iniciar uma pré-migração para tentar dar agilidade ao processo demigração e consequentemente diminuir o tempo de downtime.

• A execução de testes com aplicações próximas a tempo real comparando novamenteas políticas e estratégias de migração.

• A execução de testes que aumentem e diminuam a angulação do cone da zona demigração para tentar achar um ângulo ideal ou próximo ao ideal.

• Um estudo para melhorar o desempenho das simulações, otimizando algumas partesdo núcleo de CloudSim e iFogSim, e correção do consumo de memória dos objetosde MyiFogSim.

Referências Bibliográficas

[1] Mohammad Aazam and Eui-Nam Huh. Fog computing and smart gateway ba-sed communication for cloud of things. In Proceedings of the 2014 InternationalConference on Future Internet of Things and Cloud, FICLOUD ’14, pages 464–470,Washington, DC, USA, 2014. IEEE Computer Society.

[2] N. Ahmad, A. Kanwal, and M.A. Shibli. Survey on secure live virtual machine (vm)migration in cloud. In Information Assurance (NCIA), 2013 2nd National Conferenceon, pages 101–106, Dec 2013.

[3] Arif Ahmed and Ejaz Ahmed. A survey on mobile edge computing. In IntelligentSystems and Control (ISCO), 2016 10th International Conference on, pages 1–8.IEEE, 2016.

[4] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz,Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and MateiZaharia. A view of cloud computing. Commun. ACM, 53(4):50–58, April 2010.

[5] G. Arunkumar and Neelanarayanan Venkataraman. A novel approach to addressinteroperability concern in cloud computing. Procedia Computer Science, 50:554 –559, 2015. Big Data, Cloud and Computing Challenges.

[6] Michael Till Beck, Martin Werner, Sebastian Feld, and S Schimper. Mobile edgecomputing: A taxonomy. In Proc. of the Sixth International Conference on Advancesin Future Internet. Citeseer, 2014.

[7] Luiz Fernando Bittencourt, Márcio Moraes Lopes, Ioan Petri, and Omer F Rana.Towards virtual machine migration in fog computing. In P2P, Parallel, Grid, Cloudand Internet Computing (3PGCIC), 2015 10th International Conference on, pages1–8. IEEE, 2015.

[8] Flavio Bonomi, Rodolfo Milito, Preethi Natarajan, and Jiang Zhu. Fog computing: Aplatform for internet of things and analytics. In Nik Bessis and Ciprian Dobre, editors,Big Data and Internet of Things: A Roadmap for Smart Environments, volume546 of Studies in Computational Intelligence, pages 169–186. Springer InternationalPublishing, 2014.

[9] Flavio Bonomi, Rodolfo Milito, Jiang Zhu, and Sateesh Addepalli. Fog computingand its role in the internet of things. In Proceedings of the First Edition of the MCC

81

REFERÊNCIAS BIBLIOGRÁFICAS 82

Workshop on Mobile Cloud Computing, MCC ’12, pages 13–16, New York, NY, USA,2012. ACM.

[10] Rodrigo N Calheiros, Rajiv Ranjan, Anton Beloglazov, César AF De Rose, and Raj-kumar Buyya. Cloudsim: a toolkit for modeling and simulation of cloud computingenvironments and evaluation of resource provisioning algorithms. Software: Practiceand experience, 41(1):23–50, 2011.

[11] Christopher Clark, Keir Fraser, Steven Hand, Jacob Gorm Hansen, Eric Jul, Chris-tian Limpach, Ian Pratt, and Andrew Warfield. Live migration of virtual machines.In Proceedings of the 2nd Conference on Symposium on Networked Systems Design& Implementation-Volume 2, pages 273–286. USENIX Association, 2005.

[12] Hoang T Dinh, Chonho Lee, Dusit Niyato, and Ping Wang. A survey of mobile cloudcomputing: architecture, applications, and approaches. Wireless communicationsand mobile computing, 13(18):1587–1611, 2013.

[13] Ivan Farris, Tarik Taleb, Miloud Bagaa, and H Flinck. Optimizing service replicationfor mobile delay-sensitive applications in 5g edge network. IEEE, 201:2017, 2017.

[14] Pedro Garcia Lopez, Alberto Montresor, Dick Epema, Anwitaman Datta, Teruo Hi-gashino, Adriana Iamnitchi, Marinho Barcellos, Pascal Felber, and Etienne Riviere.Edge-centric computing: Vision and challenges. ACM SIGCOMM Computer Com-munication Review, 45(5):37–42, 2015.

[15] Harshit Gupta, Amir Vahid Dastjerdi, Soumya K Ghosh, and Rajkumar Buyya.ifogsim: A toolkit for modeling and simulation of resource management techniquesin internet of things, edge and fog computing environments. arXiv preprint ar-Xiv:1606.02007, 2016.

[16] Kirak Hong, David Lillethun, Umakishore Ramachandran, Beate Ottenwälder, andBoris Koldehofe. Mobile fog: A programming model for large-scale applications onthe internet of things. In Proceedings of the Second ACM SIGCOMM Workshop onMobile Cloud Computing, MCC ’13, pages 15–20, New York, NY, USA, 2013. ACM.

[17] Bukhary Ikhwan Ismail, Ehsan Mostajeran Goortani, Mohd Bazli Ab Karim,Wong Ming Tat, Sharipah Setapa, Jing Yuan Luke, and Ong Hong Hoe. Evalua-tion of docker as edge computing platform. In Open Systems (ICOS), 2015 IEEEConfernece on, pages 130–135. IEEE, 2015.

[18] Qin Li, Jinpeng Huai, Jianxin Li, Tianyu Wo, and Minxiong Wen. Hypermip: Hyper-visor controlled mobile ip for virtual machine live migration across networks. In HighAssurance Systems Engineering Symposium, 2008. HASE 2008. 11th IEEE, pages80–88, Dec 2008.

[19] Haikun Liu, Cheng-Zhong Xu, Hai Jin, Jiayu Gong, and Xiaofei Liao. Performanceand energy modeling for live migration of virtual machines. pages 171–182, 2011.


[20] O. Osanaiye, S. Chen, Z. Yan, R. Lu, K. Choo, and M. Dlodlo. From cloud to fogcomputing: A review and a conceptual live vm migration framework. IEEE Access,PP(99):1–1, 2017.

[21] Rodrigo Roman, Javier Lopez, and Masahiro Mambo. Mobile edge computing, foget al.: A survey and analysis of security threats and challenges. Future GenerationComputer Systems, 2016.

[22] Mahadev Satyanarayanan, P. Bahl, R Caceres, and N. Davies. The case for vm-basedcloudlets in mobile computing. Pervasive Computing, IEEE, 8(4):14–23, Oct 2009.

[23] I. Stojmenovic. Fog computing: A cloud to the ground support for smart thingsand machine-to-machine networks. In Telecommunication Networks and ApplicationsConference (ATNAC), 2014 Australasian, pages 117–122, Nov 2014.

[24] I. Stojmenovic and Sheng Wen. The fog computing paradigm: Scenarios and securityissues. In Computer Science and Information Systems (FedCSIS), 2014 FederatedConference on, pages 1–8, Sept 2014.

[25] Petter Svärd, Benoit Hudzia, Steve Walsh, Johan Tordsson, and Erik Elmroth. Prin-ciples and performance characteristics of algorithms for live vm migration. SIGOPSOper. Syst. Rev., 49(1):142–155, January 2015.

[26] T. Taleb, S. Dutta, A. Ksentini, M. Iqbal, and H. Flinck. Mobile edge computingpotential in making cities smarter. IEEE Communications Magazine, 55(3):38–43,March 2017.

[27] Luis M. Vaquero and Luis Rodero-Merino. Finding your way in the fog: Towardsa comprehensive definition of fog computing. SIGCOMM Comput. Commun. Rev.,44(5):27–32, October 2014.

[28] Tim Verbelen, Pieter Simoens, Filip De Turck, and Bart Dhoedt. Cloudlets: Bringingthe cloud to the mobile user. In Proceedings of the Third ACM Workshop on MobileCloud Computing and Services, MCS ’12, pages 29–36, New York, NY, USA, 2012.ACM.

[29] William Voorsluys, James Broberg, Srikumar Venugopal, and Rajkumar Buyya. Costof virtual machine live migration in clouds: A performance evaluation. In Proceedingsof the 1st International Conference on Cloud Computing, CloudCom ’09, pages 254–265. Springer-Verlag, Berlin, Heidelberg, 2009.

[30] M. Yannuzzi, R. Milito, R. Serral-Gracia, D. Montero, and M. Nemirovsky. Keyingredients in an iot recipe: Fog computing, cloud computing, and more fog compu-ting. In Computer Aided Modeling and Design of Communication Links and Networks(CAMAD), 2014 IEEE 19th International Workshop on, pages 325–329, Dec 2014.

[31] Hong Yao, Changmin Bai, Deze Zeng, Qingzhong Liang, and Yuanyuan Fan. Migrateor not? exploring virtual machine migration in roadside cloudlet-based vehicular


cloud. Concurrency and Computation: Practice and Experience, 27(18):5780–5792,2015.

[32] Rong Yu, Yan Zhang, Stein Gjessing, Wenlong Xia, and Kun Yang. Towardcloud-based vehicular networks with efficient resource management. IEEE Network,27(5):48–55, 2013.

[33] John K Zao, Tchin Tze Gan, Chun Kai You, Sergio José Rodríguez Méndez, Cheng EnChung, Yu Te Wang, Tim Mullen, and Tzyy Ping Jung. Augmented brain computerinteraction based on fog computing and linked data. In Intelligent Environments(IE), 2014 International Conference on, pages 374–377. IEEE, 2014.

arquitetura e mecanismos para migração de máquinas ... · virtuais entre servidores que estejam...

Documents