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 <[email protected]> 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 > [email protected] > https://lists.osgeo.org/mailman/listinfo/mapserver-users >
_______________________________________________ mapserver-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/mapserver-users
