Caro leitor, seja bem-vindo ao Blog Jefferson Castilho.
Fico muito grato com sua visita, o tema de hoje é “Adicionando um disco em uma VM no Microsoft Azure”.
Dica rápida como podemos adicionar um disco adicional em uma Virtual Machine dentro do Microsoft Azure.
Para isso, temos que selecionar qual VM o disco será inserido, após selecionar a VM, podemos selecionar a opção “Disks”.
Selecione a opção “Edit”.
Selecione a opção “Add data Disk” e “Create Disk”.
No processo de criação desse disco temos alguns passos importantes para não termos surpresas.
Nome do Disco
Resource Group que deseja armazenar esse Disco.
Size do Disco que desejamos criar.
Size de Discos, temos 3 modelos de discos, “Stardand HDD” “Stardand SSD” “Premium SSD”. Observação que os discos em camada de Tier “SSD” tem um custo maior devido a sua velocidade.
Tamanho do disco desejado em “GB”.
Nesta opção podemos criar um disco Customizado com um valor que não temos na listagem no item “5”.
Depois de tudo seleciona a opção “OK”.
Create.
Após a criação voltará para a pagina de criação do disco, no qual teremos que selecionar a opção “Save”.
Para uma validação podemos ir na VM que criamos o disco e validar se o disco está presente. Para isso na VM teremos que ir na opção “Control Panel / Administrative Tools”
Em “Administrative Tools” temos que selecione a opção “Computer Management”.
Em “Computer Management” temos que selecionar a opção “Disk Management” no qual já teremos o disco de “1023 GB”. No caso é só efetuar o processo de formatação padrão do Disco.
Após isso teremos uma nova partição de “1TB”.
Você 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.
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.
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
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
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
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).
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.
