This article will discuss SoftLayer’s unique “private cloud” capabilities and provide a technical Q&A for deploying VMware infrastructures on the SoftLayer public cloud.
After my first fair share of architectural engagements, it became clear that SoftLayer’s bare metal capabilities are resonating incredibly well with our clients.
Please let me stress that bare metal is just “one tool in our architectural tool box” (see picture) … we offer public virtual servers (even private ones, where you don’t share the underlying physical host with other tenants for e.g. compliance or performance reasons), so use those approaches where appropriate!
Actually, that’s exactly the point, SoftLayer can provide the appropriate technology for your specific workload and deployment scenario, we do not “force-fit” your workload on a restricted set of virtual (only) compute instances.
Bare-metal systems open up the door to workloads typically not associated with the public (virtual) cloud like HPC, gaming and big data … but many “Enterprise customers” are also looking for the capability to create flexible private clouds within SoftLayer.
There are many scenarios where this can make sense. Imagine a client that wants to move an on-premise IT solution ”as-is” into the public cloud, however the solution has dependencies on a specific hypervisor. One of my current customers wants to e.g. move their e-learning platform into the cloud but their deployment method for individual “classes” relies on interacting with the physical ESX hosts.
Can I host VMware hypervisors on SoftLayer? Will I have access to the physical host? How is VMware deployed and licensed? What VMware features are available?
So what are your options when you have a dependency on a particular virtualization technology? For some scenarios you could select the public cloud of that particular hypervisor vendor. Yes, there is the risk that you lock yourself further into the ecosystem of a particular virtualization vendor or ignore how (potentially poorly) other workloads and hypervisor requirements might be facilitated. This approach is also unlikely to be sufficient if you need direct interaction with the physical hypervisor host (e.g. for custom deployments) as physical hosts are typically not exposed in these clouds.
Instead, you could consider a cloud vendor that allows you to deploy your workload on ANY hypervisor of your choice (and has also just been named “#1 in IDC’s Enterprise Cloud Customer Survey) … – hint ;)
So what VMware features are available? How is it licensed? Where can you find detailed information?
I have summarized the most frequently asked questions in this technical Q&A:
Can I really create an isolated private VMware cloud in SoftLayer?
Yes, you can deploy bare metal systems in SoftLayer, install any supported hypervisor (including VMware ESX) on these hosts and deploy virtual machines using the native management tools. SoftLayer systems are deployed be default in VLANs for segregation and various networking components (like gateways, routers and firewalls) can be used to create almost any topology.
How would I deploy VMware? (Can I deploy VMware components directly from the SoftLayer portal?
You have two options:
1) Select and deploy the ESX hypervisor automatically with a monthly bare metal system (see picture). You can also deploy vCenter management automatically with a virtual machine or bare metal system (Windows only).
(Go to https://store.softlayer.com/configure to see all bare metal configuration options.)
2) Alternatively you can deploy a bare metal host (e.g. with a free operating system like Cent OS) and subsequently install ESX manually (e.g. using Remote Console and Virtual media access of the host). You could then install vCenter Server manually or deploy the Linux-based VMware vCenter Server Appliance.
New: You can now also specify “No Operating System” when deploying a bare metal system (see pic)
How is VMware licensed in a SoftLayer environment?
Again, you have two options, essentially the licensing approach is tied to the above listed deployment mechanism.
1) When deploying ESX from the portal, SoftLayer will automatically enable VMware Service Provider Program licensing (VSPP).
On deployment, a default user “vmadmin” is added to the ESX server for data collection (do not delete). VSPP charges for RAM reserved/used for all “powered on” virtual machines (not “per socket” like a standard host license).
2) When deploying ESX manually, customers can utilize the “Bring Your Own License” approach (BYOL). That means they can apply their standard licenses to these hosts.
I have a client that is a service provider, can they use their own VSPP licensing for hosts that they rent in Softlayer?
No, customers can either use SoftLayer VSPP or “BYOL” for socket based licensing. They cannot utilize their own VSPP agreement.
You state that Softlayers VSPP licensing approach is automatically enabled when deploying VMware from the portal – can I use my socket based license (BYOL) for these systems?
No, SoftLayer currently does not support this approach. When deployed from the portal Softlayer’s VSPP is expected to be enabled.
Do I have to deploy a vCenter Server instance for VSPP to work?
No, if no vCenter Server is deployed, usage information for licensing is collected directly from the ESX hosts.
What license level is enabled when deploying vSphere from the SL portal?
Enterprise Plus (highest vSphere license level)
Can I create ESX clusters and use features like vMotion, DRS, Vmware HA?
Yes physical servers deployed with VMware can be configured in a cluster with all associated features enabled. This typically requires shared storage and the appropriate VMware license level (when deploying VMware from the SL portal Enterprise Plus is enabled)
Can I segregate my VMware traffic in SoftLayer similarly to on-premise deployment (separate VLANs for vm traffic, storage and management)?
Yes, you can use segregate traffic using SoftLayers native VLAN capabilities. Multiple Private Networks can be ‘trunked’ to the ESX servers, allowing for the Virtual Switches to apply VLAN Tagging at the Port Group layer for layer 2 isolation. You can use SoftLayer network devices like the Vyatta gateway to route traffic as desired.
Could I use a SL DataCenter to provide a failover site for my VMware Site Recovery Manager (SRM)?
That scenario can be achieved with SRM and “vSphere Replication” (SW based replication).
What storage solution would you recommend for private VMware clouds in SoftLayer (to store virtual machines).
SoftLayer’s bare-metal mass storage servers are ideally suited to provide cost-effective and highly performing shared storage for virtual machines.
You can e.g. configure a server with the appropriate mix of SATA, SAS and SSD drives, deploy it with QuantaStor software from the Softlayer portal, then carve up LUNs according to your specific requirements and make them available as iSCSI or NFS LUNs.
Can I use VMware’s iSCSI initiator with MPIO (multi-pathing) in a SoftLayer environment?
Yes, you can. There are however some considerations.
By default, SoftLayer places the host uplink (NIC) ports on the infrastructure switches into an LACP Pair. Do not configure iSCSI MPIO on ports configured with LACP (MPIO expects “unbundled” ports). You can ungroup the LACP ports by submitting a SoftLayer support ticket.
Can I use Softlayer’s (portal-deployed) NAS volumes to provide VMware hosts storage?
No, SoftLayer’s NAS storage provides CIFS and FTP based access. VMware requires NFS connectivity for (NAS) datastores hosting virtual machines.
Where can I find considerations for deploying VMware VSAN in Softlayer
While technically possible to deploy it, VSAN is currently not a fully certified offering in SoftLayer. Merlin Glynn‘s (aka virtualMerlin) blog contains useful background information on VSAN and its deployment considerations (as well as other associated topics – have a look!)
I was told that SoftLayer is “Xen-based” – how can you offer VMware environments?
A: We need to distinguish between SoftLayer’s native (portal-deployed) virtual servers and virtual machines created on private clouds using bare metal hosts …
SoftLayers native virtual machines are Xen-based but this is of little relevance as the hypervisor is not exposed to the “consumer”. You order a vm and deploy a workload to it.
When creating private clouds in Softlayer, a bare metal host with a hypervisor of your choice is deployed and you will directly interact with that hypervisor (e.g. through vCenter) in order to create virtual machines.
Why would I not always use a “private cloud” approach in SoftLayer?
If a virtual machine to host a general workload is all you need, then the native public or private virtual servers available from SoftLayer are typically the most cost effective “out of the box” choice. SoftLayer manages the physical systems these VMs reside on for you, including hypervisor and virtual server deployment.
Bear in mind that when deploying private clouds for specific requirements (performance, compliance, hypervisor interaction etc.) you will have the responsibility to manage the virtualization platform and associated components.
What migration options are available to me to move VMs and VM templates into SoftLayer?
In addition the Softlayer’s data transfer service and migration partners (like Racemi) there are a variety of VMware tools and approaches available depending on your use case, including:
OVFTOOL, VMware Converter, vCloud Connector (VCC), vSphere Replication, SRM, vSphere cold migration, vSphere Replication (e.g. with Riverbed Virtual SteelHead WAN Optimization). Details see HERE
Where can I find more detailed information on VMware deployments in SoftLayer?
This VMware@Softlayer document in the KnowledgeLayer contains links to very useful cookbooks and technical documents including
- VMware@Softlayer CookBook: Basic vSphere Architecture
- VMware@Softlayer CookBook: Migrating Workloads
- VMware@Softlayer CookBook: NSX®
Note: All of the above information is subject to change – always check for up-to-date information on “KnowledgeLayer” or using your formal IBM/Softlayer support mechanisms.
Update 15/07/14: Big shout-out to Adem Yetim from vmware.pro for translating this article into Turkish at: