Enlace directo de ethernet entre dos servidores

13

Digamos que tenía dos servidores que necesitaban una latencia súper baja (base de datos, archivo, etc.). ¿Sería posible conectar directamente los dos servidores con 10 GbE, por lo que cada servidor tenía 1 (en el mundo real tendría 2) conexiones a la red 'principal', pero 1 tarjeta de red con un cable de ethernet que se conectaba directamente al segundo servidor, sin conmutadores ni enrutadores, solo una conexión directa

                         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              |
            -------------------------------------------

Mi primera pregunta es, ¿sería esto posible? ¿Necesitarían algún servicio inusual / especial configurado para permitirles hablar a través de esta red que no sea un archivo estándar /etc/sysconfig/network-scripts/? Ambos tendrían IP estáticas en eth1, pero ¿cómo funcionarían cosas como el enrutamiento? No soy un experto en redes, entonces esta es probablemente una pregunta n00b-ish

Segunda pregunta, ¿hay algún punto? ¿Habría alguna ventaja al hacer esto solo al permitirles comunicarse a través de la conexión de red estándar a través del conmutador, o al darles una segunda red dedicada solo para comunicarse dentro del servidor (dado que los clientes que acceden a los servidores usarían el ancho de banda en la red estándar) . Asumir latencia era la prioridad.

Sé que hay algunos problemas con este método, como cuando llegamos a agregar un tercer servidor, tendríamos que darle a cada servidor otra tarjeta de red y, probablemente, configurar un triángulo de replicación muy complicado, pero dado que esto es hipotético, ignoremos eso.

Y dado que la latencia es la cuestión clave, la fibra sería mejor sobre Ethernet (la velocidad no es importante siempre que pueda hacer un par de Gb / seg)

Formulé esta pregunta desde un POV de Linux, porque ese es mi fondo, pero podría aplicarse a cualquier servidor / dispositivo

networking ethernet fiber

— Mancha
fuente

1

Como nota al margen, debe usar UDP y no TCP para obtener latencia a costa de perder la garantía de entrega. Dependiendo del tamaño de sus paquetes, los marcos jumbo también podrían ayudar al limitar el número de paquetes.

— Shadok

@Shadok UDP no es ideal para servidores de bases de datos, servidores de archivos, etc., pero para monitorear, registrar y otras cosas no críticas, UDP es una opción mucho mejor, estoy de acuerdo. Creo que cualquier configuración de red como esta probablemente sea algo que requiera entrega garantizada, pero los paquetes UDP a través de la red principal tienen muchos usos.

— Mancha

Ok, tenía la impresión de que la latencia era su principal preocupación y pensé que posiblemente tenía una forma de verificar la integridad o acusar recibo de los paquetes de una manera diferente a TCP. Una idea que tenía es implementar un contador simple incrementado en cada paquete y luego solicitar los que faltan nuevamente o simplemente descartarlos, pero estoy

— divagando

@Shadok: si lograra manipular una conexión UDP a una base de datos, podría provocar un comportamiento impredecible y corrupción. Además, básicamente convertiría UDP en TCP secuenciando paquetes y solicitando los que faltan. Para eso es TCP. Sería mejor engordar el ethernet a 100 g o usar una conexión de fibra

— glifo

9

No hay ninguna razón por la que técnicamente no puedas hacer esto.

Probablemente haría algo similar, dadas las circunstancias, en realidad. Desde un punto de vista puramente linux, es realmente fácil, solo dale a la conexión una dirección IP con una máscara de bit / 30, dándote 2 direcciones IP, luego es un simple enlace punto a punto.

Si desea hacer crecer la red, puede obtener un conmutador 10GE y luego tener una VLAN separada para el tráfico entre servidores. Hay algunos equipos muy brillantes en la gama de interruptores Force10 que pueden hacer conmutación 10GE de velocidad de línea, con enormes amortiguadores.

— Tom O'Connor
fuente

5

No puedo comentar un punto de vista de Linux, pero usaré mi conocimiento y haré más preguntas.

