View Issue Details

IDProjectCategoryView StatusLast Update
000878610000-004: ServicesSpecpublic2023-06-19 15:02
ReporterJim Luth Assigned ToMatthias Damm  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.05.03 
Fixed in Version1.05.03 RC1 
Summary0008786: Current non-transparent redundancy specifications do not work for a primary/standby set of Servers
Description

A non-transparent redundancy approach using a primary and a standby is a very typical design pattern for DCS Controllers.
The current definition of non-transparent redundancy in the UA specs does not support this type of redundancy. It is appropriate for a load balancing design pattern where any Server in a redundant set can provide clients with the same functionality with the only difference being the performance based on client demand.

I propose a new subtype of NonTransparentRedundancyType be created which adds a property that provides an enumerated mode of the server. This enumeration would describe a server as being the current primary with one or more ready standbys, the current primary with no ready standbys, ready to be the primary, or not ready to be the primary. The normal ServerLevel and ServerState would continue to function as it does for all other cases of Server redudancy.

TagsNo tags attached.
Attached Files
image.png (103,108 bytes)   
image.png (103,108 bytes)   
image-2.png (269,577 bytes)
image-3.png (53,458 bytes)   
image-3.png (53,458 bytes)   
Commit Version
Fix Due Date

Relationships

related to 0008733 closedJeff Harding 10000-005: Information Model Current non-transparent redundancy specifications do not work for a primary/standby set of Servers 

Activities

Matthias Damm

2023-04-11 16:26

developer   ~0019150

My expectation was that this model is covered by Warm and/or ServiceLevel

Jeff Harding

2023-04-11 16:26

developer   ~0019151

ServiceLevel will not work because of the way we define its use by clients. It is specifically designed to assume a load balancing use case. It will not work for primary backup use cases. Specifically in part 4 the definition of 'healthy' last paragraph about not switching to another server

Jeff Harding

2023-04-11 16:26

developer   ~0019152

Agreed at Dallas Face2Face Mar 23, 2023 to add a new subtype of NonTransparentRedundancyType to address the Primary/Standby use cases. Agreed on the following:

  • failover approach fits best with Warm but the definition of Warm needs to relaxed
  • The ServiceLevel of the standby which is fully ready to take over will be defined as Degraded 199 and explained to be fully functional as a standby. Other lower levels would be used to indicate a standby that is not prepared to take over due to some vendor specific reason.
  • A property will be included in the new subtype which indicates the overall status of the primary and standby. At least representing 4 states (primary with standby, primary with no ready standby, standby ready to be primary and standby not ready.
  • A method will be included in the new subtype which is used to manually fail over. Can be call in the primary or the secondary(s). If more than 1 secondary a call to the primary will result in the primary deciding which standby will take over.

Proposed types attached here.

Jim Luth

2023-04-11 16:27

administrator   ~0019154

Jeff will propose the updated text for Part 4.

Jeff Harding

2023-04-11 17:04

developer   ~0019165

Proposed additions to Part 4.

In Table 109 - ServiceLevel ranges, in Row 'Degraded' change the second paragraph to the following:
"Servers that report a ServiceLevel in the Degraded sub-range are partially able to service Client requests. The degradation could be caused by loss of connection to underlying systems or functioning in a mode which results in some less than full functionality being available. Alternatively, it could be that the Server is overloaded to the point that it is unable to reliably deliver data to Clients in a timely manner."

In Table 110 Server Failover modes, in Row 'Warm" change the first sentence to the following:
"Warm Failover mode is where the backup Server(s) can be active, but is not operating in a mode which delivers the same level of functionality available from the primary Server. For example it cannot connect to actual data points (typically, a system where the underlying devices are limited to a single connection). "

Matthias Damm

2023-06-16 15:04

developer   ~0019502

Added proposed text to "Table 109 – ServiceLevel ranges"
Added proposed text to "Table 110 – Server Failover modes"
Added also to Table 110:
The ServiceLevel of the primary Server will be in the Healthy ServiceLevel sub-range. The ServiceLevel of the available standby Server will be in the Degraded ServiceLevel sub-range.

Jim Luth

2023-06-19 15:02

administrator   ~0019518

Agreed to changes in Virtual F2F.

Issue History

Date Modified Username Field Change
2023-04-11 16:26 Jim Luth New Issue
2023-04-11 16:26 Jim Luth Status new => assigned
2023-04-11 16:26 Jim Luth Assigned To => Jeff Harding
2023-04-11 16:26 Jim Luth Issue generated from: 0008733
2023-04-11 16:26 Jim Luth Note Added: 0019150
2023-04-11 16:26 Jim Luth Note Added: 0019151
2023-04-11 16:26 Jim Luth Note Added: 0019152
2023-04-11 16:26 Jim Luth Relationship added related to 0008733
2023-04-11 16:27 Jim Luth Project 10000-005: Information Model => 10000-004: Services
2023-04-11 16:27 Jim Luth Note Added: 0019154
2023-04-11 16:27 Jim Luth Assigned To Jeff Harding => Matthias Damm
2023-04-11 17:04 Jeff Harding Note Added: 0019165
2023-06-16 15:04 Matthias Damm Status assigned => resolved
2023-06-16 15:04 Matthias Damm Resolution open => fixed
2023-06-16 15:04 Matthias Damm Note Added: 0019502
2023-06-19 15:02 Jim Luth Status resolved => closed
2023-06-19 15:02 Jim Luth Fixed in Version => 1.05.03 RC1
2023-06-19 15:02 Jim Luth Note Added: 0019518