vCloud Hybrid Service for vCloud Director Administrators

Me and other 15 vExperts/VCDXs were invited to Early Access Program for the VMware vCloud Hybrid Service (vCHS). Even though I am a VMware Employee I was not involved in the vCHS project and this was my first chance to get some hands on time with this new service.

As architect working for Professional Services I do build vCloud Director based clouds for service providers so I was curious how is vCHS different from the clouds I designed.
This blog post therefore will not talk about what vCHS is and how it can be consumed (read Massimo Re Ferre’s vCHS: Stop Thinking About Building a Cloud, Start Thinking About How to Consume It post) but how it differs from the typical private or public vCloud Director based cloud. It is therefore assumed that the reader has at least vCloud Director Administrator equivalent knowledge.

A Service Not A Product

First of all vCHS is a service not a product. Sure it uses vCloud Director, vSphere and other VMware products, but as it is not tied to Enterprise (slow) software product release schedule new features can be incorporated during much faster release cycles. The new features will eventually get to the standard product releases.
I need to put a disclaimer here that because vCHS is a service some of the features I describe here might change until the GA which is around Q3 as the Early Access Program period is used to collect feedback and act upon it.

Cloud of Clouds

Although vCloud Director is pretty scalable (up to 25 vCenter Servers) it might not be enough if we start to think in Amazon AWS scales. vCHS is able to federate multiple vCloud Directors in multiple locations. Customers can purchase dedicated vCloud Director instances or a shared virtual private clouds.

See YouTube video: vCloud Hybrid Service – The “Cloud of Clouds”

Interesting observation I made that I guess in order to simplify Organization VDC access management there is always 1:1 relationship between Organization and Organization VDC. This has some consequences on how the customer transfers workloads or catalog images between Organization VDCs – vCloud Director does not support inter Organization transfers therefore vCloud Connector must be used. You also cannot share Org VDC networks which cannot span Organization boundaries – Edge Gateway SL VPN connection would have to be created instead.

GUI

vCHS has new web based portal. It is not vCloud Automation Center nor is it the vCloud Evaluation web portal. Those should not be confused.

vCloud Automation Center Self Service Portal

vCloud Service Evaluation Portal

vCHS has brand new portal which is simple to use and less confusing for regular users than vCloud Director portal but the tenant still has the option to use the native portal. Note that some advanced features are not yet available in the vCHS portal and must be performed directly in vCloud Director (Edge Gateway or Catalog management). As mentioned above new portal features might appear quickly.

vCloud Hybrid Service Portal

I should confess I have not spent too much time playing with the vCHS portal as I am much more comfortable in the vCloud Director interface.

User Management

This is where it gets interesting. vCHS uses different user roles than those that are in vCloud Director. Even if you buy dedicated cloud instance you will not get vCloud System Administrator rights. Also in the shared Virtual Private Cloud instance you will not get Organization Administrator rights. Instead you will get different vCHS level rights that somehow map to subset of vCloud Director rights – see KB 2053484 for more detail. This was mainly done to disable the vCloud Director local accounts and instead enforce global access management that spans cloud instances. You will not be able to directly access vCloud Director GUI with your vCHS account. It is instead needed to first log in to the vCHS portal and then thanks to Single-Sign-On go to the right vCloud Director organization.
API access works with the vCHS account (not sure how that was achieved). As even the most powerful vCloud Director role – VPC Administrator (in KB above listed as Virtual Infrastructure Administrator) does not have access to User management (either from vCloud Director GUI or vCloud API) it can break some applications that rely on this. One of them is vCloud Automation Center (read my other article Integration of vCloud Automation Center with vCloud Director for the details) which at the end of provisioning process (done under a service account) maps the provisioned VMs to a vCAC user account. If that account does not exist it tries to create it.
I assume this issue will be quickly resolved with a vCAC custom property hard user mapping or identity provider federation at the vCHS user management level.
So if you have some automation tools that leverage vCloud API you must take these limitations into account and do some testing. Even if you buy dedicated cloud you will not be able to use provider vCloud APIs – tools like vCDAudit, vCenter Operations with vCloud Adapter will not work.

vCloud Connector

Each vCloud Director instance has its own vCloud Connector (vCC) shared node. I was able to connect my vCloud Connector Server to it without any problems and quickly transfer first workloads in and out. Besides the simplicity of the setup an additional advantage is that it does not consume any allocated storage space and does not take away internet bandwidth as opposed to private vCloud Connector Node deployed inside Org VDC. It is vCC version 2.5 which has transfer path optimizations which speeds up the transfer as it is not staging the OVF vApp files on the nodes but instead is continuously streaming.

What is also nice that you get vCloud Connector Advanced license which enables in my opinion the killer feature – Content Sync. You can publish your private vSphere folder with templates to automatically sync with connected clouds. This makes the catalog management really easy.

vCloud Connector Content Sync

vCloud Connector: Public Cloud Transfers with no Private vSphere Environment

I have already blogged quite extensively about vCloud Connector – a tool for transfers of VMs, vApps and catalogs between public and private vSphere or vCloud Director based clouds. This post is dedicated to one particular use case, let’s call it ‘Developer Use Case‘. Here the user is not VI Admin, but a developer that wants to deploy his apps to public clouds. He has no access to private vSphere environment and obviously to vCenter Server.

vCloud Connector (vCC) consists of vCloud Connector Server, vCloud Connector Nodes and vCloud Connector Client. In the past the vCloud Connector was accessible either through vCenter Server plugin or through web interface at http://vcloud.vmware.com/connector. However as of April 2nd 2013 VMware discontinued the web interface access which means that vCenter Server plugin is currently the only option to use vCloud Connector.

The web portal was great for the Developer Use Case. The developer did not need to have access to vSphere, vCenter, vSphere client or even a Windows machine and could use vCloud Connector from his Mac or Linux browser.

What now follows in this article is basically a description how the Developer Use Case can still be fulfilled even after April 2nd. The idea is to use vCenter Server Appliance and deploy it to the cloud together with vCloud Connector Server. This vCenter Server Appliance will not manage any ESX hosts and will be basically used only for the instantiation of the vCloud Connector Client interface. The thick (.NET) vSphere Client is still needed (as at the moment there is no vCC plugin for vSphere Web Client), this also means a Windows OS, so the developer will need either physical Windows desktop, or a virtual one on his PC or running also in the cloud and accessible via RDP.

How to deploy vCenter Server to the public vCloud Director cloud

1. From VMware website download vCenter Server Appliance. I have used the version 5.1.0b which comes as one large OVA file.
2. As we cannot import OVA file to vCloud Director we first need to unzip the file to get the OVF format. This can be done easily by adding .zip extension to the downloaded file and using WinZip or similar utility.
3. Import the OVF file into your organization catalog.
4. As I also had vCC Server and vCC Node in the catalog I deployed them together into one vApp.
   
   
5. After accepting EULA, selecting Storage Profile and setting hostnames it is important to put the VMs on one internet routable network and manually assign IP addresses from the static pool of the organization VDC network. We cannot just rely on Guest Customization as the IP address assignment is part of the vApp property which is applied when the vApp is deployed. So in my case I used (the default) 192.168.1.0/24 subnet for the org VDC network, where IP 192.168.1.1 was used for the internal interface of the Edge Gateway and IPs 192.168.1.2-192.168.1.4 were used for vCenter Server, vCloud Connector Server and vCloud Connector Node.
6. On the next page we are presented with the vApp properties. Here we have to again manually assign the correct IP addresses as specified in the previous step. As I am deploying 3 imported vApps at once it looks quite confusing as the properties of each are merged into one screen. The default gateway address is the Edge Gateway internal interface and subnet is 255.255.255.0.
7. After the deployment is finished we will get vCloud Connector vApp which looks like this:
8. We will need to access all three VMs from the internet to configure their Virtual Appliance Management Interface (VAMI) which runs on TCP port 5480. If you have 3 external IP addresses you can set up destination NAT (DNAT) rules for each VM on the Edge Gateway. vCC Node and vCC Server will also need to access internet therefore source NAT (SNAT) rule must be created for them. We could actually get away with just one external IP address: we could use port forwarding for the VAMI interface of each VM runnning on port 5480 (or we could even configure them over console from another VM with supported browsed deployed in the cloud). Please refer to my other post linked at the beginning of the article for the advanced networking information. In my lab I have luxury of 3 external IP addresses represented by 10.0.2.151-10.0.2.153 range.
   
9. Next we need to create firewall rules. As I already mentioned we need TCP port 5480 for VAMI interface. We also need TCP port 443 for vSphere Client connectivity to vCenter and TCP port 443 for incoming and outgoing traffic for vCloud Connector Node.
   
10. Now we can start the vApp and start configuring the VMs. I will skip the vCC Server and Node configuration and will focus on the vCenter Appliance part.
11. The inital configuration of vCenter Appliance is done via browser pointing to the 5480 port. In my case I am accessing the external NATed IP: https://10.0.2.151:5480. Default login is ‘root’ and password ‘vmware’.
12. After accepting EULA on the Configure Options screen I set custom configuration
    
13. The I chose embedded database and embedded SSO and did not enable Active Directory.
14. After the vCenter Server service (together with database and SSO) is started (which takes a while) do not forget to change the default password and optionally disable not needed services.
    
15. Now we can register vCC Server with this newly deployed vCenter Server. As they are on the same org VDC network I am using vCenter internal IP address (192.168.1.2).
    
16. That’s it. Now we can download vSphere Client and connect to the external IP address of vCenter Server and access the vCloud Connector Plugin in the Solutions and Applications section of the vCenter home page.
    

Licensing

There is one catch. Unlike the standard edition of vCloud Connector, vCenter Server is a licensed product. We can use the evaluation version for 60 days but what happens then? It turns out that even with expired license of vCenter Server you can still access the vCloud Connector plugin. So from technical standpoint it is possible to use vCenter Server without a license with vCloud Connector. Not sure what are the legal implications though (IANAL).

vCloud Connector 2.0 Observations

I have been playing with vCloud Connector 2.0 which is already a third release of the tool that enables VM (vApp) transfers between various VMware clouds based on vSphere or vCloud Director. Here follows a bunch of notes that I came up with that might help others. Note I expect that the reader is familiar with basic functionality and architecture of vCC.

Compatibility

vCloud Connector 2.0 (vCC) is backward compatible with vCloud Director 1.5, however some advanced feature like Content Sync will work in such deployments with limitations (modified templates are not removed, but added instead with timestamp in the name) or will not work at all (Stretch Deploy). vCloud Connector 1.5 does not work with vCloud Director 5.1.

Architecture and Network Flows

The architecture is similar to vCC 1.5, but the ports have changed (port 8443 not needed anymore). Here is the picture from the Installing and Configuring vCC 2.0 guide and let me dive deeper into some of the network flows (black circled numbers).

Flow 1

Although vCC Server has a web interface (VAMI) available at port 5480, the interface can be used only for appliance configuration and setting up connectivity to vCC Nodes. Internet Explorer is recommended to use here as Firefox or Chrome did not display some VAMI interface parts properly. The vCC Advanced Edition license key is entered here and SSL certificates related to the vCC Client – vCC Server communications can be enabled or generated and uploaded here as well. VAMI interface always uses https (on port 5480) with self signed certificate by default that cannot be replaced via the GUI, but if required it can be replaced in the following file on the appliance:

/opt/vmware/etc/lighttpd/server.pem

vCC end-users will use either vSphere client (the .NET version, as web client is not supported yet) or vcloud.vmware.com portal for actual management of the vApp transfers and other vCC features.

Although the picture shows port 80, if SSL is enabled, 443 will be used instead. If the replaced certificates do not use intermediate CA, the web interface cannot be used for their import and java keytool command must be used instead from appliance CLI as described in the installation guide. For some reason I was not able to create the private key with the GUI, but java keytool did the job.

Flow 2

vCC Server needs to be able to reach all vCC Nodes so the arrow should be also between vCC Server and the vCC Node in the destination cloud. Again the communication can go over port 80 or 443 depending on SSL configuration – this time on the vCC Nodes. The same caveat as with Server applies when replacing the certificates.

Note: Enabling SSL is recommended here as discussed below.

Flows 3 and 6/7

Prior attaching vCC Nodes to vCC Server, the Nodes need to be configured to connect to a cloud (vCenter or vCloud Director). SSL (port 443) is always used, but if you do not want to enable the Ignore SSL Cert checkbox, vCenter or vCloud need to have CA signed certificates. If you are using enterprise CA, you have to import the CA root certificate to a different keystore than the one available in the GUI as described in KB 2045007.

Flow 5

For the inter node communication, one node is designated as the Controller. The Controller initiates the connection. Which node is picked as the Controller depends on the Public checkbox setting in the vCC Node registration at vCC Server.

Public vCC Node

It is expected that the non Public vCC node is unreachable from outside and therefore has to be the initiator of the communication between nodes and is therefore the Controller. So the Controller Node works either in push or pull mode. If the other Node has SSL enabled (see Flow 2), https port 443 is used for the transfer between nodes. If the other Node does not have SSL enabled the transfer will fail.

Shared Node

This is a new feature for vCloud Director deployments when the provider can deploy shared (multitenant) node and connect it to provider’s cloud. The tenants then do not have to deploy their own nodes inside their organization VDCs with all the troubles of securing connectivity and appropriate transfer storage.

In highly secure public clouds it gets tricky where and how to deploy the shared node. It cannot be load balanced, but provider can deploy multiple shared nodes and give their IP addresses only to specific groups of tenants. The node should be as close as possible to the vCloud API somewhere in DMZ accessible from the internet but if Web Application Firewall is used it should still be in-between the node and API as it could be used as an attack vector to other organizations. The node does not keep any vCloud credentials for communication with vCloud API. Those are transferred by vCC Server so again SSL should be enabled (see Flow 2).

Content Sync

This is a new feature, great for maintenance of catalogs in various clouds or might be also used by the provider for management of public catalog directly from vSphere where a vSphere folder is automatically synced with a vCloud Director catalog. Note however that vCC Advanced Edition license is needed which currently cannot be obtain with provider VSPP license, but only through vCloud Suite bundles.

The default polling interval for synchronization is 6 hours. It can be changed but the change is unsupported. Following file can be edited on the vCC Server:

/usr/local/tcserver/vfabric-tc-server-standard/server/webapps/agent/WEB-INF/spring/appServlet/task.xml

Look for <property name=”jobExecutionIntervalInMinutes” value=”360″ />.

Although the documentation states that ports 8443 and 8080 are used for Content Sync, my understanding is that they are used only internally on the vCC Server.

Stretch Deploy

This is again a new but licensed feature which enables migration of VMs between clouds without needing to change their IPs or MAC addresses thanks to a VPN connection (not VXLAN as often confused) which is established between the original and destination cloud. The SSL VPN is established between Edges on the vApp networks so this is quite different from the Site-to-Site IPSec VPN between Edge Gateways even though it shows up in vShield Manager in the IPSec VPN section. Its configuration is not exposed in the vCloud Director GUI at all.

Stretch Deploy Site-to-Site SSL VPN

There is quite a long list of prerequisites to get this working and some of them are out of tenant’s controls as they relate to the provider’s vCloud Director architecture – e.g. vSphere and vCloud Network and Security versions and type of distributed virtual switch used. Stretch Deploy will not work with Cisco Nexus 1000V switch. The tenant most likely will not know which switch the provider is using until he will experience following error:

Unable to update network “Stretched_VM_network”.
java.util.concurrent.ExecutionException: com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (100): A specified parameter was not correct.
selectionSet.dvsUuid

The source and transferred destination VMs need to be connected to vSphere Distributed Switch 5.1 as the unclaimed traffic needs to be sent over the SSL tunnel and this is not currently supported with other virtual switches.

The Stretch Deploy process is relatively complicated with many actions that are happening in the background. This is all abstracted from the user as he can start the process easily from vCC GUI. However if you want to end the stretch deploy by removing the remote VM, or bring it home back this must be done manually.

Stretch Deploy activities as seen by the vCenter (note both source and destination clouds were managed by the same vCenter)

Delete Stretch Deployed VM

• stop the remote vApp, this will terminate the VPN connection and destroy the vApp Edge
• delete the remote vApp
• delete the IPSec configuration in the vSphere cloud Edge in vShield Manager
• delete vCenter custom attributes of the VM which was stretched deployed (DatacenterExtendedEntityId, DatacenterExtensionRole)

Bring Home the Stretch Deployed VM

This must be done by running a script from the vCC Node managing the private cloud. So an access to the Node is needed, the script needs to be untared and quite a lot of information must be typed in when executed and their correctness is not verified until they are all typed in. This is definitely not task for an average user and I expect this part might be improved in later releases.