Projete armazenamento de dados com Armazenamento do Azure, blobs, arquivos e discos gerenciados
Converta formato dos dados, padrão de acesso, durabilidade, desempenho, custo e segurança em uma arquitetura de armazenamento defensável no Azure.
Tempo de estudo sugerido: 86 minutos • Nível intermediário • Reescrita autoral completa com resumo conciso de cada tópico
Por João Ricardo Dutra••Conteúdo autoral completo
1. Comece o design pelo formato e pelo acesso aos dados
Um design de armazenamento começa pela informação, não pelo nome de um produto. Configurações, faturas e registros financeiros altamente organizados se comportam de modo diferente de desenhos de engenharia, vídeos, documentos de escritório ou arquivos compartilhados com parceiros. O arquiteto classifica estrutura, caminho de acesso, latência, durabilidade, retenção, geografia, segurança e custo de cada conjunto.
Considere uma varejista global consolidando mídia de produtos, arquivos operacionais e dados de máquinas virtuais. A solução deve escalar sem perder controle de residência, desempenho, proteção ou gastos. Este capítulo relaciona esses requisitos a contas de armazenamento, ,,, e seus controles de segurança.
Classificar dados estruturados, semiestruturados e não estruturados.
Selecionar objetos e tipos de conta de armazenamento.
Projetar redundância primária e secundária.
Escolher camadas de acesso e imutabilidade para blobs.
Projetar compartilhamentos e discos gerenciados.
Proteger identidades, redes, transporte e chaves.
São pré-requisitos recomendados: familiaridade com assinaturas, contas de armazenamento, blobs, compartilhamentos, máquinas virtuais e conceitos básicos de proteção de dados.
Resumo do tópico
Classifique os dados e suas exigências operacionais antes de comparar serviços de armazenamento.
2. Dados estruturados compartilham um esquema fixo
Dados estruturados seguem um modelo comum: tabelas expõem linhas, colunas, tipos, chaves e relações conhecidos antes da gravação. Registros médicos, catálogos telefônicos, contas financeiras e transações comerciais são exemplos. Um banco relacional costuma ser o primeiro candidato quando consistência, junções e transações predominam.
Resumo do tópico
Esquema estável e relações explícitas geralmente indicam uma plataforma relacional, não armazenamento de objetos ou arquivos.
3. Dados semiestruturados carregam sua organização
Informações semiestruturadas não cabem em uma tabela rígida, mas tags ou campos descrevem o significado. , e são exemplos comuns. O esquema pode variar entre registros, favorecendo repositórios de documentos, objetos ou análise que aceitem evolução sem redesenhar cada linha.
Resumo do tópico
Dados semiestruturados têm campos reconhecíveis, porém não devem ser forçados a um modelo desnecessariamente rígido.
4. Dados não estruturados não têm modelo relacional uniforme
Fotos, áudio, vídeo, PDF, texto, documentos do Word e apresentações contêm informação sem uma relação consistente de linhas e colunas. Normalmente são acessados como objetos ou arquivos. “Não estruturado” não significa sem gestão: , indexação, retenção, classificação e autorização continuam essenciais.
A estrutura reduz as opções; semântica de acesso e desempenho concluem a decisão.
Resumo do tópico
Conteúdo não estruturado ainda exige e governança, mas objetos ou arquivos combinam melhor com seu acesso.
5. Relacione objetos de armazenamento à semântica da carga
Objetos centrais de armazenamento do .
Objeto
Melhor uso
Comportamento
Grandes volumes de texto e binários não estruturados: documentos, imagens, áudio e vídeo.
de objeto, acesso sequencial ou analítico e camadas de ciclo de vida.
Diretórios compartilhados e lift-and-shift.
SMB, NFS ou ; montagem simultânea por clientes compatíveis.
Discos gerenciados
Volumes de SO e dados para do .
E/S de blocos com baixa latência.
Mensagens assíncronas duráveis e filas de trabalho.
Produtores e consumidores processam mensagens de modo independente.
Dados extensos de chave e atributos sem junções relacionais.
Acesso por chave-valor.
Não conclua que todo dado estruturado pertence a um compartilhamento nem que todo byte não estruturado pertence a um blob. nativas de arquivos, E/S aleatória de blocos, mensageria e consultas podem pesar mais que o formato.
Resumo do tópico
Escolha o objeto cuja semântica combine com a aplicação: objeto, arquivo compartilhado, disco, fila ou tabela chave-valor.
6. A conta de armazenamento é e limite de governança
Uma conta reúne serviços compatíveis e fornece um globalmente exclusivo por ou . Região, redundância, desempenho, rede, criptografia e vários limites se aplicam aos dados contidos nela. Use contas distintas quando conjuntos exigirem regiões, conformidade, desempenho, exposição pública, administradores ou ciclos de vida diferentes.
A conta não tem tarifa-base fixa; o custo vem de capacidade, transações, recuperação, replicação, transferência e recursos. Poucas contas acoplam limites e riscos; contas demais ampliam políticas, inventário e operação.
A conta combina , configuração compartilhada, limites e segurança.
Resumo do tópico
Crie limites intencionais de geografia, desempenho, segurança, propriedade, capacidade e custo.
7. Selecione o tipo de conta pelo comportamento da carga
Tipos recomendados de conta.
Tipo
Serviços
Uso de design
Uso geral v2 Standard
Blobs, inclusive , Arquivos, Filas e Tabelas.
Padrão para a maioria dos cenários e conjunto de recursos mais amplo.
Blobs de blocos Premium
Blobs de blocos e de acréscimo.
Muitas transações, objetos pequenos ou latência consistentemente baixa.
Compartilhamentos Premium
.
SMB ou NFS empresarial e de alto desempenho.
Blobs de páginas Premium
Somente blobs de páginas.
Dados esparsos, indexados e cargas especializadas.
Valide regiões, redundância, hierárquico e protocolos. O tipo preferencial escolhido no orienta a criação, mas uma conta de uso geral v2 ainda pode abrigar outros serviços compatíveis.
Resumo do tópico
Uso geral v2 atende à maioria; escolha especialização Premium apenas quando a carga justificar seu perfil mais estreito.
8. Posicionamento equilibra residência, latência, custo e operação
Região: mantenha os dados próximos de consumidores e computação dependente.
Conformidade: cumpra residência, soberania, auditoria e regras do setor.
Custo: modele capacidade, operações, recuperação, saída e replicação.
Administração: separe equipes e políticas somente quando o benefício superar a proliferação.
Sensibilidade: isole dados confidenciais e conexão privada de conteúdo público intencional.
Rateio: use conta, assinatura, grupo de recursos e tags para tornar a propriedade mensurável.
Resumo do tópico
O posicionamento combina geografia, conformidade, desempenho, custo, administração e sensibilidade.
9. A redundância cobre escopos de falha diferentes
O sempre mantém várias cópias. A opção define se elas ficam em um , atravessam zonas de disponibilidade ou são reproduzidas de forma assíncrona em uma região secundária distante. Durabilidade e disponibilidade crescem com o limite de falha, assim como custo e compromissos operacionais.
Selecione a redundância pelo maior evento que a carga deve suportar.
Resumo do tópico
Redundância é uma escolha de domínio de falha: rack, , zona ou região inteira.
10. LRS é proteção local econômica
O armazenamento com redundância local (LRS) mantém cópias síncronas em um local físico da região primária. Protege contra falhas de unidade e rack pelo menor custo, mas um desastre no pode indisponibilizar ou destruir todas as cópias. Serve para dados recriáveis ou cargas com outra cópia independente.
Resumo do tópico
LRS cobre hardware local com economia, não a perda do .
11. ZRS resiste à perda de uma zona
O armazenamento com redundância de zona (ZRS) distribui dados de forma síncrona por três zonas da região primária. Leituras e gravações continuam quando uma zona cai. É forte para residência regional e alta disponibilidade, mas não cria recuperação fora da região.
Resumo do tópico
ZRS elimina a dependência de uma zona e mantém todas as cópias na mesma região.
12. GRS e GZRS acrescentam uma região secundária
O armazenamento com redundância geográfica (GRS) usa LRS na primária; o armazenamento com redundância de zona geográfica (GZRS) usa ZRS. Ambos replicam assincronamente para uma região secundária fixa, onde as cópias são locais. O atraso cria RPO diferente de zero em um desastre regional.
Com GRS ou GZRS comuns, a secundária não é legível antes do . RA-GRS e RA-GZRS expõem um secundário somente leitura. A aplicação precisa usá-lo deliberadamente; habilitar o não implementa por si só.
Resumo do tópico
GRS e GZRS ampliam durabilidade regional; variantes RA permitem leitura pré-, ainda com possível perda assíncrona.
13. A camada de Arquivo limita o desenho de redundância
Blobs arquivados aceitam LRS, GRS e RA-GRS, mas não ZRS, GZRS ou RA-GZRS. Re-hidrate os objetos para uma camada online antes de migrar a conta para redundância de zona. Como isso pode levar horas e gerar cobrança, desenhe topologia regional e arquivamento juntos.
Resumo do tópico
Arquivo é uma camada offline econômica cujas restrições de redundância precisam ser resolvidas cedo.
14. Camadas de blobs trocam custo de capacidade por custo de acesso
Camadas de blobs de blocos.
Camada
Acesso e duração mínima
Uso típico
Quente
Online, milissegundos, sem mínimo.
Dados lidos ou alterados com frequência.
Esporádico
Online, milissegundos, mínimo de 30 dias em uso geral v2.
Acesso infrequente ainda imediatamente disponível.
Frio
Online, milissegundos, mínimo de 90 dias em uso geral v2.
Acesso raro com recuperação imediata.
Arquivo
Offline, horas para reidratar, mínimo de 180 dias.
Backup longo, fontes brutas, registros legais e históricos.
Mover ou excluir antes do mínimo pode gerar cobrança proporcional de exclusão antecipada. Camadas mais frias barateiam capacidade e encarecem transações e leitura. O gerenciamento do ciclo de vida automatiza transições e expiração de blobs de blocos. A camada inteligente pode mover dados qualificados entre Quente, Esporádico e Frio de acordo com o uso observado.
Na referência de do armazenamento Standard, a disponibilidade publicada é 99,9% para Quente e 99% para Esporádico, Frio e Arquivo; com leitura RA-GRS, os valores são 99,99% e 99,9%. Use esses números como entrada e confirme o atual da conta e redundância exatas antes de definir a meta da carga.
A camada mais fria não é automaticamente a mais barata no custo total.
Resumo do tópico
Escolha a camada pelo custo completo e pelo tempo de recuperação, não só pelo preço por GiB.
15. Quente, Esporádico e Frio permanecem online
Quente é o padrão para dados ativos. Esporádico e Frio reduzem a capacidade para dados menos lidos e mantêm recuperação online em milissegundos. Têm disponibilidade ligeiramente menor e acesso mais caro. Catálogos antigos, backups curtos e conjuntos analíticos em acumulação são candidatos quando a frequência comprova a economia.
Resumo do tópico
Esporádico e Frio economizam sem tirar dados do ar, desde que acesso e duração sustentem a escolha.
16. Arquivo exige plano explícito de reidratação
Um blob em Arquivo não pode ser lido ou alterado até ser reidratado para Quente, Esporádico ou Frio. A prioridade afeta tempo e custo, e o processo pode levar até 15 horas. É apropriado para backup secundário, entrada bruta preservada e conformidade de longo prazo com prazo de recuperação flexível. continuam legíveis; a carga útil fica offline.
Resumo do tópico
Arquivo minimiza capacidade quando o negócio aceita indisponibilidade temporária, reidratação e recuperação mais cara.
17. imutável aplica retenção WORM
Políticas WORM — gravar uma vez, ler muitas — impedem alteração ou exclusão. A retenção baseada em tempo protege por um intervalo definido; depois dele, o objeto pode ser excluído, mas não sobrescrito. Uma retenção legal continua até que tags autorizadas sejam removidas e não tem término predefinido.
A política pode atuar no contêiner ou na versão, conforme a conta. Teste antes de bloquear uma política temporal, pois o bloqueio não é simplesmente desfeito. Todas as camadas aceitam imutabilidade, mas blobs de páginas de VMs ativas são inadequados porque gravações seriam bloqueadas ou criariam versões excessivas.
A retenção temporal termina pelo calendário; a legal depende de decisão autorizada.
Resumo do tópico
Use imutabilidade para evidências e backups resistentes a alteração, governando o bloqueio como operação crítica.
18. O design de blobs combina disponibilidade, latência e custo
Disponibilidade: camadas online respondem de imediato; Arquivo não.
Latência: contas Premium visam latência baixa consistente; reidratação é medida em horas.
Custo: inclua capacidade, operações, leitura, exclusão antecipada, replicação e transferência.
Durabilidade: escolha cópias locais, zonais ou geográficas.
Imutabilidade: selecione retenção temporal ou legal pelo evento regulador.
Operação: automatize transições e exclusões com regras testadas.
Resumo do tópico
Explique tipo de conta, camada, redundância, imutabilidade, ciclo de vida e custo total em conjunto.
19. entrega sistemas de arquivos gerenciados
expõe compartilhamentos gerenciados por SMB, NFS e conforme recurso e camada. Clientes Windows, Linux e macOS compatíveis podem montar simultaneamente. O serviço substitui ou complementa servidores e NAS, hospeda configuração e ferramentas compartilhadas e atende aplicativos que esperam caminhos normais de arquivo.
Sem hardware de servidor de arquivos nem correção de sistema operacional.
Criptografia em repouso e trânsito configurável.
Opções de redundância e instantâneos.
Proteção nativa pelo .
Acesso de nuvem e local com rede adequada.
Resumo do tópico
é armazenamento compartilhado sem servidor para semântica de arquivo.
20. Montagem direta e resolvem necessidades diferentes
A montagem direta conecta clientes ao compartilhamento com SMB ou NFS e elimina o servidor. O centraliza dados SMB em enquanto um Windows Server mantém local rápido, compatibilidade e menor latência para filiais.
Use montagem direta quando os clientes alcançam o e não precisam do servidor. Use para híbrido, camada de nuvem e modernização gradual. Planeje identidade, , firewall, conexão privada e portas.
Montagem direta remove o servidor; mantém um Windows Server.
Resumo do tópico
Montagem direta é acesso sem servidor; é arquitetura híbrida de SMB.
21. Mídia e camada de acesso são decisões distintas em
Compartilhamentos SSD fornecem desempenho consistente e baixa latência para bancos, sites, desenvolvimento e E/S intensa. HDD prioriza economia geral. No modelo clássico pago conforme o uso, Otimizado para transações, Quente e Esporádico usam HDD e diferenciam preço de dados e transações. Não confunda mídia com camada de acesso.
SSD oferece SMB e NFS em modelos compatíveis. Opções georredundantes aparecem em configurações HDD compatíveis, enquanto SSD usa redundância local ou zonal. Valide protocolo, região, cobrança e redundância como uma matriz única.
Resumo do tópico
Escolha SSD ou HDD por desempenho e depois a camada e redundância disponíveis nesse modelo.
22. tem três modelos de cobrança
Modelos de cobrança.
Modelo
Funcionamento
Orientação
Provisionado v2
Provisiona capacidade, IOPS e taxa de transferência separadamente.
Recomendado para novas implantações; atende SSD e HDD compatíveis.
Pago conforme o uso
Cobra armazenamento usado, operações e transferência.
Somente HDD; útil para imprevisibilidade, porém orçamento é mais difícil.
Provisionado v1
Capacidade provisionada determina desempenho em relação fixa.
Modelo SSD herdado; use v2 salvo impedimento específico.
Resumo do tópico
Provisionado v2 é o padrão atual porque capacidade, IOPS e taxa podem ser dimensionadas separadamente.
23. Compare blobs, e
Comparação de serviços.
Serviço
Padrão de acesso
Uso representativo
Objetos sequenciais, leitura intensa e grande escala; NFS 3.0 ou quando compatível.
Análise, HPC de throughput, mídia, dados brutos, backup e arquivo.
Arquivos compartilhados aleatórios e atualizações locais por SMB, NFS 4.1 ou .
Lift-and-shift, diretórios pessoais, CMS, ERP, desenvolvimento e volumes de contêiner.
NAS empresarial de alto desempenho com SMB, NFS, protocolo duplo e gestão avançada.
Bancos sensíveis à latência, SAP HANA, HPC e migrações NAS exigentes.
Limites publicados evoluem e dependem de camada, modelo, volume e região. Faça benchmark do perfil real em vez de escolher por um único número máximo.
Objetos, compartilhamentos gerenciados e NAS Premium ocupam posições diferentes.
Resumo do tópico
Use blobs pela economia de objetos, para arquivos gerenciados e para NAS empresarial exigente.
24. Discos gerenciados fornecem blocos para VMs
Discos gerenciados são volumes virtualizados usados como SO e dados por do . O administra contas, blobs de páginas e disponibilidade subjacentes. O tamanho da VM ainda limita discos anexados, IOPS e taxa; o disco mais rápido não supera o teto da VM.
Tipos de disco gerenciado.
Tipo
Carga representativa
Bancos intensivos em E/S e transações, como SAP HANA, SQL e Oracle.
SSD Premium v2
Produção com latência, IOPS e taxa ajustáveis de forma independente.
SSD Premium
Produção e cargas sensíveis a desempenho.
SSD Standard
Servidores Web, aplicativos leves e desenvolvimento/teste.
HDD Standard
Backup e dados não críticos de acesso infrequente.
e SSD Premium v2 são discos de dados, não de SO. O suporte a HDD Standard como disco de SO será desativado em 8 de setembro de 2028; novos designs devem usar SSD adequado e migrar dependências existentes.
Resumo do tópico
Selecione disco e VM juntos por latência, IOPS, taxa, região, custo e restrições de SO/dados.
25. Camadas de criptografia de disco protegem caminhos diferentes
A criptografia do lado do servidor protege automaticamente discos de SO e com chaves da plataforma ou chaves do cliente via conjunto de criptografia de disco. O Disk Encryption cifra volumes dentro do convidado com BitLocker ou DM-Crypt. A criptografia no host cobre discos temporários, e o fluxo do host até o .
Os mecanismos se sobrepõem, mas não são iguais. Escolha por conformidade, propriedade de chave, suporte, backup e operação. Não repita a afirmação antiga de que criptografia no host desabilita a criptografia do lado do servidor; os dados de discos gerenciados permanecem cifrados em repouso.
Resumo do tópico
Separe criptografia do armazenamento, do convidado e do host e escolha a combinação compatível exigida.
26. O do host deve combinar com a E/S
O padrão comum é ReadWrite no disco de SO e ReadOnly nos discos de dados. ReadOnly acelera leitura; None serve para gravação intensa; ReadWrite exige que o aplicativo persista com segurança as gravações em . não é compatível com discos de 4 TiB ou maiores nem com .
Alterar desanexa e reanexa o disco; no disco de SO, reinicia a VM. Agende e interrompa os serviços afetados para evitar corrupção.
Resumo do tópico
melhora latência quando respeita integridade, tamanho do disco, comportamento e impacto de manutenção.
27. Segurança de armazenamento funciona em camadas
Parta da linha de base de segurança e reduza acesso permanente. Prefira e do quando disponíveis. Uma assinatura de acesso compartilhado (SAS) delega recurso, permissão, protocolo, e expiração sem revelar a chave da conta; para blobs, prefira SAS de delegação de usuário quando viável e trate toda SAS como credencial.
Identidade: , identidades gerenciadas, e privilégio mínimo.
Rede: firewalls, redes selecionadas, de serviço e pontos de extremidade privados.
Transporte: transferência segura e criptografia SMB/NFS atual.
Repouso: chaves da plataforma ou do cliente no ou gerenciado.
Governança: ,, rotação, revogação e .
Resumo do tópico
Proteja autorização, alcance de rede, transporte, chaves e governança como camadas independentes.
28. Pontos de extremidade privados removem a dependência pública
Um ponto de extremidade privado coloca uma interface de rede de um subrecurso do em uma . O tráfego permanece no backbone da Microsoft e pode vir do ambiente local por ou emparelhamento privado do ExpressRoute. O privado deve resolver o serviço para o endereço privado.
Criar o ponto não desativa automaticamente o público. Configure acesso de rede pública e firewall explicitamente. Blobs, arquivos, filas, tabelas e outros subrecursos podem exigir pontos separados.
Rota privada, identidade forte, transporte cifrado e chave controlada formam limites complementares.
Resumo do tópico
Private Link oferece rota privada; e política do público determinam se a conta é realmente privada.
29. Transferência segura e chaves do cliente ampliam controle
A transferência segura obrigatória rejeita solicitações inseguras e vem habilitada em novas contas. As configurações atuais de controlam criptografia de SMB e NFS por protocolo. Preserve o padrão salvo exceção legada documentada e controlada.
O criptografa em repouso automaticamente com chaves da Microsoft. Chaves gerenciadas pelo cliente adicionam ciclo de vida e acesso no ou , mas criam responsabilidade de disponibilidade e rotação. Exclusão da chave, perda de permissão ou indisponibilidade pode tornar dados inacessíveis.
Resumo do tópico
Exija transporte cifrado e adote chaves do cliente apenas com operação capaz de garantir disponibilidade e rotação.
30. Verificação de conhecimento: decisões da Tailwind Traders
Respostas e justificativas.
Requisito
Melhor design
Motivo
Documentos de garantia imutáveis por três anos.
Retenção imutável baseada em tempo.
O prazo é conhecido; retenção legal não tem término predefinido.
Grandes volumes de fotos e vídeos.
.
Objetos escalam para mídia não estruturada.
Fornecedor externo altera só durante o desenvolvimento.
SAS curta e de privilégio mínimo.
Delega acesso restrito sem entregar a chave.
Catálogo antigo raro, mas imediatamente disponível.
Frio ou Esporádico após análise.
Arquivo exigiria reidratação.
Operar após perda da região primária.
Georredundância e testado da aplicação.
Cópias não redirecionam tráfego nem validam a solução.
Resumo do tópico
A prova cobra comportamento: WORM, mídia em objetos, delegação temporária, dados frios online e recuperação regional.
31. Checklist de arquitetura e síntese
Inventarie dados, proprietários, esquema, crescimento, protocolos, E/S e dependências.
Escolha semântica de objeto, arquivo, bloco, fila, tabela ou banco antes do SKU.
Particione contas por região, conformidade, desempenho, sensibilidade, limites e ciclo de vida.
Documente LRS, ZRS, GRS, GZRS, leitura secundária e RPO regional.
Modele camadas, recuperação, transações, exclusão antecipada, replicação e saída.
Escolha retenção imutável ou legal e governe o bloqueio.
Teste restauração, , reidratação, rotação e revogação.
Como prática, peça ao Microsoft Copilot para comparar hospedagem de um conjunto não estruturado, propor migração, explicar redundância, reduzir custos e agrupar dez práticas de segurança por esforço. Trate a resposta como hipótese e valide no Microsoft Learn e em prova de conceito controlada.
Resumo do tópico
Um design AZ-305 completo torna rastreáveis dados, serviço, conta, redundância, ciclo de vida, desempenho, segurança, custo e recuperação.
