I would like to share an experience I had several customer sites. Initially, I thought it was just a weird thing that only happened to me, but when I discussed at our sales launch event, I am flooded with "what happened to my account as" and even is part of a conversation with customers who have switched VMware View for XD after they went live. So the purpose of this blog is to share some information that I think people need to VDI investigation to know they gather information in their buying process.
a little history first .. When was released VMware View 5 launched a public relations campaign to try to convince the world that PCoIP, the protocol they license Teradici has "caught up" with HDX. they said they had overcome the problems of WAN, did a little song and dance in front of the Citrix desktop and referenced some videos (the second Gunnar Berger) showing apparently outperforming PCoIP HDX on an iPad by the end of their match proof points.
My reaction then was to release a technical diatribe about why they are not really catch up. However, it is only now that I realize I failed me to the dog and pony show, which is, I never really showed how HDX is still better than PCoIP, and so what I failed to stop was the continuous March of the videos in the accounts by VMware View reps claiming parity (or even superiority over HDX). As Gunnar tell you, different video scenarios can be rigged to produce specific results. Here's what I mean:
My point is that we need to look at the experience of the end user and holistic network performance, more than face value. Shawn Bass and Benny Tritsch made their "Protocols VDI Remoting Turned Inside Out" presentations for a long time now and I think that a thorough technical analysis of the actual performance of protocol, they are the gold standard. So I will not use this blog as another piece of lint on showing what's better in a 1: scenario 1. instead, I would like to challenge you to think bigger:
imagine that the experience of one user who logs in one office is equally as VMware and Teradici would have you believe .
in this scenario, the next consideration is bandwidth constraints . If WAN is indeed the last hurdle to clear before PCoIP can claim parity with HDX, then we must define a WAN.
most VDI benchmarks define static WAN conditions that are a Formulated bandwidth (B) latency (L), and a loss from time to time packet (P). So some value as B = 1mb / s, L = 100 ms, P = 0.05% for emulating specific WAN conditions. However, actual WAN requirements are dynamic - it goes without saying that adaptability should be an important measure to determine the efficacy protocol
In this spirit, I asked one of our ninjas Frank Anderson to add adaptability test. our technical standard marketing plan. Nothing complicated, just a scenario that would showcase an aspect of the HDX technology that is often overlooked in the POC static bandwidth conditions. Here's what he came up with (I quickly passed to the relevant part, but I encourage you to watch the entire video):
What is important to note above is twofold:
- user experience HDX on dynamic bandwidth requirements exceeds PCoIP
- HDX still takes significantly less bandwidth per user on the network that PCoIP
These two points are important to keep in mind when designing a VDI POC because the experience of the test user scale is something I regularly see VMware trying to avoid. Their demonstrations focus exclusively on one or the other user experience (some HD video) or wide (the number of VDI offices I can hold over a WAN link) but never both.
Ensure the existing network has sufficient capacity to handle the payload is one thing, but the impact of non-VDI bandwidth on the VDI user experience is probably even more relevant. While this may seem obvious, I rarely see someone saturate the POC test networks with all traffic other than VDI to test the impact of non-VDI traffic such as web, messaging, transfer files, backups, voice, etc. on VDI end-user experience (let alone the impact of traffic on VDI workloads - ie How VDI affects email or VOIP).
rejection of the user is the main reason for VDI projects fail . Another point of evidence for this position came from the analysis of Gabe Knuth's DaaS service OnLive, another virtualization solution that demo well, but would probably be rejected in a corporate environment. It does not matter if you can squeeze hundreds or thousands of workstations on a server or a network so that your end users see is the following:
therefore, it stands to reason that using the wrong protocol could make all the difference between success and failure. Instead of going further in the technology and lose what readers have left, my spec for a VDI POC FUD-less follows:
- Identify, Register and read more real workloads user
- Measure and reproduce dynamic network conditions
- Saturate the test bed network not VDI traffic such as HTML, MAPI, CIFS, VOIP, etc. representative of your existing application workloads (unless you plan to have a network dedicated solely to the VDI traffic)
- test scale, the CEP should represent 10% - 20% your driver (ie if your driver is 1,000 workstations trying to stage the POC to test 0 workstations)
- experience end user testing and scalability set (not to be seduced by the demos until you see with hundereds of workstations on the back-end infrastructure and the WAN )
If there is a delivery of this blog is this: your best chance of desktop virtualization strategy is to define a POC who is a representative of your pilot deployment. Do not be demo'd success.
0 Komentar