Combining a Virtual Grid Testbed and elearning Courseware Kathryn Cassidy, Jason McCandless, Stephen Childs, John Walsh, Brian Coghlan, Declan Dagger Department of Computer Science, Trinity College Dublin Kathryn.Cassidy@cs.tcd.ie, mccandjm@cs.tcd.ie, Stephen.Childs@cs.tcd.ie, John.Walsh@cs.tcd.ie, coghlan@cs.tcd.ie, Declan.Dagger@cs.tcd.ie Abstract Training activities in realistic settings are important contributors to successful elearning. For grid courseware, however, training users on a live production infrastructure is not ideal and a dedicated teaching environment which closely replicates the live infrastructure is more desirable. We show how the priciples of virtualisation have been applied to develop a learning environment that realistically simulates the workings of a production EGEE Grid. We outline how our tools GridBuilder and TransDeploy quickly replicate grid sites with minimum effort. We also indicate how the Adaptive Personalised elearning Service (APeLS), suitably extended with grid security, can deliver adaptive courses to users with live exercises which they can perform in the virtual teaching environment. 1 Introduction Grid technologies are maturing and entering a production phase, but outside of the High Energy Physics (HEP) community there is still a dearth of knowledgeble users who can exploit the potential of Grids. To grow the grid user community will require significant investment in training and education. This need has been recognised by the grid community and many projects, such as EGEE II[8] and ICEAGE[10] contain a strong training component. elearning is well suited to grid training because of the distributed nature of the Grid and its users, and the asynchronous training demand. elearning allows learners to begin their training when and where they wish, while simultaneously reducing the overheads associated with face-to-face learning (organisation, catering, space, registration, etc.). Delivery of instruction is not sufficient, however. In order for training to be successful it should also provide opportunities for learner engagement with the course material, in particular, opportunities for learners to practice what they have learnt. Granting learners access to a production infrastructure is risky, and an isolated training infrastructure (t-infrastructure) is a more secure option.
We present the elgrid elearning t-infrastructure which aims to integrate elearning software and courses with a training infrastructure that closely simulates a production environment, the Grid-Ireland infrastructure. 2 Requirements We identified a number of requirements for our t-infrastructure: (a) It should have dedicated resources to guarantee fast response times as learners may need the results of one exercise before progressing to the next. (b) It should be isolated from the production Grid so that many users can be trained without compromising security. (c) It should simulate a production infrastructure as closely as possible in order to ensure that there is no additional learning curve for trained users migrating to a production infrastructure. (d) Ideally, it should be easily set up to simulate the local production infrastructure, rather than some fixed example infrastructure. (e) elearning tools should be integrated into the grid t-infrastructure in order to allow communication between the courseware and the tools used in practical exercises. It should be possible to launch these tools from within the elearning course and to capture their results for use in assessment and adaptivity. (f) The system should be easy to configure and maintain for systems adminstration staff, ideally utilising the same management tools which are already in use for production. It should also be easy for learners to use so as not to impose an additional learning curve or induce rejection by users. (g) The system should follow best-practice for elearning and use tried and tested elearning tools so that the teaching can benefit from recent advances in Learning theory and elearning technology. 3 Architecture The basic architecture of our integrated t-infrastructure solution is shown in Figure 1. A firewall server ensures that the t-infrastructure is isolated from the production Grid while providing limited connectivity where required. This machine also runs certain necessary services such as the TransDeploy tool (see Section 3.5) and an install server (Section 3.4). Additional network aliases are configured on this machine to allow the replica grid sites to connect to this machine as their default gateway, install server, etc. The replica sites are hosted as virtual machines on a number of physical servers. Grid services which are shared by all the replica sites are likewise hosted on virtual machines. The tools used in this solution are described in more detail below.
Fig. 1: The ELGrid t-infrastructure architecture 3.1 Virtualisation We wanted our t-infrastructure to mirror the local production infrastructure as closely as possible. The size of the Grid-Ireland infrastructure and the number of necessary services, however, means that physically replicating even part of the infrastructure would be a huge and costly undertaking. The use of virtualisation allows us to replicate a large number of grid nodes and servers, while significantly reducing hardware requirments. There are a number of virtualisation systems available for x86 architectures which could support creation of a large virtualised testbed using inexpensive off-the-shelf hardware. The system chosen for this project was Xen[12], not only because it is already used within Grid-Ireland for our testing and development infrastructure[3] and for our production infrastructure [2], but also because it has price/performance advantages over other virtualisation systems for the x86 platform. Tests conducted by Childs et al[2] and confirmed by Hardt and Berlich[9], found that Xen performs favourably compared to a reference Grid machine without Virtualisation, outperforming alternatives such as User Mode Linux, VMWare, etc. Our t-infrastructure uses eight Dell dual-processor dual-core machines, each with 8 Gigabytes of memory, running a Xen Linux Kernel. Each replica site consists of a minimum of four virtual machines: a User Interface (UI), a Compute Element (CE), a Storage Element (SE) and a Worker Node (WN). The local resource management system (LRMS) is PBS on the CE. Allowing approx 400 Megabytes of memory for the root VM (VM0) and guest VMs allows replication of up to four Grid-Ireland sites on each physical machine. This enables replication of the entire Irish grid infrastructure with very little hardware. 3.2 Network Configuration Each of the replica VMs in our elgrid t-infrastructure has a public IP address and network configuration that is identical to those used by that machine s
counterpart in the production Grid-Ireland infrastructure. Because of this it is necessary to completely firewall off the t-infrastructure network from the rest of the network. The elgrid firewall is a dual-homed machine with an internal network device connected to the elgrid t-infrastructure and an external device connected to the real production network. Iptables firewalling is configured to ensure that no traffic from the internal interface can accidentally be sent out onto the external network and thereby to the production network (and vice-versa). A DNS server installed on the firewall machine handles DNS for the physical elgrid machines (the Xen hosts) and queries the production Grid Ireland DNS servers for the IP addresses of grid nodes (the replica virtual machines). These addresses are then cached for subsequent use. The firewall machine has an additional network alias on its internal interface for the default gateway for each replica site. All intra-site traffic (from one machine in a particular replica site to another machine in the same site) arrives at the default gateway alias of the internal interface on the firewall machine. These packets are then routed back through the same alias on this interface. Thus the firewall routing ensures that internal packets intended for replica Grid- Ireland sites are directed to the internal network interface and not to the real production sites via the external interface. Some other services are hosted on the elgrid firewall machine rather than being replicated as VMs. The replica hosts, however, know only of the real IP addresses for these services. Network aliases are created on the elgrid firewall for the install servers for each site as these are required in order to perform the initial installation of a replica site. Once installed, NAT is used on the elgrid firewall to redirect packets directed at servers which do not exist in the elgrid network to the firewall machine where these services are hosted. The use of the real IP addresses means that we have an identical configuration to the production infrastructure. This is a tried and tested configuration and is also used for our testing and development infrastructure[3]. Using an identical setup means that we can actually use the same configuration files as those used to configure the production infrastructure, thus management and administration of our t-infrastructure can be done using the same fabric management system which we use in production, with changes to configuration files only having to be made and tested once. 3.3 The GridBuilder Tool The GridBuilder[1] tool was developed by the Computer Architecture and Grid Research Group in Trinity College Dublin. It provides an easy-to-use webbased user interface which allows the user to quickly configure and start new VMs which replicate live systems. An example of this interface is provided in Figure 2. Gridbuilder stores a library of filesystem images for standard node types, each as an independent LVM partition. Examples of these standard filesystem
Fig. 2: The GridBuilder tool allows fast replica VM creation. images include gridmon (test worker node (WN)), gridui (user interface (UI)), gridstore (storage element (SE)) and gridgate (site entry point (CE)). When a new virtual machine is created, GridBuilder creates a copy-on-write clone of the appropriate LVM partition. The copy-on-write feature of LVM allows clone volumes to be created which only contain changes to the base volume, thus saving disk-space. It also speeds up the cloning process. GridBuilder then mounts the new volume and modifies the configuration. The required configuration is downloaded from the fabric management system (in our case Quattor, but Yaim and LCFG are also supported). Once the filesystem volume is unmounted a Xen image is then available and ready to boot. GridBuilder then boots a Xen VM from this image and any final updates are performed by the fabric management system on the VM, again using copy-on-write. 3.4 Configuration and Management Any network with more than a few nodes should have a fabric management system to configure, update and install machines or the workload of system administration will quickly become unscalable. In grid systems this is particularly important as the sites involved can be particularly large. In Grid-Ireland we use the Quattor fabric management system [11]. All configuration is stored in each site s install server and autonomous nodes pull this configuration and update themselves. This autonomy makes the system scalable. The configuration is stored in templates, and preconfigureed templates for grid nodes are available from CERN. The hierarchical structure of quattor templates means that templates can be combined. For example, a general site template can be overridden with a machine-specific template. These templates are stored in a CVS repository on each Grid-Ireland site s install server. As previously mentioned the same configuration files are used for the pro-
duction grid and for and the t-infrastructure. These are accessed by the Quattor client via http and so the install server is simply a webserver which makes the Quattor templates available for download. In Grid-Ireland, all the site install servers host identical CVS repositories, so a t-infrastructure optimisation would be to have only one install server (e.g. on the firewall) and alias all the site install servers to it, and this is what we do. In order to make the Quattor profiles available via http on the elgrid firewall we use the TransDeploy tool described in section 3.5. Both the physical elgrid machines and the replica VMs are configured via Quattor. The physical machines require that a new Quattor site be configured and templates created for each machine. However, the configuration of the replica VMs does not require any work as it is possible to use the same configuration templates as those used to manage the production infrastructure. 3.5 Deployment To deploy configuration changes to Grid-Ireland the Quattor configuration templates are pushed out to the site install servers. To do this Grid-Ireland uses a deployment tool called TransDeploy [4], developed by the Computer Architecture and Grid Research Group in Trinity College Dublin. The TransDeploy tool aims to ensure consistency of sites and to minimise downtime due to upgrades. Upgrades are split into a variable-duration prepare phase and a short-duration upgrade phase, i.e. a two-phase commit, which is performed transactionally insofar as the entire upgrade is treated as one atomic operation which can either fully succeed or must be entirely rolled-back. The prepare phase checks out the Quattor templates from a central CVS repository, compiles and tests them and identifies most configuration errors. If the configuration is valid then the templates are copied to the site install servers using rsync over ssh. Only if this succeeds will TransDeploy progress to the upgrade phase where the new configuration is made live by changing a symbolic link in a directory under the site install server s webserver document root to point to the new profiles. There is one TransDeploy instance for the entire Grid-Ireland production network which copies templates out to the install servers in each site. A separate TransDeploy instance is configured for the elgrid t-infrastructure. This is installed on the t-infrastructure firewall machine and copies the templates to the elgrid site install servers, which are implemented as network aliases on the internal interface of the firewall machine. At present this gives rise to redundant deployments, but once network behaviour emulation is incorporated this will ensure realistic behaviour for student grid administrators. Alternatively one could set up separate install server VMs for each replica site. 3.6 APeLS and ACCT In collaboration with the Knowledge and Data Engineering Group (KDEG) at Trinity College Dublin, we are using advanced elearning tools for our courses
that incorporate recent developments in elearning technology such as adaptivity. The tools include the Adaptive Personalised elearning Service (APeLS)[5] and the Adaptive Course Construction Toolkit (ACCT)[7] developed by KDEG. APeLS is a web-services-based Adaptive Hypermedia System (AHS) which creates personalised courses at run time by adapting the content or the navigation based on the interaction of models such as Pedagogic Activity Sequence, Subject Area, Candidate Learning Resources, Learner Model, Context, etc. The system has been used in Trinity College Dublin for delivery of an undergraduate SQL course since 2000[6]. ACCT is a user-friendly tool for designing and developing personalised elearning experiences which can be delivered via APeLS. We wish to integrate the t-infrastructure with our courses to allow launching of practical exercises from within APeLS courses and to capture the results of grid jobs. In order to achieve this APeLS must be installed on a machine which is connected to the elgrid t-infrastructure. We will use the firewall machine for this purpose as it already runs a webserver which can be accessed from outside of the elgrid t-infrastructure and yet applications running on this machine will have access to the t-infrastructure. The webserver on which APeLS runs will be secured with Grid certificates so that only users posessing a valid certificate will be permitted to gain access to the courses. We will use GridSite software to handle the user authentication based on Grid certificates and will pass the user s distinguished name (DN) to APeLS as the user name, allowing single-sign-on. 4 Preliminary Results It is difficult to judge the success of the t-infrastructure without user evaluation, however, we believe that the requirements set out at the beginning of the project have largely been met. Table 1 indicates how the technologies used in the solution have helped to meet these requirements. 5 Conclusions We have shown that it is possible to create an isolated t-infrastructure which, through the use of virtualisation, can closely replicate a production EGEE Grid. By using the existing fabric management system, along with the tools Grid- Builder and TransDeploy, the replicated t-infrastructure can be implemented with minimal effort on the part of the systems administrators. Furthermore we have indicated how it is possible to use tried-and-tested elearning tools within a Grid context to allow interaction between the elearning tools and the t-infrastructure, in courses based on sound pedagogic principles. Two courses are already in development, the first is a basic Introduction to Grid course and the second is an advanced Relational Grid Monitoring Architecture (RGMA) course. We hope to evaluate the elgrid t-infrastructure early in 2007 when undergraduates at Trinity College Dublin will use these courses as part of a Virtualisation and Grid course.
Tab. 1: How the technologies used have met the requirements Requirement Technologies (a) Dedicated resources to guarantee QoS. (b) Isolate training testbed for security (c) Simulate a production infrastructure (d) Simulate the local production infrastructure (e) Integrate elearning and grid environment (f) Make easy to use and configure (g) Follow best-practice for elearning design Xen, Network Configuration, Quattor, TransDeploy, GridBuilder Xen, Network Configuration Xen, Network Configuration, Quattor, TransDeploy, GridBuilder Xen, Network Configuration, Quattor, TransDeploy, GridBuilder APeLS GridBuilder, TransDeploy, Quattor, APeLS ACCT and APeLS References 1. Childs, S., Coghlan, B., McCandless, J. (2006) GridBuilder: A tool for creating virtual Grid testbeds In 2nd IEEE Conference on escience and Grid computing, Amsterdam, December 2006. 2. Childs, S., Coghlan, B., O Callaghan, D., Quigley, G., Walsh, J. (2005) A singlecomputer Grid gateway using virtual machines AINA 05, Taiwan, March, 2005. 3. Childs, S., Coghlan, B., Walsh, J., O Callaghan, D., Quigley, G., Kenny, E. (2006) A Virtual TestGrid, or how to replicate a national Grid, Proc.ExpGrid workshop at HPDC2006, Paris, June, 2006. 4. Coghlan, B.A., Walsh, J., O.Callaghan, D. (2005) Grid-Ireland Deployment Architecture Proc.EGC 05, Amsterdam, February, 2005. 5. Conlan, O. (2004) The Multi-Model, Metadata driven approach to Personalised elearning Services, PhD Thesis. Trinity College Dublin. 6. Conlan, O., Wade, V. (2004) Evaluation of APeLS - An Adaptive elearning Service based on the Multi-model, Metadata-driven Approach, Third International Conference on Adaptive Hypermedia and Adaptive Web-Based Systems (AH2004) Proceedings, Eindhoven, The Netherlands, 2004. 7. Dagger, D. (2006) Personalised Elearning Development Environments, PhD Thesis. Trinity College Dublin. 8. Enabling Grids for E-SciencE EGEE http://www.eu-egee.org/ 9. Hardt, M., Berlich, R. (2005) Xen: Scientific Use Cases and Performance Comparisons, UKUUG Linux Technical Conference, Swansea UK, August 4-7, 2005. 10. International Collaboration to Extend and Advance Grid Education ICEAGE http://www.iceage-eu.org/ 11. Quattor http://quattor.web.cern.ch/quattor/ Accessed September 2006 12. Xen http://xen.sf.net/ Accessed September 2006