Yellow Bricks

by Duncan Epping

performance

Performance Whitepapers

· ·

I always enjoy reading the performance whitepapers. They are usually fairly technical and give you a better understanding of how the products work! All of these are most definitely worth downloading and reading! They been released a couple of days back. Check it out:

Surprising results FC/NFS/iSCSI/FCoE…

· ·

I received a preliminary copy of a this report a couple of weeks ago, but since then nothing has changed. NetApp took the time to compare FC against, FCoE, iSCSI and NFS. Like most of us, probably, I still had the VI3 mindset and expected that FC would come out on top. Fact of the matter is that everything is so close, the differences are neglectable and tr-3916 shows that regardless of the type of data access protocol used you can get the same mileage. I am glad NetApp took the time to test these scenarios and used various test scenarios. It is no longer about which protocol works best, what drives the most performance… no it is about what is easiest for you to manage! Are you an NFS shop? No need to switch to FC anymore. Do you like the simplicity of iSCSI? Go for it…

Thanks NetApp for this valuable report. Although this report of course talks about NetApp it is useful material to read for all of you!

Tintri – virtual machine aware storage

· ·

This week I had a call with a new and exciting company called Tintri. Tintri has been flying under the radar for the last couple of years and has worked really hard to develop a new product. Tintri was founded by some of the smartest kids on the block one of which is their current CEO and former EVP of Engineering at VMware Dr. Kieran Harty. But not only former VMware employees, no we are talking about former Datadomain, NetApp and SUN employees. Although it is a rough time for a storage start-up they are jumping in the deep. Although one might wonder how deep it actually is as these are well experienced people and they know how deep they can go and what the weak and strong points are in virtualized environments when it comes to storage.

During the call the folks at Tintri offered to give a demo of how their Storage Unit works. As you know I don’t have a deep storage background like someone as Chad Sakac but I am working with storage on a day to day basis. I look at storage from a different perspective. My interest is usually around management, performance and availability.

From operational/management perspective Tintri VMstore does change things. Tintri VMstore is VM aware, which of course is easier to accomplish when you develop your own filesystem and serve it up as NFS than when using block-based storage. Tintri leverages the VMware vSphere APIs and correlates information with what they have running on top their filesystem. Now why would you want to do that? Well for instance for simple things like Storage Level snapshots per VM, try doing that on the average FC/iSCSI array and you find yourself snapshotting a full LUN or assigning dedicated LUNs to VMs. In both case not an ideal situation.

What makes VMstore special is that on top of the integration with vSphere they also do inline deduplication and compression, meaning that although a 5u VMstore node (5u includes a UPS system) offers you 8.5 TB of usable harddisk capacity it could potentially serve multitudes of that. (Depending on the type of workload of course.) But when it is doing inline dedupe and compression what about performance? Tintri VMstore offers 16 SATA drives. No not just SATA as that probably wouldn’t meet all your performance requirements, no they also offer MLC Flash aka SSD and that is where the dedupe and compression is done. In other words, in order to enable inline dedupe and compression Tintri developed a hybrid filesystem that moves data between SSD and SATA. By the way, VMstore uses RAID-6 for the 1TB of SSD drives it contains and for the 16x1TB SATA drives. If data needs to move it decides that on a pretty granular level, 4kb. Of course VMstore is smart enough to batch these transfers to optimize bandwidth.

Each VMstore node will be served up as a single NFS Share via 10GbE. Do you need more diskspace? Hook up another VMstore node and connect to the NFS Share. Other things that are simplified of course it the management of the VMstore node itself. Need to upload log files? Don’t worry, a single click sends it to the cloud over an SSL connection and  Tintri will pick it up from there. No hassling with FTP etc. Same goes for the “call back” system for support, it will upload details to the cloud and Tintri will pick it up.

When they demoed it yesterday most workloads were actually running on SSD at that moment. (The showed me their VDI environment) The cool thing is that you can actually see the performance stats on a per VM level (see screenshot below) or even per VMDK if you want to. On top of that you can also “reserve” performance for your VMs by telling VMstore that these need to be pinned to SSD.

The following is a quote from one of their customers:

Previous attempts to virtualize our Oracle Financials application had failed – as we couldn’t deliver the performance users required,” said Don St. Onge, CIO, TIBCO Software, Inc. “With Tintri VMstore, we saw a 2X performance boost which was more than enough to keep our users happy. Tintri’s unique approach to deduplication and compression lets us run the entire 1TB database instance in only 177GB of flash memory.

Now this might be slightly overstating it, like most press releases do, as I have many customers virtualizing their production tier 1 apps, but the key take away for me is the fact that they run a 1TB database in 177GB of flash and still see a performance improvement. I guess that is due to the beefy specs of the VMstore node which is literally using multiple multi core CPUs.

So in short (copy from Tintri’s press release):

  • VM-aware file system designed to service I/O workloads from VMs;
  • Seamless flash/disk integration with file system for smooth workload transitions and efficient use of flash capacity;
  • Monitoring, control and reporting features on a per-VM and per-virtual disk basis for greater transparency in managing storage for VMs;
  • Hybrid flash/disk appliances with inline deduplication and compression capabilities.

So Tintri is hot, fantastic, great… but there must be things that you feel can be improved? Well of course there are…

I would love to see even more integration with VMware. Not only make the VMstore node VM aware but also make vSphere VMstore aware. In others I would expect and love to see plugins which allow you to do most of the VM level storage management tasks within vCenter instead of through the VMstore webinterface. (Although it is a very simple interface which you can learn in seconds.) Also I feel that replication is something that it needs to have. I can imagine it is part of their roadmap but I would rather see it today than tomorrow. Having the ability to enable replication per VM and than only replicate the changed and compressed “chunks” is more than welcome. It would also be great if it had Syslog capabilities so that event correlation is even easier.

My take in short: Tintri VMstore has an interesting approach on the traditional problems virtualized infrastructures are facing, by making their nodes VM aware they are looking to solve these problems. Along the way they are simplifying management and have a very competitive price. Most definitely worth investigating if their solution meets your requirements! Their website specifically calls out “Test and Development” as one of the target solutions for VMstore, I guess by now everyone know what starting with “Test and Development” brought VMware…. Keep an eye out for these guys,

VAAI sweetness

· ·

Nothing deep technical this time, I just want to make clear how cool VAAI is! Last week I noticed on twitter that some people reported some nice figures around VAAI. I asked them if they were willing to run some tests and compare VAAI vs NON-VAAI runs. And these were some of the responses I received, I cut them down to the core of the message and I leave it up to you to visit these articles and read them. Thanks for helping me proof this point guys!

vSphere VAAI Performance on the HP P4000 G2 by Barrie Seed

The results are pretty conclusive. For block zeroing on a VMDK, VAAI accelerates the operation by 4-5x

  • VAAI enabled: 109 seconds
  • VAAI disabled: 482 seconds

VAAI Awesomeness by Anders Hansen

I guess a picture says more than a thousand words. Difference in percentage for Cloning:

Difference in time for Eager Zero Thick Creation:

 

Exploring the performance benefits of VAAI by Matt Liebowitz

To the results:

Time to create a 50GB eagerzeroedthick VMDK without VAAI: 10 minutes generating approximately 750 write IOPS on the array

Time to create a 50GB eagerzeroedthick VMDK with VAAI: 1 minute 30 seconds, could not measure IOPS (more on that later)

Clearly there is a significant difference in creating the blank eagerzeroedthick VMDK.  How about when Windows 2008 R2 is installed on that VMDK and then converted to a template?  How fast can we deploy that template?

Deploying 50GB eagerzeroedthick template without VAAI: 19 minutes generating between 1,200-1,600 IOPS (half read/write, which makes sense since it has to read from and write to the same array)

Deploying 50GB eagerzeroedthick template with VAAI: 6 minutes (again, couldn’t measure IOPS)

 

NetApp VMware VAAI Performance Tests by Jacint Juhasz

It’s not a surprise, the trend is the same.

Operation Enabled VAAI Disabled VAAI
50GB VMDK creation with cluster support (zeroed) 5:09 9:36
Clone VM within datastore (LUN) 8:36 13:38
Clone VM between datastores (LUN) 8:34 14:36
Storage VMotion 9:38 14:45

With VAAI enabled, there’s no write or read rate (as there’s no read or write from the host side), but the charts shows latency around 8-10ms. With disabled VAAI the chart looks a bit different. For the VMDK creation the write rate is around 100000KBps with 160ms latency (write only, no reads). The read/write operation shows 70000KBps IO rate with 10-15ms latency.

3PAR vSphere VAAI “Write Same” Test Results: 20x performance boost by Derek Seaman

“Write Same” Without VAAI:
70GB VMDK 2 minutes 20 seconds (500MB/sec)
240GB VMDK 8 minutes 1 second (498MB/sec)
1TB VMDK 33 minutes 10 seconds (502MB/sec)

Without VAAI the ESXi 4.1 host is sending a total 500MB/sec of data through the SAN and into the 4 ports on the 3PAR. Because the T400 is an active/active concurrent controller design, both controllers can own the same LUN and distribute the I/O load. In the 3PAR IMC (InForm Management console) I monitored the host ports and all four were equally loaded around 125MB/sec.

This shows that round-robin was functioning, and highlights the very well balanced design of the T400. But this configuration is what everyone has been using the last 10 years..nothing exciting here except if you want to weight down your SAN and disk array with processing zeros. Boorrrringgg!!

Now what is interesting, and very few arrays support, is a ‘zero detect’ feature where the array is smart enough on thin provisioned LUNs to not write data if the entire block is all zeros. So in the 3PAR IMC I was monitoring the back-end disk facing ports and sure enough, virtually zero I/O. This means the controllers were accepting 500MB/sec of incoming zeros, and writing practically nothing to disk. Pretty cool!

“Write Same” With VAAI: 20x Improvement
70GB VMDK 7 seconds (10GB/sec)
240GB VMDK 24 seconds (10GB/sec)
1TB VMDK 1 minute 23 seconds (12GB/sec)

I guess it is needless to say why VAAI rocks and why when you are looking to buy new storage it is important to inform if the array is VAAI capable, and if not make sure you ask when it will support VAAI!?! VAAI isn’t just for specific workloads, VAAI was designed to reduce stress on different layers and to decrease the cost of specific actions and more importantly for you to decrease the costs of operations!

Thin provisioned disks and VMFS fragmentation, do I really need to worry?

· ·

I’ve seen this myth floating around from time to time and as I never publicly wrote about it I figured it was time to write an article to debunk this myth. The question that is often posed is if thin disks will hurt performance due to fragmentation of the blocks allocated on the VMFS volume. I guess we need to rehash (do a search on VMFS for more info)  some basics first around Think Disks and VMFS volumes…

When you format a VMFS volume you can select the blocksize (1MB, 2MB, 4MB or 8MB). This blocksize is used when the hypervisor allocates storage for the  VMDKs. So when you create a VMDK on an 8MB formatted VMFS volume it will create that VMDK out of 8MB blocks and yes indeed in the case of a 1MB formatted VMFS volume it will use 1MB. Now this blocksize also happens to be the size of the extend that is used for Think Disks. In other words, every time your thin disks needs to expand it will grow in extends of 1MB. (Related to that, with a lazy-thick disk the zero-out also uses the blocksize. So when something needs to be written to an untouched part of the VMDK it will zero out using the blocksize of the VMFS volume.)

So using a thin disk in combination with a small blocksize cause more fragmentation? Yes, more than possibly it would. However the real question is if it will hurt your performance. The answer to that is: No it won’t. The reason for it being that the VMFS blocksize is totally irrelevant when it comes to Guest OS I/O. So lets assume you have an regular Windows VM and this VM is issuing 8KB writes and reads to a 1MB blocksize formatted volume, the hypervisor won’t fetch 1MB as that could cause a substantial overhead… no it would request from the array what was requested by the OS and the array will serve up whatever it is configured to do so. I guess what people are worried about the most is sequential I/O, but think about that for a second or two. How sequential is your I/O when you are looking at it from the Array’s perspective? You have multiple hosts running dozens of VMs accessing who knows how many volumes and subsequently who knows how many spindles. That sequential I/O isn’t as sequential anymore all of a sudden it is?!

<edit> As pointed out many arrays recognize sequential i/o and prefetch which is correct, this doesn’t mean that when contiguous blocks are used it is faster as fragmented blocks also means more spindles etc </edit>

I guess the main take away here is, stop worrying about VMFS it is rock solid and it will get the job done.