Have you ever wondered what a scanner does with a VDI station? At first, everything seems fine: it is recognized as a regular USB device and appears 'transparently' on the virtual machine. Then the user commands it to scan, and everything falls apart. In the best case, the scanner driver crashes; in a worse case, the scanning software fails after a couple of minutes, and it might affect other users in the cluster. Why? Because in order to get a five-megabyte compressed image, you need to send two to three orders of magnitude more data over USB 2.0. The bus bandwidth is 480 Mbps.
So you need to test three things: UX, peripherals, and security â certainly. There is a difference in how to test. You can install agents locally on each virtual workstation. This is relatively inexpensive, but it does not show the load on the channel and does not accurately measure CPU load. The second option is to deploy the required number of robotic emulators elsewhere and start connecting them to real workplaces like actual users. This will increase the load from the video stream transmission protocol (specifically, changed pixels), as well as network packet parsing and transmission, providing a clear understanding of channel load. The channel is very rarely tested.
UX is the speed at which various actions are performed by the end user. There are test packages that load the installation with hundreds of users and perform typical actions for them: launching office suites, reading PDFs, browsing, and, rarely, watching inappropriate content during work 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 are transitioning to VDI; they have Office, a browser, and SAP. The IT department in the company is well-developed, so there is a culture of load testing before implementations. In my experience, it usually takes some convincing to get clients to agree to this, as it involves significant costs, and the benefits are not always obvious. After all, there are calculations where mistakes can occur? In practice, such tests uncover areas that were assumed but could not be verified.
Installation
Six servers, the configuration is as follows:
We had no access to the client's storage system; it was provided as a service in the form of space. However, we know it's all-flash. We donât know exactly which all-flash, but there are sections of 10 TB. VDI is VMware by the client's choice since the IT team is already familiar with the stack, and everything integrates quite organically into a complete infrastructure. VMware tends to really draw you into its ecosystem, but if the budget is sufficient for procurement, you can go for years without issues. But thatâs often a big 'if'. We have a good discount, and the client is aware of it.
We are starting tests because the IT team doesnât allow anything into production without testing. VDI is not something you can just run and then accept. Users are onboarded gradually, and issues can arise even after six months, which is obviously something nobody wants.
450 users in the test, generating the load locally. Robo-users perform various actions simultaneously, and we measure the time of each operation over several hours of operation:
We are observing how the servers and storage array behave. Can VDI create the necessary number of virtual workstations, and so forth? Since the client didn't opt for hyper-convergence and instead chose flash storage, checking the sizing accuracy was also necessary.
Basically, if something is lagging somewhere, we need to change the VDI farm's settings, particularly the resource allocation among users from different categories.
Peripheral
There are usually three situations with peripherals:
- The client simply states that we are not connecting anything (except for headsets, which are usually recognized 'out of the box'). For the last five years or so, I've very rarely seen headsets that wouldnât connect automatically and that VMware wouldnât recognize.
- The second approachâwithin the VDI implementation project we change the peripherals: we take the tested ones supported by us and the client. This case is rare for obvious reasons.
- The third approachâwe leverage the existing hardware.
You are already aware of the issue with scanners: intermediate software needs to be installed on the workstation (thin client), which receives the USB stream, compresses the image, and sends it to VDI. Due to a number of specificities, this is not always possible: while everything works fine on Windows clients (home computers and thin clients), for *nix builds, usually only a specific distribution is supported by the VDI vendor, leading to complications, just like on Mac clients. In my experience, very few people managed to connect local printers from Linux installations so that they worked during the debugging stage without constant calls to support. But that's improvement; some time ago, it was even difficult to get them to work at all.
Video conferencing â all clients eventually want this to work well. If the farm is properly designed, it works fine; if not, we end up with a situation where the load on the channel increases during audio conferences, and in addition, there's the issue of poor image quality (no full HD, face displayed in 9-16 pixels). A significant additional delay occurs when a loop appears between the client, the VDI workstation, the VC server, then a second VDI, and a second client. Itâs best to connect directly from the client to the VC server, which requires installing an additional component.
There are generally no issues with USB keys; smart cards and the like work out of the box. Complications arise with barcode scanners, label printers, machines (yes, that has happened too), and cash registers. But everything can be resolved. With its own nuances and surprises, but ultimately it is solvable.
When a user is watching YouTube from a VDI station, it creates the worst scenario for both load and bandwidth. Most solutions offer HTML5 video redirection. The compressed file is sent to the client and displayed there. Alternatively, a link for direct browser connection to the video hosting service can be provided to the client (though this is less common).
Security
Security often sparks at the junctions of components and on client devices. Ideally, everything should work well at the junctions within a single ecosystem. In practice, this is true about 90% of the time, and some adjustments are still needed. In recent years, another convenient acquisition by VMware has been their integration of MDM for managing devices within the company. VMware recently introduced interesting network balancers (formerly Avi Networks), which help address traffic distribution issues about a year after the VDI is delivered, for instance. Another VMware-specific feature is the good optimization of branches thanks to their recent acquisition of VeloCloud, which provides SD-WAN for branch networks.
From an end-user perspective, the architecture and vendor are almost invisible. What's important globally is that there's a client for any device, allowing connections from tablets, Macs, or thin Windows clients. There were clients even for televisions, but fortunately, they are no longer available.
The peculiar aspect of current VDI installations is that end users often do not have a computer at home. They might have a weak Android tablet (sometimes even with a mouse or keyboard), or they might get lucky and find a computer running Windows XP, which, as you can guess, hasn't been updated in quite some time. And it won't be updated ever. Otherwise, there are very weak machines where the client can't be installed, applications don't work, and users are unable to operate. Fortunately, even very weak devices can work (not always comfortably, but they work), which is considered a significant advantage of VDI. Regarding security â we need to test the compromise of client systems. This happens quite frequently.
In light of the recommendations from Rospotrebnadzor regarding the organization of work in enterprises amid the risk of COVID-19, connecting to workstations in the office is very relevant. It seems that this situation is here to stay, and yes, if you were considering VDI â it's time to start testing. It will come in handy. Recommendations are available. , clarifications . It's important that VDI can also help reconfigure spaces to comply with requirements. The regulator is introducing specific distancing norms. For example, in an office space of 50 square meters, no more than five employees can be present.
If you have questions about VDI that are not for comments, here's my email: SSkryl@croc.ru.
Source: habr.com
