Virtualización del escritorio: Atención de los entornos virtuales

  • Artículo

Wes Miller

La virtualización ha evolucionado de una anomalía que requería explicación a una tecnología viable sin la cual la mayoría de nosotros no podemos vivir. Quizás usted la usa para las pruebas de control de calidad, el desarrollo, la capacitación o el diseño web. Tal vez forma parte de la vanguardia y marca tendencia con la implementación de una infraestructura virtual, o forma parte de las masas que usan la virtualización en “nube” de Amazon.com, Rackspace Inc. u otro proveedor de nubes.

No importa como utiliza la virtualización, si la ha usado durante un tiempo, sin dudas se ha dado cuenta de que tiene sus propios desafíos, así como el mantenimiento físico del hardware tiene sus dilemas. Algunas cuestiones son diferentes; otras similares.

Manejo de los hipervisores

Probablemente ha oído circular bastante la palabra “hipervisor”. Se ha convertido en uno de los términos de moda de la virtualización. Aunque los hipervisores no son nuevos. Los hemos utilizado desde que se crearon las máquinas virtuales (VM). De hecho, IBM acuñó el término hipervisor en la década de 1970.

El hipervisor es el software que hace que se ejecuten “virtualmente” los invitados en un sistema mediante un conjunto de hardware virtualizado. Abstrae el hardware físico para los SO invitados. La confusión se genera a partir del gran impulso de la ejecución de “hipervisores de tipo 1” en la plataforma x86 de los últimos años, entre ellos, Microsoft Hyper-V y VMware ESX Server. El hipervisor que la mayoría de la gente utiliza, especialmente en los sistemas cliente, se conoce como “hipervisor de tipo 2”. ¿Cuál es la diferencia?

  1. Un hipervisor de tipo 1 se ejecuta directamente en el hardware del host y no requiere un “SO para el host”. Microsoft Hyper-V y VMware ESX Server son los ejemplos más comunes de hipervisores de tipo 1.
  2. Un hipervisor de tipo 2 requiere un SO en el host para funcionar. Por lo general, un hipervisor de tipo 2 se ejecuta principalmente como aplicación de modo de usuario en el SO del host. Microsoft Virtual PC y VMware Workstation son los ejemplos más comunes de hipervisores de tipo 2.

La mayoría de las veces, querrá usar un hipervisor de tipo 1 para las cargas de trabajo “permanentes”, como un servidor de archivos o SQL virtualizado. Como mínimo, consumirá menos recursos que un hipervisor de tipo 2. Sin embargo, según el host, es posible que requiera que el usuario inicie sesión para arrancar, lo que no representa una buena opción para los sistemas esenciales. Por otra parte, los hipervisores de tipo 2 son más lógicos para las VM “a pedido”. Este tipo de función incluye pruebas, compatibilidad de aplicación y acceso seguro para las VM.

¿Qué puede economizar con la virtualización?

La respuesta obvia es que con la virtualización se ahorra dinero en hardware, pero no es tan simple. Indudablemente, si tiene dos sistemas de servidores en factores de forma 1U montados en bastidor y se encarga de las dos cargas de trabajo en el sistema 1U, habrá economizado los costos iniciales de hardware... pero esto encierra un truco. Esos dos mismos sistemas de servidor operan felizmente en dos servidores 1U individuales, donde cada uno cuenta con una CPU de doble núcleo, 2 GB de RAM y un disco duro SATA de 160 GB.

Ahora, si pone ambos sistemas en un servidor con la misma configuración de hardware, deberá dividir los recursos por la mitad, ¿no? Normalmente necesitará más recursos para un hipervisor de tipo 2.

Debe tener en cuenta los costos necesarios de CPU, RAM y HDD para determinar la consolidación de cargas de trabajo de físicas a virtuales. La consolidación virtualizada generalmente se denomina “apilamiento de sistemas vertical en lugar de horizontal”, dado que se elimina la dependencia de n sistemas físicos del OEM. A su vez, le solicita mucho más a un sistema individual que antes de la virtualización. Esto genera un rebote en la administración de sistemas que muchas organizaciones pasan por alto porque se precipitan hacia la virtualización.

¿Cuánto cuesta la virtualización?

Alguna vez, un buen software de virtualización costó bastante dinero. Con el correr del tiempo, el mercado se calentó y se pueden obtener distintos tipos de software de virtualización a bajo costo. Sin embargo, la mayoría de las funciones empresariales más importantes aún cuestan dinero, incluido el SO del host o el hipervisor.

Según la carga de trabajo que desee ejecutar en la VM, es posible que deba analizar la conmutación por error. Los invitados a veces se corrompen y el hardware del host puede fallar. La virtualización no hace que el hardware sea más confiable. Sólo cambia las probabilidades. En los sistemas principales, aún debe desarrollar una estrategia de respaldo del SO invitado, ya sea creando copias de seguridad del contenedor mismo de la VM (totalmente recomendado) o del sistema de archivo que contiene.

