O datacenter virtual: uma perspetiva de rede

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

O Microsoft Azure fornece serviços e infraestrutura de hiperescala com recursos e confiabilidade de nível empresarial. Esses serviços e infraestrutura oferecem muitas opções de conectividade híbrida, o que permite que os clientes acessem-nos pela internet ou por uma conexão de rede privada. Os parceiros da Microsoft também podem fornecer recursos aprimorados oferecendo serviços de segurança e dispositivos virtuais otimizados para execução no Azure.

Os clientes podem usar o Azure para estender perfeitamente sua infraestrutura para a nuvem e criar arquiteturas multicamadas.

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 considerações de segurança, confiabilidade, desempenho e custo que exigiam mais flexibilidade ao fornecer serviços em nuvem. Novas infraestruturas e serviços de rede foram concebidos para proporcionar flexibilidade. Os novos recursos fornecem escala elástica, recuperação de desastres e outras considerações.

As soluções em nuvem foram inicialmente projetadas para hospedar aplicativos únicos e relativamente isolados no espectro público, o que funcionou bem por alguns anos. À medida que os benefícios das soluções em nuvem se tornaram claros, várias cargas de trabalho de grande escala foram hospedadas na nuvem. Lidar com questões de segurança, confiabilidade, desempenho e custos é vital para a implantação e o ciclo de vida do seu serviço de nuvem.

No diagrama de implantação de nuvem de exemplo abaixo, a caixa vermelha destaca uma lacuna de segurança. A caixa amarela mostra uma oportunidade de otimizar dispositivos virtuais de rede em cargas de trabalho.

Os datacenters virtuais ajudam a alcançar a escala necessária para cargas de trabalho corporativas. A escala deve abordar os desafios introduzidos ao executar aplicativos de grande escala na nuvem pública.

Uma implementação de datacenter virtual inclui mais do que as cargas de trabalho de aplicativos na nuvem. Ele também fornece serviços de rede, segurança, gerenciamento, DNS e Ative 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. Um bom gerenciamento de recursos ajuda a evitar o aumento de "ilhas de carga de trabalho" gerenciadas separadamente com fluxos de dados independentes, modelos de segurança e desafios de conformidade.

O conceito de datacenter virtual fornece recomendações e designs de alto nível para implementar uma coleção de entidades separadas, mas relacionadas. Essas entidades geralmente têm funções, recursos e infraestrutura de suporte comuns. Ver suas cargas de trabalho como um datacenter virtual ajuda a obter custos reduzidos a partir de economias de escala. Ele também ajuda com a segurança otimizada por meio da centralização de componentes e fluxo de dados e operações mais fáceis, gerenciamento e auditorias de conformidade.

Nota

Um datacenter virtual não é um serviço específico do Azure. Em vez disso, vários recursos e capacidades 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 seus recursos e capacidades na nuvem. Ele fornece uma abordagem modular para fornecer serviços de TI no Azure, respeitando as funções e responsabilidades organizacionais da empresa.

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

• Hospede várias cargas de trabalho relacionadas.
• Migre cargas de trabalho de um ambiente local para o Azure.
• Implemente requisitos de segurança e acesso compartilhados ou centralizados em cargas de trabalho.
• Misture DevOps e TI centralizada adequadamente para uma grande empresa.

Quem deve implementar um datacenter virtual?

Qualquer cliente que decida adotar o Azure pode se beneficiar da eficiência da configuração de um conjunto de recursos para uso comum por todos os aplicativos. Dependendo do tamanho, até mesmo aplicativos individuais podem se beneficiar do uso dos padrões e componentes usados para criar uma implementação 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, separar responsabilidades e garantir a consistência dos componentes comuns subjacentes. As equipes de aplicativos podem manter a liberdade e o controle adequados às suas necessidades.

As organizações com uma abordagem de DevOps também podem usar conceitos de VDC para fornecer bolsos autorizados de recursos do Azure. Esse método garante que os grupos de DevOps tenham controle total dentro desse agrupamento, no nível da assinatura ou dentro dos 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 de hub e no grupo de recursos gerenciado centralmente.

Considerações para implementar um datacenter virtual

Ao projetar um datacenter virtual, considere estas questões cruciais:

Serviço de identidade e diretório

Os serviços de identidade e diretório são recursos essenciais dos datacenters locais e na nuvem. A identidade abrange todos os aspetos de acesso e autorização a serviços dentro de uma implementação VDC. Para garantir que apenas usuários e processos autorizados acessem seus 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 uma variedade de 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 de sua preferência.

Grandes empresas precisam definir processos de gerenciamento de identidade que descrevam o gerenciamento de identidades individuais, sua autenticação, autorização, funções e privilégios dentro ou entre seu VDC. Os objetivos desse processo podem aumentar a segurança e a produtividade, reduzindo custos, tempo de inatividade e tarefas manuais repetitivas.

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

Um serviço de diretório é uma infraestrutura de informações compartilhadas que localiza, gerencia, administra e organiza itens diários 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. As informações sobre um recurso são armazenadas como uma coleção de atributos associados a esse 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 abrangente e altamente disponível de gerenciamento de identidade e acesso 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 integrar-se com o Ative Directory local para habilitar o logon único para todos os aplicativos locais baseados em nuvem e hospedados localmente. Os atributos de usuário do Ative Directory local podem ser sincronizados automaticamente com o Microsoft Entra ID.

Cada departamento, grupo de usuários ou serviços específicos no Serviço de Diretório devem ter as permissões mínimas necessárias para gerenciar seus próprios recursos dentro de uma implementação VDC. Estruturar permissões requer balanceamento. Muitas permissões podem impedir a eficiência do desempenho, e poucas ou permissões soltas podem aumentar os riscos de segurança. O controle de acesso baseado em função do Azure (Azure RBAC) ajuda a resolver esse problema oferecendo gerenciamento de acesso refinado para recursos em uma implementação VDC.

Infraestrutura de segurança

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

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

Conectividade com a nuvem

Um datacenter virtual requer conectividade com redes externas para oferecer serviços a clientes, parceiros ou usuários internos. Esta necessidade de conectividade refere-se não só à Internet, mas também a redes locais e centros de dados.

Os clientes controlam os serviços que podem aceder e ser acedidos a partir da Internet pública. Esse acesso é controlado usando o Firewall do Azure ou outros tipos de dispositivos de rede virtual (NVAs), políticas de roteamento personalizadas usando rotas definidas pelo usuário e filtragem de rede usando 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 a datacenters locais ou outros recursos. Essa conectividade entre o Azure e as redes locais é um aspeto crucial ao projetar uma arquitetura eficaz. As empresas têm duas formas diferentes de criar esta interligação: transitar pela Internet ou através de ligações privadas diretas.

Uma VPN Site-to-Site do Azure conecta redes locais ao seu datacenter virtual no Azure. O link é estabelecido através 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 em protocolos padrão do setor, a maioria dos dispositivos de rede atuais pode criar conexões VPN com o Azure pela Internet ou caminhos de conectividade existentes.

O ExpressRoute permite conexões privadas entre seu datacenter virtual e quaisquer redes locais. As conexões 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 oferece 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 de Rota Expressa geralmente envolve o envolvimento com um provedor de serviços de Rota Expressa (o ExpressRoute Direct é a exceção). Para clientes que precisam começar rapidamente, é comum usar inicialmente a VPN Site a Site para estabelecer conectividade entre um datacenter virtual e recursos locais. Quando a interconexão física com o provedor de serviços estiver concluída, migre a conectividade pela conexão da Rota Expressa.

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 de ramificação a filial por meio do Azure. A WAN virtual permite que você se conecte e configure dispositivos de filial para se comunicar com o Azure. A conexão e a configuração podem ser feitas manualmente ou usando dispositivos de provedor preferenciais por meio de um parceiro de WAN virtual. O uso de dispositivos de provedor preferencial permite facilidade de uso, simplificação da conectividade e gerenciamento de configuração. O painel interno da WAN do Azure fornece informações instantâneas de solução de problemas que podem ajudar a economizar tempo e oferece uma maneira fácil de exibir conectividade site a site em grande 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 dentro da 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 e entre redes virtuais por conjuntos de regras de segurança especificadas para grupos de segurança de rede, políticas de firewall (Firewall do Azure ou dispositivos virtuais de rede) e rotas personalizadas definidas pelo usuário.

As redes virtuais são pontos de ancoragem para integrar produtos do Azure de plataforma como serviço (PaaS), como o Armazenamento do Azure, o Azure SQL e outros serviços públicos integrados que têm pontos de extremidade públicos. Com os pontos de extremidade de serviço e o Azure Private Link, você pode integrar seus serviços públicos à sua rede privada. Você pode até mesmo tornar seus serviços públicos 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 usando uma destas topologias de alto nível, com base em suas necessidades e requisitos de escala:

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

Em uma topologia Mesh, o emparelhamento de rede virtual conecta todas as redes virtuais diretamente umas às outras.

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

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

O hub de emparelhamento e a topologia spoke e a topologia 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 usando um hub de emparelhamento de rede virtual (rotulado como Hub Virtual Network no diagrama) ou um hub WAN virtual (rotulado como Azure Virtual WAN no diagrama). A WAN Virtual do Azure foi projetada para comunicações de grande escala de filial para filial e de filial para o Azure ou para evitar as complexidades de 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, como a necessidade de dispositivos virtuais de rede no hub.

Em topologias de hub e spoke, o hub é a zona de rede central que controla e inspeciona todo o tráfego entre diferentes zonas, como a internet, o local e os raios. A topologia hub and spoke ajuda o departamento de TI a aplicar centralmente as políticas de segurança. Também reduz o potencial de configuração incorreta e exposição.

O hub geralmente contém componentes de serviço comuns consumidos pelos raios. Os exemplos seguintes são serviços centrais comuns:

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

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

A função de cada spoke pode ser alojar diferentes tipos de carga de trabalho. Os spokes também proporcionam uma abordagem modular para implementações reproduzíveis das mesmas cargas de trabalho. Os exemplos incluem desenvolvimento/teste, teste de aceitação do usuário, pré-produção e produção. Os spokes podem também segregar e ativar diferentes grupos dentro da sua organização. Os grupos de DevOps são um bom exemplo do que os porta-vozes podem fazer. Dentro de um spoke, é possível implementar uma carga de trabalho básica ou cargas de trabalho multicamadas complexas com controlo de tráfego entre as camadas.

Limites de subscrições e múltiplos 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 "Esta escala de design pode ser dimensionada para usar outra rede virtual de hub nesta região?" e "Essa escala de design pode acomodar várias regiões?" É muito melhor planejar um projeto que escala e não precisa dele, do que deixar de planejar e precisar dele.

