Essa arquitetura de referência de linha de base fornece diretrizes e recomendações independentes de carga de trabalho para configurar o Azure Local, versão 23H2, versão 2311 e infraestrutura posterior para garantir uma plataforma confiável que possa implantar e gerenciar 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 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 simplificar o gerenciamento diário do Azure Local.
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
Arquitetura | Decisões de design | Abordagem do Well-Architected Framework |
---|---|---|
▪ de arquitetura do ▪ 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 ▪ de design de rede ▪ Monitoramento ▪ |
▪ de Confiabilidade ▪ security ▪ de otimização de custo ▪ de excelência operacional ▪ de eficiência de desempenho |
Ponta
o modelo local do Azure demonstra como usar um modelo do ARM (modelo do ARM) 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.
Arquitetura
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 ou locais 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 localmente para atender aos requisitos de soberania, regulamentação e conformidade ou latência de dados.
Implante e gerencie cargas de trabalho de borda baseadas em contêiner ou virtualizadas em HA implantadas em um único local ou em vários locais. Essa estratégia permite que aplicativos e serviços comercialmente críticos operem de maneira resiliente, econômica e escaloná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 uma funcionalidade de provisionamento centralizada 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 IaC (infraestrutura como código) usam o Kubernetes para contêinerização ou virtualização de carga de trabalho tradicional para impulsionar a automação e a repetibilidade.
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 seguro 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 impostas do Controle de Aplicativos do Windows Defender. Ele também se integra aos modernos serviços de segurança e gerenciamento de ameaças baseados em nuvem, como o Microsoft Defender para Nuvem 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 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 é instalado durante o processo de implantação do cluster HCI. Os nós de cluster local do Azure são registrados com Azure Arc para servidores como um pré-requisito para iniciar a implantação baseada em nuvem do cluster. Durante a implantação, as extensões obrigatórias são instaladas em cada nó de cluster, como o Gerenciador de Ciclo de Vida, o Gerenciamento de Dispositivos do Microsoft Edge e a Telemetria e Diagnóstico. Você pode usar o Azure Monitor e o Log Analytics para monitorar o cluster HCI após a implantação habilitando o Insights para o Azure Local. Atualizações de recursos do Azure Local são lançadas periodicamente para aprimorar a experiência do cliente. As atualizações são controladas e gerenciadas por meio do 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 do Azure Arc 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 do Azure Arc ou avaliar a conformidade com regulamentos do setor ou padrões corporativos por meio de 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 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 (Server Message Block) fornece criptografia automática de tráfego entre servidores no cluster (na rede de armazenamento) e assinatura de tráfego SMB entre os nós de 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 do Azure Policy para avaliar sua conformidade com regulamentos do setor e padrões corporativos.
Componentes
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:
Local do Azure é uma solução de HCI (infraestrutura hiperconvergente) implantada localmente ou em locais de borda usando infraestrutura de rede e hardware de servidor físico. 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 equipamentos originais).
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 não 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 do Armazenamento do Azure que atua como um quorum de cluster de failover. Os nós de cluster local do Azure usam esse 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.
Update Manager é um serviço unificado projetado para gerenciar e controlar atualizações para o 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. 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:
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.
do 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 simples, 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.
site recovery é um serviço de recuperação de desastre que fornece recursos 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 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 alternância de armazenamento .
Para manter a resiliência da computação, você precisa reservar pelo menos N+1 nós de capacidade no cluster. 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 n+2 nós de capacidade 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 em que 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 do armazenamento:
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á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 copia, é 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 Azure Local e crie um novo projeto para dimensionar seus clusters HCI. 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 seu cluster, considere fatores como o número de vCPUs, os requisitos de memória e a capacidade de armazenamento necessária para as VMs.
A ferramenta de dimensionamento preferências seção 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 o cluster. Certifique-se de:
Reserve um mínimo de N+1 nós de capacidade ou um nó em todo o cluster.
Reserve N+2 nós de capacidade em todo o cluster para resiliência extra. Essa opção permite que o sistema resista a uma falha de nó durante uma atualização ou outro evento inesperado que afeta 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 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
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 armazenamento baseado em flash.
Para cargas de trabalho de uso geral, uma 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 desvantagem é que os discos giratórios têm um desempenho menor 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.
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 maximizarde desempenho, maximizarde capacidade ou implementar uma configuração de tipo de unidade mista que balanceia o desempenho e a capacidade.
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 dos Espaços de Armazenamento ou volumessão usados em combinação com o cache de leitura na memória do CSV (volume compartilhado de cluster) para melhorar Hyper-Vde desempenho, especialmente para acesso de entrada não permitido ao VHD (disco rígido virtual) de carga de trabalho ou arquivos VHDX (disco rígido virtual v2).
Ponta
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 nós 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 do NVMe + SSD, não há capacidade reservada para cache. 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 multinode 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 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 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 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 esta arquitetura de linha de base:
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 nós por meio 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 sistema operacional Azure Stack HCI.
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í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 nó 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 do Azure Arc 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 multinodo para o Azure Local é o seguinte:
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 dede gerenciamento de
, de computação e portas de de 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.
- 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 dede gerenciamento de
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 o tráfego de rede intenções. 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 ode gerenciamento de
de cluster, carga de trabalho de computação e intenções de 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 nó 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 nós 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 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 dedicadas do adaptador de rede 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 conectam-se a duas redes não existentes (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ó pode acessar as funcionalidades dos 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 que estão disponíveis em cada nó. 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 multinode, 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 comutada de armazenamento de 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 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 microssegmentaçã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.
Monitorização
Para aprimorar o monitoramento e alertas, habilite Monitorar Insights no Azure Local. Os insights podem ser dimensionados 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 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 do Azure Arc, 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 novas compilações de linha de base trimestralmente. Os builds de linha de base são aplicados às instâncias locais do Azure para mantê-los atualizados. Além das atualizações regulares de build de linha de base, o Azure Local é atualizado com atualizações mensais de segurança e confiabilidade do sistema operacional.
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:
usar o Gerenciador de Atualizações do Azure para atualizar a Local do Azure
É 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 integrada, 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 do Azure Arc implantadas no Azure Local usando AUM (Azure Update Manager) para fornecer uma experiência unificada de gerenciamento de patch 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 configurações como a configuração de reinicialização reinicialização 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ê faz aos seus clientes. Para obter mais informações, consulte Visão geral do pilar de 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:
Componente | Risco | Probabilidade | Efeito/mitigação/observação | 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 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 do Azure Arc 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 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 um único computador local do Azure, sua instância local do Azure deve ter vários nós físicos. Os requisitos de capacidade de carga de trabalho durante a fase de design do cluster determinam o número de nós. Recomendamos que você tenha três ou mais nós. Também recomendamos que você use 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 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. | Possível interrupção |
VM do Azure Arc ou nó de trabalho do AKS (carga de trabalho) | Errada | Média | 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 | 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 conectividade com o Azure, ele funcionará em um estado degradado. Por exemplo, não seria possível implantar novas VMs do Azure Arc ou clusters AKS se o cluster perdesse conectividade com o Azure. As cargas de trabalho existentes em execução no cluster HCI continuam em execução, 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.
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 do Azure Arc 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 alterações de associação de grupo de contas de usuário, conhecidas como adicionar e remover ações de, para os administradores de instância local do grupo usando uma solução siEM (gerenciamento de eventos de informações de segurança). 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 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.
Redundância
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 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 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 Aplicativos do Windows Defender, 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: 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 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 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.
de detecção e correção de ameaças: Microsoft Advanced Threat Analytics detecta e corrige ameaças, como aquelas 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.
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 nós de 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 custo
A otimização de custos é sobre a busca de maneiras 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 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 do Azure Arc: 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.
de consolidação de monitoramento de custos: para consolidar os custos de monitoramento, use Insights para Locais do Azure e patch usando Update Manager para aLocal do Azure. 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 Localintegrates com o 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 ou três 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, o que simplifica 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 três 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 de três nós para implantar o Azure Local.
Para obter mais informações, consulte Recomendações para otimizar os custos de componente.
Ponta
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 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 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 do ARM. Esse 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 comercialmente críticas.
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 a CLI do Azure, o ARM ou o modelo Bicep, com atualizações do sistema operacional da Máquina Virtual usando a Extensão do Azure Arc para Atualizações e o Gerenciador de Atualizações do Azure para atualizar cada instância local do Azure. O Azure Local também oferece suporte para de gerenciamento de VM do Azure Arc usando a CLI do Azure e VMs não Azure Arc usando o Windows PowerShell. Você pode executar comandos da CLI do Azure localmente de um dos computadores locais do Azure ou remotamente de um computador de gerenciamento. A integração com o de Automação do Azure e o Azure Arc facilita uma ampla gama de cenários de automação extra para cargas de trabalho de VM por meio de extensões do Azure Arc.
Para obter mais informações, consulte Recomendações para usar 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 do AKS usando a CLI do Azure. Atualize os clusters de carga de trabalho do AKS usando a extensão do Azure Arc para atualizações do Kubernetes . Você também pode gerenciar do AKS habilitado para Azure Arc usando a CLI do Azure. Você pode executar comandos da CLI do Azure localmente de um dos computadores locais do Azure ou remotamente de um computador de gerenciamento. Integre-se ao Azure Arc para uma ampla gama de cenários de automação extra para cargas de trabalho em contêineres por meio de extensões do Azure Arc.
Para obter mais informações, consulte Recomendações para habilitar ode automação.
Eficiência de desempenho
A eficiência de desempenho é a capacidade da sua carga de trabalho de dimensionar para atender às demandas colocadas nele pelos usuários de maneira eficiente. Para obter mais informações, consulte Visão geral do pilar de 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 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 nós, 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.
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 do Azure Arc, 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.
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 do modelo de hardware do servidor físico recomendados, 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.
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.
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 nós físicos e as especificações para a configuração de CPU, memória e armazenamento de cada nó físico necessário para implantar e executar suas cargas de trabalho.
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.
Implantar dois comutadores ToR parade integração de rede. Para soluções de alta disponibilidade, os clusters HCI exigem que duas opções de ToR sejam implantadas. Cada nó físico requer quatro NICs, duas das quais devem ser compatíveis com RDMA, que fornece dois links de cada nó 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.
Trabalhar com o parceiro OEM ou SI de hardware para organizar a entrega dode hardware. O parceiro si ou seus funcionários são entã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 nós físicos.
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 nós físicos do 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.
Ponta
o sistema operacional Azure Stack HCI, a implementação de referência do sistema versão 23H2 demonstra como implantar uma implantação multisservidor 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.
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 local personalizado recurso do novo cluster HCI como a região de destino quando você 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 serviços habilitados para Azure Arc que você pode habilitar por meio de extensões do AKS e contêinerização no Azure Local.
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 Update Manager 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.
Recursos relacionados
- de design de arquitetura híbrida
- opções híbridas do Azure
- Automação em um ambiente híbrido
- de Configuração de Estado de Automação do Azure
- Otimizar a administração de instâncias do SQL Server em ambientes locais e multinuvem usando o Azure Arc
Próximas etapas
Documentação do produto:
- sistema operacional Azure Stack HCI, versão 23H2, informações de versão
- AKS no Local do Azure
- Área de Trabalho Virtual do Azure para a Local do Azure
- O que é o monitoramento local do Azure?
- proteger cargas de trabalho de VM com o Site Recovery no Azure Local
- visão geral do Monitor
- controle de alterações e visão geral do inventário
- visão geral do Gerenciador de Atualizações
- Quais são os 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
- do Azure Arc
- do Key Vault
- de Armazenamento de Blobs do Azure
- Monitor
- do Azure Policy
- registro de contêiner do Azure
- Defender para Nuvem
- do Site Recovery
- de Backup do
Módulos do Microsoft Learn:
- Configurar o Monitor
- Projetar 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 à do AKS
- implantação do modelo de escala de com o Machine Learning em qualquer lugar – do Blog da Comunidade Técnica
- Realizando o Machine Learning em qualquer lugar com o AKS e o Machine Learning habilitado para Azure Arc – Blog da Comunidade Tecnológica
- machine learning no AKS híbrido e stack HCI usando o aprendizado de máquina habilitado para Azure Arc – Blog da Comunidade Técnica
- introdução ao destino de computação do Kubernetes no do Machine Learning
- manter suas VMs atualizadas
- Proteger suas configurações de VM com a configuração de estado de Automação
- proteger suas VMs usando o Backup