Ever wondered what a scanner does with a VDI station? At first, everything looks good: it throws itself like a regular USB device and is “transparently” visible from a virtual machine. Then the user gives a command to scan, and everything falls to hell. In the best case - the scanner driver, worse - in a couple of minutes the scanner software, then it can affect other users of the cluster. Why? Because to get a five megabyte compressed picture, you need to send two or three orders of magnitude more data via USB 2.0. The throughput of the bus is 480 Mbps.
So there are three things to test: UX, peripherals, and security are a must. There is a difference how to test. You can install agents locally on each virtual workstation. This is relatively budgetary, but does not show the load on the channel and does not quite correctly calculate the load on the processor. The second option is to turn around in another place with the required number of emulator robots and start connecting them to real jobs as real users. The load will be added from the protocol for transmitting the video stream of the screen (more precisely, the changed pixels), parsing and sending network packets, the load on the channel will be understood. The channel is generally very rarely checked.
UX is the speed at which an end user can perform different actions. There are test packages that load the installation with hundreds of users and perform typical actions for them: launch office suites, read PDFs, browse, rarely watch porn during working hours, and so on.
A pretty good example of why such tests are important in advance was in the last installation. There, a thousand users move to VDI, they have an office, browser and SAP. The IT department in the company is developed, therefore there is a culture of load testing before implementation. In my experience, usually the customer has to be persuaded to do this, because the costs are high, and the benefits are not always obvious. There are calculations where you can make a mistake? In fact, such tests reveal places where they thought, but could not verify.
Installation
Six servers, the configuration is:
We did not have access to the customer's storage system, it was already provided in the form of a place as a service, in fact. But we know that there is all-flash. We don't know which all-flash exactly, but 10 TB partitions. VDI - VMware according to the customer’s choice, since the stack is already familiar to the IT team, and everything is pretty organically supplemented to a complete infrastructure. VMware is very "addictive" to its ecosystem, but if there is enough budget in the purchase - for years you can not know the problems. But this is often a very big if. We have a good discount, and the customer knows about it.
We start tests because the IT team does not release almost anything without tests. VDI is not a thing that you can launch and then accept. Users are loading gradually, and problems may well be encountered in six months. Which, naturally, nobody wants.
450 "users" in the test, we generate the load locally. Robo-users do different actions at the same time, we measure the time of each operation for several hours of operation:
We look at how the servers and storage systems will behave. Will VDI be able to create the required number of virtual desktops, and so on. Since the customer did not take the path of hyperconvergence, but took flash storage, it was necessary to check the correctness of the sizing too.
Actually, if something slows down somewhere, you need to change the settings of the VDI farm, in particular, the distribution of resources between users of different categories.
Periphery
There are usually three situations with the periphery:
- The customer simply says that we are not connecting anything (well, except for headsets, they are usually visible "out of the box"). For the past five years or so, I have very, very rarely seen headsets that would not pick up on their own and that VMware would not pick up.
- The second approach - we take and, within the framework of the VDI implementation project, we change the periphery: we take the one that was tested by us and the customer supported. The case is understandably rare.
- The third approach is to throw in the available hardware.
You already know about the problem with scanners: you need to put intermediate software on a workstation (thin client), which receives a USB stream, compresses the picture and sends it to VDI. Due to a number of peculiarities, this is not always possible: if everything is fine on Win clients (home computers and thin clients), then for * nix assemblies, a specific distribution is usually supported by the VDI vendor and dances with a tambourine begin, as on Mac -clients. In my memory, few people connected local printers from Linux installations so that they would work at the debugging stage without constant calls to support. But this is already good, some time ago - even just to work.
Video conferencing - all customers sooner or later want this to work and work well. If the farm was designed correctly, then it works well, if it’s wrong, we get a situation when the load on the channel increases during an audio conference, plus in addition there is a problem that the picture does not display well (full HD no, 9-16 pixel face ). There is a very strong additional latency when there is a loop between the client, the VDI workstation, the video conferencing server, from there the second VDI and the second client. It is correct to connect directly from the client to the video conferencing server, which requires the installation of one more additional component.
USB keys - there are no problems with them at all, smart cards and the like, everything works out of the box. Difficulties are with barcode scanners, label printers, machines (yes, there was such a thing), cash registers. But everything is decided. With nuances and not without surprises, but ultimately decided.
When a user watches YouTube from a VDI station, this is the worst situation for both the load and the channel. Most solutions offer HTML5 video redirection. The compressed file is transferred to the client, it shows there. Or the client is given a link for direct communication between the browser and video hosting (this is less common).
Safety
Security usually sparks at the interface of components and on client devices. At the junctions in one ecosystem, in words, everything should work well. In practice, this happens in percentages in 90% of cases, and something still needs to be completed. In recent years, another purchase of Vmvara turned out to be very convenient - they took MDM into the ecosystem to manage devices within the company. VMs have recently acquired interesting network balancers (formerly Avi Networks), which allow closing the issue of flow distribution a year after the delivery of VDI, for example. Another purely embedded feature is the good optimization of the branches thanks to their fresh shopping, when they took on VeloCloud, which makes SD-WAN for branch networks.
From an end-user perspective, architecture and vendor are almost invisible. It is globally important that there is a client for any device, you can connect from a tablet, poppy, wine-thin client. There were even clients for TVs, but now, fortunately, they are gone.
The peculiarity of VDI installations now is that the end user simply does not have a computer at home. Often there is a weak android tablet (sometimes even with a mouse or keyboard), or you can even get lucky and get a computer on Win XP. Which, as you might guess, hasn't been updated for a while. And it will never be updated. Or very weak machines, where the client is not installed, applications do not work, the user cannot work. Fortunately, even very weak devices are suitable (not always comfortable, but suitable), and this is considered a big plus of VDI. But regarding security, we need to test the compromise of client systems. This happens quite often.
In the light of the recommendations of Rospotrebnadzor on organizing the work of enterprises in conditions of COVID-19 risk, connecting to their workplaces in the office is very important. It looks like this story will last for a long time, and yes, if you thought about VDI - you can start testing. It will come in handy. Recommendations are here , explanations are here . It’s important that VDI can also convert facilities to meet requirements. The regulator introduces certain standards of distance. For example, in an office with an area of 50 sq. m cannot be more than five employees.
Well, if you have questions about VDI not for comments, here is my mail: SSkryl@croc.ru.