Guía de consideraciones de diseño de tejido de virtualización

Artículo
10/16/2015

¿A quién está dirigida esta guía? Profesionales de tecnologías de la información (TI) de organizaciones medianas y grandes que sean los responsables de diseñar un tejido de virtualización que admita muchas máquinas virtuales. En el resto de este documento, se hace referencia a estas personas como administradores del tejido. Las personas que administran las máquinas virtuales hospedadas en el tejido se denominan “administradores de máquinas virtuales”, pero este documento no se dirige a ellos. Dentro de la organización, puede que su responsabilidad abarque los dos roles.

How can this guide help you? Puede usar esta guía para comprender cómo diseñar un tejido de virtualización capaz de hospedar numerosas máquinas virtuales de la organización. En este documento, la colección de servidores e hipervisores y el hardware de red y almacenamiento que se utilizan para hospedar las máquinas virtuales dentro de una organización se denominan tejido de virtualización. El gráfico siguiente muestra un tejido de virtualización de ejemplo.

Virtualization fabric

Figure 1:Tejido de virtualización de ejemplo

Nota: Cada diagrama de este documento se encuentra en una pestaña independiente del documento de diagramas de consideraciones de diseño de tejidos de virtualización, que puede descargar haciendo clic en el nombre de la ilustración, en el título de cada tabla.

Aunque todos los tejidos de virtualización contienen servidores para el almacenamiento y el hospedaje de máquinas virtuales, además de las redes que los conectan, es probable que el diseño del tejido de virtualización de cada organización sea diferente del ejemplo que se muestra en la ilustración 1, dado que las necesidades varían.

Esta guía detalla una serie de pasos y tareas que puede seguir para que le resulte más fácil diseñar un tejido de virtualización que se adapte a los requisitos únicos de su organización. A lo largo de los pasos y las tareas, la guía presenta las posibles características y tecnologías relevantes de las que dispone para cubrir sus necesidades funcionales y de calidad de servicios (por ejemplo, disponibilidad, escalabilidad, rendimiento, capacidad de administración y seguridad).

Aunque este documento puede ayudarle a diseñar un tejido de virtualización administrable, no describe las consideraciones de diseño ni las opciones de administración y funcionamiento del tejido de virtualización con un producto como Microsoft System Center 2012 o System Center 2012 R2. Para más información, consulte System Center 2012 en la biblioteca de TechNet.

Esta guía le ayuda a diseñar un tejido de virtualización con Windows Server 2012 R2 y Windows Server 2012 y hardware independiente de proveedores. Algunas características que se describen en el documento son exclusivas de Windows Server 2012 R2 y se mencionan en este documento.

Se asume que: Tiene cierta experiencia en la implementación de Hyper-V, máquinas virtuales, redes virtuales, servicios de archivos de Windows Server y clústeres de conmutación por error, y cierta experiencia en la implementación de servidores físicos, almacenamiento y equipos de red.

Recursos adicionales

Antes de diseñar un tejido de virtualización, puede resultarle útil la información de los siguientes documentos:

Los dos documentos proporcionan los conceptos fundamentales que se observan en diversos diseños de tejido de virtualización y pueden servir como base para cualquier diseño de tejido de virtualización.

Comentarios: Para enviar comentarios sobre este documento, escriba un correo electrónico a virtua@microsoft.com.

Información general sobre las consideraciones de diseño

El resto de este documento proporciona un conjunto de pasos y tareas que puede seguir para diseñar un tejido de virtualización que se adapte lo mejor posible a sus requisitos. Los pasos se presentan en una secuencia ordenada. Sin embargo, las consideraciones de diseño que aprenderá en los pasos posteriores pueden requerir que cambie las decisiones que tomó en los pasos anteriores, debido a conflictos. En cualquier caso, en todo el documento, tratamos de alertarle lo mejor posible sobre los conflictos de diseño que pueden aparecer.

Dará con el diseño que se adapte mejor a sus necesidades después de recorrer en iteración los pasos tantas veces como sea necesario para incorporar todas las consideraciones del documento.

Paso 1: determinar los requisitos de los recursos de máquinas virtuales

Paso 2: planear la configuración de máquinas virtuales

Paso 3: planear los grupos host de virtualización de servidores

Paso 4: planear los hosts de virtualización de servidores

Paso 5: planear los conceptos de arquitectura del tejido de virtualización

Paso 6: planear las características de capacidad inicial

Paso 1: determinar los requisitos de los recursos de máquinas virtuales

El primer paso para diseñar un tejido de virtualización es determinar los requisitos de los recursos de las máquinas virtuales que hospedará el tejido. El tejido debe incluir el hardware físico necesario para cubrir estos requisitos. Los sistemas operativos y las aplicaciones que se ejecutan en las máquinas virtuales dictan los requisitos de los recursos de las máquinas virtuales. En el resto de este documento, la combinación del sistema operativo y las aplicaciones que se ejecutan en una máquina virtual se denomina “carga de trabajo”. Las tareas de este paso le ayudan a definir los requisitos de los recursos de las cargas de trabajo.

Sugerencia: En lugar de evaluar los requisitos de los recursos de las cargas de trabajo existentes y, luego, diseñar un tejido de virtualización que admita cada uno de ellos, puede diseñar un tejido de virtualización capaz de cubrir las necesidades de las cargas de trabajo más comunes. Después, administre por separado las cargas de trabajo que tengan necesidades únicas.

Algunos ejemplos de este tipo de tejidos de virtualización son los que ofrecen los proveedores de nube pública, como Microsoft Azure (Azure). Para más información, consulte Tamaños de máquinas virtuales y servicios en la nube de Azure.

Los proveedores de nube pública suelen ofrecer una selección de configuraciones de máquinas virtuales que satisfacen las necesidades de la mayoría de las cargas de trabajo. Si decide adoptar este enfoque, puede avanzar directamente al Paso 2: planear la configuración de máquinas virtuales de este documento. Otras ventajas de este enfoque:

Si decide migrar algunas de las máquinas virtuales locales a un proveedor de nube pública, si sus tipos de configuración de máquinas virtuales locales son similares a las de su proveedor público, migrar las máquinas virtuales será más fácil que si los tipos de configuración son diferentes.
De este modo, puede prever más fácilmente los requisitos de capacidad y habilitar una capacidad de aprovisionamiento de autoservicio para el tejido de virtualización. Esto significa que los administradores de máquinas virtuales de la organización pueden aprovisionar automáticamente nuevas máquinas virtuales sin intervención de los administradores del tejido.

Tarea 1: determinar los requisitos de los recursos de las cargas de trabajo

Cada carga de trabajo tiene ciertos requisitos para los siguientes recursos. Lo primero que deberá hacer es responder a las siguientes preguntas para cada una de las cargas de trabajo.

Procesador: ¿qué velocidad o arquitectura (Intel o AMD) del procesador o qué número de procesadores son necesarios?
Red: en gigabits por segundo (Gbps), ¿qué ancho de banda de red es necesario para el tráfico entrante y saliente? ¿Cuál es la cantidad máxima de latencia de red que puede tolerar la carga de trabajo funcionando correctamente?
Almacenamiento: ¿cuántos gigabytes (GB) de almacenamiento requieren la aplicación y los archivos del sistema operativo de la carga de trabajo? ¿Cuántos GB de almacenamiento requiere la carga de trabajo para sus datos? ¿Cuántas operaciones de entrada/salida por segundo (IOPS) necesita la carga de trabajo para su almacenamiento?
Memoria: en gigabytes (GB), ¿cuánta memoria requiere la carga de trabajo? ¿La carga de trabajo está habilitada para el acceso a memoria no uniforme (NUMA)?

Además de comprender los requisitos de los recursos anteriores, es importante determinar:

Si los requisitos de los recursos son los mínimos o los recomendados.
Cuáles son los requisitos de hardware máximos y medios en los períodos de una hora, un día, una semana, un mes y un año.
El número de minutos de tiempo de inactividad al mes que son aceptables para la carga de trabajo y los datos de la carga de trabajo. Para determinar esto, tenga en cuenta lo siguiente:
- ¿La carga de trabajo se ejecuta solamente en una máquina virtual, o se ejecuta en una colección de máquinas virtuales que actúan como una sola como, por ejemplo, una colección de servidores de carga de red equilibrada en la que todos los servidores ejecutan la misma carga de trabajo? Si utiliza una colección de servidores, el tiempo de inactividad expresado debe especificar claramente si se aplica a cada servidor de la colección, a todos los servidores de la colección o al nivel de la colección.
- Horario laboral y no laboral. Por ejemplo, si nadie va a utilizar la carga de trabajo entre las 9:00 y las 6:00, pero es fundamental que esté disponible la máxima cantidad de tiempo posible entre las 6:00 y las 9:00, con una cantidad aceptable de inactividad mensual de solo diez minutos, debe especificarse este requisito.
La cantidad de pérdida de datos que es aceptable si se produce un error inesperado de la infraestructura virtual. Se expresa en minutos, ya que las estrategias de replicación de la infraestructura virtual suelen basarse en tiempos. Aunque muchas veces no se exprese la pérdida de datos como un requisito, tenga en cuenta que supone un gran coste, y que puede venir acompañada de un rendimiento menor.
Si los archivos de la carga de trabajo y sus datos se deben cifrar en el disco y si sus datos se deben cifrar entre las máquinas virtuales y sus usuarios finales.

Dispone de las siguientes opciones para determinar los requisitos de los recursos anteriores.

Option	Ventajas	Desventajas
Evaluar y registrar el uso de recursos manualmente	Puede informar sobre todo lo que desee.	Puede requerir un esfuerzo manual considerable.
Utilice Microsoft Assessment and Planning Toolkit para evaluar y registrar el uso de recursos automáticamente.	Crea diversos informes del uso de recursos. No requiere que haya un agente instalado en la carga de trabajo.	Puede que los informes no le proporcionen todos los datos que necesita.

Nota: Si decide determinar los requisitos de los recursos manualmente, puede descargar las hojas de cálculo de la guía de consideraciones de diseño de tejidos de virtualización e introducir la información en la hoja de cálculo de requisitos de los recursos de la carga de trabajo. Esta guía hace referencia a hojas de cálculo concretas de ese documento.

Tarea 2: definir las caracterizaciones de cargas de trabajo

En su entorno, puede definir tantas caracterizaciones de cargas de trabajo como quiera. Los ejemplos siguientes se eligieron porque cada uno de ellos requiere una configuración diferente de los componentes del tejido de virtualización, que se describirá más adelante, en los pasos posteriores.

Sin estado: no escriben ninguna información exclusiva en su disco duro local una vez que están aprovisionadas inicialmente y se les asignan direcciones de red y nombres de equipo únicos. Sin embargo, pueden escribir información exclusiva en un almacenamiento independiente como, por ejemplo, una base de datos. Las cargas de trabajo sin estado son perfectas para ejecutarse en un tejido de virtualización, porque se puede crear una imagen “maestra” para la máquina virtual. La imagen se puede copiar fácilmente y arrancar en el tejido de virtualización para ampliar la escala de la carga de trabajo o reemplazar rápidamente una máquina virtual que deje de estar disponible si se produce un error del host de virtualización. Un ejemplo de una carga de trabajo sin estado es un servidor web que ejecute una aplicación web front-end.
Con estado: escriben información exclusiva en su disco duro local una vez que están aprovisionadas inicialmente y tienen asignados direcciones de red y nombres de equipo únicos. También pueden escribir información exclusiva en un almacenamiento independiente como, por ejemplo, una base de datos. Las cargas de trabajo con estado suelen requerir estrategias de aprovisionamiento y escalado más complejas que las cargas de trabajo sin estado. Las estrategias de alta disponibilidad para cargas de trabajo con estado pueden requerir el estado compartido con otras máquinas virtuales. Un ejemplo de una carga de trabajo con estado es el motor de base de datos de SQL Server.
Con estado compartidas: cargas de trabajo con estado que requieren algún estado compartido con otras máquinas virtuales. Estas cargas de trabajo suelen utilizar clústeres de conmutación por error en Windows Server para lograr una alta disponibilidad, lo que requiere acceso al almacenamiento compartido. Un ejemplo de carga de trabajo con estado compartida es Microsoft System Center Virtual Machine Manager.
Otras: caracteriza las cargas de trabajo que puede que no se ejecuten nunca, o que no se ejecuten de forma óptima, en un tejido de virtualización. Los atributos de esas cargas de trabajo consisten en que requieren:
- Acceso a periféricos físicos. Un ejemplo de este tipo de aplicación es una carga de trabajo de telefonía que se comunica con un adaptador de red de telefonía en un host físico.
- Requisitos de recursos mucho mayores que la mayoría de las otras cargas de trabajo. Un ejemplo es una aplicación en tiempo real que requiere una latencia de menos de un milisegundo entre las capas de la aplicación.
Estas aplicaciones pueden no ejecutarse en el tejido de virtualización, o pueden requerir un hardware o una configuración muy específicos que no comparta la mayoría de las otras cargas de trabajo.

Nota: Puede definir las caracterizaciones de las cargas de trabajo en la hoja de cálculo Configuración y, luego, elegir la caracterización adecuada para cada carga de trabajo en la hoja de cálculo Requisitos de los recursos de las cargas de trabajo.

Paso 2: planear la configuración de máquinas virtuales

En este paso, definirá los tipos de máquinas virtuales que necesitará para cubrir los requisitos de los recursos y las caracterizaciones de las cargas de trabajo que definió en el paso 1.

Tarea 1: definir la configuración de proceso

En esta tarea, determinará la cantidad de memoria y procesadores que requiere cada máquina virtual.

Tarea 1a: definir el tipo de generación de máquina virtual

Windows Server 2012 R2 introdujo las máquinas virtuales de generación 2. Las máquinas virtuales de generación 2 admiten las características de virtualización y hardware que no admiten las máquinas virtuales de generación 1. Es importante tomar la decisión adecuada para sus requisitos, porque una vez creada una máquina virtual, no se puede cambiar de tipo.

Una máquina virtual de generación 2 proporciona las siguientes funcionalidades nuevas:

Arranque PXE con un adaptador de red estándar
Arranque desde un disco duro virtual SCSI
Arranque desde un DVD virtual SCSI
Arranque seguro (habilitado de forma predeterminada)
Compatibilidad con firmware UEFI

Las máquinas virtuales de generación 2 admiten los siguientes sistemas operativos invitados:

Windows Server 2012 R2
Windows Server 2012
Versiones de 64 bits de Windows 8.1
Versiones de 64 bits de Windows 8
Versiones específicas de Linux Para ver una lista de las distribuciones y las versiones que admiten las máquinas virtuales de generación 2, consulte el tema sobre máquinas virtuales de Linux en Hyper-V.

En la tabla siguiente, se indican las ventajas y las desventajas de las máquinas virtuales de generación 1 y generación 2.

Option	Ventajas	Desventajas
Generación 1	Admite todos los sistemas operativos invitados Hyper-V compatibles. Proporciona compatibilidad con máquinas virtuales de Azure. Admite las versiones anteriores de Hyper-V.	No puede acceder a la nueva funcionalidad de las máquinas virtuales.
Generación 2	Admite la funcionalidad nueva. Mejora un poco los tiempos de instalación de invitados y arranque de máquinas virtuales. Usa dispositivos SCSI o un adaptador de red estándar para arrancar las máquinas virtuales. Impide que se ejecuten firmware, sistemas operativos o controladores UEFI no autorizados cuando el arranque seguro está habilitado.	Compatibilidad limitada con sistemas operativos invitados. No es compatible con las máquinas virtuales de Azure. No es compatible con RemoteFX. No admite los disquetes virtuales.

Importante: Las máquinas virtuales de Linux de generación 2 no admiten el arranque seguro. Si crea una máquina virtual y tiene pensado instalar Linux, debe desactivar el arranque seguro en la configuración de la máquina virtual.

Información adicional:

Información general acerca de las máquinas virtuales de generación 2

