Limita o número máximo de processos scp concorrentes em execução em um host

3

Estou enfrentando um problema em que tenho uma frota de servidores que contêm muitos dados. Cada host executa muitas instâncias de um processo específico p1, que faz várias conexões scp com outros hosts em paralelo para obter os dados que precisa processar. Isso, por sua vez, sobrecarrega bastante esses hosts e muitas vezes eles diminuem.

Estou procurando maneiras de limitar o número de processos scp simultâneos que podem ser executados em um único host.

A maioria dos links apontou para o MaxStartup & Configurações do MaxSessions em / etc / ssh / sshd_config que estavam mais relacionadas com a limitação do número de sessões ssh que podem ser feitas / iniciadas em qualquer ponto determinado, etc.

Existe um arquivo de configuração específico para scp que pode ser usado aqui? Ou existe uma maneira no nível do sistema para limitar o número de instâncias de um processo / comando específico que pode ser executado simultaneamente ao mesmo tempo?

    
por surekav 20.11.2014 / 07:45

1 resposta

2

scp em si não tem esse recurso. Com o GNU, você pode usar o comando parallel (de semáforo ) para limitar arbitrariamente processos concorrentes:

sem --id scp -j 50 scp ...

Para todos os processos iniciados com o mesmo sem , isso aplica um limite de 50 instâncias simultâneas. Uma tentativa de iniciar um processo 51 irá aguardar (indefinidamente) até que um dos outros processos saia. Adicione --id para manter o processo em primeiro plano (o padrão é executá-lo em segundo plano, mas isso não se comporta da mesma forma que um processo em segundo plano do shell).

Observe que o estado é armazenado em --fg , portanto, isso não funcionará como esperado se você tiver vários usuários usando ${HOME}/.parallel/ , talvez seja necessário um limite inferior para cada usuário. (Também deve ser possível substituir a variável de ambiente scp ao invocar HOME , certificar-se de que sem permite a gravação em grupo e modificar as permissões para que compartilhem o estado, embora eu não tenha testado isso intensamente, YMMV.) p>

umask requer apenas parallel e alguns módulos padrão.

Você também pode considerar usar perl onde N é um limite de transferência em kBps, selecionar uma codificação específica (para velocidade, dependendo da segurança necessária) ou desativar a compactação (especialmente se os dados já estiverem compactados) para reduzir ainda mais Impacto da CPU.

Para scp -l N , ssh é efetivamente um canal e uma instância scp é executada em cada extremidade (a extremidade de recebimento é executada com a opção scp não documentada). Em relação a -t , isso não ajudará, "sessões" são multiplexadas em uma única conexão SSH. Apesar da copiosa informação incorreta em contrário, MaxSessions limita somente a multiplexação de sessões por conexão TCP, não qualquer outro limite.

O módulo PAM MaxSessions suporta a limitação de logins simultâneos, portanto, se O OpenSSH é construído com o PAM, e pam_limits está presente no usePAM yes que você pode definir o limite por nome de usuário, associação ao grupo (e mais). Você pode definir um sshd_config para limitar os logins em maxlogins . No entanto isso conta todos os logins por usuário, não apenas os novos logins usando apenas /etc/security/limits.conf , e não apenas ssh , então você pode ter problemas a menos que tenha um ID de usuário scp dedicado . Uma vez ativado, ele também se aplicará a sessões ssh interativas. Uma maneira de contornar isso é copiar ou ligar simbolicamente o binário scp , chamando-o de sshd , então você pode usar um arquivo de configuração PAM separado, ou seja, sshd-scp (chamadas OpenSSH /etc/pam.d/sshd-scp com o "nome do serviço" definido como o binário foi invocado como). Você precisará executar isso em uma porta (ou IP) separada, e usar um pam_start() separado provavelmente também será uma boa ideia. Se você implementar isso, então sshd_config falhará (código de saída 254) quando o limite for atingido, então você terá que lidar com isso em seu processo de transferência.

(Outras opções incluem scp e ionice , isso pode fazer com que cpulimit sessões esgotem o tempo limite ou travem por longos períodos, causando mais problemas.

A maneira antiga de fazer algo semelhante é usar scp e atd , mas isso não oferece ajuste de simultaneidade, enfileira e inicia processos quando a carga está abaixo de um limite específico. Uma nova variação é Spooler de Tarefa que suporta tarefas de enfileiramento e execução em um modo sequencial / paralelo mais configurável, com suporte à reconfiguração do tempo de execução (por exemplo, alterando tarefas enfileiradas e configurações de simultaneidade), embora não ofereça carga ou controle relacionado à CPU em si.

    
por 20.11.2014 / 13:57