Compartilhar via

Arquitetura de referência de linha de base local do Azure

Azure Local
Azure Arc
Azure Key Vault
Azure Monitor
Microsoft Defender para Nuvem

Essa arquitetura de referência de linha de base fornece diretrizes e recomendações independentes de carga de trabalho para configurar a infraestrutura local do Azure 2311 e posterior, para fornecer uma plataforma confiável para cargas de trabalho virtualizadas e em contêineres altamente disponíveis. Essa arquitetura descreve os componentes de recurso e as opções de design de cluster para os computadores físicos que fornecem recursos locais de computação, armazenamento e rede. Ele também descreve como usar os serviços do Azure para simplificar e simplificar o gerenciamento diário do Azure Local para operações em escala.

Para obter mais informações sobre padrões de arquitetura de carga de trabalho otimizados para serem executados no Azure Local, consulte o conteúdo localizado no menu cargas de trabalho locais do Azure menu de navegação.

Essa arquitetura é um ponto de partida para como usar o design de rede comutado de armazenamento para implantar uma instância local do Azure de vários nós. Os aplicativos de carga de trabalho implantados em uma instância local do Azure devem ser bem arquitetados. Aplicativos de carga de trabalho bem projetados devem ser implantados usando várias instâncias ou alta disponibilidade de qualquer serviço de carga de trabalho crítico e ter controles de BCDR (continuidade de negócios e recuperação de desastre) apropriados. Esses controles BCDR incluem backups regulares e recursos de failover de recuperação de desastre. Para se concentrar na plataforma de infraestrutura HCI, esses aspectos de design de carga de trabalho são excluídos intencionalmente deste artigo.

Para obter mais informações sobre diretrizes e recomendações para os cinco pilares do Azure Well-Architected Framework, consulte o guia de serviço do Azure Local Well-Architected Framework.

Layout do artigo

Architecture Decisões de design Abordagem do Well-Architected Framework
▪ Arquitetura
▪ possíveis casos de uso
▪ Detalhes do cenário
▪ Recursos da plataforma
▪ Recursos de suporte à plataforma
▪ Implantar esse cenário
▪ opções de design do cluster
▪ unidades de disco físico
▪ Design de rede
▪ Monitorização
▪ Gerenciamento de atualizações		 ▪ Fiabilidade
▪ Segurança
▪ Otimização de custo
▪ Excelência operacional
▪ Eficiência de desempenho

Tip

Logotipo do GitHub Este modelo local do Azure demonstra como usar um modelo do ARM (modelo de Gerenciamento de Recursos do Azure) e um arquivo de parâmetro para implantar uma implantação de vários servidores comutada do Azure Local. Como alternativa, o exemplo Bicep demonstra como usar um modelo Bicep para implantar uma instância local do Azure e seus recursos de pré-requisitos.

Architecture

Diagrama que mostra uma arquitetura de referência de instância local do Azure de vários nós com comutadores toR (Top-of-Rack) duplos para conectividade norte-sul externa.

Para obter mais informações, consulte Recursos relacionados.

Possíveis casos de uso

Os casos de uso típicos do Azure Local incluem a capacidade de executar cargas de trabalho de alta disponibilidade (HA) em locais locais ou de borda, fornecendo uma plataforma para atender a requisitos como:

  • Forneça uma solução conectada à nuvem implantada localmente para atender aos requisitos de soberania, regulamentação e conformidade ou latência de dados.

  • Implante e gerencie cargas de trabalho baseadas em contêiner ou virtualizadas em HA implantadas em um único ou vários locais de borda. Para permitir que aplicativos e serviços comercialmente críticos operem de maneira resiliente, econômica e escalonável.

  • Capacidade de reduzir o custo total de propriedade (TCO) implantando uma solução que é certificada pela Microsoft e pelo parceiro OEM de hardware, que usa um processo de implantação baseado em nuvem moderno e que fornece uma experiência de monitoramento e gerenciamento centralizado consistente do Azure.

  • Forneça uma funcionalidade de provisionamento centralizada usando o Azure e o Azure Arc, permitindo a implantação de cargas de trabalho em vários locais de forma consistente e segura. Ferramentas como o portal do Azure, a CLI do Azure ou os modelos de IaC (infraestrutura como código) (ARM, Bicep e Terraform) para aumentar a automação e a repetibilidade. Habilitando a implantação rápida e o gerenciamento de clusters do AKS para VMs locais do Azure e/ou em contêineres para cargas de trabalho virtualizadas tradicionais.

  • Siga os requisitos estritos de segurança, conformidade e auditoria. O Azure Local é implantado com uma postura de segurança protegida configurada por padrão ou segura por padrão. O Azure Local incorpora hardware certificado, Inicialização Segura, TPM (Trusted Platform Module), VBS (segurança baseada em virtualização), Credential Guard e políticas de Controle de Aplicativo impostas. Com a capacidade de se integrar a serviços modernos de segurança e gerenciamento de ameaças baseados em nuvem, como o Microsoft Defender para Nuvem e o Microsoft Sentinel, para fornecer recursos XDR (detecção e resposta estendidas) e siem (gerenciamento de eventos de informações de segurança).

Detalhes do cenário

As seções a seguir fornecem mais informações sobre os cenários e possíveis casos de uso para essa arquitetura de referência. Essas seções incluem uma lista de benefícios comerciais e tipos de recursos de carga de trabalho de exemplo que você pode implantar no Azure Local.

Usar o Azure Arc com o Azure Local

O Azure Local integra-se diretamente ao Azure usando o Azure Arc para reduzir o TCO e a sobrecarga operacional. O Azure Local é implantado e gerenciado por meio do Azure, que fornece integração interna do Azure Arc por meio da implantação da ponte de recursos Azure Arc componente. Esse componente da ponte de recursos é implantado como parte do processo de implantação de nuvem da instância local do Azure. Os computadores locais do Azure são registrados com o Azure Arc para servidores como um pré-requisito para iniciar a implantação de nuvem da instância local do Azure. Durante a implantação, as extensões obrigatórias são instaladas em cada computador, como o Gerenciador de Ciclo de Vida, o Gerenciamento de Dispositivos do Microsoft Edge e as extensões de Telemetria e Diagnóstico. Após a implantação, você pode usar o Azure Monitor e o Log Analytics para monitorar a solução, habilitando o Insights para o Azure Local. As atualizações de recursos do Azure Local são lançadas a cada seis meses para aprimorar a experiência do cliente. As atualizações do Azure Local são controladas e gerenciadas usando o Gerenciador de Atualizações do Azure.

Você pode implantar recursos de carga de trabalho, como de máquinas virtuais (VMs) do Azure Arc, do AKS (Serviço de Kubernetes do Azure) habilitado para Azure Arc e hosts de sessão da Área de Trabalho Virtual do Azure que usam o portal do Azure selecionando um local personalizado da instância local do Azure como destino para a implantação da carga de trabalho. Esses componentes fornecem administração centralizada, gerenciamento e suporte. Se você tiver o Software Assurance ativo em suas licenças principais existentes do Windows Server Datacenter, poderá reduzir ainda mais os custos aplicando o Benefício Híbrido do Azure aos clusters local do Azure, VMs do Windows Server e AKS. Essa otimização ajuda a gerenciar os custos efetivamente para esses serviços.

A integração do Azure e do Azure Arc estende os recursos das cargas de trabalho virtualizadas e em contêineres locais do Azure para incluir:

  • VMs locais do Azure para aplicativos ou serviços tradicionais executados em VMs no Azure Local.

  • o AKS no Local do Azure para aplicativos ou serviços em contêineres que se beneficiam de usar o Kubernetes como plataforma de orquestração.

  • a Área de Trabalho Virtual do Azure implantar seus hosts de sessão para cargas de trabalho da Área de Trabalho Virtual do Azure no Azure Local (local). Você pode usar o plano de controle e gerenciamento no Azure para iniciar a criação e a configuração do pool de hosts.

  • serviços de dados habilitados para Azure Arc para Instância Gerenciada de SQL do Azure em contêineres ou um servidor do Banco de Dados do Azure para PostgreSQL que usa o AKS habilitado para Azure Arc hospedado no Azure Local.

  • A extensão da Grade de Eventos do Azure habilitada para a Azure Arc para Kubernetes para implantar o agente da Grade de Eventos e os componentes do operador da Grade de Eventos. Essa implantação habilita recursos como tópicos da Grade de Eventos e assinaturas para processamento de eventos.

  • o machine learning habilitado para Azure Arc com um cluster do AKS implantado no Azure Local como o destino de computação para executar o Azure Machine Learning. Você pode usar essa abordagem para treinar ou implantar modelos de machine learning na borda.

As cargas de trabalho conectadas ao Azure Arc fornecem consistência e automação aprimoradas do Azure para implantações locais do Azure, como automatizar a configuração do sistema operacional convidado com extensões de VM local do Azure ou avaliar a conformidade com regulamentos do setor ou padrões corporativos por meio do Azure Policy. Você pode ativar o Azure Policy por meio do portal do Azure ou da automação IaC.

Aproveite a configuração de segurança padrão do Azure Local

A configuração de segurança padrão local do Azure fornece uma estratégia de defesa detalhada para simplificar os custos de segurança e conformidade. A implantação e o gerenciamento de serviços de TI para cenários de varejo, fabricação e escritório remoto apresentam desafios exclusivos de segurança e conformidade. Proteger cargas de trabalho contra ameaças internas e externas é crucial em ambientes com suporte limitado de TI ou falta ou datacenters dedicados. O Azure Local tem proteção de segurança padrão e integração profunda com os serviços do Azure para ajudá-lo a enfrentar esses desafios.

O hardware certificado localmente pelo Azure garante a Inicialização Segura interna, a UEFI (Unified Extensible Firmware Interface) e o suporte ao TPM. Use essas tecnologias em combinação com o VBS para ajudar a proteger suas cargas de trabalho sensíveis à segurança. Você pode usar o BitLocker Drive Encryption para criptografar volumes de disco de inicialização e espaços de armazenamento direcionam volumes em repouso. A criptografia SMB (Bloco de Mensagens do Servidor) fornece criptografia automática de tráfego entre computadores físicos no cluster (na rede de armazenamento) e assinatura de tráfego SMB entre os computadores físicos do cluster e outros sistemas. A criptografia SMB também ajuda a evitar ataques de retransmissão e facilita a conformidade com os padrões regulatórios.

Você pode integrar VMs locais do Azure no Defender para Nuvem para ativar análise comportamental baseada em nuvem, detecção e correção de ameaças, alertas e relatórios. Gerencie VMs locais do Azure no Azure Arc para que você possa usar o Azure Policy para avaliar sua conformidade com regulamentos do setor e padrões corporativos.

Components

Essa arquitetura consiste em hardware de servidor físico que você pode usar para implantar instâncias locais ou de borda do Azure Local. Para aprimorar os recursos da plataforma, o Azure Local integra-se ao Azure Arc e a outros serviços do Azure que fornecem recursos de suporte. O Azure Local fornece uma plataforma resiliente para implantar, gerenciar e operar aplicativos de usuário ou sistemas de negócios. Os recursos e serviços da plataforma são descritos nas seções a seguir.

Recursos da plataforma

A arquitetura requer os seguintes recursos e componentes obrigatórios:

  • O Azure Local é uma solução de HCI (infraestrutura hiperconvergente) implantada localmente ou em locais de borda usando hardware de servidor físico e infraestrutura de rede. O Azure Local fornece uma plataforma para implantar e gerenciar cargas de trabalho virtualizadas, como VMs, clusters kubernetes e outros serviços habilitados pelo Azure Arc. As instâncias locais do Azure podem ser dimensionadas de uma implantação de computador único para no máximo dezesseis máquinas físicas usando categorias de hardware validadas, integradas ou premium fornecidas por parceiros OEM (fabricantes de equipamentos originais).

  • O Azure Arc é um serviço baseado em nuvem que estende o modelo de gerenciamento com base no Azure Resource Manager para o Azure Local e outros locais que não são do Azure. O Azure Arc usa o Azure como o plano de controle e gerenciamento para habilitar o gerenciamento de vários recursos, como VMs, clusters kubernetes e serviços de aprendizado de máquina e dados em contêineres.

  • a do Azure Key Vault é um serviço de nuvem que você pode usar para armazenar e acessar segredos com segurança. Um segredo é tudo o que você deseja restringir firmemente o acesso, como chaves de API, senhas, certificados, chaves criptográficas, credenciais de administrador local e chaves de recuperação do BitLocker.

  • Testemunha de nuvem é um recurso que usa o Armazenamento do Azure para atuar como um quorum de cluster de failover. O Azure Local (somente duas instâncias de computador) usa uma testemunha de nuvem como o quorum para votação, o que garante alta disponibilidade para o cluster. A conta de armazenamento e a configuração de testemunha são criadas durante o processo de implantação de nuvem local do Azure.

  • O Gerenciador de Atualizações é um serviço unificado projetado para gerenciar e controlar as atualizações do Azure Local. Você pode usar o Gerenciador de Atualizações para gerenciar cargas de trabalho implantadas no Azure Local, incluindo a conformidade de atualização do sistema operacional convidado para VMs Windows e Linux que podem ser habilitadas usando a política do Azure. Essa abordagem unificada simplifica o gerenciamento de patch no Azure, ambientes locais e outras plataformas de nuvem por meio de um único painel.

Recursos de suporte à plataforma

A arquitetura inclui os seguintes serviços opcionais de suporte para aprimorar os recursos da plataforma:

  • O Monitor é um serviço baseado em nuvem para coletar, analisar e agir em logs de diagnóstico e telemetria de suas cargas de trabalho locais e de nuvem. Você pode usar o Monitor para maximizar a disponibilidade e o desempenho de seus aplicativos e serviços por meio de uma solução de monitoramento abrangente. Implante o Insights para o Azure Local para simplificar a criação da regra de coleta de dados monitor (DCR) e habilite rapidamente o monitoramento de instâncias locais do Azure.

  • O Azure Policy é um serviço que avalia os recursos locais e do Azure. O Azure Policy avalia os recursos por meio da integração com o Azure Arc usando as propriedades desses recursos às regras de negócios, chamadas definições de política, para determinar a conformidade ou os recursos que você pode usar para aplicar a Configuração de Convidado da VM usando as configurações de política.

  • Defender para Nuvem é um sistema abrangente de gerenciamento de segurança de infraestrutura. Ele aprimora a postura de segurança de seus datacenters e fornece proteção avançada contra ameaças para cargas de trabalho híbridas, sejam elas que residem no Azure ou em outros lugares e em ambientes locais.

  • O Backup do Azure é um serviço baseado em nuvem que fornece uma solução segura e econômica para fazer backup de seus dados e recuperá-los da Nuvem da Microsoft. O Servidor de Backup do Azure é usado para fazer backup de VMs implantadas no Azure Local e armazená-las no serviço de Backup.

  • O Site Recovery é um serviço de recuperação de desastre que fornece recursos de BCDR, permitindo que aplicativos de negócios e cargas de trabalho façam failover se houver um desastre ou interrupção. O Site Recovery gerencia a replicação e o failover de cargas de trabalho executadas em servidores físicos e VMs entre seu site primário (local) e um local secundário (Azure).

Opções de design de cluster

É importante entender os requisitos de desempenho e resiliência da carga de trabalho ao projetar uma instância local do Azure. Esses requisitos incluem RTO (objetivo de tempo de recuperação) e tempos de RPO (objetivo de ponto de recuperação), CPU (computação), memória e requisitos de armazenamento para todas as cargas de trabalho implantadas na instância local do Azure. Várias características da carga de trabalho afetam o processo de tomada de decisão e incluem:

  • Recursos de arquitetura de CPU (unidade de processamento central), incluindo recursos de tecnologia de segurança de hardware, o número de CPUs, a frequência de GHz (velocidade) e o número de núcleos por soquete de CPU.

  • Requisitos de GPU (unidade de processamento gráfico) da carga de trabalho, como ia ou machine learning, inferência ou renderização de gráficos.

  • A memória por computador ou a quantidade de memória física necessária para executar a carga de trabalho.

  • O número de computadores físicos na instância que são de 1 a 16 computadores em escala. O número máximo de computadores físicos é quatro quando você usa a arquitetura de rede sem comutador de armazenamento.

    • Para manter a resiliência da computação, você precisa reservar pelo menos N+1 máquinas físicas no valor da capacidade na instância. Essa estratégia permite a drenagem de nós para atualizações ou recuperação de interrupções repentinas, como interrupções de energia ou falhas de hardware.

    • Para cargas de trabalho críticas ou críticas aos negócios, considere reservar máquinas físicas N+2 no valor da capacidade para aumentar a resiliência. Por exemplo, se dois computadores físicos na instância estiverem offline, a carga de trabalho poderá permanecer online. Essa abordagem fornece resiliência para cenários em que um computador que está executando uma carga de trabalho fica offline durante um procedimento de atualização planejado e resulta em máquinas físicas de duas instâncias sendo offline simultaneamente.

  • Requisitos de resiliência, capacidade e desempenho do armazenamento:

    • Resiliência: recomendamos que você implante três ou mais computadores físicos para habilitar o espelhamento de três vias, que fornece três cópias dos dados, para a infraestrutura e os volumes de usuário. O espelhamento de três vias aumenta o desempenho e a confiabilidade máxima para o armazenamento.

    • Capacidade: O armazenamento utilizável total necessário após a tolerância a falhas ou cópias é levado em consideração. Esse número é aproximadamente 33% do espaço de armazenamento bruto dos discos da camada de capacidade quando você usa espelhamento de três vias.

    • Desempenho: IOPS (operações de entrada/saída por segundo) da plataforma que determina os recursos de taxa de transferência de armazenamento para a carga de trabalho quando multiplicado pelo tamanho do bloco do aplicativo.

