When looking for service providers for hosted infrastructure, some customers require dedicated infrastructure for their workloads. Whether the customer is looking for additional separation for security or more predictable performance of hosted workloads, service providers will need tools that enable them to provide dedicated hardware service for customers while reducing their operational overhead. In some scenarios, providers will implement managed vSphere environments for customers to satisfy this type of request and then manage the individual vSphere environments manually or with custom automation and orchestration tools. However, it is also possible to leverage vCloud Director to provide dedicated hardware per customer while also providing a central management platform for service providers to manage multiple tenants. In this post, we will explore how this can be accomplished with ‘out of the box’ functionality in vCloud Director.
In the previous post, we reviewed the preparation steps necessary for the installation of Cassandra for use with vCloud Availability. In this post we will complete the deployment by showing the steps necessary to install Cassandra and then configure Cassandra for secure communication as well as clustering the 3 nodes. This post assumes basic proficiency with the ‘vi’ text editor.
Installing & Configuring Cassandra
For this example, the Datastax version of Cassandra will be deployed. To prepare the server for Cassandra, create the datastax.repo file in the /etc/yum.repos.d directory with the following command:
Then input the Datastax repo details in to the file.
[datastax] name = DataStax Repo for Apache Cassandra baseurl = https://rpm.datastax.com/community enabled = 1 gpgcheck = 0
Once the repo details have been correctly entered, press the ESC key, type :wq! to write and exit the file.
With the recent release of vCloud Availability for vCloud Director 2.0, it seems like a good opportunity to review the steps for one of the key components required for its installation, the Cassandra database cluster. While the vCloud Availability installation provides a container based deployment of Cassandra, this container instance of Cassandra is only meant for ‘proof of concept’ deployments.
To support a production implementation of vCloud Availability, a fully clustered instance of Cassandra must be deployed with a recommend minimum of 3 nodes. This post will outline the steps for prepping the nodes for the installation of Cassandra. These preparation steps consist of:
- Installation of Java JDK 8
- Installation of Python 2.7
This post assumes basic proficiency with the ‘vi’ text editor.
Before deploying the Cassandra nodes for vCloud Availability, ensure that:
- All nodes have access to communicate with the vSphere Cloud Replication Service over ports 9160 and 9042.
- DNS is properly configured so that each node can successfully be resolved by the respective FQDN.
It is also worth mentioning that for this implementation, Cassandra does not require a load balancer as the vSphere Cloud Replication Service will automatically select an available node from the Cassandra cluster database communications.
In the previous blog post “Leveraging vRealize CloudClient with vRealize Automation deployments for vCAN”, we explored the use of VMware vRealize® CloudClient for the automated configuration of VMware vRealize Automation™ on a per-tenant basis to speed up the deployment of per-tenant instances in a service provider environment. This method relied on a manual installation of the vRealize Automation infrastructure components. However, the release of vRealize Automation 7.1 provides built-in silent installation capabilities for increased time-to-value deployments of vRealize Automation.
Overview of vRealize Automation for SPs
While vRealize Automation is typically implemented in Private Cloud – Enterprise environments, service providers still have an interest in providing services based on vRealize Automation for customers on a per-tenant basis as well as the management of the internal infrastructure. Customers benefit from this by experiencing an expedited time to value while also being able to offload the maintenance and management overhead of the Private Cloud infrastructure to a trusted VMware vCloud® Air™ Network service provider of their choice. Some of the common deployment models that service providers use for vRealize Automation are:
- Internal Operations – Single tenant deployment of vRealize Automation by the service provider for internal operations users.
- Dedicated Customer Private Cloud – Single tenant deployment of vRealize Automation with the optional use of multiple business groups. Customer manages user access and catalog content.
- Fully Managed Service Offering – Service offering that leverages multiple business groups and/or tenants and is managed fully by the vCloud Air Network service provider on behalf of the customer.
At a platform level, each of these models enables the consumption of single and multiple data centers provided by the service provider, while the Dedicated Private Cloud and the Managed Service offering provide customers the capability to consume on-premises compute resources.
As a number of vCloud Air Network service providers start to enhance their existing hosting offerings, VMware are seeing some demand from service providers to offer a dedicated vRealize Automation implementation to their end-customers to enable them to offer application services, heterogeneous cloud management and provisioning in a self-managed model.
This blog post details an implementation option where the vCloud Air Network service provider can offer “vRealize Automation as a Service” hosted in a vCloud Director vApp, with some additional automated configuration. This allows the service provider to offer vRealize Automation to their customers based out of their existing multi-tenancy IaaS platforms and achieve high levels of efficiency and economies of scale.
“vRealize Automation as a Service”
During a recent Proof of Concept demonstrating such a configuration, an vCloud Director Organizational vDC was configured for tenant consumption. Within this Org vDC a vApp containing a simple installation of vRealize Automation was deployed that consisted of a vRealize Automation Appliance and one Windows Server for IaaS components and an instance of Microsoft SQL. With vRealize Automation successfully deployed, the vRealize Automation instance was customized leveraging vRealize CloudClient via Microsoft PowerShell scripts. Using this method for configuration of the tenant within vRealize Automation reduced the deployment time for vRealize Automation instances while ensuring that the vRealize Automation Tenant configuration was consistent and conformed to the pre-determined naming standards and conventions required by the provider.
When migrating private cloud workloads to a public or hosted cloud provider, the methods used to facilitate customer onboarding can provide some of the most critical challenges. The cloud service provider requires a method for onboarding tenants that reduces the need for additional equipment or contracts that often create barriers for customers when moving enterprise workloads onto a hosting or public cloud offering.
Customer Onboarding Scenarios
When a service provider is preparing for customer onboarding, there are a few options that can be considered. Some of the typical onboarding scenarios are:
- Migration of live workloads
- Offline data transfer of workloads
- Stretching on-premises L2 networks
- Remote site and user access to workloads
One of the most common scenarios is workload migration. For some implementations, this means migrating private cloud workloads to a public cloud or hosted service provider’s infrastructure. One path to migration leverages VMware vSphere® vMotion® to move live VMs from the private cloud to the designated CSP environment. In situations where this is not feasible, service providers can supply options for the offline migration of on-premises workloads where private cloud workloads that are marked for migration are copied to physical media, shipped to the service provider, and then deployed within the public cloud or hosted infrastructure. In some cases, migration can also mean the ability to move workloads between private cloud and CSP infrastructure on demand.