Azure Storage, conhece? [PARTE 2]

Dando continuidade ao post anterior, vamos falar sobre o que é "TIER" e entrar de vez no Azure Storage.

Para quem não leu a primeira parte, segue link:
https://dev.to/wiluey/azure-storage-conhece-parte-1-5a4b

Bom, vamos lá!

No artigo anterior estudamos os principais conceitos para entendermos uma storage, como o SO faz o acesso ao disco e as camadas que podemos montar em termos de redundância e paridade.

Mas ainda tem mais, uma vez que montamos nossos RAIDS, precisamos separar os discos rápidos dos discos lentos, senão a performance de acesso à informação será comprometida. E é aí que entra o conceito de TIER.

Veja bem, TIER é um conceito de camada (e uma tradução livre), portanto você pode separar os discos em lentos, rápidos (de 10 a 15 mil RPM) e SSDs sem "misturá-los".
Veja bem, o "misturar" é na hora de montar o RAID, como vimos no artigo anterior.

E por que isso?
Simples: reduzir o custo total do armazenamento.

Uma arquitetura de armazenamento em camadas (TIER) coloca os dados em uma hierarquia de acordo com seu valor comercial. As camadas são determinadas pelo desempenho e pelo custo da mídia, e os dados são classificados pela frequência com que os usuários acessam.
Geralmente, os dados mais importantes são veiculados na mídia de armazenamento mais rápida, que normalmente é a mais cara.

Em uma configuração básica, uma camada rápida de armazenamento flash alcança desempenho satisfatório, enquanto outros dados são gravados no armazenamento secundário em disco, fita ou nuvem. Os dados que precisam ser mantidos indefinidamente são mantidos em uma camada de arquivamento.

Antes os TIERS eram armazenados de 1 a 3, na ordem de importância, mas com o advento dos discos flash e da cloud publica, essa classificação aumentou e agora dizemos que o TIER pode ser se 0 à 3.

Acima vemos a ilustração do TIER x Criticidade do Negócio

Como classificar?

TIER 0: A camada 0 (camada zero) é o nível de armazenamento de dados mais rápido e talvez mais caro do que qualquer outro nível na hierarquia de armazenamento.

TIER 1: Discos rápidos, geralmente Fibre Channel, com velocidade acima de 10k.

TIER 2: Discos usados para armazenamento, porém que precisam de uma velocidade de gravação/leitura (write/read) mediana. Discos SATA ou SAS são os mais utilizados.

TIER 3: Camada fria, são discos usados para armazenamento histórico, a velocidade não é importante, apenas o tamanho, uma vez que vamos guardar nossos arquivos por vários anos provavelmente. Fitas são bons exemplos.

Creio que aqui deu pra entender bem o conceito e fechar o necessário para entendermos bem uma STORAGE, certo?
Claro que ainda há muito a ser dito, mas para o que precisamos, já temos informações suficientes.

Então finalmente vamos entrar no AZURE.

Quando falamos de Azure, falamos geralmente em uma Conta de Armazenamento (Storage Account), que também é divido em camadas, mas aqui já usaremos um outro termo, o Access Tier, que na prática, é o mesmo do TIER que estudamos acima.

E temos que ter em mente uma coisa: Por ser tratar de um serviço provido por um fornecedor de Cloud Publica, o serviço (sim, aqui storage é um serviço) tem que ser durável e altamente resiliente e para isso, a Microsoft possui redundância e a disponibilidade dos dados depende do que é contratado.

E quais os tipos de redundância disponíveis?

LRS — Armazenamento com Redundância Local
Replica seus dados três vezes em um único data center. O LRS é a opção de replicação de menor custo e oferece a menor durabilidade em comparação com outras opções.

ZRS — Armazenamento Redundante de Zona
Replica seus dados de forma síncrona em três clusters de armazenamento em uma única região

GRS — Armazenamento com Redundância Geográfica
O armazenamento com redundância geográfica (GRS) foi desenvolvido para fornecer pelo menos 99.99999999999999% (16 9’s) durabilidade dos objetos em um determinado ano. Se sua conta de armazenamento tem GRS habilitado, seus dados serão duráveis mesmo no caso de uma interrupção regional completa ou um desastre no qual a região principal não possa ser recuperada.

GZRS — Armazenamento com Redundância de Zona Geográfica
Armazenamento com redundância de zona geográfica (GZRS) (visualização) casa a alta disponibilidade de armazenamento com redundância de zona (ZRS) com proteção contra interrupções regionais, conforme fornecido pelo armazenamento com REDUNDÂNCIA geográfica (GRS).
Os dados em uma conta de armazenamento (Storage Account) GZRS são replicados em três zonas de disponibilidade do Azure na região primária e também são replicados para uma região geográfica secundária para proteção contra desastres regionais.

Lembre-se: Zona de Disponibilidade (Availability Zone) e Região Geográfica não podem ser confundidas.
Cada Região é uma área geográfica separada. Cada região tem vários locais isolados conhecidos como Zonas de disponibilidade. As Zonas locais fornecem a capacidade de colocar recursos, como computação e armazenamento, em vários locais mais próximos dos usuários finais. Os recursos não são replicados entre regiões, a menos que você especifique isso, ficou claro?

Acima expliquei os principais serviços de armazenamento que são entregues pela Microsoft dentro do Azure.

E dependendo do tipo de redundância, temos alguns subníveis de contratação.

Vejamos:

Dentro do GRS, podemos ter o RA-GRS, que é um tipo de armazenamento com redundância geográfica de acesso de leitura, ou seja, seus dados são replicados para outro datacenter em uma região secundária e também é fornecida a opção de leitura (read access) a partir da própria região secundária.

Ponto de atenção: Somente as contas de armazenamento (Storage Account) de uso geral V2 (GPv2) dão suporte a GZRS e RA-GZRS.

Outras vantagens de se ter storage como serviço é que são totalmente seguras e escaláveis.

Ai você pergunta: Mas toda storage tendo espaço no TIER não é escalável?
Sim, essa é a resposta. Mas este espaço é limitado, na nuvem ele é "ilimitado".

Falando em TIER, chegou o momento de explicar as camadas de acesso do Azure.

Existem cinco Camadas de Acesso (ACCESS TIER):

Hot Access Tier (Camada de Acesso Quente):
A camada de acesso quente tem custos de armazenamento maiores, mas os custos de acesso mais baixos.
Os cenários de uso de exemplo para a camada de acesso quente incluem:

• Dados que estão em uso ativo ou que devem ser acessados (lidos e gravados) com frequência.
• Dados que são preparados para processamento e migração eventual para a camada de acesso fria.

Cool Access Tier (Camada de Acesso Frio):
A camada de acesso frio reduz os custos de armazenamento e os custos de acesso mais altos em comparação com o armazenamento dinâmico. Essa camada destina-se aos dados que permanecerão na camada esporádica por pelo menos 30 dias.
Os cenários de uso de exemplo para a camada de acesso fria incluem:

• Conjuntos de dados de recuperação de desastre e de backup de curto prazo.
• Conteúdo de mídia mais antigo que não é mais exibido frequentemente, mas ainda deve estar disponível imediatamente quando acessado.

Archive Access Tier (Camada de Acesso ao Arquivo):
A camada de acesso de arquivamento tem o menor custo de armazenamento. Mas ele tem custos de recuperação de dados mais altos em comparação com as camadas quente e fria. Os dados na camada de arquivo podem levar várias horas para serem recuperados.
Os cenários de uso de exemplo para a camada de acesso de arquivamento incluem:

• Backup de longo prazo, backup secundário e conjuntos de dados de arquivamento.
• Dados originais (brutos) que devem ser preservados, mesmo após serem processados em formato utilizável final.

Observação: Os dados devem permanecer na camada de arquivo por pelo menos 180 dias ou estar sujeitos a uma cobrança de exclusão antecipada.

Blob Level Tiering (Camada no Nível do Blob):
As camadas no nível do blob permitem que você altere a camada de seus dados no nível de objeto usando uma única operação chamada Set Blob Tier.
Você pode alterar facilmente o nível de acesso de um blob entre as camadas quente, fria ou de arquivo como alteração de padrões de uso, sem a necessidade de mover dados entre contas.

Account Level Tiering (Camadas em Nível de Conta):
Os BLOBs em todas as três camadas de acesso podem coexistir dentro da mesma conta.
Qualquer BLOB que não tenha uma camada explicitamente atribuída (não definida) infere a camada da configuração de nível de acesso da conta.

Ah, também existem as Storage Account do tipo QUEUE e TABLE, a diferença entre elas é:

QUEUE - Armazenamento de Filas
O armazenamento de filas do Azure fornece mensagens na nuvem entre os componentes da aplicação.
Um grande número de mensagens que podem ser acessadas de qualquer lugar do mundo por meio de chamadas autenticadas usando HTTP ou HTTPS.
Uma única mensagem de fila pode ter até 64 KB de tamanho e uma fila pode conter milhões de mensagens, até o limite de capacidade total da Storage Account.
Sugestão: Recomendo que leiam sobre o conceito de Message Broker.

Conceito de uma QUEUE STORAGE

TABLE - Armazenamento de Tabelas
O armazenamento de tabela do Azure armazena grandes quantidades de dados estruturados. O serviço é um armazenamento de dados NoSQL (formato Key Value) que aceita chamadas autenticadas de dentro e de fora do Azure.
Sugestão: Recomendo que leiam sobre o conceito de NoSQL e Key Value.

Conceito de uma TABLE STORAGE

Agora sabemos quais os TIERs entregues pelo Azure quando vamos definir uma conta de armazenamento (Storage Account) e ficou mais fácil definir quais as melhores opções para o seu negócio, concorda?

Mas lembre-se, quando você cria sua conta de armazenamento (Storage Account), fique atento aos propósitos gerais.

Como assim?

Existem 3 tipos de Contas de Armazenamento: GPv1, GPv2 e BLOB.

GPv1 - General Purpose v1 (Propósito Geral V1):
Tipo de conta herdada para BLOBs, arquivos, filas e tabelas.
As contas de armazenamento v1 de uso geral fornecem acesso a todos os serviços de armazenamento do Azure, mas podem não ter os recursos mais recentes e tem um ponto negativo que é o uso obrigatório do modelo de implantação clássico do Azure e não tem suporte ao Azure Resource Manager.

GPv2 - General Purpose v2 (Propósito Geral V2):
As contas de armazenamento para uso geral v2 são compatíveis com os recursos mais recentes do Armazenamento do Azure e incorporam todas as funcionalidades das contas de armazenamento de blobs e para uso geral v1 e possuem a vantagem de ser compatíveis com o Azure Resource Manager (ARM), além de serem bem mais baratas que GPv1.
Observação: GPv2 é o tipo de conta atualmente recomendado pela própria Microsoft.

Blob Storage Account (Conta de Armazenamento de BLOB):
É uma conta de armazenamento especializada que você usa para armazenar dados de objeto não estruturado.
Esse tipo de conta de armazenamento (Storage Account) é otimizado para workloads com altas taxas de transações ou que exigem tempos de acesso muito rápidos.

Ótimo, entendi como são os níveis de acesso e os tipos de conta no Azure, mas e o preço?

Os preços obviamente variam de acordo com a sua necessidade, mas dependendo do seu negócio, tenha em mente alguns pontos:

• Custo do armazenamento por camada (se precisa ser premium ou não)
• Vai escrever mais ou ler mais?
• Vai fazer mais Upload ou Download?
• Se tiver HA (high availability), avalie o custo da replicação e as regiões geográficas envolvidas

E como faço para acessar a minha conta de armazenamento?

Simples, uma vez criada, você pode acessá-la de qualquer lugar via URL, sendo HTTP ou HTTPS.
A entrada fica assim: https://storagewiluey.blob.core.windows.net
Obviamente será necessário uma chave de acesso (hash key).

Você também pode acessar sua Storage Account via REST API, Azure PowerShell ou Azure CLI.

E sabia que você pode simular uma Storage Account em sua máquina local?

Existe um recurso chamado Azure Storage Simulator que faz parte da SDK de desenvolvimento do Azure e você pode baixá-lo gratuitamente.

Link direto: https://go.microsoft.com/fwlink/?linkid=717179&clcid=0x409

O Azure Storage Simulator fornece um ambiente de desenvolvimento local gratuito para desenvolver e testar seus aplicativos de armazenamento do Azure sem criar uma assinatura.

Após instalado, ele usa uma instância LocalDB do Microsoft SQL Server 2012 Express para emular os serviços de armazenamento do Azure.
Se você quiser, pode optar por configurar o Azure Storage Simulator para acessar uma instância local do SQL Server em vez da instância do LocalDB default.

Sensacional né?

Creio que até aqui deu para entender bem os conceitos de storage física e storage como serviço de armazenamento no Azure; o assunto é extenso, ainda existem muitos pontos, mas este artigo (e a parte 1) deram um norte para você estudar o assunto a fundo, certo?

Na próxima e última parte desta série, aprenderemos na prática como criar uma Storage Account no Azure via Portal, Powershell e Azure CLI ;).

Até o próximo post!

Abs,