O datacenter virtual: uma perspectiva de rede

Artigo
07/11/2023

Os aplicativos migrados do local podem se beneficiar da infraestrutura econômica segura do Azure, mesmo com alterações mínimas de aplicativo. As empresas podem querer adaptar suas arquiteturas para melhorar a agilidade e aproveitar os recursos do Azure.

O Microsoft Azure oferece serviços e infraestrutura de hiperescala com recursos e confiabilidade de nível empresarial. Esses serviços e a infraestrutura oferecem muitas opções de conectividade híbrida, o que permite aos clientes acessá-los pela Internet ou por uma conexão de rede privada. Os parceiros da Microsoft também fornecem recursos avançados com a oferta de serviços de segurança e soluções de virtualização otimizados para execução no Azure.

Os clientes podem usar o Azure para estender diretamente sua infraestrutura para a nuvem e criar arquiteturas de várias camadas.

O que é um datacenter virtual?

A nuvem começou como uma plataforma para hospedar aplicativos voltados para o público. As empresas reconheceram o valor da nuvem e começaram a migrar aplicativos internos de linha de negócios. Esses aplicativos trouxeram mais segurança, confiabilidade, desempenho e considerações de custo que exigiam maior flexibilidade na entrega dos serviços de nuvem. Novos serviços de rede e de infraestrutura foram projetados para dar flexibilidade. Os novos recursos oferecem escala elástica, recuperação de desastre e outras considerações.

As soluções de nuvem foram inicialmente projetadas para hospedar aplicativos individuais e relativamente isolados no espectro público, o que funcionou bem por alguns anos. Conforme os benefícios das soluções de nuvem foram ficando evidentes, as cargas de trabalho em grande escala passaram a ser hospedadas na nuvem. Abordar a segurança, a confiabilidade, o desempenho e as preocupações com custo é vital para a implantação e o ciclo de vida do seu serviço de nuvem.

No exemplo de diagrama de implantação de nuvem abaixo, a caixa vermelha realça uma lacuna de segurança. A caixa amarela mostra uma oportunidade para otimizar soluções de virtualização de rede entre cargas de trabalho.

Diagram that shows a cloud deployment and networking virtual datacenter.

Os datacenters virtuais ajudam a alcançar a escala necessária para cargas de trabalho corporativas. A escala precisa abordar os desafios apresentados na execução de aplicativos em larga escala na nuvem pública.

Uma implementação de datacenter virtual inclui mais do que as cargas de trabalho do aplicativo na nuvem. Ela também fornece serviços de rede, segurança, gerenciamento, DNS e Active Directory. À medida que as empresas migram mais cargas de trabalho para o Azure, considere a infraestrutura e os objetos que dão suporte a essas cargas de trabalho. O bom gerenciamento de recursos ajuda a evitar o aumento de "ilhas de carga de trabalho" gerenciadas separadamente, com fluxos de dados, modelos de segurança e desafios de conformidade independentes.

O conceito de datacenter virtual fornece recomendações e designs gerais para implementar uma coleção de entidades separadas, mas relacionadas. Essas entidades geralmente têm funções de suporte, recursos e infraestrutura em comum. Exibir as cargas de trabalho como datacenter virtual ajuda a perceber os custos reduzidos com economias de escala. Ele também ajuda com segurança otimizada por meio da centralização de componentes e fluxo de dados e operações, gerenciamento e auditorias de conformidade mais fáceis.

Observação

Um datacenter virtual não é um serviço específico do Azure. Vários recursos do Azure são combinados para atender às suas necessidades. Um datacenter virtual é uma maneira de pensar sobre suas cargas de trabalho e o uso do Azure para otimizar os recursos e as funcionalidades na nuvem. Ele fornece uma abordagem modular de prestação de serviços de TI no Azure que, ao mesmo tempo, respeita as funções organizacionais e as responsabilidades da empresa.

Um datacenter virtual ajuda as empresas a implantar cargas de trabalho e aplicativos no Azure para os seguintes cenários:

Hospedagem de várias cargas de trabalho relacionadas.
Migração de cargas de trabalho de um ambiente local para o Azure.
Implementação de segurança compartilhada ou centralizada e requisitos de acesso entre cargas de trabalho.
Mistura de TI centralizada e DevOps apropriadamente para uma grande empresa.

Quem deve implementar um datacenter virtual?

Qualquer cliente que decida adotar o Azure pode se beneficiar da eficiência de configurar um conjunto de recursos para uso comum por todos os aplicativos. Dependendo do tamanho, até mesmo aplicativos únicos podem se beneficiar do uso de padrões e componentes empregados para criar uma implementação de VDC.

Algumas organizações têm equipes ou departamentos centralizados para TI, rede, segurança ou conformidade. A implementação de um VDC pode ajudar a impor pontos de política, a separar responsabilidades e a garantir a consistência dos componentes básicos subjacentes. As equipes de aplicativos podem manter a liberdade e o controle adequados aos seus requisitos.

As organizações com uma abordagem de DevOps também podem usar conceitos de VDC para fornecer bolsões autorizados de recursos do Azure. Esse método garante que os grupos de DevOps tenham controle total dentro desse agrupamento, seja no nível de assinatura, seja em grupos de recursos em uma assinatura comum. Ao mesmo tempo, os limites de rede e segurança permanecem em conformidade. A conformidade é definida por uma política centralizada na rede do hub e no grupo de recursos gerenciado de maneira centralizada.

Considerações sobre a implementação de um datacenter virtual

Ao criar um datacenter virtual, considere estes problemas essenciais:

Serviço de identidade e diretório

Os serviços de identidade e diretório são os principais recursos de datacenters locais e na nuvem. A identidade aborda todos os aspectos de autorização e acesso a serviços em uma implementação de VDC. Para garantir que apenas usuários e processos autorizados acessem os recursos do Azure, o Azure usa vários tipos de credenciais para autenticação, incluindo senhas de conta, chaves criptográficas, assinaturas digitais e certificados. A autenticação multifator do Microsoft Entra fornece uma camada extra de segurança para acessar os serviços do Azure. Uma autenticação forte com várias opções de verificação fáceis (chamada telefônica, mensagem de texto ou notificação de aplicativo móvel) permite que os clientes escolham o método que preferirem.

As grandes empresas precisam definir processos de gerenciamento de identidades que descrevam o gerenciamento de identidades individuais, a autenticação, a autorização, as funções e os privilégios no VDC. Os objetivos deste processo podem aumentar a segurança e a produtividade e diminuir o custo, o tempo de inatividade e as tarefas manuais repetitivas.

As empresas e organizações podem exigir um conjunto exigente de serviços para diferentes linhas de negócios. Os funcionários geralmente têm diferentes funções quando envolvidos em projetos distintos. O VDC requer uma boa cooperação entre diferentes equipes, cada uma com definições de função específicas, para que os sistemas sejam executados com boa governança. A matriz de responsabilidades, acesso e direitos pode ser complexa. O gerenciamento de identidades no VDC é implementado por meio da ID do Microsoft Entra e do controle de acesso baseado em função do Azure (RBAC do Azure).

Um serviço de diretório é uma infraestrutura de informações compartilhadas que localiza, gerencia, administra e organiza itens cotidianos e recursos de rede. Esses recursos podem incluir volumes, pastas, arquivos, impressoras, usuários, grupos, dispositivos e outros objetos. Cada recurso na rede é considerado um objeto pelo servidor de diretório. Informações sobre um recurso são armazenadas como uma coleção de atributos associados a tal recurso ou objeto.

Todos os serviços empresariais online da Microsoft dependem do Microsoft Entra ID para início de sessão e outras necessidades de identidade. O Microsoft Entra ID é uma solução de nuvem de gerenciamento de identidade e acesso abrangente e altamente disponível que combina serviços de diretório principais, governança avançada de identidade e gerenciamento de acesso a aplicativos. O Microsoft Entra ID pode se integrar ao Active Directory local para habilitar o logon único para todos os aplicativos locais hospedados localmente e baseados em nuvem. Os atributos de usuário do Active Directory local podem ser sincronizados automaticamente com o Microsoft Entra ID.

