A criação de um conjunto de ferramentas para facilitar a utilização do framework mininet no ensino de sistemas distribuídos

(1)

CURSO DE SISTEMAS DE INFORMAÇÃO

LUCAS COSTA GOBBI

A CRIAÇÂO DE UM CONJUNTO DE FERRAMENTAS PARA FACILITAR A UTILIZAÇÂO DO FRAMEWORK MININET NO ENSINO DE SISTEMAS

DISTRIBUÍDOS

Cachoeiro de Itapemirim 2022

(2)

A CRIAÇÂO DE UM CONJUNTO DE FERRAMENTAS PARA FACILITAR A UTILIZAÇÂO DO FRAMEWORK MININET NO ENSINO DE SISTEMAS

DISTRIBUÍDOS

Trabalho de Conclusão de Curso apresentado à Coordenadoria do Curso de Sistemas de Informação do Instituto Federal do Espírito Santo, Campus Cachoeiro de Itapemirim, como requisito parcial para a obtenção do título de Bacharel em Sistemas de Informação.

Cachoeiro de Itapemirim 2022

(3)

CDD: 004.6 Bibliotecário/a: Jacqueline Machado Silva CRB-ES nº 640

G574c Gobbi, Lucas Costa.

A criação de um conjunto de ferramentas para facilitar a utilização do framework mininet no ensino de sistemas distribuídos / Lucas Costa Gobbi. - 2022.

66 f. : il. ; 30 cm.

Orientador: Rafael Silva Guimarães

TCC (Graduação) Instituto Federal do Espírito Santo, Campus Cachoeiro de Itapemirim, Sistemas de Informação, 2022.

1. Redes de computadores. 2. Programação (computador). 3. Educação (estudo e ensino). I. Guimarães, Rafael Silva. II.Título III. Instituto Federal do Espírito Santo.

(4)

https://sipac.ifes.edu.br/sipac/protocolo/documento/documento_visualizacao.jsf?imprimir=true&idDoc=1461348 1/1

MINISTÉRIO DA EDUCAÇÃO

INSTITUTO FEDERAL DO ESPÍRITO SANTO

FOLHA DE APROVAÇÃO-TCC nº 18/2022-CAI-CCSI Protocolo nº 23151.005109/2022-29

Cachoeiro De Itapemirim-ES, 16 de dezembro de 2022

LUCAS COSTA GOBBI

A CRIAÇÂO DE UM CONJUNTO DE FERRAMENTAS PARA FACILITAR A UTILIZAÇÂO DO FRAMEWORK MININET NO ENSINO DE SISTEMAS DISTRIBUÍDOS Trabalho de Conclusão de Curso apresentado à Coordenadoria de Sistemas de Informação do Instituto Federal do Espírito Santo, como requisito parcial para obtenção de título de Bacharel em Sistemas de Informação

Aprovado em 14 de dezembro de 2022 COMISSÃO EXAMINADORA

D.sc. Rafael Silva Guimarães Instituto Federal Do Espírito Santo

Orientador

M.Sc. Antonio Izo Júnior Instituto Federal Do Espírito Santo D.Sc. Lucas Poubel Timm do Carmo

Instituto Federal Do Espírito Santo

(Assinado digitalmente em 16/12/2022 18:27 )

ANTONIO IZO JUNIOR

PROFESSOR DO ENSINO BASICO TECNICO E TECNOLOGICO- SUBSTITUTO

CAI-CCSI (11.02.18.01.08.02.13) Matrícula: 3240051

LUCAS POUBEL TIMM DO CARMO

PROFESSOR DO ENSINO BASICO TECNICO E TECNOLOGICO CAI-CCSI (11.02.18.01.08.02.13)

Matrícula: 2417426

RAFAEL SILVA GUIMARAES

PROFESSOR DO ENSINO BASICO TECNICO E TECNOLOGICO CAI-CCSI (11.02.18.01.08.02.13)

Matrícula: 1919203

Para verificar a autenticidade deste documento entre em https://sipac.ifes.edu.br/public/documentos/index.jsp informando seu número: 18, ano: 2022, tipo: FOLHA DE APROVAÇÃO-TCC, data de emissão: 16/12/2022 e o código de verificação: 20c494f9ff

(5)

Declaro, para fins de pesquisa acadêmica, didática e técnico-científica, que este Trabalho de Conclusão de Curso pode ser parcialmente utilizado, desde que se faça referência à fonte e ao autor.

Cachoeiro de Itapemirim, 10 de Março de 2022.

Lucas Costa Gobbi

(6)

A finalização deste trabalho representa o fim da minha tão sonhada jornada de gradu- ação, e gostaria de usar este espaço para agradecer a todos os envolvidos que me ajudaram de inúmeras maneiras nessa jornada.

Primeiramente agradeço a minha namorada Mairá Ferreira Gomes, pois sem ela acredito que não conseguiria ter forças e ânimo para terminar este trabalho, além das inúmeras revisões sintáticas/ortográficas e acompanhamentos que a mesma realizou permitindo que este trabalho melhorasse em todos os sentidos.

Agradeço também a minha família e em especial ao meu pai por ter sempre aumentado a minha fome por conhecimento e me apoiado em minhas escolhas, sempre agindo pacientemente e de forma compreensiva e buscando o melhor para mim e todos a sua volta.

Também gostaria de agradecer aos meus orientadores, que me guiaram na produção do trabalho, e a colocar minhas ideias abstratas no papel me aprofundando em diversas áreas de conhecimento.

Agradeço a empresa Linkapi por permitir que eu desenvolvesse meu trabalho durante parte de meu período de trabalho, e em especial para meus colaboradores Hernandes Falcão e Luiz Kanada pela ajuda técnica e revisão do código além do constante apoio e motivação.

Agradeço ao meu amigo Elian Lima por ter sido meu companheiro de aprendizagem e de projetos, pois sem as centenas de projetos inacabados que começamos acho que eu não teria sido um décimo do programador que sou hoje.

Agradeço a Daniel Shiffman, que mesmo sem me conhecer foi um dos programadores que mais me inspirou, mostrando que a computação também é uma arte e pode ser bela e transformadora.

E para finalizar agradeço a todos os outros que me ajudaram de qualquer forma nessa jornada, desde professores a alunos, escritores e pesquisadores ou até indianos

(7)

(8)

a tendência de esquecer que nenhum computador jamais fará uma pergunta nova."

- Grace Hopper

(9)

Com o passar do tempo, muitas ferramentas já foram criadas com o objetivo de ajudar no ensino de sistemas distribuídos. Porém com a grande necessidade e procura do mercado por profissionais qualificados a trabalharem nesses sistemas em grande escala, além das dificuldades inerentes no ensino de tal disciplina efetivamente, é indispensável que novas metodologias sejam analisadas para que a disciplina consiga preparar os alunos para o mercado de trabalho.

O Mininet é um emulador de redes muito utilizado em diversas universidades como auxiliador no ensino de disciplinas de redes e sistemas distribuídos, pois ele facilita a prototipação de redes em seu ambiente emulado, porém ele deixa a desejar no quesito de montagem inicial de ambiente e de distribuição para diversos sistemas operacionais oque dificulta na ampla utilização desta ferramenta.

Com base nas dificuldades de utilização do mininet, o objetivo deste trabalho é o desenvolvimento de ferramentas auxiliadoras para a utilização do emulador, permitindo que o mesmo seja amplamente utilizado por qualquer individuo em qualquer computador e sistema operacional.

Palavras-chave: Ensino de sistemas distribuídos. Mininet. Sistemas distribuídos.

Ferramentas.

(10)

Over time, many tools have been created with the aim of helping in teaching distributed systems. However, with the great need and market demand for qualified professionals to work in these systems on a large scale, in addition to the inherent difficulties in teaching such a discipline effectively, it is essential that new methodologies be analyzed so that the discipline can prepare students for the market.

Mininet is a network emulator widely used in several universities as an aid in the teaching of disciplines on networks and distributed systems, as it facilitates the prototyping of networks in its emulated environment, but it leaves something to be desired in terms of initial assembly of the environment and distribution for different operating systems, which makes it difficult to use this tool widely.

Based on the difficulties in using mininet, the objective of this work is the development of auxiliary tools for using the emulator, allowing it to be widely used by any individual on any computer and operating system.

Keywords: Teaching Distributed Systems. Mininet. Distributed Systems. Tools.

(11)

Figura 1 – Exemplo de uma rede de computadores . . . 21

Figura 2 – Exemplos de topologias de rede . . . 23

Figura 3 – Hub de rede . . . 24

Figura 4 – Exemplo de uso de um componente bridge . . . 24

Figura 5 – Switch de rede . . . 25

Figura 6 – Uma topologia de redes com um roteador incluso . . . 25

Figura 7 – Separação de camadas de uma SDN . . . 27

Figura 8 – Minimal . . . 30

Figura 9 – Single . . . 30

Figura 10 – Reversed . . . 31

Figura 11 – Linear . . . 31

Figura 12 – Tree . . . 31

Figura 13 – Arquitetura geral do sistema . . . 38

Figura 14 – Design do banco de dados . . . 38

Figura 15 – Diversos terminais abrindo o GbbCli . . . 43

Figura 16 – Interagindo com o comando setup de diversas maneiras . . . 44

Figura 17 – Arquivo .py com topologia do mininet . . . 48

Figura 18 – Terminal invocando a módulo do CLI e chamando o comando do connect . . . 49

Figura 19 – Resultado da ação connect . . . 49

Figura 20 – Resultado da ação run . . . 50

Figura 21 – Testes na topologia . . . 50

Figura 22 – Exemplo de arquivo CSV de métrica . . . 52

Figura 23 – Gráfico de utilização de recursos pelas topologias padrão do mininet 53 Figura 24 – Gráfico de utilização de recursos pela topologia de arvore com 4 de altura padrão do mininet . . . 54 Figura 25 – Gráfico de utilização de recursos pelas topologias padrão do mininet 55 Figura 26 – Gráfico de utilização de recursos pelas topologias padrão do mininet 56 Figura 27 – Gráfico de utilização de recursos pelas topologias padrão do mininet 58

(12)

Tabela 1 – Requisitos da ferramenta . . . 37

Tabela 2 – Média de utilização de memória por comando . . . 45

Tabela 3 – Endpoints de autenticação . . . 46

Tabela 4 – Endpoints de configuração dos contêineres . . . 46

Tabela 5 – Endpoints de configuração das imagens . . . 47

Tabela 6 – Eventos Websocket . . . 47

Tabela 7 – Configurações da máquina virtual . . . 51

Tabela 8 – Máximo de utilização de memória por comando . . . 57

(13)

IFES Instituto Federal do Espírito Santo SDN Software Defined Networks

API Application Programming Interface VM Virtual Machine

SO Sistema Operacional OVA Open Virtual Appliance

REST Representational State Transfer

SSH Secure Shell

IoT Internet of Things

CLI Command Line Interface SDK Software Development Kit

(14)

1 INTRODUCAO . . . . 14

1.1 JUSTIFICATIVA . . . 17

1.2 OBJETIVOS . . . 17

1.3 ESTRUTURA DO TRABALHO . . . 18

2 REFERENCIAL TEÓRICO . . . . 20

2.1 REDE DE COMPUTADORES . . . 20

2.1.1 Classificando redes por área. . . 21

2.1.2 Classificando redes por topologia . . . 22

2.1.3 Equipamentos de conexão . . . 23

2.1.3.1 Hub . . . 23

2.1.3.2 Bridges . . . 24

2.1.3.3 Switch . . . 25

2.1.3.4 Roteadores . . . 25

2.1.4 Redes definidas por software . . . 26

2.1.4.1 Openflow . . . 27

2.1.4.2 Mininet . . . 28

2.2 TRABALHOS RELACIONADOS . . . 33

3 MATERIAIS E MÉTODOS . . . . 36

3.1 REQUISITOS . . . 36

3.2 ARQUITETURA . . . 37

3.3 TECNOLOGIAS . . . 39

3.3.1 Javascript, Typecript e Nodejs . . . 39

3.3.2 NestJs . . . 40

3.3.3 TypeORM . . . 40

3.3.4 Docker . . . 40

3.3.5 Insomnia . . . 41

3.3.6 Python e Jupyter . . . 41

4 RESULTADOS . . . . 43

4.1 FRONTEND . . . 43

4.1.1 Comandos da aplicação . . . 43

4.1.2 Análise do desempenho . . . 45

(15)

4.2.1 Documentação da APIs . . . 46

4.3 FERRAMENTA EM AÇÃO . . . 47

4.3.1 Análise de desempenho . . . 50

5 CONCLUSÃO . . . . 59

REFERÊNCIAS . . . . 61

APÊNDICE A – INSTALAÇÃO DO MININET . . . . 63

APÊNDICE B – CÓDIGOS FONTE . . . . 64

APÊNDICE C – ARQUIVOS CSV DE MÉTRICAS . . . . 65

(16)

1 INTRODUCAO

Durante a década 90, o mundo se encontrava submerso em muitas inovações, e no campo tecnológico não foi diferente quando o mesmo se deparou com a explosão da internet após a descentralização de redes locais, e a consequência do crescimento dos setores inseridos nesse mesmo meio. De frente a essa nova realidade, os sistemas distribuídos se desenvolveram aceleradamente já que eles trazem a possibilidade de controlar um amplo número de recursos descentralizados, tais como, arquivos, armazenamento e processamento computacional (MENDES, 2020).

Dentro das definições de sistemas distribuídos, Andrew Tanenbaum, um dos principais teóricos do assunto, os definiu-os como um conjunto de computadores independentes, onde seus recursos são disponibilizados como um único sistema, coeso e coerente.

Tomando Tanenbaum como fio condutor para explicar esses sistemas, a facilidade de acesso ao é fundamental, por isso, a utilização dele para um usuário deve ser tão fácil quanto a de um sistema centralizado (TANENBAUM, 2003).

Para seu funcionamento esses sistemas dependem de alguns critérios, como a boa comunicação entre seus componentes, oque geralmente é alcançado utilizando-se de softwares conectores ou middlewares que controlam as entradas e saídas das camadas de forma inteligente, padronizando as trocas de informação no sistema, e por consequência simplificando a comunicação dos diversos componentes e camadas de um sistema distribuído.

Muitos benefícios circundam os sistemas distribuídos, além da sua facilidade de acesso a recursos computacionais, destaca-se também a sua escalabilidade, fazendo com que atualmente o uso desse modelo de sistema já vem sendo considerado padrão em diversos tipos de soluções como redes sociais, sistemas de pesquisa, e-commerces, etc. O uso desse sistema já se encontra em meios até diários, considerando o grande número de usuários conectados na internet em aparelhos como computadores, celula- res, notebooks, aparelhos de loT, entre outros que estão suscetíveis a se encontrarem dentro de um sistema distribuído e uma infraestrutura boa e arquitetada de rede que seja propícia para um funcionamento eficaz e correto, com consistência e tolerância às falhas.

(17)

Em contraponto à essa evolução e grande adoção dos sistemas distribuídos, o desenvolvimento de ensino para formação de profissionais da área não caminhou nos mesmos moldes. A justificativa para tal discrepância se encontra principalmente na dificuldade em ensinar a inerente complexidade desses sistemas, que muitas vezes abrange múltiplas áreas em diferentes linguagens, plataformas e arquiteturas e também por depender da interatividade, concorrência e transparência entre todos os componentes distribuídos pela rede (WEINet al., 2009).

Empresas grandes como Google e IBM já desenvolveram iniciativas para tentar auxiliar instituições de ensino que possuem em seu currículo o ensino dessas tecnologias, com o objetivo de aprimorar o conhecimento dos alunos de computação em práticas nesses sistemas para melhor abordar os paradigmas emergentes desse setor de distribuição em larga escala, já que esses estudantes posteriormente serão inseridos no mercado atuando como profissionais (BLACK, 2007).

Com as demandas, as próprias universidades e professores desenvolveram suas próprias soluções para apoiar o ensino de sistemas distribuídos, desde jogos que recriam os problemas enfrentadas por desenvolvedores, atéframeworks¹que permitem o desenvolvimento dos algoritmos no âmbito concorrente e dinâmico de um sistema distribuído (SCHREINER, 2002; WEINet al., 2009; BURGER; ROTHERMEL, 2001).

No que tange a essa dinamicidade, os virtualizadores de rede, como as redes definidas por software (SDN), acabam sendo uma das abordagens utilizadas para gerenciar uma rede dinamicamente, o seu funcionamento se baseia na separação da camada de controle da de encaminhamento, separação essa que já foi testada em outros tipos de aplicação mas sem êxito até a criação do projeto OpenFlow (SOARES; SOUZA, 2016).

Algumas aplicações que se beneficiam muito da utilização dos SDN’s são os emuladores de rede. O Mininet é um emulador de redes de código aberto promovido pela Open Networking Foundation e se baseia na primeira versão do protocolo OpenFlow (KUNAL et al., 2020), ele consome poucos requisitos computacionais e tem uma certa escalabilidade, além de expor uma interface para definir e criar redes programaticamente

1 Frameworks são estruturas compostas por conjuntos de códigos genéricos para várias aplicações, permitindo e facilitando o desenvolvimento de sistemas e outras aplicações

(18)

(MUELAS; RAMOS; VERGARA, 2018). Em questão a suas capacidades de emulação ele consegue virtualizar diversos tipos de elementos de rede como hosts, switches e servidores além de possibilitar a inserção de aplicações customizadas para interagir com as topologias (LANTZ; HELLER; MCKEOWN, 2010).

O principal ponto do Mininet é o seu potencial facilitador da prototipação de redes, sendo ela um recurso extremamente valioso no que diz respeito ao aprendizado de sistemas distribuídos, pois por meio dela vários ambientes e desafios podem ser montados para a validação dos principais conceitos de alguma determinada atividade sem a necessidade de criar esse ambiente como um todo, já que nos casos onde é usado, o Mininet dispensa o uso de uma quantia significativa de dispositivos e ainda ter de configurá-los, o que é altamente custoso no que tange a gastos de tempo e dinheiro (KETI; ASKAR, 2015).

Ademais, para sua utilização podem ser encontrados alguns obstáculos já que para o uso do Mininet é necessário um ambiente configurado em um sistema operacional Linux, de preferências em versões mais recentes e atualizadas por conterem nativamente a biblioteca Open vSwitch (OVS), uma implementação de um switch OpenFlow para ambientes virtualizados, e isso acaba limitando a quantidade de dispositivos na qual o framework pode ser instalado.

Esta limitação faz com que a maioria dos usuários, precisem realizar a criação e configuração de uma máquina virtual (VM), dificultando a criação de um ambiente de desenvolvimento, fator fundamental segundo autores como (PIZZONIA; RIMONDINI, 2016) para uma ferramenta auxiliadora de ensino de redes e sistemas distribuídos.

Mesmo que um usuário tenha um sistema operacional linux, autores como (DORDAL, 2017), também aconselham a utilização de máquinas virtuais, pois o Mininet tem o potencial de afetar a operação do sistema.

A utilização de máquinas virtuais pode se tornar um problema pois elas tem um desempenho de funcionando ordens de magnitude inferiores de suas máquinas hospedeiras, dificultando sua utilização por máquinas mais simples, além de exigir a configuração e instalação de um sistema operacional e ambiente de desenvolvimento.

(19)

1.1 JUSTIFICATIVA

Diante do mercado de trabalho na área de sistemas distribuídos, muitos conceitos e técnicas acabam sendo requeridas para os profissionais. Por isso, torna-se imprescin- dível que no âmbito educacional as coisas também avancem, aprimorando as grades e metodologias de ensino para essas disciplinas da ciência da computação. Atualmente, o ensino de computação é extremamente plural assim como um público alvo bem di- verso e muitos países já buscaram se atualizar adaptando seus sistemas educacionais aos novos moldes para incluir a computação no currículo (SCAICOet al., 2013).

Nesses casos, a utilização de emuladores de redes como o Mininet é de extrema importância por ser uma peça chave para abrir uma grande gama de metodologias referentes a redes, isso em conjunto com a prototipação rápida de topologias e com a grande quantidade de dispositivos que podem ser virtualizados pelo emulador formam uma base para o ensino de temas simples e complexos em sistemas distribuídos.

Porém, tomando problemas como a dificuldade da ampla utilização das máquinas virtuais e que alguns dos sistemas operacionais mais utilizados no mercado não conseguem executar nativamente o software, ele se torna pouco acessível.

Considerando os distintos aspectos analisados até então, esse trabalho de conclusão de curso propõe a criação de ferramentas, já previamente configuradas para a execução do Mininet, que além de conseguir executar o Mininet poderão exportar sua utilização para quaisquer usuário conectado, independente dos seus requisitos computacionais de seu computador ou do sistema operacional utilizado.

1.2 OBJETIVOS

Em busca de construir uma ferramenta que consiga expor instâncias de contêineres, que por sua vez, estarão executando o framework mininet, o objetivo deste presente trabalho é possibilitar que o usuário se conecte a tal instância por meio da ferramenta, podendo editá-la e também utilizar os recursos disponibilizados pelo mininet sem a necessidade de sua instalação.

Dentre os objetivos específicos deste trabalho estão

(20)

• Criação de um módulo para a organização e exposição de contêineres para ser consumido pelas API’s.

• Criação de uma ferramenta para o usuário final interagir com a API via linha de comando (CLI)

• Permitir que o usuário utilize de seu ambiente de desenvolvimento para se comu- nicar com o mininet

• Construção de duas API’s:

1. API Restful para acessar os recursos dos contêineres;

2. API Websocket para as comunicações em tempo real com os contêineres;

• Documentação do ambiente, das configurações e das peças de software e hardware que foram utilizados.

• A ferramenta deve ser de simples uso para o usuário final, rodar em uma grande gama de sistemas operacionais e ser leve.

1.3 ESTRUTURA DO TRABALHO

Dividido em 5 capítulos, a estrutura do trabalho obtém a seguinte a estruturação:

Capítulo 1 - Introdução: Apresentação do tema, a justificativa, os objetivos e a estrutura deste trabalho.

Capítulo 2 - Referencial teórico: Apresentação de conceitos trabalhados, a respeito principalmente de redes de computadores e seus protocolos, SDN’s incluindo o protocolo OpenFlow, contêineres e máquinas virtuais e principalmente o mininet.

Capítulo 3 - Materiais e métodos: Abordar os mecanismos construídos antes da realização do projeto, as premissas e requisitos além da arquitetura geral do trabalho.

Capítulo 4 - Implementação e validação: Em termos mais explícitos, mostrar como foi feita a implementação da ferramenta e algumas validações a respeito do seu funcionamento.

(21)

Capítulo 5 - Conclusão: Apresentar as conclusões do trabalho com algumas conside- rações e propostas de extensão para o futuro da ferramenta.

(22)

2 REFERENCIAL TEÓRICO

Neste presente capítulo, será apresentado os conceitos primordiais nomeados como redes de computadores (suas classificações e componentes), redes definidas por software, alguns dos conceitos sobre sistemas distribuídos e também de virtualização como máquinas virtuais e web services.

2.1 REDE DE COMPUTADORES

O computador é responsável por diversas tarefas nos dias atuais, sendo que quase todas elas são dependentes da conexão com alguma rede, e isso porque o computador é uma ferramenta muito relacionada à consulta e troca de informações, essas quais costumam chegar a ele pela internet ou rede local.

