Nos últimos meses tenho trabalhado em uma ampla gama de projetos de migração de AWS para Azure. Existe uma dúvida por parte dos clientes que, em quase 100% dos casos chega até mim no momento de uma apresentação ou desenho de arquitetura: me refiro ao conceito de regiões. A dúvida é pertinente (claro, isso afeta diretamente o modelo de alta disponibilidade oferecido pela plataforma de cloud) e também se justifica pela diferença estrutural que existe entre AWS e Azure quando o assunto é réplica e comunicação entre datacenters.
Se esta dúvida é recorrente, pensei que faria total sentido escrever um post explicando em maior riqueza de detalhes o “como” o Azure implementa o modelo de comunicação entre regiões e ainda, discutir um pouco as vantagens deste padrão arquitetural. É claro, tendo este conceito clarificado, ficará fácil para aquele profissional acostumado com o modelo de regiões implementado pela AWS entender as diferenças estruturais entre as plataformas de nuvem e claro, auxiliará grandemente no processo de elaboração de uma nova arquitetura, certo?
Introdução
O primeiro aspecto importante a salientar aqui: tanto Azure quanto AWS implementam mecanismos eficientes para prover alta disponibilidade de seus Datacenters (DCs). Existem mecanismos que são implementados dentro dos DCs (o que chamamos de redundância local) e existem mecanismos que são implementados entre DCs (o que chamamos de redundância geográfica). Enquanto a primeira abordagem visa garantir a alta disponibilidade dos serviços dentro de um DC específico, o segundo visa garantir a alta disponibilidade de uma estrutura de DC como um todo.
Quando falamos em redundância local, Azure e AWS diferem conceitualmente e nominalmente no modelo de trabalho. Enquanto AWS implementa um mecanismo de diferentes regiões (note o uso da palavra “regiões”) dentro de um mesmo DC, o Azure trabalha com o conceito de Availability Set (implementando Fault Domain e Update Domain). Já escrevi sobre esses dois tópicos em um mesmo post aqui no site há algum tempo atrás. O conteúdo continua super atual e, se você não sabe exatamente do que estamos falando aqui, recomendo fortemente a leitura do mesmo antes de seguir com a leitura deste post.
Post sobre Availability Set:
https://fabriciosanchez.com.br//insight-a-importancia-do-availability-set-e-do-affinity-group-em-um-projeto-no-azure/
Como você deve saber, tanto Azure quanto AWS possuem DCs espalhados pelo mundo. O Azure entrega hoje (em 06/01/2017) para o mercado 30 DCs (e esse número deve crescer ainda mais). Sozinha a Microsoft oferece mais poder computacional que Google e AWS juntos. Este modelo de DCs distribuídos obriga as fornecedoras de nuvem a terem esquemas muito bem definidos e eficientes de redundância entre os mesmos, haja vista a possibilidade (ainda que remota) de desastres naturais ou de algum outro tipo fazer com que estes caiam. Dessa forma, com esse post, quero discutir um pouco a estratégia da Microsoft para garantir que seus DCs estejam sempre Up e Running mesmo que um DC inteiro saia do ar por um infortúnio ou outro.
Azure Region Pairs (Regiões em Pares do Azure)
Na estratégia de redundância de DCs do Microsoft Azure, uma “Região” refere-se a uma região física mesmo do globo. Por exemplo, “Brazil South” ou “East US”, respectivamente, regiões “Sul do Brasil” e “Leste dos Estados Unidos”. Essas regiões (e todas as demais suportadas pelo Azure) podem possuir um DCs e cada área geográfica pode possuir n regiões (como é o caso de “East US 2”, por exemplo). Cada DC possui então milhares de servidores físicos (aproximadamente 600 k, mas isso pode variar de acordo com o tamanho do DC) que são virtualizados e transformam-se em milhões de outros servidores virtuais, que implementam todos os serviços do Azure.
Cada região do Azure está posicionada de maneira estratégica. Existem estudos pesados que analisam tráfego, população, latência de internet, potencial de mercado, leis, etc, para que seja possível à Microsoft definir as regiões onde seus DCs serão hospedados e ainda, se você reparar bem, vai perceber que todas as regiões estão posicionadas nas mesmas áreas geográficas. Por exemplo, os Estados Unidos (um dos países escolhidos para receber um DC do Azure) possuem 4 regiões, já Japão possui 2 regiões, etc. Se a Microsoft for criar um novo DC na Ásia, por exemplo, provavelmente teremos uma terceira região no Japão ou mesmo um segundo DC em uma região já existente no Japão. A menos que os estudos apontem a necessidade de se criar algo na Malásia, por exemplo. Ficou claro? A Microsoft segue essa lógica por razões óbvias. Dentre elas podemos citar:
- O fato de que estudos anteriores já provaram a viabilidade de daquela região;
- O fato de que colocar DCs em regiões próximas torna mais fácil a interligação entre eles;
- O fato de que colocar DCs em regiões próximas pode significar considerável redução de latência;
- Dentre outras.
Mas e sobre o conceito de pares? Como isso implica necessariamente em redundância?
Agora que temos o conceito de regiões, DCs e áreas geográficas clarificados, temos a possibilidade de entender plenamente o conceito de pares entre regiões. Para facilitar o entendimento, considere a Figura 1 a seguir.
Figura 1. O conceito de regiões em pares no Azure
Imaginando que, por alguma razão complemente imprevisível (como um desastre natural, por exemplo) e como consequência dela, um de seus Datacenters possa vir a ficar inoperante, a Microsoft tratou de tomar suas providências para garantir que seus clientes não sejam afetados de maneira letal quando tais intemperes ocorrerem e dessa forma, pensou e implementou em uma arquitetura de regiões em pares.
“Azure Region Pairs” é, como o próprio nome sugere, a implementação de redundância entre Datacenters posicionados em duas regiões diferentes (de preferência em uma mesma geografia), com afinidade recursos, mas claro, respeitando certas políticas de segurança (por exemplo: uma região deve obrigatoriamente estar a no mínimo ~ 485 KM de distância de outra).
Importante notar que o conceito de pareamento de regiões vai além do que simplesmente um conceito. Significa que elas (regiões) estão fisicamente ligadas. Esta informação é importante porque diz algo realmente efetivo sobre a possibilidade de comunicação direta (e portanto, eficiente) entre os DCs. Outra informação importante é: colocar regiões em pares também garante que, todos os recursos criados na “região A” podem ser movidos com segurança para a “região B” em caso de necessidade. Interessante, não? A Tabela 1 a seguir apresenta a paridade das regiões no Azure (esta informação pode mudar no futuro com a adição de novas regiões).
Tabela 1. Listagem de DCs em pares do Azure
Como é possível observar, na primeira coluna temos a área geográfica da região (por exemplo, “Brazil”), na segunda temos a região primária do DC e na terceira, sua respectiva região par. Outra conclusão interessante aqui é: com excessão do Brasil, todas as áreas geográficas possuem ao menos duas regiões e claro, por razões óbvias, essas regiões de mesmo território geográfico são pareadas entre si (por exemplo, “Canada Central” <-> “Canada East”). O Brasil, como possui apenas uma região, faz pareamento com “South Central US”. Isso poderá mudar no futuro caso uma nova região seja criada em nosso país.
Uma recomendação importante em termos de boas práticas de arquitetura é posicionar recursos que precisam ser geo-localizados, em regiões pareadas. Seguindo esta prática, você terá réplicas perfeitas up e running em duas regiões distintas. O próprio portal do Azure dá dicas a esse respeito. Já tentou, por exemplo, criar uma storage account com geo-replicação? Se você reparar, o portal já trará selecionado como opção de datacenter para replicação, o respectivo “par” do primário. Interessante não?!
Sobre benefícios
Já mencionamos anteriormente alguns dos benefícios desse modelo de pareamento implementado pelo Azure, entretanto, existem outros que valem a menção.
Agrupamento de dados. Com certeza você já ouviu falar que certos tipos de dados precisam, necessariamente, estar armazenados dentro dos limites do país de origem. Determinações deste tipo são realizadas pela legislação dos países. Com o conceito de pareamento, como as regiões estão em sua grande maioria ligadas em um mesmo país, você pode ter um modelo de replicação de dados mais eficiente sem precisar enviar esses dados para uma região geográfica diferente, fato que deixaria aquela aplicação irregular perante a legislação de seu país.
Eficiência e isolamento em rotinas de atualização. De maneira análoga a qualquer outra plataforma que depende de software e hardware, de tempos em tempos, a Microsoft atualiza os DCs do Azure com recursos mais atuais, visando sempre garantir a maior eficiência dos serviços oferecidos. O processo de atualização dos DCs também respeita este modelo de pareamento sob a seguinte perspectiva: nunca dois DCs que são pares sofrerão atualizações simultâneas. Será sempre um, e depois, caso o processo no primeiro tenha sido bem sucedido, o segundo também o será. Isso garante, dentre outras coisas, que os dados e demais recursos geo-replicados, estarão sempre disponíveis.
Recuperação em caso de desastre generalizado. Sim, isso provavelmente não irá ocorrer (i.e., falha generalizada de DCs do Azure) mas, caso ocorra, felizmente há um modelo bem definido de recovery de regiões que também respeita o pareamento. Em um pareamento, uma região sempre terá prioridade para ser recuperada, dessa forma, os recursos geo-replicados rapidamente estarão no ar novamente, pois existirá uma alta prioridade para fazer com que isso possa ocorrer. Os recursos da outra região par, serão restabelecidos de acordo com a sua prioridade.
Redução de custos com banda. Um dos maiores custos das plataformas de nuvem está no tráfego de dados entre regiões, certo? Na verdade, depende! Se os dados são trocados entre regiões não pareadas, de fato você terá a cobrança de “in” e “out”. Agora, se os dados são trocados entre regiões pareadas, este custo não existirá (o que é consideravelmente importante, não?).
Por hoje é isso. Espero que este post possa o ajudar a entender melhor a estratégia de alta disponibilidade entre datacenters do Azure e, com essa informação, possa ter mais insumos para planejar melhor a arquitetura de sua aplicação na nuvem da Microsoft.
Este post expande os conceitos apresentados neste post:
https://buildazure.com/2017/01/06/azure-region-pairs-explained/
Até a próxima!
Facebook
Twitter
Instagram
LinkedIn
RSS