Hola
He recibido en los últimos meses muchas consultas acerca de como dimensionar una solución de alta disponibilidad basada en el Failover Cluster de Windows Server 2008, generalmente relacionadas también con el mundo de la virtualización.
En este libro de Excel he intentado plasmar sin demasiadas pretensiones gran parte de las variables que se tienen que tener en cuenta para empezar. Me gustaría compartirla con vosotros para que comprobarais que no he metido la pata y me hicieseis sugerencias acerca de cómo mejorarla. El enlace está al final del post, como un adjunto.
Antes de nada, un par de aclaraciones previas. En primer lugar, este tipo de clúster esta pensado para ofrecer alta disponibilidad por tolerancia a fallos. Y dado que de lo que se trata es que si algún servidor falla o debe dejar de dar servicio por tareas de mantenimiento su pérdida pase lo más desapercibida posible, todo el sistema debe estar sobredimensionado para que los restantes miembros del clúster puedan asumir sin problemas su carga de trabajo. Esto hace que la solución sea cara, dado que la mayor parte del tiempo tendremos recursos que no estaremos utilizando para nada. La segunda es que éste es precisamente uno de los principales talones de Aquiles de todo esto. Tener recursos sin utilizar es algo que suele gustar poco a quienes han pagado dinero por ellos, y la tentación de dar trabajo a la infraestructura “ociosa” es muy tentadora. Pero si lo hacemos y algo sucede, harán una película sobre nosotros por no tener suficientes botes salvavidas para todos los pasajeros del barco.
Dicho esto, vamos a ver como se usa el juguete:
Las cuentas que hace la hoja combinan todos esos parámetros de forma que nos indica cuanto podemos cargar cada nodo, tanto para configuraciones Activo/Activo (se ignora el número de nodos pasivos) como Activo/Pasivo (para el número número de nodos pasivos especificados). En el caso de que el numero de nodos que fallen sea mayor que el numero de nodos pasivos existentes, se sobreentiende que el resto de nodos activos han de asumir carga de trabajo.
Un par de ejemplos:
Dos nodos, con un witness adicional (necesario en este caso). Solo puede fallar un nodo, y si estamos montando un clúster es porque asumimos que puede fallar. Reservamos un 10% de los recursos de cada host para su propio uso.
El nada sorprendente resultado es que en una configuración Activo/Activo cada uno de los nodos deberá cargarse de servicios clusterizados hasta alcanzar un 45% de uso de recursos, y en una configuración Activo/Pasivo el nodo activo puede cargarse hasta el 90%. En ambos casos, si un nodo cae, el otro se queda con el 90% de carga, que es justo lo que queremos.
Vamos ahora a un caso menos trivial. 9 nodos, 8 activos y 1 pasivo, y pensamos que, todo lo mas, se nos pueden llegar a caer 3 nodos simultánemaente. En 9 nodos 5 son mayoría, luego podemos perder 4. Si ponemos un witness adicional nos salen 10 votos, pero en este caso una mayoría son 6 a 4, es decir, que solo podemos perder 4 nodos. Por tanto aquí usar o no un disco de quorum o un file share como witness es irrelevante:
En este caso, no deberíamos sobrecargar cada host activo con más de un 67% de carga de trabajo. Si prescindimos del nodo pasivo la cifra se reduce a 60%.
En la segunda hoja del libro hay una tabla rápida en la que la única variable es el número de nodos pasivos que puede ayudar a centrar un poco el tiro (o directamente nos acaba de confundir por completo):
La parte más discutible de todo esto es precisamente que significan esos porcentajes de carga de trabajo. En el fondo eso lo decide cada uno con mayor o menor acierto (el “performance tunning” es más un arte que una ciencia), pero digamos que representa una media ponderada de RAM, CPU, IO de disco e IO de red. Simplificando mucho las cosas, he incluido los dos primeros para hacernos una idea de lo que esto supone en términos de RAM en Gb y CPU en número de cores. Multiplicando por ese porcentaje nos saldrían los topes de memoria y el número de cores totalmente saturados (al 100% de CPU) que pueden llegarse a consumir por cada nodo y en total para todo el sistema clúster. La diferencia de estos valores con respecto al total de recursos disponibles es el precio que pagamos por la alta disponibilidad.
Hablando ahora de virtualización, ¿cuantas máquinas virtuales me caben si…?. Pues depende. Considerando (incorrectamente) una VM como un mero conjunto de RAM y CPU podemos echar unas cuentas rápidas. Apiñar VMs para intentar demostrar que en una solución equivalente metes más VMs que tu competidor es una práctica muy peligrosa. La cosa debe transcurrir al revés. ¿Que rendimiento deben dar mis máquinas virtuales?. ¿Cómo estaban/están dimensionadas en físico?. ¿Que usos medios de RAM y CPU utilizan?. En función de eso decidimos cuanta RAM y cuantos procesadores virtuales necesitaremos para cada VM, y luego ya podemos dividir.
Supongamos una estructura de VMs homogénea (VDI, servidores estandarizados, etc.). Tenemos la RAM en Gb de cada VM, el número de procesadores que queremos asignarles. Tenemos que decidir un ratio de procesadores virtuales por core físico. Lo normal es que un equipo no esté todo el rato al 100% de CPU. Si está al 25-30% podemos usar razonablemente un ratio 1:4. El numero máximo de VMs que podemos meter en la infraestructura será la que antes sature la memoria o los procesadores.
Veamos un caso. 16 nodos, 2 pasivos, 2 en fallo, con nodos de 32 Gb de RAM y dos procesadores quad-core, a los que les reservamos un 5%: VMs de 512 MB y un solo procesador:
Usamos por tanto 14 nodos y nos caben, redondeando a la baja, 30 VMs por host, y 420 en total. Fijaros que aquí mandan las CPUs. Subir el ratio a posteriori es trampa. Pero si metemos hosts de 4 procesadores quad-core la cosa sube a 60 VMs por host y 840 VMs en total, y en ese caso quien impone la limitación es la memoria.
Cuidado con estas cuentas. ¿Soportarán el almacenamiento y la red estas cantidades?. ¿Y nuestros debilitados corazones?.
Saludos
David Cervigón
P.D: Enhorabuena por llegar hasta aquí. Insisto. Repasadme las cuentas y comunicadme cualquier error o sugerencia que encontréis.
Se han publicado estas guías paso a paso para montar un escenario de publicación de aplicaciones, máquinas virtuales personales y Pools de máquinas virtuales utilizando el Remote Desktop Web Access y el nuevo bróker de conexiones de Windows Server 2008 R2.
Volveré sobre este tema pronto en algunos capítulos de la serie Montando un escenario de Virtualización del Escritorio. Mientras tanto, para el que no pueda esperar, creo que con esta documentación se puede uno hacer una buena idea de la interrelación entre los diferentes roles de Remote Desktop Services, Hyper-V y las máquinas virtuales corriendo sobre el.
Un PDF con una buena colección de enlaces ordenados a toda la documentación técnica de Windows Server 2008 R2 existente hasta el momento:
Y de postre, una buena colección de presentaciones, whitepapers y datasheets, también de Windows Server 2008 R2:
El SP2 de Vista y 2008 se distribuye en una única descarga para todos los idiomas y ediciones. En TechNet/MSDN hay también ISOs de Windows Server 2008 y Windows Vista “slipstreamed”, muy útiles para instalaciones desde cero y creación de imágenes, ya que nos ahorra un precioso tiempo de parcheado.
La lista de las actualizaciones incluidas está en esta hoja de Excel:
y la lista de “cambios notables”:
Esperemos que lo publiquen pronto en el área de descargas de la web pública.
Posts anteriores:
En esta ocasión veremos como desplegar y configurar el cliente de Microsoft Application Virtualization 4.5, que será el encargado de manejar y ejecutar localmente los paquetes de las aplicaciones virtualizadas que estén publicadas en el Management Server. Como suelo decir en estos casos, esta recetilla, como la del post anterior, no exime de la ardua tarea de empollarse la abúndate documentación, sobre todo si esto va a pasar a mayores. Una buena fuente para alimentarse de todo esto puede ser esta:
Como decía en el post anterior, el cliente de APP-V es en esta versión una aplicación de 32-bit, pero, a diferencia de los componentes servidor, tiene dependencias que hacen que no se pueda ejecutar en sistemas operativos de 64-bit (x64). Hay dos versiones, uno común para Windows XP, Vista y Windows 7, y otro específico para Terminal Server 2003/2008 x86 que ofrece la misma funcionalidad.
El proceso de instalación y configuración manual es el siguiente:
Primeramente, el propio MSI nos instala y configura sus dos pre-requisitos: El run-time de Visual C++ y Application Error Reporting:
Comienza el proceso de instalación propiamente dicho. Elegimos la instalación personalizada para poder llevar a cabo la configuración durante el proceso de instalación. Si no, tendremos que realizar la configuración posteriormente también manualmente o por políticas de grupo (ver más abajo).
Especificamos el tamaño de la cache donde se almacenarán los paquetes de las aplicaciones virtualizadas. Puede hacerse por tamaño máximo, o usar un tamaño que garantice un mínimo de espacio libre en disco. Dependiendo de la cantidad y volumen de aplicaciones virtualizadas a ejecutar, habrá que elegir este valor de manera apropiada
Lo siguiente que podemos especificar es el “Application Source Root” o lugar donde por defecto se almacenaran los paquetes de las aplicaciones. Aquí puedes especificar un path UNC, una URL HTTS/HTTPS o una URL RTSP/RTSPS dependiendo de cómo las aplicaciones vayan a ser distribuidas. En nuestro caso el servidor lo montamos con RTSP:
Luego, ponemos un Display Name que represente a nuestro Management server (poner el FQDN es una buena idea), y su hostname. De nuevo, como usamos un servidor sin seguridad mejorada (es decir, sin un certificado para cifrar las comunicaciones), ponemos como tipo “Application Virtualization Server”, lo que nos marca el puerto 554 por defecto. Ni que decir tiene que aquí se trata simplemente de que cuadre lo que se configura en cliente y servidor.
Una vez llegados a este punto, la instalación finaliza sola:
En entornos de virtualización del escritorio, lo normal es contemplar la instalación del cliente de APP-V como parte de las diferentes imágenes que se distribuirán a los diferentes puestos sean físicos o virtuales, y que en ese caso no se haga la personalización de la instalación. También puede suceder que queramos desplegar el cliente a sistemas ya en funcionamiento, lo que lograremos mediante algún sistema de despliegue de software, o vía script, línea de comandos y un poquito de paciencia (How to Install the Client by Using the Command Line).
En el caso de tener nuestros equipos físicos, máquinas virtuales, y/o servidores de terminal con el cliente ya distribuido, es posible que lo queramos configurar de manera desatendida en función de los servidores a los que se vayan a conectar. Para ello existe una plantilla de políticas de grupo específica de APP-V , donde se pueden especificar todos y cada unos de los parámetros relevantes del cliente. Además este método de configuración esta documentado en el APP-V ADM Template WhitePaper.
Tras la configuración de cliente y servidor, ya deberían estar conectados para empezar a servir aplicaciones virtualizadas. En el siguiente capítulo veremos como secuenciar una aplicación para crear el paquete de App-V correspondiente, y como importarlo en el servidor. Mientras tanto, hay quien parece entretenerse mucho secuenciando aplicaciones.
En esta guía podéis encontrar las configuraciones de OCS 2007 que están probadas y soportadas en entornos virtualizados, así como recomendaciones para instalarlo y configurarlo de modo que la solución tenga un buen funcionamiento.
Running Microsoft Office Communications Server 2007 R2 in a Virtualized Topology: Best Practices and Performance Considerations
Esta bastante bien detallada la arquitectura de la solución que se ha probado, con datos de escalabilidad y todo.
Esta es una excelente noticia para todos los amantes del almacenamiento en general y de los clústeres en particular.
Como podéis observar esta tanto el Target como la evaluación del Windows Storage Server 2008, que es lo que se implementa en algunos “appliances” de almacenamiento que se distribuyen por el canal OEM.
Post anterior:
Continuando con la serie, hoy trato cómo montar el “Management Server” de Microsoft Application Virtualization 4.5 que se encargará de distribuir los paquetes que contienen las aplicaciones virtualizadas a los clientes o servidores de Remote Dektop (Terminal Servers).
Como de costumbre, antes de continuar es importante aclarar que lo que sigue a continuación es una trivialización de un escenario que se puede complicar, o incluso simplificar, según vuestras necesidades. Todas las posibilidades que se pueden contemplar a la hora de hacer un despliegue de App-V están recogidas en esta guía:
Por otro lado, mencionar que esta pieza puede no ser en absoluto necesaria en tu escenario de Virtualización del Escritorio. Claro que también puede que sea la única pieza que necesitas para llevar a cabo tu estrategia. Sin embargo, lo normal es que sea una pieza que puedas llegara a usar en ciertas ocasiones, y como reza el título de la serie, esta información esta orientada a montar una infraestructura donde se vean funcionando todas las piezas juntas.
Yendo al grano, App-V son realmente cinco componentes:
El servidor se puede montar tanto sobre sistemas x86 como x64, si bien los binarios son de 32-bit. Los pre-requisitos y componentes del sistema necesarios para funcionar están documentados en Application Virtualization System Requirements. Resumiendo, para lo que vamos a montar aquí (Management+Streaming) necesitaremos:
La instalación transcurre así:
Las primeras pantallas son las típicas:
Se nos solicita el servidor de SQL que albergará ala DDBB, que puede ser remoto. En este caso es local. Usamos una base de datos nueva, en la que dejamos el nombre por defecto (APPVIRT)
El protocolo de streaming puede utilizar un certificado de autenticación de servidor instalado en el quipo para cifrar las comunicaciones. Si tienes un buen despliegue de una PKI, es ciertamente recomendable. Si no, se te convertirá en un dolor de cabeza. Una cosa a tener en cuenta si se usa seguridad mejorada es que deberemos usar el mismo nombre de servidor que hayamos puesto en el certificado en todas partes donde se nos solicite, o si no las conexiones fallarán. Exactamente igual que un navegador cuando accede por SSL a un servidor usando un nombre distinto al configurado en el certificado.
Lo siguiente que debemos introducir son los usuarios que administrarán el servidor y los usuarios que podrán acceder a el. Esto es independiente de que subconjunto de usuarios tendrán derecho o no a usar una determinada aplicación. Si os queréis usar problemas, resolved el nombre del grupo y ponedlo en estas casillas. Esto es mejor que usar el formato habitual Dominio\grupo. En mi caso, sin demasiados quebraderos de cabeza, administradores serán los Domain Admins y usuarios los Domain Users.
Lo siguiente que se nos solicita es la carpeta donde situaremos el contenido, es decir, los paquetes con las aplicaciones virtualizadas. Hace las veces del directorio InetPub\wwwroot, para entendernos:
Con esto, habremos terminado la instalación:
Tras reiniciar, lanzamos la consola (que podemos haber elegido instalar en otro equipo) y la configuramos para apuntar al servidor donde hemos instalado el servicio, recordando marcar o no la casilla se usar conexión segura en función de lo elegido anteriormente. Pidiendo las propiedades del servidor, tendremos que rellenar la URL o nombre UNC donde los clientes irán a buscar los .OSD y los iconos de la aplicación. El OSD hace las veces de una especie de .vmc que vale para que el cliente sea capaz de localizar el paquete (que equivaldría al vhd) que habremos dejado en la carpeta “Content” mencionada más arriba. Es bastante frecuente usar la misma carpeta para todo y compartir sencillamente el path mencionado en el punto anterior. En nuestro caso compartiríamos D:\App-V-Content y pondríamos \\server\App-V-Content en “System Options”.
Con esto queda el servidor operativo, pero no será funcional hasta que no instalemos la parte cliente, y sobre todo hasta que no virtualizemos aplicaciones y las publiquemos en la consola para su consumo por los usuarios en función de su pertenencia grupos de Directorio Activo.
Vamos a dejarlo aquí y seguimos en otro rato.
El grupo de producto ha hecho publicas las novedades de SCVMM 2008 R2 RC, además de la obviedad de que será la que controle la RC de 2008 R2. La disponibilidad de esta Release Candidate se anunciará próximamente, porque el desarrollo de este producto va lógicamente desfasado entre uno y dos meses con respecto al de Hyper-V.
http://blogs.technet.com/scvmm/archive/2009/05/11/scvmm-r2-rc-features.aspx
A modo de resumen rápido:
Mientras todo esto llega, sigo exprimiendo los Remote Desktop Services y su bróker, Windows Virtual PC y App-V. Cuando se sigan acumulando los anuncios de Hyper-V R2 que hasta ahora no he podido contar (o no me he enterado) provenientes del TechEd USA ya los iré resumiendo aquí.
Con este abro una serie de posts dedicados al tema de la virtualización del escritorio, en el que explicaré cual es la foto final que se pretende alcanzar. En los sucesivos daré información más detallada de cada una de las piezas que conforman el escenario.
Antes de nada, aclarar el título. Como ya expliqué en este otro post, es frecuente confundir la virtualización del escritorio con lo que hoy conocemos como VDI. Como decía entonces, existen mas posibilidades que la mera creación de una máquina virtual en el Datacenter para lograr que un usuario tenga sus aplicaciones o todo su “botón de inicio” en un lugar diferente al dispositivo físico que tiene en sus manos.
En este escenario vamos a combinar tres tecnologías diferentes:
Por ahora, dejaremos fuera la posibilidad de virtualizar clientes (o incluso servidores) en el propio equipo cliente, si bien esto abre nuevas posibilidades. Esto lo haríamos con Windows Virtual PC y/o Microsoft Enterprise Desktop Virtualization (MED-V).
El escenario sería este:
Los clientes físicos, portátiles, sobremesas o thin-clients, reciben algunas aplicaciones virtualizadas con App-V, y las ejecutan junto con las que pudieran estar ya instaladas físicamente. En este caso la ejecución es local, si bien las aplicaciones virtualizadas viven en su propia burbuja, sin “manchar” el Sistema Operativo base y sin “pelearse” unas con otras. Podemos llegar a tener ejecutándose simultáneamente diferentes versiones de la misma aplicación.
Estos los usuarios trabajando en estos clientes pueden necesitar en un momento dado ejecutar una aplicación específica que no este presente en su equipo, o incluso tener que conectarse a otro escritorio donde se ejecuta un entorno de aplicaciones específicas. Para lo primero puede acceder a una “Remote App” publicada en un servidor de terminales y para lo segundo puede, o abrir una sesión contra un servidor de terminales, o bien conectarse a una máquina virtual corriendo un sistema operativo cliente.
En este caso, los RD Web Access ofrecen un portal donde el usuario puede elegir lo que quiere hacer. Lanzar una aplicación remota, conectarse a un terminal server, conectarse a su máquina virtual personal (no dibujada), o conectarse a una máquina virtual de un pool de ellas configuradas de forma idéntica. Una vez hecha a difícil selección, será el Connection Broker quien se encargue de redirigir esa petición a buen puerto, en función del usuario y el destino. En ultima instancia, será el cliente el que hablará directamente con el destino asignado, y puede hacerlo de manera segura a través de un Gateway (no dibujado) en caso de que se encuentre en una localización remota.
El servidor de App-V se encarga de mandar las aplicaciones virtualizadas mediante streaming a los clientes físicos, a los servidores de terminal y a las máquinas virtuales, yéndose estas a sumar a las que pudieran estar instaladas directamente sobre el sistema operativo. He de decir que App-V soporta otros métodos de distribución de las aplicaciones, pero no quiero complicar esto mucho más de la necesario.
Tenemos por tanto:
Reiterando que me dejo fuera Windows Virtual PC y MED-V, solo hace falta aplicar un poco de combinatoria para darnos cuenta de lo rico que es todo esto, y de lo complicado que puede ser atinar con una estrategia de virtualización del escritorio adecuada. No conozco ninguna empresa que pueda presumir de haberse quedado única y exclusivamente con una de las combinaciones. Generalmente hay que analizar casuísticas en función de tipología de usuarios, aplicaciones que deben utilizar, datos que deben manejar y localizaciones en las que tienen que trabajar. Todo esto sumado a la infraestructura necesaria y al coste de la misma.
Llevo toda la semana montando dos escenarios que enseñan todo esto. Yo mismo me he sorprendido de haberlo podido montar todo en un único portátil. ¡Y me sobran 3-4 Gb de RAM para meter más cosas!:
Utilizo un portátil de 8 GB de RAM con Windows Server 2008 R2 con Hyper-V como estación de trabajo. Como siempre, uno de los principales trucos para mejorar el rendimiento de una solución de virtualización pasa por repartir bien el IO. Uso el disco interno para correr una VM que contiene el DC y el Bróker y tengo un par de discos USB externos conde corro las máquinas virtuales del pool y el servidor de terminal. Este contiene además tanto la parte cliente como servidora de App-V, consumiendo las propias aplicaciones que publica y sirviéndolas por Remote App. Hace además las veces de máquina virtual personal del administrador.
Todo esto puede y debe escalar mucho más. He pasado algunas horas esta semana montando todo sobre una infraestructura con un par de clústeres y algún que otro servidor más por debajo. Y he contemplado mi primera Geo-LiveMigration entre dos cabinas que replican alguna de sus LUNs de manera síncrona. La semana que viene tengo que repetir la instalación en otro entorno en la oficina. Si alguien se anima…
Tengo pendiente montar System Center Operations Manager 2007 R2 y System Center Virtual Machine Manager 2008 R2 RC en cuanto estén disponibles para enriquecer todo lo anterior con gestión / monitorización avanzada del entorno.
Sin embargo todo lo que os he contado hoy está incluido en Windows.
Ya se han hecho públicas las descargas de las Release Candidates de Windows 7, Windows Server 2008 R2, Hyper-V Server R2, Windows Virtual PC y Windows XP Mode.
Estos son los enlaces principales para lanzar las descargas. Algunos requieren pasar por el clásico proceso de registro, a cambio del cual se facilitan los Product Keys:
Corriendo el riesgo de no ser muy original en la temática escogida, vamos a dedicar este post a ver algunas de las funcionalidades del nuevo Virtual PC, al que parece que habíamos enterrado antes de tiempo. Últimamente, la evolución de Kidaro hacia MED-V ponía de manifiesto la necesidad de evolucionar el motor de virtualización en el lado cliente, pero su inclusión como una funcionalidad de Windows 7 es algo que se ha sabido hace poco, incluso internamente.
Windows Virtual PC aparece en los últimos días íntimamente relacionado a “Windows XP Mode”, que en resumidas cuentas consiste en una máquina virtual preconfigurada con un Windows XP SP3. Lo que hace especial a esa máquina es que será directamente descargable por el usuario que haya adquirido las versiones de Windows 7 que dan derecho a ello, y que gracias a las nuevas funcionalidades de Windows Virtual PC, permite ejecutar en ella las aplicaciones incompatibles con Windows 7 pero con sus ventanas integradas en el escritorio del usuario. Por supuesto, podremos también usar la tradicional ventana que nos muestre todo el escritorio de la máquina virtual con sus aplicaciones corriendo.
Como digo, esta funcionalidad no es propia de la imagen ya preconfigurada, sino que se puede hacer lo mismo con cualquier VM con Windows XP SP3, Windows Vista SP1 o Windows 7. Basta con crear la VM e instalar el sistema operativo, instalar los nuevos Componentes de Integración y hacer algunos ajustes. Todos los detalles están aquí:
Tras haber estado con Fernando parte de la mañana trasteando, os dejo algunos trucos para ahorrar tiempo:
Lo del soporte de USB parece que puede llegar bastante lejos. Estoy probando lo más friki que se me ha ocurrido, y ya os contaré. Anticipándome a la pregunta, Windows Virtual PC soporta USB pero no VMs x64. Justo al contrario que Hyper-V, que no soporta USB, pero si VMs x64. A ver si un día los de los grupos de producto salen a cenar y se obra el milagro.
Lo de las ventanas, opciones y menús en español es obra del Language Pack. Por ahora mi decisión es usar Windows 7 x64 y Office 2007 en ingles y usar los paquetes de idioma en castellano, lo que da la opción de cambiar la interfaz de idioma cuando así se desee.
Tras haber terminado de descargar los ISOs de TechNet , ayer domingo me puse manos a la obra a probar cosas en los dos portátiles corporativos. Esto es lo que ha dado tiempo a hacer hasta ahora.
¡Ah! y también he presentado la declaración de hacienda, que hoy se abre la veda. Esto del DNI electrónico, los certificados de la FNMT y demás virguerías digitales facilitan mucho la vida. El resto de la tarde toca reconfigurar el portátil de trabajo con el resto de aplicaciones necesarias para el día a día.