Como muchos se habrán
enterado, VMware ha realizado el lanzamiento de la versión 6.0 de vSphere,
veremos algunas de las tantas novedades que nos presenta la gente de Palo Alto.
VSPHERE Y VCENTER 6.0
Escalabilidad – Configuración de máximos
La Configuración de Máximos ha aumentado en todos los
ámbitos para los host vSphere en 6.0, en el que cada uno de ellos ahora puede
soportar:
- 480 CPUs Físicos por hos
- Hasta 12 TB de Memoria Física
- 1000 VMs por host
- 64 Hosts por Cluster
Escalabilidad –
Virtual Hardware v11
Este release de vSphere nos presenta la versión 11 de
Virtual Hardware. Algunas de sus
características son:
- 128 vCPUs
- 4 TB de RAM
- Una VM ahora puede tener un máximo de 32 serial
ports
- Los puertos seriales y los puertos paralelos
ahora pueden ser removidos
- Controlador xHCI 1.0 compatible con OS X 10.8+
xHCI driver
Local ESXi Account And Password Management Enhancements
En este último release de vSphere 6.0, VMware expandió el
soporte de account mangement en los hosts ESXi.
Nuevos comandos ESXCLI:
- Interface CLI para la administración de cuentas
de usuarios y permisos locales en el ESXi
- El ESXCLI puede ser invocado contra el vCenter
en lugar de acceder directamente al host ESXi
- Previamente, la funcionalidad de la
administración de cuentas y permisos para el host ESXi estaba disponible solo a
través de la conexión directa al host.
Complejidad del password:
- Previamente, los clientes tenían que editar
manualmente el archivo /etc/pam.d/passwd, ahora esto puede hacerse desde el VIM
API OptionManager.update().
- Las opciones avanzadas pueden también ser
accedidas a través de vCenter, por lo que no es necesario hacer una conexión
directa al host.
- PowerCli cmdlet permite setear las opciones
avanzadas de configuración del host
VCENTER SERVER 6.0 –
PLATFORM SERVICES CONTROLLER
El Platform Services
Controller (PSC) incluye servicios comunes que son usados a través de la
suite.
- Ellos incluyen SSO, Licencing y el VMware
Certificate Authority (VMCA)
- El PSC es la primera pieza que es instalada o
actualizada. Cuando se actualiza una
instancia de SSO, se convierte en PSC.
- Hay dos modelos de distribución, embebido y centralizado
- Embebido significa
que el PSC y el vCenter Server son instalados en una sola VM (esta es la
solución recomendad para sitios con una sola solución de SSO, tal como un solo
vCenter)
- Centralizado
significa que el PSC y el vCenter Server son instalados en diferentes VMs
(recomendado para sitios con dos o más soluciones de SSO, tal como múltiples
vCenter Servers, vRealize Automation, etc.
El PSC y los servidores vCenter se pueden combinar,
lo que significa que se puede implementar PSC Appliance junto con PSC Windows con vCenter tanto Windows como Appliance.
NETWORK AND SECURITY
Networking en vSphere 6.0 ha recibido algunas mejoras
importantes que ha dado lugar a las siguientes capacidades nuevas para vMotion:
·
Cross vSwitch vMotion
Cross vSwitch vMotion permite migrar una VM, sin problemas,
a través de diferentes virtual switches.
- Ya no está restringido por la red que se creó en
los vSwitches con el fin de hacer un vMotion de una VM
- vMotion trabajará a través de un mix de switches
(estandards y distribuidos).
Previamente, solo se podía hacer vMotion de vSS a vSS o dentro de un
solo vDS. Esa limitación ha sido
removida.
Las siguientes migraciones con Cross vSwitch vMotion son
permitidas:
- vSS a vSS
- vSS a vDS
- vDS a vDS
- vDS a vSS no está permitido!!
·
Cross vCenter vMotion
vMotion ahora puede realizar los siguientes cambios
simultáneamente:
- Cambio de host (vMotion) – realizar la migración
de VMs a través de hosts.
- Cambio de storage (Storage vMotion) – realizar
la migración de los discos de las VMs a través de datastores.
- Cambio de red (Cross vSwitch vMotion) –
migración de una VM a través de diferentes virtual switches.
- Cambio de vCenter (Cross vCenter vMotion) – realizar la migración del vCenter que gestiona la VM.
Todos estos tipos de vMotion son sin interrupciones al
sistema operativo Guest. Al igual que
con vSwitch vMotion, Cross vCenter vMotion requiere conectividad de red L2 ya
que la IP de la VM no será cambiada.
Esta funcionalidad se basa en Enhanced vMotion (Cross Host vMotion, en
vSphere 5.5) y, por lo tanto, storage compartido no es requerido.
Long Distance vMotion
Long Distance vMotion es una extensión de Cross vCenter
vMotion pensado para entornos donde los servidores vCenter se propagan a través
de grandes distancias geográficas y donde la latencia entre los sitios es de
100ms o menos.
Casos de uso:
- Migración de VMs entre servidores físicos que se
propagan a través de largas distancias geográficas sin interrupción de las
aplicaciones.
- Realizar una migración permanente de VMs en otro
datacenter.
- Distribución las VMs a través de sitios para
balancear la carga del sistema.
Requerimientos:
- Los requerimientos para Long Distance vMotion
son los mismos que para Cross vCenter vMotion, agregando la latencia máxima de
100ms entre los sitios de origen y destino, teniendo en cuenta también un ancho de banda de 250 Mbps.
- La red de la VM tendrá que ser una red L2
extendida, ya que la IP del sistema operativo Guest no va a cambiar. Si el portgroup de destino no está en el
mismo dominio L2 que el origen, se perderá la conectividad de red en el sistema
operativo Guest. Esto significa, en
algunas topologías, tal como metro o cross-continental, que necesitaremos una
tecnología L2 extendida in place. Las
tecnologías L2 extendidas no están especificadas. Cualquier tecnología que pueda presentar la
red L2 a los hosts vSphere va a funcionar, debido a que esto no es de
conocimiento para ESX de cómo está configurada la red física. Algunos ejemplos de tecnologías que funcionan
son VXLAN, NSX L2 Gateway Services, o túneles GIF/GRE.
- No hay definidas distancias máximas que serán
soportadas siempre que la red cumpla estos requerimientos.
Network I/O Control V3
Network I/O Control v3 permite a los administradores o
proveedores de servicios reservar o garantizar ancho de banda a una vNIC en una
máquina virtual o, a un nivel más alto, en un Distributed Port Group.
STORAGE AND AVAILABILITY
VMware Virtual
Volumes
VVOLS cambia la
arquitectura de storage y la manera con la cual es consumido el espacio. Cuando uno crea una LUN, esta es creada con
una capacidad fija. Luego, las VMs son
asignadas a una determinada LUN, basada en sus necesidades. Esto puede resultar en un problema cuando una
LUN con cierta cantidad de dato se queda sin capacidad, mientras otras LUNs aún
tienen espacio de sobra. El efecto de
esto es que típicamente los administradores hagan un sobredimensionamiento de
sus sistemas de storage, solo para estar seguros “por las dudas”.
Con VVOLS esto es totalmente diferente. Cada VM tiene asignada su propia política de
storage, y todas las VMs utilizan el storage desde el mismo pool en común. Los administradores de storage necesitan solo
hacer el provision para la capacidad total de todas las VMs, sin preocuparse
por las diferentes políticas. Por otra
parte, la política de una VM se puede cambiar, y esto no requiere que sea
movida a una diferente LUN.
VVOLS – Storage
Container
Un storage container es una construcción lógica para agrupar
Virtual Volumes. Este es seteado por el
administrador de storage, y la capacidad del container puede ser definida. Los container poseen la habilidad para aislar
o particionar storage de acuerdo a las necesidades requeridas.
FAULT TOLERANCE
Según mi criterio, este es el gran anuncio!, lo que hace
tiempo estábamos esperando!... veamos los beneficios de esta nueva versión:
- Enhanced virtual disk support – ahora soporta
cualquier formato de disco (thin, thick o EZT)
- Ahora soporta configuración de FT en caliente –
ya no es requerido apagar la VM para habilitar FT.
- Gran aumento de la compatibilidad del host para
FT – si podemos hacer vMotion de una VM entre hosts, podremos utilizar FT.
La nueva tecnología utilizada por FT se llama Fast
Checkpointing y es básicamente una versión modificada de xvMotion
(Cross-vCenter vMotion) que nunca termina y ejecuta muchos más checkpoints
(multiple/sec).
Nuevas Capacidades
De FT 6.0
DRS es soportado solo para el initial placement de la VM.
Backing Up FT VMs
Las VMs con FT pueden ahora ser respaldadas usando software estándar
de backup, al igual que todas las otras VMs (anteriormente las VMs con FT podían siempre ser respaldadas
utilizando agentes). Las VMs son respaldadas
usando snapshots a través de VADP. Los
usuarios no pueden tomar snapshots de esas VMs, esto es solo soportado como
parte de VADP.
Espero que les haya sido útil esta información, en los próximos post veremos otras funcionalidades de esta nueva versión...
