Virtual Environment

1. Virtual Environment to Test and Prototype Tier 3 Clusters the Problem The availability of data from the Large Hadron Collider emphasized the need for more resources for analysis and data retrieval at all the institutions involved with the experiments. Major experiments like ATLAS and CMS formalized another level in the hierarchy of their computing infrastructures, the Tier 3s. Tier 3s need tested and reliable solutions, because they are small and do not have local computing experts like larger centers, and Tier 3s come in a large variety of configurations to satisfy the need of the institutions that own and manage them. This adds complexity to the task of a solution provider like Open Science Grid. A laptop is used as a prototyping and testing cluster for Tier 3s via the use of a virtual environment. VMware ESX emulates different network topologies and runs several virtual machines on a single laptop. The possible components of a Tier 3 cluster have been studied and modularized to simplify and streamline the deployment. The virtual cluster made it possible to test different solutions and simplified the verification of the software and more importantly the testing of its instructions. Thanks to the use of virtual machines and machine templates it is possible to quickly bring up entire clusters to test different setups like the Xrootd distributed file system, configurations of the Condor queuing system and grid components. A portable laptop can be managed locally or remotely and provides a OSG Grid site that can receive jobs and transfer files gc1-se OSG-SE to transfer and manage files: “classic SE” with GridFTP server or BeStMan (over local FS or Xrootd). Xrootd redirector in some tests gc1-gums GUMS server to map the Grid users to the local accounts gc1-ui user node with OSG Client to test the client software, grid interactions and user interactions with the cluster gc-ext1 OSG-SE or Xrootd redirector (instead of gc1-se) for the configurations involving a dual homed server. gc-ext2 A second dual homed server used as CE or Web cache. VC5 VyattaCommunity5 soft router connecting the different networks, providing NAT, port forwarding and PPTP VPN access to the private network vSwitch1. gc1-ce OSG-CE to accept and manage Grid Jobs: Globus gatekeeper with jobmanager Condor and managed Fork. Condor headnode (collector+negotioator) gc1-wnX worker nodes or storage nodes (Xrootd data server) gc1-nfs NFSv4 server for home directories and shared disk space (OSG_APP, OSG_DATA, …) the Virtual Machines on the Laptop The laptop. HP EliteBook 6930p (FM897UT#ATA). Processor: Mobile Intel Core 2 Duo T9600/2.8 GHz: fast dual core 64 bits processor that supports Intel VT-x technology. RAM upgraded to 8GB (2x4GB DDR2 SDRAM 800MHx SO DIMM)Fast 320GB SATA-300 7200 rpm hard drive and a gigabit Ethernet port. VMware ESXi4. Thin hypervisor: it is more efficient than virtualization software running on top of an Operating System but lacks of a management interface. Must be used with the vSphere client or management software. “Unsupported” SSH access is possible. The cluster. The typical worker node consists of a virtual machine with 256MB of RAM and a minimal installation of SL 5.4 on a 10GB virtual drive. Server nodes have 512 MB RAM and additional virtual drives or network interfaces if needed . vSphere client with view of the virtual machines on the laptop with VMware ESX The flexibility of the virtual environment allows to reconfigure quickly the cluster in different topologies like the one above and below the Tests and the Documentation The cluster can be reconfigured quickly to test some OSG documentation or to debug new software, or to give a demonstration, or to troubleshoot a user problem. Condor LRM - Four nodes of the virtual cluster were used to test different setups of Condor: One node for the services matching the available resources with the jobs (collector and negotiator); two to run the jobs and verify the scheduling policies; and one to submit the jobs. Both an installation on a shared file system and the local RPM installation of Condor documented in the OSG Twiki were tested. This setup was actually used to test and provide useful feedback also to the Condor team to define the current Condor RPM distribution. Xrootd distributed storage - Xrootd requires one redirector, the frontend of the storage systems, installed on the SE node, and one of more data servers serving the actual disk space, installed on the worker nodes. Beside testing the Xrootd instructions, this test-bed was used to select and test the recommended configuration for USATLAS Tier 3s and to debug unusual setups like the one with a multi-homed redirector. Several Storage Element configurations based on BeStMan - The flexibility of the virtual cluster has been of great help in testing this Storage Element in a variety of configurations on top of Xrootd or a POSIX file system. Several pages of the OSG Twiki documentation, especially the Tier 3 Web, have been tested using the virtual cluster GC1 Corresponding author: Marco Mambelli (University of Chicago) marco@hep.uchicago.edu Other Authors: Rob Gardner (University of Chicago) Supported by: National Science Foundation, Grant 0621704 Department of Energy, DE-FC02-06ER41436 THE UNIVERSITY OF CHICAGO