Media Repository failover options and procedures
The Media Repository component provides the central, web based user interface, storage management, administration, etc. features. In smaller deployments, this role can be co-hosted with the Recording Server role, resulting in a simple single server deployment. In larger deployments, the SQL Server is deployed on another server or an existing corporate instance is used. In order to have a reliable, high performance central storage, a SAN/NAS system is connected for recorded media file access.
Media Repository servers can be deployed in a redundant fashion if required by placing a load balancing solution in front. In this deployment model, there is a separate, central and redundant SQL Server cluster, and a separate, redundant, central storage system.
The Media Repository servers serve user requests by talking to the same database and the same central storage, so any of them can serve any user. A (preferably hardware based) load balancer is necessary in front of the Media Repository. The load balancer has to meet the following requirements:
- Support for HTTP session stickiness to make sure authenticated users always go to the same Repository server where their session exists
- Since Verba has components that do not support cookies, the best if the affinity persistence is based on the client’s IP address
- The Verba Web application’s session timeout is 60 minutes, so the timeout while F5 stores the client’s IP address in its memory should be greater than 60 minutes.
- URI path (Might be needed for configuration if the load balancer serves other systems as well):Â http://<name>/verba
- (This requirement applies only if you use the Verba phone service for Cisco handsets) The phones support HTTP only, so even if you would like to restrict HTTP access, port 80 has to be proxied. HTTPS access can be restricted in Verba if needed (it still allows HTTP access for the phone service features).
- (Optional) HTTPS acceleration
In case of Media Repository failure, current user sessions served on the server, will be lost. Users will be logged out automatically and they will need to login back again. The load balancer will route their new login request through the next available Media Repository server. When a specific feature is tied to certain Media Repository (e.g. archiving) and the server fails, ongoing processes are interrupted and when the server is operational again, new tasks will be processed normally