Épico
Disposição do Snapshot em camadas
Sugerir alterações
PDFs
A versão inicial do FabricPool visou o caso de uso de backup. O único tipo de blocos que podiam ser dispostos em camadas eram blocos que não estavam mais associados aos dados no sistema de arquivos ativo. Portanto, apenas os blocos de dados do snapshot podem ser movidos para a camada de capacidade. Essa continua sendo uma das opções de disposição em categorias mais seguras quando você precisa garantir que a performance nunca seja afetada.
Políticas - instantâneos locais
Existem duas opções para a disposição em camadas de blocos snapshot inativos na camada de capacidade. Primeiro, a snapshot-only política segmenta apenas os blocos de snapshot. Embora auto a política inclua os snapshot-only blocos, ela também dispõe blocos do sistema de arquivos ativo. Isso pode não ser desejável.
O tiering-minimum-cooling-days valor deve ser definido para um período de tempo que torne os dados que possam ser necessários durante uma restauração disponíveis no nível de desempenho. Por exemplo, a maioria dos cenários de restauração de um banco de dados de produção crítico inclui um ponto de restauração em algum momento nos últimos dias. Definir um tiering-minimum-cooling-days valor de 3 garantirá que qualquer restauração do arquivo resulte em um arquivo que imediatamente forneça o máximo de desempenho. Todos os blocos nos arquivos ativos ainda estão presentes no storage rápido sem a necessidade de recuperá-los da camada de capacidade.
Políticas - instantâneos replicados
Um snapshot replicado com o SnapMirror ou o SnapVault que é usado somente para recuperação geralmente deve usar a política FabricPool all. Com essa política, os metadados são replicados, mas todos os blocos de dados são imediatamente enviados para a categoria de capacidade, o que proporciona o máximo de performance. A maioria dos processos de recuperação envolve e/S sequenciais, que é inerentemente eficiente. O tempo de recuperação do destino do armazenamento de objetos deve ser avaliado, mas, em uma arquitetura bem projetada, esse processo de recuperação não precisa ser significativamente mais lento do que a recuperação de dados locais.
Se os dados replicados também se destinarem a ser usados para clonagem, a auto política é mais apropriada, com um tiering-minimum-cooling-days valor que engloba dados que se espera que sejam usados regularmente em um ambiente de clonagem. Por exemplo, o conjunto de trabalho ativo de um banco de dados pode incluir dados lidos ou gravados nos três dias anteriores, mas também pode incluir outros 6 meses de dados históricos. Em caso afirmativo, a auto política no destino do SnapMirror torna o conjunto de trabalho disponível no nível de desempenho.
