Esta arquitetura de referência de linha de base fornece orientações e recomendações independentes da carga de trabalho para configurar a infraestrutura do Azure Local, versão 23H2, versão 2311 e posterior, para garantir uma plataforma confiável que possa implantar e gerenciar cargas de trabalho virtualizadas e conteinerizadas altamente disponíveis. Essa arquitetura descreve os componentes de recursos e as opções de design de cluster para os nós 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 agilizar o gerenciamento diário do Azure Local.
Para obter mais informações sobre padrões de arquitetura de carga de trabalho otimizados para execução no Azure Local, consulte o conteúdo localizado no menu de navegação cargas de trabalho
Essa arquitetura é um ponto de partida para como usar o design de rede comutada de armazenamento para implantar uma instância local do Azure com 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 arquitetados devem ser implantados usando várias instâncias ou alta disponibilidade de quaisquer serviços de carga de trabalho críticos e ter controles BCDR (Business Continuity and Disaster Recovery) apropriados. Esses controles BCDR incluem backups regulares e recursos de failover de recuperação de desastres. Para se concentrar na plataforma de infraestrutura HCI, esses aspetos de design de carga de trabalho são intencionalmente excluídos 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
Arquitetura | Decisões de conceção | Well-Architected Abordagem do quadro |
---|---|---|
▪ Arquitetura ▪ Casos de uso potenciais ▪ Detalhes do cenário ▪ Recursos da plataforma ▪ Recursos de suporte à plataforma ▪ Implantar este cenário |
▪ Opções de design de cluster ▪ Unidades de disco físicas ▪ Design de rede ▪ Monitorização ▪ Gerenciamento de atualizações |
▪ Fiabilidade ▪ Segurança ▪ Otimização de custos ▪ Excelência operacional ▪ Eficiência de desempenho |
Dica
O modelo local do Azure demonstra como usar um modelo de Gerenciamento de Recursos do Azure (modelo ARM) e um arquivo de parâmetro para implantar uma implantação multisservidor 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.
Arquitetura
Para obter mais informações, consulte Recursos relacionados.
Casos de uso potenciais
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, o que fornece uma solução para atender aos requisitos de carga de trabalho. É possível:
Forneça uma solução de nuvem híbrida implantada no local para atender aos requisitos de soberania, regulamentação e conformidade de dados ou latência.
Implante e gerencie cargas de trabalho de borda virtualizadas por HA ou baseadas em contêiner que são implantadas em um único local ou em vários locais. Essa estratégia permite que aplicativos e serviços críticos para os negócios operem de forma resiliente, econômica e escalável.
Reduza o custo total de propriedade (TCO) usando soluções certificadas pela Microsoft, implantação baseada em nuvem, gerenciamento centralizado e monitoramento e alertas.
Forneça um recurso de provisionamento centralizado usando o Azure e o Azure Arc para implantar cargas de trabalho em vários locais de forma consistente e segura. Ferramentas como o portal do Azure, a CLI do Azure ou modelos de infraestrutura como código (IaC) usam o Kubernetes para conteinerização ou virtualização de carga de trabalho tradicional para impulsionar a automação e a repetibilidade.
Cumpra requisitos rigorosos de segurança, conformidade e auditoria. O Azure Local é implantado com uma postura de segurança reforçada configurada por padrão ou seguro por padrão. O Azure Local incorpora hardware certificado, Inicialização Segura, TPM (Trusted Platform Module), segurança baseada em virtualização (VBS), Credential Guard e políticas de Controle de Aplicativo do Windows Defender impostas. Ele também se integra com serviços modernos de segurança e gerenciamento de ameaças baseados em nuvem, como o Microsoft Defender for Cloud e o Microsoft Sentinel.
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 exemplos de tipos de recursos de carga de trabalho que você pode implantar no Azure Local.
Usar o Azure Arc com o Azure Local
O Azure Local integra-se diretamente com o 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 do componente da ponte de recursos do
Você pode implantar recursos de carga de trabalho, como de máquinas virtuais (VMs) do Azure Arc, do Serviço de Kubernetes do Azure habilitado para Arco (AKS) e hosts de sessão da Área de Trabalho Virtual do Azure que usam o portal do Azure selecionando um local personalizado de instância local do Azure como destino para a implantação da carga de trabalho. Esses componentes fornecem administração, gerenciamento e suporte centralizados. 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 ao Azure Local, VMs do Windows Server e clusters AKS. Essa otimização ajuda a gerenciar os custos de forma eficaz para esses serviços.
A integração do Azure e do Azure Arc estende os recursos das cargas de trabalho virtualizadas e conteinerizadas do Azure Local para incluir:
VMs do Azure Arc para aplicativos ou serviços tradicionais executados em VMs no Azure Local.
AKS no Azure Local para aplicativos ou serviços em contêineres que se beneficiam do uso do Kubernetes como sua plataforma de orquestração.
de Área de Trabalho Virtual do Azure para 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 Arco do Azure para Instância Gerenciada SQL do Azure em contêiner ou um Banco de Dados do Azure para servidor PostgreSQL que usa AKS habilitado para Azure Arc hospedado no Azure Local.
O extensão de Grade de Eventos do Azure habilitada para Arco do Azure para Kubernetes implantar o agente de Grade de Eventos do e o operador de Grade de Eventos componentes. Essa implantação habilita recursos como tópicos da Grade de Eventos e assinaturas para processamento de eventos.
de aprendizado de máquina habilitado para Arco do Azure com um cluster 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 aprendizado de máquina na borda.
As cargas de trabalho conectadas ao Azure Arc fornecem consistência e automação aprimoradas do Azure para implantações do Azure Local, como automatizar a configuração do SO convidado com extensões de VM do Azure Arc ou avaliar a conformidade com regulamentos do setor ou padrões corporativos por meio de Política do Azure. Você pode ativar a Política do Azure por meio do portal do Azure ou da automação do 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 profunda 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, manufatura e escritórios remotos apresentam desafios exclusivos de segurança e conformidade. Proteger as cargas de trabalho contra ameaças internas e externas é crucial em ambientes com suporte de TI limitado 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 pelo Azure Local garante suporte interno à Inicialização Segura, UEFI (Interface de Firmware Extensível Unificada) e TPM. Use essas tecnologias em combinação com VBS para ajudar a proteger suas cargas de trabalho sensíveis à segurança. Você pode usar a Criptografia de Unidade de Disco BitLocker para criptografar volumes de disco de inicialização e espaços de armazenamento direcionam volumes em repouso. A criptografia SMB (Server Message Block) fornece criptografia automática do tráfego entre servidores no cluster (na rede de armazenamento) e assinatura do tráfego SMB entre os nós do cluster e outros sistemas. A criptografia SMB também ajuda a evitar ataques de retransmissão e facilita a conformidade com as normas regulamentares.
Você pode integrar VMs Locais do Azure no Defender for Cloud para ativar análises comportamentais baseadas em nuvem, deteção e correção de ameaças, alertas e relatórios. Gerencie VMs Locais do Azure no Azure Arc para que você possa usar de Política do Azure para avaliar sua conformidade com as regulamentações do setor e os padrões corporativos.
Componentes
Essa arquitetura consiste em hardware de servidor físico que você pode usar para implantar instâncias locais do Azure em locais locais ou de borda. Para melhorar 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:
Local do Azure é uma solução de infraestrutura hiperconvergente (HCI) implantada no local ou em pontos de presença 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 nó único para um máximo de dezesseis nós usando categorias de hardware validadas, integradas ou premium fornecidas por parceiros OEM (fabricante de equipamento original).
Azure Arc é um serviço baseado em nuvem que estende o modelo de gerenciamento baseado no Azure Resource Manager para o Azure Local e outros locais que não sejam 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 dados em contêineres e serviços de aprendizado de máquina.
Azure Key Vault é um serviço de nuvem que você pode usar para armazenar e acessar segredos com segurança. Um segredo é qualquer coisa a que você queira restringir fortemente o acesso, como chaves de API, senhas, certificados, chaves criptográficas, credenciais de administrador local e chaves de recuperação do BitLocker.
de testemunho na nuvem é um recurso do Armazenamento do Azure que atua como um quórum de cluster de failover. Os nós de cluster Local do Azure usam esse quórum 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 da nuvem local do Azure.
Update Manager é um serviço unificado projetado para gerenciar e governar atualizações para o Azure Local. Você pode usar o Update Manager para gerenciar cargas de trabalho implantadas no Azure Local, incluindo a conformidade de atualização do SO convidado para VMs Windows e Linux. Essa abordagem unificada simplifica o gerenciamento de patches 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 de suporte opcionais para melhorar os recursos da plataforma:
O Monitor é um serviço baseado em nuvem para coletar, analisar e atuar em logs de diagnóstico e telemetria de suas cargas de trabalho locais e na 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 for Azure Local para simplificar a criação da regra de coleta de dados (DCR) do Monitor e habilitar rapidamente o monitoramento de instâncias locais do Azure.
de Política do Azure é um serviço que avalia recursos do Azure e locais. O Azure Policy avalia recursos por meio da integração com o Azure Arc usando as propriedades desses recursos para regras de negócios, chamadas de definições de política , para determinar a conformidade ou os recursos que você pode usar para aplicar a Configuração de Convidado de VM usando configurações de política.
Defender for Cloud é um sistema abrangente de gerenciamento de segurança de infraestrutura. Melhora a postura de segurança dos seus centros de dados e fornece proteção avançada contra ameaças para cargas de trabalho híbridas, quer residam no Azure ou noutro local, e em ambientes locais.
de Backup do Azure é um serviço baseado em nuvem que fornece uma solução simples, segura e econômica para fazer backup de seus dados e recuperá-los do Microsoft Cloud. O Servidor de Backup do Azure é usado para fazer backup de VMs implantadas no Azure Local e armazená-las no serviço de Backup.
Site Recovery é um serviço de recuperação de desastres que fornece recursos BCDR permitindo que aplicativos de negócios e cargas de trabalho façam failover em caso de desastre ou paralisação. A Recuperação de Site 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 tempos de RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e RPO (Recovery Point Objetive, objetivo de ponto de recuperação), computação (CPU), 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 unidade de processamento central (CPU), incluindo recursos de tecnologia de segurança de hardware, o número de CPUs, a frequência GHz (velocidade) e o número de núcleos por soquete de CPU.
Requisitos da unidade de processamento gráfico (GPU) da carga de trabalho, como IA ou aprendizado de máquina, inferência ou renderização gráfica.
A memória por nó ou a quantidade de memória física necessária para executar a carga de trabalho.
O número de nós físicos no cluster que são de 1 a 16 nós em escala. O número máximo de nós é três quando você usa a arquitetura de rede sem comutador de armazenamento .
Para manter a resiliência de computação, você precisa reservar pelo menos nós N+1 de capacidade no cluster. Essa estratégia permite a drenagem de nós para atualizações ou recuperação de interrupções repentinas, como quedas de energia ou falhas de hardware.
Para cargas de trabalho críticas para os negócios ou de missão crítica, considere reservar capacidade de nós N+2 para aumentar a resiliência. Por exemplo, se dois nós no cluster estiverem offline, a carga de trabalho poderá permanecer online. Essa abordagem fornece resiliência para cenários nos quais um nó que está executando uma carga de trabalho fica offline durante um procedimento de atualização planejado e resulta em dois nós offline simultaneamente.
Requisitos de resiliência, capacidade e desempenho de armazenamento:
de resiliência: recomendamos que você implante três ou mais nós para habilitar o espelhamento de três vias, que fornece três cópias dos dados, para a infraestrutura e os volumes de usuários. O espelhamento de três vias aumenta o desempenho e a máxima confiabilidade para 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 é de aproximadamente 33% do espaço de armazenamento bruto dos discos da camada de capacidade quando você usa o espelhamento tridirecional.
de desempenho: operações de entrada/saída por segundo (IOPS) da plataforma que determinam os recursos de taxa de transferência de armazenamento para a carga de trabalho quando multiplicados pelo tamanho do bloco do aplicativo.
Para projetar e planejar uma implantação do Azure Local, recomendamos que você use a ferramenta de dimensionamento local do
A ferramenta de dimensionamento seção Preferências orienta você por perguntas relacionadas ao tipo de sistema (Premier, Sistema Integrado ou Nó Validado) e às opções da família de CPU. Ele também ajuda a selecionar seus requisitos de resiliência para o cluster. Certifique-se de:
Reserve um mínimo de nós N+1 de capacidade, ou um nó, em todo o cluster.
Reserve nós N+2 de capacidade em todo o cluster para resiliência extra. Esta opção permite que o sistema resista a uma falha de nó durante uma atualização ou outro evento inesperado que afete dois nós simultaneamente. Ele também garante que haja capacidade suficiente no cluster para que a carga de trabalho seja executada nos nós online restantes.
Esse cenário requer o uso de espelhamento de três vias para volumes de usuário, que é o padrão para clusters que têm três ou mais nós 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 a capacidade de carga de trabalho necessária e os requisitos de resiliência da plataforma 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 os SKUs de solução de tamanho certo a atender às suas necessidades, entre em contato com seu provedor de soluções de hardware ou parceiro de integração de sistema (SI) de sua preferência.
Unidades de disco físicas
Storage Spaces Direct suporta vários tipos de unidades de disco físico que variam em desempenho e capacidade. Ao projetar uma instância Local do Azure, trabalhe com seu 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 de sua carga de trabalho. Os exemplos incluem unidades de disco rígido (HDD) giratórias ou unidades de estado sólido (SSD) e unidades NVMe. Essas unidades são geralmente chamadas de unidades flashou de armazenamento de memória persistente (PMem), que é conhecida como memória de classe de armazenamento (SCM).
A confiabilidade da plataforma depende do desempenho de dependências críticas da plataforma, como tipos de disco físico. Certifique-se de escolher os tipos de disco certos para suas necessidades. Use soluções de armazenamento totalmente flash, como unidades NVMe ou SSD, para cargas de trabalho com requisitos de alto desempenho ou baixa latência. Essas cargas de trabalho incluem, mas não se limitam a, tecnologias de banco de dados altamente transacionais, clusters AKS de produção ou quaisquer cargas de trabalho de missão crítica ou críticas para os negócios que tenham requisitos de armazenamento de baixa latência ou alta taxa de transferência. Use implantações totalmente flash para maximizar o desempenho do armazenamento. All-NVMe configurações de unidades ou unidades totalmente SSD, especialmente em pequena escala, melhoram a eficiência do armazenamento e maximizam o desempenho porque nenhuma unidade é usada como camada de cachePara obter mais informações, consulte de armazenamento totalmente flash .
Para cargas de trabalho de uso geral, umde configuração de armazenamento híbrido, como unidades NVMe ou SSDs para cache e HDDs para capacidade, pode fornecer mais espaço de armazenamento. A contrapartida é que os discos giratórios têm um desempenho inferior se a sua carga de trabalho exceder o conjunto de trabalho cache, e as HDD têm um tempo médio mais baixo entre o valor de falha em comparação com as unidades NVMe e SSD.
O desempenho do armazenamento em cluster é influenciado pelo tipo de unidade de disco físico, que varia com base nas características de desempenho de cada tipo de unidade e no mecanismo de cache escolhido. O tipo de unidade de disco físico é parte integrante de qualquer projeto e configuração do Storage Spaces Direct. Dependendo dos requisitos de carga de trabalho local do Azure e das restrições de orçamento, você pode optar por maximizar o desempenhomaximizar a capacidadeou implementar uma configuração de tipo de unidade mista que equilibre o desempenho e a capacidade.
O Storage Spaces Direct fornece um de cache integrado, persistente, em tempo real, de leitura, gravação e 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. Espaços de Armazenamento Os discos virtuais diretos, ou volumes , são usados em combinação com o cache de leitura na memória de volume compartilhado de cluster (CSV) para melhorar Hyper-V desempenho, especialmente para acesso de entrada sem buffer a arquivos de disco rígido virtual (VHD) ou VHDX (disco rígido virtual) de carga de trabalho.
Dica
Para cargas de trabalho de alto desempenho ou sensíveis à latência, recomendamos que você use um de configuração de armazenamento totalmente flash (todos os NVMe ou todos os SSD) e um tamanho de cluster de três ou mais nós físicos. A implantação desse design com as configurações de de configuração de armazenamento padrão
Design de rede
A conceção da 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 de placa de interface de rede (NIC) física para todas as combinações de intenções de rede de gerenciamento, computação e armazenamento. O uso das mesmas portas NIC para todas as finalidades relacionadas à intenção é chamado de configuração de rede totalmente convergente .
Embora haja suporte para uma configuração de rede totalmente convergente, a configuração ideal para desempenho e confiabilidade é que a intenção de armazenamento use portas de adaptador de rede dedicadas. Portanto, essa arquitetura de linha de base fornece orientações de exemplo sobre como implantar uma instância local do Azure com vários nós usando a arquitetura de rede comutada de armazenamento com duas portas de adaptador de rede que são convergidas para fins 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.
Esta arquitetura requer dois ou mais nós físicos e até um máximo de 16 nós em escala. Cada nó requer quatro portas de adaptador de rede conectadas a dois switches Top-of-Rack (ToR). Os dois comutadores ToR devem ser interligados através de ligações MLAG (multi-chassis link aggregation group). As duas portas do adaptador de rede usadas para o tráfego de intenção de armazenamento devem oferecer suporte a RDMA (Acesso Remoto Direto à Memória). Essas portas exigem uma velocidade mínima de link 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 (switch embedded teaming). A tecnologia SET fornece redundância de link e recursos de balanceamento de carga. Essas portas exigem uma velocidade mínima de link 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 físicas reais entre nós e componentes de rede.
Você precisa dos seguintes componentes ao projetar uma implantação Local do Azure comutada de armazenamento de vários nós que usa essa arquitetura de linha de base:
Comutadores ToR duplos:
Os switches de rede ToR duplos são necessários para a resiliência da rede e a capacidade de atender ou aplicar atualizações de firmware aos switches sem incorrer em tempo de inatividade. Essa estratégia evita um único ponto de falha (SPoF).
Os switches ToR duplos são usados para o tráfego de armazenamento, ou leste-oeste. Esses switches usam duas portas Ethernet dedicadas que têm classes de tráfego específicas de armazenamento de redes locais virtuais (VLANs) e controle de fluxo prioritário (PFC) definidas para fornecer comunicação RDMA sem perdas.
Esses switches se conectam aos nós através de cabos Ethernet.
Dois ou mais nós físicos e até um máximo de 16 nós:
Cada nó é um servidor físico que executa o Azure Stack HCI OS.
Cada nó 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ível com RDMA que se conectam com um caminho para cada um dos dois switches ToR. Essa abordagem fornece redundância de caminho de link e largura de banda priorizada dedicada para o 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 um dos dois switches ToR para redundância de caminho de link.
Conectividade externa:
Os switches ToR duplos 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. Este dispositivo pode ser um firewall ou roteador. Esses switches roteiam o tráfego que entra e sai da instância Local do Azure ou o tráfego norte-sul.
A conectividade de tráfego externo norte-sul suporta a intenção de gerenciamento de cluster e as intenções de computação. Isso é conseguido usando duas portas de switch e duas portas de adaptador de rede por nó que são convergidas por meio de agrupamento incorporado de switch (SET) e um comutador virtual dentro de Hyper-V para garantir resiliência. Esses componentes funcionam para fornecer conectividade externa para VMs do Azure Arc e outros recursos de carga de trabalho implantados nas redes lógicas criadas no Gerenciador de Recursos usando modelos do portal do Azure, CLI ou Iac.
Topologia lógica de rede
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 é a seguinte:
Comutadores ToR duplos:
- Antes de implantar o cluster, os dois switches de rede ToR precisam ser configurados com as IDs de VLAN necessárias, as configurações máximas da unidade de transmissão e a configuração de ponte do datacenter para osde gerenciamento de
,de computação e portas de de armazenamento. Para obter mais informações, consulte Requisitos de rede física para o Azure Localou peça ajuda ao seu fornecedor de hardware de switch ou parceiro SI.
- Antes de implantar o cluster, os dois switches de rede ToR precisam ser configurados com as IDs de VLAN necessárias, as configurações máximas da unidade de transmissão e a configuração de ponte do datacenter para osde gerenciamento de
O Azure Local usa a abordagem ATC de Rede para aplicar automação de rede e configuração de rede baseada em intenção.
O ATC de rede foi projetado para garantir a configuração de rede ideal e o fluxo de tráfego usando o tráfego de rede intenções. O ATC de rede define quais portas físicas do adaptador de rede são usadas para as diferentes intenções (ou tipos) de tráfego de rede, como para ode gerenciamento de
de cluster,de computação de carga de trabalho e de armazenamento de de cluster. As políticas baseadas em intenção simplificam os requisitos de configuração de rede automatizando a configuração de rede do nó com base em entradas de parâmetros especificadas como parte do processo de implantação da nuvem local do Azure.
Comunicação externa:
Quando os nós ou a carga de trabalho precisam se comunicar externamente acessando a LAN corporativa, a Internet ou outro serviço, eles roteiam usando os switches ToR duplos. Esse processo é descrito na seção topologia de rede física
anterior. Quando os dois switches ToR atuam como dispositivos de Camada 3, eles lidam com o roteamento e fornecem conectividade além do cluster para o dispositivo de borda de borda, como seu firewall ou roteador.
A intenção da rede de gerenciamento usa a interface virtual convergente da equipe SET, 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 da 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 físicas do adaptador de rede que são convergidas usando uma equipe SET para as intenções de computação e gerenciamento.
Tráfego de armazenamento:
Os nós físicos se comunicam entre si usando duas portas de adaptador de rede dedicadas que são conectadas aos switches ToR para fornecer alta largura de banda e resiliência para o tráfego de armazenamento.
As SMB1 e portas de armazenamento SMB2 se conectam a duas redes não roteáveis (ou camada 2) separadas. Cada rede tem um ID de VLAN específico configurado que deve corresponder à configuração das portas do switch nos IDs de VLAN de armazenamento padrão dos switches ToR: 711 e 712.
Não há nenhum gateway padrão configurado nas duas portas do adaptador de rede de intenção de armazenamento no sistema operacional HCI do Azure Stack.
Cada nó pode acessar os recursos de Espaços de Armazenamento Diretos do cluster, como discos físicos remotos usados 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 disponíveis em cada nó. SMB Multichannel é usado para resiliência.
Essa configuração fornece velocidade de transferência de dados suficiente para operações relacionadas ao armazenamento, como a manutenção de cópias consistentes de dados para volumes espelhados.
Requisitos do comutador de rede
Seus switches Ethernet devem atender às diferentes especificações exigidas pelo Azure Local e definidas pela Institute of Electrical and Electronics Engineers Standards Association (IEEE SA). Por exemplo, para implantações comutadas de armazenamento com vários nós, a rede de armazenamento é usada para RDMA via RoCE v2 ou iWARP. Esse processo requer IEEE 802.1Qbb PFC para garantir comunicação sem perdas para a classe de tráfego de armazenamento . Seus switches ToR devem fornecer suporte para IEEE 802.1Q para VLANs e IEEE 802.1AB para o Link Layer Discovery Protocol.
Se você planeja usar comutadores de rede existentes para uma implantação do Azure Local, revise a lista de padrões e especificações IEEE obrigatórios que os comutadores de rede e a configuração devem fornecer. Ao comprar novos comutadores de rede, reveja a lista de modelos de comutadores certificados pelo fornecedor de hardware que suportam os requisitos de rede local do Azure.
Requisitos de endereço IP
Em uma implantação comutada de armazenamento com vários nós, o número de endereços IP necessários aumenta com a adição de cada nó físico, até um máximo de 16 nós em um único cluster. Por exemplo, para implantar uma configuração comutada de armazenamento de dois nós do Azure Local, a infraestrutura de cluster requer um mínimo de 11 endereços IP a serem alocados. Mais endereços IP são necessários se você usar microssegmentação ou rede definida por software. Para obter mais informações, consulte Examinar requisitos de endereço IP do padrão de referência de armazenamento de dois nós para o Azure Local.
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 planeia implementar o AKS no Azure Local, consulte AKS ativado pelos requisitos de rede do Azure Arc.
Monitorização
Para aprimorar o monitoramento e o alerta, habilite o Monitor Insights no Azure Local. O Insights pode ser dimensionado para monitorar e gerenciar vários clusters 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 for Azure Local é criado usando o Monitor e o Log Analytics, o que garante uma solução escalável e sempre up-toatualizada e 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 gráficos, a personalização de visualizações por meio de agregação e filtragem e a configuração de regras personalizadas de alerta de integridade de recursos.
Gerenciamento de atualizações
As instâncias locais do Azure e os recursos de carga de trabalho implantados, como VMs do Azure Arc, precisam ser atualizados e corrigidos regularmente. Ao aplicar atualizações regularmente, você garante que sua organização mantenha uma forte postura de segurança 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 deteção 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 novas compilações de linha de base trimestralmente. As compilações de linha de base são aplicadas às instâncias locais do Azure para mantê-las atualizadas. Além das atualizações regulares de compilação de linha de base, o Azure Local é atualizado com atualizações mensais de segurança e confiabilidade do sistema operacional.
O Update Manager é um serviço do Azure que você pode usar para aplicar, exibir e gerenciar atualizações para o Azure Local. Este serviço fornece um mecanismo para exibir todas as instâncias locais do Azure em toda a sua infraestrutura e pontos de presença usando o portal do Azure para fornecer uma experiência de gerenciamento centralizado. Para obter mais informações, consulte os seguintes recursos:
É importante verificar se há novas atualizações de driver e firmware regularmente, como a cada três a seis meses. Se você usar uma versão de categoria de solução Premier para seu hardware Local do Azure, as atualizações do pacote Solution Builder Extension serão integradas ao Update Manager para fornecer uma experiência de atualização simplificada. Se você usar nós validados ou uma categoria de sistema integrado, pode haver 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.
Correção do SO convidado da carga de trabalho
Você pode registrar VMs do Azure Arc implantadas no Azure Local usando do Azure Update Manager (AUM) para fornecer uma experiência unificada de gerenciamento de patches usando o mesmo mecanismo usado para atualizar os nós físicos do cluster Local do Azure. Você pode usar o AUM para criar configurações de manutenção de convidado. Essas configurações controlam as configurações, como a configuração Reinicializar reinicializar, se necessário,, o agendamento (datas, horas e opções de repetição) e uma lista dinâmica (assinatura) ou estática das VMs do Azure Arc 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.
Considerações
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.
Fiabilidade
A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade.
Identificar os potenciais pontos de falha
Toda arquitetura é suscetível a falhas. Você pode antecipar 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 nessa arquitetura:
Componente | Risco | Probabilidade | Efeito/atenuação/nota | Interrupção |
---|---|---|---|---|
Interrupção da instância local do Azure | Falha de energia, rede, hardware ou software | Média | Para evitar uma interrupção prolongada do aplicativo causada pela falha de uma instância Local do Azure para casos de uso de negócios ou de missão crítica, sua carga de trabalho deve ser arquitetada usando os 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 persistentes que são implantados usando várias VMs do Azure Arc ou instâncias AKS implantadas em instâncias locais do Azure separadas e em locais físicos separados. | Potencial interrupção |
Interrupção de nó físico único local do Azure | Falha de energia, hardware ou software | Média | Para evitar uma interrupção prolongada do aplicativo causada pela falha de uma única máquina Local do Azure, sua instância Local do Azure deve ter vários nós físicos. Os requisitos de capacidade da carga de trabalho durante a fase de projeto do cluster determinam o número de nós. Recomendamos que você tenha três ou mais nós. Também recomendamos o uso do espelhamento de três vias, que é o modo de resiliência de armazenamento padrão para clusters com três ou mais nós. Para evitar um SPoF e aumentar a resiliência da carga de trabalho, implante várias instâncias da sua carga de trabalho usando duas ou mais VMs do Azure Arc ou pods de contêiner que são executados em vários nós de trabalho do AKS. Se um único nó falhar, as VMs do Azure Arc e os serviços de carga de trabalho/aplicativo serão reiniciados nos nós físicos online restantes no cluster. | Potencial interrupção |
Azure Arc VM ou nó de trabalho AKS (carga de trabalho) | Configuração incorreta | Média | Os usuários do aplicativo não conseguem entrar ou acessar o aplicativo. Erros de configuração devem ser detetados durante a implantação. Se esses erros acontecerem durante uma atualização de configuração, a equipe de DevOps deverá reverter as alterações. Você pode reimplantar a VM, se necessário. A reimplantação leva menos de 10 minutos, mas pode levar mais tempo de acordo com o tipo de implantação. | Potencial interrupção |
Conectividade com o Azure | Interrupção da rede | Média | O cluster precisa acessar o plano de controle do Azure regularmente para recursos de cobrança, gerenciamento e monitoramento. Se o cluster perder a conectividade com o Azure, ele operará em um estado degradado. Por exemplo, não seria possível implantar novas VMs do Azure Arc ou clusters AKS se o cluster perder a conectividade com o Azure. As cargas de trabalho existentes em execução no cluster HCI continuam a ser executadas, mas você deve restaurar a conexão dentro de 48 a 72 horas para garantir a operação ininterrupta. | Nenhum |
Para obter mais informações, consulte Recomendações para executar a análise do modo de falha.
Objetivos de fiabilidade
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 no local. A Contoso Manufacturing tem uma meta interna de SLO (objetivo de nível de serviço) de 99,8% que as partes interessadas da empresa e do aplicativo concordam para 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 que são implantados usando VMs do Azure Arc que são executadas no Azure Local:
Semanalmente: 20 minutos e 10 segundos
Mensal: 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 atingir as metas de SLO, a Contoso Manufacturing implementa o princípio de menor privilégio (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 quaisquer ações inadvertidas ou acidentais executadas nos recursos de produção. Além disso, os logs de eventos de segurança para controladores de domínio dos Serviços de Domínio Ative Directory (AD DS) locais são monitorados para detetar e relatar quaisquer alterações de associação de grupo de contas de usuário, conhecidas como
adicionar eremover ações , para o grupo administradores de instância local do Azureusando 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 para gerenciamento de identidade e acesso.
Procedimentos rigorosos de controle de alterações 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 submetidas 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, testes e verificação pós-lançamento e critérios de sucesso claros para que uma alteração seja revisada ou aprovada.
Para obter mais informações, consulte Recomendações para práticas de implantação seguras.
Os patches de segurança mensais e as atualizações de linha de base trimestrais são aplicados à instância Local do Azure de produção somente depois de validados pelo ambiente de pré-produção. O Update Manager e o recurso de atualização com reconhecimento de cluster automatizam o processo de uso de de migração ao vivo 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 mensal. Os procedimentos operacionais padrão da Contoso Manufacturing exigem que as atualizações de segurança, confiabilidade ou compilação 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 do 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.
Contoso Manufacturing implementa backups diários, semanais e mensais para reter os últimos 6 x dias de backups diários (de segunda a sábado), os últimos 3 backups semanais (todos os domingos) e 3 x mensais, com cada da semana 4 de domingo sendo retidos para se tornarem os backups do mês 1, do mês 2 e do mês 3 usando uma agenda baseada em calendário contínuo documentada e auditável. Essa abordagem atende aos requisitos da Contoso Manufacturing para obter um equilíbrio adequado entre o número de pontos de recuperação de dados disponíveis e a redução de custos para o serviço de armazenamento de backup externo ou em nuvem.
Para obter mais informações, consulte Recomendações para projetar uma estratégia de recuperação de desastres.
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 projetar 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 paraLocal do Azure , permitem que a Contoso Manufacturing atenda à meta de SLO de 99,8% e dimensione e gerencie efetivamente implantações locais e de carga de trabalho do Azure em vários locais de fabricação distribuídos em todo o mundo.
Para obter mais informações, consulte Recomendações para definir metas de confiabilidade.
Redundância
Considere uma carga de trabalho que você implanta em uma única instância Local do Azure como um de implantação localmente redundante. O cluster fornece alta disponibilidade no nível da plataforma, mas você deve implantar o cluster em um único rack. Para casos de uso críticos para os negócios ou de missão crítica, recomendamos que você implante 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 NLB (balanceamento de carga de rede) externa 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 o uso de um dispositivo NLB externo 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 a Rota Expressa do Azure ou um túnel VPN para se conectar a um serviço local.
Para obter mais informações, consulte Recomendações para projetar para redundância.
Segurança
A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de 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 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 do Windows Defender, o Credential Guard e o BitLocker habilitados. Para simplificar a delegação de permissões usando o PoLP, use funções RBAC (controle de acesso baseado em função) internas do Azure Local, como o Administrador Local do Azure para administradores de plataforma e o Colaborador de VM Local do Azure ou o Leitor de VM Local do Azure para operadores de carga de trabalho.
Configurações de segurança padrã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 habilita o controle de desvio manter os nós 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 desvio e as configurações do servidor núcleo seguro no cluster.
Logs de eventos de segurança: de encaminhamento de syslog local do Azure integra-se a 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 for Cloud protege sua instância local do Azure contra várias ameaças e vulnerabilidades. Este serviço ajuda a melhorar a postura de segurança do seu ambiente Local do Azure e pode proteger contra ameaças existentes e em evolução.
de deteção e correção de ameaças: Microsoft Advanced Threat Analytics deteta e corrige ameaças, como as direcionadas ao AD DS, que fornecem serviços de autenticação para nós de instância local do Azure e suas cargas de trabalho de VM do Windows Server.
de isolamento de rede: isole redes, se necessário. Por exemplo, você pode provisionar várias redes lógicas que usam VLANs e intervalos de endereços de rede separados. Ao usar essa abordagem, certifique-se de que a rede de gerenciamento possa alcançar cada rede lógica e VLAN para que os nós de instância local do Azure possam se comunicar com as redes VLAN por meio dos switches ou gateways ToR. Essa configuração é necessária para o gerenciamento da carga de trabalho, como permitir que os agentes de gerenciamento de infraestrutura se comuniquem com o SO 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 consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.
As considerações de otimização de custos incluem:
modelo de cobrança no estilo de nuvem para licenciamento: o preço do Azure Local 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. Aplicam-se taxas de utilização adicionais se utilizar outros serviços do Azure. Se você possui licenças principais locais para a edição do Windows Server Datacenter com o Software Assurance ativo, pode optar por trocar essas licenças para ativar a instância local do Azure e as taxas de assinatura da VM do Windows Server.
Patch de convidado automático de VM para VMs do Azure Arc: esse recurso ajuda a reduzir a sobrecarga de aplicação manual de patches e os custos de manutenção associados. Esta 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 de custos.
Consolidação de monitoramento de custos: Para consolidar os custos de monitoramento, use o Insights para Local do Azure e o patch usando o Update Manager para o Azure Local. O Insights usa o Monitor para fornecer métricas avançadas e recursos de alerta. O componente gerenciador de ciclo de vida do Azure Localintegra-se ao Update Manager 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 Update Manager para otimizar a alocação de recursos e contribuir para a eficiência geral de custos.
Para obter mais informações, consulte Recomendações para otimizar o tempo da equipe.
Capacidade de carga de trabalho inicial ede crescimento: ao planejar sua implantação local do Azure, considere sua capacidade de carga de trabalho inicial, requisitos de resiliência e considerações de crescimento futuro. Considere se o uso de uma arquitetura sem switch de armazenamento de dois ou três nós poderia reduzir custos, como eliminar a necessidade de adquirir switches de rede de classe de armazenamento. A aquisição de switches de rede de classe de armazenamento extra pode ser um componente caro de novas implantações de instância Local do Azure. Em vez disso, você pode usar switches existentes para redes de gerenciamento e computação, o que simplifica a infraestrutura. Se suas necessidades de capacidade de carga de trabalho e resiliência não forem dimensionadas além de uma configuração de três nós, considere se você pode usar switches existentes para as redes de gerenciamento e computação e usar a arquitetura sem switch de armazenamento de três nós para implantar o Azure Local.
Para obter mais informações, consulte Recomendações para otimizar os custos de componentes.
Dica
Você pode economizar em custos com o Benefício Híbrido do Azure se tiver licenças do Windows Server Datacenter com o Software Assurance ativo. Para obter mais informações, consulte Benefício Híbrido do Azure para o Azure Local.
Excelência operacional
A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Visão geral do pilar de excelência operacional.
As considerações de excelência operacional incluem:
Experiência simplificada de provisionamento e gerenciamento integrada ao Azure: A Implantação Baseada em Nuvem no Azure fornece uma interface orientada por assistente que mostra como criar uma instância Local do Azure. Da mesma forma, o Azure simplifica o processo de de gerenciamento de instâncias locais do Azure e VMs do Azure Arc. Você pode automatizar a implantação baseada em portal da instância Local do Azure usando o modelo ARM. Este modelo fornece consistência e automação para implantar o Azure Local em escala, especificamente em cenários de borda, como lojas de varejo ou sites de fabricação que exigem uma instância Local do Azure para executar cargas de trabalho críticas para os negócios.
recursos de automação para máquinas virtuais: o Azure Local fornece uma ampla gama de recursos de automação para gerenciar cargas de trabalho, como VMs do Azure Arc, com a implantação automatizada de VMs do Azure Arc usando ade modelo do Azure CLI, ARM ou Bicep, com atualizações do sistema operacional da máquina virtual usando o Azure Arc Extension for Updates e do Azure Update Manager para atualizar cada instância local do Azure. O Azure Local também fornece suporte para de gerenciamento de VMs do Azure Arc usando a CLI do Azure e VMs Arc que não sejam do Azure usando o Windows PowerShell. Você pode executar comandos da CLI do Azure localmente a partir de uma das máquinas locais do Azure ou remotamente a partir de um computador de gerenciamento. A integração com de Automação do Azure e o Azure Arc facilita uma ampla variedade de cenários de automação extra para cargas de trabalho de VM por meio das extensões do Azure Arc.
Para obter mais informações, consulte Recomendações para usar o IaC.
Recursos de automação para contêineres no AKS: O Azure Local fornece uma ampla gama de recursos de automação para gerenciar cargas de trabalho, como contêineres, no AKS. Você pode automatizar a implantação de clusters AKS usando a CLI do Azure. Atualize os clusters de carga de trabalho do AKS usando a extensão Azure Arc para atualizações do Kubernetes. Você também pode gerenciar AKS habilitado para Azure Arc usando a CLI do Azure. Você pode executar comandos da CLI do Azure localmente a partir de uma das máquinas locais do Azure ou remotamente a partir de um computador de gerenciamento. Integre com o Azure Arc para uma ampla variedade de cenários de automação extra para cargas de trabalho em contêineres por meio das extensões do Azure Arc.
Para obter mais informações, consulte Recomendações para habilitar a automação.
Eficiência de desempenho
Eficiência de desempenho é a capacidade de sua carga de trabalho de escalar para atender às demandas colocadas pelos usuários de maneira eficiente. Para obter mais informações, consulte Visão geral do pilar Eficiência de desempenho.
As considerações de eficiência de desempenho incluem:
de desempenho do armazenamento de carga de trabalho: considere usar a ferramenta DiskSpd para testar os recursos de desempenho do 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 VMFleet para medir o desempenho do subsistema de armazenamento.
Recomendamos que você estabeleça uma linha de base para o desempenho de suas 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 principal função 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 para testes de desempenho.
de resiliência de armazenamento de carga de trabalho: considere os benefícios da resiliência de armazenamento , eficiência de uso (ou capacidade) e desempenho. O planejamento de volumes locais do Azure inclui a identificação do 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 sobre uma ou mais das outras características. O aumento da 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 nós, a configuração de armazenamento padrão emprega espelhamento de três vias para volumes de infraestrutura e usuários.
Para obter mais informações, consulte Recomendações para o planejamento de capacidade.
de otimização de desempenho de rede: considere a otimização de desempenho de rede. Como parte do seu projeto, certifique-se de incluir a alocação de largura de banda de tráfego de rede projetada ao determinar sua configuração ideal de hardware de rede.
Para otimizar o desempenho de computação no Azure Local, você pode usar a aceleração de GPU. A aceleração da GPU é benéfica para cargas de trabalho de IA ou aprendizado de máquina de alto desempenho que envolvem insights de dados ou inferência. Essas cargas de trabalho exigem implantação em pontos de presença devido a considerações como gravidade dos dados ou requisitos de segurança. Em uma implantação híbrida ou local, é importante levar em consideração os requisitos de desempenho da 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 este cenário
A seção a seguir fornece uma lista de exemplo das tarefas de alto nível ou fluxo de trabalho típico usado para implantar o Azure Local, incluindo tarefas e considerações de pré-requisito. Esta lista de fluxo de trabalho destina-se apenas a um guia de exemplo. Não é uma lista exaustiva de todas as ações necessárias, que podem variar com base nos requisitos organizacionais, geográficos ou específicos do projeto.
Cenário: há um requisito de projeto ou caso de uso para implantar uma solução de nuvem híbrida em um local local ou ponto de presença 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.
Reunir requisitos de carga de trabalho e casos de uso de partes interessadas relevantes. Essa estratégia permite que o projeto confirme se 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 tamanho da carga de trabalho e dos recursos necessários, como VMs do Azure Arc, AKS, Área de Trabalho Virtual do Azure ou Serviços de Dados habilitados para Azure Arc ou serviço de Aprendizado de Máquina habilitado para Azure Arc. Os valores de RTO e RPO (confiabilidade) da carga de trabalho e outros requisitos não funcionais (desempenho/escalabilidade de carga) devem ser documentados como parte desta etapa de coleta de requisitos.
Revise a saída do dimensionador local do Azure para a solução de parceiro de hardware recomendada. Essa saída inclui detalhes da marca e modelo de hardware de servidor físico recomendado, número de nós 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.
Use a ferramenta de dimensionamento local do Azure para criar um novo projeto que modele o tipo de carga de trabalho e dimensione. Este projeto inclui o tamanho e o número de VMs e seus requisitos de armazenamento. Esses detalhes são inseridos juntamente com as opções para o tipo de sistema, a família de CPU preferida e seus requisitos de resiliência para alta disponibilidade e tolerância a falhas de armazenamento, conforme explicado na seção Opções de design de cluster de
anterior. Revise a saída do Azure Local Sizer para a solução de parceiro de hardware recomendada. Essa solução inclui detalhes do hardware de servidor físico recomendado (marca e modelo), número de nós 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.
Entre em contato com o OEM de hardware ou parceiro SI para qualificar ainda mais a adequação da versão de hardware recomendada em relação aos seus 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. Esta etapa geralmente inclui discussões com o parceiro OEM ou SI de hardware para os aspetos comerciais da solução. Esses aspetos incluem cotações, disponibilidade do hardware, prazos de entrega e quaisquer serviços profissionais ou de valor agregado que o parceiro forneça para ajudar a acelerar seus resultados de projeto ou negócios.
Implante dois switches ToR para integração de rede. Para soluções de alta disponibilidade, os clusters HCI exigem a implantação de dois switches ToR. Cada nó físico requer quatro NICs, dois dos quais devem ser compatíveis com RDMA, que fornece dois links de cada nó para os dois switches ToR. Duas NICs, uma conectada a cada switch, são convergidas para conectividade de saída norte-sul para as redes de computação e gerenciamento. As outras duas NICs compatíveis com RDMA são dedicadas ao tráfego de armazenamento leste-oeste. Se planeia utilizar comutadores de rede existentes, certifique-se de que a marca e o modelo dos seus comutadores estão na lista aprovada de comutadores de rede suportados pelo Azure Local.
Trabalhe com o OEM de hardware ou parceiro SI para organizar a entrega do hardware. O parceiro de SI ou seus funcionários são obrigados a integrar o hardware em seu datacenter local ou ponto de presença, como empilhamento e empilhamento do hardware, rede física e cabeamento da unidade de fonte de alimentação para os nós físicos.
Execute a 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 os seus funcionários podem implantar o software Local do Azure. Esta etapa começa integrando os nós físicos do Azure Stack HCI OS em servidores habilitados para Azure Arc e, em seguida, iniciando o processo de implantação da nuvem local do Azure. Os clientes e parceiros podem fazer uma solicitação de suporte diretamente com a Microsoft no portal do Azure selecionando o ícone Support + Troubleshooting 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.
Dica
A implementação de referência do sistema Azure Stack HCI OS, versão 23H2 demonstra como implantar uma implantação multisservidor comutada do Azure Local usando um modelo ARM e um arquivo de parâmetro. Como alternativa, o exemplo do Bicep demonstra como usar um modelo Bicep para implantar uma instância Local do Azure, incluindo seus recursos de pré-requisitos.
Implante cargas de trabalho altamente disponíveis no Azure Local usando o portal do Azure, CLI ou modelos ARM + Azure Arc para automação. Use o local personalizado recurso do novo cluster HCI como a região de destino quando implantar recursos de carga de trabalho, como VMs do Azure Arc, AKS, hosts de sessão da Área de Trabalho Virtual do Azure ou outros de serviços habilitados para Azure Arc que você pode habilitar por meio de extensões AKS e conteinerização no Azure Local.
Instalar atualizações mensais para melhorar a segurança e confiabilidade da plataforma. Para manter suas instâncias locais do Azure atualizadas, é importante instalar as atualizações de software da Microsoft e as atualizações de driver e firmware OEM de hardware. Essas atualizações melhoram a segurança e a confiabilidade da plataforma. Update Manager aplica as atualizações e fornece uma solução centralizada e escalável para instalar atualizações em um único cluster ou em vários clusters. Consulte o seu parceiro OEM de hardware para determinar o processo de instalação de atualizações de driver de hardware e firmware, 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.
Recursos relacionados
- Projeto de arquitetura híbrida
- Opções híbridas do Azure
- Automação em ambiente híbrido
- de Configuração do Estado de Automação do Azure
- Otimize a administração de instâncias do SQL Server em ambientes locais e multicloud usando o Azure Arc
Próximos passos
Documentação do produto:
- Azure Stack HCI OS, versão 23H2 informações de versão
- AKS no Azure Local
- Área de Trabalho Virtual do Azure para Local do Azure
- O que é o monitoramento Local do Azure?
- Proteja cargas de trabalho de VM com a Recuperação de Site no Azure Local
- Visão geral do Monitor
- Controlo de alterações e visão geral do inventário
- Visão geral do Update Manager
- O que são serviços de dados habilitados para Azure Arc?
- O que são servidores habilitados para Azure Arc?
- O que é o serviço de Backup?
Documentação do produto para obter detalhes sobre serviços específicos do Azure:
- Local do Azure
- Azure Arc
- Key Vault
- de Armazenamento de Blob do Azure
- Monitor
- Azure Policy
- Registro de Contêiner do Azure
- Defender for Cloud
- Site Recovery
- Backup
Módulos do Microsoft Learn:
- Configurar o Monitor
- Projete sua solução de recuperação de site no Azure
- Introdução aos servidores habilitados para Azure Arc
- Introdução aos serviços de dados habilitados para Azure Arc
- Introdução ao AKS
- Dimensione a implantação de modelos com o Machine Learning em qualquer lugar - Tech Community Blog
- Realizando o Machine Learning em qualquer lugar com o AKS e o Azure Arc-enabled Machine Learning - Blog da Comunidade Técnica
- Aprendizado de máquina no AKS híbrido e no Stack HCI usando o aprendizado de máquina habilitado para Azure Arc - Tech Community Blog
- Introdução ao destino de computação do Kubernetes no Machine Learning
- Mantenha suas VMs atualizadas
- Proteja suas configurações de VM com a configuração do estado de automação
- Proteja suas VMs usando o Backup