Tag Archives: RAID5

Informational

QLC NVMe – could this signal the end of SAS and SATA?

1 Comment

I met with a team from Intel recently and discussed their new additions to the vSAN Compatibility Guide, mainly around their QLC NVMe drives. I have spoken to many customers around Full NVMe configurations on many occasions and usually there was a slightly higher price to pay for such configurations, but the QLC NVMe drives could be a turning point for future proofing your HCI platform because they are cheaper than your SAS/SATA Equivalent!

This being said, I have heard many times that the days of SATA/SAS based drives are numbered, but clearly with these QLC NVMe drives this could be much sooner rather than later.

Right now the 7.68TB D5-P4320 has been certified, and I have been informed by Intel that the 15.3TB one is currently going through certification, that’s now a game changer for delivering high amounts of capacity at a reasonable cost price. If I take the 4-Node Full NVMe cluster I have access too and replaced all the current NVMe devices for the 7.68TB QLC NVMe devices, I would have an effective usable capacity of 166TB and double that with the 15.3TB drives, this is based on RAID5 Storage Policy only and also taking into account the 10% difference between Device Capacity and Actual Capacity. So let’s take a look a bit more closely at these new QLC NVMe drives from Intel:

From the ARK portal we can determine the following information:

FormatU.2 2.5Inch
Sequential Read (up to)3200 MB/s
Sequential Write (up to)1000 MB/s
Random Read (100% span)427000 IOPS
Random Write (100% span)36000 IOPS
Latency – Read138 µs
Latency – Write30 µs
InterfacePCIe NVMe 3.1 x4

Now if you remember my blog around Full NVMe performance, combining Intel Optane with their NVMe drives will deliver a much more superior performance characteristic versus traditional SAS/SATA, however in addition to that with these new QLC NVMe drives it also reduces the cost of capacity, but just how much of a difference is it?

So I checked out the prices here in the UK, from the same supplier, here’s the link to the NVMe QLC Device and here’s the link to a SAS Equivalent.

For the benefit of this exercise I compared the lowest cost SAS 12G 7.68TB Drive on the vSAN Compatibility Guide since Intel do not manufacture SAS based SSDs and vendors seem to favour SAS based SSDs over SATA

Correct as of 11th August 2019Samsung 7.68TB
SAS 12G 		Intel P4320 7.68TB
QLC NVMe
Capacity7.68TB7.68TB
InterfaceSASNVMe
Total Cost of Drive£3093.60£1609.20
Cost per GB£0.40£0.20
DWPD10.2

As you can clearly see, the cost per GB is significantly lower at £0.20 per GB (this falls to around £0.18 per GB on the larger 15.3TB device), however there is one thing to note, the DWPD of the QLC NVMe device is much lower in comparison to the SATA device but in a vSAN environment should this matter too much? The simple answer here is no, but if we look at the maths, if I had 8 of the QLC devices in each host in my 4-node cluster, and I have a usable capacity of 166TB, at 0.2 DWPD that means I would have to be writing 33.2TB of data per day to hit the 0.2 DWPD, so the lower DWPD in a vSAN environment is not significant unless you are constantly writing fresh data that would exceed the above.

I am hoping that I can get some of these QLC NVMe drives from Intel to get some performance data from them in order to complete the write up and give some performance characteristics, but based on my previous full NVMe performance testing I would not expect them to be lower than those previous tests.

Uncategorized

Sizing for your workloads

Leave a comment

When sizing a vSAN environment there are many considerations to take into account, and with the launch of the new vSAN Sizing tool I thought I would take time and write up what questions I commonly ask people in order to get an understanding of what they want to run on vSAN as well as a scope of requirements that meet that workload.

Capacity
Obviously capacity is going to be our baseline for any sizing activity, no matter what we achieve with the other requirements, we have to meet a usable capacity, remember we should always work off a usable capacity for any sizing, a RAW capacity does not take into account any Failure Tolerance Methodology, Erasure Coding or Dedupe/Compression, this is something we will cover a bit later in this article.

Capacity should also include the required Swap File space for each of the VMs that the environment is being scoped for.

IOPS
I have been involved in many discussions where it is totally unknown what the performance requirements are going to be, so many times I have been told “We want the fastest performance possible” without being told what the current IOPS requirement is, to put it into context what is the point in buying a 200mph sports car when the requirement is to drive at 70mph max!

IOPS requirement plays a key part in determining what level of vSAN Ready Node specification is required, for example if a total IOPS requirement is 300,000 IOPS out of a 10 Node cluster, is there much point spending more money on an All-Flash configuration that delivers 150,000 IOPS Per node?  Simple answer…No!  You could opt for a lower vSAN All-Flash Ready Node config that meets the requirements a lot closer and still offer
room for expansion in the future.

Workload Type
This is a pretty important requirement, for example if your workload is more of a write intensive workload then this would change the cache requirements, it may also require a more write intensive flash technology such as NVMe for example.  If you have different workload types going onto the same cluster it would be worthwhile categorizing those workloads into four categories:-

  • 70/30 Read/Write
  • 80/20 Read/Write
  • 90/10 Read/Write
  • 50/50 Read/Write

Having the VMs in categories will allow you to specify the workload types in the sizing tool (in the advanced options).

vCPU to Physical Core count
This is something that gets overlooked not from a requirement perspective, but people are so used to sizing based on a “VM Per Host” scenario which with the increasing CPU core counts does not fit that model any more, even the new sizing tool bases it on vCPU to Physical Core ratio which makes things a lot easier, most customers I Talk to who are performing a refresh of servers with either 12 or 14 core processors can lower the amount of servers required by increasing the core count on the new servers, thus allowing you to run more vCPUs on a single host.

List of questions for requirements for each workload type

  • Average VMDK Size per VM
  • Average number of VMDKs per VM
  • Average number of vCPU per VM
  • Average vRAM per VM
  • Average IOPS Requirement per VM
  • Number of VMs
  • vCPU to Physical Core Ratio

RAW Capacity versus Usable Capacity, how much do I actually need?
The new sizing tool takes all your requirements into account, even the RAID levels, Dedupe/Compression ratios etc and returns with a RAW Capacity requirement based on the data you enter, if you are like me and prefer to do it quick and dirty, below is table showing you how to work out based on a requirement of 100TB of usable (Including Swap File Space), based on a standard cluster with no stretched capacilities it looks like this:

FTT LevelFTT MethodMin number of hostsMultiplication FactorRAW Capacity Based on 100TB Usable
FTT=0NoneN/A1x100TB
FTT=1Mirror32x200TB
FTT=2Mirror53x300TB
FTT=3Mirror74x400TB
FTT=1RAID541.33x133TB
FTT=2RAID661.5x150TB

Now in vSAN 6.6 VMware introduced localized protection (Secondary FTT) and the ability to include or not include specific objects from the stretched cluster (Primary FTT), below is a table showing what the RAW Capacity requirements are based on the two FTT levels

Primary FTT LevelSecondary FTT LevelSecondary FTT MethodMin Number of hosts per siteRAW Capacity Based on 100TB Usable
PFTT=1SFTT=0RAID01200TB
PFTT=1SFTT=1RAID13400TB
PFTT=1SFTT=1RAID54266TB
PFTT=1SFTT=2RAID66300TB

Mixed FTT levels and FTT Methods
Because vSAN is truly a Software Defined Storage Platform, this means that you can have a mixture of VMs/Objects with varying levels of protection and FTT Methods, for example for Read intensive workloads you may choose to have RAID 5 in the storage policy, and for more write intensive workloads a RAID 1 policy, they can all co-exist on the same vSAN Cluster/Datastore perfectly well, and the new sizing tool allows you to specify different Protection Levels and Methods for each workload type.

 

Uncategorized

Managing Storage Policies using PowerCLI

Leave a comment

It has been a personal project due to a few people asking me in working out how to create and manipulate vSAN Storage Policies from the new PowerCLI commandlets introduced in PowerCLi 6.5, the tasks I will cover here will be

  1. Creating a Brand New Storage Policy
  2. Changing an existing storage policy

For the purpose of this excersise I am using PowerCLI 6.5 Release 1 build 4624819 I owuld recommend you use that build or newer as some of the commands do not work as intended on previous PowerCLI builds.

 

Creating a Storage Policy

Before we proceed with creating a storage policy, you need to ensure you are logged into your vCenter server via PowerCLI and get a list of capabilities from the storage provider, for this we run the command Get-SpbmCapability and filter out the VSAN Policy capabilities

C:\> Get-SpbmCapability VSAN*
Name ValueCollectionType ValueType AllowedValue
---- ------------------- --------- ------------
VSAN.cacheReservation System.Int32
VSAN.checksumDisabled System.Boolean
VSAN.forceProvisioning System.Boolean
VSAN.hostFailuresToTolerate System.Int32
VSAN.iopsLimit System.Int32
VSAN.proportionalCapacity System.Int32
VSAN.replicaPreference System.String
VSAN.stripeWidth System.Int32

For the definitions of the values associated with each definition:-
System.Int32 = Numerical Value
System.Boolean = True or False
System.String = “RAID-1 (Mirroring) – Performance” or “RAID-5/6 (Erasure Coding) – Capacity”

So I want to create a Policy with the following Definitions

Policy Name: PowerCLI-RAID5
Policy Description: RAID5 Policy Created with PowerCLI
Failures to Tolerate: 1
Failures to Tolerate Method: RAID5
Stripe Width: 2
IOPS Limit: 1000

To create a policy with the above specification we need to run the following command:

New-SpbmStoragePolicy -Name PowerCLI-RAID5 -Description "RAID5 Policy Created with PowerCLI" `
-AnyOfRuleSets `
(New-SpbmRuleSet `
(New-SpbmRule -Capability (Get-SpbmCapability -Name "VSAN.hostFailuresToTolerate" ) -Value 1),`
(New-SpbmRule -Capability (Get-SpbmCapability -Name "VSAN.stripeWidth" ) -Value 2),`
(New-SpbmRule -Capability (Get-SpbmCapability -Name "VSAN.replicaPreference" ) -Value "RAID-5/6 (Erasure Coding) - Capacity"),`
(New-SpbmRule -Capability (Get-SpbmCapability -Name "VSAN.iopsLimit" ) -Value 1000)`
)

We can then check for our policy by running the following command:

C:\> Get-SpbmStoragePolicy -Name "PowerCLi-RAID5" |Select-Object -Property *

CreatedBy : Temporary user handle
CreationTime : 11/04/2017 13:42:36
Description : RAID5 Policy Created with PowerCLI
LastUpdatedBy : Temporary user handle
LastUpdatedTime : 11/04/2017 13:42:36
Version : 0
PolicyCategory : REQUIREMENT
AnyOfRuleSets : {(VSAN.hostFailuresToTolerate=1) AND (VSAN.stripeWidth=2) AND (VSAN.replicaPreference=RAID-5/6 (Erasure Coding) - Capacity) AND (VSAN.iopsLimit=1000)}
CommonRule : {}
Name : PowerCLI-RAID5
Id : 9f8f61f4-24db-4513-b48f-a48c584f0eac
Client : VMware.VimAutomation.Storage.Impl.V1.StorageClientImpl

And from the UI We can see our storage policy:

That’s our policy created, now we’ll move onto changing an existing policy.

Changing an existing storage policy

The policy we created earlier, if we suddenly decide that we want RAID 6 rather than RAID 5, we have to change the Failure To Tolerate number to 2, and we will also want to change our policy name and description as it will no longer be RAID5. In order to change a policy, we have to ensure we specify the other values for the other policy definitions, if we do not specify the policy definitions that we do not want to be changed, they will be removed from the storage policy, so first we run the command that tells us what our policy definition is:

C:\> Get-SpbmStoragePolicy -Name "PowerCLi-RAID5" |Select-Object -Property *

CreatedBy : Temporary user handle
CreationTime : 11/04/2017 13:42:36
Description : RAID5 Policy Created with PowerCLI
LastUpdatedBy : Temporary user handle
LastUpdatedTime : 11/04/2017 13:42:36
Version : 0
PolicyCategory : REQUIREMENT
AnyOfRuleSets : {(VSAN.hostFailuresToTolerate=1) AND (VSAN.stripeWidth=2) AND (VSAN.replicaPreference=RAID-5/6 (Erasure Coding) - Capacity) AND (VSAN.iopsLimit=1000)}
CommonRule : {}
Name : PowerCLI-RAID5
Id : 9f8f61f4-24db-4513-b48f-a48c584f0eac
Client : VMware.VimAutomation.Storage.Impl.V1.StorageClientImpl

So we need to make the following changes to the policy

  • Change the Failure to Tolerate value from 1 to 2
  • Change the Name of the Policy from PowerCLI-RAID5 to PowerCLI-RAID6
  • Change the Description of the policy from “RAID5 Policy Created with PowerCLI” to “RAID6 Policy Changed with PowerCLI”

We run the following command which specified the new values, and also the values we do not want to change:

Set-SpbmStoragePolicy -StoragePolicy PowerCLI-RAID5 -Name PowerCLI-RAID6 -Description "RAID6 Policy Changed with PowerCLI" `
-AnyOfRuleSets `
(New-SpbmRuleSet `
(New-SpbmRule -Capability (Get-SpbmCapability -Name "VSAN.hostFailuresToTolerate" ) -Value 2),`
(New-SpbmRule -Capability (Get-SpbmCapability -Name "VSAN.stripeWidth" ) -Value 2),`
(New-SpbmRule -Capability (Get-SpbmCapability -Name "VSAN.replicaPreference" ) -Value "RAID-5/6 (Erasure Coding) - Capacity"),`
(New-SpbmRule -Capability (Get-SpbmCapability -Name "VSAN.iopsLimit" ) -Value 1000)`
)

We can verify the policy has been changed by running the command with the new policy name:

C:\> Get-SpbmStoragePolicy -Name "PowerCLi-RAID6" |Select-Object -Property *

CreatedBy : Temporary user handle
CreationTime : 11/04/2017 13:42:36
Description : RAID6 Policy Changed with PowerCLI
LastUpdatedBy : Temporary user handle
LastUpdatedTime : 11/04/2017 14:03:51
Version : 2
PolicyCategory : REQUIREMENT
AnyOfRuleSets : {(VSAN.hostFailuresToTolerate=2) AND (VSAN.stripeWidth=2) AND (VSAN.replicaPreference=RAID-5/6 (Erasure Coding) - Capacity) AND (VSAN.iopsLimit=1000)}
CommonRule : {}
Name : PowerCLI-RAID6
Id : 9f8f61f4-24db-4513-b48f-a48c584f0eac
Client : VMware.VimAutomation.Storage.Impl.V1.StorageClientImpl

And again in the UI we can see the changes made

That’s how you change an existing storage policy, I hope this blog helps you manage your storage policies via PowerCLI, thanks go out to Pushpesh in VMware for showing me the error of my ways when trying to figure this out myself.