Reglas de QoS aplicadas evitando flujos de tráfico de datos incontrolados

Todos sabemos lo importante que es tener un Plan de Recuperación antes Desastres, ya bien sea con una solución On-Premises (distintas ubicaciones geográficas) o híbrida (Azure Site Recovery, Amazon Site Recovery, etc…) o haya como lo tengáis implementado. Seguramente, el que haya tenido la idea de implementarlo o lo tenga implementado, una de las cosas con la que se habrá encontrado es la de gestionar el ancho de banda que este proceso continuo le consumirá. Claramente, nadie quiere desperdiciar recursos y no todas las organizaciones por grandes que sean, tienen todos los elementos necesarios para ser capaces de controlar las ráfagas de tráfico que estos procesos pueden llegar a consumir.

En muchas empresas se dispone de dispositivos para gestionar los tráficos de red, utilizando múltiples tecnologías para ello, pero sino fuese así, voy a mostraros como podemos gestionar que ancho de banda vamos a “reservar” para algunos procesos con cierta intensidad de carga hacia Internet.

Con Windows desde hace muchos años, tenemos algo que se llama QoS basada en directivas, el cual podemos utilizar para más cosas de las que alguno se pueda pensar. Tirando de la temática de Plan de Recuperación ante Desastres, me gustaría centrar este artículo en los servicios de Azure Site Recovery, Azure Backup y AzCopy para aplicar diferentes reglas de QoS para que no saturar nuestros enlaces de Internet.

Como siempre, vamos a empezar por el escenario sobre el cual trabajaremos en este artículo, para ello… aquí va la infografía:

La infografía viene a representar un escenario donde tenemos en una empresa varios procesos que utilizan de forma intensiva Internet, pero  en diferentes ventanas horarias y tenemos que ser capaces de ofrecer un servicio mínimo durante las horas de mayor pico de usuarios conectado a la red. Debemos  garantizar, que los servicios tienen continuidad, no sólo los mostrados en la infografía sino también el acceso a Internet (navegación Web, Outlook, Skype/Teams, etc…) por parte de los usuarios.

Las diferentes configuraciones de QoS las podemos realizar de varias formas:

• Editando de forma manual las Directivas de Grupo locales de los equipos
• Creado directivas de Grupo desde nuestro controlador de dominio
• Utilizando PowerShell
  • Configuración manual en el propio servidor
  • Configuración automática utilizando para ello directivas de grupo

Antes de nada, debemos saber que podemos configurar en una Política de QoS en un sistema operativo Windows, aquí os muestro las características disponibles en una regla de QoS:

• Especificar valores DSCP: podemos definir valores DSCP para etiquetar el tráfico de red y que dispositivos de red de capas superiores puedan manejarlo con sus reglas de QoS y así darle continuidad
• Definir la velocidad máxima de la interface: aquí es donde podemos definir el ancho de banda máximo que va a poder utilizar nuestras interfaces de red
• Aplicación: podemos definir si se aplicar a todo el tráfico de red que pase por la interface de red, a aplicaciones concretas o destinos HTTP
• Origen y Destino: nos permite definir la IP de Origen y/o de Destino del tráfico
• Protocolos y Puertos: podemos definir los puertos de Origen y Destino (incluso rangos de puertos) y protocolos (TCP/UDP)

Con esto, yo creo que ya empezamos a tener claro que podremos configurar en base a nuestros requisitos/necesidades. En este caso, os voy a mostrar como configurarlo de forma manual editando las directivas de grupo locales de un servidor y lo más interesante es configurarlo por PowerShell porque tenemos la opción más interesante sólo disponible desde consola (tienes que seguir leyendo el artículo …).

Lo primero es saber en base a que parámetros vamos a realizar nuestra configuración, para ello tenemos que hacernos las siguientes preguntas:

• ¿Conocemos las aplicaciones que queremos manejar?
• ¿Conocemos las direcciones IP de Origen y Destino de nuestro flujo de tráfico?

El resto de parámetros no es que los tengamos que obviar, pero no es tan necesario conocerlos ya para nuestras primera configuración. En mi caso lo tengo claro, como quiero ajustar el ancho de banda de Azure Site Recovery, mis preguntas se responden de la siguiente forma:

