O BlueXP  Tiering soluciona os desafios que surgem com o crescimento rápido dos dados, oferecendo benefícios como:

No essencial, todos os dados que sejam considerados inativos em sistemas de storage primário e secundário são uma boa meta para migrar para a nuvem. Em sistemas primários, esses dados podem incluir snapshots, Registros históricos e projetos concluídos. Em sistemas secundários, isso inclui todos os volumes que contêm cópias de dados primários feitas para fins de recuperação de desastres e backup.

Sim, é possível categorizar dados de volumes nas para a nuvem pública ou nuvens privadas, como o StorageGRID. Ao dispor em camadas os dados acessados por protocolos SAN, a NetApp recomenda o uso de nuvens privadas porque os protocolos SAN são mais sensíveis a problemas de conectividade do que nas.

A definição do que também pode ser referido a dados frios é: "Blocos de volume (metadados excluídos) que não foram acessados por algum tempo". O "tempo" é determinado por um atributo de política de disposição em camadas chamado dias de resfriamento.

Sim, as eficiências de storage em nível de volume do ONTAP, como compressão, deduplicação e compactação, são preservadas ao mover dados para a categoria de nuvem.

O FabricPool é a tecnologia de disposição em camadas do ONTAP que pode ser autogerenciada, usando a CLI e o System Manager da ONTAP, ou gerenciada como um serviço com a disposição em camadas do BlueXP . A disposição em camadas do BlueXP  transforma o FabricPool em um serviço gerenciado com processos avançados de automação, na ONTAP e na nuvem, proporcionando maior visibilidade e controle sobre a disposição em camadas em implantações híbridas e multicloud.

Não. Como os metadados do volume nunca são dispostos em camadas na camada de performance, os dados armazenados no storage de objetos não podem ser acessados diretamente.

No entanto, a disposição em camadas do BlueXP  pode ser usada para obter backup e recuperação de desastres econômicos, habilitando-a em sistemas secundários e volumes de destino do SnapMirror (volumes de DP), para categorizar todos os dados (metadados excluídos), reduzindo o espaço físico e o TCO do data center.

A disposição em camadas do BlueXP  é habilitada no nível do volume associando uma política de disposição em categorias a cada volume. A identificação de dados inativos é feita no nível do bloco.

A política de disposição em camadas associada ao volume é o mecanismo que controla quais blocos são dispostos e quando. A política define o tipo de blocos de dados (instantâneos, dados do usuário ou ambos) e o período de resfriamento. "Políticas de disposição em categorias de volume"Consulte para obter detalhes.

A disposição em camadas do BlueXP  não afeta a capacidade do volume, mas sim o uso da camada de performance do agregado.

Sim, a disposição em camadas do BlueXP  ativa o Relatório de dados inativos (IDR) em cada agregado. Essa configuração nos permite identificar a quantidade de dados inativos que podem ser dispostos em camadas em armazenamento de objetos de baixo custo.

O IDR começa a mostrar informações após o período de arrefecimento configurado ter passado. Usando o ONTAP 9.7 e anterior, o IDR teve um período de resfriamento não ajustável de 31 dias. A partir do ONTAP 9.8, o período de resfriamento IDR pode ser configurado até 183 dias.

Ao categorizar dados pouco acessados na nuvem pública:

"Consulte os detalhes de preços".

Ao categorizar dados pouco acessados em um sistema NetApp StorageGRID (nuvem privada) sem custo.

Sim. O BlueXP  Tiering permite que você use uma licença BYOL, uma assinatura PAYGO ou uma combinação de ambos.

Se você atingir o limite de capacidade do BYOL, a disposição em categorias de novos dados inativos será interrompida. Todos os dados em camadas anteriores permanecem acessíveis, o que significa que você pode recuperar e usar esses dados. Quando recuperados, esses dados são movidos de volta para o nível de performance da nuvem.

No entanto, se você tiver uma assinatura do mercado PAYGO ao BlueXP  - implantar e gerenciar serviços de dados em nuvem, os novos dados inativos continuarão sendo dispostos no storage de objetos e você pagará por esses encargos de acordo com o uso.

