Octubre 2008 Octubre 2008
Virtualización: Introducción a Hyper-V en Windows Server 2008
La presentación de Hyper-V convierte la virtualización en una solución mucho más atractiva para los entornos de TI. Obtenga información general acerca del mercado de la virtualización de la actualidad y conozca cómo Hyper-V mejora la capacidad de administración, la confiabilidad y la seguridad de la virtualización Rajiv Arunkundram
Virtualización: Administración de entornos virtuales con VMM 2008
System Center Virtual Machine Manager proporciona una interfaz consolidada para administrar la infraestructura virtual. La última versión agrega compatibilidad con Windows Server 2008 Hyper-V, así como con las máquinas virtuales de VMware. Explore las características nuevas y obtenga información sobre cómo usar VMM para centralizar sus tareas de administración. Edwin Yuen
Virtualización: Introducción a Microsoft Application Virtualization
Microsoft Application Virtualization (App-V) le permite distribuir escritorios virtualizados a sistemas cliente en toda su organización. De esta forma se simplifica la administración del sistema y libera a los empleados de la sensación de sentirse atados a sus escritorios. Observe más de cerca cómo funciona App-V y descubra cómo puede implementarlo en su organización. Anthony Kinney
Virtualización: Obtención de alta disponibilidad para Hyper-V
Consolidar servidores en menos equipos físicos tiene muchas ventajas, pero es muy importante planificar con anterioridad la alta disponibilidad de sus sistemas. Esta guía le servirá para aprender a usar los clústeres de conmutación por error de Windows Server 2008 y así obtener una alta disponibilidad para sus máquinas virtuales Hyper-V. Steven Ekren
Virtualización: Copia de seguridad y recuperación ante desastres para la virtualización de servidores
La virtualización aporta cambios sustanciales a la recuperación ante desastres. Ésta es una introducción a cómo la plataforma de virtualización de Microsoft puede contribuir a su plan de recuperación ante desastres, además de un análisis más profundo de las opciones de copia de seguridad y restauración, y las consideraciones para Windows Server 2008 Hyper-V. Adam Fazio
Virtualización: Herramientas esenciales para planificar su infraestructura virtual
¿Está su infraestructura lista para la virtualización? MAP Toolkit es una herramienta de evaluación de infraestructura para toda la red que puede ayudarle a entender mejor su infraestructura de TI y determinar si sus sistemas están listos para la actualización o migración a diversas tecnologías, incluida la virtualización. Jay Sauls y Baldwin Ng
Columns
Nota del editor: Es un mundo virtual(izado): | Cartas: Comentarios de los lectores: | Cuadro de herramientas: Nuevos productos para profesionales de TI:
Preguntas y respuestas sobre SQL: Grandes registros de transacciones, cuándo usar la reparación, entre otros temas: En esta entrega, Paul Randal responde a las preguntas acerca de las copias de seguridad y restauración, estudia las diferencias entre el trasvase de registros y la creación de reflejos de la base de datos y explica por qué la función de reparación sólo se debe usar como último recurso.Paul S. Randal | Utility Spotlight: Herramienta de mantenimiento de máquinas virtuales sin conexión: Las máquinas virtuales que se almacenan sin conexión no reciben automáticamente las actualizaciones necesarias para mantenerlas seguras y compatibles. Esto, a su vez, puede suponer un riesgo para todo su entorno de TI. Averigüe cómo la herramienta de mantenimiento de máquinas virtuales sin conexión le permite automatizar el proceso de actualización de las máquinas virtuales.Peter Skjøtt Larsen y Suveen Kumar Reddy Vuppala | Windows PowerShell: El poder de los perfiles: ¿Nunca había deseado que Windows PowerShell se iniciara con un entorno de trabajo hecho a la medida de sus necesidades? Don Jones muestra cómo se pueden usar perfiles para personalizar el shell de Windows PowerShell.Don Jones
Hey, Scripting Guy!: Últimas palabras célebres: Los Scripting Guys debaten sobre Sócrates y vuelven a tratar el tema de la consulta de archivos XML. Esta vez, en cambio, el archivo XML se ha estructurado de tal forma que, en lugar de usar los nodos secundarios, los valores de propiedad adicionales se han configurado como atributos.Los Scripting Guys de Microsoft | Archivos del escritorio: Personalización de Servicios de implementación de Windows: Wes Miller profundiza en los Servicios de implementación de Windows y muestra cómo puede personalizar y configurar WDS para satisfacer las necesidades de su organización.Wes Miller | Vigilancia de seguridad: Repaso a las 10 leyes inmutables de la seguridad, parte 1: Han pasado unos 8 años desde que se publicó por primera vez "Las 10 leyes inmutables de la seguridad" y ha habido muchos cambios desde entonces. Este mes, Jesper Johansson inicia una serie de tres partes donde analizará las leyes desde la perspectiva actual para comprobar si siguen estando vigentes.Jesper M. Johansson
Notas de campo: Código de barras de color de alta capacidad: Gavin Jancke ha desarrollado un código de barras nuevo, usando colores y triángulos, que cuenta con una capacidad de datos mucho mayor que los tradicionales códigos de barras en blanco y negro. Examine más de cerca estos códigos de barras de color de alta capacidad.Gavin Jancke | Confidencial de Windows: Trabajar más, no mejor: Raymond Chen examina la relación desigual que los errores tienen con los bloqueos y explica el motivo por el que es importante que los programadores sufran y también ofrezcan resultados.Raymond Chen


Virtualización
Introducción a Hyper-V en Windows Server 2008
Rajiv Arunkundram
De un vistazo:
  • ¿Qué es la virtualización?
  • Tres arquitecturas de virtualización
  • Hipervisor con microkernel frente a monolítico
  • Funcionamiento de Hyper-V

Contenido
Mercado de la virtualización de servidores
Cómo funciona la virtualización de servidores
Tipos de soluciones de virtualización
Hipervisor de Windows
Partición principal
Arquitectura de uso compartido de dispositivos
Componentes de integración
Conjunto de características de Hyper-V
Escalabilidad
Alta disponibilidad
Seguridad
Capacidad de administración
Conclusión
Recientemente se habla mucho de la virtualización, y gran parte de la discusión trata específicamente de la virtualización de servidores. Es una de las tendencias más interesantes en el sector y la que tiene la capacidad, en los próximos años, de cambiar el paradigma de la implementación de los sistemas de TI. Pero la virtualización de servidores no sólo cambiará el modo en que los administradores y arquitectos de TI perciben los servidores y el uso del sistema, sino que también va a afectar a los procesos y herramientas que se usan para administrar lo que, sin duda, se convertirá en un entorno cada vez más dinámico.
La virtualización ha estado presente desde hace tiempo, pero la tecnología sigue evolucionando. De hecho, la palabra en sí tiene significados distintos para diferentes personas. No obstante, en términos generales, la virtualización hace referencia a la abstracción de una capa de la pila de tecnología de la siguiente capa, como, por ejemplo, el almacenamiento de los servidores o el sistema operativo de las aplicaciones. La abstracción de las diferentes capas, a su vez, permite la consolidación y una mejor capacidad de administración.
Como concepto, la virtualización se aplica al almacenamiento, las redes, los servidores, las aplicaciones y el acceso. En relación con el almacenamiento y las redes, el objetivo de la virtualización es agregar un conjunto de distintos dispositivos de modo que el grupo total de recursos parezca y actúe como una sola entidad. Por ejemplo, puede configurar una solución de almacenamiento de 40 TB en vez de un conjunto de 20 dispositivos de almacenamiento de 2 TB. Pero con otros componentes, la virtualización actúa en la dirección contraria y le ayuda a que un único sistema aparezca como si hubiera múltiples sistemas. El ejemplo más habitual de este caso es la virtualización de servidores, donde se hospedan múltiples instancias y entornos de sistema operativo en un solo servidor.
Microsoft ha abordado la virtualización en diferentes niveles, que van desde el escritorio hasta el centro de datos con soluciones para la virtualización de servidores, virtualización de aplicaciones, virtualización de presentaciones y virtualización de escritorios. El denominador común de todos ellos es la administración con Microsoft System Center. En este artículo me centraré en el componente de virtualización de servidores y, específicamente, en el modo en que Hyper-V, una característica clave de Windows Server 2008, encaja en la ecuación de un centro de datos dinámico.

Mercado de la virtualización de servidores
En primer lugar, considero que merece la pena examinar lo que existe en el entorno de hoy en día y hacia dónde se dirige el mercado general. Según el estudio que lea, algunos analistas calculan que del 5% al 9% de los todos los servidores físicos que se venden en la actualidad se van a usar como hosts de virtualización. Tal vez considere que esto supone una gran cantidad de sistemas en un mercado en el que cada año se distribuyen más de nueve millones de servidores físicos. Pero una cosa es cierta: todavía hay una enorme oportunidad de mercado, ya que cada vez más clientes se sienten cómodos con la virtualización y desean emplearla.
Es importante tener en cuenta dónde se adopta la virtualización. Los clientes empresariales ciertamente son los que han abierto camino con sus pruebas y al ser los primeros usuarios. Sin embargo, hay pequeñas y medianas empresas que también implementan la virtualización. La adopción de la virtualización abarca distintos tipos de cargas de trabajo, desde aplicaciones empresariales y administrativas hasta la Web y el correo electrónico.
¿Por qué se habla ahora tanto de la virtualización? Hay varios factores y el más importante es la temporización. Se han combinado una serie de factores clave del sector al mismo tiempo, lo que contribuye a impulsar la mayor adopción de la virtualización. Entre estos factores sectoriales se incluye el cambio a la computación de 64 bits, los procesadores de varios núcleos e, incluso, el impulso de una computación sostenible para mejorar el uso del sistema.
Los sistemas están aumentando de tamaño y requieren una tecnología como la virtualización para realizar un uso completo de la eficacia del sistema. Pero aunque es cierto que la tecnología principal (y la ley de Moore) ha avanzado de forma continua en lo que respecta a la producción de una mayor capacidad de procesamiento de la que los sistemas pueden usar, ahora tenemos una mayor conciencia del impacto medioambiental, los requisitos de energía y los costos de refrigeración.
Todos estos factores, además del rendimiento de la inversión (ROI) al adoptar la virtualización, deberían acelerar la adopción de la virtualización en empresas grandes y pequeñas. Y nosotros, los profesionales de TI, podemos esperar que las principales empresas sigan invirtiendo en esta tecnología en los próximos años y mejorando las características y la funcionalidad.

Cómo funciona la virtualización de servidores
En términos generales, la virtualización de servidores permite tomar un único dispositivo físico e instalar (y ejecutar simultáneamente) dos o más entornos de sistema operativo potencialmente distintos y con diferentes identidades, pilas de aplicaciones, etc. Hyper-V es una tecnología de virtualización avanzada basada en hipervisor de 64 bits que ofrece capacidades de plataforma confiables y escalables. Junto con System Center, proporciona un único conjunto de herramientas de administración integradas para los recursos físicos y virtuales.
Todo esto sirve para reducir costos, mejorar el uso, optimizar la infraestructura y permitir que las empresas aprovisionen rápidamente nuevos servidores. Para ayudarle a comprender mejor cómo se ha diseñado Hyper-V, primero examinaremos los distintos tipos de soluciones de virtualización.

Tipos de soluciones de virtualización
Esencialmente existen tres arquitecturas generales que se usan para la virtualización de servidores, tal y como se muestra en la figura 1. Las diferencias fundamentales tienen que ver con la relación entre la capa de virtualización y el hardware físico. Cuando hablo de capa de virtualización, me refiero a la capa de software denominada monitor de máquina virtual (VMM, que no se debe confundir con Virtual Machine Manager). Esta es la capa que proporciona la capacidad de crear varias instancias aisladas que comparten los mismos recursos de hardware subyacentes.
Figura 1 Las tres arquitecturas de virtualización (haga clic en la imagen para ampliarla)
La arquitectura VMM de tipo 2 se ejemplifica mediante máquinas virtuales Java. Aquí, el objetivo de virtualización es crear un entorno de tiempo de ejecución en el que el proceso puede ejecutar un conjunto de instrucciones sin basarse en el sistema host. En este caso, el aislamiento es para los distintos procesos y permite que una sola aplicación se ejecute en varios sistemas operativos sin tener que preocuparse de las dependencias de sistema operativo. La virtualización de servidores no se incluye en esta categoría.
El VMM de tipo 1 y los VMM híbridos son dos tipos de planteamientos que probablemente tengan una mayor difusión en la actualidad. El VMM híbrido constituye una etapa en la que el VMM se ejecuta junto al sistema operativo host y ayuda a crear máquinas virtuales en él. Algunos ejemplos de VMM híbrido son Microsoft Virtual Server, Microsoft Virtual PC, VMware Workstation y VMware Player. Debe tener en cuenta que estos tipos de soluciones son excelentes para un escenario de cliente donde sólo se ejecutan máquinas virtuales una parte del tiempo, ya que los VMM agregan una sobrecarga considerable y, por lo tanto, no resultan adecuados para cargas de trabajo que realicen un uso intensivo de los recursos.
En una arquitectura VMM de tipo 1, la capa de VMM se ejecuta directamente sobre el hardware. Se suele denominar capa de hipervisor. Esta arquitectura la diseñó IBM originalmente en la década de 1960 para los grandes sistemas (mainframe) y recientemente se ha hecho disponible en las plataformas x86/x64 con una amplia variedad de soluciones, incluido Windows Server 2008 Hyper-V.
Existen soluciones en las que el hipervisor es una parte incrustada del firmware. No obstante, se trata simplemente de una opción de empaquetado y no cambia realmente la tecnología subyacente.
En lo que respecta a los VMM de tipo 1, existen principalmente dos modos principales de diseñar las soluciones de hipervisor: con microkernel y monolítico. Ambos de estos enfoques, tal y como se muestra en la figura 2, son auténticos VMM de tipo 1 en los que el hipervisor se instala directamente en el hardware físico.
Figura 2 Dos formas de diseñar las soluciones de hipervisor (haga clic en la imagen para ampliarla)
El enfoque de hipervisor monolítico hospeda el hipervisor/VMM en una sola capa que también incluye la mayor parte de los componentes requeridos, como el kernel, los controladores de dispositivo y la pila de E/S. Se trata del enfoque que usan soluciones como VMware ESX y los grandes sistemas (mainframe) tradicionales.
El enfoque con microkernel usa un hipervisor muy ligero y especializado que sólo lleva a cabo las tareas principales para garantizar el aislamiento de particiones y la administración de la memoria. Esta capa no incluye la pila de E/S ni los controladores de dispositivo. Es el enfoque que usa Hyper-V. En esta arquitectura, la pila de virtualización y los controladores de dispositivo específicos del hardware se encuentran en una partición especializada que se denomina la partición principal.

Hipervisor de Windows
La separación sólida entre los múltiples sistemas operativos se garantiza con la creación de procesadores virtuales, memoria, temporizadores y controladores de interrupciones. Los sistemas operativos usan estos recursos virtuales del mismo modo que usarían sus homólogos físicos.
El hipervisor de Windows, parte de Hyper-V, realiza las siguientes tareas:
  • Crea particiones lógicas.
  • Administra la programación de memoria y procesador para los sistemas operativos invitados.
  • Proporciona mecanismos para virtualizar la entrada/salida y establecer comunicación entre las particiones.
  • Aplica las reglas de acceso a la memoria.
  • Aplica la directiva de uso de la CPU.
  • Expone una interfaz de programación sencilla denominada hiperllamadas.
Debido a que usa el enfoque con microkernel, el hipervisor de Windows es bastante pequeño, con un tamaño de menos de 1 MB. Este espacio mínimo contribuye a mejorar la seguridad general del sistema.
Uno de los requisitos para ejecutar Hyper-V es disponer de un sistema x64 que tenga tecnologías Intel VT o AMD-V. La tecnología x64 permite el acceso a un espacio de direcciones mayor y compatibilidad con sistemas con más memoria, con lo que se pueden ejecutar más máquinas virtuales en un solo sistema host. Intel VT y AMD-V son las soluciones de virtualización asistida por hardware que proporcionan una capa con grandes privilegios en la arquitectura de anillo que ayuda a mantener el entorno de ejecución del hipervisor separado del resto del sistema. También permiten que Hyper-V ejecute un sistema operativo no modificado sin que suponga una penalización importante en el rendimiento de emulación.

Partición principal
Hyper-V consta de una partición principal, que es esencialmente una máquina virtual que tiene un acceso especial o privilegiado. Es la única máquina virtual con acceso directo a los recursos de hardware. Todas las demás máquinas virtuales, que se denominan particiones invitadas, pasan por la partición principal para obtener acceso a sus dispositivitos.
La existencia de la partición principal es bastante transparente. Cuando se comienza a instalar Hyper-V, lo primero que debe hacer es instalar Windows Server 2008 x64 Edition en el sistema físico. A continuación, se debe ir a Administrador de servidores, habilitar la función de Hyper-V y reiniciar el sistema. Una vez reiniciado el sistema, primero se carga el hipervisor de Windows y, después, el resto de la pila se convierte en la partición principal.
La partición principal es la propietaria del teclado, el mouse, la pantalla de vídeo y otros dispositivos conectados al servidor host. No tiene control directo sobre los temporizadores y los controladores de interrupciones que usa el hipervisor.
La partición principal contiene un proveedor de Instrumental de administración de Windows (WMI) para facilitar la administración de todos los aspectos del entorno virtualizado, así como una pila de virtualización que lleva a cabo las tareas relacionadas con el hardware en nombre de las particiones secundarias. Además, los controladores de fabricante de hardware independiente (IHV) que necesita el hardware del sistema host se incluyen en la partición principal y los controladores creados para las ediciones de Windows Server 2008 x64 también funcionan en la partición principal.

Arquitectura de uso compartido de dispositivos
Uno de los componentes de arquitectura innovadores en Hyper-V es la nueva arquitectura de uso compartido de dispositivos que admite los dispositivos emulados y sintéticos en cada sistema operativo invitado. La emulación de dispositivos resulta bastante útil para la compatibilidad de sistemas operativos anteriores en controladores de dispositivo diseñados para generaciones de hardware antiguas. Por ejemplo, Hyper-V incluye una emulación del adaptador de red Intel 21140, que se denominó adaptador de red DEC 21140 cuando se distribuían numerosos sistemas operativos antiguos.
Por lo general, la emulación de dispositivos es lenta, no se puede ampliar fácilmente y no se escala bien. Pero la emulación sigue siendo importante porque permite ejecutar la mayoría de los sistemas operativos x86 en Hyper-V. Debido a que la virtualización ahora está pasando de una tecnología nicho principalmente para pruebas y desarrollo a una tecnología esencial para entornos de producción, los usuarios requieren un mejor rendimiento para ejecutar mayores cargas de trabajo. Los dispositivos emulados ya no cumplen estas demandas cada vez más exigentes.
Una solución alternativa a esto es usar dispositivos sintéticos de Hyper-V. Los dispositivos sintéticos son dispositivos virtuales que se asignan directamente a dispositivos físicos. A diferencia de los dispositivos emulados, los sintéticos no emulan el hardware heredado. Con el modelo de uso compartido de hardware de Hyper-V, los sistemas operativos invitados compatibles pueden interactuar directamente con los dispositivos sintéticos que tal vez no tengan equivalentes físicos. Estos sistemas operativos usan clientes de servicio virtuales (VSC), que actúan como controladores de dispositivo dentro del sistema operativo invitado.
En vez de obtener acceso al hardware físico directamente, los VSC usan VMBus, que es un bus de alta velocidad en memoria, para tener acceso a los proveedores de servicios virtuales (VSP) en la partición principal. A continuación, los VSP administran el acceso al hardware físico subyacente, tal y como se ilustra en la figura 3. Una ventaja clave de los dispositivos sintéticos es que el rendimiento de dichos dispositivos sobre VMBus se aproxima al de los dispositivos de hardware no virtualizados.
Figura 3 Los VSC usan VMBus para obtener acceso a los VPS, que administran el acceso al hardware físico subyacente (haga clic en la imagen para ampliarla)

Componentes de integración
Hyper-V se ha diseñado para proporcionar límites sólidos entre las distintas instancias que se ejecutan en un equipo. Para habilitar la interacción entre los sistemas operativos invitado y host, y para suministrar funcionalidad adicional a los sistemas operativos invitados compatibles, Hyper-V proporciona componentes de integración.
Las componentes de integración de Hyper-V admiten las siguientes características:
  • Sincronización de hora
  • Servicio de instantáneas de volumen (VSS)
  • Funcionalidad Latido
  • Apagado de invitado
  • Intercambio de pares de clave y-valor (se usa para el acceso al Registro de un sistema operativo invitado)
  • Identificación de sistema operativo
Conjunto de características de Hyper-V
Ni que decir tiene que cuanto más se aproxima la plataforma de virtualización a la forma de actuar de un servidor físico, más fácil resulta para las organizaciones implementar y confiar en las cargas de trabajo virtuales. En mi opinión, existen cuatro áreas clave en las que se pueden ver las distintas características de la plataforma de virtualización.
En la actualidad, la mayoría de las soluciones de virtualización basadas en hipervisor se parecen mucho en cuanto a características y funcionalidad. A medida que se avanza, cuestiones como el costo total de propiedad (TCO) y la facilidad de uso serán los diferenciadores clave. Se realizarán inversiones continuas en las soluciones de administración y el desarrollo nos acercará a la visión de un entorno de TI dinámico, donde la infraestructura es lo suficientemente flexible como para adaptarse a las necesidades de la empresa, y los modelos y directivas ayudarán a impulsar una mayor automatización y administración.

Escalabilidad
Gracias a la arquitectura de hipervisor con microkernel, Hyper-V tiene muy poca sobrecarga de CPU, lo que deja mucho espacio para virtualizar las cargas de trabajo. Al permitir que las máquinas virtuales hagan uso de características y hardware eficaces, como la tecnología de multinúcleo, el acceso a disco mejorado y más memoria, Hyper-V mejora la escalabilidad y el rendimiento de la plataforma de virtualización.
Combinado con el resto de las capacidades de Windows Server 2008, Hyper-V permite consolidar la mayoría de las cargas de trabajo (incluidas las de 32 y 64 bits) en un solo sistema. Y puede ayudar a equilibrar la adopción de tecnología de 64 bits con compatibilidad continua con las cargas de trabajo de 32 bits que ya se usan en el entorno.
El hecho de que Hyper-V requiera un sistema host de 64 bits con virtualización asistida por hardware contribuye a garantizar que el sistema host podrá obtener acceso a un grupo grande de recursos de memoria. Hyper-V puede admitir hasta 1 TB de memoria en el host, con hasta 64 GB de memoria por máquina virtual. Esto resulta clave para quien planifique virtualizar cargas de trabajo que hacen un uso intensivo de la memoria, como Exchange Server y SQL Server.
Hyper-V también admite hasta 16 procesadores lógicos en el sistema host, lo que convierte a Hyper-V en escalable para la mayoría de los sistemas de dos y cuatro zócalos comerciales con varios núcleos. También puede crear una máquina virtual con un máximo de cuatro procesadores virtuales con el fin de admitir cargas de trabajo que requieran o aprovechen las ventajas de un multiprocesador.
La consolidación de servidores mediante Hyper-V también permite a dichos servidores utilizar la sólida compatibilidad de funciones de red, incluido VLAN, Traducción de direcciones de red (NAT) y las directivas (cuarentena) de Protección de acceso a redes (NAP). Y como una característica de Windows Server 2008, Hyper-V funciona bien con otras características de Windows Server, como BitLocker y Windows PowerShell.

Alta disponibilidad
La alta disponibilidad es un escenario donde Hyper-V y las capacidades de agrupación en clúster del host colaboran para atender las necesidades de continuidad de negocio y la recuperación ante desastres. La continuidad de negocio es la capacidad de minimizar el tiempo de inactividad programado y el no programado. Esto incluye el tiempo que se pierde con las funciones rutinarias tales como el mantenimiento o la copia de seguridad, así como las interrupciones imprevistas.
La recuperación ante desastres es un componente clave de la continuidad de negocio. Los desastres naturales, los ataques malintencionados e incluso los problemas sencillos de configuración, como los conflictos de software, pueden paralizar los servicios y las aplicaciones hasta que los administradores resuelven el problema y restauran los datos. Una estrategia confiable de negocio y de recuperación ante desastres debe ofrece una mínima pérdida de datos y capacidades de administración remota eficaces.
En lo que respecta a la alta disponibilidad, debe considerar tres categorías distintas: tiempo de inactividad planificado, tiempo de inactividad no planificado y copias de seguridad. La protección para el tiempo de inactividad no planificado normalmente es necesaria para quitar las máquinas virtuales del sistema host para poder realizar tareas de mantenimiento de hardware o aplicar revisiones al sistema host o la plataforma de virtualización (que puede requerir que se reinicie).
La mayoría de las organizaciones tienen intervalos de mantenimiento planificado y lo que se busca realmente es minimizar o eliminar el período de tiempo en el que las máquinas virtuales no estarán disponibles mientras el sistema está inactivo durante el mantenimiento. Con la característica Migración rápida se puede migrar rápidamente una máquina virtual en ejecución desde un nodo físico a otro en cuestión de segundos. De este modo puede mantener la disponibilidad de las máquinas virtuales para el entorno de producción mientras lleva a cabo el mantenimiento en el host original. Una vez terminado el mantenimiento, puede usar Migración rápida para devolver las máquinas virtuales a su sistema host original.
El tiempo de inactividad no planificado es el que no se ha previsto. Puede ser de naturaleza catastrófica o tan simple como que un usuario desenchufe accidentalmente un cable de alimentación y apague un servidor. Aunque pueda parecer improbable, con los años he conocido a algunos administradores en Tech•Ed, VMworld y otras conferencias que han contado cómo un compañero ha apagado accidentalmente un servidor.
Con Hyper-V, puede configurar un clúster de hosts para los distintos sistemas host y configurar todas las máquinas virtuales como recursos de clúster que pueden realizar la conmutación por error en otro sistema en el caso de que se produzca un error en uno de los hosts. Mientras tanto, la capacidad de agrupación en clúster multisitio de Windows Server 2008 permitirá configurar un clúster disperso geográficamente de modo que, si se produce un error en el centro de datos principal, se tenga la capacidad de recuperar las distintas máquinas virtuales en un centro de datos remoto.
Esto también resulta útil para proteger todas las sucursales. Una de las ventajas de administrar el tiempo de inactividad no planificado con Hyper-V es que es independiente del sistema operativo invitado, lo que significa que puede ampliar sus ventajas de alta disponibilidad a máquinas virtuales Linux y a versiones anteriores de Windows Server para proteger y recuperar estos sistemas de forma similar.
En lo que respecta al tiempo de inactividad no planificado, es importante tener en cuenta que la recuperación equivale a apagar el sistema y reiniciarlo, lo que significa que se habrá perdido toda la información de estado. Esto puede suponer un problema o no, según la carga de trabajo que esté ejecutando en la máquina virtual. Por eso es importante considerar la copia de seguridad en el contexto de la alta disponibilidad.
Hyper-V realiza copias de seguridad de cada máquina virtual o usa VSS para efectuar copias de seguridad coherentes de todas las máquinas virtuales compatibles con VSS mientras se están ejecutando. Con VSS, puede configurar que las copias de seguridad se realicen a intervalos definidos, sin que se vea afectada la disponibilidad de carga de trabajo de producción, a la vez que se garantiza que dispondrá de un plan de copias de seguridad continuo que puede ayudarle a recuperar fácilmente el estado si se produce un tiempo de inactividad no planificado. Para obtener más información acerca de las soluciones de alta disponibilidad con Hyper-V, consulte el artículo "Obtención de alta disponibilidad para Hyper-V" de Steven Ekren en este número de TechNet Magazine (technet.microsoft.com/magazine/cc837977).

La arquitectura de hipervisor con microkernel se ha diseñado para minimizar la superficie de ataque y mejorar la seguridad, especialmente cuando Hyper-V se implementa como función de Server Core. Server Core es una opción de instalación de Windows Server 2008. El hipervisor no contiene controladores de dispositivo ni código de terceros, lo que promueve una base estable, ligera y segura para ejecutar máquinas virtuales. Hyper-V también proporciona seguridad sólida basada en funciones con la integración de Active Directory. Y Hyper-V permite que las máquinas virtuales aprovechen las características de seguridad de nivel de hardware, como el bit de deshabilitación de ejecución (NX), lo que contribuye aún más al aumento de la seguridad de las máquinas virtuales.
Hyper-V ha pasado el ciclo de vida de desarrollo seguro (SDL) como el resto de los componentes de Windows Server y se ha realizado un exhaustivo análisis y una modelación de las amenazas para garantizar que Hyper-V es una plataforma de virtualización muy segura. Al implementar Hyper-V, asegúrese de seguir los procedimientos recomendados para implementar Windows Server y también los procedimientos recomendados para Hyper-V. Incluya Active Directory, así como soluciones antivirus o antimalware como parte de su plan. Y use las capacidades de administración delegada para garantizar que utiliza los privilegios de acceso administrativo de forma adecuada para los hosts de Hyper-V.

Capacidad de administración
Es fácil pasar de un ligero problema de dispersión de servidores a una dispersión de servidores masiva. Es el riesgo que conlleva la facilidad de implementación de las máquinas virtuales. Y con la mayor movilidad de las máquinas virtuales, debe saber exactamente dónde se ejecutan las distintas máquinas virtuales, mantener un seguimiento de sus contextos de seguridad, etc.
Afortunadamente, con Hyper-V no tiene que crear una infraestructura de administración independiente para su entorno virtual. Se integra con las herramientas de administración de Microsoft, System Center Virtual Machine Manager y Microsoft System Center Operations Manager, así como con herramientas de administración de terceros. Esto permite administrar todos los recursos físicos y virtuales desde una consola. Para obtener más información acerca de System Center Virtual Machine Manager 2008, consulte el artículo de Edwin Yuen, "Administración de entornos virtuales con VMM 2008", en este número de TechNet Magazine (technet.microsoft.com/magazine/cc836456). Mientras tanto, la compatibilidad con Windows PowerShell facilita la automatización de tareas.
Hyper-V también proporciona máquinas virtuales con una capacidad sin precedentes para usar el hardware disponible. Como todos los controladores certificados por el laboratorio de calidad de hardware de Windows (WHQL) pueden ejecutarse en la partición principal, Hyper-V ofrece una amplia compatibilidad con controladores y dispositivos, lo que facilita la administración de los distintos controladores que se ejecutan en el entorno.

Conclusión
Tal y como he mencionado anteriormente, la administración va a ser un área clave de desarrollo y de diferenciación. Sin duda alguna verá mucha actividad en esa área en los próximos años. En términos generales, se trata de un momento interesante en el que la virtualización adopta una función más principal. Si todavía no ha probado Hyper-V o simplemente desea más información, vaya a microsoft.com/Hyper-V.
Rajiv Arunkundram es director ejecutivo de productos de Microsoft y trabaja en la virtualización de servidores en la división de marketing de Windows Server. La responsabilidad principal de Rajiv es colaborar con clientes y socios para ayudarles a comprender la estrategia y las soluciones de virtualización de Microsoft desde un punto de vista técnico y de negocio.


Virtualización
Administración de entornos virtuales con VMM 2008
Edwin Yuen

Este artículo se basa en una versión preliminar de Virtual Machine Manager 2008. Por tanto, toda la información de este documento está sujeta a cambios.
De un vistazo:
  • Compatibilidad con máquinas virtuales de VMware
  • Scripts y automatización basados en Windows PowerShell
  • Administración consolidada y centralizada
  • Procedimientos de instalación

Contenido
Introducción a Virtual Machine Manager 2008
Integración con System Center
Instalación de Virtual Machine Manager 2008
Adición de hosts VMware ESX
Migración de VMotion
Conclusión
El año pasado, Microsoft presentó System Center Virtual Machine Manager 2007, que proporciona una interfaz consolidada para administrar una infraestructura virtual que ejecuta Microsoft Virtual Server 2005. Ahora, de modo que coincida con el lanzamiento del nuevo hipervisor Windows Server 2008 Hyper-V, se ha lanzado una nueva versión de Virtual Machine Manager (VMM). System Center Virtual Machine Manager 2008 no sólo administra las instalaciones de Microsoft Virtual Server 2005 y Windows Server 2008 Hyper-V, sino que la compatibilidad también se ha extendido a servidores VMware Infrastructure 3 (ESX/ESXi). Con VMM, ahora dispone de una interfaz de administración integrada que funciona con toda la infraestructura virtual, incluidos los sistemas Microsoft y VMware.
VMM es compatible con todas las tareas de virtualización tradicionales, como la implementación rápida de máquinas virtuales a partir de plantillas y máquinas virtuales preconfiguradas, conversiones de física a virtual (P2V), una biblioteca centralizada de objetos de infraestructura virtual e incluso una conversión de virtual a virtual (V2V) de las máquinas virtuales VMware (archivos de configuración VMX además de discos virtuales VMDK) a máquinas virtuales Hyper-V. Además, la integración de VMM con el resto de la familia System Center brinda la administración de los sistemas físicos y virtuales en un solo panel.
En este artículo examinaré VMM 2008 y las características nuevas que aporta a los administradores de TI. Después veremos los requisitos y los pasos que requiere una instalación de VMM. Por último, analizaré el modo de usar algunas de las características nuevas de VMM 2008.

