Os drivers de backend do ONTAP são diferenciados pelo protocolo utilizado e pela forma como os volumes são provisionados no sistema de storage. Portanto, considere cuidadosamente qual driver implantar.

Em um nível mais alto, se sua aplicação possui componentes que precisam de storage compartilhado (vários pods acessando o mesmo PVC), os drivers baseados em NAS seriam a escolha padrão, enquanto os drivers iSCSI baseados em bloco atendem às necessidades de storage não compartilhado. Escolha o protocolo com base nos requisitos da aplicação e no nível de familiaridade das equipes de storage e infraestrutura. De modo geral, há pouca diferença entre eles para a maioria das aplicações, então, frequentemente, a decisão se baseia na necessidade ou não de storage compartilhado (onde mais de um pod precisará de acesso simultâneo).

Os drivers de backend ONTAP disponíveis são:

A escolha entre os três drivers NAS tem algumas ramificações nos recursos que são disponibilizados para o aplicativo.

Observe que, nas tabelas abaixo, nem todos os recursos são expostos pelo Trident. Alguns devem ser aplicados pelo administrador de storage após o provisionamento, caso essa funcionalidade seja desejada. As notas de rodapé em sobrescrito distinguem a funcionalidade por recurso e driver.

Trident oferece 2 drivers SAN para ONTAP, cujas capacidades são apresentadas abaixo.

As funcionalidades que não são granulares em relação ao PV são aplicadas a todo o FlexVolume e todos os PVs (ou seja, qtrees ou LUNs em FlexVols compartilhados) compartilharão um agendamento comum.

Como podemos ver nas tabelas acima, grande parte da funcionalidade entre o ontap-nas e o ontap-nas-economy é a mesma. No entanto, como o driver ontap-nas-economy limita a capacidade de controlar o agendamento na granularidade por PV, isso pode afetar especialmente o seu planejamento de recuperação de desastres e backup. Para equipes de desenvolvimento que desejam aproveitar a funcionalidade de clonagem de PVC no armazenamento ONTAP, isso só é possível ao usar os drivers ontap-nas, ontap-san ou ontap-san-economy.

Cloud Volumes ONTAP oferece controle de dados juntamente com recursos de armazenamento de nível empresarial para diversos casos de uso, incluindo compartilhamento de arquivos e armazenamento em nível de bloco, atendendo a protocolos NAS e SAN (NFS, SMB / CIFS e iSCSI). Os drivers compatíveis para Cloud Volume ONTAP são ontap-nas, ontap-nas-economy, ontap-san e ontap-san-economy. Estes são aplicáveis para Cloud Volume ONTAP para Azure, Cloud Volume ONTAP para GCP.

Amazon FSx for NetApp ONTAP permite que você aproveite os recursos, o desempenho e as capacidades administrativas do NetApp com os quais você já está familiarizado, enquanto aproveita a simplicidade, agilidade, segurança e escalabilidade de armazenar dados na AWS. FSx for ONTAP oferece suporte a muitos recursos do sistema de arquivos ONTAP e APIs de administração. Os drivers compatíveis para Cloud Volume ONTAP são ontap-nas, ontap-nas-economy, ontap-nas-flexgroup, ontap-san e ontap-san-economy.

O solidfire-san driver usado com as plataformas NetApp HCI/SolidFire ajuda o administrador a configurar um backend Element para Trident com base em limites de QoS. Se você deseja projetar seu backend para definir limites de QoS específicos nos volumes provisionados pelo Trident, use o parâmetro type no arquivo de backend. O administrador também pode restringir o tamanho do volume que pode ser criado no storage usando o parâmetro limitVolumeSize. Atualmente, recursos de storage do Element, como redimensionamento e replicação de volumes, não são suportados pelo driver solidfire-san. Essas operações devem ser realizadas manualmente por meio da interface web do Element Software.

Trident usa o azure-netapp-files driver para gerenciar o serviço "Azure NetApp Files".

Mais informações sobre este driver e como configurar podem ser encontradas em "Configuração do backend Trident para Azure NetApp Files".

A filtragem pode ser usada dentro de um objeto de classe de armazenamento específico para determinar qual pool de storage ou conjunto de pools deve ser usado com essa classe de armazenamento específica. Três conjuntos de filtros podem ser definidos na Storage Class: storagePools, additionalStoragePools, e/ou excludeStoragePools.

O storagePools parâmetro ajuda a restringir o armazenamento ao conjunto de pools que correspondem a quaisquer atributos especificados. O additionalStoragePools parâmetro é usado para estender o conjunto de pools que Trident usa para provisionamento junto com o conjunto de pools selecionados pelos atributos e storagePools parâmetros. Você pode usar qualquer um dos parâmetros individualmente ou ambos juntos para garantir que o conjunto apropriado de pools de armazenamento seja selecionado.

O `excludeStoragePools`parâmetro é usado para excluir especificamente o conjunto listado de pools que correspondem aos atributos.

Se você deseja projetar classes de armazenamento para emular políticas de Qualidade de Serviço, crie uma classe de armazenamento com o media atributo como hdd ou ssd. Com base no media atributo mencionado na storage class, Trident selecionará o backend apropriado que serve hdd ou ssd agregados para corresponder ao atributo de mídia e então direcionará o provisionamento dos volumes para o agregado específico. Portanto, podemos criar uma storage class PREMIUM que teria o media atributo definido como ssd, que poderia ser classificada como a política de QoS PREMIUM. Podemos criar outra storage class STANDARD que teria o atributo de mídia definido como hdd, que poderia ser classificada como a política de QoS STANDARD. Também podemos usar o atributo IOPS na storage class para redirecionar o provisionamento para um appliance Element, que pode ser definido como uma política de QoS.

As classes de armazenamento podem ser projetadas para direcionar o provisionamento de volumes em um backend específico, onde recursos como provisionamento thin e thick, snapshots, clones e criptografia estão habilitados. Para especificar qual storage usar, crie Storage Classes que especifiquem o backend apropriado com o recurso necessário habilitado.

Pools virtuais estão disponíveis para todos os backends do Trident. Você pode definir pools virtuais para qualquer backend, usando qualquer driver que o Trident fornece.

Os pools virtuais permitem que um administrador crie um nível de abstração sobre backends que podem ser referenciados por meio de Storage Classes, para maior flexibilidade e alocação eficiente de volumes nos backends. Diferentes backends podem ser definidos com a mesma classe de serviço. Além disso, vários storage pools podem ser criados no mesmo backend, mas com características diferentes. Quando uma Storage Class é configurada com um seletor com rótulos específicos, Trident escolhe um backend que corresponda a todos os rótulos do seletor para alocar o volume. Se os rótulos do seletor da Storage Class corresponderem a vários storage pools, Trident escolherá um deles para provisionar o volume.

É possível projetar pools virtuais para emular classes de serviço. Usando a implementação de pool virtual para Cloud Volume Service for Azure NetApp Files, vamos examinar como podemos configurar diferentes classes de serviço. Configure o backend do Azure NetApp Files com vários rótulos, representando diferentes níveis de desempenho. Defina o aspecto servicelevel para o nível de desempenho apropriado e adicione outros aspectos necessários sob cada rótulo. Agora crie diferentes Storage Classes do Kubernetes que serão mapeadas para diferentes pools virtuais. Usando o campo parameters.selector, cada StorageClass especifica quais pools virtuais podem ser usados para hospedar um volume.

É possível projetar vários pools virtuais com um conjunto específico de aspectos a partir de um único backend de armazenamento. Para fazer isso, configure o backend com vários rótulos e defina os aspectos necessários em cada rótulo. Agora crie diferentes classes de armazenamento do Kubernetes usando o parameters.selector campo que mapeará para diferentes pools virtuais. Os volumes provisionados no backend terão os aspectos definidos no pool virtual escolhido.

Alguns parâmetros além da classe de armazenamento solicitada podem afetar o processo de decisão de provisionamento do Trident ao criar um PVC.

Ao solicitar armazenamento por meio de um PVC, um dos campos obrigatórios é o modo de acesso. O modo desejado pode afetar o backend selecionado para hospedar a solicitação de armazenamento.

Trident tentará encontrar uma correspondência entre o protocolo de storage utilizado e o método de acesso especificado, de acordo com a seguinte matriz. Isso é independente da plataforma de storage subjacente.

Uma solicitação de um ReadWriteMany PVC enviada a uma implantação do Trident sem um backend NFS configurado resultará em nenhum volume sendo provisionado. Por esse motivo, o solicitante deve usar o modo de acesso apropriado para sua aplicação.

Os volumes persistentes são, com duas exceções, objetos imutáveis no Kubernetes. Uma vez criados, a política de recuperação e o tamanho podem ser modificados. No entanto, isso não impede que alguns aspectos do volume sejam modificados fora do Kubernetes. Isso pode ser desejável para personalizar o volume para aplicações específicas, garantir que a capacidade não seja consumida acidentalmente ou simplesmente mover o volume para um controlador de storage diferente por qualquer motivo.

Os detalhes de conexão do PV não podem ser modificados após a criação.

Trident suporta a criação de snapshots de volumes sob demanda e a criação de PVCs a partir de snapshots usando a estrutura CSI. Os snapshots fornecem um método conveniente para manter cópias dos dados em um ponto no tempo e têm um ciclo de vida independente do PV de origem no Kubernetes. Esses snapshots podem ser usados para clonar PVCs.

Trident também suporta a criação de PersistentVolumes a partir de snapshots de volume. Para isso, basta criar um PersistentVolumeClaim e mencionar o datasource como o snapshot necessário a partir do qual o volume precisa ser criado. Trident gerenciará esse PVC criando um volume com os dados presentes no snapshot. Com esse recurso, é possível duplicar dados entre regiões, criar ambientes de teste, substituir um volume de produção danificado ou corrompido por completo ou recuperar arquivos e diretórios específicos e transferi-los para outro volume conectado.

Os administradores de storage têm a capacidade de mover volumes entre agregados e controladores no cluster ONTAP de forma não disruptiva para o consumidor de storage. Essa operação não afeta o Trident nem o cluster Kubernetes, desde que o agregado de destino seja um ao qual a SVM que o Trident está utilizando tenha acesso. É importante ressaltar que, se o agregado foi adicionado recentemente à SVM, o backend precisará ser atualizado ao ser readicionado ao Trident. Isso fará com que o Trident faça um novo inventário da SVM para que o novo agregado seja reconhecido.

No entanto, a movimentação de volumes entre backends não é suportada automaticamente pelo Trident. Isso inclui entre SVMs no mesmo cluster, entre clusters ou para uma plataforma de storage diferente (mesmo que esse sistema de storage esteja conectado ao Trident).

Se um volume for copiado para outro local, o recurso de importação de volume pode ser usado para importar volumes atuais para Trident.

Trident suporta o redimensionamento de PVs NFS, iSCSI e FC. Isso permite que os usuários redimensionem seus volumes diretamente pela camada Kubernetes. A expansão de volumes é possível para todas as principais plataformas de storage NetApp, incluindo ONTAP, e backends SolidFire/NetApp HCI. Para permitir uma possível expansão futura, defina allowVolumeExpansion como true no seu StorageClass associado ao volume. Sempre que o Persistent Volume precisar ser redimensionado, edite a anotação spec.resources.requests.storage no Persistent Volume Claim para o tamanho de volume necessário. Trident cuidará automaticamente do redimensionamento do volume no cluster de storage.

A importação de volumes permite importar um volume de armazenamento existente para um ambiente Kubernetes. Atualmente, isso é suportado pelos ontap-nas, ontap-nas-flexgroup, solidfire-san e azure-netapp-files drivers. Esse recurso é útil ao migrar um aplicativo existente para o Kubernetes ou em cenários de recuperação de desastres.

Ao usar os drivers ONTAP e solidfire-san, utilize o comando tridentctl import volume <backend-name> <volume-name> -f /path/pvc.yaml para importar um volume existente para o Kubernetes para ser gerenciado pelo Trident. O arquivo PVC YAML ou JSON usado no comando de importação de volume aponta para uma storage class que identifica o Trident como o provisionador. Ao usar um backend NetApp HCI/SolidFire, certifique-se de que os nomes dos volumes sejam únicos. Se os nomes dos volumes estiverem duplicados, clone o volume para um nome único para que o recurso de importação de volume possa distingui-los.

Se o azure-netapp-files driver for utilizado, use o comando tridentctl import volume <backend-name> <volume path> -f /path/pvc.yaml para importar o volume para o Kubernetes para ser gerenciado pelo Trident. Isso garante uma referência de volume exclusiva.

Ao executar o comando acima, Trident localizará o volume no backend e lerá seu tamanho. Ele adicionará automaticamente (e sobrescreverá, se necessário) o tamanho do volume do PVC configurado. Em seguida, Trident cria o novo PV e o Kubernetes vincula o PVC ao PV.

Se um contêiner foi implantado de forma que exigisse o PVC importado específico, ele permanecerá em estado pendente até que o par PVC/PV seja vinculado por meio do processo de importação de volume. Após a vinculação do par PVC/PV, o contêiner deverá ser iniciado, desde que não haja outros problemas.

A implantação e o gerenciamento do armazenamento para o registro foram documentados em "netapp.io" no "blog".

Assim como outros OpenShift serviços, o serviço de registro de logs é implantado usando o Ansible com parâmetros de configuração fornecidos pelo arquivo de inventário, também conhecido como hosts, fornecido ao playbook. Há dois métodos de instalação que serão abordados: implantar o serviço de registro de logs durante a instalação inicial do OpenShift e implantar o serviço de registro de logs após o OpenShift ter sido instalado.

Se optar por usar NFS com o serviço de registro de logs, você precisará definir a variável Ansible openshift_enable_unsupported_configurations para true evitar que o instalador falhe.

Com as variáveis Ansible apropriadas definidas no seu arquivo hosts/inventory, implante o serviço usando Ansible. Se você estiver implantando no momento da instalação do OpenShift, o PV será criado e usado automaticamente. Se estiver implantando usando os playbooks de componentes, após a instalação do OpenShift, o Ansible criará todos os PVCs necessários e, depois que Trident provisionar storage para eles, implantará o serviço.

As variáveis acima e o processo de implantação podem mudar a cada versão do OpenShift. Certifique-se de revisar e seguir "Guia de implantação da Red Hat's OpenShift" para a sua versão para que esteja configurado para o seu ambiente.