.. _boas_praticas: Boas Práticas ============= .. contents:: Compartilhamento de Acesso -------------------------- Por medida de segurança e para evitar transtornos desnecessários, não se deve compartilhar a senha de acesso com terceiros, ainda que sejam membros de projetos, ou mesmo membros do GridUnesp. Outras pessoas com acesso à conta do usuário podem inadivertidamente apagar e/ou modificar aquivos, não sendo possível desfazer tais operações. Todavia, e desde que o usuário saiba o que está fazendo, é possível modificar as permissões de acesso a arquivos e pastas específios (utilizando o comando ``chmod``) para permitir o acesso de outros usuários. Solicitação de Suporte ---------------------- A maioria das dúvidas dos usuários podem ser respondidas consultando a seção :ref:`perguntas_frequentes`. Contudo caso as dúvidas persistam, os usuários podem enviar mensagem para a lista de suporte (``support.ncc@unesp.br``) com informações suficientes e adequadas para que a equipe de especialistas do GridUnesp consiga ter o melhor entendimento possível sobre a situação. Caso não estejam conseguindo resolver problemas em relação ao job (à simulação), os usuários podem enviar mensagem para a lista de suporte, sendo fundamental informações como: * a localização do script de submissão e dos arquivos e pastas de input; * a localização dos arquivos de log (*slurm-jobID.out*); * o comando usado para submeter o job; * e, se possível, o(s) número(s) do(s) job(s) em questão. .. _manutencao_dos_dados: Manutenção dos Dados -------------------- O GridUnesp não conta com sistema de backup. Isso significa que, em caso de falha irrecuperável, todos os dados do usuário podem ser perdidos. Dessa forma, é fortemente recomendável que o usário transfira os resultados de simulações para um computador local tão logo quanto possível, deixando no cluster do GridUnesp apenas aqueles arquivos e pastas que são estritamente necessários ao processamento de novas simulações. Ademais, como os recursos do cluster (armazenamento, processamento, etc.) são compartilhados por todos os membros, **o usuário não deve usar a conta do GridUnesp como local para guardar dados** pelos simples fato de que a capacidade do cluster é limitada. Caso o espaço em disco atinja 100% de uso, todo o sistema fica comprometido. Além disso, no GridUnesp não há política de quotas para nenhum dos pontos de montagem. Então é preciso ter em mente que o sistema é utilizado por outros usuários e, portanto, é sempre saudável e uma boa prática manter o ``/home/`` limpo, guardando apenas os arquivos necessários para a execução das próximas simulações. Para verificar quais arquivos/pastas estão ocupando mais espaço no ``/home/``, o usuário pode usar o seguinte comando no terminal: .. code-block:: bash du -scm $HOME/* Irá aparecer uma lista de arquivos/pastas com os tamanhos correspondentes (em MB). Apenas como exemplo, digamos que um usuário chamado *Spock*, cujo login no GriUnesp seja **spock** deseja deletar os seguintes arquivos e pastas: .. code-block:: bash /home/spock/programs/ /home/spock/Documents/ /home/spock/slurm-2848879.out /home/spock/slurm-2848880.out A partir de ``/home/spock/``, para apagar, basta usar o seguinte comando: .. code-block:: bash rm -rf programs Documents slurm-*.out .. attention:: Vale informar que algumas simulações (a depender da maneira como estão configuradas) acabam sendo salvas na partição ``/store/`` antes de serem copiadas para a partição ``/home``. A partição ``/store/`` é um *file system* compartilhado entre o nós de processamento. Em um processo normal, as simulações dos usuários escrevem no (leem do) disco desta partição e, ao final, são deletados de lá. Contudo, caso haja algum problema, a etapa de deleção não ocorre. Assim, com o tempo, o disco da partição ``/store/`` vai enchendo e, caso o usuário não apague os dados e o armazenamento atinja 100% de uso, o sistema inteira começa falhar, afetando o cluster como um todo. Por isso, também solicitamos fortemente aos usuários realizarem uma limpeza na respectiva área do ``/store/``. Para checar quais arquivos/pastas estão ocupando mais espaço, o usuário pode usar o seguinte comando no terminal: .. code-block:: bash du -scm /store/$USER/* Digamos que *Spock* deseja deletar as seguintes pastas: .. code-block:: bash /store/spock/2835861 /store/spock/2835862 /store/spock/2835866 Estando em ``/home/spock/``, basta dar o seguinte comando .. code-block:: bash rm -rf /store/spock/2835861 /store/spock/2835862 /store/spock/2835866 ou, caso queira deletar todo o conteúdo que lhe pertença nesta partição, basta usar simplesmente .. code-block:: bash rm -rf /store/spock/* Para mais informações sobre as partições, consulte a seção :ref:`informacao_sobre_o_storage`. .. _processamento_no_access2: Processamento no Access2 ------------------------ Os usuários não devem processar simulações diretamente no servidor **access2**. Esse servidor deve funcionar apenas como ponto de acesso ao ``/home/``, a partir do qual as simulações devem ser preparadas para submissão de jobs. Somente pré e pós processamentos que demandem um curtíssimo tempo de execução e pouca memória é que podem ser executados no servidor **access2**. Ou seja, é uma exceção. Em todas as demais situações, os usuários devem preparar os scripts de submissão de jobs para que as simulações sejam executadas nos nós de processamento. Por isso, caso a equipe do GridUnesp observe que o servidor **access2** esteja sendo usado para execução de aplicações que demandem muito tempo e muita memória, elas serão imediatemente canceladas para evitar que impactem negativamente na utilização do cluster pelos demais usuários.