Changes between Version 14 and Version 15 of sppReport-1Q09


Ignore:
Timestamp:
03/24/09 17:06:20 (13 years ago)
Author:
Jon Turner
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • sppReport-1Q09

    v14 v15  
    55=== Upgrading of Software for System Initialization ===
    66
    7 The PlanetLab project made significant changes to the software that manages the booting and initialization of PlanetLab nodes. Since the SPP relies on these mechanisms as well, we have had to make some changes to our own software to accommodate the changes made by PlanetLab. As context, when a PlanetLab node comes up, it contacts PlanetLab Central (PLC) to obtain a boot image and a variety of configuration data. Since the GPEs in an SPP run the PlanetLab OS, they also attempt to contact PLC when they boot. However, the SPP is designed to look to the external world, like a single PlanetLab node, so it would be inappropriate to let the GPEs contact PLC directly. To avoid making unnecessary changes to the GPE (which would make it difficult for us to track future changes to the PlanetLab code), we have implemented a software module running on the SPP's control processor that intercepts the connections between the GPEs and PLC, hiding the internal structure of the SPP from PLC, while still getting the GPEs the information they need to complete their initialization. We have implemented and tested the changes needed to this module to allow us to stay consistent with PlanetLab.
     7The PlanetLab project made significant changes to the software that
     8manages the booting and initialization of standard Linux/Vserver nodes. Since the SPP relies on these mechanisms as well, we have had to make some changes to our own software to accommodate the PlanetLab modifications. There are two core 'boot time' issues: 1) each GPE requires unique configuration information and 2) it is inappropriate for each GPE to independently report possibly contradictory node state information to the PLC.
     9
     10As context, when a PlanetLab node comes up, it obtains the initial boot image and node configuration information from a local read-only file system. After bringing up the interfaces it contacts PlanetLab Central (PLC) to obtain the final boot image and a variety of configuration data. Since the GPEs in an SPP run the PlanetLab OS, they  follow this same procedure. However, we have had to modify the initial boot scripts to use the local control processor as a boot server thus obtaining GPE specific boot images and configuration information.
     11
     12Once a PlanetLab node has completed this initial boot sequence it then contacts PLC to both download node-specific information and to report it's boot state and other ancillary information. However, the SPP is designed to look to the external world, like a single PlanetLab node, so it would be inappropriate to let the GPEs contact PLC directly. For example, if one GPE boots correctly but a second fails then the node state would be set to the value last reported (the state reported should be controlled by policy). To avoid making unnecessary changes to the PlanetLab control software (which would make it difficult for us to track future changes to the PlanetLab code), we have implemented a software module running on the SPP's control processor that intercepts the connections between the  GPEs and PLC, hiding the internal structure of the SPP from PLC, while while allowing us to manage the information flow between the PLC and GPEs. We have implemented and tested the changes needed to this module to allow us to stay consistent with PlanetLab.
    813
    914=== Integration of Slice Login Manager (SLM) ===
    1015
    11 The SLM is a software module running on the SPP's Control Processor that enables remote users to login to their slices without having to be aware of the specific GPE on which their slice's vServer is running. Incoming SSH connections are directed by the SPP Line Card to the SLM, which deals with authentication, determines which GPE is hosting the user's slice and forwards the connection to that slice. Once the login procedure is complete, packets flowing between the user and its vServer are forwarded transparently by the CP (at the OS level), without further involvement by the CP.
     16The SLM is a software module running on the SPP's Control Processor that enables remote users to login to their slices without having to be aware of the specific GPE on which their slice's vServer is running. Incoming SSH connections are directed by the SPP Line Card to the SLM, which deals with authentication, determines which GPE is hosting the user's slice and forwards the connection to that slice. Once the login procedure is complete, packets flowing between the user and its vServer are forwarded transparently, without further involvement of the SLM.
    1217
    1318=== Software for Remote Display of Real-Time Performance Data ===