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 1 – 5 years.
• 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.
• Storage allocations will auto renew with a one year period unless other arrangements are made.
  – IDRE will send notices out starting at 60 days before the end of an active allocation.
• 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 friedman@cass.idre.ucla.edu (preferred) or 310-825-8607.

To determine the effective per TB rate, first find the row containing the total amount of storage being added. Then follow across to the column corresponding to the number of years that storage will be added for. Multiply that rate times the total number of terabytes being added and the number of years to determine the total transaction cost.

Example: Adding 20TB for 2 Years.  $128.53/TB/Yr x 20TB x 2Yr = $5,141.20

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

Protecting Personal Information (PI) on CASS

Pursuant to UCLA Policy 404 any Personal Information (PI) data stored on CASS must be protected.

Personal Information is defined as “an individual’s first name or first initial, and last name, in combination with any one or more of the following: (1) Social Security number, (2) driver’s license number or California identification card number, (3) account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual’s financial account, (4) medical information, and (5) health insurance information.”

Other key points from Policy 404

• Personal Information in the custody or control of UCLA should be stored only when there is an academic, patient care or business purpose.
• Electronically stored Personal Information must be encrypted. Each organization must maintain an inventory of their electronically stored Personal Information, including individuals responsible for this Personal Information.
• Organization Heads have the authority to impose more restrictive standards for electronically storing Personal Information in their area of responsibility.
• Employees who violate this Policy will be subject to the disciplinary process in accordance with University policies and collective bargaining agreements.
• If a breach should occur, as per UCLA Policy 420, Breaches of Computerized Personal Information, its cost will be the responsibility of the organization in which it occurred. 

Since IDRE has responsibility for CASS it also has responsibility for ensuring that users of CASS understand what is required of them.

To that end we need to know if you are storing any Personal Information on CASS. If so, we strongly recommend you remove it immediately. If this is not possible then you must encrypt the data per UCLA Policy 404 guidelines. If you do decide to keep it you must inform the IDRE Director, in writing, what kind of Personal Information you have and why you must keep it on CASS. If a security breach occurs and unencrypted Personal Information is exposed then YOU as the custodian of the data are liable for the exposure.