Discovery Discovery Scoping DDM 8.0 Advanced

Discovery should be Approached Holistically vs.Simplistically When Possible• Simplistic Approach− No data? In a hurry?Reference: UCMDB Deployment Guide• (BP) Holistic Approach:• Sizing for discovery is more than the hardwarefootprint.• Start with Architecture, end with the sizing.• Work backwards from the Use Cases.4HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

“First, get your facts straight.Then, you can distort themall you want.”- S. Clemens© 2008 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice.HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

The Basic Sizing Process1. Start with the Use Cases2. Determine the data providers and consumers based on the use case3. Estimate the # and type of TQLs based on the providers andcomsumers4. Define the DDM discovery strategy based on the use case5. Use the DDM discovery strategy todefine the DB sizingDeliverable6. Use DB sizing to define the Capacity Plan7. Use Consumption model to define the Performance Plan8. Use performance plan to define Sizing Requirements9. Use Sizing Plan to define the Deployment ArchitectureBP: Use actual data over best practices, avoid guesstimates.BP: Use data from your environment over industry averages.8HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Categorize your Use CasesSimilar Use Cases Share Similar Profiles• Operational− Often a Single consumer− Provider (Population) primarily discoveryShallow discovery (scope = targets, e.g. monitored / automatedservers)• ITIL/ITSM− Multiple providers− Multiple consumers− Population via discovery and federation• OthersShallow discovery (scope = targets, e.g. hosts, applications)− Single consumer (special-purpose user)− Population primarily via discoveryDiscovery may be very deep or very wide9HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

How do I Profile the Consumers?• What CI types and relationships are required for the use case?− Determines #/type of TQLs created− Critical to performance plan!UCMDB• Direct Consumers? - Will the users consume reports / modeling/ topology directly (e.g, from the UCMDB UI)?• Indirect Consumers? - Will the users consume UCMDB (e.g.,SM, RC, BAC, launch-in-context, API users, etc.)?• What is the expansion model (how you map more applications –by platform, demographically friendly, etc.)?• If multiple providers, what are the reconciliation needs?12HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Planning Stage – Con’t•(BP) Discuss with an SME (Subject Matter Expert) of the area of youruse case. This expert should point out the critical entities (CIs withattributes and relations) that must exist in the CMS in order to providethe business value. The owner should be able to specify the abovegoals and blueprint (or at least the current architecture of theapplication).•(BP) You should aim to DISCOVER ONLY CRITICAL DATA , makesure you DON’T START WITH EVERYTHING. You can alwaysenhance the discovery later. The goal should be to first set up asimple discovery that works and provides value. It is also difficult to“clean up” after you discover too much.13HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

UCMDB Population Strategies© 2008 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice.HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Data Providers - 50% of the understandingIf you understand the data providers for your use case,you’ll understand 50% of how to size a CMDBdeployment.Population strategy is the primary determiner of CMDBsize.CMDB size plays a major part in deployment sizing• Drives performance expectations• Drives capacity and growth expectations• Drives modeling/mapping pace• Drives db sizing16HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Why an Efficient Approach is NeededDecaf versionAvoid the “Discover everything and sort it out later” approachNon-valuable CIs incur overhead• Discovery time and resources• CMDB time and resources• Ongoing time and resources (TQL, GUI, etc.)Large, Inefficient discoveries limit scalabilityLarge, Inefficient discoveries degrade performance of discovery,GUI, serverMake every CI count –• Ask yourself “How will this data be used”?17HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

