Disk Storage: Difference between revisions

From Research Computing Center Wiki
Jump to navigation Jump to search
Line 33: Line 33:
scratch= /lustre1/jsmith
scratch= /lustre1/jsmith


Note that sapelo users already have a scratch directory.  Users of the zcluster need to type 'make_escratch' while on the login node (not interactive nodes) to create a scratch directory - the command will return the name of the directory.  
Note that sapelo users already have a scratch directory.  Users of the zcluster need to type  
 
make_escratch
 
while on the login node (not interactive nodes) to create a scratch directory - the command will return the name of the directory.  


The project filesystem is not mounted on the compute nodes and cannot be accessed by running jobs.  It is mounted on the zcluster login node, and on the file "copy" and "xfer" nodes.  The copy and xfer nodes (discussed under [[Transferring Files | Transferring Files]]) are the preferred servers to use for copying and moving files between all of the filesystems, and to and from the outside world.
The project filesystem is not mounted on the compute nodes and cannot be accessed by running jobs.  It is mounted on the zcluster login node, and on the file "copy" and "xfer" nodes.  The copy and xfer nodes (discussed under [[Transferring Files | Transferring Files]]) are the preferred servers to use for copying and moving files between all of the filesystems, and to and from the outside world.

Revision as of 10:02, 17 May 2016


Storage Overview

Network attached storage systems at the GACRC are tiered in three levels based on speed and capacity. Ranked in order of decreasing speed, the file systems are "scratch", "home", and "offline" storage. The home filesystem is the "landing zone" when users login, and the scratch filesystem is where jobs should be run. Scratch is considered temporary and files are not to be left on it long-term. The offline storage filesystem is where data that is currently being used should be stored when it is not being used on scratch.

For home and scratch directories, users are assigned the following quotas (maximum space allowed):

zcluster home= 100GB scratch= 4TB

sapelo home= 100GB scratch= Currently none

The offline storage filesystem is named "project" and is configured for use by lab groups, and by default, each lab group has a 1TB quota. Individual members of a lab group can create subdirectories under their lab's project directory. PI's of lab groups can request additional storage on project as needed. Please note that this storage is not meant for long-term (e.g., archive) storage of data. That type of storage is the responsibility of the user.


Storage Architecture

The home and scratch filesystems are mounted on the zcluster and the sapelo cluster as follows, using an example user 'jsmith' in a lab group 'abclab':

zcluster-

home= /home/abclab/jsmith scratch= /escratch4/jsmith/jsmith_Month_Day

sapelo-

home= /home/jsmith scratch= /lustre1/jsmith

Note that sapelo users already have a scratch directory. Users of the zcluster need to type

make_escratch

while on the login node (not interactive nodes) to create a scratch directory - the command will return the name of the directory.

The project filesystem is not mounted on the compute nodes and cannot be accessed by running jobs. It is mounted on the zcluster login node, and on the file "copy" and "xfer" nodes. The copy and xfer nodes (discussed under Transferring Files) are the preferred servers to use for copying and moving files between all of the filesystems, and to and from the outside world.

The project filesystem has a consistent mount point of:

/project/abclab

Auto Mounting Filesystems

Some filesystems are "auto mounted" when they are first accessed on a server. For the xfer nodes, this includes Sapelo home directories and the project filesystems. For the zcluster copy nodes, this includes the project filesystems. Sapelo interactive ("qlogin") nodes will mount a user's home directory when the qlogin happens.


Snapshots

Home directories are snapshotted. Snapshots are like backups in that they are read-only moment-in-time captures of files and directories which can be used to restore files that may have been accidentally deleted or overwritten.

Home directories on sapelo have snapshots taken once a day and maintained for 4 days, giving the user the ability to retrieve old files for up to 4 days after they have deleted them. On the zcluster, some home directories have snapshots taken once a day, and some have snapshots taken once every 2 days; these are maintained for 4 days.

Any directory on the /home filesystem contains a completely invisible directory named ".snapshot". This directory cannot be listed with ls or viewed by any program at all. Only the "cd" command can be used to enter this directory. Users of /home directories may retrieve files from these snapshots by using the "cd" command and copying files from the appropriate snapshot to any location they would like.

Note: ANY user, from any HOME directory can access the snapshots *from that directory* to restore files

Here is the example for zcluster:

[cecombs@sites test]$ cd .snapshot
[cecombs@sites .snapshot]$ ls
2013.04.16.00.00.01.daily  2013.04.17.00.00.01.daily  2013.04.18.00.00.01.daily
[cecombs@sites .snapshot]$ cd 2013.04.18.00.00.01.daily/
[cecombs@sites 2013.04.18.00.00.01.daily]$ cp my-to-restore-file /home/rccstaff/cecombs/test

For Sapelo, please send in a ticket for such request. It is a different procedure at backend.

Current Storage Systems

(1) Panasas ActiveStor 12 storage cluster with 133TB usable capacity, running PanFS parallel file system. Currently supporting the home filesystem on the zcluster

(1) Seagate (Xyratex) Lustre appliance with 240TB usable capacity. Currently supporting the scratch filesystem on sapelo

(3) Penguin IceBreakers storage chains running ZFS mounted through NFS for a total of 84TB usable capacity. Currently supporting home directories on sapelo

(2) Penguin IceBreakers storage chains running ZFS mounted through NFS for a total of 374TB usable capacity. This storage is used as an active project repository

(1) Penguin IceBreaker storage chains running ZFS mounted through NFS for a total of 142TB usable capacity. This storage is used as a backup resource for the home and project filesystems