Considerazioni sulla pianificazione dell'integrazione dei data center per i sistemi integrati dell'hub di Azure Stack

Se si è interessati a un sistema integrato dell'hub di Azure Stack, è necessario comprendere le principali considerazioni sulla pianificazione della distribuzione e sul modo in cui il sistema rientra nel data center. Questo articolo offre una panoramica generale di queste considerazioni che consentono di prendere decisioni importanti sull'infrastruttura per i sistemi integrati dell'hub di Azure Stack. Una conoscenza di queste considerazioni aiuta quando si lavora con il fornitore di hardware OEM durante la distribuzione dell'hub di Azure Stack nel data center.

Nota

I sistemi integrati dell'hub di Azure Stack possono essere acquistati solo da fornitori di hardware autorizzati.

Per distribuire l'hub di Azure Stack, è necessario fornire informazioni di pianificazione al provider di soluzioni prima che la distribuzione inizi a semplificare il processo. Le informazioni necessarie variano in base alle informazioni di rete, sicurezza e identità con molte decisioni importanti che possono richiedere conoscenze da molte aree e decision maker diversi. Saranno necessari utenti di più team dell'organizzazione per assicurarsi di avere tutte le informazioni necessarie pronte prima della distribuzione. Può aiutare a comunicare con il fornitore di hardware durante la raccolta di queste informazioni perché potrebbero avere consigli utili.

Durante la ricerca e la raccolta delle informazioni necessarie, potrebbe essere necessario apportare alcune modifiche alla configurazione di pre-distribuzione nell'ambiente di rete. Queste modifiche possono includere la prenotazione di spazi di indirizzi IP per la soluzione hub di Azure Stack, nonché la configurazione dei router, dei commutatori e dei firewall per prepararsi alla connettività ai nuovi commutatori della soluzione hub di Azure Stack. Assicurati di avere l'esperto dell'area di interesse pronto per aiutarti con la tua pianificazione.

Considerazioni sulla pianificazione della capacità

Quando si valuta una soluzione hub di Azure Stack per l'acquisizione, si effettuano scelte di configurazione hardware che hanno un impatto diretto sulla capacità complessiva della soluzione hub di Azure Stack. Queste includono le scelte classiche di CPU, densità di memoria, configurazione dell'archiviazione e scalabilità complessiva della soluzione (ad esempio, numero di server). A differenza di una soluzione di virtualizzazione tradizionale, la semplice aritmetica di questi componenti per determinare la capacità utilizzabile non si applica. Il primo motivo è che l'hub di Azure Stack è progettato per ospitare l'infrastruttura o i componenti di gestione all'interno della soluzione stessa. Il secondo motivo è che alcune capacità della soluzione sono riservate per supportare la resilienza aggiornando il software della soluzione in modo da ridurre al minimo le interruzioni dei carichi di lavoro del tenant.

Il foglio di calcolo azure Stack Hub capacity planner consente di prendere decisioni informate per la pianificazione della capacità in due modi. Il primo consiste nel selezionare un'offerta hardware e tentare di adattarsi a una combinazione di risorse. Il secondo consiste nel definire il carico di lavoro che l'hub di Azure Stack deve eseguire per visualizzare gli SKU hardware disponibili che possono supportarlo. Infine, il foglio di calcolo è concepito come guida per prendere decisioni relative alla pianificazione e alla configurazione dell'hub di Azure Stack.

Il foglio di calcolo non è destinato a fungere da sostituto dell'indagine e dell'analisi. Microsoft non rilascia alcuna rappresentazione o garanzia, espressa o implicita, in relazione alle informazioni fornite all'interno del foglio di calcolo.

Considerazioni sulla gestione

L'hub di Azure Stack è un sistema sealed, in cui l'infrastruttura è bloccata sia dal punto di vista delle autorizzazioni che della rete. Gli elenchi di controllo di accesso di rete (ACL) vengono applicati per bloccare tutto il traffico in ingresso non autorizzato e tutte le comunicazioni non necessarie tra i componenti dell'infrastruttura. Questo sistema rende difficile per gli utenti non autorizzati accedere al sistema.

Per la gestione e le operazioni quotidiane, non è disponibile alcun accesso amministrativo senza restrizioni all'infrastruttura. Gli operatori dell'hub di Azure Stack devono gestire il sistema tramite il portale di amministrazione o tramite Azure Resource Manager (tramite PowerShell o l'API REST). Non è possibile accedere al sistema da altri strumenti di gestione, ad esempio Hyper-V Manager o Gestione cluster di failover. Per proteggere il sistema, non è possibile installare software di terze parti ,ad esempio agenti, all'interno dei componenti dell'infrastruttura dell'hub di Azure Stack. L'interoperabilità con software di gestione e sicurezza esterno avviene tramite PowerShell o l'API REST.

Contattare il supporto tecnico Microsoft quando è necessario un livello di accesso superiore per la risoluzione dei problemi che non vengono risolti tramite i passi di mediazione degli avvisi. Grazie al supporto, è disponibile un metodo per fornire l'accesso temporaneo completo di amministratore al sistema per operazioni più complesse.

Considerazioni sull'identità

Scegliere il provider di identità

È necessario considerare il provider di identità che si vuole usare per la distribuzione dell'hub di Azure Stack, ovvero Microsoft Entra ID o AD FS. Non è possibile cambiare provider di identità dopo la distribuzione senza ridistribuzione completa del sistema. Se non sei proprietario dell'account Microsoft Entra e stai usando un account fornito dal tuo Cloud Solution Provider e decidi di cambiare provider e usare un account Microsoft Entra diverso, sarà necessario contattare il tuo Cloud Solution Provider per ridistribuire la soluzione a tue spese.

La scelta del provider di identità non ha alcun impatto sulle macchine virtuali tenant, sul sistema di identità, sugli account usati o sul fatto che possano aggiungere un dominio di Active Directory e così via. Queste cose sono separate.

È possibile distribuire più sistemi hub di Azure Stack con lo stesso tenant di Microsoft Entra o Active Directory.

Integrazione di AD FS e Graph

Se si sceglie di distribuire l'hub di Azure Stack usando AD FS come provider di identità, è necessario integrare l'istanza di AD FS nell'hub di Azure Stack con un'istanza di AD FS esistente tramite un trust federativo. Questa integrazione consente alle identità in una foresta Active Directory esistente di eseguire l'autenticazione con le risorse nell'hub di Azure Stack.

È anche possibile integrare il servizio Graph nell'hub di Azure Stack con l'istanza di Active Directory esistente. Questa integrazione consente di gestire Role-Based Access Control (controllo di accesso RBAC) in Azure Stack Hub. Quando si delega l'accesso a una risorsa, il componente Graph cerca l'account utente nella foresta Active Directory esistente usando il protocollo LDAP.

Il diagramma seguente illustra il flusso di traffico integrato di AD FS e Graph.

Diagramma

Modello di licenza

È necessario decidere quale modello di licenza si vuole usare. Le opzioni disponibili dipendono dalla distribuzione dell'hub di Azure Stack connesso a Internet:

• Per una distribuzione connessa , è possibile scegliere licenze con pagamento in base al consumo o basate sulla capacità. Il pagamento in base al consumo richiede una connessione ad Azure per segnalare l'utilizzo, che viene quindi fatturato tramite il commercio di Azure.
• Solo le licenze basate sulla capacità sono supportate se si distribuire disconnessi da Internet.

Per altre informazioni sui modelli di licenza, vedere pacchetti e prezzi dell'hub di Microsoft Azure Stack.

Decisioni relative alla denominazione

È necessario considerare come pianificare lo spazio dei nomi dell'hub di Azure Stack, in particolare il nome dell'area e il nome di dominio esterno. Il nome di dominio completo esterno (FQDN) della distribuzione dell'hub di Azure Stack per gli endpoint pubblici è la combinazione di questi due nomi: <'area>.<fqdn>. Ad esempio, east.cloud.fabrikam.com. In questo esempio, i portali dell'hub di Azure Stack saranno disponibili negli URL seguenti:

• https://portal.east.cloud.fabrikam.com
• https://adminportal.east.cloud.fabrikam.com

Importante

Il nome dell'area scelto per la distribuzione dell'hub di Azure Stack deve essere univoco e verrà visualizzato negli indirizzi del portale.

Nella tabella seguente vengono riepilogate queste decisioni di denominazione dei domini.

Nome	Descrizione
Nome della regione	Nome della prima area dell'hub di Azure Stack. Questo nome viene usato come parte del nome di dominio completo per gli indirizzi IP virtuali pubblici gestiti dall'hub di Azure Stack. In genere, il nome dell'area è un identificatore di posizione fisica, ad esempio una posizione del data center. Il nome dell'area deve essere costituito solo da lettere e numeri compresi tra 0 e 9. Non sono consentiti caratteri speciali (ad esempio -, #e così via).
Nome di dominio esterno	Nome della zona DNS (Domain Name System) per gli endpoint con indirizzi VIP esterni. Utilizzato nel nome di dominio completamente qualificato (FQDN) per questi indirizzi IP virtuali pubblici.
Nome di dominio privato (interno)	Nome del dominio (e zona DNS interna) creato nell'hub di Azure Stack per la gestione dell'infrastruttura.

Requisiti dei certificati

Per la distribuzione, è necessario fornire certificati SSL (Secure Sockets Layer) per gli endpoint pubblici. A livello generale, i certificati hanno i requisiti seguenti:

• È possibile usare un singolo certificato wildcard oppure un set di certificati dedicati e quindi usare i wildcard solo per servizi come Archiviazione e Key Vault.
• I certificati possono essere emessi da un'autorità di certificazione (CA) attendibile pubblica o da una CA gestita dal cliente.

Per altre informazioni sui certificati PKI necessari per distribuire l'hub di Azure Stack e su come ottenerli, vedere requisiti del certificato dell'infrastruttura a chiave pubblica dell'hub di Azure Stack.

Importante

Le informazioni sul certificato PKI fornite devono essere usate come indicazioni generali. Prima di acquisire i certificati PKI per l'hub di Azure Stack, collaborare con il partner hardware OEM. Fornirà indicazioni e requisiti più dettagliati sui certificati.

Sincronizzazione dell'ora

È necessario scegliere un server ora specifico usato per sincronizzare l'hub di Azure Stack. La sincronizzazione dell'ora è fondamentale per l'hub di Azure Stack e i relativi ruoli di infrastruttura perché viene usata per generare ticket Kerberos. I ticket Kerberos vengono usati per autenticare reciprocamente i servizi interni.

È necessario specificare un indirizzo IP per il server di sincronizzazione dell'ora. Anche se la maggior parte dei componenti dell'infrastruttura può risolvere un URL, alcuni supportano solo gli indirizzi IP. Se si usa l'opzione di distribuzione disconnessa, è necessario specificare un server ora nella rete aziendale che si è certi di poter raggiungere dalla rete dell'infrastruttura nell'hub di Azure Stack.

Importante

Se il tuo server orario non è un server NTP basato su Windows, è necessario aggiungere ,0x8 alla fine dell'indirizzo IP. Ad esempio, 10.1.1.123,0x8.

Connettere l'hub di Azure Stack ad Azure

Per gli scenari cloud ibridi, è necessario pianificare la modalità di connessione dell'hub di Azure Stack ad Azure. Esistono due metodi supportati per connettere le reti virtuali nell'hub di Azure Stack alle reti virtuali in Azure:

• da sito a sito: una connessione VPN (Virtual Private Network) tramite IPsec (IKE v1 e IKE v2). Questo tipo di connessione richiede un dispositivo VPN o un servizio di routing e accesso remoto (RRAS). Per altre informazioni sui gateway VPN in Azure, vedere Informazioni sul gateway VPN. La comunicazione su questo tunnel è crittografata e sicura. Tuttavia, la larghezza di banda è limitata dalla velocità effettiva massima del tunnel (100-200 Mbps).

• NAT in uscita: Per impostazione predefinita, tutte le macchine virtuali nell'Hub di Azure Stack avranno connettività alle reti esterne tramite NAT in uscita. A ogni rete virtuale creata nell'hub di Azure Stack viene assegnato un indirizzo IP pubblico. Indipendentemente dal fatto che alla macchina virtuale venga assegnato direttamente un indirizzo IP pubblico o che si trovi dietro un servizio di bilanciamento del carico con un indirizzo IP pubblico, avrà accesso in uscita tramite NAT in uscita usando l'indirizzo VIP della rete virtuale. Questo metodo funziona solo per le comunicazioni avviate dalla macchina virtuale e destinate a reti esterne (Internet o Intranet). Non può essere usato per comunicare con la macchina virtuale dall'esterno.

Opzioni di connettività ibrida

Per la connettività ibrida, è importante considerare il tipo di distribuzione che si vuole offrire e dove verrà distribuito. È necessario valutare se è necessario isolare il traffico di rete per tenant e se si avrà una distribuzione Intranet o Internet.

• hub di Azure Stack a tenant singolo: una distribuzione dell'hub di Azure Stack che esamina, almeno dal punto di vista della rete, come se fosse un tenant. Possono essere presenti molte sottoscrizioni tenant, ma come qualsiasi servizio Intranet, tutto il traffico passa attraverso le stesse reti. Il traffico di rete proveniente da una sottoscrizione passa attraverso la stessa connessione di rete di un'altra sottoscrizione e non deve essere isolato tramite un tunnel crittografato.

• Hub di Azure Stack multi-tenant: una distribuzione dell'Hub di Azure Stack in cui il traffico di rete di ciascun abbonamento tenant destinato alle reti esterne all'Hub di Azure Stack deve essere isolato dal traffico di rete degli altri tenant.

• distribuzione Intranet: una distribuzione dell'hub di Azure Stack che si trova in una intranet aziendale, in genere in uno spazio indirizzi IP privato e dietro uno o più firewall. Gli indirizzi IP pubblici non sono realmente pubblici perché non possono essere instradati direttamente su Internet pubblico.

• distribuzione Internet: una distribuzione di Azure Stack Hub connessa a Internet pubblico e usa indirizzi IP pubblici instradabili su Internet per l'intervallo VIP pubblico. La distribuzione può comunque rimanere dietro un firewall, ma l'intervallo di indirizzi VIP pubblici è direttamente raggiungibile da Internet pubblico e Azure.

La tabella seguente riepiloga gli scenari di connettività ibrida con i vantaggi, i svantaggi e i casi d'uso.

Scenario	Metodo di connettività	Vantaggi	Contro	Buono per
Hub di Azure Stack a tenant singolo, distribuzione Intranet	NAT in uscita	Migliore larghezza di banda per trasferimenti più veloci. Semplice da implementare; nessun gateway necessario.	Traffico non crittografato; nessun isolamento o crittografia all'esterno dello stack.	Distribuzioni aziendali in cui tutti i tenant sono ugualmente attendibili. Aziende che hanno un circuito Azure ExpressRoute verso Azure.
Distribuzione intranet di Azure Stack Hub multi-tenant	VPN da sito a sito	Il traffico dalla rete virtuale del tenant alla destinazione è sicuro.	La larghezza di banda è limitata dal tunnel VPN da sito a sito. Richiede un gateway nella rete virtuale e un dispositivo VPN nella rete di destinazione.	Distribuzioni aziendali in cui è necessario proteggere il traffico degli inquilini da altri inquilini.
Hub di Azure Stack a tenant singolo, distribuzione Internet	NAT in uscita	Migliore larghezza di banda per trasferimenti più veloci.	Traffico non crittografato; nessun isolamento o crittografia all'esterno dello stack.	Scenari di hosting in cui il tenant ottiene la propria distribuzione dell'hub di Azure Stack e un circuito dedicato all'ambiente dell'hub di Azure Stack. Ad esempio, ExpressRoute e Multiprotocol Label Switching (MPLS).
Hub di Azure Stack multi-tenant, distribuzione Internet	VPN da sito a sito	Il traffico dalla rete virtuale del tenant alla destinazione è sicuro.	La larghezza di banda è limitata dal tunnel VPN da sito a sito. Richiede un gateway nella rete virtuale e un dispositivo VPN nella rete di destinazione.	Scenari di hosting in cui il provider vuole offrire un cloud multi-tenant, in cui i tenant non si considerano attendibili e il traffico deve essere crittografato.

Uso di ExpressRoute

È possibile connettere l'hub di Azure Stack ad Azure tramite ExpressRoute per scenari intranet a tenant singolo e multi-tenant. È necessario un circuito ExpressRoute dotato di provisioning tramite un provider di connettività.

Il diagramma seguente illustra ExpressRoute per uno scenario a tenant singolo ,dove "Connessione del cliente" è il circuito ExpressRoute.

diagramma

Il diagramma seguente illustra ExpressRoute per uno scenario multi-tenant.

diagramma

Monitoraggio esterno

Per ottenere una singola visualizzazione di tutti gli avvisi dalla distribuzione e dai dispositivi dell'hub di Azure Stack e per integrare gli avvisi nei flussi di lavoro esistenti di gestione dei servizi IT per il ticket, è possibile integrare l'hub di Azure Stack con soluzioni di monitoraggio dei data center esterne.

Incluso nella soluzione hub di Azure Stack, l'host del ciclo di vita dell'hardware è un computer esterno all'hub di Azure Stack che esegue gli strumenti di gestione forniti dai fornitori OEM per l'hardware. È possibile usare questi strumenti o altre soluzioni che si integrano direttamente con soluzioni di monitoraggio esistenti nel data center.

La tabella seguente riepiloga l'elenco delle opzioni attualmente disponibili.

Area	Soluzione di monitoraggio esterno
Software dell'hub di Azure Stack	Management Pack dell'hub di Azure Stack per Operations Manager plug-in Nagios Chiamate API basate su REST
Server fisici (BMC tramite IPMI)	Hardware OEM - Pacchetto di gestione del fornitore di Operations Manager Soluzione fornita dal fornitore di hardware OEM Plug-in del fornitore di hardware Nagios. Soluzione di monitoraggio supportata dai partner OEM (inclusa)
Dispositivi di rete (SNMP)	Individuazione dei dispositivi di rete di Operations Manager Soluzione fornita dal fornitore di hardware OEM Plug-in del commutatore Nagios
Monitoraggio dell'integrità della sottoscrizione del cliente	System Center Management Pack per Windows Azure

Si notino i requisiti seguenti:

• La soluzione usata deve essere senza agente. Non è possibile installare agenti di terze parti all'interno dei componenti dell'hub di Azure Stack.
• Se si vuole usare System Center Operations Manager, è necessario Operations Manager 2012 R2 o Operations Manager 2016.

Backup e ripristino di emergenza

La pianificazione del backup e del ripristino di emergenza prevede la pianificazione per l'infrastruttura dell'hub di Azure Stack sottostante che ospita macchine virtuali IaaS e servizi PaaS e per le app e i dati tenant. Pianificare questi aspetti separatamente.

Proteggere i componenti dell'infrastruttura

È possibile eseguire il backup dei componenti dell'infrastruttura di Azure Stack Hub in una condivisione SMB da te specificata:

• È necessaria una condivisione file SMB esterna in un file server basato su Windows esistente o in un dispositivo di terze parti.
• Usare questa stessa condivisione per il backup degli switch di rete e dell'host del ciclo di vita dell'hardware. Il fornitore dell'hardware OEM fornirà indicazioni per il backup e il ripristino di questi componenti perché sono esterni all'hub di Azure Stack. L'utente è responsabile dell'esecuzione dei flussi di lavoro di backup in base alle raccomandazioni del fornitore OEM.

Se si verifica una perdita irreversibile dei dati, è possibile usare il backup dell'infrastruttura per reinsediare i dati di distribuzione, ad esempio:

• Input e identificatori della distribuzione
• Account di servizio
• Certificato radice dell'Autorità di Certificazione
• Risorse federate (in distribuzioni disconnesse)
• Piani, offerte, sottoscrizioni e quote
• Politiche RBAC e assegnazioni di ruolo
• Segreti di Key Vault

Avvertimento

Per impostazione predefinita, il timbro dell'hub di Azure Stack è configurato con un solo account CloudAdmin. Non sono disponibili opzioni di ripristino se le credenziali dell'account vengono perse, compromesse o bloccate. Si perderà l'accesso all'endpoint con privilegi e ad altre risorse.

È altamente consigliabile di creare account CloudAdmin aggiuntivi, per evitare la ridistribuzione del timbro a tue spese. Assicurarsi di documentare queste credenziali in base alle linee guida dell'azienda.

Proteggere le app tenant nelle macchine virtuali IaaS

L'hub di Azure Stack non esegue il backup di app e dati tenant. È necessario pianificare la protezione di backup e ripristino di emergenza in una destinazione esterna all'hub di Azure Stack. La protezione degli inquilini è un'attività guidata dagli inquilini. Per le macchine virtuali IaaS, i tenant possono usare tecnologie in-guest per proteggere cartelle file, dati dell'app e stato del sistema. Tuttavia, in qualità di provider di servizi o aziendali, può essere necessario offrire una soluzione di backup e ripristino nello stesso data center o esternamente in un cloud.

Per eseguire il backup di macchine virtuali IaaS Linux o Windows, è necessario usare i prodotti di backup con accesso al sistema operativo guest per proteggere i dati di file, cartelle, sistema operativo e app. È possibile usare Backup di Azure, System Center Datacenter Protection Manager o prodotti di terze parti supportati.

Per replicare i dati in una posizione secondaria e orchestrare il failover dell'applicazione in caso di emergenza, è possibile usare Azure Site Recovery o prodotti di terze parti supportati. Inoltre, le app che supportano la replica nativa, come Microsoft SQL Server, possono replicare i dati in un'altra posizione in cui è in esecuzione l'app.

Ulteriori informazioni

• Per informazioni sui casi d'uso, l'acquisizione, i partner e i fornitori di hardware OEM, vedere la pagina del prodotto Azure Stack Hub.
• Per informazioni sulla roadmap e sulla disponibilità geografica per i sistemi integrati dell'hub di Azure Stack, vedere il white paper: hub di Azure Stack: un'estensione di Azure.

Passaggi successivi

modelli di connessione per la distribuzione di Azure Stack Hub