Computadores independentes formam uma rede quando os “nós” ou “hosts” estão conectados e podem trocar mensagens entre si (TANENBAUM, 2003). Para Tanenbaum, a criação de uma rede vem da facilidade que ela promove na troca de dados entre periféricos e pela tecnologia permitindo a existência de aplicações distribuídas como correio eletrônico, streaming, jogos e até a própria internet.

Esses computadores quando conectados a uma rede são nomeados dispositivos finais ou hosts, e para se comunicarem precisam estar conectados a algum dispositivo de rede como os roteadores, Switchs, Hubs, etc. Como visto na figura 1, estes dispositivos são conectados aos computadores para que os mesmos possam adentrar em novas redes, sendo que cada componente da rede tem sua função e devem ser configurados para se adequarem ao uso no contexto.

A criação de uma rede adequada para o cenário é essencial para o sucesso na utilização da mesma, e também permite que novas propostas de tecnologias se insiram no dia a dia dos usuários, como o internet of things (IoT) em que grande parte dos aparelhos utilizados no cotidiano se tornam inteligentes e conectados a internet, sendo capazes de transferir e processar informações além de monitora-las. Sem uma estrutura capaz de suportar tais dispositivos a técnologia se torna incapaz de funcionar da maneira ideal.

(23)

Figura 1 – Exemplo de uma rede de computadores

Fonte: https://www.projetoderedes.com.br/tutoriais/tutorial_equipamentos_de_redes_01.php.

2.1.1 Classificando redes por área

Muitas classificações podem ser usadas para descrever redes e seu funcionamento, uma muito comum é pela sua área de alcance, para Tanenbaum, as principais classifi- cações de rede são:

• Redes Locais (Local Area Network - LAN) com um alcance de até 2 quilôme- tros, podendo ser descrita como a rede entre aparelhos em uma residência ou instituição.

• Redes Metropolitanas (Metropolitan Area Network - MAN) com um alcance de 2 a 50 quilômetros, projetadas para interconectar as redes da cidade e entre cidades próximas.

• Redes de longa distância ( Wide Area Network 0 WAN) com um alcance a nível continental.

(24)

2.1.2 Classificando redes por topologia

As redes também podem ser classificadas pela sua forma ou topologia, que para Soares se define a partir do jeito em que os enlaces físicos e os nós de comutação estão organizados, sendo o caminho físico entre cada par de nó determinado por ela (SOARES; GUIDO; COLCHER, 1995).

Sendo assim, existem infinitas topologias que uma rede pode formar, e entre essas alguns padrões comuns já foram catalogados. Na figura 2 é possível observar alguns desses padrões, e cada uma dessas disposições interfere em como as mensagens são trocadas entre os hosts. A escolha da topologia utilizada é feita antes da instalação da mesma, para que possa ser escolhida a melhor configuração de rede para o contexto.

Para Mendes, a escolha adequada de topologia, que por sua vez vem com a análise dos seus objetivos e necessidades, torna possível uma grande redução de custos e aumento da eficiência do sistema (MENDES, 2020).

Tendo como exemplo uma topologia em linha (conhecida também por topologia em barramento), existe apenas um caminho possível entre cada um dos nós de uma rede, implicando que podem haver problemas de conectividade entre eles se ocorrer qualquer rompimento de um dos host. Já em uma topologia em malha, todos os nós estão conectados entre si, gerando uma grande redundância de caminhos possíveis entre cada um, esta topologia é mais custosa, porém é menos dependente dos nós individuais e podem receber uma maior quantidade de danos sem perder sua conectividade.

(25)

Figura 2 – Exemplos de topologias de rede

Fonte: https://pt.wikipedia.org/wiki/Topologia_de_rede.

2.1.3 Equipamentos de conexão

Dentro de uma rede de computadores existem diversos dispositivos capazes de dar suporte e manter a comunicação entre os nós fluindo, também são chamados de hardware de redes e alguns exemplos destes dispositivos são os Hubs, Switches, Bridges, etc.

2.1.3.1 Hub

Os hubs ou ethernet hubs (Figura 3) são dispositivos feitos para a expansão de redes.

Sua função é regenerar os sinais recebidos na mesma rede que ele se encontra antes do sinal ficar muito fraco ou ser corrompido, e sua função se tornou extremamente obsoleta com a larga utilização de switches no mercado.

(26)

Figura 3 – Hub de rede

Fonte: https://www.minitool.com/lib/ethernet-hub.html.

2.1.3.2 Bridges

As bridges (Figura 4) são equipamentos de rede que permitem a junção de duas ou mais redes de forma que as mesmas estejam interconectadas em um único domínio. Bridges são essencialmente repetidores com certa capacidade de filtragem de conteúdo, e geralmente são usados para a conexão de redes LAN trabalhando sobre o mesmo protocolo.

Figura 4 – Exemplo de uso de um componente bridge

Fonte: https://www.uniaogeek.com.br/principais-dispositivos-de-uma-rede-de-computadores-p1/.

(27)

2.1.3.3 Switch

Os switches (Figura 5) são equipamentos que conseguem conectar diversas estações de trabalho a uma única rede formando as LAN’s. Em suma, switches são bridges multi porta com mais performance e com funcionamento mais inteligente conseguindo encaminhar informações para portas específicas.

Figura 5 – Switch de rede

Fonte: https://www.geeksforgeeks.org/network-devices-hub-repeater-bridge-switch-router-gateways/.

2.1.3.4 Roteadores

Os roteadores (Figura 6) são equipamentos com funções parecidas com os switches que conseguem rotear pacotes baseando-se no seu endereço IP. Roteadores fazem o papel de conectar redes, sendo o seu principal ponto de uso conectar redes locais às metropolitanas.

Figura 6 – Uma topologia de redes com um roteador incluso

Fonte: https://pt.wikipedia.org/wiki/Topologia_de_rede.

(28)

2.1.4 Redes definidas por software

As redes definidas por software (SDN), apareceram para acelerar a inovação de redes, nessa arquitetura é possível gerenciar uma rede dinamicamente, possibilitando uma rápida configuração, diminuindo a necessidade de certos componentes de hardware como switches e roteadores e possibilitando o seu escalonamento conforme necessidade. Seu funcionamento se baseia na separação da camada de controle da de encaminhamento no modelo OSI, esta separação já era utilizada em outros tipos de aplicação, sem muito sucesso, porém com a criação do protocolo OpenFlow e com sua ampla utilização, a pesquisa a respeito dos SDN e outras formas de administrar programaticamente as redes cresceu (SOARES; SOUZA, 2016).

O funcionamento das redes de internet definidas por software se baseiam na centra- lização da lógica de controle dos dispositivos em um local só chamado controlador SDN, como visto na figura 7. O controlador SDN tem uma visão completa da rede, e todo seu controle de modo que a rede pode ser comandada por ele (KAUR; SINGH;

GHUMMAN, 2014). Pela natureza extremamente dinâmica dos SDN, as mesmas podem ser utilizados em conjunto com emuladores como vSDNEmul, EstiNet e Mininet para a criação de um ambiente virtual, onde o aluno pode testar diversos tópicos da rede desde a infraestrutura, sua topologia, e testar seus algoritmos.

(29)

Figura 7 – Separação de camadas de uma SDN

Fonte: https://www.gta.ufrj.br/grad/16₂/2016SDN/conceitos.html.

2.1.4.1 Openflow

Um dispositivo de rede é responsável pela conexão de uma enorme quantidade de dispositivos, tal tarefa pode se tornar complexa em vista da falta de um padrão de funcionamento. Sendo assim já houveram algumas tentativas para padronização dessa comunicação na indústria, sendo uma delas o Openflow. O openflow é um padrão aberto criado pela Open Networking Foundation (ONF), criado para padronização da comunicação entre as camadas de controle e de infraestrutura em uma SDN, para isso o Openflow disponibiliza uma especificação de uma API de baixo nível, que contempla dois modos de ação, o reativo onde os fluxos são configurados com a chegada dos pacotes, facilitando sua configuração e o modo proativo onde todos os fluxos devem ser previamente configurados, diminuindo a quantidade de requisições pro controlador em troca de uma configuração mais exaustiva. Este modelo foi imprescindível para o sucesso dos SDN, e hoje em dia já é seguido por grande parte da indústria.

