Difference between revisions of "Tier1 Operations Report 2015-10-21"

From GridPP Wiki
Jump to: navigation, search
()
()
 
(10 intermediate revisions by one user not shown)
Line 9: Line 9:
 
| style="background-color: #b7f1ce; border-bottom: 1px solid silver; text-align: center; font-size: 1em; font-weight: bold; margin-top: 0; margin-bottom: 0; padding-top: 0.1em; padding-bottom: 0.1em;" | Review of Issues during the week 14th to 21st October 2015.
 
| style="background-color: #b7f1ce; border-bottom: 1px solid silver; text-align: center; font-size: 1em; font-weight: bold; margin-top: 0; margin-bottom: 0; padding-top: 0.1em; padding-bottom: 0.1em;" | Review of Issues during the week 14th to 21st October 2015.
 
|}
 
|}
* We have been seeing problems with very high load on the AtlasTape Castor instance. This was leading to a big backlog of files waiting to go to tape as well as a big delay in files being brought online. Additinal disk servers have been added to this instance (the number of servers doubled from five to ten). At the time of the meeting Atlas have also throttled back the write requests.
+
* Some problems with the our (and other) FTS3 service was seen by Atlas and was fixed.
* LHCb have reported an ongoing low but persistent rate of failure when copying the results of batch jobs to other sites. They have also reported a current problem that sometimes occurs when writing these files to our Castor storage.
+
* ILC reported that a CVMFS repository (/cvmfs/ilc.desy.de) was not available on the worker nodes. This was traced to a missing public key. This has now been fixed across the worker nodes.
+
 
<!-- ***********End Review of Issues during last week*********** ----->
 
<!-- ***********End Review of Issues during last week*********** ----->
 
<!-- *********************************************************** ----->
 
<!-- *********************************************************** ----->
Line 22: Line 20:
 
| style="background-color: #f8d6a9; border-bottom: 1px solid silver; text-align: center; font-size: 1em; font-weight: bold; margin-top: 0; margin-bottom: 0; padding-top: 0.1em; padding-bottom: 0.1em;" | Resolved Disk Server Issues
 
| style="background-color: #f8d6a9; border-bottom: 1px solid silver; text-align: center; font-size: 1em; font-weight: bold; margin-top: 0; margin-bottom: 0; padding-top: 0.1em; padding-bottom: 0.1em;" | Resolved Disk Server Issues
 
|}
 
|}
* GDSS657 (LHCb_RAW - D0T1) was returned to service on Thursday (8th Oct). This server had failed on Saturday (3rd October). After being checked it was returned to service the following day in read-only mode. However, subsequent investigations to fix a problem on this server uncovered a further problem. As reported last week four files were found to be corrupt (partially written) from the time when the server first failed and these were reported to LHCb.
+
* GDSS746 (AtlasDataDisk - D1T0) failed on Saturday (17th Oct). Following checks it was returned to service yesterday afternoon (Tuesday 20th). It was initially put into a readonly mode (overnight) as the RAID array verification ran. It was set in full production this morning. Three files that were truncated as the server failed have been declared lost to Atlas.
 
<!-- ***********End Resolved Disk Server Issues*********** ----->
 
<!-- ***********End Resolved Disk Server Issues*********** ----->
 
<!-- ***************************************************** ----->
 
<!-- ***************************************************** ----->
Line 33: Line 31:
 
| style="background-color: #b7f1ce; border-bottom: 1px solid silver; text-align: center; font-size: 1em; font-weight: bold; margin-top: 0; margin-bottom: 0; padding-top: 0.1em; padding-bottom: 0.1em;" | Current operational status and issues
 
| style="background-color: #b7f1ce; border-bottom: 1px solid silver; text-align: center; font-size: 1em; font-weight: bold; margin-top: 0; margin-bottom: 0; padding-top: 0.1em; padding-bottom: 0.1em;" | Current operational status and issues
 
|}
 
|}
 +
* The LHCb problem with 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.
 
* 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.
 
* 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.
 
* Long-standing CMS issues. The two items that remain are CMS Xroot (AAA) redirection and file open times. Work is ongoing into the Xroot redirection with a new server having been added in recent weeks. File open times using Xroot remain slow but this is a less significant problem.
 