Incluso si desea virtualizar sólo un grupo de SO invitados para probar o implementar en un hipervisor de tipo 2, deberá asignar suficiente RAM a fin de ejecutar un invitado o más a la vez (aparte del SO del host). El problema ignorado con mayor frecuencia durante la administración de la virtualización es el consumo de espacio del disco.

Personalmente, he utilizado la virtualización como prueba de seguridad. Nada supera ejecutar una posible vulnerabilidad en una VM, verla trabajar y revertirla a una versión anterior utilizando la funcionalidad de instantáneas o reversión, sólo para volverla a probar. Pero lo más lindo de apilar los cambios de reversión uno sobre otro es que el espacio del disco puede salirse de control rápidamente. Puede terminar excediendo el tamaño real del disco duro dentro del SO invitado.

Una de las VM que uso tiene una imagen de disco duro de 50 GB. No me había dado cuenta hasta qué punto se había salido de control hasta que intenté moverla (tenía seis instantáneas de VMware) y el disco tenía más de 125 GB.

 Las siguientes son algunas prácticas recomendadas para minimizar el impacto/costo de la virtualización:

  • Si utiliza un SO cliente de Windows en un hipervisor de tipo 2 con la funcionalidad de “reversión”, deshabilite la restauración del sistema de Windows sin falta. De lo contrario, el disco aumentará de tamaño cada vez que modifique el sistema.
  • Si realiza el paso 1, determine puntualmente cuándo desea crear un punto de reversión.
  • Si realiza una prueba de seguridad/vulnerabilidad, no confíe en que Windows lo revierta a un momento dado anterior. Use la funcionalidad de reversión de su hipervisor, ya que raramente puede corromperse como los puntos de restauración.
  • Ejecute los SO invitados con la menor cantidad de recursos necesarios.
  • Asegúrese de asignar suficiente RAM para que los SO cliente no alternen entre la RAM y el disco constantemente. Esto puede enlentecer su host y todos sus invitados.
  • Desfragmente sus invitados internamente y luego externamente (consulte la sección de desfragmentación más adelante). Realice ambos procesos con cierta regularidad.

Proliferación de la VM

Como puede ver, la administración de VM rápidamente puede convertirse en un problema. La fácil duplicación de las VM puede ser un gran beneficio, pero también puede generar muchos problemas respecto de la administración y seguridad de los invitados, el seguimiento de las licencias de los SO de Windows (en las versiones anteriores a Windows Vista, la nueva administración de claves realmente puede considerarse un beneficio) y la garantía de que los secretos comerciales no se escapen de su alcance. Es mucho más sencillo para un empleado deshonesto llevarse una VM a través de una unidad flash USB o un disco duro USB que intentar llevarse un sistema de escritorio completo.

La proliferación de la VM es un problema mucho más importante para los más técnicos (que comprenden el núcleo de la virtualización). En general, es más importante entre los invitados cliente que entre los servidores virtuales invitados.

Administración de sistemas

Compañías enteras han comenzado a centrarse en recuperar el control de los sistemas virtualizados. Tanto Microsoft como VMware se han centrado menos en el valor de la virtualización y más en la administración de sistemas. Esto es importante porque no se deshace de los sistemas, los virtualiza.

Muchos productos de administración de sistemas pueden funcionar perfectamente bien en las VM, pero existen nuevas funcionalidades que permiten una administración más inteligente de los sistemas virtualizados, como la reactivación y la actualización de invitados que, de otro modo, no podrían actualizarse. En la era de la vulnerabilidad de día cero, esto es fundamental. Lo último que necesita es que una VM de poco uso se convierta en un botnet local representativo de su red corporativa.

Su enfoque de administración de sistemas debe tener en cuenta que usted tiene hosts e invitados, garantizar su actualización correspondiente y el conocimiento de las funciones de cada uno. Lo último que quiere es que una solución de administración de revisiones mal diseñada actualice su hipervisor y lo destruya en medio del día de reinicio, llevándose cuatro servidores invitados principales consigo.

También debe abordar la recuperación de dichos sistemas de la misma manera que lo ha hecho siempre. Sólo porque un sistema está actualizado no significa que no puede perderlo debido a la corrupción del registro o de la VM completa... Puede perderlo. Realice copias de seguridad con el mismo fervor que dedica a los actuales sistemas físicos.

Otra consideración que debe tener en cuenta es si su hipervisor posee la funcionalidad de reversión. Recuerde cuándo considerar la administración de revisiones. Es fácil actualizar un invitado un miércoles después de la revisión del martes, revertirlo hasta el punto de reversión del lunes para ser atacado en el día cero que, en teoría, estaba “protegido”. Se trata de un grave problema, dado que las tecnologías de reversión funcionan mediante la reversión hasta un punto anterior de toda la presentación del disco del hipervisor, lo que significa que perderá cualquier revisión de aplicaciones y de Windows, así como cualquier firma de antivirus.

Software de seguridad

Además de la funcionalidad de reversión, debe proporcionar la misma protección de seguridad a los invitados virtualizados que a las máquinas físicas, y más. Cuando se trata de amenazas entrantes, las VM son tan susceptibles como las máquinas físicas, no hay diferencia.

