- Limited data restoration. The data in your home directory can be restored from snapshots going back 3 days. Anything beyond 3 days can not be retrieved. Data stored on outside your home directory such as a group share will be subject to other data-lifetime policies that is setup at the time of purchasing the respective Turbo NFS volume. You are responsible for mitigating your own risk. We suggest you store copies of hard-to-reproduce data in your home directory or on HIPAA-aligned storage you own or purchased from Turbo.
- System usage is tracked and is used for billing reports and capacity planning. Job metadata (example: walltime, resource utilization, software accessed) is stored and used to generate usage reports and to analyze patterns and trends. ARC may report this metadata, including your individual metadata data, to your adviser, department head, dean, or other administrator or supervisor for billing or capacity planning purposes.
- Maintaining the overall stability of the system is paramount to us. While we make every effort to ensure that every job completes with the most efficient and accurate way possible, the good of the whole is more important to us than the good of an individual. This may affect you, but mostly we hope it benefits you. System availability is based on our best efforts. We are staffed to provide support during normal business hours. We try very hard to provide support as broadly as possible, but cannot guarantee support on a 24 hour per day basis. Additionally, we perform system maintenance on a periodic basis, driven by the availability of software updates, staffing availability, and input from the user community. We do our best to schedule around your needs, but there will be times when the system is unavailable. For scheduled outages, we will announce them at least one month in advance on the ARC home page; for unscheduled outages we will announce them as quickly as we can with as much detail as we have on that same page. You can also track ARC at Twitter name @umichARC.
- Armis2 is intended only for non-commercial, academic research and instruction. Commercial use of some of the software on Armis2 is prohibited by software licensing terms. Prohibited uses include product development or validation, software use supporting any service for which a fee is charged, and, in some cases, research involving proprietary data that will not be made available publicly regardless whether the research is published. Please contact email@example.com if you have any questions about this policy, or about whether your work may violate these terms.
- Data subject to export control and HIPAA regulations may be stored or processed on the cluster. The appropriate storage solution for storing export controlled information or PHI that can be accessed on the Armis2 cluster is the Turbo-NFSv4 with Kerberos offering (see the Sensitive Data Restrictions for Turbo-NFSv4 with Kerberos for further details). It is your responsibility, not ARC’s, to be aware of and comply with all applicable laws, regulations, and universities policies (e.g., ITAR, EAR, HIPAA) as part of any research activity that may raise compliance issues under those laws. For assistance with export controlled research, contact the U-M Export Control Officer at firstname.lastname@example.org. For assistance with HIPAA-related computational research, contact the ARC liaison to the Medical School at email@example.com.
Users should make requests by email to firstname.lastname@example.org:
- Renew allocations at least 2 business days before your current allocation expires in order to have the new allocation provisioned before the old one expires.
- One day in advance, request users be added to Armis2 accounts you may administer.
Users are responsible for security and compliance related to sensitive code and/or data. Security and compliance are shared responsibilities. If you process or store sensitive university data, software, or libraries on the cluster, you are responsible for understanding and adhering to any relevant legal, regulatory or contractual requirements.
Users are responsible for maintaining MCommunity groups used for MReport authorizations.
Users must manage PHI (protected health information) appropriately and can use the following locations:
- /home (80 GB quota)
- /scratch (more information below)
- Any appropriate PHI-compliant NFS volume mounted on Armis2
SCRATCH STORAGE POLICIES
Every user has a /scratch directory for every Slurm account they are a member of. Additionally for that account, there is a shared data directory for collaboration with other members of that account. The account directory group ownership is set using the Slurm account-based UNIX groups, so all files created in the /scratch directory are accessible by any group member, to facilitate collaboration.
There is a 10 TB quota on /scratch per root account (a PI or project account), which is shared between child accounts (individual users).
Users should keep in mind that scratch has an auto-purge policy on unaccessed files, which means that any unaccessed data will be automatically deleted by the system after 60 days. Scratch file systems are not backed up. Critical files should be backed up to another location.
LOGIN NODE POLICIES
Appropriate uses for the login nodes:
- Transferring small files to and from the cluster
- Creating, modifying, and compiling code and submission scripts
- Submitting and monitoring the status of jobs
- Testing executables to ensure they will run on the cluster and its infrastructure. Processes are limited to a maximum of 15 minutes of CPU time to prevent runaway processes and overuse.
Any other uses of the login node may result in the termination of the process in violation. Any production processes (including post processing) should be submitted through the batch system to the cluster. If interactive use is required then you should submit an interactive job to the cluster.