Private Cloud Service¶
The Private cloud service is intended for clients who want to use a virtualization platform, but the public cloud is unsuitable for them because of aggregation of resources, or it is incompatible with client's security policy.
Operation of the private cloud is ensured by at least 3 physical servers of the same configuration and network block or object storage, which we provide as a service. For large amount of data, it is possible to implement a dedicated storage (suitable for upper tens to hundreds of TB of space). The solution is implemented with a minimum of N + 1 redundancy (required to ensure high availability and possibility of maintenance and upgrades). For the operation of the cluster, it is necessary that more than half of the servers are running (for a 3-node cluster 2 servers must be in operation, for a 12-node cluster it is 7 servers). Our solution is limited to a maximum of 12 servers in a cluster, so we recommend using servers with adequate performance.
Responsibility and permissions¶
VSHosting manages the virtualization platform, network and storage layers. The client is fully responsible for the virtual servers running on the platform and has all the permissions to manage them.
VSHosting updates the virtualization layer during a scheduled maintenance window. Virtual servers are migrated to other nodes before the upgrade. All cluster nodes are updated one by one this way.
Supported operating systems¶
All current Linux, BSD and Windows operating systems are supported. For Windows, virtio drivers must be installed for maximum performance. To ensure maximum compatibility and support for advanced features, it is necessary to install qemu agent in addition to drivers. Without the installed agent, it is not possible to guarantee a smooth live migration of virtual servers between individual nodes (necessary to update the virtualization layer for example).
Failure of one of the nodes in the cluster¶
In case of an unplanned outage of one of the nodes in the cluster, all virtual servers are started on the other nodes in a short time. If you run HA solutions in virtual servers, it is necessary to correctly define the HA groups inside the cluster, so that virtual servers that are replicas of each other do not meet on the same physical node.