Arquitetura e mecanismos para migração de máquinas virtuais na computação em névoa

(1)

Universidade Estadual de Campinas Instituto de Computação

INSTITUTO DE COMPUTAÇÃO

Márcio Moraes Lopes

Arquitetura e Mecanismos para Migração de Máquinas

Virtuais na Computação em Névoa

CAMPINAS

2017

(2)

Márcio Moraes Lopes

Arquitetura e Mecanismos para Migração de Máquinas Virtuais

na Computação em Névoa

Dissertação apresentada ao Instituto de Computação da Universidade Estadual de Campinas como parte dos requisitos para a obtenção do título de Mestre em Ciência da Computação, na área de Sistemas de Computação.

Orientador: Prof. Dr. Luiz Fernando Bittencourt

Este exemplar corresponde à versão final da Dissertação defendida por Márcio Moraes Lopes e orientada pelo Prof. Dr. Luiz Fernando Bittencourt.

CAMPINAS

2017

(3)

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

Ficha catalográfica

Universidade Estadual de Campinas

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

Lopes, Márcio Moraes,

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 fog

computing

Palavras-chave em inglês:

Cloud computing Virtual machines Algorithms

Quality of service (Computer networks) Mobile devices

Área de concentração: Ciência da Computação Titulação: Mestre em Ciência da Computação Banca examinadora:

Luiz Fernando Bittencourt [Orientador] Eduardo Coelho Cerqueira

Edmundo Roberto Mauro Madeira

Data de defesa: 12-07-2017

Programa de Pós-Graduação: Ciência da Computação

(4)

Universidade Estadual de Campinas Instituto de Computação

INSTITUTO DE COMPUTAÇÃO

Márcio Moraes Lopes

Arquitetura e Mecanismos para Migração de Máquinas Virtuais

na Computação em Névoa

Banca Examinadora:

• Prof. Dr. Luiz Fernando Bittencourt Universidade Estadual de Campinas • Prof. Dr. Eduardo Coelho Cerqueira

Universidade Federal do Pará

• Prof. Dr. Edmundo Roberto Mauro Madeira Universidade Estadual de Campinas

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

(5)

Agradecimentos

Agradeço primeiro a Deus por esta oportunidade e peço a Ele que continue sempre fazendo o 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 Ana Júlia e Marcela por terem me dado o suporte emocional necessário nos momentos difíceis e por terem suportado minha ausência durante esta jornada. Muito obrigado. Tudo que faç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 pelo amor e suporte dado à minha família quando estive ausente. Aos meus irmãos Luciane e César (carinhosamente chamados de Tia Lu e Tucésá) pelo amor e doação a mim e minha família. Amo vocês S2.

Aos meus pais de coração (sogro e sogra) Adão e Dirce, ao meu cunhado Frederico e sua esposa Renata, à minha cunhada Valquíria e seu noivo Fábio e às minhas sobrinhas Luanna, 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 em mim depositada, pelos ensinamentos, paciência e excelente suporte intelectual sempre que necessitei. Também gostaria de agradecê-lo pelo esforço no meu processo de ida o Canadá para executar parte desta pesquisa, pois certamente foi um fator decisivo para a aceitaçã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 que fiz 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 excelente convivência com juntamente com sua esposa Ana.

Agradeço também a minha locatária Laurie, que tornou-se minha amiga, pela sua paciê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!

(6)

Resumo

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

(7)

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 triggered the 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 latency service to these applications. However, the migration process is not straightforward and involves algorithms, data communication, and efficient strategies to avoid quality of ser-vice degradation. In this research, we propose a virtual machine migration architecture and algorithms in fog computing focused in the user’s quality of experience during their mobility. 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 experience has been maintained or improved. The results show that some policies and strategies are better than others to meet the requirement of these services.

(8)

Lista de Figuras

2.1 Hierárquica dos tipos de serviços oferecidos pela nuvem . . . 16

2.2 Arquitetura hierárquica entre Cloud e Fog Computing. . . 18

2.3 Arquitetura de Fog Computing com Cloudlets. . . 19

2.4 Conceito de virtualização de servidores . . . 21

2.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 . . . 33

5.2 Arquitetura em camadas para migração de máquinas virtuais . . . 34

5.3 Fluxograma simplificado da arquitetura de migração em Fog Computing . . 36

5.4 Fluxograma detalhado . . . 39

5.5 Cenário normal para uma migração de máquinas virtuais em Fog Computing 40 5.6 O pior cenário para migração de máquinas virtuais em Fog Computing . . 42

5.7 O melhor cenário para migração de máquinas virtuais em Fog Computing . 43 5.8 Cenário com problemas de rede . . . 44

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

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

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

5.12 Padrão de projeto strategy para MigrationDecision . . . 47

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

5.14 Padrão de projeto strategy para beforeMigration . . . 49

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

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

6.3 Comparação das latências para uma rede lenta entre não migrar e migrar . 55 6.4 Comparação das latências para uma rede média entre não migrar e migrar 55 6.5 Comparação das latências para uma rede rápida entre não migrar e migrar 56 6.6 Comparação das latências para uma rede lenta entre não migrar e migrar com e todas as estratégias . . . 56

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

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

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

6.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 (ponto estático). . . 59

(9)

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 (ponto

dinâ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 . . . 64

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

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

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

6.21 Média das latências de todos os usuários em uma rede lenta para dez usuários. 68 6.22 Média das latências de todos os usuários em uma rede média para dez usuários. . . 69

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

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

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

6.27 Comparação entre todos os tempos de downtime de todos os cenários com a rede rápida . . . 72

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

6.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. . . 74

6.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. . . 75

6.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

(10)

Lista de Tabelas

2.1 Comparação das características entre Cloud Computing e Edge Computing 17

2.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

(11)

Sumário

1 Introdução 12

2 Conceitos Básicos 15

2.1 Cloud vs Fog Computing (Edge Computing) . . . 15

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

3 Trabalhos Relacionados 23 4 MyiFogSim 28 4.1 Visão geral sobre CloudSim e iFogSim . . . 28

4.1.1 Cloud Computing Simulator . . . 28

4.1.2 Fog Computing Simulator . . . 29

4.2 Arquitetura do MyiFogSim . . . 30

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

5.1.1 Arquitetura topológica . . . 32

5.1.2 Arquitetura em camadas . . . 33

5.2 Algoritmo base . . . 36

5.2.1 Fluxogramas . . . 36

5.3 Cenários com migração e handoff . . . 40

5.3.1 Comentários gerais e outros cenários . . . 41

5.4 Técnica de migração . . . 44

5.4.1 Políticas de migração . . . 45

5.4.2 Estratégias de migração . . . 47

6 Simulações 51 6.1 Etapa 1: Diferença entre não migrar e migrar uma máquina virtual . . . . 53

6.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 . . . 58

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

6.4 Discussão . . . 76

7 Considerações finais 79 7.1 Trabalhos Futuros . . . 80

(12)

Capítulo 1

Introdução

Os seres humanos têm cada vez mais se tornado dependentes dos serviços que a Internet oferece. Tais serviços vão desde simples pesquisas cotidianas feitas por algum dispositivo de usuário (por exemplo smartphone) até o envio maciço de dados para processamento em grandes data centers para serem executados em milhares de servidores. Esta dependência faz com que pesquisadores no mundo inteiro produzam conhecimento para melhorar as té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 é o conceito de Cloud Computing (Computação em Nuvem) [8]. Este modelo pode ser descrito como 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 pessoas fí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 necessidade de grandes investimentos de capital financeiro para a aquisição, manutenção e gestão de tais 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 maior distribuiçã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 dos dispositivos [9].

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

(13)

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 da computação ubíqua1, que é a Internet of Things (IoT – Internet das Coisas) [1], onde quaisquer objetos (coisas) podem atuar como nós sensores e/ou que possuam algum tipo de 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árquica em três camadas, a saber: i) Dispositivos móveis, ii) Cloudlet e iii) Nuvem, onde as Cloudlets são formadas por um ou vários computadores que disponibilizam recursos aos dispositivos 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 é uma alternativa para as aplicações que demandam mais recursos de hardware. Neste sentido, a utilização de máquinas virtuais no contexto de Fog Computing também pode ser explorado com o objetivo de fornecer aos usuários um mecanismo capaz de oferecer a infraestrutura necessária para a execução de aplicações com o processamento em tempo real e baixa latência.