• ¿Conocemos las aplicaciones que queremos manejar?:
  • cbengine.exe: proceso utilizado por el Configuration Server para replicar las máquinas virtuales con Azure
  • cxps.exe: proceso que utiliza nuestro Configuration Server para las máquinas virtuales que estamos replicando en Azure, pero es tráfico local, entre los servidores a replicar y el Configuration Server
• ¿Conocemos las direcciones IP de Origen y Destino de nuestro flujo de tráfico?: Si, pero en mi caso ya no es “relevante” para mi definición de regla de QoS

Bien, pues ahora que lo tenemos claro, vamos a configurar una Directiva de QoS de forma manual (es sólo para esta demostración, lo suyo es hacerlo vía GPO desde vuestro Controlador de Dominio) en nuestro servidor con el rol de Configuration Server. Lo primero, iniciamos la consola de Políticas de Grupo Locales (Inicio – Ejecutar – gpedit.msc), un avez dentro nos vamos a Computer Configuration – Windows Settings – Policy-Based Qos  y ahora pulsamos con el botón secundario del ratón y hacemos clic sobre la opción Create new policy…

Definimos  el nombre de la directiva y en mi caso como quiero  definir el tráfico máximo de salida de la interface de red (vamos, controlar el ancho de banda) pues especifico en Mbps el valor que considero oportuno y pulsamos en Next

Como tengo claro el proceso que quiero controlar, selecciono Only applications with this executable name y escribo el nombre de proceso a definir en la regla (voy a diferenciar entre el tráfico entre las máquinas replicadas y el Configuration Server y el que fluye entre el Configuration Server y Azure), en mi caso como primera regla especifico el cxps.exe y pulsamos en Next

En mi caso, como el servidor de Configuration Server sólo tiene una interface de red y el tráfico con los servidores virtuales será repartido de forma indistinta, no realizaré configuración alguna. En cuanto a las redes de destino, tampoco es necesario en mi caso, porque será contra los servidores de Azure para el Site Recovery  y no  necesito especificarlos, pero aquí os dejo un enlace con las direcciones IP Públicas de los servicios de Azure Site Recovery  por si vosotros queréis configurarlo: Acerca de las redes en Azure para la replicación de Azure

Defino que la regla se aplica al tráfico TCP, pero sin definir el rango de puertos, porque insisto, yo quiero controlar únicamente todo el flujo de tráfico del proceso y con esto ya tengo todo cubierto. Una vez que hayamos especificado los valores necesarios, pulsamos en Finish y con esto hemos finalizado nuestra primera regla.

Según vayamos creando diferentes reglas, las iremos revisando desde la propia consola de directivas de grupo locales

Nota: para que se pueda manejar el tráfico con la regla de QoS debemos tener habilitado en la interface de red del equipo el siguiente protocolo: QoS Packet Scheduler. Sin esto, cualquier regla de QoS en nuestro equipo no tendrá efecto sobre la interface de red.

Si ahora queréis verificar que ancho de banda de está utilizando el proceso monitorizado, podéis hacerlo desde el Monitor de Recursos (Resource Monitor) de  vuestro servidor. Simplemente lo iniciáis, filtráis por el proceso que habéis definido en la regla de QoS y veréis que el ancho de banda máximo es el especificado en la regla de QoS

En mi caso, he configurado también otra regla para el proceso cbengine.exe, controlando así el ancho de banda que utilizará dicho proceso y así no saturar los diferentes enlaces de Internet. Como veis en la captura de pantalla, ahora tenemos los procesos filtrados por cxps.exe y cbengine.exe y correspondientes directivas de QoS. Yo he definido que para el cbengine.exe utilice como máximo 10Mbps (porque serán del enlace de Internet) y para el proceso cxps.exe un máximo de 100Mbps (aunque el enlace entre sí es de 1 GB y mediante un switch local). Esto es así, porque, si limitamos a 10Mbps la subida a Azure, no quiero que lleguen ráfagas de tráfico de 1Gbps al Configuration Server y así dejar en cola más peticiones de lo esperado.

 

Si disponéis de alguna herramienta de monitorizacion de vuestro enlace de Internet, podéis ver como habrá subido de forma importante en el momento que habéis configurado el Azure Site Recovery. Aquí el enlace tiene un caudal de 100Mbps simétricos, pero ya se puede apreciar que hemos consumido entre todos los servicios (gráfica captura a las 10:00am) unos 40Mbps. A buen seguro, sino le hubiésemos definido una regla de QoS la gráfica sería de otra forma.

 