Quando escalar para um hub secundário (ou mais) depende de vários fatores, geralmente com base em limites inerentes à escala. Certifique-se de revisar os limites de assinatura, rede virtual e máquina virtual ao projetar para escala.

No Azure, cada componente, independentemente do tipo, é implantado numa subscrição do Azure. O isolamento dos componentes do Azure em diferentes subscrições do Azure pode satisfazer os requisitos de diferentes linhas de negócio, como a configuração de níveis diferenciados de acesso e autorização.

Uma única implementação VDC pode aumentar a escala de um grande número de raios. Embora, como em todo sistema de TI, haja limites de plataforma. A implantação do hub está vinculada a uma assinatura específica do Azure, que tem restrições e limites (por exemplo, um número máximo de emparelhamentos de rede virtual. Para obter detalhes, consulte Limites de assinatura, cotas e restrições de serviço e assinatura do Azure). Nos casos em que os limites podem ser um problema, a arquitetura pode aumentar 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 usando emparelhamento de rede virtual, Rota Expressa, WAN Virtual ou VPN Site a Site.

A introdução de vários hubs aumenta o custo e o esforço de gerenciamento do sistema. Isso só se justifica devido à escalabilidade, limites do sistema, redundância, replicação regional para desempenho do usuário final ou recuperação de desastres. Em cenários que exigem vários hubs, todos os hubs devem se esforçar para oferecer o mesmo conjunto de serviços para facilitar a operação.

Interligação entre spokes

Dentro de um único raio, ou um design de rede plana, é possível implementar cargas de trabalho complexas de várias camadas. As configurações de várias camadas podem ser implementadas usando sub-redes, que são 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 pode querer implementar uma carga de trabalho multicamada em várias redes virtuais. Com o emparelhamento de rede virtual, os raios podem se conectar a outros raios no mesmo hub ou em hubs diferentes. Um exemplo típico desse cenário é o caso em que os servidores de processamento de aplicativos estão em uma rede virtual ou falada. O banco de dados é implantado em uma rede virtual ou de raios diferente. Nesse caso, é fácil interconectar os raios com o emparelhamento de rede virtual, o que evita o trânsito pelo hub. Conclua uma arquitetura cuidadosa e uma revisão de segurança para garantir que ignorar o hub não ignore pontos importantes de segurança ou auditoria que podem existir apenas no hub.

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

Embora o Azure permita topologias complexas, um dos princípios fundamentais do conceito VDC é a repetibilidade e a simplicidade. Para minimizar o esforço de gerenciamento, o design hub-spoke simples é a arquitetura de referência VDC que recomendamos.

Componentes

O datacenter virtual é composto por 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 recursos do Azure. Sua implementação VDC é composta de instâncias de vários tipos de componentes e várias variações do mesmo tipo de componente. Por exemplo, você pode ter muitas instâncias de carga de trabalho diferentes e logicamente separadas que representam aplicativos diferentes. Use esses diferentes tipos de componentes e instâncias para criar o VDC.

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

Como boas práticas em geral, os direitos e privilégios de acesso podem ser baseados em grupos. Lidar com grupos em vez de usuários individuais facilita a manutenção das políticas de acesso, fornecendo uma maneira consistente de gerenciá-lo entre 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ções pode ter um prefixo exclusivo em seus nomes. Esse prefixo facilita a identificação de qual carga de trabalho um grupo está associado. Por exemplo, uma carga de trabalho que hospeda 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 prefaciadas com Corp. Um exemplo é o CorpNetOps.

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

• A equipe central de TI chamada Corp tem os direitos de propriedade para controlar os componentes da infraestrutura. Exemplos disso são a rede e a segurança. O grupo precisa ter o papel de colaborador na assinatura, controle do hub e direitos de colaborador de rede nos porta-vozes. Grandes organizações frequentemente dividem essas responsabilidades de gerenciamento entre várias equipes. Exemplos são um grupo de operações de rede CorpNetOps com foco exclusivo em redes e um grupo de operações de segurança CorpSecOps responsável pelo firewall e política de segurança. Nesse caso específico, dois grupos diferentes precisam ser criados para a atribuição dessas funções personalizadas.
• O grupo de desenvolvimento/teste chamado AppDevOps tem a responsabilidade de implantar cargas de trabalho de aplicativo ou serviço. Esse grupo assume a função de colaborador de máquina virtual para implantações de IaaS ou uma ou mais funções de colaborador de PaaS. Para obter mais informações, veja Funções incorporadas do Azure. Opcionalmente, a equipe de desenvolvimento/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 raio específico. Além do papel de contribuidor para cargas de trabalho, esse grupo também precisaria do papel de leitor de rede.
• O grupo de operação e manutenção chamado CorpInfraOps ou AppInfraOps tem a responsabilidade de gerenciar cargas de trabalho na produção. Esse grupo precisa ser um contribuidor de assinatura em cargas de trabalho em qualquer assinatura de produção. Algumas organizações também podem avaliar se precisam de um grupo de equipe de suporte de escalonamento com a função de colaborador de assinatura na produção e a assinatura do hub central. O outro grupo corrige possíveis problemas de configuração no ambiente de produção.

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

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

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

Normalmente, em TI, um ambiente (ou camada) é um sistema no qual vários aplicativos são implantados e executados. As grandes empresas utilizam um ambiente de desenvolvimento (onde as alterações são feitas e testadas) e um ambiente de produção (o que os utilizadores finais utilizam). Esses ambientes são separados, geralmente com vários ambientes de preparo entre eles, para permitir a implantação em fases (implantação), teste e reversão se surgirem problemas. As arquiteturas de implantação variam significativamente, mas geralmente o processo básico de começar no desenvolvimento (DEV) e terminar na produção (PROD) ainda é seguido.

Uma arquitetura comum para esses tipos de ambientes multicamadas inclui DevOps para desenvolvimento e teste, UAT para preparação 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 dos ambientes de DevOps ou de produção de um projeto. A presença de diferentes autenticações de usuário para acessar ambientes diferentes reduz possíveis interrupções e outros problemas causados por erros humanos.

Tipo de componente: infraestrutura

Este tipo de componente é onde reside a maior parte da infraestrutura de suporte. É também onde suas equipes centralizadas de TI, segurança e conformidade passam a maior parte do tempo.

Os componentes da infraestrutura fornecem uma interconexão para os diferentes componentes de uma implementação VDC e estão presentes tanto no hub quanto nos raios. A responsabilidade pelo gerenciamento e manutenção dos componentes da infraestrutura é normalmente atribuída à equipe central de TI ou à equipe de segurança.

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

Embora o 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 infraestrutura. A simplicidade de gestão é um dos principais objetivos do VDC. Usar NAT para lidar com questões de IP, embora seja uma solução válida, não é uma solução recomendada.

Os componentes da infraestrutura têm a seguinte funcionalidade:

• Serviços de identidade e diretório: o acesso a cada tipo 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 a recursos em uma assinatura específica do Azure. Esses serviços podem existir na nuvem ou podem ser sincronizados com a identidade local armazenada no Ative Directory.
• Redes virtuais: as redes virtuais são um dos principais componentes do VDC e permitem criar um limite de isolamento de tráfego na plataforma Azure. Uma rede virtual é composta por um único ou vários segmentos de rede virtual, cada um com um prefixo de rede IP específico (uma sub-rede, IPv4 ou IPv4/IPv6 de pilha dupla). A rede virtual define uma área de perímetro interno onde máquinas virtuais IaaS e serviços PaaS podem estabelecer comunicações privadas. As VMs (e serviços PaaS) em uma rede virtual não podem se comunicar diretamente com VMs (e serviços PaaS) em uma rede virtual diferente. Isso é verdade mesmo se ambas as redes virtuais forem criadas pelo mesmo cliente, sob a mesma assinatura. O isolamento é uma propriedade crítica que garante que as VMs e a comunicação do cliente permaneçam privadas em uma rede virtual. Quando a conectividade entre redes é desejada, os recursos a seguir descrevem como ela pode ser realizada.
• 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 acontece 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çamento privado da rede virtual para incluir o espaço 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 que você proteja seus recursos críticos de serviço do Azure para suas redes virtuais.
• Link Privado: o Azure Private Link permite que você acesse os Serviços PaaS do Azure (por exemplo, Armazenamento do Azure, Azure Cosmos DB e Banco de Dados SQL do Azure) e os serviços de cliente/parceiro hospedados pelo 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. Também pode criar o seu próprio Serviço de Link Privado na sua rede virtual e entregá-lo de forma privada aos seus clientes. A experiência de configuração e consumo usando o Azure Private Link é consistente em todos os serviços 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 define um caminho de comunicação dentro de uma rede virtual. A presença de rotas definidas pelo usuário garante o tráfego do trânsito spoke por meio de VMs personalizadas específicas ou dispositivos virtuais de rede e balanceadores de carga presentes no hub e nos raios.
• 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 chamadas de cinco tuplas 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 ambos. Os grupos de segurança de rede são essenciais para implementar um controle de fluxo correto no hub e nos raios. O nível de segurança oferecido 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 DNS para resolução de nomes públicos e privados . As zonas privadas fornecem resolução de nomes dentro de uma rede virtual e entre redes virtuais. As zonas privadas podem abranger redes virtuais na mesma região e entre regiões e subscrições. 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 alojar os seus domínios no Azure, pode gerir os recursos DNS com as mesmas credenciais, APIs, ferramentas e faturação dos seus outros serviços do Azure.
• Gerenciamento de grupo de gerenciamento, assinatura e grupo de recursos. Uma assinatura define um limite natural para criar vários grupos de recursos no Azure. Essa separação pode ser para função, segregação de funções ou faturamento. Os recursos em uma assinatura são reunidos 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 sua organização tiver muitas subscrições, poderá precisar de uma forma de gerir o acesso, as políticas e a conformidade dessas subscrições. Os grupos de gestão do Azure fornecem um nível de âmbito acima das subscrições. Você organiza assinaturas em contêineres conhecidos como grupos de gerenciamento e aplica suas condições de governança aos grupos de gerenciamento. Todas as subscrições num grupo de gestão herdam automaticamente as condições aplicadas ao grupo de gestão. Para ver esses três recursos em uma exibição de hierarquia, consulte Organizando seus recursos no Cloud Adoption Framework.
• Controle de acesso baseado em função do Azure (Azure RBAC): o Azure RBAC pode mapear funções organizacionais e direitos para acessar recursos específicos do Azure. Isso permite que você restrinja os usuários a apenas um determinado subconjunto de ações. Se estiver sincronizando a ID do Microsoft Entra com um Ative Directory local, você poderá usar os mesmos grupos do Ative Directory no Azure que usa localmente. Com o RBAC do Azure, você pode conceder acesso atribuindo a função apropriada a usuários, grupos e aplicativos dentro do 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 em um escopo pai também concede acesso aos filhos contidos nele. Com o RBAC do Azure, você pode segregar tarefas e conceder apenas a quantidade de acesso aos usuários de que eles precisam para executar seus trabalhos. Por exemplo, um funcionário pode gerenciar máquinas virtuais em uma assinatura, enquanto outro pode gerenciar bancos de dados do SQL Server 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 datacenter físicas ou locais, juntamente com qualquer conectividade com a Internet. O perímetro normalmente requer um investimento de tempo significativo de suas equipes de rede e segurança.

