Implementar Armazenamento no Azure – [1/2] – [70-533]

Share-it!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Email this to someone

Fala Pessoall! Tudo certo?

Dando continuidade ao material que eu criei para o estudo mais aprofundado em Azure, hoje comecarei uma serie de posts sobre Armazenamento no Azure. Perdeu os posts anteriores? De uma olhada AQUI.

Antes de ler, saiba que esse artigo não é:

* Fonte de estudo única e exclusiva para a prova. (Estude muito mais além desses artigos, leia a literatura oficial para o exame e faça muitos Labs's)

* Passo a passo para passar na prova. (Você deverá estudar bem mais se seu foco é a 70-533)

* 100% Atualizado com o que há de mais novo em Azure. (Após ler esse conteúdo, dê uma boa repassada em mais artigos atuais sobre o Azure. Muita coisa muda o tempo todo. #fikdik)

Estou apenas compartilhando meus métodos de estudo e meus resumos de próprio punho. Fiquem à vontade para complementar e tecer comentários à respeito. (Faço isso, porque ainda acredito na comunidade e no acesso ao conhecimento de forma GRATUITA! 😉 )

#   O Serviço  #         

* Azure Storage – Um dos aspectos mais importantes no Azure é o Armazenamento, ou Azure Storage Services

* Um serviço de armazenamento de dados que pode ser utilizado para vários serviços do Azure.

* Microsoft Azure SQL Database é uma outra opção para armazenamento de dados relacionais. ASQLD permite um deploy rápido e fácil de bancos de dados que usam a linguagem T-SQL usado no SQL Server, possibilitando um gerenciamento prático e "near-zero" overhead.

* Microsoft Azure Recovery Services (MARS), engloba Azure Site Recovery (que possibilita você construir um ambiente fail-over e proteger seu negócio contra quedas, ou suas máquinas virtuais, tornando-as disponíveis em outro data center no Azure) e Azure Backup ( o salvador da pátria, para aqueles que buscam uma alternativa de backup simples, segura, eficiente e eficaz) (ter eficiência e eficácia alinhadas à um baixo custo, é bem difícil, levando em consideração ambientes on premisses) onde se é possível efetuar o backup dos seu arquivos e pastas em um cofre de backup na nuvem. (Azure Backup Vault).

#     Blobs e Azure Files   #

* Dispões de 2 end points que permitem acessar os arquivos.

* O primeiro end point é para Blob Storage (Permite que os Desenvolvedores e ferramentas, usem a Azure Storage API para armazenar arquivos diretamente no storage)

* O segundo end point é para Azure Files. (Permite acesso aos arquivos usando o protocolo SMB). Ou seja, você consegue acesso aos seus dados usando o tradicional mapeamento de drive do Windows.

#       Azure Blob Storage     #

* É um serviço de armazenamento de dados não estruturados como texto, arquivos, videos, VHD para máquinas virtuais e etc.

Possui vários endpoints:

* .blob.core.windows.net

* .table.core.windows.net

* .queue.core.windows.net

* .files.core.windows.net

Todos eles podem ser acessados através do HTTPS (SSL) por padrão e sem nenhuma configuração adicional. (+Security)

* Cada Blob Storage pode ter um ou mais contêineres. Container é a mesma coisa de pasta (se levarmos em consideração o modelo computacional já conhecido) e são usados para agrupar as blobs dentro da conta.

* Você pode ter um Container raiz e outros contêineres abaixo dele, como uma estrutura de pasta.

* Esse serviço é baseado no esquema de flat storage. É possível criar hierarquias de blobs delimitado por nomes.

#      Criando Containeres   #

* É possível criar os containeres no portal do azure ou via linha de comando usando Azure Powershell cmdlets.

* Powershell:

New-AzureStorageContainer -Name "gmagella-teste" -Permission Off

(Para especificar acesso privado.)

Existem 2 tipos de Blobs:

* Page Blobs: uma coleção de páginas de 512bytes optimizadas para operações de leitura e escrita randômicas. O tamanho máximo que ela pode chegar é 1Tb. Discos de VM's são criados como page blobs.

* Block Blobs: foram comcebidos para um eficient uploading. Tamanho máximo que pode chegar 200Gb são blocos que podem ser escritos em conjunto.

#    Replicação   #

* Standard_LRS (Locally Redundant Storage): Faz 3 cópias síncronas dos seus dados no mesmo data center.

* Standard_ZRS (Zone Redundant Storage): Apenas para block blobs. Faz 3 cópias dos seus dados em múltiplos datacenteres na mesma ou outra região.

* Standard_GRS (Geographically Redundant Storage): LRS + 3 cópias adicionais assíncronas em um segundo datacenter em outra região.

* Standard_RAGRS(Read-Access Geographically Redundant Storage): GRS + acesso à leitura dos dados em um datacenter secundário.

* Obs.: O preço pode variar dependendo dos plano contratado. (Ex.: GRS é custa o dobro do LRS)

Para escolher o tipo de replicação, você pode utilizar parâmetro no comando powershell.

    # New-AzureStorageAccount -StorageAccountName "gmagella-teste" -Location "West Us" -Type "Standard_LRS"

Caso necessite mudar o tipo existente:

    # Set-AzureStorageAccount -StorageAccountName "gmagella-teste" -Type "Standard_GRS"

#  Async Blob Copy Service #

É um serviço que permite cópia de blobs que estejam em outro Azure Storage Account ou até mesmo fora do Azure.

A cópia de blob pode ser iniciada pelo cmdlet:

# Start-AzureStorageBlobCopy

É necessário informar outros parâmetros:

# -SrcBlob "servidor.vhd" (Nome do arquivo que você deseja copiar)

# -SrcContainer "Nome do Container" (Nome do container onde o arquivo está. Origem.)

# -Context "" (Contém o Nome e Chave do storage de origem e é usado para autenticação)***

# -DestContainer "Nome do Container" (Nome do container para onde o arquivo vai. Destino. Apenas testa se esse container existe e se está tudo ok.)

# -DestBlob (Nome do arquivo que você deseja gera. Nâo precisa ser o mesmo nome, você pode copiar trocando os nomes)

# -DestContext "" (Contém o nome da conta e chave onde está o storage de destino e é usado para autenticação. ***)

Para fazer essas cópias, é interessante trabalharmos com variáveis, para armazenar as chaves de acesso.

* Primeiro vamos criar 2 variáveis para armazenar o nome das contas.

$StAcNameOrigem = "gmagella-teste"

$StAcNameDestino = "gmagella-producao"

* Depois vamos pegar as chaves. Armazená-las em variáveis.

$StKeyOrigem = (Get-AzureStorageKey -StorageAccountName "gmagella-teste").Primary

$StKeyDestino = (Get-AzureStorageKey -StorageAccountName "gmagella-teste").Primary

Com este comando eu armazeno na variável as chaves que serão usadas posteriormente na cópia.

$ContextOrigem = New-AzureStorageContext  -StorageAccountName $StAcNameOrigem -StorageAccountKey $StKeyOrigem

$ContextDestino = New-AzureStorageContext -StorageAccountName $StAcNameDestino -StorageAccountKey $StAcNameDestino

E então eu posso usar o comando para criar um novo container, conforme eu já havia informado lá em cima:

New-AzureStorageContainer -Name "gmagella-producao" -Context $ContextDestino

E então efetuar a cópia de blobs de um Storage Account pra outro.

Vou armazenar numa variável, para posteriormente usá-la para consultar o status da cópia

$CopiaAtual = Start-AzureStorageBlobCopy -SrcBlob "X.vhd" -SrcContainer "guto-teste" -Context $ContextOrigem -DestContainer "guto-producao" -DestContext $ContextDestino -DestBlob "outronome.vhd"

Após armazenar, posso rodar esse cmdlet para iniciar a cópia.

Posso usar o comando: Get-AzureStorageBlobCopyState | $CopiaAtual para ver o status da cópia.

#    Configurando e Usando Azure Files     #

* Possibilidade de criar compartilhamento de arquivos (up to 5Tb) via SMB Diretamente na conta Azure.

* Pode ser acessado tanto quanto Azure Virtual Machines ou Cloud Services, usando o método regular de compartilhamento de arquivos. (Mapeando um drive ou arquivo I/O com comandos)

* Usado para logs de aplicações, conteúdo web, etc.

[ CRIAR NO PORTAL – DENTRO DE STORAGE ACCOUNT, FILE SHARES.]

* Usando Powershell

$Conta = "[Nome da conta de Storage]"

$NomeComp = "nomedocompartilhamento"

$ChavedeAcesso = (Get-AzureStorageKey -StorageAccountName $Conta).Primary

$Context = New-AzureStorageContext -StorageAccountName $Conta -StorageAccountKey $ChavedeAcesso

New-AzureStorageShare -Name $NomeComp -Context $Context

Após essa criação, você deve utilizar o utilitário cmdkey.exe para disponibilizar o compartilhamento do arquivo ou pasta.

cmdkey.exe /add:[Nome do Storage Account].file.core.windows.net /user:[nome da estorage account] /pass:[chave de acesso downloadeada]

Depois é só disponibilizar o compartilhamento via net use.

net use Z: \\Nome do Storage Account.file.core.windows.net\contosoweb(dominio)

#  Serviço Import/Export   #

* Serviço que possibilita envio de MUITOS dados dentro ou fora do Azure Storage Account em discos físicos para Data center Azure.

* Primeiro passo é identificar os dados a serem importados e os requerimentos físicos do disco.

* Disco Sata II ou III até 4TB. Volume NTFS.

* Preparar os drivers usando a ferramenta Microsft Azure Import Export (WAImportExport) (Download)

* Assegure-se que o driver que será importado tenha o Bitlocker ativoe então os dados podem ser encriptados no disco que será adicionado.

*Parâmetro: SrcFile para enviar um arquivo isolado.

[Estudar mais sobre a ferramenta de linha de comando que utilizará o Import e Export para mandar o Disco pro Azure]

[Possibilidade de Criar job no Portal – Tanto Import quanto Export]

#      Implementando CDN – Content Delivery Network     #

* Use o Azure para entregar conteúdo estático, imagens, videos, texto para os usuários.

* Para armazenar um CND ele deve ser criado no portal (endpoint) | CND – Quick Create

* SSL poderá ser habilitado para criptografar o tráfego. (HTTPS)

* Vc pode criar um CND para acessar um arquivo específico. Assim vc acesa esse arquivo isolado e não precisa parra informações como chave, etc..etc..

* O Azure cria um endpoint do CDN apontando para esse aqruivo. [ è possível criar um End Point em outra região, e aproveitar a velocidade entre os storages do Azure para que o usuario acesse]

* Exemplo: Vc tem um arquivo no Brasil. Tem um usuário na Europa. Normalmente ele tenha que vir até o Brasil para ver o arquivo. Dando saltos por operadoras convencionais etc.

* Se vc cria um end point na Europa, a navegação até o Brasil, é interna através dos Data Centeres do Azure. O que minimiza os saltos e latência.

* É possível gerenciar quanto tempo o conteúdo ficaráno CDN não dependendo de sua origem.

* O padrão é o conteúdo estar disponível no CDN 7 dias e será removido após o período.

* É possível setar o Cache-Control (Propriedade) usando o Portal ou Powershell e setar o TTL em segundos. (86400 = 1 Dia Em Segundos)

* Para Remover o Conteúdo do CDN completamente temos 2 opções:

– Se o conteúdo estiver no Azure Storage você pode setá-lo como Private ou apagá-lo.

– Se o conteúdo estiver num cloud services (web site), você pode

– Uma terceira opção é habilitar o gerenciamento dia query strings (deve ser habilitado no portal)

#   Implementando Domínios Customizados     #

* Tanto em Azure Storage Account e CDN é possível especificar um domínio customizado, para ficar mais identificável com sua empresa.

* Configure esse serviço adicionando uma entrada CNAME no seu provedor DNS que gerencia suas entradas DNS.

CNAME: blob.gustavomagella.com  >> TARGET: contosoblobs.blob.core.windows.net (endpoint)

* Pode aumentar a latência, pois é mais um salto a ser dado.

* Asverify subdomain. Possibilita o Azure reconhecer seu domínio customizado sem modificar a entrada DNS.

* SSL não é suportado usando Custom Domains. 🙁

#    Manage Access  #

* Várias técnicas de controle de acesso aos objetos no Azure Storage Account

Existem 2 Keys: Primary and Secondary.  Motivo: Permitir que outros aplicativos utilizam a chave secundária em vez da primária e depois regenerar a primária.

Técnica conhecida como key rolling, permite que você resete a chave primária sem "downtime" nas aplicações que estão utilizando esse modelo de autenticação.

Atenção! Quando for regenerar a chave primária, certifique-se que as VM's Azure sejam desligadas antes.

Caso contrário vc terá que refazê-las. Se vc estiver usando o Azure Media Services, você terá que re-sincronizar a chave de todos os Storages Account usados, depois da regeneração.

– Chave de Autenticação e Storage Account Name (Full Access)

– Acesso compartilhado de Assinatura (Shared Access Signature)

– Policy para permitir acesso granular com expiração.

#   Managing Storage Account Keys   #

* Por padrão toda requisição para o Azure Storage Account requer autenticação.

– PrivateOff – Sem acesso anonimo

– Blob – Acesso à blobs via anonymous requests

– Container – Listar e acessar blob via anonymous requests.

#   Shared Access Signatures   #

* Garante acesso à específicos containeres, blob, filas e tabelas.

* Concede acesso à apenas arquivos específicos. Mesmo assim requer autenticação (Private)

* Criando a SAS

$Conta = "[Storage Account Name]"

$Chave = (Get-AzureStorageKey -StorageAccountName $Conta).Primary

$Context = New-AzureStorageContext -StorageAccountName $Conta -StorageAccountKey $Chave

$DataInicio = Get-Date

$DataFim = $DataInicio.AddHours(4)

New-AzureStorageBlobSASToken -Container "nome do container" -Blob "arquivo.xls" -Permission "rwd" -StartTime $DataInicio -ExpirityTime $DataFim -Context $Context

* Após a execução desse comando, aparecerá um Token no fim do comando. Você pode usar esse token combinado com o endereço de endpoint.

Ex.: http://contoso.blob.core.windows.net/container/arquivo.xlsx

Ex.: http://contoso.blob.core.windows.net/container/arquivo.xlsx?sv=ne94dfv&dkwerila&45o2kd&24278[3&3428&384238=rwd

#  Using Stored Access Policy   #

Basicamente igual a anterior, porém vc pode escolher várias políticas de acesso, quando elas terminam  e acabam.

#   Configurando Azure Storage Diagnostics  #

* Não vem habilitado como default

* Para habilitar via portal: Storage Properties | Diagnostics Button | Enabling Storage Diagnostics

* Via Powershell:

$Conta = "[Storage Account Name]"

$Chave = (Get-AzureStorageKey -StorageAccountName $Conta).Primary

$Context = New-AzureStorageContext -StorageAccountName $Conta -StorageAccountKey $Chave

Set-AzureStorageServiceMetricsProperty -ServiceType Blob -MetricsType Hour -RetentionDays 30 -MetricsLevel ServiceAndApi -Context $Context

* Dados de métricas são gravados no nivel de serviço. Disponibilidade, Latencia e porcentagem de sucesso agregado às Blobs, Tables e Filas de serviços.

* Os dados são coletados dependendo do valor que é declarado no comando.

Set-AzureStorageServiceLoggingProperty -ServiceType Blob -RetentionDays 30 -LoggingOperations Delete -Context $Context

* Os dados de Logging são em cima dos blobs. É necessário especificar quais os tipos de operação serão capturadas.

#   Atualizando Dados de Diagnóstico   #

* Depois de habilitado e configurado a captura de diagnósticos, a próxima etapa é entender como recuperar os dados de log e entende-los.

* Para acessar esses dados vc pode optar por uma ferramenta de terceiros ou Visual Studio.

* Os Logs são armazanados num blob storage dentro do storage account container chamado $logs.

* As métricas são armazenadas no $Metric

#    Habilitando Monitoramento e Alertas   #

* Experiência bem similar ao monitoramento de máquinas virtuais

* Pelo Dashboard

* Poderão ser criados vários alertas

#     Implementando Base de Dados SQL    #

* Escolha o tier que mais tem a ver com seu negócio

* Serviço isolado, não precisa de um Host

* Os níveis de performance são mensurados em DTU (Database Throughput Units)

* DTU é uma forma de descrever a capacidade relativa de performance baseado em CPU, Memória, Leituras e Escritas.

* Maximum 1600 DTU.

* O Número de DTU é definido pelo tier escolhido.

* Maximum Size: Basic: 2GB

                                Standard: 250GB

                                Premium: 500GB

* Para mensurar a performance é possível usar uma ferramenta de Benchmark (Azure SQL Database Benchmark)

* A ferramenta faz uma varredura e identifica os trabalhos do banco.

* RTO: Tempo Máximo que demora para disponibilizar o serviço e seus dados no estado operacional. (Voltar ao normal)

está ligado ao tempo que um sistema leva para se recompor e retomar as atividades após sofrer uma parada ou um ataque.

* RPO: Quantidade de informação que é tolerável perder no caso de uma indisponibilidade de serviços.

Por exemplo: se uma rotina de backup é feita todos os dias às 2h da manhã e ocorre um incidente que

causou perda de informações às 10h, o gap de recuperação das informações é de 8 horas.

Ou seja, durante essas 8 horas podem ter sido produzidas informações que não estarão na recuperação.

Isso é aceitável para o negócio?

*        *        *        *        *

. . . Continua no próximo post! 😉

#enjoy #rock #azure #cloud

Um Forte Abraço!

Gustavo Magella

| MSP LEAD | MCSA | MTA| MCTS | ITIL | ISO 27.002 | EXIN CLOUD
| EXIN CERTIFIED INTEGRATOR SECURE CLOUD SERVICES |
***********************************************************************************
Apaixonado por tecnologia, enxergo na Cloud Computing um enorme potencial para alavancar seus negócios e transformar o mundo. Follow Me and Discover ! 😉

Author: Gustavo Magella

| MSP LEAD | MCSA | MTA| MCTS | ITIL | ISO 27.002 | EXIN CLOUD | EXIN CERTIFIED INTEGRATOR SECURE CLOUD SERVICES | *********************************************************************************** Apaixonado por tecnologia, enxergo na Cloud Computing um enorme potencial para alavancar seus negócios e transformar o mundo. Follow Me and Discover ! ;)

Leave a Reply

Your email address will not be published. Required fields are marked *

Responda o enigma: * Time limit is exhausted. Please reload CAPTCHA.