Architettura di riferimento della baseline di Azure Stack HCI

Questa architettura di riferimento di base fornisce indicazioni indipendenti dai carichi di lavoro e consigli per la configurazione dell'infrastruttura Azure Stack HCI 23H2 e versioni successive per garantire una piattaforma affidabile in grado di distribuire e gestire carichi di lavoro virtualizzati e in contenitori a disponibilità elevata. Questa architettura descrive i componenti delle risorse e le scelte di progettazione del cluster per i nodi fisici che forniscono funzionalità di calcolo, archiviazione e rete locali. Descrive anche come usare i servizi di Azure per semplificare e semplificare la gestione quotidiana di Azure Stack HCI.

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 usare la progettazione della rete commutata di archiviazione per distribuire un cluster Azure Stack HCI multinodo. Le applicazioni del carico di lavoro distribuite in un cluster Azure Stack HCI devono essere ben progettata. Le applicazioni di carico di lavoro ben strutturate devono essere distribuite usando più istanze o disponibilità elevata di qualsiasi servizio di carico di lavoro critico e devono disporre di controlli di continuità aziendale e ripristino di emergenza appropriati. Questi controlli BCDR includono 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, vedere Risorse correlate.

Potenziali casi d'uso

I casi d'uso tipici per Azure Stack HCI includono la possibilità di eseguire carichi di lavoro a disponibilità elevata in posizioni locali o perimetrali, che offre una soluzione per soddisfare i requisiti del carico di lavoro. È possibile:

• Fornire una soluzione cloud ibrida distribuita in locale per soddisfare i requisiti di sovranità dei dati, normative e conformità o latenza.

• Distribuire e gestire carichi di lavoro perimetrali virtualizzati o basati su contenitori distribuiti in un'unica posizione o in più posizioni. Questa strategia consente alle applicazioni e ai servizi critici per l'azienda di operare in modo resiliente, conveniente e scalabile.

• Ridurre il costo totale di proprietà (TCO) usando soluzioni certificate da Microsoft, distribuzione basata sul cloud, gestione centralizzata e monitoraggio e avvisi.

• Offrire una funzionalità di provisioning centralizzata usando Azure e Azure Arc per distribuire i carichi di lavoro in più posizioni in modo coerente e sicuro. Gli strumenti come i modelli portale di Azure, interfaccia della riga di comando di Azure o infrastruttura come codice (IaC) usano Kubernetes per la containerizzazione o la virtualizzazione tradizionale dei carichi di lavoro per favorire l'automazione e la ripetibilità.

• Rispettare requisiti rigorosi di sicurezza, conformità e controllo. Azure Stack HCI viene distribuito con un comportamento di sicurezza con protezione avanzata configurato per impostazione predefinita o protetto per impostazione predefinita. Azure Stack HCI incorpora hardware certificato, avvio protetto, TPM (Trusted Platform Module), sicurezza basata su virtualizzazione (VBS), Credential Guard e criteri di controllo delle applicazioni di Windows Defender. Si integra anche con i moderni servizi di sicurezza e gestione delle minacce basati sul cloud, ad esempio Microsoft Defender per il cloud e Microsoft Sentinel.

Dettagli dello scenario

Le sezioni seguenti forniscono altre informazioni sugli scenari e sui potenziali casi d'uso per questa architettura di riferimento. Queste sezioni includono un elenco dei vantaggi aziendali e dei tipi di risorse del carico di lavoro di esempio che è possibile distribuire in Azure Stack HCI.

Usare Azure Arc con Azure Stack HCI

Azure Stack HCI si integra direttamente con Azure usando Azure Arc per ridurre il costo totale di proprietà e il sovraccarico operativo. Azure Stack HCI viene distribuito e gestito tramite Azure, che offre l'integrazione predefinita di Azure Arc tramite la distribuzione del componente del bridge di risorse di Azure Arc. Questo componente viene installato durante il processo di distribuzione del cluster HCI. I nodi del cluster Azure Stack HCI vengono registrati con Azure Arc per i server come prerequisito per avviare la distribuzione basata sul cloud del cluster. Durante la distribuzione, le estensioni obbligatorie vengono installate in ogni nodo del cluster, ad esempio Lifecycle Manager, Microsoft Edge Gestione dispositivi e Telemetria e Diagnostica. È possibile usare Monitoraggio di Azure e Log Analytics per monitorare il cluster HCI dopo la distribuzione abilitando Azure Stack HCI Insights. Gli aggiornamenti delle funzionalità per Azure Stack HCI vengono rilasciati periodicamente per migliorare l'esperienza del cliente. Gli aggiornamenti vengono controllati e gestiti tramite Gestione aggiornamenti di Azure.

È possibile distribuire risorse del carico di lavoro come macchine virtuali (VM) di Azure Arc, servizio Azure Kubernetes abilitate per Azure Arc e host di sessione di Desktop virtuale Azure che usano il portale di Azure selezionando un percorso personalizzato del cluster Azure Stack HCI come destinazione per la distribuzione del carico di lavoro. Questi componenti forniscono amministrazione, gestione e supporto centralizzati. Se si dispone di software Assurance attivo nelle licenze principali di Windows Server Datacenter esistenti, è possibile ridurre ulteriormente i costi applicando Vantaggio Azure Hybrid ai cluster azure Stack HCI, macchine virtuali Windows Server e cluster del servizio Azure Kubernetes. Questa ottimizzazione consente di gestire in modo efficace i costi per questi servizi.

L'integrazione di Azure e Azure Arc estendono le funzionalità dei carichi di lavoro virtualizzati e in contenitori di Azure Stack HCI da includere:

• Macchine virtuali Di Azure Arc per applicazioni o servizi tradizionali eseguiti in macchine virtuali in Azure Stack HCI.

• Servizio Azure Kubernetes in Azure Stack HCI per applicazioni o servizi in contenitori che traggono vantaggio dall'uso di Kubernetes come piattaforma di orchestrazione.

• Desktop virtuale Azure per distribuire gli host di sessione per i carichi di lavoro di Desktop virtuale Azure in Azure Stack HCI (locale). È possibile usare il piano di controllo e gestione in Azure per avviare la creazione e la configurazione del pool di host.

• Servizi dati abilitati per Azure Arc per Istanza gestita di SQL di Azure in contenitori o un server Database di Azure per PostgreSQL che usano il servizio Azure Arc abilitato per il servizio Azure Kubernetes ospitato in Azure Stack HCI.

• L'estensione Griglia di eventi di Azure abilitata per Azure Arc per Kubernetes per distribuire i componenti dell'operatore Broker di Griglia di eventi e Griglia di eventi. Questa distribuzione abilita funzionalità come argomenti e sottoscrizioni di Griglia di eventi per l'elaborazione di eventi.

• Machine Learning abilitato per Azure Arc con un cluster del servizio Azure Kubernetes distribuito in Azure Stack HCI come destinazione di calcolo per eseguire Azure Machine Learning. È possibile usare questo approccio per eseguire il training o la distribuzione di modelli di Machine Learning nei dispositivi perimetrali.

I carichi di lavoro connessi ad Azure Arc offrono coerenza e automazione di Azure avanzate per le distribuzioni di Azure Stack HCI, ad esempio l'automazione della configurazione del sistema operativo guest con le estensioni della macchina virtuale Di Azure Arc o la valutazione della conformità alle normative del settore o agli standard aziendali tramite Criteri di Azure. È possibile attivare Criteri di Azure tramite l'automazione portale di Azure o IaC.

Sfruttare la configurazione di sicurezza predefinita di Azure Stack HCI

La configurazione di sicurezza predefinita di Azure Stack HCI offre una strategia di difesa avanzata per semplificare i costi di sicurezza e conformità. La distribuzione e la gestione dei servizi IT per scenari di vendita al dettaglio, produzione e ufficio remoto presentano problemi di sicurezza e conformità univoci. La protezione dei carichi di lavoro dalle minacce interne ed esterne è fondamentale negli ambienti con supporto IT limitato o mancanza o data center dedicati. Azure Stack HCI offre la protezione avanzata predefinita e l'integrazione approfondita con i servizi di Azure per risolvere questi problemi.