As máquinas virtuais em nuvem também são usadas para evitar desperdício de recursos de hardware neste tipo de infraestrutura, no entanto, muitas vezes os recursos de alguns servidores (ou todos) em uma determinada nuvem pode chegar ao limite e com isso surge a necessidade de migração para outros servidores (na mesma nuvem ou em outra) sem que haja perda de serviço ou de operabilidade de aplicações que estavam em execução de uma determinada 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 a latê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 a migraçã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, com migrações entre servidores de um mesmo data center.

Pensando nesse contexto, onde Fog Computing mantém Cloudlets geograficamente distantes, um usuário móvel pode ter dentro da névoa uma ou mais máquinas virtuas para “segui-lo” de Cloudlet -em-Cloudlet, através de migrações, durante o seu caminho e melhorar 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 virtuais deverã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áquinas virtuais para usuários móveis? Quais requisitos de QoS estabelecer para aplicações que 1_{Computação ubíqua: O termo Computação Ubíqua, foi definido pela primeira vez pelo cientista-chefe}

do Centro de Pesquisa Xerox PARC, Sr. Mark Weiser, através de seu artigo “O Computador do Século 21” (The Computer for the 21st Century ). Fonte: http://www.hardware.com.br/artigos/computacao-ubiqua/ Acessado em mai/2017.

(14)

CAPÍTULO 1. INTRODUÇÃO 14

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

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

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

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

3. Um simulador para validar a arquitetura e os algoritmos criados: implanta alguns componentes da arquitetura projetada, bem como executa os algoritmos e testes 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) Perguntas Problema, ii)Hipóteses, iii) Contribuições. O Capítulo 2 traz os conceitos básicos dos elementos desta pesquisa. O Capítulo 3 apresenta os trabalhos da literatura que estão relacionados e alinhados com esta pesquisa. O simulador é descrito no Capítulo 4. O Capítulo 5 descreve em detalhes a arquitetura e os algoritmos propostos. O Capítulo 6 descreve o ambiente dos testes e simulações e por fim, no Capitulo 7 são feitas as considerações finais ao trabalho.

(15)

Capítulo 2

Conceitos Básicos

Este capítulo tem como objetivo apresentar os conceitos básicos que serão discutidos durante esta dissertação. Esses conceitos são: Cloud Computing, Fog Computing, Clou-dlets, Edge Computing, Mobile Edge Computing, Mobile Cloud Computing, virtualização e 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 ganhado destaque tanto no mundo empresarial quanto no meio acadêmico. Este conceito é capaz de 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 mundo empresarial, grandes corporações que mantém data centers, com uma grande fazenda de servidores, oferecem seus serviços para outras empresas utilizarem como parte de suas infraestruturas em um modelo pay-per-use (pague pelo uso), onde o cliente paga pelo que usou dentro da nuvem, obtendo assim flexibilidade e elasticidade no uso dos recursos. Por outro lado, no mundo acadêmico, muitas pesquisas são apresentadas anualmente com o objetivo de otimizar plataformas, conceitos, serviços, acesso, consumo de energia, alocação de recurso etc.

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

Muitos podem ser os serviços que uma nuvem oferece. Estes serviços são basados em algum tipo de nível ou hierarquia no formato XaaS (Anything as a Service - Qualquer coisa 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 do provedor, tais como: i) Servidores, ii) Armazenamento e iii) Rede.

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

(16)

CAPÍTULO 2. CONCEITOS BÁSICOS 16

• O serviço oferecido é um nível intermediário para proporcionar capacidade de desenvolvimento de aplicações sem que os administradores de sistemas tenham que se preocupar com camadas mais abaixo, com por exemplo infraestrutura e sistemas 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ários não necessitam configurar suas aplicações para o uso. Normalmente, este tipo de serviço pode ser contratado por usuários comuns, sem a necessidade de pertencerem a alguma organização.