La principal distinción es que las VM secundarias (las que no son permanentes) a menudo tienen latencia respecto de la revisión y actualización de AV. En consecuencia, pueden convertirse en mayores destinos de vulnerabilidad de día cero imposibles de seguir. Esta es la razón principal por la que debe garantizar el uso de una solución de administración de sistemas completa que tenga esto en cuenta y revise también los sistemas virtuales.

Las amenazas salientes son otra cosa. Las VM pueden ser entradas de robo de propiedad intelectual. Es fundamental comprender esto porque las VM que se ejecutan en hosts no controlados pueden generar la vulnerabilidad de sus datos. En primer lugar, si se puede copiar con facilidad el entorno virtual, es un problema, especialmente si cuenta con requisitos de cumplimiento que controlan el acceso a los datos (como mencioné en un artículo de 2008 (https://technet.microsoft.com/magazine/2008.06.desktopfiles).

Segundo, como puede recordar de mi artículo sobre RMS e IRM (https://technet.microsoft.com/magazine/2008.11.desktopfiles), estos controles dependen de que el SO evite la captura de pantalla, impresión, etc. No obstante, dichos controles no llegan al hipervisor. Esto significa que, si el contenido protegido por RMS se muestra en el SO invitado, el SO del host aún puede imprimir capturas de pantalla individuales o crear una captura de video de la pantalla.

Aunque no es técnicamente análogo, no es muy diferente del “agujero analógico”. No conozco ninguna forma de proteger el contenido controlado por DRM de este tipo de vulnerabilidad. Realmente, aunque pudiera, volvería al problema de proteger dicho contenido de usuarios con cámaras o cámaras de video que puedan realizar la misma “vulneración”.

Desfragmentación del disco

La desfragmentación del disco es un desafío exclusivo de las VM por distintos motivos:

  1. Normalmente tendrá dos niveles de fragmentación, dentro del mismo contenedor del disco virtualizado (fragmentación de los invitados que cada uno ve en su nombre) —que yo llamo “fragmentación primaria”— y fragmentación del archivo que en verdad contiene el disco virtualizado entre los discos del SO del host —“fragmentación secundaria”.
  2. La virtualización de productos con discos que tienen el tamaño mínimo requerido y aumentan “a pedido” puede conducir a la fragmentación secundaria.
  3. La funcionalidad de reversión puede conducir rápidamente no sólo a la saturación del disco, sino a la fragmentación secundaria masiva dado que, como consume espacio adicional del disco del SO del host, cada invitado comienza a competir por los sectores disponibles.
  4. Respecto de los discos que aumentan a pedido, la mayoría no tiene la capacidad de reducirse cuando disminuye la demanda. Si asigna 40 GB, use sólo 10 GB al principio, porque una vez que aumente hasta los 35 GB requeridos, el disco no se recuperará por sí mismo. Esto significa que tendrá un archivo grande que probablemente conlleve a la fragmentación secundaria.

El tamaño total de los discos virtuales, la velocidad de cambio, la disminución o el aumento, y el hecho de que son susceptibles a dos tipos de fragmentación significa que debe tomarlos más en serio que a los sistemas físicos.

Este es un enfoque de protección para sus archivos:

  1. Minimice el uso de cualquier tecnología de reversión, ya que causará el aumento excesivo de los archivos del disco en general y no podrá desfragmentarse en el invitado, aunque el host pueda desfragmentar los archivos que forman parte del disco virtual.
  2. Utilice un buen producto de desfragmentación del disco en sus invitados para comenzar y ejecútelo regularmente.
  3. Si usa la tecnología de expansión del disco a pedido:
    a. Use la utilidad Sysinternals sdelete.exe de la siguiente manera: sdelete –c drive_letter, donde drive_letter significa el volumen que desea llevar a cero. Por ejemplo, sdelete –c C: volverá a cero todo el espacio de disco no utilizado después de la desfragmentación.
    b. Use cualquier tecnología de disminución de disco virtual (si la proporciona su proveedor) para reducir el contenedor del disco virtual a su tamaño mínimo.
  4. Desfragmentación de los volúmenes de SO del host que contienen las VM.

Muchas personas hacen caso omiso de la desfragmentación del disco. La cantidad total de correos de lectores que recibí respecto de mi artículo sobre la desfragmentación del disco de 2007 (technet.microsoft.com/magazinebeta/2007.11.desktopfiles) me demostró que, a menudo, es un tema mal comprendido, pero que no debe ignorarse, incluso en los sistemas virtualizados.

A medida que el uso y la importancia de la virtualización siguen aumentando, es muy fácil dejarse arrastrar por su mensaje “consolidado” sin comprender los costos y sus inesperadas complejidades inherentes. Esto debería ayudarlo a descubrir los costos adicionales que debe tener en cuenta al momento de migrar a o convivir con la virtualización.

Wes Miller es director de administración de productos en CoreTrace (CoreTrace.com) en Austin, Texas. Anteriormente, trabajó en Winternals Software y fue administrador de programas de Microsoft. Puede ponerse en contacto con Miller en technet@getwired.com.

Contenido relacionado