Child pages
  • Configuração e Execução do CSFS
Skip to end of metadata
Go to start of metadata

O CSFS auxilia o trabalho do SGA, fazendo com que os arquivos necessários para a execução de um algoritmo estejam disponíveis na máquina de execução. É utilizado quando a área de projetos e algoritmos do servidor do sistema CSBase não são visíveis para o SGA.

Requisitos

  • São necessários dois daemons CSFS para a configuração funcionar, um do lado do servidor CSBase, outro do lado do SGA.
  • Os dois daemons não poderão rodar na mesma máquina.

Configuração

Daemon CSFS do servidor

Em primeiro lugar, é preciso levantar um daemon CSFS na mesma máquina onde o servidor CSBase será executado. Para tal, rode o script startCSFS (no diretório sgad/csfs):

[server-host:~/workspace/csbase/sgad/csfs] ./startCSFS --SERVER_LOG=../logs/csfs_server.log --HOST=server-host --ROOT_DIR=../../csgrid &

Onde:

  • SERVER_LOG é o caminho para o arquivo onde será logada a atividade do CSFS. (opcional)
  • HOST é o nome ou endereço IP da máquina onde esse daemon CSFS está sendo executado. No nosso exemplo, é a mesma máquina do servidor. Esse é o caso mais comum de uso. O daemon também pode ser executado de qualquer outra máquina acessível do servidor desde que tenha acesso aos repositórios de projetos e algoritmos. (obrigatório)
  • ROOT_DIR é o caminho para o diretório pai dos repositórios de projetos e algoritmos. Caso não sejam irmãos, é necessário configurar esse diretório como um ancestral comum entre os repositórios e definir na propriedades do servidor CSFSService.PROJECT_DIR_FROM_ROOT e CSFSService.ALGORITHM_DIR_FROM_ROOT o caminho a partir do ROOT_DIR até cada um dos repositórios. (obrigatório)

Por exemplo, se o repositório de projetos está em "/home/system/project" e o diretório de algoritmos está em "/home/system/workspace/algorithms", o ROOT_DIR deve apontar para "/home/system" e as propriedades no servidor devem ser definidas da seguinte maneira:

# Caminho relativo do ROOT_DIR até o repositório de projetos
CSFSService.PROJECT_DIR_FROM_ROOT = project

# Caminho relativo do ROOT_DIR até o repositório de algoritmos
CSFSService.ALGORITHM_DIR_FROM_ROOT = workspace/algorithms
Servidor

Antes de mais nada, o servidor precisa ter o serviço CSFSService habilitado:

# Indica se o serviço está habilitado
CSFSService.ENABLED = true

O servidor deve indicar também em que máquina está rodando o daemon CSFS que ele irá utilizar. No nosso exemplo, é a própria máquina onde o servidor está rodando.

# A máquina onde o CSFS Server será executado.
CSFSService.CSFS_HOST = server-host

Definir qual o método de transferência de arquivos será utilizada pelo daemon do CSFS. Essa configuração é feita no servidor através da propriedade CSFSService.TRANSFER_METHOD e tem como valor padrão a cópia via CORBA. A configuração dessa opção deve incluir o tamanho do buffer a ser utilizado:

CSFSService.TRANSFER_METHOD = CORBA-32768

O daemon CSFS aceita diversos outros métodos de cópia, incluindo SCP, FTP e NIO. No entanto, apenas CORBA e SCP foram testados recentemente. A opção CORBA é a opção padrão atualmente utilizada. Ela é indicada principalmente em transferências de arquivos pequenos e em SGAs da plataforma Windows, onde o uso de SCP não é trivial. A configuração da cópia via SCP pode ser feita da seguinte forma:

CSFSService.TRANSFER_METHOD = SCP

Para utilizar esse método, é necessário poder fazer SCP entre as máquinas que rodarão os daemons CSFS e a autenticação deve ser feita via chave ssh, ou seja, sem a passagem de senhas na linha de comando. É recomendável que esse teste seja feito antes de prosseguir com a configuração.

Os métodos de transferência alternativos (incluindo o SCP) não ficam habilitados inicialmente. Para utilizá-los, é necessário que os dois daemons CSFS sejam configurados através do parâmetro ENABLE_EXTRA_COPY_METHODS passado para o daemon na linha de comando ou através do arquivo fileserver.properties (que se encontra em sgad/csfs/libs/csfs/).

