Architettura di riferimento della baseline locale di Azure

Questa architettura di riferimento di base fornisce indicazioni e consigli indipendenti dai carichi di lavoro per la configurazione di azure locale, versione 23H2, versione 2311 e successiva dell'infrastruttura 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 Locale.

Per altre informazioni sui modelli di architettura del carico di lavoro ottimizzati per l'esecuzione in Locale di Azure, vedere il contenuto disponibile nel menu di spostamento carichi di lavoro locali di Azure menu di spostamento.

Questa architettura è un punto di partenza per usare la progettazione della rete commutata di archiviazione per distribuire un'istanza locale di Azure multinodo. Le applicazioni del carico di lavoro distribuite in un'istanza locale di Azure 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 Well-Architected Framework locale di Azure .

Layout articolo

Architettura

Per altre informazioni, vedere Risorse correlate.

Casi d'uso potenziali

I casi d'uso tipici per l'ambiente locale di Azure 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. Si può:

• 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 il portale di Azure, l'interfaccia della riga di comando di Azure o i modelli di 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 Local viene distribuito con un comportamento di sicurezza con protezione avanzata configurato per impostazione predefinita oppure sicuro per impostazione predefinita. Azure Local 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 for 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 Locale di Azure.

Usare Azure Arc con Azure Local

Azure Local si integra direttamente con Azure usando Azure Arc per ridurre il costo totale di proprietà e il sovraccarico operativo. Azure Local viene distribuito e gestito tramite Azure, che fornisce 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 locale di Azure 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, Gestione dispositivi Microsoft Edge e Telemetria e Diagnostica. È possibile usare Monitoraggio di Azure e Log Analytics per monitorare il cluster HCI dopo la distribuzione abilitando Insights per azure locale. gli aggiornamenti delle funzionalità per i locali di Azure vengono rilasciati periodicamente per migliorare l'esperienza del cliente. Gli aggiornamenti vengono controllati e gestiti tramite Azure Update Manager.

È possibile distribuire risorse del carico di lavoro, ad esempio macchine virtuali (VM) di Azure Arc, servizio Azure Kubernetes abilitato per Azure Arce host sessione di Desktop virtuale Azure che usano il portale di Azure selezionando un percorso personalizzato percorso personalizzato dell'istanza locale di Azure 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 il vantaggio Azure Hybrid ai cluster locali di Azure, Windows Server e 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 per includere:

• macchine virtuali di Azure Arc per applicazioni o servizi tradizionali eseguiti nelle macchine virtuali in Locale di Azure.

• servizio Azure Kubernetes nei locali di Azure per applicazioni o servizi in contenitori che traggono vantaggio dall'uso di Kubernetes come piattaforma di orchestrazione.

• Desktop virtuale Azure distribuire gli host di sessione per i carichi di lavoro di Desktop virtuale Azure in Locale di Azure (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 di Database di Azure per PostgreSQL che usano il servizio Azure Arc abilitato per il servizio Azure Kubernetes ospitato in Locale di Azure.

• L'estensione griglia di eventi di Azure abilitata per Azure Arc per Kubernetes per distribuire i componenti 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 Locale di Azure 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 locali di Azure, ad esempio l'automazione della configurazione del sistema operativo guest con estensioni delle macchine virtuali 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 il portale di Azure o l'automazione IaC.

Sfruttare la configurazione di sicurezza predefinita locale di Azure

La configurazione di sicurezza predefinita locale di Azure 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 Local offre protezione avanzata predefinita e integrazione approfondita con i servizi di Azure per risolvere questi problemi.

L'hardware certificato locale di Azure garantisce l'avvio protetto predefinito, l'interfaccia UEFI (Unified Extensible Firmware Interface) e il supporto TPM. Usare queste tecnologie in combinazione con VBS 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 locali di Azure in Defender for Cloud per attivare l'analisi comportamentale basata sul cloud, il rilevamento e la correzione delle minacce, gli avvisi e la creazione di report. Gestire le macchine virtuali locali di Azure 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 istanze locali di Azure in posizioni locali o perimetrali. Per migliorare le funzionalità della piattaforma, Azure Local si integra con Azure Arc e altri servizi di Azure che forniscono risorse di supporto. Azure Locale 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:

• locale di Azure è una soluzione HCI (Hyperconverged Infrastructure) distribuita in locale o in posizioni perimetrali usando hardware server fisico e infrastruttura di rete. Azure Locale offre una piattaforma per distribuire e gestire carichi di lavoro virtualizzati, ad esempio macchine virtuali, cluster Kubernetes e altri servizi abilitati da Azure Arc. Le istanze locali di Azure possono essere ridimensionate 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 a località locali di Azure e altre località non 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.

• controllo cloud è una funzionalità di Archiviazione di Azure che funge da quorum del cluster di failover. I nodi del cluster locale di Azure usano questo quorum per il voto, garantendo la 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 del cloud locale di Azure.

• Gestione aggiornamenti è un servizio unificato progettato per gestire e gestire gli aggiornamenti per l'ambiente locale di Azure. È possibile usare Gestione aggiornamenti per gestire i carichi di lavoro distribuiti in Locale di Azure, 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 Insights per Azure Local per semplificare la creazione della regola di raccolta dati di Monitoraggio e abilitare rapidamente il monitoraggio delle istanze locali di Azure.

• 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 di 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 for 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. Il server di Backup di Azure viene usato per eseguire il backup delle macchine virtuali distribuite in Locale di Azure 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'istanza locale di Azure. 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 nell'istanza locale di Azure. 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.

  • capacity: il totale spazio di archiviazione utilizzabile necessario dopo la tolleranza di errore o copie, viene preso in considerazione. Questo numero è di circa 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 della piattaforma che determina le funzionalità di velocità effettiva di archiviazione per il carico di lavoro quando vengono moltiplicate per le dimensioni del blocco dell'applicazione.

Per progettare e pianificare una distribuzione locale di Azure, è consigliabile usare lo strumento di ridimensionamento locale di di Azure e creare un Nuovo di 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.

Lo strumento di ridimensionamento Preferenze sezione illustra le domande relative al tipo di sistema (Premier, Integrated System o Validated Node) e alle opzioni della famiglia di CPU. Consente anche di selezionare i requisiti di resilienza per il cluster. Assicurarsi 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 locale di Azure è 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 delle soluzioni locali di Azure. 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'istanza locale di Azure, 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à vengono 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. All-NVMe unità 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 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 lavoro della 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 progettazione e configurazione di Spazi di archiviazione diretta. A seconda dei requisiti del carico di lavoro locale di Azure e dei vincoli di budget, è possibile scegliere di ottimizzare le prestazioni, ottimizzare la capacitào implementare una configurazione di tipo di unità mista che bilancia le prestazioni e la capacità.

Spazi di archiviazione diretta offre un cache predefinita, persistente, in tempo reale, lettura, scrittura, lato server che ottimizza le prestazioni di archiviazione. La cache deve essere ridimensionata e configurata per supportare il working set di delle applicazioni e dei carichi di lavoro. I dischi virtuali diretti di Spazi di archiviazione o i volumi , vengono usati in combinazione con la cache in lettura in memoria (CSV) del cluster per migliorare le prestazioni Hyper-V, in particolare per l'accesso di input non memorizzato al disco rigido virtuale del carico di lavoro (VHD) o ai file VHDX (Virtual 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à viene chiamato 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'istanza locale di Azure 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 Local.

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). 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 locale di archiviazione multinodo 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 dall'istanza locale di Azure 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 set (Switch Embedded Teaming) 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 il portale di Azure, l'interfaccia della riga di comando o i modelli 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 commutata per l'archiviazione multinodo per Azure Local:

• 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 del data center per la gestione , di calcolo e porte di archiviazione. Per altre informazioni, vedere Requisiti di rete fisica per l'locale di Azure oppure richiedere assistenza al fornitore dell'hardware del commutatore o al partner SI.

• Azure Local usa l'approccio Network ATC per applicare l'automazione della 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 il traffico di rete finalità. Network ATC definisce quali porte della scheda di rete fisica vengono usate per le diverse finalità o tipi di traffico di rete, ad esempio per la gestione del cluster , il carico di lavoro di calcoloe le finalità di archiviazione 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 del cloud locale di Azure.

• 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 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 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 nei commutatori ToR ID VLAN di archiviazione predefiniti: 711 e 712.

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

  • Ogni nodo può accedere alle funzionalità di Spazi di archiviazione diretta 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 Local 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 locale di Azure, esaminare l'elenco di standard IEEE obbligatori e specifiche che i commutatori di rete e la configurazione devono fornire. Quando si acquistano nuovi commutatori di rete, esaminare l'elenco dei modelli di commutatori certificati dal fornitore hardware che supportano i requisiti di rete locale di Azure.

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 con cambio di archiviazione a due nodi di Azure locale, 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 dell'archiviazione a due nodi per l'locale di Azure.

Quando si progettano e si pianificano i requisiti degli indirizzi IP per Azure locale, ricordarsi 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 dell'istanza locale di Azure e dell'infrastruttura. Se si prevede di distribuire il servizio Azure Kubernetes in locale di Azure, vedere servizio Azure Kubernetes abilitato dai requisiti di rete di Azure Arc.

Monitoraggio

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

Insights per Azure Local viene creato usando Monitoraggio e Log Analytics, che garantisce una soluzione sempre up-to-date 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 Local. 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 alle istanze locali di Azure 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 Local 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 alle istanze locali di Azure per mantenerle aggiornate. Oltre agli aggiornamenti regolari della build di base, Azure Local 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 Locale. Questo servizio fornisce un meccanismo per visualizzare tutte le istanze locali di Azure nell'intera infrastruttura e nei percorsi perimetrali usando il portale di Azure per offrire un'esperienza di gestione centralizzata. Per altre informazioni, vedere le risorse seguenti:

• Informazioni sulla versione locale di Azure

• cadenza del ciclo di vita locale di Azure

• Esaminare le fasi di aggiornamento delle locali di Azure

• Usare Gestione aggiornamenti di Azure per aggiornare i locali di Azure

È 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 locale di Azure, gli aggiornamenti del pacchetto dell'estensione di 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 Locale di Azure 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 locale di Azure. È possibile usare la messaggistica unificata per creare configurazioni di manutenzione guest. Queste configurazioni controllano le impostazioni, ad esempio l'impostazione Riavvia riavvio, se necessario, la pianificazione (date, ore e 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, ovvero un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai 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 Recommendations for performing failure mode analysis.

Obiettivi di affidabilità

Questa sezione descrive uno scenario di esempio. Un cliente fittizio denominato Contoso Manufacturing usa questa architettura di riferimento per distribuire Azure Local. 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) di 99,8% che gli stakeholder aziendali e dell'applicazione sono d'accordo per i propri servizi.

• Un SLO di 99.8% tempo di attività o disponibilità comporta i periodi di inattività consentiti o di indisponibilità seguenti per le applicazioni distribuite usando macchine virtuali di Azure Arc eseguite in Locale di Azure:

  • 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 di istanze locali di Azure 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 Active Directory Domain Services (AD DS) locali vengono monitorati per rilevare e segnalare eventuali modifiche all'appartenenza al gruppo di account utente, note come aggiungere e rimuovere le azioni, per gli amministratori di istanze locali di Azure gruppo usando una soluzione SIEM (Security Information Event Management). Il monitoraggio aumenta l'affidabilità e migliora la sicurezza della soluzione.

  Per altre informazioni, vedere Recommendations for identity and access management.

• procedure di controllo delle modifiche rigorose sono disponibili per i sistemi di produzione di Contoso Manufacturing. 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 Recommendations for safe deployment practices.For more information, see Recommendations for safe deployment practices.

• patch di sicurezza mensili e gli aggiornamenti trimestrali delle baseline vengono applicati all'istanza locale di Azure 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 Recommendations for establishing a security baseline.

• Contoso Manufacturing implementa ogni giorno, i backup 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 essere conservati per diventare i backup del mese 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 Recommendations for designing a reliability testing strategy.

• I processi operativi e le procedure descritti in precedenza nell'articolo e le raccomandazioni riportate nella guida al servizio Well-Architected Framework per l'locale di Azure, consentire a Contoso Manufacturing di soddisfare la destinazione 99.8% obiettivo SLO ed eseguire in modo efficace la scalabilità e la gestione delle distribuzioni locali e dei carichi di lavoro di Azure in più siti di produzione distribuiti in tutto il mondo.

  Per altre informazioni, vedere Recommendations for defining reliability targets.

Ridondanza

Si consideri un carico di lavoro distribuito in una singola istanza locale di Azure 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ù istanze locali di Azure separate, 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 in istanze locali di Azure distribuite 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 applicazione di Azure che usa Azure ExpressRoute o un tunnel VPN per connettersi a un servizio locale.

Per altre informazioni, vedere Recommendations for designing for redundancy.

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 locale di Azure: locale di Azure è 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 locale di Azure e la sicurezza del carico di lavoro. Quando viene distribuita con le impostazioni di sicurezza predefinite, Azure Local include Windows Defender Application Control, Credential Guard e BitLocker abilitati. Per semplificare la delega delle autorizzazioni tramite poLP, usare ruoli di controllo degli accessi in base al ruolo (RBAC) predefiniti di Azure locale come Amministratore locale di Azure per amministratori della piattaforma e Collaboratore macchina virtuale locale di Azure o Lettore di macchine virtuali locali di Azure per gli operatori del carico di lavoro.

• Impostazioni di sicurezza predefinite: impostazione predefinita della sicurezza locale di Azure applica le impostazioni di sicurezza predefinite per l'istanza locale di Azure durante la distribuzione e abilita 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 locale di Azure 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 for Cloud protegge l'istanza locale di Azure da varie minacce e vulnerabilità. Questo servizio consente di migliorare il comportamento di sicurezza dell'ambiente locale di Azure e di proteggersi dalle 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 dell'istanza locale di Azure 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 dell'istanza locale di Azure 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 Recommendations for building a segmentation strategy.

Ottimizzazione dei costi

L'ottimizzazione dei costi consiste nell'esaminare i 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 locali di Azure seguono il modello di fatturazione della sottoscrizione mensile con una tariffa fissa per ogni core del processore fisico in un'istanza locale di Azure. 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 le tariffe di sottoscrizione all'istanza locale di Azure e alle macchine virtuali Windows Server.

• l'applicazione automatica di patch guest alle macchine virtuali di Azure Arc: questa funzionalità consente di ridurre il sovraccarico dell'applicazione manuale di 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 dei costi: per consolidare i costi di monitoraggio, usare Insights per il locale di Azure e applicare patch usando Update Manager perlocale di Azure. Insights usa Monitoraggio per fornire metriche avanzate e funzionalità di avviso. Il componente lifecycle manager di Azure Localintegrates 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à iniziale del carico di lavoro e crescita: quando si pianifica la distribuzione locale di Azure, 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 istanze locali di Azure. È 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 l'architettura locale di Azure.

  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'istanza locale di Azure. Analogamente, Azure semplifica il processo di gestione delle istanze locali di Azure e macchine virtuali di Azure Arc. È possibile automatizzare la distribuzione basata sul portale dell'istanza locale di Azure usando modello di Resource Manager. Questo modello offre coerenza e automazione per distribuire Azure Locale su larga scala, in particolare in scenari perimetrali, ad esempio punti vendita al dettaglio o siti di produzione che richiedono un'istanza locale di Azure per eseguire carichi di lavoro business critical.

• funzionalità di automazione per le macchine virtuali: Azure locale offre un'ampia gamma di funzionalità di automazione per la gestione dei carichi di lavoro, ad esempio macchine virtuali di Azure Arc, con la distribuzione automatizzata di macchine virtuali di Azure Arc tramite l'interfaccia della riga di comando di Azure, ARM o modello Bicep, con gli aggiornamenti del sistema operativo delle macchine virtuali tramite l'estensione Azure Arc per gli aggiornamenti e di Azure Update Manager per aggiornare ogni istanza locale di Azure. Azure Local offre anche il supporto per di gestione delle macchine virtuali di Azure Arc usando l'interfaccia della riga di comando di Azure e macchine virtuali non Azure Arc tramite Windows PowerShell. È possibile eseguire i comandi dell'interfaccia della riga di comando di Azure in locale da uno dei computer locali di Azure o in remoto da un computer di gestione. L'integrazione con Automazione di Azure e Azure Arc semplifica 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 Recommendations for using IaC.

• funzionalità di automazione per i contenitori nel servizio Azure Kubernetes: Azure locale 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 del 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 computer locali di Azure 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 Recommendations for enabling automation.For more information, see Recommendations for enabling automation.

Efficienza delle prestazioni

L'efficienza delle prestazioni è la capacità del carico di lavoro di ridimensionarsi per soddisfare le esigenze poste dagli utenti in modo efficiente. Per altre informazioni, vedere panoramica 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 prestazioni dell'archiviazione del carico di lavoro di un'istanza locale di Azure. È 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 delle istanze locali di Azure 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 Recommendations for performance testing.

• resilienza dell'archiviazione del carico di lavoro: considerare i vantaggi della resilienza di archiviazione , l'efficienza dell'utilizzo (o della capacità) e le prestazioni. La pianificazione dei volumi locali di Azure 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 Recommendations for capacity planning.

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

  • Per ottimizzare le prestazioni di calcolo in Locale di Azure, è possibile usare l'accelerazione GPU. L'accelerazione GPU è utile per carichi di lavoro di intelligenza artificiale ad alte prestazioni o 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 le istanze locali di Azure.

    Per altre informazioni, vedere Raccomandazioni per selezionare i servizi corretti.

Distribuire questo scenario

La sezione seguente fornisce un elenco di esempio delle attività di alto livello o del flusso di lavoro tipico usato per distribuire Azure Local, 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 casi d'uso potenziali di questo articolo. I passaggi rimanenti presuppongono che Azure Locale sia la soluzione di piattaforma dell'infrastruttura scelta per il progetto.

1. Raccogliere i requisiti del carico di lavoro e dei casi d'uso degli stakeholder pertinenti. Questa strategia consente al progetto di verificare che le funzionalità e le funzionalità di Azure Locale 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 ridimensionatore locale di Azure 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 locale di azure per creare un nuovo progetto che modella il tipo di carico di lavoro e ridimensiona. 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 precedente Scelte di progettazione del cluster.

4. Esaminare l'output di Azure Local 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 il partner OEM o SI hardware 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 presenti nell'elenco approvato dei commutatori di rete supportati da Azure Local.

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 dell'istanza locale di Azure. A seconda della versione scelta della soluzione (soluzione Premier, Sistema integrato o Nodi convalidati), il partner hardware, il partner SI o i dipendenti possono distribuire il software locale di Azure. 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 locale di Azure. 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 l'OEM hardware o il partner SI, a seconda della natura della richiesta e della categoria di soluzioni hardware.

   Mancia

   Il sistema operativo Azure Stack HCI versione 23H2 illustra come distribuire una distribuzione multiserver cambiata di Azure Local usando un modello di Resource Manager e un file di parametri. In alternativa, l'esempio Bicep illustra come usare un modello Bicep per distribuire un'istanza locale di Azure, incluse le risorse dei prerequisiti.

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

10. Installare gli aggiornamenti mensili per migliorare la sicurezza e l'affidabilità della piattaforma. Per mantenere aggiornate le istanze locali di Azure, è importante installare gli aggiornamenti software Microsoft e gli aggiornamenti hardware oem e firmware. Questi aggiornamenti migliorano la sicurezza e l'affidabilità della piattaforma. Gestione aggiornamenti applica gli aggiornamenti e offre 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

• progettazione di architetture ibride
• opzioni ibride di Azure
• Automazione in un ambiente ibrido
• di State Configuration di Automazione di Azure
• Ottimizzare l'amministrazione delle istanze di SQL Server in ambienti locali e multicloud usando Azure Arc

Passaggi successivi

Documentazione del prodotto:

• sistema operativo Azure Stack HCI versione 23H2
• servizio Azure Kubernetes nel locale di Azure
• Desktop virtuale Azure per locale di Azure
• Che cos'è il monitoraggio locale di Azure?
• Proteggere i carichi di lavoro delle macchine virtuali con Site Recovery nel locale di Azure
• panoramica di Monitor
• panoramica del rilevamento delle modifiche e dell'inventario
• panoramica di Gestione aggiornamenti di
• Che cosa sono i servizi dati abilitati per Azure Arc?
• Quali sono i server abilitati per Azure Arc?
• Che cos'è il servizio Backup?

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

• locale di Azure
• azure Arc
• key vault
• di Archiviazione BLOB di Azure
• Monitor
• di Criteri di Azure
• registro Azure Container
• Defender for Cloud
• di Site Recovery
• backup

Moduli di Microsoft Learn:

• Configurare di 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
• distribuzione di modelli di scalabilità con Machine Learning ovunque - Blog della community tecnica
• La realizzazione di Machine Learning ovunque con il servizio Azure Kubernetes e Machine Learning abilitato per Azure Arc - Blog della community tecnica
• Machine Learning nel servizio 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 i di backup