Posts

Large Scale Slowness Issues

Update: (3/10/2016, 5:00pm) Most issues are resolved, back to normal operation

The GPFS storage is back to normal performance and has now been stable for several days. However, we will continue to explore additional steps with DDN to improve the performance of the GPFS storage and schedule any upgrades recommended for our maintenance time in April. Please continue to let us know if you observe any difficulties with this critical component of the PACE clusters.

What happened:

As with most any significant storage issue, there were multiple vectors of difficulty encountered. We identified multiple factors contributing to the GPFS performance problems including uncommonly high user activity, a bad cable connection, a memory misconfiguration on most systems when we added the new GPFS scratch file system and a scheduler configuration to correctly use the new scratch space.

What was impacted:

Performance of all GPFS file systems suffered greatly during the event. Compute, login and interactive nodes and scheduler servers temporarily lost their mount points, impacting some of the running jobs. There was never any loss of user data or data integrity.

What we did:

We contacted the storage vendor support and worked with them via several phone and screen-sharing sessions to isolate and correct each of the several problems. We have added storage and node monitoring to be able to detect the memory and file system conditions that were contributing factors to this failure and have discussed operation and optimization steps with the necessary users.

What is ongoing:

We continue to work with the vendor to resolve any remaining issues and will strive to further improve performance of the file system.

 

Update: (3/4/2016, 6:30pm) GPFS storage still stable, albeit with intermittent slowness 

GPFS storage has been mostly stable. While not back to previous levels, the performance of the GPFS storage continued to improve today. We identified multiple factors contributing to the problem, including uncommonly high user activity. There are almost half a billion files in the system and the bandwidth usage has approximated the design peak a few times, which is unprecedented. While it’s great that the system is utilized at that levels, the impact of problems inevitably gets amplified under high load. We continue to work with the vendor to resolve the remaining issues and really appreciate your patience with us during this long battle.

You can help us a great deal by avoiding large data operations (e.g. cp, scp, rsync) on the headnodes. The headnodes are low capacity VMs that do not mount GPFS using native clients. Instead, all the traffic goes through a single NFS fileserver. The proper location for all data operations is the datamover node (iw-dm-4.pace.gatech.edu), which is a physical machine with fast network connections to all storage servers. Please limit your activity on the datamover machine strictly with data operations. We noticed several users running regular computations on this node and had to kill those processes.

Update: (3/1/2016, 7:30pm) GPFS storage has stabilized and schedulers are resumed.

GPFS storage appears to have stabilized, without any data loss, and we resumed scheduling to allow new jobs on the cluster.

It seems our system had outgrown an important storage configuration parameter (tokenMemLimit) having to do roughly with the number of open files times file systems times number of nodes for the whole storage-system. There was no warning message given by the storage system of impending failure. There were some symptoms observed which we were investigating which we, of course, now understand more clearly. We have asked the vendor to review the remaining parameters and recommend any additional changes.

Update: (3/1/2016, 4:30pm) Schedulers paused, new jobs will not start

Unfortunately we lost GPFS storage on the majority of compute nodes, potentially impacting running jobs using this file storage system (most project directories and all scratch). To prevent future problems, we temporarily paused schedulers. Your submissions (qsub) will appear to be hanging until we resume the scheduling functions.

What’s happening
Many users noticed that GPFS storage has slowed down recently. In some cases, this causes unresponsive commands (e.g. ‘ls’) on headnodes.

Who’s impacted

GPFS storage includes some project space (data), the new scratch, and Tardis-6 queue home directories.

How PACE is responding

We are taking the first of the several steps to address this issue. Instead of an unplanned downtime, we are planning to submit jobs to request entire nodes to facilitate the fix. This way, the solution can be applied when there are no jobs actively running on the node.

These jobs will be submitted by “pcarey8” user and will run on all of the queues. You will continue to see these jobs until all nodes are fixed, which may span a long time period (depending on when the nodes become available, which are already running long-walltime jobs). Once a node is acquired, the fix will not take too long to apply, however.

How can you help

* Replace “$PBS_O_WORKDIR” with the actual path to working directory in submission (PBS) scripts.

* Prevent concurrent data transfers and operations for very large number of files.

PACE clusters ready for research

Our January maintenance window is now complete.  As usual, we have a number of compute nodes that still need to be brought back online, however, we are substantially online and processing jobs at this point.

Transition to new scratch storage
Of approximately 1,700 PACE users, we were unable to migrate less than 35.  All users should have received an email as to their status.  Additionally, those users who were not migrated will have support tickets created on their behalf so we can track their migrations through completion.  We expect about 25 of those 35 users to complete within the next 72 hours.  The remaining 10 have data in excess of the allowable quota and will be handled on a case-by-case basis.

Scheduler update
The new schedulers are in place and processing jobs.

Server networking
Task is complete as described.

GPFS tuning
Task is complete as described.

Filesystem migration – /nv/pk1
Task is complete as described.

Read-Only /usr/local
Task is complete as described.

Diskess node transition
We upgraded approximately 65 diskless nodes with local operating system storage.

PACE quarterly maintenance – January ’16

Greetings!

The PACE team is once again preparing for maintenance activities that will occur starting at 6:00am Tuesday, January 26 and continuing through Wednesday, January 27.  We have a couple of major items that hopefully will provide a much better PACE experience.

Transition to new scratch storage

Building on the new DDN hardware deployed in October, this item is the dominant activity in this maintenance period.  Our old Panasas scratch storage has now exceeded its warranty, so this is a “must do” activity.  Given then performance level of the Panasas and the volume of data it contains, we do not believe we will be able to migrate all data during this maintenance period.  So, we will optimize the migration to maximize the number of users migrated.  Using this approach, we believe we will be able to migrate more than 99% of the PACE user community.  After the maintenance window, we will work directly with those individuals who we are not able to migrate.  You will receive an email when your migration begins, and when it is complete.  (Delivered to your official GT email address, see previous post!)

After the maintenance period, the old Panasas scratch will still be available, but in read-only mode.  All users will have scratch space provisioned on the new GPFS scratch.  Files for users who are successfully migrated will not be deleted, but will be rendered inaccessible except to PACE staff.  This provides a safety net in the unlikely event that something goes wrong.

For the time being, we will preserve the 5TB soft quota and 7TB hard quota on the new GPFS scratch, as well as the 60 day maximum file age.  However, the timestamps of the files will get reset as they migrate, so the 60 day timer gets reset for all files.

The ~/scratch symlinks in your home directories will also be updated to point to the new locations, so please continue to use these paths to refer to your scratch files.  File names beginning with /panfs will no longer work once your migration is complete.

Scheduler update

Pending successful testing, we will also be rolling out a bug fix update to our Moab & Torque scheduler software and increase network connectivity for our most heavily used schedulers.  Among issues addressed in this release is a bug where we have seen erratic notifications about failures canceling jobs, incorrect groups being included in reports and some performance improvements.  Unlike previous scheduler upgrades, all previously submitted jobs will be retained.  No user action should be required as a result of this upgrade.

Server networking

We will be upgrading network connectivity on some of our servers to take advantage of network equipment upgraded in October.  No user action required.

GPFS tuning

We will adjust parameters on some GPFS clients to more appropriately utilize their Infiniband connections.  This only affects the old (6+ years) nodes with DDR connections.  We will also substitute NFS access for native GPFS access on machines that lack Infiniband connectivity or have otherwise been identified as poorly performing GPFS clients.  In particular, this will affect most login nodes.  The /gpfs path names on these machines will be preserved, so no user action is needed here either.

Filesystem migration – /nv/pk1

The /nv/pk1 filesystem for the Aryabhata cluster will be migrated to GPFS.

Read-Only /usr/local

The /usr/local filesystem will be exported read-only.  This is a security measure, and should not impact normal operations.

Diskless node transition

We will continue the transition away from diskless nodes that we started in October.  This mainly affects nodes in the 5-6 years old range.  Apart from more predictable performance of these nodes, this should also be a transparent change.

Changing the way PACE handles email

Greetings!

In order to help ensure the reliability of email communications from PACE, we will be changing how we deliver mail effective Wednesday, January 20. (next week!) From this time forward, PACE will use only the officially published email addresses as defined in the Georgia Tech Directory.

This is a needed change, as we have many, many messages that we have been unable to deliver due to outdated or incorrect destinations.

The easiest way to determine your official email address is to visit http://directory.gatech.edu and enter your name. If you wish to change your official email address, visit http://passport.gatech.edu.

In particular, this change will affect the address which is subscribed to PACE related email lists (i.e. pace-availability and such) as well as job status emails generated automatically from the schedulers.

For the technically savvy, we will be changing our mail servers to lookup addresses from GTED. We will no longer use the contents of a users ~/.forward file.

p.s. Users of the Tardis cluster do not have entires in the Georgia Tech directory, this change does not apply to you.

Early Testflight Scheduler Upgrade

As you may know, we are preparing for upgrading the scheduler versions (that are known to be faster and less buggy) on the next maintenance day (01/26/2015, Tue).

The “testflight-sched” scheduler, which runs “testflight” and “ligo-6” queues, will receive these updates earlier for testing, most likely today. The upgrades will be mostly transparent from users, with the exception of 30min (estimated) downtime on the scheduler server as well as “testflight-6”  and “ligo-6” headnodes. For the duration of scheduler upgrade, your queries and commands will return “Cannot reach server”. The headnodes will also need to be rebooted several times, so please make sure you don’t use them for anything critical (text editing, interactive matlab sessions, etc). We confirmed that old client services on the compute nodes can still communicate with the new server, so we will be able to upgrade nodes one-by-one, without killing any running jobs, as they become idle.

Once the upgrades are complete (we will let you know), we strongly encourage every PACE user to run at least a few test jobs on testflight to make sure everything will work after the upgrades. We cannot express enough the importance of testing the new version, given our past experience with scheduler upgrades. Please contact us as soon as possible if you notice any problems or odd behavior.

Another reason for this early upgrade is to finalize upgrade procedures, which means that they are not tested yet. Therefore, expect problems and don’t rely on testflight for anything critical (which is a warning that applies to this testflight at all times, as the name suggests).

Thank you in advance for your cooperation and feedback!

PACE clusters (mostly) ready for research (cont.)

Hello all,
I’d like to apologize again for the delays in getting back to an operational state after this maintenance period.  At this point we have most things stable, although there may have been a small number of jobs interrupted over the last couple of days.
About 85% of our compute nodes are available for jobs at this point, and we continue efforts to bring those back into service.
We’ve also worked out some performance issues with the new home directory file servers that primarily impacted users of the tcsh shell.
At this point, if you see any strange behavior (other than missing nodes! 😉 please do let us know via a request to pace-support@oit.gatech.edu.

PACE clusters (mostly) ready for research

Greetings,

We’ve made substantial progress getting through our activities, and are releasing jobs.  We still have a number of compute nodes that still need to be brought online, however all clusters have some amount of resources and are running jobs.  We will continue to work through these issues later today.  After sleep.

 

Major upgrade to DDN & a new scratch storage

All data migrated successfully to new front ends, additional disks have been added for upcoming scratch.  Substantial delays due to unanticipated long running processes to join compute nodes to the new GPFS cluster.  This work is still ongoing.  Benchmarking suggests a slight performance improvement for those of you with project directories in GPFS.

New PACE router and firewall hardware & additional core network capacity

successfully completed without incident.

Panasas scratch filesystem maintenance

successfully completed without incident.

Migration of home directories

successfully completed without incident.

Migration of /usr/local storage

successfully completed without incident.

Begin transition away from diskless compute nodes.

migrated approximately 100 compute nodes.  Some of these still have issues with GPFS, as above.

ONGOING: PACE quarterly maintenance – October ’15

We’ve had some unexpected delays and challenges this go around.  The short version is that we will need to extend our maintenance activities into tomorrow.  We’ll do a rolling release to you as we can bring compute nodes online.

 

The long version:

The storage system that is responsible for /usr/local and our virtual machine infrastructure experienced a hardware failure that caused us a significant amount of lost time.  Some PACE staff have spent 40 of the last 48 hours on site in order to try and make corrections.  We were already planning on transitioning /usr/local off of this storage and had alternate storage in place.  Likewise for the virtual machines, although our plan was to live-migrate those after maintenance activities were complete.  The good news is that we don’t have data loss, the bad news is that we’ve had to accelerate the virtual machine migration, resulting in additional unplanned effort.

Also, the DDN work is taking far longer than expected.  Part of this work required us to remove all nodes from the GPFS filesystem and add them back in again.  Current estimates to bring everything back to full production range from an additional 12 to 24 hours.  This means between 10am and 10pm tomorrow before we have everything back up.  As mentioned above, we will make things available as soon as we can.  Pragmatically, that means that clusters will initially be available at reduced capacity.  Look for another post here when we start enabling logins again.