Home > Blogs > VMware Consulting Blog > Tag Archives: vSphere

Tag Archives: vSphere

Hybrid Cloud Manager Deployment Considerations

by Michael Francis

VMware Hybrid Cloud Manager™ is VMware’s management extension for VMware vSphere® and VMware vCloud® Air™. Hybrid Cloud Manager aims to simplify the implementation of a true hybrid cloud.

My Definition of Hybrid Cloud

What is hybrid cloud? In my mind, hybrid cloud means extending my on-premises estate into a data center facility owned and provided by a third party. The key to this definition is in the word “extension.” A true extension means I can retain my existing operating model, security model, and provisioning systems and seamlessly migrate applications from my on-premises environment to my provider’s platform, just as I do within my on-premises environment.

Continue reading

BCDR: Some Things to Consider When Upgrading Your VMware Disaster Recovery Solution

Julienne_PhamBy Julienne Pham

Once upon a time, you protected your VMs with VMware Site Recovery Manager, and now you are wondering how to upgrade your DR solution with minimum impact on the environment. Is it as seamless as you think?

During my days in Global Support and working on customer Business Continuity/Disaster Recovery (BCDR) projects, I found it intriguing how vSphere components can put barriers in an upgrade path. Indeed, one of the first things I learned was that timing and the update sequence of my DR infrastructure was crucial to keep everything running, and with as little disruption as possible.

Here If we look more closely, this is a typical VMware Site Recovery Manager setup:

JPham_SRM 6x

And in a pyramid model, we have something like this:

JPham_SRM Pyramid

Example of a protected site

So, where do we start our upgrade?

Upgrade and maintain the foundation

You begin with the hardware. Then, the vSphere version you are upgrading to. You’ll see a lot of new features available, along with bug fixes, so your hardware and firmware might need some adjustments to support new features and enhancements. It is important at a minimum to check the compatibility of the hardware and software you are upgrading to.

In a DR scenario, it is important to check storage replication compliance

This is where you ensure your data replicates according to your RPO.

If you are using vSphere Replication or Storage Array Replication, you should check the upgrade path and the dependency with vSphere and SRM.

  • As an example, VR cannot be upgraded directly from 5.8 to 6.1
  • You might need to update the Storage Replication Adaptor too.
  • You can probably find other examples of things that won’t work, or find work-arounds you’ll need.
  • You can find some useful information in the VMware Compatibility Guide

Architecture change

If you are looking to upgrade from vSphere 5.5 to 6.1, for example, you should check if you need to migrate from a simple SSO install to an external one for more flexibility, as you might not be able to change in the future. As VMware SRM is dependent on the health of vCenter, you might be better off looking first into upgrading this component as a prerequisite.

Before you start you might want to check out the informative blog, “vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 1.”

The sites are interdependent

Once the foundation path is planned out, you have to think about how to minimize business impact.

Remember that if your protected site workload is down, you can always trigger a DR scenario, so it is in your best interest to keep the secondary site management layer fully functional and upgrade VMware SRM and vCenter at the last resort.

VMware upgrade path compatibility

Some might assume that you can upgrade from one version to another without compatibility issues coming up. Well, to avoid surprises, I recommend looking into our compatibility matrix, and validate the different product version upgrade paths.

For example, the upgrade of SRM 5.8 to 6.1 is not supported. So, what implications might be related to vCenter and SRM compatibility during the upgrade?

JPham_Upgrade Path Sequence

Back up, back up, back up

The standard consideration is to run backups before every upgrade. A snapshot VM might not be enough in certain situations if you are in different upgrade stages at different sites. You need to carefully plan and synchronise all different database instances for VMware Site Recovery Manager and vCenter—at both sites and eventually vSphere Replication databases.

I hope this addresses some of the common questions and concerns that might come up when you are thinking of upgrading SRM. Planning and timing are key for a successful upgrade. Many components are interdependent, and you need to consider them carefully to avoid an asynchronous environment with little control over outcomes. Good luck!


Julienne Pham is a Technical Solution Architect for the Professional Services Engineering team. She is specialised on SRM and core storage. Her focus is on VIO and BCDR space.

Virtualization and VMware Virtual SAN … the Old Married Couple

Don’t Mistake These Hyper-Converged Infrastructure Technologies as Mutually Exclusive

Jonathan McDonaldBy Jonathan McDonald

I have not posted many blogs recently as I’ve been in South Africa. I have however been hard at work on the latest release of VMware vSphere 6.0 Update 2 and VMware Virtual SAN 6.2. Some amazing features are included that will make life a lot easier and add some exciting new functionality to your hyper-converged infrastructure. I will not get into these features in this post, because I want to talk about one of the bigger non-technical questions that I get from customers and consultants alike. This is not one that is directly tied to the technology or architecture of the products. It is the idea that you can go into an environment and just do Virtual SAN, which from my experience is not true. I would love to know if your thoughts and experiences have shown you the same thing.

Let me first tell those of you who are unaware of Virtual SAN that I am not going to go into great depth about the technology. The key is that, as a platform, it is hyper-converged, meaning it is included with the ESXi hypervisor. This makes it radically simple to actually configure—and, more importantly, use—once it is up and running.

My hypothesis is that 80 to 90% of what you have to do to design for Virtual SAN focuses on the Virtualization design, and not so much on Virtual SAN.  This is not to say the Virtual SAN design is not important, but virtualization has to be integral to the design when you are building for it. To prove this, take a look at what the standard tasks are when creating the design for the environment:

  1. Hardware selection, racking, configuration of the physical hosts
  2. Selection and configuration of the physical network
  3. Software installation of the VMware ESXi hosts and VMware vCenter server
  4. Configuration of the ESXi hosts
    • Networking (For management traffic, and for VMware vSphere vMotion, at a minimum)
    • Disks
    • Features (VMware vSphere High Availability, VMware vSphere Distributed Resource Scheduler, VMware vSphere vMotion, at a minimum)
  5. Validation and testing of the configuration

If I add the Virtual SAN-specific tasks in, you have a holistic view of what is required in most greenfield configurations:

  1. Configuration of the Virtual SAN network
  2. Turning on Virtual SAN
  3. Creating new policies (optional, as the default is in place once configured)
  4. Testing Virtual SAN

As you can see, my first point shows that the majority of the work is actually virtualization and not Virtual SAN. In fact, as I write this, I am even more convinced of my hypothesis. The first three tasks alone are really the heavy hitters for time spent. As a consultant or architect, you need to focus on these tasks more than anything. Notice above where I mention “configure” in regards to Virtual SAN, and not installation; this is because it is already a hyper-converged element installed with ESXi. Once you get the environment up and running with ESXi hosts installed, Virtual SAN needs no further installation, simply configuration. You turn it on with a simple wizard, and, as long as you have focused on the supportability of the hardware and the underlying design, you will be up and running quickly. Virtual SAN is that easy.

Many of the arguments I get are interesting as well. Some of my favorites include:

  • “The customer has already selected hardware.”
  • “I don’t care about hardware.”
  • “Let’s just assume that the hardware is there.”
  • “They will be using existing hardware.”

My response is always that you should care a great deal about the hardware. In fact, this is by far the most important part of a Virtual SAN engagement. With Virtual SAN, if the hardware is not on the VMware compatibility list, then it is not supported. By not caring about hardware, you risk data loss and the loss of all VMware support.

If the hardware is already chosen, you should ensure that the hardware being proposed, added, or assumed as in place is proper. Get the bill of materials or the quote, and go over it line-by-line if that’s what’s needed to ensure that it is all supported.

Although the hardware selection is slightly stricter than with an average design, it is much the same as any traditional virtualization engagement in how you come to the situation. Virtual SAN Ready nodes are a great approach and make this much quicker and simpler, as they offer a variety of pre-configured hardware to meet the needs of Virtual SAN. Along with the Virtual SAN TCO Calculator it makes the painful process of hardware selection a lot easier.

Another argument I hear is “If I am just doing Virtual SAN, that is not enough time.” Yes, it is. It really, really is. I have been a part of multiple engagements for which the first five tasks above are already completely done. All we have to do is come in and turn on Virtual SAN. In Virtual SAN 6.2, this is made really easy with the new wizard:

JMcDonald_Configure VSAN

Even with the inevitable network issues (not lying here; every single time there is a problem with networking), environmental validation, performance testing, failure testing, testing virtual machine creation workflows, I have never seen it take more than a week to do this piece for a single cluster regardless of size of configuration. In many cases, after three days, everything is up and running and it is purely customer validation that is taking place. As a consultant or architect, don’t be afraid of the questions customers ask in regards to performance and failures. Virtual SAN provides mechanisms to easily test the environment as well as see as what “normal” is.

Here are two other arguments I hear frequently:

  • “We have never done this before.”
  • “We don’t have the skillset.”

These claims are probably not 100% accurate. If you have used VMware, or you are a VMware administrator, you are probably aware of the majority of what you have to do here. For Virtual SAN, specifically, this is where the knowledge needs to be grown. I suggest a training, or a review of VMworld presentations for Virtual SAN, to get familiar with this piece of technology and its related terminology. VMware offers training that will get you up to speed on hyper-converged infrastructure technologies, and the new features of VMware vSphere 6.0 Update Manager 2 and Virtual SAN 6.2.

For more information about free learnings, check out the courses below:

In addition, most of the best practices you will see are not unfamiliar since they are vCenter- or ESXi-related. Virtual SAN Health gives an amazing overview that is frequently refreshed, so any issues you may be seeing are reported here; this also takes a lot of the guess work out of the configuration tasks as you can see from the screenshot below, as many, if not all of, the common misconfigurations are shown.

JMcDonald_VSAN Health

In any case, I hope I have made the argument that Virtual SAN is mostly a virtualization design that just doesn’t use traditional SANs for storage.  Hyper-converged infrastructure is truly bringing change to many customers. This is, of course, just my opinion, and I will let you judge for yourself.

Virtual SAN has quickly become one of my favorite new technologies that I have worked with in my time at VMware, and I am definitely passionate about people using it to change the way they do business. I hope this helps in any engagements that you are planning as well as to prioritize and give a new perspective to how infrastructure is being designed.


Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments

Configuring NSX-v Load Balancer for use with vSphere Platform Services Controller (PSC) 6.0

Romain DeckerBy Romain Decker

VMware introduced a new component with vSphere 6, the Platform Services Controller (PSC). Coupled with vCenter, the PSC provides several core services, such as Certificate Authority, License service and Single Sign-On (SSO).

Multiple external PSCs can be deployed serving one (or more) service, such as vCenter Server, Site Recovery Manager or vRealize Automation. When deploying the Platform Services Controller for multiple services, availability of the Platform Services Controller must be considered. In some cases, having more than one PSC deployed in a highly available architecture is recommended. When configured in high availability (HA) mode, the PSC instances replicate state information between each other, and the external products (vCenter Server for example) interact with the PSCs through a load balancer.

This post covers the configuration of an HA PSC deployment with the benefits of using NSX-v 6.2 load balancing feature.

Due to the relationship between vCenter Server and NSX Manager, two different scenarios emerge:

  • Scenario A where both PSC nodes are deployed from an existing management vCenter. In this situation, the management vCenter is coupled with NSX which will configure the Edge load balancer. There are no dependencies between the vCenter Server(s) that will use the PSC in HA mode and NSX itself.
  • Scenario B where there is no existing vCenter infrastructure (and thus no existing NSX deployment) when the first PSC is deployed. This is a classic “chicken and egg” situation, as the NSX Manager that is actually responsible for load balancing the PSC in HA mode is also connected to the vCenter Server that use the PSC virtual IP.

While scenario A is straightforward, you need to respect a specific order for scenario B to prevent any loss of connection to the Web client during the procedure. The solution is to deploy a temporary PSC in a temporary SSO site to do the load balancer configuration, and to repoint the vCenter Server to the PSC virtual IP at the end.

Please note that scenario B is only supported with vSphere 6.0 as repointing a vCenter between sites in a SSO domain is no longer supported in vSphere 6.5 (KB 2131191).

Both scenario steps are summarized in the workflow below.

RDecker PSC Map

Environment

NSX Edge supports two deployment modes: one-arm mode and inline mode (also referred to as transparent mode). While inline mode is also possible, NSX load balancer will be deployed in a one-arm mode in our situation, as this model is more flexible and because we don’t require full visibility into the original client IP address.

Description of the environment:

  • Software versions: VMware vCenter Server 6.0 U1 Appliance, ESXi 6.0 U1, NSX-v 6.2
  • NSX Edge Services Gateway in one-arm mode
  • Active/Passive configuration
  • VLAN-backed portgroup (distributed portgroup on DVS)
  • General PSC/vCenter and NSX prerequisites validated (NTP, DNS, resources, etc.)

To offer SSO in HA mode, two PSC servers have to be installed with NSX load balancing them in active/standby mode. PSC in Active/Active mode is currently not supported by PSC.

The way SSO operates, it is not possible to configure it as active/active. The workaround for the NSX configuration is to use an application rule and to configure two different pools (with one PSC instance in each pool). The application rule will send all traffic to the first pool as long as the pool is up, and will switch to the secondary pool if the first PSC is down.