L'hardware certificato Azure Stack HCI garantisce l'avvio protetto predefinito, l'interfaccia UEFI (Unified Extensible Firmware Interface) e il supporto TPM. Usare queste tecnologie in combinazione con la sicurezza basata su virtualizzazione per proteggere i carichi di lavoro sensibili alla sicurezza. È possibile usare Crittografia unità BitLocker per crittografare i volumi dei dischi di avvio e gli spazi di archiviazione diretti inattivi. La crittografia SMB (Server Message Block) fornisce la crittografia automatica del traffico tra i server nel cluster (nella rete di archiviazione) e la firma del traffico SMB tra i nodi del cluster e altri sistemi. La crittografia SMB consente anche di evitare attacchi di inoltro e facilita la conformità agli standard normativi.

È possibile eseguire l'onboarding di macchine virtuali di Azure Stack HCI in Defender per il cloud per attivare l'analisi comportamentale basata sul cloud, il rilevamento delle minacce e la correzione, gli avvisi e la creazione di report. Gestire le macchine virtuali di Azure Stack HCI in Azure Arc in modo da poter usare Criteri di Azure per valutare la conformità alle normative del settore e agli standard aziendali.

Componenti

Questa architettura è costituita da hardware server fisico che è possibile usare per distribuire cluster Azure Stack HCI in posizioni locali o perimetrali. Per migliorare le funzionalità della piattaforma, Azure Stack HCI si integra con Azure Arc e altri servizi di Azure che forniscono risorse di supporto. Azure Stack HCI offre una piattaforma resiliente per distribuire, gestire e gestire applicazioni utente o sistemi aziendali. Le risorse e i servizi della piattaforma sono descritti nelle sezioni seguenti.

Risorse della piattaforma

L'architettura richiede le risorse e i componenti obbligatori seguenti:

• Azure Stack HCI è una soluzione HCI (Hyperconverged Infrastructure) distribuita in locale o in posizioni perimetrali usando hardware server fisico e infrastruttura di rete. Azure Stack HCI offre una piattaforma per distribuire e gestire carichi di lavoro virtualizzati, ad esempio macchine virtuali, cluster Kubernetes e altri servizi abilitati da Azure Arc. I cluster Azure Stack HCI possono essere ridimensionati da una distribuzione a nodo singolo a un massimo di sedici nodi usando categorie hardware convalidate, integrate o premium fornite dai partner OEM (Original Equipment Manufacturer).

• Azure Arc è un servizio basato sul cloud che estende il modello di gestione basato su Azure Resource Manager ad Azure Stack HCI e ad altre posizioni non di Azure. Azure Arc usa Azure come piano di controllo e gestione per abilitare la gestione di varie risorse, ad esempio macchine virtuali, cluster Kubernetes e dati in contenitori e servizi di Machine Learning.

• Azure Key Vault è un servizio cloud che è possibile usare per archiviare e accedere in modo sicuro ai segreti. Un segreto è qualsiasi elemento a cui si vuole limitare strettamente l'accesso, ad esempio chiavi API, password, certificati, chiavi crittografiche, credenziali di amministratore locale e chiavi di ripristino di BitLocker.

• Il controllo cloud è una funzionalità di Archiviazione di Azure che funge da quorum del cluster di failover. I nodi del cluster Azure Stack HCI usano questo quorum per il voto, garantendo una disponibilità elevata per il cluster. L'account di archiviazione e la configurazione del server di controllo del mirroring vengono creati durante il processo di distribuzione cloud di Azure Stack HCI.

• Update Manager è un servizio unificato progettato per gestire e gestire gli aggiornamenti per Azure Stack HCI. È possibile usare Gestione aggiornamenti per gestire i carichi di lavoro distribuiti in Azure Stack HCI, inclusa la conformità degli aggiornamenti del sistema operativo guest per le macchine virtuali Windows e Linux. Questo approccio unificato semplifica la gestione delle patch in Azure, negli ambienti locali e in altre piattaforme cloud tramite un singolo dashboard.

Risorse di supporto della piattaforma

L'architettura include i servizi di supporto facoltativi seguenti per migliorare le funzionalità della piattaforma:

• Monitoraggio è un servizio basato sul cloud per la raccolta, l'analisi e l'azione sui log di diagnostica e i dati di telemetria dai carichi di lavoro cloud e locali. È possibile usare Monitoraggio per ottimizzare la disponibilità e le prestazioni delle applicazioni e dei servizi tramite una soluzione di monitoraggio completa. Distribuire Azure Stack HCI Insights per semplificare la creazione della regola di raccolta dati di Monitoraggio e abilitare rapidamente il monitoraggio dei cluster Azure Stack HCI.

• Criteri di Azure è un servizio che valuta le risorse di Azure e locali. Criteri di Azure valuta le risorse tramite l'integrazione con Azure Arc usando le proprietà di tali risorse alle regole business, denominate definizioni dei criteri, per determinare la conformità o le funzionalità che è possibile usare per applicare la configurazione guest della macchina virtuale usando le impostazioni dei criteri.

• Defender per il cloud è un sistema completo di gestione della sicurezza dell'infrastruttura. Migliora il comportamento di sicurezza dei data center e offre una protezione avanzata dalle minacce per i carichi di lavoro ibridi, sia che si trovino in Azure o altrove e in ambienti locali.

• Backup di Azure è un servizio basato sul cloud che offre una soluzione semplice, sicura e conveniente per eseguire il backup dei dati e recuperarli da Microsoft Cloud. Backup di Azure Server viene usato per eseguire il backup delle macchine virtuali distribuite in Azure Stack HCI e archiviarle nel servizio Backup.

• Site Recovery è un servizio di ripristino di emergenza che offre funzionalità BCDR abilitando il failover di app e carichi di lavoro aziendali in caso di emergenza o interruzione. Site Recovery gestisce la replica e il failover dei carichi di lavoro eseguiti su server fisici e macchine virtuali tra il sito primario (locale) e una posizione secondaria (Azure).

Scelte di progettazione del cluster

È importante comprendere i requisiti di prestazioni e resilienza del carico di lavoro quando si progetta un cluster Azure Stack HCI. Questi requisiti includono gli obiettivi del tempo di ripristino (RTO) e i tempi del punto di ripristino (RPO), il calcolo (CPU), la memoria e i requisiti di archiviazione per tutti i carichi di lavoro distribuiti nel cluster Azure Stack HCI. Diverse caratteristiche del carico di lavoro influiscono sul processo decisionale e includono:

• Funzionalità di architettura dell'unità di elaborazione centrale (CPU), incluse le funzionalità della tecnologia di sicurezza hardware, il numero di CPU, la frequenza GHz (velocità) e il numero di core per socket CPU.

• Requisiti dell'unità di elaborazione grafica (GPU) del carico di lavoro, ad esempio per intelligenza artificiale o Machine Learning, inferenza o rendering grafico.

• Memoria per nodo o quantità di memoria fisica necessaria per eseguire il carico di lavoro.

• Numero di nodi fisici nel cluster con scalabilità da 1 a 16 nodi. Il numero massimo di nodi è tre quando si usa l'architettura di rete senza commutatori di archiviazione.

  • Per mantenere la resilienza di calcolo, è necessario riservare almeno N+1 nodi di capacità nel cluster. Questa strategia consente lo svuotamento dei nodi per gli aggiornamenti o il ripristino da interruzioni improvvise, ad esempio interruzioni dell'alimentazione o errori hardware.

  • Per i carichi di lavoro critici per l'azienda o cruciali, prendere in considerazione la possibilità di riservare n+2 nodi di capacità per aumentare la resilienza. Ad esempio, se due nodi del cluster sono offline, il carico di lavoro può rimanere online. Questo approccio offre resilienza per gli scenari in cui un nodo che esegue un carico di lavoro passa offline durante una procedura di aggiornamento pianificata e comporta la connessione simultanea di due nodi.

• Requisiti di resilienza, capacità e prestazioni dell'archiviazione:

  • Resilienza: è consigliabile distribuire tre o più nodi per abilitare il mirroring a tre vie, che fornisce tre copie dei dati, per l'infrastruttura e i volumi utente. Il mirroring a tre vie aumenta le prestazioni e l'affidabilità massima per l'archiviazione.

  • Capacità: il totale spazio di archiviazione utilizzabile necessario dopo la tolleranza di errore o le copie viene preso in considerazione. Questo numero è circa il 33% dello spazio di archiviazione non elaborato dei dischi del livello di capacità quando si usa il mirroring a tre vie.

  • Prestazioni: operazioni di input/output al secondo (IOPS) della piattaforma che determina le funzionalità di velocità effettiva di archiviazione per il carico di lavoro quando moltiplicate per le dimensioni del blocco dell'applicazione.

Per progettare e pianificare una distribuzione di Azure Stack HCI, è consigliabile usare lo strumento di ridimensionamento di Azure Stack HCI e creare un nuovo progetto per ridimensionare i cluster HCI. Per usare lo strumento di ridimensionamento è necessario comprendere i requisiti del carico di lavoro. Quando si considera il numero e le dimensioni delle macchine virtuali del carico di lavoro eseguite nel cluster, assicurarsi di prendere in considerazione fattori quali il numero di vCPU, i requisiti di memoria e la capacità di archiviazione necessaria per le macchine virtuali.

La sezione Preferenze dello strumento di ridimensionamento illustra le domande relative al tipo di sistema (Premier, Sistema integrato o Nodo convalidato) e alle opzioni della famiglia di CPU. Consente anche di selezionare i requisiti di resilienza per il cluster. Verificare di:

• Riservare un minimo di N+1 nodi di capacità, o un nodo, nel cluster.

• Riservare n+2 nodi di capacità nel cluster per una maggiore resilienza. Questa opzione consente al sistema di resistere a un errore del nodo durante un aggiornamento o un altro evento imprevisto che influisce simultaneamente su due nodi. Garantisce inoltre che nel cluster sia disponibile una capacità sufficiente per l'esecuzione del carico di lavoro nei nodi online rimanenti.

Questo scenario richiede l'uso del mirroring a tre vie per i volumi utente, ovvero l'impostazione predefinita per i cluster con tre o più nodi fisici.

L'output dello strumento di ridimensionamento di Azure Stack HCI è un elenco di SKU di soluzioni hardware consigliate che possono fornire i requisiti di capacità del carico di lavoro e resilienza della piattaforma necessari in base ai valori di input nel progetto Sizer. Per altre informazioni sulle soluzioni dei partner hardware OEM disponibili, vedere Catalogo di soluzioni Azure Stack HCI. Per aiutare gli SKU della soluzione a soddisfare i requisiti, contattare il provider di soluzioni hardware o il partner di integrazione del sistema preferito.

Unità disco fisiche

Spazi di archiviazione diretta supporta più tipi di unità disco fisico che variano in base alle prestazioni e alla capacità. Quando si progetta un cluster Azure Stack HCI, collaborare con il partner OEM hardware scelto per determinare i tipi di unità disco fisici più appropriati per soddisfare i requisiti di capacità e prestazioni del carico di lavoro. Gli esempi includono unità DISCO rigido rotante (HDD) o unità SSD (Solid State Drive) e NVMe. Queste unità sono spesso chiamate unità flash o memoria persistente (PMem), nota come memoria della classe di archiviazione (SCM).

L'affidabilità della piattaforma dipende dalle prestazioni delle dipendenze critiche della piattaforma, ad esempio i tipi di disco fisico. Assicurarsi di scegliere i tipi di disco corretti per i requisiti. Usare soluzioni di archiviazione all-flash, ad esempio unità NVMe o SSD per carichi di lavoro con requisiti a prestazioni elevate o a bassa latenza. Questi carichi di lavoro includono, ad esempio, tecnologie di database altamente transazionali, cluster del servizio Azure Kubernetes di produzione o carichi di lavoro cruciali o critici per l'azienda con requisiti di archiviazione a bassa latenza o velocità effettiva elevata. Usare le distribuzioni all-flash per ottimizzare le prestazioni di archiviazione. Tutte le unità NVMe o tutte le configurazioni di unità SSD, in particolare su scala ridotta, migliorano l'efficienza di archiviazione e ottimizzano le prestazioni perché nessuna unità viene usata come livello di cachePer altre informazioni, vedere Archiviazione basata su tutti i flash.

Per i carichi di lavoro per utilizzo generico, una configurazione di archiviazione ibrida, ad esempio unità NVMe o UNITÀ SSD per cache e HDD per la capacità, potrebbe offrire più spazio di archiviazione. Il compromesso è che i dischi rotanti hanno prestazioni inferiori se il carico di lavoro supera il working set di cache e le unità HDD hanno un tempo medio inferiore tra il valore di errore rispetto alle unità NVMe e SSD.

Le prestazioni dell'archiviazione cluster sono influenzate dal tipo di unità disco fisico, che varia in base alle caratteristiche delle prestazioni di ogni tipo di unità e al meccanismo di memorizzazione nella cache scelto. Il tipo di unità disco fisico è parte integrante di qualsiasi Spazi di archiviazione diretta progettazione e configurazione. A seconda dei requisiti del carico di lavoro e dei vincoli di budget di Azure Stack HCI, è possibile scegliere di ottimizzare le prestazioni, ottimizzare la capacità o implementare una configurazione del tipo di unità mista che bilancia le prestazioni e la capacità.

Spazi di archiviazione diretta offre una cache predefinita, persistente, in tempo reale, di lettura, scrittura, lato server che ottimizza le prestazioni di archiviazione. La cache deve essere ridimensionata e configurata per supportare il working set di applicazioni e carichi di lavoro. Spazi di archiviazione diretta dischi virtuali, o volumi, vengono usati in combinazione con la cache in lettura in memoria (Volume condiviso cluster) per migliorare le prestazioni di Hyper-V, in particolare per l'accesso all'input non memorizzato nel carico di lavoro dei file VHD (Virtual Hard Disk) o VHDX (Virtual Hard Disk v2).

Progettazione della rete

La progettazione di rete è la disposizione complessiva dei componenti all'interno dell'infrastruttura fisica e delle configurazioni logiche della rete. È possibile usare le stesse porte della scheda di interfaccia di rete fisica per tutte le combinazioni di finalità di rete di gestione, calcolo e archiviazione. L'uso delle stesse porte della scheda di interfaccia di rete per tutti gli scopi correlati alle finalità è denominato configurazione di rete completamente convergente.

Sebbene sia supportata una configurazione di rete completamente convergente, la configurazione ottimale per le prestazioni e l'affidabilità è destinata all'uso delle porte della scheda di rete dedicate. Pertanto, questa architettura di base fornisce indicazioni di esempio per la distribuzione di un cluster Azure Stack HCI multinodo usando l'architettura di rete commutata di archiviazione con due porte della scheda di rete convergenti per finalità di gestione e calcolo e due porte di scheda di rete dedicate per la finalità di archiviazione. Per altre informazioni, vedere Considerazioni sulla rete per le distribuzioni cloud di Azure Stack HCI.

