Home > Blogs > VMware Consulting Blog > Category Archives: Virtualization

Category Archives: Virtualization

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

VMware App Volumes Backup Utility Fling: Introduction

First published on VMware’s End-User Computing blog

By Dale Carter, Chris Halstead and Stéphane Asselin

In December 2014, VMware released VMware App Volumes, and since then, lots of new features have been added, and people love using App Volumes. Organizations use App Volumes not only in VMware environments, but also in many Citrix environments.

However, there has been one big request from our App Volumes users: Every time I talk to people about App Volumes, they ask about how to back up their AppStacks and writable volumes. Normal virtual-machine backup tools cannot back up App Volumes AppStacks and writable volumes because the AppStacks and writable volumes are not part of the vCenter inventory unless they are connected to a user’s virtual machine (VM). As I talked to other people within VMware, I found this question coming up more and more, so I started to think of how we could help.

Last summer during an internal conference, Travis Wood, Senior Solutions Architect at VMware, and I were throwing around a few ideas of how to address this request, and we came up with the idea of an App Volumes backup tool.

Because I do not have any programming skills, I started talking with Chris Halstead, End-User-Computing Architect at VMware, about the idea for this tool. Chris was instantly excited and agreed that this would be a great solution. Chris and I also enlisted Stéphane Asselin, Senior End-User-Computing Architect, to help with creating and testing the tool.

Over the last couple of months, Chris, Stéphane, and I have been working on the tool, and today we are happy to announce that the App Volumes Backup Utility has been released as a VMware Fling for everyone to download.

Use Case and Benefits

The issue with backing up App Volumes AppStacks and writable volumes is that these VMDK files do not show up in the vCenter inventory unless they are currently in use and connected to a user’s virtual desktop. The standard backup tools do not see the VMDKs on the datastore if they are not in the vCenter inventory, and you do not want to back up these files while users are connected to their desktops.

The use case for this tool was to provide a way to make your backup tools see the AppStack and writable-volume VMDKs when they are not connected to a user’s virtual desktop. We also did not want to create other virtual machines that would require an OS; we wanted to keep the footprint and resources to a minimum, and the cost down.

The benefits of using the App Volumes Backup Utility are

  • It connects AppStacks and writable volumes to a VM that is never in use and that also does not have an OS installed.
  • The solution is quick and uses very few resources. The only resource that the tool does use is a 1 MB storage footprint for each temporary backup VM you create.
  • The tool can be used in conjunction with any standard software that backs up your current virtual infrastructure.

How Does the Tool Work?

DCarter_app-volumes-backup-utility-19

In the App Volumes Backup Utility, we made it easy for your existing backup solution to see and back up all of the AppStacks and writable volumes. This is accomplished in a fairly straightforward way. Using the tool, you connect to both your App Volumes Manager and vCenter. Then, using the tool, you create a backup VM. This VM is only a shell, has no OS installed, and has a very small footprint of just 1 MB.

Note: This VM will never be powered on.

After the backup VM is created, you select which AppStacks and writable volumes you want to back up, and you attach them to the backup VM using the App Volumes Backup Utility.

After the AppStacks and writable volumes are attached, you can use your standard backup solution to back up the backup VM, including the attached VMDK files. After the backup is complete, open the tool and detach the AppStacks and writable volumes from the backup VM, and delete the backup VM.

For more details on how to use the tool, see the VMware App Volumes Backup Utility Fling: Instructions.

Download the App Volumes Backup Utility Fling, and feel free to give Chris Halstead, Stéphane Asselin, and me your feedback. You can comment on the Fling site or below this blog post, or find our details on this blog site and connect with us.


Dale CarterDale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years’ experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently holds a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA. For more blog post from Dale visit his website at http://vdelboysview.com

Chris_Halstead

Chris Halstead is an EUC Architect on the End User Computing Technical Marketing & Enablement team. He has over 20 years’ experience in the End User Computing space. Chris’ experience ranges from managing a global desktop environment for a Fortune 500 company, to managing and proving EUC professional services at a VMware partner–and most recently as an End User Computing SE for VMware. Chris has written four other VMware Flings, many detailed blog articles (http://chrisdhalstead.net), has been a VMware vExpert since 2012 and is active on Twitter at @chrisdhalstead

Stephane_Asselin

Stéphane Asselin with his twenty years experience in IT, is a Senior Consultant for the Global Center of Excellence (CoE) for the End-User Computing business unit at VMware. In his recent role, he had national responsibility for Canada for EUC planning, designing and implementing virtual infrastructure solutions and all processes involved. At VMware, Stephane has worked on EUC pre-sales activities, internal IP, product development and technical specialist lead on BETA programs. He has also done work as a Subject Matter Expert for project Octopus, Horizon, View, vCOps and ThinApp. Previously, he was with CA as Senior Systems Engineer where he has worked on Enterprise Monitoring pre sales activities and technical specialist. 

In his current role in the Global Center of Excellence at VMware, he’s one of the resources developing presentation materials and technical documentation for training and knowledge transfer to customers and peer systems engineers. Visit myeuc.net for more information.

Composite USB Devices Step by Step

Jeremy WheelerBy Jeremy Wheeler

Users have a love/hate relationship with VDI: they love the ability to access apps and information from any device, at any time, but they hate the usual trade-offs in performance and convenience. If you’re using VMware Horizon View, you’ve already overcome a huge acceptance hurdle, by providing a consistently great experience for knowledge workers, mobile workers and even 3D developers across devices, locations, media and connections.

But sometimes, peripherals don’t behave as expected in a VDI environment, which can lead to JWheeler Composite USB White Paperuser frustration. For example, when someone wants to use a Microsoft LifCam Cinema camera, they naturally expect to just plug it into a USB device and have it auto-connect to their VDI session. But if anyone in your organization has tried to do this, you already know that’s not the case. Fortunately, there is an easy workaround to fix the problem.

Download the white paper for the VMware-tested fix to this common problem.

 


Jeremy Wheeler is an experienced Consulting Architect for VMware’s Professional Services Organization, End-user Computing specializing in VMware Horizon Suite product-line and vRealize products such as vROps, and Log Insight Manager. Jeremy has over 18 years of experience in the IT industry. In addition to his past experience, Jeremy has a passion for technology and thrives on educating customers. Jeremy has 7 years of hands-¬‐on virtualization experience deploying full-life cycle solutions using VMware, CITRIX, and Hyper-V. Jeremy also has 16 years of experience in computer programming in various languages ranging from basic scripting to C, C++, PERL, .NET, SQL, and PowerShell.

Jeremy Wheeler has received acclaim from several clients for his in-¬‐depth and varied technical experience and exceptional hands-on customer satisfaction skills. In February 2013, Jeremy also received VMware’s Spotlight award for his outstanding persistence and dedication to customers and was nominated again in October of 2013

Configuring NSX SSL VPN-Plus

Spas_KaloferovBy Spas Kaloferov

One of the worst things you can do is to buy a great product like VMware NSX Manager and not use its vast number of functionalities. If you are one of those people and want to “do better” then this article is for you. Will take a look how to configure SSL VPN-Plus functionality in VMware NSX. With SSL VPN-Plus, remote users can connect securely to private networks behind a NSX Edge gateway. By doing so remote users can access servers and applications in the private networks.

Consider a software development company that has made design decision and is planning to extend it’s existing network infrastructure and allow remote users access to some segments of it’s internal network. To accomplish this the company will be utilizing the already existing VMware NSX Manager network infrastructure platform to create a Virtual Private Network (VPN).

The company has identified the following requirements for their VPN implementation:

  • The VPN solution should utilize SSL certificate for communication encryption and be used with standard Web browser.
  • The VPN solution should use Windows Active Directory (AD) as identity source to authenticate users.
  • Only users within a given AD organizational unit (OU) should be granted access to the VPN.
  • Users should be utilizing User Principal Names (UPN’s) to authenticate to the VPN.
  • Only users who have accounts with specific characteristics, like those having an Employee ID associated with their account, should be able to authenticate to the VPN.

If you have followed one of my previous articles Managing VMware NSX Edge and Manager Certificates, you have already made the first step towards configuring SSL VPN-Plus.

Configuring SSL VPN-Plus is a straightforward process, but fine tuning it’s configuration to meet your needs might sometimes be a bit tricky. Especially when configuring Active Directory for authentication. We will look into a couple of examples how to use the Login Attribute Name and Search Filter parameters fine grain and filter the users who should be granted VPN access.

Edit Authentication Server tab on VMware NSX Edge:

SKaloferov Edit Authentication Server

Please visit Configuring NSX SSL VPN-Plus to learn more about the configuration.


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.

“Network Functions Virtualization (NFV) for Dummies” Blog Series – Part 2

Common Use Cases for the Transition to NFV

Gary HamiltonBy Gary Hamilton

In my previous blog posting I discussed the question – What is NFV? This blog post looks at the network functions that will be delivered as virtual network functions (VNFs), instead of as hardware appliances. SDx Central offers a nice article that helps with some of these definitions.

In very simple terms (remember this is a blog series for IT people, not network experts), a network function is a network capability that provides application and service support, and can be delivered as a composite whole, like an application. SDx Central does a good job in the aforementioned article of grouping these network functions by categorizing them into umbrella or macro use cases. By leveraging these macro use cases, I am able to provide a layman’s description of what these use cases are attempting to achieve, and the service support they deliver. The macro use cases I will focus on in my explanation are “virtual customer edge” and “virtual core and aggregation”, because these are the two use cases that are generally being tackled first from a NFV perspective.

Use Case – Connecting a remote office (using vCPE)

In layman terms, the SDx Central “customer edge” use case focuses on how to connect a remote office, or remote branch, to a central data centre network, and extending the central data centre’s network services into that remote office. In order to deliver this connectivity, a CPE (customer premises equipment) device is used. Generally, the types of device used would be a router, switch, gateway, firewall, etc., (these are all CPEs) providing anything from Layer 2 QoS (quality of service) services to Layer 7 intrusion detection. The Layer 2 and Layer 7 references are from the OSI Model. vCPE (virtual customer premises equipment) is the virtual CPE, delivered using the NFV paradigm.

The following diagram was taken from the ETSI Use Case document (GS NFV 001 v1.1.1 2013-10), referring to the vCPE device as vE-CPE. (I’ll discuss the significance of ETSI in a future blog post)

This diagram illustrates how vCPEs are used to connect the remote branch offices to the central data centre. It also illustrates that it is OK to mix non-virtualised CPEs with vCPEs in an infrastructure. Just as in the enterprise IT cloud world, the data and applications leveraging the virtual services are not aware – and do not care – whether these services are virtual or physical. The only thing that matters is whether the non-functional requirements (NFRs) of the application are effectively met. Those NFRs include requirements like performance and availability.

This particular use case has two forms, or variants –

  • Remote vCPE (or customer-premise deployed)
  • Centralised vCPE (deployed within the data centre)

The diagram below shows examples of both variants, where vCPEs are deployed in branch offices, as well as centrally. The nature of the application being supported, and its NFRs, would normally dictate placement requirements. A satellite/cable TV set-top box is a consumer example of a “customer-premise deployed” CPE.

GHamilton Customer Premise Deployed CPE

Use Case – Virtualising the mobile core network (using vIMS)

The SDx Central “Virtual core and aggregation” use cases are focused on the mobile core network (Evolved Packet Core – EPC) and IP Multimedia Subsystem (IMS). In layman terms, this is about the transportation of packets across a mobile operator’s network. This is focused on mobile telephony.

IMS is an architectural network framework for the delivery of telecommunications services using IP (internet protocol). When IMS was conceived in the 1990s by the 3rd Generation Partnership Project (3GPP), it was intended to provide an easy way for the worldwide deployment of telecoms networks that would interface with the existing public switched telephone network (PSTN), thereby providing flexibility, expandability, and the easy on-boarding of new services from any vendor. It was also hoped that IMS would provide a standard for the delivery of voice and multimedia services. This vision has fallen short in reality.

IMS is a standalone system, designed to act as a service layer for applications. Inherent in its design, IMS provides an abstraction layer between the application and the underlining transport layer, as shown in the following diagram of the 3GPP/TISPAN IMS architecture overview.

An example of an application based on IMS is VoLTE, which stands for “Voice over 4G LTE” wireless network. Examples of VoLTE applications are Skype and Apple’s FaceTime.

GHamilton 3GPP and TISPAN

Use Case – Virtualising the mobile core network (using vEPC)

While IMS is about supporting applications by providing application server functions, like session management and media control, EPC is about the core network, transporting voice, data and SMS as packets.

EPC (Evolved Packet Core) is another initiative from 3GPP for the evolution of the core network architecture for LTE (Long-Term Evolution – 4G). The 3GPP website provides a very good explanation of its evolution, and description of LTE here.

In summary, EPC is a packet-only network for data, voice and SMS, using IP. The following diagram shows the evolution of the core network, and the supporting services.

  • GSM (2G) relied on circuit-switching networks (the aforementioned PSTN)
  • GPRS and UMTS (3G) are based on a dual-domain network concept, where:
    • Voice and SMS still utilise a circuit-switching network
    • But data uses a packet-switched network
  • EPS (4G) is fully dependent on a packet-switching network, using IP.

GHamilton Voice SMS Data

Within an EPS service, EPC provides the gateway services and user management functions as shown in the following diagram. In this simple architecture:

  • A mobile phone or tablet (user equipment – UE) is connected to an EPC over an LTE network (a radio network) via an eNodeB (a radio tower base station).
  • A Serving GW transports IP data traffic (the user plane) between the UE and external network.
  • The PDN GW is the interface between the EPC and external network, for example, the Internet and/or an IMS network, and allocates IP addresses to the UEs. PDN stands for Public Data Network.
    • In a VoLTE architecture, a PCRF (Policy and Charging Rule Function) component works with the PDN GW, providing real-time authorisation of users, and setting up the sessions in the IMS network.
  • The HSS (Home Subscriber Server) is a database with user-related and subscriber-related information. It supports user authentication and authorisation, as well as call and session setup.
  • The MME (Mobility Management Entity) is responsible for mobility and security management on the control plane. It is also responsible for the tracking of the UE in idle-mode.

GHamilton EPC E-UTRAN

In summary, EPC, IMS and CPE are all network functions that deliver key capabilities that we take for granted in our world today. EPC and IMS support the mobile services that have become a part of our daily lives, and frankly, we probably would not know what to do without them. CPE supports the network interconnectivity that is a part of the modern business world. These are all delivered using very specialised hardware appliances. The NFV movement is focused on delivering these services using software running on virtual machines, running on a cloud, instead of using hardware appliances.

There are huge benefits to this movement.

  • It will be far less expensive to utilise shared, commodity infrastructure for all services, versus expensive, specialised appliances that cannot be shared.
  • Operational costs are far less expensive because the skills to support the infrastructure are readily available in the market.
  • It costs far less to bring a new service on-board, because it entails deploying some software in VMs, versus the acquisition and deployment of specialised hardware appliances.
  • It costs far less to fail. If a new service does not attract the expected clientele, the R&D and deployment costs of that service will be far less with NFV than in the traditional model.
  • It will be significantly faster to bring new services to market. Writing and testing new software is much faster than building and testing new hardware.
  • The costs of the new virtual network functions (VNFs) will be less because the entry point is far lower because it is now about developing software versus building a hardware appliance. We see evidence of this, where a lot of new players have come into the Network Equipment Provider (NEP) market (the suppliers of the VNFs), therefore creating more competition, which drives down prices.

All sounds great. But, we have to be honest, there are serious questions to be answered/addressed –

  • Can the VNFs deliver the same level of service as the hardware appliances?
  • Can the Telco operators successfully transform their current operating models to support this new NFV paradigm?
  • Can a cloud meet the non-functional requirements (NFRs) of the VNFs?
  • Are the tools within the cloud fit for purpose for Telco grade workloads and services?
  • Are there enough standards to support the NFV movement?

All great questions that I will try to answer in future blogs. The European Telecommunications Standard Institute (ETSI), an independent, not-for-profit organisation that develops standards via consensus of their members, has been working on the answers to some of these questions. Others are being addressed by cloud vendors, like VMware.


Gary Hamilton is a Senior Cloud Management Solutions Architect at VMware and has worked in various IT industry roles since 1985, including support, services and solution architecture; spanning hardware, networking and software. Additionally, Gary is ITIL Service Manager certified and a published author. Before joining VMware, he worked for IBM for over 15 years, spending most of his time in the service management arena, with the last five years being fully immersed in cloud technology. He has designed cloud solutions across Europe, the Middle East and the US, and has led the implementation of first of a kind (FOAK) solutions. Follow Gary on Twitter @hamilgar.

VMware vRealize Automation 7.0 – Finally the most desirable features and capabilities in a VMware Private Cloud Automation Solution have arrived!

By Cory Allen, RadhaKishna (RK) Dasari and Shannon Wilber

Anyone who has previously worked with vRealize Automation 6.x or earlier versions of VMware Cloud Automation Center 5.x, understands historically just how challenging it can be to manage the overall planning, design, deployment and architecture of an end-to-end Private Cloud Automation solution.

Our Professional Services Engineering team over the past few years have worked extensively with VMware engineering organizations and many diverse customer Cloud Automation deployment scenarios globally.  Our team extensively tests and researches the most effective and proven methodologies to implement vRealize Automation as a solution help mitigate and reduce historical implementation challenges.

So guess what?  We are really excited and impressed with the new vRealize Automation 7.0… 🙂

VMware finally has a new Private Cloud Solution and Product with the launch of vRealize Automation 7.0, that delivers a much easier and user friendly deployment method using the new slick vRealize Automation Installation Wizard. This new installation and configuration wizard enables a simplified and centralized deployment unlike anything you have seen in vRealize Automation before. The challenges of the installation and configuration are a thing of the past, having been solved in a whole new way with this new release of vRealize Automation.

In particular, during early testing and validation our team had performed during betas, we quickly became very impressed with this new feature and capability and immediately realized just how valuable the new vRealize Automation Installation would be for efficiency, ease of use, intuitive, and stability for the VMware field delivery teams and customers globally. The most significant change our team observed that was very cool, was that you do not have to do so many manual installation tasks anymore – which can get really tedious during the deployment of a complex highly available VRA solution.

So now let’s get to the best part – where the fun begins – some basic questions and answers.

  1. How has the installation and configuration of vRealize Automation 7.0 changed from previous versions to include 6.x and 5.x?
    Response: Well, good news! The new installation features and capabilities offered include the option to deploy a Minimal Deployment and an Enterprise Deployment.
  • The vRealize Automation Installation Wizard Minimal Deployment offers a simple non-distributed installation without high availability shown here:
    PSE Deployment 1
  • The vRealize Automation Installation Wizard provides an option for an Enterprise Deployment distributed with or without high availability options shown here:

PSE Expanded Deployment

  1. Now I have two options to perform the installation, so what is the big deal?

    Response: That is not all the installation has to offer, we are just getting started! The new installation wizard now has a cool new Gadget called the “Prerequisite Checker” available within the Wizard. This new feature leverages a new IaaS Management Agent to install on each IaaS Hosts so that the “Prerequisite Checker” that can automatically from a central location within the Wizard, automate the installation and configuration of all Microsoft Windows Server IaaS Prerequisites. No longer do architects and engineers have to manually logon to each server, configure the prerequisites, reboot, or worse – forget to install all required prerequisites. The new vRealize Automation Installation Wizard Prerequisite Check Takes care of it all. Just be careful not to get to comfortable here, there is more fun.

The vRealize Installation Wizard Installation Prerequisites Page to Download Management Agents is shown here:

PSE Deployment 3

vRealize Installation Wizard New “Prerequisite Checker” scanning IaaS Hosts within the Enterprise Deployment option:

PSE Deployment 4

The vRealize Installation Wizard New “Prerequisite Checker” identifies Windows IaaS Server Hosts that may not have “Some prerequisites are not met” notification. The wizard has a “Fix” button that enables this cool new tool too automatically fix each IaaS Host with a simple click of a button.

PSE Prerequisite Checker 1
The cool new “
Prerequisite Checker” will notify you when all Windows IaaS Machines have had all prerequisites installed configured. Guess what? If for some reason a Windows IaaS Machine goes offline during the process, simply wait for the machine to come back online and click “Run” or “Fix” a second time for where you last left off. Pretty cool stuff huh?

PSE Prerequisite Checker 2

 

PSE Prerequisite Checker 3

  1. Wow! That is pretty cool. After the “Prerequisite Checker” is done completing installation tasks, what other cool automated and fancy things can vRealize Automation 7.0 do? What about authoring infrastructure or applications? Has anything changed to enable an easier and more streamlined method for developing infrastructure and applications?Response: Check out the new (and unified) blueprint design canvas for authoring infrastructure virtual machines and applications with Machine Types and Software Components which now include Application Services as standard service. The new blueprint designer is probably the coolest, and most significant, new feature that has been implemented that allows for building simple virtual machines to complex application based blueprints all within a single design canvas.

New Unified Blueprint Design Canvas for Authoring Infrastructure and Applications

PSE Unified Blueprint Design

  1. Now that the first question has been addressed for new unified blueprints, tell me how Application services works with the new service authoring model.Response: Here is an overview of how the new Application Services works compared to previous versions of vRealize Automation Application Services in the 6.x versions:Application Services formerly Application Director used to be an optional application blueprint authoring feature that was a separate, external virtual appliance that had to be manually deployed, configured, and integrated with vRealize Automation 6.x environments. Following the former deployment methods in older Application Services versions, application blueprints had to be manually created as a separate component from single and multi-machine blueprints in vRealize Automation 6.x. Now in vRealize Automation 7.0, Application Services is a standard feature that is offered as part of the overall deployment and is available within the unified blueprint. Application services is no longer a separate virtual appliance or external component. Application Services, which now includes Software Components, have integrated authoring capabilities in the vRealize Automation 7.0. Application Services and runs as a service on each vRealize Automation 7.0 appliances, scaling as appliances are added into the overall scalable architecture.

New Capabilities to Create Applications and Software Components in the Unified Blueprint

PSE Unified Blueprint 2

VMware’s customers will be very impressed that they can now create multi-tier blueprints with combined infrastructure and application dependencies to author software components.

Create a Software Component such as an Apache Web Server Service

PSE Unified Blueprint 3

  1. Wow that is very cool, I can now create infrastructure virtual machines, create Software Components and then add my applications by dragging and dropping my applications onto the design canvas? How can I add networking or security policies to my unified blueprints?Response: In addition, another super cool new feature and capability with the unified blueprint is the option to integrate NSX On-Demand Networking and Security components into these blueprints. This is a radical new networking and security enhancement within the blueprint design canvas that allows authoring of services all in one single unified designer within vRealize Automation 7.0 that can include NSX features and Network Components to include:
  • On-Demand Private Networks
  • On-Demand NAT Networks
  • On-Demand Routed Networks

Security Components:

  • On-Demand Security Groups
  • Existing Security Groups
  • Security Tags

New Blueprint with NSX On-Demand Networking and Security “Drag & Drop” Authoring Functionality

PSE Unified Blueprint 4


Cory AllenCory Allen has been in the IT world for over 18 years and is a Technical Solutions Architect for VMware. He has been with VMware since June of 2015 working on the PSE Cloud Automation Team. Before coming to VMware, he was with Parker Kannifin where he was the Hybrid Cloud Architect where his main task was to Design and Build a Private Internal Cloud that was fully automated and able to scale to the whole organization worldwide.

RK DasariRadhaKrishna (RK) Dasari is a Technical Solutions Architect for the Professional Services Engineering team. He specializes in developing architecture designs and service kits for vRealize Automation and vCloud Air. Prior to VMware, RK had a career spanning thirteen years at Dell as a software developer, software architect and pre-sales solutions architect.

Shannon WilberShannon Wilber is a Technical Solution Architect at VMware with eighteen years of information technology experience with architecture design, implementations and infrastructure management for commercial and enterprise scale IT solutions for Software Defined Data Centers and Hybrid Cloud environments. Proven team leadership and technical experience to guide complex IT projects through the planning, design, implementation, migration and optimization stages for diverse IT solutions for customers globally. Shannon is also a VMware Certified Professional (VCP5-DCV), EMC Proven Professional and EMC Certified Cloud Infrastructure Specialist. 

Cloud Pod Architecture and Cisco Nexus 1000V Bug

Jeremy WheelerBy Jeremy Wheeler

I once worked with a customer who owned two vBlocks between two data centers. They ran Nexus 1000V for the virtual networking component. They deployed VDI, and when we enabled cloud pod architecture, global data replication worked great; however, all of our connection servers in the remote pod would show red or offline. I found that we could not telnet to the internal pod or remote pod connection servers over port 8472. All other ports were good. VMware Support confirmed that the issue is with the Nexus 1000V and found that there was a bug in the N1KV and a TCP Checksum Offload function.

The specific ports in question are the following:

VMware View Port 8472 – The View Interpod API (VIPA) interpod communication channel runs on this port. View Connection Server instances use the VIPA interpod communication channel to launch new desktops, find existing desktops, and share health status data and other information.

Cisco Nexus 1000V Port 8472 – VXLAN; Cisco posted a bug report about 8472 being dropped at the VEM for N1KV: Cisco Bug: CSCup55389 – Traffic to TCP port 8472 dropped on the VEM

The bug report mentions TCP Checksum being the root cause and offloading only 8472 packets. If removing the N1KV isn’t an option, you can disable TCP Offloading.

To Disable TCP Offloading

  • In the Windows server, open the Control Panel and select Network Settings Change Adapter Settings.
    JWheeler Ethernet Adapter Properties 1
    Right-click on each of the adapters (private and public), select Configure from the Networking menu, and then click the Advanced tab. The TCP Offload settings are listed for the Citrix adapter.JWheeler Ethernet Adapter Properties 2

I recommend applying the following:

  • IPv4 Checksum Offload
  • Large Receive Offload (was not present for our vmxnet3 advanced configuration)
  • Large Send Offload
  • TCP Checksum Offload

You would need to do this on each of the VMXNET3 Adapters on each connection server at both data centers. Once disabled (it did cause nic to blip), we were able to Telnet between the data centers on port 8472 again.

After making these adjustments you should be able to login to the View Admin portal and see all greens for remote connection servers. I have tested and validated this, and it works as intended. For more information I recommend you read Understanding TCP Segmentation Offload (TSO) and Large Receive Offload (LRO) in a VMware environment (2055140).


Jeremy Wheeler is an experienced senior consultant and architect for VMware’s Professional Services Organization, End-user Computing specializing in VMware Horizon Suite product-line and vRealize products such as vROps, and Log Insight Manager. Jeremy has over 18 years of experience in the IT industry. In addition to his past experience, Jeremy has a passion for technology and thrives on educating customers. Jeremy has 7 years of hands-¬‐on virtualization experience deploying full-life cycle solutions using VMware, CITRIX, and Hyper-V. Jeremy also has 16 years of experience in computer programming in various languages ranging from basic scripting to C, C++, PERL, .NET, SQL, and PowerShell.

Jeremy Wheeler has received acclaim from several clients for his in-¬‐depth and varied technical experience and exceptional hands-on customer satisfaction skills. In February 2013, Jeremy also received VMware’s Spotlight award for his outstanding persistence and dedication to customers and was nominated again in October of 2013

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. Both path 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

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.

User Environment Manager 8.7 working with Horizon 6.2

By Dale Carter

With the release of VMware User Environment Manager 8.7 VMware added a number of new feature, all of which you will find in the VMware User Environment Manager Release Notes.

However, in this blog, I would like to call out two new features that help when deploying User Environment Manager alongside VMware Horizon 6.2. VMware’s EUC teams did a great job in my opinion getting these two great features added or enhanced to work with Horizon 6.2 in the latest releases.

Terminal Server Client IP Address or Terminal Server Client Name

The first feature, which has been enhanced to work with Horizon 6.2, is one I think will have a number of benefits. This feature gives support for detecting client IP and client names in Horizon View 6.2 and later. With this feature it is now possible to apply conditions based on the location of your physical device.

An example would be if a user connects to a virtual desktop or RDS host from their physical device in the corporate office, an application could be configured to map a drive to corporate data or configure a printer in the office. However, if the user connects to the same virtual desktop or RDS host from a physical device at home or on an untrusted network, and launches the same application, then the drive or printer may not be mapped to the application.

Another example would be to combine the Terminal Server Client IP Address or Terminal Server Client Name with a triggered task. This way you could connect/disconnect a different printer at login/logoff or disconnect/reconnect depending on where the user is connecting from.

To configure a mapped drive or printer that will be assigned when on a certain network, you would use the Terminal Server Client IP Address or Terminal Server Client Name condition as shown below.

DCarter Drive Mapping

If you choose to limit access via the physical client name, this can be done using a number of different options.

DCarter Terminal Server Client Name 1

On the other hand, if you choose to limit access via the IP address, you can use a range of addresses.

DCarter Terminal Server Client 2

Detect PCoIP and Blast Connections

The second great new feature is the ability to detect if the user is connecting to the virtual desktop or RDS host via a PCoIP or Blast connection.

The Remote Display Protocol setting was already in the User Environment Manager, but as you can see below it now includes the Blast and PCoIP protocols.

DCarter Remote Display Protocol

 

This feature has many uses, one of which could be to limit what icons a user sees when using a specific protocol.

An example would be maybe you only allow users to connect to their virtual desktops or RDS hosts remotely using the blast protocol, but when they are on the corporate network they use PCoIP. You could then limit applications that have access to sensitive data to only show in the start menu or desktop when they are using the PCoIP protocol to connect.

Of course you could also use the Terminal Server Client IP Address or Terminal Server Client Name to limit the user from seeing an application based on their physical IP address or physical name.

The examples in this blog are just a small number of uses for these great new and enhanced features, and I would encourage everyone to download User Environment Manager 8.7 and Horizon 6.2 to see how they can help in your environment.


Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy

Improving Internal Data Center Security with NSX-PANW Integration

Dharma RajanBy Dharma Rajan

Today’s data center (DC) typically has one or more firewalls at the perimeter securing it with a strong defense, thus preventing threats to the DC. Today, applications and their associated content can easily bypass a port-based firewall using a variety of techniques. If a threat enters, the attack surface area is large. Typically the low-priority systems are often the target, as activity on those may not be monitored. Today within the DC more and more workloads are being virtualized. Thus the East-West traffic between virtual machines within the DC has increased substantially compared to the North-South traffic.

Many time threats such as data-stealing, malware, web threats, spam, Trojans, worms, viruses, spyware, bots, etc. can spread fast and cause serious damage once they enter. For example, dormant virtual machines can be a risk when they are powered back up because they may not be receiving patches or anti-malware updates, making them vulnerable to security threats. When the attack happens it can move quickly and compromise critical systems which needs to be prevented. It is also possible in many cases that the attack goes unnoticed until there is an event that triggers investigation, by which time valuable data may have been compromised or lost.

Thus it is very critical that the proper internal controls and security measures are applied at the virtual machine level to reduce the surface area of attack within the data center. So how do we do that and evolve the traditional data center to a more secure environment to overcome today’s data center challenges without additional costly hardware.

Traditional Model for Data Center Network Security

In the traditional model, we base the network architecture with a combination of perimeter-level security by way of Layer 2 VLAN segmentation. This model worked, but as we virtualize more and more workloads, and the data center grows, we are hitting the boundaries when it relates to VLANs with VLAN sprawl, and also the increased number of firewall rules that need to be created and managed. Based on RFC 5517 the maximum number of VLANs that can be provisioned is 4,094. All this adds complexity to the traditional network architecture model of the data center. Other key challenges customers run into in production data centers is too many firewall (FW) rules to create, poor documentation, and the fear of deleting FW rules when a virtual machine is deleted. Thus flexibility is lost, and holes remain for attackers to use as entry points.

Once security is compromised at one VLAN level, the spread across the network—be it Engineering VLAN, Finance VLAN, etc.—does not take very long. So the key is not just how to avoid attacks, but also—if one occurs—how to contain the spread of an attack.

DRajan Before and After Attack

Reducing Attack Surface Area

The first thing that might come to one’s mind is, “How do we prevent and isolate the spread of an attack if one occurs?” We start to look at this by keeping an eye on certain characteristics that make up today’s data centers – which are becoming more and more virtualized. With a high degree of virtualization and increased East-West data center traffic, we need certain dynamic ways to identify, isolate, and prevent attacks, and also automated ways to create FW rules and tighten security at the virtual machine level. This is what leads us to VMware NSX—VMware’s network virtualization platform—which provides the virtual infrastructure security, by way of micro-segmenting, today’s data center environments need.

Micro-Segmentation Principle

As a first step let’s take a brief look at the NSX platform and its components:

DRajan NSX Switch

In the data plane of the NSX vSwitch that are vSphere Distributed Switches (vDS) and FW hypervisor extension modules that run at the kernel level and provide Distributed Firewalling (DFW) functionality at line rate speed and performance.

The NSX Edge can provide edge firewalling functionality/perimeter firewall to the Internet-facing side. The NSX controller is the control plane-level component providing high availability. The NSX manager is the management-level component that communicates with vCenter infrastructure.

By doing micro-segmentation and applying the firewall rules at the virtual machine level we control the traffic flow on the egress side by validating the rules at the virtual machine level, avoiding multiple hops and hair pinning as the traffic does not have to make multiple hops to the physical firewall to get validated. Thus, we also get good visibility of traffic to monitor and secure the virtual machine.

Micro-segmentation is based on the startup principal: assume everything is a threat and act accordingly. This is “zero trust” model. It is indirectly saying entities that need access to resources must prove they are legitimate to gain access to the identified resource.

With a zero trust baseline assumption—which can be “deny by default” —we start to relax and apply certain design principles that enable us to build a cohesive yet scalable architecture that can be controlled and managed well. Thus we define three key design principles.

1) Isolation and segmentation – Isolation is the foundation of most network security, whether for compliance, containment or simply keeping development, test and production environments from interacting. Segmentation from a firewalling point of view refers to micro-segmentation on a single Layer 2 segment using DFW rules.

2) Unit-level trust/least privileges What this means is to provide access to a granular entity as needed for that user, be it a virtual machine level or something within the virtual machine.

3) And the final principle is ‘Ubiquity and Centralized Control’. This helps to enable control and monitoring of activity by using the NSX Controller, which provides a centralized controller, the NSX manager, and the cloud management platforms that provide integrated management.

Using the above principle, we can lay out an architecture for any greenfield or brownfield data center environment that will help us micro-segment the network in a manner that is architecturally sound, flexible to adapt, and enables safe application enablement with the ability to integrate advanced services.

DRajan Micro Segmentation

 

Dynamic Traffic Steering

Network security teams are often challenged to coordinate network security services from multiple vendors in relationship to each other. Another powerful benefit of the NSX approach is its ability to build security policies that leverage NSX service insertion, with Dynamic Services chaining and traffic steering to drive service execution in the logical services pipeline. This is based on the result of other services that make it possible to coordinate otherwise completely unrelated network security services from multiple vendors. For example, we can introduce advanced chaining services where―at a specific layer—we can direct specific traffic to, for example, a Palo Alto Networks (PANW) virtual VM-series firewall for scanning, threat identification, taking necessary action quarantine an application if required.

Palo Alto Networks VM-series Firewalls Integration with NSX

The Palo Alto Networks next-generation firewall integrates with VMware NSX at the ESXi server level to provide comprehensive visibility and safe application enablement of all data center traffic including intra-host virtual machine communications. Panorama is the centralized management tool for the VM-series firewalls. Panorama works with the NSX Manager to deploy the license and centrally administer configuration and policies on the VM-series firewall.

The first step of integration is for Panorama to register the VM-series firewall on the NSX manager. This allows the NSX Manager to deploy the VM-series firewall on each ESXi host in the ESXi cluster. The integration with the NetX API makes it possible to automate the process of installing the VM-series firewall directly on the ESXi hypervisor, and allows the hypervisor to forward traffic to the VM-series firewall without using the vSwitch configuration. It therefore requires no change to the virtual network topology.

DRajan Panorama Registration with NSX

To redirect traffic the NSX service composer is used to create security groups and define network introspection rules that specify traffic from guests who are steered to the VM-series firewall. For traffic that needs to be inspected and secured by the VM-series firewall, the NSX service composer policies redirect traffic to the Palo Alto Networks Next-Gen Firewall (NGFW) service. This traffic is then steered to the VM-series firewall and is processed by the VM-series firewall before it goes to the virtual switch.

Traffic that does not need to be inspected by the VM-series firewall, for example, network data backup or traffic to an internal domain controller, does not need to be redirected to the VM-series firewall and can be sent to the virtual switch for onward processing.

The NSX Manager sends real-time updates on the changes in the virtual environment to Panorama. The firewall rules are centrally defined and managed on Panorama and pushed to the VM-series firewalls. The VM-series firewall enforces security policies by matching source or destination IP addresses. The use of Dynamic Address Groups allows the firewall to populate members of the Dynamic Address Groups in real time, and forwards the traffic to the filters on the NSX firewall.

Integrated Solution Benefits

Better security – Micro-segmentation enables reduced surface area of attack. It enables safe application enablement and protection against known and unknown threats to protect virtual and cloud environments. The integration enables easy identification and isolation of compromised applications faster.

Simplified deployment and faster secure service enablement – When a new ESXi host is added to a cluster, a new VM-series firewall is automatically deployed, provisioned and available for immediate policy enforcement without any manual intervention.

Operational flexibility – The automated workflow allows you to keep pace with VM deployments in your data center. The hypervisor mode on the firewall removes the need to reconfigure the ports/vSwitches/network topology; because each ESXi host has an instance of the firewall, traffic does not need to traverse the network for inspection and consistent enforcement of policies.

Selective traffic redirection – Only traffic that needs inspection by VM-series firewall needs redirection.

Dynamic security enforcement – The Dynamic Address Groups maintain awareness of changes in the virtual machines/applications and ensure that security policies stay in tandem with changes in the network.

Accelerated deployments of business-critical applications – Enterprises can provision security services faster and utilize capacity of cloud infrastructures, and this makes it more efficient to deploy, move and scale their applications without worrying about security.

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

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


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