Bien, hasta aquí espero que haya quedado claro el proceso, como veis bien sencillo. Como la infografía habla de Azure Site Recovery (Plataforma de Azure para implementar nuestro Site Recovery de forma sencilla), Azure Backup (Servicio de copia de Seguridad de Azure) y AzCopy (Copiado o descarga de datos desde cuentas de almacenamiento de Azure), pues os voy a explicar de forma breve por cada servicio que configuraciones habría que realizar:

• Azure Backup: una regla que establezca que el tráfico del proceso cbengine.exe (si, si utiliza el mismo que el Azure Site Recovery) tenga un máximo de ancho de banda de xxMbps. Aunque esto podemos configurarlo desde la propia herramienta de Azure Backup, no está disponible para Windows Server 2008 R2 SP1, Windows Server 2008 SP2 ni en Windows 7 (con Service Packs). Pero si configuráis Azure Backup para que el gestione el ancho de banda en función del horario, podéis ver que realmente lo que está haciendo es crear una Directiva de QoS en el servidor, aquí os dejo una captura de pantalla al respecto (Nota: esta configuración sólo se puede ver vía PowerShell (Get-NetQoSPolicy):

• AzCopy: esta regla de QoS es muy sencilla, simplemente configuras una regla definiendo que el proceso a monitorizar es AzCopy.exe y listo, ya no dejarás que el AzCopy se “coma” todo el ancho de banda de tu enlace.

Con esto, hemos definido las diferentes directivas de QoS para gestionar o controlar los tráficos de red que pueden estar consumiendo diferentes servicios. Ahora, faltaría que se configurase vía GPO y se aplicase a los servidores/equipos donde se tenga que aplicar y listo, ya lo tendremos controlado. Pero .. como un servidor siempre quiere más (TOC, TOC, TOC y más TOC) pues … que ocurre si ahora queremos definirlo por franjas horarias .. pues que también podemos hacerlo pero ya para eso utilizaremos PowerShell.

Según la infografía, quiero poder definir diferentes anchos de banda en diferentes franjas horarias, así no saturamos los enlaces pero los aprovecharemos mejor en horarios no laborales. Pues para esta configuración, utilizaremos los siguientes elementos:

• Programador de tareas
• PowerShell

Cual es la idea, ejecutar un script (tarea programada) en cada franja horaria establecida para cambiar la prioridad (jeje, si esto es lo comentado el principio del articulo que no se podía hacer por la consola gráfica) de las mismas reglas pero con diferente ancho de banda máxima en cada regla. Pues ahora veremos a continuación, que es tan sencillo como lo he comentado, lo primero es que tengamos las reglas de QoS que necesitamos en función de las ventanas horarias que queramos manejar, si tenemos tres franjas horarias pues necesitamos tres reglas de QoS definidas. Dichas reglas las podemos crear via GPO, esto no lo voy a explicar otra vez, porque creo que es sencillo yo voy a poner las diferentes reglas creadas mediante PowerShell porque puede ser algo que no hayáis visto hasta el momento:

• New-NetQosPolicy -Name “AzureSiteRecovery-100Mbps” -AppPathNameMatchCondition “cbengine.exe” -ThrottleRateActionBitsPerSecond 100MB -store $env:computername
• New-NetQosPolicy -Name “AzureSiteRecovery-75Mbps” -AppPathNameMatchCondition “cbengine.exe” -ThrottleRateActionBitsPerSecond 75MB -store $env:computername
• New-NetQosPolicy -Name “AzureSiteRecovery-50Mbps” -AppPathNameMatchCondition “cbengine.exe” -ThrottleRateActionBitsPerSecond 50MB -store $env:computernam

Ahora, tenemos las tres reglas de QoS pero … todas con la misma prioridad (Precedence) por defecto (127), de esta forma si la regla es la misma, por lo que no podemos definir quien será la que esté actuando en un momento determinado.

Ahora bien, para poder definir que regla se está aplicando, tenemos que definir su prioridad (precedence), para ello utilizaremos PowerShell:

• Set-NetQosPolicy -Name “AzureSiteRecovery-100Mbps” -precedence 250
• Set-NetQosPolicy -Name “AzureSiteRecovery-75Mbps” -precedence 200
• Set-NetQosPolicy -Name “AzureSiteRecovery-50Mbps” -precedence 150

El valor más alto tiene mayor prioridad, por lo que, si queremos que durante una determinada franja horaria establecer una regla de QoS específica, debemos subirle la prioridad. Esto sería sencillo, tener tantos scripts como reglas de Qos definidas, para variar la prioridad:

• Script 1: ejecutado en una tarea programada a las 00:00 (100Mbps  para el Azure Site Recovery según la infografía)
  • Set-NetQosPolicy -Name “AzureSiteRecovery-100Mbps” -precedence 250
  • Set-NetQosPolicy -Name “AzureSiteRecovery-75Mbps” -precedence 200
  • Set-NetQosPolicy -Name “AzureSiteRecovery-50Mbps” -precedence 150
• Script 2: ejecutado en una tarea programada a las 08:00 (50Mbps  para el Azure Site Recovery según la infografía)
  • Set-NetQosPolicy -Name “AzureSiteRecovery-100Mbps” -precedence 150
  • Set-NetQosPolicy -Name “AzureSiteRecovery-75Mbps” -precedence 200
  • Set-NetQosPolicy -Name “AzureSiteRecovery-50Mbps” -precedence 250
• Script 3: ejecutado en una tarea programada a las 22:00 (75Mbps  para el Azure Site Recovery según la infografía)
  • Set-NetQosPolicy -Name “AzureSiteRecovery-100Mbps” -precedence 200
  • Set-NetQosPolicy -Name “AzureSiteRecovery-75Mbps” -precedence 250
  • Set-NetQosPolicy -Name “AzureSiteRecovery-50Mbps” -precedence 150

Cada script lo ejecutaríamos desde una tarea programa a la hora en cuestión y listo, ya tenemos nuestras directivas de QoS preparadas para ajustar los anchos de banda de cada proceso en función de diferentes ventanas horarias. Ahora bien, como quería automatizado, yo lo haría de la siguiente forma:

• Crear un script (New-NetQosPolicy) para creación de todas las reglas de QoS que necesitemos en cada servidor y ejecutarlo en cada servidor a aplicar utilizando alguna de las siguiente formas (son opciones posibles):
  • Creando una GPO con una tarea programa de una única ejecución (si luego necesitas cambiar  las reglas de QoS podrías volver a configurarlo para que se vuelva a ejecutar)
  • Creando una GPO y asignando el script al inicio de sesión del equipo (no me gusta porque tendrás que reiniciar los servidores)
  • Ejecutar el script vía Intune
  • Ejecutarlo manualmente en cada servidor (o remotamente conectado)
• Configurar una GPO que haga los siguiente:
  1. Cree una carpeta llamada Scripts dentro de cada servidor que necesitamos crear las reglas de QoS
  2. Copiar los scripts (que hemos creado con las prioridades) desde alguna carpeta compartida y dejarlos en la carpeta local Scripts del servidor, de esta forma, si modificamos los scripts siempre se actualizarán a los servidores y no tenemos que volver a realizar más actualizaciones de la GPO.
  3. Crear tantas tareas programadas como diferentes horarios queramos manejar (cuenta de ejecución del script: SYSTEM), cada tarea programada ejecutará el script que cambie las prioridades en función de nuestras necesidades

Con esto, tendremos implementado y automatizado las reglas de QoS en nuestros equipos/servidores/aplicaciones y así evitar flujos de tráfico importantes que puedan penalizar el rendimiento de nuestras líneas de datos. El proceso como veis es sencillo, pero muy efectivo y funciona sin mucha complicación.

Se puede simplificar el script, bueno más bien, el no tener tantos scripts, para ello tendríamos que crear un script que compruebe la hora de ejecución y en función de la franja horaria ejecutase un sección de código u otra. Si alguien lo necesita, lo podemos crear y publicar por aquí. El que lo quiera, que deje un mensaje en este artículo y nos ponemos a ello.

Por último, yo me he ceñido a servicios de Azure, pero vamos .. claramente veis que podéis configurarlo para muchísimos servicios.

Como siempre, ahora os toca a vosotros probarlo!!!