Exemplo de inicialização do daemon CSFS do servidor com a opção de usar SCP e outros métodos de transferência (além de CORBA):

[server-host:~/workspace/csbase/sgad/src] ./startCSFS --ENABLE_EXTRA_COPY_METHODS=true --SERVER_LOG=../../logs/csfs.log --HOST=server-host --ROOT_DIR=../../src
TCP_BUFFER=65536
TCP_BUFFER=16384
TCP_BUFFER=32768
ReceiveBufferSize=16384
ReceiveBufferSize=65536
ReceiveBufferSize=32768

Ao fazer a configuração que habilita os métodos alternativos de transferência, todos os métodos ficam habilitados.

O servidor pode ser iniciado agora.

SGA

Primeiramente, crie um diretório que será utilizado como raiz do CSFS, onde será criada a sandbox de projetos e o diretório de algoritmos copiados do servidor. No nosso exemplo, criaremos o diretório em "sgad/root". Em seguida, configure um SGA com os parâmetros (via sgad-cnf.lua):

csfs = {
  launch_daemon = YES,
  properties = { HOST="sga-host", PORT=10000, ROOT_DIR="../root" }
}

Onde:

  • launch_daemon indica que o SGA deve iniciar o daemon CSFS. (opcional, com valor padrão falso)
  • O HOST é o nome ou endereço IP da máquina onde o daemon CSFS usado por este SGA está. Se o launch_daemon for YES, deve ser a máquina onde esse SGA será executado. O daemon utilizado pelo SGA pode ser executado em qualquer outra máquina acessível ao SGA que tenha acesso ao ROOT_DIR especificado. (obrigatório)
  • PORT é o número da porta em que o daemon CSFS usado por este SGA está escutando. (obrigatório)
  • ROOT_DIR é onde o CSFS criará a sandbox e deve ser especificado em relação ao diretório onde o daemon CSFS é disparado (sgad/csfs). (obrigatório). Esse diretório já deve ter sido criado previamente.

Veja um exemplo de configuração completa:

Node{
  name = "sga_csfs",
  csfs = {
    launch_daemon = YES,
    properties = { HOST="sga-host", PORT=10000, ROOT_DIR="../root" }
  },
  num_processors = 2,
  platform_id = "Linux26g4",
  clock_speed_mhz = 2000,
  memory_ram_info_mb = 2*1024,
  memory_swap_info_mb = 1024,
  byte_order = LITTLE_ENDIAN,
}

Agora, você já pode executar o SGA com a configuração de CSFS.

[sga-host:~/workspace/csbase/sgad/src] ./sga-daemon --sga sga_csfs --ssi server-host

=======================================================
SGA-Daemon - SGA Start Script
Authors:
    Ana Lúcia Moura (moura@tecgraf.puc-rio.br)
    André Luiz Clinio (clinio@tecgraf.puc-rio.br)
(c) Tecgraf/PUC-Rio, 2002
=======================================================
SGA set to: sga_csfs
SSI server set to: server-host

Running SGA Script File...
Running SGA: sga_csfs (binary at ../bin/Linux26g4)
(Using configuration file at ../../init/)
(Using logfile at ../logs)
Extended dynamic libraries path: /home/t/tecgraf/lib/lua5.1/lib/Linux26g4
SSI Server: server-host
SSI Server Port: 7778
Restart hour:


[init]      09/09/09 10:11:46 Buscando o arquivo de configura??o do SGA...
[init]      09/09/09 10:11:46 Arquivo de configura??o do SGA carregado.
[init]      09/09/09 10:11:46 Buscando o arquivo de configura??o avancada do SGA...
[init]      09/09/09 10:11:46 Arquivo de configura??o avancada do SGA carregado.
[init]      09/09/09 10:11:46 Biblioteca do SGA Linux26g4 carregada.
[init]      09/09/09 10:11:46

[init]      09/09/09 10:11:46 ========================================================================
[init]      09/09/09 10:11:46 SGA daemon - Servidor de execu??o remota do CSBase
[init]      09/09/09 10:11:46 ========================================================================
[init]      09/09/09 10:11:46 sga_csfs (Linux26g4)
[init]      09/09/09 10:11:46 Endere?o do SSI: server-host:7778
[init]      09/09/09 10:11:46 # n?s: 1
[init]      09/09/09 10:11:46 # processadores no n? principal: 2
[init]      09/09/09 10:11:46 Mem?ria total do n? principal: 3072
[init]      09/09/09 10:11:46 Frequ?ncia de clock do n? principal: 2000
[init]      09/09/09 10:11:46 Ordena??o de bytes no processador do n? principal: LITTLE_ENDIAN
[init]      09/09/09 10:11:46 Intervalo, em segundos, para leitura de uso de cpu/mem?ria: 25
[init]      09/09/09 10:11:46 Intervalo, em segundos, para envio de uso de cpu/mem?ria: 30
[init]      09/09/09 10:11:46 Intervalo, em segundos, para consulta de processos: 10
[init]      09/09/09 10:11:46 Intervalo, em segundos, para busca de comandos terminados: 10
[init]      09/09/09 10:11:46 Hora definida para restart do SGA: n?o ajustado
[init]      09/09/09 10:11:46 ========================================================================
[init]      09/09/09 10:11:46

[init]      09/09/09 10:12:17 Buscando refer?ncia CORBA para o SSI server-host:7778...
[init]      09/09/09 10:12:32 Refer?ncia CORBA para o SSI server-host:7778 encontrada.
[init]      09/09/09 10:12:32 Tentando registro do SGA...
[init]      09/09/09 10:12:32 SGA [sga_csfs] registrado no SSI.
[error]     09/09/09 10:12:32 Erro lendo arquivo de persistencia
[platcmd]   09/09/09 10:12:32 Tentando execu??o:
	/bin/ksh -c "/usr/bin/time -p 2> /tmp/lua_M3ltzC /bin/ksh -c ' cd ../csfs; ./startCSFS  --SERVER_LOG=../src/../logs/csfs-sga_csfs.log --HOST=sga-host --PORT=10000 --CANONICAL_ROOT_DIR="/csbase/sgad/root/" --ROOT_DIR=../root/'"

[cmdexec]   09/09/09 10:12:32 Comando para execu??o:
	Comando: [ cd ../csfs; ./startCSFS  --SERVER_LOG=../src/../logs/csfs-sga_csfs.log --HOST=sga-host --PORT=10000 --CANONICAL_ROOT_DIR="/csbase/sgad/root/" --ROOT_DIR=../root/]
	Id: [CSFS_PROCESS]
	Host: [sga_csfs]
	PID: [26956].

Observação

Um SGA pode disparar o daemon CSFS, mas não necessariamente usá-lo nas suas execuções. Para isso, basta adicionar a propriedade "use_local_root_directories = YES" à configuração do CSFS. Nesse caso, o SGA deve ter acesso aos repositórios de projetos e algoritmos do servidor. As propriedades "project_root_directory" e "algorithm_root_directory" devem ser obrigatoriamente configuradas para apontar para os repositórios.

Se o SGA não conseguir executar o daemon CSFS corretamente, ele ficará tentando reexecutá-lo indefinidamente. Se o log do SGA indicar esse comportamento, é aconselhável tentar executar a linha de comando da maneira que aparece no log manualmente (ex: "cd ../csfs; ./startCSFS []") e verificar a mensagem de erro. Os erros mais comuns estão listados na próxima seção.

Testando a configuração

Primeiro, conecte um cliente no servidor. Depois, rode um algoritmo no SGA configurado com CSFS (conferir se a linha de comando executada no SGA aponta para o sandbox).

Verifique se o algoritmo foi rodado com sucesso e se é possível ver o seu log de execução. Caso positivo, o teste foi bem sucedido.

Solucionando problemas

Daemon não está sendo executado corretamente

Se o daemon CSFS não executar, indicando um erro de socket (tanto via o script startCSFS, quanto via SGA):

[server-host:~/workspace/csbase/sgad/csfs] ./startCSFS --SERVER_LOG=../../logs/csfs.log --ROOT_DIR=../../src --HOST=server-host
Exception in thread "main" org.omg.CORBA.INITIALIZE: Could not create server socket  vmcid: 0x0  minor code: 0  completed: No
	at org.jacorb.orb.iiop.IIOPListener$Acceptor.createServerSocket(Unknown Source)
	at org.jacorb.orb.iiop.IIOPListener$Acceptor.init(Unknown Source)
	at org.jacorb.orb.iiop.IIOPListener.configure(Unknown Source)
	at org.jacorb.orb.etf.FactoriesBase.create_listener(Unknown Source)
	at org.jacorb.orb.BasicAdapter.configure(Unknown Source)
	at org.jacorb.orb.ORB.getRootPOA(Unknown Source)
	at org.jacorb.orb.ORB.resolve_initial_references(Unknown Source)
	at csfs.impl.Server.main(Server.java:97)
Processo CSFS (JAVA) terminado ou n?o iniciado.

É indicação de que:

  • Já existe um daemon CSFS na máquina;
  • Há algum outro processo usando a porta que ele está configurado para utilizar.

No primeiro caso, basta verificar com o comando:

[server-host:~] ps ax | grep csfs
  875 s000  S+     0:00.01 /bin/ksh ./startCSFS --SERVER_LOG=../../logs/csfs.log --ROOT_DIR=../../src --HOST=server-host
  877 s000  S+     0:01.50 /usr/bin/java -Xmx128m -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton -classpath libs/csfs/:libs/csfs/csfs.jar:libs/javautils/javautils.jar:libs/jacorb2.2:libs/jacorb2.2/jacorb.jar:libs/jacorb2.2/avalon-framework-4.1.5.jar:libs/jacorb2.2/logkit-1.2.jar:libs/jacorb2.2/antlr-2.7.2.jar:libs/jacorb2.2/concurrent-1.3.2.jar csfs.impl.Server ./server.ior.txt --SERVER_LOG=../../logs/csfs.log --ROOT_DIR=../../src --HOST=server-host

No segundo caso, verifique a porta com o comando netstat:

[server-host:~] netstat -anp | grep 10000
tcp6       0      0 10.0.16.44:10000        :::*                    LISTEN      26961/java

A configuração da porta é feita no arquivo orb_init.properties no diretório sgad/csfs/libs/csfs/:

OAPort 10000

Do lado do servidor, outra opção é configurar o parâmetro na linha de comando do script startCSFS:

[server-host:~/workspace/csbase/sgad/src] ./startCSFS --SERVER_LOG=../../logs/csfs.log --ROOT_DIR=../../src --HOST=server-host --PORT=10000

Do lado do SGA, a configuração também pode ser feita via parâmetro no arquivo sgad-cnf:

csfs = {
  properties = { HOST="sga-host", ROOT_DIR="../root/", PORT=10000}
}

Atualmente, a implementação do CSFS tem a limitação de que o daemon CSFS que roda do lado do servidor não pergunta ao SGA qual a porta que o daemon CSFS dele usa. Ao invés disso o daemon do servidor assume que o outro daemon usa a mesma porta que ele. Portanto, na versão atual não adianta tentar configurar portas diferentes para esses daemons. *

Arquivos não estão sendo copiados corretamente via SCP

Usuários diferentes

Se o daemon estiver utilizando o método scp para copiar os arquivos e o usuário que roda o servidor não for o mesmo do que roda o SGA, será necessário configurar o CSFS para fazer scp com nomes de usuário diferentes. Essa configuração fica no arquivo fileserver.properties do diretório sgad/csfs/libs/csfs/.

(...)

# Caminho para o scp
SCP_BINARY /usr/bin/scp

FILE_SEPARATOR /

USER my_username

A configuração deverá ser feita nos dois daemons CSFS! 

Máquinas não conseguem fazer scp corretamente

Caso os artefatos necessários para execução/gerados durante a execução (arquivos de saída, logs, código de retorno do algoritmo) não estejam conseguindo ser copiados entre os daemons CSFS, verificar o log dos dois daemons. Os logs se encontram no local indicado pelo parâmetro SERVER_LOG passado na execução. Todos os comandos scp executados pelo CSFS são logados. É recomendado rodar o comando logado manualmente e verificar porque ele não foi executado. Em alguns casos, o scp fica esperando uma resposta do usuário e, por isso, não completa sua execução. Isso acontece geralmente em dois casos:

  • Da primeira vez que é executado o scp entre duas máquinas: basta completar um scp manualmente da primeira vez. As seguintes funcionarão normalmente.
  • Caso seja requisitada a senha do usuário: é necessário configurar uma chave ssh, para que a autenticação seja feita automaticamente, sem a entrada de senha pelo usuário.
  • No labels