Não é necessário haver um único administrador global para atribuir todas as permissões na implementação de um VDC. Cada departamento, grupo de usuários ou serviço específico no Serviço de Diretório pode ter as permissões necessárias para gerenciar seus próprios recursos em uma implementação de VDC. Estruturar permissões requer balanceamento. Um número excessivo de permissões pode prejudicar a eficiência de desempenho, enquanto permissões de menos ou não exigentes podem aumentar os riscos de segurança. O RBAC (controle de acesso baseado em função) do Azure ajuda a resolver esse problema oferecendo gerenciamento de acesso refinado para recursos em uma implementação de VDC.

Infraestrutura de segurança

A infraestrutura de segurança diz respeito à segregação de tráfego em um segmento de rede virtual específico da implementação de VDC. Essa infraestrutura especifica como a entrada e a saída são controladas em uma implementação de VDC. O Azure baseia-se em uma arquitetura multilocatário que impede o tráfego não autorizado e não intencional entre as implantações. Isso é feito ao usar isolamento de rede virtual, listas de controle de acesso, políticas de fluxo de tráfego, filtros IP e balanceadores de carga. NAT (conversão de endereços de rede) separa o tráfego de rede interno do tráfego externo.

A malha do Azure aloca recursos de infraestrutura a cargas de trabalho de locatário e gerencia comunicações para e de VMs (máquinas virtuais). O hipervisor do Azure impõe a separação de memória e processo entre VMs e encaminha com segurança o tráfego de rede a locatários do sistema operacional convidado.

Conectividade com a nuvem

Um datacenter virtual exige conectividade com redes externas para oferecer serviços a clientes, parceiros ou usuários internos. Essa necessidade de conectividade diz respeito não só à Internet, mas também a datacenters e redes locais.

Os clientes controlam os serviços que podem acessar a Internet pública e ser acessados por ela. Esse acesso é controlado pelo Firewall do Azure ou por outros tipos de NVAs (dispositivos de rede virtual), as políticas de roteamento personalizadas, por rotas definidas pelo usuário e a filtragem de rede, pelos grupos de segurança de rede. Recomendamos que todos os recursos voltados para a Internet sejam protegidos pela Proteção contra DDoS do Azure.

As empresas podem precisar conectar seu datacenter virtual aos datacenters locais ou a outros recursos. Essa conectividade entre o Azure e as redes locais é um aspecto essencial de um projeto de arquitetura eficaz. As empresas têm duas maneiras diferentes de criar essa interconexão: trânsito pela Internet ou por conexões diretas privadas.

Uma VPN site a site do Azure conecta redes locais ao datacenter virtual no Azure. O link é estabelecido por meio de conexões criptografadas seguras (túneis IPsec). As conexões VPN site a site do Azure são flexíveis, rápidas de criar e, normalmente, não exigem mais aquisição de hardware. Com base nos protocolos padrão do setor, a maioria dos dispositivos de rede atuais pode criar conexões VPN com o Azure pela Internet ou por caminhos de conectividade existentes.

O ExpressRoute permite conexões privadas entre o datacenter virtual e uma rede local. As conexões do ExpressRoute não passam pela Internet pública e oferecem maior segurança, confiabilidade e velocidades mais altas (até 100 Gbps), além de latência consistente. O ExpressRoute fornece os benefícios das regras de conformidade associadas a conexões privadas. Com o ExpressRoute Direct, você pode se conectar diretamente aos roteadores da Microsoft a 10 Gbps ou 100 Gbps.

A implantação de conexões do ExpressRoute geralmente envolve a interação com um provedor de serviços do ExpressRoute (o ExpressRoute Direct é a exceção). Para os clientes que precisam iniciar rapidamente, é comum usar inicialmente o VPN site a site para estabelecer uma conectividade entre um datacenter virtual e recursos locais. Quando a interconexão física com o provedor de serviços for concluída, migre a conectividade pela conexão do ExpressRoute.

Para um grande número de conexões VPN ou ExpressRoute, a WAN Virtual do Azure é um serviço de rede que fornece conectividade otimizada e automatizada entre branches por meio do Azure. A WAN Virtual permite que você conecte e configure dispositivos de branch para se comunicar com o Azure. A conexão e a configuração podem ser feitas manualmente ou usando os dispositivos de provedor preferidos por meio de um parceiro de WAN Virtual. O uso dos dispositivos de provedor preferidos facilitam o uso, simplificam a conectividade e permitem o gerenciamento da configuração. O painel interno de WAN do Azure fornece informações instantâneas de solução de problemas que podem ajudar você a economizar tempo e proporcionam uma maneira fácil de exibir conectividade site a site em larga escala. A WAN Virtual também fornece serviços de segurança com um Firewall do Azure e um Gerenciador de Firewall opcionais em seu hub de WAN Virtual.

Conectividade na nuvem

As Redes Virtuais do Azure e o emparelhamento de rede virtual são os componentes básicos de rede em um datacenter virtual. Uma rede virtual garante um limite de isolamento para recursos de datacenter virtual. O emparelhamento permite a intercomunicação entre diferentes redes virtuais na mesma região do Azure, entre regiões e até mesmo entre redes em assinaturas diferentes. Os fluxos de tráfego podem ser controlados dentro das redes virtuais e entre elas por conjuntos de regras de segurança especificados para grupos de segurança de rede, políticas de firewall (Firewall do Azure ou soluções de virtualização de rede) e rotas personalizadas definidas pelo usuário.

As redes virtuais são pontos de ancoragem para a integração de produtos do Azure para PaaS (plataforma como serviço), como o Armazenamento do Microsoft Azure, o SQL do Azure e outros serviços públicos integrados que tenham pontos de extremidade públicos. Com os pontos de extremidade de serviço e o Link Privado do Azure, você pode integrar os serviços públicos à rede privada. Você pode até mesmo colocar seus serviços públicos como privados, mas ainda aproveitar os benefícios dos serviços de PaaS gerenciados pelo Azure.

Visão geral do datacenter virtual

Topologias

Um datacenter virtual pode ser criado com uma dessas topologias de alto nível, com base em suas necessidades e requisitos de escala:

Em uma topologia simples, todos os recursos são implantados em uma única rede virtual. As sub-redes permitem o controle de fluxo e a diferenciação.

Em uma Topologia de malha, o emparelhamento de rede virtual conecta todas as redes virtuais diretamente entre si.

Uma topologia de hub e spoke de emparelhamento é adequada a aplicativos distribuídos e equipes com responsabilidades delegadas.

Uma topologia de WAN Virtual do Azure pode dar suporte a cenários de filiais em larga escala e serviços WAN globais.

A topologia de hub e spoke de emparelhamento e a topologia de WAN Virtual do Azure usam um design de hub e spoke, que é ideal para comunicação, recursos compartilhados e política de segurança centralizada. Os hubs são criados com um hub de emparelhamento de rede virtual (rotulado como Hub Virtual Network no diagrama) ou um hub de WAN Virtual (rotulado como Azure Virtual WAN no diagrama). A WAN Virtual do Azure foi projetada para comunicações de grande escala entre branches e entre branch e Azure para evitar as complexidades de se criar todos os componentes individualmente em um hub de emparelhamento de rede virtual. Em alguns casos, seus requisitos podem exigir um design de hub de emparelhamento de rede virtual, por exemplo, a necessidade de ter dispositivos de rede virtual no hub.

Nas topologias de hub e spoke, o hub é a zona de rede central que controla e inspeciona todo o tráfego entre diferentes zonas, como Internet, local e spokes. A topologia hub e spoke ajuda o departamento de TI a impor as políticas de segurança de forma centralizada. Ela também reduz a possibilidade de erros de configuração e exposição.

