Hola
TMG 2010 es la evolución de ISA Server, cuya ultima versión era la 2006, y que hereda el nombre de la familia Forefront de productos orientados a diferentes aspectos relativos a la seguridad:
Como se puede observar está únicamente disponible en x64, y solamente la consola de gestión puede ser montada en un equipo de 32-bit. De hecho esta era una carga de trabajo que no podía beneficiarse de las ventajas de correr sistemas operativos x64, ya que todos los drivers que ISA 2006 incluía eran de 32-bit.
También puede descargarse una versión de evaluación del producto:
Toda la información del producto y recursos técnicos se pueden encontrar aquí:
Tanto ISA como TMG están soportados en entornos virtualizados. Aquí podréis encontrar un buen whitepaper sobre las consideraciones a tener en cuenta en esos casos:
Estaba esperando tener los binarios finales para intentar montarlo en un equipo de Celestix que hoy en día constituye la puerta de entrada al laboratorio con ISA 2006.
Saludos
David Cervigón
Un excelente compendio de información que han recolectado y centralizado en TechNet los diferentes grupos de producto:
Como veis, hay información, guías y recursos para las diferentes fases de planificación, instalación, despliegue, gestión, soporte de cargas de trabajo específicas…
Se acercan fechas en las que preocuparse por la decoración de la oficina, y para ello qué mejor que unos posters con la explicación de los principales características y funcionalidades de Windows Server 2008 y Windows Server 2008 R2:
Un par de ejemplos:
Esto son solo 2/8 de uno de los posters. Buscaros cualquier excusa para imprimirlos en un buen plotter, porque incluso en A3 no hay manera de ver gran cosa.
Posts anteriores:
Continuando con esta serie dedicada a las diferentes tecnologías de Virtualización del Escritorio, hoy vamos a tratar acerca de cómo montar una granja de Remote Desktop Session Hosts (es decir, Terminal Servers). Estas granjas nos van a permitir acceder a aplicaciones de dos maneras distintas:
Como ya hemos dicho en post anteriores, las aplicaciones en el Remote Desktop Session Host pueden estar a su vez virtualizadas con App-V, lo que nos permitirá servir incluso diferentes versiones de la misma aplicación usando el mismo conjunto de servidores.
Antes de dar detalles acerca de la configuración, vamos a ver cómo es el proceso de conexión ya que es sensiblemente diferente al que se usar para conectar usuarios con máquinas virtuales. Recordemos que el actual Remote Desktop Connection Broker que utilizan los pools de VDI es una evolución del que se ha venido utilizando para distribuir las sesiones de usuario entre servidores de Terminal Server desde hace años, por lo que de hecho es este role el que nos ofrece una solución unificada de acceso a escritorios virtualizados, bien por sesiones, bien por VDI.
Proceso de conexión a una granja de Remote Desktop Session Hosts
Configuración del método de balanceo
No voy a incidir en el proceso de instalación del Sistema operativo ni del role de Remote Desktop Sessión Host, ni tampoco sobre el proceso de instalación de las aplicaciones. Sobre este punto, el único matiz que hay que tener en cuenta a la hora de usar App-V en estos entornos es que, al ser Windows Server 2008 R2 única y exclusivamente de 64-bit, necesitamos el cliente de App-V 4.6, actualmente en fase Beta. El resto es tal y como se describía en Montando un escenario de Virtualización del Escritorio: El Cliente de App-V
Lo primero que hay que tener claro es qué método vamos a utilizar para balancear la carga de trabajo entrante a la granja. Como decía antes contamos con dos métodos software, además de los consabidos balanceadores hardware que quedan fuera del ámbito de este post:
En el caso de los Remote Desktop Services, utilizar estas afinidades constituyen un sistema de brokering extremadamente simple, que no se aprovecha de capacidades de reparto de la carga pero que puede cumplir las veces. Sin embargo, cuando estamos usando el Remote Desktop Connection Broker, debemos usar la afinidad a “none”, de modo que cada conexión pueda ser tratada y redirigida. En este artículo de TechNet se explica como usar NLB para balancear las conexiones entrantes a una granja de terminales con una única NIC por host, usando un modelo de unicast: Network Load Balancing Step-by-Step Guide: Configuring Network Load Balancing with Terminal Services Aunque lo anterior es suficiente, aquí vamos a utilizar dos NICs por servidor, donde dedicaremos una para gestión y uso propio del host, y otra exclusivamente para aceptar las conexiones RDP remotas de los clientes. En esta segunda NIC de cada hosts simplemente enlazaremos TCPIP, donde pondremos la IP dedicada que le corresponda a cada uno. Necesitaremos una IP adicional para el cluster, que tendremos que registrar en el DNS. CONSIDERACIONES: Si los servidores están virtualizados, hay que acordarse de marcar la casilla “Enable MAC Spoofing” en las propiedades de esta tarjeta. NLB sobreescribe o agrega direcciones MAC a las tarjetas de red, y en el caso de las tarjetas virtuales debemos permitir explícitamente que esto suceda. Si se juega a cambiar de un modelo a otro de balanceo y se utiliza el mismo nombre de granja, hay que recordar limpiar las caches DNS del broker y clientes involucrados con ipconfig /flushdns, además de, lógicamente, agregar/borrar/cambiar las entradas en el DNS. Veamos el proceso para crear el cluster: Agregamos el primer host del cluster en la consola de NLB, seleccionamos la NIC que vamos a dedicar a NLB y respetamos su IP dedicada Ponemos la IP del cluster y el nombre de la granja, que tendremos que registrar en el DNS. En este caso elegimos unicast (la MAC asociada a la IP del cluster sobreescribe la MAC de la NIC) Elegimos las reglas de balanceo. En este caso es única, para el puerto TCP 3398, con afinidad a “none” Agregamos el segundo host, elegimos la misma NIC, también respetamos la IP dedicada y respetamos la regla que hemos creado en el punto anterior Tras haber seguido alguno de estos dos métodos, un telnet al puerto 3389 contra el nombre de la granja debe funcionar.
En el caso de los Remote Desktop Services, utilizar estas afinidades constituyen un sistema de brokering extremadamente simple, que no se aprovecha de capacidades de reparto de la carga pero que puede cumplir las veces. Sin embargo, cuando estamos usando el Remote Desktop Connection Broker, debemos usar la afinidad a “none”, de modo que cada conexión pueda ser tratada y redirigida.
En este artículo de TechNet se explica como usar NLB para balancear las conexiones entrantes a una granja de terminales con una única NIC por host, usando un modelo de unicast:
Aunque lo anterior es suficiente, aquí vamos a utilizar dos NICs por servidor, donde dedicaremos una para gestión y uso propio del host, y otra exclusivamente para aceptar las conexiones RDP remotas de los clientes. En esta segunda NIC de cada hosts simplemente enlazaremos TCPIP, donde pondremos la IP dedicada que le corresponda a cada uno. Necesitaremos una IP adicional para el cluster, que tendremos que registrar en el DNS.
CONSIDERACIONES:
Veamos el proceso para crear el cluster:
Tras haber seguido alguno de estos dos métodos, un telnet al puerto 3389 contra el nombre de la granja debe funcionar.
Configuración de los Remote Desktop Session Hosts (ver http://technet.microsoft.com/en-us/library/cc771383.aspx)
Todos los hosts de la granja deben ser informados de cual es el nombre de la granja a la que pertenecen y que bróker es quien s encarga de gestionar la granja. Esto se especifica en la consola de la configuración del Remote Desktop Session Host de cada uno de ellos (Herramientas Administrativas)
Como se puede observar, es en este único sitio donde decimos que el host es miembro de una granja, el nombre de la misma y cual es su broker. En este caso estamos usando redirecciones basadas en direcciones IP (ver http://technet.microsoft.com/en-us/library/cc732852.aspx), y al estar usando dos NICs utilizaremos para las reconexiones la IP dedicada de la NIC enlazada a NLB.
Lógicamente, todos los Remote Desktop Session Hosts deben estar configurados de forma idéntica, tener instalado (o virtualizado con App-V)el mismo software y estar publicando las mismas aplicaciones si es así como las queremos consumir. Esto último podemos garantizarlo trabajando sobre uno de ellos y exportando la configuración a los demás:
Configuración del Connection Broker (ver http://technet.microsoft.com/en-us/library/cc753630.aspx)
En el connection broker tendremos simplemente que agregar los Remote Desktop Session Hosts de la granja al grupo local “Session Broker Computers”:
Si además queremos que un Remote Desktop Web sea capaz de publicar las aplicaciones servidas por los servidores de la granja a través de este broker, solo tenemos que agregarla como una fuente de RemoteApps en la consola de configuración:
Una vez llegados a este punto, deberíamos tener una granja de servidores de sesiones de usuario funcionando a pleno rendimiento.
Dado que estamos comprobando que estos temas suscitan bastante interés, ya que son un componente tan importante como a menudo olvidado de los estudios de viabilidad y rentabilidad de proyectos de virtualización, vamos a intentar ampliar en esta webcast toda la información que ya recogimos en el post Licenciamiento en entornos virtualizados.
Como de costumbre, el registro es gratuito y la sesión quedará grabada para poder ser consultada offline.