Difference between revisions of "Tier1 Operations Report 2016-06-29"

Latest revision as of 09:56, 29 June 2016

RAL Tier1 Operations Report for 29th June 2016

• The problems with the "ACSLS" control software for the tape library crashing as reported at previous meetings continued up until last Wednesday (22nd). Various actions were taken to understand the problem and we have worked closely with the vendor (Oracle). Since that date the system has been stable - with no crashes at all for a week. We do have a reduced number of Tier1 tape drives in use - although this has been sufficient to keep up with the existing workload. However, the cause of the problem has not been understood and our investigations continue. We will be changing various configurations of the tape library during the working day with the aim of understanding this problem, returning to what be believe is a known good configuration overnight.
• At the start of this period we continued to see high load on the OPN link. However this has eased off for the last week or so.
• On Friday there was a problem with lcgwms04. A user had submitted many jobs needing large output sandboxes. The user was contacted and responded quickly. It took us a while to clear jobs already in lcgwms04 and there were some ongoing problems until the start of this week.
• Yesterday afternoon (Tuesday 28th) there was a problem with the Atlas Castor instance that lasted for a few hours. This was resolved by a restart of processes. We have suggestion as to the cause of this problem (a resource limit) although it is not conclusive.

• GDSS748 (AtlasDataDisk - D1T0) crashed on the afternoon of Sunday morning 19th June. There were problems with the RAID array which were finally fixed by transplanting all the disks into another chassis which was re-named. The server was put back in service read-only on Tuesday 21st June. It is being drained ahead of sorting out the re-named system.
• GDSS743 (AtlasDataDisk - D1T0) crashed in the early hours of Monday 20th June. Following two disk replacements it was put back in service the following day, initially read-only. Once teh disk rebuilds had all completed it was set back to read/write.

• There is a problem seen by LHCb of a low but persistent rate of failure when copying the results of batch jobs to Castor. There is also a further problem that sometimes occurs when these (failed) writes are attempted to storage at other sites. A recent modification has improved, but not completed fixed this.
• The intermittent, low-level, load-related packet loss seen over external connections is still being tracked. Likewise we have been working to understand some remaining low level of packet loss seen within a part of our Tier1 network.

• None.

• All access to GenScratch has now been stopped. (As announced)
• ARC-CE02 has been reinstalled on new virtual infrastructure. The space for job sandboxes has been tripled.
• All access to lecgwms06 has now been stopped - largely completing the decommissioning procedure.
• The migration of Atlas data from "C" to "D" tapes continues. We have migrated around 600 of the 1300 tapes so far.

Listing by category:

• Databases:
  • Switch LFC/3D to new Database Infrastructure.
• Castor:
  • Update SRMs to new version, including updating to SL6. This will be done after the Castor 2.1.15 update.
  • Update to Castor version 2.1.15. This awaits successful resolution and testing of the new version.
  • Migration of data from T10KC to T10KD tapes (Affects Atlas & LHCb data).
• Networking:
  • Replace the UKLight Router. Then upgrade the 'bypass' link to the RAL border routers to 2*40Gbit.
• Fabric
  • Firmware updates on remaining EMC disk arrays (Castor, LFC)

Key: Atlas HC = Atlas HammerCloud (Queue ANALY_RAL_SL6, Template 729); CMS HC = CMS HammerCloud