Desafio: Controlar vários Shells Scripts ao mesmo tempo !!!!

AprendiNoLinux
(usa Ubuntu)

Enviado em 29/08/2011 - 12:58h

Eu tenho que resolver de uma forma ou de outra este problema. Existe um tópico que está bombando que trata de algo similar: http://www.vivaolinux.com.br/topico/Shell-Script/Varios-scripts-ao-mesmo-tempo/?pagina=3&num_por...

Já entramos até na jogatina rsrs aqui e as apostas do truco já estão em 9.

A partir deste momento, vou tentar resolver o meu problema e tumaticamente tentar resolver esta pendência aqui: http://www.vivaolinux.com.br/topico/Shell-Script/Varios-scripts-ao-mesmo-tempo/?num_por_pagina=12&am...

O meu problema é:

1 - Disparar muitos scripts de tempos em tempos ao mesmo tempo. Muitos são mais de 100.
2 - Ter o controle da quantidade que está sendo executada.
3 - Manter log das atividades de cada serviço e dentro, cada processo.
4 - Ser flexível para enviar e até mesmo coletar informações. Um exemplo é lembrar de fazer backup e ele deve dar conta do recado.
5 - Permitir que outras máquinas possam participar do serviço (vai ficar pra outra etapa).
6 - Dividir o máximo as rotinas para acompanhamento de cada unidade de trabalho.
7 - Usar o máximo de funções para reaproveitamento futuro.

oops: Tenho 5 dias pra resolver este protótipo e 10 dias para resolver o meu problema.

Sugestões sempre serão bem vindas. :)

AprendiNoLinux
(usa Ubuntu)

Enviado em 29/08/2011 - 13:01h

#!/bin/bash
#
#: package: transfer.sh (***)
#: file: prototipo.include.sh
#: since: 2011-08-28 07:33 (GMT -03:00)
#: author: Geraldo T. Albuquerque - Twitter: @AprendiNoLinux
#: version: 0.03 Alfa
#:-----------------------------------------------------------------------------
#: Detalhes: Protótipo de operação envolvendo o envio e controle de arquivos
#: usando o controle via pipes.
#: Operações: + Conferir se já está em operação.
#: + Registrar em log.
#: + Se não está em operação, pode iniciar atividades.
#: + Registrar em log.
#: + Se já está em atividade, abortar carregamento, já está no ar.
#: + Registrar em log.
#: + Usar arquivo de configurações.
#: + Registrar em log.
#: + Testar se configuração é válida.
#: + Registrar em log.
#: + Salvar cada operação finalizada em diretório.
#: + Registrar comandos e finalização em log.
#: + Pegar serviço a ser feito em diretório.
#: + Registrar em log.
#: + Finalizar processo de serviço.
#: + Registrar em log.
#: + Limpar diretório de serviço para ser iniciado novamente.
#: + Finalizar registro deste serviço no log.
#:-----------------------------------------------------------------------------
#: TODO: Cada serviço deverá ter um log separado.
#: Sempre que for iniciado um serviço, será aberto um novo arquivo de log.
#: Todos os processos de um determinado serviço ficarão no log.
#:-----------------------------------------------------------------------------
#: FIXME: Procurei copiar a estrutura que estou usando de outros scripts para
# adaptar este protótipo. Se encontrar bugs avise. ;)
#:-----------------------------------------------------------------------------

# Carregando todas configurações e já incluindo as bibliotecas de código.

source conf.sh

# Loop principal do aplicativo.
function main()
{
:
echo "Carregando aplicativo"
}
echo Verificando SOURCE_CHECK_AMBIENTE é: $SOURCE_CHECK_AMBIENTE

main {$@}

exit

AprendiNoLinux
(usa Ubuntu)

Enviado em 29/08/2011 - 13:05h

#!/bin/bash
#
#: package: transfer (***)
#: file: conf.sh
#: since: 2011-08-28 07:33 (GMT -03:00)
#: author: Geraldo T. Albuquerque - Twitter: @AprendiNoLinux
#: version: 0.04 Alfa
#------------------------------------------------------------------------------
#: objectives: Montar o ambiente de variáveis do aplicativo
#------------------------------------------------------------------------------
#: comments: coleta o máximo de infos do bash e do aplicativo. (Gambiarra)
#: Geralmente eu separo as variáveis de ambiente em outro arquivo.
#------------------------------------------------------------------------------
#: TODO: Indica uma tarefa a ser feita, pendência.
#: FIXME: Use para indicar um bug conhecido e precisa ser arrumado
#: XXX: Recado importante no local. Pedindo ajuda para solução, help-me.
#------------------------------------------------------------------------------
[ "$DIR_INSTALL" ] || DIR_INSTALL="$PWD"

# Variável que irá controlar se a instalação está OK em qualquer momento.
# Inicializada em 0 ( não OK ) É obrigado editar para ter certeza que vc
# sabe quais são as configs. Também poderá alterar alguns diretórios.
INSTALL_OK=0


# Contém o caminho completo ao home do usuário.
# Poderá ser usado como um caminho raiz para seus diretórios internos.
# Se mudar este valor por padrão, mudará todas localizações do arquivos.
# Todas as variáveis de diretórios herdam o que está definido em _HOME
# Tome cuidado e confira a sua estrutura de diretórios.
# Note que se você mudar o endereço da variável _HOME, irá ajustar todos os
# demais abaixo. Na dúvida, consulte o arquio meuambiente.tmp que será gerado.
_HOME="$HOME"

# Local base da aplicação. No protótipo, tudo deve estar abaixo de:

DIR_BASE="${_HOME}/transfer"

# Contém o editor preferencial, ex: nano, mcedit, etc...
_EDITOR="$EDITOR"

# Diretório atual PWD formato: /home/usuario/TESTES/v1 (padrão local)
# Diretório atual PWD formato: /home/usuario/TESTES/VIRTUAL (padrão SERVER)
# Diretório ANTERIOR formato: /home/administrador
_DIR_ATUAL="$PWD" # Deve ser o diretório do INSTALL
_DIR_ANTERIOR="$OLDPWD" # Onde estava antes de entrar aqui.

# Caminho PATH, formato: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
_PATH="$PATH" #
_PATH_SHELL="$SHELL" #/bin/bash

# PID do AGENTE ativo de SSH, formato: pid NNNN
_SSH_AGENT_PID="$SSH_AGENT_PID"

# Nome do usuário conectado, USER ou USERNAME, ex: meunome
_USER="$USER"
_USERNAME="$USERNAME"

# Qual o Id do usuário atual. Nas duas formas básicas. Se 0 (zero) é root.
_USER_ID="$(id -u)"
_USER_UID="$UID"

# HOSTNAME ou nome da máquina.
_HOSTNAME="$HOSTNAME"

# Controle de separador padrão do shell. Cuidado com esta variável.
# Para atribuir novo valor: IFS=: ( padrão normal é: ' \t\n' )
# Após usar, lembrar de retornar ao original: IFS="_IFS_ORIGINAL"
_IFS_ORIGINAL="$IFS"

#Executa as configurações do local.

DIR_INSTALL="${DIR_BASE}"

# Raiz do diretório absoluto para todos arquivos temporários.
# Qualquer diretório temporário será criado abaixo dele.
# Caso não exista, diretório será criado.

CONF_TMP="/tmp"
DIR_TMP_LOCAL="${DIR_BASE}${CONF_TMP:-${DIR_BASE}/tmp}"

# Local base onde irã ficar os Scripts personalizados.
# Cada tipo de aplicação deverá ter o seu próprio diretório para os Scripts.
# Muitas vezes poderá ser o próprio diretório do DIR_BASE.
# Note, a pasta de SCRIPTS é idenpendente de onde está sendo feito o trabalho.

DIR_SCRIPTS="${DIR_BASE}/libs" # Normalmente é outro diretório.

# Local onde ficarão todas as bibliotecas reaproveitáveis de código.
# Todos Scripts deverão compartilhar este endereço.
# Para o desenvolvimento, a variável está em sub-diretório do DIR_BASE
# Será movida futuramente após liberação da versão a outro local.
# Não tem importância o local onde estão os outros Scripts.
# As bibliotecas não precisam saber de seus diretórios.
# Quem precisa saber são os Scripts.
# Bibliotecas poderão verificar se o código que está solicitando seu
# trabalho é incompatível. Restrições de versão serão impostas.

DIR_LIBS="${DIR_BASE}/libs"

