You are viewing limited content. For full access, please sign in.

Question

Question

Domain-based Licensing : Multiple Domains

asked on September 25

Our client is planning to establish a Disaster Recovery (DR) environment and requires a configuration that ensures an immediate cutover to the DR site whenever the primary site goes down. The expectation is for Laserfiche to remain continuously available without any noticeable disruption to end users.

A key requirement is that the client does not want to go through the process of deactivating and reactivating licenses during failover. Instead, they expect a seamless experience where users remain unaffected by the switch.

The proposed DR site will be a replica of the production environment, including:

  • A Laserfiche Application Server

  • A Web Server (hosting Forms and LFDS)

  • A Workflow Server

With the existing licensing model, failover introduces complications:

  • The Hardware Fingerprint (HWFP) will change once the system switches to the DR site.

  • This change causes the LFDS site to be locked, since there would effectively be two active sites at the same time.

  • Allow for multiple domains to be included in the license (as the client currently has two identity providers configured in LFDS). - An application for this update has already been submitted to Laserfiche.

 

Based on the above and referring to LF documentation, the plan is to

  1. Renew the primary license by updating the existing license to domain-based licensing.

  2. Re-register all applications (Forms, Workflow, LFDS, etc.) using the updated domain-based license.

  3. Validate that the DR site functions as expected under the new licensing model

Could you please let me know if there are any additional considerations we should be aware of before proceeding with the switch? Also, would there be any potential issues in reverting back to an HWFP-based licensing model if required? Ideally, what would the rollback plan look like?

Thank you in advance for your guidance.

0 0

Replies

replied on September 26

Hi Bipin,

 

Just checking, have you read these whitepapers attached? Some useful information in there which may answer your queries. 

 

Reversing a domain locked licensed back to a HWFP model isn't something I've ever encountered before, as you can add any number of new domains to support the LF system going forward.

 

Cheers!

Chris

2 0
replied on September 26

Yeah, the license domain lock is a list of allowed AD domains for applications to run on. By default, when you request "example.com" you get both:

  • example.com
  • *.example.com, which covers all first-level subdomains (e.g., eu.example.com) 

If you also have an "example.org" domain, you just submit a separate request for that. 

Requesting a domain license has no impact on your ability to use HWFP-based licenses for individual applications, which are always available as an option. It adds the domain-locked license as the new default option but does not remove the HWFP ones. There's really no reason you'd ever "roll back", but if you needed to, you'd simply go edit each application license in Directory Server, switch the type from Domain-locked to HWFP, save, and re-issue/replace any existing ones.

Domain licensing is the least of your concerns with this setup though. 

Seamless failover of a self-hosted Laserfiche system to a separate DR site with zero disruption to end users is generally unrealistic. If there's no requirement for any data replication between the systems whatsoever (repository data, Forms/Workflow process state, users in LFDS, etc. etc.) and all you're doing is redirecting traffic to "lf.example.com" from the primary site to the DR site with a cross-site load balancer, you can get close, but that's not usually the scenario.

The best and lowest complexity approach is typically to use a "continuous replication" Business Continuity/Disaster Recovery (BCDR) solution that continuously replicates all VMs in the solution to the DR site with <30s of replication lag and can bring up the VMs at the DR site within a few minutes, once failover is triggered. If this option is available, use it. 

The next best and much higher complexity approach involves cross-site ("stretch") failover clustering of key Laserfiche components like Directory Server and Repository Server, along with (near-)synchronous storage replication and asynchronous SQL Server Availability Group replication for application databases (which require manually triggered failover due to risk of data loss). Note that you cannot failover cluster all Laserfiche components. If you and/or the customer don't have significant experience with most/all the elements and pre-req infrastructure technologies of that setup, don't do it. You won't be able to effectively support the solution, everything is significantly more complex, and the risks of subtle data loss and volume/database desync issues are real.

If the business use case truly does not need any data replication between Production and DR, you can go with the "hot separate DR system" setup. An example of such a use case would be "Users submit a starting Form with an attachment that triggers a Workflow that sends the file to an ERP system with an HTTP Web Request activity API call", where the process is a single step for the user, is not long-running, and has no dependencies on any other system state for the repository or other Forms or Workflow processes.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.