Reestruturação de Rede Lógica e Acesso ao Banco de Dados

[Liliane]

Caros Colegas,


Devido à necessidade de reestruturação da rede lógica da Empresa em que trabalho, compramos 02 Switches Gerenciáveis 3Com 24 Portas 10/100/1000 (GigaByte Ethernet) e já tínhamos 02 Switches 10/100 Dell com 24 Portas, hoje estou com uma rede funcionando a 10/100/1000. Como todas as placas de rede funcionam 100 e tem umas que acessam 100/1000 (micros novos e servidor). A pergunta é a seguinte: Porque quando acesso o banco de dados (postgres sql) através de uma estação pra fazer backup (placa de rede da estação 100), notei que a rede ficou mais lenta e que quando dou um ping no mesmo instantante do backup da estação pro servidor ocorre uma variação no tempo de resposta chegando a mais de 5ms. O que pode estar acontecendo?

[brunosolar]

Caros Colegas,


Devido à necessidade de reestruturação da rede lógica da Empresa em que trabalho, compramos 02 Switches Gerenciáveis 3Com 24 Portas 10/100/1000 (GigaByte Ethernet) e já tínhamos 02 Switches 10/100 Dell com 24 Portas, hoje estou com uma rede funcionando a 10/100/1000. Como todas as placas de rede funcionam 100 e tem umas que acessam 100/1000 (micros novos e servidor). A pergunta é a seguinte: Porque quando acesso o banco de dados (postgres sql) através de uma estação pra fazer backup (placa de rede da estação 100), notei que a rede ficou mais lenta e que quando dou um ping no mesmo instantante do backup da estação pro servidor ocorre uma variação no tempo de resposta chegando a mais de 5ms. O que pode estar acontecendo?

Olha podem ser por diversos fatores.

Por exemplo? como esta a configuracao dos switchs e placas de rede? Half? full? auto?

[Liliane]

Quanto a placa de rede ela esta como auto.

[Guzpido Krush]

tá com cara do servidor misturar jumbo frames com não-JF aí na sua LAN

Mixing jumbo and standard frames?

> I'm looking at upgrading a Linux-based network to gigabit speed
> using 9K jumbo ethernet frames. However, there are still some old
> 100Mbit computers and devices that will still need to be connected
> to the network, these needless to say do not support jumbo frame
> sizes.

> It is my understanding that everything on the LAN needs to have the
> same ethernet frame size. What is the best way to connect the jumbo
> and non-jumbo devices? Web searching indicates that 802.1Q VLANs
> may be the answer, but there is a lot of information to dig through
> and the implementation details are not clear to me.

If all your traffic is TCP, then you can "get away" with setting Jumbo
Frames on a subset of the systems. The reason is the TCP MSS (Maximum
Segment Size) exchange at the beginning of each connection. The
systems without JF enabled will specify a smaller MSS and all will be
well.

The issue arrises with UDP or direct link-level stuff, or anything
else without a TCP-like MSS exchange. Normal stuff like DNS will be
OK (IIRC) since that is already keeping itself below 1500 bytes
(handwaving). NFS over UDP however will have problems if you try to
go from a JF to non-JF system. The closest thing there to an MSS
exchange is the mount size and crippling to a 1024 byte mount size
would probably be worse than leaving the JF off.

Otherwise, the two systems have to be in separate IP subnets, with a
router in between them and/or you have to start adding a lot of host
routes with specific PathMTU's set on each JF-enabled system.

They don't necessarily have to be in separate VLANs. The "router" in
this case would have to be a JF-capable system, _perhaps_ with two
NICs but I think you can get away with logical interfaces instead - if
you can assign separate MTU's to each logical interface (eth0 and
eth0:1 in linux-like parlance). When JF talks to non-JF through the
router, it will fragment the IP datagrams to the proper size.

rick jones

[Guzpido Krush]

traduzation, traduzation tion

>> Estou planejando atualizar uma rede baseada em Linux para velocidade gigabit usando frames ethernet jumbo de 9K. Entretanto, ainda há alguns computadores e dispositivos antigos de 100Mbit, que também irão precisar estar conectados a rede, desnecessário portanto dizer que estes não suportam o tamanho de jumbo frame.

>> Ao meu entender tudo na LAN deveria ter o mesmo tamanho de frame ethernet. Qual a melhor forma de conectar os dispositivos jumbo e não-jumbo? Buscas na web indicam que VLANs 802.1Q podem ser a resposta, mas há mta informação para escarafunchar e os detalhes de implementação não estão claros para mim.

Se todo o seu tráfico for TCP, então você pode "se livrar" setando Jumbo Frames em um subconjunto de sistemas. A razão é a troca TCP MSS (Maximum Segment Size) que ocorre no começo de cada conexão. Os sistemas sem JF habilitado vão especificar menores MSS e tudo estará bem.

A questão emerge com UDP ou trecos de link direto, ou qualquer coisa sem uma troca MSS TCP. Coisas normais como DNS estão OK (IIRC) já que eles já se mantém abaixo dos 1500 bytes (handwaving). NFS sobre UDP de qualquer forma terá problemas se você tentar ir de um JF para outro não-JF. A coisa mais próxima que existe em uma troca MSS é o mount size, que largar como 1024 bytes seria pior que manter JF desligado.

Caso contrário, os dois sistemas devem estar em subnets de IP diferentes, com um roteador entre eles e/ou você deve começar a adicionar um monte de rotas de hosts com pathMTU específica definida em cada sistema com JF habilitado.
Eles não necessariamente precisam estar em VLANs separadas. O "roteador" nesse caso seria um sistema apto a JF, _talvez_ com duas NICs mas eu acho que você pode se livrar com interfaces lógicas no lugar -- se você atribuir MTUs separadas para cada interface lógica (eth0 e eth0:1 por exemplo em linux);
Quando JF fala com não-JF pelo roteador, irá fragmentar seus datagramas IP para o tamanho próprio.

rick jones

[brunosolar]

/* so um comentario sem muito a ver com o problema citado mas como o wireshark pode ajudar........


Este texto me lembrou um problema de rede pois tinha um roteador com MTU abaixo de 1500. Acontecia que os sites HTTP acessavam normalmente e os os HTTPS nao. Foi ai que o brilhante wireshark que mostrou que os pacotes https nao fragmentavam e onde ocorria o erro. Feito isso corrigido MTU no roteador e tudo OK.