Architettura senza cambio di archiviazione a tre nodi di Azure Stack HCI

Questo articolo fa parte di una serie basata sull'architettura di riferimento della baseline di Azure Stack HCI. Per distribuire in modo efficace Azure Stack HCI usando una progettazione senza cambio di archiviazione a tre nodi, è importante comprendere l'architettura di base. Questo processo include familiarità con le scelte di progettazione del cluster per i nodi fisici che offrono funzionalità di calcolo, archiviazione e rete locali. Queste informazioni consentono di identificare le modifiche necessarie per una distribuzione corretta. Le indicazioni contenute in questo articolo si applicano anche a una distribuzione senza commutatori di archiviazione a due nodi e apporta modifiche necessarie per i casi in cui il numero di nodi fisici diminuisce da tre a due.

La progettazione della rete senza commutatori di archiviazione rimuove il requisito per i commutatori di rete della classe di archiviazione per connettere le porte della scheda di rete usate per il traffico di archiviazione. I nodi vengono invece connessi direttamente tramite cavi Ethernet interlink. Questa configurazione viene comunemente usata negli scenari di vendita al dettaglio, produzione o ufficio remoto. Questa configurazione è adatta anche ai casi d'uso perimetrali più piccoli che non hanno o richiedono commutatori di rete di data center estesi per il traffico di replica di archiviazione.

Questa architettura di riferimento fornisce indicazioni indipendenti dai carichi di lavoro e consigli per la configurazione di Azure Stack HCI come piattaforma di infrastruttura resiliente per distribuire e gestire carichi di lavoro virtualizzati. Per altre informazioni sui modelli di architettura del carico di lavoro ottimizzati per l'esecuzione in Azure Stack HCI, vedere il contenuto disponibile nel menu di spostamento dei carichi di lavoro di Azure Stack HCI.

Questa architettura è un punto di partenza per un cluster Azure Stack HCI a tre nodi che usa una progettazione di rete senza commutatori di archiviazione. Le applicazioni del carico di lavoro distribuite in un cluster Azure Stack HCI devono essere ben progettata. Questo approccio include la distribuzione di più istanze per la disponibilità elevata di tutti i servizi del carico di lavoro critici e l'implementazione di controlli di continuità aziendale e ripristino di emergenza appropriati, ad esempio backup regolari e funzionalità di failover di ripristino di emergenza. Per concentrarsi sulla piattaforma dell'infrastruttura HCI, questi aspetti di progettazione del carico di lavoro sono intenzionalmente esclusi da questo articolo. Per altre informazioni sulle linee guida e le raccomandazioni per i cinque pilastri di Azure Well-Architected Framework, vedere la guida al servizio Azure Stack HCI Well-Architected Framework.

Layout articolo

Architettura

Per altre informazioni su queste risorse, vedere Risorse correlate.

Potenziali casi d'uso

Usare questa progettazione e le progettazioni descritte nell'architettura di riferimento della baseline di Azure Stack HCI per soddisfare i requisiti dei casi d'uso seguenti:

• Distribuire e gestire carichi di lavoro perimetrali virtualizzati o basati su contenitori a disponibilità elevata distribuiti in un'unica posizione per consentire alle applicazioni e ai servizi critici aziendali di operare in modo resiliente, conveniente e scalabile.

• La progettazione della rete senza commutatori di archiviazione rimuove il requisito di distribuire commutatori di rete della classe di archiviazione per connettere le porte della scheda di rete usate per il traffico di archiviazione.

• È possibile usare la progettazione di rete senza commutatori di archiviazione per ridurre i costi associati all'approvvigionamento e alla configurazione dei commutatori di rete della classe di archiviazione per il traffico di archiviazione, ma aumenta il numero di porte della scheda di rete necessarie nei nodi fisici.

Componenti dell'architettura

Le risorse dell'architettura rimangono per lo più invariate rispetto all'architettura di riferimento di base. Per altre informazioni, vedere le risorse della piattaforma e le risorse di supporto della piattaforma usate per le distribuzioni di Azure Stack HCI.

Scelte di progettazione del cluster

Quando si determinano le opzioni di progettazione del cluster, fare riferimento all'architettura di riferimento di base. Usare queste informazioni dettagliate e lo strumento Azure Stack HCI Sizer per ridimensionare in modo appropriato un cluster Azure Stack HCI in base ai requisiti del carico di lavoro.

