1
Angewandte Wissenschaft Software und Technologie (AWST) GmbH, Mariahilfer Str. 47/3/1, A-1060 Vienna, Austria Telephone: +43-1-5861314 Facsimile: +43-1-5861314-22 Email Address: [email protected] Disclaimer The views expressed on this poster are those of the author and do not necessarily reflect the view of the CTBTO SnT2015 Poster No. T3.3-P14 IDCDACS: IDC’s Distributed Application Control System ported to Open Technologies Martin Ertl 1 , Alexander Boresch 1 , Ján Kianička 1 , Alexander Sudakov 2 , Elena Tomuta 2 (1) Angewandte Wissenschaft Software und Technologie (AWST) GmbH, Vienna, Austria (2) Comprehensive Nuclear-Test-Ban Treaty Organization (CTBTO), Vienna, Austria Background The Distributed Application Control System (DACS) is the backbone of the automatic processing of seismic, hydro- acoustic and infrasound (SHI) waveform data at the IDC. It drives the execution of processing applications by organizing data into time intervals, processing steps into pipelines, and using message queues for task scheduling. Objective Because licensed software hampers free distribution and use of IDC software to and by National Data Centres, IDC aimed at eliminating the dependency on the proprietary Tuxedo middleware. Accomplishments We redesigned the existing system and implemented the new IDCDACS based on an open-source messaging solution in combination with existing in-house IDC libraries and a custom- developed application framework, which together replace Tuxedo in a robust, reliable and scalable way. Open Technologies Our solution utilizes the RabbitMQ high availability message broker and the Advanced Message Queuing Protocol (AMQP), an open industry standard and wire-level protocol mandating that senders and recipients can interoperate irrespective of their specific implementation. IDCDACS is flexibly configurable to control different processing applications and pipeline-like processing workflows, i.e. it is by design not limited to SHI data processing, which is the primary use case at the IDC. Development Approach The new IDCDACS was implemented using the Scrum agile development methodology, aligned with evolving requirements and priorities. The first major Release is running on the IDC development LAN. Transition to Testbed and Operations LANs is in progress. Further development will improve usability, extend features, and lift current limitations. Message Queue for Task Scheduling Figure 2: Task Queue decouples Publishing and Consuming Clients. Yields a reliable and robust system. Permits parallel processing, for load balancing and scaling up. RabbitMQ Message Broker Consuming Client 1 Publishing Client Data Monitor, Tortoise publish Task Queue routing Consuming Client 2 Consuming Client N Consumer 1 Consumer 2 Consumer N Direct Exchange Round-robbin dispatch with prefetch=1 consume consume consume Connection + Channel Binding Connection + Channel Toirtoise, Database Service Processing Pipelines and Message Flow Figure 3: DACS processes (blue) run as daemons and listen on Message Queues (purple). Scheduler wakes up Data Monitor. Data Monitor checks conditions (data availability, status information, time, etc.) and creates Time Intervals. Tortoise executes Processing Application (aqua), reports status to Interval Table, and publishes to next Task Queue. Each Time Interval passes through all Steps until reaching Done Queue. In case of an error it will be short-circuited into Failed Queue. Deployment and Distribution Figure 4: 1 Database, 1 Message Broker, 1-N Processing Servers for DACS Server Programs and Processing Applications. Processing Server 2 Oracle Database Account (User) RabbitMQ Message Broker Virtual Host Processing Server 1 Operator Workstations Processing Server N . . . Software Application Framework Figure 1: Building blocks for common functionality like main control loop, exceptions, resource management, transactional messaging, client-side failover for high-availability cluster. Analyzable and Maintainable Code Figure 5: Object-oriented programming style. /* Create and setup the application object */ app = Application.new(NULL, argc, argv); /* Create the shell object */ shell = plain_shell_builder(1, "ticron_rabbit", app); /* Create resource objects */ dbconn = DbConn.new(0, "db_connection", shell); mbconn = MbConn.new(0, "mb_connection", shell); mbconsumer = MbConsumer.new(0, "mb_consumer", shell, mbconn); /* Create the message processing state machine */ machine = StateMachine.new(10, "processor", shell); aesir stdtime paridc table cbase idcdacs domain layer idcdacslog idcpipeline idcrabbit idcstate technical services layer / application framework tis_rabbit tiseg_rabbit tin_rabbit ticron_rabbit tortoise db_rabbit application layer dbconn idcstate::resource mbconn mbconsumer msgstore idcstate::activity mbreader message_builder msgwriter genmsg_builder intvlmsg_builder message cmdmsg sqlmsg intvlmsg idcstate::state state pseudostate activity state_machine resource application_signal event state_impl application shell

The views expressed on this poster are those of the author ...€¦ · RabbitMQ Message Broker Virtual Host Processing Server 1 Operator Workstations Processing Server N. . . Software

  • Upload
    others

  • View
    4

  • Download
    0

Embed Size (px)

Citation preview

Page 1: The views expressed on this poster are those of the author ...€¦ · RabbitMQ Message Broker Virtual Host Processing Server 1 Operator Workstations Processing Server N. . . Software

Angewandte Wissenschaft Software und Technologie (AWST) GmbH, Mariahilfer Str. 47/3/1, A-1060 Vienna, Austria

Telephone: +43-1-5861314 – Facsimile: +43-1-5861314-22 – Email Address: [email protected]

DisclaimerThe views expressed on this poster are those of the

author and do not necessarily reflect the view of the

CTBTO

SnT2015 Poster No. T3.3-P14 IDCDACS: IDC’s Distributed Application Control System ported to Open TechnologiesMartin Ertl1, Alexander Boresch1, Ján Kianička1, Alexander Sudakov2, Elena Tomuta2

(1) Angewandte Wissenschaft Software und Technologie (AWST) GmbH, Vienna, Austria

(2) Comprehensive Nuclear-Test-Ban Treaty Organization (CTBTO), Vienna, Austria

Background

The Distributed Application Control System (DACS) is the

backbone of the automatic processing of seismic, hydro-

acoustic and infrasound (SHI) waveform data at the IDC. It

drives the execution of processing applications by organizing

data into time intervals, processing steps into pipelines, and

using message queues for task scheduling.

Objective

Because licensed software hampers free distribution and

use of IDC software to and by National Data Centres, IDC

aimed at eliminating the dependency on the proprietary Tuxedo

middleware.

Accomplishments

We redesigned the existing system and implemented the new

IDCDACS based on an open-source messaging solution in

combination with existing in-house IDC libraries and a custom-

developed application framework, which together replace

Tuxedo in a robust, reliable and scalable way.

Open Technologies

Our solution utilizes the RabbitMQ high availability message

broker and the Advanced Message Queuing Protocol (AMQP),

an open industry standard and wire-level protocol mandating

that senders and recipients can interoperate irrespective of

their specific implementation.

IDCDACS is flexibly configurable to control different

processing applications and pipeline-like processing workflows,

i.e. it is by design not limited to SHI data processing, which is

the primary use case at the IDC.

Development Approach

The new IDCDACS was implemented using the Scrum agile

development methodology, aligned with evolving requirements

and priorities. The first major Release is running on the IDC

development LAN. Transition to Testbed and Operations

LANs is in progress. Further development will improve

usability, extend features, and lift current limitations.

Message Queue for Task Scheduling

Figure 2: Task Queue decouples Publishing and Consuming Clients. Yields a reliable and robust

system. Permits parallel processing, for load balancing and scaling up.

RabbitMQ Message Broker

Consuming Client 1

Publishing Client

Data Monitor, Tortoise

publish Task Queuerouting Consuming Client 2

Consuming Client N

Consumer 1

Consumer 2

Consumer N

Direct Exchange

Round-robbin dispatch with prefetch=1

consume

consume

consumeConnection + Channel Binding

Connection + Channel

Toirtoise, Database Service

Processing Pipelines and Message Flow

Figure 3: DACS processes (blue) run as daemons and listen on Message Queues (purple).

Scheduler wakes up Data Monitor. Data Monitor checks conditions (data availability, status

information, time, etc.) and creates Time Intervals. Tortoise executes Processing Application (aqua),

reports status to Interval Table, and publishes to next Task Queue. Each Time Interval passes through

all Steps until reaching Done Queue. In case of an error it will be short-circuited into Failed Queue.

Deployment and Distribution

Figure 4: 1 Database, 1 Message Broker, 1-N Processing Servers for

DACS Server Programs and Processing Applications.

ProcessingServer 2

Oracle DatabaseAccount (User)

RabbitMQ Message BrokerVirtual Host

ProcessingServer 1 Operator Workstations

ProcessingServer N

. . .

Software Application Framework

Figure 1: Building blocks for common functionality like main control

loop, exceptions, resource management, transactional messaging,

client-side failover for high-availability cluster.

Analyzable and Maintainable Code

Figure 5: Object-oriented programming style.

/* Create and setup the application object */

app = Application.new(NULL, argc, argv);

/* Create the shell object */

shell = plain_shell_builder(1, "ticron_rabbit", app);

/* Create resource objects */

dbconn = DbConn.new(0, "db_connection", shell);

mbconn = MbConn.new(0, "mb_connection", shell);

mbconsumer = MbConsumer.new(0, "mb_consumer", shell, mbconn);

/* Create the message processing state machine */

machine = StateMachine.new(10, "processor", shell);

aesi

r

std

tim

e

par

idc

tab

le

cbase

gdi

ibase

rabbitmq

third party

idcdacs

domain layer

idcd

acsl

og

idcp

ipel

ine

idcr

ab

bit

idcstate

technical services layer / application framework

tis_

rab

bit

tise

g_

rab

bit

tin

_ra

bb

it

ticr

on

_ra

bb

it

tort

ois

e

db

_ra

bb

it

application layer

dbconn

idcstate::resource

mbconn

mbconsumer

msgstore

idcstate::activity

mbreader

message_builder

msgwriter

genmsg_builder

intvlmsg_builder

message

cmdmsg

sqlmsg

intvlmsg

idcstate::state

state

pseudostate

activity

state_machine

resource

application_signal

event

state_impl

application

shell