NetApp Tech OnTap
     

Caso práctico: Lecciones aprendidas con
Hyper-V y NetApp

En Avanade, el éxito de nuestro negocio se basa en la calidad con la que nuestros asesores globales satisfacen las necesidades de los clientes. Para ello, hemos invertido en aplicaciones y servicios de TI que proporcionan todas las herramientas digitales necesarias para alcanzar nuestros objetivos. Una de las principales razones que nos motivó a adentrarnos en el campo de la virtualización de servidores con Microsoft® Hyper-V™ fue la flexibilidad que ofrecía para casos de disponibilidad y recuperación ante desastres. Al combinarlo con un entorno de gestión de almacenamiento compartido, consideramos que este tipo de arquitectura permitiría que nuestras aplicaciones y servicios recurrieran a otro nodo local y se replicaran en un centro de datos remoto, lo que nos protegería de fallos generalizados.

Aunque existieron otros factores que impulsaron la transición a Hyper-V, la flexibilidad de restauración y recuperación de entornos de servidores virtuales en operaciones de recuperación ante desastres fue el motivo definitivo para que nuestro CIO se decantara por esta importante inversión. Entre los factores que complementaron la decisión de adoptar Hyper-V destacan la necesidad de:

  • Reducir los costes de nuestros centros de datos (espacio de bastidor, refrigeración y alimentación) sin reducir la calidad de los servicios prestados
  • Optimizar el uso de nuestros recursos de servidor más eficaces
  • Implementar con mayor rapidez nuevos entornos de servidores de aplicaciones

Nuestro objetivo era hacer avances en todas estas áreas. De ese modo, nos inscribimos como usuario beta de la versión de Windows Server® 2008 con Hyper-V de Microsoft, que todavía no había sido lanzada al mercado. Y ahí fue cuando comenzó el trabajo real.

Nuestra implementación de Hyper-V

Antes de describir la naturaleza de nuestro entorno Hyper-V actual, nos centraremos en nuestra infraestructura de TI anterior. Nuestro entorno se compone de tres centros de datos (en Estados Unidos, Europa y Asia) y la mayoría de los servicios de aplicaciones empleados por nuestros asesores corresponden al centro de datos de Seattle, en Estados Unidos. Cuando iniciamos la implementación de Hyper-V, contábamos con más de 200 servidores distribuidos para sustentar las actividades de los más de 8.000 profesionales de Avanade.

Como Avanade es una sociedad conjunta formada por Microsoft y Accenture, nuestro entorno de TI se basa principalmente en aplicaciones de Microsoft para realizar las operaciones de campo y generales de la empresa. Estas aplicaciones incluyen una instalación de Microsoft Office SharePoint® Server, Microsoft Exchange, Microsoft SQL Server®, Microsoft Team Foundation Server, Microsoft Terminal Services y 120 líneas de aplicaciones de negocio de múltiples líneas que utilizan interfaces Web.

Para optimizar los resultados de nuestro futuro entorno de servidores virtuales, decidimos combinar Microsoft Hyper-V con una infraestructura de almacenamiento compartido. Ya disponíamos de almacenamiento NetApp® con iSCSI para nuestra infraestructura de SQL Server. Por ello, era natural recurrir a NetApp para acometer también la implementación en ciernes de Hyper-V. Nos atraía la flexibilidad del sistema y la eficacia de tecnologías como NetApp Snapshot™ y SnapMirror® para la protección y replicación de datos. Nos habíamos acostumbrado a poder provisionar rápidamente almacenamiento para las nuevas aplicaciones, además de comenzar a reclamar parte de nuestra capacidad mediante el uso de deduplicación de NetApp en el sistema de almacenamiento primario.

En este caso, esperábamos que NetApp resultara tan adecuado para Hyper-V como lo había sido en el resto de entornos. Las pruebas de rendimiento realizadas con Hyper-V y NetApp sobre iSCSI confirmaron que obtendríamos el elevado rendimiento que necesitábamos en una combinación NetApp/Hyper-V.

Tras nuestra decisión de seguir adelante, la implantación de Hyper-V se había realizado en dos áreas: producción y en nuestro entorno de pruebas y desarrollo. A continuación le mostramos algunas de las características principales de nuestra instalación actual.

