This article provides an introduction to Cloud Servers

What Are Cloud Servers?

Cloud Servers are the virtual machine object in CloudControl environments. Unlike most Cloud environments, CloudControl does not use an "instance" model where users choose from a set of preconfigured compute instances with specific CPU and RAM performance characteristics. Instead, CloudControl servers are virtual servers with fully customizable amounts and performance levels of CPU, RAM, and disk storage. This allows users to modify the characteristics of the server based on the needs of the underlying application at any point during the life of the Cloud Server. Usage calculation is updated in real-time in conjunction with such changes.

Each Cloud Server can have one to ten virtual NIC's which are connected to VLANs within the same Cloud Network Domain. Network connectivity is dependent on the Cloud Network Domain configuration. For more information on these concepts, see Introduction to Cloud Network Domains and VLANs as it is strongly recommended to review that article in conjunction with this one.

How do I Deploy a Cloud Server?

NOTE: Deploying a Cloud Server requires you to have already deployed a Cloud Network Domain and VLAN as every Cloud Server must have at least one virtual NIC that is connected to a VLAN. 

Cloud Servers are deployed from an Image. The server itself is an exact copy of the virtual hardware and local storage of the source Image, though users can change the performance characteristics as part of the deployment process and can be changed "on the fly" after deployment.

CloudControl supports two types of Images:

The server deployment process itself has different variations that are explained in the following articles:

Remember that although all Images have a base set of specifications, including CPU, RAM, and Storage, the Cloud Servers are NOT fixed in terms of CPU, RAM, and Storage once they are deployed. All of these are scalable and can be modified to fit the demands of your workload.

Performance Characteristics of Cloud Servers

The performance characteristics of servers are dictated by the server specifications and "speeds" associated with the specifications. The key concepts to understand are:

  • CPU
    • Each Cloud Server must have at least one vCPU. The number of CPU's represents the number of virtual cores on the underlying VMware ESXi host that are available to the Cloud Server's Guest OS. By default, the Guest OS will perceive each virtual CPU as a separate physical processor with one core. However, using the "cores per socket" function, you can adjust how the Guest OS perceives the CPU
    • Most MCP 2.0 locations also support different CPU speeds, which dictate the amount of processing power on each ESXi core that is available to the Guest OS. For more details, see Introduction to CPU Speeds (vCPU Classes).
    • Note that underlying performance is also  governed by the ESXi host processor type, which is natively perceived by the Guest OS
  • RAM
    • The maximum amount of RAM available to the Guest OS is adjustable in GB. Each Cloud Server must have at least one GB of RAM allocated to it.
    • There are no "speed" concepts associated with RAM, though the physical characteristics of the underlying ESXi host processor type may vary by datacenter location
  • Local Storage / "Disk"
    • Each Cloud Server can have SCSI, SATA, or IDE controllers that support local storage which will be perceived by the Guest OS as "disks" attached to the controller. Most OS Images will have the OS loaded onto the SCSI 0:0 position, but this is not required. In fact, local disk is not a requirement for a Cloud Server, though the lack of any disk means that the server must be configured to network boot from some external source.
    • Users can change both the size of the disk (in 1 GB increments) and the performance characteristics of the underlying storage base on the disk speed associated with the disk The available disk speeds vary between data center locations.
    • Complete details on these concepts are covered in Introduction to Cloud Server Local Storage ("Disks") and Disk Speeds. It is also strongly recommended to review that article in conjunction with this one. It covers modifications related to the disk performance characteristics so that information is not repeated here, but the basic reference articles are:

Modifying the CPU and RAM Characteristics of Cloud Servers

The basic mechanics of changing CPU and RAM characteristics are covered in How to Manage a Cloud ServerHowever, the rules around whether a server must be stopped in order to make a change are complex. There are three different possibilities;

  1. Server Must Be Stopped To Make a Change - Changes that require the server to be in a stopped state in order to even request a change
  2. Server Will Be Stopped As Part of Change - If server is running VM Tools, the system will allow some changes to be requested while the server is in a running state, but the system will gracefully shutdown the server as part of the change process
  3. "Hot Change" Support  - Changes that can be made and implemented while the server is running. No shutdown is required

The following sections explain which changes are supported in each scenario.

"Hot Add" CPU and RAM Settings

The underlying vSphere hypervisor requires a specific virtual machine "flag" to be set in order for CPU and RAM increases to be performed on a running server. In order for CPU to be increased while the server is running, the Hot Add CPU Enabled flag must be set to true. Similarly, RAM increases require the Hot Add RAM Enabled flag be set to true. 

With the March 2020 release, the system now exposes the state of these flags on the Server Dashboard screen for all Cloud Servers (see Navigating the Server Dashboard for more details): 

Users can change these "Hot Add" flags using the Reconfigure Hot Add Settings option, but these settings require the server to be in a stopped state in order to be changed.

The system tracks these flags only for Cloud Servers. When a new Cloud Sever is deployed, it will inherit the same settings as the parent Image or Snapshot, but the settings are not currently tracked or visible on Images or Snapshots. 

Note that vSphere also has an important limitation around adding RAM to a running server even when Hot Add RAM Enabled is set to true. The amount of additional RAM that can be added is limited based on the amount of RAM that was deployed when the server was first powered on:

  • Hot add is only supported up to maximum RAM value of 16 times the amount of RAM that was on the Server when it was last powered on
  • Additional rule applies only to UNIX servers: If server has less than 3 GB RAM on a server when powered on, the maximum size you can “hot add” to is limited to 3 GB RAM

If a server is running and Hot Add RAM Enabled = true , the system will show the maximum size to which the RAM can be increased as the Maximum Hot Add RAM value as shown in screenshot above. If this field is set to "N/A", the server is in a stopped state. The field is not shown if the Hot Add RAM Enabled flag is set to false. 

Updating this maximum value requires a full power down to occur - the maximum value is not updated based on a reboot of the server.

Matrix Identifying Which CPU/RAM Changes Can be Made In Which State

The following matrix identifies the various CPU and RAM changes and identifies the requirements. Note the UI will warn users prior to the change based on these rules:

CPU/RAM Change

Server Must Be Stopped in order to request a change

Server Can Be Running when change is requested but it will be stopped as part of the change process

“Hot Change” supported (change can be requested and made while the server is running)

Set Hot Add CPU/RAM flag

✔ (always)

Increase CPU

If Hot Add CPU = FALSE and VM Tools is NOT Running

If Hot Add CPU = FALSE and VM Tools is Running

If Hot Add CPU = TRUE

Increase RAM

If Hot Add RAM = FALSE and VM Tools is NOT Running

If Hot Add RAM = FALSE and VM Tools is Running

If Hot Add RAM = TRUE

Decrease CPU or RAM

If VM Tools is NOT Running

If VM Tools is Running

Change CPU Speed

Change to Cores per Socket

Change to Advanced Virtualization Settings

In addition to these changes requirements, note that "hot" CPU, RAM, and CPU Speed changes to a running server also require a compute vMotion of the server between ESXi hosts to be performed as part of the change. Due to this requirement, two additional caveats apply:

  • The system will require sufficient CPU and RAM capacity on the underlying hypervisor cluster. If sufficient capacity is not found, the change will be aborted. Users can either choose to try the change at a later time or stop the server and initiate the change. Such failures will have a failure entry (with "REASON_11") made to the Administrator logs available at How to View an Administrator Logs Report and be visible in the UI:
  • In the rare case, the compute vMotion needed to apply the change does not succeed, the operation will succeed but the new performance characteristics will not take effect until the server is restarted. The Cloud Server will be flagged with a status of "Requires Restart". Users will not be able to take any action against this Server until the server is either restarted via CloudControl or shutdown.

Viewing Cloud Server Configurations in the Dashboard

The Cloud Server Dashboard displays relevant information about a Cloud Server - note that users can click the Networking, Storage, Monitoring, Snapshot, and Backup sections to expose the specific configurations associated with those elements:

For more information about the Server Dashboard, see Navigating the Server Dashboard

Additional Cloud Server Features

Cloud Servers can be further customized by utilizing the many additional features that have been developed the usability of the platform, including:

Managed Cloud Servers

As part of a managed service contract with your service provider, one or more Cloud Servers may be deployed into your organization's Network Domain(s) as part of the managed service. In these cases, the server is managed by your service provider and is therefore "locked" to prevent users from managing it. Such servers still incur usage but all management actions (including Console access) are blocked.

Such servers are tagged and visible through the UI as a "Managed Server":

Should you identify a Cloud Server that you believe is improperly tagged as a Managed Server, contact your service provider.

Recently Updated