Update to GT's Research Cyberinfrastructure Cost Model

Introduction and Summary 

Over the past few months, a team from the EVPR, OIT, EVP-A&F, and GTRC has been working with Institute leadership to develop a more sustainable and flexible way to support research cyberinfrastructure. This new model is described in more detail below and will affect researchers who leverage PACE services. The model enjoys strong support, but it is not yet fully approved.  We are communicating at this stage because we wanted you to be aware of the upcoming changes and we welcome your feedback. Please submit comments to the PACE Team <pace-support@oit.gatech.edu> or to Lew Lefton <lew.lefton@gatech.edu>. We will also have some listening sessions in the coming weeks to hear more feedback. 

In a nutshell, PACE will transition from a service that purchases nodes with equipment funds, to a service which operates as a Cost Center. This means that major research cyberinfrastructure (including compute and storage services) will be treated like other core facilities. This new model will begin as the transition to the new equipment in the CODA data center happens. We recognize that this represents a shift in how we think about research computing. But, as shown below, the data indicates that the long-term benefits are worth the change.  When researchers only pay for actual consumption – similar to commercial cloud offerings from AWS, Azure, and GCP – there are several advantages: 

  • Researchers have more flexibility to leverage new hardware releases instead of being restricted to hardware purchased at a specific point in time. 

  • The PACE team can use capacity and usage planning to make compute cycles available to faculty in days or week as opposed to having to wait for months due to procurement bottlenecks. 

  • We have secured an Indirect Cost Waiver on both PACE services and commercial cloud offerings for two years to allow us to collect data on the model and see how it is working.  

  • Note that a similar consumption model has been used successfully at other institutions such as Univ. Washington and UCSD, and this approach is also being developed by key sponsors (e.g. NSF’s cloudbank.org). 

  • A free tier that provides any PI the equivalent of 10,000 CPU-hours (per month) on a 192GB compute node and 1 TB of project storage at no cost. 

 

Migration to new CODA data center 

As previously communicated, PACE has developed a plan to migrate services from the Rich data center to CODA.  As is with many things this year, COVID-19 brought significant complications and delays to this process.  However, our goals remain the same: 

  • Reduce or eliminate negative impact to research schedules.  

  • Reduce the long-term cost to the Institute. 

  • Maximize the utilization of the leased space in Coda in order to make the most cost-effective use of this new resource.  

  • Remove HPC equipment supported by PACE from Rich as quickly as possible. 

The supporting infrastructure is in production, and PI migrations are now in progress.  Due to these delays, the time we have to complete the move is more compressed than we would like.  Critical pieces of infrastructure in Rich are rapidly deteriorating, and we have a “hard stop” for licensing of critical components on 12/31/2020.  In light of this, we have adjusted the migration schedule such that the process will complete by the end of December.  Individual migration times will be communicated to PIs and CSRs shortly. 

Current cost model & equipment refreshment 

In partnership with GT Capital Finance, PACE has secured the necessary campus approvals and has secured commercial financing to purchase an entirely new set of hardware for use in CODA.  The repayment for this loan will come from existing PACE budget over the course of the next five years.  Following established precedent, we have developed an “equivalent or better” refreshment rubric using the SPECfp_rate benchmark, while accounting for memory, local storage, GPU, and other capabilities of current equipment that produces a mapping to current generation hardware. We acknowledge that there are a small number of edge cases where this rubric needed adjustment and we have worked with those PIs individually with EVP-R approval. 

Issues with old cost model 

The old cost model calls for faculty to spend equipment funds on compute nodes.  Additional supporting IT infrastructure and personnel were subsidized by the Institute via the PACE budget.  With increased procedures mandated in the procurement process and manufacturer lead times, the "time to science" has now increased to an untenable 6-8 months between a PIs request for resources and the availability of those resources. This model also results in "silos" of equipment with some resources sitting idle while others have a backlog of work to process.  Additionally, this model locks PIs into specific configurations for a 5-year period which prevents the timely leveraging of technology breakthroughs to advance research.  As research needs evolve, it is frequently difficult or impossible to adjust existing hardware to accommodate the new requirements.  A preferable approach would be one where the hardware adapts to the needs of scientific workflows.

The new cost model 

The Institute has developed a new and more sustainable and flexible way to support research cyberinfrastructure. This cost model will be used going forward and has full support from the offices of the EVP-R and EVP-A&F, as well as GTRC, and PACE.  The new model is based on actual consumption - similar to commercial cloud offerings from Amazon (AWS), Microsoft (Azure), and Google (GCP) – that has significant benefits to PIs as well as the Institute as a whole. In this "consumption model," PIs only pay for what they actually use rather than some fixed capacity. This model also provides:  

  • Costs calibrated to match old equipment model.  A critical goal of this consumption model is to keep bottom line costs to PIs equivalent to what they paid in the previous model.  For instance, the cost of a compute node with 192GB RAM purchased in the equipment model is approximately $7,000 and provides approximately 200,000 CPU-hours per year over the course of its 5-year lifetime.  In the consumption model, the cost of 1,000,000 CPU-hours on the same configuration hardware will cost approximately $7,000.  A draft rate study has been submitted, which will formalize rates for PACE services and be reviewed annually.  A detailed breakdown of charges is provided in the appendix. 

  • F&A overhead waiver.  Cost recovery will be managed via the PACE service center, with OIT Resource Management handling the accounting as they have in the past.  PACE has secured the necessary campus approvals to waive the F&A overhead on PACE services, as well as those from commercial cloud providers, for an initial period of two years. 

  • Increased flexibility in the type of resources used, allowing researchers to tailor computing resources to fit their scientific workflows rather than being restricted to the specific quantity and configuration of compute nodes purchased. 

  • Ability for rapid provisioning without the requirement to wait for a lengthy procurement period to complete.  We anticipate being able to reduce the time-to-science from 6-8 months to a period measured in days or weeks. 

  • Insulation from failure of compute nodes.  Compute nodes in need of repair can be taken out of service and repaired, allowing jobs to proceed using other compute nodes in the pool rather than decreasing the capacity available to a particular user. 

  • PACE will monitor the time jobs wait in the queue and procure additional equipment as needed to keep wait times reasonably low. 

  • Based on recent usage trends, we project a lower overall cost to PIs versus the old equipment model. 

  • A free tier of compute and storage will replace the proposal-based FoRCE allocation process.  Supplying the proposal will no longer be required.  PIs simply need to request access and they will be given a monthly allocation of compute time and 1TB of project storage at no cost.  This is available to all GT academic and research faculty, including GTRI. 

Transition from equipment to credits 

The transition from the Rich data center to CODA, and associated equipment refresh, provides an ideal opportunity to transition to the new consumption model.  In place of specific compute nodes, PIs will receive a corresponding number of credits which can be drawn down over a period of five years.  These credits will not be associated with any specific compute nodes, allowing for the use of different capabilities as research workflows require.  As part of this transition, no billing will occur for compute and storage until April 1, 2021.  Specifically, the credits allocated via this refresh will not begin to be drawn down until this time.  During the time between migration and the start of billing, PACE will provide PIs a monthly “show back” invoice.  No funds will be transferred during this time, as this period is intended to give PIs a sense of their monthly utilization and be best able to make projections going forward. 

PACE Services and proposed rates 

Current rates for PACE services are listed here and are described in the appendix.  Please note that a possibility exists that these rates could change slightly upon final review and approval by Grants & Contracts.  In this event, adjustments to PI refresh allocations will be made as needed.

Consider the following example.  A PI currently has a 22-node cluster in Rich that was purchased in 2012.  The warranty on the cluster expired three years ago but continues to limp along experiencing occasional hardware failures.  Each node has 64 cores and 256GB of memory, and the cluster has a total rating of 16,830 on the SPECfp benchmark.  According to the refresh rubric, the replacement resource is 13 nodes, each with 24 cores and 192GB memory.  (Note that this is twice the memory per core as the original system.)  Each new node provides 202,657 CPU-hours per year.  The PI will receive 13 nodes * 202,657 CPU-hours per year * 5 years * $0.0068 = $89,574.39 in credits.  The PI can utilize these credits to run on nodes with 192GB memory if desired, but also has the flexibility to run a mix of jobs that use 768GB nodes, or GPU nodes, or any other available configuration.  

Operational Considerations 

The interface to the queuing system has been simplified.  Behind the scenes, the scheduler hardware has been enhanced, software upgraded, and configuration changes applied that are all designed to increase scheduler performance and response time.  An additional software module – MAM (Moab Accounting Manager) has been procured to augment the Moab scheduler currently in use by PACE and provides a robust means of consumption recording and billing for jobs. 

Individual queues are largely replaced with billing codes known as MAM Accounts.  PIs will be issued multiple MAM Accounts for use by their students and collaborators.  It is important to note that the PI will be responsible for all usage charges incurred by their MAM Accounts. 

Free tier MAM Account – Each PI will receive a MAM Account that contains the equivalent of 10,000 CPU-hours on a 192GB compute node.  The credits can be used to run jobs on any available compute node configuration.  Unused credits do not accumulate month-to-month.  The account will be reset to 10,000 every month. 

Refresh Credit MAM Account – Each PI that currently has resources in the Rich data center will receive a MAM Account with an amount of credits according to the refresh rubric.  The MAM Account will be retired when exhausted or after five years, whichever comes first.  If no additional sponsored resources are available to the researcher, they are still able to continue at the free tier. 

New Project MAM Account – A new MAM Account will be issued for each new funding source.  This could be a startup package, sponsored research, departmental funds, etc.  MAM Accounts of this type will be associated with exactly one Worktag.  Worktags associated with a MAM Account cannot be changed, but any number of MAM Accounts can be issued.  If desired, a PI may set a cap on monthly utilization.  This can be helpful in preventing errant jobs from consuming an inordinate amount of resources. 

Backfill queue – The iw-shared queue is replaced by a backfill queue.  Jobs submitted to the backfill queue do not debit MAM Account balances.  These jobs run at the lowest priority in the system and will be preempted (killed) if a non-backfill job is waiting to run.  During the first hour of execution, backfill jobs are exempted from being preempted. 

A default queue is provided for all jobs not intended for backfill.  A MAM Account must be provided for each job.    As normal, resource requirements must also be specified for each job.  The scheduler will route jobs to the least costly compute node configuration that satisfies the specified requirements.  Thus, jobs may run on any node configuration by simply requesting the appropriate resources. 

PACE will provide a command line tool to show MAM Account balances in real time.  Invoices will be sent monthly.  No funds will actually be transferred, and Refresh Credit MAM Accounts will not be debited until April 1, 2021.  Resources consumed towards the end of the FY will be billed at the beginning of the next FY.  PACE will also develop a refund policy and procedure for crashed jobs.  The details are still being worked out, but the philosophy is that refunds will be issued for jobs that crash due to a system issue.  A higher threshold will need to be met if a job crashes for other reasons. 

FAQ 

Does this new cost model apply to prior PACE purchases or only to new purchase? All users of Phoenix, the replacement for PACE's Rich clusters, will participate in the new cost model. This includes PIs who have made purchases in the past of shared or dedicated resources that are being refreshed with the move to Coda, PIs who made purchases in FY20, and new PIs who join PACE in the future. At this time, only Hive is excluded.

Does this new cost model apply to PIs who have previously purchased dedicated nodes on PACE?  Yes. All users of Phoenix, the replacement for PACE's Rich clusters, will participate in the new cost model, regardless of prior shared or dedicated status.

I’m preparing a budget for a proposal.  How many CPU-hours do I need?  Engaging PACE in proposals is highly encouraged.  Our mission is to support the research community in their efforts, and part of that is helping to optimize workflows, suggest effective computational methods, plan projects with a cyberinfrastructure component, and assist in the preparation of proposal budgets.  If appropriate, we may also act as senior personnel or Co-PI.  We will also publish a calculator tool to convert from more familiar units such as compute nodes and CPU cores and GPUs to credits. 

I use the Hive cluster.  Are we going to be charged now?  No.  Hive is 100% allocated according to the terms of its NSF award and exists outside of this consumption model. 

What about data management plans requiring long-term retention?  Storage may be purchased in advance for a defined quantity and duration.  The Archive storage service would be an excellent choice for this use case. We encourage engaging PACE for any storage concerns. 

Can I have the old equipment that is not moving to CODA?  No.  Equipment with useful lifetime remaining will be traded in to offset the cost of the new equipment and to fund expanded PACE services.  The rest will be disposed of via the regular surplus process. 

I already have projects in various stages of funding that have budgeted for equipment.  What do I do?  This will be handled on a case-by-case basis in partnership with the office of the EVP-R, OSP, and PACE.  Among the possibilities would be to work with your program officer to reallocate the equipment budget.  A memo will be drafted by the EVP-R’s office and PACE that describes the change in cost model for use in these discussions. 

How does this change the process used to budget for new faculty startup packages?  Historically, PACE purchases for startup packages have been one-time equipment purchases, budgeted for in a given fiscal year.  This new model spreads out the expenses over time.  We suggest creating a Worktag to track the startup commitment and then add funds to that Worktag as appropriate based on the particulars of the startup package.  It is expected that this commitment will be satisfied over the course of a number of years.  This Worktag will be associated with a “New Project MAM Account” as described above. 

What about equipment-only awards like DURIP, and NSF’s CC* and MRI?  We are committed to providing appropriate research cyberinfrastructure to advance Georgia Tech’s mission and we recognize that there will be rare exceptions to the new model. We have already made accommodations for sponsored funds which explicitly require equipment in the call for proposals, and we will continue to develop this hybrid aspect of the model on a case-by-case basis.  If you are pursuing and equipment-only award which needs support of the PACE team, we encourage you to engage with them early in the proposal process. 

How do the internal cost center rates from GT compare to commercial cloud providers like AWS, Azure, etc. ?  A true apples-to-apples comparison would require more project specific details including ingress and egress of large datasets, specific CPU/GPU requirements, etc.  However, based on published information, commercial cloud rates are 4 – 10 times higher than GT rates.  This is in part because GT doesn’t have to build in profit margins that commercial entities require.  We should also note that commercial cloud providers have a more robust infrastructure and higher scalability which may be worth the cost differential depending on the project. 

Appendix 

Current rates for PACE services are listed here.  Please note that a possibility exists that these rates could change slightly upon final review and approval by Grants & Contracts.  In this event, adjustments to PI refresh allocations will be made as needed.

The calculated usage rate is the maximum rate GT is allowed to charge itself (e.g. GT PIs) for these services.  The internal rate is what will actually be charged to GT PIs.  The difference between the calculated usage rate and the internal rate reflects the subsidy provided by the Institute and is similar to the level of subsidy in the old cost model.  This subsidy includes data center costs, PACE staff salaries and fringe benefits, supporting IT infrastructure, software licenses, etc.  CRITICAL TO NOTE regarding the internal rate is that it has been carefully selected to match the current cost of the corresponding compute node configuration.  The external rate is intended for GTRI and any future possible non-GT customers (e.g. a startup company spun out from GT, etc.)   

Compute services are broken down into three major categories.  General (GEN), CUI, and LIGO/OSG.  The general category comprises the vast majority of current PACE resources.  CUI (Controlled Unclassified Information) requires additional security measures and is for activities requiring adherence to NIST800-171 such as ITAR and various export control regimes.  LIGO/OSG is the Open Science Grid model of computing, used primarily by high-throughput workloads.  Subcategories describe the capabilities of the compute node such as memory size (e.g. 192GB), availability of local disk (e.g. SAS), or GPUs (e.g. v100 for double precision workloads and RTX6000 for single precision workloads).  Note that there are different units for compute nodes with GPUs.  They are measured in GPU-hours rather than CPU-hours. 

Storage is charged based on the capabilities of the storage platform.  Project storage is intended for data sets that are in active use.  Scratch storage and home directories continue to be available and are provided at no cost.  Capacities of both will increase relative to what is provided in Rich.  LIGO/OSG uses a different model for storage and is not accessible to compute services other than LIGO/OSG.  Archival storage is intended for the long-term storage of data sets and is not directly accessible from PACE compute services.  It uses Globus as a user interface, allowing data sets to be easily transferred to Project storage. 

Both CUI compute and storage have notable differences.  Due to security requirements CUI compute must be scheduled per-node rather than per CPU core.  Since current compute nodes contain 24 CPU cores, the effective rate for CUI compute is 24x of the table below.  PACE research scientists will be available to assist transforming workflows to utilize as many CPU cores in a single job as possible.  Security requirements dictate a hybrid consumption/equipment model for CUI storage.  PIs will need to pay a monthly/annual fee per drive bay, plus the cost of the drives themselves.  To ensure integrity and availability of the storage, at least two drives and drive bays must be purchased.  For larger capacity requirements, more sophisticated RAID levels may be utilized, and PACE staff will provide assistance in determining the optimal solution.  PACE will generate a vendor quote for drives of the chosen capacity and appropriate configuration and issue a PO against a Worktag provided by the PI.  Additional drives and drive bays are required to provide backups.  PACE will provide the required funding to enable nightly backups per our usual operational procedures. 

Finally, a new consulting service is forthcoming which will enable PACE staff to provide a higher level of service when required and allows easy budgeting for PIs wishing to include PACE staff in grant proposals.