ADM de Redes

Um Blog sobre o dia a dia do Administrator de Redes e Servidores Microsoft

By

Basic ou Standard? Com que Máquina Virtual eu vou no Azure?

Olá Pessoal,

Uma das coisas que deixa dúvidas quando você está criando uma Máquina Virtual no Microsoft Azure é a opção de Basic ou Standard, veja:

Mas afinal, o que significa isso? A diferença entre Basic e Standard é pequena, mas pode ser relevante caso você queira utilizar alguma configuração que só está disponível no Standard.

Basicamente (Desculpe o trocadilho), a Máquina Virtual Basic não tem os recursos de Load Balance e AutoScale. Além disso, Máquinas Virtuais Standard tem mais opções de tamanho de Máquina. Além disso, existe uma diferença de preço entre as duas categorias, mesmo para Máquinas Virtuais com o mesmo tamanho, veja:

Na tabela acima, você pode verificar que existe uma pequena diferença para o mesmo tamanho de Máquinas Virtuais Basic e Standard. A tabela acima está com os valores em U$ e para o Datacenter do Brasil. Para mais informações, acesse: http://azure.microsoft.com/en-us/pricing/details/virtual-machines.

Se você já sabe de antemão que não irá necessitar dos recursos de Load Balance e AutoScale, e que estes tamanhos de Máquina Virtual atendem suas necessidades, você pode optar por uma Máquina Virtual Basic. Veja que se você precisar alterar esta configuração, isso é possível. Na console de gerenciamento do Azure, você deverá selecionar a Máquina Virtual e clicar em “Configure”, veja:

Veja porém que caso você faça a alteração a Máquina Virtual pode ser alterada:

Nos próximos posts, vou explicar como configurar o Load Balance e AutoScale nas Máquinas Virtuais do Azure.
Até mais!

By

Cloud Service e Availability Set no Microsoft Azure

Olá Pessoal,

Com mais empresas utilizando o modelo de IaaS (Infaestruturas como Serviço) no serviço de Cloud do Microsoft Azure, algumas dúvidas vão surgindo, pois a forma como você gerencia uma Máquina Virtual em um modelo de Nuvem, apesar de simples, não é exatamente igual ao modelo tradicional de Virtualização.

No Microsoft Azure, quando você cria uma Máquina Virtual uma das configurações que você precisa fornecer é o endereço de Cloud Service desta Máquina Virtual. Veja:

O Cloud Service é basicamente o nome público que esta VM vai receber, o IP Público deste nome público, uma fronteira de Firewall e a configuração de Load Balance. Isso significa que o nome, como acima, admderedes100.cloudapp.net estará respondendo por esta VM após a criação da mesma. Isso não significa que a VM vai estar de forma desprotegida, simplesmente aberta na Internet. Tanto que outro ponto que você precisa indicar são quais portas públicas (Endpoints) estarão abertas nesta Máquina Virtual, veja:

Veja que por padrão, apenas as portas de Remote Desktop e Powershell estão abertas. E mesmo assim, a porta de Remote Desktop pública não é a porta 3389 padrão, para que isso também não seja explorado. De qualquer maneira, estas são as portas que permitem que após a criação da VM, você consiga gerenciar esta VM. Se você simplesmente remover estas portas, você perderá totalmente o acesso a VM e irá precisar recriar a mesma.

Outro ponto é que você pode atribuir outras portas (Endpoints) para o Cloud Service desta VM, de acordo com os serviços que esta VM vai oferecer. Por exemplo, se esta VM for um servidor Web, você pode querer abrir porta 80 e/ou 443. Se for um servidor DNS, você pode abrir a porta 53, e assim por diante.

Agora, uma das coisas que poucos sabem que você pode fazer é colocar mais de uma VM dentro do mesmo Cloud Service. Isso fará com que o Azure coloque automaticamente as VMs em um Load Balance dentro do nome público do Cloud Service. Para fazer esta operação no momento de criação da primeira VM, você irá criar a VM com o Cloud Service novo, no nome a ser utilizado. No momento da criação da segunda VM, você irá selecionar a opção de utilização de um Cloud Service já criado, veja:

Isso é muito legal, pois permite que você tenha balanceamento de carga para este nome público. Porém requer atenção à um ponto importante. Neste post eu expliquei como funcionam os Affinity Groups no Azure. Se você reparar na imagem acima, a opção de “Region/Affinity Group/Virtual Network” está desabilitada, pois o Azure identificou a informação da primeira VM e colocou esta nova VM no mesmo “local”. Assim como expliquei no post sobre Affinity Group, o motivo para isso é para que as VMs fiquem próxima uma à outra. Isso leva a um cenário onde as VMs podem acabar ficando dentro do mesmo Rack, inclusive, no datacenter selecionado. Na eventualidade de um problema neste Rack as VMs que estiverem nele serão afetadas ao mesmo tempo, degradando todo o serviço colocado em um único Cloud Service.

Para resolver esta questão, você pode utilizar um Availability Set. O Availability Set é uma configuração que está disponível quando você coloca mais de uma VM dentro do mesmo Cloud Service. Com o Availability Set, as VMs serão colocadas em locais onde uma falha de Rack não irá impactar mais o Cloud Service como um todo, mas sim apenas as VMs que estão no Rack com falha. Veja na ilustração abaixo:

Na imagem acima, você pode verificar que as VMs que rodam IIS foram colocadas no “Availability Set 01″, por isso nunca estarão no mesmo Rack. As VMs que rodam SQL estão em outro Availability Set seguindo a mesma premissa. Para configurar isso dentro do Azure, basta selecionar a opção abaixo, veja:

Depois de criar o Availability Set, basta colocar as VMs que não deveriam estar no memso Rack neste Availability Set. Vale lembrar que o Availability Set também coloca as VMs em Upgrade Domains diferentes, garantindo que se o Host tiver algum update e a VM ficar fora do ar por isso, o Cloud Service não será impactado por essa atualização de Host.

Tecnicamente, quando você coloca apenas uma VM dentro de um Cloud Service você tem, por contrato, um SLA de 99,9%. Quando você coloca no mínimo duas VMs no mesmo Cloud Service, e coloca estas VMs no mesmo Availability Set, você tem o SLA de 99,95%.
Para mais informações sobre SLA, você pode acessar este link.

Espero que tenham gostado.
Até mais!

By

Quer cursos de Nuvem Privada Microsoft?

Olá Pessoal,

Muita gente me pergunta sobre cursos de System Center e Nuvem Privada e realmente estes cursos não são tão comuns como cursos de Windows Server e até Hyper-V. Resolvi então (Com a ajuda do Fabio Hara) fazer um apanhado dos cursos de System Center que estão focados em Nuvem Privada no MVA:

Proteção de Dados e Servidores em ambiente de Nuvem Privada – Aqui.

Nuvem privada: alta disponibilidade e recuperação – Aqui.

Gerenciamento de Infraestrutura de Updates para Nuvem Privada – Aqui.

Gerencie dispositivos com o System Center 2012 – Aqui.

Automatize processos com System Center Orchestrator – Aqui.

São boas horas de estudo, então aproveite!
Até mais!

By

Affinity Groups no Microsoft Azure.

Olá pessoal,

Se você já utilizou o Microsoft Azure, sabe que existem diversas regiões onde você pode alocar o recurso que está querendo criar. Por exemplo, para criar uma Máquina Virtual, você pode selecionar em qual datacenter você gostaria de criar esta VM, veja:

O que poucos sabem é que como estes datacenters são gigantescos, mesmo estando dentro do mesmo datacenter, estes recursos criados podem estar relativamente distantes entre sí. Por exemplo, 2 Máquinas Virtuais que precisam “falar” entre si podem ficar distantes e não ter a performance esperada. E esse não é o pior caso. Outro exemplo é a conta de storage que armazena os VHDs das Máquinas Virtuais em um local do datacenter e a execução da VM em outro. Para evitar esse tipo de situação, existem os Affinity Groups.

A ideia do Affinity Group é alocar os recursos que pertencem a este Affinity Group o mais próximo possível dentro de um Datacenter. Isso vale para vários recursos. Para criar um Affinity Group, vá em Settings no portal de gerenciamento do Azure e clique na aba Affinity Groups. Clique em “Add” na parte inferior:

Quando você for criar os recursos, ao invés de selecionar a região, você poderá selecionar o Affinity Group. Pensando em Máquinas Virtuais, existem 2 recursos que fazem muito sentido colocar em um Affinity Group. O primeiro é a conta de Storage. No momento de criação da conta de storage, ao invés de selecionar a região, selecione o Affinity Group, veja:

Outro recurso que é interessante colocar neste Affinity Group é a Virtual Network. Isso por que quando você for criar uma Máquina Virtual, ao invés de selecionar a região ou até mesmo Affinity Group, você colocará a Virtual Network que esta VM deverá estar, garantindo assim que esta Virtual Network esteja no Affinity Group. Veja:

Veja que quando você for criar a Máquina Virtual, você deverá indicar a Virtual Network:

Repare também que na imagem acima, a conta de storage também está no mesmo Affinity Group que a Virtual Network, garantindo assim que todos os recursos estarão o mais próximos possível um do outro.

Espero que tenham gostado da dica.
Até mais!

By

PPT sobre DevOps utilizado no #MSTechDay!

Olá Pessoal,

Não sei se todos sabem mas vocês podem baixar a maioria dos PPTs que eu utilizo (Sério, todos os que uso estão no SlideShare, mas como quase não uso PPT nas minhas apresentações por questões filosóficas, vocês verão que são poucos mesmo. Mas estão todos lá) diretamente do SlideShare.

O último PPT que utilizei foi em conjunto com o chefe Danilo Bordini e o André Dias da BRSoluções, sobre DevOps:

Espero que gostem!
Até mais!