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.
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 this blog we will run though how to use the vCloud Air Network vCloud Availability for vCloud Director Calculator to see how a multi tier DR solution could benefit your business. It has been created to provide indicative revenues and margins based on a multi-tiered Disaster Recovery solution using vCloud Air Network vCloud Availability for vCloud Director as the middle tier option.
Please access the calculator at the Partner Central link: “vCloud Air Network Services IP”
In the sheet called CapEx modelling you can change any cell highlighted GREY and with Bold Red Text
- Input your number of VM for Premium / Standard and Basic Tiers of Disaster Recovery Service.
- Input the approximate number of virtual CPU (vCPU), virtual RAM (vRAM) and storage for each VM in each Tier
- Input the contention ratio of compute (vCPU) for each tier, usually the lower the service, the higher it is contented with other resources.
Among the many challenges an organization and its IT department confront on a daily basis, availability of services is particularly critical for the survival of the businesses that entrust and rely on the technologies on which their services have been built. At the same time, several legislations across different countries are creating continuous pressure on each and every organization to maintain an appropriate plan to protect and secure their data and their services.
Historically, every large enterprise has planned and built its own approach to face a disaster of small or large proportions in the most suitable way for their businesses: backups, hardware redundancy, host clustering, data mirroring, replication, geographically distributed sites, and so on, are just few identifiers for technologies and strategies to build a solution trying to address the problem.
Over the years, some of these technologies have been commoditized. Still for some of them, the financial burden to allow their implementation has been an overwhelming capital expense for many medium and small organizations. In addition, expertise is required to manage and organize the software, hardware, and storage components involved.
In this context, a great opportunity for cloud service providers has materialized. The market has increased its confidence in using cloud-based services offering a more cost-effective (subscription based) access to resources. Disaster recovery as a service (DRaaS) is a highly desirable service to offer to all organizations, but particularly for the ones that might have concerns or financial exposures caused by planning and building their own secondary data center site to make their services more robust and resilient to local disasters. Continue reading
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.