I need a solution architecture guide or design for Laserfiche deployment on AWS as IAAS.
Hi Mohammed,
Here's a general diagram I use as a guideline. Your actual number of servers and how you split up Laserfiche components among them will depend on the system's size, user count, and use case.
For example, if your solution doesn't use Quick Fields Agent or Import Agent, you don't need the "Capture Server". If your solution is especially Forms-heavy, you may want a dedicated Forms Server. Etc.
Hi Mohammed,
Can you make your request any more specific? Deploying Laserfiche on AWS IaaS is similar to deploying it on-prem. You still have Windows Server VMs, file storage, and SQL Server databases.
Generally speaking, you'll have the following:
Thanks for your reply, I think this information is good enough, however, I do not have an experience in such implementation, do you have any diagram sample that shows how to place all mentioned component in one architecture diagram?
Hi Mohammed,
Here's a general diagram I use as a guideline. Your actual number of servers and how you split up Laserfiche components among them will depend on the system's size, user count, and use case.
For example, if your solution doesn't use Quick Fields Agent or Import Agent, you don't need the "Capture Server". If your solution is especially Forms-heavy, you may want a dedicated Forms Server. Etc.
Dear Samuel,
What about load balancing for Laserfiche web applications (forms, web, weblink), do we have to use AWS application or network balancing and why?
NLBs have a much simpler form of sticky sessions (source IP affinity) than ALBs, which are cookie-based.
You should go with ALBs. That also allows you to use path-based routing to have one hostname for those Laserfiche web applications (e.g. lf.company.com). In addition to being simpler for end users, it can help avoid CORS issues in your solution.
NLBs do not support path-based routing, so you need an NLB per backend server with separate application roles. For example, if you have two Forms servers and two Web Client servers, you'll need two different endpoints (e.g. docs.company.com, forms.company.com), each of which requires a separate NLB.
ALBs also allow you to use Web Application Firewall (WAF), an incredibly useful security tool for anything public-facing.
Important Note: Integrated Windows Authentication (IWA, the "Windows Authentication" button) does not work correctly through an ALB (layer 7, HTTP) as it is a layer 4 TCP-level protocol. Doing so presents a security risk as users' authentication tokens can get crossed. It is important to ensure that LFDSSTS login pages are either behind an NLB (layer 4, TCP) or not behind load balancer at all.
I know this is a bit of an older post but I wanted to get clarification. If we want to have multiple WebLink or WebClient servers that would've used NLB if they were physical, we would instead use ALB's to accomplish the same goals?
There's an important caveat to what I wrote above five years ago.
An AWS Network Load Balancer (NLB) is the direct functional equivalent of a Windows NLB - they are both Layer 4 TCP load balancers.
If end users are using any of the Laserfiche desktop client components (Scanning, Office Integration, Snapshot, Webtools Agent) you MUST use an NLB with NLB target group sticky sessions enabled. See: Edit target group attributes for your Network Load Balancer - Elastic Load Balancing. While AWS doesn't state it explicit, this NLB type of sticky sessions uses the client IP address for stickiness. Client IPs do not change based on the client application (i.e., the same for a user's web client browser session and Laserfiche Scanning, etc.).
AWS Application Load Balancers (ALBs) are Layer 7/HTTP and only support cookie-based sticky session. See: Edit target group attributes for your Application Load Balancer - Elastic Load Balancing.
Laserfiche desktop client applications that connect to the Repository Web Client use an embedded Edge WebView2 browser that does not share a cookie store with any other browser. Webtools Agent manages auth tokens for them via a special non-browser mechanism. Any existing ALB's session affinity cookies aren't accessible to them, so the ALB treats them as new connections and assign them to a target group according to whatever the load balancing algorithm is, typically round-robin, making it a coin flip or 1dX dice roll on whether the client app connects to the same web client server as your browser. If the client app connection is sent to a different server, it fails at the application layer because none of the assumed/required session state is present.
This is only a consideration if you're actually load balancing among multiple backend targets. If you're using an ALB as a pure reverse proxy to a single backend server, you don't need the LB to handle session affinity because there's only one valid destination server for any request.
In summary:
Wow, you are awesome! Thanks a ton for that in-depth info. We are setting this up for WebLink first but the WebClient isn't far behind so I love knowing both options. I appreciate the follow-up on an old post, providing us this updated knowledge.