Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
A partire da HPC Pack 2008 R2 con Service Pack 1, gli amministratori e gli sviluppatori di cluster WINDOWS HPC possono aumentare la potenza del cluster locale aggiungendo risorse di calcolo su richiesta in Azure. Questo scenario di "burst" del cluster HPC con istanze del ruolo di lavoro di Azure consente carichi di lavoro HPC di dimensioni maggiori, a volte che richiedono migliaia di core oltre o al posto di risorse del cluster locali. Questo argomento fornisce indicazioni e procedure consigliate per facilitare la pianificazione e l'implementazione di una distribuzione di grandi dimensioni di nodi di Azure da un cluster HPC Pack locale. Queste procedure consigliate devono contribuire a ridurre al minimo l'occorrenza dei timeout della distribuzione di Azure, degli errori di distribuzione e della perdita di istanze attive.
Nota
- Queste procedure consigliate includono raccomandazioni sia per l'ambiente di Azure che per la configurazione del nodo head locale. La maggior parte delle raccomandazioni migliorerà anche il comportamento delle distribuzioni più piccole dei nodi di Azure. Le eccezioni a queste linee guida sono distribuzioni di test in cui le prestazioni e l'affidabilità dei servizi nodo head potrebbero non essere critiche e molto piccole distribuzioni, in cui i servizi del nodo head non saranno fortemente stressati.
- Molte delle considerazioni per la configurazione di un nodo head locale per una distribuzione di Azure di grandi dimensioni si applicano anche ai cluster che contengono un numero comparabilmente elevato di nodi di calcolo locali.
- Queste raccomandazioni integrano il cluster, la rete e altri requisiti per aggiungere nodi di Azure a un cluster HPC Windows. Per altre informazioni, vedere Requisiti di per i nodi di Azure.
- Queste raccomandazioni generali possono cambiare nel tempo e potrebbero dover essere modificate per i carichi di lavoro HPC.
Versioni applicabili di HPC Pack e Azure SDK per .NET
Queste raccomandazioni sono in genere basate su HPC Pack 2012 R2 e HPC Pack 2012, ma sono utili anche per distribuzioni di grandi dimensioni eseguite con HPC Pack 2008 R2.
La tabella seguente elenca le versioni di HPC Pack e le versioni correlate di Azure SDK per .NET a cui si applicano queste linee guida.
| HPC Pack | Azure SDK |
|---|---|
| HPC Pack 2012 R2 | Azure SDK per .NET 2.2 |
| HPC Pack 2012 con Service Pack 1 (SP1) | Azure SDK per .NET 2.0 |
| HPC Pack 2012 | Azure SDK per .NET 1.8 |
| HPC Pack 2008 R2 con Service Pack 4 (SP4) | Azure SDK per .NET 1.7 |
| HPC Pack 2008 R2 con Service Pack 3 (SP3) | Azure SDK per .NET 1.6 |
Soglie per distribuzioni di grandi dimensioni di nodi di Azure
Una distribuzione di nodi di Azure per un cluster HPC viene considerata "grande" quando diventa necessario prendere in considerazione la configurazione del nodo head e quando la distribuzione richiederà una percentuale significativa del cluster di risorse di Azure che potrebbe essere usata da un singolo servizio cloud. Una distribuzione più grande rischierebbe i timeout della distribuzione e la perdita di istanze attive.
Importante
Ogni sottoscrizione di Azure viene allocata una quota di core e altre risorse, che influisce anche sulla possibilità di distribuire un numero elevato di nodi di Azure. Per poter distribuire un numero elevato di nodi di Azure, potrebbe essere necessario contattare il supporto tecnico Microsoft per richiedere un aumento della quota di core per la sottoscrizione. Si noti che una quota è un limite di credito, non una garanzia di disponibilità delle risorse.
La tabella seguente elenca i numeri di soglia pratici delle istanze del ruolo comunemente usate per una distribuzione di grandi dimensioni dei nodi di Azure in un singolo servizio cloud. La soglia dipende dalle dimensioni della macchina virtuale (predefinite in Azure) scelte per le istanze del ruolo di Azure.
| Dimensioni dell'istanza del ruolo | Numero di istanze del ruolo |
|---|---|
| A9 (supportato a partire da HPC Pack 2012 R2) | 125 |
| A8 (supportato a partire da HPC Pack 2012 R2) | 250 |
| A7 (supportato a partire da HPC Pack 2012 con SP1) | 250 |
| A6 (supportato a partire da HPC Pack 2012 con SP1) | 250 |
| Extra Large | 250 |
| Grande | 500 |
| Medio | 800 |
| Piccola | 1000 |
Per informazioni dettagliate sulle dimensioni di ogni macchina virtuale, incluso il numero di core CPU e memoria per ogni dimensione, vedere dimensioni per i servizi cloud.
Per distribuire più di questi numeri di soglia di istanze del ruolo in un servizio con affidabilità elevata richiede in genere il coinvolgimento manuale del team operativo di Azure. Per avviare questa operazione, contattare il rappresentante microsoft, il responsabile dell'account del supporto tecnico Microsoft Premier o il supporto tecnico Microsoft. Per altre informazioni su piani di supporto, vedere Piani di supporto per Azure.
Anche se non esiste un limite rigido e applicabile a tutte le distribuzioni di nodi di Azure, 1000 istanze per ogni servizio cloud è un limite pratico per la produzione.
Procedure consigliate per l'uso di Azure per distribuzioni di grandi dimensioni
Di seguito sono riportate le linee guida generali per creare e usare correttamente distribuzioni di Azure di grandi dimensioni con il cluster HPC.
Fornire segnali iniziali al team operativo di Azure
A meno che non siano state prese disposizioni per la distribuzione in un cluster di Azure dedicato in un data center, la raccomandazione più importante consiste nel comunicare la necessità al team operativo di Azure (tramite un canale di supporto Microsoft) di una grande quantità di capacità in anticipo e di pianificare le distribuzioni di conseguenza per eliminare la capacità come collo di bottiglia. Si tratta anche di un'opportunità per ottenere indicazioni aggiuntive sulle strategie di distribuzione oltre quelle descritte in questo argomento.
Distribuire le distribuzioni in più servizi cloud
È consigliabile suddividere le distribuzioni di grandi dimensioni in diverse distribuzioni di dimensioni minori, usando più servizi cloud, per i motivi seguenti:
Per consentire flessibilità nell'avvio e nell'arresto di gruppi di nodi.
Per rendere possibile l'arresto delle istanze inattive al termine dei processi.
Per facilitare la ricerca di nodi disponibili nei cluster di Azure, in particolare quando vengono usate istanze Extra Large.
Per abilitare l'uso di più data center di Azure per scenari di ripristino di emergenza o di continuità aziendale.
Non esiste alcun limite fisso per le dimensioni di un servizio cloud, ma le indicazioni generali sono inferiori a 500-700 istanze di macchine virtuali o meno di 1000 core. Le distribuzioni di grandi dimensioni rischierebbero i timeout della distribuzione, la perdita di istanze attive e i problemi con lo scambio di indirizzi IP virtuali.
Il numero massimo di servizi cloud testato per un singolo cluster HPC è 32.
Nota
È possibile riscontrare limitazioni nel numero di servizi cloud e istanze del ruolo che è possibile gestire tramite HPC Pack o il portale di gestione di Azure.
Essere flessibile con la posizione
La presenza di dipendenze da altri servizi e altri requisiti geografici può essere inevitabile, ma può essere utile se la distribuzione di Azure non è associata a un'area o a un'area geografica specifica. Tuttavia, non è consigliabile inserire più distribuzioni in aree geografiche diverse, a meno che non abbiano dipendenze esterne in tali aree geografiche o a meno che non si disponga di requisiti di disponibilità elevata e ripristino di emergenza.
Flessibilità con le dimensioni della macchina virtuale
La presenza di dipendenze rigorose da una determinata dimensione di macchina virtuale (ad esempio, Extra Large) può influire sul successo delle distribuzioni su larga scala. La flessibilità necessaria per regolare o persino combinare le dimensioni delle macchine virtuali per bilanciare i conteggi delle istanze e i core può essere utile.
Usare più account di archiviazione di Azure per le distribuzioni di nodi
È consigliabile usare account di archiviazione di Azure diversi per distribuzioni simultanee di nodi di Azure di grandi dimensioni e per applicazioni personalizzate. Per determinate applicazioni vincolate dall'I/O, usare diversi account di archiviazione. Inoltre, come procedura consigliata, un account di archiviazione usato per una distribuzione di nodi di Azure non deve essere usato per scopi diversi dal provisioning dei nodi. Ad esempio, se si prevede di usare l'archiviazione di Azure per spostare i dati di processi e attività da e verso il nodo head o da e verso i nodi di Azure, configurare un account di archiviazione separato a tale scopo.
Nota
Vengono addebitati addebiti per la quantità totale di dati archiviati e per le transazioni di archiviazione negli account di archiviazione di Azure, indipendentemente dal numero di account di archiviazione di Azure. Tuttavia, ogni sottoscrizione limiterà il numero totale di account di archiviazione. Se sono necessari account di archiviazione aggiuntivi nella sottoscrizione, contattare il supporto tecnico di Azure.
Modificare il numero di istanze del nodo proxy per supportare la distribuzione
I nodi proxy sono istanze del ruolo di lavoro di Azure aggiunte automaticamente a ogni distribuzione di nodi di Azure da un cluster HPC per facilitare la comunicazione tra i nodi head locali e i nodi di Azure. La richiesta di risorse nei nodi proxy dipende dal numero di nodi distribuiti in Azure e dai processi in esecuzione in tali nodi. In genere è consigliabile aumentare il numero di nodi proxy in una distribuzione di Azure di grandi dimensioni.
Nota
- Le istanze del ruolo proxy comportano addebiti in Azure insieme alle istanze del nodo di Azure.
- Le istanze del ruolo proxy usano core allocati alla sottoscrizione e riducono il numero di core disponibili per distribuire i nodi di Azure.
HPC Pack 2012 ha introdotto gli strumenti di gestione HPC per configurare il numero di nodi proxy in ogni distribuzione del nodo di Azure (servizio cloud). In HPC Pack 2008 R2 il numero viene impostato automaticamente su 2 nodi proxy per distribuzione. Il numero di istanze del ruolo per i nodi proxy può anche essere ridimensionato verso l'alto o verso il basso usando gli strumenti nel portale di gestione di Azure, senza ridistribuire i nodi. Il numero massimo consigliato di nodi proxy per una singola distribuzione è 10.
Le distribuzioni di dimensioni maggiori o molto usate possono richiedere più del numero di nodi proxy elencati nella tabella seguente, che si basa su un utilizzo della CPU inferiore al 50% e la larghezza di banda inferiore alla quota.
| Nodi di Azure per servizio cloud | Numero di nodi proxy |
|---|---|
| <100 | 2 |
| 100 - 400 | 3 |
| 400 - 800 | 4 |
| 800 - 1000 | 5 |
Per altre informazioni sulle opzioni di configurazione del nodo proxy, vedere Impostare il numero di nodi proxy di Azure.
Procedure consigliate per configurare il nodo head per distribuzioni di grandi dimensioni
Le distribuzioni di grandi dimensioni dei nodi di Azure possono porre richieste significative al nodo head (o ai nodi head) di un cluster. Il nodo head esegue diverse attività per supportare la distribuzione:
Accede alle istanze del nodo proxy create in una distribuzione di Azure per facilitare la comunicazione con i nodi di Azure. Vedere Modificare il numero di istanze del nodo proxy per supportare la distribuzione, in questo argomento.
Accede agli account di archiviazione di Azure per BLOB (ad esempio pacchetti di runtime), code e dati di tabella.
Gestisce l'intervallo di heartbeat e le risposte, il numero di proxy (a partire da HPC Pack 2012), il numero di distribuzioni e il numero di nodi.
Man mano che le distribuzioni di Azure aumentano di dimensioni e velocità effettiva, aumenta lo stress del nodo head del cluster HPC. In generale, gli elementi chiave necessari per garantire che il nodo head possa supportare la distribuzione sono:
RAM sufficiente
Spazio su disco sufficiente
Un database SQL Server ben ridimensionato e ben gestito per i database del cluster HPC
Specifiche hardware per il nodo head
Di seguito sono riportate le specifiche minime consigliate per un nodo head per supportare una distribuzione di Azure di grandi dimensioni:
8 core CPU
2 dischi
16 GB di RAM
Configurare i database di SQL Server remoti
Per le distribuzioni di grandi dimensioni, è consigliabile installare i database del cluster in un server remoto che esegue Microsoft SQL Server, anziché installare i database del cluster nel nodo head. Per linee guida generali su come selezionare e configurare un'edizione di SQL Server per il cluster, vedere Pianificazione e ottimizzazione della capacità del database per Microsoft HPC Pack.
Non configurare il nodo head per ruoli del cluster aggiuntivi
Come procedura consigliata generale per la maggior parte delle distribuzioni di produzione, è consigliabile che i nodi head non siano configurati con un ruolo del cluster aggiuntivo (ruolo del nodo di calcolo o del nodo broker WCF). La disponibilità del nodo head serve più di uno scopo può impedire la corretta esecuzione del ruolo di gestione principale. Per modificare i ruoli eseguiti dal nodo head, prima di tutto portare offline il nodo usando l'azione in gestione risorse (denominata Node Management in alcune versioni di HPC Pack) in HPC Cluster Manager. Fare quindi clic con il pulsante destro del mouse sul nodo head e scegliere Modifica ruolo.
Inoltre, lo spostamento dello spazio di archiviazione del cluster all'esterno del nodo head garantisce che il nodo head non esaurisca lo spazio e funzioni in modo efficace.
Usare le utilità client HPC per connettersi in remoto al nodo head
Quando il nodo head funziona con un carico elevato, le prestazioni possono essere influenzate negativamente dalla presenza di molti utenti connessi con connessioni Desktop remoto. Anziché fare in modo che gli utenti si connettano al nodo head usando Servizi Desktop remoto (RDS), gli utenti e gli amministratori devono installare le utilità client HPC Pack nelle workstation e accedere al cluster usando questi strumenti remoti.
Disabilitare la raccolta dei contatori delle prestazioni e l'inoltro degli eventi
Per distribuzioni di grandi dimensioni, la raccolta dei contatori delle prestazioni e l'inoltro degli eventi possono comportare un notevole carico sul servizio di gestione HPC e SQL Server. Per queste distribuzioni, potrebbe essere consigliabile disabilitare queste funzionalità usando gli strumenti di gestione del cluster HPC. Ad esempio, impostare la proprietà cluster
Disabilitare i servizi dei nodi head non usati
Per garantire un footprint hardware minimo dal sistema operativo e come procedura consigliata generale del cluster HPC, disabilitare tutti i servizi del sistema operativo non necessari per il funzionamento del cluster HPC. È consigliabile disabilitare le funzionalità orientate al desktop che potrebbero essere state abilitate.
Non eseguire NAT nel nodo head
Anche se HPC Pack consente una configurazione rapida del servizio Routing e Accesso remoto (RRAS) in esecuzione nel nodo head per fornire NAT (Network Address Translation) e consentire ai nodi di calcolo di raggiungere la rete aziendale, questo può rendere il nodo head un collo di bottiglia significativo per la larghezza di banda di rete e può anche influire sulle prestazioni. Come procedura consigliata generale per distribuzioni o distribuzioni di grandi dimensioni con traffico significativo tra i nodi di calcolo e la rete pubblica, è consigliabile usare una delle alternative seguenti:
Fornire una connessione di rete pubblica diretta a ogni nodo di calcolo.
Fornire un router NAT dedicato, ad esempio un server separato che esegue un sistema operativo Windows Server e che è dual homed nelle due reti e che esegue RRAS.
Garantire un periodo ragionevole di archiviazione per i processi completati
La proprietà TtlCompletedJobs
Configurare un numero ragionevole di heartbeat mancanti prima di contrassegnare i nodi non raggiungibili
HPC Pack usa un segnale heartbeat per verificare la disponibilità dei nodi. La mancanza di risposta di un nodo di calcolo a questo probe di integrità periodico da parte del servizio utilità di pianificazione processi HPC determina se il nodo verrà contrassegnato come non raggiungibile. Configurando le opzioni heartbeat in Configurazione dell'utilità di pianificazione processi in Gestione cluster HPC, oppure usando il comando cluscfg o il Set-HpcClusterProperty cmdlet HPC, l'amministratore del cluster può impostare la frequenza degli heartbeat (HeartbeatInterval) e il numero di heartbeat che un nodo può perdere (InactivityCount) prima che venga contrassegnato come non raggiungibile. Ad esempio, il valore predefinito HeartbeatInterval di 30 secondi può essere aumentato a 2 minuti quando il cluster include una distribuzione di Azure di grandi dimensioni. Il valore predefinito InactivityCount è impostato su 3, adatto per alcune distribuzioni locali, ma deve essere aumentato a 10 o più quando i nodi di Azure vengono distribuiti.
Nota
A partire da HPC Pack 2012 con SP1, il numero di heartbeat persi viene configurato separatamente per i nodi locali e i nodi di Azure. La proprietà del cluster InactivityCountAzure configura il numero di heartbeat mancanti dopo i quali i nodi di lavoro distribuiti in Azure sono considerati non raggiungibili dal cluster. Il valore predefinito di InactivityCountAzure è impostato su 10. A partire da HPC Pack 2012 con SP1, la proprietà InactivityCount si applica esclusivamente ai nodi locali.
Se il nodo head o i nodi broker WCF sono configurati per la disponibilità elevata in un cluster di failover, è consigliabile prendere in considerazione anche il segnale heartbeat usato da ogni computer del cluster di failover per monitorare la disponibilità degli altri computer (o computer) nel cluster di failover. Per impostazione predefinita, se un computer perde cinque heartbeat, una volta al secondo, la comunicazione con tale computer viene considerata non riuscita. È possibile usare Gestione cluster di failover per ridurre la frequenza degli heartbeat o aumentare il numero di heartbeat mancanti in un cluster con una distribuzione di Azure di grandi dimensioni.
Se si eseguono processi SOA (Service-Oriented Architecture) nei nodi di Azure, potrebbe essere necessario modificare le impostazioni di timeout di monitoraggio nel file di registrazione del servizio per gestire sessioni di grandi dimensioni. Per altre informazioni sul file di configurazione del servizio SOA, vedere file di configurazione del servizio SOA in Windows HPC Server 2008 R2.
Configurare una chiave del Registro di sistema per migliorare le prestazioni delle operazioni di gestione temporanea dei file
A partire da HPC Pack 2008 R2 con SP2, è possibile impostare una chiave del Registro di sistema nel computer del nodo head per migliorare le prestazioni dei test di diagnostica, clusrun operazioni e l'utilità hpcfile in distribuzioni di azure di grandi dimensioni. A tale scopo, aggiungere un nuovo valore DWORD denominato FileStagingMaxConcurrentCalls in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HPC. È consigliabile configurare un valore compreso tra 50% e 100% del numero di nodi di Azure che si prevede di distribuire. Per completare la configurazione, dopo aver impostato il valore FileStagingMaxConcurrentCalls, è necessario arrestare e quindi riavviare il servizio utilità di pianificazione processi HPC.
Attenzione
La modifica errata del Registro di sistema può danneggiare gravemente il sistema. Prima di apportare modifiche al Registro di sistema, è necessario eseguire il backup di tutti i dati con valori nel computer.
Vedi anche
burst in istanze di lavoro di Azure con Microsoft HPC Pack
procedure consigliate per la progettazione di servizi Large-Scale in Servizi cloud di Azure
guida tecnica per la continuità aziendale di Windows Azure