Armazenamento standard com acesso esporádico no Azure NetApp Files
Usando o armazenamento padrão do Azure NetApp Files com acesso legal, você pode configurar dados inativos para mover do armazenamento de nível de serviço do Azure NetApp Files Standard (a camada quente) para uma conta de armazenamento do Azure (a camada legal). A habilitação do acesso legal move os blocos de dados inativos do volume e os instantâneos do volume para a camada fria, resultando em economia de custos.
A maioria dos dados frios está associada a dados não estruturados. Ele pode representar mais de 50% da capacidade total de armazenamento em muitos ambientes de armazenamento. Dados acessados com pouca frequência associados a software de produtividade, projetos concluídos e conjuntos de dados antigos são um uso ineficiente de um armazenamento de alto desempenho.
Os Arquivos NetApp do Azure dão suporte a três níveis de serviço que podem ser configurados no nível do pool de capacidade (Standard, Premium e Ultra). O acesso fresco é um serviço adicional apenas no nível de serviço Padrão.
O diagrama a seguir ilustra um aplicativo com um volume habilitado para acesso legal.
Na gravação inicial, os blocos de dados recebem um valor de temperatura "quente" (no diagrama, blocos de dados vermelhos) e existem na camada "quente". Como os dados residem no volume, uma verificação de temperatura monitora a atividade de cada bloco. Quando um bloco de dados está inativo, a verificação de temperatura diminui o valor do bloco até que ele fique inativo pelo número de dias especificado no período de resfriamento. O período de arrefecimento pode ser entre 7 e 183 dias; Tem um valor padrão de 31 dias. Uma vez marcada como "fria", a verificação hierárquica coleta blocos e os empacota em objetos de 4 MB, que são movidos para o armazenamento do Azure de forma totalmente transparente. Para o aplicativo e os usuários, esses blocos legais ainda aparecem online. Os dados hierárquicos parecem estar on-line e continuam disponíveis para usuários e aplicativos por meio de recuperação transparente e automatizada da camada legal.
Por Default (a menos que a política de recuperação de acesso legal seja configurada de outra forma), os blocos de dados na camada fria que são lidos aleatoriamente novamente se tornam "quentes" e são movidos de volta para a camada ativa. Uma vez marcados como quentes, os blocos de dados são novamente submetidos à verificação de temperatura. No entanto, grandes leituras sequenciais (como verificações de índice e antivírus) em dados inativos na camada legal não "aquecem" os dados nem acionam dados inativos para serem movidos de volta para a camada ativa. Além disso, leituras sequenciais para Arquivos NetApp do Azure, replicação entre regiões ou replicação entre zonas não "aquecem" os dados.
Importante
Se você estiver usando um serviço de backup de terceiros, configure-o para usar NDMP em vez dos protocolos CIFS ou NFS. As leituras NDMP não afetam a temperatura dos dados.
Os metadados nunca são arrefecidos e permanecem sempre no nível quente. Como tal, as atividades de cargas de trabalho com uso intensivo de metadados (por exemplo, ambientes de alta contagem de arquivos, como design de chips, VCS e diretórios base) não são afetadas pela hierarquização.
Regiões suportadas
O armazenamento padrão com acesso fresco é suportado para as seguintes regiões:
- Austrália Central
- Austrália Central 2
- Leste da Austrália
- Austrália Sudeste
- Sul do Brasil
- Brasil Sudeste
- Canadá Central
- Leste do Canadá
- Índia Central
- E.U.A. Central
- Ásia Leste
- E.U.A. Leste
- E.U.A. Leste 2
- França Central
- Norte da Alemanha
- Alemanha Centro-Oeste
- Israel Central
- Leste do Japão
- Oeste do Japão
- Coreia do Sul Central
- Sul da Coreia do Sul
- E.U.A. Centro-Norte
- Europa do Norte
- Leste da Noruega
- Oeste da Noruega
- Catar Central
- Norte da África do Sul
- E.U.A. Centro-Sul
- Sul da Índia
- Sudeste Asiático
- Norte da Suíça
- Oeste da Suíça
- Suécia Central
- E.A.U. Central
- Norte dos E.A.U.
- Sul do Reino Unido
- Oeste do Reino Unido
- US Gov - Arizona
- US Gov - Texas
- US Gov - Virginia
- Europa Ocidental
- E.U.A. Oeste
- E.U.A. Oeste 2
- EUA Oeste 3
Efeitos do acesso legal nos dados
Esta seção descreve um teste de aquecimento de grande duração e grande conjunto de dados. Ele mostra um cenário de exemplo de um conjunto de dados em que 100% dos dados estão na camada legal e como eles aquecem ao longo do tempo.
Os dados acessados aleatoriamente típicos começam como parte de um conjunto de trabalho (leitura, modificação e gravação). À medida que os dados perdem relevância, tornam-se "cool" e acabam por ser hierarquizados para o nível cool.
Dados frios podem ficar quentes novamente. Não é típico que todo o conjunto de trabalho comece frio, mas existem alguns cenários, por exemplo, auditorias, processamento de fim de ano, processamento de fim de trimestre, ações judiciais e revisões de licenciamento de fim de ano.
Este cenário fornece informações sobre o comportamento de desempenho de aquecimento de um conjunto de dados 100% resfriado. O insight se aplica seja uma pequena porcentagem ou todo o conjunto de dados.
Teste de leitura aleatória 4k
Esta seção descreve um teste de leitura aleatória de 4k em 160 arquivos, totalizando 10 TB de dados.
Configurar
Tamanho do pool de capacidade: pool de capacidade de 100 TB
Capacidade alocada por volume: volumes de 100 TB
Conjunto de dados de trabalho: 10 TB
Nível de serviço: Armazenamento padrão com acesso fresco
Contagem de volume/tamanho: 1
Contagem de clientes: Quatro clientes padrão 8-s
OS: RHEL 8,3
Opção de montagem:rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg,hard
Metodologia
Este teste foi configurado via FIO para executar um teste de leitura aleatória de 4k em 160 arquivos que totalizam 10 TB de dados. O FIO foi configurado para ler aleatoriamente cada bloco em todo o conjunto de dados de trabalho. (Ele pode ler qualquer bloco qualquer número de vezes como parte do teste, em vez de tocar em cada bloco uma vez). Este script foi chamado uma vez a cada 5 minutos e, em seguida, um ponto de dados coletado sobre o desempenho. Quando os blocos são lidos aleatoriamente, eles são movidos para a camada quente.
Esse teste tinha um grande conjunto de dados e era executado vários dias iniciando os dados mais antigos do pior caso (todos os caches despejados). O componente de tempo do eixo X foi removido porque o tempo total para reaquecer varia devido ao tamanho do conjunto de dados. Essa curva pode ser em dias, horas, minutos ou até segundos, dependendo do conjunto de dados.
Resultados
O gráfico a seguir mostra um teste executado por mais de 2,5 dias no conjunto de dados de trabalho de 10 TB que foi 100% resfriado e os buffers limpos (dados do pior caso absoluto).
Teste de leitura sequencial de 64k
Configurar
Tamanho do pool de capacidade: pool de capacidade de 100 TB
Capacidade alocada por volume: volumes de 100 TB
Conjunto de dados de trabalho: 10 TB
Nível de serviço: Armazenamento padrão com acesso fresco
Contagem de volume/tamanho: 1
Contagem de clientes: Um grande cliente
OS: RHEL 8,3
Opção de montagem:rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg,hard
Metodologia
Os blocos lidos sequencialmente não são reaquecidos para o nível quente. No entanto, tamanhos pequenos de conjuntos de dados podem ver melhorias de desempenho devido ao cache (sem garantias de alteração de desempenho).
Este teste fornece os seguintes pontos de dados:
- Conjunto de dados de nível 100% quente
- Conjunto de dados de camada 100% legal
Este teste decorreu durante 30 minutos para obter um número de desempenho estável.
Resultados
A tabela a seguir resume os resultados do teste:
| 64-K sequencial | Taxa de transferência de leitura |
|---|---|
| Dados quentes | 1.683 MB/s |
| Dados interessantes | 899 MB/s |
Conclusões dos testes
Os dados lidos da camada legal experimentam um impacto de desempenho. Se você dimensionar seu tempo para se refrescar corretamente, então você pode não experimentar um sucesso de desempenho. Você pode ter pouco acesso à camada legal, e uma janela de 30 dias é perfeita para manter os dados quentes quentes.
Você deve evitar uma situação que gere blocos entre a camada quente e a camada fria. Por exemplo, você define uma carga de trabalho para que os dados resfriem sete dias e lê aleatoriamente uma grande porcentagem do conjunto de dados a cada 11 dias.
Em resumo, se o seu conjunto de trabalho for previsível, você pode economizar custos movendo blocos de dados acessados com pouca frequência para a camada legal. O intervalo de espera de 7 a 30 dias antes do resfriamento fornece uma grande janela para conjuntos de trabalho que raramente são acessados depois de estarem inativos ou não exigirem as velocidades mais quentes quando são acessados.
Métricas
O Cool Access oferece métricas de desempenho para entender os padrões de uso por volume:
- Tamanho da camada fria do volume
- Tamanho de leitura de dados da camada fria de volume
- Tamanho de gravação de dados da camada fria de volume
Faturação
Você pode habilitar a hierarquização no nível de volume para um pool de capacidade recém-criado que usa o nível de serviço Padrão. A forma como é faturado baseia-se nos seguintes fatores:
- A capacidade no nível de serviço padrão
- Capacidade não alocada dentro do pool de capacidade
- A capacidade no nível frio (habilitando a hierarquização para volumes em um pool de capacidade padrão)
- Transferência de rede entre o nível quente e o nível frio na taxa determinada pela marcação no topo do custo de transação (
GETPUTe solicitações) no armazenamento de blob e transferência de link privado em qualquer direção entre os níveis quentes.
O cálculo de faturamento para um pool de capacidade padrão está na taxa de nível de acesso para os dados que não são hierarquizados para o nível frio; Isso inclui a capacidade não alocada dentro do pool de capacidade. Quando você habilita a hierarquização para volumes, a capacidade na camada fria estará na taxa da camada fria e a capacidade restante será na taxa da camada quente. A taxa do nível frio é menor do que a taxa do nível quente.
Exemplos de estrutura de faturação
Suponha que você criou um pool de capacidade padrão de 4 TiB. A estrutura de faturamento está na taxa de nível de capacidade padrão para todos os 4 TiB.
Quando você cria volumes no pool de capacidade e começa a hierarquizar os dados para a camada legal, os cenários a seguir explicam a estrutura de faturamento aplicável:
Suponha que você crie três volumes com 1 TiB cada. Você não habilita a hierarquização no nível de volume. O cálculo de faturamento é o seguinte:
- 3 TiB de capacidade atribuída à taxa do nível quente
- 1 TiB de capacidade não atribuída à taxa do nível quente
- Capacidade zero à taxa de nível frio
- Transferência de rede zero entre o nível quente e o nível frio na taxa determinada pela marcação no topo do custo de transação (
GET,PUT) no armazenamento de blob e transferência de link privado em qualquer direção entre os níveis quentes.
Suponha que você crie quatro volumes com 1 TiB cada. Cada volume tem 0,25 TiB da capacidade de volume no nível quente e 0,75 TiB da capacidade de volume no nível frio. O cálculo de faturamento é o seguinte:
- Capacidade de 1 TiB na taxa de nível quente
- Capacidade de 3 TiB à taxa de nível frio
- Transferência de rede entre o nível quente e o nível frio à taxa determinada pela marcação sobre o custo de transação (
GET,PUT) no armazenamento de blob e transferência de link privado em qualquer direção entre os níveis quentes.
Suponha que você crie dois volumes com 1 TiB cada. Cada volume tem 0,25 TiB da capacidade de volume no nível quente e 0,75 TiB da capacidade de volume no nível frio. O cálculo de faturamento é o seguinte:
- Capacidade de 0,5 TiB na taxa de nível quente
- 2 TiB de capacidade não atribuída à taxa do nível quente
- Capacidade de 1,5 TiB à taxa de nível frio
- Transferência de rede entre o nível quente e o nível frio à taxa determinada pela marcação sobre o custo de transação (
GET,PUT) no armazenamento de blob e transferência de link privado em qualquer direção entre os níveis quentes.
Suponha que você crie um volume com 1 TiB. O volume tem 0,25 TiB da capacidade de volume no nível quente, 0,75 da capacidade de volume no nível frio. O cálculo de faturamento é o seguinte:
- Capacidade de 0,25 TiB na taxa de nível quente
- Capacidade de 0,75 TiB à taxa de nível frio
- Transferência de rede entre o nível quente e o nível frio à taxa determinada pela marcação sobre o custo de transação (
GET,PUT) no armazenamento de blob e transferência de link privado em qualquer direção entre os níveis quentes.
Exemplos de cálculos de custos com períodos de refrigeração variáveis
Esta seção mostra exemplos de custos de armazenamento e transferência de rede com períodos de resfriamento variáveis.
Nestes exemplos, assuma:
- O custo de armazenamento de nível quente é de US$ 0,000202/GiB/hr. O custo de armazenamento de nível legal é de US$ 0,000082/GiB/hr.
- O custo de transferência de rede (incluindo atividades de leitura ou gravação do nível legal) é de US$ 0,020000/GiB.
- Você tem uma piscina de capacidade de 5 TiB com acesso legal habilitado.
- Você tem 1 TiB de capacidade não alocada dentro do pool de capacidade
- Você tem um volume de 4 TiB habilitado para acesso legal.
- 3 TiB dos 4 TiB são movidos para o nível frio após o período de refrigeração.
- Você lê ou grava 20% dos dados por mês a partir da camada legal.
- Cada mês é de 30 dias ou 730 horas. Assim, cada dia é de 730/30 horas.
Importante
- Estes cálculos devem ser utilizados apenas como estimativa de referência e não para validar a exatidão do valor da fatura.
- As taxas consideradas nos exemplos são para uma região de exemplo e podem ser diferentes para a região de implantação pretendida.
- Se os dados forem lidos ou gravados na camada legal, isso fará com que a porcentagem de distribuição de dados na camada quente e na camada fria seja alterada. Os cálculos neste artigo demonstram a distribuição percentual inicial nas camadas quente e fria, e não depois que os 20% dos dados foram movidos para ou da camada fria.
Nota
Os exemplos a seguir incluem 1 TiB de espaço não alocado no pool de capacidade para mostrar como o espaço não alocado é cobrado quando o acesso legal está habilitado. Para maximizar suas economias, o tamanho do pool de capacidade deve ser reduzido para eliminar a capacidade não alocada do pool.
Exemplo 1: O período de arrefecimento está definido para 7 dias
Seu custo de armazenamento para o primeiro mês seria:
| Custo | Description | Cálculo |
|---|---|---|
| Custo de armazenamento não alocado para o Dia 1~30 (30 dias) | 1 TiB de armazenamento não alocado | 1 TiB x 1024 x 30 days x 730/30 hrs. x $0.000202/GiB/hr. = $151.00 |
| Custo de armazenamento para o Dia 1~7 (sete dias) | 4 TiB de dados ativos (camada quente) | 4 TiB x 1024 x 7 days x 730/30 hrs. x $0.000202/GiB/hr. = $140.93 |
| Custo de armazenamento para o Dia 8~30 (23 dias) | 1 TiB de dados ativos (hot tier) 3 TiB de dados inativos (camada legal) |
1 TiB x 1024 x 23 days x 730/30 hrs. x $0.000202/GiB/hr. = $115.77 3 TiB x 1024 x 23 days x 730/30 hrs. x $0.000082/GiB/hr. = $140.98 |
| Custo de transferência de rede | Movendo dados inativos para a camada fria 20% dos dados são lidos/gravados a partir do nível Cool |
3 TiB x 1024 x $0.020000/GiB = $61.44 3 TiB x 1024 x 20% x $0.020000/GiB = $12.29 |
| Total do primeiro mês | $622.41 |
Seu custo mensal de armazenamento para o segundo mês e meses subsequentes seria:
| Custo | Description | Cálculo |
|---|---|---|
| Custo de armazenamento por 30 dias | 1 TiB de armazenamento não alocado 1 TiB de dados ativos (hot tier) 3 TiB de dados inativos (camada legal) |
1 TiB x 1024 x 30 days x 730/30 hrs. x $0.000202/GiB/hr. = $151.00 1 TiB x 1024 x 30 days x 730/30 hrs. x $0.000202/GiB/hr. = $151.00 3 TiB x 1024 x 30 days x 730/30 hrs. x $0.000082/GiB/hr. = $183.89 |
| Custo de transferência de rede | 20% dos dados são lidos/gravados a partir do nível Cool | 3 TiB x 1024 x 20% x $0.020000/GiB = $12.29 |
| Segundo total mensal e subsequente | $498.18 |
As suas primeiras poupanças semestrais:
- Custo sem acesso fresco:
5 TiB x 1024 x $0.000202/GiB/hr. x 730 hrs. x 6 months = $4,529.97 - Custo com acesso legal:
First month + Second month + … + Sixth month = $622.41 + (5x $498.18) = $3,113.31 - Economia usando acesso legal:
31.27%
A sua primeira poupança de doze meses:
- Custo sem acesso fresco:
5 TiB x 1024 x $0.000202/GiB/hr. x 730 hrs. x 12 months = $9,059.94 - Custo com acesso legal:
First month + Second month + … + twelfth month = $622.41 + (11 x $498.18) = $6,102.39 - Economia usando acesso legal:
32.64%
Exemplo 2: O período de arrefecimento está definido para 35 dias
Todos os 5 TiB são dados ativos (em nível quente) para o primeiro mês. Seu custo de armazenamento para o primeiro mês seria: 5 TiB x 1024 x 730hr. x $0.000202/GiB/hr. = $755.00
Seu custo de armazenamento para o segundo mês seria:
| Custo | Description | Cálculo |
|---|---|---|
| Custo de armazenamento não alocado para o Dia 1~30 (30 dias) | 1 TiB de armazenamento não alocado | 1 TiB x 1024 x 30 days x 730/30 hrs. x $0.000202/GiB/hr. = $151.00 |
| Custo de armazenamento para o Dia 1~5 (cinco dias) | 4 TiB de dados ativos (camada quente) | 4 TiB x 1024 x 5 days x 730/30 hrs. x $0.000202/GiB/hr. = $100.67 |
| Custo de armazenamento para o Dia 6~30 (25 dias) | 1 TiB de dados ativos (hot tier) 3 TiB de dados inativos (camada legal) |
1 TiB x 1024 x 25 days x 730/30 hrs. x $0.000202/GiB/hr. = $125.83 3 TiB x 1024 x 25 days x 730/30 hrs. x $0.000082/GiB/hr. = $153.24 |
| Custo de transferência de rede | Movendo dados inativos para a camada fria 20% dos dados são lidos/gravados a partir do nível Cool |
3 TiB x 1024 x $0.020000 /GiB = $61.44 3 TiB x 1024 x 20% x $0.020000/GiB = $12.29 |
| Total do segundo mês | $604.47 |
Seu custo mensal de armazenamento para o terceiro mês e meses subsequentes seria:
| Custo | Description | Cálculo |
|---|---|---|
| Custo de armazenamento por 30 dias | 1 TiB de armazenamento não alocado 1 TiB de dados ativos (hot tier) 3 TiB de dados inativos (camada legal) |
1 TiB x 1024 x 30 days x 730/30 hrs. x $0.000202/GiB/hr. = $151.001 TiB x 1024 x 30 days x 730/30 hrs. x $0.000202/GiB/hr. = $151.00 3 TiB x 1024 x 30 days x 730/30 hrs. x $0.000082/GiB/hr. = $183.89 |
| Custo de transferência de rede | 20% dos dados são lidos/gravados a partir do nível Cool | 3 TiB x 1024 x 20% x $0.020000/GiB = $12.29 |
| Total mensal terceiro e subsequente | $498.18 |
As suas primeiras poupanças semestrais:
- Custo sem acesso fresco:
5 TiB x 1024 x $0.000202/GiB/hr. x 730 hrs. x 6 months = $4,529.97 - Custo com acesso legal:
First month + Second month + … + Sixth month = $755.00 + $604.47 + (4 x $498.18) = $3,352.19 - Economia usando acesso legal:
25.99%
A sua primeira poupança de doze meses:
- Custo sem acesso fresco:
5 TiB x 1024 x $0.000202/GiB/hr. x 730 hrs. x 12 months = $9,059.94 - Custo com acesso legal:
First month + Second month + … + twelfth month = $755.00 + $604.47 + (10 x $498.18) = $6,341.27 - Economia usando acesso legal:
30.00%
Exemplo 3: O período de arrefecimento é definido como 63 dias
Todos os 5 TiB são dados ativos (em nível quente) para os primeiros dois meses. Seu custo mensal de armazenamento para o primeiro e segundo meses seria: 5 TiB x 1024 x 730hr. x $0.000202/GiB/hr. = $755.00
Seu custo de armazenamento para o terceiro mês seria:
| Custo | Description | Cálculo |
|---|---|---|
| Custo de armazenamento não alocado para o Dia 1~30 (30 dias) | 1 TiB de armazenamento não alocado | 1 TiB x 1024 x 30 days x 730/30 hrs. x $0.000202/GiB/hr. = $151.00 |
| Custo de armazenamento para o Dia 1~3 (três dias) | 4 TiB de dados ativos (camada quente) | 4 TiB x 1024 x 3 days x 730/30 hrs. x $0.000202/GiB/hr. = $60.40 |
| Custo de armazenamento para o Dia 4~30 (27 dias) | 1 TiB de dados ativos (hot tier) 3 TiB de dados inativos (camada legal) |
1 TiB x 1024 x 27 days x 730/30 hrs. x $0.000202/GiB/hr. = $135.90 3 TiB x 1024 x 27 days x 730/30 hrs. x $0.000082/GiB/hr. = $165.50 |
| Custo de transferência de rede | Movendo dados inativos para a camada fria 20% dos dados são lidos/gravados a partir do nível Cool |
3 TiB x 1024 x $0.020000/GiB = $61.44 3 TiB x 1024 x 20% x $0.020000/GiB = $12.29 |
| Total do terceiro mês | $586.52 |
Seu custo mensal de armazenamento para o quarto mês e subsequentes seria:
| Custo | Description | Cálculo |
|---|---|---|
| Custo de armazenamento por 30 dias | 1 TiB de armazenamento não alocado 1 TiB de dados ativos (hot tier) 3 TiB de dados inativos (camada legal) |
1 TiB x 1024 x 30 days x 730/30 hrs. x $0.000202/GiB/hr. = $151.00 1 TiB x 1024 x 30 days x 730/30 hrs. x $0.000202/GiB/hr. = $151.00 3 TiB x 1024 x 30 days x 730/30 hrs. x $0.000082/GiB/hr. = $183.89 |
| Custo de transferência de rede | 20% dos dados são lidos/gravados a partir do nível Cool | 3 TiB x 1024 x 20% x $0.020000/GiB = $12.29 |
| Quarto total mensal e subsequente | $498.18 |
As suas primeiras poupanças semestrais:
- Custo sem acesso fresco:
5 TiB x 1024 x $0.000202/GiB/hr. x 730 hrs. x 6 months = $4,529.97 - Custo com acesso legal:
First month + Second month + … + Sixth month = (2 x $755.00) + $586.52 + (3 x $498.18) = $3,591.06 - Economia usando acesso legal:
20.73%
A sua primeira poupança de doze meses:
- Custo sem acesso fresco:
5 TiB x 1024 x $0.000202/GiB/hr. x 730 hrs. x 12 months = $9,059.94 - Custo com acesso legal:
First month + Second month + … + twelfth month = (2 x $755.00) + $586.52 + (9 x $498.18) = $6,580.14 - Economia usando acesso legal:
27.37%
Gorjeta
Você pode usar o armazenamento padrão do Azure NetApp Files com o estimador de economia de custos de acesso legal para estimar interativamente as economias de custos com base em parâmetros de entrada alteráveis.