- Infos im HLRS Wiki sind nicht rechtsverbindlich und ohne Gewähr -
- Information contained in the HLRS Wiki is not legally binding and HLRS is not responsible for any damages that might result from its use -

Storage usage policy: Difference between revisions

From HLRS Platforms
Jump to navigationJump to search
(35 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This page describe how to handle data within HLRS computing environment.  
This page describes how to handle data within HLRS computing environment.  


Please be aware, storage ressources are are optimized for bandwidth of large parallel IO operations. This requires lots of components like disks, controllers, network connections, ... and make it expensive. To get the maximum  
Please be aware, storage resources are optimized for a particular usage. For example
benefit for all Users, following extra short guidlines should be read.
work space filesystems are tuned for bandwidth of large parallel IO operations. This  
requires lots of components like disks, controllers, network connections, ... and makes it expensive. To get the maximum benefit for all users, following ''extra short'' guidelines
should be read.


'''Important Notice!''' No Backup on any filesystem. Please copy important data into the archive.
'''Important Notice!''' No Backup on any filesystem. Please copy important data into the archive.


Following filesystems are available:
Following filesystems are available:
* Home Directory - this storage type is availabel on all compute ressources within HLRS  network. Users should store e.g. profiles, script files for workflow tasks, sources for programm develpment, ... But do not use this dircetory for number crunching (esapecially on large parallel) jobs!
* Home Directory - this storage type is available on all compute resources within HLRS  network. Users should store e.g. profiles, script files for workflow tasks, sources for program development... But do not use this dircetory for number crunching (especially on large parallel) jobs!
* The workspace - here users jobs read / write large amount of data. IO has to be optimized to get considerable performance (e.g. use of optimized IO libraries), if unsure, please feel free to contact your project supervisor.
* The workspace - here users jobs read / write large amount of data. IO has to be optimized to get considerable performance (e.g. use of optimized IO libraries), if unsure, please feel free to contact your project supervisor.
* TMP directory. This is an "in-memory" filesystem, used for small temporary files. All data will be removed at the end of the job. Each node has its own TMP directory, not shared with other nodes, fast but small.  
* TMP directory. On almost all compute hosts, this is an "in-memory" filesystem, used for small temporary files. All data will be removed at the end of the job. Each node has its own TMP directory, not shared with other nodes, fast but small.
* HPSS - mid term storage system, here users are able to keep permanent data and save a copy of important data as a user defined backup. Please be aware, this sort of storage system can't handle large number of small files well.  




== Usage guidlines for workspace filesystems ==
== Usage guidelines for workspace filesystems ==


* The workspace filesystems are expensive ressources, only data which is neccessary for the ongoing work should be held within this directories
* The workspace filesystems are expensive resources, only data which is necessary for the ongoing work should be held within this directories. It is NOT a place for permanent (mid or long term) storage.
* If a project is suspended for a while, users have to free the disk space. Data could be transfered into the HPSS storage system
* If a project is suspended for a while, users have to free the disk space. Data could be transfered into the HPSS storage system
* Storge ressources are overcommitted, this means the disk quota is not equal with a grant of storage space. (This is also true for compute ressources)
* Storge resources are overcommitted, this means the disk quota is not equal to grant of storage space. (This is also true for compute resources)
* If the group's quota has a high usage (currently > 80 %) the performance of the filesystem degrades significantly, To avoid this slowdown, '''NO Jobs of those groups are scheduled to run'''.
* If the group's quota has a high usage (currently > 80 %) the performance of the filesystem degrades significantly for all users, to avoid this slowdown, '''NO Jobs of those groups are scheduled to run'''. All group members (with a registered e-mail address) will be notified by e-mail
* Performance optimization is important, e.g. small size IO kill performance
* Performance optimization is important, e.g. small size IO operations kill performance. Following bandwidth is possible for well optimized applications.
{|Class=wikitable
|-
! File System
! Host
! Max. Performance
|-
| WS7  (*)
| Hazel Hen
| ~75 GB/s
|-
| WS8  (*)
| Hazel Hen
| ~75 GB/s
|-
| WS9
| Hazel Hen
| ~200 GB/s
|-
| WS2
| laki cluster
| 6 GB/s
|-
|}
(*) Filesystem ws7 and ws8 have been decommissioned in preparation for Hawk installation.
* How to use the tools for managing work space directories is explained [[Workspace_mechanism | here ]].
 
== Accounting of workspace ==
There is currently a test phase for a change in the accounting of workspaces for academic projects. If the test is successful and the Steering Committee approves the change, academic project’s awarded computing time will be charged by
 
    ''ressource usage = max ( compute ressource usage, storage usage )''
 
based on a calendar month.
 
This step is necessary to motivate users to more efficiently free up disk space if the project will be inactive for an extended period. If users do not remove data for inactive projects, the project report must justify why  the allocation has been used for storage usage. Please be aware large amount of data may reduce the allocation significantly.
 
For administration reasons, a small usage of the workspace (a few TB) will not reduce the allocation. The project administrator will be informed via Email if the project’s ''resource usage'' is being impacted by storage usage.
 
== Related links ==
 
* [[Workspace_mechanism]]
* [[High_Performance_Storage_System_(HPSS)]]

Revision as of 11:18, 19 August 2019

This page describes how to handle data within HLRS computing environment.

Please be aware, storage resources are optimized for a particular usage. For example work space filesystems are tuned for bandwidth of large parallel IO operations. This requires lots of components like disks, controllers, network connections, ... and makes it expensive. To get the maximum benefit for all users, following extra short guidelines should be read.

Important Notice! No Backup on any filesystem. Please copy important data into the archive.

Following filesystems are available:

  • Home Directory - this storage type is available on all compute resources within HLRS network. Users should store e.g. profiles, script files for workflow tasks, sources for program development... But do not use this dircetory for number crunching (especially on large parallel) jobs!
  • The workspace - here users jobs read / write large amount of data. IO has to be optimized to get considerable performance (e.g. use of optimized IO libraries), if unsure, please feel free to contact your project supervisor.
  • TMP directory. On almost all compute hosts, this is an "in-memory" filesystem, used for small temporary files. All data will be removed at the end of the job. Each node has its own TMP directory, not shared with other nodes, fast but small.
  • HPSS - mid term storage system, here users are able to keep permanent data and save a copy of important data as a user defined backup. Please be aware, this sort of storage system can't handle large number of small files well.


Usage guidelines for workspace filesystems

  • The workspace filesystems are expensive resources, only data which is necessary for the ongoing work should be held within this directories. It is NOT a place for permanent (mid or long term) storage.
  • If a project is suspended for a while, users have to free the disk space. Data could be transfered into the HPSS storage system
  • Storge resources are overcommitted, this means the disk quota is not equal to grant of storage space. (This is also true for compute resources)
  • If the group's quota has a high usage (currently > 80 %) the performance of the filesystem degrades significantly for all users, to avoid this slowdown, NO Jobs of those groups are scheduled to run. All group members (with a registered e-mail address) will be notified by e-mail
  • Performance optimization is important, e.g. small size IO operations kill performance. Following bandwidth is possible for well optimized applications.
File System Host Max. Performance
WS7 (*) Hazel Hen ~75 GB/s
WS8 (*) Hazel Hen ~75 GB/s
WS9 Hazel Hen ~200 GB/s
WS2 laki cluster 6 GB/s

(*) Filesystem ws7 and ws8 have been decommissioned in preparation for Hawk installation.

  • How to use the tools for managing work space directories is explained here .

Accounting of workspace

There is currently a test phase for a change in the accounting of workspaces for academic projects. If the test is successful and the Steering Committee approves the change, academic project’s awarded computing time will be charged by

   ressource usage = max ( compute ressource usage, storage usage ) 

based on a calendar month.

This step is necessary to motivate users to more efficiently free up disk space if the project will be inactive for an extended period. If users do not remove data for inactive projects, the project report must justify why the allocation has been used for storage usage. Please be aware large amount of data may reduce the allocation significantly.

For administration reasons, a small usage of the workspace (a few TB) will not reduce the allocation. The project administrator will be informed via Email if the project’s resource usage is being impacted by storage usage.

Related links