Thank you!
Thank you!
Categoría: VMware
VCP-DCV 2021 vSphere 7 – Describe storage…
VCP-DCV 2021 vSphere 7 – Describe storage…
Today we’ll discuss vSphere 7 storage. This post is part of Free VCP-DCV 2021 Study Guide.
Advanced Cross vCenter vMotion disponible en vSphere 7.0 Update 1c (p02)
¿De qué se trata Cross vCenter vMotion?
Advanced Cross vCenter vMotion es nueva capacidad disponible con la actualización vSphere 7.0 Update 1c (p02), que nos brinda una forma nativa de vMotion VM entre servidores vCenter y dominios SSO totalmente separados.
Imaginemos los diversos casos de uso de esta nueva funcionalidad. Migración de entornos completos, consolidación o bien cualquier necesidad de mover maquinas virtuales entre diferentes vCenter. Mover VMs sin estar limitado por las configuraciones de vCenter Server permite muchas «libertades» de migración.
Desde vSphere Client, hay dos flujos de trabajo disponibles para migrar cargas de trabajo entre vCenter Servers. Puede utilizar la opción ‘importar máquinas virtuales’ en la vista Hosts y clústeres para importar máquinas virtuales desde un vCenter Server “Origen” o bien seleccionar máquinas virtuales desde nuestro vCenter y optar por ‘Migrar’ hacia otro..
Caso de uso A: importar o migrar máquinas virtuales desde otro vCenter Server (que NO tiene que estar ejecutando vSphere 7.0 Update 1c (p02), ni en el mismo dominio de SSO). Ahora hay una nueva opción llamada » Importar VMs/Import VMs » cuando hace clic con el botón derecho sobre un objeto de vSphere Datacenter o Cluster.
A continuación, especificará su vCenter Server de origen. De forma predeterminada, estará en blanco y deberá agregar todos los vCenter Server desde los que desea migrar las máquinas virtuales al vCenter Server actual al que está conectado.
Nota: Por motivos de seguridad, las credenciales de vCenter Server guardadas no se conservan y se borrarán al cerrar la sesión o cuando expire la sesión actual.
Ahora, haga clic en la pestaña Saved vCenters y seleccione el vCenter Server de origen específico; o bien cargue un nuevo vCenter y haga clic en Siguiente, para este último caso nos aparecerá la alerta de seguridad.
Aceptamos la misma, y en caso de que todos los datos sean correctos nos informará que la conexión ha sido exitosa. Click en siguiente
El último paso es seleccionar la VM, las las VMs del vCenter Server de origen al cual nos conectamos y que deseemos migrar al vCenter Server actual
Los siguientes pasos, son los normales a los cuales estamos acostumbrados al realizar un vMotion de storage y de recursos de cómputo.
A continuación las imágenes demostrativas
Caso de uso B: exportar o migrar máquinas virtuales desde el vCenter Server actual a otro vCenter Server que NO necesariamente tiene que estar ejecutando vSphere 7.0 Update 1c (p02), ni en el mismo dominio de SSO
Para iniciar este flujo de trabajo, simplemente haga clic derecho en la (s) VM (s) deseada (s) y luego haga clic en » Migrar » y ahora verá un nuevo tipo de migración llamado opción de exportación Cross vCenter Server .
Seleccionamos Cross vCenter Server export
Y a partir de este paso, el flujo de trabajo es similar al Método A, en el que selecciona o agrega los vCenter Sever deseados y luego continúa con la migración.
Notas importantes
- La migración utiliza puertos vmkernel con trafico vmotion habilitado, tal como vMotion normal. Por lo tanto, el host de origen y destino deben poder comunicarse mediante puertos vMotion.
- La dirección MAC de la VM/VMs permanece/n igual/es después del XMV.
- Considerar que probablemente deba volver a agregar máquinas virtuales después de la migración a la copia de seguridad.
- Tener también en cuenta el modo EVC. De lo contrario, podría causar problemas en algunas VMs
vSphere DRS en 7.0 u1
vSphere DRS es una característica crítica de vSphere que se requiere para mantener el estado de las cargas de trabajo que se ejecutan dentro del clúster de vSphere. Desde vSphere 7.0 Update 1, DRS depende de la disponibilidad de las máquinas virtuales de vCLS.
Nota:Si intenta habilitar DRS en un clúster en el que haya problemas con las máquinas virtuales de vCLS, aparecerá un mensaje de advertencia en la página Resumen del clúster.
Nota:Si DRS está activado, pero hay problemas con las máquinas virtuales de vCLS, debe solucionar dichos problemas para que DRS funcione. Se mostrará un mensaje de advertencia en la página Resumen del clúster.
Si DRS no funciona, esto no significa que DRS esté deshabilitado. La configuración y los grupos de recursos de DRS existentes se conservan aunque se pierda el cúorum en las máquinas virtuales de vCLS. El estado de vCLS solo se vuelve Estado incorrecto en un clúster habilitado para DRS cuando las máquinas virtuales de vCLS no se están ejecutando, y la primera instancia de DRS se omite debido a este motivo. El estado de vCLS se mantendrá Degradado en un clúster que no esté habilitado para DRS cuando al menos una máquina virtual de vCLS no esté en ejecución.
vSphere Cluster Services (vCLS)
A partir de vSphere 7.0 Update 1, los servicios de clústeres de vSphere (vSphere Cluster Services, vCLS) están habilitados de forma predeterminada y se ejecutan en todos los clústeres de vSphere. vCLS garantiza que, si vCenter Server deja de estar disponible, los servicios de clústeres seguirán estando disponibles para mantener los recursos y el estado de las cargas de trabajo que se ejecutan en los clústeres. vCenter Server sigue siendo necesario en 7.0 Update 1 para ejecutar DRS y HA.
vCLS se habilita cuando se actualiza a vSphere 7.0 Update 1 o cuando hay una nueva implementación de vSphere 7.0 Update 1. vCLS se actualiza como parte de la actualización de vCenter Server.
vCLS utiliza máquinas virtuales de agente para mantener el estado de los servicios de clúster. Las máquinas virtuales de agente de vCLS se crean cuando se agregan hosts a los clústeres. Es necesario que se ejecuten hasta tres máquinas virtuales de vCLS en cada clúster de vSphere, distribuidas dentro de un clúster. vCLS también está habilitado en los clústeres que solo contienen uno o dos hosts. En estos clústeres, el número de máquinas virtuales de vCLS es uno y dos, respectivamente.
| Número de hosts de un clúster | Número de máquinas virtuales de agente de vCLS |
|---|---|
| 1 | 1 |
| 2 | 2 |
| 3 o más | 3 |
Las máquinas virtuales de vCLS se ejecutan en todos los clústeres aunque los servicios de clúster como vSphere DRS o vSphere HA no estén habilitados en el clúster. Las operaciones de ciclo de vida de las máquinas virtuales de vCLS se administran mediante servicios de vCenter como ESX Agent Manager y el plano de control de carga de trabajo. En vSphere 7.0 Update 1, las máquinas virtuales de vCLS no son compatibles con las tarjetas NIC.
Un clúster habilitado con vCLS puede contener hosts ESXi de diferentes versiones si las versiones de ESXi son compatibles con vCenter Server 7.0 Update 1. vCLS funciona con clústeres administrados tanto por vLCM como por VUM, y se ejecuta en todos los clústeres de SKU de licencias de vSphere.
Referencia:
Manejo de rutas con PowerCLI
Buenas tardes!!
Les comparto este script para manejar rutas de los hipervisores.
Primero les cuento el problema: este script lo hice para manejar el ruteo de hipervisores donde los cambios de vínculos entre principal y contingencia, provocan que queden rutas de vínculos inactivos y causan la desconexión de los hipervisores en el vCenter.
Desarrollo del script:
#variable $hosts se debe poner el nombre o ip del/los hipervisores
#variable $ruatcred es la ruta donde se almacenan las contraseñas guardadas de forma segura. #Puede ser útil: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/convertto-securestring?view=powershell-7.1
#variable $vcenter se debe escribir el nombre o ip del vcenter
$rutacred="ruta donde se almacenaron las credenciales de root"
$hosts="nombre o ip del hipervisor","nombre o ip del hipervisor"
$vcenter="se debe escribir el nombre o ip del vcenter"
$user='root'
$cred = New-Object System.Management.Automation.PsCredential $user,(Get-Content $rutacred | ConvertTo-SecureString)
Import-Module VMware.VimAutomation.Core
foreach ($hosts in $hosts)
{
Connect-VIServer -Server $hosts -Credential $cred -Force
$ruta=Get-VMHostRoute
foreach($ruta in $ruta)
{
if ($ruta.Destination.IPAddressToString -contains "$vcenter")
{
Remove-VMHostRoute -VMHostRoute $ruta -Confirm:$false
}
}
Disconnect-VIServer -confirm:$false
}
Autor: Torres Leandro.
vCenter filesystem /storage/archive full
Buenas tardes, les comento una solución que encontramos al evento de tener lleno el filesystem /storage/archive. Se controlaron las configuraciones recomendadas por la siguiente KB y la versión de vCenter es superior a 6.7 1b. https://kb.vmware.com/s/article/57829. Si nos conectamos por ssh podremos ver que la carpeta /storage/archive/vpostgres, contiene archivos .gz que se generan cada 5 minutos.
Para solucionarlo ejecutamos el siguiente comando que depura los archivos de más de 60 días: /storage/archive/vpostgres -name "*.gz" -type f -mtime +60 -exec rm -f {} \;
Fuente: http://dimitridumont.fr/vmware-vcenter-suppression-des-fichiers-de-logs-archives/ Autor: Torres Leandro.
Witness traffic separation en vSAN
Al momento de realizar el diseño de un cluster de vSAN en formato extendido (Stretched Cluster) puede que nos surjan dudas o cuestiones referidas al deployment del Witness.
A continuación dejo la lista de los requerimientos para la implementación:
- vCPUs: 2
- vRAM: 8GB
- ESXi installation vmdk: 12GB (as of 6.5, previous were 8GB)
- vSAN Cache vmdk: 10GB (this is common across profiles)
- Does not ever need to be larger than 10GB
- Does not have to be backed by a flash device, but must be tagged as a flash device
- vSAN Capacity vmdk: 15GB
- Can be tagged as flash, but not required
- Management VMkernel Interface (vmk0)
- Must be reachable by vCenter for Management
- Can be tagged for vSAN Traffic if the WitnessPg is not.
- WitnessPg VMkernel Interface (vmk1)
- Cannot be on the same network at the Management Network (KB 2010877)
- If vSAN Traffic is tagged, must be able to communicate with vSAN Data Nodes using vSAN VMkernel Interface or alternate VMkernel Interface when using Witness Traffic Separation
- Not required if vSAN Traffic is tagged on the Management VMkernel Interface
Como vemos en uno de los ítems a tener en cuenta, es necesario contar con ping y visibilidad desde los vmk de vSAN del cluster al Witness, por lo que para esto en redes que se encuentren aisladas, existe la posibilidad de implementar Witness Traffic Separation, es un feature que no es posible configurar desde vSphere Client.
En las siguientes líneas les comentaré como configurar WTS en los nodos vSAN y que la comunicación con el Witness se realice desde otro VMK diferente al de vSAN.
Podemos observar que, de forma predeterminada, el host testigo tiene dos redes:
a.) Management network – vSwitch0 – vmk0
b.) Witness switch “vsan traffic enabled” – vmk1
Esta característica permite flexibilidad para distinguir el tráfico de nodo a nodo y de nodo a testigo. En el host de testigos, no es necesario etiquetar el tráfico de testigos. Aquí, vmk1 está etiquetado para el tráfico vsan y en el lado de los nodos de datos, vmk1 debe etiquetarse para el tráfico testigo. No hay ninguna opción en vsphere webclient / vsphere client para habilitar el tráfico testigo en el adaptador vmkernel.
Esto se puede habilitar ejecutando el siguiente comando en los hosts SSH:
esxcli vsan network ip add -i vmk1 -T=witness
Por ejemplo: (en nodos del cluster)
[root@blr1:~] esxcli vsan network ip add -i vmk1 -T=witness
[root@blr1:~] esxcli vsan network list
Interface
VmkNic Name: vmk2
IP Protocol: IP
Interface UUID: 15bb6d5b-9328-22b0-137d-0050560151b8
Agent Group Multicast Address: 224.2.3.4
Agent Group IPv6 Multicast Address: ff19::2:3:4
Agent Group Multicast Port: 23451
Master Group Multicast Address: 224.1.2.3
Master Group IPv6 Multicast Address: ff19::1:2:3
Master Group Multicast Port: 12345
Host Unicast Channel Bound Port: 12321
Multicast TTL: 5
Traffic Type: vsan
Interface
VmkNic Name: vmk1
IP Protocol: IP
Interface UUID: 1b9c285c-c649-a3b6-f0c8-0050560151b8
Agent Group Multicast Address: 224.2.3.4
Agent Group IPv6 Multicast Address: ff19::2:3:4
Agent Group Multicast Port: 23451
Master Group Multicast Address: 224.1.2.3
Master Group IPv6 Multicast Address: ff19::1:2:3
Master Group Multicast Port: 12345
Host Unicast Channel Bound Port: 12321
Multicast TTL: 5
Traffic Type: witness
Desde que se agregó compatibilidad con MTU mixta de vSAN 6.7U1 en Stretched cluster de vSAN y clústeres ROBO de 2 nodos.
Viendo la imagen del ejemplo, utilizamos vmk1 (Naranja) para trafico Witness y vmk2 (verde) para trafico vSAN dedicado. De esta forma vemos como es posible contar con MTU mixto habilitado en el cluster. Jumbo frames activo entre los dos sites miembros del cluster extendido, y MTU 1500 contra el equipo testigo que puede estar desplegado en un tercer sitio o proveedor de nube.
Espero les sea de utilidad esta información.
Referencia:
https://blogs.vmware.com/virtualblocks/
Componentes opcionales de vCenter Server
Con el producto base, se empaquetan y se instalan los componentes opcionales de vCenter Server. No obstante, estos pueden necesitar una licencia aparte.
Las características opcionales de vCenter Server son, entre otras:
- vMotion
- Permite mover máquinas virtuales en ejecución de un host ESXi a otro host ESXi sin interrumpir el servicio. Requiere licencias tanto en el host de origen como en el de destino. vCenter Server coordina de forma centralizada todas las actividades de vMotion.
- Storage vMotion
- Permite mover el archivo de configuración y los discos de una máquina virtual en ejecución de un almacén de datos a otro sin interrumpir el servicio. Requiere licencias en el host de la máquina virtual.
- vSphere HA
- Habilita un clúster con alta disponibilidad. Si ocurre un error en el host, todas las máquinas virtuales que estaban en ejecución en él se reinician de inmediato en otros hosts del mismo clúster.
Cuando habilite el clúster para vSphere HA, debe especificar la cantidad de hosts que desee poder recuperar. Si establece en 1 la cantidad de errores de host permitidos, vSphere HA mantiene la capacidad suficiente en el clúster para tolerar el error de un host. Todas las máquinas virtuales en ejecución en ese host pueden reiniciarse en los hosts restantes. De manera predeterminada, no puede encender una máquina virtual si al hacerlo se infringe la capacidad de conmutación por error requerida.
- vSphere DRS
- Ayuda a mejorar el consumo de energía y la asignación de recursos en todos los hosts y grupos de recursos. vSphere DRS recopila la información de uso de recursos de todos los hosts y las máquinas virtuales del clúster, y ofrece recomendaciones (o migra las máquinas virtuales) en una de dos situaciones:
- Selección de ubicación inicial: cuando se enciende por primera vez una máquina virtual en el clúster, DRS ubica la máquina virtual o realiza una recomendación.
- Equilibrio de carga: DRS intenta mejorar el uso de recursos en el clúster mediante migraciones automáticas de las máquinas virtuales (vMotion) o recomendaciones para las migraciones de máquinas virtuales.
vSphere DRS incluye las capacidades de Distributed Power Management (DPM). Cuando se habilita DPM, el sistema compara la capacidad en los niveles de host y de clúster con las demandas de las máquinas virtuales en ejecución en el clúster. Según los resultados obtenidos en la comparación, DPM recomienda (o implementa) acciones que pueden reducir el consumo de energía del clúster.
- Storage DRS
- Permite administrar varios almacenes de datos como un solo recurso, llamado clúster de almacenes de datos. Un clúster de almacenes de datos es una suma de varios almacenes de datos dentro de un único grupo lógico con equilibrio de cargas. Puede tratarlo como un único recurso de almacenamiento flexible para los fines de administración de recursos. Puede asignar un disco virtual a un clúster de almacenes de datos, y Storage DRS encontrará el almacén de datos apropiado para él. El equilibrador de cargas se encarga de la selección de ubicación inicial y las futuras migraciones según las medidas de la carga de trabajo. El equilibrio del espacio de almacenamiento y de E/S minimiza el riesgo de quedarse sin espacio y el riesgo de cuellos de botella de E/S que bajan el rendimiento de las máquinas virtuales.
- vSphere Fault Tolerance
- vSphere Fault Tolerance proporciona disponibilidad continua para máquinas virtuales mediante la creación y el mantenimiento de una máquina virtual secundaria que es idéntica a la máquina virtual principal. Esta máquina virtual secundaria está continuamente disponible para reemplazar la máquina virtual principal en una situación de conmutación por error.
Objetos de inventario administrados de vSphere
En vSphere, el inventario es una colección de objetos físicos y virtuales en la que puede colocar permisos, supervisar tareas y eventos, y establecer alarmas. Puede agrupar la mayoría de los objetos de inventario mediante carpetas para administrarlas de manera más fácil.
Puede cambiarse el nombre de todos los objetos de inventario, con excepción de los hosts, para representar sus objetivos. Por ejemplo, se les puede poner el nombre según los departamentos de la empresa, las ubicaciones o las funciones.
Nota:Los nombres de objetos administrados no pueden superar los 214 bytes (codificados con UTF-8).
vCenter Server supervisa y administra los siguientes objetos de inventario:
- Centros de datos
- A diferencia de las carpetas, que se usan para organizar tipos de objetos específicos, un centro de datos es una acumulación de todos los tipos diferentes de objetos necesarios para realizar el trabajo en la infraestructura virtual.
Dentro de cada centro de datos, existen cuatro jerarquías separadas.
- Máquinas virtuales (y plantillas)
- Hosts (y clústeres)
- Redes
- Almacenes de datos
- Clústeres
- Una recopilación de hosts ESXi y las máquinas virtuales asociadas destinados a trabajar juntos como una unidad. Cuando se agrega un host a un clúster, los recursos del host se vuelven parte de los recursos del clúster. vCenter Server administra los recursos de todos los hosts de un clúster como una unidad.
- Almacenes de datos
- Una representación física de los recursos de almacenamiento físico en el centro de datos. Un almacén de datos constituye la ubicación de almacenamiento para los archivos de la máquina virtual. En un SDDC local, estos recursos de almacenamiento físico pueden provenir del disco de SCSI local del host ESXi, las matrices de disco SAN de canal de fibra, las matrices de disco SAN de iSCSI o las matrices de almacenamiento conectado a la red (Network Attached Storage, NAS). Tanto para los SDDC locales como en la nube, los almacenes de datos de vSAN ocultan las idiosincracias del almacenamiento físico subyacente y presentan un modelo uniforme para los recursos de almacenamiento que necesitan las máquinas virtuales.
- Carpetas
- Las carpetas permiten agrupar objetos del mismo tipo para poder administrarlos con facilidad. Por ejemplo, puede usar carpetas para establecer permisos entre los objetos, establecer alarmas entre ellos y organizarlos de forma significativa.
Una carpeta puede contener otras carpetas o un grupo de objetos del mismo tipo: centros de datos, clústeres, almacenes de datos, redes, máquinas virtuales, plantillas o hosts. Por ejemplo, una carpeta puede contener hosts y otra carpeta que contenga hosts, pero no puede contener hosts y otra carpeta que contenga máquinas virtuales.
- Hosts
- El equipo físico en el que está instalado ESXi Todas las máquinas virtuales se ejecutan en hosts o clústeres.
- Redes
- Un conjunto de tarjetas de interfaz de red (NIC virtuales), conmutadores distribuidos o vSphere Distributed Switch, y grupos de puertos o grupos de puertos distribuidos que conectan máquinas virtuales entre sí o con la red física fuera del centro de datos virtual. Puede supervisar las redes, y puede establecer permisos y alarmas en los grupos de puertos y los grupos de puertos distribuidos.
- Grupos de recursos
- Los grupos de recursos se usan para clasificar los recursos de memoria y CPU de un host o clúster. Las máquinas virtuales se ejecutan en grupos de recursos y obtienen sus recursos de esos grupos. Puede crear varios grupos de recursos como elementos secundarios directos de un host o clúster independiente, y luego delegar el control sobre cada grupo de recursos a otros individuos u otras organizaciones.
- Plantillas
- Una plantilla es una copia principal de una máquina virtual que se puede utilizar para crear y aprovisionar máquinas virtuales nuevas. Las plantillas pueden tener un sistema operativo invitado y un software de aplicación instalado. Se pueden personalizar durante la implementación para garantizar que la nueva máquina virtual tenga un nombre y una configuración de red únicos.
- Máquinas virtuales
- Un entorno de equipo virtualizado en el que pueden ejecutarse un sistema operativo invitado y el software de aplicación asociado. Varias máquinas virtuales pueden funcionar a la vez en el mismo equipo host administrado.
- vApps
- vSphere vApp es un formato para empaquetar y administrar aplicaciones. Una vApp puede contener varias máquinas virtuales.
Referencia:
El blog de Cristian Mercado 