Solved

Always on high availability group

  • 29 April 2019
  • 3 replies
  • 56 views

Badge +4

Hi, 

We have a client which has put the K2 on a Database with Always on high availibilty groups across 2 servers using active passive infrastructure.For the sake of simplicity, lets call these SQL1 and SQL2.

Our primary node is always SQL1. This acts as the “Live replica” and all read-write operations are done on it. SQL2 is just on standby and replicating with SQL1 in real-time. In case something happens to SQL1, a failover is automatically triggered and SQL2 now becomes the primary replica. Once the issue with SQL1 is fixed, we usually fail over manually back to SQL1, bringing SQL2 back as a secondary replica.

 

Is this recommended by K2? Will this cause any issues?  

icon

Best answer by Dumisani 30 April 2019, 09:19

View original

3 replies

Hi  @JPG079;

 

Please check out with the following links and its content regarding your scenario:-

https://community.k2.com/t5/K2-blackpearl-Articles/K2-High-Availability/ta-p/93296

 

Additional-:

Also read  through the attached doc.

 

Should you find the above information useful kindly mark as "Kudo and/or Accepted Solution".

 

Kind regards;

Widson.

Good day ,  

@JPG079

 

Depending on the environment that you are on please read the following scenarios but these are based on K2  black pearl and they might apply to your question.

 

  1. Parallel Server in Same Environment 
    https://help.k2.com/onlinehelp/k2five/icg/5.1/default.htm#Plan/BCP-DisasterStandby.htm 
    The "parallel server in same environment" scenario would involve installing and adding another K2 server node into you current K2 farm with a "StandBy" license. Although this server will be a part of your farm, it will need to be turned off and not load balanced in this farm setup. Should anything happen to your main K2 server(s) and it cannot process requests, you can turn on this Standby server and send traffic to it via the load balancer/DNS record. 

    Regular operation: 
    SQL AlwaysOn <---> K2 Farm (ServerA (Online) + ServerB Standby (Offline)) 

    DR scenario: 
    SQL AlwaysOn <---> K2 Farm (ServerA (Offline due to disaster) + ServerB (Online)) 
    * update load balancer/DNS to Standby server instead 

    2. Parallel Standby Environment 
    https://help.k2.com/onlinehelp/k2five/icg/5.1/default.htm#Plan/BCP-DisasterRestorEnv.htm 
    The "parallel standby environment" in this case is more applicable if your whole SQL AlwaysOn Availability Group is down and if there is a separate SQL server instance/SQL AlwaysOn Availability group. In this scenario, a separate network-segmented DR server/farm is installed elsewhere and the [Server.Server] and [HostServer.LicenseKey] for this installation is stored in record. During this DR event, the K2 database backup from your live farm is restored onto this separate SQL Server instance/SQL AlwaysOn Availability group and the [Server.Server] and [HostServer.LicenseKey] is updated in this separate SQL server/AlwaysOn availability group to work with your DR K2 server/farm. 

    Regular operation: 
    SQL AlwaysOn <---> K2 Farm (ServerA (Online)) 
    Separate SQL Server instance/AlwaysOn group <---> separate network-segmented K2 DR Farm/Server (Offline) 

    DR scenario: 
    SQL AlwaysOn (Offline) <---> K2 Farm (ServerA (Offline)) 
    Separate SQL Server instance/AlwaysOn group <---> separate network-segmented K2 DR Farm/Server (Online) 
    * when restoring the K2 database backup from your live SQL AlwaysOn to this separate SQL Server instance/separate SQL AlwaysOn, it will not have the [Server.Server] and [HostServer.LicenseKey] entries for your separate network-segmented K2 DR Farm/Server, and as such need to be restored as per the documentation 

    Once the K2 Server service of the DR K2 Server is running, any upcoming escalations and/or scheduled workflows will get processed by the DR K2 Server. There may be issues if there is the usage of IPC/sub-workflow events; such that it is still referencing the original K2 Server hostname instead of the DR K2 Server hostname. This can be resolved by adding a temporary 'hosts' file entry that points the original K2 Server hostname to the loopback address (127.0.0.1) and retrying any IPC/sub-workflow event in error. 

    Kindly feel free to mark as “Accepted solution, kudo and/me too” if you find this information answered your question or leads to your answer.

    Thank you and kind regards,

    Dumisani

    K2 will not accept any liability for any issues arising from actions taken in respect of the information provided by any forum member.

I-46 is greatness

Reply