Arquitetura de referência de linha de base do Azure Stack HCI

Essa arquitetura de referência de linha de base fornece diretrizes e recomendações independentes de carga de trabalho para configurar a infraestrutura do Azure Stack HCI 23H2 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 cálculo, armazenamento e rede. Ela também descreve como usar os serviços do Azure para simplificar e agilizar o gerenciamento diário do Azure Stack HCI.

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

Essa arquitetura é um ponto de partida para usar o design de rede comutada de armazenamento para implantar um cluster do Azure Stack HCI de vários nós. Os aplicativos de carga de trabalho implantados em um cluster do Azure Stack HCI devem ser bem arquitetados. Os aplicativos de carga de trabalho bem arquitetados devem ser implantados usando várias instâncias ou alta disponibilidade de quaisquer serviços críticos de carga de trabalho e ter controles apropriados de continuidade de negócios e recuperação de desastres (BCDR) em vigor. Esses controles de BCDR incluem backups regulares e recursos de failover de recuperação de desastre. Para se concentrar na plataforma de infraestrutura de HCI, esses aspectos 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 Stack HCI Well-Architected Framework.

Layout do artigo

Arquitetura

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

Possíveis casos de uso

Os casos de uso típicos do Azure Stack HCI 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 satisfazer os requisitos de carga de trabalho. Você poderá:

• Forneça uma solução de nuvem híbrida implantada localmente para satisfazer os requisitos de soberania, regulamentação e conformidade ou latência de dados.

• Implante e gerencie cargas de trabalho de borda virtualizadas ou baseadas em contêiner de HA implantadas em um ou em vários locais. Essa estratégia permite que aplicativos e serviços essenciais aos negócios operem de maneira resiliente, econômica e escalável.

• Reduza o TCO (custo total de propriedade) usando soluções certificadas pela Microsoft, implantação baseada em nuvem, gerenciamento centralizado e monitoramento e alertas.

• Forneça uma funcionalidade 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 IaC (infraestrutura como código) usam o Kubernetes para conteinerização ou virtualização de carga de trabalho tradicional para impulsionar a automação e a repetibilidade.

• Cumpre requisitos rigorosos de segurança, conformidade e auditoria. O Azure Stack HCI é implantado com uma postura de segurança reforçada configurada por padrão ou segura por padrão. O Azure Stack HCI incorpora hardware certificado, Inicialização Segura, TPM (Trusted Platform Module), VBS (segurança baseada em virtualização), Credential Guard e políticas impostas pelo Windows Defender Application Control. Ele também se integra a serviços modernos de segurança e gerenciamento de ameaças baseados em nuvem, como Microsoft Defender para Nuvem e 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 Stack HCI.

Usar o Azure Arc com o Azure Stack HCI

O Azure Stack HCI se integra diretamente ao Azure usando o Azure Arc para reduzir o TCO e a sobrecarga operacional. O Azure Stack HCI é implantado e gerenciado por meio do Azure, que fornece integração interna do Azure Arc por meio da implantação do componente de ponte de recursos do Azure Arc. Esse componente é instalado durante o processo de implantação do cluster HCI. Os nós de cluster do Azure Stack HCI são registrados no Azure Arc para servidores como um pré-requisito para iniciar a implantação baseada em nuvem do cluster. Durante a implantação, extensões obrigatórias são instaladas em cada nó de cluster, como Lifecycle Manager, Microsoft Edge Device Management e 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 Azure Stack HCI Insights. As atualização de recursos do Azure Stack HCI são lançadas periodicamente para aprimorar a experiência do cliente. As atualizações são controladas e gerenciadas por meio do Azure Update Manager.

Você pode implantar recursos de carga de trabalho, como VMs (máquinas virtuais) do Azure Arc, 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 do cluster do Azure Stack HCI como o 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 Stack HCI, VMs do Windows Server e clusters do 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 Stack HCI para incluir:

• VMs do Azure Arc para aplicativos ou serviços tradicionais executados em VMs no Azure Stack HCI.

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

• Á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 Stack HCI (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 Stack HCI.

• A extensão da Grade de Eventos do Azure habilitada para Arc do Azure para Kubernetes para implantar o corretor 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.

• Machine learning habilitado para Azure Arc com um cluster do AKS implantado no Azure Stack HCI 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 do Azure Stack HCI, como automatizar a configuração do sistema operacional convidado com extensões de VM do Azure Arc ou avaliar a conformidade com os regulamentos do setor ou padrões corporativos por meio do Azure Policy. Você pode ativar o Azure Policy por meio do portal do Azure ou da automação de IaC.

Aproveite a configuração de segurança padrão do Azure Stack HCI

A configuração de segurança padrão do Azure Stack HCI fornece uma estratégia de defesa em profundidade 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 cargas de trabalho contra ameaças internas e externas é crucial em ambientes com suporte de TI limitado ou com falta de datacenters dedicados. O Azure Stack HCI 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 Stack HCI garante suporte interno à inicialização segura, à UEFI (Unified Extensible Firmware Interface) e ao TPM. Use essas tecnologias em combinação com o VBS para ajudar a proteger suas cargas de trabalho sensíveis à segurança. Você pode usar a Criptografia de Unidade de Disco BitLocker para criptografar volumes de disco de inicialização e volumes diretos de espaços de armazenamento 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 as normas regulatórias.

Além disso, você pode integrar VMs do Azure Stack HCI no Defender para Nuvem para ativar análises comportamentais baseadas em nuvem, detecção e correção de ameaças, alertas e relatórios. Gerencie VMs do Azure Stack HCI no Azure Arc para que você possa usar o Azure Policy para avaliar sua conformidade com os regulamentos do setor e normas corporativas.

Componentes

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

Recursos da plataforma

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

• O Azure Stack HCI é uma solução de HCI (infraestrutura hiperconvergente) implantada localmente ou em locais de borda usando hardware de servidor físico e infraestrutura de rede. O Azure Stack HCI fornece uma plataforma para implantar e gerenciar cargas de trabalho virtualizadas, como VMs, clusters do Kubernetes e outros serviços habilitados pelo Azure Arc. Os clusters do Azure Stack HCI podem ser dimensionados 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 (fabricantes de equipamentos originais).

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

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

• A testemunha de nuvem é um recurso do Armazenamento do Azure que atua como um quorum de cluster de failover. Os nós de cluster do Azure Stack HCI 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 do Azure Stack HCI.

• O Update Manager é um serviço unificado projetado para gerenciar e controlar atualizações para o Azure Stack HCI. Você pode usar o Gerenciador de Atualizações para gerenciar cargas de trabalho implantadas no Azure Stack HCI, incluindo a conformidade de atualização do sistema operacional convidado para VMs Windows e Linux. Essa abordagem unificada simplifica o gerenciamento de patches no Azure, em ambientes locais e em 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 aprimorar os recursos da plataforma:

• O Monitor é um serviço baseado em nuvem para coletar, analisar e agir em logs de diagnóstico e telemetria de suas cargas de trabalho locais e 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 Azure Stack HCI Insights para simplificar a criação da DCR (regra de coleta de dados) do Monitor e habilitar rapidamente o monitoramento de clusters do Azure Stack HCI.

• O Azure Policy é um serviço que avalia os recursos locais e do Azure. O Azure Policy avalia os recursos por meio da integração com o Azure Arc usando as propriedades desses recursos 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 da VM usando as configurações de política.

• O Defender para Nuvem é um sistema de gerenciamento de segurança de infraestrutura abrangente. Ele aprimora a postura de segurança de seus datacenters e oferece proteção avançada contra ameaças para cargas de trabalho híbridas, independentemente de residirem no Azure ou em outro lugar, e em ambientes locais.

• O Azure Backup é 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 Microsoft Cloud. O Servidor de Backup do Azure é usado para fazer backup de VMs implantadas no Azure Stack HCI e armazená-las no serviço de Backup.

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

Opções de projeto de cluster

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

• Recursos de arquitetura da unidade central de processamento (CPU), 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 unidade de processamento gráfico (GPU) da carga de trabalho, como IA ou aprendizado de máquina, 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 têm 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+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 quedas de energia ou falhas de hardware.

  • Para cargas de trabalho críticas para os negócios ou críticas, 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 de 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 do usuário. O espelhamento de três vias aumenta o desempenho e a confiabilidade máxima 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 é aproximadamente 33% do espaço de armazenamento bruto dos discos da camada de capacidade quando você usa o espelhamento de três vias.

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

Para projetar e planejar uma implantação do Azure Stack HCI, recomendamos que você use a ferramenta de dimensionamento do Azure Stack HCI e crie um Novo Projeto para dimensionar seus clusters HCI. O uso da 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 no 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 seção Preferências da ferramenta de dimensionamento orienta você por meio de perguntas relacionadas ao tipo de sistema (Premier, Sistema Integrado ou Nó Validado) e às opções da família de CPUs. Ele também ajuda você a selecionar seus requisitos de resiliência para o cluster. Não se esqueça:

• 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 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 do Azure Stack HCI é uma lista de SKUs de solução de hardware recomendados 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 de Dimensionador. Para obter mais informações sobre as soluções de parceiros de hardware OEM disponíveis, consulte Catálogo de soluções do Azure Stack HCI. Para ajudar a dimensionar corretamente os SKUs da solução para atender às suas necessidades, entre em contato com seu provedor de soluções de hardware preferido ou parceiro de integração de sistemas (SI).

Unidades de disco físico

Os Espaços de Armazenamento Diretos dão suporte a vários tipos de unidade de disco físico que variam em desempenho e capacidade. Ao criar um cluster do Azure Stack HCI, 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 de sua carga de trabalho. Os exemplos incluem unidades de disco rígido (HDDs) giratórias ou unidades de estado sólido (SSDs) e unidades NVMe. Essas unidades geralmente são chamadas de unidades flash ou armazenamento de memória persistente (PMem), conhecido 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, entre outras, tecnologias de banco de dados altamente transacionais, clusters AKS de produção ou cargas de trabalho críticas 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. As configurações de unidade totalmente NVMe ou unidade totalmente SSD, especialmente em pequena escala, melhoram a eficiência do armazenamento e maximizam o desempenho porque nenhuma unidade é usada como uma camada de cachePara 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 desempenho inferior se sua carga de trabalho exceder o conjunto de trabalho do cache, e os HDDs têm um valor médio de tempo entre falhas menor em comparação com as unidades NVMe e SSD.

O desempenho do armazenamento de 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 de Espaços de Armazenamento Diretos. Dependendo das cargas de trabalho e restrições de orçamento do Azure Stack HCI, você pode optar por maximizar o desempenho, maximizar a capacidade ou implementar uma configuração de unidade que forneça equilíbrio entre desempenho e capacidade.

O Storage Spaces Direct fornece um cache do servidor interno, persistente, em tempo real e de leitura e gravação 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 de Espaços de Armazenamento Diretos, ou volumes, são usados em combinação com o cache de leitura na memória CSV (volume compartilhado clusterizado) para melhorar o desempenho do Hyper-V, especialmente para acesso de entrada sem buffer a arquivos VHD (disco rígido virtual) ou VHDX (disco rígido virtual v2) de carga de trabalho.

Design de rede

O design de rede é o arranjo 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í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 diretrizes de exemplo sobre como implantar um cluster do Azure Stack HCI de vários nós usando a arquitetura de rede comutada de armazenamento com duas portas de adaptador de rede que são 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 Stack HCI.

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 switches Top-of-Rack (ToR). Os dois switches ToR devem ser interconectados por meio de links de grupo de agregação de enlaces (MLAG) de vários chassis. As duas portas do adaptador de rede usadas para o tráfego de intenção de armazenamento devem dar suporte ao 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 (agrupamento incorporado ao switch). A tecnologia SET fornece recursos de redundância de link e 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 criar uma implantação do Azure Stack HCI comutada por armazenamento de vários nós que usa essa arquitetura de linha de base:

• Interruptores ToR duplos:

  • Os switches de rede ToR duplos são necessários para resiliência de 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 redes locais virtuais (VLANs) de armazenamento específicas e classes de tráfego de controle de fluxo prioritário (PFC) definidas para fornecer comunicação RDMA sem perdas.

  • Esses switches 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 um dos dois comutadores 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 um dos dois comutadores 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 comutadores roteiam o tráfego que entra e sai do cluster do Azure Stack HCI ou do tráfego norte-sul.

  • A conectividade de tráfego externo-norte-sul dá suporte à intenção de gerenciamento de cluster e às intenções de computação. Isso é obtido usando duas portas de comutador e duas portas de adaptador de rede por nó que são convergidas por meio do SET (agrupamento inserido de comutador) e um comutador virtual no 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 multinó para o Azure Stack HCI é o seguinte:

• Interruptores ToR duplos:

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

• O Azure Stack HCI usa a abordagem ATC de Rede para aplicar a automação de rede e a configuração de rede baseada em intenção.

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

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

• 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 anterior de topologia de rede física.

  • 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 de rede de gerenciamento usa a interface virtual da equipe SET convergente, que permite que o endereço IP de gerenciamento do cluster e os recursos do plano de controle se comuniquem externamente.

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

• Tráfego de armazenamento:

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

  • As portas de armazenamento SMB1 e SMB2 se conectam a duas redes separadas não roteáveis (ou de Camada 2). Cada rede tem um ID VLAN específico configurado que deve corresponder à configuração das portas do switch nos IDs 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 do nó do Azure Stack HCI.

  • 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 SMB-Direct RDMA nas duas portas dedicadas do adaptador de rede de armazenamento disponíveis em cada nó. O SMB Multicanal é usado para fins de 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 do switch de rede

Seus comutadores Ethernet devem atender às diferentes especificações exigidas pelo Azure Stack HCI e definidas pelo IEEE SA (Institute of Electrical and Electronics Engineers Standards Association). Por exemplo, para implantações comutadas de armazenamento multinode, a rede de armazenamento é usada para RDMA via RoCE v2 ou iWARP. Esse processo requer IEEE 802.1Qbb PFC para garantir a 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 Stack HCI, examine 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, entre em contato com o fornecedor do comutador para garantir que os dispositivos atendam aos requisitos de especificação IEEE do Azure Stack HCI ou examine a lista de modelos de comutador certificados pelo fornecedor de hardware que dão suporte aos requisitos de rede do Azure Stack HCI.

Requisitos de endereço IP

Em uma implantação comutada de armazenamento multinode, 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 Stack HCI, a infraestrutura de cluster requer que um mínimo de 11 x endereços IP sejam alocados. Mais endereços IP serão necessários se você usar microssegmentação ou rede definida por software. Para obter mais informações, consulte Examinar os requisitos de endereço IP do padrão de referência de armazenamento de dois nós para o Azure Stack HCI.

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

Monitoramento

Para aprimorar o monitoramento e os alertas, habilite o Monitor Insights no Azure Stack HCI. 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 do Azure Stack HCI. Os logs são coletados pelo DCR configurado por meio do Monitor e do Log Analytics.

O Azure Stack HCI Insights é criado usando o Monitor e o Log Analytics, o que garante uma solução escalonável e sempre atualizada que é 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 Stack HCI. 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 de alerta de integridade de recursos personalizadas.

Gerenciamento de atualizações

Os clusters do Azure Stack HCI 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 melhora 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 Stack HCI é 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 aos clusters do Azure Stack HCI para mantê-los atualizados. Além das atualizações regulares de build de linha de base, o Azure Stack HCI é 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 do Azure Stack HCI. Esse serviço fornece um mecanismo para exibir todos os clusters do Azure Stack HCI em toda a infraestrutura e locais de borda usando o portal do Azure para fornecer uma experiência de gerenciamento centralizada. Para saber mais, consulte os recursos a seguir:

• Informações de versão do Azure Stack HCI

• Cadência do ciclo de vida do Azure Stack HCI

• Examinar as fases de atualização do Azure Stack HCI

• Usar o Azure Update Manager para atualizar o Azure Stack HCI

É importante verificar regularmente se há novas atualizações de driver e firmware, como a cada três a seis meses. Se você usar uma versão de categoria de solução Premier para o hardware do Azure Stack HCI, as atualizações do pacote de Extensão do Construtor de Soluções serão integradas ao Gerenciador de Atualizações para fornecer uma experiência de atualização simplificada. Se você usar nós validados ou uma categoria de sistema integrado, 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 o OEM de hardware ou parceiro de SI.

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

Você pode registrar VMs do Azure Arc implantadas no Azure Stack HCI usando o AUM (Azure Update Manager) para fornecer uma experiência unificada de gerenciamento de patches usando o mesmo mecanismo usado para atualizar os nós físicos do cluster do Azure Stack HCI. Você pode usar o AUM para criar configurações de manutenção de convidado. Essas configurações controlam as definições, como a definição de reinicialização 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

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

Identificar os possíveis pontos de falha

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

Para obter mais informações, consulte Recomendações para executar uma análise de modos de falha.

Metas 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 Stack HCI. 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% com a qual os stakeholders de negócios e aplicativos concordam para seus serviços.

• Um SLO de 99,8% de 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 Stack HCI:

  • Semanalmente: 20 minutos e 10 segundos

  • Mensalmente: 1 hora, 26 minutos e 56 segundos

  • Trimestralmente: 4 horas, 20 minutos e 49 segundos

  • Anualmente: 17 horas, 23 minutos e 16 segundos

• Para ajudar a atender às metas de SLO, a Contoso Manufacturing implementa o princípio de PoLP (privilégio mínimo) para restringir o número de administradores de cluster do Azure Stack HCI 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 locais do AD DS (Active Directory Domain Services) são monitorados para detectar e relatar quaisquer alterações de associação de grupo de contas de usuário, conhecidas como ações de adição e remoção, para o grupo de administradores de cluster do Azure Stack HCI usando uma solução de 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 de gerenciamento de identidade e acesso.

• Procedimentos rígidos 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 em produção. Todas as alterações enviadas ao processo do conselho consultivo de alterações semanais 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ções pós-lançamento e critérios de sucesso claros para que uma alteração seja revisada ou aprovada.

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

• Os patches de segurança mensais e as atualizações trimestrais de linha de base são aplicados aos clusters de produção do Azure Stack HCI somente depois de serem 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 da migração dinâmica da 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 da data de lançamento. Sem essa política, os sistemas de produção são perpetuamente incapazes de se manter atualizados com as 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.

• A Contoso Manufacturing implementa backups diários, semanais e mensais para reter os últimos 6 dias de backups diários (de segunda a sábado), os últimos 3 x semanais (todos os domingos) e 3 backups mensais, com cada domingo da semana 4 sendo retido para se tornar os backups do mês 1, mês 2 e mês 3 usando um agendamento baseado em calendário contínuo documentado 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 de custos para o serviço de armazenamento de backup externo ou em nuvem.

  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 de BCDR são válidos e que os negócios estão protegidos se ocorrer um desastre no datacenter ou um 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 para o Azure Stack HCI permitem que a Contoso Manufacturing atenda à meta de SLO de 99,8% e dimensione e gerencie efetivamente as implantações do Azure Stack HCI e da carga de trabalho em vários locais de fabricação distribuídos em todo o mundo.

  Para saber mais, confira Recomendações para definir destinos de confiabilidade.

Redundância

Considere uma carga de trabalho que você implanta em um único cluster do Azure Stack HCI como uma 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 críticos para os negócios ou críticos, recomendamos que você implante várias instâncias de uma carga de trabalho ou serviço em dois ou mais clusters separados do Azure Stack HCI, 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 clusters do Azure Stack HCI implantados 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 projetar para redundância.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

As considerações de segurança incluem:

• Uma base segura para a plataforma Azure Stack HCI: o Azure Stack HCI é 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 Azure Stack HCI e a segurança da carga de trabalho. Quando implantado com as configurações de segurança padrão, o Azure Stack HCI tem o Windows Defender Application Control, 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 Stack HCI, como Administrador do Azure Stack HCI para administradores de plataforma e Colaborador de VM do Azure Stack HCI ou Leitor de VM do Azure Stack HCI para operadores de carga de trabalho.

• Configurações de segurança padrão: o padrão de segurança do Azure Stack HCI aplica as configurações de segurança padrão para o cluster do Azure Stack HCI durante a implantação e permite o controle de descompasso para 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 desvios e as configurações do servidor núcleo protegido em seu cluster.

• Logs de eventos de segurança: o encaminhamento de syslog do Azure Stack HCI se integra à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: o Defender para Nuvem protege seus clusters do Azure Stack HCI contra várias ameaças e vulnerabilidades. Esse serviço ajuda a melhorar a postura de segurança do ambiente do Azure Stack HCI e pode proteger contra ameaças existentes e em evolução.

• Detecção e correção de ameaças: o 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 cluster do Azure Stack HCI e suas cargas de trabalho de VM do Windows Server.

• Isolamento de rede: isole as 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, verifique se a rede de gerenciamento pode alcançar cada rede lógica e VLAN para que os nós de cluster do Azure Stack HCI possam se comunicar com as redes VLAN por meio dos comutadores 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 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 é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

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

• Modelo de cobrança em estilo de nuvem para licenciamento: Os preços do Azure Stack HCI seguem o modelo de cobrança de assinatura mensal com uma taxa fixa por núcleo de processador físico em um cluster Azure Stack HCI. Taxas de uso adicionais também podem ser aplicadas se você usar outros serviços do Azure. Se você tiver licenças principais locais para a edição Windows Server Datacenter com Software Assurance ativo, poderá optar por trocar essas licenças para ativar o cluster do Azure Stack HCI 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 da aplicação de patch manual e os custos de manutenção associados. Essa ação não apenas 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 Azure Stack HCI Insights e aplique patches usando o Update Manager para Azure Stack HCI. 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 Stack HCI se integra ao Gerenciador de Atualizações para simplificar a tarefa de manter seus clusters atualizados, consolidando fluxos de trabalho de atualização para vários componentes em uma única experiência. Use o Monitor e o 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 de pessoal.

• Capacidade e crescimento da carga de trabalho inicial: ao planejar a implantação do Azure Stack HCI, considere a capacidade inicial da carga de trabalho, os requisitos de resiliência e as considerações de crescimento futuro. Considere se o uso de uma arquitetura sem comutador de armazenamento de dois ou três nós pode reduzir custos, como eliminar a necessidade de adquirir comutadores de rede de classe de armazenamento. A aquisição de comutadores de rede de classe de armazenamento extra pode ser um componente caro de novas implantações de cluster do Azure Stack HCI. Em vez disso, você pode usar switches 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 usar a arquitetura sem comutador de armazenamento de três nós para implantar o Azure Stack HCI.

  Para obter mais informações, consulte Recomendações para otimizar os custos dos componentes.

Excelência operacional

A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.

As considerações sobre a 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 um cluster do Azure Stack HCI. Da mesma forma, o Azure simplifica o processo de gerenciamento de clusters do Azure Stack HCI e VMs do Azure Arc. Você pode automatizar a implantação baseada em portal do cluster do Azure Stack HCI usando o modelo do ARM. Este modelo fornece consistência e automação para implantar o Azure Stack HCI em escala, especificamente em cenários de borda, como lojas de varejo ou locais de fabricação que exigem um cluster do Azure Stack HCI para executar cargas de trabalho comercialmente críticas.

• Recursos de automação para máquinas virtuais: o Azure Stack HCI fornece uma ampla variedade 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 o modelo CLI do Azure, ARM ou Bicep, com atualizações do sistema operacional da máquina virtual usando a Extensão do Azure Arc para Atualizações e o Azure Update Manager para atualizar cada cluster do Azure Stack HCI. O Azure Stack HCI também fornece suporte para o 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 a partir de um dos servidores HCI do Azure Stack ou remotamente a partir de um computador de gerenciamento. A integração com a 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 de extensões do Azure Arc.

  Para obter mais informações, consulte as Recomendações para uso de IaC.

• Recursos de automação para contêineres no AKS: o Azure Stack HCI fornece uma ampla variedade 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 o AKS habilitado para Azure Arc usando a CLI do Azure. Você pode executar comandos da CLI do Azure localmente a partir de um dos servidores HCI do Azure Stack ou remotamente a partir de um computador de gerenciamento. Integre-se ao Azure Arc para uma ampla variedade 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 a automação.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

As considerações sobre a eficiência de desempenho incluem:

• 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 um cluster do Azure Stack HCI. Você pode usar a ferramenta VMFleet para gerar carga e medir o desempenho de um subsistema de armazenamento. Avalie se você deve usar o VMFleet para medir o desempenho do subsistema de armazenamento.

  • Recomendamos que você estabeleça uma linha de base para o desempenho dos clusters do Azure Stack HCI 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 saber mais, consulte Recomendações para testes de desempenho.

• 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 dos volumes do Azure Stack HCI 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. 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 de usuário.

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

• Otimização do desempenho da rede: considere a otimização do desempenho da 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 de hardware de rede ideal.

  • Para otimizar o desempenho de computação no Azure Stack HCI, você pode usar a aceleração de GPU. A aceleração de 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 locais de borda 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 seus clusters do Azure Stack HCI.

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

Implantar este 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 Stack HCI, 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 de acordo com os 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 ou local 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 de casos de uso potenciais deste artigo. As etapas restantes pressupõem que o Azure Stack HCI seja a solução de plataforma de infraestrutura escolhida para o projeto.

1. Reúna os requisitos de carga de trabalho e caso de uso das partes interessadas relevantes. Essa estratégia permite que o projeto confirme se os recursos e as funcionalidades do Azure Stack HCI atendem aos requisitos de escala de carga de trabalho, desempenho e funcionalidade. Esse processo de revisão deve incluir a compreensão da escala ou 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 de RTO e RPO (confiabilidade) da carga de trabalho e outros requisitos não funcionais (desempenho/escalabilidade de carga) devem ser documentados como parte dessa etapa de coleta de requisitos.

2. Examine a saída do dimensionador do Azure Stack HCI para obter a solução de parceiro de hardware recomendada. Essa saída inclui detalhes da marca e do modelo de hardware de servidor físico recomendados, o 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.

3. Use a ferramenta de dimensionamento do Azure Stack HCI para criar um novo projeto que modele o tipo e a escala da carga de trabalho. Este projeto inclui o tamanho e o número de VMs e seus requisitos de armazenamento. Esses detalhes são inseridos junto com as opções para o tipo de sistema, a 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.

4. Examine a saída do dimensionador do Azure Stack HCI para obter a solução de parceiro de hardware recomendada. Esta solução inclui detalhes da marca e do modelo de hardware de servidor físico recomendados, o 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.

5. Entre em contato com o parceiro OEM ou SI de hardware para qualificar ainda mais a adequação da versão de hardware recomendada em relação aos 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 OEM de hardware ou parceiro de SI para os aspectos comerciais da solução. Esses aspectos 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.

6. Implante dois switches ToR para integração de rede. Para soluções de alta disponibilidade, os clusters HCI exigem que dois switches ToR sejam implantados. Cada nó físico requer quatro NICs, duas das quais devem ser compatíveis com RDMA, o que fornece dois links de cada nó para os dois switches ToR. Duas NICs, uma conectada a cada switch, 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 de armazenamento. Se você planeja usar comutadores de rede existentes, verifique se a marca e o modelo de seus comutadores estão na lista aprovada de comutadores de rede compatíveis com o Azure Stack HCI.

7. Trabalhe com o parceiro OEM ou SI de hardware para providenciar a entrega do hardware. O parceiro de SI ou seus funcionários precisam integrar o hardware ao datacenter local ou ao local de borda, como racking e empilhamento do hardware, da rede física e do cabeamento da unidade de fonte de alimentação para os nós físicos.

8. Execute a implantação do cluster do Azure Stack HCI. Dependendo da versão da solução escolhida (solução Premier, sistema integrado ou nós validados), o parceiro de hardware, o parceiro de SI ou seus funcionários podem implantar o software Azure Stack HCI. Esta etapa começa integrando os nós físicos do sistema operacional do Azure Stack HCI em servidores habilitados para Azure Arc e, em seguida, iniciando o processo de implantação de nuvem do Azure Stack HCI. Os 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 o 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 de cluster do Azure Stack HCI 23H2 demonstra como implantar uma implantação multisservidor comutada do Azure Stack HCI usando um modelo do ARM e um arquivo de parâmetro. Como alternativa, o exemplo do Bicep demonstra como usar um modelo do Bicep para implantar um cluster do Azure Stack HCI, incluindo seus recursos de pré-requisitos.

9. Implante cargas de trabalho altamente disponíveis no Azure Stack HCI usando o portal do Azure, a CLI ou os modelos do ARM + Azure Arc para automação. Use o recurso de local personalizado do novo cluster HCI como a região de destino ao 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 conteinerização no Azure Stack HCI.

10. Instale atualizações mensais para melhorar a segurança e a confiabilidade da plataforma. Para manter seus clusters do Azure Stack HCI atualizados, é importante instalar atualizações de software da Microsoft e atualizações de driver e firmware 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 em vários clusters. Verifique com 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 saber mais, veja atualizações de infraestrutura.

Recursos relacionados

• Projeto de arquitetura híbrida
• Opções híbridas do Azure
• Automação em um ambiente híbrido
• State Configuration da 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:

• Informações sobre a versão do Azure Stack HCI, versão 23H2
• AKS no Azure Stack HCI
• Área de Trabalho Virtual do Azure para o Azure Stack HCI
• O que é o monitoramento do Azure Stack HCI?
• Proteger cargas de trabalho de VM com o Site Recovery no Azure Stack HCI
• Visão geral do Monitor
• Visão geral do Controle de Alterações e Inventário
• Visão Geral do Gerenciador de Atualizações
• 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 detalhes sobre serviços específicos do Azure:

• Azure Stack HCI
• Azure Arc
• Key Vault
• Armazenamento de Blobs do Azure
• Monitorar
• Azure Policy
• Registro de Contêiner do Azure
• Defender para Nuvem
• Recuperação de Site
• Backup

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 ao AKS
• Dimensione a implantação de modelos com Machine Learning em qualquer lugar - Tech Community Blog
• Realizando o Machine Learning em qualquer lugar com o AKS e o Machine Learning habilitado para Azure Arc - Tech Community Blog
• Machine Learning no AKS híbrido e no Stack HCI usando o Machine Learning habilitado para Azure Arc - Tech Community Blog
• Introdução ao destino de computação do Kubernetes em Machine Learning
• Manter suas VMs atualizadas
• Proteger as configurações da VM com a configuração de estado de automação
• Proteger suas VMs usando o Backup