The following is a representation of the NSX-v and PSC logical design.

RDecker PSC NSX

Procedure

Each step number refers to the above workflow diagram. You can take snapshots at regular intervals to be able to rollback in case of a problem.

Step 1: Deploy infrastructure

This first step consists of deploying the required vCenter infrastructure before starting the configuration.

A. For scenario A: Deploy two PSC nodes in the same SSO site.

B. For scenario B:

  1. Deploy a first standalone Platform Services Controller (PSC-00a). This PSC will be temporary used during the configuration.
  2. Deploy a vCenter instance against the PSC-00a just deployed.
  3. Deploy NSX Manager and connect it to the vCenter.
  4. Deploy two other Platform Services Controllers in the same SSO domain (PSC-01a and PSC-02a) but in a new site. Note: vCenter will still be pointing to PSC-00a at this stage. Use the following options:
    RDecker PSC NSX Setup 1RDecker PSC NSX Setup 2

Step 2 (both scenarios): Configure both PSCs as an HA pair (up to step D in KB 2113315).

Now that all required external Platform Services Controller appliances are deployed, it’s time to configure high availability.

A. PSC pairing

  1. Download the PSC high availability configuration scripts from the Download vSphere page and extract the content to /ha on both PSC-01a and PSC-02a nodes. Note: Use the KB 2107727 to enable the Bash shell in order to copy files in SCP into the appliances.
  2. Run the following command on the first PSC node:
    python gen-lb-cert.py --primary-node --lb-fqdn=load_balanced_fqdn --password=<yourpassword>

    Note: The load_balanced_fqdn parameter is the FQDN of the PSC Virtual IP of the load balancer. If you don’t specify the option –password option, the default password will be « changeme ».
    For example:

    python gen-lb-cert.py --primary-node --lb-fqdn=psc-vip.sddc.lab --password=brucewayneisbatman
  3. On the PSC-01a node, copy the content of the directory /etc/vmware-sso/keys to /ha/keys (a new directory that needs to be created).
  4. Copy the content of the /ha folder from the PSC-01a node to the /ha folder on the additional PSC-02a node (including the keys copied in the step before).
  5. Run the following command on the PSC-02a node:
python gen-lb-cert.py --secondary-node --lb-fqdn=load_balanced_fqdn --lb-cert-folder=/ha --sso-serversign-folder=/ha/keys

Note: The load_balanced_fqdn parameter is the FQDN of the load balancer address (or VIP).

For example:

python gen-lb-cert.py --secondary-node --lb-fqdn=psc-vip.sddc.lab --lb-cert-folder=/ha --sso-serversign-folder=/ha/keys

Note: If you’re following the KB 2113315 don’t forget to stop the configuration here (end of section C in the KB).

Step 3: NSX configuration

An NSX edge device must be deployed and configured for networking in the same subnet as the PSC nodes, with at least one interface for configuring the virtual IP.

A. Importing certificates

Enter the configuration of the NSX edge services gateway on which to configure the load balancing service for the PSC, and add a new certificate in the Settings > Certificates menu (under the Manage tab). Use the content of the previously generated /ha/lb.crt file as the load balancer certificate and the content of the /ha/lb_rsa.key file as the private key.

RDecker PSC Certificate Setup

B. General configuration

Enable the load balancer service and logging under the global configuration menu of the load balancer tab.

RDecker PSC Web Client

C. Application profile creation

An application profile defines the behavior of a particular type of network traffic. Two application profiles have to be created: one for HTTPS protocol and one for other TCP protocols.

Parameters HTTPS application profile TCP application profile
Name psc-https-profile psc-tcp-profile
Type HTTPS TCP
Enable Pool Side SSL Yes N/A
Configure Service Certificate Yes N/A

Note: The other parameters shall be left with their default values.

RDecker PSC Edge

D. Creating pools

The NSX load balancer virtual server type HTTP/HTTPS provide web protocol sanity check for their backend servers pool. However, we do not want that sanity check their backend servers pool for the TCP virtual server. For that reason, different pools must be created for the PSC HTTPS virtual IP and TCP virtual IP.

Four pools have to be created: two different pools for each virtual server (with one PSC instance per pool). An application rule will be defined to switch between them in case of a failure: traffic will be send to the first pool as long as the pool is up, and will switch to the secondary pool if the first PSC is down.

Parameters Pool 1 Pool 2 Pool 3 Pool 4
Name pool_psc-01a-http pool_psc-02a-http pool_psc-01a-tcp pool_psc-02a-tcp
Algorithm ROUND-ROBIN ROUND-ROBIN ROUND-ROBIN ROUND-ROBIN
Monitors default_tcp_monitor default_tcp_monitor default_tcp_monitor default_tcp_monitor
Members psc-01a psc-02a psc-01a psc-02a
Monitor Port 443 443 443 443

Note: while you could use a custom HTTPS healthcheck, I selected the default TCP Monitor in this example.

RDecker PSC Edge 2 (Pools)

E. Creating application rules

This application rule will contain the logic that will perform the failover between the pools (for each virtual server) corresponding to the active/passive behavior of the PSC high availability mode. The ACL will check if the primary PSC is up; if the first pool is not up the rule will switch to the secondary pool.

The first application rule will be used by the HTTPS virtual server to switch between the corresponding pools for the HTTPS backend servers pool.

# Detect if pool "pool_psc-01a-http" is still UP
acl pool_psc-01a-http_down nbsrv(pool_psc-01a-http) eq 0
# Use pool " pool_psc-02a-http " if "pool_psc-01a-http" is dead
use_backend pool_psc-02a-http if pool_psc-01a-http_down

The second application rule will be used by the TCP virtual server to switch between the corresponding pools for the TCP backend servers pool.

# Detect if pool "pool_psc-01a-tcp" is still UP
acl pool_psc-01a-tcp_down nbsrv(pool_psc-01a-tcp) eq 0
# Use pool " pool_psc-02a-tcp " if "pool_psc-01a-tcp" is dead
use_backend pool_psc-02a-tcp if pool_psc-01a-tcp_down

RDecker PSC Edge 3 (app rules)

F. Configuring virtual servers

Two virtual servers have to be created: one for HTTPS protocol and one for the other TCP protocols.

Parameters HTTPS Virtual Server TCP Virtual Server
Application Profile psc-https-profile psc-tcp-profile
Name psc-https-vip psc-tcp-vip
IP Address IP Address corresponding to the PSC virtual IP
Protocol HTTPS TCP
Port 443 389,636,2012,2014,2020*
Default Pool pool_psc-01a-http pool_psc-01a-tcp
Application Rules psc-failover-apprule-http psc-failover-apprule-tcp

* Although this procedure is for a fresh install, you could target the same architecture with SSO 5.5 being upgraded to PSC. If you plan to upgrade from SSO 5.5 HA, you must add the legacy SSO port 7444 to the list of ports in the TCP virtual server.

RDecker PSC Edge 4 (VIP)

Step 4 (both scenarios)

Now it’s time to finish the PSC HA configuration (step E of KB 2113315). Update the endpoint URLs on PSC with the load_balanced_fqdn by running this command on the first PSC node.

python lstoolHA.py --hostname=psc_1_fqdn --lb-fqdn=load_balanced_fqdn --lb-cert-folder=/ha --user=Administrator@vsphere.local

Note: psc_1_fqdn is the FQDN of the first PSC-01a node and load_balanced_fqdn is the FQDN of the load balancer address (or VIP).

For example:

python lstoolHA.py --hostname=psc-01a.sddc.lab --lb-fqdn=psc-vip.sddc.lab --lb-cert-folder=/ha --user=Administrator@vsphere.local

Step 5

A. Scenario A: Deploy any new production vCenter Server or other components (such as vRA) against the PSC Virtual IP and enjoy!

B. Scenario B

Please note that scenario B is only supported with vSphere 6.0 as repointing a vCenter between sites in a SSO domain is no longer supported in vSphere 6.5 (KB 2131191).

The situation is the following: The vCenter is currently still pointing to the first external PSC instance (PSC-00a), and two other PSC instances are configured in HA mode, but are not used.

RDecker Common SSO Domain vSphere

Introduced in vSphere 6.0 Update 1, it is now possible to move a vCenter Server between SSO sites within a vSphere domain (see KB 2131191 for more information). In our situation, we have to re-point the existing vCenter that is currently connected to the external PSC-00a to the PSC Virtual IP:

  1. Download and replace the cmsso-util file on your vCenter Server using the actions described in the KB 2113911.
  2. Re-point the vCenter Server Appliance to the PSC virtual IP to the final site by running this command:
/bin/cmsso-util repoint --repoint-psc load_balanced_fqdn

Note: The load_balanced_fqdn parameter is the FQDN of the load balancer address (or VIP).

For example:

/bin/cmsso-util repoint --repoint-psc psc-vip.sddc.lab

Note: This command will also restart vCenter services.

  1. Move the vCenter services registration to the new SSO site. When a vCenter Server is installed, it creates service registrations that it issues to start the vCenter Server services. These service registrations are written to a specific site of the Platform Services Controller (PSC) that was used during the installation. Use the following command to update the vCenter Server services registrations (parameters will be asked at the prompt).
/bin/cmsso-util move-services

After the command, you end up with the following.

RDecker PSC Common SSO Domain vSphere 2

    1. Log in to your vCenter Server instance by using the vSphere Web Client to verify that the vCenter Server is up and running and can be managed.

RDecker PSC Web Client 2

In the context of the scenario B, you can always re-point to the previous PSC-00a if you cannot log, or if you have an error message. When you have confirmed that everything is working, you can remove the temporary PSC (PSC-00a) from the SSO domain with this command (KB 2106736​):

cmsso-util unregister --node-pnid psc-00a.sddc.lab --username administrator@vsphere.local --passwd VMware1!

Finally, you can safely decommission PSC-00a.

RDecker PSC Common SSO Domain vSphere 3

Note: If your NSX Manager was configured with Lookup Service, you can update it with the PSC virtual IP.

Resources:


Romain Decker is a Senior Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) portfolio – a part of the Global Technical & Professional Solutions (GTPS) team.

How NSX Simplifies and Enables True Disaster Recovery with Site Recovery Manager

Dharma RajanBy Dharma Rajan

VMware Network Virtualization Platform (NSX) is the network virtualization platform for the software-defined datacenter (SDDC). Network virtualization using VMware NSX enables virtual networks to be created as software entities, saved and restored, and deleted on demand without requiring any reconfiguration of the physical network. Logical network entities like logical switch, logical routers, security objects, logical load balancers, distributed firewall rules and service composer rules are created as part of virtualizing the network.

To provide continuity of service from disaster recovery (DR), datacenters are built with capabilities for replicating and recovering workloads between protected and recovery sites. VMware Site Recovery Manager (SRM) helps to fully automate the recovery process.

From a DR point the recovery site has to be in synch with the protected site at all times from a compute, storage and networking point of view to enable seamless fast recovery when the protected site fails due to a disaster. When using SRM today for DR there are a couple of challenges customers face. From a compute perspective one needs to prepare the host at the recovery site, pre-allocate compute capacity for placeholder virtual machines and create placeholder virtual machines themselves.

From a storage point, the storage for protected applications/virtual machines needs to be replicated and kept in synch. Both of these steps are easy and has been handled by SRM-, vSphere- and/or Array-based replication. The challenge today is the networking piece of the puzzle. As illustrated below, depending on the type of networking established between protected and recovery site, various networking changes (carve out Layer-2, Layer-3, Firewall, Load balancer policy in recovery site, re-map of network if IP address space overlap, recreate policies, etc.) may have to be manually done to ensure smooth recovery. This adds a lot of time, subject to human error in making the changes, inability to meet internal and external SLA. The result of this is the network is the bottleneck that prevents seamless disaster recovery. From a business perspective this can easily translate into millions of dollars in business loss based on criticality of workloads/services impacted.

DRajan 1

Why Are We Running into the Networking Challenge?

The traditional DR solution is tied tightly to physical infrastructure (physical routers, switches, firewalls, load balancers). The security domains of the protected and recovery sites are completely separate. As networking changes, be it new adds, delete, updates are made (say IP address, Layer-2 extension changes, subnets, etc.) at the protected site, no corresponding automated synchronization happens at the recovery site. Thus one may have to do Layer-2 extension to preserve the changes, create and maintain special scripts, manage the tools, and perform manual DR setup and recovery steps across different infrastructure layers and vendors (physical and virtual). From a process point it requires coordination across various teams within your company, good bookkeeping and periodic validation, so you are always ready to address a DR scenario as quickly as you can.

What is the Solution?

VMware NSX from release 6.2 offers a solution that enables customers to address the above-cited networking challenges. NSX is the network virtualization platform for the SDDC. NSX provides the basic foundation to virtualize networking components in the form of logical switching, distributed logical router, distributed logical firewall, logical load balancer, and logical edge gateways. For a deeper understanding of NSX see more at: http://www.vmware.com/products/nsx

NSX 6.2 release has been integrated with SRM 6.1 to enable automated replication of networking entities between protected and recovery sites.

DRajan 2

How Does the Solution Work?

NSX 6.2 supports a couple of key concepts that will intelligently understand that it is logically the same network on both sites. These concepts include:

  1. a) “Universal Logical Switches” (ULS) – This allows for the creation of Layer-2 networks that span vCenter boundaries. This means that when utilizing ULS with NSX there will be a virtual port group at both the protected and recovery site that connect to the same Layer-2 network. When virtual machines are connected to port groups that are backed by ULS, SRM implicitly creates a network mapping, without requiring the admin to configure it. Providing seamless network services portability and synchronization automatically reconnects virtual machines connected to a ULS to the same logical switch on the other vCenter.

DRajan 3

NSX 6.2 ULS Integration with SRM 6.1 Automatic Network Mapping

  1. b) Cross vCenter Networking and Security enables key use cases such as:
  • Resource pooling, virtual machine mobility, multi-site and disaster recovery
  • Cross-vCenter NSX eliminates the need for guest customization of IP addresses

and management of portgroup mappings, two large SRM pain points today

  • Centralized management of universal objects, reducing administration effort
  • Increased mobility of workloads; virtual machines can be “vMotioned” across vCenter Servers without having to reconfigure the virtual machine or making changes to firewall rules

The deployment process would ideally be to:

  • Configure Master NSX Manager at primary site and Secondary NSX Manager at recovery site
  • Configure Universal Distributed Logical Router between primary and secondary site
  • Deploy Universal Logical Switch between primary and recovery site and connect it to Universal Distributed Logical Router
  • Deploy the VRO plugin for automation and monitoring
  • Finally map SRM network resources between primary and recovery sites

Supported Use Cases and Deployment Architectures

The primary use cases are full site disaster recovery scenarios or unplanned outage where the primary site can go down due to a disaster and secondary site takes immediate control and enables business continuity. The other key use case is planned datacenter migration scenarios where one could migrate workloads from one site to another maintaining the underlying networking and security profiles. The main difference between the two use cases is the frequency of the synchronization runs. In a datacenter migration use case you can take one datacenter running NSX and reproduce the entire networking configuration on the DR side in a single run of the synchronization workflow or run it once initially and then a second time to incrementally update the NSX objects before cutover.

DRajan 4

Other supported use cases include partial site outages, preventive failover, or when you anticipate a potential datacenter outage, for example, impending events like hurricanes, floods, forced evacuation, etc.

The standard 1:1 deployment model with one site as primary and another as secondary is the most common deployed model. In a shared recovery site configuration, like for branch offices, you install one SRM server instance and NSX on each protected site. On the recovery site, you install multiple SRM Server instances to pair with each SRM server instance on the protected sites. All of the SRM server instances on the shared recovery site connect to the same vCenter server and NSX instance. You can consider the owner of an SRM server pair to be a customer of the shared recovery site. You can use either array-based replication or vSphere replication or a combination of both when you configure an SRM server to use a shared recovery site.

DRajan 5

Logical Disaster Recovery Architecture Using NSX Universal Objects

What Deployment Architecture Will the Solution Support?

This solution applies to all Greenfield and Brownfield environments. The solution will need the infrastructure to be base-lined to vCenter 6.0 or later, ESXi 6.0 or later, vSphere Distributed switch, SRM 6.0 or later with NSX 6.2 or later.

SRM can be used for different failover scenarios. It could be Active-Active, Active-Passive, Bidirectional, and Shared Recovery.

Integrated Solution Advantages

The ability to automate the disaster recovery planning, maintenance and testing process becomes much simpler, with automation enabling significant operational efficiencies.

  • The ability to create a network that spans vCenter boundaries creates a cross-site Layer-2 network, which means that after failover, it is no longer necessary to re-configure IP addresses. Not having to re-IP recovered virtual machines can further reduce recovery time by up to 40 percent.
  • There is more automation with networking and security objects. Logical switching, logical routing, security policies (such as security groups), firewall settings and edge configurations are also preserved on recovered virtual machines, further decreasing the need for manual configurations post-recovery.
  • Making an isolated test network with all the same capabilities identical to a production environment becomes much easier.

In conclusion, the integration of NSX and SRM greatly simplifies operations, lowers operational expenses, increases testing capabilities and reduces recovery times.

For more information on NSX visit: http://www.vmware.com/products/nsx/

For more information on SRM visit: http://www.vmware.com/products/site-recovery-manager/

For more information on VMware Professional Services visit: http://www.vmware.com/consulting/

 


About the Author:

Dharma Rajan is a Solution Architect in the Professional Services Organization specializing in pre-sales for SDDC and driving NSX technology solutions to the field. His experience spans Enterprise and Carrier Networks. He holds an MS degree in Computer Engineering from NCSU and M.Tech degree in CAD from IIT

VMware Certificate Authority, Part 3: My Favorite New Feature of vSphere 6.0 – The New!

jonathanm-profileBy Jonathan McDonald

In the last blog, I left off right after the architecture discussion. To be honest, this was not because I wanted to but more because I couldn’t say anything more about it at the time. As of September 10, vSphere 6.0 Update 1 has been released with some fantastic new features in this area that make the configuration of customized certificates even easier. At this point what is shown is a tech preview, however it shows the direction that the development is headed in the future. It is amazing when things just work out and with a little bit of love, an incredibly complex area becomes much easier.

In this release, there is a UI that has been released for configuration of the Platform Services Controller. This new interface can be accessed by navigating to:

https://psc.domain.com/psc

When you first navigate here, a first time setup screen may be shown:

JMcDonald 1

To set up the configuration, login with a Single Sign-On administrator account, and the actual setup will run and be complete in short order. Subsequently when you login, the screen is plain and similar to the login of the vSphere Web Client:

JMcDonald 2
After login, the interface appears as follows:

JMcDonald 3

As you can see, it provides a ton of new and great functionality, including a GUI for installation of certificates! I will not be talking about the other features except to say there is some pretty fantastic content in there, including the single sign-on configuration, as well as appliance-specific configurations. I only expect this to grow in the future, but it is definitely amazing for a first start.

Let’s dig in to the certificate stuff.

Certificate Store

When navigating to the Certificate Store link, it allows you to see all of the different certificate stores that exist on the VMware Certificate Authority System:

JMcDonald 4This gives the option to view the details of all the different stores that are on the system, as well as view details, and add or remove entry details of each of the entries available:

JMcDonald 5
This is very useful when troubleshooting a configuration or for auditing/validating the different certificates that are trusted on the system.

Certificate Authority

Next up: the Certificate Authority option, which shows a view similar to the following:

JMcDonald 6

This area shows the Active, Revoked, Expired and Root Certificate for the VMware Certificate Authority. It also provides the option to be able to show details of each certificate for auditing or review purposes:

JMcDonald 7

In addition to providing a review, the Root Certificate Tab also allows the additional functionality of replacing the root certificate:

JMcDonald 8

When you go here to do just that, you are prompted to input the new Certificate and Private Key:

JMcDonald 9

Once processed the new certificate will show up in the list.

Certificate Management

Finally, and by far the most complex, is the Certificate Management screen. When you first click this, you will need to enter the single sign-on credentials for the server you want to connect to. In this case, it is to the local Platform Services Controller:

JMcDonald 10

Once logged in the interface looks as follows:

JMcDonald 11

Don’t worry, however, the user or server is not a one-time thing and can be changed by clicking the logout button. This interface allows the Machine Certificates and Solution User Certificates to be viewed, renewed and changed as appropriate.

If the renew button is clicked the certificate will be renewed from VMware Certificate Authority.JMcDonald 12

Once complete the following message is presented:

JMcDonald Renewal

If the certificate is to be replaced it is similar to the process of replacing the root certificate:

JMcDonald Root

Remember that the root certificate must be valid or replaced first or the installation will fail. Finally, the last screenshot I will show is the Solution Users Screen:

JMcDonald Solutions

The notable difference here is that there is a Renew All button, which will allow for all the solution user certificates to be changed.

This new interface for certificates is the start of something amazing, and I can’t wait to see the continued development in the future. Although it is still a tech preview, from my own testing it seems to work very well. Of course my environment is a pretty clean one with little environmental complexity which can sometimes show some unexpected results.

For further details on the exact steps you should take to replace the certificates (including all of the command line steps, which are still available as per my last blog) see, Replacing default certificates with CA signed SSL certificates in vSphere 6.0 (2111219).

I hope this blog series has been useful to you – it is definitely something I am passionate about so I can write about it for hours! I will be writing next about my experiences at VMworld and hopefully to help address the most common concerns I heard from customers while there.


Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments

 

VMware Certificate Authority, Part 2: My Favorite New Feature of vSphere 6.0 – The Architecture

jonathanm-profileBy Jonathan McDonald

Picking up where Part 1 left off, I will now discuss the architecture decisions I have seen commonly used for the VMware Certificate Authority. This comes from many conversations with customers, VMware Professional Services, VMware Engineering and even VMware Support. In addition to these sources I recently participated in many conversations at VMworld. I spoke at several sessions as well while I was manning the VMworld booth. I ended up with the opportunity to better appreciate the complexities, and also got to talk with some fantastic people about their environments.

Architecture of the Environment

Getting back to the conversation, the architecture of the environment becomes one that is incredibly important to design up front. This allows an administrator to avoid much of the complexity and allows for security to be kept. That being said, from my current experiences I have seen three different ways that environments are most frequently configured:

  • VMware Certificate Authority as the root CA in the default configuration
  • VMware Certificate Authority used but operating as a subordinate CA
  • Hybrid model using custom Machine SSL Certificates, but using VMware Certificate Authority in its default configuration.

Before we get into them, however, keep in mind that as I mentioned in my previous blog series regarding the architecture changes for vSphere 6.0, there are two basic platform service controller architectures that should be considered when designing your certificate infrastructure.

Be sure to note up-front whether an external or embedded Platform Services controller is to be used as this is quite important. The difference here is that a separate Machine SSL endpoint certificate would be required for each system.

This means that on an embedded system a single certificate is required as shown below:

JMcDonald 1

Or, for an external environment, two or more will be needed depending on the size of the infrastructure, as can be seen in the following figure.

JMcDonald 2

For further details on the different platform services controller architectures, and to become familiar with them before proceeding, see http://blogs.vmware.com/consulting/2015/03/vsphere-datacenter-design-vcenter-architecture-changes-vsphere-6-0-part-1.html.

Using VMware Certificate Authority as the Root CA in the Default Configuration

This is by far the most common configuration I have seen deployed. Of course this is also the default, which explains why this is the case. Personally, I fully support and recommend actually using this configuration in almost all circumstances. The beauty of it is that it takes very little configuration to be fully secured. Why change something if you do not need to, right? By default, after installation everything is already configured to use VMware Certificate Authority and has already had certificates granted, which are deployed to all solutions and ESXi hosts, and are then added to vCenter Server.

In this situation the only thing required to secure the environment is to download and install the root certificate (or chain) from VMware Certificate Authority.

JMcDonald 3

Note: When you download this file in vSphere 6.0, it is simply called ‘download.’ This is a known issue in some browsers. It is actually a ZIP file, which contains the root certificate chain.

Once downloaded and extracted, the certificate(s) are the file(s) ending in .0. To install simply rename .0 to .cer and double-click to import to the Windows certificate store. Repeat the procedure for all certificates in the chain. The certificates should be installed into the Local Machine’s Trusted Root Certificate Authority or the Intermediate Certificate Authority stores respectively. If using Firefox, import to its proper store to ensure the chain is trusted.

The next time you go to the web page, it will show as trusted as in the following screenshot.

JMcDonald 4

This can potentially take some time if there are many clients who need to have certificates imported to them, however, this is the easiest (and default) deployment model.

Using VMware Certificate Authority as a Subordinate CA

This mode is less commonly used but it is the second largest deployment type I have seen. This takes a bit of work, but essentially it allows you to integrate VMware Certificate Authority into an existing certificate infrastructure. The big benefit to this is that you will issue completely signed certificates in the existing hierarchy, and in many cases no installation of the certificate chain is required. The downside is you will need a subordinate CA certificate to be able to implement the configuration in this way. I have seen this in some cases but it is simply not allowed by policy. This is where the hybrid configuration comes into play as discussed next.

To configure this use the command line utility called certificate-manager.

JMcDonald 5

Once launched, Option 2 is used to Replace VMCA Root Certificate with Custom Signing Certificate and to replace all certificates. The first part of the process is to generate the private key, and the certificate request that will be submitted to the Certificate Authority. To do this, select Option 1:
JMcDonald 6

Once generated, submit the request to the CA for issuance of the certificate, as well as collection of the root certificate chain. For more details, see KB article Configuring VMware vSphere 6.0 VMware Certificate Authority as a subordinate Certificate Authority (2112016).

When the new certificate has been collected, it is a matter of providing this new certificate, as well as the key, to the manager utility. If the certificate-manager screen is still open, select Option 1 to continue, otherwise select Option 2 and then Option 2 again. You will be prompted to provide the details for the certificate including all details for the certificate being issued. Once complete, services are stopped and restarted:

JMcDonald 7

After this the Machine Certificate (aka the Reverse Proxy certificate) can be regenerated from the VMware Certificate Authority for the vCenter Server(s) that are in the environment. This is done by selecting Option 3 from the menu:

JMcDonald 8

This will prompt for a Single Sign-On administrator password—as well as the Platform Services Controller IP—if the system is a distributed installation. It will then prompt you to enter the information for the certificate and restart the vCenter services. The server has its reverse proxy certificate replaced at this point.

The next step is to replace the solution user certificates by running Option 6 from certificate-manager:

JMcDonald 9

This completes the configuration of the custom certificate authority certificates for the vCenter components, but it is not quite done yet.

The final step is to replace the ESXi host certificates. This is done directly from each host’s configuration in the Web Client. The first step here is to set the details for the certificate in the advanced settings for the vCenter Server:

JMcDonald 10

When complete, navigate to an ESXi host and select Manage > Certificates. On this screen, click Renew. This will regenerate the certificate for this host.

JMcDonald 11

In any case, this is the most complex of the architectures shown, but it also is the most environmentally integrated as well. It provides an additional level of security that is required to satisfy compliance regulatory requirements.

Using Hybrid Configurations for the Reverse Proxy – but VMware Certificate Authority for All Other Certificates

Hybrid configurations are the middle ground in this discussion. It is a balance between security and complexity and also satisfies the security team in many cases as well. The biggest issues I have seen that require such a configuration such are:

  • Granting or purchasing a Subordinate CA certificate is not possible due to policy or cost.
  • Issuing multiple certificates to the same server, one for each service, is not something that can be done due to policy or regulatory requirements.
  • Controls to approve or deny certificate requests are required.

In these cases, although it may not be possible to fully integrate VMware Certificate Authority into the existing CA Hierarchy, it is possible to still provide added levels of security. In this case it is possible to leave VMware Certificate Authority in the default configuration, and replace the Machine certificate only. You can do this by using Option 1 from the Certificate Manager tool.

JMcDonald 12

When configured, the environment will use the corporate CA certificate for external user-facing communication because everything now goes through the reverse proxy. On the other side of things components are still secured by certificates from VMware Certificate Authority. The configuration should look like this:

JMcDonald 13

As you can see, the architectures are varied and also provide quite a bit of flexibility for the configuration.

Which Configuration Method Should You Use?

The only remaining question is – which method is the best for you to use? As stated in a previous section, my personal preference is actually to use the “keep it simple” methodology, and use the default configuration. The reason is it’s the simplest configuration, and the only requirement is that the root certificate is installed on clients rather than regenerating custom certificates, and then modifying the configuration.

Obviously where policy or regulatory compliance is concerned there may be a need to integrate it. This, although more complex than doing nothing, is also something that is much easier than it was in prior versions.

Hopefully all of this information has been of use to you for consideration when designing or configuring your different vSphere environments. As can be seen, the complexity has been dramatically reduced, and only promises to get better. I can’t wait till I complete the next blog in this series—part 3—which will provide even more detail that will make all of this even simpler.


 

Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments.

VMware Certificate Authority – My Favorite New Feature of vSphere 6.0 – Part 1 – The History

jonathanm-profileBy Jonathan McDonald

Anyone who knows me knows I have a particular passion (however misplaced that may be…) for the VMware Certificate Story. This multi-part blog series will discuss a bit of background on the certificate story, what you need to know about the architectural design of it in an environment and some new features you may not know about.

Let me start off by saying this passion started off several years ago when I was in Global Support Services, and I realized that too few people had an understanding about certificates. I am not even talking certificates in the context of VMware, but in general. This was compounded when we released vSphere 5.1 due to the fact that strict certificate checking was enabled.

A Bit of History

Although certificates were used for securing communication prior to vSphere 5.1, they were self-signed and there was no verification performed to ensure the certificate was valid. Therefore, for example, the certificate could be expired, or be used for multiple services at the same time (such as for the vCenter Server service and the vCenter Inventory service). This is obviously not a good practice, but it nevertheless was allowed.

When vCenter Single Sign-On was released with vSphere 5.1, it enforced strict certificate checking. This included not only the certificate uniqueness, but such information as the validity period of the certificates as well. Therefore, if any of the components were not using a unique and valid certificate, they would not be accepted when registering the different services as solutions in Single Sign-On. This would turn out to be a pretty large issue as upgrades would fail with very little detail as to why.

That being said, if all services in vCenter 5.1 and 5.5 have their certificate replaced, seven unique certificates are required:

  • vCenter Single Sign-On
  • vCenter Inventory Service
  • vCenter Server
  • vSphere Web Client
  • vSphere Web Client Log Browser
  • vCenter Update Manager
  • vCenter Orchestrator

The process to change the certificates is not straightforward and caused a significant amount of trouble amongst customers and global support services alike. This is when we raised it as a concern internally and helped to get a short-, medium- and long-term plan in place in time to make it easier to replace certificates when required. The plan was as follows:

  • Short term – We ensured the KB articles relating to certificate replacement were accurate and easy to follow.
  • Medium term – We helped in the development of the SSL Certificate Automation Tool, which dramatically reduced the number of steps and made it fairly easy to replace the certificates.
  • Long term – We forced focus on the issue so a solution could be built into the product.

Prior to moving from VMware Support to Professional Services Engineering we had released the tool and the larger plan was in place. The following are two blog posts I did for the tool:

http://blogs.vmware.com/kb/2013/04/introducing-the-vcenter-certificate-automation-tool-1-0.html

http://blogs.vmware.com/kb/2013/05/ssl-certificate-automation-tool-version-1-0-1.html

With vSphere 6.0 the larger long-term solution is finally coming to fruition with the introduction of the VMware Certificate Authority. It solves many of the problems that were seen.

Introduction to the VMware Certificate Authority

With vSphere 6.0, the base product installs an internal certificate authority (CA) called the VMware Certificate Authority. This is a part of the Platform Services Controller installation and has changed the architecture significantly for the better. No longer are the default certificates self-signed, rather, they are issued and signed by the VMware Certificate Authority.

This works in one of two ways:

  • VMware Certificate Authority acts as the root certificate authority. This is the default configuration and allows for an out-of-the-box configuration that is fully signed. All the clients need to do is to trust the root certificate and the communication is fully trusted.
  • VMware Certificate Authority acts as an Intermediate CA, integrating into an existing CA infrastructure in the environment. This allows for certificates to be issued that are already trusted throughout the environment.

In each of these two modes, it acts in the same way granting certificates to not only the solutions connected to the management infrastructure, but to ESXi hosts as well. This occurs when the solution/host is added to vCenter server. By default, communication is secure and trusted, and therefore, everything on the management network that was previously difficult to secure is trusted.

