Home > Blogs > VMware vSphere Blog > Category Archives: vSphere

Category Archives: vSphere

vSphere Hardening Guide 6.0 Public Beta 1 available

I’m happy to announce that the vSphere 6 Hardening Guide Public Beta 1 is now available.

The guide is being provided as Excel spreadsheet. I’m also making a PDF doc available for easier viewing. In addition,  I’ve also included an Excel spreadsheet of the guidelines that have moved out of the guide and into documentation. THIS IS INCOMPLETE. We are still working on some of that content. (that’s why this is a beta!)

Please read the blog on the changes that have happened to the guide. LOTS of changes and the blog will explain.

vSphere 6.0 Hardening Guide – Overview of coming changes | VMware vSphere Blog – VMware Blogs

Continue reading

Virtual Volumes and the SDDC

I saw a question the other day that asked “Can someone explain what the big deal is about Virtual Volumes?”   A fair question.

The shortest, easiest answer is that VVols offer per-VM management of storage that helps deliver a software defined datacenter.

That, however, is a pretty big statement that requires some unpacking.  Rawlinson has done a great job of showcasing Virtual Volumes already, and has talked about how it simplifies storage management, puts the VMs in charge of their own storage, and gives us more fine-grained control over VM storage.  I myself will also dive into some detail on the technical capabilities in the future, but first let’s take a broader look at why this really is an important shift in the way we do VM storage.

Continue reading

Confessions of an Energy Consciousness Mind

I have a confession. 

My data center kit has been using too much energy.

Having kit available at my disposable is great, but I have been wasting this resource when it’s not required by my workloads. And if there’s one thing I try to be conscious of, it’s energy consumption. Just ask my kids who I chase from room to room turning off lights, screens, and the lot when they aren’t using them.

But why not in the data center? Did you know that hosts typically use 60%+ of their peak power when idle?

Until recently, I had overlooked configuring my kit to use the vSphere Distributed Power Management (“DPM”) feature to manage power consumption and save energy.

With the release of vSphere 6.0 it’s a good time to review and take deeper look into the capabilities and benefits of this feature.

What is VMware vSphere Distributed Power Management?

VMware vSphere Distributed Power Management is a feature included with vSphere Enterprise and Enterprise Plus editions that dynamically optimizes cluster power consumption based on workload demands. When host CPU and memory resources are lightly used, DPM recommends the evacuation of workloads and powers-off of ESXi hosts. When CPU or memory resource utilization increases for workloads or additional host resources are required, DPM powers on a required set of hosts back online to meet the demand of HA or other workload-specific contraints by executing vSphere Distributed Resource Scheduler (“DRS”) in a “what-if” mode. DRS will ensure host power recommendations are consistent with the cluster constraints and resources being managed by the cluster.

Beneath the covers there are key challenges that DPM addresses to enable effective power-savings capabilities:

  • Accurately Assessing Workload Resource Demand
  • Avoiding Frequent Power-on/Power-off of Host and Excessive vMotion Operations
  • Rapid Response to Workload Demand and Performance Requirements
  • Appropriate Host Selection for Power-on/Power-Off within Tolerable Host Utilization Ratios
  • Intelligent Redistribution of Workloads After Host Power-on/Power-Off

Once DPM determines the number of hosts needed to satisfy all workloads and relevant constraints, and DRS has distributed virtual machines across hosts to maintain resource allocation constraints and objectives, each powered-on host is free to handle its power management

Hosts Entering and Exiting Standby

When a host is powered-off by DPM, they are marked in vCenter Server in “standby” mode indicating that they are powered-off but available to be powered-on when required. The host icon is updated with a crescent moon overlay symbolizing a “sleeping” state for the host.

DPM can awaken hosts from the standby mode using one of three power management options:

  1. Intelligent Platform Management Interface (IPMI)
  2. Hewlett Packard Integrated Lights-Out (iLO), or
  3. Wake-On-LAN (WOL).

Each protocol requires its own hardware support and configuration. If a host does not support any of these protocols it cannot be put into standby by DPM. If a host supports multiple protocols, they are used in the following order: IPMI, iLO, WOL. This article is focused on the use of the first two.

Continue reading

Enable Auto Deploy on vCenter Server Appliance (vCSA) 6

Many customers are now converting over to use the vCenter Server Appliance 6.0 since vSphere 6 has reached feature parity with the Windows vCenter Server.

For those of you who are new to using the appliance, I figured I would walk you through setting up the Auto Deploy portion of the server. Continue reading

Virtual SAN VCG Update – New HP, Fujitsu & Quanta Controllers certified for Virtual SAN!

The Virtual SAN product team is pleased to announce that the following controllers are now certified on Virtual SAN and are listed on the Virtual SAN VCG:

6G 6.0 Hybrid:

HP P420

HP P420i

HP P220i

HP P822

Quanta SAS2308

12G 6.0 Hybrid

HP P440 (without hot plug)

12G 5.5 Hybrid

Fujitsu LSI 3008

We now have a total of 80 I/O controllers certified on Virtual SAN 5.5 and 40 I/O controllers certified on Virtual SAN 6.0.

What about the Ready Nodes for platforms based on the above controllers?

We are working closely with our OEM partners such as HP to publish Ready Nodes for both 6G and 12G platforms for Virtual SAN Hybrid and All Flash configurations for both 5.5 and 6.0 and these should be available soon.

What are the controllers that are currently in the certification queue and when do we expect them to get certified?

Please see the attached list of controllers that are currently undergoing Virtual SAN certification

Note:  In many cases, we rely on our partners to provide driver/firmware fixes for controller issues so if there are delays in receiving these updates from partners, the certification timelines may get pushed out.

I have follow up questions on the attached controller list. Who do I reach out to?

As always, if you have questions on Hardware Compatibility for Virtual SAN, please email your queries to vsan-hcl@vmware.com and someone will get back to you soon!

Where do I learn more about the VMware Virtual SAN Certification process?

Please refer to the Virtual SAN Certification blog post for more details:

 

vSphere 6.0 Lockdown Mode Exception Users

In vSphere 6.0 we now have a new concept called Exception Users. The intent of Exception Users is that they are not general admin users. I would consider them more of a “Service Account” type of access.

As a matter of fact, just the other day I got an email from someone internal at VMware that brought up a great use case for Exception Users. They were talking to a customer that wanted to access ESXi via a PowerCLI cmdlet (Get-VMHostAccount) to list out the local accounts on an ESXi server as part of their normal security reporting.

But they also wanted to enable Lockdown Mode and were finding it difficult to comply with both things. In vSphere 6.0 this is now much easier to address. Let’s get started.

Continue reading

Virtualized Big Data Faster Than Bare Metal

VMware is excited to highlight a new partner benchmark effort in the Big Data technology space.

Dell recently published two TPCx-HS results that demonstrate that Big Data technology on vSphere is actually ‘faster’ than bare metal.

Let’s take a look…

Continue reading

Video: Virtual SAN From An Architect’s Perspective

Video: Virtual SAN From An Architect’s Perspective

Have you ever wanted a direct discussion with the people responsible for designing a product?

Recently, Stephen Foskett brought a cadre of technical bloggers to VMware as part of Storage Field Day 7 to discuss Virtual SAN in depth.  Christos Karamanolis (@XtosK), Principle Engineer and Chief Architect for our storage group went deep on VSAN: why it was created, its architectural principles, and why the design decisions were important to customers.

The result is two hours of lively technical discussion — the next best thing to being there.  What works about this session is that the attendees are not shy — they keep peppering Christos with probing questions, which he handles admirably.

The first video segment is from Alberto Farronato, explaining the broader VMware storage strategy.

The second video segment features Christos going long and deep on the thinking behind VSAN.

The third video segment is a run-over of the second.  Christos presents the filesystem implementations, and the implications for snaps and general performance.

Our big thanks to Stephen Foskett for making this event possible, and EMC for sponsoring our session.

 

Help us improve vSphere!

Are you a vSphere user? If so, we want to hear from you. Attached is our new survey. Help us build a better product and make sure our features are aligned with your business needs.

http://www.surveymethods.com/EndUser.aspx?B094F8E0B1F6ECE7B3

 

How To Double Your VSAN Performance

How To Double Your VSAN Performance

VSAN 6.0 is now generally available!

Among many significant improvements, performance has been dramatically improved for both hybrid and newer all-flash configurations.

VSAN is almost infinitely configurable: how many capacity devices, disk groups, cache devices, storage controllers, etc.  Which brings up the question: how do you get the maximum storage performance out of VSAN-based cluster?

Our teams are busy running different performance characterizations, and the results are starting to surface.  The case for performance growth by simply expanding the number of storage-contributing hosts in your cluster has already been well established — performance linearly scales as more hosts are added to the cluster.

Here, we look at the impact of using two disk groups per host vs. the traditional single disk group.  Yes, additional hardware costs more — but what do you get in return?

As you’ll see, these results present a strong case that by simply doubling the number of disk -related resources (e.g. using two storage controllers, each with a caching device and some number of capacity devices), cluster-wide storage performance can be doubled — or more.

Note: just to be clear, two storage controllers are not required to create multiple disk groups with VSAN.  A single controller can support multiple disk groups.  But for this experiment, that is what we tested.

This is a particularly useful finding, as many people unfamiliar with VSAN mistakenly assume that performance might be limited by the host or network.  Not true — at least, based on these results.

For our first result, let’s establish a baseline of what we should expect with a single disk group per host, using a hybrid (mixed flash and disks) VSAN configuration.

Here, each host is running a single VM with IOmeter.  Each VM has 8 VMDKs, and 8 worker tasks driving IO to each VMDK.  The working set is adjusted to fit mostly in available cache, as per VMware recommendations.

More details: each host is using a single S3700 400GB cache device, and 4 10K SAS disk drives. Outstanding IOs (OIOs) are set to provide a reasonable balance between throughput and latency.

VSAN_perf_1

On the left, you can see the results of a 100% random read test using 4KB blocks.  As the cluster size increases from 4 to 64, performance scales linearly, as you’d expect.  Latency stays at a great ~2msec, yielding an average of 60k IOPS per host.  The cluster maxes out at a very substantial ~3.7 million IOPS.

When the mix shifts to random 70% read / 30% writes (the classic OLTP mix), we still see linear scaling of IOPS performance, and a modest increase in latency from ~2.5msec to ~3msec.  VSAN is turning it a very respectable 15.5K IOPS per host.  The cluster maxes out very close to ~1m IOPS.

Again, quite impressive.  Now let’s see what happens when more storage resources are added.

For this experiment, we added an additional controller, cache and set of capacity devices to each host.  And the resulting performance is doubled — or sometimes even greater!

VSAN_perf_2

Note that now we are seeing 116K IOPS per host for the 100% random read case, with a maximum cluster output of a stunning ~7.4 million IOPS.

For the OLTP-like 70% read / 30% write mix, we see a similar result: 31K IOPS per host, and a cluster-wide performance of ~2.2 million IOPS.

For all-flash configurations of VSAN, we see similar results, with one important exception: all-flash configurations are far less sensitive to the working set size.  They deliver predictable performance and latency almost regardless of what you throw at them.  Cache in all-flash VSAN is used to extend the life of write-sensitive capacity devices, and not as a performance booster as is the case with hybrid VSAN configurations.

In this final test, we look at an 8 node VSAN configuration, and progressively increase the working set size to well beyond available cache resources.  Note: these configurations use a storage IO controller for the capacity devices, and a PCI-e cache device which does not require a dedicated storage controller.

On the left, we can see the working set increasing from 100GB to 600GB, using our random 70% read / 30% OLTP mix as before.

Note that IOPS and latency remain largely constant:  ~40K IOPS per node with ~2msec latency.  Pretty good, I’d say.

On the right, we add another disk group (with dedicated controllers) to each node (flash group?) and instead vary the working set size from an initial 100GB to a more breathtaking 1.2TB.  Keep in mind, these very large working set sizes are essentially worst-case stress tests, and not the sort of thing you’d see in a normal environment.

VSAN_perf_3

Initially, performance is as you’d expect: roughly double of the single disk group configuration (~87K IOPS per node, ~2msec latency).  But as the working set size increases (and, correspondingly, pressure on write cache), note that per-node performance declines to ~56K IOPS per node, and latency increases to ~2.4 msec.

What Does It All Mean?

VSAN was designed to be scalable depending on available hardware resources.  For even modest cluster sizes (4 or greater), VSAN delivers substantial levels of storage performance.

With these results, we can clearly see two axes to linear scalability — one as you add more hosts in your cluster, and the other as you add more disk groups in your cluster.

Still on the table (and not discussed here): things like faster caching devices, faster spinning disks, more spinning disks, larger caches, etc.

It’s also important to point out what is not a limiting factor here: compute, memory and network resources – just the IO subsystem which consists of a storage IO controller, a cache device and one or more capacity devices.

The other implication is incredibly convenient scaling of performance as you grow — by either adding more hosts with storage to your cluster, or adding another set of disk groups to your existing hosts.

What I find interesting is that we really haven’t found the upper bounds of VSAN performance yet.  Consider, for example, a host may have as many as FIVE disk groups, vs the two presented here.   The mind boggles …

I look forward to sharing more performance results in the near future!

———–

Chuck Hollis

http://chucksblog.typepad.com

@chuckhollis