Editar

Partilhar via


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

Azure Stack HCI
Azure Arc
Azure Key Vault
Azure Blob Storage
Azure Monitor
Microsoft Defender for Cloud

Esta arquitetura de referência de linha de base fornece orientações e recomendações independentes da carga de trabalho para configurar o Azure Stack HCI 23H2 e infraestrutura posterior para garantir uma plataforma confiável que possa implantar e gerenciar cargas de trabalho virtualizadas e conteinerizadas altamente disponíveis. Essa arquitetura descreve os componentes de recursos e as opções de design de cluster para os nós físicos que fornecem recursos locais de computação, armazenamento e rede. Ele também descreve como usar os serviços do Azure para simplificar e agilizar o gerenciamento diário do Azure Stack HCI.

Para obter mais informações sobre padrões de arquitetura de carga de trabalho otimizados para execução 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 como usar o design de rede comutada de armazenamento para implantar um cluster HCI do Azure Stack de vários nós. Os aplicativos de carga de trabalho implantados em um cluster HCI do Azure Stack devem ser bem arquitetados. Aplicativos de carga de trabalho bem arquitetados devem ser implantados usando várias instâncias ou alta disponibilidade de quaisquer serviços de carga de trabalho críticos e ter controles BCDR (Business Continuity and Disaster Recovery) apropriados. Esses controles BCDR incluem backups regulares e recursos de failover de recuperação de desastres. Para se concentrar na plataforma de infraestrutura HCI, esses aspetos de design de carga de trabalho são intencionalmente excluídos deste artigo.

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

Layout do artigo

Arquitetura Decisões de conceção Abordagem de estrutura bem arquitetada
Arquitetura
Casos de uso potenciais
Detalhes do cenário
Recursos da plataforma
Recursos de suporte à plataforma
Implantar este cenário
Opções de design de cluster
Unidades de disco físicas
Design de rede
Monitorização
Gerenciamento de atualizações
Fiabilidade
Segurança
Otimização de custos
Excelência operacional
Eficiência de desempenho

Gorjeta

Logótipo do GitHub A implementação de referência de cluster do Azure Stack HCI 23H2 demonstra como usar um modelo de Gerenciamento de Recursos do Azure (modelo ARM) e um arquivo de parâmetro para implantar uma implantação multisservidor comutada do Azure Stack HCI. Como alternativa, o exemplo Bicep demonstra como usar um modelo Bicep para implantar um cluster HCI do Azure Stack e seus recursos de pré-requisitos.

Arquitetura

Diagrama que mostra uma arquitetura de referência de cluster HCI do Azure Stack com dois switches Top-of-Rack (ToR) para conectividade externa norte-sul.

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

Potenciais casos de utilização

Os casos de uso típicos do Azure Stack HCI incluem a capacidade de executar cargas de trabalho de alta disponibilidade (HA) em locais locais ou de borda, o que fornece uma solução para atender aos requisitos de carga de trabalho. Pode:

  • Forneça uma solução de nuvem híbrida implantada no local para atender aos requisitos de soberania, regulamentação e conformidade de dados ou latência.

  • Implante e gerencie cargas de trabalho de borda virtualizadas por HA ou baseadas em contêiner que são implantadas em um único local ou em vários locais. Essa estratégia permite que aplicativos e serviços críticos para os negócios operem de forma resiliente, econômica e escalável.

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

  • Forneça um recurso de provisionamento centralizado usando o Azure e o Azure Arc para implantar cargas de trabalho em vários locais de forma consistente e segura. Ferramentas como o portal do Azure, a CLI do Azure ou modelos de infraestrutura como código (IaC) usam o Kubernetes para conteinerização ou virtualização de carga de trabalho tradicional para impulsionar a automação e a repetibilidade.

  • Cumpra requisitos rigorosos de segurança, conformidade e auditoria. O Azure 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), segurança baseada em virtualização (VBS), Credential Guard e políticas de Controle de Aplicativo do Windows Defender impostas. Ele também se integra com serviços modernos de segurança e gerenciamento de ameaças baseados em nuvem, como o Microsoft Defender for Cloud e o Microsoft Sentinel.

Detalhes do cenário

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

Usar o Azure Arc com o Azure Stack HCI

O Azure Stack HCI integra-se diretamente com o 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. Este componente é instalado durante o processo de implantação do cluster HCI. Os nós de cluster HCI do Azure Stack 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 o Lifecycle Manager, o Microsoft Edge Device Management e o 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ções de recursos para o Azure Stack HCI são lançadas periodicamente para aprimorar a experiência do cliente. As atualizações são controladas e geridas através do Azure Update Manager.

