Trident: Os drivers ontap devem ter um posicionamento de volume mais inteligente

Criado em 17 out. 2017 · 6Comentários · Fonte: NetApp/trident

A colocação de flexvols pelo driver ontap-nas-economy precisa ser mais inteligente. As seguintes sugestões são feitas como ponto de partida, com base no feedback do cliente para um ambiente de grande escala:

Permitir que o Trident seja configurado para que continuemos a provisionar qtrees em um flexvol até que a agregação subjacente tenha X porcentagem cheia ou Y porcentagem com excesso de assinatura.
Se vários agregados forem definidos, prefira usar o agregado que tiver mais espaço livre e menos subscrição.
Embora #1 e #2 sejam mais importantes no curto prazo, em algum momento também seria desejável que o provisionamento levasse em consideração o headroom do nó.

enhancement tracked

Fonte

arndt-netapp

Todos 6 comentários

Para ser claro, a maioria deles se aplicaria a todos os drivers ONTAP. O planejador Trident é definitivamente um ambiente de destino rico.

clintonk em 17 out. 2017

Marcarei com +1 esta solicitação em nome de muitas interações que tive e adicionarei alguns itens adicionais. Muitas vezes, são solicitados vários recursos em torno da lógica de seleção do pool de armazenamento:

Ser capaz de excluir pools de armazenamento usando a definição de classe de armazenamento. Por exemplo, "Eu quero tudo flash (media=ssd), exceto para AFF aggr1 e política SF QoS Bronze." Atualmente, o único mecanismo para fazer isso é fazer o inverso, onde todos os conjuntos de armazenamento, exceto os que serão excluídos, são especificados na classe de armazenamento.
Um mecanismo para interromper o provisionamento de novas solicitações de PVC em um pool de armazenamento quando o dispositivo de armazenamento subjacente (por exemplo, um agregado ONTAP) atinge um nível arbitrário de "completo". Isso pode/deve ser baseado na capacidade real/real restante, bem como em uma taxa/porcentagem de sobre assinatura.
Permitir a especificação de um limite de capacidade arbitrário para um determinado back-end. Por exemplo, com o ONTAP, independentemente do tamanho real de um agregado, o Trident só pode consumir X GiB dessa capacidade. O mesmo princípio se aplicaria ao SolidFire, embora o paradigma pudesse ser estendido não apenas para GiB, mas também para IOPS (mínimos de QoS, especificamente).
Aproveite o AppDM como um back-end.
Aproveite o Service Level Manager como um back-end.
Incorpore a capacidade de desempenho do ONTAP como uma métrica de seleção do pool de armazenamento.

acsulli em 5 abr. 2018

👍1

Bem, se falarmos sobre lógica de posicionamento, adicionarei mais alguns itens a serem considerados (com base nos requisitos reais do cliente):

Número de volumes em um nó (já que o Ontap tem limites lógicos que você não deseja exceder)
Nó que contém o LIF para o SVM (para evitar acesso indireto a dados para melhor desempenho)
IOPS provisionado (via conceito de QoS adaptável) no nó/agregado

Combinados com os pontos já mencionados por outros e ponderados e ordenados de acordo com os requisitos específicos do cliente.

No final, precisaríamos de um mecanismo de regras personalizável no tridente ou de um mecanismo flexível para anexar outras ferramentas. Se decidirmos seguir com o posterior, eu votaria no WFA além do AppDM e do NSLM que já foram mencionados, já que (hoje) é a única ferramenta flexível o suficiente para construir uma solução personalizada que leva todos os itens acima itens em consideração.

hendrikland em 13 abr. 2018

+1 para isso, pois estou enfrentando problemas ao usar o Trident + gerenciador de nuvem juntos, pois ainda não está escolhendo o pool correto que é gerado automaticamente para mim.

CalvinHartwell em 24 set. 2018

👍1

+1 Mesma solicitação: temos um cluster de 12 nós para o ponto: Nó que contém o LIF para o SVM (para evitar acesso indireto a dados para melhor desempenho)
e
aproveitando o provisionamento de volume total, conforme mencionado anteriormente.

Bem, se falarmos sobre lógica de posicionamento, adicionarei mais alguns itens a serem considerados (com base nos requisitos reais do cliente):
Número de volumes em um nó (já que o Ontap tem limites lógicos que você não deseja exceder)
Nó que contém o LIF para o SVM (para evitar acesso indireto a dados para melhor desempenho)
IOPS provisionado (via conceito de QoS adaptável) no nó/agregado
Combinados com os pontos já mencionados por outros e ponderados e ordenados de acordo com os requisitos específicos do cliente.
No final, precisaríamos de um mecanismo de regras personalizável no tridente ou de um mecanismo flexível para anexar outras ferramentas. Se decidirmos seguir com o posterior, eu votaria no WFA além do AppDM e do NSLM que já foram mencionados, já que (hoje) é a única ferramenta flexível o suficiente para construir uma solução personalizada que leva todos os itens acima itens em consideração.

Errant-Dutchman em 24 jun. 2019

👍1

também +1

Outra ideia. O parâmetro limitAggregateUsage analisa o uso global do agregado, não apenas a capacidade gerenciada pelo Trident.

se o agregado for compartilhado entre diferentes cargas de trabalho, o que geralmente é o caso, esse parâmetro deve ser um pouco mais preciso.

um exemplo:

o limite é definido para 20%
o aggr já está 50% cheio de outras cargas de trabalho
Neste caso, o Trident não poderá criar um volume.
Se o parâmetro estivesse olhando para o espaço ocupado apenas pelo Trident, a criação teria sido bem-sucedida.