Infrastructure Access

In order to make the CERIT-SC computing infrastructure fault-tolerant as well as to allow the possibility of its specific setting/tuning, it is designed to be fully independent of the MetaCentrum computing infrastructure. Therefore, the jobs dedicated to run on the CERIT-SC nodes are managed by our own scheduling server (using the Torque scheduling system).

CERIT-SC computing infrastructure is vailable for all active MetaCentrum users automatically. New users have to submit a registration form to MetaCentrum. MetaCentrum membership is free for all persons from academic environment of the Czech republic with research objectives.

In spite of this fact, the jobs can be submitted to the CERIT-SC computing infrastructure both via the CERIT-SC frontend as well as MetaCentrum frontends:

Using the CERIT-SC frontend - once logged on the zuphux.cerit-sc.cz frontend (using the SSH protocol - log-in methods), the jobs are submitted in a common way using the qsub command:

$ ssh username@zuphux.cerit-sc.cz Password: <enter META password>

$ qsub <job's/nodes' properties>  <job script>

Note: To access the frontend using Kerberos v5 tickets, please, add the following lines to the section "domain_realm" of your /etc/krb5.conf file (alternatively, download the new /etc/krb5.conf file from MetaCentrum site):

[domain_realm]

    ...

    .cerit-sc.cz = ICS.MUNI.CZ
Using MetaCentrum frontends - when submitting a job via any of the MetaCentrum frontends (list of frontends and log-in methods), there has to be the wagap.cerit-sc.cz server (the CERIT-SC scheduling server) explicitly specified. This specification is performed via the "-q" option in the following way:

$ ssh username@arda.ics.muni.cz # or any of the other frontends Password: <enter META password>

$ qsub -q @wagap.cerit-sc.cz <job's/nodes' properties> <job script>

Our future goal is to ensure the interoperability between both the CERIT-SC and MetaCentrum scheduling servers, thanks to which it won't be required to explicitly specify the scheduling server - the jobs will be automatically exchanged between the servers based on their resource requirements. However, this functionality requires a non-trivial development of the Torque scheduling system, and thus will be provided in a later project stage.