Você pode implantar recursos de carga de trabalho, como máquinas virtuais (VMs) do Azure Arc, Azure Arc-enabled Azure Kubernetes Service (AKS) e hosts de sessão da Área de Trabalho Virtual do Azure que usam o portal do Azure selecionando um local personalizado de cluster HCI do Azure Stack 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 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 SQL do Azure em contêiner ou um Banco de Dados do Azure para servidor PostgreSQL que usa AKS habilitado para Azure Arc hospedado no Azure Stack HCI.

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

  • Aprendizado de máquina habilitado para Azure Arc com um cluster 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 aprendizado de máquina na borda.

As cargas de trabalho conectadas ao Azure Arc fornecem consistência e automação aprimoradas do Azure para implantações HCI do Azure Stack, como automatizar a configuração do sistema operacional convidado com extensões de VM do Azure Arc ou avaliar a conformidade com as regulamentações do setor ou padrões corporativos por meio da Política do Azure. Você pode ativar a Política do Azure por meio do portal do Azure ou da automação do Iac.

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

A configuração de segurança padrão do Azure Stack HCI fornece uma estratégia de defesa profunda para simplificar os custos de segurança e conformidade. A implantação e o gerenciamento de serviços de TI para cenários de varejo, manufatura e escritórios remotos apresentam desafios exclusivos de segurança e conformidade. Proteger as cargas de trabalho contra ameaças internas e externas é crucial em ambientes com suporte de TI limitado ou falta ou datacenters dedicados. O Azure 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 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 espaços de armazenamento direcionam volumes em repouso. A criptografia SMB (Server Message Block) fornece criptografia automática do tráfego entre servidores no cluster (na rede de armazenamento) e assinatura do tráfego SMB entre os nós do cluster e outros sistemas. A criptografia SMB também ajuda a evitar ataques de retransmissão e facilita a conformidade com as normas regulamentares.

Você pode integrar VMs HCI do Azure Stack no Defender for Cloud para ativar análises comportamentais baseadas em nuvem, deteção e correção de ameaças, alertas e relatórios. Gerencie VMs HCI do Azure Stack no Azure Arc para que você possa usar a Política do Azure para avaliar sua conformidade com as regulamentações do setor e os padrões corporativos.

Componentes

Essa arquitetura consiste em hardware de servidor físico que você pode usar para implantar clusters HCI do Azure Stack em locais locais ou de borda. Para melhorar os recursos da plataforma, o Azure Stack HCI integra-se 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 infraestrutura hiperconvergente (HCI) implantada no local ou em pontos de presença 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 Kubernetes e outros serviços habilitados pelo Azure Arc. Os clusters HCI do Azure Stack 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 (fabricante de equipamento original).

  • 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 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 a que você queira restringir fortemente o acesso, como chaves de API, senhas, certificados, chaves criptográficas, credenciais de administrador local e chaves de recuperação do BitLocker.

  • O testemunho de nuvem é um recurso do Armazenamento do Azure que atua como um quórum de cluster de failover. Os nós de cluster HCI do Azure Stack usam esse quórum para votação, o que garante alta disponibilidade para o cluster. A conta de armazenamento e a configuração de testemunha são criadas durante o processo de implantação na nuvem do Azure Stack HCI.

  • O Update Manager é um serviço unificado projetado para gerenciar e governar atualizações para o Azure Stack HCI. Você pode usar o Update Manager para gerenciar cargas de trabalho implantadas no Azure Stack HCI, incluindo conformidade de atualização do sistema operacional convidado para VMs Windows e Linux. Essa abordagem unificada simplifica o gerenciamento de patches no Azure, ambientes locais e outras plataformas de nuvem por meio de um único painel.

Recursos de suporte à plataforma

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

  • O Monitor é um serviço baseado em nuvem para coletar, analisar e 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 regra de coleta de dados (DCR) do Monitor e habilitar rapidamente o monitoramento de clusters HCI do Azure Stack.

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

  • O Defender for Cloud é um sistema abrangente de gerenciamento de segurança de infraestrutura. Melhora a postura de segurança dos seus centros de dados e fornece proteção avançada contra ameaças para cargas de trabalho híbridas, quer residam no Azure ou noutro local, e em ambientes locais.

  • 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 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.

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

Opções de design de cluster

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

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

  • Requisitos da unidade de processamento gráfico (GPU) da carga de trabalho, como IA ou aprendizado de máquina, inferência ou renderização gráfica.

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

  • O número de nós físicos no cluster que são de 1 a 16 nós em escala. O número máximo de nós é três quando você usa a arquitetura de rede sem comutador de armazenamento.

    • Para manter a resiliência de computação, você precisa reservar pelo menos nós N+1 de capacidade no cluster. Essa estratégia permite a drenagem de nós para atualizações ou recuperação de interrupções repentinas, como quedas de energia ou falhas de hardware.

    • Para cargas de trabalho críticas para os negócios ou de missão crítica, considere reservar capacidade de nós N+2 para aumentar a resiliência. Por exemplo, se dois nós no cluster estiverem offline, a carga de trabalho poderá permanecer online. Essa abordagem fornece resiliência para cenários nos quais um nó que está executando uma carga de trabalho fica offline durante um procedimento de atualização planejado e resulta em dois nós offline simultaneamente.

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

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

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

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

Para projetar e planejar uma implantação do Azure Stack HCI, recomendamos que você use a ferramenta de dimensionamento HCI do Azure Stack 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 em seu cluster, certifique-se de considerar 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 perguntas relacionadas ao tipo de sistema (Premier, Sistema Integrado ou Nó Validado) e às opções da família de CPU. Ele também ajuda a selecionar seus requisitos de resiliência para o cluster. Realize o procedimento abaixo:

  • Reserve um mínimo de nós N+1 de capacidade, ou um nó, em todo o cluster.

  • Reserve nós N+2 de capacidade em todo o cluster para resiliência extra. Esta opção permite que o sistema resista a uma falha de nó durante uma atualização ou outro evento inesperado que afete dois nós simultaneamente. Ele também garante que haja capacidade suficiente no cluster para que a carga de trabalho seja executada nos nós online restantes.

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

A saída da ferramenta de dimensionamento HCI do Azure Stack é uma lista de SKUs de solução de hardware recomendadas que podem fornecer a capacidade de carga de trabalho necessária e os requisitos de resiliência da plataforma com base nos valores de entrada no Projeto Sizer. Para obter mais informações sobre as soluções de parceiros de hardware OEM disponíveis, consulte Azure Stack HCI Solutions Catalog. Para ajudar os SKUs de solução de tamanho certo a atender às suas necessidades, entre em contato com seu provedor de soluções de hardware ou parceiro de integração de sistema (SI) de sua preferência.

Unidades de disco físicas

O Storage Spaces Direct suporta vários tipos de unidades de disco físico que variam em desempenho e capacidade. Ao projetar um cluster HCI do Azure Stack, trabalhe com seu parceiro OEM de hardware escolhido para determinar os tipos de unidade de disco físico mais apropriados para atender aos requisitos de capacidade e desempenho de sua carga de trabalho. Os exemplos incluem unidades de disco rígido (HDD) giratórias ou unidades de estado sólido (SSD) e unidades NVMe. Essas unidades geralmente são chamadas de unidades flash ou armazenamento de memória persistente (PMem), que é 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, mas não se limitam a, tecnologias de banco de dados altamente transacionais, clusters AKS de produção ou quaisquer cargas de trabalho de missão crítica ou críticas para os negócios que tenham requisitos de armazenamento de baixa latência ou alta taxa de transferência. Use implantações totalmente flash para maximizar o desempenho do armazenamento. As configurações de unidades totalmente NVMe ou SSD, especialmente em pequena escala, melhoram a eficiência do armazenamento e maximizam o desempenho porque nenhuma unidade é usada como camada de cachePara obter mais informações, consulte Armazenamento totalmente 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 contrapartida é que os discos giratórios têm um desempenho inferior se a sua carga de trabalho exceder o conjunto de trabalho da cache e as HDD têm um tempo médio entre falhas mais baixo em comparação com as unidades NVMe e SSD.

O desempenho do armazenamento em cluster é influenciado pelo tipo de unidade de disco físico, que varia com base nas características de desempenho de cada tipo de unidade e no mecanismo de cache escolhido. O tipo de unidade de disco físico é parte integrante de qualquer projeto e configuração do Storage Spaces Direct. Dependendo dos requisitos de carga de trabalho do Azure Stack HCI e das restrições de orçamento, você pode optar por maximizar o desempenho, maximizar a capacidade ou implementar uma configuração de tipo de unidade mista que equilibre o desempenho e a capacidade.

O Storage Spaces Direct fornece um cache integrado, persistente, em tempo real, de leitura, gravação e do lado do servidor que maximiza o desempenho do armazenamento. O cache deve ser dimensionado e configurado para acomodar o conjunto de trabalho de seus aplicativos e cargas de trabalho. Espaços de Armazenamento Os discos virtuais diretos, ou volumes, são usados em combinação com o cache de leitura na memória do volume compartilhado do cluster (CSV) 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) de carga de trabalho.

Gorjeta

Para cargas de trabalho de alto desempenho ou sensíveis à latência, recomendamos que você use uma configuração de armazenamento totalmente flash (todos os NVMe ou todos os SSD) e um tamanho de cluster de três ou mais nós físicos. A implantação desse design com as definições de configuração de armazenamento padrão usa espelhamento de três vias para a infraestrutura e os volumes de usuários. Essa estratégia de implantação oferece o mais alto desempenho e resiliência. Quando utiliza uma configuração totalmente NVMe ou SSD, beneficia da capacidade de armazenamento utilizável total de cada unidade flash. Ao contrário das configurações híbridas ou mistas 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