Introducción a Virtual Machine Manager 2008
System Center Virtual Machine Manager 2008 es una aplicación independiente que proporciona administración centralizada de clase empresarial de las máquinas virtuales que se ejecutan en servidores Microsoft Virtual Server 2005 R2 SP1, Windows Server 2008 Hyper-V, Microsoft Hyper-V Server 2008 y VMware Infrastructure 3 (ESX/ESXi). Junto con otros productos de System Center, VMM proporciona administración de infraestructuras físicas y virtuales de extremo a extremo. En la figura 1 se muestra el diseño de arquitectura de Virtual Machine Manager.
Figura 1 Arquitectura de System Center Virtual Machine Manager 2008 (haga clic en la imagen para ampliarla)
Para quienes estén familiarizados con VMM 2007, advertirán que hay considerablemente más interfaces al sistema VMM en VMM 2008 (consulte la figura 1). Los cuadros de la parte superior izquierda representan VMM 2008, los cuadros de la parte superior derecha representan System Center Operations Manager 2007 y los sistemas e interfaces administrados se muestran debajo. Los cuadros rojos indican los servidores de administración, los cuadros azules muestran las entradas del sistema y los cuadros verdes son los sistemas host administrados cuyos objetos administrados se muestran de color amarillo.
El cuadro rojo de la parte superior izquierda representa el servicio del servidor Virtual Machine Manager 2008. Encima de él están las distintas interfaces al servicio, la Consola de administrador, la interfaz de Windows PowerShell y el portal web de autoservicio con acceso de usuario delegado. Windows PowerShell constituye la base para el acceso al servidor VMM. La Consola de administrador de VMM se ha creado totalmente en Windows PowerShell, por lo que puede crear scripts de Windows PowerShell que ejecute el servicio del servidor VMM. Por tanto, la API pública para VMM 2008 es Windows PowerShell y cualquier programa puede aprovechar VMM mediante Windows PowerShell. Un ejemplo excepcional de esto lo constituye la integración de XenDesktop Desktop Delivery Controller de Citrix con Virtual Machine Manager, que se realiza totalmente mediante Windows PowerShell.
Como respaldo de VMM está una base de datos de SQL Server 2005 o SQL Server 2008, tanto una instalación completa como SQL Server Express Edition si no hay disponible otra base de datos. Aunque el diagrama muestra a Operations Manager y Virtual Machine Manager apuntando a SQL Server, los dos programas no comparten una base de datos. Simplemente ejecutan la misma versión de SQL Server. La integración real entre Virtual Machine Manager y Operations Manager se lleva a cabo mediante un conector que está disponible a través de VMM. Este conector permite que VMM y OpsMgr compartan datos, con lo que se lleva la información de virtualización a OpsMgr y los datos de OpsMgr se llevan a VMM para las acciones.
La mitad inferior del diagrama muestra los hosts administrados. VMM 2008 todavía administra los hosts de máquina virtual de Virtual Server 2005 R2 SP1 y un recurso compartido de biblioteca centralizada, como sucedía en VMM 2007. Se debe tener en cuenta que en VMM el recurso compartido de biblioteca no es un almacén o servidor de archivos especial. Se trata simplemente de un recurso compartido de archivos de Windows que administra VMM. Puede administrar la biblioteca mediante VMM o puede copiar y eliminar archivos fácilmente del recurso compartido de archivos y dejar que VMM detecte los cambios. También puede tener múltiples bibliotecas, lo que resulta útil para los conjuntos de servidores delegados y para servidores de oficinas remotas.
Una novedad de VMM 2008 es la capacidad de administrar los hipervisores Hyper-V y ESX. La administración de hosts de Hyper-V se realiza mediante Administración remota de Windows (WinRM) y la interfaz de Instrumental de administración de Windows (WMI). De hecho, cuando se agrega un host potencial de Hyper-V, si la función de Hyper-V no está habilitada en Windows Server 2008, VMM puede habilitarla automáticamente para el administrador. Esta característica también está a disposición de los hosts potenciales de Virtual Server para sistemas de Windows Server 2003.
La administración de hosts de VMware VI3 ESX realmente se realiza mediante un servidor VMware VirtualCenter. VMM 2008 interactúa con VirtualCenter mediante la API de servicios web de VirtualCenter. Por lo tanto, se requiere un servidor VirtualCenter para la administración de VMware y la mayoría de las instalaciones empresariales de VMware tendrá al menos un servidor VirtualCenter. Lo que es exclusivo de VMM 2008 es la capacidad para administrar varios servidores VirtualCenter. VMM puede agregar varios servidores VirtualCenter, lo que permite que un administrador agregue toda la estructura de VMware y proporcione una sola vista empresarial que no era posible anteriormente.
Como parte de la familia de productos de System Center, VMM usa la interfaz de System Center o de tipo Outlook en la Consola de administrador. La Consola de administrador de VMM no es un complemento MMC, se trata de una aplicación completamente nueva creada con Microsoft .NET Framework y se basa en Windows PowerShell 1.0. De hecho, como se ha indicado anteriormente, cualquier acción de la Consola de administrador llama al comando de Windows PowerShell asociado, por lo que la interfaz de usuario realmente usa Windows PowerShell. Cualquier comando o función realizado en la Consola de administrador se puede llevar a cabo mediante la línea de comandos en Windows PowerShell.
Cada asistente en la Consola de administrador tiene un botón Ver script que puede mostrar el script de Windows PowerShell asociado con el comando que va a ejecutarse, el cual supone un buen punto de partida para conocer cómo se relacionan Windows PowerShell y VMM. La acción Ver script, que es una novedad de VMM 2008, ahora abre estos scripts en el Bloc de notas, por lo que se pueden editar fácilmente desde VMM. También se pueden guardar fácilmente los scripts editados, que podrá reutilizar desde la biblioteca de VMM, otra nueva característica de VMM 2008. Los cmdlets de VMM 2007 se han actualizado para VMM 2008, incluida la compatibilidad con los servidores VMware. Los mismos cmdlets funcionan en distintas plataformas de virtualización, por lo que los cmdlets como New-VM funcionan en sistemas Microsoft y VMware. De este modo, los administradores de TI pueden usar un conjunto de cmdlets para administrar hosts de Virtual Server, Hyper-V y VMware ESX.
Virtual Machine Manager 2008 se ha diseñado para proporcionar tres ventajas importantes a los administradores de TI:
  • Maximizar los recursos
  • Lograr una mejor agilidad
  • Aprovechar las capacidades existentes
Varias características y funciones facilitan estas ventajas. En primer lugar, VMM contribuye a maximizar los recursos mediante la integración de toda la infraestructura virtual, independientemente del hipervisor. Mediante la integración de los sistemas de Microsoft y VMware, VMM 2008 proporciona una vista única de todos los hosts y máquinas virtuales, tal y como se muestra en la figura 2, y permite que los administradores filtren y vean sus sistemas mediante parámetros como host, sistema operativo, propietario, fecha de adición, etc.
Figura 2 La consola de VMM muestra la administración integrada de Microsoft y VMware (haga clic en la imagen para ampliarla)
VMM también contribuye a maximizar los recursos del sistema mediante una consolidación sencilla de los servidores con conversiones tales como P2V y V2V. P2V permite consolidar los equipos físicos existentes en máquinas virtuales sin tener que volver a instalarlos. Esto resulta muy útil cuando se convierten equipos que tienen un uso reducido de su hardware, por lo que se pueden maximizar los recursos al colocar varios equipos de uso reducido juntos en un solo elemento de hardware físico. P2V es una característica integrada de VMM y no requiere software ni servidores adicionales. En VMM 2008 se ha agregado compatibilidad para un mayor número de sistemas físicos, incluidos los hosts de Windows Vista, Windows Server 2008 y x64. La funcionalidad P2V de VMM resulta un complemento excepcional para herramientas de planificación como la herramienta Microsoft Assessment Planning (MAP) (descrita en el artículo de Baldwin Ng y Jay Sauls en este número de TechNet Magazine), que ayuda a identificar a los candidatos para la consolidación de servidores.
Si ya tiene máquinas virtuales en formato VMDK de VMware, VMM permite usar V2V para convertir las VMDK existentes al formato VHD. Se trata de un proceso sin conexión: la máquina virtual de VMware se tiene que apagar para que el proceso V2V convierta el archivo VMDK real en un VHD. También puede convertir una máquina virtual de VMware mediante la función P2V. Puede resultar un poco confuso, pero es importante recordar que las máquinas virtuales ante todo son máquinas y, después, virtuales. Debido a que todos los demás sistemas ven las máquinas virtuales como máquinas en ejecución, lo mismo hará la funcionalidad P2V de VMM, que permite convertir una máquina virtual que se ejecute en cualquier software de virtualización en VHD de Microsoft.
VMM proporciona mayor agilidad a los administradores de TI mediante varias características. Una de las características clave que permite VMM es la migración de máquinas virtuales de un host a otro, lo que puede ayudar a mantener una alta disponibilidad y la optimización de servidores. Con los hosts de Hyper-V, VMM 2008 admite la migración rápida, con la que se puede mover una máquina virtual entre hosts de Hyper-V con sólo unos segundos de inactividad. Esto requiere un clúster de Windows Server 2008 y almacenamiento compartido, pero VMM contribuye a facilitar la administración y la configuración.
Con un host de VMware ESX, VMM 2008 también admite VMware VMotion, la característica de VMware que mueve máquinas virtuales sin que el usuario perciba tiempo de inactividad. Se requieren hosts de VMware ESX habilitados para VMotion, al igual que un back-end de clúster y SAN como la migración rápida. Más adelante en este capítulo mostraré un ejemplo de VMotion con VMM 2008.
Finalmente, VMM 2008 puede migrar una máquina virtual de Virtual Server 2005 existente a un host de Hyper-V, realizando automáticamente todas las actualizaciones y conversiones necesarias para la migración.
Como parte de cualquier implementación de máquinas virtuales (incluidas las migraciones anteriores) iniciadas mediante conversiones o nuevas implementaciones, VMM usa un proceso denominado ubicación inteligente para implementar las máquinas virtuales en los hosts. También usa el proceso de ubicación inteligente para consultar todos los hosts de máquinas virtuales que administra, recupera varios parámetros acerca de la disponibilidad de recursos de estos hosts y, a continuación, devuelve una lista ponderada de los hosts recomendados en los que puede implementar la máquina virtual. Como se puede ver en la figura 3, el proceso de ubicación inteligente admite hosts de Microsoft y VMware, junto con sus configuraciones de almacenamiento. El proceso de ubicación inteligente en VMM 2008 tiene en cuenta tanto la plataforma como la configuración. De este modo, sólo recomendará hosts que encajen en la plataforma de host correcta; sólo los hosts que estén en clúster si se necesita una alta disponibilidad y sólo hosts que admitan x64 para máquinas virtuales x64.
Figura 3 El proceso de ubicación inteligente analiza todos los hosts disponibles (haga clic en la imagen para ampliarla)

Integración con System Center
Una de las características clave de VMM 2008 es la integración con System Center Operations Manager 2007. Aunque VMM 2007 tenía algo de integración con Operations Manager, VMM 2008 incluye un conector de producto para Operations Manager que incrementa considerablemente la funcionalidad de la integración. Mediante su integración con Operations Manager, VMM proporciona informes de Operations Manager desde la consola de administración, así como una nueva característica denominada Optimización de rendimiento y recursos (PRO).
PRO permite que VMM 2008 cree alertas denominadas Sugerencias de PRO e incluso ejecute acciones según los parámetros de supervisión de Operations Manager. En la figura 4 se muestran algunas sugerencias de PRO de ejemplo. Cuando se usa un módulo de administración habilitado para PRO (módulo PRO), VMM 2008 puede llevar a cabo acciones automatizadas como las migraciones de máquinas virtuales y la creación de nuevas máquinas virtuales basadas en parámetros de rendimiento basados en host, hipervisor, hardware e incluso carga de trabajo.
Figura 4 Las sugerencias de PRO proporcionan alertas y soluciones para los problemas de la infraestructura virtual (haga clic en la imagen para ampliarla)

Instalación de Virtual Machine Manager 2008
Para realizar una instalación de System Center VMM 2008, existen varios requisitos previos y requisitos de sistema nuevos. En primer lugar, el servidor VMM 2008 requiere Windows Server 2008 x64. El servidor no se instalará en Windows Server 2003 ni en las versiones x86 de Windows Server 2008. La consola de administración y otros componentes se pueden instalar en Windows Server 2003 y Windows XP o Windows Vista (en el caso de la consola) con los mismos requisitos y procedimientos de instalación que VMM 2007.
En segundo lugar, VMM 2008 requiere una instalación en un dominio de Active Directory para su modelo de seguridad. VMM 2008 admite la administración de hosts de red perimetral (no unidos a dominio), incluida la característica P2V de sistemas que no sean de dominio, lo que supone una novedad en VMM 2008. Una de las ventajas del uso de Windows Server 2008 como plataforma de instalación es que muchos de los requisitos previos de VMM (como .NET Framework 3.0, WinRM y Windows PowerShell 1.0) ya están integrados. Finalmente, VMM 2008 requiere el Kit de instalación automatizada de Windows (WAIK) 3.0, aunque el instalador de VMM 2008 incluye los archivos de instalación.
Aunque recomiendo que en un entorno de producción cada componente de VMM se instale en un servidor de producción independiente, explicaré una instalación de servidor único. El hardware recomendado para una instalación de servidor VMM es un servidor basado en x64 que se ejecute a un mínimo de 2,8 GHz con, al menos, 2 GB de RAM. Puesto que se trata de una instalación de servidor único con una base de datos local de SQL Server, se necesitan 7 GB de espacio en el disco duro. Tenga en cuenta que si se usa una base de datos remota, sólo se necesitará 1 GB para la instalación de VMM. Se recomienda un espacio de 80 GB adicionales para la instalación de la biblioteca local.
Tal como he mencionado anteriormente, VMM se ejecuta en una instalación x64 de Windows Server 2008. Los requisitos de software adicionales son .NET Framework 3.0, Windows PowerShell 1.0, WinRM e IIS 6.0 o posterior para el portal de autoservicio. También se requiere el analizador de Microsoft MSXML 6.0, pero está incluido como parte de .NET Framework 3.0.
Al iniciar la instalación de VMM se ofrecen cinco opciones: Servidor Virtual Machine Manager, Consola de administrador, Portal de autoservicio y Agente local, así como una opción para configurar el módulo de administración de Operations Manager. Tal como he mencionado, instalaré todos los componentes en un solo equipo, empezando por el servidor VMM. Una vez iniciada la instalación, las primeras pantallas comprobarán los requisitos previos del sistema.
Además de los requisitos mencionados anteriormente, el equipo debe estar en un dominio. La instalación del servidor VMM habilitará automáticamente las funciones integradas, con lo que se elimina la necesidad de habilitarlas manualmente.
Una vez iniciado el instalador, recomiendo usar la opción de Windows Update para asegurarse de que VMM 2008 está actualizado. El instalador revisará las opciones, relacionadas principalmente con la instalación de la base de datos SQL. Para este ejemplo, usaré SQL Server 2005 Express Edition.
A continuación, el asistente le solicita que identifique la ubicación de la biblioteca centralizada. Se puede tratar de un directorio local en el servidor VMM (y se creará un recurso compartido para dicho directorio) o puede ser un recurso compartido de archivos existente. La ubicación predeterminada es C:\ProgramData\Virtual Machine Manager Library Files.
Después se realizan las asignaciones de puerto. Aquí se configura el puerto de la conexión de Consola de administrador al servicio del servidor VMM básico (8100 de forma predeterminada), el puerto que usa WinRM para llevar a cabo las funciones de administración (80 de forma predeterminada) y el puerto que usa el Servicio de transferencia inteligente en segundo plano (BITS) para mover archivos a los hosts de máquina virtual (443 de forma predeterminada). Una vez especificada esta información, se presenta una pantalla de resumen y la instalación del servidor puede finalizar.
A continuación instalaremos la Consola de administrador, que tiene requisitos previos de sistema similares al servidor VMM. La única opción de configuración disponible aparte del directorio de instalación es la confirmación del puerto de comunicaciones usada para conectarse al servicio del servidor VMM. Este puerto debe ser el 8100, tal y como se ha configurado en la instalación del servidor VMM.
Al final de la instalación se ofrece la opción de crear un acceso directo de escritorio para la Consola de administrador y para abrir la consola cuando cierre la instalación. Es buena idea seleccionar las dos opciones. La primera vez que abra la Consola de administrador, se le solicitará que se conecte al servidor. Con la instalación de servidor único, localhost en el puerto 8100 es correcto y basta presionar Entrar para iniciar la consola.
Por último, instalaremos el portal de autoservicio. Los requisitos previos para esta opción son IIS 6.0 o 7.0, .NET Framework 3.0 y Windows PowerShell 1.0. (Se necesita Windows PowerShell, ya que el portal de autoservicio es sólo una interfaz a los servicios de VMM principales, que usan Windows PowerShell.) Para Windows Server 2008, debe habilitar la función IIS antes de iniciar la instalación de VMM 2008. De este modo se asegura de que los siguientes servicios de función de IIS están habilitados:
  • Características HTTP comunes (Contenido estático, Documento predeterminado, Examen de directorios, Errores HTTP)
  • Desarrollo de aplicaciones (ASP.NET, Extensibilidad de .NET, Extensiones ISAPI, Filtros ISAPI)
  • Seguridad (Filtro de solicitudes)
  • IIS 6.0 Management Compatibility
Si estos servicios de función están habilitados, la instalación superará la comprobación de requisitos previos y comenzará la instalación. Durante la instalación, las opciones de configuración tratan únicamente los puertos que usa el portal de autoservicio. El primero, el puerto para conectar al servicio de VMM principal, es 8100, el mismo que para la Consola de administrador. El segundo es el puerto en el que se ejecutará el portal. El predeterminado es el puerto 80, pero en numerosas configuraciones el puerto ya está ocupado y el instalador de VMM le avisará si es así. Si es necesario, cambie el puerto por uno que esté abierto, como 8080. El instalador creará un sitio web denominado Inicio de portal de autoservicio de Microsoft System Center Virtual Machine Manager 2008. La configuración se puede cambiar en el Administrador de servidores.
Cuando se haya completado la instalación de IIS, vaya a localhost:8080 para abrir el sitio web en Internet Explorer. Si se le solicita autenticación para abrir el sitio web, se debe a la configuración de seguridad de Internet Explorer. El portal de autoservicio debe ejecutarse en el contexto de intranet en Internet Explorer y puede que necesite agregar el servidor VMM a la lista de sitios de intranet en Internet Explorer. Una vez realizadas estas configuraciones, estará listo para crear y usar las máquinas virtuales habilitadas para autoservicio en VMM 2008.

Adición de hosts VMware ESX
Aunque hay numerosas características nuevas en VMM 2008, sin lugar a dudas la más esperada es la adición de compatibilidad con la administración de hosts VMware ESX. Con esta compatibilidad, VMM ahora puede administrar la infraestructura virtual de la mayoría de los departamentos de TI empresariales.
El proceso de adición de hosts ESX a Virtual Machine Manager 2008 es bastante sencillo. Como he indicado anteriormente, VMM 2008 administra los hosts VMware mediante un servidor VirtualCenter, que debe ser de la versión 2.0.1 o 2.5. Para agregar los servidores VMware ESX a la consola de administración, simplemente se agrega el servidor VirtualCenter con la acción Agregar servidor VMware VirtualCenter que se encuentra en la parte superior derecha del panel Acciones.
Después de iniciar el asistente, escriba el nombre de equipo del servidor VirtualCenter junto con la cuenta administrativa para dicho servidor. VMM agregará los hosts ESX, incluida la estructura de grupo de hosts existente de VirtualCenter, a la interfaz de VMM. Esta tarea puede tardar varios minutos, pero puede supervisar el progreso en el menú VMM Jobs.
Cuando se hayan importado todos los servidores, debe poder ver la misma estructura de servidores host VMware ESX en VMM que la que se muestra en VirtualCenter. Para agregar otro servidor VirtualCenter, basta con repetir el proceso. Una vez agregada la estructura de hosts a VMM, puede agregar los servidores que no son VMware a la misma estructura de grupo. Evidentemente, los servidores que no sean VMware no se mostrarán en VirtualCenter.
Aunque VMM 2008 usa VirtualCenter para administrar los hosts ESX, debe poder obtener acceso directamente a los hosts ESX para determinadas funciones, como V2V, almacenamiento del estado y clonación de máquinas virtuales a partir de hosts ESX. De este modo, después de agregar el servidor VirtualCenter a VMM, los hosts se mostrarán como Correcto (limitado). Para habilitar la administración completa, vaya a la página Propiedades de los hosts ESX individuales en VMM y proporcione las credenciales de host adecuadas para administrar directamente los servidores.

Migración de VMotion
Siempre que se trata la administración de VMware en Virtual Machine Manager 2008, invariablemente se plantea la pregunta de si VMM puede realizar la función de VMotion, así como otras funciones de VirtualCenter. Y desde que VMM usa VirtualCenter para la administración de VMware, la respuesta a esa pregunta es sí.
Funcionalmente, VMM trata VMotion como cualquier otra migración. Para iniciar una función VMotion, seleccione primero la máquina virtual que desee mover y, a continuación, seleccione la opción Migrar máquina virtual en el panel Acciones de la parte derecha de VMM. Una vez haya terminado, VMM muestra la ventana del proceso de ubicación inteligente para dicha máquina virtual y presenta los posibles hosts de destino, con un tipo de transferencia Activa, tal y como se muestra en la figura 5. El proceso de ubicación inteligente puede ayudarle a seleccionar los hosts de destino correctos para sus máquinas virtuales. Tenga en cuenta que es el mismo proceso que realizar una migración rápida con hosts Hyper-V.
Figura 5 VMotion con el proceso de ubicación inteligente (haga clic en la imagen para ampliarla)
Seleccione el host de destino para la máquina virtual; en este caso se trata del servidor denominado cqaesxi003.contoso.com y haga clic en Siguiente. La ventana final del resumen, mostrada en la figura 6, mostrará la acción solicitada.
Figura 6 Ventana VMotion Summary (haga clic en la imagen para ampliarla)
Tal y como he mencionado anteriormente, cada asistente de VMM tiene un botón Ver script que puede mostrar el script de Windows PowerShell de un trabajo en el Bloc de notas. Esto nos da la oportunidad de ver cómo funciona Windows PowerShell en VMM 2008 con VMware. El script de esta acción es:
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq "cqaesxi003.contoso.com"}
$VMHost = Get-VMHost -VMMServer localhost |   where {$_.Name -eq "cqaesxi003.contoso.com"}
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
Tres comandos sencillos realizan la operación de VMotion para este sistema. En el ejemplo, traslado la máquina virtual MyVM desde el servidor VMware cqaesxi003.contoso.com al servidor cqaesxi001.contoso.com. El primer comando identifica la máquina que se migrará mediante VMotion. Como se puede ver en esta línea de comandos, asigno el valor de máquina virtual a la variable $VM:
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq " cqaesxi003.contoso.com"}
El segundo comando identifica el sistema host ESX de destino para la máquina virtual. En esta línea, asigno la variable $VMHost al host ESX cqaesxi003.contoso.com:
$VMHost = Get-VMHost -VMMServer localhost | where
  {$_.Name -eq " cqaesxi003.contoso.com"}
Finalmente, uso el comando Move-VM para mover realmente la máquina virtual. A continuación se muestran la línea de comandos y los parámetros completos para Move-VM:
Move-VM [-VM] [<String VM>] -VMHost [<String Host>]
  [-JobGroup <Guid>] [-JobVariable <String>] [-Path
  <String>] [-PROTipID] [-RunAsynchronously]
  [-StartVMOnTarget <Boolean>] [-UseLAN <Boolean>]
  [<CommonParameters>]
De acuerdo con la filosofía de administración heterogénea en Virtual Machine Manager, se puede ver que el comando no es específico de proveedor o de software. Para completar la operación VMotion, use este comando:
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
Indica a VMM que ejecute Move-VM, en la máquina virtual de $VM, que la mueve al sistema host de $VMHost y que ejecute el trabajo asincrónicamente. Una vez iniciado el trabajo, el proceso entero se puede supervisar desde la ventana Trabajos de VMM. De nuevo, este mismo comando básico se puede usar para migraciones rápidas en clústeres de Hyper-V e incluso en hosts no en clúster, mediante una transferencia basada en LAN.
Como se puede ver, System Center Virtual Machine Manager 2008 ha ampliado las características y funciones excepcionales de Virtual Machine Manager 2007 con nuevas plataformas de administración y características. Con la revisión del proceso de instalación y par de características, espero haber mostrado la sencillez y la administración de múltiples hipervisores en VMM 2008.
VMM 2008 se ha diseñado para ser el software de administración consolidada para la virtualización, ya que unifica los sistemas físicos y virtuales de Microsoft y VMware. Con esta nueva versión de Virtual Machine Manager, los administradores de VMware, los administradores de Microsoft Virtual Server 2005 y los nuevos administradores de Hyper-V pueden aprovechar por completo una herramienta única, una sola interfaz de scripts y, lo que es más importante, un único proceso de administración para su infraestructura virtual.

Edwin Yuen es director técnico de producto de la división de Administración empresarial de Windows para System Center Virtual Machine Manager. Edwin llegó a Microsoft por medio de la adquisición de Softricity en julio de 2006. Edwin cuenta también con 13 años de experiencia en consultoría técnica tanto en espacios comerciales como federales. Es licenciado en Ingeniería eléctrica por la Johns Hopkins University.


Virtualización
Introducción a Microsoft Application Virtualization
Anthony Kinney

Este artículo está basado en una versión preliminar de App-V. Por lo tanto, toda la información de este documento está sujeta a cambios.
De un vistazo:
  • Arquitectura de App-V
  • Administración de las aplicaciones virtuales
  • Uso del secuenciador de App-V
  • Integración de App-V con el Administrador de configuración

Contenido
La arquitectura de App-V
Cómo funciona la infraestructura completa de App-V
Actualización de las aplicaciones virtuales
Proceso de secuencias
Versión 4.5
Microsoft Application Virtualization (o App-V) es una de mis aplicaciones preferidas. App-V antes era conocida como SoftGrid, y yo llegué a Microsoft tras la adquisición de la compañía que creó SoftGrid, llamada Softricity. Hoy estoy contento de tener la oportunidad de escribir este artículo para TechNet Magazine, ya que han cambiado muchas cosas desde que se produjo la adquisición.
La mejor manera de enfocar App-V es hablar primero de los desafíos que los profesionales de TI afrontan en relación con la administración empresarial. Los escritorios empresariales de hoy en día están inundados de aplicaciones. Antes de instalar cualquier aplicación, deben pasar por unas largas pruebas de regresión para asegurarnos de que la aplicación puede coexistir con las otras ya instaladas en el sistema, sin que ello afecte a la capacidades de éstas de ejecutarse correctamente. Después, la aplicación deberá seguir una serie de procesos de implementación antes de llegar a la fase de producción. Y, como básicamente una aplicación sólo está disponible allí en donde está instalada, sus usuarios se ven atados a equipos específicos. Esto hace que los proyectos complejos y más importantes, tales como las migraciones de sistemas operativos y de aplicaciones, las actualizaciones de seguridad y la planificación de la recuperación ante desastres, se compliquen aún más.
App-V cambia todo esto. Más que una serie compleja de pasos laboriosos que consumen recursos, con App-V, la administración del escritorio se convierte en un proceso más sencillo y automatizado. Se pueden implementar, aplicar revisiones, actualizar y finalizar aplicaciones de forma fácil y con unos resultados mejores.
Con App-V, un usuario puede sentarse en cualquier escritorio y tener acceso a todas sus aplicaciones. Las aplicaciones se distribuyen a petición pero, de hecho, se ejecutan como si se hubiesen instalado de forma local. De esta manera, no hay necesidad de instalar los componentes de la aplicación ni de alterar el dispositivo host.
Este uso de la virtualización puede cambiar drásticamente la forma en que los profesionales administran sus escritorios. El hecho de no alterar el dispositivo host y de ejecutar aplicaciones virtualizadas, en cambio, introduce numerosas ventajas, entre las que se incluyen:
  • Menor número de conflictos con las aplicaciones
  • Actualizaciones de las aplicaciones más rápidas y fáciles
  • La posibilidad de ejecutar múltiples versiones de la misma aplicación en paralelo
  • Aplicaciones flexibles que siguen a los usuarios tanto cuando están conectados como cuando no lo están
  • Pruebas de regresión de aplicación a aplicación

La arquitectura de App-V
Ahora vamos a ver lo que realmente sucede entre los bastidores de la plataforma App-V. Esta plataforma está formada por varios componentes principales: un secuenciador, una base de datos, clientes, un servidor de administración, un servidor de transmisión y una consola de administración (consulte la figura 1).
Figura 1 Diseño de un entorno App-V (haga clic en la imagen para ampliarla)
En el centro del sistema de App-V está el cliente App-V. Hay dos tipos de clientes que pueden usarse: el cliente de Terminal Server y el cliente de escritorio. En cualquiera de los casos, es necesario instalar el cliente en cada uno de los escritorios y Terminal Server en aquellos en los que prevé implementar las aplicaciones virtuales. El cliente ocupa relativamente poco espacio en disco. Instala un controlador y cuenta con un componente visible del tiempo de ejecución del usuario que aparece como un indicador de bandeja.
El cliente reúne una lista de aplicaciones virtuales desde el servidor de administración de App-V y muestra las aplicaciones virtuales que hay disponibles. Controla el inicio de estas aplicaciones (cuando las inicia el usuario) y administra la memoria caché del cliente. El cliente también es responsable de la administración para la creación del entorno virtual del tiempo de ejecución y se asegura de que cada entorno ejecute su propia burbuja virtual. Este entorno virtual incluye varios componentes, incluidos un registro virtual, un sistema de archivos virtual y un administrador de servicios virtual.
Para la implementación de la infraestructura en App-V 4.5, hay tres opciones disponibles: la infraestructura completa, la infraestructura ligera y el modo independiente. Al implementarse una infraestructura completa, el servidor incluye App-V Management Server y App-V Streaming Server (éste último es un componente nuevo del que hablaremos dentro de un momento). App-V Management Server hospeda y distribuye las aplicaciones centralizadas virtuales, y además actualiza las aplicaciones virtuales cuando se aplican las revisiones o actualizaciones.
Este servidor de administración depende de SQL Server para hospedar la base de datos de App-V, la cual contiene la configuración y los valores de las aplicaciones virtuales. Para aprovisionarse de los permisos y poder controlarlos para las aplicaciones virtuales, deben usarse grupos de Active Directory como la herramienta de administración central.
Para administrar los valores y la configuración, la plataforma de App-V proporciona un servicio web de Microsoft .NET Framework que puede cargarse en el mismo servidor, siempre y cuando tenga instalado IIS. Este servicio web actúa como un enlace entre la consola de administración de App-V, un complemento de Microsoft Management Console (MMC) y la base de datos de App-V. Los administradores pueden usar la consola para publicar y administrar las aplicaciones virtuales, asignar grupos de Active Directory y valores de control del servidor, así como ejecutar informes sobre el uso de las aplicaciones virtualizadas (consulte la figura 2).
Figura 2 Consola de administración (haga clic en la imagen para ampliarla)
La infraestructura ligera incluye el servidor de transmisión de App-V, el cual habilita las capacidades de transmisión como la actualización activa o de paquetes. Esta opción no requiere Active Directory ni SQL Server, no cuenta con ningún servicio de configuración de escritorio y carece de las capacidades de licencia y medición. La infraestructura ligera sí que permite, sin embargo, que las capacidades de transmisión sean agregadas a System Center Configuration Manager (SCCM) y a otras soluciones de implementación de software empresarial (ESD) de terceros.
En el modo independiente, el secuenciador de App-V puede crear un archivo MSI que automatice la adición de la aplicación virtual (consulte la figura 3). El archivo MSI contiene metadatos que permiten que cualquier sistema de ESD lo reconozca y controle la aplicación virtualizada. Este modo requiere que el cliente entre en el modo independiente, que sólo permite actualizaciones de las aplicaciones virtuales basadas en MSI, mientras que la transmisión por secuencias no está permitida en este modo. Este modo ofrece a las organizaciones la posibilidad de usar las capacidades de aislamiento de App-V.
Figura 3 El secuenciador de App-V (haga clic en la imagen para ampliarla)
Los archivos MSI son muy flexibles, ya que pueden ejecutarse de forma completamente independiente con un solo cliente App-V y no requieren componentes de servidor. Esto significa que pueden implementarse de forma manual, mediante disco o mediante las herramientas de implementación tradicionales.
En App-V 4.5, los protocolos HTTP y HTTPS ahora son compatibles con los protocolos de transmisión, lo que permite obtener un mejor rendimiento de la transmisión por secuencias además de un protocolo adoptado de forma más amplia, especialmente para la transmisión por secuencias en todos los entornos seguros de la red de área extensa (WAN) y de Internet.

Cómo funciona la infraestructura completa de App-V
Un usuario inicia sesión en un dispositivo que tiene uno de los clientes instalados (App-V Terminal Services o cliente de escritorio), y este cliente envía una solicitud al servidor para conseguir una lista de aplicaciones asignadas al usuario actual. El servidor se comunica con Active Directory para determinar de qué grupos es miembro el usuario y, a continuación, devuelve la lista de aplicaciones al cliente. El cliente empieza a crear anuncios para las aplicaciones virtuales que hayan sido asignadas a ese usuario concreto.
Durante este proceso de publicación, se llevan a cabo varias acciones:
  • Se copian los archivos de configuración
  • Se crean los iconos de escritorio
  • Se crean vínculos Enviar a
  • Se crean carpetas del menú Inicio
  • Se configuran los tipos de archivos
Este proceso es muy rápido y, lo que es más importante, asegura que el entorno presente exactamente el aspecto que el usuario espera, sin que haya cambios visuales. Las aplicaciones virtuales actúan como si estuvieran instaladas de forma local, pero, por supuesto, no alteran el equipo host. Los iconos, en lugar de apuntar a los archivos ejecutables que residen en el directorio de archivos de programa, apuntan al cliente de App-V, que depende de un archivo selector (un archivo OSD) para su configuración.
Es importante tener en cuenta que este proceso tiene muy poca repercusión sobre la red porque, a diferencia de las implementaciones de software tradicionales, no se instala nada. Esto tiene grandes ventajas, especialmente en lo relativo a la movilidad de los entornos de usuario, ya que las aplicaciones están disponibles para el usuario pero, de hecho, no se proporciona nada hasta que se inicia alguna aplicación. Este método de anuncios es también lo que proporciona las características de aplicaciones a petición y de movilidad de App-V.
Cuando el usuario inicia una aplicación virtual, el cliente lee un archivo de configuración OSD, que previamente ha sido almacenado en el equipo local. Éste informa al cliente sobre qué protocolo debe usar al comunicarse con el servidor de administración de App-V y en qué servidor se encuentra la aplicación.
El servidor adecuado responde al cliente transmitiendo en secuencias el umbral inicial, que es normalmente de entre el 20 y el 40 por ciento de la aplicación completa. Una vez que transmitido todo el umbral de inicio (de nuevo, de entre el 20 y el 40 por ciento de la aplicación), la aplicación virtual estará preparada para ejecutarse.
La transmisión por secuencias es realmente uno de los elementos clave del cambio de paradigma que se introduce con App-V. Envía lo justo de una aplicación de forma que pueda ejecutarse sin malgastar el valioso ancho de banda de la red. Todos los datos que deben proporcionarse al cliente se encuentran en un archivo de la memoria caché local del dispositivo y cualquier inicio posterior de la aplicación se inicia desde la memoria caché local, lo cual elimina el tráfico adicional de la red.
Una vez que la aplicación virtual ha finalizado la transmisión por secuencias, el cliente construye un entorno aislado que evita que la aplicación altere el equipo local (en otras palabras, la aplicación no dispone de superficie de cliente). El cliente sí que permite, sin embargo, que las aplicaciones virtuales tengan acceso al sistema de archivos local al guardarlos y editarlos, y también permite que la aplicación interactúe con los servicios locales (como la impresora), siempre y cuando el usuario disponga de los privilegios adecuados en el sistema local. Sin embargo, cualquier cambio hecho por una aplicación virtual a los archivos del sistema local y al registro se redireccionan al entorno virtualizado de tal forma que el dispositivo de host permanece sin cambios.
Al ejecutar la aplicación, cualquier característica que no haya sido usada anteriormente se proporciona a medida que se va necesitando y se almacena en la memoria caché para poder usarse más adelante. La ventaja de esto es que en primer inicio sólo se cargan los componentes que necesita el usuario, y así las características que no son necesarias no consumen recursos de red. (La nueva versión ofrece algunas mejoras del almacenamiento en la memoria caché del cliente que permiten un uso de la caché más inteligente y una transferencia por secuencias de los antecedentes.)
Piense en Microsoft Office Word, por ejemplo. Casi todos los usuarios usan el corrector ortográfico (de hecho, yo no podría escribir este artículo sin él); por lo tanto, formaría parte del primer inicio. ¿Pero qué hay sobre la característica Ayuda de Word? No hay muchos usuarios que la usen y, por tanto, no haría falta que se proporcionara en el primer inicio de la aplicación. En lugar de eso, se enviaría a un usuario la primera vez que obtuviera acceso a ésta.
Cuando el usuario termina y cierra la aplicación, el cliente anula el entorno virtual y almacena toda la configuración de usuario en una ubicación específica de tal forma que el entorno se puede conservar y volver a generar al inicio siguiente. Cualquier porcentaje de la aplicación virtual que se hubiese transferido permanece en la memoria caché local y estará disponible al inicio siguiente. Y si otro usuario inicia sesión en el mismo sistema host e inicia la misma aplicación virtual, el nuevo usuario se reutilizará la aplicación ya almacenada en la memoria caché.
Para quitar los anuncios virtuales de la aplicación, sólo tiene que quitar al usuario del grupo correspondiente de Active Directory. Y para desinstalar la aplicación virtual completamente de un escritorio, sólo hace falta limpiar la memoria caché. Puesto que la aplicación nunca se instaló realmente de forma local, no hay mensajes molestos que pregunten: "¿Desea eliminar este componente compartido?"
Observe que, incluso si una aplicación virtual se almacena en una memoria caché, eso no significa que todos los usuarios tengan acceso a ésta. A diferencia de las aplicaciones instaladas de forma local en las que los usuarios sólo necesitan buscar o navegar por los archivos ejecutables sobre los que tienen derechos, no hay representaciones visuales o físicas de que la aplicación virtual exista, salvo que al usuario se le hayan concedido derechos explícitos a través de los grupos de Active Directory.

Actualización de las aplicaciones virtuales
La actualización se realiza mediante el secuenciador. Una vez que una aplicación ha sido revisada para incluir una actualización, se coloca en el servidor de administración de App-V, justo al lado de la versión anterior. Luego, en el siguiente inicio el servidor notificará al cliente que se ha producido un cambio. Si la versión anterior todavía está en uso, el usuario continúa teniendo acceso a esa versión, hasta que la aplicación virtual se cierra. En el siguiente inicio, se transmiten al cliente los archivos deltas que llevan a cabo la actualización y se cargan en la memoria caché, con lo que se consigue una versión actualizada de la aplicación.
Supongamos que hay 1.000 usuarios ejecutando Word 2000. Un administrador necesita actualizar Word 2000 (word2K.sft) a Word 2000 SP3, así que copia el archivo word2K.sft en la estación de secuencias y selecciona Abrir para actualizar paquete en el secuenciador. Al seleccionar Abrir para actualizar paquete, el administrador empieza a funcionar desde el último estado del paquete. Así el usuario puede copiar los archivos DLL, ejecutar actualizaciones o revisiones dentro de la aplicación virtual para actualizarla a Word 2000 SP3. De esta forma el administrador guarda el paquete actualizado.
El secuenciador asigna automáticamente un nombre de archivo nuevo, word2K_2.sft, para evitar duplicar los nombres de archivos e indicar la versión de las secuencias. Este nuevo paquete se coloca en el mismo directorio que el paquete anterior, en el servidor de administración de App-V, para que Word 2000 (word2K.sft) y Word 2000 SP3 (word2K_2.sft) acaben ubicándose en el mismo directorio. A continuación, el administrador usa la consola de administración de App-V para vincular estos dos archivos SFT.
En el cliente, los usuarios que tienen abierta una sesión de Word 2000 sin SP3 siguen operando con normalidad. Los usuarios que inician una sesión nueva de la aplicación después de que el administrador haya realizado la vinculación, recibirán un mensaje de que se ha detectado un cambio. El cliente, entonces, empieza a transmitir sólo los cambios delta entre word2K.sft y word2K_2.sft, de tal forma que actualiza automáticamente la aplicación a Word 2000 SP3.
Dada la naturaleza dinámica de las aplicaciones virtuales, revertir esta acción resulta también bastante fácil. Sólo necesita volver a ir a la consola de administración de App-V y quitar la última versión agregada. Esto hace que el cliente revierta a la versión anterior cuando vuelve a iniciar la aplicación. Para asegurarse de no cruzar datos de paquetes, el cliente purga automáticamente la memoria caché y vuelve a transmitir el archivo SFT adecuado. Se trata de un equilibrio justo si piensa en lo que debe hacerse para revertir una actualización de una aplicación que haya sido instalada físicamente con las herramientas de implementación de software más tradicionales.

Para poder apreciar las ventajas que ofrece App-V, debe crear paquetes de aplicaciones virtuales. Aquí es donde el secuenciador de App-V entra en juego. Todo el conocimiento y experiencia que tenga en el uso de scripts y en crear paquetes para herramientas de implementación de software tradicionales facilitarán su transición en secuencias. (En este punto debo indicar que el tema de las secuencias ya podría conformar un artículo por sí mismo.)
La mayoría de las soluciones de implementación de software dependen de scripts que capturan la manera en que una aplicación se instala y, a continuación, duplican el proceso en otros equipos, sin necesidad de acceder a cada uno de los equipos para instalar o actualizar las aplicaciones. Una vez que se ha instalado la aplicación, las herramientas de implementación de software habituales se deshacen del paquete. Después deberá instalar una dependencia en la que la aplicación pueda confiar, ejecutar otros scripts o realizar los pasos manuales para configurar la aplicación en función de sus necesidades.
El cambio fundamental de App-V es que el proceso de secuencias genera una imagen de una aplicación ya instalada y completa, con todas sus dependencias y configuraciones. Ésta puede "reproducirse" mediante el cliente de App-V sin necesidad de alterar el dispositivo en el que está siendo reproducida.
El secuenciador genera diversos archivos, el más importante de los cuales es el archivo SFT, que contiene todos los activos de la aplicación, las dependencias y la información de configuración. En algunos casos también puede contener múltiples aplicaciones. No es de extrañar, por tanto, que este archivo pueda llegar a ser bastante grande. Existen opciones de compresión, pero es necesario tener un sólido conocimiento de su rendimiento de red y del dispositivo. El archivo de icono (.ico) que el secuenciador crea se usa para anunciar la aplicación virtual. De esta forma, ésta actúa como si estuviera instalada de forma local.
El archivo OSD también es muy importante, y sus opciones son interminables. De forma predeterminada, es un archivo basado en XML que se usa para decirle al cliente de App-V cómo iniciar la aplicación virtual. El archivo OSD también puede modificarse para configurar y controlar cómo se inicia y se ejecuta la aplicación virtual. Le sugiero que consulte la guía del administrador de secuencias y las prácticas recomendadas de secuenciación para familiarizarse con las propiedades y valores disponibles en el archivo OSD.
Por último, el nuevo archivo manifest.xml contiene información de configuración basada en el paquete y puede usarse para la integración con soluciones ESD e implementaciones de MSI de terceros. El secuenciador también puede generar un archivo MSI para el paquete de aplicaciones virtuales. Éste puede usarse para cargar las aplicaciones virtuales en clientes independientes (sin servidor) y en un sistema ESD.
El propio secuenciador es una herramienta basada en asistente que guía al empaquetador a través del proceso de instalación de una aplicación y de su transformación en una aplicación virtual (consulte la figura 4). El primer paso le permite configurar las propiedades predeterminadas para el paquete. Estas propiedades, que se encuentran almacenadas en el archivo OSD, contienen el nombre y comentarios del paquete. Parte de la configuración avanzada le permite especificar el servidor desde el que se va a transmitir, el directorio de contenidos y qué sistemas operativos debe admitir el paquete.
Figura 4 El asistente de secuencias (haga clic en la imagen para ampliarla)
El segundo paso es instalar, configurar y probar la aplicación. Durante la instalación, el secuenciador captura todos los cambios hechos en el sistema local, incluidos el sistema de archivos, el registro y el sistema. Este asistente también contiene unas cuantas utilidades que permiten, por ejemplo, la integración con Windows Update.
El paso siguiente es configurar las asociaciones de tipos de archivos y especificar dónde deben colocarse los accesos directos. Las colocaciones estándar incluyen el menú Inicio, el escritorio y la barra de inicio rápido, si bien también puede crear ubicaciones personalizadas.
A continuación, debe iniciar la aplicación y configurar el umbral inicial. Éste es el momento en que App-V determina la parte inicial de la aplicación que necesita proporcionarse al cliente para que la aplicación pueda empezar a funcionar.
Para configurar este código inicial (normalmente denominado bloque de característica 1 (FB1)), sólo es necesario iniciar la aplicación y usar las características más habituales que necesitan los usuarios. Por ejemplo, abra Word y, a continuación, inicie el corrector ortográfico. Cualquier DLL, archivos o claves de registro llamadas por la aplicación durante esta fase pasan a ser designadas automáticamente como parte del FB1. Ningún archivo, configuración o componentes no usados hasta el momento se agregarán a FB2. Cuando por tanto se usa la aplicación, el cliente recibe un mapa del archivo SFT que indica dónde se inicia y se detiene el FB1, y dónde existen otros archivos en el FB2. De este modo, el cliente puede recuperar esos archivos cuando la aplicación lo requiera.
El paso final en el proceso de secuencias es asegurarse de que todo se ha configurado correctamente. El secuenciador muestra el diálogo que aparece en la figura 5, que representa el archivo SFT y permite hacer algunas adiciones o cambios finales al paquete.
Figura 5 Confirmación y ajuste de un paquete final (haga clic en la imagen para ampliarla)

Versión 4.5
Después que dos años en construcción, está previsto que App-V 4.5 salga al mercado hacia finales de este año. Ésta es la primera versión de Microsoft del producto que va a lanzarse al mercado, y promete incrementar la virtualización de aplicaciones introduciendo varias mejoras clave, tales como Dynamic Virtual Application Interaction, una escalabilidad prolongada y una alineación mejorada con los requisitos de internalización y de seguridad de Microsoft.
Dynamic Virtual Application Interaction permite que las aplicaciones virtualizadas interactúen entre sí. A esta interacción se la denomina Dynamic Suite Composition (DSC). DSC no reemplaza la capacidad de agregar múltiples aplicaciones en el mismo paquete. En lugar de eso, lo que hace es ofrecer una nueva manera de integrar las dependencias, software intermedio y complementos compartidos entre aplicaciones virtuales.
Los administradores pueden especificar qué aplicaciones virtualizadas pueden interactuar entre sí. Por ejemplo, supongamos que tiene cinco aplicaciones web que requieren la misma versión de Java. En App-V 4.1, tendría que agregar esa misma versión de Java a cada uno de los cinco paquetes por separado. Y supongamos que la versión de Java necesitaba una revisión. El administrador, por tanto, tendría que aplicar una revisión a los cinco paquetes. Con DSC, Java puede empaquetarse una vez y, a continuación, configurarse como un paquete para que las cinco aplicaciones web puedan usarlo. El resultado sería que al aplicar una revisión de Java sólo se requeriría que el administrador aplicara una revisión al paquete de Java una vez.
Lo mismo se aplica al software intermedio y los complementos. Tengo previsto crear un blog acerca de otros casos que puedan darse a medida que Microsoft avanza en el lanzamiento del producto y finaliza cualquier adición posterior.
Las mejoras de escalabilidad afectan tanto a la transmisión por secuencias como a la infraestructura del back-end. Los componentes del back-end han sido modificados para que puedan ser más compatibles con los clústeres y las situaciones de conmutación por error, y la transmisión por secuencias es más compatible con las redes WAN y LAN. Las mejoras proceden de varias adiciones que resultan clave.
Primero está el nuevo componente del servidor de transmisión, que permite la transmisión por secuencias sin necesidad de disponer de una infraestructura de back-end de Active Directory o SQL Server. Aun así, se obtienen todas las grandes ventajas de la entrega a petición y de la actualización centralizada de paquetes, pero no hay necesidad de tener que cumplir con los difíciles requisitos del back-end. Esto se usará extensamente en escenarios de sucursales y para la integración de soluciones ESD de terceros.
También en el cliente de App-V se han introducido algunas mejoras. Ahora, por ejemplo, el cliente almacena toda la información de uso a nivel local, de tal forma que esta información puede ser rastreada tanto si el sistema cliente está conectado a la red o no. La memoria caché del cliente también ha sido ampliada y mejorada para que pueda proporcionar un mejor rendimiento en escenarios con espacio en disco limitado. Asimismo, ahora también se ofrece soporte técnico para la secuenciación de las aplicaciones en otros idiomas diferentes del inglés, la ejecución de App-V en sistemas operativos en idiomas diferentes del inglés y su localización en otros lenguajes.

Integración de App-V con el Administrador de configuración
Para hacer posible la integración de App-V en SCCM 2007 R2, se han diseñado varias mejoras y nuevas características en la versión 4.5. Como apunté anteriormente, la virtualización y la transmisión por secuencias ofrecen algunas capacidades para distribuir aplicaciones que las herramientas de implementación de software tradicionales no proporcionan. No quiero decir con eso que App-V va a reemplazar a estas herramientas, sino más bien que App-V puede complementarlas y ampliarlas.
Con esta integración, el usuario obtiene toda la escalabilidad, la creación de informes, el reconocimiento de dispositivos y las características de la red WAN de SCCM, además de todas las características de transmisión por secuencias y aislamiento de App-V. Aquí se muestran algunas de las áreas que se benefician de la integración de estas dos tecnologías:
Distribución de aplicaciones La integración de SCCM R2 es compatible con todas las capacidades de la entrega a petición, las aplicaciones de movilidad, los umbrales iniciales y la implementación de aplicaciones sin alterar los PC cliente.
Actualización de SCCM Al actualizar los paquetes, los puntos de distribución (DP) solamente pueden implementar los cambios delta de las aplicaciones virtuales. Esto introduce la capacidad centralizada de revertir las aplicaciones virtualizadas a versiones anteriores mediante un solo clic.
Administración La versión R2 introdujo un nuevo asistente de anuncios para las aplicaciones virtuales que permite a los administradores implementar aplicaciones virtualizadas, así como paquetes de software tradicionales y anuncios desde una sola consola.
Empaquetado Cuando se integra App-V con SCCM, no hay necesidad de volver a empaquetar las aplicaciones. La secuencia inicial de una aplicación debe hacerse con la secuencia de App-V fuera de SCCM, no obstante, los administradores también pueden actualizar los paquetes existentes con SCCM.
Licencias Las aplicaciones virtuales pueden ser rastreadas en busca de licencias y para medición con las herramientas de SCCM.
BITS SCCM ofrece un método nuevo para implementar las aplicaciones virtualizadas en App-V mediante el protocolo BITS estándar. Aunque los puntos de distribución de SCCM pueden transmitirse en secuencias, hay casos donde la transmisión en secuencias no es el método más adecuado para implementar las aplicaciones virtualizadas. Al realizar implementaciones a través de SCCM, hay dos opciones. Puede usar la transmisión por secuencias estándar o puede usar las características de Calidad de servicio (QoS) de BITS, para poder realizar la implementación de una forma mucho más controlada. Esto resulta también útil en situaciones en las que desee cargar previamente la memoria caché antes de que los usuarios inicien la aplicación virtual.
Implementaciones de equipos SCCM ofrece la capacidad de implementar las aplicaciones virtualizadas en equipos específicos, además de seguir siendo compatible con el método orientado al usuario de la plataforma App-V. Esto puede resultar útil cuando se implementan aplicaciones virtuales en equipos portátiles, quioscos y en equipos de laboratorio. Esto también resulta práctico para el control de la licencia para los casos en que su software pueda obtener la licencia a través de un dispositivo, y no de los usuarios denominados.
Escalabilidad La necesidad de implementar dos herramientas por separado que tienen mucho solapamiento es una de las preocupaciones habituales. Al integrar las ventajas de la escalabilidad y de la red WAN de SCCM con las ventajas del aislamiento y la transmisión por secuencias de App-V, el usuario podrá usar su SCCM, el cual incluye una sola herramienta para controlar tanto la administración como la implementación, sin necesidad de tener que añadir más complejidades.

Anthony Kinney es responsable de los técnicos en ventas profesionales de Microsoft Desktop Optimization Pack. Anthony llegó a Microsoft en 2006 cuando se compró Softricity. Cuando trabajaba en Softricity, Anthony escribió y diseñó el primer programa de aprendizaje para SoftGrid (hoy App-V). Puede ponerse en contacto con él a través de Anthony.kinney@microsoft.com.


virtualización
Obtención de alta disponibilidad para Hyper-V
Steven Ekren
De un vistazo:
  • Consolidación de servidores mediante Hyper-V
  • Cómo asegurar una alta disponibilidad de las máquinas virtuales
  • Configuración de una conmutación por error en Windows Server 2008

Contenido
Alta disponibilidad
Hosts e invitados
Disponibilidad de los invitados
Cómo hacer que las MV tengan una alta disponibilidad
Requisitos previos
Análisis pormenorizado de la alta disponibilidad
Consideraciones
La virtualización del servidor está pensada para tener una repercusión considerable en los departamentos de TI de las empresas. Hyper-V junto con Windows Server 2008 pueden hacer que eso sea una realidad. La consolidación de servidores en menos equipos físicos presenta enormes ventajas para el ahorro de recursos y costos, pero, durante el proceso de planificación, es necesario tener en cuenta dos factores clave. Los usuarios tienen cada vez más expectativas en la disponibilidad de su software, incluyendo tanto las aplicaciones como las herramientas de línea de negocios (LOB) tales como las plataformas de mensajería y de colaboración. Además, los problemas o errores en servidores pueden tener una repercusión bastante significativa sobre las operaciones. Windows Server 2008 y Hyper-V proporcionan tanto soluciones que pueden implementarse de tal manera que presenten una alta disponibilidad de las máquinas virtuales (MV), como para las cargas de trabajo alojadas en éstas.

Alta disponibilidad
Disponibilidad significa que los usuarios pueden tener acceso a un sistema para llevar a cabo su trabajo. Con una alta disponibilidad, hay bastantes posibilidades de que los usuarios puedan gozar siempre de acceso al sistema, ya que ha sido diseñada e implementada para asegurar una continuidad operativa.
La alta disponibilidad de Hyper-V se consigue a través de la característica de clúster de conmutación por error de Windows Server 2008. La alta disponibilidad está influenciada por el tiempo de inactividad planificado y no planificado, y el clúster de conmutación por error puede aumentar de manera significativa la disponibilidad de las máquinas virtuales en estas dos categorías.
Las máquinas virtuales pueden administrarse mediante el clúster de conmutación por error, y éste puede usarse dentro de las máquinas virtuales para supervisar y transferir las cargas de trabajo alojadas en la máquina virtual. En este artículo voy a describir ambos escenarios de configuración con más detalle, pero la gran parte versará sobre la administración de las máquinas virtuales. Antes de empezar, sin embargo, quizás desee echar un vistazo a los "Términos útiles sobre Hyper-V" en la barra lateral.

Hosts e invitados
Puesto que hay múltiples sistemas operativos ejecutándose en un sistema Hyper-V, averiguar de qué capa o sistema operativo estamos hablando puede llegar a ser todo un desafío. Usaré el término "invitado" para referirme al sistema operativo y entorno dentro de una máquina virtual Hyper-V que se está ejecutando en una partición secundaria. Y usaré el término "host" para indicar el equipo físico que esté siendo administrado por el sistema operativo en la partición primaria Hyper-V.
La disponibilidad del host aborda los problemas que se presentan con el escenario de "poner todos los huevos en la misma cesta" que la consolidación de servidores puede causar. El clúster de conmutación por error de Windows Server 2008 puede configurarse en la partición primaria Hyper-V (host) para que particiones secundarias Hyper-V (máquinas virtuales o invitados) puedan supervisarse para comprobar su estado y moverse entre nodos del clúster. Esta configuración tiene las siguientes ventajas clave:
  • Si el equipo físico en el que se ejecutan Hyper-V y la máquina virtual necesita actualizarse, modificarse o reiniciarse, las MV pueden moverse a otros nodos del clúster. Luego, las máquinas virtuales pueden volver a su lugar de origen una vez que el equipo físico vuelva a funcionar.
  • Si el equipo físico en el que Hyper-V y las máquinas virtuales se están ejecutando genera algún error (quizás un error de la placa base) o se degrada notablemente, los otros miembros del clúster de conmutación por error de Windows tomarán posesión de la máquina virtual y los conectarán automáticamente.
  • Si la máquina virtual genera algún error, podrá reiniciarse en el mismo servidor Hyper-V o moverse a otro servidor Hyper-V. Desde el momento en que el clúster de conmutación por error de Windows Server lo detecta, automáticamente se adoptan los pasos de recuperación basados en la configuración de las propiedades de los recursos de las máquinas virtuales. El tiempo de inactividad se minimiza debido a la detección y automatización de la recuperación.
