Entender a arquitetura do Azure e uma tarefa essencial para o exame AZ-900. O Azure se divide em infraestrutura fisica (onde estao os servidores) e estrutura logica (como os recursos sao agrupados e gerenciados). As analogias da rede logistica nacional e do sistema de arquivamento empresarial tornam tudo claro de uma vez.
A estrutura completa de um vistazo
Toda a infraestrutura do Azure se divide em duas dimensoes.
A dimensao fisica aborda "onde no mundo estao os servidores do Azure". Data centers, regioes, zonas de disponibilidade e pares de regioes pertencem aqui.
A dimensao logica aborda "como os recursos do Azure sao agrupados e gerenciados". Recursos, grupos de recursos, assinaturas e grupos de gerenciamento pertencem aqui.
Infraestrutura fisica — A analogia da rede logistica nacional
Imagine uma grande empresa de entrega que opera centros logisticos em multiplas cidades do pais. Centros independentes operam em Sao Paulo, Rio de Janeiro, Brasilia e Salvador. Se o centro de uma cidade tem um problema, os outros continuam funcionando normalmente. As regioes do Azure sao exatamente esses centros logisticos.
Data Centers
Tudo no Azure comeca com data centers fisicos. Um data center e um edificio cheio de servidores reais, equipamentos de rede e armazenamento. O Azure opera centenas de data centers em todo o mundo. Cada data center tem fornecimentos de energia independentes, sistemas de refrigeracao e conexoes de rede. Por seguranca, o publico nao pode visita-los e as localizacoes exatas nao sao divulgadas.
Regioes (Regions)
Uma regiao e uma colecao de multiplos data centers localizados na mesma area geografica. O Azure opera mais de 60 regioes em todo o mundo, mais do que qualquer outro provedor de nuvem.
Lista de regioes de exemplo
| Area | Nome da regiao | |------|--------------| | Coreia do Sul | Korea Central (Seoul), Korea South (Busan) | | Estados Unidos | East US (Virginia), West US (California), Central US (Iowa) | | Europa | North Europe (Irlanda), West Europe (Paises Baixos) | | Asia | East Asia (Hong Kong), Southeast Asia (Singapura) | | Japao | Japan East (Toquio), Japan West (Osaka) |
O que considerar ao escolher uma regiao
Latencia: Escolher a regiao mais proxima dos usuarios finais acelera os tempos de resposta. Para um servico voltado para usuarios coreanos, Korea Central e a melhor escolha. Soberania de dados: Algumas leis nacionais exigem que certos tipos de dados sejam armazenados apenas dentro do pais. Por exemplo, o GDPR da UE pode exigir que os dados de cidadaos europeus permaneçam na Europa. Disponibilidade de servicos: Nem todos os servicos do Azure estao disponiveis em todas as regioes. Ao usar um servico especifico, voce deve escolher uma regiao que o suporte. Custo: Os precos podem diferir por regiao. East US costuma ser um dos mais economicos. Conformidade: Certos setores (financas, saude) podem ter regulamentacoes que exigem o uso de data centers em locais especificos.
Zonas de disponibilidade (Availability Zones)
Agora pense em um centro logistico (regiao) que opera varios edificios independentes. O Edificio A, B e C tem fiacao, refrigeracao e conexoes de internet independentes. Se o Edificio A pegar fogo, os Edificios B e C continuam operando. Isso e uma Zona de disponibilidade.
Uma Zona de disponibilidade e um data center fisicamente separado dentro de uma unica regiao. Cada zona tem seu proprio fornecimento de energia independente, sistema de refrigeracao e rede, de modo que uma zona caindo completamente nao afeta as outras. Uma regiao normalmente tem tres zonas de disponibilidade.
Como usar as Zonas de disponibilidade
Servicos com redundancia de zona: O Azure replica automaticamente dados ou aplicacoes entre varias zonas. O Azure Storage ZRS (Zone-Redundant Storage) e o exemplo principal. Servicos zonais: Voce coloca recursos diretamente em uma zona especifica. Colocar uma VM em cada uma das zonas 1, 2 e 3, por exemplo, garante que o servico continue mesmo se uma zona cair.
Pares de regioes (Region Pairs)
Pense em centros logisticos gemeos. O centro de Sao Paulo e o centro do Rio de Janeiro estao oficialmente emparelhados. Se um desastre em grande escala (terremoto, inundacao) atingir Sao Paulo, o centro do Rio assume automaticamente o servico. Ambos os centros monitoram constantemente o status um do outro. Isso e um par de regioes.
Principais pares de regioes
| Regiao 1 | Regiao 2 | |---------|---------| | Korea Central (Seoul) | Korea South (Busan) | | East US | West US | | North Europe | West Europe | | East Asia | Southeast Asia | | Japan East | Japan West |
Caracteristicas importantes dos pares de regioes
As duas regioes estao pelo menos 300 km de distancia dentro da mesma area geografica (mesmo pais ou paises adjacentes). Um desastre em grande escala aciona failover automatico de uma regiao para a outra. Quando o Azure lanca atualizacoes de plataforma, nunca atualiza ambas as regioes de um par ao mesmo tempo. Atualiza uma primeiro e so atualiza a outra se a primeira for bem-sucedida. Isso evita interrupcoes totais de servico durante as atualizacoes. A replicacao de dados permanece dentro do mesmo pais ou paises adjacentes, respeitando as regulamentacoes de soberania de dados.
Zonas de disponibilidade vs. Pares de regioes
| | Zonas de disponibilidade | Pares de regioes | |--|------------------------|----------------| | Escopo | Dentro da mesma regiao | Regioes diferentes (centenas de km) | | Distancia | Alguns km | Pelo menos 300 km | | Protege contra | Falha de um unico data center | Desastres afetando uma regiao inteira | | Contagem tipica | 3 por regiao | 1 par por regiao | | Status ativo | Ambas as zonas ativas simultaneamente | Uma em espera, ativa em caso de falha |
Regioes soberanas (Sovereign Regions)
Sao regioes de proposito especial fisicamente e logicamente isoladas das regioes comerciais padrao do Azure. Existem para atender a requisitos governamentais ou regulatorios especificos.
Azure Government: Reservado exclusivamente para agencias governamentais federais, estaduais e locais dos EUA e seus parceiros. Acessivel apenas de dentro dos Estados Unidos; completamente inacessivel com uma conta padrao do Azure. Cumpre os padroes de seguranca FedRAMP e DoD do governo dos EUA. Azure China: Um ambiente isolado que opera completamente dentro da China, conforme exigido pela lei chinesa. Operado pela 21Vianet, nao pela Microsoft.
No exame, sempre que "um ambiente Azure especial para as agencias governamentais de um pais especifico" for mencionado, uma regiao soberana e a resposta.
Estrutura logica — A analogia do sistema de arquivamento empresarial
Se a infraestrutura fisica e "onde estao os servidores do Azure", a estrutura logica e "como os recursos do Azure sao gerenciados". A forma como uma empresa organiza seu sistema de arquivamento de documentos facilita entender.
Um Recurso e uma folha de papel. Uma VM, um banco de dados, uma rede — cada um e um recurso.
Um Grupo de recursos e uma pasta de arquivo. Documentos relacionados vao em uma pasta. Por exemplo, uma pasta "projeto web" contem a VM do servidor web, o banco de dados e o balanceador de carga.
Uma Assinatura e uma gaveta de arquivo. Uma gaveta gera uma fatura. Usar gavetas diferentes por departamento separa os custos departamentais.
Um Grupo de gerenciamento e o arquivo completo. Multiplas gavetas (assinaturas) sao agrupadas em um arquivo e a mesma politica de seguranca e aplicada a todas ao mesmo tempo.
!A hierarquia de recursos do Azure
Hierarquia completa
Grupos de recursos (Resource Groups)
Um grupo de recursos e um conteiner que agrupa recursos do Azure relacionados como uma unica unidade de gerenciamento. Todo recurso do Azure deve pertencer a exatamente um grupo de recursos.
Caracteristicas importantes dos grupos de recursos
Cada recurso do Azure pode pertencer a exatamente um grupo de recursos; nao pode estar em dois grupos ao mesmo tempo. Excluir um grupo de recursos exclui todos os recursos dentro dele. Este e um recurso poderoso, mas usa-lo incorretamente pode causar perda de dados. O grupo de recursos em si nao incorre em custos. Apenas os recursos dentro dele geram cobranças. Recursos em um grupo de recursos podem se comunicar livremente com recursos em outro grupo de recursos. Recursos podem ser movidos para um grupo de recursos diferente (embora alguns tipos de recursos tenham restricoes de movimentacao). Tags podem ser aplicadas a grupos de recursos para rastrear custos ou categorizar recursos.
Padroes comuns de organizacao de grupos de recursos
Por projeto: "ProjetoA-Dev", "ProjetoA-Prod" Por ambiente: "Dev-GrupoRecursos", "Test-GrupoRecursos", "Prod-GrupoRecursos" Por departamento: "Marketing-GrupoRecursos", "Engenharia-GrupoRecursos" Por ciclo de vida: Agrupar recursos que serao excluidos juntos ao mesmo tempo
Assinaturas (Subscriptions)
Uma assinatura e a unidade contratual e de cobranca para usar os servicos do Azure. Todo recurso do Azure deve pertencer a exatamente uma assinatura. As assinaturas tambem servem como limites de controle de acesso.
Papeis principais de uma assinatura
Limite de cobranca: Uma fatura separada e gerada para cada assinatura. Separar assinaturas por departamento oferece visibilidade precisa dos custos de nuvem de cada departamento. Limite de controle de acesso: O Azure RBAC (Controle de Acesso Baseado em Funcoes) pode ser aplicado no nivel da assinatura. Equipes que devem ser isoladas umas das outras usam assinaturas separadas. Limites de recursos: Cada assinatura tem limites de criacao de recursos. Por exemplo, uma assinatura tem por padrao um maximo de 20.000 VMs. Se um limite for atingido, voce pode criar uma nova assinatura ou solicitar um aumento.