[mapserver-users] Mapserver installation in cloud environments (kubernetes)

[Wouter Visscher]

Hi Andreas,

To answer your question: "Do you know of any work ...."

For the Dutch National Geodata Infrastructure (PDOK) we are running now
(over a year) hundreds of OGC WMS/WMTS/WFS servers (primarily Mapserver and
Mapproxy) on aks (Azure kubernetes).

The challenges you are describing sound very similar to ours :)

To give some small inside on some of our solutions regarding:
deployment: kustomize and operators
cloud optimization: (regarding data) geohashes over GPKG and PostGIS tables
and getting the data as close to the pods as possible.
load balancing: (infrastructure wise) 'standaard'
loadbalancing with traefik, (OGC wise) we are working on a
'ogc-webservice-proxy' for determining the size/duration/location,
basically what is going to be the impact of a request.
resource sharing: (infrastructure) ScaleSets for nodes, and ReplicaSets
based on load, (data) because we have most of the data in GPKG we 'copy'
the data around. So for a service that scales up to 4 pods we have 4 of the
same GPKG copied to that node.

I will share your knowledge with my colleagues, but it seems you reached a
lot of the same conclusions (so far I have read) we have.

On Fri, Apr 23, 2021 at 5:20 PM Andreas Neumann <andreas at qgis.org> wrote:

> Hi,
>
> For a small project as part of the Swiss National Geodata Infrastructure
> (grant project) several people worked on a study document called
> "Cloud-optimized OGC WMS Server" where we analyzed problems that can arise
> when you install an OGC web server in the cloud (e.g. docker image deployed
> via Kubernetes, OpenShift or the likes). This work had a focus on QGIS
> Server with it's own set of problems - but some of the issues studied in
> this document also matter for other OGC WMS servers, such as UMN Mapserver
> or Geoserver, such as the load balancing problem, how to share resources,
> etc.
>
> Here is the link to the document (not in final form yet, but close to
> being final):
> https://docs.google.com/document/d/1cOUWgzalRx7CHWTFgHz6-uyScsCcoaEmYC0VBHdZShQ/edit#heading=h.c7gq4lie7ys2
>
> I wonder if any similar work has been done specifically around problems,
> challenges and solutions when you deploy UMN Mapserver in cloud
> environments? Do you know of any work?
>
> One major problem that probably all installations of an OGC WMS server
> have is how to deploy a more intelligent load balancing system? Often, the
> default load balancer is some kind of round robin load balancer system, but
> often this leads to inferior results where "cheap and short" requests (such
> as a simple GetFeatureInfo or GetLegendGraphics request) can be queued
> behind a long-running GetMap request (potentially with many layers, many
> features and a high-dpi, such as 600dpi, where the request can take several
> seconds to process.
>
> In our production system we are currently separating the requests to
> dedicated instances for short requests and potentially long requests, to
> avoid the above mentioned scenario, but we are not so satisfied with the
> solution, as it is  a bit inflexible and also a bit harder to maintain.
> Ideally, we would like to have a more intelligent load balancer with
> incoming queue that holds back requests as long as all WMS server instances
> are busy. This would avoid the situation where a "less intelligent" load
> balancer would simply forward the requests to instances based on
> Round-Robin principle.
>
> Do you know of any work in the UMN Mapserver community regarding cloud
> deployment, cloud optimization, load balancing and resource sharing?
>
> In our study document I'd like to also include the perspective of other
> WMS servers besides QGIS server, so any input would be welcome.
>
> Thanks,
> Andreas
>
> --
> Andreas Neumann
> QGIS.ORG board member (treasurer)
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20210423/a29cec4b/attachment.htm>