Manual online do dvd::rip - versão 0.52.6 (parte 3)
Dividido em seis partes. Ir para:
Índice geral;
parte 1;
parte 2;
parte 2(cont);
parte 3;
parte 4;
parte 5;
parte 6;
>>próxima
Capítulo 3: Processamento em Cluster
3.1 - Passos adicionais na instalação
Primeiro deve-se estar seguro de que todos os módulos do Perl e programs necessários para o uso de cluster estejam instalados. As dependências para isso podem ser vistas nos capítulos sobre instalação e lista de dependências.
3.2 - Restrições
Algumas restrições devem ser observadas com cuidado:
- Não podem ser criados (S)VCDs;
- Não podem ser usado o modo de capítulos;
- Não se pode usar o núcleo PSU;
- Não se pode transcodificar um intervalo de telas (frames), sempre será transcodificado todo o filme;
- Os títulos devem ser copiados para o disco rígido, não se pode usar o modo "na hora" (on-the-fly) ou a transcodificação de imagens.
3.3 - Resumo da arquitetura
Um cluster do dvd::rip é composto dos seguintes componentes:
- Um computador com uma instalação completa do dvd::rip e do transcode, acesso a DVDs e espaço em disco localmente ou em um servidor NFS, onde todos os arquivos são armazenados.
- Um computador com uma instalação do dvd::rip, mas sem acesso à interface gráfica (GUI) e sem o transcode, onde os processos de controle do cluster estarão rodando. Este pode ser o mesmo computador do item 1 (o que usualmente é o caso).
- Um número qualquer de computadores com a instalação completa do transcode, o dvd::rip não é necessário nestes. Estes são os nós da rede para o cluster do transcode.
- O computador com a interface gráfica para o dvd::rip e os nós do transcode devem ter acesso ao diretório de trabalho, compartilhado via NFS ou algo similar. Não faz diferença qual será o servidor de NFS nesta rede.
- A comunicação entre os processos de controle do cluster e os nós transcode é feita via ssh. Todos os comandos para o transcode são calculados pelo processo de controla do cluster e executados via ssh em cada nó transcode. O dvd::rip assim que o controle computador que controla o cluster tem as chaves de acesso para autenticação no ssh. Isto significa que nenhuma senha deverá ser digitada manualmente.
Isto pode parecer confuso, mas na verdade todos os diferentes serviços descritos aqui, podem ser distribuídos arbitrariamente no hardware disponível. Pode-se até usar o modo cluster em
um único computador, o qual rodará todos os serviços:
- Interface gráfica do dvd::rip;
- Processo de controle do cluster;
- Nó do transcode (naturalmente que usando acesso local aos dados).
Neste caso estará sendo desperdiçado o uso de cluster para controle do trabalho, pois o dvd::rip não oferece nenhum tipo de benefício interno...
Um exemplo de instalação em dois nós se parece com:
- Primeiro computador executa os serviços:
- dvd:rip GUI;
- dvd::rip processo de controle do cluster;
- nó do transcode com acesso a armazenamento local;
- servidor NFS.
- Segundo computador roda os serviços
- nó transcode com acesso NFS aos dados do projeto.
3.3.1 - Aviso sobre segurança
Atualmente a arquitetura de cluster tem alguns problemas de segurança. Uma vez que o cluster tenha sido configurado é fácil usa-lo, porque não há senhas envolvidas ou outro tipo de restrição de acesso. A autenticação usando a chave de usuário ssh - em tese - permite que qualquer um com acesso ao seu cluster possa controlar o processo que gerencia o cluster, sem qualquer senha.
Esta estrutura está planejada para uma pequena rede local (LAN), onde os assuntos de segurança não são relevantes. Se há uma maior preocupação com segurança devem ser criadas contas especiais de acesso para o dvd::rip, as quais ficam restritas para somente poder executar comandos do transcode. Ou pode-se abandonar totalmente a idéia de usar cluster.
3.4 - Configuração da Rede
3.4.1 - Ajuste do SSH
Primeiro, uma boa base de comunicação ssh entre o processo de controle do cluster e os nós transcode deve ser ajustada. Não deve have a necessidade de digitar senhas em modo interativo para efetuar autenticações, isto porque o processo de controle do cluster deve ser capaz de executar comandos de modo autônomo e sem a interferência do usuário.
Na documentação do ssh podem ser encontrados mais detalhes. Esta é uma breve descrição das configurações necessárias para ter-se autenticação pode chave-de-usuário no OpenSSH.
Entre no sistema como o usuário sob o qual será executado o processo de controle do cluster (no respectivo computador onde isto ocorrerá) e verifique se este usuário tem uma chave pública:
ls -l ~/.ssh/identity.pub
Se este arquivos não existir deve-se executar este comando:
Seguindo as instruções,
apenas pressiona-se a tecla ENTER se lhe for pedido senha.
Então, o conteúdo do arquivo ~/.ssh/identity.pub deve ser adicionado no arquivo ~/.ssh/authorized_keys em cada um dos computadores nós de transcode. Após isto deve ser possível entrar, a partir do computador que controla o cluster, em qualquer um dos computadores do cluster sem que seja necessário digitar senha. Caso isto não esteja ocorrendo pode-se usar o comando 'ssh -v' para verificar se alguma mensagem indica o problema.
3.4.1.1 - Dicas sobre usar a versão 2 do protocolo SSH no OpenSSH
Os passos descritos acima funcionam tanto com a implementação Livre quanto com a comercial o SSH, mas somente se a versão 1 do SSH for aceita pelo servidor (o que roda o processo sshd). Se está sendo usando o OpenSSH e é necessário usar a versão 2 do protocolo SSH, seguem algumas instruções:
Criar as chaves pública e privada:
Como antes, pressiona-se ENTER como senha quando esta for pedida. Neste ponto, deve existir o arquivo ~/.ssh/rsa.pub. Adiciona-se este conteúdo ao arquivo ~/.ssh/authorized_keys e isto deverá permitir o uso do SSH2.
3.4.1.2 - Se o OpenSSH não encontra o transcode
Um outro problema comum com o OpenSSH é que os executáveis do transcode não podem ser encontrados e são rodados via ssh. Freqüentemente o diretório /usr/local/bin não está listado na variável de ambiente $PATH para conexões SSH, porém por omissão o transcode é instalado neste local e então não é encontrado.
A solução para esta caso é adicionar o /usr/local/bin no caminho (PATH) para o ssh usando o arquivo ~/.ssh/environment. Apenas adiciona-se a seqüência de diretórios (/usr/local/bin) como uma linha no ~/.ssh/environment em cada nó do cluster e então todos os executáveis serão encontrados.
echo $PATH":/usr/local/bin:/bin:/usr/bin" > ~/.ssh/environment
ou algum outro caminho onde tenham sido instalados os executáveis do transcode.
Á importante notar que o arquivo 'sshd.conf' (usualmente em /etc/ssh) deve contar a linha:
PermitUserEnvironment yes
de outro modo o arquivo que ajusta o ambiente para o shell do ssh (~/.ssh/environment) será ignorado.
3.4.2 - Ajuste do NFS
Observação: O modo de uso em cluster possui uma restrição a respeito da estrutura de diretórios que contém os dados. Os valores padrão para os diretórios vob/avi/temp
devem ser mantidos e o diretório raiz dos projetos não pode ser colocado fora do diretório base padrão que é configurado no formulário de preferências globais. De outra forma o acesso aos dados nos nós NFS falhará.
Todos os nós devem ter acesso ao diretório base do projeto, normalmente usando NFS. O diretório base do projeto deve ser exportado e montado em cada nó do cluster. Adiante será visto como apontar especificamente para o ponto de montagem em cada nó.
O exemplo a seguir mostra a configuração em uma estação (cujo nome é wizard) onde há um grande volume de disco montado em '/mega' o qual contém os projetos dvd::rip, então este é exportado assim:
# cat /etc/exports:
/mega *(rw)
Em um notebook este volume está montado no caminho /hosts/wizard/mega o qual é especificado por esta linha no /etc/fstab
wizard:/mega /hosts/wizard/mega nfs
Não é aconselhável usar a opção "soft" do NFS no /etc/fstab. Isto resulta em que, dependendo das circunstâncias, ocorram mensagens de erro em vez de repetir a tentativa de acesso e pode ser muito difícil localizar o problema estando-se neste modo "soft".
3.5 - Iniciar o processo de controle do cluster
Para iniciar o processo que controla o cluster usa-se este comando:
Onde o número '2' define o nível de registro de eventos (log). Para a maioria dos casos '2' é suficiente, pode-se aumentar este número para que mais mensagens apareçam na saída padrão (STDERR).
Um exemplo da saída de mensagens é mostrado a seguir:
Sun Feb 3 13:55:43 2002 Master daemon activated
Sun Feb 3 13:55:43 2002 ~np~dvd::rip~/np~ cluster control daemon started
Sun Feb 3 13:55:43 2002 Started rpc listener on TCP port 28646
Sun Feb 3 13:55:43 2002 Started log listener on TCP port 28656
Á possível omitir a inicialização manual do processo de controle do cluster, então a interface gráfica do dvd::rip (GUI) rodará o processo em segundo plano de modo automático no sistema local, no qual está a interface gráfica e com o nível '2' de registro. Na verdade só é preciso executar manualmente o processo de controle do cluster caso se deseja passar o parâmetro que ajusta o nível de registros, ou depuração, para um patamar acima de 2 ou case se deseja executar esse processo em um outro computador. Á uma questão de escolha.
3.6 - A configuração do Cluster
Quando as comunicações SSH e NFS já estiverem todas operacionais, então o próprio
dvd::rip necessita de alguns ajustes.
3.6.1 - Preferências globais
Ao iniciar a interface gráfica (GUI) e abrir o formulário de preferências, devem ser selecionadas as opções de cluster. Há basicamente três parâmetros para o modo de cluster. Pode ser configurado para que o processo de controle do cluster seja executado localmente na estação de trabalho do dvd::rip. De outra forma, terá que ser especificado o nome do computador na qual será executado esse processo.
Se for configurado como um processo loca de controle do cluster, ele será executado sob demanda caso não seja encontrado nenhum outro já em execução no sistema. Não deve ser modificada a porta TCP padrão.
3.6.2 - A janela de controle do cluster
Para abrir o menu de controle do cluster pode-se usar a combinação Ctrl-M ou selecioná-la a partir do menu - opção
Cluster/Control. Se o resultado for uma mensagem de erro, deve ser verificado se os dados colocados no formulário de preferências estão corretos e se o processo de controle do cluster está em execução.
A janela é dividida em quatro partes:
- a fila de projetos
- a fila de tarefas
- a lista de nós
- uma área de mensagens do processo de controle
Inicialmente as listas estarão vazias porque não foram configurados os nós e porque ainda não foram dadas tarefas ao cluster.
3.6.3 - Adicionar nós
Para adicionar nós à rede que estrutura o cluster clica-se no botão
Adicionar Nó ("Add Node") e a
Janela de edição de nós ("Edit cluster node") será aberta.
Essencialmente existem duas classes de nós: um nó local alguns nós remotos. O nó local executa o processo de controle do cluster, então não são necessários acessos SSH para enviar comandos neste nó. Normalmente este é o nó onde está o disco rígido, então não há tráfego NFS para acessar os dados.
Para os nós remotos o processo de controle do cluster usa comunicação via SSH para executar os comandos, e eles acessam dados via NFS ou algum outro protocolos de comunicação que cumpra a mesma função.
O dvd::rip passa as tarefas mais pesadas em entrada/saída para o nó com acesso local a disco, pois o acesso via rede pode torna-los muito lentos.
3.6.3.1 - O nó local
A imagem abaixo mostra a janela para um nó que apresenta a configuração (1) no exemplo de um cluster de dois nós, mostrado no item 3.3. Isto significa que o nó tem acesso local ao disco, o processo de controle do cluster roda nele - de modo que ele não é preciso ajustar um nome de usuário para o SSH.
 |
| Nó com acesso a dados locais e controle daemon de cluster |
3.6.3.2 - Nó remotos do transcode
A imagem abaixo mostra a configuração típica de um nó remoto do transcode com acesso via NFS, o ponto de montagem correspondente ao diretório de dados e o nome de usuário para as conexões SSH.
O dvd::rip usa o parâmetro
'-x' com o
ssh (acompanhado de
usuário@nome_do_computador) para executar os comandos no sistema remoto. Este parâmetro '-x' significa:
não tente estabelecer uma sessão gráfica remota. Caso isto não funcione (por exemplo, porque se está atrás de um firewall ou algo similar) é possível adicionar um outro comando ssh, com os parâmetros que funcionem.
 |
| Nó remoto apenas para transcodificação |
3.6.4 - Configuração de nó
Podem ser acrescentados opções especiais para o transcode em dado nós. Estas opções são adicionadas na chamada interna ao transcode, elas se sobreporão às respectivas opções que já tenham sido enviadas pelo dvd::rip. Por exemplo, pode-se usar o parâmetro
'-u 4,2' para aumentar o desempenho em uma máquina com dois processadores.
Case se esteja usando máquinas multiprocessadas, uma outra opção é configurar múltiplos nós para elas através de nós com nomes diferentes mas com o mesmo nome do computador (hostname). Para a maioria dos outros casos pode-se deixar em branco o espaço para o nome do computador, se o nome do nó já é um nome de computador.
 |
| Janela de controle de cluster com dois nós |
3.6.5 - Teste de nó
Com o botão "Test" é possível testar as configurações a qualquer momento, verificando se estão corretas. Surgirá uma janela que mostrará o resultado de vários testes, mostrando apenas "
Ok" ou "
Not Ok". Uma descrição mais detalhada em cada um dos testes onde houver falha, quando é mostrado o resultado de cada comando correspondente no nó, comparado com o comando executado na máquina local. Deste modo, é fácil verificar uma configuração errada no NFS, problemas de SSH ou se existirem versões diferentes do transcode em um ou mais nós.
3.7 - Trabalhando com clusters
Estado dos os ajustes funcionando corretamente... o próximo passo é iniciar um projeto em cluster
3.7.1 - Inserindo projetos no sistema
Primeiramente deve-se extrair (??rip??) e configurar o projeto como de costume. No exato momento de pressionar o botão
Transcode deve-se, então, usar o
Adicionar ao Cluster ("Add to Cluster") em substituição. A
Janela de controle do cluster será aberta, caso já não esteja aberta. Igualmente a janela de configuração de projeto em cluster aparecerá, quando então se poderão ajustar algumas propriedades.
3.7.2 - Propriedades de um projeto
Inicialmente pode-se escolher o número de telas (frames) por grupo (ou pedaço de conteúdo - chunk). O padrão é 10000, o que usualmente é adequado. Mas se a potência computacional entre os nós do cluster for muito diferente, pode-se diminuir este número para que os nós mais lentos não atrasem todo processamento do cluster, fazendo com que os nós mais rápidos tenham que esperar. Entretanto, reduzir em muito o tamanho dos grupos resulta em que uma segunda passagem de processamento (encoding), para aprimorar os resultados, perca o seu efeito , porque haverá pouco o material a ser analisado. Terão que ser feitos testes para que se obtenha empiricamente a melhor relação entre estes fatores.
Neste ponto, pode-se escolher se o arquivo AVI final deve ser dividido após o processamento e se os arquivos AVI temporários deve ser removidos quando não forem mais necessários. Esta opção deve ser adotada pois quando se está processando em cluster o projeto necessita três vezes mais espaço do que um projeto completamente local (não em cluster). Igualmente, os arquivos VOB podem ser removidos após a transcodificação, se os espaço em disco assim exigir...
 |
| Propriedades do projeto de cluster |
3.7.3 - Agendamento de projetos
Depois de todas as configurações, inclusive a do título, feitas, o projeto será adicionado à fila. O estado inicial do projeto é
não agendado. Podem ser adicionados vários projetos na fila do cluster e também ajustar a prioridade entre eles, movendo-os para cima ou para baixo na fila - usando os botões apropriados.
Então, ao pressionar o botão
Agendar projeto ("Schedule project") para cada projeto é iniciado o trabalho pelo cluster. O estado do primeiro projeto mudará para
rodando (running). Também, o estado de todos os nós trocarão de inativo (idle) para
rodando e então todas as tarefas que forem possível executar em paralelo assim o serão.
3.7.4 - Tarefas
A fila de tarefas mostra todas as atividades que precisam ser completadas. De modo geral, o trabalho é dividido em seis fases:
3.7.4.1 - Transcodificação do vídeo
Tantos nós quanto possível serão usados em paralelo durante esta fase. Cada um transformará um pedaço do conteúdo de MPEG para AVI, porém sem o audio.
 |
| Este é um diagrama do fluxo de trabalho do cluster |
3.7.4.2 - Transcodificação do áudio
Por motivos técnicos o áudio tem que ser transformado de modo independente do vídeo e não é possível quebrar esta tarefa em pedaços para que seja processada em paralelo. Somente se forrem selecionadas mais de uma trilha sonora ai sim um certo número de tarefas de transformação de áudio serão iniciadas.
3.7.4.3 - Juntando áudio e vídeo
O conteúdo de áudio da primeira trilha sonora selecionada e todos os pedaços do conteúdo de vídeo devem ser aglutinados e multiplexados em um único arquivo. Isto é feito pelo nó onde está o disco que armazena estes arquivos localmente.
3.7.4.4 - Adicionando mais trilhas de áudio
Trilhas de áudio adicionais podem ser ajuntadas ao resultado em
Merge video + audio.
3.7.4.5 - Juntando PSU's
Se o filme é composto de uma seqüência de conteúdos, os passos a descritos acima devem ser repetidos para cada unidade. Então os arquivos correspondentes deverão ser aglutinados.
3.7.4.6 - Divisão
Caso se deseje dividir o arquivo AVI que foi construído então este é a última etapa.
3.7.5 - Estado dos nós
Conforme já foi observado, o processo de controle do cluster verifica regularmente o estado dos nós rodando o transcode. Se um nó saí de linha a tarefa correspondente será cancelada automaticamente e posteriormente será assumida por algum outro nó. Á possível parar e iniciar os nós manualmente, usando os botões de controle correspondentes. A tarefa que estiver sendo processada no nó será cancelada. O nó que tiver sido parado não receberá tarefas, mesmo que ele esteja em linha com a rede. Deste modo pode-se retirar dinamicamente nós da rede quando o computador for necessário para outra atividade.
Pode-se remover um projeto de fila somente se ele não estiver ativo ou já houver terminado. Para interromper um projeto primeiro deverão ser parados todos os nós que estiverem trabalhando no projeto e só então ele poderá ser removido.
3.8 - Interface via navegador
O processo de controle do cluster ter um servidor de página, somente para leitura, que relata o estado do cluster via HTML. Deste modo é possível averiguar o andamento dos trabalhos através da Internet, sem a necessidade de usar a interface gráfica exportando a saída do 'X Window'.
O padrão é o processo de controle do cluster ão execute o servidor de página. Para que isto ocorra é necessário executar o 'dvdrip-master' manualmente, usando as opções '-w' e '-W':
 |
| Cheque seu cluster pela internet |
a '-w' ativa o servidor de página (nenhum processo adicionar será executado - o servidor de página é um componente interno do 'dvdrip-master'). E a '-W' é um parâmetro opcional e serve para definir a porta TCP na qual o servidor de página estará escutando. A porta padrão é a 8888.
A página mostrada é bastante simples. Á similar à interface gráfica (GUI) do dvd::rip, exceto pela possibilidade de modificar o estado do cluster. Pode-se selecionar um projeto que esteja na fila para examinar suas tarefas. Também é possível ligar e desligar a auto-atualização da página usando o controle na parte superior direita da página. O intervalo de recarga será de 5 segundos.
3.9 - Algumas observações sobre o funcionamento interno
O processo de controle do cluster do dvd::rip armazena o seu estado independentemente da estação onde está a interface gráfica. Isto significa que, uma vez que um projeto tenha sido inserido no cluster, modificações que venham a ser feitas com o dvd::rip não afetarão a operação do cluster. As configurações dos nós e de todos os projetos são armazenadas neste sistema.
A gerências das informações sobre o cluster são feitas através da janela de controle de cluster do dvd::rip. As estações de trabalho dvd::rip não armazenam localmente nenhuma informação sobre o cluster. A comunicação entre a interface gráfica e os demais processos é feita via protocolo TCP, o qual possibilita ao dvd::rip criar objetos e chamar seus métodos de modo transparente através da rede.
Complementarmente, o processo de controle do cluster escuta na porta 28656 e copia todas as mensagens de registro aos clientes conectados. Então pode-se, de modo simples, fazer 'telnet' para a porta com processo de controle para ver o que está ocorrendo (além de abrir a janela do processo de controle do cluster do dvd::rip, de onde se obtém as mesmas informações ;).
