Yottabyte Research Cloud

The Yottabyte Research Cloud (YBRC) is the University’s private cloud environment for research. It’s a collection of processors, memory, storage, and networking that can be subdivided into smaller units and allocated to research projects on an as-needed basis to be accessed by virtual machines and containers.

Access to Yottabyte Research Cloud resources involves a single email to us at arc-support@umich.edu. Please include:

• Your name or your advisor’s name
• Your unit
• What you would like to use YBRC for
• Whether you plan to use restricted data.

Someone from your unit IT staff or an ARC staff member will reach out to you and arrange details to determine the best path to make your request work within the Yottabyte Cloud environment.

Yottabyte Research Cloud resources are aimed squarely at research and the teaching and training of students involved in research. Primarily, Yottabyte resources are for sponsored research. Yottabyte Research Cloud is not for administrative or clinical use (business of the university or the hospital). Clinical research is acceptable as long as it is sponsored research.

In total, Yottabyte Research Cloud (YBRC) has 960 processing cores for each Yottabyte cluster, 7.5 Terabytes, and roughly 330 TB of scratch storage available in Maize and Blue each.

Yottabyte resources are divided up between two clusters of computing and storage. Maize YBRC is for restricted data analyses and storage, and Blue YBRC is for unrestricted data analyses and storage.

The initial offering of YBRC is focused on a few different types of use cases:

1. Database hosting and data ingestion of streaming data from an external source into a database. We can host many types of databases within Yottabyte, including most structured and unstructured databases.  Examples include MariaDB, PostgreSQL, and MongoDB.
2. Hosting for applications that you can’t host locally in your lab or you would like to connect to our HPC and data science clusters, such as Material Studio, Galaxy, and SAS Studio.
3. Hosting of Virtual Desktops and Servers for restricted data use cases, such as statistical analysis of health data, or an analytical project for Controlled Unsecured Information (CUI).  Most people in this case may need a powerful workstation for SAS, Stata or R analyses, for example, or some other application.

No! Contact us at arc-support@umich.edu if you want to learn whether or not your idea can be done within YBRC!

The best way to get help is to send an email to arcts-support@umich.edu with a brief description of the issues you are seeing.

Yottabyte is supported between the hours of 9 a.m. to 5 p.m. Monday through Friday. Response times for support outside of these hours will be longer.

Because of the way that YBRC divides up resources, the largest Virtual Machine within the cluster is 12 processing cores, and 96 GB of RAM.

ARC policy is to limit no-cost individual allocations to 100 cores, so that access is always open to multiple research groups.

If you need to use more than 100 cores of YBRC, we recommend that you purchase YBRC physical infrastructure of your own and add it to the cluster. Physical infrastructure can be purchased in 96 physical core chunks, which can be oversubscribed as memory allows. For every block purchased, the researcher will also receive 4 years of hardware and OS support for that block in the case of failure. For a cost estimate of buying your own blocks of infrastructure and adding to the cluster, please email arc-support@umich.edu.

Scratch storage for Yottabyte Research Cloud is the storage area network that OS storage and active data storage on the local virtual machines that are not actively being backed up or replicated to a separate infrastructure. Like the scratch storage on Flux, we don’t recommend storing any data solely on the local disk of any machines. Make sure that you have backups on other machines, like Turbo, Locker, or some other service.

For researchers with restricted data with a HIPAA classification, we provide a small menu of Linux and Windows workstations to be installed within your enclave.  We do not delegate administrative rights for those workstations to researchers or research staff.  We may delegate administrative rights for workstations and services in your enclaves to IT staff in your unit who have successfully completed the HIPAA IT training coursework given by ITS or HITS, and are familiar with desktop and virtual machine environments.

Machines in the HIPAA network enclaves are encircled by a deny first firewall that prevents most traffic from entering the enclaves.  Researchers can still visit external-to-campus websites from within a HIPAA network enclave.  Researchers within a HIPAA network enclave can use storage services such as Turbo and MiStorage Silver (via CIFS) to host data for longer-term storage.

All researchers, staff, and students that use YBRC when analyzing restricted data have a shared responsibility in keeping their restricted data secure.

• Researchers need to be aware of the personnel in their labs who have access to the data in their enclaves.
  • Each lab should have a process for adding and removing users from enclaves that includes removing departed lab members from access to restricted data as soon as possible after they have left the lab.
  • Each lab should review who has access to their data and enclaves on a twice yearly basis via checking the memberships of their M-Community and Active Directory groups to ensure that people have been removed as requested.
• Each lab user must store their restricted data in a specific directory, as discussed during their introductory meeting with YBRC staff.  They must keep the data only in this directory over the life of the data on the system.

Staff will work with researchers using CUI-classified data to determine the types of analysis that can be conducted on YBRC resources that comply with relevant regulations.

All researchers, staff, and students that use YBRC when analyzing restricted data have a shared responsibility in keeping their restricted data secure.

• Researchers need to be aware of the personnel in their labs who have access to the data in their enclaves.
  • Each lab should have a process for adding and removing users from enclaves that includes removing departed lab members from access to restricted data as soon as possible after they have left the lab.
  • Each lab should review who has access to their data and enclaves on a twice yearly basis via checking the memberships of their M-Community and Active Directory groups to ensure that people have been removed as requested.
• Each lab user must store their restricted data in a specific directory, as discussed during their introductory meeting with YBRC staff.  They must keep the data only in this directory over the life of the data on the system.