Archivo

Archivo para diciembre, 2016

Upgrading Remote Desktop Services deployments to Windows Server 2016 (Parte I de II )

viernes, 16 de diciembre de 2016 Sin comentarios

 

No somos muchos los que tuvimos y mantenemos la visión de apostar por una arquitectura robusta, escalable, en constante evolución y muy competitiva en el plano económico.

Hablo de los servicios RDS de Microsoft:
Remote Desktop Session Host, Remote Desktop Connection Bróker, Remote Desktop Gateway, Remote Desktop Web Access, Remote Desktop App, RD License Server y por supuesto Hyper-V.

¿Se admiten las actualizaciones de sistema operativo con los roles y las función de RDS instalado a Windows Server 2016?
Sí, pero con matices, veamos por qué:

Servidores de Remote Desktop Connection Bróker (En adelante RDCB)
Es obligatorio actualizar en primer lugar, los servidores de agente de conexión de RD o Bróker. Insisto, debe/n ser los primeros en actualizarse.
Primer matiz
Microsoft no soporta los servidores Windows Server 2012 R2 con el rol de RD Conexión Broker en una implementación mixta con servidores Windows Server 2016.
Sin embargo, al revés sí, una vez que los servidores de RDCB están ejecutando Windows Server 2016, el despliegue será funcional, aunque el resto de los servidores del despliegue todavía estén ejecutando Windows Server 2012 R2, como pueden ser tal vez los Host de Virtualización de RD, en definitiva, los Hyper-V.
Si hay una configuración activo/activo en el despliegue, se deben actualizar todos los servidores al mismo tiempo y durante el despliegue no estarán disponibles los servidores de RDCB.

Servidores de Remote Desktop License Server
Segundo matiz
Si vamos a actualizar los Host de sesión de escritorio remoto, normalmente las VMs, a Winsdows 2016, antes debemos actualizar el servidor de RD License Server
La CAL utilizada debe corresponder a la versión de Windows Server que se está conectando el dispositivo o usuario. Se puede utilizar CAL mayores para acceder a versiones más recientes de Windows Server, y podremos utilizar las CAL más nuevas para acceder a versiones anteriores de Windows Server.

La siguiente tabla muestra la compatibilidad de CAL en los RDSH y los Hosts de Virtualización de RD.

cals

Los servidores Remote Desktop Session Host (En adelante RDSH) 
Tercer matiz
Las actualizaciones para Windows Server 2016 son compatibles solamente si los RDSH son Windows Server 2012R2 y Windows Server 2016 TP5.
Además todas las aplicaciones instaladas en los RDSH, deben desinstalarse antes y volverlas a instalar después para evitar cualquier problema de compatibilidad de aplicación.

Cómo actualizar una Colección de sesiones de RDSH

  1. Identificar en la colección los servidores RDSH que vamos a actualizar.
  2. Impedir o evitar nuevas conexiones a estos servidores estableciendo a false la opción, Allow New Connections
  3. Desconectar todas las sesiones abiertas en los RDSH
  4. Quitar los RDSH de la colección.
  5. Actualizar los servidores a Windows Server 2016.
  6. Añadir los RDSH actualizados a sus Colecciones correspondientes.
  7. Modificar Allow New Connections en “true” para los RDSH actualizados de la colección.

Los servidores RD Web Access
Pueden actualizarse en cualquier momento. En el caso de RD Web con Windows Server 2012 y 2012 R2 trabajarán bien con implementaciones de Windows Server 2016. Sin embargo hay que tener en cuenta que la actualización puede restablecer propiedades del IIS (como los ficheros de configuración). Para no perder los cambios, es muy recomendable sacar unas pantallas o unas notas de las personalizaciones hechas al sitio Web de RD en IIS.

Los servidores RD Gateway (En adelante RDG)
También pueden actualizarse en cualquier momento. En el caso de RDG con Windows Server 2012 y 2012 R2 trabajarán bien con implementaciones de Windows Server 2016.
Sin embargo, Windows Server 2016 no incluye las políticas de protección de acceso de red (NAP). Éstas tienen que eliminarse antes de actualizar. Para administrar las directivas de NAP, abra la herramienta de servidor de directivas de red. Después de eliminarlos, haga clic en Actualizar la herramienta de configuración para continuar con el proceso de actualización.

Los servidores Remote Desktop Virtualization Host
Está opción estará disponible en la próxima entrada: Upgrading Remote Desktop Services deployments to Windows Server 2016 (Parte II de II )

Categories: Windows 2016 Tags:

NUMA en Hyper-V

jueves, 15 de diciembre de 2016 Sin comentarios

NUMA viene de “Non uniform Memory Access o Non Uniform Memory Architecture” y nació de la necesidad de incorporar funcionalidades en el hardware que permitieran un incremento mas lineal del rendimiento, a medida que los servidores cada vez tenían mas procesadores.

AVISO: Antes de seguir es necesario que te insista en que preocuparte por NUMA no es necesario salvo que quieras optimizar un sistema hasta las ultimas consecuencias y necesites hasta la ultima gota de rendimiento y aun en ese caso hay otras muchas cosas de las que preocuparse por optimizar antes que NUMA.

Una forma simple de entender NUMA es decir que en un servidor multiprocesador que pueda usar NUMA va a generar unos grupos llamados nodos, formados por uno o mas procesadores y una cantidad de memoria, normalmente los procesadores dentro de un nodo comparten físicamente un bus de sistema y un canal de entrada salida con el sistema.

Los diferentes nodos están conectados entre si por un bus de interconexión.

El sistema tratara de correr los hilos en los procesadores asociados a la memoria hasta donde el hilo trata de acceder.

Las APIs del sistema permiten además a las aplicaciones ser conscientes de NUMA lo que puede redundar en mejoras de rendimiento, la virtualización es una de las cargas que mas puede beneficiarse de NUMA por esta razón Microsoft invirtió en Hyper-V de cara a extraer lo máximo de NUMA.

Gracias a esta arquitectura los procesadores pueden usar la memoria dentro de su nodo NUMA de forma mucho mas rápida que la que esta en otros nodos, esto redunda en un mayor numero de ciclos de reloj disponibles para otras actividades lo que implica un mejor rendimiento del sistema, cuantas mas VMs tiene un servidor de Hyper-V mayores son los beneficios de NUMA.

En sistemas no NUMA todos los procesadores tienen el mismo derecho a acceder a los recursos de memoria e I/O cuantos mas procesadores tienen estos sistemas menos eficiente son en el uso rápido de los recursos.

Una maquina no NUMA funciona así:

image

Mientras que una NUMA organizara los recursos en nodos como he contado:

image

La inquietud por NUMA en la virtualización viene cuando una VM necesita recursos de mas de un nodo NUMA debido a que el uso de esos recursos será mas lento que si usa recursos locales a su nodo.

Preocuparse por NUMA no es algo común, muchos administradores no conocen de su existencia, no es algo que debamos hacer en el día a día en una instalación normal, sin embargo en ciertas situaciones entender NUMA puede ayudarnos a comprender por que un sistema no rinde como nos gustaría o como optimizar mejor un host de virtualización.

NUMA es lo suficientemente inteligente como para ser consciente de  por ejemplo agrupar los cores de un mismo procesador en vez de cores de diferentes procesadores.

En procesadores AMD crean un nodo por procesador mientras que en Intel puede variar.

Por ultimo decir, que los nodos NUMA puedes estar contenidos en grupos, cada grupo tiene un máximo de 64 procesadores lógicos (cores o hilos si usas hyperthreading) el numero máximo de grupos es 4 numerados del 0 al 3, en sistemas con menos de 64 procesadores lógicos veras un solo grupo NUMA con los nodos que sean necesarios.

Os voy a explicar NUMA para vuestro conocimiento de Hyper-V, ten en cuenta que en general la penalización de rendimiento por falta de afinamiento de NUMA es muy pequeña.

La optimización de NUMA es especialmente interesante y productiva cuando hablamos de hosts de Hyper-V muy estáticos que normalmente siempre tienen las mismas VMs. En sistemas mas dinámicos optimizar NUMA no es sencillo y en algunos casos no es posible.

Algunos servidores incluyen una alternativa a NUMA llamada SUMA si es tu caso no la actives, Hyper-V y Windows Server se benefician de NUMA, SUMA esta pensada para sistemas que no sean capaces de aprovechar estas capacidades.

Que vamos a ver

  • Como saber si mi servidor esta usando NUMA y que nodos tengo
  • ¿Por que me tiene que preocupar NUMA en un host de virtualización?
  • NUMA y la memoria dinámica
  • La afinidad de las VMs a nodos NUMA
  • ¿Puedo evitar que los recursos de una VM se extiendan a mas de un nodo NUMA?

Como saber si mi servidor esta usando NUMA y que nodos tengo

Una forma de ver los nodos NUMA que tienes y con que recursos cuentan son los contadores de Hyper-V con respecto a NUMA:

 ¿Por que me tiene que preocupar NUMA en un host de virtualización?

Cuando un hilo corre sobre un procesador que esta en el mismo nodo que la memoria a la que quiere acceder entonces el rendimiento es fantástico, cuando por el contrario esta situación no se da, el rendimiento es algo peor, no es el fin del mundo y la mayoría de los sistemas se enfrentan a esta condición a diario sin conocimiento de sus administradores.

Cuantificar esta penalización en un % es muy difícil dado el numero de factores que entran en juego, la cifra depende mucho del tipo de carga, podemos decir que una VM con muchos procesadores y con mucha RAM es mas susceptible de este problema y que en caso de darse, si la VM ejecuta cargas que hacen uso intensivo de operaciones de memoria o de operaciones SMP entonces la VM se vera aun mas afectada.

Los host de virtualización gestionan unas cargas muy dinámicas en cuanto a recursos, una VM puede usar memoria dinámica o en cualquier momento una VM con mas de un procesador puede verse afectada por la imposibilidad de encontrar tiempo libre de tantos procesadores como necesite dentro del mismo nodo NUMA.

En un sistema NUMA, por defecto cada VM tiene un nodo preferido, Hyper-V siempre trata de asignar memoria del mismo nodo a la VM.

Hyper-V establece este nodo preferido cada vez que  la VM arranca, como Hyper-V no puede predecir la carga que la VM tendrá es posible que con el tiempo esta VM requiera recursos que estén en otros nodos y esto conducirá a lo que denominamos fragmentación NUMA.

Desde el performance monitor puedes ver también en que nodo NUMA esta corriendo cada VM y en el contador “Remote physical pages” os dais cuenta de si se esta usando memoria de otros nodos.

NUMA y la memoria dinámica

Aunque NUMA afecta a la red y a los procesadores también, os voy a contar el ejemplo de la memoria dinámica por que es el mas fácil de entender:

Hyper-V siempre tratara de ubicar toda la memoria de una VM en un único nodo NUMA.

image

Pero si no es posible tendrá que usar memoria de varios nodos NUMA, esto puede pasar en el arranque de una VM, pero la probabilidad aumenta de que pase en ejecución cuando usas memoria dinámica, tu VM seguirá funcionando igual de bien, pero el rendimiento bajara un poquito.

image

Usar memoria dinámica aumenta las probabilidades de que una VM tenga que repartirse entre varios nodos NUMA lo normal será, insisto que esto no nos preocupe salvo en condiciones muy extremas.

La afinidad de las VMs a nodos NUMA

Es posible configurar que las maquinas virtuales tengan afinidad con un nodo NUMA, obviamente esto es algo que se debe de analizar cautelosamente debido a la cantidad de implicaciones que tiene en la gestión de los recursos. Cuando se cambia el nodo preferido para una VM, es necesario reiniciarla.

¿Puedo evitar que los recursos de una VM se extiendan a mas de un nodo NUMA?

En event viewer de los servidores hay eventos indicándote si en algún momento se ha tenido que usar recursos de otro nodo para servir por ejemplo la memoria pedida por una ampliación realizada a través de memoria dinámica. En Hyper-V, desde W2K8R2 tiene la posibilidad de evitar que una VM use recursos de mas de un nodo.

Activar esta opción tiene claras connotaciones como que por ejemplo se reducirá el numero de VMs que podremos correr en el host o se limitara la memoria RAM máxima que pueda tener una VM en función de la que este disponible en el nodo NUMA en la que corra.

hv

Cuando activamos éste parámetro desde el punto de vista de los recursos del host es como si dividieras tu servidor en servidores de virtualización mas pequeños

Categories: Sin categoría Tags: