DokuWiki

User Tools

Site Tools

Trace: • 88
cluster:93

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
Next revision Both sides next revision
cluster:93 [2011/01/09 20:37]
hmeij 		cluster:93 [2011/01/10 16:55]
hmeij
Line 1: Line 1:
 \\ \\
 **[[cluster:0|Back]]** **[[cluster:0|Back]]**
 +
 +|{{:cluster:greentail.jpg|}}|
 +|  greentail  |
 +
  
 ====== Greentail ====== ====== Greentail ======
Line 44: Line 48:
  
 ===== Home Dirs ===== ===== Home Dirs =====
 +
 +The home directory disk space (5 TB) on the clusters is served up via NFS from one of our data center NetApp storage servers (named filer3).  (Lets refer to those as "old home dirs"). We will be migrating off filer3 to greentail's local disk array.  The path will remain the same on greentail: /home/username. (Lets refer to those as "new home dirs").
 +
 +In order to do this, your old home directory content will be copied weekly from filer3 to greentail's disk array.  When you create new files in your old home dirs they will show up on greentail's new home dirs.  However, if you delete files in old home dirs, and they have already been copied over, the files will remain in your new home dirs.  If you create new files in greentail's new home dirs they will **not** be copied back to your old home dirs.
 +
 +To avoid a conflict between home dirs I strongly suggest you create a directory to store the files you will be creating on greentail, for example /home/username/greentail or /home/username/hp.
 +
 +At some point in the future, greentail's new home dirs will be mounted on the petaltail/swallowtail and sharptail clusters.  Filer3's old home dirs will then disappear permanently.
 +
 +Greentail's new home dirs will provide 10 TB of disk space.  Again, the clusters file system should not be used to archive data. However, doubling the home directory size should provide much needed relief.
 +
 +Because of the size of the new home dirs, we will also not be able to provide backup via TSM (Tivoli).  Backup via TSM to our Virtual Tape Library (VTL) will be replaced with disk to disk backup on greentail's disk array.  That has some serious implications.  Please read the section about RSnapshot.
 +
  
 ===== Passwords ===== ===== Passwords =====
Line 72: Line 89:
  
 ===== Rsnapshot ===== ===== Rsnapshot =====
 +
 +[[http://rsnapshot.org|Rsnapshot]] can be used to perform disk to disk backup of file systems using linux tools such as hard and soft links and rsync.  It will replace our practice of backing up to the virtual tape library. Since I had to disable the functionality of keeping modified files for 30 days (one file version only) because of the mass of files in /home (18 million by last count) we actually gain functionality using rsnapshot.  Rsnaphot will take daily, weekly and monthly point in time backups. We will keep backups for the last 6 days, the last 4 weeks and the last 3 months.
 +
 +Rsnaphot content of all the new home directory content is made available to you at /snapshot/repository/? where ? is a single letter from a to z.  This file system is read only.  Users can retrieve deleted data by simply copying the data lost back into their new home directories.
 +
 +Within the snapshot repository you will find directories:
 +
 +  * daily.0 (yesterday), daily.1 (day before yesterday) etc ... daily backups are taken mon-sat at 11 pm
 +  * weekly.0 (last week), weekly.1 (week before last week) etc ... weekly backups are taken sunday at 10:30 pm
 +  * monthly.0 (last month), monthly.1 (month before last month) etc ... monthly backups are taken on the first day of each month at 10:00 pm
 +
 +/home and /snapshot are different logical volumes using a different set of disks to protect against loss of data.  In addition, both use RAID 6 (double parity) for another layer of protection.  However, it is one disk array comprised of 4 disk shelves directly attached to greentail.  A catastrophic failure implies the potential of data loss.  I therefore encourage you to archive data elsewhere for permanent storage.
 +
 +===== Sanscratch =====
 +
 +Previously there were two scratch areas available to your programs: /localscratch which is roughly 50 GB on each node's local hard disk and /sanscratch a shared scratch area available to all nodes.  Sanscratch allows you to monitor your jobs progress by looking in /sanscratch/jobpid. It was also much larger (1 TB).
 +
 +However, since our fantastic crash of June 2008 ([[cluster:67|The catastrophic crash of June 08]] /snapshot was simply a directory inside /home and thus compete for disk space.
 +
 +On greentail, /sanscratch will be a separate logical volume of 5 TB using a different disk set.  SO i urge those that have very large files to stage their files in /sanscratch when running their jobs for best performance.  The scheduler will always create (and delete!) two directories for you.  The JOBPID of your job is used to create /localscratch/jobpid and /sanscratch/jobpid.
 +
 +===== MPI =====
 +
  
 ===== ... ===== ===== ... =====
 +
 +|{{:cluster:swallowtail.jpg|}}|{{:cluster:petaltail.jpg|}}|{{:cluster:sharptail.jpg|}}|
 +|  swallowtail  |  petaltail  |  sharptail  |
  
  
cluster/93.txt · Last modified: 2011/01/11 20:55 by hmeij

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki