Archivo

Archivo para noviembre, 2012

TEAM en Windows Server 2012

jueves, 15 de noviembre de 2012 Sin comentarios

Como ya expusimos en otro post de éste blog, Windows Server 2008 R2 soporta y admite configuración Teaming en las NIC de nuestro hardware, con el siempre condicionante de que dependía de los fabricantes de NIC el desarrollo del software de Team.

En Windows Server 2012, el Team es ahora nativo del sistema operativo, independientemente del fabricante que se encuentre en nuestro CPD.

Hay tres grandes aspectos que destacan en la solución de Team.

  • Poder asociar Team NICs para el tráfico de red normal o para el entorno virtual.
  • Poder trabajar en Team con NICs de diferentes fabricantes.
  • Poder formar Team de hasta 32 tarjetas de red en un solo equipo.

Veamos la interfaz de usuario y las opciones que tenemos disponibles.

En  ésta imagen muestro una configuración de NIC Teaming nativa a Windows Server 2012 y quería resaltar algunos de los puntos de interes de éste nuevo concepto de Team.

Evidentemente necesitamos al menos dos tarjetas de red para crear un equipo y notar que podemos trabajar en un servidor con un máximo de 32 NICs. La creación de un grupo de NIC es muy fácil y personalmente me gusta porque el proceso de instalación respeta los nombres que se colocan en las NICs.


Una vez creado el grupo de NIC, al que he llamado Team 1, podemos seleccionar las NICs que formarán parte de ese Team.

Si ampliamos las propiedades adicionales podremos realizar cambios de configuración en base a la parametrización de red individual que necesitemos y debemos tener opciones para configurar nuestro Team más alla de conformarnos con una configuración estática del tipo; “One Size Fits All”.

Como vemos en la imagen de arriba, as propiedades del Team, proporcionan una lista de todas las tarjetas disponibles en el servidor. Aquí podremos elegir qué tarjetas de red deseamos añadir a nuestra configuración de Team.

El nombre que he dado a mis tarjetas de red es uno muy al uso en laboratorios como el mío, “Test NIC 1,” Test NIC 2, y “Test NIC 3” y el Team se llama “Team 1”.

A partir de aquí se presentan los detalles adicionales que se pueden configurar para nuestro Team, lo cual nos va a permitir ser muy específicos acerca de cómo el Team, equilibra la carga y se conecta a la red.

MODO TEAMING

Como podemos ver en la imagen el Team se puede configurar para trabajar en Team estático, en modo switch independiente, o LACP (Link Aggregation Control Protocol).

Static Teaming requiere configuración tanto en el switch como en el servidor para identificar los vínculos que formaran el Team. Este modelo de Team nos ofrece un switch dependiente del Teaming que formemos con nuestras NICs.

Switch Independent El modo independiente nos permite distribuir las tarjetas de red en el Team a través de múltiples conmutadores de red ó (Network Switches) en nuestro entorno.

LACP proporciona (Link Aggregation) que podríamos traducir como, la agregación de enlace y además permite la expansión y la reducción del grupo de NIC. Este es un modo de swith ó conmutación independiente del NIC Teaming.
MODO LOAD BALANCING:

Las opciones son o bien Address Hash o Hyper-V Port.

Address Hash es la forma de configurar el Team para el tráfico NLB (network load balancing) entre las NIC que forman el Team.

Hyper-V Port balancea la carga para equilibrar el tráfico que pasa por la VM.

Con Hyper-V Port, la buena noticia es que, las transacciones de cada VM tienen una tarjeta de red por separado, con la desventaja de que que cada máquina virtual sólo puede realizar transacciones a través de una tarjeta de red única. Si tienes varias tarjetas de red virtuales en la máquina virtual y se forma un team para ellas, el Hyper-V Port puede ser la mejor opción.

Para la mayoría de las configuraciones, es muy posible que la Address Hash sea la mejor opción para que la máquina virtual pueda acceder a la red, aún en el caso de que la tarjeta de red de la máquina virtual está dando fallo. Recordemos que con la tecnología Hyper-V Port, un fallo de la NIC de la máquina virtual está causando una interrupción de la comunicación entre, la máquina virtual y la red. Con Address Hash no tendremos éste problema.

STANDBY ADAPTER Ó ADAPTADOR EN ESPERA:


Como bien define su nombre, ésta solución nos permite definir un adaptador de reserva para el equipo. Hay que tener en cuenta que sólo se puede definir un adaptador de espera y además se puede asegurar que el ancho de banda asociado estará disponible incluso si una tarjeta de red de nuestro Team falla.


Fijémonos en las conexiones de red que se nos han formado. Team 1 es una asociación de NICs y notar también que las NIC agrupadas son de diferentes fabricantes.

Categories: Windows 2012 Tags:

Hyper-V R2 con el Teaming de HP y VirtualConnect

miércoles, 7 de noviembre de 2012 2 comentarios

El asunto del NIC Teaming en Hyper-V es un tema recurrente, máxime si hemos adquirido en los últimos años servidores tipo blade, donde podemos encontrarnos hasta con diez NICs, y tenemos el impulso de utilicemos todas, por esa máxima de como repartir las NICs en un CSV de hyper-v, “mínimo 2, máximo… y mejor Gigabit”  ¿Como se monta, cómo se configura, cuándo esta o no recomendado, lo soporta Microsoft?.

Por qué necesitamos el Teaming

Estas son las razones por las que se suele plantear la necesidad de establecer Teams de tarjetas de red:

  • Por si falla la una NIC física. Hay quien incluso quiere establecer Teams entre NIC de diferentes fabricantes para mayor tolerancia a fallos. Mi opinión al respecto es que, por esta razón, no merece la pena. Si falla físicamente una NIC es muy posible que el Team no te arregle los problemas colaterales, y con mucha probabilidad, los posibles problemas en drivers/firmware etc. en lugar de ser eliminados por el software de teaming, se verán amplificados. Además la tendencia en las NICs para servidores es que adaptadores multipuerto, que se presentan como interfaces independientes de cara al sistema operativo. La probabilidad de que un hipotético fallo afecte a un único puerto es aún más baja. Si además los puertos de las diferentes NICs están enchufadas al mismo switch de red no ganaremos ningún tipo de tolerancia ante un posible problema ajeno a las propias tarjetas. En estas condiciones, bajo mi punto de vista, el teaming supone mas riesgo que beneficio real.
  • Por si falla el camino: Esto incluye los elementos de red a los que las NICs están conectadas, en particular cables y switches. No queremos confiar en un único latiguillo de red, ni en un único switch de red. Es más, queremos tener la posibilidad de dar mantenimiento a dichos elementos sin afectar a la conectividad de las cargas de trabajo. Por ejemplo, reemplazarlos o actualizar firmwares y versiones de sistema operativo de los switches. Teams entre puertos de diferentes interfaces que conectan a diferentes elementos de red es lo más adecuado para entornos en los que la tolerancia a fallos es un requisito.
  • Agregación de ancho de banda y balanceo de carga. En el mundo de las interfaces a 1GB esta ha sido la forma de aumentar el ancho de banda para cargas de trabajo que así lo requieran, como podría ser el caso de las NICs correspondientes a un switch virtual. Sin embargo la tendencia es ir hacia interfaces multipuerto de 10Gb, que pueden virtualizarse o particionarse a voluntad, obteniéndose anchos de banda personalizados.

En los documentos que se enlazan más abajo encontrareis descripciones mucho más puristas de todo esto. Simplemente se trata de dejar claro que el Teaming es una pieza que puede ser un requisito fundamental en muchos escenarios.

Soportabilidad

La soportabilidad del NIC Teaming por parte de Microsoft esta muy bien resumida en estos dos artículos

Since Network Adapter Teaming is only provided by Hardware Vendors, Microsoft does not provide any support for this technology thru Microsoft Product Support Services. As a result, Microsoft may ask that you temporarily disable or remove Network Adapter Teaming software when troubleshooting issues where the teaming software is suspect.         If the problem is resolved by the removal of Network Adapter Teaming software, then further assistance must be obtained thru the Hardware Vendor.

  • Network adapter teaming and server clustering: http://support.microsoft.com/kb/254101/en-us
    In Windows Server 2008 and Windows Server 2008 R2, there are no restrictions that are associated with NIC Teaming and the Failover Clustering feature. In Windows Server 2008, the new Microsoft Failover Cluster Virtual Adapter is compatible with NIC Teaming and allows it to be used on any network interface in a Failover Cluster.

Me he permitido subrayar las partes más relevantes. La pila de red de Windows no implementa los mecanismos de agregación de ancho de banda y tolerancia a fallos mencionadas, es necesario utilizar el software especifico del fabricante de la tarjeta o de los propios servidores para introducirlos por encima de los drives de las tarjetas de red. El Teaming está soportado para Windows y por tanto para Hyper-V.

Configuración

En Hyper-V, la pila de red y la pila de almacenamiento se configuran en la partición padre. Por tanto, la configuración del Teaming de red, al igual que el multipath en el caso del almacenamiento, se gestionan exactamente igual que en un servidor físico. En la grandísima mayoría de las situaciones nos encontraremos con NICs basadas en chipset de Intel o Broadcom. Con la salvedad de HP, que implementa su propia herramienta de creación y gestión de los teams, la mayoría del resto de fabricantes se basan en las herramientas que proveen directamente los propios fabricantes del chipset.

Estos son los principales enlaces para instalar y configurar los Teams de algunos fabricantes, mi experiencia se basa en HP y en su solución de Virtual Connect:

HP Network Configuration Utility:

  • Using HP ProLiant Network Teaming Software with Microsoft® Windows® Server 2008 Hyper-V or with Microsoft® Windows® Server 2008 R2 Hyper-V:

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01663264/c01663264.pdf

http://www.hp.com/sbso/bus_protect/teaming.pdf

Intel ProSet / ANS:

Broadcom BACS / BASP:

Cuando tiene sentido el Teaming en entornos de Hyper-V

Nos plantearemos el uso de NIC Teaming en Hyper-V en aquellas redes en las que no se implementen ya mecanismos de tolerancia a fallos por otra vía y en las que podamos necesitar agregar ancho de banda o implementar políticas de balanceo, en función de lo que hemos mencionado más arriba.

  • iSCSI. Si nuestro almacenamiento es iSCSI y queremos utilizar más de una tarjeta, lo adecuado es usar los mecanismos de multipathing propios del sistema de almacenamiento. Sin Teaming
  • Red de HeartBeat del cluster: En W2K8R2 podemos especificar diferentes redes para transportar el heartbeat, y los requerimientos de ancho de banda son mínimos. Sin necesidad de Teaming
  • Red de Live Migration: Requerimos alto ancho de banda, solamente cuando se realicen Live Migrations. Se pueden especificar diferentes redes para ello, con lo que tenemos tolerancia a fallos. Puede justificarse Teaming
  • Red de CSVs: Es la red con menor métrica del cluster. Puede tener altos consumos de ancho de banda de manera puntual. Puede justificarse Teaming
  • Red Pública de gestión: Necesitamos tolerancia a fallos, y un ancho de banda razonable para la administración del servidor. Puede ser necesario Teaming
  • Virtual Switches: Requerimos tanto altos anchos de banda como tolerancia a fallos . Puede ser necesario Teaming pero no siempre funciona.

En el siguiente documento está la recomendación oficial para hosts con cuatro o menos interfaces de red.

Sin embargo, los escenarios pueden complicarse si necesitamos dedicar ciertas NICs a dar servicio en determinadas VLANs. El software de Teaming puede crear NICs virtuales sobre las interfaces físicas reales, las cuales a su vez pueden convertirse en Switches virtuales, pudiéndose sacar además vNICs virtuales para la partición padre. Todo esto es factible y funciona. Pero conviene sentarse a pensar si realmente tiene sentido, y recordar que lo sencillo funciona y se opera mejor que lo complicado.

 Como ya he mencionado, mi experiencia viene del empleo de hardware HP, estos son dos documentos básicos;

Mis comentarios basados en mi experiencia vs resultados:

  • Activa siempre el role de Hyper-V antes de instalar el software de Teaming (NCU). Si este consejo llega tarde, simplemente renombra cpqteam.dll (http://support.microsoft.com/kb/950792)
  • Si utilizas Server Core, ejecuta HPTeam.cpl o CPQTeam.cpl (versiones antiguas) para configurar el Teaming cómodamente mediante interfaz gráfica.
  • A medida que se genera el Team y se van agregando VLANs, empiezan a proliferar NICs en el sistema. Es mas que recomendable ir renombrándolas para tener control en cada momento que es cada cosa (puertos físicos que forman el Team, NICs asociadas a cada VLAN y que conforman virtual switches, NICs virtuales que se generan en Hyper-V para la partición padre y conectadas a los switches virtuales, etc.)
  • Existe una manera mucho mas sencilla de hacer las cosas. Que sea solamente el Virtual Switch de Hyper-V quien haga el VLAN Tagging, para lo cual ni en el Team ni en Virtual Connect deberemos definir estas opciones (Para poder hacer eso, el dominio de Virtual Connect debe estar en modo “VLAN Tunneling”)
  • El Proliant Support Pack, SmartStart, CD de Firmware, etc. son buenos compañeros de viaje. El comportamiento de todo esto puede ser muy dependiente de versiones de firmware, drivers, software y por supuesto siempre últimas versiones de MPIO de Microsoft.
  • Por último, mi recomendación sobre como dedicar las NICs de tu entorno cluster (CSV) para hyper-v;
    • 2 NIC en Team para Gestión. IMPORTANTE, en modo TLB con Destination MAC Address y si no utilizas entradas ISATAP o IPV6 deshabilita todo lo alusivo a ello.
    • 1 NIC para Virtual Switch
    • 1 NIC para Heartbeat
    • 1 NIC para Live Migration

Y si utilizas los swith de Virtual Connect de HP, reparte según necesidad el ancho de banda de 10 GB,

 

Categories: Hyper-V Windows 2K12 Tags: