Share via

Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Requerimientos: Almacenamiento

  • Article

Posts anteriores:

Hola

Sin ningún lugar a dudas, el almacenamiento es una de las piezas clave a la hora de hablar de virtualización. El hecho de virtualizar un servidor no implica que la carga de trabajo que corra en el vaya a tener un patrón de uso del almacenamiento diferente al que utilizaría en físico. Y lógicamente, cuanto mayor sea la densidad de máquinas virtuales, mayor será la superposición de dichos patrones del host de virtualización hacia el sistema de almacenamiento. Hable de este tipo de cosas en este post acerca de los Cluster Shared Volumes:

Para el caso que nos ocupa, si queremos probar las funcionalidades de HA y Live Migration necesitaremos contar con almacenamiento compartido al cual accederán los hosts por Fiber Channel y/o iSCSI

NOTA: El uso de sistemas NAS basados en CIFS/NFS, si bien funciona con Hyper-V, no está oficialmente soportado por ahora. Para más información al respecto, este es el post de referencia, de la mano de nuestro compañero José Barreto: Failover Clustering for Windows Server 2008 Hyper-V with File Server Storage

En el caso de nuestro laboratorio, todo funciona a través de iSCSI (mucho más barato que FC) contra dos sistemas de almacenamiento. Uno de ellos está basado en Windows Storage Server 2008, que incluye el Microsoft iSCSI Target, y el otro es una cabina SAN que amablemente nos presta NetApp. Tenemos montados laboratorios similares basados también en cabinas Dell Equalogic, y EVAs y MSAs de HP (tengo muchas ganas de probar también las Lefthand). También conozco casos de entornos basados en otros Targets iSCSI basados en software, como los de StarWind.

El esquema que hemos seguido es el siguiente:

Laboratorio y Demo Center

  • Todos los servidores usan sus discos locales únicamente para la partición padre. En algún caso los hemos montado arrancando directamente de la SAN, en cuyo caso los discos locales se configuran para uso del fichero de paginación
  • Los servidores stand-alone tienen asociadas una o varias LUNs del almacenamiento compartido, donde se almacenan la máquinas virtuales
  • Los servidores que son miembros del cluster tienen presentadas las LUNs correspondientes al quorum y a los CSVs que utilizaremos para almacenar las máquinas virtuales. También es posible configurar máquinas virtuales clusterizadas que hagan uso exclusivo de sus propias LUNs.
  • Hay máquinas virtuales que tienen necesidades de almacenamiento particulares, y a las que servimos directamente almacenamiento compartido de las cabinas. En nuestro caso lo hacemos mediante el iniciador iSCSI del propio sistema operativo, pero también podríamos hacerlo por pass-through, que el la única opción que tendríamos en el caso de usar Fiber Channel. Por ejemplo
    • La VM con SCVMM tiene una LUN para almacenar las máquinas virtuales almacenadas en la biblioteca y las plantillas
    • La VMM con Data Protection Manager tiene una LUN donde se almacenan las copias de seguridad de las máquinas virtuales
    • La VM de MED-V tiene una LUN para albergar las máquinas virtuales que se distribuirán a los clientes (para los que no lo conozcáis MED-V es la versión empresarial del XP Mode)
    • La VM con Citrix Provisioning Server tiene una LUN dnde se almacenan los VHDs que constituyen las “golden images” que usan ciertas máquinas virtuales de los pools para trabajar.

La obsesión de tener todo almacenado en la SAN es sencilla de entender. Rinde estupendamente y si además tu cabina deduplica, los ahorros de espacio son sencillamente espectaculares. Por otro lado, recordemos que queremos la máxima granularidad y aislamiento entre las piezas. Si alguien se carga algún servidor físico, o lo cambias por otro de diferentes características, sus máquinas virtuales no están en los discos locales. Y si alguien borra inadvertidamente alguna de las máquinas virtuales mencionadas anteriormente, sus datos críticos siguen disponibles en espera de que aprovisionemos un nuevo servidor virtual o restauremos el backup, que será mucho más ligero al carecer de un gran volumen de datos.

La conexión de los servidores físicos con el almacenamiento es una de las primeras tareas que hay que abordar en el montaje de estos entornos, y la experiencia dice que suele ser uno de los principales escollos técnicos. He aquí algunas pistas y trucos que pueden hacer que el proceso sea más sencillo:

  • Conviene tener bien a mano los drivers recomendados por el fabricante del servidor para las NICs y/o las HBAs. Por lo general existen las versiones del fabricante del servidor, certificadas para su hardware, y las del fabricante de los propios adaptadores. Es preferible comenzar utilizando siempre los primeros.
  • Agrega el framework de Multipath del propio sistema operativo. Esta como funcionalidad en el Server Manager. Si algún elemento del almacenamiento requiere algún elemento adicional específico lo agregará durante su instalación
  • Instala a continuación el Device Specific Module (DSM) de la cabina que vayas a utilizar. Un síntoma claro de que falta este elemento es ver el mismo disco varias veces en el administrador de discos (tenemos varios caminos al almacenamiento y  no sabemos como manejar la situación pese a tener el framework Multipath instalado)
  • Puede ser interesante instalar también los Hardware Providers tanto de VDS (Virtual Disk Service) como de VSS (Volume Sahdow Copies)del almacenamiento en particular.
  • Inicializa los discos, ponlos online y formatealos con NTFS antes se intentar utilizarlos :-)

Todas estas operaciones pueden llevarse a cabo antes o después de haber agregado el role de Hyper-V. Se siga el orden que se siga, si que es interesante haber pensado, antes incluso de instalar los hosts, acerca de qué tipo de almacenamiento vamos a tener a nuestro disposición y cómo vamos a utilizarlo. Como hemos dicho al principio, es una de las piezas claves a tener en cuanta a la hora de planificar lo que vamos a poder hacer y lo que no.

Saludos

David Cervigón