Condividi tramite


Passaggio 1: Preparare la distribuzione

Il primo passaggio della distribuzione del cluster HPC consiste nel prendere decisioni importanti, ad esempio decidere il numero di nodi head e scegliere una topologia di rete per il cluster. Le attività seguenti consentono di prepararsi per la distribuzione del cluster.

1.1: Esaminare i requisiti di sistema

Se non è già stato fatto, esaminare i requisiti di sistema per Microsoft HPC Pack 2016. Si noti che HPC Pack ha requisiti diversi per i diversi ruoli del nodo e opzioni di distribuzione. Potrebbe essere necessario rivedere di nuovo i requisiti di sistema, dopo aver finalizzato le decisioni per la distribuzione.

1.2: Decidere se si vuole configurare il nodo head per la disponibilità elevata

Se è necessario continuare a eseguire processi HPC durante un'interruzione pianificata o non pianificata nei servizi in un computer nodo head, è possibile pianificare la configurazione del nodo head per la disponibilità elevata in un cluster di Service Fabric. A tale scopo, sarà necessario installare HPC Pack in tre computer del nodo head configurati in un cluster di Service Fabric.

1.3: Decidere se si vuole distribuire il cluster con database remoti

HPC Pack 2016 richiede e supporta Microsoft SQL Server 2012 o una versione successiva. HPC Pack usa cinque database di SQL Server diversi per archiviare la gestione del cluster, la pianificazione dei processi, la creazione di report, la diagnostica e i dati di monitoraggio. È possibile installare uno o più di questi cinque database HPC in uno o più server remoti anziché installarli nel nodo head del cluster. Per impostazione predefinita, HPC Pack installa SQL Server Express 2016 nel nodo head e crea i database HPC nel nodo head se si sceglie un singolo nodo head. Se si sceglie di distribuire tre nodi head, il vantaggio dell'installazione dei database HPC in uno o più server remoti consiste nel salvare le risorse nel nodo head, assicurandosi di poter gestire in modo efficiente il cluster.

Importante

L'uso di SQL Server 2016 Express nel nodo head è consigliato per i cluster di verifica o di sviluppo e per i cluster di produzione più piccoli. È consigliabile installare i database HPC in uno o più server remoti se il cluster avrà più di 256 nodi, si prevede di configurare il nodo head per la disponibilità elevata oppure la velocità effettiva del processo e i requisiti di creazione di report potrebbero superare le funzionalità di SQL Server 2016 Express.

Per installare i database HPC in un server remoto, è necessario che il server esegua l'edizione Standard o Enterprise di SQL Server 2008 R2 o versione successiva e sia configurato per l'uso con HPC Pack. Prima di installare HPC Pack con database remoti, chiedere all'amministratore del database di eseguire lo script di SetupHpcDatabase.ps1 nella cartella di installazione o di eseguire manualmente o modificare le attività nello script. Lo script crea automaticamente i database necessari e gli account di accesso e gli utenti del database SQL per l'account che installerà HPC Pack e per l'account computer per i servizi HPC. Per informazioni dettagliate, vedere Deploying a Windows HPC Cluster with Remote Databases Step-by-Step Guide (Guida dettagliata alla distribuzione di un cluster HPC Windows con database remoti).

1.4: Decidere il tipo di nodi da aggiungere al cluster e quanti

È possibile aggiungere i tipi di nodi seguenti al cluster locale:

  • nodi di calcolo: i nodi di calcolo vengono usati per l'esecuzione di processi. Questo tipo di nodo non può diventare un tipo diverso di nodo ( ovvero modificare i ruoli) senza essere ridistribuito.
  • nodi broker : i nodi broker di Windows Communication Foundation (WCF) vengono usati per il routing delle chiamate WCF dai client SOA (Service-Oriented Architecture) ai servizi SOA in esecuzione nei nodi del cluster. Questo tipo di nodo può modificare i ruoli in modo che diventino un nodo di calcolo senza essere ridistribuiti.
  • nodi workstation e nodi server non gestiti: i nodi workstation e i nodi server non gestiti sono computer dell'organizzazione che possono anche eseguire processi, ma non sono risorse cluster dedicate. Possono essere pianificati per diventare disponibili per l'esecuzione di processi in momenti specifici o possono essere resi disponibili su richiesta. Questo tipo di nodo non può modificare i ruoli.
  • nodi di Microsoft Azure: se si ha una sottoscrizione di Microsoft Azure, è possibile aggiungere nodi di Azure su richiesta per aumentare la capacità del cluster quando necessario. Come i nodi di calcolo, i nodi della workstation e i nodi del server non gestiti, i nodi di Azure possono eseguire processi. Quando si aggiungono nodi di Azure, si configura anche un numero fisso o variabile di nodi proxy nella distribuzione di Azure per facilitare la comunicazione tra il nodo head locale e i nodi di Azure.
  • nodi IaaS di Microsoft Azure: se si dispone di una sottoscrizione di Microsoft Azure, è possibile aggiungere nodi IaaS di Microsoft Azure su richiesta per aumentare la capacità del cluster quando necessario.

Per altre informazioni sui ruoli dei nodi in un cluster WINDOWS HPC, vedere Understanding Node Roles in Microsoft HPC Pack.

Quando HPC Pack è installato, a seconda del tipo di nodo che viene creato, vengono installate funzionalità diverse. Queste funzionalità determinano il ruolo che il nodo eseguirà nel cluster. In alcuni casi, un nodo è in grado di modificare i ruoli perché dispone delle funzionalità necessarie per eseguire un ruolo diverso. La possibilità di modificare i ruoli è un aspetto importante da considerare quando si decide il tipo di nodi da aggiungere al cluster.

Un'altra decisione importante da prendere è il numero di nodi da aggiungere. Se si aggiungono nodi broker, è anche necessario decidere il numero di nodi di calcolo che verranno aggiunti per ogni nodo broker disponibile nel cluster. Il rapporto tra nodi broker e nodi di calcolo può influire sulle prestazioni del cluster.

Se si prevede di aggiungere nodi di Azure, è consigliabile considerare il numero di nodi proxy ottimali per il numero di nodi distribuiti in Azure e i processi che verranno eseguiti in tali nodi. I nodi proxy sono necessari per la comunicazione con il nodo head locale e possono essere un collo di bottiglia per determinate dimensioni e carichi di lavoro del cluster.

Infine, se si vuole configurare il nodo head o un nodo broker in un cluster di failover, è necessario un computer aggiuntivo per ogni nodo del cluster di failover configurato, che potrebbe ridurre il numero di nodi di calcolo che è possibile aggiungere al cluster.

1.5: Scegliere il dominio di Active Directory per il cluster

HPC Pack 2016 introduce una nuova funzionalità che HPC Pack può essere installata in un computer che non è aggiunto a un dominio. Questa nuova funzionalità è progettata per i cluster HPC in Azure. Per un cluster HPC locale, è necessario creare il cluster in un dominio di Active Directory.

I nodi nel cluster HPC locale saranno membri di un dominio di Active Directory. Prima di distribuire il cluster locale, scegliere il dominio di Active Directory che verrà usato per il cluster HPC.

A seconda dell'ambiente Active Directory nell'organizzazione, può essere utile configurare un'unità organizzativa separata per i computer che saranno membri del cluster HPC. Con un'unità organizzativa separata, se necessario, è possibile applicare criteri e impostazioni diversi ai nodi del cluster rispetto agli altri computer dell'organizzazione.

Se non si dispone di un dominio di Active Directory a cui è possibile aggiungere il cluster o se si preferisce non aggiungere un dominio esistente, è possibile creare un nuovo dominio di Active Directory. Per altre informazioni sull'installazione del ruolo Servizi di dominio Active Directory, vedere Deploying Active Directory Domain Services (AD DS) in Your Enterprise.

Considerazioni aggiuntive

  • Il nodo head HPC Pack 2016 non può essere installato in un controller di dominio se si prevede di installare un cluster a disponibilità elevata. Questo perché il nodo head HPC Pack viene eseguito nel contesto di un cluster di Service Fabric, che non può essere distribuito in un controller di dominio.

  • Se si prevede di aggiungere nodi workstation o nodi server non gestiti al cluster HPC, è possibile aggiungere tali computer a qualsiasi dominio di Active Directory con una relazione di trust stabilita con il dominio a cui viene aggiunto il nodo head.

1.6: Scegliere un account di dominio per l'aggiunta di nodi

Per installare HPC Pack nel nodo head, è necessario essere connessi con un account utente di dominio membro del gruppo Administrators nel computer del nodo head. Inoltre, durante il processo di configurazione del nodo head HPC dopo l'installazione di HPC Pack, è necessario specificare le credenziali per un account utente di dominio che verrà usato per aggiungere nodi locali e per la configurazione di sistema di tali nodi. È necessario scegliere un account esistente o creare un nuovo account prima di avviare la distribuzione del cluster.