# local físico onte estarão os Scripts especializados das tarefas.
# Se nova versão no servidor remoto, atualização será automática.
# Este é o local REAL onde os Scripts estarão.
# Dependem da variável DIR_SCRIPTS e não de DIR_BASE, faz grande diferença.
# Neste momento, Scripts deverão estar ao alcance do usuário.
# Só um facilitador para os testes. Serão movidos a outro local furamente.

DIR_APLICATIVO="${DIR_SCRIPTS}"

# Diretório de bibliotecas de código reaproveitável.
# Se nova versão no servidor remoto, atualização será automática.

DIR_BIBLIOTECAS="${DIR_LIBS}"

# Caixa de serviço da máquina que irá realizar as operações.
# Se não existe, irei abortar a operação.
# Na versão final, a caixa de serviço deve ter arquivo de assinatura.

CONF_SERVICO="/service"

# Diretório físico dos serviços a serem realizados.

DIR_SERVICO="${DIR_BASE}${CONF_SERVICO}"

# Caixa que contém os serviços a serem realizados. Local RELATIVO.
# teste no diretório RECEBE porque não é possível neste momento simular vários.
# Dentro do diretório service, cada arquivo terá o comando dentro.
# No protótipo, os endereços serão os mesmos para alguns casos.

CONF_RECEBE="/recebe"

#Diretório físico do local para onde serão enviados os arquivos.

DIR_RECEBE="${DIR_BASE}${CONF_RECEBE}"

# Local RELATIVO para alocação dos pipes de comunicação.

CONF_PIPES="/pipes"
DIR_PIPES="${DIR_BASE}${CONF_PIPES}"

# Configuração do prefixo dos pipes para os serviços.
CONF_PREFIX_PIPES="service_pipe_"

# Local relativo para gravação de logs.

CONF_LOGS="/logs"
DIR_LOGS="${DIR_BASE}${CONF_LOGS}"

# Configuração do prefixo dos pipes para os serviços.
# Quando o serviço entrar em operação, o nome do arquivo de log vai ganhar
# o nome do serviço em operação. Geralmente será a data e hora minuto.
# Vários processos irão usar o mesmo log. Cada serviço terá o seu próprio log.

CONF_PREFIX_LOGS="log_service_"

# Local relativo ao que você deseja que seja enviado ao serviço.
# Quando um serviço está em operação, o diretório serviço contém arquivos.
# Sempre que um serviço for terminado, o diretório serviço estará vazio.
# Quando for iniciar um serviço, o sistema irá ler o diretório envio.
# Sempre o diretório envio deverá conter os arquivos para o próprixo serviço.

CONF_ENVIO="/envio"
DIR_ENVIO="${DIR_BASE}${CONF_ENVIO}"

# Prefixo dos Arquivos dentro do diretório envio.
# Dentro do arquivo cada linha poderá conter um Script a ser processado.
# Neste linha o Script poderá receber os parâmetros necessários.
# exemplo: arquivo: ./service_lj_01.sh
# parâmetros "$01 $02 $03 $04"
# Então a linha ficaria assim: ./service_lj_01.sh par1 par2 par3 etc...
# Se tiver mais de uma linha, adicione da mesma forma.
# é importante saber que o prefixo é sempre igual conforme abaixo.
# Se não quiser passar parâmetros, cada linha conterá apenas o
# endereço completo onde o Script estará e nada mais.
# A sua criatividade é que vai comandar. Escolha a melhor no seu caso.
CONF_FILES_PREFIX_ENVIO="service_"

# XXX: Coletar o prefixo das variáveis DIR_* para teste de uma função
# XXX: que irá verificar a existência dos diretórios de configuração.
# XXX: Testar se tem permissões para gravar, ler e criar.
# XXX: Parâmetro adicional poderá ser passado se não for obrigatório.
# XXX: Protosuário deve ser alertado se faltar algum diretório.
# XXX: Exemplo: Diretório envio deve existir. Se falhou, aplicativo deve parar.

#: FIXME: É possível automatizar este processo ?
# Será usada ao longo do aplicativo para evitar carga de source desnecessário.
SOURCE_CHECK_AMBIENTE="${BASH_SOURCE[0]}"

if [ -e "$DIR_SCRIPTS/libs.sh" ]
then
echo " Tudo Ok seguindo em frente, linha: $BASH_LINENO"
source "$DIR_SCRIPTS/libs.sh" #Carrega bibliotecas de funções.
else
echo "Não encontrou arquivo fundamental. Aplicativo irá abortar...."
read -t 5
exit 1
fi

set > meuambiente.tmp

AprendiNoLinux
(usa Ubuntu)

Enviado em 29/08/2011 - 13:06h

Se você está acompanhando, qual deve ser a fase 3 ?

Sugestões ?

hudyfx
(usa Outra)

Enviado em 29/08/2011 - 21:51h

nossa que negócio complicado... essa eu sabia melhor com maçãs rsrsrs
cara... pq vc num usa o mysql para te ajudar gerenciar os diversos scripts?
se eu tivesse um problema desse tamanho eu criaria uma tabela, orientava os mais de 100 scripts que em um certo período eles deveriam dizer seu status, assim:
estado de execução= 1 ativo, 2 aguardando, 3 parado

sicript1 = 3
sicript2 = 2
sicript3 = 1
sicript4 = 2
sicript5 = 3
sicript6 = 3

com base nessa tabela, sempre atualizada pelos scripst, da pra saber em que pé anda o funcionamento de todos.
usaria também outra tabela para controlá-los, no mesmo naip da outra:

vida dos scrips:

estado = 1 viverás , 2 morrerás

sicript1 = 1
sicript2 = 2
sicript3 = 1
sicript4 = 2
sicript5 = 1
sicript6 = 1

de tempos em tempos, na virada de cada loop do script, ele pode chamar uma função que acessa o banco de dados e verifica qual deve ser o seu estado.

tipo assim...

if [ $(echo `mysql -u u_script -psenha -e "select STATUS from VIDA_SCRIPT where id=1" CONTROLE` | cut -d" " -f2) -eq 2 ]; then
exit
fi

daria pra fazer isso usando um arquivo de texto, o problema é que seriam varios scripts ao mesmo tempo escrevendo no mesmo arquivo, uma hora ele iria se 'corromper' ( e ir para o mundo das drogas rrsrsrs), como isso o mysql se vira para gerenciar os acesso es tal sem muita dor de cabeça....

oq vc acha?

AprendiNoLinux
(usa Ubuntu)

Enviado em 30/08/2011 - 00:07h

Meu carríssimo @hudyfx , tudo é uma questão de aprendizado rrs :)

Poderia contar uma ESTOrinha, mas vou ficar quieto. Vou apresentar números pq acho melhor.

[citando]cara... pq vc num usa o mysql para te ajudar gerenciar os diversos scripts?[/citando]

Hoje está assim :) E não tá dando conta.

[citando]
se eu tivesse um problema desse tamanho eu criaria uma tabela, orientava os mais de 100 scripts que em um certo período eles deveriam dizer seu status, assim:
estado de execução= 1 ativo, 2 aguardando, 3 parado
[/citando]

Certo. Você tem razão. Preciso de servidor potente. Como ter servidor potente está fora de questão, preciso distribuir os trabalhos entre várias máquinas.

[citando]
de tempos em tempos, na virada de cada loop do script, ele pode chamar uma função que acessa o banco de dados e verifica qual deve ser o seu estado.
[/citando]

Este tempos tem tempos estou falando em cerca de 1 minuto de intervalo. Os crons não conseguem trabalhar com menos tempo. O Mysql consegue, mas não gerencia os processos em background. Nem toma conta de gravações em disco e quantidade de arquivos nos diretórios. Se vocẽ tem dentro de cada diretório cerca de 20mil a 40mil arquivos por hora, e sem um servidor potente para dar conta do recado, tudo fica mais complicado.

Cada caso é um caso. Como já disse antes, existe várias formas de se fazer sistema. Cada um tem uma forma de resolver um problema e todas podem estar igualmente corretas.


[citando]
daria pra fazer isso usando um arquivo de texto, o problema é que seriam varios scripts ao mesmo tempo escrevendo no mesmo arquivo, uma hora ele iria se 'corromper' ( e ir para o mundo das drogas rrsrsrs), como isso o mysql se vira para gerenciar os acesso es tal sem muita dor de cabeça....

oq vc acha?
[/citando]

Eu acho que o mysql já deu o que tinha que dar. Ele está pendurando os processos.
A resposta do servidor sobrecarregado com um número elevado de conexões torna tudo mais lento.
A única chance que tenho é separar o servidor exclusivamente para mysql.
Separar uma máquina para ser a servidora de scripts.
Usar outras 50 máquinas para fazer vários processamentos pesados e tratar as infos.
Infos tratadas, vamos enviar ao mysql.

Qual o número diário de linhas por dia no mysql ? de 3.000.000 a 5.000.000 milhoes dia. De uma tabela de exemplo. As outras são bem menores. Antes alguns dados precisam de depuração.
Quantos serviços por dia ? 1.000 a 2.000, depende.
Quantos processos por dia ? 100.000 tô chutando rrs, nem eu sei.

A solução ?

Não posso fazer em nuvem.
Distribuir o processamento de informações em várias máquinas e replicar o banco em outras duas máquinas que serão usadas apenas para consultas.
Gravar é mais rápido do que executar as queries via de regra.

Se manipular esta quantidade de informação já é complicado usando crons com disparadores em scripts de php que consomem muita memória, fico imaginando jogar o resto para o coitado do mysql gerenciar.

Nos meus testes, os processamentos em shell distribuídos sem o uso do cron está sendo pelo menos 10 a 50 vezes mais rápido do que é hoje usando o tripé, cron, php e mysql.

Nunca se deve esquecer que nas máquinas, qualquer dado, informação é na prática um arquivo. Alocado em partes pequenas, médias ou grandes. Depende de como esta área está formatada. Gravar infos seja em banco ou arquivos de texto, diretórios ocupam I/O.

Não sou expert no tema. Só estou comparando os tempos do que tenho feito na base da gambiarra.

Até o cabeamento e roteadores devem ser trocados para que a demanda possa ser aumentada.

E a pergunta continua. Qual o próximo passo para a fase 3 ?

Outras opiniões para a solução são bem vindas sempre.

Ainda não tenho a solução concreta. Estou enxergando uma luz, mas não sei se o caminho está correto.

hudyfx
(usa Outra)

Enviado em 30/08/2011 - 01:33h

nossa que dilema... foi mal por não ter ajudado muito...
o que mais me intriga é o fato de ser (para um problemão desses) tudo feito em shell script.
gosto muito do shell script mas acredito que ele tem suas limitações...
e ja que o lance é controle de processos e uso de memoria, programar essa pipoca em C seria mais plausível. Aja vista que seria muito mais facil de trabalhar as informações na memoria através de uma hash table, e redirecionar os processos em tempo de execução (nem sei se da pra fazer isso em shell script). Alem disso usar threads (linha de execução de um programa, que executa “paralelamente” com o restante do código do programa) e por ai vai... Um programa bem feito pode reduzir em muito essa lista de recursos, pra poder ver tudo funfando numa boa...
bom é isso ai...

"vamo lado a lado na caminhada pra ve até onde vai dar essa sintonia brow" rsrsrs

removido
(usa Nenhuma)

Enviado em 30/08/2011 - 04:18h

@AprendiNoLinux Lembra do que eu disse lá no começo? Olha ai você entrando em ação, exatamente da maneira que descrevi rsrsrs

Enquanto isso eu fico aqui quetinho.... só observando ...

http://goo.gl/9cwCx

hudyfx
(usa Outra)

Enviado em 30/08/2011 - 10:10h

rsrsr como esse gato foi parar ali?! rersrsrsrs
parece o gato da minha prima ele se chama "improvavel"
nunca se sabe qual sera seu próximo movimento rsrsrsr

AprendiNoLinux
(usa Ubuntu)

Enviado em 30/08/2011 - 11:59h

Fala @mrk3004 o profeta kkkk ;)


Não para não @hudyfx , pode dar os palpites a vontade.
Onde você lê pipes, pense sempre que na prática são arquivos textos que de alguma forma estão controlando as operações. A vantagem de usa-los é que o acesso será exclusivo. Posso ter um número grande de máquinas e ninguém vai entrar no código da outra.

Vou pensar como fazer o lance do status sugerido para processos. :) O serviços creio que o melhor é pipe mesmo. Salvo me convença do contrário.

AprendiNoLinux
(usa Ubuntu)

Enviado em 02/09/2011 - 12:07h

Alguma sugestão extra ?