FabricPool políticas de escalonamento de volume
Sugerir alterações
PDFs
FabricPool as políticas de hierarquização de volumes determinam quais dados em um volume são elegíveis para serem hierarquizados e o parâmetro de dias mínimos de resfriamento para hierarquização determina quando os dados são considerados inativos e elegíveis para serem hierarquizados.
|
Listas de controle de acesso (ACLs), estruturas de diretório e metadados nunca são transferidos de camada; eles sempre permanecem na camada local. |
Uma verificação diária de tiering em segundo plano procura por blocos frios. Quando blocos suficientes de 4KB do mesmo volume são coletados, eles são concatenados em um objeto de 4MB e movidos para a camada de nuvem com base na política de tiering do volume.
Compreender como funcionam as políticas de hierarquização ajudará você a selecionar a política certa para suas necessidades de gerenciamento de storage.
Opções de política de escalonamento de volume
Por padrão, os volumes usam a política de hierarquização de volumes None. A exceção a isso são os volumes FlexVol recém-criados em agregados FabricPool, que usam a política de hierarquização de volumes Snapshot-Only.
Você pode usar o volume object-store tiering show comando para exibir o status de disposição em camadas de um volume FabricPool. Saiba mais sobre volume object-store tiering show o "Referência do comando ONTAP"na .
A política de disposição em camadas do FabricPool é especificada no nível do volume. Estão disponíveis quatro opções:
Somente instantâneo
A `snapshot-only`política de tiering armazena em camadas os dados de snapshot que não estão mais associados ao sistema de arquivos ativo. Por padrão, são necessários dois dias de inatividade para que um snapshot esteja apto a ser armazenado em camadas. A maioria dos agendamentos de proteção de dados é horária ou diária e lê os dados localmente antes de armazená-los em camadas.
Você pode modificar a configuração padrão para o período mínimo de resfriamento do tiering com o parâmetro -tiering-minimum-cooling-days no nível de privilégio avançado dos comandos volume create e volume modify. Os valores válidos são de 2 a 183 dias usando ONTAP 9.8 e versões posteriores. Se você estiver usando uma versão do ONTAP anterior à 9.8, os valores válidos são de 2 a 63 dias.
Quando lidos, os blocos frios associados às cópias de snapshot permanecem frios e não são gravados de volta na camada local.
Automático
A `auto`política de hierarquização move todos os dados inativos do volume, tanto os snapshots quanto o sistema de arquivos ativo, para a camada de nuvem. O período mínimo de resfriamento padrão para hierarquização é de 31 dias e se aplica a todo o volume, tanto ao sistema de arquivos ativo quanto aos snapshots.
É possível modificar a configuração padrão para o período mínimo de resfriamento em camadas com o -tiering-minimum-cooling-days parâmetro no nível de privilégio avançado dos volume create comandos e. volume modify Os valores válidos são de 2 a 183 dias.
Quando lidos aleatoriamente, os blocos frios em um volume com uma política de tiering definida como Auto são tornados quentes e gravados de volta na camada local.
Quando lidos sequencialmente, os blocos frios em um volume com uma política de tiering definida como Auto permanecem frios e continuam na camada de nuvem. Eles não são gravados de volta na camada local.
Tudo
A all política de hierarquização marca imediatamente todos os dados no volume como frios e começa a transferi-los para a camada de nuvem o mais rápido possível. Não é necessário esperar 48 horas para que novos blocos em um volume usando a all política de hierarquização se tornem frios.
O período de resfriamento mínimo de disposição em camadas não se aplica porque os dados são movidos para a camada de nuvem assim que a verificação de disposição em camadas é executada e não é possível modificar a configuração.
Quando blocos frios em um volume com uma política de camadas definida como All são lidos, eles permanecem frios e ficam na camada de nuvem. Eles não são gravados de volta na camada local.
|
|
A O armazenamento de objetos não é transacional como o armazenamento de arquivos ou blocos. Fazer alterações em arquivos armazenados como objetos em volumes usando a política de tiering All pode resultar na criação de novos objetos, fragmentação de objetos existentes, redução do desempenho de leitura e adição de ineficiências de storage. |
Nenhum
A `none`política de hierarquização mantém os dados de um volume na camada de desempenho e não os hierarquiza.
Definir a política de disposição em categorias none para impedir a nova disposição em camadas. Os dados de volume anteriormente movidos para a camada de nuvem permanecem na camada de nuvem até que fiquem ativos e são movidos automaticamente de volta para a camada local.
O período de resfriamento mínimo de disposição em camadas não se aplica porque os dados nunca são movidos para a camada de nuvem e não é possível modificar a configuração.
Quando blocos frios em um volume com uma política de disposição em categorias definida como none são lidos, eles ficam ativos e gravados no nível local.
O volume show comando output mostra a política de disposição em camadas de um volume. Um volume que nunca foi usado com o FabricPool mostra a none política de disposição em camadas na saída.
|
|
Em uma relação SVM DR, os volumes de origem e destino não precisam usar agregados FabricPool, mas precisam usar a mesma política de disposição em camadas. |
O que acontece quando você modifica uma política de escalonamento de volume
Você pode modificar a política de disposição em categorias de um volume executando volume modify uma operação. Você deve entender como mudar a política de disposição em camadas pode afetar o tempo necessário para que os dados fiquem inativos e sejam movidos para a categoria de nuvem.
-
Ao alterar a política de disposição em categorias de
snapshot-onlyounoneparaauto, o ONTAP pode enviar blocos de dados de usuários no sistema de arquivos ativo que já estão inativos na categoria de nuvem, mesmo que esses blocos de dados de usuários não estivessem qualificados anteriormente para a categoria de nuvem. -
A alteração da política de disposição em categorias para
alloutra política faz com que o ONTAP mova todos os blocos de usuário no sistema de arquivos ativo e nos snapshots para a nuvem o mais rápido possível. Antes do ONTAP 9.8, os blocos precisavam esperar até que a próxima verificação de disposição em camadas fosse executada.Mover blocos de volta para o nível de desempenho não é permitido.
-
Alterar a política de disposição em categorias de
autoounoneparasnapshot-onlyfazer com que os blocos de sistema de arquivos ativos que já foram migrados para a categoria de nuvem sejam movidos de volta para a categoria de performance.Leituras de volume são necessárias para que os dados sejam movidos de volta para a camada de performance.
-
Sempre que você alterar a política de disposição em categorias em um volume, o período mínimo de resfriamento em categorias será redefinido para o valor padrão da política.
O que acontece com a política de disposição em camadas quando você move um volume
-
A menos que você especifique explicitamente uma política de disposição em camadas diferente, um volume mantém sua política de disposição em camadas original quando é movido para dentro e para fora de um agregado habilitado para FabricPool.
No entanto, a política de disposição em categorias só entra em vigor quando o volume está em um agregado habilitado para FabricPool.
-
O valor existente
-tiering-minimum-cooling-daysdo parâmetro para um volume é movido com o volume, a menos que você especifique uma política de disposição em camadas diferente para o destino.Se você especificar uma política de disposição em camadas diferente, o volume usará o período mínimo de resfriamento de disposição em camadas padrão para essa política. Este é o caso se o destino é FabricPool ou não.
-
Você pode mover um volume entre agregados e, ao mesmo tempo, modificar a política de disposição em camadas.
-
Você deve prestar atenção especial quando
volume moveuma operação envolver aautopolítica de disposição em camadas.Supondo que a origem e o destino sejam agregados habilitados para FabricPool, a tabela a seguir resume o resultado de uma
volume moveoperação que envolve alterações de política relacionadasautoao :Quando você move um volume que tem uma política de disposição em camadas de…
E você altera a política de disposição em camadas com a…
Então, depois que o volume se move…
allautoTodos os dados são movidos para o nível de performance.
snapshot-only,none, ouautoautoOs blocos de dados são movidos para o mesmo nível de destino que anteriormente estavam na origem.
autoouallsnapshot-onlyTodos os dados são movidos para o nível de performance.
autoallTodos os dados de usuário são movidos para a camada de nuvem.
snapshot-only,autoouallnoneTodos os dados são mantidos na camada de performance.
O que acontece com a política de disposição em camadas quando você clonar um volume
-
A partir do ONTAP 9.8, um volume de clone herda sempre a política de disposição em camadas e a política de recuperação de nuvem do volume pai.
Em versões anteriores ao ONTAP 9.8, um clone herda a política de disposição em camadas do pai, exceto quando o pai tem a
allpolítica de disposição em camadas. -
Se o volume pai tiver a
neverpolítica de recuperação de nuvem, seu volume clone precisará ter aneverpolítica de recuperação de nuvem ou aallpolítica de disposição em camadas e uma política de recuperação de nuvem correspondentedefault. -
A política de recuperação de nuvem de volume pai não pode ser alterada para
never, a menos que todos os seus volumes clones tenham uma política de recuperação denevernuvem .
Ao clonar volumes, tenha em mente as seguintes práticas recomendadas:
-
A
-tiering-policyopção etiering-minimum-cooling-daysa opção do clone controlam apenas o comportamento de disposição em camadas de blocos exclusivos do clone. Portanto, recomendamos o uso de configurações de disposição em categorias no FlexVol pai que migram a mesma quantidade de dados ou que migram menos dados do que qualquer um dos clones -
A política de recuperação de nuvem no FlexVol pai deve mover a mesma quantidade de dados ou mover mais dados do que a política de recuperação de qualquer um dos clones
Como as políticas de recuperação na nuvem funcionam com políticas de tiering
A recuperação de dados de nuvem do FabricPool é controlada por políticas de recuperação que determinam quando os dados são gravados de volta na camada local. Os padrões de leitura podem ser sequenciais ou aleatórios.
A tabela a seguir lista as políticas de hierarquização de volumes e o comportamento de recuperação padrão para cada política.
Política de disposição em camadas |
Comportamento de recuperação padrão |
nenhum |
Leituras sequenciais e aleatórias |
apenas snapshot |
Leituras sequenciais e aleatórias |
auto |
Leituras aleatórias |
tudo |
Sem recuperação de dados |
A partir do ONTAP 9.8, a opção de controle de migração para a cloud-retrieval-policy nuvem substitui o comportamento padrão de migração ou recuperação da nuvem controlado pela política de disposição em camadas.
A tabela a seguir lista as políticas de recuperação de nuvem suportadas e seu comportamento de recuperação.
Política de recuperação de nuvem |
Comportamento de recuperação |
padrão |
Quando blocos frios em um volume são lidos, eles usam o comportamento padrão da política de camadas do volume. Essa política é o valor padrão para qualquer volume, independentemente do tipo de agregado hospedado. |
na leitura |
Quando blocos frios em um volume com uma política de recuperação na nuvem definida como “On-Read” são lidos, aleatoriamente ou sequencialmente, eles se tornam quentes e são gravados na camada local. Aplicações que utilizam leituras sequenciais acionam gravações de retorno para a camada local ao definir a política de recuperação de volume na nuvem como “On-Read”. Isso pode ser benéfico para aplicações que necessitam do desempenho da camada local a partir de dados anteriormente inativos que agora estão sendo lidos por cargas de trabalho ativas |
nunca |
Quando blocos frios em um volume com uma política de recuperação na nuvem definida como "Nunca" são lidos, eles permanecem frios e ficam na camada de nuvem. Eles não são gravados de volta na camada local. Definir a política de recuperação na nuvem como "Nunca" é semelhante à política de tiering "All", pois os dados não podem retornar à camada local, mas difere da política de tiering "All" por continuar usando a configuração tiering-minimum-cooling-days do volume, em vez de realizar o tiering o mais rápido possível. Por exemplo, um volume que utiliza a configuração padrão da política de tiering automático não marcará os dados como frios até que ocorram 31 dias de inatividade. Após 31 dias, os dados inativos serão movidos para o storage de objetos e não serão recuperados quando lidos, pois a política de recuperação na nuvem do volume foi definida como "Never". |
promover |
|
O exemplo a seguir altera a política de tiering do volume para none e a política de recuperação para promote:
set -privilege advanced volume modify -vserver vs1 -volume myvol -tiering-policy none -cloud-retrieval-policy promote