O tamanho do arquivo é menos importante do que o número de gravações emitidas entre o OPEN e CLOSE chamadas para um arquivo. Arquivos pequenos têm, inerentemente, WRITE menos chamadas, tornando-os menos ideais para write-back. Arquivos grandes podem ter mais gravações entre OPEN e CLOSE chamadas, mas isso não é garantido.

Consulte "Diretrizes de reescrita do FlexCache"a página para obter as recomendações mais recentes sobre o tamanho máximo do arquivo.

Ao gravar de um cliente, outras chamadas nas modificadas são envolvidas além de chamadas de gravação. Estes incluem, mas não estão limitados a:

SETATTR e SET_INFO as chamadas que definem mtime, atime, , ctime owner , group ou size são processadas no cache. O resto dessas chamadas deve ser processado na origem e acionar uma gravação de qualquer dado sujo acumulado no cache habilitado para write-back para o arquivo que está sendo operado. O IO para o arquivo será silenciado até que o write-back esteja concluído.

Saber que essas chamadas devem atravessar a WAN ajuda você a identificar cargas de trabalho adequadas para back-back. Geralmente, quanto mais gravações que podem ser feitas entre OPEN e CLOSE chamadas sem que uma das outras chamadas listadas acima seja emitida, melhor será o ganho de desempenho de retorno de gravação.

As cargas de trabalho de leitura após gravação têm tido um desempenho insatisfatório na FlexCache. Isto deve-se ao modo de operação de escrita antes de 9.15.1. A WRITE chamada para o arquivo tem que ser confirmada na origem, e a chamada subsequente READ teria que puxar os dados de volta para o cache. Isso resulta em ambas as operações que incorrem na penalidade da WAN. Portanto, as cargas de trabalho de leitura após gravação são desencorajadas para o FlexCache no modo write-around. Com a introdução do write-back em 9.15.1, os dados agora são comprometidos no cache e podem ser lidos imediatamente a partir do cache, eliminando a penalidade da WAN. Se o seu workload incluir leitura após gravação em volumes FlexCache, você deverá configurar o cache para operar no modo write-back.

Quando um arquivo acumula dados sujos em um cache, o cache grava os dados de volta para a origem de forma assíncrona. Isso naturalmente leva a momentos em que o cliente fecha o arquivo com dados sujos ainda esperando para ser lavado de volta à origem. Se outro arquivo aberto ou escrito aparecer para o arquivo que foi fechado e ainda tem dados sujos, a gravação será suspensa até que todos os dados sujos tenham sido lavados para origem.

Quando o FlexCache opera no modo write-back, torna-se mais benéfico para os clientes nas à medida que a latência aumenta. No entanto, há um ponto em que a sobrecarga do write-back supera as vantagens obtidas em ambientes de baixa latência. Em alguns testes do NetApp, os benefícios de write-back começaram em torno de uma latência mínima entre cache e origem do 8ms. Essa latência varia de acordo com o workload, portanto, teste para saber o ponto de retorno do workload.

O gráfico a seguir mostra o ponto de retorno para write-back em testes de laboratório do NetApp. O x eixo é o tamanho do arquivo e o y eixo é o tempo decorrido. O teste utilizou NFSv3, montagem com um rsize e wsize de 256KB e 64ms de latência WAN. Este teste foi realizado usando uma pequena instância do ONTAP Select para o cache e origem, e uma única operação de escrita em thread. Seus resultados podem variar.