Máquinas virtuais de armazenamento (SVMs) fornecem isolamento e separação administrativa entre locatários em um sistema ONTAP . Dedicar uma SVM a aplicações permite a delegação de privilégios e a aplicação das melhores práticas para limitar o consumo de recursos.

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

Em todos os casos, a interface deve estar no DNS e o nome DNS deve ser usado ao configurar o Trident. Isso ajuda a facilitar alguns cenários de recuperação de desastres (DR), por exemplo, SVM-DR sem a necessidade 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 escolhida. Independentemente disso, o LIF de gerenciamento deve ser acessível via DNS para facilitar a máxima flexibilidade. "SVM-DR" Pode ser usado em conjunto com o Trident.

Os sistemas de armazenamento ONTAP possuem um número máximo de volumes, que varia de acordo com a versão do software e a plataforma de hardware. Consulte "Hardware Universe da NetApp" Para determinar os limites exatos, consulte a plataforma específica e a versão do ONTAP . Quando o número de volumes disponíveis se esgota, as operações de provisionamento falham não apenas para o Trident, mas para todas as solicitações de armazenamento.

Tridente ontap-nas e ontap-san Os drivers provisionam um FlexVolume para cada Volume Persistente (PV) do Kubernetes que é criado. O ontap-nas-economy O driver cria aproximadamente um FlexVolume para cada 200 PVs (configurável entre 50 e 300). O ontap-san-economy O driver 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 armazenamento, você deve definir um limite no SVM. Você pode fazer isso na linha de comando:

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

O max-volumes O valor representa 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 condições em que um nó de cluster ONTAP pode ter muito mais ou menos volumes provisionados Trident do que outro nó.

Por exemplo, um cluster ONTAP de dois nós tem a capacidade de hospedar um máximo de 2000 volumes FlexVol . Definir o número máximo de volumes em 1250 parece bastante razoável. No entanto, se apenas "agregados" Se os volumes atribuídos a partir de um nó forem alocados ao SVM, ou se os agregados atribuídos a partir de um nó não puderem ser provisionados (por exemplo, devido à capacidade), o outro nó se torna o destino de todos os volumes provisionados Trident . Isso significa que o limite de volume pode ser atingido para esse nó antes do max-volumes O valor é atingido, impactando tanto o Trident quanto 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 ao SVM usado pelo Trident em números iguais.

O NetApp Trident suporta a clonagem de volumes ao usar o ontap-nas , ontap-san , solidfire-san , e gcp-cvs drivers de armazenamento. Ao usar o ontap-nas-flexgroup ou ontap-nas-economy Drivers, 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 dos volumes que podem ser criados pelo Trident, use o limitVolumeSize parâmetro em seu backend.json definição.

Além de controlar o tamanho do volume no array de armazenamento, você também deve aproveitar os recursos do Kubernetes.

Para configurar o tamanho máximo dos FlexVols usados como pools para os drivers ontap-san-economy e ontap-nas-economy, utilize o limitVolumePoolSize parâmetro em seu 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 configurar o Trident para habilitar o CHAP na SVM. Usando o useCHAP Ao configurar o parâmetro na sua configuração de backend, o Trident autentica as conexões iSCSI para backends ONTAP com CHAP.

Utilizando uma política de QoS do ONTAP , aplicada ao SVM, limita-se o número de IOPS que podem ser consumidos pelos volumes provisionados Trident . Isso ajuda a "prevenir um valentão" ou um contêiner fora de controle que afete cargas de trabalho fora do Trident SVM.

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

Além disso, se a sua versão do ONTAP suportar, você pode considerar usar um mínimo de QoS para garantir uma quantidade de throughput para cargas de trabalho em contêineres. A QoS adaptativa 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 fatores. Entre outras coisas, isso inclui:

É importante lembrar que uma política de QoS atribuída no nível da SVM resulta em todos os volumes provisionados para a SVM compartilhando o mesmo pool de IOPS. Se uma, ou um pequeno número, das aplicações conteinerizadas tiverem uma alta exigência de IOPS, isso poderá sobrecarregar as outras cargas de trabalho conteinerizadas. Nesse caso, você pode considerar usar automação externa para atribuir políticas de QoS por volume.

A Qualidade de 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 obter mais informações sobre QoS, consulte: "Garantindo a taxa de transferência com QoS" . Você pode especificar grupos de políticas de QoS no backend ou em um pool de armazenamento, e eles serão aplicados a cada volume criado nesse pool ou backend.

O ONTAP possui dois tipos de grupos de políticas de QoS: tradicionais e adaptativos. Os grupos de políticas tradicionais fornecem uma taxa de transferência máxima (ou mínima, em versões posteriores) fixa em IOPS. O QoS adaptativo 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 à medida que o tamanho da carga de trabalho muda. Isso proporciona uma vantagem significativa ao gerenciar centenas ou milhares de cargas de trabalho em uma implantação de grande porte.

Ao criar grupos de políticas de QoS, considere o seguinte:

Para obter mais informações sobre grupos de políticas de 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 evita que hosts que não fazem parte do cluster do Kubernetes acessem os volumes e potencialmente modifiquem dados inesperadamente.

É importante entender que os namespaces são o limite lógico para recursos no Kubernetes. A premissa é que os recursos no mesmo espaço de nomes podem ser compartilhados; no entanto, é importante ressaltar que não há capacidade de compartilhamento entre espaços de nomes diferentes. Isso significa que, embora os PVs sejam objetos globais, quando vinculados a um PVC, eles só são acessíveis 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 projetadas para evitar esse tipo de comprometimento. No entanto, existe uma exceção: os 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 opções não são negadas por padrão, portanto, certifique-se de desativar a funcionalidade usando "políticas de segurança de 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 (Volume de Processo) introduzido pelo administrador e não gerenciado pelo Trident. Isso garante que o volume de armazenamento seja destruído somente quando o Kubernetes e os hosts externos estiverem desconectados e não estiverem mais usando o volume. Além disso, é possível aplicar uma política de exportação personalizada, que permite o acesso a partir dos nós do cluster Kubernetes e de servidores de destino 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 armazenamento. 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 OpenShift Metrics e Logging) e aplicativos padrão que são implantados em nós que não são de 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. O Trident pode criar e gerenciar automaticamente políticas de exportação. Dessa forma, o Trident limita o acesso aos volumes que provisiona aos nós no cluster Kubernetes e simplifica a adição/exclusã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 restringir quais nós do Kubernetes têm acesso aos dados.

O showmount Esse recurso permite que um cliente NFS consulte a SVM para obter uma lista de exportações NFS disponíveis. Um pod implantado no cluster Kubernetes pode emitir o showmount -e Comande o inimigo e receba uma lista de montarias disponíveis, incluindo aquelas às quais ele 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 uma exportação NFS.

Você deve desativar showmount utilizando 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 Protocolo de Autenticação por Desafio e Aperto de Mão (CHAP). Você pode acessar os 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 só pode pertencer a uma conta.

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

Você pode definir parâmetros de QoS para cada volume individualmente. O desempenho de cada volume pode ser garantido definindo três parâmetros configuráveis que definem a QoS: IOPS mínimo, IOPS máximo e IOPS de rajada.

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

O tamanho do bloco e a largura de banda influenciam diretamente o número de IOPS. À medida que o tamanho dos blocos aumenta, 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 consegue atingir diminui. Consulte "Qualidade de serviço SolidFire" Para obter mais informações sobre QoS e desempenho.

O Element suporta dois métodos de autenticação: CHAP e Grupos de Acesso por Volume (VAG). O CHAP utiliza o protocolo CHAP para autenticar o host no servidor de backend. Os Grupos de Acesso a Volumes controlam o acesso aos volumes que provisionam. A 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 do volume pretendido) é 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 então o host autentica o volume por meio do nome da conta e do segredo do destino.

No entanto, se o CHAP não puder ser ativado 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 adicionado a um grupo de acesso pode acessar todos os volumes 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á utilizado. Se o iniciador iSCSI não estiver configurado para usar autenticação CHAP, o controle de acesso do Grupo de Acesso ao Volume será utilizado.