¿Es usted tan dependiente de la baja latencia y necesita mantener estos servidores sincronizados? ¿Ambos están ejecutando una base de datos o algo así? 10GbE deberían satisfacer la mayoría de las necesidades de 2 servidores para mantenerlos sincronizados. Pronto preferiría gastar el dinero en un interruptor decente en el medio de los 2 en lugar de seguir la ruta que está viendo.

Con un conmutador decente, puede etiquetar estos puertos para priorizar el tráfico e incluso QoS el tráfico que debe ser en tiempo real.

Mis pensamientos.

— Zapto
fuente

Darles su propio conmutador / 'red privada' sería una opción mucho mejor que una conexión directa, de esa forma, si necesitáramos agregar más servidores más tarde, sería mucho más fácil. También priorizar el tráfico es bueno, no me di cuenta de que podría hacerlo, ¿depende de las características del interruptor / fabricante o es algo bastante estándar?

— Mancha

QoS en el conmutador depende en gran medida del proveedor, algunos lo admiten, otros lo admiten de forma muy patentada, algunos lo admiten según la RFC, pero es probable que tenga que tenerlo en todos los dispositivos de la red para Ve cualquier efecto decente.

— Tom O'Connor

+1 porque muchos interruptores funcionan a lo que esencialmente es la velocidad del cable ahora. Una red configurada adecuadamente será ventajosa en una miríada de formas ya discutidas, y también ayudará a encontrar fallas.

— Dan

5

De hecho, he hecho esto entre dos computadoras portátiles. La mayoría de los adaptadores LAN modernos tienen negociación automática entre ellos para que pueda usar un cable LAN normal.

Establezca direcciones IP estáticas que no estén en el mismo rango que cualquier otra subred que esté utilizando; por ejemplo, si mis sistemas están en una subred 192.168.xx, utilizo una subred 10.0.0.x entre ellos. De lo contrario, debería funcionar

— Journeyman Geek
fuente

2

No hay ninguna ventaja de usar dicha configuración. Los interruptores de hoy se están aligerando rápidamente, por lo que nunca enfrenta una latencia visible debido al interruptor. y la escalabilidad también sería un gran problema para usted. Además, también habría problemas de configuración del enrutamiento, ya que tendrá que mantener DOS redes separadas en lugar de solo una.

— Farhan
fuente

2

La ventaja en mi situación fue que la conexión directa eliminó la necesidad de usar el cifrado SSL en una conexión de base de datos, ya que pasa por un cable privado y no un interruptor semiprivado donde las contraseñas pueden ser rastreadas.

— glifo

2

Estoy bastante seguro de que necesitará un cable cruzado para conectar el Servidor 1 al Servidor 2.
Tendrá una latencia muy baja, pero la latencia a través de una LAN con conmutadores modernos es lo más cercana posible a cero. Dudo sinceramente que vea un aumento de rendimiento medible.

— SBWorks
fuente

10

Gb y 10Gb hacen MDIX automático, por lo que no necesita un crossover. Eso es solo por 10/100.

— MDMarra

Creo que tienes razón en eso, @MarkM No creo que lo haya probado en la vida real.

— SBWorks

2

Seguridad versus rendimiento versus dinero.

Si el tráfico del canal posterior es alto y el dinero es bajo, use una conexión directa. Se hace todos los días y en muchas situaciones del mundo real puede tener un mejor rendimiento que un interruptor ya sobrecargado.
Si el tráfico del canal posterior es bajo y la seguridad es media o baja, conecte las NIC para aumentar el rendimiento general de Internet: dos conexiones de cada servidor a Internet, NICS de múltiples hogares para "aislar" el tráfico de replicación (los espacios de IP separados facilitan el firewall , auditoría, hacer diagnósticos de rastreo de paquetes, etc.).
Si la seguridad es alta y hay mucho dinero, use un interruptor. Más fácil de expandir. Más fácil de diagnosticar problemas.

En el escenario dado, una compra de cambio no estaría justificada. La utilización de un conmutador existente con segmentación de VLAN tendría sentido. Sin embargo, no veo ninguna razón para conectarme al conmutador a menos que los servidores estén codificados, es decir, no sean físicamente accesibles. Es una pérdida de dos puertos de switch a menos que la captura / depuración de paquetes esté activa.

— joe
fuente