Tarea 1b: definir la memoria

Debe planear el tamaño de la memoria de la máquina virtual como lo haría normalmente con las aplicaciones de servidor en un equipo físico. Debe controlar, en una medida razonable, la carga esperada habitualmente y la que se espera en las horas pico. Si la memoria es insuficiente, pueden aumentar considerablemente los tiempos de respuesta y el uso de CPU o E/S.

Memoria estática o memoria dinámica

La memoria estática es la cantidad de memoria asignada a la máquina virtual. Cuando se inicia la máquina virtual, se mantiene asignada en todo momento y no cambia mientras se está ejecutando la máquina virtual. Toda la memoria se asigna a la máquina virtual durante el inicio y la memoria que no está utilizando la máquina virtual no está disponible para las demás máquinas virtuales. Si no hay suficiente memoria disponible en el host que se va a asignar a la máquina virtual cuando se inicia, la máquina virtual no se iniciará.

La memoria estática es adecuada para las cargas de trabajo con un uso intensivo de memoria y las cargas de trabajo que tienen sus propios sistemas de administración de memoria, como SQL Server. Estos tipos de cargas de trabajo funcionan mejor con la memoria estática.

Nota: No hay ninguna configuración que permita habilitar la memoria estática. La memoria estática se habilita cuando la configuración de memoria dinámica no está habilitada.

La memoria dinámica le permite usar mejor la memoria física de un sistema, al equilibrar la memoria física total de varias máquinas virtuales: asigna más memoria a las máquinas virtuales que están ocupadas y quita memoria a las máquinas virtuales que se utilizan menos. Esto puede producir mayores índices de consolidación, especialmente en entornos dinámicos, como en servidores web o de Infraestructura de escritorio virtual (VDI).

Al utilizar la memoria estática, si a una máquina virtual se le asignan 10 GB de memoria y solo usa 3 GB, los otros 7 GB de memoria no estarán disponibles para usarse en otras máquinas virtuales. Cuando una máquina virtual tiene la memoria dinámica habilitada, la máquina virtual solo usará la cantidad de memoria que sea necesaria, pero esta no será inferior a la RAM mínima configurada. Así, se libera más memoria para las demás máquinas virtuales.

En la tabla siguiente, se indican las ventajas y las desventajas de la memoria estática y la memoria dinámica.

Option	Ventajas	Desventajas
Memoria estática	Proporciona a las máquinas virtuales la memoria configurada, que está disponible en todo momento. Proporciona un rendimiento superior. Se puede utilizar con NUMA virtual.	No se puede asignar la memoria no utilizada por una máquina virtual a otra máquina virtual. Las máquinas virtuales no se inician si no hay suficiente memoria disponible.
Memoria dinámica	Proporciona una densidad de máquinas virtuales mejorada cuando se ejecutan cargas de trabajo inactivas o de poca carga. Permite asignar la memoria que no se utiliza para que se pueda usar en otras máquinas virtuales.	Puede saturar la memoria configurada. Es necesaria una sobrecarga adicional para administrar las asignaciones de memoria. No es compatible con NUMA virtual. No es compatible con las cargas de trabajo que implementan sus propios administradores de memoria.

Estos son los valores de configuración de memoria:

RAM de inicio: especifica la cantidad de memoria necesaria para iniciar la máquina virtual. El valor debe ser lo suficientemente alto como para permitir el inicio del sistema operativo invitado, pero debe ser lo más bajo posible para permitir un uso óptimo de la memoria e índices de consolidación potencialmente más altos.
RAM mínima: especifica la cantidad mínima de memoria que se debe asignar a la máquina virtual una vez iniciada la máquina virtual. El valor mínimo que se puede establecer es 32 MB, y el valor máximo es el equivalente al valor de la RAM de inicio. Esta opción solo está disponible cuando está habilitada la memoria dinámica.
RAM máxima: especifica la cantidad máxima de memoria que se puede usar esta máquina virtual. El valor mínimo es el valor de la RAM de inicio, y el máximo es 1 TB. Sin embargo, una máquina virtual no puede usar más memoria que la cantidad máxima de memoria que admite el sistema operativo invitado. Por ejemplo, si especificó 64 GB para una máquina virtual que ejecuta un sistema operativo que admite 32 GB como máximo, la máquina virtual no podrá utilizar más de 32 GB. Esta opción solo está disponible cuando está habilitada la memoria dinámica.
Peso de memoria: permite a Hyper-V determinar cómo distribuir la memoria entre las máquinas virtuales si no hay suficiente memoria física disponible en el host para proporcionar la cantidad de memoria solicitada a cada máquina virtual. Las máquinas virtuales con un peso de memoria mayor tienen precedencia sobre las máquinas virtuales con ponderaciones menores.

Notas:

La memoria dinámica y las características de NUMA virtual no se pueden usar al mismo tiempo. Una máquina virtual que tenga habilitada la memoria dinámica, en la práctica, tendrá solo un nodo NUMA virtual y no se presentará ninguna topología NUMA a la máquina virtual, sea cual sea la configuración de NUMA virtual.
Al instalar o actualizar el sistema operativo de una máquina virtual, la cantidad de memoria que está disponible para la máquina virtual durante el proceso de instalación y actualización es el valor especificado como RAM de inicio. Aunque se configure la memoria dinámica en la máquina virtual, esta solo usará la cantidad de memoria que esté establecida en la configuración de la RAM de inicio. Asegúrese de que el valor de la RAM de inicio cumple los requisitos mínimos de memoria del sistema operativo durante los procedimientos de instalación y actualización.
El sistema operativo invitado que se ejecute en la máquina virtual deberá admitir la memoria dinámica.
Las aplicaciones de base de datos complejas, como SQL Server o Exchange Server, implementan sus propios administradores de memoria. Consulte la documentación de la carga de trabajo para averiguar si la carga de trabajo es compatible con la memoria dinámica.

Información adicional:

Información general sobre la memoria dinámica

Tarea 1c: definir el procesador

Para configurar las máquinas virtuales, se debe determinar la configuración siguiente:

Determine el número de procesadores necesarios para cada máquina virtual. Suele ser equivalente al número de procesadores que necesita la carga de trabajo. Hyper-V admite un máximo de 64 procesadores virtuales por cada máquina virtual.
Determine el control de recursos de cada máquina virtual. Se pueden establecer límites para que ninguna máquina virtual pueda monopolizar los recursos del procesador del host de virtualización.
Defina una topología NUMA. Para las cargas de trabajo habilitadas para NUMA de alto rendimiento, puede especificar el número máximo de procesadores, la cantidad de memoria permitida en un solo nodo NUMA virtual y el número máximo de nodos permitido en un solo socket de procesador. Para más información, consulte Introducción a NUMA virtual de Hyper-V.

Nota: No se pueden usar NUMA virtual y la memoria dinámica al mismo tiempo. Al tratar de decidir si va a utilizar memoria dinámica o NUMA, responda a las preguntas siguientes. Si la respuesta a ambas es Sí, habilite NUMA virtual y no habilite la memoria dinámica.

¿La carga de trabajo que se ejecuta en la máquina virtual está habilitada para NUMA?
¿La máquina virtual consumirá más recursos, procesadores o memoria de los que están disponibles en un solo nodo NUMA físico?

Tarea 1d: definir los sistemas operativos compatibles

Debe confirmar que el sistema operativo que requiere la carga de trabajo se admite como sistema operativo invitado. Tenga en cuenta lo siguiente:

Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 R2 and Windows 8.1
Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 and Windows 8
Para Linux: si quiere ver información sobre las distribuciones de Linux admitidas, consulte el tema sobre máquinas virtuales de Linux en Hyper-V.

Nota: Hyper-V incluye un paquete de software para los sistemas operativos invitados admitidos, que mejora el rendimiento y la integración entre el equipo físico y la máquina virtual. Esta colección de servicios y controladores de software se denomina “servicios de integración”. Para obtener el mejor rendimiento, las máquinas virtuales deben ejecutar los servicios de integración más recientes.

Concesión de licencias

Deberá asegurarse de que los sistemas operativos invitados tengan la licencia correcta. Revise la documentación del proveedor para ver los requisitos específicos de las licencias al ejecutar un entorno virtualizado.

La activación automática de máquina virtual (AVMA) es una característica que se introdujo en Windows Server 2012 R2. AVMA enlaza la activación de la máquina virtual con el servidor de virtualización con licencia y activa la máquina virtual cuando se inicia. De este modo, no es necesario especificar la información de las licencias y activar cada máquina virtual individualmente.

AVMA requiere que el host ejecute Windows Server 2012 R2 Datacenter y que el sistema operativo de la máquina virtual invitada sea Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard o Windows Server 2012 R2 Essentials.

Nota: Deberá configurar AVMA en cada host implementado en el tejido de virtualización.

Información adicional:

Activación automática de máquina virtual

Tarea 1e: definir la convención de nomenclatura de las máquinas virtuales

La estrategia de nomenclatura del equipo existente puede indicar dónde está ubicado físicamente el equipo o el servidor. Las máquinas virtuales pueden moverse de un host a otro, incluso a diferentes centros de datos, por lo que es posible que la estrategia de nomenclatura existente deje de ser útil. Actualizar la convención de nomenclatura existente para indicar que el equipo se está ejecutando como máquina virtual puede ayudar a encontrar el lugar donde se está ejecutando la máquina virtual.

Tarea 2: definir la configuración de red

Cada máquina virtual recibirá o enviará distintos tipos de tráfico de red. Cada tipo de tráfico de red tendrá requisitos de seguridad, disponibilidad y rendimiento diferentes.

Las máquinas virtuales de generación 1 pueden tener un máximo de 12 adaptadores de red: 4 adaptadores de red heredados y 8 adaptadores de red virtuales. Las máquinas virtuales de generación 2 no admiten los adaptadores de red heredados, por lo que el número máximo de adaptadores que se admite es 8.

Tarea 2a: determinar los tipos de tráfico de red

Cada máquina virtual enviará y recibirá distintos tipos de datos, por ejemplo:

Datos de aplicaciones
Copia de seguridad de datos
Comunicaciones con equipos cliente, servidores o servicios
Comunicación dentro del clúster, si la carga de trabajo forma parte de un clúster de conmutación por error de máquinas virtuales invitadas
Soporte
Almacenamiento

Si ya hay redes existentes dedicadas a diferentes tipos de tráfico de red, puede utilizarlas para esta tarea. Si va a definir nuevos diseños de red para admitir el tejido de virtualización, puede definir qué tipos de tráfico de red admitirá cada máquina virtual.

Tarea 2b: definir las opciones de rendimiento del tráfico de red

Cada tipo de tráfico de red tiene unos requisitos de ancho de banda máximo y latencia mínima. La siguiente tabla muestra las estrategias que pueden utilizarse para cumplir los diferentes requisitos del rendimiento de la red.

Estrategia	Ventajas	Desventajas
Separación de tipos de tráfico a distintos adaptadores de red físicos	Separa el tráfico de modo que no se comparta con otros tipos de tráfico.	Debe haber adaptadores de red físicos independientes instalados en el host para cada tipo de tráfico de red. Es necesario hardware adicional para cada red que requiera alta disponibilidad de la red. No se escala bien con un gran número de redes.
Administración del ancho de banda de Hyper-V (Calidad de servicio (QoS) de Hyper-V)	Proporciona QoS para el tráfico de red virtual Exija un ancho de banda mínimo y máximo para un flujo de tráfico, identificado con un número de puerto de conmutador virtual de Hyper-V. Configure el ancho de banda mínimo y máximo de cada puerto de conmutador virtual de Hyper-V con cmdlets de PowerShell o Instrumental de administración de Windows (WMI). Configure varios adaptadores de red virtuales en Hyper-V y especifique la QoS en cada adaptador de red virtual individualmente. Proporciona un complemento a la directiva de QoS de la red física.	La QoS de software y la QoS de hardware no deben utilizarse al mismo tiempo en el mismo adaptador de red. Tendrá que planear correctamente la directiva de QoS de la red y Hyper-V para que no se invaliden entre sí. Una vez establecido el modo de Calidad de servicio de un conmutador virtual, no se puede cambiar. No se pueden migrar máquinas virtuales a un host con un conmutador virtual configurado para utilizar otro modo de QoS. Cuando no se puedan respetar los valores absolutos configurados para una máquina virtual, se bloqueará la migración.
SR-IOV	Proporciona la menor latencia de red a una máquina virtual. Proporciona la E/S de red máxima a una máquina virtual. Reduce la sobrecarga de CPU necesaria para las redes virtuales.	Necesita un adaptador de red compatible con SR-IOV y un controlador en el host y en cada máquina virtual que tenga una función virtual asignada. Los adaptadores de red virtuales habilitados para SR-IOV no pueden formar parte del equipo NIC en el host. Para obtener una alta disponibilidad de red, tiene que haber dos o más adaptadores de red SR-IOV instalados en el host, y la Formación de equipos NIC debe estar configurada en la máquina virtual. SR-IOV solo debe utilizarse con cargas de trabajo de confianza, porque el tráfico pasa por alto el conmutador de Hyper-V y tiene acceso directo al adaptador de red físico. Si se configuran ACL, QoS de Hyper-V, RouterGuard y DHCPGuard en los puertos de los conmutadores virtuales, se impedirá el uso de SR-IOV. SR-IOV no se admite en las máquinas virtuales que se ejecutan en Azure.
Ajuste de escala en lado de recepción virtual	Admite el escalado del lado de recepción virtual, que permite a las máquinas virtuales distribuir la carga de procesamiento de red entre varios procesadores virtuales (vCPU) para aumentar el rendimiento de red en las máquinas virtuales. Proporciona compatibilidad con: Formación de equipos NIC Live migration NVGRE	El escalado del lado de recepción virtual requiere que el adaptador de red físico admita Virtual Machine Queue (VMQ), y debe estar habilitado en el host. No es compatible con los adaptadores de red virtuales habilitados para SR-IOV. Las máquinas virtuales deben ejecutar Windows Server 2012 R2 o Windows 8.1. Está deshabilitado de forma predeterminada si el adaptador VMQ es menor de 10 Gbps.
Tramas gigantes	Permite transferir más datos con cada transacción de Ethernet y, así, reducir el número de tramas que es necesario transmitir. Se suele usar para la comunicación con el almacenamiento, pero puede usarse con todos los tipos de comunicación. Reduce la sobrecarga de las máquinas virtuales, el equipo de red y el servidor final al que se envían los datos. Se configura para la comunicación interna de un centro de datos, donde puede controlar la configuración de la Unidad de transmisión máxima (MTU) en todos los saltos.	Proporciona una probabilidad de detección de errores ligeramente inferior. Todos los dispositivos de red de la ruta de acceso deben admitir las tramas gigantes y estar configurados con un valor de MTU igual o superior. Utilice el comando Ping para comprobar la configuración de MTU de un extremo a otro. Si algún salto del camino no admite las tramas gigantes o está configurado con una MTU menor, se descartarán los paquetes.

Tarea 2c: definir las opciones de disponibilidad del tráfico de red

La Formación de equipos NIC, también llamada “Equilibrio de carga y conmutación por error” (LBFO), permite colocar varios adaptadores de red en un equipo para realizar la conmutación por error del tráfico y la agregación de ancho de banda. Así, se mantiene la conectividad si se produce un error en un componente de la red. La Formación de equipos NIC se suele configurar en el host y, cuando se crea el conmutador virtual, se enlaza a un equipo de adaptadores de red.

Los conmutadores de red que se implementan determinan el modo de Formación de equipos NIC. La configuración predeterminada de Windows Server 2012 R2 es suficiente para la mayoría de las implementaciones.

Nota: SR-IOV no es compatible con la Formación de equipos NIC. Para más información sobre SR-IOV, consulte el Tarea 2b: definir las opciones de rendimiento del tráfico de red.

Información adicional:

Introducción a la formación de equipos NIC