Não, não.

Sim. Todas as leituras da nuvem pública estão sujeitas a taxas de saída.

A melhor maneira de estimar o quanto um provedor de nuvem cobrará por hospedar seus dados é usar suas calculadoras: "AWS", "Azure" E "Google Cloud".

Sim. Verifique "Definição de preço do Amazon S3", "Preços de Blob em bloco" e "Preços do Cloud Storage" para obter preços adicionais incorridos com a leitura/recuperação de dados.

Para obter uma estimativa, basta adicionar seu cluster ONTAP ao BlueXP  e inspecioná-lo na página clusters de disposição em camadas do BlueXP . Clique em Calcule potenciais poupanças em camadas para que o cluster inicie o "Calculadora de TCO em camadas da BlueXP " para ver quanto dinheiro pode poupar.

A disposição em camadas do BlueXP  é compatível com o ONTAP versão 9,2 e posterior.

A disposição em camadas do BlueXP  é compatível com clusters de AFF, FAS e ONTAP Select de alta disponibilidade e nó único. Os clusters nas configurações de espelhamento do FabricPool e configurações de MetroCluster também são compatíveis.

Sim, ao iniciar o ONTAP 9.8, você pode categorizar dados de volumes hospedados em agregados HDD.

Sim. A disposição em camadas do BlueXP  pode ser configurada para volumes de camadas hospedados em qualquer agregado. A configuração de categorização de dados é irrelevante para o tipo de controlador usado e se o cluster é heterogêneo ou não.

Se você tiver sistemas Cloud Volumes ONTAP, os encontrará na página clusters de disposição em camadas do BlueXP . Assim, você terá uma visão completa da disposição de dados em sua infraestrutura de nuvem híbrida. No entanto, os sistemas Cloud Volumes ONTAP são somente leitura da disposição em camadas do BlueXP . Não é possível configurar a disposição de dados em categorias no Cloud Volumes ONTAP a partir do BlueXP . "Você configurou a disposição em camadas para sistemas Cloud Volumes ONTAP a partir do ambiente de trabalho no BlueXP ".

Depende de onde você categoriza os dados inativos. Consulte os seguintes links para obter mais detalhes:

A disposição em camadas do BlueXP  é compatível com os seguintes fornecedores de storage de objetos:

Sim, você pode. Ao configurar a disposição de dados em categorias, você pode adicionar um novo bucket/contêiner ou selecionar um bucket/contêiner existente.

A disposição em camadas do BlueXP  oferece suporte à disposição em camadas de dados para as classes de armazenamento Standard, Standard-uninfrequente Access, One Zone-unfrequente Access, Intelligent Tiering e Glacier Instant Retrieval. "Classes de armazenamento S3 suportadas"Consulte para obter mais detalhes.

O principal motivo pelo qual o Amazon S3 Glacier Flexible e o S3 Glacier Deep Archive não são compatíveis é que a disposição em camadas do BlueXP  foi projetada como uma solução de disposição em camadas de alto desempenho. Assim, os dados devem estar continuamente disponíveis e rapidamente acessíveis para recuperação. Com o S3 Glacier Flexible e o S3 Glacier Deep Archive, a recuperação de dados pode durar entre alguns minutos e 48 horas.

Sim, a configuração de storage de objetos compatível com S3 por meio da IU em camadas é compatível com clusters que usam o ONTAP 9.8 e versões posteriores. "Veja os detalhes aqui".

A disposição em camadas do BlueXP  é compatível com a disposição de dados nas camadas de acesso Hot ou Cool para os dados inativos. "Camadas de acesso Azure Blob compatíveis"Consulte para obter mais detalhes.

A disposição em camadas do BlueXP  oferece suporte à disposição de dados nas classes de armazenamento Standard, Nearline, Coldline e Archive. "Classes de armazenamento do Google Cloud compatíveis"Consulte para obter mais detalhes.

Sim. Você pode habilitar o gerenciamento de ciclo de vida para que a disposição em camadas do BlueXP  faça a transição dos dados da categoria de acesso/classe de storage padrão para uma categoria mais econômica após um determinado número de dias. A regra de ciclo de vida é aplicada a todos os objetos no bucket selecionado para o storage do Amazon S3 e do Google Cloud, bem como a todos os contêineres na conta de storage selecionada do Azure Blob.

Em uma configuração típica, há um armazenamento de objetos para todo o cluster. A partir de agosto de 2022, você pode usar a página Configuração Avançada para adicionar armazenamentos de objetos adicionais para um cluster e, em seguida, anexar armazenamentos de objetos diferentes a diferentes agregados ou anexar armazenamentos de objetos 2 a um agregado para espelhamento.

É possível anexar até dois buckets por agregado para fins de espelhamento, onde os dados inativos são dispostos de forma síncrona em ambos os buckets. Os baldes podem ser de diferentes fornecedores e locais diferentes. A partir de agosto de 2022, você pode usar a página Configuração Avançada para anexar dois armazenamentos de objetos a um único agregado.

Sim. A melhor prática geral é anexar um único balde a vários agregados. No entanto, ao usar a nuvem pública há uma limitação máxima de IOPS para os serviços de armazenamento de objetos, portanto, vários buckets devem ser considerados.

Ao migrar um volume de um cluster para outro, todos os dados inativos são lidos da camada de nuvem. O local de gravação no cluster de destino depende se a disposição em categorias foi ativada e do tipo de política de disposição em camadas usada nos volumes de origem e destino.

Se o agregado de destino não tiver uma camada de nuvem anexada, os dados serão lidos a partir da camada de nuvem do agregado de origem e gravados inteiramente no nível local do agregado de destino. Se o agregado de destino tiver uma categoria de nuvem anexada, os dados serão lidos a partir da camada de nuvem do agregado de origem e gravados primeiro no nível local do agregado de destino para facilitar a transferência rápida. Posteriormente, com base na política de disposição em camadas usada, ela é gravada na categoria de nuvem.

A partir do ONTAP 9.6, se o agregado de destino estiver usando a mesma camada de nuvem que o agregado de origem, os dados inativos não serão movidos de volta para o nível local.

Em geral, a gravação é feita de acordo com as leituras e depende do tipo de diretiva de disposição em camadas. Antes do ONTAP 9.8, a gravação de todo o volume pode ser feita com uma operação volume Move. A partir do ONTAP 9.8, a IU em categorias tem opções para trazer de volta todos os dados ou trazer de volta o sistema de arquivos ativo. "Veja como mover os dados de volta para o nível de performance".

Não. Durante o procedimento de "troca de cabeças", a única coisa que muda é a propriedade do agregado. Neste caso, ele será alterado para o novo controlador sem qualquer movimentação de dados.

Não. Os objetos construídos e dispostos na nuvem não contêm um único arquivo, mas até 1.024 4KB blocos de vários arquivos. Os metadados de um volume sempre permanecem no nível local.

O conector é um software executado em uma instância de computação na sua conta de nuvem ou no local que permite que o BlueXP  gerencie com segurança os recursos de nuvem. Para usar o serviço de disposição em camadas do BlueXP , é necessário implantar um conector.

Sim. O software Connector pode ser baixado e instalado manualmente em um host Linux em sua rede. "Veja como instalar o conetor nas suas instalações".

Sim. Você deve ter uma conta antes de definir o armazenamento de objetos que deseja usar. Uma conta com um provedor de armazenamento em nuvem também é necessária ao configurar o conetor na nuvem em uma VPC ou VNet.

No caso de uma falha no conetor, apenas a visibilidade nos ambientes em camadas é afetada. Todos os dados estão acessíveis e os dados inativos recém-identificados são automaticamente colocados em camadas no storage de objetos.

Há quatro políticas de disposição em camadas:

"Saiba mais sobre as políticas de disposição em camadas".

