Changes between Version 21 and Version 22 of GEMINIv1.1Tutorial

Timestamp:

10/22/12 17:07:36 (11 years ago)

Author:

Ahmed El-Hassany

Comment:

--

GEMINIv1.1Tutorial

@@ -399 +399 @@
 === 3) Configure I&M tools and experiment services ===
 
-3.1)   Configure selected I&M services
+3.1)   Configuring Active Measuremens
 
  - objectives:
@@ -407 +407 @@
  
  - at completion:    configured I&M services, ready to run and collect data
+
+
+
+The GEMINI I&M system in its current version facilitates regular measurements of throughput, one-way delay and round-trip delay. Other metrics like jitter and loss can also be derived from these measurements. 
+
+The GEMINI services on a given node are configured by the pSConfig service. This service reads configuration stored in UNIS as part of the node's topology information and applies it to local configuration files. pSConfig will also start enabled services or stop disabled services that are running. 
+
+We will now configure one-way (OWAMP) and round-trip (Ping) latency regular tests according to the following diagram.
+
+[[Image(latency-tests.png)]]
+
+===== 3.1.1 Accessing pSConfig UI =====
+
+To configure active measurements we access the pSConfig Web UI. You can find the URL by clicking on the MC node on the GEMINI portal, or by going to https://<gn node>/psconfig.
+
+[[Image(psconfig-portal.png)]]
+
+The certificate used by the web server is self-signed, so you will have to add an exception on the browser to proceed.
+
+[[Image(psconfig-secexception.png)]]
+
+After adding the exception you should see another pop-up for a certificate request. This time you're providing your user certificate to the service. Make sure the user that is shown for the certificate is the one assigned to you for the tutorial. In this example I'm using the user ''gemini20''. In case you did not see this pop-up or cannot see your user, please redo the steps on [wiki:GEMINIGEC14VMInstructions User Workspace - Accessing the portal].
+
+[[Image(psconfig-usercert.png)]]
+
+The main page of the pSConfig UI shows what services are currently enabled for each node. It also shows the last time we have synchronized with UNIS (remember that configuration information resides in UNIS). There are other agents that could be changing the information on UNIS, and the pSConfig UI will make sure we don't overwrite changes made since the last pull (i.e. a race condition). It is always a good idea to first pull the current configuration from UNIS before making changes.
+
+[[Image(psconfig-main.png)]]
+
+===== 3.1.2 Enabling Services =====
+
+After we've made sure to have a recent copy of the topology information, we can move on to the Manage Services administration page. On this page we will enable the services required to perform on-demand and regularly scheduled tests. We start by enabling the throughput and one-way latency services on PCA. Make sure to save the changes before continuing to the next node.
+
+[[Image(psconfig-managepca.png)]]
+
+We then proceed to configure the services on nodes PCB and PCC. Since PCB will be the gateway, we will only enable the daemons for the tools used (owamp and bwctl). PCC will have all the latency services and the daemon for throughput measurements. Note that PingER is only enabled on PCC, and we will configure our Ping measurement on that node. (We will use PCA for the scheduled throughput measurements at the end of the tutorial.)
+
+[[Image(psconfig-managepcbpcc.png)]]
+
+Now that we've enabled the services for our active measurements we will push the configuration to UNIS. To do this we need to go back to the Configuration Status page and then click the Push Configuration to UNIS. You can verify the list of services enabled for each node (i.e. the list in the image should match what you see).
+
+[[Image(psconfig-managepush.png)]]
+
+If everything goes well we should see a green message "Configuration pushed to UNIS.". However, the page auto reloads after this, so you might miss it if not paying attention. If there is no error message, the push completed successfully and the modification time will be 'never'.
+
+Success:
+
+[[Image(psconfig-managepushsuccess.png)]]
+
+Failure (unfortunately, you will have to redo the steps above in the case of a race condition):
+
+[[Image(psconfig-managepushfailure.png)]]
+
+===== 3.1.3 Configuring Regular Active Measurements =====
+
+Enabling the OWAMP and BWCTL daemons is all we need to perform on-demand active measurements. However, it's usually better to have active measurements running regularly to analyze the performance over time. Throughput and ping tests can be scheduled with a given interval (e.g. every 30 minutes). One-way delay tests are scheduled as a stream (a constant amount of packets is sent per second). 
+
+To schedule regular tests we go to the Schedule Tests administration page. 
+
+[[Image(psconfig-schedule.png)]]
+
+We will schedule OWAMP tests from PCA to PCB. We could schedule them on either endpoint, as long as both of them are running the appropriate pSBOUY Regular Testing service. In this case we schedule the tests on PCA by selecting it and adding a new OWAMP test. Clicking the Add New One-Way Delay Test button will pop-up the options to configure the test. The description for the test is only important to you, the services don't use it directly. You can change the packet rate and the packet size used for the test, but we will use the default for the tutorial.
+
+[[Image(psconfig-schedule-pcacreate.png)]]
+
+The test we've added establishes the test parameters for a given "star" mesh configuration. We can add multiple targets for this mesh (for OWAMP tests will run in parallel, for BWCTL measurements will be serialized). In this case we add PCB as a target and save the test.
+
+[[Image(psconfig-schedule-pcasave.png)]]
+
+Now we do the same thing on node PCC (one-way delay test to PCB). 
+
+[[Image(psconfig-schedule-pccowd.png)]]
+
+We also add a Ping test between nodes PCA and PCC, scheduled at node PCC (this is where we enabled the PingER service).
+
+[[Image(psconfig-schedule-pccping-add.png)]]
+
+We can configure the standard ping parameters and the description for our test. The default has a relatively large packet size, so keep this in mind when analyzing the latency results (the ideal is to have packets the size of your experiment's packets). After creating the test we need to add our targets (PCA) and save the test. ''NOTE: You could use the 'Add New Host' button to add hosts outside of the slice (e.g. to ping geni.net).''
+
+[[Image(psconfig-schedule-pccping-save.png)]]
+
+After adding all these tests we go back to the Configuration Status page and push the configuration to UNIS.
+
+[[Image(psconfig-schedule-push.png)]]
+
+===== 3..14 Applying the Configuration =====
+
+pSConfig will pull the node's configuration from UNIS every 30 minutes (from the time it was started, not hh:00 and hh:30). Since we don't want to wait this long to start gathering data, we can restart pSConfig on each node by clicking the Apply Config link. This is achieved by ssh'ing to the node and restarting pSConfig, so errors are usually ssh related.
+
+[[Image(psconfig-apply.png)]]
+
+Make sure you apply the configuration on all three nodes. We will now run the user experiment to generate some heavier traffic on the slice before looking at the data.
+
+