Introduction to the VMware Endpoint Certificate Store

In addition to the certificate authority itself, vSphere 6 certificates are now managed and stored in a “wallet.” This wallet is called the VMware Endpoint Certificate Store (VECS). The benefit here is certificates and private keys are no longer stored on disk in various locations. They are centrally managed in VECS on every vSphere node. This allows for a greatly simplified configuration for the environment because you no longer need to update trusts when the certificates are replaced because it is done automatically by VECS.

The VECS is installed on all platform services controller installation, including both embedded and external configurations.

JMcDonald Certificate Authority 1

The following different stores for certificates are used:

  • The Machine Certificates store contains the Machine SSL Certificate and private key, which is used for the Reverse Proxy, discussed next.
  • The Root CA Certificates store contains trusted root certificates and revocation lists, from any VMware Certificate Authority in the environment, or the third-party certificate authority being used. Solutions use this store to verify certificates.
  • The Solution User Certificates store contains the certificates and private keys for any solutions such as vCenter and the vSphere Web Client.

A single location for all certificates is a welcome change to the previous versions.

The Reverse Proxy – (Machine SSL Certificate)

Finally, before we get into the recommended architectures, the Reverse Proxy is the last thing I want to introduce. The change here addresses one of the biggest problems that was seen in previous versions of vCenter, which is that there are so many different services installed that require SSL communication. To be honest, the real challenge here is not the number of services rather, trying to get signed certificates all of them from the SSL administrator for the same host.

To combat this, solution users were consolidated with vCenter 6.0 to four vpxd, vpxd-, vsphere-webclient and machine. This is to say that where possible many of the various listening ports on the vCenter Server have been replaced with a single Reverse Web Proxy for communication. The Reverse Web Proxy uses the newly created Machine SSL Certificate to secure communication. Therefore, all communication to the different services is routed to the appropriate service based on the type of request through the reverse proxy. This can be seen in the figure below.

JMcDonald Certificate Authority 2

It is still possible to change the certificate of the solution users behind it, however, these are only used internally and do not necessarily need to be changed. More on this in the next part of this series.

With all of this background detail out of the way, I think it is a good place to pause. Part 2 of this article will discuss the architecture decision points and some configuration details. On another note, I am actually going to be off to VMworld very soon and will be manning the VMware booth, as well as speaking at several sessions! It is unlikely I will get part 2 done before then, but if you have any questions look for me (downstairs at the Solution Exchange, in the VMware Booth, at the Technology Advisor station), and we can talk more on this and other topics with the other members of my team!


Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments.

VMworld Preview: Just Because You COULD, Doesn’t Mean You SHOULD – VMware vSphere 6.0 Architecture

jonathanm-profileBy Jonathan McDonald

Have you noticed the ever-changing VMware vSphere architecture with the introduction of new services and technologies? If you answered yes, you should already know that the architectural configuration details in an environment become instrumentally important to the Software-Defined Data Center (SDDC). The foundation of the SDDC starts with vSphere; if architected correctly it will be much more than a platform for the environment.

At VMworld in San Francisco I will discuss lessons learned from our VMware Professional Services team. This discussion will bring real-world experience to light so that common issues can be addressed prior to the deployment of the solution, rather than after the fact.

Here is an example of what we will dive into: There are different architectures for the Platform Services Controller, from an embedded node to a maximum-sized configuration, as shown in the figure below.

JMcDonald VMworld Blog

To be able to use Enhanced Linked Mode however, it is important to understand the correct and supported architectures that allow for a design to be configured in a supported manner. This will ensure that the chances of a failure are minimized from the beginning.

To learn more, attend my session on Wednesday, September 2, 8-00 AM- 9:00 AM or on Thursday, September 3, at 1:30 PM. # INF4712


Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments.

VIO – A Closer Look from a vSphere Administrator View.

Julienne_PhamBy Julienne Pham

A version of VMware Integrated OpenStack was released in April, and for the DevOps team, the Cloud API did not change from one vendor to another. So, how does it impact me as a vSphere administrator?

This article will go through how VIO can be managed through the vSphere Web Client.

After deploying the VIO cluster services instance, this is what I have noticed:

One Single Pane of Glass

Yes, the initial OVA deployment involves the registration of the VMware Integrated OpenStack services to vCenter Service, so there is no surprise to see the OpenStack logo on the vSphere Web Client.

Instead, I find it very practical to be able to configure all the services through the same vSphere Web Client.

JPham vSphere Web Client

 

Backup and Restore Configuration File

I like this feature in particular, if you are like me, someone who is constantly multitasking, it is really a gain of time when you have to redeploy the OpenStack services or troubleshoot any deployment issue.

The installation requirements can be found on this article: http://blogs.vmware.com/openstack/vmware-integrated-openstack-first-look/

It is quite an exhaustive list, and it can save a lot time especially when you have to fill the IP range.

JPham vSphere Web Client 2

Managing the VIO OpenStack Management Cluster

Depending on the business demand, you can scale-up and scale-down your Nova Compute or other storage configurations from your actual setup within the VMware Integrated OpenStack web interface.

You can:

  • Get the summary of OpenStack Services cluster
  • Add new Nova Compute
  • Add new Nova Storage
  • Add new Glance Storage resources
  • Eventually patch your OpenStack Cluster

JPham vSphere Web Client 3

 

High Availability (HA)/Disaster Recovery Services (DRS) Rules

VMware has designed an OpenStack architecture in high availability mode, but does it integrate with the vSphere HA or DRS? In this example, during the OpenStack services cluster deployment, DRS rules get created to ensure the same OpenStack Service virtual machines are not hosted on the same VMware ESXi host.

JPham vSphere Web Client 4

 

Once configured, the things you need to remember are:

  1. DevOps will provision daily virtual machine workload. You need to make sure you have some controls, monitoring and alarms set on the vSphere infrastructure to prevent any massive production disruption, e.g., a case where a virtual machine provisioning script keeps running in a loop … and might impact the full vSphere environment.
  2. Maintenance. For application awareness, you need to go through the vSphere VMware Integrated web plugin and shut down the cluster from there, not from the vSphere web virtual machine inventory, as it has no application dependency awareness.
  3. We are providing a validated VIO architecture. If you are customizing OpenStack services virtual machines manually, I would suggest backing up the virtual machines and calling support if needed to validate it – as with any future upgrade, your configuration might be overwritten and not persistent.

Julienne Pham is a Technical Solution Architect for the Professional Services Engineering team. She is specialised on SRM and core storage. Her focus is on VIO and BCDR space.