A conceção da rede é a disposição geral dos componentes dentro da infraestrutura física e das configurações lógicas da rede. Você pode usar as mesmas portas de placa de interface de rede (NIC) física para todas as combinações de intenções de rede de gerenciamento, computação e armazenamento. O uso das mesmas portas NIC para todos os fins relacionados à intenção é chamado de configuração de rede totalmente convergente.

Embora haja suporte para uma configuração de rede totalmente convergente, a configuração ideal para desempenho e confiabilidade é que a intenção de armazenamento use portas de adaptador de rede dedicadas. Portanto, essa arquitetura de linha de base fornece orientações de exemplo sobre como implantar um cluster HCI do Azure Stack 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 fins de gerenciamento e computação e duas portas de adaptador de rede dedicadas para a intenção de armazenamento. Para obter mais informações, consulte Considerações de rede para implantações em nuvem do Azure Stack HCI.

Esta arquitetura requer dois ou mais nós físicos e até um máximo de 16 nós em escala. Cada nó requer quatro portas de adaptador de rede conectadas a dois switches Top-of-Rack (ToR). Os dois comutadores ToR devem ser interligados através de ligações MLAG (multi-chassis link aggregation group). As duas portas do adaptador de rede usadas para o tráfego de intenção de armazenamento devem oferecer suporte 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 (switch embedded teaming). A tecnologia SET fornece redundância de link e recursos de balanceamento de carga. Essas portas exigem uma velocidade mínima de link de 1 Gbps, mas recomendamos uma velocidade de 10 Gbps ou superior.

Topologia de rede física

A topologia de rede física a seguir mostra as conexões físicas reais entre nós e componentes de rede.

Você precisa dos seguintes componentes ao projetar uma implantação HCI do Azure Stack comutada de armazenamento de vários nós que usa essa arquitetura de linha de base:

Diagrama que mostra a topologia de rede física para um cluster HCI do Azure Stack de vários nós que usa uma arquitetura comutada de armazenamento com switches ToR duplos.

  • Comutadores ToR duplos:

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

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

    • Esses switches se conectam aos nós através de cabos Ethernet.

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

    • Cada nó é um servidor físico que executa o Azure Stack HCI OS.

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

    • O armazenamento usa as duas portas dedicadas do adaptador de rede compatível com RDMA que se conectam com um caminho para cada um dos dois switches ToR. Essa abordagem fornece redundância de caminho de link e largura de banda priorizada dedicada para o tráfego de armazenamento SMB Direct.

    • O gerenciamento e a computação usam duas portas de adaptador de rede que fornecem um caminho para cada um dos dois switches ToR para redundância de caminho de link.

  • Conectividade externa:

    • Os switches ToR duplos se conectam à rede externa, como sua LAN corporativa interna, para fornecer acesso às URLs de saída necessárias usando seu dispositivo de rede de borda de borda. Este dispositivo pode ser um firewall ou roteador. Esses switches roteiam o tráfego que entra e sai do cluster HCI do Azure Stack ou o tráfego norte-sul.

    • A conectividade de tráfego externo norte-sul suporta a intenção de gerenciamento de cluster e as intenções de computação. Isso é conseguido usando duas portas de switch e duas portas de adaptador de rede por nó que são convergidas por meio de agrupamento incorporado de switch (SET) e um comutador virtual no Hyper-V para garantir resiliência. Esses componentes funcionam para fornecer conectividade externa para VMs do Azure Arc e outros recursos de carga de trabalho implantados nas redes lógicas criadas no Gerenciador de Recursos usando modelos do portal do Azure, CLI ou Iac.

Topologia lógica de rede

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

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

Diagrama que mostra a topologia lógica de rede para um cluster HCI do Azure Stack de vários nós usando a arquitetura comutada de armazenamento com switches ToR duplos.

  • Comutadores ToR duplos:

    • Antes de implantar o cluster, os dois switches de rede ToR precisam ser configurados com as IDs de VLAN necessárias, configurações máximas de unidade de transmissão e 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 seu fornecedor de hardware de switch ou parceiro SI.
  • O Azure Stack HCI usa a abordagem ATC de rede para aplicar automação de rede e configuração de rede baseada em intenção.

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

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

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

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

  • Tráfego de armazenamento:

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

    • As portas de armazenamento SMB1 e SMB2 se conectam a duas redes não roteáveis (ou camada 2) separadas. Cada rede tem um ID de VLAN específico configurado que deve corresponder à configuração das portas do switch nas IDs de VLAN de armazenamento padrão dos switches ToR: 711 e 712.

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

    • Cada nó pode acessar os recursos de Espaços de Armazenamento Diretos do cluster, como discos físicos remotos usados no pool de armazenamento, discos virtuais e volumes. O acesso a esses recursos é facilitado por meio do protocolo SMB-Direct RDMA nas duas portas dedicadas do adaptador de rede de armazenamento disponíveis em cada nó. SMB Multichannel é usado para resiliência.

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

Requisitos do comutador de rede

Seus switches Ethernet devem atender às diferentes especificações exigidas pelo Azure Stack HCI e definidas pelo Institute of Electrical and Electronics Engineers Standards Association (IEEE SA). Por exemplo, para implantações comutadas de armazenamento com vários nós, a rede de armazenamento é usada para RDMA via RoCE v2 ou iWARP. Esse processo requer IEEE 802.1Qbb PFC para garantir comunicação sem perdas para a classe de tráfego de armazenamento. Seus switches ToR devem fornecer suporte para IEEE 802.1Q para VLANs e IEEE 802.1AB para o Link Layer Discovery Protocol.

Se você planeja usar switches de rede existentes para uma implantação do Azure Stack HCI, revise a lista de padrões e especificações IEEE obrigatórios que os switches de rede e a configuração devem fornecer. Ao comprar novos comutadores de rede, contacte o fornecedor do comutador para garantir que os dispositivos cumprem os requisitos de especificação IEEE do Azure Stack HCI ou reveja a lista de modelos de comutadores certificados pelo fornecedor de hardware que suportam os requisitos de rede HCI do Azure Stack.

Requisitos de endereço IP

Em uma implantação comutada de armazenamento com vários nós, o número de endereços IP necessários aumenta com a adição de cada nó físico, até um máximo de 16 nós em um único cluster. Por exemplo, para implantar uma configuração comutada de armazenamento de dois nós do Azure Stack HCI, a infraestrutura de cluster requer um mínimo de 11 endereços IP a serem alocados. Mais endereços IP são necessários se você usar microssegmentação ou rede definida por software. Para obter mais informações, consulte Examinar 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 os 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 que são necessários para o cluster HCI do Azure Stack e componentes de infraestrutura. Se você planeja implantar o AKS no Azure Stack HCI, consulte AKS habilitado pelos requisitos de rede do Azure Arc.

Monitorização

Para aprimorar o monitoramento e o alerta, 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 and Log Analytics, que garante uma solução escalável e sempre atualizada e altamente personalizável. O Insights fornece acesso a pastas de trabalho padrão com métricas básicas, juntamente com pastas de trabalho especializadas criadas para monitorar os principais recursos do Azure 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 personalizadas de alerta de integridade de recursos.

Gestão de atualizações

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

Atualizações de infraestrutura

O Azure 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. As compilações de linha de base são aplicadas aos clusters HCI do Azure Stack para mantê-los atualizados. Além das atualizações regulares de compilação 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 para o Azure Stack HCI. Este serviço fornece um mecanismo para exibir todos os clusters HCI do Azure Stack em toda a sua infraestrutura e pontos de presença usando o portal do Azure para fornecer uma experiência de gerenciamento centralizado. Para obter mais informações, consulte os seguintes recursos:

É importante verificar se há novas atualizações de driver e firmware regularmente, como a cada três a seis meses. Se você usar uma versão de categoria de solução Premier para seu hardware HCI do Azure Stack, 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 seu parceiro OEM ou SI de hardware.

Correção do SO convidado da carga de trabalho

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

Considerações

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

Fiabilidade

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

Identificar os potenciais pontos de falha

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

Componente Risco Probabilidade Efeito/atenuação/nota Indisponibilidade
Interrupção do cluster HCI do Azure Stack Falha de energia, rede, hardware ou software Médio Para evitar uma interrupção prolongada do aplicativo causada pela falha de um cluster HCI do Azure Stack para casos de uso de negócios ou de missão crítica, sua carga de trabalho deve ser arquitetada usando os princípios de HA e DR. Por exemplo, você pode usar tecnologias de replicação de dados de carga de trabalho padrão do setor para manter várias cópias de dados de estado persistentes que são implantados usando várias VMs do Azure Arc ou instâncias AKS implantadas em clusters HCI do Azure Stack separados e em locais físicos separados. Potencial interrupção
Interrupção de nó físico único do Azure Stack HCI Falha de energia, hardware ou software Médio Para evitar uma interrupção prolongada do aplicativo causada pela falha de um único nó HCI do Azure Stack, seu cluster HCI do Azure Stack deve ter vários nós físicos. Os requisitos de capacidade da carga de trabalho durante a fase de projeto do cluster determinam o número de nós. Recomendamos que você tenha três ou mais nós. Também recomendamos o uso do espelhamento de três vias, que é o modo de resiliência de armazenamento padrão para clusters com três ou mais nós. Para evitar um SPoF e aumentar a resiliência da carga de trabalho, implante várias instâncias da sua carga de trabalho usando duas ou mais VMs do Azure Arc ou pods de contêiner que são executados em vários nós de trabalho do AKS. Se um único nó falhar, as VMs do Azure Arc e os serviços de carga de trabalho/aplicativo serão reiniciados nos nós físicos online restantes no cluster. Potencial interrupção
Azure Arc VM ou nó de trabalho AKS (carga de trabalho) Configuração incorreta Médio Os usuários do aplicativo não conseguem entrar ou acessar o aplicativo. Erros de configuração devem ser detetados durante a implantação. Se esses erros acontecerem durante uma atualização de configuração, a equipe de DevOps deverá reverter as alterações. Você pode reimplantar a VM, se necessário. A reimplantação leva menos de 10 minutos, mas pode levar mais tempo de acordo com o tipo de implantação. Potencial interrupção
Conectividade ao Azure Interrupção da rede Médio O cluster precisa acessar o plano de controle do Azure regularmente para recursos de cobrança, gerenciamento e monitoramento. Se o cluster perder a conectividade com o Azure, ele operará em um estado degradado. Por exemplo, não seria possível implantar novas VMs do Azure Arc ou clusters AKS se o cluster perder a conectividade com o Azure. As cargas de trabalho existentes em execução no cluster HCI continuam a ser executadas, mas você deve restaurar a conexão dentro de 48 a 72 horas para garantir a operação ininterrupta. Nenhuma

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

Objetivos de fiabilidade

Esta seção descreve um cenário de exemplo. Um cliente fictício chamado Contoso Manufacturing usa essa arquitetura de referência para implantar o Azure 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% que as partes interessadas 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 que são implantados usando VMs do Azure Arc que são executadas no Azure Stack HCI:

    • Semanalmente: 20 minutos e 10 segundos

    • Mensal: 1 hora, 26 minutos e 56 segundos

    • Trimestral: 4 horas, 20 minutos e 49 segundos

    • Anual: 17 horas, 23 minutos e 16 segundos

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

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

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

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

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

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

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

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

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

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

  • Os processos e procedimentos operacionais descritos anteriormente no artigo e as recomendações no guia de serviço do Well-Architected Framework para Azure Stack HCI permitem que a Contoso Manufacturing atinja sua meta de SLO de 99,8% e dimensione e gerencie com eficiência as implantações de HCI e carga de trabalho do Azure Stack em vários locais de fabricação distribuídos em todo o mundo.

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

Redundância

Considere uma carga de trabalho que você implanta em um único cluster HCI do Azure Stack como uma implantação localmente redundante. O cluster fornece alta disponibilidade no nível da plataforma, mas você deve implantar o cluster em um único rack. Para casos de uso críticos para os negócios ou de missão crítica, recomendamos que você implante várias instâncias de uma carga de trabalho ou serviço em dois ou mais clusters HCI do Azure Stack separados, 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 o SQL Server Always On. Você também pode usar uma tecnologia de balanceamento de carga de rede (NLB) externo que roteia solicitações de usuário entre as várias instâncias de carga de trabalho executadas em clusters HCI do Azure Stack que você implanta em locais físicos separados. Considere o uso de um dispositivo NLB externo parceiro. Ou você pode avaliar as opções de balanceamento de carga que dão suporte ao roteamento de tráfego para serviços híbridos e locais, como uma instância do Gateway de Aplicativo do Azure que usa a Rota Expressa do Azure ou um túnel VPN para se conectar a um serviço local.

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

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