* Long-standing CMS issues. The two items that remain are CMS Xroot (AAA) redirection and file open times. Work is ongoing into the Xroot redirection with a new server having been added in recent weeks. File open times using Xroot remain slow but this is a less significant problem.
Line 45: Line 44:
 
| style="background-color: #f8d6a9; border-bottom: 1px solid silver; text-align: center; font-size: 1em; font-weight: bold; margin-top: 0; margin-bottom: 0; padding-top: 0.1em; padding-bottom: 0.1em;" | Ongoing Disk Server Issues
 
| style="background-color: #f8d6a9; border-bottom: 1px solid silver; text-align: center; font-size: 1em; font-weight: bold; margin-top: 0; margin-bottom: 0; padding-top: 0.1em; padding-bottom: 0.1em;" | Ongoing Disk Server Issues
 
|}
 
|}
* None
+
* GDSS707 (AtlasDataDisk - D1T0) failed on Friday (16th Oct). This server had only been put back into service at the end of September. The server was drained of files over the weekend and the problem is being investigated.
 +
* GDSS657 (LHCb_RAW - D0T1) failed on Sunday (18th Oct). This server had only been put back into service on the 8th October. One file that was being written as it failed was lost. The server was returned to service yesterday (20th Oct) but this morning was reporting further disk drive/controller problems and has been taken out of service again. (There are no files awaiting migration to tape).
 +
* GDSS637 (AtlasTape - D0T1) was taken out of service on Monday (19th Oct) as it was showing a disk drive /controller problem. There were no files waiting to go to tape. The problem is being investigated.
 
<!-- ***************End Ongoing Disk Server Issues**************** ----->
 
<!-- ***************End Ongoing Disk Server Issues**************** ----->
 
<!-- ************************************************************* ----->
 
<!-- ************************************************************* ----->
Line 56: Line 57:
 
| style="background-color: #b7f1ce; border-bottom: 1px solid silver; text-align: center; font-size: 1em; font-weight: bold; margin-top: 0; margin-bottom: 0; padding-top: 0.1em; padding-bottom: 0.1em;" | Notable Changes made since the last meeting.
 
| style="background-color: #b7f1ce; border-bottom: 1px solid silver; text-align: center; font-size: 1em; font-weight: bold; margin-top: 0; margin-bottom: 0; padding-top: 0.1em; padding-bottom: 0.1em;" | Notable Changes made since the last meeting.
 
|}
 
|}
* The final step in the update of the Castor Oracle databases to version 11.2.0.4 took place yesterday (Tuesday 13th Oct). This was the switch-over of the production and standby versions of the "pluto" database to return these to their correct configuration. This completes the upgrades to 11.2.0.4 of all Oracle databases used by the Tier1.
+
* A change has been made to the FTS3 service (at developers request) to fix a problem that caused some Atlas transfers to stall.
* Five additional disk servers were added to atlasTape in order to ease the high load seen on this instance. (Tuesday 13th).
+
* Yesterday (Tuesday 20th) four disk servers in tape-backed service classes were updated to SL6. This was a transparent operation.
* Disk server GDSS758 was deployed into into lhcbDst (D1T0). This is a server that had been out of service for some time.
+
* The update of the final batch of worker nodes to the new configuration has been done.
+
 
<!-- *************End Notable Changes made this last week************** ----->
 
<!-- *************End Notable Changes made this last week************** ----->
 
<!-- ****************************************************************** ----->
 
<!-- ****************************************************************** ----->
Line 94: Line 93:
 
** Update to Castor version 2.1.15.
 
** Update to Castor version 2.1.15.
 
* Networking:
 
* Networking:
 +
*** Complete changes needed to remove the old core switch from the Tier1 network.
 
** Make routing changes to allow the removal of the UKLight Router.
 
** Make routing changes to allow the removal of the UKLight Router.
 
* Fabric
 
* Fabric
Line 126: Line 126:
 
| Green
 
| Green
 
| Less Urgent
 
| Less Urgent
| In Progress
+
| On Hold
 
| 2015-10-12
 
| 2015-10-12
| 2015-10-13
+
| 2015-10-19
 
| SNO+
 
| SNO+
 
| snoplus support at RAL-LCG2 (pilot role)
 
| snoplus support at RAL-LCG2 (pilot role)
Line 137: Line 137:
 
