Ever wondered what a scanner does with a VDI station? At first, everything looks good: it is forwarded as a normal USB device and is "transparently" visible from the virtual machine. Then the user gives a command to scan, and everything goes to hell. In the best case, a scanner driver, worse, in a couple of minutes, the scanner software, then it may affect other users of the cluster. Why? Because to get a five-megabyte compressed picture, you need to send two to three orders of magnitude more data via USB 2.0. Bus bandwidth 480 Mbps.
So you need to test three things: UX, peripherals and security - 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 deploy in another place with the required number of emulator robots and start connecting them to real jobs as real users. The load from the screen video stream transmission protocol (more precisely, changed pixels), parsing and sending network packets will be added, and the load on the channel will be clear. The channel is generally very rarely checked.
UX is the speed of performing different actions by the end user. There are test packages that load the installation with hundreds of users and do typical actions for them: launch office suites, read PDFs, browse, rarely watch porn during work hours, and so on.
A pretty good example of why such tests are important up front was in the last install. There, a thousand users move to VDI, they have an office, a browser, and SAP. The IT department in the company is developed, so 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. Are there any calculations where you can go wrong? In fact, such tests reveal places where they thought, but could not check.
Installation
Six servers, the configuration is here:
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, but the partitions are 10 TB each. VDI - VMware of the customer's choice, since the IT team is already familiar with the stack, and everything is quite organically complemented to a complete infrastructure. VMware is very “addicted” to its ecosystem, but if there is enough budget in the purchase, you can not know problems for years. But it's often a very big "if". We have a good discount, and the customer knows about it.
We are starting tests, because the IT team does not release almost anything without tests. VDI is not something that you can launch and then accept. Users load gradually, and it is quite possible to encounter problems in six months. Which, of course, no one wants.
450 "users" in the test, we generate the load locally. Robousers do different actions at the same time, we measure the time of each operation over several hours of work:
We look at how 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 follow the path of hyperconvergence, but took a flash storage system, 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 do not connect anything (well, except for headsets, they are usually visible “out of the box”). For the last five or so years, I've very, very rarely seen headsets that wouldn't pick up on their own, and that VMware wouldn't pick up.
- The second approach is to take and, as part of the VDI implementation project, change the periphery: we take what we and the customer have tested and supported. The case is rare for obvious reasons.
- The third approach is to throw over the existing hardware.
You already know about the problem with scanners: you need to install middleware on a workstation (thin client), which receives a USB stream, compresses the image and sends it to VDI. Due to a number of features, this is not always possible: if everything is fine on Win-clients (home computers and thin clients), then for * nix-assemblies, a particular distribution kit is usually supported by the VDI vendor and dances with a tambourine begin, as on Mac -clients. In my memory, few people have connected local printers from Linux installations so that they 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 it to work and work well. If the farm was designed correctly, then it works well, if not, we get a situation where during an audio conference we have an increase in the load on the channel, plus, in addition to this, there is a problem that the picture is displayed poorly (no full HD, a face of 9–16 pixels ). There is a very strong additional delay 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 immediately from the client to the video conferencing server, which requires the installation of another additional component.
USB keys - there are no problems with them at all, smart cards and the like, everything works out of the box. There are difficulties with barcode scanners, label printers, machine tools (yes, there were such), cash desks. But everything is decided. With nuances and not without surprises, but in the end it is solved.
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 a link is sent to the client for a direct connection between the browser and video hosting (this is less common).
Security
Security typically sparks at component interfaces and client devices. At the junctions in one ecosystem, in words, everything should work well. In practice, this happens 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 received interesting network balancers (formerly Avi Networks), which allow them to close the issue of stream distribution a year after VDI, for example. Another purely vmvar feature is the good optimization of branch offices thanks to their fresh shopping when they took on VeloCloud, which makes SD-WAN for branch networks.
From the point of view of the end user, the 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, win-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 can guess, hasn't been updated in a while. And it will never update. Or very weak machines where the client is not installed, applications do not work, the user cannot work. Fortunately, even very weak devices fit (not always comfortable, but fit), and this is considered a big plus for VDI. Well, regarding security, you 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 under the risk of COVID-19, connecting to their workplaces in the office is very important. It seems that this story is for a long time, and yes, if you thought about VDI, you can start testing. Come in handy. Recommendations lie , clarification . Importantly, VDI can also be used to refurbish rooms to comply. The regulator introduces certain norms of distancing. For example, in a 50 sq. m can not be more than five employees.
Well, if you have questions about VDI not for comments - here is my mail: [email protected].
Source: habr.com