[mapguide-users] Mapguide and the Cloud
Riccardo Pucci
riccardo.pucci at geowebitalia.it
Tue Oct 5 09:12:07 PDT 2021
Hi
I've successfully tested your second option: the one with external load
balancer (on Kubernetes). If the load balancer supports some flavor of
"sticky" routing (ngix it does with cookies), sessions can be used. However
if, for any reason, mgserver stops, all active sessions are lost. But in
any case, since mapguide doesn't support sessions replication you couldn't
do better :)
I think Berkley db was not a lucky choice at design time... do you think it
it feasible to change it with something else? for example Mongodb o other
noSql? if library and session repository will be external, much of
architectural issues with mapguide could be addressed...
Il giorno lun 4 ott 2021 alle ore 10:07 Jackie Ng <jumpinjackie at gmail.com>
ha scritto:
> 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
> mapguide-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapguide-users
>
--
Riccardo Pucci
Geoweb Italia S.r.l.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20211005/4f65c54c/attachment.html>
More information about the mapguide-users
mailing list