Este artigo faz parte de uma série que se baseia na arquitetura de referência de linha de base local do Azure. Para implantar efetivamente o Azure Local usando um design de de armazenamento sem switch 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 a identificar as alterações necessárias para uma implantação bem-sucedida. A orientação neste artigo também se aplica a uma implantação de de armazenamento sem switch de dois
O design de rede sem comutador de armazenamento elimina a necessidade de switches de rede de classe de armazenamento para conectar as portas do adaptador de rede que são usadas para o tráfego de armazenamento. Em vez disso, os nós são conectados diretamente usando cabos ethernet de interligação. Essa configuração é comumente usada em cenários de varejo, fabricação ou escritórios remotos. Essa configuração também é adequada para casos de uso de borda menores que não têm ou exigem switches de rede de datacenter extensos para tráfego de replicação de armazenamento.
Esta arquitetura de referência fornece orientações e recomendações independentes da 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 de navegação cargas de trabalho
Essa arquitetura é um ponto de partida para uma instância Local do Azure de trê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 críticos de carga de trabalho e a implementação de controles BCDR (Business Continuity and Disaster Recovery) apropriados, como backups regulares e recursos de failover de DR. Para se concentrar na plataforma de infraestrutura HCI, esses aspetos de design de carga de trabalho são intencionalmente excluídos deste artigo. Para obter mais informações sobre diretrizes e recomendações para os cinco pilares do Azure Well-Architected Framework, consulte o guia de serviço do Azure Local Well-Architected Framework.
Layout do artigo
Arquitetura | Decisões de conceção | Well-Architected Abordagem do quadro |
---|---|---|
▪ Diagrama de arquitetura ▪ Casos de uso potenciais ▪ Implantar este cenário |
▪ Opções de design de cluster ▪ Networking |
▪ Otimização de custos ▪ Eficiência de desempenho |
Dica
Arquitetura
Para obter mais informações sobre esses recursos, consulte Recursos relacionados.
Casos de uso potenciais
Use esse design e os designs descritos no de arquitetura de referência de linha de base local do
Implante e gerencie cargas de trabalho de borda altamente disponíveis (HA) virtualizadas ou baseadas em contêiner que são implantadas em um único local para permitir que aplicativos e serviços críticos para os negócios operem de maneira resiliente, econômica e escalável.
O design de rede sem comutador de armazenamento elimina a necessidade de implantar switches 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 switches de rede de classe de armazenamento para 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 da plataforma usados para implantações do Azure Local.
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 essas informações e o Azure Local Sizer Tool para dimensionar adequadamente uma instância Local do Azure de acordo com os requisitos de carga de trabalho.
Quando você usa o design sem switch de armazenamento, é crucial lembrar que um cluster de três nós é o tamanho máximo suportado. 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 de cluster de três nós. Como não é possível executar um gesto de nó adicional 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 com antecedência 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 durante a vida útil esperada do hardware da instância Local do Azure.
Atenção
O tamanho máximo de cluster suportado para a arquitetura de rede sem comutador de armazenamento é de três nós físicos. Certifique-se de considerar 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
A conceção da rede refere-se à disposição global dos componentes físicos e lógicos dentro da rede. Em uma configuração sem switch de armazenamento de três nós para o Azure Local, três nós físicos são conectados diretamente sem usar um switch externo para tráfego de armazenamento. Essas conexões ethernet interligadas diretas simplificam o projeto de rede, reduzindo a complexidade porque não há necessidade de definir ou aplicar configurações de qualidade de serviço e priorização de armazenamento nos switches. As tecnologias que sustentam a comunicação RDMA sem perdas, como notificação explícita de congestionamento (ECN), controle de fluxo prioritário (PFC) ou qualidade de serviço (QoS) que são necessárias para RoCE v2 e iWARP, não são necessárias. No entanto, essa configuração oferece suporte a um máximo de três nós, o que significa que você não pode dimensionar o cluster adicionando mais nós após a implantação.
Observação
Essa arquitetura sem switch de armazenamento de três nós requer seis portas de 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 de formato pequeno SKU ou se houver espaço físico limitado no chassi do servidor para placas de rede extras. Consulte o seu parceiro fabricante de hardware preferido 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 do Azure Local sem comutação de armazenamento de três nós são:
Três nós (ou servidores):
Cada nó é um servidor físico executado no sistema operacional HCI do Azure Stack.
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 através de duas portas de adaptador de rede física dedicadas 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 mesh 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.
Os 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 de switch de rede extras para armazenamento e elimina a necessidade de aplicar a configuração de QoS ou PFC para tráfego SMB Direct ou RDMA nos switches de rede.
Consulte o seu parceiro fabricante de hardware ou fornecedor de placa de interface de rede (NIC) para obter quaisquer controladores de SO recomendados, versões de firmware ou definições de firmware para a configuração de rede de interligação sem comutador.
Switches Top-of-Rack (ToR) duplos:
Essa configuração é sem switch para o tráfego de armazenamento, mas ainda requer switches ToR para a conectividade externa. Essa conectividade é chamada de tráfego norte-sul e inclui a intenção do de gerenciamento de
de cluster e a carga de trabalho as intenções de computação .Os uplinks para os switches de cada nó usam duas portas de adaptador de rede. Os cabos Ethernet conectam essas portas, uma a cada switch ToR, para fornecer redundância de link.
Recomendamos que você use switches ToR duplos para fornecer redundância para operações de manutenção e balanceamento de carga para comunicação externa.
Conectividade externa:
Os switches ToR duplos se conectam à rede externa, como a LAN corporativa interna, e usam seu dispositivo de rede de borda de borda, como um firewall ou roteador, para fornecer acesso às URLs de saída necessárias.
Os dois switches 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 lógica de rede
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 comutação de armazenamento de três nós:
Comutadores ToR duplos:
- Antes da implantação do cluster, os dois switches de rede ToR precisam ser configurados com as IDs de VLAN necessárias e as configurações de MTU (unidade máxima de transmissão) para as portas de gerenciamento e computação. Para obter mais informações, consulte a requisitos de rede física ou peça ajuda ao fornecedor de hardware do switch ou ao parceiro integrador de sistemas (SI).
O Azure Local aplica automação de rede e configuração de rede baseada em usando o serviço ATC de Rede .
O ATC de rede foi projetado para garantir a configuração de rede ideal e o fluxo de tráfego usando o tráfego de rede intenções. O ATC de rede define quais portas físicas do adaptador de rede são usadas para as diferentes intenções (ou tipos) de tráfego de rede, como para ode gerenciamento de
de cluster,de computação de carga de trabalho e de armazenamento de de cluster. As políticas baseadas em intenção simplificam os requisitos de configuração de rede automatizando a configuração de rede do nó com base em entradas de parâmetros especificadas como parte do processo de implantação da nuvem local do Azure.
Comunicação externa:
Quando os nós ou a carga de trabalho precisam se comunicar externamente acessando a LAN corporativa, a Internet ou outro serviço, eles roteiam usando os switches ToR duplos. Esse processo é descrito na seção anterior 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 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 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 máquinas virtuais (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 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 ethernet de interconexão direta por nó, que usam seis redes não roteáveis separadas (ou Camada 2) 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 no sistema operacional HCI do Azure Stack.
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 disponíveis em cada nó. SMB Multichannel é usado para resiliência.
Essa configuração garante 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 de endereço IP
Para implantar uma configuração de armazenamento sem opção 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 um mínimo de 20 endereços IP. Mais endereços IP são necessários se você usar um dispositivo VM fornecido pelo seu parceiro fabricante de hardware ou se você usar microssegmentação ou rede definida por software (SDN). Para obter mais informações, consulte Revisar os requisitos de IP do padrão de referência de armazenamento de três nós para o Azure Local.
Ao projetar e planejar os requisitos de endereço IP para o Azure Local, lembre-se de considerar endereços IP adicionais ou intervalos de rede necessários para sua carga de trabalho além dos necessários para a instância Local do Azure e os componentes de infraestrutura. Se você planeja usar os Serviços Kubernetes do Azure (AKS) 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
Analise as considerações do Well-Architected Framework descritas na arquitetura de referência de linha de base local do Azure.
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:
- Interconexões de cluster sem comutador versus interconexões de cluster baseadas em switch. A topologia de interconexão sem switch consiste em conexões entre portas duplas, ou portas redundantes de, de adaptador de rede compatível 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ó é suportada 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 switch de armazenamento que não oferece suporte a operações de nó suplementar.
Eficiência de desempenho
Eficiência de desempenho é a capacidade de sua carga de trabalho de escalar para atender às demandas colocadas pelos usuários de maneira eficiente. Para obter mais informações, consulte Visão geral do pilar Eficiência de desempenho.
As considerações de eficiência de desempenho incluem:
- Não é possível aumentar a escala (ou executar uma operação de nó adicional) de um cluster HCI sem switch 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 tráfego de armazenamento e os outros nós necessários. Três nós são o tamanho máximo de cluster suportado 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 suportar o crescimento futuro da capacidade de carga de trabalho.
Implantar este cenário
Para obter mais informações sobre como projetar, adquirir e implantar uma solução Local do Azure, consulte a seção Implantar este cenário da arquitetura de referência de linha de base do Azure Local.
Use o seguinte modelo de automação de implantação como um exemplo de como implantar o Azure Local usando a arquitetura sem switch de armazenamento de três nós.
Dica
Recursos relacionados
- Projeto de arquitetura híbrida
- Opções híbridas do Azure
- Automação do Azure em um ambiente híbrido
- de Configuração do Estado de Automação do Azure
- Otimize a administração de instâncias do SQL Server em ambientes locais e multicloud usando o Azure Arc
Próximos passos
Documentação do produto:
- Azure Stack HCI OS, versão 23H2 informações de versão
- AKS no Azure Local
- Área de Trabalho Virtual do Azure para Local do Azure
- O que é o monitoramento Local do Azure?
- Proteja cargas de trabalho de VM com a Recuperação de Site no Azure Local
- Visão geral do Azure Monitor
- Visão geral do controle de alterações e do inventário
- Visão geral do Azure Update Manager
- O que são serviços de dados habilitados para Azure Arc?
- O que são servidores habilitados para Azure Arc?
- O que é o 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
- Azure Arc
- do Azure Key Vault
- de Armazenamento de Blob do Azure
- Monitor
- Azure Policy
- Registro de Contêiner do Azure
- Microsoft Defender for Cloud
- Azure Site Recovery
- Backup
Módulos do Microsoft Learn:
- Configurar o Monitor
- Projete sua solução de recuperação de site no Azure
- Introdução aos servidores habilitados para Azure Arc
- Introdução aos serviços de dados habilitados para Azure Arc
- Introdução ao AKS
- Dimensione a implantação do modelo com o Azure Machine Learning em qualquer lugar - Blog da Comunidade Técnica
- Realizando Machine Learning em qualquer lugar com AKS e aprendizado de máquina habilitado para Arc - Tech Community Blog
- Aprendizado de máquina no AKS híbrido e no Stack HCI usando o aprendizado de máquina habilitado para Azure Arc - Tech Community Blog
- Mantenha suas máquinas virtuais atualizadas
- Proteja suas configurações de máquina virtual com o Azure Automation State Configuration
- Proteja suas VMs usando o Backup