universidade federal de pernambuco pÓs-graduaÇÃo em ciÊncia da … · graduação em ciência...
TRANSCRIPT
UNIVERSIDADE FEDERAL DE PERNAMBUCO
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
CENTRO DE INFORMÁTICA
GIORGE VANZ
COMPARAÇÃO DE ESTRATÉGIAS PARA GERÊNCIA DE CONFIGURAÇÃO DE
REDES
RECIFE
2016
GIORGE VANZ
COMPARAÇÃO DE ESTRATÉGIAS PARA GERÊNCIA DE CONFIGURAÇÃO DE
REDES
Dissertação apresentada ao Programa de Pós-
Graduação em Ciência da Computação do Centro
de Informática da Universidade Federal de
Pernambuco como requisito parcial para obtenção
do grau de mestre em Ciência da Computação.
Prof. Dr. Carlos André Guimarães Ferraz – Orientador
RECIFE
2016
Catalogação na fonteBibliotecário Jefferson Luiz Alves Nazareno CRB 4-1758
V285c Vanz, Giorge. Comparação de estratégias para gerência de configuração de redes /
Giorge Vanz – 2016. 122f.: quad., tab.
Orientador: Carlos André Guimarães Ferraz. Dissertação (Mestrado profissional) – Universidade Federal de
Pernambuco. CIn. Ciência da Computação, Recife, 2016. Inclui referências e apêndices.
1. Redes de computadores. 2. Gerência de configuração. I. Ferraz, Carlos André Guimarães (Orientador). II. Titulo.
004.65 CDD (22. ed.) UFPE-MEI 2017-006
GIORGE VANZ
COMPARAÇÃO DE ESTRATÉGIAS PARA GERÊNCIA DE CONFIGURAÇÃO DE
REDES
Dissertação apresentada ao Programa de Pós-
Graduação em Ciência da Computação da
Universidade Federal de Pernambuco, como
requisito parcial para obtenção do grau de Mestre,
à banca examinadora formada por:
Aprovado em: 18/11/2016
_________________________________________________
Presidente: Prof. Dr. Daniel Carvalho da Cunha, UFPE
_________________________________________________
Membro: Profa. Dra. Juliana Regueira Basto Diniz, UFRPE
_________________________________________________
Membro: Prof. Dr. Carlos André Guimarães Ferraz, Orientador, UFPE
AGRADECIMENTOS
Agradeço primeiramente ao meu poder superior, Deus, que me deu força e coragem
para completar com ânimo este valioso estágio da minha vida.
Ao meu orientador Prof. Dr. Carlos André Guimarães Ferraz, que me aceitou
como orientando após uma breve conversa mesmo sabendo que eu estaria geograficamente
distante nas próximas reuniões. Pela confiança depositada no meu trabalho e por compartilhar
o seu conhecimento e vivências não somente como professor, mas como pessoa. Seus
ensinamentos foram fundamentais para a construção desse trabalho.
Ao meu Prof. Dr. Alexandre Savaris por estar ao meu lado, desde o início da minha
vida acadêmica, sempre disposto a oferecer todo o apoio necessário para que eu pudesse
conquistar todos os meus objetivos.
Aos meus pais Ademar Jorge Vanz e Rita Pagno Vanz, por terem abdicado e me
blindado de muitas coisas, priorizando o que era importante para mim, fazendo com que eu
conseguisse realizar o meu sonho. Serei grato pelo resto da minha vida a ambos.
Ao Instituto Federal Catarinense (IFC) pelo apoio financeiro para o cumprimento
de todas as etapas do mestrado.
À empresa Teltec Solutions pelo apoio tecnológico no fornecimento do equipamento
para realização dos testes.
Aos membros da banca avaliadora pelas valorosas contribuições oferecidas.
Conceda-nos, Senhor, a serenidade necessária para aceitar as coisas que não
podemos modificar. Coragem para modificar aquelas que podemos, e sabedoria para
distinguir umas das outras.
— REINHOLD NIEBUHR
RESUMO
Atualmente as redes de computadores podem ser encontradas em diversos ambientes,
apresentando escalas de crescimento que comumente não seguem um padrão bem definido,
interligando pessoas, equipamentos e dados. Essas redes integram cenários acadêmicos ou
empresariais, apoiam backbones onde as grandes operadoras estão em constante busca por
desempenho aliado à alta disponibilidade, e estão presentes também nas operadoras de
telecomunicações regionais de pequeno porte, que almejam propiciar a custos acessíveis uma
infraestrutura de acesso à internet com qualidade equivalente à última milha. Diante desses
cenários, na maioria das vezes compostos por equipamentos de interconexão heterogêneos
(por exemplo, roteadores e switches), um grande desafio da gerência de configuração de redes
é encontrar ferramentas computacionais que apoiem o trabalho do administrador de redes. O
presente trabalho compara estratégias com o propósito de superar os problemas da
heterogeneidade de hardware, estabelecendo o mapeamento das tarefas de gerência de
configuração com a utilização das arquiteturas Service Oriented Architecture – Arquitetura
Orientada a Serviço (SOA) e Resource Oriented Architecture – Arquitetura Orientada a
Recurso (ROA) por meio de Web Services – Serviços Web (WS), do protocolo Network
Configuration – Configuração de Rede (NETCONF) e também, através da Command Line
Interface – Interface de Linha de Comando (CLI) disponível no dispositivo gerenciado.
Valendo-se das estratégias estabelecidas, o trabalho procura estabelecer a melhor abordagem
no desenvolvimento de ferramentas direcionadas à configuração de equipamentos
heterogêneos, reduzindo o tempo de resposta e a quantidade de tráfego gerado durante a
alteração de topologias. A experimentação proposta nos mostrou que os melhores resultados
são obtidos por meio de uma abordagem baseada nas estratégias CLI/NETCONF, quando as
ferramentas desenvolvidas são executadas no mesmo segmento da rede de gerência dos
equipamentos de interconexão. Por sua vez, se considerarmos uma solução distribuída,
acessível através da internet com base em dispositivos cliente heterogêneos (por exemplo,
desktops, notebooks e smartphones), a arquitetura ROA é considerada a melhor escolha.
Palavras-chave: Redes de Computadores. Gerência de Configuração. Arquiteturas
Orientadas a Serviços – SOA e Recursos – ROA. NETCONF. CLI.
ABSTRACT
Nowadays, computer networks can be found in a number of environments, presenting
growing scales that usually do not follow a well-established pattern, and encompass links
between people, equipments and data. These networks integrate academic and business
backgrounds, support backbone networks where companies are constantly looking for
performance combined with high availability, and are present in small-sized regional
telecommunication companies, which aim to provide, with affordable costs, an infrastructure
for access to the internet with similar quality to the last mile. Facing these environments,
usually composed by heterogeneous interconnection equipments (e.g. routers and switches), a
big challenge for the management of network configuration is to find computational tools to
support the work of the network manager. This work compares strategies established to
overcome problems from hardware heterogeneity, mapping tasks for configuration
management using Service Oriented Architecture (SOA) and Resource Oriented Architecture
(ROA) through Web Services (WS), the Network Configuration protocol (NETCONF), and
the Command Line Interface (CLI) available on the managed device. Using the established
strategies, the work aims to identify the best approach for the development of tools directed to
the management of heterogeneous equipments, reducing the response time and the amount of
data exchanged during topology changes. The performed experiments achieved the best
results using an approach based on CLI/NETCONF, when the developed computational tools
are executed in the same segment of the management network used by the interconnection
equipments. On the other hand, if a distributed, internet-accessible solution based on
heterogeneous client devices (e.g. desktop computers, notebooks, smartphones) is considered,
a ROA-based approach is the best choice.
Keywords: Computer Networks. Configuration Management. Service Oriented Architecture
– SOA and Resources – ROA. NETCONF. CLI.
LISTA DE ILUSTRAÇÕES
Figura 1 – Síntese da divisão funcional do modelo FCAPS. ................................................... 20
Figura 2 – Formas de conexão para acesso à CLI do dispositivo gerenciado. ......................... 23
Figura 3 – Variabilidade semântica em uma topologia VRRP. ................................................ 24
Figura 4 – Arquitetura em camadas do protocolo NETCONF. ................................................ 28
Figura 5 – Estrutura de um serviço na arquitetura SOA........................................................... 33
Figura 6 – Paradigma e componentes da arquitetura SOA. ...................................................... 36
Figura 7 – Elementos e condições de uma aplicação REST..................................................... 46
Figura 8 – Definição da arquitetura do sistema. ....................................................................... 52
Figura 9 – Diagrama de classes da API CLI. ........................................................................... 61
Figura 10 – Diagrama de classes da API NETCONF. ............................................................. 65
Figura 11 – Diagrama de sequência das aplicações REST e SOAP. ........................................ 71
Figura 12 – Diagrama de sequência da aplicação CLI. ............................................................ 74
Figura 13 – Diagrama de sequência da aplicação NETCONF. ................................................ 76
Figura 14 – Cenário de testes utilizado durante a execução das aplicações e medições. ......... 77
LISTA DE QUADROS
Quadro 1 – Levantamento das tarefas de gerência de configuração de redes. ......................... 54
Quadro 2 – Comandos CLI responsáveis pelas tarefas 1, 2 e 12. ............................................. 55
Quadro 3 – Comandos NETCONF responsáveis pelas tarefas 1, 2 e 12.................................. 55
Quadro 4 – Mapeamento das tarefas dentro de cada estratégia. ............................................... 57
Quadro 5 – Definição do formato de retorno do resultado para cada estratégia. ..................... 58
Quadro 6 – Mapeamento da configuração de interface de rede através da API CLI. .............. 59
Quadro 7 – Conexão com o dispositivo de rede através da API CLI. ...................................... 60
Quadro 8 – Método responsável pela execução dos comandos através da API CLI................ 60
Quadro 9 – Fábrica de conexões da API NETCONF. .............................................................. 62
Quadro 10 – Fábrica de sessões da API NETCONF. ............................................................... 63
Quadro 11 – Método responsável pela execução de comandos através da API NETCONF. .. 63
Quadro 12 – Declaração das constantes utilizadas pela API NETCONF. ............................... 64
Quadro 13 – Tarefas de gerência de configuração transformadas em web services REST. ..... 66
Quadro 14 – WS REST que retorna as configurações de um dispositivo de rede. .................. 67
Quadro 15 – WS REST que configura uma interface de rede. ................................................. 67
Quadro 16 – WS REST que exclui uma entrada na tabela de roteamento estático. ................. 68
Quadro 17 – Tarefas de gerência de configuração transformadas em web services SOAP. .... 69
Quadro 18 – WS SOAP que retorna as configurações de um dispositivo de rede. .................. 70
Quadro 19 – WS SOAP que configura uma interface de rede. ................................................ 70
Quadro 20 – Trecho de código da aplicação CLI. .................................................................... 73
Quadro 21 – Trecho de código da aplicação NETCONF. ........................................................ 75
Quadro 22 – Comandos utilizados para configuração do roteador Cisco 2921. ...................... 79
Quadro 23 – VLANs utilizada no cenário de testes. ................................................................ 80
Quadro 24 – Direções e filtros aplicados para captura de pacotes. .......................................... 84
Quadro 25 – Organização e visualização dos dados coletados ................................................ 86
Quadro 26 – Mensagem XML enviada pelo dispositivo no momento da conexão. ................. 99
Quadro 27 – Mensagem XML enviada pelo cliente para concretizar a conexão. .................... 99
Quadro 28 – Mensagem XML enviada ao dispositivo de rede solicitando a desconexão. .... 100
Quadro 29 – Mensagem XML enviada pelo dispositivo confirmando a desconexão. ........... 100
Quadro 30 – Comandos CLI para as tarefas de gerência de configuração. ............................ 118
Quadro 31 – Comandos NETCONF para as tarefas de gerência de configuração. ................ 119
Quadro 32 – Tarefas de gerência de configuração transformadas em web services REST. ... 121
Quadro 33 – Tarefas de gerência de configuração transformadas em web services SOAP. .. 122
LISTA DE TABELAS
Tabela 1 – Valores médios da quantidade de bytes trafegados durante a execução da tarefa 1.
.................................................................................................................................................. 87
Tabela 2 – Valores médios dos tempos de resposta obtidos para a realização da tarefa 1. ...... 88
Tabela 3 – Valores médios da quantidade de bytes trafegados durante a execução das tarefas 2
e 3. ............................................................................................................................................ 89
Tabela 4 – Valores médios dos tempos de resposta obtidos para a realização das tarefas 2 e 3.
.................................................................................................................................................. 89
Tabela 5 – Valores médios da quantidade de bytes trafegados durante a execução das tarefas
4, 5, 6 e 7. ................................................................................................................................. 90
Tabela 6 – Valores médios dos tempos de resposta obtidos para a realização das tarefas 4, 5, 6
e 7. ............................................................................................................................................ 90
Tabela 7 – Valores médios da quantidade de bytes trafegados durante a execução da tarefa 8.
.................................................................................................................................................. 91
Tabela 8 – Valores médios dos tempos de resposta obtidos para a realização da tarefa 8. ...... 91
Tabela 9 – Valores médios da quantidade de bytes trafegados durante a execução das tarefas 9
e 10. .......................................................................................................................................... 92
Tabela 10 – Valores médios dos tempos de resposta obtidos para a realização das tarefas 9 e
10. ............................................................................................................................................. 93
Tabela 11 – Valores médios da quantidade de bytes trafegados durante a execução da tarefa
11. ............................................................................................................................................. 93
Tabela 12 – Valores médios dos tempos de resposta obtidos para a realização da tarefa 11. .. 94
Tabela 13 – Valores médios da quantidade de bytes trafegados durante a execução das tarefas
12, 13 e 14. ............................................................................................................................... 94
Tabela 14 – Valores médios dos tempos de resposta obtidos para a realização das tarefas 12,
13 e 14. ..................................................................................................................................... 95
Tabela 15 – Agrupamento dos valores médios da quantidade de bytes trafegados de todas as
tarefas........................................................................................................................................ 96
Tabela 16 – Valores médios da quantidade de bytes trafegados durante a conexão utilizando
CLI e NETCONF. .................................................................................................................... 98
Tabela 17 – Valores médios da quantidade de bytes trafegados durante a desconexão
utilizando CLI e NETCONF. ................................................................................................. 100
Tabela 18 – Soma dos valores médios da quantidade de bytes trafegados na conexão e
desconexão para CLI e NETCONF. ....................................................................................... 101
Tabela 19 – Agrupamento dos valores médios dos tempos de resposta obtidos para todas as
tarefas...................................................................................................................................... 102
LISTA DE SIGLAS E ABREVIATURAS
ACL Access Control List – Lista de Controle de Acesso
API Application Programming Interface – Interface de Programação de Aplicativos
BEEP Blocks Extensible Exchange Protocol
CLI Command Line Interface – Interface de Linha de Comando
CORBA Common Object Request Broker Architecture
CPU Central Processing Unit – Unidade de Processamento Central
CRUD Create, Read, Update and Delete – Criar, Ler, Atualizar e Deletar
DCOM Distributed Component Object Model
DMZ Demilitarized Zone – Zona Desmilitarizada
DTD Document Type Definition – Definição de Tipo de Documento
FCAPS Fault, Configuration, Accounting, Performance, Security – Falha,
Configuração, Contabilidade, Desempenho, Segurança
FTP File Transfer Protocol – Protocolo de Transferência de Arquivo
GUI Graphical User Interface – Interface Gráfica do Usuário
HP Hewlett-Packard
HTTP Hypertext Transfer Protocol – Protocolo de Transferência de Hipertexto
HTTPS Hyper Text Transfer Protocol Secure – Protocolo Seguro de Transferência de
Hipertexto
ID Identificador
IDE Integrated Development Environment – Ambiente Integrado de
Desenvolvimento
IETF Internet Engineering Task Force
IFC Instituto Federal Catarinense
IP Internet Protocol – Protocolo de Internet
IPv4 Internet Protocol Version 4 – Protocolo de Internet Versão 4
IPv6 Internet Protocol Version 6 – Protocolo de Internet Versão 6
ISO International Organization for Standardization
ITIL Information Technology Infrastructure Library
ITU-T International Telecommunication Union Telecommunication Standardization
Sector
JDK Java Development Kit
JRE Java Runtime Environment
JSON JavaScript Object Notation – Notação de Objeto Javascript
LMAP Large-Scale Measurement of Broadband Performance
MIB Management Information Base
MTU Maximum Transmission Unit – Unidade Máxima de Transmissão
NETCONF Network Configuration – Configuração de Rede
NOC Network Operations Center – Centro de Operações de Rede
NOS Network Operating System – Sistema Operacional de Rede
NVEs Network Virtualization Environments – Ambientes de Virtualização de Rede
PCAP Packet Capture
QoS Quality of Service – Qualidade de Serviço
REST Representational State Transfer – Transferência de Estado Representacional
RFC Request for Comments
ROA Resource Oriented Architecture – Arquitetura Orientada a Recurso
RPC Remote Procedure Call – Chamada de Procedimento Remoto
SDN Software Defined Networking – Redes Definidas por Software
SFP Small Form-Factor Pluggable
SLA Service Level Agreement – Acordo de Nível de Serviço
SMI Structure of Management Information – Gerenciamento da Estrutura de
Informação
SMING Structure of Management Information, Next Generation – Próxima Geração
para Gerenciamento da Estrutura de Informação
SMTP Simple Mail Transfer Protocol – Protocolo de Transferência de Correio Simples
SOA Service Oriented Architecture – Arquitetura Orientada a Serviço
SOAP Simple Object Access Protocol – Protocolo Simples de Acesso a Objeto
SSH Secure Shell – Shell Seguro
SSH-2 Secure Shell Version 2 – Shell Seguro Versão 2
STI Setor de Tecnologia da Informação
TCP Transmission Control Protocol – Protocolo de Controle de Transmissão
TFTP Trivial File Transfer Protocol
TI Tecnologia da Informação
TLS Transport Layer Security – Segurança da Camada de Transporte
UDDI Universal Description, Discovery and Integration
UDP User Datagram Protocol
VLAN Virtual Lan – Rede Local Virtual
VRRP Virtual Router Redundancy Protocol – Protocolo de Redundância Virtual de
Roteador
URI Uniform Resource Identifier – Identificador Uniforme de Recurso
VNs Virtual Networks – Redes Virtuais
VRs Virtual Routers – Roteadores Virtuais
VTY Virtual Teletype
VPN Virtual Private Network – Rede Virtual Privada
WADL Web Application Description Language – Linguagem de Descrição de
Aplicação Web
WS Web Services – Serviços Web
WSDL Web Services Description Language – Linguagem de Descrição de Serviços
Web
W3C World Wide Web Consortium
XHTML eXtensible Hypertext Markup Language
XML Extensible Markup Language – Linguagem de Marcação Extensível
XPath XML Path Language
10G-PON 10 Gigabit-Passive Optical Network
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................... 10
1.1 MOTIVAÇÃO E JUSTIFICATIVA ........................................................................ 10
1.2 OBJETIVOS DA PESQUISA ................................................................................. 12
1.2.1 Objetivo Geral .......................................................................................................... 12
1.2.2 Objetivos Específicos ............................................................................................... 12
1.3 ESTRUTURA DO TRABALHO............................................................................. 13
2 REVISÃO DA LITERATURA ............................................................................ 15
2.1 GERÊNCIA DE REDES ......................................................................................... 15
2.1.1 Modelo FCAPS ........................................................................................................ 16
2.1.2 Artefatos para Gerência de Configuração ................................................................ 20
2.1.2.1 Simple Network Management Protocol (SNMP) .................................................... 21
2.1.2.2 Command Line Interface (CLI) ............................................................................... 22
2.1.2.3 Network Configuration (NETCONF) ...................................................................... 24
2.2 WEB SERVICES ....................................................................................................... 30
2.3 SOA .......................................................................................................................... 32
2.3.1 Componentes e Paradigma ....................................................................................... 34
2.3.2 Características da Arquitetura .................................................................................. 36
2.3.3 Tecnologias Relacionadas ........................................................................................ 38
2.4 ROA ......................................................................................................................... 39
2.4.1 REST – A Base da Arquitetura ................................................................................ 40
2.4.2 Condições Norteadoras de REST ............................................................................. 42
2.5 TRABALHOS RELACIONADOS ......................................................................... 46
2.5.1 SOA e SOAP ............................................................................................................ 46
2.5.2 ROA e REST ............................................................................................................ 47
2.5.3 NETCONF ............................................................................................................... 48
3 COMPARAÇÃO DAS ESTRATÉGIAS PARA GERÊNCIA DE
CONFIGURAÇÃO DE REDES .......................................................................... 51
3.1 DEFINIÇÃO DA ARQUITETURA DO SISTEMA ............................................... 51
3.2 DEFINIÇÃO DAS TAREFAS DE GERÊNCIA DE CONFIGURAÇÃO .............. 54
3.3 COMPOSIÇÃO DAS ESTRATÉGIAS .................................................................. 56
3.3.1 Mapeamento e Desenvolvimento ............................................................................. 56
3.3.1.1 APIs: implementações intermediárias ...................................................................... 58
3.3.1.2 Estratégia baseada em web services REST e SOAP ................................................ 65
3.3.1.3 Estratégia baseada em CLI e NETCONF ................................................................ 72
3.4 CENÁRIO DE TESTES .......................................................................................... 77
3.4.1 Equipamentos utilizados .......................................................................................... 78
3.4.2 Descrição do cenário ................................................................................................ 80
3.4.3 Definição das métricas e descrição das ferramentas de medição............................. 81
3.4.4 Descrição da coleta .................................................................................................. 83
4 ANÁLISE DOS RESULTADOS ......................................................................... 86
4.1 ORGANIZAÇÃO E VISUALIZAÇÃO DOS DADOS COLETADOS ................. 86
4.2 COMPARAÇÃO DAS ESTRATÉGIAS ................................................................ 87
4.3 DISCUSSÕES .......................................................................................................... 95
5 CONCLUSÕES ................................................................................................... 105
5.1 CONTRIBUIÇÕES DO TRABALHO .................................................................. 106
5.2 DIFICULDADES E LIMITAÇÕES ...................................................................... 107
5.3 TRABALHOS FUTUROS .................................................................................... 109
REFERÊNCIAS .................................................................................................. 111
APÊNDICE A – LISTAGEM DOS COMANDOS CLI .................................. 118
APÊNDICE B – LISTAGEM DOS COMANDOS NETCONF ...................... 119
APÊNDICE C – TAREFAS MAPEADAS EM WS REST ............................. 121
APÊNDICE D – TAREFAS MAPEADAS EM WS SOAP ............................. 122
10
1 INTRODUÇÃO
Neste capítulo são apresentadas as motivações e justificativas que nortearam a
realização deste trabalho. Também são descritos os objetivos geral e específicos seguidos de
uma breve exposição das condições necessárias para o cumprimento dos mesmos. Ao final, o
capítulo é encerrado com uma seção que expõe a estrutura utilizada para construção deste
trabalho.
1.1 MOTIVAÇÃO E JUSTIFICATIVA
À medida que os recursos de rede se tornam indispensáveis, que as aplicações dos
usuários requerem um tempo máximo de resposta a requisições, e que a alta confiabilidade e
disponibilidade se apresentam como fatores críticos ao bom andamento dos trabalhos dentro
das instituições acadêmicas ou empresarias (seja no acesso a sistemas disponíveis em outros
sites, ou mesmo no suporte a projetos de redes de experimentação), o correto gerenciamento
dos equipamentos dispostos nestes ambientes torna-se uma tarefa essencial.
Para auxiliar a administração destes cenários, Hedstrom et al. (2015) propõe que as
tarefas de gerência neste ambiente incidam em duas frentes: na operação, monitorando o
ambiente como um todo durante o seu funcionamento ou falha, e na manutenção, atuando
sobre a configuração de equipamentos mediante a percepção de um comportamento anômalo
previamente identificado pela operação, na instalação e também na alteração de topologias de
rede.
Subdividindo ainda mais o gerenciamento de uma rede de computadores e com o
objetivo de fornecer artefatos específicos para determinadas ações, a International
Telecommunication Union Telecommunication Standardization Sector (ITU-T) e a
International Organization for Standardization (ISO) definiram um modelo funcional
denominado Fault, Configuration, Accounting, Performance, Security – Falha, Configuração,
Contabilidade, Desempenho, Segurança (FCAPS). Esse modelo trata das melhores práticas
definidas dentro dessas cinco áreas funcionais, fazendo com que a divisão de
responsabilidades contribua com a qualidade do serviço prestado pelas áreas responsáveis por
gerenciar os cenários onde, na maioria das vezes, a heterogeneidade de equipamentos e a
11
variabilidade semântica na configuração, com o intuito de garantir a interoperabilidade dos
mesmos, pode se tornar um problema.
Nota-se que a correta configuração da rede é fundamental para a eficácia e a
eficiência das aplicações como um todo, incorrendo que a realização de alterações em
topologias através da configuração de vários dispositivos e a análise do impacto destas
alterações no ambiente são atividades fundamentais (STALLINGS, 2005; TERAMOTO et al.,
2013).
A possibilidade de abstrair as tarefas de gerência de configuração dos dispositivos de
rede através da modelagem e do desenvolvimento de ferramentas distribuídas baseadas em
serviços ou recursos que otimizem o trabalho do administrador pode ser considerada um
ponto fundamental para superar um dos principais desafios que a heterogeneidade de
hardware que este ambiente de larga escala (redes corporativas, acadêmicas ou de
Datacenter) impõe (LU et al., 2008; ANEDDA; ATZORI, 2009). O princípio do
gerenciamento de configuração da rede, que rotineiramente se concentra na centralização
dessas atividades em uma única ferramenta (por facilidade de manutenção e suporte), muitas
vezes não utiliza todo o recurso disponibilizado pelas várias arquiteturas e protocolos que
possibilitam a execução deste trabalho de maneira distribuída ou remota.
Portanto, definir estratégias para contornar os problemas de um ambiente de rede
heterogêneo e comparar o desempenho das tecnologias que ofereçam suporte ao
desenvolvimento de ferramentas amigáveis, que possibilitem a realização da gerência de
configuração de equipamentos de rede durante alterações de topologias, com um menor tempo
de resposta a requisições e um menor tráfego durante as execuções, através da utilização das
arquiteturas Service Oriented Architecture – Arquitetura Orientada a Serviço (SOA) e
Resource Oriented Architecture – Arquitetura Orientada a Recurso (ROA) por meio da
implementação de web services Simple Object Access Protocol1 (SOAP) e Representational
State Transfer2 (REST) (respectivamente), do protocolo NETCONF e também, através da
interação direta com a Command Line Interface3 (CLI) é o maior motivador para o
desenvolvimento do presente trabalho.
Por fim, espera-se que os resultados apresentados por este estudo corroborem a área
funcional da gerência de configuração, definida pelo modelo FCAPS, através da redução dos
1 Protocolo de Acesso Simples a Objetos
2 Transferência de Estado Representacional
3 Interface de Linha de Comando
12
erros de provisionamento e também na diminuição do tempo durante a abertura de janelas de
paradas programadas que objetivam, dentre outras demandas, a alteração de topologias de
rede.
1.2 OBJETIVOS DA PESQUISA
Nesta seção serão descritos os objetivos geral e específicos que se buscam alcançar
por meio deste trabalho.
1.2.1 Objetivo Geral
Este trabalho tem o objetivo de criar e comparar estratégias para execução das
atividades pertinentes à área funcional da gerência de configuração de redes, instituída pelo
modelo Fault, Configuration, Accounting, Performance, Security – Falha, Configuração,
Contabilidade, Desempenho, Segurança (FCAPS).
1.2.2 Objetivos Específicos
Para alcançar o objetivo geral da proposta, os seguintes objetivos específicos foram
determinados:
elencar um conjunto de tarefas de gerência de configuração realizadas
rotineiramente por um administrador de redes;
definir quatro estratégias de gerência de configuração baseadas nas
arquiteturas SOA, ROA, no protocolo NETCONF e na forma de acesso CLI,
através do mapeamento das tarefas elencadas em um conjunto de ferramentas
computacionais;
compor um ambiente de testes que se aproxime ao máximo de uma topologia
de rede real e que possibilite a aderência das ferramentas implementadas;
elaborar e executar um plano de testes através das ferramentas desenvolvidas;
comparar o custo efetivo de cada abordagem através da análise dos resultados
obtidos;
13
identificar as estratégias mais rápidas e menos invasivas – que possibilitem
uma redução do tráfego – durante a execução das tarefas de gerência de
configuração.
Para atingir estes objetivos será necessário o desenvolvimento de uma infraestrutura
de software que possibilite a conexão ao equipamento de rede e a execução de determinado
comando, bem como a obtenção do seu retorno, variando neste ponto a forma como é
apresentado o resultado ao usuário, seja na utilização de web services SOAP, REST para
atender respectivamente aos princípios das arquiteturas SOA e ROA, através de respostas
oriundas do protocolo NETCONF ou das interações por meio da CLI. Com o objetivo de
possibilitar a parametrização e configuração de diversos equipamentos de rede (desde que
estes disponham do suporte mínimo exigido pelas estratégias propostas), essa infraestrutura
deverá possuir um baixo nível de acoplamento. Essa implementação deve ser planejada e
modelada de modo que as estratégias escolhidas se enquadrem às necessidades da gerência de
configuração e possam ser devidamente avaliadas em um cenário que simule um ambiente
real de trabalho.
1.3 ESTRUTURA DO TRABALHO
A organização deste trabalho se dá como segue. Neste primeiro capítulo foi
apresentada a introdução do trabalho com a finalidade de contextualizar o leitor nos temas
abordados por esta dissertação. Ainda neste capítulo são apresentadas as motivações e
justificativas, bem como os objetivos geral e específicos.
O segundo capítulo tem como objetivo apresentar os conceitos de gerenciamento de
redes, o modelo FCAPS e alguns artefatos para a realização da gerência de configuração.
Nesta seção, que trata dos artefatos, são abordadas algumas características do protocolo
Simple Network Management Protocol – Protocolo Simples de Gerenciamento de Redes
(SNMP), da forma de acesso CLI e, como estratégia complementar, do protocolo NETCONF,
que com suas características específicas propõe a criação de padrões. Cabe salientar que todos
os artefatos abordados buscam equalizar as características de utilização da área funcional de
gerência de configuração, área essa que é o foco principal deste trabalho. Ainda neste capítulo
é realizada uma apresentação sobre a tecnologia de web services e suas características,
seguidas das arquiteturas SOA e ROA. Por fim, são descritos trabalhos relacionados,
14
selecionados a partir de uma busca com base em abordagens práticas relativas aos temas
envolvidos.
No capítulo 3 são apresentados os materiais e métodos utilizados no
desenvolvimento da dissertação. Neste capítulo, são apresentadas as estratégias para o
gerenciamento de configuração de equipamentos de rede baseadas nas formas de acesso
expostas nos objetivos específicos. É apresentada também, de forma descritiva e através de
figuras e diagramas, a implementação da solução para a execução automatizada das tarefas de
gerência de configuração. Dando sequência à estrutura do capítulo, foram elencadas as tarefas
comumente executadas pelos administradores de rede na área funcional do modelo FCAPS da
gerência de configuração de equipamentos. Posterior à definição das tarefas, foi realizado o
mapeamento dessas por meio das ferramentas desenvolvidas onde, ao final, este mapeamento
se concretizou através da disponibilização de métodos, serviços ou recursos, dependendo da
estratégia abordada. Ainda neste capítulo, foram definidos os equipamentos utilizados para a
criação de um cenário de rede que serviu de base para a instalação das ferramentas
computacionais implementadas, simulando assim um ambiente de produção. Com o ambiente
finalizado e as ferramentas configuradas foram executados os testes para cada estratégia e
tarefas. A última seção do capítulo 3 apresenta uma descrição de como foi realizada a coleta
desses dados.
O capítulo 4 apresenta uma combinação dos resultados obtidos ao término da
execução dos testes. Neste capítulo é apresentado como os dados foram organizados e, em
seguida, são realizadas as comparações e discussões, por meio da exibição de tabelas, sobre os
resultados alcançados. Este capítulo é encerrado com uma discussão adicional e abrangente
que trata da realização de uma inspeção mais profunda, seguida de uma análise diante do
comportamento de cada estratégia.
Ao final, no capítulo 5, a dissertação é encerrada com a apresentação das conclusões,
contribuições, dificuldades, limitações e também das sugestões de possíveis trabalhos futuros.
15
2 REVISÃO DA LITERATURA
Neste capítulo serão apresentados os aspectos teóricos a serem utilizados com a
finalidade de orientar a pesquisa, dando suporte à implementação das estratégias para gerência
de configuração de dispositivos de redes e, por conseguinte, ao alcance dos objetivos
apresentados pelo trabalho.
2.1 GERÊNCIA DE REDES
A complexidade de uma rede de computadores é derivada do hardware de
interconexão (switches, roteadores e access points) em que ela se apoia, em conjunto a uma
série de protocolos, softwares e servidores que executam o processamento ou armazenamento
de dados que serão entregues aos dispositivos finais de usuários ou instituições. Esses
elementos formam uma estrutura que demanda acompanhamento, de forma que a
comunicação entre os dispositivos de hardware e os componentes de software flua de maneira
que as operações realizadas sejam estáveis e que as respostas sejam condizentes com as
requisições – sem falhas e em um tempo aceitável. Para alcançar esse nível de qualidade é
necessário gerenciar o ambiente onde esses componentes de hardware e software estão
inseridos.
Segundo Hedstrom et al. (2015) a gerência de redes pode ser composta por dois
cenários de atuação bem definidos:
operação – abrange o monitoramento do ambiente como um todo, incluindo a
detecção de falhas e a disponibilização de alertas à administração da rede.
Decisões sobre intervenção são tomadas a partir do resultado da coleta de dados
estatísticos de desempenho ou de indicadores de utilização do usuário final para
efeitos de posterior cobrança. Prevê também a atuação em áreas que cercam a
segurança da rede mantendo o sistema confiável;
manutenção – engloba as rotinas de verificação e atualização de equipamentos.
Aborda as falhas executando correções necessárias e garante a execução de rotinas
de backup e restauração de equipamentos ou configurações. Com o intuito de
atender a demandas oriundas da implantação de políticas ou alterações de
topologias de rede, atua na ativação de novos recursos ou reconfiguração de
equipamentos.
16
Com a junção desses dois cenários, define-se o gerenciamento de rede como a
capacidade de sistematizar os processos de acompanhamento durante o funcionamento ou em
momentos de falha dos componentes de hardware que compõem o ambiente (KUROSE;
ROSS, 2010). A utilização de ferramentas computacionais visa dar suporte ao fluxo de
trabalho do gerenciamento de redes, dividindo as tarefas em três eixos principais. O primeiro
eixo é responsável pelo monitoramento, sendo caracterizado pela obtenção dos dados brutos
do ambiente gerenciado (configurações ou dados de desempenho). O segundo eixo, por sua
vez, visa o processo de análise baseado na interpretação dos dados coletados. Por fim, no
terceiro eixo tem-se a fase de ação – onde são realizadas as operações reativas frente a
eventos de falha, reconfigurações ou otimizações (GUIMARAES et al., 2016).
Objetivando estabelecer estratégias para realizar o gerenciamento dos equipamentos
de interconexão, é apresentado a seguir um modelo de gerenciamento que será utilizado como
guia para o presente trabalho. O modelo é complementado pela descrição de formas de
acesso, arquiteturas e protocolos que serão empregados na construção de componentes de
software para auxiliar na gerência de configuração de redes.
2.1.1 Modelo FCAPS
Oferecer suporte e acompanhar o rápido desenvolvimento de uma rede de
computadores (de backbone, acadêmica ou empresarial) para que a mesma sirva como
instrumento primário de conexão entre dispositivos heterogêneos, transportando dados com a
máxima disponibilidade, é um dos principais objetivos que norteiam o desenvolvimento de
rotinas de controle dos dispositivos (roteadores, switches, access points, dentre outros) que
compõem este ambiente de múltiplas conexões.
Para atingir este objetivo (que envolve uma série de tarefas complexas) e que, sem a
definição de um plano poderia causar certa confusão, a International Telecommunication
Union Telecommunication Standardization Sector (ITU-T) e a International Organization for
Standardization (ISO) instituíram um modelo funcional de gerenciamento de redes através da
criação de cinco áreas funcionais (JACOBS, 2014; WEISS; SOLOMON, 2015). Esse modelo,
denominado FCAPS, é um acrônimo para Fault, Configuration, Accounting, Performance
and Security, e abrange respectivamente as áreas de gerenciamento de falhas, configuração,
contabilização, desempenho e segurança (INTERNATIONAL TELECOMMUNICATION
UNION, 2000).
17
O detalhamento das cinco áreas funcionais de gerenciamento do modelo FCAPS é
apresentado a seguir.
Fault (falha) – executa uma série de ações que incidem na localização,
isolamento e reparação/substituição de componentes que apresentem um
comportamento anômalo dentro de um ambiente de rede, afetando negativamente
o tempo de atividade, implicando em um baixo desempenho e degradação do
serviço. O gerenciamento de falhas deve seguir o problema até a sua resolução
(SINH et al., 2015), e pode ser dividido em dois subsistemas (BOUTABA;
POLYRAKIS, 2001; FOROUZAN, 2010):
reativo – subsistema responsável pela detecção, isolamento, correção e
documentação de falhas em curto prazo;
proativo – subsistema que tenta prever e prevenir comportamentos anômalos
da rede.
Configuration (configuração) – define os parâmetros de funcionamento dos
dispositivos de rede através da alteração de sua configuração inicial para o
atendimento a mudanças de topologia ou o estabelecimento de critérios mais
rigorosos de Quality of Service – Qualidade de Serviço (QoS) ou Service Level
Agreement – Acordo de Nível de Serviço (SLA) em uma porção da rede ou
serviço em particular (BOUTABA; POLYRAKIS, 2001). Para Goyal, Mikkilineni
e Ganti (2009) a gerência de configuração envolve tarefas complexas, sendo que a
falha ou o atraso na realização dessas atividades pode gerar um impacto negativo
sobre os serviços disponibilizados pela TI e que fazem o uso da rede como meio
para troca de informações. Cabe também a esta área funcional a coleta dos dados
de configuração de dispositivos com a finalidade de propiciar um funcionamento
contínuo ou preparar-se para a inicialização e o encerramento de serviços de
interconexão de maneira correta (GOROD; SAUSER; BOARDMAN, 2008). Para
Dooley e Rooney (2013) e Hedstrom et al. (2015) outra funcionalidade da
gerência de configuração é a realização do backup/restore das informações de
dispositivos de interconexão de rede, que aliado à correta configuração dos
mesmos contribui na redução de erros de provisionamento e na diminuição do
intervalo de tempo durante a abertura das janelas de paradas programadas que
18
objetivam a alteração de topologias de rede. A gerência de configuração pode ser
organizada em duas vertentes, descritas como segue (FOROUZAN, 2010):
reconfiguração – abrange as alterações de hardware, sejam elas na
realocação física de equipamentos ou na alteração de sua configuração para
atendimento a mudanças de topologia;
documentação – especifica o registro de cada mudança física ou de
configuração no/dos dispositivos de rede. Este registro pode ser realizado
através de diagramas que apresentem a localização física em uma planta,
possibilitando também o apontamento lógico das configurações agregadas a
cada equipamento dentro do cenário de rede administrado. Cabe também a
esta vertente as especificações de cada dispositivo de interconexão, tais como
marca, modelo e número de série.
Accounting (contabilização) – objetiva a tarifação dos dispositivos de rede
baseada na sua utilização (largura de banda, uso da Central Processing Unit –
Unidade de Processamento Central (CPU), memória ou até mesmo as prioridades
em agendamentos durante a execução de computação em supercomputadores)
(ANDRZEJ, 2012). A gerência de contabilização trabalha na coleta, na análise e
no agrupamento de métricas para entender o comportamento de um usuário ou
grupo de usuários dentro de um determinado segmento da rede, com o propósito
de estabelecer cotas individuais ou coletivas na utilização de recursos (DOOLEY;
ROONEY, 2013). Cabe salientar que os mesmos indicadores utilizados para
tarifação da utilização podem ser aplicados no atendimento a demandas que
envolvem processos de auditoria.
Performance (desempenho) – caracteriza-se pelo reconhecimento dos limites da
comunicação de dados entre componentes, com o objetivo de estabelecer
parâmetros de qualidade e oferecer a possibilidade de predição de comportamento
ao administrador da rede. Este segmento da gerência de redes está fortemente
relacionado com as técnicas de controle de tráfego como, por exemplo, traffic
shaping (BOUTABA; POLYRAKIS, 2001). Para mensurar o desempenho de uma
rede Forouzan (2010) e SINH et al. (2015) estabelecem que esta área funcional
necessita fazer o uso de quantidades mensuráveis (estatísticas de rede) como taxa
de erro, capacidade, tráfego, throughput ou tempo de resposta. Similar à divisão
19
citada por Hedstrom et al. (2015) para a gerência de redes no início da seção 2.1,
Stallings (2005) expõe que a área de desempenho também pode ser subdividida
em duas categorias funcionais, como segue:
monitoramento – categoria que busca acompanhar o funcionamento da rede
e coletar informações para medição, com o intuito de escrutinar o
comportamento da rede como um todo;
controle – função que se apoia nas métricas coletadas pelo monitoramento da
rede. A principal característica do controle é possibilitar ao gerenciamento de
desempenho a realização dos ajustes necessários para proporcionar níveis
elevados de qualidade na comunicação entre dispositivos.
Security (segurança) – concentra-se no controle, na auditoria de acesso a redes de
computadores e no apoio à aplicação de políticas de segurança (GOROD;
SAUSER; BOARDMAN, 2008; GOYAL; MIKKILINENI; GANTI, 2009). Esta
área funcional absorve também os procedimentos de segurança necessários para
evitar que os equipamentos, responsáveis pelo armazenamento ou tráfego de
dados, venham a sofrer ataques que objetivam a degradação do desempenho,
sobrecarregando, reconfigurando ou causando mau funcionamento do sistema
como um todo. É atribuição da gerência de segurança o suporte e reação frente ao
comportamento às vezes inusitado do usuário, protegendo as informações contra
danos involuntários (BOUTABA; POLYRAKIS, 2001).
Percebe-se que, através da divisão exposta, é possível controlar todos os segmentos
de uma rede garantindo a disponibilidade e a integridade da mesma, desde que seguidas as
condições e requisitos únicos de cada área e dos dispositivos de interconexão que são
utilizados para o tráfego das informações entre pessoas ou instituições (HEDSTROM et al.,
2015).
Com o objetivo de elucidar os conceitos previamente apresentados, a figura 1 exibe a
divisão do modelo funcional FCAPS sucedida de uma síntese com as principais
características, ações e formas para cada área.
20
Figura 1 – Síntese da divisão funcional do modelo FCAPS.
Fonte: Estrutura da figura baseada em Forouzan (2010) e síntese elaborada pelo autor.
Doravante neste trabalho e com o objetivo de delimitar o escopo da pesquisa, quando
citado o modelo FCAPS, a área funcional de gerência de configuração será abordada com
destaque.
2.1.2 Artefatos para Gerência de Configuração
Os administradores de rede, durante configurações para o atendimento às tarefas que
visam a manutenção ou provisionamento de novos serviços, instalação, realocação física de
equipamentos ou pontos de rede, fazem uso de algum tipo de software. Procedimentos
simples como a alteração de uma topologia de rede frente à necessidade de mudança de um
setor que dispõe de uma Virtual Lan – Rede Local Virtual (VLAN) específica para outro
local, pode envolver a configuração de um ou vários equipamentos dependendo do alcance da
topologia e do que se utiliza na rede.
Em redes corporativas, a homogeneidade dos equipamentos de interconexão não é
uma premissa que possa ser tratada como verdadeira. Diante desse cenário, e da necessidade
de configuração de dispositivos de rede dentro de um ambiente heterogêneo, vários esforços
têm sido empregados para contornar o problema que a variabilidade da rede apresenta
21
(causada pelo fato de que diferentes fornecedores de equipamentos dispõem de variadas
funcionalidades, interfaces e modelos de programação e customização para seus dispositivos)
(WONG et al., 2005).
Esforços têm sido feitos para organizar este ambiente que é composto de
componentes de hardware não uniformes e que, na maioria das vezes, demanda
interoperabilidade. O gerenciamento de configuração destes dispositivos pode acontecer
através de protocolos ou meios específicos como SNMP, CLI, Network Configuration –
Configuração de Rede (NETCONF) por meio da linguagem de modelagem YANG, métodos
proprietários ou Application Programming Interface – Interface de Programação de
Aplicativos (API) que, por sua vez, podem emular chamadas de configurações e apresentar ao
usuário uma Graphical User Interface – Interface Gráfica do Usuário (GUI) web amigável,
utilizando-se de tecnologias como Extensible Markup Language – Linguagem de Marcação
Extensível (XML), Representational State Transfer – Transferência de Estado
Representacional (REST) ou JavaScript Object Notation – Notação de Objeto Javascript
(JSON) (STADLER, 2013; HEDSTROM et al., 2015).
2.1.2.1 Simple Network Management Protocol (SNMP)
Segundo Xu e Xiao (2006), o protocolo SNMP tem sido amplamente utilizado no
monitoramento de falhas e desempenho; entretanto, quase não é utilizado para o
gerenciamento de configuração. A razão do não uso reside no fato de o referido protocolo
apresentar limitações de aplicação no contexto de grandes redes. Essas limitações são
diretamente relacionadas à representação de dados que retratam a configuração dos
dispositivos de rede por meio de Structure of Management Information – Gerenciamento da
Estrutura de Informação (SMI) ou Structure of Management Information, Next Generation –
Próxima Geração para Gerenciamento da Estrutura de Informação (SMIng), que é a
linguagem de definição de dados que visa fornecer uma representação independente de
protocolo. Outra razão pela qual o protocolo SNMP é pouco utilizado para gerência de
configuração é não trabalhar bem com grandes transferências de dados por meio de operações
snmpgetbulk, bem como a densidade do protocolo que cresce em paralelo junto à
complexidade de configuração dos dispositivos através de operações get e set (Hedstrom et
al., 2015; Santos, P. R., Esteves e Granville, 2015). Essa densidade é observada através da
22
utilização excessiva de parâmetros durante as operações de configuração e recuperação de
informações do dispositivo alvo.
O fato do protocolo SNMP utilizar User Datagram Protocol (UDP) como protocolo
de transporte entre agentes gerenciadores e componentes gerenciados pode ser tratado como
um problema durante a gerência de configuração. O não estabelecimento de uma conexão,
característica intrínseca do protocolo UDP entre os pares, faz com que sua utilização seja tida
como não confiável e, com o objetivo de contornar esse problema, cabe à aplicação executar o
tratamento de erros que venham a acontecer até na camada de transporte, realizando as
retransmissões necessárias (DOUGLAS; KEVIN, 2005; LOUREIRO; GONÇALVES;
NOGUEIRA, 2012).
Cabe ressaltar, porém, que o SNMP agregado ao UDP foi um protocolo
desenvolvido para ser utilizado em redes instáveis, ponto de encontro das áreas funcionais da
gerência de falhas e desempenho citadas acima e, frente a um cenário problemático, nada
mais justo que evitar a inundação de retransmissões do Transmission Control Protocol –
Protocolo de Controle de Transmissão (TCP) que busca o retorno da confiabilidade perdida.
Portanto, frente às dificuldades apresentadas pelo protocolo SNMP, gerenciar um ambiente
instável através de um padrão que se utiliza de mecanismos que não transmitam confiança
durante a comunicação pode fazer com que a gerência de configuração seja alvo comum das
áreas de gerência de falha e desempenho (YU; AJARMEH, 2010).
2.1.2.2 Command Line Interface (CLI)
Outra forma de realizar a gerência de configuração é através da CLI. Para Guimarães
et al. (2016) os administradores de rede estão familiarizados e rotineiramente utilizam de
ferramentas tradicionais para executar a gerência de configuração, sendo que muitas dessas
ferramentas baseiam-se em CLI. Essa utilização se firma na elasticidade da personalização de
uso através dos inúmeros comandos e parametrização pré-estabelecidas (FILIPPETTI, 2011).
A CLI continua sendo a base para o provisionamento de novas funcionalidades e,
quanto mais complexas se tornam as tarefas do administrador de rede, mais provável é que
elas sejam provisionadas de maneira mais manual do que automática. Outra característica, já
citada anteriormente, remete aos desafios que a interoperabilidade semântica apresenta na
configuração de dispositivos heterogêneos. Contudo, a popularidade da CLI é balizada na sua
eficiência de uso, bem como na capacidade de comunicação direta com o dispositivo. Um
23
exemplo clássico de CLI é o UNIX CLI para bourne shell (programas sh em sistemas
operacionais UNIX). Usualmente administradores de rede utilizam a CLI de sistemas UNIX
como ponto de partida para realizar a conexão em dispositivos de interconexão de rede
através de protocolos que estabelecem sessões Virtual Teletype (VTY) TELNET, Secure Shell
(SSH) ou Trivial File Transfer Protocol (TFTP) (ODOM, 2008; HEDSTROM et al., 2015).
As formas de conexão SSH, TELNET e também através de uma interface auxiliar
para acesso à CLI de um dispositivo de rede são apresentadas na figura 2.
Figura 2 – Formas de conexão para acesso à CLI do dispositivo gerenciado.
Fonte: Elaborada pelo autor.
Pode-se notar a variabilidade semântica na configuração de dispositivos de rede
diante da necessidade de interoperabilidade entre estes equipamentos durante a utilização, por
exemplo, do Virtual Router Redundancy Protocol – Protocolo de Redundância de Roteador
Virtual (VRRP). O VRRP adiciona redundância e aumenta a disponibilidade da rede,
possibilitando que dois ou mais roteadores compartilhem um único endereço Internet
Protocol – Protocolo de Internet (IP) virtual. Um dos roteadores trabalha como dispositivo
mestre enquanto os outros atuam como backup: se o equipamento mestre falhar, ou se o link
configurado nas interfaces com o endereço IP virtual falhar, um dos roteadores de backup
assume como mestre da topologia (NADAS, 2010).
Para que o protocolo VRRP funcione conforme o padrão estabelecido por sua
Request for Comments (RFC), as interfaces que interligam os equipamentos assumem
endereços únicos; porém, essas interfaces compartilham de um único IP virtual. Com o
objetivo de exemplificar a configuração do protocolo VRRP, a figura 3 apresenta uma
topologia de rede Internet Protocol Version 4 – Protocolo de Internet Versão 4 (IPv4) onde os
comandos são executados por meio da CLI. Percebe-se na figura a diferença entre comandos
que essencialmente executam a mesma função, porém em equipamentos de marcas diferentes.
24
Figura 3 – Variabilidade semântica em uma topologia VRRP.
Fonte: Topologia baseada em Nadas (2010) e configurações CLI elaboradas pelo autor.
2.1.2.3 Network Configuration (NETCONF)
Diferente da CLI, onde cada fornecedor (não se preocupando com padronização)
especifica uma série de parâmetros para realizar a gerência de configuração de cada
dispositivo de rede, a Internet Engineering Task Force (IETF) propôs a criação de um
protocolo através da RFC 6241 (ENNS et al., 2011), que visa fornecer novos mecanismos
padronizados para contornar a abordagem complexa e dependente da CLI, que muitas vezes
dificulta a interoperabilidade de equipamentos durante as atividades de criação de topologias
mais complexas.
O protocolo NETCONF é utilizado para o gerenciamento de rede através de métodos
para instalar, manipular e excluir configurações de dispositivos de rede utilizando-se de uma
codificação baseada em XML para as mensagens de protocolo e também de configuração
(SEHGAL et al., 2012; NARISETTY et al., 2013). Sua utilização, por meio de algumas
características específicas, possibilita a automatização do gerenciamento em ambientes
complexos (quantidade e heterogeneidade de equipamentos) proporcionando maior segurança
e confiabilidade durante as alterações das topologias de rede desses cenários (LOUREIRO;
GONÇALVES; NOGUEIRA, 2012). Yu e Ajarmeh (2010) comentam, ainda na fase draft
(rascunho) do protocolo na IETF, que sua utilização será um passo importante para a criação
de sistemas de gerenciamento de redes baseados em XML, e que através de NETCONF são
25
definidas as operações para gerenciar dispositivos de rede onde os dados de configuração
podem ser enviados, recuperados ou manipulados de forma parcial ou na sua totalidade.
NETCONF utiliza o paradigma cliente/servidor e tem por base a uniformidade na
representação dos dados (ELBADAWI; YU, 2011). Neste cenário, um servidor é um
dispositivo de rede (por exemplo, um roteador) e o cliente pode ser uma aplicação que acessa
o roteador para executar determinadas operações por meio do referido protocolo. Esse
protocolo tem como requisito principal a estratégia de que suas operações devem ser
orientadas à conexão, provendo um meio de comunicação entre cliente/servidor confiável,
devendo atender a alguns requisitos básicos como: entrega garantida e na sequência de
mensagens, autenticação, integridade e confidencialidade – características essas estabelecidas
pela camada de transporte (ENNS et al., 2011).
O projeto do protocolo NETCONF baseia-se em uma arquitetura modular composta
de quatro camadas que desempenham funções únicas e bem definidas (TAVARES;
GONÇALVES; OLIVEIRA, 2011; HALLÉ, CHERKAOUI; VALTCHEV, 2012; KREJCI,
2013; STEINMETZ, 2015):
camada de transporte – é a primeira camada, em uma visão bottom-up, que
define um canal de comunicação seguro entre cliente e servidor para troca de
mensagens necessárias à execução de procedimentos remotos. O NETCONF pode
ser utilizado sobre qualquer protocolo de transporte desde que atenda aos
requisitos expostos anteriormente. Dentre os possíveis protocolos a serem
utilizados podemos relacionar o SSH, Transport Layer Security – Segurança da
Camada de Transporte (TLS), Blocks Extensible Exchange Protocol (BEEP)/TLS,
SOAP/HTTP/TLS. Cabe salientar que segundo a RFC 6242 (WASSERMAN,
2011) o NETCONF deve apoiar-se no SSH como protocolo para a camada de
transporte;
camada de mensagem – o modelo de comunicação utilizado entre cliente e
servidor é baseado no paradigma Remote Procedure Call – Chamada de
Procedimento Remoto (RPC), onde um cliente codifica uma requisição RPC
(<rpc>) em XML e a envia para um servidor com um atributo de identificação
obrigatório (message-id). Baseado na requisição do cliente, o servidor envia uma
resposta RPC (<rpc-reply>) também codificada em XML. Cabe salientar que o
sucesso na execução de uma mensagem (<ok>), bem como a falha da mesma
26
(<rpc-error>) e seus subelementos (<error-type>, <error-info>, dentre outros),
também são tratados através de uma resposta RPC com elementos específicos.
Ambos os pares envolvidos na conexão compreendem a sintaxe XML descrita
durante a troca de mensagens, pois a mesma pode ser definida em um arquivo
Document Type Definition – Definição de Tipo de Documento (DTD) ou schema
XML;
camada de operações – esta camada é composta por um conjunto básico de
operações utilizadas para a realização do gerenciamento de configuração. A tarefa
definida por esta camada é a de oferecer métodos para recuperar, configurar,
copiar e excluir parâmetros em dispositivos de rede, com o objetivo de alterar o
seu status atual. Também são descritas como operações básicas as funcionalidades
de bloqueio e desbloqueio que permitem acesso exclusivo em um determinado
momento aos parâmetros de configuração;
camada de conteúdo – também pode ser definida como a camada de dados que
estabelece os parâmetros de configuração de cada dispositivo. Pelo fato de
existirem inúmeros retornos a parâmetros, esta camada torna-se independente do
protocolo NETCONF.
A camada de conteúdo do NETCONF é desprendida de padrões, e cada fornecedor
pode defini-la utilizando-se de suas próprias especificações. Contudo, para equacionar essa
independência de tecnologia a IETF propôs, através da RFC 6020 (BJORKLUND, 2010),
uma linguagem para descrever as informações das tarefas de gerenciamento de rede. YANG é
uma linguagem de modelagem de dados extensível e utilizada pelo protocolo NETCONF para
definir uma árvore hierárquica de dados utilizados nas mensagens RPC de configuração,
operação e notificação, permitindo uma descrição completa entre cliente e servidor. As
informações são divididas em módulos de forma que cada módulo define uma validação
sintática e semântica de fácil entendimento (GOLLING et al., 2014; MEDVED et al., 2014;
SASSI et al., 2014; AKHTAR, 2015).
Para Bajpai e Schönwälder (2014) o protocolo NETCONF e a possibilidade de
utilização de uma linguagem de modelagem de dados como YANG formam a base de uma
nova estrutura de gerenciamento de rede, aumentando a capacidade de interoperabilidade de
dispositivos.
27
O protocolo NETCONF suporta várias formas de configuração, as quais devem ser
anunciadas através de elementos específicos (<capabilities>) pelo dispositivo durante a
primeira troca de mensagens e identificadas através de Uniform Resource Identifier –
Identificador Uniforme de Recurso (URI). Quando uma sessão é aberta entre os pares, o
servidor envia um elemento <hello>, incluindo um identificador de sessão (<session-id>)
seguido de sua lista de recursos disponíveis (<capabilities>). Para concretizar essa sessão
NETCONF o cliente deve, impreterivelmente, responder ao servidor com outra mensagem
contendo o elemento <hello> e os recursos que deseja dispor durante as tarefas de
configuração. Caso não seja respeitada a sequência e a estrutura da mensagem a sessão é
encerrada automaticamente pelo servidor. As capacidades adicionais, utilizadas para estender
o protocolo, são apresentadas a seguir (TAVARES; GONÇALVES; OLIVEIRA, 2011;
KREJCI, 2013):
writable-running – representa a alteração da configuração em um dispositivo que
está em execução, onde as modificações realizadas nesse modo afetam o sistema
em produção;
candidate-configuration – indica que um dispositivo suporta o armazenamento de
dados de configuração que podem ser manipulados sem afetar a configuração
atual (em execução). Através de uma operação de commit a configuração marcada
como candidata poderá entrar em execução;
confirmed-commit – permite que uma alteração seja revertida caso não seja
realizada em um limite de tempo pré-definido;
rollback-on-error – capacidade que permite ao servidor voltar ao estado anterior
em caso de erro;
validate – oferece a capacidade de validação das configurações antes da sua
execução;
distinct-startup – possibilita que as operações realizadas em modo writable-
running não surtam efeito caso o dispositivo seja reiniciado;
URL – capacidade que permite aos dispositivos a exposição de características
adicionais através de URLs com o argumento esquemas (http, ftp, file);
XPath – permite que os pares utilizem expressões XML Path Language (XPath)
dentro dos elementos <filter>.
28
Outra característica de NETCONF é que, através de mensagens assíncronas
(notificações), o protocolo possibilita que o cliente, mediante uma espécie de assinatura por
meio do elemento <create-subscription> enviado na mensagem, receba anúncios que o
alertam da ocorrência de algum evento através do elemento <notification> na resposta do
servidor (KREJCI, 2013).
A arquitetura do protocolo NETCONF, bem como alguns exemplos utilizados em
cada camada, é detalhada na figura 4.
Figura 4 – Arquitetura em camadas do protocolo NETCONF.
Fonte: Elaborada pelo autor com base em Tavares, Gonçalves e Oliveira (2011) e Krejci (2013).
Fundamentando-se na união do protocolo NETCONF com princípios de REST,
apresentados na seção 2.4.1, um novo protocolo para gerência de redes denominado
RESTCONF (BIERMAN; BJORKLUND; WATSEN, 2016) está em fase de desenvolvimento
pela IETF. O protocolo pode ser descrito como a busca pela simplificação do protocolo
NETCONF, utilizando-se dos mecanismos do Hyper Text Transfer Protocol Secure –
Protocolo Seguro de Transferência de Hipertexto (HTTPS) para acesso aos dados, através da
linguagem YANG, de equipamentos com suporte a NETCONF (VILALTA et al., 2015).
O protocolo RESTCONF pode ser descrito em um quadro composto de quatro
modelos (PRIETO; LEUNG; ROCKWELL, 2015):
modelo de recurso – em REST um recurso é, informalmente, qualquer
informação que pode ser nomeada e posteriormente acessada. No contexto de
29
RESTCONF um recurso apresenta os elementos gerenciáveis de cada
equipamento;
modelo de mensagem – cada mensagem do protocolo realiza uma única operação
em um único recurso; logo, para cada tarefa da gerência de configuração deve ser
realizada uma operação HTTP;
modelo de datastore (armazenamento de dados) – os dados são armazenados
conceitualmente em um único local, sendo esse a união das configurações de
execução e do estado operacional do dispositivo;
modelo de conteúdo – o conteúdo é estabelecido através da linguagem YANG e
disponibilizado por meio de um URI.
As operações RESTCONF são definidas pela interface uniforme fornecida por REST
e codificadas em HTTP. Cada operação inclui o método HTTP e um URI, que identifica o
recurso de destino através de um nó de dados YANG. As operações de leitura a recursos
(aquisição da configuração ou estado operacional de um equipamento) são alcançadas através
do método GET; já as operações que alteram as configurações atuais do equipamento são
definidas por meio dos métodos DELETE, PATCH, POST e PUT. Essas operações podem ser
refinadas valendo-se de parâmetros de consulta inseridos diretamente na URI ou em dados
enviados no cabeçalho do protocolo HTTP.
A utilização do protocolo RESTCONF não tem como objetivo tornar-se uma
substituta do NETCONF, mas sim procura fornecer um meio adicional de acesso, através de
HTTPS, para o gerenciamento de dispositivos de rede. Valendo-se de métodos e protocolos
largamente utilizados, o que induz a sua facilidade nos quesitos que tangem a
interoperabilidade, vem chamando a atenção de controladores Software Defined Networking –
Redes Definidas por Software (SDN), como OpenDayligth (OpenDaylight Platform, 2016),
que inclui um cliente RESTCONF para gerenciamento de sua Northbound Interface (interface
norte), responsável pela comunicação entre o plano de gerenciamento que contém as
aplicações de rede e o plano de controle que contém o Network Operating System – Sistema
Operacional de Rede (NOS) (MEDVED et al., 2014; ZHOU et al., 2014; AUTENRIETH et
al., 2015).
30
2.2 WEB SERVICES
A possibilidade de realizar a gerência de configuração de uma rede de computadores
por meio de técnicas baseadas em princípios distribuídos e com a disponibilização de uma
interface amigável ao administrador do ambiente tem como principal objetivo transpor as
limitações impostas pelo modelo tradicional de configuração, e que se dá muitas vezes pelo
acesso individual e direto à CLI de cada componente. A tecnologia de web services pode ser
utilizada para fornecer meios que possibilitem o desenvolvimento de ferramentas que
permitam o mapeamento desses comandos executados na CLI durante a realização das tarefas
da gerência de configuração através de serviços ou recursos distribuídos (GIOVANNI;
LUIGI, 2012).
Com o intuito de refinar, padronizar e também sugerir a forma como web services
devem funcionar, uma definição inicial é apresentada pela World Wide Web Consortium
(W3C), citada também por Austin et al. (2004) e Berners-lee, Fielding e Masinter (2005).
Nessa apresentação web services são abordados como aplicativos identificados por um
Uniform Resource Identifier – Identificador Uniforme de Recurso (URI) cujas interfaces e
ligações são descritas, definidas e descobertas por outras aplicações através de Extensible
Markup Language – Linguagem de Marcação Extensível (XML) utilizando-se de meios de
transporte definidos por protocolos da internet. Resultantes dessa definição inicial,
apresentações distintas foram surgindo com o objetivo de comparar web services a outras
estratégias de middleware ou a fim de fornecer uma visão mais genérica e centrada no
contorno dos problemas de comunicação entre aplicações totalmente heterogêneas, orientando
o desenvolvimento de software no sentido de incorporar características como flexibilidade e
reutilização de componentes.
Segundo Tanenbaum e Steen (2006) e Coulouris et al. (2011) web services são
aplicações desenvolvidas de forma modular baseadas em componentes de software,
implementadas de modo a serem independentes de plataforma de hardware, sistema
operacional, infraestrutura de rede ou linguagem de programação. São também aplicações
auto-descritas, acessíveis e descobertas através da internet e que possibilitam a comunicação e
a integração de sistemas distintos ou mesmo a interoperabilidade entre componentes de
software instalados em infraestruturas diferentes, desde que executem funções bem
específicas. Para atingir esse nível de interoperabilidade, ambas as aplicações provedoras e
consumidoras de web services devem respeitar um conjunto de padrões previamente
31
definidos, que atentem a descoberta, a especificação da forma como ocorre a comunicação e
os parâmetros de chamada e retorno.
Para He e Xu (2014) web services são componentes que normalmente contém várias
funções e podem ser organizados como uma entidade única. Esses componentes são utilizados
para a construção e a integração de aplicações heterogêneas, sendo distribuídos e acessados
através da internet. Web services podem utilizar vários protocolos como Hypertext Transfer
Protocol – Protocolo de Transferência de Hipertexto (HTTP), Simple Mail Transfer Protocol
– Protocolo de Transferência de Correio Simples (SMTP) e File Transfer Protocol –
Protocolo de Transferência de Arquivo (FTP) para transferência dos dados; contudo, o
protocolo HTTP é comumente adotado fazendo com que esses componentes se sobreponham
a abordagens tradicionais como Common Object Request Broker Architecture (CORBA) e
Distributed Component Object Model – (DCOM), que apresentam dificuldades para
ultrapassar os limites de firewalls durante a comunicação entre processos.
Conforme Girbea et al. (2014) os padrões e a tecnologia estabelecida através de web
services devem ser utilizados no desenvolvimento sempre que possível. As aplicações devem
fornecer interfaces de acesso universal, além de serem interoperáveis e seguras. Essas
aplicações, que disponibilizam seus dados através de web services, devem possibilitar a
integração com sistemas complexos e serem escaláveis.
Todas as definições apresentadas acima corroboram uma definição mais genérica
apresentada por Sheng et al. (2014). Para os autores, web services são como uma abstração
semântica de um conjunto bem definido de atividades computacionais ou físicas envolvendo
uma série de soluções destinadas a atender as necessidades de um cliente ou um requisito de
negócio, podendo ser descrito, anunciado e descoberto utilizando uma linguagem baseada em
padrões e interagindo através de protocolos que utilizam a internet como base para a
comunicação entre clientes e servidores. Define-se ainda que as duas formas principais para o
desenvolvimento de web services são os tradicionais web services baseados em SOAP e os,
conceitualmente mais simples, web services REST.
Motivados por essa separação, as diversas formas de aplicações interagirem através
de web services serão apresentadas nas seções 2.3 e 2.4. Nessas seções são expostas as
arquiteturas, paradigmas e tecnologias que possibilitam a composição, exposição, descoberta
e utilização de processos internos de software, respeitando e fazendo uso das características e
definições de web services descritas anteriormente.
32
2.3 SOA
À medida que a complexidade e o tamanho dos sistemas distribuídos aumentam, a
flexibilidade é identificada como sendo a palavra-chave. Essa flexibilidade é imposta sobre as
maneiras antigas de lidar com problemas de escalabilidade e distribuição onde, para se
alcançar os objetivos de harmonizar e manter o controle, necessitava-se de uma nova
abordagem que fosse portável à heterogeneidade e voltada à descentralização. Dadas as
imposições que foram surgindo, o conceito de SOA e seus atributos foram sendo aprimorados
para diminuir e/ou até suprimir os problemas que apareciam sobre paradigmas de programas,
ambientes operacionais, escalabilidade e harmonização de sistemas legados.
A capacidade de trabalhar com sistemas distribuídos onde a integração e a
manutenção entre aplicações são constantes leva ao uso de SOA. Sua utilização abre a
possibilidade para entidades que necessitam de certas capacidades distribuídas localizarem e
fazerem o uso das mesmas.
O conceito SOA, relacionado com web services, pode ser analisado onde web
services irá trazer SOA para os usuários finais, e o bom uso das funcionalidades e práticas
definidas por SOA irá trazer uma possibilidade para uso de web services (JOSUTTIS, 2008;
SERRANO, HERNANTES; GALLARDO, 2014). Vê-se nisso que web services não
necessariamente utilizam SOA, e nem que SOA seja baseada em web services.
Antes de discorrer sobre o significado dessa arquitetura e seus atributos necessita-se
definir o conceito de serviço dentro desse ambiente. Um serviço pode ser tratado como uma
representação discreta de uma funcionalidade de negócio disponível através de um contrato.
Esta representação deve corresponder a uma funcionalidade independente, porém relacionada
à atividade do mundo real, fornecendo uma interface bem definida para que possa ser
realizada uma correta troca de mensagens ou alteração do estado de uma entidade associada.
Essas definições, tratadas entre os pares, são realizadas através de contratos – os quais
possuem a interface do serviço, os documentos da interface, as políticas e os acordos de
desempenho de cada serviço. Uma das principais diferenças entre a construção de
componentes de software convencionais e web services (esse último, por mais relacionado
que esteja com SOA) é que a utilização de serviços vai além da implementação e a eleva
diante de aspectos gerenciais, onde o serviço é acompanhado desde a sua concepção e
implantação até a manutenção (ROSEN et al., 2012). Para Haupt et al. (2014), as principais
33
entidades de SOA são os serviços em si, pois é através deles que é fornecido um conjunto de
operações.
A figura 5 apresenta a estrutura de um serviço. Nela, observa-se a divisão entre a
interface e a implementação. A interface do serviço especifica as operações do serviço, ou
seja, o que o serviço realiza. É nesse ponto que se especificam os parâmetros, informados
durante as solicitações e respostas, e também o protocolo que trata de como isso será
fornecido e utilizado. Cabe salientar que um serviço pode realizar uma ou várias operações. Já
a implementação desse serviço pode ser baseada em aplicações existentes através da
orquestração junto a outros serviços ou desenvolvida para atender uma necessidade pontual,
estabelecendo o código utilizado para a execução do serviço e também a forma como serão
gerenciados internamente os dados. Separando a interface da implementação melhora-se o
fator de acoplamento da solução, diminuindo-o como um todo. Define-se assim que um
serviço dentro dessa arquitetura é uma combinação de um conjunto de operações de serviços e
dados passados entre componentes.
Figura 5 – Estrutura de um serviço na arquitetura SOA.
Fonte: Elaborada pelo autor com base em ROSEN et al. (2012).
SOA pode ser definida como um paradigma ou uma arquitetura utilizada durante o
desenvolvimento de software e serve como base para integrar e organizar recursos
distribuídos estabelecendo diversas formas de controle em um ambiente heterogêneo onde
cada elemento é exposto como um serviço (PULIER; TAYLOR, 2008). Existem muitas
definições diferentes de SOA, mas todas tratam essa arquitetura como sendo um paradigma
para o aumento da flexibilidade dos componentes de software resultantes da sua utilização.
34
Outras definições mais centradas no processo de software tratam SOA como uma
tendência na integração de sistemas heterogêneos e diferentes sistemas de middleware onde
os desenvolvedores organizam e empacotam aplicações distintas como serviços. Para que isso
aconteça cada serviço inclui uma interface que especifica as operações disponíveis e os tipos
de mensagens, representando assim um modelo em que a lógica do negócio é separada em
pequenas unidades distintas (HE; XU, 2014). Utilizando-se dessas características são criadas
estruturas organizacionais e técnicas que permitem que essa lógica seja apresentada e
utilizada por diferentes consumidores como blocos de construção para aplicações atuais e
futuras (SANTOS, C. et al., 2015).
Através dessas diversas propriedades analisa-se que SOA fornece uma arquitetura de
software onde os componentes desses sistemas (serviços) são conectados através de
mensagens que se utilizam de primitivas baseadas na modularidade e na comunicação com o
objetivo de melhorar o nível de interoperabilidade e abstração desses componentes. Observa-
se também que as interfaces criadas podem ser disponibilizadas e acessadas como serviços
autônomos sem que sua implementação interna seja conhecida.
Define-se também que SOA não está atrelada a nenhuma tecnologia específica;
entretanto, essa arquitetura utiliza de alguns padrões pré-estabelecidos e bem consolidados
como web services, protocolo SOAP, linguagens como XML e Web Services Description
Language – Linguagem de Descrição de Serviços Web (WSDL), apresentados nas seções a
seguir e que visam facilitar a sua adoção, desde que exista a concordância uniforme da
tecnologia utilizada entre as partes envolvidas na comunicação.
2.3.1 Componentes e Paradigma
Em um sistema SOA, três tipos de componentes podem ser reconhecidos
(PAPAZOGLOU; HEUVEL, 2007; GIOVANNI; LUIGI, 2012; SUN; STRANG;
YEARWOOD, 2014):
Service Provider (Provedor de Serviço) – é o componente que torna um serviço
disponível, ou o serviço em si que executa uma tarefa solicitada. Para que isso
aconteça o serviço precisa ser publicado a fim de se tornar disponível para outros
clientes ou mesmo serviços. Essa publicação acontece através de um componente
que registra, em um primeiro momento, os serviços a serem oferecidos pelo
provedor.
35
Service Registry (Registro de Serviço) – é o componente responsável por
intermediar as requisições, interpondo-se entres os provedores e os consumidores.
O registro de serviço recebe dos provedores e disponibiliza aos consumidores as
informações relativas a um serviço, criando assim um ambiente confiável entre os
agentes envolvidos. Essa confiabilidade pode ser apresentada na obrigatoriedade
da aderência de provedores a práticas que estejam em conformidade com leis ou
regulamentos de privacidade exigidos pelos consumidores. Esse componente,
além de manter as informações dos serviços como endereço e funcionalidades,
pode oferecer um índice de provedores disponíveis no exato momento, sendo
também capaz de agregar valores a estes registros propiciando assim
características adicionais a seus consumidores como diferenciais de credibilidade,
confiabilidade, Service Level Agreement – Acordo de Nível de Serviço (SLA),
possíveis rotas de compensação, composição, recomendação ou transferência de
serviços.
Service Consumer (Consumidor do Serviço) – é o componente responsável por
buscar as informações relevantes por meio do registro de serviço às quais serão
utilizadas para identificar como deverá se proceder com a comunicação durante a
invocação e execução dos serviços. Esse componente pode ser outro serviço ou
uma aplicação que demande de uma tarefa a ser executada por um serviço.
Percebe-se também que, embora os serviços disponibilizados por SOA sejam visíveis
para os consumidores, seus componentes web subjacentes são transparentes. O consumidor do
serviço não tem de se preocupar com a implementação do serviço, contanto que ele suporte a
funcionalidade necessária, oferecendo a qualidade desejada. Do ponto de vista do provedor de
serviço o projeto e a gerência de seus serviços refletem sua arquitetura e design, sendo
decisões chave para o alcance de SOA.
Baseada nesses componentes, SOA é organizada de acordo com o paradigma find/
bind and invoke/publish (encontrar, conectar/invocar e publicar). Cabe salientar que através
da utilização desse paradigma é introduzido um maior grau de flexibilidade na criação de
serviços complexos por meio da possibilidade de integração de serviços complementares.
A figura 6, além de apresentar os componentes e o paradigma descritos acima,
evidencia que através do seu uso é possível alcançar um nível de correlação entre SOA e web
36
services através das características de descrição, definição e descoberta expostas
anteriormente.
Figura 6 – Paradigma e componentes da arquitetura SOA.
Fonte: Elaborada pelo autor com base em Giovanni e Luigi (2012) e Sun, Strang e Yearwood (2014).
2.3.2 Características da Arquitetura
Do ponto de vista da concepção e do desenvolvimento de serviços dentro de SOA,
algumas características devem ser abordadas como chave ou princípios arquitetônicos
somando-se ao paradigma find/bind and invoke/publish e a independência de localização,
linguagem e protocolo (JOSUTTIS, 2008; GIOVANNI; LUIGI, 2012; ROSEN et al., 2012;
SERRANO; HERNANTES; GALLARDO, 2014; SANTOS, C. et al., 2015):
encapsulamento – característica que estabelece funcionalidades bem definidas de
um serviço, tornando-o capaz de se comunicar com outros serviços através de
interfaces padronizadas ocultando detalhes da estrutura ou dados internos dos
serviços;
acoplamento fraco – capacidade de interligação entre duas tecnologias ou entre
provedores e consumidores. Em um acoplamento fraco os serviços mantém uma
relação onde a dependência entre ambos é pequena. Essa característica possibilita
que a arquitetura lide bem com os requisitos de escalabilidade, flexibilidade e
tolerância a falhas. Aspectos como comunicação assíncrona e harmonização de
37
tipos de dados heterogêneos são premissas tratadas durante o desenvolvimento de
serviços fracamente acoplados;
abstração – característica que trata os quesitos de como o serviço irá ocultar sua
lógica interna de implementação de seus consumidores;
granularidade – é a qualidade da riqueza funcional de cada serviço, podendo ser
dividida em granularidade fina e grossa.
granularidade fina – estabelecer uma granularidade fina nos serviços
disponibilizados pode ser entendido como a existência de um serviço para
cada acesso a determinado atributo. Como exemplo, cita-se o uso de um
serviço para cada método definido pelo projetista/programador como get ou
set de uma classe. Essa característica pode causar certa demora entre o tempo
de requisição e resposta desses serviços devido às inúmeras requisições que
poderão executar tarefas diferentes; contudo, serviços de granularidade fina
impõe um grau ascendente de flexibilidade entre aplicações.
granularidade grossa – em contrapartida, os serviços de granularidade
grossa fornecem um maior nível de funcionalidade durante uma única
operação de serviço. Em uma chamada a determinado serviço com
granularidade grossa pode ser passada e retornada uma série de parâmetros;
entretanto, essa sobrecarga no número de parâmetros pode influenciar
negativamente no aumento da largura de banda, levando à diminuição de
desempenho.
isolamento – característica que isola a responsabilidade de cada serviço
promovendo a existência de apenas uma forma de executar determinada função.
Isso possibilita aos serviços uma funcionalidade adicional de consistência e
também de diminuição de código redundante;
autonomia – permite que os serviços sejam implantados, modificados e mantidos
de forma independente podendo ser representados por um ciclo de vida;
falta de estado – permite que durante a execução do serviço não se mantenha
nenhum estado entre diferentes chamadas de serviços, sendo que todos os
processos ou threads usados na instância são descartados. Essa característica faz
38
com que as chamadas anteriores não interfiram em chamadas futuras,
minimizando a retenção de informações;
componibilidade – característica que um serviço tem de ser coordenado e
agrupado a fim de tornar-se um serviço composto;
reutilização – caracterizada como sendo a divisão lógica de um serviço com a
intenção de reuso. O alcance dessa característica foi apresentado por último dentro
desta listagem pelo fato de que é fortemente dependente das características de
encapsulamento, acoplamento fraco, isolamento de responsabilidade e autonomia.
2.3.3 Tecnologias Relacionadas
Por mais independente que SOA seja de tecnologia, quando utilizada no
planejamento e desenvolvimento de serviços precisa oferecer e sustentar as características
descritas na seção anterior. Para atingir o objetivo de contemplar todas as características
previstas pela arquitetura, vê-se necessária a utilização de web services (conhecidos como
SOAP WS) em conjunto com três padrões bem estabelecidos – SOAP, WSDL e UDDI
(GIOVANNI; LUIGI, 2012; SHENG et al., 2014).
Em SOA, as interações entre provedores e consumidores de serviços, realizadas por
meio de web services, são definidas pelo protocolo Simple Object Access Protocol –
Protocolo de Acesso Simples a Objetos (SOAP), baseado no modelo de dados XML e
fundamentado em protocolos da camada de aplicação tais como HTTP e SMTP para a
negociação e transmissão de mensagens. As especificações SOAP definem como o XML será
utilizado para representar o conteúdo de mensagens individuais, a forma com que duas
mensagens podem ser acordadas para produzir mensagens padronizadas de requisição e
resposta, as normas de como os destinatários devem tratar os elementos de um arquivo XML,
bem como o protocolo que deve ser utilizado para comunicação. Uma mensagem SOAP
contém um elemento descrito como envelope que fornece as informações de contexto de
serialização, espaço de nomes dos elementos e parâmetros utilizados na mensagem. Por sua
vez, esse elemento raiz é segmentado em duas partes (TEKLI et al., 2012):
header (cabeçalho) – elemento opcional que contém informações não
relacionadas com a invocação ou resposta da operação em si, mas possibilita a
39
aderência ao serviço e trata de aspectos relativos à segurança, roteamento ou
manipulação da mensagem por parte do destinatário;
body (corpo) – elemento principal e requerido, pois contém o conteúdo da
mensagem a ser transmitida. Esse conteúdo pode ser composto por parâmetros ou
valores de parâmetros de requisições ou respostas ou simplesmente dados no
formato XML.
Como citado anteriormente, durante a utilização de SOA institui-se um contrato de
padrões entre as partes envolvidas. Esse contrato pode ser exposto através de um arquivo Web
Services Description Language – Linguagem de Descrição de Serviços Web (WSDL) que
contém os endereços e operações suportadas pelo serviço, os parâmetros necessários para
invocação dessas operações e também os tipos de dados e protocolos utilizados durante a
transação (MATEOS et al., 2013).
Como funcionalidade adicional, e utilizando-se dos componentes definidos pela
arquitetura, um serviço pode ser publicado e descoberto em um diretório. As especificações
tratadas pelo protocolo Universal Description, Discovery and Integration (UDDI) oferecem
mecanismos necessários ao consumidor que necessita encontrar serviços para atendimento a
um determinado requisito. Para fornecer essas facilidades, os diretórios UDDI se valem de
web services baseados em XML e SOAP (CLEMENT et al., 2004).
2.4 ROA
Resource Oriented Architecture – Arquitetura Orientada a Recurso (ROA), assim
como SOA, é uma arquitetura que orienta uma metodologia de desenvolvimento e estabelece
elementos e conceitos das melhores práticas na utilização do modelo cliente/servidor durante
o projeto e criação de componentes distribuídos, fracamente acoplados e baseados em
Representational State Transfer – Transferência de Estado Representacional (REST)
(LUCHI; MILLOT; ELFERS, 2008; MAROTTA et al., 2014).
Segundo Guo, Shen e Yin (2010) e Singh et al. (2015), ROA define um conjunto de
critérios para concepção e também uma maneira de transformar um problema em um web
service RESTful, sendo este um arranjo de HTTP, URIs e XML que interagem com o restante
da internet tornando-se uma alternativa mais simples e menos carregada, se comparada a
SOAP WS, para construção de web services.
40
A utilização de ROA como arquitetura é uma opção que possibilita a criação e
disponibilização de web services de forma leve utilizando-se de padrões simples e largamente
utilizados. Como citado na seção 2.3, SOA é baseada em web services que realizam algumas
operações (gets e sets, por exemplo) motivados por requisitos de negócio; já ROA usufrui
dessas ações através de substantivos e seu acesso se dá por meio de um URI (OVERDICK,
2007; SINGH et al., 2015). As operações (verbos) em ROA ficam a cargo da interface
uniforme que será apresentada na próxima seção.
2.4.1 REST – A Base da Arquitetura
A base da arquitetura ROA é fundamentada nos princípios de REST. REST, por sua
vez, não é uma arquitetura ou um padrão nos mesmos moldes de SOAP, e pode ser definido
com um estilo arquitetural, desenvolvido por Roy Fielding em sua tese de doutorado
(FIELDING, 2000) como um modelo abstrato da arquitetura web para orientar a reformulação
e definição do Hypertext Transfer Protocol (HTTP) e dos URIs baseado em um conjunto de
critérios para o desenvolvimento de aplicações em rede. Esse estilo consiste em várias restrições
para tratar da divisão de interesses, visibilidade, confiabilidade, escalabilidade, flexibilidade e
desempenho. Embora REST não possa ser tratado como um padrão de fato, com a finalidade de
definir seu comportamento e boas práticas, no intuito de transformar um problema em um recurso,
ele faz uso de padrões estabelecidos e difundidos no desenvolvimento de aplicações web
distribuídas, tais como HTTP, URIs, XML, JavaScript Object Notation (JSON), HTML, dentre
outros (BELQASMI et al., 2012; DUGGAN, 2012; NUNES et al., 2015). Para Li (2011) REST
não é um protocolo e sim uma descrição de como desenvolver um sistema distribuído, frente as
suas dificuldades, utilizando-se ao máximo dos recursos básicos da web.
O conceito que torna REST um estilo arquitetural e que possibilita o desenvolvimento de
aplicações distribuídas também é analisado em Santos, C. et al. (2015). Os autores destacam que a
principal característica de REST é envolver clientes e servidores através do envio e recebimento
de mensagens de uma forma que não fossem impostas restrições sobre o seu formato, mas sim
sobre o comportamento dos elementos envolvidos.
O estilo REST não restringe a comunicação entre cliente e servidor a um protocolo
específico; contudo, o protocolo comumente utilizado é o HTTP para transferência de dados e
representações entre web services. Antes de utilizar um recurso, o consumidor precisa encontrá-lo
e conhecê-lo. Para a realização dessas tarefas, além do uso de WSDL, comumente utiliza-se de
um arquivo Web Application Description Language – Linguagem de Descrição de Aplicação Web
41
(WADL). O foco de um arquivo WADL está no recurso, que descreve sua finalidade, contendo
um identificador URI, os dados que devem ser informados como parâmetros para invocação e o
padrão utilizado para resposta. Ao invés de interfaces os recursos descritos nesse arquivo têm uma
noção dos métodos HTTP que são aplicados a eles (FOKAEFS; STROULIA, 2015; XUE;
ZHANG; JI, 2015).
Segundo Richardson e Ruby (2007) a arquitetura ROA toma por base quatro
elementos oriundos de REST:
recursos – no lugar da definição de serviços exposta por SOA, em ROA tem-se o
conceito de recurso. Recursos são utilizados para transformar um problema em
um web service REST. Um recurso em ROA é um mapeamento conceitual, onde
um servidor recebe um identificador e responde com uma ação. Para Belqasmi et
al. (2012) uma definição, em primeiro momento formal e depois voltada à
programação é apresentada sobre os recursos dentro de ROA. Os autores referem-
se a um recurso como qualquer forma de informação que seja importante o
suficiente para ser referenciado como um documento, uma linha em um banco de
dados ou o resultado de uma pesquisa. Uma visão mais genérica é apresentada por
Ambra et al. (2013) e Polônia, Melgarejo e Queiroz (2015) onde os recursos são
tratados como uma informação abstrata de uma entidade que possa ser mapeada e
identificada. Recursos não são os dados em si, são apenas uma ideia de como os
dados de web services serão divididos podendo ser apresentados de forma estática
ou com alguma variação;
representações – as representações expõem o estado atual ou desejado de um
recurso partindo do princípio que os recursos são os dados conceituais em si. Se o
estado atual de um recurso for um dado, as representações apresentam a sua
estrutura semântica (metadados) e seu conteúdo. Cabe salientar que as
representações não estão vinculadas a qualquer tipo de dado em particular,
podendo ser utilizado qualquer formato para representar um recurso (arquivos
HTML, XML, JSON, imagens ou vídeos, por exemplo), e sua utilização oculta do
cliente aspectos internos desses recursos. Com o objetivo de facilitar o
entendimento Haupt et al. (2014) cita o exemplo de um blog na internet que
utiliza REST. Um artigo desse blog é o recurso disponível e o cliente, ao acessar
esse artigo, abre uma representação HTML do recurso (artigo). Utilizando dessa
premissa um recurso pode ter múltiplas representações e os clientes podem
42
escolher quais representações se adaptam à sua realidade através de mecanismos
de múltiplo acesso. Esse múltiplo acesso pode ser alcançado de duas formas:
nomeando e acessando recursos através de identificadores únicos (diferentes
URIs) ou por meio de negociação de conteúdo – por exemplo, através de atributos
de cabeçalho da solicitação HTTP (POLÔNIA; MELGAREJO; QUEIROZ,
2015);
nomes – a URI é o nome e o endereço de um recurso. Sua utilização é
fundamental e se ignorada não possibilita a visibilidade e utilização de um
recurso. A URI é responsável por fazer referência a um recurso e também por
manter a validade semântica do mapeamento ao longo do tempo. As URIs
necessitam ser correspondências claras de um recurso e devem direcionar a apenas
um recurso; entretanto, várias URIs podem designar um único recurso
possibilitando várias formas de acesso ao mesmo aumentando sua visibilidade;
links (hypermedia relationships) – é através dos links que são fornecidos acessos
a outros recursos, bem como a sua correlação. Um exemplo clássico da utilização
de links é a pesquisa em um site de busca que faz o uso dos conceitos de REST.
Após uma consulta, o site retorna os dados (representações de um determinado
recurso pesquisado) fornecendo ligações para essas representações. Os links
podem qualificar o estado interno de um recurso permitindo a suposição sobre o
seu comportamento (OVERDICK, 2007).
2.4.2 Condições Norteadoras de REST
Trabalhando em conjunto com os quatro elementos apresentados na seção anterior
um web service, para ser considerado aderente ao estilo arquitetural REST deve atender às
seguintes condições (RICHARDSON; RUBY, 2007):
ser endereçável – o endereçamento trata da exposição do conjunto de
características de um recurso através de uma URI. A característica de uma
aplicação endereçável possibilita que outros clientes ou aplicações façam a
utilização das representações desses recursos (GRÜNER; PALM, 2015). Para que
isso aconteça, a aplicação precisa dividir os dados em um conjunto de recursos e,
por sua vez, em representações;
43
ser encadeado – condição oferecida à uma aplicação por meio dos links enviados
na resposta das representações. O cliente, na utilização de uma aplicação bem
encadeada, percorre um caminho de recursos sendo guiado através de links bem
definidos. Fielding (2000) define o encadeamento tratando a hipermídia como
motor de estado da aplicação. Nesse caso, links e formulários demonstram os
mecanismos de estados responsáveis pela alteração do estado do recurso
(RICHARDSON; RUBY, 2007);
utilizar interface uniforme – define como os recursos são acessados e as
operações básicas que podem ser realizadas sobre eles. Essa uniformização impõe
uma padronização, utilizando um conjunto fixo e largamente utilizado das
primitivas Create, Read, Update and Delete – Criar, Ler, Atualizar e Deletar
(CRUD), na comunicação entres os componentes de uma aplicação REST (OH;
KIM, 2014). Nesse ponto, cabe um adendo: a diferença entre recursos está
intrínseca nas representações e não na sua interface uniforme. Novamente
valendo-se do protocolo HTTP como mediador de interações entre clientes e
recursos, REST dispõe de métodos básicos para expor suas funcionalidades
(OVERDICK, 2007; PAUTASSO, 2009; LI, 2011; DUGGAN, 2012):
GET – uma requisição para recuperação/leitura da representação do estado
atual de um recurso. Como a requisição GET não altera o estado atual do
recurso, a ela cabe a possibilidade de ser armazenada em cache;
PUT – operação que trata da criação/atualização completa de um recurso. Se
o recurso informado previamente na representação da URI não existir ele é
criado; caso contrário, é atualizado;
POST – requisição que tem por objetivo a criação (adição) de um recurso
baseado em outro preexistente. É através da requisição POST que pode ser
utilizada a capacidade de anexar algo ao estado de um recurso existente sem
precisar criar um novo recurso;
DELETE – operação utilizada para definir que a representação de um
recurso, identificado através de uma URI, não deve mais existir. Cabe
salientar que a operação DELETE, assim como PUT, é tratada de forma
idempotente; ou seja, executar mais de uma vez uma representação através
dessas operações deve ter o mesmo efeito de executá-la apenas uma vez, não
44
afetando o estado do recurso. O único efeito para o DELETE será na posterior
resposta negativa do método GET pois sua URI foi invalidada;
HEAD – similar a uma requisição GET, diferenciando-se pelo fato de que
somente os metadados da representação são enviados, omitindo-se a
representação em si;
OPTIONS – é um método utilizado para descobrir qual o conjunto de
interfaces uniformes (operações básicas) são suportados pelos recursos. Essa
operação é pouco utilizada pelo fato de existirem mecanismos de
documentação como arquivos eXtensible Hypertext Markup Language
(XHTML) ou WADL;
não ter estado – conforme citado anteriormente REST faz uso de tecnologias
como HTTP, que por padrão é um protocolo sem estado, incorrendo que toda
solicitação ocorre em um isolamento completo e nenhuma informação do cliente
(sessões por exemplo) é armazenada no servidor (TANENBAUM; STEEN, 2006;
RICHARDSON; RUBY, 2007). Para que isso ocorra a solicitação deve conter
todos os dados necessários (através de URI, cabeçalhos ou corpo do pedido) para
ser compreendida e atendida pelo servidor. Em uma aplicação REST o lado
servidor não preserva qualquer estado da aplicação. Cabe salientar aqui uma
diferença entre estado da aplicação e estado do recurso. O estado do recurso fica
armazenado no servidor e é enviado ao cliente, a cada requisição, através de
representações (dados dos recursos). Já o estado da aplicação fica no lado do
cliente, sendo o endereço acessado por ele e utilizado para realizar alguma ação
sobre um recurso, tornando os pedidos e as respostas autossuficientes (NUNES et
al., 2015). Essa característica permite que mecanismos simples de sincronismo de
dados entre os componentes da arquitetura possam ser utilizados para resolver
problemas complexos de balanceamento de carga. O fato de uma aplicação REST
não manter o estado da aplicação simplifica a comunicação assíncrona e o envio
de solicitações isoladas em paralelo (GRÜNER; PALM, 2015). Esse fato pode se
tornar um ponto positivo e negativo ao mesmo tempo, visto que o desempenho da
rede pode ser degradado pelo aumento do número de pequenas requisições.
utilizar cache – como a arquitetura de uma aplicação REST é distribuída em
camadas que se comunicam diretamente apenas com a camada adjacente
45
(podendo ser composta por elementos físicos intermediários como proxies,
gateways, servidores ou mesmo o próprio equipamento do requisitante) o cliente
não tem a capacidade de diferenciar se está conectado com uma representação
final do recurso ou com um intermediário (POLÔNIA; MELGAREJO;
QUEIROZ, 2015). Diante dessa característica um equipamento, tanto do lado do
cliente ou do servidor, inserido neste meio, pode fazer um uso eficiente da rede
realizando cache das respostas e, por sua vez, eliminando algumas interações
durante a comunicação (SANTOS, C. et al., 2015). Contudo, existe um tradeoff
(conflito de escolha) na utilização de caches: se esse mecanismo não for bem
controlado, representações antigas de recursos armazenados podem ser
apresentadas aos clientes, diminuindo a confiabilidade; entretanto, seu uso
aumenta a escalabilidade e o desempenho;
A figura 7 possibilita a visualização de uma aplicação REST composta dos
elementos e das condições que a orientam. Nela é analisada primeiramente a topologia do
sistema que é composta por: uma aplicação hospedada em um cliente, um balanceador de
carga, servidores proxies que gerenciam o cache das requisições oriundas dos clientes e um
servidor web (repositorio.com) que se torna o elemento responsável por hospedar e gerenciar
os recursos de um repositório que, neste exemplo, é composto de livros e revistas.
Iniciando-se do cliente tem-se o conceito da interface uniforme, através do método
HTTP GET que possibilita a realização de uma solicitação de busca ao resumo do livro
identificado pelo número 10. O identificador é enviado através do URI que endereça a
aplicação (http://repositorio.com/livro/10/resumo) e não infringe a privacidade do recurso.
Cabe aqui citar dois pontos sobre a solução: a utilização do protocolo HTTP que por padrão é
um protocolo sem estado, e salientar que a aplicação do cliente não armazena nenhum registro
(sessão) das requisições no lado do servidor. Orientando-se por esses dois pontos pode-se
realizar facilmente o balanceamento de carga e o cache das requisições em servidores proxy
sincronizando somente o estado do recurso (representação). Utilizando-se do conceito de
recurso e representação, temos o livro como recurso e seu resumo atual como a representação
que o sintetiza. Nesse mesmo servidor tem-se hospedado outro recurso (revistas) e, por
conseguinte, sua representação que é uma listagem (links) com as notícias de determinada
revista. Regressando ao livro e ao seu resumo, o tipo de dado retornado para a solicitação
GET é apresentado no formato JSON e é analisado no texto da figura que contém a resposta
do servidor ao lado do cliente.
46
Figura 7 – Elementos e condições de uma aplicação REST.
Fonte: Elaborada pelo autor.
2.5 TRABALHOS RELACIONADOS
As técnicas tradicionais de gerenciamento de redes, baseadas única e exclusivamente
na configuração individual dos equipamentos através da CLI, não escalam no contexto atual
de heterogeneidade das grandes infraestruturas corporativas, acadêmicas ou de Datacenter.
Para contornar esse cenário tradicional, novas abordagens e técnicas, baseadas no
mapeamento de comandos CLI em web services ou protocolos específicos, podem ser
utilizadas no desenvolvimento de ferramentas amigáveis que auxiliem o administrador nas
tarefas que norteiam a gerência de configuração de dispositivos de rede (KIM; FEAMSTER,
2013). Nas sessões a seguir serão apresentados os trabalhos relacionados, selecionados a
partir de uma busca com base em abordagens práticas relativas às arquiteturas e protocolos
apresentados anteriormente e que visam encontrar meios para sobrepor os problemas de
interoperabilidade de equipamentos, ambientes ou informações.
2.5.1 SOA e SOAP
Em Anedda e Atzori (2009), é proposta a criação de uma solução de gerenciamento
de configuração de redes baseada na arquitetura SOA. A fim de abstrair os detalhes
47
proprietários e específicos de cada fornecedor, foi implementado um protótipo para validar a
proposta que se ampara na tarefa de alteração de VLANs em switches das marcas Cisco e HP.
Notou-se que, com a utilização da solução proposta, a flexibilidade e a facilidade na
implantação de serviços de gerência rede baseados em interfaces já existentes foram
elencadas como características principais. Em contrapartida a utilização do protocolo SOAP,
se comparada com as formas tradicionais como SNMP, injeta uma quantidade considerável de
dados na comunicação, o que pode impactar negativamente no cenário da rede de
gerenciamento.
A comparação entre web services SOAP e REST é analisada em Belqasmi et al.
(2012) no desenvolvimento de aplicativos para conferência multimídia. Observou-se que o
atraso com a utilização de uma arquitetura distribuída (componentes instalados em máquinas
distintas) das aplicações baseadas em REST foi de três a cinco vezes menor se comparado à
abordagem que utiliza o protocolo SOAP. Salientou-se que as aplicações realizam tarefas
iguais e diferenciam-se somente na forma de acesso, o que leva à conclusão que o protocolo
SOAP é o responsável pelo maior atraso devido às características inerentes ao protocolo e
apresentadas na seção 2.3. As diferenças de atraso são semelhantes (REST é de três a quatro
vezes menor que SOAP) com o cenário onde a instalação de todos os componentes era
disposta sobre uma única máquina, ressaltando ainda mais o tempo demandado para o
processamento das mensagens SOAP. Já a sobrecarga da rede utilizando web services REST é
de duas a três vezes menor do que seu concorrente SOAP. Novamente essa diferença é
analisada pela forma com que os web services SOAP realizam a comunicação com a
utilização de envelopes e arquivos XML. Conclui-se que, tanto para o cenário distribuído
quanto para o local, a utilização de web services REST é mais vantajosa quando comparada
ao seu concorrente SOAP.
2.5.2 ROA e REST
Já a modelagem dos serviços Session Initiation Protocol (SIP) em recursos REST é
analisada por Ambra et al. (2013). Nesse trabalho os recursos de chamada são encarregados
de executar e gerenciar a configuração de um canal de comunicação entre dois pares,
localizados em máquinas distintas. Para isso é definida uma metodologia que passa pela
especificação de um conjunto de APIs REST para tratamento dos recursos de chamada. Após
isso é modelado o comportamento do recurso por meio de uma notação de máquina de estados
48
finita, e posteriormente é projetado e desenvolvido um protótipo que garante a
interoperabilidade entre agentes SIP em clientes web heterogêneos. Posterior à modelagem,
foram realizados testes de medição de atraso de uma arquitetura puramente baseada em REST
e outra fundamentada em REST-SIP. Percebeu-se que o atraso na arquitetura baseada
unicamente no protocolo REST é aproximadamente 50% menor que a abordagem híbrida
REST-SIP, fato motivado pelo tempo adicional de processamento imposto pelo protocolo
SIP.
Em Marotta et al. (2014) uma avaliação do protocolo SNMP e das arquiteturas ROA
e SOA é realizada no contexto da gerência de dispositivos (sensores) para internet das coisas.
O gerenciamento de dispositivos da internet das coisas engloba o acesso a esses objetos,
através de protocolos de comunicação de forma direta com tecnologias padronizadas como
HTTP ou Internet Protocol Version 6 – Protocolo de Internet Versão 6 (IPv6), ou indireta por
meio de gateways que intermediam o acesso desses sensores à internet. A forma indireta é
utilizada quando os sensores são desprovidos de grandes recursos de processamento. É nessa
forma indireta de comunicação, utilizada pelo trabalho de Marotta et al. (2014), que estão
inseridos o protocolo e as arquiteturas citadas anteriormente. Para a realização dos testes
foram desenvolvidos protótipos para as três formas de acesso respeitando as peculiaridades
das arquiteturas ou protocolos que coletam dados de temperatura e luminosidade. As métricas
analisadas foram o tempo de resposta despendido para solicitar e recuperar uma informação a
partir de um sensor, o consumo de energia do dispositivo, entre outras. Analisou-se que o
tempo de resposta utilizando ROA é semelhante ao SNMP para coleta de informações, sendo
aproximadamente sete vezes mais rápido se comparado a SOA. Para a métrica que trata do
consumo de bateria a arquitetura ROA é 32% mais eficiente, apresentando um menor
consumo de energia que SOA. Através das análises realizadas, concluiu-se que o meio de
acesso ROA é mais vantajoso quando se utiliza intermediários (gateways) para fornecer
conectividade a sensores que trabalham no contexto de internet das coisas.
2.5.3 NETCONF
Conforme apresentado anteriormente, o protocolo NETCONF tem por objetivo
estabelecer padrões, através de RFCs, para a realização das tarefas de gerência de
configuração de dispositivos de rede através de um conjunto de técnicas e métodos bem
definidos. O trabalho de Sassi et al. (2014) apresenta uma arquitetura de gerência de rede 10
49
Gigabit-Passive Optical Network (10G-PON) que utiliza a linguagem YANG e o protocolo
NETCONF como mecanismo principal para configuração de topologias de redes ópticas
passivas implementadas através de switches com suporte ao protocolo OpenFlow. Observou-
se que a utilização dessa abordagem possibilita o desenvolvimento de aplicações mais
flexíveis e incrementais, permitindo o gerenciamento e a integração de vários dispositivos de
rede (mesmo estes necessitando de parametrizações específicas).
Para Bajpai e Krejci (2014) o protocolo NETCONF agregado ao protocolo
RESTCONF tem sido utilizado como artefato de controle em ambientes Large-Scale
Measurement of Broadband Performance (LMAP) (BURBRIDGE, EARDLEY et al., 2016)
(SCHOENWAELDER; BAJPAI, 2016). O modelo LMAP ainda está em fase de
desenvolvimento pela IETF e converge em um conjunto de componentes que trabalham de
forma coordenada para realizar medições em ambientes heterogêneos de larga escala. Para
atingir a interoperabilidade, desenvolveu-se um cliente NETCONF, utilizando-se da
biblioteca libnetconf (KREJCI, 2013), instalado em um ponto de medição SamKnows
(plataforma baseada em hardware semelhante a um access point que realiza medições ativas
com objetivo de avaliar o desempenho de uma rede de acesso a banda larga). Este cliente
substitui o firmware proprietário e interage com um servidor NETCONF a fim de fornecer os
dados de desempenho de determinado ponto de medição. Avaliou-se que por meio das
características intrínsecas do protocolo NETCONF é possível utilizá-lo como substituto da
abordagem proprietária estabelecida pelo SamKnows para medições de rede.
Uma comparação entre os protocolos SNMP e NETCONF foi realizada por Yu e
Ajarmeh (2010). As tarefas relativas aos testes desenvolvidos foram centradas na gerência de
um servidor VOIP Asterisk por meio da escolha de módulos NETCONF e Management
Information Base (MIBs) SNMP que abrangessem as operações realizadas. As experiências
buscaram avaliar as métricas de número de operações realizadas, tamanho total das
mensagens trocadas e tamanho médio dos pacotes. Para realização dos testes foram utilizados
os protocolos apresentados através de três tarefas realizadas sobre este servidor VOIP, sendo
elas a recuperação de todas as informações de gerenciamento disponíveis no dispositivo, a
recuperação de um único objeto e a alteração de configurações. No que diz respeito ao
número de transações o protocolo NETCONF apresentou um melhor resultado frente ao
SNMP na primeira e na segunda tarefa, pois através de uma única solicitação (get-config)
conseguiu-se recuperar vários objetos (configuração inteira, nesse caso) diferenciando-se do
SNMP que necessitou de várias transações para entregar o resultado final. As experiências
50
relacionadas com o uso da rede apontaram, nas duas tarefas iniciais, que o protocolo
NETCONF apresenta uma maior sobrecarga se comparado ao SNMP, pelo fato de utilizar
uma codificação baseada em uma natureza detalhada por meio de documentos XML para os
dados de configuração e mensagens de protocolo, além da sobrecarga do protocolo SSH2
utilizado como mecanismo de transporte. Especificamente na terceira tarefa não foi realizado
o teste de alteração de configuração utilizando o protocolo SNMP pelo fato de que, no
momento, não existiu uma MIB para objetos graváveis em servidores ASTERIX. Porém,
valendo-se do NETCONF foi possível realizar a configuração de qualquer elemento deste
servidor. Conclui-se que as deficiências inerentes ao consumo de rede apresentado pelo
protocolo NETCONF, quando comparado ao SNMP, são sobrepostas por suas qualidades que
principalmente atuam na garantia da interoperabilidade e segurança na configuração entre
equipamentos de rede distintos.
Nota-se que nos trabalhos relacionados a busca de um método menos consumista
para efetuar o gerenciamento de dispositivos de rede ou das informações geradas por ela é
uma tarefa comum, e que todos compartilham e corroboram a mesma ideia: fornecer um
conjunto de técnicas e padrões bem definidos para contornar a heterogeneidade de
dispositivos e configurações que uma infraestrutura de rede costuma englobar.
Através da utilização das arquiteturas, protocolos e abordagens apresentadas no
decorrer do capítulo 2 – e utilizadas na modelagem e criação de sistemas de gerência nos mais
diferentes contextos como analisado especificamente neste capítulo – o presente trabalho vem
contribuir no estabelecimento da avaliação de desempenho destas técnicas, em um cenário
real construído através do mapeamento das tarefas realizadas na gerência de configuração de
redes. O diferencial apresentado por esta dissertação frente aos trabalhos relacionados é
analisado no comparativo entre as abordagens distribuídas, fornecidas através da
implementação e utilização de ferramentas computacionais baseadas em web services SOAP e
REST, e entre os métodos que utilizam protocolos e formas de acesso específicos –
NETCONF e CLI – para a configuração de equipamentos de interconexão de redes. Além
dessa comparação, são fornecidas alternativas para sobreposição dos problemas apresentados
pela variabilidade semântica no momento da configuração desses equipamentos – fato esse
atribuído à heterogeneidade de hardware encontrada nas redes de computadores.
51
3 COMPARAÇÃO DAS ESTRATÉGIAS PARA GERÊNCIA DE
CONFIGURAÇÃO DE REDES
Finalizada a fundamentação teórica das tecnologias, arquiteturas e protocolos que
servirão de base para o desenvolvimento das ferramentas computacionais utilizadas na
comparação, este capítulo apresenta a metodologia (arquitetura, definições e cenário)
empregada para o desenvolvimento da proposta. Nas próximas seções serão definidas as
arquiteturas e descritas as tarefas de gerência de configuração, bem como o mapeamento
dessas em aplicações através de métodos, serviços e recursos para atendimento aos objetivos
específicos. Dando sequência ao capítulo, serão apresentados os equipamentos empregados
tanto para a composição da topologia de rede quanto para o deploy das aplicações
implementadas. Após a montagem do cenário serão definidas as métricas empregadas para a
avaliação de desempenho de cada tarefa, bem como as ferramentas para coleta dos dados que
serão utilizadas na comparação do custo efetivo de cada estratégia. Na última seção do
capítulo é realizada a descrição dos testes executados para cada estratégia. Cabe salientar que
as especificações de cenário, aplicações e equipamentos apresentados neste capítulo visam
garantir a futura reprodutibilidade do ambiente.
3.1 DEFINIÇÃO DA ARQUITETURA DO SISTEMA
Em atendimento aos requisitos impostos pelos objetivos específicos, fazendo com
que as comparações entre as estratégias escolhidas possam ser executadas, foi necessária a
construção de um sistema composto de aplicações distintas. O bubble map apresentado na
figura 8 ilustra a arquitetura do sistema que é segmentada e organizada em duas camadas,
quatro aplicações e duas Applications Programming Interfaces – Interface de Programação de
Aplicativos (APIs).
52
Figura 8 – Definição da arquitetura do sistema.
Fonte: Elaborado pelo autor.
Nota: * Secure Shell Version 2 – Shell Seguro Versão 2 (SSH-2).
De acordo com a figura 8, o sistema é dividido como segue:
camada de apresentação – responsável por oferecer diferentes perspectivas
de acesso através de aplicações que se valem de serviços e recursos providos
pelas arquiteturas SOA e ROA por meio de web services SOAP e REST,
respectivamente, e também de métodos NETCONF. Como será apresentado
na camada de acesso a seguir, desenvolveu-se uma API que tem por objetivo
intermediar a execução utilizando a Command Line Interface – Interface de
Linha de Comando (CLI) do dispositivo para as tarefas quando o acesso
ocorrer por meio de web services. Com a utilização da referida API analisou-
se também, durante a definição da arquitetura, a possibilidade de simular por
meio de software individual as tarefas de gerência de configuração de
dispositivos de rede, transformando estas em métodos automatizados
passíveis de medição. Para isso foi criada uma aplicação denominada CLI que
compõe, junto a outras três (NETCONF e web services REST e SOAP) o
cenário de testes. É por meio da camada de apresentação que os usuários ou
aplicações (que venham a consumir os web services) executam as tarefas de
53
gerência de configuração no dispositivo de rede, fazendo com que as
particularidades da variabilidade semântica de comandos e tratamento de
erros sejam abstraídas;
camada de acesso – camada que contém a lógica do negócio – formas de
conexão e mapeamento de comandos CLI e NETCONF – sendo divida em
duas APIs. A API CLI é responsável por intermediar as requisições das
aplicações, tendo como objetivo conectar-se através do protocolo SSH-2 ao
equipamento de rede e executar a devida tarefa por meio de uma série de
comandos CLI. Ao final da execução a API devolve o retorno aos métodos no
caso da aplicação CLI ou aos web services SOAP/REST dispostos na camada
de apresentação. Para a API NETCONF o modo de operação é basicamente o
mesmo, diferenciando-se no fato de que para esta foram utilizados os
mecanismos padronizados nas camadas de transporte, mensagem e operação
estabelecidos pela RFC 6241. Ao final da camada de acesso, tanto a API CLI
quanto a API NETCONF (esta última por meio da RFC 6242) equalizam-se
fazendo uso do mesmo protocolo, SSH-2, na conexão ao dispositivo de rede.
A modularidade imposta pela arquitetura do sistema tem o objetivo de realizar a
separação em quatro aplicações distintas que controlam as formas de acesso durante a
invocação das tarefas de gerência de configuração; entretanto, em um ponto comum e
valendo-se do reuso de código na camada de acesso, compartilham as mesmas APIs para
acesso, através do protocolo SSH-2, ao dispositivo de rede. Por meio desse reuso as
aplicações podem ser utilizadas por usuários ou consumidas por outras aplicações no caso dos
web services SOAP e REST; assim, as estratégias definidas e utilizadas na comparação
proposta são apresentadas em quatro aplicações baseadas em web services REST e SOAP, e
na simulação através de software quando do acesso por CLI e NETCONF. O presente
trabalho tratará os termos estratégias e aplicações de forma análoga no decorrer das próximas
seções. Baseando-se nos princípios das arquiteturas utilizadas por este trabalho uma segunda
definição será empregada: os termos web services SOAP ou REST e estratégias SOA ou
ROA, respectivamente, também serão tratados de maneira análoga.
54
3.2 DEFINIÇÃO DAS TAREFAS DE GERÊNCIA DE CONFIGURAÇÃO
Posterior à definição das estratégias, que se deu por meio de aplicações distintas
como apresentado na seção 3.1, elencaram-se as tarefas pertinentes à área funcional do
modelo FCAPS que trata exclusivamente da gerência de configuração, comumente executadas
pelos administradores de redes em seu cotidiano. Essas tarefas, enumeradas por um
identificador e definidas por um escopo de utilização, são apresentadas no quadro 1.
Quadro 1 – Levantamento das tarefas de gerência de configuração de redes.
ID1 Tarefa Escopo de utilização
1 Recuperação da configuração
geral Retorna a configuração corrente do roteador.
22 Recuperação de todas as VLANs
Retorna uma listagem de todas as VLANs contendo: VLANid, name e
status.
3 Recuperação de VLAN
específica
Retorna as configurações de uma VLAN específica contendo: VLANid,
name e status.
4 Criação de VLAN Informa os parâmetros vlanid, name e status para criação de uma nova
VLAN.
5 Alteração de estado de VLAN Altera o estado de uma VLAN entre active ou suspend.
6 Alteração de nome de VLAN Altera o nome de uma VLAN.
7 Exclusão de VLAN Exclui uma VLAN baseado no identificador (id) passado como
parâmetro.
83
Recuperação da tabela de
roteamento estático
Retorna uma listagem da tabela de roteamento estático com as redes e
seus respectivos gateways.
9 Criação de rota estática
Informa os parâmetros destination, destinationPrefixMask e
forwardingRoutersAddress para criação de uma nova rota na tabela de
roteamento.
10 Exclusão de rota estática Exclui uma entrada na tabela de roteamento baseado em destination e
destinationPrefixMask passados como parâmetro.
11 Recuperação das configurações
de interface
Retorna as configurações de uma porta específica passada como
parâmetro.
12 Configuração de interface Configura uma interface de rede através dos parâmetros port,
interfaceAddress, subnetMask, MTU e description.
13 Ativação de interface Ativação da interface de rede do roteador.
14 Desativação de interface Desativação da interface de rede do roteador.
Fonte: Elaborado pelo autor.
Nota: 1 Identificador (ID).
Anterior à execução das tarefas 2 e 8 e com o objetivo de simular um cenário de produção foram criadas
no roteador da marca Cisco modelo 2921: 2
48 VLANs (número máximo suportado pelo equipamento); 3
200 rotas estáticas no roteador (número máximo suportado pelo equipamento).
Após a execução dessas duas tarefas as VLANs e rotas criadas sinteticamente foram excluídas,
retornando a uniformidade do ambiente.
Após a definição das tarefas foi necessário realizar o cruzamento dessas com seus
devidos comandos CLI e NETCONF. O quadro 2 apresenta a listagem dos comandos CLI
responsáveis por executar as tarefas apresentadas no quadro 1. Os comandos não listados
neste quadro são encontrados no APÊNDICE A.
55
Quadro 2 – Comandos CLI responsáveis pelas tarefas 1, 2 e 12.
Tarefa Comando CLI
1 show running-config
2 show vlan-switch brief
12
conf t
interface GigabitEthernet interface
ip address address subnetMask
mtu MTU
description DESCRIPTION
no shutdown
end
Fonte: Elaborado pelo autor.
Nota: Os trechos de configuração realçados em negrito são substituídos por parâmetros de métodos no
momento da implementação.
Para o protocolo NETCONF, que se utiliza da linguagem de marcação XML nas
camadas de mensagem, operação e conteúdo, os comandos de gerência de configuração são
apresentados no quadro 3. As tarefas não listadas neste quadro são encontradas no
APÊNDICE B.
Quadro 3 – Comandos NETCONF responsáveis pelas tarefas 1, 2 e 12.
ID Comando NETCONF
1
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>]]>]]>
2
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter>
<oper-data-format-text-block>
<show>vlan-switch</show>
</oper-data-format-text-block>
</filter>
</get>
</rpc>]]>]]>
12
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<cli-config-data>
<cmd>interface GigabitEthernet interface</cmd>
<cmd>ip address address subnetMask</cmd>
<cmd>mtu MTU</cmd>
<cmd>description DESCRIPTION</cmd>
</cli-config-data>
</config>
</edit-config>
</rpc>]]>]]>
Fonte: Elaborado pelo autor.
Nota: Os trechos de configuração realçados em negrito são substituídos por parâmetros de métodos no
momento da implementação.
Além da sintaxe XML apresentada por todos os comandos NETCONF, nota-se
também na segunda linha de cada tarefa o elemento <rpc> que apresenta o modelo de
56
comunicação baseado no paradigma Remote Procedure Call – Chamada de Procedimento
Remoto (RPC), onde um cliente (aplicação) codifica uma requisição RPC e a envia para um
servidor (dispositivo de rede) com um atributo de identificação obrigatório denominado
message-id, também apresentado em cada tarefa NETCONF.
Seguindo os preceitos apresentados pela RFC 6241 que orientam o protocolo
NETCONF, a camada de conteúdo também é definida em formato XML; porém, não é
dependente de um padrão pré-estabelecido. Tomando por base a utilização do equipamento de
rede que irá compor o cenário de testes (um roteador da marca Cisco modelo 2921 que será
especificado nas seções seguintes), buscou-se em um primeiro momento a utilização da
linguagem YANG para a modelagem da camada de conteúdo, porém sem êxito. Foi
identificado então que a empresa Cisco, para esse equipamento, encapsula durante a execução
de algumas tarefas NETCONF os comandos CLI dentro de tags XML baseada em uma
definição proprietária4,5
. Graças à divisão de camadas apresentada pelo protocolo NETCONF
e, mesmo a camada de conteúdo sendo proprietária (fato permitido pelo padrão), a utilização
do referido protocolo como forma de comparação para este trabalho é válida, pois para o
equipamento suportar NETCONF deve basear-se única e exclusivamente nas imposições
estabelecidas pelas camadas de transporte, mensagem e operação.
As tarefas e comandos elencados nos quadros 1, 2 e 3 serão utilizados na
implementação das estratégias expostas na seção 3.3.
3.3 COMPOSIÇÃO DAS ESTRATÉGIAS
A implementação das estratégias em aplicações individuais e que tem como objetivo
compor a montagem do cenário de testes serão apresentadas nesta seção.
3.3.1 Mapeamento e Desenvolvimento
Após a definição das tarefas de gerência de configuração e de seus comandos foi
realizado o mapeamento dessas tarefas dentro de cada estratégia, apresentadas na seção 3.1.
O objetivo do mapeamento especificado no quadro 4 foi o de levantar e testar os
comandos CLI e NETCONF no equipamento alvo para cada uma das 14 tarefas elencadas no
4 http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cns/configuration/15-mt/cns-15-mt-book.pdf
5 http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cns/configuration/15-mt/cns-15-mt-book/cns-netconf.html
57
quadro 1 da seção 3.2, e apresentar a matriz utilizada como base para a execução das
comparações.
Quadro 4 – Mapeamento das tarefas dentro de cada estratégia.
ID Tarefa
Estratégias
Web Services Métodos
REST SOAP CLI NETCONF
1 Recuperação da configuração geral S S S S
2 Recuperação de todas as VLANs S S S S
3 Recuperação de VLAN específica S S S S
4 Criação de VLAN S S S
N 5 Alteração de estado de VLAN S S S
6 Alteração de nome de VLAN S S S
7 Exclusão de VLAN S S S
8 Recuperação da tabela de roteamento estático S S S S
9 Criação de rota estática S S S S
10 Exclusão de rota estática S S S S
11 Recuperação das configurações de interface S S S S
12 Configuração de interface S S S S
13 Ativação de interface S S S S
14 Desativação de interface S S S S
Fonte: Elaborado pelo autor.
Nota: Legenda S: Tarefa passível de automação;
N: Tarefa que não apresenta suporte através do protocolo NETCONF no equipamento utilizado para
montagem do ambiente de testes.
A realização desse cruzamento culminou no posterior desenvolvimento das
aplicações utilizadas pela proposta. Para cada tarefa e estratégia foi necessário implementar,
em conjunto às APIs, os métodos e web services quantificados abaixo:
14 métodos CLI;
10 métodos NETCONF (as tarefas de 4 a 7 não apresentam suporte no
equipamento conforme especificado no quadro 4);
14 web services SOAP (um para cada tarefa);
14 web services REST (um para cada tarefa).
Cabe salientar que cada tarefa mapeada tem seu retorno – resultado da execução do
método ou web service – baseado na sua arquitetura ou protocolo. O formato de retorno
definido para cada estratégia é apresentado no quadro 5.
58
Quadro 5 – Definição do formato de retorno do resultado para cada estratégia.
Estratégia Tipo de retorno ao usuário ou aplicação
REST JSON
SOAP XML
CLI TEXTO PURO1
NETCONF XML
Fonte: Elaborado pelo autor.
Nota: 1O tipo de retorno ―texto puro‖ refere-se ao fato do retorno não ser encapsulado em outro tipo ou formato
de dado, sendo apresentado da forma original enviada pelo dispositivo de rede.
Para o desenvolvimento de todas as aplicações e APIs, observadas tanto na camada
de apresentação quanto na camada de acesso, foram utilizadas as seguintes tecnologias:
kit de desenvolvimento – linguagem de programação Java da empresa
Oracle para Microsoft Windows x64 através do Java Development Kit (JDK)
na versão 1.8.0_516;
ambiente de execução – Java Runtime Environment (JRE) na versão 8u51-
b167;
ambiente de desenvolvimento – Integrated Development Environment –
Ambiente Integrado de Desenvolvimento (IDE) NetBeans na versão 8.0.2
(Build 201411181905)8.
3.3.1.1 APIs: implementações intermediárias
Com o objetivo de oferecer suporte e intermediar as requisições das estratégias
apresentadas anteriormente foi necessário desenvolver duas APIs, localizadas na camada de
acesso como apresentado na figura 8, que atendessem tanto às aplicações baseadas em Web
Services (WS) REST e SOAP quanto CLI e NETCONF. Essas APIs trabalham, em nível de
camada de acesso, como se fossem gateways entre as aplicações e o dispositivo de rede a ser
gerenciado. Intrínseco a elas estão a responsabilidade de conter o mapeamento dos comandos
CLI e NETCONF relativos às tarefas de gerência de configuração elencadas no quadro 1 da
seção 3.2, automatizando assim a sua execução.
Para realizar a conexão entre as APIs e o equipamento de rede foi utilizada a
biblioteca Ganymed SSH-29 disponível sob uma licença New BSD License, que traz uma
implementação do protocolo SSH-2 baseada na linguagem Java.
6 http://download.oracle.com/otn/java/jdk/8u51-b16/jdk-8u51-windows-x64.exe
7 http://download.oracle.com/otn/java/jdk/8u51-b16/jre-8u51-windows-x64.exe
8 http://download.netbeans.org/netbeans/8.0.2/final/bundles/netbeans-8.0.2-windows.exe
59
Como exemplo, no trecho de código do quadro 6 tem-se a simulação por meio de
software para a tarefa de número 12, a qual objetiva a configuração de uma interface (porta)
de rede através dos parâmetros port, interfaceAddress, subnetMask, MTU e description por
meio de um método disposto na API CLI. Esses parâmetros em conjunto a um objeto do tipo
Router fornecem, após a execução do método, uma nova configuração para a interface de rede
desejada.
Quadro 6 – Mapeamento da configuração de interface de rede através da API CLI. /**
* Método responsável pela execução da configuração de uma interface
* de rede através da CLI
* @param router - Objeto que contém o host (endereço IP), usuário e senha
* @param port
* @param address
* @param subnetMask
* @param MTU
* @param description
* @return String - Contendo o spool do dispositivo após a execução dos comandos
*/
public static String configureInterface(Router router, String port, String address,
StringsubnetMask,String MTU, String description) {
//Crio um array para empilhar os comandos
List<String> comandos = new ArrayList<>();
comandos.add("conf t");
comandos.add("interface GigabitEthernet " + port);
comandos.add("ip address " + address + " " + subnetMask);
comandos.add("mtu " + MTU);
comandos.add("description " + description);
comandos.add("no shutdown");
comandos.add("end");
//Crio um StringBuilder de retorno
StringBuilder sb = new StringBuilder();
try {
//Chamo a função responsável por executar os comandos
sb = ExecMultipleCommands.RunMultipleCommands(router, comandos);
} catch (ExceptionSSHConnection ex) {
System.out.println(ex.getMessage());
} catch (Exception exa) {
System.out.println(exa.getMessage());
}
//Faço o replace para devolver a resposta já formatada com as quebras de linhas
//idênticas ao acesso via CLI realizado manualmente
return sb.toString().replaceAll("@", "\n");
}
Fonte: Elaborada pelo autor.
Para execução do método apresentado pelo quadro 6, primeiramente deve-se realizar
a conexão com o dispositivo de rede. O trecho de código apresentado no quadro 7 demonstra
a realização dessa conexão através do protocolo SSH-2. Esse método recebe como parâmetro
um objeto do tipo device que contém os atributos host, user e password. Nota-se nesse trecho
a orientação a objetos na extensão das classes que tratam dos objetos routers e devices
(Router extends Device), pois todo roteador é um dispositivo de rede, com características
específicas, mas nem todo dispositivo de rede é um roteador. Nesse caso a realização da
9 https://code.google.com/archive/p/ganymed-ssh-2/
60
conexão SSH-2 é genérica, servindo para qualquer dispositivo de rede – tomando como
padrão a porta 22 para o estabelecimento da conexão.
Quadro 7 – Conexão com o dispositivo de rede através da API CLI. /**
* Método responsável por realizar a conexão com o dispositivo de rede através
* do protocolo SSH
* @param device - Objeto que contém o host (endereço IP), usuário e senha
* @return Connection - Um objeto contendo a conexão aberta
* @throws IOException
*/
public static Connection getConnection(Device device) throws IOException {
//Crio um novo objeto conexão e informo o host
Connection conn = new Connection(device.getHost());
conn.connect();
//Conecto no dispositivo de rede informando usuário e senha
boolean isAuthenticated = conn.authenticateWithPassword(device.getUser(),
device.getPassword());
//Verifico se a autenticação foi realizada
if (isAuthenticated == false) {
throw new IOException("Autenticação falhou.");
}
//Retorno um objeto contendo a conexão realizada.
return conn;
}
Fonte: Elaborada pelo autor.
Entretanto, para executar uma tarefa de gerência de configuração no dispositivo,
além de realizar a conexão é necessário abrir uma sessão SSH-2 emulando um terminal
virtual. Essa operação é apresentada no quadro 8 e realizada no mesmo método responsável
por enviar e executar os comandos no roteador. Após o envio e a execução desses comandos o
parâmetro de retorno é encapsulado em um objeto contendo todo o spool oriundo do
dispositivo de rede. Durante a comunicação entre a API CLI e o dispositivo de rede existem
basicamente duas trocas de mensagens: o envio dos comandos e o recebimento das respostas,
diferenciando-se da API NETCONF onde a troca de mensagens em uma mesma sessão é
intermitente, cessando e recomeçando por intervalos definidos pelos agentes e tipos de
mensagens trocadas.
Quadro 8 – Método responsável pela execução dos comandos através da API CLI. /**
* Método responsável por executar os comandos passados
* como parâmetro para o roteador
* @param connection
* @param outputListener
* @param commands
* @return StringBuilder - Contendo o retorno dos comandos executados no roteador
* @throws IOException
* @throws UnsupportedEncodingException
*/
private static StringBuilder execCommands(Connection connection,
OutputStream outputListener,
List<String> commands)
throws IOException,UnsupportedEncodingException {
//Crio um StringBuilder de saída
StringBuilder output = new StringBuilder();
//Utilizo a conexão criada para abrir uma sessão
Session session = connection.openSession();
try {
//Emulo um terminal virtual VT100
session.requestPTY("VT100", Integer.MAX_VALUE, Integer.MAX_VALUE,0,0,null);
61
//Inicio a shell desse terminal
session.startShell();
//Crio um stream para escrever os comandos na entrada na sessão
OutputStreamWriter writer = null;
writer = new OutputStreamWriter(session.getStdin(), "utf-8");
//Itero nos comandos passados como parâmetros e escrevo
//na entrada da sessão
for (String temp : commands) {
writer.write(temp);
writer.flush();
}
//Leio o spool oriundo do roteador após a execução dos comandos
output = ConnectionReturns.getOutput(session, outputListener);
//Finalizo o stream
writer.close();
//Finalizo a sessão
} finally {
session.close();
}
//Dou o retorno do método com o spool
return output;
}
Fonte: Elaborada pelo autor.
O diagrama contendo algumas classes utilizadas pela API CLI é apresentado na
figura 9.
Figura 9 – Diagrama de classes da API CLI.
Fonte: Elaborado pelo autor.
Durante o desenvolvimento da API NETCONF foi necessário alterar os
procedimentos de abertura de conexão e sessão, motivado pelo fato de que quando uma sessão
é aberta entre os pares (cliente/aplicação – servidor/dispositivo de rede) é realizada uma troca
de mensagens como apresentado na seção 2.1.2.3. Caso não seja respeitada a sequência e
62
estrutura dessa comunicação, a conexão não é estabelecida. Com a necessidade de manter
uma sessão aberta durante essa troca de mensagens, foi utilizado um design pattern (padrão
de projeto) chamado singleton, implementando assim uma fábrica de conexões e sessões de
forma a limitar a existência de uma única instância para cada objeto.
O trecho de código apresentado no quadro 9 define a classe responsável pela criação
da fábrica de conexões. Com a utilização dessa fábrica, e caso uma conexão já tenha sido
realizada para a execução de algum comando, somente o objeto preexistente é retornado; do
contrário, é iniciado o procedimento de conexão similar à API CLI.
Quadro 9 – Fábrica de conexões da API NETCONF. /***
* Classe responsável pela fábrica de conexões implementando o padrão
* de projeto singleton
* @author giv-NB
*/
public class ConnectionFactory {
//Declaro o objeto do tipo Connection como público e passível de ser reaproveitado
public static Connection con;
/***
* Método responsável por realizar a conexão com o dispositivo
* de rede através do protocolo SSH-2
* mantendo somente uma instância para o objeto
* @param device
* @return Connection - Um objeto contendo a conexão aberta
* @throws IOException
*/
public static Connection getConnection(Device device) throws IOException {
//Se o objeto estiver nulo
if (con == null) {
//Crio um novo objeto conexão e informo o host
con = new Connection(device.getHost());
//Conecto no dispositivo de rede informando usuário e senha
con.connect();
boolean isAuthenticated = con.authenticateWithPassword(device.getUser(),
device.getPassword());
//Verifico se a autenticação foi realizada e retorno um
//objeto contendo a conexão.
if (isAuthenticated == false) {
throw new IOException("Autenticação falhou.");
}
return con;
//Se o objeto não estiver nulo então a conexão para a execução
//corrente já foi realizada logo retorno o objeto criado
} else {
return con;
}
}
}
Fonte: Elaborada pelo autor.
A mesma analogia da fábrica de conexões foi utilizada na criação das sessões,
diferenciando-se da API CLI pelo fato de que a sessão é delegada a uma classe separada e não
dentro de um método responsável pela execução dos comandos. Outra característica que a
diferencia da API CLI foi a utilização do subsistema10
NETCONF para estabelecer a sessão
com o dispositivo de rede, firmando assim o uso desse protocolo durante a troca de
10
https://manpages.debian.org/cgi-bin/man.cgi?query=ssh&apropos=0&sektion=0&manpath=Debian+8+jessie&format=html&locale=en
63
mensagens entre os pares. A metodologia aplicada na fábrica de sessões é apresentada no
quadro 10.
Quadro 10 – Fábrica de sessões da API NETCONF. /**
* Classe responsável pela fábrica de sessões NETCONF
* implementando o padrão de projeto singleton
* @author giv-NB
*/
public class SessionFactory {
//Declaro o objeto do tipo Session como público e passível de ser reaproveitado
public static Session session;
/**
* Método responsável por iniciar a sessão com o dispositivo de rede
* através do protocolo SSH-2
* @param connection
* @return Session - Um objeto contendo uma sessão aberta
* utilizando o protocolo NETCONF
* @throws IOException
*/
public static Session getSession(Connection connection) throws IOException {
//Se o objeto estiver nulo
if (session == null) {
//Abro a sessão
session = connection.openSession();
//E ao invês de utilizar VT100 (da API CLI) inicio o subsistema para
//trabalhar com o protocolo NETCONF
session.startSubSystem("netconf");
//Retorno a sessão ao método
return session;
//O objeto já está criado então somente o retorno
} else {
return session;
}
}
}
Fonte: Elaborada pelo autor.
O envio e a execução de comandos através da API NETCONF são apresentados pelo
método execCommands do quadro 11. Diferente da API CLI, esse método utiliza a fábrica de
sessões para estabelecer uma comunicação com o dispositivo de rede e envia uma mensagem
(comando) por vez, respeitando a sequência de troca de mensagens imposta pelo protocolo
NETCONF. Cabe à aplicação NETCONF, hospedada na camada de apresentação, organizar e
sequenciar essa troca de mensagens.
Quadro 11 – Método responsável pela execução de comandos através da API
NETCONF. /***
* Método responsável por executar os comandos NETCONF,
* passados como parâmetro, no roteador
* @param connection
* @param outputListener
* @param commands
* @return StringBuilder - Contendo o spool do dispositivo após a execução dos comandos
* @throws IOException
* @throws UnsupportedEncodingException
*/
private static StringBuilder execCommands(Connection connection,
OutputStream outputListener,
String commands)
throws IOException,UnsupportedEncodingException {
//Crio um StringBuilder de saída
StringBuilder output = new StringBuilder();
//Utilizo a fábrica de sessões para início da sessão SSH-2 pelo subsistema NETCONF
Session session = SessionFactory.getSession(connection);
64
try {
//Crio um stream para escrever os comandos na entrada da sessão
OutputStreamWriter writer = null;
writer = new OutputStreamWriter(session.getStdin(), StandardCharsets.UTF_8);
//Escrevo o comando na entrada da sessão -
//Como só vem um XML por vez não preciso iterar
writer.write(commands + "\n");
writer.flush();
//Leio o spool oriundo do roteador após a execução do comando
output = ConnectionReturns.getOutput(session, outputListener);
//Fecho o stream mas não finalizo a sessão
writer.close();
}
//Dou o retorno do método com o spool
return output;
} Fonte: Elaborada pelo autor.
Outro ponto que difere a API NETCONF da API CLI é de que os comandos
imutáveis estão dispostos em constantes e não em métodos – ver quadro 12. Para os
comandos variáveis, que necessitam da substituição das informações estruturais, a aplicação
NETCONF realiza a modificação para que uma demanda específica possa ser atendida – por
exemplo, a criação de uma rota ou a configuração individual de uma interface de rede.
Quadro 12 – Declaração das constantes utilizadas pela API NETCONF. /**
* Classe responsável por abrigar as constantes (comandos NETCONF)
* utilizados para gerência de configuração
* @author giv-NB
*/
public class NETCONFConstants {
//Hello enviado para estabelecimento da comunicação
public static String hello
= "<?xml version=\"1.0\" encoding=\"UTF-8\"?>"
+ "<hello xmlns=\"urn:ietf:params:xml:ns:netconf:base:1.0\">\n"
+ "<capabilities>\n"
+ "<capability>urn:ietf:params:netconf:base:1.0</capability>\n"
+ "<capability>urn:ietf:params:netconf:capability:writeable-running:1.0</capability>\n"
+ "<capability>urn:ietf:params:netconf:capability:startup:1.0</capability>\n"
+ "<capability>urn:ietf:params:netconf:capability:url:1.0</capability>\n"
+ "<capability>urn:cisco:params:netconf:capability:pi-data-model:1.0</capability>\n"
+ "<capability>urn:cisco:params:netconf:capability:notification:1.0</capability>\n"
+ "</capabilities>\n"
+ "</hello>]]>]]>\n";
//Recuperação da configuração geral
public static String getRunningConfigurationRouter
= "<?xml version=\"1.0\" encoding=\"UTF-8\\?>\n"
+ "<rpc message-id=\"101\" xmlns=\"urn:ietf:params:xml:ns:netconf:base:1.0\">\n"
+ "<get-config>\n"
+ " <source>\n"
+ " <running/>\n"
+ " </source>\n"
+ " </get-config>\n"
+ "</rpc>]]>]]>";
} Fonte: Elaborada pelo autor.
O diagrama contendo algumas classes utilizadas pela API NETCONF é apresentado
na figura 10.
65
Figura 10 – Diagrama de classes da API NETCONF.
Fonte: Elaborado pelo autor.
As seções 3.3.1.2 e 3.3.1.3 tratam exclusivamente das especificações utilizadas no
desenvolvimento das aplicações baseadas em web services, que utilizam como norteadores os
conceitos das arquiteturas ROA e SOA e também da simulação, por meio de software, para o
acesso através da CLI e do protocolo NETCONF no gerenciamento de dispositivos de rede.
3.3.1.2 Estratégia baseada em web services REST e SOAP
O desenvolvimento das aplicações baseadas em web services REST e SOAP seguiu
os preceitos estabelecidos pelas arquiteturas ROA e SOA, respectivamente.
Para a composição dos web services REST foi necessário dividir as tarefas,
apresentadas no quadro 1 da sessão 3.2, em recursos. Valendo-se da ideia de que os recursos
não são os dados em si, mas sim uma informação abstrata de uma entidade (aqui, um
dispositivo de rede), agrupou-se essas tarefas em quatro recursos, sendo eles: configuração,
VLAN, tabela de roteamento estático e interface. A exposição do estado atual ou desejado
desses recursos foi definida através da utilização de representações no formato JSON,
ocultando assim aspectos internos da sua implementação. Já as referências a essas
representações são realizadas através de URIs que nomeiam esses recursos. O quadro 13
66
apresenta a transformação dessas tarefas de gerência de configuração em web services REST.
As tarefas não listadas nesse quadro são encontradas no APÊNDICE C.
Quadro 13 – Tarefas de gerência de configuração transformadas em web services REST.
ID Recurso URI Método
HTTP
Tipos e nomes de parâmetros da
URI
1 CONFIG /{address}/configuration/runnning/ GET Path {address}
2 VLAN /{address}/vlan/all GET Path {address}
4 VLAN /{address}/vlan/{vlanid} PUT
Path {address}
{vlanid}
Query name
status
7 VLAN /{address}/vlan/{vlanid} DELETE Path {address}
{vlanid}
8 TBRE /{address}/routes/static GET Path {address}
11 IFACE /{address}/ports/{port}/ GET Path {address}
{port}
12 IFACE /{address}/ports/{port}/ PUT
Path {address}
{port}
Query
interfaceAddress
subnetMask
MTU
description
Fonte: Elaborado pelo autor.
Nota: Legenda para a coluna denominada recurso: CONFIG: Configurações do dispositivo de rede;
VLAN: Virtual Lans – Rede Local Virtual (VLANs);
TBRE: Tabela de Roteamento Estático;
IFACE: Interface de rede.
Legenda para a coluna denominada tipos e nomes de parâmetros da URI:
Path: Parâmetros inseridos diretamente na URI;
Query: Parâmetros adicionais passados explicitamente na URI e inseridos após o sinal de interrogação
(?).
O quadro 13, além de demonstrar a estrutura (forma) de aceso aos web services
REST, apresenta as condições norteadoras elencadas na seção 2.4.2 para os princípios desse
estilo arquitetural. A definição de como as representações são acessadas e as operações
básicas realizadas sobre elas é dada pela interface uniforme e apresentada pela coluna
denominada método HTTP do quadro 13. Os parâmetros do tipo Path – identificados pela
anotação @PathParam nos trechos de códigos dos web services (WS) REST – são inseridos
diretamente na URI; já os parâmetros do tipo Query são atributos adicionais – identificados
pela anotação @QueryParam – adicionados na query string da URI (contendo os dados do
recurso que não são convenientes de serem adicionados a estrutura do seu caminho
hierárquico). A separação através desses parâmetros foi necessária para não alongar a URI aos
olhos do usuário, possibilitar o seu encadeamento, deixá-la clara, bem definida e tornar a
aplicação endereçável. Cabe salientar que os métodos HTTP PUT e DELETE das tarefas 4, 7
e 12, apresentados pela interface uniforme, são tratados de forma idempotente seguindo
67
também as orientações de REST. Os web services REST foram desenvolvidos de forma a não
manter o estado da aplicação; com isso nenhuma informação do lado do servidor é
armazenada, fazendo com que todos os dados necessários para que a solicitação seja atendida
sejam enviados através da URI ou por meio de parâmetros de cabeçalho.
O trecho de código apresentado no quadro 14 demonstra o mapeamento da tarefa 1
em um WS REST. Para esse WS é utilizado o método GET do HTTP (anotação @GET) com
o objetivo de obter as configurações (representação de um recurso no formato JSON através
da anotação @Produces("application/json")) em execução no roteador por meio da classe
RouterFunctions e do método getRunningConfigurationRouter disponibilizada pela API CLI
na camada de acesso e disposta no diagrama de classes da figura 9. Os atributos user e
password passados como parâmetro nesses métodos foram anonimizados, através de strings
de mesmo nome, nos códigos que detém essas características.
Quadro 14 – WS REST que retorna as configurações de um dispositivo de rede. /**
* Método responsável por obter as configurações de um dispositivo de rede
* @param address
* @return String - Contendo uma representação no formato JSON com o spool
* oriundo do roteador mediante a execução do comando
*/
@GET
@Path("/{address}/configuration/runnning/")
@Produces("application/json")
public String RunningConfiguration(@PathParam("address") String address) {
//Crio um novo objeto do tipo Router passando como parâmetro seu endereço
Router router = new Router(address, "user", "password");
//Executo o método da camada de acesso reponsável por obter
//a configuração geral do roteador
return RouterFuntions.getRunningConfigurationRouter(router);
}
Fonte: Elaborado pelo autor.
A configuração de uma interface (porta) de rede de um dispositivo é apresentada no
quadro 15. Nesse trecho de código é observada a utilização da interface uniforme por meio do
método HTTP PUT, que trata da criação/atualização completa de um recurso (porta) oferecida
pelo método de aplicação denominado configureInterface e apresentado no quadro 6.
Quadro 15 – WS REST que configura uma interface de rede. /**
* Método responsável por configurar uma interface (recurso) de rede no
* dispositivo de rede
* @param address
* @param port
* @param interfaceAddress
* @param subnetMask
* @param MTU
* @param description
* @return String - Contendo uma representação no formato JSON com o spool
* oriundo do roteador mediante a execução do comando
*/
@PUT
@Path("/{address}/ports/{port}/")
@Produces("application/json")
public String configureInterface(@PathParam("address") String address,
68
@PathParam("port") String port,
@QueryParam("interfaceAddress") String interfaceAddress,
@QueryParam("subnetMask") String subnetMask,
@QueryParam("MTU") String MTU, @QueryParam("description") String description) {
//Crio um novo objeto do tipo Router passando como parâmetro seu endereço
Router router = new Router(address, " user ", "password");
//Executo o método da camada de acesso reponsável por configurar a interface
//passando os devidos parâmetros
return RouterFuntions.configureInterface(router, "0/" + port, interfaceAddress,
subnetMask, MTU, description);
} Fonte: Elaborado pelo autor.
O quadro 16 apresenta o método deleteRoute. Através desse método, implementado
dentro de um WS REST de mesmo nome e por meio da interface uniforme DELETE, é
realizada a exclusão de uma entrada na tabela de roteamento estático no dispositivo de rede.
Quadro 16 – WS REST que exclui uma entrada na tabela de roteamento estático. /**
* Método responsável por excluir uma entrada da tabela de roteamento
* @param address
* @param destination
* @param destinationPrefixMask
* @return String - Contendo uma representação no formato JSON com o spool
* oriundo do roteador mediante a execução do comando
*/
@DELETE
@Path("{address}/routes/static/{destination}")
@Produces("application/json")
public String deleteRoute(@PathParam("address") String address,
@PathParam("destination") String destination,
@QueryParam("destinationPrefixMask") String destinationPrefixMask) {
//Crio um novo objeto do tipo Router passando como parâmetro seu endereço
Router router = new Router(address, "user", " password");
//Executo o método da camada de acesso reponsável por
//excluir uma entrada da tabela de roteamento
return RouterFuntions.deleteRoute(router, destination, destinationPrefixMask);
} Fonte: Elaborado pelo autor.
Diferente dos WS REST, onde as tarefas foram mapeadas em recursos, os WS SOAP
valem-se dessa divisão através de serviços, levando em consideração a transformação de uma
funcionalidade de negócio relacionada às tarefas de gerência de configuração.
Os componentes da arquitetura SOA utilizados neste trabalho são o service provider
(provedor de serviço) e o service consumer (consumidor de serviço). As especificações de
hardware desses componentes serão definidas na seção 3.4 que trata do cenário de testes. No
contexto desta dissertação a responsabilidade do provedor de serviço é de ser o componente
que torna os serviços (tarefas) passíveis de serem executados. Já o consumidor de serviço
(cliente) é o componente responsável por consultar a existência de serviços e invocá-las para a
execução de uma determinada tarefa de gerência de configuração de redes. Cabe salientar que
no cenário montado para este trabalho, o componente service registry (registro de serviço) foi
suprimido, logo as interações entre provedores e consumidores são realizadas sem
intermediações.
69
Através dessa arquitetura é abstraída a implementação interna do serviço por parte do
provedor, pois o consumidor invoca somente as interfaces fornecendo os parâmetros, quando
necessário, para a sua execução. As interações (requisições e respostas) entre os pares são
realizadas por meio de web services e definidas pelo protocolo SOAP, que se fundamenta em
um modelo de dados XML. Os serviços elencados no quadro 17 executam as tarefas
apresentadas no quadro 1 da seção 3.2. As tarefas mapeadas em serviços e não listadas nesse
quadro são encontradas no APÊNDICE D.
Quadro 17 – Tarefas de gerência de configuração transformadas em web services SOAP. ID Métodos Parâmetros de entrada
1 getRunningConfigurationRouter address
2 getAllVLANs address
4 setNewVLAN
address
VLANid
name
state
7 deleteVLAN address
VLANid
8 getStaticRoutes address
11 getPortConfigurationRouter address
port
12 configureInterface
address
port
interfaceAddress
subnetMask
MTU
description
13 noShutdownInterface address
port
14 shutdownInterface address
port
Fonte: Elaborado pelo autor.
Percebe-se pelo exposto no quadro 17 que as operações em SOA são apresentadas
por métodos get e set – quando sua correspondência for clara à execução da tarefa –
diferente de ROA, onde as operações são tratadas como substantivos – representações de
recursos acessados através das URIs – e os verbos ficam a cargo da interface uniforme.
Outro fato que diferencia a utilização de WS baseados em SOAP dos WS que utilizam o
estilo arquitetural REST trata basicamente do seu mapeamento individual e do não
agrupamento dos serviços. Essa diferença é motivada pelas características oriundas da
arquitetura SOA que abordam a granularidade fina e a reutilização. Através dessas duas
características foi incorporada uma maior flexibilidade à aplicação fazendo com que cada
serviço desempenhe uma funcionalidade clara e passível de ser reutilizada sem a
dependência ou agregação de outros serviços (o chamado encadeamento) no caso de WS
REST. Essas duas características também possibilitaram aos serviços a qualidade de
70
isolamento, onde permitiu-se a existência de apenas uma forma de acesso – através de um
serviço fino e bem definido – para a execução de determinada tarefa evitando assim o uso de
código redundante na aplicação.
O trecho de código apresentado no quadro 18 é semelhante ao demonstrado no
quadro 14, onde é exibido um WS REST que retorna as configurações de um dispositivo de
rede. Porém, este difere na interface de acesso que se dá através da anotação @WebMethod
expondo essa funcionalidade aos consumidores por meio do protocolo SOAP. A passagem
de parâmetros quando o acesso acontece por meio de SOAP, para essa aplicação, é definida
pela anotação @WebParam. Cabe salientar que da mesma forma definida em REST os web
services SOAP acessam os métodos disponibilizados pela API CLI disposta na camada de
acesso.
Quadro 18 – WS SOAP que retorna as configurações de um dispositivo de rede. /***
* WebMethod responsável por obter as configurações de um dispositivo de rede
* @param address
* @return - String no formato XML com o spool oriundo do roteador mediante a execução
* do comando
*/
@WebMethod(operationName = "getRunningConfigurationRouter")
public String getRunningConfigurationRouter(@WebParam(name = "address") String address) {
//Crio um novo objeto do tipo Router passando como parâmetro seu endereço
Router router = new Router(address, "user", "password");
//Executo o método da camada de acesso reponsável por obter a configuração
//geral do roteador
return RouterFuntions.getRunningConfigurationRouter(router);
}
Fonte: Elaborado pelo autor.
O trecho de código apresentado no quadro 19 se vale das mesmas características
expostas pelo quadro 18, diferenciando-se na funcionalidade de negócio que é tratada pela
tarefa de configuração de uma interface (porta) no dispositivo de rede.
Quadro 19 – WS SOAP que configura uma interface de rede. /**
* Método responsável por configurar uma interface (recurso) de rede no
* dispositivo de rede
* @param address
* @param port
* @param interfaceAddress
* @param subnetMask
* @param MTU
* @param description
* @return - String no formato XML com o spool oriundo do roteador mediante
* a execução do comando
*/
@WebMethod(operationName = "configureInterface")
public String configureInterface(@WebParam(name = "address") String address,
@WebParam(name = "port") String port,
@WebParam(name = "interfaceAddress") String interfaceAddress,
@WebParam(name = "subnetMask") String subnetMask,
@WebParam(name = "MTU") String MTU,
@WebParam(name = "description") String description) {
//Crio um novo objeto do tipo Router passando como parâmetro seu endereço
Router router = new Router(address, "user", " password ");
//Executo o método da camada de acesso reponsável por obter a configuração
//geral do roteador
71
return RouterFuntions.configureInterface(router, port, interfaceAddress,
subnetMask, MTU, description);
}
Fonte: Elaborado pelo autor.
O diagrama de sequência apresentado na figura 11 ilustra o processo de execução da
tarefa 1 através de WS REST e SOAP. Com o intuito de facilitar a visualização do fluxo as
condições de guarda durante a ocorrência de erros, por exemplo, nos procedimentos de
conexão ao equipamento ou na execução de uma tarefa, foram omitidas do diagrama de
sequência; entretanto, foram tratadas nas APIs e aplicações.
Figura 11 – Diagrama de sequência das aplicações REST e SOAP.
Fonte: Elaborado pelo autor.
72
3.3.1.3 Estratégia baseada em CLI e NETCONF
Assim como os web services REST e SOAP foram desenvolvidos de uma forma
que pudessem ser avaliados, através de ferramentas específicas, as aplicações CLI e
NETCONF que compõem o cenário de testes seguiram as mesmas metodologias. Essas
aplicações ficam dispostas na camada de apresentação e, análogas aos web services, fazem o
uso das APIs CLI e NETCONF. O desenvolvimento de ambas foi baseado na simulação por
meio de software, utilizando os comandos mapeados pelas APIs, não se valendo de
protocolos específicos para a exposição de funcionalidades (tarefas de gerência de
configuração) aos usuários finais como a transformação dessas tarefas em recursos REST
(através da interface uniforme do HTTP) ou serviços SOAP (por meio de protocolo de
mesmo nome para troca de mensagens).
As aplicações descritas nesta seção basicamente invocam os métodos estabelecidos
nas APIs da camada de acesso, sendo tratadas como softwares dispostos diretamente no
computador usuário e que executam as tarefas no dispositivo de rede, não passando por
nenhum intermediador ou gateway como acontece com o acesso através de web services.
Esses sim se valem de um mediador – servidor de aplicação – para suas requisições, e que
por meio de arquiteturas específicas abstraem todos os detalhes de implementação e
executam funções únicas e bem definidas sobre o dispositivo de rede.
A simulação do comportamento de um administrador de redes durante a execução
de suas tarefas de gerência de configuração é uma definição para essas estratégias. Essa
simulação passa somente pelo acesso, através do protocolo SSH-2, ao dispositivo e a
execução de comandos, análogo ao cenário onde um administrador executa as tarefas
através de um terminal de emulação como, por exemplo, PuTTY11
.
Novamente, valendo-se da substituição de parâmetros, dessa vez com acesso direto
aos métodos apresentados pela camada de acesso, as estratégias CLI e NETCONF executam
as tarefas de gerência de configuração mapeadas pela camada subjacente. O trecho de
código apresentado no quadro 20 demonstra esse acesso para algumas tarefas. Para a
aplicação CLI cabe somente a responsabilidade de alimentar os métodos com os valores
desejados, recuperar o seu retorno e registrar o tempo de execução. No trecho de código
apresentado pelo quadro 20, a variável nomeDoArquivo tem seu valor substituído na porção
11
http://www.putty.org
73
xx pelo id da VLAN onde a aplicação foi executada e salvando, ao término das repetições, o
tempo total de cada execução.
Quadro 20 – Trecho de código da aplicação CLI. //Itero sobre o número total de tarefas (14)
while (nrTarefa < nrTotalTarefas) {
nrIteracaoRodada = 0;
dadosParaArquivo = "";
duracaoExecucaoRodada = 0;
//Itero sobre o total de execuções sobre cada tarefa (30)
while (nrIteracaoRodada < nrTotalIteracoes) {
switch (nrTarefa) {
case 1: {
nomeDoArquivo = "TAREFA1\\CLI_TAREFA1_TIMES_VLANxx.csv";
//Gravo o tempo inicial e entro no switch para cada tarefa
inicioExecucaoRodada = System.currentTimeMillis();
RouterFuntions.getRunningConfigurationRouter(router);
//Pego o tempo final da execução da tarefa
terminoExecucaoRodada = System.currentTimeMillis();
break;
}
case 12: {
nomeDoArquivo = "TAREFA12\\CLI_TAREFA12_TIMES_VLANxx.csv";
RouterFuntions.configureInterface(router, port, interfaceAddress,
subnetMask, MTU, description);
break;
}
case 14: {
nomeDoArquivo = "TAREFA14\\CLI_TAREFA14_TIMES_VLANxx.csv";
RouterFuntions.disableInterface(router, port);
break;
}
}
//Calculo o tempo de execução total
duracaoExecucaoRodada = terminoExecucaoRodada - inicioExecucaoRodada;
registraTempoExecucao.add((int) duracaoExecucaoRodada);
if (nrIteracaoRodada == 0) {
dadosParaArquivo = "iteracao;duracao\n";
dadosParaArquivo = dadosParaArquivo +
nrIteracaoRodada + ";" +
duracaoExecucaoRodada + "\n";
} else {
dadosParaArquivo = dadosParaArquivo +
nrIteracaoRodada + ";" +
duracaoExecucaoRodada + "\n";
}
nrIteracaoRodada++;
//Pausa de 10 segundos entre execuções de uma mesma tarefa
Thread.sleep(10000);
}
nrTarefa++;
//Pausa de 1 minuto entre tarefas
Thread.sleep(60000);
//Crio o arquivo CSV com a duração de cada rodada para cada tarefa
CreateFile.CreateFile(caminhoDoArquivo, nomeDoArquivo + ".csv",
dadosParaArquivo.toString());
}
Fonte: Elaborado pelo autor.
O diagrama de sequência apresentado na figura 12 demostra, de forma abrangente e
sem especificar uma determinada tarefa, os procedimentos realizados durante a execução da
aplicação CLI.
74
Figura 12 – Diagrama de sequência da aplicação CLI.
Fonte: Elaborado pelo autor.
O trecho de código apresentado no quadro 21 demonstra que, além de executar as
tarefas de gerência de configuração por meio do protocolo NETCONF, cabe à aplicação
coordenar o sequenciamento das mensagens através das constantes apresentadas no quadro
12 e efetuar a troca dos parâmetros, quando necessário, antes da execução de cada tarefa.
Essa ordenação foi apresentada na seção 2.1.2.3 e visa garantir o correto pareamento, no
momento da conexão, entre o cliente que recebe uma mensagem denominada <hello> no
formato XML e responde, para o dispositivo de rede, com uma mensagem semelhante,
alterando somente elementos internos com intuito de dar prosseguimento à execução das
tarefas. Nota-se também nesse trecho de código a diferença entre as aplicações CLI e
NETCONF: na aplicação CLI, cada tarefa invoca um método específico para sua execução;
75
já para NETCONF o método RunMultipleCommands, responsável pela execução dos
comandos, é chamado diretamente recebendo como parâmetros as mensagens RPC definidas
em variáveis ou constantes. As linhas que tratam da medição e registro do tempo de
execução foram omitidas desse trecho de código.
Quadro 21 – Trecho de código da aplicação NETCONF. switch (nrTarefa) {
case 1: {
nomeDoArquivo = "TAREFA1\\NETCONF_TAREFA1_TIMES_VLANxx";
ExecMultipleCommands.RunMultipleCommands(router, NETCONFConstants.hello);
ExecMultipleCommands.RunMultipleCommands(router,
NETCONFConstants.getRunningConfigurationRouter);
ExecMultipleCommands.RunMultipleCommands(router, NETCONFConstants.closeSession);
break;
}
case 12: {
nomeDoArquivo = "TAREFA12\\NETCONF_TAREFA12_TIMES_VLANxx";
ExecMultipleCommands.RunMultipleCommands(router, NETCONFConstants.hello);
ExecMultipleCommands.RunMultipleCommands(router, NETCONFCommands.configureInterface);
ExecMultipleCommands.RunMultipleCommands(router, NETCONFConstants.closeSession);
break;
}
case 14: {
nomeDoArquivo = "TAREFA14\\NETCONF_TAREFA14_TIMES_VLANxx";
ExecMultipleCommands.RunMultipleCommands(router, NETCONFConstants.hello);
ExecMultipleCommands.RunMultipleCommands(router, NETCONFCommands.shutdownInterface);
ExecMultipleCommands.RunMultipleCommands(router, NETCONFConstants.closeSession);
break;
}
}
Fonte: Elaborado pelo autor.
A figura 13 apresenta a sequência dos procedimentos realizados durante a execução
da aplicação NETCONF sem especificar uma determinada tarefa. Nota-se que para essa
aplicação existe um maior número de interações entre os objetos, sendo uma prática inerente
ao protocolo NETCONF.
76
Figura 13 – Diagrama de sequência da aplicação NETCONF.
Fonte: Elaborado pelo autor.
Cabe salientar que ambas as aplicações, CLI e NETCONF, possuem mecanismos
desenvolvidos para que o tempo da execução de cada tarefa possa ser mensurado e
armazenado para posterior análise estatística (conforme apresentado no quadro 20), o que as
diferencia das estratégias baseadas em web services que têm esse tempo de execução
coletado por ferramentas externas como será apresentado na seção 3.4.
77
3.4 CENÁRIO DE TESTES
Para realizar a comparação das estratégias definidas pela seção 3.3 foi necessária a
criação de um cenário típico para o gerenciamento de redes. O ambiente utilizado para a
avaliação de desempenho de cada estratégia é apresentado na figura 14. É sobre esse
ambiente que a arquitetura do sistema, composta pelas aplicações e APIs, foi instalada e
executada.
Figura 14 – Cenário de testes utilizado durante a execução das aplicações e medições.
Fonte: Elaborado pelo autor.
Com o objetivo de oferecer uma visão de alto nível da topologia criada, os switches
centrais, de distribuição e de borda, bem como o servidor hospedeiro utilizado para
virtualização do servidor de aplicação Glassfish, foram suprimidos da figura; contudo, são
especificados na próxima seção que apresenta uma descrição detalhada de todos os
equipamentos utilizados para montagem desse cenário de testes.
78
3.4.1 Equipamentos utilizados
O ambiente de testes é disposto sobre a rede de produção do Instituto Federal
Catarinense (IFC) Campus Videira, sendo composta por equipamentos de rede – tanto
switches quanto servidores e clientes – que suportam a tecnologia Gigabit Ethernet. As
especificações de cada componente (hardware) utilizado para a modelagem da topologia
exposta na figura 14 encontram-se listadas a seguir:
dispositivo cliente – ultrabook da marca Hewlett-Packard (HP) modelo 840-
G1 com sistema operacional Microsoft Windows 10 Pro 64 bits, 8GB de
memória, processador Intel Core i5-4300 de 1.9GHz e HD SSD de 256GB;
servidor de virtualização – com o objetivo de otimizar a utilização da
infraestrutura física foi empregado o VMware vSphere 6.0 (ESXi) como
hypervisor para criação do servidor virtual que irá suportar o servidor de
aplicações. Essa virtualização foi realizada sobre um servidor PowerEdge
R710 da marca DELL com sistema operacional VMWare ESXi 6.0.0 build
2494585, 16GB de memória, 2 processadores Intel Xeon E5620 de 2.4GHZ e
2 HDs Near Line 15k de 300GB;
servidor de aplicação – máquina virtual com sistema operacional Linux
Debian na versão 8.2, 6GB de memória, 1 processador de 4GHz e 50GB de
HD. O servidor web, instalado nessa máquina e utilizado para deploy das
estratégias baseadas em web services, é o GlassFish Server Open Source
Edition 4.1.1 (build 1) rodando sobre uma JVM na versão 1.8.0_66.
switch de borda – equipamento que oferece conectividade ao usuário final da
marca HP/3C, versão 4210G e modelo 3CRS42G-84-91;
switch de distribuição – equipamento com 24 portas Small Form-Factor
Pluggable (SFP) utilizado para distribuição e que interliga os switches de
borda aos switches centrais. Esse equipamento de distribuição é da marca HP,
versão A5500 SERIES e modelo JD374A;
switch central (core) – elemento central da rede da marca HP, versão A5500
SERIES e modelo JD375A, que serve de conexão para o servidor de
virtualização e o equipamento a ser gerenciado (roteador) pelas estratégias
apresentas por esse trabalho;
79
firewall – servidor da marca HP modelo ProLiant DL 120 G7 com sistema
operacional Linux Debian na versão 6.0.8, 1 processador Intel Xeon X3440 de
2.53GHz, 16GB de memória e HD SATA 7.2K de 1TB;
roteador – equipamento da marca Cisco modelo 2921 com firmware C2900-
UNIVERSALK9-M na versão 15.1(4)M3, com 512MB de memória, 1
processador FTX1603AM78, 3 Gigabit Ethernet interfaces (sendo uma SFP),
1 terminal line, 255Kb para as configurações de memória não volátil e
250880Kb para ATA System CompactFlash (Read/Write).
O trecho de comandos apresentado no quadro 22 informa uma parte da configuração
realizada para alocar o roteador Cisco 2921 (equipamento a ser gerenciamento pelas
estratégias) nesse ambiente de testes.
Quadro 22 – Comandos utilizados para configuração do roteador Cisco 2921. router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#hostname CISCO2921
CISCO2921(config)#ip domain-name videira.ifc.edu.br
CISCO2921(config)#enable secret secret
CISCO2921(config)#crypto key zeroize rsa
% All keys will be removed.
% All router certs issued using these keys will also be removed.
Do you really want to remove these keys? [yes/no]: yes
CISCO2921(config)#crypto key generate rsa
......{retorno omitido}
CISCO2921(config)#aaa new-model
CISCO2921(config)#aaa authentication login default local
CISCO2921(config)#aaa authorization exec default local
CISCO2921(config)#username usuario password 0 password
CISCO2921(config)#username admin privilege 15 password password
CISCO2921(config)#aaa authentication login LOCALUSERS local
CISCO2921(config)#line vty 0 4
CISCO2921(config-line)#login authentication LOCALUSERS
CISCO2921(config-line)#transport input ssh
CISCO2921(config-line)#exit
CISCO2921(config)#exit
CISCO2921(config)#ntp server ntp.pop-sc.rnp.br
Translating "ntp.pop-sc.rnp.br"...domain server (200.135.55.2) [OK]
CISCO2921(config)#clock timezone GMT -3
CISCO2921(config)#no ip domain-lookup
CISCO2921(config)#ip ssh version 2
CISCO2921(config)#netconf ssh
CISCO2921(config)#netconf max-message 2147483
CISCO2921(config)#ip domain name videira.ifc.edu.br
CISCO2921(config)#crypto key generate rsa mod 1024
......{retorno omitido}
CISCO2921(config)#end
Fonte: Elaborado pelo autor.
Nota: Os comandos destacados em itálico envolvem especificamente as configurações realizadas para o
funcionamento do protocolo NETCONF. As configurações utilizadas para atualização do firmware do
equipamento, bem como de parametrizações SNMP ou de segurança, foram omitidas desse quadro.
A seção a seguir apresenta a descrição do cenário, bem como a alocação de cada
equipamento dentro da topologia de rede criada.
80
3.4.2 Descrição do cenário
Tomando como base a topologia apresentada na figura 14, nota-se que a rede foi
segmentada em três VLANs. Essa segmentação foi realizada com o intuito de apresentar um
cenário de gerenciamento real e típico de uma rede acadêmica ou empresarial, onde os
computadores responsáveis pela gerência não se encontram conectados no mesmo segmento
dos equipamentos de interconexão e também de mensurar o desempenho durante a execução
das tarefas de gerência de configuração quando seus dados trafegam por um equipamento do
tipo firewall, implementado com regras de liberação e redirecionamento utilizando a
ferramenta iptables. As VLANs utilizadas no cenário de testes, bem como seu endereçamento,
são apresentadas no quadro 23.
Quadro 23 – VLANs utilizada no cenário de testes. VLAN ID VLAN NAME Rede Máscara
2 Demilitarized Zone – Zona Desmilitarizada (DMZ) 200.135.55.0 /24
100 GERENCIAMENTO 10.100.0.0 /26
22 NOC 172.22.0.0 /28
Fonte: Elaborado pelo autor.
No cenário em questão a VLAN com identificador 22 é a rede onde estão dispostos
os computadores do Network Operations Center – Centro de Operações de Rede (NOC), à
qual tem acesso a todas as VLANs implementadas no Campus através de regras configuradas
no firewall. Já a VLAN com identificador 100 é a rede de gerência de todos os equipamentos
de interconexão (switches, roteadores, access points, entre outros). Segmentar a rede dessa
forma cria um domínio de broadcast independente para o gerenciamento de equipamentos e
impede o acesso de outros domínios (salvo exceções), proporcionando assim a segurança do
tráfego e a independência da topologia física.
A boa prática de isolar o gerenciamento da rede através de uma VLAN específica faz
com que todos os equipamentos de interconexão, além de transportarem as VLANs que
acolhem as demandas dos usuários, carreguem através de suas portas de uplink marcadas
como trunk a tag da VLAN de gerenciamento. Ainda nesses equipamentos são criadas as
interfaces (portas) virtuais, e para essas são atribuídas as VLANs de gerenciamento com o
intuito de fornecer acesso de gerência por meio de endereços IP delegados a essas interfaces
virtuais.
Portanto, através da segmentação definida para o cenário, todo tráfego oriundo de um
equipamento conectado diretamente na VLAN 100 não necessita ser liberado e redirecionado
pelo firewall para outro equipamento dentro da mesma rede virtual; já para que um
81
equipamento conectado na VLAN 22 interaja com um equipamento da VLAN 100 o tráfego
precisa ser liberado e redirecionado de maneira bidirecional pelo firewall.
Para a topologia proposta um componente adicional é utilizado entre o cliente e o
dispositivo de rede a ser gerenciado quando as execuções das tarefas ocorrem por meio de
web services. Esse equipamento é um gateway Linux Debian que comporta um servidor de
aplicação Glassfish responsável por operar como um intermediador entre o cliente e o
dispositivo de rede, sendo através desse que são fornecidos os web services REST e SOAP ao
cliente.
Cabe salientar que durante os testes realizados o roteador utilizado se encontrava
constantemente conectado a rede de gerência – VLAN 100 – e o servidor de aplicação,
conforme a topologia proposta, dispunha de duas interfaces (portas) de rede conectadas nas
VLANs com identificadores de número 100 e 2. Uma interface de rede do servidor de
aplicação conectada a VLAN com ID 100 tinha alcance para gerenciar diretamente os
dispositivos de rede e a outra interface desse servidor, conectada a VLAN 2 (DMZ),
possibilitava um acesso seguro por parte dos usuários, conectados na VLAN 22, durante a
execução dos serviços e recursos fornecidos pelos web services hospedados nesse
equipamento.
Evidencia-se que o servidor de aplicação foi conectado à VLAN 2 e não à VLAN 22
pelo fato de que os serviços poderiam ser consumidos através da internet. Entretanto, para o
cenário em questão, mesmo dispondo de um endereço IP válido a comutação dos pacotes
provenientes dos testes ficou contida no cenário controlado; ou seja, as oscilações do tráfego
externo não interferiram no ambiente interno.
A seção a seguir apresenta as métricas utilizadas para mensurar o desempenho de
cada tarefa dentro das estratégias estabelecidas.
3.4.3 Definição das métricas e descrição das ferramentas de medição
Para a avaliação das tarefas de gerenciamento de configuração de redes –
implementadas e executadas por meio do mapeamento definido pelas quatro estratégias –
foram elencadas duas métricas a serem avaliadas:
tempo de resposta – tempo total para a execução de cada tarefa,
compreendendo o intervalo após a passagem de parâmetros aos métodos ou
82
web services (quando necessário) e o recebimento da resposta pelo usuário. É
através dessa métrica que a experiência com o usuário é avaliada, ou seja,
quanto maior o tempo de execução de uma tarefa, maior será o tempo de
espera do usuário por uma resposta. Portanto, o tempo de resposta foi adotado
neste trabalho como um aspecto comparativo para medir a eficiência de cada
estratégia durante a execução das tarefas de gerência de configuração de rede;
tráfego gerado – métrica que indica o número total de bytes enviados e
recebidos durante a execução das tarefas dentro de cada estratégia. O objetivo
de realizar a análise dessa métrica é a verificação do impacto que cada forma
de gerenciamento traz à rede. Para a composição desse tráfego, não são
considerados apenas os bytes trocados pelos protocolos de níveis superiores
para cada estratégia, ou seja, HTTP para aplicações baseadas em web services
e SSH-2 para aplicações baseadas em CLI ou NETCONF, mas sim todos os
bytes utilizados pela pilha de protocolos como ethernet, IP e TCP.
Para a realização das medições e coletas dos indicadores de desempenho de cada
tarefa foram utilizadas ferramentas computacionais que se fundamentam nos princípios das
arquiteturas ou formas de acesso utilizadas pelas estratégias para passagem de parâmetros e
posterior execução individual. Com a utilização dessas ferramentas buscou-se a
automatização ou a semi-automatização da execução de cada tarefa fazendo com que uma
possível interferência, durante cada procedimento, não influenciasse no resultado final.
Foi parametrizado em todas as aplicações e ferramentas de medição de tempo de
resposta que o intervalo entre cada uma das 30 execuções fosse de 10 segundos, e no caso
específico das aplicações CLI e NETCONF, onde as tarefas estavam aninhadas em uma
iteração loop, que o tempo de execução entre tarefas fosse igual a 60 segundos. As execuções
que tinham por objetivo a coleta por meio de aplicações externas dos bytes trafegados em
cada requisição, seguiram de forma manual para equalizarem-se com capturas e nomeações de
arquivos, realizados em paralelo, para cada tarefa e estratégia. Justifica-se aí a separação das
execuções para as métricas estabelecidas.
Como mencionado na seção 3.3.1.3, que trata das estratégias baseadas em CLI e
NETCONF, os tempos de resposta foram registrados pela própria aplicação por meio de
contadores de tempo internos, e salvos em arquivos individuais para cada tarefa. O tempo
inicial e final foi registrado durante o início e o término de cada execução, respectivamente.
83
Completada a execução foi subtraído o tempo final do tempo inicial obtendo o tempo total
para determinada ação, empilhando-os em um array e, após o término das 30 execuções para
cada tarefa, registrados em um arquivo individual com o número de cada rodada. Para medir o
tempo de resposta das estratégias baseadas em web services REST e SOAP foi utilizada a
aplicação SoapUI12
, uma ferramenta open source para testes funcionais, de carga e de
conformidade para as arquiteturas orientadas a serviços e a recursos. Através da ferramenta
SoapUI também foi possível a automatização e o agendamento da execução para cada web
service mediante a passagem e cadastro prévio de parâmetros.
Para a medição do tráfego gerado (bytes trafegados) durante a execução de cada
tarefa foram utilizadas duas ferramentas distintas, mas que executam funções similares. A
distinção dessas ferramentas se deu pela composição heterogênea do ambiente e do hardware
empregado pela arquitetura apresentada nas estratégias baseadas em web services SOAP e
REST. As aplicações utilizadas foram tcpdump13
e Wireshark14
. O tcpdump é uma ferramenta
que monitora, captura e exibe os pacotes que trafegam por uma interface (porta) de rede de
um equipamento através da linha de comando; já o Wireshark é um software similar ao
tcpdump, porém disponibiliza um ambiente gráfico para filtragem e geração de relatórios
customizados. Ambas as ferramentas fazem uso de uma biblioteca chamada Packet Capture
(PCAP), sendo que para sistemas operacionais baseados em Linux é utilizada a versão libpcap
e para o ambiente Microsoft Windows a versão dessa biblioteca é chamada WinPcap.
A alocação de cada ferramenta no ambiente de testes, visualizado na figura 14, será
apresentada na seção 3.4.4.
3.4.4 Descrição da coleta
Cada uma das 14 tarefas mapeadas dentro das quatro estratégias, salvo as tarefas 4 a
7 que não puderam ser traduzidas em métodos na aplicação NETCONF, foram executadas 30
vezes para cada métrica sendo que, no momento da execução de cada tarefa, somente as
aplicações responsáveis pelos agendamentos ou execuções, coleta dos dados das medições ou
as rotinas de background do sistema operacional estavam sendo executadas em paralelo.
12
https://www.soapui.org 13
http://www.tcpdump.org 14
https://www.wireshark.org
84
Durante a medição do tráfego gerado pelas tarefas em todas as estratégias adotou-se
a utilização de filtros para a correta captura de pacotes trocados durante as execuções. A
utilização dos filtros apresentados pelo quadro 24 levou em consideração a direção do tráfego
e não o protocolo utilizado em cada segmento da rede, atendendo os requisitos impostos pela
métrica apresentada na seção anterior. Com isso foram capturados todos os pacotes da
hierarquia de protocolos, mensurando assim o custo concreto de cada execução.
Quadro 24 – Direções e filtros aplicados para captura de pacotes.
Estratégia Direção da captura VLAN Software de
captura Filtro
CLI
Cliente < > Roteador 22 Wireshark
((ip.dst_host==10.100.0.61 &&
ip.src_host==172.22.0.5) || (ip.dst_host==172.22.0.5
&& ip.src_host==10.100.0.61) )
Cliente < > Roteador 100 Wireshark
((ip.dst_host==10.100.0.61 &&
ip.src_host==10.100.0.56) || (ip.dst_host==10.100.0.56
&& ip.src_host==10.100.0.61) )
NETCONF
Cliente < > Roteador 22 Wireshark
((ip.dst_host==10.100.0.61 &&
ip.src_host==172.22.0.5) || (ip.dst_host==172.22.0.5
&& ip.src_host==10.100.0.61) )
Cliente < > Roteador 100 Wireshark
((ip.dst_host==10.100.0.61 &&
ip.src_host==10.100.0.56) || (ip.dst_host==10.100.0.56
&& ip.src_host==10.100.0.61) )
WS REST
Cliente < > Servidor de
Aplicação 2 Wireshark
((ip.dst_host==200.135.55.66 &&
ip.src_host==172.22.0.5) || (ip.dst_host==172.22.0.5
&& ip.src_host==200.135.55.66) )
Servidor de Aplicação <
> Roteador 100 tcpdump
-i eth1 src host 10.100.0.59 or src host 10.100.0.61 -
vvv
WS SOAP
Cliente < > Servidor de
Aplicação 2 Wireshark
((ip.dst_host==200.135.55.66 &&
ip.src_host==172.22.0.5) || (ip.dst_host==172.22.0.5
&& ip.src_host==200.135.55.66) )
Servidor de Aplicação <
> Roteador 100 tcpdump
-i eth1 src host 10.100.0.59 or src host 10.100.0.61 -
vvv
Fonte: Elaborado pelo autor.
As aplicações baseadas em CLI e NETCONF foram testadas inicialmente com o
computador do cliente conectado à VLAN com identificador 22, e em seguida com o cliente
conectado à VLAN 100. Esses testes foram executados de maneira idêntica e a mudança foi
realizada somente no switch de borda ao qual o cliente estava conectado, alterando a tag da
VLAN dessa porta. Como citado na seção 3.4.3 o tempo de resposta para as tarefas dessas
duas estratégias foram coletados por meio de contadores internos e o tráfego gerado, pelo fato
dessas aplicações estarem instaladas em um computador com sistema operacional Microsoft
Windows, foram coletadas através do software Wireshark disposto no mesmo equipamento
que contém as referidas aplicações.
Cabe salientar que para os testes das estratégias que se baseavam em WS REST e
SOAP o equipamento do cliente ficou conectado somente à VLAN 22 (NOC) e dispunha de
livre acesso ao servidor de aplicação, localizado na VLAN 2 (DMZ) conforme cenário
proposto. Outro ponto que merece atenção é de que os dados trafegados para a descoberta por
85
meio de arquivos WSDL dos serviços, disponibilizados através da estratégia baseada em WS
SOAP, não foram contabilizados no resultado final dessa métrica.
O mesmo equipamento – hardware e sistema operacional – utilizado para os testes
das aplicações CLI e NETCONF foi utilizado para as estratégias baseadas em web services.
Uma imposição na direção do tráfego, com a inclusão de um servidor gateway para
intermediar as requisições por meio de duas interfaces (portas) de rede, uma conectada na
VLAN 2 (DMZ) e outra conectada na VLAN 100 (GERENCIAMENTO) faz com que as
ferramentas utilizadas para captura de pacotes sejam dispostas da seguinte maneira: para o
segmento entre o cliente e o servidor de aplicação foi utilizada a ferramenta Wireshark e para
a parte que trata da comunicação entre o servidor de aplicação e o dispositivo de rede foi
utilizado o software tcpdump, pelo fato do servidor de aplicação ter sido executado sobre um
sistema operacional Linux e não dispor de ambiente gráfico. Portanto, a métrica que aborda os
dados trafegados pelas tarefas nas estratégias baseadas em web services SOAP e REST é
alcançada com a soma dos bytes trafegados nos dois segmentos de rede. Apesar de ambas as
estratégias suportarem a ativação de mecanismos de cache tanto no lado do cliente quanto no
lado do servidor de aplicação essa característica foi desabilitada em qualquer equipamento da
rede envolvido na comunicação, sendo que tal ação teve por objetivo eliminar resultados não
condizentes com a proposta.
Para as estratégias CLI e NETCONF, o tempo de resposta para cada tarefa foi
mensurado e registrado pelas próprias aplicações desenvolvidas por este trabalho. Já para os
web services SOAP e REST, essa métrica foi contabilizado por meio do software SoapUI
seguindo as características tradadas na seção que apresentou as ferramentas de medição. Cabe
salientar que o software SoapUI foi utilizado para orquestrar as execuções de todos os web
services aferidos por este trabalho.
Os resultados obtidos pela utilização de cada estratégia – para realização das tarefas
de gerência de configuração de dispositivos de rede sobre o cenário exposto – são
apresentados no capítulo a seguir.
86
4 ANÁLISE DOS RESULTADOS
O cenário descrito no capítulo anterior foi utilizado para a execução dos testes com
as tarefas implementadas através das quatro estratégias propostas. A apresentação, avaliação e
comparação dos dados coletados são exibidos neste capítulo: em um primeiro momento
apresentaremos a organização dos dados com o intuito de facilitar a visualização, bem como a
interpretação das métricas estabelecidas. O capítulo é finalizado com uma discussão
abrangente sobre os resultados alcançados, bem como a influência e particularidades
observadas em cada estratégia durante a execução das tarefas.
4.1 ORGANIZAÇÃO E VISUALIZAÇÃO DOS DADOS COLETADOS
A visualização dos resultados foi organizada através da separação dos quadros e
figuras baseando-se nas ações que alteram o estado da configuração do dispositivo de rede
gerenciado (roteador) e também nas ações que consultam as configurações desse
equipamento. Finalizada a separação, as tarefas correlatas foram agrupadas quanto às suas
funcionalidades. O quadro 25 apresenta, de forma tabular, a organização dos resultados que
serão exibidos nas próximas seções.
Quadro 25 – Organização e visualização dos dados coletados
Ação Funcionalidade ID Tarefa
Recuperação CONFIG 1 Recuperação da configuração geral
Recuperação VLAN 2 Recuperação de todas as VLANs
3 Recuperação de VLAN específica
Alteração VLAN
4 Criação de VLAN
5 Alteração de estado de VLAN
6 Alteração de nome de VLAN
7 Exclusão de VLAN
Recuperação TBRE 8 Recuperação de tabela de roteamento estático
Alteração TBRE 9 Criação de rota estática
10 Exclusão de rota estática
Recuperação IFACE 11 Recuperação das configurações de interface
Alteração IFACE
12 Configuração de interface
13 Ativação de interface
14 Desativação de interface
Fonte: Elaborado pelo autor.
Nota: Legenda para a coluna denominada funcionalidade: CONFIG: Configurações do dispositivo de rede;
VLAN: Virtual Lans – Rede Local Virtual (VLANs);
TBRE: Tabela de Roteamento Estático;
IFACE: Interface de rede.
87
A execução das tarefas descritas na seção 3.4.4 culminou, através do somatório das
duas métricas, em 1.680 execuções divididas igualmente entre web services REST e SOAP,
1.680 execuções de métodos da aplicação CLI – 840 para cada VLAN – e mais 1.200
execuções para a forma de acesso NETCONF – 600 para cada VLAN.
Como apresentado na definição das métricas, realizamos a composição do tráfego
gerado pelas estratégias baseadas em web services por meio da soma dos bytes em dois
segmentos da rede. Lembramos que, para WS SOAP, o tráfego gerado pela descoberta dos
serviços por parte do cliente através de documentos WSDL não foi contabilizado no total do
tráfego gerado para essa estratégia. Para visualização gráfica dos resultados, o total trafegado
foi sumarizado acima da barra de cada estratégia sendo que essas barras, quando da utilização
de web services, foram separadas em duas aplicações. A primeira, denominada SSH, trata dos
dados trafegados entre o servidor de aplicação e o roteador correspondendo à parte inferior do
gráfico – dados oriundos do protocolo SSH-2; a segunda, visualizada através da parte superior
da barra, apresenta o indicativo de tráfego utilizando a denominação HTTP.
Cabe salientar que os valores apresentados neste capítulo são baseados nos valores
médios obtidos através das 30 execuções.
4.2 COMPARAÇÃO DAS ESTRATÉGIAS
Os resultados apresentados pelas tabelas 1 e 2 mostram a quantidade de bytes
trafegados e os tempos de resposta durante a execução da tarefa 1, que objetiva a recuperação
das informações de configuração do roteador. As informações apresentadas após as execuções
são parâmetros de acesso através de SSH-2 ou NETCONF, informações de domínio e
interfaces, Access Control List – Lista de Controle de Acesso (ACL), modelos de
autenticação, dentre outras.
Tabela 1 – Valores médios da quantidade de bytes trafegados durante a execução da
tarefa 1.
ID
Estratégias
Aplicações (bytes) Web Services (bytes)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
SOAP REST
HTTP SSH HTTP SSH
Total Total
1 7268,6 7238,4 11438,667 10726,333 3789,367 7074,6 3001,8 7115
10863,967 10116,8
Fonte: Elaborado pelo autor.
88
Tabela 2 – Valores médios dos tempos de resposta obtidos para a realização da tarefa
1.
ID
Estratégias
Aplicações (ms) Web Services (ms)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100 SOAP REST
1 740,267 685,833 781,733 779,133 574,967 567,067
Fonte: Elaborado pelo autor.
Avaliamos, por meio dos valores médios apresentados na tabela 1, que a execução
onde se obteve o menor tráfego através da rede foi a estratégia baseada na aplicação CLI
disposta na VLAN 100. Ainda na métrica que trata dos bytes trafegados durante a execução, a
estratégia mais consumista foi a aplicação NETCONF conectada na VLAN 22 gerando
36,71% mais dados na rede do que a melhor estratégia para essa tarefa.
Os valores médios para os tempos de resposta demonstram que a execução por meio
do web service REST é a forma mais rápida para a obtenção das configurações do roteador,
sendo que a estratégia similar baseada em SOAP tem seu valor médio para o tempo de
resposta muito semelhante (tabela 2).
Os bytes trafegados durante a recuperação de todas ou de uma VLAN –
correspondendo respectivamente às tarefas 2 e 3 – criadas sinteticamente no roteador, bem
como os tempos de resposta dessas tarefas, são analisados através das tabelas 3 e 4. O retorno,
após a execução da tarefa de número 2, é composto de uma listagem contendo todas as
VLANs bem como seus atributos – identificadores, nomes e status. Os mesmos atributos são
retornados na tarefa de número 3, porém com um diferencial: somente as informações de uma
VLAN informada como parâmetro durante a chamada dos web services ou métodos são
apresentadas. Cabe salientar que, previamente à sua execução, foram criadas sinteticamente
48 VLANs no roteador, sendo, conforme mencionado no início da seção 3.2, esse o número
máximo de redes locais virtuais suportadas pelo equipamento. Após a realização da coleta das
métricas, as VLANs criadas no equipamento foram excluídas, retornando o ambiente à sua
uniformidade.
89
Tabela 3 – Valores médios da quantidade de bytes trafegados durante a execução das
tarefas 2 e 3.
ID
Estratégias
Aplicações (bytes) Web Services (bytes)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
SOAP REST
HTTP SSH HTTP SSH
Total Total
2 7690,2 7507,8 19453,233 18517,067 5346,8 7467,2 2196,4 7478
12814 9674,4
3 5003 4883,6 12335,4 11611,4 1607,8 4843 764,2 4843
6450,8 5607,2
Fonte: Elaborado pelo autor.
Tabela 4 – Valores médios dos tempos de resposta obtidos para a realização das tarefas
2 e 3.
ID
Estratégias
Aplicações (ms) Web Services (ms)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100 SOAP REST
2 580,9 556,567 1164,367 1097 408,633 403,133
3 548,9 586,933 778,533 773,9 398,967 394,233
Fonte: Elaborado pelo autor.
Na tabela 3 são apresentados os valores médios para os bytes trafegados pelas tarefas
2 e 3. Nela observamos que, durante a execução de ambas, a estratégia que se sobressai
(trafegando menos dados) é a aplicação onde os comandos são mapeados através da CLI e
executados diretamente do computador do usuário conectado na VLAN 100 na qual é disposta
a interface de gerenciamento do roteador. Observamos que se comparado à estratégia baseada
em NETCONF na mesma VLAN, o consumo da aplicação CLI é 59,45% inferior para a tarefa
2 e 57,94% inferior para a tarefa 3. A tabela 4 apresenta os resultados obtidos para os tempos
de resposta das estratégias através da média das 30 execuções de cada tarefa. Notamos que,
semelhante à tarefa 1, as tarefas 2 e 3 obtiveram os menores tempos de resposta quando
executadas através da abordagem baseada em web services REST.
As tarefas que alteram o comportamento do dispositivo de rede através da criação,
alteração ou exclusão de VLANs – tarefas enumeradas de 4 a 7 – foram agrupadas e são
apresentadas pelas tabelas 5 e 6 para as métricas que demonstram o tráfego gerado e os
tempos de resposta das estratégias. Complementamos a demonstração e a comparação dos
resultados para essas tarefas salientando que, conforme apresentado na seção 3.3, onde
realizamos a composição das estratégias, uma limitação do equipamento utilizado para os
testes nos impediu de que estas fossem mapeadas por meio da camada de conteúdo e
90
executadas através da estratégia baseada na aplicação NETCONF, tanto na VLAN 22 quanto
na VLAN 100.
Tabela 5 – Valores médios da quantidade de bytes trafegados durante a execução das
tarefas 4, 5, 6 e 7.
ID
Estratégias
Aplicações (bytes) Web Services (bytes)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
SOAP REST
HTTP SSH HTTP SSH
Total Total
4 12097,667 11898,333 2058,6 13509 1160,867 11819,6
15567,6 12980,467
5 12028 11861,2 1990,2 11979,33 1162,2 11953,6
13969,533 13115,8
6 12487,267 12376,2 2003,4 12505,8 1171,733 12497,13
14509,2 13668,867
7 9392,2 9219,8 1877 10564,6 1119 10606
12441,6 11725
Fonte: Elaborado pelo autor.
Tabela 6 – Valores médios dos tempos de resposta obtidos para a realização das tarefas
4, 5, 6 e 7.
ID
Estratégias
Aplicações (ms) Web Services (ms)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100 SOAP REST
4 454,533 460,933 324,333 305,8
5 453,467 447,433 308,867 302,167
6 485,133 456,5 310,3 303,7
7 388,367 400,3 307,767 299,767
Fonte: Elaborado pelo autor.
Observamos através das tabelas 5 e 6 um comportamento semelhante para as tarefas
enumeradas de 4 a 7. Ao analisarmos a tabela 5 visualizamos que a estratégia que menos
sobrecarrega a rede durante a execução dessas tarefas é a aplicação CLI, que se utiliza da
VLAN 100 para comunicação com o roteador. Podemos avaliar, através da comparação com
as tarefas 2 e 3, que as execuções que visam modificar o comportamento através da criação ou
alteração de uma funcionalidade (nesse caso as VLANs), são mais custosas quanto ao tráfego
gerado do que as que realizam somente a consulta dessa mesma funcionalidade no
equipamento. O motivador para esse resultado é a necessidade de acesso, no caso específico
de VLANs, a um módulo chamado vlan-database que realiza o gerenciamento de um arquivo
denominado vlan.dat, armazenado na memória flash do equipamento. Justamente por acessar
diretamente a memória flash do dispositivo através de um módulo próprio, observamos por
meio da tabela 6 que, se compararmos novamente com as tarefas 2 e 3 os tempos de resposta,
91
por mais dados que sejam trafegados durante as execuções, são menores nas operações de
escrita e exclusão do que nas de leitura. Valendo-se dos valores médios, observamos que os
web services REST utilizados durante a execução dessas tarefas apresentaram um menor
tempo de resposta e que a diferença de sobrecarga do protocolo SOAP para a abordagem
REST, quanto ao tráfego gerado, foi de 16,61%, 6,11%, 5,79% e 5,75% superior para as
tarefas 4, 5, 6 e 7, respectivamente.
Nas tabelas 7 e 8 mostramos os bytes trafegados e os tempos de resposta para as
estratégias na tarefa 8, as quais, igualmente, visam a recuperação da tabela de roteamento
estático. Assim como na tarefa 3, vimos a necessidade da criação, neste caso, de entradas
sintéticas na tabela de roteamento com o objetivo de simular um ambiente real de roteamento
para posterior recuperação. Com isso buscamos o número máximo de rotas estáticas
suportadas pelo roteador e chegamos a um total de 200 rotas. As rotas criadas sinteticamente
foram utilizadas somente para os testes através dessa tarefa e excluídas após a coleta das
métricas propostas.
Tabela 7 – Valores médios da quantidade de bytes trafegados durante a execução da
tarefa 8.
ID
Estratégias
Aplicações (bytes) Web Services (bytes)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
SOAP REST
HTTP SSH HTTP SSH
Total Total
8 15588,6 15418,8 22669,5 21203,067 14921,13 15176,6 6743,6 15227
30097,733 21970,6
Fonte: Elaborado pelo autor.
Tabela 8 – Valores médios dos tempos de resposta obtidos para a realização da tarefa
8.
ID
Estratégias
Aplicações (ms) Web Services (ms)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100 SOAP REST
8 545,733 587,567 1420,667 1500,9 430,1 415,333
Fonte: Elaborado pelo autor.
A partir dos resultados dos experimentos verificamos que a quantidade média de
dados trafegados durante a execução da tarefa 8 mostrou-se mais satisfatória para a aplicação
CLI que utiliza como trânsito até o roteador a VLAN 100. Entretanto, pela arquitetura do
sistema, a tarefa sendo executada através dessa aplicação não é a mais rápida, ficando a cargo
do web service REST a execução com menor tempo médio de resposta.
92
Assim como apresentado na tarefa 3 notamos uma diferença evidente entre o web
service REST e SOAP. Esse último, pela sua natureza de modelagem com o tráfego de
arquivos XML durante todas as etapas da comunicação entre o cliente e o servidor de
aplicação oferece, se compararmos somente a porção superior do gráfico de barras (HTTP),
expressivos 8177,53 bytes, ou seja, 54,8% mais dados do que o seu similar em REST, sendo
que esse último proporciona os mesmos dados com um diferencial: as requisições utilizam
HTTP sem envelopamento XML adicional, e os dados são apresentados após a execução da
tarefa em formato JSON, não existindo sobrecarga de elementos XML no momento da sua
visualização. Essa diferença tornou-se notória pela quantidade de entradas retornada pela
tabela de roteamento.
Após a execução da tarefa 8 analisamos, quanto ao tempo de resposta do protocolo
NETCONF, um comportamento semelhante com a tarefa de número 2. Por recuperarem mais
informações, os valores dessas duas tarefas exibem uma grande variância, apresentando mais
oscilações que as tarefas que recuperam informações únicas (por exemplo, de somente uma
VLAN). Atribuímos esse desempenho ao tempo de processamento do roteador entre a coleta
interna desses dados e o início da próxima execução posterior à apresentação.
Os resultados apresentados nas tabelas 9 e 10 foram obtidos após a execução das
estratégias para as tarefas 9 e 10. Seguindo o princípio exibido na seção 4.1, agrupamos as
tarefas correlatas que alteram a configuração do equipamento – nesse caso, através da criação
e exclusão de entradas na tabela de roteamento estático.
Tabela 9 – Valores médios da quantidade de bytes trafegados durante a execução das
tarefas 9 e 10.
ID
Estratégias
Aplicações (bytes) Web Services (bytes)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
SOAP REST
HTTP SSH HTTP SSH
Total Total
9 12761,6 12620,4 9479,4 8656,6 1937,067 12537,2 1016,967 12714,2
14474,267 13731,167
10 11793,133 11495,333 9471,333 8684 1874,367 11720,6 988,4 11669,2
13594,967 12657,6
Fonte: Elaborado pelo autor.
93
Tabela 10 – Valores médios dos tempos de resposta obtidos para a realização das
tarefas 9 e 10.
ID
Estratégias
Aplicações (ms) Web Services (ms)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100 SOAP REST
9 411,467 442,9 771,333 772,633 313,067 302,967
10 410,2 447,667 781,633 777,4 311,667 306,533
Fonte: Elaborado pelo autor.
Observamos através da tabela 9 que a estratégia mais econômica quanto à geração de
tráfego para as tarefas 9 e 10 durante uma requisição é a aplicação que utiliza o protocolo
NETCONF na VLAN 100 como meio de acesso entre o cliente e o equipamento gerenciado.
Se comparada à sua similar, que utiliza do mapeamento através de comandos CLI na mesma
VLAN, percebemos que sua economia é de 31,40% e 24,45%, o que resulta em 3963,8 bytes e
2811,333 bytes a menos passados em cada requisição para as tarefas 9 e 10, respectivamente.
O tempo médio para obtermos o retorno de uma tarefa após as 30 execuções é exibido na
tabela 10. Nela, avaliamos que a transformação dessas tarefas em recursos, por meio de web
services REST, é a alternativa mais rápida dentre as opções oferecidas.
Avaliamos também, através das tabelas 11 e 12, o custo efetivo durante a
recuperação das informações pertinentes a uma interface de rede. Para essa tarefa de número
11 as informações retornadas apresentaram o estado atual da configuração de determinada
porta do roteador. Exibimos, após a sua execução, as informações que continham o número da
porta, sua descrição, o valor do Maximum Transmission Unit – Unidade Máxima de
Transmissão (MTU), o endereço IP seguido de sua máscara, o parâmetro duplex que orienta o
fluxo de dados e a velocidade parametrizada.
Tabela 11 – Valores médios da quantidade de bytes trafegados durante a execução da
tarefa 11.
ID
Estratégias
Aplicações (bytes) Web Services (bytes)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
SOAP REST
HTTP SSH HTTP SSH
Total Total
11 4938 4843,8 12151,067 11434,2 1776,8 4877,2 900,2 4891,4
6654 5791,6
Fonte: Elaborado pelo autor.
94
Tabela 12 – Valores médios dos tempos de resposta obtidos para a realização da tarefa
11.
ID
Estratégias
Aplicações (ms) Web Services (ms)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100 SOAP REST
11 548,167 568,2 765,133 768,8 407,067 398,367
Fonte: Elaborado pelo autor.
Através dos valores médios apresentados nas tabelas 11 e 12 podemos notar que a
aplicação CLI na VLAN com identificador 100 é a estratégia com a menor quantidade de
dados trafegados durante a execução. Percebemos através dessa tarefa que o protocolo
NETCONF arranjado sobre a VLAN 100 consome 57,63% mais bytes em cada requisição se
comparada à melhor estratégia. Validamos também que a estratégia com o menor tempo de
resposta continua como nas estratégias anteriores – sendo a alternativa que se fundamenta nos
conceitos de REST para a disponibilização das funcionalidades de gerenciamento de
configuração.
Apresentamos, através das tabelas 13 e 14, os resultados obtidos para as tarefas 12,
13 e 14. O agrupamento, nesse caso, foi realizado frente às tarefas que possibilitam a
alteração do estado de uma interface (porta) de rede através da sua configuração, ativação e
desativação. Para a tarefa 12, que realiza a configuração de uma interface no roteador, foram
informados, em cada execução, os mesmos parâmetros retornados pela tarefa 11; para as
tarefas 13 e 14 somente o número da porta foi atribuído como parâmetro de entrada para cada
tarefa, com o objetivo de realizar a ativação ou desativação da mesma.
Tabela 13 – Valores médios da quantidade de bytes trafegados durante a execução das
tarefas 12, 13 e 14.
ID
Estratégias
Aplicações (bytes) Web Services (bytes)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
SOAP REST
HTTP SSH HTTP SSH
Total Total
12 21826,2 21666,067 9825,267 8920,533 2235,133 21731,4 1185,6 21673,8
23966,533 22859,4
13 12467 12290,6 9674,267 8766,8 1769,4 12399,4 950 12415,6
14168,8 13365,6
14 12079,2 11899,8 9709,2 8753 1733 12008,53 947 11996,13
13741,533 12943,133
Fonte: Elaborado pelo autor.
95
Tabela 14 – Valores médios dos tempos de resposta obtidos para a realização das
tarefas 12, 13 e 14.
ID
Estratégias
Aplicações (ms) Web Services (ms)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100 SOAP REST
12 520,2 436,9 769,6 774,067 324,367 314,8
13 464,4 429,267 772,067 792,733 318,133 301,533
14 436,6 418,367 786,333 782,233 315,133 303,833
Fonte: Elaborado pelo autor.
Assim como nas tarefas 9 e 10, que tinham como objetivo a alteração de uma
funcionalidade do roteador, observamos que quanto aos valores médios dos dados trafegados
por cada estratégia para as tarefas 12, 13 e 14 a que se sobrepôs às demais foi também a
aplicação que utilizou o mapeamento desses comandos através do protocolo NETCONF na
VLAN 100. Nesse caso, utilizar a aplicação NETCONF possibilita uma economia de 58,82%,
28,67% e 26,44% durante a execução das mesmas funcionalidades quando comparada a CLI
nessa VLAN. Notamos novamente que a forma de realizar essas tarefas de maneira mais
rápida é através da disponibilização de web services REST.
4.3 DISCUSSÕES
Os resultados apresentados na seção anterior resumem o comportamento das tarefas
executadas através das estratégias estabelecidas neste trabalho. Se analisarmos, por meio do
agrupamento definido na seção 4.1, os valores médios para a métrica que mensurou a
quantidade de dados trafegados, verificamos uma similaridade comportamental das estratégias
frente às tarefas que alteram e recuperam as características do dispositivo de rede gerenciado.
Nesta seção, dentre outras discussões, buscamos encontrar o motivo dessa similaridade
escrutinando o sequenciamento das ações que envolvem a execução das tarefas em cada
estratégia. A tabela 15 agrupa os resultados quanto à geração de tráfego; através desse
agrupamento, podemos perceber o motivo para a realização de uma inspeção mais profunda.
96
Tabela 15 – Agrupamento dos valores médios da quantidade de bytes trafegados de
todas as tarefas.
Ação ID
Estratégias
Aplicações (bytes) Web Services (bytes)
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
SOAP REST
HTTP SSH HTTP SSH
Total Total
REC 1 7268,6 7238,4 11438,667 10726,333 3789,367 7074,6 3001,8 7115
10863,967 10116,8
REC
2 7690,2 7507,8 19453,233 18517,067 5346,8 7467,2 2196,4 7478
12814 9674,4
3 5003 4883,6 12335,4 11611,4 1607,8 4843 764,2 4843
6450,8 5607,2
ALT
4 12097,667 11898,333 2058,6 13509 1160,867 11819,6
15567,6 12980,467
5 12028 11861,2 1990,2 11979,33 1162,2 11953,6
13969,533 13115,8
6 12487,267 12376,2 2003,4 12505,8 1171,733 12497,13
14509,2 13668,867
7 9392,2 9219,8 1877 10564,6 1119 10606
12441,6 11725
REC 8 15588,6 15418,8 22669,5 21203,067 14921,13 15176,6 6743,6 15227
30097,733 21970,6
ALT
9 12761,6 12620,4 9479,4 8656,6 1937,067 12537,2 1016,967 12714,2
14474,267 13731,167
10 11793,133 11495,333 9471,333 8684 1874,367 11720,6 988,4 11669,2
13594,967 12657,6
REC 11 4938 4843,8 12151,067 11434,2 1776,8 4877,2 900,2 4891,4
6654 5791,6
ALT
12 21826,2 21666,067 9825,267 8920,533 2235,133 21731,4 1185,6 21673,8
23966,533 22859,4
13 12467 12290,6 9674,267 8766,8 1769,4 12399,4 950 12415,6
14168,8 13365,6
14 12079,2 11899,8 9709,2 8753 1733 12008,53 947 11996,13
13741,533 12943,133
Fonte: Elaborado pelo autor.
Nota: Legenda para a coluna denominada ação: ALT: Alteração de comportamento através de modificação de funcionalidade no dispositivo de rede;
REC: Recuperação das configurações do dispositivo de rede.
Começamos o exame procurando identificar o comportamento de dois segmentos
peculiares para os dados trafegados por meio das estratégias CLI e NETCONF. Esse
comportamento foi observado através da análise dos procedimentos de conexão e desconexão
de ambas as estratégias e, para tanto, coletamos os pacotes trafegados durante esses processos.
A captura para os procedimentos de conexão e desconexão ocorreu de maneira
semelhante quando da coleta dos dados trafegados por cada tarefa. Executamos ambos os
97
procedimentos 30 vezes em cada VLAN através das estratégias baseadas nas aplicações CLI e
NETCONF para, ao final, acumularmos um montante de 240 capturas de pacotes divididas
igualmente pelas estratégias dentro de cada VLAN. A não realização desses procedimentos
para WS REST e SOAP justifica-se pelo fato de que essas estratégias utilizam a API CLI
como intermediadora e os resultados alcançados, através da inspeção proposta, podem ser
expandidos para essas estratégias.
Com o objetivo de realizar essa crítica modificamos a estrutura da API CLI para que,
quando da coleta dos dados de conexão, a aplicação fosse finalizada após o procedimento de
abertura de sessão por meio da inclusão do comando System.exit dentro do método
execCommands, apresentado pelo quadro 8 da seção 3.3.1.1. Através dessa intervenção
conseguimos capturar somente os pacotes que envolveram o procedimento de conexão e não
todos os dados relativos à execução da tarefa. A coleta dos dados para o procedimento de
conexão através da aplicação CLI ocorreu da seguinte forma para ambas as VLANs:
iniciamos a ferramenta Wireshark para captura dos pacotes trafegados;
iniciamos a aplicação CLI;
a aplicação CLI conecta no dispositivo de rede;
a aplicação CLI, após a conexão com o dispositivo de rede, abre a sessão;
interrompemos a aplicação CLI após a conexão/abertura da sessão e antes da
execução da tarefa;
interrompemos a captura de pacotes através do Wireshark.
Cabe salientar que para a API CLI, responsável pelo procedimento de abertura de
conexão e sessão, somente o endereço IP, porta, usuário e senha são necessários para o
estabelecimento da comunicação com o dispositivo de rede.
O procedimento adotado para a estratégia NETCONF foi similar; contudo, não
alteramos a API NETCONF e sim a aplicação. Essa alteração se deu através da inclusão do
mesmo comando de parada, System.exit, após o envio do XML contendo a mensagem
<hello>, utilizado para o procedimento de abertura de sessão NETCONF, e antes da
execução do comando XML mapeado para a tarefa, conforme analisado no quadro 21 da
seção 3.3.1.3. Novamente, através desses comandos de controle, obtivemos somente os bytes
utilizados pelos mecanismos de conexão. A coleta dos pacotes utilizados durante a conexão
NETCONF ocorreu da seguinte maneira:
98
iniciamos a ferramenta Wireshark para captura dos pacotes trafegados;
iniciamos a aplicação NETCONF;
recebemos a mensagem XML com o elemento <hello> do dispositivo de rede
contendo uma lista de recursos suportados, bem como um identificador de
sessão;
enviamos ao dispositivo de rede a resposta para a mensagem <hello>
contendo os recursos que desejamos dispor durante a tarefa de configuração
para concretizarmos a abertura da sessão. Com o objetivo de mantermos a
consistência dos resultados essa mensagem de resposta enviada pelo cliente e
apresentada por esse item é a mesma utilizada durante a execução de cada
tarefa;
interrompemos a aplicação após a abertura de conexão/sessão NETCONF e
antes da execução da tarefa;
interrompemos a captura de pacotes através do Wireshark.
Realizados os procedimentos de coleta para as duas estratégias analisamos, através
da tabela 16, os dados trafegados durante o procedimento de conexão tanto para a VLAN 22
quanto na VLAN 100.
Tabela 16 – Valores médios da quantidade de bytes trafegados durante a conexão
utilizando CLI e NETCONF.
Estratégias (bytes)
Procedimento
CLI
VLAN
22
CLI
VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
Conexão 3776,4 3660,6 6924,8 6470,467
Fonte: Elaborado pelo autor.
Podemos notar que o procedimento de conexão através da estratégia CLI disposta na
VLAN com identificador 100, ou seja, no cenário onde a aplicação se encontra no mesmo
segmento de gerência dos equipamentos de rede, ocupa 2809,867 bytes a menos do que a
estratégia NETCONF disposta na mesma VLAN. Portanto, a sobrecarga de duas mensagens
no formato XML – uma enviada pelo dispositivo gerenciado contendo uma lista de recursos
disponíveis (quadro 26) e a outra, partindo do cliente contendo os recursos desejáveis para a
execução da tarefa (quadro 27) é 43,42% mais custosa do que um procedimento de conexão
SSH convencional através da estratégia CLI, na mesma VLAN, onde somente é informado
usuário, senha e porta.
99
Quadro 26 – Mensagem XML enviada pelo dispositivo no momento da conexão. <?xml version="1.0" encoding="UTF-8"?>
<hello>
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:capability:writeable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
<capability>urn:ietf:params:netconf:capability:url:1.0</capability>
<capability>urn:cisco:params:netconf:capability:pi-data-model:1.0</capability>
<capability>urn:cisco:params:netconf:capability:notification:1.0</capability>
</capabilities>
<session-id>732400044</session-id>
</hello> Fonte: Elaborado pelo autor.
Quadro 27 – Mensagem XML enviada pelo cliente para concretizar a conexão. <?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:capability:writeable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
<capability>urn:ietf:params:netconf:capability:url:1.0</capability>
<capability>urn:cisco:params:netconf:capability:pi-data-model:1.0</capability>
<capability>urn:cisco:params:netconf:capability:notification:1.0</capability>
</capabilities>
</hello>]]>]]>
Fonte: Elaborado pelo autor.
Conforme mencionado anteriormente, avaliamos a execução de ponta a ponta, ou
seja, medimos também os dados trafegados no momento da desconexão após a execução das
tarefas. Esse procedimento, na API CLI, deu-se através da inclusão de um temporizador com
o comando Thread.sleep e da indicação visual através do comando System.out.println, que
gera uma saída de texto. Através dessas diretivas tínhamos conhecimento de que o programa
entrou na instrução finally e iniciou o procedimento para encerramento da conexão. A adição
desses comandos se deu antes do encerramento da sessão no método execCommands
apresentado pelo quadro 8 da seção 3.3.1.1, sendo que quando recebíamos a indicação visual,
a conexão já havia sido realizada, a sessão já havia sido aberta e a tarefa executada. Após isso
tínhamos o tempo necessário, estabelecido pelo temporizador, para iniciarmos a ferramenta
Wireshark e realizarmos a captura somente dos pacotes relativos ao procedimento de
desconexão.
Para a captura dos pacotes de desconexão quando utilizamos a estratégia baseada em
NETCONF alteramos a aplicação incluindo os mesmos comandos Thread.sleep e
System.out.println com o objetivo de controlarmos o fluxo da aplicação. Esses comandos
foram incluídos após a execução da tarefa e antes do envio da mensagem XML close-session,
a qual informa o dispositivo de rede da necessidade de encerramento de sessão e desconexão.
Novamente, com o objetivo de manter a similaridade estrutural e dos resultados para a métrica
que trata dos dados trafegados, a mensagem de desconexão enviada pelo cliente foi a mesma
enviada no momento do término da conexão de cada tarefa executada através da aplicação
100
NETCONF. O procedimento de captura de pacotes trafegados utilizados durante a
desconexão se deu como segue:
iniciamos a ferramenta Wireshark para a captura dos pacotes trafegados após
a execução do comando de gerência de configuração;
enviamos ao dispositivo de rede uma mensagem XML <close-session/> que
trata da necessidade de encerramento da sessão e conexão;
recebemos a mensagem XML com o elemento <ok/>, o qual indica a correta
execução da última mensagem (o encerramento da sessão);
interrompemos a captura de pacotes através do Wireshark.
Após a coleta dos pacotes utilizados durante o procedimento de desconexão
analisamos, através da tabela 17, os resultados obtidos.
Tabela 17 – Valores médios da quantidade de bytes trafegados durante a desconexão
utilizando CLI e NETCONF.
Procedimento
Estratégias (bytes)
CLI VLAN
22
CLI VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
Desconexão 450,533 440 1516,667 1501,267
Fonte: Elaborado pelo autor.
Notamos, através dos resultados apresentados, que o tráfego das mensagens XML
exibidas por meio dos quadros 28 e 29 e utilizadas como mecanismos de controle pelo
protocolo NETCONF na VLAN 100 entre o cliente e o servidor, realizado no momento da
desconexão, adiciona 1061,267 bytes, ou seja, 70,69% mais dados quando comparado ao seu
concorrente, a estratégia CLI na mesma VLAN, onde a conexão é encerrada sem qualquer
mecanismo de controle adicional.
Quadro 28 – Mensagem XML enviada ao dispositivo de rede solicitando a desconexão. <?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="106" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>]]>]]>
Fonte: Elaborado pelo autor.
Quadro 29 – Mensagem XML enviada pelo dispositivo confirmando a desconexão. <?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="106" xmlns="urn:ietf:params:netconf:base:1.0">
<ok />
</rpc-reply>]]>]]>
Fonte: Elaborado pelo autor.
Através da tabela 18 totalizamos os dados utilizados nos procedimentos de conexão e
desconexão de cada estratégia e notamos que os métodos estabelecidos para essas ações, pela
101
API CLI na VLAN 100, oferecem uma economia de 48,56% se comparada à sua similar,
desenvolvida em NETCONF e disposta na mesma VLAN.
Tabela 18 – Soma dos valores médios da quantidade de bytes trafegados na conexão e
desconexão para CLI e NETCONF.
Procedimento
Estratégias (bytes)
CLI VLAN
22
CLI VLAN
100
NETCONF
VLAN 22
NETCONF
VLAN 100
Conexão 3776,4 3660,6 6924,8 6470,467
Desconexão 450,533 440 1516,667 1501,267
Total 4226,933 4100,6 8441,467 7971,734
Fonte: Elaborado pelo autor.
Observamos que mesmo com o tráfego adicional imposto pelo protocolo NETCONF
nos procedimentos de conexão e desconexão, essa estratégia, preparada na VLAN 100, é a
melhor abordagem quando se trata da alteração das características do dispositivo de rede
gerenciado – tarefas de número 9, 10 e 12 a 14. Atribuímos esse resultado à diferença do
retorno frente à concretização dos comandos. Na estratégia CLI, para possibilitarmos a
confiança de que o comando foi executado corretamente, precisamos devolver o retorno do
spool oriundo do dispositivo de maneira integral ao usuário, para que este possa visualizar e
analisar a ocorrência de algum erro. Quando utilizamos NETCONF esse procedimento é
abstraído por padrão pelo protocolo, retornando somente uma resposta no formato XML com
a confirmação de execução, no caso de sucesso, idêntica à apresentada pelo quadro 29.
Para as tarefas que recuperam as informações de configuração do dispositivo de rede
a estratégia CLI instalada na VLAN 100 é a abordagem, em todas as tarefas, que consome
menos bytes em uma visualização fim a fim da topologia. Se compararmos com NETCONF
atribuímos esse fato ao tráfego adicional de elementos XML dentro de cada resposta; logo,
quanto mais informações foram repassadas utilizando NETCONF, mais elementos XML
existirão em cada requisição e resposta. Se comparada às estratégias baseadas em web
services REST e SOAP, temos que considerar uma composição de tráfego: além dos bytes
utilizados pela API CLI para a realização das tarefas devem ser sumarizados na métrica os
dados do protocolo HTTP para entrega ao usuário.
Uma análise quanto ao tempo de resposta, apresentado pela tabela 19 através do
agrupamento de todas as tarefas, permite atestar a robustez do cenário proposto,
principalmente na utilização das estratégias que se baseiam em web services SOAP e REST.
Mesmo com uma hierarquia de protocolos maior e, portanto, uma sobrecarga adicional, tanto
em REST quanto em SOAP na inclusão de uma camada HTTP, notamos que frente a outras
102
estratégias, o tempo de resposta foi inferior em todas as tarefas. Essa característica demonstra
que a utilização de web services, os quais abstraem a lógica do negócio através do
mapeamento de comandos de gerência de configuração, conexão, execução e desconexão,
apresenta-se como uma ótima opção para o desenvolvimento de aplicações voltadas à
gerência de configuração. Para atingir esse nível de qualidade, esses web services devem ser
disponibilizados como proposto por este trabalho, ou seja, em um servidor específico e bem
dimensionado, que apresente duas interfaces de rede, sendo uma que realize a entrega dos
serviços ou recursos ao usuário e outra que esteja conectada à VLAN de gerenciamento do
dispositivo de interconexão controlado. Outro fato que justificou esses resultados frente aos
tempos de resposta das tarefas foi a utilização de um servidor de aplicação Linux que não
continha aplicações de sistema operacional voltadas aos usuários finais, executando única e
exclusivamente as tarefas responsáveis pelas intermediações das requisições desses web
services. Devido à possibilidade dos tempos de resposta alcançados serem distintos, quando
se utilizar um servidor de aplicação ou dispositivo cliente – hardware – que não o definido
neste trabalho, os valores médios alcançados por essa métrica foram normalizados pelo valor
máximo dos elementos, com o objetivo de ajustar as escalas para um mesmo intervalo.
Tabela 19 – Agrupamento dos valores médios dos tempos de resposta obtidos para
todas as tarefas.
Ação ID
Estratégias
Aplicações (ms) Web Services (ms)
CLI
VLAN 22
CLI
VLAN 100
NETCONF
VLAN 22
NETCONF
VLAN 100 SOAP REST
Média Norm. Média Norm. Média Norm. Média Norm. Média Norm. Média Norm.
REC 1 740,267 1,000 685,833 1,000 781,733 0,550 779,133 0,519 574,967 1,000 567,067 1,000
REC 2 580,9 0,785 556,567 0,812 1164,367 0,820 1097 0,731 408,633 0,711 403,133 0,711
3 548,9 0,741 586,933 0,856 778,533 0,548 773,9 0,516 398,967 0,694 394,233 0,695
ALT
4 454,533 0,614 460,933 0,672 324,333 0,564 305,8 0,539
5 453,467 0,613 447,433 0,652 308,867 0,537 302,167 0,533
6 485,133 0,655 456,5 0,666 310,3 0,540 303,7 0,536
7 388,367 0,525 400,3 0,584 307,767 0,535 299,767 0,529
REC 8 545,733 0,737 587,567 0,857 1420,667 1,000 1500,9 1,000 430,1 0,748 415,333 0,732
ALT 9 411,467 0,556 442,9 0,646 771,333 0,543 772,633 0,515 313,067 0,544 302,967 0,534
10 410,2 0,554 447,667 0,653 781,633 0,550 777,4 0,518 311,667 0,542 306,533 0,541
REC 11 548,167 0,740 568,2 0,828 765,133 0,539 768,8 0,512 407,067 0,708 398,367 0,703
ALT
12 520,2 0,703 436,9 0,637 769,6 0,542 774,067 0,516 324,367 0,564 314,8 0,555
13 464,4 0,627 429,267 0,626 772,067 0,543 792,733 0,528 318,133 0,553 301,533 0,532
14 436,6 0,590 418,367 0,610 786,333 0,553 782,233 0,521 315,133 0,548 303,833 0,536
Fonte: Elaborado pelo autor.
Nota: Legenda para a coluna: Norm.: Valores normalizados pelo valor máximo das médias, através da fórmula f(X) = X / máximo.
Como comentado anteriormente, nota-se que a estratégia REST, se comparada a
SOAP, é mais rápida. Cabe salientar que a única diferença entre os web services REST e
SOAP está na utilização de um protocolo específico para esse último. Podemos, portanto,
concluir com segurança que a diferença no tempo de resposta e também no consumo de dados
103
é devido ao protocolo SOAP, visto que o servidor de aplicação que antepara as duas
estratégias (bem como a API CLI, que serve de base para intermediar as requisições), é o
mesmo em ambas. As requisições, bem como suas respostas em web services SOAP, são
escritas em um formato de mesmo nome e envoltas em uma mensagem HTTP; já os web
services REST disponibilizados por esse trabalho não usam SOAP ou qualquer protocolo
adicional diferente do HTTP, permitindo a visualização das informações ao usuário através de
JSON e não dos elementos adicionais impostos por XML. Outro fator que torna a utilização
de web services REST retornando objetos JSON mais rápida e estável, como analisado em
todas as tabelas, é o fato de que para esses, diferente de SOAP, não existe a necessidade de
consumir processamento e tempo para a serialização e deserialização de documentos XML
em cada requisição, tanto por parte do usuário quanto por parte do servidor.
Apesar de web services imporem um maior nível na hierarquia de protocolos se
comparados às estratégias CLI e NETCONF, que não utilizam camadas adicionais para
visualização dos dados, podemos obter outro resultado quanto aos dados trafegados por cada
tarefa. Se não levarmos em consideração o tráfego fim a fim, ou seja, se isolarmos os dados
passantes entre o segmento do servidor de aplicação e o dispositivo gerenciado e analisarmos
somente a porção visível ao usuário (representada pela coluna denominada HTTP de cada
tarefa na tabela 15, coluna essa que apresenta os dados trafegados entre o servidor de
aplicação e o usuário), a estratégia que se baseia nos conceitos de REST, além de ser a mais
rápida, torna-se a menos consumista. Esse fato vem a atestar novamente o sucesso da
topologia na utilização de web services, pois além de abstraírem os procedimentos inerentes à
execução de uma tarefa, suprimem também os bytes necessários para os mecanismos de
concretização desses procedimentos, entregando ao usuário somente o que lhe é útil e de seu
interesse no momento, ou seja, somente o resultado final da tarefa.
Avaliamos também, por meio da segmentação proposta com a utilização das VLANs
com identificadores 22 para rede do NOC e 100 para rede de gerência, o nível de degradação
que um equipamento do tipo firewall traz durante a execução das tarefas de gerência de
configuração quando se utiliza as estratégias apresentadas. Por meio dos resultados agrupados
nas tabelas 15 e 19 notamos que a utilização desse equipamento não injeta tráfego adicional
na rede (somente a diferença de bytes que compõe o endereço IP e da VLAN nos pacotes), e
que os tempos de execuções das tarefas, quando os pacotes são liberados e redirecionados
entre redes, são insignificantes se levarmos em consideração os benefícios que um
equipamento desse tipo proporciona dentro de uma topologia de rede – isolamento do
104
domínio de gerência e a liberação de acesso de VLANs específicas, responsáveis pela
execução das tarefas pertinentes ao controle dos equipamentos de toda rede.
Cabe salientar que os resultados apresentados neste capítulo e discutidos de forma
abrangente nesta seção, por mais similares que sejam, não podem ser comparados em sua
totalidade aos apresentados na seção de trabalhos relacionados (isso porque os testes
realizados em cada um objetivavam a aferição do comportamento utilizando objetos
diferentes e não do dispositivo de rede testado por este trabalho). Porém, tomamos a liberdade
de confrontar com o trabalho de Anedda e Atzori (2009) – a pesquisa que proporcionou maior
grau de similaridade pela sua aréa fim, de alteração de VLANs em portas de switches das
marcas Cisco e HP, onde a utilização do protocolo SOAP, se comparado com as formas
tradicionais como SNMP, injeta uma quantidade considerável de dados na comunicação (o
que pode impactar negativamente no cenário da rede de gerenciamento). De acordo com a
tabela 15, observamos esse mesmo comportamento em nosso cenário, onde a estratégia
baseada em SOAP foi uma das abordagens que gerou mais tráfego durante a execução de cada
tarefa.
Com base nos resultados exibidos neste capítulo e também na identificação das
principais características responsáveis pela obtenção desses resultados, o capítulo a seguir
expõe as conclusões do presente trabalho quanto à escolha da estratégia mais adequada,
aplicável na execução da gerência de configuração de equipamentos de rede.
105
5 CONCLUSÕES
Neste trabalho foi apresentada uma comparação de estratégias para o gerenciamento
de configuração de dispositivos de rede, objetivando identificar a melhor abordagem por meio
da análise do tempo de resposta e do tráfego gerado durante a execução de um conjunto de
tarefas que recuperaram ou alteraram as configurações de um equipamento de interconexão de
redes – neste caso, um roteador da marca Cisco modelo 2921. Os dados utilizados na
comparação foram coletados a partir de quatro aplicações desenvolvidas neste trabalho e
baseadas em métodos CLI e NETCONF, e também em web services SOAP e REST, ambos
aderentes às arquiteturas SOA e ROA, respectivamente. Através dessas aplicações foi
mapeado e desenvolvido um conjunto de artefatos computacionais, os quais abstraíram a
complexidade e a heterogeneidade das tarefas rotineiramente executadas por administradores
de rede. Valendo-se da arquitetura e do mapeamento das tarefas de gerência de configuração
em aplicações, além das análises para as métricas estabelecidas, viabilizou-se também a
aplicabilidade do trabalho por meio da instrumentação e montagem de um cenário de testes
que simulou um ambiente real e típico de uma rede acadêmica ou empresarial.
Por meio da análise dos resultados apresentados e discutidos na seção anterior,
especificamente para a métrica que trata do tráfego gerado (número de bytes enviados e
recebidos durante a execução das tarefas dentro de cada estratégia), conclui-se que uma
abordagem de desenvolvimento híbrida é a alternativa que proporcionaria um menor impacto
em termos de tráfego na realização das tarefas de gerenciamento de configuração. Portanto,
empregando os métodos utilizados pela aplicação CLI para a consulta e a recuperação das
configurações do roteador (tarefas 1, 2, 3, 8 e 11) e os procedimentos impostos pela aplicação
NETCONF, que faz uso de um protocolo de gerência de configuração de mesmo nome para a
alteração do estado das configurações desse equipamento (tarefas 9, 10, 12, 13 e 14), têm-se o
melhor resultado para essa métrica desde que as tarefas sejam executadas no mesmo segmento
da rede de gerência. Cabe salientar que, conforme mencionado anteriormente, não podemos
estender essa lógica para as tarefas de número 4 a 7, as quais são responsáveis por modificar
as configurações de VLAN, pois suas execuções foram anuladas devido à impossibilidade de
realização dos testes sobre a aplicação que utilizou o protocolo NETCONF como proposta de
ferramenta. Para essas tarefas os melhores resultados foram alcançados pela aplicação CLI
conectada também à rede de gerência. Contudo, existe um tradeoff na utilização dessas
estratégias: escolhendo-se NETCONF para alteração do estado das configurações no
106
dispositivo, têm-se um menor tráfego de dados pela rede, mas aumenta-se o tempo de
execução das tarefas.
Por sua vez, se nos apoiarmos no desenvolvimento de aplicações de gerência de
configuração utilizando uma arquitetura distribuída e que possibilite a execução de tarefas
através de dispositivos cliente heterogêneos – desktops, notebooks e smartphones, por
exemplo – chegamos a uma conclusão oposta. Diferente da abordagem apresentada pelas
aplicações CLI e NETCONF, que podem ser descritas como aplicações monolíticas (interface
do usuário e códigos de acesso combinados em um único programa, instalados e executados
diretamente no computador do usuário), as estratégias baseada em web services apresentam os
melhores resultados para as duas métricas, proporcionando um menor tempo de resposta e um
menor tráfego de dados pela rede – levando em consideração para essa última métrica
somente as informações relevantes ao usuário, ou seja, o segmento de mão dupla entre o
cliente e o servidor de aplicação. Conclui-se, portanto, que para esse cenário o mapeamento
dessas tarefas de gerência de configuração utilizando os princípios de ROA através de web
services REST, que por sua vez abstraem todos os mecanismos de comunicação com o
dispositivo final gerenciado, apresenta-se como sendo a melhor estratégia.
As próximas sessões apresentam as contribuições alcançadas através deste trabalho,
bem como as dificuldades e limitações para o desenvolvimento da proposta. Ao final, este
capítulo é encerrado com uma proposta de trabalhos futuros a serem desenvolvidos.
5.1 CONTRIBUIÇÕES DO TRABALHO
Salienta-se que as contribuições deste estudo se resumem na complementaridade das
funcionalidades oferecidas pelo modelo FCAPS, mais especificamente na área funcional da
gerência de configuração através da composição e disponibilização de mecanismos adicionais
que visam: abstrair a complexidade da configuração de equipamentos de interconexão
heterogêneos por meio do mapeamento de tarefas em artefatos computacionais próprios;
reduzir o tráfego de dados de gerência na rede durante a execução das tarefas de configuração
sobre estes equipamentos; proporcionar um menor tempo de resposta e uma diminuição de
erros de provisionamento durante o atendimento à abertura de janelas de paradas programadas
que visam mudanças de topologia, correções de comportamentos anômalos ou o
estabelecimento de novos critérios de QoS ou SLA em uma porção da rede ou em um serviço
em particular. Destaca-se também que este estudo, precisamente através das estratégias CLI e
107
web services SOAP e REST, apresentou-se como uma opção para o gerenciamento de
configuração de dispositivos de rede que não suportem as especificações e facilidades
oferecidas pelo protocolo NETCONF, provendo assim a dissociação da forma de acesso
convencional (através da CLI) a partir do uso de um sistema de gerenciamento flexível.
Como contribuição secundária e levando-se em consideração o uso de web services
para fins de gerência de configuração, onde mapeamos e entregamos ao usuário serviços ou
recursos ocultando a lógica interna do negócio, pode-se oferecer aos administradores desses
ambientes, através da inclusão de novos componentes de hardware como, por exemplo,
servidores Virtual Private Network – Rede Virtual Privada (VPN), um modelo de
gerenciamento de rede como serviço – Network Management as a Service.
Como contribuição adicional e pelo desenvolvimento centrado no baixo acoplamento
e na separação em camadas, as APIs utilizadas pelas estratégias CLI e NETCONF podem ser
empacotadas e reutilizadas por outras aplicações.
Por fim, considera-se que esta pesquisa colaborou através do desenvolvimento de
ferramentas computacionais mais elaboradas e que aperfeiçoam o trabalho do administrador
de redes de forma considerável, oferecendo suporte e acompanhando o rápido
desenvolvimento de uma rede de computadores através da sobreposição dos problemas
apresentados pela variabilidade semântica na configuração de equipamentos heterogêneos –
premissa, na maioria das vezes, verdadeira em um backbone, ambiente acadêmico ou
empresarial – possibilitando que as atividades complexas de alteração de topologia sejam
executadas de forma rápida e menos onerosa na injeção de tráfego de gerência na rede.
5.2 DIFICULDADES E LIMITAÇÕES
Ressalta-se que foram encontradas dificuldades e limitações na pesquisa, as quais
merecem atenção.
O mapeamento das tarefas que envolveram a criação, exclusão e alteração de estado
ou nome de VLANs foram limitados pela impossibilidade de acesso, através do protocolo
NETCONF, ao módulo vlan-database do roteador utilizado. Essa limitação anulou a execução
dos testes propostos para as tarefas de número 4 a 7 e também de afirmar, para essas, a
conclusão anteriormente obtida: empregando-se NETCONF para a alteração do estado das
configurações têm-se um menor tráfego de dados de gerência na rede, em uma visualização
108
fim a fim, durante a comunicação entre o cliente e o dispositivo gerenciado, quando
comparadas as estratégias CLI, NETCONF e web services SOAP e REST.
Outra limitação deste estudo refere-se ao tempo de disponibilidade do equipamento
utilizado para os testes das estratégias propostas durante o desenvolvimento deste trabalho. O
pouco tempo impossibilitou a análise de métricas adicionais e principalmente a extensão dos
testes para o protocolo HTTPS, nas estratégias que se baseavam em web services. Utilizando
o referido protocolo poderíamos oferecer uma comparação, de certa forma mais justa, pois
estaríamos empregando mecanismos de segurança de ponta a ponta – assim como
possibilitado pelo protocolo SSH-2 nas aplicações CLI e NETCONF, instaladas e executadas
diretamente no computador do usuário.
O tempo de disponibilidade do equipamento para os testes elaborados nesta
dissertação também influenciou no tamanho da amostra. Com isso nos limitamos à execução
de 30 ciclos de experimentos para cada uma das 14 tarefas mapeadas dentro das quatro
estratégias, sendo que as estratégias CLI e NETCONF foram testadas em duas VLANs
distintas – método idêntico ao realizado durante a análise dos procedimentos de conexão e
desconexão utilizando essas formas de acesso. Esse valor de 30 ciclos é considerado pela
estatística como uma importância considerável de amostras para obtenção de um resultado
inicial. Não dispusemos de tempo hábil para executar um número mínimo de ciclos
necessários para cada tarefa (valendo-se dos cálculos sobre a média, desvio e erro padrão)
com objetivo de garantir uma maior credibilidade dos resultados através de um intervalo de
confiança alto. Poderíamos ter executado um número reduzido de tarefas de gerência de
configuração com o intuito de apresentar resultados mais concretos; porém, se reduzíssemos
esse número e por sua vez o seu tipo (recuperação ou alteração de configurações),
possivelmente pelos resultados obtidos, não realizaríamos as discussões adicionais descritas
no capítulo que abrange a análise dos resultados.
Outro fator limitante foi a impossibilidade de comparar esses resultados,
principalmente pela estratégia NETCONF, através da execução dos testes propostos em
outros equipamentos, pois como citado na definição do cenário, os testes foram executados
sobre um dispositivo físico real e não em componentes de interconexão virtuais.
Todas as dificuldades encontradas no desenvolvimento deste trabalho foram
superadas de alguma forma. Identificou-se uma delas durante o desenvolvimento da API
NETCONF e resolveu-se através da utilização do design pattern chamado singleton. Por meio
desse padrão foram alterados os procedimentos de abertura de conexão e sessão e
109
possibilitou-se, utilizando uma fábrica de conexões e sessões, a existência de uma única
instância para cada objeto. Com isso foram respeitadas as imposições apresentadas pelo
protocolo NETCONF, garantindo assim a correta troca de mensagens em uma única sessão.
Outra dificuldade encontrada foi a impossibilidade do mapeamento das tarefas de
gerência de configuração utilizando a linguagem YANG na camada de conteúdo, durante o
desenvolvimento da estratégia que fez uso do protocolo NETCONF. Como essa camada é
desprendida de padrões, ou seja, cada fornecedor de equipamento que deseje implementar o
referido protocolo é livre para especificar a sua forma, buscaram-se os procedimentos
adotados pelo dispositivo utilizado durante os testes e o mapeamento foi realizado seguindo a
definição proprietária.
5.3 TRABALHOS FUTUROS
Com relação a pesquisas futuras, sugere-se a alteração das estratégias baseadas em
web services por meio da inclusão do protocolo HTTPS, oferecendo mecanismos de
segurança de ponta a ponta para o desenvolvimento de uma futura aplicação distribuída. Após
a alteração dessas estratégias, propõe-se a repetição dos testes realizados neste trabalho a fim
de comparar o custo que uma sobrecarga adicional de segurança, imposta sobre o protocolo
HTTP, geraria sobre os resultados atuais.
Dada a simplicidade da comparação executada nesta dissertação, sugere-se também,
como proposta de trabalho futuro, a realização de uma inspeção mais profunda sobre o dataset
de pacotes de rede obtido. Analisando-se separadamente a hierarquia de protocolos podem-se
obter métricas adicionais em cada segmento da pilha de protocolos (IP, TCP, SSH e HTTP)
como: quantidade, duração e tamanho dos pacotes capturados em cada segmento, quantidade
de pacotes mal formados e consumo de banda. Por meio dessa análise particionada da pilha de
protocolos, pode-se elaborar uma conclusão mais apurada sobre o nível de invasão que a
execução das tarefas de gerência de configuração impõe sobre uma rede de produção.
Indica-se também como proposta de atividade futura uma coleta de indicadores de
desempenho de CPU e memória no dispositivo de rede gerenciado durante a execução das
estratégias CLI e NETCONF. Para esses futuros testes cabe uma observação: deve-se atentar
para que os mecanismos utilizados para coletas dos indicadores de desempenho (como
SNMP, por exemplo) não interfiram negativamente sobre os resultados das métricas. Através
da avaliação de desempenho realizada diretamente no equipamento gerenciado obtém-se uma
110
visão da estratégia que menos sobrecarrega o equipamento durante a sua execução e que, por
sua vez, possa interferir nos resultados obtidos por esta dissertação. Salienta-se que se pode
estender essa mesma medição sobre o equipamento do usuário, e com base nesses resultados
identifica-se a estratégia que menos sobrecarrega o dispositivo final em termos de consumo de
memória e processamento.
Propõe-se também como trabalho futuro a inclusão de mecanismos de compressão
para as APIs CLI e NETCONF, que utilizam o protocolo SSH durante a comunicação cliente
– roteador. Para a estratégia baseada em web services REST, além da utilização dos
mecanismos de compressão propostos, pode-se levar em consideração o uso de cache HTTP
através da inclusão de servidores específicos na topologia ou na ativação dessa característica
sobre os equipamentos já utilizados – servidor de aplicação e dispositivo cliente – com
objetivo de reduzir o tráfego de dados de gerência em segmentos específicos da rede.
Valendo-se da inclusão de tais funcionalidades e mediante a execução dos testes propostos
por esta dissertação, os valores resultantes podem ser agregados à comparação atual para, ao
final, identificar-se novos indicadores para as métricas estabelecidas.
Como sugestão de trabalho futuro propõe-se ainda o desenvolvimento de uma
abordagem híbrida, baseada na composição das quatro estratégias apresentadas, e
posteriormente compará-la com as estratégias individuais – SOA, ROA, CLI e NETCONF –
já avaliadas no presente trabalho. Através dos valores alcançados por meio do comparativo
proposto, pode-se avaliar o impacto, em termos de tráfego gerado e tempo de resposta, que a
composição de estratégias em uma única ferramenta causaria na rede, no momento da
configuração de dispositivos de interconexão.
Como proposta final, propõe-se o desenvolvimento de um aplicativo para
gerenciamento de configuração de dispositivos de rede, acessível através da internet, que
detenha, dentre outras qualidades, um design responsivo, adaptando-se automaticamente aos
mais variados dispositivos finais dos usuários e valendo-se da melhor estratégia desenvolvida
pela presente dissertação para este fim, ou seja, através do aprimoramento e inclusão de novas
funcionalidades por meio de web services REST.
111
REFERÊNCIAS
AKHTAR, J. YANG modeling of network elements for the management and monitoring
of Elastic Optical Networks. IEEE International Conference on Telecommunications and
Photonics (ICTP). [S.l.]: [s.n.]. 2015. p. 1-5.
AMBRA, T. et al. Resource-oriented design towards the convergence of Web-centric and
Telecom-centric services. Second International Conference on Future Generation
Communication Technology (FGCT). [S.l.]: [s.n.]. 2013. p. 120-125.
ANDRZEJ, J. Network Management and Security. In: A Guide to the Wireless Engineering
Body of Knowledge (WEBOK). [S.l.]: Wiley-IEEE Press, 2012. Cap. 3, p. 135-172.
ANEDDA, P.; ATZORI, L. Network Administration Using Web Services. IEEE Global
Telecommunications Conference (GLOBECOM). [S.l.]: [s.n.]. 2009. p. 1-6.
AUSTIN, D. et al. W3C. Web Services Architecture Requirements, 2004. Disponivel em:
<https://www.w3.org/TR/wsa-reqs/>. Acesso em: 24 Março 2016.
AUTENRIETH, A. et al. Optical network programmability- Requirements and
applications. International Conference on Photonics in Switching (PS). [S.l.]: [s.n.]. 2015. p.
321-323.
BAJPAI, V.; KREJCI, R. Managing SamKnows probes using NETCONF. IEEE Network
Operations and Management Symposium (NOMS). [S.l.]: [s.n.]. 2014. p. 1-2.
BAJPAI, V.; SCHÖNWÄLDER, J. NETCONF Interoperability Lab. IEEE Network
Operations and Management Symposium (NOMS). [S.l.]: [s.n.]. 2014. p. 1-2.
BELQASMI, F. et al. SOAP-Based vs. RESTful Web Services: A Case Study for Multimedia
Conferencing. IEEE Internet Computing, v. 16, p. 54-63, Julho 2012.
BERNERS-LEE, T.; FIELDING, R.; MASINTER, L. Uniform Resource Identifier (URI):
Generic Syntax. RFC 3986, 2005. Disponivel em: <http://tools.ietf.org/html/rfc3986>.
Acesso em: 3 Abril 2016.
BIERMAN, A.; BJORKLUND, M.; WATSEN, K. RESTCONF Protocol. Draft-ietf-netconf-
restconf-10, 2016. Disponivel em: <https://tools.ietf.org/html/draft-ietf-netconf-restconf-10>.
Acesso em: 4 Abril 2016.
BJORKLUND, M. YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF). RFC 6020, 2010. Disponivel em:
<https://tools.ietf.org/html/rfc6020>. Acesso em: Abril set. 2016.
BOUTABA, R.; POLYRAKIS, A. Projecting FCAPS to Active Networks. Enterprise
Networking, Applications and Services Conference Proceedings. Atlanta: IEEE. 2001. p. 97-
104.
112
BURBRIDGE, T. et al. Information Model for Large-Scale Measurement Platforms (LMAP)
- draft-ietf-lmap-information-model-09, 2016. Disponivel em: <https://www.ietf.org/id/draft-
ietf-lmap-information-model-09.txt>. Acesso em: 12 Abril 2016.
CLEMENT, L. et al. UDDI Spec TC. UDDI Version 3.0.2, 2004. Disponivel em:
<http://www.uddi.org/pubs/uddi_v3.htm>. Acesso em: 29 Março 2016.
COULOURIS, G. F. et al. Distributed Systems: Concepts and Design. 5ª. ed. New Jersey:
Pearson Education, 2011.
DOOLEY, M.; ROONEY, T. IPv6 Deployment and Management. [S.l.]: Wiley-IEEE Press,
v. 22, 2013. Cap. 7, p. 214.
DOUGLAS, R. M.; KEVIN, J. S. Essential SNMP. 2ª. ed. [S.l.]: O'Reilly Media, 2005.
DUGGAN, D. Enterprise Software Architecture and Design: Entities, Services, and
Resources. [S.l.]: Wiley-IEEE Press, 2012.
ELBADAWI, K.; YU, J. Improving Network Services Configuration Management.
Proceedings of 20th International Conference on Computer Communications and Networks
(ICCCN). [S.l.]: [s.n.]. 2011. p. 1-6.
ENNS, R. et al. Network Configuration Protocol (NETCONF). RFC 6241, 2011. Disponivel
em: <https://tools.ietf.org/html/rfc6241>. Acesso em: 5 Abril 2016.
FIELDING, R. Architectural Styles and the Design of Network-based Software
Architectures. Tese de Doutorado. University of California. 2000.
FILIPPETTI, M. A. CCNA 4.1: Guia Completo de Estudo. Florianópolis: Visual Books,
2011.
FOKAEFS, M.; STROULIA, E. Using WADL Specifications to Develop and Maintain
REST Client Applications. IEEE International Conference on Web Services (ICWS). [S.l.]:
[s.n.]. 2015. p. 81-88.
FOROUZAN, B. A. Comunicação de dados e Redes de Computadores. 4ª. ed. São Paulo:
McGraw-Hill, 2010.
GIOVANNI, B.; LUIGI, A. A Survey of SOA Technologies in NGN Network Architectures.
IEEE Communications Surveys Tutorials, v. 14, p. 644-661, 2012.
GIRBEA, A. et al. Design and Implementation of a Service-Oriented Architecture for the
Optimization of Industrial Applications. IEEE Transactions on Industrial Informatics, v.
10, p. 185-196, Fevereiro 2014.
GOLLING, M. et al. YANG2UML: Bijective transformation and simplification of YANG to
UML. 10th International Conference on Network and Service Management (CNSM). [S.l.]:
[s.n.]. 2014. p. 300-303.
GOROD, A.; SAUSER, B.; BOARDMAN, J. System-of-systems engineering management: A
review of modern history and a path forward. IEEE Systems Journal, Dezembro 2008. 484-
499.
113
GOYAL, P.; MIKKILINENI, R.; GANTI, M. FCAPS in the business services fabric
model. 18th IEEE International Workshops on Enabling Technologies: Infrastructures for
Collaborative Enterprises. WETICE'09. Groningen: IEEE. 2009. p. 45 - 51.
GRÜNER, S.; PALM, J. P. A. F. A RESTful extension of OPC UA. IEEE World
Conference on Factory Communication Systems (WFCS). [S.l.]: [s.n.]. 2015. p. 1-4.
GUIMARAES, V. T. et al. A Survey on Information Visualization for Network and Service
Management. IEEE Communications Surveys Tutorials, v. 18, p. 285-323, 2016.
GUO, X.; SHEN, J.; YIN, Z. On software development based on SOA and ROA. Control
and Decision Conference. [S.l.]: [s.n.]. 2010. p. 1032-1035.
HALLÉ, S.; CHERKAOUI, O.; VALTCHEV, P. Towards a semantic virtualization of
configurations. IEEE Network Operations and Management Symposium (NOMS). [S.l.]:
[s.n.]. 2012. p. 1268-1271.
HAUPT, F. et al. Service Composition for REST. IEEE 18th International Enterprise
Distributed Object Computing Conference (EDOC). [S.l.]: [s.n.]. 2014. p. 110-119.
HE, W.; XU, L. D. Integration of Distributed Enterprise Applications: A Survey. IEEE
Transactions on Industrial Informatics, v. 10, p. 35-42, Fevereiro 2014.
HEDSTROM, B. et al. Cable Networks, Services, and Management. 1ª. ed. New Jersey:
Wiley-IEEE Press, 2015.
INTERNATIONAL TELECOMMUNICATION UNION. M.3400: TMN management
functions. International Telecommunication Union, 2000. Disponivel em:
<https://www.itu.int/rec/T-REC-M.3400-200002-I/en>. Acesso em: 15 Março 2016.
JACOBS, S. Introduction in Security Management of Next Generation
Telecommunications Networks and Services. 1ª. ed. [S.l.]: Wiley-IEEE Press, 2014.
JOSUTTIS, M. N. SOA in practice: The Art of Distributed System Design. [S.l.]: O'Reilly
Media, 2008.
KIM, H.; FEAMSTER, N. Improving network management with software defined
networking. IEEE Communications Magazine, v. 51, p. 114-119, Fevereiro 2013. ISSN
0163-6804.
KREJCI, R. Building NETCONF-enabled network management systems with libnetconf.
IFIP/IEEE International Symposium on Integrated Network Management (IM 2013). [S.l.]:
[s.n.]. 2013. p. 756-759.
KUROSE, J. F.; ROSS, K. W. Redes de Computadores e a Internet: Uma Abordagem Top-
Down. 5ª. ed. São Paulo: Pearson, 2010.
LI, H. RESTful Web service frameworks in Java. IEEE International Conference on Signal
Processing, Communications and Computing (ICSPCC). [S.l.]: [s.n.]. 2011. p. 1-4.
114
LOUREIRO, D.; GONÇALVES, P.; NOGUEIRA, A. NETCONF agent for link state
monitoring. IEEE International Conference on Communications (ICC). [S.l.]: [s.n.]. 2012. p.
6565-6569.
LU, Z. et al. SOAMS: A Novel SOA-based System and Network Management Model and
Scheme. IEEE International Conference on Services Computing. SCC'08. Honolulu, HI,
USA: IEEE. 2008. p. 479 - 480.
LU, Z. et al. WSDSNM3: A Web Services-based Distributed System and Network
Management Middleware Model and Scheme. The 9th International Conference for Young
Computer Scientists. ICYCS. Hunan, China: [s.n.]. 2008. p. 392-397.
LUCHI, R.; MILLOT, M.; ELFERS, C. Resource oriented architecture and REST:
Assessment of impact and advantages on INSPIRE. Institute for Environment and
Sustainability. [S.l.]. 2008.
MAROTTA, M. A. et al. Evaluating management architectures for Internet of Things
devices. Wireless Days Conference. [S.l.]: [s.n.]. 2014. p. 1-7.
MATEOS, C. et al. Revising WSDL Documents: Why and How, Part 2. IEEE Internet
Computing, v. 17, p. 46-53, 2013.
MEDVED, J. et al. OpenDaylight: Towards a Model-Driven SDN Controller architecture.
IEEE 15th International Symposium on a World of Wireless, Mobile and Multimedia
Networks (WoWMoM). [S.l.]: [s.n.]. 2014. p. 1-6.
NADAS, S. Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6. RFC
5798, 2010. Disponivel em: <http://tools.ietf.org/html/rfc5798>. Acesso em: 21 Março 2016.
NARISETTY, R. et al. OpenFlow Configuration Protocol: Implementation for the of
Management Plane. Second GENI Research and Educational Experiment Workshop (GREE).
[S.l.]: [s.n.]. 2013. p. 66-67.
NUNES, T. M. et al. Towards a Distinction between Application State Resources and
Data Resources in ROA. IEEE International Conference on Computer and Information
Technology; Ubiquitous Computing and Communications; Dependable, Autonomic and
Secure Computing; Pervasive Intelligence and Computing. [S.l.]: [s.n.]. 2015. p. 895-900.
ODOM, W. CCENT/CCNA ICND1: Guia Oficial de Certificação Do Exame. 2ª. ed. Rio De
Janeiro: Cisco, 2008.
OH, S. W.; KIM, H. S. Decentralized access permission control using resource-oriented
architecture for the Web of Things. 16th International Conference on Advanced
Communication Technology. [S.l.]: [s.n.]. 2014. p. 749-753.
OPENDAYLIGHT Platform, 2016. Disponivel em: <https://www.opendaylight.org/>. Acesso
em: 10 Abril 2016.
OVERDICK, H. The Resource-Oriented Architecture. IEEE Congress on Services. [S.l.]:
[s.n.]. 2007. p. 340-347.
115
PAPAZOGLOU, M. P.; HEUVEL, W.-J. V. D. Service oriented architectures: approaches,
technologies and research issues. The VLDB Journal, v. 16, p. 389-415, 2007.
PAUTASSO, C. RESTful Web service composition with BPEL for REST. Sixth
International Conference on Business Process Management. [S.l.]: [s.n.]. 2009. p. 851 - 866.
POLÔNIA, P. V.; MELGAREJO, L. F. B.; QUEIROZ, M. H. D. A resource oriented
architecture for Web-integrated SCADA applications. IEEE World Conference on Factory
Communication Systems (WFCS). [S.l.]: [s.n.]. 2015. p. 1-8.
PRIETO, A. G.; LEUNG, A.; ROCKWELL, K. Automating the testing of RESTCONF
agents. IFIP/IEEE International Symposium on Integrated Network Management (IM). [S.l.]:
[s.n.]. 2015. p. 984-989.
PULIER, E.; TAYLOR, H. Compreendo SOA Corporativa. Rio de Janeiro: [s.n.], 2008.
RICHARDSON, L.; RUBY, S. RESTful Web Services. California: O’Reilly, 2007.
ROSEN, M. et al. Applied SOA: Service-Oriented Architecture and Design Strategies. [S.l.]:
John Wiley & Sons, 2012.
SANTOS, C. et al. Service Oriented Architecture for Data Visualization in Smart
Devices. 19th International Conference on Information Visualisation (iV). Barcelona: [s.n.].
2015. p. 561-567.
SANTOS, P. R. D. P. F.; ESTEVES, R. P.; GRANVILLE, L. Z. Evaluating SNMP,
NETCONF, and RESTful web services for router virtualization management. IFIP/IEEE
International Symposium on Integrated Network Management (IM). [S.l.]: [s.n.]. 2015. p.
122-130.
SASSI, A. B. et al. Integrated management of 10G-PON network element using
NETCONF and OpenFlow. 10th International Conference on Network and Service
Management (CNSM). [S.l.]: [s.n.]. 2014. p. 364-367.
SCHOENWAELDER, J.; BAJPAI, V. Using RESTCONF with LMAP Measurement Agents
- draft-ietf-lmap-restconf-02.txt, 2016. Disponivel em: <https://www.ietf.org/id/draft-ietf-
lmap-restconf-02.txt>. Acesso em: 12 Abril 2016.
SEHGAL, A. et al. Management of resource constrained devices in the internet of things.
IEEE Communications Magazine, v. 50, p. 144-149, Dezembro 2012. ISSN 0163-6804.
SERRANO, N.; HERNANTES, J.; GALLARDO, G. Service-Oriented Architecture and
Legacy Systems. IEEE Software, v. 31, p. 15-19, 2014.
SHENG, Q. Z. et al. Web services composition: A decade’s overview. Information Sciences,
v. 280, p. 218 - 238, 2014.
SINGH, S. R. et al. A RESTful web networking framework for vital sign monitoring.
IEEE International Conference on Communications. [S.l.]: [s.n.]. 2015. p. 524-529.
116
SINH, A. et al. Implementation of ICMP based Network Management System for
heterogeneous networks. 2nd International Conference on Computing for Sustainable Global
Development. INDIACom. New Delhi: [s.n.]. 2015. p. 382-387.
STADLER, R. Protocols for Distributed Embedded Management. In: Network-Embedded
Management and Applications: Understanding Programmable Networking Infrastructure.
New York, NY: Springer New York, 2013. Cap. 13, p. 263-290.
STALLINGS, W. Redes e Sistemas de Comunicação de Dados. 5ª. ed. Rio de Janeiro:
Elsevier, 2005.
STEINMETZ, P. Measuring and limiting the covert channel risk of XML document
transmission. International Conference on Military Communications and Information
Systems (ICMCIS). [S.l.]: [s.n.]. 2015. p. 1-9.
SUN, Z.; STRANG, K. D.; YEARWOOD, J. Analytics Service Oriented Architecture for
Enterprise Information Systems. Proceedings of the 16th International Conference on
Information Integration and Web-based Applications & Services. Hanoi: ACM. 2014. p. 508-
516.
TANENBAUM, A. S.; STEEN, M. V. Distributed Systems: Principles and Paradigms. 2ª.
ed. [S.l.]: Prentice Hall, 2006.
TAVARES, P.; GONÇALVES, P.; OLIVEIRA, J. L. An IDE for NETCONF management
applications. 7th Latin American Network Operations and Management Symposium
(LANOMS). [S.l.]: [s.n.]. 2011. p. 1-8.
TEKLI, J. M. et al. SOAP Processing Performance and Enhancement. IEEE Transactions on
Services Computing, v. 5, p. 387-403, 2012.
TERAMOTO, Y. et al. Managing Networks Independently of the Physical Topology by
Service Defined Network. IEEE 37th Annual Computer Software and Applications
Conference Workshops (COMPSACW), 22-26 Julho 2013. 650 - 655.
VILALTA, R. et al. The need for a Control Orchestration Protocol in research projects
on optical networking. European Conference on Networks and Communications (EuCNC).
[S.l.]: [s.n.]. 2015. p. 340-344.
WASSERMAN, M. Using the NETCONF Protocol over Secure Shell (SSH). RFC 6242,
2011. Disponivel em: <https://tools.ietf.org/html/rfc6242>. Acesso em: 8 Abril 2016.
WEISS, M. M.; SOLOMON, M. G. Auditing It Infrastructures for Compliance. 2ª. ed.
[S.l.]: Jones & Bartlett Publishers, 2015.
WONG, A. K. Y. et al. Ontology mapping for the interoperability problem in network
management. IEEE Journal on Selected Areas in Communications, v. 23, p. 2058-2068,
Outubro 2005.
XU, H.; XIAO, D. A common ontology-based intelligent configuration management
model for IP network devices. First International Conference on Innovative Computing,
Information and Control. ICICIC '06.. [S.l.]: IEEE. 2006. p. 385-388.
117
XUE, Y.; ZHANG, C.; JI, Y. RESTful Web Service Matching Based on WADL.
International Conference on Cyber-Enabled Distributed Computing and Knowledge
Discovery (CyberC). [S.l.]: [s.n.]. 2015. p. 364-371.
YU, J.; AJARMEH, I. A. An Empirical Study of the NETCONF Protocol. Sixth
International Conference on Networking and Services (ICNS). [S.l.]: [s.n.]. 2010. p. 253-258.
ZHOU, W. et al. REST API Design Patterns for SDN Northbound API. 28th International
Conference on Advanced Information Networking and Applications Workshops (WAINA).
[S.l.]: [s.n.]. 2014. p. 358-365.
118
APÊNDICE A – LISTAGEM DOS COMANDOS CLI
Quadro 30 – Comandos CLI para as tarefas de gerência de configuração.
ID Comando CLI
1 show running-config
2 show vlan-switch brief
3 show vlan-switch id VLANid
4
vlan database
vlan VLANid name VLANName state VLANState
apply
exit
5
vlan database
vlan VLANid state VLANState
apply
exit
6
vlan database
vlan VLANid name VLANName
apply
exit
7
vlan database
no vlan VLANid
apply
exit
8 show ip route
9 conf t
ip route destination destinationPrefixMask forwardingRoutersAddress
end
10 conf t
no ip route destination destinationPrefixMask
end
11 show running-config interface gigabitEthernet interface
12
conf t
interface GigabitEthernet interface
ip address address subnetMask
mtu MTU
description DESCRIPTION
no shutdown
end
13
conf t
interface GigabitEthernet interface
shutdown
end
14
conf t
interface GigabitEthernet interface
no shutdown
end
Fonte: Elaborado pelo autor.
Nota: Os trechos de configuração realçados em negrito são substituídos por parâmetros de métodos no
momento da implementação.
119
APÊNDICE B – LISTAGEM DOS COMANDOS NETCONF
Quadro 31 – Comandos NETCONF para as tarefas de gerência de configuração.
ID Comando NETCONF
1
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>]]>]]>
2
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter>
<oper-data-format-text-block>
<show>vlan-switch</show>
</oper-data-format-text-block>
</filter>
</get>
</rpc>]]>]]>
3
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter>
<oper-data-format-text-block>
<show>vlan-switch id VLANid</show>
</oper-data-format-text-block>
</filter>
</get>
</rpc>]]>]]>
4 ¹
5 ¹
6 ¹
7 ¹
8
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter>
<oper-data-format-text-block>
<show>ip route</show>
</oper-data-format-text-block>
</filter>
</get>
</rpc>]]>]]>
9
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<cli-config-data>
<cmd>ip route destination destinationPrefixMask forwardingRoutersAddress</cmd>
</cli-config-data>
</config>
</edit-config>
</rpc>]]>]]>
10
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<cli-config-data>
<cmd>no ip route destination destinationPrefixMask</cmd>
</cli-config-data>
</config>
</edit-config>
</rpc>]]>]]>
11 <?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
120
<filter>
<oper-data-format-text-block>
<show>running-config interface gigabitEthernet interface</show>
</oper-data-format-text-block>
</filter>
</get>
</rpc>]]>]]>
12
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<cli-config-data>
<cmd>interface GigabitEthernet interface</cmd>
<cmd>ip address address subnetMask</cmd>
<cmd>mtu MTU</cmd>
<cmd>description DESCRIPTION</cmd>
</cli-config-data>
</config>
</edit-config>
</rpc>]]>]]>
13
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<cli-config-data>
<cmd>interface GigabitEthernet interface</cmd>
<cmd>no shutdown</cmd>
</cli-config-data>
</config>
</edit-config>
</rpc>]]>]]>
14
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<cli-config-data>
<cmd>interface GigabitEthernet interface</cmd>
<cmd>shutdown</cmd>
</cli-config-data>
</config>
</edit-config>
</rpc>]]>]]>
Fonte: Elaborado pelo autor.
Nota: Os trechos de configuração realçados em negrito são substituídos por parâmetros de métodos no
momento da implementação.
1
Tarefas de 4 a 7 não apresentam suporte, através do protocolo NETCONF, no equipamento alvo
utilizado para execução das tarefas de gerência de configuração.
121
APÊNDICE C – TAREFAS MAPEADAS EM WS REST
Quadro 32 – Tarefas de gerência de configuração transformadas em web services REST.
ID Recurso URI Método
HTTP Tipos e nomes de parâmetros da URI
1 CONFIG /{address}/configuration/runnning/ GET Path {address}
2 VLAN /{address}/vlan/all GET Path {address}
3 VLAN /{address}/vlan/{vlanid} GET Path {address}
{vlanid}
4 VLAN /{address}/vlan/{vlanid} PUT
Path {address}
{vlanid}
Query name
status
5 VLAN /{address}/vlan/{vlanid} PUT Path
{address}
{vlanid}
Query status
6 VLAN /{address}/vlan/{vlanid} PUT Path
{address}
{vlanid}
Query name
7 VLAN /{address}/vlan/{vlanid} DELETE Path {address}
{vlanid}
8 TBRE /{address}/routes/static GET Path {address}
9 TBRE /{address}/routes/static/{destination} PUT
Path {address}
{destination}
Query destinationPrefixMask
forwardingRoutersAddress
10 TBRE /{address}/routes/static/{destination} DELETE Path
{address}
{destination}
Query destinationPrefixMask
11 IFACE /{address}/ports/{port}/ GET Path {address}
{port}
12 IFACE /{address}/ports/{port}/ PUT
Path {address}
{port}
Query
interfaceAddress
subnetMask
MTU
description
13 IFACE /{address}/ports/{port}/up PUT Path {address}
{port}
14 IFACE /{address}/configuration/ports/{port}/ DELETE Path {address}
{port}
Fonte: Elaborado pelo autor.
Nota: Legenda para a coluna denominada recurso: CONFIG: Configurações do dispositivo de rede;
VLAN: Virtual Lans – Rede Local Virtual (VLANs);
TBRE: Tabela de Roteamento Estático;
IFACE: Interface de rede.
Legenda para a coluna denominada tipos e nomes de parâmetros da URI:
Path: Parâmetros inseridos diretamente na URI;
Query: Parâmetros adicionais passados explicitamente na URI e inseridos após o sinal de interrogação
(?).
122
APÊNDICE D – TAREFAS MAPEADAS EM WS SOAP
Quadro 33 – Tarefas de gerência de configuração transformadas em web services SOAP. ID Métodos Parâmetros de entrada
1 getRunningConfigurationRouter address
2 getAllVLANs address
3 getSpecifiedVLAN address
VLANid
4 setNewVLAN
address
VLANid
name
state
5 updateVLANState
address
VLANid
state
6 updateVLANName
address
VLANid
name
7 deleteVLAN address
VLANid
8 getStaticRoutes address
9 setNewRoute
address
destination
destinationPrefixMask
forwardingRoutersAddress
10 deleteRoute
address
destination
destinationPrefixMask
11 getPortConfigurationRouter address
port
12 configureInterface
address
port
interfaceAddress
subnetMask
MTU
description
13 noShutdownInterface address
port
14 shutdownInterface address
port
Fonte: Elaborado pelo autor.