Este é o primeiro tópico do módulo “Describe Core Azure Services (15-20%)”.
Para encontrar todos outros posts para estudo da certificação Azure AZ-900 acesse:
Azure AZ-900: Microsoft Azure Fundamentals
Describe Core Azure Services (15-20%)
Describe the core Azure architectural components
- describe the benefits and usage of Regions and Region Pairs
fonte:
https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions
https://docs.microsoft.com/en-us/azure/availability-zones/az-overview
https://docs.microsoft.com/en-us/azure/virtual-machines/regions
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/regions-availability-zones
Region é um conjunto de datacenters interligados entre si num perímetro de até 300 milhas – quando possível – e que utilizam rede de baixa latência. Então podemos dizer que Region são datacenters em algum lugar, como mostra o mapa acima. Perceba que no Brazil South temos uma região do tipo “Availability Zone” (AV), falo sobre isso na sequência. Mesmo que uma Region não seja do tipo AV ela ainda pode ter mais que um datacenter no mesmo local.
Region Pairs consiste em duas ou mais Regions dentro da mesma geografia (EUA com EUA, Europa com Europa). Dessa forma Azure garante que problemas como incêndios, guerras, desastres naturais, não afetem o serviço como um todo, uma vez que a Região pode assumir os serviços da outra.
Atualizações no ambiente do Azure são feitas em uma Region de cada vez, de forma a não gerar outage do serviço.
Alguns serviços da Azure replicam dados automaticamente usando Region Pairs pra garantir alta disponibilidade desses dados, como é o caso do Azure Geo-redundant Storage (GRS)
Importante: nem todos serviços replicam dados automaticamente, nem todos serviços se recuperam automaticamente usando seus pares. Nesses casos o cliente deve configurar a replicação e recuperação ele mesmo.
Os benefícios para uso de Region Pairs são
– physical isolation; quando possível os datacenters estarão no mínimo a 300 milhas uns dos outros. Essa separação física previne ou diminui a chance de problemas como falta de energia, guerras, desastres naturais, etc.
– platform-provided replication; alguns serviços fazem replicação automática entre regiões pares, como o exemplo do GRS.
– region recovery order; no caso de algum problema generalizado de outage a recuperação de uma região de cada par é priorizada. Aplicações que fazem uso dessas regiões tem garantido que pelo menos uma das regiões será recuperada com high priority. Aplicações que não fazem uso de regiões pares podem acabar tendo sua região como a última recuperada e gerar um outage maior.
– sequencial updates; atualizações planejadas do Azure são feitas em cada região de uma vez, pra diminuir o tempo de downtime, ou efeito de bugs ou falhas lógicas no caso de um update ruim.
– data residency; os dados ficam resididos na mesma geografia para atender propósitos jurídicos e de impostos.
Lista de Region Pairs: https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions#azure-regional-pairs
- describe the benefits and usage of Availability Zones
fonte:
https://docs.microsoft.com/en-us/azure/availability-zones/az-overview
https://docs.microsoft.com/en-us/azure/availability-zones/az-region
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/regions-availability-zones
Entendemos que uma Region é composta de vários datacenters e podem ter datacenters pareados entre Regions, que eles chamam de Region Pairs. Sabemos também que esses datacenters podem estar interligados em rede de baixa latência e afastados entre si para evitar que problemas afetem mais de um datacenter ao mesmo tempo.
Availability Zones (AZs) são locações físicas únicas dentro de uma Region, portanto dentro de uma Region podemos ter várias AZs. Cada AZ é composta por um ou mais datacenters com independência de energia, rede, resfriamento, e estão separadas fisicamente entre si para prevenir problemas de desastre naturais e outros tipos de catástrofes que possam gerar outage dos serviços como um todo.
Todas AZs são arquitetadas pensando em ser resilientes a problemas num nível de Region, de forma que tenhamos serviços com high availability. Nas Regions que tem AZs habilitadas existe sempre um mínimo de 3 AZs. Quando existe algum problema dentro de uma Region as AZs são trazidas de volta uma a uma. As manutenções críticas também são realizadas uma zone por vez dentro de cada Region.
Zone-redundant services; esse tipo de serviço replica seus dados e aplicações entre AZs dentro de uma mesma Region.
Uma AZ em um Region é um domínio de falha e de atualização, de forma que, se por exemplo, você tem 3 ou mais VMs espalhadas por 3 AZs, então suas VMs estão efetivamente distribuídas por 3 diferentes domínios de falha e de atualização. O Azure reconhece essa distribuição por 3 AZs diferentes e garante que essas VMs não sejam atualizadas ao mesmo tempo (pra não gerar indisponibilidade).
Para garantir durability e high availability construa seus serviços utilizando diferentes AZs em Region Pairs. Você pode replicar de forma síncrona seus aplicativos e dados usando AZs em uma Region para alta disponibilidade e replicar de forma assíncrona entre Regions para proteção de recuperação de desastre.
Os serviços do Azure que oferecem suporte a AZs se enquadram em três categorias:
– Zonal services; aqui o recurso do Azure é definido a uma AZ específica. Se for preciso você pode replicar seus dados e serviços para uma ou mais AZs dentro da mesma Region.
– Zone-redundant services; os serviços desse tipo são automaticamente replicados entre diferentes AZs
– Non-regional services; Os serviços estão sempre disponíveis nas geografias do Azure e são resilientes a interrupções em toda a zona e também em toda a Region.
- describe the benefits and usage of Resource Groups
fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/overview
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview
A estrutura de organização do Azure tem quatro níveis, conforme podem ser visto na imagem acima: Management groups, Subscriptions, Resource groups, Resources. Cada uma delas é descrita em detalhes nos tópicos a seguir.
Nesse tópico vamos falar de Resource Groups, que são containers lógicos onde agrupamos Resources, com objetivo de organizar o gerenciamento desses recursos. Você decide quais recursos pertencem a um Resource GRoups com base no que faz mais sentido para sua organização.
Resources são tudo o que você cria com uma Subscription do Azure, como VMs, instâncias do Gateway, e instâncias do Azure Cosmos DB. Todos os Resources devem estar em um Resource Group e um Resource só pode ser membro de um único Resource Group. Muitos Resources podem ser movidos entre Resource Groups, com alguns Resources tendo limitações ou requisitos específicos para mover. Os Resource Groups não podem ser aninhados. Antes que qualquer Resource possa ser provisionado/criado/instanciado, você precisa de um Resource Group para colocá-lo.
Geralmente, adicione Resources que compartilham o mesmo ciclo de vida ao mesmo Resource Group para que você possa implementá-los, atualizá-los e excluí-los facilmente como um grupo.
Se você excluir um Resource Group, todos os Resources contidos nele também serão excluídos. Organizar recursos por ciclo de vida pode ser útil em ambientes de não produção, onde você pode tentar um experimento e depois descartá-lo. Os Resource Groups facilitam a remoção de um conjunto de recursos de uma só vez.
Os Resource Groups também são utilizados para aplicar permissões RBAC (role-based access control). Ao aplicar permissões RBAC a um Resource Group, você pode facilitar a administração e gerenciamento de acesso aos Resources para permitir apenas o que é necessário.
Resource Groups armazenam metadados sobre os Resources. Portanto, ao especificar um local para o Resource Group, você está especificando onde esses metadados serão armazenados. Por motivos de compliance, pode ser necessário que seus metadados sejam armazenados na mesma Region que seus dados ou suas aplicações, mas também é possível que o Resource Group seja criado numa Region diferente das que seus Resources.
Pontos de atenção:
- Todos os Resources em um Resource Group devem compartilhar o mesmo ciclo de vida. Você os implanta, atualiza e exclui juntos. Se um recurso, como um servidor, precisa existir em um ciclo de implantação diferente, ele deve estar em um Resource Group diferente.
- Cada Resource só pode pertencer a um único Resource Group.
- Você pode adicionar, mover ou remover recursos de um Resource Group a qualquer momento.
- Se a Region do Resource Group estiver indisponível, você não poderá atualizar os recursos desse Resource Group porque os metadados estarão indisponíveis. Os recursos em outras Regions ainda funcionarão normalmente, mas você não poderá atualizá-los.
- Através do Resource Group você pode aplicar controle administrativo a todos recursos do grupo, através de Azure Policies, Azure Roles ou Resource Locks.
- Você pode aplicar tags a Resource Groups, mas os recursos não herdam automaticamente essas tags.
- Um recurso pode se conectar a recursos em outros Resource Groups. Este cenário é comum quando os dois recursos estão relacionados, mas não compartilham o mesmo ciclo de vida.
- Você pode implantar até 800 instâncias de um tipo de recurso em cada Resource Group.
- Existem alguns Resources específicos que podem existir fora de Resource Groups.
- describe the benefits and usage of Subscriptions
fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/management-groups-subscriptions
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/subscriptions/
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions
Azure Subscription (ou assinatura), como podemos ver na imagem acima, é uma unidade lógica de serviços do Azure que se vincula a uma conta do Azure, que é uma identidade no Azure Active Directory (Azure AD) ou em um diretório em que o Azure AD confia.
Uma Azure Subscription fornece acesso autenticado e autorizado aos produtos e serviços do Azure. Também permite provisionar recursos.
Uma conta pode ter uma ou várias Subscriptions com diferentes modelos de faturamento e às quais você aplica diferentes políticas de gerenciamento de acesso. Existem dois tipos de limites de assinatura que você pode usar:
Billing Boundary; Este tipo de assinatura determina como uma conta do Azure é cobrada pelo uso do Azure. Você pode criar várias subscriptions para diferentes tipos de requisitos de faturamento. O Azure gera relatórios de cobrança e faturas separados para cada subscription para que você possa organizar e gerenciar os custos.
Access control boundary; O Azure aplica políticas de gerenciamento de acesso no nível de subscription e você pode criar subscription separadas para refletir diferentes estruturas organizacionais. Um exemplo é que, em uma empresa, você tem departamentos diferentes aos quais aplica políticas de subscriptions distintas do Azure. Este modelo de cobrança permite que você gerencie e controle o acesso aos recursos que os usuários provisionam com assinaturas específicas.
Além desses limites descritos acima, você pode criar subscriptions adicionais com o simples propósito de organização do seu faturamento. Por exemplo, você pode criar assinaturas adicionais pra separar seu faturamento por:
Ambiente; você pode criar uma subscription diferente pra cada ambiente, de teste, produção ou algum outro ambiente necessário. Dessa forma os acessos aos recursos já ficam controlados num nível de assinatura.
Estrutura Organizacional; também pode criar assinaturas pra cada departamento, assim fica mais fácil controlar qual departamento tem acesso a quais recursos. Por exemplo, você pode criar uma assinatura pra TI onde esse time terá acesso a todos os recursos disponíveis, enquanto em outra assinatura um time de contabilidade tem acesso apenas a recursos mais simples.
Tipo de Faturamento; seus custos na Azure são agrupados primeiro num nível de assinatura, portanto pode ser interessante criar assinaturas pra controlar e acompanhar suas faturas na Azure. Por exemplo, você pode criar uma assinatura pra ambiente de Prod e outra pra ambiente de Dev, dessa forma fica fácil compara quanto está custando cada um desses ambientes apenas olhando o faturamento de cada uma dessas duas assinaturas.
Existem alguns limites nas assinaturas, por exemplo, o número máximo de Azure ExpressRoute circuits por assinatura é de 10, portanto ao planejar suas assinaturas, levem esses limites em consideração.
Subscriptions, ou assinaturas, podem ser organizadas em “invoice sections”. Cada invoice section é uma linha na invoice (nota fiscal) que mostra quanto foi gasto mensalmente, ou seja, você pode pegar uma ou duas ou três assinaturas e colocar tudo na mesma invoice section, que daí na invoice vai aparecer como uma linha agregada.
Você também pode criar perfis diferentes para faturamento, ou seja, pode criar um “billing profile” que contém um conjunto de invoices section e subscriptions pro setor de compras e outro billing profile com outras invoices e assinaturas pro setor de vendas.
- describe the benefits and usage of Management Groups
fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/management-groups-subscriptions
https://docs.microsoft.com/en-us/azure/governance/management-groups/overview
https://docs.microsoft.com/en-us/azure/governance/management-groups/
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/govern/resource-consistency/resource-access-management#what-is-azure-resource-manager
Se você tem várias subscriptions e quer organizar tudo de uma forma melhor utilize os Management Groups (vou abreviar para MG). Através os Management Groups você pode definir nível de acesso, políticas (policies) e compliances para as subscriptions pertencentes aos Management Groups.
Assim como Resource Groups são containers de Resources, Management Groups são containers de Subscriptions.
Todas as assinaturas dentro de um MG herdam automaticamente as condições aplicadas nesse MG. Os MG fornecem gerenciamento de nível empresarial em grande escala, não importa o tipo de assinatura que você possa ter. Todas as assinaturas em um único MG devem confiar no mesmo tenant do Azure AD.
Por exemplo, com MG você pode aplicar políticas que não permitam a criação de VMs em regions que você não queira. Essa política seria então aplicada a tudo que estiver embaixo desse MG, sendo: outros MG, subscriptions, e resources. Essa política aplicada a nível de MG não pode ser alterada a nível de subscription ou recurso, o que facilita a governança da sua estrutura.
Você também pode dar acesso a todas subscriptions que estiverem dentro do seu MG, ou seja, se seu MG tem várias assinaturas você pode facilmente dar acesso a todas elas de uma só vez. Você pode criar uma atribuição role-based access control (RBAC) no MG, que aplicará esse acesso a todas as assinaturas. Uma atribuição no MG pode permitir que os usuários tenham acesso a tudo o que precisam, em vez de criar scripts RBAC em assinaturas diferentes.
Pontos importantes:
- 10 mil management groups podem existir em cada diretório
- Uma árvore de Management Group pode ter até 6 níveis de profundidade. Esse limite não inclui o root nem o nível de assinatura (ou seja, 6 Management Group um embaixo do outro, além do root).
- Cada Management Group e Assinatura só suporta 1 parente
- Cada Management Group pode ter vários filhos
- Todos Management Groups e Assinaturas ficam dentro de uma única hierarquia dentro do mesmo diretório
- describe the benefits and usage of Azure Resource Manager
fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/resources-resource-manager
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview
Azure Resource Manager (abrevia ARM, ou Gerenciador de Recursos em português), como o nome já diz, é uma camada de orquestração dos recursos na Azure. É através dele que você cria, atualiza, e deleta seus recursos na Azure, e também gerencia coisas como controle acesso, travas e tags pra organizar e deixar mais seguro seus recursos depois de serem deploiados.
A imagem acima mostra como a camada do Resource Manager trata requisições.
Quando uma requisição é feita para um serviço da Azure é o Resource Manager recebe essa requisição e faz sua autenticação, e depois transmite essa requisição para os serviços da Azure (os recursos). Como todas requests são tratadas pela mesma API (Resource Manager), você vê resultados e recursos consistentes em todas as diferentes ferramentas.
Todos os recursos que estão disponíveis no portal do Azure também estão disponíveis por meio do PowerShell, CLI do Azure, REST APIs e client SDKs. A funcionalidade inicialmente lançada por meio de APIs será representada no portal em 180 dias após o lançamento inicial.
Reforçando os níveis de escopo do Azure
No Azure existem 4 nívels de escopo: Management Groups, Subscriptions, Resource Groups, Resources.
Isso significa que, permissões, políticas, regras, travas, e demais configurações de gerenciamento podem ser aplicadas a cada um desses níveis, sendo que os níveis mais baixos herdam dos níveis mais altos.
Existem também outra coisa chamada de “template”, que são arquivos JSON que definem uma série de comportamentos e que podem ser aplicados nos seguintes níveis: tenants, management groups, subscriptions, ou resource groups. Acredito que templates não devem cair na prova, mas aqui vai o link sobre o assunto: https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview
Benefícios do uso do Azure Resource Manager (ARM)
- Através do ARM você pode gerenciar seu ambiente através de templates e não apenas de scripts.
- ARM permite você gerenciar e monitorar todos seus recursos como um grupo, ao invés de fazer isso individualmente recurso por recurso.
- Redeploy da sua solução ao longo do ciclo de vida de desenvolvimento e garante que seus recursos serão deployados em um estado consistente.
- Defina as dependências entre os recursos para que sejam deployados na ordem correta.
- Aplica controle de acesso em todos serviços através do RBAC que é nativo no ARM.
- Aplica tags nos recursos pra organizá-los de forma lógica dentro da sua subscription.
- Aumenta a clareza na hora do faturamento porque os custos dos recursos pode ser visto de acordo com o agrupamento de recursos que compartilham a mesma tag.
- explain Azure resources
fonte:
https://docs.microsoft.com/en-us/learn/modules/azure-architecture-fundamentals/resources-resource-manager
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/govern/resource-consistency/resource-access-management
Resources (recursos em pt-br) são qualquer coisa que você cria numa Azure Subscription, como VMs, Gateways de Aplicação, instâncias do Cosmos DB, etc. Todos recursos precisam estar dentro de um Resource Group, e cada recurso só pode estar em apenas um Resource Group por vez. Muitos recursos podem ser movidos entre Resource Groups, com alguns deles tendo algumas limitações específicas pra realizar esse movimento. Antes de qualquer recurso ser criado (provisionado é a palavra certa) você precisa ter um Resource Group pra colocar ele dentro.
Na Azure o termo RESOURCE se refere a uma entidade gerenciada pela Azure, como por exemplo as VMs, Virtual Networks, Storage Accounts, etc, tudo isso são chamados de Resource (ou recursos) na Azure.
Referências
https://www.udemy.com/course/introducao-ao-microsoft-azure-certificacao-az-900/
Pedro Carvalho 