Have you ever heard conflicting information about a parameter or best practices and wondered what was really true or "true" best practice? Citrix never, right? 😉
I recently heard some people say to use fixed vDisk with PVS and others saying Dynamic . So what is the best practice true or real? That is precisely what I want to address in this article
Before we begin, please note :.
- I will not give an overall view of the virtual hard disk (VHD) format or to explain the difference between fixed and dynamic VHD. I highly recommend reading the short article by Jeff Muir on the VHD format if you want a history lesson or recycling. The actual VHD specification (now "owned" by Microsoft) is something I recommend you check as well - it is important to understand concepts such as footer and block sizes so you know how VHD dynamic grow
- I speak. about PVS in the context of the fixed elements vs dynamic. Many other technologies and products out there use the VHD specification. And just because a type of disk image is the "best practice" for PVS does not mean it is the way forward for other products or technologies out there that use the VHD specification (XS, HV, etc. .). In fact, I'll explain why PVS is "special" in this article, and why we can go against the best original fixed practice
- I do not speak of vDisk - the VHD file that contains the image of the operating system that PVS flow target devices. It is very important to distinguish between the write cache and the PVS PVS vDisk. And again, just because a type of disk image is the way to go for the vDisk does not mean the same is true for the write cache. While we support the equivalent of "dynamic" for the secondary drive that hosts the write cache file (.vdiskcache) - being equivalent thin-provisioning - write caching is not an ideal candidate for provisioning end. We are constantly writing to that file into very small pieces (ie 4k random write IOPS), so that the trouble associated with going dynamic or thin supply that lead could be significant, depending on the type of storage that supports it. So I want to be clear - this article is only on the vDisk (but maybe I'll do another article on Thin Provisioning later write cache because it is somewhat controversial!)
Now that I. 'I did the typical thing CYA board, we will get down to business. We acquired Ardence in 06 and best practice (after we passed the VHD specification for vDisk I might add ... we did not use the VHD original!) Was always something along the lines of "fixed for vDisk production, but momentum is OK to POC and testing. "reasonable Seems, especially because performance has always been king in this game. So we went for about 3 or 4 years and published many things that told vDisk always use "fixed". well, actually our direction on this subject has been quite confusing or nonexistent to be honest. that's partly why I would "clear the air" today. Let some of Citrix resources on this topic.
vDisk In our XenDesktop with PVS best practices whitepaper, we even mention fixed or dynamic. Oops ... I think I co-wrote that. Guilty! in our PVS 5.6 best practices whitepaper, we say to use fixed because "the internal structure of the dynamic VHD is different and can cause alignment problems." OK ... at least it's some guidance, but is that really true? Hold that thought for a second. In the PVS for XA Implementation Guide, we say to use Dynamic but we do not provide any reasoning or justification. Damn. On the PVS eDocs where we discuss the subject of imaging, we just say that you can go with either fixed or dynamic. So no help there. And finally, in the technote where we show the best practices for creating an image of XD, we also affirm just the two types and provide no guidance. Fail.
So if you add it all up, it's a few resources that say nothing, a resource that said fixed and dynamic resource that said. Impressive ... now it makes sense why I see clients doing different things, partners saying different things and our own consulting team not even knowing what we recommend about it!
So what is the answer? Well, if this was a technology or product other than PVS and the performance was important, I recommend fixed. But this is ... PVS and PVS is "special" as I said earlier. I think the reason we recommended set all this time was largely because we do not understand how PVS used system cache. And I give a lot of credit for understanding my friend Dan Allen. If you do not know how PVS operates kernel memory, please do yourself a favor and read a great book called Dan White "Advanced Storage Considerations Memory and PVS". But essentially, if we have a PVS server properly configured operating on a 64-bit platform with lots of RAM and we really cache the content of the disk stored in the VHD in the memory then we do not really care much about the disc or VHD because everything is served from memory! And since most of the time we use PVS, we use a standard mode image that is Read Only , we are not really anything written in this VHD, are we? This is why I said PVS was special ... as time goes to infinity, our bed this vDisk (VHD) ZERO approach. Because we are either using a block-level protocol to access the VHD (iSCSI, FCP or even local storage) or we access the VHD with NFS or CIFS, but we PVS tuning so it caches in fact the content of vDisk in memory. This is also why we say XD-PVS based deployments are about 0% IOPS write and only 10% IOPS read - because PVS operates its system cache to serve everyone reads the following target devices. These are super-big things, so if this is new to you or you scratch your head, please read again the white paper of Dan. This can mean the difference between a hot implement PVS smoking and very poor.
So we can use momentum to the PVS vDisk then, right? That's a fair assumption to make at this stage, but there is one more thing we need to know first. Do PVS add anything to the beginning or the end of the VHD as a header or footer extra? The PVS VHD really a "different internal structure" and not follow the VHD specification (possibly cause alignment problems resulting from poor performance)? Do we grow the PVS VHD in sizes of non-standard blocks or something? I arrived with our product PVS architect and LCM PVS team on this issue and the answers are no to all these questions. And what probably is even more confusing ... just as we add specific information to the PVS vDisk, we do not add to the actual VHD file. We use the PVP file (which is the "properties" file left by the Ardence days) to store these "side-car" info that is unique to PVS and PVS only. But that's good news because we are simply following the VHD specification for dynamic disks and we grow the VHD in 2 MB or 16 MB pieces (you can specify when you create the dynamic vDisk in the GUI PVS). And while there is a header and footer in the VHD, not specific PVS and I confirmed that we do not extend the header or footer ... it is just the header and footer used in all dynamic disks based on the specification defined by our PVS MSFT friends. And let us remember ... it's not like we're really writing or the expansion of this standard VHD file PVS fashion anyway, right? We first read from disk after the startup and suck everything in the system cache (memory) as soon as possible, so that we are barely touching the actual VHD file in the steady state. If we take advantage of PVS with images off the record (which are read + write), then it might be a different story here and dynamics could be bad. But 99% of the time, we make the images in standard mode and we will serve everything from memory, as opposed to drive in the steady state.
So now I can recommend safe to use with dynamic VHD PVS - even in production environments! not only save you a lot of time when you do things like vDisk updates, backups, copies, etc. But you can also save a lot of silver on storage costs by recovering all that white space! And go with dynamic (compared to the old fixed best practice) could mean the difference between using an extremely cheap local storage on a blade to expensive disks on a SAN. And above all, we do not sacrifice performance when using dynamic vDisk because PVS is special.
Remember, if we have a properly designed PVS environment, then we are caching the content of vDisk in memory and hardly ever touching the disk or VHD file. And the fact that we use the standard mode image means that we are not writing in this VHD file. And finally, our PVS-specific information is contained in a separate file properties (PVP) - we simply follow the VHD specification in terms of the way we store the image of the operating system in a dynamic VHD and we grow / develop VHD according MSFT best practices as well.
I really hope this clears any confusion (and I will ensure that this "new best practice" is reflected in our documentation). I would like to personally thank Jarian Gibson, Joe Shonk and Thorsten Rood for drawing my attention to BriForum last summer (and question our best practices, frankly). This should save our customers significant time and money as I said above ... while achieving the same performance as we know, love and expect fixed vDisk.
Cheers, Nick
Nick Rintalan, Senior Architect, Citrix Consulting
0 Komentar