Secondary service runs as primary service.
When there was a time-sync problem with the domain system (secondary was set 12 hours late), the secondary Connectivity server could not properly access the domain system when it was restarted.
At this time, joined to domain in an unusual way and all services were normal. But actually, there was a problem with the trend screen, and when I checked the service status,
the Basic history service of the secondary was running. When I disabled the Basic history service on the secondary CS, Trend display became normal.
My customer asked me why secondary service operates beyond primary service while using redundancy service ?
and how domain controller works in redundant system? (1 working 1 standby, or 2 works simultaneously ?)
Thank you in advance for your answer.
Answers
Running domain controllers out of clock sync, or running domain members out of clock sync with the domain controller(s) can yield any kind of trouble which I will not go into detail about. Poor time sync is simply a "No Go".
Keeping all domain controllers and members in sync is very important and this check item in System Health Check should be revisited periodically to ensure smooth time sync. Several methods to keep a system synchronized are listed in the System 800xA Automation Network User's Guide.
System 800xA on domain setup (i.e. not workgroup) need continuous connection with a domain controller. To decrease the risk of an outage due to lack of a valid domain controller, ABB recommend configuring at least two domain controllers. Domain controllers are also a check item in System Health Check. Periodic checks are very recommended. Without a domain controller, System 800xA may cease to work as it can no longer properly authenticate users.
System 800xA uses authenticated Microsoft Windows sockets to ensure authenticated communication between servers and clients. A time sync problem often manifest itself as unable to authenticate. Hence, potentially, Basic History in CS2 could not communicate with CS1.
Some extracts from the System Event List from the time of problem could shed some light on what went wrong.
Also, running a historian out of clock sync is not recommended.
Add new comment