Para projetar e planejar uma implantação local do Azure, recomendamos que você use a ferramenta de dimensionamento local do Azure e crie um Novo Projeto para dimensionar suas instâncias locais do Azure. Usar a ferramenta de dimensionamento requer que você entenda seus requisitos de carga de trabalho. Ao considerar o número e o tamanho das VMs de carga de trabalho executadas em sua instância, considere fatores como o número de vCPUs, os requisitos de memória e a capacidade de armazenamento necessária para as VMs.

A seção Preferências da ferramenta de dimensionamento orienta você por meio de perguntas relacionadas ao tipo de sistema (Premier, Sistema Integrado ou Nó Validado) e opções de família de CPU. Ele também ajuda você a selecionar seus requisitos de resiliência para a instância. Certifique-se de:

  • Reserve um mínimo de máquinas físicas N+1 de capacidade (ou um nó) em toda a instância. Isso garante que você possa aplicar atualizações de solução (drenando e reiniciando cada nó, um por um), sem incorrer em tempo de inatividade da carga de trabalho.

  • Reserve máquinas físicas N+2 no valor da capacidade em toda a instância para resiliência adicional. Essa opção permite que o sistema resista a uma falha de computador durante uma atualização ou outro evento inesperado que afeta dois computadores simultaneamente. Ele também garante que haja capacidade suficiente na instância para que a carga de trabalho seja executada nos computadores online restantes.

Esse cenário requer o uso de espelhamento de três vias para volumes de usuário, que é o padrão para instâncias que têm três ou mais computadores físicos.

A saída da ferramenta de dimensionamento local do Azure é uma lista de SKUs de solução de hardware recomendadas que podem fornecer os requisitos de capacidade de carga de trabalho e resiliência de plataforma necessários com base nos valores de entrada no Projeto Sizer. Para obter mais informações sobre soluções de parceiros de hardware OEM disponíveis, consulte catálogo de soluções locais do Azure. Para ajudar a dar direitos a SKUs de solução para atender às suas necessidades, entre em contato com seu provedor de solução de hardware preferencial ou parceiro de SI (integração do sistema).

Unidades de disco físico

Espaços de Armazenamento Diretos dá suporte a vários tipos de unidade de disco físico que variam em desempenho e capacidade. Ao projetar uma instância local do Azure, trabalhe com o parceiro OEM de hardware escolhido para determinar os tipos de unidade de disco físico mais apropriados para atender aos requisitos de capacidade e desempenho da carga de trabalho. Exemplos incluem hdds (unidades de disco rígido) giradas ou SSDs (unidades de estado sólido) e unidades NVMe. Essas unidades geralmente são chamadas de unidades flash ou armazenamento de memória persistente (PMem), que é conhecido como SCM (memória de classe de armazenamento).

A confiabilidade da plataforma depende do desempenho de dependências críticas da plataforma, como tipos de disco físico. Escolha os tipos de disco corretos para seus requisitos. Use soluções de armazenamento all-flash, como unidades NVMe ou SSD para cargas de trabalho que têm requisitos de alto desempenho ou baixa latência. Essas cargas de trabalho incluem, mas não estão limitadas a tecnologias de banco de dados altamente transacionais, clusters aks de produção ou quaisquer cargas de trabalho críticas ou críticas aos negócios que tenham requisitos de armazenamento de baixa latência ou alta taxa de transferência. Use implantações flash para maximizar o desempenho do armazenamento. All-NVMe unidade ou configurações de unidade SSD, especialmente em pequena escala, melhoram a eficiência de armazenamento e maximizam o desempenho porque nenhuma unidade é usada como uma camada de cache. Para obter mais informações, consulte de armazenamento baseado em flash.

Diagrama que mostra uma arquitetura de armazenamento de instância local do Azure de vários nós para uma solução de armazenamento híbrido, usando unidades NVMe como a camada de cache e unidades SSD para capacidade.

O desempenho do armazenamento do cluster é influenciado pelo tipo de unidade de disco físico, que varia de acordo com as características de desempenho de cada tipo de unidade e o mecanismo de cache escolhido. O tipo de unidade de disco físico é parte integrante de qualquer design e configuração dos Espaços de Armazenamento Diretos. Dependendo dos requisitos de carga de trabalho local do Azure e das restrições de orçamento, você pode optar por maximizar o desempenho, maximizar a capacidade ou implementar uma configuração de tipo de unidade mista que equilibra o desempenho e a capacidade.

Para cargas de trabalho de uso geral que exigem armazenamento persistente de grande capacidade, uma configuração de armazenamento híbrido poderia fornecer o armazenamento mais utilizável, como usar unidades NVMe ou SSDs para a camada de cache e unidades HDDs para capacidade. A desvantagem é que as unidades giratórias têm capacidades de desempenho/transferência inferiores em comparação com unidades flash, o que pode afetar o desempenho do armazenamento se a carga de trabalho exceder o conjunto de trabalho de cache , e os HDDs têm um tempo médio menor entre o valor da falha em comparação com as unidades NVMe e SSD.

Os Espaços de Armazenamento Diretos fornecem uma interna, persistente, em tempo real, leitura, gravação e cache do lado do servidor que maximiza o desempenho do armazenamento. O cache deve ser dimensionado e configurado para acomodar o conjunto de trabalho de seus aplicativos e cargas de trabalho. Os discos virtuais diretos de espaços de armazenamento, ou volumes, são usados em combinação com o cache de leitura na memória CSV (volume compartilhado de cluster) para melhorar o desempenho Hyper-V, especialmente para acesso de entrada não permitido ao VHD (disco rígido virtual) da carga de trabalho ou arquivos VHDX (disco rígido virtual v2).

Tip

Para cargas de trabalho de alto desempenho ou sensíveis à latência, recomendamos que você use uma configuração de armazenamento all-flash (todos os NVMe ou todos os SSD) e um tamanho de cluster de três ou mais computadores físicos. Implantar esse design com a configuração de armazenamento padrão configurações usa de espelhamento de três vias para os volumes de infraestrutura e de usuário. Essa estratégia de implantação fornece o maior desempenho e resiliência. Ao usar uma configuração all-NVMe ou all-SSD, você se beneficia da capacidade total de armazenamento utilizável de cada unidade flash. Ao contrário das configurações híbridas ou mistas de NVMe + SSD, não há capacidade reservada para cache ao usar um único tipo de unidade. Isso garante a utilização ideal dos recursos de armazenamento. Para obter mais informações sobre como equilibrar o desempenho e a capacidade para atender aos requisitos de carga de trabalho, consulte Planejar volumes – quando o desempenho é mais importante.

Design de rede

O design de rede é a disposição geral dos componentes dentro da infraestrutura física e das configurações lógicas da rede. Você pode usar as mesmas portas nic (placa de interface de rede) físicas para todas as combinações de intenções de rede de gerenciamento, computação e armazenamento. Usar as mesmas portas NIC para todas as finalidades relacionadas à intenção é chamado de configuração de rede totalmente convergida.

