[mapguide-users] Mapguide and the Cloud

[Jackie Ng]

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.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20211004/b7aa1ff0/attachment.html>