Disposição em camadas de arquivos parcial
Como o FabricPool funciona no nível de bloco, os arquivos sujeitos a alteração podem ser parcialmente dispostos em camadas no storage de objetos, permanecendo também parcialmente na camada de performance.
Isso é comum com bancos de dados. Bancos de dados que contêm blocos inativos também são candidatos à disposição em camadas do FabricPool. Por exemplo, um banco de dados de gerenciamento da cadeia de suprimentos pode conter informações históricas que devem estar disponíveis se necessário, mas não são acessadas durante operações normais. O FabricPool pode ser usado para realocar seletivamente os blocos inativos.
Por exemplo, os arquivos de dados executados em um volume FabricPool com tiering-minimum-cooling-days
um período de 90 dias mantêm todos os blocos acessados nos 90 dias anteriores no nível de performance. No entanto, qualquer coisa que não seja acessada por 90 dias é realocada para o nível de capacidade. Em outros casos, a atividade normal da aplicação preserva os blocos corretos no nível correto. Por exemplo, se um banco de dados é normalmente usado para processar os 60 dias anteriores de dados regularmente, um período muito menor tiering-minimum-cooling-days
pode ser definido porque a atividade natural do aplicativo garante que os blocos não sejam transferidos prematuramente.
|
A auto política deve ser usada com cuidado com bancos de dados. Muitos bancos de dados têm atividades periódicas, como processo de fim de trimestre ou operações de reindexação. Se o período dessas operações for maior do que os tiering-minimum-cooling-days problemas de desempenho podem ocorrer. Por exemplo, se o processamento no final do trimestre exigir 1TB TB de dados que, de outra forma, foram intocados, esses dados podem agora estar presentes na camada de capacidade. As leituras do nível de capacidade geralmente são extremamente rápidas e podem não causar problemas de desempenho, mas os resultados exatos dependerão da configuração do armazenamento de objetos.
|
Políticas
A tiering-minimum-cooling-days
política deve ser definida suficientemente alta para reter arquivos que possam ser necessários no nível de desempenho. Por exemplo, um banco de dados em que os 60 dias mais recentes de dados possam ser necessários com desempenho ideal garantiria a definição tiering-minimum-cooling-days
do período para 60 dias. Resultados semelhantes também podem ser alcançados com base nos padrões de acesso dos arquivos. Por exemplo, se os 90 dias mais recentes de dados forem necessários e o aplicativo estiver acessando esse período de 90 dias de dados, os dados permanecerão no nível de desempenho. Definir o tiering-minimum-cooling-days
período para 2 dias classificaria os dados imediatamente após os dados ficarem menos ativos.
`auto`A política é necessária para impulsionar a disposição em camadas desses blocos, porque somente a `auto` política afeta os blocos que estão no sistema de arquivos ativo.
|
Qualquer tipo de acesso aos dados repõe os dados do mapa de calor. Portanto, varreduras completas de tabela de banco de dados e até mesmo atividades de backup que leem os arquivos de origem impedem a categorização porque o limite necessário tiering-minimum-cooling-days nunca é atingido.
|