Embora haja suporte para uma configuração de rede totalmente convergida, a configuração ideal para desempenho e confiabilidade é para a intenção de armazenamento usar portas de adaptador de rede dedicadas. Portanto, essa arquitetura de linha de base fornece diretrizes de exemplo para como implantar uma instância local do Azure de vários nós usando a arquitetura de rede comutada de armazenamento com duas portas de adaptador de rede convergidas para intenções de gerenciamento e computação e duas portas de adaptador de rede dedicadas para a intenção de armazenamento. Para obter mais informações, consulte Considerações de rede para implantações de nuvem do Azure Local.

Essa arquitetura requer dois ou mais computadores físicos e até um máximo de 16 computadores em escala. Cada computador requer quatro portas de adaptador de rede conectadas a dois comutadores ToR (Top-of-Rack). Os dois comutadores ToR devem ser interconectados por meio de links MLAG (grupo de agregação de link de vários chassis). As duas portas do adaptador de rede que são usadas para o tráfego de intenção de armazenamento devem dar suporte rdma (acesso remoto direto à memória). Essas portas exigem uma velocidade mínima de vínculo de 10 Gbps, mas recomendamos uma velocidade de 25 Gbps ou superior. As duas portas do adaptador de rede usadas para as intenções de gerenciamento e computação são convergidas usando a tecnologia SET (comutador de agrupamento inserido). A tecnologia SET fornece funcionalidades de redundância de vínculo e balanceamento de carga. Essas portas exigem uma velocidade mínima de vínculo de 1 Gbps, mas recomendamos uma velocidade de 10 Gbps ou superior.

Topologia de rede física

A topologia de rede física a seguir mostra as conexões de rede física entre os computadores locais do Azure e os componentes de rede.

Você precisa dos seguintes componentes ao criar um armazenamento de vários nós que alternou a implantação local do Azure que usa essa arquitetura de linha de base:

Diagrama que mostra a topologia de rede física para uma instância local do Azure de vários nós que usa uma arquitetura comutada de armazenamento com comutadores ToR duplos.

  • Comutadores de ToR Duplo:

    • Os comutadores de rede de ToR duplo são necessários para resiliência de rede e a capacidade de atender ou aplicar atualizações de firmware aos comutadores sem incorrer em tempo de inatividade. Essa estratégia impede um único ponto de falha (SPoF).

    • Os comutadores ToR duplos são usados para o tráfego de armazenamento ou leste-oeste. Essas opções usam duas portas Ethernet dedicadas que têm VLANs (redes locais virtuais) de armazenamento específicas e classes de tráfego PFC (controle de fluxo de prioridade) definidas para fornecer comunicação RDMA sem perdas.

    • Esses comutadores se conectam aos computadores físicos por meio de cabos Ethernet.

  • Dois ou mais computadores físicos e até um máximo de 16 computadores físicos:

    • Cada computador é um servidor físico que executa o sistema operacional Azure Stack HCI.

    • Cada computador requer quatro portas de adaptador de rede no total: duas portas compatíveis com RDMA para armazenamento e duas portas de adaptador de rede para gerenciamento e tráfego de computação.

    • O armazenamento usa as duas portas dedicadas do adaptador de rede compatíveis com RDMA que se conectam com um caminho para cada uma das duas opções de ToR. Essa abordagem fornece redundância de caminho de link e largura de banda priorizada dedicada para tráfego de armazenamento SMB Direct.

    • O gerenciamento e a computação usam duas portas de adaptador de rede que fornecem um caminho para cada uma das duas opções de ToR para redundância de caminho de link.

  • Conectividade externa:

    • Os comutadores Der Duplo se conectam à rede externa, como sua LAN corporativa interna, para fornecer acesso às URLs de saída necessárias usando seu dispositivo de rede de borda de borda de borda. Esse dispositivo pode ser um firewall ou roteador. Isso alterna o tráfego de rota que entra e sai da instância local do Azure ou do tráfego norte-sul.

    • A conectividade de tráfego norte-sul externo dá suporte às intenções de computação e intenção de gerenciamento de cluster. Isso é feito usando duas portas de comutador e duas portas de adaptador de rede por computador que são convergidas por meio do SET (comutador integrado) e um comutador virtual dentro de Hyper-V para garantir a resiliência. Esses componentes funcionam para fornecer conectividade externa para VMs locais do Azure e outros recursos de carga de trabalho implantados nas redes lógicas criadas no Resource Manager usando o portal do Azure, a CLI ou os modelos de IaC.

Topologia de rede lógica

A topologia de rede lógica mostra uma visão geral de como os dados de rede fluem entre dispositivos, independentemente de suas conexões físicas.

Um resumo da configuração lógica para essa arquitetura de linha de base comutada de armazenamento de vários nós para o Azure Local é o seguinte:

Diagrama que mostra a topologia de rede lógica para uma instância local do Azure de vários nós usando a arquitetura comutada de armazenamento com comutadores ToR duplos.

  • Comutadores de ToR Duplo:

    • Antes de implantar o cluster, os dois comutadores de rede ToR precisam ser configurados com as IDs de VLAN necessárias, as configurações máximas de unidade de transmissão e a configuração de ponte do datacenter para as portas de gerenciamento, computação e armazenamento . Para obter mais informações, consulte Requisitos de rede física para aLocal do Azure ou peça assistência ao fornecedor de hardware ou parceiro SI.

  • O Azure Local usa a abordagem do Network ATC para aplicar a automação de rede e a configuração de rede baseada em intenção.

    • A ATC de rede foi projetada para garantir a configuração de rede ideal e o fluxo de tráfego usando intenções de tráfego de rede. A ATC de rede define quais portas de adaptador de rede física são usadas para as diferentes intenções de tráfego de rede (ou tipos), como para o gerenciamento de cluster, computação de carga de trabalho e intenções de armazenamento de cluster.

    • As políticas baseadas em intenção simplificam os requisitos de configuração de rede automatizando a configuração de rede do computador com base em entradas de parâmetro especificadas como parte do processo de implantação de nuvem local do Azure.

  • Comunicação externa:

    • Quando os computadores físicos ou a carga de trabalho precisam se comunicar externamente acessando a LAN corporativa, a Internet ou outro serviço, eles roteam usando os comutadores tor duplos. Esse processo é descrito na seção anterior topologia de rede física.

    • Quando as duas opções de ToR atuam como dispositivos de Camada 3, elas lidam com o roteamento e fornecem conectividade além do cluster para o dispositivo de borda de borda, como o firewall ou o roteador.

    • A intenção de rede de gerenciamento usa a interface virtual de equipe SET convergida, que permite que o endereço IP de gerenciamento de cluster e os recursos do plano de controle se comuniquem externamente.

    • Para a intenção de rede de computação, você pode criar uma ou mais redes lógicas no Azure com as IDs de VLAN específicas para seu ambiente. Os recursos de carga de trabalho, como VMs, usam essas IDs para dar acesso à rede física. As redes lógicas usam as duas portas do adaptador de rede física que são convergidas usando uma equipe SET para as intenções de computação e gerenciamento.

  • Tráfego de armazenamento:

    • Os computadores físicos se comunicam entre si usando duas portas de adaptador de rede dedicadas que estão conectadas aos comutadores de ToR para fornecer alta largura de banda e resiliência para o tráfego de armazenamento.

    • As portas de armazenamento SMB1 e SMB2 se conectam a duas redes nãooutable (ou camada 2) separadas. Cada rede tem uma ID de VLAN específica configurada que deve corresponder à configuração de portas de comutador nas IDs de VLAN de armazenamento padrão dos comutadores toR: 711 e 712.

    • Não há nenhum gateway padrão configurado nas duas portas do adaptador de rede de intenção de armazenamento dentro do sistema operacional Azure Stack HCI.

    • Cada nó de cluster pode acessar as funcionalidades dos Espaços de Armazenamento Diretos do cluster, como unidades físicas remotas usadas no pool de armazenamento, discos virtuais e volumes. O acesso a esses recursos é facilitado por meio do protocolo RDMA SMB-Direct nas duas portas dedicadas do adaptador de rede de armazenamento que estão disponíveis em cada computador. O SMB Multichannel é usado para resiliência.

    • Essa configuração fornece velocidade de transferência de dados suficiente para operações relacionadas ao armazenamento, como manter cópias consistentes de dados para volumes espelhados.

Requisitos de comutador de rede

Os comutadores Ethernet devem atender às diferentes especificações exigidas pelo Azure Local e definidos pela Associação de Padrões de Engenheiros Elétricos e Eletrônicos (IEEE SA). Por exemplo, para implantações comutada de armazenamento de vários nós, a rede de armazenamento é usada para RDMA via RoCE v2 ou iWARP. Esse processo requer o IEEE 802.1Qbb PFC para garantir a comunicação sem perdas para a classe de tráfego de armazenamento . Seus comutadores ToR devem fornecer suporte para IEEE 802.1Q para VLANs e IEEE 802.1AB para o Protocolo de Descoberta de Camada de Link.

Se você planeja usar os comutadores de rede existentes para uma implantação local do Azure, examine a lista de padrões e especificações obrigatórias do IEEE que os comutadores de rede e a configuração devem fornecer. Ao comprar novos comutadores de rede, examine a lista de modelos de comutador certificados pelo fornecedor de hardware que dão suporte aos requisitos de rede locais do Azure.

Requisitos de endereço IP

Em uma implantação com comutada de armazenamento de vários nós, o número de endereços IP necessários aumenta com a adição de cada computador físico, até um máximo de 16 computadores físicos em um único cluster. Por exemplo, para implantar uma configuração comutada de armazenamento de dois nós do Azure Local, a infraestrutura do cluster requer um mínimo de 11 x endereços IP a serem alocados. Mais endereços IP serão necessários se você usar a micro segmentação ou a rede definida pelo software. Para obter mais informações, consulte Examinar os requisitos de endereço IP padrão de referência de armazenamento de dois nós para oLocal do Azure.

Ao projetar e planejar os requisitos de endereço IP para o Azure Local, lembre-se de considerar endereços IP adicionais ou intervalos de rede necessários para sua carga de trabalho além dos necessários para a instância local do Azure e os componentes de infraestrutura. Se você planeja implantar o AKS no Azure Local, consulte AKS habilitado pelos requisitos de rede do Azure Arc.

Conectividade de rede de saída

É importante entender os requisitos de conectividade de rede de saída do Azure Local e fatorar esses requisitos em seu plano de design e implementação antes de implantar a solução. A conectividade de rede de saída é necessária para permitir que o Azure Local se comunique com o Azure e o Azure Arc para operações de plano de gerenciamento e controle. Por exemplo, para fornecer a capacidade de provisionar recursos habilitados para Azure Arc, como VMs locais do Azure ou clusters DO AKS, além de usar serviços de gerenciamento do Azure, como o Azure Update Manager e o Azure Monitor.

O planejamento inicial e a devida diligência de como você habilitará a comunicação de rede com os pontos de extremidade públicos necessários são extremamente importantes se você estiver integrando o Azure Local a uma rede de datacenter local existente. Especialmente se você tiver regras de saída estritas configuradas em seu proxy e/ou dispositivos de firewall, ou se você estiver usando "tecnologias de inspeção SSL" como parte de seus controles de segurança de rede existentes, porque a inspeção SSL não tem suporte para a comunicação de rede local do Azure.

Por que a conectividade de rede de saída é tão importante?

A conectividade de rede de saída é necessária da instância local do Azure, isso inclui os computadores físicos, o dispositivo ARB (ponte de recursos arc ), os clusters do AKS e as VMs locais do Azure se estiverem usando o Azure Arc para gerenciamento de so convidado da VM. Esses dispositivos têm agentes locais ou serviços que se conectam aos pontos de extremidade públicos usando o acesso à rede de saída para comunicação em tempo real, isso fornece conectividade com os provedores de recursos do plano de gerenciamento/controle executados no Azure. Por exemplo, a conectividade é necessária para que os operadores possam usar o portal do Azure, a CLI do Azure ou um modelo ARM, Bicep ou Terraform para provisionar e/ou gerenciar VMs locais do Azure e clusters AKS habilitados para Arc. O Azure e a ponte de recursos arc funcionam em combinação com o recurso de localização personalizada da instância local do Azure, permitindo que você direcione a instância local do Azure específica para qualquer operação CRUD de recurso (criar, ler, atualizar ou excluir) para seus recursos de carga de trabalho habilitados para Arc.

Para habilitar a conectividade normalmente envolve a configuração da tecnologia de firewall, proxy e/ou saída da Internet para permitir o acesso de saída aos pontos de extremidade públicos necessários. Principais considerações para os requisitos de rede de saída local do Azure:

  • O Azure Local não dá suporte à inspeção de pacotes SSL/TLS ao longo de qualquer um dos caminhos de rede das instâncias locais do Azure para os pontos de extremidade públicos. Além disso, não há suporte para a rota de Link Privado e Express para a conectividade com os pontos de extremidade públicos necessários. Para obter informações detalhadas, consulte os requisitos de firewall para o Azure Local.

  • Considere usar o gateway do Azure Arc para simplificar os requisitos de conectividade, pois isso reduz significativamente o número de pontos de extremidade necessários que precisam ser adicionados às regras de firewall ou proxy para a implantação e o gerenciamento do Azure Local.

  • Ao implantar o Azure Local usando um Servidor Proxy para controlar e gerenciar o acesso à saída da Internet, examine os requisitos de Proxy

Monitoring

Para aprimorar o monitoramento e alertas, habilite Monitorar Insights no Azure Local. Os insights podem ser dimensionados para monitorar e gerenciar várias instâncias locais usando uma experiência consistente do Azure. O Insights usa contadores de desempenho de cluster e canais de log de eventos para monitorar os principais recursos locais do Azure. Os logs são coletados pelo DCR configurado por meio do Monitor e do Log Analytics.

O Insights do Azure Local é criado usando o Monitor e o Log Analytics, o que garante uma solução sempre up-todata e escalonável altamente personalizável. O Insights fornece acesso a pastas de trabalho padrão com métricas básicas, juntamente com pastas de trabalho especializadas criadas para monitorar os principais recursos do Azure Local. Esses componentes fornecem uma solução de monitoramento quase em tempo real e permitem a criação de grafos, a personalização de visualizações por meio da agregação e filtragem e a configuração de regras de alerta de integridade de recursos personalizadas.

Gerenciamento de atualizações

As instâncias locais do Azure e os recursos de carga de trabalho implantados, como VMs locais do Azure, precisam ser atualizados e corrigidos regularmente. Aplicando atualizações regularmente, você garante que sua organização mantenha uma postura de segurança forte e melhore a confiabilidade geral e a capacidade de suporte de seu patrimônio. Recomendamos que você use avaliações manuais automáticas e periódicas para descoberta antecipada e aplicação de patches de segurança e atualizações do sistema operacional.

Atualizações de infraestrutura

O Azure Local é atualizado continuamente para melhorar a experiência do cliente e adicionar novos recursos e funcionalidades. Esse processo é gerenciado por meio de trens de lançamento, que fornecem atualizações de recursos a cada seis meses, elas são lançadas em abril (YY04) e outubro (YY10). Além das atualizações regulares de recursos, o Azure Local é atualizado com atualizações cumulativas mensais que incluem atualizações de segurança e confiabilidade do sistema operacional, além de extensões e atualizações de agente.

O Gerenciador de Atualizações é um serviço do Azure que você pode usar para aplicar, exibir e gerenciar atualizações para o Azure Local. Esse serviço fornece um mecanismo para exibir todas as instâncias locais do Azure em toda a sua infraestrutura e locais de borda usando o portal do Azure para fornecer uma experiência de gerenciamento centralizada. Para obter mais informações, consulte os seguintes recursos:

É importante verificar se há atualizações de driver e firmware regularmente, como a cada três ou seis meses. Se você usar uma versão de categoria de solução Premier para o hardware local do Azure, as atualizações do pacote de extensão do Construtor de Soluções serão integradas ao Gerenciador de Atualizações para fornecer uma experiência de atualização simplificada. Se você usar nós validados ou uma categoria de Sistema Integrado, talvez haja um requisito para baixar e executar um pacote de atualização específico do OEM que contenha as atualizações de firmware e driver para seu hardware. Para determinar como as atualizações são fornecidas para seu hardware, entre em contato com seu parceiro OEM ou SI de hardware.

Aplicação de patch do sistema operacional convidado da carga de trabalho

Você pode registrar VMs locais do Azure implantadas no Azure Local no AUM (Azure Update Manager) para fornecer uma experiência unificada de gerenciamento de patch usando o mesmo mecanismo usado para atualizar os computadores físicos da instância local do Azure. Você pode usar o AUM para criar configurações de manutenção de convidado . Essas configurações controlam configurações como a reinicialização da configuração de reinicialização, se necessário, o agendamento (datas, horários e opções de repetição) e uma lista dinâmica (assinatura) ou estática das VMs locais do Azure para o escopo. Essas configurações controlam a configuração para quando os patches de segurança do sistema operacional são instalados dentro do sistema operacional convidado da VM de carga de trabalho.

Considerations

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Reliability

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design parade confiabilidade.

Identificar os possíveis pontos de falha

Cada arquitetura é suscetível a falhas. Você pode prever falhas e estar preparado com mitigações com análise de modo de falha. A tabela a seguir descreve quatro exemplos de possíveis pontos de falha nesta arquitetura:

Component Risk Likelihood Effect/mitigation/note Outage
Interrupção da instância local do Azure Falha de energia, rede, hardware ou software Medium Para evitar uma interrupção prolongada do aplicativo causada pela falha de uma instância local do Azure para casos de uso comercial ou crítico, sua carga de trabalho deve ser arquitetada usando princípios de HA e DR. Por exemplo, você pode usar tecnologias de replicação de dados de carga de trabalho padrão do setor para manter várias cópias de dados de estado persistente que são implantadas usando várias VMs locais do Azure ou instâncias do AKS implantadas em instâncias locais do Azure separadas e em locais físicos separados. Possível interrupção.
Interrupção de computador físico único local do Azure Falha de energia, hardware ou software Medium Para evitar uma interrupção prolongada do aplicativo causada pela falha de um único computador local do Azure, sua instância local do Azure deve ter vários computadores físicos. Os requisitos de capacidade de carga de trabalho durante a fase de design do cluster determinam o número de computadores físicos. Recomendamos que você tenha três ou mais computadores físicos. Também recomendamos que você use o espelhamento de três vias, que é o modo de resiliência de armazenamento padrão para clusters com três ou mais computadores físicos. Para evitar um SPoF e aumentar a resiliência da carga de trabalho, implante várias instâncias da carga de trabalho usando duas ou mais VMs locais do Azure ou pods de contêiner que são executados em vários nós de trabalho do AKS. Se um único computador falhar, as VMs locais do Azure e os serviços de carga de trabalho/aplicativo serão reiniciados nos computadores físicos online restantes no cluster. Possível interrupção.
VM local do Azure ou nó de trabalho do AKS (carga de trabalho) Misconfiguration Medium Os usuários do aplicativo não podem entrar ou acessar o aplicativo. As configurações incorretas devem ser capturadas durante a implantação. Se esses erros ocorrerem durante uma atualização de configuração, a equipe do DevOps deverá reverter as alterações. Você pode reimplantar a VM, se necessário. A reimplantação leva menos de 10 minutos para ser implantada, mas pode levar mais tempo de acordo com o tipo de implantação. Possível interrupção.
Conectividade com o Azure Interrupção de rede Medium O Azure Local requer a conectividade de rede com o Azure para que as operações do plano de controle estejam disponíveis. Por exemplo, para a capacidade de provisionar novas VMs locais do Azure ou clusters AKS, instale atualizações de solução usando o Gerenciador de Atualizações do Azure ou monitore o status de integridade da instância usando o Azure Monitor. Se a conectividade com o Azure não estiver disponível, a instância funcionará em um estado degradado, onde esses recursos não estão disponíveis, no entanto, as cargas de trabalho existentes que já estão em execução no Azure Local continuarão a ser executadas. Se a conectividade de rede com o Azure não for restaurada dentro de 30 dias, a instância inserirá um status "Fora de Política", o que pode limitar a funcionalidade. O dispositivo ARB (Azure Resource Bridge) não pode ficar offline por mais de 45 dias, pois isso pode afetar a validade da chave de segurança usada para autenticação. Operações de gerenciamento indisponíveis.

Para obter mais informações, consulte Recomendações para executar a análise do modo de falha.

Destinos de confiabilidade

Esta seção descreve um cenário de exemplo. Um cliente fictício chamado Contoso Manufacturing usa essa arquitetura de referência para implantar o Azure Local. Eles querem atender aos seus requisitos e implantar e gerenciar cargas de trabalho locais. A Contoso Manufacturing tem uma meta de SLO (objetivo de nível de serviço) interna de 99,8% que os stakeholders de negócios e aplicativos concordam com seus serviços.

  • Um SLO de 99,8% tempo de atividade ou disponibilidade resulta nos seguintes períodos de tempo de inatividade permitido, ou indisponibilidade, para os aplicativos implantados usando VMs locais do Azure executadas no Azure Local:

    • Semanalmente: 20 minutos e 10 segundos

    • Mensalmente: 1 hora, 26 minutos e 56 segundos

    • Trimestral: 4 horas, 20 minutos e 49 segundos

    • Anual: 17 horas, 23 minutos e 16 segundos

  • Para ajudar a atender às metas de SLO, a Contoso Manufacturing implementa o princípio de privilégio mínimo (PoLP) para restringir o número de administradores de instância local do Azure a um pequeno grupo de indivíduos confiáveis e qualificados. Essa abordagem ajuda a evitar o tempo de inatividade devido a ações inadvertidas ou acidentais executadas em recursos de produção. Além disso, os logs de eventos de segurança para controladores de domínio do AD DS (Active Directory Domain Services) locais são monitorados para detectar e relatar quaisquer alterações de associação de grupo de contas de usuário, conhecidas como adicionar e remover ações, para o grupo de administradores de instância local do Azure usando uma solução de gerenciamento de eventos de informações de segurança (SIEM). O monitoramento aumenta a confiabilidade e melhora a segurança da solução.

    Para obter mais informações, consulte Recomendações parade gerenciamento de identidade e acesso.

  • Procedimentos estritos de controle de alteração estão em vigor para os sistemas de produção da Contoso Manufacturing. Esse processo requer que todas as alterações sejam testadas e validadas em um ambiente de teste representativo antes da implementação na produção. Todas as alterações enviadas ao processo semanal do conselho consultivo de alterações devem incluir um plano de implementação detalhado (ou link para o código-fonte), pontuação de nível de risco, um plano de reversão abrangente, teste e verificação pós-lançamento e critérios claros de êxito para que uma alteração seja revisada ou aprovada.

    Para obter mais informações, consulte Recomendações para práticas de implantação seguras.

  • patches de segurança mensais e atualizações de linha de base trimestrais são aplicados à instância local do Azure de produção somente após serem validados pelo ambiente de pré-produção. O Gerenciador de Atualizações e o recurso de atualização com reconhecimento de cluster automatizam o processo de uso de migração dinâmica de VM para minimizar o tempo de inatividade para cargas de trabalho críticas para os negócios durante as operações de manutenção mensais. Os procedimentos operacionais padrão da Contoso Manufacturing exigem que as atualizações de segurança, confiabilidade ou build de linha de base sejam aplicadas a todos os sistemas de produção dentro de quatro semanas após a data de lançamento. Sem essa política, os sistemas de produção são perpetuamente incapazes de se manter atualizados com atualizações mensais de sistema operacional e de segurança. Sistemas desatualizados afetam negativamente a confiabilidade e a segurança da plataforma.

    Para obter mais informações, consulte Recomendações para estabelecer uma linha de base de segurança.

  • a Contoso Manufacturing implementa diariamente, backups semanais e mensais manter os últimos 6 x dias de backups diários (segundas a sábados), os últimos 3 x semanais (todos os domingos) e 3 x backups mensais, com cada domingo da semana 4 sendo retidos para se tornarem os backups do mês 1, mês 2 e mês 3 usando uma agenda baseada em calendário documentada e auditável. Essa abordagem atende aos requisitos de Fabricação da Contoso para um equilíbrio adequado entre o número de pontos de recuperação de dados disponíveis e a redução dos custos para o serviço de armazenamento de backup de nuvem ou externo.

    Para obter mais informações, consulte Recomendações para criar uma estratégia de recuperação de desastre.

  • Os processos de backup e recuperação de dados são testados para cada sistema de negócios a cada seis meses. Essa estratégia fornece garantia de que os processos bcdr são válidos e que a empresa está protegida se ocorrer um desastre de datacenter ou incidente cibernético.

    Para obter mais informações, consulte Recomendações para criar uma estratégia de teste de confiabilidade.

  • Os processos e procedimentos operacionais descritos anteriormente no artigo e as recomendações no guia de serviço do Well-Architected Framework para aLocal do Azure, permitem que a Contoso Manufacturing atenda ao seu destino 99.8% SLO e dimensione e gerencie efetivamente as implantações locais e de carga de trabalho do Azure em vários sites de fabricação distribuídos em todo o mundo.

    Para obter mais informações, consulte Recomendações para definir destinos de confiabilidade.

Redundancy

Considere uma carga de trabalho que você implanta em uma única instância local do Azure como um implantação com redundância local. O cluster fornece alta disponibilidade no nível da plataforma, mas você deve implantar o cluster em um único rack. Para casos de uso comercialmente críticos ou críticos, recomendamos implantar várias instâncias de uma carga de trabalho ou serviço em duas ou mais instâncias locais do Azure separadas, idealmente em locais físicos separados.

Use padrões de alta disponibilidade padrão do setor para cargas de trabalho que fornecem replicação ativa/passiva, replicação síncrona ou replicação assíncrona, como SQL Server Always On. Você também pode usar uma tecnologia de NLB (balanceamento de carga de rede externo) que roteia solicitações de usuário entre as várias instâncias de carga de trabalho executadas em instâncias locais do Azure que você implanta em locais físicos separados. Considere usar um dispositivo NLB externo do parceiro. Ou você pode avaliar as opções de balanceamento de carga que dão suporte ao roteamento de tráfego para serviços híbridos e locais, como uma instância do Gateway de Aplicativo do Azure que usa o Azure ExpressRoute ou um túnel VPN para se conectar a um serviço local.

Para obter mais informações, consulte Recomendações para criarde redundância.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design parade segurança.

As considerações de segurança incluem:

  • uma base segura para a plataforma local do Azure: Local do Azure é um produto seguro por padrão que usa componentes de hardware validados com um TPM, UEFI e Inicialização Segura para criar uma base segura para a plataforma local do Azure e a segurança da carga de trabalho. Quando implantado com as configurações de segurança padrão, o Azure Local tem o Controle de Aplicativo, o Credential Guard e o BitLocker habilitados. Para simplificar a delegação de permissões usando o PoLP, use funções de RBAC (controle de acesso baseado em função) internas do Azure Local como Administrador Local do Azure para administradores de plataforma e Colaborador de VM Local do Azure ou Leitor de VM Local do Azure para operadores de carga de trabalho.

  • Configurações de segurança padrão: o padrão de segurança local do Azure aplica as configurações de segurança padrão para sua instância local do Azure durante a implantação e permite que o controle de descompasso mantenha os computadores físicos em um bom estado conhecido. Você pode usar as configurações padrão de segurança para gerenciar a segurança do cluster, o controle de descompasso e as configurações de servidor principal protegidas em seu cluster.

  • Logs de eventos de segurança: o encaminhamento de syslog local do Azure integra-se às soluções de monitoramento de segurança recuperando logs de eventos de segurança relevantes para agregar e armazenar eventos para retenção em sua própria plataforma SIEM.

  • Proteção contra ameaças e vulnerabilidades: Defender para Nuvem protege sua instância local do Azure contra várias ameaças e vulnerabilidades. Esse serviço ajuda a melhorar a postura de segurança do ambiente local do Azure e pode proteger contra ameaças existentes e em evolução.

  • Detecção e correção de ameaças: a Análise Avançada de Ameaças da Microsoft detecta e corrige ameaças, como aquelas direcionadas ao AD DS, que fornecem serviços de autenticação para computadores de instância local do Azure e suas cargas de trabalho de VM do Windows Server.

  • Isolamento de rede: isolar redes, se necessário. Por exemplo, você pode provisionar várias redes lógicas que usam VLANs separadas e intervalos de endereços de rede. Ao usar essa abordagem, verifique se a rede de gerenciamento pode alcançar cada rede lógica e VLAN para que os computadores físicos da instância local do Azure possam se comunicar com as redes VLAN por meio dos comutadores ou gateways do ToR. Essa configuração é necessária para o gerenciamento da carga de trabalho, como permitir que agentes de gerenciamento de infraestrutura se comuniquem com o sistema operacional convidado da carga de trabalho.

    Para obter mais informações, consulte Recomendações para criar uma estratégia de segmentação.

Otimização de custos

A Otimização de Custos trata-se de procurar maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design parade Otimização de Custos.

As considerações sobre otimização de custo incluem:

  • modelo de cobrança no estilo nuvem parade licenciamento: o preço local do Azure segue o modelo de cobrança de assinatura mensal com uma taxa fixa por núcleo de processador físico em uma instância local do Azure. Encargos de uso extra se aplicam se você usar outros serviços do Azure. Se você tiver licenças principais locais para o Windows Server Datacenter Edition com o Software Assurance ativo, poderá optar por trocar essas licenças para ativar a instância local do Azure e as taxas de assinatura de VM do Windows Server.

  • Aplicação automática de patch de convidado de VM para VMs locais do Azure: esse recurso ajuda a reduzir a sobrecarga de patch manual e os custos de manutenção associados. Essa ação não só ajuda a tornar o sistema mais seguro, mas também otimiza a alocação de recursos e contribui para a eficiência geral do custo.

  • Consolidação do monitoramento de custos: para consolidar os custos de monitoramento, use o Azure Local Insights e patch usando o Gerenciador de Atualizações do Azure Local. O Insights usa o Monitor para fornecer métricas avançadas e recursos de alerta. O componente do gerenciador de ciclo de vida do Azure Local integra-se ao Gerenciador de Atualizações para simplificar a tarefa de manter seus clusters atualizados consolidando fluxos de trabalho de atualização para vários componentes em uma única experiência. Use o Monitor e o Gerenciador de Atualizações para otimizar a alocação de recursos e contribuir para a eficiência de custo geral.

    Para obter mais informações, consulte Recomendações para otimizar o tempo de equipe.

  • Capacidade inicial de carga de trabalho ede crescimento: ao planejar sua implantação local do Azure, considere sua capacidade inicial de carga de trabalho, requisitos de resiliência e considerações de crescimento futuros. Considere se o uso de uma arquitetura sem alternância de armazenamento de dois, três ou quatro nós poderia reduzir os custos, como remover a necessidade de adquirir comutadores de rede de classe de armazenamento. A criação de comutadores de rede de classe de armazenamento extra pode ser um componente caro das novas implantações de instância local do Azure. Em vez disso, você pode usar comutadores existentes para redes de gerenciamento e computação, que simplificam a infraestrutura. Se a capacidade de carga de trabalho e as necessidades de resiliência não forem dimensionadas além de uma configuração de quatro nós, considere se você pode usar comutadores existentes para as redes de gerenciamento e computação e use a arquitetura sem alternância de armazenamento para implantar o Azure Local.

    Para obter mais informações, consulte Recomendações para otimizar os custos de componente.

Tip

Você pode economizar em custos com o Benefício Híbrido do Azure se tiver licenças do Datacenter do Windows Server com o Software Assurance ativo. Para obter mais informações, consulte Benefício Híbrido do Azure paraLocal do Azure.

Excelência operacional

A Excelência Operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design parade Excelência Operacional.

As considerações de excelência operacional incluem:

Eficiência de desempenho

A Eficiência de Desempenho é a capacidade da carga de trabalho de atender às demandas colocadas nele pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de design parade Eficiência de Desempenho.

Considerações sobre eficiência de desempenho incluem:

  • de desempenho de armazenamento de carga de trabalho: considere usar a ferramenta DiskSpd para testar os recursos de desempenho de armazenamento de carga de trabalho de uma instância local do Azure. Você pode usar a ferramenta VMFleet para gerar carga e medir o desempenho de um subsistema de armazenamento. Avalie se você deve usar a VMFleet para medir o desempenho do subsistema de armazenamento.

    • Recomendamos estabelecer uma linha de base para o desempenho das instâncias locais do Azure antes de implantar cargas de trabalho de produção. O DiskSpd usa vários parâmetros de linha de comando que permitem que os administradores testem o desempenho de armazenamento do cluster. A função principal do DiskSpd é emitir operações de leitura e gravação e métricas de desempenho de saída, como latência, taxa de transferência e IOPs.

      Para obter mais informações, consulte Recomendações parade teste de desempenho.

  • de resiliência de armazenamento de carga de trabalho: considere os benefícios de resiliência de armazenamento, eficiência de uso (ou capacidade) e desempenho. O planejamento para volumes locais do Azure inclui identificar o equilíbrio ideal entre resiliência, eficiência de uso e desempenho. Você pode achar difícil otimizar esse equilíbrio porque maximizar uma dessas características normalmente tem um efeito negativo em uma ou mais das outras características. Aumentar a resiliência reduz a capacidade utilizável. Como resultado, o desempenho pode variar, dependendo do tipo de resiliência selecionado. Quando a resiliência e o desempenho são a prioridade e quando você usa três ou mais computadores físicos, a configuração de armazenamento padrão emprega espelhamento bidirecional para volumes de infraestrutura e de usuário.

    Para obter mais informações, consulte Recomendações para planejamento de capacidade.

  • de otimização de desempenho de rede: considere a otimização de desempenho de rede. Como parte do seu design, certifique-se de incluir alocação de largura de banda de tráfego de rede projetada ao determinar sua configuração de hardware de rede ideal .

    • Para otimizar o desempenho da computação no Azure Local, você pode usar a aceleração de GPU. A aceleração de GPU é benéfica para cargas de trabalho de IA ou machine learning de alto desempenho que envolvem insights de dados ou inferência. Essas cargas de trabalho exigem implantação em locais de borda devido a considerações como gravidade de dados ou requisitos de segurança. Em uma implantação híbrida ou implantação local, é importante levar em consideração seus requisitos de desempenho de carga de trabalho, incluindo GPUs. Essa abordagem ajuda você a selecionar os serviços certos ao projetar e adquirir suas instâncias locais do Azure.

      Para obter mais informações, consulte Recomendações para selecionar os serviços corretos.

Implantar esse cenário

A seção a seguir fornece uma lista de exemplos das tarefas de alto nível ou do fluxo de trabalho típico usado para implantar o Azure Local, incluindo tarefas e considerações de pré-requisito. Esta lista de fluxos de trabalho destina-se apenas a um guia de exemplo. Não é uma lista completa de todas as ações necessárias, que podem variar de acordo com os requisitos organizacionais, geográficos ou específicos do projeto.

Cenário: há um requisito de caso de uso ou projeto para implantar uma solução de nuvem híbrida em uma localização local ou de borda para fornecer computação local para recursos de processamento de dados e um desejo de usar experiências de gerenciamento e cobrança consistentes com o Azure. Mais detalhes são descritos na seção possíveis casos de uso deste artigo. As etapas restantes pressupõem que o Azure Local é a solução de plataforma de infraestrutura escolhida para o projeto.

  1. Reunir carga de trabalho e requisitos de caso de uso de stakeholders relevantes. Essa estratégia permite que o projeto confirme que os recursos e os recursos do Azure Local atendem aos requisitos de escala, desempenho e funcionalidade da carga de trabalho. Esse processo de revisão deve incluir a compreensão da escala ou do tamanho da carga de trabalho e os recursos necessários, como VMs locais do Azure, AKS, Área de Trabalho Virtual do Azure ou Serviços de Dados habilitados para Azure Arc ou serviço de Machine Learning habilitado para Azure Arc. Os valores RTO e RPO (confiabilidade) da carga de trabalho e outros requisitos não funcionais (escalabilidade de desempenho/carga) devem ser documentados como parte dessa etapa de coleta de requisitos.

  2. Examine a saída do sizer local do Azure para a solução de parceiro de hardware recomendada. Essa saída inclui detalhes da criação e modelo de hardware do servidor físico recomendado, número de computadores físicos e as especificações para a CPU, memória e configuração de armazenamento de cada nó físico necessário para implantar e executar suas cargas de trabalho.

  3. Usar a ferramenta de dimensionamento Azure Local para criar um novo projeto que modele o tipo de carga de trabalho e a escala. Esse projeto inclui o tamanho e o número de VMs e seus requisitos de armazenamento. Esses detalhes são inseridos junto com opções para o tipo de sistema, família de CPU preferencial e seus requisitos de resiliência para alta disponibilidade e tolerância a falhas de armazenamento, conforme explicado na seção anterior opções de design de cluster seção.

  4. Examine a saída do Azure Local Sizer para a solução de parceiro de hardware recomendada. Essa solução inclui detalhes do hardware do servidor físico recomendado (marca e modelo), número de computadores físicos e as especificações para a CPU, memória e configuração de armazenamento de cada nó físico necessário para implantar e executar suas cargas de trabalho.

  5. Entre em contato com o parceiro OEM ou SI de hardware para qualificar ainda mais a adequação da versão de hardware recomendada em comparação com os requisitos de carga de trabalho. Se disponível, use ferramentas de dimensionamento específicas do OEM para determinar os requisitos de dimensionamento de hardware específicos do OEM para as cargas de trabalho pretendidas. Essa etapa normalmente inclui discussões com o parceiro OEM ou SI de hardware para os aspectos comerciais da solução. Esses aspectos incluem aspas, disponibilidade do hardware, tempos de entrega e quaisquer serviços profissionais ou de agregação de valor que o parceiro fornece para ajudar a acelerar os resultados do projeto ou dos negócios.

  6. Implantar dois comutadores ToR parade integração de rede. Para soluções de alta disponibilidade, as instâncias locais do Azure exigem que duas opções de ToR sejam implantadas. Cada computador físico requer quatro NICs, dois dos quais devem ser compatíveis com RDMA, que fornece dois links de cada computador para as duas opções de ToR. Duas NICs, uma conectada a cada comutador, são convergidas para conectividade norte-sul de saída para as redes de computação e gerenciamento. As outras duas NICs compatíveis com RDMA são dedicadas ao tráfego leste-oeste do armazenamento. Se você planeja usar os comutadores de rede existentes, verifique se a criação e o modelo de seus comutadores estão na lista aprovada de comutadores de rede compatíveis com o Azure Local.

  7. Trabalhar com o parceiro OEM ou SI de hardware para organizar a entrega dode hardware. O parceiro SI ou seus funcionários são obrigados a integrar o hardware ao datacenter local ou ao local de borda, como racking e empilhamento do cabeamento de hardware, rede física e unidade de alimentação para os computadores físicos.

  8. executar ode implantação da instância local do Azure. Dependendo da versão da solução escolhida (solução Premier, sistema integrado ou nós validados), o parceiro de hardware, o parceiro si ou seus funcionários podem implantar o software local do Azure. Esta etapa começa integrando os computadores físicos Azure Stack HCI OS em servidores habilitados para Azure Arc e iniciando o processo de implantação de nuvem local do Azure. Clientes e parceiros podem gerar uma solicitação de suporte diretamente com a Microsoft no portal do Azure selecionando o ícone Suporte + Solução de Problemas ou entrando em contato com seu parceiro OEM ou SI de hardware, dependendo da natureza da solicitação e da categoria da solução de hardware.

    Tip

    Logotipo do GitHub A implementação de referência do sistema operacional do Azure Stack HCI, versão 23H2 , demonstra como implantar uma implantação de vários nós comutada do Azure Local usando um modelo do ARM e um arquivo de parâmetro. Como alternativa, o exemplo Bicep demonstra como usar um modelo Bicep para implantar uma instância local do Azure, incluindo seus recursos de pré-requisitos.

  9. Implantar cargas de trabalho altamente disponíveis no Azure Local usando modelos do Azure Portal, CLI ou ARM + Azure Arc para automação. Use o recurso de localização personalizado da nova instância local do Azure como a região de destino ao implantar recursos de carga de trabalho, como VMs locais do Azure, AKS, hosts de sessão da Área de Trabalho Virtual do Azure ou outros serviços habilitados para Azure Arc que você pode habilitar por meio de extensões do AKS e contêinerização no Azure Local.

  10. Instalar atualizações mensais para melhorar a segurança e a confiabilidade da plataforma. Para manter suas instâncias locais do Azure atualizadas, é importante instalar atualizações de software da Microsoft e atualizações de firmware e driver OEM de hardware. Essas atualizações melhoram a segurança e a confiabilidade da plataforma. O Gerenciador de Atualizações aplica as atualizações e fornece uma solução centralizada e escalonável para instalar atualizações em um único cluster ou vários clusters. Verifique com seu parceiro OEM de hardware para determinar o processo de instalação de atualizações de firmware e driver de hardware, pois esse processo pode variar dependendo do tipo de categoria de solução de hardware escolhido (solução Premier, sistema integrado ou nós validados). Para obter mais informações, consulte Atualizações de infraestrutura.

Próximas etapas

Documentação do produto:

Documentação do produto para obter detalhes sobre serviços específicos do Azure:

Módulos do Microsoft Learn: