ultra messaging® technical product overview - blog...

1 1

Ultra Messaging® Technical Product Overview

2 2

Overview

What is messaging? Tibco RV, Tibco EMS, IBM MQ, ActiveMQ, MSMQ, etc.

Overview of Ultra Messaging®

• Future Proof Design for the Enterprise

• Parallel Persistence

• Queuing

• Load Balancing

• Caching

• LAN/WAN Bridging & Desktop Fan-out

• Extending UM over the Web

• Management

• Monitoring

3 3

How to move data from A to B?

4 4 4

Legacy Server-Based Designs

Application A

Comm Library

Network

App Network

App Network

App

TCP TCP

Sending CPU Receiving CPU

Messaging

Server CPU

Network

Application B

Comm Library

Message Server CPU is a performance bottleneck

TCP doesn’t scale, delivery not ―fair‖

Message

Router

4

5 5 5

Legacy Daemon-Based Design

Application A

Comm Library

Local

Daemon

Sending CPU Receiving CPU

Local

Daemon

Application B

Comm Library

LAN

NAK storm problems Crybaby receiver problems

More daemons required for receivers on other LANs

5

TCP Loopback

UDP Reliable Multicast

TCP Loopback

6 6 6

Messaging Choke Points

6

Server-Based Designs

Daemon-Based Designs

7 7

Legacy Designs

• Choke Points

• Messages must move through central servers or brokers

• Local daemons slow delivery by introducing overhead

• Scalability Issues

• Servers and brokers can only handle so much load

• Made worse by aggregating all of the message traffic through the points

• Single points of failure

• Failure of a server or broker can cripple the entire message system

8 8

• EMS (Enterprise Message Service)

• Server based design

• API’s: JMS, C, .NET, Cobol, Java

• UM Lead: more efficient (cut infrastructure cost), reliable (uptime), more scalable (grow)

• Rendezvous (original pub/sub)

• Legacy daemon based design (RVRD)

• API’s C, C++, C#, Java, Perl, COM

• UM Lead: more efficient, more functional, more reliable, future life

• Smart Sockets (acquired through Talarian)

• Legacy daemon based design for pragmatic multicasting (PGM)

• Proprietary (EOL)

• UM Lead: more efficient, more functional, more reliable, future life

• FTL (Faster Than LBM??)

• Modern nothing in the middle type design (stated copy!)

• RV compatibility stated / announced

• UM Lead: 6 years behind UM, more functionality (persistence, queuing, etc.), more proven, more open

(less re-write)

9 9

• webSphere MQ (original queuing)

• Legacy server design, very functional, very robust

• API’s: JMS, C, .NET, Cobol…

• UM Lead: lower costs, more efficient & flexible, easier to use

• webSphere MQ LLM

• Modern nothing in the middle design

• API’s: MQ, JMS, RV,

• UM Lead: proven (production references), easier to use

11 11

Ultra Messaging® Design and UMS

12 12 12

The Nothing in the Middle Design: No Brokers or Daemons Required

Topic-based Addressing

Choice of reliable and scalable transport mechanisms

12

Application A

UM Library

Kernel User

Kernel User

Message Flow

Reliable Multicast, Reliable Unicast, or TCP

Sending CPU Receiving CPU

Network

Application B

UM Library

➀ ➁

Cross-platform C, C# / .NET, and JAVA APIs with JMS support

13 13

Ultra Messaging – Key Facts

• Single API for Streaming,

Persistence/Guaranteed Delivery, and

Queuing/Load Balancing

• Out-of-the-box support for TCP, Reliable Unicast,

Reliable Multicast, and IPC/Shared Memory

• Native Infiniband and RDMA

• C, Java, and .Net APIs plus JMS Support

14 14

Our Reliable Multicast Approach is Different

• Reliable multicast has historically been considered unstable

• Prone to NAK storms

• Retransmission storms can seriously impact network performance by reducing available bandwidth

• Ultra Messaging’s proprietary reliable multicast

implementation solves these issues entirely in user space,

requiring no special permissions, modules or hardware.

• Control network behavior

• Allocate bandwidth for specific traffic like retransmissions

• Maintain network stability

15 15

Our Reliable Multicast Maintains Control

• Retransmission rate controls and NAK ignore, back-off and

suppression algorithms ensure stable behavior.

• UM multicast design doesn’t get tripped up by a consumer that cannot keep up

• If a consumer cannot keep up, it experiences loss

• Other consumers which are able to keep up are not impacted

• UM controls the amount of bandwidth allocated to retransmissions resulting in stable and predictable network behavior

• Configurable limits can also be set on transmission bandwidth

• Publishers sending too much within a short interval have a choice of waiting for bandwidth or having send requests fail (allowing for conflation and similar strategies)

• UM maintains network stability with all of the advantages

provided by multicasting

16 16

• Sub 500 nanosecond latency

• Transparent to applications

• Change configuration, not code

• Publishers choose transport

mechanism on per-topic basis

• Subscribers automatically use

publishers’ chosen transport

• All semantics and QoS supported

• Streaming, guaranteed delivery and queued / load-balanced delivery

• Supported using the same API as all other transports

• Optional receiver pacing

Inter-Process Communication Transport

19 19

Adding Guaranteed Delivery / Persistence

UMP

20 20

Persistence/Guaranteed Delivery

Many use cases require message delivery even in cases of

hard failures in the sending and receiving applications

Ultra Messaging offers Persistence for Guaranteed Delivery,

Durable Subscription & Late Join of message streams,

regardless of message format, content or meaning

Not to be confused with Caching which is content-aware

processing / transformation, storage and retrieval of data

Parallel Persistence®

Ultra Messaging’s breakthrough persistence architecture

provides an order of magnitude reduction in latency and a

substantial increase in throughput over competing solutions

21 21 21

Legacy: Persistence with a Central Server

21

Persistent

Storage

Application A

Comm Library

Application B

Comm Library

Message

Router

Sending CPU Receiving CPU Messaging

Server CPU

Store and Forward Messages do not continue receivers until stored

Speed of the system is no more than the speed of the store

22 22 22

Next Generation Architecture: Parallel Persistence®

22

Application A

UM Library

Application B

UM Library

Ultra Messaging

Persistent Store

Persistent

Storage

Sending CPU Receiving CPU Persistent Store CPU

TCP, UDP Reliable Multicast, or UDP Reliable Unicast

No delays added by Parallel Persistence® Messages move to receivers at full speed

Speed of the store no longer impacts message delivery speed

23 23

Key Design Advantages

• Decoupled persistence and delivery functions

• Industry leading performance

• Determinism for latency and throughput on commodity hardware

• Applications are not delayed by using persistence

• Unique high availability LAN and WAN configurations provide zero latency failover

• Eliminates the need for specialized servers or expensive SANs

• Flexible implementation offers choice of transports and QoS on a per topic basis

24 24

Adding Queuing Semantics: Once and Only Once Delivery plus Load Balancing

UMQ

25 25

UMQ Overview

• Adding queuing semantics to UM environment

• Low latency capable receivers can receive messages at top

speed

• Slower receivers can receive messages in order / without loss

even if they cannot keep up with raw message flow

• Source / receiver decoupling

• Data persistence / resiliency

• Load Balancing

• Indexed Queuing

• Allows consistent processing of related messages through a

queue.

26 26

UMQ Semantics and Features

• Once And Only Once delivery (OAOO)

• Sources / Receivers • Decoupled

• Queue or mailbox abstraction

• Allows connection of low latency messaging with slower receivers

without impacting low latency messages

• Both can automatically discover queues

• Sources

• Multiple source and topics can send to same Queue

• Simultaneously send to Queues as well as UMS and UMP receivers

• Receivers

• Multiple receivers for individual messages

• Application sets – under receiver control

• Innovative Capabilities • Application Sets

• Indexed Queuing

27 27

UMQ High Level Components

Source Queue

Instance Queue

Instance Queue

Instance

Data and ACK Data and ACK

Sources submit messages

Queue Instances persist and assign messages;

multiple queue instances provide resilience

Receivers consume messages from the queues;

multiple receiver instances provide receiver resilience

and scalability

Receiver

Receiver

Receiver

Ap

plic

atio

n S

et A

Receiver

Receiver

Receiver

Applic

ation

Set

B

28 28

UMQ Application Sets

• Both Application Sets read from a single queue – each app set gets the message OAOO

• Much simpler Trade Capture app – sends only to a single queue

• Greatly improved failure resilience – offload resilience support to UMQ

• Messages in the queue get delivered even if sending application fails

2

8

28

Persistence is per-trade

and per-application

Settlement

App Set Settlement

Server 1

Settlement

Server 2

Settlement

Server 3

Reporting

App Set Reporting

Server 1

Reporting

Server 2

Trade

Capture

Read

Read

X Read

Read

29 29

Using Ultra Messaging Indexed Queuing for Exchange Connectivity

• Cancel index=2 follows Order index=2 with

indexed queuing even though Server 1 is Next

• Only one queue shown, but failure-resilient

backup queues are easily configured

2

9

29

Next

Next

Order

Queue

DB 1

DB 2 Server 2

Server 1

Exchange 1

Exchange 2

Orders

Orders

Cancel 2

Order 2

Order 1

30 30

Ultra Load Balancing (ULB)

• Ultra-low latency load balancing

• Load balancing done at the source with nothing

in the middle—brokerless queuing

• Per-source queuing, not shared-source queuing

• Indexed queuing

• Messages held in volatile storage at the source

• Faster load balancing

3

0

30

31 31

Indexed Load Balancing

• Establishes subscriber process affinity based on application

supplied Index

• Subsequent messages containing this index are routed to the

same subscriber within a load balanced application set

• Ideally suited for routing of Modify/Cancel Orders to an

Exchange Gateway Instance

• Can be used to insulate Order level acknowledgements from

costly database lookups

• Available in both brokered and brokerless (ULB)

configurations

32 32

JMS Support

• Broker-less design tightly integrated with UM

• Interoperability with all of Ultra Messaging

• Allow JMS-based applications to receive and send

messages on a UM backbone

• JMS attributes and properties become UM application headers

• JMS payloads map directly to UM payloads

• Supports send / receive using native C, .NET, or JAVA

APIs

3

2

32

33 33

JMS Support

• Allows other applications to leverage the UM

message bus

• 3rd party applications can access to UM message flow

• Integration with other Informatica applications such as PowerCenter and CEP for example

• Compatible with 1.0 and 1.1 JMS specs

• Except XA transactions

• Bundled with UMQ

• Shipping now

3

3

33

34 34

Caching using UMCache

35 35

Ultra Messaging Cache

• Receives, processes, indexes, stores and in some

cases republishes messages, providing:

• Conflation or merger of data streams

• Delayed market data

• Content-based routing

• Bridging between messaging systems

• Out-of-the-box capabilities

• High speed archival and replay

• Snapshot requests i.e. Last Value Cache

3

5

35

36 36

Caching Architecture

• Framework-based plugin architecture supports customization

and extension

• We provide pre-built modules (with source) for last value

caching and archival and replay at multiples of original rate

3

6

36

Command and Control Module

Reception

Module

Processing

Modules

PROC 1

PROC 2

PROC 3

Indexing Modules

Storage

Module

IDX 1

Client Requests

Utility

Module

IDX 2

37 37

Ultra Messaging Cache Use Cases

Besides the common use cases (replay and LVC server) …

• Conversion of TCP/UDP connections to UMS topics

• Conversion of Tibco topic streams to/from UM

• High speed ingest (topics) into a database

• Data Translation of messages on a topic

3

7

37

38 38

Reaching Unmanaged Consumers using UMDS

39 39

UMDS - Desktop Connectivity for Data Center Services

• Pure Java, fully managed .Net assemblies

• Only requires single TCP connection for all traffic

• Server in data center provides desktop connectivity

• User authentication

3

9

39

UMDS Server

UMDS Client Library

Client Application

Desktop Desktop

TCP TCP Uncontrolled Infrastructure

Controlled Infrastructure

Ultra Messaging Backbone

… UMDS Client Library

Client Application

UMDS Server UMDS Server

40 40

UMDS 1.1

• Proxy sources created in UMDS server at

request of UMDS clients

• Server retains control over source configuration

• Topic queues per client

• Dedicated space per topic stream

• Per-topic conflation of streams for slow consumers

• Late join in both UM source and in server cache

• XML Configuration per topic (like UM XML

config)

4

0

40

41 41

Extending UM over the Web with UMWeb

42 42

Extending Messaging to the Web

42

WANs

Intranets

Your

Firewall

Their

Firewall

DMZ

WebSocket Gateway

Mobile Clients

Browser Clients

Proxy

Server

OS Native Applications Web Applications

UMWeb

Bridges

the Gap

Web Applications

43 43

Bridging Network or Application Domains with the UM Gateway

44 44

Ultra Messaging Gateway

• Ultra Messaging Gateways extend the usage of UM:

• Enable transparent bridging of network or application domains

• Preserves all Ultra Messaging semantics

• Maintains all qualities of service

• Capabilities include:

• Subscription-based forwarding, driven by receiver interest

• Per-topic or wildcard permit/deny policies

• Bi-directional and multi-hop forwarding

• Single TCP “tunnel” connection between Gateways

• Tunnel compression, encryption and encapsulation

• Highly available configurations (master/slave, multiple paths)

• Comprehensive monitoring via published statistics and web interface

45 45

Ultra Messaging Gateway

• Filters and forwards traffic between topic resolution domains

• Now with multi-hop, failure resilience, wildcard receivers, request/response forwarding and more

• Applications

• Relay production traffic to development but block return traffic

• Selectively forward topics based on policy

• Connectivity between IPC and network resolution domains

45

46 46

Sending

Process

UM Library

IPC Local & Remote Receivers using the Gateway

46

UM Gateway

Process

Receiving

Process

UM Library

User

Kernel

Network

Message Flow to Processes on Other Machines

47 47

Ultra Messaging Manager - UMM

48 48

Ultra Messaging Manager

• The next step up for our management and

configuration capabilities

• Ultra Messaging has always been highly

configurable and controllable but now it is easier

to manage

• GUI configuration view

• Ease of setting options

• Ability to apply security, templates, change management to configuration

• Ease of distribution of configurations

49 49

UMM Overview

• Ultra Messaging Manager GUI

• This is what the UM administrator “sees” and interacts with

• Provides a GUI configuration and management interface for UM

• Provides Management of UM Networks

• Distributed configuration of UM senders/receivers

• User / application authentication

• Auditing and capture of configuration changes

• Eliminates the need for manual configuration file editing

• Supports transport-level configuration

• UMP ands UMQ stores and queues coming in future releases

• Detects and notifies of common misconfiguration errors

• Supports templates and policies for consistent configuration

• Distributed as part of UMP

50 50

UMM – Technical Architecture

51 51

UMM GUI

52 52

UMM—Templates

• Allows setting default options that applications

can override

• Enables setting option policies that applications cannot override

• Multiple templates can be applied hierarchically

52

53 53

UMM—Receiver Configuration

53

54 54

UMM—Source Configuration

54

55 55

Monitoring & Management

56 56

Ultra Messaging Monitoring Overview

• Applications can self-monitor transport metrics through the API, including how long messages spend in the API and how long the application spends processing them

• Automatic monitoring to publish metrics to the network, sample code provided to receive, collect and display

• SNMP agent available for use with any SNMP compliant management station (e.g. InterMapper, HP OpenView, etc.) for centralized monitoring

• Wireshark dissectors for packet level inspection

• Partner with firms such as Correlix, Corvil, ITRS for passive latency monitoring and dashboard views

57 57

Measuring Latency and Monitoring Possible Causes

• Ultra Messaging SNMP Agent

• Bring messaging, OS, and network statistics together for

possible correlation

• Geneos, Intermapper probes, Solarwinds, OpenNMS

• Interesting Statistics

• LBT-RM Receiver

• Out_of_order: Count of datagrams that fill a gap but are not retransmissions

• Dgrams_dropped_*: Count of datagrams dropped and why

• Event Queues

• Min/Mean/Max service times (how long callback ran in microseconds)

• Min/Mean/Max event age when dequeued (how long event was queued)

58 58

Questions?

• Topic Resolution

59 59