| In Progress
 
| In Progress
 
| 2015-10-12
 
| 2015-10-12
| 2015-10-12
+
| 2015-10-14
 
| CMS
 
| CMS
 
| T1_UK_RAL AAA opening and reading test failing again...
 
| T1_UK_RAL AAA opening and reading test failing again...

Latest revision as of 11:10, 21 October 2015

RAL Tier1 Operations Report for 21st October 2015

Review of Issues during the week 14th to 21st October 2015.
  • Some problems with the our (and other) FTS3 service was seen by Atlas and was fixed.
Resolved Disk Server Issues
  • GDSS746 (AtlasDataDisk - D1T0) failed on Saturday (17th Oct). Following checks it was returned to service yesterday afternoon (Tuesday 20th). It was initially put into a readonly mode (overnight) as the RAID array verification ran. It was set in full production this morning. Three files that were truncated as the server failed have been declared lost to Atlas.
Current operational status and issues
  • The LHCb problem with 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.
  • 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.
  • Long-standing CMS issues. The two items that remain are CMS Xroot (AAA) redirection and file open times. Work is ongoing into the Xroot redirection with a new server having been added in recent weeks. File open times using Xroot remain slow but this is a less significant problem.
Ongoing Disk Server Issues
  • GDSS707 (AtlasDataDisk - D1T0) failed on Friday (16th Oct). This server had only been put back into service at the end of September. The server was drained of files over the weekend and the problem is being investigated.
  • GDSS657 (LHCb_RAW - D0T1) failed on Sunday (18th Oct). This server had only been put back into service on the 8th October. One file that was being written as it failed was lost. The server was returned to service yesterday (20th Oct) but this morning was reporting further disk drive/controller problems and has been taken out of service again. (There are no files awaiting migration to tape).
  • GDSS637 (AtlasTape - D0T1) was taken out of service on Monday (19th Oct) as it was showing a disk drive /controller problem. There were no files waiting to go to tape. The problem is being investigated.
Notable Changes made since the last meeting.
  • A change has been made to the FTS3 service (at developers request) to fix a problem that caused some Atlas transfers to stall.
  • Yesterday (Tuesday 20th) four disk servers in tape-backed service classes were updated to SL6. This was a transparent operation.
Declared in the GOC DB
  • None
Advanced warning for other interventions
The following items are being discussed and are still to be formally scheduled and announced.
  • Upgrade of remaining Castor disk servers (those in tape-backed service classes) to SL6. This will be transparent to users.
  • Some detailed internal network re-configurations to enable the removal of the old 'core' switch from our network. This includes changing the way the UKLIGHT router connects into the Tier1 network.

Listing by category:

  • Databases:
    • Switch LFC/3D to new Database Infrastructure.
  • Castor:
    • Update SRMs to new version (includes updating to SL6).
    • Update disk servers to SL6 (ongoing)
    • Update to Castor version 2.1.15.
  • Networking:
      • Complete changes needed to remove the old core switch from the Tier1 network.
    • Make routing changes to allow the removal of the UKLight Router.
  • Fabric
    • Firmware updates on remaining EMC disk arrays (Castor, LFC)
Entries in GOC DB starting since the last report.
  • None
Open GGUS Tickets (Snapshot during morning of meeting)
GGUS ID Level Urgency State Creation Last Update VO Subject
116866 Green Less Urgent On Hold 2015-10-12 2015-10-19 SNO+ snoplus support at RAL-LCG2 (pilot role)
116864 Green Urgent In Progress 2015-10-12 2015-10-14 CMS T1_UK_RAL AAA opening and reading test failing again...
Availability Report

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

Day OPS Alice Atlas CMS LHCb Atlas HC CMS HC Comment
14/10/15 100 100 100 100 100 91 n/a
15/10/15 100 100 98 100 100 85 100 Single SRM test failure (ould not open connection to srm-atlas.gridpp.rl.ac.uk:8443)
16/10/15 100 100 100 98 100 89 100 Short problem with glexec in the early hours of the morning.
17/10/15 100 100 100 100 100 95 100
18/10/15 100 100 100 100 100 92 n/a
19/10/15 100 100 100 100 100 100 100
20/10/15 100 100 100 100 100 93 100