Discussion:
VDI iops with caching
(too old to reply)
Geoff Nordli
2013-01-03 04:45:00 UTC
Permalink
Raw Message
I am looking at the performance numbers for the Oracle VDI admin guide.

http://docs.oracle.com/html/E26214_02/performance-storage.html

From my calculations for 200 desktops running Windows 7 knowledge user
(15 iops) with a 30-70 read/write split it comes to 5100 iops. Using
7200 rpm disks the requirement will be 68 disks.

This doesn't seem right, because if you are using clones with caching,
you should be able to easily satisfy your reads from ARC and L2ARC. As
well, Oracle VDI by default caches writes; therefore the writes will be
coalesced and there will be no ZIL activity.

Anyone have other guidelines on what they are seeing for iops with vdi?

Happy New Year!

Geoff
Richard Elling
2013-01-03 17:45:59 UTC
Permalink
Raw Message
Post by Geoff Nordli
I am looking at the performance numbers for the Oracle VDI admin guide.
http://docs.oracle.com/html/E26214_02/performance-storage.html
From my calculations for 200 desktops running Windows 7 knowledge user (15 iops) with a 30-70 read/write split it comes to 5100 iops. Using 7200 rpm disks the requirement will be 68 disks.
This doesn't seem right, because if you are using clones with caching, you should be able to easily satisfy your reads from ARC and L2ARC. As well, Oracle VDI by default caches writes; therefore the writes will be coalesced and there will be no ZIL activity.
All of these IOPS <--> VDI users guidelines are wrong. The problem is that the variability of
response time is too great for a HDD. The only hope we have of getting the back-of-the-napkin
calculations to work is to reduce the variability by using a device that is more consistent in its
response (eg SSDs).
Post by Geoff Nordli
Anyone have other guidelines on what they are seeing for iops with vdi?
The successful VDI implementations I've seen have relatively small space requirements for
the performance-critical work. So there are a bunch of companies offering SSD-based arrays
for that market. If you're stuck with HDDs, then effective use of snapshots+clones with a few
GB of RAM and slog can support quite a few desktops.
-- richard

--

***@RichardElling.com
+1-760-896-4422
Geoff Nordli
2013-01-04 04:38:54 UTC
Permalink
Raw Message
Thanks Richard, Happy New Year.
Post by Richard Elling
Post by Geoff Nordli
I am looking at the performance numbers for the Oracle VDI admin guide.
http://docs.oracle.com/html/E26214_02/performance-storage.html
From my calculations for 200 desktops running Windows 7 knowledge
user (15 iops) with a 30-70 read/write split it comes to 5100 iops.
Using 7200 rpm disks the requirement will be 68 disks.
This doesn't seem right, because if you are using clones with
caching, you should be able to easily satisfy your reads from ARC and
L2ARC. As well, Oracle VDI by default caches writes; therefore the
writes will be coalesced and there will be no ZIL activity.
All of these IOPS <--> VDI users guidelines are wrong. The problem is
that the variability of
response time is too great for a HDD. The only hope we have of getting
the back-of-the-napkin
calculations to work is to reduce the variability by using a device
that is more consistent in its
response (eg SSDs).
For sure there is going to be a lot of variability, but it seems we
aren't even close.

Have you seen any back-of-the-napkin calculations which take into
consideration SSDs for cache usage?
Post by Richard Elling
Post by Geoff Nordli
Anyone have other guidelines on what they are seeing for iops with vdi?
The successful VDI implementations I've seen have relatively small space requirements for
the performance-critical work. So there are a bunch of companies offering SSD-based arrays
for that market. If you're stuck with HDDs, then effective use of
snapshots+clones with a few
GB of RAM and slog can support quite a few desktops.
-- richard
Yes, I would like to stick with HDDs.

I am just not quite sure what quite a few desktops mean.

I thought for sure there would be lots of people around that have done
small deployments using a standard ZFS deployment.

thanks,

Geoff
Eric D. Mudama
2013-01-04 17:38:21 UTC
Permalink
Raw Message
Post by Geoff Nordli
I am looking at the performance numbers for the Oracle VDI admin guide.
http://docs.oracle.com/html/E26214_02/performance-storage.html
From my calculations for 200 desktops running Windows 7 knowledge user
(15 iops) with a 30-70 read/write split it comes to 5100 iops. Using
7200 rpm disks the requirement will be 68 disks.
This doesn't seem right, because if you are using clones with caching,
you should be able to easily satisfy your reads from ARC and L2ARC. As
well, Oracle VDI by default caches writes; therefore the writes will be
coalesced and there will be no ZIL activity.
Yes, I would like to stick with HDDs.
I am just not quite sure what quite a few desktops mean.
I thought for sure there would be lots of people around that have done small
deployments using a standard ZFS deployment.
Even a single modern SSD should be able to provide hundreds of
gigabytes of fast L2ARC to your system, and can scale as your userbase
grows for a relatively small initial investment. This is actually
about the perfect use case for an L2ARC on SSD.
--
Eric D. Mudama
***@bounceswoosh.org
Richard Elling
2013-01-04 22:08:05 UTC
Permalink
Raw Message
Post by Geoff Nordli
Thanks Richard, Happy New Year.
Post by Richard Elling
Post by Geoff Nordli
I am looking at the performance numbers for the Oracle VDI admin guide.
http://docs.oracle.com/html/E26214_02/performance-storage.html
From my calculations for 200 desktops running Windows 7 knowledge user (15 iops) with a 30-70 read/write split it comes to 5100 iops. Using 7200 rpm disks the requirement will be 68 disks.
This doesn't seem right, because if you are using clones with caching, you should be able to easily satisfy your reads from ARC and L2ARC. As well, Oracle VDI by default caches writes; therefore the writes will be coalesced and there will be no ZIL activity.
All of these IOPS <--> VDI users guidelines are wrong. The problem is that the variability of
response time is too great for a HDD. The only hope we have of getting the back-of-the-napkin
calculations to work is to reduce the variability by using a device that is more consistent in its
response (eg SSDs).
For sure there is going to be a lot of variability, but it seems we aren't even close.
Have you seen any back-of-the-napkin calculations which take into consideration SSDs for cache usage?
Yes. I've written a white paper on the subject, somewhere on the nexenta.com website (if it is still available).
But more current info is presentation at ZFSday.

http://www.slideshare.net/relling
Post by Geoff Nordli
Post by Richard Elling
Post by Geoff Nordli
Anyone have other guidelines on what they are seeing for iops with vdi?
The successful VDI implementations I've seen have relatively small space requirements for
the performance-critical work. So there are a bunch of companies offering SSD-based arrays
for that market. If you're stuck with HDDs, then effective use of snapshots+clones with a few
GB of RAM and slog can support quite a few desktops.
-- richard
Yes, I would like to stick with HDDs.
I am just not quite sure what quite a few desktops mean.
I thought for sure there would be lots of people around that have done small deployments using a standard ZFS deployment.
... and large :-) I did 100 desktops with 2 SSDs two years ago. The presentation was given at
OpenStorage Summit 2010. I don't think there is a video, though :-(.

Fundamentally, people like to use sizing in IOPS, but all IOPS are not created equal. An I/O
satisfied by ARC is often limited by network bandwidth constraints whereas an I/O that hits a
slow pool is often limited by HDD latency. The two are 5 orders of magnitude different when
using HDDs in the pool.
-- richard

--

***@RichardElling.com
+1-760-896-4422
Geoff Nordli
2013-01-05 05:07:03 UTC
Permalink
Raw Message
Post by Richard Elling
Post by Geoff Nordli
Post by Richard Elling
All of these IOPS <--> VDI users guidelines are wrong. The problem
is that the variability of
response time is too great for a HDD. The only hope we have of
getting the back-of-the-napkin
calculations to work is to reduce the variability by using a device
that is more consistent in its
response (eg SSDs).
For sure there is going to be a lot of variability, but it seems we aren't even close.
Have you seen any back-of-the-napkin calculations which take into
consideration SSDs for cache usage?
Yes. I've written a white paper on the subject, somewhere on the
nexenta.com <http://nexenta.com> website (if it is still available).
But more current info is presentation at ZFSday.
http://youtu.be/A4yrSfaskwI
http://www.slideshare.net/relling
Great presentation Richard.

Our system is designed to provide hands-on labs for education. We use a
saved state file for our VMs which eliminate the need for cold
boot/login and shutdown issues. This reduces the need for random IO.
As well, in this scenario we don't need to worry about software updates
or AV scans, because the labs are completely sandboxed. We need to use
HDDs because you have a large amount of labs which can be stored for an
extended period.

I have been asked to adapt the platform to deliver a VDI solution so I
need to make a few more tweaks.

thanks,

Geoff

Loading...