1 / 28

Controls Middleware renovation – technical overview 26th June 201 3

Controls Middleware renovation – technical overview 26th June 201 3. Wojciech Sliwinski BE-CO-IN for the BE-CO Middleware team: Felix Ehm, Kris Kostro, Joel Lauener, Radoslaw Orecki, Ilia Yastrebov , [Andrzej Dworak] Special thanks to : Vito Baggiolini and Pierre Charrue. Agenda.

fayre
Download Presentation

Controls Middleware renovation – technical overview 26th June 201 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Controls Middleware renovation –technicaloverview26thJune 2013 Wojciech SliwinskiBE-CO-IN for the BE-CO Middleware team: • Felix Ehm, Kris Kostro, Joel Lauener, • Radoslaw Orecki, Ilia Yastrebov, [Andrzej Dworak] • Special thanks to: Vito Baggiolini and Pierre Charrue

  2. Agenda • Context & Motivation for Renovation • Middleware Reviewprocess • Technical evaluation of the transport layer • Changes in the MW Architecture in LS1 • MW Upgrade milestones in 2013 • Conclusions

  3. Agenda Context & Motivation for Renovation

  4. Motivations for MW Renovation • Current CORBA-based CMW-RDA • Integrated in the Control system • Used to operate all CERN accelerators • Provides widely accepted Device/Property model • > 10 years old • Why to review & upgrade MW ? • CORBA was choosen15 years ago • Technical limitations of CORBA-based transport • Functional limitations of the current CMW-RDA • Codebase with long history difficult to maintain, needs architecture review • Major issue of long-term support & future evolution • Evolution of technology over last 10 years: HW, OS, middleware, 3rd party libraries • Human factor  less & less CORBA expertise on the market

  5. Technical limitations of CORBA transport • Became legacy, not actively supported  maintenance issue • Shrinkingcommunity, slowresponsetime • omniORB (C++) – 1 developer/maintainer, lastrelease mid-2011 • JacORB (Java) – fewdevelopers, small community • Major technical limitations • Lack of fullyasynchronousprocessing channel • Blockingcommunication infamous JacORB blockingissue • Lack of low-level control of IO resources (sockets, requestqueues) • Development issues • Difficult to extend the wireprotocol Backward compatibility issue • Complex, error prone API • Heavy in memoryusage

  6. Summary: Whychange CORBA? • CORBA was choosen15 years ago • Not activelymaintained big risk for the MW project • Bettersolutionsexist on the market • Invest in futuresolutionratherthanmaintainingold one • With current CORBA-basedmiddlewarewe can’tsolvethe pendingoperationalissues • We can’tprovidebetterscalability & reliability • CMW-RDA isdifficult to evolve& extend

  7. Agenda Middleware Reviewprocess

  8. Middleware Renovationprocess • MW Renovation = MW Review + MW Upgrade • MW Review aims to provide the most appropriate technical solution satisfying theuser requirements • MW Upgrade establishes the plan & strategy for introductionof the new MW • Objective: LS1 the uniqueopportunityfor the major MW upgrade • Middleware Review Process • Gathering of users feedback and requirements (2010-11) • Review of communication and serialization libraries (2011-12) • Prototyping using selected communication products (2012) • Design & impl. of new RDA3: Data, Client & Server (2012-13) • Testing & validation of core MW infrastructure (summer’13) • Upgrade of all dependent MW libraries & services (2013-14) • JAPC, Directory Service, Proxy, DIP Gateway

  9. Review of usersrequirements • 2010-11 – series of interviews with major users • Lars Jensen, Stephen Jackson (BI) • Andy Butterworth, Frode Weierud, Roman Sorokoletov (RF) • Brice Copy, Clara Gaspar (DIP, DIM) • Frederic Bernard,Herve Milcent, Alexander Egorov (PVSS) • Alexey Dubrovskiy (CTF), Kris Kostro (DIP gateways) • Marine Gourber-Pace, Nicolas Hoibian (Logging) • Nicolas De Metz-Noblat (Front-Ends), Alastair Bland (Infrastructure) • Michel Arruat (FESA), Stephen Page (FGC) • Niall Stapley, Mark Buttner, Marek Misiowiec (LASER & DIAMON) • Nicolas Magnin, Christophe Chanavat (ABT) • Stephane Deghaye, Jakub Wozniak (InCA, SIS) • Vito Baggiolini, Roman Gorbonosov (JAPC & DA systems) • + regularfeedback from OP • + internalteam input • http://wikis/display/MW/Interviews+with+Experts

  10. New RDA3: Acceptedrequirements New requirement • General • Java & C++ API, Win (64-bit) & Linux (SLC5 32-bit & SLC6 64-bit) • Accelerator Device Model (i.e. Device/Property) • Get, Set, Async-Get, Async-Set, Subscribe • Early detection of communication failures • Improve error reporting in all the layers: client, server, gateways • Admin interface & runtime diagnostics & statistics • Data support • Data object: primitives, n-dim arrays, data structures • Subscription mechanism • Subscription behaviour the same regardless condition of the server (active, down) • Several client subscription policies (default: continuous) • Providesubscription notification ordering • First-Update enforced via CMW on server-side • Providecallback to front-end framework for the server-side Get • Drop support for on-change flag • Standardise use of subscription filtersand updateflags (e.g. immediate update) • Addheader for acquiredDatacommonmetadata (e.g. acq. stamp, cyclename) • Allloss of data (droppedupdates) must be notified to clients

  11. New RDA3: Acceptedrequirements New requirement • Client side • RDA3 client API connects with both: RDA2 (old) & RDA3 (new) servers • Efficientmechanism for: connection, disconnection & reconnection • Must be able to recover from anyinterruption of communication with the server • Server restarts, IP addresschange, rename/move of a device to anotherserver • Improvedsemantics of ArrayCalls, i.e. handling of individualparameters • Enhanced diagnostics & collection of statistics • Server side • Policies for discarding notifications, i.e. deal with overflowsand ’badclients’ • Instrument with counters & timingsallowing to diagnose the notificationsdelivery • Prioritisation of Get/Setrequests for high-priorityclients • Server-side subscription tree fully managed by CMW • Server does not need to manageclientsubscriptionsanymore • Manage the clientconnections, e.g. forceddisconnect of a client • Client lifetime callbacks (i.e. connected, disconnected)

  12. New RDA3: Acceptedrequirements New requirement • Server side (cont.) • Client discovery for the diagnostics purposes (i.e. connectedclients with payload) • Enhanced diagnostics & collection of statistics • Ongoingdiscussions (not acceptedyet) • Prioritisation of subscription notifications for high-priorityclients • Technical notes • Invest in asynchronous & non-blocking communication • Prefer0-copy & lock-free data structures, message queues • http://wikis/display/MW/Design+of+New+RDA

  13. New RDA3: Summary of requirements • Unchanged • Device/Property model • Set of basicoperations (Get, Set, Subscribe) • Fixes & improvements • Subscription mechanism • Connection management • Diagnostics & statistics • New functionality • Policies for subscription management (client & server) • Client priorities • Server-sidesubscriptiontree • Extended Datasupport • StandardiseFirst-Updateconcept

  14. Agenda Technical evaluation of the transport layer

  15. Middleware transport requirements Desirable • Lightweight • Friendly API, documentation • Request/reply & pub/sub patterns • Asynchronous • Performance & Scalability • Stability, Maturity & Longevity Mandatory • Active community • Open source license • C++/Java • Linux/Windows • Over TCP/IP LAN Fundamental

  16. Evaluated middleware products All opinions are based only on our knowledge and evaluation. Each of the products, depending on the requirements, may constitute a good solution. OpenAMQ CoreDX RTI DDS QPid ZeroMQ OpenSpliceDDS RabbitMQ YAMI Ice omniORB MQtt RSMB JacORB Thrift Mosquito Andrzej Dworak, ICALEPCS 2011

  17. Products comparison (according to the criteria) Andrzej Dworak, ICALEPCS 2011

  18. Conclusions • Several good middleware solutions available • The choice is dictated by the most critical requirements • Not easy performance matters but also ease of use, community, … • Prototyping was done with the most promising candidates: • ZeroMQ, Ice& YAMI • Finally we decided to chooseZeroMQ (http://www.zeromq.org/) • Asynchronous & non-blocking communication • 0-copy& lock-free data structures, message queues • Nice API, gooddocumentation & activecommunity

  19. New RDA3 Java – Sync Get round-triptime Test setup: 1kB messagepayload, cs-ccr-* machines, 1 server host & 10 clienthosts

  20. New RDA3 Java – subscriptionnotificationlatency Test setup: 1kB messagepayload, cs-ccr-* machines, 1 server host & 10 clienthosts

  21. New RDA3 Java – subscriptionnotificationlatency Test setup: 1kB messagepayload, cs-ccr-* machines, 1 server host & 10 clienthosts

  22. Agenda Changes in the MW Architecture in LS1

  23. Current MW Architecture User written Middleware Java Control Programs Central services VB, Excel, LabView C++ Programs Administration console JAPC API Passerelle C++ Clients RDA Client API (C++/Java) Device/Property Model Directory Service Directory Service RBAC A1 Service RBAC Service Configuration Database CCDB CMW Infrastructure CORBA-IIOP RDA Server API (C++/Java) Device/Property Model CMW integr. CMW int. CMW int. CMW int. CMW int. CMW int. Servers Virtual Devices (Java) FESA Server FGC Server PS-GM Server PVSS Gateway More Servers Physical Devices (BI, BT, CRYO, COLL, QPS, PC, RF, VAC, …)

  24. User written Changes in MW Architecture in LS1 Middleware Central services Java Control Programs Upgrade in LS1 VB, Excel, LabView C++ Programs Administration console JAPC API Passerelle C++ Clients RDA Client API (C++/Java) Device/Property Model Directory Service Directory Service RBAC A1 Service RBAC Service Configuration Database CCDB CMW Infrastructure ZeroMQ RDA Server API (C++/Java) Device/Property Model CMW integr. CMW int. CMW int. CMW int. CMW int. CMW int. Servers Virtual Devices (Java) FESA Server FGC Server PS-GM Server PVSS Gateway More Servers Physical Devices (BI, BT, CRYO, COLL, QPS, PC, RF, VAC, …)

  25. Agenda MW Upgrade milestonesin 2013

  26. MW Upgrade Milestones in 2013 July’13 July-Oct’13 September’13 December’13 Winter’13/14 August’14 End-of-Life for RDA2: LS2

  27. MW Upgrade strategy in LS1 and towards LS2 • No BIG-BANG migration but gradual • Backward compatible (connection-wise)newRDA3 client library • New RDA3 clients can communicatewith RDA2 & RDA3 servers • FESA3 willexist with both: old RDA2 (FESA3.1) and new RDA3 (FESA3.2) Client appswillmigrateduring LS1 Only for justified, exceptionalcases OldJAPC New JAPC RDA2  RDA3 Gateway Old RDA2client New RDA3client Old RDA2 server Old RDA2 server FEC developersshouldmigrate to FESA3.2 ASAP New RDA3 server FESA2.10 FESA3.1 FESA3.2

  28. Conclusions • We haveto replace CORBA with a newsolution • We collectedupdatedusersrequirements • MW upgradewill be performedduring LS1 (2013-2014) • Interoperabilitybetween RDA2  RDA3 • Gradualcontrol system migrationuntilLS2 (end-2017) • End-of-Life for RDA2: LS2

More Related