Como funciona o Azure – O Fabric

Olá pessoal, tudo certin?

Como devem ter percebido, ainda não estou conseguindo escrever aqui no blog na mesma frequência que escrevia antes.

Há alguns dias, comecei a falar sobre os “internals” do Windows Azure – a solução PaaS da Microsoft para Cloud Computing.

No post anterior, falei um bocado sobre como o Azure utiliza os computadores dos data centers da Microsoft da melhor forma possível. Indiquei que a tecnologia desenvolvida para isso chama-se “extraoficialmente” de Windows Azure Hypervisor.

Hoje quero falar sobre como o Windows Azure combina o poder computacional desses computadores para produzir soluções de alto desempenho. O nome dessa solução é Windows Azure Fabric (ou apenas Fabric, para os íntimos)

O que é o Windows Azure Fabric?

Comecemos explicando o que o Windows Azure Fabric não é!

O termo Fabric (tecido, malha) tem sido usado com muita frequência pela Microsoft para designar soluções que envolvem alguma integração entre componentes. O mais famoso uso, na minha opinião, para o termo é o Windows Azure AppFabric. É importante que você saiba que não é sobre ele que quero falar hoje.

O Windows Azure Fabric é um componente de software que roda em todos os computadores que formam o “grid” do Windows Azure. Sua responsabilidade é manter os diversos computadores que formam a rede integrados e se comunicando da forma necessária para o cumprimento de seus objetivos.

Como assim, integrar máquinas?!

Como arquiteto de software, considero uma das atividades mais importantes do desenvolvimento de qualquer serviço web (um website, no caso mais simples), a organização das máquinas que pretendemos utilizar.

Para dar um exemplo muito simples, consideremos um pequeno website de e-commerce.

Um bom arquiteto começaria desenhando em um quadro branco um retângulo para cada computador necessário. Seguramente, teríamos:

• Uma caixa representando o computador que proverá a interface web (páginas);
• Outra para representar o computador que proverá os serviços (regras de negócio);
• Outra para representar o computador que realizará a persistência de dados;

Desenhadas as “caixinhas” dos computadores, compete ao arquiteto desenhar setas (ligações) entre essas caixinhas (computadores). Essas setas indicam o sentido de comunicação e o que será comunicado. Além disso, provavelmente, o arquiteto indicará o(s) protocolo(s) e/ou estratégia de comunicação que será adotada.

Repare que este é um exemplo simples. Entretanto, já aqui encontramos um desafio em converter esse “modelo do serviço” em uma estrutura física hardware.

Inspirados pelo conceito de máquinas virtuais, podemos pensar em um server “pancada” como host de nossas três máquinas, mas mesmo assim… a coisa não é simples. O que fazer se uma máquina cair, ou precisar entrar em manutenção? Como serão operacionalizados os processos de backup e restauração?

Agora considere o pesadelo (no bom sentido) do website simples prosperar. Seguramente as máquinas alocadas não serão suficientes. É provável que a máquina que serve “páginas” não “segure o rojão”… talvez seja interessante pensar em uma máquina mais forte para o trabalho… talvez seja importante pensar em adicionar mais uma máquina para “ajudar” (obviamente, um bom arquiteto sempre modela seu servidor de páginas web como stateless para poder escalar…).. mas aí surge um “Load Balancer” … e a coisa complica… e complica … e complica!

Qual é a função do Windows Azure Fabric

O Windows Azure Fabric se propõe a acabar com o pesadelo de converter o “modelo de serviço” pensado pelo arquiteto (o chato) em uma estrutura física de verdade (pesadelo dos profissionais de infra).

Na prática, o que o Fabric faz é interpretar um “service model” representado, obviamente fora de um quadro branco, em um arquivo e montar as máquinas virtuais correspondentes. Além disso, garantir que todas as máquinas permaneçam operantes.

O arquiteto especifica quais são as:

• Roles (tipo de máquina, webs ou workers)
• Seus tamanhos (volume de memória, número de processadores dedicados), necessários para cada role;
• Quantas instâncias (máquinas virtuais de um determinado tipo) deverão ser criados para cada Role (tipo de máquina virtual).

Para que isso ocorra, há um componente de software muito especial: o Fabric Controller

The Fabric Controller

Embora o Fabric rode em todas as máquinas que formam o Azure, o trabalho mais pesado acaba sendo feito por um núcleo formado por um pequeno conjunto de máquinas conhecido como The Fabric Controller.

O Fabric Controller é, frequentemente, chamado de “o cérebro” do Windows Azure. Isso ocorre por uma boa razão: ele controla a operação de todas as outras máquinas, bem como os serviços que estão rodando nelas.

O Fabric Controller é responsável pelas seguintes tarefas:

• O Fabric Controlller “possui” todo o hardware do data center. Isso compreende desde máquinas normais até load balancers, switches, etc. O Fabric Controler sabe o estado de cada um deles e consegue detectar eventuais falhas.
• O Fabric Controller toma todas as decisões de provisionamento. O Fabric Controler possuí um inventário dinâmico de computadores (um computador é adicionado ao Fabric, o Fabric Controller reconhece e gerencia);
• O Fabric Controller mantem a saúde de todos os serviços. Ele monitora os serviços e tenta adotar ações corretivas sempre que detecta uma falha. Ele também lida com atualizações e mudanças de configuração para os serviços.

O Fabric Controller não pode cair (!?)

Como você pode imaginar, uma falha no fabric controller é ruim para a saúde de todo o sistema. Por isso, é suportado por conjuntos de cinco a sete computadores, cada um deles com uma replica. Todas as replicas compartilham estado através deum um sistema de replicação baseado em no algoritmo Paxos.

A máquina primária é sempre a responsável por executar todas as tarefas chave. Quaisquer modificações no estado da máquina primária é “replicada” pra todos os nodos no cluster do Fabric Controller. Se a máquina primária cair, uma nova máquina primária é selecionada de um dos outros nodos.

Perceba, entretanto, que o Fabric Controller garante que os computadores da Fabric continuem funcionando bem. Entretanto, note que mesmo que todas as réplicas caiam, todos os serviços vão continuar funcionando até que o fabric controller consiga ser restaurado.

O estado nessas replicas é muito importante, visto que contem o conhecimento do todos os serviços que estão rodando. Para impedir ou se recuperar uma perda, o estado de cada replica é verificado regularmente. Isso ajuda a prevenir erros de programa ou de operadores.

É o Fabric Controller que considera os Domínios de Atualização e Falta… Mas esse já é assunto para outro post..

Por hoje, era isso.