La figura 1 representa lo que podría ocurrir en dichas situaciones. En primer lugar, la MV2 se encuentra en el host A y, a continuación, la MV2 se traslada al host B. Tenga en cuenta que el nodo que posee el almacenamiento SAN de LUN 2 cambia del host A al host B durante este traslado. Para asegurar que su solución de alta disponibilidad satisface sus necesidades de disponibilidad, piense bien dónde instalará la máquina virtual. Deberá tener en cuenta tanto la capacidad como el rendimiento.
Figura 1 Una máquina virtual y su almacenamiento se mueven a un nuevo host (haga clic en la imagen para ampliarla)
La capacidad de los nodos debe ser suficiente para alojar a todas las máquinas virtuales y permitir que un número x de nodos generen error o no colaboren en la participación activa del clúster. (X representa el número de nodos cuya pérdida puede ser soportada por el clúster y a la vez poder alojar a todas las máquinas virtuales. Al decidir la capacidad, puede seleccionar tener algunos nodos que generalmente no alojan máquinas virtuales y mantenerlos en reserva. También puede propagar las máquinas virtuales en todos los nodos, pero deberá asegurarse de que cada uno tiene suficiente capacidad adicional para poder tomar posesión correctamente e iniciar las máquinas virtuales si un número x de nodos generase error.
Por motivos de rendimiento diario, puede resultar más conveniente propagar las máquinas virtuales a todos los nodos del clúster. Si los nodos se mantienen en reserva y no hospedan ninguna máquina virtual, entonces los nodos que hospedan las máquinas virtuales tendrán más recursos en uso, lo que puede disminuir su rendimiento, además de la partición de la administración. La propagación de las máquinas virtuales a todos los nodos reduce la carga que cada uno debe asumir, y eso proporciona mayor rendimiento a las máquinas virtuales y a las particiones de administración. Sin embargo, puede hacer que la planificación de la capacidad sea más complicada. El software de administración, como System Center Virtual Machine Manager 2008, puede resultar de gran ayuda, ya que ofrece cálculos de la capacidad de error de los nodos y de la ubicación de la máquina virtual.

Disponibilidad de los invitados
La disponibilidad de los invitados se basa en hacer que la carga de trabajo que está siendo ejecutada dentro de una máquina virtual goce de una alta disponibilidad. Las cargas de trabajo comunes incluyen servidores de archivo y de impresión, IIS y aplicaciones LOB. El análisis de las necesidades y soluciones de alta disponibilidad para cargas de trabajo en las máquinas virtuales es casi el mismo que el que se hace en servidores independientes. Esta solución dependerá de la carga de trabajo específica.
Algunas cargas de trabajo pueden lograr una alta disponibilidad mediante el equilibrio de carga de red de Windows (NLB), que permite que varios servidores formen parte de un grupo con un nombre de red común. Los clientes hacen una solicitud para realizar una conexión con ese nombre de red virtual, y la conexión se hace para uno de los nodos del clúster NLB. Un escenario típico que usa el clúster NLB es la creación de granjas de servidores web con IIS, en donde cada sistema individual tiene IIS con las mismas páginas web y acceso a los mismos datos. NLB ofrece equilibrio de carga, así como la capacidad de eliminar servidores del grupo para su mantenimiento o por si sucede algún problema con el servidor y, por lo tanto, ofrece un nivel de alta disponibilidad. Si una máquina virtual Hyper-V está ejecutando Windows Server 2008 (o una versión anterior de Windows Server que incluye NLB), el invitado puede ser un miembro de un clúster NLB con otros invitados en el mismo host Hyper-V o en uno diferente.
Los invitados que ejecutan Windows Server 2008 pueden usar la característica del clúster de conmutación por error de Windows para poder ofrecer una alta disponibilidad a sus cargas de trabajo. El uso de los clústeres de conmutación por error de Windows dentro de un invitado (clúster de invitado) presenta varias ventajas:
Supervisión del estado de la carga de trabajo El clúster de conmutación por error de Windows dispone de un monitor de recursos que hace llamadas a la DLL del recurso asociada con el clúster. Cada recurso realiza una supervisión del estado que prueba la aplicación o el servicio que el recurso está administrando para asegurarse de que funciona correctamente. Estas comprobaciones se denominan habitualmente comprobaciones isAlive/looksAlive. Si el recurso produce un error en alguna de estas llamadas, el propio recurso también fallará. Dependiendo de cómo se hayan configurado sus propiedades, el recurso podría intentar reiniciar el servicio o aplicación, o podría moverse a otro nodo en el clúster de conmutación por error de Windows.
Mantenimiento de las máquinas virtuales Si es necesario cambiar la configuración de las máquinas virtuales, o si es necesario actualizar o cambiar el sistema operativo o el software, la carga de trabajo puede transferirse a otro nodo del clúster, y las máquinas virtuales pueden apagarse o actualizarse ocasionando a los usuarios finales una mínima interrupción.
Mantenimiento del equipo host Si el equipo físico que hospeda la máquina virtual Hyper-V necesita actualizaciones de mantenimiento o de software, y otros miembros del clúster de conmutación por error de Windows están ubicados en diferentes hosts Hyper-V, la carga de trabajo en la máquina virtual puede trasladarse a otro nodo del clúster y esa máquina virtual puede apagarse para acomodar los cambios o reinicios del servidor físico.
Error de la máquina virtual o del equipo host Si ocurre algún error procedente del host físico Hyper-V o del invitado de la máquina virtual, los otros nodos del clúster de conmutación por error de Windows detectarán que el miembro del clúster ya no responde ni participa en el clúster y los nodos supervivientes pondrán en línea las aplicaciones o los servicios que se habían estado ejecutando en las máquinas virtuales con errores.

Términos útiles sobre Hyper-V
A continuación, mostramos una lista de los términos que ayudan a definir los componentes o las funciones de un sistema Hyper-V de alta disponibilidad (clúster del host).
Partición primaria Todos los sistemas operativos que se ejecutan en un servidor basado en hipervisor han asignado recursos de hardware entre los que se incluyen la RAM, CPU y otros componentes del sistema. En Hyper-V, a menudo se hace referencia a la partición que administra la configuración del hipervisor y de los recursos del sistema como partición primaria. Al configurar la función de Hyper-V y reiniciar el servidor, la instalación de Windows Server 2008, que era el sistema operativo nativo en el sistema, pasa a ser el sistema operativo de la partición primaria del servidor Hyper-V.
Partición secundaria Entorno aislado en un servidor Hyper-V que se configura para mantener un sistema operativo invitado y ofrecer recursos de hardware a ese sistema operativo.
Host Hyper-V El servidor físico que hospeda Hyper-V y el sistema operativo que se ejecuta dentro de la partición primaria.
Máquina virtual Hyper-V La información de configuración de Hyper-V y los datos que se usan para iniciar y ejecutar una partición secundaria Hyper-V. Esto incluye la información de configuración para crear la partición secundaria y los archivos VHD o discos passthrough que contienen sus datos.
Disco passthrough Dispositivo de almacenamiento expuesto en la Administración de discos como un disco físico asignado para uso exclusivo de un invitado Hyper-V. El invitado Hyper-V monta el disco y lo usa como un dispositivo de almacenamiento conectado de forma local.
Disco duro virtual (VHD) Archivo que está conectado por una partición secundaria Hyper-V expuesta al sistema operativo como un dispositivo de almacenamiento (disco). El archivo .vhd se encuentra ubicado en un dispositivo de almacenamiento montado por la partición primaria y puede tratarse de un dispositivo de almacenamiento conectado directamente, o bien el almacenamiento que está conectado a redes SAN, NAS o SMB.
Cómo hacer que las MV tengan una alta disponibilidad
Configurar una máquina virtual para que goce de una alta disponibilidad es tan sencillo como usar el asistente para funciones de alta disponibilidad en la Administración del clúster de conmutación por error. Las máquinas virtuales Hyper-V tienen varios componentes clave que deben tenerse en cuenta al administrarse como altamente disponibles. Veamos algunos conceptos importantes y requisitos previos generales.
Nodos del clúster de conmutación por error Cada servidor físico que forma parte de un clúster de conmutación por error se denomina nodo. Para agrupar los clústeres del host, el servicio del clúster de conmutación por error se ejecuta en Windows Server 2008, en la partición primaria del sistema Hyper-V. Esto permite que las máquinas virtuales que se ejecutan en particiones secundarias en los mismos servidores físicos se configuren como máquinas virtuales de alta disponibilidad. Las máquinas virtuales que se configuran para obtener una alta disponibilidad se muestran como recursos en la consola de administración del clúster de conmutación por error.
Almacenamiento de alta disponibilidad Las máquinas virtuales de alta disponibilidad pueden configurarse de forma que puedan usarse discos duros virtuales (VHD), discos passthrough y discos de diferenciación. Para habilitar el movimiento de máquinas virtuales entre los nodos de los clústeres de conmutación por error, se necesita capacidad de almacenamiento (en forma de discos en Administración de discos) accesible a través de cualquier nodo que pueda hospedar la máquina virtual y que esté administrado por el servicio del clúster de conmutación por error. Los discos passthrough deben agregarse al clúster de conmutación por error como recursos del disco, y los archivos VHD deben encontrarse en discos que se agreguen al clúster de conmutación por error como recursos del disco.
Recurso de la máquina virtual Es un tipo de recurso del clúster de conmutación por error que representa la máquina virtual. Cuando se pone en conexión el recurso de la máquina virtual, Hyper-V crea una partición secundaria y el sistema operativo se inicia en la máquina virtual. La función sin conexión del recurso de la máquina virtual elimina la máquina virtual Hyper-V en el nodo donde se hospedó y la partición secundaria se elimina del host Hyper-V. Si la máquina virtual se encuentra apagada, detenida o en estado guardado, este recurso pasará a estado sin conexión.
Recursos de configuración de la máquina virtual Es un tipo de recurso del clúster de conmutación por error que se usa para administrar la información de configuración de una máquina virtual. Existe un recurso de configuración para cada máquina virtual. Una propiedad de este recurso contiene la ruta al archivo de configuración que contiene toda la información necesaria para agregar la máquina virtual al host Hyper-V. El acceso al archivo de configuración es necesario para iniciar los recursos de la máquina virtual. Puesto que la configuración se administra mediante un recurso separado, la configuración de los recursos de las máquinas virtuales puede modificarse aunque las máquinas virtuales no estén conectadas.
Servicios de máquinas virtuales y grupos de aplicaciones Para que un servicio o aplicación tenga una alta disponibilidad en todos los clústeres de conmutación por error, varios recursos deben hospedarse en el mismo nodo del clúster de conmutación por error. Para asegurarse de que estos recursos están siempre en el mismo nodo y de que interoperan correctamente, los recursos se almacenan en un grupo al que el clúster de conmutación por error de Windows Server 2008 se referirá como "Servicio o Aplicación". El recurso de la máquina virtual y el recurso de configuración de la máquina virtual están siempre en los mismos grupos de servicios o de aplicaciones. También puede haber uno o más recursos de disco físico (u otro tipo de almacenamiento) que contengan VHD, archivos de configuración o discos passthrough en un grupo de servicios o de aplicaciones.
Dependencias de recursos Es importante asegurarse de que el recurso de configuración de la máquina virtual está conectado antes de que el recurso de la MV se conecte (iniciado), y de que el recurso de configuración de la máquina virtual se desconecta una vez que el recurso de la MV se ha desconectado (detenido). La configuración de las propiedades del recurso de la máquina virtual para que sea dependiente del recurso de configuración de la máquina virtual asegura este orden de conexión o desconexión. Si hay algún recurso de almacenamiento que contiene el archivo del recurso de configuración de la máquina virtual o del recurso de la máquina virtual, dicho recurso deberá hacerse dependiente de estos recursos de almacenamiento. Por ejemplo, si la máquina virtual usa los archivos VHD que hay en el disco G: y el disco H:, el recurso de la máquina virtual debería ser dependiente del recurso del archivo de configuración y del recurso para el disco G: y el recurso para el disco H:.

Requisitos previos
A continuación se muestran los tres requisitos previos para hacer que las máquinas virtuales Hyper-V presenten alta disponibilidad mediante la característica del clúster de conmutación por error de Windows Server 2008:
  1. 1. La característica del clúster de conmutación por error de Windows Server 2008 debe configurarse para cada nodo del clúster. Para obtener más información sobre la configuración y administración de los clústeres de conmutación por error, consulte "Recursos de Hyper-V" en la barra lateral.
  2. 2. Debe instalarse la función de Hyper-V. Las actualizaciones de Hyper-V deben instalarse así como la función configurada para cada nodo del clúster de conmutación por error (de nuevo, consulte "Recursos de Hyper-V" en la barra lateral). Hyper-V dispone de un paquete de actualización que instala los componentes del servidor Hyper-V y otro que instala la consola de administración de Hyper-V. Una vez que la actualización se ha instalado para los componentes del servidor Hyper-V, la función puede agregarse a través del Administrador de servidores o de ServerManagerCMD.
  3. 3. Deberá disponer de almacenamiento compartido en las máquinas virtuales. El almacenamiento puede ser administrado por el clúster de conmutación por error como un tipo de recurso de disco físico integrado, o bien puede usar una solución de terceros para administrar el almacenamiento compartido. Por supuesto, la solución de terceros debe ser compatible con los clústeres de conmutación por error de Windows Server 2008.

Análisis pormenorizado de la alta disponibilidad
Ahora veamos cómo se configura una solución de alta disponibilidad. El primer paso es configurar una máquina virtual. En uno de los nodos del clúster de conmutación por error que tiene la función de Hyper-V instalada, configure una máquina virtual mediante el Administrador de Hyper-V (consulte la figura 2). Puede ser una máquina virtual nueva que configure manualmente, o puede importar una que ya exista. Los VHD deben ubicarse en un disco administrado por el clúster de conmutación por error de Windows Server 2008 y que en esos momentos esté conectado en el nodo en el que la máquina virtual se ha configurado.
Figura 2 Configuración de una máquina virtual (haga clic en la imagen para ampliarla)
Ahora, ponga la máquina virtual en estado detenido, apagando, desactivando o guardando dicho estado. Sólo las máquinas virtuales que se encuentran en estado detenido pueden ser administradas por el clúster de conmutación por error.
Abra la consola del administrador del clúster de conmutación por error (se muestra en la figura 3) en cualquier servidor que esté ejecutando la función del clúster de conmutación por error en Windows Server 2008, o en un cliente de Windows Vista que ejecute las Herramientas de administración remota de servidores (RSAT). Conéctese al clúster de conmutación por error seleccionando la acción "Administrar un clúster..." y, a continuación, seleccione un nodo o el nombre del clúster, o bien la opción para conectarse al clúster en el nodo en el que la consola se esté ejecutando.
Figura 3 Máquina virtual en el administrador del clúster de conmutación por error (haga clic en la imagen para ampliarla)
Desde la consola del administrador del clúster de conmutación por error, seleccione la acción "Configurar un servicio o aplicación…". Esto abrirá el asistente para alta disponibilidad, que le guiará a través de la configuración de los servicios, aplicaciones o máquinas virtuales, que deben ser administrados por el clúster de conmutación por error. En la página del asistente Seleccionar servicio o aplicación, seleccione la máquina virtual y, a continuación, seleccione Siguiente.
La página Seleccionar máquina virtual mostrará todas las máquinas virtuales que se hayan configurado en algún nodo del clúster de conmutación por error. Seleccione la máquina virtual y, a continuación, seleccione Siguiente. La página Confirmación del asistente le mostrará si existen advertencias o errores. Llegados a este paso, se comprueba la configuración de la máquina virtual para comprobar que puede configurarse como un recurso de alta disponibilidad y que los nodos puedan hospedarla. Al seleccionar Siguiente, se agregará la máquina virtual al clúster de conmutación por error como un recurso de alta disponibilidad.
La página Resumen ofrece información acerca de las consecuencias de agregar la máquina virtual como un recurso de alta disponibilidad, incluidas algunas advertencias. El botón Ver informe… le muestra los detalles de las tareas que se llevaron a cabo para hacer que la máquina virtual goce de una alta disponibilidad, además de las advertencias o errores que puedan generarse. Por último, seleccione Finalizar para cerrar el asistente para alta disponibilidad.
Como muestra la ventana en la figura 3, la consola del administrador del clúster de conmutación por error enumerará el objeto con el nombre predeterminado de la máquina virtual (x) en el panel izquierdo, bajo el nombre del clúster y de los servicios o aplicaciones. Seleccione la máquina virtual desde esa estructura de árbol, y los recursos que forman parte de esos grupos de servicios o aplicaciones se mostrarán en el panel central de la consola. Si cualquier otra máquina virtual tuvo sus archivos en el mismo almacenamiento que la seleccionada, también se agregará al grupo. La máquina virtual y los recursos de configuración de la máquina virtual se mostrarán con respecto a cada máquina virtual del grupo.
El panel de información del grupo de servicios o de aplicaciones muestra la información del grupo sobre el estado, las alertas, los propietarios preferidos y el propietario actual. El nodo Propietario es el nodo en donde la máquina virtual se configura o se está ejecutando. Seleccione la acción de mover las máquinas virtuales a otro nodo para desconectar la máquina virtual y conectarla a otro nodo. Ésta es, en general, una práctica que se recomienda para trasladar máquinas virtuales a cada nodo que puede hospedarlas en el clúster de conmutación por error, y así comprobar que el traslado se ha realizado correctamente y que las máquinas virtuales se iniciarán y ejecutarán correctamente.

Recursos de Hyper-V
  • Descripción de la actualización para la versión final de la tecnología Hyper-V para Windows Server 2008
  • Guía paso a paso de Hyper-V: Pruebas para Hyper-V y los clústeres de conmutación por error
  • Introducción a Windows Server 2008 Failover Clustering (por Chuck Timon, TechNet Magazine, julio de 2008)
  • El host de NLB no converge como estaba previsto en las máquinas virtuales Hyper-V de Windows Server 2008
  • Webcasts de clústeres de Win2008
  • Directiva de soporte de Microsoft para los clústeres de conmutación por error de Windows Server 2008
Consideraciones
A continuación se muestran algunos puntos clave que conviene tener presente al configurar las máquinas virtuales para obtener una alta disponibilidad:
Almacenamiento Si las máquinas virtuales disponen de archivos VHD en el mismo disco compartido, incluso si se ubican en volúmenes diferentes en el mismo disco, se ubicarán en el mismo grupo de servicios o de aplicaciones. Una de las ventajas de compartir el disco es que permite mejor uso del espacio de almacenamiento compartido disponible.
Sin embargo, el equilibrio está en que en cualquier momento en el que se traslada una máquina virtual, ya sea por motivos de una recuperación automatizada después de un problema con ésta o por causa de la selección de un administrador, todas las máquinas virtuales del grupo también serán trasladadas.
Letras de unidad y GUID Los volúmenes pueden crearse sin necesidad de asignarles letras de unidad. Las máquinas virtuales pueden usar estos volúmenes, que pueden administrarse a través del clúster de conmutación por error. Si un recurso de disco contiene volúmenes que usan GUID en lugar de letras de unidad, el GUID se mostrará en la Administración del clúster. Al crear máquinas virtuales y especificar la ruta de acceso a los archivos VHD, es muy importante asegurarse de que el GUID en la ruta de acceso coincide con el GUID que se muestra en la Administración del clúster para el volumen. Si no coincide, la máquina virtual no puede iniciarse correctamente (conectarse) en otros nodos del clúster de conmutación por error.
Hay varias situaciones que podrían hacer que los GUID no coincidan. Si un volumen se conectó a los nodos antes de que éstos fueran agregados como un recurso de conmutación por error administrado por disco, el volumen puede contener un GUID diferente en cada nodo. Asimismo, es posible que un volumen contenga múltiples GUID en un solo nodo. Cuando se agrega un disco a un clúster de conmutación por error como un recurso de disco físico, los GUID de volumen que están en uso en el nodo que tiene los discos conectados se anotarán en las propiedades para el recurso de disco.
Los GUID para los volúmenes se agregarán a un nodo al conectar el recurso de disco. Esto asegura que el GUID específico que el clúster de conmutación por error haya anotado para el volumen es una ruta de acceso válida en cualquier nodo que pone en conexión al disco. Ese nodo puede tener otros GUID que también están asociados con el mismo volumen. Por lo tanto, un usuario puede encontrar un GUID que sea válido para el volumen en ese nodo, pero no es el mismo GUID que el clúster de conmutación por error asegura se usa para el volumen en otros nodos. Las consecuencias que puede ocasionar este problema son que un recurso de la máquina virtual, generalmente el recurso de configuración, genere algún error al conectarse y muestre un mensaje de error indicando que la ruta de acceso no es válida. La ruta de acceso que contiene el mensaje de error muestra qué GUID no es el administrado por el clúster para el volumen.
Puntos de montaje Los volúmenes que se montan en una carpeta en otro volumen, en vez de asignar una letra de unidad o de usar un GUID, son válidos para usarse con Hyper-V y los clústeres de conmutación por error. Puesto que el volumen que se monta y el volumen que hospeda el punto de montaje deben estar en el mismo nodo del clúster de conmutación por error, debe tener todos los discos que forman parte del punto de montaje en el mismo grupo de servicios o aplicaciones que el clúster de conmutación por error.
Si los volúmenes se encuentran en los mismos discos, por supuesto, no supondrá ningún problema. Sin embargo, lo que sí es un problema es que los volúmenes se encuentren en discos diferentes. También es algo obvio, pero aun así vale la pena mencionarlo, que el volumen que se monta y el host del punto de montaje deben formar parte del almacenamiento compartido que se configura para ser administrado por el clúster de conmutación por error.
Discos de diferenciación Todos los archivos VHD que forman parte de los discos de diferenciación deben encontrarse en almacenamiento compartido en los mismos grupos de servicios o de aplicaciones que las máquinas virtuales que usan los discos de diferenciación. En su configuración más sencilla, un disco de diferenciación contiene dos VHD. Un VHD es el disco principal y cuenta con un conjunto de datos que se usan como base. El otro VHD es un disco secundario asociado al principal.
Cuando se usa por primera vez, el disco de diferenciación se parece al principal. Si los datos se ubican en el VHD principal, se leen desde ese archivo VHD. Las escrituras tienen todas lugar en el VHD secundario. Si los datos se encuentran en el VHD secundario, entonces la lectura de esos datos hará referencia al VHD secundario.
Si una máquina virtual se configura de tal forma que el VHD secundario se encuentra en un almacenamiento compartido pero el VHD primario no está en almacenamiento compartido en el mismo grupo ni en el dispositivo de almacenamiento asociado localmente, al trasladar la MV a otro nodo, dicha máquina virtual generará un error al iniciarse (conectarse). El asistente para alta disponibilidad deberá comprobar que se ha configurado correctamente en la máquina virtual, y generar un mensaje de error si detecta este problema. Sin embargo, conviene tener en cuenta este requisito en el caso de que la configuración de las máquinas virtuales cambie.

Steven Ekren es administrador jefe de programas en el equipo de clústeres de conmutación por error de Windows Server y alta disponibilidad. Steven pasó 12 años con el equipo de soporte técnico de Microsoft, donde ayudó a los clientes corporativos a realizar sus implementaciones y a solucionar los problemas procedentes de los clústeres de conmutación por error de Windows Server y de las tecnologías de virtualización, incluidos Windows Hyper-V, System Center Virtual Machine Manager, Microsoft Virtual Server y Microsoft PC Virtual.


virtualización
Copia de seguridad y recuperación ante desastres para la virtualización de servidores
Adam Fazio
De un vistazo:
  • Consideraciones para la planificación de la recuperación ante desastres
  • Soluciones de alta disponibilidad para la recuperación ante desastres
  • Copia de seguridad y restauración con copia de seguridad de Windows Server

Contenido
Planificación de la recuperación ante desastres 101
Recuperación ante desastres y virtualización
Conversión de físico a virtual
Instantáneas de máquina virtual
Copia de seguridad de Hyper-V
Copia de seguridad de Windows Server
Copia de seguridad de máquinas virtuales con WSB
Consideraciones
Restauración de máquinas virtuales con WSB
Administrador de protección de datos
Copias de seguridad con scripts
DiskShadow
Conclusión
A medida que evoluciona la tecnología de virtualización de servidor y aumenta su adopción en la industria, las organizaciones reconocen los beneficios, que van mucho más allá de la justificación más popular para la virtualización: costos de infraestructura reducidos y aumento de la agilidad de TI. El paso siguiente consiste en usar la plataforma de virtualización como forma de habilitar o mejorar las estrategias de recuperación ante desastres (DR).
¿Por qué la preparación para la recuperación ante desastres es uno de los temas más candentes del sector de TI? Los estudios sugieren que las compañías pierden un promedio de 80.000 a 90.000 dólares por hora de tiempo de inactividad, y que muy pocas compañías que sufren una pérdida de datos catastrófica sobreviven a largo plazo. Este artículo ofrece una introducción a la recuperación ante desastres a través de la plataforma de virtualización de Microsoft, además de un examen más profundo de las opciones de copia de seguridad y restauración, y consideraciones para Windows Server 2008 Hyper-V.

Planificación de la recuperación ante desastres 101
DR es el proceso de restauración de los servicios críticos en caso de interrupción y debe ser una parte del plan de continuidad empresarial de cada compañía, que define cómo la compañía continuará funcionando durante o después de producirse un desastre así. Estos planes son la piedra angular de cualquier iniciativa de recuperación ante desastres.
Algunos proveedores afirman que su tecnología de automatización de recuperación ante desastres minimiza o evita la necesidad de un plan detallado y bien ensayado. Aunque es justo decir que esa automatización puede mejorar los tiempos de recuperación y disminuir la dependencia de la intervención humana, vamos a hacer una pausa para hacer un anuncio público: no puede mitigar correctamente un desastre sólo con la tecnología. Las personas y los procesos son siempre tan importantes como las tecnologías.
De hecho, resulta casi imposible seleccionar las tecnologías correctas sin conocer primero todas las restricciones y los objetivos que surgen del proceso de planificación de recuperación ante desastres. Queda fuera del ámbito de este artículo definir un plan entero de recuperación ante desastres, pero me gustaría poner énfasis en los elementos necesarios para seleccionar las tecnologías e implementaciones correctas. Vamos a resumir rápidamente algunos controladores de tecnología críticos dentro de un plan de recuperación ante desastres.
Definiciones de servicio y priorización ¿Qué es lo que define exactamente el servicio que está intentando proteger y cuán crítico es para la organización? La figura 1 muestra ejemplos de los servicios de la compañía que probable se incluirían en cualquier plan de recuperación ante desastres.
Figura 1 Definiciones de servicio y ejemplo de priorización
Servicio | Componentes principales | Dependencias | Uso empresarial | CONTRATO DE NIVEL DE SERVICIO
Sitio web público | Un equilibrador de carga de la red, tres servidores web, dos servidores de base de datos | DNS, red, firewall, directorio, almacenamiento en red de área de almacenamiento (SAN) | Compra de productos y seguimiento de órdenes; comercio electrónico; portal de soporte técnico a clientes; información de compañía | 99.99%
Sistema financiero | Dos servidores de base de datos, un servidor de aplicaciones | DNS, red | Registro de los ingresos de la compañía, tal y como requieren las leyes y regulaciones | 99.99%
Sistema de correo electrónico | Tres servidores de correo electrónico, un servidor web | DNS, red, firewall, directorio | Comunicación de compañía; soporte técnico de cliente | 99.5%
Una vez definidos los servicios, puede empezar a identificar qué sistemas y dependencias seleccionar para cada clase de estrategia de recuperación ante desastres. Es posible que después de examinar el conjunto entero de servicios y dependencias crea que debe tener en cuenta unos niveles distintos de capacidad de recuperación ante desastres, ya que una solución única de recuperación ante desastres para todos los servicios críticos sería demasiado cara y compleja.
Contratos de nivel de servicio (SLA) Un contrato de nivel de servicio es un acuerdo o contrato entre el proveedor de servicios (TI) y el cliente (la organización) que define la disponibilidad de objetivos para un servicio determinado. Éstos pueden ser muy largos o bien cortos y concisos; por ejemplo, "El sistema de correo electrónico estará disponible el 99,95% del tiempo en horas de oficina y el 98% durante horas de oficina no generales, excluyendo las ventanas de mantenimiento programado, medidas mensualmente". Generalmente los SLA se dividen en niveles a los que se pueden asignar servicios de TI, medidos a lo largo de un espacio de tiempo predefinido.
Contratos de nivel operativo (OLA) Los OLA básicamente describen los contratos entre distintos grupos de TI que trabajan para sostener un SLA, incluyendo los tiempos de procesamiento y respuesta para entregar sus servicios. Suponga que tiene un sitio web crítico con un objetivo de SLA del 99,99%, pero la base de datos de la que depende su contenido tiene sólo un 95% de disponibilidad de objetivo. El OLA ayuda a clarificar estas incompatibilidades y a alinear equipos de TI hacia el mismo objetivo.
Punto de recuperación y Objetivos de tiempo de recuperación (RPO/RTO) Un RTO define cuánto tiempo puede estar no disponible un servicio si hay una interrupción en la continuidad, mientras que un RPO define lo que la organización considera un nivel aceptable de pérdida de datos. Por lo tanto, si un servicio tiene un SLA del 99% medido mensualmente, tiene un RTO de 7 horas, 18 minutos. Si lo combina con un RPO de, por ejemplo, 24 horas, puede definir exactamente sus técnicas y programaciones de copia de seguridad.
Directivas de retención de datos Las directivas de retención de datos de una organización especifican exactamente cuánto tiempo hay que mantener las copias de seguridad y dónde hay que almacenarlas. Suelen estar impulsadas por requisitos legales y regulativos.
Categorización de datos También debe tener en cuenta la naturaleza de los datos. Si organiza sus datos en categorías, puede ver rápidamente que no todos los datos requieren el mismo nivel de consideración de recuperación ante desastres. Por ejemplo, una sola base de datos puede tener requisitos de disponibilidad diferentes respecto a un Active Directory con múltiples controladores de dominio, cada uno con una réplica del directorio. De forma similar, los datos de servidor de archivos pueden tener procedimientos de restauración muy diferentes respecto a los datos CRM.
Escenarios de desastre Es importante definir todos los escenarios que desea tener en cuenta, ya que cada uno de ellos tendrá unos procedimientos de restauración, un impacto empresarial y unos costos asociados distintos. Es útil tener en cuenta todos los escenarios posibles, y entonces decidir en cuáles desea centrarse al trabajar en la planificación de recuperación ante desastres para su entorno:
  • Pérdida de un sitio entero
  • Pérdida de un único centro de datos
  • Pérdida de un sistema (error de hardware o de sistema operativo)
  • Pérdida de datos (eliminación de datos o datos dañados)
  • Pérdida de una dependencia crítica
Recuperarse de la pérdida de un sitio entero tiene consideraciones muy diferentes respecto a la recuperación de un solo sistema. También querrá definir los umbrales de recuperación en función de sus SLA. Por ejemplo, pongamos que un sitio entero está sin conexión debido a una interrupción inesperada de la red ISP. Si el SLA para el servicio afectado es 8 horas para la restauración del servicio y 48 horas para la restauración de los datos, quizás realizaría los procedimientos de conmutación por error del servicio en el sitio de copia de seguridad, pero sin realizar el proceso de recuperación de datos, ya que anticiparía el error en el sitio de producción bastante rápidamente.
¡Vaya! ¡Tanto trabajo y ni siquiera hemos empezado a hablar de tecnología! No hay que subestimar la importancia de la planificación. Una implementación de recuperación ante desastres sin plan documentado sólo es un "proyecto de recuperación ante desastres".

Recuperación ante desastres y virtualización
De acuerdo, ahora que conocemos los conceptos básicos de la planificación de recuperación ante desastres, ¿qué aporta la virtualización? Muchas compañías notifican los tiempos de restauración del servicio con servidores virtualizados en minutos y no en días o semanas como sus contrapartidas físicas. Dado que todo el sistema operativo de servidor es sólo un conjunto de archivos abstraídos del hardware físico subyacente, se abren nuevas puertas cuando se tiene en cuenta la recuperabilidad.
Una teoría predominante hoy en día afirma que alguno de los objetivos de recuperación ante desastres, o todos, puede cumplirse con soluciones de alta disponibilidad (HA). La idea es que si tiene nodos de clúster en ubicaciones físicas separadas con datos sincronizados entre los sitios, en caso de un error, el nodo pasivo puede reanudar las operaciones y el usuario se puede recuperar casi en tiempo real.
Esto es cierto, pero si recuerda los escenarios de desastre definidos anteriormente, está claro que ésta no es una solución para todos ellos. Necesita una combinación de tecnologías para estar preparado para todos los escenarios; esto suele incluir copias de seguridad regulares. La alta disponibilidad no protege contra todas las interrupciones posibles y no excluye completamente la necesidad de cierto tipo de estrategia de copia de seguridad.
La alta disponibilidad con Hyper-V requiere que planifique con cuidado la capa de almacenamiento, ya que es un factor clave para que se produzca la recuperación. Por ejemplo, un clúster Hyper-V de 2 nodos con almacenamiento compartido sigue teniendo el subsistema de almacenamiento y los datos como un solo punto de fracaso, aunque los nodos de clúster estén en centros de datos separados.
Sin embargo, debe saber que el mismo clúster de Hyper-V de 2 nodos con almacenamiento no compartido puede soportar pérdidas de datos o almacenamiento en uno u otro nodo. Esto requiere tecnologías de réplica para mantener el almacenamiento sincronizado y, además, introduce complejidades (consulte la figura 2).
Figura 2 Cluster Hyper-V de varios sitios (haga clic en la imagen para ampliarla)
Hay algunos desarrollos muy interesantes en el área de réplica y sincronización de datos, pero no es algo que Microsoft proporcione actualmente. En la página de Clústeres de varios sitios de Windows Server 2008 (microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx) vale la pena examinar los socios destacados. Otro recurso es el catálogo de Windows Server (consulte windowsservercatalog.com), que muestra los fabricantes de dispositivos de almacenamiento con tecnologías de réplica certificadas para Windows Server 2008.
Como puede ver, hay muchas configuraciones posibles de alta disponibilidad y almacenamiento a tener en cuenta. De nuevo, es por esto que necesita tener definidos sus requisitos empresariales y permitirles manejar los requisitos técnicos, y no al revés.

Conversión de físico a virtual
La virtualización ofrece sin duda una agilidad de recuperación única, pero ¿qué pasa con los sistemas físicos que no son buenos candidatos de virtualización? System Center Virtual Machine Manager (SCVMM) incluye la habilidad de realizar conversiones de físico a virtual (P2V) de servidores Windows en ejecución que resultan en una máquina virtual (MV) de arranque Hyper-V que es una réplica exacta del servidor de origen físico. Ahora puede replicar esta máquina virtual como su contrapartida virtualizada en todo el campus o en todo el país y lograr tiempos de recuperación similares.
Este enfoque se distingue de la restauración completa tradicional en que su ubicación de recuperación ya no necesita el mismo número o tipo de sistemas físicos como la ubicación de producción. Así que puede sobre-suscribir su hardware de recuperación y escalarlo como sea necesario dependiendo del impacto del desastre.
Aunque SCVMM no incluye un programador para conversiones P2V, dado que la interfaz gráfica de usuario se ejecuta enteramente en Windows PowerShell, puede generarse un script mediante el cmdlet New-P2V. De hecho, todos los asistentes de SCVMM mostrarán el código que usan para ejecutar un trabajo y podrá copiar el código de un P2V de prueba en su entorno y modificarlo para un uso automatizado futuro. La figura 3 muestra un código de ejemplo; puede ejecutar el asistente de SCVMM P2V en su entorno para obtener un script de Windows PowerShell único y personalizable.
Figura 3 Código producido por el asistente de SCVMM P2V
$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"
-Credential $Credential -RunAsynchronously

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External"
-MachineConfig $MachineConfig

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM
-UseHardwareAssistedVirtualization $false -StopAction SaveVM

Instantáneas de máquina virtual
Aunque técnicamente no es una copia de seguridad, una instantánea de MV proporciona un punto en el tiempo al que puede regresar mediante discos de diferenciación y una copia del archivo de configuración de máquina virtual. Si el desastre implica la supresión accidental de datos dentro de la máquina virtual, esto puede considerarse una característica de la recuperación ante desastres, ya que puede revertirse la máquina virtual a la instantánea, y así deshacer el daño. (Más adelante examinaremos las instantáneas del Servicio de instantáneas de volumen, o VSS.)

Copia de seguridad de Hyper-V
Copias de seguridad basadas en host Una gran ventaja de la virtualización de servidores es la perspectiva de no tener que realizar la copia de seguridad de los sistemas virtualizados individualmente. Ahora que estos sistemas son simplemente archivos que viven en el sistema de archivos de un host, puede limitarse a realizar copias de seguridad de los archivos y ya está, ¿no? No exactamente. Dado que se trata de equipos activos con datos en memoria, datos en disco, configuraciones del sistema y archivos abiertos, hay unas cuantas cosas a tener en cuenta. ¿Cómo podemos asegurar la coherencia de los datos de la copia de seguridad teniendo en cuenta estos elementos móviles?
Una gran mejora de las copias de seguridad de Windows Server llegó con Windows Server 2003 y la aparición de VSS, que ofrece un conjunto estándar de API extensibles que usan los creadores de VSS (enlaces en aplicaciones y servicios que ayudan a proporcionar instantáneas coherentes) para crear las copias de seguridad de archivos y aplicaciones abiertos. Con la ayuda del servicio VSS, los proveedores y los creadores, la aplicación de copia de seguridad puede generar rápidamente una copia puntual de un volumen, uno que la aplicación conozca y que pueda procesar apropiadamente.
Hyper-V incluye su propio escritor de VSS, lo cual permite a los fabricantes de software crear atractivas soluciones de copia de seguridad. El escritor permite a las aplicaciones de copia de seguridad crear copias de VSS basadas en host de máquinas virtuales en ejecución. Si el sistema operativo que se ejecuta dentro de la máquina virtual tiene los componentes de integración de Hyper-V instalados, así como el servicio VSS (disponible en Windows XP SP1 y Windows Server 2003 y posteriores), la copia de seguridad basada en host se producirá como si se estuviera ejecutando dentro del invitado; la copia de seguridad se realizará con la máquina virtual en ejecución y los datos serán coherentes (consulte la figura 4).
Figura 4 Copia de seguridad de VSS (haga clic en la imagen para ampliarla)
Sin embargo, si el sistema operativo invitado no es compatible con los componentes de integración o con VSS, el proceso de copia de seguridad requiere que el equipo invitado se ponga en un estado guardado y que se tome una instantánea de VSS basada en host de los archivos de datos de la máquina virtual que se pueda usar para una recuperación puntual. Las instantáneas de VSS en estado guardado provocarán algún tiempo de inactividad de la máquina virtual (normalmente 5-10 minutos), con los procedimientos completos de copia de seguridad en cinta realizándose en contra de la copia de VSS de los datos.
Copias de seguridad basadas en invitado En un entorno físico, hay que hacer copias de seguridad de servidores y aplicaciones de forma individual, y estas copias de seguridad pueden continuar en un centro de datos virtualizado. En esta situación, hay que tener en cuenta las mismas consideraciones al realizar copias de seguridad de una máquina virtual, como los requisitos de capacidad de red para copias de seguridad de red y la repercusión sobre el rendimiento del sistema durante la ventana de copia de seguridad. Con las copias de seguridad basadas en invitado, puede elegir tener una NIC física dedicada en el host dependiente de una red virtual usada por todos los invitados.

Copia de seguridad de Windows Server
Windows Server 2008 incluye Copias de seguridad de Windows Server (WSB) compatibles con VSS, que se pueden usar para realizar copias de seguridad de host e invitado Hyper-V de sus máquinas virtuales. Dado que es totalmente compatible con VSS, puede realizar copias de seguridad basadas en host de sus máquinas virtuales en ejecución, lo cual es preferible, evidentemente.
Pero si tiene máquinas virtuales sin los componentes de integración instalados, no se usará VSS. En ese caso, tiene dos opciones a elegir. Todavía puede usar WSB para realizar copias de seguridad una máquina virtual que no tiene instalados los componentes de integración, lo cual significa que se guardará el estado de la máquina virtual y entonces la copia de seguridad tomará los archivos de configuración y discos virtuales de la máquina virtual.
Sin embargo, esto puede no ser recomendable con una aplicación como Exchange, ya que la aplicación no sabrá que se ha hecho una copia de seguridad y los registros de aplicaciones no estarán truncados. Además, habrá un tiempo de inactividad en la máquina virtual, que variará según lo que tarde la copia de seguridad.
Alternativamente, puede realizarse una copia de seguridad dentro de la máquina virtual como si fuera un equipo físico que usara NTBackup o WSB, dependiendo del sistema operativo de la máquina virtual. Veamos cómo usar WSB para los invitados compatibles que tienen instalados los componentes de integración.

Copia de seguridad de máquinas virtuales con WSB
Hyper-V no registra automáticamente su escritor VSS para el uso con WSB. Debe agregar manualmente la clave del registro y el valor que se muestra en la figura 5 para que WSB sea compatible con una copia de seguridad Hyper-V. Puede agregarlos a través de la línea de comandos de la manera siguiente:
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v
Figura 5 Clave y valor para registrar el escritor VSS Hyper-V
Ruta de acceso | Clave o valor del Registro | Tipo
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} | Clave | n\d
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier | Valor | REG_SZ (Hyper-V, por ejemplo)
No es necesario reiniciar, ya que WSB busca esta clave/valor en tiempo de ejecución de la copia de seguridad. El comando siguiente mostrará si se ha establecido la entrada:
reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s
Así es cómo se instala WSB. Haga clic en Inicio | Administrador de servidores. En el panel izquierdo, haga clic en Características y, a continuación, haga clic en la función para agregar características del panel derecho. En la página de selección de características, expanda las características de copia de seguridad de Windows Server y seleccione las casillas de verificación para copia de seguridad de Windows Server y herramientas de línea de comandos. Ahora siga estos pasos para configurar su copia de seguridad:
  1. Vaya a Inicio | Herramientas Administrativas | Copias de seguridad de Windows Server.
  2. Si está realizando copias de seguridad de un host remoto, seleccione la opción para conectarse a otro equipo y escriba el host de Hyper-V.
  3. Seleccione la opción para realizar la copia de seguridad una vez o programar la copia de seguridad.
  4. Seleccione la configuración de copia de seguridad: servidor completo o personalizada. Si selecciona la opción personalizada, asegúrese de que obtiene todos los volúmenes que contienen datos relacionados con la máquina virtual de la que está realizando copias de seguridad, incluidos los datos de configuración de la máquina virtual, discos virtuales e instantáneas.
  5. Seleccione la ubicación donde almacenar la copia de seguridad.
  6. Seleccione si desea una copia de seguridad completa de VSS o de copia de VSS. Para las copias de seguridad basadas en host donde no hay otras copias de seguridad de las máquinas virtuales, seleccione la copia de seguridad completa de VSS.
  7. Una vez confirmados los detalles, seleccione Copia de seguridad.
Consideraciones
  • Debe realizar copias de seguridad de todos los volúmenes relacionados con una máquina virtual, incluyendo discos duros virtuales (VHD), archivos de configuración de máquina virtual e instantáneas.
  • Si está creando una programación de copia de seguridad, debe usar un volumen local dedicado, que será formateado y usado exclusivamente por WSB. En cambio, si está realizando una copia de seguridad de una vez, puede almacenar la copia de seguridad en un volumen local no dedicado, un dispositivo extraíble o un recurso compartido de red.
  • Si los componentes de integración no están instalados dentro de la máquina virtual de la que se realiza una copia de seguridad, WSB guardará el estado de la máquina virtual en ejecución para asegurar la coherencia de los datos de la copia de seguridad.
  • Una vez completado, el conjunto de copia de seguridad es portátil y puede usarse con cualquier host Hyper-V.
Restauración de máquinas virtuales con WSB
Aunque WSB tiene la capacidad de restaurar archivos individuales, esta característica no usa VSS y, por lo tanto, puede tener como resultado una restauración incoherente si la máquina virtual se estaba ejecutando en el momento de la copia de seguridad. Para restaurar máquinas virtuales en ejecución, necesita restaurar el volumen o los volúmenes enteros.
Para ello, debe ir a Inicio | Herramientas administrativas | Copias de seguridad de Windows Server y, en el panel Acciones, seleccionar la opción de recuperación. Seleccione el servidor del que desea recuperar los datos (en el que se encuentran los datos de copia de seguridad de WSB) y seleccione la fecha de la que restaurar los datos. Ahora puede seleccionar el tipo de recuperación.
Aquí es donde debe tomar una decisión. Si necesita toda la máquina virtual, incluyendo su configuración, instantáneas y discos virtuales (en caso de fracaso completo de host, por ejemplo), seleccione la restauración de aplicación y, a continuación, Hyper-V, tal y como se muestra en la figura 6. En este caso, no tiene la opción de restaurar los archivos individuales. Tendrá que restaurar todo lo que incluye ese conjunto de copias de seguridad. Tenga en cuenta que esto no sobrescribirá los datos de configuración existentes de Hyper-V y la máquina virtual que hayan cambiado desde la copia de seguridad.
Figura 6 Restauración de una copia de seguridad Hyper-V (haga clic en la imagen para ampliarla)
Si sólo necesita el VHD en sí, y los datos de configuración e instantáneas de la máquina virtual están bien, puede seleccionar la opción de archivos y carpetas, y escoger el archivo VHD individual que necesita. Tenga en cuenta que este proceso no usa el escritor de VSS; debería haberse creado la copia de seguridad de la máquina virtual con esto en mente, con el estado guardado primero.
Si ha sufrido pérdida de datos y pérdida total del sistema y necesita recuperar el host de Hyper-V en sí (incluyendo el sistema operativo Windows Server 2008 y todas las máquinas virtuales en ejecución), debe arrancar con el Entorno de recuperación de Windows y realizar su restauración desde ahí. Esto puede hacerse desde el disco de configuración de Windows Server 2008 o desde una partición de disco preconfigurada.

Administrador de protección de datos
Hemos examinado los pasos a seguir para realizar copias de seguridad y restauraciones, además de las consideraciones para invitados y hosts de Hyper-V que usan el WSB integrado, gratuito y confiable, pero WSB no es una solución empresarial de protección de datos. Allá donde terminan sus prestaciones empiezan las del Administrador de protección de datos (DPM) 2007 SP1. Con su lanzamiento planificado para finales de 2008, DPM SP1 será compatible con Hyper-V y ofrecerá características muy atractivas:
  • Una única consola de administración para todos los invitados y hosts de Hyper-V.
  • Protección continua de datos, que toma instantáneas basadas en VSS en intervalos de hasta 15 minutos, registrando sólo los bits cambiados en el proceso.
  • Consciencia del clúster de Hyper-V, que permite a la copia de seguridad seguir a la máquina virtual a medida que se mueve entre nodos de clúster.
•Réplica de servidor DPM a servidor DPM.
  • Compatibilidad con medios de disco y cinta (disco a disco, disco a cinta o disco a disco a cinta).
  • Capacidades de copia de seguridad y restauración en todo el espectro de datos, que incluye invitados y hosts de Hyper-V; copias de seguridad de VSS sin agente de invitados en ejecución; soporte técnico para restaurar máquinas virtuales individuales; datos de clúster de conmutación por error y las mejores características específicas de aplicación para SQL Server, Exchange, SharePoint, Hyper-V y Servidor virtual.
  • Scripting previo y posterior a la copia de seguridad.
Si actualmente usa una solución de copia de seguridad de terceros, consulte las actualizaciones de la aplicación; la mayoría de proveedores están trabajando para obtener soluciones basadas en host Hyper-V.

Copias de seguridad con scripts
WSB incluye una interfaz de línea de comandos, WBadmin.exe, además de un conjunto de cmdlets de Windows PowerShell para usar con scripting. Al usarlos, se aplican las mismas reglas de copia de seguridad descritas anteriormente, además de la necesidad de registrar manualmente el escritor de VSS Hyper-V a través del registro.
La figura 7 muestra algunos comandos de WBAdmin. Para ver la documentación completa de WBAdmin, consulte go.microsoft.com/fwlink/?LinkId=124380. Como puede ver, en WBAdmin no hay nada para configurar la directiva de copia de seguridad en sí, pero hay un complemento de Windows PowerShell para administrar esta configuración. Puede comprobar si este complemento está registrado con el comando siguiente:
Get-PSSnapin -Registered
Figura 7 Comandos de WBAdmin
Comandos de WBAdmin | Descripción
ENABLE BACKUP | Habilita o modifica una copia de seguridad diaria programada.
DISABLE BACKUP | Deshabilita la ejecución de copias de seguridad diarias programadas.
START BACKUP | Ejecuta una copia de seguridad.
STOP JOB | Detiene la copia de seguridad o recuperación en ejecución.
GET VERSIONS | Muestra los detalles de las copias de seguridad recuperables de una ubicación específica.
GET ITEMS | Muestra los artículos contenidos en la copia de seguridad.
START RECOVERY | Ejecuta una recuperación.
GET STATUS | Notifica el estado del trabajo en ejecución.
GET DISKS | Muestra los discos que están en línea actualmente.
START SYSTEMSTATERECOVERY | Ejecuta una recuperación de estado del sistema.
START SYSTEMSTATEBACKUP | Ejecuta una copia de seguridad de estado del sistema.
DELETE SYSTEMSTATEBACKUP | Elimina la copia o copias de seguridad de estado del sistema.
Puede usar lo siguiente para cargar un complemento llamado Windows.ServerBackup
Add-PSSnapin windows.serverBackup
Una vez que cargado, tiene acceso a los cmdlets de Windows PowerShell para WSB, tal y como se muestra en la figura 8. Para obtener una descripción detallada de cada cmdlet, ejecute este comando:
Get-Command -PSSnapin windows.serverBackup | select name | get-help –full
Figura 8 Cmdlets de copia de seguridad de Windows Server
Cmdlet | Descripción
Add-WBBackupTarget | Agrega un destino de copia de seguridad a la directiva de copia de seguridad.
Add-WBVolume | Agrega un volumen a la directiva de copia de seguridad.
Get-WBBackupTarget | Obtiene un objetivo de copia de seguridad de una directiva.
Get-WBDisk | Obtiene todos los discos.
Get-WBPolicy | Obtiene la directiva de copia de seguridad actual.
Get-WBSchedule | Obtiene la programación de copia de seguridad de la directiva.
Get-WBSummary | Obtiene el historial y el resumen de la copia de seguridad.
Get-WBVolume | Obtiene todos los volúmenes.
New-WBBackupTarget | Crea un nuevo destino de copia de seguridad.
New-WBPolicy | Crea una nueva directiva vacía.
Remove-WBBackupTarget | Quita un destino de copia de seguridad de la directiva.
Remove-WBPolicy | Elimina la directiva de copia de seguridad.
Remove-WBVolume | Quita un volumen de la directiva.
Set-WBPolicy | Guarda el objeto de WBPolicy para crear una copia de seguridad programada.
Set-WBSchedule | Establece la programación en la directiva de copia de seguridad.

Hay otra utilidad integrada en Windows Server 2008 que también puede usar el escritor VSS de Hyper-V y que agrega un poco de flexibilidad a sus opciones de scripting. DiskShadow.exe permite crear y montar una instantánea como unidad; esto permite a los administradores hacer una copia de seguridad más selectiva que con WSB. Es importante que recuerde que DiskShadow no acepta la entrada de canalización de Windows PowerShell; en vez de eso, requiere que los comandos pasen a través de un script, que puede tener el aspecto siguiente:
Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit
Este script elimina primero las instantáneas existentes de la unidad C: y a continuación comprueba que la instantánea persista después de ejecutar DiskShadow. A continuación, crea un bloque de transacción; si alguno de los pasos falla, el proceso entero falla. En este bloque, DiskShadow comprueba que se carga el escritor para Hyper-V y agrega la unidad C: a la lista de unidades para realizar copias de seguridad.
Unidad C: obtendrá un GUID para identificarla, y este GUID se almacenará en una variable de entorno llamada "MyShadow". Una vez completado este proceso, se crea la instantánea.
La copia de seguridad se muestra como unidad X: uso de la variable de entorno. Se pueden hacer varias cosas con los datos de X: y, entonces, se puede ejecutar otra vez Disk-Shadow con el comando Unexpose X: para quitar la unidad.
Tenga en cuenta que la restauración de las máquinas virtuales de Hyper-V de las que se ha realizado una copia de seguridad mediante DiskShadow es actualmente un proceso manual (hay que volver a crear la máquina virtual, las instantáneas no se conservan, etc.). Aunque esto implica claras desventajas, se protegen los datos.
La recuperación ante desastres puede ser un proceso arduo y aparentemente interminable. Pero la virtualización de servidores ofrece nuevas posibilidades, gracias a las tecnologías y al punto de entrada de costo menor resultante. Microsoft no sólo ofrece virtualización, sino un ecosistema entero. Juntos, la plataforma de virtualización de servidores y la familia System Center ofrecen soluciones más holísticas para los desafíos cada vez más complejos a los que se enfrentan las organizaciones, como la recuperación ante desastres.
Me gustaría dar las gracias a James O'Neill por su contribución a este artículo.

Adam Fazio empezó en los servicios de consultoría de Microsoft hace más de 2 años y ahora trabaja en el sector público de los EE. UU. Lleva más de 10 años en el sector de TI trabajando en diversos proyectos de infraestructura y de centros de datos para compañías pertenecientes a la lista Fortune 100 y nuevas compañías de Internet. Actualmente es responsable de la escalada técnica del programa global de implementación rápida de virtualización de Microsoft.


virtualización
Herramientas esenciales para planificar su infraestructura virtual
Jay Sauls y Baldwin Ng
De un vistazo:
  • Contención de costos
  • Inventario de equipos
  • Determinación del uso de CPU, E/S de disco y red

Contenido
Información destacada sobre herramientas
Descubra lo que tiene
Determine los usos actuales
Recomendaciones de colocación del servidor
Configuración de la máquina virtual
Restricciones de ubicación
Tenga en cuenta sus opciones
Requisitos
Conclusión
La virtualización no es una tecnología nueva, aunque ahora se está expandiendo hacia numerosas áreas nuevas, mucho más allá de la primera plataforma de virtualización desarrollada por IBM en los años sesenta. Una de las principales razones de este rápido crecimiento es el potencial de las tecnologías de virtualización para ayudar a contener los costos relacionados con el centro de datos y las operaciones de TI. Con el aumento de los costos de energía y de la necesidad de servicios de TI por parte de las distintas secciones de su organización, en continuo crecimiento, se plantea la lucha por mantener el ritmo de crecimiento del servidor y reducir los costos de las operaciones. La virtualización puede ayudarle. Microsoft y otros fabricantes de software han estado desarrollando nuevas tecnologías (incluyendo virtualización de servidor, escritorio y aplicación) para que los recursos virtuales estén más disponibles.
En este artículo examinamos un conjunto de herramientas que puede ayudarle con sus proyectos de virtualización: Microsoft Assessment and Planning (MAP) Toolkit, que forma parte de la familia de aceleradores de soluciones de Microsoft. ¿Qué son los aceleradores de soluciones? En pocas palabras, son las herramientas de automatización e instrucciones que usted necesita para casi cada todos los proyectos de TI. Los aceleradores de soluciones son recursos libres y autorizados que le ayudan a planificar, entregar y hacer funcionar su infraestructura de TI de forma proactiva, desde escritorios a servidores, desde físico a virtual.
Diseñados en colaboración con expertos del sector y probados en entornos de cliente reales, los aceleradores de soluciones ofrecen el nivel correcto de instrucciones prescriptivas y automatización para lograr un alto rendimiento y construir una infraestructura de TI cruzada de productos, todo ello sin tener que volver a inventar la rueda. Estos recursos se centran en las principales preocupaciones de compañías de todos los tamaños, como la evaluación y planificación de la infraestructura, la virtualización, la comunicación, la colaboración o la seguridad y el cumplimiento.

Información destacada sobre herramientas
El nuevo MAP Toolkit 3.1 (consulte la figura 1) es una herramienta de evaluación de infraestructura para toda la red diseñada para ayudarle a adquirir rápidamente un conocimiento de base de sus servidores y escritorios, incluyendo si están listos para la actualización o la migración a tecnologías como Hyper-V, Microsoft Application Virtualization, Windows Server 2008, Windows Vista, Office 2007 y SQL Server.
Figura 1 Microsoft Assessment and Planning Toolkit 3.1 (haga clic en la imagen para ampliarla)
Tal y como muestra la figura 2, MAP genera automáticamente informes de evaluación de preparación y propuestas, y ahorra mucho trabajo que normalmente tendría que hacer usted mismo. MAP Toolkit 3.1 es compatible con escenarios de servidor y de escritorio, inclusive la evaluación de equipos de escritorio para actualizar a Windows Vista y la planificación del lanzamiento de Microsoft Application Virtualization.
Figura 2 Muestra de propuesta de migración generada automáticamente (haga clic en la imagen para ampliarla)
Para planificar la virtualización de un servidor hay tres características clave de la herramienta que pueden ayudarle a determinar qué equipos físicos son buenos candidatos: inventario del servidor, recopilación de indicadores de rendimiento y recomendaciones de colocación de virtualización. Vamos a examinar un escenario que muestra cómo se pueden usar estas características para obtener un retrato detallado de su entorno actual y planificar la transición a la virtualización.

Descubra lo que tiene
Muchas grandes empresas tienen algún tipo de infraestructura de administración de servidor, como System Center Operations Manager. Algunos entornos se administran de forma menos activa. Si usted trabaja en un entorno en el que no está seguro de qué servidores hay o qué es lo que ejecutan, la característica de inventario de servidores puede ayudarle rápidamente a verlo claramente. El inventario de servidores puede detectar equipos en su entorno usando Active Directory, examinando el intervalo de direcciones IP o simplemente importando una lista de equipos de un archivo sin formato. Tal y como muestra la figura 3, también puede usar diversos métodos de detección a la vez (Active Directory y examinar direcciones IP, por ejemplo) para encontrar equipos que deberían estar en Active Directory pero no lo están.
Figura 3 Elección del método de detección de equipos (haga clic en la imagen para ampliarla)
Cuando se detectan equipos, MAP Toolkit 3.1 intenta conectarse a cada uno de ellos y recuperar más de 50 clases de datos a través del Instrumental de administración de Windows (WMI). Se pueden generar diferentes tipos de informes a partir de estos datos. Para consolidar servidores con virtualización, estamos particularmente interesados en los informes que se crean al seleccionar la migración de roles y servicios específicos a Windows Server 2008.
Aunque no esté realizando una migración a Windows Server 2008 en este momento, los dos informes creados en este escenario son válidos para determinar la clase de hardware que hay en su entorno (incluyendo el tipo de procesador y la velocidad, el tamaño de disco y la memoria instalada), así como qué roles de software ha asignado a cada servidor (servidores DNS, controladores de dominio y servicios de Terminal Server).
Estos informes se proporcionan como libros de Microsoft Excel, así que es fácil usar las herramientas de clasificación y filtrado en Excel para identificar exactamente qué equipos de su entorno serían apropiados para la virtualización.
Los informes del inventario de servidores proporcionan datos acerca de diversos atributos que puede tener en cuenta al elegir servidores para virtualizar. Por ejemplo, es posible que desee asegurar que los equipos que está virtualizando funcionen con un sistema operativo compatible con la plataforma de virtualización Hyper-V. En el libro de Excel WS2008HardwareAssessment creado por proceso de inventario de servidores, en la ficha de inventario de servidores puede examinar las columnas Sistema operativo actual y Service Pack para encontrar los sistemas que pueden necesitar actualización.

Determine los usos actuales
El paso siguiente en la búsqueda de candidatos de virtualización es medir el grado de uso de los equipos físicos. El asistente de indicadores del rendimiento de MAP Toolkit 3.1 (consulte la figura 4) registra los contadores de rendimiento a partir de una lista de equipos identificados como candidatos de virtualización. Se captura el uso de la CPU, la E/S de disco y la red para su posterior revisión.
Figura 4 El asistente de indicadores del rendimiento (haga clic en la imagen para ampliarla)
Esta parte de la herramienta fue diseñada para examinar los equipos en un espacio de tiempo bastante largo (hasta un mes), de modo que puede tener cierta flexibilidad para elegir cómo lo usa. Si ya tiene una idea de cuándo se producen los usos más altos en su entorno (por ejemplo, puede que tenga una ventana semanal del procesamiento por lotes), puede configurar el asistente para que se ejecute durante sólo unas horas en ese período. Sin embargo, si no está seguro de cuándo se producen los usos más altos o si desea observar diversos equipos con distintas horas pico de uso, puede configurar el asistente para que se ejecute durante varios días o semanas y registre los datos de sus equipos. Esto hace que la herramienta pueda identificar automáticamente los picos de uso de un conjunto de datos mayor.
Con la información de su anterior inventario, obtenga acceso a las funciones de clasificación y filtrado de Excel para crear una lista de los equipos que le gustaría supervisar. El asistente de indicadores del rendimiento aceptará esta lista como archivo sin formato, con un nombre de equipo por línea. Copie la lista de nombres de equipo de Excel a un documento nuevo de Bloc de notas y guárdelo. Cuando se le solicite, importe este archivo al asistente y establezca el tiempo final del período de recopilación de indicadores del rendimiento. El asistente entrará en el modo de recogida de datos y reunirá cada cinco minutos contadores de rendimiento de los equipos especificados.
Una vez completado el asistente de indicadores del rendimiento, se crea un informe detallado de Excel que incluye una lista de todos los equipos examinados y todos los indicadores del rendimiento para categorías diferentes de uso: CPU, disco físico, disco lógico y red. Con esta información, puede refinar más la lista de candidatos a tener en cuenta para la virtualización.
Puede centrarse en equipos con un uso extremadamente bajo y consolidar varios como máquinas virtuales (MV) en un solo host, o puede combinar esta información con los datos de inventario para encontrar equipos que desarrollan servicios fundamentales y que necesitan una alta disponibilidad. La virtualización se puede usar para proporcionar capacidades mejoradas de recuperación tras desastres para entornos de alta disponibilidad. Una vez realizado el análisis, puede pasar a la fase final, la formulación de recomendaciones para la ubicación de máquinas virtuales.

Recomendaciones para la ubicación del servidor
El asistente para virtualización y consolidación de servidores le permite especificar la configuración de un hipotético equipo host de virtualización por CPU, red, subsistema de disco y memoria. Basándose en los datos de rendimiento recogidos por el asistente de indicadores del rendimiento, el asistente de virtualización y consolidación de servidores calcula una buena asignación de MV invitadas a MV hosts, asegurando que cada host se utilice correctamente, sin riesgo de sobreutilización durante el uso máximo.
Una vez completado el asistente de virtualización y consolidación de servidores, se crea una hoja de cálculo detallada de Excel detallada con la asignación propuesta de MV invitadas a host físicos. Para cada MV y host, el informe muestra el uso previsto de E/S de disco, E/S de red y de CPU. A medida que se agregan MV invitadas a equipos de host físicos durante el proceso correspondiente, se asignan los nuevos equipos a medida que se llenan los hosts anteriores. Para cada nuevo host se muestra un mensaje que indica por qué se ha tenido que asignar un nuevo host.
Si varios hosts obtienen el mismo mensaje, quizás debería plantearse volver a ejecutar el asistente de ubicación con una configuración de host diferente para intentar aumentar el número de invitados asignados a cada host. Por ejemplo, si varios host muestran el mensaje que informa de que han alcanzado el límite de memoria, puede intentar volver a ejecutar el asistente y especificar una cantidad mayor de RAM para la configuración de host. Esto debería aumentar el número de invitados que pueden ser asignados a cada host.

Configuración de la máquina virtual
Cada página del asistente de virtualización y consolidación de servidores le permite configurar un componente principal de la configuración hipotética del equipo que se usará para modelar la capacidad del equipo host de la MV. Se proporcionan modelos tanto para Virtual Server 2005 R2 como para Hyper-V, y en la primera página del asistente se le preguntará qué tecnología de virtualización desea usar (consulte la figura 5).
Figura 5 Selección de la tecnología de virtualización para recomendaciones de colocación (haga clic en la imagen para ampliarla)
En la página de configuración de CPU se ofrecen modelos de varias familias de CPU de AMD e Intel. Si no hay un modelo disponible para su CPU exacta, elija el modelo más cercano. En dicha página puede configurar el número de procesadores físicos, núcleos e hyper-threading por núcleo. Tenga en cuenta que si elige Hyper-V como plataforma de virtualización, sólo podrá se mostrarán las CPU de 64 bits para su elección (consulte la figura 6).
Figura 6 Configuración de CPU host (haga clic en la imagen para ampliarla)
En la tercera página del asistente se puede configurar un subsistema de disco en términos de número de unidades de disco y tecnología RAID para calcular el espacio en disco total disponible en el host y un valor para la capacidad de rendimiento del subsistema de disco. El valor de capacidad de rendimiento se proporciona automáticamente en función de la tecnología de interfaz y la velocidad de Monitor de confiabilidad y rendimiento (RPM) seleccionada.
En MAP Toolkit 3.1, no se proporciona soporte directo para modelar soluciones de disco de Red de área de almacenamiento (SAN) y Almacenamiento conectado a la red (NAS). Para una aproximación, seleccione la tecnología de disco SCSI y configure un nivel de RAID parecido a su configuración de SAN, con discos de velocidad semejante. Esta aproximación debería acercarse lo suficiente como para ayudarle a hacer su planificación inicial.

Restricciones de ubicación
Al asignar equipos invitados virtualizados a hosts físicos, se tienen en cuenta seis factores para evaluar si un invitado cabrá en la capacidad restante de un equipo host:
  • Uso de CPU
  • Uso de E/S de red
  • Uso de E/S de subsistema de disco
  • Memoria
  • Espacio en disco
  • Compatibilidad del sistema operativo invitado en la tecnología de virtualización especificada
El uso de CPU, de red y de subsistema de disco son bastante sencillos. Los usos medidos en el candidato invitado físico para la virtualización se convierten en un uso equivalente del equipo host de virtualización, que entonces se agrega al uso existente del host. Si el uso total resultante de todos los invitados asignados a ese host para ese recurso es menos que el umbral límite, el invitado se asigna al host. Si no, no se ubicará el invitado y se probarán otros invitados para ver si se encuentra uno que encaje.
Por ejemplo, supongamos que ha recopilado indicadores del rendimiento acerca de un equipo con una CPU Pentium 4 a 1,2 GHz con un uso de CPU del 32 por ciento. Si configura un host de virtualización con una CPU Intel Xeon 5300 de cuatro núcleos, el uso de CPU original medido en el posible equipo invitado se extrapolará a un uso equivalente proyectado en el equipo host. Este nuevo uso será inferior al valor medido original debido a la arquitectura de CPU más nueva, la distinta velocidad de reloj de CPU y la adición de más núcleos.
Por el contrario, si ha configurado un equipo host con una CPU menos eficaz que la del invitado, el uso proyectado será mayor una vez extrapolado al host. En cualquier caso, la nueva utilización de la unidad de procesamiento central extrapolada se usará para calcular el uso total del equipo host a medida que se asignan invitados.
Vale la pena describir brevemente cómo se decide el uso de memoria y el espacio en disco. La cantidad total de memoria física instalada en cada invitado potencial para la virtualización se reserva en el equipo host. Además, se reserva una pequeña cantidad de memoria (512 MB) para el propio host. Cuando se agota la memoria total del host debido a la asignación de invitados más la sobrecarga del host, ya no pueden colocarse más invitados de virtualización en ese equipo host.
El espacio en disco se controla de forma parecida: la cantidad total de espacio en disco físico en cada posible invitado para la virtualización se reserva en el equipo host. Adicionalmente, se reservan 50 GB de espacio en disco para el host de virtualización. Una vez que el uso total de disco de todos los invitados asignados al host más el espacio reservado para el propio host alcance el tamaño especificado en la configuración del host, no se podrán asignar más invitados.
En función de la plataforma de virtualización elegida, se realizarán comprobaciones para asegurar que el sistema operativo del equipo invitado sea compatible con la plataforma de virtualización. Por ejemplo, los sistemas operativos de 64 bits no son compatibles como invitados en Virtual Server 2005 R2, así que no se colocarán si elige la referida tecnología de virtualización.

Tenga en cuenta sus opciones
Ejecutando varias veces el asistente de virtualización y consolidación de servidores, es fácil comparar los resultados de distintas elecciones de hardware para el equipo host de virtualización. Cada vez que usted ejecuta el asistente, puede elegir diferentes opciones de CPU, de disco y de memoria hasta dar con la solución ideal para su entorno.
Tenga en cuenta la columna referida al motivo de error de la última selección de colocación en la ficha de recomendaciones de consolidación del libro Excel de consolidación de servidores. Estos motivos le darán indicios sobre la razón por la que no se han podido ubicar más equipos de invitado en un host particular. Si varios host muestran el mismo motivo, como un uso de memoria de invitado que supera la memoria disponible en el host, aumentar la cantidad de memoria en la configuración de host puede reducir el número total de hosts necesarios.

Requisitos
Una de las ventajas de MAP Toolkit 3.1 es que no requiere la instalación de software en los equipos inventariados. Todas las operaciones se realizan en remoto. Sin embargo, hay algunos factores que se deben tener en cuenta para que todo funcione correctamente.
Para que el asistente de inventario y el asistente de indicadores del rendimiento realicen su trabajo, algunos puertos TCP deben estar abiertos en el equipo de destino y accesibles desde el equipo donde está instalado MAP Toolkit. En la Guía de introducción se explican con detalle los requisitos; en resumen, los puertos para la autenticación, DCOM y WMI, deben estar abiertos para que los equipos sean inventariados. Si hay un firewall instalado en la red entre el equipo que ejecuta MAP Toolkit 3.1 y los objetivos de inventario, debe configurarse el firewall para también permitir este tráfico.
MAP Toolkit 3.1 está diseñado para entornos de inventario de hasta 100.000 equipos y para recoger indicadores del rendimiento de hasta 3.000 equipos a la vez. De forma predeterminada, esta herramienta instalará una instancia privada de SQL Server 2005 Express Edition. Debido a la limitación del tamaño de archivo de base de datos de 4 GB en SQL Server Express, esta configuración sólo le permite inventariar 20.000 equipos antes de alcanzar el límite de tamaño de archivo estipulado por SQL Server Express. Para trabajar con más equipos durante el inventario, hay que modificar una serie de valores predeterminados.
Para trabajar con entornos más grandes, debe usar una versión completa de SQL Server, como SQL Server 2005 Standard Edition. Antes de instalar el MAP Toolkit, instale una instancia nueva de SQL Server 2005 y llámele "MAPS". A continuación, ejecute el instalador de MAP Toolkit con toda normalidad en el mismo equipo. MAP Toolkit requiere una instancia local de SQL Server, y el instalador detectará automáticamente una instancia local de "MAPS" del servidor de base de datos y se instalará ahí, en lugar de instalar SQL Server Express Edition.
Para entornos todavía más grandes, puede usar la característica de escalado, que permite a múltiples equipos auxiliares que tengan instalado MAP Toolkit ejecutar un inventario grande cooperativamente y almacenar todos los datos reunidos en una sola base de datos central. Esta configuración también requiere el uso de SQL Server Standard Edition para evitar el límite de tamaño de archivo de 4 GB.
Consulte la Guía de introducción para obtener detalles sobre cómo instalar esta herramienta en esta configuración y editar las cadenas de conexión de base de datos correctamente para este modo. La característica de escalado también se puede usar para instalar SQL Server en un equipo distinto del que contiene MAP Toolkit.

Conclusión
Los aceleradores de soluciones como Microsoft Assessment and Planning Toolkit se encargan del trabajo pesado de sus proyectos de TI para que no lo tenga que hacer usted. MAP Toolkit ha ahorrado a muchos usuarios cientos de horas de planificación para implementaciones de Hyper-V. ¿Está listo para probarlo?
Si lo desea, puede descargar MAP Toolkit gratuitamente desde microsoft.com/map, o bien obtener los aceleradores de soluciones de virtualización en microsoft.com/vsa. También le recomendamos que visite el blog del equipo de MAP Toolkit en blogs.technet.com/mapblog, donde podrá encontrar más sugerencias y ver vídeos de demostración.

Jay Sauls es administrador de programas senior del grupo de aceleradores de soluciones de Microsoft, donde ha trabajado en el diseño y la implementación de herramientas como Windows Vista Hardware Assessment y Microsoft Assessment and Planning Toolkit. Anteriormente, trabajó en otros equipos de productos Microsoft, como Microsoft Commerce Server, Microsoft BizTalk y System Center Capacity Planner.

Baldwin Ng es director de producto senior del equipo de ingeniería principal de aceleradores de soluciones Microsoft. Entre sus proyectos actuales se incluyen MAP Toolkit y los aceleradores de soluciones de virtualización. Baldwin tiene más de 16 años de experiencia en administración de productos y desarrollo en TI, comercio electrónico y servicios inalámbricos de Internet en Microsoft, Corbis y Alltel. Suele escribir en blogs.technet.com/MAPBLOG.


Nota del editor Es un mundo virtual(izado)
Joshua Hoffman

La virtualización no es ninguna novedad. Tal vez no sea la forma más apasionante de comenzar la nota de este mes, pero es la verdad. El concepto de virtualización (separar un sistema operativo de los recursos de hardware subyacentes) ha estado presente desde 1967, con la presentación del sistema operativo CP/CMS de IBM. Aunque el concepto puede estar ya bien establecido, ha cambiado mucho en los últimos 40 años.
En 2008, llegamos a un punto clave en la virtualización de equipos. Al converger la necesidad de reducir costos, simplificar la administración y establecer prácticas de computación sostenible con procesadores más eficaces de múltiples núcleos y la nueva tecnología de hipervisor, es el momento de que salga a escena la virtualización. Es de lo que trata este número de TechNet Magazine. En el interior encontrará artículos que detallan la nueva e interesante plataforma Hyper-V en Windows Server 2008, herramientas para administrar un entorno virtual, técnicas para implementar aplicaciones virtuales y mucho más.
En un tono más personal, deseo expresar mi gratitud en nombre de todo el equipo de TechNet Magazine a los editores colaboradores Greg Stemp y Jean Ross de los mal afamados Microsoft Scripting Guys. Sé que puede suponer un trauma saber que los Microsoft Scripting Guys no son, de hecho, hombrecitos enfundados en trajes de laboratorio con cabezas exageradamente grandes que deambulan por los pasillos de Microsoft con un tubo de ensayo en una mano y un script en la otra. Por el contrario, durante los tres últimos años, Greg y Jean han escrito en la columna Hey, Scripting Guy! de TechNet Magazine y han obtenido reconocimiento mundial. Hey, Scripting Guy! no sólo se ha convertido en la columna más popular que publicamos, sino que ha ido ganando premios en su andadura y recibe incontables elogios y correos electrónicos de los lectores.
Por todos estos motivos y muchos más (sin olvidarnos del hecho de que los apreciamos muchísimo) en TechNet Magazine nos hemos sentido tristes al decir adiós a Greg y Jean este mes. Lamentablemente, como les sucede a los mejores de nosotros, Greg y Jean han prosperado. Por fortuna, seguirán deambulando por los pasillos de Redmond, repartiendo su talento en beneficio de los clientes de Microsoft. Les deseamos lo mejor a ambos y sólo esperamos que sus palabras vuelvan a honrar nuestras páginas algún día.
Mientras tanto, Dean Tsaltas, un venerable discípulo de Scripting Guys, ha tenido la gentileza de tomar el testigo de Hey, Scripting Guy! mientras vamos a la búsqueda y captura de la próxima generación de Scripting Guys. Dean se unirá a nosotros el próximo mes para sondear las profundidades del instrumental de administración de Windows. No se lo pierda. —Joshua Hoffman

Mi agradecimiento a los siguientes expertos de Microsoft: Karri Alexion-Tiernan, Carmen Asher, Scott Culp, Steve Ekren, Trina Gorman, Michael Michael, Mike Mitchell, Michael Murgolo, Rob Polly, Dan Reger, Jez Sadler, Bill Scheidel, Bryon Surace y Jim Truher.


Cartas Comentarios de los lectores

Administración de bases de datos SQL
Felicidades por "SQL Server: Buenos consejos para el mantenimiento eficaz de bases de datos", artículo del número de agosto de 2008 (disponible en technet.microsoft.com/magazine/cc671165). Por fin un artículo en la sección de SQL destinado a nosotros, los "administradores de bases de datos involuntarios", cuyo único cometido es asegurarse de que una aplicación llamada SQL Server se ejecute y realice copias de seguridad.
Y justo en la página siguiente, sigue con "Administración de Windows: Cómo tomarle el pulso a un servidor" (technet.microsoft.com/magazine/cc718984). Éste fue espectacular. Arranqué estos artículos de la revista para guardarlos en un lugar seguro, algo que simplemente no se puede hacer con las revistas electrónicas. Me referiré a estos dos artículos con frecuencia. Sigan trabajando así.
Nos alegra oír que disfrutó de estos dos artículos. Siempre nos gusta saber que nuestros contenidos son útiles. Sin embargo, aunque nunca rechazamos los elogios efusivos ¡no se quede ahí! No dude en escribirnos para recomendarnos cualquier otro tema que le gustaría que tratemos en otros números. Estamos siempre dispuestos a recibir comentarios de nuestros lectores.
—Joshua Hoffman, Jefe de redacción

Imagine X y Windows PE
Enhorabuena por la columna sobre la implementación de sistemas operativos anteriores con ImageX y Windows PE ("Arranque dual con Windows XP y Windows PE 2.0", de febrero de 2008, technet.microsoft.com/magazine/cc194422). Descubrí el potencial de estas herramientas el año pasado y empecé a experimentar con ellas para reemplazar la herramienta de imágenes que mi compañía ha estado usando (Acronis Snap Deploy). Hace unos seis meses, conseguí que todo funcionara tal como necesitaba y, de hecho, ahora es la única herramienta de imágenes que usamos.
Después, leí su artículo y presté atención al consejo de agregar la opción bootsect.exe /n52. Nunca antes había oído hablar de esta opción. Antes de aplicar las imágenes, lo único que hacemos es borrar el disco duro con DiskPart, que lleva incluido el script (commands.txt). Hasta ahora no hemos experimentado ningún problema, pero ¿podría haberlo en el futuro?
Hace algún tiempo, este comando era necesario. Sin embargo, tras la publicación del artículo, un miembro del equipo me informó de que ya no lo era, ya que el código de arranque ahora incorpora una lógica que permite buscar el nuevo código del administrador de arranque, y, en caso de no encontrarlo, prueba NTLDR antes de generar un error. Por tanto, puede omitirse completamente sin problemas.
—Wes Miller, columnista, Archivos del escritorio

Entorno de pruebas de imágenes
Leí su columna Archivos del escritorio acerca de la implementación de imágenes con la herramienta ImageX y la habilitación de la multidifusión a través de Servicios de implementación de Windows o de WDS ("Arranque dual con Windows XP y Windows PE 2.0"). Quiero montar un entorno de pruebas y me gustaría saber exactamente qué herramientas necesito. ¿Debo instalar Windows Server 2008 para realizar la implementación de multidifusión? Y también, para las imágenes reflejadas, ¿es necesario utilizar ImageX para proceder a la instalación de Deployment 4 o del Kit de instalación automatizada de Windows (WAIK) y WDS?
Para utilizar la multidifusión con WDS, debe tener Windows Server 2008 instalado. No hay componentes de multidifusión disponibles para Windows Server 2003 (y no los va a haber).
Para utilizar la multidifusión, Deployment 4 no es necesario. Para usarlo, necesita obtener Windows Server 2008, así como la versión comercializada de WAIK para Windows Server 2008. Esta versión de WAIK es la primera que contiene las piezas necesarias para la multidifusión en Windows PE.
—Wes Miller

Multidifusión con WDS
Intenté usar ImageX para clonar imágenes en equipos y desde ellos. Y enseguida me surgió un problema: ImageX no es compatible con las transmisiones de multidifusión. Quiero hacer lo mismo con los servidores de WDS para las transmisiones de multidifusión. ¿Es posible? Parece que el comando Wdsmcast puede funcionar. ¿Cómo puede informar un cliente WDS a un servidor de WDS sobre qué imagen debe descargar?
En realidad, ImageX no puede controlar una multidifusión por sí mismo. Necesita de Wdsmcast (en WAIK de Windows Server 2008) para especificar a qué transmisión conectarse (una vez que las haya iniciado en el servidor). El artículo técnico acerca de cómo usar el servidor de transporte contiene información interesante sobre cómo conectarse con Wdsmcast (technet.microsoft.com/library/cc725964). Lea la sección "Cómo conectar un cliente/servidor a un espacio de nombres mediante Wdsmcast.exe".
—Wes Miller

Póngase en contacto con nosotros ¿Tiene algo que decir? Mándenos un correo electrónico a tnmag@microsoft.com o visite nuestro blog en blogs.technet.com/tnmag.


Cuadro de herramientas Nuevos productos para profesionales de TI
Greg Steen

Todos los precios fueron confirmados el 19 de agosto de 2008 y están sujetos a cambios. Las opiniones expresadas en este artículo son exclusivas del autor y no reflejan necesariamente las opiniones de Microsoft.

Llévese sus aplicaciones con usted
PortableApps.com
PortableApps.com
Si usted es un profesional de TI, probablemente tendrá que moverse mucho entre equipos. Cuando lo hace, seguramente le gustaría tener a mano un conjunto estándar de aplicaciones, herramientas y documentos. Una buena forma de satisfacer esas necesidades es empezar con una plataforma de selector como la que ofrece PortableApps.com. Aquí encontrará la plataforma libre de código abierto PortableApps.com, además de varias aplicaciones portátiles que pueden ejecutarse únicamente desde una unidad flash USB, una tarjeta de memoria, un disco duro portátil o un reproductor de música digital.
También hay un paquete PortableApps.com. Esta práctica descarga incluye un grupo de aplicaciones portátiles y el instalador todo en uno de la plataforma de base. Hay dos versiones del paquete. El paquete Light incluye Mozilla Firefox, Thunderbird y Sunbird, junto con ClamWin antivirus, Pidgin para mensajería instantánea, el lector de PDF Sumatra, el gestor de contraseñas KeePass, el procesador de textos AbiWord, un reproductor de audio y algunos juegos sencillos. El paquete Standard incluye todas esas aplicaciones y además el paquete de ofimática OpenOffice.org, que contiene Writer, Calc, Impress, Base y Draw.
Además, hay otras cuantas aplicaciones de código abierto que se han hecho "portátiles" en este sitio, entre ellas FileZilla para FTP, PuTTY para Telnet y SSH, WinSCP para SFTP y SCP, PNotes y Task Coach para listas rápidas, 7-Zip para archivado, un símbolo del sistema, Eraser para eliminar archivos, InfraRecorder para grabar CD/DVD, WinDirStat para visualizar el contenido de un disco, winMd5Sum para comprobar archivos y WinMerge para comparar diferencias entre archivos y directorios. (Los lectores habituales de mi columna Cuadro de herramientas quizás se den cuenta de que ya he hablado de varias de estas aplicaciones en entregas anteriores).
Hay también una comunidad de usuarios muy activa que está trabajando en versiones portátiles de utilidades de red como WinPCap y Wireshark. (Estas dos herramientas pueden ayudarle con sus tareas de administración y de solución de problemas). Los foros incluso ofrecen específicamente un lugar para sugerir las aplicaciones que deberían hacerse portátiles.
Estas aplicaciones están autocontenidas en el dispositivo de almacenamiento usado. Si escriben al registro o requieren un acceso "fuera de disco", al salir deben devolverlo todo al estado anterior a la ejecución. Puede ejecutar las aplicaciones sin la plataforma PortableApps.com, ya que están disponibles para ejecución desde sus propios instaladores. No obstante, es probable que de todos modos desee disponer de la mayoría de características de la plataforma, así que el paquete es un buen lugar para iniciar un entorno personalizado que puede llevar con usted.
La plataforma PortableApps.com está configurada para que se ejecute de modo automática. Así, cuando inserta su memoria flash USB o unidad portátil en el equipo host Windows, tendrá la opción de ejecutar la aplicación de la plataforma. Una vez iniciada la plataforma, aparece un icono en la bandeja de sistema. Si hace clic en este icono aparece un menú similar al menú Inicio de Windows. Este selector de aplicaciones ofrece acceso rápido a todas sus aplicaciones portátiles, además de vínculos a carpetas de documentos de su unidad portátil, un indicador de cuánto espacio queda en la unidad, una utilidad de copia de seguridad para los documentos de la unidad, una herramienta de búsqueda y un vínculo para instalar nuevas aplicaciones portátiles. Puede personalizar la interfaz y elegir uno de los más de 30 idiomas disponibles.
Después de probar la plataforma, puede que empiece a interesarle saber cómo modificar una aplicación para hacerla portátil. El sitio web también tiene un activo foro sobre desarrollo de aplicaciones portátiles para ayudarle. Teniendo en cuenta todo esto, se trata de un conjunto de herramientas muy interesante para tener en un paquete portátil.

Precio: Producto gratuito.
PortableApps le permite llevar sus herramientas consigo