As considerações de segurança incluem:

  • Uma base segura para a plataforma 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 HCI do Azure Stack 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 as funções RBAC (controle de acesso baseadas em função) internas do Azure Stack HCI, como o Azure Stack HCI Administrator para administradores de plataforma e o Azure Stack HCI VM Contributor ou o Azure Stack HCI VM Reader para operadores de carga de trabalho.

  • Configurações de segurança padrão: o padrão de segurança HCI do Azure Stack aplica as configurações de segurança padrão para seu cluster HCI do Azure Stack durante a implantação e habilita o controle de desvio para manter os nós em um bom estado. Você pode usar as configurações padrão de segurança para gerenciar a segurança do cluster, o controle de desvio e as configurações do servidor núcleo seguro no cluster.

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

  • Proteção contra ameaças e vulnerabilidades: o Defender for Cloud protege seus clusters HCI do Azure Stack contra várias ameaças e vulnerabilidades. Este serviço ajuda a melhorar a postura de segurança do seu ambiente HCI do Azure Stack e pode proteger contra ameaças existentes e em evolução.

  • Deteção e correção de ameaças: o Microsoft Advanced Threat Analytics deteta e corrige ameaças, como as direcionadas ao AD DS, que fornecem serviços de autenticação para nós de cluster HCI do Azure Stack e suas cargas de trabalho de VM do Windows Server.

  • Isolamento de rede: isole redes, se necessário. Por exemplo, você pode provisionar várias redes lógicas que usam VLANs e intervalos de endereços de rede separados. Ao usar essa abordagem, certifique-se de que a rede de gerenciamento possa alcançar cada rede lógica e VLAN para que os nós de cluster HCI do Azure Stack possam se comunicar com as redes VLAN por meio dos switches ou gateways ToR. Essa configuração é necessária para o gerenciamento da carga de trabalho, como permitir que os agentes de gerenciamento de infraestrutura se comuniquem com o SO convidado da carga de trabalho.

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

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

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

  • Modelo de cobrança no estilo de nuvem para licenciamento: o preço do Azure Stack HCI segue o modelo de cobrança de assinatura mensal com uma taxa fixa por núcleo de processador físico em um cluster HCI do Azure Stack. Aplicam-se taxas de utilização adicionais se utilizar outros serviços do Azure. Se você possui licenças principais locais para a edição do Windows Server Datacenter com o Software Assurance ativo, pode optar por trocar essas licenças para ativar o cluster HCI do Azure Stack e as taxas de assinatura da VM do Windows Server.

  • Patch automático de convidado de VM para VMs do Azure Arc: esse recurso ajuda a reduzir a sobrecarga de patches manuais e os custos de manutenção associados. Esta ação não só ajuda a tornar o sistema mais seguro, mas também otimiza a alocação de recursos e contribui para a eficiência geral de custos.

  • Consolidação de monitoramento de custos: para consolidar os custos de monitoramento, use o Azure Stack HCI Insights e o patch 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 gerenciador de ciclo de vida do Azure Stack HCI integra-se ao Update Manager para simplificar a tarefa de manter seus clusters atualizados, consolidando fluxos de trabalho de atualização para vários componentes em uma única experiência. Use o Monitor e o Update Manager para otimizar a alocação de recursos e contribuir para a eficiência geral de custos.

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

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

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

Gorjeta

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

Excelência operacional

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

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

  • Experiência simplificada de provisionamento e gerenciamento integrada ao Azure: a Implantação Baseada em Nuvem no Azure fornece uma interface orientada por assistente que mostra como criar um cluster HCI do Azure Stack. Da mesma forma, o Azure simplifica o processo de gerenciamento de clusters HCI do Azure Stack e VMs do Azure Arc. Você pode automatizar a implantação baseada em portal do cluster HCI do Azure Stack usando o modelo 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 sites de fabricação que exigem um cluster HCI do Azure Stack para executar cargas de trabalho críticas para os negócios.

  • Recursos de automação para máquinas virtuais: o Azure Stack HCI 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 o modelo Azure CLI, ARM ou Bicep, com atualizações do sistema operacional da máquina virtual usando o Azure Arc Extension for Updates e o Azure Update Manager para atualizar cada cluster HCI do Azure Stack. O Azure Stack HCI também fornece suporte para o gerenciamento de VMs do Azure Arc usando a CLI do Azure e VMs que não são do 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 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 das extensões do Azure Arc.

    Para obter mais informações, consulte Recomendações para usar o IaC.

  • Recursos de automação para contêineres no AKS: o Azure Stack HCI fornece uma ampla gama de recursos de automação para gerenciar cargas de trabalho, como contêineres, no AKS. Você pode automatizar a implantação de clusters AKS usando a CLI do Azure. Atualize os clusters de carga de trabalho do AKS usando a extensão Azure Arc para atualizações do Kubernetes. Você também pode gerenciar 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 de um computador de gerenciamento. Integre com o Azure Arc para uma ampla variedade de cenários de automação extra para cargas de trabalho em contêineres por meio das extensões do Azure Arc.

    Para obter mais informações, consulte Recomendações para habilitar a automação.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

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

  • Desempenho do 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 HCI do Azure Stack. 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 HCI do Azure Stack antes de implantar cargas de trabalho de produção. O DiskSpd usa vários parâmetros de linha de comando que permitem que os administradores testem o desempenho de armazenamento do cluster. A principal função do DiskSpd é emitir operações de leitura e gravação e métricas de desempenho de saída, como latência, taxa de transferência e IOPs.

      Para obter mais informações, consulte Recomendações para testes de desempenho.

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

    Para obter mais informações, consulte Recomendações para 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 ideal de hardware de rede.

    • Para otimizar o desempenho de computação no Azure Stack HCI, você pode usar a aceleração de GPU. A aceleração da GPU é benéfica para cargas de trabalho de IA ou aprendizado de máquina de alto desempenho que envolvem insights de dados ou inferência. Essas cargas de trabalho exigem implantação em pontos de presença devido a considerações como gravidade dos dados ou requisitos de segurança. Em uma implantação híbrida ou local, é importante levar em consideração os requisitos de desempenho da carga de trabalho, incluindo GPUs. Essa abordagem ajuda você a selecionar os serviços certos ao projetar e adquirir seus clusters HCI do Azure Stack.

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

Implementar este cenário

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

Cenário: há um requisito de projeto ou caso de uso para implantar uma solução de nuvem híbrida em um local local ou ponto de presença 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 é a solução de plataforma de infraestrutura escolhida para o projeto.

  1. Reúna os requisitos de carga de trabalho e casos de uso das partes interessadas relevantes. Essa estratégia permite que o projeto confirme se os recursos do Azure Stack HCI atendem aos requisitos de escala, desempenho e funcionalidade da carga de trabalho. Esse processo de revisão deve incluir a compreensão da escala ou tamanho da carga de trabalho e dos recursos necessários, como VMs do Azure Arc, AKS, Área de Trabalho Virtual do Azure ou Serviços de Dados habilitados para Azure Arc ou serviço de Aprendizado de Máquina habilitado para Azure Arc. Os valores de RTO e RPO (confiabilidade) da carga de trabalho e outros requisitos não funcionais (desempenho/escalabilidade de carga) devem ser documentados como parte desta etapa de coleta de requisitos.

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

  3. Use a ferramenta de dimensionamento HCI do Azure Stack para criar um novo projeto que modela 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 juntamente com as opções para o tipo de sistema, a família de CPU preferida e seus requisitos de resiliência para alta disponibilidade e tolerância a falhas de armazenamento, conforme explicado na seção de opções de design de cluster anterior.

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

  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 seus requisitos de carga de trabalho. Se disponível, use ferramentas de dimensionamento específicas do OEM para determinar os requisitos de dimensionamento de hardware específicos do OEM para as cargas de trabalho pretendidas. Esta etapa geralmente inclui discussões com o parceiro OEM ou SI de hardware para os aspetos comerciais da solução. Esses aspetos incluem cotações, disponibilidade do hardware, prazos de entrega e quaisquer serviços profissionais ou de valor agregado que o parceiro forneça para ajudar a acelerar seus resultados de projeto ou negócios.

  6. Implante dois switches ToR para integração de rede. Para soluções de alta disponibilidade, os clusters HCI exigem a implantação de dois switches ToR. Cada nó físico requer quatro NICs, dois dos quais devem ser compatíveis com RDMA, que fornece dois links de cada nó para os dois switches ToR. Duas NICs, uma conectada a cada switch, são convergidas para conectividade de saída norte-sul para as redes de computação e gerenciamento. As outras duas NICs compatíveis com RDMA são dedicadas ao tráfego de armazenamento leste-oeste. Se planeia utilizar comutadores de rede existentes, certifique-se de que a marca e o modelo dos seus comutadores estão na lista aprovada de comutadores de rede suportados pelo Azure Stack HCI.

  7. Trabalhe com o OEM de hardware ou parceiro SI para organizar a entrega do hardware. O parceiro de SI ou seus funcionários são obrigados a integrar o hardware em seu datacenter local ou ponto de presença, como empilhamento e empilhamento do hardware, rede física e cabeamento da unidade de fonte de alimentação para os nós físicos.

  8. Execute a implantação do cluster HCI do Azure Stack. Dependendo da versão da solução escolhida (solução Premier, Sistema integrado ou Nós validados), o parceiro de hardware, o parceiro SI ou os seus funcionários podem implementar o software Azure Stack HCI. Esta etapa começa integrando os nós físicos do Azure Stack HCI OS em servidores habilitados para Azure Arc e, em seguida, iniciando o processo de implantação na nuvem do Azure Stack HCI. Os clientes e parceiros podem fazer 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.

    Gorjeta

    Logótipo do GitHub 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 ARM e um arquivo de parâmetro. Como alternativa, o exemplo Bicep demonstra como usar um modelo Bicep para implantar um cluster HCI do Azure Stack, incluindo seus recursos de pré-requisitos.

  9. Implante cargas de trabalho altamente disponíveis no Azure Stack HCI usando o portal do Azure, CLI ou modelos 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 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 HCI do Azure Stack 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 escalável para instalar atualizações em um único cluster ou em vários clusters. Consulte o seu parceiro OEM de hardware para determinar o processo de instalação de atualizações de driver de hardware e firmware, pois esse processo pode variar dependendo do tipo de categoria de solução de hardware escolhida (solução Premier, Sistema integrado ou Nós validados). Para obter mais informações, consulte Atualizações de infraestrutura.

Próximos passos

Documentação do produto:

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

Módulos do Microsoft Learn: