Considerazioni sulla pianificazione dell'integrazione del data center per i sistemi integrati dall'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 si adatta al 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 comprensione di queste considerazioni consente di usare il fornitore dell'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 dai fornitori di hardware autorizzati.
Per distribuire l'hub di Azure Stack, è necessario fornire informazioni di pianificazione al provider di soluzioni prima dell'avvio della distribuzione per facilitare il processo in modo rapido e uniforme. Le informazioni necessarie si estendeno tra reti, sicurezza e informazioni sull'identità con molte decisioni importanti che possono richiedere conoscenze da molte aree diverse e responsabili delle decisioni. È necessario che gli utenti di più team dell'organizzazione dispongano di tutte le informazioni necessarie pronte prima della distribuzione. Può aiutare a parlare con il fornitore dell'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 di configurazione pre-distribuzione all'ambiente di rete. Queste modifiche possono includere la prenotazione di spazi di indirizzi IP per la soluzione Hub di Azure Stack e la configurazione dei router, delle opzioni e dei firewall per preparare la connettività ai nuovi commutatori dell'hub di Azure Stack. Assicurarsi di avere l'esperto dell'area del soggetto allineato per aiutarti a pianificare.
Considerazioni sulla pianificazione della capacità
Quando si valuta una soluzione hub di Azure Stack per l'acquisizione, si apportano 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 di 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 una delle capacità della soluzione è riservata al supporto della resilienza aggiornando il software della soluzione in modo da ridurre al minimo l'interruzione dei carichi di lavoro del tenant.
Il foglio di calcolo di pianificazione della capacità dell'hub di Azure Stack consente di prendere decisioni informate per la pianificazione della capacità in due modi. Il primo è selezionare un'offerta hardware e tentare di adattarsi a una combinazione di risorse. Il secondo è definire il carico di lavoro che l'hub di Azure Stack è destinato a eseguire per visualizzare gli SKU hardware disponibili che possono supportarlo. Infine, il foglio di calcolo è destinato a una guida per prendere decisioni correlate alla pianificazione e alla configurazione dell'hub di Azure Stack.
Il foglio di calcolo non intende sostituire le normali attività di indagine e analisi svolte dal cliente. Microsoft non fornisce rappresentazioni o garanzie, esplicite o implicite, relativamente alle informazioni fornite nel foglio di calcolo.
Considerazioni sulla gestione
L'hub di Azure Stack è un sistema chiuso, in cui l'infrastruttura è bloccata sia da un punto di vista delle autorizzazioni che della rete. Gli elenchi di controllo di accesso di rete 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 amministratore senza restrizioni all'infrastruttura. Gli operatori dell'hub di Azure Stack devono gestire il sistema tramite il portale di amministratore 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 esterna e sicurezza si verifica tramite PowerShell o l'API REST.
Contattare supporto tecnico Microsoft quando è necessario un livello superiore di accesso per la risoluzione dei problemi che non vengono risolti tramite i passaggi di mediazione degli avvisi. Tramite il supporto è disponibile un metodo per fornire l'accesso completo temporaneo al sistema per operazioni più avanzate.
Considerazioni sull'identità
Scegliere il provider di identità
È necessario considerare quale provider di identità si vuole usare per la distribuzione dell'hub di Azure Stack, Microsoft Entra ID o AD FS. Non è possibile cambiare provider di identità dopo la distribuzione senza una ridistribuzione completa del sistema. Se non si possiede l'account Microsoft Entra e si usa un account fornito dal provider di soluzioni cloud e se si decide di cambiare provider e usare un account Microsoft Entra diverso, è necessario contattare il provider di soluzioni per ridistribuire la soluzione a costo.
La scelta del provider di identità non ha alcun effetto sulle macchine virtuali del tenant, sul sistema di identità, sugli account usati o sul fatto che possano partecipare a un dominio di Active Directory e così via. Questi aspetti sono separati.
È possibile distribuire più sistemi hub di Azure Stack con lo stesso tenant 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 Controllo di accesso (RBAC) nell'hub di Azure Stack. Quando l'accesso a una risorsa viene delegato, il componente Graph cerca l'account utente nella foresta Active Directory esistente usando il protocollo LDAP.
Il diagramma seguente mostra il flusso di traffico di AD FS e Graph integrato.
Modello di licenza
È necessario decidere quale modello di licenza usare. Le opzioni disponibili variano in base al fatto che si distribuisca l'hub di Azure Stack con o senza connessione a Internet.
- Per una distribuzione connessa, è possibile scegliere licenze basate su pagamento in base al consumo o alla capacità. Il pagamento in base al consumo richiede una connessione ad Azure allo scopo di tracciarne l'utilizzo, che viene quindi fatturato tramite l'e-commerce di Azure.
- Solo le licenze basate sulla capacità sono supportate se si distribuisce disconnessa da Internet.
Per altre informazioni sui modelli di licenza, vedere Creazione di pacchetti e prezzi dell'hub di Microsoft Azure Stack.
Decisioni di denominazione
È necessario considerare come pianificare lo spazio dei nomi dell'hub di Azure Stack, soprattutto 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 agli URL seguenti:
https://portal.east.cloud.fabrikam.comhttps://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.
La tabella seguente riepiloga queste decisioni di denominazione del dominio.
| Name | Descrizione |
|---|---|
| Nome area | 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 | Il nome della zona DNS (Domain Name System) per gli endpoint con indirizzi VIP esterni. Viene usato nel nome di dominio completo per questi indirizzi VIP pubblici. |
| Nome di dominio privato (interno) | Il nome del dominio (e della zona DNS interna) creato nell'hub di Azure Stack per la gestione dell'infrastruttura. |
Requisiti per i certificati
Per la distribuzione, è necessario fornire i certificati Secure Sockets Layer (SSL) per gli endpoint pubblici. A livello generale, i certificati hanno i requisiti seguenti:
- È possibile usare un unico certificato con caratteri jolly oppure usare un set di certificati dedicati e quindi usare caratteri jolly solo per endpoint come archiviazione e Key Vault.
- I certificati possono essere rilasciati 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 fornito devono essere usate come linee guida generali. Prima di acquisire i certificati PKI per l'hub di Azure Stack, consultare il partner hardware OEM. Il partner fornirà indicazioni e requisiti più dettagliati sui certificati.
Sincronizzazione dell'ora
È necessario scegliere un server di ora specifico che viene usato per sincronizzare l'hub di Azure Stack. La sincronizzazione temporale è fondamentale per l'hub di Azure Stack e i relativi ruoli di infrastruttura perché viene usata per generare i ticket Kerberos. I ticket Kerberos vengono usati per autenticare i servizi interni tra loro.
È necessario specificare un INDIRIZZO IP per il server di sincronizzazione dell'ora. Anche se la maggior parte dei componenti nell'infrastruttura può risolvere un URL, alcuni solo supportano gli indirizzi IP. Se si usa l'opzione di distribuzione disconnessa, è necessario specificare un server di tempo nella rete aziendale che si è certi di poter raggiungere dalla rete infrastruttura in Azure Stack Hub.
Importante
Se il server di tempo non è un server NTP basato su Windows, è necessario aggiungere ,0x8 la fine dell'indirizzo IP. Ad esempio: 10.1.1.123,0x8.
Connettere l'hub di Azure Stack ad Azure
Per gli scenari basati su cloud ibrido, è necessario pianificare come connettere l'hub di Azure Stack ad Azure. Sono supportati due metodi per connettere reti virtuali nell'hub di Azure Stack a reti virtuali in Azure:
Da sito a sito: connessione di rete privata virtuale (VPN) tramite IPsec (IKE v1 e IKE v2). Questo tipo di connessione richiede un dispositivo VPN e il servizio Routing e Accesso remoto. Per altre informazioni sui gateway VPN in Azure, vedere Informazioni su Gateway VPN. La comunicazione tramite 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. Se la macchina virtuale viene assegnata direttamente a un indirizzo IP pubblico o si trova 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 la comunicazione avviata dalla macchina virtuale e destinata alle 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à eseguita. È necessario valutare se è necessario isolare il traffico di rete per ogni tenant e se eseguire una distribuzione Intranet o Internet.
Hub di Azure Stack a tenant singolo: una distribuzione dell'hub di Azure Stack che sembra, almeno da un punto di vista di rete, un unico tenant. Possono essere disponibili molte sottoscrizioni di tenant ma, come qualsiasi servizio Intranet, tutto il traffico viaggia sulle stesse reti. Il traffico di rete proveniente da una sottoscrizione viaggia sulla stessa connessione di rete di un'altra sottoscrizione e non è necessario isolarlo tramite un tunnel crittografato.
Hub di Azure Stack multi-tenant: una distribuzione dell'hub di Azure Stack in cui il traffico di ogni sottoscrizione di tenant destinato a reti esterne all'hub di Azure Stack deve essere isolato dal traffico di rete di altri tenant.
Distribuzione Intranet: una distribuzione dell'hub di Azure Stack che risiede in una Intranet aziendale, in genere nello spazio indirizzi IP privato e dietro a uno o più firewall. Gli indirizzi IP pubblici non sono realmente pubblici perché non possono essere instradati direttamente tramite la rete Internet pubblica.
Distribuzione Internet: una distribuzione dell'hub di Azure Stack connessa alla rete Internet pubblica che usa indirizzi IP pubblici instradabili a Internet per l'intervallo di indirizzi VIP pubblici. La distribuzione può comunque rimanere dietro a un firewall, ma l'intervallo di indirizzi VIP pubblici è raggiungibile direttamente dalla rete Internet pubblica e da Azure.
La tabella seguente riepiloga gli scenari di connettività ibrida con i vantaggi, gli svantaggi e i casi d'uso.
| Scenario | Metodo Di connettività | Vantaggi | Svantaggi | Ideale per |
|---|---|---|---|---|
| Hub di Azure Stack a tenant singolo, distribuzione Intranet | NAT in uscita | Larghezza di banda migliore per trasferimenti più veloci. Semplice da implementare; non sono necessari gateway. | Traffico non crittografato; nessun isolamento o crittografia all'esterno dello stack. | Distribuzioni aziendali in cui tutti i tenant vengono ugualmente considerati attendibili. Aziende che hanno un circuito Azure ExpressRoute verso Azure. |
| Hub di Azure Stack multi-tenant, distribuzione Intranet | VPN da sito a sito | Il traffico dalla rete virtuale del tenant alla destinazione è protetto. | 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 parte del traffico di un tenant deve essere protetto da altri tenant. |
| Hub di Azure Stack a tenant singolo, distribuzione Internet | NAT in uscita | Larghezza di banda migliore per trasferimenti più veloci. | Traffico non crittografato; nessun isolamento o crittografia all'esterno dello stack. | Scenari di hosting in cui il tenant ottiene una propria distribuzione dell'hub di Azure Stack e un circuito dedicato per l'ambiente dell'hub di Azure Stack. Ad esempio, ExpressRoute e MPLS (Multiprotocol Label Switching). |
| Hub di Azure Stack a multi-tenant, distribuzione Internet | VPN da sito a sito | Il traffico dalla rete virtuale del tenant alla destinazione è protetto. | 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, i tenant non si considerano reciprocamente 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 con provisioning tramite un provider di connettività.
Il diagramma seguente mostra ExpressRoute per uno scenario a tenant singolo (dove la connessione del cliente è il circuito ExpressRoute).
Il diagramma seguente mostra ExpressRoute per uno scenario multi-tenant.
Monitoraggio esterno
Per ottenere una sola visualizzazione di tutti gli avvisi dalla distribuzione e dai dispositivi dell'hub di Azure Stack e per integrare gli avvisi nei flussi di lavoro di gestione dei servizi IT esistenti per il ticketing, è possibile integrare l'hub di Azure Stack con soluzioni di monitoraggio del data center esterno.
Incluso nella soluzione dell'hub di Azure Stack, l'host del ciclo di vita hardware è un computer esterno all'hub di Azure Stack che esegue gli strumenti di gestione offerti 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 offre un elenco di riepilogo delle opzioni attualmente disponibili.
| Area | Soluzione di monitoraggio esterna |
|---|---|
| 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 - Management Pack dei fornitori di Operations Manager Soluzione fornita dal fornitore hardware OEM Plug-in nagios del fornitore hardware. Soluzione di monitoraggio supportata dal partner OEM (inclusa) |
| Dispositivi di rete (SNMP) | Individuazione dei dispositivi di rete di Operations Manager Soluzione fornita dal fornitore hardware OEM Plug-in del commutatore Nagios |
| Monitoraggio dello stato della sottoscrizione del tenant | Management Pack di System Center per Microsoft Azure |
Tenere presenti 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 hub di Azure Stack sottostante che ospita le macchine virtuali IaaS e i servizi PaaS e per le app e i dati del tenant. Pianificare separatamente questi aspetti.
Proteggere i componenti dell'infrastruttura
È possibile eseguire il backup dei componenti dell'infrastruttura dell'hub di Azure Stack in una condivisione SMB 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 di commutatori di rete e l'host del ciclo di vita dell'hardware. Il fornitore dell'hardware OEM aiuterà a fornire indicazioni per il backup e il ripristino di questi componenti perché questi sono esterni all'hub di Azure Stack. È responsabile dell'esecuzione dei flussi di lavoro di backup in base alla raccomandazione del fornitore OEM.
Se si verifica una perdita di dati irreversibile, è possibile usare il backup dell'infrastruttura per eseguire il ripristino dei dati di distribuzione, ad esempio:
- Input e identificatori di distribuzione
- Account di servizio
- Certificato radice della CA
- Risorse federate (in distribuzioni disconnesse)
- Piani, offerte, sottoscrizioni e quote
- Criteri di controllo degli accessi in base al ruolo e assegnazioni di ruolo
- Segreti Key Vault
Avviso
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.
È consigliabilecreare account CloudAdmin aggiuntivi, per evitare la ridistribuzione del timbro a spese proprie. 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 del tenant. È necessario pianificare la protezione del backup e del ripristino di emergenza in una destinazione esterna all'hub di Azure Stack. La protezione del tenant è un'attività basata su tenant. Per le macchine virtuali IaaS, i tenant possono usare tecnologie guest per proteggere cartelle file, dati delle app e stato del sistema. Tuttavia, come provider di servizi o aziendali, è possibile offrire una soluzione di backup e ripristino nello stesso data center o esternamente in un cloud.
Per eseguire il backup di macchine virtuali Linux o Windows IaaS, è necessario usare i prodotti di backup con accesso al sistema operativo guest per proteggere file, cartelle, stato del sistema operativo e dati dell'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 delle applicazioni se si verifica un'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.
Altre informazioni
- Per informazioni sui casi d'uso, l'acquisto, i partner e i fornitori di hardware OEM, vedere la pagina del prodotto hub di Azure Stack .
- 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: estensione di Azure.