RUOLI E CONFIGURAZIONI IN HPC

Innanzitutto, è bene chiarire la struttura delle macchine appartenenti al cluster HPC. Il ruolo di orchestrazione, comunicazione con i nodi di calcolo e distribuzione dell’esecuzione delle applicazioni è delegata a uno o più Head Node. Questi non hanno il compito di elaborazione della logica applicativa ma si occupano di operazioni di più alto livello: verificano lo stato di avanzamento dell’esecuzione, gestiscono il

cluster, monitorano lo stato di utilizzo, il bilanciamento del carico e il polling alle

istanze gestite. Solitamente, il numero di Head Node è molto contenuto e in stretto rapporto con il numero di nodi di calcolo. Questi ultimi prendono il nome di Compute Node: si tratta delle istanze che si occupano dell’effettivo carico di lavoro da eseguire. Il loro compito, dunque, è limitato all’esecuzione dei comandi a essi delegati sotto

50

forma di job (solitamente si tratta di eseguire delle applicazioni appositamente realizzate, con un ben determinato insieme di dati di input). Il vero punto di forza di HPC, pertanto, consiste nella realizzazione di applicazioni che non tengano conto delle risorse di calcolo sottostanti, in quanto la distribuzione delle operazioni sulle varie istanze di macchina (fisica o virtuale) viene delegata agli Head Node in maniera del tutto trasparente.

HPC Pack supporta anche l’utilizzo di macchine remote che ospitano Microsoft SQL Server. Esso usa cinque database differenti dedicati alle informazioni circa job scheduling, gestione del cluster, reportistica, diagnostica e monitoraggio. Questi database possono risiedere nell’Head Node (impostazione di default in soluzioni con un singolo Head Node) oppure in un server remoto. Quest’ultima configurazione migliora l’efficienza del cluster, alleggerendo il carico di lavoro dell’Head Node. La scelta può ricadere su macchine SQL Server oppure, in soluzioni basate su Azure, su istanze di pool elastico, istanze gestite o macchine virtuali.

HPC Pack definisce in maniera chiara una separazione nei ruoli delle macchine coinvolte nel cluster e, quindi, nelle loro funzionalità.

• Gli Head Node si occupano dello scheduling dei job e delle richieste SOA (Service Oriented Architecture) delle applicazioni client, comunicando con i Broker Node;

• I Broker Node ricevono le richieste SOA e le distribuiscono ai nodi che ospitano il servizio desiderato; dunque, raccolgono le risposte e le inoltrano all’applicazione client:

• I Workstation Node si occupano di ospitare servizi SOA, ma possono anche eseguire job;

• I Windows Azure Worker Node eseguono i job richiesti e possono ospitare servizi SOA;

• Gli Unmanaged Server Node sono istanze che possono essere usate occasionalmente per eseguire job o per fornire servizi di networking e file

sharing.

Una considerazione importante riguarda il ruolo dell’Head Node che di default può fungere anche da Broker e Compute Node, se portato in stato Online. Lo stesso può

51

essere fatto per i Broker Node, che possono gestire anche il ruolo di Compute Node in scenari di alta disponibilità. [7]

I nodi HPC Pack, qualsiasi sia il loro ruolo, sono descritti da State e Health, grazie al monitoraggio costante cui sono sottoposti. Il Node State definisce lo stato di

deployment e la sua disponibilità: un nodo è Online se può accettare ed eseguire job.

Pertanto, lo scheduling di un job si occupa di distribuire l’esecuzione tra i soli nodi Online. Questo stato può essere configurato dall’amministratore del Cluster mediante l’Head Node. Lo stato Offline, al contrario, specifica che un nodo non può eseguire

job e, nel caso di Broker Node, che non può gestire sessioni SOA. Lo stato Unknown

indica che un nodo non è parte del cluster o che si è verificato un fallimento. Gli stati di Provisioning, Removing, Stopping, Starting e Draining sono transitori. Rejected indica che un nodo è stato rifiutato dall’amministratore del cluster, mentre Not- Deployed (valido solo per gli Azure Node) specifica che il nodo in questione è stato definito, ma l’istanza relativa non è stata ancora creata su Azure.

Il Node Health, invece, descrive lo stato di warning o errore del servizio HPC su un nodo: l’assenza di fallimenti è indicata dallo stato OK; al contrario, si può incorrere in Warning (test diagnostici falliti) o Error (nodo non raggiungibile, rifiutato o

deployment fallito). Se un nodo non appartiene al cluster o non è ancora stato creato

(Azure Node) è marcato come Unapproved, mentre Transitional rappresenta una fase transitoria (avviato, modificato, o portato in stato Online/Offline).

I cluster che ospitano HPC possono essere realizzati in accordo con diverse topologie supportate nativamente dal sistema:

• Compute Node isolati in una rete privata: il traffico da e verso i nodi di calcolo passa attraverso l’Head Node. In questo scenario i Compute Node non sono direttamente accessibili dall’utente, e le risorse (database e file server) non sono direttamente visibili dai nodi di calcolo. Situazioni di questo tipo potrebbero tradursi in colli di bottiglia;

• Tutti i nodi in una rete privata e in una rete enterprise, compreso l’Head Node: il traffico, a differenza dello scenario precedente, può essere indirizzato direttamente verso i nodi di calcolo. Inoltre, questi ultimi sono accessibili all’utente;

52

• Compute Node isolati in due reti, una privata e una legata all’applicazione: questo modello offre migliori prestazioni, separando il Node

Management del cluster dalla logica applicativa (accesso ai dati). Anche in

questo caso, tuttavia, i nodi di calcolo non sono direttamente accessibili all’utente;

• Tutti i nodi connessi sulle reti enterprise, privata e applicativa: vengono messi insieme i vantaggi dei modelli precedenti, consentendo comunicazione diretta con i Compute Node tramite la rete enterprise, accessibilità dell’utente a essi e gestione del cluster in una rete dedicata;

• Tutti i nodi in un’unica enterprise network: il traffico enterprise, applicativo e del cluster è instradato in un’unica rete. [7]

Fig. 18: Topologia di comunicazione HPC su enterprise network