É recomendável que você não use o rebalanceamento automático do FlexGroup após uma conversão de FlexVol para FlexGroup. Em vez disso, você pode usar o recurso de movimentação de arquivos retroativos disruptivos disponível no ONTAP 9.10,1 e posterior, digitando o volume rebalance file-move comando. Para obter a sintaxe de comando, consulte a volume rebalance file-move start página man.

O rebalanceamento com o recurso de rebalanceamento automático do FlexGroup pode degradar o desempenho ao mover um grande número de arquivos, como quando você executa uma conversão de FlexVol para FlexGroup, e até 50 a 85% dos dados no FlexVol volume são movidos para um novo componente.

A seleção de arquivos para rebalanceamento automático é baseada em blocos salvos. O tamanho mínimo de arquivo considerado para rebalanceamento é de 100 MB por padrão (pode ser configurado tão baixo quanto 20 MB usando o parâmetro min-file-size mostrado abaixo) e o tamanho máximo do arquivo é de 100 GB.

Você pode configurar o rebalanceamento do FlexGroup para considerar apenas os arquivos a serem movidos que não estão presentes atualmente em nenhuma cópia Snapshot. Quando o rebalanceamento é iniciado, uma notificação é exibida se uma operação de cópia Snapshot for agendada a qualquer momento durante uma operação de rebalanceamento.

As cópias snapshot ficam restritas se um arquivo estiver sendo movido e estiver passando por enquadramento no destino. Uma operação de restauração de cópia Snapshot não é permitida enquanto o rebalanceamento de arquivos estiver em andamento.

Qualquer cópia Snapshot criada após a granular-data opção ser ativada não pode ser replicada para um sistema que executa o ONTAP 9.11,1 e versões anteriores porque o ONTAP 9.11,1 e versões anteriores não suportam inodes de várias partes.

O rebalanceamento do FlexGroup deve ocorrer entre operações SnapMirror agendadas. Uma operação SnapMirror pode falhar se um arquivo estiver sendo relocado antes que uma operação SnapMirror comece se essa movimentação de arquivo não for concluída dentro do período de 24 minutos de tentativa do SnapMirror. Qualquer nova realocação de arquivo que comece após uma transferência do SnapMirror ser iniciada não falhará.

Com a eficiência de storage de compactação baseado em arquivo, o arquivo é descompactado antes de ser movido para o destino. Assim, a economia de compactação será perdida. A economia de compressão é recuperada depois que um scanner de fundo iniciado manualmente é executado no volume FlexGroup após o rebalanceamento. No entanto, se qualquer arquivo estiver associado a uma cópia Snapshot em qualquer volume, o arquivo será ignorado para compactação.

Mover arquivos desduplicados pode causar maior uso geral do volume FlexGroup. Durante o rebalanceamento de arquivos, apenas blocos exclusivos são movidos para o destino, liberando essa capacidade na origem. Os blocos compartilhados permanecem na origem e são copiados para o destino. Embora isso alcance o objetivo de reduzir a capacidade usada em um componente de origem quase completa, ele também pode levar ao aumento do uso geral no volume FlexGroup devido a cópias de blocos compartilhados nos novos destinos. Isso também é possível quando os arquivos que fazem parte de uma cópia Snapshot são movidos. A economia de espaço não será totalmente reconhecida até que o agendamento de cópia Snapshot seja reciclado e não haja mais cópias dos arquivos nas cópias Snapshot.

Se o rebalanceamento de arquivos estiver em andamento quando um volume FlexClone for criado, o rebalanceamento não será realizado no volume FlexClone. O rebalanceamento no volume FlexClone deve ser realizado após a criação.

Quando um arquivo é movido durante uma operação de rebalanceamento do FlexGroup, o tamanho do arquivo é relatado como parte da contagem de cotas nos componentes de origem e destino. Quando a movimentação estiver concluída, a contagem de cotas retorna ao normal e o tamanho do arquivo só é relatado no novo destino.

A partir do ONTAP 9.13,1, a proteção autônoma contra ransomware é suportada durante operações de rebalanceamento ininterruptas e sem interrupções.

O rebalanceamento da capacidade de volume não é compatível com volumes de armazenamento de objetos, como buckets do S3.