Este é o segundo artigo da nova série que iniciei aqui no site: “Insights sobre Azure”. No primeiro artigo tratei sobre a possibilidade de customização de ambientes PHP baseados em Web Apps substituindo arquivos .htaccess por web.config. Você pode visualizar o conteúdo ao qual me refiro seguindo o link abaixo.
Artigo: https://fabriciosanchez.com.br//insight-personalizando-ambiente-de-host-php-no-azure-web-app/
No post de hoje quero falar um pouco sobre a importância de se implementar adequadamente dois recursos bem importantes (até mesmo críticos para alguns casos) em projetos de nuvem: os availability sets e os affinity groups.
Quando se fala em nuvem, todos são unânimes em concordar que uma das principais vantagens (senão a principal vantagem) disponibilizada por esses ambientes é a alta disponibilidade. E isso é um fato. Plataformas sérias de computação em nuvem devem ser capazes de prover alta disponibilidade de recursos para seus clientes. No Microsoft Azure esse número chega a 99,9% de uptime. Mas ok, isso você já deve estar cansado de ouvir. O que talvez você não saiba ou que talvez ninguém tenha lhe dito, é que essa “alta disponibilidade” não é automática, que ela depende de algumas implementações realizadas por quem está configurando os ambientes. É neste ponto que se destacam os Availability Sets (AS).
É claro que quando estamos falando de PaaS (Web Apps, SQL Azure Databases, Web Roles, etc.) temos a implementação de alta disponibilidade simplificada em larga escala pelo Azure, bastando para isso a alocação de duas ou mais instâncias para que determinado recurso esteja disponível 99,9% do tempo. A coisa muda um pouco de figura quando precisamos criar ambientes altamente disponíveis de forma manual utilizando máquinas virtuais ou containers, por exemplo. Mas antes de entrarmos no mérito de como configurar os availability sets, precisamos entender ainda que de forma generalista, o modelo de gestão de disponibilidade do Azure para máquinas virtuais: Fault Domain & Update Domain.
Azure Fault Domain (FD) & Update Domain (UD)
Como o próprio nome sugere, Fault Domain refere-se ao contexto de “medidas” que o Azure deverá adotar para caso haja alguma falha relacionada a determinada máquina virtual em um mesmo availability set, enquanto Update Domain refere-se ao conjunto de medidas que o Azure deverá tomar caso máquinas virtuais de um mesmo availability set precisem ser atualizadas.
Quando criamos um availability set e após isso adicionamos máquinas virtuais a ele, estamos “ordenando” ao Azure que adicione essas instâncias de servidores em racks distintos no mesmo datacenter. Por esse motivo, os deployments de aplicações precisam ser necessariamente ser realizados individualmente em cada instância. Para conseguir ser mais assertivo no detalhamento deste modelo, peço que considere a Figura 1.
Figura 1. Modelo operacional de instâncias por Fault e Update Domain
Quando uma máquina é adicionada a um Availability Set ela recebe dois ID’s únicos para carregar consigo: um FD e um UD. Evidentemente que o FD refere-se a marcação de Fault Domain e o UD a de Update Domain. São esses ID’s que permitirão ao Azure identificar um dada instância de máquina virtual no contexto de múltiplas em um mesmo AS. O mesmo ocorre com o UD. Por padrão um AS trabalha suas máquinas virtuais ao longo de três Fault Domains (no exemplo, FD0, FD1 e FD2). Isso quer dizer que o deploy das máquinas virtuais do AS serão distribuídos ao longo destes três FD’s (você também pode ler o FD como rack).
Cada FD compartilha apenas dois recursos: fonte de energia e switch de rede. As máquinas físicas do rack são completamente isoladas e são resolvidas na mesma rede local. Se um AS agrupa máquinas virtuais clássicas, ele estará limitado a 5 ID’s únicos de FD + UD. Caso mais máquinas virtuais sejam adicionadas neste mesmo AS, a partir da sexta os ID’s serão repetidos nas máquinas entrantes e a ordem será: VM 6 <- FD + UD (VM 1), VM 7 <- FD + UD (VM 2), e assim sucessivamente. Se o AS agrupar máquinas ARM, ele terá capacidade de assinar de maneira unitária até 20 máquinas. Se houver necessidade de mais máquinas o processo de repetição será o mesmo informado há pouco.
Availability Set na prática
Entender o modelo de trabalho baseado em Fault Domain e Update Domain é de suma importância, uma vez que fundamenta de forma efetiva a utilização de dos AS em projetos reais. Desta forma, se você quer garantir que um web farm de máquinas virtuais (por exemplo) ou ainda, que um pool de máquinas virtuais dedicadas para banco de dados esteja sempre disponível, o conselho é: configure de maneira adequada o availability set para as máquinas que fazem parte do cluster.
Isso posto, podemos partir para o modelo de implementação de AS em um caso real. Vou criar um web farm Windows para hospedar uma aplicação desenvolvida em ASP.NET. Neste farm implementaremos um AS. O web farm terá duas máquinas virtuais A3 que estarão na mesma máquina virtual. Vamos a implementação.
Observação 1: como tudo no Azure você pode criar os recursos de três maneiras. 1) Portal web (antigo ou novo); 2) Powershell; 3) Azure CLI; Para facilitar a ilustração do processo em imagens, farei as implementações baseadas no portal web. Mas sinta-se a vontade para seguir de outra maneira.
Observação 2: se você optar pelo portal antigo do Azure (http://manage.windowsazure.com), conseguirá criar apenas recursos do modelo ASM (ou classic). Para criar recursos ARM você deverá utilizar o portal novo (http://portal.azure.com).
Passo 1: Crie um novo Resource Group
Já logado no portal do Azure, navegue até a opção “Resource Groups” e forneça as informações solicitadas. Ao final do processo, sua janela deverá estar parecida com aquela apresentada pela Figura 2.
Figura 2. Criando um novo Resource Group
O alerta em vermelho a frente do nome do Resource Group está sendo exibido pelo fato de este resource group já ter sido criado anteriormente. Ao colocar seu próprio nome o mesmo não deverá aparecer pra você :-).
Passo 2: Crie um nova virtual network
Navegue agora até a opção “Virtual Network” e forneça as informações solicitadas. Não irei entrar nos detalhes das informações solicitadas por não ser o foco deste artigo. Sua tela preenchida deverá estar semelhante aquela apresentada pela Figura 3.
Figura 3. Configuração básica de uma rede virtual no Azure
Como estamos criando um farm de máquinas virtuais, é interessante que estas máquinas estejam na mesma rede virtual para que o acesso aos recursos possam ser realizados localmente. Outro aspecto importante a ser notado é o apontamento desta rede virtual para que ele fique dentro do resource group que criamos no passo anterior.
Passo 3: Crie um novo Availability Set
Como terceiro passo, navegue até a opção “Availability Set” no portal do Azure. Vamos finalmente criar o recurso do qual estamos falando até aqui e assim, entender sua implementação na prática.
Vale lembrar que estamos criando aqui um availability set para arquitetura ARM.
Vamos ao detalhamento das informações solicitadas:
- Name: este é o nome que identificará seu Availability Set. Atente para as regras de nomeação (o portal o ajudará neste quesito). Para nosso exemplo, estou chamando este availability set de “Post_AS_AG”.
- Fault Domain: a próxima informação solicitada é a quantidade de recursos de fault domain. Lembram quando falei que a quantidade máxima de fault domains para o Azure era 3? Note que o Azure já traz esse número selecionado, entretanto, se achar conveniente, você poderá diminuir esta quantidade. Para o exemplo, manterei o número padrão, 3.
- Update Domain: como já mencionamos anteriormente neste artigo, para a arquitetura ARM, temos a opção de utilizar até 20 update domains unitários, diferentemente do que o modelo ASM, que possibilita apenas 5. Vou selecionar o número 10.
- Subscription: selecione a assinatura sob a qual o recurso será criado.
- Resource Group: selecione o grupo de recursos que criamos no primeiro passo deste texto.
- Location: selecione o datacenter sob o qual o availability set será disponibilizado. É importante por questões de performance, baixa latência, etc., que os recursos seja criados todos sob o mesmo datacenter. Para este exemplo, estou padronizando tudo no “East US 2”.
Após preencher todas as informações, clique em “Create”. Se tudo correu bem, você deverá ter seu availability set rapidamente criado e disponível, tal qual apresenta a Figura 4.
Figura 4. Availability Set criado
Pronto. Agora já possuímos os assets necessários para que possamos subir as máquinas virtuais do farm de modo que elas se tornem altamente disponíveis.
Passo 4: Crie uma nova máquina virtual
Como quarto passo, navegue até a opção máquinas virtuais no portal do Azure e crie uma duas máquinas virtuais ARM (sem ser a clássica). As minhas máquinas de exemplo chamei de “Flynn01” e “Flynn02”, mas você deve nomear conforme sua vontade/necessidade. Não irei cobrir aqui o processo de criação de máquinas virtuais, entretanto, você pode visualizar um bom tutorial seguindo o link abaixo.
Antes de partir para o tutorial entretanto, tenha em mente que, durante o processo de criação das VM’s você precisará realizar três apontamentos:
- O resource group que criamos no primeiro passo deste artigo.
- A rede virtual que criamos no segundo passo.
- E por fim, o Availability Set que criamos no passo anterior.
Criando uma nova máquina virtual através do portal do Azure: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-hero-tutorial/
A Figura 4 a seguir apresenta as duas máquinas virtuais recém criadas e que serão os assets de nosso farm.
Figura 5. Máquinas virtuais de exemplo disponíveis
Pronto, máquinas altamente disponíveis dentro do farm. Novas máquinas continuarão sendo distribuídas entre os 3 fault domains e os 10 update domains que configuramos. Fácil, né?
Affinity Group
Para entender de maneira plena a importância dos affinity groups (agora Regions), é fundamental entender, ainda que a 10 mil pés, como funcionam os datacenters do Azure.
Um datacenter do Azure é formado por milhares de containers. Cada container possuir milhares de racks que são interligados, formando um modelo de cluster. Os serviços do Azure (armazenamento, computação, CDN, cache, etc.) são distribuídos em containers específicos. Por exemplo, o container 00001 agrupa apenas serviços de armazenamento, enquanto o container 00002 agrupa apenas serviços de compute, e assim por diante.
Adicione a esta equação o fato de que são 22 datacenters espalhados ao redor do mundo. O que isso quer dizer? Quer dizer que é muito fácil criarmos recursos no Azure sem atentar para o fato de que os mesmos precisam estar no mesmo datacenter, mesma rede virtual, etc. Como você pode imaginar, esse “descuido” pode gerar coisas ruins para o ambiente, como lentidão, cobranças desnecessárias (recursos em diferentes datacenters, por exemplo), etc.
Affinity Groups são os elementos que “dizem” ao Azure Fabric Controller (o sistema interno do Azure responsável por fazer a alocação e gestão de todos os recursos da plataforma) que, recursos marcados pelo mesmo affinity group deverão ser criados e “deployados” juntos. Bacana, não é?
Affinity Groups na prática
Affinity Group é um recurso disponível apenas para assets clássicos (ASM) e portanto, até o momento em que este artigo foi escrito, somente podia ser criado/gerenciado no portal antigo do Azure. Dessa forma, para que possamos demonstrar seu funcionamento, iremos alternar a visualização para este ambiente. Se preferir você pode acessar o portal antigo diretamente pela url: http://manage.windowsazure.com.
Uma vez no portal do Azure, no menu principal (lado esquerdo), clique na opção “Settings”. Na tela que se abre, clique na guia “Affinity Groups”. O resultado final pode ser visualizado na Figura 6.
Figura 6. Área de criação de Affinity Groups
Como próximo passo, clique em “Add an Affinity Group”. Uma janela modal solicitando algumas informações será exibida. Informe o nome do Affinity Group (para este exemplo estou chamando “affinitygrouppost”), a descrição (que é opcional) e ainda, o datacenter (no meu caso, selecionei East US) onde o Affinity Group será criado. A Figura 7 apresenta o Affinity Group recém criado.
Figura 7. Affinity Group criado
Pronto. Agora, durante a criação de suas máquinas virtuais, contas de armazenamento, etc. (todas clássicas, é importante reforçar), para apontar o Affinity Group recém criado para que você garanta que os recursos serão entregues juntos pelo Azure.
Era isso. Forte abraço!
Facebook
Twitter
Instagram
LinkedIn
RSS