Rede x aplicativo: A culpa não é minha!

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.

Compartilhar

12 diferenças entre um bom engenheiro de TI e um ótimo engenheiro de TI

Por Don Thomas Jacob

Nas operações diárias de qualquer organização, normalmente os usuários finais são aqueles responsáveis por uma ampla gama de ações que comprometem a segurança e/ou o desempenho da rede.

No entanto, até mesmo os profissionais de TI têm seus maus hábitos: ignorar usuários, não fazer backups, não ter procedimentos definidos e outros pecados de TI. Para lembrá-los de que mesmo os gurus da rede são humanos, veja a seguir a 12 diferenças da SolarWinds entre um BOM engenheiro de TI e um ÓTIMO engenheiro de TI:

1. Aquisição de recursos
Quando quer recursos adicionais, o profissional da rede precisa se justificar para consegui-los. Um bom engenheiro envia e-mails para o chefe solicitando mais orçamento. Um ótimo engenheiro utiliza seus sistemas de monitoramento para criar uma lista completa da utilização de cada dispositivo e mostrar como investimento adicional em hardware ou em largura de banda melhorará a utilização dos recursos e aumentará a eficiência do negócio.

2. Identifique os alertas críticos
Um número excessivo de alertas significa que os administradores de rede não conseguirão ver os alarmes mais críticos. Um ótimo engenheiro cria cronogramas de alertas que avisam apenas dos problemas mais graves e garantem que a pessoa certa, com as habilidades certas, receba um alerta.

3. Além do monitoramento
Um bom engenheiro monitora a rede. Um ótimo engenheiro desenvolve painéis capazes de apresentar todos os dados necessários para encontrar dificuldades antes que elas causem problemas reais aos usuários, como problemas relacionados com armazenamento ou com sobrecarga nos pontos de acesso sem fio.

4. Estações de pânico
Nunca espere o telefone tocar com a notícia de uma pane na rede – um ótimo engenheiro deve se certificar de que será o primeiro a ficar sabendo de um problema.

5. Compartilhe conhecimentos
Como a TI é uma parte essencial de qualquer negócio, um ótimo engenheiro deve utilizar sua compreensão da rede para manter a gerência e os usuários chave informados sobre o desempenho de seus recursos e o que ele pode fazer para ajudar a melhorar uma situação difícil.

6. “Vou documentar mais tarde”
Um bom engenheiro pode adicionar, remover ou distribuir ativos, ou atribuir ou alterar endereços IP, mas, quando chega a hora do almoço, pode deixar para documentar tudo isso mais tarde… e muitas vezes se esquece! Um ótimo engenheiro registra as alterações imediatamente. Mesmo um sistema básico de gerenciamento de alterações que facilite o registro de mudanças é melhor que nenhum. Uma documentação incompleta ou desatualizada é fonte de problemas.

7. “Vou resolver”
A TI é uma peça tão essencial ao negócio que, se houver uma pane ou falha de hardware – em um computador individual ou em um dos sistemas principais – um ótimo engenheiro definirá prazos de respostas e notificações à equipe. O help desk deve confirmar o recebimento de um tíquete no momento em que ele chega, com feedback claro sobre prazos de resposta e opções de encaminhamento caso eles não sejam satisfatórios.

8. Não deixe as novidades para amanhã
Quando surgem novas tecnologias – como virtualização, nuvem ou BYOD – um ótimo engenheiro não as deixa para o dia seguinte nem espera que outra pessoa procure se informar sobre elas. Novas tecnologias são inevitáveis e sempre vale a pena aprender algo novo.

9. Fórmula para o desastre
Não deixe que uma enorme falha seja o gatilho para se criar um plano de recuperação de desastres: desenvolva e teste o plano com antecedência. Um ótimo engenheiro garante a implantação de um plano de contingência, o backup dos dados e a prova de êxito das restaurações. Reveja o plano e agende simulações regulares de desastres, mesmo que seja apenas uma vez por ano ou quando novos administradores assumirem funções relacionadas à recuperação.

10. Senha – aprovar ou rejeitar
Muitos administradores de rede tendem a usar a mesma senha em vários servidores, aplicativos e dispositivos de rede. Se um usuário não aprovado obtiver acesso a um só sistema menos crítico, será extremamente fácil comprometer o núcleo dos sistemas críticos usando a senha mestre.

11. Policie os administradores
Você tem políticas de acesso e auditoria implantadas para usuários, mas você também policia seus administradores? Muitas vezes pensamos que adicionar procedimentos à carga de trabalho dos administradores os sobrecarregará, impedindo que resolvam uma situação de emergência. No entanto, a desculpa de “fazer as coisas mais rápido” não deve significar a não supervisão dos administradores, mesmo os mais antigos. Um ótimo engenheiro implementa um mecanismo simples de auditoria e revisão ocasional de acesso. Para equipes maiores com níveis diferentes, implemente controles baseados em funções, correspondentes às responsabilidades de cada um.

12. Ignore o planejamento de capacidade
Muitos administradores de TI esperam a escassez dos ativos (equipamentos de rede, PCs, servidores, dispositivos móveis, rede sem fio, armazenamento etc.) para solicitar equipamentos adicionais. Um ótimo engenheiro está pronto para situações como um alto volume inesperado ou falhas simultâneas, especialmente quando o fornecedor leva algum tempo para disponibilizar o equipamento.

*Don Thomas Jacob é um “geek” chefe da SolarWinds, fornecedora de softwares de gerenciamento de TI com sede em Austin, no Texas.

Compartilhar