Link Ethernet direto entre dois servidores

13

Digamos que eu tenha dois servidores que precisem de latência super baixa (banco de dados, arquivo etc.). Seria possível conectar diretamente os dois servidores com 10GbE, para que cada servidor tivesse 1 (no mundo real, teria 2) conexões com a rede 'principal', mas 1 placa de rede com um cabo Ethernet conectado diretamente ao segundo servidor, sem comutadores ou roteadores, apenas uma conexão direta

                         Internet/Datacenter
                                 |
                                 |
                                 |
                                 |
                                 |
                                 |
                                 |
                        --------------------
                        |                  |
            ------------|      Switch      |-----------
            |           |                  |          |
            |           --------------------          |
            |                                         |
            |                                         |
            |                                         |
            |                                         |
            |                                         |
            |                                         |
            |                                         |
  Network Card 1 (eth0)                     Network Card 1 (eth0)
            |                                         |
  --------------------                      --------------------
  |                  |                      |                  |
  |     Server 1     |                      |     Server 2     |
  |                  |                      |                  |
  --------------------                      --------------------
            |                                         |
  Network Card 2 (eth1)                     Network Card 2 (eth1)
            |                                         |
            |                                         |
            |               Direct 10GbE              |
            -------------------------------------------

Minha primeira pergunta é: isso seria possível? Eles precisariam de algum serviço incomum / especial configurado para permitir que eles conversassem nessa rede que não fosse um arquivo padrão /etc/sysconfig/network-scripts/? Ambos teriam IPs estáticos no eth1, mas como coisas como roteamento funcionariam? Eu não sou especialista em redes, então essa é provavelmente uma pergunta n00b-ish

Segunda pergunta, há algum ponto? Haveria vantagens em fazer isso apenas permitindo que eles se comunicassem pela conexão de rede padrão por meio do comutador ou fornecendo uma segunda rede dedicada apenas para a comunicação intra-servidor (como a largura de banda seria usada na rede padrão pelos clientes acessando os servidores) . Supondo que a latência era a prioridade.

Eu sei que existem alguns problemas com esse método, como quando adicionamos um terceiro servidor, éteres teríamos que dar a cada servidor outra placa de rede e provavelmente configurar um triângulo de replicação muito complicado, mas como isso é hipotético, vamos ignorar isso.

E como a latência é a questão principal, a fibra seria melhor em relação à Ethernet (a velocidade não é importante desde que consiga alguns Gb / s)

Fiz essa pergunta a partir de um ponto de vista linux, porque esse é o meu histórico, mas pode ser aplicado a qualquer servidor / dispositivo

networking ethernet fiber

— mancha
fonte

1

Como observação, você deve usar o UDP e não o TCP para obter latência às custas de perder a garantia de entrega. Dependendo do tamanho dos seus pacotes, os jumbo-frames também podem ajudar, limitando o número de pacotes.

— Shadok 8/11/11

O @Shadok UDP não é ideal para servidores de banco de dados, servidores de arquivos etc., mas para monitoramento, registro e outras coisas não críticas O UDP é uma opção muito melhor, eu concordo. Eu acho que qualquer configuração de rede como essa provavelmente seria algo que exigia entrega garantida, mas os pacotes UDP na rede principal têm muitos usos.

— Smudge

Ok, fiquei com a impressão de que a latência era sua principal preocupação e pensei que você possivelmente tivesse uma maneira de verificar a integridade ou confirmar a entrega de pacotes de uma maneira diferente da TCP. Uma idéia que eu só tinha seria implementar um contador simples incrementado a cada pacote e, em seguida, solicitar os faltando novamente ou apenas deixá-los, mas estou divagando :)

— Shadok

@Shadok - Se você conseguiu manipular uma conexão UDP com um banco de dados, isso poderia levar a um comportamento imprevisível e corrupção. Além disso, você basicamente transformaria UDP em TCP sequenciando pacotes e solicitando os que estavam faltando. É para isso que serve o TCP. Seria melhor engordar a Ethernet para 100g ou usar uma conexão de fibra

— glifo

9

Não há razão para que você tecnicamente não possa fazer isso.

Eu provavelmente faria algo semelhante, nessas circunstâncias, na verdade. Do ponto de vista puramente linux, é realmente fácil, basta fornecer à conexão um endereço IP com uma máscara de bit / 30, fornecendo 2 endereços IP e, em seguida, é um simples link ponto a ponto.

Se você quisesse expandir a rede, poderia obter um switch 10GE e, em seguida, ter uma VLAN separada para o tráfego entre servidores. Há alguns equipamentos muito brilhantes na gama de switches Force10 que podem fazer comutação 10GE com taxa de linha, com enormes amortecedores.

— Tom O'Connor
fonte

5

Não posso comentar o ponto de vista do Linux, mas vou usar meu conhecimento e fazer mais algumas perguntas.

Você é dependente de baixa latência e precisa manter esses servidores sincronizados? Ambos estão executando um banco de dados ou algo assim? 10GbE deve bastar a maioria das necessidades de 2 servidores para mantê-los sincronizados. Em breve, prefiro gastar o dinheiro em um switch decente no meio dos 2 em vez de seguir o caminho que você está procurando.

Com um switch decente, você pode marcar essas portas para priorizar o tráfego e até mesmo QoS o tráfego que precisa ser em tempo real.

Meus pensamentos.

— Zapto
fonte

Dar a eles seu próprio switch / 'rede privada' seria uma opção muito melhor do que uma conexão direta; assim, se precisássemos adicionar mais servidores mais tarde, seria muito mais fácil. Também priorizar o tráfego é bom, eu realmente não percebi que você poderia fazer isso, depende dos recursos / fabricante do switch ou é algo bastante padrão?

— Smudge

A QoS no comutador é muito dependente do fornecedor, alguns suportam, outros suportam de maneira muito proprietária, outros suportam de acordo com a RFC, mas você provavelmente precisaria disso em todos os dispositivos da rede para veja algum efeito decente.

— Tom O'Connor

+1 porque muitos switches funcionam com o que é essencialmente a velocidade do fio agora. Uma rede adequadamente configurada será vantajosa de inúmeras maneiras já discutidas e também ajudará na localização de falhas.

— Dan

5

Na verdade, eu fiz isso entre dois laptops. A maioria dos adaptadores LAN modernos possui negociação automática entre eles, para que você possa usar um cabo LAN comum.

Defina endereços IP estáticos que não estejam no mesmo intervalo que qualquer outra sub-rede que você esteja usando - por exemplo, se meus sistemas estiverem em uma sub-rede 192.168.xx, eu uso uma sub-rede 10.0.0.x entre eles. Caso contrário, deve funcionar

— Journeyman Geek
fonte

2

Não há vantagem em usar essa configuração. hoje, os interruptores são extremamente rápidos, para que você nunca enfrente nenhuma latência visível devido a ele. e escalabilidade também seria um grande problema para você. Além disso, também haveria um problema de configuração do roteamento, pois você precisará manter DUAS redes separadas em vez de apenas uma.

— Farhan
fonte

2

A vantagem na minha situação foi que a conexão direta eliminou a necessidade de usar a criptografia SSL em uma conexão de banco de dados, porque ela passa por uma conexão privada e não por um comutador semi-privado, onde as senhas podem ser detectadas.

— glyph

2

Tenho certeza de que você precisará de um cabo cruzado para conectar o Servidor 1 ao Servidor 2.
Você terá uma latência muito baixa, mas a latência em uma LAN com comutadores modernos é quase o mais próxima de zero possível. Sinceramente, duvido que você verá algum ganho mensurável de desempenho.

— SBWorks
fonte

10

Gb e 10Gb fazem o auto-MDIX, assim você não precisa de um crossover. Isso é apenas para 10/100.

— MDMarra

Acho que você está certo sobre isso, @MarkM. Não acho que já tenha experimentado isso na vida real.

— SBWorks 8/11/11

2

Segurança vs. Desempenho vs. Dinheiro.

Se o tráfego do canal traseiro for alto e o dinheiro baixo, use uma conexão direta. É feito todos os dias e em muitas situações do mundo real pode ter melhor desempenho do que um switch já sobrecarregado.
Se o tráfego do canal traseiro for baixo e a segurança for média ou baixa, as NICs obrigatórias para aumentar a taxa de transferência geral da Internet - duas conexões de cada servidor com a Internet, a NICS com várias residências para "isolar" o tráfego de replicação (espaços IP separados facilitam o firewall) , faça auditoria, faça diagnósticos de rastreamento de pacotes etc.).
Se a segurança for alta e houver bastante dinheiro, use um interruptor. Mais fácil de expandir. Mais fácil de diagnosticar problemas.

No cenário fornecido, uma compra de switch não seria garantida. Utilizar um switch existente com segmentação de VLAN faria sentido. No entanto, não vejo nenhum motivo para conectar-se ao switch, a menos que os servidores sejam compartilhados, ou seja, não estejam fisicamente acessíveis. É um desperdício de duas portas de switch, a menos que a captura / depuração de pacotes esteja ativa.

— Joe
fonte