Questa architettura richiede due o più nodi fisici e fino a un massimo di 16 nodi in scala. Ogni nodo richiede quattro porte della scheda di rete connesse a due commutatori Top-of-Rack (ToR). I due commutatori ToR devono essere interconnessi tramite collegamenti MLAG (Multi-Chassis Link Aggregation Group). Le due porte della scheda di rete usate per il traffico delle finalità di archiviazione devono supportare Remote Direct Memory Access (RDMA).The two network adapter ports that are used for the storage intent traffic must support Remote Direct Memory Access (RDMA). Queste porte richiedono una velocità minima di collegamento di 10 Gbps, ma è consigliabile una velocità di 25 Gbps o superiore. Le due porte della scheda di rete usate per la gestione e le finalità di calcolo sono convergenti usando la tecnologia SET (Switch Embedded Teaming). La tecnologia SET offre funzionalità di ridondanza dei collegamenti e bilanciamento del carico. Queste porte richiedono una velocità minima di collegamento di 1 Gbps, ma è consigliabile una velocità di 10 Gbps o superiore.

Topologia di rete fisica

La topologia di rete fisica seguente mostra le connessioni fisiche effettive tra nodi e componenti di rete.

Quando si progetta una distribuzione multinodo di Archiviazione multinodo di Azure Stack HCI che usa questa architettura di base, sono necessari i componenti seguenti:

• Commutatori Dual ToR:

  • I commutatori di rete Dual ToR sono necessari per la resilienza di rete e la possibilità di gestire o applicare gli aggiornamenti del firmware ai commutatori senza incorrere in tempi di inattività. Questa strategia impedisce un singolo punto di guasto (SPoF).

  • I due commutatori ToR vengono usati per lo spazio di archiviazione o per il traffico est-ovest. Questi commutatori usano due porte Ethernet dedicate con reti di archiviazione locali (VLAN) e classi di traffico PFC (Priority Flow Control) definite per fornire comunicazioni RDMA senza perdita.

  • Questi commutatori si connettono ai nodi tramite cavi Ethernet.

• Due o più nodi fisici e fino a un massimo di 16 nodi:

  • Ogni nodo è un server fisico che esegue il sistema operativo Azure Stack HCI.

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

  • L'archiviazione usa le due porte della scheda di rete con supporto per RDMA dedicate che si connettono con un percorso a ognuno dei due commutatori ToR. Questo approccio offre ridondanza del percorso di collegamento e larghezza di banda dedicata con priorità per il traffico di archiviazione diretta SMB.

  • La gestione e il calcolo usano due porte della scheda di rete che forniscono un percorso a ognuno dei due commutatori ToR per la ridondanza del percorso di collegamento.

• Connettività esterna:

  • I commutatori Dual ToR si connettono alla rete esterna, ad esempio la LAN aziendale interna, per fornire l'accesso agli URL in uscita necessari usando il dispositivo di rete perimetrale. Questo dispositivo può essere un firewall o un router. Questi commutatori instradano il traffico in uscita e in uscita dal cluster Azure Stack HCI o dal traffico nord-sud.

  • La connettività esterna del traffico nord-sud supporta la finalità di gestione del cluster e le finalità di calcolo. A tale scopo, è possibile usare due porte switch e due porte della scheda di rete per nodo convergenti tramite il raggruppamento incorporato del commutatore (SET) e un commutatore virtuale all'interno di Hyper-V per garantire la resilienza. Questi componenti funzionano per fornire connettività esterna per le macchine virtuali di Azure Arc e altre risorse del carico di lavoro distribuite all'interno delle reti logiche create in Resource Manager usando modelli portale di Azure, interfaccia della riga di comando o IaC.

Topologia di rete logica

La topologia di rete logica mostra una panoramica del flusso dei dati di rete tra i dispositivi, indipendentemente dalle connessioni fisiche.

Di seguito è riportato un riepilogo della configurazione logica per questa architettura di base per il commutatore di archiviazione multinodo per Azure Stack HCI:

• Commutatori Dual ToR:

  • Prima di distribuire il cluster, è necessario configurare i due commutatori di rete ToR con gli ID VLAN necessari, le impostazioni massime delle unità di trasmissione e la configurazione del bridging dei data center per le porte di gestione, calcolo e archiviazione. Per altre informazioni, vedere Requisiti di rete fisici per Azure Stack HCI o chiedere al fornitore dell'hardware del commutatore o al partner SI per assistenza.

• Azure Stack HCI usa l'approccio Network ATC per applicare l'automazione di rete e la configurazione di rete basata sulle finalità.

  • 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 della 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 del team SET convergente, 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 un team SET per le finalità di calcolo e gestione.

• Traffico di archiviazione:

  • I nodi fisici comunicano tra loro usando due porte di scheda di rete dedicate connesse ai commutatori ToR per fornire larghezza di banda elevata e resilienza per il traffico di archiviazione.

  • Le porte di archiviazione SMB1 e SMB2 si connettono a due reti nonroutable separate (o di livello 2). Ogni rete ha un ID VLAN specifico configurato che deve corrispondere alla configurazione delle porte del commutatore negli ID VLAN di archiviazione predefiniti dei commutatori ToR: 711 e 712.

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

  • Ogni nodo può accedere Spazi di archiviazione diretta funzionalità 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 RDMA SMB-Direct sulle due porte della scheda di rete di archiviazione dedicate disponibili in ogni nodo. SMB multicanale viene usato per la resilienza.

  • Questa configurazione offre 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.

Requisiti del commutatore di rete

I commutatori Ethernet devono soddisfare le diverse specifiche richieste da Azure Stack HCI e impostate dall'Institute of Electrical and Electronics Engineers Standards Association (IEEE SA). Ad esempio, per le distribuzioni a più nodi di archiviazione, la rete di archiviazione viene usata per RDMA tramite RoCE v2 o iWARP. Questo processo richiede IEEE 802.1Qbb PFC per garantire la comunicazione senza perdita per la classe di traffico di archiviazione. Le opzioni ToR devono fornire supporto per IEEE 802.1Q per VLAN e IEEE 802.1AB per il protocollo di individuazione dei livelli di collegamento.

Se si prevede di usare commutatori di rete esistenti per una distribuzione di Azure Stack HCI, esaminare l'elenco degli standard IEEE obbligatori e delle specifiche che devono essere forniti dai commutatori di rete e dalla configurazione. Quando si acquistano nuovi commutatori di rete, contattare il fornitore del commutatore per assicurarsi che i dispositivi soddisfino i requisiti di specifica IEEE di Azure Stack HCI o esaminare l'elenco dei modelli di commutatori certificati dal fornitore hardware che supportano i requisiti di rete di Azure Stack HCI.

Requisiti degli indirizzi IP

In una distribuzione a più nodi di archiviazione cambiata, il numero di indirizzi IP necessari aumenta con l'aggiunta di ogni nodo fisico, fino a un massimo di 16 nodi all'interno di un singolo cluster. Ad esempio, per distribuire una configurazione di archiviazione a due nodi di Azure Stack HCI, l'infrastruttura del cluster richiede almeno 11 x indirizzi IP da allocare. Se si usano microsegmentazioni o reti software-defined, sono necessari più indirizzi IP. Per altre informazioni, vedere Esaminare i requisiti degli indirizzi IP del modello di riferimento per l'archiviazione a due 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 distribuire il servizio Azure Kubernetes in Azure Stack HCI, vedere Servizio Azure Kubernetes abilitato dai requisiti di rete di Azure Arc.

Monitoraggio

Per migliorare il monitoraggio e gli avvisi, abilitare Monitor Insights in Azure Stack HCI. Le informazioni dettagliate possono essere ridimensionate per monitorare e gestire più cluster locali usando un'esperienza coerente con Azure. Insights usa contatori delle prestazioni del cluster e canali del log eventi per monitorare le principali funzionalità di Azure Stack HCI. I log vengono raccolti dal Registro Azure Container configurato tramite Monitoraggio e Log Analytics.

Azure Stack HCI Insights viene creato usando Monitoraggio e Log Analytics, che garantisce una soluzione sempre aggiornata e scalabile altamente personalizzabile. Insights fornisce l'accesso alle cartelle di lavoro predefinite con metriche di base, insieme alle cartelle di lavoro specializzate create per il monitoraggio delle funzionalità chiave di Azure Stack HCI. Questi componenti forniscono una soluzione di monitoraggio quasi in tempo reale e consentono la creazione di grafici, la personalizzazione delle visualizzazioni tramite aggregazione e filtro e la configurazione delle regole di avviso di integrità delle risorse personalizzate.

Gestione aggiornamenti

È necessario aggiornare e applicare regolarmente patch ai cluster Azure Stack HCI e alle risorse del carico di lavoro distribuite, ad esempio le macchine virtuali di Azure Arc. Applicando regolarmente gli aggiornamenti, si garantisce che l'organizzazione mantenga un comportamento di sicurezza forte e si migliori l'affidabilità e il supporto complessivi del patrimonio. È consigliabile usare valutazioni manuali automatiche e periodiche per l'individuazione anticipata e l'applicazione di patch di sicurezza e aggiornamenti del sistema operativo.

Aggiornamenti dell'infrastruttura

Azure Stack HCI viene costantemente aggiornato per migliorare l'esperienza del cliente e aggiungere nuove funzionalità e funzionalità. Questo processo viene gestito tramite i training delle versioni, che offrono nuove build di base trimestrali. Le build di base vengono applicate ai cluster Azure Stack HCI per mantenerle aggiornate. Oltre agli aggiornamenti regolari della build di base, Azure Stack HCI viene aggiornato con aggiornamenti mensili della sicurezza e dell'affidabilità del sistema operativo.

Gestione aggiornamenti è un servizio di Azure che è possibile usare per applicare, visualizzare e gestire gli aggiornamenti per Azure Stack HCI. Questo servizio fornisce un meccanismo per visualizzare tutti i cluster Azure Stack HCI nell'intera infrastruttura e nei percorsi perimetrali usando il portale di Azure per offrire un'esperienza di gestione centralizzata. Per ulteriori informazioni, vedi le seguenti risorse:

• Informazioni sulla versione di Azure Stack HCI

• Frequenza del ciclo di vita di Azure Stack HCI

• Esaminare le fasi di aggiornamento di Azure Stack HCI

• Usare Azure Update Manager per aggiornare Azure Stack HCI

È importante verificare regolarmente la disponibilità di nuovi aggiornamenti del driver e del firmware, ad esempio ogni tre-sei mesi. Se si usa una versione della categoria di soluzioni Premier per l'hardware azure Stack HCI, gli aggiornamenti del pacchetto dell'estensione Solution Builder sono integrati con Gestione aggiornamenti per offrire un'esperienza di aggiornamento semplificata. Se si usano nodi convalidati o una categoria di sistema integrata, potrebbe essere necessario scaricare ed eseguire un pacchetto di aggiornamento specifico dell'OEM che contiene gli aggiornamenti del firmware e dei driver per l'hardware. Per determinare la modalità di fornitura degli aggiornamenti per l'hardware, contattare l'OEM hardware o il partner SI.

Applicazione di patch al sistema operativo guest del carico di lavoro

È possibile registrare macchine virtuali di Azure Arc distribuite in Azure Stack HCI usando Azure Update Manager (AUM) per offrire un'esperienza unificata di gestione delle patch usando lo stesso meccanismo usato per aggiornare i nodi fisici del cluster Azure Stack HCI. È possibile usare la messaggistica unificata per creare configurazioni di manutenzione guest. Queste configurazioni controllano le impostazioni, ad esempio il riavvio dell'impostazione di riavvio, se necessario, la pianificazione (date, ore e le opzioni di ripetizione) e un elenco dinamico (sottoscrizione) o statico delle macchine virtuali di Azure Arc per l'ambito. Queste impostazioni controllano la configurazione per quando le patch di sicurezza del sistema operativo vengono installate all'interno del sistema operativo guest della macchina virtuale del carico di lavoro.

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.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

Identificare i potenziali punti di errore

Ogni architettura è soggetta a errori. È possibile prevedere gli errori ed essere preparati con le mitigazioni con l'analisi della modalità di errore. La tabella seguente descrive quattro esempi di potenziali punti di errore in questa architettura:

Per altre informazioni, vedere Raccomandazioni per l'esecuzione dell'analisi della modalità di errore.

Obiettivi di affidabilità

Questa sezione descrive uno scenario di esempio. Un cliente fittizio denominato Contoso Manufacturing usa questa architettura di riferimento per distribuire Azure Stack HCI. Vogliono soddisfare i requisiti e distribuire e gestire i carichi di lavoro in locale. Contoso Manufacturing ha un obiettivo interno del livello di servizio (SLO) del 99,8% che gli stakeholder aziendali e delle applicazioni sono d'accordo per i propri servizi.

• Un SLO del 99,8% di tempo di attività o disponibilità comporta i seguenti periodi di inattività consentiti o indisponibilità per le applicazioni distribuite usando macchine virtuali Di Azure Arc in esecuzione in Azure Stack HCI:

  • Settimanale: 20 minuti e 10 secondi

  • Mensile: 1 ora, 26 minuti e 56 secondi

  • Trimestrale: 4 ore, 20 minuti e 49 secondi

  • Annuale: 17 ore, 23 minuti e 16 secondi

• Per soddisfare le destinazioni SLO, Contoso Manufacturing implementa il principio dei privilegi minimi (PoLP) per limitare il numero di amministratori del cluster Azure Stack HCI a un piccolo gruppo di utenti attendibili e qualificati. Questo approccio consente di evitare tempi di inattività dovuti a eventuali azioni accidentali o accidentali eseguite sulle risorse di produzione. Inoltre, i registri eventi di sicurezza per i controller di dominio di Active Directory locale Domain Services (AD DS) vengono monitorati per rilevare e segnalare eventuali modifiche all'appartenenza ai gruppi di account utente, note come azioni di aggiunta e rimozione, per il gruppo di amministratori del cluster Azure Stack HCI usando una soluzione siem (Security Information Event Management). Il monitoraggio aumenta l'affidabilità e migliora la sicurezza della soluzione.

  Per altre informazioni, vedere Raccomandazioni per la gestione delle identità e degli accessi.

• Per i sistemi di produzione di Contoso Manufacturing sono state applicate procedure rigorose di controllo delle modifiche. Questo processo richiede che tutte le modifiche vengano testate e convalidate in un ambiente di test rappresentativo prima dell'implementazione nell'ambiente di produzione. Tutte le modifiche inviate al processo consultivo delle modifiche settimanali devono includere un piano di implementazione dettagliato (o un collegamento al codice sorgente), un punteggio del livello di rischio, un piano di rollback completo, test e verifica post-rilascio e criteri chiari per la revisione o l'approvazione di una modifica.

  Per altre informazioni, vedere Raccomandazioni per procedure di distribuzione sicure.

• Le patch di sicurezza mensili e gli aggiornamenti di base trimestrali vengono applicati ai cluster Azure Stack HCI di produzione solo dopo la convalida dell'ambiente di preproduzione. Gestione aggiornamenti e la funzionalità di aggiornamento compatibile con il cluster automatizzano il processo di uso della migrazione in tempo reale delle macchine virtuali per ridurre al minimo i tempi di inattività per i carichi di lavoro critici per l'azienda durante le operazioni di manutenzione mensile. Le procedure operative standard di Contoso Manufacturing richiedono che gli aggiornamenti della sicurezza, dell'affidabilità o della build di base vengano applicati a tutti i sistemi di produzione entro quattro settimane dalla data di rilascio. Senza questo criterio, i sistemi di produzione non sono in grado di rimanere aggiornati con gli aggiornamenti mensili del sistema operativo e della sicurezza. I sistemi non aggiornati influiscono negativamente sull'affidabilità e sulla sicurezza della piattaforma.

  Per altre informazioni, vedere Raccomandazioni per la definizione di una baseline di sicurezza.

• Contoso Manufacturing implementa backup giornalieri, settimanali e mensili per conservare gli ultimi 6 x giorni di backup giornalieri (da lunedì a sabato), gli ultimi 3 x settimanali (ogni domenica) e 3 x backup mensili, con ogni settimana domenica 4 che viene mantenuta per diventare il backup mensile 1, mese 2 e mese 3 usando una pianificazione basata su calendario in sequenza documentata e controllabile. Questo approccio soddisfa i requisiti di produzione di Contoso per un equilibrio adeguato tra il numero di punti di ripristino dei dati disponibili e la riduzione dei costi per il servizio di archiviazione di backup fuori sede o cloud.

  Per altre informazioni, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.

• I processi di backup e ripristino dei dati vengono testati per ogni sistema aziendale ogni sei mesi. Questa strategia garantisce che i processi BCDR siano validi e che l'azienda sia protetta se si verifica un'emergenza del data center o un evento informatico.

  Per altre informazioni, vedere Raccomandazioni per la progettazione di una strategia di test di affidabilità.

• I processi operativi e le procedure descritti in precedenza nell'articolo e le raccomandazioni contenute nella Guida al servizio Well-Architected Framework per Azure Stack HCI consentono a Contoso Manufacturing di soddisfare la destinazione SLO del 99,8% e di ridimensionare e gestire in modo efficace le distribuzioni di Azure Stack HCI e dei carichi di lavoro in più siti di produzione distribuiti in tutto il mondo.

  Per altre informazioni, vedere Raccomandazioni per la definizione degli obiettivi di affidabilità.

Ridondanza

Si consideri un carico di lavoro distribuito in un singolo cluster Azure Stack HCI come distribuzione con ridondanza locale. Il cluster offre disponibilità elevata a livello di piattaforma, ma è necessario distribuire il cluster in un singolo rack. Per i casi d'uso critici per l'azienda o cruciali, è consigliabile distribuire più istanze di un carico di lavoro o di un servizio in due o più cluster Azure Stack HCI separati, idealmente in posizioni fisiche separate.

Usare modelli di disponibilità elevata standard del settore per carichi di lavoro che forniscono la replica attiva/passiva, la replica sincrona o la replica asincrona, ad esempio SQL Server Always On. È anche possibile usare una tecnologia di bilanciamento del carico di rete esterna che instrada le richieste degli utenti tra più istanze del carico di lavoro eseguite nei cluster Azure Stack HCI distribuiti in posizioni fisiche separate. Prendere in considerazione l'uso di un dispositivo di bilanciamento carico di rete esterno del partner. In alternativa, è possibile valutare le opzioni di bilanciamento del carico che supportano il routing del traffico per i servizi ibridi e locali, ad esempio un'istanza del gateway di app Azure lication che usa Azure ExpressRoute o un tunnel VPN per connettersi a un servizio locale.

Per altre informazioni, vedere Raccomandazioni per la progettazione per la ridondanza.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Le considerazioni sulla sicurezza includono:

• Una base sicura per la piattaforma Azure Stack HCI: Azure Stack HCI è un prodotto sicuro per impostazione predefinita che usa componenti hardware convalidati con un TPM, UEFI e avvio protetto per creare una base sicura per la piattaforma Azure Stack HCI e la sicurezza dei carichi di lavoro. Quando viene distribuita con le impostazioni di sicurezza predefinite, Azure Stack HCI ha Controllo applicazioni di Windows Defender, Credential Guard e BitLocker abilitato. Per semplificare la delega delle autorizzazioni tramite poLP, usare i ruoli di controllo degli accessi in base al ruolo (RBAC) predefiniti di Azure Stack HCI, ad esempio l'amministratore di Azure Stack HCI per gli amministratori della piattaforma e il collaboratore della macchina virtuale Azure Stack HCI o il lettore di macchine virtuali Di Azure Stack HCI per gli operatori del carico di lavoro.

• Impostazioni di sicurezza predefinite: l'impostazione predefinita di sicurezza di Azure Stack HCI applica le impostazioni di sicurezza predefinite per il cluster Azure Stack HCI durante la distribuzione e consente il controllo della deriva per mantenere i nodi in uno stato valido noto. È possibile usare le impostazioni predefinite di sicurezza per gestire la sicurezza del cluster, il controllo della deriva e le impostazioni del server di base protette nel cluster.

• Log eventi di sicurezza: l'inoltro syslog di Azure Stack HCI si integra con soluzioni di monitoraggio della sicurezza recuperando i log eventi di sicurezza pertinenti per aggregare e archiviare gli eventi per la conservazione nella propria piattaforma SIEM.

• Protezione da minacce e vulnerabilità: Defender per il cloud protegge i cluster Azure Stack HCI da varie minacce e vulnerabilità. Questo servizio consente di migliorare il comportamento di sicurezza dell'ambiente Azure Stack HCI e di proteggersi da minacce esistenti e in continua evoluzione.

• Rilevamento e correzione delle minacce: Microsoft Advanced Threat Analytics rileva e corregge le minacce, ad esempio quelle destinate ad Active Directory Domain Services, che forniscono servizi di autenticazione ai nodi del cluster Azure Stack HCI e ai carichi di lavoro delle macchine virtuali Windows Server.

• Isolamento rete: isolare le reti, se necessario. Ad esempio, è possibile effettuare il provisioning di più reti logiche che usano VLAN separate e intervalli di indirizzi di rete. Quando si usa questo approccio, assicurarsi che la rete di gestione possa raggiungere ogni rete logica e VLAN in modo che i nodi del cluster Azure Stack HCI possano comunicare con le reti VLAN tramite commutatori o gateway ToR. Questa configurazione è necessaria per la gestione del carico di lavoro, ad esempio per consentire agli agenti di gestione dell'infrastruttura di comunicare con il sistema operativo guest del carico di lavoro.

  Per altre informazioni, vedere Raccomandazioni per la creazione di una strategia di segmentazione.

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:

• Modello di fatturazione in stile cloud per le licenze: i prezzi di Azure Stack HCI seguono il modello di fatturazione della sottoscrizione mensile con una tariffa fissa per ogni core del processore fisico in un cluster Azure Stack HCI. Gli addebiti per l'utilizzo aggiuntivo si applicano se si usano altri servizi di Azure. Se si possiedono licenze di base locali per Windows Server Datacenter Edition con Software Assurance attivo, è possibile scegliere di scambiare queste licenze per attivare i costi di sottoscrizione del cluster Azure Stack HCI e delle macchine virtuali Windows Server.

• Applicazione automatica di patch guest alle macchine virtuali di Azure Arc: questa funzionalità consente di ridurre il sovraccarico dell'applicazione manuale delle patch e dei costi di manutenzione associati. Questa azione non solo consente di rendere il sistema più sicuro, ma ottimizza anche l'allocazione delle risorse e contribuisce all'efficienza complessiva dei costi.

• Consolidamento del monitoraggio dei costi: per consolidare i costi di monitoraggio, usare Azure Stack HCI Insights e applicare patch con Gestione aggiornamenti per Azure Stack HCI. Insights usa Monitoraggio per fornire metriche avanzate e funzionalità di avviso. Il componente lifecycle manager di Azure Stack HCI si integra con Gestione aggiornamenti per semplificare l'attività di mantenere aggiornati i cluster consolidando i flussi di lavoro di aggiornamento per vari componenti in un'unica esperienza. Usare Monitoraggio e Gestione aggiornamenti per ottimizzare l'allocazione delle risorse e contribuire all'efficienza complessiva dei costi.

  Per altre informazioni, vedere Raccomandazioni per l'ottimizzazione del tempo del personale.

• Capacità e crescita iniziale del carico di lavoro: quando si pianifica la distribuzione di Azure Stack HCI, prendere in considerazione la capacità iniziale del carico di lavoro, i requisiti di resilienza e le future considerazioni sulla crescita. Valutare se l'uso di un'architettura senza commutatori di archiviazione a due o tre nodi potrebbe ridurre i costi, ad esempio la rimozione della necessità di acquistare commutatori di rete di classe di archiviazione. L'acquisizione di commutatori di rete di classi di archiviazione aggiuntive può essere un componente costoso delle nuove distribuzioni di cluster Azure Stack HCI. È invece possibile usare commutatori esistenti per le reti di gestione e calcolo, semplificando l'infrastruttura. Se le esigenze di capacità e resilienza del carico di lavoro non superano una configurazione a tre nodi, valutare se è possibile usare commutatori esistenti per le reti di gestione e calcolo e usare l'architettura senza commutatori di archiviazione a tre nodi per distribuire Azure Stack HCI.

  Per altre informazioni, vedere Raccomandazioni per l'ottimizzazione dei costi dei componenti.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

Le considerazioni sull'eccellenza operativa includono:

• Esperienza semplificata di provisioning e gestione integrata con Azure: la distribuzione basata sul cloud in Azure offre un'interfaccia guidata che illustra come creare un cluster Azure Stack HCI. Analogamente, Azure semplifica il processo di gestione dei cluster Azure Stack HCI e delle macchine virtuali di Azure Arc. È possibile automatizzare la distribuzione basata sul portale del cluster Azure Stack HCI usando il modello di Resource Manager. Questo modello offre coerenza e automazione per distribuire Azure Stack HCI su larga scala, in particolare in scenari perimetrali, ad esempio punti vendita al dettaglio o siti di produzione che richiedono un cluster Azure Stack HCI per eseguire carichi di lavoro business critical.

• Funzionalità di automazione per Macchine virtuali: Azure Stack HCI offre un'ampia gamma di funzionalità di automazione per la gestione dei carichi di lavoro, ad esempio le macchine virtuali Di Azure Arc, con la distribuzione automatizzata delle macchine virtuali di Azure Arc usando il modello dell'interfaccia della riga di comando di Azure, ARM o Bicep, con gli aggiornamenti del sistema operativo delle macchine virtuali con l'estensione Azure Arc per gli aggiornamenti e Azure Update Manager per aggiornare ogni cluster Azure Stack HCI. Azure Stack HCI offre anche il supporto per la gestione delle macchine virtuali di Azure Arc usando l'interfaccia della riga di comando di Azure e le macchine virtuali non Azure Arc usando Windows PowerShell. È possibile eseguire i comandi dell'interfaccia della riga di comando di Azure in locale da uno dei server Azure Stack HCI o in remoto da un computer di gestione. L'integrazione con Automazione di Azure e Azure Arc facilita un'ampia gamma di scenari di automazione aggiuntivi per i carichi di lavoro delle macchine virtuali tramite le estensioni di Azure Arc.

  Per altre informazioni, vedere Raccomandazioni per l'uso di IaC.

• Funzionalità di automazione per i contenitori nel servizio Azure Kubernetes: Azure Stack HCI offre un'ampia gamma di funzionalità di automazione per la gestione dei carichi di lavoro, ad esempio i contenitori, nel servizio Azure Kubernetes. È possibile automatizzare la distribuzione dei cluster del servizio Azure Kubernetes usando l'interfaccia della riga di comando di Azure. Aggiornare i cluster del carico di lavoro del servizio Azure Kubernetes usando l'estensione Azure Arc per gli aggiornamenti di Kubernetes. È anche possibile gestire il servizio Azure Kubernetes abilitato per Azure Arc usando l'interfaccia della riga di comando di Azure. È possibile eseguire i comandi dell'interfaccia della riga di comando di Azure in locale da uno dei server Azure Stack HCI o in remoto da un computer di gestione. Eseguire l'integrazione con Azure Arc per un'ampia gamma di scenari di automazione aggiuntivi per carichi di lavoro in contenitori tramite le estensioni di Azure Arc.

  Per altre informazioni, vedere Raccomandazioni per l'abilitazione dell'automazione.

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:

• Prestazioni di archiviazione del carico di lavoro: prendere in considerazione l'uso dello strumento DiskSpd per testare le funzionalità di archiviazione del carico di lavoro di un cluster Azure Stack HCI. È possibile usare lo strumento VMFleet per generare il carico e misurare le prestazioni di un sottosistema di archiviazione. Valutare se è necessario usare VMFleet per misurare le prestazioni del sottosistema di archiviazione.

  • È consigliabile stabilire una baseline per le prestazioni dei cluster Azure Stack HCI prima di distribuire i carichi di lavoro di produzione. DiskSpd usa vari parametri della riga di comando che consentono agli amministratori di testare le prestazioni di archiviazione del cluster. La funzione principale di DiskSpd consiste nel rilasciare operazioni di lettura e scrittura e metriche delle prestazioni di output, ad esempio latenza, velocità effettiva e operazioni di I/O.

    Per altre informazioni, vedere Raccomandazioni per i test delle prestazioni.

• Resilienza dell'archiviazione del carico di lavoro: considerare i vantaggi dell'efficienza dell'archiviazione, dell'utilizzo (o della capacità) e delle prestazioni. La pianificazione dei volumi di Azure Stack HCI include l'identificazione dell'equilibrio ottimale tra resilienza, efficienza di utilizzo e prestazioni. Potrebbe risultare difficile ottimizzare questo equilibrio perché massimizzare una di queste caratteristiche in genere ha un effetto negativo su una o più delle altre caratteristiche. L'aumento della resilienza riduce la capacità utilizzabile. Di conseguenza, le prestazioni possono variare, a seconda del tipo di resilienza selezionato. Quando la resilienza e le prestazioni sono prioritarie e quando si usano tre o più nodi, la configurazione di archiviazione predefinita usa il mirroring a tre vie sia per l'infrastruttura che per i volumi utente.

  Per altre informazioni, vedere Raccomandazioni per la pianificazione della capacità.

• Ottimizzazione delle prestazioni di rete: prendere in considerazione l'ottimizzazione delle prestazioni di rete. Come parte della progettazione, assicurarsi di includere l'allocazione della larghezza di banda del traffico di rete proiettata quando si determina la configurazione hardware di rete ottimale.

  • Per ottimizzare le prestazioni di calcolo in Azure Stack HCI, è possibile usare l'accelerazione GPU. L'accelerazione GPU è utile per carichi di lavoro di intelligenza artificiale a prestazioni elevate o di Machine Learning che comportano informazioni dettagliate sui dati o inferenza. Questi carichi di lavoro richiedono la distribuzione in posizioni perimetrali a causa di considerazioni come la gravità dei dati o i requisiti di sicurezza. In una distribuzione ibrida o in una distribuzione locale, è importante prendere in considerazione i requisiti di prestazioni del carico di lavoro, incluse le GPU. Questo approccio consente di selezionare i servizi corretti quando si progettano e si acquistano i cluster Azure Stack HCI.

    Per altre informazioni, vedere Raccomandazioni per la selezione dei servizi corretti.

Distribuire lo scenario

La sezione seguente fornisce un elenco di esempio delle attività di alto livello o del flusso di lavoro tipico usato per distribuire Azure Stack HCI, incluse le attività e le considerazioni sui prerequisiti. Questo elenco di flussi di lavoro è destinato solo a una guida di esempio. Non è un elenco completo di tutte le azioni necessarie, che possono variare in base ai requisiti aziendali, geografici o specifici del progetto.

Scenario: è necessario un progetto o un caso d'uso per distribuire una soluzione cloud ibrida in una posizione locale o perimetrale per fornire risorse di calcolo locali per le funzionalità di elaborazione dei dati e il desiderio di usare esperienze di gestione e fatturazione coerenti con Azure. Altri dettagli sono descritti nella sezione dei potenziali casi d'uso di questo articolo. I passaggi rimanenti presuppongono che Azure Stack HCI sia la soluzione di piattaforma dell'infrastruttura scelta per il progetto.