(30)

2.1.4.2 Mininet

O mininet é um framework que permite a criação e emulação de uma rede realista que pode conter diversos dispositivos e objetos caracteristicos uma rede como switches, hosts, servidores além do código da aplicação, tudo isso podendo ser instalado e configurado em um computador ou em uma máquina virtual (LANTZ; HELLER; MCKEOWN, 2010).

Como um emulador, o Mininet pode executar qualquer controlador Openflow e o seu principal ponto é a facilitação da prototipação de uma rede, sem um emulador e se faz necessário adquirir uma grande gama de dispositivos e ainda configurá-los no formato da rede, uma atividade extremamente custosa em relação ao tempo e ao dinheiro gasto na compra dos dispositivos, além de que para redes de larga escala a prototipagem de forma manual se torne extremamente inviável (KETI; ASKAR, 2015). Alguns outros atributos do fluxo de trabalho do mininet descritos por Lantz:

• Flexibilidade: Quaisquer topologias e novas funcionalidades podem ser definidas por software

• Facilidade no Deploy: Qualquer deploy de uma funcionalidade pode ser feito sem mudança na base de código

• Interatividade: Possibilidade de manter e fazer o suporte a rede em tempo real

• Escalabilidade: O ambiente de prototipagem pode servir para redes de larga escala (centenas ou milhares de switches ou outros dispositivos de rede)

• Permite o compartilhamento: O compartilhamento de uma topologia de rede é tão simples quanto o compartilhamento de um trecho de código.

• Ambiente Realístico: O ambiente de prototipagem tenta representar o comporta- mento real da rede.

O Mininet é um emulador CBE (Container-Based Emulation) pois tem seu funcionamento baseado na criação de nós lógicos que podem ser conectados a redes. Sendo

(31)

estes nós também chamados contêineres ou namespaces de rede (DORDAL, 2017).

Além disso o Mininet utiliza virtualização baseada em processos para executar uma grande quantidade de hosts simultaneamente, e a ferramenta pode criar kernels, ou Openflow Switches, controladores, e hosts para a comunicação nesta rede emulada.

E podemos acessar todas as features pela linha de comando, alguns exemplos de comandos que o mininet disponibiliza são:

• sudo mn Este comando inicializa o mininet e permite a execução dos próximos comandos

• Mininet> help Mostra varias opções de outros comandos que podem ser utilizados no mininet

• Mininet> nodes Mostra todos os nós (Hosts, switches e etc) que existem na configuração atual de rede

• Mininet> dump Mostra as opções de dump de todos os nós da configuração atual de rede

• Mininet> HOST ping OTHERHOST Testa a conectividade entre os hosts HOST e OTHERHOST, e continua testando até a finalizar o comando (Pode fazer uma quantidade de testes finito N se passar a flag -c N, exemplo h1 ping -c 2 h2

• Mininet> HOST ifconfig -aMostra as interfaces h1-eth0 e loopbakc(Io)

• Mininet> pingall Checa a conectividade entre todos os hosts na configuração atual de rede

Para a execução dos comandos é necessário que haja uma configuração de redes feitas para que o Mininet possa simula, e a propria biblioteca do mininet já vem com algumas redes pré configuradas para se realizar testes, que podem ser chamadas adicionando a flag –topo no comando mn (Exemplo: sudo mn –topo minimal), sendo elas:

Minimal é a topologia mais básica que contém apenas dois hosts e um switch, para executar está topologia podemos utilizar a flag–topo minimal

(32)

Figura 8 – Minimal

Fonte: https://telcomaglobal.com/p/what-is-mininet.

Single é uma topologia que pode conter uma quantidade N de hosts e apenas um switch, e podemos configurar a quantidade N de hosts utilizando a flag–topo single,N

Figura 9 – Single

Reversed é similar a Single porém feita com a ordem das conexões inversa e podemos configurar a quantidade N de hosts utilizando a flag–topo reversed,N

(33)

Figura 10 – Reversed

Linear é uma topologia que adiciona uma N quantidaded de switches em conjunto com a N quantidade de hosts,–topo linear,N

Figura 11 – Linear

Tree é uma topologia em formato de Arvore, que contém uma altura de N níveis e dois hosts por switch,–topo tree,N

Figura 12 – Tree

(34)

Porém a fim de ensino de redes é desejavel não utilizar apenas as redes pré configuradas, e para isto o mininet disponibiliza uma interface de configuração de rede que pode ser acessada via script python, com este arquivo em mãos podemos utilizar a flag –custom ARQUIVO.

No Algoritmo 2.1 segue um exemplo de script utilizando a interface do mininet para criar a topologia minimal, note que a configuração da rede se encontra apenas no método build consistindo de apenas 5 linhas de código, das linhas 8 até a 13.

Analisando mais detalhadamente o algoritmo 2.1, é possível observar:

• Linhas 9 e 10: O Comando addHost(...) , utilizado para se adicionar umhost com a nomenclatura definida

• Linha 11: O Comando addSwitch(...), usado para adicionar um switch de rede, como visto no tópico 2.1.3.3, para a topologia

• Linhas 12 e 13: O Comando addLink(..., ...), para criar a conexão entre os elementos passados por parâmetro.

• Linha 31: A definição do nome da rede como "minimal"importante para a execução do Mininet por linha de comando

1 f r o m m i n i n e t . cli i m p o r t CLI

2 f r o m m i n i n e t . log i m p o r t s e t L o g L e v e l

3 f r o m m i n i n e t . net i m p o r t M i n i n e t

4 f r o m m i n i n e t . t o p o i m p o r t T op o

5 f r o m m i n i n e t . n o d e i m p o r t R e m o t e C o n t r o l l e r , O V S S w i t c h

6

7 c l a s s M i n i m a l T o p o ( T o p o ) :

8 def b u i l d ( se l f ) :

9 h1 = se l f . a d d H o s t ( ’ h1 ’ )

10 h2 = se l f . a d d H o s t ( ’ h2 ’ )

11 s1 = se l f . a d d S w i t c h ( ’ s1 ’ )

12 s e l f . a d d L i n k ( s1 , h1 )

(35)

13 s e l f . a d d L i n k ( s1 , h2 )

14

15 def r u n M i n i m a l T o p o () :

16 t o p o = M i n i m a l T o p o ()

17 net = M i n i n e t (

18 t o p o = topo ,

19 s w i t c h = O V S S w i t c h ,

20 a u t o S e t M a c s = T r u e )

21

22 net . s t a r t ()

23 CLI ( net )

24 net . s t o p ()

25

26 if _ _ n a m e _ _ == ’ _ _ m a i n _ _ ’:

27 s e t L o g L e v e l ( ’ i n f o ’ )

28 r u n M i n i m a l T o p o ()

29

30 t o p o s = {

31 ’ m i n i m a l ’: M i n i m a l T o p o

32 }

Algoritimo 2.1 – Python example

2.2 TRABALHOS RELACIONADOS

Com o objetivo de avaliar oque já havia sido escrito na academia, algumas buscas foram conduzidas a respeito de ensino de redes e sistemas distribuídos, sobre o mininet e sua utilização em aula e também a respeito de ferramentas crias com o principal objetivo de auxiliar no ensino de tais disciplinas.

Os primeiros trabalhos avaliados foram a respeito da utilização do mininet e sua validação em sala de aula, (LANTZ; HELLER; MCKEOWN, 2010), descreveu em um trabalho bem completo, todas as especificações do mininet, como o mesmo pode ser executado e distribuído e validou a uso de memória das topologias emuladas, calculando algumas métricas para verificar sua escalabilidade e limitações. Outro ponto importante do trabalho de Lantz é no estudo de caso de pesquisadores e universidades que utilizam o Mininet, o que mostrou a grande quantidade de adoção do framework

(36)

para atividades como prototipação e otimização de redes, além de demonstrações e no ensino.

Já James, trabalha mais na prática e no porque utilizar de emuladores de rede no ensino de matérias de rede. James também explica os objetivos do trabalho em laboratório nessas disciplinas e seus benefícios, e mostra como aplicar o emulador na prática em sala de aula, além de trazer alguns questionamentos sobre os principais eventos que influenciam no consumo de processamento do mininet (JAMES, 2020).

Também foram analisados trabalhos a respeito do ensino de laboratorial, (MENGEL;

BOWLING, 1995) descreve logisticamente algumas necessidades que um laboratório de redes deve conter para a sua efetividade além de definir as dificuldades de sua organização. Tais fatores logísticos mostram como a utilização de novas ferramentas como os emuladores de redes são fortes candidatos para a facilitação do ensino de tal disciplina.

Já a respeito da criação de novas ferramentas neste contexto,(PIZZONIA; RIMONDINI, 2016), realizou um trabalho minucioso, comparando em diversas métricas várias ferramentas disponíveis, descrevendo as necessidades que softwares auxiliadores de ensino de redes e sistemas distribuídos tem que prover. Além disso ele propôs sua própria ferramenta o Netkit e expos alguns estudos de caso do uso do software.

Também foram analisadas algumas extensões biblioteca Mininet, já que como a mesma tem seu código aberto sob a licença BSD Terceira¹, váriosforks² da base de código principal surgiram. Na UNICAMP, (FONTESet al., 2015), desenvolveram o Mininet- Wifi, uma ferramenta que adiciona estações wireless virtuais e access points para o emulador do mininet, mantendo todas suas capacidades e arquitetura.

Outrofork interessante é o ContainerNet, que utiliza contêineres docker como instancias dentro da rede emulada, permitindo mais dinamicidade dentro da topologia, pois os contêineres podem ser configurados, inseridos e removidos durante a execução da topologia (PEUSTER; KARL; ROSSEM, 2016). Posteriormente, até mesmo o

1 Uma licença de software permissiva, que permite a distribuição e comercialização do software sem a garantia e a liberação da marca

2 Forkssão projetos que se originam de um projeto inicial, criando assim ramificações no projeto.

(37)

ContainerNet teve ramificações como o CrystalNet, que tem o objetivo de aumentar as capacidades de emulação do mininet, podendo trazer topologias de escala cloud com milhares de componentes para o ambiente virtualizado (LIUet al., 2017).

O NestedNet também é outra ramificação do Containernet, que diferente do Crystal- Net utiliza o aninhamento de contêineres para a emulação de topologias de grande complexidade e hierarquizadas (ZHANG; PRABHU; TESSIER, 2020).

(38)

3 MATERIAIS E MÉTODOS

Neste capítulo serão descritas as etapas do desenvolvimento do trabalho. Alguns dos pontos que serão abordados são os requisitos iniciais levantados para o desenvolvimento, especificações, e as tecnologias e ferramentas escolhidas.

i. Levantamento de requisitos: Reuniões com discentes e docentes da disciplina de Sistema distribuídos para identificar as necessidades e dificuldades da prática da matéria.

ii. Prova do conceito: Aplicação simplificada para constatar que a plataforma e seus requisitos poderiam ser desenvolvidos.

iii. Desenvolvimento: Este processo foi dividido entre Backend e Frontend. Backend que contava com grandes dificuldades técnicas para sua elaboração, e o Frontend que pode ser realizado após a conclusão do primeiro processo.

iv. Validação: Criação de uma série de scripts para a geração de métricas no frontend e backend, e posteriormente, os dados coletados foram processados e descritos em diagramas realizados na plataforma Jupyter, utilizando Python e a biblioteca MatPlot.

3.1 REQUISITOS

Os principais requisitos desse sistema são divididos entre requisitos funcionais (RF) e requisitos não funcionais (RNF).

(39)

Requisito Tipo

O usuário deve interagir com a ferramenta pela CLI RF

O usuário deve conseguir logar e listar os ambientes que ele tem pela CLI RF A ferramenta deve permitir inserir, excluir e editar arquivos nos ambientes RF A ferramenta deve permitir iniciar e interromper execuções nos contêineres RF A ferramenta deve permitir a o envio de comandos para os contêineres RF

A ferramenta deve retornar o output dos comandos enviados RF

A ferramenta deve ter ter autenticação RF

A ferramenta deve seguir os padrões Restful RNF

A ferramenta deve criar pseudo terminais para os usuários poderem interagir com os contêineres RNF A ferramenta deve receber comandos via sessão websocket e enviá los para os pseudo terminais RNF

A autenticação da ferramenta deve ser via cookie e JWT RNF

A ferramenta deve ser escrita na linguagem Javascript RNF

A ferramenta deve utilizar o framework NestJs RNF

A ferramenta deve utilizar MySql como banco de dados RNF

A ferramenta deve utilizar Docker e o Docker API para a organização dos contêineres RNF A ferramenta deve conter um ambiente favorável para o mininet instalado RNF Devem ser criados SDK’s para facilitar a utilização da API por outras ferramentas RNF A ferramenta deve expor documentação dos seus endpoints e do seu SDK RNF

Tabela 1 – Requisitos da ferramenta

3.2 ARQUITETURA

A ferramenta foi desenvolvida utilizando a linguagem de programação Javascript em conjunto com nodejs e foi dividida em 3 componentes:

1. GbbCli: Esta será a maneira que o usuário realizará a comunicação com o sistema 2. GbbSdk: OSDK que realizará as chamadas de API que o usuário executar pela

CLI

3. GbbApi: O backend realizará a autenticação e manutenção das instancias de docker

Na figura 13 é demonstrado como os componentes da ferramenta serão organizados e disponibilizados para o uso. Nela o usuário irá interagir com o sistema utilizando a CLI, que por sua vez usará doSDK de javascript para realizar as chamadas à API. A API

(40)

Restful é responsável pela criação e manutenção dos contêineres, e ela estabelecerá comunicação via websocket com oSDK para a troca de comandos e respostas com os contêineres. O banco guardará os dados de cada o usuário e dos contêineres criados pelo mesmo, para permitir que apenas o usuário que tenha criado o contêiner consiga o utilizar.

Figura 13 – Arquitetura geral do sistema

Fonte: De autoria própria.

O banco de dados, como mostrado na figura 14, será utilizado para guardar as informa- ções dos usuários e dos contêineres que eles detém, além disso algumas informações a respeito dos comandos serão guardados para possibilitar a verificação do que foi feito em cada contêiner.

Figura 14 – Design do banco de dados

(41)

Quando o usuário enviar a requisição para receber acesso ao contêiner, a API checa a autenticidade de requisição e verifica se o contêiner é realmente de posse do usuário, após isto ela cria um PTY (Pseudo terminal) e executa o sobe o contêiner. Após o início do contêiner a API liga as comunicações do websocket e do PTY.

A utilização de pseudo terminais é preferível a de processos pois com a criação de um PTY a aplicação já ganha acesso a um processo independente e também consegue interagir com tal processo de forma semelhante a um terminal, facilitando a disponibilização das entradas e saídas.

3.3 TECNOLOGIAS

3.3.1 Javascript, Typecript e Nodejs

Javascript é uma das linguagens mais utilizada atualmente e seu principal uso é adicionar interatividade a páginas web, além disso, ela pode ser usada junta a uma runtime para ser executada em servidores e em sistemas operacionais nativamente¹. Uma das runtimes por exemplo é o NodeJs que foi criada com o objetivo de possibilitar o desenvolvimento de aplicações de rede escaláveis e rápidas com Javascript em servidores, além de utilizar recursos como o motor v8, criado pelo google para garantir certos requisitos de performance².

A escolha do Javascript para o presente trabalho se deu pela experiência pessoal com a linguagem, além da existência de uma enorme comunidade e biblioteca de pacotes open source que ela contém. Também foi utilizado o Typescript, um superset de JS que adiciona peças de sintaxe e permite a existência de tipos e validações em tempo de compilação para o Javascript³, para assim conseguir alcançar um código mais descritível, legível e escalável.

1 Disponível em: <https://developer.mozilla.org/pt-BR/docs/Web/JavaScript>.

2 Disponível em: <https://nodejs.org/en/>.

3 Disponível em: <https://www.typescriptlang.org/>.

(42)

3.3.2 NestJs

Outra tecnologia utilizada foi o NestJs⁴, um framework que ajuda no desenvolvimento de aplicações com o NodeJs, ele se baseia na estrutura do AngularJs e traz conceitos arquiteturais como módulos, services, controllers e middlewares para o projeto. O framework também facilita na construção de API’s Restful, pois ele gera os endpoints com os seus controllers e permite a adição de outros protocolos de transporte como gRPC e WebSocket⁵.

A escolha do framework foi feita para a construção de uma API robusta e escalável, além de ajudar com a necessidade de dois tipos de comunicação com a API (HTTP e WebSocket).

3.3.3 TypeORM

Com o aumento da utilização do paradigma de programação orientada a objetos (POO) e o distanciamento deste paradigma com o do banco de dados relacionais, surgiram aplicações denominadas Object-Relational Mapping (ORM) que fazem o intermédio das comunicações entre as duas etapas. O typeORM é justamente uma destas aplicações, sendo implementado em Javascript e permitindo a utilização de diferentes bancos de dados sem grandes mudanças na implementação do código⁶.

O typeORM foi escolhido com o foco em simplificar a comunicação e criação do banco e suas entidades, facilitando o crescimento da aplicação e aumentando sua escalabilidade.

3.3.4 Docker

O docker é uma plataforma que facilita a criação e gerenciamento de ambientes isolados chamados de contêineres. Um contêiner contém uma imagem que define todos os seus requisitos, pacotes e o ambiente em que o mesmo está criando, e com o docker engine é possivel inserir tal contêiner em uma grande gama de sistemas operacionais. Sendo

4 Disponível em: <https://nestjs.com/>.

5 Disponível em: <https://docs.nestjs.com/websockets/gateways>

6 Disponível em: <https://typeorm.io/>.

(43)

assim uma aplicação que antes não poderia ser executada em diferentes sistemas pode ser executada dentro do contêiner, que por sua vez cuidará de quaisquer necessidade da aplicação e de sua implantação⁷.

A utilização do docker neste trabalho não foi pela sua facilitação de criação de ambientes, mas sim no ambiente isolado que o mesmo cria. Como é uma necessidade da aplicação que o usuário interaja com uma instancia do mininet que está em execução no sistema, seria muito difícil limitar as ações do usuário e limitar os recursos que o mesmo consome, porém com o docker é possível criar uma imagem que consegue executar a aplicação (Mininet) com as quotas de uso de cpu e memória acopladas ao contêiner, e liberar o acesso a este contêiner para o usuário.

Quando um usuário tem acesso ao contêiner, com o isolamento, nenhuma ação que o mesmo causa a sua instancia será refletida nem para o sistema operacional nem para as demais instancias, sendo assim permite a liberação de recursos do sistema facilmente não comprometendo sua segurança.

3.3.5 Insomnia

O insomnia⁸ é uma aplicação que facilita os testes em API’s Restful, podendo enviar as requisições HTTP realizando a configuração dos parâmetros, autenticação, etc. Um dos principais fatores contribuintes a sua utilização no trabalho é sua simplicidade e da facilidade documentar uma API rapidamente e exporta-la para os usuários.

3.3.6 Python e Jupyter

O Python⁹ é uma das principais linguagens utilizada pela comunidade cientifica, tendo uma grande gama de bibliotecas para a análise e transformação de dados além da geração de métricas. Neste trabalho o Python foi utilizado justamente pelas seus pacotes de engenharia de dados e pela facilidade de seu uso. Em conjunto com a linguagem as bibliotecas Pandas¹⁰ para realizar as importações de dados de arquivos

7 Disponível em: <https://www.docker.com/>.

8 Disponível em: <https://insomnia.rest/download>.

9 Disponível em: <https://www.python.org/>.

10 Disponível em: <https://pandas.pydata.org/>.

(44)

CSV, e MatPlot¹¹, para a criação dos gráficos foram utilizadas, Além do Jupyter¹²usado como um notebook para o desenvolvimento. .

11 Disponível em: <https://matplotlib.org/>.

12 Disponível em: <https://jupyter.org/try>.

(45)

4 RESULTADOS

Este capitulo demonstra a ferramenta que foi criada em conjunto com a análise de sua performance e desempenho, para fins organizacionais o capitulo foi dividido em Frontend e Backend, sendo o Frontend a Cli que o usuário Aluno tem contato e o Backend a aplicação que está no servidor configurado pelo professor ou universidade

4.1 FRONTEND

O usuário interage com a ferramenta pelo terminal utilizando o módulo GbbCli, sendo ele uma interface de linha de comando (CLI) que funciona por qualquer terminal. A escolha de interface por linha de comando se deu, pois ela permite que o usuário mantenha seu ambiente de desenvolvimento e consiga utilizar a ferramenta de quase qualquer dispositivo. Na figura 15 é demonstrado a utilização do cli por diversos terminais.

Figura 15 – Diversos terminais abrindo o GbbCli

4.1.1 Comandos da aplicação

O Gbbcli define alguns comandos que o usuário pode utilizar:

(46)

• GbbCli –help: Para visualizar todos os comandos disponíveis

• GbbCli setup: Para configurar o acesso a Api

• GbbCli login: Para realizar o login com a ferramenta

• GbbCli connect: Para realizar a conexão com a instancia do docker

Por padrão, quando se utiliza algum comando, o terminal pede pelas demais informa- ções necessárias para prosseguir com a ação. Porém também é possível passar essas informações pelo próprio comando, deste modo: GbbCli login –usuario="USUARIO’

–password="PASSWORD". Na figura abaixo é demonstrado a utilização do comando setup de algumas maneiras diferentes seguindo os padrões da Cli.

Figura 16 – Interagindo com o comando setup de diversas maneiras

A CLI pode ser utilizado de qualquer sistema operacional que consiga executar NodeJs, sendo assim ela tem o suporte em uma grande gama de sistemas operacionais incluindo Linux, macOS, Microsoft Windows, SmartOS, FreeBSD, OpenBSD e IBM AIX. Além de ser relativamente simples e reproduzível em outras linguagens e plataformas caso fosse necessário.

(47)

4.1.2 Análise do desempenho

Algumas métricas simples foram produzidas com o objetivo de averiguar se a CLI pode ser realmente utilizada amplamente. Para testar o consumo de memória utilizou-se a própia API do Nodeprocess.memoryUsage()foi utilizada, com ela é possível verificar de maneira parcial a quantidades de alocações na pilha de memória da aplicação.

Com a API de memoryUsage do node foram escolhidos alguns trechos do código estratégicos para se salvar os snapshots da quantidade de memória naquele instante e afim de descobrir uma média da máxima utilização de memória.

Para a geração das métricas, foi considerado que o motor v8 consegue otimizar o código a partir de execuções suscetivas, sendo assim o comando foi executado uma sequencia de vezes (20 vezes) e foram retiradas os 4 dados extremos de pior e melhor resultado realizando a média aritmética dos resultados restantes.

Tabela 2 – Média de utilização de memória por comando Comando Memória

Mb

setup 12,3

login 15.1

connect 18

Outra métrica importante para a distribuição do pacote é o seu tamanho de armazenamento, como a aplicação será distribuída com o código fonte incluso o tamanho da mesma tem uma certa sobrecarga, que apesar de não indispensável é vantajosa caso o usuário queira fazer alguma modificação em sua aplicação. O tamanho do pacote com o código fonte é de 25,5 Mb.

(48)

4.2 BACKEND

4.2.1 Documentação da APIs

A API construída em NestJs, tem diversos endpoints que permitem a consulta e visualização de seus dados, além de sua manutenção.

A próximas tabelas descrevem o básico de documentação dos endpoints criados. Na tabela 3 são mostrados os serviços que são usados para o registro e login de novos usuários.

Tabela 3 – Endpoints de autenticação URI Método Resposta Descrição

/auth

/login POST Status Executá o login por JWT na API

/register POST User Executá o registro do usuá- rio na API

Na tabela 4 são mostrados os endpoints que realizam a configuração, execução, criação e interrompimento de contêineres.

Tabela 4 – Endpoints de configuração dos contêineres

URI Método Resposta Descrição

/docker/container

/create POST Contêiner Cria um contêiner /list GET Contêiner[] Lista os contêineres

/:id/start POST Inicia um contêiner

/:id/stop POST Para um contêiner

/:id/file POST Cria um arquivo dentro do

contêiner

(49)

Na tabela 5 são mostrados os serviços para criação das imagens que os contêineres podem utilizar

Tabela 5 – Endpoints de configuração das imagens URI Método Resposta Descrição

/docker/image

/create POST Cria uma imagem

Na tabela 6 são mostrados os eventos websocket em que a API recebe e responde.

Tabela 6 – Eventos Websocket

Evento Direção Dados Descrição

start Cliente envia

• Chave JWT de Login

• Conteúdo do arquivo

• Id do Contêiner

Inicia a comunicação websocket com o servidor terminal-input Cliente

envia stdindo cliente Envia o conteúdo escrito no terminal para o servidor terminal-output Cliente

recebe stdout do servidor Recebe o output do terminal do servidor

4.3 FERRAMENTA EM AÇÃO

Um fluxo de utilização da ferramenta comum, onde um usuário escreve uma topologia, inicia na ferramenta e faz seus testes pode ser descrito da seguinte forma:

1. Um arquivo (em python) deve ser escrito com as configurações da topologia (Figura 23)

2. Algum terminal deve ser aberto, e o comando gbbcli connect deve ser chamado (Figura 24)

(50)

3. Com o ultimo passo os terminais do usuário e do contêiner que foi instanciado já são interligados (Figura 25)

4. Nesse instante o usuário já pode usar de qualquer recurso do mininet a partir de sua execução pelo terminal

5. Caso o usuário queira criar uma emulação com a sua topologia ao invés das padrões do mininet, ele pode executar o comando run passando como argumento o nome da topologia. Exrun simple(Figura 26)

6. Agora o usuário já dispõe de um ambiente emulado e pode executar os comandos de teste do mininet (Figura 27)

Figura 17 – Arquivo .py com topologia do mininet

(51)

Figura 18 – Terminal invocando a módulo do CLI e chamando o comando do connect

Figura 19 – Resultado da ação connect

(52)

Figura 20 – Resultado da ação run

Figura 21 – Testes na topologia

4.3.1 Análise de desempenho

No Backend, foram analisados o consumo de recursos computacionais na forma de Memória e CPU, tanto por parte da aplicação como um todo, tanto pela parte dos

(53)

contêineres disponibilizados para os usuários.

O servidor foi instalado em uma máquina virtual com as seguintes especificações:

Tabela 7 – Configurações da máquina virtual Sistema Operacional Memória Armazenamento CPU

Lubuntu 1024 Mb 20 Gb VDI 4 Núcleos

Como é impossível predizer a utilização de recursos dos contêineres pois os mesmos dependem da utilização por cada usuário, foram usadas as topologias padrão do Mininet para estimar uma quantidade suficiente de memória.

Para a geração dos dados foram criados 3 scripts em JS que foram inseridos em diferences contextos:

1. save-docker-stats-all.js: Fora da aplicação principal e coleta os dados de todos os contêineres simultaneamente usando a API Docker stats

2. save-docker-stats-single.js:: Fora da aplicação principal e coleta os dados de todos os contêineres individualmente usando a API Docker stats

3. save-app-stats.js: Dentro da aplicação principal coletando os dados da mesma usando a API do Node process.memoryUsage()

Estes scripts salvaram os dados gerados em arquivos csv (Comma Separated Values), como pode ser visto na figura 17.

(54)

Figura 22 – Exemplo de arquivo CSV de métrica

Além desses scripts também houveram outros escritos no frontend para permitir a emulação de usuários executando os comandos nas topologias, além de salvar uma timeline de como, quando e oque foi executado facilitando a união das métricas de forma coesa e a sua análise.

Na figura 18 está o gráfico que compara a utilização de memória e CPU pelas 5 topologias básicas do Mininet, vistas nas figuras 8, 9, 10 , 11 e 12. Com base no gráfico é possível ver um certo padrão no consumo de recursos, na memória geralmente ocorre um grande crescimento inicial e depois uma constância até o fim de execução, já a quantidade de processamento é baixa por padrão acontecendo alguns picos, picos esses que são geralmente distribuídos em dois.

(55)

Figura 23 – Gráfico de utilização de recursos pelas topologias padrão do mininet

Com base no gráfico anterior, e retirando um dos casos (Tree N = 4) para a melhor visualização, a figura 19 traz o gráfico com dois marcos no eixo X que correspondem a dois eventos que aconteceram no Frontend.

A linha pontilhada roxa descreve o momento de construção da topologia, na qual o mininet realiza a criação de todos os componentes de rede da aplicação, nessa hora acontece um leve pico na utilização de CPU que logo volta ao normal, e também um crescimento alto na utilização de memória que permanece em certa constância até o fim da execução.

Após este primeiro evento o usuário consegue realizar os testes de conectividade dentro do ambiente, neste caso foi utilizado o comando pingall que executa esse teste entre todos os nós na rede, o momento que este comando é executado é representado no gráfico pela linha pontilhada na cor azul, e é visível o grande pico de utilização de

(56)

CPU que ele acarreta, aumentando levemente a utilização de memória.

Figura 24 – Gráfico de utilização de recursos pela topologia de arvore com 4 de altura padrão do mininet

Estes dois gráficos trazem algumas informações essenciais para o entendimento da aplicação, primeiro que a utilização de memória é quase constante após a execução do ambiente emulado e permanece em seu máximo durante todo tempo de vida de uma topologia, isso mostra que este recurso pode ser rapidamente consumido por apenas alguns ambiente em execução e quando chega em seu máximo apenas com a saída de algum usuário é possível iniciar mais execuções.

Sendo assim este recurso deve ser deliberadamente limitado para cada usuário, possibilitando que mais topologias sejam utilizadas ao mesmo tempo.

Já para a utilização de processamento, o ambiente não é tão grave, apesar das topologias utilizarem uma grande quantidade desse recurso, como o mesmo acontece em picos e apenas em certos momentos de sua utilização, o processador tem tempos de respiro, e caso exista uma sobrecarga a API pode esperar pela diminuição do uso de CPU para executar uma nova chamada. Além disso a utilização de todo o

(57)

processamento em certos instantes não é tão grave e irreversível quanto a utilização de toda a memória disponível.

Com base nas informações coletadas sobre o uso de memória e processamento das topologias, foi conduzido alguns testes para determinar uma limitação de memória razoável para os contêineres.

Utilizando os mesmos dados da figura 18 e modificando sua visualização para um violinplot¹, que permite visualizar a distribuição da utilização de recursos.

Na figura 20 está o gráfico de violino e com ele é possível afirmar que a as topologias analisadas utilizam majoritariamente entre 40 à 60 MiB e no caso da topologia de arvore este dado aumenta para cerca de 60 à 80 Mib em sua execução.

Figura 25 – Gráfico de utilização de recursos pelas topologias padrão do mininet

Novamente constatando a constância de utilização de memória, porém ainda é difícil validar em que casos essa memória pode acabar aumentando e como definir um limite suficiente para a utilização.

1 Gráficos de violino (Violinplot) são parecidos com boxplots, exceto que eles também mostram a densidade de probabilidade dos dados