Redundant Combined Aspect & Connectivity Server Data Delay
My system consist of 2 Domain Servers 2 Combined Aspect & Connectivity Servers & 6 Clients
when the system is up, all the services are ok except the Engineering base service for the Secondary Server , its Status is Undefined
when i try to switch off the Primary Combined Aspect & Connectivity Server the Secondary server works as master , but a problem appears in the Clients
the problem is when you try to call a faceplate it tooks too long time to open
when you switch on again the primary server, the system becomes normal.
can any one help ??
Voted best answer
Which 800xA system version are you using? I assume 5.0 or earlier since Engineering Base service was removed in 5.1.
Prior version 5.1 the Microsoft Windows domain DNS function must be properly configured, i.e. having:
- one forward lookup zone (with A-records for each node's primary network interface)
- one reverse lookup zone per client/server network path, i.e. TWO if redundant network is used. Each reverse zone shall be populated with a PTR record for each node
- redundant DNSs (DCs) must be synchronized (this is normally done via Active Directory)
- DNS must be installed/activated in DC2 since only DC1 get DNS role by default.
- Each 800xA server and client must have correct primary and secondary DNS settings on their NICs
- NIC bind order is important in all nodes. Client/Server networks must be listed first.
The required network configuration is thoroughly described in the Automation System Network Guide. Please read relevant chapters and verify your setup.
The Engineering Base service in AS2 is probably not involved but should be corrected for true redundancy of all services.
If you can't get this to work on your own, please contact your regional ABB support center for assistance.
Furthermore, the support center shall have access to troubleshooting documents regarding the Engineering Base service; there are a number of repair/resync actions that can be attempted by a person with adequate skills/training.
Thanks for your answer
just i want to clarify some points
- the System Version is 5.0.2 RevC
- when the primary server is switched off , calling faceplates on the secondary server is normal, the problem exist in the clients (The Slow response) So it can not be a Network Problem ?
I'm not primarily targeting the physical network at your site (but I can not rule it out of the picture either), however I was more aiming at "soft" settings in the configuration that can play a part
The following items are known to cause trouble between 800xA servers and clients:
- Incorrect settings in DNS server
- Incorrect content in DNS server
- Incorrect settings in DNS client (NIC Bind Order and/or Primary & Alternate DNS fields on each NIC)
- Incorrect System Network Settings in 800xA Config Wizard
- Incorrect content in "hosts" file (which only need to have 'localhost' in pre SV 5.1 system)
- Incorrect speed & duplex setting (resulting in low bandwidth, packet loss, etc.)
There is no simple answer to your last question (what to test) and I feel that writing the whole essay of how to find the settings that need to be checked would not fit on this discussion thread.
I did attempt to be as descriptive as possible in my previous answers, e.g. what to expect and where - but I fear that explaining what need to be done in very high detail would take up too much space to fit here.
The Automation System Network Guide (search for the lastest one released before the 5.1 version when DNS became much less important) should have some details and pictures - please check it. I know for sure the primary/alternate DNS settings required on each NIC is nicely described with pictures, etc. that should be easy to follow.
For the remaining part (what to expect in each zone of the DNS server, etc.) please try to follow my previous advices.
The 'nslookup.exe' command in Windows is a key tool for probing the DNS and to query for the expected A and PTR records. E.g. all questions below should be returned immediately with correct data and no timeout - this command may have to be repeated on each node, and also, more than "AS1" need to be queried (I use DC1, DC2 and AS1 here and its AS1's fictive addresses of 172.16.4.11 and 172.17.4.11, but you should check that ALL nodes can be queried)
[check AS1's A record in DC1 DNS]
C:\> nslookup as1 dc1
[check AS1's A record in DC2 DNS]
C:\> nslookup as1 dc2
[check AS1's primary network's PTR record in DC1 DNS]
C:\> nslookup 172.16.4.11 dc1
[check AS1's primary network's PTR record in DC2 DNS]
C:\> nslookup 172.16.4.11 dc2
[check AS1's secondary network's PTR record in DC1 DNS]
C:\> nslookup 172.17.4.11 dc1
[check AS1's secondary network's PTR record in DC2 DNS]
C:\> nslookup 172.17.4.11 dc2
In no case, timeout or incorrect data should be returned.
A standalone DNS should have a root zone (.) in its forward zone list. Also, standalone DCs seem to enjoy (read require) their own PTR records to exist in DNS, i.e. 172.16.4.1, 172.17.4.1, 172.16.4.2 and 172.17.4.2 should exist as PTR records (DC1 is node 172.16.4.1 and DC2 is node 172.16.4.2 in my example above)
If it is too complex, please don't hesitate to contact your regional ABB support center to get additional help with figuring out what is wrong in the system.