Posts

Update to GT’s Research Cyberinfrastructure Cost Model

Please visit our Web page for up to date information and FAQs: https://pace.gatech.edu/update-gts-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 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 now ready to go and the move of the first cohort of PIs is planned for early October 2020.  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 until at least January 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

Draft rates for PACE services are given as an 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 and rescheduled) 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 at least January 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

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

The following table lists draft rates for PACE services.  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.

 

Unit

Calculated Usage Rate

Internal

External

[GEN] cpu-192GB

CPUh

 $0.0273

 $0.0068

 $0.0246

[GEN] cpu-384GB

CPUh

 $0.0255

 $0.0077

 $0.0276

[GEN] cpu-384GB-SAS

CPUh

 $0.0252

 $0.0091

 $0.0289

[GEN] cpu-768GB

CPUh

 $0.0254

 $0.0091

 $0.0297

[GEN] cpu-768GB-SAS

CPUh

 $0.0285

 $0.0119

 $0.0340

[GEN] gpu-192GB-v100

GPUh

 $0.3669

 $0.2307

 $0.5161

[GEN] gpu-384GB-RTX6000

GPUh

 $0.2693

 $0.1491

 $0.2777

[GEN] gpu-384GB-v100

GPUh

 $0.4789

 $0.2409

 $0.5084

[GEN] gpu-768GB-RTX6000

GPUh

 $0.1552

 $0.1552

 $0.2833

[GEN] gpu-768GB-v100

GPUh

 $0.4567

 $0.2627

 $0.4945

[CUI] Server-192GB

CPUh

 $0.0570

 $0.0068

 $0.0570

[CUI] Server-384GB

CPUh

 $0.0636

 $0.0103

 $0.0641

[CUI] Server-384GB-SAS

CPUh

 $0.0797

 $0.0153

 $0.0818

[CUI] Server-768GB

CPUh

 $0.0651

 $0.0128

 $0.0651

[LIGO/OSG] cpu-192GB

CPUh

 $0.0469

 $0.0068

 $0.0469

[LIGO/OSG] cpu-384GB

CPUh

 $0.0353

 $0.0077

 $0.0414

[LIGO/OSG] gpu-384GB-RTX6000

GPUh

 $0.2313

 $0.1639

 $0.3789

[Storage] Project Storage

TB/Mo

 $7.85

 $6.67

 $7.85

[Storage] CUI

Drive Bay/Mo

 $41.20

 $41.20

 $41.20

[Storage] Hive

TB/Mo

 $6.60

 $6.60

 $6.60

[Storage] LIGO/OSG

TB/Mo

 $2.61

 $2.61

 $2.61

[Storage] Archival

TB/Mo

 $4.89

 $3.33

 $4.89

General Consulting

Hour

 $98

 $98

 $98

[Resolved] Emergency Storage maintenance (GPFS/pace2) in Rich datacenter

[Update – 3:02pm] 

We are following up to inform you that our emergency maintenance work on GPFS pace2 storage in Rich datacenter was completed successfully, and at approximately 2:10pm we have released the jobs on the Shared and Dedicated clusters in Rich.   Please note that temporarily the GPFS pace2 file system will be slightly slower as it is concurrently rebuilding 7 drives.  During this maintenance, we did not lose any user data, and we did not interrupt any user jobs that were running during this period.

What PACE will do:  PACE will continue to monitor the storage and report as needed.  Thank you for your attention and patience during this brief emergency storage maintance.  

If you have any questions or concerns, please direct them to pace-support@oit.gatech.edu

Thank you,
The PACE Team

 

[Original – 11:25]

PACE will be conducting an emergency maintenance work on storage in Rich datacenter today at 1:00pm.  As a precaution we have paused all user jobs as of 10:15am today.  Currently running jobs will remain running but may be subject to interruption during our emergency maintenance.  

What’s about to happen: Today, starting at 1:00pm, PACE team will need to conduct an emergency maintenance activity on our GPFS in Rich datacenter, which will involve reseating the primary IO module.  The storage impacted is /data directory on GPFS pace2 that users use on Shared and Dedicated clusters.

Who is impacted: As of 10:15am, all PACE users are unable to submit and run new jobs as the schedulers in Rich datacenter have been paused.  Currently running user jobs may be subject to interruption during the maintenance activity.  If jobs get interrupted, PACE team will follow up with the impacted users to notify them.  

This emergency maintenance activity does not impact Coda datacenter that includes Hive and TestFlight-Coda clusters.  Also, as of 11:30am we have released the jobs for Gryphon and Novazohar that were briefly paused this morning as we assessed the situation.  Gryphon and Novazohar clusters will not be impacted by the 1:00pm scheduled emergency maintenance.

For updates, you may refer to our blog post,LINK  that we will updated as further information is available.

If you have any questions or concerns, please direct them to pace-support@oit.gatech.edu.

Thank you for your attention and our apologies for this inconvenience.

The PACE Team

OIT’s Planned Network Maintenance

We are following up with an update on the schedule for OIT’s planned network maintenance.  OIT’s Network Engineering team will be conducting two maintenance activities scheduled for the evening of Friday, September 11th, from 7:00pm to 4:00am.  These maintenance activities will affect connections of PACE to the outside Internet that is anticipated to last 30 minutes or less from the start of the activity, which may occur at any point during this updated and longer maintenance time window.

What’s about to happen:  On Friday, September 11th, starting at 7:00pm –  4:00am (September 12th), Network Engineering team will be upgrading the data center firewall appliances to the latest code that is recommended by Palo Alto who has addressed serious security vulnerabilities with their latest released code.  To reassure you, OIT’s network team has been operating with some controls in place to address these vulnerabilities, and this planned upgrade will further reduce our risk.  Second maintenance activity also starts on Friday, September 11th, Network Engineering team will be swapping service to a more capable Network Address Translation (NAT) appliance in Coda datacenter, as the one currently in Coda  is being overloaded.  These activities will affect PACE’s connection to/from the Internet.

Who is impacted: PACE users will not be able to connect to PACE resources and/or they may lose connection during this maintenance window that may last 30 minutes or less from the start of the activity at any point during the maintenance time window.  We encourage users to avoid running interactive jobs (e.g., VNC/X11) that rely on an active SSH connection to a PACE cluster during this time frame to avoid sudden interruptions due to a loss of connection to the PACE resources.  Batch jobs that are running and queued in the PACE schedulers will operate normally; however, any jobs that require resources outside of PACE or Internet will be subject to interruptions during these maintenance activities.  These maintenance activities will not affect any of the PACE storage systems.

What PACE will do:  PACE will remain on standby during these activities to monitor the systems, conduct testing and report on any interruptions in service.  For up-to-date progress, please check the Georgia Tech’s status page, https://status.gatech.edu.

If you have any questions or concerns, please direct them to pace-support@oit.gatech.edu.

OIT’s Planned Network Maintenance

[Update – September 8, 2020, 1:31PM] 

We are following up with an update on the schedule for OIT’s planned network maintenance.  OIT’s Network Engineering team will be conducting two maintenance activities scheduled for the evening of Friday, September 11th, from 7:00pm to 4:00am. Blog entry: http://blog.pace.gatech.edu/?p=6889

[Update – August 28, 2020, 6:05PM] 

As of 4:46PM, the Office of Information Technology has postponed this evening’s data center firewall upgrade and network migration. The maintenance will be rescheduled in an effort to maintain access to systems that are critical to COVID-19 data collection and contact tracing. Please expect additional communications within the next two weeks regarding new dates.

 

[Original Note – August 26, 2020, 5:44PM] 

OIT’s Network Engineering team will be conducting two maintenance activities scheduled for the evening of Friday, August 28th, starting at 8:00pm, which are anticipated to last 3 – 4 hours.  These maintenance activities will affect connections of PACE to the outside Internet that is anticipated to last 30 minutes or less from the start of the activity, which may occur at any point during this maintenance time window.

What’s about to happen:  On Friday, August 28th, starting at 8:00pm – 11:59pm, Network Engineering team will be upgrading the data center firewall appliances to the latest code that is recommended by Palo Alto who has addressed serious security vulnerabilities with their latest released code.  To reassure you, OIT’s network team has been operating with some controls in place to address these vulnerabilities, and this planned upgrade will further reduce our risk.  Second maintenance activity also starts on Friday, August 28th, starting at 8:00pm – 11:00pm, Network Engineering team will be swapping service to a more capable Network Address Translation (NAT) appliance in Coda datacenter, as the one currently in Coda  is being overloaded.  These activities will affect PACE’s connection to/from the Internet.

Who is impacted: PACE users will not be able to connect to PACE resources and/or they may lose connection during this maintenance window that may last 30 minutes or less from the start of the activity at any point during the maintenance time window.  We encourage users to avoid running interactive jobs (e.g., VNC/X11) that rely on an active SSH connection to a PACE cluster during this time frame to avoid sudden interruptions due to a lose of connection to the PACE resources.  Batch jobs that are running and queued in the PACE schedulers will operate normally; however, any jobs that require resources outside of PACE or Internet will be subject to interruptions during these maintenance activities.  These maintenance activities will not affect any of the PACE storage systems.

What PACE will do:  PACE will remain on standby during these activities to monitor the systems, conduct testing and report on any interruptions in service.

If you have any questions or concerns, please direct them to pace-support@oit.gatech.edu.

[Resolved/Monitoring] Brief Network/InfiniBand Interruptions

Dear Researchers,

As we continue to monitor our network closely after the recent issues with our network/InfiniBand, we wanted to alert you about a brief network glitch  from this afternoon that’s impacted the connection between the GPFS and the compute nodes as well as node to node communication.

What happened and what we did: At 12:45pm, we started to experience issues in connection between our two main InfiniBand switches that GPFS connects to along with compute nodes.   We observed various errors that we were able to quickly diagnose, and by 1:55pm we resolved the issues after rebooting one of the main switches.

Who is impacted: During this brief network glitch, users may have experienced slow read/write and/or errors on GPFS directories from the compute nodes.  This may have impacted running MPI jobs.  We encourage users to check on their running jobs from earlier this afternoon, and resubmit any jobs that may have been interrupted.

What we will continue to do: We will continue to monitor the network and report as needed.    We appreciate your continued understanding and patience during these recent network interruptions. Please rest assured that we are doing everything we can to keep this network fabric operational.

If you have any questions or concerns, please direct them to pace-support@oit.gatech.edu.

[Resolved/Monitoring] GPFS – network issues

We began experiencing a network issue earlier today at approximately 2:00AM with the connection between our GPFS filesystem (data and scratch directories) and about one third of PACE’s compute nodes in the Rich datacenter. Affected nodes are on these racks, indicated by the second section of the node name (e.g., rich133-s40-20 or iw-s40-21 would be on rack s40):

b13, b14, b16, b17, c32, c34, c36, c38, g13, g14, g15, g16, g17, h31, h33, k35.

As a result of this network issue, users may have experienced slow read/write on GPFS directories from these nodes that may also have impacted MPI running jobs on these nodes. We finished making a repair late this afternoon, but the slowness could return, and we are continuing to monitor the system. Thank you to users who have been reporting the issue today via support tickets. Please continue to contact us if the slowness returns.
If your jobs have been running on the impacted nodes and not producing output, please cancel and resubmit them.  To check what nodes your job is running on, please run the following command: qstat -u USER_NAME -n, replacing USER_NAME with your username, eg. “qstat -u.
If you have any questions or concerns, please direct them to pace-support@oit.gatech.edu.

Georgia Power testing in Coda

Georgia Power will be conducting additional tests of the MicroGrid powering the Coda datacenter (Hive and testflight-coda) this week. Unlike the last round, this new set of tests is expected to be a low risk for power interruption to compute nodes.

[Reopened] Network (Infiniband Subnet Manager) Issues in Rich

[ Update 8/14/20 7:00 PM ]

After an additional nearly-48-hour outage in the Rich datacenter due network/InfiniBand issues, we have brought back up PACE resources on the affected systems and released user jobs. We thank you for your patience and understanding during this unprecedented outage, as we understand the significant impact that this outage has continued to have on your research throughout this week. Please note that PACE clusters in the Coda datacenter (Hive and testflight-coda) and CUI clusters in Rich have not been impacted.

While new jobs have not begun over the past two days, already-running jobs have continued. Please check the output of any jobs that are still running. If they are failing or not producing output, please cancel them and resubmit to run again. Some running user jobs were killed in the process of repairing the network, and those should also be resubmitted to the queue.

In addition to previously reported repairs, we removed a problematic spine module from a network switch this morning and further adjusted connections. This module appeared to be causing intermittent failures when under heavy load.

Currently, our network is running at reduced capacity. We have ordered a replacement switch spine module that will be used to replace the removed part. We have conducted extensive stress testing of the network and storage today, which were far beyond tests conducted earlier in the week, that indicate the system is healthy. We will continue to monitor the systems for any further network abnormalities.

Again, thank you for your patience and understanding this week while we addressed one of the most significant outages in the history of PACE.

Please contact us at pace-support@oit.gatech.edu with any questions or if you observe unexpected behavior on the cluster.

[ Update 8/13/20 8:30 PM ]

We continue to work on the network issues impacting the Rich datacenter.  We have partitioned the network and adjusted connections in an effort to isolate the problem. As mentioned this morning, we have ordered parts to address potential problematic switches as we continue systematic troubleshooting of them. We continue to run tests on InfiniBand, and we are running an overnight stress test on the network to monitor for reoccurrence of errors. The schedulers remain paused to prevent further jobs being launched on the cluster. We will follow up tomorrow with an update on the Rich cluster network.

Thank you for your continued patience and understanding during this outage.

[ Update 8/13/20 10:10 AM ]

Unfortunately, after the nearly-80-hour outage earlier this week, we must report another network outage.  We apologize for this inconvenience, as we do understand the impact of this to your research. The network/InfiniBand issues in the Rich datacenter began reoccurring late yesterday evening, and we are aware of the issues. We are currently working to resolve them, and we have ordered replacements for the parts of the network switches that appear problematic. The issue was not detected via our deterministic testing methods and occurred only after restarting user production jobs caused very heavy network utilization. We will provide further updates once more information is available.  As before, you may experience slowness in accessing storage (home, project, and/or scratch) and/or issues with communication within MPI jobs.
We have paused all the schedulers for clusters in Rich datacenter that are accessed by the following headnodes/login nodes: login-s, login-d, login7-d, novazohar, gryphon, and testflight-login. This pause prevents additional jobs from starting, but already-running jobs have not been stopped. However, there is a chance they will be killed as we continue to work to resolve the network issues.
Please note that this network issue does not impact the Coda datacenter (Hive and testflight-coda) or CUI clusters in the Rich datacenter.
Thank you for your continued patience as we continue to work to resolve this issue.
Please contact us with any questions or concerns at pace-support@oit.gatech.edu.

[ Update 8/12/20 6:20 PM ]

After nearly 80 hours of Rich datacenter outage due to network/InfiniBand issues, we have been able to bring up the PACE compute nodes in the Rich datacenter, and user jobs have begun to run again. We thank you for your patience during this period, and we understand the significant impact of this outage on your research this week.
For any user jobs that were killed due to restarts yesterday, please resubmit the jobs to the queue at this time. Please check the output of any recent jobs and resubmit any that did not succeed.
As noted yesterday evening, we have carefully brought nodes back into production in small groups to identify issues, and we have turned off nodes that we identified as having network difficulties. Our findings point to multiple hardware problems that caused InfiniBand connectivity problems between nodes. We addressed these issues, and we are no longer observing the errors after our extensive testing. We will continue to monitor the systems, but please contact us immediately at pace-support@oit.gatech.edu if you notice your job running slowly or failing to produce output.
Please note that we will continue to work on problematic nodes that are currently offline in order to restore compute access to all PACE users, and we will contact affected users as needed.
Again, thank you for your patience and understanding this week while we addressed one of the most impactful outages in the history of PACE.
Please contact us at pace-support@oit.gatech.edu with any questions.

[ Update 8/12/20 12:30 AM ]

We continue to work to bring PACE nodes back into production. After turning off all the compute nodes and reseating faulty network connections we identified, we have been slowly bringing nodes back up to avoid overwhelming the network fabric, which has been clean so far.  We are carefully testing each group to ensure full functionality, and we continue to identify challenging nodes and repair them where possible. At this time, the schedulers remain paused while we turn on and test nodes. We will provide additional updates as more progress is made.

[ Update 8/11/20 5:15 PM]

We continue to troubleshoot the network issues in the Rich datacenter. Unfortunately, our efforts to avoid disturbing running jobs have complicated the troubleshooting, which has not led to a resolution. At this time, we need to begin systematic rebooting of many nodes, which will kill some running user jobs. We will contact users with current running jobs directly to alert you to the effect on your jobs.

Our troubleshooting today has included reseating multiple spine modules in the main datacenter switch, adjusting uplinks between the two main switches to isolate problems, and rebooting switches and some nodes already.

We will continue to provide updates as more information becomes available. Thank you for your patience during this outage.

[ Update 8/10/20 11:35 PM ]

We have made several changes to create a more stable Infiniband network, including deploying an updated subnet manager, bypassing bad switch links, and repairing GPFS filesystem errors. However, we have not yet been able to uncover all issues the network is facing, so affected schedulers remain paused for now, to ensure that new jobs do not begin when they cannot produce results.

We will provide an update on Tuesday as more information becomes available. We greatly appreciate your patience as we continue to troubleshoot.

[ Update 8/10/20 6:20 PM ]

We are continuing to troubleshoot network issues in Rich. At this time, we are working to deploy an older backup subnet manager, and we will test the network again to determine if communication has been restored after that step.

The schedulers on the affected clusters remain paused, to ensure that new jobs do not begin when they cannot produce results.

We recognize that this outage has a significant impact on your research, and we are working to restore functionality in Rich as soon as possible. We will provide an update when more information becomes available.

[ Update 8/9/20 11:55 PM]

We have restarted PACE’s Subnet Manager in Rich, but some network slowness remains. We are continuing to troubleshoot the problem. At this time, we plan to leave the Rich schedulers paused overnight in order to ensure that the issue is fully resolved before additional jobs begin, so that they will be able to run successfully.
We will provide further updates on Monday.

[ Original Post]

At approximately noon today, we began experiencing issues with our primary InfiniBand Subnet Manager in Rich data center.  PACE is investigating this issue.  We will provide an update when additional information or a resolution is available.  At this time, you may experience slowness in accessing storage (home, project, or scratch) or issues with communication within MPI jobs.

In order to minimize impact to jobs, we have paused all schedulers on the affected clusters (accessed via login-s, login-d, login7-d, novazohar, gryphon, and testflight-login headnodes). This will prevent additional jobs from starting, but jobs that are already running will not be stopped, although they may fail to produce results due to the network issues.

This issue does not impact the Coda data center (Hive & testflight-coda clusters) or CUI clusters in the Rich data center.

Please contact us with any questions or concerns at pace-support@oit.gatech.edu.

[Resolved] [testflight-coda] Lustre scratch outage

[ Update 8/11/20 10:15 AM]

Lustre scratch has been repaired. We identified a broken ethernet port on a switch and moved to another port, restoring access.

[ Original Post ]

There is an outage affecting our Lustre scratch, which is currently used only in testflight-coda. We are working with the vendor to restore the system. Storage on all PACE production systems is unaffected.

You may continue your testing in testflight-coda to prepare for your Coda migration by using Lustre project storage, accessed via the “data” symbolic link in your testflight-coda home directory.

We will provide an update when the Lustre scratch system is restored. Please contact us at pace-support@oit.gatech.edu with questions.

[Mitigated] Globus Access Restored

PACE’s globus-internal server, which hosts the PACE Internal endpoint, experienced an outage beginning earlier this afternoon. We have redirected traffic to an alternate interface, and access to PACE storage via Globus is restored.

The PACE Internal endpoint provides access to the main PACE system in Rich, including home, project, and scratch storage, in addition to serving as the interface to PACE Archive storage. Hive is accessed via a separate Globus endpoint and was not affected.

As a reminder, you can find instructions on how to use Globus for file transfer to/from PACE at http://docs.pace.gatech.edu/storage/globus/. Please contact us at pace-support@oit.gatech.edu with any questions.