Considerazioni sulla scelta di un account utente

  • L'account utente scelto deve essere un account di dominio con privilegi sufficienti per creare account computer di Active Directory per i nodi e aggiungere i nodi al dominio.
  • Se i criteri dell'organizzazione limitano l'uso di un account di dominio in grado di aggiungere nuovi computer al dominio, sarà necessario chiedere all'amministratore di dominio di pre-creare gli oggetti computer in Servizi di dominio Active Directory prima di distribuire i nodi. Per altre informazioni, vedere Deploy Nodes with Pre-created Computer Objects in Active Directory.
  • Se una parte della distribuzione richiede l'accesso alle risorse nella rete aziendale, l'account utente deve disporre delle autorizzazioni necessarie per accedere a tali risorse, ad esempio i file di installazione disponibili in un server di rete.
  • Se si desidera riavviare i nodi in modalità remota tramite Gestione cluster HPC, l'account deve essere membro del gruppo Administrators locale nel nodo head. Questo requisito è necessario solo se non si dispone di strumenti di controllo alimentazione con script che è possibile usare per riavviare in remoto i nodi.

1.7: Scegliere una topologia di rete per il cluster

HPC Pack supporta cinque topologie del cluster. Queste topologie sono distinte dal modo in cui i nodi del cluster sono connessi tra loro e alla rete aziendale. Le cinque topologie di cluster supportate sono:

  • Topologia 1: nodi di calcolo isolati in una rete privata
  • Topologia 2: tutti i nodi nelle reti aziendali e private
  • Topologia 3: Nodi di calcolo isolati nelle reti private e dell'applicazione
  • Topologia 4: tutti i nodi nelle reti aziendali, private e dell'applicazione
  • Topologia 5: Tutti i nodi in una rete aziendale

Per altre informazioni su ogni topologia di rete e su ogni rete cluster HPC, vedere Appendice 1: Rete cluster HPC, più avanti in questa guida.

Quando si sceglie una topologia di rete, è necessario prendere in considerazione l'infrastruttura di rete esistente e il tipo di nodi che verranno aggiunti al cluster:

  • Decidere quale rete nella topologia scelta verrà usata come rete aziendale, rete privata e rete dell'applicazione.
  • Non disporre della scheda di rete connessa alla rete aziendale nel nodo head nella configurazione automatica, ovvero l'indirizzo IP per tale scheda non inizia con: 169.254. Tale adattatore deve avere un indirizzo IP valido, assegnato dinamicamente o manualmente (statico).
  • Se si sceglie una topologia che include una rete privata e si prevede di aggiungere nodi al cluster da bare metal, eseguire le operazioni seguenti:
    • Assicurarsi che nella rete privata non siano presenti server PXE (Pre-Boot Execution Environment).
    • Se si vuole usare un server DHCP esistente per la rete privata, assicurarsi che sia configurato per riconoscere il nodo head come server PXE nella rete.
  • Se si vuole abilitare il server DHCP nel nodo head per le reti private o dell'applicazione e sono presenti altri server DHCP connessi a tali reti, è necessario disabilitare tali server DHCP.
  • Se si dispone di un server DNS (Domain Name System) esistente connesso alla stessa rete dei nodi del cluster, non è necessaria alcuna azione, ma i nodi verranno annullati automaticamente dalla registrazione da tale server DNS.
  • Contattare l'amministratore di sistema per determinare se la sicurezza del protocollo Internet (IPsec) viene applicata al dominio tramite Criteri di gruppo. Se IPsec viene applicato al dominio tramite Criteri di gruppo, è possibile che si verifichino problemi durante la distribuzione. Una soluzione alternativa consiste nel rendere il nodo head un server di limiti IPsec in modo che gli altri nodi del cluster possano comunicare con il nodo head durante l'avvio PXE.
  • Se si vogliono aggiungere nodi workstation o nodi server non gestiti al cluster, la topologia 5 (tutti i nodi in una rete aziendale) è la topologia consigliata, ma sono supportate altre topologie. Per aggiungere nodi workstation in altre topologie, vedere il contenuto in Aggiunta di nodi workstation a un cluster HPC Windows.
  • Se si desidera aggiungere nodi broker al cluster, devono essere connessi alla rete in cui i client che avviano sessioni SOA sono connessi (in genere la rete aziendale) e alla rete in cui sono connessi i nodi che eseguono i servizi SOA (se diversi dalla rete in cui sono connessi i client).
  • Se si vogliono aggiungere nodi di Azure al cluster, il cluster HPC può essere configurato in qualsiasi topologia di rete del cluster supportata da HPC Pack. Il nodo head e qualsiasi computer client usato per gestire il cluster e che richiede una connessione ad Azure deve essere in grado di connettersi tramite Internet ai servizi di Azure.

1.8: Preparare i certificati usati per proteggere la comunicazione tra nodi HPC

Il cluster Microsoft HPC Pack 2016 (e versioni successive) usa il certificato X.509 per proteggere la comunicazione tra i nodi HPC. È possibile usare uno stesso certificato in tutti i nodi HPC o usare due certificati diversi:

  • Certificato per il nodo head: questo certificato viene installato nel nodo head (o nodi head) per proteggere il cluster di Service Fabric e la comunicazione tra nodi HPC. Se il certificato è autofirmato, è anche necessario importarlo nel certificato di Azure Key Vault se si prevede di distribuire nodi di calcolo IaaS di Azure con burst in una macchina virtuale IaaS di Azure.
  • Certificato per altri nodi: questo certificato viene installato nei nodi HPC diversi dai nodi head (o nodi head) per proteggere la comunicazione tra nodi HPC. Se si sceglie di usare uno stesso certificato in tutti i nodi HPC, si tratta dello stesso certificato con Certificato per il nodo head.

I certificati devono soddisfare i requisiti seguenti:

  • Disporre di una chiave privata in grado di scambiare chiavi;
  • L'utilizzo delle chiavi include firma digitale, crittografia delle chiavi, contratto di chiave e firma del certificato ;
  • L'utilizzo avanzato delle chiavi include autenticazione client e autenticazione server ;
  • Se vengono usati due certificati diversi, devono avere un stesso nome soggetto.

Se il certificato viene usato per proteggere anche cluster di Service Fabric, deve soddisfare i requisiti aggiuntivi seguenti :

  1. Il provider del certificato deve essere Microsoft Enhanced RSA e AES Cryptographic Provider;
  2. La lunghezza della chiave RSA deve essere 2048 bit.

Se non si dispone già di certificati che soddisfano questi requisiti, è possibile richiedere i certificati da un'autorità di certificazione oppure usare certificati autofirmati. Viene fornito uno strumento di script di PowerShell CreateHpcCertificate.ps1 certificato nella cartella Setup del supporto di installazione di HPC Pack per generare un certificato autofirmato.

.\CreateHpcCertificate.ps1 -CommonName "HPCPackNodeCommunication" -Path "d:\hpccomm.pfx" -Password (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force)

Se si usa un certificato firmato dall'autorità di certificazione (CA) o un certificato autofirmato esistente, è possibile eseguire il comando seguente e controllare il valore di KeySpec, Subject, Key Usage, Enhanced Key Usage, Public Key Length, e provider .

CertUtil.exe -p "<password>" -v -dump <path-of-pfxFile>
  • Se il valore di Oggetto, Utilizzo chiavi, Utilizzo chiavi avanzato o lunghezza chiave pubblica non corrisponde, è necessario generare nuovamente il certificato.

  • Se il valore di KeySpec (deve essere "1 -- AT_KEYEXCHANGE") o Provider non corrisponde, Non è necessario generare nuovamente il certificato, eseguire il comando seguente per importare il certificato con modificati valori KeySpec e Provider e quindi eseguire certlm.msc per esportare il certificato (inclusa la chiave privata) in un nuovo file PFX che soddisfi i requisiti.

    CertUtil.exe -f -p "<password>" -csp "Microsoft Enhanced RSA and AES Cryptographic Provider" -importpfx "<path-of-pfxFile>" AT_KEYEXCHANGE
    

Se si è deciso di usare un singolo nodo head nel passaggio 1.2 e si vuole usare un certificato autofirmato, è anche possibile generare un certificato autofirmato nell'Installazione guidata durante l'installazione del nodo head.

Se si decide di usare un certificato autofirmato per altri nodi, è possibile generare un certificato autofirmato in Gestione cluster HPC in passaggio 3.4, più avanti in questa guida.

1.9: Preparare l'integrazione degli strumenti di controllo alimentazione con script (facoltativo)

La console di amministrazione del cluster (HPC Cluster Manager) include azioni per avviare, arrestare e riavviare i nodi in remoto. Queste azioni sono collegate a un file di script (CcpPower.cmd) che esegue queste operazioni di controllo dell'alimentazione usando i comandi del sistema operativo. È possibile sostituire i comandi predefiniti del sistema operativo in tale file di script con script di controllo dell'alimentazione personalizzati, ad esempio script IPMI (Intelligent Platform Management Interface) forniti dal fornitore di soluzioni cluster.

In preparazione a questa integrazione, è necessario ottenere tutti gli script necessari, .dll file e altri componenti degli strumenti di controllo alimentazione. Dopo aver ottenuto tutti i componenti necessari, testarli in modo indipendente e assicurarsi che funzionino come previsto nei computer che verranno distribuiti come nodi nel cluster.

Per informazioni sulla modifica di CcpPower.cmd per integrare i propri strumenti di controllo dell'alimentazione con script, vedere Appendice 5: Scripted Power Control Tools, più avanti in questa guida.

Passaggio successivo