Retaining connectivity post failover

[Richard_Evans1]

Hi All!

Our installation of OnBase is very sensitive to network issues (v.18).   All of our other applications, with the exception of voice and video traffic, do  not appear to suffer the same issues. Our network is built with redundancy in place. If a network device fails, traffic is routed to a working device automatically. All of our applications with the exception of OnBase seem to survive these brief outages (typically just seconds).  Over the years, we have come to believe that it is related to the connection to the SQL database.  OnBase is our only application that does not survive a quick cluster failover. Nor do its VMs survive a host migration.    We have always wondered if the application's tolerance to a loss of connectivity to SQL are configurable. Maybe some type of "keep alive" setting.   

Is there anything in OnBase that can be configured to prevent the web, application, and timer servers from failing due to a brief loss of connectivity?

I really appreciate the help. 

Makarios

[Ryan_Wakefield]

I also would love to hear more about this because I know whenever we do a failover, especially with our DB cluster, we get the same thing and a lot of our Windows Services are hung. So hopefully someone from Hyland will respond and give some details to this.

[Ryan_Wakefield]

I feel like @Adam Shane would be a good resource to help with this one. Tagging if he can assist.

[AdamShaneHyland]

Hi Markarios.

My first recommendation is to review the High Availability Options section of the Database Reference Guide (Note, post OnBase 17 the Database Reference Guide is released with software and updated accordingly).   There are many referenced articles within the documentation related to configuring different high available technologies.

You noted that you are using Failover Clustering with MS SQL.   Are you using any other technologies like Always-On Groups?  Further, I would not expect OnBase to work the same as every other application without knowing how those other applications work (manage database connections, database transactions, etc.).  It could be that OnBase is the only application within your organization which manages database connections the way it does causing it to work a bit differently than others.  

Technically, the failover should be automatic and transparent to OnBase, but it is typically no so simple.   There are many different levels of architecture and technology at play here.  Further investigation would be necessary to determine what is failing and if/how given the technologies available at your organization an automatic failover is possible.

My recommendation would be to open an issue with Technical Support for further investigation.  

Take care.

[Ashish_Srivasta]

@Adam Shane

You mentioned AlwaysON. How does "AlwaysON"  makes a difference?

We are thinking of using it where SQL database environment is transactional and the transactions are sent to both the PROD and DR Databases. It’s almost real time.

Also before creating our DR environment, we were also wondering if any of the host names of any server is stored in DB or not? If not, we can clone the Prod DB and just need to install some software components against Cloned Prod database (say DR database) but if host names are stored, we cannot do this otherwise it will be overwritten, when we will again enable the mirror link between Prod and DR. Any insights by Adam/Ryan or anyone who has setup DR will be helpful.

Thanks!