Configurar SET (Switch Embedded Teaming)

SET es una alternativa a la solución de NIC Teaming en el host. SET integra las funcionalidades del team en el Virtual Switch.

Pueden agruparse hasta ocho adaptadores de red (todos iguales e instalados en el mismo host)

RDMA y SET: en Windows Server 2012 R2 no es posible que los adaptadores de red que usan RDMA sean vinculados a un virtual switch. Esta limitación hacía que se necesitara una mayor cantidad de adaptadores de red en el host. Windows Server 2016 no tiene esta restricción.

Aunque RDMA puede usarse con o sin SET es conveniente combinar ambas tecnologías.

Escenario:

LON-HOST1: host Hyper-V Windows Server 2016

LON-HOST1 tiene dos adaptadores de red, Ethernet 2 y Ethernet 3

LON-CL1 y LON-SVR1, máquinas virtuales cliente y servidor para comprobar SET.

Originalmente ambas VMs están conectadas a un Private Switch (luego las conectaremos al switch configurado para usar SET)

La dirección IP de LON-SVR1 es 172.16.0.11. 

Comprobamos la conectividad con las VMs aún conectadas al Private Switch.

Crear un Switch que utilice SET

Cuando se crea un virtual switch mediante powershell y se especifica más de una interfaz automáticamente se configura SET.

En el ejemplo creamos un switch llamado SETSwitch1 mediante el siguiente comando:

New-VMSwitch -Name SETSwitch1 -NetAdapterName "Ethernet 2","Ethernet 3" 
-AllowManagementOS $true

Cuando se crea el switch puede verse que es External y Teamed-Interface. 

No es necesario especificar el tipo de switch porque los virtual switches que usan SET son Externos, ya que se asocian a interfaces de red del host.

Tampoco es necesario usar el parámetro EnableEmbeddedTeaming cuando se especifica más de una interfaz en el parámetro NetAdapterName

En la pantalla siguiente vemos el adaptador vEthernet con el nombre del switch (SETSwitch1)

A continuación vemos la configuración IP de la interfaz virtual que representa al switch.





En LON-HOST1 vemos en Server Manager el nuevo adaptador vEthernet que representa el team.
Notar que la opción NIC Teaming está deshabilitada (SET no es un team en el host, sino un team integrado al switch virtual)

Conectamos ambas VMs al nuevo switch (en la imagen siguiente sólo se muestra LON-SVR1 aunque se hizo lo mismo para LON-CL1)

A continuación deshabilitamos una de las dos placas del host 

En estas condiciones de error se prueba conectividad nuevamente. Debido al team habrá comunicación entre los equipos que usan el switch SETSwitch1

Powershell Desired State Configuration

Powershell Desired State Configuration (DSC)

DSC es la tecnología de Powershell que nos permite, a través de scripts, mantener un estado deseado de configuración en los equipos.

De este modo podemos lograr un estado de cumplimiento que puede automatizarse para que se ejecute regularmente, permitiendo que nuestros equipos tengan siempre el estado de configuración deseada.

En esta nota mostramos un ejemplo básico de Powershell DSC que define como estado deseado la presencia de un rol determinado en un servidor.

Modos de configuración de DSC

Modo Push: un administrador envía manualmente las configuraciones a los nodos. Este método es manual y no garantiza que los equipos que estén apagados o desconectados en ese momento reciban la configuración.

Modo Pull: se crea un servidor (pull server) y los nodos lo contactan regularmente para obtener su configuración.

Su principal ventaja es que cuando los equipos se conectan a la red reciben la configuración deseada. Como desventaja requiere un equipo configurado como Pull server.

DSC Resources

Los recursos de DSC representan lo que queremos configurar en cada nodo en forma forzada, por ejemplo servicios, roles, archivos, etc.

Ejecutando Get-DSCResource podemos obtener una lista de recursos (entre los que vemos Windows Feature, Service, File, WindowsProcess, etc).

Ejemplo: lista de recursos obtenida al ejecutar Get-DSCResource

• File
• SignatureValidation
• Archive
• Environment
• Group
• GroupSet
• Log
• Package
• ProcessSet
• Registry
• Script
• Service
• ServiceSet
• User
• WaitForAll
• WaitForAny
• WaitForSome
• WindowsFeature
• WindowsFeatureSet
• WindowsOptionalFeature
• WindowsOptionalFeatureSet
• WindowsPackageCab
• WindowsProcess

Sintaxis del script

En la configuración siguiente, que llamamos TestConfig se trata de forzar que en el nodo LON-SVR1 esté instalado el rol de DNS Server (DNS)

Configuration TestConfig
{
                Node “LON-SVR1”
                                {
                                WindowsFeature DNSExample
                                                {
                                                Ensure = “Present”
                                                Name = “DNS”                                                }
                                }
}

NOTA: en Node podría usarse una variable previamente definida, por ejemplo $Servers o eventualmente Localhost para que sirva en varios equipos.


Antes de comenzar con la configuración verificamos que el rol DNS no está instalado en el servidor LON-SVR1

Consulta de Sintaxis para el Resource "WindowsFeature"

Mediante Get-DscResource windowsfeature -Syntax averiguamos la sintaxis para el recurso Feature. El resultado nos muestra las opciones "Name" y "Ensure" utilizadas en el script del ejemplo.

WindowsFeature [String] #ResourceName

{

    Name = [string]

    [Credential = [PSCredential]]

    [DependsOn = [string[]]]

    [Ensure = [string]{ Absent | Present }]

    [IncludeAllSubFeature = [bool]]

    [LogPath = [string]]

    [PsDscRunAsCredential = [PSCredential]]

    [Source = [string]]

}

Preparación del Script:

El script se debe ejecutar como función. Una forma sencilla de lograrlo es agregar el nombre de la función en la última línea del script (TestConfig en el ejemplo)

En la figura siguiente vemos el script editado en Powershell ISE

Guardamos el script con  en la carpeta C:\DSC con el nombre TestConfig.ps1

Ejecución del script:

Lo ejecutamos mediante la sentencia C:\DSC\> .\TestConfig.ps1

El script en sí no aplica la configuración, sino que crea un archivo MOF que es un archivo de texto con la configuración que se va a aplicar.

El archivo MOF podría crearse manualmente, aunque es más sencillo seguir los pasos previos.

Puede verse el archivo MOF editado con Notepad.

A continuación se invoca el MOF usando el CMDLET Start-DscConfiguration

Start-DscConfiguration –Wait –Verbose –Path .\TestConfig

La opción Verbose permite que se vea el progreso de la configuración.

Al terminar se volvió a ejecutar Get-WindowsFeature para ver el estado del rol DNS.

Puede verse en la pantalla siguiente que DNS Server está instalado. 

Elegir entre Windows Containers y Hyper-V Containers

Introducción

Windows Server 2016 incluye el rol Containers, que permite crear y administrar Windows Containers y Hyper-V Containers.

La creación y administración de ambos tipos de containers es muy similar. En esta nota daremos algunas pautas para ayudar a elegir el modelo más conveniente.

Diferencias en el licenciamiento

Los Hyper-V Containers adhieren al mismo modelo de licenciamiento de las máquinas virtuales.

En un Host Datacenter Edition se pueden crear ilimitados Hyper-V Containers

En un Host Standard Edition se pueden crear hasta dos Hyper-V Containers por cada paquete de licencias.

En cambio, los Windows Containers son ilimitados para ambas ediciones de Windows Server 2016.

Diferencias de aislamiento de procesos

En las máquinas virtuales, el sistema operativo se ejecuta en User mode y Kernel mode (hay un kernel mode para cada guest).

Los Windows Server Containers solamente utilizan user mode, permitiendo a los procesos de Windows y procesos de aplicaciones ejecutarse en el container, aislado del user mode de otros containers.

Por este motivo, los Windows Containers no consiguen un completo aislamiento, ya que trabajan con un único Kernel mode en común.

Los Hyper-V Containers en forma similar a las máquinas virtuales son child partitions, el sistema operativo guest del Hyper-V container no es el sistema operativo Windows normal, sino una versión reducida (que tampoco es la versión Nano).

El nivel de aislamiento que provee el Hyper-V container para cada child partition es entre el Hyper-V container con otros Hyper-V containers en el host, el hipervisor y la parent partition del host.

La siguiente figura muestra la diferencia entre ambos tipos de containers.

Ejemplo 1: Hyper-V Container

A continuación se crea un Hyper-V Container llamado TestIISH y se ejecuta dentro del container Notepad.exe

Para crear el container se ejecutó el siguiente comando:

docker run -d --name TestIISH --isolation=hyperv microsoft/iis -p 80:80

Ejecutamos un CMD dentro del container y luego Notepad.exe:

docker exec -i TestIISH cmd

C:\Windows\System32>notepad.exe

PS C:\Windows\System32> get-process -name n*

Vemos el proceso Notepad con ID 2668 dentro del Container

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id     SI  ProcessName

-----------   -------        -----         ------         ----           -----    ---   -------------

  128            9           1984       7632        0.08        2668   1     notepad

Se ejecuta el comando Get-Process en el host y se verifica que no está el proceso del notepad pero si aparecen procesos llamados vmwp (virtual machine work process)

PS C:\Users\Administrator> get-process n* (no hay resultados)

PS C:\Users\Administrator> get-process v*

Handles  NPM(K)    PM(K)       WS(K)     CPU(s)     Id   SI    ProcessName

