Hei, desenvolvedores, vocês sabem mesmo o que é uma WAN?

Confira nossos E-books e Cursos on-line completos!

Introdução ás Redes WAN 1a edição 2013 bat e blog

Hei, desenvolvedores, vocês sabem mesmo o que é uma WAN?

Do original Hey, devs, do you even know what a WAN is? By http://www.infoworld.com.

Um projeto de migração de mainframe conturbado atinge outro obstáculo: a ignorância de interconexão de redes do time do desenvolvimento

Nós, como seres humanos e, sim, até mesmo os departamentos de TI, podem ser nosso pior inimigo, especialmente quando ignoramos o conceito básico de comunicação. Na nossa empresa, o contato limitado entre os desenvolvedores e nosso grupo de administração da rede quase afunda um projeto.

Muitos anos atrás, nós iniciamos planos para uma migração com promessas vagas de reduzir custos e complexidade de sistemas de computação “jurássicos”. A iteração atual deste projeto foi iniciada há alguns anos atrás, ainda que com passos travados que continua puxando o processo para trás. A migração foi prevista para ser concluída rapidamente mas estamos apenas a um terço do caminho.

A fim de desligar o mainframe, todos os sistemas teriam que ser migrados para outras plataformas, como Unix, Linux ou Windows.

O projeto começou bem o suficiente, mas rapidamente ficou para trás. Empreiteiros foram contratados, peritos foram consultados e, eventualmente, a decisão foi tomada para se mover a função de mainframe para uma localização remota de propriedade de um contratado e executado a partir de seu centro de dados.

Um projeto lento fica ainda atrasado
No entanto, o projeto está enfrentando problema após problema, e na realidade nós não estaremos fora de nossa casa do mainframe por algum tempo. Uma dessas razões: A desconexão entre os desenvolvedores e a equipe de networking.

Como especialistas em rede que lidam com switches, roteadores e firewalls, nossa equipe sempre tentou ficar à frente da curva de largura de banda. Temos dedicado largura de banda, políticas de qualidade de serviço, VPN backup e aceleração de WAN, para citar algumas ferramentas que usamos para manter a rede funcionando.

Como o projeto se arrastava, um dos processos críticos da empresa foi migrado para outra plataforma e foi ao ar em um único local. O desempenho foi péssimo. Após os desenvolvedores, empreiteiros e todos os DBAs levarem um puxão de orelha sobre isto, eles por default culparam a rede. “É lenta!” clamaram.

A minha equipe mantém um muito bom histórico de nossos processos, e nós mostramos o poder de se ter uma ampla largura de banda e os quase 10: 1 de compressão sobre os dados transferidos na rede. Além disso, foi demonstrado que o tráfego de alta prioridade foi marcado para usar a qualidade de serviço (QoS).

Aparentemente, a informação foi insuficiente, por isso montamos pacotes de captura para ver o que estava acontecendo entre o host central A (HQ) e o host remoto B. Infelizmente, e desconhecido para nós até depois do fato ocorrer, os desenvolvedores alteraram os direitos de acesso a dispositivos quase no momento da nossa tentativa de corrigir o problema em sua extremidade, então nós capturamos apenas alguns pacotes, mas nada particularmente útil.

Uma chamada de conferência foi organizada às pressas, e nós já estávamos investigando o fato de que eles agora estavam utilizando duas máquinas virtuais especialmente interligadas para testes em vez de capturar dados reais ao vivo.

Bom – nós mudamos a porta da captura de pacotes e começamos tudo de novo. Neste momento nós tínhamos os dados reais, e eles estavam nos revelando coisas interessantes. O processo era uma cópia do banco de dados, mas não uma cópia tradicional. Era um processo de envio de dados atrelado a um reconhecimento. Poderíamos ver claramente os pacotes chegando, depois um pequeno atraso, e, em seguida, uma confirmação enviada de volta.

Além disso, percebemos que nenhuma resposta era enviada ao pedido do servidor transmissor para aumentar a quantidade de dados que podem ser enviados antes de uma confirmação ser necessária. Os resultados foram muito conclusivos: O processo não era amigável para a WAN.

Outra conferência foi criada em conjunto. Expliquei os resultados, e um dos desenvolvedores disse: “Parece que ele é executado milhares de vezes mais rápido na matriz (HQ) do que remotamente.”

Minha resposta: “Temos vários gigabytes de largura de banda na matriz (HQ), alguns poucos megabytes no site remoto. Mil vezes mais rápido é quase inoperante”.

A diferença entre LAN e WAN
Em seguida, ocorreu-me a ideia: Eles nunca tinham testado este produto através de um link WAN! O atraso de 2 para 3 milissegundos entre Hosts conectados na LAN não é um problema, mas o tempo de resposta de 40 milissegundos remotamente para cada pacote transferido tinha se tornado num pobre desempenho devido a um protocolo de transferência de arquivos que se tornou um caracol de tão lento.

Eu mencionei isso, mas a explicação foi recebida com confusão. Expliquei para o desenvolvedor que a LAN é como uma operação para apagar um incêndio: um bombeiro com um balde de água está sentado entre os dois servidores locais. Ele enche o balde em um servidor e despejá-o imediatamente no segundo servidor. Com a WAN, eles ainda estão usando apenas um bombeiro, mas ele tem que percorrer todo o caminho para o local remoto antes que ele possa despejar o balde e todo o caminho de volta para conseguir mais água para inserir no balde.

Nós tínhamos uma WAN de teste disponível, e os desenvolvedores foram informados disso através de reuniões de kick-off. Eles ignoraram ou esqueceram o fato e em vez disso continuaram a utilizar a LAN para todos os testes de tipo remoto sem nunca executar os sistemas como eles iriam operar na produção. Assim, eles de repente acordaram para um problema de desempenho que eles nunca tinham encontrado antes e que tinham atribuído a causa para uma “rede lenta”.

Eles nunca admitiram que foi um problema com o método do protocolo FTP, mas decidiram seguir um método de transferência de arquivo diferente que era mais adequado para uma rede WAN. O primeiro teste foi realizado com o processo de transferência de dados 75 por cento mais rápido antes de alguém sequer tentar ajustá-lo.

Tudo dito, toda a equipe de administração da rede investiu três dias de tempo de resolução de problemas para a exclusão de quase todas as outras funções, apenas para provar que aquilo que nós tínhamos informado pela primeira vez era verdade.

Autor: Anonymous

Disponível em: <http://www.infoworld.com/article/2948200/it-jobs/developers-do-you-know-what-a-wan-is.html?phint=newt%3Dinfoworld_network&phint=idg_eid%3D90c7fc2d3e03d5a53caa0dfd4d78fcdd#tk.IFWNLE_nlt_networking_2015-07-21&gt;

Acesso em: 21/07/2015

Traduzido e adaptado por Ademar Felipe Fey em 31/07/2015

Confira nossos E-books e Cursos on-line completos!

Introdução ás Redes WAN 1a edição 2013 bat e blog

Sobre ademarfey

Professor de TI aposentado. Escritor na área de Redes de Computadores e Telecomunicações. Também pesquisa a Imigração Alemã no Brasil desde 2017.
Esse post foi publicado em Redes de Computadores e marcado , . Guardar link permanente.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s