Camadas de acesso de Arquivo, Quente e Fixe para dados blob

Os dados armazenados na nuvem crescem a um ritmo exponencial. Para gerir os custos para as suas necessidades de armazenamento em expansão, pode ser útil organizar os seus dados com base na frequência com que serão acetidos e durante quanto tempo serão mantidos. O armazenamento do Azure oferece diferentes níveis de acesso para que possa armazenar os seus dados blob da forma mais eficaz em função da sua eficácia. Os níveis de Armazenamento do Azure incluem:

  • Hot tier - uma nível online otimizada para armazenar dados que são acededos ou modificados frequentemente. A escalão Ativos tem os custos de armazenamento mais elevados, mas os custos de acesso mais baixos.
  • Escalão fixe – uma nível online otimizada para armazenar dados que não podem ser acetidos ou modificados com pouco acesso. Os dados na escalão Cool devem ser armazenados durante, no mínimo, 30 dias. A escalão Cool tem custos de armazenamento mais baixos e custos de acesso mais elevados em comparação com a escalagem de Quente.
  • Nível de arquivo - uma nível offline otimizado para armazenar dados que raramente são acededos e que tem requisitos de latência flexíveis pela ordem das horas. Os dados na escalão Arquivo devem ser armazenados durante, no mínimo, 180 dias.

Os limites de capacidade de armazenamento do Azure são definidos ao nível da conta, em vez de de acordo com a escalão de acesso. Pode optar por maximizar a utilização da sua capacidade numa camada ou distribuir a capacidade em duas ou mais camadas.

Camadas de acesso online

Quando os seus dados são armazenados numa escalão de acesso online (Hot ou Cool), os utilizadores podem aceder-lhe imediatamente. A escalão de ataças é a melhor escolha para dados que estão ativamente utilizados, enquanto a escalão Cool é ideal para dados aos que são acetidos com menos frequência, mas que ainda têm de estar disponíveis para leitura e escrita.

Os cenários de utilização de exemplo para a escalagem de atalho incluem:

  • Dados que estão em utilização ativa ou que se espera que sejam lidos e escritos frequentemente.
  • Dados faseados para o processamento e uma eventual migração para a escalão de acesso fixe.

Os cenários de utilização da escalagem de acesso Fixe incluem:

  • Cópia de segurança de dados a curto prazo e recuperação após desastre.
  • Conjuntos de dados mais antigos que não são utilizados frequentemente, mas espera-se que esteja disponível para acesso imediato.
  • Grandes conjuntos de dados que precisam de ser armazenados de uma forma custo-eficaz enquanto estão a ser recolhidos dados adicionais para processamento.

Os dados na escalão Cool têm uma disponibilidade ligeiramente inferior, mas oferecem a mesma durabilidade elevada, latência de recuperação e características de débito que a escalão de ataço. Para os dados na escalagem Cool, uma disponibilidade ligeiramente mais baixa e custos de acesso mais elevados podem ser trade-offs aceitáveis para custos de armazenamento gerais mais baixos, em comparação com a escalagem de quente. Para obter mais informações, consulte SLA para armazenamento.

Um blob na escalão Interessante numa conta v2 para fins gerais está sujeito a um problema de eliminação antecipada se for eliminado ou movido para uma escalão diferente antes de decorridos 30 dias. Esta cobrana é favorecida. Por exemplo, se um blob for movido para a escarpa Fixe e, em seguida, for eliminado após 21 dias, ser-lhe-ão cobrados uma taxa de eliminação antecipada equivalente a 9 (30 menos 21) dias de armazenar esse blob na escarpa Fixe.

Os níveis de Atalho e Arrefecimento suportam todas as configurações de redundância. Para obter mais informações sobre as opções de redundância de dados no Azure Armazenamento, consulte O Azure Armazenamento redundância.

Escalão de acesso de arquivo

A escalão Arquivo é uma escalão offline para armazenar dados a que raramente é acededo. A camada de Acesso de arquivo tem o custo de armazenamento mais baixo, mas uma latência e custos de recuperação de dados mais elevados em comparação com os níveis de Atalho e Arrefecimento. Os cenários de utilização de exemplo para a escalão de acesso de Arquivo incluem:

  • Cópia de segurança a longo prazo, cópia de segurança secundária e conjuntos de dados de arquivo
  • Dados originais (não processados) que têm de ser preservados, mesmo depois de estes ter sido processados no formato de utilizador final
  • Dados de conformidade e arquivo que precisam de ser armazenados durante muito tempo e que raramente são acededos

Os dados têm de permanecer na escalão Arquivo durante, pelo menos, 180 dias ou estar sujeitos a uma cobrança de eliminação antecipada. Por exemplo, se um blob for movido para a escalão Arquivo e, em seguida, eliminado ou movido para a escalagem de Atalho após 45 dias, ser-lhe-à cobrada uma taxa de eliminação antecipada equivalente a 135 (180 menos 45) dias após o armazenar esse blob na escalagem arquivo.

Enquanto um blob estiver na escalão Arquivo, não pode ser lido ou modificado. Para ler ou transferir um blob na escarla do Arquivo, primeiro tem de o recalcar para uma escaleira online, quer seja quente ou fixe. Os dados na escalão Arquivo podem demorar até 15 horas a re hidratar, dependendo da prioridade que especificar para a operação de re hidratação. Para obter mais informações sobre a re hidratação blob, consulte Overview of blob re hidation from the Archive tier.

Os metadados de um blob arquivado permanecem disponíveis para acesso de leitura, para que possa listar o blob e as res suas propriedades, metadados e etiquetas de índice. Os metadados de um blob na escalão Arquivo são só de leitura, enquanto as etiquetas de índice blob podem ser lidas ou escritas. Os instantâneos não são suportados para blobs arquivados.

As seguintes operações são suportadas para os blobs na escalagem Arquivo:

Nota

A nível de arquivo não é suportada para contas ZRS, GZRS ou RA-GZRS. A migração do LRS para o GRS é suportada desde que não foram movidos blobs para a escalão Arquivo enquanto a conta estava definida para LRS. Uma conta pode ser movida novamente para o GRS se a atualização for efetuada menos de 30 dias depois de a conta se tornar no LRS e não tiver sido movido nenhum blobs para a escalão Arquivo enquanto a conta estava definida como LRS.

Definição de nível de acesso à conta predefinida

Armazenamento contas têm uma definição de escalão de acesso predefinida que indica a escalagem online na qual é criado um novo blob. A predefinição da escalão de acesso pode ser definida como Quente ou Fixe. Os utilizadores podem alterar a predefinição de um blob individual ao carregar o blob ou ao alterar a resceção.

Por predefinição, a escalão de acesso para uma nova conta de armazenamento v2 para fins gerais está definida para a escalagem de atah. Pode alterar a definição de nível de acesso predefinida quando cria uma conta de armazenamento ou após a mesma ser criada. Se não alterar esta definição na conta de armazenamento ou definir explicitamente a escaraça ao carregar um blob, é carregado um novo blob para a escalagem de atalho por predefinição.

Um blob que não tem uma escalão explicitamente atribuída infere a sua escalão a partir da definição de nível de acesso à conta predefinida. Se a escalão de acesso de um blob for inferida a partir da definição de nível de acesso à conta predefinida, o portal do Azure apresenta a escalão de acesso como Quente (inferida) ou Baixa (inferida).

A alteração da definição da escalão de acesso predefinida de uma conta de armazenamento aplica-se a todos os blobs na conta para a qual uma escalagem de acesso não foi explicitamente definida. Se alternar a definição da escalão de acesso predefinida de Atalho para Fixe numa conta v2 para fins gerais, é-lhe cobrada as operações de escrita (por 10 000) para todos os blobs para os quais a escalagem de acesso é inferida. São cobradas tanto pelas operações de leitura (por 10.000) como pela recolha de dados (por GB) se alternar do modo Fixe para Hot numa conta v2 para fins gerais.

Quando cria uma conta de Blob legada Armazenamento, tem de especificar a definição de escalão de acesso predefinida como Hot ou Cool no momento da criação. Não é cobrado por alterar a definição da escalão de acesso de conta predefinida de Hot to Cool numa conta de Blob legada Armazenamento conta. É cobrado tanto pelas operações de leitura (por 10.000) como pela recolha de dados (por GB) se alternar entre Refrescar e Quente numa conta de Blob Armazenamento. A Microsoft recomenda a utilização de contas de armazenamento v2 para fins gerais em vez de Blob Armazenamento contas sempre que possível.

Nota

A escalagem de Arquivo não é suportada como a escalão de acesso predefinida para uma conta de armazenamento.

Definir ou alterar a escarma de um blob

Para definir explicitamente a escalão de um blob ao criá-lo, especifique a escalena quando carregar o blob.

Após a criação de um blob, pode alterar a sua escalena de uma das seguintes formas:

  • Ao chamar a operação Definir Escalão de Blob, direta ou através de uma política de gestão do ciclo de vida. O Conjunto de Chamadas Escalão de Blob normalmente é a melhor opção quando está a alterar a escaleira de um blob de uma mais quente para uma mais fixe.
  • Ao chamar a operação Copiar Blob para copiar um blob de um escalão para outro. O Blob de Chamadas Copiar é recomendado para a maioria dos cenários em que está a re hidratar um blob a partir da escaleira Arquivo para uma escaleira online ou para mover um blob de Cool para Hot. Ao copiar um blob, pode evitar o período de eliminação antecipado, se o intervalo de armazenamento necessário para o blob de origem ainda não tiver decorrido. No entanto, copiar um blob resulta em encargos de capacidade de dois blobs, o blob de origem e o blob de destino.

Alterar a escaleira de um blob de Ativo para Fixe ou Arquivo é instantâneo, tal como mudar de Fixe para Mais Quente. Re hidratar um blob da escaleira de Arquivo para a escaleira quente ou fixe pode demorar até 15 horas.

Tenha em atenção os seguintes pontos ao mover um blob entre as camadas De Arrefecimento e Arquivo:

  • Se a escalagem de um blob for inferida como Cool com base na escalagem de acesso predefinida da conta de armazenamento e o blob for movido para a escalão Arquivo, não existe qualquer cobrança de eliminação antecipada.
  • Se um blob for explicitamente movido para a escalão Arrefecimento e, em seguida, movido para a escalão Arquivo, é aplicada a cobrança de eliminação antecipada.

A tabela seguinte resume as abordagens que pode seguir para mover blobs entre vários níveis.

Origem/Destino Escalão de quente Escalão fixe Escalão de arquivo
Escalão de quente N/D Altere a escaleira de um blob de Hot to Cool com Definir Escalão de Blob ou Copiar Blob. Saiba mais...

Mova blobs para a escalão Fixe com uma política de gestão do ciclo de vida. Saiba mais...
Altere a escaleira de um blob de Ativo para Arquivo com Definir Escalão de Blob ou Copiar Blob. Saiba mais...

Arquive blobs com uma política de gestão do ciclo de vida. Saiba mais...
Escalão fixe Altere a escaleira de um blob de Fixe para Quente com Definir Escalão de Blob ou Copiar Blob. Saiba mais...

Mova blobs para a escalão de atalho com uma política de gestão do ciclo de vida. Saiba mais...
N/D Altere a escaleira de um blob de Fixe para Arquivo com Definir Escalão de Blob ou Copiar Blob. Saiba mais...

Arquive blobs com uma política de gestão do ciclo de vida. Saiba mais...
Escalão de arquivo Re hidratar para Escalão, com Definir Escalão de Blobou Copiar Blob. Saiba mais... Re hidratar para o escalão Fixe com Definir Escalão de Blobou Copiar Blob. Saiba mais... N/D

Gestão do ciclo de vida do Blob

A gestão do ciclo de vida de armazenamento de blob oferece uma política baseada em regras que pode utilizar para fazer a transição dos seus dados para a escalão de acesso pretendida quando as condições especificadas são cumpridas. Também pode utilizar a gestão do ciclo de vida para expirar dados no fim da sua vida. Consulte Otimizar custos automatizando o Blob do Azure Armazenamento níveis de acesso para saber mais.

Nota

Os dados armazenados numa conta de armazenamento blob de bloco premium não podem ser representados como Hot, Cool ou Archive utilizando Definir Escalão de Blob ou utilizando o Blob do Azure Armazenamento gestão do ciclo de vida. Para mover dados, tem de copiar sincronicamente blobs da conta de armazenamento blob de bloco para a escalagem de atalho numa conta diferente através da API Colocar Bloco A partir do URL ou uma versão da AzCopy que suporte esta API. A API Colocar Bloco a Partir da API de URL copia sincronizadamente os dados no servidor, o que significa que a chamada é concluída apenas quando todos os dados são movidos da localização do servidor original para a localização de destino.

Resumo das opções de escalão de acesso

A seguinte tabela resume as funcionalidades dos níveis de acesso aTivo, Fixe e Arquivo.

Escalão de quente Escalão fixe Escalão de arquivo
Disponibilidade 99.9% 99% Offline
Disponibilidade
(O RA-GRS lê)
99.99% 99.9% Offline
Encargos de utilização Custos de armazenamento mais elevados, mas menos custos de acesso e transação Custos de armazenamento mais baixos, mas custos de acesso e transações mais elevados Custos de armazenamento mais baixos, mas maior acesso e custos de transações
Período de retenção de dados recomendado mínimo N/D 30 dias1 180 dias
Latência
(Hora do primeiro byte)
Milissegundos Milissegundos Horas2
Configurações de redundância suportadas Tudo Tudo Apenas LRS, GRS e RA-GRS3

1 Os objetos na escalão Fixe para contas v2 para fins gerais têm uma duração de retenção mínima de 30 dias. Para contas de Blob Armazenamento, não existe uma duração de retenção mínima para a escalão Fixe.

2 Ao re hidratar um blob a partir da escaleira arquivo, pode escolher uma opção de prioridade padrão ou de re hidratação alta. Cada uma oferece custos e atrasos de recuperação diferentes. Para obter mais informações, consulte Overview of blob re hidraation from the Archive tier.

3 Para obter mais informações sobre configurações de redundância no Azure Armazenamento, consulte O Azure Armazenamento redundância.

Preços e faturação

Todas as contas de armazenamento utilizam um modelo de preços para bloquear armazenamento blob baseado na escalagem de um blob. Tenha em atenção as considerações de faturação descritas nas secções seguintes.

Para obter mais informações sobre preços para blobs bloqueados, consulte Bloquear preços de blob.

Armazenamento custos de capacidade

Além da quantidade de dados armazenados, o custo do armazenamento de dados varia consoante a escalão de acesso. O custo da capacidade por gigabyte diminui à medida que a escalão fica mais fixe.

Custos de acesso a dados

Os custos de acesso a dados aumentam à medida que a escalão fica mais fixe. Para os dados na escalão de acesso De Arrefecimento e Arquivo, é-lhe cobrada uma cobradora de acesso a dados por gigabyte para leituras.

Custos da transação

Uma cobrana por transação aplica-se a todas as camadas e aumenta à medida que a camada fica mais fixe.

Custos de transferência de dados de replicação geográfico

Esta cobrança só se aplica a contas com a replicação geográfico configurada, incluindo GRS e RA-GRS. A transferência de dados de replicação geográfico implica uma cobrança por gigabyte.

Custos de transferência de dados de saída

As transferências de dados de saída (dados transferidos de uma região do Azure) incorrem na faturação da utilização da largura de banda por gigabyte. Para obter mais informações sobre custos de transferência de dados, consulte Página Detalhes dos Preços de Largura de Banda.

Alterar a escalão de acesso de conta predefinida

Alterar a escalão de acesso à conta resulta nos encargos de alteração de nível de todos os blobs que ainda não têm uma escalão definida explicitamente. Para obter mais informações, consulte a secção seguinte, Alterar a divisão de acesso de um blob.

Alterar a escalão de acesso de um blob

Tenha em atenção os seguintes impactos de faturação ao alterar a escalagem de um blob:

  • Quando um blob é carregado ou movido entre camadas, é cobrado à taxa correspondente imediatamente após o carregamento ou alteração de camada.
  • Quando um blob é movido para uma escarma mais cool (Hot to Cool, Hot to Archive ou Cool to Archive), a operação é faturada como uma operação de escrita para a escalão de destino, onde são aplicadas as taxas de escrita da operação de escrita (por 10 000) e escrita de dados (por GB) da escalão de destino.
  • Quando um blob é movido para uma escalão mais quente (Arquivo para Arrefecer, Arquive para Ativado ou Refrescar para Quente), a operação é faturada como uma leitura a partir da escalão de origem, onde a operação de leitura (por 10.000) e os encargos de recolha de dados (por GB) da escaleira de origem são aplicáveis. Também poderão aplicar-se taxas de eliminação antecipadas de quaisquer blobs movidos da escalão Cool ou Archive.
  • Enquanto um blob está a ser re hidratado a partir da escarla de Arquivo, os dados do blob são faturados como dados arquivados até que os dados sejam restaurados e a escarma do blob muda para Hot ou Cool.

A tabela seguinte resume a forma como as alterações de nível são faturadas.

Escrever encargos (operação + acesso) Ler custos (operação + acesso)
Definir operação Blob Tier Aqueça-se até ao mais fixe
Ativado para Arquivar
Refrescante para Arquiver
Arquive como Porreiro
Arquive para ativado
Do mais fixe ao Mais

Alterar a escalagem de acesso de um blob quando o esboço de versões está ativado ou, se o blob tiver instantâneos, poderá resultar em encargos adicionais. Para obter informações sobre blobs com o sistema de versões ativado, consulte Preços e faturação na documentação do blob de versões. Para obter informações sobre blobs com instantâneos, consulte Preços e faturação na documentação de instantâneos do blob.

Suporte de funcionalidades

Esta tabela mostra como esta funcionalidade é suportada na sua conta e o impacto no suporte quando ativa determinadas funcionalidades.

Armazenamento de conta Blob Armazenamento (suporte predefinido) Data Lake Armazenamento Gen2 1 NFS 3.0 1 SFTP 1
Objetivo geral padrão v2 Sim Sim Sim Sim
Premium blobs Não Não Não Não

1 O Protocolo SFTP (Data Lake Armazenamento Gen2, Network File System (NFS) 3.0 e o protocolo SSH File Transfer Protocol (SFTP) necessitam de uma conta de armazenamento com um espaço de nomes hierárquico ativado.

Para obter informações sobre o suporte de funcionalidades por região, consulte Produtos do Azure disponíveis por região.

Passos seguintes