The Why, When, What and for Whom Table(BP) Choose the appropriate discovery toolUse CaseCategoryExampleDiscoveryToolDiscoveredDataUsersAssetManagement/ConfigurationManagementSoftware licensemanagement,Software audit,complianceDDM Inventory(EnterpriseDiscovery)HW/SWInventorySW UsageFinanceITSM - ChangeManagementHostdependencies ,Impact AnalysisDDM Standard/AdvancedHostDependenciesApplicationMappingOperationsNetworkManagementNetworkperformance,NetworkcomplianceNNMNetworkdevice,attributes,connectivityand statusNetwork,Engineering18 24 June 200918HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Research Stage – Model Research•(BP) Take some time to browse the UCMDB class model (CIType Manager) and match the entities and relations from theblueprint to existing ones. It is highly recommended to adhereto the current model if possible to avoid possible complicationin version upgrades. If you need to extend the model it isrecommended to create separate types since an upgrade mayoverwrite the core types that came out of the box.19HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Research Stage – Model Research•If some entities, relations or attributes are lacking from thecurrent UCMDB model you will need to create them (modelextension) or federate them.20HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Research Stage – Technology ResearchHow do I find out how to get the data that I need?• Any data source which may provide information on the use case inquestion is valuable. This requires both extensive knowledge of thesystems and sometimes creativity. (usually involves access using someprotocol to either a management part of the application)• For home-grown applications, provide a questionnaire to theapplication owner. Application owner should be able to point out all theareas in the application which can provide the information needed for theblueprint and business values. This should include (but not limited to):management databases, configuration files, log files, managementinterfaces, administration programs, web services, messages\events sentetc.• For off-the-shelf products, focus on documentation, forums or supportof the product. Look for administration guides, plug-ins and integrationsguides, management guides or anything of the sort. Relevant data sourcescould be - Application configuration files Registry entries Log files NTEvent Log etc..21HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Research Stage – Technology Research• (BP) Relevance: Select sources which give the most datayou need. Could be a combination of sources (and usuallyis). Access the value vs Effort (ROI) of a specific method ofdata gathering vs. another. Sometimes you will decide toreduce the blueprint if the value\cost isn’t worth it.22HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Research Stage – Technology Research• (BP) Reuse: If UCMDB already has a specific connectionprotocol support, it is a good reason to use it. It means thediscovery framework will be able to supply a ready made clientand configuration for the connection. The currently supportedUCMDB connection protocols can be viewed in the Discoverypanel, under Domain Configuration Credentials.23HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Research Stage – Technology Research•Security: Access to information usually requires credentials(user, password). These credentials need to be entered intoUCMDB and are kept secure throughout the product. If possible,and if this factor doesn’t collide with previous principles,choose the least sensitive credentials\protocol which stillanswers the needs.24HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Research Stage – Technology Research• Comfort: Some management interfaces may have more advancedfeatures you can use. For example it might be easier to issue queries(SQL, WMI) than to navigate information trees or build regularexpressions for parsing.• Developer Audience: The people which will eventually develop thediscovery may have an inclination towards a certain technology. Thiscan also be considered if two technologies provide almost the sameinformation at equal cost in other factors.25HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Outcome•The outcome of this stage should produce the PLANof which sources to discover and what information toextract from each into the blueprint model , accessmethods (which should also have a correspondingUCMDB model by now).26HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

UCMDB Performanceand Capacity Planning© 2008 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice.HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Why a good mapping approach is so key –Example ?Each fully discovered Host (“strong” or “complete” host) = ~ 300 CIsShallow (“weak” or “incomplete” host) = ~ 10 CIs300:10 = 30:1 ratio for # of CIs for full vs. shallow hosts (includes all ancillary CIssuch as networking and host resource CIs)In other words, 250+ additional CIs per host.The Discover Everything Approach will make complete hosts out of everything youhave credentials for.(BP) Efficient Discovery Approach discovers only what is neededExample: 5,000 hosts in an environment, 20% are “important” hosts hosting somepart of an application to be mapped into a use case – the rest are shared services ornot directly part of the use case - = 4,000 hosts NOT to be discovered in depth4,000 x 250 = 1,000,000 not needed CIs.28HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Why an Efficient Approach is Needed - HR exampleWarning: Do Not actually read this slide unless you are up for some Espresso!CIs/host = Hosts + Host Resources + Network + NW resources + Database + DB Resources + Apps + Appresources + connections/dependenciesC/H = H + HR + NW + NWR + DB + DBR + A + AR + CAssumptions and ranges:Where H = 1, HR = cpu(1-64), memory(1), disk(1-10, avg 5 for unix, 3 for Windows), Services (50-75), processes(40-100), software (40-100 for Windows, 150-600 for unix)NW = 1/# servers per network (subnet), NWR = Interface/indexes(2-6)DB = 1/# servers not a DB server X DBR, DBR = (50-500)A = 1/# servers/app X AR, AR = (50-500) + 10,000 from external sourceC = 10-100Non-resourced (aka a “shallow” or “weak” host ~ 15-20 CIs,Resourced host (aka “strong” or “complete” host) ~ 1,200-11,000 CIsDifference ratio: 20 : 600 = 1:30Example:5,000 hosts, 1,000 are resourced = 20% of hosts go “deep”, 80% are shared or shallow hosts (not an appserver or DB)Comprehensive discovery = 5000 x 600 = 3,000,000 CIs per 5,000 hostsEfficient discovery = 1000 x 600 + 4000 x 20 = 600,000 + 80,000 = 680,000 CIs per 5,000 hosts680K / 3,000K = ~226% difference in efficiency – CMDB affects limits of TQL, GUI, etc. capacity and performanceScale 5,000 to 50,000 hosts in an enterprise environment = factor of 10, a single order of magnitude3million CIs become 30 million CIs, 680K CIs become 6.8 million CIs, 441% the size of an efficient discoveryThis significantly impacts the pace of the mapping schedule based on the supported (published) capacity of theUCMDB systems (not just the CMDB)Conclusion: Inefficient discovery not only slows performance of the CMDB, it ultimately slows the maximum paceof the mapping effort and impacts delivery of value.29HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Are there Use Cases Requiring Comprehensive Discovery?True discovery of the unknownData Center relocations/consolidationsDR“Aha!” moments, true discovery of the unknown, e.g., (“hey,come look at THAT!”)Practical experience proves these are still possible with atargeted (non-100%) discovery.• Just because you are excluding layers known to be noisy, your shallowsweeps don’t lose value – plenty of “discovery” is still done• Look at 100% use cases by layer, not by depth• Example: DC relocation – You DO need to know about every device, butyou DON’T need to know about every running process !30HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Discovery Approach – Get only what you needNetworkIPHostDependencyShallow hostsDBOrcl HRCommonPlatformDeep-divesWASHRJ2EESQLBEAHR HRDB J2EE31HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Size = Area – Two casesWWAComprehensiveDiscoveryDD1BEfficientDiscoveryD2D3SArea (A) = W x D(BP) Area (B) = W x S + a(d1) + a(d2) + a(d3)…(dn)32HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Discovery Recommendations(BP) Keys to Success•Try to make every CI (and it’s discovery) have apurpose and a owner•Discovery is only one step in the CI Life Cycle –discovery with aging and expiration in mind•Discover sparingly at first and expand as needed –on a scale of millions of CIs, it is much easier toadd a CI than to delete it•Discover with focus, specifically, methodically,flexibly (keep in mind your usecase)•Use federation when appropriate•A CMS Project is an investment in time andresources33HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Discovery - Keys to Failure• Discover without a use case in mind• Discover carelessly, curiously, or too quickly• Discover Everything - aka “just in case”, “We don’t know what wedon’t know?”, etc.• Use the wrong tool for Discovery• Overly Restrict Discovery times or capabilities, or only with manualapproval, these will all either generate too many requests or take toomuch time to allow success• Overriding Spiral discovery because you want to control discovery• Adapt a purely credential-less discovery approach – not enough CIdetail to see the "fingerprint" of many applicationsSolution: Segment discovery by scope, process,platform, use case, etc. to show success early andoften34HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Scope vs. Breadth of Discovery Patterns in theDDM Spiral Discovery“uncoiled spiral”D E P T HRate of CIsDiscovered(# of targets)Depth(Total # ofCIsand CITypes)B a s e l i n e M i d d l e A p p l i c a t i o nCredential-less ScopePing Hosts& Deep-Dive(IP) Platforms Fingerprint ApplicationMoreNetworksIP AddrsNW Connections/Host DependenciesHostsCustom PatternsHost Resources35DatabasesCitrix,ldapLayer 2 DiscoveryHost ResourcestSAP, Siebel, MQJ2EE/JMX noInternalsDB ResourcesNot too deep!From Inward to outward on the discovery spiral, Breadthof discovery patterns decreases (narrows) as their Depthincreases, balancing CMDB growthHP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.Less

Discovery: Risk vs. Value vs. Time&EffortTime&Effort curveRisk vs. ValuecurveLimitedNetflowInsecure Protocols, e.g. NTCMD, TelnetRiskRisk avoidance“goal”MorenetflowCredential-lessDiscoveryAdministrative Credentialed DiscoveryManagement’s goal – balanced risk vs. benefitNon-Admin Credentialed Discovery - common loginNon-Admin Credentialed Discovery - server by serverTime&EffortNotesNo DiscoveryicmpServer login (TTY), WMI, SNMP, Application uid/pw (Best Value vs. Risk)SUDO for ‘ls’ and ‘cat’ commands due to likelihood of incorrect file permissionsValueNtcmd, root, sudo, etc.Low effort – large value – large risk – insecureOnly recommeded for small shops1. 100% secure = no value – can’t access anything!2. No Credentials = some value3. Best Value = Basic (non-admin) Credentials = biggest single-step gain in value vs. risk4. All Credentials (including Application-level) provides the most value5. No need to be insecure (vs. no risk) by using “bad” protocols6. Effort-Time curve – major effort to go credential-less – value is hard-earned7. Even a little credentials require much less effort and provide much more value8. Most time&effort = repeatedly, iteratively requesting each credential on an element-by-element basis9. MANAGEMENT must get IT Security buy-in – effort risk will be rejected if value is not understood36HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Real-World Discovery Flow Case StudyInput CI Discovery Pattern Discovered CI TypesDomain IP rangeICMP_Net_Dis_IPbICMP_Net_Dis_IPcipKnown_ip_no_DNSDNS_Net_Dis_DNSNameipLegendip w/DNS w/o host typeIP IntegrationwindowsunixID’dIPsEnrichmentrestDiscovered obj.ip_of_win WMI_Net_Dis_Connection ntDiscovery Patternip_of_unixTTY_Net_Dis_ConnectionunixTriggerip_not_unix(win + rest)SNMP_Net_Dis_ConnectionSNMP_Net_Dis_NW_DevNt+unixHostsNW devHosts via TCPhost“LIGHT” SNMP_Net_Dis_TCP“LIGHT” TTY_Net_Dis_TCP“LIGHT” TCP_Net_Dis_PorthostipportCreateDependency linkslinksException Rpt.Host IntegrationReview/Discard still-unidentifiable hostsStatus, usage,Location,ownerID’dHosts37HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Discovery CustomizationReasons to customize discovery patterns• Integration: Exchange data with application• Unsupported platform, version, or combination of the two• Avoid credentials• Efficiency or performance increase• Overcome limitations like platform gaps or 1-off attributesHP and Partner Consulting is available to help extenddiscovery and provide help to customers who wish to do itthemselvesCustomers, with sufficient expertise and experience, canextend and customize discovery as appropriate38HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Performance and Capacity Planning© 2008 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice.HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Growth RateGrowth rate is highly dependent on use cases:• New CI rate levels off as use cases are fulfilled• History growth increases with CMDB/CMS maturity• Most “Growth” during initial deployment into full Operationalmode (can take some time!)SizeinstallationEvaluation& 1 st MapsInitialdiscoveryPhase 2 Discovery& Ramp-UptMost NewDiscovery DoneFine-TuningNew Business CasesNew CIsTotal CI count40HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Partially and Fully Resident ModeThe total number of CIs & Links that a single UCMDB instance can hold in this mode is 25M (2525,000,000).This usually translate to 20k to 50k servers depending how “deep” you’re discovering them.-Yoav BoazDirector of Product Management | Emerging Technology Group & CMSPartial Resident Mode – (Applicable for Large EnterpriseDeployments only 12.5 M to 25 M CIs and links) Configurationof UCMDB in such a way as to allow for some CIs to bememory resident and the remainder to be stored on disk.Optimizes performance in a larger deployment.Fully Resident Mode – (Standard and Small Deployments , lessthan 12.5M CIs and links) Configuration of UCMDB where CIs/ links are database resident and are retrieved as needed.Reference - HP Universal CMDB Capacity Planning.pdf41HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Partially Resident Mode‣ Partially Resident Mode is only relevant for the Enterprisedeployment of HP Universal CMDB. For the small orstandard deployments, Fully Resident Mode is the onlyavailable option.‣ 12.5 M to 25 M CIs and links‣ Partially Resident Mode is only supported on systemsworking with Oracle. Systems working with Microsoft SQLonly support Fully Resident Mode.‣Supported configuration:➤ 64-bit operating system (Windows 64-bit Enterprise Edition was used for this test)➤ CMDB heap increased to 4 GB➤ Oracle Database SGA - 4 GB supported, 8 GB recommended42HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Are you approaching the limit?When the total size of your database is approaching the12.5 million limit, it is recommended to convert the CMDBto Partially Resident Mode. This is only relevant when atleast 20% of the CIs in the database are of thefollowing types (all located under Host Resource in the CItype tree):➤ Process➤ Service➤ CPU➤ Installed SoftwareRefer to the HP Universal CMDB Capacity Planning guide43HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Managed Hosts and Host-Related CisEstimating SizeSize Managed Hosts / Host Managed Hosts / HostRelated CIs Fully Resident Related CIs Partially ResidentEstimating CapacitySmall 4500/160 to 1000/500 Not ApplicableStandard 9000/160 – 3000/500 Not ApplicableEnterprise 28000/160 – 9000/500 56000/160 - 18000/500Note: The numbers in the table include only CIs and not links.Host-related CIs include all CIs of typeswhich are subclasses of Application Resource,Host Resource, or Software Element. Thehost-related CIs number depends on the size ofyour deployment and the number of managedhosts: The more managed hosts you maintainin the CMDB, the fewer host-related CIs youcan discover for each managed host.44HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Example UCMDB BreakdownLinks are more than50% of the totalHosts less than 3% ofthe total (typically it willbe less than 1%)DB Data File Sizes(MSSQL)CMDB 1.5 GB (Growswith new CIs)CMDB History 1.1GB(Grows with Changes)Foundation 200MB(Static)45HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Are you or the customer asking “what is the totalnumber of CIs UCMDB can hold?”If so then the objective may be the wrong focus. “Population” instead on the right objectivewhich is “what is the use case I’m trying to achieve?”When the size of the system increases beyond 12.5 million objects, thedegradation of performance continues as you approach the maximum size of25 million objects and links.BP for success Do NOT turn discovery wide open – Don’t populate UCMDB for the sakeof population Start small and be use case driven – Understand what is the “end goal” ofdiscovery Have an owner for each CI and each attribute – By doing so the customerputs a “quality barrier“ on the CIs entering UCMDB, thus making sure theamount of “garbage” will be minimal46HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

