Top 6 Features of vSphere 6

This changes things. It sounds cliché to say “this is our best release ever” because in a sense the newest release is usually the most evolved.  However as a four year VMware vExpert I do think that there is something special about this one.  This is a much more significant jump than going from 4.x

vsphere6vsphere6

vSphere 6.0 Public Beta — Sign Up to Learn What’s New

Yesterday, VMware announced the public availability of vSphere 6.0 Beta 2.  I can’t tell you what’s all in it due to the NDA, but you can still register for the beta yourself, read about what’s new and download the code for your home lab. There’s some pretty exciting stuff being added to vSphere 6.0 in

v6v6

Will VMware Start Selling Hardware? Meet MARVIN

The Register is running a story that VMware is preparing to launch a line of hardware servers.

marvinmarvin

VMware Pursues SDN With Upcoming NSX Offering

Earlier this week VMware announced VMware NSX – an upcoming offering that takes network virtualization to new levels. NSX appears to be somewhat of a fusion between Nicria’s SDN technology (acquired last year by VMware) and vCloud Network and Security (vCNS – formerly known as vShield App and Edge). Since I already had intentions to

NSX2NSX2

What Really Is Cloud Computing? (Triple-A Cloud)

What is cloud computing?  Ask a consumer, CIO, and salesman and you’ll likely get widely varying responses. The consumer will typically think of the cloud as a hosted service, such as Apple’s iCloud, or uploading pictures to Photobucket, and scores more of like services (just keep in mind that several such services existed before it

3pillars_f3pillars_f

Agility Part 2 — The Evolution of Value in the Private Cloud

When an IT project is commissioned it can be backed by a number of different statements such as: “It will reduce our TCO” “This is a strategic initiative” “The ROI is compelling” “There’s funds in the budget” “Our competitors are doing it” Some of these are better reasons than others, but here’s a question.  Imagine a

agility2agility2

Stacks, the Vblock and Value — A Chat with EMC’s Chad Sakac

…I reached out to EMC’s Chad Sakac to gain more insights from his perspective on how the various stacks…well…stacked up….

stacksstacks

Should You Virtualize vCenter Server (and everything else?)

When concerns are raised around virtualizing vCenter Server, in my experience they usually revolve around either performance and/or out-of-band management. The VROOM! blog at VMware just published a whitepaper that looks closely at vCenter Server performance as a VM versus native (physical) which speaks to these concerns as well as for other workloads. vCenter Performance

vcenter_virtvcenter_virt

When CPU metrics with Hyperthreading, Monster VMs and VMware Make No Sense

CPU seems like such a simple thing, but in the age of virtualization, hyper-threading and vNUMA, it can get quite complicated. In fact looking at some metrics can get you to lose your mind until you realize what’s really going on. Let’s jump right in to the original problem.

I encountered a VM with 16 vCPUs on a server with 16 physical cores (2 x 8). The VM was frequently getting alarms in vROPS (vRealize Operations Manager) as at times it would be at 90% or more for sustained periods, but the host server would show just under 50% utilization. This is illustrated in the graph below.

Screenshot_92

Click Image to Expand

Why would a VM with 16 vCPU be at 80% when the 16 core host is only at 41%. What’s going on here?

The first things we will need to explore are hyper-threading, NUMA and how different CPU metrics in VMware are calculated.

Hyperthreading

Hyper-threading was intended to solve an issue with a waste of potential resources in the CPU. It does not change the physical resources (the CPU cores) but more resources can be potentially tapped into by allowing two threads to be processed by the same execution resource simultaneously — with each physical core being an execution resource.

When hyper-threading is enabled it doubles the number of logical processors presented by the BIOS. In this example, our 2 socket, 8 core system with 16 cores total now presents 32 cores to VMware. Chris Wahl has an excellent post on this topic which I strongly encourage you to read, but for now I’m just going to “borrow” one of his graphics.

ht-image

Image taken from Chris Wahl’s post (link in article)

VMware’s CPU scheduler can make efficient use of hyper-threading and generally it should be enabled. The number of logical processors now doubles, providing a performance benefit in the range of 10-15% in most vSphere environments (depending on workload/applications, etc.).

But what about our scenario of a host which has only 1 “monster VM”?

Sizing a Monster VM with Hyper-Threading

The general rule here is that you should not provision more vCPUs than the number of PHYISCAL cores the server has. In our scenario there are 32 logical processors presented due to hyper-threading, but only 16 physical cores. If we provision more than 16 vCPUs to the VM it means that execution resources will now be shared for the VM. Now there are some exceptions here (test your workloads!), but is it generally recommended not to exceed the number of physical cores for this reason.

VMware has a blog post on this topic.  What is their guidance?

VMware’s conservative guidance about over-committing your pCPU:vCPU ratio for Monster virtual machines is simple – don’t do it.

For a deeper dive on the issues here please see Chris Wahl’s post (again) or this post on the VMware blogs about Monster VMs.

NUMA and vNUMA

In the interest of time I’m going to go too deep here, but let’s just say NUMA is a technology designed to assign affinity between CPUs and memory banks in order to optimize memory access times.

vNUMA was introduced with vSphere 5.0 which allows this technology to be extended down to guest virtual machines.

The bottom line here is that the mix of virtual sockets and virtual cores assigned matters. As this article shows, processing latency can be increased if these settings are not optimal.

First you’ll want to make sure that hot-CPU add is disabled as this disables vNUMA in any virtual machine and then you’ll want to make sure that your allocation of virtual sockets and virtual cores matches the underlying physical architecture or you could be adding some processing latency to your VM as noted in this VMware blog post.

One more point here. There’s a setting in VMWare called PerferHT. You can read about it here, but it basically changes the preferences in vNUMA. There’s no universal answer here as it will vary from application to application, but this setting is a trade off between additional compute cycles and more efficient access to processor cache and memory via vNUMA. If your application needs faster memory access more than it needs compute cycles, you may want to experiment with this setting.

BACK TO OUR PROBLEM…

As it turned out all of our settings here were optimal. We had one vCPU socket with 16 cores – matching the 16 physical cores on the server – and vNUMA enabled. If you are using a Windows guest you can download Coreinfo.exe from Sysinternals and get more detail on how vNUMA is configured within your VM.

But we still don’t have an answer to our question – why is VM CPU at 80% when the host is at 41% given 16 physical cores (host) and 16 virtual cores (VM)?

Is it possible that not all the cores are being used?  Let’s check — here is a graph from vCenter showing that all 32 logical cores are being used (and tracking within 10% of each other) but average CPU is 19% peaking at 27% over the past hour:

Screenshot_73

But then we look at the VM for the same time period and we see the same pattern except that CPU peaks at over 90% and averages 45%:

 

Screenshot_72

 

How can this be? The VM is triggering high utilization alarms when the host is at less than 50% utilization.

Let’s go to ESXTOP to get some additional metrics, but first we need to understand the difference between PCPU and “CORE” in ESXTOP:

Screenshot_90

Click to Expand

So PCPU refers to all 32 logical processors while “CORE” refers to only the 16 physical cores.

Now lets look at ESXTOP for this host.

Screenshot_91

Click to Expand

Notice how CORE UTIL % is reported at 78% while PCPU util is only 40%. That’s a big difference! Which one is right?

If we look at the Windows OS, we see that CPU at that same instant was aligned with the CORE UTIL% metric:

Screenshot_94

It seems that there’s a couple things going on here. First, the CORE UTIL metric more accurately reflects utilization for THIS Monster VM scenario as it averages across 16 physical cores and not 32 logical cores. Second it seems that the CPU utilization metrics which we tend to rely on in vCenter and other tools tend to follow the PCPU (hyper-threaded) statistics and not the “core” utilization.

A few graphs to quickly illustrate this. First once more here’s CPU for both the host and the 1 VM that is on it as reported by vROPS 6:

Screenshot_92

Same pattern in both but the host is averaged across 32 logical processors while the VM is averaged across 16 vCPUs, which results in the numbers being almost double for the VM.

We can also see this by looking at MHz rather than percent utilization:

Screenshot_96

Without breaking down the math, the number of Mhz consumed by the VM divided by the capacity of the host, does align with the CORE UTIL% metric.

One thing I could not figure out about this chart is why the host shows LESS Mhz utilized. There should be no averaging here – just raw Mhz consumed – so it’s escaping me why the host would show less consumed than the VM (not possible in raw Mhz). If anyone has an answer for this I’ll gladly update this post with attribution.

So if I’m using vROPS 6, what metric do I use to see actual core utilization without factoring for hyper threading? The documentation I must confess lost me a bit. Allegedly this metric exists but I couldn’t find it anywhere:

Screenshot_97

After some trial and error I did find a CPU Workload % metric which does appear to focus on the cores (no hyper-threading):

Screenshot_98

Again the pattern is identical except “Usage” (top) is averaged over 32 cores – not accurate for our scenario – and “Workload” (bottom) is averaged over the 16 physical cores.  Here the Workload metric (bottom) gives a far more accurate picture which aligns with the VM level metrics.  If we look at just the default Usage % metric we are left with the impression that the host has far more resources to give and that our vCPU allocation (or something else) may not be efficient, but that does not seem to be the case here.

So what would these metrics look like on a host with many workloads and no Monster VMs (more common)?

Screenshot_99

Different scales here which makes the bottom chart appear more volatile, but the gap between the two is not a doubling like we saw before. The numbers are much closer.

Now here’s a question that troubles me. The default CPU metrics in vSphere count all the logical cores but look at the peak above. If I looked at the default CPU graph, I’d think I was at 74% when the physical cores were actually at 88%. I can see how averaging across all logical cores can provide a better view of utilization, but it seems to me that the Workload metric (physical cores only) provides a better watermark for detecting bottlenecks.

CONCLUSION:

We’ve jumped about a bit here but if you’re still with me let’s try to nail down some conclusions from all this:

  • Hyper-threading does not increase execution resources, but it many cases it allows them to be used more efficiently depending on the workload (this benefit is often 10-15% in VMware environments).
  • The default CPU metrics in vSphere are averaged across all logical cores which includes those added by hyper-threading. This can result in confusing results when a single “Monster VM’ is running from a host
  • VMware’s guidance is to NOT exceed the number of physical cores on a host, when provisioning vCPUs to a Monster VM.
  • In vROPS 6 the Workload % metric appears to only look at physical cores and thus may be a better indicator for CPU bottlenecks in some cases.
  • vNUMA considerations including virtual to physical core allocation can impact performance.

As for our VM which was triggering CPU alarms, it appears that it is using an appropriate amount of resources on the host after all.  Now there’s a possibility that we could experiment with more cores and possibly get better results, but they key is we can throw out the 50% disparity between CPU utilization and VM utilization as bad data in this scenario.

And last but not least –

  • Measuring CPU utilization is not nearly as simple as we had thought.

One final note — this is my interpretation of what I am seeing. If anyone can offer better guidance (especially corrections) to anything I’ve posted here, please do so and I will be glad to update the post with attribution.

VM Snapshots — They can be a problem, but VVols in vSphere 6 can help

Snapshots in VMware have been an invaluable tool for years.  The ability to create an application consistent point-in time snapshot of a virtual machine has significant OPEX (or DevOps — take your pick) benefits. It can be used as an “undo” button for upgrades, it can facilitate clones and some replication solutions, but perhaps most commonly it is used to facilitate backups of virtual machines.

For me snapshots have always been a love-hate thing.  Wonderful feature but in some cases they’ve caused a lot of pain and disruption. In my vSphere 6 What’s New post I talk a bit about vVols — what VVols mean for snapshots just might be one of the least known and discussed features.

Here’s the issue.  A snap is created, the backup runs, and then the snap is closed.  It is this closing of the snap where the VM can become “stunned” for significant lengths of time.  I’ve seen this become an issue for highly transactional servers ranging from web servers, databases and email mail systems as well.

There’s even a VMware KB article that discusses this problem:

Screenshot_63

So what’s happening here? Think of this this way.

First the snap is opened.  From this point forward writes are not committed to the base virtual disk (VMDK) but a child VMDK.  The more writes that occur while the snap is open (often how long the backup takes), the greater the size of this child VMDK which will have to be consolidated.

 

Screenshot_64

Above you can see a VMDK with three snapshots open.  Writes go to the most recent snapshot, and the live state of the VMDK is actually a real-time calculation across this entire chain.  Once I discovered an Exchange server for which the backups were not properly configured — there was a chain of 58 snaps supporting a production Microsoft Exchange server! Yikes!

There’s actually an additional snapshot file that is created for application quiescing (Microsoft VSS) but there’s no need to go into that here.  Hopefully you already have an appreciation for how closing a snapshot can be problematic for transactional workloads.  These snapshots — and the child VMDKs created for them — need to be written back into the base VMDK.

For many VMs you might be able to backup and run snapshots just fine.  But in my experience, just an IIS server creating a steady output of IIS log files, can experience disruption during a snap close event — especially if you are doing a full backup. I’ve watched the snap close process freeze IIS servers to where web transactions are dropped and lost. And for large transactional databases you can just forget about it.

vSphere 6 and VVols

With the new VVol feature in vSphere 6 several things change.  First of all the base VMDK is ALWAYS the base VMDK.  It is always the write target.  The snapshots are now read only reference files that do NOT exist with a chain.  When the snap is closed, there’s nothing to ingest back into the base VMDK — it already has it!

 

VVol-VSS-1-300x252

This image is from Cormac Hogan’s post (link in article) which shows how snapshots are read-only references in vSphere 6 VVols.

This is a huge change from the previous method where writes went into the most recent snap in the chain and would have to be consolidated back into the base VMDK.  Now there’s nothing to consolidate when the snap is closed — the base VMDK is always the live state. VMware’s Cormac Hogan has an excellent post on this which goes into far greater detail on how this process works.

But that’s not all. VVols also enable the ability to offload snapshot functions to the array controller.  The implementation details may  vary among storage vendors, but the whole snapshot process can be offloaded to the storage array itself in some cases, providing instant and non-disruptive snapshots.

This is a huge change from vSphere 5 which should allow for backups and snap close operations on highly transactional servers where this might not have been possible in the past.  Impact free snapshot (and backuptennesse-vols-fans(2)) operations.

Now in full disclosure I’ve not had the opportunity to work with VVols in production yet, but perhaps you can see why I’m rather excited.  Non disruptive snaps and backups for ALL workloads would be a welcome feature.

Do you have any experience with snapshots with vSphere 6 and VVols? Post in the comments below.  Go VVols!

vSphere 6 (and VSAN 6) Now Available

The wait is over.  You can now download vSphere 6 and VSAN 6 from VMware.com.  I’ve written about the great features in vSphere 6 here and a lot of people are anxious to upgrade to start realizing the benefits of the new capabilities,  but hold on….before you do there’s some things you should probably review first.

First of all you’ll want to review this KB article which details compatibility considerations, upgrade considerations and much more.

If you’re using vCNS (vCloud Networking and Security) you will most definitely want to be reading this KB article before you start even making plans to upgrade.

You’ll also want to check out the vSphere HCL (Hardware Compatibility List) to see if things like your processors or your storage array will support vSphere 6.  The HCL even goes into specifics like VAAI primitives to show you which features are supported with which firmware releases on your storage array.  Also note that many storage arrays will support ESXi 6.0 with their current firmware release but support for vVols in some cases will not be available until a future firmware release.  As always check with your storage vendor.

Screenshot_44

Example of level of support detailed for a specific storage array varying with firmware version

You’ll also want to check with 3rd party vendors that integrate with vSphere.  This is basically any VIBs installed on host servers and anything that registers with vCenter Server, especially any plugins.  Backup/recovery and monitoring solutions are some of the most common here, but there’s also replication, storage acceleration and several others.  I’ve reached out to 5 vendors on the issue of vSphere 6 support it and none of them formally support it yet, but plan on delivering support in a matter of weeks or months depending on the vendor.  Whether you need to wait for formal support or want to be a pioneer depends on the use case and your tolerance for risk.  In some cases you may be able to “cheat” formal support while in other cases the risk may be just too great without formal support.

And last but not least read the releases notes!

Happy upgrading!

Top 6 Features of vSphere 6

Top 6 Features of vSphere 6

This changes things.

It sounds cliché to say “this is our best release ever” because in a sense the newest release is usually the most evolved.  However as a four year VMware vExpert I do think that there is something special about this one.  This is a much more significant jump than going from 4.x to 5.x for example.  It’s not just feature packed or increasing the maximums, although it does accomplish both of these.  vSphere 6 introduces a few new paradigms which have the potential to create a lot of value, efficiency, and also good old-fashioned performance.

In our clickbait, social media driven world, “listsicles” seem to be a favorite article style . When I began to look at vSphere 6 with all of the new features I thought to myself “where does one start”?  Perhaps just this once I’ll go full “buzzfeed” and list what I feel are the top 6 new features of vSphere 6. All without any diet tips, Tumblr feeds or embarrassing celebrity photos — I promise.

I think there’s some really game changing stuff here. Let’s dive in.

UPDATE (2/9/15):  This post has been updated to reflect details which have changed from the beta to GA. Changed information will be highlighted.

1) vVols (virtual volumes)

This is arguably the biggest new feature and has the potential to fundamentally transform how storage in approached in vSphere, so it demands that we spend a bit more time exploring this one.

VASA 1.0 ( vSphere Storage APIs for Storage Awareness) was introduced with vSphere 5 which enabled many features ranging from array integration, offloading of copying and zeroing operations, multipathing, and storage awareness, which gave vSphere insight into the relative performance of your storage tiers.

While these features were great, there were several limits, including that datastores could not offer granularity to individual virtual machines, but rather all virtual machines would inherit the capabilities of a datastore.  And while we could offload some functions to the array, snapshots were still based on delta files with copy-on-write mechanics.

While this is “OK”, what if every VM could have it’s own storage container and storage policy?

Today we spend a fair amount of time managing LUNs and Volumes in vSphere which in turn determine the storage characteristics.  My VM is on “SAN02-VOL03″ but what does that mean to me as an application owner?

What if the storage array through APIs could become “aware” of vSphere elements?  What if each VM was it’s own container and vSphere administrators no longer had to deal with the management overhead and complexity of LUNs and file systems?  Just provision a server and choose “Gold”, “Silver” or “Bronze” storage — or have this predetermined by a policy.

This is what vVols along with VASA 2.0 aim to provide. Chuck Hollis has a great post going into more detail on this but for now I’m going to “borrow” one of the slides from his post to illustrate how this facilitates providing the right capabilities to the right consumers.

Screenshot_91

[Click to expand]

vVols and VASA 2.0 could be a blog post in and of itself, but to keep things simple let’s just focus on a few key characteristics of vVols:

  • VMDKs are native storage objects

That sounds good, but what does this mean exactly? Well it means that the storage array is “aware” of each VMDK and that the complexity of LUNS and mount points are no more. This layer of complexity is now removed from vSphere administration — going forward administrators only need to focus on VMs and storage policies.

Screenshot_82

Traditional Storage versus vVols (click to expand)

 

  • Virtual Volumes

Each virtual volume maps to a specific VMDK.  Because of this exclusivity, SCSI locking is no longer necessary.

  • Storage Containers

In vSphere 6 a new logical construct is a Storage Container which can contain multiple virtual volumes.  Storage containers are managed by the storage array and can be used to group together storage that will share common characteristics and/or a common storage policy.

  • Single Protocol Endpoint

All storage is unified behind a single logical construct for I/O—called a Protocol Endpoint. With all storage traffic passing through this logical element

Screenshot_8

vVol — Protocol Endpoint (Click to Expand)

 

  • Policy Based Management

Now we can have policies that we apply to VMs to govern capacity, performance and availability. Rather than managing this on the back end with LUNs and volumes we can now simply apply policies that provide the desired capacity/performance/availability configurations on a per-VM basis.  We used to do this with scripts (or CLI) against hosts for specific LUNs — now we can simply define a policy and assign it to storage objects as desired.

  • Storage Array Integration

Storage vendors can integrate with the VASA APIs to offload I/O functions (array acceleration) and granular capabilities. This existed for some functions with VASA 1.0, but now with VASA 2.0 the opportunities to unlock the full capabilities of the storage array are available throughout the vSphere ecosystem.

For just one example of this, think of the way snapshots work today – a separate file is created which is basically copy-on-write which must then be reconstituted back into the VMDKs when the snap is closed. Many of you are already familiar with the performance impacts of these operations – which are especially common with backup and replication operations. Imagine if all this could be offloaded to the storage array for fast and space efficient snapshots!

And let’s not stop there as these benefits can be extend to provisioning, replication, deduplication, caching and more.  In my opinion this is HUGE — you may be familiar with the benefits of space efficient snaps and clones, but these were always outside the domain of native vSphere snapshots.  Now all storage vendors have the ability to provide hardware accelerated snapshots (big impact on backups) as well as instantly deploy space efficient clones for test/dev and more.   There’s a lot of implications here for replication and disaster recovery as well. Pictured below are just some of the vendors that have made commitment to supporting vVols.

vendorsIn a nutshell, the complexity of LUNs and volumes is removed from the vSphere administrator, while enabling policy-based management and hardware acceleration from storage arrays for many common functions. Fast and space efficient snapshots. Space efficient instant clones for test/dev.

We’ve had storage APIs for a few releases now, but this level of integration between the storage array and the hypervisor is new.  In many ways it’s a game changer.

(I’ll update this post in the future with links to more detailed vVol articles as they become available).

2) Fault Tolerance

VMware fault tolerance was always a fantastic solution but it’s use was always limited due to the restriction to only a single vCPU, no snapshots and more. Now these restrictions are being removed, opening up new possibilities.

If you’re not familiar with Fault Tolerance, a second clone of a VM is maintained in CPU-lockstep such that either VM in the pair could become unavailable and a single CPU cycle would not be missed, nor would any TCP connection be dropped. This is critical for transactional applications, e-commerce, VoIP and many more mission critical applications.

ft

Now with vSphere 6, Fault Tolerance is now available for VMs with up to four (4) vCPUs and 64GB of RAM, enabling it to be used for larger web servers, VOIP, databases and more.  You’ll want to test your applications first for latency and failover response, but this opens up fault tolerance to a whole new set of VMs that couldn’t leverage this previously.  Some may also want to consider this as an alternative to Microsoft Cluster Server (MSCS) in some scenarios.

vCenter Server is an obvious potential use case here, especially with the retirement of the vCenter Heartbeat product.  Some deployments of vCenter Server will be supported for use with FT based on the size and scale.  Exact details of the requirements for vCenter Server support are still being worked out. (Separate from FT, Microsoft Clustering for vCenter Server will also be supported).

vSphere 6 also adds support for VADP based snapshots (not user snapshots), enabling backups and replication. Also added are support for paravirtualized devices, and storage redundancy for Fault Tolerant VMs which is critical for many use cases.

3) vMotion Improvements

vMotion has always been an incredible feature in vSphere which helps to provide both flexibility and availability, but now several new features will allow its use to be significantly expanded:

  1. vMotion across virtual switches
  2. vMotion across vCenter Servers
  3. Long Distance vMotion

The last one refers to a dramatic increase in latency tolerance as noted in this tweet from this past VMworld:

Put those three together and you now have the ability to vMotion to different regions. I worked on a large datacenter migration project (petabytes) where we had to populate data mules and ship them to remote datacenters to “seed” the replication process. I can only imagine how much time and money could have been saved if this technology were available then.

Future enhancements will support for active-passive replication as well as vSphere Replication.

4) Policy Based Management

Update:  While Policy Based Management was featured in the beta, it seems that it has been witheld from the 6.0 release and will be introduced in a later update.  The Content Libraries feature mentioned below will still be in the initial 6.0 release as I understand it.

There’s a few components to this including a new Virtual Datacenter Object which is essentially a resource pool which can span multiple vSphere clusters and facilities the assignment of policies to VMs. For example you might want to create virtual datacenters for production and another for test/dev and have these span multiple sites (and clusters). In the initial release this will be limited to a single vCenter server, with plans to support multiple vCenter servers in a future release.

polixyAnother new logical construct is tags which can be applied to any VM. These tags can be used to automate the initial deployment of VMs and ensure that the proper policies are maintained throughout the VM’s lifecycle.

Also worth a mention here is the new Content Libraries feature. Very often in VMware environments administrators will carve out datastores and/or folders for VM templates, ISOs, vApps, scripts and more. Now you can have a full content library for your virtual datacenters that can even be published across them.

With the ability to aggregate this content into a library, which can be shared and published to multiple vCenter servers, content can be standardized and made more accessible. You might even want to have different content libraries for different teams, business units and/or applications.

5) Installation and Usability Improvements

This is sort of a collection of multiple features, but I’d like to briefly touch on each as they are significant:

a) vCenter Server Appliance with guided install from ISO image

In vSphere 6 the vCenter Server Appliance has made improvements with feature parity and is now provisioned using a guided process from a self-contained ISO. I went through the guided process and it is much more quickly deployed than in prior versions.

b) Infrastructure Controller

With vSphere 6 a new Infrastructure Controller (IC) service is introduced which provides the following functions:

  • Single Sign-On (SSO)
  • Licensing
  • Certificate Authority
  • Certificate Store
  • Service Registration

Depending on your topology and requirements the Infrastructure Controller can be deployed within a vCenter Server or as its own independent server. This not only facilitates scale and more complex topologies but it simplifies both deployment and management.

c) vSphere Web Client Improvements

vSphere 6 still ships with a traditional thick client (C++) but newer functionality specific to 5.5 and later will require the Web Client which has been substantially improved in this release. The login time has been reduced to about 3 seconds while other common functions within vSphere have been improved by several full seconds (such as from 4 seconds to 1 second for invoking the Data Center Action menu).

Screenshot_83

The task pane returns to the bottom in the improved vSphere Web Client (click to expand)

 

Not only is the Web Client significantly more responsive in this release but navigation has been significantly improved by providing more right-click menus and adding the tasks pane back to the bottom of the screen.

The combination of the performance and usability improvements makes it easier to be more productive in vSphere as well as making the experience more enjoyable.

6) vCloud Air Integration

Hybrid_CouldYou already have a vSphere infrastructure but what if you could quickly add for unplanned capacity using vCloud Air and make a hybrid cloud?

What if you could quickly set up full disaster recovery capability for your most important virtual machines using vCloud Air with 15 minute recovery points?

vSphere 6 has built in integration with the vCloud Air service allowing you to quickly tap into these hybrid cloud capabilities.  On the backup and DR front, vSphere 6 features RPOs as low as 15 minutes, allowing you to effectively use the vCloud Air service as a hot site for your production workloads, with support for both failover and failback operations.

Recently I wrote a review of VMware’s vCloud Air OnDemand service and I was honored that VMware had elected to share it. Rather that talk about it here, I’ll just link here to my post on vCloud Air for more information on that service.

Note:  an earlier version had stated that RPO’s would be 5 minutes.  This was based on information communicated during the beta.  In the initial (GA) release the RPO will be 15 minutes.

Honorable Mention

Of course there’s many more features than just these six, so here’s a few I want to just briefly mention:

  • Storage I/O granularity improved to per -VM basis (was per LUN).
  • Network I/O control allows bandwidth reservations for the VMs that need it.
  • 64 node clusters hosting up to 8,000 VMs
  • VMs up to 128 vCPUs and 4TB of RAM
  • Hosts with up to 12TB RAM, 64TB datastores and up to 1,000 VMs
  • NFS 4.1 client enables multipathing, improved security, improved locking and less overhead for NFS storage.
  • vCenter Server resiliency — vCenter Server will now attempt to “self-heal” at several different levels in order to improve availability.
  • vSphere Replication now supports RPOs of as little as 15 minutes.

There’s a lot here, and the combination of vVols with VM level policy management and tagging will be huge.  Performance benefits aside, administrators can now organize and combat the configuration drift of VM sprawl by designing policies that will automatically place VMs on the desired class of storage, with the appropriate performance and availability policies.

Many of these features are worthy of their own blog post, but I hope this quick list introduced some of the reasons why I think vSphere 6 is one of the more significant releases in VMware’s history.

Best of 2014

These lists typically annoy me but I was curious what some of my most popular content was and since I have it right here….

The most popular blog post by far was “Exploring VMware’s New OnDemand Private Cloud” which was shared over 650 times on social media.

Below are some of the most popular tweets of the year, several which came at the Vice President’s expense:

Exploring VMware’s New OnDemand Private Cloud (Part 1)

Screenshot_108UPDATE:  vCloud Air OnDemand is out of beta and has now entered an Early Access Program for which you can sign up here.

Recently I’ve had the opportunity to explore a beta of VMware’s upcoming cloud offering – vCloud Air OnDemand through their Ambassador program. I wanted to share my observations and experiences, but there’s so much to talk about, I found it better to start with an introductory post and drill deeper with a walk through some of the details in a future post.

The quick version is that vCloud Air’s Virtual Private Cloud OnDemand is pretty much what it sounds like. Hosted IaaS (Infrastructure as a Service) running on VMware, enhanced with SDN, with on-demand availability and pricing — meaning that you are billed only for what resources (CPU, memory, disk, etc.) are actually consumed. It’s like the electricity meter on our homes, but this is measuring the resource utilization of your virtual datacenter in the “cloud”.

Amazon (AWS), Azure and Google are on most everyone’s short list for IaaS service providers but there may be some good reasons to put VMware on your short list as well.

The vCloud Air service is compelling for several reasons. To start, it runs VMware vSphere which provides easy and familiar methods for integrating with existing on-prem infrastructure. Perhaps you have a new project but don’t have time to wait to add more hardware and capacity, but still need to maintain operational methods and security. For many use cases vCloud Air Private Cloud will be seen as compelling — especially where vSphere is already used. And with over 99% of the Fortune 1000 using VMware, that’s…well…most of us.

Before we explore Virtual Private Cloud OnDemand in more detail, I’d first like to step back and review different cloud types, use cases.

Private, Public, Hybrid

The original key distinctions between private and public cloud were mostly control and multi-tenancy. With a private cloud the hosted infrastructure was exclusively yours and therefore afforded more control, whereas in a public cloud your workloads might be shared with those of others on the same hardware (multi-tenancy) which could lead to the “noisy neighbor” problem.

Advances in hypervisors, I/O virtualization, SDN and orchestration have made this a bit less of distinction now days as more control is available to the consumer and the “noisy neighbor” is not the threat that it once was.Hybrid_Could

A Hybrid cloud then is essentially a combination of an “in-house” private cloud and infrastructure from an external service provider. A perfect example is a business that runs VMware vSphere internally in their datacenter. Let’s say a new project comes along, and rather than buy new infrastructure (and incur the associated delays) they could just logically extend and scale their existing vSphere infrastructure to a hosted offering, and be billed only for what is consumed.

Is vCloud Air Hybrid or Private?

In 2013, VMware launched the vCloud Hybrid Service (vCHS) which was positioned as the the hosted cloud infrastructure needed to evolve an on-premises environment into a hybrid cloud.  The vCloud Connector facilitated building a unified view of the hybrid cloud, allowing the ability to view, manage and migrate workloads from either the on-premises side or the hosted side.

Just this past September the service was re-branded as vCloud Air with the service offering now called Virtual Private Cloud (a dedicated option is available). What changed that it’s now called a private and not a hybrid cloud? Yes, there’s a bit of marketing here but also a pretty important point.  Private cloud is all about control.  Do you control the security, the operations, the processes?vchs-vca1

When you start with the vCloud Air service you create a virtual datacenter.  There is no external access until you establish firewall rules, public IPs, SNAT/DNAT rules, routing and more.  There’s also VPN and load balancing services built in.

If that sounds like a lot, it’s not and it’s quite straight forward as you’ll see in the next post, but the point is that you have such a strong level of control that really can be considered a private cloud.  It’s like the difference between ordering a sandwich someone else designed versus building your own.   As an engineer who has encountered the friction and delays that silos bring, I found it liberating to be able to quickly design the virtual datacenter — network, storage, compute — to my requirements.  And of course if  you integrate the Virtual Private Cloud with an on-premises environment, you still have a hybrid cloud spanning those two environments.

Introducing vCloud Air Virtual Private Cloud OnDemand

The “original” vCloud Air Service that went live last year is Virtual Private Cloud.  It is powered by vCloud Director, providing VMware users with a familiar construct and interface with their on-premises environment.  With this service, capacity is purchased in “blocks”.   For example a starting block might consist of 20GB of memory, 10Ghz of CPU and 2TB of storage (pricing as of November 16, 2014 shown below).Screenshot_111

The new OnDemand service has many similarities with the original service.  They both run vSphere and vCloud Director.  They both employ SDN using VMware’s own offerings. They both integrate into vCenter Server using the vCloud Air plug-in.  They both allow stretched Layer 2 and Layer 3 so that you can “bring your own IPs” and also feature Direct Connect options (private circuit).

My understanding is that the OnDemand service is a new “pod” within the vCloud Air service meaning that it is a new and separate rack design and configuration.  The new OnDemand service — as it’s name would suggest — uses an OnDemand pricing model.  Rather than purchasing “blocks” of capacity you will be billed for what you consume as you consume it.  I haven’t done much for the past 24 hours but below you can see a screen shot of my billing for that period, broken down by CPU, memory, storage (SSD and standard tiers), and public IPs.

Screenshot_7

Click to expand

Each account has a single billing point but as we’ll see in a future post, it is possible to create multiple virtual data centers (VDCs) within your account to both track internal costs and well as to control access.

Use Cases for Virtual Private Cloud OnDemand

There’s many different use cases that are a very good fit for the OnDemand service.  If you’re a new company without much capital you might want to just use the virtual datacenter as your primary datacenter.

If you’re a medium or large business with an established on-prem vSphere infrastructure, you might elect to keep your most critical applications and data on premises, but still leverage the OnDemand service for seasonal capacity, test/dev and new projects.

I was working at a Fortune 500 once when a new project came up which required a large amount of  web servers, databases and middleware.  How nice it would have been — and how much more quickly we would have been able to execute — if we could have simply defined our vApps in Virtual Private Cloud OnDemand and then clone and distribute them as needed in the vCloud Air service.  You might even choose to keep the databases on-premises but put the web tier out in the cloud.  You have the flexibility to align your workloads between on-premises and vCloud Air with whatever balance and topology works best for your organization, your security and operational requirements — you have the flexibility to allocate as you see fit.

Disaster Recovery

As you could imagine, disaster recovery for on-premises vSphere deployments is a very popular use case and quite straight forward to setup.  Today, the Disaster Recovery option is offered as a discounted tier on the original Virtual Private Cloud Service but it is my understanding that this will move to the OnDemand service in the future.  This would be a very effective pricing model as when using the capacity for hot-site replication, most of your resources in a passive state will be storage.  CPU and memory would be at relatively low levels until a fail-over occurred at which point they would increase with all the instances coming on-line.  OnDemand capacity when you need it.

Sign Up and Getting Started

I’ll go through a detailed walk through later, but the effort required to start creating VMs and consuming resources is relatively low.  I simply registered for the service, supplied a credit card, and once I was confirmed I was off creating my virtual data center and spinning up virtual machines and vApps.  This was my first time using vCloud Air but it was not my first time using VMware and as a result it didn’t take me much time to quickly find my way around and be productive within the vCloud Director interface within the vCloud Air service.   Within a few hours of signup, most should be able to define their networks and start provisioning VMs.

VMs, vApps and Catalogs

Within vCloud Air there is a public catalog from which you can instantly provision new VMs.  At this time, the public catalog includes multiple editions of CentOS, Ubuntu and Windows Server.  The Windows Server VMs will incur a licensing surcharge for their use which is prorated to an hourly rate.  In other words you are effectively renting the Windows Server license cost by the hour.

There’s two other important ways to populate your own private catalog within vCloud Air.  First you can import any OVA into your private catalog as either a URL link or a local file — which includes the over 1700 virtual appliances available on the VMware Marketplace.  The second way is to simply upload your own ISO to your catalog.  Just to prove a point that it could be easily done, I uploaded a Windows ISO to my private catalog in vCloud Air and I was able to build a VM from scratch right form ISO.  Also using the vCloud Connector you can even keep your catalogs in sync between our on-premises vSphere environment and vCloud Air.

vApps are a vCloud Director construct which solves several problems.  You can add multiple VMs and define rules for how they should work together.  A vApp can be an n-tier application or just a set of servers that need to be managed by a common team.  You can define leases on vApps as a cost control measure (i.e. power off after x hours, delete storage when off for x days) and even fencing, which ensures VM clones which exist in multiple vApps have unique MACs and IP addresses.  More on this later but there’s a lot of rich capability here for designing and managing your virtual datacenter.

Unified View

The vCloud Air plugin that is built into current versions of the vSphere client provides support for administering vCloud Air right from within the vSphere Web client.  The video below provides a walkthrough of the functionality available in the vCloud Air plugin.

Monitoring

Having run administered many vSphere environments I’ve been somewhat spoiled by the ability to quickly extract rich metrics on VMs and hosts using vCenter and even more with vCOPS.  In the vCloud Air environment you can see your CPU, memory and storage utilization for your virtual datacenters and vApps but that’s about it.  The hosts really don’t need to be in the picture (that’s sort of the point of a cloud service) but it would be nice to know some key VM metrics (what’s my storage latency or memory allocation over time?

Two things here.  One is that there’s nothing stopping you from using the monitoring solution of our choice. Want to use Microsoft System Center, CA UIM, Nagios, etc?  Use whatever processes you use today in house.  The second thing is that VMware has a robust monitoring solution in vCOPS.  I would not at all be surprised if VMware were to release a version of this that would work within vCloud Air in the future.

UPDATE:  The vCloud Air adapter for vCOPS was released in July, 2014.  Below are some screenshots of vCOPS monitoring vCloud Air with more at the link:

vcops1

Click to expand

 

Summary

There’s much more here in terms of features and even connection options that I haven’t drilled into here and which I’ll try to explore in future posts. But just to back this up a bit, many IT consultancies have suggested that hybrid cloud is the new normal — the business having the ability to consume on-prem and hosted capacity as needs arise, with use-case flexibility and functional integration (i.e. the vCloud Air plug-in in vSphere). Some cloud providers will require you to make adjustments to operational procedures and security, but vCloud Air does a good job of making this feel seamless for VMware shops. Also keep in mind the appeal of multi-cloud (using more than one cloud service provider) which can be used to mitigate risk, provide flexibility and expand DR options.  And if you don’t already have a DR solution you may want to take a look at vCloud Air’s Disaster Recovery Service.

Most companies will want to explore options for both hybrid cloud and multi-cloud scenarios for many compelling reasons.  As a long time VMware vSphere engineer, I found the vCloud Air service very accessible and easy to quickly get started with.   If you have a significant VMware vSphere deployment in our organization or even if you are just starting out, you owe it to yourself to include vCloud Air in your short list of options.  With the new OnDemand service with its utility pricing model being prepared for launch and more datacenters being added globally, the vCloud Air solution is worth taking a close look.

VMware vSphere 6 — What’s New?

v6vSphere 6 has been in public beta for several months now and this week at VMworld some of the new capabilities are now public. vSphere 6 remains in beta for a future release (sign up here!), but let’s take a quick look at some of the new features that have been announced (so far)

SMP for Fault Tolerance

Just a quick overview here. Fault Tolerance is a pretty neat feature that can keep a second copy of a VM in complete lockstep for HA purposes. The second VM has it’s own VMDKs which can sit on a different datastore or SAN, while each CPU transaction is maintained on both servers. This is a great way to provide redundancy for applications which can’t afford to lose cycles during a fail-over event, but the Achilles heel was always that it was limited to a single vCPU.

v6_FT

VMware announced earlier this year that it would be discontinuing vSphere Heartbeat and now we know why. With Fault Tolerance being able to support VMs with up to 4 vCPUs in vSphere 6, it would no longer be necessary for high availability to be provided by in-OS clustering.  VMs of up to 4 vCPUs and 64GB of RAM can now enjoy the benefits of VMware Fault Tolerance.

vMotion Improvements

Some of the vMotion improvements announced include being able to vMotion across difference vCenter instances, across routed networks (this “may” work now but was never formally supported), and perhaps most importantly long distance vMotion.

BwC4PLgIQAAsoo7The latency tolerance for vMotion will be increased from 10ms to 100ms in vSphere 6! With this generous of a tolerance for latency so many more vMotion scenarios would now be a possibility without the normal geographic penalties. Personally, I think VMware should demonstrate this capability by vMotioning a VM to an EVO:RAIL cluster in a hot air balloon with a 4G LTE wireless network.

vVOLS

This is a huge feature in my opinion – a whole evolution beyond what VAAI introduced — and rather than try to drill deep here I’ll try to stick to a simple overview. A vVol is a new logical construct that appears as a datastore in your admin tools, which allows the virtual disk to be a “first class citizen” in storage (versus the LUN or volume). A vVol does not use VMFS but is a new abstraction layer that enables object based storage access (with your VMDKs being the objects).

I found a good illustration of a “before and after” view of all these pieces on Greg Schulz’ StorageIO blog which are shown below:

BEFORE vVOLs

BEFORE vVOLs

WITH vVOLs

WITH vVOLs

 

There’s several things going on here which I’ll just quickly touch on. First there is one protocol end point now versus many as illustrated below. This enables more API capabilities to be exposed and if I understand correctly, VMware has plans to allow third parties to develop filter APIs here.

download (2)

Protocols are consolidated into a single endpoint

 

vVOLS are hardware integrated much like VAAI which means the storage vendors will develop their definitions for the API to activate the capabilities of their storage arrays. For example one capability is the ability to offload the snapshot function from a copy-on write flat file – to have the storage array handle it. While snapshots are an awesome feature of vSphere (which are not backups by the way), I’m not a big fan of the copy-on-write delta file method. I’ve seen snap chains 40+ levels deep (without anyone knowing) and snaps that were left open for months until the datastore filled up. By offloading snapshots and other operations to the storage array these things can be handled a lot more effectively.

I didn’t even get to storage profiles yet which allow to define what characteristics a certain VMDK should have. There’s many scenarios here but at a high level just removing the complexity of LUNs and RAID characteristics from admins is a big deal. When a VM is provisioned the admin needs only to select the storage policy (or one is forced for them) and the desired settings are enforced without the complexity being visible.

With that very basic into a highly encourage you to read one or more of the following blog posts which go FAR deeper into vVOLs, how they work, and their benefits.

Also check out what EMC, NetApp and Nimble Storage are doing with vVols, just to name a few.

Virtual Datacenter

This is a new logical construct within vSphere which allows you to enjoin multiple vSphere clusters into one construct to force consistent policy settings, provide a top level management point and facilitate cross-cluster vMotion.

Improved Web Client

The web client has significantly improved with each release but many (like me) find the web client to be a bit slow at times. It’s clear that VMware has spent some time on this as from using the beta I can assure you that there is a significant improvement in response time between the 6.0 and 5.5 web clients.

SUMMARY

That’s just a quick summary of some of the features that were mentioned in the general session. Even more details should be available over time as vSphere 6 grows closer and closer to a GA (General Availability) release. If you’re anything like me, you probably can’t wait for vSphere 6 – perhaps the biggest feature I’m looking forward to is vVols. Until then, happy virtualizing!

VMware Announces EVO:RAIL for the Software Defined Data Center

VMW-LOGO-EVO-Rail-108-300x278The much rumored “MARVIN” has manifested today as EVO:RAIL which represents VMware’s entry into the “Infrastructure In-A-Box” or hyper-converged market.

Each “RAIL” consists of a block of four (4) x86 rack mount servers available from a list of partners, with VMware vSphere and VSAN. Because EVO can scale this solution will likely find acceptance in both branch offices as well as some larger scale-out designs – all with an HTML5 front end. Customers can now simply procure virtualization infrastructure — including storage — by purchasing multiple “RAILs” as needed for scale

Screenshot_9

“Shall we dance?”

This is a truly a software defined infrastructure solution which enables IT shops to procure infrastructure through a single vendor and scale-out as needed. Nutanix was the first to find success with this business model, and others will be sure to follow (also see Cisco and Simplivity) . I expect that this will be an increasingly popular (and disruptive) trend in the marketplace.

Also EVO RACK will be announced as being in the tech preview stage which will be intended to scale to multiple server racks of SDDC infrastructure.

Screenshot_5

More details will be announced later in the day, but for now be sure to check out Duncan Epping’s announcement post as well as VMware’s EVO:RAILS site for more details.

UPDATE:  Also see VMware CTO Chris Wolf’s announcement post on EVO RAIL here.vmw-evo-rail-screen-2

Get Excited for VMworld 2014!

picard_giddy

Captain Picard can’t contain his enthusiasm for VMworld 2014

It’s the season for VMworld and all of us are getting a bit excited. I’ve never been to VMworld (and won’t this year either) but I’m still quite excited about what this VMworld will bring. Why? I’m glad you asked.

The two big reasons are what’s going to be announced/revealed as well as all the great ways to follow VMworld remotely (I’m am expert at this now!). My mind is already racing about designs, use cases and planning around deploying several elements that these new capabilities we expect to be announced.

vSphere 6

This is all under NDA so we can’t talk about all the exciting new capabilities just yet, but if you’ve participated in the vSphere 6 beta you know that there’s some pretty major features we can expect to be announced here and possibly a surprise or two yet. One of the features we do know a bit about are….

vVOLs

vVOLS aren’t really a new concept as it was introduced at VMworld 2012 as a preview of where VMware would be going with storage. Over two years in the making and now with the overwhelming support of VMware’s storage partners (EMC, NetApp, Nimble Storage and more) vVols are poised to make a big splash. More on this after the embargo is lifted but here’s some available content from VMware on vVols until then.

Infrastructure-In-a-Box

Call it hyperscale, scale-out, or software defined (all of these work) but we are basically talking about modular hardware sold as single units which can be enjoined to form large pools of vSphere infrastructure. We’re not just talking about vSphere here, but also software defined storage (i.e. VSAN) and possibly SDN as well (i.e. NSX). Nutanix is one vendor who already sells hardware based on this model and quite successfully.

There’s been rumors all summer about VMware offering such a single box model which has so far been named MARVIN, Magic and Mystic if I’m not mistaken. Now we’ll get a chance to see the details behind what may be VMware’s entry into the hardware market. Also I wouldn’t be surprised at all to see some other big names making similar moves in this new and growing space.

PernixData FVP 2.0

I posted on PernixData FVP 1.5 here (which won “Best New Product” at VMworld 2013 and 2.0 will be a big jump with some exciting features – including the ability to use memory on your ESXi hosts as an acceleration tier (read cache and clustered write offloading).

PernixData is planning on having a big presence at VMworld this year – be sure to check them out

vCloud Air

Today VMware announced the re-branding of vCloud Hybrid Service (vCHS) as vCloud Air and also introduced some new vCloud Air pricing calculators. I think VMware has a growing story here with their public cloud offering and it’s integration with vSphere based on-prem private clouds.

A growing differentiation point with cloud providers is services on top of the stack and VMware recently introduced disaster recovery a few months ago. I hope to see some enhancements and possibly even new services and/or pricing options announced at VMworld.

Sessions

Sessions are a huge part of the value of VMworld. These sessions are recorded and (in time) are made available for on-demand playback (access required). Duncan Epping has taken the time to highlight some of this year’s “must attend” VMworld sessions here.

Keeping Up Remotely

Like I said I’m an expert on this. Several of the general sessions will be available via live stream and there’s twitter and bloggers as well. It’s not the same as being there but it’s not hard to keep up with some of the details and big news either.

All the details on VMworld social media from hashtags to bloggers and more are available here. Also don’t forget the official VMworld app and the live stream of the general sessions.

Looking forward to a great VMworld and some exciting new solutions and offerings that will help us solve problems, fill gaps and create value. Have an enjoyable and safe VMworld whether your attending in person or remotely!

Software Defined Speed — A Look at PernixData FVP

pernixdata_logoPernixData FVP is a solution I’ve worked with in one environment for perhaps the past 6 months or so. I’ve been meaning to write about it (more than just tweets anyway) for some time, but I’m first now getting around to it.

The first question of course is “what does PernixData FVP do and why might I want it in my vSphere infrastructure?”. The short answer I usually give is that it’s Nitrus Oxide for your storage tier – just add FVP to your existing storage infrastructure and enjoy the speed (plus it’s legal)!

The longer answer is a bit more detailed than that, and first it would be helpful to have a quick overview of various storage architectures.

STORAGE ARCHITECTURES

Traditional Storage Array

sanstockHere we are talking about hardware that is designed to offer up storage via usually fiber channel, iSCSI or NFS protocols. For the purposes of this article, most any hardware based storage array from NetApp, EMC, Nimble Storage, HP, Dell and many others fits this definition.  This is a tried and true design, but as our capacity and performance needs grow, scale-out ability can become an issue in some environments (especially Google, Facebook, etc.).  In fairness some storage array vendors have implemented scale-out capabilities into their solutions, but for our purposes here I am simply trying to build a distinction between architectures at a VERY high level.

Hyper-Scale

Remember scale-out NFS and Hadoop? These designs typically did not rely on a monolithic storage array but multiple nodes using direct-attached storage and logically joined by…software.  First we had “software defined” compute with VMware abstracting the CPU and memory resources of server hardware.  Now we are abstracting at the storage controller level as well to unlock more potential.

Recently several vendors have had success with incorporating Hyper-Scale concepts into virtual storage arrays for vSphere, including Nutanix, VMware (VSAN), Simplivity, and more. Hyper-scale infrastructure is truly “software defined” as software and logical controllers are the key to making this distributed and scalable architecture work.

Screenshot_74

Click to enlarge

Occasionally this design is referred to as “Web Scale” as it does invoke a highly parallel environment designed for scale, but I prefer the term Hyper-Scale for several reasons, including that the use cases go far beyond just “web”. We’re talking about applying web scale principles to present “software defined storage”.

Considerations with Hyper-Scale

If write activity is in progress on a server node and it crashes hard before the data is replicated, what happens? (the answer is “nothing good”). The solution here is to write in parallel to two or more nodes (depending on your tolerance for failure settings). This is why a 10GB or better backbone is critical for hyper-scale designs – every write needs to be copied to at least one more host before it is considered to be committed.

Another consideration is locality to processor. For some applications anything under 20ms of latency is “adequate”, but some mission critical OLTP systems measure latency in the fractions of milliseconds. For these applications, latency can be significantly reduced by having the data closer to the CPU rather than having to fetch it from other nodes (more on this later).

Enter PernixData FVP

So let’s say you have an existing vSphere infrastructure and you have a storage array that while it could benefit from better performance, you are otherwise comfortable with. With PernixData FVP you can keep your existing storage array — eliminating the CAPEX burden of a new storage array — and accelerate it by decoupling performance from the storage array onto a new logical “flash cluster” that transcends your server nodes.

Screenshot_75

Click to enlarge

There are other solutions for adding flash-based read cache to your environment including vSphere’s vFlash capability, but most are local only (no flash cluster concept) and don’t offer the ability to cache writes.  PernixData FVP is unique in my experience in that it is a true flash cluster that transcends across your server nodes that will accelerate BOTH reads and writes.

INSTALLATION

I’ve done this more than a few times now but I must say it’s rather straight forward.

First you will need to install some flash in your servers. In the environment I worked on we used FusionIO PCI cards, but SSDs will work as well. How much flash should you use? It depends on your performance profile and objectives, but as a general starting point, about 10% of the total size of the dataset you wish to accelerate is a usually a good place to start.

Then you install PernixData FVP which is done in two steps. First there’s a component you install on your vCenter server which adds an additional database to track some new flash performance metrics. Once installed you can managed and view the flash cluster from the vSphere Client (including the vSphere Web Client as of FVP 1.5).

Screenshot_76

Managing the Flash Cluster from the vSphere Web Client (click to enlarge)

The second step is to install the FVP VIB (vSphere Installation Bundle) on each ESXi host. I must have installed and uninstalled the FVP VIB several dozen times by now and it’s quite easy – just a standard ESXCLI VIB install.

First put the ESXi host into maintenance mode (stopping any active I/O) and perform the install ( a single ESXCLI command) and exit maintenance mode, and repeat for all additional ESXi hosts in the cluster.

CONFIGURATION

Once you define and create the flash cluster, you can designate policy by datastore or VM. The two policies are write-though and write-back. With a write-through policy you are only using the flash cluster for reads – the most commonly used blocks as determined by efficient algorithms are maintained on the flash cluster for quick access. Not only does this reduce storage latency, but it reduces the IOPS load that your storage controller must process which should result in a performance improvement on the storage controller as well.

With the write-back policy writes are also processed by the flash cluster. Writes are written to the flash cluster (two nodes for failure tolerance) and are then de-staged back to the storage array as performance allows. The net result is that the commit time or latency from the application’s perspective is vastly reduced — incredibly important for write-intensive (i.e. OLTP) applications.

FVP_graph2

1 Day IOPS Chart for a database VM (click to expand)

The graph above shows a chart (from the vSphere Web Client) of a database server accelerated by PernixData FVP for the past day. The purple line shows the latency that is incurred at the storage controller level, but the blue line is what the VM or application “feels”. The orange line represents the latency to local flash which is measured in fractions of a millisecond. The distance between the purple and blue lines is latency that has been effectively removed from the application by PernixData FVP.

FVP_historicalAlso one nice feature about FVP is that it reminds you right in the vSphere client what it is doing for you.  In the environment I work on, it has saved almost 2 billion IOPS (pronounced “Beeeeeelion”) and 87TB of storage traffic just in the past 25 days.

Nitrus Oxide For Your Storage Array

In review, now you can see why I say PernixData FVP is much like adding Nitrus Oxide to a car (and of course being legal). You don’t have to buy a new car – you can just make the one you already have faster. And if you buy a new car (or storage array) you can still use your server-side flash cluster to accelerate it.

Much of what makes PernixData FVP special is the clustered file system that enables it to quickly and efficiently process writes to multiple hosts at once. This capability makes PernixData FVP a great fit for write-intensive transactional applications for which latency is key. Or maybe you have an array with slower SATA disk and you might find it more cost effective to simply accelerate it rather than getting a new storage array. Either way adding a server-side flash cluster to your vSphere cluster will significantly boost your performance. The DBA team in this environment has seen the time duration on some batch jobs decrease by over 900%.

What’s Next?

PernixData isn’t done yet. Their next release will include the following features:

  • RAM (memory) as a storage tier
  • NFS Support
  • Network Compression (reducing replication throughput)
  • Topology Aware Replica Groups (control over the hosts used for DR and/or performance considerations).

The biggest feature there is RAM support. That’s right, you’ll be able to skip the flash if you prefer and use the RAM in your host servers as your clustered read and write cache. Just buy your host servers with the extra RAM capacity you want to use as cache and add FVP. And because memory is close to the CPU it should be quite fast. I’m looking forward to testing this capability when it comes out of beta and I’ll try to follow up with a post on that experience when the time comes.

The addition of network compression should also reduce the amount of data to be transmitted. ESXi already compresses memory pages because even with the CPU overhead it will increase performance by reducing swapping. FVP is using the same concept here to reduce the amount of data that has to be transmitted across the cluster.

In summary I found PernixData FVP a pleasure to use. It’s not difficult to install and it decouples most of the performance pain away from the storage controller and onto the server-side flash cluster (or RAM cluster in the next release). But the best result was seeing the impact on database performance and transaction times. If you have a write-intensive application that can benefit from server-side caching (not just reads but writes too!) then you owe it to yourself to take a look at PernixData FVP. I’ll be taking another look when 2.0 becomes available.

Monitoring Storage Elements with LSI Controllers in ESXi

Cisco UCS servers have made quite an impact in the market and are currently #1 in blades.  Most UCS Servers don’t use any local storage beyond maybe booting ESXi from an SD card.  But what if you had a use case where you needed to use direct attached storage? Not a common use case today, but VMware VSAN is likely to change that.

The problem I encountered is that ESXi in UCS servers would not report health for storage elements to ESXi.  Cisco UCS servers use LSI controllers and we were completely blind to events like a hard drive failure, RAID rebuild, predictive failure and so forth. The use case here was a single UCS-C server with direct-attached storage which hasn’t been a common use case until just now with VMware VSAN.

Using different combinations of drivers blessed by VMware and Cisco I was unable to get physical drive and controller health to report in ESXi. I did my due diligience on a few Google searches but was unable to find any solution.

Then I went on the LSI website to look at the available downloads and something caught my eye — an SMI-S provider for VMware. I remembered that SMI-S is basically CIM, which is what ESXi uses to collect health information. This is a separate VIB that is independent of the megaraid_sas driver in ESXi.  With the SMI-S provider installed in ESXi suddenly I could see all the things that were missing in the health section such as:

  • Controller health
  • Battery health
  • Physical drive health
  • Logical drive health

Screenshot_50Basically the moral of the story is this — if you have an LSI array controller (common in UCS-C) then you’ll need to follow these steps to get health monitoring on your storage elements:

1) Go to LSI’s website and download the current SMI-S provider for VMware for your card.

2) Upload the VIB file to a VMFS datastore

3) From an SSH shell type “esxcli software vib install -v [full path to vib file]”

4) Reboot

I’m not clear on why this capability is not exposed by the driver, but it seems for the time being that installing this additional VIB is required to get ESXi to monitor the health of storage elements on LSI controllers.

Hope some will find this valuable.

vSphere 6.0 Public Beta — Sign Up to Learn What’s New

vSphere 6.0 Public Beta — Sign Up to Learn What’s New

Yesterday, VMware announced the public availability of vSphere 6.0 Beta 2.  I can’t tell you what’s all in it due to the NDA, but you can still register for the beta yourself, read about what’s new and download the code for your home lab.

There’s some pretty exciting stuff being added to vSphere 6.0 in quite a few areas.  One of these new areas is vVols — a new abstraction for volumes that enables tighter integration with storage arrays through the VASA API. You can read more about vVols in vSphere 6.0 on Rawlinson’s post.

One more thing — after you sign up for the beta you will be able to attend the following two webinars on the vSphere 6.0 beta

  • Introduction / Overview – Tuesday, July 8, 2014
  • Installation & Upgrade – Thursday, July 10, 2014

Needless to say there’s some pretty awesome stuff in the 6.0 Beta.  Start your download engines!

https://communities.vmware.com/community/vmtn/vsphere-beta