DEV Community: Wiluey Sousa

BlobFuse - Azure Blob Storage como Filesystem no Linux

Wiluey Sousa — Tue, 02 Feb 2021 04:41:16 +0000

Fala comunidade!

Depois de um tempo ausente, estamos de volta com força total e sem hiatos!

E nada melhor do que tirar a poeira da mobília com um post bacana sobre Infra Azure, concordam?

Bom, vamos lá!

Antes de mais nada, a primeira coisa a ser entendida antes de entrarmos no técnico é: Já ouviram falar sobre Blobfuse?

Blobfuse é um driver utilizado em sistemas operacionais baseados em Linux (diferentes distros) que simula um filesystem que aponta direto para um blob storage do Azure, ou seja, através do driver, o Blobfuse simula um diretório virtual.

O Blobfuse dá suporte à instalação nas seguintes distros:

Ubuntu: 16, 4, 18, 4 e 20, 4
RHELversions: 7.5, 7.8, 8.0, 8.1, 8.2
CentOS: 7.0, 8.0
Debian: 9.0, 10.0
SUSE: 15
OracleLinux 8.1

Mas will, não seria mais fácil apontar diretamente para um File Share dentro do meu Blob Storage?

Depende!

Por dois motivos:

File Share tem o limite de 5TB, parece muito, mas tratando-se de armazenamento, acreditem, não é!
Exige o uso do protoclo SMB 3.0 para ser usado nas distros listadas acima.

Então avalie bem a sua necessidade.

Agora que já entendemos o Blobfuse, vamos à prática?

Primeiramente vamos logar no portal do Azure (www.portal.azure.com) e abrir o Cloud Shell para executarmos comandos na linguagem Powershell (imagem abaixo).

Obs: Se preferir, pode fazer isso direto pela console do Powershell ISE também, basta apenas logar na sua subscription.

Daqui pra frente nós vamos usar scripts powershell para a criação da Sorage Account, CLI para a criação da VM e o Packer para o deploy da imagem.

Logado no Powershell, execute os comandos abaixo:
Listar as suas Subscriptions (caso tenha mais de uma)

Get-AzSubscription

Selecionar o ID da sua Subscription e insira-o como parâmetro

Set-AzContext -Subscription "xxxxx-xxxxx-xxxxxxxxxxxxxxxx"

Crie seu Resource Group (RG)

$resourceGroup = "BlobFuseWiluey" (Aqui crie o nome que quiser)
$location = "eastus"
New-AzResourceGroup -Name $resourceGroup -Location $location

Crie a Storage Account

$storageAccount = New-AzStorageAccount -ResourceGroupName $resourceGroup -Name "blobfusestoragewill" -SkuName Standard_LRS -Location $location
$ctx = $storageAccount.Context

Crie o Container Storage

$containerName = "blobfuse-will-azure"
New-AzStorageContainer -Name $containerName -Context $ctx -Permission blob

Aqui finalizamos a primeira etapa, já temos nossa Storage Account criada.

Agora vamos brincar um pouco com DevOps e gerar a imagem da nossa máquina virtual com o Packer.

Não conhece o Packer?

O Packer é um dos produtos da HashiCorp (como o Terraform), criado para gerar e gerenciar imagens de forma automatizada.
O Packer é capaz de construir a imagem de sua aplicação, banco de dados ou sistema operacional utilizando os seus mesmos playbooks e scripts inseridos no Userdata.

Uma vantagem do Packer é possibilidade de criar imagens multiplataforma com o mesmo código, uma vez que ele é compatível com AWS, Microsoft Azure, Google Cloud, VMWare, Docker, Digital Ocean, dentre outras.
O Packer não substitui os seus configurations managers, mas faz uso deles para provisionar as imagens criadas.

Agora vamos lá!

Altere o seu Cloud Shell agora para usar o Bash, onde vamos executar scripts CLI (imagem abaixo).

Feito isso, vamos "setar" a subscription correta, não vamos provisionar o recurso no lugar errado, certo?

Execute o comando abaixo para listar suas Subscriptions:

az account show

"Sete" a Subscription:

az account set --subscription "xxxxxxx-xxxxxxxxx-xxxxxxxxxxxxxx"

Como não vamos criar uma VM para servir como nosso configuration Manager, vamos usar o módulo nativo do Azure.
Porém para usar o módulo nativo, e necessário gerar uma role de acesso (RBAC) para gerar os códigos que serão usados no script para autenticação.

Execute o comando abaixo e guarde os ID's gerados

az ad sp create-for-rbac --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"

Com o comando abaixo você pega o ID da Subscription

az account show --query "{ subscription_id: id }"

Obs: Não transfira, ceda ou mostre publicamente esse ID para NINGUÉM!

Basicamente os comandos acima lhe trarão os IDs dos parametros abaixo:

"client_id": "xxxxx-xxxxxxxx-xxxxxxxxxxxxxxx"
"client_secret": "xxxxx-xxxxxxxx-xxxxxxxxxxxxxxx"
"tenant_id": "xxxxx-xxxxxxxx-xxxxxxxxxxxxxxx"
"subscription_id": "xxxxx-xxxxxxxx-xxxxxxxxxxxxxxx"

Agora com os IDs em mãos, vá para o Cloud Shell (em modo BASH) e gere o JSON com as configuraçõe da nossa imagem.

O script com o JSON está no meu GitHub, pegue-o no link abaixo:

https://github.com/Wiluey/packer/blob/master/RedHat7.json

Agora que possui o JSON, execute o comando o comando abaixo (no BASH):

vi RedHat7.json (um novo arquivo será criado)
Tecle "I"(insert) e cole o JSON dentro deste arquivo novo que foi aberto com o "vi"
Tecle ESC seguido de :wq (para salvar e sair)

Agora com o JSON criado, vamos chamado o módulo do PACKER para gerar a nossa imagem.

Execute o comando abaixo:

packer build RedHat7.json

Uma imagem parecida vai informar o status do Deploy:

O tempo de geração da imagem leva em torno de 10 a 12 minutos.

Quando o processo finalizar, teremos o output abaixo:

E indo até o Resource Group, você verá o recurso provisionado:

Repare que em "Data Disks" não há nenhuma LUN ou LVM montado. Isso foi proposital para que a minha imagem fosse a mais "limpa" possível.
E o Blobfuse vai fazer esse papel depois...

Agora é o momento de criarmos nossa máquina virtual Linux Red Hat 7 a partir da nossa imagem.

No Cloud Shell (em modo BASH), execute o comando abaixo:

az vm create --resource-group BlobFuseWiluey --name WilueyVmLinux --image PackerImageBlobfuse --admin-username wiluey --admin-password "xxxxxx" (senha forte aqui)

Após o deploy da nova VM criada a partir da nossa imagem, teremos um output confirmando o IP Publico atribuído a ela (conforme imagem):

Agora vamos testar/validar o acesso à nossa máquina virtual, execute o comando:

ssh seuuser@seuippublico

O output:

Sucesso!

Agora a etapa final, criar o Blobfuse e fazer o linux reconhecer nosso container como um filesystem.

A imagem abaixo comprova que nossa distro possui apenas os pontos de montagem padrão (o "barra").

Logados no Linux, o primeiro passo é criar as variáveis de ambiente globais, utilizando o comando export:

export AZURE_STORAGE_ACCOUNT=nome_da_sua_storage_account
export AZURE_STORAGE_ACCESS_KEY=a_sua_chave_de_acesso

Não sabe onde encontra isso?
Vem comigo!

Execute o comando abaixo:

az storage account keys list -g BlobFuseWiluey -n blobfusestoragewill

Obviamente alterando os parâmetros para os seus, onde "-g" é o nome do Resource Group e "-n" é o nome da Storage Account.

O output:

Na variável de ambiente, basta inserir o valor retornado em "value" da Key1.

Criadas as variáveis, agora vamos criar os diretórios que serão nossos binários.

Primeiramente eleve seus privilégios:

sudo su

Depois execute os comandos abaixo (inserindo o nome que quiser):

cd /home/wiluey
mkdir blobfuse-mount-will/
chown wiluey:wiluey blobfuse-mount-will/

Acima estamos autorizando o usuário a acessar nosso filesystem, afinal não podemos usar o root o tempo todo, até mesmo por questões de segurança.

Execute a instalação do Blobfuse:

rpm -Uvh https://packages.microsoft.com/config/rhel/7/packages-microsoft-prod.rpm
yum install blobfuse -y

Crie uma pasta temporária vazia:

mkdir /blobfuse-mount-will-tmp

Agora vamos fazer o "mount" do nosso diretório com o Blobfuse:

blobfuse /home/wiluey/blobfuse-mount-will --container-name=blobfuse-will-azure --tmp-path=/blobfuse-will-tmp

Vamos validar se o filesystem foi devidamente reconhecido pelo SO:

Sucesso!

Vamos fazer o teste e copiar algum arquivo para nosso container storage, o mesmo deve aparecer no Linux, certo?

Existem diversas maneiras, mas pra ganharmos tempo, vou fazer o upload via Portal.

Fazendo uma primeira verificação, constatamos que o volume está vazio.

Navegue até seu Container Storage, selecione um arquivo qualquer da sua máquina e faça o upload do mesmo para o Azure conforme imagem abaixo:

Arquivo encontra-se no container após o upload:

Vamos ver se ele está na VM, dentro do nosso filesystem?

Voilà!

Tudo certo, nosso filesystem foi reconhecido com sucesso e está acessível!

Existem outras opções para uso de área temporária, como o ramdisk, que consiste em usar parte da sua memória RAM como se fosse um disco local, mas isso fica pro próximo post, ainda tem muito assunto sobre Infra Azure para falarmos.

Agora um ponto de atenção super importante:
Este foi apenas um laboratório que servirá de estudos e aprendizado aos leitores.
E por ser um laboratório, diversas regras de segurança foram deixadas de lado, portanto se um dia houver a necessidade de criar uma arquitetura desta em ambiente produtivo, conte com um arquiteto experiente que conheça bem a segurança do Azure e as boas práticas para manter os dados da sua empresa seguros, não arrisque as práticas deste tutorial!

Acompanhem o blog para ficar por dentro do mundo Cloud Computing!

Grande abraço e até a próxima!

WSFC + SQL AlwaysOn no AZURE sem Active Directory [#3]

Wiluey Sousa — Wed, 05 Aug 2020 22:52:46 +0000

Fala pessoal!

Na etapa anterior, vimos como criar nossas máquinas virtuais, atrelar um IP estático a elas e habilitar a Feature de Cluster.

Nesta última parte da série, vamos criar nosso WSFC e habilitar o SQL Server AlwaysOn Availability Groups.

Para quem não leu a primeira e segunda parte, segue os links:
https://dev.to/wiluey/wsfc-sql-alwayson-no-azure-sem-active-directory-1-405g

https://dev.to/wiluey/criando-um-wsfc-sem-ad-sql-alwayson-no-azure-parte-1-1bhl

Mas antes preciso esclarecer que isso só é possível ser feito no Windows Server 2016 em diante, pois a partir dele é possível criar um Failover Cluster (de 2 ou mais nós) em Domínios diferentes ou em servidores Workgroup (que não fazem parte de um AD).
Este é chamado de Workgroup Cluster e será o tipo de cluster que criaremos.

Então vamos lá!

Primeiramente acesse cada uma das máquinas virtuais, acesse o Powershell como administrador e execute o script abaixo:
New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1

Esse script é para habilitar na chave de registro do Windows a opção de acesso remoto aos compartilhamentos administrativos, uma vez que por segurança o acesso só pode ser feito por contas de domínio.
E o script desabilita o filtro de tokens das contas locais desbloqueia o acesso remoto a essas contas.

Após isso, reinicie ambas as máquinas virtuais.

A partir daqui vamos falar de alguns conceitos de Infraestrutura para melhorar o entendimento.

O primeiro passo é configurarmos o Sufixo DNS Primário, pois ele nos permitirá configurar os nós para comunicarem-se via FQDN.

O FQDN (Fully Qualified Domain Name) é a abreviatura que significa o nome de domínio completo e ser composto por domínio e/ou diversos subdomínios.

Como o Listener do SQL AlwaysOn usa resolução de DNS, é necessário configurarmos o FQDN, pois por características do produto, o SQL Server não faz Proxy Reverso, por isso é uma má prática apontamos para o IP do Listener ao invés do DNS.

Agora acesse as máquinas virtuais e configure o Sufixo DNS Primário seguindo os passos abaixo:

Acesse System properties do Windows
Na tela abaixo, clique em "More"
Em DNS Suffix and NetBIOS Computer Name digite o nome de Domínio DNS (de sua escolha)

Finalizado os passos acima, clique em OK até ser solicitado o boot do servidor, reinicie as máquinas.

Após logar nas máquinas, verá que agora ela possui um nome completo:

Agora vem o "pulo do gato", nós vamos "enganar" e fazê-lo acreditar que as entradas no DNS estão criadas.

A diferença aqui é que se eu não usar um AD, ainda precisarei do DNS Domain para registrar as entradas do meu FQDN.

Acesso o arquivo HOSTS do servidor, geralmente fica em "c:\windows\system32\drivers\etc".

Insira no Arquivo Hosts todos os servidores que farão parte do Cluster, faça isso em TODOS os servidores.

A partir de agora, as máquinas conseguirão fazer um ping entre si resolvendo o FQDN.

Agora estamos prontos para colocar o Windows em Cluster, ou seja, finalmente criar o WSFC.

Execute Windows+R e digite Cluadmin.msc para abrir o Failover Cluster Manager.

Clique com o botão direito do mouse em "Create Cluster" e siga o passo a passo abaixo:

Nesta tela clique em "next"
Nesta tela digite um nome de servidor de cada vez e clique em "Add", o nome deve ser o FQDN, depois clique em "next".
Nesta tela clique em "Yes" para rodar o Cluster Validate, e depois em "next".
Nesta tela, selecione a opção Run only tests I select e clique em "next".
Como não estamos com Storage compartilhada, desmarque a opção de validação dos discos e clique em "next".

Após isso clique novamente em "Next" e espere o processo de validação que levará alguns minutos.

O processo vai reclamar que não encontrou o Active Directory (ah vá! haha), ignore!
ele também vai gerar alguns Warnings, ignore também!
Finalizando a validação, clique em "finish".

Nesta tela você dá um nome ao seu WSFC

Após isso, só clicar em "next" até iniciar o processo de criação do WSFC.

Ao final vai gerar esta tela com alguns Warnings, só clicar em "finish".

Ao final do processo você verá que o serviço do Cluster não ficou online e mesmo executando um "Bring Online" ele não sobe de maneira alguma.

Calma rs! Aqui vem um outro pulo do gato!

Isso ocorre porque houve um conflito de IPs, como na criação o processo de deploy não nos permite inserir o IP Vip manualmente, ele pega os IPs disponíveis nas interfaces e como eu propositadamente não inseri mais de uma interface, ele tentou pegar um IP que estava em uso.

Para resolver é simples, clique com o botão direito em cima do recurso do cluster e vá em "Properties".

Na tela abaixo, clique em cima de um dos IPs e depois em "Edit".

Altere a opção do endereço de IP para Use Static, insira um novo IP (dentro do seu bloco CIDR) e clique em OK.

Repita o processo para a outra interface.

Clique em "apply", depois em "OK".

Pronto, recurso no ar novamente!

"Mas Will, ainda tem um recurso offline, ainda tá dando erro!"

Calma Padawan, isso é completamente normal, lembre-se que cada uma das máquinas virtuais estão em uma VNET diferente, portanto estamos usando o conceito de Multi-subnet Failover, na qual garantimos a alta disponibilidade a nível de rede também.
Ou seja, somente em caso de Failover/Chaveamento a outra interface ficará online. Então fica tranquilo! =)

Agora sim, nosso WSFC está no ar e operante!

Agora chegou o momento de configurarmos o SQL Server AlwaysOn Availability Group.

Digite Windows+R e depois digite SQLServerManager14.msc.

No serviço do SQL Server, clique na opção abaixo, depois em OK e reinicie o serviço do SQL.

Faça isso em ambos os servidores!

Agora localize o Microsoft SQL Server Management Studio 18.

Abra-o e logue com a sua conta.

PONTO DE ATENÇÃO!!!
A partir daqui, tudo o que você fizer, certifique-se que está usando o mesmo usuário na qual criou o WSFC.

Antes disso:
Como tudo é autenticação no Active Directory, precisamos garantir que as contas de serviço gerem tokens confiáveis e que consigam registrar as ações no SQL Server.

Para que isso aconteça, vamos precisar criar uma Chave Simétrica e um Certificado.

A chave simétrica tem como objetivo proteger as chaves privadas dos certificados, garantindo a segurança, já que é criptografada com o algoritmo AES_256.

Já o certificado é um objeto de segurança assinado digitalmente que contém uma chave pública (e, opcionalmente, uma privada) e é protegido pela chave simétrica.

Agora vamos iniciar nosso passo a passo:

Logue no servidor primário, abra o Management Studio e execute o script abaixo para criar a Chave Simétrica.
USE master
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Wiluey@123'; GO

Lembre-se de adaptar o script para a sua realidade!

Em seguida execute o comando abaixo para criar o Certificado.
USE master
GO
CREATE CERTIFICATE Cluster_VM_BR_cert
WITH SUBJECT = 'Cluster-VM-BR certificate for Availability Group';
GO
Em seguida, execute o comando para criar o Endpoint.
USE master
GO
CREATE ENDPOINT Endpoint_AvailabilityGroup
STATE = STARTED
AS TCP
(
LISTENER_PORT = 5022, LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING
(
AUTHENTICATION = CERTIFICATE Cluster_VM_BR_cert,
ENCRYPTION = REQUIRED ALGORITHM AES,
ROLE = ALL
);
GO

Agora vamos fazer o BACKUP do Certificado, pois precisaremos copiá-lo para os outros NODES que compõem o Cluster.

Execute o comando abaixo.
USE master
GO
BACKUP CERTIFICATE Cluster_VM_BR_cert TO FILE = 'F:\data\Cluster_VM_BR_cert.cer';
GO

Copie o Certificado gerado na execução do script acima para o Servidor Secundário!

Repita o Procedimento acima nos outros Nodes do Cluster, gerando as respetivas chaves simétricas, os certificados, gerando os backups e copiando os arquivos para todos os outros nodes.

Feito isso, vamos ao passo abaixo!

Retorne ao servidor primário, lá vamos criar um Login/User com perfil administrador e posteriormente associá-lo na criação do Availability Group:
USE master
GO
CREATE LOGIN [SQL-AG] WITH PASSWORD = 'Wiluey@123';
GO

USE master
GO
CREATE USER [SQL-AG] FOR LOGIN [SQL-AG];
ALTER SERVER ROLE [sysadmin] ADD MEMBER [SQL-AG];
GO

Neste passo vamos associar a conta [SQL-AG] ao Certificado para que ela possa autenticar nos outros Nodes.
USE master
GO
CREATE CERTIFICATE Cluster_VM_EUA_cert
AUTHORIZATION [SQL-AG] FROM FILE = 'F:\data\Cluster_VM_EUA_cert.cer';
GO
Neste passo autorizamos a conta [SQL-AG] a conectar no Endpoint.
USE master
GO
GRANT CONNECT ON ENDPOINT::Endpoint_AvailabilityGroup TO [SQL-AG];
GO

Repita o Procedimento acima nos outros Nodes do Cluster, criando o Login/User e autorizando a conexão via Certificado.
Atentar-se para o certificado utilizado e justar o script.

Agora vamos criar o Availability Group!

Antes disso, acesso o SQL Server no seu servidor primário e crie um banco de dados de teste, altere o Recovery Model para FULL e faça um Backup Full deste banco de dados recém criado.

Agora sim, acesse seu servidor primário e execute o procedimento abaixo (lembre-se de fazer isso com logado com o usuário SQL-AG):
USE [master]
GO
CREATE AVAILABILITY GROUP [Wiluey_AG]
WITH
(
AUTOMATED_BACKUP_PREFERENCE = PRIMARY,
DB_FAILOVER = ON,
DTC_SUPPORT = NONE
)
FOR DATABASE [TESTE_WILUEY]
REPLICA ON
N'Cluster-VM-BR' WITH
(
ENDPOINT_URL = N'TCP://Cluster-VM-BR.ALWAYSON.COM:5022',
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
SECONDARY_ROLE
(
ALLOW_CONNECTIONS = NO
)
),
N'Cluster-VM-EUA' WITH
(
ENDPOINT_URL = N'TCP://Cluster-VM-EUA.ALWAYSON.COM:5022',
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
SECONDARY_ROLE
(
ALLOW_CONNECTIONS = NO)
);
GO
Availability Group criado, agora vamos criar o LISTENER.
USE [master]
GO
ALTER AVAILABILITY GROUP [Wiluey_AG]
ADD LISTENER N'LS_Wiluey_AG' (
WITH IP
((N'10.0.0.25', N'255.255.255.0'),
(N'10.1.0.25', N'255.255.255.0')
)
, PORT=1433);
GO

Lembrando que aqui é um IP "barra 24", já que está atrelado à Subnet da interface de rede do servidor.

Feito isso, vamos validar a conexão no SQL AlwaysOn via LISTENER

TUDO CERTO!

Agora vamos validar o Failover!

TUDO CERTO NOVAMENTE!

E com isso fechamos nossa série, nela aprendemos a criar um SQL Server AlwaysOn AG utilizando a feature Workgroup Cluster do Windows Server 2016.
Aprendemos a criar máquinas virtuais no Azure, a configurar uma interface de rede, criando VNETs e Subnets.
Também foi aprendido como se faz um Vnet Peering entre VMs em zonas de disponibilidade ou regiões distintas.

E é isso pessoal, espero que tenham gostado!

No próximo post, vamos aprender a configurar um verdadeiro Active Directory Domain Services (ADDS) como serviço e vamos inserir estas máquinas em um dominio e atrelá-las à um DNS Domain original, vamos fazer o inverso. =)

Acompanhem o blog para ficar por dentro do mundo Azure!

Grande abraço e até a próxima!

WSFC + SQL AlwaysOn no AZURE sem Active Directory [#1]

Wiluey Sousa — Wed, 05 Aug 2020 14:29:51 +0000

Fala pessoal!

Na nova série que se inicia, vamos aprender a criar um Windows Server Failover Cluster sem o uso do Active Directory (AD) no Azure.

Depois vamos criar um SQL AlwaysOn Availability Group em cima dessas máquinas usando a feature do WSFC recém criada.

A principio, o processo é bem simples, porém requer conhecimento em Azure, portanto para o post ser produtivo, vamos aprender do zero.

Então a série completa abordará:

Como criar as VNets e Subnets
Fazer o Peering entre as redes
Como criar as máquinas virtuais (VMs) no Azure
Atrelar as VNets e Setar IPs estáticos nas VMs
Criar o WSFC entre as VMs
Criar o AlwaysOn AG
Testar e validar

Lembrando que por ser um post que pretende ensinar de maneira clara e objetiva todos os níveis, vou tentar deixá-lo o mais "entendível" possível, portanto evitarei ao máximo o uso de scripts CLI ou Powershell e entrarei no detalhe de alguns conceitos.

Existem outros meios de fazer todo o processo por meio do Azure DevOps ou utilizando ferramentas de Infra as a Code (IaC) como o Terraform e o Packer, mas isso ficará para uma próxima série mais High Level.

Bom, chega de introdução, vamos la!

No post de hoje vamos aprender primeiramente a criar duas Azure Virtual Networks (VNets)e suas respectivas Subnets, como a ideia é termos alta disponibilidade, então cada uma será criada em uma Availability Zone diferente.

Mas antes: O que é uma VNET?

É o bloco fundamental de sua rede privada no Azure. Ela permite que vários tipos de recursos do Azure possam se comunicar de forma segura com a Internet, com as redes locais e com outras redes pareadas. Ela seria a sua rede principal e fazendo um comparativo com um Datacenter on-premises, seria a responsável pela conectividade entre seus servidores e seus switchs, porém aqui por ser parte de uma arquitetura própria, entrega escalabilidade, disponibilidade e isolamento.

Basicamente a sua VNet é composta pelos itens abaixo:

Address space: Como o nome diz, é seu espaço de endereço, ele hospedará sua subnet (sub-rede), onde você conectará outros recursos do Azure.
Subnets: Um segmento da rede virtual que consiste em uma ou mais sub-redes, você aloca uma parte do espaço de endereço da rede virtual (VNet) a cada uma delas. Por padrão, um IP em uma subnet pode se comunicar com qualquer outro IP dentro da VNet. Também pode ser feito uma rota de tráfego (route traffic) entre subnets e até mesmo para fora da VNet.
Regions: Cada VNet pode ser atrelada à apenas uma unica região ou localização. Caso queira conectar um ou mais subnets de regiões distintas, é necessário criar um VNet Peering.
Subscription: VNets estão no escopo de uma Subscription, ou seja, é um dos vários recursos que ficam atrelados diretamente à uma assinatura.

Pelo menos a rede no Azure é mais sobre roteamento IP. Um Datacenter tradicional geralmente usa Comutação de VLAN ou Camada 2 e menos roteamento, o que deixa a administração mais complexa.

Bom, esse é apenas um resumo básico de redes, em breve vou lançar um artigo APENAS sobre Arquitetura de Redes, ai vamos entrar no detalhe de muitas outras coisas que não cabem aqui nesta série.

Agora vamos à prática! :)

Primeiramente vamos logar no Azure: www.portal.azure.com

Acessando com a sua conta, vamos criar o grupo de recursos dentro da nossa Subscription.

Caso seja sua primeira experiência com Azure, abra o CloudShell clicando onde a seta da imagem abaixo aponta.

No primeiro acesso, ele pede a criação de uma simples Storage Account para a configuração do CloudShell, basta clicar em "yes" e tudo certo, não é necessário fazer mais nada.

Com o CloudShell ativo, execute o comando: az account list --output table

Caso você tenha mais de uma Subscription, ela será listada para você (conforme imagem abaixo).

Após decidir qual a subscription utilizar, execute o comando abaixo:
az account set --subscription "Sua SubscriptionID AQUI"

"Setando" a assinatura, agora chegou a vez de criar seu grupo de recursos (resource group).
Execute o comando abaixo:
az group create -l eastus -n Cluster_VM_Azure_EUA

Lembrando que essa primeira VNet ficará no EUA, portanto o parâmetro "-l" do script está criando o grupo de recursos e tudo o que vier a seguir na localidade East US.

A saída deverá ser idêntica a da imagem abaixo:

Feito isso, agora vamos para a criação da Azure Virtual Networks (VNet) e conforme prometido, usando pouca scriptação para facilitar o entendimento.

Volte o portal do Azure e acesse Resource Group que você acabou de criar.

Clique em "Add", conforme imagem abaixo:

No marketplace, procure por Virtual Network, conforme imagem abaixo:

Na próxima tela vamos dar um nome à nossa VNet, atrelar ao Resource Group (RG) recém criado e garantir que a Localização seja a mesma em que se encontra nosso RG, no caso, East US (vide imagem).

Agora vamos atribuir nosso espaço de endereço à nossa VNet, no caso do LAB, estipulei uma rede "/16" (barra 16) para a VNET e um "/24" para a subnet.

Ponto de Atenção: Aqui estou criando apenas os espaços de endereço (Address Space) da minha VNet, não estou definindo os IPs que minhas futuras máquinas virtuais utilizarão.
Outro ponto importante, os 3 primeiros e os 3 últimos IPs são reservados para o roteamento e a resolução de nomes do Azure, então meu range deverá obrigatoriamente começar em "10.0.0.4".

Voltando ao Azure, na próxima aba Security, deixe tudo com status DISABLE.

Agora clique em REVIEW + CREATE e depois clique em CREATE.
A partir daqui ocorrerá o deploy da sua VNet.

Agora vamos criar a outra Vnet, que será atrelada à segunda máquina virtual.
Para o artigo não ficar extenso, volte para o inicio e repita todos os passos até aqui, trocando apenas os parâmetros abaixo:

Resource Group: Cluster_VM_Azure_BR
Localização: Brazil South

Ou seja, volte ao Cloud Shell e execute o comando abaixo:
az group create -l brazilsouth -n Cluster_VM_Azure_BR

E nos passos seguintes, basta atrelar a nova VNet ao RG Cluster_VM_Azure_BR.

A partir daqui entendo que ambos os Resource Groups estão criados, as VNETs e Subnets atreladas corretamente.

Então ao final, sua rede ficou assim:

Cluster_VM_Azure_EUA
VNET: 10.0.0.0/16
SUBNET: 10.0.0.0/24
Cluster_VM_Azure_BR
VNET: 10.1.0.0/16
SUBNET: 10.1.0.0/24

Agora vamos ao passo mais importante: a criação do VNet Peering para garantir que ambas as Subnets enxerguem-se.

Acessando o Resource Group Cluster_VM_Azure_EUA, clique no recurso já criado vnet_vm_eua.

Navegue no menu à esquerda e clique em "Peerings" (imagem), depois clique em + add.

Abrirá a tela abaixo:

Atenção: As setas vermelhas são os nomes do "Peering" e a seta verde é a VNET que fará o pareamento com a nossa rede atual.
Obviamente se eu comecei configurando a VNET EUA, então nesse menu eu escolho a VNET BR.

Logo abaixo, tem as opções de permissão de tráfego:

Atenção:

Quadrado Vermelho: Estas opções habilitadas permitirão o tráfego entre as VNets.
Quadrado Verde: Permite o tráfego encaminhado de uma VNet para outra, quando temos uma VPN ou uma Vnet-to-Vnet configurada.
Quadrado Azul: Permite que se use uma VPN gateway pareada no estilo "cross-premises" ou uma VNet-to-VNet.

Depois que clicar em CREATE, o processo de deploy se iniciará.

Aqui validamos se o Peering está conectado:

Estando tudo OK, então fechamos as configurações iniciais de REDES.

No próximo post desta série, vamos criar as nossas máquinas virtuais, atribuir nossas VNets à elas, criar os IPs estáticos e habilitar o WSFC.

Até o próximo post!

Abraços.

WSFC + SQL AlwaysOn no AZURE sem Active Directory [#2]

Wiluey Sousa — Sat, 13 Jun 2020 20:48:02 +0000

Fala pessoal!

Na etapa anterior, vimos como criar as VNets, Subnets e fazer o Peering entre elas.
Agora vamos criar as nossas máquinas virtuais.

Nesta segunda parte da série vamos aprender a criar nossas Máquinas Virtuais no Azure, e como a ideia é termos alta disponibilidade total, então cada uma será criada em uma Availability Zone diferente.

Para quem não leu na primeira parte, segue o link:
https://dev.to/wiluey/wsfc-sql-alwayson-no-azure-sem-active-directory-1-405g

Vamos lá!

Vamos começar criando a máquina que ficará no EUA.

Acesse o Resource Group Cluster_VM_Azure_EUA.

Clique em "Add", conforme imagem abaixo:

No marketplace, procure pela imagem que usaremos nesta série, digite "SQL Server 2017 on Windows Server 2016", algumas opções surgirão.
Por questões de licenciamento, vamos escolher a versão Developer do SQL Server (conforme imagem):

Após escolher, basta clicar em "Create".

Abrira uma nova tela, certifique-se da região, e do modelo da imagem, veja se condizem com o selecionado.
Também dê um nome à sua máquina virtual.

Rolando mais para baixo, insira o nome do usuário que será administrador da VM e uma senha forte.
Como vamos conectar depois via Remote Desktop Protocol (ou RDP), vamos deixar a Porta 3389 que é padrão como pública.

Após isso, vá para a escolha dos tipos de disco (aqui usando o conceito de camada) conforme abaixo:

Se quiserem saber mais sobre os conceitos e arquiteturas de STORAGE, recomendo outra série minha:
https://dev.to/wiluey/azure-storage-conhece-parte-1-5a4b

Voltando...

Agora chegou a parte mais importante: Configuração de rede.

Para facilitar, todo o trabalho de configuração das VNet, Subnets e Peering foi feita na primeira parte desta série.

Podemos ver que por atrelarmos esta VM no RG que fica na região East US, ele pegou a primeira VNet (e única) disponível e já atribui às interfaces.

Lembrando que ainda não é aqui que configuraremos os IPs estáticos nas nossas máquinas virtuais.

As outras opções ficam Default mesmo.

Agora pule diretamente para a opção SQL Server Settings.

SQL Connectivity: o SQL aceitará apenas conexões das nossas VM e não estará aberto para acesso via internet.
Port: padrão 1433 (podendo usar outra se quiser).
SQL Authentication: Para permitir conexão no SQL via usuário SA.
Azure Key Vault integration: Usado para armazenar e acessar segredos de forma segura, não usaremos neste LAB.

Após isso, clique diretamente em REVIEW + CREATE e após validar as informações, confirme para iniciar o deployment da nossa primeira máquina virtual.
Esta operação levará uns 15 minutos.

Ao final do deployment, cliquem em "Go to resources" para ser direcionado para o ARM.

Você chegará nesta tela:

O Azure atribuiu um IP Publico à nossa máquina virtual e também um IP Privado, porém esse privado é entregue via DHCP, precisamos garantir que ele seja estático para que não haja troca do IP após um boot na VM.

Pensa que acabou?

Clique na opção Networking (seta vermelha da imagem acima).

Após isso, clique na interface de rede da sua VNet.

Após isso, clique na opção IP Configurations no menu à esquerda, depois clique na interface (ipconfig1).

Na próxima tela, altere a opção Assignment para Static.
Por opção defini os IPs como 10.0.0.10(EUA) e 10.1.0.10(BR), mas você pode colocar qual IP desejar, desde que eles façam parte do range pertencente às suas VNets obviamente.

Depois clique em Save para salvar as alterações e faça um Boot nas máquinas virtuais para que as interfaces de rede peguem o novo IP.

Validada a criação da máquina virtual que encontra-se nos EUA, vamos repetir todo o procedimento, agora criando a máquina na região do Brasil, apontando para o Resource Group Cluster_VM_Azure_BR.

A partir daqui presumo que as duas máquinas virtuais estão criadas e as interfaces configuradas com os IPs estáticos.

Agora vamos validar.

No ARM (Azure Resource Manager) vá na sua máquina virtual e clique em Connect, após isso, clique em RDP para acessar o Remote Desktop Protocol.

Baixando o arquivo, agora vamos acessar a nossa máquina virtual.
E feito isso, vamos desabilitar o Firewall do Windows e as opções de segurança do IE.

feito isso, vamos fazer teste de conectividade entre as máquinas virtuais.

Lembrando que uma máquina só "enxerga" a outra por causa do VNet Peering.

Agora vamos habilitar a Feature de Cluster e fechar por aqui o post.

Acesse o Server Manager e clique em Dashboard, depois em Add roles and features.

Na próxima tela que abrir, clique quatro vezes em Next até chegar na tela abaixo.

Clique onde a seta vermelha indica, depois em "Add Features" e por fim em "Next".

Agora só aguardar a instalação da Feature.

Repita o procedimento para a outra máquina virtual e pronto!

No próximo e último post da série, vamos habilitar o WSFC e configurar o SQL Server AlwaysOn AG.

Até o próximo post!

Abraços.

Azure Storage, conhece? [PARTE 2]

Wiluey Sousa — Thu, 09 Jan 2020 04:40:07 +0000

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,

Configurando sua própria Cloud Híbrida - Conheça o Azure Stack

Wiluey Sousa — Thu, 31 Oct 2019 01:48:50 +0000

Fala comunidade!

Queria compartilhar com vocês um pequeno artigo que será muito útil para você que quer se aprofundar nos estudos do Azure.

Ultimamente tenho recebido muitos questionamentos sobre como iniciar os estudos na Cloud da Microsoft, muitos falam sobre os créditos limitados, outros que não possuem cartão de crédito, item obrigatório para configurar sua conta no Azure, outros sobre o fato de ter que estar conectado a internet (e em alguns cenários, isso pode ser uma dificuldade pessoal) e claro, os valores dos produtos que podem acabar com os créditos antes do planejado.

Então para resolver uma grande parte deste impasse, a Microsoft criou o Azure Stack.

E o que é isso?

Simples, é uma plataforma de nuvem híbrida local (seu computador) na qual simula um ambiente de infraestrutura como serviço (IaaS) e alguns serviços de plataforma (PaaS).

Como assim?

Significa que você poder ter um ambiente Azure simulado no seu ambiente para poder estudar e aplicar a maioria dos serviços que a Cloud da Microsoft oferece. Genial!

Obviamente, por questões arquiteturais, nem todos os serviços do Azure estão disponíveis. Mas isso não interfere em quase nada seu aprofundamento nos estudos.

E que arquitetura é essa?

Antes, precisamos entender no que ela se baseia: Em Arquitetura Hiperconvergente, do inglês hyperconverged infrastructure (HCI).

A Arquitetura Hiperconvergente é uma solução simplificada que utiliza Softwares e dispositivos x86 modernos em substituição à Hardwares de alto custo.
Com isso você combina armazenamento, computação e rede em um único sistema que pode reduzir a complexidade do datacenter e aumentar sua escalabilidade, com isso, as funções críticas do próprio datacenter são executadas em uma camada de software totalmente integrada.

Não entendeu?
Pense que agora toda a sua infraestrutura é executada em cima de um hypervisor, como o Hyper-V por exemplo.

Topologia simples da integração do Azure Stack em HCI.

Uma observação, se sua empresa quiser "rodar" como uma nuvem privada, existem hardwares criados exclusivamente para que você administre sua Infra Hiperconvergente como o Dell EMC Storage Spaces Direct Ready Node - R640 All-NVMe que é homologado pela própria Microsoft.

Assim você pode ter "seu próprio Azure" e integrar soluções híbridas com a Cloud Pública.

Onde isso se encaixa?

Em soluções de migração e estudos em como converter aplicações e serviços que possam ser executados diretamente no Azure, sem usar o conceito de "Lift-and-Shift".

Agora que entendemos como se baseia o Azure Stack, que tal configurarmos o nosso próprio ambiente e começar os estudos?

Para começar, baixe a imagem do Azure Stack no link abaixo:
https://azure.microsoft.com/pt-br/overview/azure-stack/development-kit-thank-you/

Feito isso, dê permissões para o seu usuário Powershell rodar scripts não assinados.
Abra a console do Powershell como administrador e execute o script abaixo:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Execute o script abaixo (lembrando de apontar o caminho da variável $LocalPath para a pasta onde você baixou a imagem do Azure Stack), tire o "--" do script:

--##Variables
$Uri = 'https://raw.githubusercontent.com/Azure/AzureStack-Tools/master/Deployment/asdk-installer.ps1'
$LocalPath = 'D:\AzureStack_Installer'
--##Create folder
New-Item $LocalPath -Type directory
--##Enforce usage of TLSv1.2 to download from GitHub
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
--##Download file
Invoke-WebRequest $uri -OutFile ($LocalPath + '\' + 'asdk-installer.ps1')

O script acima criará um arquivo chamado "asdk-installer.ps1" no caminho especificado na variável $LocalPath.

Via Powershell (como administrador) execute o script abaixo que será baixado no passo acima (lembrando de mudar o caminho):
D:\AzureStack_Installer\asdk-installer.ps1

Agora é só selecionar a imagem na tela de Deployment e configurar o seu ambiente. =)

A partir de então, tudo será simples e bastante auto-explicativo.

Aproveite seu ambiente Azure simulado e estude!

Até o próximo post!

Abs,

Azure Storage, conhece? [PARTE 1]

Wiluey Sousa — Sat, 26 Oct 2019 04:15:22 +0000

Muitos analistas de infraestrutura e DBAs trabalham com discos, isso já é de conhecimento de quem atua na área de TI, certo?

Mas tratando-se de disco, muitas vezes o analista ou DBA fica perdido em uma análise ou troubleshooting, pois isso vai além da ferramenta em que o profissional atua. Porém "disco" (em aspas mesmo) muitas vezes é o responsável pelo gargalo e lentidão de um ambiente.

Antes de entrarmos no mundo Cloud Azure, que tal conhecermos melhor o que é uma Storage e como administramos isso?

Então vamos lá!

Como posso entender qual o melhor disco para o meu banco de dados ou aplicação? Quando migrar as aplicações para o Azure (Cloud da Microsoft), como saber a melhor escolha?

Antes de mais nada, vamos dar um passo para trás e entender o conceito de storage para clarear o entendimento.

Segundo a InfoB: "Storage é um hardware que contém slots para vários discos, ligado aos servidores através de iSCSI (protocolo de rede) ou Fibra Ótica (Fiber Channel). Ele é uma peça altamente redundante e cumpre com louvor a sua missão, que é armazenar os dados da sua empresa com segurança".

Bom, no geral já sabemos como é o conceito, a partir daqui vamos entender como isso funciona na prática.

O servidor de banco de dados, não conecta diretamente numa Storage, ele utiliza os protocolos específicos acima para estabelecer uma comunicação direta, passando por um Switch Fabric ou uma HBA (vamos entender mais lá na frente).

As Storage dividem-se em três tipos: DAS, NAS e SAN.
E quais as diferenças entre eles?

DAS (Direct Attached Storage): Um dispositivo externo que vai conectado diretamente aos computadores ou servidores. Um exemplo prático são os HDs Externos.

NAS (Network Attached Storage): É ligado diretamente na rede e roda um sistema operacional próprio e completo. Um File Server (servidor de arquivos) é um exemplo prático já que ele pode compartilhar e gerenciar as informações armazenadas.

SAN (Storage Area Network): Como o NAS, também é uma rede dedicada, mas a diferença consiste no aumento do desempenho, da velocidade e da segurança no acesso aos dados armazenados.

Ai fica a questão, o que foi apresentado acima são protocolos de rede, o que isso tem a ver com Storage?

Bom, uma analogia simples seria comparar a um corpo humano. Se uma Storage é o coração do armazenamento, os protocolos de redes são as artérias por onde os dados trafegam, ou seja, são tão importantes quanto e influenciam diretamente na performance do seu banco de dados ou aplicação.

Mas ainda falta um componente importante, a Placa HBA!

A HBA (Host Bus Adapter) é a responsável por "traduzir" em uma rede SAN os protocolos de redes externos e internos que são trafegados, ela possui um chip próprio que evita sobrecarga da CPU no processo de conversão.

Existem muito mais para falar sobre isso como HUB, Switches, Bridges Fibre Channel SCSI, BCV (Business Continuance Volumes) e iSCSI Extensions for RDMA (iSER), mas o artigo é sobre Storage e não Redes, correto?

Acima um desenho simples de uma topologia de rede SAN

Continuando o assunto, agora já sabemos como nossos dados trafegam entre nossos os servidores e a storage e a importância de ter uma topologia correta.

Mas e os discos, cadê?

Calma, ainda faltam mais coisas pra você aprender, mas prometo que valerá a pena.

A Storage é um conjunto de vários discos e de diversas volumetrias e estes discos podem ser somados formando uma unidade maior.

E como isso é feito?
Primeiro que não dá pra fazer uma fusão física dos discos, é impossível, mas posso fazer o sistema operacional "enxergar" um disco lógico.
Esse disco é conhecido como LUN (Logical Unit Number), que é um subconjunto dos discos apresentados, ou seja, usando um exemplo simples, fisicamente eu uso 2 discos de 500GB, mas o Windows enxerga um disco de 1TB.

Mas porque o SO não enxerga dois discos de 500GB?
Simples, porque entre o SO e a Storage, existe um software chamado Multipath IO (ou MPIO para os íntimos), nativamente o Windows Server possui este software, mas é recomendado sempre utilizar o software Multipath IO do fabricante da Storage que você contratou/comprou.

E o que o MPIO faz?
Ele define mais de um caminho usando a placa HBA (Host Bus Adapter), ou seja, ele unifica logicamente os "caminhos" que passam pela controladora. Por isso o SO enxerga um disco de 1TB e não 2, lembrando que uma vez montado o disco, eu apresento a volumetria ao SO contabilizando cada "path" usado pra montar o volume lógico, por isso o MPIO é importante.

Ok, já entendemos o conceito de LUN e o que faz o MPIO, mas e o RAID?

Vamos lá, RAID é uma sigla em inglês para Redundant Array of Inexpensive Disks, que em tradução livre significa Matriz Redundante de Discos Independentes.
Não entendeu? simples, RAID nada mais é que o nome dados aos discos que foram unificados logicamente para formar uma unidade de armazenamento maior.

Só que existe algo muito importante para entender: Os RAIDS que você consegue montar e quais as importâncias e diferenças em cada tipo e como isso influencia no seu ambiente.

RAID 0 (zero):
Usando o conceito de “fracionamento”, quando montamos uma unidade lógica com varios discos, o arquivo ou dado gravado fragmenta-se entre os discos, aumentando o throughput, por exemplo, um RAID 0 com dois discos de 50 MB/s, resultariam num disco com velocidade de 100 MB/s.
O RAID 0 é usado para melhorar o desempenho porém sacrificando a confiabilidade, isso significa que ele NÃO É tolerante a falhas.

Vantagens: Muito rápido para acesso e baixo custo.
Desvantagens: Não faz paridade de dados e não tolera falhas, em caso de corrupção de um dos sectors do disco, você pode perder toda a informação.

Figura de um RAID 0

RAID 1:
Usa o conceito de espelhamento, no modo simples, é termos os dados de um disco em outro. É mais seguro que o RAID 0 e não há perda de desempenho para leitura.

Vantagens: Segurança dos dados, caso algum setor de disco falhe, você consegue recuperar copiando os arquivos de outro disco.
Desvantagens: Não é usada paridade, escrita é mais demorada e maior custo.

Figura de um RAID 1

RAID 2:
Praticamente caiu em desuso porque os novos HDs já saem de fábrica com mecanismos similares a ele e que impedem certas falhas.
O RAID 2 é (ou era) uma técnica que dividia os dados no nível de bit usando um Código Hamming (What?) para detectar erros.
O Código Hamming é um conjunto de códigos de correção de erros que podem ser usados para detectar e corrigir "erros de bits" que podem ocorrer.

Figura de um RAID 2

RAID 3:
Usa um sistema de paridade para manter a integridade dos dados. Num sistema com 5 HDs por exemplo, o 4 primeiros servirão para armazenar dados, enquanto o último armazenará os códigos de paridade.

Vantagens: Lê e escreve muito rápido e tem controle de erros.
Desvantagens: Disponíveis apenas em controladoras SCSI e mais complexo de montar via software.

Figura de um RAID 3

RAID 4:
O RAID 4 é similar ao 3, com a diferença dos dados serem divididos entre os discos. Porém a gravação requer que a paridade seja atualizada toda as vezes que ocorrerem gravações no disco, tornando-a mais lenta a gravação dos dados.

Vantagens: Taxa de leitura e pode-se inserir mais discos físicos na storage e aumentar o volume lógico.
Desvantagens: Taxa de gravação lenta e exige no mínimo três discos rígidos.

Figura de um RAID 4

RAID 5:
É a evolução natural das versões 2, 3 e 4, utilizando discos completos para fazer a paridade dos outros discos, ou seja, temos informação redundante.
O sistema aqui é mais complexo e a paridade é armazenada de forma alternada em vários discos. Usa complexas fórmulas matemáticas e complexos algoritmos que comprimem os dados, gerando assim, a paridade.
Apesar de haver uma perda de desempenho durante a gravação (devido ao calculo de paridade) em comparação com RAID 0, o RAID 5 faz a leitura e gravação simultânea de todos os discos do array o que ocasiona considerável aumento de desempenho se comparado com a utilização de apenas 1 disco.

Vantagens: Mais rápido pra identificar erros e leitura rápida.
Desvantagens: Escrita lenta e sistema de controle de discos mais complexo.

Figura de um RAID 5

RAID 6 (Dupla Paridade):
É uma evolução do RAID 5, gravando dados com duas camadas de bits de paridade, esse arranjo permite que até dois discos falhem no mesmo conjunto sem que haja perda de dados. Oferece boa tolerância a falhas, sendo utilizado em ambientes onde é priorizada a segurança dos dados armazenados.

Vantagens: Possibilidade de falhar 2 Hds ao mesmo tempo sem perda de dados.
Desvantagens: Precisa de pelo menos 3 Hds para ser implementado por causa da paridade, sua escrita é mais lenta, controle de dados também é complexo.

Figura de um RAID 6

RAID 10:
É um sistema que empresta características dos RAIDs 0 e 1. Esse sistema só pode ser usado com mais de 4 discos e SEMPRE em número par.
Há uma diferença na montagem, podemos escolher "0 + 1" ou "1 + 0", mas qual a diferença?
0 + 1: É uma fusão do striping (RAID 0) e do mirroring (RAID 1), em caso de falha o sistema se transforma e atua como RAID 0.
1 + 0: Um RAID hibrido, em caso de falha o sistema se transforma e atua como RAID 1.

Vantagens: Segurança contra perda de dados e pode falhar um ou dois HDs ao mesmo tempo. É considerado o mais seguro que existe.
Desvantagens: Alto custo de expansão e uma solução cara. Os Drivers devem ficar em sincronismo de velocidade para ampliar a performance.

Figura de um RAID 10

Legal fera, mas você esqueceu de uma coisa: O que é paridade?
Para explicar de uma forma mais simples, a paridade é a soma de todos os dispositivos utilizados numa matriz (array).

Como assim?
É um sistema de capacidade para recuperar a informação no caso de um erro de disco usando uma forma de redundância de bits. Sacou?

E fechando a explicação de discos, o que são "Hot Spare" ou "Spare Disk"?

Hot Spare ou Spare Disk é um disco sobressalente que pode ser adicionado ao array para assumir automaticamente o papel de um dos discos do próprio array quando houver falha, permitindo assim que os dados sejam restaurados automaticamente de maneira transparente ao usuário e mantendo o sistema íntegro, sem quedas de desempenho. Apesar dos spare disk não serem muito conhecidos, eles são amplamente utilizados em grandes arrays de discos em RAID 5 ou 6.

Bom, até aqui aprendemos o necessário para conhecer uma storage e como estas informações serão úteis daqui pra frente para você que depende dos discos para uma boa performance e segurança dos seus ambientes.

Na próxima parte, conheceremos o conceito de TIER e entraremos com tudo o que aprendemos até aqui no mundo Azure, agora de forma objetiva ;).

Até o próximo post!

Abs,