| 1 | [[PageOutline]] |
| 2 | |
| 3 | = InstrumentationTools Project Status Report = |
| 4 | |
| 5 | Period: 2Q09 |
| 6 | == I. Major accomplishments == |
| 7 | |
| 8 | === A. Milestones achieved === |
| 9 | During the past quarter we made continued progress toward our milestones. In summary we: |
| 10 | * continued to improve the aggregate reference implementation running at Kentucky. |
| 11 | * continue to work with Utah and members of the security team regarding security issues in the design of our aggregate and measurement system. |
| 12 | * have begun to design an instrumentation/measurement model that can be integrated with the Proto-GENI architecture. |
| 13 | |
| 14 | === B. Deliverables made === |
| 15 | None yet. |
| 16 | |
| 17 | == II. Description of work performed during last quarter == |
| 18 | |
| 19 | === A. Activities and findings === |
| 20 | This quarter we began building on the (evolving) ProtoGENI aggregate system that we installed in the |
| 21 | previous quarter. In particular, we spent a good deal of our time getting familiar with the new system, |
| 22 | its architecture, and the new software that drives it. As part of this effort, we have begun to develop test |
| 23 | scripts that make use of the ProtoGENI interface (API) to reserve resources and create experiments. Not |
| 24 | only has this helped us better understand the API, RSPECs, and the overall system architecture, but it has |
| 25 | help us uncover some issues with the ProtoGENI design that were going to make it difficult for us to build |
| 26 | an instrumentation system. In particular, we found that the current RSPEC approach did not include the |
| 27 | information we needed to be able to monitor links in the topology, and, more generally, the information that |
| 28 | is assigned at the time that resources are allocated and redeemed. We raisied these issues with the Utah team |
| 29 | and had various discussions about how to handle these issues. The solution that the Utah group has decided |
| 30 | to use is to redesign the RSPECs to include a “manifest” that provides the additional information we need. |
| 31 | |
| 32 | Given a better understanding of the ProtoGENI architecture, we have been developing an instrumenation |
| 33 | architecture that will incorporate the Edulab’s measurment capabilities into the ProtoGENI system. Our new |
| 34 | approach is different from our original design in that we intend to deploy experiment-specific measurement |
| 35 | infrastructure in the form of measurement controller nodes that monitor an experiment’s behavior across the |
| 36 | various aggregates that comprise the experiment. Not only are experiment measurement results kept private |
| 37 | to the experiment, but it distributes the monitoring load across multiple nodes so the monitoring system |
| 38 | can scale up as the measurement workload increases. An initial version of our instrumentation design was |
| 39 | presented by Jim Griffioen at the GENIMeasurement Workshop at the University of Wisconsin. Slides from |
| 40 | the talk can be found at http://groups.geni.net/geni/wiki/GENIMeasWS. Another important issue that we |
| 41 | are trying to resolve is how visible the measurement system should be to users. Our current thinking is that |
| 42 | the measurement infrastructure should be as invisible as possible, only making the results of measurement |
| 43 | available to users and giving them the ability to control which measurement results they want to see. |
| 44 | |
| 45 | In the process of becoming familiar with the ProtoGENI system and developing an instrumentation |
| 46 | system for it, we ran into issues related to authenticating users and services between nodes; in particular, |
| 47 | between our measurement system resources and the resources being measured. We have had multiple conversations |
| 48 | with the Utah team and have discussed these issues with other members of Cluster C–including |
| 49 | members of the security team–working with them to come up with security solutions (and a general security |
| 50 | framework) that will be useful to all members of the cluster. As of yet, the security/access model has not |
| 51 | been finalized, and we continue to discuss various alternatives. |
| 52 | |
| 53 | In addition to planning measurement additions to our aggregate, the ProtoGENI team has been making |
| 54 | continuous improvements to the code base which we have been applying regularly and then testing to make |
| 55 | sure our scripts continue to run with the newly updated system. We have also done some limited testing |
| 56 | across aggregates to verify that it works as expected and to become familiar with allocating resources across |
| 57 | aggregates. |
| 58 | === B. Project participants === |
| 59 | The following individuals have helped with the project in one way or another during the last quarter: |
| 60 | * Jim Griffioen - Project PI |
| 61 | * Zongming Fei - Project Co-PI |
| 62 | * Hussamuddin Nasir - The project’s primary technician and programmer |
| 63 | * Lowell Pike - Network administrator |
| 64 | * Woody Marvel - Assists in Emulab administration |
| 65 | === C. Publications (individual and organizational) === |
| 66 | James Griffioen and Zongming Fei, Automatic Creation of Experiment-specific Measurement Infrastructure, |
| 67 | In the proceedings of the First Workshop on Performance Evaluation of Next-Generation Networks (Neteval |
| 68 | ’09), Boston MA, April 2009 |
| 69 | === D. Outreach activities === |
| 70 | We participated in the recent GENI Measurement conference and also gave a talk about our work at the |
| 71 | Neteval ’09 conference. |
| 72 | === E. Collaborations === |
| 73 | Most of our collaborations continue to be with the Utah ProtoGENI team, and we continue to be actively |
| 74 | involved in the bi-weekly meetings of the ProtoGENI cluster (Cluster C). |
| 75 | === F. Other Contributions === |
| 76 | None yet. |