-------         ------        -----            -----        ------          --    --     -----------------

    294        31         4928         13264       0.14   2996     0       vmcompute

      0      2770      1072600     616020      0.00   1280     0       vmmem

      0       2717     1050640     346972      0.00   3184     0       vmmem

      0      2724     1050640         16           0.00   3852     0       vmmem

    617      22         10288         23936       0.27   2312     0       vmms

   4488     18         40688         21756      10.05  1872     0      vmwp

    238       5          35640         16392       1.41   3844     0      vmwp

    130       9            1588           7716        0.02   1192    0      VSSVC

Ejemplo 2: Windows Container

Se crea un Windows Container llamdo TestIISW se ejecuta Notepad y se ve el proceso dentro del container con ID 3768

docker run -d --name IISTestW -p 80:80 microsoft/iis

docker exec -i IISTestW cmd

C:\Windows\System32>notepad.exe

PS C:\Windows\System32> get-process -name n*

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)    Id       SI    ProcessName

   -------       ------      -----          -----            ------       --        --      -----------

    128         9           1684       7600           0.02     3768    3      notepad

A continuación Se ejecuta Get-Process en el host 

PS C:\Users\Administrator> get-process -name n*

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id       SI   ProcessName

-------       ------          -----          -----          ------        --       --      -----------

   128        9             1684         7600        0.02      3768    3      notepad

El proceso Notepad con ID 3768 también está presente en el host. Se nota la diferencia de aislamiento respecto del Hyper-V Container.

Instalar Nano Server mediante Nano Server Image Builder

Cuando desplegamos Windows Server 2016 en su versión Nano Server habitualmente lo hacemos mediante comandos de Powershell. De este modo obtenemos la imagen VHD o VHDx que usaremos en una Máquina Virtual o en un equipo físico.

Microsoft desarrolló la aplicación Nano Server Image Builder que permite la creación y personalización de la imagen mediante un menú gráfico, de una manera más sencilla e intuitiva.

Esta aplicación puede descargarse desde el siguiente enlace:

https://www.microsoft.com/en-us/download/details.aspx?id=54065

En este mismo enlace pueden consultarse los pre requisitos para instalar la aplicación. Entre ellos debe estar instalado ADK (Assessment and Deployment Kit)

ADK puede obtenerse del siguiente enlace:

https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit

Una vez iniciado el asistente, nos permite elegir entre crear una imagen de Nano Server y Crear un medio USB de inicio (esta última opción sería útil para desplegar Nano Server usando una imagen Wim, procedimiento que no haremos en esta demostración).

Continuamos el asistente seleccionando la opción Create a new Nano Server image

Se debe indicar la ruta donde se encuentran los medios de Windows Server 2016, en nuestro caso en la unidad D: 

Aceptamos los términos de licencia para poder continuar. Vale aclarar que para utilizar Nano Server se debe contar con un acuerdo de licencias Software Assurance

En la pantalla siguiente se establecen las rutas y el nombre del archivo VHD o VHDX que vamos a usar. En este ejemplo se seleccionó una extensión VHDX 

También puede establecerse un tamaño máximo para el disco virtual

Se seleccionan los paquetes adicionales, en nuestro caso elegimos Web Server

El asistente permite agregar drivers al disco virtual. Esta opción es de especial importancia cuando usamos el disco virtual en un equipo físico donde debiéramos agregar los drivers de disco y de red si fueran necesarios

Establecemos el nombre del equipo, contraseña del administrador y zona horaria

Elegimos unir equipo al dominio, en este caso se creará automáticamente la cuenta del equipo en Active Directory. Existe la posibilidad de usar un blob previamente generado mediante Djoin /provision.

La página siguiente permite establecer excepciones en el firewall y configurar los parámetros de red. En nuestro caso usamos IP dinámica.

Seleccionamos la opción más directa para crear la imagen básica de Nano Server. La configuración avanzada permite entre otras cosas agregar scripts y seleccionar opciones de administración y depuración. 

Antes de crear el disco virtual podemos ver el resumen con las opciones seleccionadas

La creación de la imagen demora unos minutos. En la pantalla siguiente puede verse el comando New-NanoServerImage con las opciones seleccionadas previamente en el asistente

Copiamos la imagen nano16vm.vhdx al host de virtualización. Luego creamos la máquina virtual conectando ese disco en una controladora virtual SCSI.

En este caso, la máquina virtual es Generación 2 debido a que el disco virtual es VHDX (si se hubiera elegido VHD tendría que haberse creado una máquina virtual Generación 1).

En la pantalla siguiente pueden verse las propiedades de la máquina virtual NANO-SVR01

Para comprobar que la imagen generada está correcta, iniciamos la máquina virtual NANO-SVR01.

En la pantalla siguiente podemos ver la consola de recuperación de Nano Server del servidor SVR-NANO01.