Os pacotes de entrada podem fluir através dos dispositivos de segurança no hub antes de chegar aos servidores e serviços back-end nos porta-vozes. Os exemplos incluem o firewall, IDS e IPS. Antes de deixarem a rede, os pacotes ligados à Internet das cargas de trabalho também podem fluir através dos dispositivos de segurança na rede de perímetro. Esse fluxo permite a aplicação, inspeção e auditoria de políticas.

Os componentes da rede de perímetro incluem:

• Redes virtuais, rotas definidas pelo utilizador e grupos de segurança de rede
• Aplicações virtuais de rede
• Balanceador de Carga do Azure
• Gateway de Aplicativo do Azure com firewall de aplicativo Web (WAF)
• IPs Públicos
• Azure Front Door com firewall de aplicativo Web (WAF)
• Azure Firewall e Azure Firewall Manager
• Proteção DDoS padrão

Normalmente, a equipe central de TI e as equipes de segurança são responsáveis pela definição de requisitos e 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. No hub DMZ, a rede de perímetro para a Internet pode ser dimensionada para dar suporte a muitas linhas de negócios, usando vários farms de Firewalls de Aplicativos Web (WAFs) ou Firewalls do Azure. O hub também permite conectividade local via VPN ou ExpressRoute, conforme necessário.

Nota

No diagrama anterior, no DMZ Hub, muitos dos recursos a seguir podem ser agrupados em um hub WAN Virtual do Azure (como redes virtuais, rotas definidas pelo usuário, grupos de segurança de rede, gateways VPN, gateways de Rota Expressa, Balanceadores de Carga do Azure, Firewalls do Azure, Gerenciador de Firewall e DDOS). Usar hubs WAN virtuais 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 de engenharia é tratada para você pelo Azure quando você implanta um hub 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 de ou para a Internet por meio do Firewall do Azure, NVAs, WAF e instâncias do Gateway de Aplicativo do Azure.

Rotas definidas pelo usuário. Com as rotas definidas pelo utilizador, os clientes podem implementar firewalls, IDS/IPS e outras aplicações virtuais. Eles podem rotear o tráfego de rede por meio desses dispositivos de segurança para aplicação, auditoria e inspeção de políticas de limites de segurança. As rotas definidas pelo usuário podem ser criadas no hub e nos raios para garantir que o tráfego transite pelas VMs personalizadas específicas, Dispositivos Virtuais de Rede e balanceadores de carga usados por uma implementação VDC. Para garantir que o tráfego gerado a partir de 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 definindo o endereço IP front-end do balanceador de carga interno como o próximo salto. O balanceador de carga interno distribui o tráfego interno pelas aplicações virtuais (conjunto de back-end do balanceador de carga).

O Firewall do Azure é um serviço de segurança de rede gerenciado que protege os recursos da Rede Virtual do Azure. É um firewall gerenciado com estado com alta disponibilidade e escalabilidade na nuvem. Pode criar, impor e registar centralmente políticas de conectividade de rede e aplicações entre subscrições e redes virtuais. O Azure Firewall utiliza um endereço IP público estático para os recursos de redes virtuais. Permite às firewalls externas identificar o tráfego proveniente da rede virtual. O serviço está totalmente integrado no Azure Monitor para fins de registo e análise.

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

Dispositivos virtuais 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 firewall de aplicativo Web (WAF).

Diferentes linhas de negócios geralmente usam muitas aplicações web, que tendem a sofrer de várias vulnerabilidades e explorações potenciais. Os firewalls de aplicativos da Web são um tipo especial de produto usado para detetar ataques contra aplicativos da Web e HTTP/HTTPS de forma mais eficaz do que um firewall genérico. Em comparação com a tecnologia de firewall tradicional, os WAFs têm um conjunto de recursos específicos para proteger os servidores Web internos contra ameaças.

Um Firewall do Azure ou um firewall NVA usa um plano de administração comum, com um conjunto de regras de segurança para proteger as cargas de trabalho hospedadas nos raios e controlar o acesso a redes locais. O Firewall do Azure tem escalabilidade interna, enquanto os firewalls NVA podem ser dimensionados manualmente atrás de um balanceador de carga. Geralmente, um farm de firewall tem um software menos especializado em comparação com um WAF, mas tem um escopo de aplicativo mais amplo para filtrar e inspecionar qualquer tipo de tráfego de saída e entrada. Se uma abordagem NVA for usada, eles poderão ser encontrados e implantados no Azure Marketplace.

Recomendamos que você use um conjunto de instâncias do Firewall do Azure, ou NVAs, para o tráfego originado na Internet. Use outro para o tráfego originado no local. Usar apenas um conjunto de firewalls para ambos é um risco de segurança, pois não fornece perímetro de segurança entre os dois conjuntos de tráfego de rede. O uso de camadas de firewall separadas reduz a complexidade da verificação de regras de segurança, o que deixa claro quais regras correspondem a qual solicitação 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 para o balanceador de carga a partir de pontos de extremidade 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ço para um conjunto de pools de endereços IP back-end (como dispositivos virtuais de rede ou máquinas virtuais).

O Azure Load Balancer pode investigar a integridade de várias instâncias de servidor. Quando uma instância não consegue responder a uma pesquisa, o balanceador de carga deixa de enviar tráfego para as instâncias em mau estado de funcionamento. Em um datacenter virtual, um balanceador de carga externo é implantado no hub e nos raios. No hub, o balanceador de carga é usado para rotear o tráfego de forma eficiente entre instâncias de firewall. Nos raios, os balanceadores de carga são usados para gerenciar o tráfego do aplicativo.

O Azure Front Door (AFD) é 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 que você crie, opere e dimensione seu aplicativo Web dinâmico e conteúdo estático. O AFD fornece ao seu aplicativo desempenho de usuário final de classe mundial, automação unificada de manutenção regional/de selos, automação BCDR, informações unificadas de cliente/usuário, cache e insights de serviço.

A plataforma oferece:

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

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

O Gateway de Aplicativo do Azure é um dispositivo virtual dedicado que fornece um controlador de entrega de aplicativos gerenciados. Ele oferece vários recursos de balanceamento de carga da Camada 7 para seu aplicativo. Ele permite otimizar o desempenho da 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, como distribuição round-robin de tráfego de entrada, afinidade de sessão baseada em cookie, roteamento baseado em caminho de URL e a capacidade de hospedar vários sites atrás de um único gateway de aplicativo. Também é fornecida uma firewall de aplicações Web (WAF) como parte do SKU da WAF do gateway de aplicação. Este SKU oferece proteção às aplicações Web contra vulnerabilidades e exploits Web comuns. O gateway de aplicativo pode ser configurado como gateway voltado para a Internet, gateway somente 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 seja acessível pela Internet. Este ponto de extremidade usa NAT para rotear o tráfego para o endereço interno e a porta na rede virtual no Azure. Este caminho é a via principal de passagem do tráfego externo para a rede virtual. Você pode configurar endereços IP públicos para determinar qual tráfego é passado e como e onde ele é traduzido 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 aos recursos de rede virtual do Azure. A Proteção contra DDoS é simples de ativar e não requer alterações na aplicação. As políticas de proteção são otimizadas através de uma monitorização de tráfego dedicada e de algoritmos de aprendizagem automática. As políticas são aplicadas aos endereços IP públicos associados aos recursos implementados nas redes virtuais. Os exemplos incluem o balanceador de carga do Azure, o gateway de aplicativo do Azure e as instâncias do Azure service fabric. Os logs gerados pelo sistema quase em tempo real estão disponíveis por meio das exibições do monitor do Azure durante um ataque e para o histórico. A proteção da camada de aplicativo pode ser adicionada por meio do firewall do aplicativo Web do gateway de aplicativo do Azure. A proteção é fornecida para endereços IP públicos do Azure IPv4 e IPv6.

A topologia hub e spoke usa emparelhamento de rede virtual e 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 ExpressRoute (se a política de firewall permitir esse fluxo).

Tipo de componente: monitorização

Os componentes de monitoramento fornecem visibilidade e alertas de todos os outros tipos de componentes. Todas as equipas podem ter acesso à monitorização dos componentes e serviços a que têm acesso. Se você tiver um help desk centralizado ou equipes de operações, elas precisarão de acesso integrado aos dados fornecidos por esses componentes.

O Azure oferece diferentes tipos de serviços de registo e monitorização para controlar o comportamento dos recursos alojados no Azure. A governança e o controle de cargas de trabalho no Azure não se baseiam apenas na coleta de dados de log, mas também na capacidade de acionar ações com base em eventos relatados específicos.

Azure Monitor. O Azure inclui vários serviços que efetuam individualmente uma tarefa ou função específica no espaço de monitorização. Juntos, esses serviços fornecem uma solução abrangente para coletar, analisar e agir em logs gerados pelo sistema de seus aplicativos e dos recursos do Azure que os suportam. Eles também podem trabalhar para monitorar recursos locais críticos para fornecer um ambiente de monitoramento híbrido. Compreender as ferramentas e os dados disponíveis é o primeiro passo 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 aspeto de um sistema em um determinado momento. Eles são leves e capazes de suportar cenários quase em tempo real. Para muitos recursos do Azure, você verá os dados coletados pelo Azure Monitor diretamente na página de visão geral no portal do Azure. Como exemplo, olhe para qualquer máquina virtual e você verá vários gráficos exibindo métricas de desempenho. Selecione qualquer um dos gráficos para abrir os dados no explorador de métricas no portal do Azure, que permite mapear os valores de várias métricas ao longo do tempo. Você pode visualizar os gráficos interativamente ou fixá-los em um painel para visualizá-los com outras visualizações.

• Os logs contêm diferentes tipos de dados organizados em registros com diferentes conjuntos de propriedades para cada tipo. Eventos e rastreamentos são armazenados como logs juntamente com dados de desempenho, que podem ser combinados para análise. Os dados de log coletados pelo Azure Monitor podem ser analisados com consultas para recuperar, consolidar e analisar rapidamente os dados coletados. Os logs são armazenados e consultados a partir da análise de logs. Você pode criar e testar consultas usando a análise de log 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 monitorar dados para seus aplicativos em camadas que vão desde seu aplicativo, qualquer sistema operacional e os serviços dos quais ele depende, até a própria plataforma Azure. O Azure Monitor recolhe dados de cada um dos seguintes escalões:

• Dados de monitoramento de aplicativos: dados sobre o desempenho e a funcionalidade do código que você escreveu, independentemente de sua plataforma.
• Dados de monitoramento do SO convidado: dados sobre o sistema operacional no qual seu aplicativo está sendo executado. Este SO pode estar a ser executado no Azure, noutra nuvem ou no local.
• 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 e a integridade e a 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 syslog de dispositivo de rede.

O monitoramento de dados só é útil se puder aumentar sua visibilidade sobre a operação do seu ambiente de computação. O Azure Monitor inclui vários recursos e ferramentas que fornecem informações valiosas sobre seus aplicativos e outros recursos dos quais eles dependem. Soluções e recursos de monitoramento, como insights de aplicativos e o Azure Monitor para contêineres, fornecem insights profundos sobre diferentes aspetos de seu aplicativo e serviços específicos do Azure.

As soluções de monitoramento no Azure Monitor são conjuntos empacotados de lógica que fornecem informações para um aplicativo ou serviço específico. Eles incluem lógica para coletar dados de monitoramento para o aplicativo ou serviço, consultas para analisar esses dados e exibições para visualização. As soluções de monitoramento estão disponíveis da Microsoft e de parceiros para fornecer monitoramento para vários serviços do Azure e outros aplicativos.

Com essa coleção de dados ricos, é importante tomar medidas proativas sobre eventos que acontecem em seu ambiente, especialmente onde as consultas manuais por si só não são suficientes. Os alertas no Azure Monitor notificam proativamente sobre condições críticas e potencialmente tentam tomar medidas corretivas. As regras de alerta baseadas em métricas fornecem alertas quase em tempo real com base em valores numéricos. As regras de alerta baseadas em logs permitem uma lógica complexa entre dados de várias fontes. As regras de alerta no Azure Monitor usam grupos de ações, que contêm conjuntos exclusivos de destinatários e ações que podem ser compartilhados entre várias regras. Com base em suas necessidades, os grupos de ação podem usar webhooks que fazem com que alertas iniciem ações externas ou se integrem às suas ferramentas de 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. Opcionalmente, você pode compartilhar o painel com outros usuários do Azure. Elementos em todo o Azure Monitor podem ser adicionados a um painel do Azure, além da saída de qualquer consulta de log ou gráfico de métricas. Por exemplo, você pode criar um painel que combine blocos que mostram um gráfico de métricas, uma tabela de logs de atividades, um gráfico de uso de insights de aplicativos 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 a outras pessoas dentro e fora da sua organização. Você pode configurar o Power BI para importar automaticamente dados de log do Azure Monitor para aproveitar essas mais visualizações.

O Azure Network Watcher fornece ferramentas para monitorar, diagnosticar e exibir métricas e habilitar ou desabilitar logs para recursos em uma rede virtual no Azure. É um serviço multifacetado que permite as seguintes funcionalidades e muito mais:

• Monitore a comunicação entre uma máquina virtual e um ponto de extremidade.
• Visualize recursos em uma rede virtual e seus relacionamentos.
• Diagnostique problemas de filtragem de tráfego de rede de ou para uma VM.
• Diagnostique problemas de roteamento de rede a partir de uma VM.
• Diagnostique conexões de saída de uma VM.
• Capture pacotes de e para uma VM.
• Diagnostique problemas com um gateway de rede virtual e conexões.
• Determine latências relativas entre regiões do Azure e provedores de serviços de Internet.
• Veja as regras de segurança para uma interface de rede.
• Veja as métricas da rede.
• Analise o tráfego de ou para um grupo de segurança de rede.
• Exiba logs de diagnóstico para recursos de rede.

Tipo de componente: Cargas de trabalho

Os componentes da carga de trabalho são onde seus aplicativos e serviços reais residem. É onde suas equipes de desenvolvimento de aplicativos 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 para as operações corporativas. Estas aplicações têm algumas características comuns:

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

Sites voltados para o cliente (voltados para a Internet ou internos): A maioria dos aplicativos da Internet são sites. O Azure pode executar um site por meio de uma máquina virtual IaaS ou de 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 spoke. Sites voltados internamente não precisam expor um ponto de extremidade público da Internet porque os recursos são acessíveis por meio de endereços privados não roteáveis da Internet a partir da rede virtual privada.

Análise de Big Data: quando os dados precisam ser dimensionados para volumes maiores, os bancos de dados relacionais podem não ter um bom desempenho sob a carga extrema ou a natureza não estruturada dos dados. O Azure HDInsight é um serviço de análise gerenciado, de espectro completo e de código aberto na nuvem para empresas. Você pode usar estruturas de código aberto como Hadoop, Apache Spark, Apache Hive, LLAP, Apache Kafka, Apache Storm e R. HDInsight. Isso oferece suporte à implantação em uma rede virtual baseada em local, que pode ser implantada em um cluster em um 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. Pode receber e processar milhões de eventos por segundo. Ele fornece baixa latência e retenção de tempo configurável, permitindo que você ingira grandes quantidades de dados no Azure e os leia de vários aplicativos. Um único fluxo pode suportar pipelines em tempo real e baseados em lotes.