Solución de problemas de sistemas remotos
TeamViewer
teamviewer.com
Cuando está solucionando problemas de aplicaciones, ofreciendo demostraciones de productos y tutoriales o intentando entender las preguntas del usuario, no hay nada mejor que sentarse en el equipo en cuestión. Pero muchas veces esto no es posible. La siguiente mejor solución es usar una herramienta para ayudarle a "estar ahí" sin estar realmente ahí. TeamViewer, de TeamViewer GmbH, hace precisamente eso.
Esta utilidad tiene un sencillo proceso de instalación que le permite conectarse rápidamente a un equipo remoto. TeamViewer admite cuatro modos básicos de funcionamiento. Están el Soporte técnico remoto, que le permite controlar el equipo remoto para poder solucionar problemas, ayudar con las operaciones y el mantenimiento y guiar al usuario por una actividad. Además hay el modo de Presentación, que le permite mostrar su escritorio en el sistema del usuario remoto para poder demostrar una actividad o hacer una presentación. Otro modo es el de Transferencia de archivos, que le permite transferir archivos entre dos equipos sin realmente compartir los escritorios. Por último, VPN, que le permite crear una red privada virtual e instantánea entre usted y el equipo host (este modo usa la opción de instalación del adaptador de TeamViewer VPN).
A nivel de seguridad, la aplicación usa un intercambio de claves RSA y codificación de sesión AES de 256 bits. El intercambio de claves le asegura que ningún intermediario (inclusive los servidores de enrutamiento TeamView) rastreará la secuencia de datos. Además, cuando se conecta a una sesión del Personal de servicio (entendiendo por Personal de servicio el usuario que hospeda la sesión), se genera un identificador de sesión y una contraseña que el usuario remoto debe escribir para conectarse. En caso de que usted desee conectarse a un equipo sin usuario (para administrar sus servidores, por ejemplo), TeamViewer ofrece la opción de instalarse como servicio del sistema para que así pueda transferir fácilmente los archivos, usar las prestaciones de control remoto, crear una VPN o incluso reiniciar su equipo remoto.
Otra característica muy práctica, especialmente si prevé usar la aplicación para dar soporte técnico o hacer presentaciones, es el módulo QuickSupport de TeamViewer (o módulo de Cliente). Es un archivo ejecutable relativamente pequeño que no requiere instalación de software ni derechos de instalación en el equipo remoto para ejecutarse. El usuario final sólo tiene que hacer doble clic en el archivo exe y escribir el identificador de sesión y la contraseña; a continuación, usted puede conectar fácilmente su sesión al equipo.
TeamViewer tiene una serie de opciones de configuración muy útiles. Puede optimizar el número de colores compartidos en la pantalla, quitar el fondo de escritorio remoto de la pantalla o decidir si quiere mantener activado Aero Glass de Windows Vista. También puede ajustar la configuración general de calidad/velocidad para sus sesiones. Asimismo, puede decidir si desea permitir varias características, incluido el control remoto, la transferencia de archivos, las conexiones VPN, la entrada remota de teclado y de mouse, la alternancia de control entre el host local y el remoto y la visualización de la pantalla remota.
También es posible registrar las sesiones para poder repetirlas o auditarlas más adelante. Y si no desea enrutar a través de los servidores TeamViewer (por ejemplo, debido a su configuración de seguridad) puede elegir que TeamViewer sólo use conexiones LAN para enrutarse.
La edición Premium, que acepta instalaciones ilimitadas por parte del Personal de servicio, también incluye una edición portátil, que se puede meter en un CD o unidad flash USB para llevársela consigo. La edición Premium también incluye TeamViewer Manager, que registra los detalles de la sesión y le permite almacenar los detalles de socios, opciones estas muy útiles para el seguimiento, la generación de informes y la facturación de sus clientes. TeamViewer también está disponible para Mac OS X y es compatible con el acceso para múltiples plataformas, así que puede permanecer en su equipo Windows al conectarse a un Mac.

Precio: Gratuito para uso no comercial. La edición Business está disponible a partir de 699 dólares (instalación de una única instalación para Personal de servicio). La edición Premium cuesta 1.399 dólares y permite instalaciones en un número ilimitado instalaciones para Personal de servicio.
Conectarse a un sistema remoto con TeamViewer

Reseña de libro
End-to-End Network Security: Defense-in-Depth
Hoy en día la seguridad de red integra múltiples capas de tecnologías proactivas para reducir la exposición a incidentes y limitar el potencial de infracciones desde dentro y fuera de la infraestructura de la red. End-to-End Network Security: Defense-in-Depth (Cisco Press, 2007), de Omar Santos, puede ayudarle a entender las complejidades crecientes de la defensa de su red.
Aunque por motivos obvios este libro se limita a la tecnología Cisco, ofrece abundante información general sobre seguridad, lo que lo convierte en una buena referencia para cualquier profesional de red o administrador de sistemas interesado en la seguridad de infraestructuras.
El libro empieza con una introducción a las tecnologías de seguridad de red, desde firewalls y VPN a sistemas de detección y prevención de intrusos o administración de identidad. A continuación, detalla una metodología de seis pasos para controlar los incidentes de seguridad: preparación, identificación (de amenazas de seguridad), clasificación (de amenazas de seguridad), trazabilidad, reacción y postmortem.
El libro describe un marco de trabajo de seguridad proactivo que usa diversos dispositivos y herramientas, como IDS/IPS, NAC, AAA, SNMP, Syslog y VLAN. A continuación, adopta un enfoque de defensa exhaustiva de Cisco (que cubre redes inalámbricas, telefonía IP, seguridad de centros de datos y seguridad IPv6), principalmente como reflejo de las soluciones de Cisco para esas áreas de seguridad de red. El libro termina tres casos de estudio, que describen situaciones reales de soluciones de seguridad empresarial de pequeña, mediana y gran escala.

Precio: 49,50 dólares (venta directa).

Investigar identificadores de dispositivos
PCIDatabase.com
PCIDatabase.com
¿Alguna vez ha intentado actualizar un sistema y ha acabado con uno o dos dispositivos desconocidos cuyas descripciones sólo dicen "Dispositivo PCI" y no tiene la menor idea de cómo obtener un controlador o saber qué es el dispositivo sin tener que abrir su equipo y mirar en su interior con una linterna? O quizás ha intentado descubrir qué conjunto de chips subyacente hay en un dispositivo conocido. Pues un servicio gratuito que puede ayudarle es PCIDatabase.com.
Esta base de datos mantenida por el usuario le permite buscar por nombre e Id. de proveedor y dispositivo para encontrar más información. Sólo tiene que abrir el Administrador de dispositivos, hacer clic con el botón secundario en el dispositivo en cuestión y seleccionar Propiedades, ir a la ficha Detalles y seleccionar la propiedad Id. de hardware. Aquí verá un conjunto de cadenas que contienen algunos valores hexadecimales que empiezan por "VEN_" (para el proveedor) y "DEV_" (para el dispositivo).
El sitio proporciona vínculos a diversos recursos útiles para descubrir si hay algún controlador disponible para el dispositivo buscaba (y, claro, no se olvide de mirar también en el sitio web del fabricante).
Otra característica útil que puede encontrar en PCIDatabase.COM: si busca un proveedor concreto, se abrirá una página con una lista de direcciones de sedes, números de teléfono, sitios web aplicables, contactos, el identificador hexadecimal del proveedor para dispositivos PCI y una lista de todos los dispositivos del proveedor que conoce el sitio. Como el sitio lo mantienen los usuarios, esto le anima a añadir sus conocimientos.

Precio: Producto gratuito.
Obtenga información acerca del proveedor y el dispositivo en PCIDatabase.com (haga clic en la imagen para ampliarla)

Activos de auditoría e inventario
CCS Network Inventory
crowcanyon.com
Poder averiguar qué tiene instalado uno de los equipos cliente sin moverse de su mesa puede ahorrarle mucho tiempo. Asumámoslo, realizar un seguimiento de esos activos forma parte de su trabajo. Crow Canyon Systems puede ayudarle en esta tarea realizarlo con su solución CCS Network Inventory.
Se trata de una herramienta de auditoría e inventario sin agentes que busca estaciones de trabajo en su LAN y recoge información acerca del hardware, el software, el servicio y el usuario. Dado que CCS Network Inventory no usa un agente remoto, su contexto de ejecución necesita RPC, el servicio Examinador de equipos, el servicio de Registro remoto, compartir archivos e impresoras y acceso compartido de ADMIN$ a los equipos que desea inventariar (al igual que la mayor parte de productos de inventario sin agentes).
La aplicación le permite usar credenciales alternativas para sus consultas, algo muy útil para examinar múltiples dominios. Después de instalar la aplicación, puede examinar un intervalo de direcciones IP, usar la Detección de redes Windows, importar una lista de equipos o especificar manualmente una lista de estaciones de trabajo de Windows para inventariar.
En función de lo que CCS Network Inventory esté auditando, recogerá los siguientes detalles de software: qué aplicaciones hay instaladas, qué revisiones se han aplicado, qué sistema operativo y service pack se ha instalado en el equipo e incluso qué fuentes hay instaladas. En lo referente a la configuración del equipo, puede ver qué servicios y otros procesos hay en ejecución, qué carpetas se comparten, las asignaciones de unidad, las variables de entorno, las cuentas de usuario, las tareas programadas, los comandos de inicio y qué protocolos de red se están ejecutando. Y para el hardware, puede ver los detalles de los monitores, impresoras y discos duros vinculados (además de su tamaño y particiones), la información de unidades de CD y DVD, procesadores, memoria, etc. Además, puede establecer análisis personalizados para valores del registro, recuentos de archivos (por ejemplo, quién tiene más archivos mp3) y el espacio disponible en disco.
Toda esta información se almacena en la base de datos personalizada de la aplicación y los datos pueden usarse para crear informes. CSS Network Inventory proporciona una serie de informes integrados para visualizar y transportar los datos para crear auditorías e informes. Si la información integrada en los informes y consultas no incluye exactamente lo que usted necesita, puede usar la herramienta integrada SQL Query Builder, que ofrece la posibilidad de escribir y ejecutar una consulta más detallada o específica para los datos.
Con el tiempo suele ser recomendable realizar capturas del entorno para poder examinar los cambios. CSS Network Inventory le permite consultar estos cambios comparando dos instancias de las bases de datos de información. Por ejemplo, puede comparar el análisis actual con un análisis de hace un año para ver cuántas estaciones de trabajo han pasado a Windows Vista, cuántas han actualizado sus componentes de hardware en el último año o qué usuarios han continuado usando software no compatible después que usted ya los avisara.
En el momento de escribir este texto, CSS Network Inventory no es totalmente compatible con Windows 2008 Server, pero sí que es compatible con otras versiones de Windows, por ejemplo Windows Vista.

Precio: A partir de 235 dólares por un máximo de 25 nodos.
Administre activos remotos con CCS Network Inventory

Escriba a Cuadro de herramientas Si tiene una herramienta o utilidad favorita que le gustaría que aparezca aquí, escriba al autor en la dirección tntools@microsoft.com.

Greg Steen es un entusiasta empresario dedicado a las tecnologías. Siempre está buscando nuevas herramientas para ayudar a simplificar las operaciones, el control de calidad y el desarrollo para los profesionales de TI.


Preguntas y respuestas sobre SQL Grandes registros de transacciones, cuándo usar la reparación, entre otros temas
Paul S. Randal

P He observado un comportamiento extraño con las copias de seguridad que espero que me pueda explicar. Muchas veces realizamos copias de seguridad de nuestra base de datos de producción de 62 GB para actualizar los datos usados por nuestros desarrolladores de aplicaciones. Siempre eliminamos la copia antigua antes de restaurar la nueva. La copia restaurada tiene el mismo tamaño que la base de datos de producción y los datos parecen los mismos, pero el proceso de restauración tarda mucho más que el proceso de copia de seguridad. ¿A qué se debe? ¿Por qué tarda mucho más tiempo en restaurar que en realizar la copia de seguridad?
R Realmente no ocurre nada extraño. Según las circunstancias, generalmente éste es el comportamiento que se espera. La diferencia en el tiempo necesario para una copia de seguridad frente a una restauración se debe a los pasos que debe realizar cada proceso.
La realización de copias de seguridad de una base de datos consta de dos pasos. Básicamente, sólo se trata de E/S de lectura de la base de datos y E/S de escritura en el dispositivo de copia de seguridad:
Paso 1 de la copia de seguridad Lea todos los datos asignados en los archivos de datos y escríbalos en el dispositivo de copia de seguridad.
Paso 2 de la copia de seguridad Lea algo del registro de transacciones y escríbalo en los dispositivos de copia de seguridad.
La cantidad exacta necesaria del registro de transacciones puede variar de forma considerable, pero es realmente la cantidad necesaria para poder recuperar la base de datos restaurada en un punto coherente en el tiempo. (Encontrará una explicación más exhaustiva al respecto en una publicación de blog disponible en sqlskills.com/blogs/paul/2008/01/31/MoreOnHowMuchTransactionLogAFullBackupIncludes.aspx.)
Por otra parte, la restauración de una base de datos puede constar de hasta cuatro pasos, y el trabajo que conlleva es más complicado que sólo las E/S de lectura y escritura:
Paso 1 de restauración Si no existen archivos de base de datos, créelos.
Paso 2 de restauración Lea todos los datos y el registro de transacciones de la copia de seguridad y escríbalos en los archivos de base de datos pertinentes.
Paso 3 de restauración Ejecute la fase REDO de la recuperación en el registro de transacciones.
Paso 4 de restauración Ejecute la fase UNDO de la recuperación en el registro de transacciones.
El tiempo total transcurrido para ambos pasos de la copia de seguridad debe ser aproximadamente el mismo que el tiempo necesario para el Paso 2 de restauración (suponiendo que tiene hardware similar y un servidor sin ninguna actividad de usuario). El paso 1 de la restauración puede tardar mucho tiempo si los archivos de datos son grandes y tienen que inicializarse en cero (que es el comportamiento en SQL Server 2000 y el comportamiento predeterminado en SQL Server 2005).
Para evitarlo, no elimine los archivos existentes antes de iniciar la restauración. O bien, como alternativa, habilite la inicialización instantánea de manera que los archivos se creen muy rápidamente (se puede obtener más información al respecto en msdn.microsoft.com/library/ms175935.aspx).
Los pasos 3 y 4 de la restauración ejecutan la recuperación en la base de datos restaurada para que sea coherente en las transacciones; éste es el mismo proceso por el que pasaría una base de datos durante la recuperación tras bloqueo. El tiempo que tardará dicha recuperación dependerá de la cantidad del registro de transacciones que se tiene que procesar. Por ejemplo, si había una transacción de muy larga ejecución en el momento en que se realizó la copia de seguridad, todo el registro de transacciones para dicha transacción estaría en la copia de seguridad y tendría que revertirse.

P Estoy intentando elegir entre el trasvase de registros y la creación de reflejo de la base de datos para hacer una copia redundante de nuestra base de datos de producción. Me preocupa la cantidad del registro de transacciones que se tendrá que enviar entre los servidores, especialmente para las operaciones de reconstrucción de índices que realizamos todas las noches. He oído que la creación de reflejos envía los comandos de reconstrucción reales en lugar del registro de transacciones y las reconstrucciones se realizan en la creación de reflejos. ¿Es cierto? Esto haría que la creación de reflejo fuera una solución incluso mejor que el trasvase de registros con el modelo de recuperación BULK_LOGGED, ¿es así?
R Lo que ha oído no es cierto. La creación de reflejo de la base de datos funciona enviando los registros de transacciones reales de la base de datos principal al servidor reflejado, donde se "vuelven a reproducir" en la base de datos reflejada. No se está produciendo ninguna traducción ni filtrado de ningún tipo, ni ninguna clase de intercepción de comandos T-SQL para una base de datos reflejada.
La creación de reflejos de bases de datos sólo admite el modelo de recuperación FULL, lo que significa que una operación de reconstrucción de índices siempre se registrará por completo. Según el tamaño de los índices implicados, esto podría significar que se generará una cantidad importante del registro de transacciones y, a su vez, un archivo de registro grande en la base de datos principal y un ancho de banda de red sustancial para enviar los registros al reflejo.
Puede pensar en la creación de reflejo de la base de datos como un trasvase de registros en tiempo real (de hecho, éste fue un nombre que se usó para la característica al principio durante el desarrollo de SQL Server 2005). En el trasvase de registros, las copias de seguridad del registro de transacciones de la base de datos principal se trasvasan con regularidad al servidor secundario y se restauran en la base de datos secundaria.
El trasvase de registros admite los modelos de la recuperación FULL y BULK_LOGGED. Para una operación de reconstrucción de índices en una base de datos de registros trasvasados con el modelo de recuperación FULL, se generará la misma cantidad del registro de transacciones que la cantidad generada para una base de datos reflejada. Sin embargo, en el escenario de la base de datos de registros trasvasados, los datos se envían a la base de datos redundante en una copia de seguridad de registro (o una serie de copias de seguridad de registro) en lugar de como un flujo continuo.
Si se usa el modelo de recuperación BULK_LOGGED en la base de datos de registros trasvasados mientras se realiza la reconstrucción de índices, sólo se generará una cantidad mínima del registro de transacciones. Sin embargo, la siguiente copia de seguridad del registro de transacciones también contendrá todas las extensiones del archivo de datos que se han cambiado por la operación de reconstrucción de índice mínimamente registrada. Esto significa que las copias de seguridad de registro que cubren la reconstrucción de índices en el modelo de recuperación BULK_LOGGED tendrán casi el mismo tamaño que las que cubren la reconstrucción de índices en el modelo de recuperación FULL.
Por tanto, la cantidad de información que se tiene que enviar a la base de datos redundante es casi la misma para una reconstrucción de índices en una base de datos reflejada y en una base de datos de registros trasvasados. La diferencia real radica en la manera en que se envía la información: de manera continua o en lotes.
Hay otros muchos factores que se deben tener en cuenta al elegir entre estos dos métodos (demasiados factores que tratar en una sola entrega de Preguntas y respuestas sobre SQL). Debería observar cómo todos estos factores coinciden con sus requisitos (como el límite aceptable de pérdida de datos y el tiempo de inactividad permisible) antes de tomar una decisión.

P Estoy ejecutando SQL Server 2005 y una de mis bases de datos tiene un registro de transacciones que no para de crecer. La base de datos se encuentra en el modo de recuperación completa y estoy realizando copias de seguridad del registro de transacciones. Pensaba que así evitaría el crecimiento del registro de transacciones. ¿Qué es lo que está fallando?
R Tiene razón al afirmar que la creación de copias de seguridad del registro de transacciones en el modo de recuperación completa es crítico. Sin embargo, hay otros factores que pueden contribuir al crecimiento del registro de transacciones. Todo se reduce a lo que el registro de transacciones exija que sea necesario (o que esté activo). Entre otros factores comunes (aparte de la falta de copias de seguridad del registro de transacciones) que pueden ser la causa de su problema se incluyen la replicación, la creación de reflejos de la base de datos y una transacción activa.
La replicación funciona leyendo de manera asincrónica sus registros del registro de transacciones y cargando a continuación las transacciones para replicar en una base de datos de distribución independiente. No se podrá liberar ningún registro del registro de transacciones que la tarea del lector de registros de réplica no haya leído todavía. Si su carga de trabajo genera muchos registros del registro de transacciones y ha establecido un gran intervalo para la frecuencia con que se ejecutará el lector de registros de replicación, se podrán acumular muchos registros y hacer que crezca el registro de transacciones.
Si ejecuta la creación asincrónica de reflejo de la base de datos, podría haber un registro de seguridad de las entradas del registro de transacciones que no se hayan enviado desde la entidad principal al reflejo (denominado la cola SEND de la creación de reflejos de la base de datos). Los registros del registro de transacciones no se pueden liberar hasta que no se hayan enviado correctamente. Con una tasa alta de generación de registros del registro de transacciones y el ancho de banda limitado en la red (u otros problemas de hardware), el registro de seguridad puede crecer bastante y hacer que crezca el registro de transacciones.
Por último, si un usuario inicia una transacción explícita (por ejemplo, usando la instrucción BEGIN TRAN) y, a continuación, realiza una modificación de algún tipo (como una instrucción de DDL o una acción de insertar/actualiza/eliminar), los registros del registro de transacciones que se generan tienen que mantenerse hasta que el usuario confirme o revierta la transacción. Lo anterior significa que tampoco se puede liberar ningún registro del registro de transacciones posterior generado por otras transacciones, ya que el registro de transacciones no se puede liberar de manera selectiva. Si dicho usuario, por ejemplo, regresa a casa sin completar la transacción, el registro de transacciones continuará creciendo conforme se generan cada vez más registros de transacciones, pero no se puede liberar.
Puede averiguar por qué el registro de transacciones no se puede liberar consultando la vista de catálogo del sistema sys.databases y examinando la columna log_reuse_wait_desc, de la siguiente manera:
SELECT name AS [Database],
  log_reuse_wait_desc AS [Reason]
FROM master.sys.databases;
Si la causa resulta ser una transacción activa, puede usar la instrucción DBCC OPENTRAN para obtener más información acerca de la transacción:
DBCC OPENTRAN ('dbname')

P He oído que REPAIR_ALLOW_DATA_LOSS sólo debería usarse como último recurso para recuperar datos dañados; en su lugar, se debería usar la restauración de copias de seguridad. ¿Puede explicar por qué no se debería usar la "reparación para SQL Server 2005" y por qué está incluida en el producto teniendo en cuenta lo "peligroso" que es?
R En primer lugar, ciertamente fui yo quien escribió la reparación para SQL Server 2005. El problema de REPAIR_ALLOW_DATA_LOSS (al que de ahora en adelante me referiré sencillamente como reparación) es que su funcionamiento no está claro. El nombre de la opción de reparación se eligió para destacar que ejecutarla podría provocar la pérdida de datos de la base de datos. La manera en que esta característica suele reparar una estructura dañada de la base de datos es eliminando la estructura dañada y, a continuación, corrigiendo el resto de la base de datos que hacía referencia a la estructura eliminada o al que hacía referencia dicha estructura. Reparar debería ser el último recurso para conseguir que la base de datos sea coherente estructuralmente; no se trata de guardar datos de usuario. Reparar no se toma la molestia de eliminar datos de usuario ni tampoco de guardarlos.
Esto puede parecer una manera irresponsable de realizar reparaciones pero, cuando se tiene que usar la opción de reparación, ofrece el método más rápido y confiable de corregir el daño. La velocidad es de suma importancia en una situación de recuperación ante desastres y la exactitud es absolutamente necesaria. Es casi imposible desarrollar algoritmos de reparación más complejos cuyo funcionamiento se pueda probar de manera rápida y correcta en todos los casos. Hay algunos algoritmos complejos en el código de reparación diseñados para resolver el problema que se da cuando dos índices tienen, por ejemplo, la misma página o extensión asignadas, pero básicamente el algoritmo implica reparar y corregir.
Aún así, la reparación plantea algunos problemas que debería tener en mente:
  • La reparación no considera las restricciones de clave externa al eliminar las estructuras dañadas, por lo que puede eliminar los registros de una tabla que tenga una relación de clave externa con otra tabla. No hay manera de determinar si esto ha sucedido sin ejecutar DBCC CHECKCONSTRAINTS después de ejecutar la reparación.
  • La reparación no considera (ni puede considerar) relaciones de datos o de lógica empresarial inherente definidas en el nivel de aplicación que podrían interrumpirse por la eliminación de algún dato. De nuevo, no hay manera de determinar si se ha interrumpido algo sin ejecutar, independientemente de la comprobación de coherencia personalizada que esté integrada en la aplicación.
  • No es posible replicar algunas operaciones de reparación. La ejecución de la reparación en un publicador o un nodo de una topología de punto a punto puede introducir incoherencias dentro de la topología, las cuales deberán corregirse manualmente.
Por estas razones, siempre resulta buena idea recuperar datos dañados usando una copia de seguridad en lugar de ejecutar la opción de reparación. Sin embargo, se ofrece la opción de reparación con el producto porque siempre es posible que se dé una situación en la que la base de datos está dañada, no haya copia de seguridad y necesite una solución para hacer que la base de datos vuelva a estar conectada rápidamente.

P Acabo de empezar a trabajar en una compañía nueva como administrador de bases de datos y soy responsable de varias aplicaciones y de sus bases de datos back-end. Al realizar actualizaciones, el rendimiento de una de las aplicaciones es muy bajo. Investigué y descubrí que las tablas usadas por la aplicación tienen un número enorme de índices en cada una de ellas. Después de preguntar por ahí, parece que el anterior administrador de bases de datos tenía la costumbre de agregar un índice de cada columna de tabla más algunas combinaciones. No creo que todos estos índices sean necesarios, ¿cómo puedo saber cuáles son los que puedo eliminar con seguridad? Trabajamos en SQL Server 2005.
R Como se imaginará, es muy probable que el número elevado de índices contribuya en gran medida al bajo rendimiento. Cada vez que se inserta, actualiza o elimina una fila en la tabla, se tienen que realizar las operaciones correspondientes en todos los índices no agrupados. Esto agrega una gran sobrecarga a la E/S, la utilización de la unidad de procesamiento central y la generación del registro de transacciones.
En SQL Server 2000, la única manera de determinar qué índices se usaban era empleando la creación de perfiles y examinando los planes de consulta. Con SQL Server 2005 hay una nueva vista de administración dinámica (DMV) que realiza un seguimiento del uso del índice: sys.dm_db_index_usage_stats.
Esta DMV realiza un seguimiento cada vez que se ha usado un índice (y de cómo se ha usado) desde que se inició la base de datos de la que forma parte. Cuando se apaga SQL Server, se pierde la estadística para todas las bases de datos, y la estadística para una base de datos única se pierde cuando se cierra o se separa. La idea es que si un índice no aparece en la salida significa que no se ha usado desde que se inició la base de datos.
Un método sencillo para hacer un seguimiento del uso del índice a lo largo del tiempo es crear instantáneas periódicas de los resultados de DMV y después compararlas. Un asunto en el que no piensan muchas personas es que se debe realizar un seguimiento del uso del índice en un ciclo de negocio completo. Si acaba de crear una instantánea para un solo día, puede encontrar varios índices que no se usan. Sin embargo, si se usan dichos índices, por ejemplo, como ayuda para que los informes ejecuten magnitudes con mayor rapidez, probablemente los índices no se deberían eliminar. Si realmente no se ha estado usando un índice durante un ciclo de negocio completo, probablemente podrá eliminarlo, y así recuperar espacio y mejorar el rendimiento.
Para ver código sencillo que puede usar para tomar instantáneas periódicas de la DMV, consulte mi publicación de blog en sqlskills.com/blogs/paul/2007/10/05/IndexesFromEveryAngleHowCanYouTellIfAnIndexIsBeingUsed.aspx.

Paul S. Randal es el director general de SQLskills.com y uno de los profesionales más valorados (MVP) de SQL Server. Paul escribió DBCC CHECKDB/repair para SQL Server 2005 y fue responsable del motor de almacenamiento del núcleo durante el desarrollo de SQL Server 2008. Es experto en recuperación de desastres, en alta disponibilidad y en el mantenimiento de bases de datos, además de moderador habitual en congresos. Además, es autor de un blog: SQLskills.com/blogs/paul.


Utility Spotlight Herramienta de mantenimiento de máquinas virtuales sin conexión
Peter Skjøtt Larsen y Suveen Kumar Reddy Vuppala

Contenido
Pesadilla de seguridad
De forma subyacente
Infraestructura de servicios
Uso de la herramienta
Próximamente
La virtualización de una carga de trabajo de un equipo significa simplemente el uso de una máquina virtual (VM) para liberar la carga de trabajo del hardware subyacente. Los departamentos de TI modernos creen que las máquinas virtuales son útiles en muchas situaciones, entre las que se incluyen:
Desplazamiento de cargas de trabajo Puede usar máquinas virtuales con facilidad para aumentar o disminuir el ancho de banda de la carga de trabajo de varias instalaciones conforme cambien sus necesidades de uso, sin tener que hacer el cambio de hardware correspondiente.
Desarrollo y prueba de aplicaciones Es posible crear varias máquinas virtuales que representan cada configuración supuestamente compatible con una aplicación sin necesidad de un hardware dedicado.
Actualizaciones de software Puede usar máquinas virtuales para poner en línea la nueva versión de un paquete de software a la vez que desconecta la versión anterior: todo ello en el mismo hardware.
Distribución de software Las máquinas virtuales se pueden usar como una unidad de distribución para una aplicación de línea de negocios que tiene una combinación coherente de software en un paquete previamente probado.

Pesadilla de seguridad
Una de las ventajas de usar máquinas virtuales es que puede almacenarlas sin conexión como imágenes de VM. Cuando las necesite, puede "despertar" estas MV e implementarlas con mucha más rapidez que si implementara el hardware equivalente.
Sin embargo, el mantenimiento de un número creciente de entornos informáticos a la espera y sin conexión supone todo un desafío. Muchos mecanismos de actualización de software dependen de que los sistemas estén en línea para buscar actualizaciones o para recibir actualizaciones automáticamente.
Cuando una MV no está conectada, no es más que un archivo dentro de un equipo, por lo que no puede interactuar con ningún mecanismo de actualización. Una MV que ha sido puesta en conexión después de estar desconectada durante unos meses podría convertirse en una amenaza para la red o al revés, la red podría serlo para ésta.
No se trata sólo de una cuestión de falta de actualizaciones del sistema operativo. Los perfiles de virus o las aplicaciones no actualizadas pueden hacer que la MV sea vulnerable o que no cumpla los estándares de la compañía.
Para ayudar a los clientes a hacer frente al desafío de mantener actualizadas las MV sin conexión, el equipo de Acelerador de Solución Microsoft ha creado la herramienta de mantenimiento de máquinas virtuales sin conexión. Esta herramienta funciona con System Center Configuration Manager (SCCM) 2007, Windows Server Update Services (WSUS) 3.0 y System Center Virtual Machine Manager (VMM) 2007 para organizar la actualización de máquinas virtuales almacenadas. La figura 1 muestra una representación conceptual de la herramienta y cómo se conecta a distintos componentes externos.
Figura 1 Cómo funciona la herramienta de mantenimiento de máquinas virtuales sin conexión (haga clic en la imagen para ampliarla)
Para que las MV estén disponibles para actualizaciones, la herramienta usa VMM para implementarlas temporalmente en hosts de mantenimiento. Debido a que una configuración de host de mantenimiento normalmente tiene la memoria y la CPU necesarias para ejecutar varias MV a la vez, la herramienta puede administrar MV en lotes.
Tan pronto como la MV esté activa en los hosts de mantenimiento, SCCM o WSUS pueden suministrarles las actualizaciones necesarias. Después de que se hayan aplicado las actualizaciones, la herramienta usa VMM para devolver las MV a su estado sin conexión. (Tenga en cuenta que la herramienta sólo es compatible con MV administradas por VMM.)

De forma subyacente
La herramienta de mantenimiento de máquinas virtuales sin conexión usa Windows Workflow Foundation (WF) para organizar el proceso de actualización de una MV. El proceso conlleva varias decisiones, empezando por la elección del sistema de administración de actualizaciones adecuado y del siguiente host de mantenimiento disponible para la MV, asegurándose de que se haya producido la actualización y, por último, la gestión de excepciones.
El uso de una solución basada en Windows WF brindó al equipo de desarrollo una gran flexibilidad para cambiar y continuar desarrollando el proceso. También ofrece a los usuarios una solución eficaz que se puede adaptar para satisfacer necesidades específicas; en momentos críticos del proceso, los pasos integrados anteriores y posteriores al flujo de trabajo ofrecen oportunidades para la personalización.
La herramienta usa Windows PowerShell para implementar tareas individuales bajo el nivel del flujo de trabajo, que se vincula estrechamente con la API de Windows PowerShell ofrecida por VMM. Además, la interfaz de usuario basada en Microsoft .NET Framework tiene un aspecto similar a los productos de System Center, por lo que los nuevos usuarios deberían sentirse como en casa.

Infraestructura de servicios
Uno de los principios básicos de la infraestructura de servicios es configurar la seguridad de red para proteger a las MV de daños durante el proceso de actualización. En la versión 1.0 de la herramienta, esto se logra usando una red privada virtual (VPN) a la que se conecta VMM y el sistema de actualización adecuado (WSUS o SCCM). La infraestructura más adecuada para una biblioteca VMM es una red de área de almacenamiento (SAN) conectada por canal de fibra, que ofrece los medios para la transferencia rápida de imágenes de MV a los hosts de mantenimiento.
Todas las MV deben ser miembros del mismo dominio, en el que se use Active Directory y DNS. Los servidores independientes pueden dedicarse a VMM, WSUS, SCCM y la biblioteca VMM, pero las combinaciones de servidores virtuales también se pueden usar para entornos más pequeños. Ni decir tiene que los hosts de mantenimiento deben ser servidores físicos.

Uso de la herramienta
Tras configurar la infraestructura de servicios, tiene que comprobar que la configuración es correcta antes de iniciar la herramienta. Asegúrese de que VMM administra todas las MV adecuadas, que cada MV tienen instalado el cliente de actualización correcto y que los paquetes de actualización necesarios están configurados en WSUS o SCCM. Asegurar que los grupos de hosts de mantenimiento están configurados en VMM es opcional.
Cuando esté listo, inicie la herramienta de mantenimiento de máquinas virtuales sin conexión, que cuenta con varios pasos de configuración propios. Tendrá que designar el servidor VMM y el servidor WSUS o SCCM adecuado, y especificar entonces qué grupo de hosts de mantenimiento se va a usar (si los hosts de mantenimiento están agrupados) y qué host de mantenimiento de dicho grupo se va a usar (consulte la figura 2). Puede que desee configurar grupos de MV para administrarlos, pero esto es opcional.
Figura 2 Configuración de la herramienta de mantenimiento de máquinas virtuales sin conexión (haga clic en la imagen para ampliarla)
Tras configurar la herramienta, se crean los trabajos de mantenimiento. Un trabajo de mantenimiento contiene toda la información que la herramienta usa para administrar MV específicas, entre las que se incluye si se debe usar WSUS o SCCM para actualizaciones; ubicaciones del servidor VMM y el servidor WSUS o SCCM; identidades de las VM que se van a administrar; tipo (e identidad, según sea necesario) de la red que se va a usar para el proceso; identidades de los hosts de mantenimiento que se van a usar; credenciales de cuenta necesarias para tener acceso a las máquinas virtuales, el servidor VMM y el servidor WSUS o SCCM; y, por último, la programación para ejecutar el trabajo de mantenimiento ( inmediatamente o en una fecha y hora específicos).
Si especifica una fecha y hora para el trabajo de mantenimiento, el Programador de tareas de Windows determina cuándo iniciarlo. Cuando se ejecuta el trabajo de mantenimiento, la herramienta de mantenimiento de máquinas virtuales sin conexión sigue esta secuencia para cada MV:
  • Seleccione la siguiente MV de la biblioteca VMM.
  • Consulte VMM para ver el host de mantenimiento más adecuado.
  • Implemente la MV en el host de mantenimiento.
  • Asegúrese de que la MV se conecta a la red correcta.
  • Inicie la MV.
  • Asegúrese de que el cliente de actualización adecuado se encuentra instalado en la MV.
  • Inicie el proceso de actualización.
  • Espere a que se complete el proceso de actualización.
  • Apague la MV.
  • Almacene la MV de nuevo en la biblioteca VMM.
El tiempo que se tarda en actualizar una biblioteca de una máquina virtual variará mucho, dependiendo del número y la capacidad de los hosts de mantenimiento, la velocidad de acceso del almacenamiento de la biblioteca VMM y de la naturaleza de las actualizaciones.
Deberá tener en cuenta que la versión actual (1.0) de la herramienta de mantenimiento de máquinas virtuales sin conexión no es compatible con la protección de acceso a redes (NAP), que constituye una manera realmente tentadora para proteger las MV de la red. Además, no admite la tecnología Hyper-V de Windows Server 2008 ni el uso de Windows Server 2008 como sistema operativo cliente.
Las versiones más recientes de SCCM, WSUS y VMM estarán disponibles pronto y la versión 2.0 de la herramienta de mantenimiento de máquinas virtuales sin conexión ofrecerá soporte técnico a estos productos así como para Hyper-V y el uso de Windows Server 2008 en el cliente. La herramienta también será compatible con NAP para el aislamiento de la red. Puede descargar la herramienta de mantenimiento de máquinas virtuales sin conexión en technet.microsoft.com/cc501231.

Peter SkjØtt Larsen es director senior de productos en Microsoft. Antes de trabajar en Microsoft, Peter colaboró en la arquitectura y el desarrollo de sistemas de software operativos de telecomunicaciones y en la normalización y desarrollo de servicios inalámbricos.
Suveen Kumar Reddy Vuppala es ingeniero senior de desarrollo de software en Microsoft. Durante los últimos siete años, ha participado en el diseño y desarrollo de las soluciones de implementación y en las herramientas de supervisión en tiempo real para Microsoft.


Windows PowerShell El poder de los perfiles
Don Jones

Contenido
Shells, hosts y perfiles
Uso de perfiles
Creación de una consola personalizada
Más trucos de perfiles
Cuidado con el perfil
Si acostumbra a leer esta columna, ya sabrá que Windows PowerShell admite un sistema de perfiles. En esencia son scripts shell, con una extensión de nombre de archivo .ps1, que se ejecutan automáticamente cuando el shell está en funcionamiento. Son una excelente manera de, por ejemplo, definir alias personalizados. Puede tenerlo establecido de manera que cada vez que se ejecute el shell, el perfil defina automáticamente los alias, haciendo que estén disponibles siempre que use el shell.
El shell define los cuatro perfiles siguientes:
  • Uno que se aplica a todos los shells y a todos los usuarios del equipo.
  • Uno que se aplica a todos los usuarios pero sólo al shell de Microsoft PowerShell.
  • Uno que se aplica al usuario actual y a todos los shells.
  • Uno que se aplica al usuario actual y únicamente al shell de Microsoft PowerShell.
El concepto de "todos los shells" puede resultar un poco confuso. La terminología está arraigada en algunos de los primeros conceptos de desarrollo de Windows PowerShell que no llegaron a incluirse en el producto final. En la actualidad el término "todos los hosts" probablemente sería más adecuado.

Vídeo
Don Jones le muestra cómo puede crear perfiles para personalizar el shell de Windows PowerShell.

Shells, hosts y perfiles
Como ve, el propio Windows PowerShell es un conjunto de ensamblados de Microsoft .NET Framework. Me gusta referirme a esta parte del shell como el motor de Windows PowerShell porque contiene la funcionalidad que generalmente se piensa que pertenece a Windows PowerShell. Aún así, no hay ninguna función integrada para que los usuarios interactúen con este motor. Para poder usar realmente el shell, es necesario que una aplicación de hospedaje (o host) cargue el motor.
La aplicación powershell.exe a la que probablemente está acostumbrado que se ejecute es dicho host. La aplicación gpowershell.exe incluida con Community Technology Preview (CTP) de Windows PowerShell 2.0 es otro host. Esta relación entre los hosts y los shells no es tan sencilla como he expuesto aquí pero mi explicación simplificada describe el comportamiento que se observa.
Es importante comprender que si está interactuando con el shell a través de una interfaz de línea de comandos basada en texto, probablemente estará usando el host de powershell.exe. Esto es aplicable incluso aunque haya iniciado el shell mediante un método abreviado instalado por otra aplicación, como el Shell de administración de Exchange. El Shell de administración de Exchange no es una aplicación host o shell diferente, sino que es simplemente el host de powershell.exe normal iniciado con un método abreviado que especifica un conjunto de complementos y scripts que se van a cargar de antemano. Dichos complementos son los que habilitan la funcionalidad de administración de Exchange dentro del shell. Sin embargo, usted está usando todavía el mismo shell.
Las ubicaciones (en Windows Vista) de los perfiles para el host de powershell.exe son las siguientes:
  • %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 Esta ubicación es para todos los usuarios del equipo y para todos los shells.
  • %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 Esta ubicación es para todos los usuarios del equipo pero sólo para el shell Microsoft.PowerShell.
  • %PerfilDeUsuario%\Mis documentos\WindowsPowerShell\profile.ps1 Esta ubicación es para el usuario actual sólo y todos los shells.
  • %PerfilDeUsuario%\Mis documentos\WindowsPowerShell\Microsoft.PowerShel_profile.ps1 Esta ubicación sólo es para el usuario actual y sólo para el shell Microsoft.PowerShell.
Estos perfiles no se crean de forma predeterminada. Sólo existen si los crea.
Cada aplicación host es responsable de cargar y ejecutar el perfil correcto. Si una aplicación de hospedaje concreta "decide" no cargar ningún perfil en absoluto, realmente no lo tiene que hacer. La ejecución de perfil no se realiza por el motor de Windows PowerShell automáticamente.
La manera más sencilla de realizar un seguimiento de todo esto es abrir simplemente el shell, escribir $profile y presionar Entrar. Eso le dará la ruta de acceso completa que el shell intenta usar como lo que creo que es el perfil "principal" (el perfil específico de shell por usuario). A continuación, puede crear o modificar dicho script, que se ejecutará cada vez que se inicie el shell.

Uso de perfiles
Un uso común de un perfil es definir los alias personalizados, como apunté anteriormente. O bien, puede agregar PSDrives personalizados (en esencia, son unidades de disco asignadas que existen por completo dentro de Windows PowerShell). Un uso menos común es crear un tipo de supershell que puede realizar cualquier tarea de administración que se pueda necesitar, basándose en los productos de software que se estén usando en su entorno. Para explicar realmente el concepto de supershell, es necesario dar cierta información general.
El grupo de producto de Microsoft que crea Windows PowerShell es responsable de muchas otras tecnologías de administración principales, entre las que se incluye Microsoft Management Console (MMC). MMC ofrece una buena analogía para explicar cómo funciona Windows PowerShell. Cuando ejecuta mmc.exe, inicia una consola en blanco que no sirve de mucho. Agrega complementos de MMC para crear una consola funcional.
Una vez que tenga configurada la consola de la manera que desee, guárdela en un archivo con una extensión de nombre de archivo .msc. Este archivo de consola guardado le permite volver a cargar rápidamente su consola personalizada en cualquier momento.
En lugar de crear consolas de MMC personalizadas, muchos administradores dependen únicamente de las consolas que se instalan junto con los productos que administran. Exchange Server, por ejemplo, crea una consola que sólo contiene el complemento de Exchange Server. Usuarios y equipos de Active Directory es otra consola previamente creada que contiene un único complemento.
Windows PowerShell funciona de manera muy parecida. El icono de Shell de administración de Exchange instalado con las herramientas de administración de Exchange Server 2007 es en realidad un método abreviado a powershell.exe con instrucciones para cargar un archivo de consola. Los archivos de la consola de shell tienen una extensión de nombre de archivo .psc1 y contienen una lista de complementos que se van a cargar de antemano (de manera muy similar a como un archivo .msc contiene una lista de complementos que MMC precarga de antemano automáticamente). Sin embargo, no está limitado a usar estas consolas de shell creadas previamente. Puede crear una consola personalizada, de la misma manera que lo haría con MMC, y usarla para llevar a cabo todas sus tareas de administración. Los perfiles desempeñan una función clave para que esto sea posible.

Creación de una consola personalizada
Para crear una consola personalizada, debería empezar por encontrar los nombres completos de cada complemento con el que desea trabajar. Asegúrese de que todas las herramientas de administración necesarias están instaladas en el equipo. A continuación, en Windows PowerShell, ejecute Get-PSSnapin –registered. Aparecerán en una lista todos los complementos registrados disponibles pero que no se han descargado todavía. A continuación, cree o edite el perfil de Windows PowerShell adecuado. Agregue los comandos Add-PSSnapin para cargar cada complemento que desea que esté siempre disponible. Esto podría incluir complementos para Exchange Server, productos de System Center y complementos de terceros, como las extensiones de la comunidad de PowerShell. A continuación, guarde su perfil (recuerde firmar digitalmente el perfil si su directiva de ejecución de Windows PowerShell lo requiere) y cierre el shell. Vuelva a abrir el shell y cargará automáticamente todos los complementos que aparecen en la lista en su perfil.
Otra técnica es cargar todos los complementos en el shell (usando Add-PSSnapin y los nombres de los complementos) y, a continuación, ejecutar Export-Console para crear un archivo de consola .psc1 que contenga todos los complementos que está usando actualmente. A continuación, puede usar este archivo de consola .psc1 para crear un nuevo método abreviado de Windows PowerShell que especifique el parámetro PSConsoleFile y su archivo .psc1 personalizado. Dicho método abreviado usaría a continuación su consola, cargando todos los complementos especificados automáticamente.

Más trucos de perfiles
Uso mi perfil de Windows PowerShell para realizar otras tareas útiles cada vez que se inicia el shell. Esto es lo que sucede cuando el shell se inicia en mi sistema:
  1. Ejecuto Get-Credential para mi cuenta de administrador del dominio, almacenando los resultados en una variable denominada $cred. Con ello, $cred estará disponible a través del shell. Entonces puedo pasarla al parámetro –credential de varios cmdlets, como el cmdlet de Get-WmiObject. Puesto que $cred almacena la contraseña, puedo usar dichos cmdlets sin que se me pida una contraseña.
  2. Ejecuto Cd C:\ de manera que el shell se inicia en la raíz de la unidad C: de mi PC.
  3. Ejecuto New-Alias of Out-File para crear un alias denominado "of"; así puedo usar "of" en lugar de "Out-File". Lo uso mucho, por lo que tener el alias corto definido resulta muy práctico.
Intento crear una clave de prueba en la unidad HKLM: del shell, que representa la parte HKEY_LOCAL_MACHINE del registro. Si se produce un error, sé que se inició el shell sin los privilegios elevados. Normalmente necesito privilegios elevados para el trabajo que realizo y ésta es simplemente una manera rápida de saber si tengo privilegios elevados antes de empezar el trabajo serio.
Defino una función personalizada denominada Ping-Address que acepta un nombre de equipo o dirección IP, y devuelve un valor Verdadero o Falso dependiendo de si al equipo se le puede enviar un ping. Uso mucho esta función en mi trabajo, por lo que tenerla definida en mi perfil hace que esté disponible globalmente en mi shell.

Cmdlet del mes: Get-WmiObject
El observador agudo quizás se dé cuenta de que éste es un cmdlet que ya traté anteriormente, no obstante me gustaría presentar una interesante novedad que ofrece. Me encuentro a menudo con administradores que intentan recuperar información del Instrumental de administración de Windows (WMI) desde varios equipos, cuyos nombres aparecen incluidos en una lista de un archivo de texto, usando esta técnica:
Get-Content c:\computers.txt | ForEach-Object
  { Get-WmiObject Win32_Service –comp $_ }
Aunque esta técnica funciona, realmente no la necesita porque Get-WmiObject puede aceptar una matriz de nombres de equipo para el parámetro –computerName. Para lograr el mismo efecto, basta con que use lo siguiente:
Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)
La colocación del comando Get-Content entre paréntesis fuerza al shell a ejecutar el comando y colocar los resultados (una matriz de nombres de equipo) en el parámetro –computerName.
Cuidado con el perfil
Tenga presente que powershell.exe no es la única aplicación que carga los perfiles de Microsoft.PowerShell o todos los perfiles de shell. Muchos entornos de desarrollo integrados (IDE) que admiten la compatibilidad con Windows PowerShell (incluyendo PrimalScript de SAPIEN Technologies, PowerGUI de Quest Software y PowerShell Plus de ShellTools) cargan también estos mismos perfiles para ofrecer una experiencia que refleja el host powershell.exe.
Los perfiles grandes que cargan muchos complementos pueden hacer que estas aplicaciones se inicien con mayor lentitud debido a que el motor de Windows PowerShell tiene que llevar a cabo muchas instrucciones antes de prepararse para la aplicación host. De hecho, incluso powershell.exe puede tardar algo de tiempo en iniciarse si tiene un script de perfil muy grande para ejecutar.
Los complementos que definen cmdlets con los mismos nombres pueden provocar además conflictos. Por ejemplo, si dos complementos definen un cmdlet denominado Get-User, Windows PowerShell no ejecutará ningún cmdlet hasta que no use el nombre completo del cmdlet para especificar cuál desea. El nombre completo puede que no resulte atractivo puesto que los nombres de complementos pueden ser bastante largos. Cuando me encuentro con este problema, por lo general me doy simplemente por vencido con la idea de tener esos dos complementos cargados a la vez. En su lugar, cargaré sólo el que uso con mayor frecuencia en mi perfil y usaré entonces un shell nuevo e independiente cuando tengo que cargar y usar el otro complemento.
Los perfiles de Windows PowerShell pueden ofrecer mucha comodidad adicional al shell. Sin embargo, tenga presente que si están editados de forma malintencionada con malware, los perfiles también pueden causar mucho daño. Puede proteger su perfil firmándolo digitalmente y configurando Windows PowerShell para usar su directiva de ejecución AllSigned, o bien modificar los permisos del archivo NTFS en sus perfiles (todos ellos) para que su cuenta de usuario normal no los pueda modificar.

Don Jones es el autor de Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed. Puede ponerse en contacto con él a través del sitio web PowerShellCommunity.org.


Hey, Scripting Guy! Últimas palabras célebres
Los Scripting Guys de Microsoft

El famoso filósofo griego Sócrates (quien murió en el año 399 a. C., poco antes de que naciera el redactor de scripting) es quizás más conocido por haber dicho: "Una vida sin examen no merece ser vivida". Mucha gente conoce esta frase. Sin embargo, resulta significativo que los Scripting Guys descubrieran recientemente que Sócrates nunca había dicho eso de que "una vida sin examen no merece ser vivida". Resulta que fue una mala traducción hecha por un escribiente medieval hace siglos. En lugar de eso, lo que Sócrates realmente dijo fue que: "un archivo XML sin examen no merece la pena tenerlo".
¡Este dicho sí que tiene realmente sentido! En los últimos tiempo, XML se está haciendo cada vez más popular; una búsqueda rápida de uno de los equipos de prueba de los Scripting Guys reveló que son más de 500 archivos XML los que usan diversos sistemas o aplicaciones.
Sin mencionar la gran cantidad de datos importantes que ahora se almacenan en formato XML. Y eso está bien. A menos que, por supuesto, esos datos dejen de examinarse. Y, por desgracia, así sucede a menudo, no por otra cosa que el hecho de que muchas personas no tienen ni idea de cómo se examina un archivo XML. En particular, no tienen la menor idea sobre cómo realizar consultas y buscar ese archivo XML.
Nota Por si no está al corriente de quiénes son los filósofos griegos: Sócrates era un gran defensor del pasear mientras hablaba de cosas, pero no lo fue, en cambio, del andar mientras se iban haciendo cosas. De hecho, su mujer, Xanthippe, se refería a él como un "holgazán inútil". Ya habrá visto por qué los Scripting Guys sienten debilidad por Sócrates.
Por supuesto, alguno de los que están leyendo esto quizás esté pensando, "Un momento: ¿no hablaron ya los Scripting Guys acerca de la búsqueda de archivos XML en una columna anterior ("Persecución de coches… y XML" en technet.microsoft.com/magazine/cc162506)? Si es así, ¿por qué vuelven a insistir en este tema ahora? ¿Son tan perezosos que pretenden escribir la misma columna una y otra vez?"
Créalo o no, somos aún más perezosos que eso. Pero no es este el motivo principal de que estemos insistiendo en este tema. En nuestra columna anterior hablamos sobre el hecho de trabajar con un archivo XML que estuviese estructurado como el código que se muestra en la figura 1, en la que cada uno de los valores de las propiedades representa un solo nodo en el archivo.
Figura 1 Archivo XML sólo con nodos
<?xml version='1.0'?>
  <INVENTORY>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Human Resources
      </department>
      <name>atl-ws-001</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Finance</department>
      <name>atl-ws-002</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows Vista</os>
      <department>Finance</department>
      <name>atl-ws-003</name>
    </COMPUTER>
  </INVENTORY>
Eso está bien, salvo porque no es la única manera en que los archivos XML pueden estructurarse, tal y como la gente ya se apresuró a señalar. En el ejemplo anterior, cada equipo del archivo tiene su propio nodo; en cambio, cada uno de esos nodos tiene varios nodos secundarios (sistema operativo, departamento y nombre). Sin embargo, también es posible construir un archivo XML en el que los nodos individuales no tengan nodos secundarios; en lugar de eso, los valores de propiedad adicionales se configuran como atributos. Como en el archivo que se muestra en la figura 2.
Figura 2 Archivo XML con atributos
<?xml version='1.0'?>
  <HARDWARE>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-001</COMPUTER>
      <COMPUTER os="Windows XP" department="Finance">atl-ws-002</COMPUTER>
      <COMPUTER os="Windows Server 2003" department="IT">atl-fs-003</COMPUTER>
      <COMPUTER os="Windows Vista" department="IT">atl-ws-004</COMPUTER>
      <COMPUTER os="Windows Vista" department="Human Resources">atl-ws-005</COMPUTER>
      <COMPUTER os="Windows Vista" department="Finance">atl-ws-006</COMPUTER>
      <COMPUTER os="Windows XP" department="Sales">atl-ws-007</COMPUTER>
      <COMPUTER os="Windows Server 2008" department="IT">atl-fs-008</COMPUTER>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-009</COMPUTER>
      <COMPUTER os="Windows Vista" department="Sales">atl-ws-010</COMPUTER>
  </HARDWARE>
¿Supone eso un problema? Pues sí. El script que le mostramos hace algún tiempo, en un número publicado hace ya bastante tiempo, no funciona con un archivo XML estructurado como el que se muestra en la figura 2. Simplemente no va a funcionar. Y aquí está básicamente el problema, ya que muchos de los usuarios necesitan poder leer este tipo de archivo XML.
Todo lo que debían hacer era preguntar. Bueno, eso, y también esperar un año y medio antes de que finalmente nos pusiéramos a abordar el tema.
Antes de continuar, observemos más de cerca nuestro archivo XML. En este caso, tenemos un archivo con un nodo principal denominado HARDWARE y cada equipo individual existe como un nodo secundario de HARDWARE. Además, cada uno de estos nodos tiene un par de atributos: sistema operativo (usado para almacenar el nombre del sistema operativo instalado en el equipo) y departamento (usado para almacenar el nombre del departamento que posee el equipo).
Supongamos, por ejemplo, que queremos obtener una lista de todos los equipos que ejecutan Windows XP. ¿Podemos hacerlo usando un script? Por supuesto que podemos:
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("HARDWARE.xml")

Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")

For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
Veamos lo que tenemos aquí. Para empezar, creamos una instancia del objeto de Microsoft.XMLDOM; tal y como el mismo nombre implica, éste es el objeto que nos permite trabajar con archivos XML. Una vez que hemos creado el objeto, establecemos la propiedad Async en Falso. Ello permite que el script sepa que queremos cargar el documento sincrónicamente en lugar de hacerlo asincrónicamente. ¿Por qué le importa al script hacerlo de esta forma? Para ser sinceros, probablemente no le importa; después de todo, los scripts (como los Scripting Guys) son objetos inanimados.
Sin embargo, a usted sí debe importarle. Si cargásemos el documento de manera asincrónica, el script continuaría ejecutándose incluso si el documento no se hubiese cargado completamente. Eso no es bueno: imagínese los problemas que podrían generarse si intentara realizar una tarea en un documento que todavía no existe. La carga de un archivo XML de manera sincrónica garantiza que el archivo se cargará completamente antes de que nuestro script siga ejecutándose.
¡Qué coincidencia más asombrosa! Nos encontramos en el punto en el que cargamos nuestro archivo XML. Eso es algo que hacemos llamando al método Load y abriendo el archivo C:\Scripts\HARDWARE.xml, lo cual nos lleva a esta línea de código:
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")
Lo que hacemos a continuación es usar el método SelectNodes para realizar consultas en el archivo XML y comunicarle al script qué nodos XML queremos recuperar. Observe la sintaxis, que es, ciertamente, poco habitual.
Para empezar, debemos especificar la ruta de acceso dentro del archivo XML. Nuestro archivo XML tiene un nodo superior denominado HARDWARE seguido de una serie de nodos de segundo nivel denominados EQUIPO. Cada uno de estos nodos de segundo nivel representa un solo registro en nuestro archivo de datos XML. Por eso nuestra consulta de selectNodes empieza de esta forma:
//HARDWARE/COMPUTER
Llegados a este punto, nos encontramos con esta construcción:
[@os='Windows XP']
Esta parte de la consulta es parecida a una cláusula WHERE en una consulta SQL estándar. Con SQL podríamos usar una consulta de la base de datos similar a ésta para recuperar una lista de todos los equipos que ejecutan el sistema operativo de Windows XP:
SELECT Name FROM Hardware
    WHERE OS = 'Windows XP'
Con el método SelectNodes hacemos algo parecido: pedimos recibir una lista de todos los equipos en los que el atributo del sistema operativo (@os) es igual a Windows XP. Y para indicar que se trata de una cláusula WHERE, encerramos la cláusula entera entre corchetes.
Nota Este tipo de consulta se conoce como una consulta XPath. Para obtener más información acerca de XPath, vaya a msdn.microsoft.com/library/ms256115.aspx.
Como ya dijimos antes, es un poco raro, pero funciona. ¿Qué pasaría si quisiéramos obtener una lista de todos los equipos que pertenecen al departamento de finanzas? No supondría ningún problema; nuestra llamada a selectNodes se parecería a esto:
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER" & _
   "[@department='Finance']")
De nuevo, nuestra cláusula WHERE está encerrada entre corchetes, comenzamos por el nombre del atributo (el departamento) con el signo de la arroba (@) y, a continuación, indicamos el valor que nos interesa.
Sencillo, ¿eh?
Después de haber llamado al método selectNodes, podemos obtener los nombres de los equipos simplemente recorriendo con un bucle la recopilación de valores y devolviendo la propiedad Text, tal y como se muestra a continuación:
For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
¿Y qué tipo de información podemos esperar obtener? Para ser sinceros, esperamos recibir información como ésta:
atl-ws-001
atl-ws-002
atl-ws-007
atl-ws-009
En otras palabras, nos devuelve los nombres de todos los equipos que siguen ejecutando Windows XP.
Por cierto, no sólo es posible enviar informes con el nombre de los equipos. Como el nombre de los equipos es el valor "predeterminado" para cada nodo, eso es simplemente lo que obtenemos al hacer referencia a la propiedad Text.
Otra alternativa consiste en poder especificar exactamente qué valores de atributos deseamos que se nos devuelvan. Por ejemplo, echemos una ojeada a este bucle For each modificado:
For Each objNode in colNodes
    Wscript.Echo objNode.Text
    Wscript.Echo objNode.Attributes. _
      getNamedItem("department").Text
    Wscript.Echo
Next
Como puede ver, en este bucle todavía obtenemos el valor de la propiedad Text; sin embargo, en esta línea de código también hemos agregado:
Wscript.Echo objNode.Attributes. _
  getNamedItem("department").Text
En este caso, usamos el método get-NamedItem para recuperar el valor del atributo de departamento y, a continuación, obtenemos la propiedad Text para ese atributo. De esta forma es como podemos especificar qué valores de atributo (y cuáles no) obtenemos en la pantalla. (Observe también que hemos agregado un comando Wscript.Eco para dejar una línea en blanco entre registros.) Al ejecutar este script, deberíamos recibir lo siguiente:
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources
Y sí, pueden escribirse consultas más complejas si se desea. Por ejemplo, supongamos que desea tener una lista de todos los equipos que ejecutan Windows XP y Windows Vista. En SQL lo haría escribiendo una consulta OR. ¿Lo adivina? Se hace lo mismo exactamente al consultar un archivo XML:
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' or " & _
     "@os='Windows Vista']")
¿Ve lo que hemos hecho aquí? Dentro de un único conjunto de corchetes, proporcionamos dos criterios: @os='Windows XP' o @os='Windows Vista'. Eso es todo lo hay que hacer. Y nos va a generar un informe parecido al de la figura 3.
Figura 3 Resultado de la consulta OR
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-004
IT

atl-ws-005
Human Resources

atl-ws-006
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources

atl-ws-010
Sales
Si vuelve a comprobar el archivo XML, verá que los equipos que ejecutan Windows XP o Windows Vista quedan incluidos en los resultados; los equipos que ejecutan Windows Server 2003 o Windows Server 2008 no se han incluido en los resultados. Ni deben.
¿Alguna pregunta? ¿Le gustaría escribir alguna consulta más restringida, una que facilite sólo los equipos que ejecutan Windows XP y que pertenezcan al departamento de finanzas? Como probablemente habrá adivinado, es fácil; todo lo que hay que hacer es escribir una consulta AND como ésta:
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' and " & _
     "@department='Finance']")
Al hacerlo recibirá el siguiente conjunto de datos:
atl-ws-002
Finance
¿Por qué hay sólo un elemento en nuestro informe? Exacto: Porque el departamento de finanzas sólo tiene un equipo que ejecuta Windows XP.
Esperamos haberle ayudado a tratar con este tipo específico de archivo XML. Si resulta que hay algún otro tipo de archivo XML pululando por ahí, buena suerte con él.
Ya que hemos empezado la columna de este mes con un dicho famoso, pensamos que estaría bien terminarla de una forma parecida. Así que nos gustaría concluir con unas palabras del emperador Guillermo II, palabras que los Scripting Guys recordamos con cariño: "Por la presente renuncio, a todos los efectos, al trono de Prusia y al trono imperial alemán vinculado a éste".
Dr. Scripto's Scripting Perplexer
El desafío mensual que pone a prueba no sólo sus habilidades para resolver rompecabezas, también sus habilidades para el scripting.

Octubre de 2008: Crucigrama de VBScript
Para resolver este enigma, simplemente rellene cada fila con el nombre de una función de VBScript. Una vez que haya acabado, descifre las letras de los cuadrados azules para encontrar otro nombre de función.

RESPUESTA:
Dr. Scripto's Scripting Perplexer
Respuesta: Octubre de 2008: Crucigrama de VBScript

Los Scripting Guys, Greg Stemp y Jean Ross, trabajan para Microsoft.


Archivos del escritorio Personalización de Servicios de implementación de Windows
Wes Miller

Contenido
Reemplazo de lo que se tiene
Examen de la pila
Programa de arranque de red
Proveedor PXE de WDS
Demonio de TFTP
Almacén de datos de configuración de arranque
Windows PE
Servidor de transporte
Multidifusión personalizada
Conclusión
Durante tres meses he profundizado en Servicios de implementación de Windows (WDS): sus orígenes, información general y, finalmente, información más exhaustiva sobre algunos temas avanzados, como WDSutil y la multidifusión. En esta entrega final de la serie vamos a examinar dónde y cómo se puede personalizar y configurar WDS para satisfacer las necesidades de su organización. La mayoría de las herramientas de Microsoft están diseñadas con algo de capacidad de configuración. Pero es cuando se aplican en la práctica cuando realmente se sabe si las herramientas satisfacen sus necesidades o, con más frecuencia, si requieren algún ajuste para que funcionen en sus escenarios.

Reemplazo de lo que se tiene
Una pregunta que últimamente me plantean con frecuencia los lectores es "Tengo x (una tecnología de implementación existente), ¿me servirá WDS y tiene equivalencia de características con x?" Con el abandono de los servicios de implementación automatizados (ADS), un área de interés es: "¿Cómo puedo realizar una implementación rápida de alto volumen o el reaprovisionamiento de servidores? ¿Qué puede hacer WDS por mí?"
Aunque WDS no se ha diseñado para ser un reemplazo total de ADS, y de hecho le faltan algunos componentes clave para ser un verdadero sustituto, con un poco de trabajo se puede hacer que WDS sea como ADS. Del mismo modo, si algún aspecto de WDS no le sirve tal como está, averiguará que muchos de sus componentes se pueden reemplazar, con distintos grados de complejidad y diseño. Veamos la implementación mediante WDS y examinemos los elementos que puede personalizar y cómo puede hacerlo.

Examen de la pila
En la figura 1 se muestran los componentes del proceso de implementación de WDS. Cada uno de estos pasos se puede personalizar en cierta medida. He aplicado códigos de color a cada paso para reflejar la complejidad (por lo general, los conocimientos de desarrollo) que creo que supone reemplazarlo o personalizarlo. Cuanto más oscuro sea el color azul, habrá más probabilidad de que resulte difícil personalizar dicho paso.
Figura 1 Complejidad de la personalización de WDS
En realidad, la dificultad de implementación de cada paso, como es evidente, depende tanto de las capacidades de su equipo (desarrollo o scripting) y del conocimiento de WDS, el formato de imagen de Windows (WIM), Active Directory o cualquier tecnología que desee integrar, como SQL o ADSI. Examinemos cada uno de estos pasos. Piense en los modos en que desea personalizarlos y los métodos que usaría.

Programa de arranque de red
Es poco probable que deba crear un programa de arranque de red (NBP) personalizado para reemplazar los que proporciona WDS, pero es posible. WDS incluye programas de arranque de red para usarlos en sistemas sin periféricos (por lo general, servidores) o sistemas en los que puede pedir que se presione F12, etc. Estos programas de arranque de red se pueden almacenar previamente en Active Directory con WDSUtil, o se puede reemplazar Startrom.com por el programa de arranque de red que desee para todos los sistemas que no estén almacenados previamente (por ejemplo, si todos los sistemas son equipos sin periféricos o nunca desea que se pida presionar F12).
Lamentablemente, no hay disponible mucha información acerca de cómo crear un programa de arranque de red propio (consulte msdn.microsoft.com/library/bb870970.aspx para obtener algo de información). Un programa de arranque de red es un archivo ejecutable de 16 bits muy pequeño con grandes limitaciones y requiere conocimientos de programación específicos. Por lo general recomiendo el uso de los programas de arranque de red existentes que se proporcionan con WDS a menos que intente satisfacer un requisito muy específico y tenga un equipo de desarrollo con los conocimientos adecuados.

Proveedor PXE de WDS
Con Servicios de instalación remota (RIS), los comentarios habituales que recibimos de los clientes es el deseo de usar un almacén distinto de Active Directory para la información del sistema cliente, con mucha frecuencia, SQL Server. Con WDS, el diseño incluye una infraestructura acoplable para proveedores de entorno de ejecución previo al arranque (PXE). Esto significa que con el trabajo de desarrollo se puede usar otro almacén de refuerzo además de Active Directory para la información de PXE.
WDS incluye su propio proveedor que usa Active Directory; System Center Configuration Manager (SCCM) ahora también se integra en WDS e implementa un proveedor propio. La documentación acerca de cómo escribir un proveedor propio es muy escasa y no hay disponible demasiado código de muestra (aunque el SDK de Windows proporciona documentación y un par de muestras), por lo que es una tarea ardua. A menos que tenga unos requisitos muy específicos para este aspecto del proceso de arranque, de nuevo recomiendo que no se intente crear un proveedor PXE personalizado.

Demonio de TFTP
A veces los clientes han invertido en su propio demonio de protocolo trivial de transferencia de archivos (TFTPD) antes de que apareciera WDS. Debido a que los servidores PXE no se entienden bien entre sí, esto suele significar que se debe activar sólo uno.
Según mi experiencia, por lo general significa tomar un TFTPD existente, normalmente basado en Linux, y obtener acceso a él para arrancar otros sistemas operativos. Con el RIS de infraestructura original utilizado no se podía hacer esto. Pero cuando arrancar desde un disco RAM se convirtió en la norma, se podía, y todavía se puede, hacerlo con imágenes de arranque basadas en WDS.
Lo que se debe tener presente es que se adentra en un área sin soporte técnico en lo que respecta a Microsoft y que se pueden producir problemas que son difíciles de diagnosticar. Además, con un TFTPD mejorado en WDS, es muy probable que no alcance un mejor rendimiento. Idealmente, recomiendo el uso de TFTPD de WDS existente e intentar usar los tiempos de espera de PXE, el almacenamiento previo y los perímetros de red para definir los clientes que arrancan desde cada servidor PXE en vez de intentar adaptar un servidor existente.

Almacén de datos de configuración de arranque
Con RIS nunca se pudo especificar, en el nivel de arranque, lo que debía arrancar; siempre se tenía que ir al selector de sistema operativo y elegir una opción (configuración, Windows PE [entorno de preinstalación de Windows] o algo completamente distinto). WDS, debido a que usa un cargador completo para el arranque de red, también admite la personalización del almacén de datos de configuración de arranque (BCD) que se sirve a los clientes. Los BCD predeterminados de cada arquitectura se encuentran en RemoteInstall\Boot\<arq>\Default.bcd, donde <arq> es la arquitectura específica del sistema que va a arrancar.
Puede personalizar estos BCD para cada cliente y el cliente los usará para arrancar. Por ejemplo, puede establecer una entrada de BCD para iniciar la configuración, otra para ejecutar Entorno de recuperación de Windows (WinRE) e incluso otra para ejecutar una prueba de memoria; o puede tener una entrada de configuración totalmente automatizada que sea la predeterminada y otra manual (o experiencia de instalación personalizada) que sea una opción que pueda seleccionar el usuario. (Para obtener más información, vaya a "Cómo modificar el almacén de BCD con Bcdedit" en go.microsoft.com/fwlink/?LinkId=115267.)

Evidentemente, la mayoría del trabajo pesado de WDS se produce en Windows PE, por lo que ajustar Windows PE según sus necesidades puede ser un área crítica de interés para una experiencia personalizada. De forma predeterminada, WDS ofrece una plantilla muy estándar para la instalación, que incluye la experiencia de instalación completa. En ocasiones, las necesidades de implementación pueden implicar que esto no le funcione. En este caso, puede crear su propia imagen de arranque de Windows PE. Empecemos por el principio.
Además de usar los BCD para indicar la imagen que se utilizará, también puede especificar la imagen si personaliza el objeto de cuenta de máquina (MAO) de un equipo en Active Directory. En RIS, se almacena un atributo MAO específico por cada elemento (que indica el archivo Startrom y Unattend, SIF, que se utilizará). Con WDS, se almacenan como pares de nombre y valor en la entrada netBootMirrorDataFile. Por ejemplo, en esta entrada se almacenan la imagen de arranque y el archivo Unattend que utilizará un determinado equipo. El formato de las entradas es una lista delimitada por puntos y comas de pares de nombre y valor. Las entradas para modificar la imagen de arranque y el archivo Unattend son BootImage y UnattendFilePath, respectivamente.
Evidentemente, puede suceder que desee descartar la experiencia de instalación existente por completo y crear una propia. Tal vez necesite más capacidad de configuración, más automatización o una generación automatizada mediante SQL Server. Tal vez desee hacer como hacían algunos clientes con RIS y Windows PE anteriormente y crear su propio front-end para la instalación. Las tareas clave que necesite llevar a cabo independientemente de la experiencia de instalación que escriba son:
  • Averiguar la información por equipo o por usuario. Esta información se puede obtener de los datos del usuario, de SQL Server o de un archivo de texto, por ejemplo.
  • Copiar y aplicar una imagen de instalación al sistema cliente. Esta tarea se puede llevar a cabo con la instalación directamente, con ImageX para aplicar una imagen desde un recurso compartido de red o mediante multidifusión (simplemente copiar la imagen y aplicarla a través de ImageX).
  • Proporcionar un archivo Unattend (como Unattend.xml o sysprep.inf, según la versión de Windows que se vaya a implementar) para terminar la instalación.
  • Automatizar los pasos de migración posteriores a la instalación que desee llevar a cabo (o cualquier paso que aplique funciones en el caso de Windows Server 2008).
Con ADS se inició el concepto de las secuencias de tareas que permite asignar pasos repetibles a uno o varios equipos. Debido a que ADS no se diseñó para Windows XP ni es compatible con él, no se puede utilizar para implementar el sistema operativo. Pero las secuencias de tareas de ADS realmente son scripts estructurados y puede llevar a cabo los mismos pasos con un proceso de instalación personalizado.
Desde hace tiempo soy admirador de Microsoft SQL Server (desde la versión 6.5 de SQL Server), por lo que mi instinto me dicta crear dicha estructura con SQL. Evidentemente, se necesita agregar la funcionalidad de SQL a la compilación de Windows PE para hacerlo. Además, puede escribir su propia GUI, una aplicación HTML (HTA) o un archivo ejecutable compilado, o usar Windows Script Host (WSH) para realizar una experiencia de instalación minimalista sólo a través de la línea de comandos. Para usarlos, HTA o WSH también se deben agregar a Windows PE.
La complejidad del diseño de una experiencia de instalación propia depende por completo de sus conocimientos e imaginación. He visto sistemas bastante elegantes que se han definido únicamente con SQL y WSH o HTA, que son capacidades relativamente sencillas que puede elegir cualquiera. No obstante, es muy importante tener presentes las restricciones que he mencionado en columnas anteriores.
  • Windows PE no dispone del subsistema Windows sobre Windows (WOW), por lo que tendrá que realizar la compilación una vez para cada arquitectura que desee admitir.
  • No puede usar Visual Basic 6.0 si necesita implementar mediante Windows PE x64 o IA64.
  • Puede usar Visual Studio 2005 o 2008 para crear aplicaciones, pero debe crear una aplicación Visual C++ no administrada, ya que no hay ninguna versión de Microsoft .NET Framework que se admita en Windows PE.
  • Sin .NET Framework, tampoco podrá usar Windows PowerShell para la automatización.
Evidentemente, también puede usar una utilidad de imagen de terceros mediante WDS si desea escribir su propia experiencia de instalación. Aunque creo que el formato WIM e ImageX pueden cubrir la mayoría de los escenarios de implementación, puede haber determinados requisitos que necesita que cumpla la herramienta de imagen existente.
De forma similar, determinados escenarios pueden requerir particiones personalizadas: tal vez vaya a implementar Windows Vista con BitLocket o crear sistemas Windows XP y almacenar los datos de perfil en otro volumen, o tal vez vaya a implementar un sistema Windows Server y desea crear un volumen independiente en el mismo disco para realizar el registro. Cualquiera de estos escenarios requiere la automatización de DiskPart que, como en versiones anteriores, se puede realizar con un script (cualquier formato de archivo) para DiskPart que contenga los comandos que desea ejecutar y termine con exit, para finalizar DiskPart.
La creación de una experiencia de instalación es para valientes, ya que básicamente se está reconstruyendo el archivo ejecutable de instalación (o al menos replicando su funcionalidad) y puede haber bastante que diseñar y generar. Pero se trata de cuánta funcionalidad desea incorporar de forma predeterminada y de lo que se desea incorporar (HTA o WSH, o bien un lenguaje de programación compilado).

Servidor de transporte
Si no va a usar la mayor parte de la funcionalidad integrada de WDS (como Active Directory) o va a diseñar su propia solución completa y personalizada, el servidor Transporte puede cubrir sus necesidades y no incorporar requisitos que no desee. La tabla de la figura 2 (reproducida de "Uso del servidor Transporte" en go.microsoft.com/fwlink/?LinkID=115298) describe lo que se incluye como parte de la función de servidor de transporte de WDS.
Figura 2 Servidor de implementación frente a servidor de transporte
 | Servidor de implementación | Servidor de transporte
Requisitos de servidor | Requiere Servicios de dominio de Active Directory (ADDS), Protocolo de configuración dinámica de host (DHCP) y Servicios de nombres dinámicos (DNS) en el entorno. | No requiere otros servidores en el entorno.
PXE | Admite el arranque PXE con el proveedor PXE predeterminado. | No se instala un proveedor PXE, por lo que debe crear uno.
Servidor de imagen | Incluye el servidor de imagen de Servicios de implementación de Windows. | No incluye el servidor de imagen de Servicios de implementación de Windows.
Método de transmisión | Admite unidifusión y multidifusión. | Sólo admite multidifusión.
Herramientas de administración | Se administra con el complemento de MMC Servicios de implementación de Windows o la herramienta de la línea de comandos WDSUTIL. | Sólo se administra mediante la herramienta de la línea de comandos WDSUTIL.
Aplicación en el equipo cliente | Usa el cliente de Servicios de implementación de Windows (que básicamente es Setup.exe y los archivos auxiliares), Wdsmcast.exe (que se incluye en el AIK de Windows) o una aplicación de multidifusión personalizada. | Usa sólo Wdsmcast.exe o una aplicación personalizada.
Cuando me refiero a que el servidor de transporte es un elemento complicado de implementar, no es que la función sea difícil, ya que, evidentemente, se implementa de modo sencillo (consulte la figura 3). Es la implementación de instalación personalizada de alrededor del servidor de transporte la que requiere trabajo. El uso de la función de servidor de transporte anula la mayor parte de la facilidad de uso integrada en WDS como función.
Figura 3 El servidor de transporte puede resultar útil para los escenarios de implementación personalizada (haga clic en la imagen para ampliarla)

Multidifusión personalizada
Independientemente de si usa la función de servidor de transporte, pero especialmente si la usa, es una buena ocasión para usar la multidifusión si va a realizar una implementación de multidifusión. ADS dispone de una característica de multidifusión muy eficaz, que puede duplicar mediante WDS con multidifusión. WDS dispone de multidifusión, pero si va a crear su propia solución personalizada, puede aprovechar la multidifusión con WDSMCast, tal y como mencioné el mes pasado (consulte la figura 4). Recuerde que debe transferir los archivos de imagen que se implementan y, a continuación, se deben aplicar. Por lo general esto significa que necesita suficiente espacio en el disco local para que la imagen se almacene y, a continuación, se aplique.
Figura 4 Ejecución de WDSMCast (haga clic en la imagen para ampliarla)

Conclusión
WDS proporciona bastante eficacia por sí mismo, probablemente la suficiente para satisfacer las necesidades de muchas organizaciones. Pero si busca crear su propia solución que traspase los límites de WDS, puede hacerlo, y sólo estará limitado por su imaginación, su programación y sus conocimientos.

Wes Miller es jefe de productos técnicos senior en CoreTrace (CoreTrace.com), con sede en Austin, Texas. Anteriormente, trabajó en Winternals Software y como administrador de programas en Microsoft. Si lo desea, puede ponerse en contacto con Wes en la dirección technet@getwired.com.


Vigilancia de seguridad Repaso a las 10 leyes inmutables de la seguridad, parte 1
Jesper M. Johansson

En el año 2000, Scott Culp publicó un ensayo titulado "Las 10 leyes inmutables de la seguridad". Es uno de los mejores ensayos acerca de la seguridad que he leído. La información que presentaba sigue siendo fundamental en todo trabajo en seguridad de la información y recomiendo consultarlo (e incluso imprimirlo) si todavía no lo ha hecho. Se puede encontrar en microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.
El ensayo tuvo distintas respuestas. Algunos comentan sarcásticamente que era un modo de que Microsoft evitara corregir lo que se consideraban problemas graves. Otros lo consideran uno de los escritos más fundamentales acerca de la seguridad y lo han plagiado debido a su gran importancia. Sin embargo, algunas de mis respuestas favoritas son las de las personas que se han inspirado para crear sus propias listas, como la que está disponible en edgeblog.net/2006/10-new-immutable-laws-of-it-security.
En los ocho años que han transcurrido desde la publicación del ensayo han sucedido muchas cosas en el terreno de la seguridad. Se ha publicado prácticamente todos lo digno de mención. Hemos entrado en un estado de conflicto de información (con crimen organizado, entidades políticas, etc.). Una serie de palabras y frases nuevas han pasado a formar parte del vocabulario común, incluido "phishing", granjas de servidores, botnet, spyware y suplantación de solicitudes entre sitios. Tenemos algunos de los rootkit más sofisticados que se han creado para Windows. Tenemos nuevas publicaciones de sistema operativo que están dedicadas, en gran medida, a la seguridad y otros sistemas operativos en los que la seguridad se ignora por completo.
La ingeniería social ha evolucionado hasta convertirse en una amenaza importante. Las infracciones de datos, como el caso en que un proveedor importante deja expuestos 94 millones de números de tarjeta de crédito, se han convertido en noticias habituales (y la gente sigue comprando en dichas tiendas). Los gobiernos de Estados Unidos y Reino Unido, conjuntamente, han conseguido extraviar información importante de un gran porcentaje de los habitantes del mundo occidental (y la gente sigue teniendo información privada con dichos gobiernos). Y una gran parte de la puesta en escena de la seguridad ha llegado a nuestras vidas, y a nuestros aeropuertos.
Creo que ha llegado el momento de revisar las leyes. En virtud de todos los cambios a los que hemos asistido en la primera parte del siglo, ¿podemos seguir proclamando que estas leyes son inmutables? Si lo son, si han sobrevivido los últimos 8 años, sin duda se puede decir con seguridad que sobrevivirán otros 10.
En esta serie de tres partes examinaré de forma crítica cada una de estas 10 líneas. Este mes traté las leyes 1 a 3. En el número del mes siguiente, examinaré las leyes 4 a 7. Y la entrega final la dedicaré a las leyes 8 a 10 y ofreceré ideas y comentarios adicionales que parecen razonables según lo que ha sucedido desde que las leyes se escribieron originalmente en el año 2000.
Ley 1: Si uno de los malos puede persuadirle para ejecutar un programa en su equipo, deja de ser su equipo.
Esta ley indica, de forma patente, que cualquier software que ejecute en el equipo puede controlar dicho equipo. Cuando aparecieron las leyes inmutables por primera vez, los sistemas operativos Microsoft eran Windows 98, Windows Me y Windows NT 4.0. En la actualidad tenemos Windows Vista y Windows Server 2008.
En Windows 98 y Windows Me, cualquier software ejecutado tenía control completo del equipo. Windows NT 4.0 tenía un modelo de seguridad subyacente muy sólido, pero si se ejecutaba como administrador, se reducía su modelo de aislamiento al de Windows 98 y Windows Me. Se podía ejecutar Windows NT 4.0 sin ser administrador, pero resultaba bastante complicado y muy pocas organizaciones lo hicieron (probablemente se podría contar el número total de organizaciones que lo hicieron sin usar los dedos de los pies).
Supongamos que ejecutaba Windows NT 4.0 sin ser administrador. ¿La ley 1 también era cierta cuando se escribió? La respuesta es sí. En primer lugar, Windows NT 4.0 tenía una gran cantidad de agujeros importantes. Por ejemplo, había permisos que podrían haber sido más estrictos, en concreto en los objetos de kernel y en el Registro. También había muchos tipos de ataques que todavía no se habían descubierto, pero que los expertos esperaban que sugieran. Por ejemplo, en 1999 los usuarios no se habían dado cuenta de que tener procesos que se ejecutaran como usuarios con privilegios elevados en el escritorio interactivo podían poner en peligro el equipo. No fue hasta 2002 cuando Chris Paget publicó sus notas de la versión sobre los ataques destructivos, Vulneración de la API Win32, que se convirtió en un conocimiento estándar (seclists.org/bugtraq/2002/Aug/0102.html).
¿Había previsto Microsoft los ataques destructivos cuando se redactó la ley 1? En realidad, no. Microsoft simplemente reconoció un hecho simple: hay muy pocos límites de seguridad auténticos que impidan que una aplicación que se ejecute en un equipo tome el control del mismo.
Windows Vista y Windows Server 2008 son dos generaciones que se han apartado de Windows NT 4.0. ¿Han invalidado la ley 1? ¿Existen otros sistemas operativos que lo hagan? Depende. Ciertamente, hay límites de seguridad más sólidos en los nuevos sistemas operativos y había algunos sistemas operativos experimentales en 2000 que tenían límites de seguridad adecuados. Sin embargo, sólo quedan algunos de esos límites. Por ejemplo, la seguridad de acceso del código de Microsoft .NET Framework es un límite de seguridad. Se ha diseñado específicamente para que el código que se ejecuta en el recinto de seguridad no afecte al sistema operativo subyacente.
Iframes en Internet Explorer proporciona otro límite de seguridad. Pero Iframes no afecta al acceso al sistema operativo, sólo al acceso entre las partes de contenido en una página web. El modo protegido en Internet Explorer, que se muestra en la figura 1, es un límite de seguridad de nivel de sistema operativo. Su finalidad es impedir que el código que se ejecuta en un explorador afecte al sistema operativo subyacente, sin intervención del usuario. Existen otros, como las cuentas de usuario estándar, que se supone que impiden que una cuenta de usuario afecte al sistema operativo subyacente o a otro usuario.
Figura 1 Internet Explorer 7 usa un límite de seguridad denominado modo protegido (haga clic en la imagen para ampliarla)
Es muy importante comprender lo que significa el término "límite de seguridad". No significa que haya una pared infranqueable que garantice un aislamiento impermeable e indefinido. Lo que el término significa realmente es que el fabricante de software, Microsoft por ejemplo, es responsable de corregir las infracciones de dicho límite mediante una revisión de seguridad. El software siempre tendrá errores y, sin duda, seguiremos descubriendo más infracciones que los fabricantes de software seguirán revisando. Con el tiempo, deben mejorar su software para evitar estas vulnerabilidades en primer lugar. Eso se puede considerar como una confirmación de que la ley 1 todavía sigue vigente.
No obstante, hay un elemento más esencial que debo tener en cuenta. Puede que anteriormente se haya dado cuenta de la frase "sin intervención del usuario". Realmente, la ley 1 no se refiere a defectos o vulnerabilidad del software. Realmente se refiere a las vulnerabilidades de las personas. La frase clave es "convencerle". Si uno de los malos puede convencerle para que ejecute su programa, probablemente le convencerá para que lo haga en un contexto que, por diseño, concede al programa privilegios elevados.
Incluso puede no importar que no tenga privilegios administrativos. Como usuario estándar tendrá acceso a mucha información sustancial: archivos bancarios, cartas de amor, imágenes, vídeos y datos confidenciales de la compañía. Todos estos datos tienen un interés potencial para un atacante y todos se pueden leer sin privilegios elevados. En lo que respecta a la información que administra en su equipo, la ejecución de un programa malintencionado entrega a un atacante todo lo que usted hace. Por lo tanto, si define "su equipo" como "los datos que administra en el equipo", puede ignorar las explicaciones acerca de los privilegios y simplemente concluir que la ley 1 sigue vigente.
Incluso sin hilar muy fino con respecto a la definición del equipo, la ley 1 parece haber resistido la prueba del tiempo. La cuestión de la ley 1 es establecer el hecho de que el usuario, como operador de un equipo, debe asumir la responsabilidad del software que se ejecuta en el equipo. Si instala un controlador malintencionado o un códec de vídeo malintencionado, le está entregando el control completo del equipo a un criminal.
Aunque los fabricantes de software pueden hacer mucho para prevenir los riesgos accidentales, a lo que realmente hacen referencia los límites de seguridad, la ejecución intencionada de software malintencionado por lo general superará todas las medidas de protección. Por este motivo el aprendizaje del usuario es fundamental, además de garantizar que los usuarios no tienen permiso para llevar a cabo tareas administrativas. Por lo tanto, se puede decir sin lugar a dudas que la ley 1 sigue vigente en la actualidad, pero posiblemente con una ligera modificación de la definición de equipo.
Ley 2: Si uno de los malos puede modificar el sistema operativo de su equipo, deja de ser su equipo.
A simple vista, esta ley parece bastante clara. Evidentemente, si uno de los malos puede modificar el sistema operativo de su equipo, ya no podrá confiar en él. Pero el significado de sistema operativo ha cambiado con la evolución de las necesidades de computación. Hace muchos años escribí una definición del término sistema operativo para The Blackwell Encyclopedia of Management (managementencyclopedia.com). En la definición se hablaba de un sistema operativo que administra el acceso a los dispositivos de entrada y de salida, el acceso al hardware y cuestiones similares. Ahora bien, nunca obtuve una copia de la enciclopedia y mi envío original se perdió en la historia, pero estoy seguro de que no mencioné que un sistema operativo incluye el solitario, un sistema de entrada por tableta y transcodificadores de vídeo.
A medida que se ha ido complicando la computación, los sistemas operativos se han ampliado para ofrecer más capacidades. Para complicarlo todo aún más, los OEM suelen incluir su propio surtido de software adicional, que normalmente va desde lo útil hasta lo francamente perjudicial. Y parte de este software adicional duplica la funcionalidad ya integrada en el sistema operativo principal.
Por ejemplo, una instalación predeterminada de Windows Server 2008 Enterprise Edition ocupa en disco más de 5 gigabytes. Windows Vista Ultimate Edition incluye más de 58.000 archivos que ocupan más de 10 gigabytes. Y hay algo más que simples archivos que componen el sistema operativo. Están las miles de opciones de configuración y los demonios o servicios.
Todos ellos forman parte del sistema operativo. Se trata de un término colectivo que incluye todos los archivos, todas las opciones de configuración y todos los servicios, así como todos los objetos de tiempo de ejecución (semáforos, canalizaciones con nombre, extremos de RPC) creados por los archivos y las opciones de configuración. Incluso las construcciones de elevada abstracción, como la hora del sistema y determinados tipos de datos, por ejemplo el contenido de los registros de eventos, se deben considerar parte del sistema operativo.
Si se tiene en cuenta lo que ha crecido y evolucionado el sistema operativo, ¿realmente se considera que al modificar cualquiera de estos archivos se resta confiabilidad al equipo? La respuesta directa es no. Por ejemplo, Windows Vista incluye edlin.exe, el antiguo editor de líneas de MS-DOS. No puedo afirmarlo a ciencia cierta, pero me apuesto un café triple grande que edlin.exe sólo se ha invocado un par de veces en todas las copias instaladas de Windows Vista desde que se publicó el sistema operativo. Ambas veces han sido hace tres minutos, cuando intentaba recordar la sintaxis. ¿Si alguien modifica edlin.exe o algún otro archivo que nadie usa jamás, significa realmente que ya no es su equipo?
Indiscutiblemente edlin.exe forma parte del sistema operativo, pero si nadie ejecuta el archivo, ¿cómo una modificación va a poner en peligro el equipo? Evidentemente, la respuesta es que no lo pondrá. La modificación de una parte del sistema operativo que nunca se usa no pondrá en peligro el equipo. Y hay numerosas partes del sistema operativo que nunca se usan.
No obstante, la respuesta indirecta es sí. No se puede tener en cuenta simplemente el hecho de si alguien ejecuta un archivo para considerar si su modificación puede poner en peligro el equipo. El problema es más sutil. Observe la lista de control de acceso (ACL) de edlin.exe, mostrada en la figura 2.
Figura 2 La ACL de edlin.exe es muy restrictiva (haga clic en la imagen para ampliarla)
La ACL de edlin.exe es muy restrictiva. Sólo el servicio TrustedInstaller tiene derechos para modificar dicho archivo ejecutable. Esto es muy importante: significa que hay un efecto indirecto para uno de los malos que modifique dicho archivo en su equipo. El acto de modificar edlin.exe no significa que ya no sea su equipo. Es el hecho de que el usuario malintencionado tiene la capacidad de modificar edlin.exe, que en este caso es clave. Si uno de los malos puede modificar el archivo, puede modificar cualquier archivo, lo que significa que ya no puede confiar en nada del equipo.
El sistema operativo se protegerá a sí mismo. Los servicios están protegidos contra la modificación no autorizada. Las opciones de configuración están protegidas contra la modificación no autorizada. Los archivos del disco están protegidos contra la modificación no autorizada. Incluso los semáforos y los extremos RPC que usa el sistema operativo están protegidos contra la modificación no autorizada. Si un atacante puede modificar cualquiera de estos objetos protegidos, podrá modificarlos todos y, muy posiblemente, ya lo habrá hecho.
Se trata de un punto crítico. Con varias de las leyes inmutables, no es el acto de hacer algo lo que significa que el equipo está en peligro. Lo que importa es que alguien tiene la capacidad de hacer algo. Esta cuestión no se debe obviar. En todos los aspectos de la seguridad de los equipos, siempre se debe recordar que la capacidad suele ser tan importante como la acción que se realice realmente.
Si un equipo está abierto a Internet y hace meses que no se le aplican revisiones, ¿sigue siendo de confianza? No. Se debe considerar que el equipo está en peligro. No se puede confiar en nada de un sistema que ha estado en peligro. (Dije lo mismo hace cinco años en mi artículo "Socorro. Me han atacado. ¿Qué debo hacer?" disponible en technet.microsoft.com/library/cc512587.) Si se enfrenta a un adversario hábil, puede que el sistema en peligro ni siquiera muestre signo alguno de que haya estado en peligro. El sistema puede parecer perfectamente normal.
Sin duda, la ley 2 todavía sigue vigente. Si un atacante tiene la capacidad de modificar un objeto protegido del equipo, deja de ser su equipo. Recuerde que es la capacidad de modificar estos objetos lo que importa, no si realmente se ha realizado el ataque.
Ley 3: Si uno de los malos tiene acceso físico sin restricción a su equipo, ya no es su equipo.
Esta ley fue esencial en el año 2000. Muchos usuarios no acababan de comprender lo que se podía hacer con el acceso físico a un sistema. De hecho, algunos organismos gubernamentales que debían tener un mejor conocimiento no tuvieron en cuenta esta cuestión fundamental. En aquel tiempo, la orientación de seguridad recomendaba deshabilitar la opción que permitía apagar sin iniciar sesión. Esto provoca que el botón Apagar… de la pantalla de inicio de sesión esté atenuado. La teoría subyacente es que para apagar el equipo, el usuario primero debe iniciar sesión para que haya un registro de auditoría de quién apaga el sistema.
Se trata de un caso práctico de idea errónea. Para tener acceso al botón Apagar… de la pantalla de inicio de sesión, hay que estar realmente delante de la consola. Y si está delante de la consola y realmente desea apagar el equipo, normalmente se usa el gran botón redondo que hay en la parte frontal del equipo o incluso el cable de alimentación. Sistema apagado. Sin seguimiento de auditoría.
Windows 2000 incluye una configuración de seguridad denominada Permitir desacoplamiento sin tener que iniciar sesión y esta opción sigue estando disponible en Windows Vista, tal y como se muestra en la figura 3. El principio es el mismo. Para desacoplar un equipo portátil de su estación de acoplamiento, primero se debe iniciar sesión en el sistema.
Figura 3 ¿Y por qué no robar el equipo y la base de acoplamiento? (haga clic en la imagen para ampliarla)
El valor real de la seguridad de esta configuración es muy dudoso. Pienso que la teoría es que si alguien puede acercarse al equipo portátil y desacoplarlo, le resultaría fácil robarlo. Ahora bien, no es que vaya a robar un equipo portátil, pero si fuera a hacerlo, esta medida preventiva no me disuadiría. Probablemente me llevaría el equipo y la estación de acoplamiento a la vez. Caramba, también robaría el cable de red y el de alimentación. Veamos una optimización de seguridad absurda.
La cuestión del acceso físico realmente me hizo pensar cuando Petter Nordahl-Hagen creó su Offline NT Password & Registry Editor. Su creación era simplemente un disco de arranque Linux con un controlador de sistema de archivos NTFS experimental que permitía el acceso de lectura y escritura a un volumen NTFS. El software del disco de arranque montaba el Registro del equipo local y escribía una nueva contraseña de la cuenta Administrador en la rama SAM (administración de activos de software). Todo lo que se necesitaba era acceso físico al sistema y uno o dos minutos.
La ley 3 se escribió principalmente debido a herramientas como ésta. De hecho, la herramienta de Nordahl-Hagen se usó en numerosas demostraciones. Por desgracia, la cuestión nunca trascendió a la inmensa mayoría de los usuarios. Personalmente he usado la herramienta en algunas demostraciones, pero dejé de usarla después de que me cansé de que me preguntaran, "¿cómo nos aseguramos de que ninguno de nuestros usuarios conoce herramientas como ésta?" y "¿qué hace Microsoft para corregir este problema?" Una parte alarmantemente grande del sector de TI no desea aceptar o comprender que el acceso físico acabaría con todo lo demás.
En ese entorno, la ley 3 constituyó una declaración muy importante. Aunque los críticos arremetieron contra ella sin piedad. Se ridiculizó como el intento de Microsoft para evitar tener que corregir cualquier problema que pudiera estar, incluso del modo más remoto, vinculado con el acceso físico. Realmente la ley 3 se usó en varios casos para descartar informes de vulnerabilidad, incluido el programa Offline NT Password & Registry Editor. No obstante, bloquear a los atacantes que tiene acceso físico al sistema sólo se puede hacer de un modo: garantizar que no puedan llegar.
Ahí es donde posiblemente se encuentre el punto débil de la ley 3. Desde que se escribieron las leyes, la tecnología de cifrado del disco completo se ha convertido en una solución viable. Con dicho cifrado, más correctamente denominado cifrado de volumen completo, se puede cifrar todo un volumen (que se denomina partición en otros sistemas operativos). Por lo tanto, si todo el volumen de arranque (es decir, el volumen que contiene el sistema operativo) está cifrado, nos debemos preguntar si la ley 3 sigue vigente.
La respuesta es un firme probablemente. En primer lugar, las claves de descifrado se tienen que almacenar en algún lugar. El lugar más simple para guardar las claves, y la opción predeterminada en BitLocker, es un chip Trusted Platforms Module en el equipo. De este modo, el equipo arrancará desatendido. Una vez iniciado el equipo, un atacante con recursos y bien financiado con control físico permanente al equipo puede atacarlo de varias formas. Debido a que el equipo ahora se puede conectar a una red arbitraria, puede haber formas relacionadas con la red de atacar el sistema.
Por ejemplo, el atacante puede leer o escribir en la memoria mediante un dispositivo de acceso directo a memoria (DMA), como una unidad flash USB. Una vez que el equipo está en funcionamiento, no hay nada imposible para un atacante con acceso físico al equipo.
Si las claves no están almacenadas en el equipo, el ataque dependerá de si el atacante puede obtenerlas o adivinarlas. Si se usa un código NIP para iniciar el equipo, el atacante probablemente podrá adivinar el código con relativamente poco esfuerzo. Si las claves se almacenan o derivan de un dispositivo de hardware independiente, como una unidad flash USB o un acceso de contraseña única, el atacante debe tener acceso a dicho dispositivo. Ciertamente hay formas de obtener estas claves o de incomodar a la persona que tiene acceso a ellas, aunque el esfuerzo necesario probablemente sea un poco mayor.
También se podría interpretar la ley 3 de un modo ligeramente distinto: "si el atacante tiene acceso físico a su equipo, es probable que haya robado el equipo y, por lo tanto, es improbable recuperarlo". Desde ese punto de vista, realmente ya no es su equipo. Y desde esa perspectiva, al atacante puede no importarle si puede obtener acceso al equipo o no. No obstante, realmente el espíritu de la ley 3 no se refiere a eso. Significa que el atacante ha tenido acceso a los datos del equipo y no sólo al equipo.
Bien mirado, la ley 3 todavía sigue vigente. Es cierto que determinadas tecnologías disponibles hoy en día llegan muy lejos para detener a muchos atacantes con acceso físico y, por lo tanto, reducir el número de atacantes que pueden obtener acceso a los datos de un equipo que emplea una medida de seguridad. Dicho esto, las capacidades del atacante siempre definen lo que realmente puede conseguir y las nuevas tecnologías resuelven muchas de las 10 leyes inmutables, hasta cierto punto. Pero el acceso físico todavía ofrece modos, aunque más complejos, de entrar en un sistema.
Hasta ahora, las leyes inmutables de seguridad han demostrado ser muy resistentes, tanto a los avances tecnológicos como al tiempo. De las tres primeras leyes, la tercera es la más dudosa, aunque todavía sigue vigente en algunos casos. Sin embargo, es a la que se han aplicado más soluciones disponibles inmediatamente y sólidas. Volveré en los dos próximos números de TechNet Magazine para seguir con esta explicación y determinar si las leyes 4 a 10 siguen siendo inmutables.

Jesper M. Johansson es un arquitecto de software que trabaja en el campo del software de seguridad y colabora como editor en TechNet Magazine. Posee un doctorado en sistemas de información de administración, más de 20 años de experiencia en el ámbito de la seguridad y es MVP de Microsoft en seguridad empresarial. Su último libro es Windows Server 2008 Security Resource Kit.


Notas de campo Código de barras de color de alta capacidad
Gavin Jancke

Todos estamos tan familiarizados con los códigos de barras que a menudo pasan inadvertidos; son casi omnipresentes en la vida cotidiana y aparecen por todas partes, desde el empaquetado de alimentos hasta en las etiquetas de envío. Los códigos de barras 1D originales que aparecían en el sector de la venta al por menor en 1974 comprendían barras verticales de ancho variable y almacenaban un número de 12 dígitos. Los códigos de barras evolucionaron conforme aumentaban las capacidades informáticas y en los últimos años de la década de los 80 se desarrollaron los códigos de barras 2D en blanco y negro (códigos matriciales), marcando un aumento en la densidad de datos desde tan solo unos pocos dígitos a varios cientos de bytes.
En 2003 comencé a trabajar en una tarjeta de identificación biométrica a prueba de falsificaciones para un proyecto de Microsoft Research. No sólo necesitaba almacenar el texto cifrado, como el nombre y la edad, sino también las huellas dactilares o las plantillas de digitalización del iris. Para almacenar todos los datos necesarios, el código de barras en blanco y negro existente habría sido mayor que la propia tarjeta de identificación, por lo que era evidente que se necesitaba un enfoque nuevo.
Tenía que determinar cómo almacenar más de un bit de información por símbolo, lo que había sido el estándar para los códigos de barras 2D en blanco y negro. Usando colores en lugar del blanco y negro, podría aumentarlo a dos o tres bits de datos con cuatro y ocho colores, respectivamente.
También experimenté con las formas del símbolo para ver si se podrían incluir juntos de forma más estrecha sin poner en peligro su registro al digitalizarlos. Inicialmente los hexágonos parecían una buena posibilidad pero las formas se entremezclaban y el equipo informático no las podía distinguir con suficiente claridad.
Me decidí finalmente por los triángulos porque forman una intersección perfecta en un espacio comprimido, a la vez que conservan su identidad como formas diferenciadas. Al usar filas de triángulos de varios colores, pude aumentar la capacidad de densidad en 3D.
Hubo muchos factores con los que me tuve que enfrentar. Uno de los mayores desafíos de trabajar con color es la desviación en las especificaciones de impresión y en las condiciones de iluminación. Aunque el color se puede distinguir fácilmente por el ojo humano (al menos por los usuarios que no son daltónicos), esto no resulta tan sencillo para un equipo.
Para garantizar que el software pudiera leer el color de manera precisa usé diferentes enfoques. Creé una paleta muy pequeña, casi imperceptible, dentro del código de barras con los colores de referencia que existían en el código de barras real. Esto proporcionó un mecanismo de calibración que especificaba exactamente lo que constituye un rojo en concreto, por ejemplo. También probé técnicas más avanzadas como algoritmos de agrupamiento por colores ligeros y personalizados que aprovechan la teoría del espacio para clasificar los colores en conjuntos. Ambos enfoques funcionan igualmente bien y se complementan.
Uno de mis objetivos para este proyecto fue escribir un programa que habilitara a los teléfonos móviles para leer los códigos de barras. Con los teléfonos móviles, hay que tener en cuenta la escasa iluminación y las lentes fijas, de longitud focal y desenfocadas. Un desafío adicional fue hacer toda esta visión de equipo en las CPU de teléfonos móviles relativamente lentas, basadas en enteros, de manera que el equipo del proyecto tuvo que proponer una teoría sólida sobre cómo detectar el código de barras en la imagen al tocar tan pocos píxeles como fuera posible. La digitalización tenía que funcionar dentro de un intervalo de calidad de lectura, como, por ejemplo, desde el enfoque brillante de los paneles LCD hasta una impresión física desenfocada y con poca iluminación.
El algoritmo final descodifica imágenes de código de barras en fotogramas de vídeo de cámara en tiempo real con mayor rapidez que la velocidad de fotogramas real: cerca de 10 m en una CPU de 200 Mhz. En una imagen, el número más pequeño de píxeles que un código de barras puede tener para la carga de datos más pequeña y que aún se puede detectar es de casi 45 píxeles cuadrados.
La realización de todo este trabajo junto con el perfeccionamiento del mismo bajo distintas condiciones llevó más de dos años. Recientemente se ha concedido la licencia de esta tecnología a terceros y, más adelante, este año, habrá algunas interesantes aplicaciones creadas a partir de ella.
Gavin Jancke, director de ingeniería para Microsoft Research, dirige los equipos del grupo de desarrollo avanzado y experiencia web. Anteriormente trabajó como ingeniero de soporte técnico, ingeniero de software para SQL Server y fue consultor técnico ejecutivo de Bill Gates.


Confidencial de Windows Trabajar más, no mejor
Raymond Chen

Para los desarrolladores de software, una de las grandes ventajas de Informe de errores de Windows es que pueden obtener información real acerca de los errores de sus programas. Estos informes de errores están disponibles para cualquier proveedor de software que se registre en línea en winqual.microsoft.com. Evidentemente que puede ejecutar todo tipo de pruebas en sus laboratorios, pero siempre hay un vacío entre las condiciones de laboratorio y las condiciones reales. Esto puede tener como resultado errores que nunca aparecen en las pruebas pero que enloquecen a sus clientes.
Hace unos años un programador al que se le había asignado una tarea del equipo de confiabilidad de su producto me contó una historia. El equipo deseaba resolver los motivos principales de los errores y los bloqueos en un determinado componente. Después de negociarlo, ambas partes acordaron establecer un objetivo de reducir el número de estos tipos de errores a la mitad. Deseaban corregir los errores responsables del 50% de los bloqueos de dicho componente, tal y como se cuantificaba en Informes de errores de Windows.
Todos sabemos que los errores no se distribuyen uniformemente. Algunos son esporádicos, otros son habituales y otros son inesperados (hablando de forma relativa). La ingeniería es cuestión de equilibrio; a partir de recursos finitos (tiempo, dinero y capacidad mental) se tienen que dedicar los esfuerzos donde tengan más efecto. Como el objetivo aquí era reducir el número de bloqueos, el enfoque sensato era estudiar los errores más habituales notificados por Informe de errores de Windows, descubrir la causa e intentar corregir esos errores habituales.
Informe de errores de Windows proporciona información real acerca de los errores de los programas (haga clic en la imagen para ampliarla)
Cuando el programador profundizó en los datos de error, resultó evidente que cinco bloqueos concretos suponían más del 60% de los informes. Si el programador podía corregir los errores que provocan estos cinco bloqueos, reduciría el número de bloqueos por un factor de 2,5, mucho más que el factor objetivo de 2.
El propio análisis de Microsoft de los datos de Informe de errores de Windows muestra que el principio de Pareto es una regla sorprendentemente buena para los bloqueos de Windows; cerca del 20% de los errores provocan el 80% de los bloqueos. El mismo estudio reveló un resultado aún más sorprendente: sólo el 1% de los errores provoca el 50% de los bloqueos. No todos los errores se crean por igual, pero resulta bastante revelador para saber lo desigual que es la distribución.
Después de estudiar estos cinco errores detenidamente, el programador llegó a la conclusión de que todos tenían la misma causa. Los bloqueos simplemente eran manifestaciones distintas del mismo error subyacente. Por lo tanto, desarrolló y probó una corrección y, conjuntamente con el personal de control de calidad, inició el proceso para incluir la corrección en la siguiente revisión. Con esa única corrección de error, el índice teórico de errores del componente descendió inmediatamente en un factor de 2,5. Cumplió su misión con una corrección de código relativamente sencilla.
Cuando escuché esta historia, me sorprendió que la curva de distribución de errores del componente era incluso más pronunciada que la de Windows. Más de la mitad de todos los bloqueos se debían a un solo error. Se trata del tipo de información del código que no es posible sin los datos obtenidos con alguna herramienta como Informe de errores de Windows.
Se podría pensar que el equipo de confiabilidad se quedaría estupefacto por haber cumplido su objetivo tan rápidamente. El objetivo acordado se superó en tan sólo dos semanas con una única corrección. En vez de eso, se enfadaron.
"Es inaceptable, esperábamos que se tardaría dos meses. ¡Ha sido demasiado fácil!" Aparentemente deseaban que el programador trabajara más intensamente, no mejor.
En el sitio web de Raymond Chen, The Old New Thing, y en su libro homónimo se trata la historia de Windows y la programación Win32. El 20% de su ropa es el responsable del 80% de su colada.