Hola
El asunto del NIC Teaming en Hyper-V es un tema recurrente. ¿Como se monta y configura?. ¿Cuando esta o no recomendado?. ¿Esta soportado por Microsoft?.
Por qué necesitamos el Teaming
Estas son las razones por las que se suele plantear la necesidad de establecer Teams de tarjetas de red:
En los documentos que se enlazan más abajo encontrareis descripciones mucho más puristas de todo esto. Simplemente se trata de dejar claro que el Teaming es una pieza que puede ser un requisito fundamental en muchos escenarios.
Soportabilidad
La soportabilidad del NIC Teaming por parte de Microsoft esta muy bien resumida en estos dos artículos
Since Network Adapter Teaming is only provided by Hardware Vendors, Microsoft does not provide any support for this technology thru Microsoft Product Support Services. As a result, Microsoft may ask that you temporarily disable or remove Network Adapter Teaming software when troubleshooting issues where the teaming software is suspect. If the problem is resolved by the removal of Network Adapter Teaming software, then further assistance must be obtained thru the Hardware Vendor.
Me he permitido subrayar las partes más relevantes. La pila de red de Windows no implementa los mecanismos de agregación de ancho de banda y tolerancia a fallos mencionadas más arriba, y como veremos más adelante, es necesario utilizar el software especifico del fabricante de la tarjeta o de los propios servidores para introducirlos por encima de los drives de las tarjetas de red. Por tanto, Microsoft no puede hacerse responsable en primera instancia del proceso de diagnostico y resolución de problemas que pudieran localizarse en esta capa de software. Estaríamos exactamente en la misma situación si habláramos de los propios drivers de las NICs, o de los drivers y software de configuración de las tarjetas gráficas, o cualquier otra pieza de software que resulte ajeno a Microsoft. Como ya hemos explicado en otras ocasiones, para Microsoft “soportado” significa exactamente que puedes llamar a Microsoft Product Support Services y esperar un compromiso de alcanzar una solución sobre un asunto determinado. En este sentido, “no soportado” no significa en absoluto ni que no funcione, ni que no se recomiende, ni que se vaya a negar la ayuda, ni que el fabricante en particular no lo soporte oficialmente por su lado.
Dejémoslo por tanto en que el Teaming está soportado para Windows y por tanto para Hyper-V, pero no directamente por Microsoft PSS.
Configuración
En Hyper-V, la pila de red y la pila de almacenamiento se configuran en la partición padre. Por tanto, la configuración del Teaming de red, al igual que el multipath en el caso del almacenamiento, se gestionan exactamente igual que en un servidor físico. En la grandísima mayoría de las situaciones nos encontraremos con NICs basadas en chipset de Intel o Broadcom. Con la salvedad de HP, que implementa su propia herramienta de creación y gestión de los teams, la mayoría del resto de fabricantes se basan en las herramientas que proveen directamente los propios fabricantes del chipset.
Aquí os dejo los principales enlaces para instalar y configurar los Teams:
Cuando tiene sentido el Teaming en entornos de Hyper-V
Nos plantearemos el uso de NIC Teaming en Hyper-V en aquellas redes en las que no se implementen ya mecanismos de tolerancia a fallos por otra vía y en las que podamos necesitar agregar ancho de banda o implementar políticas de balanceo, en función de lo que hemos mencionado más arriba.
En el siguiente documento tenéis la recomendación oficial para hosts con cuatro o menos interfaces de red.
Sin embargo, los escenarios pueden complicarse si necesitamos dedicar ciertas NICs a dar servicio en determinadas VLANs. El software de Teaming puede crear NICs virtuales sobre las interfaces físicas reales, las cuales a su vez pueden convertirse en Switches virtuales, pudiéndose sacar además vNICs virtuales para la partición padre. Todo esto es factible y funciona. Pero conviene sentarse a pensar si realmente tiene sentido, y recordar que lo sencillo funciona y se opera mejor que lo complicado.
Saludos
David Cervigón
El diseño del almacenamiento para soluciones de virtualización es un tema ciertamente importante, y muy a menudo recibimos consultas acerca de cómo llevar a cabo el diseño de los “datastores” que albergarán máquinas virtuales, y en particular sobre los Cluster Shared Volumes. Tratamos el tema del funcionamiento y otras consideraciones de los CSVs en este post:
y esta es una buena guía al respecto:
Recapitulando algunos puntos de estos artículos, y añadiendo algunos otros:
Límites
Rendimiento
¿Cuales son los parámetros que pueden afectar al rendimiento de un CSV?. Pues básicamente los mismos que afectan a cualquier volumen que usemos para almacenar datos, sea DAS, NAS o SAN, pero con la peculiaridad adicional de que cada una de las máquinas virtuales almacenadas en el mismo contribuirá con su propio patrón de IO. Este problema no es en realidad específico de los CSVs, sino de cualquier otro volumen que almacene varias máquinas virtuales. Sin embargo, en el caso de los CSVs, serán varios hosts los que estarán generando carga de trabajo sobre el sistema de almacenamiento subyacente de manera simultánea.
Resumiendo, estas son cosas que afectan al rendimiento de un CSV.
http://msdn.microsoft.com/en-us/library/cc767961.aspx Choosing a cluster size. Choose a volume's cluster size based on the average type and size of file that the volume will store. Ideally, the volume cluster size is evenly divisible by the average file size (rounded to the nearest kilobyte). This ideal cluster size minimizes disk I/O transaction overhead and wasted disk space. For example, suppose you're creating a new NTFS volume that will store several files of about 6KB each in size. Format the volume with a 2KB cluster size, because the average file will fit evenly into three clusters. What if the average file size is about 16KB? In that case, a 4KB cluster size will provide the best performance, because it's evenly divisible into 16KB and requires only half the cluster allocations that the same file would require using 2KB clusters. Why not take this process one step further and use an 8KB or 16KB cluster size? These values are valid alternatives and might yield additional performance benefits; however, using cluster sizes greater than 4KB has several potentially negative side effects. For example, when you use cluster sizes larger than 4KB, disk-defragmentation utilities can't defragment the volume, you can't use NTFS file compression on the volume, and the amount of wasted disk space increases because user data files stored on the volume don't end evenly on cluster boundaries.
http://msdn.microsoft.com/en-us/library/cc767961.aspx
Choosing a cluster size. Choose a volume's cluster size based on the average type and size of file that the volume will store. Ideally, the volume cluster size is evenly divisible by the average file size (rounded to the nearest kilobyte). This ideal cluster size minimizes disk I/O transaction overhead and wasted disk space. For example, suppose you're creating a new NTFS volume that will store several files of about 6KB each in size. Format the volume with a 2KB cluster size, because the average file will fit evenly into three clusters. What if the average file size is about 16KB? In that case, a 4KB cluster size will provide the best performance, because it's evenly divisible into 16KB and requires only half the cluster allocations that the same file would require using 2KB clusters. Why not take this process one step further and use an 8KB or 16KB cluster size? These values are valid alternatives and might yield additional performance benefits; however, using cluster sizes greater than 4KB has several potentially negative side effects. For example, when you use cluster sizes larger than 4KB, disk-defragmentation utilities can't defragment the volume, you can't use NTFS file compression on the volume, and the amount of wasted disk space increases because user data files stored on the volume don't end evenly on cluster boundaries.
Como regla general, debemos de pensar que la controladora del host va a leer o escribir los datos en el sistema de almacenamiento en bloques iguales al tamaño del Stripe Size subyacente, independientemente de lo que ocupe el dato. Por otro lado, en entornos virtualizados, con los tipos de datos que manejamos hoy en día, y en virtud del párrafo anterior, parece que tiene sentido formatear nuestros datastores y discos virtuales de datos con tamaños de bloque grandes. Por defecto, un volumen normal del orden de decenas de GB se formatea a 4KB en lugar de a 64K, que es el máximo en NTFS a fecha de hoy.
¿Cuantos CSVs por cluster, y cuantas VMs por CSV?
Pues a la vista de todo lo anterior solo cabe una respuesta. Depende. Personalmente, creo que la respuesta acertada pasa por la estandarización, que nos obliga por necesidad a conocer y manejar los parámetros mencionados anteriormente. Esto, obviamente, deja la libertad de diseñar algo “ad-hoc” si la una solución específica lo requiere.
Una vez establecido este catálogo, iremos presentando CSVs al cluster y llenándolos de máquinas virtuales bajo demanda. De esta forma lograremos trabajar con el almacenamiento de la manera más predecible y ordenada posible. Por ejemplo:
Por supuesto, hay otra manera de abordar el problema. Te dan una LUN de un cierto tamaño, conviertes el volumen en CSV y lo vas llenando hasta que reviente. Si usas discos de crecimiento dinámico, ten por seguro que te enterarás de cuando sucede eso, porque todas las VMs que tengan discos en ese CSV se habrán quedado en estado pausado. No hay problema, porque los CSVs se pueden agrandar en caliente, y siempre puedes hacerlo crecer (ampliando la LUN en la cabina, te vas al nodo que es el owner del CSV y extiendes el volumen con el Disk manager o Diskpart). Pero llegará el momento en que dará miedo ver una cesta tan rebosante, pediremos crear una nueva LUN, y vuelta a empezar. Y luego resultará que “todo va lento”, entre otras calamidades.
Se acaba de anunciar la disponibilidad de la CTP de Windows Thin PC, que se puede descargar de Microsoft Connect en este enlace:
WinTPC es la evolución de Windows Fundamentals for Legacy PCs (WFLP), un beneficio para clientes con Software Assurance, y mantiene por tanto su filosofía. Es una versión muy limitada de Windows, que consume por tanto muy pocos recursos, y cuyo propósito es ser utilizado principalmente para conectarse a escritorios remotos basados en Remote Desktop Services o VDI. Si bien WFLP estaba basado en Windows XP, el principal cambio que se introduce en WinTPC es que está basado en Windows 7 Embedded Standard SP1, que es, precisamente, lo mismo que utilizarán los OEM para maquetar los Thin Clients basados en Windows que sacan al mercado. Obviamente esto incluye las novedades a nivel de protocolo incluidas en el SP1, es decir, RemoteFX, que podremos completar instalando los protocolos de nuestro principales partners en esta área, Citrix y Quest.
Desde el punto de vista del licenciamiento, WinTP tiene una gran ventaja. Al ser un beneficio de Software Assurance, no es necesario adquirir la licencia VDA, ya que esta también va incluida como beneficio del mismo. Recordemos que la licencia VDA es necesaria para cualquier dispositivo que no este cubierto con SA para acceder a una infraestructura de VDI basada en Windows.
El proceso de instalación está a medio camino entre lo que publique en este post (Virtualización Recreativa) y el de un Windows 7 “normal”. En las guías que os podéis descargar en Connect habla también de los componentes que incluye y como se puede automatizar el despliegue mediante el ya tradicional proceso generación de imágenes personalizadas de Windows mediante WAIK y MDT.
Asi es la instalación manual, en un equipo con 4 GB de disco y 512 MB de RAM (y nos sobra):
Dos reinicios:
Creación de cuenta local y configuración inicial:
El resultado:
Una vez llegados a este punto, solo nos queda definir personalización adicional y qué piezas adicionales de software necesitamos instalar para obtener una plataforma mínima sobre la que trabajar.
En este posts trataremos las principales novedades de Virtual Machine Manager 2012, con la cautela de estar hablando de una versión Beta para evaluación. La mejor lista oficial que he podido localizar es la que encontraréis en el apartado correspondiente del SCVMM 2012 TechCenter:
VMM 2012 se posiciona como una de las principales herramientas de gestión del IaaS (Infraestructura como Servicio) o de la nube privada. Para ello se han reforzado algunos puntos que hasta hoy no estaban integrados de manera nativa en SCVMM 2008 R2.
Gestión del Fabric
Entendemos por Fabric (tejido) el conjunto de elementos que necesita una infraestructura de IT para funcionar. Esto comprende principalmente hosts, hypervisores, red y almacenamiento. Este pantallazo nos permite hacernos una idea de qué elementos se consideran y gestionan dentro de SCVMM 2012 como parte de ese “Fabric” general:
Es decir:
http://www.hyper-v.nu/blogs/hans/?p=673
Seguridad
El repositorio primario de seguridad de SCVMM continua siendo como es natural el Directorio Activo. Sin embargo, para gestionar aspectos que suelen quedar fuera del mismo como puedan ser la red, los hosts y el almacenamiento, SCVMM 2012 hereda la idea de las “Run as Accounts” y “Run as Profiles” que podemos encontrar por ejemplo en Operations Manager.
Nubes, Máquinas Virtuales y Servicios
Una de las cosas más sorprendentes que incluye SCVMM 2012 es su integración con Server App-V (documentación descargable aquí). Tal y como sucede con App-V en los clientes y servidores de Remote Desktop, la idea es desacoplar las aplicaciones de servidor del sistema operativo para poderlas desplegar de manera independiente.
Simplificando mucho (para mucha más información: Deploying Virtual Machines and Services in a Private Cloud in VMM 2012):
El papel de la Librería
En SCVMM 2012 la librería tienen un papel aún más relevante, y como sucede en la versión actual, se compone de una serie de carpetas de red y de la información que se almacena en la propia base de datos. En un golpe de vista se observa todo lo que podemos almacenar aquí para que lo podamos combinar a voluntad a la hora de crear nuestras VMs, Servicios y Clouds:
Y en particular, en la parte de Application Frameworks, encontraremos los binarios necesarios para utilizar Server App-V:
¿Y el portal de autoservicio?
Por ahora, no ha sufrido apenas cambios con respecto al existente en SCVMM 2008 R2 SP1. Sin embargo cabe esperar que las funcionalidades del SSP 2.0, desarrollado como un “Solution Accelerator” y no como parte del propio producto, se integren con todo lo mencionado anteriormente.
Para cerrar, recordaros que todo lo que sabemos por ahora está documentado aquí:
Durante la semana pasada se celebró en Las Vegas la Microsoft Management Summit 2011, un evento anual centrado en las tecnologías de gestión. Durante el mismo se anunciaron las fechas de la próxima ola de productos de System Center, la disponibilidad de algunas Betas, y en particular la de System Center Virtual Machine Manager 2012, que ya se puede descargar desde aquí:
Podéis leer aquí el resto de anuncios que se realizaron durante el evento:
Vamos a ver el proceso de instalación de SCVMM 2012. Antes de nada, como de costumbre, toda la información técnica relevante a prerrequisitos, instalación, configuración y uso la tenéis disponible en el TechCenter correspondiente en Microsoft TechNet:
Al menos en la beta, los prerrequisitos han cambiado con respecto a SCVMM 2008 R2:
Tras descargar y descomprimir el fichero de descarga, lanzamos la instalación.
Tras el acuerdo de licencia, podemos elegir los componentes que queremos instalar. El propio servidor, la consola (obligatoria en el servidor) y el portal de autoservicio
Además de los prerrequisitos arriba mencionados, se nos piden al menos 4 GB de RAM
La instancia de SQL donde crear la base de datos
Los puertos que se utilizarán por defecto son configurables, lo que nos viene bien para controlar las comunicaciones en los firewalls
La parte correspondiente al portal de autoservicio. Podríamos usar un equipo remoto con IIS:
Creamos la primera carpeta compartida para la librería y finalizamos la instalación, que no debería llevar más allá de unos minutos:
Y ya tenemos un servidor con VMM 2012 Beta listo para ser utilizado:
En un primer golpe de vista, además de los cambios en la interfaz, vemos algunas cosas diferentes a lo que tenemos hoy en la consola de VMM 2008 R2. Servicios, Nubes, Fabrics…
Pronto más.
Otro poster de arquitectura reciente, en esta ocasión relativo a los Remote Desktop Services de Windows server 2008 R2 SP1
Se ha incluido un apartado dedicado a RemoteFX, que es la novedad introducida en SP1
Se puede descargar de aquí:
El otro día lo mencionaba Tomás en un comentario del post sobre Guías de implementación de Hyper-V y Arquitecturas de Referencia. No había tenido tiempo de descargarlo e ir ampliando las diferentes zonas para ver en detalle. La verdad es que esta muy bien para discusiones de pizarra, o para ilustrar presentaciones.
Según las propiedades del fichero tiene aproximadamente 1 m de ancho por 64 cm de alto, así es que la captura de pantalla vale de poco salvo para adornar.
Lo podéis descargar de aquí:
Como suele ser habitual, unas semanas después de anunciarse un Service Pack que afecta a funcionalidades de Hyper-V como es el caso del SP1 de Windows Server 2008 R2 y Windows 7, ya tenemos disponible para descarga la versión de Virtual Machine Manager que contempla los cambios introducidos, en este caso la Memoria Dinámica y RemoteFX, además de las actualizaciones que han ido apareciendo meses atrás.
Esta disponible en TechNet/MSDN y en la web para clientes con licenciamiento por volumen.
Además también podemos descargar la versión de evaluación desde aquí:
La actualización de una infraestructura de virtualización que esté siendo gestionada por System Center Virtual Machine Manager 2008 R2 a esta versión con el SP1 ya integrado no puede resultar más sencilla. Basta con lanzar el ejecutable de instalación allí donde tengamos instalados uno o varios componentes de SCVMM 2008 R2. El proceso los detectará y los actualizará automáticamente. Posteriormente observaremos que todos los hosts gestionados aparecen en la consola en estado de alerta, y tendremos habilitada la posibilidad de actualizarles el agente de manera remota y centralizada.
También ha sido actualizada la información del TechCenter dedicado a SCVMM, que podéis encontrar aquí:
He estado recopilando una serie de guías de implementación de Hyper-V tanto de Microsoft como de algunos fabricantes que ofrecen arquitecturas de referencia de sus sistemas para las tecnologías de virtualización de Microsoft. Obviamente no es la lista completa, y sobre todo la parte de almacenamiento se queda corta y la trataremos más adelante. Muchas de ellas están solamente a algunos clics de http://www.microsoft.com/virtualization/en/us/private-cloud.aspx