Entenda igroups e políticas de exportação em ferramentas ONTAP para VMware vSphere
Sugerir alterações
PDFs
Grupos iniciadores (igroups) são tabelas de nomes de portas mundiais (WWPNs) de hosts de protocolo FC ou nomes de nós qualificados de hosts iSCSI. Você pode definir grupos e mapeá-los para LUNs para controlar quais iniciadores têm acesso a LUNs.
Nas ferramentas ONTAP para VMware vSphere 9.x, os igroups eram criados e gerenciados em uma estrutura plana, onde cada datastore no vCenter era associado a um único igroup. Esse modelo limitava a flexibilidade e a reutilização de igroups em múltiplos datastores. As ferramentas ONTAP para VMware vSphere 10.x introduzem igroups aninhados, onde cada datastore no vCenter é associado a um igroup pai, enquanto cada host é vinculado a um igroup filho sob esse pai. Você pode definir igroups pais personalizados com nomes definidos pelo usuário para reutilização em vários armazenamentos de dados, permitindo um gerenciamento mais flexível e interconectado de igroups. Entender o fluxo de trabalho dos igroups é essencial para gerenciar LUNs e datastores de forma eficaz nas ferramentas ONTAP para VMware vSphere. Diferentes fluxos de trabalho geram configurações de igroup variadas, como mostrado nos exemplos a seguir:
|
Os nomes mencionados são apenas para fins ilustrativos e não se referem a nomes de igroups reais. Os igroups gerenciados pelas ferramentas ONTAP usam o prefixo "otv_". Igroups personalizados podem receber qualquer nome. |
Prazo |
Descrição |
DS<número> |
Armazenamento de dados |
iqn<número> |
IQN do iniciador |
host<número> |
Anfitrião MoRef |
lun<número> |
ID LUN |
<NomeDS>GrupoI<número> |
igroup pai padrão (gerenciado por ferramentas ONTAP) |
<Host-Moref>Igroup<número> |
igroup infantil |
CustomIgroup<número> |
igroup pai personalizado definido pelo usuário |
ClassicIgroup<número> |
Igroup usado nas versões 9.x das ferramentas ONTAP. |
Crie um armazenamento de dados em um único host com um iniciador
Fluxo de trabalho: [Criar] DS1 (lun1): host1 (iqn1)
Resultado:
-
DS1Igroup:
-
host1Igroup → (iqn1: lun1)
-
Um igroup pai, DS1Igroup, é criado nos sistemas ONTAP para DS1, com um igroup filho, host1Igroup, mapeado para lun1. LUNs são sempre mapeados para igroups filhos.
Montar o armazenamento de dados existente em um host adicional
Fluxo de trabalho: [Montagem] DS1 (lun1): host2 (iqn2)
Resultado:
-
DS1Igroup:
-
host1Igroup → (iqn1: lun1)
-
host2Igroup → (iqn2: lun1)
-
Um igroup filho host2Igroup é criado e adicionado ao igroup pai existente DS1Igroup.
Desmontar um armazenamento de dados de um host
Fluxo de trabalho: [Desmontar] DS1 (lun1): host1 (iqn1)
Resultado:
-
DS1Igroup:
-
host2Igroup → (iqn2: lun1)
-
O host1Igroup é removido da hierarquia. Os igroups filhos não são excluídos explicitamente. A exclusão ocorre sob estas duas condições:
-
Se nenhum LUN for mapeado, o sistema ONTAP excluirá o igroup filho.
-
Uma tarefa de limpeza agendada remove os igroups filhos pendentes sem mapeamentos de LUN. Esses cenários se aplicam apenas a igroups gerenciados por ferramentas ONTAP, não a igroups criados de forma personalizada.
Excluir armazenamento de dados
Fluxo de trabalho: [Excluir] DS1 (lun1): host2 (iqn2)
Resultado:
-
DS1Igroup:
-
host2Igroup → (iqn2: lun1)
-
Os igroups pai e filho são removidos se outro repositório de dados não reutilizar o igroup pai. Os igroups filhos nunca são excluídos explicitamente.
Crie vários armazenamentos de dados em um igroup pai personalizado
Fluxo de trabalho:
-
[Criar] DS2 (lun2): host1 (iqn1), host2 (iqn2)
-
[Criar] DS3 (lun3): host1 (iqn1), host3 (iqn3)
Resultado:
-
CustomIgroup1:
-
host1Igroup → (iqn1: lun2, lun3)
-
host2Igroup → (iqn2: lun2)
-
host3Igroup → (iqn3: lun3)
-
O CustomIgroup1 é criado para o DS2 e reutilizado para o DS3. Os igroups filhos são criados ou atualizados sob o pai compartilhado, com cada igroup filho mapeando para seus LUNs relevantes.
Exclua um armazenamento de dados em um igroup pai personalizado.
Fluxo de trabalho: [Excluir] DS2 (lun2): host1 (iqn1), host2 (iqn2)
Resultado:
-
CustomIgroup1:
-
host1Igroup → (iqn1: lun3)
-
host3Igroup → (iqn3: lun3)
-
-
Mesmo que CustomIgroup1 não seja reutilizado, ele não é excluído.
-
Se nenhum LUN for mapeado, o sistema ONTAP excluirá o host2Igroup.
-
O host1Igroup não é excluído porque está mapeado para lun3 do DS3. Igroups personalizados nunca são excluídos, independentemente do status de reutilização.
Expandir o armazenamento de dados vVols (Adicionar volume)
Fluxo de trabalho:
Antes da expansão:
[Expandir] DS4 (lun4): host4 (iqn4)
-
DS4Igroup: host4Igroup → (iqn4: lun4)
Após a expansão:
[Expandir] DS4 (lun4, lun5): host4 (iqn4)
-
DS4Igroup: host4Igroup → (iqn4: lun4, lun5)
Um novo LUN é criado e mapeado para o igroup filho existente host4Igroup.
Reduzir o armazenamento de dados vVols (remover volume)
Fluxo de trabalho:
Antes de encolher:
[Encolher] DS4 (lun4, lun5): host4 (iqn4)
-
DS4Igroup: host4Igroup → (iqn4: lun4, lun5)
Após a redução:
[Encolher] DS4 (lun4): host4 (iqn4)
-
DS4Igroup: host4Igroup → (iqn4: lun4)
O LUN especificado (lun5) não está mapeado do igroup filho. O igroup permanece ativo enquanto tiver pelo menos um LUN mapeado.
Migração das ferramentas ONTAP 9 para 10 (normalização igroup)
Fluxo de trabalho
As ferramentas ONTAP para VMware vSPhere 9.x não oferecem suporte a igroups hierárquicos. Durante a migração para versões 10.3 ou superiores, os igroups devem ser normalizados na estrutura hierárquica.
Antes da migração:
[Migração] DS6 (lun6, lun7): host6 (iqn6), host7 (iqn7) → ClassicIgroup1 (iqn6 e iqn7: lun6, lun7)
A lógica das ferramentas ONTAP 9.x permite vários iniciadores por igroup sem impor mapeamento de host um para um.
Após a migração:
[Migração] DS6 (lun6, lun7): host6 (iqn6), host7 (iqn7) → ClassicIgroup1: otv_ClassicIgroup1 (iqn6 e iqn7: lun6, lun7)
Durante a migração:
-
Um novo igroup pai (ClassicIgroup1) é criado.
-
O igroup original é renomeado com o prefixo otv_ e se torna um igroup filho.
Isso garante a conformidade com o modelo hierárquico.
Políticas de exportação
As políticas de exportação controlam o acesso aos datastores NFS nas ferramentas ONTAP para VMware vSphere. Elas definem quais clientes podem acessar os datastores e quais permissões eles têm. As políticas de exportação são criadas e gerenciadas em sistemas ONTAP e podem ser associadas aos datastores NFS para impor o controle de acesso. Cada política de exportação consiste em regras que especificam os clientes (endereços IP ou sub-redes) que têm acesso e as permissões concedidas (somente leitura ou leitura/gravação).
Ao criar um repositório de dados NFS nas ferramentas ONTAP para VMware vSphere, você pode selecionar uma política de exportação existente ou criar uma nova. A política de exportação é então aplicada ao repositório de dados, garantindo que apenas clientes autorizados possam acessá-lo.
Ao montar um repositório de dados NFS em um novo host ESXi, as ferramentas ONTAP para VMware vSphere adicionam o endereço IP do host à política de exportação existente associada ao repositório de dados. Isso permite que o novo host acesse o repositório de dados sem criar uma nova política de exportação.
Ao excluir ou desmontar um repositório de dados NFS de um host ESXi, o ONTAP Tools for VMware vSphere remove o endereço IP do host da política de exportação. Se nenhum outro host estiver usando essa política de exportação, ela será excluída. Ao excluir um repositório de dados NFS, o ONTAP Tools for VMware vSphere remove a política de exportação associada a esse repositório de dados se ela não for reutilizada por outros repositórios de dados. Se a política de exportação for reutilizada, ela manterá o endereço IP do host e permanecerá inalterada. Ao excluir os repositórios de dados, a política de exportação desatribui o endereço IP do host e atribui uma política de exportação padrão, para que os sistemas ONTAP possam acessá-los, se necessário.
A atribuição da política de exportação difere quando ela é reutilizada em diferentes repositórios de dados. Ao reutilizar a política de exportação, você pode anexá-la ao novo endereço IP do host. Ao excluir ou desmontar um repositório de dados que usa uma política de exportação compartilhada, a política não será excluída. Ela permanece inalterada e o endereço IP do host não é removido, pois é compartilhado com os outros repositórios de dados. A reutilização de políticas de exportação não é recomendada, pois pode levar a problemas de acesso e latência.