A Figura 2.1 mostra o modelo dos principais tipos de serviços oferecidos pela Cloud Computing. Na parte mais abaixo está o IaaS, onde é possível perceber que os principais atores são os administradores de redes. No nível intermediário, PaaS, os atores são os desenvolvedores de aplicações. No mais alto nível está o SaaS e os principais atores são os 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 inovador que 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évoa e, 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 processaexecuta-dos em um paradigma descentralizado chamado de Edge Computing, que basicamente consiste em trazer os dados para processamento para borda da rede. Neste sentido, nota-se que Fog Computing é uma instância de Edge Computing.

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

(17)

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

Requisitos Cloud Computing Edge Computing

Latênica Alta Baixa

Atraso Jitter Alto Muito baixo

Localização do Serviço Dentro da Internet Na borda Distância entre Clientes e servidores Múltiplos saltos Um salto

Onisciência na Localização Não Sim

Geo-distribuição Centralizada Distribuída

Suporte 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 do paradigma de Cloud Computing na borda da rede, permitindo assim uma nova geração de aplicações e serviços. Em resumo, os autores descrevem um conjunto de características que uma nuvem próxima aos usuários deve ter. Estas características estão enumeradas a seguir:

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 de computação, armazenamento e rede entre os dispositivos e a tradicional Cloud Computing em data centers, mas não exclusivamente localizada na borda da rede.”

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

(18)

Seção 2.2. A Figura 2.2 ilustra a relação entre a nuvem e a névoa. A nuvem está no topo de uma infraestrutura hierárquica, de forma centralizada, onde são disponibilizados di-versos recursos como processamento de alto desempenho e armazenamento. A névoa, por sua vez, está distribuída e oferece serviços que usualmente demandam menor capacidade computacional 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 aos dispositivos de IoT, que muitas vezes são heterogêneos.

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

A Figura 2.3 mostra um conjunto de Cloudlets formando uma Fog Computing. As Cloudlets 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, como por exemplo estado da rede, carga de processamento computacional, mecanismos para a migração de máquinas virtuais etc.

(19)

Figura 2.3: Arquitetura de Fog Computing com Cloudlets.

Importante ressaltar que cada névoa tem seu conjunto de Cloudlets e cada um desses conjuntos é responsável por algum tipo de serviço oferecido aos usuários finais. As Figuras 2.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 da névoa interagem com uma ou mais Cloudlets e por isso as aplicações de usuários devem ser disponibilizadas em todas elas. No entanto, esta disponibilização não precisa ser necessariamente simultânea, ou seja, os serviços de usuário podem estar ativos somente na Cloudlet a qual este usuário está diretamente conectado, uma vez que disponibilizar e sincronizar todos os dados de todos os usuários em todas as Cloudlets geraria um alto custo computacional e financeiro.

Por conta da mobilidade observada na Figura 2.3 e pela impraticabilidade de replicação e sincronização de todos os dados, a migração de máquinas virtuais é uma importante té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 apcaçõ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, MEC considera somente os dispositivos móveis fazendo o uso da Edge Computing. No mesmo sentido, [12] em 2009 introduz MCC como um paradigma que move o poder de processa-mento e armazenaprocessa-mento dos dispositivos móveis dos usuários e entrega para uma nuvem centralizada (não para a borda) executar tais tarefas. Porém, segundo [21], mais tarde outros 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 as visõ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, MEC e 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

(20)

estudo apresentado pelos autores onde é possível verificar as diferenças e semelhanças entres 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 Empresas

Privadas Desenvolvimento Borda da Rede Próximo à borda, borda Borda da rede, dispositivos Núcleo da rede

Hardware Servidores heterogêneos Servidores, dispositivos de usuários Servidores

Serviço Virtualização Virtualização, outros Virtualização

Arq. da rede N-camadas, descentralizado, distribuído Centralizado

Mobilidade Sim Não

Latência, Jitter Baixa Média

Onisciência Sim Não

Disponibilidade Alta

Escalabilidade Alta Média

Na primeira coluna observa-se as características estudadas e na primeira linha os paradigmas 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 apresentam diversas similaridades.

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

Em 1960 a IBM Corporation desenvolveu uma tecnologia de virtualização de recursos computacionais 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 chamada de Hypervisor entre o hardware físico e serviço virtualizado com o objetivo de controlar a execução, por exemplo, de vários sistemas operacionais simultaneamente em uma única máquina física. Ou seja, a virtualização de recursos computacionais cria a possibilidade de isolamento da carga de trabalho para que diferentes aplicações compartilharem os mesmos recursos 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 sistema operacional que controla o hardware diretamente. No modelo virtualizado existe a camada de virtualização (Hypervisor ) que separa o hardware físico de vários sistemas operacionais em execução simultaneamente. Os sistemas operacionais enviam/recebem os comandos para/do Hypervisor que por sua vez controla a máquina física diretamente.

(21)

Figura 2.4: Conceito de virtualização de servidores

Do ponto de vista de um sistema operacional sobre um Hypervisor ele controla o hardware virtualizado da mesma forma que faria se fosse uma máquina física real. Este hardware virtualizado é conhecido como máquina virtual. Um sistema de virtualização dentro de data centers deve ser bem gerenciado para que os recursos da infraestrutura computacional 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 de copiar de uma máquina virtual de um servidor físico para outro. Neste sentido, Voorsluys et al. [29] argumentam que uma máquina virtual pode ser usada para um melhor controle de dados, e que ao usar as técnicas de migração para outra localização (hardware) há a possibilidade de oferecer um serviço que melhora a capacidade de gerenciamento, desem-penho e aspectos de tolerância a falhas, garantindo assim flexibilidade, adaptabilidade e eficiê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 da má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 estes dois tempos também é importante para manter os recursos utilizados e disponibilizados equilibrados 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. De

forma simples, uma máquina virtual é desligada do servidor de origem, a sua imagem transferida e ligada novamente em outro servidor. De acordo com [11] esta técnica tem como vantagem sua simplicidade, porém pode gerar tempos indesejáveis de downtime e de migração.

• Migração sob demanda: É considerada como uma parada e cópia curta, pois somente 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 é adicionado para a separação dos dados. Esses dados essenciais são conhecidos por containers de 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

(22)

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, o tempo de downtime existirá, porém segundo [11], este tempo será muito menor se comparado 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ída e cada Cloudlet está centralizada, uma máquina virtual deve ficar disponível em outra Cloudlet sempre que o usuário mudar sua região geográfica e, consequentemente, mudar de cobertura. A Figura 2.5 ilustra este cenário.

(23)

Capítulo 3

Trabalhos Relacionados

Muitas pesquisas têm sido realizadas em torno de Fog Computing e IoT, principalmente a partir 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áquinas virtuais em Cloud Computing com diferentes contextos. Nesta seção serão apresentados alguns trabalhos para posicionar esta pesquisa em relação aos trabalhos presentes na literatura.

Em [9] são mostradas em detalhes as principais características de Fog Computing, as quais já foram listadas anteriormente. Mostra-se ainda uma relação intrínseca entre Fog Computing e IoT em três abordagens: i) Veículos conectados , ii) Grades inteligentes e iii) Redes de sensores em fio e atuadores. Como principal contribuição os autores trazem uma arquitetura de interação entre névoa e nuvem. Destaca-se que este artigo é um dos primeiros 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ça em Fog Computing e também exploram cenários como as grades inteligentes, rede de sensores sem fio, IoT e Software Defined Networks (SDN – Redes Definidas por Software). Outro ponto importante destacado é que enfatizam a necessidade dos usuários finais terem serviços que provejam baixa latência, a localização de conhecimento e a incorporação de QoS para aplicações de tempo real.

Em [1] é abordado um outro conceito similar à Fog Computing, chamado de Cloud of Things (CoT), que é uma integração/interligação entre IoT e Cloud Computing. O artigo apresenta um desafio envolvendo: i) o envio de dados para a nuvem, ii) os dispositivos de IoT, iii) um método de envio chamado Smart Gateway e iv) Fog Computing. Os autores afirmam ainda que o processamento dados não pode estar somente sob a responsabilidade dos 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 de IoT e mostram uma pesquisa baseada em uma relação entre mobilidade, controle confiável e atuação e escalabilidade, focalizando no cenário de IoT em grandes áreas geográficas e na 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 infraestrutura de roteadores. São expostos alguns cuidados que devem ser tomados com o surgimento de

(24)

CAPÍTULO 3. TRABALHOS RELACIONADOS 24

novas tecnologias, pois segundo os autores, existe uma tendência em se vulgarizar essas novas 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 Fog Computing, sua situação atual e uma série de desafios futuros. Os autores de [27] definem entã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, se comunicam e potencialmente cooperam entre si e com a rede para executar tarefas para atuar no armazenamento e processamento sem a intervenção de partes 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 fazer estes serviços.”

Outro ponto a se destacar em [27] é que os autores trazem aspectos importantes que pouco foram discutidos em outros trabalhos, como o gerenciamento de redes e serviços no contexto 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 como uma forma de produzir o gerenciamento de uma rede bem como dos serviços por ela oferecidos 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ção geográfica, aplicações de larga escala e aplicações que sejam sensíveis à latência. Outro ponto importante, considerado na pesquisa, é o conceito de PaaS que deve ser utilizado no modelo de programação com o objetivo de simplificar a abstração e suporte à aplicações escalá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 de eficiê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 virtuais sem o interrompimento de serviços usando técnicas de migração ao vivo de máquinas virtuais. No trabalho são apresentados problemas relacionados ao custo de migração considerando o desempenho e consumo de energia, tanto em termos teórico, como em termos práticos. As principais contribuições desse trabalho incluem a criação de um modelo para redução dos custos de migração das máquinas virtuais tanto para redes cabeadas como para redes sem fio. Os resultados encontrados mostram que a eficiência do 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 da memória na origem (memória suja) e taxa de transmissão da rede são os fatores de maior influê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 o hí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

(25)

consumo de recursos, iii) Robustez, iv) Previsibilidade e v) Transparência. Sobre esses critérios, os autores argumentam ainda que “fornecem um meio para descrever e comparar algoritmos de migração ao vivo” através de uma avaliação de desempenho de migração em algoritmos 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 quando a maior preocupação for a Robustez, caso contrário, os modelos pós-cópia e híbrido são altamente recomendados.

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

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

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

Em [20] são pesquisados alguns aspectos de virtualização em Fog Computing que incluem questões de segurança e privacidade nos serviços e recursos disponíveis. Mais ainda, 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 na migração ao vivo de máquinas virtuais. Este framework faz uma adaptação do algoritmo de pré-cópia de Xen. Os autores apresentam uma taxonomia para caracterizar dois tipos de aplicações em Fog Computing, a saber: i) aplicações em tempo real, ii) aplicações próximas a tempo real.

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

(26)

considerada. Nestes sentido, eles elencam que uma replicação de serviços proativa é uma estratégia promissora de migração para reduzir o tempo de downtime e garantir uma QoE satisfatória. No entanto, o provisionamento de réplicas em múltiplos nós aumenta o 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 de problemas lineares inteiros para minimizar a degradação de QoE devido a migração e o custo 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 um problema de baixo tempo de resposta e alto custo de comunicação do modelo Vehicular Cloud Computing (VCC1) apresentado em [32], pois [31] consideram que pode haver um custo de execução muito alto usando VCC uma vez que o tráfego em uma rede de longa distância pode ser elevado. Neste sentido, os autores de [31] propõem uma heurística de duas fases para minimizar o custo de migração de máquinas virtuais entre RSCs durante a movimentação dos veículos. A fase um consiste em um algoritmo para encontrar o menor caminho até o próximo nó sem violação da capacidade do link e a fase dois consiste em outro algoritmo baseado no custo de alocação da máquina virtual em uma RSC a partir do 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ível para 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 em que 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 a tomada 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 com a mobilidade do usuário. Durante os testes, nós levamos em consideração os três tipos principais de migração: migração tradicional (parada e cópia), migração de containers e migração ao vivo. Mais detalhes serão apresentados nos próximos capítulos.

A grande maioria dos trabalhos apresentados discutem conceitos, desafios e futuras direçõ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 de resultados. A Tabela 3.1 mostra um quadro comprativo entre estes principais trabalhos mais fortemente relacionados com esta dissertação.

1_{VCC é um paradigma similar a primeira visão de MCC, onde o processamento das aplicações é}

(27)

CAPÍTULO 3. TRABALHOS RELACIONADOS 27 T ab ela 3.1: Comparação dos princip a is trabalhos relacionados P aradigma Mobilidade Mecanismo de decisão Técnica de migração Aplicação Pró-ativ o T aleb et al. [26] MEC Sim Latência limite A o viv o de con tainers Video streaming Sim Osanaiy e et al. [20] F og Genérico Regressão linear A o viv o (pré-cópia) Em temp o real/pro x. temp o real Genérico F a rris et al. [13] MEC Sim Otimização de problemas lineares in teiros Con tainers Sensív el ao atraso Sim Y ao et al. [31] RSC Sim Custos do link e alo cação T rad ic ion al Não esp ecificado Sim Este trabalho F og Sim P on to de migração/zona d e Migração Con tainers, tradicional e ao viv o Em temp o real Sim

(28)

Capítulo 4

MyiFogSim

Este capítulo apresenta os componentes de CloudSim e iFogSim que dão a base para a execução do simulador MyiFogSim, os detalhes de seu projeto e implementação e os detalhes da integração com uma arquitetura para migração de máquinas virtuais em né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 para simular 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 desenvolvedores na indústria podem facilmente testar o desempenho de novos serviços e verificar se há ou nã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 entidades de 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 nuvens de 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 de CloudSim fez com que muitos outros simuladores fossem baseados neste framework, como por 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 CloudCloud-Sim, uma cloudlet é uma aplicação que é executada por uma máquina virtual dentro de um hospedeiro. Ou seja, o termo cloudlet em CloudSim não tem nenhuma relação com o paradigma de Cloudlet já discutida neste trabalho e adotada no contexto de computação em névoa.

(29)

CAPÍTULO 4. MYIFOGSIM 29

4.1.2 Fog Computing Simulator

Com o surgimento recente de paradigmas como Fog Computing e IoT, surgiu também a necessidade de criação de uma plataforma de avaliação de desempenho de recurso que estes conceitos oferecem. Pensando nisso, Gupta et al. [15] desenvolveram iFogSim, um simulador criado sobre CloudSim que é capaz de modelar uma névoa e dispositivos de IoT com o objetivo de medir o impacto das técnicas de gerenciamento de recursos em termos de 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 dos eventos entre os componentes de uma névoa e como contribuição, os desenvolvedores criam tais componentes neste novo simulador. Os principais componentes são instanciados pelas classes:

• 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 downlink são os principais atributos de FogDevice. Os métodos desta classe realizam tarefas específicas de uma névoa ou dispositivo de IoT responsáveis pelo processamento das tuplas recebidas.

• Tuple: Estende a classe Cloudlet1 _{de CloudSim. É a tupla gerada por um sensor e}

que será enviada para processamento em algum AppModule.

• Application: É projetada conforme um grafo acíclico direcionado (DAG - Directed Acyclic Graph) onde os vértices são os módulos de execução de chegada de uma tupla e as arestas são as dependências dos dados entre esses módulos. Esta classe cria 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) e gerar 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 recebiprocessa-das 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áfico em 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

(30)

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 e da necessidade um ambiente de simulação com estas características, durante esta pesquisa foi 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 os aspectos necessários para obter mobilidade dos dispositivos dos usuários, migração de máquinas virtuais (AppModule) e mecanismos de handoff de rede. Os detalhes deste novo núcleo são descritos a seguir.

A Figura 4.1 ilustra um diagrama de classes do núcleo de MyiFogSim. As classes escuras são providas por CloudSim e iFogSim e as classe claras são as principais classes criadas 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 plano cartesiano para posicionar todas as entidades instanciadas de uma simulação. Estas entidades podem ser os servidores de uma névoa, as antenas (access points) e os dispositivos dos usuários ou IoT. Os limites deste mapa podem ser configurados pelo desenvolvedor.

(31)

• ApDevice: Esta classe estende FogDevice do iFogSim e acrescenta características e responsabilidade de um access point de uma rede sem fio, como por exemplo o sistema de gerenciamento de handoffs e conexão e desconexão de dispositivos. • MobileDevice: Também é uma classe que estende FogDevice do iFogSim. O

principal objetivo com a criação desta classe é separar conceitualmente os servidores de uma névoa e os dispositivos de usuário ou IoT, pois em iFogSim ambos são instanciados por FogDevice. Com essa separação é possível manter características peculiares dos dispositivos de usuários ou IoT.

• MobileSensor: Um dispositivo de usuário pode ter mais de um sensor acoplado ao hardware e neste sentido esta classe estende Sensor de iFogSim. Em iFogSim o desenvolvedor necessita, caso necessário, criar vários objetos do tipo Sensor para compor um hardware. MobileSensor já mantém um conjunto de sensores bastando o desenvolvedor instanciar um único objeto e adicionar, quando necessário, mais sensores 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 desejada pelo pesquisador/desenvolvedor. As subclasses de MigrationStrategy são exemplos de classes abstratas criadas para o uso nesta dissertação e serão descritas em detalhes no 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ção de máquinas virtuais do CloudSim. Um método dentro da classe FogDevice é responsável por: i) desvincular todos os mapeamentos entre tuplas, AppModule, SmartThing e Ser-verCloudlet de origem e ii) vincular novamente os novos mapeamentos no SerSer-verCloudlet de destino.

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

Após a implementação dos componentes principais do MyiFogSim, que atendem aos requisitos 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ão descritos detalhadamente.

(32)

Capítulo 5

Migração de máquinas virtuais em Fog

Computing

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évoa para que a baixa latência na resposta de aplicações dos usuários móveis seja mantida e a QoE 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ários móveis. Esta seção apresenta todos os componentes da arquitetura proposta em duas principais abordagens: i) uma arquitetura topológica de alto nível e ii) uma arquitetura em 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 um projeto Top-Down, uma topologia hierárquica completa em três camadas principais. No topo 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ções suficientes para a otimização de futuras migrações das máquinas virtuais.

(33)

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 camada de software para separação dos contextos das diversas aplicações que executam sobre a nuvem 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 Cloudlets associadas à névoa. Estas Cloudlets oferecem algum serviço ao dispositivos de IoT e manté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 das máquinas virtuais. Os principais componentes desta central de migração serão detalhados na 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 um usuário móvel pode fazer um processo de handoff para um outro AP que está conectado a 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 arquiarqui-tetura em camadas com os componentes necessá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 camadas desta arquitetura, a saber: i) Dispositivos móveis, ii) Cloudlets e, iii) Nuvem

(34)

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 em execução nos dispositivos móveis que se comunicam com as camadas inferiores (Cloudlets e Cloud ). Os componentes desta arquitetura são descritos em aspectos gerais e de alto ní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 de sincronização entre a replicação, criação e/ou exclusão de dados durante o processo de migração.

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

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

(35)

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ção e é responsável pelas decisões de mobilidade entre as Cloudlets aptas a receber as máquinas virtuais.

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

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

5. Sincronização: Comportamento similar ao módulo Sincronização na camada dos dispositivos 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 comparar com 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 foram os componentes implementados.

Tabela 5.1: Componentes implementados da arquitetura

Componentes Proporção da implementação

Offloading Parcial

Monitoramento Parcial

Descoberta de Cloudlets e sincronização Mínimo

Migração de aplicação Parcial

Comportamento de mobilidade Total

Migração de máquinas virtuais Total

Monitoramento de QoS Mínimo

Análise de custo Mínimo

Sincronizaçã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ém do mínimo, foi necessário algo mais elaborado, mas ainda faltam partes a implementar. Total significa que o componente foi implementando em sua totalidade.

(36)

5.2 Algoritmo base

Os algoritmos propostos nesta dissertação foram baseados em um fluxograma com a ideia geral 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ós esta elaboração, imaginou-se cenários que podem ocorrer em um ambiente real que serão descritos na Seção 5.3. Os algoritmos são propostos por meio de técnicas de migração que sã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 um algoritmo de migração em Fog Computing. A Figura 5.3 mostra os componentes para a tomada 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ão de 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 algum sistema que faz migração propriamente dita (transmissão através da rede).