Come eseguire un kernel Wolfram remoto da un portatile tramite VPN

Collegate la VPN, aprite il notebook e vi aspettate che la cella pesante venga eseguita sul server. In pratica il tunnel trasporta solo pacchetti. Non installa un valutatore, non concede una licenza e non sceglie quale macchina esegue il codice. Sono tre cose separate, e un flusso di lavoro con kernel remoto ha bisogno di tutte e tre prima che il primo calcolo sia affidabile.

Il mito: una connessione VPN è la configurazione

La VPN fornisce un percorso di rete tra il portatile e il server. È utile e spesso necessario, perché il canale di avvio e la connessione del kernel devono raggiungere l’host remoto. Non dice nulla sulla presenza di un kernel Wolfram su quell’host, se la licenza consente un secondo processo concorrente o se l’interfaccia frontale è configurata per usarlo.

Un portatile gestito può portare solo l’interfaccia frontale, con il diritto collegato al server. Accade anche il contrario: una licenza desktop sul portatile non autorizza un kernel su infrastruttura condivisa. Nessuno dei due casi si risolve riconnettendo il tunnel.

Verificate presto questa ipotesi. Valutate $MachineName in un notebook nuovo e confrontate la risposta con l’host atteso. Se restituisce il nome del portatile, la cella è stata eseguita localmente, per quanto la VPN sembri sana.

Separa l’interfaccia frontale dal valutatore

L’interfaccia frontale è la finestra: modifica le celle, mostra l’output e salva il file del notebook. Il kernel è il processo che valuta le espressioni e mantiene le definizioni in memoria. Chiudere l’interfaccia frontale non sposta il kernel, e salvare il notebook non salva lo stato del kernel.

Una volta collegato un kernel remoto, la posizione del file del notebook e la directory di lavoro del kernel sono cose diverse. Directory[] riporta la directory del valutatore, ed è il percorso che conta per Import, Export e i nomi di file relativi. Un insieme di dati accanto al notebook sul portatile non è visibile a un kernel in esecuzione su un’altra macchina.

Decidete come i dati raggiungeranno il server prima di scrivere l’analisi: una posizione montata condivisa, un passaggio di trasferimento approvato o un database a cui il server può accedere direttamente. La scelta influisce sulla riproducibilità, perché un notebook che dipende da un percorso del portatile fallirà la prossima volta che qualcun altro lo eseguirà.

Avviate il kernel attraverso un canale approvato

La guida ai kernel remoti di Wolfram descrive come aggiungere una voce di kernel, selezionare la macchina remota e avviare tramite SSH. Il percorso dell’eseguibile e gli argomenti dell’esempio appartengono al flusso di lavoro di quel prodotto; adattateli all’host e alla versione indicati dall’amministratore invece di incollarli senza modifiche.

L’identità dell’host fa parte della configurazione. Verificate la chiave host SSH tramite il processo dell’organizzazione, usate il metodo di autenticazione emesso e tenete le chiavi private e le password fuori dai file del notebook condivisi o confermati nel repository. Un notebook con un comando di avvio e una password è una fuga di credenziali, non una comodità.

Non aprite un listener WSTP su internet come scorciatoia. Il modello supportato è l’avvio SSH, che mantiene il canale del kernel dentro una connessione autenticata. Se il team di rete ha approvato un altro trasporto, usatelo, ma trattate una porta del valutatore esposta come una modifica di progettazione, non come un passo di risoluzione dei problemi.

Verificate prima il diritto, i dati e la dimensione dell’output

Confermate con il titolare della licenza che il server possa eseguire un kernel per questo utente e che le sessioni concorrenti siano consentite. Il calcolo remoto è spesso concesso in licenza separatamente dall’interfaccia frontale desktop, e un avvio fallito per il diritto sembra un comando SSH fallito finché qualcuno non legge il messaggio del server.

Poi stimate la dimensione del risultato. Un kernel che restituisce un’espressione di diversi gigabyte la invia attraverso il canale di avvio e il canale del kernel all’interfaccia frontale, il che può bloccare o esaurire la memoria del portatile. Mantenete l’aggregazione pesante sul server e restituite riepiloghi, oppure scrivete i risultati grandi in un percorso del server e trasferiteli deliberatamente.

Annotate il percorso dell’eseguibile, gli argomenti di avvio e la directory di lavoro nelle note di configurazione del notebook. Il prossimo utente riproduce così la disposizione invece di riscoprire quale dei cinque percorsi possibili usa il server.

Diagnosticate le fasi in ordine

Cinque fasi devono riuscire, e ciascuna ha un test distinto. Partite dal portatile e fermatevi al primo fallimento invece di cambiare più impostazioni insieme:

nc -vz research.example.edu 22
ssh -v [email protected] 'hostname; command -v wolframscript'
ssh [email protected] 'wolframscript -code "$MachineName"'

Un controllo TCP fallito indica routing, DNS o le destinazioni consentite della VPN. Un controllo TCP riuscito con un accesso SSH fallito indica l’autenticazione o la politica delle chiavi host. Un accesso che funziona ma non trova alcun eseguibile indica l’installazione del kernel o il percorso fornito all’interfaccia frontale. Un kernel che si avvia ma non si connette mai indica gli argomenti di avvio o il firewall locale.

Conservate il primo errore significativo e inviate le fasi lato server all’amministratore che possiede quella macchina. Ricreare ripetutamente la voce del kernel nasconde quale fase è davvero fallita e scarta le prove di cui l’amministratore ha bisogno.

Alla fine volete una finestra che riconoscete, un valutatore che potete nominare e un percorso concordato per codice e file. La VPN è un componente di quel percorso, e prima il flusso di lavoro lo riflette, meno tempo va perso a riconnettere un tunnel che non è mai stato il problema.