Assess new traffic patterns in private cloud deployments
The starting point for private cloud performance assurance is the question of how much traffic patterns and volumes are likely to change as a result of the private cloud technology used to augment or displace traditional data center hosting of applications. If we assume that the private cloud generates the same traffic as the older data center configuration, then no special issues would arise. In most cases, though, there will be some differences in traffic associated with private cloud deployment, and these differences will have to be accommodated to stabilize application QoE through the transition.
Consider new data center connectivity requirements for private cloud
The primary question for user-to-cloud performance assurance is whether the private cloud introduces new data center connectivity requirements. No matter how many data centers might be used in a private cloud, the question is less the number than whether the data centers are integrated to share work and form a common resource pool. If they are not contributing to a pool but are simply separate data centers, each with their own load of applications, then each can simply be added to the corporate WAN and other network changes are not likely needed.
If the data centers in a private cloud are a collective resource to be shared as needed among applications and application components, it will be necessary to interconnect these data centers with a WAN connection. To ensure that the connection process doesn't create performance issues, it's critical to size the traffic load between data centers by measuring or estimating traffic, then comparing peak and average traffic patterns to the capacity of the connection. Once this has been assessed, it's important to ask whether all data centers connect to the enterprise WAN in parallel or whether there is a single connection shared among data centers.
In the latter case, the inter-data-center connection will have to carry user traffic to the secondary data centers from the one with the WAN connection, and faster facilities will be needed. Users of VPNs probably will not expect one data center to be the host of their WAN, but those who use leased-line, fiber, or virtual-circuit networks may have this problem.
In all cases, inter-process communication among application components and storage access to resources in another data center will have to pass across an inter-data-center trunk. It's important to manage these traffic sources with the policies that determine where application components are run and where data is stored. Otherwise, traffic loads across these paths will be so high that connectivity costs may become alarming, and that will induce management to try to live with slower paths, creating more congestion and QoS problems.
A cloud data center interconnection using a circuit or virtual circuit (like fiber or point-to-point Ethernet) can usually be installed to link LAN switchs in different data centers in the same way a local cable would be used. That means the WAN service has no features to consider other than capacity. If a VLAN or VPN service is purchased to link cloud data centers, it's important to ensure that the LAN features used in the data center can work with or over the VLAN/VPN service. Traffic prioritization standards and the collection of Ethernet standards popularly called "data center bridging" may require support within the VLAN to work properly, and not all VLAN services provide support for all Ethernet standards in topology discovery and packet prioritization, so it's critical to ask your service provider.
Application performance assurance in hybrid/private cloud environments
The issue of hybrid cloud connectivity is often the most complex for cloud builders. There are a number of configuration models for accessing public cloud services, and each creates some challenges in managing connection performance and availability. Generally it's easier for businesses to adopt the same basic connection approach to both public and private cloud services where possible, meaning to either accept Internet (SSL and IPsec) or provisioned (MPLS/BGP Layer 3) VPNs for both. If public cloud services are accessed through the Internet, and private cloud applications are accessed via a Layer 3 VPN, it's important to decide whether the remote sites on the company network will access the public cloud directly from their sites (requiring a special access router configuration there), or whether they'll access the public cloud and the Internet from within the VPN through a central gateway. In the latter case, the public cloud traffic will transit the company's VPN. This may create additional load, congestion, and QoS issues that must be considered when selecting a VPN provider and providing access connections to the central private cloud sites. Faster access will always provide some insurance against performance issues.
In a private cloud, it's always possible to employ the full range of application acceleration technologies to improve performance and availability because the business controls both the user (branch office) and server (cloud data center) ends of the connection. Data compression technology is often useful in increasing performance by reducing the actual traffic on the network. For hybrid cloud configurations, though, it may be impossible to install a matching device in a public cloud data center. Compression strategies that work through server-side software may be a solution, but this can create server load and reduce performance of the public cloud components of the application. It's probably wise not to assume that application acceleration techniques will work to manage performance in hybrid clouds. A truly asymmetrical application delivery controller (ADC) -- which requires nothing on the server side -- should work in cloud environments. However, you should get both the application acceleration vendor and the cloud provider to sign off on its use.
The easy rule of thumb for private cloud networking is to forget the composition of the data centers and their networks for the moment and ask whether the WAN connectivity will change between a new private cloud infrastructure and a traditional data center. If there are no changes in connectivity or where applications are run, it's likely that there will be few changes needed in the WAN. To recap, your options would be as follows:
- A connectivity change is one that alters the number of sites or the routes of circuits.
- An application change is one that moves where the application runs and therefore changes the pattern of traffic. The move might mean that the app is hosted in a different data center, or it could mean that it is hosted elastically in any of several data centers.
Where significant changes in connectivity are created, most often by hosting applications/components in a larger number of places, then the impact of these connectivity changes will have to be addressed if the private cloud is to provide equivalent service to its users.
This was first published in January 2012