A multi-petabyte scale service for networked based storage.

CASS’ driving principles are:

• Simplicity
• Flexibility
• Resiliency
• Expandability
• Affordability
• Security

Easy to setup and easy to use…

Access

CASS offers several methods to access and use its storage.

• NFS: File level access from Linux and OSX.
• SMB: File level access from Windows (and Linux and OSX).
• iSCSI: Block level access from Linux, Windows and OSX*.
• Globus Online: A simple, reliable, secure and asynchronous file transfer service.
• CrashPlanPROe**: Use CASS as a backup server for your local desktops and servers.

Occasionally, we are asked if CASS will offer some particular type of access method and/or service it currently does not. While several are under consideration we have no plans to add any at this time. If you have a suggestion please let us know and we will take it into consideration.

CASS, HPC Storage and the Hoffman2 cluster – We are very often asked what the difference is between CASS and HPC Storage on Hoffman2. They are completely different things. HPC Storage is project space for Hoffman2 compute jobs that is not accessible directly from outside the Hoffman2 cluster environment. HPC Storage is also more expensive given the high-performance nature of the systems that provide it. CASS is accessible from outside the Hoffman2 environment but not within it. Globus Online is the best way to move data back and forth between these two systems.

* OSX does not natively include an iSCSI initiator (client) which would have to be purchased separately.

** This service requires separate licenses from Code42 to use. Please contact us for more details.

Resiliency

It is important to understand that CASS itself is not backed up. CASS is most often used for storing reproducible data or data that is stored elsewhere, i.e. a backup of a backup. CASS however, at its core, is designed to be resilient to failure. That being said, there are ways that users can configure their storage to enable additional storage resiliency. Below are descriptions of the three options available to all CASS users for configuring their storage.

• Basic: This is the default option which relies on the underlying CASS hardware. Data is striped over hardware RAID6 arrays. If CASS ever lost a RAID6 array that some of your data is stored on that data would be lost. With this option, you have all purchased storage available to you – 1TB purchased = 1TB usable. (the space used for the RAID6 parity is included in the base cost of CASS)
• Parity: Parity is enabled across the hardware RAID6 arrays. Here, CASS could lose any single RAID6 array we have striped your data over and no data would be lost. This option reserves 12.5% of your purchased space for storing this additional parity and, again, the data is striped over hardware RAID6, parity over parity. 1TB purchased = 875GB usable. This is our most popular resiliency option.
• Mirroring: Data is mirrored across two data centers on the UCLA campus. All data written to CASS is synchronously written to two locations. This option uses 50% of your total purchased space (another way to think of this is…you need to buy double). This is the safest option. Here CASS would have to lose two corresponding RAID6 arrays that make up a mirrored pair. 1TB purchased = 500GB usable. This option is best for data you cannot lose and/or is not (easily) reproducible.

We are considering an additional option to replication CASS data out of Los Angeles for extra protection and/or disaster recovery (DR) purposes. The most likely scenario would replicate data to a UC campus in northern California. Please let us know if this capability would be something you would be interested in.

Network

CASS is connected directly to the UCLA backbone network through redundant 10G links. Users can choose to place their CASS storage endpoint onto the network most appropriate to their needs. There are, currently, three options available.

• Global: Endpoints are accessible from anywhere in the world.
• UCLA Campus: Endpoints are accessible from anywhere on the UCLA campus but not the UCLA medical center/school. Users outside UCLA would need to use the UCLA VPN.
• UCLA Medical School: Endpoints are accessible from within the UCLA medical center/school.

Security

The CASS approach to security is simple. The default is zero access. Services are made available to specific users, hosts and networks on an as needed basis. It is up to the user to determine how restrictive access should be with the understanding that they are taking responsibility for the access permitted to their CASS storage endpoint. Beyond this CASS is physically located in secure data centers on the UCLA campus which are monitored 24 hours a day.

Rates

• Storage is sold in units of a terabyte (TB*) for a period of one year.
• Rates are per terabyte (TB*) / per year.
• The effective volume/period rate is determined per transaction.
  – The rate is determined by the amount of storage added to an allocation.
  – A transaction can be prorated so that renewals capture total allocations and, potentially, a lower rate.
• Rates are current as of December 1, 2015 and are subject to change without notice.
• Using federal funds will incur overhead (currently 54%) as CASS is considered a service. See: Current UC Overhead Rates.
• CASS is currently available only to University of California (UC) entities.
• To discuss your needs and how CASS might be able to help you, have questions or order storage please contact Scott Friedman at support@idre.ucla.edu (preferred) or 310-825-8607 or through our support site: https://support.idre.ucla.edu

To determine the cost for your desired storage allocation, find the row containing the total amount of storage being added. Then follow across to the ‘Price per TB’ column. Multiply that rate times the total number of terabytes being added.

Example: Adding 20TB for 1 Year.  $131.66/TB/Yr x 20TB = $2,633.20

* 1TB = 1,000,000,000,000 bytes

Personal information and sensitive data on CASS

Personal information and other sensitive data, including statutory, regulatory, and contractually protected data — for example, human subjects research, restricted research, student and educational data, and PHI — are prohibited on Hoffman2. (See the UC Protection Level Classification Guide charts on Protection Level 3 and Protection Level 4 for details.)

Researchers using any data defined by UCLA Health as protected health data must contact UCLA Health IT. Such data are prohibited on Hoffman2.

UCLA Health defines ‘health data’ as “any information pertaining to the health, care, and treatment of UCLA Health patients or health plan members which: (1) results in a report used in treatment or monitoring of a patient; (2) generates a claim or a bill for services that are provided; and/or (3) is used for operations, financial management, population health activities or quality metrics.

Prospectively-collected clinical research data and related research results will not be considered Health Data if these data are collected/created exclusively for a sponsored research (“Sponsored Research Data”); however, Sponsored Research Data that appears in the patient’s medical record is Health Data. (The use of Sponsored Research Data may be subject to contractual and regulatory obligations; release of Sponsored Research Data to any entity other than the sponsor of the study must be reviewed in advance by the Clinical Trials Administration Office.) Non-health data is all other data collected at UCLA Health.”

Please contact the Director of the IDRE Research Technology Group if your research requires use of these types of data, or if you have any questions. More information about security requirements can be found at security.ucop.edu.