This wiki is obsolete, see the NorduGrid web pages for up to date information.

Testing/ARC-InfoSys

From NorduGrid
Jump to navigationJump to search

Coordination effort for each RC will be performed at the links shown in the Testing page.

Test report

Test report goes here.

EMI Component Description and Version

The ARC Infosys components are responsible for storing and presenting of informations collected on CE or SE. They include the "Local", LDAP-based information system (ARIS, ARC Resource Information System) and the LDAP-based Index service, the EGIIS. As a special "client", the grid monitor provides visualization of the information content of both the ARIS and EGIIS services.

Code analysis

  • Tester: Marek
  • due: for every RC
  • Sloccount:
  • CCCC metrics:

Later the results will be split between components.

Unit tests

  • Tester: Anders
  • due for every RC

Lonk to results of unit test code coverage for entire ARC code goes here.

The text description of results will come later.

Later the results will be split between components.


Deployment tests

IS-D1: clean installation

  • Tester: Marek
  • due: for every RC

IS-D2: upgrade installation

  • Tester: Marek
  • due: for every RC

System tests

Regression tests

  • Tester: Marek
  • due for every RC

Check savanna RfCs for bugs

Functionality tests

IS-F1: ARIS

    • Description of the test:
Configure and distcleanstart the ARC CE and its Infosys. Submit a simple job to ARC CE, wait 120 seconds and query the local Infosys using the ldapsearch command with proper parameters. Repeat the submission and query every five times.
    • Testbed:
ARC CE and its Infosys deployed on resource described above, ldapsearch command on external machine
    • Expected result:
After each query the produced output shall contain information about additional job being submitted to that ARC CE (after first query there shall be one job recorded, after second, there shall be two, etc.).
    • Result:

IS-F2: EGIIS

  • IS-F2.1: registering ARC CE to EGIIS
    • Description of the test:
Configure and start the EGIIS. Configure the ARC CE`s Infosys so that it registers to the running EGIIS. Query the EGIIS using ldapsearch command with proper parameters.
    • Testbed:
EGIIS deployed on resource described above, ARC CEs taken from EMI Testbed, ldapsearch command on external machine
    • Expected result:
The output produced by ldapsearch shall contain the information about registered ARC CE.
    • Result:
  • IS-F2.2: de-registering ARC CE from EGIIS
    • Description of the test:
Configure and start the EGIIS. Configure the ARC CE`s Infosys so that it registers to the running EGIIS. Query the EGIIS using ldapsearch command with proper parameters to check if the ARC CE is registered. Stop the ARC CE`s Infosys and query the EGIIS using ldapsearch command with proper parameters
    • Testbed:
EGIIS deployed on resource described above, ARC CEs taken from EMI Testbed, ldapsearch command on external machine
    • Expected result:
The output produced by ldapsearch shall not contain any information about previously running ARC CE.
    • Result:


IS-F3: Grid Monitor

IS-F3: Ldap Grid Monitor

  • IS-F3.1: Check registered ARC CE to EGIIS using Grid Monitor
    • Description of the test:

Configure and start the EGIIS. Configure the ARC CE`s Infosys so that it registers to the running EGIIS. Query the EGIIS using ldapsearch command with proper parameters to check if the ARC CE is registered. Configure and start the Grid Monitor and check the details about registered CEs.

    • Testbed:

Ldap Grid Monitor deployed on resource described above, ARC CEs taken from EMI Testbed, ldapsearch command on external machine

    • Expected result:

The Grid Monitor shall include correct information about ARC CE registered to EGIIS. The information shall be identical with output produced by ldapsearch command

    • Result:


  • IS-F3.2: Check de-registered ARC CE from EGIIS using Grid Monitor
    • Description of the test:
Configure and start the EGIIS. Configure the ARC CE`s Infosys so that it registers to the running EGIIS. Query the EGIIS using ldapsearch command with proper parameters to check if the ARC CE is registered. Check the details of Grid Monitor to make sure the ARC CE is listed there properly. Stop the ARC CE`s Infosys and check the Grid Monitor again.
    • Testbed:
Ldap Grid Monitor deployed on resource described above, ARC CEs taken from EMI Testbed, ldapsearch command on external machine
    • Expected result:
No information about ARC CE shall be found in Grid Monitor
    • Result:

Performance tests

IS-P1: ARIS service reliability

Services run by the component must maintain a good performance and reliability over long periods of time with normal operation. Long running unattended operation test measuring performance of the product. Service must not show performance degradation during a 3-day period.

IS-P2: EGIIS service reliability

Services run by the component must maintain a good performance and reliability over long periods of time with normal operation. Long running unattended operation test measuring performance of the product. Service must not show performance degradation during a 3-day period.

IS-P3: ARIS load test

  • Tester: Florido
  • Purpose: Check if ARIS can handle 100 hundreds concurrent client query (downgraded to 50 due to lack of time to setup the test)

Description of the test:

This test is to measure if ARIS is able to serve 50 parallel ldap requests with 5000 jobs sitting in the ARC-CE and be uptime for at least one day.

The test will measure uptime, cputime, memory, memory used by the slapd server. On the client side, data will be gathered to understand the average time needed to perform and receive a ldap request.

In this test we will use an isolated ARC-CE with ARIS running, that is, the cluster is not part of the grid hence infosystem data is not pushed to an index but just published locally via an ldap server. Moreover, A-REX and ARIS are the only relevant load on the server. We expect a performance degradation for the server resources to be 50% than without requests.

We expect a performance degradation for all the clients to be 50% than for a single client performing the request with server not on load.


Detailed description:

Server specification:

  • 5000 jobs sitting on the server but not executing; these jobs are sent to the CE using the --dryrun option of ARC clients. This will populate job records of the ldap infosys.
  • 100 users allowed to access the server. This will populate the users records of the ldap server
  • fork as a LRMS backend, that means, jobs are executed locally by the CE with no advanced LRMS.
  • two runtime environments are added so to publish more data
  • only the nordugrid schema is published
  • data is collected using ps, top and netstat by a cron job.

Clients specifications:

  • two physical machines running respectively 20 and 15 ldap concurrent queries each
  • one virtual machine running 15 concurrent ldap queries
  • queries are run using the ldapsearch command
  • concurrency and data collection is done by a perl script
  • Request response time is estimated using perl time


Description of the specific context:

Testbed requirements:
* A physical machine running a-rex and aris with nordugrid schema enabled
* at least 3 machines with ldapsearch installed
* deployment of test scripts on the machines

Testbed Setup

Attached files: arc.conf, grid-mapfile, testldap.xrsl, datacollector.sh, ldapparqueries.pl, gnuplot.sh in Media:ARC_Infosys-P3.tar.gz
  1. from a client machine with ng* or arc* tools installed, populate the server with 20000 sitting jobs this way: 
     for (( i=1; i<=5000; i++)); do ngsub -dryrun -f testldap.xrsl -c <servername> ; done;
    for (( i=1; i<=5000; i++)); do arcsub -D -f testldap.xrsl -c <servername> ; done;
  2. scp ldapparqueries.pl to each client machine and create a tmp directory in the same directory where ldapparqueries is
  3. On the server:
    1. copy grid-mapfile in /etc/grid-security/
    2. copy arc.conf in /etc/ and modify at least the hostname
    3. copy datacollector.sh into /tmp/ and add a cronjob to run the script datacollector.sh. suggested time is every 10 min. cron entry:
      */10 * * * * /tmp/datacollector.sh
  4. start ldapparqueries.pl on each machine:
    1. on a physical machine:
      ./ldapparqueries.pl --server <hostname> --threads 20 --nqueries 5 --loop
    2. on a physical and a virtual machine:
      ./ldapparqueries.pl --server <hostname> --threads 15 --nqueries 5 --loop
  5. let the machines run for at least 1 day
  6. collect output:
    1. on the server, /tmp/ps-ldap-output.txt,/tmp/top-ldap-output.txt,/tmp/conns-ldap-output.txt
    2. on the clients, copy all the files in the tmp directories (thay contain query results and time for each thread)
  7. To evaluate, run the gnuplot script for each dataset and check the averages using the script average.pl.
Actual Testbed:

Describe here

Expected results:
1) Uptime of the ldap server must be > 1 day;
2) attended requests of the ldap server must be 50% of the total performed requests
3) memory usage of the ldap server must be < 50% of the system memory
4) cpu usage of the ldap server must be < 50% of the system memory
5) average response time of the ldap server must be < 20 sec

Result: PASSED/FAILED

Test is passed if the above are fulfilled.

IS-P4: EGIIS load test

Check if EGIIS can handle 100 hundred concurrent client query

Scalability tests

IS-S1: ARIS

Check how ARIS behaves with increasing number of job entries on the cluster.

IS-STD Standard compliance/conformance tests

  • see the glue2 tests in ARC-CE tbd: put link

IS-ICT Inter-component tests

  • check later interoperability with glite site and top BDII
Retrieved from "https://wiki.nbi.ku.dk/w/index.php?title=Testing/ARC-InfoSys&oldid=4809"