Hi, I suggest to ask Camp2Camp and Gabriel Roldan about how much details they can tell about their customer. Some background is published in http://geoserver.org/geoserver-cloud/ and an excerpt from an open mailing list archive is telling that
“…the project was intended to be donated to the community from its inception, and Camptocamp is going to keep using it with the current and other customers, which will provide funding and hence resourcing both for maintenance and continued development. The donation comes in the spirit that it'll be useful to other parties and in the hope of establishing a healthy relationship with the community, feeding on GeoServer, and contributing back to the upstream project.” -Jukka Rahkonen- Lähettäjä: Andreas Neumann <andr...@qgis.org> Lähetetty: tiistai 27. huhtikuuta 2021 19.34 Vastaanottaja: Rahkonen Jukka (MML) <jukka.rahko...@maanmittauslaitos.fi> Aihe: Re: [Geoserver-users] Small study on "Cloud optimized OGC WMS Servers" Hi Jukka, Thank you for sharing this resource - which seems to be the same we already came across during our online research. Nevertheless a very interesting resource. Do you know if this setup is actively being worked on? Is this (or a similar) setup being used in a production deployment? How fast can such a service (e.g. the OGC WMS service) spin up for auto scaling for large configurations (several hundred layers)? Is this a matter of milliseconds / seconds or also 1-2 minutes (like we experienced with QGIS server when loading a huge project with almost 1000 Postgis layers). I assume the "catalog/Config back-end" in the system architecture is the shared part that QGIS server is still missing, that would allow it to autoscale much better than it can today ... In the case of QGIS server, each instance has its own copy of the project and layer configurations and they are not sharing this information. I would assume that the "Catalog/Config back end" would do exactly this? Thanks for the discussion, Andreas On Sun, 25 Apr 2021 at 19:56, Rahkonen Jukka (MML) <jukka.rahko...@maanmittauslaitos.fi<mailto:jukka.rahko...@maanmittauslaitos.fi>> wrote: Hi Andreas, See https://github.com/geoserver/geoserver/wiki/GSIP-201 “Cloud Native GeoServer Project Donation”. -Jukka Rahkonen- Lähettäjä: Andreas Neumann <andr...@qgis.org<mailto:andr...@qgis.org>> Lähetetty: perjantai 23. huhtikuuta 2021 18.36 Vastaanottaja: geoserver-users@lists.sourceforge.net<mailto:geoserver-users@lists.sourceforge.net> Aihe: [Geoserver-users] Small study on "Cloud optimized OGC WMS Servers" 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, like 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 Geoserver in cloud environments? Do you know of any work? We came across this project here: http://geoserver.org/geoserver-cloud/ - this is probably the closest system compared to what we have in mind. Can you share a bit of experience with this system? How well does it work in practice? What are the challenges/problems and what works well? One major problem that probably all installations of an OGC WMS server have is how to deploy a more intelligent load balancing system? (the "Gateway" in the above mentioned Geoserver system architecture diagram). Often, the default load balancer is some kind of round robin load balancer system, but this frequently 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 or PDF generation task (potentially with many layers, many features and a high-dpi, such as 600dpi, where the request can take several seconds to process. Meanwhile, the GetFeatureInfo might still wait behind a long-running request, while parallel instances would have free resources, because they have just finished their own task. As mentioned in our study document it is of course possible to separate 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 additional work in the Geoserver community regarding cloud deployment, cloud optimization, intelligent 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<http://QGIS.ORG> board member (treasurer -- Andreas Neumann QGIS.ORG<http://QGIS.ORG> board member (treasurer) -- -- Andreas Neumann QGIS.ORG<http://QGIS.ORG> board member (treasurer)
_______________________________________________ Geoserver-users mailing list Please make sure you read the following two resources before posting to this list: - Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/ - The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