Quando si usa la progettazione senza cambio di archiviazione, è fondamentale ricordare che un cluster a tre nodi è la dimensione massima supportata. Questa limitazione è una considerazione fondamentale per le scelte di progettazione del cluster perché è necessario assicurarsi che i requisiti di capacità del carico di lavoro non superino le funzionalità di capacità fisica delle specifiche del cluster a tre nodi. Poiché non è possibile eseguire un movimento del nodo aggiuntivo per espandere un cluster senza cambio di archiviazione oltre tre nodi, è fondamentale comprendere in anticipo i requisiti di capacità del carico di lavoro e pianificare la crescita futura. In questo modo è possibile assicurarsi che il carico di lavoro non superi la capacità di archiviazione e calcolo per la durata prevista dell'hardware del cluster Azure Stack HCI.

Progettazione della rete

La progettazione di rete si riferisce alla disposizione complessiva dei componenti fisici e logici all'interno della rete. In una configurazione senza commutatori di archiviazione a tre nodi per Azure Stack HCI, tre nodi fisici sono connessi direttamente senza usare un commutatore esterno per il traffico di archiviazione. Queste connessioni Ethernet collegate dirette semplificano la progettazione della rete riducendo la complessità perché non è necessario definire o applicare la qualità del servizio di archiviazione e le configurazioni di definizione delle priorità nei commutatori. Le tecnologie che supportano la comunicazione RDMA senza perdita, ad esempio la notifica esplicita della congestione (ECN), il controllo del flusso di priorità (PFC) o la qualità del servizio (QoS) necessari per RoCE v2 e iWARP, non sono necessarie. Tuttavia, questa configurazione supporta un massimo di tre nodi, il che significa che non è possibile ridimensionare il cluster aggiungendo altri nodi dopo la distribuzione.

Topologia di rete fisica

La topologia di rete fisica mostra le connessioni fisiche effettive tra nodi e componenti di rete. Le connessioni tra nodi e componenti di rete per una distribuzione senza cambio di archiviazione a tre nodi di Azure Stack HCI sono:

• Tre nodi (o server):

  • Ogni nodo è un server fisico eseguito nel sistema operativo Azure Stack HCI.

  • Ogni nodo richiede sei porte della scheda di rete in totale: quattro porte con supporto per RDMA per l'archiviazione e due porte per la gestione e il calcolo.

• Traffico di archiviazione:

  • Ognuno dei tre nodi è interconnesso tramite due porte di schede di rete fisiche dedicate per l'archiviazione. La figura seguente illustra questo processo.

  • Le porte della scheda di rete di archiviazione si connettono direttamente a ogni nodo usando cavi Ethernet per formare un'architettura di rete mesh completa per il traffico di archiviazione.

  • Questa progettazione offre ridondanza dei collegamenti, bassa latenza dedicata, larghezza di banda elevata e velocità effettiva elevata.

  • I nodi all'interno del cluster HCI comunicano direttamente tramite questi collegamenti per gestire il traffico di replica di archiviazione, noto anche come traffico east-west.

  • Questa comunicazione diretta elimina la necessità di porte aggiuntive del commutatore di rete per l'archiviazione e rimuove il requisito di applicare la configurazione QoS o PFC per il traffico SMB diretto o RDMA nei commutatori di rete.

  • Rivolgersi al partner del produttore hardware o al fornitore della scheda di interfaccia di rete (NIC) per eventuali driver del sistema operativo, versioni del firmware o impostazioni del firmware consigliati per la configurazione di rete di interconnessione senza commutatori.

• Doppio commutatore Top-of-Rack (ToR):

  • Questa configurazione è senza cambio per il traffico di archiviazione, ma richiede comunque commutatori ToR per la connettività esterna. Questa connettività è denominata traffico nord-sud e include la finalità di gestione del cluster e le finalità di calcolo del carico di lavoro.

  • I collegamenti uplink ai commutatori da ogni nodo usano due porte della scheda di rete. I cavi Ethernet connettono queste porte, una a ogni commutatore ToR, per fornire ridondanza dei collegamenti.

  • È consigliabile usare due commutatori ToR per fornire ridondanza per le operazioni di manutenzione e il bilanciamento del carico per le comunicazioni esterne.

• Connettività esterna:

  • I due commutatori ToR si connettono alla rete esterna, ad esempio la LAN aziendale interna, e usano il dispositivo di rete perimetrale, ad esempio un firewall o un router, per fornire l'accesso agli URL in uscita necessari.

  • I due commutatori ToR gestiscono il traffico nord-sud per il cluster Azure Stack HCI, incluso il traffico correlato alle finalità di gestione e calcolo.

    

