Building and Managing Virtual GPUs
March 26, 2014, GPU Technology Conference, San Jose, CA—Dane Young from Entisys Solutions talked about adoption and acceptance of virtual graphics functions. The move of more end-point operations into virtual functions raises issues in implementation and user interactions.
Remote graphics are the next phase of enterprise virtualization, allowing for thin clients at the desk and all other hardware functions in the network. The tools and software to move functions to the network are proliferating and are fairly robust. The leader is Citrix with its Agile 360 and other VDI solutions.
The rationale for desktop virtualization is greater agility, security, easier functional upgrades and maintenance , and mobility. The mobile devices often need additional GPU processing to make many desktop functions available on the mobile device.
Agility comes in many forms. Device independence allows Windows programs to run in non-Windows environments and platforms. Modular and remote functionality improves time to market, as no single platform is restricted by graphics performance. In addition, the virtual GPU farm provides flexibility for the future, as GPUs can be upgraded from central location, rather than having to upgrade every individual machine.
Security in the network helps preserve the data at rest. The network can protect IP better than in an individual machine, due to policies and restrictions per user. The net requires more authentication before granting access to those data. One area for consideration is the data size, and the impact of transfer times on processing time.
In general, remote graphics improve productivity. The near native response of a remote access GPU farm improves operational efficiency. Detaching the people from the corporation allows for easier maintenance of the various levels of data in the network.
Desktop virtualization is a concept that is growing in acceptance within the IT ranks. Before starting out, however, the concept requires a proof of concept design, pilot testing and functional conformation, before moving into full production and validation. It also helps to have an assessment of conditions and user desires before changing to drive to the goods. It is important to consider the fit for the in-place apps on the desktop versus hosted models.
The maintenance cycles can identify the goals for the project. These goals help to define the proof of concept design issues. Then research, discovery, and design lead to a pilot project for debug and scalability checks. Once the pilot is complete, the project can move to full production implementation and validation. Upon completion of the full system, the new system can be deployed in segments to the workforce. Management functions and routine evaluation can then lead back to another round of development. One aspect of this flow is that you are always working on getting the next generation of equipment ready.
Some tips and tricks to help ease implementation of new systems. The pilot phase is used to build, tune, validate, and scale the design after the proof of concept trials. Usually these phases use “perfect” data, but must understand the apps and users behaviors which can affect system performance. The pilot should take on from 10- 20 percent of the users and start at minimum capacity.
Starting small allows better containment of disasters and helps to determine the ability to scale. The pilot has to implement all of the design requirements, and all apps must be included in the user acceptance tests. The system has to be tuned for best performance with an eye to scale to the full system. It helps to benchmark before and after the pilot to measure difference.
An important feature of the pilot is some user acceptance testing, with all existing apps in the workplace. This testing helps to identify special functions or tools that are not in the operational inventory. Provide a checklist to confirm user acceptance and note all comments. Past practices have shown that printed forms are more reliable and used than on-line surveys. The survey must confirm all apps per department and per user. Create test cases for each app and check for full functionality. Make sure you check for special cases, especially ones that are rarely used.
The target population for the pilot should include the technology champions in various departments. They will help to identify important issues and problems in a way that can be addressed. Try to keep the troublesome and non-technical users out of the trials and address their issues later, after the new system is stable and all functionality is achieved.
Develop a “bug” list of issues to be resolved and allow everyone to track the fixes. The outstanding issues need to be prioritized by sponsors and teams, and all levels of communications are important.
The tools for evaluation and validation should be able to synthesize data sets and flows for benchmarks. Monitoring tools can track system functionality and GPU use over time for all relevant parameters like throughput, lag, etc. The same tools and others are needed for the production build and validation and other tools are needed for training the users.
By the time for end user rollout and deployment, the developers should have gotten overall user acceptance and willingness for adoption. Finally, overall management is a critical but often overlooked aspect of any changes to the systems.