Como a categorização de dados é feita no nível do bloco, um bloco de dados é considerado inativo depois que ele não foi acessado por um determinado período de tempo, que é definido pelo atributo de dias de resfriamento mínimos da política de disposição em camadas. O intervalo aplicável é de 2-63 dias com o ONTAP 9.7 e anterior, ou 2-183 dias a partir do ONTAP 9.8.

O período de resfriamento padrão da política de Cold Snapshot é de 2 dias, enquanto o período de resfriamento padrão para dados de usuários inativos e snapshots é de 31 dias. O parâmetro de dias de resfriamento não é aplicável à política de disposição em categorias.

Durante o backup completo, todos os dados inativos são lidos. A recuperação dos dados depende da política de disposição em camadas usada. Ao usar as políticas All and Cold User Data and Snapshots, os dados inativos não são gravados de volta no nível de performance. Ao usar a política Cold Snapshots, somente no caso de um snapshot antigo ser usado para o backup seus blocos inativos serão recuperados.

Não. No entanto, você pode escolher quais volumes estão qualificados para disposição em categorias, o tipo de dados a serem dispostos em camadas e o período de resfriamento. Isso é feito associando uma política de disposição em categorias a esse volume.

Os volumes de proteção de dados (DP) podem ser associados a qualquer uma das três políticas disponíveis. O tipo de política usada nos volumes de origem e destino (DP) determina o local de gravação dos dados.

Não ocorre reidratação quando uma política de disposição em camadas é redefinida, mas impedirá que novos blocos inativos sejam movidos para a categoria de nuvem.

Sim. O comportamento após a alteração depende da nova política associada.

Não associe uma política de disposição em camadas ao volume que contém esses dados.

Os metadados de um volume sempre são armazenados localmente na camada de performance. Eles nunca são dispostos em camadas na nuvem.

Para obter mais detalhes, consulte:

Além da disposição em camadas do BlueXP  "Active IQ Unified Manager", "Consultor digital da BlueXP" pode ser usada para monitoramento e geração de relatórios.

Em caso de falha de rede, o nível de desempenho local permanece on-line e os dados ativos permanecem acessíveis. No entanto, os blocos que já foram movidos para a camada de nuvem ficarão inacessíveis e os aplicativos receberão uma mensagem de erro ao tentar acessar esses dados. Depois que a conetividade for restaurada, todos os dados estarão perfeitamente acessíveis.

A latência de leitura da tecnologia de disposição em camadas subjacente do FabricPool depende da conectividade à camada de nuvem. Embora a disposição em camadas funcione em qualquer largura de banda, recomenda-se colocar LIFs entre clusters em portas de 10 Gbps para fornecer desempenho adequado. Não há recomendações ou limitações de largura de banda para o conetor.

Além disso, você pode controlar a quantidade de largura de banda de rede usada durante a transferência de dados inativos do volume para o armazenamento de objetos. A configuração maximum transfer rate está disponível ao configurar seu cluster para disposição em camadas e depois na página clusters.

Sim. As camadas de nuvem não fornecem a mesma latência que a camada local, já que a latência depende da conectividade. Para estimar a latência e a taxa de transferência de um armazenamento de objetos, a disposição em camadas do BlueXP  fornece um teste de desempenho na nuvem (baseado no profiler do armazenamento de objetos do ONTAP) que pode ser usado após o armazenamento de objetos ser anexado e antes da configuração da disposição em camadas.

A criptografia AES-256-GCM é mantida nas camadas de performance e nuvem. A criptografia TLS 1,2 é usada para criptografar dados por cabo à medida que se move entre camadas e para criptografar a comunicação entre o conetor e o cluster ONTAP e o armazenamento de objetos.

Sim. É necessário configurar um LIF entre clusters em uma porta ethernet, em cada nó dentro de um par de HA que hospede volumes com dados que você planeja categorizar na nuvem. Para obter mais informações, consulte a seção requisitos do fornecedor de nuvem no qual você planeja categorizar dados.