Scale-out components
In a production deployment, the major components are split onto dedicated servers. Still every machine hosts only one copy of each component. In this chapter we will explain options to provide 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 (or VCC) database 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 the VSPC configuration and change the connection to the new listener of our AlwaysOn Availability Group. This change can be done without downtime.
During the entire time of the migration, the VSPC stays 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 backend 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.