We’ve recently had a few technical support calls querying how to diagnose High Availability issues. To make things easier, with identifying the health of all Passwordstate Servers, we included the health status under the Authorized Web Servers screen in Passwordstate 9.0 Build 9000. This uses a traffic light approach of “green is good”, “red needs investigation”.
So, if your HA server shows a status of red what do you do next?
Recap on HA Implementations
To start with let’s recap on Passwordstate’s High Availability offerings. The following logical diagram shows 2 variations of Passwordstate with High Availability. The solution, as depicted by the Green Dot 1, is an Active / Passive implementation. This allows the Passwordstate High Availability instance to be enabled, and will provide read only access to requests in the event of an issue with the Passwordstate Primary Instance. All access events are audited and synced with the Passwordstate Primary Instance once recovered.
The solution, as depicted by the Blue Dot 2,shows an Active / Active implementation. This requires a Load Balancer redirecting the End User’s Passwordstate traffic to either the Passwordstate Primary Instance or the Passwordstate Secondary Instance. This offering allows users to update data in both the Primary and Secondary instances of Passwordstate. It requires Basic Availability Groups, or Always On Availability Groups to be implemented in Microsoft SQL Server Standard and above.
Your High Availability Server along with your Primary Server will show up on the Authorized Web Servers page. This page is available at Administration->Authorized Web Servers and details the Polling Health, Last Poll Time, Server Role and HA Mode along with the Install Path. Our test environment is shown in the screenshot below;
Note the Host Names must be entered in their NETBIOS name format not FQDN (Fully Qualified Domain Name).
High Availability: Active-Passive Implementation
When running your Passwordstate High Availability model in Active / Passive mode your HA Server will initiate the polling. It does this through the Passwordstate Windows Service attempting to contact the Primary instance’s API. When it successfully connects to the API it will complete the poll and your Primary instance will record the Polling Health status as green for your HA Server.
If your Polling Health status isn’t showing as “green is good” you’ll need to investigate the cause. The first thing you can check is if the API is functional. To do this try creating a password using the password generator icon in the top right-hand side of your Passwordstate User Interface;
When clicking on the password generator a password should be generated in the dialog box as shown above. If this works successfully then the API is functioning correctly.
You can also check if the connection to your API is functioning correctly by opening a web browser and typing in the URL for your Passwordstate instance with the following appended to the URL /api/highavailability/primarypoll/polltest. If the connection is successful, you’ll see the following result;
If the connection fails, in this example because the Application Pool wasn’t running, you’ll see an error message like;
It does this via a GET request to the specified Uri (URL) as an asynchronous operation. For more information on the GET request please see https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.getasync?view=net-5.0 .
Connection issues are always caused by issues with an incorrectly configured Load Balancer, Reverse Proxy or Firewall issues between the two Passwordstate instances. You can also check the Authorized Webserver Host Names are the Netbios names and not the FQDN.
High Availability: Active-Active Implementation
When running your Passwordstate High Availability model in Active / Active mode your High Availability Server (secondary instance) writes its Polling Health status directly into the Passwordstate Database. As with Active / Passive implementations this will then show the Polling Health status as green for your HA Server.
Again, the biggest issue we find with a Passwordstate instance not correctly participating in an Active / Active HA implementation is incorrectly configured Firewalls or your Passwordstate Windows Service isn’t started. Again, check the Authorized Webserver Host Names are the Netbios names and not the FQDN.
Knowing where to look when you experience HA Polling Issues is straightforward. Unfortunately Click Studios can’t tell you how to resolve your Load Balancer, Reverse Proxy or Firewall issues as the number of suppliers for these is huge and growing. You will need to log a call with the vendor responsible for the equipment if you are unable to identify and resolve the issue.
Got feedback? We’d love to hear it! Send it through to support@clickstudios.com.au.