contemporaine : les héritages du passé
III. Les expériences autoritaires postcoloniales
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.
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
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:
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.
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
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
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
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
é 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
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.
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