Auto Scale de WebApp no Microsoft Azure

Auto Scale de WebApp no Microsoft Azure

Caro leitor, seja bem-vindo ao Blog Jefferson Castilho.

Fico muito grato com sua visita, o tema de hoje é “Auto Scale de WebApp no Microsoft Azure”.

Neste artigo vou explicar um pouco sobre como podemos criar um Auto Scale de uma Web App ou “App Service” dentro do Microsoft Azure.

Para quem não sabe o que é o Auto Scale temos os dois modelos abaixo.

Dimensionamento vertical, também chamado de aumento e redução vertical, significa que é possível alterar a capacidade de um recurso. Por exemplo, você pode mover um aplicativo para um tamanho maior de VM.

Geralmente, o dimensionamento vertical requer que o sistema fique temporariamente indisponível enquanto é reimplantado. Portanto, não é comum automatizar o dimensionamento vertical.

Dimensionamento horizontal, também chamado de expansão e redução horizontal, significa que é possível adicionar ou remover instâncias de um recurso. O aplicativo continua em execução sem interrupções conforme os novos recursos são provisionados.

Quando o processo de provisionamento é concluído, a solução é implantada com esses recursos adicionais. Se a demanda cair, os recursos adicionais poderão ser desligados e desalocados.

Fonte Docs

Iniciando o processo de criação do Auto Scale para uma WebApp temos que ir em “App Service Plans”.


Temos que selecionar qual o “App Service Plan” que iremos configurar o “Auto Scale”.


No menu dentro do recurso do “App Service Plan” podemos selecionar a opção “Scale out (App Service Plan).


Scale Manual

Temos duas opções de configurações do “Scale” com a opção “Manual” que você configurar quantas máquinas for necessário dependendo do Size que “App Service Plan” suportar.

Na opção “Custom Auto Scale” esse podemos definir a quantidade de máquinas que o plano suportar, com uma opção que podemos definir métricas de “Processamento” que faz o provisionamento da máquina sozinha. Sem precisar de intervenção humana.


Custom AutoScale

Podemos manter o padrão que é baseado no “Scale Manual” que é feito pela opção “Scale to specific instance count” ou podemos configurar o modo “Scale Based on a Metric” que podemos manter métricas de processamento para o “Scale In” ou “Scale Out”.


Neste modo podemos configurar “regras” para o “Scale In” ou “Scale Out” selecionando a opção “Add a rule”.

Teremos algumas opções que iremos configurar para a criação do “Scale Out”

Metric Source: É o Recurso que teremos que configurar.

Time aggregation: Temos que selecionar opção que iremos usar para o método de no caso será o “Average”.

Metric Name: Iremos utilizar o “CPU Porcentage” que iremos realizar a métrica do “Scale In” pelo uso de Porcentagem de CPU.

Operator: Temos que definir a opção “Greater Than” que é maior que o numero mencionado na “Threshold” que for maior que “70%” por “Duration de 5 Minutes” ele provisiona uma máquina.


Teremos algumas opções que iremos configurar para a criação do “Scale In”

Metric Source: É o Recurso que teremos que configurar.

Time aggregation: Temos que selecionar opção que iremos usar para o método de no caso será o “Average”.

Metric Name: Iremos utilizar o “CPU Porcentage” que iremos realizar a métrica do “Scale In” pelo uso de Porcentagem de CPU.

Operator: Temos que definir a opção “Less than” que é menor que o número mencionado na “Threshold” que for menor que “20%” por “Duration de 5 Minutes” ele desprovisiona uma máquina.


Na aba “Instance limits” podemos definir quantas máquinas desejamos que ele faça o “Scale Out” e o “Scale In” dependendo do seu “Size”

Minimum – 1

Maximum – 4

Default – 1

Que podemos manter um mínimo de 1 máquina, com um possível Scale Out de 4 máquinas.

Após isso podemos selecionar a “Opção de Save”.


Teremos a opção do Auto Scale habilitado com as métricas configuradas. Um ponto importante que cada “escalonamento” com a criação de uma nova máquina será pago por duas máquinas a primeira e a segunda criada.

Por exemplo

Temos um Size X com uma máquina que custa “R$300,00” por um mês, usei o primeiro mês uma máquina paguei “R$300,00”, no segundo mês fiz o processo de escalonar mais uma máquina usando duas máquinas no mês, vou pagar “R$600,00”.

Lembrando que você paga por hora utilizada, então se não usamos o “mês todo” vamos pagar somente pelo uso.

Conhece as minhas redes sociais? E meu canal no Youtube?

Caso não acesse nos links abaixo e se cadastre para não perder as oportunidades

de receber os links quando forem publicados.

Facebook:  https://www.facebook.com/blogjeffersoncastilho
Youtube:  https://goo.gl/1g3OvL

Twitter:  https://twitter.com/je_will

Em caso de dúvidas ou problemas na execução, pode deixar seu comentário que em breve responderemos.

Obrigado e até o próximo post.

Jefferson Castilho 
Certificações: MPN | MCP | MCTS | MCTIP | MS | MCSA | MCSE  | MCT  
Blog MVP  :  http://jeffersoncastilho.com.br
Facebook:  https://www.facebook.com/blogjeffersoncastilho
Youtube:  https://goo.gl/1g3OvL

Stop VM, reserva de IP Público Azure

Stop VM, reserva de IP Público Azure

Caro leitor, seja bem-vindo ao Blog Jefferson Castilho.

Fico muito grato com sua visita, o tema de hoje é “Stop VM, reserva de IP Público Azure”.

Hoje trago uma novidade que sempre quando criamos uma VM no Microsoft Azure, por default o IP Publico dela vem como “Dinâmico”.

Isso sempre foi um problema que caso não fosse habilitado o IP como “Estático” dentro das propriedades do IP Público após o reboot ou processo de desalocate da VM, esse IP era liberado para outra máquina virtual gerando transtorno para o administrador do Azure.

O Microsoft Azure disponibilizou o processo quando é criado uma nova VM, após o primeiro “Stop” dela temos um Pop-Up de informação se desejamos reservar esse IP Público para essa VM como na imagem abaixo.

Caso você selecione a opção que deseja reservar o IP Público, no processo de desligamento dela o IP será mantido.


Uma dica superinteressante que nos ajuda no dia-dia de configuração das Virtual Machine do Azure.

Conhece as minhas redes sociais? E meu canal no Youtube?

Caso não acesse nos links abaixo e se cadastre para não perder as oportunidades

de receber os links quando forem publicados.

Facebook:  https://www.facebook.com/blogjeffersoncastilho
Youtube:  https://goo.gl/1g3OvL

Twitter:  https://twitter.com/je_will

Em caso de dúvidas ou problemas na execução, pode deixar seu comentário que em breve responderemos.

Obrigado e até o próximo post.

Jefferson Castilho 
Certificações: MPN | MCP | MCTS | MCTIP | MS | MCSA | MCSE  | MCT  
Blog MVP  :  http://jeffersoncastilho.com.br
Facebook:  https://www.facebook.com/blogjeffersoncastilho
Youtube:  https://goo.gl/1g3OvL


Windows Server 2019 no Microsoft Azure

Windows Server 2019 no Microsoft Azure

Caro leitor, seja bem-vindo ao Blog Jefferson Castilho.

Fico muito grato com sua visita, o tema de hoje é “Windows Server 2019 no Microsoft Azure”.

Neste artigo vou mostrar como podemos criar uma máquina no Microsoft Azure.

Como base temos algumas novidades bastante interessantes da versão 2016 para a versão 2019.

  • Windows Admin Center
  • Experiencia Desktop
  • Insight de Sistema.
  • Recurso sob demanda de compatibilidade de aplicativos do Server Core
  • Proteção Avançada contra Ameaças do Windows Defender (ATP)
  • Segurança com SDN (Rede Definida pelo Software)

Entre outras que podemos ver no link de referência do “Docs”.

Link

Para criação desta VM, temos que no portal do Azure, selecionar a opção “All Services” / Virtual Machine / Create Virtual Machine.

Na opção “Basic” temos que apontar os principais itens de configuração da VM.

  • Criação do Resource Group
  • Nome da VM
  • Datacenter
  • Imagem
  • Size
  • Usuário de Administrador
  • Senha
  • Regra de Portas de Entrada (Por Default habilito a 3389)

Após isso selecione a opção “Next Disk”. Nessa opção iremos selecionar qual disco desejamos.

  • Premium SSD – Camada de SSD com uma tier maior, muito utilizado para quem necessita de muitos IOPS.
  • Standard SSD – Camada de SSD com um tier menor, rápido porem com um consumo de IOPS menor e mais barato.
  • Standard HDD – Camada em HDD com um tier mais lento, porem mais barato e mais utilizado.

Na opção “Use Managed disks” mantenha a opção “Yes” para discos gerenciados.

Em Network temos o processo de validação de qual Vnet deseja inserir sua VM.

Por Default ela já cria um IP Público, indicado para quem vai hospedar algum dado na VM.

Não recomendado para quem tem VPN Site to Site, pois o acesso RDP por default já vem habilitado.

Em “Management” podemos manter o padrão, mais podemos visualizar as informações de boot da VM na opção de “Boot Diagnostics”.

Em OS Guest Diagnostics, opção para validação de uso de Performance, usado no Azure Monitor / OMS.

Podemos inserir a máquina diretamente no domínio que seja Azure Active Directory.

Você pode habilitar o Auto Shutdown para máquinas de laboratório e não produtiva.

Em “Advanced” podemos habilitar extensões que por default não vem instaladas nas máquinas.

Temos dois recursos “Cloud Init” que funciona com Boot para VM´s Linux e o “VM Generation” que herda a opção do Hyper-V que agora teremos o suporte para máquinas com “.vhdx” que antes só eram suportados “.vhd” mais essa opção ainda é “preview” e não aconselho o uso dela em produção.

Após isso selecione a opção “Review + create”, caso tenha a opção de “Validation passed” pode selecionar a opção “Create”.

Será iniciado o processo de criação da VM com o Windows Server 2019.

A Virtual Machine já foi criada com sucesso.

Informações da Virtual Machine criada.

Conhece as minhas redes sociais? E meu canal no Youtube?

Caso não acesse nos links abaixo e se cadastre para não perder as oportunidades

de receber os links quando forem publicados.

Facebook:  https://www.facebook.com/blogjeffersoncastilho
Youtube:  https://goo.gl/1g3OvL

Twitter:  https://twitter.com/je_will

Em caso de dúvidas ou problemas na execução, pode deixar seu comentário que em breve responderemos.

Obrigado e até o próximo post.

Jefferson Castilho 
Certificações: MPN | MCP | MCTS | MCTIP | MS | MCSA | MCSE  | MCT  
Blog MVP  :  http://jeffersoncastilho.com.br
Facebook:  https://www.facebook.com/blogjeffersoncastilho
Youtube:  https://goo.gl/1g3OvL

PowerShell – Alterando o LRS Site Recovery

PowerShell – Alterando o LRS Site Recovery

Caro leitor, seja bem-vindo ao Blog Jefferson Castilho.

Fico muito grato com sua visita, o tema de hoje é “PowerShell – Alterando a redundância LRS Site Recovery”.

Neste artigo vou mostrar como podemos alterar a redundância de armazenamento de datacenter para “LRS”

LRS – Locally redundant storage

O armazenamento localmente redundante (LRS) fornece pelo menos 99,999999999% (11 noves) de durabilidade dos objetos em um determinado ano. O LRS fornece a durabilidade deste objeto, replicando seus dados para uma unidade de escala de armazenamento. Um datacenter, localizado na região onde você criou sua conta de armazenamento, hospeda a unidade de escala de armazenamento.

O que é?

O LRS é a opção de replicação de menor custo e oferece a menor durabilidade em comparação com outras opções. Em caso de desastre no nível de datacenter (por exemplo, incêndio, inundação etc.), as réplicas podem ser perdidas ou ficar irrecuperáveis. 

Para reduzir esse risco, a Microsoft recomenda o uso de armazenamento com redundância de zona (ZRS) ou armazenamento com redundância geográfica (GRS).

Fonte de Dados acima, Docs Microsoft.

Este procedimento para a criação do site recovery é muito importante no início da implementação, uma vez inserido dados neste cofre não é mais possível a mudança dessa propriedade.

Como podemos alterar essa opção? No comando podemos executar alterando a opção para LRS (Locally redundant storage).

$vaultbackup = Get-AzureRMRecoveryServicesVault -Name “backup-iaas”


Após de ter executado criando a variável, podemos testar a variável chamado ela no powershell “$vaultbackup” terá que retornar as informações do Vault.


Para validar qual o modelo de “Redundância está configurado” no comando abaixo.

Get-AzureRmRecoveryServicesBackupProperties -Vault $vaultbackup


Iremos executar o comando para alterar

Set-AzureRmRecoveryServicesBackupProperties -Vault $vaultbackup -BackupStorageRedundancy LocallyRedundant


Conhece as minhas redes sociais? E meu canal no Youtube?

Caso não acesse nos links abaixo e se cadastre para não perder as oportunidades

de receber os links quando forem publicados.

Facebook:  https://www.facebook.com/blogjeffersoncastilho
Youtube:  https://goo.gl/1g3OvL

Twitter:  https://twitter.com/je_will

Em caso de dúvidas ou problemas na execução, pode deixar seu comentário que em breve responderemos.

Obrigado e até o próximo post.

Jefferson Castilho 
Certificações: MPN | MCP | MCTS | MCTIP | MS | MCSA | MCSE  | MCT  
Blog MVP  :  http://jeffersoncastilho.com.br
Facebook:  https://www.facebook.com/blogjeffersoncastilho
Youtube:  https://goo.gl/1g3OvL


PowerShell – Alterando o GRS do Site Recovery

PowerShell – Alterando o GRS do Site Recovery

Caro leitor, seja bem-vindo ao Blog Jefferson Castilho.

Fico muito grato com sua visita, o tema de hoje é “PowerShell – Alterando o GRS do Site Recovery”.

Neste artigo vou mostrar como podemos alterar a redundância de armazenamento de datacenter para “GRS”

GRS – Geo-redundant storage

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, replicando dados para uma região secundária situada a centenas de milhas de distância da região primária.

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.

Para uma conta de armazenamento com GRS ou RA-GRS habilitada, todos os dados são primeiro replicados com armazenamento redundante localmente (LRS). Uma atualização primeiro é confirmada para o local primário e replicados usando o LRS.

A atualização, em seguida, é replicada assincronamente para a região secundária usando GRS.

Quando dados são gravados para o local secundário, ela também é replicada dentro desse local usando o LRS.

Fonte de Dados acima, Docs Microsoft.

Este procedimento para a criação do site recovery é muito importante no inicio da implementação, uma vez inserido dados neste cofre não é mais possível a mudança dessa propriedade.

Como podemos alterar essa opção? No comando podemos executar alterando a opção para GRS (Geo-redundant storage).

Criação da variável que traz as informações do Recovery Services.

$vaultbackup = Get-AzureRMRecoveryServicesVault -Name “backup-iaas”


Após de ter executado criando a variável, podemos testar a variável chamado ela no powershell “$vaultbackup” terá que retornar as informações do Vault.


Para validar qual o modelo de “Redundância está configurada” no comando abaixo.

Get-AzureRmRecoveryServicesBackupProperties -Vault $vaultbackup


Iremos executar o comando para alterar

Set-AzureRmRecoveryServicesBackupProperties -Vault $vaultbackup -BackupStorageRedundancy GeoRedundant


Após alterado, podemos usar o comando que efetuamos para validar as configurações.


Conhece as minhas redes sociais? E meu canal no Youtube?

Caso não acesse nos links abaixo e se cadastre para não perder as oportunidades

de receber os links quando forem publicados.

Facebook:  https://www.facebook.com/blogjeffersoncastilho
Youtube:  https://goo.gl/1g3OvL

Twitter:  https://twitter.com/je_will

Em caso de dúvidas ou problemas na execução, pode deixar seu comentário que em breve responderemos.

Obrigado e até o próximo post.

Jefferson Castilho 
Certificações: MPN | MCP | MCTS | MCTIP | MS | MCSA | MCSE  | MCT  
Blog MVP  :  http://jeffersoncastilho.com.br
Facebook:  https://www.facebook.com/blogjeffersoncastilho
Youtube:  https://goo.gl/1g3OvL