Transcript
Page 1: Don't Architect a Real-Time System that Can't Scale

Your systems. Working as one.

Architect Scalable Real-Time Systems

David Barnett

Page 2: Don't Architect a Real-Time System that Can't Scale

About RTI

• World leader in communications software for real-time systems– 350,000+ deployed copies– 500+ unique designs

• Standards leader– Participate in 15+ standards

organizations– Authored DDS (OMG)

Page 3: Don't Architect a Real-Time System that Can't Scale

Real-Time Systems

Page 4: Don't Architect a Real-Time System that Can't Scale

Characteristics of Real-Time Systems

• Time sensitive• Low latency• High throughput• Non-stop availability• Dynamic, ad hoc• Autonomous, no sys admin• Components run outside

data center– Decentralized– Processing distributed– Few or no central servers– Embedded, resource constrained– Disadvantaged networks

Page 5: Don't Architect a Real-Time System that Can't Scale

Challenge: Increasing Scale

• More CPUs, nodes, apps, data, orgs, developers…

• Systems of systems

System of systems

Existing architectures and infrastructure break under the load

Page 6: Don't Architect a Real-Time System that Can't Scale

Traditional Integration

• Point-to-point• Custom, e.g., using sockets• RPC, RMI

• Complex• Costly – O(n2)• Poor reuse• Limits information

sharing

Page 7: Don't Architect a Real-Time System that Can't Scale

Cost Constrains Integration

Time & cost of integration,

maintenance and upgrades

System Scale and Age

Page 8: Don't Architect a Real-Time System that Can't Scale

Six Keys to Scalability

Page 9: Don't Architect a Real-Time System that Can't Scale

1. Publish/Subscribe

• Simplifies integration – O(n) • Improves information sharing

Bus

Sensor

Sens

or D

ata

Sens

or D

ata

Control App

Com

man

ds

Stat

us

Sensor

Sens

or D

ata

Actuator

Com

man

ds

Stat

us

Display App

Sens

or D

ata

Stat

us

Page 10: Don't Architect a Real-Time System that Can't Scale

2. Explicit, Well-Defined Data Model

Page 11: Don't Architect a Real-Time System that Can't Scale

3. Maintain State in Infrastructure

• External to applications• System-wide single version of truth• Temporal decoupling• Simplifies system development and integration• Essential for robust, dynamic systems

Source(Key)

LatitudeLongitud

eAltitude

RADAR1 37.4 -122.0 500.0

UAV2 40.7 -74.0 250.0

LPD3 50.2 -0.7 0.0

Page 12: Don't Architect a Real-Time System that Can't Scale

Message Message

Data Centric

• Infrastructure manages data and lifecycle

• Standard data operations (CRUD)• Automatic state synchronization

when applications join• Robust, scalable

• Applications must manage data• Application layer protocol required for

lifecycle management• State synchronization requires persisting

every message or application protocol• Brittle, inefficient

Source(Key)

Latitude Longitude Altitude

RADAR1 37.4 -122.0 500.0

UAV2 40.7 -74.0 250.0

LPD3 50.2 -0.7 0.0

Application

Create UpdateRead Delete

Src=RADAR1Msg=Create

X=37.4Y=37.4Z=500

Src=RADAR1Msg=Update

X=37.4Y=37.4

ReceiveSend

Application Logic

Message Centric

Page 13: Don't Architect a Real-Time System that Can't Scale

4. Explicit Quality of Service Contracts

Bus

Sensor

Sens

or D

ata

Sens

or D

ata

Control App

Com

man

ds

Stat

us

Sensor

Sens

or D

ata

Actuator

Com

man

ds

Stat

us

Display App

Sens

or D

ata

Stat

us

Reliable 1000 Hz primary

Reliable 1000 Hz backup

Reliable100 Hz

Best effort 1 Hz

Reliable100 Hz

Page 14: Don't Architect a Real-Time System that Can't Scale

Sample Real-Time QoS

• Volatility– Durability– History– Lifespan

• Delivery– Reliability– Time based filter– Content filter– Deadline

• High availability– Liveliness– Ownership– Ownership strength

Page 15: Don't Architect a Real-Time System that Can't Scale

