We have a number of OVSD API applications/websites built, but they are all hardcoded to a specific Application Server. We've noticed that the OVSD built-in load balancing does not work with the API, but only within the UI.
We attempted to set up a Virtual IP (VIP) for our 3 application servers so that if one was down, it would try another one. The problem is that the VIP polls using TCP traffic on port 30999 and hangs the server.
Has anybody configured the API to do it's own load balancing or setup VIPs in a way which does not use TCP traffic for the application servers?
This is rather urgent as we wish to have our API calls function even if one server is unavailable.
We have done it on application level: I mean the application keeps a list of all servers and when needed to open session it choses one of them. If it's unavailable, goes for next, etc. Once the application gets the session it uses it. If an exception occurs (from server becoming unavailable) it tries to reconnect to other server from the list.
This is not probably what you're looking for but this is how we do it. Also it is easier for us this way because we only save changes to SD via WEB-API: we read the data directly from database. That way we only do very short transactions (save only) that can be repeated easily on another server.
Thanks Radovan. Would you be willing to share your code for the connection checking? The access directly to the database would not meet our needs, but if we could just ensure that the server is up it will accomplish part of what we were going to use the VIPs for.
Well, there is no specific code that could be posted here. I mean the code is scattered on few places around the application. The structure is like this: when a user wants to save some changes it asks a singleton for a WEB-API session. If that doesn't exist yet, it is opened with one of the servers from the list (if that fails, it tries another from the list, etc.). If the session already exists (from previous use), it tries to use that one. If it fails on an exception indicating the target server is no longer available, we consult the singleton again for getting new session.