As Storage Virtual Machines (SVMs) fornecem isolamento e separação administrativa entre os tenants em um sistema ONTAP. Dedicar uma SVM a aplicativos permite a delegação de privilégios e possibilita aplicar as melhores práticas para limitar o consumo de recursos.

Existem diversas opções disponíveis para o gerenciamento da SVM:

Em cada caso, a interface deve estar no DNS e o nome DNS deve ser usado ao configurar Trident. Isso ajuda a facilitar alguns cenários de DR, por exemplo, SVM-DR sem o uso de retenção de identidade de rede.

Não há preferência entre ter uma LIF de gerenciamento dedicada ou compartilhada para a SVM, no entanto, você deve garantir que suas políticas de segurança de rede estejam alinhadas com a abordagem que você escolher. Independentemente disso, a LIF de gerenciamento deve ser acessível via DNS para facilitar a máxima flexibilidade caso "SVM-DR" seja usada em conjunto com Trident.

Os sistemas de storage ONTAP têm uma contagem de volume máxima, que varia de acordo com a versão do software e a plataforma de hardware. Consulte "NetApp Hardware Universe" para sua plataforma específica e versão do ONTAP para determinar os limites exatos. Quando a contagem de volume é atingida, as operações de provisionamento falham não apenas para Trident, mas para todas as solicitações de storage.

Os drivers do Trident ontap-nas e ontap-san provisionam um FlexVolume para cada Persistent Volume (PV) do Kubernetes criado. O driver ontap-nas-economy cria aproximadamente um FlexVolume para cada 200 PVs (configurável entre 50 e 300). O driver ontap-san-economy cria aproximadamente um FlexVolume para cada 100 PVs (configurável entre 50 e 200). Para evitar que o Trident consuma todos os volumes disponíveis no sistema de storage, você deve definir um limite no SVM. Você pode fazer isso pela linha de comando:

O valor para max-volumes varia de acordo com diversos critérios específicos do seu ambiente:

O max-volumes valor é o total de volumes provisionados em todos os nós do cluster ONTAP, e não em um nó ONTAP individual. Como resultado, você pode encontrar algumas situações em que um nó de cluster ONTAP pode ter muito mais ou muito menos volumes provisionados pelo Trident do que outro nó.

Por exemplo, um cluster ONTAP de dois nós tem a capacidade de hospedar um máximo de 2000 FlexVol volumes. Ter a contagem máxima de volume definida para 1250 parece muito razoável. No entanto, se apenas "agregados" de um nó forem atribuídos à SVM, ou se os agregados atribuídos de um nó não puderem ser provisionados (por exemplo, devido à capacidade), então o outro nó se torna o destino para todos os volumes provisionados pelo Trident. Isso significa que o limite de volume pode ser atingido para esse nó antes que o valor max-volumes seja alcançado, resultando em impacto tanto para o Trident quanto para outras operações de volume que utilizam esse nó. Você pode evitar essa situação garantindo que os agregados de cada nó do cluster sejam atribuídos à SVM usada pelo Trident em números iguais.

NetApp Trident suporta clonagem de volumes ao usar os ontap-nas, ontap-san e solidfire-san drivers de armazenamento. Ao usar os ontap-nas-flexgroup ou ontap-nas-economy drivers, a clonagem não é suportada. Criar um novo volume a partir de um volume existente resultará na criação de um novo snapshot.

Para configurar o tamanho máximo para volumes que podem ser criados pelo Trident, use o limitVolumeSize parâmetro na sua backend.json definição.

Além de controlar o tamanho do volume no array de storage, você também deve aproveitar as capacidades do Kubernetes.

Para configurar o tamanho máximo dos FlexVols usados como pools para os drivers ontap-san-economy e ontap-nas-economy, use o limitVolumePoolSize parâmetro na sua backend.json definição.

Você pode especificar os nomes de usuário e senhas do iniciador e do destino CHAP na definição do seu backend e fazer com que Trident habilite o CHAP na SVM. Usando o useCHAP parâmetro na configuração do seu backend, Trident autentica as conexões iSCSI para backends ONTAP com CHAP.

Ao utilizar uma política de qualidade do serviço (QoS) do ONTAP, aplicada à SVM, limita-se o número de IOPS consumíveis pelos volumes provisionados pelo Trident. Isso ajuda a "prevenir um agressor" evitar que um contêiner descontrolado afete cargas de trabalho fora da SVM do Trident.

Você pode criar uma política de QoS para a SVM em algumas etapas. Consulte a documentação da sua versão do ONTAP para as informações mais precisas. O exemplo abaixo cria uma política de QoS que limita o total de IOPS disponível para a SVM a 5000.

Além disso, se a sua versão do ONTAP for compatível, você pode considerar o uso de um QoS mínimo para garantir uma quantidade de largura de banda para cargas de trabalho em contêineres. O QoS adaptável não é compatível com uma política de nível SVM.

O número de IOPS dedicados às cargas de trabalho em contêineres depende de muitos aspectos. Entre outras coisas, incluem:

É importante lembrar que uma política de QoS atribuída no nível da SVM resulta em todos os volumes provisionados para a SVM compartilharem o mesmo pool de IOPS. Se uma, ou um pequeno número, das aplicações conteinerizadas tiver uma alta necessidade de IOPS, ela pode se tornar um problema para as outras cargas de trabalho conteinerizadas. Se for esse o caso, talvez você queira considerar o uso de automação externa para atribuir políticas de QoS por volume.

A qualidade do serviço (QoS) garante que o desempenho de cargas de trabalho críticas não seja prejudicado por cargas de trabalho concorrentes. Os grupos de políticas de QoS do ONTAP fornecem opções de QoS para volumes e permitem que os usuários definam o limite de taxa de transferência para uma ou mais cargas de trabalho. Para mais informações sobre QoS, consulte "Garantindo a taxa de transferência com qualidade do serviço". Você pode especificar grupos de políticas de QoS no backend ou em um pool de storage, e eles são aplicados a cada volume criado nesse pool ou backend.

ONTAP possui dois tipos de grupos de políticas de qualidade do serviço: tradicional e adaptável. Os grupos de políticas tradicionais fornecem uma taxa máxima (ou mínima, em versões posteriores) de IOPS fixa. A qualidade do serviço adaptável dimensiona automaticamente a taxa de transferência de acordo com o tamanho da carga de trabalho, mantendo a proporção de IOPS para TBs|GBs conforme o tamanho da carga de trabalho muda. Isso proporciona uma vantagem significativa ao gerenciar centenas ou milhares de cargas de trabalho em uma grande implementação.

Considere o seguinte ao criar grupos de políticas de QoS:

Para obter mais informações sobre grupos de políticas de qualidade do serviço (QoS), consulte "Referência de comandos ONTAP".

Limitar o acesso aos volumes NFS, LUNs iSCSI e LUNs FC criados pelo Trident é um componente crítico da postura de segurança da sua implementação do Kubernetes. Isso impede que hosts que não fazem parte do cluster Kubernetes acessem os volumes e potencialmente modifiquem dados inesperadamente.

É importante entender que os namespaces são o limite lógico para os recursos no Kubernetes. A premissa é que recursos no mesmo namespace podem ser compartilhados, no entanto, é importante ressaltar que não existe capacidade entre namespaces diferentes. Isso significa que, mesmo que os PVs sejam objetos globais, quando vinculados a um PVC, eles só podem ser acessados por pods que estejam no mesmo namespace. É fundamental garantir que os namespaces sejam usados para fornecer separação quando apropriado.

A principal preocupação da maioria das organizações em relação à segurança de dados em um contexto Kubernetes é que um processo em um contêiner possa acessar o armazenamento montado no host, mas que não se destina ao contêiner. "Espaços de nomes" são projetados para evitar esse tipo de comprometimento. No entanto, há uma exceção: contêineres privilegiados.

Um contêiner privilegiado é aquele que é executado com permissões de nível de host substancialmente maiores do que o normal. Essas permissões não são negadas por padrão, portanto, certifique-se de desativar a capacidade usando "políticas de segurança do pod".

Para volumes onde o acesso é desejado tanto do Kubernetes quanto de hosts externos, o armazenamento deve ser gerenciado de maneira tradicional, com o PV introduzido pelo administrador e não gerenciado pelo Trident. Isso garante que o volume de armazenamento seja destruído somente quando tanto o Kubernetes quanto os hosts externos estiverem desconectados e não estiverem mais utilizando o volume. Além disso, uma política de exportação personalizada pode ser aplicada, permitindo o acesso a partir dos nós do cluster Kubernetes e de servidores direcionados fora do cluster Kubernetes.

Para implantações que possuem nós de infraestrutura dedicados (por exemplo, OpenShift) ou outros nós que não conseguem agendar aplicativos de usuário, políticas de exportação separadas devem ser usadas para limitar ainda mais o acesso aos recursos de storage. Isso inclui a criação de uma política de exportação para serviços que são implantados nesses nós de infraestrutura (por exemplo, os serviços de Métricas e Registro do OpenShift), e para aplicativos padrão que são implantados em nós que não fazem parte da infraestrutura.

Você deve garantir que exista uma política de exportação para cada backend que permita acesso apenas aos nós presentes no cluster Kubernetes. Trident pode criar e gerenciar políticas de exportação automaticamente. Dessa forma, Trident limita o acesso aos volumes que provisiona aos nós do cluster Kubernetes e simplifica a adição/remoção de nós.

Alternativamente, você também pode criar uma política de exportação manualmente e preenchê-la com uma ou mais regras de exportação que processem cada solicitação de acesso ao nó:

Executar esses comandos permite que você restrinja quais nós do Kubernetes têm acesso aos dados.

O showmount recurso permite que um cliente NFS consulte a SVM para obter uma lista de exports NFS disponíveis. Um pod implantado no cluster Kubernetes pode executar o showmount -e comando contra a SVM e receber uma lista de montagens disponíveis, incluindo aquelas às quais não tem acesso. Embora isso, por si só, não represente uma falha de segurança, fornece informações desnecessárias que podem auxiliar um usuário não autorizado a se conectar a um export NFS.

Você deve desativar showmount usando o comando ONTAP CLI em nível de SVM:

Cada conta SolidFire representa um proprietário de volume único e recebe seu próprio conjunto de credenciais do Challenge-Handshake Authentication Protocol (CHAP). Você pode acessar volumes atribuídos a uma conta usando o nome da conta e as credenciais CHAP correspondentes ou por meio de um grupo de acesso a volumes. Uma conta pode ter até dois mil volumes atribuídos a ela, mas um volume pode pertencer a apenas uma conta.

Utilize as políticas de qualidade do serviço (QoS) do SolidFire se você quiser criar e salvar uma configuração padronizada de qualidade do serviço que pode ser aplicada a vários volumes.

Você pode definir parâmetros de qualidade do serviço em uma base por volume. O desempenho de cada volume pode ser garantido definindo três parâmetros configuráveis que definem a qualidade do serviço: Min IOPS, Max IOPS e Burst IOPS.

Aqui estão os possíveis valores mínimos, máximos e de burst de IOPS para o tamanho de bloco de 4Kb.

O tamanho do bloco e a largura de banda têm influência direta sobre o número de IOPS. À medida que os tamanhos dos blocos aumentam, o sistema aumenta a largura de banda para um nível necessário para processar os blocos maiores. À medida que a largura de banda aumenta, o número de IOPS que o sistema é capaz de atingir diminui. Consulte "Qualidade do serviço do SolidFire" para mais informações sobre QoS e desempenho.

O Element suporta dois métodos de autenticação: CHAP e Grupos de Acesso a Volumes (VAG). CHAP utiliza o protocolo CHAP para autenticar o host no backend. Grupos de Acesso a Volumes controla o acesso aos volumes que provisiona. NetApp recomenda o uso do CHAP para autenticação, pois é mais simples e não possui limites de escalabilidade.

A autenticação CHAP (verificação de que o iniciador é o usuário pretendido do volume) é suportada apenas com controle de acesso baseado em conta. Se você estiver usando CHAP para autenticação, duas opções estão disponíveis: CHAP unidirecional e CHAP bidirecional. O CHAP unidirecional autentica o acesso ao volume usando o nome da conta SolidFire e o segredo do iniciador. A opção CHAP bidirecional oferece a maneira mais segura de autenticar o volume, pois o volume autentica o host por meio do nome da conta e do segredo do iniciador e, em seguida, o host autentica o volume por meio do nome da conta e do segredo de destino.

No entanto, se o CHAP não puder ser habilitado e os VAGs forem necessários, crie o grupo de acesso e adicione os iniciadores de host e os volumes ao grupo de acesso. Cada IQN que você adicionar a um grupo de acesso pode acessar cada volume do grupo com ou sem autenticação CHAP. Se o iniciador iSCSI estiver configurado para usar autenticação CHAP, o controle de acesso baseado em conta será usado. Se o iniciador iSCSI não estiver configurado para usar autenticação CHAP, então o controle de acesso do Volume Access Group será usado.