Tarea 2d: definir las opciones de seguridad del tráfico de red

Cada tipo de tráfico de red puede tener distintos requisitos de seguridad: por ejemplo, los requisitos relacionados con el aislamiento y el cifrado. La siguiente tabla explica las estrategias que pueden utilizarse para cumplir los diversos requisitos de seguridad.

Estrategia	Ventajas	Desventajas
Separación en diferentes adaptadores de red.	Tráfico independiente del tráfico de otras redes.	No se escala bien. Cuantas más redes tenga, más adaptadores de red tendrá que instalar y administrar en el host.
Descarga de tareas de IPsec con IPsec	Admite la descarga de IPsec para el cifrado de tráfico de red hacia las máquinas virtuales con Hyper-V y desde ellas. Cifra el tráfico mientras recorre la red.	La instalación es compleja. Puede dificultar la solución de problemas, porque no se puede abrir el tráfico hacia los hosts y las máquinas virtuales y desde ellos. Aumenta el uso del procesador cuando los adaptadores de red físicos del host no admiten la descarga de IPsec.
Etiquetado de VLAN	La mayoría de las compañías ya lo usa. Es compatible con las directivas de QoS. Admite las VLAN privadas. Admite el modo de tronco de VLAN con las máquinas virtuales. Reduce el número de adaptadores físicos que deben instalarse en el host.	Limitado a 4094 redes VLAN. Requiere la configuración de conmutadores, hosts y máquinas virtuales. Realizar cambios incorrectos en la configuración de VLAN puede provocar problemas de red que afecten al servidor o a todo el sistema.
Virtualización de red de Hyper-V	Proporciona la selección de ubicación flexible de las cargas de trabajo, incluidos el aislamiento de red y la reutilización de direcciones IP sin VLAN. Permite mover las cargas de trabajo en la nube con más facilidad. Admite la migración en vivo entre subredes sin necesidad de insertar una nueva dirección IP en el nuevo servidor. Permite usar soluciones de redes multiempresa. Proporciona un diseño de red simplificado y mejora el uso de los servidores y los recursos de la red. La rigidez de las VLAN y la dependencia de la selección de ubicación de las máquinas virtuales en las infraestructuras de red físicas suelen provocar la infrautilización o el exceso de aprovisionamiento.	Para administrar la Virtualización de red de Hyper-V, es necesario System Center 2012 R2 Virtual Machine Manager o una solución de administración de un proveedor distinto de Microsoft. Es necesaria una puerta de enlace de Virtualización de red de Hyper-V para permitir la comunicación con el exterior de la red virtual.
DHCPGuard	Bloquea la máquina virtual para que no realice ofertas de DHCP a través de la red virtual. Se configura en cada adaptador de red virtual. No hace que la máquina virtual deje de recibir una dirección de un servidor DHCP.	Apenas afecta al rendimiento cuando está habilitado.
RouterGuard	Bloquea los paquetes siguientes: ICMPv4, tipo 5 (mensaje de redirección) ICMPv4, tipo 9 (anuncio de enrutador) ICMPv6, tipo 134 (anuncio de enrutador) ICMPv6, tipo 137 (mensaje de redirección) Se configura en cada adaptador de red virtual.	Apenas afecta al rendimiento cuando está habilitado.

Decisión de diseño: puede descargar las hojas de cálculo de la guía de consideraciones de diseño de tejidos de virtualización y cambiar los datos de ejemplo de la hoja de cálculo de configuración de máquinas virtuales para capturar las decisiones que tome en todas las tareas anteriores de este paso. Para tomar las siguientes decisiones de diseño, este documento hace referencia a las hojas de cálculo concretas de esta guía donde puede escribir los datos.

Tarea 2e: definir los adaptadores de red virtuales

Una vez que comprenda los tipos de tráfico que necesitan las máquinas virtuales, además de las estrategias de rendimiento, disponibilidad y seguridad del tráfico, puede determinar cuántos adaptadores de red virtuales necesitará cada máquina virtual.

Cada adaptador de red virtual se conecta a un conmutador virtual. Hay tres tipos de conmutadores virtuales:

Conmutador virtual externo
Conmutador virtual interno
Conmutador virtual privado

El conmutador virtual externo permite a la máquina virtual acceder a la red física a través del adaptador de red asociado al conmutador virtual al que se conecta. Cada adaptador de red físico del host solo puede asociarse con un conmutador externo.

Las máquinas virtuales de generación 1 pueden tener un máximo de 12 adaptadores de red: 4 adaptadores de red heredados y 8 adaptadores de red virtuales. Las máquinas virtuales de generación 2 no admiten los adaptadores de red heredados, por lo que la cantidad máxima de adaptadores admitidos es 8. Cada adaptador de red virtual puede tener asignado un identificador de VLAN, salvo que esté configurado en el modo de tronco.

Si va a asignar tráfico de máquinas virtuales a diferentes VLAN, un adaptador de red que admita VLAN debe instalarse en el host y asignarse al conmutador virtual. Puede establecer el identificador de VLAN de la máquina virtual en las propiedades de la máquina virtual. El identificador de VLAN establecido en el conmutador virtual es el identificador de VLAN que se asignará al adaptador de red virtual asignado al sistema operativo host.

Nota: Si tiene una máquina virtual que necesita acceder a una cantidad de redes mayor que el número de adaptadores disponibles, puede habilitar el modo de tronco de VLAN en un adaptador de red de máquina virtual con el cmdlet de Windows PowerShell Set-VMNetworkAdapterVlan.

Tarea 2f: definir la estrategia de direccionamiento IP

Deberá determinar cómo asignará direcciones IP a las máquinas virtuales. Si no lo hace, puede tener conflictos de direcciones IP, que pueden perjudicar a otras máquinas virtuales y otros dispositivos físicos de la red.

Además, los servidores DHCP no autorizados pueden causar confusión en la infraestructura de red, y pueden ser especialmente difíciles de seguir cuando el servidor se ejecuta como máquina virtual. Puede proteger la red para que los servidores DHCP no autorizados no se ejecuten en una máquina virtual habilitando DHCPGuard en la configuración de las máquinas virtuales. DHCPGuard ofrece protección para evitar que las máquinas virtuales malintencionadas se representen a sí mismas como servidores DHCP para los ataques de tipo “Man in the middle”.

Información adicional:

Introducción al Protocolo de configuración dinámica de host (DHCP)

DHCPGuard

Información general de la administración de direcciones IP (IPAM)

Tarea 3: definir la configuración de almacenamiento

Para determinar la configuración de almacenamiento, tendrá que definir los tipos de datos que almacenarán las máquinas virtuales y el tipo de almacenamiento que necesitan.

Tarea 3a: definir los tipos de datos

En la tabla siguiente, se indican los tipos de datos que puede tener que almacenar una máquina virtual y dónde se suele almacenar ese tipo de datos.

Tipo de datos	Ubicación de almacenamiento del tipo de datos
Archivos del sistema operativo	Dentro de un archivo de disco duro virtual que se almacena en el host de virtualización. Las consideraciones sobre el almacenamiento del host de virtualización se describen más detalladamente en el paso 4: planear los hosts de virtualización de servidores, más adelante.
Archivo de paginación de Windows	Se suele almacenar en la misma ubicación que los archivos del sistema operativo.
Archivos de aplicaciones	Se suelen almacenar en la misma ubicación que los archivos del sistema operativo.
Datos de configuración de aplicaciones	Se suelen almacenar en la misma ubicación que los archivos del sistema operativo.
Datos de aplicaciones	Se suelen almacenar en una ubicación independiente de la de los archivos de aplicaciones y del sistema operativo. Por ejemplo, si la aplicación es una aplicación de base de datos, los archivos de base de datos se suelen almacenar en una solución de almacenamiento de alta disponibilidad, eficiente y basada en red que sea independiente de la ubicación donde se almacenan los archivos de las aplicaciones y los del sistema operativo.
Volúmenes compartidos de clúster (CSV) y testigos de disco (necesarios para la agrupación en clústeres de las máquinas virtuales invitadas)	Se suelen almacenar en una ubicación independiente de la de los archivos de aplicaciones y del sistema operativo. El almacenamiento CSV es donde las aplicaciones en clúster almacenan los datos, de modo que estén disponibles para todos los nodos del clúster. Un testigo de disco es un disco del almacenamiento de clúster designado para mantener una copia de la base de datos de configuración de clúster. Un clúster de conmutación por error solamente tiene un testigo de disco si se especifica como parte de la configuración de cuórum.
Archivos de volcado de memoria	Se suelen almacenar en la misma ubicación que los archivos del sistema operativo.

Tarea 3b: definir los tipos de almacenamiento

En la tabla siguiente, se muestran los tipos de almacenamiento que se pueden usar para los tipos de datos definidos en el paso 2, tarea 2a, más arriba.

Tipo de almacenamiento	Consideraciones
Disco virtual de IDE	Máquinas virtuales de generación 1: 2 controladoras IDE, cada una de las cuales puede admitir un máximo de 2 dispositivos IDE, por lo que el máximo es 4 dispositivos IDE. El disco de inicio, también llamado “disco de arranque”, debe asociarse a uno de los dispositivos IDE como disco duro virtual o disco físico. Las máquinas virtuales de generación 2 no admiten los dispositivos IDE.
SCSI virtuales	4 controladoras SCSI virtuales, cada una de las cuales admite hasta 64 dispositivos, por lo que el máximo total es 256 dispositivos SCSI. Dado que las máquinas virtuales de generación 2 solo admiten una unidad SCSI, las máquinas virtuales de generación 2 admiten los discos de arranque de SCSI.
Iniciador iSCSI de la máquina virtual	Aproveche el almacenamiento de las SAN sin necesidad de instalar adaptadores de Canal de fibra en el host. No se puede usar para el disco de arranque. Use directivas de QoS de la red para que el ancho de banda adecuado esté disponible para el almacenamiento y otros tipos de tráfico de red. No es compatible con la Réplica de Hyper-V. Al usar un back-end de almacenamiento SAN, utilice las opciones de replicación de SAN que le proporcione el proveedor de almacenamiento.
Canal de fibra virtual	Requiere uno o más adaptadores de red convergentes de adaptadores de bus host (HBA) de Canal de fibra o Canal de fibra sobre Ethernet (FCoE) en cada host que vaya a hospedar las máquinas virtuales con adaptadores de Canal de fibra virtual. Los controladores de HBA y FCoE deben admitir el Canal de fibra virtual. Una SAN habilitada para NPIV. Requiere configuración adicional para admitir la migración en vivo. Para más información sobre la migración en vivo y el Canal de fibra virtual, consulte Información general del canal de fibra virtual de Hyper-V. No es compatible con la Réplica de Hyper-V. Si usa almacenamiento SAN, debe utilizar las opciones de replicación de SAN que proporciona el proveedor de almacenamiento. Una máquina virtual puede tener hasta cuatro puertos virtuales. Los LUN de Canal de fibra virtual no pueden utilizarse como medios de arranque de la máquina virtual.
SMB 3.0	Acceda a los archivos almacenados en los recursos compartidos del Bloque de mensajes del servidor (SMB) 3.0 desde dentro de la máquina virtual.

Tarea 3c: definir el tipo y el formato de disco duro virtual

Si va a utilizar el tipo de almacenamiento de disco duro virtual (VHD), primero debe seleccionar el formato de VHD que usará de entre las opciones que se indican en la tabla siguiente.

Formato de disco	Ventajas	Desventajas
VHD	Compatible con todas las versiones de Hyper-V Compatible con las implementaciones locales y de Azure	Capacidad de almacenamiento máxima de 2.040 GB Disco duro virtual máximo compatible con Azure de 1 TB Incompatible con las máquinas virtuales de generación 2
VHDX	Capacidad de almacenamiento máxima de 64 terabytes (TB) Protección contra daños en datos durante los errores de alimentación Alineación mejorada del formato de disco duro virtual para que funcione bien en los discos de sector grande Un disco virtual de sector lógico de 4 KB que permite aumentar el rendimiento cuando lo utilizan las aplicaciones y las cargas de trabajo diseñadas para los sectores de 4 KB Puede utilizarse como almacenamiento compartido para las máquinas virtuales que requieran clústeres de conmutación por error.	Actualmente, no es compatible con las máquinas virtuales de Azure. No se puede utilizar con las versiones de Hyper-V anteriores a Windows Server 2012.
Uso compartido de discos duros virtuales	Se usa para el almacenamiento compartido de clústeres de máquinas virtuales invitadas.	Requiere tener Windows Server 2012 R2 en el host que ejecuta Hyper-V. Entre los sistemas operativos invitados compatibles para los clústeres invitados que usan un disco duro virtual compartido, se incluyen Windows Server 2012 R2 y Windows Server 2012. Para admitir Windows Server 2012 como sistema operativo invitado, deben estar instalados los servicios de integración de Windows Server 2012 R2 en la (máquina virtual) invitada. Las siguientes características no son compatibles con el uso compartido de VHDX: Réplica de Hyper-V Cambiar el tamaño del disco duro virtual mientras se ejecuta alguna de las máquinas virtuales configuradas Migración de almacenamiento en vivo Copias de seguridad de VSS de nivel de host. Las copias de seguridad de nivel de invitado deben realizarse con los mismos métodos que utilizaría para un clúster que se ejecuta en servidores físicos. Puntos de control de la máquina virtual QoS de almacenamiento

Luego, elija el tipo de disco que utilizará de entre las opciones que aparecen en la tabla siguiente.

Tipo de disco	Ventajas	Desventajas
Fijo	Menos propenso a sufrir fragmentación que otros tipos de disco Menor sobrecarga de CPU que otros tipos de disco Una vez creado el archivo VHD, no tiene que preocuparse por el espacio en disco disponible tanto como con otros tipos de disco. Compatible con las implementaciones locales y de Azure	Un disco duro virtual creado requiere que todo el espacio esté disponible, aunque la máquina virtual no esté utilizando todo el espacio. Se producirá un error al crear el disco duro virtual si no hay suficiente espacio de almacenamiento. El espacio no utilizado del disco duro virtual no se puede asignar a otros discos duros virtuales.
Dinámico	Solo utiliza el espacio necesario en cada momento, en lugar de usar todo el espacio aprovisionado.	Actualmente, no es compatible con Azure, aunque los discos dinámicos se pueden convertir en discos fijos. Es importante supervisar el espacio libre en disco al usar discos duros virtuales dinámicos. Si no hay espacio en disco disponible para que un disco duro virtual dinámico crezca, la máquina virtual entrará en estado de pausa crítica. El archivo de disco duro virtual puede fragmentarse. Sobrecarga de CPU algo mayor para las operaciones de leer y escribir que con el tipo de disco fijo
Diferenciación	Puede usar menos espacio en disco si hay varios discos de diferenciación que usan el mismo elemento primario.	Actualmente, no es compatible con Azure. Los cambios realizados en un disco primario pueden causar incoherencias de datos en el disco secundario. Sobrecarga de CPU algo mayor para las operaciones de leer y escribir de las cargas de trabajo con un uso muy intensivo de E/S

Al elegir el tipo de archivo y el formato de disco duro virtual, tenga en cuenta lo siguiente:

Si usa el formato VHDX, puede utilizar un disco dinámico, porque ofrece resistencia además de ahorrar espacio, al asignar espacio solamente cuando es necesario hacerlo.
También puede usar un disco fijo, con independencia del formato, si el almacenamiento del volumen de hospedaje no se supervisa de forma activa. Así, habrá suficiente espacio en disco cuando el archivo VHD se expanda en tiempo de ejecución.
Los puntos de control (anteriormente llamados “instantáneas”) de una máquina virtual crean un disco duro virtual de diferenciación para almacenar las escrituras en los discos. Apenas unos pocos puntos de control pueden elevar el uso de CPU de E/S de almacenamiento, pero no afectan al rendimiento de manera perceptible (excepto en las cargas de trabajo de servidor con un uso muy intensivo de E/S).

Sin embargo, tener una gran cadena de puntos de control puede afectar notablemente al rendimiento, porque la lectura de los discos duros virtuales puede requerir la comprobación de los bloques solicitados en muchos discos de diferenciación. Es importante, para mantener un buen rendimiento de E/S del disco, evitar que las cadenas de puntos de control se alarguen.

Tareas 3d: definir qué tipo de almacenamiento se utilizará para cada tipo de datos

Después de definir los tipos de datos y los tipos de almacenamiento de las máquinas virtuales, puede determinar qué tipo de almacenamiento y qué formato y qué tipo de disco virtual utilizará para cada tipo de datos.

Tarea 4: definir la estrategia de disponibilidad de máquinas virtuales

Aunque los administradores del tejido son los responsables de la disponibilidad del tejido, los administradores de las máquinas virtuales son los responsables, en última instancia, de la disponibilidad de sus máquinas virtuales. Por ello, el administrador de la máquina virtual debe comprender las funcionalidades del tejido, con el fin de diseñar la estrategia de disponibilidad adecuada para sus máquinas virtuales.

En las tablas siguientes, se analizan tres estrategias de disponibilidad para máquinas virtuales que ejecuten cargas de trabajo con las caracterizaciones que se definen en el paso 1, tarea 2, más arriba. Normalmente, el administrador del tejido informa de antemano a los administradores de las máquinas virtuales cuando tiene planeado realizar actividades de tiempo de inactividad programadas en el tejido, de modo que los administradores de las máquinas virtuales puedan ajustar sus planes en consecuencia. Las tres estrategias de disponibilidad son:

Sin estado
Con estado
Con estado compartida

Sin estado

Option	Consideraciones
Migración en vivo de máquinas virtuales en el nivel del host	Si es necesario poner un host fuera de servicio para realizar tareas de mantenimiento planeado, las máquinas virtuales en ejecución pueden migrarse a un host en funcionamiento sin que haya ningún tiempo de inactividad en las máquinas virtuales. Para más información sobre las consideraciones del host, consulte el Tarea 5: definir la estrategia de disponibilidad de host de virtualización de servidores, más abajo. Si las máquinas virtuales no están almacenadas en un almacenamiento al que puedan acceder ambos hosts, tendrá que mover el almacenamiento de las máquinas virtuales durante una migración en vivo. Si se produce un error inesperado en un host, todas las máquinas virtuales que se ejecutan en el host dejarán de ejecutarse. Debe iniciar las máquinas virtuales ejecutando la misma carga de trabajo en otro host.
Clústeres de carga equilibrada (con equilibrio de carga de red de Windows)	Requiere que el administrador de la máquina virtual tenga al menos dos máquinas virtuales que ejecuten dos cargas de trabajo idénticas hospedadas en diferentes hosts. El administrador de la máquina virtual configura el equilibrio de carga de red (NLB) en las máquinas virtuales. NLB requiere que se asignen direcciones IP estáticas a los adaptadores de red. No se admite la asignación de direcciones DHCP. El administrador de la máquina virtual tiene que colaborar con el administrador del tejido con el fin de obtener las direcciones IP que se utilizarán para la dirección IP virtual de NLB y para crear la entrada DNS necesaria. Habilite la suplantación de direcciones MAC en la red virtual que utiliza NLB en las invitadas. Puede hacerlo desde la configuración del adaptador de red de cada máquina virtual que participa en un clúster NLB como nodo. Puede crear clústeres NLB, agregar nodos y actualizar las configuraciones de clústeres NLB sin tener que reiniciar las máquinas virtuales. Todas las máquinas virtuales que forman parte del clúster de NLB deben estar en la misma subred. Para que la carga de trabajo esté siempre disponible (aunque se produzca un error en el host), el administrador del tejido de máquinas virtuales debe asegurarse de que las máquinas virtuales se ejecuten en hosts diferentes.
Clústeres de carga equilibrada (con un equilibrador de carga de hardware)	Debe proporcionar esta funcionalidad en el nivel del tejido, y los administradores deben configurar los clústeres de carga equilibrada para las máquinas virtuales que lo requieran. También puede permitir que los administradores de las máquinas virtuales la configuren en el portal de administración del equilibrador de carga de hardware. Requiere que el administrador de la máquina virtual tenga al menos dos máquinas virtuales que ejecuten dos cargas de trabajo idénticas hospedadas en el tejido. Para más información, revise la documentación del producto proporcionada por el proveedor del hardware.

Con estado

Option	Consideraciones
Clúster de Hyper-V	Requiere la configuración de un clúster de conmutación por error. Requiere almacenamiento compartido entre todos los nodos del clúster para los archivos CSV. Puede ser un recurso compartido SMB 3.0 o almacenamiento SAN. Cuando el clúster encuentra un problema con un host o Hyper-V detecta un problema con las redes de las máquinas virtuales o el almacenamiento, la máquina virtual se puede mover a otro host. La máquina virtual seguirá ejecutándose durante el desplazamiento. Si hay un error grave de un host, las máquinas virtuales que se estaban ejecutando en ese host se pueden iniciar en otros nodos del clúster. Las máquinas virtuales críticas pueden configurarse para iniciarse automáticamente. Esto limita la cantidad de tiempo de inactividad si se produce un error grave en el host. Aplique una revisión a los hosts sin afectar a las máquinas virtuales en ejecución con la Actualización compatible con clústeres. Configure la antiafinidad de las máquinas virtuales para evitar que las máquinas virtuales se ejecuten en el mismo nodo. Por ejemplo, si ejecuta dos servidores web que proporcionan servicios front-end a una aplicación back-end, estos dos servidores web no deben ejecutarse en el mismo nodo. Un nodo puede colocarse en el modo de mantenimiento, y el servicio de clúster de conmutación por error moverá las máquinas virtuales a otro nodo del clúster. Cuando no haya ninguna máquina virtual en ejecución en el nodo, podrá realizarse el mantenimiento necesario. El clúster de conmutación por error no mueve las máquinas virtuales a un nodo en el modo de mantenimiento. Antes de poner un nodo en modo de mantenimiento, asegúrese de que hay suficiente capacidad en los demás nodos del clúster de Hyper-V para ejecutar las máquinas virtuales existentes y seguir manteniendo los contratos de nivel de servicio de los clientes.

Clúster de Hyper-V

Requiere la configuración de un clúster de conmutación por error.
Requiere almacenamiento compartido entre todos los nodos del clúster para los archivos CSV. Puede ser un recurso compartido SMB 3.0 o almacenamiento SAN.
Cuando el clúster encuentra un problema con un host o Hyper-V detecta un problema con las redes de las máquinas virtuales o el almacenamiento, la máquina virtual se puede mover a otro host. La máquina virtual seguirá ejecutándose durante el desplazamiento.
Si hay un error grave de un host, las máquinas virtuales que se estaban ejecutando en ese host se pueden iniciar en otros nodos del clúster. Las máquinas virtuales críticas pueden configurarse para iniciarse automáticamente. Esto limita la cantidad de tiempo de inactividad si se produce un error grave en el host.
Aplique una revisión a los hosts sin afectar a las máquinas virtuales en ejecución con la Actualización compatible con clústeres.
Configure la antiafinidad de las máquinas virtuales para evitar que las máquinas virtuales se ejecuten en el mismo nodo. Por ejemplo, si ejecuta dos servidores web que proporcionan servicios front-end a una aplicación back-end, estos dos servidores web no deben ejecutarse en el mismo nodo.
Un nodo puede colocarse en el modo de mantenimiento, y el servicio de clúster de conmutación por error moverá las máquinas virtuales a otro nodo del clúster. Cuando no haya ninguna máquina virtual en ejecución en el nodo, podrá realizarse el mantenimiento necesario.

El clúster de conmutación por error no mueve las máquinas virtuales a un nodo en el modo de mantenimiento. Antes de poner un nodo en modo de mantenimiento, asegúrese de que hay suficiente capacidad en los demás nodos del clúster de Hyper-V para ejecutar las máquinas virtuales existentes y seguir manteniendo los contratos de nivel de servicio de los clientes.

Con estado compartida

Al ejecutar cargas de trabajo compatibles con clústeres, puede proporcionar un nivel adicional de disponibilidad habilitando la agrupación en clústeres de invitados de las máquinas virtuales. La agrupación en clústeres invitados admite la alta disponibilidad en las cargas de trabajo de la máquina virtual. La agrupación en clústeres invitados proporciona protección a la carga de trabajo que se ejecuta en las máquinas virtuales, aunque se produzcan errores en un host donde se esté ejecutando la máquina virtual. Como los clústeres de conmutación por error protegieron la carga de trabajo, la máquina virtual del otro nodo puede hacerse cargo automáticamente.

Option	Consideraciones
Agrupación en clústeres invitados de máquinas virtuales	Requiere que dos o más máquinas virtuales puedan acceder al mismo tiempo al almacenamiento compartido. Los tipos de conexión admitidos son: iSCSI Canal de fibra virtual VHDX compartido Configure la antiafinidad de las máquinas virtuales para evitar que las máquinas virtuales se ejecuten en el mismo nodo del clúster. La agrupación en clústeres de invitados de máquinas virtuales no es compatible con Azure. Las siguientes características no son compatibles con el uso compartido de VHDX: Réplica de Hyper-V Cambiar el tamaño del disco duro virtual mientras se ejecuta alguna de las máquinas virtuales configuradas Migración de almacenamiento en vivo Copias de seguridad de VSS de nivel de host. Las copias de seguridad de nivel de invitado deben realizarse con los mismos métodos que utilizaría para un clúster que se ejecuta en servidores físicos. Puntos de control de la máquina virtual QoS de almacenamiento

Agrupación en clústeres invitados de máquinas virtuales

Requiere que dos o más máquinas virtuales puedan acceder al mismo tiempo al almacenamiento compartido. Los tipos de conexión admitidos son:
- iSCSI
- Canal de fibra virtual
- VHDX compartido
Configure la antiafinidad de las máquinas virtuales para evitar que las máquinas virtuales se ejecuten en el mismo nodo del clúster.
La agrupación en clústeres de invitados de máquinas virtuales no es compatible con Azure.
Las siguientes características no son compatibles con el uso compartido de VHDX:
- Réplica de Hyper-V
- Cambiar el tamaño del disco duro virtual mientras se ejecuta alguna de las máquinas virtuales configuradas
- Migración de almacenamiento en vivo
- Copias de seguridad de VSS de nivel de host. Las copias de seguridad de nivel de invitado deben realizarse con los mismos métodos que utilizaría para un clúster que se ejecuta en servidores físicos.
- Puntos de control de la máquina virtual
- QoS de almacenamiento

Información adicional:

Implementar un clúster invitado con un disco duro virtual compartido

Usar clústeres invitados para alta disponibilidad

Recuperación de desastres

Si se produce un desastre, ¿cuánto puede tardar en lograr que las cargas de trabajo necesarias vuelvan a funcionar y a dar servicio a los clientes? En algunos casos, el tiempo asignado puede ser de tan solo unos minutos.

La replicación de datos desde los centros de datos principales hasta los centros de recuperación ante desastres es necesaria para que se puedan replicar los datos más actualizados con una pérdida aceptable de datos debido a los retrasos. Al ejecutar las cargas de trabajo en las máquinas virtuales, puede replicar los discos duros virtuales y los archivos de configuración de máquinas virtuales desde el sitio principal hasta un sitio de réplica.

En la siguiente tabla, se comparan las opciones de recuperación ante desastres.

Option	Consideraciones
Réplica de Hyper-V	De bajo coste, y no es necesario duplicar el hardware de almacenamiento y el host en los sitios de recuperación ante desastres. Use las mismas herramientas de administración para administrar la replicación que para administrar las máquinas virtuales. Intervalos de replicación configurables para que el margen de pérdida de datos coincida con sus requisitos. Configure diferentes direcciones IP para utilizarlas en el sitio de réplica. Impacto mínimo en la infraestructura de red. Incompatible con las máquinas virtuales configuradas con discos físicos (también llamados “discos de paso a través”), el almacenamiento de Canal de fibra virtual y los discos duros virtuales compartidos. La Réplica de Hyper-V no debe utilizarse para reemplazar el almacenamiento de copias de seguridad de datos ni la recuperación de datos. Si se configuran puntos de recuperación adicionales, será necesario almacenamiento adicional en el sitio de réplica. El ritmo de los intervalos de replicación determinará la cantidad de pérdida de datos. Si una máquina virtual con una gran cantidad de cambios se configura con un intervalo de replicación corto, será necesario almacenamiento adicional en el sitio de réplica.
Copias de seguridad	Realice una copia de seguridad de la máquina virtual completa con una solución de copia de seguridad compatible con Hyper-V como, por ejemplo, System Center Data Protection Manager. La pérdida de datos dependerá de la antigüedad de la última copia de seguridad. No se puede hacer una copia de seguridad en el nivel de host de las máquinas virtuales configuradas con un archivo VHDX compartido. Instale un agente de copia de seguridad en la máquina virtual y realice una copia de seguridad de los datos desde dentro de la máquina virtual.

Réplica de Hyper-V

De bajo coste, y no es necesario duplicar el hardware de almacenamiento y el host en los sitios de recuperación ante desastres.
Use las mismas herramientas de administración para administrar la replicación que para administrar las máquinas virtuales.
Intervalos de replicación configurables para que el margen de pérdida de datos coincida con sus requisitos.
Configure diferentes direcciones IP para utilizarlas en el sitio de réplica.
Impacto mínimo en la infraestructura de red.
Incompatible con las máquinas virtuales configuradas con discos físicos (también llamados “discos de paso a través”), el almacenamiento de Canal de fibra virtual y los discos duros virtuales compartidos.
La Réplica de Hyper-V no debe utilizarse para reemplazar el almacenamiento de copias de seguridad de datos ni la recuperación de datos.
Si se configuran puntos de recuperación adicionales, será necesario almacenamiento adicional en el sitio de réplica.
El ritmo de los intervalos de replicación determinará la cantidad de pérdida de datos.
Si una máquina virtual con una gran cantidad de cambios se configura con un intervalo de replicación corto, será necesario almacenamiento adicional en el sitio de réplica.

Copias de seguridad

Realice una copia de seguridad de la máquina virtual completa con una solución de copia de seguridad compatible con Hyper-V como, por ejemplo, System Center Data Protection Manager.
La pérdida de datos dependerá de la antigüedad de la última copia de seguridad.
No se puede hacer una copia de seguridad en el nivel de host de las máquinas virtuales configuradas con un archivo VHDX compartido. Instale un agente de copia de seguridad en la máquina virtual y realice una copia de seguridad de los datos desde dentro de la máquina virtual.

Notas:

Para administrar y automatizar la replicación de forma centralizada al ejecutar System Center 2012 R2 Virtual Machine Manager, deberá usar Microsoft Azure Site Recovery.
Para replicar las máquinas virtuales en Azure con Microsoft Azure Site Recovery. La replicación de máquinas virtuales en Azure está, actualmente, en modo de vista previa.

Información adicional:

Recuperación de sitios de Microsoft Azure

Importante:

Utilice el Programador de capacidad de Réplica de Hyper-V para comprender el impacto que tendrá la réplica de Hyper-V sobre su infraestructura de red, el uso de procesador de los servidores principal, Réplica y Réplica extendido, el uso de memoria de los servidores principal y Réplica, y las IOPS de disco de los servidores principal, Réplica y Réplica extendido que se basan en las máquinas virtuales existentes.
Puede que su carga de trabajo tenga una solución de recuperación ante desastres integrada, como los grupos de disponibilidad AlwaysOn de SQL Server. Consulte la documentación de la carga de trabajo para confirmar si la Réplica de Hyper-V es compatible con la carga de trabajo.

Información adicional:

Réplica de Hyper-V

System Center Data Protection Manager

Tarea 5: definir los tipos de máquina virtual

Para admitir las cargas de trabajo en su entorno, puede crear máquinas virtuales con requisitos de recursos únicos para cubrir las necesidades de cada carga de trabajo. También puede adoptar un enfoque similar al de los proveedores públicos de máquinas virtuales que hospedan servicios (también llamado “infraestructura como servicio” (IaaS)).

Consulte Tamaños de máquinas virtuales y servicios en la nube de Azure para ver una descripción de las configuraciones de máquina virtual que ofrecen los Servicios de infraestructura de Microsoft Azure. En la fecha en la que se redactó este texto, el servicio admitía 13 configuraciones de máquina virtual, cada una con diferentes combinaciones de espacio para procesador, memoria, almacenamiento e IOP.

Decisión de diseño: puede escribir las decisiones que tome en todas las tareas de este paso en las hojas de cálculo de configuración de máquinas virtuales.

Paso 3: planear los grupos host de virtualización de servidores

Antes de definir los hosts de servidor individual, puede que desee definir primero los grupos host. Un grupo host es, simplemente, una colección con nombre de los servidores que se agrupan para cumplir los objetivos comunes que se describen en las tareas restantes de este paso.

Tarea 1: definir las ubicaciones físicas

Probablemente, agrupará y administrará los recursos de hardware por su ubicación física, por lo que es conveniente que defina primero las ubicaciones que contengan recursos del tejido dentro de la organización.

Tarea 2: definir los tipos de grupos host

Puede crear grupos host por diversos motivos como, por ejemplo, para hospedar cargas de trabajo de con determinados:

Caracterizaciones de carga de trabajo
Requisitos de recursos
Requisitos de calidad de servicio

La siguiente imagen ilustra una organización que creó cinco grupos host en dos ubicaciones.

Grupo host

Figure 2:Ejemplo de grupo host

La organización creó los grupos host por las razones que se describen en la tabla siguiente.

Grupo host	Razones para crearlo
Carga de trabajo con y sin estado	Estas caracterizaciones de cargas de trabajo son las más comunes en esta organización, por lo que tienen este tipo de grupo host en ambas ubicaciones. Estas cargas de trabajo tienen requisitos de nivel de servicio y rendimientos similares.
Cargas de trabajo con estado y sin estado del departamento de contabilidad	Aunque la configuración de hardware de los servidores de este grupo host es la misma que la de otros grupos host de cargas de trabajo con y sin estado de su entorno, el departamento de contabilidad tiene aplicaciones con requisitos de seguridad mayores que otros departamentos de la organización. Por ello, se creó un grupo host dedicado para ellos, para poder protegerlo de manera diferente a la de los otros grupos host del tejido.
Cargas de trabajo con estado compartidas	Las cargas de trabajo hospedadas por este grupo host requieren almacenamiento compartido, porque dependen de los clústeres de conmutación por error de Windows Server para mantener su disponibilidad. Estas cargas de trabajo se hospedan en un grupo host dedicado, porque la configuración de estas máquinas virtuales es diferente de la de las otras máquinas virtuales de la organización.
Cargas de trabajo con estado de muchas E/S	Todos los hosts de este grupo host se conectan a redes de mayor velocidad que los hosts de los otros grupos host.

Aunque la organización podría haber distribuido las ubicaciones con sus grupos host, decidió mantener a todos los miembros de cada grupo host dentro de la misma ubicación para facilitar su administración. Como puede ver en este ejemplo, se pueden crear grupos host por diversos motivos, que varían entre una organización y otra. Cuantos más tipos de grupos host cree en la organización, más complejo resultará el entorno a la hora de administrarlo, lo que afectará en última instancia al coste de hospedar las máquinas virtuales.

Sugerencia: Cuanto más estandarizado esté el hardware del servidor dentro de un grupo host, más fácil será escalar y mantener el grupo host con el tiempo. Si decide estandarizar el hardware de un grupo host, puede agregar los datos de configuración estandarizados a la hoja de cálculo de grupos host de Hojas de cálculo de consideraciones de diseño de tejidos de virtualización. Para más información sobre las consideraciones de hardware físico, consulte el Paso 4: planear los hosts de virtualización de servidores.

Tenga en cuenta que, en la actualidad, la mayoría de los proveedores de nube pública que hospedan máquinas virtuales:

Solo hospedan las máquinas virtuales que no requieren el estado compartido.
A menudo, solo tienen un conjunto de medidas de calidad de servicio que proporcionan a todos los clientes.
No dedican un hardware específico a cada cliente.

Le recomendamos que comience con un tipo de grupo host que contenga hardware idéntico, y que solo agregue tipos de grupos host adicionales cuando las ventajas de hacerlo compensen los costes.

Tarea 3: determinar si los miembros del grupo host se deben agrupar en clústeres

Antes, los clústeres de conmutación por error de Windows Server solo se usaban para aumentar la disponibilidad del servidor, pero ahora proporcionan una funcionalidad significativamente mayor. Tenga en cuenta la información de la tabla siguiente al decidir si quiere agrupar en clústeres los miembros del grupo host.

Option	Ventajas	Desventajas
Los miembros del grupo host forman parte de un clúster de conmutación por error.	Si se produce un error en algún host, las máquinas virtuales que hospeda se reiniciarán automáticamente en los nodos que sobrevivan. Las máquinas virtuales se pueden mover a otro nodo del clúster cuando el nodo donde se están ejecutando detecta un problema con el nodo o en la máquina virtual. Utilice la Actualización compatible con clústeres para actualizar fácilmente los nodos del clúster sin que esto afecte a las máquinas virtuales en ejecución.	Los hosts requieren una configuración específica para ser miembros de un clúster. Los hosts deben ser miembros de un dominio de Active Directory. La agrupación en clústeres de conmutación por error requiere requisitos adicionales de redes y almacenamiento.
Los miembros del grupo host no forman parte de un clúster de conmutación por error.	Los hosts no requieren una configuración de clúster específica. Los hosts no tienen por qué ser miembros de un dominio de Active Directory. No son necesarios almacenamiento ni redes adicionales.	Las máquinas virtuales que se ejecutan en un host donde se produce un error deben moverse manualmente (o puede utilizar alguna forma de automatización) a un host que sobreviva y reiniciarse.

Decisión de diseño: puede escribir las decisiones que tome en todas las tareas de este paso en la hoja de cálculo de configuración.

Paso 4: planear los hosts de virtualización de servidores

En este paso, definirá los tipos de hosts que necesitará para hospedar las máquinas virtuales que tiene pensado ejecutar en el tejido de virtualización. Es conveniente que limite la cantidad de configuraciones de host, a veces incluso hasta una sola configuración, para facilitar la adquisición y no incrementar los costes de soporte técnico. Además, si adquiere el equipo equivocado, los costes de implementación aumentarán.

Cloud Platform System

Microsoft le ofrece su experiencia con algunos de los mayores servicios en la nube y centros de datos en un sistema convergente totalmente validado e integrado de fábrica. Cloud Platform System (CPS) combina la pila de software comprobada de Microsoft, con Windows Server 2012 R2, System Center 2012 R2 y Windows Azure Pack, y el hardware de redes, almacenamiento y servidor para la nube de Dell. Como bloque de creación escalable para la nube, CPS acorta el plazo de obtener rentabilidad y ofrece una experiencia de nube coherente.

CPS proporciona un entorno de nube multiempresa y autoservicio para máquinas virtuales de plataforma como servicio, Windows y Linux, e incluye paquetes de implementación optimizados para aplicaciones de Microsoft como SQL Server, SharePoint y Exchange. La integración de fábrica disminuye el riesgo y la complejidad y, al mismo tiempo, reduce el tiempo de implementación de meses a días. El proceso de soporte técnico simplificado y la automatización de las tareas rutinarias de la infraestructura también liberan recursos de TI para que pueda centrarse en innovar.

Para más información, consulte el sitio Cloud Platform System.

Fast Track

En lugar de diseñar la configuración de hardware (y software), puede adquirir configuraciones de hardware preconfiguradas de diversos socios de hardware a través del programa Microsoft Private Cloud Fast Track.

El programa Fast Track es una iniciativa conjunta de Microsoft y sus socios de hardware para ofrecer soluciones validadas y preconfiguradas que reducen la complejidad y el riesgo de implementar un tejido de virtualización y las herramientas para administrarlo.

El programa Fast Track permite al cliente elegir con flexibilidad las soluciones de entre las diversas tecnologías de los proveedores de hardware. Utiliza las funcionalidades básicas del sistema operativo Windows Server, la tecnología Hyper-V y Microsoft System Center para proporcionar los bloques de creación de una oferta de infraestructura como servicio de nube privada.

Información adicional:

Sitio de Microsoft Private Cloud Fast Track

Tarea 1: definir la configuración de proceso

En esta tarea, podrá determinar la cantidad de memoria, el número de procesadores y la versión de Windows Server que son necesarios para cada host. Los componentes de hardware que se explican en esta sección determinan el número de máquinas virtuales que se ejecutan en un host.

Nota: Para asegurarse de que la solución sea totalmente compatible, todo el hardware que adquiera deberá llevar el logotipo de certificación para Windows Server de la versión de Windows Server que esté ejecutando.

El logotipo de certificación para Windows Server demuestra que un sistema de servidor cumple con los estándares técnicos más altos de Microsoft en materia de seguridad, confiabilidad y capacidad de administración. Con otros dispositivos y controladores certificados, puede admitir los roles, las características y las interfaces de las cargas de trabajo empresariales y de nube y las aplicaciones empresariales fundamentales.

Para ver la lista más reciente de hardware con certificación para Windows Server, consulte el catálogo de Windows Server.

Tarea 1a: definir el procesador

Hyper-V presenta los procesadores lógicos a cada máquina virtual activa como uno o más procesadores virtuales. Puede conseguir eficacia adicional en tiempo de ejecución si utiliza procesadores compatibles con las tecnologías de traducción de direcciones de segundo nivel (SLAT), como las tablas de páginas extendidas (EPT) o las tablas de páginas anidadas (NPT). Hyper-V en Windows Server 2012 R2 admite un máximo de 320 procesadores lógicos.

Consideraciones:

Las cargas de trabajo sin un uso intensivo del procesador deben configurarse para usar un procesador virtual. Supervise la utilización del procesador del host de vez en cuando, para asegurarse de que asignó los procesadores adecuados para obtener la máxima eficacia.
Las cargas de trabajo con un uso intensivo de la CPU deben tener asignados dos o más procesadores virtuales. Puede asignar un máximo de 64 procesadores virtuales a una máquina virtual. El número de procesadores virtuales reconocidos por la máquina virtual depende del sistema operativo invitado. Por ejemplo, Windows Server 2008 con Service Pack 2 reconoce solo cuatro procesadores virtuales.

Información adicional:

Introducción a Hyper-V

Ajuste de rendimiento para servidores Hyper-V

Tarea 1b: definir la memoria

El servidor físico requiere suficiente memoria para las máquinas virtuales en ejecución y el host. El host necesita memoria para realizar E/S de manera eficiente en nombre de las máquinas virtuales, y para llevar a cabo operaciones como, por ejemplo, crear un punto de control de la máquina virtual. Hyper-V se asegura de que haya suficiente memoria disponible para el host, y permite que el resto de la memoria se asigne a las máquinas virtuales. El tamaño de las máquinas virtuales se debe ajustar según las necesidades de la carga esperada para cada máquina virtual.

El hipervisor virtualiza la memoria física del invitado para aislar las máquinas virtuales entre sí y para proporcionar un espacio de memoria contiguo y de base cero para cada sistema operativo invitado, el mismo que en los sistemas no virtualizados. Para obtener el máximo rendimiento, utilice hardware basado en SLAT para minimizar el coste de rendimiento de la virtualización de la memoria.

Ajuste el tamaño de la memoria de la máquina virtual como se suele hacer para las aplicaciones de servidor de un equipo físico. La cantidad de memoria asignada a la máquina virtual debe permitir que la máquina virtual administre la carga esperada de forma razonable en los períodos normales y las horas pico, porque la insuficiencia de memoria puede aumentar significativamente los tiempos de respuesta y el uso de CPU o E/S.

La memoria asignada a una máquina virtual reduce la cantidad de memoria que está disponible para las demás máquinas virtuales. Si no hay suficiente memoria disponible en el host, la máquina virtual no se iniciará.

La memoria dinámica permite alcanzar cifras más altas de consolidación con una mayor confiabilidad en las operaciones de reinicio. De este modo, se pueden reducir los costes, especialmente en los entornos que tienen muchas máquinas virtuales inactivas o con poca carga, como los entornos de VDI agrupados. Los cambios de configuración en tiempo de ejecución de memoria dinámica pueden reducir el tiempo de inactividad y proporcionar mayor agilidad para responder a los cambios en los requisitos.

Para más información sobre la memoria dinámica, consulte el Tarea 1b: definir la memoria, en el que se explica cómo determinar la memoria de una máquina virtual.

Información adicional:

Información general sobre la memoria dinámica

Introducción a NUMA virtual

Tarea 1c: definir la edición del sistema operativo Windows Server

Los conjuntos de características de Windows Server Standard y Windows Server Datacenter son exactamente los mismos. Windows Server Datacenter proporciona un número ilimitado de máquinas virtuales. Con Windows Server Standard, está limitado a dos máquinas virtuales.

En Windows Server 2012 R2, se agregó la característica de activación automática de máquina virtual (AVMA). AVMA permite instalar máquinas virtuales en un servidor activado correctamente sin tener que administrar claves de producto para cada máquina virtual, incluso en entornos desconectados.

AVMA requiere que los sistemas operativos invitados ejecuten Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard o Windows Server 2012 R2 Essentials. La siguiente tabla compara las ediciones.

Edición	Ventajas	Desventajas
Standard	Incluye todas las características de Windows Server. Aceptable para los entornos no virtualizados o poco virtualizados	Limitado a dos máquinas virtuales
Datacenter	Incluye todas las características de Windows Server. Permite un número ilimitado de máquinas virtuales. Aceptable para entornos de nube privada muy virtualizados	Más caro

Hyper-V puede instalarse en una opción de instalación de Server Core de Windows Server. La instalación de Server Core reduce el espacio necesario en el disco, la superficie expuesta a ataques potenciales y, especialmente, los requisitos de mantenimiento. La instalación de Server Core se administra con la línea de comandos, con Windows PowerShell o con administración remota.

Es importante revisar los términos de licencia de todo el software que se va a utilizar.

Microsoft Hyper-V Server

Microsoft Hyper-V Server proporciona una solución de virtualización confiable y simple que ayuda a las organizaciones a mejorar su uso del servidor y reducir los costes. Es un producto independiente que contiene solo el hipervisor de Windows, un modelo de controlador de Windows Server y componentes de virtualización.

Hyper-V Server encaja en los entornos de TI existentes de los clientes y permite sacar provecho de sus herramientas de soporte técnico y sus procesos de administración y aprovisionamiento existentes. Admite la misma lista de compatibilidad de hardware que las ediciones de Windows Server correspondientes, y se integra completamente con Microsoft System Center y las tecnologías de Windows, como Windows Update, Active Directory y los clústeres de conmutación por error.

Hyper-V Server se puede descargar gratuitamente y la instalación viene ya activada. Sin embargo, cada sistema operativo que se ejecute en una máquina virtual hospedada requerirá una licencia adecuada.

Información adicional:

Activación automática de máquina virtual

Microsoft Hyper-V Server

Administrar Hyper-V Server de forma remota

Tarea 2: definir la configuración de red

En el paso 2, tarea 2, más arriba, analizamos las consideraciones de diseño de las redes de máquinas virtuales. Ahora vamos a explicar la consideración de las redes del host. Hay varios tipos de tráfico de red que debe tener en cuenta y planear al implementar Hyper-V. Debe diseñar la configuración de red teniendo en cuenta los siguientes objetivos:

Garantizar la QoS de red
Proporcionar redundancia de red
Aislar el tráfico a las redes definidas

Tarea 2a: definir los tipos de tráfico de red

Al implementar un clúster de Hyper-V, debe planear varios tipos de tráfico de red. En la tabla siguiente, se resumen los tipos de tráfico.

Tipo de tráfico	Descripción
Administración	Proporciona conectividad entre el servidor que ejecuta Hyper-V y la funcionalidad de infraestructura básica. Se usa para administrar las máquinas virtuales y el sistema operativo host de Hyper-V.
Clúster y CSV	Se usa para la comunicación entre nodos del clúster, como el latido del clúster y la redirección de volúmenes compartidos de clúster (CSV). Solo si Hyper-V se implementó con clústeres de conmutación por error
Live migration	Se usa para la migración en vivo de máquinas virtuales y la migración en vivo sin uso compartido.
Almacenamiento	Se usa para el tráfico SMB o el tráfico iSCSI.
Réplica	Se usa para el tráfico de replicación de máquinas virtuales con la característica de Réplica de Hyper-V.
Tráfico de máquina virtual (inquilino)	Se usa para la conectividad de las máquinas virtuales. Suele requerir conectividad de red externa para atender las solicitudes de cliente. Nota: Consulte el Paso 2: planear la configuración de máquinas virtuales para ver una lista de los tipos de tráfico de las máquinas virtuales.
Copias de seguridad	Se usa para hacer copias de seguridad de los archivos de disco duro virtual.

Tarea 2b: definir las opciones de rendimiento del tráfico de red

Cada tipo de tráfico de red tendrá requisitos de latencia mínima y requisitos de ancho de banda máximo y mínimo. Las estrategias que pueden utilizarse para cubrir los diferentes requisitos de rendimiento de red son las siguientes.

QoS basada en directivas

Al implementar un clúster de Hyper-V, necesita un mínimo de seis patrones de tráfico o redes. Cada red requiere redundancia de red. Para empezar, estamos hablando de 12 adaptadores de red en el host. Es posible instalar varios adaptadores de red cuádruples, pero en algún momento se quedará sin ranuras en el host.

Los equipos de red avanzan más rápido. No hace mucho, los adaptadores de red de 1 GB eran un lujo. Ahora, los adaptadores de 10 GB son cada vez más comunes en los servidores, y los precios que supone admitir las infraestructuras de 10 GB son cada vez más razonables.

Dos adaptadores de red de 10 GB agrupados proporcionan más ancho de banda que dos adaptadores cuádruples de 1 GB, requieren menos puertos de conmutador y simplifican la necesidad de cableado. A medida que une los diversos tipos de tráfico de red en adaptadores de red de 10 GB agrupados, las directivas basadas en QoS permiten administrar el tráfico de red para cubrir correctamente las necesidades de la infraestructura de virtualización.

La QoS basada en directivas le permite especificar el control de ancho de banda de red en función de los equipos, los usuarios y el tipo de aplicación. Las directivas de QoS le permiten cubrir los requisitos de servicios de una carga de trabajo o una aplicación al medir el ancho de banda de red, detectar los cambios en las condiciones de red (por ejemplo, congestión o disponibilidad de ancho de banda) y clasificar por orden de prioridad (o limitar) el tráfico de red.

Además de poder aplicar el ancho de banda máximo, las directivas de QoS de Windows Server 2012 R2 proporcionan una nueva característica de administración de ancho de banda: el ancho de banda mínimo. A diferencia del ancho de banda máximo, que es un tope del ancho de banda, el ancho de banda mínimo es un punto de partida del ancho de banda y asigna una determinada cantidad de ancho de banda a un tipo determinado de tráfico. Puede implementar límites de ancho de banda mínimos y máximos al mismo tiempo.

Ventajas	Desventajas
Administrado por la directiva de grupo Se aplica fácilmente a las redes VLAN para proporcionar la configuración de ancho de banda adecuada cuando se ejecutan varias VLAN en el adaptador de red o con la Formación de equipos NIC. La QoS basada en directivas se puede aplicar al tráfico de IPsec.	No proporciona administración de ancho de banda para el tráfico que utiliza un conmutador virtual. Los hosts de Hyper-V deben estar unidos a un dominio. Las directivas de QoS basadas en software y las directivas de QoS basadas en hardware (DCB) no deben utilizarse al mismo tiempo.

Información adicional:

Introducción a la Calidad de servicio (QoS)

Calidad de servicio basada en directivas

Protocolo de puente del centro de datos

El protocolo de puente del centro de datos (DCB) proporciona la asignación de ancho de banda basada en hardware a un tipo específico de tráfico y mejora la confiabilidad del transporte Ethernet mediante el control de flujo basado en prioridad. Se recomienda usar DCB con FCoE e iSCSI.

Ventajas	Desventajas
Compatibilidad con iSCSI de Microsoft Compatibilidad con FCoE	Inversiones de hardware necesarias, incluidos: Adaptadores Ethernet compatibles con DCB Conmutadores de hardware compatibles con DCB Complejo de implementar y administrar No proporciona administración de ancho de banda para el tráfico del conmutador virtual. Las directivas de QoS basada en software y las directivas DCB no deben utilizarse al mismo tiempo.

Información adicional:

Información general sobre el protocolo de puente del centro de datos (DCB)

SMB directo

SMB directo (SMB sobre acceso directo a memoria remota o RDMA) es un protocolo de almacenamiento de Windows Server 2012 R2. Permite las transferencias de datos directas de memoria a memoria entre el servidor y el almacenamiento. Requiere un uso mínimo de la CPU y utiliza adaptadores de red compatibles con RDMA estándar. De este modo, proporciona respuestas rápidas a las solicitudes de red y, con ello, tiempos de respuesta de almacenamiento de archivos remotos similares a los del almacenamiento de bloques conectados directamente.

Ventajas	Desventajas
Aumento de rendimiento: aprovecha todo el rendimiento de las redes de alta velocidad, donde los adaptadores de red coordinan la transferencia de grandes cantidades de datos a velocidad de línea. Latencia baja: proporciona respuestas extremadamente rápidas a las solicitudes de red y, con ello, hace que el almacenamiento de archivos remoto parezca almacenamiento en bloque conectado directamente. Uso bajo de CPU: usa menos ciclos de CPU al transferir datos a través de la red, lo que libera más ciclos de CPU de las máquinas virtuales. La migración en vivo se puede configurar de modo que se use SMB directo, para realizar migraciones en vivo con mayor rapidez. Habilitado de forma predeterminada en el host El cliente SMB detecta y utiliza automáticamente varias conexiones de red si no se identifica una configuración apropiada. Configure la administración de ancho de banda de SMB para establecer los límites de la migración en vivo, las máquinas virtuales y el tráfico de almacenamiento predeterminado. SMB multicanal no requiere adaptadores compatibles con RDMA.	Los adaptadores de red habilitados para RDMA no son compatibles con la Formación de equipos NIC. Requiere implementar dos o más adaptadores de red RDMA en cada host para proporcionar alta disponibilidad. Actualmente está limitado a los siguientes tipos de adaptadores de red: iWARP Infiniband RoCE El uso de RDMA con RoCE requiere DCB para el control de flujo.

Aumento de rendimiento: aprovecha todo el rendimiento de las redes de alta velocidad, donde los adaptadores de red coordinan la transferencia de grandes cantidades de datos a velocidad de línea.
Latencia baja: proporciona respuestas extremadamente rápidas a las solicitudes de red y, con ello, hace que el almacenamiento de archivos remoto parezca almacenamiento en bloque conectado directamente.
Uso bajo de CPU: usa menos ciclos de CPU al transferir datos a través de la red, lo que libera más ciclos de CPU de las máquinas virtuales.
La migración en vivo se puede configurar de modo que se use SMB directo, para realizar migraciones en vivo con mayor rapidez.
Habilitado de forma predeterminada en el host
El cliente SMB detecta y utiliza automáticamente varias conexiones de red si no se identifica una configuración apropiada.
Configure la administración de ancho de banda de SMB para establecer los límites de la migración en vivo, las máquinas virtuales y el tráfico de almacenamiento predeterminado.
SMB multicanal no requiere adaptadores compatibles con RDMA.

Los adaptadores de red habilitados para RDMA no son compatibles con la Formación de equipos NIC.
Requiere implementar dos o más adaptadores de red RDMA en cada host para proporcionar alta disponibilidad.
Actualmente está limitado a los siguientes tipos de adaptadores de red:
- iWARP
- Infiniband
- RoCE
El uso de RDMA con RoCE requiere DCB para el control de flujo.

Fusión de segmentos de recepción

La fusión de segmentos de recepción (RSC) reduce el uso de CPU del procesamiento de red entrante al descargar las tareas de la CPU a un adaptador de red compatible con RSC.

Ventajas	Desventajas
Mejora la escalabilidad de los servidores al reducir la sobrecarga de procesamiento de una gran cantidad de tráfico de red entrante. Minimiza los ciclos de CPU que se emplean para el almacenamiento de red y las migraciones en vivo.	Requiere un adaptador de red compatible con RSC. No proporciona una mejora significativa de las cargas de trabajo de uso intensivo de envíos. No es compatible con el tráfico cifrado IPsec. Se aplica al tráfico de host. Para aplicar RSC al tráfico de la máquina virtual, la máquina virtual debe ejecutar Windows Server 2012 R2 y estar configurada con un adaptador de red SR-IOV. No está habilitado de forma predeterminada en los servidores actualizados a Windows Server 2012 R2.

Mejora la escalabilidad de los servidores al reducir la sobrecarga de procesamiento de una gran cantidad de tráfico de red entrante.
Minimiza los ciclos de CPU que se emplean para el almacenamiento de red y las migraciones en vivo.

Requiere un adaptador de red compatible con RSC.
No proporciona una mejora significativa de las cargas de trabajo de uso intensivo de envíos.
No es compatible con el tráfico cifrado IPsec.
Se aplica al tráfico de host. Para aplicar RSC al tráfico de la máquina virtual, la máquina virtual debe ejecutar Windows Server 2012 R2 y estar configurada con un adaptador de red SR-IOV.
No está habilitado de forma predeterminada en los servidores actualizados a Windows Server 2012 R2.

Escalado del lado de recepción

El escalado del lado de recepción (RSS) permite a los adaptadores de red distribuir la carga de procesamiento de red de modo kernel entre varios núcleos de procesador de varios equipos básicos. La distribución de este procesamiento permite admitir mayores cargas de tráfico de red de las que se obtendrían si solo se utilizara un núcleo. RSS lo logra al repartir la carga de procesamiento de red entre muchos procesadores y equilibrar de forma activa la carga del tráfico que finaliza el Protocolo de control de transmisión (TCP).

Ventajas	Desventajas
Distribuye las interrupciones de supervisión entre varios procesadores, por lo que no es necesario un procesador concreto para controlar todas las interrupciones de E/S, que son comunes a las versiones anteriores de Windows Server. Funciona con la Formación de equipos NIC. Funciona con el tráfico de Protocolo de datagramas de usuario (UDP).	Requiere un adaptador de red compatible con RSS. Se deshabilita si el adaptador de red virtual se enlaza a un conmutador virtual. VMQ se utiliza en lugar de RSS para los adaptadores de red enlazados a un conmutador virtual.

SR-IOV

Hyper-V admite los dispositivos de red compatibles con SR-IOV y permite la asignación directa de una función virtual de SR-IOV de un adaptador de red físico a una máquina virtual. Esto aumenta el rendimiento de la red, reduce la latencia de red y reduce la sobrecarga de CPU del host necesaria para procesar el tráfico de red.

Para más información sobre SR-IOV, consulte el Tarea 2b: definir las opciones de rendimiento del tráfico de red, más arriba.

Tarea 2c: definir la estrategia de agregación de ancho de banda y alta disponibilidad del tráfico de red

La Formación de equipos NIC, también llamada “equilibrio de carga y conmutación por error” (LBFO), permite colocar varios adaptadores de red en un equipo para la agregación de ancho de banda y la conmutación por error del tráfico. Esto ayuda a mantener la conectividad si se produce un error en un componente de red.

Los proveedores de adaptadores de red ofrecen esta característica desde hace tiempo. Desde Windows Server 2012, la Formación de equipos NIC se incluye como característica del sistema operativo Windows Server.

La Formación de equipos NIC es compatible con todas las funcionalidades de red de Windows Server 2012 R2, con tres excepciones:

SR-IOV
RDMA
Autenticación 802.1X

Desde la perspectiva de la escalabilidad, en Windows Server 2012 R2, se pueden agregar a un solo equipo entre 1 y 32 adaptadores de red. Puede crearse en un solo host un número ilimitado de equipos.

Información adicional:

Introducción a la formación de equipos NIC

Microsoft Virtual Academy: Formación de equipos NIC en Windows Server 2012

Cmdlets de Formación de equipos NIC (NetLBFO) en Windows PowerShell

Implementación y administración de Formación de equipos NIC (LBFO) de Windows Server 2012 R2

Centro de datos convergente con almacenamiento del servidor de archivos

Tarea 2d: definir la estrategia de aislamiento y seguridad del tráfico de red

Cada tipo de tráfico de red puede tener distintos requisitos de seguridad para funciones como el aislamiento y el cifrado. En la tabla siguiente, se muestran las estrategias que pueden utilizarse para cumplir los diversos requisitos de seguridad.

Estrategia	Ventajas	Desventajas
Cifrado (IPsec)	El tráfico se protege al atravesar la red.	Impacto en el rendimiento para cifrar y descifrar el tráfico. Es complejo configurarlo, administrarlo y solucionar los problemas. Los cambios de configuración incorrectos de IPsec pueden provocar interrupciones de red o hacer que el tráfico no se cifre correctamente.
Redes físicas independientes	La red está físicamente separada.	Requiere instalar adaptadores de red adicionales en el host. Si la red requiere alta disponibilidad, son necesarios dos o más adaptadores de red para cada red.
Red de área local virtual (VLAN)	Aísla el tráfico con un identificador de VLAN asignado. Compatibilidad con el protocolo de enlace troncal VLAN Compatibilidad con VLAN privadas Ya lo usan muchos clientes de empresa.	Limitado a 4094 redes VLAN, y la mayoría de los conmutadores admite solo 1000 VLAN. Requiere la configuración y la administración adicionales de equipos de red. Las redes VLAN no pueden abarcar varias subredes de Ethernet, lo que limita el número de nodos de una sola VLAN y restringe la colocación de las máquinas virtuales, según la ubicación física.

Tarea 2e: definir los adaptadores de red virtuales

Con una comprensión de los tipos de tráfico que requieren los hosts de los servidores de virtualización, y las estrategias de rendimiento, disponibilidad y seguridad del tráfico, puede determinar cuántos adaptadores de red físicos son necesarios para cada host y los tipos de tráfico de red que se transmitirán con cada adaptador.

Tarea 2f: definir los conmutadores virtuales

Para conectar una máquina virtual a una red, deberá conectar el adaptador de red a un conmutador virtual de Hyper-V.

Hay tres tipos de conmutadores virtuales que se pueden crear en Hyper-V:

Conmutador virtual externo

Use un conmutador virtual externo cuando quiera proporcionar a las máquinas virtuales acceso a una red física para comunicarse con clientes y servidores ubicados externamente. Este tipo de conmutador virtual también permite que las máquinas virtuales del mismo host se comuniquen entre sí. Este tipo de red también puede estar disponible para que la use el sistema operativo host, según cómo configure las redes.

Importante: un adaptador de red físico no se puede enlazar a más de un conmutador virtual.
Conmutador virtual interno

Use un conmutador virtual interno cuando quiera permitir la comunicación entre máquinas virtuales del mismo host, y entre las máquinas virtuales y el sistema operativo host. Este tipo de conmutador virtual se utiliza, normalmente, para crear un entorno de prueba en el que tiene que conectarse a las máquinas virtuales desde el sistema operativo host. Las redes virtuales internas no están enlazadas a un adaptador de red físico. Por ello, la red virtual interna está aislada del tráfico de red externo.
Conmutador virtual privado

Use un conmutador virtual privado cuando quiera permitir la comunicación únicamente entre las máquinas virtuales del mismo host. Los conmutadores virtuales privados no están enlazados a un adaptador de red físico. Un conmutador virtual privado se aísla de todo el tráfico de red externo en el servidor de virtualización, y de todo el tráfico de red entre el sistema operativo host y la red externa. Este tipo de red resulta útil cuando necesita crear un entorno de red aislado como, por ejemplo, un dominio de prueba aislado.

Nota: Los conmutadores virtuales privados e internos no se benefician de las características de aceleración de hardware que están disponibles para una máquina virtual conectada a un conmutador virtual externo.

Decisión de diseño: puede escribir las decisiones que tome en todas las tareas de este paso en las hojas de cálculo de hosts de virtualización.

Sugerencia: Los conmutadores virtuales de diferentes hosts que se conectan a la misma red deben tener el mismo nombre. Así, se elimina la confusión sobre a qué conmutador virtual debe conectarse una máquina virtual, y se simplifica el desplazamiento de una máquina virtual de un host a otro. El cmdlet de Windows PowerShell Move-VM no se ejecutará correctamente si no se encuentra el mismo nombre de conmutador virtual en el host de destino.

Tarea 3: definir la configuración de almacenamiento

Además del almacenamiento necesario para el sistema operativo host, cada host necesita acceder al almacenamiento donde se encuentran los archivos de configuración de máquinas virtuales y los discos duros virtuales. Esta tarea se centrará en el almacenamiento de máquinas virtuales.

Tarea 3a: definir los tipos de datos

Estos son los tipos de datos de ejemplo que deberá tener en cuenta para definir los requisitos de almacenamiento.

Tipo de datos	Ubicación de almacenamiento del tipo de datos
Archivos del sistema operativo host	Por lo general, en un disco duro local
Volcados de memoria y archivos de paginación de host de Windows	Por lo general, en un disco duro local
Estado compartido del clúster de conmutación por error	Volumen compartido del clúster o almacenamiento de red compartido
Archivos de disco duro virtual y archivo de configuración de máquina virtual	Normalmente, en almacenamiento compartido de red o volumen compartido de clúster

El resto de este paso se centra en el almacenamiento necesario para las máquinas virtuales.

Tarea 3b: opciones de almacenamiento

Las siguientes opciones están disponibles para almacenar los archivos de configuración de máquinas virtuales y los discos duros virtuales.

Opción 1: almacenamiento conectado directamente

El almacenamiento conectado directamente es un sistema de almacenamiento del equipo que está conectado directamente a su servidor, en lugar de asociarse directamente a una red. El almacenamiento conectado directamente no se limita a almacenamiento interno. También puede usar un contenedor de discos externos que contenga unidades de disco duro, incluidos los contenedores de tipo "Just a bunch of disks" (JBOD) y los contenedores conectados a través de SAS u otra controladora de disco.

Ventajas	Desventajas
No requiere una red de almacenamiento. E/S de disco rápido, por lo que no hay necesidad de usar solicitudes de almacenamiento para trasladarse a través de una red. Puede ser almacenamiento interno o un contenedor de discos externos, incluido JBOD. Puede usar JBOD con la tecnología de Espacios de almacenamiento para combinar todos los discos físicos en un grupo de almacenamiento y, luego, crear uno o más discos virtuales (denominados “Espacios de almacenamiento”) fuera del espacio disponible en el grupo. Los JBOD suelen ser menos costosos y, a menudo, más flexibles y fáciles de administrar que los contenedores RAID, dado que utilizan los sistemas operativos Windows o Windows Server para administrar el almacenamiento, en lugar de usar adaptadores RAID dedicados.	Limitado en el número de servidores que se pueden conectar al contenedor de discos externos Solo el almacenamiento compartido externo, como las SAS compartidas con Espacios de almacenamiento, proporciona compatibilidad con los clústeres de conmutación por error.

No requiere una red de almacenamiento.
E/S de disco rápido, por lo que no hay necesidad de usar solicitudes de almacenamiento para trasladarse a través de una red.
Puede ser almacenamiento interno o un contenedor de discos externos, incluido JBOD.
Puede usar JBOD con la tecnología de Espacios de almacenamiento para combinar todos los discos físicos en un grupo de almacenamiento y, luego, crear uno o más discos virtuales (denominados “Espacios de almacenamiento”) fuera del espacio disponible en el grupo.
Los JBOD suelen ser menos costosos y, a menudo, más flexibles y fáciles de administrar que los contenedores RAID, dado que utilizan los sistemas operativos Windows o Windows Server para administrar el almacenamiento, en lugar de usar adaptadores RAID dedicados.

Limitado en el número de servidores que se pueden conectar al contenedor de discos externos
Solo el almacenamiento compartido externo, como las SAS compartidas con Espacios de almacenamiento, proporciona compatibilidad con los clústeres de conmutación por error.

Opción 2: almacenamiento conectado a la red

Los dispositivos de almacenamiento conectado a red conectan el almacenamiento a una red, donde se accede a ellos a través de recursos compartidos de archivos. A diferencia del almacenamiento conectado directamente, no están conectados directamente al equipo.

Los dispositivos de almacenamiento conectado a la red admiten las conexiones Ethernet y, normalmente, permiten que un administrador controle el espacio en disco, establezca cuotas de disco, proporcione seguridad y utilice tecnologías de puntos de control. Los dispositivos de almacenamiento conectado a la red admiten varios protocolos, entre ellos, sistemas de archivos conectados a la red, Sistemas de archivos de Internet común (CIFS) y Bloque de mensajes del servidor (SMB).

Ventajas	Desventajas
Más fácil de configurar que el almacenamiento SAN, ya que requiere menos hardware de almacenamiento dedicado Plug and Play Puede utilizar la red Ethernet existente.	El dispositivo de almacenamiento conectado a la red debe admitir SMB 3.0: no se admite CIFS. No está conectado directamente a los servidores host que acceden al almacenamiento. Más lento que otras opciones Suele necesitar una red dedicada para un rendimiento óptimo. Funcionalidad y administración limitadas Hyper-V admite los dispositivos de almacenamiento conectado a la red que admiten SMB 3.0. SMB 2.0 y CIFS no se admiten. Pueden no admitir RDMA.

Más fácil de configurar que el almacenamiento SAN, ya que requiere menos hardware de almacenamiento dedicado
Plug and Play
Puede utilizar la red Ethernet existente.

El dispositivo de almacenamiento conectado a la red debe admitir SMB 3.0: no se admite CIFS.
No está conectado directamente a los servidores host que acceden al almacenamiento.
Más lento que otras opciones
Suele necesitar una red dedicada para un rendimiento óptimo.
Funcionalidad y administración limitadas
Hyper-V admite los dispositivos de almacenamiento conectado a la red que admiten SMB 3.0. SMB 2.0 y CIFS no se admiten.
Pueden no admitir RDMA.

Opción 3: red de área de almacenamiento

Una red de área de almacenamiento (SAN) es una red dedicada que le permite compartir el almacenamiento. Una SAN está formada por un dispositivo de almacenamiento, una infraestructura de red de interconexión (conmutadores, adaptadores de bus host y cableado) y los servidores que están conectados a esta red. Los dispositivos SAN proporcionan un acceso rápido y continuo a grandes cantidades de datos. El mecanismo de transferencia de datos y comunicación de una implementación determinada se suele denominar “tejido de almacenamiento“.

Una SAN utiliza una red independiente y, por lo general, los demás dispositivos no pueden acceder a ella a través de la red de área local. Una SAN puede administrarse con Storage Management Initiative Specification (SMI-S), Protocolo simple de administración de redes (SNMP) o un protocolo de administración de propietario.

Una red SAN no proporciona abstracción de archivos, solo operaciones en el nivel de bloque. Los protocolos más comunes de SAN son iSCSI, Canal de fibra y Canal de fibra sobre Ethernet (FCoE). SMI-S o un protocolo de administración de propietario pueden ofrecer funcionalidades adicionales, como división en zonas de discos, asignación de discos, enmascaramiento de LUN y administración de errores.

Ventajas	Desventajas
SAN utiliza una red independiente, por lo que tiene un impacto limitado sobre la red de datos. Proporciona acceso continuo y rápido a grandes cantidades de datos. Normalmente, proporciona características adicionales, como la replicación y la protección de datos. Se puede compartir entre varios equipos. Compatibilidad con Canal de fibra virtual para el acceso directo a LUN de almacenamiento Compatibilidad con clústeres invitados Las máquinas virtuales que necesitan acceder a volúmenes de datos de más de 64 TB pueden utilizar el Canal de fibra virtual para el acceso directo de LUN.	Costoso Requiere habilidades especializadas para la implementación, la administración y el mantenimiento. Tiene que haber HBA o adaptadores de red FCoE instalados en cada host. La migración de un clúster de Hyper-V requiere una planeación adicional y un tiempo de inactividad limitado. Para proporcionar administración de ancho de banda para el tráfico de FCoE, es necesaria una directiva de QoS de hardware que utilice el protocolo de puente de centros de datos. El tráfico FCoE no es enrutable.

SAN utiliza una red independiente, por lo que tiene un impacto limitado sobre la red de datos.
Proporciona acceso continuo y rápido a grandes cantidades de datos.
Normalmente, proporciona características adicionales, como la replicación y la protección de datos.
Se puede compartir entre varios equipos.
Compatibilidad con Canal de fibra virtual para el acceso directo a LUN de almacenamiento
Compatibilidad con clústeres invitados
Las máquinas virtuales que necesitan acceder a volúmenes de datos de más de 64 TB pueden utilizar el Canal de fibra virtual para el acceso directo de LUN.

Costoso
Requiere habilidades especializadas para la implementación, la administración y el mantenimiento.
Tiene que haber HBA o adaptadores de red FCoE instalados en cada host.
La migración de un clúster de Hyper-V requiere una planeación adicional y un tiempo de inactividad limitado.
Para proporcionar administración de ancho de banda para el tráfico de FCoE, es necesaria una directiva de QoS de hardware que utilice el protocolo de puente de centros de datos.
El tráfico FCoE no es enrutable.

Opción 4: recursos compartidos de archivos de Bloque de mensajes del servidor 3.0

Hyper-V puede almacenar archivos de máquina virtual, como archivos de configuración, archivos de disco duro virtual y puntos de control, en recursos compartidos de archivos que utilicen el protocolo Bloque de mensajes del servidor (SMB) 3.0. Los recursos compartidos de archivos suelen estar en un Servidor de archivos de escalabilidad horizontal para proporcionar redundancia. Al ejecutar un Servidor de archivos de escalabilidad horizontal, si un nodo está inactivo, los recursos compartidos de archivos siguen estando disponibles en otros nodos del Servidor de archivos de escalabilidad horizontal.

Ventajas	Desventajas
Opción de usar protocolos y redes existentes SMB multicanal proporciona agregación del ancho de banda de red y tolerancia a errores cuando existen varias rutas de acceso disponibles entre el servidor que ejecuta Hyper-V y el recurso compartido de archivos SMB 3.0. Puede usar JBOD con la tecnología de Espacios de almacenamiento para combinar todos los discos físicos en un grupo de almacenamiento y, luego, crear uno o más discos virtuales (denominados “Espacios de almacenamiento”) fuera del espacio disponible en el grupo. SMB multicanal puede utilizarse para las migraciones de máquinas virtuales. Menos costoso que las implementaciones de SAN Configuraciones de almacenamiento flexibles en el servidor de archivos que ejecuta Windows Server Separe los servicios Hyper-V de los servicios de almacenamiento, para poder escalar cada servicio según sea necesario. Proporciona flexibilidad al actualizarse a la versión siguiente cuando se ejecuta un clúster de Hyper-V. Puede actualizar los servidores que ejecutan Hyper-V o los servidores de archivos de escalabilidad horizontal en cualquier orden sin tiempo de inactividad. Necesita suficiente capacidad en el clúster para quitar uno o dos nodos y realizar la actualización. El Servidor de archivos de escalabilidad horizontal proporciona compatibilidad con VHDX compartido. La administración de ancho de banda SMB permite establecer límites para la migración en vivo, el disco duro virtual y el tráfico de almacenamiento predeterminado. Compatibilidad con el cifrado de tráfico SMB con un impacto mínimo en el rendimiento Ahorre espacio en disco con la desduplicación de datos en las implementaciones de VDI. No requiere habilidades especializadas para la implementación, la administración y el mantenimiento.	El rendimiento de E/S no es tan rápido como en las implementaciones de SAN. No admite la desduplicación de datos en los archivos de máquina virtual en ejecución, excepto en las implementaciones de VDI.

Opción de usar protocolos y redes existentes
SMB multicanal proporciona agregación del ancho de banda de red y tolerancia a errores cuando existen varias rutas de acceso disponibles entre el servidor que ejecuta Hyper-V y el recurso compartido de archivos SMB 3.0.
Puede usar JBOD con la tecnología de Espacios de almacenamiento para combinar todos los discos físicos en un grupo de almacenamiento y, luego, crear uno o más discos virtuales (denominados “Espacios de almacenamiento”) fuera del espacio disponible en el grupo.
SMB multicanal puede utilizarse para las migraciones de máquinas virtuales.
Menos costoso que las implementaciones de SAN
Configuraciones de almacenamiento flexibles en el servidor de archivos que ejecuta Windows Server
Separe los servicios Hyper-V de los servicios de almacenamiento, para poder escalar cada servicio según sea necesario.
Proporciona flexibilidad al actualizarse a la versión siguiente cuando se ejecuta un clúster de Hyper-V. Puede actualizar los servidores que ejecutan Hyper-V o los servidores de archivos de escalabilidad horizontal en cualquier orden sin tiempo de inactividad. Necesita suficiente capacidad en el clúster para quitar uno o dos nodos y realizar la actualización.
El Servidor de archivos de escalabilidad horizontal proporciona compatibilidad con VHDX compartido.
La administración de ancho de banda SMB permite establecer límites para la migración en vivo, el disco duro virtual y el tráfico de almacenamiento predeterminado.
Compatibilidad con el cifrado de tráfico SMB con un impacto mínimo en el rendimiento
Ahorre espacio en disco con la desduplicación de datos en las implementaciones de VDI.
No requiere habilidades especializadas para la implementación, la administración y el mantenimiento.

El rendimiento de E/S no es tan rápido como en las implementaciones de SAN.
No admite la desduplicación de datos en los archivos de máquina virtual en ejecución, excepto en las implementaciones de VDI.

SMB directo

SMB directo funciona como parte de los recursos compartidos de archivos SMB. SMB directo requiere adaptadores de red y conmutadores que admitan RDMA para proporcionar acceso de almacenamiento de latencia baja y velocidad máxima. SMB directo permite que los servidores de archivos remotos funcionen de una manera similar a la del almacenamiento local conectado directamente. Además de las ventajas de SMB, SMB directo tiene las siguientes ventajas y desventajas.

Ventajas	Desventajas
Funciones a velocidad máxima con latencia baja y, al mismo tiempo, uso de muy poca CPU. Permite que un Servidor de archivos de escalabilidad horizontal proporcione un rendimiento de almacenamiento y una resistencia similares a los de una SAN tradicional con soluciones de almacenamiento de Microsoft y almacenamiento compartido conectado directamente, de bajo coste. Es la opción más rápida para las migraciones en vivo y las migraciones de almacenamiento.	No es compatible con la Formación de equipos NIC. Son necesarios dos o más adaptadores de red habilitados para RDMA para las conexiones redundantes con el almacenamiento.

Funciones a velocidad máxima con latencia baja y, al mismo tiempo, uso de muy poca CPU.
Permite que un Servidor de archivos de escalabilidad horizontal proporcione un rendimiento de almacenamiento y una resistencia similares a los de una SAN tradicional con soluciones de almacenamiento de Microsoft y almacenamiento compartido conectado directamente, de bajo coste.
Es la opción más rápida para las migraciones en vivo y las migraciones de almacenamiento.

No es compatible con la Formación de equipos NIC.
Son necesarios dos o más adaptadores de red habilitados para RDMA para las conexiones redundantes con el almacenamiento.

Servidor de archivos de escalabilidad horizontal

Figure 3:Servidor de archivos de escalabilidad horizontal de ejemplo que usa redes convergentes con RDMA

Información adicional:

Proporcionar un almacenamiento rentable para las cargas de trabajo de Hyper-V mediante el uso de Windows Server

Centro de datos convergente con almacenamiento del servidor de archivos

Implementación de Hyper-V en SMB

Lograr más de un millón de IOPS de máquinas virtuales de Hyper-V en un clúster de Servidores de archivos de escalabilidad horizontal con Windows Server 2012 R2

Tarea 3c: definir los tipos de arquitectura de la unidad física

El tipo de arquitectura de la unidad física que seleccione para el almacenamiento afectará al rendimiento de la solución de almacenamiento. Para más información sobre los tipos de discos, consulte el apartado 7.1 del tema sobre arquitectura de la línea de productos de infraestructura como servicio.

Tareas 3d: definir el tipo de redes de almacenamiento

Los tipos de controladora de almacenamiento o controladora de redes de almacenamiento que debe usar dependen de la opción de almacenamiento que seleccione para cada grupo host. Para más información, consulte el Tarea 3b: opciones de almacenamiento.

Tarea 3e: determinar qué tipo de almacenamiento se utilizará para cada tipo de datos

Con una comprensión de los tipos de datos, ahora puede determinar qué opción de almacenamiento, controladora de almacenamiento, controladora de redes de almacenamiento y arquitecturas de disco físico se adaptan mejor a sus requisitos.

Decisión de diseño: puede escribir las decisiones que tome en esta tarea en la hoja de cálculo de hosts de virtualización.

Información adicional:

Configuraciones de redes de Hyper-V sobre SMB en Windows Server 2012 y Windows Server 2012 R2

Póster de arquitectura de componentes de Hyper-V de Windows Server 2012 y referencias complementarias

Información general sobre tecnologías de almacenamiento

Tarea 4: definir las unidades de escalado de host de virtualización de servidores

Comprar servidores individuales requiere la adquisición, la instalación y la configuración de cada servidor. Las unidades de escalado le permiten comprar colecciones de servidores (que suelen contener hardware idéntico). Están preconfiguradas, lo que le permite agregar capacidad al centro de datos agregando unidades de escalado, en lugar de tener que agregar los servidores uno por uno.

La siguiente imagen ilustra una unidad de escalado que podría adquirirse preconfigurada a diversos proveedores de hardware. Incluye un bastidor, una fuente de alimentación ininterrumpida (SAI o UPS), un par de conmutadores de red redundantes para los servidores incluidos en el bastidor y diez servidores.

Host scale unit

Figure 4:Ejemplo de unidad de escalado de host de servidor de virtualización

La unidad de escalado viene preconfigurada y ya conectada por cable a los conmutadores de red y SAI. La unidad solo tiene que agregarse a un centro de datos, conectarse a la corriente eléctrica y conectarse a la red y al almacenamiento. Con eso, ya está lista para usarse. Si no se adquirieran los componentes individuales como una unidad de escalado, el comprador tendría que colocar en un bastidor todos los componentes y conectarlos.

Decisión de diseño: si decide utilizar unidades de escalado de host de virtualización de servidores, puede definir el hardware de las unidades de escalado de host de virtualización en la hoja de cálculo de unidades de escalado de host.

Sugerencia: Puede adquirir unidades de escalado preconfiguradas a diversos socios de hardware de Microsoft con el programa Microsoft Private Cloud Fast Track.

Tarea 5: definir la estrategia de disponibilidad de host de virtualización de servidores

Los hosts de servidor de virtualización pueden dejar de estar disponibles por motivos planeados (por ejemplo, por mantenimiento) o no planeados. Estas son algunas de las estrategias que pueden usarse para ambos casos.

Planeado

Puede usar la migración en vivo para mover las máquinas virtuales de un host a otro. No requiere ningún tiempo de inactividad de las máquinas virtuales.

No planeado

Este escenario depende de los tipos de caracterización de cargas de trabajo que hospede el host.

Para las cargas de trabajo con estado compartidas, utilice la agrupación en clústeres de conmutación por error dentro de las máquinas virtuales.
Para las cargas de trabajo con estado, ejecútela como una máquina virtual de alta disponibilidad en un clúster de Hyper-V.
Para las cargas de trabajo sin estado, inicie nuevas instancias manualmente o con algunos medios automatizados.

Si utiliza clústeres de conmutación por error en Windows Server con Hyper-V, piense si va a usar las características que se indican en la tabla siguiente. Para más información sobre cada característica, haga clic en el hipervínculo.

Funcionalidad	Consideraciones
Supervisión de aplicaciones de Hyper-V	Supervise una máquina virtual para controlar si hay errores en las redes y el almacenamiento que no estén supervisados por el servicio de clústeres de conmutación por error.
Configuración de prioridad de máquinas virtuales	Establezca la prioridad de la máquina virtual, según la carga de trabajo. Puede asignar los siguientes valores de prioridad a las máquinas virtuales de alta disponibilidad (también llamadas “máquinas virtuales en clúster”): Alta Media (predeterminada) Baja No iniciar automáticamente Los roles en clúster con mayor prioridad se inician y se colocan en los nodos antes de los que tienen una prioridad inferior. Si se asigna la prioridad No iniciar automáticamente, el rol no se conectará automáticamente después de que se produzca un error, lo que mantiene los recursos disponibles para que puedan iniciarse otros roles.
Antiafinidad de máquinas virtuales	Establezca la antiafinidad de las máquinas virtuales que no quiera que se ejecuten en el mismo nodo de un clúster de Hyper-V. Puede hacerlo en las máquinas virtuales que proporcionan servicios redundantes o forman parte del clúster de máquinas virtuales invitadas. Nota: La configuración de antiafinidad se establece con Windows PowerShell.
Purga de nodos automatizada	El clúster purga automáticamente un nodo (mueve los roles en clúster que se ejecutan en el nodo a otro nodo) antes de poner el nodo en modo de mantenimiento o realizar otros cambios en el nodo. Los roles conmutan por recuperación al nodo original después de las operaciones de mantenimiento. Los administradores pueden purgar un nodo con una sola acción en el Administrador de clústeres de conmutación por error o con el cmdlet de Windows PowerShell Suspend-ClusterNode. Se puede especificar el nodo de destino de los roles en clúster movidos. La Actualización compatible con clústeres usa la purga de nodos en el proceso automatizado para aplicar actualizaciones de software a los nodos del clúster.
Actualización compatible con clústeres	La Actualización compatible con clústeres le permite actualizar los nodos de un clúster sin afectar a las máquinas virtuales que se ejecutan en el clúster. Un número suficiente de los nodos del clúster debe permanecer disponible durante el proceso de actualización para controlar la carga de las máquinas virtuales en ejecución.
Adelantamiento de máquinas virtuales en función de su prioridad	Otra razón para establecer la prioridad de la máquina virtual es que el Servicio de clúster puede desconectar una máquina virtual de prioridad inferior cuando una máquina virtual de alta prioridad no tiene suficiente memoria y otros recursos para iniciarse. El adelantamiento comienza por la máquina virtual de prioridad más baja y continúa con las máquinas virtuales de mayor prioridad. Las máquinas virtuales que se adelantan se reinician más adelante por orden de prioridad.

Nota: Los clústeres de Hyper-V pueden tener un máximo de 64 nodos y 8000 máquinas virtuales.

Paso 5: planear los conceptos de arquitectura del tejido de virtualización

Este paso requiere la definición de los conceptos lógicos a los que se ajustará la arquitectura del tejido.

Tarea 1: definir los dominios de mantenimiento

Los dominios de mantenimiento son colecciones lógicas de servidores que se atienden conjuntamente. El mantenimiento puede incluir actualizaciones de hardware o software o cambios de configuración. Los dominios de mantenimiento suelen abarcar grupos host de cada tipo o dentro de cada ubicación, aunque no tienen por qué. El objetivo es evitar que el mantenimiento de los servidores perjudique a las cargas de trabajo de los consumidores.

Nota: Este concepto se aplica a los componentes de red y de almacenamiento físicos.

Tarea 2: definir los dominios de error físicos

A menudo, los errores de los grupos host de los servidores de virtualización aparecen juntos, debido a un error en un componente de la infraestructura compartida, como un conmutador de red o una fuente de alimentación ininterrumpida (SAI). Los dominios de error físicos ofrecen resistencia dentro del tejido de virtualización. Es importante entender cómo un dominio de error afecta a cada uno de los grupos host que definió para el tejido.

Nota: Este concepto se aplica a los componentes de red y de almacenamiento físicos.

Tenga en cuenta el ejemplo de la imagen siguiente, donde se superponen los dominios de error físicos y de mantenimiento en una colección de grupos host de un centro de datos.

Fault domain

Figure 5:Ejemplo de definición de dominio de error físico y de mantenimiento

En este ejemplo, cada bastidor de servidores se define como un dominio de error físico independiente y numerado. Se debe a que cada bastidor contiene un conmutador de red en la parte superior y un SAI en la parte inferior. Todos los servidores del rack dependen de estos dos componentes, y si se produce un error en uno, se producirá un error en todos los servidores del bastidor.

Dado que todos los servidores de un bastidor son también miembros de grupos host únicos, con este diseño, no hay ninguna reducción en caso de que se produzca un error en alguno de los dominios de error físicos. Para mitigar los problemas, puede agregar dominios de error físicos de cada tipo de grupo host. En los entornos de escala más pequeña, podría agregar fuentes de alimentación y conmutadores redundantes en cada bastidor, o usar clústeres de conmutación por error para los hosts de servidores de virtualización en los dominios de error físicos.

En la ilustración 5, cada uno de los cuadros de colores de línea discontinua define un dominio de mantenimiento (tienen la etiqueta MD del 1 al 5). Observe cómo cada uno de los servidores del clúster de equilibrio de carga de máquinas virtuales se hospeda en un host de virtualización de servidor que está dentro de un dominio de mantenimiento independiente y un dominio de error físico independiente.

Esto permite al administrador del tejido dar de baja todos los hosts de servidor de virtualización dentro de un dominio de mantenimiento sin afectar significativamente a las aplicaciones que tienen varios servidores repartidos entre diferentes dominios de mantenimiento. También implica que la aplicación que se ejecuta en el clúster de carga equilibrada no pierde completamente su disponibilidad si se produce un error en un dominio de error físico.

Decisión de diseño: puede escribir las decisiones que tome en las tareas 1 y 2 en la hoja de cálculo de configuración.

Tarea 3: definir la capacidad reservada

Es inevitable que se produzca algún error en cada uno de los servidores del tejido. El diseño del tejido tiene que dar cabida a los errores de todos los servidores, tal y como se adapta a los errores de las colecciones de servidores en los dominios de error y mantenimiento. La siguiente ilustración es igual que la ilustración 5, pero identifica los tres servidores con errores en color rojo.

Servidores con errores

Figure 6:Servidores con errores

En la ilustración 6, los errores de los hosts de virtualización de servidores se produjeron en los siguientes grupos host, dominios de mantenimiento y dominios de error físicos.

Grupo host	Dominio de error físico	Dominio de mantenimiento
2	2	3
3	3	2
4	4	2

La aplicación que se ejecuta en el clúster de equilibrio de carga sigue estando disponible, aunque fallara el host del dominio de error físico 2, pero funciona con un tercio menos de capacidad.

Tenga en cuenta lo que sucedería si se produjera otro error en el host de virtualización de servidores que hospedaba una de las máquinas virtuales del dominio de error físico 3, o si el dominio de mantenimiento 2 se diera de baja por mantenimiento. En estos casos, la capacidad de la aplicación podría disminuir dos tercios.

Puede que esto no sea aceptable para su tejido de virtualización. Para mitigar el impacto de los servidores con errores, puede asegurarse de que cada uno de sus dominios de mantenimiento y dominios de error físicos tengan suficiente capacidad reservada para que la capacidad no descienda nunca por debajo del nivel aceptable que defina.

Para más información sobre cómo calcular la capacidad reservada, consulte el apartado sobre capacidad reservada en el tema sobre arquitectura de referencia de Cloud Services Foundation: principios, conceptos y patrones.

Paso 6: planear las características de capacidad inicial

Después de completar todas las tareas de este documento, podrá determinar los costes iniciales de hospedar las máquinas virtuales y el almacenamiento en el tejido, además de los niveles de calidad de servicio iniciales que puede lograr el tejido. Sin embargo, no podrá finalizar ninguna de estas tareas hasta que implemente los recursos humanos y las herramientas de administración del tejido, que se describen en el apartado Pasos siguientes de este documento.

Tarea 1: definir las métricas iniciales del contrato de nivel de servicio correspondientes al almacenamiento y las máquinas virtuales

Como administrador del tejido, probablemente definirá un contrato de nivel de servicio (SLA) que detalle las métricas de calidad de servicio que cumplirá el tejido. Los administradores de las máquinas virtuales deberán tenerlo en cuenta para planear cómo usarán el tejido.

Es probable que incluya, al menos, una métrica de disponibilidad, pero también puede incluir otras métricas. Para hacerse una idea de las posibles métricas del contrato de nivel de servicio de un tejido de virtualización, puede revisar las proporcionadas por los proveedores de nube pública, como Microsoft Azure. Para hospedar máquinas virtuales, el contrato de nivel de servicio garantiza que, cuando un cliente implementa dos o más instancias de una máquina virtual que ejecutan la misma carga de trabajo e implementa esas instancias en diferentes dominios de error y actualización (denominados “dominios de mantenimiento” en este documento), al menos una de esas máquinas virtuales estará disponible el 99,95 % del tiempo.

Para ver una descripción completa del contrato de nivel de servicio de Azure, consulte Contratos de nivel de servicio. En condiciones óptimas, su tejido de virtualización cumplirá o superará los de los proveedores de nube pública.

Tarea 2: definir los costes iniciales del almacenamiento del host y las máquinas virtuales

Con el tejido diseñado, también podrá calcular:

Los costes de hardware, espacio, alimentación y refrigeración del tejido
La capacidad de hospedaje del tejido

Esta información, junto con los demás costes, como el coste de los recursos humanos y las herramientas de administración del tejido, le permitirá determinar los costes finales de hospedar el almacenamiento y las máquinas virtuales.

Para hacerse una idea de los costes previstos de las máquinas virtuales y el almacenamiento, puede revisar los costes de hospedaje de los proveedores de nube pública, como Microsoft Azure. Para más información, consulte los detalles de los precios de máquinas virtuales.

Aunque no siempre es el caso, por lo general, verá que los costes de hospedaje son mayores que los de los proveedores públicos, porque su tejido será mucho menor que los tejidos de los proveedores públicos de gran tamaño, que pueden obtener descuentos por volumen en el hardware, el espacio del centro de datos y la alimentación.

Pasos siguientes

Después de completar todas las tareas de este documento, tendrá un diseño de tejido que cumpla los requisitos de su organización. También tendrá una definición de características de servicio iniciales que incluya los costes y las métricas de nivel de servicio. No podrá determinar los costes y las métricas de nivel de servicio finales hasta que pueda determinar los costes de recursos humanos y los procesos y las herramientas de administración que utilizará para el tejido.

Microsoft System Center 2012 ofrece un conjunto completo de funcionalidad que le permite aprovisionar, supervisar y mantener el tejido de virtualización. Para más información sobre cómo usar System Center para la administración del tejido, consulte los siguientes recursos:

Biblioteca de documentación técnica de System Center

Guía de arquitectura de administración de tejidos