1-Tema 1 - Buenas prácticas con VMware

Orense, 20
28020 Madrid
D`Aribau, 200
08036 Barcelona
www.formadoresfreelance.es
Tema 1: BUENAS PRÁCTICAS CON VMWARE VSPHERE
Parte 1 - Introducción a Vmware Sphere
Parte 2 - Gestión de Maquinas Virtuales
Parte 3 - Redes
Parte 4 - Almacenamiento
Parte 5 - Gestión de recursos
© Formadores IT, Todos los derechos reservados. Prohibida su reproducción total o parcial.
VMware vSphere en un componente esencial dentro de la solución de virtualitzación para Datacenters de Vmware.
La función básica de un entorno de virtualización es la de particionar una máquina física en varias máquinas virtuales con
las mismas funcionalidades que la física pero con menos recursos asignados. Conforme la capacidad de proceso de los
equipos va creciendo y las necesidades de las compañías se mantienen constantes, tenemos más oportunidad de sacar
provecho económico a un entorno de virtualización
Por ejemplo es bastante más económico adquirir una máquina con 16GB de memoria que 16 máquinas de 1GB y en el caso
de procesadores, es común tener los procesadores a un uso medio del 5% o 10%, con lo que tenemos oportunidad de sacar
más provecho a la inversión realizada si podemos compartir este procesador entre varias máquinas virtuales y conseguir
utilizaciones del 70% o 80%
En cualquier entorno de consolidación se tiene que tener la vista puesta sobre los contadores que indican el uso para evitar
una sobreasignación de recursos y afectar a la calidad de servicio de las máquinas virtuales, ya que ningún recurso podrá
llegar a más del 100% de utilización
Orígenes
Dentro del mundo basado en Intel x86, los comúnmente llamados PC, la virtualización es un fenómeno relativamente
moderno, se popularizó con la llegada al mercado en 1999 de Vmware Workstation, muy orientado a desarrolladores y
administradores de sistemas. Así podían tener en el mismo equipo varios entornos, por ejemplo el entorno corporativo de
trabajo y un entorno virtual para las pruebas emulando los entornos donde el software desarrollado se iba a desplegar, y en
el caso de administradores de sistemas en entornos con mucho peso en Unix/Linux, utilizar por defecto el entorno Linux y
levantar la máquina virtual con Windows cuando requerían hacer algo con las herramientas corporativas.
Casi al momento, se empezó a utilizar para hacer demostraciones de productos o simular entornos complejos con varios
equipos en un solo equipo, algo parecido a lo que haremos en la práctica.
Al cabo de poco tiempo, sacaron al mercado Vmware GSX, que ya era un entorno para tener máquinas virtuales en un
servidor, este servidor podía ser Windows o Linux y en el fondo GSX era el producto anterior con herramientas para
gestionar el arranque y parada de máquinas virtuales de forma desatendida. También en el mismo entorno de tiempo,
lanzaron Vmware ESX, que no requería de un sistema operativo con lo que dedicábamos toda la potencia de la máquina a
las tareas de virtualización.
Sobre el año 2003 se empieza a hablar de entornos paravirtualizados, con Xen a la cabeza. La diferencia entre el entorno
virtualizado y paravirtualizado, es que un entorno virtualizado emula a la perfección una máquina física y por tanto
cualquier software que pueda ser ejecutado en ese hardware debería poder ejecutarse en la máquina virtual. En el caso de la
paravirtualización, lo que hacemos es “iluminar” el sistema operativo alojado de forma que sus controladores de dispositivos
y la forma de acceder al hardware tienen en cuenta que es un entorno diferente.
Los primeros entornos paravirtualizados daban mejor rendimiento que los virtualizados ya que estos últimos debían de
interceptar llamadas directas al hardware y emular el comportamiento del dispositivo en cuestión. Con la salida al mercado
de procesadores con soporte a la virtualización y la maduración de los varios sistemas operativos que ya incluyen ciertas
“iluminaciones” por defecto, ya no existe una diferencia tan importante entre rendimiento y compatibilidad sino que en
lugar de tener un entorno de blanco y negro, estamos en un momento más de grises. Vmware soporta paravirtualización en
algunos dispositivos y Xen virtualización con ayuda del hardware. Por tanto las diferencias se han difuminado mucho más y
ahora se valoran otros aspectos como funcionalidades avanzadas de gestión de recursos, compatibilidad, escalabilidad, etc…
Aunque es reciente para la mayoría de nosotros, los fundamentos de la virtualización y del soporte por hardware de la
misma se remontan a los años 1960 donde IBM ya disponía de procesadores que soportaban la virtualización y en el fondo
lo que se acababa ejecutando en esas máquinas era un hipervisor que monitorizaba la máquina virtual, de esta forma
particionaban el equipo y facilitaban las emulaciones de otros sistemas operativos
vSphere
vSphere es la última versión del hipervisor de Vmware con los paquetes de gestión relacionados. El hipervisor a día de hoy,
inicios de 2012, sigue llamándose ESX y vamos por la versión 5.0
Dentro del producto vSphere tenemos todo el conjunto de hipervisores y herramientas para otorgar alta disponibilidad a
nuestra infraestructura. Por ejemplo tenemos:
El hipervisor es el componente más importante de toda una infraestructura basada en la virtualización, ya
que es el componente que monitoriza las diversas máquinas virtuales que se ejecutan en un nodo
determinado. Aquí monitoritzación se entiende como interceptación del uso de los recursos y autorización
de acceso a los mismos, con lo que en el fondo estamos particionando un nodo para que pueda ejecutar
varios entornos operativos (Linux, Windows, etc...)
ESXi: El hipervisor de Vmware. En el siguiente enlace podrás entrar más en detalle de lo que es y
hace un hipervisor y como consigue controlar a varias máquinas virtuales corriendo en la misma
máquina física es.wikipedia.org/wiki/Hipervisor. A partir de la versión 5.0 de vSphere, solo tenemos
disponible ESXi y no ESX. Este último, además del hipervisor incluia la llamada Service Console
que era un Red Hat con privilegios en el hipervisor para realizar la gestión del mismo. Al no tener la
Service Console, reducimos los recursos necesarios para el funcionamiento, menos disco, menos
memoria y evitamos tener que actualizar el entorno vSphere por fallos de seguridad de Red Hat.
Aquí podemos ver como se comparan ESXi con ESX a nivel de arquitectura
DRS (Distributed Resource Scheduler): El gestor de recursos distribuido de Vmware que permite
balancear las máquinas virtuales entre los nodos de nuestro clúster. En el siguiente vídeo realizado
por Dell, se puede observar como actúa DRS en un entorno de tres nodos y como consigue
balancear de nuevo el clúster. En el vídeo vemos como se genera carga en tres máquinas virtuales
que está en un clúster de tres nodos pero se eligen dos máquinas albergadas en el mismo nodo lo
que provoca que el clúster se desbalancee, mediante DRS, al cabo de un rato ya que se recalcula
cada 5 minutos por defecto, se mueve una de las dos máquinas virtuales que están en el nodo más
cargado al que no tiene nada de carga. Con esto se demuestra que aunque las cargas que hay en
nuestras máquinas virtuales varien de un rato a otro, él solo se encarga de mover las máquinas a los
nodos más descargados
DPM (Distributed Power Management): Permite que si no hacen falta algunos nodos, estos se
puedan parar para reducir el consumo eléctrico
Gestión de memoria: ESXi permite asignar a las máquinas virtuales más memoria de la existente en
el nodo físico, esto se conoce como sobreasignación y un exceso puede provocar problemas graves
de rendimiento
VMFS: Es el sistema propio de ficheros de ESX, como Windows puede usar por defecto FAT o
NTFS o los ext3 o ext4 de Linux. La diferencia principal es que éste está optimizado para albergar a
máquinas virtuales y accesos desde varios servidores simultáneamente.
Thin Provisioning: Permite mostrar a nuestra máquina virtual más almacenamiento que el de
verdad asignado, de esta forma nos caben más máquinas virtuales de las que cabrían si tuviésemos
en cuenta la suma de capacidades asignadas. Un abuso de Thin Provisioning nos implicará estar
muy encima de la ocupación real de almacenamiento ya que si en algún momento excedemos la
capacidad las máquinas virtuales generaran errores de disco, seguramente corrompiendo los datos
Storage I/O Control: Ya que el almacenamiento es un recurso compartido entre todas las máquinas
virtuales, debemos evitar que una sola acapare gran parte de los recursos afectando al resto. Esta
funcionalidad evita un consumo excesivo de peticiones de lectura/escritura en un conjunto de
máquinas virtuales pueda afectar al rendimiento de todas, priorizando las máquinas con más peso en
caso de detectar problemas.
Network I/O Control: Al igual que el almacenamiento, la red también es un recurso finito y
debemos poder asegurar que las máquinas virtuales más críticas tendrán disponibilidad de suficiente
ancho de banda en la red
Distributed Switch: La funcionalidad de switch distribuido permite que se simule un switch que
abarca a todo el clúster en lugar de varios switches en cada nodo. De esta forma se pueden aplicar
políticas y seguridad a nivel global y tolerar correctamente las migraciones de nodo de las máquinas
virtuales
Luego tenemos los servicios para las aplicaciones que se sustentan en la base de funcionalidades descritas
con anterioridad y son:
vMotion: Es la funcionalidad que permite a una máquina virtual cualquiera migrar a otro nodo del
clúster. Esto permite realizar tareas de mantenimiento sin parada de servicio y rebalancear el clúster
cuando tenemos nodos descargados y otros con más carga. En el siguiente vídeo se puede observar
como vMotion es completamente transparente para el usuario
Storage vMotion: Funcionalidad pareja a la de vMotion, pero permite que una máquina virtual
migre de almacenamiento, ya sea para rebalancear capacidad, carga o actualización de la cabina de
almacenamiento
High Availability: Funcionalidad que monitoriza que las máquinas virtuales que deben estar
funcionando estén funcionando. En caso de caída de algún nodo físico, rearrancará las máquinas
virtuales afectadas a los nodos restantes
Fault Tolerance: A diferencia de la anterior, por cada máquina en FT activa, tenemos dos
instancias corriendo en nodos diferentes que van ejecutando las mismas instrucciones, así en caso
de problema con un nodo, no hay afectación en el servicio ofrecido por la máquina virtual. Como
una imagen vale más que mil palabras, a partir del minuto 4 del siguiente vídeo se puede observar
como las dos máquinas van a la par
Data Recovery: Es una máquina virtual que ofrece VMware incluida con las licencias más
avanzadas que permite realizar las copias de seguridad sin instalar ningún sistema alternativo
vShield Zones: La gama de productos de seguridad de VMware se llama vShield y Zones es su
producto de entrada de gama, incluido desde las versiones Advanced hacia adelante. Permite
segmentar la red interna de los nodos de forma que se pueda controlar el trafico entre máquinas
virtuales y aplicar seguridad
VMsafe: Son las interfaces de seguridad de VMware que permiten a otros desarrolladores crear
aplicaciones que se integren con sus soluciones, un ejemplo de aplicaciones que las aprovechan son
los antivirus que a través de VMsafe pueden proteger a varias máquinas virtuales sin tener que
instalar nada dentro de ellas
DRS: Este es el componente que se ejecuta a nivel de clúster que permite que el componente DRS a
bajo nivel pueda realizar su tarea correctamente. Evalúa los consumos históricos de las máquinas en
cada nodo y elige las migraciones adecuadas para tener al máximo de balanceado nuestro clúster
Hot-Add: En los sistemas operativos que lo soportan permiten añadir nuevos recursos permite
añadir nuevos recursos de memoria y procesador mientras la máquina virtual está activa. Añadir
nuevas tarjetas de red o discos la mayoría de sistemas lo soportan y no está descrito como
funcionalidad por lo común de su us. En el siguiente enlace se puede descargar una guía de
compatibilidad de sistemas operativos con el servicio Hot-add. (http://partnerweb.vmware.com
/comp_guide/pdf/VMware_OS_Compatibility_Guide.pdf)
Como se puede observar un entorno virtual nos ofrece muchas más ventajas que el entorno físico tradicional,
por este y otros motivos, en bastantes casos conviene virtualizar servidores aunque solo podamos consolidar
muy pocos por nodo
Además de las funcionalidades propias del entorno virtual, VMware ofrece una serie de productos que ayudan
a sacar más provecho a la infraestructura, siendo estos:
vCenter: Esta es la herramienta básica en cualquier despliegue de vSphere, ya que provee de las
funcionalidades para gestionar los nodos del clúster, recopilar alertas, controlar las actualizaciones y en el
fondo la gestión de todo lo relacionado con la infraestructura virtual, hablaremos más extensamente de él
en un momento
vCloud Director: Es el paquete que propone VMware para crear nubes privadas y en el fondo ofertar tu
nube a posibles clientes externos. Dispone de un portal de auto aprovisionamiento, control de consumos,
etc…Tiene características de Director ya que puede controlar varios clústeres de varios nodos vSphere.
Un clúster vSphere puede tener como mucho 32 nodos y un vCenter unos 1000 nodos, así que para
infraestructuras más grandes necesitamos de varios vCenter. En el siguiente vídeo puedes ver qué tipo de
interfaz obtiene el usuario
VMware View: Es la solución de Vmware para albergar escritorios (Windows XP o 7) en la
infraestructura virtual, incluye herramientas para asignar las máquinas en base el usuario o mantener un
numero de máquinas pre-arrancadas de forma que los tiempos de respuesta de conexión de usuario sean
más ágiles
vCenter Operations: Permite definir políticas que se deben aplicar a toda la infraestructura de forma
que las ampliaciones, cambios, etc… de la misma no las vulneren
vCenter Site Recovery Manager: Otra herramienta vinculada a vCenter que permite tener un cluster en
otra ubicación de forma que en caso de problemas en el datacenter principal, se puedan levantar las
máquinas virtuales protegidas en otro sitio
vCenter CapacityIQ: En base a las métricas que ofrece vCenter agregando datos de todos los nodos y
servicios, avisar y proponer mejoras antes de llegar a límites de capacidad en nuestra infraestructura
virtual
vCenter Chargeback: Facilitar la gestión del cobro de los servicios a los diferentes departamentos de la
compañía. Una forma de que el presupuesto de TI (tecnologías de la información) se reparta entre los
usuarios, por ejemplo si marqueting requiere 30 sitios web para sus promociones, lo lógico es tener como
mínimo controlado este coste
vCenter Configuration Manager: Una herramienta para definir tipos de configuración estándar de
forma que podamos validar si nuestras máquinas virtuales tienen los parches adecuados, parámetros en el
registro o procesos de arranque autorizados
VMware Service Manager: Herramienta para definir qué servicios vamos a ofrecer desde nuestra
infraestructura y llevar todo el ciclo de vida. Está basado en las buenas prácticas de ITIL (glosario)
vCenter Orchestrator: Un plugin para vCenter que permite definir flujos de trabajo y automatizar
tareas, por ejemplo programar que por la noche a la máquina de facturación le asignamos más recursos,
mientras se los quitamos a otra y actualizamos a una tercera
vCenter es la mejor baza que tiene VMware ahora mismo respecto a sus competidores, una herramienta de
gestión del clúster, fácil de utilizar y a la vez muy potente. Es una aplicación que corre sobre un sistema
Windows de 64bits y que podemos tener dentro o fuera de nuestro entorno virtual
.
vCenter se encarga de que la gestión de recursos sea eficiente, que las políticas de afinidad (X y Y en el mismo
nodo) y anti-afinidad (X y Y en nodos diferentes) para cada máquina virtual se cumplan, activar el clúster entre
varios ESX, pero ante todo es la herramienta básica para el día a día de un administrador de infraestructura
virtual
Una vez montado nuestro servidor vCenter, tenemos dos opciones para gestionar de forma gráfica toda la
infraestructura, utilizar vSphere Client o vSphere Web Client.
vSphere Client es una herramienta solo para Windows que permite configurar y operar con todo lo que se
pueda activar en un entorno vSphere. Para las funcionalidades no incluidas de serie, incluye soporte de plugins
de forma que por ejemplo si instalamos Update Manager, tendremos las herramientas de gestión de este
paquete completamente integradas en el entorno. Por ejemplo hasta podemos cambiar los iconos por defecto en
las máquinas virtuales para facilitar la gestión
En el otro extremo de los casos de uso tenemos a vSphere Web Client que es una aplicación web que debemos
instalar en algún servidor que tenga acceso a nuestro vCenter Server, ya que utiliza vCenter Server para
gestionar a todo el entorno.
vSphere Web Client está pensada para poder parar y arrancar máquinas, editar parámetros básicos de las
máquinas virtuales y monitorizar los recursos gastados. Está orientada a aquel usuario que debe interactuar con
vSphere pero no se dedica a administrar la infraestructura virtual
En el siguiente video podéis ver un recorrido por la herramienta, está en inglés pero lo importante es que veáis
lo que nos permite realizar para decidir si instalamos vSphere Web Client o vSphere Client
2. Gestión de máquinas virtuales
Módulos
2.1 Requerimientos mínimos
Antes de gestionar las máquinas debemos tener el entorno montado, por un lado tendremos varías
máquinas corriendo el hipervisor ESXi 5, por otro algún equipo SAN o NAS que ofrezca almacenamiento
a ESXi, puede ser NFS, iSCSI o Fibre Channel y vCenter Server corriendo en el propio entorno virtual o
en otra máquina física. Estos documentos se pueden encontrar en la web de Vmware
(http://kb.vmware.com/selfservice/documentLinkInt.do?micrositeID=&popup=true&languageId=&
externalID=2005381), pero los incluimos aquí al entender interesante conocer que tipo de servidores
debemos adquirir para nuestra plataforma
Los requerimientos para instalar ESXi 5.0, son:
Su hardware cumple con los requisitos de la Guía de compatibilidad de VMware. Esto incluye:
Compatibilidad del sistema
Compatibilidad de E/S (tarjetas de red y HBA)
Compatibilidad de almacenamiento
Compatibilidad del software de copias de seguridad (backup)
Tenemos un procesador de 64 bits. Tenga en cuenta que VMware ESXi 5.0 sólo instala y se ejecuta en
servidores con CPU de 64 bits x86. Adicionalmente sólo admite instrucciones de CPU tipo LAHF y SAHF.
Estos son procesadores de 64 bits ampliamente conocidos:
Todos los procesadores AMD Opteron
Todos los procesadores Intel Xeon 3000/3200, 3100/3300, 5100/5300, 5200/5400, 5500/5600, 7100/7300,
7200/7400, y los procesadores 7500
La opción Intel VT está habilitada en el BIOS del host o servidor.
La memoria RAM es de 3GB. Este es el mínimo requerido para instalar.
Usted tiene uno o más controladores Ethernet de 1 Gigabit o 10 Gigabit. Para una lista de los modelos
de adaptadores de red, consulte la Guía de compatibilidad de VMware.
Tiene un disco SCSI o uno local, no en red, un LUN RAID con el espacio sin particionar para las
máquinas virtuales. Para Serial ATA (SATA), se debe tener el disco conectado a través de controladores
SAS soportados o sobre tarjetas controladoras SATA soportadas. Los discos SATA se consideran
remotos, no locales. Estos discos no se utilizan por defecto como una partición de scratch, porque se
les ve como discos remotos.
Nota: No se puede conectar un dispositivo de disco CD-ROM SATA a una máquina virtual en un servidor
ESXi 5.0. Para utilizar el dispositivo CD-ROM SATA, debe usar el modo de emulación IDE.
Usted está utilizando un sistema de almacenamiento soportado o compatible. ESXi 5.0 soporta la
instalación y el arranque desde los siguientes sistemas de almacenamiento:
Unidades de disco SATA. Unidades de disco SATA conectados a través de controladores SAS
compatibles. Algunos controladores SAS soportados son:
LSI1068E (LSISAS3442E)
LSI1068 (SAS 5)
IBM ServeRAID 8K SAS controller
2.1 Requerimientos
mínimos
2.2 Requerimientos de
vCenter 5.0
2.3 Cómo gestionarlas
2.4 Plantillas
2.5 Creación de una
máquina virtual
2.6 Prerequisitos
Generales
2.7. Ejercicio
2.2 Requerimientos de vCenter 5.0
Los requerimientos mínimos para vCenter 5.0 son:
Asegúrese que cumple con los requisitos mínimos de hardware y que el hardware y sistema
operativo son compatibles. El servidor vCenter Server 5.0 del sistema puede ser una máquina física
o una máquina virtual. Si va a instalar vCenter 5.0 en una máquina virtual, consulte Running vCenter
Server in a virtual machine (10087) para más información.
vCenter Server 5.0 requiere un nombre de la fuente de datos (DSN) de 64-bit para conectarse a su
base de datos.
En esta tabla se describen los requisitos mínimos de hardware:
Hardware
Requisito
Comentarios
Procesador Procesadores Intel o AMDEl procesador Intel Itanium (IA64) no es compatible. Los
x86 con dos o más
requisitos de procesador podrían ser mayores si la base de
núcleos (cores) lógicos, datos se ejecuta en la misma máquina.
cada uno con una
velocidad de al menos
2GHz
Los requisitos de RAM pueden ser mayores si su base de
Memoria 4 GB de RAM
datos se ejecuta en la misma máquina. La administración
de servicios web, VMware VirtualCenter Management
WebServices, requiere de 512 MB a 4.4GB de memoria
adicional. La máxima memoria la JVM de Webservices se
puede especificar durante la instalación dependiendo del
tamaño del inventario.
Los Requisitos de disco pueden ser mayores si la base de
Capacidad de4 GB de Disco
datos del servidor vCenter Server se ejecuta en la misma
Disco
máquina.En vCenter Server 5.0, el tamaño predeterminado
para los registros log de vCenter Server es 450 MB, que es
mayor que en vCenter Server 4.x Asegúrese que el espacio
asignado a la carpeta de registros log es suficiente para
soportar este aumento.
Hasta 2GB de espacio libre en disco para descomprimir el
Disco para 2 GB de Disco
archivo de instalación. Aproximadamente 1,5 GB de estos
SQL 2k8R2
archivos son borrados después de finalizada la instalación.
Express
Recomendación
Conexión de 1 Gbps
red
Estos son los requisitos para instalar vCenter Server en un disco local no que no sea C::
1 GB en la unidad custom drive para vCenter Server
1.13GB en la unidad C: para Microsoft.NET 3.0 SP1, Microsoft ADAM, Microsoft SQL Server 2008 R2
Express (opcional) y Microsoft Visual C++ 2008 Redistribuible
375MB for la unidad no C: drive%temp%variable
La base Microsoft SQL Server 2008 R2 Express incluida en el paquete requiere al menos 2GB de
espacio libre en disco para la base de datos.
Configuraciones de hardware recomendadas
Esta tabla resume las configuraciones de hardware recomendadas para una instalación mediana de
hasta 50 hosts y 500 máquinas virtuales encendidas:
Producto
Número de núcleos
Memoria
Disco
vCenter Server
2
4GB
5GB
Producto
vSphere Client
1
Número de núcleos
Memoria
200MB
Disco
1.5GB
Esta tabla resume las configuraciones de hardware recomendadas para una instalación grande de
hasta 300 hosts y 3.000 máquinas virtuales encendidas:
Producto
Número de núcleos
Memoria
Disco
vCenter Server
4
8GB
10GB
vSphere Client
1
500MB
1.5GB
Esta tabla resume las configuraciones de hardware recomendadas para una instalación extra-grande
de hasta 1.000 hosts y 10.000 máquinas virtuales encendidas:
Producto
Número de núcleos
Memoria
Disco
vCenter Server
8
16GB
10GB
vSphere Client
2
500MB
1.5GB
Requisitos del sistema operativo
Nota: vCenter Server 5.0 requiere un sistema operativo de 64 bits y no se puede instalar en un
sistema operativo de 32 bits. Al realizar una instalación debe asegurarse de que su sistema operativo
es compatible con 64 bits.
Estos son los sistemas operativos soportados:
Microsoft Windows Server 2003 Standard, Enterprise or Datacenter SP2 64bit
Microsoft Windows Server 2003 Standard, Enterprise or Datacenter R2 SP2 64bit
Microsoft Windows Server 2008 Standard, Enterprise or Datacenter SP2 64bit
Microsoft Windows Server 2008 Standard, Enterprise or Datacenter R2 SP2 64bit
Requisitos de la Pre-instalación de software
vCenter Server requiere Microsoft .NET 3.5 SP1 Framework. Si no está instalado en su sistema, el
instalador de vCenter Server lo instala por usted.
Nota: Microsoft Framework 3.5 SP1 puede requerir conexión a Internet para descargar y actualizar
los archivos durante el proceso de instalación.
Si planea utilizar la base de datos Microsoft SQL Server 2008 R2 Express que viene incluida con
vCenter Server 5.0, Microsoft Windows Installer version 4.5 (MSI 4.5) necesita estar instalado en su
sistema. Usted puede descargar MSI 4.5 del sitio Web de Microsoft. También puede instalar MSI 4.5
directamente desde el CD/DVD-ROM de vCenter Server 5.0.
Configuración de la base de datos de vCenter Server
vCenter Server y el Administrador de actualizaciones (Update Manager) requieren bases de datos
para almacenar y organizar los datos del servidor. VMware recomienda el uso de bases de datos
separadas para vCenter Server y el Administrador de actualizaciones. Para implementaciones
pequeñas, una base de datos para el administrador Update Manager podría no ser necesaria, sin
embargo no se recomienda omitirla.
Cada instancia de vCenter Server debe tener su propia base de datos. instancias de vCenter Server
no pueden compartir el mismo esquema de base de datos. Varias bases de datos de vCenter Server
pueden residir en el mismo servidor de base de datos, o también pueden estar separadas a través
de múltiples servidores de bases de datos.
Para bases de datos Oracle, que tienen el concepto de objetos de esquema, usted puede ejecutar
múltiples instancias de vCenter Server en un solo servidor de base de datos si usted tiene un
propietario de esquema diferente para cada instancia de vCenter Server. También puede utilizar un
servidor de base de datos Oracle dedicado para cada instancia de vCenter Server.
No es necesario instalar un nuevo servidor de base de datos para que trabaje la instalación del
servidor vCenter server. Durante la instalación de vCenter Server, usted puede apuntar el sistema de
vCenter Server a cualquier base de datos existente que sea compatible o soportada. vCenter Server
es compatible con las bases de datos IBM DB2, Oracle y Microsoft SQL Server. El administrador de
actualizaciones Update Manager es compatible con las bases de datos Oracle y Microsoft SQL
Server. Adicionalmente, las bases de datos de vCenter Server requieren un set de caracteres UTF.
Nota: Si usted tiene una base de datos de vCenter Server que desea conservar, no realice una
nueva instalación de vCenter Server. Para más información, consulte Upgrading to vCenter Server
5.0 (2003866). Para utilizar una base de datos existente, es necesario proporcionar el nombre DSN
de un sistema de 64 bits que apunte a la base de datos de vCenter Server.
Después de elegir un tipo de base de datos, asegúrese que entiende los requisitos de configuración
y versión o parche requerido por la base de datos.
Notas:
Microsoft SQL Server 2005 Express está diseñado para utilizarse con las implementaciones
pequeñas de hasta 5 hosts y/o 50 máquinas virtuales.
IBM DB2 sólo es compatible con vCenter Server. No hay soporte para el administrador de
actualizaciones Update Manager o cualquier plug-in que requiera una base de datos.
Un DSN de 64 bits debe ser creado para que apunte a una base de datos configurada con los
requisitos mínimos.
Creación de un DSN de 64 bits para vCenter Server
El sistema del servidor vCenter Server debe tener un DSN de 64 bits. Este requisito es aplicable a
todas las bases de datos soportadas.
Nota: El administrador Update Manager todavía requiere el uso de un DSN de 32-bit.
Para crear un DSN de 64 bits para vCenter Server siga estos pasos:
Seleccione Control Panel > Administrative Tools > Data Sources (ODBC).
Utilice la aplicación para crear un DSN para el sistema y seleccione el controlador apropiado de
acuerdo a los requisitos del proveedor de bases de datos.
Nota: Por ejemplo, si usted tiene una base de datos Microsoft SQL Server, cree el DSN del sistema
para el controlador de SQL Native Client driver.
Pruebe la conectividad.
Configuración del servidor vCenter Server para comunicarse con una base de datos local
Si desea instalar vCenter Server y la base de datos en el mismo sistema, la máquina en la que
instale o actualice vCenter Server debe tener un nombre de equipo de 15 caracteres o menos.
Si su base de datos se encuentra en la misma máquina en la que vCenter Server será instalado, y
recientemente ha cambiado el nombre de esta máquina para cumplir con el requisito de longitud del
nombre, asegúrese que el DSN vCenter Server está configurado para comunicarse con el nuevo
nombre de la máquina.
Cambiar el nombre del equipo del vCenter Server impacta la comunicación con la base de datos si el
servidor de esa base está en el mismo equipo del servidor vCenter Server. Si ha cambiado el nombre
de la máquina, verifique que la comunicación se mantiene intacta.
El cambio de nombre no tiene ningún efecto en la comunicación con bases de datos remotas. Usted
puede omitir este procedimiento si su base de datos es remota.
Nota: La limitación de longitud del nombre aplica al sistema de vCenter Server. El DSN y los
sistemas de bases de datos remotos pueden tener nombres con más de 15 caracteres.
Consulte con su administrador de base de datos o con el proveedor de bases de datos para
asegurarse que todos los componentes de la base de datos funcionan después de cambiar el
nombre del servidor.
Cuando esté configurando vCenter Server para comunicarse con una base de datos local, asegúrese
que:
El servidor de base de datos está en ejecución
El nombre del equipo del servidor vCenter Server esté actualizado en el servicio de nombres de
dominio (DNS)
Para probar la conexión, haga ping al nombre del equipo. Por ejemplo, si el nombre del equipo es
host-1.company.com, ejecute el siguiente comando en una pantalla de comandos de Windows:
ping host-1.company.com
Si puede hacer ping correctamente al nombre del equipo, entonces el nombre está actualizado en el
DNS.
Paquete incluido de la Base de Datos Microsoft SQL Server 2008 R2 Express
El Paquete incluido de la Base de Datos Microsoft SQL Server 2008 R2 Express es instalado y
configurado cuando se selecciona la opción bundled database durante la instalación o actualización
de vCenter Server.
Para instalar la base de datos Microsoft SQL Server 2008 R2 Express que viene incluida con vCenter
Server 5.0, se necesita que Microsoft Windows Installer version 4.5 (MSI 4.5) esté instalado en su
sistema. Usted puede descargar MSI versión 4.5 desde Microsoft. También se puede instalar MSI 4.5
directamente desde el instalador autorun.exe de vCenter Server.
Las siguientes son las bases de datos soportadas:
IBM DB2 9.5
IBM DB2 9.7
SQL Server 2005 32-bit Standard, Enterprise SP3
SQL Server 2005 64-bit Standard, Enterprise SP3
SQL Server 2008 64-bit Express R2
SQL Server 2008 32-bit Standard, Enterprise
SQL Server 2008 64-bit Standard, Enterprise
SQL Server 2008 32-bit Standard, Enterprise SP1
SQL Server 2008 64-bit Standard, Enterprise SP1
Oracle 10g 32-bit Standard, Enterprise, One R2 (supported with version 10.2.0.3.0 or higher)
Oracle 10g 64-bit Standard, Enterprise, One R2 (requires version 10.2.0.4)
Oracle 11g 32-bit Standard, Enterprise, One R1
Oracle 11g 64-bit Standard, Enterprise, One R1
Oracle 11g 32-bit Standard, Enterprise, One R2
Oracle 11g 64-bit Standard, Enterprise, One R2
2.3 Cómo gestionarlas
La gestión de máquinas virtuales en un entorno vSphere la podemos realizar de varias formas,
siendo la más intuitiva la proporcionada por vSphere Client. Disponemos también de acceso vía línea
de comandos a través de PowerShell (PowerCLI) o trabajando contra el API de ESX o de vCenter
según convenga. Aquí podemos ver una captura de la ayuda de PowerCLI para el comando
Get-VMhost, que nos listará todos los nodos ESXi dados de alta en un vCenter determinado
Como guía, podemos considerar que casi todo lo podremos hacer por la interfaz gráfica, los plugins
se integran perfectamente y además es la herramienta más usada por más administradores lo que
ayuda a encontrar soluciones a nuestros problemas mediante Google o los foros propios de Vmware.
Aun así, es recomendable utilizar la línea de comandos o el API cuando se realicen tareas repetitivas
o se quiera automatizar alguna de ellas. Por ejemplo si estamos ofreciendo un servicio que debe
permitir a no-administradores solicitar máquinas virtuales de un catálogo, puede ser interesante
automatizar desde un portal Web o parecido la petición, validar el flujo conforme la petición está
autorizada (lo mismo que haríamos si nos llega un correo electrónico pidiendo una máquina
adicional), clonar una plantilla (Template) y arrancar la máquina virtual automatizando o no la
asignación de la IP y la membresía en el dominio en caso de máquina Windows.
Automatizándolo de forma correcta, es decir incluyendo registro y auditoria de las acciones y
generando una serie de informes de uso y consumo, ganamos en el control de nuestra plataforma
virtual, ya que el gran problema en las plataformas virtuales es que el coste marginal de una nueva
máquina es casi despreciable y acaban existiendo demasiadas máquinas con su memoria y disco,
de las que no sabemos casi nada y nadie se atreve a eliminarlas, generando un problema de
gestión. Si tenemos un buen registro, siempre podremos preguntar a quien autorizó la activación el
por qué y si sigue siendo necesaria. Si las peticiones pasan a través de una persona, puede darse el
caso de activaciones de máquinas mediante una llamada y que luego no quede el registro oportuno,
del quién y porqué se activó esa máquina que lleva 6 meses allí sin hacer nada pero ocupando
espacio.
Por ejemplo, esa capacidad de automatización es la que permite tener productos como vCloud,
vCenter Orchestrator o de terceros como Abiquo o OpenStack. En el caso de Abiquo, disponemos
de una interfaz Web que nos permite crear nuevas máquinas, indicar relaciones entre ellas,
gestionar desde un único lugar varios centros de datos y un largo etcétera
vSphere nos permite agrupar las máquinas de nuestro clúster dentro de carpetas para tenerlas
fácilmente ordenadas y encontrar rápidamente una máquina virtual cuando la estamos buscando por
algún tipo de incidencia o petición de usuario.
Ya que la carpeta física donde está guardada la máquina tiene el nombre de creación, si definimos
nombres como “Test-Servidor1” y luego cambiamos de nombre a “Producción-Servidor1”, aunque
la interfaz nos muestre el cambio de nombre, en la datastore o almacén de datos, se mantendrá el
nombre antiguo hasta que se realice una datastore migration, por tanto es mucho más cómodo
mover la máquina de la carpeta “Test” a la carpeta “Producción” y luego no tendremos que tocar
nada.
Una vez tenemos alguna máquina creada, si creemos que vamos a necesitar varias de ellas, la
podemos convertir en plantilla, “Template”, para luego, clonarla y convertirla de nuevo en máquina
virtual
2.4 Plantillas
Esta es una funcionalidad que aporta vCenter, así que si solo tenemos ESXi, la interfaz no nos
permitirá clonar máquinas virtuales o crear plantillas, aunque copiando los ficheros .vmdk (Vmware
disk, el disco de nuestra máquina) y asignándolo a otras máquinas acabamos teniendo clonación y
una especie de plantillas
Si nos hemos decidido aprovechar la capacidad de disponer de plantillas de máquinas virtuales,
debemos tener en cuenta que al volver a convertirla en máquina virtual se mantendrá la
configuración que tenía en su momento la plantilla con lo que tendremos que cambiar la direcciones
IP en caso de tenerlas configuradas como estáticas, cambiar nombre la máquina y demás
configuración específica. En el caso de máquinas Windows puede ser interesante ejecutar sysprep
(http://technet.microsoft.com/es-es/library/cc721940(WS.10).aspx)
Por tanto una buena práctica es montar un servidor DHCP (http://es.wikipedia.org
/wiki/Dynamic_Host_Configuration_Protocol) para que asigne las IPs a las máquinas o en su defecto,
reservar las IP de las plantillas de forma que cuando activemos una de las máquinas virtuales, lo
primero que debemos hacer es cambiar la IP y seguramente el nombre, e intentar que el nombre de
máquina sea el mismo o muy similar al nombre que le hemos dado a la máquina virtual.
En el fondo, la diferencia de disponer de plantillas o clonar máquinas virtuales, es que las plantillas
no son ejecutables y quedan muy bien identificadas como tales, mientras que una máquina virtual
que utilicemos como base para clonar, por error la podemos pasar a producción o realizar cambios
que afecten luego a nuevos clones
Los pasos para realizarlo son los siguientes
Escoger una máquina virtual que será la base de nuestra plantilla. Si está parada mucho mejor
Si seleccionamos "Convert to Template", perderemos esa máquina virtual, si Clonamos a plantilla,
se realizará una copia y podremos seguir utilizando aquella máquina para su uso normal. Si la
clonamos, debemos decidir donde la guardamos. Por comodidad, puede ser interesante disponer de
un datastore para ficheros que no se mueven demasiado como ISOs o plantillas y almacenarlo en
discos baratos
Una vez seleccionado el lugar, nos debemos esperar a que vSphere copie los datos a ese
almacenamiento y marque la máquina como Plantilla. Dependiendo de la velocidad de nuestro
entorno y del tamaño de la máquina, pueden ser unos minutos
Una vez clonada y marcada como "Template", podremos ver que el icono a la izquierda del nombre
es diferente
En el siguiente paso, vamos a convertir a nuestra plantilla otra vez en máquina virtual, como se
puede ver en la captura anterior, tenemos dos opciones, una "Deploy Virtual Machine from this
Template" que copiará de nuevo la plantilla a otra ubicación y luego la marcará como máquina virtual
y "Convert to Virtual Machine" que solo la marcará otra vez como máquina virtual. Se nos pide donde
vincularla, seleccionamos el nodo o el clúster en caso de disponer de DRS y ya la tendremos
Y una vez terminado el proceso, volvemos a tener una máquina con icono normal, manteniendo el
nombre y la carpeta en el almacenamiento de la plantilla, así que se debe ir con cuidado para
mantener una cierta consistencia entre nombres de almacenamiento y nombres de inventario. En la
parte de la pantalla que muestra las tareas recientes, podemos ver la diferencia de tiempo en clonar
y marcar la plantilla. Estos 5 minutos que ha tardado en copiar los 40GB implican una velocidad de
casi 150 MB/s, más de 1Gb/s.
En caso de máquinas Windows, si no nos interesa realizar un sysprep, debemos tener cuidado en
no darla de alta en el dominio ya que al clonarla nos puede dar problemas por autenticación y
membresía al mismo. Así que si vamos a crear plantillas Windows, instalamos, aplicamos los
parches, instalamos las aplicaciones que no son dependientes del nombre de la máquina ni de la
membresía del dominio, como por ejemplo las VMtools y luego generamos la plantilla, cuando la
clonemos a máquina virtual, cambiamos la IP y nombre, la agregamos al dominio y luego ya
instalamos el resto de aplicaciones dependientes
2.5 Creación de una máquina virtual
El primer paso para crear una máquina virtual es indicárselo a vSphere Client, una vez nos muestra
el diálogo debemos darle nombre a la máquina teniendo en cuenta, que este nombre se usará para
la carpeta en el datastore y no es trivial cambiar el nombre allí, si lo hacemos directamente nos
quedaremos sin acceso a la máquina virtual ya que no cuadrará con el inventario
Una vez dado nombre, debemos escoger en qué datastore almacenaremos los ficheros de
configuració y datos de la máquina virtual. Aunque podemos crear discos relacionados con esa
máquina en varios datastores, mejor guardarlos todos juntos por facilidad de gestión. Un caso podría
ser un servidor de base de datos, donde tenemos el sistema operativo en un almacenamiento "lento"
y las bases de datos en un almacenamiento "rápido"
El siguiente paso es indicar qué tipo de sistema operativo instalaremos en nuestra máquina virtual,
en base a esto, la configuración por defecto de la máquina será una u otra, recomendación de
memoria, emulación de dispositivos (SCSI, red, etc...) y comportamiento si es 64 o 32 bits.
La mejor forma para hacer pruebas es instalar una pequeña distribución Linux, que al ser de libre
descarga no nos generará problemas legales y al ser Ubuntu una de las más asequibles para
cualquier usuario, vamos a usar esta
El siguiente paso es escoger qué redes tendrá nuestra nueva máquina, cada una de estas tarjetas
de red o NICs en inglés la tenemos que vincular a una red del servidor ESXi, seleccionar que tipo de
adaptador usaremos, tenemos Intel E1000, VMXnet2, VMXnet3 y Flexible, los VMXnet* requieren de
controladores especificos que se instalan con las VMtools, el tipo "Flexible" que dependiendo del
controlador se comporta como una Vlance o una VMXnet.
.
El siguiente paso es crear un disco donde instalar nuestra máquina, los dos modos "Thick" generan
un fichero en el datastore del tamaño especificado y la diferencia es si lo escriben con ceros durante
la creación o conforme se va accediendo a él. El modo "Thin", muestra a la máquina virtual un disco
del tamaño total pero el fichero que da soporte a ese disco va creciendo conforme se va usando, de
esta forma podemos asignar más disco del existente físicamente
Revisamos que todo es correcto y ya que esa configuración no instala el sistema operativo le
indicamos que queremos editar la configuración antes de crearla
Editamos el CD/DVD emulado para indicarle que utilice una ISO que tenemos en el datastore pero
podemos pasar un CD/DVD que tenga el nodo ESXi o nuestro propio CD donde se esté ejecutando
el cliente vSphere
Damos a "Finish" y ya tendremos nuestra máquina virtual creada, ahora solo falta encederla, abrir la
consola (el icono con una pantalla y flecha verde) e instalar Ubuntu de forma normal
Una vez tengamos instalado nuestro sistema operativo hospedado, debemos instalar las
herramientas de Vmware o VM Tools, es interesante instalarlas ya que incluyen controladores
específicos para los dispositivos emulados, ya sea la red, el disco o la pantalla, con lo que
ganaremos velocidad en la máquina virtual y al bajar la carga adicional de recursos o “overhead” en
inglés, mejoramos el rendimiento para el resto de máquinas virtuales hospedadas en ese nodo.
Además de los controladores también se incluye la capacidad de “balloning” o un pequeño servicio
que reserva memoria en nuestra máquina virtual para asignársela a otra máquina virtual que lo
necesita y tiene más prioridad que la nuestra. Esta función, aunque no aportar mejora del
rendimiento en nuestra máquina, si que permite que en algún momento, la suma de las memorias
de las máquinas virtuales supere a la del nodo físico. El sistema de hinchado de globo se utiliza
porque la mayoría de sistemas operativos no toleran demasiado bien que se les quite memoria de un
momento para otro y de esa forma, teniendo un proceso no paginable corriendo en la máquina
virtual, nos aseguramos que los procesos más importantes seguirán en memoria y se reducirá la
memoria asignada a cache de ficheros o usos menos prioritarios
2.6 Prerequisitos Generales
Antes de instalar vCenter Server, asegúrese de lo siguiente:
Compruebe que tiene el DVD de instalación o ha descargado el instalador de vCenter Server.
Verifique que los puertos necesarios están abiertos. Para más información, consulte Required
Ports for vCenter Server (2005105).
Verifique que su base de datos cumple con los requisitos correspondientes. Para más
información
Recopile la información que el asistente de instalación del servidor vCenter Server requiere. Para
más información.
Verifique que el nombre de dominio completo (FQDN) del sistema donde va a instalar vCenter
Server se pueda resolver. Para comprobar que el nombre se puede resolver, escriba: nslookup
<vCenter_Server_fqdn> en una ventana de linea de comandos. Si el nombre completo (FQDN)
se puede resolver, el comando nslookup devuelve la dirección IP y el nombre de la máquina del
controlador de dominio.
Verifique que no haya Network Address Translation (NAT) existente entre el sistema de vCenter
Server y los servidores que va a administrar.
Verifique que el nombre del equipo no tiene más de 15 caracteres.
Compruebe que el nombre DNS de la máquina coincide con el nombre real del equipo.
Asegúrese que el sistema en el que va a instalar vCenter Server no es un controlador de dominio
de Active Directory. La instalación de vCenter Server en un controlador de dominio no es
soportada.
En cada sistema que se está ejecutando vCenter Server, asegúrese que la cuenta de usuario de
dominio tiene estos permisos:
Pertenece al grupo de administradores
Actúa como parte del sistema operativo
Inicia sesión como un servicio
Tenga en cuenta si la instancia del servidor vCenter será independiente (Standalone) o
pertenecerá a un grupo vinculado (Linked Mode group).
Adicionalmente, considere los siguientes puntos:
A menos que usted planee instalar el paquete incluido de SQL Server 2008 R2 Express, cree
una base de datos para el servidor vCenter Server.
Si el sistema que se utiliza para la instalación de vCenter Server pertenece a un grupo de trabajo
(workgroup) en lugar de pertenecer a un dominio, no toda la funcionalidad estará disponible para
vCenter Server. Si es asignado a un grupo de trabajo, el sistema de vCenter Server no es capaz
de descubrir todos los dominios y los sistemas disponibles en la red cuando utiliza ciertas
funciones. Para determinar si el sistema pertenece a un grupo de trabajo o un dominio, haga
click-derecho en My Computer.
Durante la instalación, verifique que la conexión entre la máquina y el controlador de dominio
está funcionando.
La cuenta Servicio de red (NETWORK SERVICE) se requiere que esté en la carpeta en la que
está instalado el servidor vCenter Server y en la clave de Registro HKLM. Si no está seguro de
esto, póngase en contacto con el administrador del sistema.
Instale vCenter Server, al igual que cualquier servidor de la red, en una máquina con una
dirección IP fija y un nombre DNS conocido, de tal forma que los clientes puedan acceder
confiablemente al servicio. Asigne una dirección IP estática y un nombre de host para el servidor
de Windows donde residirá el sistema de vCenter Server. Esta dirección IP debe tener un registro
(interno) válido en el sistema de nombres de dominio (DNS). Asegúrese que la interfaz de
administración del servidor ESXi tiene una resolución DNS válida desde vCenter Server y desde
todos los clientes vSphere. Asegúrese que el servidor vCenter Server tiene una resolución DNS
válida desde todos los hosts ESXi y desde todos los clientes vSphere. Si utiliza DHCP en lugar
de una dirección IP estática para vCenter Server, asegúrese que el nombre del equipo de
vCenter Server está actualizado en el servicio de nombres de dominio (DNS).
Haga Ping al nombre del equipo para probar esta conexión. Por ejemplo, si el nombre del
equipo es host-1.company.com, ejecute este comando en una ventana de comandos del
sistema Windows:
ping host-1.company.com
Si puede hacer ping correctamente al nombre del equipo, entonces el nombre está
actualizado en el DNS.
Información sobre cuentas
Usted puede utilizar el sistema integrado de cuentas de Microsoft Windows o una cuenta de
usuario para ejecutar vCenter Server.
Con una cuenta de usuario, puede habilitar la autenticación de Windows para SQL Server y
proporcionar una mayor seguridad. La cuenta de usuario debe ser un administrador en la
máquina local. En el asistente de instalación, debe especificar el nombre de cuenta como
DomainNameUsername. Debe configurar la base de datos SQL Server para permitir el acceso de
SQL Server a la cuenta de dominio.
El sistema integrado de cuentas de Microsoft Windows tiene más permisos y derechos en el
servidor que las necesidades del sistema vCenter Server, lo que puede contribuir a problemas de
seguridad.
Para los DSN de SQL Server configurados con autenticación de windows, utilice la misma cuenta
de usuario para el servicio web VMware VirtualCenter Management Webservices y para el usuario
DSN.
Si no planea utilizar la autenticación de Microsoft Windows para SQL Server o si está utilizando
una base de datos Oracle o DB2, es posible que aún desee configurar una cuenta de usuario
local para el sistema de vCenter Server. El único requisito es que la cuenta de usuario sea un
administrador en la máquina local.
Nota: Si instala una instancia de vCenter Server como una cuenta de sistema local en una base
de datos local de SQL Server con la autenticación integrada de Windows NT, y usted agrega un
usuario de autenticación integrada de Windows NT en el servidor de base de datos local con la
misma base de datos predeterminada que vCenter Server, vCenter Server podría no arrancar.
IPv6
Si instala vCenter Server en un sistema que está configurado para utilizar IPv6, vCenter Server
utiliza IPv6. Cuando se conecte a ese sistema de vCenter Server o instale más módulos, debe
especificar la dirección del servidor en formato IPv6, a menos que utilice el nombre de dominio
completo (FQDN). Tal como se especifíca en los estándares de la llamada de procedimiento
remoto (Remote Procedure Call - RPC) para direcciones IPv6, se debe incluir la dirección IPv6
entre corchetes. Por ejemplo: [IPv6-address]
3.1 Tipos de Redes y puertos
En vSphere podemos diferenciar dos tipos de redes, las llamadas de “Virtual Machine” o
máquina virtual y las de VMKernel o necesarias para el hipervisor.
Redes
Las redes de VMKernel son en las que asignaremos las direcciones IP que usará ESXi para
migrar máquinas de un nodo a otro, para gestión y conexión a su vCenter Server asignado, para
decidir qué nodo es el maestro del clúster y acceder a almacenamiento basado en IP como
puede ser NFS o iSCSI. Por tanto es una red muy crítica para el buen funcionamiento del
entorno y debe disponer de una alta disponibilidad y ancho de banda, máxime si utilizamos
almacenamiento basado en IP. En caso de utilizar Fibre Channel como protocolo de acceso a
nuestra SAN (Storage Area Network) la red VMkernel, no requerirá tanto acho de banda si no
tenemos activado la funcionalidad de vMotion (migración de máquinas virtuales en caliente)
Las redes de “Virtual Machine”, en cambio, son las que usaremos para conectar las máquinas
virtuales alojadas en el nodo con el mundo exterior, debemos utilizar sistemas de alta
disponibilidad ya que en el caso de fallo, no solo dejaríamos una máquina sin servicio sino todas
las máquinas alojadas dentro del nodo, que pueden ser decenas. A nivel de ancho de banda
disponible, debemos hacer un cálculo de la capacidad total necesaria para cada máquina
teniendo en cuenta que al agregarse debemos sumar la capacidad en un momento dado y no la
suma de picos de ancho de banda. Por ejemplo si tenemos una máquina virtual que requiere 900
Mb/s por la noche ya que es la que realiza las copias de seguridad, y otra que requiere 800 Mb/s
por el día ya que ofrece los vídeos para nuestro sistema de formación en línea, la capacidad total
que debemos ofrecer será por lo menos 900 Mb/s en lugar de 1700 Mb/s.
Como hemos visto en la lección de gestión de máquinas virtuales, al crear una máquina se nos
pregunta qué red o redes queremos asignar a la misma y de esta forma simulamos el latiguillo
de la tarjeta de red virtual a un puerto del switch virtual.
Grupo de puertos
Como veremos en el siguiente apartado, en cada switch virtual por lo menos tenemos un grupo
de puertos, el que viene por defecto. Todos los puertos virtuales del mismo grupo de puertos se
pueden comunicar entre ellos a nivel 2, con lo que lo más normal es que un grupo de puertos
defina una red con direccionamiento propio, por ejemplo en el caso de redes IPv4, el grupo de
puertos A podría tener asignado el direccionamiento 192.168.10.0/24, si asignamos una máquina
virtual del mismo rango en otro grupo de puertos no se podrán comunicar ya que no usaran una
puerta de enlace o Gateway.
La diferencia principal entre los grupos de puertos en switches distribuidos o estándar, radica en
que en el caso de switches estándar debemos asegurarnos que los grupos de puertos están
etiquetados con el mismo nombre y en caso de utilizar VLANes está asignados al mismos ID de
VLAN. En cambio en un switch distribuido, la configuración es global en todo el clúster y por
tanto solo necesitaremos una configuración específica de VLAN si también tenemos máquinas
del mismo direccionamiento en el mundo físico.
A parte de algunas funcionalidades adicionales como políticas de seguridad, ancho de banda,
etc…, la mayor parte del tiempo estaremos utilizando grupos de puertos como sinónimos de
VLAN
En el caso que estemos utilizando puertos troncales de VLANes que permiten que por un mismo
puerto virtual pasen varias VLANes simultaneas y sea la máquina virtual la qué decida qué hace
con ellas, no tenemos una relación 1:1, pero igualmente funcionará como funcionan los switches
físicos, tenemos unos puertos que pueden comunicarse con los que pertenecen a su misma
VLAN (o no pertenecen a ninguna), los puertos de acceso, y algunos por los que pueden pasar
una serie de VLANs, los denominados puertos trunk
3.2 Switches
Tenemos dos tipos de switch, los estándares y los distribuidos, a nivel de funcionalidades y
configuración son muy parecidos. La gran ventaja del distribuido sobre el estándar es que nos
aseguramos que todos los nodos tienen exactamente la misma configuración de red y por lo tanto
las máquinas virtuales se pueden ser alojadas en cualquiera de ellos de forma indistinta
Switches Estándar
Este tipo de switch es independiente de cada nodo, en el fondo son una abstracción que permiten
por un lado disponer de conexión al mundo físico mediante los enlaces de que dispone el nodo, ya
sean gigabit Ethernet, 10gigabit Ethernet o cualquiera de los medios soportados por ESXi, con una o
varias tarjetas para balanceo de carga o disponibilidad y por el otro redes virtuales como las
descritas anteriormente donde tenemos vinculadas las máquinas virtuales.
Por defecto un switch estándar emula a 120 puertos y podemos conectar redes de 1Gb/s, las
emuladas como Intel E1000 o de 10Gb/s en las VMXnet
Para crear un switch, podemos ir desde el cliente vSphere a la pestaña “Configuration” del nodo
que nos interese, seleccionamos “Add Networking”, escogemos el tipo de red que nos interese, si
de máquinas virtuales o VMkernel
Decidimos donde vinculamos nuestra nueva red, si en un switch nuevo o la añadimos a un switch
virtual existente.
Una vez creado o seleccionado el switch virtual, le damos nombre a la red e indicamos qué VLAN
(es.wikipedia.org/wiki/VLAN) se asigna a esa red. De esta forma podemos segmentar fácilmente
nuestras redes y mantener un alto nivel de seguridad al poder describir y separar entornos con
internet pública, DMZ (http://es.wikipedia.org/wiki/Zona_desmilitarizada_(inform%C3%A1tica)) o
entorno privado o de servicios. Todo esto sin necesidad de tener varios dispositivos de red físicos
para cada una de las redes
Una vez creado el switch virtual, podemos configurarlo para nuestras necesidades, si cada una de
nuestras máquinas virtuales dispone de varios enlaces de red, puede ser necesario ampliar el
numero por defecto de puertos, de los 120 a 4088 teniendo en cuenta que cada puerto asignado
gastará recursos para su gestión, así que una buena opción es calcular cuantas máquinas virtuales
vamos a tener por nodo y cuantos puertos vamos a utilizar dejando algunos para posibles puntas.
Hemos de ser conscientes que para realizar cambios en el número de puertos deberemos reiniciar el
nodo con que mejor decidir de forma conservadora para minimizar cambios en producción.
Tenemos las opciones de seguridad, por ejemplo si permitimos puertos en modo promiscuo, es decir
que reciban paquetes que no van dirigidos a ellos, si las direcciones MAC (es.wikipedia.org/wiki
/Direcci%C3%B3n_MAC) pueden cambiar o si los equipos virtuales pueden enviar paquetes
falseando la MAC de origen.
Control de tráfico, donde podemos limitar para todos los puertos el ancho de banda que pueden
utilizar y de esta forma asegurar que ninguno de ellos supere los límites establecidos o las opciones
que nos ayudaran a definir qué uso se les da a varios puertos de red vinculados al mismo switch
virtual. Política de balanceo en base a puerto virtual de origen o destino, direcciones IP del paquete
o sistema activo/pasivo donde solo se usará el puerto pasivo si el activo no está en un estado
funcional.
Switches Distribuidos
Los switches distribuidos solo están disponibles en nodos vinculados a un vCenter Server y licencia
Enterprise. Este tipo de switch facilita en gran medida la gestión de la red en entornos relativamente
grandes ya que nos evita tener que crear en cada nodo las redes, asignarles los mismos nombres y
configuraciones, etc… para que se puedan mover las máquinas virtuales entre los nodos sin
problemas.
Cuando creamos un switch virtual distribuido, lo creamos a nivel de Datacenter, el sinónimo para
vSphere del clúster o grupo de nodos con configuración equivalente y donde se pueden mover las
máquinas con total libertad.
Le damos el nombre que estimemos oportuno, definimos la compatibilidad entre versiones, ya que si
tenemos nodos vSphere 4.1 y nodos vSphere 5.0 deberemos indicar el modo de compatibilidad de
4.1, el número máximo de puertos de subida (uplinks) por nodo, luego asignamos los nodos que
pertenecerán a ese switch y qué puertos físicos de ese nodo estarán vinculados al mismo.
Una vez hecho esto, asignamos los diferentes grupos de puertos (Port Group) que se comportarán
como varios segmentos de red. Todos los equipos virtuales asignados al mismo grupo de puertos se
podrán comunicar sin tener que pasar por un equipo enrutador de nivel 3.
La gran ventaja de los switches distribuidos es que no solo podemos utilizar el propio de Vmware
sino también basarse en lógica de otros fabricantes como por ejemplo Cisco con su Nexus 1000V.
De esta forma, se puede gestionar la parte de la red del entorno virtualizado con las mismas
herramientas y muchas de las funcionalidades y ventajas que la gestión de red en el entorno físico.
3.3 Buenas prácticas en redes
La buena práctica más importante es asegurarse mediante los medios más adecuados a
nuestras necesidades que en todos los nodos donde se pueda alojar una máquina virtual
cualquiera tengan la configuración de red lo más idéntica posible, tanto en lo que respecta a
número, tipo y nombre de los switchs virtuales, como de los enlaces hasta la red física.
El hecho que se llamen igual y tengan los mismos tipos nos permitirá que las máquinas se
puedan ejecutar en esa máquina y que además se permita la migración de las mismas. Este
último punto, habilitará una de las funciones más interesantes de un clúster vSphere, la
recuperación rápida ante fallos y el balanceo de carga.
Otra buena práctica que nos evitará problemas de rendimiento y disponibilidad, es dedicar
algunos enlaces a la red VMkernel, de forma que cuando se esté realizando un o varios
vMotions, sincronizando dos máquinas virtuales mediante FT (Fault Tolerance) o comunicaciones
de gestión del propio vSphere.
Y para asegurar que mantenemos el máximo de disponibilidad posible, cada uno de nuestros
nodos debería estar conectado por lo menos a dos switches físicos para tolerar la caída de uno
de ellos. Debemos tener en cuenta que un nodo de virtualización normalmente es mucho más
crítico que otra máquina no virtualizada, por el simple hecho que en un nodo de virtualización
podemos tener decenas de máquinas virtuales y aunque cada una de ellas no sea más crítica
que las no virtualizadas, la suma de todas ellas puede afectar más al negocio que la caída de
una de las otras.
Tener en cuenta que podemos añadir y quitar dispositivos de red físicos asignados a un vSwitch
sin problemas, pero si los quitamos todos o todos los asignados se quedan sin conectividad,
entre las máquinas virtuales del mismo nodo asignadas al mismo grupo de puertos o red se
podrán comunicar, pero no lo podrán hacer con el exterior.
Para proteger las máquinas virtuales más críticas, se recomienda instalar cortafuegos en el
propio entorno virtual de forma que no se pueda acceder a estas máquinas desde el entorno
físico sin pasar por el cortafuegos. Además si no es necesario que este grupo de máquinas se
comuniquen con el exterior podemos vincularlas únicamente a redes sin ningún enlace (uplink)
En las máquinas donde sea posible, para maximizar el rendimiento utilizar como tipo de
adaptador de red VMXnet3
En las máquinas con VMXnet3 es interesante activar la descarga de la gestión de los segmentos
TCP al procesador de la tarjeta de red. Esta función hace que sea la propia tarjeta de red física
del nodo la que compruebe que los paquetes llegan en orden y de forma correcta, de manera
que el sistema operativo y por tanto el procesador de la máquina virtual no deben realizar esta
tarea, mejorando latencias y rendimientos
En caso de modificar los tamaños máximos de transmisión (MTU), nos debemos asegurar que
por lo menos todos los adaptadores, enlaces y switches vinculados a las redes VMkernel tienen
exactamente el mismo valor, ya que sino nos podemos encontrar con problemas intermitentes
dentro del clúster que serán difíciles de diagnosticar y solucionar.
3.2 Switches
Tenemos dos tipos de switch, los estándares y los distribuidos, a nivel de funcionalidades y
configuración son muy parecidos. La gran ventaja del distribuido sobre el estándar es que nos
aseguramos que todos los nodos tienen exactamente la misma configuración de red y por lo tanto
las máquinas virtuales se pueden ser alojadas en cualquiera de ellos de forma indistinta
Switches Estándar
Este tipo de switch es independiente de cada nodo, en el fondo son una abstracción que permiten
por un lado disponer de conexión al mundo físico mediante los enlaces de que dispone el nodo, ya
sean gigabit Ethernet, 10gigabit Ethernet o cualquiera de los medios soportados por ESXi, con una o
varias tarjetas para balanceo de carga o disponibilidad y por el otro redes virtuales como las
descritas anteriormente donde tenemos vinculadas las máquinas virtuales.
Por defecto un switch estándar emula a 120 puertos y podemos conectar redes de 1Gb/s, las
emuladas como Intel E1000 o de 10Gb/s en las VMXnet
Para crear un switch, podemos ir desde el cliente vSphere a la pestaña “Configuration” del nodo
que nos interese, seleccionamos “Add Networking”, escogemos el tipo de red que nos interese, si
de máquinas virtuales o VMkernel
Decidimos donde vinculamos nuestra nueva red, si en un switch nuevo o la añadimos a un switch
virtual existente.
Una vez creado o seleccionado el switch virtual, le damos nombre a la red e indicamos qué VLAN
(es.wikipedia.org/wiki/VLAN) se asigna a esa red. De esta forma podemos segmentar fácilmente
nuestras redes y mantener un alto nivel de seguridad al poder describir y separar entornos con
internet pública, DMZ (http://es.wikipedia.org/wiki/Zona_desmilitarizada_(inform%C3%A1tica)) o
entorno privado o de servicios. Todo esto sin necesidad de tener varios dispositivos de red físicos
para cada una de las redes
Una vez creado el switch virtual, podemos configurarlo para nuestras necesidades, si cada una de
nuestras máquinas virtuales dispone de varios enlaces de red, puede ser necesario ampliar el
numero por defecto de puertos, de los 120 a 4088 teniendo en cuenta que cada puerto asignado
gastará recursos para su gestión, así que una buena opción es calcular cuantas máquinas virtuales
vamos a tener por nodo y cuantos puertos vamos a utilizar dejando algunos para posibles puntas.
Hemos de ser conscientes que para realizar cambios en el número de puertos deberemos reiniciar el
nodo con que mejor decidir de forma conservadora para minimizar cambios en producción.
Tenemos las opciones de seguridad, por ejemplo si permitimos puertos en modo promiscuo, es decir
que reciban paquetes que no van dirigidos a ellos, si las direcciones MAC (es.wikipedia.org/wiki
/Direcci%C3%B3n_MAC) pueden cambiar o si los equipos virtuales pueden enviar paquetes
falseando la MAC de origen.
Control de tráfico, donde podemos limitar para todos los puertos el ancho de banda que pueden
utilizar y de esta forma asegurar que ninguno de ellos supere los límites establecidos o las opciones
que nos ayudaran a definir qué uso se les da a varios puertos de red vinculados al mismo switch
virtual. Política de balanceo en base a puerto virtual de origen o destino, direcciones IP del paquete
o sistema activo/pasivo donde solo se usará el puerto pasivo si el activo no está en un estado
funcional.
Switches Distribuidos
Los switches distribuidos solo están disponibles en nodos vinculados a un vCenter Server y licencia
Enterprise. Este tipo de switch facilita en gran medida la gestión de la red en entornos relativamente
grandes ya que nos evita tener que crear en cada nodo las redes, asignarles los mismos nombres y
configuraciones, etc… para que se puedan mover las máquinas virtuales entre los nodos sin
problemas.
Cuando creamos un switch virtual distribuido, lo creamos a nivel de Datacenter, el sinónimo para
vSphere del clúster o grupo de nodos con configuración equivalente y donde se pueden mover las
máquinas con total libertad.
Le damos el nombre que estimemos oportuno, definimos la compatibilidad entre versiones, ya que si
tenemos nodos vSphere 4.1 y nodos vSphere 5.0 deberemos indicar el modo de compatibilidad de
4.1, el número máximo de puertos de subida (uplinks) por nodo, luego asignamos los nodos que
pertenecerán a ese switch y qué puertos físicos de ese nodo estarán vinculados al mismo.
Una vez hecho esto, asignamos los diferentes grupos de puertos (Port Group) que se comportarán
como varios segmentos de red. Todos los equipos virtuales asignados al mismo grupo de puertos se
podrán comunicar sin tener que pasar por un equipo enrutador de nivel 3.
La gran ventaja de los switches distribuidos es que no solo podemos utilizar el propio de Vmware
sino también basarse en lógica de otros fabricantes como por ejemplo Cisco con su Nexus 1000V.
De esta forma, se puede gestionar la parte de la red del entorno virtualizado con las mismas
herramientas y muchas de las funcionalidades y ventajas que la gestión de red en el entorno físico.
3.3 Buenas prácticas en redes
La buena práctica más importante es asegurarse mediante los medios más adecuados a
nuestras necesidades que en todos los nodos donde se pueda alojar una máquina virtual
cualquiera tengan la configuración de red lo más idéntica posible, tanto en lo que respecta a
número, tipo y nombre de los switchs virtuales, como de los enlaces hasta la red física.
El hecho que se llamen igual y tengan los mismos tipos nos permitirá que las máquinas se
puedan ejecutar en esa máquina y que además se permita la migración de las mismas. Este
último punto, habilitará una de las funciones más interesantes de un clúster vSphere, la
recuperación rápida ante fallos y el balanceo de carga.
Otra buena práctica que nos evitará problemas de rendimiento y disponibilidad, es dedicar
algunos enlaces a la red VMkernel, de forma que cuando se esté realizando un o varios
vMotions, sincronizando dos máquinas virtuales mediante FT (Fault Tolerance) o comunicaciones
de gestión del propio vSphere.
Y para asegurar que mantenemos el máximo de disponibilidad posible, cada uno de nuestros
nodos debería estar conectado por lo menos a dos switches físicos para tolerar la caída de uno
de ellos. Debemos tener en cuenta que un nodo de virtualización normalmente es mucho más
crítico que otra máquina no virtualizada, por el simple hecho que en un nodo de virtualización
podemos tener decenas de máquinas virtuales y aunque cada una de ellas no sea más crítica
que las no virtualizadas, la suma de todas ellas puede afectar más al negocio que la caída de
una de las otras.
Tener en cuenta que podemos añadir y quitar dispositivos de red físicos asignados a un vSwitch
sin problemas, pero si los quitamos todos o todos los asignados se quedan sin conectividad,
entre las máquinas virtuales del mismo nodo asignadas al mismo grupo de puertos o red se
podrán comunicar, pero no lo podrán hacer con el exterior.
Para proteger las máquinas virtuales más críticas, se recomienda instalar cortafuegos en el
propio entorno virtual de forma que no se pueda acceder a estas máquinas desde el entorno
físico sin pasar por el cortafuegos. Además si no es necesario que este grupo de máquinas se
comuniquen con el exterior podemos vincularlas únicamente a redes sin ningún enlace (uplink)
En las máquinas donde sea posible, para maximizar el rendimiento utilizar como tipo de
adaptador de red VMXnet3
En las máquinas con VMXnet3 es interesante activar la descarga de la gestión de los segmentos
TCP al procesador de la tarjeta de red. Esta función hace que sea la propia tarjeta de red física
del nodo la que compruebe que los paquetes llegan en orden y de forma correcta, de manera
que el sistema operativo y por tanto el procesador de la máquina virtual no deben realizar esta
tarea, mejorando latencias y rendimientos
En caso de modificar los tamaños máximos de transmisión (MTU), nos debemos asegurar que
por lo menos todos los adaptadores, enlaces y switches vinculados a las redes VMkernel tienen
exactamente el mismo valor, ya que sino nos podemos encontrar con problemas intermitentes
dentro del clúster que serán difíciles de diagnosticar y solucionar.
ESXi proporciona una abstracción del almacenamiento de forma que las máquinas virtuales alojadas en el
nodo ESXi no tienen por qué conocer que tipo de almacenamiento físico existe en realidad
Una máquina virtual basada en ESXi utiliza un disco virtual para almacenar su sistema operativo, archivos
de programa y otros datos asociados con su funcionalidad. Un disco virtual es un gran fichero o un
conjunto de ficheros físicos más pequeños que se pueden copiar, mover o archivar y de los que se puede
realizar una copia de seguridad de forma fácil. Se puede configurar una máquina virtual de forma que
contenga más de un disco virtual sin problemas.
Para acceder a los discos virtuales, las máquinas virtuales usan controladores SCSI virtuales. Estos
controladores emulan a:
BusLogic Parallel SCSI
LSI Logic Parallel SCSI
LSI Logic SAS
Vmware Paravirtual
Estos controladores son los únicos que una máquina virtual puede ver y acceder.
Cada uno de los discos virtuales que una máquina virtual puede acceder a través de uno de los
controladores virtuales SCSI, reside en un datastore o almacenamiento basado en el Sistema de Ficheros
de Máquinas Virtuales de vSphere (VMFS), en un datastore basado en NFS o en disco directo o también
llamado modo raw (crudo).
Desde el punto de vista de la máquina virtual, cada disco parece que esté conectado a través de un
controlador SCSI, tanto da si el disco físico está siendo accedido mediante SATA, SCSI, iSCSI, NFS o
Fibre Channel, y por tanto es completamente transparente para el sistema operativo alojados y sus
aplicaciones
4.2 Adaptadores de almacenamiento soportados
Los adaptadores de almacenamiento proporcionan conectividad para nuestro nodo ESXi contra
unidades de almacenamiento o servicios en red (NFS) específicos.
ESXi soporta diferentes tipos de adaptadores de almacenamiento, incluyendo SCSI, iSCSI, RAID,
Fibre Channel, Fibre Channel sobre Ethernet (FCoE) y Ethernet. ESXi accede a los adaptadores
directamente mediante los controladores de dispositivos en el VMkernel, por tanto, debemos validar
que nuestros adaptadores de almacenamiento son soportados por ESXi o que por lo menos existen
controladores para él.
Dependiendo del tipo de almacenamiento que usemos deberemos activar y configurar el adaptador
en cada nodo. Si usamos adaptadores basados en software de FCoE o iSCSI deberemos crear el
adaptador o iniciador y definirle los objetivos
Conexión a un datastore NFS
El primer paso para conectarnos por NFS contra algún almacenamiento compatible, es asegurarnos
que tenemos permisos en ese servidor
En Configuration->Storage seleccionamos Add Storage…
Escogemos NFS y se nos pregunta por el servidor NFS, el nombre de la carpeta que queremos usar
y un nombre para dárselo al datastore
Finish y ya tenemos un datastore basado en NFS para alojar nuestras máquinas virtuales
3 de 3
27/04/2014 18:30
El proceso de gestión de almacenamiento de ESXi arranca con el espacio de almacenamiento que nuestro
administrador de almacenamiento nos asigna en los diferentes sistemas.
ESXi soporta los siguientes tipos de almacenamiento
Almacenamiento Local: Almacena los ficheros de nuestras máquinas virtuales en almacenamiento
interno del nodo o directamente conectado a él
Almacenamiento en Red: Se almacenan los ficheros de las máquinas virtuales en discos o cabinas
conectadas a nuestro nodo ESXi mediante una red de alta velocidad
Almacenamiento Local
El almacenamiento local pueden ser o discos internos ubicados dentro de nuestro nodo ESXi o bien discos
en dispositivos externos conectados directamente con nuestro nodo mediante protocolos SAS o SATA.
El almacenamiento local no requiere de una red para comunicarse con nuestro nodo. Necesitamos un
cable conectado a la unidad de almacenamiento y cuando sea necesario una controladora compatible en
nuestro nodo.
La siguiente ilustración muestra una máquina virtual utilizando un almacenamiento SCSI local
En este ejemplo de topología de almacenamiento local, el nodo utiliza una sola conexión hasta el disco de
almacenamiento. En ese disco podemos crear una datastore VMFS, que podemos utilizar para almacenar
los ficheros de los discos de nuestras máquinas virtuales
Aunque este tipo de configuración es posible, no es una topología recomendada. Utilizando una sola
conexión entre el almacenamiento y los nodos, crea puntos únicos de fallo que pueden causar
interrupciones cuando una conexión tiene problemas.
ESXi soporta una gran variedad de dispositivos de almacenamiento interno, incluyendo SCSI, IDE, SATA,
USB y SAS. Independientemente del tipo de almacenamiento usado, nuestro nodo oculta la capa física de
almacenamiento a nuestras máquinas virtuales
El almacenamiento local no soporta compartición entre varios nodos. Ya que la mayoría de
almacenamiento local no permite múltiples conexiones, no se pueden utilizar múltiples caminos de acceso
al almacenamiento
4.4 Almacenamiento en red
El almacenamiento en red consiste de sistemas de almacenamiento externo que nuestro nodo
ESXi utiliza para almacenar remotamente ficheros de máquina virtual. Normalmente, los nodos
acceden a estos sistemas mediante redes de alta velocidad.
El almacenamiento en red es compartido, y por tanto los datastores en dispositivos de
almacenamiento en red pueden ser accedidos por múltiples nodos a la vez. ESXi soporta los
siguientes sistemas de almacenamiento en red.
Fibre Channel (FC)
Almacena las máquinas virtuales remotamente en una red de área de almacenamiento (SAN) FC.
Una SAN FC es una red de alta velocidad específica para conectar los nodos a dispositivos de
almacenamiento de alto rendimiento. La red utiliza el protocolo Fibre Channel para transportar
tráfico SCSI de las máquinas virtuales a los dispositivos de la FC SAN.
Para conectarse a una FC SAN, nuestro nodo debe disponer de un adaptador de bus para nodo
de tipo Fibre Channel (HBA, Host bust adapter). A no ser que usemos conexiones directas a los
dispositivos FC, necesitaremos de switches FC para enrutar nuestro tráfico de almacenamiento.
Si en nuestro nodo disponemos de adaptadores FCoE( Fibre Channel sobre Ethernet),
podremos conectarnos a nuestros dispositivos FC compartidos mediante una red Ethernet
En esta configuración, un nodo conecta a una estructura SAN, que consiste de switches FC y
cabinas de almacenamiento utilizando un adaptador FC. Las unidades lógicas (LUNs) de la
cabina aparecen disponibles al nodo. Podemos acceder a la LUN y crear datastores para
nuestras necesidades de almacenamiento. Los datastores utilizan el formato VMFS
Internet SCSI (iSCSI)
Almacena los ficheros de las máquinas virtuales en dispositivos remotos basados en iSCSI. iSCSI
empaqueta el tráfico SCSI de almacenamiento en el protocolo TCP/IP de forma que puede viajar
por una red estándar TCP/IP en lugar de tener que hacerlo por una red especializada basada en
FC.
Con una conexión iSCSI, nuestro nodo hace de iniciador de una comunicación con el objetivo
(target), ubicado en un almacenamiento remoto iSCSI.
ESXi proporciona dos tipos de conexiones iSCSI
Hardware iSCSI: Donde nuestro nodo se conecta al almacenamiento mediante un adaptador
capaz de procesar gran parte del protocolo iSCSI, descargando por tanto el procesador de
nuestro nodo
Software iSCSI: Nuestro nodo utiliza un iniciador iSCSI basado en software en el VMkernel para
conectarse al almacenamiento. Con este tipo de conexión iSCSI, solo necesitamos un adaptador
estándar de red.
Independientemente del tipo de conexión que utilicemos, debemos configurar los iniciadores en
el nodo para que se pueda acceder a las LUNs y crear los datastores
En el ejemplo de la izquierda, el nodo utiliza un adaptador iSCSI hardware para conectarse con
el sistema de almacenamiento iSCSI. En el caso de la de derecha, el nodo utiliza un adaptador
de software iSCSI y una tarjeta de red Ethernet para conectarse al almacenamiento iSCSI.
De esta manera los dispositivos de almacenamiento iSCSI del sistema de almacenamiento se
hacen disponibles en el nodo y ya los podemos configurar como almacenamiento VMFS
Almacenamiento en Red (NAS)
Almacena los ficheros de máquina virtual en servidores accesibles mediante una red TCP/IP
estándar. ESXi incluye un cliente NFS que soporta el protocolo Network File System (NFS)
versión 3 para comunicarse con servidores NAS/NFS.
Para lo conectividad de red, el nodo solo requiere de una tarjeta de red estándar.
En este caso nuestro datastore no tendrá el sistema de ficheros VMFS, sino que al utilizar el
protocolo NFS, se nos abstrae del sistema de ficheros subyacente
4.5 Configuración de un datastore iSCSI
Un datastore o almacén de datos es donde vSphere ESXi almacena los datos de las máquinas
virtuales, su configuración, registros asociados a las máquinas para identificar problemas y otros
ficheros para el uso de varios de los elementos que componen el clúster, por ejemplo para indicar
qué nodo es el propietario de la máquina.
Lo primero que debemos hacer, es decidir qué tipo de almacenamiento vamos a utilizar. Si sabemos
que vamos a montar un clúster, podemos descartar el almacenamiento local desde buen inicio, si
por el contrario las máquinas virtuales de ese nodo NUNCA se moverán de ese nodo, un
almacenamiento local nos reducirá la complejidad y coste del entorno
Vamos a suponer que necesitamos almacenamiento remoto, ya que así podremos aprovechar todas
las ventajas que tienen vSphere respecto a su competencia.
Así pues nos toca decidir si Fibre Channel, NFS o iSCSI. A nivel de protocolo todos dan más o
menos el mismo rendimiento si el sistema de almacenamiento tiene características similares, no tiene
sentido comparar discos de estado sólido con disco SATA de 4200 rpm. Así que lo decidiremos en
base a la capacidad de inversión, sinergias que podamos tener con el resto de servicios o
funcionalidades que se nos faciliten por el protocolo. Aquí tiene sentido hablar con el responsable de
almacenamiento de la compañía y que nos aconseje en base a la infraestructura instalada.
Decidido el almacenamiento, vamos a configurarlo. Los pasos que vamos a mostrar son muy
parecidos en todos los casos. Añadimos o usamos un adaptador que soporte el protocolo, se
accede, se le da formato en el sistema de ficheros VMFS, la versión 3 si tenemos en el clúster nodos
con versiones ESX 3.5 o 4.x o versión 5 si solo tenemos nodos con ESXi 5.0. Una vez creado el
datastore ya podemos crear o mover máquinas virtuales al nuevo almacenamiento.
Los pasos para iSCSI son los siguientes:
Añadimos un adaptador iSCSI desde storage adapters
Lo vinculamos a algún interfaz VMkernel
Le indicamos donde tenemos el sistema de almacenamiento y si es necesario le informamos de
usuario y contraseña para el acceso mediante el botón CHAP
Volvemos a buscar si hay nuevos discos disponibles
Se nos indica que en el adaptador que hemos creado, tenemos en nuestro caso un volumen (LUN)
disponible
Ahora en la opción Storage vamos a añadir un disco o LUN (descripción en es.wikipedia.org/wiki
/Logical_unit_number). Se nos da la opción también de NFS ya que el adaptador NFS va incluido de
serie con ESXi y no se le da formato al volumen
Seleccionamos el disco que nos interesa
Decidimos el tipo de sistema de ficheros
Creamos particiones, damos nombre y decidimos espacio a utilizar y revisamos que todo esté
correcto
Esperamos a que termine y ya tenemos el datastore creado. Ya podemos añadir o mover máquinas
a este nuevo datastore
5.1 Gestión y tipos de recursos
Gestión de recursos:
Para entender la gestión de recursos, debemos ser conscientes de sus componentes, sus objetivos y
cual es la mejor forma de implementarla en la configuración del clúster.
Hablaremos de como la asignación de recursos para una máquina virtual (peso, reserva y límites) puede
ser configurada y como ver sus valores. También hablaremos del proceso de control de admisión,
mediante el cual la configuración es validada teniendo en cuenta los recursos existentes.
La gestión de recursos es la asignación de recursos desde los proveedores de recursos a los
consumidores de los mismos. La necesidad de una gestión de recursos surge de la sobreasignación de
los mismos, es decir, más demanda que capacidad y del hecho que la capacidad puede ir variando
durante el tiempo. La gestión de recursos nos permite reasignar recursos de forma dinámica de manera
que podemos utilizar eficientemente la capacidad disponible
Tipos de recursos
Los recursos que podemos gestionar son todos lo que vSphere nos permite compartir, por ejemplo, la
CPU, memoria, potencia (eléctrica), almacenamiento y red.
De esta forma podemos decidir qué parámetros son los más importantes en cada caso, si nos interesa
una eficiencia de consumo eléctrico avanzada en lugar de maximizar el rendimiento, si queremos
asegurar que una máquina concreta tenga los recursos de red y almacenamiento necesarios para
ofrecer su servicio de forma adecuada o si nos queremos asegura que un máquina que ofrece un
servicio poco importante no consuma demasiados recursos del clúster afectando a otras máquinas
alojadas en él.
Proveedores de Recursos.
Los nodos y los clústeres, incluyendo los clústeres de almacenamiento, son los proveedores de
recursos físicos.
Para los nodos, los recursos disponibles son las especificaciones de hardware del mismo menos los
recursos utilizados por el software de virtualización, en nuestro caso ESXi.
Un clúster es un grupo de nodos. Podemos crear un clúster utilizando vSphere Client, y añadir
múltiples nodos al clúster, vCenter Server gestiona los recursos de esos nodos de forma conjunta, el
clúster tiene asignados todos los recursos de CPU y memoria de todos los nodos.
Podemos habilitar un sistema de balanceo de carga y alta disponibilidad global en todo el clúster,
habilitando las funcionalidades de DRS (Distributed Resource Scheduler) y HA (High Availability)
permitidas en algunas licencias de vSphere
Consumidores de recursos:
Las máquinas virtuales son los consumidores de recursos. La configuración por defecto de los recursos
que se establece durante la creación de la máquina virtual funciona correctamente para la mayoría de
máquinas. Pero posteriormente podemos editar los parámetros para asignar un porcentaje de la CPU
total, memoria, y Entrada/Salida de almacenamiento del proveedor de recursos o garantizar una reserva
de CPU y memoria. Cuando encendemos esa máquina virtual, el nodo comprueba si existen suficientes
recursos no reservados y en caso que los haya permite la activación de la máquina virtual. Este proceso
se llama Control de Admisión.
Un grupo de recursos es una abstracción lógica para la gestión flexible de los recursos. Los grupos de
recursos (Resource Pools) se pueden agrupar en jerarquías y ser usados para particionar
jerárquicamente los recursos disponibles de CPU y memoria. De acuerdo con esto, los grupos de
recursos se pueden considerar a la vez, consumidores y proveedores de recursos. Proveen recursos a
los grupos de recursos inferiores en la jerarquía y las máquinas virtuales, pero a la vez consumen
recursos de los grupos de recursos de jerarquía superior y en último termino del clúster o del nodo.
Aunque a nivel gráfico puede parecer que podemos utilizar los grupos de recursos para ordenar
nuestras máquinas virtuales, solo los debemos utilizar para realizar gestión de recursos, ya que si los
utilizamos como carpetas podemos generar problemas de falta de rendimiento en máquinas críticas y
exceso de recursos en otras no tan importantes.
Los nodos ESXi asignan a cada máquina virtual una porción de sus recursos de hardware en base a los
siguientes factores:
Recursos disponibles totales para el nodo ESXi o el clúster
Número de máquinas virtuales arrancadas y los recursos usados por estas
Sobrecoste requerido para la gestión de la virtualización
Límites de recursos definidos por el administrador
Objetivos de la gestión de recursos
Cuando nos podemos a gestionar los recursos, debemos ser conscientes de cuales son nuestros
objetivos.
Adicionalmente a resolver problemas de sobreasignación de recursos, la gestión de recursos nos puede
ayudar a cumplir lo siguiente
Aislamiento de rendimiento: Evitar que algunas máquinas virtuales monopolicen recursos y garantizar
unos niveles de servicio predecibles
Utilización eficiente: Aprovechar recursos sobrantes y sobreasignar recursos con una degradación
adecuada. Es decir que si estamos en un estado de sobreasignación, el rendimiento y los recursos
asignados nos permiten cumplir o estar muy cerca de los niveles de servicios acordados (SLA)
Facilitar la administración: Al controlar la importancia relativa de las máquinas virtuales, permitir un
particionamiento dinámico que nos permita cumplir los niveles de servicio
5.2 Cómo configurar la gestión de recursos
Cuando los recursos disponibles en el clúster no cubren las demandas de los consumidores de
recursos (y del sobrecoste de la virtualización), los administradores quizá deberían modificar la
cantidad de recursos asignados a cada máquina virtual o a los grupos de recursos donde
residen.
Usaremos los parámetros de asignación de recursos (cuota, reserva y límite) para determinar la
cantidad de CPU, memoria y recursos de almacenamiento proveídos a cada máquina virtual. En
particular tenemos varias opciones para asignar recursos
Reservar los recursos físicos del nodo o clúster
Asegurarse que por lo menos una parte de la memoria de máquina virtual es proveída por la
memoria física del nodo ESXi
Garantizar que una máquina virtual especifica siempre dispone de un porcentaje superior de
recursos físicos que otras máquinas virtuales
Definir un límite superior de los recursos que pueden ser asignados a una máquina virtual
Cuotas de asignación de recursos
Las cuotas (shares) definen la relativa importancia de una máquina virtual (o grupo de recursos).
Si una máquina virtual tiene el doble de cuota que otra máquina virtual, tiene derecho a consumir
como mucho el doble de aquel recurso cuando esas dos máquinas virtuales están compitiendo
por los recursos.
Las cuotas normalmente se especifican como High, Normal o Low (Alta, Normal o Baja), que
especifican una relación 4:2:1 respectivamente. Además, podemos seleccionar Custom
(personalizada) para asignar un número específico de cuota, el cual expresa un peso
proporcional, a cada máquina virtual.
Especificar cuotas tiene sentido solo en máquinas virtuales o grupos de recursos del mismo
nivel, es decir, máquinas virtuales y grupos de recursos que comparten el mismo ancestro en la
jerarquía de asignación de recursos. Estos consumidores de recursos del mismo nivel,
comparten recursos de acuerdo a su relativo peso en base a cuotas con el límite inferior de la
reserva y el supero del límite. Cuando asignamos cuotas a una máquina virtual, siempre
especificamos la prioridad de esa máquina virtual con relación al resto de otras máquinas
virtuales que estén encendidas.
Por defecto, cada vCPU asignada a una máquina virtual, le asigna 1000 shares de CPU si
estamos con prioridad normal, 500 si en baja y 2000 en alta. Por la parte de la memoria, tenemos
10 shares por cada MB de RAM asignado, 20 si estamos en modo alto y 5 en modo de baja
prioridad.
Así que una máquina con dos vCPUs y 16GB de memoria tendrá 1000*2=2000 shares de CPU y
16384*10=163840 shares de memoria en estado normal.
La prioridad relativa representada por cada share se modifica cuando una nueva máquina virtual
es encendida, esto afecta a todas las máquinas que estén dentro del mismo grupo de recursos.
Vamos a suponer que todas las máquinas virtuales tienen el mismo número de vCPUs.
Dos máquinas virtuales limitadas por CPU (consumimos toda la CPU disponible) corren en un
nodo con 8Ghz de capacidad total. Al tener las dos el mismo nivel de shares, Normal, cada una
recibe 4Ghz
Una tercera máquina es encendida y tiene especificado que los shares de CPU son de tipo Alto,
por lo que debería tener el doble de lo otorgado a las máquinas Normal. La nueva máquina
recibe 4Ghz y las otras dos máquinas se les reduce la capacidad hasta 2Ghz cada una.
Reserva de recursos
Una reserva especifica una garantía mínima de recursos para una máquina virtual.
El vCenter Server o el propio ESXi permite arrancar una máquina solo si dispone de suficientes
recursos no reservados para cumplir la reserva indicada en los parámetros de la máquina virtual.
El nodo garantiza que esa capacidad estará disponible aun y cuando el nodo esté muy cargado.
La reserva se expresa en unidades concretas (megahercios o megabytes).
Por ejemplo, imaginemos que tenemos 2GHz disponibles y especificamos una reserva de 1Ghz
para la MV1 y otro 1Ghz para MV2. Ahora cada máquina le garantizamos 1Ghz en caso que lo
necesite pero si en un momento dado MV1 solo está usando 500 Mhz, MV2 podría estar usando
1.5Ghz
La reserva por defecto es de 0, y podemos especificar un valor en caso de necesitar garantizar
ese mínimo de CPU o memoria para cada máquina virtual
Límite en la asignación de recursos
El límite define un umbral superior para los recursos de CPU, memoria o E/S de almacenamiento
que pueden ser asignados a una máquina virtual.
Un nodo puede asignar más que la reserva definida a una máquina virtual, pero nunca asigna
más del límite aunque existan recursos ociosos en el sistema. El límite también se expresa en
unidades concretas (megahercio, megabyte o operaciones E/S por segundo).
Los límites por defecto son ilimitados. Cuando el límite de memoria es ilimitado, la cantidad de
memoria configurada para la máquina virtual se convierte en el límite efectivo.
En la mayoría de los casos no es necesario especificar ningún límite, pero como todo, tiene
beneficios e inconvenientes:
Beneficios: Asignar un limite es útil si empezamos un número pequeño de máquinas virtuales y
queremos gestionar las expectativas de los usuarios. Ya que el rendimiento se deteriora
conforme vayamos activando más máquinas virtuales en nuestro sistema, podemos simular
disponer de menos recursos disponibles asignando límites
Inconvenientes: Podemos malgastar recursos ociosos si especificamos el límite. El sistema no
permitirá utilizar más recursos que el límite aun y cuando el sistema está infrautilizado.
Especificaremos un límite solo cuando tengamos buenas razones para hacerlo.
Recomendaciones en la asignación de recursos
Vamos a seleccionar lo parámetros de asignación de recursos (cuotas, reservas y límites) que
sean apropiados para nuestro entorno vSphere:
Si esperamos cambios frecuentes en el total de recursos disponibles, utilizar la funcionalidad de
cuotas para asignar los recursos de razonable entre las máquinas virtuales. Si usamos cuotas y
mejoramos el nodo (más Ram, más CPUs), cada máquina seguirá estando en la misma
prioridad, aunque ahora cada cuota representa un valor más grande de CPU, memoria o E/S
Utilizaremos reserva para especificar el mínimo aceptable de CPU o memoria, no la cantidad que
queremos que esté disponible. El nodo asigna recursos adicionales como disponibles en base a
las cuotas, la demanda estimada y los límites definidos por cada máquina virtual. La cantidad de
recursos concretos (Mhz o MB) no se modifica cuando cambia el entorno, ya sea parando o
arrancando nuevas máquinas virtuales o modificando el tipo o número de nodos en el clúster
Cuando especifiquemos las reservas de las máquinas virtuales, no asignemos todos los recursos
disponibles, dejemos al menos un 10% no reservado. Cuanto más cerca estemos de reservar
completamente toda la capacidad del sistema, más complicado es realizar modificaciones a las
reservas y a la jerarquía de grupos de recursos sin violar el control de admisión. Si nuestro
clúster tiene activada la funcionalidad de balanceo de carga (DRS), las reservas pueden
completar toda la capacidad del clúster o de los nodos individuales de forma que DRS no pueda
realizar su trabajo de forma eficiente
5.3 Control de admisión
Cuando activamos una máquina virtual, el sistema comprueba la cantidad de CPU y memoria
que todavía no se han reservado. En base a esta capacidad de recursos no reservados, el
sistema determina si puede garantizar la reserva que tiene asignada esa máquina virtual, en caso
que la tenga. Este proceso se llama Control de Admisión.
Si existen suficientes recursos no reservados de CPU y memoria, o si no hay ninguna reserva, la
máquina virtual es encendida, en caso que no sea así, se genera una alerta de “Recursos
Insuficientes” o Insufficient Resources.
A parte de la posible memoria reservada por parte del administrador, para cada máquina virtual
tenemos una cantidad de memoria que es el sobrecoste de la virtualización. Esta dependerá del
número de vCPUs asignadas, emulación de la tarjeta de vídeo, dispositivos y cantidad total de
memoria.
Ésta memoria también se tiene en cuenta al realizar los cálculos para el control de admisión.
Cuando también tenemos activada la funcionalidad DPM (Distributed Power Management),
algunos nodos pueden se puestos en modo de pausa (es decir, parados, standby) para reducir
el consumo eléctrico. Los recursos no reservados proporcionados por estos nodos son
considerados disponibles por el control de admisión. Por tanto si una máquina virtual no puede
ser encendida por falta de recursos, se hará una recomendación para activar alguno de los
nodos en pausa y dependiendo del grado de automatización, se les dará la orden de encendido
al número de nodos requerido para cubrir las necesidades de recursos.