5. Govern Interactions with Middleware

• Instantiates data model• Provides

– Syntactic interoperability– Discovery– Access control

• Independent of:– Programming language– Operating system– CPU type– Physical location– Transport protocol– Network type

Modular, Loosely Coupled Services

Bus

Evolvable, interoperable,shareable, swappable, reusable

Page 16: Don't Architect a Real-Time System that Can't Scale

Example: Data Distribution Service

• Standard means to define data– IDL, XML, dynamically via API– Generated from UML

• Wire protocol for interoperability

• API for portability

Real-Time Publish-Subscribe

Wire Protocol (RTPS)

Middleware

DDS API

Portability

InteroperabilityRTPS also standardized as IEC 61148

Data def’n

Page 17: Don't Architect a Real-Time System that Can't Scale

6. Decentralized Physical Architecture

• No central ESBs, brokers, database or servers• Peer-to-peer communication

– Components, services, applications, devices, subsystems, systems

• Bus is virtual

Network

Page 18: Don't Architect a Real-Time System that Can't Scale

Comparison

• Server-based• Administration heavy• Assume high-bandwidth, reliable

network (TCP)• Poor latency, scalability• Slow failover

• Library only, easy to embed• Low latency; good determinism• Highly scalable• No single point of failure:

non stop availability‑

Centralized: Traditional ITDecentralized: Real Time

Page 19: Don't Architect a Real-Time System that Can't Scale

Relative JMS Performance

0 25,000 50,000 75,000 100,000

JBoss

Sun

ActiveMQ

Sonic

Tibco

RTI

1 KB Messages per Second

Page 20: Don't Architect a Real-Time System that Can't Scale

P2P Publish/Subscribe over Multicast

Minimizes:• CPU overhead• Network overhead• Latency• Determinism

Publisher

Subscriber SubscriberSubscriber

Switch• Replication• Filtering

Page 21: Don't Architect a Real-Time System that Can't Scale

Multicast Scalability

0 100 200 300 400 500 600 700 800 900 1,0000

100,000

200,000

300,000

400,000

500,000

600,000

Gigabit Ethernet

Subscribers

Mes

sage

s pe

r Sec

ond

Page 22: Don't Architect a Real-Time System that Can't Scale

Summary:Architecting Scalable Real-Time Systems

1. Publish/subscribe2. Explicit data model3. Maintain state in infrastructure4. Explicit QoS contracts5. Govern interactions with middleware6. Decentralized physical architecture

Page 23: Don't Architect a Real-Time System that Can't Scale

RTI’s Solution

RTI DataBus™

ConnextMicro

Pub/Sub API(DDS subset)

Small Device Apps

ConnextDDS

Pub/Sub API(Full DDS)

DDS Apps

ConnextMessaging

Messaging API(DDS++ & JMS)

General-Purpose Real-Time Apps

ConnextIntegrator

Adapters

DiscreteApps/Systems

Administration

Monitoring

Logging

Recording

Replay

Federation

Transformation

PersistenceVisualization

Common Tools and Infrastructure Services

Page 24: Don't Architect a Real-Time System that Can't Scale

Designed for Real-Time Systems

• Fully embeddable– Applications are self-contained– Deterministic resource utilization– Support embedded and real-time OS– C, C++, C#, Java and Ada APIs; no Java dependence

• Autonomous operation– Plug-and-play via automatic discovery– No sys admin– Supports highly dynamic and ad hoc systems– Self healing

• Real-time Quality of Service (QoS)– Control and visibility over timing and resources– Built-in filtering by time and content

• Disadvantaged network support– E.g.: wireless, radio, satellite, WAN– No TCP or IP dependence

Page 25: Don't Architect a Real-Time System that Can't Scale

Learn More

• Contact RTI• Downloads

– www.rti.com/downloads– Interactive “Shapes” demo– Free trial with comprehensive

tutorial– Free licenses for internally-funded

IR&D• Videos, webinars and whitepaper

– www.rti.com/resources

Page 26: Don't Architect a Real-Time System that Can't Scale

DownloadConnextFree TrialNOW

www.rti.com/downloads

Page 27: Don't Architect a Real-Time System that Can't Scale

Thank You!


Recommended