Universidade de Brasília
Instituto de Ciências Exatas Departamento de Ciência da Computação
Interface WEB e automação para simulações em redes ópticas
Matheus M. Sarmento
Monografia apresentada como requisito parcial para conclusão do Curso de Engenharia da Computação
Orientador
Prof. Dr. André Drumond
Brasília
2018
Universidade de Brasília
Instituto de Ciências Exatas Departamento de Ciência da Computação
Interface WEB e automação para simulações em redes ópticas
Matheus M. Sarmento
Monografia apresentada como requisito parcial para conclusão do Curso de Engenharia da Computação
Prof. Dr. André Drumond (Orientador) CIC/UnB
Prof. Dr. Marcos Fagundes Caetano Prof. Dr. João José Costa Gondim
CIC/UnB CIC/UnB
Prof. Dr. Ricardo Pezzuol Jacobi
Coordenador do Curso de Engenharia da Computação
Brasília, 22 de janeiro de 2018
Dedicatória
Dedico este trabalho a toda minha família, em especial à minha afilhada Renata.
Agradecimentos
Agradeço a todos que contribuíram no decorrer desta jornada e nesse projeto, em especial:
A minha família que sempre me apoiou nos estudos e nas escolhas tomadas.
Aos meus amigos, em especial Flávio, João Paulo, Franck, Daniel e Vitor Ao orientador Prof. André Drummond que me auxiliou na elaboração deste trabalho.
Ao Kaio A. da Silva que me orientou nas necessidades que o projeto deveria possuir e pelo fornecimento de um ambiente para a realização dos testes do trabalho.
Ao Instituto Federal de Educação, Ciência e Tecnologia de Rondônia - Campus Porto Velho Calama por disponibilizar a infra-estrutura do Centro Internacional de Metodos Numéricos em Engenharia (Sala IFRO-CIMNE) no desenvolvimento deste trabalho.
Resumo
Aplicações de cunho cientifico e estatístico costumam exigir bastantes recursos computa- cionais para alcançar seus resultados e por conta disso, os prazos de execução através da computação sequencial tornam as execuções dos processos impraticáveis. Como forma de superar tais desafios, a computação paralela surge como alternativa para aumentar o de- sempenho dessas aplicações e consequentemente minimizar o tempo gasto para a execução de tais tarefas.
Atualmente o simulador em redes ópticas (ONS), desenvolvido por pesquisadores da Universidade de Brasília enfrenta desafios no que tange ao tempo gasto em processamento das simulações. Apesar da disponibilidade de recursos computacionais distribuídos pelos pesquisadores, o simulador carece de uma ferramenta que lide com a distribuição de tarefas em um sistema distribuído, com o balanceamento de carga e com tolerância a falhas.
Além desse aspecto requer uma interface didática para exibição dos resultados gerados pelo simulador e um sistema de fácil interação com os pesquisadores para gerenciar o sistema e exportar os resultados mais facilmente.
Este trabalho apresenta informações sobre a ferramenta desenvolvida para automatizar a distribuição de tarefas do simulador ONS em um sistema distribuído tolerante a falhas, baseado no paradigma de programação paralela mestre/escravo. Além disso, a ferramenta se propõe a fornecer uma interface intuitiva para gerenciamento do sistema e exibição e exportação dos resultados.
Palavras-chave: ONS, sistemas distribuídos, mestre, escravo, despachador, trabalhador
Abstract
Scientific and statistical applications often require a lot of computational resources to achieve their results, such that time spent on execution through sequential computing makes the process impractical. As a way to overcome such challenges, parallel computing emerges as an alternative to increase the performance of those applications and conse- quently minimize the time spent to perform such tasks.
Currently the optical network simulador (ONS), developed by University of Brasilia’s researchers, faces challenges regarding the time spent in processing the simulations. De- spite the availability of computational resources distributed by the researchers, the simu- lator lacks a tool that deals with the distribution of tasks in a parallel system, with load balancing and fault tolerance. In addition, this aspect requires a didactic interface to display the results generated by the simulator and a system of easy interaction with the researchers to manage the system and export the results more easily.
This work presents information about the tool developed to automate the distribution of ONS’s tasks in a distributed fault tolerant system based on the parallel master / slave programming paradigm. In addition, the tool aims to provide an intuitive interface for system management and display and exportation of results.
Keywords: ONS, distributed system, master, slave, dispatcher, worker
Sumário
1 Introdução 1
1.1 Objetivos Gerais . . . 2
1.2 Objetivos Específicos . . . 3
1.3 Metodologia . . . 3
1.4 Organização do texto . . . 3
2 Revisão Conceitual 5 2.1 Computação Distribuída . . . 5
2.1.1 Acoplamento de sistemas com multiplos processadores . . . 5
2.1.2 Paradigmas de programação . . . 6
2.1.3 Tipos de computação distribuída . . . 7
2.1.4 Computação em Grade - GRID . . . 7
2.1.5 Tolerância a falhas . . . 7
2.2 Redes Ópticas . . . 8
2.2.1 Comutação por circuitos . . . 9
2.2.2 Comutação de pacotes . . . 9
2.2.3 Topologia Física . . . 9
2.2.4 Caminhos ópticos . . . 9
2.2.5 Topologia Virtual . . . 9
2.2.6 Multiplexação por Divisão de Comprimento de Onda . . . 10
2.2.7 Elastic Optical Network (EON) . . . 10
2.2.8 Optical Network Simulator (ONS) . . . 11
3 Requisitos e Implementação 14 3.1 Requisitos . . . 15
3.1.1 Descrição do Problema . . . 15
3.1.2 Regras de Negócio . . . 16
3.2 Dispatcher Worker Protocol (DWP) . . . 16
3.2.1 Tipos dos Campos . . . 17
3.2.2 Especificação dos PDUs . . . 17
3.3 Despachador . . . 20
3.3.1 Classes de negócio . . . 20
3.3.2 Arquivo de Configuração . . . 21
3.3.3 Conectividade com máquinas trabalhadoras . . . 22
3.3.4 Descobrimento de máquinas trabalhadoras . . . 23
3.3.5 Pedido de Recurso . . . 23
3.3.6 Expedição . . . 24
3.3.7 Detecção e tolerância a falhas . . . 25
3.3.8 Agendamento de execução e pausa de máquinas trabalhadoras . . . . 25
3.3.9 Desempenho das máquinas trabalhadoras . . . 26
3.3.10 Funcionalidades . . . 27
3.4 Trabalhador . . . 28
3.4.1 Conexão com despachador . . . 28
3.4.2 Alternância entre mecanismos de conexão . . . 29
3.4.3 Permissão de execução de instâncias de simulação . . . 29
3.4.4 Apelido da máquina . . . 29
3.4.5 Estados . . . 29
3.4.6 Execução de uma instância de simulação . . . 31
3.5 Trabalhos Similares . . . 31
3.6 Testes e Resultados . . . 31
3.6.1 Interface . . . 33
4 Conclusão 36 4.1 Trabalhos futuros . . . 36
Referências 38
Lista de Figuras
2.1 Exemplo de resultado de uma simulação do ONS para uma carga . . . 12
3.1 Visão geral da arquitetura do sistema . . . 14
3.2 Visão do simulador pelo sistema . . . 21
3.3 Fluxograma de entrada de uma nova máquina trabalhadora . . . 22
3.4 Exemplo de gráfico gerado pela combinação de dois resultados do simulador (Load v BBR) . . . 28
3.5 Máquina de estados de uma máquina trabalhadora . . . 30
3.6 Interface das máquinas trabalhadoras . . . 33
3.7 Interface dos grupos de simulações em execução . . . 34
3.8 Menu dropdown com a seleção dos possíveis eixos de avaliação . . . 35
3.9 Exemplos de dois gráficos gerados pelo sistema . . . 35
Lista de Abreviaturas e Siglas
CPU Central Processing Unit.
CWDM Coarse Wavelength-Division Multiplexing.
DWDM Dense Wavelength-Division Multiplexing.
DWP Dispatcher Worker Protocol.
EON Elastic Optical Network.
JSON Javascript Object Notation.
ONS Optical Networks Simulator. PDU Protocol Data Unit.
RSA Routing and Spectrum Assignment.
RWA Routing and Wavelength Assignment.
TCP Transmission Control Protocol.
UDP User Datagram Protocol.
UnB Universidade de Brasília.
WDM Wavelength-Division Multiplexing.
XML eXtensible Markup Language.
Capítulo 1 Introdução
O grande avanço tecnológico em comunicação observado nas últimas décadas aprofundou internacionalmente a integração econômica, social, cultural e política, tendo a internet como uma grande contribuição nesse acontecimento. Criada com objetivos militares du- rante a guerra fria, serviu como alternativa aos meios tradicionais de telecomunicações à época (telefones e telégrafos), por possuir uma arquitetura planejada para manter as comunicações militares operantes em caso de destruição dos meios de comunicação con- vencionais por conta de um ataque inimigo. Sua popularização veio na década de 1990 com a invenção da World Wide Web por Tim Berners-Lee, sistema de documentos em hipermídia que permitiu uma integração mais facilitada com usuários sem conhecimento técnico sobre internet a partir de uma interface gráfica dinâmica e intuitiva. Desde então houve um crescimento exorbitante de usuários da rede mundial de computadores: em 2015, cerca de 3,2 bilhões de pessoas já possuiam acesso à Internet [1], contabilizando aproximadamente 43% da população mundial. Em mesma proporção veio o aumento sig- nificativo de tráfego de dados pela rede. Em 2016, a taxa de transmissão anual para o tráfego global de IP foi de 1,2 Zettabytes (aproximadamente 1,2 trilhão de gigabytes) de dados por ano, onde é previsto que esse valor atinja a marca de 3,3 ZB para o ano de 2021 [2].
Um dos principais fatores que permite à Internet esse imenso crescimento e escala- bilidade é como os dados são encaminhados, visto que os protocolos da Internet foram desenvolvidos para serem independentes do meio físico de transmissão. Atualmente exis- tem três meios físicos que conectam as operadoras aos usuários, sendo eles:
Cabo de par trançado: dois filamentos entrelaçados de forma a cancelar interferências eletromagnéticas externas, mas ainda assim estão suscetíveis a ruídos externos; sua trans- missão de dados é feita através de pulsos elétricos. Como esse tipo de cabo aproveita a infraestrutura telefônica é o mais comum e o mais barato entre os três tipos [3], mas em comparação, é o que fornece a menor largura de banda, acarretando em menores taxas de
transferência de dados.
Cabo coaxial: possui um fio central de cobre revestido por uma malha protetora externa que absorve possíveis interferências; sua transmissão de dados é feita através de pulsos elétricos. Com um custo um pouco maior consegue transmite 80 vezes mais capacidade que o par trançado [3].
Fibra óptica: tecnologia mais nova dentre as três, é constituída de filamentos flexíveis de vidro revestidos em um material eletricamente isolante. Diferentemente das outras tecnologias, a transmissão de dados se dá em forma de luz, e por conta disso, não sofre interferências eletromagnéticas. Além disso, consegue atingir 26,000 vezes mais capaci- dade de transmissão do que cabos de par trançado [3]. As pesquisas feitas nessa área visam avaliar desempenho de sistemas de comunicação óptica, no entanto, por questões de custo e disponibilidade, muitas vezes é inviável a realização de análises e testes em uma configuração real. Para isso, pesquisadores da Universidade de Brasília (UnB) de- senvolveram um simulador em redes ópticas que avalia os paradigmas em redes ópticas de Multiplexação por Comprimento de Onda (Wavelength Division Multiplexing, WDM) e a recente Redes Ópticas Elásticas (Elastic Optical Networks, EON) (COSTA; SOUSA;
OLIVEIRA; SILVA; JÚNIOR; DRUMMOND, 2016) [4].
Simuladores dessa espécie costumam exigir bastante processamento computacional para realizar suas tarefas, onde habitualmente opta-se pelo desenvolvimento de um sistema que gerencie a distribuição dessas tarefas em sistema distribuído, de forma a agilizar o tempo de simulações. No entanto, o simulador em questão carece de tal ferramenta, e uma interface gráfica intuitiva que permita didaticamente a demonstração de seus resultados.
1.1 Objetivos Gerais
• Fornecer uma aplicação computacional robusta que encarregue-se de eliminar pro- cessos reiterativos facilmente substituíveis por procedimentos em software;
• Otimizar a eficiência do trabalho do pesquisador, no que tange à execução de simu- lações de redes ópticas do simulador ONS;
• Permitir um maior controle intuitivo fornecendo uma interface gráfica que também servirá de demonstração didática para outros pesquisadores interessados na proposta do simulador.
1.2 Objetivos Específicos
• Promover a automação e controle de delegação de atividades em simulações de redes ópticas em um sistema distribuído;
• Fornecer uma interface de usuário para a exibição do comportamento das soluções, exportação de dados e fácil interação com o sistema;
• Proteger o sistema contra fatores adversos que possam afetar a continuidade das simulações, sem a necessidade de intervenção humana.
1.3 Metodologia
O trabalho será desenvolvido com base na metodologiaAgile SCRUM [5], onde serão feitas pequenas iterações em qual cada um objetiva-se alcançar a implementação de característi- cas novas(features) ao sistema ou correções de falhas(bugs). Uma interação (sprint) dessa rotina consiste nas seguintes 5 etapas:
1. Levantamento de requisitos com os usuários sobre novas características ou ações corretivas do sistema;
2. Planejamento, organização e estimativa de prazo;
3. Desenvolvimento/correção do que foi planejado;
4. Testes em uma configuração de cenário real;
5. Validação dos resultados pelo usuário.
As iterações costumam compreender períodos relativamente curtos de tempo (1 a 2 sema- nas) onde são realizadas todas as implementações planejadas, entregando em seguida aos usuários o novo incremento do sistema para validação. Dessa forma, o desenvolvimento torna-se mais reativo às necessidades do usuário e responsivo à mudanças nos requisitos.
1.4 Organização do texto
O documento está dividito em 4 capítulos. No primeiro capítulo apresenta-se uma breve contextualização e apresentando a problemática central, bem como os objetivos gerais e específicos.
No segundo capítulo é realizado um embasamento teórico sobre a temática de compu- tação distribuída, redes ópticas e o simulador ONS, fundamentais para a compreensão do sistema proposto.
O terceiro capítulo apresenta os requisitos do sistema, a proposta de solução e im- plementação do mesmo, como a elaboração do protocolo de comunicação compartilhado entre os elementos do sistema e o desenvolvimento das aplicações despachadora e traba- lhadora. Nesse capítulo é também feita a exposição dos resultados obtidos durante os testes em um ambiente real.
Por fim, o quarto capítulo contém as considerações finais e os trabalhos futuros.
Capítulo 2
Revisão Conceitual
Neste capítulo será apresentado um embasamento teórico suficiente para a compreensão do escopo avaliado pelo sistema desenvolvido nesse trabalho.
2.1 Computação Distribuída
Tanenbaum e Van Steen, 2007 [6], definem um sistema distribuído como coleções de com- putadores independentes que apresentam-se como um sistema único e coerente ao usuário.
Dessa forma, os processos complexos são fragmentados em tarefas menores de forma a serem distribuídas entre os componentes autônomos que estão interconectados, paraleli- zando o processamento dos dados e ampliando virtualmente o desempenho computacional do sistema. Como cada máquina possui sua autonomia, permite-se que a escalabilidade do sistema aconteça de forma fácil e flexível. No entanto, com essa técnica surgem al- guns desafios para a implementação desse método de maneira correta e eficiente, como o compartilhamento de recursos, condições de corrida e dependência de dados para proces- samentos subsequentes.
2.1.1 Acoplamento de sistemas com multiplos processadores
A forma com que os processadores estão interligados irá definir o tipo de acoplamento do sistema com múltiplos processadores.
Acoplamento forte
Consiste em um sistema com múltiplos processadores onde possuem uma unidade central de memória compartilhada entre os processos, fornecendo dessa forma, tempo de acesso rápido das aplicações aos dados. Sistemas desse tipo fornecem, portanto, maiores veloci- dades em seu processamento em computação distribuída, porém são intrinsecamente mais
caros pois necessitam muitas vezes de hardware especial para tratamento de conflitos de memória entre processos e mecanismo de sincronização entre processos.
Acoplamento fraco
Esse tipo de sistema aproveita diferentes componentes computacionais já existentes, não possuindo dessa forma o compartilhamento de recursos físicos. São interconectados tipica- mente por sistemas de alta velocidade de comunicação, como ethernet, onde a comunicação entre os processos é dada via troca de mensagens, fornecendo menores taxas de dados en- tre os processos em comparação a um sistema fortemente acoplado. Apesar de mais lentos ante aos sistemas fortemente acoplados, o acoplamento fraco permite um maior tamanho do sistema a um custo menor, além de propiciar menor imposição de mesma plataforma, linguagem, sistema operacional ou ambiente de construção aos componentes do sistema.
2.1.2 Paradigmas de programação
BUYYA, 1999 [7], estabelece classificações de paradigmas de programação em aplicações em paralelo para lidar com os novos desafios impostos pela computação com múltiplos núcleos. As mais populares dentre elas são: Mestre/Escravo, Um Programa Múltiplos Dados e Dividir e Conquistar.
Mestre/Escravo
Envolve dois tipos de processadores: o processador mestre e o processador escravo. O processador mestre visa decompor um processo complexo em tarefas menores para con- sequente distribuição dos trabalhos e posteriormente coletar e organizar os resultados intermediários gerados de forma a compor o resultado final. O processador escravo, por sua vez, visa exclusivamente a execução da ordem de trabalho designada pelo processa- dor mestre. Segundo Meyer [8], normalmente, a comunicação entre os processos é feita somente entre o mestre e os escravos, ou seja, as unidades escravas não possuem qualquer conhecimento umas das outras.
A divisão das tarefas, também chamada de balanceamento de carga é categorizada como estática ou dinâmica. A divisão estática das tarefas é realizada no início da compu- tação, enquanto a dinâmica ocorre durante a execução da aplicação.
Um Programa Múltiplos Dados (Single Program Multiple Data - SPMD) Considerado o paradigma de programação paralela mais comum na ciência da computa- ção [9], o SPMD, trabalha com múltiplos processadores autônomos executando simulta- neamente o mesmo programa, embora cada um tenha seus próprios dados.
Dividir e Conquistar
Consiste na divisão de um problema complexo em diversos subproblemas, onde cada um é processado individualmente e posteriormente os resultados são combinados de forma a concluir um resultado ao problema profundo. Esse paradigma, diferentemente do mestre- escravo, não possui um processador responsável unicamente pela divisão e distribuição das tarefas; a divisão e distribuição ocorrem a partir dos nós e suas hierarquias subsequentes.
2.1.3 Tipos de computação distribuída
Cluster
Consiste no acoplamento (forte ou fraco) de computadores normalmente homogêneos, ou seja, que possuem características de processamento similares e sistema operacional em comum, trabalhando em conjunto para atingir um determinado objetivo, podendo ser maior redundância ou maior desempenho. Segundo DANTAS(2005) [10], o escopo geográfico de um cluster parte desde uma pequena sala até no máximo uma organização, onde a comunicação das máquinas é realizada através de uma rede de área local (Local Area Network - LAN), pelo compartilhamento de recursos, ou pela combinação dos dois.
2.1.4 Computação em Grade - GRID
Em contraste ao cluster, a computação em grade não possui limitação espacial, ocasio- nando na distribuição geográfica das máquinas que participam do sistema distribuído. É portanto um sistema distribuído fracamente acoplado onde a composição das máquinas é heterogênea, ou seja, pode ser composto por hardwares, sistemas operacionais e redes distintas (TANENBAUM; STEEN, 2007). A principal característica dessa tecnologia de sistema é a utilização de recursos ociosos de máquinas de diversos domínios para aplica- ções matemáticas, científicas ou com propósito educacional que exigem bastante poder computacional.
2.1.5 Tolerância a falhas
Tolerância à falhas em um sistema distribuído é a habilidade do sistema de detectar e se recuperar mediante a ocorrência de falhas em hardware ou software, de forma a manter a continuidade dos serviços de acordo com suas especificações [11].
Um sistema tolerante a falhas em um sistema distribuído se faz necessário pois garante:
1. Confiabilidade: efetuar suas tarefas perante condições adversas;
2. Disponibilidade: garantia da operabilidade do sistema dado um certo momento, assegurado pela taxa de quantidade de tempo efetivamente em operação em relação ao tempo total que deveria estar operante;
3. Segurança: prevenção de acessos não autorizados ao sistema.
Técnicas empregadas para tolerância a falhas Checkpointing
A técnica consiste no armazenamento persistente e periódico do estado do sistema en- quanto funciona corretamente. Se uma falha ocorre, o sistema é restaurado ao estado onde a falta não ocorria. Atua bem quando as falhas são transientes ou intermitentes.
Replicação
Consiste na criação de múltiplas cópias persistentes em diferentes armazenamentos, de modo que aumente a disponibilidade dos dados havendo a falha de um nó do sistema, a informação permanece disponível através de outra reserva de dados. Deve possuir um mecanismo de consistência de dados entre os meios de armazenamento, bem como quantos níveis de replicação devem existir.
Como solução à crescente demanda das provedoras de serviço por mais capacidade de transferência na rede, a utilização da luz como meio de propagação de dados tem chamado bastante atenção pela sua alta largura de banda, transmissão à longas distâncias e imunidade à interferências eletromagnéticas, grandes vantagens em constraste com as outras tecnologias atuais. No entanto, é necessário que a tecnologia esteja adaptada aos meios de comunicação atuais que baseiam-se em grande parte à comunicação por sinais elétricos. Na transmissão dos dados, através de dispositivos chamados de transceptores, os sinais elétricos são convertidos em sinais de luz e propagados na fibra óptica de uma ponta à outra. Já na recepção dos sinais de luz, o transceptor converte novamente para um sinal elétrico.
2.2 Redes Ópticas
Este capítulo visa trazer os principais conceitos que são objeto de avaliação do simulador ONS.
2.2.1 Comutação por circuitos
A comutação por circuitos estabelece um método de conexão entre nós de uma rede onde se faz necessária a alocação de um canal de comunicação físico dedicado, também chamado de circuito, cuja troca de dados é realizada. Enquanto há a conectividade entre os pares, o circuito mantém-se reservado e ocupado para o uso de um terceiro nó que deseje aproveitar o mesmo canal. O canal é composto a partir de uma sequência de conexões entre elos físicos de nós na rede, configurando uma ligação virtual entre os pares.
2.2.2 Comutação de pacotes
A comutação por pacotes determina que não é necessária uma conexão dedicada entre os nós, possibilitando o compartilhamento de um mesmo canal de comunicação entre diver- sos nós da rede. Para tal, a informação a ser transmitida é fragmentada em pequenos pacotes de dados onde são encapsulados com informações de controle que provém dados de roteamento do destino do pacote. Dessa forma os pacotes provenientes de uma mesma fonte de informação podem ser encaminhados pela rede por diferentes caminhos, não ha- vendo, contudo, a garantia que cada pacote alcance o destino ou mesmo chegue ordenado, cabendo ao receptor a ordenação e recuperação de pacotes perdidos.
2.2.3 Topologia Física
A topologia fisica de uma rede óptica consiste em uma série de nós interligados por conexões físicas de fibra óptica, também chamados de ligações físicas.
2.2.4 Caminhos ópticos
No contexto de redes ópticas, um caminho óptico é um meio de comunicação entre dois nós de uma rede onde em toda sua propagação, o sinal não é convertido em forma elétrica.
Assim como na comutação por circuitos, um caminho óptico estabelece a comunicação entre os pares através de "um único salto", ao realizar uma sequência de interconexões físicas que possuem a propriedade de ocupar o mesmo comprimento de onda em todo seu caminho, também chamado de restrição de continuidade do comprimento de onda [12].
2.2.5 Topologia Virtual
Similarmente à topologia física, consiste na interligação de nós em uma rede óptica. No entanto, a conexão é realizada mediante a caminhos ópticos em oposição à fibra óptica.
2.2.6 Multiplexação por Divisão de Comprimento de Onda
A multiplexação por divisão de comprimento de onda, do inglês Wavelength-Division Multiplexing (WDM), é uma técnica que consiste no compartilhamento simultâneo de múltiplas frequências eletromagnéticas em um mesmo filamento de fibra óptica [12].
Essa técnica apoia-se sobre a propriedade de dispersão da luz, fenômeno que permite a separação de um feixe de luz em cores que a compõem, observado tipicamente em prismas.
O WDM, portanto, transmite diversos sinais de luz unidos sobre uma fibra óptica, onde cada um é individualizado no receptor dos feixes. O WDM divide o espectro em diferentes faixas de frequências, chamadas de canais, onde são espaçados uns aos outros por uma faixa de proteção de filtro, padronizada pela União de Telecomunicações Internacionais por 50GHz ou 100GHz.
Atualmente, o WDM possui três tipos de padrões de comprimento de onda em uma fibra óptica: o normal(WDM), o grosseiro(CWDM) e o denso(DWDM), onde o WDM utiliza apenas dois comprimentos de onda; o Coarse Wavelength-Division Multiplexing (CWDM) conseguindo prover até 16 canais de multiplexação; e o Dense Wavelength- Division Multiplexing (DWDM) que tem a capacidade de comportar de 40 à 80 canais simultâneos.
Essa técnica tornou-se popular entre as companhias de telecomunicações pois permitiu o aumento significativo da capacidade de transmissão das fibras ópticas sem a necessidade de investimentos em infraestrutura adicionando mais filamentos para alcançar os mesmos níveis de transmissão.
No WDM, a comunicação entre os usuários da rede é realizada por meio de caminhos ópticos. No entanto, visto a propriedade de restrição de continuidade do comprimento de onda, surge o problema de alocação de caminhos ópticos que construam um circuito inteiramente usuário-a-usuário que seja restrito à uma mesma frequência de onda. Dessa forma, um mesma conexão entre dois nós da rede não pode compartilhar mais de um comprimento de onda. Uma das técnicas mais conhecidas para a resolução desse problema é o Routing and Wavelength Assignment (RWA), que é um dos alvos de avaliação do simulador ONS.
2.2.7 Elastic Optical Network (EON)
O EON surgiu como alternativa ao WDM para sanar uma de suas limitações, que consiste na sobrecarga ocasionada pela faixa de proteção de filtro caso um canal transmita apenas baixas larguras de banda. Como consequência disso, grande parte do espectro fica inuti- lizado somente para realizar o espaçamento dos canais. M. Jinno, 2008 [13] propôs uma solução para o problema utilizando a tecnologia Orthogonal Frequency-Division Multi-
plexing (OFDM) aplicado à redes ópticas. O OFDM é uma tecnologia já utilizada em aplicações como TV digital, transmissão de audio, redes sem fio e telefonia móvel 4G que consiste na alocação de dados em diversos canais subportadores com baixas taxas de dados. Como proveito da modulação ortogonal do espectro de canais subportadores adja- centes, as amplitudes podem se sobrepor aumentando a eficiência de transmissão espectral em contraponto à proposta vista no WDM.
Assim como o WDM, nas redes EON também são necessários algoritmos de roteamento e de atribuição do espectro, Routing and Spectrum Assignment(RSA), que também são avaliados pelo simulador ONS.
2.2.8 Optical Network Simulator (ONS)
Como forma de reduzir custos e permitir uma maior resguardo no momento da implanta- ção de um projeto em um cenário real, a modelagem computacional de sistemas complexos tem sido introduzida cada vez mais em setores industriais e em meios acadêmicos. São propostas de modelos comportamentais de processos reais complexos, onde delimita-se o escopo de interesse do problema a ser avaliado.
Inspirado no WDMSim [14], o ONS é um simulador de eventos discretos que avalia de- sempenho dos sistemas de comunicação óptica para os paradigmas WDM e EON (COSTA et. al, 2016). O sistema de despachador foi desenvolvido para otimizar os processos dos pesquisadores na utilização deste simulador.
Diretivas de entrada
Para que o simulador avalie os algoritmos desejados para uma topologia física específica à uma carga determinada, é necessário que o usuário especifique-os a partir das diretivas de entrada do simulador. Para esse trabalho, serão avaliados apenas os parâmetros de in- teresse. Uso: ONS simulationfile seed [minload maxload step] Os parâmetros obrigatórios do simulador empregados na linha de comando são os seguintes:
• simulationfile: o arquivo XML contendo os parâmetros da simulação;
• seed: trata-se de um número no intervalo [1-25] que define 25 diferentes conjuntos de sementes escolhidas internamente para maximizar a qualidade das sequências aleatórias utilizadas. Para a geração de resultados com intervalo de confiança em uma mesma simulação, se faz necessário a execução com diferentes conjuntos de sementes.
Os parâmetros opcionais do simulador são:
Figura 2.1: Exemplo de resultado de uma simulação do ONS para uma carga
• minload maxload step: permite a automação de diversas execuções de uma mesma simulação para uma faixa de cargas no intervalo [minload, maxload] e incremento [step]. Para fins de fragmentação de tarefas que serão expedidas para o sistema distribuído, os valores de minLoad e maxLoad serão especificamente os mesmos, pois dessa maneira o simulador executa a menor tarefa possível, granularizando o seu escopo de execução.
Diretivas de saída
Ao término da simulação, os resultados processados devem ser exportados à saída de fluxo padrão (standard output stream) em um formato JSON (Figura 2.1), protocolando a comunicação do simulador com o sistema que irá manipular os dados.
Funcionamento
A partir de um arquivo de configuração XML, o pesquisador decide a construção da rede a ser avaliada, podendo caracterizar a tecnologia de rede (WDM/EON), o algoritmo de alocação de recursos (RWA/RSA), os dados relativos ao cenário de tráfego e a configuração da topologia física (número de nós, enlaces, dispositivos e características da rede) (COSTA et. al, 2016).
O simulador emula o tráfego entre os nós definidos no arquivo de configuração e gera um evento para cada fluxo de dados que se dá a partir de um nó de origem a um nó de destino, onde são escolhidos aleatoriamente seguindo uma distribuição uniforme. Todos eventos gerados são inseridos em uma fila de prioridade cuja ordenação é feita de acordo com o momento em que os eventos devem ocorrer durante a simulação.
Em uma próxima etapa, todos os eventos gerados e enfileirados são consumidos orde- nadamente para qual cada um é executado um algoritmo RWA/RSA/RMLSA, baseado nas informações do estado da rede e do evento recebido, que por sua vez, toma a decisão de aceitar ou bloquear uma chamada.
O processo executado pelo simulador, dependendo da topologia física modelada pelo pesquisador e os algoritmos avaliados, pode gerar muitos eventos para serem tratados e cálculos bastantes complexos, acarretando a exigência de recursos da máquina para seu devido processamento que justificam a necessidade de um sistema distribuído para a execução desses tipos de simulações. Um gráfico, por exemplo, que compara o comporta- mento de três algoritmos com cinco pontos de carga e cinco sementes gera um total de 75 instâncias de simulação.
Capítulo 3
Requisitos e Implementação
Nesse capítulo serão descritos os requisitos iniciais propostos, a documentação do projeto e como o mesmo é organizado. Como forma de elucidar a estrutura do projeto, a Fi- gura 3.1 descreve uma visão geral da arquitetura do sistema. Os usuários interagem com a interface WEB, que por sua vez resgata e envia comandos para o sistema despacha- dor. O despachador gerencia as tarefas para as máquinas trabalhadoras e recupera seus resultados, persistindo-os em uma base de dados.
Figura 3.1: Visão geral da arquitetura do sistema
O projeto possui código aberto e está disponível nos links:
• Despachador: https://github.com/MatheusMS01/web_dispatcher
• Trabalhador: https://github.com/MatheusMS01/worker
• Protocolo DWP: https://github.com/MatheusMS01/protocol
O desenvolvimento foi realizado na linguagem JavaScript a partir da plataforma No- deJS. Os projetos estão separados em repositórios diferentes para evidenciar a separação lógica das aplicações, e permitir mais facilmente uma eventual mudança de linguagem de programação, se necessário, desde que o protocolo de comunicação seja respeitado.
3.1 Requisitos
Esta seção tem como objetivo descrever de forma geral o sistema, o escopo e suas principais funções.
3.1.1 Descrição do Problema
Pesquisadores comumente, seja por questões de custo, disponibilidade ou praticidade, re- correm ao auxílio de simuladores para conduzir experimentos com o propósito de entender o comportamento de um sistema real e/ou avaliar estratégias para sua operação (Pedgen, 1991).
Geralmente, esses tipos de aplicações envolvem bastantes iterações que irão gerar uma quantidade amostral suficiente para fornecer dados próximos aos que seriam obtidos um sistema real. Além disso, costumam exigir tempo e recursos computacionais consideráveis para alcançar seus resultados. Combinando esses dois principais fatores, a realização da pesquisa pode inviabilizar ao pesquisador o fornecimento dos resultados em um tempo hábil. Por esse motivo, opta-se pela computação distribuída onde serão paralelizadas, na medida do possível, as tarefas geradas pelo simulador, reduzindo por consequência, o tempo total da execução das simulações. Apesar das vantagem da computação distri- buída, na condição de não existência um sistema autônomo para gerenciá-la, novos obs- taculos manifestam-se, como a distribuição das tarefas e a fatores adversos que possam afetar a continuidade das simulações, implicando no despêndio de tempo em configuração bem como no retrabalho corrigindo tarefas afetadas por desconformidades durante suas execuções.
Com a finalidade de sanar os problemas supracitados, o sistema em questão visa gerenciar a distribuição de simulações em um sistema distribuído bem como garantir, na medida do possível, a resolução de fatores adversos, deixando transparente ao usuário
como isso é feito, sem qualquer necessidade de intervenção manual do usuário para apurar esses contratempos.
3.1.2 Regras de Negócio
Deverá possuir uma interface WEB onde o usuário fará sua interação.
O sistema deve partir da premissa de menor intervenção do usuário no sistema, garan- tido apenas pelas entrada das simulações a serem avaliadas e também a disponibilidade dos recursos computacionais que irão lidar com o devido processamento dos dados.
Deverá ser tolerante a falhas, como finalização anormal ou intermitencia de conecti- vidade de uma máquina conectada ao sistema. Também lidará, dentro do possível, com execuções de tarefas finalizadas incorretamente ocasionadas por falhas do simulador.
Os gráficos resultantes das execuções das simulações deverão ser exibidos em tempo real à medida que seus resultados forem gerados.
As tarefas deverão ser distribuídas igualitariamente às máquinas ativas no sistema, desde que cada máquina suporte novas execuções de tarefas a partir da disponibilidade de seus recursos.
As máquinas poderão ser reservadas para execuções de tarefas do proprietário que a disponibilizou na rede.
As máquinas trabalhadoras deverão se conectar dinamicamente ao despachador.
A comunicação realizada entre as partes deverá obedecer um contrato definido a partir de um protocolo de comunicação desenvolvido especificamente para essa finalidade.
As aplicações despachadora e trabalhadora deverão ser projetos independentes, com- partilhando apenas o protocolo de comunicação.
3.2 Dispatcher Worker Protocol (DWP)
O DWP é um protocolo da camada de aplicação responsável pela troca de mensagens, transmissão de comandos e realização de configurações entre o despachador e as máquinas trabalhadoras. É independente de um subsistema de transmissão específico, requerendo somente um canal de transmissão que garanta confiabilidade e integridade dos dados. Os dados dos Protocol Data Unit (PDU) são formatados via JSON e encapsulados por meio de duas marcações que indicam respectivamente o início e fim do pacote. São atribuídos a cada PDU um identificador único numérico, assegurando a distinção deles no momento de análise do pacote por uma das pontas de tratamento.
3.2.1 Tipos dos Campos
No protocolo DWP, os campos dos PDUs devem obedecer um dos tipos abaixo:
• String
• Número
• Objeto JSON
• Matriz
• Booleano
3.2.2 Especificação dos PDUs
ControlCommand
Mensagem enviada do despachador para uma máquina trabalhadora. Define uma ação que o despachador deseja que a máquina trabalhadora execute. Essas ações estão relacionadas ao comportamento da máquina trabalhadora.
Campo Tipo do
Campo
Obrigatório Observação
Comando Número Sim Admite os se-
guintes valores:
Comando Valor
Pausar 0
Retomar 1
Parar 2
ReportRequest
Mensagem enviada do despachador para uma máquina trabalhadora. Mensagem de sincro- nismo do despachador com um trabalhador, de forma a obter conhecimento das simulações que a máquina está executando, caso haja alguma.
Campo Tipo do
Campo
Obrigatório Observação
N/A N/A N/A N/A
ReportResponse
Mensagem enviada de uma máquina trabalhadora para o despachador. Resposta de um ReportRequest.
Campo Tipo do Campo
Obrigatório Observação
Instâncias em execução
Matriz Sim Este campo configura
uma matriz de infor- mações sobre os iden- tificadores das instân- cias em execução da- quela máquina.
E-mail String Não Este campo configura
o identificador do usuário proprietário da máquina
Apelido String Não Este campo configura
o apelido da máquina ResourceRequest
Mensagem enviada do despachador para uma máquina trabalhadora. Realiza o pedido mais atual dos recursos da máquina.
Campo Tipo do
Campo
Obrigatório Observação
N/A N/A N/A N/A
ResourceResponse
Mensagem enviada de uma máquina trabalhadora para o despachador. Resposta de um ResourceRequest.
Campo Tipo do
Campo
Obrigatório Observação
Processamento em Central Processing Unit (CPU)
Número Sim Este campo informa
a taxa de disponibili- dade de CPU da má- quina
Memória Número Sim Este campo informa
a taxa de disponibili- dade de memória da máquina
SimulationRequest
Mensagem enviada do despachador para uma máquina trabalhadora. Pedido de um despa- chador para uma máquina trabalhadora de execução de uma nova instância de simulação.
Campo Tipo do
Campo
Obrigatório Observação
Dados da instân- cia de simulação
Objeto JSON Sim Este campo informa
as diretrizes de execu- ção da instância de si- mulação bem como o executável e arquivos de configuração
SimulationResponse
Mensagem enviada de uma máquina trabalhadora para o despachador. Resposta de um SimulationRequest.
Campo Tipo do
Campo
Obrigatório Observação
Resultado Objeto JSON Sim Este campo informa
o estado e o resul- tado proveniente da execução da simula- ção. O estado admite os seguintes valores:
Estado Valor Sucesso 0
Erro 1
ID da instância de simulação
Número Sim Este campo informa o
identificador único da simulação que foi fina- lizada.
SimulationTerminateRequest
Mensagem enviada do despachador para uma máquina trabalhadora. Pedido de término de uma instância de simulação à uma máquina trabalhadora.
Campo Tipo do Campo
Obrigatório Observação
ID da instância de simulação
Número Sim Este campo informa o
identificador único da simulação que deve ser terminada.
3.3 Despachador
Apoiado no paradigma de programação mestre/escravo, o despachador é um serviço mes- tre tolerante a falhas responsável pelo controle do sistema, onde atua nele como elemento central. Através de troca de mensagens, gerencia a conexão de máquinas trabalhadoras assim como a distribuição de instâncias de simulação da aplicação ONS, recebendo os resultados das execuções e persistindo-os em uma base de dados. O despachador protege os dados das simulações contra fatores adversos que podem afetar a sua continuidade.
São exemplos de fatores adversos:
Do despachador
• Queda na rede;
• Eventuais problemas de programação;
• Reinício do processo.
Da máquina trabalhadora
• Queda na rede enquanto executava uma instância;
• Falha na execução de uma instância.
Um importante aspecto do sistema despachador é que a aplicação do simulador ONS é vista por ele como uma caixa preta (Figura 3.2), ou seja, não é do escopo do sistema o conhecimento de qualquer implementação do simulador, apenas suas diretivas de entrada e saída são de seu interesse. Dessa maneira deixa-se flexível a alteração interna do simulador, possibilitando até mesmo a linguagem com a qual é programado.
3.3.1 Classes de negócio
São objetos que compõe o sistema para garantir sua perenidade e seu estado de consis- tência. São eles:
Figura 3.2: Visão do simulador pelo sistema
• Simulador: Aplicação que obedece as diretrizes de entrada e saída da aplicação ONS;
• Arquivo de configuração: Documento onde estão registradas as características do sistema a ser simulado;
• Grupo de simulações: Agregação de associações de um simulador com um arquivo de configuração. Armazena também informações de quantas cargas de execução serão executadas para aquele grupo, bem como a quantidade de sementes, que irão incorporar o fator de aleatoriedade ao simulador;
• Simulação: Associação de um simulador com um arquivo de configuração;
• Instância de simulação: Nível de execução de uma simulação para uma única carga.
É a menor divisão de tarefa fornecida pelo simulador ONS.
3.3.2 Arquivo de Configuração
A instalação de um sistema pode requerer uma configuração prévia do usuário para que melhor se adeque ao propósito que deseja-se alcançar. Com essa motivação, o sistema despachador disponibiliza um arquivo de configuração o qual o usuário decida a escolha certos parâmetros, onde é possível configurar:
• Limiar de remanescência de processamento em CPU: Define, em porcentagem, o valor o qual o despachador deve deixar disponível em processamento em CPU nas máquinas trabalhadoras, resultando em não envio de execuções de instâncias de simulação para uma máquina caso seu recurso em CPU esteja abaixo desse parâme- tro;
• Limiar de remanescência de memória: Define, em porcentagem, o valor o qual o despachador deve deixar disponível em memória nas máquinas trabalhadoras, re- sultando em não envio de execuções de instâncias de simulação para uma máquina caso seu recurso em memória esteja abaixo desse parâmetro;
• Limiar de desempenho: Define, em porcentagem, os intervalos de análise de desem- penho das máquinas trabalhadoras;
Figura 3.3: Fluxograma de entrada de uma nova máquina trabalhadora
• Intervalo de pedido de recursos: Define, em segundos, o valor que o despachador requisita recursos das máquinas trabalhadoras conectadas ao sistema;
• Intervalo de expedição: Define, em segundos, o valor que o despachador realiza o procedimento de expedição em lotes.
3.3.3 Conectividade com máquinas trabalhadoras
O despachador possui um socket TCP aberto na porta 16180 para estabelecimento de conexões com máquinas trabalhadoras. Uma vez que uma máquina se conecta ao des- pachador, o fluxograma apresentado na Figura 3.3 é executado. Este algoritmo se faz necessário devido ao cenário de intermitência de conectividade de uma máquina trabalha- dora. Caso a máquina que possuía instâncias de simulação em execução deixe a rede por problemas de conectividade e em um momento posterior retome sua conexão, o procedi- mento tende a aproveitar o processamento que já foi realizado, atribuindo à máquina que finalizaria mais cedo a tarefa de executar aquela instância até o final, liberando recursos da máquina que terminaria mais tardiamente.
3.3.4 Descobrimento de máquinas trabalhadoras
O despachador possui um socket UDP aberto na porta 16180 o qual recepciona mensagens de outras máquinas que desejam se conectar ao despachador via descoberta dinâmica.
Ao recebimento de uma mensagem por esse socket, é enviada uma resposta contendo o endereço do despachador na rede, que será utilizado pela máquina trabalhadora para a conexão TCP a posteriori. Como para o protocolo UDP não há qualquer tipo de garantia que o pacote irá chegar ou não, até que seja gerado um evento de conexão no socket TCP por aquela máquina, a resposta é reenviada a cada período de um segundo.
3.3.5 Pedido de Recurso
O sistema procura sempre manter os dados atualizados dos recursos das máquinas tra- balhadoras para ter conhecimento de quais delas estão disponíveis para a execução de uma nova instância de simulação. Para isso, seguindo o intervalo configurado no arquivo de configuração, o despachador envia um PDU de ResourceRequest para cada uma das máquinas ativas no sistema. Ao recebimento de um ResourceResponse, são atualizados os recursos da máquina. Como uma simulação logo após seu inicio desenvolve um consumo de recursos da máquina, é recomendável que o intervalo de pedido de recursos seja baixo (entre 1 e 10 segundos).
Estados de uma instância de simulação
Para a garantia de que os grupos de simulação sejam executados de forma consistente, o despachador atribui estados a cada instância de simulação. São eles:
• Pendente: estado seguro da instância de simulação que ainda não foi executada;
• Em execução: estado onde a instância está sendo executada por uma máquina trabalhadora;
• Finalizada: estado onde a instância foi executada com sucesso;
• Cancelada: estado onde o grupo de simulação foi cancelado e por consequência, suas instâncias também foram;
• Inválida: estado de atribuição à instância ocasionado por algum erro considerado irrecuperável pelo sistema.
Atribui-se, por padrão, às instâncias de simulação o estado “Pendente” e a transição dos estados ocorre de acordo com a progressão do processo.
3.3.6 Expedição
Para fins de progresso das simulações, é necessário que o despachador escalone as instân- cias de simulação para as máquinas trabalhadoras, uma vez que elas serão responsáveis pelo processamento dos dados. Esse procedimento é realizado através da expedição em lotes das instâncias, que possui o seguinte funcionamento:
• O despachador avalia a disponibilidade das máquinas trabalhadoras e a compara com o limiar de remanescência de recursos configurado;
• É recuperada na base de dados os registros de instâncias de simulações que estão pendentes de execução, limitando ao número de máquinas trabalhadoras efetiva- mente disponíveis;
• São enviados PDUs de SimulationRequest para as máquinas trabalhadoras de acordo com o número de instâncias de simulação retornadas pelo banco;
• As instâncias escolhidas são marcadas como “Em execução”.
Essa expedição em lotes ocorre a cada intervalo de tempo, em segundos, determinado no arquivo de configurações do despachador.
Prioridade
O sistema despachador possui um mecanismo de diferenciação de grupos de simulações a partir de prioridades, sendo elas (ordenadas de menor para maior grau de prioridade):
• Mínima
• Baixa
• Normal
• Alta
• Urgente
No momento em que o despachador recupera os registros de instâncias de simulação na base, são escolhidas as que participam de grupos de simulação com maior nível de prioridade. A seleção de instâncias de grupos de mesma prioridade são resolvidas seguindo o princípio first come, first served.
Por padrão, todo grupo de simulação possui prioridade normal de execução, cabendo somente a um administrador do sistema a redefinição desse valor.
Carga e semente
Além de prioridade, o despachador visa ser justo entre as instâncias de simulações, ordenando-as ascendentemente por carga e semente. Dessa forma, os algoritmos ava- liados pelo grupo de simulação são executados paralelamente para que desta forma o pesquisador veja rapidamente o comportamento geral das soluções.
Permissão de execução de instâncias de simulação
Existem cenários onde o pesquisador deseja alocar os recursos de máquinas proprietá- rias exclusivamente para seus grupos de simulação. Caso a máquina trabalhadora esteja configurada para tal propósito, instâncias de simulação de outros usuários nunca serão designadas para ela, onde somente serão executadas instâncias provenientes de seu pro- prietário.
3.3.7 Detecção e tolerância a falhas
Na ocorrência de erros durante a execução de uma instância de simulação, o despachador incrementa um contador de saúde da instância e atribui a ela o estado de pendência, para que seja executada em uma nova rodada de expedição em lotes. Caso o contador de saúde atinja o valor cinco, a instância é sinalizada com o estado de “Inválida” e registra-se um log de erro para o usuário. Dessa forma, erros transientes são tolerados e erros contínuos são descartados
Caso os dados de saída da instância estejam em desacordo com as diretrizes de saída da aplicação ONS, a instância é sinalizada pelo estado de “Inválida” e registra-se um log de erro para o usuário. Por se tratar de um erro intrínseco da maneira que o simulador expôs seus resultados, a instância é descartada de imediato pois não cumpriu com o contrato estabelecido pelas diretrizes de saída do simulador ONS.
Se uma máquina trabalhadora que executava instâncias de simulação deixa a rede, todas suas instâncias associadas são marcadas como pendentes.
3.3.8 Agendamento de execução e pausa de máquinas trabalha- doras
Existem cenários onde as máquinas utilizadas para as execuções das simulações poderão ser utilizadas por usuários, e portanto a disponibilidade de recursos da máquina se faz necessária em certos períodos do dia. O despachador fornece ao usuário uma programação de horários os quais as máquinas deverão estar aptas para execução de instâncias de
simulação. Uma vez definido pela interface a faixa de horário de funcionamento das máquinas, o despachador avalia o tempo atual e os compara.
1. Se o horário atual está contido fora da faixa de funcionamento, é enviado um co- mando de pausa para a máquina trabalhadora, e configura-se um temporizador que será acionado novamente ao início da faixa de funcionamento. Quando o tempori- zador é acionado, envia-se um comando de retomada para a máquina.
2. Se o horário atual está contido na faixa de funcionamento, configura-se um tempo- rizador que será acionado imediatamente após o fim da faixa de funcionamento, no qual o procedimento 1 é executado.
Caso a máquina tenha em sua configuração um usuário proprietário, somente aquele usuário terá permissão para esse controle de agendamento; caso contrário, somente admi- nistradores do sistema.
3.3.9 Desempenho das máquinas trabalhadoras
O sistema fornece ao usuário informações sobre o desempenho de processamento das máquinas disponíveis, sendo útil para a avaliação de quais máquinas são melhores ou piores na rede em relação a tempo de execução de instâncias de simulação. Como toda instância de simulação possui informação de data-hora de início e fim, uma vez finalizada por uma máquina trabalhadora, o sistema persiste uma média atualizada de tempo de execução (data-hora de fim - data-hora de início) para aquela simulação. Avalia-se então a proporção de tempo gasto pela máquina para a execução da instância em relação à média da simulação, onde se extrai a razão de velocidade da máquina; essa informação atualiza sua média de desempenho (d), em porcentagem, fazendo uma comparação com um limiar (t), em porcentagem, configurado para o despachador, e categoriza o desempenho da máquina de acordo com os seguintes critérios:
• Rápida:
d≥t
• Mediana:
−t < d < t
• Lenta:
d≤t
Percebe-se que esse parâmetro de velocidade é inferido a partir de comparações com velocidades de processamento outras máquinas que participam ou participaram da mesma rede, não utilizando informações de hardware como critério de avaliação.
3.3.10 Funcionalidades
O sistema disponibiliza uma série de funcionalidades com o propósito de facilitar e me- lhorar os processos do usuário, evidenciando os passos do processo, automatizando pro- cedimentos reiterativos e agrupamento e exposição dos dados relativos ao processamento das simulações.
Notificação por e-mail
O sistema deixa o usuário ciente sobre o progresso de suas simulações, notificando-o quando um grupo de simulação é finalizado ao enviar uma mensagem para o e-mail que o usuário fez seu cadastro, anexando os dados dos resultados do grupo de simulação.
Exportação dos dados
Através da interface WEB, possibilita-se ao usuário, após o término de um grupo de simulação, a exportação dos dados em formatos JSON ou XML, agrupando os resultados das cargas por semente dentro de um diretório denominado pelo nome da simulação.
Gráficos
O sistema provê ao usuário uma área a qual pode-se visualizar graficamente os resul- tados obtidos pelo processamento das simulações (Figura 3.4). Os gráficos são exibidos dinamicamente à medida em que os resultados computados pelas máquinas trabalhadoras são retornados. De acordo com as diretivas de saída da aplicação ONS, o sistema pos- sibilita ao usuário a combinação qualquer dos resultados para a montagem dos eixos do gráfico que deseja-se avaliar. Cabe ao usuário, portanto, o juízo de qualificar a validade da combinação escolhida.
Logs
Como forma de registro de eventos importantes do sistema, é provida uma área de logs de dados que fornecem, por exemplo, o histórico de expedições de instâncias de simulação do usuário, erros, conexões e desconexões de máquinas trabalhadoras e término de instâncias de simulação. A usuários comuns são exibidos somente logs provenientes de seus grupos de simulações e de máquinas trabalhadoras a qual sejam proprietários. Ao administradores, são exibidos todos os registros que não são mostrados a um usuário comum. Possuem níveis de logs que são utilizados para atribuir importância às mensagens, com a seguinte ordem ascendente de relevância
• Trace
Figura 3.4: Exemplo de gráfico gerado pela combinação de dois resultados do simulador (Load v BBR)
• Debug
• Info
• Warn
• Error
• Fatal
3.4 Trabalhador
As máquinas trabalhadoras são unidades de componentes autônomos fracamente acopla- dos de um sistema distribuído que atuam como escravas no paradigma mestre/escravo de programação paralela. São, portanto, responsáveis pelo processamento de instâncias de simulações designadas pelo mestre (despachador).
3.4.1 Conexão com despachador
A fim de estabelecer uma conexão com o despachador, a aplicação da máquina trabalha- dora opera sobre dois mecanismos de vinculação: descoberta dinâmica e conexão direta com endereço configurado.
Descoberta dinâmica
Situações onde o pesquisador deseja montar um sistema despachador em uma rede local, existe a possibilidade de que as máquinas trabalhadoras reconheçam e conectem-se dina-
micamente ao despachador, eliminando qualquer configuração manual da aplicação. Para isso, a máquina trabalhadora submete uma mensagem simples sobre o protocolo UDP, fazendo um broadcast na porta 16180 para todos os dispositivos da rede local, com o ob- jetivo de notificar o despachador. Enquanto uma mensagem de resposta do despachador não é recebida, periodicamente a cada um segundo, a máquina repete o procedimento.
Uma vez que a mensagem é recebida, obtém-se o endereço do despachador na rede local e então estabelece-se uma conexão TCP.
Conexão direta com endereço configurado
Para esse tipo de conexão, é necessário que o usuário defina no arquivo de configuração o endereço do despachador alvo. A aplicação realizará a leitura do arquivo e tentará realizar diretamente uma conexão TCP com o endereço configurado.
3.4.2 Alternância entre mecanismos de conexão
Caso o endereço do despachad esteja configurado, o sistema sempre opta pelo mecanismo de conexão direta. Em caso de falha nos mecanismos de conexão, é feita a alternância entre a conexão direta e a descoberta dinâmica.
3.4.3 Permissão de execução de instâncias de simulação
Caso o usuário deseje que determinada máquina execute apenas instâncias de simulação de seus grupos de simulação, é necessário que o usuário defina no arquivo de configurações o endereço de e-mail com o qual seu usuário foi cadastrado no sistema do despachador.
Dessa forma, a máquina só receberá instâncias provenientes de grupo de simulações do usuário especificado.
3.4.4 Apelido da máquina
Cenários onde pesquisadores são responsáveis pela avaliação de muitas máquinas do sis- tema, por questões de organização, é possível atribuir apelidos às máquinas, onde torna-se mais intuitivo durante a exibição das informações das máquinas pela interface, em contra- partida à leitura do valor de seu IP. Para isso, basta adicionar ao arquivo de configuração o apelido desejado da máquina.
3.4.5 Estados
Uma máquina trabalhadora deve estar definida em um número finito de estados, a qual pode estar somente em um estado por vez, chamado de estado atual. O estado atual da
máquina irá definir as ações que ela poderá executar e as transições são controladas pelo despachador. Os estados exibidos na Figura 3.5 estão descritos abaixo:
Figura 3.5: Máquina de estados de uma máquina trabalhadora
1. Inativo: Estado em que a aplicação não está sendo executada, portanto não possui comunicação alguma com o despachador. O usuário se encarrega de inicializar a aplicação
2. Procurando pelo despachador: Estado em que a aplicação está inicializada, porém não possui comunicação com o despachador. Nesse estado a aplicação tenta inde- finidamente se conectar ao despachador, alternando entre os dois mecanismos de conexão: dez tentativas de se conectar via broadcast UDP, uma vez via endereço de despachador configurado, caso haja um.
3. Em execução: Estado em que a aplicação está executando e possui conectividade com o despachador. Está sujeita aos comandos do despachador, onde a comunica- ção ocorre através do protocolo DWP. A máquina está apta a receber e executar simulações. Caso a conexão com o despachador seja fechada, volta para o estado de procura pelo despachador.
4. Em pausa: Estado em que a aplicação está executando, possui conectividade com o despachador, porém não executa simulações, tipicamente utilizado para poupar os recursos da máquina. Pode retornar à execução caso receba um comando de retomada pelo despachador, comando esse acionado pelo usuário via interface web.
Caso a conexão com o despachador seja fechada, volta para o estado de procura pelo despachador.
3.4.6 Execução de uma instância de simulação
A máquina trabalhadora é submissa ao despachador e, quando em execução, está apta ao recebimento de instâncias de simulação para executá-las. Ao recebimento de um Si- mulationRequest, a máquina disponibiliza uma estrutura organizada temporária para os arquivos e gera um novo processo que realiza a execução da instância a partir das dire- trizes de entrada da aplicação ONS. Ao final do processo, limpa a estrutura temporária, recolhe os dados de saída e analisa se houve erro durante a execução. Envia um Simulati- onResponse ao despachador informando sucesso ou erro e respectivamente o resultado ou a mensagem de erro. Se durante a execução de uma instância de simulação for recebida uma mensagem de término de instância, é forçada a finalização do processo, sem envio dos dados ao despachador.
3.5 Trabalhos Similares
Após uma extensiva busca por trabalhos que se propõem ao mesmo escopo, fornecendo funcionalidades parecidas às desenvolvidas por esse sistema, não foram encontradas apli- cações similares em repositórios públicos ou mesmo artigos que os divulguem. Por esse motivo, não foi possível realizar uma comparação apropriada do sistema desenvolvido com outros gerenciadores de sistemas distribuídos para tarefas de simuladores em redes ópticas.
3.6 Testes e Resultados
Para a realização de testes do trabalho um ambiente simulado contou com um cluster de 15 máquinas com sistema operacional linux, locação de máquinas em nuvem da amazon e google, além de mais de 100 máquinas do Centro Internacional de Métodos Numéricos em Engenharia(Sala INFRO-CIMNE). Inicialmente os servidores WEB e o despachador foram hospedados em uma máquina não tão robusta computacionalmente para os padrões atuais, porém não demonstrou grandes desafios quanto ao processamento logístico do sistema,
demonstrando a capacidade da aplicação de lidar com múltiplas requisições tanto pela interface web, quanto pelo gerenciamento das máquinas trabalhadoras.
Com o auxílio de um pesquisador da área e desenvolvedor do simulador ONS, foram realizadas diversas apurações de como o sistema deveria se comportar e ferramentas que deveria prover para atender aos requisitos dos usuários e diversas iterações foram realiza- das com o objetivo de evoluir a ferramenta adequando-se à proposta inicial estipulada.
A titulo de exemplo, para a metodologia aplicada pelos pesquisadores envolvidos na pesquisa de algoritmos em redes ópticas, a simples configuração do cenário de execução dos simuladores em todas as máquinas, era puramente manual, contando ocasionalmente com o auxílio de scripts. Esse procedimento, segundo relato de um dos pesquisadores, em um determinado cenário, consumia o tempo de aproximadamente três horas e meia devido a configuração do simulador em cada máquina. Com a adoção do sistema de despachamento automático das simulações, o mesmo procedimento passou a consumir questão de poucos minutos. Fatores adversos que ocasionavam em falhas na simulação e consequentemente fazia com que o pesquisador se preocupasse em tratá-las, tornou-se transparente ao pesquisador o modo com que o sistema lidava com isso.
O sistema possibilitou também ao usuário a criação de vários grupos de simulações simultâneos, onde sem o sistema, a mesma prática era inviável, visto que cada máquina suportava um número limitado de simuladores ao mesmo tempo devido ao consumo com- putacional que cada simulação gerava. Com isso o próprio usuário era encarregado de executar os novos grupos de simulação uma vez que os anteriores fossem finalizados.
Em um cenário de teste, um pesquisador pôs em análise três grupos de simulação onde cada um contava com pouco mais que dez simulações, cinco sementes, e dez cargas cada, gerando um total de mais de 3000 instâncias de simulação que consumiam em média meia hora de processamento em uma máquina trabalhadora. No sistema que contava com aproximadamente 100 máquinas trabalhadoras onde havia constante intermitência de conectividade, tornaria bastante oneroso um trabalho puramente manual para gerir todas as simulações. Todas as instâncias foram terminadas em pouco mais de 16 horas de atividade do sistema onde não se fez necessária qualquer intervenção manual do usuário para auxiliar com a continuidade dos processos.
Fatores como tolerância a falhas são parâmetros difíceis de se mensurar. Para tal, foram avaliados os logs do sistema durante uma execução de um grupo de simulações com mais de 1000 instâncias de simulação em um grupo de 50 máquinas trabalhadoras.
Durante toda sua execução, mais de 100 desconexões de máquinas do sistema ocorreram, onde eventualmente retornavam ao sistema. No entanto, o prazo estimado para término do grupo (aproximadamente 10 horas) não pareceu ser bruscamente afetado por esses fatores, conseguindo ser completado em pouco mais de 11 horas.
3.6.1 Interface
Nessa sessão serão apresentadas os resultados obtidos pela implementação da interface gráfica WEB.
Máquinas trabalhadoras
Figura 3.6: Interface das máquinas trabalhadoras
A figura 3.6 representa a interface de usuário que recolhe informações das máquinas trabalhadoras bem como sua interação ao envio de comandos de execução. Seguindo a numeração exposta pela imagem, estão listados seus respectivos significados:
1. Indica o número de máquinas trabalhadoras que estão conectadas ao despachador 2. Exibe o aglomerado de informações sobre todas as máquinas trabalhadoras conecta-
das. Consiste em paineis recolhíveis onde as cores representam o estado da máquina:
amarelado indica o estado parado/pausado; azulado indica o estado em execução 3. Indica informações das máquinas trabalhadoras como quantas instâncias de simula-
ção estão em execução, apelido, performance e IP da máquina 4. Botões de comando à máquina trabalhadora
5. Exibe os medidores de recursos da máquina (memória e processamento em UCP)
Grupos de simulação em execução
A figura 3.7 representa a interface de usuário que exibe as informações dos grupos de simulações em execução do usuário. Seguindo a numeração exposta pela imagem, estão listados seus respectivos significados:
1. Caixa de texto de entrada responsável por filtrar os grupos de simulação a partir de seu nome;
Figura 3.7: Interface dos grupos de simulações em execução
2. Nome do grupo de simulação. Fornece um hiperlink que redireciona para a tela de exibição dos resultados gráficos;
3. Indica o número de instâncias de simulações remanescentes até o término do grupo de simulação. São contabilizadas as instâncias em execução e pendente de execução;
4. Quantidade de sementes daquele grupo de simulações;
5. Data a qual o grupo de simulações foi inicializado;
6. Data a qual estima-se que o grupo de simulações será finalizado;
7. Botão de cancelamento do grupo de simulações.
Grupos de simulação finalizados
A interface de grupos de simulação finalizados assemelha-se à interface exibida pela figura 3.7, onde são mostradas as datas de término e um botão que permite a exportação dos resultados.
Exibição dos gráficos
A figura 3.8 demonstra a possibilidade do usuário de escolha dos eixos de avaliação do comportamento geral das soluções propostas pelo simulador. Vale ressaltar que cabe ao usuário a validade da combinação dos resultados exibidos pelo gráfico. A figura 3.9 demonstra duas combinações de resultados das execuções do simulador ONS.
Figura 3.8: Menu dropdown com a seleção dos possíveis eixos de avaliação
Figura 3.9: Exemplos de dois gráficos gerados pelo sistema
![Referência Técnica para Atuação de Psicólogas(os) em Programas de Medidas Socioeducativas em Meio Aberto [2012] - CREPOP CREPOP](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==)