Entorno de producción

  • Microsoft Hyper-V para Windows Server 2008, Core Installation, Enterprise Edition
  • Configurado como cluster Hyper-V de cuatro nodos
  • 27 particiones secundarias (máquinas virtuales)
  • Aplicaciones virtualizadas ejecutadas en el sistema operativo Windows Server 2003 o Windows Server 2008
    Aplicaciones virtualizadas
  • Team Foundation Server
  • Systems Center Operations Manager 2007
  • Microsoft Windows Server 2008 Terminal Services (incluidos TS Farm y TS Gateway)
    Servidores y almacenamiento
  • Servidores Sun Fire X4150, con dos procesadores de cuádruple núcleo y 32 GB de RAM
  • Sistema de almacenamiento FAS3040 de NetApp configurado con el protocolo iSCSI

Entorno de desarrollo y pruebas

  • Microsoft Hyper-V para Windows Server 2008, instalación completa, Enterprise Edition
  • Un cluster de cuatro nodos
  • Un cluster de dos nodos
  • Tres servidores independientes
  • Más de 150 particiones secundarias (máquinas virtuales) entre los hosts Hyper-V de desarrollo y pruebas
    Aplicaciones virtualizadas
  • Diferentes, incluidas aplicaciones en producción
    Servidores y almacenamiento
  • Servidores Dell 2950, con dos procesadores de cuádruple núcleo y 32 GB de RAM
  • Sistema de almacenamiento FAS3020 de NetApp configurado con el protocolo iSCSI

VMware DRS

Figura 1) Sistema de NetApp para el cluster Hyper-V de cuatro nodos de Avanade.

Decisiones en la adopción de Hyper-V

Al recordar las experiencias vividas durante el proceso de implementación, puedo ver cómo el enfoque que mantuvimos ante determinados aspectos esenciales fue determinante para el éxito global del proyecto. Entre estos se incluyen:

  • Decidir la edición de Microsoft Windows Server 2008 que implementaríamos, la edición completa de la edición de Windows Server Core, más reducida
  • Determinar la configuración del sistema NetApp para utilizar los ficheros de disco duro virtual (VHD) de las particiones secundarias de Hyper-V
  • Desarrollar un proceso que nos permitiera provisionar y conectar con rapidez un nuevo disco duro virtual a un nodo Hyper-V existente

Elección de Microsoft Windows Server 2008 Core Edition
Nos llevó cierto tiempo determinar si debíamos utilizar o no Server Core o la edición completa de Windows Server 2008. Sabíamos que desde una perspectiva de seguridad, Server Core ocuparía mucho menos espacio, de modo que la necesidad de parches sería menos frecuente. Era un aspecto importante, ya que cada host tendría en última instancia 10, 15 ó 20 máquinas virtuales. Para garantizar la alta disponibilidad de máquinas virtuales, pretendíamos minimizar la cantidad de reinicios necesarios en los servidores host.

Sin embargo, Server Core disponía de una interfaz de línea de comandos, lo que resultaba un tanto intimidatorio para nuestro personal de asistencia técnica. Nos preguntaban cómo podrían gestionarlo o solucionar cualquier problema que pudiera surgir. Tras numerosas negociaciones y conversaciones, nos decantamos por Server Core. Resultó ser una gran decisión. Después de su compilación, su funcionamiento resultó excelente, con una sólida infraestructura. Nuestro personal de asistencia podía seguir utilizando herramientas estándar para Windows Server 2008, incluidos snap-ins de MMC y herramientas de gestión de servidores remotos. Tras esta experiencia, todos nos convertimos en acérrimos defensores de Server Core.

Configuración del almacenamiento de NetApp para utilizar discos duros virtuales y particiones secundarias de Hyper-V