O hub costuma conter os componentes de serviço comuns consumidos pelos spokes. Os exemplos a seguir são serviços centrais comuns:

A infraestrutura do Windows Active Directory é necessária para a autenticação de usuários de terceiros que acessam de redes não confiáveis antes de obterem acesso às cargas de trabalho no spoke. Ela inclui os Serviços de Federação do Active Directory (AD FS)
Um serviço de DNS (Sistema de Nomes de Domínio) é usado para resolver nomes para a carga de trabalho nos spokes e para acessar recursos locais e na Internet se o DNS do Azure não for usado
Uma infraestrutura de chave pública (PKI) é usada para implementar logon único em cargas de trabalho
Controle de fluxo de tráfego TCP e UDP entre as zonas da rede de spoke e a Internet
Controle de fluxo entre os spokes e o local
Se necessário, fluxo de controle entre um spoke e outro

Um datacenter virtual reduz o custo geral usando a infraestrutura de hub compartilhada entre vários spokes.

A função de cada spoke pode ser hospedar diferentes tipos de cargas de trabalho. Os spokes também fornecem uma abordagem modular para implantações repetíveis das mesmas cargas de trabalho. Os exemplos incluem desenvolvimento e teste, testes de aceitação do usuário, pré-produção e produção. Os spokes também podem separar e habilitar diferentes grupos na sua organização. Os grupos do DevOps são um bom exemplo do que os spokes podem fazer. Dentro de um spoke, é possível implantar uma carga de trabalho básica ou cargas de trabalho complexas de várias camadas com controle de tráfego entre as camadas.

Limites de assinatura e vários hubs

Importante

Com base no tamanho de suas implantações do Azure, você pode precisar de uma estratégia de vários hubs. Ao projetar sua estratégia de hub e spoke, pergunte-se "Essa escala de design pode usar outra rede virtual de hub nessa região?" e "Essa estrutura pode ser dimensionada para acomodar várias regiões?". É muito melhor planejar um design que possa ser dimensionado, mesmo que não seja necessário, do que falhar em planejar e precisar dele.

O momento de dimensionar para um hub secundário (ou mais) depende de vários fatores, geralmente com base nos limites inerentes da escala. Examine os limites de assinatura, rede virtual e máquina virtual ao projetar para escala.

No Azure, cada componente, seja qual for o tipo, é implantado em uma assinatura do Azure. O isolamento dos componentes do Azure em diferentes assinaturas do Azure pode atender aos requisitos de diferentes linhas de negócios, como configurar níveis diferenciados de acesso e autorização.

Uma única implementação de VDC pode escalar verticalmente um grande número de spokes. Embora, assim como acontece com todos os sistemas de TI, haja limites de plataformas. A implantação do hub está associada a uma assinatura específica do Azure, que tem restrições e limites (por exemplo, um número máximo de emparelhamentos de rede virtua. Para obter detalhes, confira Assinatura e limites de serviço, cotas e restrições do Azure). Em casos em que os limites possam ser um problema, a arquitetura pode ser escalada verticalmente ainda mais estendendo o modelo de um único hub-spokes para um cluster de hub e spokes. Vários hubs em uma ou mais regiões do Azure podem ser conectados por meio de emparelhamento de rede virtual, ExpressRoute, WAN Virtual ou VPN site a site.

A introdução de vários hubs aumenta o esforço de gerenciamento e o custo do sistema. Isso só é justificado pela escalabilidade, pelos limites do sistema, pela redundância e replicação regional para desempenho do usuário ou pela recuperação de desastre. Em cenários que exigem vários hubs, todos os hubs devem buscar oferecer o mesmo conjunto de serviços para facilidade operacional.

Interconexão entre spokes

Dentro de um único spoke, ou um design de rede simples, é possível implementar cargas de trabalho complexas de várias camadas. As configurações de várias camadas podem ser implementadas com sub-redes, sendo uma para cada camada ou aplicativo, na mesma rede virtual. O controle de tráfego e a filtragem são feitos usando grupos de segurança de rede e rotas definidas pelo usuário.

Um arquiteto talvez queira implantar uma carga de trabalho de várias camadas em várias redes virtuais. Com um emparelhamento de redes virtuais, os spokes podem se conectar a outros spokes no mesmo hub ou em hubs diferentes. Um exemplo típico desse cenário é o caso em que os servidores de processamento do aplicativo estão em um spoke ou rede virtual. O banco de dados é implantado em um spoke ou em uma rede virtual diferente. Nesse caso, é fácil interconectar os spokes ao emparelhamento de redes virtuais, o que evita trânsito pelo hub. Faça uma revisão cuidadosa de arquitetura e segurança para garantir que ignorar o hub não ignorará pontos de auditoria ou segurança importantes que possam existir somente no hub.

Os spokes também podem ser interconectados a um spoke que atue como um hub. Essa abordagem cria uma hierarquia de dois níveis. O spoke no nível mais alto (nível 0) torna-se o hub dos spokes inferiores (nível 1) da hierarquia. Os spokes de uma implementação de VDC são necessários para encaminhar o tráfego para o hub central. O tráfego pode transitar para o destino na rede local ou na Internet pública. Uma arquitetura com dois níveis de hubs apresenta roteamento complexo que remove os benefícios de uma relação de hub-spoke simples.

Embora o Azure permita topologias complexas, dois princípios mais importantes do conceito de VDC são a repetição e a simplicidade. Para minimizar o esforço de gerenciamento, o design simples de hub-spoke é a arquitetura de referência do VDC que nós recomendamos.

Componentes

Um datacenter virtual é composto de quatro tipos de componentes básicos: Infraestrutura, Redes de Perímetro, Cargas de Trabalho e Monitoramento.

Cada tipo de componente consiste em vários recursos e funcionalidades do Azure. Sua implementação de VDC é composta por instâncias de vários tipos de componentes e muitas variações do mesmo tipo de componente. Por exemplo, você pode ter muitas instâncias de carga de trabalho diferentes e logicamente separadas que representem diferentes aplicativos. Você usa esses diferentes tipos e instâncias de componentes para criar o VDC.

A arquitetura conceitual de alto nível do VDC anterior mostra diferentes tipos de componente usados em diferentes zonas na topologia hub-spokes. O diagrama mostra os componentes da infraestrutura em várias partes da arquitetura.

Como boa prática em geral, os privilégios e direitos de acesso pode se basear nos grupos. Lidar com grupos em vez de usuários individuais facilita a manutenção das políticas de acesso, oferecendo uma maneira consistente para gerenciá-las entre as equipes, o que ajuda a minimizar erros de configuração. Atribuir e remover usuários de e para grupos apropriados ajuda a manter os privilégios de um usuário específico atualizados.

Cada grupo de função pode ter um prefixo exclusivo em seus nomes. Esse prefixo torna mais fácil identificar a qual carga de trabalho um grupo está associado. Por exemplo, uma carga de trabalho que hospede um serviço de autenticação pode ter grupos chamados AuthServiceNetOps, AuthServiceSecOps, AuthServiceDevOps e AuthServiceInfraOps. Funções centralizadas ou funções não relacionadas a um serviço específico podem ser antecedidas por Corp. Um exemplo é CorpNetOps.

Muitas organizações usam uma variação dos seguintes grupos para fornecer uma divisão importante de funções:

A equipe de TI central Corp tem os direitos de propriedade para controlar os componentes de infraestrutura. Exemplos de rede e segurança. O grupo deve ter a função de colaborador na assinatura, o controle do hub e direitos de colaborador de rede nos spokes. Organizações de grande porte dividem com frequência essas responsabilidades de gerenciamento entre várias equipes. Por exemplo, o grupo CorpNetOps de operações de rede com foco exclusivo na rede e o grupo CorpSecOps de operações de segurança, responsável pela política de firewall e segurança. Nesse caso específico, os dois grupos diferentes precisam ser criados para a atribuição dessas funções personalizadas.
O grupo de desenvolvimento e teste chamado AppDevOps tem a responsabilidade de implantar cargas de trabalho de aplicativos ou serviços. Esse grupo usa a função de colaborador de máquina virtual para implantações de IaaS e/ou uma ou mais funções de colaborador de PaaS. Para obter mais informações, veja Funções internas do Azure. Opcionalmente, a equipe de desenvolvimento e teste pode precisar de visibilidade sobre políticas de segurança (grupos de segurança de rede) e políticas de roteamento (rotas definidas pelo usuário) dentro do hub ou de um spoke específico. Além das funções de colaborador para cargas de trabalho, esse grupo também precisaria da função de leitor de rede.
O grupo de operação e manutenção, chamado CorpInfraOps ou AppInfraOps, tem a responsabilidade de gerenciar cargas de trabalho em produção. Esse grupo deve ser um colaborador de assinatura em cargas de trabalho em qualquer assinatura de produção. Algumas organizações também podem avaliar se elas precisam de um grupo de equipe de suporte de escalonamento com a função de colaborador de assinatura em produção e na assinatura do hub central. O outro grupo corrige possíveis problemas de configuração no ambiente de produção.

O VDC foi criado de modo que os grupos da equipe de TI central que gerenciam o hub tenham os grupos correspondentes no nível da carga de trabalho. Além de gerenciar recursos de hub, a equipe de TI central poderia controlar o acesso externo e permissões de nível superior na assinatura. Os grupos de carga de trabalho também podem controlar recursos e permissões da rede virtual de modo independente na equipe de TI central.

O datacenter virtual é particionado para hospedar vários projetos com segurança em diferentes linhas de negócios. Todos os projetos exigem diferentes ambientes isolados (dev, UAT e produção). Assinaturas separadas do Azure para cada um desses ambientes fornecem isolamento natural.

O diagrama anterior mostra a relação entre os projetos, os usuários, os grupos e os ambientes de uma organização em que os componentes do Azure são implantados.

Normalmente, em TI, um ambiente (ou camada) é um sistema em que vários aplicativos são implantados e executados. Grandes empresas usam um ambiente de desenvolvimento (em que as alterações são feitas e testadas) e um ambiente de produção (que os usuários finais usam). Esses ambientes são separados, geralmente com vários ambientes de preparo entre eles para permitir implantação em fases (distribuição), testes e reversão em caso de problemas. As arquiteturas de implantação variam significativamente, mas geralmente o processo básico de iniciar em desenvolvimento (DEV) e terminar em produção (PROD) ainda é seguido.

Uma arquitetura comum para esses tipos de ambientes de várias camadas inclui ambientes de produção DevOps para desenvolvimento e teste, UAT de preparo e ambientes de produção. As organizações podem usar um ou vários locatários do Microsoft Entra para definir o acesso e os direitos a esses ambientes. O diagrama anterior mostra um caso em que dois locatários diferentes do Microsoft Entra são usados: um para DevOps e UAT, e o outro exclusivamente para produção.

A presença de diferentes locatários do Microsoft Entra impõe a separação entre ambientes. O mesmo grupo de usuários, como a equipe central de TI, precisa se autenticar usando um URI diferente para acessar um locatário diferente do Microsoft Entra. Isso permite que a equipe modifique as funções ou permissões do DevOps ou os ambientes de produção de um projeto. A presença de diferentes autenticações de usuário para acessar diferentes ambientes reduz possíveis interrupções e outros problemas causados por erros humanos.

Tipo de componente: infraestrutura

Esse tipo de componente é o local em que a maioria da infraestrutura de suporte reside. Também é o ponto em que as equipes centralizadas de TI, segurança e conformidade passam a maior parte do tempo.

Os componentes de infraestrutura fornecem uma interconexão para vários componentes de uma implementação de VDC e estão presentes no hub e nos spokes. Normalmente, a responsabilidade por gerenciar e manter os componentes da infraestrutura é atribuída à equipe de segurança ou equipe de TI central.

Uma das principais tarefas da equipe de infraestrutura de TI é assegurar a consistência dos esquemas de endereço IP em toda a empresa. O espaço do endereço IP privado atribuído à implementação de VDC precisa ser consistente e não se sobrepor aos endereços IP privados atribuídos em suas redes locais.

Embora NAT nos roteadores de borda locais ou em ambientes do Azure possa evitar conflitos de endereço IP, ele adiciona complicações aos componentes da sua infraestrutura. Simplicidade de gerenciamento é uma das principais metas do VDC. Embora seja uma solução válida, o uso de NAT para lidar com as preocupações de IP não é uma solução recomendada.

Os componentes da infraestrutura contêm a seguinte funcionalidade:

Serviços de diretório e identidade: o acesso a todos os tipos de recurso no Azure é controlado por uma identidade armazenada em um serviço de diretório. O serviço de diretório armazena não apenas a lista de usuários, mas também os direitos de acesso aos recursos em uma assinatura específica do Azure. Esses serviços podem existir na nuvem ou podem ser sincronizados com identidade local armazenada no Active Directory.
Redes virtuais: as Redes Virtuais são um dos principais componentes do VDC e permitem criar um limite de isolamento do tráfego na plataforma Azure. Uma rede virtual é composta por um ou vários segmentos de rede virtual, cada um com um prefixo de rede IP específico (uma sub-rede, seja IPv4, seja dual stack IPv4/IPv6). A rede virtual define uma área de perímetro interna em que máquinas virtuais de IaaS e serviços de PaaS podem estabelecer uma comunicação privada. As VMs (e serviços PaaS) em uma rede virtual não podem se comunicar diretamente com as VMs (e serviços PaaS) em uma rede virtual diferente. Isso é verdadeiro mesmo que ambas as redes virtuais sejam criadas pelo mesmo cliente, na mesma assinatura. Isolamento é uma propriedade vital que garante que as VMs e as comunicações do cliente permaneçam privadas em uma rede virtual. Quando a conectividade entre redes for desejada, os recursos a seguir descrevem como isso poderá ser feito.
Emparelhamento de rede virtual: o recurso fundamental usado para criar a infraestrutura de um VDC é o emparelhamento de rede virtual, que conecta duas redes virtuais na mesma região. Essa conexão ocorre por meio da rede de datacenter do Azure ou usando o backbone mundial do Azure entre regiões.
Pontos de extremidade de serviço de rede virtual: os pontos de extremidade de serviço estendem o espaço de endereço privado da rede virtual para incluir o espaço de PaaS. Os pontos de extremidade também estendem a identidade de sua rede virtual para os serviços do Azure por meio de uma conexão direta. Os pontos de extremidade permitem proteger os recursos críticos de serviço do Azure somente nas suas redes virtuais.
Link Privado: o Link Privado do Azure te habilita a acessar os serviços de PaaS do Azure (por exemplo, Armazenamento do Azure, Azure Cosmos DB e Banco de Dados SQL do Azure) e serviços de parceiros/clientes hospedados no Azure em um Ponto de Extremidade Privado em sua rede virtual. O tráfego entre a rede virtual e o serviço percorre a rede de backbone da Microsoft, eliminando a exposição da Internet pública. Você também pode criar seu Serviço de Link Privado na rede virtual e fornecê-lo de maneira privada aos clientes. A experiência de configuração e consumo usando o Link Privado do Azure é consistente entre os serviços de parceiro de PaaS do Azure, de propriedade do cliente e de parceiros compartilhados.
Rotas definidas pelo usuário: o tráfego em uma rede virtual é roteado por padrão com base na tabela de roteamento do sistema. Uma rota definida pelo usuário é uma tabela de roteamento personalizada que os administradores de rede podem associar a uma ou mais sub-redes para substituir o comportamento da tabela de roteamento do sistema e definir um caminho de comunicação em uma rede virtual. A presença de rotas definidas pelo usuário garante que o tráfego do spoke transite por VMs personalizadas específicas ou soluções de virtualização e balanceadores de carga presentes no hub e nos spokes.
Grupos de segurança de rede: um grupo de segurança de rede é uma lista de regras de segurança que atuam como filtragem de tráfego em fontes IP, destinos IP, protocolos, portas de origem IP e portas de destino IP (também chamado de tupla de cinco de Camada 4). O grupo de segurança de rede pode ser aplicado a uma sub-rede, a uma NIC virtual associada a uma VM do Azure ou a ambas. Os grupos de segurança de rede são essenciais para implementar um controle de fluxo correto no hub e nos spokes. O nível de segurança proporcionado pelo grupo de segurança de rede é uma função de quais portas você abre e para qual finalidade. Os clientes podem aplicar mais filtros por VM com firewalls baseados em host, como IPtables ou Firewall do Windows.
DNS: o DNS fornece resolução de nomes para recursos em um datacenter virtual. O Azure fornece serviços de DNS para resolução de nomes públicos e privados. As zonas privadas fornecem resolução de nomes em uma rede virtual e em redes virtuais. As zonas privadas podem abranger as redes virtuais na mesma região, e entre regiões e assinaturas. Para resolução pública, o DNS do Azure fornece um serviço de hospedagem para domínios DNS, fornecendo resolução de nomes usando a infraestrutura do Microsoft Azure. Ao hospedar seus domínios no Azure, você pode gerenciar seus registros DNS usando as mesmas credenciais, APIs, ferramentas e cobrança que seus outros serviços do Azure.
Grupo de gerenciamento, assinatura e gerenciamento de grupo de recursos. Uma assinatura define um limite natural para criar vários grupos de recursos no Azure. Essa separação pode ser por função, diferenciação de função ou cobrança. Recursos em uma assinatura são mostrados em conjunto em contêineres lógicos conhecidos como grupos de recursos. O grupo de recursos representa um grupo lógico para organizar os recursos em um datacenter virtual. Se a organização tiver muitas assinaturas, talvez você precise de uma forma de gerenciar o acesso, as políticas e a conformidade com eficiência para essas assinaturas. Os grupos de gerenciamento do Azure fornecem um nível de escopo acima das assinaturas. Você organiza assinaturas em contêineres conhecidos como grupos de gerenciamento e aplica as condições de governança aos grupos de gerenciamento. Todas as assinaturas dentro de um grupo de gerenciamento herdam automaticamente as condições aplicadas ao grupo de gerenciamento. Para ver esses três recursos em uma exibição de hierarquia, confira Organizando seus recursos no Cloud Adoption Framework.
RBAC do Azure (controle de acesso baseado em função do Azure): o RBAC do Azure pode mapear funções e direitos organizacionais para acessar recursos específicos do Azure. Isso permite que você restrinja os usuários a apenas determinado subconjunto de ações. Se você estiver sincronizando a ID do Microsoft Entra com um Active Directory local, poderá usar os mesmos grupos do Active Directory no Azure que você usa localmente. Com o RBAC do Azure, você pode conceder acesso ao atribuir a função apropriada a usuários, grupos e aplicativos no escopo relevante. O escopo de uma atribuição de função pode ser uma assinatura do Azure, um grupo de recursos ou um único recurso. O RBAC do Azure permite a herança de permissões. Uma função atribuída a um escopo pai também concede acesso aos filhos contidos nele. Com o RBAC do Azure, você pode separar as tarefas e conceder aos usuários apenas o nível de acesso de que eles precisam para trabalhar. Por exemplo, um funcionário pode gerenciar máquinas virtuais em uma assinatura e outro pode gerenciar bancos de dados SQL na mesma assinatura.

Tipo de componente: redes de perímetro

Os componentes de uma rede de perímetro (às vezes chamada de rede DMZ) conectam suas redes de datacenters locais ou físicos, juntamente com a conectividade com a Internet, se houver. O perímetro geralmente requer um investimento de tempo significativo de suas equipes de rede e segurança.

Os pacotes de entrada devem podem fluir por dispositivos de segurança no hub antes de alcançar os servidores e serviços de back-end nos spokes. Os exemplos incluem firewall, IDS e IPS. Antes de saírem da rede, pacotes limitados à Internet das cargas de trabalho também podem fluir pelos dispositivos de segurança na rede de perímetro. Esse fluxo permite imposição de políticas, inspeção e auditoria.

Os componentes de rede de perímetro incluem:

Normalmente, as equipes de segurança e a equipe de TI central têm a responsabilidade de definir requisitos e a operação das redes de perímetro.

O diagrama anterior mostra a imposição de dois perímetros com acesso à Internet e uma rede local, ambos residentes no hub DMZ. Em um hub DMZ, a rede de perímetro para a Internet pode ser escalada verticalmente para dar suporte a muitas linhas de negócios, usando vários farms de WAFs (Firewalls de Aplicativo Web) ou Firewall do Azure. O hub também permite a conectividade local via VPN ou ExpressRoute, conforme a necessidade.

Observação

No diagrama anterior, em DMZ Hub, muitos dos recursos a seguir podem ser agrupados em um hub de WAN Virtual do Azure (como redes virtuais, rotas definidas pelo usuário, grupos de segurança de rede, gateways de VPN, gateways do ExpressRoute, Azure Load Balancers, Firewalls do Azure, Gerenciador de Firewall e DDoS). O uso dos hubs de WAN Virtual do Azure pode tornar a criação da rede virtual do hub e do VDC, muito mais fácil, já que a maior parte da complexidade da engenharia é tratada para você pelo Azure na implantação de um hub de WAN Virtual do Azure.

Redes virtuais. O hub normalmente é construído em uma rede virtual com várias sub-redes que hospedam diferentes tipos de serviços. Esses serviços filtram e inspecionam o tráfego da Internet por meio do Firewall do Azure, NVAs, WAF e instâncias do Gateway de Aplicativo do Azure.

Rotas definidas pelo usuário. Usando rotas definidas pelo usuário, os clientes podem implantar firewalls, IDSs /IPSs e outras soluções de virtualização. Eles podem rotear o tráfego de rede por meio dessas soluções de segurança para a aplicação, auditoria e inspeção das políticas de limites de segurança. As rotas definidas pelo usuário podem ser criadas no hub e nos spokes para assegurar que o tráfego passe por VMs personalizadas específicas, Soluções de Virtualização da Rede e balanceadores de carga usados pela implementação de VDC. Para garantir que o tráfego gerado por máquinas virtuais no spoke transite para os dispositivos virtuais corretos, uma rota definida pelo usuário precisa ser definida nas sub-redes do spoke. Isso é feito configurando o endereço IP de front-end do balanceador de carga interno como o próximo salto. O balanceador de carga interno distribui o tráfego interno para as soluções de virtualização (pool de back-end do balanceador de carga).

O Firewall do Azure é um serviço de segurança de rede gerenciado que protege seus recursos da Rede Virtual do Azure. É um firewall gerenciado com estado e alta disponibilidade e escalabilidade de nuvem. É possível criar, impor e registrar centralmente políticas de conectividade de rede e de aplicativo em assinaturas e redes virtuais. O Firewall do Azure usa um endereço IP público estático para seus recursos de rede virtual. Ele permite firewalls externos para identificar o tráfego proveniente da sua rede virtual. O serviço é totalmente integrado ao Azure Monitor para registro em log e análise.

Se você usa a topologia de WAN Virtual do Azure, o Gerenciador de Firewall do Azure é um serviço de gerenciamento de segurança que fornece gerenciamento central de rotas e políticas de segurança para perímetros de segurança baseada em nuvem. Ele funciona com o hub de WAN Virtual do Azure, um recurso gerenciado pela Microsoft que possibilita criar arquiteturas de hub e spoke facilmente. Quando as políticas de segurança e roteamento são associadas a um hub, ele é chamado de hub virtual seguro.

Soluções de virtualização de rede. No hub, a rede de perímetro com acesso à Internet normalmente é gerenciada por meio de uma instância do Firewall do Azure ou de um farm de firewalls ou do firewall de aplicativo Web (WAF).

Linhas de negócios diferentes geralmente usam muitos aplicativos Web, que tendem a sofrer de diversas vulnerabilidades e explorações em potencial. Os firewalls de aplicativos Web são um tipo especial de produto usado para detectar ataques contra aplicativos Web e HTTP/HTTPS mais eficazmente do que um firewall genérico. Em comparação à tecnologia de firewall tradicional, WAFs têm um conjunto de recursos específicos para proteger os servidores Web internos contra ameaças.

Um Firewall do Azure ou firewall NVA usam um plano de administração comum, com um conjunto de regras de segurança para proteger as cargas de trabalho hospedadas nos spokes e controlar o acesso a redes locais. O Firewall do Azure tem escalabilidade integrada, enquanto os firewalls do NVA podem ser dimensionados manualmente por um balanceador de carga. Normalmente, um farm de firewall tem software menos especializado comparado a um WAF, mas tem um escopo de aplicação mais amplo para filtrar e inspecionar qualquer tipo de tráfego de entrada e saída. Se for usada uma abordagem de NVA, ela pode ser localizada e implantada no Azure Marketplace.

É recomendável que você use um conjunto de instâncias do Firewall do Azure ou NVAs para tráfego originado na Internet. Use outro para o tráfego originado localmente. Usar apenas um conjunto de firewalls para ambos é um risco à segurança, uma vez que ele não oferece nenhuma segurança de perímetro entre os dois conjuntos de tráfego de rede. Usar camadas de firewall separadas reduz a complexidade da verificação das regras de segurança, o que deixa claro quais regras correspondem a quais solicitações de rede de entrada.

O Azure Load Balancer oferece um serviço de Camada 4 (TCP, UDP) de alta disponibilidade que pode distribuir o tráfego de entrada entre instâncias de serviço definidas em um conjunto com balanceamento de carga. O tráfego enviado ao balanceador de carga de pontos de extremidade de front-end (pontos de extremidade IP públicos ou pontos de extremidade IP privados) pode ser redistribuído com ou sem conversão de endereços para um conjunto de pools de endereços IP de back-end (por exemplo, soluções de virtualização de rede ou máquinas virtuais).

O Azure Load Balancer pode testar a integridade de várias instâncias de servidor. Quando uma instância não responde a uma investigação, o balanceador de carga interrompe o envio de tráfego para a instância não íntegra. Em um datacenter virtual, um balanceador de carga externo é implantado no hub e nos spokes. No hub, o balanceador de carga é usado para encaminhar com eficiência o tráfego entre instâncias de firewall. Nos spokes, os balanceadores de carga são usados para gerenciar o tráfego do aplicativo.

O AFD (Azure Front Door) inclui a plataforma de aceleração de aplicativos Web altamente disponível e escalável da Microsoft, balanceador de carga HTTP global, proteção de aplicativos e rede de entrega de conteúdo. Em execução em mais de 100 locais na borda da Rede Global da Microsoft, o AFD permite compilar, operar e escalar horizontalmente seu aplicativo Web dinâmico e o conteúdo estático. O AFD oferece a seu aplicativo desempenho do usuário final de alto nível, automação de manutenção de carimbo/regional unificada, automação de BCDR, informações unificadas de cliente/usuário, insights de serviço e caching.

A plataforma oferece:

Desempenho, confiabilidade e suporte a SLAs (contratos de nível de serviço).
Certificações de conformidade.
Práticas de segurança auditáveis que são desenvolvidas, operadas e têm suporte nativo pelo Azure.

O Azure Front Door também fornece um WAF (firewall do aplicativo Web), que protege os aplicativos Web contra exposições e vulnerabilidades comuns.

O Gateway de Aplicativo do Azure é uma solução de virtualização dedicada que fornece um controlador de entrega de aplicativos gerenciado. Ele oferece vários recursos de balanceamento de carga de camada 7 ao seu aplicativo. Ele permite que você otimize o desempenho do Web farm descarregando a terminação SSL com uso intensivo de CPU para o Gateway de Aplicativo. Ele também fornece outros recursos de roteamento de Camada 7, por exemplo, distribuição round robin do tráfego de entrada, afinidade de sessão, roteamento com base no caminho de URL e a capacidade de hospedar vários sites por trás de um único gateway de aplicativo baseado em cookie. Um WAF (firewall do aplicativo Web) também é fornecido como parte da SKU do WAF do gateway de aplicativo. Essa SKU oferece proteção para aplicativos Web contra explorações e vulnerabilidades comuns da Web. O gateway de aplicativo pode ser configurado como um gateway voltado para a Internet, um gateway apenas interno ou uma combinação de ambos.

IPs públicos. Com alguns recursos do Azure, você pode associar pontos de extremidade de serviço a um endereço IP público para que seu recurso possa ser acessado pela Internet. Esse ponto de extremidade usa NAT a fim de rotear o tráfego para o endereço interno e a porta na rede virtual no Azure. Esse caminho é a principal rota para que o tráfego externo passe para dentro da rede virtual. Você pode configurar endereços IP públicos para determinar qual tráfego é passado para dentro e como e onde ele é convertido para a rede virtual.

A Proteção contra DDoS do Azure fornece mais recursos de mitigação sobre a camada de serviço básica que são ajustados especificamente para os recursos de rede virtual do Azure. A proteção contra DDoS é simples de habilitar e não requer alterações no aplicativo. As políticas de proteção são ajustadas por meio do monitoramento de tráfego dedicado e de algoritmos de aprendizado de máquina. As políticas são aplicadas a endereços IP públicos associados aos recursos implantados em redes virtuais. Os exemplos incluem instâncias do Azure Load Balancer, do Gateway de Aplicativo do Azure e do Azure Service Fabric. Os logs gerados pelo sistema quase em tempo real estão disponíveis por meio de exibições do Azure Monitor durante um ataque e para o histórico. Proteções de camada de aplicativo podem ser adicionadas por meio do firewall do aplicativo Web do gateway de aplicativo do Azure. A proteção é fornecida para endereços IP públicos IPv4 e IPv6 do Azure.

A topologia hub e spoke usa o emparelhamento de rede virtual e as rotas definidas pelo usuário para rotear o tráfego corretamente.

No diagrama, a rota definida pelo usuário garante que o tráfego flua do spoke para o firewall antes de passar para o local por meio do gateway do ExpressRoute (se a política de firewall permitir esse fluxo).

Tipo de componente: monitoramento

Componentes de monitoramento oferecem visibilidade e alertas de todos os outros tipos de componente. Todas as equipes podem ter acesso ao monitoramento para os componentes e serviços aos quais elas têm acesso. Se você tiver equipes de operações ou suporte técnico centralizadas, elas precisarão ter acesso integrado aos dados fornecidos por esses componentes.

O Azure oferece diferentes tipos de serviços de registro em log e monitoramento para controlar o comportamento de recursos hospedados do Azure. Governança e controle de cargas de trabalho no Azure baseiam-se não apenas na coleta de dados de log, mas também na capacidade de disparar ações com base em eventos relatados específicos.

Azure Monitor. O Azure inclui vários serviços que individualmente executam uma função ou tarefa específica no espaço de monitoramento. Juntos, esses serviços oferecem uma solução abrangente para coletar, analisar e agir nos logs gerados pelo sistema de seus aplicativos e dos recursos do Azure que dão suporte a eles. Eles também podem trabalhar para monitorar recursos críticos locais, para fornecer um ambiente de monitoramento híbrido. Compreender as ferramentas e os dados que estão disponíveis é a primeira etapa no desenvolvimento de uma estratégia de monitoramento completa para seus aplicativos.

Há dois tipos fundamentais de logs no Azure Monitor:

As Métricas são valores numéricos que descrevem algum aspecto de um sistema em um ponto específico no tempo. Elas são leves e podem dar suporte a cenários quase em tempo real. Para muitos recursos do Azure, você verá os dados coletados pelo Azure Monitor diretamente em sua página de visão geral no portal do Azure. Como exemplo, dê uma olhada em uma máquina virtual e você verá vários gráficos que exibem as métricas de desempenho. Selecione um dos gráficos para abrir os dados no Metrics Explorer, no portal do Azure, que permite fazer o gráfico dos valores de várias métricas ao longo do tempo. É possível exibir os gráficos interativamente ou fixá-los em um painel para exibi-los com outras visualizações.
Os Logs contêm diferentes tipos de dados organizados em registros com diferentes conjuntos de propriedades para cada um. Eventos e rastreamentos são armazenados como logs junto com dados de desempenho, que podem todos ser combinados para análise. Os dados do log coletados pelo Azure Monitor podem ser analisados com consultas que recuperam, consolidam e analisam rapidamente esses dados. Os logs são armazenados e consultados na análise de logs. É possível criar e testar consultas usando a análise de logs no portal do Azure e analisar diretamente os dados usando essas ferramentas ou salvar consultas para uso com visualizações ou regras de alerta.

O Azure Monitor pode coletar dados de várias fontes. Você pode pensar em dados de monitoramento de seus aplicativos em camadas, que vão do aplicativo, do sistema operacional e dos serviços de que ele depende, até a própria plataforma Azure. O Azure Monitor coleta dados de cada uma dos seguintes camadas:

Dados de monitoramento de aplicativo: dados sobre o desempenho e a funcionalidade do código que você escreveu, independentemente da plataforma.
Dados de monitoramento de SO convidado: dados sobre o sistema operacional no qual o aplicativo é executado. Este SO pode estar em execução no Azure, em outra nuvem ou localmente.
Dados de monitoramento de recursos do Azure: dados sobre a operação de um recurso do Azure.
Dados de monitoramento de assinatura do Azure: dados sobre a operação e o gerenciamento de uma assinatura do Azure, além da integridade e da operação do próprio Azure.
Dados de monitoramento de locatário do Azure: Dados sobre a operação de serviços do Azure no nível do locatário, como o Microsoft Entra ID.
Fontes personalizadas: os logs enviados de fontes locais também podem ser incluídos. Os exemplos incluem eventos de servidor local ou saída de syslog do dispositivo de rede.

Os dados de monitoramento só serão úteis se puderem aumentar sua visibilidade em relação ao funcionamento do ambiente de computação. O Azure Monitor inclui vários recursos e ferramentas que fornecem insights valiosos sobre seus aplicativos e outros recursos dos quais eles dependem. Soluções de monitoramento e recursos como o Application Insights e o Azure Monitor para contêineres fornecem insights aprofundados sobre diferentes aspectos do aplicativo e de serviços específicos do Azure.

As soluções de gerenciamento no Azure Monitor são conjuntos de lógica empacotados que fornecem informações para determinado aplicativo ou serviço. Eles incluem lógica para coleção de dados de monitoramento de aplicativo ou serviço, consultas para analisar esses dados e exibições para visualização. As soluções de gerenciamento são disponibilizadas pela Microsoft e por parceiros para oferecer monitoramento de vários serviços de terceiros e do Azure.

Com essa coleção de dados avançados, é importante tomar medidas proativas em relação a eventos que ocorram em seu ambiente, especialmente para os quais as apenas as consultas manuais não serão suficientes. Os alertas no Azure Monitor notificam proativamente sobre condições críticas e podem tentar tomar as medidas corretivas necessárias. As regras de alerta baseadas em métricas fornecem alertas quase em tempo real baseados em valores numéricos. Regras de alerta baseadas em logs permitem que haja lógica complexa em dados de várias fontes. As regras de alerta no Azure Monitor usam grupos de ação, que contêm conjuntos exclusivos de destinatários e ações que podem ser compartilhados entre várias regras. De acordo com suas necessidades, os grupos de ação podem usar webhooks que fazem com que os alertas iniciem ações externas ou sejam integrados às ferramentas ITSM.

O Azure Monitor também permite a criação de painéis personalizados. Os painéis do Azure permitem combinar diferentes tipos de dados, incluindo métricas e logs, em um único painel no portal do Azure. Você pode compartilhar o painel com outros usuários do Azure. Podem ser adicionados elementos de todo o Azure Monitor a um painel do Azure, além da saída de qualquer gráfico de métricas ou de consulta de log. Por exemplo, é possível criar um painel que combine blocos que mostrem um gráfico de métricas, uma tabela de logs de atividades, um gráfico de uso do Application Insights e a saída de uma consulta de log.

Por fim, os dados do Azure Monitor são uma fonte nativa para o Power BI. O Power BI é um serviço de análise de negócios que fornece visualizações interativas em várias fontes de dados. Também é um meio eficaz de disponibilizar dados para outras pessoas dentro e fora da sua organização. Você pode configurar o Power BI para importar dados de log automaticamente do Azure Monitor, para aproveitar essas visualizações adicionais.

O Observador de Rede do Azure fornece ferramentas para monitorar, diagnosticar, exibir métricas e ativar ou desativar os logs de recursos em uma rede virtual no Azure. É um serviço multifacetado que permite as seguintes funcionalidades e muito mais:

Monitorar a comunicação entre uma máquina virtual e um ponto de extremidade.
Exibir recursos em uma rede virtual e suas relações.
Diagnosticar problemas de filtragem de tráfego de erro para ou de uma VM.
Diagnosticar problemas de roteamento de rede de uma VM.
Diagnosticar conexões de saída de uma VM.
Capturar pacotes para e de uma VM.
Diagnosticar problemas com conexões e um gateway de rede virtual.
Determinar as latências relativas entre regiões do Azure e provedores de serviços de Internet.
Exibir regras de segurança para uma interface de rede.
Exibir métricas de rede.
Analisar o tráfego de ou para um grupo de segurança de rede.
Exibir logs de diagnóstico para recursos de rede.

Tipo de componente: cargas de trabalho

Componentes de carga de trabalho são o local em que seus aplicativos reais e serviços residem. É o ponto em que as equipes de desenvolvimento de aplicativo passam a maior parte do tempo.

As possibilidades de carga de trabalho são infinitas. A seguir estão apenas alguns dos tipos de carga de trabalho possíveis:

Aplicativos internos: os aplicativos de linha de negócios são essenciais às operações corporativas. Esses aplicativos têm algumas características em comum:

Interativo: os dados são inseridos e os resultados ou relatórios são retornados.
Controlado por dados: dados intensivos com acesso frequente aos bancos de dados ou outro armazenamento.
Integrado: oferecem integração a outros sistemas dentro ou fora da organização.

Sites voltados para o cliente (voltados para a Internet ou internos): a maioria dos aplicativos de Internet são sites da Web. O Azure pode executar um site em uma máquina virtual IaaS ou um site de Aplicativos Web do Azure (PaaS). Os aplicativos Web do Azure integram-se a redes virtuais para implantar aplicativos Web em uma zona de rede do spoke. Os sites da Web internos não precisam expor um ponto de extremidade de Internet público porque os recursos podem ser acessados por meio de endereços privados roteáveis fora da Internet a partir da rede virtual privada.

Análise de Big Data: quando os dados precisam ser escalados verticalmente para volumes maiores, os bancos de dados relacionais podem não ter um bom desempenho com carga extrema ou com sua natureza não estruturada. O Azure HDInsight é um serviço de análise totalmente gerenciado, completo e open-source na nuvem para empresas. Você pode usar estruturas de software livre como Hadoop, Apache Spark, Apache Hive, LLAP, Apache Kafka, Apache Storm e R. HDInsight. Isso dá suporte à implantação em uma rede virtual baseada em local, que pode ser implantada em um cluster em um spoke do datacenter virtual.

Eventos e mensagens: os Hubs de Eventos do Azure são uma plataforma de streaming de Big Data e um serviço de ingestão de eventos. Ele pode receber e processar milhões de eventos por segundo. Ele fornece baixa latência e retenção de tempo configurável, permitindo a você ingerir grandes quantidades de dados no Azure e lê-los de vários aplicativos. Um único fluxo pode dar suporte a pipelines tanto em tempo real quanto em lote.

Você pode implementar um serviço entre aplicativos e serviços por meio de mensagens de nuvem altamente confiável usando o Barramento de Serviço do Azure. Ele oferece um sistema de mensagens agenciado e assíncrono entre o cliente e o servidor, recursos de mensagens PEPS (primeiro a entrar, primeiro a sair) e de publicação e assinatura.

Esses exemplos mostram apenas poucos tipos de cargas de trabalho que você pode criar no Azure. Você pode criar tudo, desde um aplicativo Web e SQL básico até o mais recente em IoT, big data, aprendizado de máquina, IA e muito mais.

Alta disponibilidade: vários datacenters virtuais

Até agora, este artigo concentrou-se no projeto de um único VDC, descrevendo os componentes básicos e as arquiteturas que contribuem para sua resiliência. Recursos do Azure, como Azure Load Balancer, NVAs, zonas de disponibilidade, conjuntos de disponibilidade, conjuntos de dimensionamento e outros recursos que ajudam a incluir níveis sólidos de SLA em seus serviços de produção.

No entanto, como um datacenter virtual normalmente é implementado em uma única região, ele pode ficar vulnerável a interrupções que afetem toda a região. Os clientes que exigem alta disponibilidade precisam proteger os serviços por meio de implantações do mesmo projeto em duas (ou mais) implementações de VDC feitas em regiões diferentes.

Além das preocupações de SLA, vários cenários comuns se beneficiam da execução de vários datacenters virtuais:

Presença regional ou global dos seus usuários finais ou parceiros.
Requisitos de recuperação de desastre.
Um mecanismo para desviar o tráfego entre datacenters para fins de carga ou desempenho.

Presença regional/global

Os datacenters do Azure existem em muitas regiões em todo o mundo. Ao selecionar vários datacenters do Azure, considere dois fatores relacionados: distâncias geográficas e latência. Para otimizar a experiência do usuário, avalie a distância entre cada datacenter virtual e a distância de cada datacenter virtual até os usuários finais.

Uma região do Azure que hospeda seu datacenter virtual precisa estar em conformidade com os requisitos regulatórios das jurisdições legais sob as quais sua organização opera.

Recuperação de desastre

O design de um plano de recuperação de desastre depende dos tipos de cargas de trabalho e da capacidade de sincronizar o estado dessas cargas de trabalho entre diferentes implementações de VDC. Idealmente, a maioria dos clientes quer um mecanismo de failover rápido, e esse requisito pode exigir a sincronização de dados de aplicativo entre implantações executadas em várias implementações de VDC. No entanto, durante a criação de planos de recuperação de desastre, é importante considerar que a maioria dos aplicativos são afetados pela latência que pode ser causada por essa sincronização de dados.

A sincronização e o monitoramento de pulsação dos aplicativos em diferentes implementações de VDC exigem que eles se comuniquem pela rede. Várias implementações de VDC em regiões diferentes podem ser conectadas da seguinte maneira:

Comunicação hub a hub interna de hubs de WAN Virtual do Azure entre regiões na mesma WAN Virtual.
Emparelhamento de redes virtuais para conectar hubs entre regiões.
Emparelhamento privado ExpressRoute quando os hubs em cada implementação de VDC estão conectados ao mesmo circuito do ExpressRoute.
Vários circuitos do ExpressRoute conectados via backbone corporativo e suas várias implementações de VDC conectadas aos circuitos do ExpressRoute.
Conexões VPN Site a Site entre a zona de hub de suas implementações de VDC em cada região do Azure.

Normalmente, os hubs de WAN Virtual, o emparelhamento de rede virtual ou as conexões de ExpressRoute são preferidos conectividade de rede, devido à maior largura de banda e níveis de latência consistentes na passagem pelo backbone da Microsoft.

Faça testes de qualificação de rede para verificar a latência e a largura de banda dessas conexões e escolham a replicação de dados adequada, síncrona ou assíncrona, com base no resultado. Também é importante avaliar esses resultados tendo em vista o RTO (objetivo de tempo de recuperação) ideal.

Recuperação de desastre: desviando tráfego de uma região para outra

Tanto o Gerenciador de Tráfego do Azure quanto o Azure Front Door verificam periodicamente a integridade do serviço de pontos de extremidade de escuta em diferentes implementações de VDC. Se esses pontos de extremidade falharem, o Gerenciador de Tráfego do Azure e o Azure Front Door serão encaminhados automaticamente para o VDC mais próximo. O Gerenciador de Tráfego usa medidas de usuário em tempo real e DNS a fim de roteá-lo para o mais próximo (ou mais próximo durante a falha). O Azure Front Door é um proxy reverso em mais de 100 sites de borda do backbone da Microsoft, usando anycast a fim de rotear os usuários para o ponto de extremidade de escuta mais próximo.

Resumo

A abordagem de datacenter virtual para a migração é criar uma arquitetura escalonável que otimiza o uso de recursos do Azure, reduz os custos e simplifica a governança do sistema. O datacenter virtual é típico com base em topologias de rede hub e spoke (usando o emparelhamento de rede virtual ou os hubs de WAN Virtual). Os serviços compartilhados comuns fornecidos no hub e os aplicativos e as cargas de trabalho específicos são implantados nos spokes. O datacenter virtual também corresponde à estrutura de funções da empresa, em que departamentos diferentes, como TI Central, DevOps, Operação e Manutenção, trabalham juntos durante a execução de suas funções específicas. O datacenter virtual dá suporte à migração de cargas de trabalho locais existentes para o Azure, mas também oferece muitas vantagens para implantações nativas de nuvem.

Referências

Saiba mais sobre os recursos do Azure discutidos neste documento.

Recursos de rede
Redes Virtuais do Azure
Grupos de segurança de rede
Pontos de Extremidade de Serviço
Link privado
Rotas Definidas pelo Usuário
Soluções de virtualização de rede
Endereços IP Públicos
DNS do Azure

Balanceamento de carga
Azure Front Door
Azure Load Balancer (Camada 4)
Gateway de Aplicativo (Camada 7)
Gerenciador de Tráfego do Azure

Conectividade
Emparelhamento de rede virtual
Rede Virtual Privada
WAN Virtual
ExpressRoute
ExpressRoute Direct

Identidade
Microsoft Entra ID
Autenticação multifator do Microsoft Entra
Controle de acesso baseado em função do Azure
Funções internas do Azure

Monitoring
Observador de Rede
Azure Monitor
Log Analytics

Segurança
Firewall do Azure
Gerenciador de Firewall
WAF do Gateway de Aplicativo
WAF do Front Door
Azure DDoS

Outros serviços do Azure
Armazenamento do Azure
SQL do Azure
Aplicativos Web do Azure
Azure Cosmos DB
HDInsight
Hubs de Eventos
Barramento de Serviço
IoT do Azure
Azure Machine Learning

Próximas etapas

Saiba mais sobre o emparelhamento de rede virtual, a principal tecnologia de topologias de hub e spoke.
Implemente a ID do Microsoft Entra para usar o controle de acesso baseado em função do Azure.
Desenvolva uma assinatura e um modelo de gerenciamento de recursos usando o controle de acesso baseado em função do Azure que se ajusta à estrutura, aos requisitos e às políticas da sua organização. A atividade mais importante é o planejamento. Analise como reorganizações, fusões e aquisições, novas linhas de produto e outras considerações afetarão seus modelos iniciais para ter certeza de que poderá dimensionar e atender às necessidades e ao crescimento futuros.