This shows you the differences between two versions of the page.
Next revision | Previous revision Next revision Both sides next revision | ||
cluster:135 [2014/12/02 19:02] hmeij created |
cluster:135 [2014/12/05 20:16] hmeij [RSTORE FAQ] |
||
---|---|---|---|
Line 1: | Line 1: | ||
\\ | \\ | ||
**[[cluster: | **[[cluster: | ||
+ | |||
+ | This is the template that the primary share owner will receive in order to get the process of migrating off flexstorage to the rstore platform (with custom edits in bottom section). It is not a storage policy draft but information could be gleaned from it. | ||
==== RSTORE FAQ ==== | ==== RSTORE FAQ ==== | ||
+ | |||
+ | Your Flexstorage storage share will be migrated to our new platform dubbed Rstore. | ||
+ | Details are below. | ||
=== What is it? === | === What is it? === | ||
+ | |||
+ | Our current platform to provide disk storage capacity for users and groups is called Flexstorage. | ||
=== How do I access it? === | === How do I access it? === | ||
- | === Is my data safe? === | + | You will use your Wesleyan Active Directory (AD) credentials, |
+ | |||
+ | There are several ways to access your contents either by logging in or mounting the shares. More information is provided below with specifics for your share. | ||
+ | |||
+ | === How is is configured? === | ||
+ | |||
+ | Each primary/ | ||
+ | |||
+ | Replication is duplicating data on primary member to be in sync with data on secondary member. | ||
+ | |||
+ | Only the shares located on the third data filesystem (/data/3), in addition to replication, | ||
+ | |||
+ | Note: Because of replication, | ||
+ | |||
+ | Note: For very large filesystems whose contents does not change, the replication can take a long time and is typically unnecessary after first copy event. | ||
+ | |||
+ | === Is my content | ||
+ | |||
+ | Your content is protected using these methods: | ||
+ | |||
+ | * When the content was transferred from Flexstorage to Rstore the -c option of rsync was used meaning perform a checksum check guaranteeing that both files have the same unique finger print. | ||
+ | * Once copied to Rstore disk arrays the content is protected with redundant array of independent disk technology, in our case RAID 60. This technique keeps multiple copies of data chunks so that failed disks can be repaired. | ||
+ | * RAID cards managing the arrays continually scrub and test the disks for sign of probable near future failure events thus reducing actual failures. | ||
+ | * In the event of a primary catastrophic failure of a member in a pair, the content is available on the secondary member in a state defined by last replication event. | ||
+ | * In an accidental deletion of content in shares in /data/3 (ONLY), there will be snapshots available for restoration (daily, weekly, monthly). | ||
+ | * Both primary/ | ||
+ | * Both primary/ | ||
+ | * Upon deployment of your share, checksums will be calculated for each file on both primary and secondary members. | ||
+ | |||
+ | === How do I test? === | ||
+ | |||
+ | * Your share' | ||
+ | * Your share' | ||
+ | * Your share' | ||
+ | * Your share' | ||
+ | * Your share' | ||
+ | * share owner (SHARE_OWNER) rwx, share group (SHARE_GROUP) rwx, others none | ||
+ | * share members own their own folders and files they create | ||
+ | * share members have group access to folders and files created | ||
+ | * This default policy can be changed to a certain extent | ||
+ | |||
+ | Note: UID/GID name space. Every user has a uid/gid identification which determines permissions to files and directories. | ||
- | note to large users | + | * SSH access |
+ | * open any ssh client and connect | ||
+ | * then change directories (cd / | ||
+ | * view contents ('' | ||
+ | * These are not computational servers but running maintenance scripts is allowed | ||
+ | * If you will be running programs that will take a long time please notify us | ||
+ | * Your uid/gid comes from AD but your gid may not be the share group gid (for example it can s15) | ||
+ | * to force the corect gid type '' | ||
+ | * Samba access (Preferred) | ||
+ | * Windows users, map a network drive and use your AD credentials | ||
+ | * -\-\service_address.wesleyan.edy\SHARE_NAME | ||
+ | * Max users, mount a samba share | ||
+ | * smb:// | ||
+ | * The uid/gid will be forced by Samba to be correct. | ||
+ | * NFS (least preferred) | ||
+ | * This has the most potential to cuase havoc with uid/gid settings | ||
+ | * It requires the client (mounting client) to have the porper uid/gid or be AD enabled. | ||
+ | * Must refer to the current primary hostname. | ||
+ | * Hangs during a fail over event. | ||
+ | * Via command line | ||
+ | * mount -t nfs rstoresrv[0|1].wesleyan.edu/ | ||
+ | * Or via /etc/fstab using CIFS (mount the Samba share) | ||
+ | * '' | ||
\\ | \\ |