1 / 51

PeerDirect Distributed Enterprise

PeerDirect Distributed Enterprise. J. Espen Stokke alias “Curt…” Professional Services Manager. PeerDirect Distributed Enterprise. Agenda. Introduction to Database Replication Architecture Overview Configuration Replication Rule Design. Introduction to Database Replication . What if….

zlata
Download Presentation

PeerDirect Distributed Enterprise

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. PeerDirect Distributed Enterprise J. Espen Stokke alias “Curt…” Professional Services Manager

  2. PeerDirect Distributed Enterprise Agenda • Introduction to Database Replication • Architecture Overview • Configuration • Replication Rule Design

  3. Introduction to Database Replication What if… • Remote offices could benefit from local application performance, no matter where they are located? • Corporate data could automatically synchronize across the enterprise? • Your eBusiness infrastructure was infinitely scalable? • Remote users could update central databases when they are on the road?

  4. Introduction to Database Replication Remote Offices Corporate Data Center How to Remote Restore? Data Center Peak Performance Latency Restricted Data Access Remote Users Remote Failover Linking Systems Network Bandwidth and Outages Solve Common Expensive Problems . . .

  5. Integration - Multiple Production Site No Designated Master Bi-directional & Heterogeneous Two Way Update anywhere, propagate everywhere Duplication - Single Production Site Designated Master Copy Source to Target(s) One Way Data Modifications only allowed at Source Introduction to Database Replication

  6. Introduction to Database Replication Replication uses • Back-up • Fail-over • Latency avoidance • Load balancing • Reporting • Distributed environments • Consolidation • Synchronisation

  7. Introduction to Database Replication Approaches • Log based (AI, Progress to Progress) • Database activity logged for periodic ‘replay’ at all locations • Queue based (SonicMQ, Any to Any) • Middleware intercepts application to database activity for periodic replay at all locations • Table based (PeerDirect, Any to Any) • Captures changes, queries source and duplicates values at all locations

  8. Introduction to Database Replication Drawbacks of each approach • Log based • Log size • Can not remain dormant (sleeping) long • Periodically need to re-synch • Inefficient use of bandwidth • Typically only hub and spoke topology • Queue based • All of the above • Application must be modified • Table based • Not real-time • Increases database size

  9. PeerDirect Distributed Enterprise Agenda • Introduction to Database Replication • Architecture Overview • Configuration • Replication Rule Design

  10. Architecture Overview Order Processing Site A Production OLTP Order Processing Site B Order Processing Site C Production OLTP Production OLTP Distributed DBMS Management Features and benefits Feature Benefit • Bi-directional update-everywhere model • Read-write data between multiple databases • Replicate, synchronize, and distribute corporate data across multiple locations

  11. Architecture Overview Features and benefits Feature Benefit • Scheduled synchronization • Net change compression • Strong encryption • Subset data using ‘slices’ • Maximize network efficiency, reduce costs • Security • Controlled access to data

  12. Architecture Overview Features and benefits Feature Benefit • Replicates between different database types • MS SQL Server and Progress • Oracle and Progress • Supported databases • Progress • Oracle • SQL Server • DB2 • Share data in mixed environments • Consolidated view of corporate data

  13. Architecture Overview Features and benefits Feature Benefit • Multiple topologies supported • Peer-to-peer • Hub and spoke • Load balance clustering • Provide new options for building scalable systems • Flexible configurations

  14. Architecture Overview Features and benefits Feature Benefit • Auto-discovery of nodes within the replication network • Improve quality of service and system availability • Improved system administration • Allows mobile workers who are disconnected or have low-bandwidth limitations access to enterprise applications

  15. Architecture Overview Features and benefits Feature Benefit • Database level configuration • Adds needed tables to replicated database to manage replication • Does not modify user-defined tables • Existing application does not need to be altered

  16. Architecture Overview Patented replication technology • Dynamic Data Slicing Architecture (DDSA) • Table partitioning - schema • Work set partitioning - query • Column level partitioning - fragment • Dynamic data migration • Dynamic Bandwidth-Managed Partner Selection (DBP) • Auto-discovery, auto-balanced • Avoids overloading any one server • Backbone, server and workstation algorithms • Collision Avoidance Methodology (CAM) • Record fragment management – related columns • Consistent resolution contracts • Rich API for custom resolution

  17. Architecture Overview Table-based Application Database PK Data Table “M” Rows Control Tables 1 table per database table PK Control Table “M” Rows System Tables 41 tables of setup data

  18. Architecture Overview System Tables 41 tables of setup data + Control Tables 1 table per database table System and control table cost • Cost • Typically 15% to 25% size increase of the overall database size • Scales linearly and is predictable • Advantages • No user table modifications • No primary key restrictions • Predictable footprint

  19. Architecture Overview Embedded Application Application Application Non-Progress Database Progress Database Database Control Tables PDR Control Tables Control Tables Triggers System Tables System Tables System Tables Change capture methods

  20. Architecture Overview System Requirements • PDDE 6.1 • Progress 9.1D • Service Pack 5 • DataDirect Driver 4.1 • Available via FTP site

  21. Architecture Overview PeerDirect Distributed Enterprise • Principal components PeerDirect Distributed Enterprise (PDDE) ReplicationEngine(PDRE) ReplicationDesigner(PDRD) ReplicationAdministrator(PDRA)

  22. Architecture Overview PeerDirect Distributed Enterprise • Available licenses PeerDirect Distributed Enterprise (PDDE) SDK InnerEdge OuterEdge OuterEdgeWorkstation

  23. Architecture Overview PeerDirect Distributed Enterprise • Available licenses InnerEdge Servers are “complete” PDRE sites that exist as part of your data center and possess a complete set of data for replication to other sites. PeerDirect Distributed Enterprise (PDDE) InnerEdge

  24. Architecture Overview PeerDirect Distributed Enterprise • Available licenses OuterEdge Servers are PDRE sites installed in remote office locations that replicate with the central data center or peer databases. PeerDirect Distributed Enterprise (PDDE) OuterEdge

  25. PeerDirect Distributed Enterprise Agenda • Introduction to Database Replication • Architecture Overview • Configuration • Replication Rule Design

  26. Configuration Replication Engine • Communicates via SQL through ODBC • The closer the Replication Engine is to the database, the better the performance • Supports Win32 and Linux • Configuration of InnerEdge and OuterEdge servers affect the way in which sites will be replicated

  27. Configuration Machine A DB PeerDirect DB Machine B Machine A PeerDirect DB DB Machine A Machine B Machine C DB DB PeerDirect PDRE Setup

  28. Configuration Sample configuration A InnerEdge Server OuterEdge Server PeerDirect DB DB PeerDirect 4GL App.

  29. Configuration InnerEdge Server InnerEdge Server InnerEdge Server OuterEdge Server OuterEdge Server OuterEdge Server OuterEdge Server PeerDirect PeerDirect PeerDirect PeerDirect DB DB DB DB DB DB DB PeerDirect PeerDirect PeerDirect 4GL App. 4GL App. 4GL App. 4GL App. Sample configuration B

  30. Configuration OuterEdge OuterEdge OuterEdge OuterEdge Distributed Enterprise • Aircraft Manufacturer • Aircraft maintenance application • Maintenance records were handled either on paper or in different centralized databases • Maintenance issues cause commercial aircraft delays and military readiness issues • Solution: One PeerDirect InnerEdge Server and multiple OuterEdge Workstations • Remote capabilities, work sets, and occasionally connected users • Aircraft maintenance data captured while aircraft is being maintained resulting in significant cost savings InnerEdge

  31. ConfigurationPeerDirect Replication Network

  32. PeerDirect Distributed Enterprise Agenda • Introduction to Database Replication • Architecture Overview • Configuration • Replication Rule Design

  33. Replication Rule Design Database considerations • Generic • No auto-increment fields • Primary keys or candidate keys must be identified • PDUSER must be created with proper DBA permissions • Progress • Unique primary keys must be defined and available to SQL engine • Primary unique index • 4GL dates must be SQL92 compliant • Be aware of column width overflow • Heterogeneous • Schemas of the data being replicated must match

  34. Replication Rule Design Basic steps to defining rules • Specify the application database • Select the tables to replicate • Define fragments to minimize the number of data collisions • Subset data into work sets • Arrange tables in transaction sets and/or groups • Prepare to activate replication-enabled database • Enable heterogeneous replication (if required)

  35. Replication Rule Design Partial Sports2000 Schema Analyze the Schema

  36. Replication Rule Design Specify the application database • Select the database type • Enter the location of the database • Non-production instance is recommended for development • Enter the PDUSER user and password • Enter any optional ODBC parameters

  37. Replication Rule Design Enter the project information • Specify the name of the project • Enter the name of the network • Enter a name for the replication release

  38. Replication Rule Design Selecting tables to replicate • Select the Not Replicated tab • Choose the tables you wish to replicate • Multi-select tables by holding down the Ctrl or Shift keys • Right click the group and select Replicate Table • Select the Replicate tab and view the tables that are now selected to replicate

  39. Replication Rule Design Table structure • Verify primary key or select candidate keys * • Under the Key column, click on the field that is the primary key for the table • From the drop down box, select the appropriate ordinal • Select field to be marked as a GUID field

  40. Replication Rule Design Fragments • Generic replication • Unit of replication is whole record • Changes occur at multiple locations • One user changes Addr • One user changes Limit • Can cause ‘False Collisions’ Name Addr City Zip Ctry Pymt Rating Limit  

  41. Replication Rule Design Fragments • Common solution to generic replication • Unit of replication is each field • Changes occur at multiple locations • One user changes Addr and Limit • One user changes Addr and Zip • Can cause ‘Silent Data Corruption’ Name Addr City Zip Ctry Pymt Rating Limit Name Addr City Zip Ctry Pymt Rating Limit    

  42. Replication Rule Design Fragments • PeerDirect solution to generic replication • Unit of replication is a group of fields • Changes occur at multiple locations • One user changes Addr and Limit • One user changes Addr and Zip • Helps avoid ‘False Collisions’ • Optimizes the replication cycle Name Addr City Zip Ctry Pymt Rating Limit    

  43. Replication Rule Design Fragment considerations • Common update responsibility • Database size • 12 bytes/fragment • Frequency of replication • Frequency of data being changed • All columns in a fragment change • Primary keys can not be part of fragments • Customized conflict handling can be created

  44. Replication Rule Design Foreign Keys • Determines the order in which tables are replicated • Parent tables must be replicated before child tables • Alphabetic order is used if no foreign key relationships are defined • Table relationships are defined from the bottom level upward • Child to parent • Must be defined if work sets or transaction sets are to be used

  45. Replication Rule Design Foreign Keys • The Designer will read the database's key constraints and display the foreign key relationships if defined within your database

  46. Replication Rule Design Acct Credit Hist ADetl Trans TDetl Introduction to work sets • PeerDirect allows you to define the business rules for sub-setting around base tables Ctry Off Off Prod Prod Cust Price Price Acct Credit Hist ADetl Trans TDetl

  47. Replication Rule Design Ctry Off 1 - Canada Cust 2 - USA 12 - New York Acct 3 - Australia 29 - Toronto 142 - Bouchard . . . 37 - Montreal 217 - W. Gates 84006239 44 - Sydney 330 - A. Palmer 93050403 . . . 401 - L. Haney 93072677 550 - N. Peart 96193414 . . . 97005567 98717696 99656643 99700174 . . . Defining work sets • Define the ‘Ctry’ base table • Subscribe the site to its country

  48. PeerDirect Replication Network Order Processing Site A Production OLTP Order Processing Site B Order Processing Site C Production OLTP Production OLTP Distributed DBMS Management

  49. Introduction to Database Replication PeerDirect Distributed Enterprise • Breaks dependency on centralized application architectures • Radically improves employee productivity with decentralized applications • Disconnected use • Creates an inherently resilient application architecture • Eliminates the latency and availability problems caused by the centralized model

  50. PeerDirect Replication Network

More Related