lamboot - Online na nuvem

PROGRAMA:

NOME

lamboot - Inicie um multicomputador LAM.

SINOPSE

lamboot [-b] [-d] [-h] [-H] [-l] [-s] [-v] [-V] [-x] [-nn] [-np] [-c arquivo conf ] [-prefixo
/ lam / install / path /] [-sessionprefix value] [-sessionsuffix value]
[-withlamprefixpath valor] [-ssi valor da chave] [bhost]

OPÇÕES

-b Suponha que os shell local e remoto sejam iguais. Isso significa que apenas um shell remoto
a invocação é usada para cada nó. Se -b não é usado, duas invocações de shell remoto
são usados ​​para cada nó.

-d Ative a saída de depuração. Isso implica em -v.

-h Imprima o menu de ajuda do comando.

-l Atrasar a resolução do nome do host para o endereço IP.

-prefixo Use a instalação do LAM especificada em / lam / install / path /. Não compatível com
Versões LAM / MPI anteriores a 7.1.

-s Fechar stdio no nó local.

-ssi chave valor
Envie argumentos para vários módulos SSI. Consulte a seção "SSI" abaixo.

-v Seja prolixo.

-x Execute no modo tolerante a falhas.

-H Não exiba o cabeçalho do comando.

-nn Não adicione "-n" à linha de comando do agente remoto

-np Não force a execução de $ HOME / .profile em hosts remotos

-prefixo de sessão valor
Defina o prefixo da sessão, substituindo LAM_MPI_SESSION_PREFIX.

-sessão-sufixo valor
Defina o sufixo da sessão, substituindo LAM_MPI_SESSION_SUFFIX.

-com caminho de prefixo da lâmpada valor
Substitua o caminho de instalação interno. Apenas para uso interno, não use a menos que
você sabe o que está fazendo.

MEIO AMBIENTE VARIÁVEIS

LAM_MPI_SESSION_PREFIX

LAM_MPI_SESSION_SUFFIX
É possível alterar o diretório de sessão usado pelo LAM / MPI, normalmente do
Formato:

tmpdir / lam-username @ hostname [-suffix]

tmpdir será definido como LAM_MPI_SESSION_PREFIX se definido. Caso contrário, ele voltará para
o valor de TMPDIR. Se nenhum deles for definido, o padrão é / tmp.

sufixo pode ser substituído pelo LAM_MPI_SESSION_SUFFIX variável de ambiente. Se
LAM_MPI_SESSION_SUFFIX não está definido e o LAM está sendo executado em um lote compatível
sistema de agendamento, $ sufixo será um valor exclusivo para o trabalho em execução no momento.

DESCRIÇÃO

A rabo de cavalo ferramenta inicia o software LAM em cada uma das máquinas especificadas no boot
esquema, anfitrião. O esquema de inicialização especifica os nomes de host dos nós a serem usados ​​na execução
no ambiente MPI de tempo e, opcionalmente, lista como as CPUs LAM podem ser usadas em cada nó. o
o usuário pode querer primeiro executar o reconstrução(1) ferramenta para verificar se o LAM pode ser iniciado.

Iniciar o LAM é um procedimento de três etapas. Na primeira etapa, hboot(1) é invocado em cada um
as máquinas especificadas. Então, cada máquina aloca uma porta dinâmica e a comunica
voltar para rabo de cavalo que os coleta. Na terceira etapa, rabo de cavalo dá a cada máquina o
lista de máquinas / portas para formar uma topologia totalmente conectada. Se alguma máquina fosse
não consegue iniciar, ou se um período de tempo expirar antes que a primeira etapa seja concluída, rabo de cavalo
invoca limpa-fogo(1) para encerrar o LAM e relatar o erro.

A anfitrião file é um esquema de inicialização LAM escrito na sintaxe do arquivo host. Ver anfitrião(5).
Em vez da linha de comando, um esquema de inicialização pode ser especificado no ambiente LAMBHOST
variável. Caso contrário, um arquivo padrão, lam-bhost.def, é usado. LAM procura por anfitrião primeiro
no diretório local e, em seguida, no diretório de instalação em etc /.

Além disso, rabo de cavalo usa um esquema de processo para os nós LAM individuais. Um esquema de processo
(Vejo conf(5)) é uma descrição dos processos que constituem o sistema operacional em um
nó. Em geral, o administrador do sistema mantém este arquivo - os usuários LAM / MPI irão
geralmente não é necessário alterar este arquivo. Também é possível para o usuário personalizar o
Software LAM com esquema de processo privado.

A anfitrião lima
O formato do anfitrião arquivo é documentado no anfitrião(5) página de manual.

rabo de cavalo irá resolver todos os nomes em anfitrião no nó em que rabo de cavalo foi invocado (o
nó de origem). Depois disso, o LAM usará apenas endereços IP, não nomes. Especificamente, o
a configuração de resolução de nomes em todos os outros nós não é usada. Portanto, o nó de origem
deve ser capaz de resolver todos os nomes em anfitrião para endereços que podem ser acessados ​​por todos
outros nós.

Um erro comum é listar localhost (ou qualquer nome que resolva para o endereço especial
127.0.0.1 - o dispositivo TCP / IP de loopback) em um anfitrião arquivo que contém outros nós. No
neste caso, o endereço 127.0.0.1 seria enviado para cada um dos outros nós como o endereço
do nó de origem. Se os outros nós tentarem usar 127.0.0.1 para entrar em contato com o nó de origem,
eles realmente entrarão em contato consigo mesmos e, eventualmente, atingirão o tempo limite e falharão.

Os endereços IP obtidos de anfitrião são usados ​​para as metamensagens do LAM: inicialização e
encerramento de tarefas, mensagens fora de banda usadas para coordenação, etc. A quantidade de tráfego
é bastante baixo (a menos que use o modo "lamd" de passagem de mensagem MPI, caso em que todos os MPI
o tráfego também utilizará as metamensagens do LAM para transporte - consulte mpirun(1)). Ao usar
o TCP RPI, esses endereços IP também são usados ​​para a passagem de mensagens MPI por meio de sockets diretos
entre cada par de nós.

Um caso comum é quando um nó "mestre" tem várias placas de interface de rede (NICs) - uma
que está conectado a uma rede pública e aquele que está conectado a uma rede privada
onde trabalhos paralelos devem ser executados. Para incluir o nó mestre em um anfitrião arquivo, o IP
nome (ou endereço) da NIC na rede privada deve ser listado em anfitrião. Este
garante que todos os outros nós possam alcançar o nó mestre na rede privada.

Como outro exemplo, algumas configurações têm vários NICs TCP / IP em cada nó de um
trabalho paralelo. Um NIC é considerado "lento" (por exemplo, 10 Mbps), enquanto o outro é considerado
"rápido" (por exemplo, 100 Mbps). É desejável permitir que o LAM tire vantagem do maior
largura de banda na rede "rápida" para mensagens MPI. Como tal, anfitrião deve listar os nomes de IP
(ou endereços) de todos os NICs "rápidos". No entanto, se o LAM RPI não usa TCP / IP (por exemplo,
o Myrinet / GM RPI), o anfitrião arquivo provavelmente deve listar os NICs "lentos" para que o LAM
o tráfego de meta mensagens não causa sobrecarga e potencialmente prejudica o desempenho em
a rede "rápida" de outros aplicativos de alto desempenho.

Atraso hostname pesquisas
Normalmente, a resolução de nomes de hostnames é feita nas máquinas onde rabo de cavalo é invocado.
Isso é feito por motivos de otimização, de modo que a lista de nomes de host só precisa ser
resolvido uma vez (potencialmente minimizando a quantidade de DNS ou outra rede de pesquisa de nome de host
tráfego).

No entanto, em alguns ambientes de rede não uniformes, isso não é suficiente porque cada
o host pode ter um endereço IP diferente em cada um de seus pares. Por exemplo, o host A pode ter
endereço Z no host B, mas tem endereço Y no host C.

A -l opção para rabo de cavalo fará com que o LAM distribua nomes de host para cada nó em vez de um
conjunto totalmente resolvido de endereços IP. Portanto, cada nó onde o LAM é inicializado fará seu próprio
resolução de nomes na lista de nomes de host.

SSI (Sistema Serviços interface)
A -ssi switch permite a passagem de parâmetros para vários módulos SSI. SSI da LAM
módulos são descritos em detalhes em lamssi(7). Módulos SSI têm impacto direto no MPI
programas porque eles permitem que parâmetros ajustáveis ​​sejam definidos em tempo de execução (como qual inicialização
driver de dispositivo a ser usado, quais parâmetros passar para esse driver, etc.).

A -ssi switch leva dois argumentos: chave e valor. O chave argumento geralmente especifica
qual módulo SSI receberá o valor. Por exemplo, o chave "boot" é usado para selecionar
qual RPI a ser usado para iniciar processos em nós remotos. o valor argumento é o
valor que é passado. Por exemplo:

lambboot -ssi inicialização tm
Diz ao LAM para usar o módulo de inicialização "tm" para lançamento nativo em PBSPro / OpenPBS
ambientes (o módulo de inicialização tm não requer um esquema de inicialização).

lamboot -ssi boot rsh -ssi rsh_agent "ssh -x" boot_schema
Diz ao LAM para usar o módulo de inicialização "rsh" e diz ao módulo rsh para usar "ssh -x" como
o agente específico para lançar executáveis ​​em nós remotos.

E assim por diante. Os módulos SSI de inicialização do LAM são descritos em lamssi_boot(7). Esta página deve ser
consultado para ações específicas que são realizadas por e como ajustar o comportamento do tempo de execução
de cada módulo de inicialização.

A -ssi switch pode ser usado várias vezes para especificar diferentes chave e / ou valor
argumentos. Se o mesmo chave é especificado mais de uma vez, o valors são concatenados com
uma vírgula (",") separando-os.

Observe que o -ssi switch é simplesmente um atalho para definir variáveis ​​de ambiente. o
o mesmo efeito pode ser obtido definindo as variáveis ​​de ambiente correspondentes antes
corrida rabo de cavalo. A forma das variáveis ​​de ambiente que o LAM define são:
LAM_MPI_SSI_key = valor.

Observe que o -ssi switch substitui quaisquer variáveis ​​de ambiente definidas anteriormente. Observe também
aquele desconhecido chave argumentos ainda são definidos como variáveis ​​de ambiente - eles não são verificados
(por limpa-fogo) para correção. Ilegal ou incorreto valor argumentos podem ou não ser
relatado - depende do módulo SSI específico.

Remote Executável Invocação
Todos os aspectos ajustáveis ​​do lançamento de executáveis ​​em nós remotos durante rabo de cavalo e guarante que os mesmos estão
discutido em lamssi(7) e lamssi_boot(7). Os tópicos incluem (mas não estão limitados a):
descoberta de shell remoto, substituições de tempo de execução do uso do agente para iniciar remoto
executáveis ​​(por exemplo, rsh e ssh), etc.

Encerramento stdio
O stdio de cada daemon LAM em um host remoto que é iniciado por rabo de cavalo é fechado por
predefinição. Normalmente, o stdio do daemon LAM lançado no host local é deixado aberto para
que o LAM interno tstdio(3) o pacote funciona corretamente. No entanto, às vezes é
desejável fechar o stdio do daemon LAM local também. Por exemplo:

rsh somenode lamboot -s arquivo de host

Isto é porque rsh aguarda duas condições antes de sair: rabo de cavalo para sair e stdout /
stderr a ser fechado. Sem -s, stdout / stderr não seria fechado e rsh (E ssh)
vai travar embora rabo de cavalo tinha concluído. -s faz com que o stdout / stderr do local
Daemon LAM a ser fechado na invocação, o que permitirá rsh completar. Usando -s precisarão
não afetar rabo de cavalo de qualquer outra forma, mas irá prevenir o tstdio(3) pacote de
trabalhando corretamente.

Culpa Tolerância
Se o -x opção for fornecida, o LAM é executado no modo tolerante a falhas. Neste modo, os nós trocam
Mensagens de "batimento cardíaco" periodicamente para se certificar de que todos os nós estão rodando e os links
conectá-los estão operacionais. Quando os batimentos cardíacos de um nó param, ele é declarado `` morto ''
e todos os nós (e processos) LAM são notificados. Isso permite que os usuários escrevam tolerantes a falhas
aplicativos que podem se degradar normalmente ou se recuperar totalmente substituindo o nó extinto
com outro (veja crescimento lento(1)). Uma vez que este modo introduz uma penalidade de desempenho, é
não ativado por padrão.

EXEMPLOS

lambboot -v
Inicie o LAM nas máquinas descritas no esquema de inicialização padrão. Relatório sobre
etapas importantes à medida que são realizadas.

lamboot -d arquivo de host
Inicie o LAM nas máquinas descritas no arquivo arquivo de host. Fornece incrivelmente detalhado
relatórios sobre o que está acontecendo em cada estágio do processo de inicialização.

mynodes lamboot
Inicie o LAM nas máquinas descritas no esquema de inicialização meus nós. Opere silenciosamente.

Use o lamboot online usando os serviços onworks.net