Virtualization | Feature
Foolproof Desktop Virtualization: 4 Easy Steps
The CIO of Lone Star College System discusses how to evaluate desktop virtualization opportunities, set up pilots, and ultimately establish a reliable production environment.
Photo: iStockphoto.com |
|
This is the second installment in a three-part series on desktop virtualization. Part I focused on planning and building a business case, while Part III will examine the TCO and ROI.
|
Once you've evaluated the strategic value of a virtual desktop initiative on campus, you need to define exactly what your production environment will look like. You want a clearly defined architecture that will exceed your defined service levels and provide a rich customer experience--while keeping the project on track and on budget. Here are four steps to help you achieve your goal:
1) Monitor Demand
First, you need to know how your customers actually use computing resources on campus and what systems offer the best opportunities for desktop virtualization. Many tools on the market provide visibility into how systems are being used. By monitoring application demand and system-resource utilization, they can identify those systems that are prime candidates for desktop virtualization. At Lone Star College System (TX), for instance, we identify these opportunities by looking at the last 30 days of usage data.
These assessment tools can serve double duty since many also have the ability to monitor issues that may occur after you stand up your virtual desktop environment. This allows the IT team to ensure that newly deployed applications are performing well and that the appropriate resources are available.
2) Establish Proof of Concept
Before you finalize a deployment plan, it's critical to pilot a virtual desktop environment. This is actually the easiest part of the project, and the time and resources spent at this stage will significantly improve your ability to provide a comprehensive solution later. Before starting any pilot, though, first clearly define its goals and scope. It's all too easy during the pilot phase to shift the project's scope and lose momentum as a result. What is your area of focus? Student resources, personal devices, learning centers, computer labs? Is the emphasis on administrative functions such as business operations or kiosks? What about faculty: Will this be an additional or sole resource for this group?
It makes sense to start small, too: A virtual desktop pilot of 20-30 seats can yield the same results as a 50- to 100-seat pilot without the same complications. If possible, try to test your pilot on infrastructure that mirrors your planned production environment--just on a smaller scale. This will help identify potential problems.
To ensure the long-term success of your virtualization effort, also be sure to involve all areas of your IT shop in the pilot. It's the perfect time to identify and train key staff to support the production systems, and to include external experts alongside your IT staff. The knowledge gained by your staff will lead to improved support for your eventual production systems. Desktop virtualization involves a radical shift in how IT provides both desktop and infrastructure support, so provide every opportunity possible for staff to develop the skills they will need.
By its very nature a pilot is of limited scope, so it's important at this point to calculate the scale of the full project. In designing your final core infrastructure, the challenge is to determine what the number of your actual concurrent connections may be. If your pilot is focused on an administrative function such as business operations, for example, the concurrent connections ratio will be much higher than for a pilot dealing with student computing resources.
One final caution: While planning and testing are absolutely imperative, be careful not to over-pilot. If you spend too much time on pilots, the project can lose credibility.
3) Set Expectations
While a pilot project can be more forgiving than a production environment, it is nevertheless critical to define your service levels early. Your final design will be based on these service levels. One advantage of all virtual desktop solutions is they are built on a virtual server/application platform, which has an inherent resiliency that can prevent major system failures.
To start, you need to identify the acceptable level of risk, or tolerance. How tolerant will your organization be if, during login, a "boot storm" brings the process to a crawl? What will happen if the core infrastructure fails and all systems go down? Will students still want to use virtual desktops if the systems are slow over a wireless connection? While there are deployment models that will reduce these risks, they will also impact the project cost.
Ultimately, your service levels for virtual desktops should be better than your current service levels for physical desktops. This can be achieved when your virtual desktop environment is designed around a dynamic desktop running on solid-state hardware.
4) Design for Success
Network.Start with your network! The network will be a defining factor in your final design, so it's critical to have network staff involved at all stages. Even if your core team designs for performance, if your network can't deliver your customers will see a drop in quality. Constant monitoring of network performance during the pilot can help eliminate future issues. On a positive note, the demand placed on networks by virtual desktops has declined significantly in the last few years, due to the rapid adoption of mobility platforms along with virtual desktop performance tuning.
Architecture Models. In setting up a virtual desktop initiative, schools can choose from several deployment models, each with significant pros and cons:
- Single infrastructure: In this model, the infrastructure is deployed for a single function: desktop virtualization. The system can be split into segments--one for student computing, for instance, and another for administrative functions. While resiliency can be built into this design to address the failure of a hardware component, the impact of a total failure of the system would be significant. Simply put, if the virtual environment supporting 3,000 student desktops fails, it's time to start polishing your résumé. To prevent this from happening, you must have highly skilled staff to monitor the systems along with virtual desktop/application performance. On the plus side, this model of deployment offers a lower cost of ownership than the private cloud model (see below).
- Private cloud: This model will significantly reduce your risks and allow you to mix the administrative and student virtual desktop resources with a high level of fault tolerance. The challenge to deploying this model is cost--and the need for facilities and experience. To deploy a private cloud, the core infrastructure must reside in two or more data centers, and the staff must have experience in balancing these cloud resources. While the cost is higher, it's certainly not double that of the single infrastructure model. In the event of a catastrophe, though, performance might be diminished but customers would still have access.
- Hybrid cloud: This model utilizes virtual desktop endowments delivered via a hosted provider. It's a relatively new approach and is typically priced on a per-desktop, per-month basis. Use of a hybrid model would alter your internal hardware needs while at the same time significantly impacting your network distribution and bandwidth requirements. While the hybrid model has gained some traction in certain industry sectors, it's rare or unknown in the education sector other than in distance learning or specialized application training. One important proviso: While your school would not manage the core infrastructure under this model, if the service were to go down you would be at fault, not the provider.
Endpoint Devices. Establishing standards for the endpoints is just as important as the core infrastructure. Plus, sticking to these standards through the first phases of pilot and production will greatly simplify your project. These device standards establish a baseline for deployment based on the actual chipsets. In the last year, major breakthroughs have enhanced device and video performance. As with everything else, many options are available--including BYOD for students. The typical endpoint options are:
- Client-access software: Students and faculty use their own devices, provisioned via a software application.
- Zero clients: Also known as ultra-thin clients, these typically use an all-in-one solid-state approach that boots directly to the virtual desktop environment. These devices are also available without the all-in-one design.
- Thin clients: A solid-state device that has additional capabilities along with performance enhancements--video, local memory, and expansion bays. Many of the new zero clients are also adding these features.
- Provisioning of existing desktops: This approach uses existing hardware to boot directly to the virtual desktop environment. It's a good way to extend the life of older desktops that lack the resources to run newer operating systems or applications.
Backup Systems. Do not overlook the impact that a virtual desktop environment will have on your backup and recovery systems. Take the time to identify what will be backed up beyond the servers supporting virtual desktops.
