The Virtual Computing Lab at North Carolina State University (NC State), established August 2004, proved that the concept of a highly scalable, high-performance computing (HPC) resource providing on-demand applications anywhere/anytime had become a reality in this particular educational setting.
The VCL allows platform-independent access to a variety of computing configurations without having to maintain each one separately. This is done through software images installed (on demand by users) onto blade servers. The result is a highly scalable computing environment that allows users to use what they need when they need it.
The VCL was a groundbreaking project, in that it used entirely open source tools to dramatically increase the accessibly of computing resources for students, but the costs incurred are beyond the means of most smaller universities. However, in light of lessons learned, we now know that a much more affordable implementation is possible. Here, we offer a case study of a follow-on VCL pilot project at North Carolina Central University (NCCU), an historically black college in Durham, NC. But NCCU has less than a third the number of students as NC State while also being a liberal arts college (with a science focus), not an engineering school like NC State. By leveraging NC State expertise, we showed that such technology is within reach of practically any educational institution.
Virtualization is a key component of the way applications are deployed and used today.2 Users are no longer tied to a particular locale or limited by a particular workstation environment, and organizations are no longer limited to applications that use platforms commensurate with the expertise of their IT-support staffs. For example, professors who need applications to run on Linux need not be concerned if their universities’ IT staffs include all authorized Linux administrators. Virtualization allows operating environments to be simulated in a way that does not require in-house expertise in the environment being used.5 What is required are users who know the applications they’ll be using and their proper configurations. The VCL project at NC State is a large-scale, publicly accessible example of a virtualization application in education,1 providing transparent access to dozens of applications used by students and their professors in virtually every discipline in the university. It has dramatically altered the way students and faculty access the school’s computer resources.
Founded in 1910, NCCU today has an enrollment of approximately 8,500 students. As a liberal arts school with a science focus, it includes the Biomanufacturing Research Institute and Technology Enterprise and the Biomedical and Biotechnology Research Institute and so has an ongoing need to manage diverse computing environments to support their various research projects. The VCL project represented a good model for addressing NCCU computing needs.
We attended a fall 2004 technology conference in Research Triangle Park, NC, where virtualization was covered. Researchers from NC State and Duke University described a project that allowed an infrastructure built on a Linux, Apache, PHP, MySQL (or LAMP) software base installed on blade servers to host multiple research projects on different platforms. For example, if one faculty member had a project requiring a Windows-based server and another had a project requiring a Solaris-based server, both projects could be hosted on the same infrastructure through virtualization of the respective operating systems. While not newcomers to virtualization, we were nonetheless impressed by how blade servers added a higher level of scalability. We began to seek out relationships with researchers and major technology companies in the Research Triangle Park area to determine how NCCU might get involved in the flow of this innovation.
Over the next two years we received a series of hardware grants and cash awards that allowed NCCU to build a simple blade-server infrastructure suitable for a virtualization project. We were introduced to the VCL project in the College of Engineering at NC State where blade servers and virtualization, as well as stored images containing software components, were installed directly on the blades. Strictly speaking, using a full image on a blade is not “virtualization” per se, but the “virtual” designation fits in that users access the application remotely, not on their local computers. The project’s most notable innovation was software-driven management logic that provides resources as needed and allows unused resources to be used for HPC applications, including molecular analysis. Students could use any Web browser with access to adequate bandwidth (at least 125kbs) to connect to dozens of desktop applications anywhere/anytime.
We intended to deploy this innovation at NCCU using blade servers—ultra-thin computers with multiple high-end processors—in a highly flexible “one-stop-shop” infrastructure to provide the same service to our students and faculty. With the two major biotechnology centers at NCCU, along with the university’s focus on scientific computing, we felt the NC State approach would also be appropriate for NCCU—use the blades to run virtualized applications when needed but apply all idle processing time to long-running, processor-intensive scientific applications.
The goal was a scalable, reliable infrastructure for both virtualization and HPC applications. Toward this end, we began by purchasing nine blade servers. In fall 2005, we received a hardware grant from IBM (www.ibm.com/university) providing $84,000 for hardware, though nothing for software or support. Most was apportioned to the infrastructure to support the blades, leaving little for the blades themselves. For example, the rack required to host the chassis for the blades cost $2,649. The network switch for the blades cost $10,000. The monitor, keyboard, and video and monitor connector cost $2,245. After we ordered these foundational pieces, there was funding enough for nine initial blades. We chose IBM HS20 Xeon blade servers with 4GB of RAM and two 3.8GHz processors per server. Each server also had two 36GB mirrored hard drives. The cost per blade, with extra processor, memory, and hard drive, was approximately $6,106.
One technical lesson we learned quick was there really is no need to mirror the hard drives in the blade servers when using them for virtualization and that it is better to spend our grant money on a faster processor and more memory. The failure rate of the IBM blade servers was low, and if students were backing up their work to permanent storage (as we advised them to do), the unlikely event of a drive failure would be only an annoyance, while the students secured another session and resumed their work. No drive failure during any session has been reported by NCCU users.
In 2006, we were awarded a second grant from IBM for the same amount. This time we were able to spend more of the grant money on blade servers. Having learned we did not have to mirror the hard drives, we were able to purchase higher-end blade servers at lower cost. This time, we chose 14 IBM HS21 blade servers (a later model from the previous year) with 72GB hard drives, two 3.8GHz processors, and 4GB of memory. We then had a total of 23 blades in the two chassis.
Staff from NC State and NCCU Information Technology Services (ITS) assisted in the installation of the initial blades. Our intention was to adhere to the NC State LAMP standard as closely as possible, the rationale being that we wanted to leverage the existing knowledge base, deviating from the standards only when absolutely necessary. However, circumstances prevented rigid adherence to the NC State installation model. The standard operating system (OS) NC State used was the Red Hat Enterprise License (RHEL) distribution of Linux. While the State of North Carolina has a licensing agreement with Red Hat to use RHEL, we could not get clarity as to how we might properly use the license for our installation. We decided on SuSE 10.1 (available for free at the time) as our OS because one of the consultants working with us was familiar with it, and in our judgment Red Hat Fedora (another free distribution) was not appropriate for our purposes.
As a physical location for the equipment, we chose a data center in Research Triangle Park that already housed many North Carolina University system projects, including much of the VCL infrastructure. Though the decision had not been formalized at the time of our 2006 installation, we knew the data center had sufficient power, cooling, and bandwidth, and its staff was familiar with the equipment the NCCU team would be using. The initial cost for housing the blade center, including power and bandwidth, was approximately $600/month, which we considered reasonable.
The project’s driving theme was the use of existing expertise to extend both the VCL footprint and NCCU’s computing capability. We knew that virtualization per se is a somewhat mature technology we had not previously tapped due to the limits of NCCU staffing and expertise. Our collaboration with technology companies (one of which, IBM, provided the hardware grant), the data center (which hosted the project as funding was worked out and provided unpaid assistance), and other universities in the area (an endless supply of innovation and expertise) is as much the story here as the technology of virtualization. The model we used thus represents a template for a bare-bones venture into virtualization technology by institutions otherwise lacking the resources to do so. This will prove invaluable for those in remote areas, like rural school districts, and those with limited financial resources, like many in North Carolina today.
The NC State VCL uses blade servers for hardware and a LAMP open source environment for software. Red Hat Enterprise License is the core OS, though we also still use SuSE 10.1. We emulated this environment due to its stability, flexibility, and scalability—characteristics of an infrastructure suited to our purposes. Our resources were limited; we initially (in 2005) lacked funding other than what we received to purchase hardware. But one VCL merit is a system built (basically) with open source software. Meanwhile, the LAMP environment has proved itself robust enough for even the most demanding use in terms of number of users, application size, hours of operation, and performance.
Figure 1 outlines the hardware used to deploy the VCL. Applications are deployed using either full images of the application (including OS and peripheral files) installed directly on an empty blade or virtual machines via VMware. These images are stored in an image library until the scheduler calls them to be loaded. The scheduler, consisting of code written in PERL and PHP, communicates with the MySQL instance containing the data for the system. The entire infrastructure sits on racks of blade servers maintained at a central location in Research Triangle Park; some parts are in NC State’s facility in Raleigh, NC, but over the next few years all VCL equipment is expected to be located in the Research Triangle Park facility.
Users access the VCL from their personal locations, whether school, lab, home, or during travel. What they need is some form of broadband connection (as little as 128kbs is sufficient, though at least 256kbs is recommended), a computer with TCP/IP (properly configured), and a Web browser. The VCL uses student and faculty institutional email for authentication, an approach that facilitates the VCL’s extensibility. Users external to NC State do not need to maintain separate VCL authentication identities, selecting whatever identity they normally use to get onto their own organizations’ networks. Users authenticating to the VCL see a screen like the one in Figure 2.
From that initial screen the users select the application (image) they want to use, the time they want to use it, and the duration of their session. When using applications, they select a remote-access client (varying by OS) to attach to and use the image as if it were their regular desktop. Performance is excellent; only changes to the desktop screen traverse the network, with all processing occurring on the blades or on whatever high-end hardware houses the VCL not otherwise married to a blade configuration.
The NC State implementation is robust and stable, but building a similar application from scratch would be prohibitively expensive for smaller institutions. What emerged is a methodology that allows any institution, irrespective of size, to use the system. At present, NCCU is able to use it in day-to-day functions, somewhat separate from the NC State VCL team. While support from NC State is still required, it decreases with the passing semesters. As the pilot project expands and is viewed as successful, the NCCU goal is to be completely autonomous in terms of hardware, software, and maintenance, though such autonomy is not strictly necessary. Whether an institution wants to run its own part of the VCL or have it run by NC State varies by institutional mission. For NCCU, having its technology students fully understand the VCL is almost as important as the value it gets from using the tool itself; on the other hand, a middle-school English class might need access only to word processing software. Having the mission of each institution drive the configuration of the tool highlights the VCL’s flexibility and fitness as an educational resource.
The evolving VCL model involves a loose confederation of user organizations consisting of several colleges and community colleges in the University of North Carolina system. Some purchase their own blades, deploying them in racks in the data center housing VCL equipment; some use the existing equipment and just add users to infrastructure already deployed. A statewide VCL network will eventually include K12 school systems in North Carolina, nonprofit corporations, and other organizations in need of the functionality the VCL provides but lacking the means and expertise to deploy themselves.
NCCU has partnered with two high schools that exemplify the VCL’s eclectic nature; one is interested in the VCL primarily as a tool for teaching networking concepts, the other more in the easy access to the software it provides. Both serve predominantly African-American student populations that would benefit tremendously from being exposed to VCL innovation.
What about licensing? On the surface it might seem that licensing would add considerable complexity to VCL deployment. However, none of the VCL partners have found this to be the case. All that is required of any institution is a clear understanding with the software vendor that access to its products conforms to the agreed-upon license; access logs provide ready confirmation that the terms of the license have been followed. For certain products (such as widely used statistical software), we meet with the vendor to establish the processes it finds acceptable for accessing its product. For individual licenses, VCL staff maps users to software per the product’s license agreement. While some up-front organization is required, licensing is not a major hurdle.
What about VCL bandwidth requirements? Because users access software remotely (the application is not on the user’s local system), use of bandwidth does increase somewhat. Programs that are graphically intensive (such as engineering design) send more packets than less graphically intensive programs (such as word processing). However, during NCCU pilot development we found neither performance degradation on NCCU’s network nor severe performance issues on graphically intensive programs (such as AutoCAD). The local high schools use Alice, a 3D programming environment that uses graphics extensively; its performance via the VCL is more than acceptable. A more challenging test, perhaps, is a more graphically intensive business simulation, like IBM’s business-process simulation Innov8 (http://www-01.ibm.com/software/solutions/soa/innov8/index.html). Because it requires high-end graphics capability on the monitor (a problem not directly related to the VCL), we have been unable to test its effect on the VCL environment because the graphics cards in our lab machines don’t support the required graphics. We’re eager to see how the VCL handles such applications when the monitors on those machines are upgraded to render graphics for programs like Innov8.
Discussions among faculty and administrators at both NCCU and NC State, along with the local technology companies funding project hardware and the NCCU data center staff were necessary for planning how to use the VCL at NCCU. All the administrators seemed to understand and recognize the value of the project, giving it their full support. Such support is vital to any technology project. An early question involved who would pay to house the equipment. The funding grant NCCU received for the project was limited to hardware. Ultimately, the NCCU School of Business (with permission of its Dean) absorbed the initial housing costs for the equipment.
We installed SuSE 10.1 on the first nine blades in early 2006. That spring we began to poll the NCCU community about what applications it used that might be deployed on our blades. The first was Web MO, a chemistry program for molecular analysis, complementing our plan to use the processing power of the blades to run scientific programs when not used for virtualization. A blade was dedicated to classes in both the NCCU School of Business and School of Library and Information Science. Classes using these blades were graduate database classes (Library and Information Science), programming and database classes (School of Business), and Web development (School of Business). The entire university could access the resource without interfering with the production infrastructure managed by NCCU ITS. These parts of the project were completed in summer 2006.
Beginning fall 2006, the NC State VCL team began making presentations to faculty and staff beyond the NC State campus, explaining the promise of the VCL. The NCCU Provost attended one and gave the project her full support. NCCU administrators determined that a formal VCL pilot project was warranted for roll-out in fall 2007. This included NCCU’s willingness to pay the cost of housing its blade center. We cannot stress enough how important it was for this to be perceived as an NCCU-wide project not restricted to NCCU’s School of Business. The greater the VCL footprint, meaning the larger the number of users, the greater would be the value to the entire university.
Once the CIO, Provost, and Dean of the School of Business were in agreement that NCCU would develop the VCL, members of the NCCU VCL team (now NCCU ITS) were assigned to identify the applications the VCL would support. So we asked NCCU faculty what applications they felt would provide the greatest initial benefit. The consensus was the statistical package SAS. One reason for this choice was that the more popular standalone version of the package had to be installed on every workstation that uses it. Since the application is updated regularly, manually updating every workstation is prohibitively labor-intensive, in spite of imaging software. If the application could be accessed centrally, this would produce a considerable cost saving in terms of labor. In addition, students in classes requiring SAS usually come to campus to do their assignments because the software is too expensive for them to purchase on their own, and the SAS academic license requires it be installed only on NCCU computers. The VCL would allow them to access the software remotely.
One technical lesson we learned quick was there really is no need to mirror the hard drives in the blade servers when using them for virtualization and that it is better to spend our grant money on a faster processor and more memory.
The CIOs of NC State and NCCU met with SAS management to determine how SAS could be accessed through the VCL. SAS agreed to allow faculty and students at NCCU, NC State, and other affiliated users who follow all requirements of the SAS licensing agreements to access the product through the VCL.
Now the problem was how to let NCCU users actually aaccess it. The NCCU team lacked the expertise to manage the system’s scheduling of images and virtual machines but did not want to add to NC State’s administrative burden by having to routinely manage NCCU users. The VCL teams at NC State and NCCU agreed that the NC State infrastructure would serve as a base for other organizations so the scheduling and management logic of the NC State VCL engine would serve additional participants. As resources were acquired and added to the infrastructure (to be centrally located in the Research Triangle Park data center), for the time being, management logic would still be centralized. As the VCL code base was made portable (not the case initially), other entities would be able to use the code to manage their own parts of the infrastructure. The blade configuration was such that all chassis added to it could be managed centrally through a “management module” on each rack, an approach providing maximum extensibility.
Another positive development was IBM awarding an additional hardware grant to NCCU in fall 2006. As we had already purchased much of the infrastructure to house additional blades, we used the new grant to purchase 14 more blades. This time, we chose Centos 5 as the OS. Though the RHEL license issue was still not resolved, the Centos design is very much like RHEL, and we felt this would help move NCCU toward a standard configuration.
One thing apparent early in this process was that a facilitator, or person with direct interest in VCL adoption, is essential. While necessary, academic departments, administrators, and technical managers “getting it” is not sufficient. The project repeatedly ran into obstacles that would have been fatal without the required commitments. Even an executive champion is not sufficient. A facilitator must be able to build communication channels, provide or find expertise, help the organization with funding, and act as handholder/cheerleader as the organization grows into the VCL.
One reason the facilitator is so essential is that almost invariably several entities are involved. The VCL is not an application whose value is best derived through its use in one or two departments. The VCL’s greatest value is when an entire institution, across functional units and academic disciplines, uses it to seamlessly access computing resources.
The facilitator (like champions in other technology projects) must present the idea to both administrators and technical people as something desirable, as well as doable. The technology itself is not daunting to most IT shops; virtualization is not new. But to the staff it could be seen as extra work. The facilitator must address this perception, making it clear that the VCL means less work, not more.
It’s entirely possible that convincing a university’s president, provost, and/or CIO is not sufficient; there may be resistance from department heads and technical leads who see the VCL as problematic. The facilitator can identify and help articulate the most important value-adds; one is that the VCL flattens the hardware landscape so different labs access the same application on the same platform, for the most part irrespective of the configuration of the workstation accessing the VCL.
In larger organizations, the facilitator convincing a dean to try the VCL may indeed be able to marshal the necessary resources but must still ensure all parties follow through; in this context the facilitator is more like a project manager. For smaller organizations, however, the facilitator may do everything, from moving the organization’s mail identities into a Lightweight Directory Access Protocol structure to finding funds to purchase software, to creating the images to be used through the VCL.
By fall 2009, the NCCU VCL pilot had been in effect two full academic years, serving several targeted areas of the university. The heaviest users were from the following programs: Computer Information Systems (CIS), Decision Science, Marketing, and Hospitality and Tourism, and the School of Library and Information Science. In addition, special licensing was arranged for a local high school to access an application via NCCU’s license with the application’s publisher.
While the duration of the pilot was never specified, we (the authors) were comfortable that it is now ready to put into production. However, a delay was encountered (a change of CIO at NCCU), and such a campuswide project cannot be accomplished until a new CIO is in place. We do not know when this will occur.
Meanwhile, from September 1, 2007 to December 31, 2009 a total of 11,529 reservations were submitted to use the VCL; total usage time of all applications was 14,645 hours, with 947 unique users. The most popular images/virtual machines were courseware for a CIS course (2,488 reservations, 328 unique users during the pilot project); SAS (1,657 reservations, 191 unique users); an Alice image at Hillside High School (1,174 reservations, 109 unique users); an Office 2007 image at Hillside High School (1,082 reservations, 86 unique users); an image of the statistical package SPSS (771 reservations, 99 unique users); and tools to access a mainframe for a course in mainframe technology (893 reservations, 34 unique users).
This usage profile shows that if the requested applications are provided through the VCL, users will use them. The NCCU VCL pilot project opened a new realm for virtual access to applications. NCCU is not an engineering school with layers of technology expertise. It has a highly competent but small ITS staff (in many ways the reason for the project’s success). Most of our expertise extended from NC State, which has shared lessons learned with us.
Our (the authors) role in the pilot project has been to put the right people in the right places at the right time. Through the business model that emerged from this process, we hope to bring other organizations into the VCL family.
Historically black colleges and universities, both public and private, can benefit from this model. We are in discussion with two larger technical HBCUs: Morgan State University in Baltimore, MD, and NC A&T State University in Greensboro, NC (both engineering schools). Southern University in Baton Rouge, LA, also an engineering school, recently received funding to begin its own VCL project. The NCCU VCL team is in discussion with the Southern VCL team to help facilitate the project.
Comments from faculty and students reflect the ease of VCL access. In each semester of the pilot, NCCU faculty used VCL for undergraduate and graduate classes requiring SAS software, mostly by students with no familiarity with the software; more than 300 participated. The related faculty had all taught SAS-related courses for years, so the content was familiar. The undergraduate students were, for the most part, newcomers to SAS. Most of the graduate students had some experience, but none could be considered an expert.
Each semester of the pilot project we’ve regularly asked all related professors whether their students reported difficulty accessing SAS software through the VCL. Other than ensuring students use the correct credentials to log into the system (NCCU student identities), we’ve received no reports of difficulty accessing the software when off campus. Moreover, none of the students with whom we spoke reported any difficulty accessing the software remotely, once they logged into the system once or twice.
Several students functioned as unofficial technical support for the software (more for SAS than for the VCL), greatly enhancing the experience of their less-proficient counterparts, at least according to the students with whom we spoke. These impromptu experts eased the novelty for novices logging in for the first time. One graduate student whose home was adjacent to campus served as a sort of coordinator for graduate novices logging in for the first time.
NCCU has benefited from the fact that the VCL makes complicated installations less burdensome when done concurrently in labs with dissimilar hardware configurations. NCCU ITS uses a set number of master images to deploy OSs and software applications to the labs. While the images are designed for lab heterogeneity, any application outside the existing configurations could cause problems for ITS staff. An example is an application the CIS Department uses to teach students office-productivity software. Though not complicated to install, it is beyond the scope of the NCCU ITS standard image and involves ITS managers assigning staff to install it. The solution was to have CIS faculty using the application create an image, then have the students access it. The software publisher sees no violation of its license agreement, and NCCU ITS does not assign support staff to install and maintain the package. While this is a rather pedestrian example, it nonetheless caused considerable frustration on the part of both the CIS faculty and the NCCU ITS staff.
Because the NCCU VCL pilot project could count on NC State’s extensive expertise and resources, we had little concern that the pilot project’s workload would overwhelm our blades. Because we deployed both virtual machines and “bare metal” images (loaded directly onto the blade servers), we addressed any limitation in our resources through NC State’s much more robust infrastructure. NC State had been the recipient of both cash grants and hardware donations to support an environment with hundreds of blade servers.
Because we used NC State’s node-management software, it was a small matter to direct users to available resources; we have no record of a user lacking available resources to use an image. We calculated that if we could dedicate all 14 blades, we could also support four virtual machines per blade, for a total of 56 concurrent users; most of the applications are not computationally intensive, and we were able to distribute computationally intensive applications, like SAS, across several blades to balance demand on the processor. At no time did demand from the pilot approach this requirement. Our focus was not so much on maximum utilization of resources (though with virtualization this goal is a given) as it was on determining the level, quality, and type of service that would be required for faculty and staff to use the infrastructure.
We planned to address demand in several ways:
- Use the large donation of processors and cash to NC State by IBM and Intel to provide enough resources so the entire 16-campus University of North Carolina system could use the VCL the same way NCCU and NC State use it;
- Provide autonomy to NCCU and not strain the NC State staff for expertise, limiting the pilot until funding was available; and
- Porting the VCL to IBM’s system z platform, running it on zLinux. Several companies have offered to support such an effort, but how to run Windows applications smoothly on the z/OS platform is not fully resolved.
It appears that the first approach is the most likely near-term solution because much of the cost of a mega-blade center would be spread across the entire University of North Carolina system, covering power, hardware, and staff.
Of considerable interest to many educators is the possibility of also bringing K12 organizations into the VCL.3 The application is ideal for technologically and financially limited schools serving lower-income students.6 NCCU is involved with two high schools in the Research Triangle Park area, one using the VCL, the other expecting to by fall 2010. These schools will be an excellent test case, further demonstrating the VCL’s ability to flatten the technology playing field.
Another compelling VCL development is the possibility of porting some functionality to a mainframe environment. Virtualization technology had an early home there, beginning 40 years ago with the need to replicate a development environment without having to add separate, prohibitively expensive machines. IBM’s zVM OS was an early answer to this demand. With the advent of sophisticated partitioning technologies in the 1980s, zVM became much less essential, and the technology was almost retired; x86-based virtualization then gave zVM new life. IBM claims its z10 processor (announced in February 2008) can lower the cost of energy by 85% compared to x86 processors doing the same work.4 While only the Linux/Unix-based applications are candidates for migration from the VCL to mainframes (due to instruction-set compatibility issues between zOS and Windows). Even if only the Linux/Unix VCL applications are run on the z10, it will be interesting to see if such impressive cost savings can be realized.
Conclusion
The NCCU VCL pilot is an extension of the VCL project begun at NC State and owes full attribution to the NC State team for its innovative work. But as users of the VCL, we aim to drive it to places where it might not go of its own accord. The VCL began at a public university; implicit in such work is the ethical obligation to allow the public to avail itself of its benefit, with the consent of its creators at NC State. Extensions of the VCL, including the NCCU pilot, are themselves innovations, because what is needed (once the science and engineering issues are addressed) is a replicable business model. The VCL has now been extended to NCCU, a relatively small public university, a significant accomplishment available to other organizations without large technology staffs.
VCL mainframe implications are significant. The VCL runs well on a distributed platform. All reports of performance and reliability in the current blade environment are positive. But virtualization has been part of the mainframe domain (such as IBM’s zVM) for decades. That it works is an understatement. To be able to have hundreds, even thousands, of virtual servers running on a mainframe with accompanying dramatic reduction in power demand is a development we are eager to see.
The VCL project is important to virtualization technology in education for four main reasons:
- Though it began in the College of Engineering at NC State, and NC State provides most of the technical direction, the project is developing an increasingly eclectic profile. Participants are able to apply innovation to the hardware and software infrastructure and still enjoy the benefits of being part of the VCL environment. For example, if a high school wants to use a homegrown virtualization solution (perhaps for instructional purposes) and didn’t use the VCL per se, accommodations could be made for it to use VCL management logic and networking, as long as its solution does not impede other users;
- For NCCU, development of expertise among internal staff and students is invaluable. We are learning to deploy our production infrastructure more efficiently, and our students are acquiring a valuable and marketable skill set involving virtualization;
- For the predominantly African-American community served by NCCU, the related technology transfer is especially welcome. As we work with high schools in our area, the community at large is involved directly in technological innovation at a much deeper level than it ever was before; and
- With the emergence of cloud computing,7 the VCL might also serve as a major cloud application, becoming yet another software service for the world at large while delivering services from commercial vendors.
The VCL’s greatest value is when an entire institution, across functional units and academic disciplines, uses it to seamlessly access computing resources.
Though commercial solutions may provide the same or similar results for the same or lower cost, they don’t (as far as we see) allow our extended community (particularly in North Carolina) to directly participate in the ongoing innovation. However, in many ways this participation is as vital to us as the benefit derived from the technology itself.
Acknowledgments
Our thanks to NC State, Duke University, International Business Machines, and MCNC in Research Triangle Park, NC.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment