Skip to main content
ONTAP tools for VMware vSphere 105
Hay disponible una nueva versión de este producto.
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Cómo las herramientas de ONTAP gestionan los igroups y las políticas de exportación

Colaboradores netapp-revathid
PDF

Los grupos de iniciadores (igroups) son tablas que contienen los nombres de puerto global (WWPN) de los hosts del protocolo FC o los nombres de nodo calificados de los hosts iSCSI. Puedes definir igroups y asignarlos a LUN para controlar qué iniciadores tienen acceso a los LUN.

En las herramientas de ONTAP para VMware vSphere 9.x, los igroups se creaban y gestionaban en una estructura plana, donde cada almacén de datos en vCenter se asociaba con un único igroup. Este modelo limitaba la flexibilidad y la reutilización de los igroups en varios almacenes de datos. Las herramientas ONTAP para VMware vSphere introducen igroups anidados, donde cada almacén de datos en vCenter está asociado a un igroup padre, mientras que cada host está vinculado a un igroup hijo bajo ese padre. Puedes definir igroups padre personalizados con nombres definidos por el usuario para reutilizarlos en distintos almacenes de datos y así facilitar la gestión de los igroups. Conoce el flujo de trabajo de los igroups para gestionar LUN y almacenes de datos en las herramientas ONTAP para VMware vSphere. Los diferentes flujos de trabajo generan configuraciones de igroups variables, como se muestra en los siguientes ejemplos:

Nota Los nombres mencionados son meramente ilustrativos y no hacen referencia a nombres reales de igroups. Los igroups gestionados por ONTAP tools usan el prefijo “otv_”. A los igroups personalizados se les puede dar cualquier nombre.

Término

Descripción

DS<number>

Almacén de datos

iqn<number>

Iniciador IQN

host<number>

MoRef de host

lun<number>

ID de LUN

<DSName>Igroup<number>

Igroup principal predeterminado (gestionado por ONTAP tools)

<Host-Moref>Igroup<number>

Subgrupo hijo

CustomIgroup<number>

Grupo principal de igroup personalizado definido por el usuario

ClassicIgroup<number>

Igroup utilizado en las versiones 9.x de ONTAP tools.
Ejemplo 1:

Crear un almacén de datos en un único host con un solo iniciador

Flujo de trabajo: [Crear] DS1 (lun1): host1 (iqn1)

Resultado:

  • DS1Igroup:

    • host1Igroup → (iqn1: lun1)

ONTAP crea el igroup principal DS1Igroup para DS1 y asigna el igroup secundario host1Igroup a lun1. El sistema siempre asigna los LUN a los igroups secundarios.

Ejemplo 2:

Montar un almacén de datos existente en un host adicional

Flujo de trabajo: [Montar] DS1 (lun1): host2 (iqn2)

Resultado:

  • DS1Igroup:

    • host1Igroup → (iqn1: lun1)

    • host2Igroup → (iqn2: lun1)

ONTAP tools for VMware vSphere crean un igroup secundario host2Igroup y lo añaden al igroup principal existente DS1Igroup.

Ejemplo 3:

Desmontar un almacén de datos de un host

Flujo de trabajo: [Desmontar] DS1 (lun1): host1 (iqn1)

Resultado:

  • DS1Igroup:

    • host2Igroup → (iqn2: lun1)

ONTAP tools for VMware vSphere elimina host1Igroup de la jerarquía. El sistema no elimina explícitamente los igroups secundarios. Los elimina cuando se dan estas dos condiciones:

  • Si no hay ningún LUN asignado, el sistema ONTAP elimina el igroup secundario.

  • Una tarea de limpieza programada elimina los igroups «suspensos» que no tienen asignaciones de LUN. Estos casos solo se aplican a los igroups gestionados por ONTAP tools, no a los creados de forma personalizada.

Ejemplo 4:

Eliminar almacén de datos

Flujo de trabajo: [Eliminar] DS1 (lun1): host2 (iqn2)

Resultado:

  • DS1Igroup:

    • host2Igroup → (iqn2: lun1)

Los igroups padres e hijos se eliminan, a menos que otro almacén de datos reutilice el igroup padre. Los igroups hijos no se eliminan de forma explícita

Ejemplo 5:

Crear varios almacenes de datos bajo un igroup principal personalizado

Flujo de trabajo:

  • [Crear] DS2 (lun2): host1 (iqn1), host2 (iqn2)

  • [Crear] DS3 (lun3): host1 (iqn1), host3 (iqn3)

Resultado:

  • CustomIgroup1:

    • host1Igroup → (iqn1: lun2, lun3)

    • host2Igroup → (iqn2: lun2)

    • host3Igroup → (iqn3: lun3)

Se crea CustomIgroup1 para DS2 y se reutiliza para DS3. Los child igroups se crean o actualizan bajo el parent compartido, y cada child igroup se asigna a sus LUN relevantes.

Ejemplo 6:

Eliminar un almacén de datos bajo un igroup principal personalizado.

Flujo de trabajo: [Eliminar] DS2 (lun2): host1 (iqn1), host2 (iqn2)

Resultado:

  • CustomIgroup1:

    • host1Igroup → (iqn1: lun3)

    • host3Igroup → (iqn3: lun3)

  • Aunque CustomIgroup1 no se vuelve a utilizar, no se elimina.

  • Si no hay ningún LUN asignado, el sistema ONTAP elimina host2Igroup.

  • host1Igroup no se elimina porque está asignado a lun3 de DS3. Los igroups personalizados nunca se eliminan, independientemente del estado de reutilización.

Ejemplo 7:

Ampliar vVols datastore (Agregar volumen)

Flujo de trabajo:

Antes de la expansión:

[Expandir] DS4 (lun4): host4 (iqn4)

  • DS4Igroup: host4Igroup → (iqn4: lun4)

Después de la ampliación:

[Expandir] DS4 (lun4, lun5): host4 (iqn4)

  • DS4Igroup: host4Igroup → (iqn4: lun4, lun5)

Se crea un nuevo LUN y se asigna al igroup secundario existente host4Igroup.

Ejemplo 8:

Reducir el almacén de datos vVols (Eliminar volumen)

Flujo de trabajo:

Antes de la reducción:

[Reducir] DS4 (lun4, lun5): host4 (iqn4)

  • DS4Igroup: host4Igroup → (iqn4: lun4, lun5)

Después de la contracción:

[Reducir] DS4 (lun4): host4 (iqn4)

  • DS4Igroup: host4Igroup → (iqn4: lun4)

El LUN especificado (lun5) se ha desasignado del igroup secundario. El igroup permanece activo siempre que tenga al menos un LUN asignado.

Ejemplo 9:

Migración de ONTAP tools de la versión 9 a la 10 (normalización de igroup)

Flujo de trabajo

ONTAP tools for VMware vSphere 9.x versions no admiten igroups jerárquicos. Durante la migración a 10.3 o versiones superiores, los igroups deben normalizarse en la estructura jerárquica.

Antes de la migración:

[Migración] DS6 (lun6, lun7): host6 (iqn6), host7 (iqn7) → ClassicIgroup1 (iqn6 & iqn7 : lun6, lun7)

La lógica de ONTAP tools 9.x permite tener varios iniciadores por igroup sin imponer una correspondencia uno a uno con los hosts.

Después de la migración:

[Migración] DS6 (lun6, lun7): host6 (iqn6), host7 (iqn7) → ClassicIgroup1: otv_ClassicIgroup1 (iqn6 & iqn7 : lun6, lun7)

Durante la migración:

  • Se crea un nuevo grupo principal (ClassicIgroup1).

  • El igroup original se renombra con el prefijo otv_ y se convierte en un igroup secundario.

Esto garantiza el cumplimiento del modelo jerárquico.

A partir de ONTAP tools 10.5P2, los igroups migrados se eliminan cuando ya no se utilizan. En versiones anteriores, los igroups migrados nunca se eliminaban. Ten en cuenta lo siguiente:

  • Los igrupos migrados no se pueden reutilizar en distintos almacenes de datos.

  • Los igroups personalizados (definidos por el usuario) nunca se eliminan y pueden seguir reutilizándose.

Temas relacionados

"Acerca de igroups"

Políticas de exportación

Las políticas de exportación controlan el acceso a los datastores NFS y los permisos de los clientes en ONTAP tools for VMware vSphere. Las políticas de exportación se crean y gestionan en los sistemas ONTAP y pueden usarse con datastores NFS para aplicar el control de acceso. Cada política de exportación consta de reglas que especifican los clientes (direcciones IP o subredes) que tienen permitido el acceso y los permisos otorgados (solo lectura o lectura y escritura).

Al crear un almacén de datos NFS en ONTAP tools for VMware vSphere, puedes seleccionar una política de exportación ya existente o crear una nueva. Luego, la política de exportación se aplica al almacén de datos, asegurando que solo los clientes autorizados puedan acceder a él.

Al montar un almacén de datos NFS en un nuevo host ESXi, ONTAP tools for VMware vSphere añade la dirección IP del host a la política de exportación existente asociada al almacén de datos. Esto permite que el nuevo host acceda al almacén de datos sin crear una nueva política de exportación.

Al eliminar o desmontar un almacén de datos NFS de un host ESXi, las herramientas ONTAP para VMware vSphere eliminan la dirección IP del host de la política de exportación. Si ningún otro host está utilizando esa política de exportación, esta se eliminará. Al eliminar un almacén de datos NFS, las herramientas ONTAP para VMware vSphere eliminan la política de exportación asociada a dicho almacén de datos si no la reutiliza ningún otro almacén de datos. Si la política de exportación se reutiliza, conserva la dirección IP del host y no cambia. Al eliminar los almacenes de datos, la política de exportación desasigna la dirección IP del host y asigna una política de exportación predeterminada, de modo que los sistemas ONTAP puedan acceder a ellos si es necesario.

La asignación de la política de exportación varía cuando se reutiliza en diferentes almacenes de datos. Al reutilizar la política de exportación, puedes añadir la nueva dirección IP del host a la política. Al eliminar o desmontar un almacén de datos que utilice una política de exportación compartida, la política no se eliminará. Permanece sin cambios y la dirección IP del host no se elimina, ya que se comparte con los demás almacenes de datos. No se recomienda reutilizar las políticas de exportación, ya que puede provocar problemas de acceso y latencia.

Temas relacionados

"Crea una política de exportación"