An interesting topic that came to our attention is how to migrate VMware vCloud Director® vApps from one distributed virtual switch to another. Recently, from the experience of one of our field consultants, Aleksander Bukowinski, we received a detailed procedure to overcome the possible service disruptions due to such a move. Aleksander has also authored a whitepaper on this topic that will soon be available for our audience in VMware Partner Central. The paper also covers in detail an additional use case with Cisco Nexus 1000V and provides PowerShell and API call samples.
Depending on connectivity mode, we can have five different types of vApps in vCD: directly connected, routed, connected to routed vApp networks, isolated, and fenced. The migration process would not require shutting down the vApps while the migration happens, but rather could generate brief network outages in case the VMs are connected to a vCloud Director Edge Gateway, or no outage at all if the VMs use isolated networks with no dependency to the Edge. Continue reading →
VMware vRealize Operations™ is a key component of a vCloud Air Network powered cloud service offering. It provides a simplified yet extensible approach to operations management of the cloud infrastructure. It helps service providers maximize profitability by optimizing efficiency and differentiates their service offerings by increasing customer satisfaction and delivering to SLAs.
VMware vRealize Operations also enables service providers to generate new revenue streams by expanding their footprint to offer VMware vRealize Operations™ as a service to give their tenants a deeper insight in to the health, capacity and performance of their hosted environments.
This can either be delivered on a dedicated per-tenant basis as part of a private cloud solution offering alternatively the vCAN Service Provider can offer a shared vRealize Operations™ platform as a managed service.
In this scenario, the service provider operates a centralized vRealize Operations Manager instance to collect all data generated by the resource cluster. Both service provider personnel and tenants will access the same instance of vRealize Operations, and data access will be controlled with RBAC. This scenario allows for easy management and deployment.
This approach is especially attractive for service providers who can operate their complete environment within one vRealize Operations Manager environment.
Advantages include the following:
Easy to deploy and manage
No additional data/configuration distribution for dashboards, policies, and so on is needed
Only one instance to maintain (software updates, management packs, and so on)
Disadvantages involve the following:
Role-based access control requires careful maintenance
Objects can only be operated under one policy, removing the ability to limit alert visibility for a customer/tenant
Sizing can get complex and larger environments could be limited by sizing parameters. A possible workaround could be to build instances per larger resource group.
This is just one way a vCloud Air Network provider can differentiate their service portfolio with vRealize Operations™ by extending the consumption to your end-customers as a managed service.
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 →
This has been an exciting time for the IT industry. At VMworld US 2016 (August 29th 2015) we had the announcement of VMware Cloud Foundation becoming an integral part of IBM SoftLayer and then we had the news of the strategic partnership with Amazon Web Services (AWS) and VMware (October 13th 2016). VMware Cloud Foundation is a shift in cloud infrastructure that enables the Software Defined Data Center (SDDC). This is significant because what we know as the SDDC, with technology such as VMware Horizon, NSX and Virtual SAN, can now be consumed and offered by service providers in a unique way.
At the core is SDDC Manager and lifecycle management (LCM) which allows a fully automated deployment, configuration and patching & upgrades. But what does the architecture look like behind VMware Cloud Foundation? Let’s take a closer look. 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.
Since I published the Horizon 7 Network Ports diagram with the latest release of Horizon 7, I’ve been frequently asked about the connection flow between the Horizon Client and the virtual desktop. VMware Horizon supports RDP, PCoIP and now Blast Extreme. I’ll start with PCoIP and then we’ll look at Blast Extreme.
The connection flow of the Horizon Client is largely the same with Horizon 7, Horizon Air or Horizon DaaS. There may be differences in external load-balancing, Security Server or Access Point, and external URL configuration, but for this post I’ll focus on the Horizon Client itself and the aforementioned protocols.
A colleague asked me a very good question which I’d also like to address. How does Access Point know which VM to connect to?
Access Point doesn’t need to know which ESXi host is running the VM. When the entitled desktops are returned to the client(see 1b below) it also receives the external URL of the Access Point appliance, this is where the Horizon Client > Access Point connection is established on HTTPS (TCP 443). This could be a VIP on the load-balancer, or an external facing IP for each of the Access Point appliances, depending on the configuration (see Method 3 of Mark’s article).
When the user launches the chosen desktop pool, Access Point will communicate on HTTPS (TCP 443) to receive the desktop IP from the Connection server. The role of the PCoIP Gateway on the Access Point appliance is to then forward the PCoIP connection to the IP address of the Horizon Agent.
Note: In the past, Security Server used JMS, IPsec and AJP13, but Access Point doesn’t use these protocols (JMS is still used on the Connection Servers). If you refer to my Horizon 7 Network Ports diagram, you’ll see I’ve put these in a dotted line to show this.
When looking at the adoption of public or hybrid cloud, one of the primary considerations must be how to migrate existing workloads to the target platform. Choosing the right migration tool(s) will prove critical in the coaching of customers, mainly their IT and application owners, to address this challenge. There are many VMware vCloud® Air™ Network architectures that can provide workload mobility where capabilities, like hybrid cloud networking enabled by VMware NSX®, and other solutions, such as VMware Site Recovery Manager™, might be in place. Enterprise migration technologies however, span a much broader scope than that of moving applications hosted on physical or virtual infrastructure to a cloud architecture. Specifically, these tools address the enterprise architecture features required to discover, plan, and execute migration, while allowing for scheduling and systems level dependencies.
VMware offers tools that address many of these needs and some have been described in the VMware vCloud Architecture Toolkit™ for Service Providers (vCAT-SP) blog and white paper. As stated in the vCAT-SP documentation for migration, offerings will not meet all requirements for migrating workloads to the cloud, and the purpose of this series of blogs is to allow VMware Technology Partners to discuss their solutions and advocate for why they might be the best choice in many situations. Many standard forms of analysis will apply to the evaluation of enterprise migration technologies, including common items such as pricing, support, or strategic direction. This series of blogs will focus on the more technical aspects, such as ease of deployment/usage, versatility, reliability, scalability, and security. The blog entries will also cover optimal use cases addressed by the partner solutions, often with customer references.
The first blog in this series is with VMware Technology Partner ATADATA. In particular, their enterprise migration solution focusing on their ATAvision and ATAmotion products. The combination of these two offerings fits into the “Discover & Assess, Job Scheduling, Workload Migration, Application Verification” lifecycle described in the blog and vCAT-SP documentation referenced above. The first three letters of the ATADATA name are an acronym for “any to any” and their deployment model, shown in the following figure, indicates their abstraction from the underlying physical, virtual, or cloud infrastructures that are part of an enterprise migration. This capability enables their technology to not only support many platforms (see ATADATA supported platforms), but to provide a consistent abstraction of underlying details for migrating between sources and targets of any supported type. Continue reading →
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.
In part 1 of this blog series, I discussed the Horizon 7 architecture and a typical single-tenant deployment using Pods and Blocks. In this post I will discuss the Horizon DaaS platform architecture and how this offers massive scale for multiple tenants in a service provider environment.
Horizon DaaS Architecture
The fundamental difference with the Horizon DaaS platform is multi-tenancy architecture. There are no Connection or Security servers, but there are some commonalities. I mentioned Access Point previously, this was originally developed for Horizon Air, and is now a key component for both Horizon 7 and DaaS for remote access.
If you take a look at the diagram above you’ll see these key differences. Let’s start with the management appliances. Continue reading →