Eder Paulo Pereira - repositorio.ufsm.br
81
UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO Eder Paulo Pereira SMARTFOGLB: BALANCEAMENTO DE CARGA NA COMPUTAÇÃO EM NÉVOA Santa Maria, RS 2020
Transcript of Eder Paulo Pereira - repositorio.ufsm.br
UNIVERSIDADE FEDERAL DE SANTA MARIACENTRO DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
Eder Paulo Pereira
SMARTFOGLB: BALANCEAMENTO DE CARGA NACOMPUTAÇÃO EM NÉVOA
Santa Maria, RS2020
Eder Paulo Pereira
SMARTFOGLB: BALANCEAMENTO DE CARGA NA COMPUTAÇÃO EM NÉVOA
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação (PGCC)da Universidade Federal de Santa Maria (UFSM,RS), como requisito parcial para obtenção do tí-tulo de Mestre em Ciência da Computação.
Orientadora: Prof. Dra. Roseclea Duarte Medina
Co-orientador: Prof. Dr. Edson Luiz Padoin
Santa Maria, RS
2020
Pereira, Eder Paulo
SmartFogLB: Balanceamento de Carga na Computação em Névoa/ por Eder Paulo Pereira. – 2020.
80 f.: il.; 30 cm.
Orientadora: Roseclea Duarte MedinaCo-orientador: Edson Luiz PadoinDissertação (Mestrado) - Universidade Federal de Santa Maria,
Centro de Tecnologia, Pós-Graduação em Ciência da Computação , RS,2020.
1. Computação em névoa. 2. Internet das coisas. 3. Balancea-mento de carga. I. Duarte Medina, Roseclea. II. Luiz Padoin, Edson.III. Título.
c© 2020Todos os direitos autorais reservados a Eder Paulo Pereira. A reprodução de partes ou do tododeste trabalho só poderá ser feita mediante a citação da fonte.E-mail: [email protected]
AGRADECIMENTOS
Uma seção de agradecimentos torna-se algo desafiador. Isto porque, muitas pessoascontribuíram para que eu viesse a realizar esta conquista, tanto direta quanto indiretamente.Mesmo assim, irei esforçar-me para tentar relembrar todos os nomes envolvidos nesta cami-nhada. Agradeço primeiramente à Deus. Não fosse por ele, nada disso teria acontecido. Acre-dito que tudo é obra d’Ele, e se cheguei aqui, foi por sua permissão. Por ter dado o fôlego devida, sabedoria, paciência e tantos outros atributos para conquistar esta vitória. À minha fa-mília. À minha esposa Cristina Rupp Pereira. Por ter me apoiado em todas as decisões, por sercompanheira para todas as horas, por suportar minhas crises existenciais, por sua sabedoriae ao mesmo tempo sua ingenuidade. Ao seu lado, o caminho tornou-se mais leve. Obrigado,minha querida, por suportar a distância nos meses iniciais. Esta conquista também é sua. Aosmeus pais, Aristeu e Clenir. Pelo incentivo, pelas palavras de conforto. Por me ensinarem anão desistir na primeira dificuldade. Pelo homem que sou, devo muito à vocês. Meus sogros,Egon e Marina, por todo apoio fornecido nestes 2 anos, por cuidarem da Cristina enquantoeu estava longe. Aos meus irmãos, cunhados, pois ajudaram indiretamente nesta caminhada.Aos meus professores. Roseclea Duarte Medina, uma pessoa incrível que a vida permitiu-meconhecer. Uma mulher de fibra, batalhadora e muito sábia. Por todos os momentos de orien-tação, pelas palavras de conforto quanto das crises. Pelos puxões de orelha, pelas correções,por tudo profe, a senhora será lembrada para sempre. Ao meu professor Edson Luiz Padoin.Obrigado professor, pelas orientações, por acreditar no meu trabalho, mesmo quando eu desa-creditei. Por ser quem és, fizeste a diferença para mim durante minha graduação e mestrado.Ao GRECA - Grupo de Redes e Computação Aplicada, aos colegas de mestrado, aos colegasde iniciação científica. À todos vocês eu gostaria de registrar meus sinceros agradecimentospor todos os aprendizados obtidos neste período. Aos demais, que porventura tenha esquecido,queria agradecer também. Talvez sua ajuda foi mínima pra você, mas para mim possa tersignificado muito. Obrigado!
“A mente é fogo a ser aceso, não umvaso a preencher”
(PLUTARCO)
RESUMO
SMARTFOGLB: BALANCEAMENTO DE CARGA NA COMPUTAÇÃO EM NÉVOA
AUTOR: EDER PAULO PEREIRAORIENTADORA: ROSECLEA DUARTE MEDINA
CO-ORIENTADOR: EDSON LUIZ PADOIN
A Computação em Névoa, caracteriza-se como uma extensão da Computação em Nu-vem para a borda da rede. Tal paradigma, portanto, não exclui a Nuvem, mas a complementa,preenchendo lacunas como tempo de resposta mais baixo e também menor utilização de links deinternet. Este paradigma vem ao encontro das necessidades impostas pelas aplicações de Inter-net das Coisas, as quais, muitas vezes, possuem restrições de baixos tempos de processamento,privacidade, prioridade, largura de banda, dentre outros.
Considerando a grande quantidade de coisas inteligentes necessitando de capacidadescomputacionais e a demanda crescente de aplicações de Internet das Coisas, os nodos que com-põem a Computação em Névoa tendem a ficar sobrecarregados. Consequentemente, os temposde resposta das aplicações de Internet das Coisas que possuem restrições são afetados. Nestesentido, um dos principais desafios para prover menores tempos de resposta para tais aplica-ções é a distribuição das tarefas de Internet das Coisas entre os nodos do nevoeiro. Para tanto,propor estratégias de balanceamento de carga para este novo paradigma passam a ser uma alter-nativa para aumentar a disponibilidade dos recursos computacionais na névoa, principalmenteconsiderando este como um ambiente dinâmico.
Para atenuar este problema, este trabalho apresenta uma abordagem de balanceamentode carga, que almeja reduzir o tempo de processamento das tarefas nos nodos do nevoeiro.Nossa proposta toma decisões em tempo real considerando a dinamicidade e heterogeneidadedo ambiente e utilização de CPU Memória, Armazenamento, Rede dos nodos e Prioridade datarefas.
Com o objetivo de validar a efetividade da abordagem proposta, foi organizado um am-biente de simulação. Para tanto onde comparou-se este trabalho com algumas abordagens debalanceamento de carga, como Round-Robin e também sem balanceador. Os resultados mos-tram que as tarefas de alta prioridade consomem o menor tempo de resposta possível no ambi-ente, seja de processamento ou na fila, o que traz à tona a efetividade da solução proposta. Omecanismo de fila baseado em prioridade mostrou-se um importante componente da solução, oqual analisa e reorganiza a fila de tarefas baseado em suas prioridades.
Palavras-chave: Computação em névoa. internet das coisas. balanceamento de carga.
ABSTRACT
SMARTFOGLB: AN LOAD BALANCING APPROACH IN FOG COMPUTING
AUTHOR: EDER PAULO PEREIRAADVISOR: ROSECLEA DUARTE MEDINA
COADVISOR: EDSON LUIZ PADOIN
Fog Computing is characterized as an extension of Cloud Computing to the edge of thenetwork. Such a paradigm, therefore, does not exclude the Cloud, but complements it, fillinggaps such as lower response time and also less use of internet links. This paradigm meets theneeds imposed by the Internet of Things applications, which often have restrictions on lowprocessing times, privacy, priority, bandwidth, among others.
Considering the growing and diverse demand for Internet of Things applications, thenodes that compose the Fog Computing tend to be overloaded, given the large number of smartthings requiring computational capabilities, such as processing, storage, networking, amongothers. Consequently, overloaded computational nodes compromise the response times of IoTapplications that have restrictions for the shortest possible time. In this sense, the main chal-lenge to provide the shortest response time for such applications is the distribution of tasksbetween the fog nodes. However, the availability of computational resources in the fog must beconsidered since it is characterized as a dynamic environment to perform load balancing in thisnew computing paradigm.
To alleviate the response time problem, this work presents a load balancing approachthat aims to reduce the processing time of the tasks in the fog nodes. The distribution of tasksbetween the Nodes of the Fog was carried out through dynamic load balancing in real time,whose contribution is therefore the load balancing algorithm that takes into account the dynam-ics and computational heterogeneity of the environment, as well as the sudden changes in theindexes use of computational resources, which associates tasks more appropriately.
To prove the effectiveness of the proposed solution, a simulation environment was or-ganized, where this work was compared with some load balancing approaches, such as Round-Robin and also without a balancer. The results show that high priority tasks consume the short-est possible response time in the environment, either in processing or in the queue, which bringsout the effectiveness of the proposed solution. The priority-based queuing mechanism provedto be an important component of the solution, which analyzes and reorganizes the task queuebased on its priorities.
Keywords: Fog computing. internet of things. load balancing.
LISTA DE FIGURAS
Figura 1 – Aplicações Tradicionais de Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figura 2 – Domínios de aplicação da Internet das Coisas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Figura 3 – Relatório da Gartner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figura 4 – Gerenciamento de Máquinas Virtuais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figura 5 – Arquitetura da Computação em Névoa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Figura 6 – Diagrama da Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 7 – Arquitetura Balanceador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figura 8 – Diagrama UML do Ambiente de Simulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figura 9 – Criação de Servidor Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Figura 10 – Criação de Servidor Virtual: Escolha do Sistema Operacional . . . . . . . . . . . . . . 49Figura 11 – Criação de Servidor Virtual: Escolha dos Recursos Computacionais . . . . . . . . 50Figura 12 – Tempos de Resposta com Nodos Pequenos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Figura 13 – Tempos de Resposta com Nodos Médios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figura 14 – Tempos de Resposta com Nodos Grandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figura 15 – Tempos de Resposta com Nodos Pequenos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 16 – Tempos de Resposta com Nodos Médios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Figura 17 – Tempos de Resposta com Nodos Grandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Figura 18 – Tempos de Resposta com Nodos Pequenos - Baixa Prioridade . . . . . . . . . . . . . . 59Figura 19 – Tempos de Resposta com Nodos Médios - Baixa Prioridade . . . . . . . . . . . . . . . . 60Figura 20 – Tempos de Resposta com Nodos Grandes - Baixa Prioridade . . . . . . . . . . . . . . . 61Figura 21 – Tempos de Resposta com Nodos Pequenos - Alta Prioridade . . . . . . . . . . . . . . . 62Figura 22 – Tempos de Resposta com Nodos Médios - Alta Prioridade . . . . . . . . . . . . . . . . . 63Figura 23 – Tempos de Resposta com Nodos Grandes - Alta Prioridade . . . . . . . . . . . . . . . . . 64Figura 24 – Tempos de resposta para 100 requisições, nodos pequenos . . . . . . . . . . . . . . . . . . 65Figura 25 – Tempos de resposta para 500 requisições, nodos pequenos . . . . . . . . . . . . . . . . . . 66Figura 26 – Tempos de resposta para 1000 requisições, nodos pequenos . . . . . . . . . . . . . . . . 67Figura 27 – Tempos de resposta para 100 requisições, nodos médios . . . . . . . . . . . . . . . . . . . . 67Figura 28 – Tempos de resposta para 500 requisições, nodos médios . . . . . . . . . . . . . . . . . . . . 68Figura 29 – Tempos de resposta para 1000 requisições, nodos médios. . . . . . . . . . . . . . . . . . . 68Figura 30 – Tempos de resposta para 100 requisições, nodos grandes . . . . . . . . . . . . . . . . . . . 69Figura 31 – Tempos de resposta para 500 requisições, nodos grandes . . . . . . . . . . . . . . . . . . . 69Figura 32 – Tempos de resposta para 1000 requisições, nodos grandes . . . . . . . . . . . . . . . . . . 70
LISTA DE TABELAS
Tabela 1 – Comparativo dos Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Tabela 2 – Configuração das Tarefas usadas na simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Tabela 3 – Definição dos nodos da Camada de Borda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Tabela 4 – Testes Realizados na Simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Tabela 5 – Resumo dos dados da simulação em todos os ambientes . . . . . . . . . . . . . . . . . . . . 70
LISTA DE ABREVIATURAS E SIGLAS
SmartFogLBSmart Load Balancing for Fog Computing Environment
FC Fog Computing
LB Load Balancer
IoT Internet of Things
RAM Random Access Memory
BC Balanceamento de Carga
IP Internet Protocol
URI Uniform Resource Identifier
SDN Software Defined Network
RR Round-Robin
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1 PROBLEMA DE PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3 OBJETIVOS E CONTRIBUIÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 CONSIDERAÇÕES DO CAPÍTULO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1 INTERNET DAS COISAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 COMPUTAÇÃO EM NUVEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 COMPUTAÇÃO EM NÉVOA (FOG COMPUTING) . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4 BALANCEAMENTO DE CARGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.5 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.5.1 Abordagem Centralizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.5.2 Abordagem Distribuída . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.6 CONSIDERAÇÕES DO CAPÍTULO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1 SMARTFOGLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.1 Camada de Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.2 Camada de Borda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.3 Camada das Aplicações IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 BALANCEADOR DE CARGA (BC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.1 Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3 CONSIDERAÇÕES DO CAPÍTULO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1 CONFIGURAÇÃO DAS TAREFAS DOS CONSUMIDORES DE RECURSOS 454.2 CONFIGURAÇÃO DOS NODOS COMPUTACIONAIS DE BORDA . . . . . . . . . 464.3 AMBIENTE DE SIMULAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1 EXPERIMENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 ANÁLISE DOS RESULTADOS EM UM CENÁRIO SEM BALANCEADOR
DE CARGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.3 ANÁLISE DOS RESULTADOS EM UM CENÁRIO COM O ALGORITMO
ROUND-ROBIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.4 ANÁLISE DOS RESULTADOS EM UM CENÁRIO COM O ALGORITMO
PROPOSTO SMARTFOGLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.5 CONSIDERAÇÕES DO CAPÍTULO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.1 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
12
1 INTRODUÇÃO
Vive-se em uma era da informação rápida, das pessoas cada vez mais conectadas, de
coisas inteligentes as quais interagem com os ambientes e as pessoas. Estes avanços na área
da computação nos últimos anos trazem à tona o grande potencial que a mesma pode oferecer
se for aplicada de forma correta nos mais variados campos de aplicação, com o objetivo de
melhorar a qualidade de vida das pessoas.
A miniaturização dos dispositivos eletrônicos tem subsidiado o desenvolvimento de con-
ceitos e paradigmas computacionais, por exemplo a Computação Ubíqua e IoT (Internet das
Coisas) (GARCIA; ALMENDRA FREITAS, 2019). Estes paradigmas destacam-se especial-
mente pela característica de utilização de pequenos dispositivos eletrônicos, os quais possuem
funções bem definidas para realizar tarefas específicas. A finalidade destes mini-dispositivos é
diversa, todavia, observa-se um aumento exponencial nos dispositivos inteligentes com algum
tipo de conexão com a rede, portanto, isto tem trazido um aumento nas funcionalidades dos
mesmos. Na época em que vivemos, observa-se que, salvo exceções, perde-se o sentido de um
novo dispositivo não possuir algum tipo de conectividade com a rede.
Dado o tamanho reduzido destes novos equipamentos, prover capacidades computacio-
nais torna-se um verdadeiro desafio, uma vez que além do pequeno espaço disponível, via de
regra estes dispositivos são alimentados por bateria. Em função das limitações de poder compu-
tacional, tais dispositivos necessitam de apoio de alguma estrutura de rede ou servidores. Para
estes casos, tais paradigmas são apoiados por unidades de processamento com recursos para tal,
via de regra o paradigma de Computação em Nuvem, uma vez que o armazenamento e proces-
samento das informações torna-se inviável em sensores e atuadores, uma vez que estes possuem
restrições computacionais.
O paradigma de Internet das Coisas mostra-se cada vez mais com ampla utilização nos
mais diversos contextos, como a área da saúde, por exemplo, a qual pode tirar proveito deste
novo paradigma no monitoramento proativo dos pacientes em um hospital. Salas de aula inteli-
gentes podem automatizar o processo de verificação dos alunos em sala, bem como automação
e integração com sistemas em Nuvem para uso futuro dos dados. Máquinas autônomas já efe-
tuam a colheita de grãos sem a necessidade de intervenção humana para tal. Cada vez mais,
a Internet das Coisas possibilita aos dispositivos físicos a ver, sentir, ouvir e pensar, realizar
tarefas baseado nos sinais capturados no ambiente em que os mesmos encontram-se inseridos.
13
Figura 1 – Aplicações Tradicionais de Internet das Coisas
Fonte: AUTOR
Uma vez que a Internet das Coisas vem ganhando muita atenção da academia e indústria,
percebe-se o aumento na quantidade de dispositivos inteligentes, os quais geram informações
dos mais variados tipos, onde as mesmas podem ser rapidamente visualizadas em smartphones
ou dashboards, muitas delas em ambientes de alta complexidade, como dados de saúde de
um paciente. É previsto que em 2022, 45% de todo o tráfego de Internet no mundo será entre
máquinas autônomas através de Machine-to-Machine, ou seja, existe uma grande expectativa de
crescimento ainda mais das coisas inteligentes que irão sensorear ambientes, gerar ou consumir
informações, seja no volume de dados consequência deste crescimento (AL-FUQAHA et al.,
2015).
Visto que a Computação em Nuvem oferece seus recursos computacionais sob demanda
para o usuário, este paradigma preenche a lacuna da restrição computacional imposta pelos dis-
positivos inteligentes. Portanto, o mesmo vem a atuar em uma camada superior, como mostra a
Figura 1, a qual recebe e processa os dados oriundos das mais diversas aplicações de Internet das
Coisas, como transporte, saúde, campus e cidades inteligentes, e armazenamento permanente
dos mesmos para recuperação futura.
Todavia, o crescimento e desenvolvimento tecnológico proporciona novas formas para
que os objetos inteligentes consigam realizar suas tarefas computacionais de maneira mais efici-
ente. As demandas das aplicações também estão mais exigentes, no sentido de que os sistemas
atuais precisam estar cada vez mais rápidos e disponíveis com as informações quando o usuá-
14
rio as requer. Neste sentido, mudanças repentinas na quantidade de requisições aos sistemas
computacionais precisam ser prontamente acomodadas, o que dá dinamicidade e elasticidade
ao ambiente computacional. Estas características, portanto, são bem conhecidas e intrínsecas
no paradigma de Computação em Nuvem.
Embora a Computação em Nuvem tende a preencher a lacuna da ausência de recursos
computacionais dos sensores da Internet das Coisas, ainda tem-se uma preocupação com a de-
manda de rede. A despeito disso, mesmo a Nuvem tendo recursos computacionais ad-infinitum,
os dados gerados pelos sensores da Internet das Coisas precisam trafegar pela rede, passar por
toda a pilha de protocolos envolvidos no caminho, tipos de rede, meios físicos diferentes, até
alcançar seu destino. Entretanto, tal abordagem, com sensores de Internet das Coisas na parte
inferior e servidores em Nuvem na parte superior, tem se mostrado efetiva. Porém, algumas
aplicações de Internet das Coisas podem requerer um menor tempo de resposta, como aplica-
ções de realidade aumentada, veículos autônomos, campus inteligentes, saúde, e outros. Sendo
assim, esta abordagem outrora eficiente, pode não atender este requisito de menores tempos
de reposta, uma vez que a distância física entre os dispositivos tende a provocar um atraso na
entrega dos pacotes, e consequentemente, comprometer o resultado final das aplicações, o que
gera uma lacuna em aberto para pesquisa (MOURADIAN et al., 2017).
Com o propósito de preencher esta lacuna, o paradigma de Computação em Névoa é
proposto (BONOMI et al., 2012), a qual atua em um nível abaixo da Computação em Nuvem e
acima da Internet das Coisas, na borda da rede, posicionando-se, portanto, entre a Nuvem e os
dispositivos finais da Internet das Coisas. Sendo assim, a presença de recursos computacionais
na borda da rede, próxima dos sensores de aplicações de Internet das Coisas, visa atenuar os
altos tempos de respostas para aplicações que possuem tais restrições. Portanto, como vanta-
gem deste novo paradigma, destaca-se uma diminuição nos tempos de resposta para com os
sensores e atuadores da Internet das Coisas. Outra vantagem visível neste paradigma, é a dimi-
nuição no consumo de largura de banda de Internet, uma vez que estes dispositivos passam a
enviar os seus dados para os nodos que compõem o nevoeiro, e não para a Nuvem. Embora este
novo paradigma computacional foi proposto em 2012, muito tem a ser feito ainda. Em 2015
várias empresas de tecnologia fundaram o OpenFog Consortium Reference Architecture (CON-
SORTIUM et al., 2017), com o intuito de promover padrões e protocolos para este paradigma,
juntando-se, em 2018, com a Industrial Internet Consortium 1.
1 https://www.iiconsortium.org/
15
Sendo assim, percebe-se a contribuição da Computação em Névoa para com a Internet
das Coisas. Dada a previsão da quantidade cada vez maior de dispositivos inteligentes, a Névoa
atua como uma espécie de ’represa’ dos dados, a qual traz a principal vantagem de diminuir os
tempos de resposta, bem como também diminuir o uso excessivo de links de Internet. Portanto,
este novo paradigma agrega os dados oriundos da Internet das Coisas, trata os mesmos e os
envia aos servidores na Nuvem quando conveniente.
1.1 PROBLEMA DE PESQUISA
Uma vez que a Computação em Névoa define-se como uma extensão da Computação
em Nuvem, alguns problemas deste último podem vir a migrar para a borda da rede. O fato
da computação em névoa ser um ambiente distribuído e dinâmico, demanda uma forma de co-
ordenação dos seus recursos computacionais, para a correta utilização dos mesmos por parte
das aplicações que irão adotá-los. Nós de névoa podem começar a participar e deixar o sistema
distribuído logo em seguida, o que exige o constante monitoramento dos nodos restantes para
alocar as tarefas. Dada a característica de ser um ambiente heterogêneo e distribuído, no sentido
de recursos computacionais, uma abordagem estática não condiz com a realidade desta arquite-
tura. Dito isto, o gerenciamento de seus recursos computacionais torna-se necessário, para fins
de escalabilidade, pilar destacado no documento do OpenFog Consortium (CONSORTIUM
et al., 2017) e para fins de alocação de tarefas entre seus nodos computacionais.
Portanto, o balanceamento de carga, embora um tema de computação relativamente con-
solidado em muitas áreas, ganha um papel fundamental neste novo paradigma. Todavia, a forma
de alocação de tarefas entre os nodos necessita de uma atenção especial neste cenário, uma vez
que tem-se uma grande variedade de nodos e recursos computacionais disponíveis, heteroge-
neidades de protocolos e afins. Abordagens de balanceamento estáticas performam melhor em
ambientes homogêneos, porém, esta não condiz com uma descrição adequada no nevoeiro. Por
outro lado, uma abordagem de balanceamento de carga dinâmica que leve em consideração a
saúde dos nodos em tempo real torna-se crucial para o bom funcionamento deste sistema. Esta
abordagem objetiva manter os tempos de respostas baixos, para aplicações que possuem tais
restrições; também, através da associação de prioridades, pode-se aliviar a carga de trabalho
no nevoeiro, através do envio de tarefas de baixa prioridade para a Nuvem, com o objetivo de
manter apenas o que é urgente utilizando o processamento na camada do nevoeiro.
Sendo assim, quanto mais nodos computacionais participarem do aglomerado do nevo-
16
eiro, mais recursos o mesmo vai ter para atender as requisições das aplicações de Internet das
Coisas. Uma vez que estes nodos são heterogêneos, no sentido de possuir diferentes recursos
computacionais, como quantidade de unidades de processamento, memória, armazenamento e
rede, estas características necessitam de uma atenção especial para que o agendador de tarefas
realize a alocação das mesmas de forma correta, que leve em consideração a prioridade destas
tarefas. Caso o nodo que forma o nevoeiro esteja sobrecarregado, o mesmo precisa notificar uma
entidade que tenha uma visão holística de todo o sistema para que o mesmo provisione nodos
computacionais para cooperar no processamento dos dados, e quando for o caso, encaminhar
tarefas de baixa prioridade para que sejam processados na Nuvem.
1.2 JUSTIFICATIVA
A alocação de tarefas, assim como na Nuvem, executa um papel fundamental para dimi-
nuir o tempo de resposta e aumentar a vazão do sistema distribuído, com interferência mínima
sobre as aplicações que irão utilizá-lo. Contudo, soluções que funcionam de forma adequada
na Computação em Nuvem, não necessariamente podem ser efetivas neste novo paradigma da
Névoa, dada a sua singularidade. Balanceadores de carga centralizados performam bem, mas
possuem restrições de escalabilidade. Por outro lado, balanceadores distribuídos escalam em
ambientes grandes, mas possuem seu custo computacional elevado para que seja feito o con-
senso entre os nodos. Assim, com este objetivo esclarecido, a forma de evitar altos tempos de
resposta, o que pode comprometer as aplicações de tempo real, pode ser mitigada através da
alocação de tarefas entre os vários nodos computacionais, de forma transparente ao usuário,
a qual leva em consideração a disponibilidade de recursos computacionais de cada nodo que
compõem o nevoeiro.
1.3 OBJETIVOS E CONTRIBUIÇÕES
Este trabalho tem como principal objetivo diminuir os tempos de respostas das aplica-
ções de Internet das Coisas, uma vez que a sobrecarga iminente dos sensores e atuadores que
compõem a IoT podem levar os nodos computacionais do nevoeiro à esgotar seus recursos. Para
isto, utilizar-se-ão as técnicas de balanceamento de carga entre estes nodos, com o intuito de
prover tempos de respostas mais baixos e auto-adaptação às mudanças repentinas no ambiente.
Sendo assim, as principais contribuições deste trabalho são:
17
• Propor um modelo arquitetural genérico da Computação em Névoa, para aplicação do
método do balanceamento de carga proposto;
• Especificar os módulos que compõem o sistema proposto de balanceamento de carga; e
• Comprovar a viabilidade do trabalho proposto através de um ambiente simulado.
1.4 CONSIDERAÇÕES DO CAPÍTULO
Neste capítulo foi realizada uma introdução às tecnologias de Internet das Coisas e
Computação em Névoa, paradigmas computacionais que se complementam. Observa-se que
a Computação em Névoa tem obtido atenção nos últimos anos, dada a constante necessidade
das aplicações de Internet das Coisas de ter um tempo de resposta baixo, com tomada de decisão
próxima dos sensores e atuadores para que se tenha aplicações de tempo real, como realidade
aumentada, campus e salas de aula inteligentes, e outros. A dinamicidade do ambiente de Com-
putação em Névoa torna-se um problema para os algoritmos de balanceamento de carga, e as
mudanças repentinas nos ambientes podem comprometer os tempos de respostas da camada de
nevoeiro. Portanto, uma nova abordagem de balanceamento de carga é proposta neste trabalho
para que o problema seja atenuado.
18
2 REFERENCIAL TEÓRICO
Este capítulo tem por objetivo trazer à tona os principais conceitos abordados neste tra-
balho. Sendo assim, procedeu-se com uma revisão de literatura sobre os mesmos, elucidando o
embasamento teórico, trazendo os dados sobre os conceitos como Internet das Coisas, Compu-
tação em Névoa, Computação em Nuvem e Balanceamento de Carga. Em seguida, buscou-se os
trabalhos que estão envolvidos na resolução do problema do balanceamento de carga em nevo-
eiro, objetivando demonstrar quais critérios foram adotados pelos autores para tomar a decisão
de alocação das requisições no balanceador de carga.
2.1 INTERNET DAS COISAS
O conceito de Internet das Coisas, apresentado em 1999 por Kevin Ashton (ASHTON
et al., 2009) refere-se à objetos do cotidiano, os quais tornaram-se inteligentes. Estes, possuem
algum tipo de conectividade, via de regra, sem fios, e capturam dados dos ambientes onde estão
inseridos, seja de uma casa inteligente, do nosso corpo, de uma cidade inteligente, uma rede de
veículos, dentre outras.
Vários pesquisadores definem a Internet das Coisas, dentre eles, os autores (AL-FUQAHA
et al., 2015) a destacam como sendo uma rede de objetos físicos conectados à Internet, possibilitando-
os a ver, ouvir, sentir e pensar, os quais podem realizar tarefas, compartilhar informações e
trabalhar de forma coordenada.
No trabalho de (ATZORI; IERA; MORABITO, 2010), os autores definem a IoT como
uma conexão entre o mundo virtual e o mundo físico, destacando a presença pervasiva ao
nosso redor de uma variedade de coisas ou objetos, como etiquetas de Identificação por Rádio-
frequência (RFID), sensores, atuadores, capazes de interagir uns com os outros cooperando para
cumprir objetivos em comum.
Os autores (LI; DA XU; ZHAO, 2015) destacam a IoT como um super conjunto de
dispositivos interconectados entre si, identificados unicamente na Internet. Portanto, trata-se de
uma rede de sensores e atuadores, comunicando-se uns com os outros e cooperando para atingir
um objetivo em comum.
Dentre as características da Internet das Coisas, o autor (RAY, 2018) destaca:
1. Auto-adaptação e dinamicidade: que diz respeito à adaptação dos sensores aos ambientes,
19
bem como a diversidade de conexão à rede, tipos de hardware dos sensores.
2. Auto-configuração: que diz respeito à capacidade dos dispositivos adentrarem em um
ambiente de rede, receber sua identificação única e adequar-se no ambiente em questão,
com o mínimo de intervenção humana possível.
3. Interoperabilidade: onde os sensores/atuadores da Internet das Coisas podem implemen-
tar uma variedade de protocolos de comunicação, e necessitam comunicar uns com os
outros através dos mesmos.
4. Identidade única: cada dispositivo IoT deve ter seu endereçamento único, seja IP ou URI,
o qual é gerenciado por uma interface de middleware responsável pela identificação dos
mesmos, o que possibilita o controle e acesso remoto ao dispositivo.
5. Integração à rede: onde os dados capturados pelos dispositivos possam ser utilizados
para troca de dados com outros sistemas já existentes.
6. Consciência de contexto: que diz respeito que as decisões tomadas no nó se relacionam
ao tipo de dado que está sendo capturado no ambiente.
7. Capacidade de tomada de decisão: através das camadas de middlewares, torna-se possí-
vel a tomada de decisão baseado no ambiente a qual estão inseridos.
A aplicabilidade do paradigma de Internet das Coisas torna-se viável nos mais variados
domínios como ilustrado na Figura 2. Por exemplo, a área da saúde, para monitorar os pacientes,
na indústria, coletando dados das máquinas e produtos, em ambientes inteligentes, como um
campus ou cidades inteligentes.
Como a Internet das Coisas refere-se à pequenos dispositivos, como sensores e atuado-
res, os recursos computacionais que os mesmos possuem são limitados, e portanto, a função
dos mesmos restringe-se à capturar e enviar seus dados para uma entidade central, que possa
processá-los e dar retorno quando for um atuador que precisa da resposta.
Sendo assim, o apoio computacional da Computação em Nuvem e da Computação em
Névoa torna-se fundamental para a realização do paradigma da Internet das Coisas, as quais
oferecem seus recursos computacionais sob medida para cada domínio de aplicação. Embora
ainda há a necessidade de tempos de resposta mais baixos, este paradigma computacional traz
benefícios às pessoas, uma vez que tem-se uma computação onipresente para facilitar o dia-a-
dia das pessoas.
20
Figura 2 – Domínios de aplicação da Internet das Coisas.
Fonte: (AL-FUQAHA et al., 2015)
Portanto, a evolução de outros paradigmas computacionais torna-se necessária para que
se impulsione a Internet das Coisas. Novos modelos de computação vêm surgindo para preen-
cher as lacunas impostas e atender as demandas computacionais da sociedade. Dentre eles, o
paradigma de Computação em Nuvem será discutido na próxima seção.
2.2 COMPUTAÇÃO EM NUVEM
O paradigma de Computação em Nuvem tem revolucionado a oferta de serviços de
computação nos dias atuais (SAKPAL, 2019), como mostra a Figura 3. Baseada em três com-
ponentes chave, que são: Infraestrutura como Serviço; Plataforma como Serviço e Software
como Serviço, possui como características essenciais (VERDI et al., 2010):
1. Serviço sob demanda: as funcionalidades computacionais são providas automaticamente
sem a interação humana com o provedor do serviço;
2. Amplo acesso aos serviços: recursos computacionais estão disponíveis através da Inter-
net, os quais são acessados via mecanismos padronizados, possibilitando o acesso via
computadores, dispositivos móveis e outros;
3. Pool de recursos: os recursos computacionais, sejam físicos ou virtuais, são utilizados
para servir múltiplos usuários, e são realocados dinamicamente conforme a demanda do
21
usuário;
4. Elasticidade: as funcionalidades computacionais devem ser rápida e elasticamente provi-
das, assim como rapidamente liberadas, o que dá a impressão ao usuário de que possui
recursos ilimitados, e;
5. Medição dos Serviços: os sistemas que gerenciam a Nuvem controlam e monitoram auto-
maticamente os recursos para cada tipo de serviço, de forma transparente para o provedor
do serviço assim como para o consumidor do mesmo.
Figura 3 – Relatório da Gartner.
Fonte: (SAKPAL, 2019)
Dentre os principais modelos de implantação, tem-se (VERDI et al., 2010):
1. Nuvem Privada: o que compreende a infraestrutura de nuvem operada unicamente por
uma organização, ou seja, os serviços serão consumidos localmente;
2. Nuvem Comunitária: fornece infraestrutura compartilhada por uma comunidade de orga-
nizações com interesses em comum;
3. Nuvem Pública: a qual é disponibilizada publicamente através do modelo pay-per-use,
as quais são oferecidas tipicamente por organizações que possuem grandes capacidades
computacionais para tal;
22
4. Nuvem Híbrida: compõe-se de uma infraestrutura de duas ou mais nuvens (privada, co-
munitária ou pública), mas que apresenta-se como única, mas conectadas através de tec-
nologias e padrões proprietários;
Nota-se que a elasticidade é um aspecto chave na Computação em Nuvem, inclusive,
sendo a principal diferença deste paradigma ao comparar com Computação em Grade ou Com-
putação de Alto Desempenho (HPC). O autor (VERDI et al., 2010) destaca que as vantagens da
Nuvem como sendo a eliminação do comprometimento inicial por parte do usuário, bem como
a capacidade de alocar recursos apenas conforme a necessidade do cliente, o que dá um controle
granular por horas de utilização.
Os autores em (JADEJA; MODI, 2012) e (JIN et al., 2010) definem a Computação em
Nuvem como uma estrutura conveniente, a qual consiste da combinação de hardware e soft-
ware, cujo objetivo é prover serviços de computação, rede e armazenamento, provendo um
provisionamento de recursos sob-demanda de forma rápida. Ou seja, a Computação em Nuvem
compõe-se de datacenters com muitos nós computacionais, e adicionado à estes nós, uma ca-
mada de software, os quais são projetados para gerenciar todos estes recursos computacionais.
No trabalho de (SUBASHINI; KAVITHA, 2011), os autores definem a arquitetura da
Computação em Nuvem em camadas, à saber: i) Software-as-a-Service (SaaS): refere-se à
uma aplicação oferecida como serviço, onde seus clientes não preocupam-se com questões
de infraestrutura, como servidores, links de Internet, apenas usam a aplicação; ii) Platform-
as-a-Service (PaaS): neste modelo, o público-alvo são desenvolvedores de aplicações, onde
é provido para os clientes sistemas e ambientes para gerenciar o ciclo de vida completo das
aplicações que são desenvolvidas; iii) Hardware-as-a-Service (HaaS): de forma resumida, é
a situação onde os clientes podem adquirir servidores por um período de tempo, e, vencido
este período, podem devolvê-los ao provedor da nuvem, pagando apenas pelo que foi utilizado;
iv) Infrastructure-as-a-Service (IaaS): diz respeito à entrega de toda a estrutura computacional
do datacenter para o cliente, onde o mesmo gerencia à seu modo, e ainda, paga pelo que usa.
Máquinas virtuais são a base para prover o emprego das diversas funcionalidades da
Computação em Nuvem. Sendo assim, através delas, torna-se possível o rápido desenvolvi-
mento de software, o qual é disponibilizado para os clientes, com o objetivo de ser utilizados.
Uma vez que não é mais necessária, a máquina virtual pode ser descartada, liberando os recur-
sos computacionais para outros usuários (JIN et al., 2010). Múltiplas máquinas virtuais podem
executar em um mesmo servidor físico, o que torna possível a utilização ao máximo do hard-
23
ware disponível no datacenter. Para isto funcionar, a presença do gerenciador da infraestrutura
de Nuvem torna-se necessária, via de regra baseados em soluções para web, localizada no topo
dos provedores de IaaS, como mostra a Figura 4.
Figura 4 – Gerenciamento de Máquinas Virtuais.
Fonte: (JIN et al., 2010)
Aplicações de larga escala, que requerem uma alocação dinâmica de recursos computa-
cionais, estão cada vez mais comuns, sendo que a Computação em Nuvem torna o uso destas
aplicações mais fácil, pois a mesma tem a habilidade de tratar dezenas de milhares de requi-
sições, e ainda, prover aos usuários um baixo custo por isto, onde os mesmos pagam apenas
pelo que utilizaram. Dentre os principais serviços dentro de uma Nuvem, os autores (RIMAL;
CHOI; LUMB, 2010) destacam o gerenciamento e balanceamento de carga. O principal obje-
tivo é prevenir ’gargalos’ nos sistemas, em função do desbalanceamento de carga que pode vir
a ocorrer, bem como, possibilitar outras características que são intrínsecas na Nuvem, como a
escalabilidade.
2.3 COMPUTAÇÃO EM NÉVOA (FOG COMPUTING)
A Computação em Névoa, proposta em 2012 por (BONOMI et al., 2012), caracteriza-se
como uma extensão da Computação em Nuvem para a borda da rede, posicionando-se perto
dos sensores (geradores de dados) e atuadores (geradores e consumidores de dados). Este novo
paradigma não exclui a Computação em Nuvem, mas a complementa, a qual traz recurso com-
putacionais próximos dos sensores e atuadores, ou seja, a Computação em Névoa não pode
existir de forma autônoma (CONSORTIUM et al., 2017).
Aplicações tradicionais de Internet das Coisas, via de regra são compostas por senso-
res/atuadores em um lado, e, no outro, os recursos computacionais alocados na nuvem, que é
24
para onde tais dispositivos enviam seus dados. Tais recursos computacionais ficam longe dos
sensores/atuadores, por consequência, uma alta latência e altos tempos de respostas são perce-
bidos neste modelo, além da alta utilização dos links de Internet, que com o tempo podem ficar
sobrecarregados, dada a grande quantidade de objetos inteligentes que compõem a Internet das
Coisas (AL-FUQAHA et al., 2015).
No trabalho dos autores (NAHA et al., 2018), os mesmos destacam a Computação em
Névoa como um sistema computacional distribuído, o qual potencializa as aplicações de Inter-
net das Coisas, colocando seus recursos computacionais à disposição dos sensores e atuadores
que demandam armazenamento e processamento, como mostrada na Figura 5.
Figura 5 – Arquitetura da Computação em Névoa.
Fonte: (NAHA et al., 2018)
Os nodos que compõem a Computação em Névoa podem ser compostos de switches,
roteadores, access points, ou mesmo servidores tradicionais, bem como outros tipos de equi-
pamentos (YI; LI; LI, 2015), onde cada um destes oferece seus recursos computacionais, de
rede, de armazenamento, para as aplicações de Internet das Coisas, em uma plataforma vir-
tualizada e distribuída (VAQUERO; RODERO-MERINO, 2014). Como este novo paradigma
posiciona-se na borda da rede, ou poucos saltos de distância dos objetos inteligentes da IoT, a
Computação em Névoa provê baixa latência, consequentemente, baixos tempos de reposta em
uma plataforma distribuída geograficamente.
Devido ao aumento da adoção de objetos inteligentes da Internet das Coisas, a Compu-
tação em Névoa possui um papel de suma importância, dada a crescente demanda de proces-
25
samento bem como do volume de dados gerados, sendo que, além da diminuição da latência
(por consequência, dos tempos de reposta), os links de Internet tendem a ficar menos sobre-
carregados, pois os objetos inteligentes enviam seus dados para a Névoa, onde os mesmos são
pré-processados perto dos sensores, e só então são enviados para a Nuvem.
2.4 BALANCEAMENTO DE CARGA
Dada a diversidade das aplicações de Internet das Coisas, somado ao fato da Computa-
ção em Névoa possuir nodos computacionais heterogêneos, a alocação de tarefas é um problema
desafiador. Sem a correta utilização dos recursos computacionais, por outro lado, os nodos da
Névoa tendem a ficar com cargas de trabalho desequilibradas, ou seja, a utilização do hard-
ware à disposição pode não ser utilizada corretamente. Alguns nodos computacionais podem
estar sobrecarregados, o que compromete os tempos de resposta e o QoS das aplicações, en-
quanto que outros nodos podem estar com seus recursos computacionais subutilizados, sendo
que poderiam ser desativados temporariamente, ou ainda, ter tarefas alocadas para que sejam
aproveitados.
O Balanceamento de Carga consiste na distribuição de tarefas entre vários nodos com-
putacionais, onde apenas um nó não é capaz de atender todas as requisições. Tais nodos estão
sob gerência do balanceador, o qual recebe as requisições e as distribui entre seus nodos para
serem processadas (VERMA; BHARDWAJ; YADAV, 2016), com o objetivo de minimizar a
latência, e maximizar a vazão de todo o sistema distribuído.
Em sistemas distribuídos como Computação em Nuvem, o Balanceador de Carga exe-
cuta um papel fundamental, uma vez que na nuvem, os sistemas e aplicações devem atender
todas as requisições dos clientes no menor tempo possível, mantendo a alocação de tarefas
entre os nodos, para aproveitar os recursos computacionais e otimizar os custos. Ainda, ba-
lanceadores de carga devem ser tolerantes à falhas de rede, como heterogeneidade, falhas dos
nodos computacionais e outros (AL NUAIMI et al., 2012).
Os algoritmos de balanceamento de carga, como descrito em (CASAVANT; KUHL,
1988), classificam-se quanto à habilidade de adaptar-se ao ambiente ou não, à localização da
entidade que toma a decisão de onde alocar a tarefa ou não e quando ao nível de balanceamento.
Algoritmos de Balanceamento de Carga globais são classificados em estáticos e dinâ-
micos. Ambientes homogêneos e estáveis tiram benefícios dos algoritmos estáticos, os quais
não são flexíveis e não levam em conta as mudanças repentinas do ambiente em questão, nem
26
a carga de trabalho atual de seus nodos. Por outro lado, algoritmos dinâmicos são mais flexí-
veis, os quais levam em conta a heterogeneidade do ambiente e as capacidades de seus nodos,
em tempo de execução, portanto, adaptam-se às mudanças repentinas que podem ocorrer no
ambiente (AL NUAIMI et al., 2012).
Dentre os principais objetivos do balanceamento de carga, os autores (VERMA; YA-
DAV, 2015) destacam:
• Tempo de resposta mínimo: que significa o tempo de envio do primeiro pacote ao servidor
(nodo) e o recebimento do tempo de resposta;
• Máxima vazão: diz respeito ao tempo máximo requerido para completar uma transação
por segundo;
• Ótima utilização de recursos: que significa garantir que nenhum nodo esteja ocioso;
• Mínimo delay de rede: diz respeito à interferência mínima por parte dos equipamentos de
rede nos pacotes, durante seu percurso até o servidor;
• Fator de performance: tempo mínimo do algoritmo para atender a requisição;
• Tolerância à falhas: para o caso de falhas de links, falhas no software ou no hardware;
• Tempo de execução: o tempo requerido para executar as tarefas do usuário;
• Escalabilidade: trata da habilidade do sistema escalar mais hardware ou software para
atender a demanda emergencial;
• Baixo overhead: refere-se ao tempo de processamento requerido pelo sistema, incluindo
toda a operação do balanceamento de carga;
Neste contexto, realizar a alocação de tarefas na Computação em Névoa torna-se uma
tarefa complexa, uma vez que a mesma é composta de nodos computacionais com capacida-
des heterogêneas. Sendo assim, algoritmos de balanceamento estáticos, apesar de serem mais
rápidos, não combinam com o formato dinâmico deste novo paradigma, e os algoritmos dinâ-
micos, por outro lado, podem vir a contribuir para a alocação das mesmas, mesmo que seu custo
computacional venha ser maior (VERMA; YADAV, 2015).
27
2.5 TRABALHOS RELACIONADOS
Nesta seção, serão apresentados alguns trabalhos que se correlacionam com esta pro-
posta. Dentre eles, buscou-se destacar quais critérios foram utilizados para a tomada de decisão
de alocação das tarefas entre os nodos da Computação em Névoa. Alguns trabalhos abordam o
balanceamento de carga em Computação de Borda (Edge Computing) como sinônimo da Com-
putação em Névoa, então para este trabalho, buscou-se artigos que tratam do balanceamento
de carga nestes dois paradigmas. De forma geral, os trabalhos dividem-se na abordagem do
balanceamento centralizada ou distribuída, então classificou-se os trabalhos desta maneira à
seguir.
2.5.1 Abordagem Centralizada
O balanceamento de carga centralizado trata da decisão de alocação de tarefas se reali-
zada em uma entidade central na rede. Os critérios usados para a alocação são os que constam
na Tabela 1. Por exemplo, em (TALAAT et al., 2019), os autores propuseram o balanceador de
carga para a Computação em Névoa, denominado Effective Load Balancing Strategy (ELBS),
o qual é dotado de cinco módulos, cada qual com sua função definida, aplicado ao domínio de
Internet das Coisas na saúde. Os critérios que o balanceador leva em consideração para alocar
a tarefa são CPU, memória e armazenamento do nodo. Por conta disso, o tempo de retorno
médio, quando comparado com outras soluções, chegou a ser até 50% menor, e a taxa de falhas
diminuiu até 30%. No entanto, todos os testes provocaram uma alta carga de trabalho na CPU,
onde os resultados ficaram acima de 90% da capacidade total.
O autor (JUNIOR, 2017) apresenta um balanceamento de carga e predição de fluxos para
a Computação em Névoa, onde o mesmo propõe um modelo de arquitetura, dispositivos da IoT,
dispositivos da Fog e controladores, utilizando o paradigma de Redes Definidas por Software
(SDN). Como vantagem, o fato de um enlace entre um dispositivo IoT e seu nó de Névoa estar
sobrecarregado ou falhar, através de técnicas que são possibilitadas pelo SDN, torna-se possível
desviar o fluxo de dados para outro nó de Névoa que tenha condições de executar a tarefa.
As métricas de avaliação foram o tempo de resposta e a quantidade de pacotes perdidos dada
a sobrecarga dos nodos da Névoa, onde a solução proposta proporcionou uma melhoria nas
duas métricas avaliadas, sendo que o tempo de resposta diminuiu até 63% no melhor caso, e o
número de amostras perdidas caiu de 14.15% para 0.57%.
28
Na área da saúde, os autores (WANG et al., 2017) e (NGUYEN; PHAM, 2018) aplica-
ram as técnicas do balanceamento de carga em casas inteligentes e em clínicas, especificamente
nos cuidados da saúde das pessoas, aplicando prioridades às tarefas, sempre com o objetivo de
diminuir o tempo de resposta, enviando-as à Nuvem quando a tarefa não tem alta prioridade. Os
resultados apontam uma menor utilização da rede quando comparado com a Nuvem, e menor
latência e consumo de energia.
No trabalho de (VERMA et al., 2016), os autores propõem um modelo de arquitetura
e balanceamento de carga para a Computação em Névoa. A arquitetura é composta de vários
nodos de Névoa, e também do Fog Server Master, que atua como balanceador de carga, e ao
mesmo tempo, processa tarefas de alta prioridade quando necessário. Através da técnica de
replicação dos dados, a arquitetura torna-se menos dependente dos servidores na Nuvem. O
trabalho proposto trouxe um ganho de 17% nos tempos de resposta, e 25% de diminuição no
tempo de processamento comparado com outros trabalhos.
Na área de Computação de Borda, o trabalho de (CHAMOLA; THAM; CHALAPATHI,
2017), foca em cloudlets, que são recursos computacionais localizados em estações base de
antenas de telefonia móvel, os quais oferecem seus recursos computacionais aos dispositivos
móveis, através da adoção de SDN. Com o trabalho proposto, houve uma diminuição maior que
50% nos tempos de resposta.
Os autores em (YU; LI; QIAN, 2017) propuseram um balanceador para Computação
em Névoa, denominado SDLB, o qual leva em consideração apenas o poder computacional e
memória, sendo que a solução proposta consome poucos recursos computacionais, em função
de manter uma tabela hash no balanceador, e os dados são mantidos no controlador, que tem
maiores capacidades computacionais. A taxa de vazão, que foi a métrica avaliada, teve um
aumento de 4 a 10 vezes, quando comparado com outros trabalhos, utilizando 50% a menos de
memória.
Um olhar sob o ponto de vista dos custos é abordado em (PHAM; HUH, 2016) e em
(PHAM et al., 2017), onde os autores propuseram um algoritmo de balanceamento de carga para
ambientes de Névoa e Nuvem, alcançando resultados até 25% superiores aos algoritmos com-
parados no trabalho. Destacou-se que o algoritmo usou menos recursos financeiros comparado
com outros trabalhos, sendo até 30% mais barato financeiramente, mantendo boa performance
do sistema.
No trabalho de (OUEIS; STRINATI; BARBAROSSA, 2015), abordou-se o balancea-
29
mento de carga em Névoa, levando em consideração a formação de um cluster para o processa-
mento das requisições de offloading dos usuários, objetivando diminuir a latência e melhorar a
qualidade de experiência (QoE) dos mesmos. Todas as variações do algoritmo proposto obtive-
ram melhores resultados do que a clusterização estática, destacada no trabalho dos autores, e a
satisfação dos usuários foi avaliada em no mínimo 80% positivamente.
Para distribuir as tarefas das aplicações de Internet das Coisas entre os nodos computaci-
onais de borda, o trabalho de (SONG et al., 2017) preocupa-se em manter o tempo de execução
baseado na qualidade de serviço, levando em consideração as características de CPU, armazena-
mento e rede para realizar a alocação das tarefas no nodo mais apropriado. A melhoria proposta
foi no sentido de melhorar a capacidade da rede de borda para receber um maior número de
tarefas, que foi no mínimo 54% superior aos outros métodos comparados, mesmo em situações
de tamanho de dados ou variações de conectividade de rede diferentes.
Um olhar na questão da segurança dos dados foi aplicado no trabalho dos autores Bane-
riee et. al. (BANERIEE et al., 2018). O objetivo é realizar a alocação das tarefas e gerenciar os
recursos de rede dos nodos participantes da Névoa. A dependência da comunicação dos clien-
tes com o controlador para a decisão da criptografia dos arquivos pode ser um problema, pois o
controlador depende também da infraestrutura de Nuvem para armazenamento dos dados.
2.5.2 Abordagem Distribuída
Na abordagem de balanceamento de carga distribuída, o ponto de tomada de decisão de
alocação de tarefas pode co-existir com vários outros, onde pode haver uma sincronização ou
consenso entre eles para realização do balanceamento de carga. Destes, alguns trabalhos ado-
taram apenas a utilização de CPU como critério de balanceamento de carga, seja em ciclos de
CPU, MIPS ou Mhz. Por exemplo, em (JOŠILO; DÁN, 2018) foi proposto um algoritmo para
alocação de tarefas descentralizado em sistemas de Computação em Névoa, considerando que
os dispositivos possuem a habilidade de decisão para processar as tarefas neles, ou encaminhar
para outros nodos na rede, ou até na Nuvem. Em (LI et al., 2018), buscou-se a otimização do
atraso da rede através de um modelo de arquitetura de três camadas o qual combina o poder
computacional da Computação em Nuvem e da Computação em Névoa.
Em (CHEN; ZHANG; CHEN, 2018), os autores preocuparam-se com a mobilidade dos
usuários, e propuseram um serviço dinâmico de agendamento de requisições na computação de
borda, observando questões de custo e de performance das requisições. O custo do algoritmo
30
de agendamento e o tamanho da fila ficaram abaixo das soluções comparadas pelos autores,
demonstrando portanto ser uma solução viável para o cenário proposto. Em (BERALDI; MTI-
BAA; ALNUWEIRI, 2017), os autores propuseram a solução denominada CooLoad, tendo
como objetivo a cooperação entre os datacenters computacionais na borda da rede, o qual foi
realizado através de um modelo matemático através da captura dos aspectos necessários para
realizá-la. Em ambientes de carga homogênea a solução mostrou-se apropriada, mas em cargas
distintas, houve uma distribuição das mesmas entre os nodos computacionais.
Sob um olhar nas cidades inteligentes, os autores do trabalho em (LIU et al., 2017)
destacam a heterogeneidade do ambiente das aplicações de Internet das Coisas e de nevoeiro. O
foco principal do trabalho foi a otimização simultânea do custo de produção e de comunicação,
bem como a habilidade de adaptar-se de maneira flexível à importância custo de fabricação e
comunicação em aplicações práticas. No trabalho de (MOGI; NAKAYAMA; ASAKA, 2018),
um cenário de IoT foi proposto, onde os autores destacam o problema de cooperação entre os
nodos da IoT, e trazem à tona o conceito de Borda/Nevoeiro. Então, propõe-se o método de
balanceamento de carga para o ambiente de IoT através da adoção de múltiplos acessos para
equilibrar a carga dos servidores. No trabalho em (ZHOU; THAM, 2018), os autores trazem
um olhar sob o ponto de vista de dispositivos móveis em função da decisão de onde realizar o
processamento dos dados.
Um framework de alocação de tarefas voltado para este cenário foi proposto, o qual
realiza o balanceamento em tempo real entre os nodos que compõem o nevoeiro. Observou-
se neste trabalho a baixa taxa de rejeição de tarefas dos nodos, e o baixo tempo de resposta,
quando comparado aos trabalhos relacionados, todavia neste trabalho considerou-se apenas a
CPU do nodo para realizar a alocação de tarefas. No trabalho de (KOLOMVATSOS; ANAG-
NOSTOPOULOS, 2018), através da tomada de decisão de dois níveis, e da análise estatística,
os autores conseguiram um realizar a alocação sem ter uma sobrecarga nos links de comunica-
ção para estabelecimento de vizinhança dos nodos computacionais, uma vez que apenas CPU
foi considerada na simulação.
A energia pode ser um fator importante para o nevoeiro em alguns cenários, onde se tem
dispositivos alimentados por baterias. Pensando nisso, os autores em (KAN; CHIANG; WEI,
2018) destacam a importância da alocação de tarefas no ambiente de computação de borda
móvel. Assim, foi proposto uma heurística e comparado com outras soluções, com o intuito
de promover qualidade de serviço aos usuários, avaliando-se o custo de execução, satisfação
31
dos usuários e consumo de energia para realizar a operação. Observou-se no trabalho uma
melhora em todas as grandezas avaliadas com outras soluções propostas, mas o trabalho consi-
derou apenas a capacidade de CPU para a decisão de alocação das tarefas nos nodos computa-
cionais.Em (STHAPIT; HOPGOOD; THOMPSON, 2017), os autores propuseram algoritmos
reativos e proativos para a realização do balanceamento de carga distribuído em ambientes de
borda/nevoeiro. Os autores consideraram apenas características de CPU no balanceamento, e os
resultados da simulação demonstram que todas as tarefas puderam ser processadas sem perdas,
mantendo o tradeoff entre consumo de energia e desempenho adequado.
Em (YU et al., 2018), os autores preocuparam-se principalmente com o consumo de
energia dos nodos que compõem o nevoeiro, através da decomposição do problema do balan-
ceamento de carga em subproblemas menores, e então tenta resolvê-los. A capacidade de rede
dos nodos foi levada em consideração, uma vez que os autores tratavam de computação móvel
em antenas de telefonia móvel. Um mecanismo distribuído e com ciência de contexto para as-
sociação de tarefas na borda foi proposto pelos autores em (GU et al., 2018), cujo foco principal
foi o baixo consumo de energia e boa escalabilidade.
Um algoritmo baseado no particionamento de grafos foi proposto pelos autores em
(BOUET; CONAN, 2017), levando em consideração a capacidade computacional total do clus-
ter de borda da rede, o qual diminuiu em 55% do tráfego de rede, mantendo-o dentro do do-
mínio da borda. Embora a abordagem distribuída tenha melhor escalabilidade e convergência
em ambientes distribuídos, os autores negligenciaram atributos como rede e memória dos no-
dos para realizar o balanceamento de carga. Em (XU et al., 2018), os autores propuseram o
DRAM (Dynamic Resource Allocation Method), composto de quatro passos: partição do nodo
da névoa, detecção de espaço livre para nós de computação, alocação estática para subconjunto
de serviços de nevoeiro e balanceamento de carga orientado a alocação de recursos. Através
de simulações, observa-se que a solução faz a utilização máxima dos recursos computacionais
para evitar o desperdício dos mesmos, e ainda, embora escalou-se quatro vezes a quantidade de
serviços de nevoeiro, os nodos computacionais utilizados permaneceram estáveis.
Os autores em (CHEN et al., 2017) e em (NETO; CALLOU; AIRES, 2017) destacam a
utilização de prioridades às tarefas, onde os mesmos propuseram um mecanismo de classifica-
ção de tarefas, para definir e classificar a prioridade da tarefa que chega, ou qual é utilizado no
agendamento das mesmas no balanceador de carga no nevoeiro. Contudo, apenas a prioridade
é levada em conta no agendamento, o que pode ser melhorado se houver uma coleta dos dados
32
sobre a saúde computacional dos nodos no nevoeiro. Já em (NETO; CALLOU; AIRES, 2017),
os autores propuseram o balanceamento de carga em nevoeiro considerando as características
de CPU, rede e prioridade dos nodos computacionais. E em (FAN et al., 2017), os autores
propuseram uma otimização para o balanceamento de carga baseado na eurística da Colônia de
Formigas, para alocação de tarefas baseada em seu tempo máximo de espera. A colaboração
entre nevoeiro e nuvem também é destacada no trabalho dos autores, todavia os critérios de alo-
cação foram apenas CPU e rede, negligenciando outros critérios elencados na Tabela 1 durante
a simulação do ambiente proposto.
A aplicação de Computação em Névoa em redes veiculares também foi aplicada no
trabalho dos autores em (CHEN; WALTERS; CRAGO, 2017), (ZHU et al., 2018) e em (CHE-
KIRED; KHOUKHI; MOUFTAH, 2018). No primeiro trabalho, o cenário de uma rede veicular
é proposto, onde aplica-se o balanceamento de carga em Computação em Névoa, objetivando
o tempo mínimo de execução, dada a alta dinamicidade dos dispositivos envolvidos em tais
ambientes. Contudo, antes mesmo de propor o algoritmo proposto, os autores preocuparam-se
em realizar um padrão para predição de mobilidade, o qual é utilizado no momento do agenda-
mento das tarefas nos nodos do nevoeiro mais apropriados. Os autores destacam que o consumo
de energia deve ser considerado em trabalhos futuros, o que torna-se de fato algo de suma im-
portância, uma vez que para este cenário, tem-se vários dispositivos alimentados à fontes finitas
de energia.
No artigo dos autores (ZHU et al., 2018), também propõe-se um modelo de balance-
amento de carga para redes veiculares em Computação em Névoa. Contudo, ao contrário do
trabalho anterior que leva em consideração apenas a CPU, neste, o critério para alocação dá-se
pela capacidade da rede dos nodos, CPU e memória. Já em (CHEKIRED; KHOUKHI; MOUF-
TAH, 2018), os autores propuseram uma abordagem descentralizada para o balanceamento de
carga em Computação em Névoa com preocupação em eficiência energética, aplicado à carga
e descarga de veículos elétricos. A solução proposta considera a prioridade, CPU e memória
como critérios para realizar a alocação de tarefas nos nodos. Além de performar melhor do que
seus trabalhos relacionados, trouxe economia de energia aliada à estabilidade do sistema como
um todo.
Na aplicação de dispositivos móveis, os autores em (WU et al., 2018) propuseram o
algoritmo para balanceamento de carga geográfico voltado à computação de borda e usuários
móveis. Especificamente o consumo de energia ficou abaixo dos trabalhos relacionados, de-
33
monstrando ser uma opção viável para o cenário proposto pelos autores, com garantia de per-
formance. Em (NA et al., 2018), os autores também propuseram um algoritmo dinâmico para
alocação de tarefas em ambientes de computação móvel. Destaca-se a dificuldade de comunica-
ção intermitente da rede por parte dos autores, sendo que esta é a dificuldade de estabelecimento
de comunicação para com os gateways móveis que tratam para com cada cliente conectado na
antena de comunicação. Portanto, foi proposta uma abordagem de distribuição dinâmica de
tarefas para distribuir o tráfego de rede em múltiplas redes para que cada unidade móvel possa
alcançar seu gateway móvel. Observa-se a melhoria em até 250% de vazão dos dados quando a
função do balanceamento de carga foi adotada.
Sob o olhar de cidades inteligentes, o provisionamento de recursos em ambientes de edi-
fícios inteligentes baseado em Computação em Névoa e Computação em Nuvem é o trabalho
proposto em (YASMEEN et al., 2018). Através da integração entre estes dois paradigmas, foi
proposto um modelo baseado em três camadas para realizar o balanceamento de carga. Resulta-
dos mostraram que a solução obteve melhores índices de tempo de resposta quando comparados
à abordagem Round-Robin. Contudo, os autores consideraram apenas características de rede e
CPU para agendamento das tarefas. No contexto das forças armadas, os autores em (WANG
et al., 2018) propuseram uma arquitetura composta por nodos de nevoeiro no campo de batalha
que adota conceitos de Internet das Coisas. Dada a característica distribuída dos ambientes, os
autores então preocupam-se com a questão do agendamento e balanceamento de carga, visto
que cada unidade de combate armazena e processa dados coletados de várias fontes, e os servi-
dores em Nuvem otimizam e organizam os dados, e servem ainda de escape quando o nevoeiro
está sobrecarregado.
Com destaque na cooperação dos nodos computacionais, os trabalhos de (ENNYA;
HADI; ABOUAOMAR, 2018) e de (XU et al., 2017) trazem um modelo para realizar a forma-
ção de um modelo para que haja o compartilhamento de recursos entre os nodos. Um modelo
de jogo de coalizão foi proposto em (ENNYA; HADI; ABOUAOMAR, 2018), cujo objetivo é o
de cooperação entre os nodos que compõem o nevoeiro. Através da simulação, os autores defi-
niram o modelo de comunicação entre os nodos da névoa e então a formulação da coalizão para
que haja cooperação entre eles. A quantidade de recursos utilizados e latência da resposta da
solução proposta permaneceu abaixo do modelo proposto sem cooperação, mas prioridade de
tarefas e rede foram negligenciados, e uma avaliação com outras soluções também não houve.
No trabalho de (XU et al., 2017), foi proposto um modelo de compartilhamento de re-
34
cursos computacionais, o qual provê o algoritmo de balanceamento que conhece o tempo limite
de execução das tarefas, e as aloca em um nodo mais apropriado, utilizando-se de contêineres
para processamento. Como principais ganhos, o tempo de resposta ficou em média 25% abaixo
da alocação em nuvem, e a taxa de sucesso até dez vezes maior do que na nuvem, mesmo não
considerando prioridade e armazenamento para a realização do agendamento.
A Tabela 1, sistematiza os trabalhos relacionados apresentados de acordo com os crité-
rios utilizados para a tomada de decisão em seus algoritmos de balanceamento de carga. Sob o
ponto de vista deste trabalho, destaca-se que o mesmo difere-se dos demais pelo fato de levar
em consideração todos os itens dos trabalhos anteriores.
# Trabalho CPU Memória Armazenamento Rede Prioridade1 (YU; LI; QIAN, 2017) • •2 (PHAM et al., 2017) • •3 (OUEIS; STRINATI; BARBAROSSA, 2015) •4 (VERMA et al., 2016) • •5 (PHAM; HUH, 2016) • •6 (WANG et al., 2017) • • •7 (SONG et al., 2017) • •8 (BANERIEE et al., 2018) • • •9 (NGUYEN; PHAM, 2018) • • •10 (CHAMOLA; THAM; CHALAPATHI, 2017) • •11 (JUNIOR, 2017) • •12 (TALAAT et al., 2019) • • • •13 (BOUET; CONAN, 2017) • •14 (JOŠILO; DÁN, 2018) •15 (GU et al., 2018) •16 (LI et al., 2018) • •17 (XU et al., 2018) • • •18 (CHEN; ZHANG; CHEN, 2018) •19 (BERALDI; MTIBAA; ALNUWEIRI, 2017) •20 (CHEN et al., 2017) •21 (NETO; CALLOU; AIRES, 2017) • • •22 (FAN et al., 2017) • •23 (LIU et al., 2017) •24 (CHEN; WALTERS; CRAGO, 2017) •25 (ZHU et al., 2018) • • •26 (YU et al., 2018) •27 (WU et al., 2018) •28 (CHEKIRED; KHOUKHI; MOUFTAH, 2018) • • •29 (YASMEEN et al., 2018) • •30 (WANG et al., 2018) • •31 (ZHOU; THAM, 2018) •32 (NA et al., 2018) • •33 (MOGI; NAKAYAMA; ASAKA, 2018) •34 (KAN; CHIANG; WEI, 2018) •35 (ENNYA; HADI; ABOUAOMAR, 2018) • • •36 (XU et al., 2017) • • •37 (KOLOMVATSOS; ANAGNOSTOPOULOS, 2018) •38 (STHAPIT; HOPGOOD; THOMPSON, 2017) •39 Este Trabalho • • • • •
Tabela 1 – Comparativo dos Trabalhos Relacionados
Observa-se nestes trabalhos, que nem sempre adotou-se um simulador próprio para Fog
35
Computing, pois o objetivo foi validar o modelo proposto, seja na forma matemática, usando
ferramentas como Matlab ou implementando de forma própria. Contudo, nem todos os traba-
lhos esclarecem em detalhes como foi realizada a validação, que linguagens de programação
utilizou-se, que quantidade de sensores, nós de nevoeiro e outros dados que possam ser rele-
vantes. Dos trabalhos que implementaram fisicamente, os hardwares adotados foram placas
dotadas de algum MPSOC, como Raspberry PI 3 ou DragonBoard (BANERIEE et al., 2018), e
ainda utilizou-se servidores com arquitetura x86 (ZHU et al., 2018) (NA et al., 2018).
O consumo de recursos computacionais relacionado em alguns destes, refere-se aos re-
cursos computacionais utilizados após a implementação do algoritmo proposto para balancear a
carga entre os nós da névoa, ou seja, se houve uma distribuição de fato da carga computacional
entre os nós. Por outro lado, o tempo de resposta relaciona-se com a latência da rede, ou ainda,
com o tempo de processamento do pacote por parte do nó, acrescido da latência da rede.
2.6 CONSIDERAÇÕES DO CAPÍTULO
Entende-se, portanto, que ao contrário dos trabalhos acima citados e relacionados na
Tabela 1, todas as características computacionais dos nodos computacionais que compõem a
Computação em Névoa precisam ser consideradas para a realização do balanceamento de carga.
Uma vez que um nodo possui largura de banda de rede disponível, mas com baixos recursos
computacionais, este nodo precisa ser avaliado se o mesmo possui condições de receber mais
tarefas a serem processadas. Nodos da Computação em Névoa por si só não possuem esta ha-
bilidade intrínseca de discernir as mudanças comportamentais repentinas do ambiente, então o
Balanceamento de Carga torna-se uma tarefa vital para este cenário, em função da heteroge-
neidade dos nodos que compõe a Névoa e da dinamicidade das requisições das aplicações de
Internet das Coisas.
Neste capítulo observou-se a relevância do tema de pesquisa, endereçando os principais
trabalhos relacionados que tentam mitigar a questão do tempo de resposta e heterogeneidade dos
nodos na computação de borda/nevoeiro. Como forma de validação, observa-se que a maioria
dos artigos encontrados tiraram proveito da simulação como forma de consolidar o modelo
proposto. Mesmo em simulações, optou-se por validar o trabalho através da implementação de
ferramentas específicas para cada cenário, uma vez que simuladores como iFogSim possuem
suas especificidades para o cenário de Computação em Nuvem e Computação em Névoa focada
no gerenciamento e consumo de energia. Apesar deste ser um ponto de suma importância, nem
36
todos os trabalhos observaram esta característica para realizar a alocação de tarefas nos nodos
computacionais.
37
3 PROPOSTA
Neste capítulo é apresentado o balanceador de carga proposto neste trabalho chamado
de SmartFogLB. Na Seção 3.1 são detalhadas as camadas da arquitettura e a sua atuação. Na
Seção 3.2 são descritos os módulos implementados para o funcionamento do balanceador de
carga proposto. Na Seção 3.2.1 o algoritmo de tomada de decisão de balanceamento de carga
do SmartFogLB é detalhado.
3.1 SMARTFOGLB
Nesta seção é apresentado o balanceador de carga SmartFogLB proposto neste trabalho.
Na Figura 6 é apresentado o Diagrama da Arquitetura proposta onde são explicitadas as três
camadas envolvidas no processo de alocação de tarefas, que compreende desde a origem dos
dados, na camada das aplicações de Internet das Coisas, até a camada da Computação em
Nuvem.
Figura 6 – Diagrama da Arquitetura Proposta
Fonte: AUTOR
Neste modelo proposto, tem-se três camadas envolvidas, que serão descritas nas seções
à seguir. Nota-se que a dependência de recursos computacionais não deixará de existir, contudo,
agora a infraestrutura computacional necessária está próxima da camada de Internet das Coisas.
38
3.1.1 Camada de Nuvem
Nesta, tem-se a Computação em Nuvem e todos os seus recursos tecnológicos que pro-
porcionam serviços de computação, rede e armazenamento, mas que ficam longe dos sensores
da IoT. Esta camada recebe os dados da camada inferior, e então os dados são persistidos e
podem ser utilizados para alimentar outros sistemas mais complexos que demandam um alto
poder computacional. Em caso de falta de recursos computacionais na camada de nevoeiro,
esta camada poderá atuar também como um escape para suprir as demandas dos sensores da
camada de Internet das Coisas.
Sendo assim, esta camada não está diretamente envolvida com o pré-processamento
dos dados oriundos das aplicações de Internet das Coisas, cuja responsabilidade principal é a
camada do nevoeiro. Porém, nesta, tem-se o controlador do nevoeiro, o qual é responsável pela
gerência dos nodos da camada de borda. Sendo assim, o controlador tem o objetivo de alocar
mais recursos de nevoeiro na borda da rede, mais balanceadores, ou ainda, direcionar o tráfego
para ser processado na Nuvem, quando for o caso.
3.1.2 Camada de Borda
A Camada de Borda possui os recursos computacionais, ou seja, os nodos do nevoeiro
disponíveis para realizar a computação dos dados oriundos dos sensores/atuadores da camada
inferior. Aqui tem-se os nodos computacionais com capacidades suficientes para que possam
atuar como gateways dos nodos da IoT. Além disso, esta camada está em constante comunicação
com os servidores em Nuvem para envio de dados para armazenamento permanente, onde os
dados serão utilizados para fornecer informações para outros sistemas mais complexos, os quais
demandam um alto poder de processamento, como por exemplo bancos de dados, sistemas de
gestão e controle, dentre outros.
Nesta camada, portanto, tem-se a responsabilidade do processamento dos dados, assim
como a tomada de decisões com baixo tempo de resposta para as aplicações dos sensores da
primeira camada. É composta essencialmente de nodos computacionais com pouco poder com-
putacional em relação às máquinas virtuais na Computação em Nuvem, todavia, estes nodos são
em maior quantidade, e seu poder computacional é maior do que os sensores que integram as
aplicações de IoT. Podem ser entendidos como um gateway, o qual agrega os dados, processa-os
e gera informações para tomada de decisão em sistemas que possam estar em Nuvem, enviando
39
seus dados para este último. Nesta camada tem-se a presença do balanceador de carga proposto
neste trabalho, o qual será explicado nas próximas seções.
3.1.3 Camada das Aplicações IoT
Sendo a camada inferior ilustrada na Figura 6, trata-se da camada de percepção/atuação,
onde tem-se os sensores/atuadores pertencentes às mais diversas aplicações de IoT, via de regra
em rede local, com conectividade sem fio. Esta camada é aplicada nos mais diversos contextos,
como saúde, no monitoramento de pacientes, um campus inteligente, no monitoramento de suas
estruturas de salas de aula inteligentes, ou ainda, sobre algo maior, em uma cidade inteligente,
aplicado à um subsistema para prover uma infraestrutura de transportes inteligentes.
A Camada das Aplicações de IoT tem um papel muito importante neste contexto, uma
vez que tais sensores/atuadores coletam os dados do ambiente ao qual estão inseridos, e os
reportam para a Camada de Borda, que, por sua vez, realiza o processamento dos dados, e se
for o caso, pode enviar um retorno ao sensor ou ao atuador. Em um cenário hipotético de uma
sala de aula inteligente, por exemplo, os dados de temperatura, impressões digitais de alunos,
são enviados à um o mais nodos computacionais com poder de processamento para que se tome
decisões, como abrir a porta, registrar a presença do aluno, ligar o climatizador, dentre outras
ações, que possam vir a ser implementadas.
3.2 BALANCEADOR DE CARGA (BC)
O desbalanceamento da carga de trabalho, como dito na seção 2, pode ocasionar um
atraso nos tempos de respostas para as aplicações de Internet das Coisas. Portanto, o balancea-
dor de carga executa um papel de suma importância no paradigma de Computação em Névoa, o
qual deve conhecer todos os seus nodos computacionais que estão à sua disposição, assim como,
seus respectivos recursos computacionais, inclusive os que já estão sendo utilizados, para que
a tomada de decisão seja o mais próximo do ideal possível. Entende-se que o ideal, para este
trabalho, seria o menor tempo de resposta, para as tarefas. Alocar uma tarefa em um nodo que
esteja sem recursos computacionais ou, sem recursos de rede disponíveis, pode resultar na perda
da tarefa, ou no longo tempo de execução, o que pode trazer consequências negativas para as
aplicações de tempo real.
Para realizar a alocação de tarefas entre os nodos do nevoeiro, sob o ponto de vista deste
40
trabalho, assim como descrito no Capítulo 2, o algoritmo proposto leva em consideração todas
as características computacionais dos nodos, como utilização de CPU, de memória, armaze-
namento, de rede e prioridade da tarefa. Para que se obtenha os menores tempos de reposta
possíveis para as aplicações de Internet das Coisas, o balanceador aloca as tarefas em dife-
rentes nodos computacionais, a fim de obter uma melhor utilização dos recursos disponíveis
no mesmo. Contudo, esta alocação segue os critérios de análise de disponibilidade de recur-
sos computacionais que estejam disponíveis nos nodos. Especificamente, para a arquitetura do
balanceador de carga, que é ilustrada na Figura 7, destacam-se os seguintes módulos:
1. Módulo de Fila de Tarefas: para cada tarefa que chega no balanceador, oriunda dos sen-
sores/atuadores, as mesmas são colocadas em uma fila.
2. Módulo Tabela de Nodos: cada nodo computacional que compõem camada de borda é
elencado em tempo de execução em uma tabela em memória. Um daemon é responsável
pelo monitoramento das informações dos recursos computacionais destes nodos, para
aplicação das políticas de balanceamento.
3. Módulo de Balanceamento: o lugar onde acontece a alocação da tarefa no nó mais apro-
priado, baseado nas características discutidas anteriormente.
4. Módulo de Retorno: uma vez que a tarefa está concluída, caso haja necessidade, o balan-
ceador poderá retornar uma resposta à quem enviou a tarefa.
5. Módulo de Comunicação com o Controlador: para atualizações e monitoramento do ba-
lanceador de carga, com uma visão geral do sistema.
Toda tarefa que chega no balanceador, independente de sua prioridade, vai entrar em
uma fila. Caso o sistema esteja com recursos computacionais disponíveis, rapidamente a mesma
será retirada e alocada em um nodo por meio do algoritmo de balanceamento. No entanto, se
todos os nodos estão sobrecarregados a tarefa permanece na fila, aguardando o algoritmo para
retirá-la.
O módulo de balanceamento de carga é o ponto central desta seção. Neste, o algoritmo
proposto realiza a retirada das tarefas da fila, e as aloca nos nodos computacionais da Névoa,
baseado em sua prioridade e na política de alocação. Para a correta alocação das tarefas, um
daemon percorre todos os nodos computacionais do nevoeiro, para saber quais nodos estão com
recursos de computação e rede disponíveis, sendo que tais recursos são disponibilizados para o
41
Figura 7 – Arquitetura Balanceador.
Fonte: AUTOR
algoritmo de balanceamento de carga. Com estas informações, o algoritmo realiza a alocação
da tarefa no nodo mais apropriado.
Alguns dispositivos realizam suas tarefas apenas através do envio de seus dados para a
camada de nevoeiro, os quais não precisam receber o retorno de quem recebeu a tarefa. Todavia,
outros tipos de sensores, ou ainda atuadores, podem vir a necessitar de um retorno vindo da
camada superior, com o objetivo de receber instruções para, por exemplo, executar determinada
ação, como ligar uma luz ou abrir uma porta. Caso o sensor ou atuador necessite de um retorno
da tarefa enviada ao balanceador, o módulo de balanceamento encaminhará a resposta para
o módulo de retorno, que irá interagir com o dispositivo final, enviando para ele o retorno
requerido.
O módulo de comunicação com o controlador, por outro lado, é responsável pela in-
teração do balanceador de carga com o seu controlador, que é alocado na camada de nuvem.
A função do controlador é o monitoramento e gerenciamento da infraestrutura como um todo,
onde são definidas as políticas de alocação de tarefas, prioridades dos sensores para fins de
balanceamento e monitoramento dos recursos computacionais do balanceador de carga e seus
42
nodos, assim como questões de escalabilidade.
3.2.1 Algoritmo
O algoritmo de balanceamento de carga, para fins de tomada de decisão, necessita de
algumas informações. Dentre elas, destacam-se informações sobre recursos computacionais e
recursos de rede do nodo. Tais características precisam ser conhecidas em tempo de execução,
uma vez que dada a dinamicidade do ambiente, estes valores podem ser alterados de forma
repentina, então estas métricas precisam ser atualizadas periodicamente. Neste caso, o módulo
daemon executa um papel de suma importância no algoritmo proposto, o qual torna-se respon-
sável pela coleta dos dados referentes aos recursos computacionais dos nodos na Camada de
Borda, que é ilustrado no Algoritmo 1.
Algoritmo 1 Algoritmo do Daemoninput : A Fog array fog_array and a threshold thrld .output: A new Fog array with data of each Fog node f adjusted.
foreach Fog Node f doload ← getLoad(f )memory ← getMemory(f )network ← getNetwork(f )storage ← getStorage(f )if ((load ≤ thrld ) and (memory ≤ thrld ) and (network ≤ thrld ) and (storage ≤ thrld ))then
fog_array[ ]← fend
end
Para a correta execução do algoritmo do daemon, precisa-se de dois parâmetros: o ar-
ray de nodos, o qual caracteriza-se como uma lista dos nodos computacionais que compõem
o nevoeiro, alocados em um vetor, pelo qual o balanceador de carga é o responsável pela dis-
tribuição de tarefas. O threshold, caracteriza-se como um limite, o qual indica, para fins deste
trabalho, o limite máximo do percentual de utilização de recursos computacionais e de rede de
cada nodo de nevoeiro.
Observa-se que o algoritmo do daemon recebe como parâmetro um array dos nodos do
nevoeiro, assim como o threshold que é pré-definido pelo administrador do sistema. De posse
destas duas grandezas, o mesmo analisa todos os nodos que compõem o nevoeiro, bem como
seus recursos computacionais, índice de utilização de CPU, memória, rede e armazenamento.
Feito isto, o algoritmo compara se estes valores de utilização estão abaixo do threshold estabe-
43
lecido inicialmente. Caso todos os índices de utilização estejam abaixo, o nodo será adicionado
em uma lista. No final da execução, o algoritmo do daemon irá retornar esta lista para o algo-
ritmo principal do balanceamento, no caso, o Algoritmo 2. Se o nodo que foi verificado estiver
com algum de seus índices de utilização acima do threshold estabelecido, este nodo não será
adicionado à lista, uma vez que tal comportamento poderá comprometer os tempos de resposta
para as aplicações, e por consequência, não fará parte da alocação de tarefas neste ciclo.
Algoritmo 2 Algoritmo propostoinput : A Fog array fog_array, a Queue Priority array queue_array and a task t.output: A Queue Priority array adjusted and a task allocation
prio ← getTaskPrio(t)if (prio 6= high) then
queue_array[tail]← task(t)else
queue_array[head]← task(t)end
fog_array[] ← getFogsNodesfromDaemon ()max_Wload ← getMaxLoad(fog_array[] ) min_Wload ← getMinLoad(fog_array[] )
while (queue_array 6= empty) doprio ← getTaskPrio() if (prio 6= High) then
allocateFogNode(t, max_Wload )else
allocateFogNode(t, min_Wload )end
end
O Algoritmo 2 descreve a forma de alocação da tarefa no balanceador de carga proposto.
Observa-se que o mesmo recebe como entrada a lista dos nodos de nevoeiro (fog_array), a lista
da fila e também a tarefa oriunda das aplicações de Internet das Coisas. No momento em que
a tarefa chega no balanceador, a mesma entra em uma fila. O algoritmo que faz a alocação
da tarefa vai analisar se a prioridade da mesma é alta ou baixa, e então, realizar a alocação
adequada na fila. Para o caso da tarefa ser de alta prioridade, a tarefa entra no começo da fila e,
se baixa prioridade, no final da mesma.
Após, o algoritmo irá obter os dados de utilização dos recursos computacionais dos
nodos de nevoeiro através da chamada do algoritmo do daemon, para obter a lista atualizada
com os recursos computacionais e de rede. Sendo assim, irá analisar os índices de utilização,
sendo que o índice do nodo com o maior número de recursos computacionais disponíveis será
armazenado, assim como o índice do nodo com menor número de recursos computacionais
também.
44
Uma vez que estas tarefas de pré-agendamento estejam concluídas, será realizada de fato
a alocação das requisições. Ou seja, enquanto a fila de tarefas não estiver vazia, o algoritmo
do balanceador proposto avalia a prioridade da tarefa. Se a mesma possui prioridade alta, o
médoto allocateFogNode vai alocar a mesma no nodo com a menor utilização de carga de
trabalho, senão, no nodo com maior carga de trabalho, ou seja, o balanceador encaminha as
mesmas para o nodo cuja quantidade de tarefas recebidas é inferior aos demais nodos, o que
indica que o mesmo pode ter um baixo poder de processamento.
Neste trabalho, assim como em (JUNIOR, 2017), definiu-se um threshold de 90% da ca-
pacidade total, tanto computacional quanto de rede, como o limite para zerar a nota do nodo na
Névoa. Ou seja, caso algum item computacional ou de rede estiver com seu índice de utilização
igual ou superior à este threshold, automaticamente o nodo não receberá tarefas para processar.
3.3 CONSIDERAÇÕES DO CAPÍTULO
Neste capítulo procurou-se elucidar a proposta deste trabalho. Inicialmente, apresentou-
se a arquitetura de todo o sistema de Internet das Coisas, bem como o posicionamento dos
nodos de nevoeiro dentro dele, e então, uma discussão sobre cada camada foi realizada. Então,
procedeu-se a descrição do balanceador de carga em si, descrevendo-se os módulos que o com-
põe. Então, apresentou-se os algoritmos de daemon e o algoritmo proposto, assim como suas
respectivas descrições e detalhamentos.
45
4 METODOLOGIA
Neste capítulo será apresentada a metodologia utilizada para avaliação do algoritmo pro-
posto. Na Seção 4.1 é detalhado como cada tarefa foi modelada para então chegar ao resultado.
Na Seção 4.2, descreve-se os tipos de nodos computacionais que foram utilizados, como carac-
terísticas de recursos computacionais e de rede. Na Seção 4.3 é detalhado o ambiente utilizado
para testes.
Segundo os autores (CASAVANT; KUHL, 1988), o problema do balanceamento de
carga tem três maiores componentes: consumidores, recursos e políticas. Sendo assim, para
este trabalho, definiu-se como consumidores os sensores/atuadores e outros dispositivos inteli-
gentes que estão na camada de Internet das Coisas. Os recursos, por sua vez, posicionam-se na
de borda, que são os nodos com capacidade computacional disponível, os quais estão à dispo-
sição do balanceador de carga. Por fim, as políticas referem-se ao modo como se dá de fato o
balanceamento de carga, no que diz respeito à algoritmos e técnicas, as quais são consultadas
pelo algoritmo de balanceamento de carga em tempo de execução, com o objetivo de realizar a
alocação das tarefas.
A simulação foi escolhida como forma de validação da proposta. Sendo assim, modelou-
se um sistema para tal, o qual possui métodos específicos para cada abordagem de balancea-
mento de carga, com tarefas, nodos de nevoeiro, para que sejam medidos os tempos de resposta
em cada abordagem adotada no balanceamento de carga.
Segundo o autor (WAZLAWICK, 2017), este trabalho denota uma pesquisa quantitativa.
Isto significa que, uma vez que pretende-se quantificar os ganhos de desempenho, procedeu-se
o desenvolvimento de uma ferramenta para simular o ambiente em questão. Também, definiu-se
formas para medir e capturar os tempos de resposta, que é o principal objetivo deste trabalho.
4.1 CONFIGURAÇÃO DAS TAREFAS DOS CONSUMIDORES DE RECURSOS
Para realizar a simulação, um conjunto de tarefas foi definido. Estas tarefas simulam
requisições que partem dos sensores/atuadores da camada de Internet das Coisas, as quais pos-
suem requisitos mínimos para que sejam executadas em tempo hábil. Sendo assim, os autores
em (TALAAT et al., 2019) realizaram uma simulação com três níveis de tarefas para a camada
de Internet das Coisas. Para este trabalho, com o intuito de validar a abordagem proposta,
46
utilizou-se este mesmo modelo, que é demonstrado na Tabela 2.
Tipo CPU (Mhz) Memória (MB) Armazenamento (MB) Rede (Mb)Leve 80 12 2 1Média 100 20 4 2Pesada 120 25 8 4
Tabela 2 – Configuração das Tarefas usadas na simulação
Os recursos computacionais e de rede tornam-se necessários para fins de escalonamento
no balanceador de carga. Adicionalmente, as tarefas acima modeladas podem ter prioridades
diferentes, neste trabalho definiu-se que as mesmas podem ser de prioridade alta ou baixa,
porém, isto é definido pelo administrador da rede.
Caso a tarefa em questão tenha prioridade alta, uma abordagem de escalonamento que
faça a mesma ser alocada no início da módulo da fila é adotado. Caso contrário, a mesma será
alocada no final do módulo da fila, para que se priorize as tarefas mais importantes primeiro.
4.2 CONFIGURAÇÃO DOS NODOS COMPUTACIONAIS DE BORDA
Para fins deste trabalho, assim como do ambiente de simulação, um conjunto de nodos
computacionais do nevoeiro foi modelado. Estes nodos tornam-se necessários para realizar a
alocação de tarefas que partem da camada da Internet das Coisas para que sejam processadas
na camada de nevoeiro. Sendo assim, os tempos de respostas para as aplicações de Internet das
Coisas tendem a ser inferiores quando os mesmos são enviados aos servidores de Computação
em Nuvem. Portanto, para este trabalho, modelou-se três tipos de nodo computacional, sendo
que a Tabela 3 ilustra os mesmos, assim como suas capacidades computacionais, como número
de núcleos do processador, frequência dos núcleos, memória, armazenamento e capacidade de
rede.
Tipo Núcleos de CPU CPU (Mhz) Memória (MB) Armazenamento (MB) Rede (Mb)Pequeno 1 600 512 2048 50Médio 2 800 1024 4096 80Grande 4 1200 2048 10240 100
Tabela 3 – Definição dos nodos da Camada de Borda
A capacidade computacional dos nodos, podem ser equivalentes à equipamentos de rede
como pontos de acesso sem fio, ou ainda, unidades computacionais como Raspberry PI. Sendo
assim, estes equipamentos são responsáveis por acomodar as tarefas que vêm da camada de
47
Internet das Coisas e então processar as mesmas, para que seja realizada a tomada de decisão
em aplicações de IoT que precisam de tempos de respostas menores.
4.3 AMBIENTE DE SIMULAÇÃO
Para fins de validação da proposta deste trabalho, conduziu-se os experimentos em am-
biente de simulação, ou seja, procedeu-se o desenvolvimento de um sistema para simular o
trabalho proposto. O autor Ian Sommerville (SOMMERVILLE, 2011) classifica os requisitos
do processo de desenvolvimento de software como funcionais e não funcionais. O requisitos
funcionais dizem respeito às funcionalidades do sistema, ou o que ele deve fazer. Já os requisi-
tos não funcionais, referem-se às restrições que o sistema impõe para sua execução. Como por
exemplo, o sistema precisa executar um relatório em tempo hábil, ou, um sistema precisa de
sistema operacional Linux.
Para o trabalho proposto, definiu-se que o ambiente de simulação precisa atuar com
threads. Isto implica que, necessariamente, a linguagem de programação escolhida precisa
trabalhar com esta característica. Atuar com programação paralela usando esta técnica, via de
regra está ligado ao fato de se obter alta performance, para diminuir o tempo de computação de
um sistema. Todavia, para fins deste trabalho, o recurso de threads dá ao ambiente de simulação
outra característica: a de simultaneidade. Sendo assim, pode-se simular o mais próximo do que
seria um ambiente real, onde cada sensor que compõem a camada da Internet das Coisas, pode
enviar seus dados de forma aleatória ao balanceador de carga, o que provoca uma demanda
computacional e otimização do algoritmo muito maior.
Como requisito funcional, portanto, trabalhar com thread tornou-se uma premissa im-
portante. Dentre as muitas linguagens de programação que suportam a programação paralela, a
linguagem de programação adotada para este trabalho o Python 2, uma vez que tal linguagem
tem grande destaque nos trabalho acadêmicos, isto porque a implementação ocorre de forma
mais rápida, e a linguagem oferece uma grande extensão de bibliotecas que estendem as suas
funcionalidades.
O principal requisito não funcional para este trabalho foi a execução do ambiente de
simulação em sistema operacional Linux. Isto se deve ao fato de, em ambiente de simulação
de alta performance, o Linux tem sido o sistema operacional predominante. Assim como, a lin-
guagem de programação já vem como padrão em várias distribuições de Linux, o que facilitou
2 https://www.python.org/
48
o trabalho de configuração do ambiente de simulação.
Uma vez lavantados os requisitos funcionais e não funcionais, definiu-se o diagrama de
classes UML do sistema, o qual é ilustrado pelo diagrama UML na Figura 8. Para a simulação,
modelou-se duas classes abstratas, de nome Tarefa e Política, as quais servem de modelo de
herança para as classes físicas do sistema da simulação, garantindo-se assim que as mesmas
nunca serão implementadas sozinhas.
Figura 8 – Diagrama UML do Ambiente de Simulação.
Fonte: AUTOR
Ainda, sobre a multiplicidade do sistema, observa-se que os nodos de nevoeiro, neces-
sariamente, podem possuir zero ou 1 balanceador. Na situação em que o simulador possuir zero
balanceadores, significa que o ambiente está operando no modo sem balanceador de carga, ou
seja, os sensores de IoT estão conectados e enviando tarefas diretamente aos nodos. A priori-
dade, que é definida anteriormente pelo administrador do sistema, faz parte da classe NodoIoT,
e não da tarefa, visto que os nodos são os responsáveis de fato para o envio de tarefas ao seu
49
respectivo gateway, seja o nodo de nevoeiro, ou o balanceador de carga.
Os testes foram realizados em uma máquina virtual alocada no provedor de nuvem pú-
blica da Amazon Web Services, do tipo ’c5.18xlarge’, com 72 núcleos, 144 Gb de memória
Ram, e 50Gb de armazenamento. Para realizar a alocação do servidor virtual, precisa-se criar
uma instância do tipo EC2, que é o nome do produto deste provedor de nuvem, como é ilustrado
na Figura 9.
Figura 9 – Criação de Servidor Virtual
Ao clicarmos no botão ’Launch Instance’, precisa-se escolher o tipo e versão do sistema
operacional, que é ilustrado na Figura 10. Para este trabalho, definiu-se o sistema operacional
Linux Debian, versão 9.
Figura 10 – Criação de Servidor Virtual: Escolha do Sistema Operacional
Uma vez definido o sistema operacional, a Figura 11 nos mostra as opções de tamanho
de recursos computacionais de cada versão de máquina virtual deste provedor de serviços de
nuvem.
Dada a quantidade de sensores e atuadores da simulação, assim como a quantidade de
nodos de nevoeiro, optou-se por uma quantidade mínima de núcleos de processamento, para que
as threads que executam em paralelo não venham a bloquear umas as outras. Por conta disso,
50
Figura 11 – Criação de Servidor Virtual: Escolha dos Recursos Computacionais
a quantidade de núcleos do servidor escolhido está de acordo com a quantidade de threads que
serão executadas simultaneamente.
Esta plataforma executa o sistema operacional não modificado Debian Linux, versão 9,
arquitetura de 64 bits, com versão do kernel 3.0.101-0.29. Os testes foram compilados usando
a linguagem de programção Python, versão 3.7, sendo que os resultados apresentados são a
média de 100 execuções.
Portanto, definiu-se três cenários, variando a quantidade de requisições, sendo eles con-
tendo 100, 500 e 1.000 requisições por sensor, para a quantidade de 60 sensores contendo 6
nodos de Névoa. Para cada sensor e nodo da Névoa, o simulador aciona uma thread, a qual
simula as requisições simultaneamente no balanceador de carga, assim como, para o algoritmo
de balanceamento proposto, totalizando 67 threads no sistema. Para este trabalho, a utilização
de threads torna-se especificamente útil para que se possa dar uma simultaneidade na simula-
ção, com o objetivo de testar os limites do algoritmo de balanceamento proposto. Definiu-se
também que 50% dos sensores possuem prioridade alta, onde o algoritmo será forçado a realizar
a avaliação dos recursos computacionais e de rede de cada nodo. A quantidade de simulações
foi de 27 testes, em um total de 2700 simulações.
51
5 RESULTADOS
Esta seção apresenta os resultados alcançados quando aplicado o BC proposto em dife-
rentes cenários. Cada cenário, possui variações de tamanho de nodos de nevoeiro, quantidade
de requisições, assim como o tipo de algoritmo de balanceamento, ou, para o caso do cenário
sem balanceador, com conexão direta ao nodo do nevoeiro. A seção 5.1 nos mostra como os
experimentos foram conduzidos. A seção 5.2, traz os resultados quando a simulação não adotou
nenhuma abordagem de BC, ou seja, os nodos da camada de Internet das Coisas foram conec-
tados diretamente aos nodos de nevoeiro. Na seção 5.3, utilizou-se a abordagem de algoritmo
de round-robin, e, na seção 5.4, mostra-se os resultados quando realizada a simulação adotando
o algoritmo proposto neste trabalho.
5.1 EXPERIMENTOS
Com o intuito de validar a eficiência do BC proposto, foram realizados testes utilizando
3 cenários:
• Cenário sem balanceador de carga;
• Cenário com o algoritmo Round-Robin e;
• Cenário com o algoritmo proposto SmartFogLB.
Inicialmente, precisa-se medir a performance do ambiente sem a presença de qualquer
balanceador de carga, para que se possa entender como o sistema se comporta, e assim, cap-
turar seus tempos de resposta para com os sensores e atuadores da Internet das Coisas. Após,
definiu-se também que é importante simular o mesmo ambiente, agora usando um algoritmo de
balanceamento de carga estático, como o Round-Robin. Isto porque, deseja-se entender se este
algoritmo tem resultados satisfatórios, uma vez que neste cenário existe a distribuição de tarefas
entre os nodos computacionais do nevoeiro. Por fim, simulou-se o mesmo ambiente, agora com
a adoção do trabalho proposto SmartFogLB, para que se possa entender e analisar se houve
ganhos, no sentido de diminuição dos tempos de resposta para com os sensores e atuadores da
IoT.
Em cada teste, foi utilizado 3 quantidades de requisições. Desta forma cada sensor da
camada de IoT envia ao seu gateway 100, 500 e 1.000 de requisições. Assim, a quantidade de
52
testes realizados em cada cenário é apresentada na Tabela 4. Tal montante de requisições foi
definido em função da heterogeneidade dos sensores e atuadores da camada de IoT, assim como
nos trabalhos dos autores (TALAAT et al., 2019) e (VERMA; BHARDWAJ; YADAV, 2016).
ID Tamanho do Nodo Fog Tamanho da Tarefa Requisições1 Pequeno Leve 1002 Pequeno Leve 5003 Pequeno Leve 10004 Pequeno Média 1005 Pequeno Média 5006 Pequeno Média 10007 Pequeno Pesada 1008 Pequeno Pesada 5009 Pequeno Pesada 1000
10 Médio Leve 10011 Médio Leve 50012 Médio Leve 100013 Médio Média 10014 Médio Média 50015 Médio Média 100016 Médio Pesada 10017 Médio Pesada 50018 Médio Pesada 100019 Grande Leve 10020 Grande Leve 50021 Grande Leve 100022 Grande Média 10023 Grande Média 50024 Grande Média 100025 Grande Pesada 10026 Grande Pesada 50027 Grande Pesada 1000
Tabela 4 – Testes Realizados na Simulação
Como descrito acima, foram realizados experimentos em um ambiente onde não há a
presença do balanceador de carga. Sendo assim, mediu-se sempre os tempos de respostas das
requisições realizadas pelos sensores. Uma vez que em um ambiente sem balanceador, não há
como diferenciar tarefas de alta ou baixa prioridade, pois, como dito anteriormente, esta não é
uma característica intrínseca do paradigma de Computação em Névoa. Sendo assim, para este
ambiente, a alocação fixa de sensores por nodo de nevoeiro foi realizada, tendo a quantidade de
10 sensores por nodo.
Após, realizou-se a simulação utilizando um algoritmo de balanceamento de carga co-
53
nhecido como Round-Robin (RR) (PANDA; BHOI, 2014). A ideia geral desta simulação
caracteriza-se como a alocação das requisições oriundas dos sensores da camada de IoT em
um modelo de fila circular, onde para cada requisição que chega, o agendador RR aloca no
próximo nodo do nevoeiro; quando todos os nodos foram alocados, então retorna-se ao pri-
meiro nodo e a alocação permanece neste círculo. Neste modelo de balanceamento, não há
conhecimento das prioridades das tarefas, dada que esta não é uma implementação típica para
este cenário, assim como, não há o conhecimento por parte do agendador RR sobre o índice de
utilização dos recursos computacionais dos nodos. Sendo assim, embora os nodos do nevoeiro
possam estar sobrecarregados, o agendador RR enviará requisições aos mesmos.
Por fim, executou-se a simulação utilizando o algoritmo proposto neste trabalho. Os
índices de threshold foram mantidos os mesmos nas três simulações, assim como as quantidades
de recursos computacionais dos nodos e as que foram requeridas pelos sensores. Sendo assim,
os resultados obtidos foram executados em igualdade de ambiente de simulação.
5.2 ANÁLISE DOS RESULTADOS EM UM CENÁRIO SEM BALANCEADOR DE CARGA
Nesta seção, são apresentados os resultados dos testes realizados sem a presença do
balanceador de carga no ambiente de simulação. Deste modo, os nodos da camada da Internet
das Coisas conectam-se diretamente aos nodos da camada de Computação em Névoa.
Percebe-se que neste cenário, as tarefas geradas pelos sensores/atuadores, não possuem
distinção de prioridade. Portanto, os nodos do nevoeiro simplesmente recebem as tarefas oriun-
das da camada da Internet das Coisas, sendo que, desta maneira, os sensores/atuadores não
conhecem a carga de trabalho real dos nodos do nevoeiro. Portanto, os nodos da camada de IoT
apenas enviam tarefas para que sejam processadas pelos nodos da Computação em Névoa, os
quais processam e retornam o tempo de resposta para o ambiente de simulação.
Na Figura 12 é ilustrado os tempos de resposta mensurados na simulação para o ambi-
ente sem a adoção do balanceamento de carga. Neste cenário, utilizou-se os nodos de nevoeiro
do tamanho pequeno, variando-se a quantidade de requisições ao nodo.
Com esta simulação é possível observar que as tarefas pesadas foram responsáveis pelos
maiores tempos de resposta, mesmo no cenário com 100 requisições enviadas ao nodo. Por
outro lado, as tarefas leve e média, obtiveram menores tempos de resposta, sendo que, as tarefas
leves sempre ficaram com seus tempos de resposta inferiores à 200 milissegundos.
Neste cenário, tem-se o ambiente mais desfavorável para o ambiente da Computação
54
Figura 12 – Tempos de Resposta com Nodos Pequenos
Fonte: AUTOR
em Névoa, no sentido de disponibilidade de recursos computacionais. Isto ocorre uma vez que
estão sendo utilizados nodos de nevoeiro pequenos, e soma-se ao fato do cenário com 1.000
requisições de tarefas do tipo pesadas. Sendo assim, a mínima variação no tamanho das tarefas,
expõe a fragilidade do ambiente quando não se tem um gerenciamento adequado dos recursos
computacionais.
No ambiente com nodos médios, o qual é ilustrado pela Figura 13, observa-se uma
diminuição nos tempos de resposta das tarefas oriundas da camada de Internet das Coisas. No-
vamente, os tempos de respostas das tarefas leves obtiveram os menores valores, sendo que
permaneceram abaixo de 1 milissegundo. As tarefas médias, por outro lado, obtiveram tem-
pos muito próximos, visto que neste ambiente, há um aumento na disponibilidade de recursos
computacionais.
Nas tarefas pesadas, por outro lado, os tempos de resposta ficaram heterogêneos, os
quais foram escalando de forma muito proporcional à variação de quantidade de requisições no
ambiente de simulação, ficando com proporções um pouco abaixo das variações em si. Mesmo
assim, nota-se mais uma vez a fragilidade do ambiente sem a gerência dos recursos computaci-
onais, onde o tempo aumentou em mais de 3 vezes, quando comparando o cenário com 100 e
1.000 requisições.
O ambiente de simulação que utilizou nodos de nevoeiro de tamanho grande é ilustrado
pela Figura 14. Neste cenário, podemos observar que todos os tempos de resposta ficaram
55
Figura 13 – Tempos de Resposta com Nodos Médios
Fonte: AUTOR
abaixo de 1 milissegundo, mesmo variando-se em 10 vezes a quantidade de requisições ao nodo.
Estes tempos baixos se dão pelo fato de que, neste ambiente de simulação com nodos grandes,
há uma disponibilidade maior de recursos computacionais para realizar o processamento das
informações que vem da camada da Internet das Coisas.
Figura 14 – Tempos de Resposta com Nodos Grandes
Fonte: AUTOR
As tarefas pesadas, que outrora em outros ambientes obteve os tempos de respostas
variando em 3 vezes mais, neste cenário observou-se que tais tempos permaneceram muito
56
parecidos, o que novamente comprova que a alta disponibilidade de recursos computacionais
se fez presente. Ou seja, pode-se concluir, portanto, que em um cenário sem balanceador de
carga, precisa-se disponibilizar muitos recursos computacionais para que se tenha um ganho
considerável em tempos de reposta baixos. Isto, por outro lado, pode comprometer o projeto de
Internet das Coisas ou de Computação em Névoa, uma vez que precisar-se-ão muitos recursos
financeiros para que se tenha um ambiente minimamente razoável para atender as requisições
do projeto.
5.3 ANÁLISE DOS RESULTADOS EM UM CENÁRIO COM O ALGORITMO ROUND-
ROBIN
Nesta seção, tem-se os resultados do trabalho, onde utilizou-se a presença do balancea-
dor de carga no ambiente de simulação, o qual adotou a política de escalonamento Round-Robin.
Sendo assim, embora neste cenário há a presença de um balanceador de carga, o mesmo não
possui a habilidade de entender as prioridades das tarefas oriundas das aplicações de Internet
das Coisas. Logo, o algoritmo de balanceamento de carga simplesmente envia as requisições
dos sensores/atuadores para o nodo do nevoeiro em um estilo de fila circular, independente-
mente da carga de trabalho e recursos computacionais que o nodo possui, inclusive, sem saber
se o respectivo nodo tem condições de executar o processamento da tarefa em questão.
Sendo assim, os nodos da camada da Internet das Coisas conectaram-se diretamente aos
nodos da Computação em Névoa. Neste sentido, as tarefas geradas pelos sensores/atuadores,
não possuem distinção de prioridade, assim como, os nodos do nevoeiro simplesmente rece-
bem as tarefas oriundas da camada da IoT. Portanto, desta forma os sensores/atuadores não
conhecem a carga de trabalho real dos nodos do nevoeiro, apenas enviam tarefas para que sejam
processadas.
Na Figura 15, o ambiente ilustrado diz respeito ao cenário com nodos de nevoeiro peque-
nos. Embora neste ambiente há a presença de um balanceador de carga, o que pode-se observar
são os altos tempos de resposta, quando comparados ao mesmo tipo de nodo de nevoeiro sem o
balanceador de carga, onde houve um aumento na média de 60% nos tempos de resposta neste
ambiente.
As tarefas leves obtiveram os menores tempos de resposta nesta simulação, contudo, a
diferença de tempos entre tarefas médias e pesadas aumentou, quando comparado ao cenário
sem balanceador de carga. No cenário com 100 requisições, a diferença entre as tarefas média e
57
Figura 15 – Tempos de Resposta com Nodos Pequenos
Fonte: AUTOR
pesada, foi de 27.9%, e no cenário sem balanceador de carga, de 25%. Em 500 requisições tem-
se a diferença de 20.7%, sem balanceador de carga, por outro lado, a diferença foi de 20.5%.
Por fim, com 1.000 requisições, 14.5% de diferença de tempo, sendo que no ambiente sem
balanceador de carga, a diferença foi de 11.5%. Sendo assim, observa-se que, ao aumentarmos a
carga de trabalho, o balanceador de carga Round-Robin não conseguiu manter uma estabilidade
para que se atenda as tarefas com tempos de respostas satisfatórios.
A Figura 16 nos mostra o cenário com nodos de nevoeiro médios. Novamente, os tem-
pos de resposta diminuíram, visto que percebe-se um aumento na disponibilidade de recursos
computacionais para processar as tarefas. Contudo, as tarefas leves e médias, obtiveram bons
tempos de resposta, ficando inclusive com valores próximos. Porém, mesmo assim, os tempos
de resposta, embora mais elevados, ficaram mais 47% mais homogêneos quando comparados
ao ambiente sem balanceador de carga. Sendo assim, quando há uma disponibilidade razoá-
vel de recursos computacionais, o balanceador de carga Round-Robin consegue manter uma
estabilidade melhor.
A Figura 17 ilustra-nos o ambiente de simulação que utilizou os nodos de nevoeiros
grandes. Neste cenário, tem-se uma disponibilidade maior de recursos computacionais, então
os tempos de reposta ficaram abaixo de 1 milissegundo para todas as quantidades de requisições
e tarefas. Mesmo assim, quando comparando com o ambiente sem balanceador de carga, os
tempos de resposta ficaram, em média, 52.3% mais altos.
58
Figura 16 – Tempos de Resposta com Nodos Médios
Fonte: AUTOR
Figura 17 – Tempos de Resposta com Nodos Grandes
Fonte: AUTOR
Observa-se, portanto, que mesmo utilizando-se um algoritmo de balanceamento de carga,
precisa-se avaliar qual a sua implementação. Embora o algoritmo Round-Robin tem suas van-
tagens em ambientes estáticos, para este trabalho o mesmo não teve bons resultados, ficando
abaixo do cenário sem balanceador de carga. Sendo assim, nota-se, mais uma vez, que a sim-
ples implementação de um algoritmo de balanceamento de carga no paradigma de Computação
em Névoa precisa ser analisada com cautela para que não se tenha tempos piores, o que pode
59
comprometer toda a aplicação de Internet das Coisas.
5.4 ANÁLISE DOS RESULTADOS EM UM CENÁRIO COM O ALGORITMO PROPOSTO
SMARTFOGLB
Nesta seção serão discutidos os resultados da simulação, a qual utilizou o algoritmo
proposto neste trabalho. Conforme descrito na Tabela 2, nos testes foram utilizados 3 tipos de
tarefas (Leve, Média e Pesada), as quais representam diferentes requisitos de CPU, Memória,
Armazenamento e Rede. Neste, o balanceador de carga possui as habilidades de distinguir
tarefas de baixa e alta prioridade, sendo que as tarefas de baixa prioridade serão analisadas
inicialmente no texto.
A Figura 18 nos mostra os resultados do ambiente de simulação que utilizou-se de nodos
de nevoeiro pequenos, para as tarefas de baixa prioridade. Este cenário com nodos pequenos,
assim como nas outras abordagens anteriores, demonstra ser um cenário muito crítico, uma vez
que tem-se pouca disponibilidade de recursos computacionais por parte dos nodos do nevoeiro,
mas as tarefas e suas respectivas quantidades permanecem as mesmas.
Figura 18 – Tempos de Resposta com Nodos Pequenos - Baixa Prioridade
Fonte: AUTOR
Observa-se, no cenário da Figura 18, que os piores tempos de resposta ficaram no am-
biente com 1.000 requisições de cada sensor. Neste, observando as médias dos tempos de
resposta, entre as tarefas pesadas e médias, tem-se que um aumento de 27.9%. Quando compa-
rado ao ambiente de Round-Robin, no mesmo cenário, tem-se a diferença de tempo em 14.5%;
60
no cenário sem balanceador, 11.5%. Isto ocorre porque o balanceador de carga proposto neste
trabalho consegue separar os níveis de tarefas, as quais possuem tempos de respostas condizen-
tes para seus níveis de exigências de recursos computacionais, o que comprova a efetividade do
trabalho proposto, mesmo em um cenário desfavorável no que diz respeito à disponibilidade de
recursos computacionais.
Em relação aos tempos de resposta, pode-se observar que a solução proposta obteve ga-
nhos em relação ao Round-Robin e ao ambiente sem balanceador. Em comparação ao ambiente
sem balanceador, os ganhos foram, em média, de 124%, mas nas tarefas leves, chegaram em até
251%. Em comparação ao algoritmo Round-Robin, por outro lado, os ganhos foram maiores,
onde alcançaram em média 279%, chegando em até 534% nas tarefas leves.
A Figura 19 ilustra-nos o ambiente de simulação com nodos médios e sensores de baixa
prioridade. Novamente, no cenário com 1.000 requisições, as tarefas do tipo pesadas obtiveram
o maior tempo de resposta. Nas demais quantidades de requisições, por outro lado, os tempos de
reposta ficaram mais homogêneos, o que mostra a estabilidade do balanceador de carga, mesmo
aumentando a quantidade de requisições.
Figura 19 – Tempos de Resposta com Nodos Médios - Baixa Prioridade
Fonte: AUTOR
Para o cenário de nodos médios, os ganhos são mais significativos, uma vez que a quan-
tidade de recursos computacionais dos nodos de nevoeiro aumentou. Em comparação ao ce-
nário sem balanceador de carga, o ganho geral nos tempos de resposta foi de 254%, contudo,
nas tarefas pesadas, atingiu-se ganhos em percentuais de 867%. Ou seja, mesmo com tarefas
61
que exigem mais recursos computacionais, o algoritmo proposto conseguiu tempos de resposta
abaixo das soluções anteriores.
Comparando-se este cenário com a solução de Round-Robin, os ganhos nos tempos de
resposta também foram maiores. Para este, o percentual geral foi de 349% abaixo, sendo que,
em tarefas pesadas, atingiu-se o percentual de 964%, ou seja, quase 10 vezes mais rápido do
que o ambiente anterior.
No cenário com nodos grandes, ilustrado pela Figura 20, observa-se uma alta queda
nos tempos de resposta quando comparados com os cenários anteriores. Uma vez que tem-
se uma alta disponibilidade de recursos computacionais, o balanceador de carga manteve seus
tempos de resposta homogêneos, onde a variação ficou em 6%, comparando-se tarefas médias
e pesadas.
Figura 20 – Tempos de Resposta com Nodos Grandes - Baixa Prioridade
Fonte: AUTOR
Para o ambiente com nodos grandes, observa-se ganhos nos tempos de reposta quando
comparamos os mesmos nos cenários anteriores. Porém, observa-se que neste cenário, dada a
maior quantidade de recursos computacionais, tem-se que a diferença não foi tão grande quando
comparado com os cenários com nodos pequenos e médios. Mesmo assim, o algoritmo proposto
obteve os menores tempos de resposta, o qual alcançou uma diminuição em média de até 61%
nos tempos de resposta quando comparado ao cenário sem balanceador de carga usando nodos
grandes, e obteve o maior índice percentual em tarefas leves, na marca de 86%. Para o ambiente
de Round-Robin, os tempos de resposta são menores ainda, diminuindo no geral em 145%, com
62
um alcance de até 186% em tarefas leves.
Para o cenário com tarefas de alta prioridade, os tempos de resposta também ficaram
menores. A Figura 21 nos mostra os resultados para o cenário de nodos de nevoeiro pequenos,
mas com tarefas de alta prioridade. Nota-se, neste resultado, que todos os tempos de reposta
permaneceram abaixo de 1 segundo, sendo que no cenário com 1.000 requisições de tarefas
pesadas, o tempo médio de reposta foi de 978, 97 milissegundos. Também, embora aumentou-
se em 10 vezes a quantidade de requisições, as tarefas médias permaneceram com seus tempos
abaixo de 800 milissegundos, sendo que, no cenário com baixa prioridade, tal resultado obtido
foi de 874 milissegundos para 1.000 requisições, ou seja, obteve um tempo de resposta 22.4%
menor, o que comprova a efetividade do mecanismo de prioridade.
Figura 21 – Tempos de Resposta com Nodos Pequenos - Alta Prioridade
Fonte: AUTOR
Quando comparamos a solução deste cenário com o ambiente sem balanceador de carga,
o percentual médio de diminuição nos tempos de resposta atingem 149%, mas podem alcançar
270% nas tarefas leves. No ambiente de baixa prioridade, os ganhos foram, respectivamente,
de 124% e 251%, o que comprova mais uma vez a efetividade do mecanismo de prioridade do
trabalho proposto.
Em relação à abordagem utilizando o Round-Robin, os ganhos médios foram de até
322%, contudo, em tarefas leves obteve-se um ganho de até 568%. Comparando-se com o
cenário de baixa prioridade, tem-se que o ganho médio foi de 279% no percentual de diminuição
do tempo de resposta, alcançando até 534% nas tarefas leves.
63
O ambiente de alta prioridade com nodos de nevoeiro médios é ilustrado na Figura 22.
Este cenário possui a vantagem de possuir mais recursos computacionais do que o cenário an-
terior, então os tempos de resposta foram menores, inclusive, em função da abundância de
recursos, os tempos ficaram próximos. Para a situação de 1.000 requisições, todavia, as tarefas
pesadas ainda consumiram o maior tempo de resposta. Porém, mesmo assim, quando com-
parado ao cenário de baixa prioridade, o tempo diminuiu no percentual de 10.6%. Portanto, o
mecanismo de prioridades ainda foi efetivo, mesmo com uma disponibilidade maior de recursos
de nodos de nevoeiro.
Figura 22 – Tempos de Resposta com Nodos Médios - Alta Prioridade
Fonte: AUTOR
Quando comparamos a solução acima com o ambiente sem balanceador, o percentual
de diminuição de tempo de resposta atingiu, na média, o valor de 260%, sendo que, em tarefas
pesadas, chegou-se em até 867% menos tempo. Para a solução proposta de baixa prioridade,
os índices de diminuição de tempos de resposta foram, na média, em 254%, chegando em
até 867% menos tempo nas tarefas pesadas. Na média geral, portanto, o mecanismo de fila
prioritária ganha destaque novamente, onde com exceção das tarefas pesadas, que obtiveram
os mesmos percentuais, no geral houve uma diminuição nos tempos de resposta em 6% apenas
mudando-se a prioridade dos sensores.
Por outro lado, ao comparar-se com a abordagem Round-Robin, percebe-se um ganho
médio na diminuição dos tempos de resposta de até 356%, atingindo-se, como percentual má-
ximo, o valor de 964% nas tarefas pesadas. Ao observarmos a mesma abordagem com baixa
64
prioridade, nota-se que os ganhos alcançados na média foi de 349% menos tempo de resposta,
alcançando igualmente o percentual de 964% como diminuição de tempo de resposta para tare-
fas pesadas.
Com nodos de nevoeiro grandes, o qual é ilustrado na Figura 23, observa-se os tem-
pos de resposta. Como neste cenário tem-se os maiores nodos computacionais de nevoeiro, os
tempos de resposta ficaram extremamente baixos, uma vez que os nodos podem processar as
requisições de forma mais rápida. Nota-se também, que os tempos de resposta permaneceram
muito próximos, em função da alta disponibilidade dos recursos computacionais. As tarefas
pesadas, que nos cenários anteriores ganharam destaque pelo consumo de tempo desproporcio-
nal, neste cenário as mesmas continuaram com os altos tempos de resposta, mas de uma forma
mais homogênea. No cenário com 1.000 requisições, os ganhos de tempos de resposta, em
percentual, foi de 28% quando comparado à solução proposta com baixa prioridade.
Figura 23 – Tempos de Resposta com Nodos Grandes - Alta Prioridade
Fonte: AUTOR
Quando comparamos a solução proposta, de alta prioridade, com o cenário sem o balan-
ceador de carga, tem-se que o ganho médio na diminuição dos tempos de resposta foi de 114%,
onde nas tarefas leves, este índice aumenta para 133%. Em relação aos nodos pequenos e mé-
dios, este índice diminui, uma vez que, assim como no cenário sem balanceador de carga, os
nodos computacionais do nevoeiro são grandes o suficiente, o que estreita a diferença de tempos
de resposta entre eles. Mesmo assim, observa-se que a solução é viável, embora se tenha uma
fartura de recursos computacionais, os mesmos foram utilizados de forma mais eficiente, pois
65
os tempos de resposta foram diminuídos.
Comparando-se esta solução com o cenário de baixa prioridade, com nodos grandes,
os tempos de resposta também foram menores, o que demonstra a efetividade do mecanismo
de prioridade do trabalho proposto. Por exemplo, na média, o mecanismo de alta prioridade
obteve o percentual de tempo de resposta médio 114% menos quando comparado ao ambiente
sem balanceador. Por outro lado, no ambiente com baixa prioridade, este percentual foi de 61%
a menos, ou seja, com a demanda de tarefas de alta prioridade, o balanceador precisou priorizar
as mesmas para que tenham o menor tempo de resposta possível.
Em relação ao algoritmo Round-Robin, observa-se os ganhos, que na média geral, foram
de 226%, mas que alcançam até 258% em tarefas leves. Para a solução de baixa prioridade,
neste mesmo cenário de nodos grandes, a média geral foi de 145% menos tempo, alcançando-se
o percentual de até 186% em tarefas leves.
5.5 CONSIDERAÇÕES DO CAPÍTULO
As próximas figuras ilustram os ganhos nos tempos de resposta deste trabalho para com
os demais. A Figura 24, ilustra os ganhos no cenário usando nodos pequenos, em 100 requisi-
ções.
Figura 24 – Tempos de resposta para 100 requisições, nodos pequenos
Fonte: AUTOR
O algoritmo de alta prioridade obteve os melhores resultados, que são os menores tem-
pos de resposta. Neste cenário da Figura 24, para a simulação de tarefas leves, o tempo de
resposta do trabalho proposto, em alta prioridade, em relação ao ambiente sem BC, foi 2 vezes
66
menor. No cenário de Round-Robin, os ganho foi de 3.5 vezes. Em ambiente de tarefas médias,
tem-se o ganho de 2 vezes no tempo, no cenário sem BC; e para o ambiente com Round-Robin,
o ganho foi de 3 vezes. Os ganhos permanecem no cenário com tarefas pesadas.
A Figura 25 ilustra o cenário com 500 requisições em nodos pequenos. Nesta, observa-se
novamente os ganhos obtidos na solução proposta, onde o cenário com alta prioridade também
obteve os melhores resultados. Para tarefas pesadas, este trabalho ficou 3 vezes mais rápido
do que a solução abordada com o algoritmo Round-Robin, e quase 2 vezes menor quando
comparada a abordagem sem balanceador de carga.
Figura 25 – Tempos de resposta para 500 requisições, nodos pequenos
Fonte: AUTOR
Com a adoção de nodos pequenos em 1000 requisições por sensor, os resultados obtidos
são demonstrados na Figura 26. Neste cenário, observa-se o ganho, para tarefas pesadas, de
3.5 vezes mais, quando comparado ao algoritmo Round-Robin, e 2 vezes quando comparado ao
ambiente sem BC. Em tarefas leves, por outro lado, os ganhos foram ainda maiores. Quando
comparado ao ambiente sem BC, o trabalho proposto ficou 3.7 vezes mais rápido. No cenário
com o algoritmo Round-Robin, o ganho de tempo ficou 6.6 vezes maior. No cenário de tarefas
médias, também obteve-se ganhos. Quando comparado ao cenário sem BC, o tempo de resposta
ficou 2.5 menor; já no Round-Robin, o tempo ficou 4 vezes menor. Ou seja, mesmo em uma
situação adversa, com poucos recursos computacionais, o trabalho proposto conseguiu entregar
tempos de respostas muito inferiores às demais abordagens.
Para nodos médios, o trabalho proposto também obteve ganhos. A Figura 27 ilustra o
cenário de nodos médios, em 100 requisições. Para o cenário de tarefas leves e médias, no
cenário sem BC e Round-Robin, os ganhos foram de 2 e 3 vezes, respectivamente. Para tarefas
67
Figura 26 – Tempos de resposta para 1000 requisições, nodos pequenos
Fonte: AUTOR
pesadas, os tempos de resposta ficaram mais de 5 vezes inferiores ao cenário sem BC. No
Round-Robin, os ganhos foram de 6 vezes.
Figura 27 – Tempos de resposta para 100 requisições, nodos médios
Fonte: AUTOR
A Figura 28 ilustra o cenário com 500 requisições, em nodos médios. Houve uma di-
minuição nos tempos de resposta, quando comparado ao cenário sem BC, em tarefas leves, de
pelo menos 2 vezes. No cenário com Round-Robin, os ganhos foram de 3 vezes. Nas tarefas
pesadas, os ganhos foram 9 e 10 vezes maiores, quando comparando ao cenário sem BC e com
Round-Robin, respectivamente.
Para o ambiente com 1000 requisições em nodos médios, tem-se os resultados na Fi-
gura 29. Embora houve a maior quantidade de requisições, a solução proposta por este trabalho
68
Figura 28 – Tempos de resposta para 500 requisições, nodos médios
Fonte: AUTOR
obteve os menores tempos de resposta. Isto demonstra a resiliência do algoritmo de BC de,
mesmo sob forte demanda, consegue manter tempos de resposta abaixo das outras abordagens.
No cenário com tarefas pesadas, observa-se que o cenário sem BC obteve os tempos de resposta
4 vezes maior do que o trabalho proposto. No algoritmo Round-Robin, os tempos de resposta
ficaram 5 vezes maiores.
Figura 29 – Tempos de resposta para 1000 requisições, nodos médios
Fonte: AUTOR
Na Figura 30, ilustra-se o ambiente de simulação com nodos computacionais grandes,
em 100 requisições. Neste cenário, tem-se uma maior disponibilidade de recursos computaci-
onais por parte dos nodos de nevoeiro, haja vista os baixos tempos de resposta como um todo.
Percebe-se que, em função destes recursos computacionais, os resultados dos tempos de res-
69
postas ficaram próximos, mesmo variando-se o tamanho da tarefa. Todavia, o trabalho proposto
conseguiu obter tempos de resposta 2 vezes menores, comparando-se com as outras abordagens.
Figura 30 – Tempos de resposta para 100 requisições, nodos grandes
Fonte: AUTOR
Escalando-se a quantidade de requisições para 500, tem-se os resultados na Figura 31.
Da mesma forma que na Figura 30, os tempos de resposta, em linhas gerais, ficaram abaixo de
1 ms. Novamente, o trabalho proposto trouxe tempos de resposta inferiores, mesmo variando-se
o tamanho das tarefas.
Figura 31 – Tempos de resposta para 500 requisições, nodos grandes
Fonte: AUTOR
Na Figura 32, os resultados da simulação usando nodos de nevoeiro grandes, com a
quantidade de 1000 requisições são ilustrados no gráfico. Embora neste cenário tem-se a maior
quantidade de requisições por sensor, dada a grande quantidade de recursos computacionais, os
70
tempos de resposta no geral, também ficaram abaixo de 1 ms. O trabalho proposto, por outro
lado, também obteve ganhos, Para o cenário sem BC, os tempos de resposta atingidos foram de 2
vezes menores. No cenário com Round-Robin, os tempos de resposta foram 3 vezes menores. A
principal vantagem do trabalho, é que, quando muita disponibilidade computacional, o mesmo
consegue extrair os melhores tempos de resposta. Com pouca disponibilidade, os ganhos foram
maiores, atingindo até 10 vezes na simulação.
Figura 32 – Tempos de resposta para 1000 requisições, nodos grandes
Fonte: AUTOR
Na Tabela 5, agrupou-se os resultados das simulações, na forma de resumo, para todos
os ambientes simulados neste trabalho.
Requisições 100 500 1000Abordagem Nodos Tarefa Leve Tarefa Média Tarefa Pesada Tarefa Leve Tarefa Média Tarefa Pesada Tarefa Leve Tarefa Média Tarefa Pesada
Pequenos 30,01 194,54 243,32 127,75 843,31 1016,9 174,2 1792,05 1998,75Médios 0,78 1,23 3,97 0,79 1,24 7,16 0,8 1,25 12,9Sem BalanceadorGrandes 0,28 0,43 0,49 0,29 0,44 0,5 0,29 0,44 0,5Pequenos 45,52 311,74 398,72 224,07 1437,51 1735,72 314,57 2993,73 3429,06Médios 1,18 1,86 4,71 1,2 1,88 7,88 1,2 1,88 13,63Round-RobinGrandes 0,43 0,66 0,73 0,45 0,67 0,75 0,45 0,67 0,75Pequenos 12,71 95,23 122,59 35,93 394,65 473,47 47,07 714,56 978,97Médios 0,37 0,6 0,71 0,38 0,61 0,74 0,38 0,61 2,72SmartFogLB-Alta PrioridadeGrandes 0,12 0,2 0,23 0,13 0,21 0,25 0,13 0,21 0,25Pequenos 13,03 104,1 132,98 41,08 414 600,07 49,58 874,68 1119,2Médios 0,38 0,61 0,71 0,38 0,61 0,74 0,38 0,61 3,01SmartFogLB-Baixa PrioridadeGrandes 0,15 0,29 0,31 0,17 0,29 0,31 0,17 0,3 0,32
Tabela 5 – Resumo dos dados da simulação em todos os ambientes
Nota-se também que, mesmo utilizando-se um algoritmo de balanceamento de carga
como o Round-Robin, os resultados ficaram aquém do esperado. Isto se deve ao fato de que,
para o paradigma de Computação em Névoa, precisa-se entender as propriedades de cada nodo
do nevoeiro, no sentido de saber a disponibilidade dos seus recursos computacionais em tempo
real, para cada alocação de tarefa, com o objetivo de realizar a melhor alocação possível. No
Round-Robin, todavia, isto não é possível, visto que o mesmo caracteriza-se como um algoritmo
71
de balanceamento de carga estático, e portanto, o mesmo não conhece a disponibilidade de
recursos computacionais dos nodos em tempo de execução. Sendo assim, o mesmo teve tempos
de resposta mais altos que o cenário sem o balanceador de carga, sendo em média 65% maior
em nodos grandes.
Entretanto, o trabalho proposto mostrou-se efetivo na solução do problema de altos tem-
pos de resposta no paradigma de Computação em Névoa. A abordagem deste trabalho trouxe
um ganho considerável na diminuição de tais tempos, o que foi comprovado nos resultados
do ambiente de simulação descrito. Dois são os principais motivos desta melhoria: primeiro,
o algoritmo de daemon executa um papel fundamental no trabalho como um todo, no qual o
mesmo destaca-se pela importância de buscar as informações de recursos computacionais dis-
poníveis nos nodos de nevoeiro. Segundo, o algoritmo que realiza a alocação, de posse da lista
de recursos computacionais atualizada de cada nodo, o mesmo pode então realizar a alocação
das tarefas oriundas da camada de Internet das Coisas de forma adequada, o que proporciona
portanto, um ganho na diminuição nos tempos de resposta quando comparado com as outras
abordagens.
Também, o mecanismo de prioridade mostrou-se efetivo neste trabalho proposto, onde o
mesmo tem a habilidade de entender o nível de urgência da tarefa, e então acomodá-la no nodo
mais favorecido computacionalmente, seja de recursos de rede ou de computação no geral.
Tarefas de baixa prioridade, por outro lado, foram atendidas com seus tempos de resposta ligei-
ramente superiores, mesmo assim, seus tempos de resposta permaneceram abaixo dos tempos
de resposta das outras abordagens que foram implementadas nesta simulação, o que demonstra
que o trabalho proposto é viável e também muito estável.
72
6 CONCLUSÃO
Uma vez que o paradigma de Computação em Névoa tem sido amplamente estudado
pela academia, sua aplicação para o paradigma de Internet das Coisas traz vantagens para a
mesma, como redução dos tempos de resposta, assim como diminuição de utilização de links
de Internet, que tendem a estar sobrecarregados, em função da grande quantidade de coisas
inteligentes que estão na rede.
Neste sentido, como forma de atenuar os altos tempos de resposta, consequência de
nodos computacionais do nevoeiro sobrecarregados, este trabalho apresenta uma proposta de
BC. O principal objetivo neste, é obter tempos de respostas das aplicações de Internet das Coisas
os mais baixos possíveis, uma vez que a sobrecarga iminente dos sensores e atuadores que
compõem a IoT podem levar os nodos computacionais do nevoeiro à esgotar seus recursos, e por
consequência, elevar tais tempos de resposta. Para isto, utilizou-se técnicas de balanceamento
de carga entre estes nodos, com o intuito de prover tempos de respostas mais baixos e auto-
adaptação às mudanças repentinas no ambiente. Uma mudança repentina no ambiente que possa
a vir demandar mais nodos de nevoeiro, pode ser prontamente atendida através da distribuição
de tarefas entre todos os nodos que compõem a névoa.
Para alcançar o balanceamento de carga efetivo no paradigma da Computação em Né-
voa, foi desenvolvido uma arquitetura adequada, assim como um algoritmo de daemon, que foi
responsável pela coleta de dados dos nodos do nevoeiro, e também o algoritmo de balancea-
mento de carga proposto.
Este trabalho traz como contribuição uma abordagem para que se tenha tempos de res-
posta mais baixos para aplicações de Internet das Coisas que as requerem. Através da arquite-
tura proposta, assim como o algoritmo do daemon e de balanceamento proposto, se obtém um
menor tempo de resposta para aplicações com estas restrições, sendo que modelou-se três níveis
diferentes de tamanho de tarefa, assim como, três níveis de nodos de nevoeiro.
Com a aplicação do balanceamento de carga proposto neste trabalho, observa-se ganhos
nos tempos de resposta, como discutidos na seção 5.5, os quais alcançaram uma melhoria de até
226% quando comparado ao cenário com algoritmo round-robin, o que comprova a efetividade
e contribuição deste trabalho.
A partir dos experimentos realizados, percebe-se que o paradigma de Computação em
Névoa, mesmo atuando como uma extensão da Computação em Nuvem, precisa de cuidados
73
especiais, como um gerenciamento mais eficiente de seus recursos computacionais para que se
tire o melhor proveito dos mesmos para processar os dados da camada da Internet das Coisas.
Sendo assim, a abordagem do balanceamento de carga atua neste cenário para realizar o melhor
aproveitamento dos recursos computacionais, para que se tenha dinamicidade no ambiente, com
o intuito de atender as demandas de aplicações futuras.
Através da utilização de três diferentes tipos de ambientes com três diferentes tipos
de tarefas e três quantidades de requisições, observa-se que o trabalho proposto obteve bons
resultados, mostrando portanto a capacidade de adaptar-se às mudanças repentinas no ambiente
da Internet das Coisas.
6.1 TRABALHOS FUTUROS
No desenvolvimento deste trabalho percebe-se algumas limitações. Uma questão, diz
respeito à tolerância à falhas do nodo balanceador, uma vez que ele é o ponto de entrada na
rede, e este assunto não foi abordado aqui. Outra questão diz respeito à heterogeneidade dos
nodos de nevoeiro, onde se faz necessária a validação do algoritmo proposto em ambientes com
muitos nodos diferentes, para saber como vai se comportar. Também, aspectos de segurança
e elasticidade não foram abordados neste trabalho. Tais questões, poderiam ser discutidas e
implementadas em trabalhos futuros complementando o algoritmo de balanceamento de carga
proposto neste trabalho.
74
REFERÊNCIAS
AL-FUQAHA, A. et al. Internet of things: a survey on enabling technologies, protocols, and
applications. IEEE communications surveys & tutorials, [S.l.], v.17, n.4, p.2347–2376, 2015.
AL NUAIMI, K. et al. A survey of load balancing in cloud computing: challenges and algo-
rithms. In: SECOND SYMPOSIUM ON NETWORK CLOUD COMPUTING AND APPLI-
CATIONS, 2012. Anais. . . [S.l.: s.n.], 2012. p.137–142.
ASHTON, K. et al. That ‘internet of things’ thing. RFID journal, [S.l.], v.22, n.7, p.97–114,
2009.
ATZORI, L.; IERA, A.; MORABITO, G. The internet of things: a survey. Computer networks,
[S.l.], v.54, n.15, p.2787–2805, 2010.
BANERIEE, A. et al. Centralized Framework for Workload Distribution in Fog Computing.
In: INTERNATIONAL CONFERENCE FOR CONVERGENCE IN TECHNOLOGY (I2CT),
2018. Anais. . . [S.l.: s.n.], 2018. p.1–5.
BERALDI, R.; MTIBAA, A.; ALNUWEIRI, H. Cooperative load balancing scheme for edge
computing resources. In: SECOND INTERNATIONAL CONFERENCE ON FOG AND MO-
BILE EDGE COMPUTING (FMEC), 2017. Anais. . . [S.l.: s.n.], 2017. p.94–100.
BONOMI, F. et al. Fog computing and its role in the internet of things. In: MCC WORKSHOP
ON MOBILE CLOUD COMPUTING. Proceedings. . . [S.l.: s.n.], 2012. p.13–16.
BOUET, M.; CONAN, V. Geo-partitioning of mec resources. In: WORKSHOP ON MOBILE
EDGE COMMUNICATIONS. Proceedings. . . [S.l.: s.n.], 2017. p.43–48.
CASAVANT, T. L.; KUHL, J. G. A taxonomy of scheduling in general-purpose distributed
computing systems. IEEE Transactions on software engineering, [S.l.], v.14, n.2, p.141–154,
1988.
CHAMOLA, V.; THAM, C.-K.; CHALAPATHI, G. S. Latency aware mobile task assign-
ment and load balancing for edge cloudlets. In: IEEE INTERNATIONAL CONFERENCE
ON PERVASIVE COMPUTING AND COMMUNICATIONS WORKSHOPS (PERCOM
WORKSHOPS), 2017. Anais. . . [S.l.: s.n.], 2017. p.587–592.
75
CHEKIRED, D. A.; KHOUKHI, L.; MOUFTAH, H. T. Queuing model for evs energy manage-
ment: load balancing algorithms based on decentralized fog architecture. In: IEEE INTERNA-
TIONAL CONFERENCE ON COMMUNICATIONS (ICC), 2018. Anais. . . [S.l.: s.n.], 2018.
p.1–6.
CHEN, Y.-A.; WALTERS, J. P.; CRAGO, S. P. Load balancing for minimizing deadline misses
and total runtime for connected car systems in fog computing. In: IEEE INTERNATIONAL
SYMPOSIUM ON PARALLEL AND DISTRIBUTED PROCESSING WITH APPLICATI-
ONS AND 2017 IEEE INTERNATIONAL CONFERENCE ON UBIQUITOUS COMPUTING
AND COMMUNICATIONS (ISPA/IUCC), 2017. Anais. . . [S.l.: s.n.], 2017. p.683–690.
CHEN, Y.-C. et al. Cloud-fog computing for information-centric Internet-of-Things applicati-
ons. In: INTERNATIONAL CONFERENCE ON APPLIED SYSTEM INNOVATION (ICASI),
2017. Anais. . . [S.l.: s.n.], 2017. p.637–640.
CHEN, Y.; ZHANG, Y.; CHEN, X. Dynamic Service Request Scheduling for Mobile Edge
Computing Systems. Wireless Communications and Mobile Computing, [S.l.], v.2018, 2018.
CONSORTIUM, O. et al. OpenFog reference architecture for fog computing. Architecture
Working Group, [S.l.], 2017.
ENNYA, Z.; HADI, M. Y.; ABOUAOMAR, A. Computing Tasks Distribution in Fog Com-
puting: coalition game model. In: INTERNATIONAL CONFERENCE ON WIRELESS
NETWORKS AND MOBILE COMMUNICATIONS (WINCOM), 2018. Anais. . . [S.l.: s.n.],
2018. p.1–4.
FAN, J. et al. Deadline-aware task scheduling in a tiered IoT infrastructure. In: GLOBECOM
2017-2017 IEEE GLOBAL COMMUNICATIONS CONFERENCE. Anais. . . [S.l.: s.n.], 2017.
p.1–7.
GARCIA, E. N.; ALMENDRA FREITAS, C. O. de. Releitura da sociedade da informação a
partir da computação ubíqua, da internet das coisas e do neuromarketing. Revista Jurídica da
FANAP, [S.l.], v.6, n.1, p.67–79, 2019.
GU, B. et al. A distributed and context-aware task assignment mechanism for collaborative
mobile edge computing. Sensors, [S.l.], v.18, n.8, p.2423, 2018.
76
JADEJA, Y.; MODI, K. Cloud computing-concepts, architecture and challenges. In: INTER-
NATIONAL CONFERENCE ON COMPUTING, ELECTRONICS AND ELECTRICAL TE-
CHNOLOGIES (ICCEET), 2012. Anais. . . [S.l.: s.n.], 2012. p.877–880.
JIN, H. et al. Tools and technologies for building clouds. In: Cloud Computing. [S.l.]: Sprin-
ger, 2010. p.3–20.
JOŠILO, S.; DÁN, G. Decentralized algorithm for randomized task allocation in fog computing
systems. IEEE/ACM Transactions on Networking, [S.l.], v.27, n.1, p.85–97, 2018.
JUNIOR, E. P. B. Modelagem, Balanceamento de Carga e Predição de Fluxos no para-
digma Névoa das Coisas. 2017. 100p. Programa de Pós-Graduação em Ciência da Computação
— Universidade Federal da Bahia.
KAN, T.-Y.; CHIANG, Y.; WEI, H.-Y. QoS-Aware Mobile Edge Computing System: multi-
server multi-user scenario. In: IEEE GLOBECOM WORKSHOPS (GC WKSHPS), 2018.
Anais. . . [S.l.: s.n.], 2018. p.1–6.
KOLOMVATSOS, K.; ANAGNOSTOPOULOS, C. In-network decision making intelligence
for task allocation in edge computing. In: IEEE 30TH INTERNATIONAL CONFERENCE
ON TOOLS WITH ARTIFICIAL INTELLIGENCE (ICTAI), 2018. Anais. . . [S.l.: s.n.], 2018.
p.655–662.
LI, G. et al. Data processing delay optimization in mobile edge computing. Wireless Commu-
nications and Mobile Computing, [S.l.], v.2018, 2018.
LI, S.; DA XU, L.; ZHAO, S. The internet of things: a survey. Information Systems Frontiers,
[S.l.], v.17, n.2, p.243–259, 2015.
LIU, Q. et al. Task scheduling in fog enabled Internet of Things for smart cities. In:
IEEE 17TH INTERNATIONAL CONFERENCE ON COMMUNICATION TECHNOLOGY
(ICCT), 2017. Anais. . . [S.l.: s.n.], 2017. p.975–980.
MOGI, R.; NAKAYAMA, T.; ASAKA, T. Load balancing method for IoT sensor system using
multi-access edge computing. In: SIXTH INTERNATIONAL SYMPOSIUM ON COMPU-
TING AND NETWORKING WORKSHOPS (CANDARW), 2018. Anais. . . [S.l.: s.n.], 2018.
p.75–78.
77
MOURADIAN, C. et al. A comprehensive survey on fog computing: state-of-the-art and re-
search challenges. IEEE Communications Surveys & Tutorials, [S.l.], v.20, n.1, p.416–464,
2017.
NA, T. et al. Dynamic Load Balancing Mechanism in Mobile Gateway with Heterogeneous
Network. In: INTERNATIONAL CONFERENCE ON INFORMATION AND COMMUNICA-
TION TECHNOLOGY CONVERGENCE (ICTC), 2018. Anais. . . [S.l.: s.n.], 2018. p.1549–
1554.
NAHA, R. K. et al. Fog Computing: survey of trends, architectures, requirements, and research
directions. IEEE access, [S.l.], v.6, p.47980–48009, 2018.
NETO, E. C. P.; CALLOU, G.; AIRES, F. An algorithm to optimise the load distribution of
fog environments. In: IEEE INTERNATIONAL CONFERENCE ON SYSTEMS, MAN, AND
CYBERNETICS (SMC), 2017. Anais. . . [S.l.: s.n.], 2017. p.1292–1297.
NGUYEN, Q.-H.; PHAM, T.-A. T. Studying and developing a resource allocation algorithm
in Fog computing. In: INTERNATIONAL CONFERENCE ON ADVANCED COMPUTING
AND APPLICATIONS (ACOMP), 2018. Anais. . . [S.l.: s.n.], 2018. p.76–82.
OUEIS, J.; STRINATI, E. C.; BARBAROSSA, S. The fog balancing: load distribution for small
cell cloud computing. In: IEEE 81ST VEHICULAR TECHNOLOGY CONFERENCE (VTC
SPRING), 2015. Anais. . . [S.l.: s.n.], 2015. p.1–6.
PANDA, S. K.; BHOI, S. K. An effective round robin algorithm using min-max dispersion
measure. arXiv preprint arXiv:1404.5869, [S.l.], 2014.
PHAM, X.-Q. et al. A cost-and performance-effective approach for task scheduling based on
collaboration between cloud and fog computing. International Journal of Distributed Sensor
Networks, [S.l.], v.13, n.11, p.1550147717742073, 2017.
PHAM, X.-Q.; HUH, E.-N. Towards task scheduling in a cloud-fog computing system.
In: ASIA-PACIFIC NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM (AP-
NOMS), 2016. Anais. . . [S.l.: s.n.], 2016. p.1–4.
RAY, P. P. A survey on Internet of Things architectures. Journal of King Saud University-
Computer and Information Sciences, [S.l.], v.30, n.3, p.291–319, 2018.
78
RIMAL, B. P.; CHOI, E.; LUMB, I. A taxonomy, survey, and issues of cloud computing ecosys-
tems. In: Cloud Computing. [S.l.]: Springer, 2010. p.21–46.
SAKPAL, M. Gartner’s 2019 Hype Cycle for IT in GCC Indicates Public Cloud
Computing Will Transform Businesses. [Online; acessado em 12-Dezembro-
2019], https://www.gartner.com/en/newsroom/press-releases/
2019-10-14-gartner-s-2019-hype-cycle-for-it-in-gcc-indicates-pub.
SOMMERVILLE, I. Engenharia de Software 9a Edição. [S.l.]: Pearson Education do Brasil,
2011.
SONG, Y. et al. An approach to QoS-based task distribution in edge computing networks for
IoT applications. In: IEEE INTERNATIONAL CONFERENCE ON EDGE COMPUTING
(EDGE), 2017. Anais. . . [S.l.: s.n.], 2017. p.32–39.
STHAPIT, S.; HOPGOOD, J. R.; THOMPSON, J. Distributed computational load balancing for
real-time applications. In: EUROPEAN SIGNAL PROCESSING CONFERENCE (EUSIPCO),
2017. Anais. . . [S.l.: s.n.], 2017. p.1385–1189.
SUBASHINI, S.; KAVITHA, V. A survey on security issues in service delivery models of cloud
computing. Journal of network and computer applications, [S.l.], v.34, n.1, p.1–11, 2011.
TALAAT, F. M. et al. Effective Load Balancing Strategy (ELBS) for Real-Time Fog Compu-
ting Environment Using Fuzzy and Probabilistic Neural Networks. Journal of Network and
Systems Management, [S.l.], p.1–47, 2019.
VAQUERO, L. M.; RODERO-MERINO, L. Finding your way in the fog: towards a comprehen-
sive definition of fog computing. ACM SIGCOMM Computer Communication Review,
[S.l.], v.44, n.5, p.27–32, 2014.
VERDI, F. L. et al. Novas arquiteturas de data center para cloud computing. Minicursos do
XXVIII SBRC, [S.l.], v.28, p.103–152, 2010.
VERMA, M.; BHARDWAJ, N.; YADAV, A. K. Real time efficient scheduling algorithm for
load balancing in fog computing environment. Int. J. Inf. Technol. Comput. Sci, [S.l.], v.8,
n.4, p.1–10, 2016.
79
VERMA, M.; YADAV, N. B. A. K. An architecture for load balancing techniques for Fog com-
puting environment. International Journal of Computer Science and Communication, [S.l.],
v.8, n.2, p.43–49, 2015.
VERMA, S. et al. An efficient data replication and load balancing technique for fog computing
environment. In: INTERNATIONAL CONFERENCE ON COMPUTING FOR SUSTAINA-
BLE GLOBAL DEVELOPMENT (INDIACOM), 2016. Anais. . . [S.l.: s.n.], 2016. p.2888–
2895.
WANG, H. et al. Healthedge: task scheduling for edge computing with health emergency and
human behavior consideration in smart homes. In: IEEE INTERNATIONAL CONFERENCE
ON BIG DATA (BIG DATA), 2017. Anais. . . [S.l.: s.n.], 2017. p.1213–1222.
WANG, Y. et al. “Combat Cloud-Fog” Network Architecture for Internet of Battlefield Things
and Load Balancing Technology. In: IEEE INTERNATIONAL CONFERENCE ON SMART
INTERNET OF THINGS (SMARTIOT), 2018. Anais. . . [S.l.: s.n.], 2018. p.263–268.
WAZLAWICK, R. Metodologia de pesquisa para ciência da computação. [S.l.]: Elsevier
Brasil, 2017. v.2.
WU, H. et al. Online geographical load balancing for energy-harvesting mobile edge compu-
ting. In: IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS (ICC), 2018.
Anais. . . [S.l.: s.n.], 2018. p.1–6.
XU, J. et al. Zenith: utility-aware resource allocation for edge computing. In: IEEE INTER-
NATIONAL CONFERENCE ON EDGE COMPUTING (EDGE), 2017. Anais. . . [S.l.: s.n.],
2017. p.47–54.
XU, X. et al. Dynamic resource allocation for load balancing in fog environment. Wireless
Communications and Mobile Computing, [S.l.], v.2018, 2018.
YASMEEN, A. et al. Efficient resource provisioning for smart buildings utilizing fog and cloud
based environment. In: INTERNATIONAL WIRELESS COMMUNICATIONS & MOBILE
COMPUTING CONFERENCE (IWCMC), 2018. Anais. . . [S.l.: s.n.], 2018. p.811–816.
YI, S.; LI, C.; LI, Q. A survey of fog computing: concepts, applications and issues. In: OF THE
2015 WORKSHOP ON MOBILE BIG DATA. Proceedings. . . [S.l.: s.n.], 2015. p.37–42.
80
YU, Y. et al. Green Fog Computing Resource Allocation Using Joint Benders Decompo-
sition, Dinkelbach Algorithm, and Modified Distributed Inner Convex Approximation. In:
IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS (ICC), 2018. Anais. . .
[S.l.: s.n.], 2018. p.1–6.
YU, Y.; LI, X.; QIAN, C. SDLB: a scalable and dynamic software load balancer for fog and
mobile edge computing. In: WORKSHOP ON MOBILE EDGE COMMUNICATIONS. Pro-
ceedings. . . [S.l.: s.n.], 2017. p.55–60.
ZHOU, C.; THAM, C.-K. Where to Process: deadline-aware online resource auction in mo-
bile edge computing. In: IEEE INTERNATIONAL CONFERENCE ON PERVASIVE COM-
PUTING AND COMMUNICATIONS WORKSHOPS (PERCOM WORKSHOPS), 2018.
Anais. . . [S.l.: s.n.], 2018. p.675–680.
ZHU, C. et al. Fog following me: latency and quality balanced task allocation in vehicular fog
computing. In: ANNUAL IEEE INTERNATIONAL CONFERENCE ON SENSING, COM-
MUNICATION, AND NETWORKING (SECON), 2018. Anais. . . [S.l.: s.n.], 2018. p.1–9.
