Skip to end of metadata
Go to start of metadata

Description

Provides an overview of the basic concepts involved in MCP 2.0 Data Center Locations, including Cloud Network Domains, VLAN's, Cloud Servers, Cloud Images, Cloud Server Snapshots, Cloud Monitoring, Console, Tagging, Cloud Private Network Connection (CPNC), and the CloudControl UI and API.


Content / Solution:

What is MCP 2.0?

MCP 2.0 refers is the current data center location architecture supported by CloudControl. It is designed to replace the previous MCP 1.0 are offers far greater server and network capabilities with greater ability to customize the environment. Unless you currently have assets deployed in MCP 1.0 locations, the only locations you will see available for new deployments in CloudControl are MCP 2.0. Users who are looking to migrate from MCP 1.0 to MCP 2.0 may wish to review the comparison between MCP 1.0 and 2.0 locations provided by Understanding MCP 1.0 vs. MCP 2.0 Data Center Locations.

This article is designed to provide an overview of the new concepts associated with MCP 2.0 locations and to provide links to relevant introduction articles that provide more details on these concepts.

Cloud Network Domains and VLANs

Cloud Network Domains represent a "Virtual Private Data Center" within the Cloud infrastructure that supports both IPv4 and IPv6 networking. Within this "Virtual Private Data Center"  You can deploy one or more of these Network Domains in an MCP 2.0 environment, each of which effectively creates a separate virtualized environment in which you can deploy VLANs and Cloud Servers (virtual servers and appliances). Each Network Domain provides its own capabilities for routing, firewall rules, NATs, ViPs, anti-affinity, and other networking and virtualization capabilities. 

Cloud Network Domains and VLAN are the cornerstone of MCP 2.0 architecture - you can't actually deploy Cloud Servers without deploying the network architecture first. At a high level, the system supports two types of VLANs:

  • Attached VLANs leverage the networking capabilities of the Network Domain and provide the ability to route traffic to other Attached VLANs in the same Networking Domain and to route traffic external to other Network Domains, the Public Internet and Cloud Private Network Connections (CPNC). All such traffic is subject to the firewall and routing rules defined by the user on on the Network Domain.
  • Detached VLANs sit outside the networking capabilities and act as "stand-alone" VLANs that let you interconnect with NICs on other Cloud Servers located on the same Network Domain while remaining isolated from the Network Domain's routing capabilities. For an overview of how this functionality can be used in practice, see Introduction to Detached VLAN Use Cases.

Within each type, users define the VLAN's IPv4 address space while the system defines a corresponding IPv6 space. Each Network Domain provides a wide range of capabilities to control the networking in and out of Attached VLANs. These capabilities are too complex to cover in this article. Please review the following related Introduction articles for a more detailed explanation of both Cloud Network Domains, VLANs, and their capabilities.

Cloud Servers and Images  

Cloud Servers

Cloud Servers in MCP 2.0 have one or more NICs, each of which can be connected to a separate VLAN. Each Cloud Server can have up to 10 NICs, each of which is assigned its own private IPv4 and IPv6 from the IP space associated with the VLAN to which it's connected. Users can choose the private IPv4 address from the available pool in the NIC but the IPv6 address is assigned by the system. 

Unlike many Cloud solutions, MCP 2.0 does not use a "menu" of fixed instance sizes. Instead, users can customize the number of vCPU, the presentation of the vCPU to the OS, and the amount of RAM to any value allowed within the MCP 2.0 location. The system also offers multiple CPU performance characteristics called CPU Speeds so you can customize performance (and usage charges) to the workload. In addition, note that CPU and RAM usage is incurred only when the server is powered on, allowing you to maintain servers in a stopped state at low cost. In addition to CPU and RAM, users can modify the specific local storage configuration, including SCSI, SATA, and IDE controllers and ISO and Floppy disk configurations. The system offers multiple local storage performance configurations. These configurations can be changed on-demand and affect the usage calculations.

All Cloud Servers can be securely accessed either via Console or through a Client-to-Site VPN connection that provides access to all MCP 2.0 VLANs in a location.

See the following introduction articles for a complete explanation of Cloud Servers but also ensure you read the Cloud Images section below as Cloud Servers can only 

The basic server management function details can be found at:

Cloud Images

Cloud Images are the "source" of a Cloud Server deployment. When you deploy a Cloud Server, you are deploying a "clone" of a Cloud Image that will have the same local storage (including data) and hardware characteristics as the source Cloud Image. Images will have "default" values for the resulting server's CPU, RAM and performance characteristics but users can modify these values on deployment. The only aspect that cannot be changed in the deployment process is the local storage and data. However, the storage can be changed after deployment. 

There are several types of Cloud Images available:

  • OS Images are provided in all locations and provide the ability to deploy servers pre-built with an Operating System but no additional local data or software. in most cases, these images also include the OS licensing.
  • Priced Software Images add pre-built additional software packages in addition to the OS. These images may or may not include licensing. In most cases, they also incur additional charges.
  • Client Images are images you add into the library yourself by importing them into the system. The system supports imports via Open Virtualization Format (OVF) as supported in VMware's vSphere software, so in most cases you can export a virtual machine directly from your vSphere environment and use it as a template for deployment of Cloud Servers.

There are also two types of Server deployment methodologies:

  • Guest OS Customization deployments will use VM Tools to go into the Operating System of the Cloud Server and configure the correct IPv4 / IPv6 settings for each NIC based on the IP ranges defined for the connected VLAN. In some cases, the system will also reset the root/administrative password for the Cloud Server as part of the deployment. This deployment uses vSphere's Guest OS Customization feature and therefore is supported only for a subset of Operating Systems.
  • Uncustomized deployments provide an exact clone of the Image, meaning the resulting server will ave the same IPv4 / IPv6 settings as the source Image. This provides a larger support footprint but the resulting server will likely require re-configuring the NIC IP addresses after deployment.

See the following introduction articles for a complete explanation of Cloud Images and the deployment process

The basic image management and deployment function details can be found at:

Additional Services for Cloud Servers

There are a number of additional services that can be added on to Cloud Servers to enhance usability.

Cloud Server Snapshots is a feature that can be enabled for a given Cloud Server, like Cloud Backups or Cloud Monitoring. Once the feature is enabled, the system takes periodic "snapshots" of the Cloud Server. Each snapshot is a copy of a Cloud Server’s hardware and storage state at a given point in time. Cloud Server Snapshots include the current state of all components of the Cloud Server, including server hardware configuration elements (Number of CPU, CPU Speed, RAM, Network Adapters, Storage Controllers, etc.) as well as the state of all local storage disks. Cloud Server Snapshots can be created while a server is running – the system uses VMware’s native snapshot capability to create a snapshot and then offloads a “copy” of that snapshot to external storage datastores. See Introduction to Cloud Server Snapshots

Cloud Monitoring provides customers with the ability to enable monitoring services on a per server basis, allowing users to view a series of dynamic graphs illustrating the performance of their Cloud Servers, create alert-driven notifications using thresholds based on this information, and manage their Cloud environments by configuring powerful auto-scaling capabilities. Basic monitoring data is available directly in the Cloud UI. More advanced performance data and the Customer Notification / Auto Scaling Managers are accessible via a separate Cloud Monitoring portal that can be accessed using your existing Cloud credentials. See Introduction to Cloud Monitoring.

Tagging is a CloudControl function that allows you to associate additional metadata with billable Cloud assets for grouping and reporting purposes. See Introduction to Tagging, Tag Keys and Tag Values.

The Cloud Backup service offers backup and recovery for all Compute-as-a-Service (CaaS), Managed Hosting and on-premise servers. The Cloud Backup service is provisioned using the Cloud API, the CloudControl UI or the Cloud Backup Service Portal. See Cloud Backup - Introduction for details.

Cloud Private Network Connections (CPNC)

You can attach a Cloud Private Network Connection (CPNC) to a Cloud Network Domain in order to interconnect the Cloud Network Domain's IPv4 space with your corporate network. Since you can choose your own Private IPv4 address space within the Cloud Network Domain, a NAT mapping between the corporate network and Cloud Network Domain is usually not required. This allows you to make your Cloud Network Domain a literal extension of your corporate network. 

For more details, see Introduction to Cloud Private Network Connection (CPNC).

CloudControl UI

CloudControl provides an a UI interface to all MCP 2.0 functions. This documentation site includes complete step-by-step instructions for all functions based on the UI so you will see screenshots and references in all of the articles. For an overview of the key functions, see 

CloudControl API

To utilize MCP 2.0 locations and functionality, you will need to use our API 2. This API provides almost identical functionality as the UI as the UI leverages this API for all functionality. The API directly supports both REST and JSON integrations. For more details, see: