-
Title
Does Foglight support MS SQL Server Always ON Cluster, using Availability Group and multiSubnet failover, as Database repository -
Description
Does Foglight support MS SQL Server Always ON Cluster, with Availability Group and multiSubnet failover, as Database repository? -
Resolution
Enhancement FGLCM-366 has been logged to Improve database connection validation in foglight db connection pool.
Additional Information:
Support for MS SQL Server AlwaysON cluster using Availability Group as Database Repository was added starting with FMS version 5.9.3. In this scenario during FMS installation process, name of the Availability group listener is used as database.host
For multiSubnetfailover feature, some additional configuration parameters need to be added, as necessary.
Note: Please make sure the parameters are added on every FMS (in case of HA or Federated environment) and it is restarted any time a chnage is made in any of the configuration files referenced below.
1. Add below parameter to <FMS_home>/config/datasource/datasource-sqlsvr.properties file:
#Enable multisubnet failoverMultiSubnetFailover=True2. If Availability Groups listener has multiple IPs (due to multisubnet) then add bellow parameter to <FMS_home>/config/server.config file to clear jvm cache when fail-over occurs. Here 60 means to clear the cache in 60 seconds.server.vm.optionx = "-Dsun.net.inetaddr.ttl=60"; (x is the next available number)3. In some cases it is necessary to validate the connection to the database first and for that additional parameter needs to be added to Item#1 above.testOnBorrow=true4. Instead Item#3 above, below parameter can be added to Item#1 for better performance.numTestsPerEvictionRun=10Additional Information:Based on performance consideration, there are some idle JDBC connections kept in the connection pool. When failover occurs, those idle connections still keep the old setting. In this case, old IP address becomes unreachable but those idle connections still try to connect to the old IP, then error reported.The testOnBorrow parameter is to validate the connection first. If it's invalid, then drop it from the pool and create a new connection(with new IP then). When those old idle connections are all dropped, then DB connections become normal.
Errors would be reported if any JDBC operations performed during that time period. Depending on the current operations, these errors will be captured in FMS log.
In case of FMS HA setup, the secondary FMS may take long time to startup because it keeps some idle connection as well but does not have that frequent DB operations as primary, hence it may take more time to validate and drop the old idle connection
-
Defect ID
FGLCM-366