Você pode implementar um serviço de mensagens na nuvem altamente confiável entre aplicativos e serviços por meio do Barramento de Serviço do Azure. Ele oferece mensagens intermediadas assíncronas entre cliente e servidor, mensagens estruturadas first-in-first-out (FIFO) e recursos de publicação e assinatura.

Esses exemplos mal arranham a superfície dos 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 que há de 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 arquiteturas que contribuem para a resiliência. Recursos do Azure, como o Azure Load Balancer, NVAs, zonas de disponibilidade, conjuntos de disponibilidade, conjuntos de escala 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 estar vulnerável a interrupções que afetam toda a região. Os clientes que exigem alta disponibilidade devem proteger os serviços por meio de implantações do mesmo projeto em duas ou mais implementações VDC implantadas em regiões diferentes.

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

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

Presença regional/global

Os datacenters do Azure existem em muitas regiões do 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 para os usuários finais.

Uma região do Azure que hospeda seu datacenter virtual deve estar em conformidade com os requisitos regulatórios de qualquer jurisdição legal sob a qual sua organização opera.

Recuperação após desastre

O design de um plano de recuperação de desastres 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 deseja um mecanismo de failover rápido, e esse requisito pode precisar de sincronização de dados de aplicativos entre implantações em execução em várias implementações VDC. No entanto, ao projetar planos de recuperação de desastres, é importante considerar que a maioria dos aplicativos é sensível à latência que pode ser causada por essa sincronização de dados.

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

• Comunicação hub-to-hub incorporada nos hubs WAN Virtual do Azure entre regiões na mesma WAN Virtual.
• Emparelhamento de rede virtual para conectar hubs entre regiões.
• Emparelhamento privado de Rota Expressa, quando os hubs em cada implementação de VDC estão conectados ao mesmo circuito de Rota Expressa.
• Vários circuitos de Rota Expressa conectados através de seu backbone corporativo e suas várias implementações VDC conectadas aos circuitos de Rota Expressa.
• Conexões VPN site a site entre a zona de hub de suas implementações VDC em cada região do Azure.

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

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

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

O Azure Traffic Manager e o Azure Front Door verificam periodicamente a integridade do serviço de pontos de extremidade de escuta em diferentes implementações VDC. Se esses pontos de extremidade falharem, o Gerenciador de Tráfego do Azure e o Azure Front Door encaminham automaticamente para o VDC mais próximo. O Gestor de Tráfego utiliza medições de utilizador em tempo real e DNS para encaminhar os utilizadores para o mais próximo (ou próximo durante uma falha). O Azure Front Door é um proxy reverso em mais de 100 sites de borda de backbone da Microsoft, usando anycast para rotear os usuários para o ponto de extremidade de escuta mais próximo.

Resumo

A abordagem de datacenter virtual para migração é criar uma arquitetura escalável que otimize o uso de recursos do Azure, reduza custos e simplifique a governança do sistema. O datacenter virtual é típico com base em topologias de rede hub e spoke (usando emparelhamento de rede virtual ou hubs WAN virtuais). Serviços compartilhados comuns fornecidos no hub e aplicativos e cargas de trabalho específicos são implantados nos porta-vozes. O datacenter virtual também corresponde à estrutura das funções da empresa, onde diferentes departamentos, como TI central, DevOps e operações e manutenção, trabalham juntos enquanto desempenham 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 da 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 Finais de Serviço
Ligação Privada
Rotas definidas pelo usuário
Dispositivos virtuais de rede
Endereços IP públicos
Azure DNS

Balanceamento de carga
Azure Front Door
Azure Load Balancer (Camada 4)
Gateway de aplicativo (camada 7)
Gestor de Tráfego do Azure

Conetividade
Virtual Network Peering (Peering de Rede Virtual)
Rede Privada Virtual
Virtual WAN
ExpressRoute
ExpressRoute Direto

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

Monitorização
Observador de rede
Azure Monitor
Log Analytics

Melhores práticas
Grupo de Gestão
Gestão de Subscrição
Gestão de Grupos de Recursos
Limites de Subscrição do Azure

Segurança
Azure Firewall
Gestor de Firewall
WAF do gateway de aplicativo
Porta da frente WAF
Azure DDoS

Outros serviços do Azure
Armazenamento do Azure
SQL do Azure
Aplicações Web do Azure
BD do Cosmos para o Azure
HDInsight
Hubs de Eventos
Service Bus
Azure IoT
Azure Machine Learning

Próximos passos

• Saiba mais sobre o emparelhamento de rede virtual, a tecnologia central das topologias hub e spoke.
• Implemente o Microsoft Entra ID para usar o controle de acesso baseado em função do Azure.
• Desenvolva um modelo de gerenciamento de assinatura e recursos usando o controle de acesso baseado em função do Azure que se adapte à estrutura, aos requisitos e às políticas da sua organização. A atividade mais importante é o planejamento. Analise como reorganizações, fusões, novas linhas de produtos e outras considerações afetarão seus modelos iniciais para garantir que você possa escalar para atender às necessidades e ao crescimento futuros.