Como executar um kernel remoto do Wolfram a partir de um laptop por VPN

Liga a VPN, abre o caderno e espera que a célula pesada seja executada no servidor. Na prática, o túnel transporta apenas pacotes. Não instala um avaliador, não concede uma licença e não escolhe que máquina executa o código. São três coisas separadas, e um fluxo de trabalho com kernel remoto precisa das três antes de o primeiro cálculo ser fiável.

O mito: uma ligação VPN é a configuração

A VPN fornece um caminho de rede entre o laptop e o servidor. Isso é útil e frequentemente necessário, porque o canal de arranque e a ligação ao kernel têm de chegar ao anfitrião remoto. Não diz nada sobre se existe um kernel do Wolfram nesse anfitrião, se a licença permite um segundo processo concorrente ou se a interface frontal está configurada para o usar.

Um laptop gerido pode transportar apenas a interface frontal, com o direito associado ao servidor. Também acontece o contrário: uma licença de ambiente de trabalho no laptop não autoriza um kernel em infraestrutura partilhada. Nenhum dos casos se resolve ao voltar a ligar o túnel.

Teste a suposição cedo. Avalie $MachineName num caderno novo e compare a resposta com o anfitrião que espera. Se devolver o nome do laptop, a célula foi executada localmente, por mais saudável que a VPN pareça.

Separe a interface frontal do avaliador

A interface frontal é a janela: edita células, mostra a saída e guarda o ficheiro do caderno. O kernel é o processo que avalia expressões e mantém as definições em memória. Fechar a interface frontal não move o kernel, e guardar o caderno não guarda o estado do kernel.

Depois de ligar um kernel remoto, a localização do ficheiro do caderno e o diretório de trabalho do kernel são coisas distintas. Directory[] indica o diretório do avaliador, e é esse o caminho que importa para Import, Export e nomes de ficheiro relativos. Um conjunto de dados ao lado do caderno no laptop não é visível para um kernel que corre noutra máquina.

Decida como os dados chegarão ao servidor antes de escrever a análise: uma localização montada partilhada, um passo de transferência aprovado ou uma base de dados a que o servidor possa aceder diretamente. A escolha afeta a reprodutibilidade, porque um caderno que dependa de um caminho do laptop falhará na próxima vez que outra pessoa o executar.

Lance o kernel por um canal aprovado

O guia de kernels remotos do Wolfram descreve como adicionar uma entrada de kernel, selecionar a máquina remota e lançar por SSH. O caminho do executável e os argumentos do exemplo pertencem ao fluxo de trabalho desse produto; adapte-os ao anfitrião e à versão indicados pelo administrador em vez de os colar sem alterações.

A identidade do anfitrião faz parte da configuração. Verifique a chave de anfitrião SSH através do processo da organização, use o método de autenticação emitido e mantenha as chaves privadas e as palavras-passe fora dos ficheiros do caderno que são partilhados ou confirmados no repositório. Um caderno com um comando de arranque e uma palavra-passe é uma fuga de credenciais, não uma comodidade.

Não abra um ouvinte WSTP para a internet como atalho. O padrão suportado é o arranque por SSH, que mantém o canal do kernel dentro de uma ligação autenticada. Se a equipa de rede aprovou outro transporte, use esse, mas trate uma porta de avaliador exposta como uma alteração de desenho, não como um passo de resolução de problemas.

Verifique primeiro o direito, os dados e o tamanho da saída

Confirme com o titular da licença que o servidor pode executar um kernel para este utilizador e que as sessões concorrentes são permitidas. O cálculo remoto é frequentemente licenciado em separado da interface frontal de ambiente de trabalho, e um arranque falhado por causa do direito parece um comando SSH falhado até alguém ler a mensagem do servidor.

Depois estime o tamanho do resultado. Um kernel que devolve uma expressão de vários gigabytes envia-a pelo canal de arranque e pelo canal do kernel até à interface frontal, o que pode bloquear ou esgotar a memória do laptop. Mantenha a agregação pesada no servidor e devolva resumos, ou escreva os resultados grandes num caminho do servidor e transfira-os deliberadamente.

Anote o caminho do executável, os argumentos de arranque e o diretório de trabalho nas notas de configuração do caderno. O utilizador seguinte reproduz então a disposição em vez de descobrir de novo qual dos cinco caminhos possíveis o servidor usa.

Diagnostique as etapas por ordem

Cinco etapas têm de ter sucesso, e cada uma tem um teste distinto. Comece pelo laptop e pare na primeira falha em vez de alterar vários ajustes ao mesmo tempo:

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

Uma verificação TCP falhada aponta para o encaminhamento, o DNS ou os destinos permitidos da VPN. Uma verificação TCP bem-sucedida com um início de sessão SSH falhado aponta para a autenticação ou para a política de chaves do anfitrião. Um início de sessão que funciona mas não encontra nenhum executável aponta para a instalação do kernel ou para o caminho que a interface frontal recebeu. Um kernel que arranca mas nunca se liga aponta para os argumentos de arranque ou para a firewall local.

Preserve o primeiro erro significativo e envie as etapas do lado do servidor ao administrador que é dono dessa máquina. Recriar a entrada do kernel repetidamente esconde qual etapa falhou de facto e deita fora as provas de que o administrador precisa.

No fim, quer uma janela que reconheça, um avaliador que possa nomear e uma rota acordada para código e ficheiros. A VPN é um componente desse caminho, e quanto mais cedo o fluxo de trabalho o refletir, menos tempo se perde a voltar a ligar um túnel que nunca foi o problema.