Sabíamos que la deduplicación de NetApp y la tecnología Snapshot funcionaban con volúmenes, de modo que decidimos crear el almacenamiento para nuestras particiones secundarias de Hyper-V de tal modo que aprovecharan al máximo estas características.
Debido a la gran cantidad de datos redundantes entre instancias del mismo sistema operativo guest, esperábamos obtener un ahorro significativo al ejecutar la deduplicación de NetApp en un volumen de desarrollo y prueba con discos duros virtuales de Hyper-V. Estuvimos encantados al conseguir un ahorro de espacio del 50%. Nuestro siguiente objetivo es implementar la deduplicación en nuestro entorno de producción. Con estas características para volúmenes, adoptamos las siguientes prácticas:

  • Particiones secundarias agrupadas ejecutadas en el mismo sistema operativo invitado con el mismo volumen flexible de NetApp (FlexVol®).
    En nuestro entorno de producción, esto significaba que las particiones secundarias de Windows Server 2003 estarían en un mismo volumen, mientras que las particiones de Windows Server 2008 estarían en otro. (En nuestro entorno de desarrollo y pruebas, se trata de una regla flexible , ya que podemos utilizar la tecnología Snapshot de NetApp para realizar backups o restaurar un entorno completo para realizar pruebas adicionales. En este caso, el entorno estaría formado por más de un sistema operativo invitado.)
  • Adopción de una asignación 1:1 de disco duro virtual a LUN.
    En cada partición secundaria, existe un LUN asociado que almacena los ficheros de disco duro virtual (VHD) de dicha partición, junto con los datos relacionados. Para reforzar la independencia entre las particiones secundarias, esta asignación 1:1 implica que ninguna partición secundaria comparte un LUN con otra partición secundaria. Sin embargo, muchos LUN (y discos duros virtuales) pueden existir en el mismo volumen de NetApp.
  • Uso de GUID de volumen de Microsoft para asignar un identificador exclusivo a cada partición secundaria.
    Debido a la presencia de numerosas máquinas virtuales en nuestros clusters de Hyper-V, las letras de unidades se agotaban rápidamente. El uso de puntos de montaje no era factible, ya que se generarían dependencias no deseadas entre discos. Nuestra estrategia consistió en utilizar GUID de volumen para identificar a los discos en los clusters. En lugar de almacenar un LUN en una unidad con letra como, por ejemplo, la unidad E:, optamos por no seleccionar ninguna letra. De este modo, se genera una asignación de GUID similar a la siguiente:  \\?\Volume{c9612f6f-702e-11dc-b79a-00123f769676}\.

En los siguientes apartados veremos la configuración actual del almacenamiento en nuestros entornos de producción, desarrollo y pruebas.

Configuración de almacenamiento para entornos Hyper-V de producción
Dos volúmenes flexibles de NetApp (FlexVol) que almacenan los datos asociados a cada partición secundaria. Los ficheros de disco duro virtual de las particiones secundarias se configuran en Hyper-V como ficheros de “disco duro virtual fijo” para optimizar el rendimiento. Sabíamos que podríamos ahorrar espacio adicional con la tecnología de deduplicación de NetApp que los clientes esperan cuando utilizan discos duros virtuales dinámicos.

Volumen 1:

  • Almacena datos para siete particiones secundarias de Windows Server 2003 (máquinas virtuales), donde los datos de cada una de ellas se almacenan en su propio LUN iSCSI
  • El volumen dispone de 500 GB de capacidad de almacenamiento general
  • El volumen se utiliza actualmente al 48%

Volumen 2:

  • Almacena datos para 20 particiones secundarias de Windows Server 2008, donde los datos de cada una de ellas se almacenan en su propio LUN iSCSI
  • El volumen dispone de 1,25 TB de capacidad de almacenamiento general
  • El volumen se utiliza actualmente al 76%

Configuración del almacenamiento en entornos de desarrollo y pruebas.
Más de 30 volúmenes flexibles de NetApp (FlexVol) almacenan datos de desarrollo o pruebas asociados a particiones secundarias. Los ficheros de disco duro virtual de las particiones secundarias se configuran en Hyper-V como ficheros de “disco duro virtual dinámico” para facilitar su cambio de tamaño durante las fases de prueba y desarrollo.

Volumen 1: Utilizado en desarrollo

  • Almacena datos para 25 particiones secundarias de Windows Server 2008
  • Los datos de cada partición secundaria se almacenan en su propio LUN iSCSI
  • El tamaño de los LUN oscila entre 40 y 100 GB
  • El volumen dispone de 600 GB de capacidad de almacenamiento general
  • El volumen se utiliza actualmente al 39%

~32 volúmenes: Utilizados por los equipos de desarrollo y pruebas

  • Los volúmenes almacenan colectivamente datos para 100 particiones secundarias de Hyper-V de Windows Server 2008
  • Los datos de cada partición secundaria se almacenan en su propio LUN iSCSI
  • El tamaño medio de los LUN es de 20 GB
  • Cada volumen dispone de tres LUN de media
  • Los volúmenes disponen colectivamente de 2,5 TB de capacidad de almacenamiento general

Provisionamiento rápido de nuevos LUN y discos duros virtuales (VHD)
Un aspecto que nos atraía de NetApp es la flexibilidad del array de almacenamiento back-end. Desarrollamos una forma sencilla de autoprovisionar nuevos LUN y conectar un nuevo disco (VHD) a un nodo Hyper-V en cinco minutos. Desarrollamos un conjunto de secuencias de comandos sobre comandos de shell seguros (ssh). Las secuencias de comandos crean el LUN y lo conectan automáticamente a nuestro cluster Hyper-V. Así pues, este proceso nos permite automatizar el provisionamiento de LUN. Después de documentar el proceso de forma completa, esperamos poder proporcionarlo a nuestro personal para que lo ejecuten personalmente. El proceso implica acceder al host, ejecutar los comandos y finalizar la conexión. ¡Así de sencillo!

Proyectos futuros

En función de nuestra experiencia, esperamos que a partir de ahora todo sea virtual. Si me preguntan sobre nuestra arquitectura de destino, imagino tanto nuestro cluster Hyper-V como el cluster SQL Server conectados a sistemas de almacenamiento NetApp. Todas nuestras aplicaciones de interfaz de usuario acabarán en última instancia en el cluster Hyper-V, que esperamos aumente hasta ocho nodos. Además, estamos en proceso de actualizar el firmware de NettApp en nuestro sistema de producción para poder ejecutar deduplicación de NetApp y reducir la cantidad de espacio de almacenamiento necesario al aumentar las máquinas virtuales.

Planes de virtualización
Tenemos pensado virtualizar nuestra instalación de SharePoint y pensamos que incluso el cluster SQL Server se podría virtualizar. Gracias a la mayor compatibilidad de Microsoft con Hyper-V, nuestros planes de virtualización podrían ampliarse para incluir nuestros principales servidores, servidores ISA cortafuegos y servidores Web IIS de interfaz de usuario. En los próximos seis a nueve meses, pretendemos virtualizar multitud de servidores independientes de una sola aplicación que ocupan gran cantidad de espacio de bastidor en el centro de datos. Se trata de aplicaciones utilizadas por entre 10 y 20 personas de diferentes departamentos, como el de Recursos Humanos o financiero. Los consideramos la base que nos permitirá obtener éxitos adicionales en nuestra transición hacia máquinas virtuales.

Además, muchas de nuestras prácticas de Hyper-V siguen evolucionando. Parte del calendario está relacionado con los últimos lanzamientos de Microsoft que integran estrechamente soluciones de Microsoft con Hyper-V, como por ejemplo Service Center Virtual Machine Manager (SCVMM) y Microsoft Data Protection Manager (DPM). En realidad, ya hemos comenzado a probar la característica P a V (físico a virtual) de SCVMM, que promete ser una solución rápida para convertir muchos de nuestros servidores físicos en máquinas virtuales. Asimismo, estamos barajando la forma óptima de incorporar nuevas tecnologías NetApp de protección de datos que aprovechan VSS para Microsoft Hyper-V para capturar copias Snapshot rápidas de una máquina virtual base. Esperamos poder utilizar este tipo de tecnología NetApp en la gestión y protección de datos, junto con Data Protection Manager.

Planes de protección de datos y recuperación ante desastres
También estamos desarrollando procesos para protección de datos por niveles.

  • Parte de los datos de Hyper-V serán objeto de backup por medio de Microsoft Data Protection Manager o determinadas combinaciones de DPM y tecnologías de protección de datos NetApp creadas sobre VSS.
  • En la actualidad, utilizamos DPM en nuestros entorno de producción, para lo que se necesita un agente en cada partición secundaria.
  • Se crearán backup de datos por medio de Snapshot de NetApp. (En la actualidad, Snapshot se emplea en nuestros entornos de desarrollo y pruebas.)
  • Parte de los datos clave se replicará con SnapMirror de NetApp entre nuestro centro de datos de Seattle y otra ubicación de recuperación ante desastres de una nuestras oficinas en la zona oriental de Estados Unidos.

Conclusión

Nuestra experiencia con Microsoft Hyper-V y NetApp ha sido excelente. Hemos obtenido un valioso espacio de disco (a través de la deduplicación de NetApp) y en la actualidad podemos autoprovisionar hasta cuatro servidores en menos de una hora. Esperamos que este proceso sea incluso más rápido con SCVMM. La disponibilidad de nuestras máquinas virtuales sigue siendo elevada. Además, hemos obtenido un gran rendimiento gracias a Hyper-V y NetApp.

© 2008 Avanade Inc. Todos los derechos reservados. El nombre y el logotipo de Avanade son marcas comerciales registradas en EE.UU. y otros países. Otros nombres de marcas y productos son marcas registradas de sus respectivos propietarios.

¿Qué opina de este caso práctico?

Formule sus preguntas, intercambie ideas y comparta sus opiniones en las comunidades online de NetApp.
Andy Schneider

Andy Schneider
Ingeniero jefe de sistemas
Avanade

Tras comenzar su carrera en Avanade como asesor de campo hace tres años y medio, Schneider ha dedicado los dos últimos años a materializar sus conocimientos en el equipo principal de infraestructura de TI de la empresa. Junto a su equipo, se encarga de determinar el uso óptimo de las nuevas tecnologías en el entorno de producción de Avanade.

 
En profundidad