Changes between Initial Version and Version 1 of InstrumentationTools-Nov2011-status


Ignore:
Timestamp:
04/06/11 10:36:45 (13 years ago)
Author:
Vic Thomas
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • InstrumentationTools-Nov2011-status

    v1 v1  
     1[[PageOutline]]
     2
     3= INSTOOLS Project Status Report =
     4
     5Period: 6/30/10 - 11/15/10
     6
     7== I. Major accomplishments ==
     8
     9The following highlights our accomplishments during the last reporting period.
     10
     11=== A. Milestones achieved ===
     12
     13We continued to make progress toward our milestones.  Some of our
     14accomplishments include:
     15
     16  * continuing to support operation of the Kentucky ProtoGENI aggregate, enabling basic experimentation through the ProtoGENI clearinghouse.
     17 
     18  * updating the instrumentation software to support virtual nodes and provide a VNC interface to experiment nodes.
     19     
     20=== B. Deliverables made ===
     21
     22  * We contributed the latest version of our code to the ProtoGENI GIT repository.
     23
     24== II. Description of work performed during last quarter ==
     25
     26The following provides a description of our activities and results
     27during the last reporting period.
     28
     29=== A. Activities and findings ===
     30
     31During this period of time we made significant progress on several fronts.
     32We enhanced our software to support instrumentation of ''virtual nodes''
     33and improved  the web interface to provide X window access to experimental
     34nodes through a ''VNC-based interface''.
     35
     36As more experiments start to use the ProtoGENI facilities, making efficient
     37use of the resources has become one of our priorities.   To that end,
     38we worked with the Utah group to add support for ''virtual nodes'' based
     39on OpenVZ so that each physical PC can be used as multiple experimental
     40nodes.  Adding support for virtual nodes turned out to be fraught with
     41problems, and so we had to go through several rounds of bug fixes and
     42upgrades to get the latest development version of the code working.  In
     43addition we had to manually fix the OPENVZ image for the shared nodes because
     44the change had not been pushed out to the image running at Utah.
     45
     46Unlike BSD jails, we found that the OpenVZ image supports the abilty to run
     47independent SNMP daemons on each OpenVZ node (i.e., one SNMP daemon per VM).
     48This feature allows us to perform per-sliver monitoring without the need to
     49write new monitoring software to understand the OpenVZ virtual interfaces.
     50
     51To conserve public IP address space, the ProtoGENI implementation of virtual
     52nodes does not give public IP addresses to virtual nodes.   While the IP
     53addresses assigned to a virtual node can be used within the experimental
     54network created by the user (i.e., the slice), accessing the node from the
     55normal Internet is a problem.  To address this problem, the ProtoGENI team
     56added the ability to reach an ssh server via port forwarding to the OpenVZ VM
     57nodes.  This meant we had to modify our code to extract the ``services''
     58information from the manifest and then use the login information to access
     59the virtual nodes.  In particular, our INSTOOLS software queries the manifest
     60for the sshd port and hostname, and uses that information to login
     61into the VMs. We have to modify all ssh calls being made in both the client
     62side and server side code to work using port forwarding.
     63
     64We also found that the Measurement Controller (MC) could be virtualized. We
     65applied the same technique that we used on the experimental nodes in order to
     66gain ssh access to the MC.   However, we encountered the same problem of
     67accessing the web server on the MC, because port forwarding is only setup for
     68ssh access, not for web access.  To address this we currently require that the
     69user set up their own ssh tunneling, but we are talking with Utah about ways
     70to automate this in the future.  As a result of this limitation, we currently
     71prefer non-shared nodes for the MC because users can easily access the web
     72services there without the need to tunnel.
     73
     74We gave a hands-on tutorial as part of the ProtoGENI tutorial at GEC9.  The
     75hands-on tutorial allowed experimenters to create ProtoGENI slices and then
     76instrumentize their slice using the INSTOOLS software.   To ensure we had
     77enough resources available for the slices of all the attendees, we utilized
     78the virtual node support, allocating virtual nodes for the users'
     79topologies.   The experience pointed out a few areas that we could make
     80better, but overall most attendees were able to instrumentize their slice and
     81monitor its behavior.  Incidently, after the GEC9 conference we have noticed
     82that some of the attendees are starting to use our system for their
     83experiments.
     84
     85Another major addition to our software this period was the ability to access
     86X window software running on the experimental nodes (slivers) via the MC web
     87interace.  Our goal was to leverage existing network monitoring
     88tools, such as Wireshark and EtherApe, in order to observe the behavior of
     89experimental nodes. These tools are helpful to collect node statistics and
     90visualize the link traffic. However, they need X window support.
     91To support such access, we added the ability to dynamically load X-window
     92software onto the experimental nodes and then provide indirect access through
     93the MC Web browser and the VNC protocol.   It has been added to the the MC's
     94Drupal content management system as one of the menu options.  The only way
     95for a user to access the programs running on the experimental nodes is to
     96first login to the Drupal CMS running on the MC.  This way, we can assure the
     97slice owner that they are the only ones allowed to access/run these
     98programs.   Our Drupal interface currently has two VNC templates that are
     99preconfigured to run xterm and wireshark respectively on the nodes in the
     100slice via VNC.  The MC runs a JAVA-based VNC client (in the CMS) that mirrors
     101the VNC connections from the nodes.  The VNC communication between the nodes
     102and the MC are protected by a system generated random password that is
     103unique for every slice and invisible to the user.
     104
     105We gave an overview of the INSTOOLS software at the GEC9 Instrumentation and
     106Measurement Workshop in Washington D.C.   We demonstrated the major
     107features of the INSTOOLS software, including the ability to access X-based
     108software like wireshark doing packet-level capture on experimental nodes.
     109
     110=== B. Project participants ===
     111
     112The following individuals have helped with the project in one way or another
     113during the last quarter:
     114 * Jim Griffioen - Project PI
     115 * Zongming Fei - Project Co-PI
     116 * Hussamuddin Nasir - Technician/programmer
     117 * Xiongqi Wu - Research Assistant
     118 * Jeremy Reed - Research Assistant (half time)
     119 * Lowell Pike - Network administrator
     120 * Woody Marvel - Assists in Emulab administration
     121
     122
     123=== C. Publications (individual and organizational) ===
     124
     125=== D. Outreach activities ===
     126
     127 * Gave an overview of our INSTOOLS software at the GEC9 Instrumentation and Measurement Workshop.
     128 * Gave a hands-on tutorial as part of the ProtoGENI tutorial at GEC9.
     129
     130=== E. Collaborations ===
     131
     132Most of our collaborations continue to be with the Utah ProtoGENI team, and
     133we continue to be actively involved in the bi-weekly meetings of the ProtoGENI
     134cluster.
     135
     136=== F. Other Contributions ===