Topologia di rete logica

La topologia di rete logica offre una panoramica del flusso dei dati di rete tra i dispositivi, indipendentemente dalle connessioni fisiche. L'elenco seguente riepiloga la configurazione logica per un cluster Azure Stack HCI senza commutatori di archiviazione a tre nodi:

• Commutatori Dual ToR:

  • Prima della distribuzione del cluster, i due commutatori di rete ToR devono essere configurati con gli ID VLAN necessari e le impostazioni massime dell'unità di trasmissione (MTU) per le porte di gestione e calcolo. Per altre informazioni, vedere i requisiti di rete fisica o chiedere al fornitore di hardware switch o al partner di integratore di sistemi (SI) di assistenza.

• Azure Stack HCI applica l'automazione della rete e la configurazione di rete basata sulle finalità usando il servizio Network ATC.

  • Network ATC è progettato per garantire una configurazione di rete e un flusso di traffico ottimali usando le finalità del traffico di rete. Network ATC definisce le porte della scheda di rete fisica usate per le diverse finalità o tipi di traffico di rete, ad esempio per la gestione del cluster, il calcolo del carico di lavoro e le finalità di archiviazione del cluster.

  • I criteri basati sulle finalità semplificano i requisiti di configurazione di rete automatizzando la configurazione di rete del nodo in base agli input dei parametri specificati come parte del processo di distribuzione cloud di Azure Stack HCI.

• Comunicazione esterna:

  • Quando i nodi o il carico di lavoro devono comunicare esternamente accedendo alla rete LAN aziendale, a Internet o a un altro servizio, instradano tramite i due commutatori ToR. Questo processo è descritto nella sezione precedente Topologia di rete fisica.

  • Quando i due commutatori ToR fungono da dispositivi di livello 3, gestiscono il routing e forniscono connettività oltre il cluster al dispositivo perimetrale, ad esempio il firewall o il router.

  • La finalità di rete di gestione usa l'interfaccia virtuale SET (Converged Switch Embedded Teaming), che consente alle risorse dell'indirizzo IP di gestione del cluster e del piano di controllo di comunicare esternamente.

  • Per la finalità di rete di calcolo, è possibile creare una o più reti logiche in Azure con gli ID VLAN specifici per l'ambiente. Le risorse del carico di lavoro, ad esempio le macchine virtuali, usano questi ID per concedere l'accesso alla rete fisica. Le reti logiche usano le due porte della scheda di rete fisica convergenti usando SET per le finalità di calcolo e gestione.

• Traffico di archiviazione:

  • I nodi comunicano tra loro direttamente per il traffico di archiviazione usando le quattro porte Ethernet di interconnessione diretta per nodo, che usano sei reti nonroutable separate (o di livello 2) per il traffico di archiviazione.

  • Non è configurato alcun gateway predefinito nelle quattro porte della scheda di rete delle finalità di archiviazione all'interno del sistema operativo del nodo Azure Stack HCI.

  • Ogni nodo può accedere alle funzionalità S2D del cluster, ad esempio dischi fisici remoti usati nel pool di archiviazione, nei dischi virtuali e nei volumi. L'accesso a queste funzionalità è facilitato tramite il protocollo SMB Direct RDMA sulle due porte della scheda di rete di archiviazione dedicate disponibili in ogni nodo. SMB multicanale viene usato per la resilienza.

  • Questa configurazione garantisce una velocità di trasferimento dei dati sufficiente per le operazioni correlate all'archiviazione, ad esempio la gestione di copie coerenti dei dati per i volumi con mirroring.

    

    Diagramma che mostra la topologia di rete logica per un cluster Azure Stack HCI a tre nodi. Usa un'architettura di archiviazione senza cambio con due commutatori ToR per la connettività esterna (o nord-sud).

Requisiti degli indirizzi IP

Per distribuire una configurazione senza cambio di archiviazione a tre nodi di Azure Stack HCI con due collegamenti per le interconnessioni di archiviazione, la piattaforma dell'infrastruttura del cluster richiede di allocare almeno 20 indirizzi IP. Sono necessari più indirizzi IP se si usa un'appliance VM fornita dal partner del produttore hardware o se si usa la microsegmentazione o la rete SDN (Software Defined Networking). Per altre informazioni, vedere Esaminare i requisiti IP del modello di riferimento per l'archiviazione a tre nodi per Azure Stack HCI.

Quando si progettano e si pianificano i requisiti degli indirizzi IP per Azure Stack HCI, tenere presente di tenere conto degli indirizzi IP aggiuntivi o degli intervalli di rete necessari per il carico di lavoro oltre a quelli necessari per i componenti del cluster e dell'infrastruttura di Azure Stack HCI. Se si prevede di usare servizio Azure Kubernetes s (AKS) in Azure Stack HCI, vedere Servizio Azure Kubernetes abilitato dai requisiti di rete di Azure Arc.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Le considerazioni sull'ottimizzazione dei costi includono:

• Interconnessioni di cluster senza cambio rispetto alle interconnessioni cluster basate su commutatore. La topologia di interconnessione senza commutatori è costituita da connessioni tra porte con doppia porta o schede di rete con supporto per RDMA in ogni nodo per formare una mesh completa. Ogni nodo ha due connessioni dirette a ogni altro nodo. Anche se questa implementazione è semplice, è supportata solo in cluster a due nodi o a tre nodi. Un cluster Azure Stack HCI con quattro o più nodi richiede l'architettura di rete commutata dall'archiviazione. È possibile usare questa architettura per aggiungere altri nodi dopo la distribuzione, a differenza della progettazione senza cambio di archiviazione che non supporta le operazioni di componente aggiuntivo.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.

Le considerazioni sull'efficienza delle prestazioni includono:

• Non è possibile aumentare la scalabilità (o eseguire un'operazione add-node) di un cluster HCI senza commutatori di archiviazione a tre nodi esistente senza ridistribuire il cluster e aggiungere funzionalità di rete aggiuntive, ad esempio commutatori di rete, porte e cavi per il traffico di archiviazione e gli altri nodi necessari. Tre nodi sono le dimensioni massime supportate del cluster per la progettazione della rete senza commutatori di archiviazione. Considerare questa limitazione nella fase di progettazione del cluster per garantire che l'hardware possa supportare la crescita futura della capacità del carico di lavoro.

Distribuire lo scenario

Per altre informazioni su come progettare, acquistare e distribuire una soluzione Azure Stack HCI, vedere la sezione Distribuire questo scenario dell'architettura di riferimento di riferimento di Azure Stack HCI.

Usare il modello di automazione della distribuzione seguente come esempio di come distribuire Azure Stack HCI usando l'architettura senza commutatori di archiviazione a tre nodi.

Risorse correlate

• Design dell'architettura ibrida
• Opzioni ibride di Azure
• Automazione di Azure in un ambiente ibrido
• State Configuration di Automazione di Azure
• Ottimizzare l'amministrazione di istanze di SQL Server in ambienti locali e multicloud usando Azure Arc

Passaggi successivi

Documentazione sui prodotti:

• Informazioni sulla versione 23H2 di Azure Stack HCI
• Servizio Azure Kubernetes in Azure Stack HCI
• Desktop virtuale Azure per Azure Stack HCI
• Che cos'è il monitoraggio di Azure Stack HCI?
• Proteggere i carichi di lavoro delle macchine virtuali con Site Recovery in Azure Stack HCI
• Panoramica di Monitoraggio di Azure
• Panoramica di Rilevamento modifiche e inventario
• Panoramica di Azure Update Manager
• Che cosa sono i servizi dati abilitati per Azure Arc?
• Che cosa sono i server abilitati per Azure Arc?
• Informazioni su Backup di Azure
• Introduzione alla destinazione di calcolo di Kubernetes in Azure Machine Learning

Documentazione del prodotto per servizi di Azure specifici:

• Azure Stack HCI
• Azure Arc
• Azure Key Vault
• Archiviazione BLOB di Azure
• Monitoraggio
• Criteri di Azure
• Registro Azure Container
• Microsoft Defender per il cloud
• Azure Site Recovery
• Backup

Moduli di Microsoft Learn:

• Configurare monitoraggio
• Progettare la soluzione di site recovery in Azure
• Introduzione ai server abilitati per Azure Arc
• Introduzione ai servizi dati abilitati per Azure Arc
• Introduzione al servizio Azure Kubernetes
• Ridimensionare la distribuzione di modelli con Azure Machine Learning ovunque - Blog della community tecnica
• Creazione di Machine Learning ovunque con servizio Azure Kubernetes e Machine Learning abilitato per Arc - Blog della community tecnica
• Machine Learning in azure Kubernetes ibrido e Stack HCI con Machine Learning abilitato per Azure Arc - Blog della community tecnica
• Mantenere le macchine virtuali sempre aggiornate
• Proteggere le impostazioni della macchina virtuale con Automazione di Azure State Configuration
• Proteggere le macchine virtuali usando Backup