Configurare la sottoscrizione di Azure

Per eseguire Azure CycleCloud, sarà necessaria una sottoscrizione di Azure valida e Rete virtuale.

In genere, le decisioni di creazione e configurazione del tenant e della sottoscrizione di Azure sono decisioni aziendali all'esterno dell'ambito della documentazione di Azure CycleCloud. Tuttavia, poiché le applicazioni HPC e big compute in generale sono a elevato utilizzo di risorse, vale la pena considerare la creazione di una sottoscrizione dedicata per tenere traccia della fatturazione, applicare limiti di utilizzo e isolare l'utilizzo delle risorse e dell'API. Per altre informazioni sulla progettazione dei tenant e delle sottoscrizioni di Azure, vedere Gestione delle sottoscrizioni di Azure.

Configurare una rete virtuale

Sarà necessario selezionare un Rete virtuale di Azure esistente e subnet oppure creare una nuova Rete virtuale in cui eseguire la macchina virtuale CycleCloud e i cluster di calcolo che verranno gestiti da CycleCloud.

Se la Rete virtuale non è già stata creata, è consigliabile prendere in considerazione l'avvio dalla distribuzione del modello di Arm CycleCloud specificata. Il modello CycleCloud ARM crea una nuova rete virtuale per CycleCloud e i cluster di calcolo in fase di distribuzione. In alternativa, è possibile seguire queste istruzioni per creare una nuova Rete virtuale.

Se quindi Express Route o VPN non sono già configurati per il Rete virtuale, è possibile connettersi alla Rete virtuale tramite Internet pubblico, ma è consigliabile configurare un Gateway VPN.

Configurare una subnet e un gruppo di sicurezza di rete

Poiché CycleCloud ha in genere diversi requisiti di sicurezza di rete e criteri di accesso rispetto ai cluster di calcolo, è spesso consigliabile eseguire Azure CycleCloud in una subnet di Azure diversa dai cluster.

La procedura consigliata consiste nell'usare almeno due subnet, una per la macchina virtuale CycleCloud e qualsiasi altra vm con gli stessi criteri di accesso e subnet aggiuntive per i cluster di calcolo. Tuttavia, tenere presente che per i cluster di grandi dimensioni, l'intervallo IP della subnet può diventare un fattore di limitazione. Pertanto, in generale, la subnet CycleCloud deve usare un piccolo intervallo CIDR e le subnet di calcolo devono essere grandi.

Seguire le istruzioni riportate qui per creare una o più subnet nel Rete virtuale.

Uso di più subnet per il calcolo

I cluster CycleCloud possono essere configurati per eseguire nodi e nodi in più subnet, purché tutte le macchine virtuali possano comunicare all'interno del cluster e con CycleCloud (forse tramite Proxy restituito). Ad esempio, è spesso utile avviare il nodo dell'utilità di pianificazione o i nodi di invio in una subnet con regole di sicurezza diverse dai nodi di esecuzione. I tipi di cluster predefiniti in CycleCloud presuppongono una singola subnet per l'intero cluster, ma la subnet può essere configurata per nodo o nodearray usando l'attributo SubnetId nel modello di nodo.

Tuttavia, la risoluzione host basata su file host predefinita applicata ai cluster CycleCloud genera solo un file host per la subnet del nodo per impostazione predefinita. Quindi, quando si crea un cluster che si estende su più subnet, la risoluzione del nome host deve essere personalizzata anche per il cluster.

Sono necessarie 2 modifiche del modello di cluster di base per supportare più subnet di calcolo:

1. Impostare l'attributo SubnetId in ogni nodo o nodearray che non si trova nella subnet predefinita per il cluster.
2. Configurare la risoluzione del nome host per tutte le subnet, in base a:
   1. Uso di una zona DNS di Azure e disabilitazione della risoluzione predefinita basata su file host
   2. In alternativa, impostare l'attributo CycleCloud.hosts.standalone_dns.subnets su un intervallo CIDR della rete virtuale o un elenco delimitato da virgole di intervalli CIDR per ogni subnet. Per informazioni dettagliate, vedere Informazioni di riferimento sulla configurazione del nodo .

Impostazioni del gruppo di sicurezza di rete per la subnet CycleCloud

La configurazione dell'Rete virtuale di Azure per la sicurezza è un argomento generale, oltre l'ambito di questo documento.

I cluster CycleCloud e CycleCloud possono funzionare in ambienti molto bloccati. Per informazioni dettagliate sulla configurazione, vedere Esecuzione in Reti bloccate ed esecuzione dietro un proxy .

Tuttavia, per reti meno restrittive, esistono alcune linee guida generali. Prima di tutto, gli utenti di CycleCloud GUI richiedono l'accesso alla macchina virtuale CycleCloud tramite HTTPS e amministratori possono richiedere l'accesso SSH. Gli utenti del cluster richiedono in genere l'accesso SSH a almeno i nodi di invio nei cluster di calcolo e potenzialmente ad altri accessi, ad esempio RDP per i cluster Windows. L'ultima regola generale consiste nel limitare l'accesso al minimo richiesto.

Per creare un nuovo gruppo di sicurezza di rete per ognuna delle subnet create in precedenza, seguire la guida alla creazione di un gruppo di sicurezza di rete.

Regole di sicurezza in ingresso

Importante

Le regole seguenti presuppongono che la rete virtuale sia configurata con Express Route o VPN per l'accesso alla rete privata. Se si esegue su Internet pubblico, l'origine deve essere modificata nell'indirizzo IP pubblico o nell'intervallo IP aziendale.

Subnet della macchina virtuale CycleCloud

Nome	Priorità	Origine	Servizio	Protocollo	Intervallo di porte
SSH	100	VirtualNetwork	Personalizzato	TCP	22
HTTPS	110	VirtualNetwork	Personalizzato	TCP	443
HTTPS	110	VirtualNetwork	Personalizzato	TCP	9443

Subnet di calcolo

Nome	Priorità	Origine	Servizio	Protocollo	Intervallo di porte
SSH	100	VirtualNetwork	Personalizzato	TCP	22
RDP	110	VirtualNetwork	Personalizzato	TCP	3389
Gangli	120	VirtualNetwork	Personalizzato	TCP	8652

Regole di sicurezza in uscita

In generale, la macchina virtuale CycleCloud e i cluster di calcolo prevedono di poter accedere a Internet per l'installazione del pacchetto e le chiamate API REST di Azure.

Se l'accesso Internet in uscita è bloccato dai criteri di sicurezza, seguire le istruzioni per l'esecuzione in reti bloccate e l'esecuzione dietro un proxy per informazioni dettagliate sulla configurazione.