1. Raccogliere i requisiti del carico di lavoro e dei casi d'uso dagli stakeholder pertinenti. Questa strategia consente al progetto di verificare che le funzionalità e le funzionalità di Azure Stack HCI soddisfino i requisiti di scalabilità, prestazioni e funzionalità del carico di lavoro. Questo processo di revisione deve includere informazioni sulla scalabilità o sulle dimensioni del carico di lavoro e le funzionalità necessarie, ad esempio macchine virtuali Di Azure Arc, servizio Azure Kubernetes, Desktop virtuale Azure o Servizi dati abilitati per Azure Arc o il servizio Machine Learning abilitato per Azure Arc. I valori RTO e RPO (reliability) del carico di lavoro e altri requisiti non funzionali (scalabilità delle prestazioni/carico) devono essere documentati come parte di questo passaggio di raccolta dei requisiti.

2. Esaminare l'output del sizer di Azure Stack HCI per la soluzione partner hardware consigliata. Questo output include i dettagli del modello e dell'hardware del server fisico consigliati, il numero di nodi fisici e le specifiche per la configurazione della CPU, della memoria e dell'archiviazione di ogni nodo fisico necessario per distribuire ed eseguire i carichi di lavoro.

3. Usare lo strumento di ridimensionamento di Azure Stack HCI per creare un nuovo progetto che modella il tipo di carico di lavoro e la scalabilità. Questo progetto include le dimensioni e il numero di macchine virtuali e i relativi requisiti di archiviazione. Questi dettagli vengono inseriti insieme alle scelte per il tipo di sistema, la famiglia di CPU preferita e i requisiti di resilienza per la disponibilità elevata e la tolleranza di errore di archiviazione, come illustrato nella sezione Opzioni di progettazione del cluster precedente.

4. Esaminare l'output di Azure Stack HCI Sizer per la soluzione partner hardware consigliata. Questa soluzione include i dettagli dell'hardware del server fisico consigliato (make and model), il numero di nodi fisici e le specifiche per la configurazione della CPU, della memoria e dell'archiviazione di ogni nodo fisico necessario per distribuire ed eseguire i carichi di lavoro.

5. Contattare l'OEM hardware o il partner SI per qualificare ulteriormente l'idoneità della versione hardware consigliata rispetto ai requisiti del carico di lavoro. Se disponibile, usare strumenti di dimensionamento specifici dell'OEM per determinare i requisiti di dimensionamento hardware specifici dell'OEM per i carichi di lavoro previsti. Questo passaggio include in genere discussioni con l'OEM hardware o il partner SI per gli aspetti commerciali della soluzione. Questi aspetti includono offerte, disponibilità dell'hardware, lead time e qualsiasi servizio professionale o di valore aggiunto fornito dal partner per accelerare il progetto o i risultati aziendali.

6. Distribuire due commutatori ToR per l'integrazione di rete. Per le soluzioni a disponibilità elevata, i cluster HCI richiedono la distribuzione di due commutatori ToR. Ogni nodo fisico richiede quattro schede di interfaccia di rete, due delle quali devono essere in grado di supportare RDMA, che fornisce due collegamenti da ogni nodo ai due commutatori ToR. Due schede di interfaccia di rete, una connessa a ogni commutatore, sono convergenti per la connettività nord-sud in uscita per le reti di calcolo e gestione. Le altre due schede di interfaccia di rete che supportano RDMA sono dedicate per il traffico di archiviazione east-west. Se si prevede di usare i commutatori di rete esistenti, assicurarsi che il make e il modello dei commutatori siano nell'elenco approvato dei commutatori di rete supportati da Azure Stack HCI.

7. Collaborare con l'OEM hardware o il partner SI per organizzare la distribuzione dell'hardware. Il partner SI o i dipendenti devono quindi integrare l'hardware nel data center locale o nella posizione perimetrale, ad esempio rack e stacking dell'hardware, della rete fisica e del cablaggio dell'unità di alimentazione per i nodi fisici.

8. Eseguire la distribuzione del cluster Azure Stack HCI. A seconda della versione della soluzione scelta (soluzione Premier, sistema integrato o nodi convalidati), il partner hardware, il partner SI o i dipendenti possono distribuire il software Azure Stack HCI. Questo passaggio inizia eseguendo l'onboarding dei nodi fisici del sistema operativo Azure Stack HCI nei server abilitati per Azure Arc, quindi avviando il processo di distribuzione cloud di Azure Stack HCI. I clienti e i partner possono generare una richiesta di supporto direttamente con Microsoft nel portale di Azure selezionando l'icona Supporto e risoluzione dei problemi oppure contattando il partner OEM o SI hardware, a seconda della natura della richiesta e della categoria della soluzione hardware.

   Suggerimento

   L'implementazione di riferimento del cluster Azure Stack HCI 23H2 illustra come distribuire una distribuzione multiserver cambiata di Azure Stack HCI usando un modello arm e un file di parametri. In alternativa, l'esempio Bicep illustra come usare un modello Bicep per distribuire un cluster Azure Stack HCI, incluse le risorse dei prerequisiti.

9. Distribuire carichi di lavoro a disponibilità elevata in Azure Stack HCI usando portale di Azure, l'interfaccia della riga di comando o i modelli arm + Azure Arc per l'automazione. Usare la risorsa percorso personalizzata del nuovo cluster HCI come area di destinazione quando si distribuiscono risorse del carico di lavoro, ad esempio macchine virtuali di Azure Arc, servizio Azure Kubernetes , host di sessione di Desktop virtuale Azure o altri servizi abilitati per Azure Arc che è possibile abilitare tramite estensioni del servizio Azure Kubernetes e containerizzazione in Azure Stack HCI.

10. Installare gli aggiornamenti mensili per migliorare la sicurezza e l'affidabilità della piattaforma. Per mantenere aggiornati i cluster Azure Stack HCI, è importante installare gli aggiornamenti software Microsoft e gli aggiornamenti del firmware OEM hardware. Questi aggiornamenti migliorano la sicurezza e l'affidabilità della piattaforma. Gestione aggiornamenti applica gli aggiornamenti e fornisce una soluzione centralizzata e scalabile per installare gli aggiornamenti in un singolo cluster o in più cluster. Rivolgersi al partner OEM hardware per determinare il processo di installazione degli aggiornamenti del driver hardware e del firmware perché questo processo può variare a seconda del tipo di categoria di soluzione hardware scelto (soluzione Premier, sistema integrato o nodi convalidati). Per altre informazioni, vedere Aggiornamenti dell'infrastruttura.

Risorse correlate

• Design dell'architettura ibrida
• Opzioni ibride di Azure
• Automazione 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 del monitoraggio
• Panoramica del rilevamento delle modifiche e dell'inventario
• Panoramica di Gestione aggiornamenti
• Che cosa sono i servizi dati abilitati per Azure Arc?
• Che cosa sono i server abilitati per Azure Arc?
• Che cos'è il servizio Backup?

Documentazione del prodotto per informazioni dettagliate su servizi di Azure specifici:

• Azure Stack HCI
• Azure Arc
• Insieme di credenziali delle chiavi di
• Archiviazione BLOB di Azure
• Monitoraggio
• Criteri di Azure
• Registro Azure Container
• Defender for Cloud
• 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 Machine Learning ovunque - Blog della community tecnica
• Creazione di Machine Learning ovunque con il servizio Azure Kubernetes e Il Machine Learning abilitato per Azure 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
• Introduzione alla destinazione di calcolo Kubernetes in Machine Learning
• Mantenere aggiornate le macchine virtuali
• Proteggere le impostazioni della macchina virtuale con la configurazione dello stato di Automazione
• Proteggere le macchine virtuali usando Backup