WARNING: Lots of theory and hypotheticals below. Definitely requires experimentation.
You may or may know this, but MapGuide does have a built-in load balancer. Unfortunately, it is not very well documented nor has it been extensively battle-tested so it is understandable if you never knew such a feature exists. If you want to try using MapGuide's load balancer, you need to have webconfig.ini point to the IP addresses of the participating MapGuide Server nodes. You can refer to this RFC for the configuration details ( https://trac.osgeo.org/mapguide/wiki/MapGuideRfc3) This should give you an architecture that resembles this crude ASCII diagram below: +-----------+ +-----------+ | mapagent +--+--->| mgserver1 | +-----------+ | +-----------+ | | +-----------+ +--->| mgserver2 | | +-----------+ | | +-----------+ +--->| mgserver3 | +-----------+ The key takeaway here is that the mapagent and mgserver do not have to reside physically on the same machine. These tiers can reside on separate machines. So in a cloud context, the mapagent would be public-facing while the mgserver nodes would be provisioned within the mapagent's VPC. The weakness of this architecture besides the untested nature of the MG load balancer is that your mapagent is a single point of failure. I'm sure there could be ways to address this at an architectural level, but nothing comes to mind at the moment. Here's another possible alterative architecture, but requires taking this into consideration: Can your MapGuide application get away with *not* using sessions? What you lose from not using sessions: - Session repository access - Temporary layers and operations that create or operate on such layers (eg. Buffer, Dynamic Theming) - QUERYMAPFEATURES for mouse-driven selections. With 4.0, we have APIs in place so you should be able to implement a stateless version of this API if needed. What you gain from not using sessions: - Zero server memory overhead and burden from having to maintain and cleanup active sessions - Substantially simpler horizontal scaling. You can go with a hypothetical load-balanced architecture that resembles something like this crude ASCII diagram below +-----------------------+ +-----------+ +-----------+ | nginx / load balancer +----+---->| mapagent1 +------>| mgserver1 | +-----------------------+ | +-----------+ +-----------+ | | +-----------+ +-----------+ +---->| mapagent2 +------>| mgserver2 | | +-----------+ +-----------+ | | +-----------+ +-----------+ +---->| mapagent3 +------>| mgserver3 | +-----------+ +-----------+ As long as mgserver1/2/3/n are provisioned with the same data, you should be able to hit your mapagent at the [nginx/load-balancer] node and it should be able to distribute the requests across. This kind of architecture assumes your data/repository is effectively read-only as you can't author/create resources in a load-balanced manner. You will have to author this repository in a separate single-node MG installation and apply it to mgserver1/2/3 though the MapGuide package mechanism. If you're thinking about cloud, you should also think about the "pets vs cattle" dichotomy. In this case, you should think of the mapagent + mgserver pair as "cattle", something that is expendable, it can be easily spun up and easily killed to be replaced with another spun up instance if it is misbehaving. By making your data/repository read-only, you can simplify spinning up a mapagent/mgserver pair with the following provisioning process. 1. "Install" MapGuide server and webtiers via the InstantSetup package 2. Use the included MgInstantSetup utility to set up paths and port numbers 3. Assuming you're using the 4.0 previews: 1. Load in your packages from the command-line with mgserver (eg. mgserver.exe loadpackage path/to/package/file.mgp) 2. Optionally change the password for Administrator and other user accounts from the command-line also with mgserver 4. Start the mgserver Now if you're not constrained by Windows / .net and can use Linux then you can explore the big-league stuff with docker containers and orchestrating it all through something like Kubernetes. That's another major topic on its own, so it may not be something you want to pursue. Hope this helps give you some more ideas. - Jackie You wrote: Hi, I have been thinking what is the best architectural solution to implement an ASP.Net/mapguide scalable solution at AWS Cloud. Today I have a windows server EC2 instance running the web server and mapguide. To be able to use EC2 autoscaling, I have to deal with user sessions outside the web server, maybe a ElastiCache as an ASP.NET Session Store. But I also have to deal with mapguide sessions outside EC2, maybe put them in Amazon Elastic File System ? I want to explore other options of architecture and open this discussion. How you guys are using mapguide in a cloud enviroment ? Liglio Cavalcante -- *Please Note: I no longer create new posts or post replies to any OSGeo mailing list through nabble. As a result, you most likely won't see this message appear on nabble's view of any OSGeo mailing list and may only see this message through mailing list archives or depending on your mailing list subscription settings, through daily message digests or automated notifications from the mailing lists.*
_______________________________________________ mapguide-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/mapguide-users
