Hola
Ya está disponible la Release Candidate de Windows 7 y Windows Server 2008 R2 para subscriptores de TechNet y MSDN:
Vamos a amortizar esta tarde-noche la ADSL, y este fin de semana y toda la que viene tocará ponerse instalar/actualizar para probar novedades y montar escenarios de demo. Sin olvidarse de la máquina de trabajo, que será seguramente la primera.
La RC0 de Windows Server 2008 se anunció el 25/9/2007. La RTM el 4/2/2008, es decir, aproximadamente cuatro meses después. Esto no quiere decir nada, pero puede valer para hacernos una idea.
Saludos
David Cervigón
Continuando con las nubes, y tras que se haya anunciado hoy entre otras cosas la oferta de Microsoft para las nubes públicas y privadas en la Microsoft Management Summit de Las Vegas, me animo con este post que llevaba un tiempo pendiente de ver la luz. Lo cierto es que el título fue lo primero que se me ocurrió, aunque ahora me parece un poco bastante pretencioso. Pero es que si no, no rima :-).
Se trata de ver diferentes opciones para montar la infraestructura de virtualización sobre la que construiremos nuestros servicios, sobre todo en lo tocante a la monitorización y a la gestión de identidades. Resumiendo, qué opciones tenemos a lo hora de diseñar nuestro Directorio Activo de cara a albergar los servidores con Hyper-V y toda su gestión. Lógicamente esto son solo ideas, y adaptarlas a la realidad puede tener su complejidad.
Antes de seguir es importante tener una cosa en cuenta. Considerando a Hyper-V como mera capa de software con tareas de Hypervisor, es de cajón que no puede pertenecer a un dominio. Sin embargo, la partición padre de la que proviene, el Windows Server 2008 o Hyper-V Server en la que hemos activado Hyper-V como role y donde residen componentes claves de la pila de virtualización como red, almacenamiento, drivers y componentes de administración, puede ser un servidor miembro de un dominio o un servidor stand-alone (workgroup). Su pertenencia a un dominio es condición necesaria para el uso de ciertas funcionalidades avanzadas, como el host clustering que nos permite HA, Quick Migration y Live Migration, y es ciertamente conveniente si queremos hacer uso de una gestión de identidades, configuración y administración medianamente consistentes y unificadas.
MiNube.Local – El forest de Hyper-V
En primer lugar, vamos a ver el caso que mejor pone de manifiesto el concepto de nube. Una infraestructura totalmente independiente que contiene única y exclusivamente los servidores de Hyper-V y lo necesario para gestionarla:
Como puede observarse, tenemos la imprescindible capa de almacenamiento en la que se apoyan todos los servidores de virtualización. Los grupos de 16 hosts vienen a representar clústeres de 16 nodos, el máximo soportado a fecha de hoy en Windows server 2008 x64. ¿Deben de ser todos los servidores miembros de un cluster y dotar a la máquinas virtuales de HA y capacidades de migración?. Definitivamente no. Seguramente alberguemos entornos de pruebas y desarrollo en los que no necesitemos esas capacidades, o incluso sistemas en producción que ya implementes sus propios mecanismos de tolerancia a fallos y escalabilidad horizontal. Por ejemplo, una granja de frontales web trabajando en balanceo de carga (NLB o balanceadores hardware) es posible que no lo precise. Otro ejemplo es el guest clustering de Exchange CCR. Directamente en este entorno no se soporta que los nodos del cluster virtuales sean máquinas virtuales HA en un host cluster.
Lo segundo destacable de la figura es que la pila de gestión y los controladores de dominio de MiNube.Local son físicos. Aunque cuanto mayor sea el número de hosts y el número de DCs los potenciales problemas tienden a minimizarse, no es una mala idea reservarse algún DC físico. No se va a necesitar además responder a un gran volumen de cambios o autenticaciones en este sentido. Los servidores de gestión no se montan sobre la propia infraestructura a la que se supone que van a monitorizar por la misma razón por la que un huevo de la cesta no debe ser el encargado de vigilar si la cesta se cae o no.
Sin embargo es posible también crear una mini-nube dentro de la nube orientada únicamente a albergar los servicios de directorio, gestión y monitorización, aparte de los que albergaran el resto de los servicios:
Sobre esta base implantaremos soluciones completamente virtualizadas. A imagen y semejanza de lo que se lleva haciendo mucho tiempo en hosting y housing, no tenemos ningún tipo de dependencia con la infraestructura de virtualización. Hay podemos albergar el/los dominios internos de nuestra empresa, los frontales de nuestros dominios externos, o incluso hospedar soluciones de empresas asociadas, o interesadas en subcontratar/externalizar servicios en nuestra infraestructura.
Como haríamos en un entorno físico, siempre existe la posibilidad de plantearse el establecimiento de relaciones de confianza entre estos dominios, o establecer federaciones entre ellos. Esto puede resultar de utilidad para delegar la administración, o incluso para utilizar los mismos productos de monitorización y gestión que se utilizan para la nuestra nube. En nuestro caso, los productos de la familia System Center, Virtual Machine Manager, Operations Manager y Data Protection Manager.
Nebulizando el dominio existente con Hyper-V
Este es si duda uno de los escenarios más inmediatos, y por tanto el más frecuente. Ir integrando la virtualización en lo ya existente y que seguramente tenga ya mucha historia “física” recorrida. En este caso nuestra nube interna quedará reducida a un conjunto de máquinas, seguramente agrupada en una Unidad Organizativa propia, que albergarán un subconjunto de los servidores/clientes presentes en el directorio.
Aquí esta representado un dominio único, donde tenemos controladores de dominio y servidores de gestión tanto físicos como virtuales, y los servicios se construirán igualmente sobre infraestructura física y/o virtual. Lo más normal hoy en día es encontrarse que para un mismo servicio, ciertos componentes están virtualizados y otros permanecen todavía directamente sobre el hierro.
Esta foto facilita bastante la gestión al encontrase todo bajo el mismo paraguas desde el punto de vista de gestión de la seguridad e identidades. Una de las principales bazas que juega Microsoft en el mundo de la virtualización es ofrecer un conjunto de herramientas de gestión adaptadas que permiten la administración de todo el ciclo de vida de la infraestructura de manera unificada, independientemente de si es física, virtual, o esta mezclada.
La nube como dominio de recursos
Entre la opción de montar una verdadera nube aislada lógicamente y erigirnos en hosters internos y la de simplemente poner el vaporizador en lo que ya tenemos, existe una alternativa que se ha venido utilizando tradicionalmente (¿recordáis lo dominios de cuentas y de recursos que se estudiaban en NT?). Podemos usar un dominio del forest que dedicaremos en exclusiva a Hyper-V y su gestión. Repasando conceptos, un dominio en Directorio Activo supone una frontera de seguridad y contiene su propio conjunto de objetos (equipos, usuarios, políticas, etc.), pero comparte con el resto de dominios que conforman el bosque el mismo esquema y configuración, existiendo entre ellos por defecto relaciones de confianza. Esto permite un buen aislamiento de cada uno de los dominios, sin llegar a complicar demasiado el trabajo conjunto como en el primer caso, en el que existe más estanqueidad.
En el fondo, esta opción es un caso particular de la anterior, en la que violamos el principio de mantener las cosas los más sencillas posibles (forest único, dominio único). Sin embargo todos sabemos que muchas veces existen razones para ello, y en ocasiones fuera del ámbito técnico:
Bueno, todo este rollo para llegar a la conclusión de que podemos elegir entre multiforest, multidominio o dominio único. Pues menuda novedad, y además las combinaciones expuestas pueden pecar hasta de simplistas. Pero lo importante de todo esto es que la decisión de virtualizar esta muy ligada a la creciente necesidad de poner orden en los actuales datacenters, o incluso rediseñarlos. Y ese suele ser un buen momento para plantearse este tipo de cambios, e incluso decidir que servicios pueden pasarse a la “nube pública”. Y por supuesto hablar de qué se virtualiza y qué no, clústeres o no clústeres, almacenamiento, VLANs, recuperación ante desastres y centros de respaldo, etc.
¿Como os lo estáis planteando vosotros?
Y construyó, castillos en aire a pleno sol, con nubes de algodón, en un lugar, adonde nunca nadie pudo llegar usando la razón.
Así reza una canción de Alberto Cortez que me gustaba a mi de pequeño. Y es que hay que reconocer que el tema de las nubes tiene una atracción especial. Por eso no se le pasa desapercibido a ningún equipo de marketing que se precie, y así sucede después, que nos acabamos todos preguntando a qué huelen las nubes.
El tema de la nube lleva unos meses de moda, y en las últimas semanas más ya que asistimos al presunto nacimiento del sistema operativo para la nube. Sin embargo esto es como un conjunto de niños tumbados bocarriba en el prado viendo pasar un cúmulo en una tarde de verano. A uno le parece un perrito, a otro un gatito, a otro un conejo y a otro un elefante.
No seré yo quien reniegue o ponga en duda el término “cloud computing” a estas alturas de la película, ni quien se suba al carro del análisis de “tendencias muy interesantes”. El cálculo distribuido lleva mucho tiempo entre nosotros, más o menos desde que nos libramos de la tiranía del host como unidad única de procesamiento central, y asistimos a la explosión de equipos x86 conectados a Internet. Desde entonces, todos los sistemas operativos implementan diversas maneras de llevar a cabo peticiones de procesamiento remoto, se llevan muchos años implementando arquitecturas cliente-servidor, y hay ya mucha gente a la que no le ha pasado desapercibida la oportunidad de albergar capas de software y hardware que subcontratar como servicio a potenciales clientes.
Cuando parecía que la pelea estaba en si el sistema operativo iba o no a ser un navegador (que va a ser que no), o si mis aplicaciones y mis datos serán todas albergadas por un servicio ofrecido a través de Internet (que va a ser que todas todas, tampoco) surge de repente de la nada el concepto de nube interna o nube privada como pieza fundamental del puzle.
Me da rabia que nuestros equipos de marketing hayan estado tan lentos, cuando la jugada hace ya tiempo que se veía venir. Los que hayan estado en alguna de las charlas que hemos dado en el último año habrán visto esta diapositiva como parte de la presentación. En ella se habla de la virtualización como parte de los cimientos para construir el Datacenter Dinámico. Un cliente, al que dedico el post, lo contaba de una manera muy sencilla. Su negocio no es mantener un datacenter sino otro. El quiere una fibra gorda con dos luces, una verde y una roja. Cuando la verde este encendida, paga. Cuando esté roja, cobra penalizaciones. Otro mantiene su datacenter. El se dedica a su negocio. Como nadie le puede ofrecer a fecha de hoy los servicios que él necesita en la nube, se construye su datacenter en plan nube privada. Y cuando sea posible, la virtualización le ayudará a “exportarlo”.
Otro cliente, al escuchar esto, decía que es un concepto muy bonito, pero que hay que aterrizarlo. Y desde luego, no le faltaba razón. Cualquiera que haya puesto un pié en un datacenter mediano tirando a grande habrá podido comprobar la gran variedad que existe en todo, desde la ferretería hasta los servicios que se ofrecen, pasando por supuesto por los sistemas operativos y el software que corre en ellos.
De cara a materializar la utopía de nuestro cliente, la virtualización juega un papel importante. Lograr la mayor independencia posible de la ferretería. Sin embargo, pensar en que esto es el único requerimiento para lograr algo de este estilo es peligrosamente simplista. Los productos utilizados deben acompañar a la arquitectura de la solución, debe se seguirse un modelo y todo debe ser gestionable de manera adecuada. Mucha gente, sino toda, se esta planteando dar pasos en este sentido. Virtualizar o no ya casi no es una elección. Pero hay muchas, muchas más cosas que se pueden contemplar.
Volviendo al papel del sistema operativo en todo esto, pasamos de escuchar hablar del sistema operativo para el datacenter virtualizado a el sistema operativo para la nube interna. Brillante maniobra de marketing, supongo que cuidadosamente calculada. Es la primera vez que alguien tiene redaños para ponerse voluntariamente en contra de todos los sistemas operativos de datacenter, Windows Server, los Unix propietarios, los Linux comerciales y los demás Linux, que incluyen todos su sabor de Hypervisor, y de paso hacer que te miren de reojo los jugadores de “la otra nube” es decir, los Google, Amazon, Yahoo… y, como no, Microsoft.
Hablando de esta otra “nube pública”, hace algunos meses que publique un enlace a un vídeo acerca de cómo Microsoft construye los datacenters que albergan sus servicios en la nube. Windows Live, Azure, Microsoft Business Productivity Online Services, y lo que esté por venir. Nuevamente, esto tampoco es nuevo. El Hosting y Housing y la externalización de servicios no es algo que se inventara ayer, precisamente. Pero me resulta complicado pensar en que alguien monte una infraestructura de este calibre, bien sin desarrollar su propia tecnología, bien sin usar alguna que no le suponga un coste adicional. Y es que un Sistema Operativo hace más, mucho más que solo virtualizar. Creo honestamente que en este terreno estamos ante una continuación de la eterna guerra Linux-Windows.
Estoy por apostar que no basta con tener una buena oferta para la “nube pública” o una buena oferta para la “nube privada”. Creo que se va a tratar de tener ambas ofertas y además una buena conexión entre nubes. Como de costumbre, puede que en Microsoft no lleguemos los primeros a ninguna de ellas, pero si tal vez a ambas a la vez. Y esta por ver como todo esto afectará a Windows, y Windows a todo esto.
Acaba aquí la historia del idiota que por el aire, como el aire libre, quiso volar igual que las gaviotas..., pero eso es imposible..., ¿o no?... Alberto Cortez
Acaba aquí la historia del idiota que por el aire, como el aire libre, quiso volar igual que las gaviotas..., pero eso es imposible..., ¿o no?...
Alberto Cortez
P.D: Todo esto viene a santo de que tenía dos posts a medio escribir (“Arquitecturas para la nube” y “Conectando nubes”) y si no iban a parecer oportunistas :-)
Como continuación del post en el que hablaba sobre clústeres de Hyper-V (host clustering) y clústeres virtuales (guest clustering), aquí van un par de diagramas de como quedaría una solución con “guest clustering” sobre un host clustering, que, salvo por aspectos puntuales, es válido para cualquier plataforma de virtualización. Si lo quieres reutilizar y te viene bien el Visio original, no dudes en contactar conmigo.
A modo de resumen de aquel post, las controladoras SCSI virtuales que introduce Hyper-V en la máquinas virtuales no nos sirven para montar un bus de almacenamiento compartido apropiado para clustering, ni para Windows Server 2003 ni para Windows server 2008, por lo que cualquier intento de usar VHDs o discos Pass-Through conectados simultáneamente a cualquier controladora virtual de una VM montada en Hyper-V será en vano. Decíamos también que tanto Virtual Server 2005 como diversos productos de vmware emulan en las máquinas virtuales unas controladoras SCSI que si son válidas para formar clústeres de Windows Server 2003, pero que en el caso de Windows Server 2008 solo se soporta Fiber Channel , iSCSI o SAS como bus compartido para un Failover Cluster, con lo que en este caso tampoco nos vale la clásica estrategia. En resumidas cuentas, que el futuro del “guest clustering” con sistemas operativos Microsoft pasa por el uso de iSCSI.
Esto plantea una ventaja y un inconveniente. La ventaja es que el almacenamiento se le presenta a las máquinas virtuales que conforman los nodos del cluster directamente sin pasar por los host de virtualización. La desventaja es que no todo el mundo dispone de almacenamiento que sea capaz de utilizar iSCSI, si bien esto parece que es una tendencia que va a más, a medida de que nos vamos dando cuenta de que habíamos descartado las capacidades del cobre antes de tiempo. Luego volveré sobre este punto.
Este es el esquema de una solución basada en tres hosts que conforman un cluster, sobre el que se albergan un cierto número de servidores virtuales, dos de los cuales forman un cluster virtual:
Como se puede observar, los hosts están conectados a la SAN a través de diferentes fabrics de fibra y ethernet, a la que se conectan a través de sus HBAs y NICs (dedicadas). Desde las cabina se presentan un cierto numero de LUNs a los nodos. Las que serán específicas de cada nodo se presentan individualmente, y las que se usarán como almacenamiento compartido del cluster se las presentamos a todos. En estas últimas almacenaremos los VHDs de nuestras máquinas virtuales, aunque alguna puede incluso tener asociada su propia LUN por razones diversas, o porque se vaya a usar en pass-through.
Para formar el almacenamiento compartido del cluster virtual, presentamos desde la cabina los volúmenes que vayamos a necesitar a través de iSCSI. Una vez hecho esto, configuramos los “iSCSI Initiators” del sistema operativo de la máquina virtual para que se conecte al target de la cabina y monte los volúmenes que se les han asignado. Este es el detalle de cómo queda el cluster virtual:
Los nodos virtuales en este caso se comportan exactamente igual que lo haría un cluster físico que se montara con iSCSI, y por tanto, se deben seguir las mismas recomendaciones para su configuración. Necesitaremos una par de NICs virtuales para atender a los clientes y para el heartbeat (no represento su conectividad), y es conveniente dedicar una NIC virtual para iSCSI. También sería una buena idea dedicar switches virtuales en el host para conectar a los switches físicos que nos conectan con la cabina.
Como decía, hay muchas ocasiones en las que no tenemos una cabina que “hable” iSCSI, o simplemente en las que no tenemos almacenamiento compartido. Tanto para simular entornos de producción como por mero aprendizaje, es interesante montar tanto clústeres físicos como clústeres virtuales. En ese caso, ¿como nos las apañamos?.
Existe un buen número de Targets iSCSI por software e incluso emuladores de SAN (OpenFiler, OpenNAS, FreeNAS, etc.), que se pueden montar tanto en físico como en virtual. Encontrar uno no nos garantiza el poder formar un cluster de Windows Server 2008 (aunque si 2003), porque muchos de ellos implementan un target NetBSD/FreeBSD que a fecha de hoy no soporta SCSI-3. Tampoco he probado los targets que implementan algunos *nix (SUSE, OpenSolaris, etc.)
Entre los que sé que funcionan (ejemplo 1, ejemplo 2), se encuentran:
Después de releer este ladrillo, no sé si esto será aclaratorio o si simplemente aumenta vuestro nivel de confusión. Espero que no.
Resuelve seis problemas, que están documentados en este artículo de la Knowledge Base:
La actualización está disponible directamente a través de Microsoft Update. Si necesitas realizar la descarga desde un equipo que no tenga SCVMM2008 instalado, puedes hacerlo directamente desde el catálogo de Microsoft Update (1,3MB):
Si estáis usando SCVMM2008, no deberíais prescindir de él.
Desde la época en que me tocó, con mucho gusto, ir contando las novedades de Exchange Server 2007 me he ido desconectando un poco del producto a cambio de Windows Server 2008 y el mundo de la virtualización. Pero como siempre tendré un huequecito para Exchange en mi corazoncito, creo que esto va a ir derechito a una máquina virtual:
La descarga (por ahora, unas 300 MB) esta disponible aquí:
También para suscriptores a TechNet/MSDN:
He de reconocer que las novedades de Exchange 2010 no me las se muy bien todavía, pero ya esta listo incluso su TechCenter con abundante información:
Lo que si he probado ha sido Exchange Online, ya que en mi opinión esto tiene mucho mas que ver con la virtualización, y el “Cloud Computing” que virtualizar o no Exchange en tu datacenter. Pero esta es otra historia.
Hay algunos realmente chulos
Y otros que no usan la tecla Windows pero que también pueden ser útiles.
Este es un compendio de lo que esta disponible a fecha de hoy:
Cursos:
Clinics:
Colecciones:
Exámenes:
Cursos específicos para Partners: (visibles a traves del Microsoft Partner Training and Readiness Resource Center). Los exámenes de certificación arriba mencionados serán necesarios para obtener la futura Competencia en Virtualización.
Existe abundante información acerca del impacto que tiene este tema en el rendimiento de las cargas de trabajo que hacen un uso intensivo del sistema de almacenamiento. Si indagáis un poco es frecuente encontrar datos que justifican ganancias/pérdidas de rendimiento de hasta el 30-40% por el hecho de tener las particiones alineadas o desalineadas en sistemas que usan “arrays” de discos que usen diferentes niveles de tolerancia a fallos.
Los sistemas de almacenamiento modernos son lo suficientemente complejos como para que el viejo modelos para representar a los discos basado en Cilindros, Cabezas y Sectores (CHS), o el esquema LBA para direccionar la información que almacenan, se puedan considerar una mera simplificación conceptual. Sin embargo, estos tres factores tienen especial relevancia en el fenómeno del alineamiento/desalineamiento de las particiones de un array de discos.
El alineamiento de las particiones se basa en buscar una buena combinación de los tres parámetros anteriores, de manera que una cierta operación de lectura/escritura no suponga tener que ir a buscar los datos a más de un disco de los que conforman el volumen. Si para ciertas peticiones tenemos que acabar leyendo o escribiendo en diferentes discos, la acumulación de las mismas puede conllevar una pérdida de rendimiento muy significativa. Para evitar esto, es importante que las siguientes relaciones den como resultado un número entero:
Esto se entiende muy bien con un el siguiente gráfico. En el vamos a suponer que la Stripe Size Unit es 64 KB y analizaremos cinco casos en los que usaremos diferentes Partition Offsets y tamaños de cluster. Lamentablemente no se puede pintar bien a escala, por lo que los guioncillos intermedios representan que la gráfica se “estira” por ellos. Cada sector representa 512 Bytes.
La buena noticia es que el desalineamiento es fácil de detectar, y también es fácil crear particiones alineadas. La mala es que corregir la situación a posteriori supone reparticionar y formatear de nuevo.
Comprobando si las particiones están o no alineadas
Habida cuenta de que conocemos el Stripe Set Unit que utiliza nuestro almacenamiento, el Partition Offset y el tamaño de cluster los podemos obtener así:
El comando DISKPART también muestra el Offset de las particiones, sin embargo no es de fiar, porque lo da en KB y redondea. En el primer ejemplo de la gráfica anterior nos hubiera engañado miserablemente mostrando 32 KB.
Si nos salen las cuentas, estupendo. Si no, nos espera la tediosa tarea de rehacer nuestras particiones, con lo que eso supone en lo tocante al salvaguardado de los datos y su disponibilidad durante el proceso.
Generando particiones alineadas
Una vez creada la partición, la formatearemos usando el tamaño de cluster deseado, pero recordando que la relación Stripe Unit/Allocation Unit debe dar también un entero. Sin embargo es muy improbable que esto no sea así.
Eligiendo sabiamente los valores de la Stripe Set Unit y Allocation Unit antes de ponerse manos a la obra
Desafortunadamente, aquí no podemos hablar de a existencia de una regla general. Estos valores deben ser elegidos en función de la naturaleza de la carga de trabajo, teniendo en cuenta el balance entre lecturas y escritoras, si serán secuenciales o aleatorias, en bloques de qué tamaño se escribirá/leerá la información, etc., y también de como se comportan las cachés y cada almacenamiento en particular. Por eso es muy frecuente encontrar guías específicas de cada fabricante para las cargas de trabajo más frecuentes.
Así es que antes de hacer nada “sabiamente” no nos queda otra que leernos esto para empezar:
para posteriormente bucear entre los whitepapers de los fabricantes de nuestras cabinas.
Vamos a dejarlo aquí por ahora. Supongo que los que hayáis llegado a leer hasta aquí os estaréis preguntando cómo aplica todo esto a entornos virtualizados, tanto a nivel de host como de máquina virtual. Es de cajón que las LUN donde se almacenen las VMs, o los discos pass-through es importante que estén alienados. Pero, ¿y las propias particiones de las VMs?. ¿Que tamaños de cluster y Stripe Unit Set son adecuadas?. Lo veremos en otro post.
CREDITOS:
REFERENCIAS:
Como en todos los sistemas consistentes en agentes que se comunican con un servicio/consola centralizada, SCVMM no refleja el estado del entorno en tiempo real, y ese retraso se hace más patente cuando las acciones sobre el mismo se llevan a cabo desde otras consolas, como podrían ser las MMC de Hyper-V y de Failover Cluster. Lógicamente de lo que se trata es de balancear la exactitud de la información mostrada con la carga de trabajo y el consume de ancho de banda de red que supone mantener toda esta información actualizada.
Digamos que en situaciones en las que se está montando, configurando o probando un entorno podemos llegar a considerar que los tiempos de refresco de la información mostrada son demasiado largos, y también es posible que en entornos ya en producción, estables y poco cambiantes, pueda parecer que el consumo de recursos de los servicios/agentes y el tráfico de red son demasiado altos.
Aprovechando de nuevo la información ya publicada por Cheng en su post All about refreshers ..., vamos a ver cuales son los tiempos por defecto que usa Virtual Machine Manager para refrescar la información que muestra en la consola y almacena en la base de datos, y que, por supuesto, son independientes de lo que el administrador fuerce manualmente mediante la interfaz gráfica o Cmdlets de PowerShell al llevar a cabo operaciones específicas sobre el entorno:
Por supuesto estos valores son modificables, si bien hay que considerar que los valores predeterminados mencionados arriba son los más recomendables para la mayoría de los entornos. Como decía al principio, bajar los tiempos de refresco hace que la información sea más precisa en menos tiempo a cambio de incrementar muy sensiblemente la carga de trabajo de los agentes y el servicio y el tráfico de red. Subirlos minimiza estos efectos a cambio de tardar más en mostrar el estado real de la infraestructura.
Curándome en salud y al no encontrar en ningún sitio publicadas las entradas del registro que controlan estos valores, he decidido no ser el primero en documentarlas, aunque supongo que el que aparezcan por ahí es una mera cuestión de tiempo. Si tienes buenas razones para querer cambiar al alza o a la baja estos valores por defecto, puedes contactar con mis compañeros de soporte o conmigo en privado.
En ocasiones es necesario sacar más información de qué es lo que están haciendo los componentes de SCVMM2008 en un determinado momento, sobre todo a la hora de resolver problemas imprevistos. Estas trazas son las que se suelen solicitar por parte de nuestros compañeros de soporte y de los grupos de producto para poder avanzar en la resolución del problema, y lo cierto es que, aunque un poco incómoda, es en ocasiones relativamente fácil averiguar al menos el punto en el que la cosa falla. Lo que sigue a continuación es una traducción bastante libre del post de referencia al respecto, How to collect SCVMM traces, de mi compañero Cheng Wei
Este procedimiento se puede aplicar al servicio de SCVMM, al agente, y al portal de autoservicio. Sus aplicaciones más frecuentes son desconexiones de la consola (generalmente errores 1612), que suceden como consecuencia de que el servicio se ha detenido por causa de un error inesperado, hosts que no responden o que están en estado “Needs Attention”, errores poco claros en máquinas virtuales como el “Unsupported Cluster Configuration”, etc.
Resumiendo, el procedimiento consiste en habilitar el trazado del los componentes en los servidores involucrados (VMM Server, Host Agent y/o Portal de Autoservicio), decidir que tipo de información se quiere almacenar en la traza, reiniciar los servicios y capturar la información usando Dbgview.
Para facilitar las cosas, adjunto un .zip con los ficheros necesarios para hacerlo. En el post de Cheng tenéis la información de como producir estos mismos ficheros por vosotros mismos.
Para cada servidor presuntamente involucrado en el problema hacemos los siguiente:
Una completa guía de referencia de todos los CMDLets de System Center Virtual Machine Manager:
Todas las acciones que se llevan a cabo desde la consola de System Center Virtual Machine Manager son scriptables desde Powershell. Como sucede con Exchange Server 2007, es frecuente encontrarnos con un botón “View Script” que nos muestra el conjunto de sentencias que son responsables de las tareas en las que se divide cada uno de los trabajos. Es un buen punto para empezar.
Es conveniente usar esta guía como complemento del apartado “Scripting” que encontramos en la System Center Virtual Machine Manager 2008 Library de TechNet y que cubre los siguientes puntos:
La semana pasada se publicó la Hyper-V Security Guide, que complementa la información ya publicada en la sección Planning for Hyper-V Security de TechNet. Está disponible en la página de descarga de la Guía de Seguridad de Hyper-V, y en ella se cubren tres aspectos relativos a la seguridad de entornos virtualizados con Hyper-V:
1.- El bastionado del host
Basado en la instalación de Server Core, en el que se incluyen recomendaciones a la hora de configurar la red y los permisos del almacenamiento donde vivirán los VHDs de las máquinas virtuales. En esta sección se esconden tres recursos muy útiles:
2.- Delegación de la administración
En este apartado se trata como delegar el entorno virtualizado usando dos técnicas diferentes. La primera, utilizando el Authorization Manager (AZMan.msc) para abrir el Authorization Store (InitialStore.xml) y configurar los grupos de usuarios que pertenecerán a los roles que podemos definir en base a las 33 diferentes operaciones contempladas. Una segunda parte cuenta como hacer algo similar usando System Center Virtual Machine Manager 2008, con sus roles de Administrador Delegado y Usuario de autoservicio.
Bajo mi punto de vista esta parte se queda un poco coja en dos aspectos. Primeramente, no explica cómo crear, almacenar el Authorization Store en el Directorio Activo (aquí está perfectamente explicado en ruso :-), aunque lo realmente importante alta a la vista porque está en perfecto inglés), y por otro lado no aclara que VMM crea su propia copia del almacén, al que llama HyperVAuthStore.xml. En la versión actual de SCVMM es imposible compatibilizar ambos stores. Es decir, debemos elegir entre usar uno (el local o en el AD, creado por Azman) u otro (el de VMM). Cualquier intento en modificar con AZman el correspondiente a VMM es inútil, ya que la configuración se sobrescribirá en el siguiente refresco del host.
En SCVMM2008 R2 se planea cambiar algo este comportamiento, tal y como explica aquí mi compañero Michael: Azman permissions for VMM-managed Hyper-V hosts.
3.- Securización de las Máquinas Virtuales
En esta sección se incluyen enlaces a guías de securización de los sistemas operativos que corren dentro de la VM, utilización de Bitlocker para protección adicional de los ficheros que conforman las VMs, y cómo auditar el acceso que se lleva a cabo a las propias máquinas virtuales. Por último se recomienda otro “Solution Accelerator” para mantener al ultimo nivel de actualizaciones las maquinas virtuales que pudieran estar almacenadas en la biblioteca, y del que hablaré un poco pronto por aquí:
Espero que os resulte de utilidad
Esta es la demo que hemos hecho sobre Hyper-V R2 en los eventos de Madrid y Barcelona de esta semana. El lunes lo grabamos por si las moscas, y pensando en compartirlo con los que no hayáis podido asistir.
Le he puesto unos cartelitos que pretenden ser autoexplicativos (lo siento, en inglés). Dado que tiene un buen tamaño, he preferido compartirlo en un Skydirve, en espera a que Fernando lo suba a Edge.
En esta demo se ve lo siguiente
Dos accesos por Remote Resktop, uno a una máquina virtual corriendo Windows 7 (con Vista o XP me hubiera bastado) y otra a un nodo de un cluster de Windows server 2008 R2 en el que está instalada la consola de Failover Cluster. Desde aquí:
Agradecimientos especiales a Ángel y José Manuel por su indispensable e inestimable ayuda con la ferretería.
Espero que os guste, y que pronto podamos disfrutar de la Release Candidate de Windows server 2008 R2.
Hoy, durante el evento Virtualización Inteligente en Madrid no se me ha ocurrido otra cosa que intentar hacer una pequeña demo de algo que no teníamos previsto dentro de la apretadísima agenda, y además sin tiempo para muchas explicaciones. Intentando migrar una máquina de un nodo del cluster a otro mediante System Center Virtual Machine Manager 2008 salía es siguiente mensaje de error:
Unable to migrate the virtual machine RedHat5 because the version of virtualization software on the host NODO2.nsbc.compaq.es (6.0.6001.22383) does not match the version of virtualization software on the source host (6.0.6001.22352). To be migrated, the virtual machine must be stopped and should not contain any saved state
La explicación es que simplemente un nodo se había actualizado con el KB967902 desde Windows Update y el otro no. Esta actualización solamente afecta a dos componentes de los servicios de gestión, pero ha sido suficiente como para hacer que el cluster no funcione correctamente desde SCVMM (aunque si desde la consola de Failover Cluster). Todo se podría haber evitado, aparte de probando más o no improvisando, introduciendo en el entorno un simple WSUS o mejor aun un System Center Configuration Manager. Esto demuestra la importancia de asegurar que en particular toda la plataforma de virtualización debe ser cuidadosamente maquetada, mantenida y operada de manera uniforme.
Sobre la lista de actualizaciones relativas a Hyper-V hay dos lugares donde puede consultarse la lista de los que van saliendo tanto para Hyper-V, y para que pueda ser gestionado por System Center Virtual Machine Manager 2008 y System Center Data Protectione Manager 2007 SP1.
Otra duda que puede surgir es qué actualizaciones de Hyper-V introducen modificaciones en la versión de los Componentes de Integración. Dichas versión se puede averiguar pidiendo las propiedades de, por ejemplo, el fichero vmbus.sys dentro de la máquina virtual:
Versión de ICs
Versión de Hyper-V
URL de descarga
6.0.6001.18000
Preview incluida en Windows Server 2008 RTM
-
6.0.6001.18016
Hyper-V RTM (KB950050)
http://www.microsoft.com/downloads/details.aspx?familyid=F3AB3D4B-63C8-4424-A738-BADED34D24ED&displaylang=en
6.0.6001.22258
Actualización para soporte de 24 procesadores lógicos (KB956710)
http://www.microsoft.com/downloads/details.aspx?FamilyId=FE36823A-7E5A-4262-9BF5-D6B3AE3AD375&displaylang=en
6.0.6001.22352
Actualización para mejorar la copias de seguridad / Restauraciones mediante VSS (KB959962)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;959962
Si, yo también estoy deseando que salga el SP2, y poder echarle el guante a la imagen “slipstreamed” de 2008 ya con él incluido.