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 di pianificazione relative alla distribuzione e al 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 le interruzioni dei carichi di lavoro del tenant.

Il foglio di calcolo 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 è destinato a fungere da sostituto dell'indagine e dell'analisi. Microsoft non rilascia rappresentazioni o garanzie, esplicite o implicite, rispetto alle informazioni fornite all'interno del 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, Azure AD o AD FS. Non è possibile cambiare provider di identità dopo la distribuzione senza ridistribuzione completa del sistema. Se non si possiede l'account Azure AD e si usa un account fornito dall'Cloud Solution Provider e se si decide di cambiare provider e usare un account Azure AD 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. Queste cose sono separate.

È possibile distribuire più sistemi hub di Azure Stack con lo stesso tenant Azure Active Directory 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 Active Directory esistente. Questa integrazione consente di gestire Role-Based Controllo di accesso (RBAC) nell'hub di Azure Stack. Quando si accede a una risorsa viene delegato, il componente Graph cerca l'account utente nella foresta Active Directory esistente usando il protocollo LDAP.

Il diagramma seguente illustra l'integrazione di AD FS e il flusso di traffico Graph.

Diagram showing AD FS and Graph traffic flow

Modello di licenza

È necessario decidere quale modello di licenza usare. Le opzioni disponibili dipendono da se si distribuisce l'hub di Azure Stack connesso 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 per segnalare l'utilizzo, che viene quindi fatturato tramite il commercio di Azure.
  • Solo le licenze basate sulla capacità sono supportate se si distribuisce disconnessa da Internet.

Per altre informazioni sui modelli di licenza, vedere Microsoft Azure pacchetti e prezzi dell'hub 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 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.

La tabella seguente riepiloga queste decisioni di denominazione del dominio.

Nome 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 Nome della zona DNS (Domain Name System) per gli endpoint con indirizzi VIP esterni. Usato nel nome di dominio completo per questi INDIRIZZI VIP 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 per i certificati

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

  • È possibile usare un singolo 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 attendibile pubblica (CA) 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 linee guida generali. Prima di acquisire tutti i certificati PKI per l'hub di Azure Stack, usare il partner hardware OEM. Verranno fornite indicazioni e requisiti di certificato più dettagliati.

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.

Connessione hub di Azure Stack in 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: 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 su 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. Ogni rete virtuale creata nell'hub di Azure Stack ottiene un indirizzo IP pubblico assegnato. 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à distribuito. È necessario valutare se è necessario isolare il traffico di rete per tenant e se si avrà una distribuzione Intranet o Internet.

  • Hub Azure Stack a tenant singolo: una distribuzione dell'hub di Azure Stack che esamina almeno da un punto di vista di rete, come se si tratta di un tenant. Esistono molte sottoscrizioni tenant, ma come qualsiasi servizio Intranet, tutti i viaggi del traffico sulle stesse reti. Il traffico di rete da una sottoscrizione passa alla 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 ogni sottoscrizione tenant associato alle 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 si trova in una intranet aziendale, in genere nello spazio indirizzi IP privato e dietro uno o più firewall. Gli indirizzi IP pubblici non sono veramente pubblici perché non possono essere indirizzati direttamente tramite Internet pubblico.

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

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

Scenario Metodo Di connettività Vantaggi Svantaggi Buono per
Hub azure Stack singolo, distribuzione intranet NAT in uscita Larghezza di banda migliore per i trasferimenti più veloci. Semplice da implementare; non sono necessari gateway. Traffico non crittografato; nessun isolamento o crittografia all'esterno dello stack. Enterprise distribuzioni in cui tutti i tenant sono altrettanto attendibili.

Aziende che dispongono di un circuito Azure ExpressRoute in Azure.
Hub di Azure Stack multi-tenant, distribuzione intranet VPN da sito a sito Il traffico dalla rete virtuale 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.
Enterprise distribuzioni in cui è necessario proteggere un traffico tenant da altri tenant.
Hub azure Stack singolo, distribuzione Internet NAT in uscita Larghezza di banda migliore per i trasferimenti più veloci. Traffico non crittografato; nessun isolamento o crittografia all'esterno dello stack. Scenari di hosting in cui il tenant ottiene la distribuzione dell'hub di Azure Stack e un circuito dedicato all'ambiente hub di Azure Stack. Ad esempio, ExpressRoute e Multiprotocol Label Switching (MPLS).
Hub azure Stack multi-tenant, distribuzione Internet VPN da sito a sito Il traffico dalla rete virtuale 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 fidano e il traffico devono essere crittografati.

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 illustra ExpressRoute per uno scenario a tenant singolo (dove la connessione del cliente è il circuito ExpressRoute).

Diagram showing single-tenant ExpressRoute scenario

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

Diagram showing multi-tenant ExpressRoute scenario

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 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 dal fornitore 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 - Management Pack dei fornitori di Operations Manager
Soluzione fornita dal fornitore di hardware OEM
Plug-in del fornitore hardware Nagios.
Soluzione di monitoraggio supportata dal 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 tenant Management Pack System Center per Windows 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 queste cose separatamente.

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 su 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 (nelle 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 dell'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 dell'applicazione se si verifica un'emergenza, è possibile usare prodotti di terze parti o Site Recovery di Azure supportati. Inoltre, le app che supportano la replica nativa, ad esempio 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.

Passaggi successivi

Modelli di connessione all'hub di Azure Stack