Requisitos de vSphere

Google Distributed Cloud se ejecuta de forma local en un entorno de vSphere. En este documento, se describen los requisitos para el entorno de vSphere.

Compatibilidad de versiones

Los requisitos de vSphere varían según la versión de Google Distributed Cloud que uses. Si deseas obtener más información, consulta la matriz de compatibilidad de versiones para versiones compatibles y versiones anteriores.

Versiones compatibles

vSphere es el software de virtualización de servidores de VMware que incluye ESXi y vCenter Server.

Google Distributed Cloud es compatible con estas versiones de ESXi y vCenter Server

  • 7.0 Actualización 2 y actualizaciones posteriores de la versión 7.0
  • Actualizaciones a la versión 8.0 y posteriores 8.0

Te recomendamos que uses 8.0, 7.0 actualización 3 o una actualización posterior de la versión 7.0.

Si deseas crear instantáneas de volumen de CSI, debes tener una de las siguientes versiones:

  • 7.0 Actualización 3 o una actualización posterior de la versión 7.0
  • 8.0 o una actualización posterior de la versión 8.0

Requisitos de licencias

Necesitarás una de las siguientes licencias:

  • Licencia de vSphere Enterprise Plus. Junto con esta licencia, debes tener una suscripción de asistencia válida.

  • Licencia de vSphere Standard. Junto con esta licencia, debes tener una suscripción de asistencia válida. Con esta licencia, no puedes habilitar grupos de antiafinidad. Además, no puedes especificar tu propio grupo de recursos. Debes usar el grupo de recursos predeterminado.

Requisitos de hardware

Google Distributed Cloud se ejecuta en un conjunto de hosts físicos que ejecutan el hipervisor ESXi de VMware. Para obtener información sobre los requisitos de hardware de ESXi, consulta ESXi Hardware Requirements (Requisitos de hardware de ESXi).

Para entornos de producción, te recomendamos lo siguiente:

Si configuras antiAffinityGroups.enabled como true, Google Distributed Cloud crea reglas de antiafinidad de DRS para los nodos del clúster, lo que hace que se distribuyan en al menos tres hosts ESXi físicos. Aunque las reglas de DRS requieren que los nodos del clúster se distribuyan en tres hosts ESXi, te recomendamos que tengas al menos cuatro hosts ESXi disponibles. Esto evita que pierdas el plano de control de tu clúster. Por ejemplo, supongamos que solo tienes tres hosts ESXi y el nodo del plano de control de tu clúster de administrador se encuentra en un host ESXi que falla. La regla de DRS evitará que el nodo del plano de control se coloque en uno de los dos hosts ESXi restantes.

Para la evaluación y la prueba de concepto, puedes configurar antiAffinityGroups.enabled como false y usar solo un host de ESXi. Para obtener más información, consulta Configura una infraestructura mínima.

Privilegios de la cuenta de usuario de vCenter

Para configurar un entorno de vSphere, un administrador de la organización puede optar por usar una cuenta de usuario de vCenter que tenga el rol de administrador de vCenter Server. Esta función proporciona acceso completo a todos los objetos de vSphere.

Después de configurar el entorno de vSphere, un administrador de clústeres puede crear clústeres de administrador y de usuario. El administrador del clúster no necesita todos los privilegios que proporciona el rol de administrador de vCenter Server.

Cuando un administrador o desarrollador de clústeres crea un clúster, proporciona una cuenta de usuario de vCenter en un archivo de configuración de credenciales. Recomendamos que a la cuenta de usuario de vCenter que aparece en un archivo de configuración de credenciales se le asigne uno o más roles personalizados que tengan los privilegios mínimos necesarios para la creación y la administración de clústeres.

Hay dos enfoques diferentes que un administrador de la organización puede adoptar:

  • Crea varios roles con diferentes privilegios. Luego, crea permisos que asignen esos roles limitados a un usuario o grupo en objetos individuales de vSphere.

  • Crea un rol que tenga todos los privilegios necesarios. Luego, crea un permiso global que asigne ese rol a un usuario o grupo en particular en todos los objetos de tus jerarquías de vSphere.

Recomendamos el primer enfoque, ya que limita el acceso y aumenta la seguridad de tu entorno de vCenter Server. A fin de obtener más información, consulta Usa roles para asignar privilegios y Prácticas recomendadas para roles y permisos.

Para obtener información sobre el uso del segundo enfoque, consulta Crea un permiso global.

En la siguiente tabla, se muestran cuatro roles personalizados que un administrador de la organización puede crear. Luego, el administrador puede usar los roles personalizados para asignar permisos en objetos específicos de vSphere:

Función personalizadaPrivilegiosObjetos¿Deseas propagar a
objetos secundarios?
ClusterEditor System.Read
System.View
System.Anonymous
Host.Inventory.Modify cluster 		clúster Sí
SessionValidator System.Read
System.View
System.Anonymous
Sessions.Validate session
Cns.Searchable
Profile-driven storage.Profile-driven storage view 		Raíz de vCenter Server No
ReadOnly System.Read
System.View
System.Anonymous 		centro de datos
red 		Sí
Anthos Privilegios en el rol de Anthos datastore
grupo de recursos
carpeta de VM
red 		Sí

Privilegios en el rol personalizado de Anthos

Crea roles y permisos personalizados

Un administrador de la organización puede usar la herramienta de línea de comandos govc para crear roles y permisos personalizados.

El administrador de la organización debe tener una cuenta de vCenter Server que tenga privilegios suficientes para crear roles y permisos. Por ejemplo, una cuenta con el rol de administrador sería apropiada.

Antes de ejecutar govc, configura algunas variables de entorno:

  • Configura GOVC_URL como la URL de tu instancia de vCenter Server.

  • Configura GOVC_USERNAME como el nombre de usuario de la cuenta de vCenter Server del administrador de la organización.

  • Configura GOVC_PASSWORD como la contraseña de la cuenta de vCenter Server del administrador de la organización.

Por ejemplo:

export GOVC_URL=vc-01.example
export GOVC_USERNAME=alice@vsphere.local
export GOVC_PASSWORD=8ODQYHo2Yl@

Crea roles personalizados

Crea los roles personalizados ClusterEditor, SessionValidator y ReadOnly:

govc role.create ClusterEditor System.Read System.View System.Anonymous Host.Inventory.EditCluster
govc role.create SessionValidator System.Read System.View System.Anonymous Sessions.ValidateSession Cns.Searchable StorageProfile.View
govc role.create ReadOnly System.Read System.View System.Anonymous

Crea un permiso que otorgue el rol ClusterEditor

Un permiso toma un par (usuario, rol) y lo asocia con un objeto. Cuando asignas un permiso a un objeto, puedes especificar si el permiso se propaga a objetos secundarios. Esto lo puedes hacer con govc, para ello, configura la marca --propagate en true o false. El valor predeterminado es false.

Crea un permiso que otorgue el rol ClusterEditor a un usuario en un objeto de clúster. Este permiso se propaga a todos los objetos secundarios del objeto de clúster:

govc permissions.set -principal ACCOUNT \
 -role ClusterEditor -propagate=true CLUSTER_PATH`

Reemplaza lo siguiente:

  • ACCOUNT: la cuenta de usuario de vCenter Server a la que se le otorga el rol

  • CLUSTER_PATH: la ruta del clúster en la jerarquía de objetos de vSphere

Por ejemplo, el siguiente comando crea un permiso que asocia el par (bob@vsphere.local, ClusterEditor with my-dc/host/my-cluster. El permiso se propaga a todos los objetos secundarios de my-dc/host/my-cluster:

govc permissions.set -principal bob@vsphere.local \
    -role ClusterEditor -propagate=true my-dc/host/my-cluster

Crea permisos adicionales

En esta sección, se proporcionan ejemplos de creación de permisos adicionales. Reemplaza las rutas de acceso de los objetos de ejemplo según sea necesario para tu entorno.

Crea un permiso que otorgue el rol SessionValidator a una cuenta en el objeto raíz de vCenter Server. Este permiso no se propaga a objetos secundarios:

govc permissions.set -principal ACCOUNT \
    -role SessionValidator -propagate=false

Crea permisos que otorguen el rol ReadOnly a una cuenta en un objeto del centro de datos y un objeto de red. Estos permisos se propagan a objetos secundarios:

govc permissions.set -principal ACCOUNT \
    -role ReadOnly -propagate=true \
    /my-dc \
    /my-dc/network/my-net

Crea permisos que otorguen el rol de Anthos a una cuenta en cuatro objetos: un almacén de datos, una carpeta de VM, un grupo de recursos y una red. Estos permisos se propagan a objetos secundarios:

govc permissions.set -principal ACCOUNT -role Anthos -propagate=true \
    /my-dc/datastore/my-ds  \
    /my-dc/vm/my-folder \
    /my-dc/host/my-cluster/Resources/my-rp \
    /my-dc/network/my-net

Crea un permiso global

En esta sección, se ofrece una alternativa a la creación de varios roles y permisos. No recomendamos este enfoque porque otorga un gran conjunto de privilegios en todos los objetos de tus jerarquías de vSphere.

Si aún no creaste el rol personalizado de Anthos, créalo ahora.

Crea un permiso global:

govc permissions.set -principal ACCOUNT \
 -role Anthos -propagate=true

Reemplaza lo siguiente:

Reemplaza ACCOUNT por la cuenta de usuario de vCenter Server a la que se le otorga el rol.

Por ejemplo, el siguiente comando crea un permiso global que otorga el rol de Anthos a bob@vsphere.local. El permiso se propaga a todos los objetos de tus jerarquías de vSphere:

govc permissions.set -principal bob@vsphere.local -role Anthos -propagate=true

Problemas conocidos

Consulta El instalador falla cuando se crea el disco de datos de vSphere.

¿Qué sigue?

Requisitos de CPU, RAM y almacenamiento