Lo nuevo en Microsoft Windows Server 2012 R2 – Networking Parte 1

21 de mayo de 2014 por
Wetcom admin

Actualmente todo está relacionado con la nube, y la base principal de la nube es la infraestructura.

Si vamos a crear y gestionar una nube privada nos basaremos en 3 elementos principales de la infraestructura: Equipos, Almacenamiento, Red.

Si somos un proveedor de alojamiento y proveemos una solución de nube con servicios para nuestros clientes, también nos apoyaremos en los 3 elementos de la infraestructura, haciendo un escalamiento de dichas características.

Hemos revisado las novedades de Infraestructura como así también Virtualización en Windows Server 2012 R2, lo que nos lleva a entrar en el área de Networking para conocer las nuevas características y mejoras de las existentes abriéndonos un abanico de soluciones y reducción del costo operativo a la hora de gestionar redes en los distintos escenarios.

En esta primera parte de Networking veremos una nueva característica llamada VRSS, mejoras en NIC Teaming y más herramientas para Diagnósticos de Red.

VRRS (Virtual Receive Side Scaling)

Previamente RSS nos permitía utilizar multiprocesadores para hacer utilización de los adaptadores NIC y de esa forma maximizar el uso del adaptador de red, la limitante la encontrábamos en las Máquinas Virtuales de Hyper-V ya que sólo podíamos limitar un solo procesador virtual al uso del tráfico de red.

Ahora con Windows Server 2012 R2 maximizamos el uso de los procesadores en los adaptadores de redes virtuales gracias a VRRS, ya que cuando el adaptador físico de red distribuye el tráfico entre los núcleos disponibles del procesador físico, el adaptador virtual distribuye la carga dentro de los procesadores virtuales disponibles dentro de la máquina virtual.

BlogNet1_1

NIC Teaming

Con Windows Server 2012 fue introducida una nueva característica llamada Windows NIC teaming que permitía agrupar más de un adaptador de red formando un equipo que proveía 2 funciones inmejorables, aumento de ancho de banda y failover.

Para ejemplificarlo de manera sencilla tenemos un servidor con 2 adaptadores de red de 1GB cada uno, agrupándolos con Windows NIC teaming pasamos a tener un adaptador de 2 GB y un failover de red, si uno de los adaptadores falla volveremos a trabajar con el que quede a 1GB y con esto nos aseguramos de que el servidor no pierda conectividad.

También cabe destacar que un NIC teaming de 2 adaptadores de 10GB va a tener mejor performance que un adaptador de 20GB, y sobre todo menor cuello de botella.

En Windows Server 2012 R2 NIC Teaming agrega un nuevo modo denominado Dinámico que realiza una distribución equitativa sobre los adaptadores miembros del Team creado, éste modo es el predeterminado cuando creamos un equipo de adaptadores.

BlogNet1_2

Diagnóstico de Red

Para hacer troubleshooting y testear la conexión de nuestros hosts tenemos un nuevo cmdlet para PowerShell que seguramente pasará a ser el que utilicemos a la hora de realizar pruebas de conectividad de los equipos, este nuevo cmdlet es: Test-NetConnection.

Nada mejor que visualizar unos ejemplos para entender de qué se trata este cmdlet:

Primero vamos a testear la conectividad entre un servidor llamado HOST30 y otro cuyo nombre es HOST50.

PS C:\> Test-NetConnection HOST50.contoso.com

ComputerName                  : HOST50.contoso.com

RemoteAddress                 : 172.16.11.50

InterfaceAlias                    : vEthernet (Broadcom NetXtreme Gigabit Ethernet #2 –

Virtual Switch)

SourceAddress                  : 172.16.11.30

PingSucceeded                : True

PingReplyDetails (RTT)      : 0 ms

 

A continuación usaremos el parámetro –TraceRoute a un sitio web para que nos devuelva los saltos que realiza hasta llegar a destino:

PS C:\> Test-NetConnection w ww.xbox.com -TraceRoute

ComputerName                : w ww.xbox.com

RemoteAddress              : 184.29.219.150

InterfaceAlias                 : vEthernet (Broadcom NetXtreme Gigabit Ethernet #2 –

Virtual Switch)

SourceAddress               : 172.16.11.30

PingSucceeded              : True

PingReplyDetails (RTT)  : 29 ms

TraceRoute                   : 172.16.11.1

142.161.5.200

142.161.5.65

4.28.68.21

4.69.158.146

4.69.138.166

4.68.111.70

184.29.219.150

 

Y para finalizar con los ejemplos, testearemos si un servidor llamado HOST40 tiene habilitado el RDP (Remote Desktop Protocol) y veremos qué resultado obtenemos:

PS C:\> Test-NetConnection HOST40 RDP

WARNING: Ping to HOST40 failed — Status: TimedOut

ComputerName              : HOST40

RemoteAddress             : 172.16.11.61

RemotePort                   : 3389

InterfaceAlias                : vEthernet (Broadcom NetXtreme Gigabit Ethernet #2 –

Virtual Switch)

SourceAddress               : 172.16.11.30

PingSucceeded             : False

PingReplyDetails (RTT)   : 0 ms

TcpTestSucceeded        : True

 

Como podemos ver tenemos una advertencia que nos indica que no hubo comunicación mediante PING el cual corroboramos en la línea PingSucceeded: False, pero sí encontramos habilitado el RDP verificando la línea TcpTestSucceeded : True que hace referencia al protocolo que testeamos (RDP) cuyo puerto es 3389 como podemos ver en la línea RemotePort: 3389. Esto nos indica que dicho servidor tiene activo el firewall y bloquea el ingreso de mensajes ICMP (comando PING).

Con este cmdlet tenemos una amplia variedad de parámetros para identificar el comportamiento de las conexiones de nuestros equipos y nos permite hacer troubleshooting de forma más segura ya que nos devuelve información clara y concreta según el tipo de test que hagamos.

 

Así concluimos la primera parte de Networking en  “Lo nuevo de Microsoft Windows Server R2”

No te pierdas el próximo capítulo “Lo nuevo en Microsoft Windows Server 2012 R2 – Networking Parte 2”