Skip to content

Jagger Deployment

Jump to bottom
Dmitry Latnikov edited this page Dec 23, 2013 · 20 revisions

Jagger Deployment

Introduction to the System Configuration

Jagger is pretty configurable system. It could be launched in local or distributed mode, with internal or external DBMS, with or without monitoring agents. See Jagger Operation Modes for examples.

All specified could be be configured with corresponding properties.

The main configuration Jagger's file is default.environment.properties . It contains properties for managing:

  • roles with that Jagger instance could be launched (MASTER, KERNEL, RDB_SERVER, REPORTER, COORDINATION_SERVER and so on).
    • MASTER is a node that distributes tests execution between KERNELs, decides when workload should be stopped, gathers hi-level statistics.. Could exist only one instance within configuration.
    • KERNEL is a node that creates workload on a tested system. In the distributed mode any count of KERNELs could be present.
    • COORDINATION_SERVER is a node that used for communication purpose between MASTER, KERNELs, monitoring agents. Could exist only one instance within configuration.
    • RDB_SERVER is a node that responsible for storing aggregated data and execution summary. Currently MySQL and H2 could be used. Could exist only one instance within configuration.
    • REPORTER is a node that responsible for reports building. Could be used for building reports on existing in DBMS data. Could exist only one instance within configuration.
  • DBMS settings.
  • settings for coordinator server.
  • settings for file system storage.

Every property from default.environment.properties could be overridden in profile or from a command line during system start.

Jagger Profiles

Currently existing profiles:

  • local - profile for running Jagger in local mode on developer's machine.
  • ci-distributed - profile for running Jagger in distributed mode on virtual machines.
  • report - profile for running Jagger in report generation mode.

Samples of profile choosing for Jagger start:

./start.sh profiles/local/environment.properties
./start.sh profiles/reporter/environment-reporter.properties

Local Mode

Local mode is a mode within that whole infrastructure is launched in single JVM.

Local profile location is JAGGER_HOME/profiles/local. That directory contains file environment.properties that overrides some properties from default.environment.properties.

  • chassis.roles setting value specifies what roles should be launched within one JVM. E.g. chassis.roles=MASTER,KERNEL,RDB_SERVER,HTTP_COORDINATION_SERVER
  • chassis.coordination.bean=memoryCoordinator means that no external coordinator will be used for communication between MASTER and KERNEL. Coordinator with in-memory implementation will be used for that mode.
  • chassis.log.storage.bean=localFileStorage means that information for aggregation will be stored in local FileSystem.
  • chassis.log.storage.file.workspace=${chassis.workspace}/storage specifies path where information for aggregation should be stored.

External RDBMS for Storing Test Results

Jagger can store final results in its own embedded database or in external database. The last alternative slightly complicates deployment (you need to deploy and configure standalone RDBMS), but enable you to browse and manage test results at any time using any DB visualization tool.

To make Jagger use external database the next properties should be overridden in profile's environment.properties file:

chassis.storage.rdb.client.driver
chassis.storage.rdb.client.url
chassis.storage.rdb.username
chassis.storage.rdb.password
chassis.storage.hibernate.dialect

MySQL is a typical choice for external DB. Configuration for MySQL looks as follows:

chassis.storage.rdb.client.driver=com.mysql.jdbc.Driver
chassis.storage.rdb.client.url=jdbc:mysql://test-jagger1.vm.griddynamics.net:3306/jaggerdb
chassis.storage.rdb.username=******
chassis.storage.rdb.password=******
chassis.storage.hibernate.dialect=org.hibernate.dialect.MySQL5Dialect

###Distributed Mode

For extensive workload creation Jagger could be launched on multiple servers.

Next roles are needed for distributed mode:

  • one instance with MASTER role
  • one instance with COORDINATION_SERVER role
  • one or more instances with KERNEL role

Communication between MASTER and KERNELs comes through COORDINATION_SERVER.

MASTER doesn't have information about KERNELs that will do workload before its start. KERNEL has an address of COORDINATION_SERVER (chassis.coordinator.zookeeper.endpoint) in it's config and registers on COORDINATION_SERVER after start. MASTER gets list of available KERNELs from COORDINATION_SERVER and distributes tasks for execution among registered KERNELs after start. Report with execution results available on MASTER after execution finished.

###KERNEL Configuration

Typical environment.properties file for KERNEL role:

chassis.roles=KERNEL
chassis.coordinator.zookeeper.endpoint=test-jagger1.vm.griddynamics.net:2181
chassis.workspace=./jaggerworkspace
chassis.storage.fs.default.name=hdfs://test-jagger1.vm.griddynamics.net/
chassis.storage.rdb.client.driver=com.mysql.jdbc.Driver
chassis.storage.rdb.client.url=jdbc:mysql://test-jagger1.vm.griddynamics.net:3306/jaggerdb
chassis.storage.rdb.username=******
chassis.storage.rdb.password=******
chassis.storage.hibernate.dialect=org.hibernate.dialect.MySQL5Dialect

###MASTER Configuration

Typical environment.properties file for MASTER role:

chassis.roles=MASTER,COORDINATION_SERVER,HTTP_COORDINATION_SERVER
chassis.master.session.configuration.bean.name=testConfiguration
chassis.coordinator.zookeeper.endpoint=test-jagger1.vm.griddynamics.net:2181
chassis.workspace=./jaggerworkspace
chassis.storage.fs.default.name=hdfs://test-jagger1.vm.griddynamics.net/
chassis.storage.rdb.client.driver=com.mysql.jdbc.Driver
chassis.storage.rdb.client.url=jdbc:mysql://test-jagger1.vm.griddynamics.net:3306/jaggerdb
chassis.storage.rdb.username=******
chassis.storage.rdb.password=******
chassis.storage.hibernate.dialect=org.hibernate.dialect.MySQL5Dialect
chassis.conditions.monitoring.enable=true
chassis.conditions.min.agents.count=2
chassis.conditions.min.kernels.count=2

Make your own profiles, and launch Jagger with it.

more about configuration properties

Typical scenario of launching Jagger in a distributed mode:

  • Multiple Jagger instances with KERNEL role (chassis.roles=KERNEL) are launched.
  • KERNELs are waiting for COORDINATION_SERVER to register.
  • Optional One or more monitoring agents start and wait for COORDINATION_SERVER to register.
  • MASTER starts, parses tasks for execution list and waits for COORDINATION_SERVER.
  • After COORDINATION_SERVER started MASTER retrieves list of active KERNELs and monitoring agents.
  • If active KERNELs count < chassis.conditions.min.kernels.count MASTER waits till more KERNELs registered.
  • If monitoring enabled (chassis.conditions.monitoring.enable=true) and active agents count < chassis.conditions.min.agents.count` MASTER waits till more monitoring agents registered.
  • MASTER distributes tasks between active KERNELs.
  • After all tasks execution finished MASTER stores data about execution to DB and generates report.
  • MASTER and COORDINATION_SERVER could be launched on the same server.
Clone this wiki locally