Como as ONTAP tools gerenciam igroups e políticas de exportação
Sugerir alterações
PDFs
Os grupos de iniciadores (igroups) são tabelas de nomes de porta World Wide Port Name (WWPNs) de hosts do protocolo FC ou nomes de nós qualificados de hosts iSCSI. Você pode definir igroups e mapeá-los para LUNs para controlar quais iniciadores têm acesso aos LUNs.
Nas ONTAP tools for VMware vSphere 9.x, os igroups eram criados e gerenciados em uma estrutura plana, onde cada datastore em vCenter estava associado a um único igroup. Esse modelo limitava a flexibilidade e a reutilização de igroups em vários datastores. ONTAP tools for VMware vSphere introduz igroups aninhados, onde cada datastore em vCenter está associado a um igroup pai, enquanto cada host está vinculado a um igroup filho sob esse pai. Você pode definir igroups pai personalizados com nomes definidos pelo usuário para reutilização em vários datastores, facilitando o gerenciamento de igroups. Entenda o fluxo de trabalho de igroup para gerenciar LUNs e datastores nas ONTAP tools for 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 reais de igroups. Os igroups gerenciados pelas ONTAP tools usam o prefixo "otv_". Os igroups personalizados podem receber qualquer nome. |
Termo |
Descrição |
DS<number> |
Datastore |
iqn<number> |
IQN do iniciador |
host<number> |
MoRef do host |
lun<number> |
ID LUN |
<DSName>Igroup<number> |
Grupo pai padrão (gerenciado por ONTAP tools) |
<Host-Moref>Igroup<number> |
Igroup filho |
CustomIgroup<number> |
Igroup pai personalizado definido pelo usuário |
ClassicIgroup<number> |
Igroup usado nas versões 9.x das ONTAP tools. |
Criar armazenamento de dados em um único host com um iniciador
Fluxo de trabalho: [Criar] DS1 (lun1): host1 (iqn1)
Resultado:
-
DS1Igroup:
-
host1Igroup → (iqn1: lun1)
-
ONTAP cria o igroup pai DS1Igroup para DS1 e mapeia o igroup filho host1Igroup para lun1. O sistema sempre mapeia LUNs para igroups filhos.
Montar o datastore existente em um host adicional
Fluxo de trabalho: [Mount] DS1 (lun1): host2 (iqn2)
Resultado:
-
DS1Igroup:
-
host1Igroup → (iqn1: lun1)
-
host2Igroup → (iqn2: lun1)
-
ONTAP tools for VMware vSphere criam um igroup filho host2Igroup e o adicionam ao igroup pai existente DS1Igroup.
Desmontar um datastore de um host
Fluxo de trabalho: [Desmontar] DS1 (lun1): host1 (iqn1)
Resultado:
-
DS1Igroup:
-
host2Igroup → (iqn2: lun1)
-
ONTAP tools for VMware vSphere removem o host1Igroup da hierarquia. O sistema não exclui explicitamente os igroups filhos. Ele os exclui sob estas duas condições:
-
Se nenhum LUN estiver mapeado, o sistema ONTAP exclui o igroup filho.
-
Uma tarefa de limpeza agendada remove os igroups filhos órfãos sem mapeamento de LUN. Esses cenários se aplicam somente aos igroups gerenciados pelas ONTAP tools, não aos criados pelo usuário.
Excluir datastore
Fluxo de trabalho: [Excluir] DS1 (lun1): host2 (iqn2)
Resultado:
-
DS1Igroup:
-
host2Igroup → (iqn2: lun1)
-
Os igroups pai e filho são removidos, a menos que outro datastore reutilize o igroup pai. Os igroups filho não são excluídos explicitamente
Crie vários datastores sob 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)
-
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 respectivos LUNs.
Exclua um datastore em um igroup pai personalizado.
Fluxo de trabalho: [Excluir] DS2 (lun2): host1 (iqn1), host2 (iqn2)
Resultado:
-
CustomIgroup1:
-
host1Igroup → (iqn1: lun3)
-
host3Igroup → (iqn3: lun3)
-
-
Embora o CustomIgroup1 não seja reutilizado, ele não é excluído.
-
Se nenhum LUN estiver mapeado, o sistema ONTAP exclui o host2Igroup.
-
host1Igroup não é excluído porque está mapeado para o lun3 do DS3. Custom igroups nunca são excluídos, independentemente do status de reutilização.
Expandir vVols datastore (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 datastore 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) foi desassociado do igroup filho. O igroup permanece ativo enquanto tiver pelo menos um LUN mapeado.
Migração das ferramentas ONTAP 9 para 10 (normalização de igroup)
Fluxo de trabalho
ONTAP tools for VMware vSphere versões 9.x não suportam 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 & iqn7 : lun6, lun7)
A lógica das ONTAP tools 9.x permite múltiplos iniciadores por igroup sem impor um mapeamento de host um para um.
Após a migração:
[Migração] DS6 (lun6, lun7): host6 (iqn6), host7 (iqn7) → ClassicIgroup1: otv_ClassicIgroup1 (iqn6 & iqn7 : lun6, lun7)
Durante a migração:
-
Um novo igroup pai (ClassicIgroup1) é criado.
-
O igroup original é renomeado com o prefixo otv_ e torna-se um igroup filho.
Isso garante a conformidade com o modelo hierárquico.
A partir do ONTAP tools 10.5P2, os igroups migrados são excluídos quando deixam de ser utilizados. Em versões anteriores, os igroups migrados nunca eram removidos. Observe o seguinte:
-
Os igroups migrados não podem ser reutilizados em diferentes datastores.
-
Igroups personalizados (definidos pelo usuário) nunca são excluídos e ainda podem ser reutilizados.
Políticas de exportação
As políticas de exportação controlam o acesso ao datastore NFS e as permissões do cliente em ONTAP tools for VMware vSphere. As políticas de exportação são criadas e gerenciadas em sistemas ONTAP e podem ser usadas com 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 permissão de acesso e as permissões concedidas (somente leitura ou leitura e gravação).
Ao criar um datastore NFS nas ONTAP tools for 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 datastore, garantindo que apenas clientes autorizados possam acessá-lo.
Ao montar um datastore NFS em um novo host ESXi, ONTAP tools for VMware vSphere adiciona o endereço IP do host à política de exportação existente associada ao datastore. Isso permite que o novo host acesse o datastore sem criar uma nova política de exportação.
Ao excluir ou desmontar um NFS datastore de um host ESXi, 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 NFS datastore, ONTAP tools for VMware vSphere remove a política de exportação associada a esse datastore, caso ela não seja reutilizada por nenhum outro datastore. Se a política de exportação for reutilizada, ela mantém o endereço IP do host e não é alterada. Ao excluir os datastores, 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 datastores. Ao reutilizar a política de exportação, você pode adicionar o novo endereço IP do host à política. Quando você exclui ou desmonta um datastore 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 datastores. A reutilização de políticas de exportação não é recomendada, pois pode causar problemas de acesso e latência.