Difference between revisions of "Tier1 Operations Report 2015-11-18"

From GridPP Wiki
Jump to: navigation, search
()
Line 21: Line 21:
 
| 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
 
|}
 
|}
* gdss664 (AtlasTape - D0T1) was removed from service on the 28th Oct. The system was having some problems running some network commands which were resolved by a reboot. Following there placement of a failing disk and a disk controller firmware update the server was re-tested before being put back into service on Wednesday afternoon (4th Nov).
+
* Both GDS663 (AtlasTape - D0T1) and GDSS676 (CMSTape - D0T1) were taken out of service early this morning (11th Nov). In both cases the servers were not responding correctly to DNS lookups. The servers were returned to service during Wednesday afternoon, 11th November. However, the cause of the problem has not been understood.
 +
* GDSS654 (LHCbRawRDst - D0T1) was taken out of service on Wednesday morning, 11th November.  A second disk was found to have failed while an earlier replaced disk was being rebuilt. The server was returned to service on Friday afternoon, 13th November after a third disk which was showing a large number of media errors was also replaced.
 
<!-- ***********End Resolved Disk Server Issues*********** ----->
 
<!-- ***********End Resolved Disk Server Issues*********** ----->
 
<!-- ***************************************************** ----->
 
<!-- ***************************************************** ----->
Line 45: Line 46:
 
|}
 
|}
 
* gdss707 (AtlasDataDisk - D1T0) has been out of production since Friday (16th Oct). The server was drained and is currently undergoing testing with fabric.
 
* gdss707 (AtlasDataDisk - D1T0) has been out of production since Friday (16th Oct). The server was drained and is currently undergoing testing with fabric.
* GDSS720 (AtlasDataDisk - D1T0) failed on Monday evening (9th Nov). The error looks to be in the CPU. The server is being drained ahead of the CPU being swapped.
+
* GDSS720 (AtlasDataDisk - D1T0) failed on Monday evening (9th Nov). The error looks to be in the CPU. The server has been drained, the CPU swapped, and the server is being re-tested ahead of being returned to service.
* Both GDS663 (AtlasTape - D0T1) and GDSS676 (CMSTape - D0T1) were taken out of service early this morning (11th Nov). In both cases the servers were not responding correctly to DNS lookups. This is similar to the problem seen recently on GDSS664. The problem is under investigation. There are no migration candidates on either server now.
+
* GDSS654 (LHCbRawRDst - D0T1) was taken out of service this morning. A second disk was found to have failed while an earlier replaced disk was being rebuilt.
+
 
+
 
<!-- ***************End Ongoing Disk Server Issues**************** ----->
 
<!-- ***************End Ongoing Disk Server Issues**************** ----->
 
<!-- ************************************************************* ----->
 
<!-- ************************************************************* ----->

Revision as of 16:30, 17 November 2015

RAL Tier1 Operations Report for 18th November 2015

Review of Issues during the week 11th to 18th November 2015.
  • We have been investigating the behaviour of some batch jobs as there is a low level of failures that are not understood.
  • We are investigating a problem that has affected some Castor disk servers ability to make DNS lookups.
Resolved Disk Server Issues
  • Both GDS663 (AtlasTape - D0T1) and GDSS676 (CMSTape - D0T1) were taken out of service early this morning (11th Nov). In both cases the servers were not responding correctly to DNS lookups. The servers were returned to service during Wednesday afternoon, 11th November. However, the cause of the problem has not been understood.
  • GDSS654 (LHCbRawRDst - D0T1) was taken out of service on Wednesday morning, 11th November. A second disk was found to have failed while an earlier replaced disk was being rebuilt. The server was returned to service on Friday afternoon, 13th November after a third disk which was showing a large number of media errors was also replaced.
Current operational status and issues
  • 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.
  • 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.
Ongoing Disk Server Issues
  • gdss707 (AtlasDataDisk - D1T0) has been out of production since Friday (16th Oct). The server was drained and is currently undergoing testing with fabric.
  • GDSS720 (AtlasDataDisk - D1T0) failed on Monday evening (9th Nov). The error looks to be in the CPU. The server has been drained, the CPU swapped, and the server is being re-tested ahead of being returned to service.
Notable Changes made since the last meeting.
  • Two tape servers are now running Castor 2.1.15.
  • Another set (of four) Castor D0T1 disk servers have been upgraded to SL6.
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.
Service Scheduled? Outage/At Risk Start End Duration Reason
Whole Site SCHEDULED WARNING 18/11/2015 09:30 18/11/2015 10:30 1 hour Warning on site during small change to network configuration.
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 On Hold 2015-10-12 2015-11-04 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
04/11/15 100 100 98 100 100 92 100 Single SRM test failure "could not open connection to srm-atlas.gridpp.rl.ac.uk:8443"
05/11/15 100 100 100 100 100 93 100
06/11/15 100 100 100 100 100 90 100
07/11/15 100 100 100 100 100 97 100
08/11/15 100 100 100 100 100 100 N/A
09/11/15 100 100 100 100 100 93 100
11/11/15 100 100 100 100 100 100 100
12/11/15 100 100 100 100 100 100 100
13/11/15 100 100 100 100 100 100 100
14/11/15 100 100 100 100 100 100 100
15/11/15 100 100 100 100 100 100 100
16/11/15 100 100 100 100 100 100 100
17/11/15 100 100 100 100 100 100 100