ultra messaging® technical product overview - blog...
TRANSCRIPT
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