Por Don Jacob
“Deve ser a rede!” São exatamente essas as palavras que ouvimos quando um aplicativo está lento, a transferência de dados não é rápida o suficiente ou as ligações por VoIP ficam caindo. É óbvio que a rede existe para dar suporte à funcionalidade de que um aplicativo necessita e fornecer valor comercial para a organização. Assim, se alguma coisa não funciona como esperado, na maioria das vezes, os usuários culpam a rede.
Os administradores de rede aceitam isso: eles estão conscientes dos fatores de rede que podem afetar o desempenho dos aplicativos. Entre esses fatores estão largura de banda insuficiente destinada à WAN, tráfego de rede não comercial consumindo toda a largura de banda, alta latência, prioridade incorreta ou sem QoS, alternância de rota, integridade dos dispositivos de rede ou erros de configuração. E, acredite se quiser, a principal causa para o mau desempenho dos aplicativos pode ser o próprio aplicativo!
O mau desempenho de um aplicativo pode ser consequência do design do aplicativo: excesso de elementos ou de conteúdo no programa, múltiplas conexões para cada solicitação do usuário, consultas lentas e de longa duração, perda de memória, bloqueio de segmentos ou um esquema de banco de dados deficiente que retarda a recuperação dos dados. Diga isso para o desenvolvedor do aplicativo, e provavelmente ele vai apontar o dedo acusador para o administrador do banco de dados; a causa pode ser problemas de indexação, o fato de a SAN compartilhar E/S e armazenamento subjacente com vários aplicativos, banco de dados corrompido etc. Também não podemos esquecer o papel do hardware e do sistema operacional. Problemas de hardware, como servidor muito utilizado, falta de espaço em disco livre, desempenho insatisfatório de disco, janela TCP com tamanho incorretamente configurado, múltiplas tarefas em segundo plano e um SO desatualizado, também podem ser responsáveis pela lentidão de um aplicativo.
Será que a rede tem metade dessas razões que afetam o desempenho dos aplicativos? Mas ainda não ganhamos a discussão – não até provarmos que a rede está ótima. Quando muitos usuários reclamam que vários aplicativos rodando em servidores diferentes em um data center remoto estão lentos, só pode ser culpa da rede, certo?
Provando que não é a rede:
“Acho que a rede está lenta.” Todas as vezes que a rede leva a culpa, o administrador deve começar a discussão com o SNMP. Acione a ferramenta de monitoramento de rede e verifique a integridade e o status dos dispositivos da rede. As ferramentas de SNMP podem fornecer muitas informações úteis. Ao monitorar roteadores e switches com SNMP, veja se havia alternâncias de rota (“route flaps”), perda de pacotes, aumento no RTT e na latência, e também se a utilização de CPU ou de memória do dispositivo estava alta.
“Talvez o seu link WAN não seja compatível com o meu aplicativo.” O Cisco IPSLA pode enviar pacotes sintéticos e informar a capacidade ou a disponibilidade do link de rede para gerenciar o tráfego IP com protocolos TCP e UDP ou informar especificamente o desempenho de VoIP, RTT etc. Assim, se os pacotes sintéticos gerados pelo Cisco IPSLA para combinar com o protocolo do aplicativo são aceitos, por que não o tráfego real do aplicativo?
“Temos largura de banda suficiente?” Existe uma ferramenta para isso também! Os dados do NetFlow vindos dos dispositivos de roteamento e comutação podem informar o uso da largura de banda, dizendo o quanto de um link WAN está sendo utilizado, quais aplicativos estão usando, que end points estão envolvidos e até informar a prioridade ToS de cada conversa por IP.
“Poderia ter algo a ver com as prioridades QoS?” Usando uma ferramenta de monitoramento compatível com a geração de relatórios do Cisco CBQoS, você pode validar o desempenho de suas políticas de QoS: quais são as estatísticas de pré- e pós-política, se há muito buffer ou quanto tráfego está sendo descartado para cada política e classe de QoS. Se suas políticas de QoS estão funcionando da forma esperada, o que sobra, então?
“E agora?” Para o administrador de rede que ainda não ganhou a discussão (ou adora ficar discutindo), a resposta é a chamada “inspeção profunda de pacotes” (DPI, na sigla em inglês). A visibilidade que o DPI fornece é praticamente ilimitada: informações de rendimento, detalhes de segmentos fora de ordem, detalhes de “handshake”, retransmissões e todas as informações de que você vai precisar para provar que não é a rede, e também para descobrir as causas reais para o fraco desempenho do aplicativo.
Com a tecnologia e as ferramentas adequadas, o administrador da rede pode provar que a culpa não é da rede. Mas, também é importante ser proativo e garantir que os nós essenciais da rede estão sendo vigiados com uma boa ferramenta de monitoramento e que os aplicativos críticos têm prioridade na rede. O monitoramento ajuda a detectar e resolver pequenos problemas antes que se tornem graves, e a priorização garante a entrega dos dados do aplicativo.
“Hmm, então deve ser o banco de dados… Vou falar com a equipe de lá!”
Don Thomas Jacob é “geek” chefe da SolarWinds, fornecedora de softwares de gerenciamento de TI com sede em Austin, no Texas.