ARCHITECTURE OF SEMI-VIRTUAL CAMPUS FOR EDUCATION IN DISTRIBUTED DATA NETWORK LABORATORY

Transcription

1 ARCHITECTURE OF SEMI-VIRTUAL CAMPUS FOR EDUCATION IN DISTRIBUTED DATA NETWORK LABORATORY Petr Grygárek et al. Department of Computer Science, Faculty of Electrical Engineering and Computer Science Technical University of Ostrava, Tř. 17. listopadu, Ostrava, Czech Republic Tel.: (+420) , Fax: (+420) Abstract. The article presents architecture of semivirtual campus technical infrastructure for Edinet project. Its aim is to integrate data network laboratories of multiple partners into single unified system accessible by students remotely via Internet. The architecture is defined to integrate various existing remotely accessible networking laboratories and education approaches. The intent was to reach maximum flexibility to support efficient sharing of lab equipment including a possibility to create temporary distributed lab topologies spanning multiple partners. Keywords: collaborative learning, distance education, distributed learning, interactive learning, network, infrastructure, virtual laboratory 1. INTRODUCTION To improve efficiency of practical training in the field of computer networking, it proved very useful to provide remote access to networking laboratories. Because of high cost of special laboratory equipment it also makes sense to join effort of multiple educational institutions to share equipment with other partners which allows individual partners to specialize of particular special technology and utilize lab equipment for other technologies owned by other partners. The result of that cooperation is a virtual campus which allows student to work with real network devices of any partner, so we call it semivirtual to emphasize the fact that students get real practical experience which cannot be reached using of any kind of device simulators. Because of advantages of participation in such semivirtual campus (SVC) environment, we joined the European Union project called Education in Distributed Data Network Laboratory (EdiNet) operated under EU Lifelong Learning Programme. Our responsibility in scope of Edinet project is the architecture design and implementation of semivirtual campus technical infrastructure. In the following article, we want to share our experience with definition of a such architecture. Our results seem to be general enough to suit rather diverse needs of individual partners and all potential usage patterns and pedagogical approaches which are planned to be tested in the implemented semivirtual campus. The first step of the architecture definition was the thorough investigation of existing partners' remote access solutions, which were rather diverse. Although almost all partners took one of the two possible approaches (i.e. VPN-based approach or solution with exposed terminal server), individual solutions varied considerably in the level of reservation system implementation and overall flexibility of the remote laboratory usage. The SVC architecture proposal was defined so that necessary changes of existing partner labs were minimized. It was necessary because of the fact that many partners currently use their labs in real student education and the process of migration to the common SVC has to be as easy as possible. On the other hand, we wanted to develop a consistent system with clear and well-defined architecture which may be easily extended in the future, so the pure encapsulation of existing solutions was not a wise option. We also needed to minimize cost of new required hardware and software licences so that free opensource technologies were chosen for SVC implementation. This approach also corresponds well with the academic nature of the whole project. During design phase of the overall SVC architecture we took into account many years of our experience with development of remote access lab solutions [1],[2], distributed virtual laboratory architectures [4] and real operation of both nondistributed [3] and distributed [5] semi-virtual education environment. Because the time to implement SVC and prepare the whole distributed environment for piloting was only a couple of months, we decided to defer utilization of advanced features fieldproven in our Distributed Virtlab [5] to the later stages. Our experience with piloting Distributed Virtlab revealed that handling of such features as dynamic creation of distributed virtual topologies with dynamic search of lab devices suitable for particular reservation is rather demanding to organize even in scope of Northern Moravia Distributed Virtlab installation. It would be very risky to try to implement it in such short time in a large-extent SVC covering multiple very distant universities. On the other hand, our goal was to develop an architecture that will be flexible and adaptable enough to allow mutual sharing of partners' lab equipment as effectively as possible. Our politics is that all partners will have equal access to resources of other partners, including both lab devices and 1

2 lab manuals or other educational documents. There was also a requirement to support statically preconfigured distributed virtual topologies spanning multiple partner's labs. The main parts of the architecture that had to be designed were common remote access system, reservation system which reasonably organizes tasks and lab pods and common authentication and authorization (AAA) infrastructure. The general philosophy of all of the mentioned parts will be described in the following sections. 2. COMPONENTS OF THE ARCHITECTURE The SVC distributed architecture is composed of Common Portal, Local AAA Servers and VPN Gateways to Lab Management Networks of individual partners labs, as shown of figure 1. Figure 1: Overall Architecture of the SVC The Common Portal acts as the main SVC WWW portal. It hosts databases of tasks and lab devices, reservation database and database of user groups (see later). Local AAA servers authenticate users of respective partner and maintain local user databases. VPN Gateways provide remote access to Lab Management Network of individual partners labs, as will be described in the next section. 3. THE INTEGRATED REMOTE ACCESS SOLUTION The remote access solution is designated with primary intent to support all kinds of management interfaces of lab network devices used up to now by partners or considered in the future. Currently, we need access to lab networking devices' RS232 consoles and Telnet/SSH/Remote Desktop access to manage lab PCs. In the future, it is expected that a lot of networking devices will be manageable primarily using Web interface. There is also lot of manufacturers who implement their own L2/L3 management protocol and proprietary (commonly Windows-based) management applications. We plan to manage such devices from lab PCs with appropriately configured Web browser and all necessary proprietary management applications preinstalled. To integrate access to RS232 consoles with both text-based and GUI-based access to lab PCs into one technical solution, we have chosen to implement an VPN-based access for remote management of lab equipment (see Figure 2). Lab PCs will have one NIC card connected to the Lab Network and another one connected to so called Lab Management Network. Lab Network contains lab devices used by students to solve tasks, while Lab Management Network is used to access management interfaces of lab PCs and Terminal Servers, which makes RS232 consoles of lab networking devices available to the remote user using reverse Telnet. Various kinds of terminal servers may be utilized (either commercial or partner's own hardware prototype). Figure 2: Basic remote access architecture 2

3 To allow integration of remote desktop clients into remote user s GUI, it is desirable do unify methods of lab PC access over all partners. At the time of writing of this article, TightVNC [8] was chosen as the most suitable open, bandwidth-efficient and cross-platform solution. In the real lab implementations we do not really expect wide usage of "real" lab PCs. To simplify and automatize lab management, reduce cost, power consumption and required space, we expect that partners will want to use some sort of virtualization technology to simulate multiple lab PCs using single server. It will also simplify resetting of PC configurations/filesystems to the known state at the beginning of every reserved timeslot. As can be seen from Figure 2, remote user's PC is used only for management of lab equipment, including lab PCs. It is never incorporated directly to the Lab Network. To manage lab network devices by mean other than RS232 console, the user first accesses some lab PC and then uses software preinstalled on that PC to manage lab network devices. Because the configuration of lab PCs' operating system, WWW browser and other software is completely known to and under control of local lab administrator, we do not have to solve problems with poorly installed or malicious software on remote user's PC as we would have in case if we would have been used remote user's PC as a part of the Lab Network. Every lab is equipped with Linux-based VPN gateway connected both to the local Lab Management Network and to the Internet. It allows remote (VPN) access to the Lab Management Network. After successful authentication, 3.1 Lab Interconnection In some situations, partners may want to interconnect lab devices from multiple labs into distributed virtual topology and provide the resulting (even preconfigured) lab pod for remote access for a limited period of time. The technical solution how it will be implemented is depicted on Figure 3. Both Lab Networks and Lab Management Networks of partners' labs involved in distributed virtual topology have to be virtually connected together. For location-independent access to management interfaces of lab devices spread across labs of multiple partners, Lab Management Networks of all partners will be connected together with VPN tunnels (green dashed line on Figure 3). In the first piloting environment we plan to implement full mesh of tunnels among partners and utilize static routing. If more partners join our environment later, topology may be optimized and suitable dynamic routing protocol implemented. By interconnection of Lab Management Networks, the distributed nature of the virtual topology becomes completely transparent to the user. Controls of Web pages providing access to lab devices' management interfaces may just operate with IP addresses of management interfaces of lab PCs and terminal serves regardless of in which partner's laboratory they are actually located. Tunnels between Lab Networks of partners participating in particular distributed virtual topology (yellow dashed line(s) on Figure 3) will be preconfigured manually when needed. authorization and creation of VPN tunnel, remote user's PC becomes virtually part of respective Lab Management Network. An access list (ACL) will be dynamically applied on the VPN gateway to allow remote user to access only management interfaces of those lab devices which the user previously reserved for a current timeslot. The access is authenticated using one-time passwords generated by Common Portal. Those passwords are passed to remote clients which launch OpenVPN [9] client transparently via HTTPS. Details can be found at [6]. Figure 3: Interconnection of multiple partner's labs We plan to use OpenVPN [9] SSL VPN because we need to be able to create multiple parallel virtual links between a pair of Topology VPN gateways in many distributed virtual topologies. SSL VPN allows to differentiate them using TCP/UDP ports. To ensure OSI layer 3 protocol independence and to allow layer 2 control protocols to pass through virtual links, virtual topology tunnels will be implemented as Layer 2 tunnels. More detailed example of implementing distributed virtual topology in the described way may be found in [8]. 3

4 4. RESERVATION SYSTEM Our general goal during design of the reservation system was to develop a system which allows to share lab equipment in dynamically changing environment and with reasonable level of flexibility. To optimize usage of the whole SVC and thus gain maximum pedagogical effect, we stated the following requirements for the organization of the SVC: There must be a possibility to offer lab pods to solve tasks which require various network topologies. For some tasks, lab devices have to be preconfigured as required for that particular task. There must be a method to offer multiple alternative lab pods suitable to solve particular task in parallel (either by the same or by multiple partners' labs). It is ineffective to dedicate every lab pod for solution of only single fixed task. Lab admins will want to change lab pod topologies over time. Our reservation system is based on the global system noticeboard. Lab administrators advertise lab pods with various topologies and device preconfiguations as available for some time period on the global noticeboard maintained at Common Portal. The description of every task specifies requirements of lab pod on which it can be solved. These requirements include specification of lab devices which may be utilized, device interconnection topology and eventually required preconfiguration of individual devices. When student selects a task to reserve, Common Portal offers him/her those lab pods which can be used to solve required task and times when they are available. The student then reserve a timeslot on particular lab pod. There are no fixed timeslots, students may reserve any timeslot which fits into period during which particular preconfigured lab pod is available, according to the advertisement on the Noticeboard. Using that paradigm, we were able to reach complete decoupling of tasks from preconfigured lab pods and increase flexibility of lab pods usage considerably. Every task just specifies (using so called Preconfiguration Description) requirements for the lab pod suitable to solve the task. At the same time, lab administrators advertise their Preconfiguation Implementations (i.e. lab pods preconfigured according to some Preconfiguration Description) on the global noticeboard. It allows various alternative tasks (with the same topology and preconfiguration requirements) to be solved on the same lab pod. The whole philosophy of is depicted at Figure 4. With regard to various and potentially very different planned usages of the SVC (individual remote work, teacher-controlled work of student's group from the classroom and others), we decided to take group-based reservation approach. It means that timeslots are reserved for groups of users, not for users as individuals. Figure 4: Reservation system philosophy User may create user groups by themselves by listing other users, potentially from multiple partner sites. The creator of the group becomes its owner and may modify or delete it. Group owner may make reservation for his group and all members of the group may equally access the reserved task during the reserved timeslot. Teacher may reserve additional time for checking of students configurations after the end of the timeslot. Every user may also reserve timeslot exclusively for himself/herself, because separate group is automatically created for every single user. Individual remote work is thus handled as a special case of more general group-based reservation paradigm. Reservations are maintained in Reservation Database on the Common Portal. 5. AAA INFRASTRUCTURE To simplify user administration process, we decided to avoid any central authority which manages all user accounts. Instead of that, every partner maintains it's own user database which is accessible to the rest of SVC via Local AAA Server. Using that concept, every partner is responsible for management of his own user accounts. The another advantage is that partners may easily integrate Edinet user databases with existing local user databases and authentication mechanisms, like institution's LDAP or RADIUS servers. Lab admins may also easily perform offline imports of users accounts exported from institutional information systems directly to the Edinet local user database by themselves. Although we assessed usage of PKI and user certificates first, we finally decided to use username/password 4

5 approach to authenticate users to eliminate overhead of handling certificates on both user and SVC side. Working with user certificates would be very difficult on shared classroom computers because of limited students' operating system privileges and potential risk of stealing of student's certificate. Another advantage is that users may even use the same passwords as they use in their home institution for other purposes. Users are assigned names in the format, so usernames are scoped. Users are authenticated in their "home" institutions (implied by realm part of their username) by Local AAA Servers. Together with result of the authentication (true/false), the local AAA server will also return a set of user's attributes (name-value pairs) from local user database. As soon as the user is authenticated, it is allowed to log in to the Common Portal. His/her authorization to perform particular operations is based on the user's roles stored in user database and provided as user attributes by local AAA servers. Shibboleth [10] was chosen as global AAA middleware. 6. SUPPORTING LAB MAINTENANCE SYSTEMS To allow SVC to be operated without constant administrators' interaction, it is necessary to be able to return configurations of lab devices into original preconfigurations before each reserved timeslot automatically. Because of the diversity of utilized lab devices, their configuration interfaces and ways of resetting them to factory defaults, it is not possible to develop a system which will solve this task in genereal. For that reason, we decided to define a SVC component named Configuration Clearing Server, which will be implemented by each partner by himself and will provide unified software interface to the rest of SVC to request reset of individual local lab devices. The real implementation of the cleaning method is left to local administrators. Currently, we expect usage of various power switches to simply power networking device off and on and a system of Shell scripts to reload instances of simulated PCs. We foresee that this mechansm will have to be accompanied by another security measures, such as disallowing users to store configurations into lab devices FLASH, as we do in Virtlab [2]. Power switch may also be optionally made available to students who solve particular task. From students' point of view, switching power of individual lab devices is accomplished using controls of WWW page which makes management interfaces of individual lab devices available to him/her. Since we need to limit user to control power of only those devices that are reserved by him/her during the current timeslot and handle power switches of all manufacturers uniformly, we created a software component called Power Switch Controller which acts as a proxy between user and any kind of real power switch. 7. CONCLUSIONS The SVC architecture presented in the article is now being implemented by Edinet SVC development team of VSB-TU Ostrava. It will be ready during summer 2008 and after period of internal testing and adaptation of partners' labs it will be released for piloting in real distributed teaching environment starting at October The outcomes of the piloting phase will be published. 8. REFERENCES [1] Grygárek, P., Seidl, D., Němec P.: Virtual Network Laboratory for CNAP. Annual Conference of Cisco Networking Academy Program, Brno Available at [April 2007]. [In Czech] [2] Grygárek, P., Seidl, D., Němec, P.: Enabling Access to Equipment of Computer Network Laboratory for Practical Trainging via the Internet. Proceedings of Technologies for E-Learning conference, FEL ČVUT Praha, 2005, ISBN , pp [In Czech] [3] Grygárek, P., Practical Experience with Implementiation of Virtual Computer Network Laboratory and Proposed Ways of its Further Development. Proceedings of Technologies for E-Learning conference, FEL ČVUT Praha, 2006, ISBN , pp [In Czech] [4] Grygárek, P., Milata, M., Vavříček, J.: The Fully Distributed Architecture of Virtual Network Laboratory. Proceedings of ICETA, Stara Lesna, High Tatras, Slovakia, 2007, ISBN [5] Grygárek,P., Milata, M.: Piloting Environment of Distributed Virtual Networking Laboratory. Proceedings of Virtual University, Bratislava, Slovakia, 2007, ISBN , pp [6] Edinet SVC Technical Infrastructure Architecture Design/Remote Access and Lab Interconnection [online], 2005, [cite ], Available at WWW: < Lab_Interconnection>. [7] Edinet Lab Interconnection Implementation Example [online], 2008, [cite ], Available at WWW: < Lab_Interconnection#Lab_Interconnection_Implementati on_example>. [8] TightVNC: VNC-Based Free Remote Control Solution [online], 2007, [cite ], Available at WWW: < [9] OpenVPN - The Open Source VPN [online], 2008, [cite ], Available at WWW: < [10] Shibboleth Project - Internet2 Middleware [online], 2008, [cite ], Available at WWW: < 5

6 THE AUTHOR(S) Petr Grygárek (Ph.D, Msc.) is a professorassistant at Department of Computer Science at VŠB-TU Ostrava. His professional interest is focused on computer networking, distributed systems and computer hardware. He has a couple of years of experience with development of virtual networking laboratory architectures and is a main responsible for semivirtual campus design and its implementation in scope of Edinet project. He is also a coordinator and instructor (CCNP,NS,CCNA) of Regional Cisco Networking Academy at VSB-TU Ostrava. The ideas presented in the article were developed jointly by Edinet WP3 SVC Development Team under supervision of Petr Grygárek. Persons who contributed most to the architecture definition were Ivan Doležal, Jiří Grygárek, Adam Janošek, Tomáš Kučera, Marek Malysz and Martin Milata (in alphabetical order). All of them are empleyees or students of VŠB-TU Ostrava. ACKNOWLEDGEMENT This work presented here is supported by EU Lifelong Learning Programme project E-learning in Distributed Data Network Laboratory (EdiNet). 6