O Cloud Tiering aborda os desafios que surgem com o rápido crescimento de dados, oferecendo benefícios como:

Basicamente, qualquer dado considerado inativo nos sistemas de armazenamento primário e secundário é um bom alvo para mover para a nuvem. Em sistemas primários, esses dados podem incluir instantâneos, 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 DR e backup.

Sim, você pode hierarquizar dados de volumes NAS para a nuvem pública ou para nuvens privadas, como o StorageGRID. Ao hierarquizar 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 o NAS.

A definição do que também pode ser chamado de dados frios é: "blocos de volume (metadados excluídos) que não foram acessados por algum período de tempo". A “quantidade de tempo” é determinada por um atributo de política de níveis chamado cooling-days.

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

FabricPool é a tecnologia de hierarquização ONTAP que pode ser autogerenciada por meio do ONTAP CLI e do System Manager, ou gerenciada como serviço por meio do Cloud Tiering. O Cloud Tiering transforma o FabricPool em um serviço gerenciado com processos de automação avançados, tanto no ONTAP quanto na nuvem, proporcionando maior visibilidade e controle sobre o hierarquização em implantações híbridas e multinuvem.

Não. Como os metadados do volume nunca são hierarquizados em relação à camada de desempenho, os dados armazenados no armazenamento de objetos não podem ser acessados diretamente.

No entanto, o Cloud Tiering pode ser usado para obter backup e DR com boa relação custo-benefício, habilitando-o em sistemas secundários e volumes de destino do SnapMirror (volumes DP), para hierarquizar todos os dados (metadados excluídos), reduzindo assim a pegada do seu data center e o TCO.

A hierarquização da nuvem é habilitada no nível do volume associando uma política de hierarquização a cada volume. A identificação de dados frios é feita no nível do bloco.

A política de hierarquização associada ao volume é o mecanismo que controla quais blocos são hierarquizados 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. Ver"Políticas de níveis de volume" para mais detalhes.

O Cloud Tiering não tem efeito na capacidade do volume, mas sim no uso da camada de desempenho do agregado.

Sim, o Cloud Tiering habilita o Relatório de Dados Inativos (IDR) em cada agregado. Essa configuração nos permite identificar a quantidade de dados inativos que podem ser alocados ao armazenamento de objetos de baixo custo.

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

Ao hierarquizar dados frios na nuvem pública:

"Veja detalhes de preços" .

Ao hierarquizar dados frios em um sistema NetApp StorageGRID (nuvem privada), não há custo.

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

Se você atingir o limite de capacidade BYOL ou se sua licença BYOL expirar, a hierarquização de novos dados frios 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 a camada de desempenho da nuvem.

No entanto, se você tiver uma assinatura do marketplace PAYGO para o BlueXP - Implantar e gerenciar serviços de dados em nuvem, os novos dados frios continuarão sendo classificados em camadas no armazenamento de objetos e você pagará por essas taxas por 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 quanto um provedor de nuvem cobrará pela hospedagem de seus dados é usar suas calculadoras: "AWS" , "Azul" e "Google Cloud" .

Sim. Verificar "Preços do Amazon S3" , "Preço do Block Blob" , e "Preços de armazenamento em nuvem" para preços adicionais incorridos com leitura/recuperação de dados.

Para obter uma estimativa, adicione seu cluster ONTAP ao NetApp Console e inspecione-o na página Clusters de camadas de nuvem. Selecione Calcular economia potencial de níveis para o cluster iniciar o "Calculadora de TCO de hierarquização de nuvem" para ver quanto dinheiro você pode economizar.

Quando usado em ambientes MetroCluster , a licença de hierarquização total é aplicada ao uso de ambos os clusters. Por exemplo, se você tiver uma licença para 100 TiB de camadas, a capacidade de camadas usada de cada cluster contribuirá para a capacidade total de 100 TiB.

O Cloud Tiering oferece suporte ao ONTAP versão 9.2 e superior.

O Cloud Tiering é compatível com clusters AFF, FAS e ONTAP Select de nó único e alta disponibilidade. Clusters em configurações de espelho do FabricPool e configurações do MetroCluster também são suportados.

Sim, a partir do ONTAP 9.8 você pode hierarquizar dados de volumes hospedados em agregados de HDD.

Sim. O Cloud Tiering pode ser configurado para hierarquizar volumes hospedados em qualquer agregado. A configuração de camadas 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 , você os encontrará na página Clusters de camadas de nuvem para obter uma visão completa da divisão de dados em camadas na sua infraestrutura de nuvem híbrida. No entanto, os sistemas Cloud Volumes ONTAP são somente leitura no Cloud Tiering. Não é possível configurar o armazenamento em camadas de dados no Cloud Volumes ONTAP a partir do Cloud Tiering. "Você configura o hierarquização para sistemas Cloud Volumes ONTAP a partir do sistema ONTAP no NetApp Console" .

Depende de onde você organiza os dados frios. Consulte os links a seguir para mais detalhes:

O Cloud Tiering oferece suporte aos seguintes provedores de armazenamento de objetos:

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

O Cloud Tiering oferece suporte ao armazenamento em camadas de dados para as classes de armazenamento Standard, Standard-Infrequent Access, One Zone-Infrequent Access, Intelligent Tiering e Glacier Instant Retrieval. Ver"Classes de armazenamento S3 suportadas" para mais detalhes.

O principal motivo pelo qual o Amazon S3 Glacier Flexible e o S3 Glacier Deep Archive não são suportados é que o Cloud Tiering foi projetado como uma solução de hierarquização de alto desempenho, portanto 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 levar de alguns minutos a 48 horas.

Sim, a configuração do armazenamento de objetos compatível com S3 por meio da interface de usuário em camadas é suportada para clusters que usam o ONTAP 9.8 e versões posteriores. "Veja os detalhes aqui" .

O Cloud Tiering oferece suporte ao hierarquização de dados para os níveis de acesso Hot ou Cool para seus dados inativos. Ver"Camadas de acesso do Azure Blob com suporte" para mais detalhes.

O Cloud Tiering oferece suporte ao armazenamento em camadas de dados para as classes de armazenamento Standard, Nearline, Coldline e Archive. Ver"Classes de armazenamento do Google Cloud compatíveis" para mais detalhes.

Sim. Você pode habilitar o gerenciamento do ciclo de vida para que o Cloud Tiering faça a transição dos dados da classe de armazenamento/nível de acesso padrão para um nível mais econômico após um determinado número de dias. A regra do ciclo de vida é aplicada a todos os objetos no bucket selecionado para armazenamento do Amazon S3 e do Google Cloud, e a todos os contêineres na conta de armazenamento selecionada para o 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 diferentes armazenamentos de objetos a diferentes agregados ou anexar 2 armazenamentos de objetos a um agregado para espelhamento.

É possível anexar até dois buckets por agregado para fins de espelhamento, onde dados frios são sincronizados em camadas para ambos os buckets. Os buckets podem ser de diferentes provedores e locais. A partir de agosto de 2022, você poderá 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 frios são lidos da camada de nuvem. O local de gravação no cluster de destino depende se a hierarquização foi habilitada e do tipo de política de hierarquização 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 da camada de nuvem do agregado de origem e gravados inteiramente na camada local do agregado de destino. Se o agregado de destino tiver uma camada de nuvem anexada, os dados serão lidos da camada de nuvem do agregado de origem e primeiro gravados na camada local do agregado de destino, para facilitar a transição rápida. Posteriormente, com base na política de camadas usada, ele é gravado na camada 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 frios não retornarão para a camada local.

A gravação geralmente é realizada em leituras e depende do tipo de política de camadas. Antes do ONTAP 9.8, a gravação de volta do volume inteiro podia ser feita com uma operação volume move. A partir do ONTAP 9.8, a interface de usuário em camadas tem opções para Trazer de volta todos os dados ou Trazer de volta o sistema de arquivos ativo. "Veja como mover dados de volta para a camada de desempenho" .

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 hierarquizados na nuvem não contêm um único arquivo, mas até 1.024 blocos de 4 KB de vários arquivos. Os metadados de um volume sempre permanecem na camada local.

O agente do Console é um software executado em uma instância de computação na sua conta de nuvem ou no local, que permite que o NetApp Console gerencie com segurança os recursos da nuvem. Para usar o serviço Cloud Tiering, você deve implantar um agente.

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

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

No caso de falha de um agente, apenas a visibilidade dos ambientes em camadas é afetada. Todos os dados são acessíveis e os dados frios recém-identificados são automaticamente classificados no armazenamento de objetos.

Existem quatro políticas de níveis:

"Saiba mais sobre políticas de níveis" .

Como a hierarquização de dados é feita no nível do bloco, um bloco de dados é considerado frio após não ser acessado por um determinado período de tempo, definido pelo atributo minimum-cooling-days da política de hierarquização. O intervalo aplicável é de 2 a 63 dias com ONTAP 9.7 e versões anteriores, ou de 2 a 183 dias a partir do ONTAP 9.8.

O período de resfriamento padrão para a política Cold Snapshot é de 2 dias, enquanto o período de resfriamento padrão para Cold User Data e Snapshots é de 31 dias. O parâmetro dias de resfriamento não é aplicável à política de todas as camadas.

Durante o backup completo, todos os dados frios são lidos. A recuperação dos dados depende da política de hierarquização utilizada. Ao usar as políticas Todos os Dados Frios do Usuário e Snapshots, os dados frios não são gravados de volta na camada de desempenho. Ao usar a política Cold Snapshots, somente no caso de um snapshot antigo ser usado para o backup seus blocos frios serão recuperados.

Não. No entanto, você pode escolher quais volumes são elegíveis para camadas, o tipo de dados a serem colocados em camadas e seu período de resfriamento. Isso é feito associando uma política de níveis a esse volume.

Não. 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.

Nenhuma reidratação ocorre quando uma política de hierarquização é redefinida, mas isso impedirá que novos blocos frios sejam movidos para a camada de nuvem.

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

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

Os metadados de um volume são sempre armazenados localmente, na camada de desempenho — eles nunca são hierarquizados na nuvem.

Para mais detalhes, consulte:

Além do Cloud Tiering, "Active IQ Unified Manager" e "consultor digital" pode ser usado para monitoramento e relatórios.

Em caso de falha de rede, a camada de desempenho local permanece online 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. Assim que a conectividade for restaurada, todos os dados ficarão facilmente acessíveis.

A latência de leitura da tecnologia de camadas FabricPool subjacente depende da conectividade com a camada de nuvem. Embora a hierarquização funcione em qualquer largura de banda, é recomendável colocar LIFs intercluster em portas de 10 Gbps para fornecer desempenho adequado. Não há recomendações ou limitações de largura de banda para o agente.

Além disso, você pode limitar 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 Taxa máxima de transferência está disponível ao configurar seu cluster para camadas e, posteriormente, na página Clusters.

Sim. As camadas de nuvem não podem fornecer a mesma latência que a camada local, pois a latência depende da conectividade. Para estimar a latência e a taxa de transferência de um armazenamento de objetos, o Cloud Tiering fornece um Cloud Performance Test (com base no criador de perfil do armazenamento de objetos ONTAP ) que pode ser usado depois que o armazenamento de objetos for anexado e antes da configuração do armazenamento em camadas.

A criptografia AES-256-GCM é mantida nas camadas de desempenho e de nuvem. A criptografia TLS 1.2 é usada para criptografar dados pela rede conforme eles se movem entre camadas e para criptografar a comunicação entre o agente e o cluster ONTAP e o armazenamento de objetos.

Sim. Um LIF intercluster deve ser configurado em uma porta Ethernet, em cada nó dentro de um par de HA que hospeda volumes com dados que você planeja hierarquizar na nuvem. Para obter mais informações, consulte a seção Requisitos do provedor de nuvem onde você planeja hierarquizar os dados.