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.