MGT 329 - DBMS Overview - University of New Mexico

Virtual Computing Laboratories
Past, Present, and Future
Stephen D. Burd
Associate Professor
Provost’s Academic Technology Liaison
[email protected]
Last Revised: 7/17/2015 8:22 AM
Others that have and/or continue to work with me on
VLAB-related issues
 Alex Seazzu – Faculty member and ASM IT services
 Greg Gaillard – Manager of infrastructure and services –
including the ASM VLAB
 Josh Saiz – Application developer and database manager,
adjunct faculty member, and VLAB user in multiple courses
 Eugene Rooney – Application developer, VLAB web portal
developer, and adjunct faculty member
 Kara Nance – Faculty member and VLAB developer/user at
the University of Alaska Fairbanks
 Brian Hay – VLAB developer and manager at the University
of Alaska Fairbanks
 Ronald Dodge – Faculty member and VLAB developer/user
at the United States Military Academy
 Simulating one type of computing resource with another, for example
Virtual memory - using disk as a RAM extender
Hardware abstraction layer - emulating an Intel CPU and chipset with software executing on
 Technique for making the sum of allocated computing resources appear greater
than actual physical resources
Virtual computing environment (VCE)
 Software that enables simulating one “complete” computing environment
 Examples: VMware Workstation or ESX, Microsoft Hyper-V, Apple Parallels, Xen
 Combines earlier “single resource type” virtualization approaches into an
integrated whole
 Today, the term virtualization is synonymous with the use of VCEs
Virtual machine (VM)
 A single simulated computing hardware environment with network
connections/services and installed system and application software (e.g., a
virtualized workstation or server)
 Multiple VMs operating on a virtual network with or without network services
(e.g., DHCP) and connected to or isolated from other networks
Resurgence of Virtualization
VCEs were widespread in the 1960s but faded by the early 1980s
 IBM 370 and 3090 systems used virtualization to share a single
mainframe between batch and online operating systems
 IBM AS/400 operating in System 36 emulation mode was one of the last
commercial implementations in that era
VCEs made a comeback in the late 1990s – Why?
Reduced cost disparity among desktops, minicomputers, and “big iron”
CPU cycles in abundance
Fast networks and consolidated storage
Reduced management complexity and total cost of ownership (TCE)
Usage scenarios:
Software testing (single machine)
Server consolidation
Desktop virtualization
Complex test environments containing multiple VMs on an isolated
virtual network
What is a VLAB?
VLAB = Virtual computing laboratory
The virtual equivalent of a physical computing
laboratory in an educational setting
 Users access hardware and software resources without
being “in the same room” as the physical resources
 Shared multiuser resources (e.g., server clusters)
emulate single-user resources (e.g., desktop
 Resources may be general-purpose or customized to
specific educational needs
 Resources are updated and reconfigured to match
changing needs
Sample Educational VLABs
George Mason
Apache VCL, general purpose computing laboratory,
similar labs implemented at other Virginia state
Georgia State
Apache VCL, primarily supports students using SPSS
and similar software
Citrix Xen with significant extensions, supports advanced
research into distributed applications
SUNY - Buffalo
Citrix XenApp, general purpose computing lab, also
provides access to common data storage
University of
Alaska Fairbanks
VMware ESX and Lab Manager, provides specialized labs
for information assurance courses.
University of
Citrix XenApp, primarily supports engineering students
University of
New Mexico
VMware ESX and Lab Manager, provides a generalpurpose computing laboratory and specialized labs for
information systems and information assurance
University of
North Carolina
Apache VCL, general purpose computing laboratory,
similar labs used at other NC state universities
University of
West England
Citrix XenApp, general purpose computing lab, also
provides access to a common data storage
Common VLAB Usage Scenarios
One or more applications (e.g., SPSS or Microsoft General-purpose
Office) hosted on server with presentation layer computing and license
executing on user device
Stateless desktop
Complete VM with operating system and
applications hosted on server with remote console
on user device, VM initialized to default state each
time it is used
Complete VM with operating system and
applications hosted on server with remote console
on user device, per user VM state is stored between
Multiple VMs (e.g., servers and clients) interacting
within a private isolated network (usually with state
Stateful desktop
Multiple VMs with
virtual network
General- and specialpurpose computing
Longer-term projects,
configuration exercises
Advanced computerrelated courses and
Educational VLAB Benefits
The Sales Pitch
Support learning at a distance
Reduced hardware and space costs
Efficient use of lab, site, and academic licenses
Minimal investment required of students
Simpler management (of some things)
Support for complex hardware/software
Specialized configurations per course or assignment
Multi-machine configurations with customized networks
Fast/simple setup and tear-down
A protected sandbox for “dangerous games”
UNM VLAB Implementations - Past
VLAB version 1 (2005-2008)
 Rack of ordinary workstations
connected to a SAN (see image on
 Custom-developed Web portal +
remote desktop protocol (RDP)
 42 users – one per computer
VLAB version 2 (2008-2010)
 4x Dell 2950s (32 CPU cores, 128
 2 TB storage array
 VMware ESX v3 + vCenter Lab
Manager v3
 Ordinary web server for portal
 Client console interface via ActiveX
browser plug-in
 Up to 100 users and scalable to
UNM VLAB Implementation – Present
VLAB version 3 (2010-2013)
 3x Dell R910s (32 CPU cores,
512 GB RAM each node)
 6 TB storage array
 VMware
ESX v4
vCenter Lab Manager
 Same web server and ActiveX
console interface
 Up to 400 users?
Version 3a (early 2013)
 Migrate ESX to ESX 5.0?
 Add a few more network
VM-Based VLAB Architectural Overview
Quick VLAB Demo
VLAB Challenges – The Gotchas
Acquiring, configuring, and supporting the VCE
and its underlying physical resources
Limited I/O efficiency
Clunky user interfaces – portal and VM console
More complex management (of some things)
Student and faculty training and support
Current Network Issues
Acceptable performance requires
 High-bandwidth and low-latency Internet connections at
both ends – particularly problematic at the user end
 Avoid I/O-intensive applications and features (e.g.,
complex desktop backgrounds, transparency, and
motion-video) to minimize bandwidth requirements
 Need high-performance connections among compute,
storage, and network resources
Current User Interface Issues
VMware Lab Manager is misnamed!
 Not really designed for an educational computing lab
Better suited to “professional” administration of virtual servers
 All the shortcomings of a Web-based application, e.g.,
Click, wait for refresh, click, wait for refresh, ... repeat ad
 Lacks many standard desktop capabilities such as drag/drop,
limited support for other such as cut/paste
 Non-intuitive interface and terminology for end-users
(e.g., workspace, template, configuration, clone, deploy,
and undeploy)
 “Atomic” actions from the student or faculty perspective
require multiple steps with many “traps for the unwary”
Browser Support
Limited browser support
 Internet Explorer with an ActiveX control works best
 Firefox also works
Customized browser and firewall configuration
Enable/accept ActiveX download
Disable Internet Explorer protected mode
Add lab manger URL to trusted sites list
Open 90x ports
Library Management
Faculty and/or technical staff typically manage a library of
VMs and configurations:
 Standard VM provided to all users for general-purpose needs
 Many courses use a single VM with all needed tools (e.g., Office +
Visio + Visual Studio for a database course)
 Some courses use multiple VMs alone or in a configuration
Library management issues:
 Creating VMs and multi-VM configurations is complex and timeconsuming
 Complex classes (e.g., information assurance) may have dozens
of VMs and multi-VM configurations
 No tag, index, or search capabilities (so, is it really a library?)
 Sharing VMs and configurations across classes and faculty is
cumbersome – OUs are hierarchically related with no inheritance
User Management
User management issues:
 Large classes and general-purpose lab access require
managing hundreds to thousands of user accounts
 Lab manager can be configured to use “internal” accounts –
best avoided!
 User account import from LDAP or Active Directory is
straightforward though not for non-technical faculty and staff
Doesn’t use LDAP or Active Directory as a central authentication
 Implementing access controls requires management of
groups, permissions, roles, and resource pools - beyond the
skill of non-technical faculty
Accounts and groups must be defined and redefined from semester
to semester
Resource Management and Overall VLAB
RAM and disk are usually the most limited server resources
 VMs must economize on both or overall VLAB performance suffers
 Economization can be complex and may require usability or suitability-to-purpose
compromises (e.g., older OS version or disabled features in newer OSs)
VM and template management
 VM templates can be created and cloned to a library or workspace
 Cloning creates long dependency chains and a trail of linked disk image and delta files that
compromise performance (due to more complex disk I/O)
 Shortening dependency chains
Improves VM and overall VLAB run-time performance
Requires lots of disk space for “full” clones
Increases administrative effort
 In an Active Directory environment clones can’t be “on domain” unless their GUIDs are
modified – which may break preinstalled software and services
VM existence and deployment duration
 “Throw-away” VMs are best since they consume no resources when idle
But, they must be cloned from a library or template before each use – a delay
 Many educational activities require longer-lived VMs and configurations that consume disk
resources even when not deployed
 Need to balance more immediate access but greater resource requirements of long-lived
always-deployed VMs against the lower resource requirements but delayed access implied
by cloning and deploying – available resources vs. user patience
Training and Support Requirements
There are two significant resource requirement
increases when using a VLAB
 User support for faculty and staff
Student and faculty training to navigate Lab Manager and deal
with browser configuration issues – significant even for
“technically-savvy” users
 Additional training for faculty to self-manage libraries and
 Help desk support
 Technical staff
Acquire, configure, and manage back-end resources
 Acquire, configure, customize, and manage the front-end
 Configure and manage “general-purpose” VMs
 Perform class-related tasks that faculty are unwilling or unable
to perform
UNM VLAB Implementation - Future
Primary drivers for change
VMware Lab Manager reaches end of life in June 2013
Current hardware architecture has reached limits
Want to explore cloud-compatible approaches
Want greater access from non-Windows devices
Want an easier-to-use interface for students and faculty
Dell will supply new hardware for VLAB experimentation
 Blade architecture with a 40 Gbps backplane
 Fractional provisioning of CPU, storage, and network resources
 We’ll partition it into at least two pieces to experiment with different VLAB architectural
VLAB experimental version 4a
 vCloud Director 1.5
 ESXi 5.0
 VMware View?
VLAB experimental version 4b
 Windows Server 2012
 Hyper-V and Windows desktop virtualization services
 Library, configuration manager, and portal – to be developed
Market and Technology Trends
Migrating to the cloud
 Migrate what, precisely?
 Migrate using which supporting technologies/products?
 Private cloud, public cloud, or both?
End-user devices
 Fixed workstations
 Mobile workstations (keyboard, touchpad and/or
mouse, and “large” screen)
 Tablets (no/optional keyboard, touch screen, and
“midsized” screen
 Handheld (e.g., smart phone)
Market and Technology Trends - Continued
How to access virtual software, data, and services
on end-user devices
 As in current VLAB architecture – complete VM
executing on a server with a remote console
 Local execution of VMs (e.g., Windows 8 with HyperV
or Parallels/BootCamp on a Mac, VM downloaded or
distributed on a flash drive)
 Application streaming (e.g., Citrix, Microsoft App-V,
VMware ThinApp)
 Web applications (e.g., Office 365 and GoogleDocs)
 Cloud storage (e.g., SkyDrive)
Market/Technology Trends - Observations
Virtualization and VLABs are here to stay for the foreseeable future
 Virtualization support hardware is wired into CPUs
 Virtualization is a standard feature of latest client OSs and will likely migrate to
“lower” platforms like tablets and smart phones
 Distance education is growing
 Users expect anywhere/anytime access to every education resource
Back-end tools and infrastructure for application and desktop
virtualization deployment are well-developed
Nearly mature technology
Available from multiple vendors
Still some variation in support for host hardware and OS environment
Rapidly migrating into the cloud
Application virtualization and software as a service are also welldeveloped, though there’s room for improvement and standardization
Mixed environments that deliver resources via a combination of methods
are feasible (e.g., Office via SAS, Adobe Creative Suite via app
streaming, and developer toolkits encapsulated within complete VMs)
 Using, administering, and supporting them may be overload for both users and
technical staff
More Observations
Cloud-based VLABs (VLABs as a service) are a natural
progression forward
 Management and security issues will become more important
than technology and accessibility issues
 App-streaming and stateless-desktops will probably be first,
followed later by stateful desktops and multiple-VM configurations
 Streamed apps and virtual desktops will need to integrate
seamlessly with cloud storage
Lab administrators will have to determine which
apps/desktops/services can be supported on which clients
 Some software and services will easily move from desktop to
laptop to tablet to phone (e.g., many office apps)
 Some software and services will be limited to devices with
sufficient screen size and I/O flexibility (e.g., users can’t feasibly
interact with current programming toolkits via a tablet or phone)
Current VM-Based VLAB Infrastructure
VMware ESX + vCloud + View
Industrial strength product with a long track record
Strong support for Windows and UNIX VMs and clients
Apple client support is a recent addition
Portal environment?? Unclear what is Lab Manager successor – possibly third-party
solutions (e.g., Liquidware ProfileUnity FlexApp)
 Strong support for virtual networks and multiple-VM configurations
Windows Server 2008/2012Microsoft Hyper-V
Hyper-V bundled with server OS and embedded in Windows 8
Strong support for Microsoft clients/servers and UNIX servers
Adequate support for UNIX and Apple clients via RDP
Portal environment can be provided through IIS and bundled desktop virtualization tools –
unclear how well they fit an educational VLAB environment
 Support for virtual networks and multiple-VM configurations?
Apache Virtual Computing Lab
Linux/Xen virtualization and VM deployment – Open source
Strong support for Linux and Windows VMs
Strong support for UNIX, Windows, and Mac clients via RDP
Apache web server and tool-kit for portal development – some templates provided through
 Weak support for virtual networks and multiple-VM configurations
Sample Cloud-Based VLAB Solutions
IBM Cloud9
 Xen-based desktop virtualization
 Relatively complete solution
Dell Virtual Labs
 Suite of products/services targeted to educational uses
 App streaming products/services use Citrix XenApp or VMware View
infrastructure with thin clients
 Integration of Dell hardware and setup support services with third-party
 Open-source Xen-based VM deployment to third party cloud providers
 Targeted to scientific and high-performance applications
 Xen-based VM deployment to local and remote server clusters (of
member institutions) across configurable/experimental I2/LR connections
 Targeted to research applications for next-generation network and
distributed software architectures
VLABs do deliver on their benefits, but not without
significant costs and some limitations
Current VLAB technology can’t deliver the same
experience to all users all of the time as sitting in front
of a directly-connected console
There are multiple implementation alternatives, but
nothing yet comprises and “out of the box” solution for
local installation
IBM Cloud9 is the best-developed cloud-based VLAB
Successful VLAB implementations require lots of
training, user support, and technical staff resources

similar documents