Accpac 6 Online
As we move to finish and release Sage ERP Accpac 6.1A, we are also working to host the Web Version of Accpac at AccpacOnline.com. I talked a bit about AccpacOnline and how it hosts Accpac currently as well as some of our plans here, this article looks a little deeper into how we will be deploying the Web version of Accpac Online, how we will be scaling it and how we will manage reliability. Of course as we develop this out, there will likely be some changes from what I am describing here.
The goal is to have an economically profitable hosted solution that can scale with our anticipated growth. Although it would be nice to assume we will be as successful as Facebook and quickly have 750,000,000 users, realistically we won’t and engineering a solution for 750,000,000 users doesn’t make sense. Like most companies you want to engineer your solution for the number of users you anticipate over the next few years and then as that materializes, you engineer for the next step.
Our initial goal is fairly conservative, and that is to host as many users on a web server as we currently host on a Citrix server. The Web server has a number of advantages over the Citrix server; namely it doesn’t run the UIs, so we save all the memory and processing by not having all those VB programs running, there is just the View portion then further the Web Server runs fewer processes and instead individual sessions are threads within a process, so this further saves resources.
Then we have the ability to scale out as many web servers as we need to accommodate our user load. As we move forward then we will work to increase the number of users that run efficiently on each server to make our solution better economically trying to scale to more users per server faster than we need to add servers.
To compare to how we deploy for on-premise installations, have a look at this article.
Below is a high level block diagram of how we will be running. This just shows the main components. I’m not covering everything, for instance this doesn’t show firewalls or other security layers that are present.
Hardware Load Balancer
At the left is a hardware load balancer. Its first job is handle encryption. All external requests come in using SSL. It is the job of this piece of hardware to decrypt all incoming communications and encrypt all outgoing communication. This offloads this onerous function from the actual Web Servers. Then its second job is to distribute incoming connections between however many Web Servers we happen to be running. Due to the way Accpac works we require that once a new connection is sent to one particular Web Server then all subsequent requests for that connection go to the same server, this is called operating with sticky sessions.
From the load balancer un-encrypted requests are routed to one of the IIS’s. If the request is for static content like bitmap images or HTML files then IIS just provides these. If the request is an SData request then it is passed onto Jakarta.
Jakarta is the connector which connects IIS to Tomcat. Besides connecting IIS to Tomcat, this connector has a number of very important jobs in a hosted environment. In our hosted environment we run a number of Tomcat server processes; each one running as a Windows service. Jakarta then acts as a software load balancer distributing requests across the Tomcat processes using sticky sessions again.
So why do we want to run multiple Tomcat processes and why do we want to operate a software load balancer on each server in addition to the main hardware one? The two big reasons are reliability and memory usage.
Accpac is still a 32-Bit Windows application. It runs fine on 64-Bit versions of Windows, but a 32-Bit process can only address 2Gig of RAM. As a consequence each Tomcat process can only allocate up to 2Gig of RAM and this is shared by all the threads running inside that Tomcat process. It’s easy and cheap now to get servers with far more RAM than this. So the way to utilize that RAM is to run multiple Tomcat processes each of which can utilize up to 2Gig of RAM.
The second issue is reliability. Of course we write our software to never crash and to never leak resources or do anything else harmful or bad. But the reality is that bugs happen and they have to be accounted for. If your Order Entry screen crashes, it only affects you and usually you just re-run the screen or at worst re-boot your computer. In a Web environment, something crashing on the server affects all the users on that server and re-booting a server is considered a very long time for a service to be down. Newer versions of Windows Server have gotten very good at isolating problems to an individual process, so when that process crashes, Windows can recover all its resources and happily continue working. So if a thread inside Tomcat (representing one user) crashes then the Tomcat process will crash and all the users using that Tomcat will be affected. Jakarta monitors this and if a Tomcat process crashes it will restart it. It also notes when a Tomcat process isn’t responding and will stop directing new requests to that Tomcat. Additionally you can configure Jakarta to stop using a Tomcat after some period of time (usually some number of days) and then when everyone is logged off it, restart it to recover any leaked resources. Generally the overall health and availability of the Web Server is being monitored and controlled by Jakarta. Of course we do extensive testing so these sort of events are infrequent, but they still need to be handled and recovered from.
Tomcat is a Java application server that runs our Java program that interprets SData requests. Then this Java application will call into the Accpac Business Logic (Views) to do the actual processing. Tomcat runs as a multi-threaded program in which each new request is handled from a pool of worker threads which do their job and then return to the pool. All the classic Accpac Business Logic then runs in the context of this program. As far as Tomcat can tell at this point, it is running as if it was on-premise and it doesn’t know about the other entire infrastructure that is going on around it.
Then off to the right of the diagram we have our pool of SQL Servers. Basically an individual customer’s company will exist on one specific one of these. Basically we manage these in exactly the same way we do for the current Accpac Online. In fact for a given customer, some users could be accessing the SQL Server through all the items in this blog and other users could be accessing it via Citrix and our current VB screens. All co-existing and sharing nicely.
This blog is just meant to give an idea of how we are setting up AccpacOnline.com for running the web version of Sage ERP Accpac, hopefully you found it interesting.