Este artigo faz parte de uma série que se baseia no arquitetura de referência de linha de base local do Azure. Para implantar efetivamente o Azure Local usando um design de sem alternância de armazenamento de três nós, é importante entender a arquitetura de linha de base. Esse processo inclui familiarizar-se com as opções de design de cluster para os nós físicos que fornecem recursos locais de computação, armazenamento e rede. Esse conhecimento ajuda você a identificar as alterações necessárias para uma implantação bem-sucedida. As diretrizes neste artigo também se aplicam a um armazenamento de de dois nós sem alternância implantação e faz os ajustes necessários para casos em que o número de nós físicos diminui de três para dois.
O design de rede sem comutador de armazenamento remove o requisito de comutadores de rede de classe de armazenamento para conectar as portas do adaptador de rede usadas para o tráfego de armazenamento. Em vez disso, os nós são conectados diretamente usando cabos ethernet de interlink. Essa configuração é comumente usada em cenários de varejo, fabricação ou escritório remoto. Essa configuração também é adequada para casos de uso de borda menores que não têm ou exigem opções de rede de datacenter abrangentes para o tráfego de replicação de armazenamento.
Essa arquitetura de referência fornece diretrizes e recomendações independentes de carga de trabalho para configurar o Azure Local como uma plataforma de infraestrutura resiliente para implantar e gerenciar cargas de trabalho virtualizadas. Para obter mais informações sobre padrões de arquitetura de carga de trabalho otimizados para execução no Azure Local, consulte o conteúdo localizado no menu cargas de trabalho locais do Azure menu de navegação.
Essa arquitetura é um ponto de partida para uma instância local do Azure de três nós que usa um design de rede sem comutador de armazenamento. Os aplicativos de carga de trabalho implantados em uma instância local do Azure devem ser bem arquitetados. Essa abordagem inclui a implantação de várias instâncias para alta disponibilidade de quaisquer serviços de carga de trabalho críticos e a implementação de controles de BCDR (continuidade de negócios e recuperação de desastre) apropriados, como backups regulares e recursos de failover de DR. Para se concentrar na plataforma de infraestrutura HCI, esses aspectos de design de carga de trabalho são excluídos intencionalmente deste artigo. Para obter mais informações sobre diretrizes e recomendações para os cinco pilares do Azure Well-Architected Framework, consulte o guia de serviço do Azure Local Well-Architected Framework.
Layout do artigo
Arquitetura | Decisões de design | Abordagem do Well-Architected Framework |
---|---|---|
▪ de diagrama de arquitetura de ▪ possíveis casos de uso ▪ Implantar esse cenário |
▪ opções de design do cluster ▪ de Rede |
▪ de otimização de custo ▪ de eficiência de desempenho |
Ponta
Arquitetura
Para obter mais informações sobre esses recursos, consulte Recursos relacionados.
Possíveis casos de uso
Use esse design e os designs descritos no arquitetura de referência de linha de base local do Azure para atender aos seguintes requisitos de caso de uso:
Implante e gerencie cargas de trabalho de borda virtualizadas ou baseadas em contêineres altamente disponíveis que são implantadas em um único local para permitir que aplicativos e serviços comercialmente críticos operem de maneira resiliente, econômica e escalonável.
O design de rede sem alternância de armazenamento remove o requisito de implantar comutadores de rede de classe de armazenamento para conectar as portas do adaptador de rede usadas para o tráfego de armazenamento.
Você pode usar o design de rede sem comutador de armazenamento para ajudar a reduzir os custos associados à aquisição e configuração de comutadores de rede de classe de armazenamento para o tráfego de armazenamento, mas isso aumenta o número de portas de adaptador de rede necessárias nos nós físicos.
Componentes de arquitetura
Os recursos de arquitetura permanecem praticamente inalterados em relação à arquitetura de referência de linha de base. Para obter mais informações, consulte os recursos da plataforma e os recursos de suporte à plataforma usados para implantações locais do Azure.
Opções de design de cluster
Ao determinar as opções de design do cluster, consulte a arquitetura de referência de linha de base . Use esses insights e a ferramenta Azure Local Sizer para dimensionar adequadamente uma instância local do Azure de acordo com os requisitos de carga de trabalho.
Quando você usa o design sem comutador de armazenamento, é crucial lembrar que um cluster de três nós é o tamanho máximo com suporte. Essa limitação é uma consideração fundamental para suas opções de design de cluster, pois você deve garantir que os requisitos de capacidade da carga de trabalho não excedam os recursos de capacidade física das especificações do cluster de três nós. Como você não pode executar um gesto de nó de adição para expandir um cluster sem comutador de armazenamento além de três nós, é extremamente importante entender os requisitos de capacidade da carga de trabalho de antemão e planejar o crescimento futuro. Dessa forma, você pode garantir que sua carga de trabalho não exceda a capacidade de armazenamento e computação ao longo do tempo de vida esperado do hardware da instância local do Azure.
Cuidado
O tamanho máximo do cluster com suporte para a arquitetura de rede sem comutador de armazenamento é de três nós físicos. Considere esse limite durante a fase de design do cluster, como incluir os requisitos atuais e futuros de capacidade de crescimento para sua carga de trabalho.
Design de rede
O design de rede refere-se à disposição geral de componentes físicos e lógicos dentro da rede. Em uma configuração sem alternância de armazenamento de três nós para o Azure Local, três nós físicos são conectados diretamente sem usar um comutador externo para tráfego de armazenamento. Essas conexões ethernet interligadas diretas simplificam o design de rede reduzindo a complexidade porque não há nenhum requisito para definir ou aplicar a qualidade de armazenamento de configurações de serviço e priorização nas opções. As tecnologias que sustentam a comunicação rdma sem perdas, como ECN (notificação de congestionamento explícita), PFC (controle de fluxo de prioridade) ou QoS (qualidade de serviço) necessária para RoCE v2 e iWARP, não são necessárias. No entanto, essa configuração dá suporte a no máximo três nós, o que significa que você não pode dimensionar o cluster adicionando mais nós após a implantação.
Nota
Essa arquitetura sem alternância de armazenamento de três nós requer seis portas do adaptador de rede que fornecem links redundantes para todas as intenções de rede. Leve isso em consideração se você planeja usar um hardware pequeno fator forma SKU ou se há espaço físico limitado no chassi do servidor para cartões de rede extras. Consulte seu parceiro de fabricante de hardware preferencial para obter mais informações.
Topologia de rede física
A topologia de rede física mostra as conexões físicas reais entre nós e componentes de rede. As conexões entre nós e componentes de rede para uma implantação local do Azure sem alternância de armazenamento de três nós são:
Três nós (ou servidores):
Cada nó é um servidor físico executado no so do Azure Stack HCI.
Cada nó requer seis portas de adaptador de rede no total: quatro portas compatíveis com RDMA para armazenamento e duas portas para gerenciamento e computação.
Tráfego de armazenamento:
Cada um dos três nós é interconectado por meio de portas de adaptador de rede física dedicadas duplas para armazenamento. O diagrama a seguir ilustra esse processo.
As portas do adaptador de rede de armazenamento se conectam diretamente a cada nó usando cabos ethernet para formar uma arquitetura de rede de malha completa para o tráfego de armazenamento.
Esse design fornece redundância de link, baixa latência dedicada, alta largura de banda e alta taxa de transferência.
Nós dentro do cluster HCI se comunicam diretamente por meio desses links para lidar com o tráfego de replicação de armazenamento, também conhecido como tráfego leste-oeste.
Essa comunicação direta elimina a necessidade de portas extras de comutador de rede para armazenamento e remove o requisito de aplicar a configuração de QoS ou PFC para o tráfego SMB Direct ou RDMA nos comutadores de rede.
Verifique com o parceiro do fabricante de hardware ou o fornecedor de NIC (placa de interface de rede) para obter os drivers de so recomendados, versões de firmware ou configurações de firmware para a configuração de rede de interconexão sem comutador.
Opções de ToR (Top-of-Rack Duplo):
Essa configuração é sem alternância para o tráfego de armazenamento, mas ainda requer opções de ToR para a conectividade externa. Essa conectividade é chamada de tráfego norte-sul e inclui o cluster intenção de gerenciamento e a carga de trabalho intenções de computação.
Os uplinks para as opções de cada nó usam duas portas de adaptador de rede. Os cabos Ethernet conectam essas portas, uma para cada comutador ToR, para fornecer redundância de link.
Recomendamos que você use comutadores ToR duplos para fornecer redundância para operações de manutenção e balanceamento de carga para comunicação externa.
Conectividade externa:
Os comutadores ToR duplos se conectam à rede externa, como a LAN corporativa interna, e usam seu dispositivo de rede de borda de borda de borda, como um firewall ou roteador, para fornecer acesso às URLs de saída necessárias.
As duas opções de ToR lidam com o tráfego norte-sul da instância local do Azure, incluindo o tráfego relacionado a intenções de gerenciamento e computação.
Topologia de rede lógica
A topologia de rede lógica fornece uma visão geral de como os dados de rede fluem entre dispositivos, independentemente de suas conexões físicas. A lista a seguir resume a configuração lógica para uma instância local do Azure sem alternância de armazenamento de três nós:
Comutadores de ToR Duplo:
- Antes da implantação do cluster, os dois comutadores de rede ToR precisam ser configurados com as IDs de VLAN necessárias e as configurações máximas de MTU (unidade de transmissão) para as portas de gerenciamento e computação. Para obter mais informações, consulte os requisitos de rede física ou peça assistência ao seu fornecedor de hardware ou parceiro do SI (integrador de sistemas).
O Azure Local aplica a automação de rede e
de configuração de rede baseada em intenção usando ode serviço atc de rede . A ATC de rede foi projetada para garantir a configuração de rede ideal e o fluxo de tráfego usando o tráfego de rede intenções. A ATC de rede define quais portas de adaptador de rede física são usadas para as diferentes intenções de tráfego de rede (ou tipos), como para ode gerenciamento de
de cluster, carga de trabalho de computação e intenções de de armazenamento de cluster. As políticas baseadas em intenção simplificam os requisitos de configuração de rede automatizando a configuração de rede do nó com base em entradas de parâmetro especificadas como parte do processo de implantação de nuvem local do Azure.
Comunicação externa:
Quando os nós ou a carga de trabalho precisam se comunicar externamente acessando a LAN corporativa, a Internet ou outro serviço, eles roteam usando os comutadores tor duplos. Esse processo é descrito na seção de topologia de rede física do
anterior. Quando as duas opções de ToR atuam como dispositivos de Camada 3, elas lidam com o roteamento e fornecem conectividade além do cluster para o dispositivo de borda de borda, como o firewall ou o roteador.
A intenção de rede de gerenciamento usa a interface virtual SET (Converged Switch Embedded Teaming), que permite que o endereço IP de gerenciamento de cluster e os recursos do plano de controle se comuniquem externamente.
Para a intenção de rede de computação, você pode criar uma ou mais redes lógicas no Azure com as IDs de VLAN específicas para seu ambiente. Os recursos de carga de trabalho, como máquinas virtuais (VMs), usam essas IDs para dar acesso à rede física. As redes lógicas usam as duas portas do adaptador de rede física convergidas usando SET para as intenções de computação e gerenciamento.
Tráfego de armazenamento:
Os nós se comunicam entre si diretamente para o tráfego de armazenamento usando as quatro portas de ethernet de interconexão direta por nó, que usam seis redes nãooutable (ou Camada 2) separadas para o tráfego de armazenamento.
Não há nenhum gateway padrão configurado nas quatro portas do adaptador de rede de intenção de armazenamento dentro do sistema operacional Azure Stack HCI.
Cada nó pode acessar recursos S2D 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 que estão disponíveis em cada nó. O SMB Multichannel é usado para resiliência.
Essa configuração garante velocidade de transferência de dados suficiente para operações relacionadas ao armazenamento, como manter cópias consistentes de dados para volumes espelhados.
Requisitos de endereço IP
Para implantar uma configuração sem alternância de armazenamento de três nós do Azure Local com links duplos para as interconexões de armazenamento, a plataforma de infraestrutura de cluster requer que você aloque no mínimo 20 x endereços IP. Mais endereços IP são necessários se você usar um dispositivo de VM fornecido pelo seu parceiro de fabricante de hardware ou se você usar microssegmentação ou SDN (rede definida pelo software). Para obter mais informações, consulte Examinar os requisitos de IP de padrão de referência de armazenamento de três nós para aLocal do Azure.
Ao projetar e planejar os requisitos de endereço IP para o Azure Local, lembre-se de considerar endereços IP adicionais ou intervalos de rede necessários para sua carga de trabalho além dos necessários para a instância local do Azure e os componentes de infraestrutura. Se você planeja usar o AKS (Serviços de Kubernetes do Azure) no Azure Local, consulte AKS habilitado pelos requisitos de rede do Azure Arc.
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.
Importante
Examine as considerações do Well-Architected Framework descritas no de arquitetura de referência de linha de base local do Azure.
Otimização de custo
A otimização de custos é sobre a busca de maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.
As considerações sobre otimização de custo incluem:
- Interconexões de cluster sem alternância versus interconexões de cluster baseadas em comutador. A topologia de interconexão sem alternância consiste em conexões entre porta dupla ou portas de adaptador de rede redundantes e compatíveis com RDMA em cada nó para formar uma malha completa. Cada nó tem duas conexões diretas com cada outro nó. Embora essa implementação seja simples, ela só tem suporte em clusters de dois ou três nós. Uma instância local do Azure com quatro ou mais nós requer o armazenamento comutado arquitetura de rede. Você pode usar essa arquitetura para adicionar mais nós após a implantação, ao contrário do design sem comutador de armazenamento que não dá suporte a operações de nó de adição.
Eficiência de desempenho
A eficiência de desempenho é a capacidade da sua carga de trabalho de dimensionar para atender às demandas colocadas nele pelos usuários de maneira eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.
Considerações sobre eficiência de desempenho incluem:
- Você não pode aumentar a escala (ou executar uma operação de nó de adição) de um cluster HCI sem alternância de armazenamento de três nós existente sem reimplantar o cluster e adicionar recursos de rede extras, como comutadores de rede, portas e cabos para o tráfego de armazenamento e os outros nós necessários. Três nós são o tamanho máximo do cluster com suporte para o design de rede sem comutador de armazenamento. Considere essa limitação na fase de design do cluster para garantir que o hardware possa dar suporte ao crescimento futuro da capacidade da carga de trabalho.
Implantar esse cenário
Para obter mais informações sobre como projetar, adquirir e implantar uma solução local do Azure, consulte o Implantar esse cenário seção da arquitetura de referência de linha de base local do Azure.
Use o modelo de automação de implantação a seguir como um exemplo de como implantar o Azure Local usando a arquitetura sem alternância de armazenamento de três nós.
Ponta
Recursos relacionados
- de design de arquitetura híbrida
- opções híbridas do Azure
- Automação do Azure em um ambiente híbrido
- de Configuração de Estado de Automação do Azure
- Otimizar a administração de instâncias do SQL Server em ambientes locais e multinuvem usando o Azure Arc
Próximas etapas
Documentação do produto:
- sistema operacional Azure Stack HCI, versão 23H2, informações de versão
- AKS no Local do Azure
- Área de Trabalho Virtual do Azure para a Local do Azure
- O que é o monitoramento local do Azure?
- proteger cargas de trabalho de VM com o Site Recovery no Azure Local
- visão geral do Azure Monitor
- Visão geral controle de alterações e inventário
- visão geral do Gerenciador de Atualizações do Azure
- Quais são os serviços de dados habilitados para Azure Arc?
- O que são servidores habilitados para Azure Arc?
- O que é o Backup do Azure?
- introdução ao destino de computação do Kubernetes no Azure Machine Learning
Documentação do produto para serviços específicos do Azure:
- Local do Azure
- do Azure Arc
- do Azure Key Vault
- de Armazenamento de Blobs do Azure
- Monitor
- do Azure Policy
- registro de contêiner do Azure
- Microsoft Defender para Cloud
- do Azure Site Recovery
- de Backup do
Módulos do Microsoft Learn:
- Configurar o Monitor
- Projetar sua solução de recuperação de site no Azure
- introdução aos servidores habilitados para Azure Arc
- introdução aos serviços de dados habilitados para Azure Arc
- Introdução à do AKS
- implantação do modelo do Scale com o Azure Machine Learning em qualquer lugar – do Blog da Comunidade Técnica
- Realizando o Machine Learning em qualquer lugar com o AKS e o aprendizado de máquina habilitado para Arc – Blog da Comunidade Técnica
- machine learning no AKS híbrido e stack HCI usando o aprendizado de máquina habilitado para Azure Arc – Blog da Comunidade Técnica
- Manter suas máquinas virtuais atualizadas
- Proteger suas configurações de máquina virtual com a Configuração de Estado de Automação do Azure
- proteger suas VMs usando o Backup