Transcript MDB Federation - SupportConnect

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)
- 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)
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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 100500% but you cannot typically support a large enterprise with
everything on one MDB
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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)
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
Federated MDB
- Accommodates organizational, network, or geographic
distribution – aggregate or summarize to enterprise MDB
Solution
A
Solution
B
MDB1
Solution
E
Solution
D
MDB2
Solution
C
Solution
F
MDB
Enterprise MDB
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
Horizontal Federation
MDB
Solution
A
MDB
Solution
B
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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)
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
Where to Begin?
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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?
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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)
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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.
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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.
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
Single Solution Environments
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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.)
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
–
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
Multi-Solution Environments
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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.
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
Maintaining Multiple MDBs
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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)?
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
Maintenance Considerations for Multiple MDBs
- In general multiple MDBs result in more total planning for
maintenance but lower impact for each individual
maintenance operation
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
FAQs
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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.
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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 Practices
on SupportConnect
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
Summary
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.
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, …)
© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.