1 / 46

MDB Federation

MDB Federation. Working with Multiple MDBs Revised July 10 2006. Deployment Choices. One product, one MDB instance Multiple products, one MDB instance One or more products, multiple MDB instances ( Federated )

toshi
Télécharger la présentation

MDB Federation

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. MDB Federation Working with Multiple MDBs Revised July 10 2006

  2. Deployment Choices • One product, one MDB instance • Multiple products, one MDB instance • One or more products, multiple MDB instances (Federated) • Federation: multiple MDBs usable as though they are one. “pure” federation involves linking to data wherever it resides as though all required data was in a single MDB. For our MDB discussion we treat other transparent forms of access as federation: • Link to remote data when accessed • Replicate some remote data to an MDB before it is needed • Hybrid (replicate some information, link some)

  3. Single, Double or More? • Multiple applications can use the same MDB – in fact the more apps using the MDB, the richer the data Solution A Solution B MDB Solution C Solution D

  4. So, Why Not Put Everything into One MDB? • Many clients have several organizations each responsible for part of EITM – thus it is common to have operations separate from helpdesk separate from desktop management.   • When organizations are independent it is common to use separate databases and application servers for each team (so that administration, maintenance processes and backups and so on do not need to be synchronized). • Separate organizations may even outsource different parts of their IT infrastructure

  5. So, Why Not Put Everything into One MDB? • Large clients may be made up of multiple independent operating units • xSPs often process large clients using separate hardware (in fact large clients often work like xSPs with respect to logical separation of their operating units)  • It is common to keep certain types of data separate for compliance or legal reasons

  6. So, Why Not Put Everything into One MDB? • Single point of change control/failure • Outage impact felt by everyone – even if they do not use the component one is working on • Ingres MDB needs an outage for patches to database and some MDB patches • Database maintenance often impacts online transactions – single database means ANY products maintenance can impact other products – there are many single product tables within the MDB – all require maintenance

  7. So, Why Not Put Everything into One MDB? • Scalability – one product doing poorly structured queries can impact all products • Single MDB may not scale beyond medium sized clients • Reporting and searches are some classic pain points • Administrivia increases non-linearly with additional products • Secureability – much more difficult or not feasible if you need a high degree of granularity on database controls • Fault Tolerance – major outages are more likely

  8. Size limitation for one Ingres MDB – rough guide • I want to run NSM, Service Desk, UDSM, UAPM in one MDB • UDSM 2k-10k desktops with modest NSM server and network management (one hundred servers) • UAPM 20k assets • Service Desk one hundred issues a day • You can use a giant MDB with tuned DASD and extend this 100-200% but you cannot support even a medium enterprise with everything on one MDB

  9. Size limitation for one SQL MDB – rough guide • I want to run NSM, Service Desk, UDSM, UAPM in one MDB • UDSM 10k-25k desktops with modest NSM server and network management (one or a few hundred servers) • UAPM 50k assets (actual max varies dependant upon use) • Service Desk five hundred issues a day • Running reports may impact all applications • DB maintenance will impact all applications • You can use an MDB with tuned DASD and extend this 100-500% but you cannot typically support a large enterprise with everything on one MDB

  10. What the current MDB offers • Product Specific Federation • Repository Bridge for NSM, pdm_nsmimp for USPSD/NSM • Service Desk multiple MDBs, contact replication, and request broker • Desktop and Server Management hierarchical selective replication (2-tier now but n-tier designed) • Native database replication may apply to some products but is NOT currently a focus of testing best practices (yet)

  11. Federated MDB: Inter-Product Support • Service Desk supports access/import of external NSM MDB(s) • Asset Intelligence aggregates MDBs across multiple UDSM enterprises and domains • Service Intelligence aggregates multiple MDBs • UAPM reconciliation links discovered and owned assets • Common Asset Viewer displays USPSD, UAPM, DSM assets across multiple MDBs • Desktop Management federates domains into one enterprise • UAPM provides ADT - can use for 3rd party discovery tools

  12. Federated MDB • Accommodates organizational, network, or geographic distribution – aggregate or summarize to enterprise MDB Solution A Solution B Solution E Solution D MDB1 MDB2 Solution C Solution F MDB Enterprise MDB

  13. Horizontal Federation MDB MDB SolutionB Solution A

  14. Integration • Model level: normalized data • Database level • triggers, stored procedures • Application level • API, scripts • “Bridge” for CORe • Asset Intelligence • Presentation level • Common Asset Viewer, Portal, Reporter, F&T

  15. Federated MDB • Not just “multiple MDBs sharing an environment” but “multiple MDBs architected and designed to work together” • Product Specific Federation • NSM Core Bridge (true n-tier hierarchical summarization) • Service Desk multiple MDBs, contact replication, and request broker • Desktop and Server Management hierarchical selective replication (2-tier but n-tier designed)

  16. Federated MDB – DB Level Replication • Native database replication – may apply to some products but is NOT a focus of best practices and is not encouraged outside of specialized services engagements • Ingres supports several mechanisms for data replication • Native Replication – Previously used in 2.6 by USD • PSB's High Volume Replicator (HVR) • Star • SQL/Oracle also support PSB HVR as well as native replication • DB replication is possible but NOT typically supported

  17. Where to Begin? © 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.

  18. What do I need to know first? • What solutions are being deployed? • How well do they scale and integrate? • What federation options are available? • What degree of integration is required? • What type of hardware is available? • How mission critical is each solution? • What administrative and reporting options are required?

  19. General Considerations for Federation • Many factors go in to deciding on MDB placement and federation, including: • Which products are being deployed • Whether the data needs to be integrated – and how? • Multiple MDBs WITHOUT federation is supported? (e.g., USD/helpdesk managed by one department, UDSM managed by another)

  20. Any Restrictions? • If I deploy multiple MDBs, is there anything I cannot do? Do any functions require the products to share an MDB? Can I bring the data into one MDB? • Typically no loss in functionality by employing separate MDB's. • Placing all data into one MDB does have some benefits but there is no requirement to have only one MDB instance. • If you need to combine data from multiple MDBs this is typically already addressed by the products that are using the MDB. • If you encounter a problem caused by an inability to integrate separate MDB’s, that would be treated as a bug and remedied.

  21. Federated MDB: Restrictions • UAPM must be in same MDB as Discovered Asset data • uDSM Enterprise must be single MDB with UAPM • This restriction will be corrected soon • USPSD and UAPM should be in the same MDB

  22. Performance Questions • What kind of performance can I expect in a production environment when there are multiple products hitting the same database? • Are there particular deployment/load scenarios that, based on testing, will require multiple MDBs? • Extensive tests have been run against the MDB as part of the r11 quality assurance testing. The performance results and configuration recommendations determined from this testing are published • A single MDB will usually be slower than dedicated MDBs – but not slow enough to matter except for large environments • With that said, whether or not multiple MDB’s will be required will, in large measure, depend on performance requirements for your business.

  23. Single Solution Environments © 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.

  24. Unicenter NSM r11 • Multiple MDBs supported – but recommend use of “Enterprise MDB” to act as central database. • Enterprise MDB provides status that other products can use • Use Repository Bridge to: • synchronize WorldView data between multiple MDBs • Roll up higher level monitoring to Enterprise MDB • Alternatively, use bridge to segregate a single MDB into multiple views in order to separate dept. reference points for the enterprise wide view • Distributed MDB – several component DBs (e.g., remote MDB for Trap Mgr., separate MDB for DSM and WV, etc.)

  25. Unicenter NSM r11 – scalability controls • Object count matters, but not as much as state changes • As always, NSM is scalable to the extent you restrict how much data is replicated • Use ADS, AEC as filters to deglitch rapid state changes • Use Agent policy to stop state flapping and control maximum rate of change • Use bridge rules to stop frequent create/destroy object cycles

  26. Unicenter NSM r11 – Federation • In general there is little need to install NSM using a shared MDB with another product • Continuous discovery works with a remote MBD • Unicenter Bridge replicates selective data to a remote MDB • Service Desk CIA imports and exports to a remote NSM MDB • pdm_nsmimp is part of Service Desk r11

  27. Unicenter Service Desk r11 • Recommendations/limitations (h/w, s/w, network, etc.) • How is information “rolled up” in USD • Support for multiple releases of USD ? • Sample architectures • USD supports multiple peer level MDBs based upon geography or organization and replicates only contact data – this ensures scalability • And, Service Desk itself supports multiple MDBs right now –

  28. Unicenter Desktop and Server Management (UDSM) r11 • Recommendations/limitations (h/w, s/w, network, etc.) • How is information “rolled up” in UDSM • Support for multiple releases of UDSM ? • Sample architectures • UAM and USD support multiple separate domain level MDBs based upon geography or organization and you do not need to replicate more than just a few items to the top level MDB to get good value • Distributed MDB – different components on different databases • Must always have 1 Enterprise MDB serving as the central db – provides a complete view of the status of the entire environment • Distributed architecture – enterprise and domain mgr cannot share the same remote MDB interface • Enterprise Manager and Domain Mgr each have an associated MDB (local or remote). DM provides MDB connection to other UDSM components

  29. Unicenter Asset Portfolio Management r11 • Recommendations/limitations (h/w, s/w, network, etc.) • How is information “rolled up” in UAPM • Support for multiple releases of UAPM ? • Sample architectures • Currently Federation is NOT supported – UAPM supports only a single MDB and requires it to contain any data to be reconciled

  30. Multi-Solution Environments © 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.

  31. Asset Information Scenarios • ServiceDesk and UAPM (Argis): • As Service Desk is about to enter data about an asset, the user can search through existing assets in the MDB, including those created by Argis • Users can pick an existing asset and avoid data entry, or add a new entry • NSM and UAM: • When Discovery runs, every object is registered as an asset.  UAM is triggered by asset registration and can push out an agent to do a full hardware and software inventory • Trigger is “glue” between "continuous discovery" and UAM • Result: When an incident is recorded in ServiceDesk, SD will check registered assets, even those discovered by NSM, and the inventory info will be available as well

  32. Federated MDB: Inter-Product Support • Service Desk supports import of external NSM MDB • Asset Intelligence aggregates multiple UDSM enterprises and domains • Service Intelligence aggregates multiple Service Desk MDBs • UAPM needs to be in the same MDB as products that you wish to run the reconciliation engine against at the moment. It is an exception you have to architect around. We expect a more formal UAPM MDB federation solution sooner than r12, but for now you can architect around the special requirements

  33. Unicenter NSM + USD • So, NSM integrates just fine with Service Desk in a separate MDB and even feeds BPVs from a separate MDB to Service Desk • Additional post installation procedures are required to enable integration (e.g., making discovered assets in MDB available to USD, enabling Unicenter NSM events to automatically create new/update existing requests or announcements on USD scoreboard). See Implementation Guide for details.

  34. Unicenter NSM + uDSM • No general need to run in same MDB • uDSM focus is individual contributor desktops • NSM focus is servers • Can run separate uDSM for servers • High volume NSM and medium to large uDSM do not work well in same Ingres MDB

  35. Unicenter NSM + ? • NSM has little direct need to reside in one MDB • Most medium to large NSM deployments involve multiple MDBs • All medium to large NSM sites run hierarchical federation • You should reduce objects in top level MDB, reduce create/destroy object cycles, and reduce rate of state changeto improve scalability • Low volume NSM – MDB can co-reside with another product

  36. USD + UDSM • Service Desk and uDSM need same MDB only for UAPM reconciliation (which should be fixed sooner rather than later) • Service Desk MDB activity can be a primary limiter on its scalability, especially if any reporting against live MDB is done • Service Desk searches can also create high load on MDB

  37. USD + ? • Service Desk supports horizontal federation • This is a fine solution for large scale deployments where individual components are separately managed • One can easily roll up data to a single Service Intelligence • One can replicate data to a single reporting MDB • One can link to Asset Intelligence or Desktop Management in separate remote MDBs • When scalability is not a factor, one shared MDB with UDSM is the easiest way to integrate USD and UDSM

  38. UDSM + ? • uDSM supports hierarchical federation as always • Required for scalability • Required for manageability • Only weakness is that some administrative work needs repeated for each domain • Enterprise should be on UAPM MDB to allow reconciliation

  39. Maintaining Multiple MDBs © 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.

  40. Maintenance Considerations for Multiple MDBs • Lower impact of Ingres sysmod, ckpdb, optimizedb • Lower impact of SQL/Oracle backups • Considerations/differences when multiple products are using the same MDB • Scheduling considerations? • Troubleshooting? • Cost of multiple database instances (software/hardware)?

  41. Maintenance Considerations for Multiple MDBs • In general multiple MDBs result in more total planning for maintenance but lower impact for each individual maintenance operation

  42. FAQs © 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.

  43. FAQs • If I decide to deploy multiple MDB's – how do I decide which products should share each MDB? • This document has some guidelines, individual product documentation has more data. The EITM architecture for each client depends on their requirements. Services analysis focuses on MDB federation and hierarchy. • How do I configure and administer multiple MDB's? • There are Best Practice materials that provide detailed information on how to properly administer and maintain the MDB.

  44. FAQs • How do I configure and administer multiple MDB's? • Additional best practice materials for implementing CA products with multi MDB's and multi RDBMS MDB are constantly refined by the team that exercised the MDB as part of R11 stress testing. That information and various scripts/tools is delivered as part of the Implementation Best Practiceson SupportConnect

  45. Summary © 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.

  46. Summary • Single or multiple MDBs are supported in most r11 products • Federation makes size/maintenance/fault impact minimal • Most applications co-exist, or integrate/federate MDBs • Several “best in class” products coordinate and share data across MDBs transparently (NSM, UDSM, UAI, …)

More Related