Even though SV does not support high availability deployment out of the box, you might be able to achieve it with some custom configuration.

Prerequisites

1. SV Server license (SV is Class 1 product, so this will give you several non-production licenses)
2. Using VCS to store virtual services
3. You can use CI/CD tool in your environment
4. You can use a Load Balancer in your environment

High availability setup concept example

1. Install secondary SV Server with hot-standby SV Server license. Make sure you use separate DB!
2. Setup a TCP load balancer, which is able to route to primary or secondary SV Server based on its configuration
3. Put all your virtual services to Git repo
4. Configure Jenkins to monitor Git repo and if change is detected:
   1. Run CLI, which would identify which virtual service was changed
   2. Redeploy the changed virtual service to both primary and secondary SV Server
   3. Switch it to Simulation
5. Setup a health check, which would monitor primary SV Server for issues. For example:
   1. Valid SV Server API response
   2. Valid Virtual service response
   3. CPU utilization
   4. ...
6. If health check fails, reconfigure a load balancer to route to a secondary SV Server
7. Recreate primary SV Server
8. Reconfigure load balancer to use primary SV Server

Note: This setup adds quite a lot of complexity to the SV Server deployment, so consider if it is worth it or not. From our experience I would say not for majority of our customers. Usually customers trying to achieve HA setup were just having less stable SV environment due to added complexity (both technical and organizational). Also if your current SV deployment is not stable, than there will be other problem and creating HA setup above would just add more complexity and would hide the root cause.

Quick recovery example

Even if you don't want to create full HA setup above, it might still be useful to have some tasks automated, so you can quickly recreate your environment in case of issues:

1. Put all your virtual services to Git repo
2. Configure Jenkins to monitor Git repo and if change is detected:
   1. Run CLI, which would identify which virtual service was changed
   2. Redeploy the changed virtual service to SV Server
   3. Switch it to Simulation