UCMDB Hardware Sizing© 2008 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice.HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Hardware Sizing RecommendationsStart with the DocumentationApply 8.0 Safety FactorsApply Growth & Capacity PlansFactor in Growth based on Strategy:• Least Cost• Least Change• Latest Technology• Rigid Compliance with Local Standards/PoliciesDocument and Present to Hardware Team48HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Basic Sizing ElementsSizing = Initial footprint• CMDB Server – Single-jvm or multi-jvm• Database space• Probe and gateway profile• Federated Data Source (future)Capacity = Initial + Growth of Footprint• Initial deployment into Operation• Normal Growth• New Business Cases49HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Basic Hardware Sizing Process(do this step LAST, after all the other plans are done)Identify the size tier (S/M/E) based on data created from earlier steps(IN THIS ORDER)• Estimated # of “expensive” TQLs• Estimated # of inexpensive/ancillary/low priority TQLs• Estimated # of concurrent consumers• Estimated # of CIs in the CMDB• # of Planned probes/gatewaysUse the tables in the next slides to assemble a footprintAssemble the accompanying plans to justify the footprint requirements(support x capacity, y performance, z users – this will varydepending on how the customer wants to see it)Compile the sizing footprint and the justification plans into arecommendations documentPreview, review, revise, and present to decision-makers50HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Hardware RequirementsResults * MayVary.WindowsMemoryTypical *UCMDBfootprintWindowsCPU*Number of Managed Hosts/HostResource CIsSmall 2Gb Single jvm(+FCMDB)1 CPU 4500/160 – 1000/500Standard 4Gb Multi-jvm 2 CPU 9000/160 – 3000/500Enterprise 8Gb Multi-jvm 2 CPU 28000/160 – 9000/500*To fulfill the CPU requirements, Dual Core Processor 2.4 GHz or higherRecommended Hardware for Solaris: dual processor 1.5GHZ - 1.8 GHZ with8 GB RAM51HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

OOTB JVMs Memory AllocationEnterprise:• cmdb_res_utils - 1400• mercury_cmdb - 1400• mercury_fcmdb - 767• mercury_mam - 1400• MercuryAS - 1400• Broker – 1280Medium:• mercury_cmdb - 1280• mercury_fcmdb - 512• mercury_mam - 1280• MercuryAS - 512• Broker – 51252**memory size in MbytesHP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

UCMDB – Block diagram53HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Multi-JVM• The deployment XML file determines whether theinstallation will be multi JVM or not according to thememory size.• The path to reach deployment XML file isC:\hp\UCMDB\UCMDBServer\j2f\conf54HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Deployment XMLMemory checkProcesses NamesMemory Map55HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Deployment XMLMedium DeploymentmercuryAS - 512mercury_cmdb - 1280mercury_mam - 1280mercury_fcmdb - 512Broker – 51256HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Deployment XMLEnterprise DeploymentmercuryAS - 512mercury_cmdb – 1280cmdb_res_utils - 1400mercury_mam - 1280mercury_fcmdb - 512Broker – 51257HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

How many probes do I need?Doc says, 1 probe per 5,000 devicesPractical experience indicates this is usually low• Some shops have more like 15,000 devices per probe• Number of probes required for performance will vary by use case andenvironment profile• Number of probes required for visibility is easy to calculate:– # of Probes = # of data centers + # of DMZs + performance factor– Performance factor = # of devices per data center / scale factor– Scale factor constant = something between 5,000 and 15,000– Example: 2 data centers each with 2 DMZs and 50,000 devices each(devices=all devices, not just licensed application servers):– 4 DMZs = 4 probes– 2 data centers x 50,000 devices = 100,000 devices / 15,000 = ~6 probes– 6 + 4 = ~10 probes– This example is obviously an enterprise-tier environment!58HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Putting it all togetherAssemble into formal documents, and present as formally as appropriate• Hardware recommendations– all Servers and probes/gateways– Details of platforms, cpu/memory/disk/database• Discovery Strategy– What will be discovered (CI Types and relationships)– Which probes for what networks/infrastructure– Discovery schedule– Modeling and /mapping plan (how discovery will be used)• Performance Plan– Expected performance in terms of response times, throughput, availability– Expected peak loads of UI vs. discovery activity, maximum users• Growth and Capacity Plan– CMDB Capcity growth over time– Expected TQL metrics growth (# of active result nodes, consumers, # of TQLs)– Mapping pace for deployment – how many maps created how fast• Deployment Plan– Project plan milestones for hw allocation, installation, discovery, mapping,consumption/value-add– Success criteria for performance (did we size it correctly?)59HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.

Q&A© 2008 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice.HP CONFIDENTIAL - ENABLEMENT ONLY, NOT FOR CUSTOMER USE.