Scalability and High Availability
In a production deployment, the key components are distributed across dedicated servers, with each machine hosting only one instance of each component. In this chapter, we will discuss various options for ensuring high availability for the most critical components.
MSSQL Server
For MSSQL Server we can leverage the Windows Server Failover Cluster technology combined with SQL Server Always On. Thanks to this, we can make our VSPC and VCC databases fully redundant. We create an extra SQL server and then we join the existing and the new one as members of the cluster.
There are many resources where we can learn how to build a SQL Cluster using Always-On Availability Groups. For a step-by-step guide, please check Convert MSSQL standalone to Always On
Once we have converted our MSSQL standalone deployment into Always On, we can go back into VSPC and VCC to change the connection to the new listener of our AlwaysOn Availability Group. This change can be done without downtime.
- For VSPC, this change can be made under Configuration -> Settings -> SQL Server Connection.
- For VCC, this change can be made using the Veeam Configuration Database Connection Utility
During the entire time of the migration, VSPC and VCC stay connected to a single node and this connection keeps working. This is because the database is exposed from both nodes via their own DNS names and via the listener.
VSPC Web UI
The VSPC Web UI is comprised of two websites that are both installed and controlled with IIS (Internet Information Services), the native Web Server of Microsoft Windows. Just like any other website, the way to make them redundant is by leveraging high availability solutions, in this case load balancing. This is achieved by deploying multiple Web UI installations and by publishing them through a load balancer.
In a standard production deployment we already have a dedicated Web UI server (e.g. vspc-webui-01) so in this case we will add one or more servers to our setup. In this example we add one extra server for the Web UI:
- VSPC Web UI 1 (e.g. vspc-webui-01.cloudsp.local)
- VSPC Web UI 2 (e.g. vspc-webui-02.cloudsp.local)
- Prerequisites:
- A Windows Server machine to install the VSPC Web UI onto
- VSPC installation media
- A DNS name and IP address for the extra server
- A load balancer
-
Once the new Windows Server machine is deployed, we can follow the exact same installation procedure as described in chapter Build (View VSPC Web UI installation).
- Configure the load balancer in front of the Web UI servers so that users will only have to connect to the generic URL like for example console.cloudprovider.com.
Deploying and configuring the load balancer itself is out of the scope of this document.
One item is mandatory in the selection of the load balancer. Since VSPC uses a HTTPS connection, the load balancer must support session persistence (also known as sticky sessions).
-
Regarding the SSL certificate, the same certificate needs to be installed on both Web UI servers and refer to the DNS name of the public web interface. This way the connection to each of the web servers is exactly the same and we are able to distribute the load across the two servers via load balancing.
-
In the end, we will be able to connect to VSPC using either of the VSPC Web UI servers.
VSPC Server
Unfortunately there is no way to implement high availability for the VSPC Server. The recommended approach is to replicate the virtual machine where the VSPC Server is installed. This creates a cloned server that is identical to the original one. and in case of failure can be simply powered on to restore operations.
VCC Server
Unfortunately there is no way to implement high availability for the VCC Server. Two recommended approaches exist:
- Replicate the virtual machine where the VCC Server is installed. This creates a cloned server that is identical to the original one. In case of failure, it can simply be powered on to restore operations. Downtime is only a few minutes.
- Create a stand-by VCC Server where VCC is installed and kept at the same software/patch level as the original. In case of failure, it can be powered on and a configuration backup is restored. Downtime of the service depends on how quickly the operations can be executed.
VCC Cloud Gateway(s)
It is recommended to deploy N+2 Cloud Gateway Servers for scalability as well as automatic failover between the cloud gateways.
When a tenant connects to the Cloud Connect service using a DNS name or IP address of a cloud gateway, the Veeam backup server on the tenant side obtains a list of all configured cloud gateways. If the primary cloud gateway is unavailable, the Veeam backup server on the tenant side fails over to another cloud gateway from the list.
