Aller au contenu principal

High Availability in the VS Web world - anyone doing it?

Commentaires

2 commentaires

  • Jakob Furrer

    Hi Gareth,

    While your inquiry is specifically about Studio Web, I would like to offer a few broader considerations related to designing for high availability across the Studio product line.

    When aiming for high availability, it is often helpful to take a step back and assess the overall system architecture. The key is to identify potential single points of failure in your environment and evaluate the impact of their failure. You can then determine where and how much effort to invest in mitigation.

    Here is my advice regarding several relevant Studio components:

    Studio Web
    Studio Web servers only deliver static content. The application code is executed client-side (in the browser). Therefore, deploying multiple server instances should be rather straightforward — no special handling is required.

    Studio Printing (gen2: based on .pagx layouts and ArcPy-based geoprocessing services)
    Print jobs are generated server-side. Each print request is atomic and can be handled by any server instance.
    However:

    • The download request for the generated print must be routed to the same server that processed the print job.
    • Your load-balancing proxy must therefore be configured for sticky sessions.

    Studio Search
    While technically a multi-instance deployment for performance and/or high availability is possible, it comes at significant complexity and cost — well beyond simply adding hardware.

    Such a deployment would require:

    • Careful planning of the architecture
    • Significant time investment from both your team and VertiGIS
    • Considerable configuration effort to manage multiple instances and services
    • Synchronization of both configuration and indexed data across instances, without introducing new single points of failure

    Currently, there is no official documentation or tutorial available for this type of setup.
    VertiGIS has some internal experience from similar efforts with the legacy product FTS-Index for WebOffice.
    For a glimpse of what was involved, you can review this page: WebOffice FTS Application Cloud Deployment

    It is important to note that Studio Search is built on a different (microservices-based) architecture, so any comparable solution would need significant adaptation.

    In practice, the effort required for such a deployment would be substantial, with limited benefit in most cases.
    Given the complexity, VertiGIS Support would not be able to provide assistance for such an undertaking.
    If this is a direction you would like to pursue, our Professional Services team could assist as part of a dedicated, customer-specific project.

    Best regards,
    Jakob

    0
  • Gareth Finney

    Hi Jakob Furrer 

    Thanks for the feedback - it's appreciated. I hadn't really considered the implications like Printing would bring to the new VS config.

    We currently have sticky sessions enabled via the LB for our Geocortex installs across 2 instances (siloed, not ‘clustered’). It has it's benefits for HA, but yeah, it presents some more challenges for printing as you say, and with things like projects (which we could never implement), and also for maintenance (patching with rebooting for example) and deployment to a leader/follower type arrangement. Basically bringing one of the web servers down essentially orphaned the GCX session which was/is a pain - think browser cache clearing and you're on the right track :(

    We're trying here to avoid going down this path again if possible, but still offer some redundancy somehow. We don't use Studio Search, and more than likely wont, but printing is certainly in the mix here, so this an interesting conundrum we find ourselves in. 

    Is anyone to your knowledge implementing multiple VSWeb instances?  Our planned architecture also involves an active-passive arrangement (replicated installs of portal/vsweb/arcgisserver etc) so in any event we could potentially switch to the second instance, but I'm also looking at how to cater/balance for load across the VSWeb instance(s) - or is this not really a factor if the web servers aren't really doing a lot other then brokering requests from the client?

    Just trying to avoid single points of failure here, but given we can only have one portal instance in the mix, it's more difficult now to even start with!

     

    again, thanks for the feedback

    Gareth

     

    0

Vous devez vous connecter pour laisser un commentaire.