VERIFICAÇÃO INICIAL DE PROBLEMAS EM REDES ( PARA INICIANTES )

Através deste Blog tentarei explicar uma ajuda inicial para solucionar problemas em suas redes , principalmente para aqueles que estão iniciando agora e ainda não têm o devido conhecimento técnico e experimental. 

Os problemas mais freqüentes são latência do link aumentando, perda de pacotes , instabilidade em conexões , Loop ou retorno como alguns gostam de chamar , e muitos outros problemas que acarretam na instabilidade do serviço.

Na maioria dos casos sempre pensamos de imediato em trocar equipamentos como Rb , swicths , atualizar firmwares , trocar placas eth do servidor ou até mesmo trocar o servidor sem fazer os devidos testes, sendo que apenas um vírus ou um equipamento com problema técnico em sua rede pode vir a causar problemas gigantescos.

Sabendo disto, antes de fazer a troca de qualquer equipamento , devemos sanar todas as dúvidas que podem vir a causar estes problemas.

Sempre e em todos os casos antes de mais nada devemos verificar nossos Links, ou seja fazer os devidos testes para que não haja uma dúvidas sobre a conexão contratada.

Verificando link :
1- Desconectar cabo principal que leva o Link à eth de entrada na Rb ou Servidor.

2- Conectar o cabo principal em um Notebook ou Pc com configuração do link e fazer os devidos testes de download , pings e navegação.

Link testado e verificado , iremos para o próximo passo :
Em qualquer caso nosso link entra por uma eth e sai por outra eth ou várias podendo ser Servidor, Rb, Roteador ou qualquer outro equipamento que fará a distribuição do link. 

Vamos à um exemplo fictício e simplificado de distribuição do Link :

Eth1 ==> Entrada Link
Eth2 ==> Saída Rádio 1
Eth3 ==> Saída Rádio 2
Eth4 ==> Saída Swicth

1- O primeiro passo é verificar todas as portas eth de saída desconectando as mesmas deixando apenas a eth de entrada do link. 

2- Eths de saída desconectadas , aconselho ligar um PC ou Notebook em uma das eths de saída e fazer os devidos testes . Caso haja um problema em seus testes estando somente ligado seu PC ou Notebook na eth de saída e o link na eth de entrada , deverá imediatamente fazer os devidos reparos em seu equipamento de distribuição do link , exemplos :

. Caso seja uma Rb , atualizar firmware , verificar regras ou até mesmo um problema físico na própria Rb.

. Caso seja um Servidor , verificar Software, versão , regras e também um problema físico.

Ou seja , qualquer que seja seu equipamento de distribuição do Link deve ser reparado tendo em vista que o problema já foi identificado com este teste inicial. 

Equipamento de distribuição do Link testado e comprovado o seu funcionamento adequado vamos ao próximo passo para verificação das ramificações que saem das eths.

Testando eths de saída :

1- Deve-se continuar com o PC ou notebook ligado à uma eth de saída .

2- Ligar a primeira eth de saída fazendo com que comece novamente a distribuição do link para alguns clientes.

3- Ligada a primeira eth de saída deixe por alguns segundos o processamento começar a rodar ou funfar como dizemos.

4- Tendo em vista que já estamos com a eth de entrada do link ligada , uma eth de saída ligada , e seu PC ou Notebook ligada em outra eth de saída , faça os devidos testes com seu equipamento para observar se o problema começa a ocorrer novamente .

5- Caso o problema não comece a ocorrer podemos concluir que não há nada de errado com esta célula de clientes plugados nesta eth de saída que foi testada.

Sabendo disto , faça o mesmo teste em todas as eths de saída até encontrar a célula( Ap ou swicth que está conectado na eth ) que faz com que comece a ocorrer o problema. 

Célula com problema encontrada :
Vamos a um exemplo simples e fictício :

eth de saída ==> célula (Ap ou swicth ) ==> clientes 
Quando encontramos a célula problemática devemos começar a isolar rádios de clientes que recebem o sinal dos Aps bloqueando macs ou de outra forma que desejarem assim como swicths que teremos que desconectar cabos até encontrarmos a origem do problema.

Este isolamento deve ser feito um a um ,ou seja ,Ap por Ap , swicth por swicth , e a cada isolamento , os testes devem estar sendo feitos para que se identifique realmente a origem do problema.

Este procedimento eu chamo de isolando e detectando problemas em ramificações .

Espero ter sido claro e espero também estar concedendo uma boa ajuda aos iniciantes .

Marcio Marques

Read More

TOPOLOGIAS DO CACHE E ANÁLISE DOS SEUS PROCESSAMENTOS

Neste tutorial tentarei explicar todas as topologias usadas em servidor cache , vantagens e desvatagens , para que possam analisar e tirar suas conclusões sobre performance e aplicação dos mesmos.

Todas as análisas feitas abaixo são calculadas após o link , pois como sabemos existem links dedicados, links adsl's e muitos tratam diferente suas opções como por exemplo usar load balance .

. CACHE COMO PARALELO AO SERVIDOR USANDO RB MIKROTIK OU ROTEADOR

1- CLIENTE faz requisição para SERVIDOR

2- SERVIDOR faz requisição para RB
3- RB  faz requisição para CACHE
4- CACHE devolve requisição para RB
Se cache tem requisição cacheada 
5- RB devolve requisição para SERVIDOR
6- SERVIDOR devolve requisição para CLIENTE
Se cache não tem requisição cacheada 
5- RB  faz requisição para LINK
6-LINK devolve requisição para RB
7- RB devolve requisição para CACHE
8- CACHE devolve requisição para RB (CACHEANDO OU NÃO)
9- RB devolve requisição para SERVIDOR
8- SERVIDOR devolve requisição para CLIENTE
Fim se
Fim se
Reparem que neste modo Paralelo existem 3 processamentos distintos, processamento da RB processamento do Servidor e processamento do Cache além do que a requisição percorre um longo caminho até ser devolvida ao cliente.
Em meu entendimento além do caminho longo percorrido e como ainda temos 3 processamentos distintos a sendo executados, existe uma considerável perda de performance nas requisições.


. CACHE COMO BRIDGE ENTRE SERVIDOR E LINK

1- CLIENTE faz requisição para SERVIDOR

2- SERVIDOR faz requisição para CACHE
Se cache tem requisição cacheada 
5- CACHE devolve requisição para SERVIDOR
6- SERVIDOR devolve requisição para CLIENTE
Se cache não tem requisição cacheada 
5- SERVIDOR faz requisição para LINK passando por dentro do cache transparente
6- LINK devolve requisição para SERVIDOR passando por dentro do cache transparente
7- SERVIDOR envia requisição para CACHE para cachear
8- SERVIDOR devolve requisição para CLIENTE
Fim se
Fim se

Reparem que neste modo Bridge existem 2 processamentos distintos, processamento do Cache e do Servidor e um caminho menor a ser percorrido por requisições , porém a fatos que podem ser preponderantes para uma perda de performance e neste caso tem a seguintes explicações :
- Como estão em modo Bridge , o Hardware do Cache e o hardware do servidor deveriam ser compatíveis e com o mesmo nível de qualidade e performance para que haja um sincronismo.
- Como os Caches não estão preparados para fazer exatamente um controle de tráfego (sabendo-se que a função dos mesmos não é esta) com certeza haverá uma perda de performance no envio e recebimento destas requisições que ficam passando por dentro dele indo e voltando.
Em todo caso ainda prefiro este modo comparando-se ao paralelo pois a performance deste considerando a quantidades de processamentos e caminhos de requisições é menor , desde que sejam bons hardwares para que tenham bom sincronismo é claro.

. CACHE COMO BRIDGE ENTRE SERVIDOR E CLIENTE

1- CLIENTE faz requisição para SERVIDOR passando por dentro do cache transparente

2- SERVIDOR faz requisição para CACHE
Se cache tem requisição cacheada 
5- CACHE devolve requisição para SERVIDOR
6- SERVIDOR devolve requisição para CLIENTE
Se cache não tem requisição cacheada 
5- SERVIDOR faz requisição para LINK
6- LINK devolve requisição para SERVIDOR
7- SERVIDOR envia requisição para CACHE para cachear
8- SERVIDOR devolve requisição para CLIENTE passando por dentro do cache transparente
Fim se
Fim se

Obs: Este segundo modo bridge diferencia-se do primeiro devido apenas a posição diferenciada do cache na topologia. 

Reparem que neste modo Bridge existem 2 processamentos distintos, processamento do Cache e do Servidor e um caminho menor a ser percorrido por requisições , porém a fatos que podem ser preponderantes para uma perda de performance e neste caso tem a seguintes explicações :
- Como estão em modo Bridge , o Hardware do Cache e o hardware do servidor deveriam ser compatíveis e com o mesmo nível de qualidade e performance para que haja um sincronismo.
- Como os Caches não estão preparados para fazer exatamente um controle de tráfego (sabendo-se que a função dos mesmos não é esta) com certeza haverá uma perda de performance no envio e recebimento destas requisições que ficam passando por dentro dele indo e voltando.
Em todo caso ainda prefiro este modo comparando-se ao paralelo pois a performance deste considerando a quantidades de processamentos e caminhos de requisições é menor , desde que sejam bons hardwares para que tenham bom sincronismo é claro. 




. CACHE COMO CLIENTE OU EM PARALELO COM O SERVIDOR

Obs1:  O cache é ligado em uma ETH no servidor específica para ele

Obs2: Algumas vezes também são usadas RB MIKROTIK  como servidor

Esta topologia é minha preferiada pois se trata de uma topologia com menos processamentos e com menos caminhos para as requisições percorrerem. 

Para que este modo funcione corretamente tanto como cliente quanto paralelo com servidor é necessário uma programação devidamente correta para que haja um funcionamento com a perfonmace desejada no processamento e no encaminhamento das requisições.

1- CLIENTE faz requisição para SERVIDOR
2- SERVIDOR faz requisição para CACHE
Se cache tem requisição cacheada 
5- CACHE devolve requisição para SERVIDOR
6- SERVIDOR devolve requisição para CLIENTE
Se cache não tem requisição cacheada 
5- SERVIDOR faz requisição para LINK
6- LINK devolve requisição para SERVIDOR 
7- SERVIDOR devolve requisição para CACHE caso a requisição precise ser cacheada e simultaneamente devolve a requisição que está sendo cacheada ao CLIENTE ou devolve diretamente para o CLIENTE caso a requisição não precise ser cacheada.
Fim se
Fim se

Reparem que neste modo com o Cache como cliente ou paralelo com o servidor, se tivermos um bom Hardware haverá um processamento central feito pelo Servidor economizando assim caminhos a serem percorridos por requisições. 

.SERVIDOR CACHE GATEWAY

Este caso em específico deveria ser o melhor de todos devido à concentrar todos os processamentos, enviar e receber todas as requisições diretamente, porém a restrições que fazem com que seja ainda inviável esta aplicação :

1 - Neste caso precisamos de um hardware muito eficiente e de qualidade para fazer todos os processamentos que serão concentrados somente nele.

2 - Como necessitamos frequentemente de atualizações e reparos tanto no cache quanto no sistema de controle de banda , todas as vezes que necessitássemos de atulizações ou reparos tanto em um quanto o outro , o serviço de ambos seria pausado causando assim o interrompimento de suas funções e serviço.

3 - Um opinião pessoal ! Para pequenos provedores de internet, desconheço nos dias atuais um software a altura para que execute estas funções tanto no controle de banda quanto cache simultêneamente e devidamente sincronizado , aproveitando todo o processamento do hardware.

Read More