Teaming e Hyper-V
Hola
El asunto del NIC Teaming en Hyper-V es un tema recurrente. ¿Como se monta y configura?. ¿Cuando esta o no recomendado?. ¿Esta soportado por 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 parece ser 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
- Microsoft Support Policy for NIC Teaming with Hyper-V: http://support.microsoft.com/kb/968703
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 más arriba, y como veremos más adelante, 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. Por tanto, Microsoft no puede hacerse responsable en primera instancia del proceso de diagnostico y resolución de problemas que pudieran localizarse en esta capa de software. Estaríamos…
———–
Fuente:
Microsoft, su tecnología y yo