Deploying DIET and Jux Mem Go DIET JDF

Conducting JXTA-based experiments: the JXTA Distributed Framework (JDF) § A framework for automated testing

How to define a test using JDF? n An XML description file of the

Deploying a Jux. Mem network (1/2) cluster C group cluster A group juxmem group

Usage of JDF’s scripts n run. All. sh [<flags>] <list-of-hosts> <network-descriptor> n n n

Common architecture: DIET + Jux. Mem juxmem group Cluster manager + MA/LA Provider Client

Common deployment: Go. DIET + JDF n 2 differents tools with different goals n

Modified DTD of Go. DIET § Idea: 2 different hierarchies § n The matching

Launching DIET and Jux. Mem entities n DIET entities 1) 2) 3) n Jux.

Example of a common deployment (1/2) n Physical architecture n n n Logical architecture

Example of a common deployment: DIET hierarchy <diet_hierarchy> <master_agent> <config server="cluster. A-0" remote_binary="diet. Agent"/>

Example of a common deployment: Jux. Mem hierarchy <juxmem_hierarchy> <manager server="cluster. A-0" /> <client

Required modifications in Go. DIET n Handling new XML tags n n Writing the

Work schedule for Go. DIET + JDF n Modified DTD of Go. DIET n

Work schedule for DIET + Jux. Mem n Deploying JXTA-C peers using JDF n

Conclusion n Common architecture for DIET and Jux. Mem n n Common deployment using

Slides: 17

Download presentation

Deploying DIET and Jux. Mem: Go. DIET + JDF Mathieu Jan PARIS Research Group IRISA INRIA & ENS Cachan / Brittany Extension Rennes Lyon, July 2004

Conducting JXTA-based experiments: the JXTA Distributed Framework (JDF) § A framework for automated testing of JXTA-based systems from a single node (control node) § Original work from Sun Microsystems § http: //jdf. jxta. org/ n JDF: several shell scripts n Deployment n n n n Jar files and script used on each node Configuration of JXTA peers Launch peers Collect logs and results files of each node Analyze results on the control node Cleanup deployed and generated files Kill remaining processes Update resource 2

How to define a test using JDF? n An XML description file of the JXTA-based network n n n A set of Java classes describing the behavior of each peer n n n Type of peers (rendezvous, edge peers) How peers are interconnected, etc Extend the JDF’s framework (start, stop JXTA, etc) A Java class for analyzing collected results A file containing the list of nodes and the path of the JVM on each node 3

Deploying a Jux. Mem network (1/2) cluster C group cluster A group juxmem group cluster B group 4

Deploying a Jux. Mem network (2/2) <profile name=“cluster. Manager. A" instances="1"> … <profile name=“cluster. Manager. B" instances="1"> … <profile name=“cluster. Manager. C" instances="1"> … </profile> <profile name="provider. A" instances=“ 42“ > <peer base-name="provider. A" instances=“ 4“ /> <rdv cluster=“cluster. Manager. A"/> … </profile> <profile name="provider. B" instances=“ 42“ > <peer base-name="provider. C" instances=“ 5“ /> <rdv cluster=“cluster. Manager. B"/> … </profile> <profile name="provider. C" instances=“ 35“ > <peer base-name="provider. C" instances=“ 6“ /> <rdv cluster=“cluster. Manager. C"/> … </profile> 5

Usage of JDF’s scripts n run. All. sh [<flags>] <list-of-hosts> <network-descriptor> n n n n -debug: show all script commands executed -unsecure: use rsh instead of ssh -cleanup: cleanup JDF directory on each host -bundle: create bundle for distribution -install: install distribution bundle -update: update files on each peer -config: configure JXTA network -kill: kill existing JDF processes -run: run test -nohup: run and return without waiting for peers to exit -analyze: analyze test results -log: keep test results and log 4 j logs from peers -save: save JXTA platform. Config files -restore: restore JXTA platform. Config files 6

Common architecture: DIET + Jux. Mem juxmem group Cluster manager + MA/LA Provider Client DIET + client Jux. Mem Se. D + client Jux. Mem 7

Common deployment: Go. DIET + JDF n 2 differents tools with different goals n n n DIET = Go. DIET Jux. Mem = JDF Idea for merging tools n n n Go. DIET reads the XML configuration file Create the test. xml and host. txt files for JDF Call JDF to configure and run the test n In the correct order 8

Modified DTD of Go. DIET § Idea: 2 different hierarchies § n The matching is done by the server tag <!ELEMENT deployment (diet_services, diet_hierarchy, juxmem_hierarchy? )> n <!ELEMENT juxmem_hierarchy (manager+)> n <!ELEMENT manager (client*|provider*)> n n <!ELEMENT client EMPTY> n n <!ATTLIST manager server CDATA #REQUIRED port CDATA #IMPLIED> <!ATTLIST client server CDATA #REQUIRED port CDATA #IMPLIED> <!ELEMENT provider EMPTY> n <!ATTLIST provider server CDATA #REQUIRED port CDATA #IMPLIED> 9

Launching DIET and Jux. Mem entities n DIET entities 1) 2) 3) n Jux. Mem entities 1) 2) n MA LA Se. D Cluster managers (rdv peers) Providers / clients (edge peers) DIET + Jux. Mem 1) 2) 3) MA / LA + cluster managers Providers Se. D + Jux. Mem clients 10

Example of a common deployment (1/2) n Physical architecture n n n Logical architecture n n n 4 clusters: A, B, C, D 15 nodes in each cluster 1 4 4 3 8 MA on cluster A LA, one on each cluster managers, one on each cluster providers per manager Se. D + client Jux. Mem A DIET-Jux. Mem client needs to connect to n n 1 MA in order to use DIET 1 cluster manager in order to use Jux. Mem 11

Example of a common deployment: DIET hierarchy <diet_hierarchy> <master_agent> <config server="cluster. A-0" remote_binary="diet. Agent"/> <local_agent> <config server="cluster. A-0" remote_binary="diet. Agent"/> <Se. D><config server="cluster. A-1" remote_binary="scalar_server"/></Se. D>. . . <Se. D><config server="cluster. A-8" remote_binary="scalar_server"/></Se. D> </local_agent> <config server="cluster. B-0" remote_binary="diet. Agent"/> <Se. D><config server="cluster. B-1" remote_binary="scalar_server"/></Se. D>. . . <Se. D><config server="cluster. B-8" remote_binary="scalar_server"/></Se. D> </local_agent> …. </master_agent> </diet_hierarchy> 12

Example of a common deployment: Jux. Mem hierarchy <juxmem_hierarchy> <manager server="cluster. A-0" /> <client server="cluster. A-1, . . . , cluster. A-8" /> <provider server="cluster. A-9, . . . , cluster. A-11" /> </manager> <manager server="cluster. B-0" /> <client server="cluster. B-1, . . . , cluster. B-8" /> <provider server="cluster. B-9, . . . , cluster. B-11" /> </manager> <manager server="cluster. C-0" /> <client server="cluster. C-1, . . . , cluster. C-8" /> <provider server="cluster. C-9, . . . , cluster. C-11" /> </manager> <manager server="cluster. D-0" /> <client server="cluster. D-1, . . . , cluster. D-8" /> <provider server="cluster. D-9, . . . , cluster. D-11" /> </manager> </juxmem_hierarchy> 13

Required modifications in Go. DIET n Handling new XML tags n n Writing the correct test. xml and host. txt JDF files n n No need to write a files. txt New commands in Go. DIET shell n n Manager, client, provider Deploy Jux. Mem bundle Cleanup files, update files Retrieve log files and results files Modified launch command n += -config -run 14

Work schedule for Go. DIET + JDF n Modified DTD of Go. DIET n n Handling new XML tags n n Do we agree ? Creating the correct test. xml and host. txt files New Go. DIET shell commands => Holly and / or Mathieu ? 15

Work schedule for DIET + Jux. Mem n Deploying JXTA-C peers using JDF n n Jux. Mem client using JXTA-C n n Almost done Started (July) DIET using Jux. Mem clients code n Using API given by Jux. Mem (August-September) 16

Conclusion n Common architecture for DIET and Jux. Mem n n Common deployment using Go. DIET and JDF n n A Se. D is a client Jux. Mem Required step before a first DIET-Jux. Mem prototype Work schedule on n n Go. DIET + JDF DIET + Jux. Mem 17