Scaling and Availability for the new Sage 300 Web UIs
I introduced our new Sage 300 Web UIs, talked about installing them and then discussed security implications. Now the question is that you have hundreds of users and things are starting to run quite slowly, what do you do? Similarly suppose you are all happily using the Web UIs and the web server hardware breaks down or Windows Update kicks in or Windows fails for some other reason? These two problems are quite related since the solution to both is the same, namely adding another Web Server. If you have two Web Servers and one breaks down, then people might run a bit slower since they are all on the remaining server, but at least they keep running. If the Web UIs slow down when there are a certain number of users, then add another web server to distribute the load.
This articles will look at the various issues around adding Web Servers. For the other parts of the system I talked about various techniques here.
Poor Man’s Scaling
Later in the article we’ll talk about automatic failover and automatic ways to distribute load. In this section I just wanted to point out that you can do this manually without requiring any extra configuration, servers or hardware.
Basically just have two Web Servers, each with its own URL (which might just be //servername/sage300) and then just assign which server your users sign on to. You would want each server to have the Sage 300 programs installed locally, but use the same shared data folder and the same databases on the same database server.
Then if one server fails, just send an email to everyone using that server to use the other one. This way it’s pretty easy to add servers, but it’s up to you to distribute your users over the servers and it’s up to you to switch the users from one server to another when one goes down or you want to do maintenance.
Sticky Load Balancer
Ideally we would like to have a pool of Web Servers that are all behind the same URL. Then as users access the URL they will be distributed among the working servers in the pool. If a server fails, this will be automatically detected and it will be removed from the pool.
There are quite a few hardware load balancers on the market, most of which have the “sticky” feature that we require. Sticky means that once a user starts talking to one server, all their traffic will be directed to that same server, unless it fails. For the Sage 300 Web UIs most of the UIs are what are called stateless and don’t require this feature. However we do have a number of stateful UIs that must communicate with the same server to do things like build up an Invoice or other accounting document.
Most load balancers will detect when a server fails (usually by regularly pinging it) and hence remove it from the pool.
Many load balancers also have the feature of decoding HTTPS for you. So you have an HTTPS connection to the load balancer and then an HTTP connection from the load balancer to the Web Server. This improves performance of the Web Server since decoding HTTPS traffic can be quite computationally intensive.
If you are thinking “high availability”, you might want to now ask: what happens if the load balancer fails? In this case you would have two load balancers in an active/passive configuration where the passive will take over if it detects the active one has failed.
You also wouldn’t want all your servers to automatically do Windows Update, otherwise they will all do this at the same time and the whole system will be unavailable during this process. It’s a good idea to take control of when Windows Update happens and to stagger it across your infrastructure.
There are a number of software solutions for load balancing. After all a hardware load balancer is just really a computer with the exact hardware ports required and then runs the load balancer software. One software solution is built into IIS called Application Request Routing (ARR). Here you can have a server in front of your Web server which has ARR configured to know about your pool of servers, have sticky session enabled and off you go.
If you want to make the ARR server HA (Highly Available) you can add a second one. If you have them work in parallel then they need to share a SQL database that you might want to also make HA.
You might want to be highly available across geographic locations. However keep in mind that there is only one SQL database and the location where that is located will work really well, and the other location will probably have terrible performance. Generally for disaster recovery if something catastrophic happens to one location, you would have a second location that you can bring online reasonably quickly and probably involve restoring the SQL Server database from an off-site backup.
Rather than managing all these servers in your own datacenter, you might consider running them all as virtual servers in a Cloud such as AWS or Azure. Here you can create all these servers and configurations fairly easily. You can also add web servers when you need extra capacity and delete a few when you aren’t using them and want to save a bit of money.
There are lots of arguments between running in the cloud versus running in your own data center. These often revolve around data security, data privacy, cost, and the skills needed to maintain the given system. Whichever is right for you, you will still want to make sure you can configure the correct capacity for your needs and that you have the correct level of disaster recovery, failover and backup for your needs.
This was just a quick introduction to how you increase capacity of your Sage 300 Web Servers, along with a quick discussion of High Availability. As in all things, the most deluxe solution will be very expensive and no solution will likely be unacceptable. So you will need to find the correct balance for your business.