Balance de carga NIC, conmutador y enrutador (redundancia)


7

Tengo dos preguntas que separaré para evitar confusiones.

Tengo la intención de construir una red basada en la redundancia. Habrá dos piezas de cada dispositivo, a veces más de 2, como tarjetas NIC. Dibujé esta foto para ti.

Diagrama de Red

Como puede ver, tengo dos conmutadores , un enrutador y dos servidores . Cada servidor ejecutará Windows 2012 R2 Teaming, (equipos de 2), cada equipo estará en su propia VLAN (tenga en cuenta que esto puede cambiar ya que la pregunta 2 habla de ello).

  1. Mi primera pregunta es, ¿qué tipo de lógica tienen las NIC para el equilibrio de carga? , ¿Tengo que apilar los interruptores para que funcione? , ¿Puedo conectar dos puertos del enrutador a cada uno de los conmutadores y NO apilarlos (los conmutadores)? ¿Entonces esto enviará tráfico desde el interruptor A al enrutador para cambiar al B ? , Preferiría que fueran completamente independientes, por lo que si falla un interruptor o falla una NIC no será un problema.

  2. Mi segunda pregunta es sobre VLAN'ing. Tenemos múltiples procesos independientes que se ejecutan en la red (alrededor de 8). Donde preferiríamos que el servidor A no hable con el servidor B si no es necesario. Esto me está haciendo crear 8 VLAN diferentes y hacer que cada máquina o VM tenga una dirección IP específicamente en la VLAN. Una o dos computadoras necesitan las 8. (Hay muchos más de 2 servidores, pero por el bien de la imagen, solo dibujé dos para el ejemplo).

¿Hay una mejor manera de hacer esto? Vamos a tener el equipo VPN en la red, y quiero que puedan acceder a cada conmutador / pc / vm, por lo que creo que necesitaría otra VLAN de administrador, agregando otra IP y otra VNIC a cada máquina. Tiene que haber una mejor manera de hacer esto.

Gracias a todos,


Las NIC realmente no equilibran la carga, eso es manejado por el sistema operativo. No entiendo todo el asunto de VLAN. El servidor A nunca hablaría con el servidor B a menos que sea necesario, independientemente de en qué VLAN se encuentre. Es posible que desee llevar esta pregunta a Falla del servidor, ya que parece más sobre servidores que sobre la red.
Ron Maupin

No está claro qué quiere decir con "prefiera que A no hable con B". ¿Desea aislar los servidores para que no puedan hablar entre ellos? ¿O evitar que las máquinas virtuales se hablen entre sí?
Ron Trunk

Me gustaría evitar que los servidores hablen. Por ejemplo, el Servidor A tiene un virus, no quiero que B pueda obtenerlo de A. (No ocurre con frecuencia, solo para explicar la idea). Simplemente no hay razón para que se vean, pero a medida que dibujaba mi diseño, tendría que hacer que 8 VLAN, con 10 IP por VLAN, se salieran de control. Me imagino que tiene que haber una mejor manera de hacerlo.
KenBeanNet

Si enruta entre las VLAN, el virus aún puede propagarse. Las VLAN simplemente evitan que los servidores hablen en la capa 2, pero el enrutador les permite hablar en la capa 3. Si un servidor puede iniciar sesión en otro servidor, el virus puede propagarse, VLAN o no. Estás intentando clavar un clavo con un destornillador. Las VLAN tienen usos legítimos, pero parece que te estás metiendo en muchos problemas sin ninguna razón. Las cuentas de usuario separadas y el software antivirus son las herramientas adecuadas para detener la propagación del virus que usted describe.
Ron Maupin

¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.
Ron Maupin

Respuestas:


2

parece que hablamos de algo así

ingrese la descripción de la imagen aquí

Mi primera pregunta es, ¿qué tipo de lógica tienen las NIC para el equilibrio de carga?

El diseño lógico del equilibrio de carga es como el diagrama, cada VM debe tener al menos dos VNIC (puede asignar cada VNIC a una NIC física en el servidor) que se combinarán según su diseño y cada VNIC se conectará a un conmutador diferente, y la agregación de puertos en el nivel de los conmutadores debe configurarse (que se llama etherchanel o grupo de puertos). el etherchanel creado en los conmutadores está conectando VM individuales y también asignado a VLAN. por ejemplo, puede configurar el equipo entre VNIC para usar LACP como puerto agregue y use el hashing de direcciones mac, por ejemplo, como mecanismo de equilibrio de carga y desde el lado del conmutador puede configurar los puertos conectados a estas VNIC como grupo de puertos y configurarlo como una agregación de puertos LACP y asignar a este grupo de puertos una VLAN.

¿Tengo que apilar los interruptores para que funcione?

Sí, seguro que la pila causa que los dos interruptores vinieron como un interruptor que le permitirá configurar etherchanel en los dos interruptores.

¿Puedo conectar dos puertos del enrutador a cada uno de los conmutadores y NO apilar los conmutadores?

NO conectar los dos interruptores al enrutador no resolverá este problema, debe apilarlos a ambos como en el siguiente diagrama

ingrese la descripción de la imagen aquí

¿Entonces esto enviará tráfico del Switch A al Router al Switch B?

En este caso, tiene una redundancia total en el nivel de los servidores y el nivel de los conmutadores, por lo que no se teme que ningún conmutador se caiga o que cualquier NIC se caiga, lo único que puede temer es que el servidor se haya caído.

¿Hay una mejor manera de hacer esto?

La mejor manera de lograr esta tarea es configurar el 8 vlan como capa 2 en sus conmutadores y como capa 3 en el enrutador y aplicar la configuración de la lista de acceso en el enrutador que controlará el acceso de cada host de vlan a otro


1

Tiene dos opciones cuando cablea un servidor como ese, con un parche que cambiará a A y otro a B. O bien, haga que el servidor use un enlace en ese momento, también conocido como. conmutación por error, o apilar los conmutadores y hacer LACP. LACP requiere que todos los puertos miembros estén conectados al mismo conmutador, pero con el apilamiento puede evitar esto.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.