The Importance of Initial Discovery
Discovering what you have in your datacenter, which includes all the hardware, software, applications, services, and their interdependencies, and assembling accurate documentation that reflects the current state can be a monumental task. Thankfully, that’s one of Device42’s specialties.
Device42 includes comprehensive autodiscovery and application dependency mapping that discovers and documents the details of a range of network connected devices. Anything from long forgotten remote access servers in the corner of some branch office closest to critical network hardware powering the main application stack – and anything in between – is within easy view of Device42.
Populating Device42’s CMDB, however, is not what we’re here to talk about today. Many of us know that at the center of Device42 lies its CMDB (configuration management database), into which all discovered data and inter-relationships are stored.
Today’s question is this: Once Device42’s autodiscovery has been run, comprehensive documentation about CI’s and their details has been generated, and the CMDB populated … What’s next?
We’ve had customers ask this question, and taking a step back, it became more obvious as to why. Especially with larger deployments, but to some degree with most all of them, Device42 can locate and generate a lot of documentation. All of it is good, accurate, and necessary – But at the same point, the documentation itself doesn’t come with an instruction manual.
Today’s post aims to change that. When a Device42 user finishes the “How do I Run Initial Discovery” guide, this will be the document to consult next.
After I’ve run Initial Discovery, What’s Next?
So here you are! You have your CMDB populated and you can see all your CI’s and their details. You’ve probably even created a rack or two and added some cable connections. Now, how do you make sense of all the auto-discovered data, and how do you leverage it to get the most from it?
We’ve gathered usage information from some of our power users, and we’ve distilled it into what we hope is a short, simple, and easy to digest guide that gives everyone the push in the right direction that they’ve been looking for. A general overview of the process, and the thought process behind it goes something like this: Just as many of your servers contain the applications, services, connections, and interdependencies you care about, they likely also are running things you don’t care to see. Examples are things like monitoring agent daemons, system processes and tasks, default configuration files, etc. To filter out that ‘noise’, we identify those services we don’t want to see, and we hide them.
Once we’ve hidden things we don’t care about, we do a 180 and, in preparation to start pulling actionable data out of Device42, start to think about things we do care about. There are two ways to go about the process: Top down, or bottom up. Top down means start with a service endpoint, like a website or IP address that hosts a given service, and work your way ‘down’ to the machines and eventually data sources that power it. Bottom up is the opposite – bottom up means start with, say, a database that holds all the important data, and work your way ‘up’ towards the services that rely on it. We then pull up Dependency or Topology charts by browsing to the CI for the device that holds our endpoint of interest, and we can then start organizing the relevant components into groups, for example ‘business applications’.
So, now the things we don’t want to see are hidden, we’ve identified a starting point and we’ve got the topology or dependency maps for our relevant CI’s pulled up. The last step is to create component groups, as briefly mentioned above, and to name them. This final step not only helps the user to assemble a clear mental picture of how important business applications and the machines that power them are organized and interconnected, but also groups them together within Device42 for future reference.
Hiding Redundant Services From Topology Charts
Now that we’ve known the overview of what we’re trying to achieve, and the ‘why’ that went into it, the following is a step-by-step, with pictures.
- Begin by going to the Service view:
- Sort the service by instances, descending.
- Do this by clicking on the highlighted “Service Instances” column header twice, until the sort indicator arrow points downwards:
- This should identify common services that either you do (but most likely don’t) particularly care about, e.g. antivirus running across the infra… or monitoring, etc.
- Select those services that are of no concern (check the box next to each service):
- From the Action menu, export to CSV, and then press “Go”:
- Head to the Import Export Screen and Download the “Services” sample Excel file:
- Open the downloaded “services.csv” spreadsheet, and the newly downloaded sample api_services.xls sheet:
- Copy the service names and topology status column data from your CSV to the sample api_services.xls file you downloaded:
- Add the column ‘topology_status’ to a blank column on the topology API sample file, and paste the copied service data from the exported CSV. Change the topology status (topology_status) from ‘1’ to ‘3’ (or to ‘hidden’, which also works) to hide each service you don’t want to display in Topology Views.
- Save your changes & re-import the updated “Services” file via the “Import / Export” page’s import function.
- View your topology and impact charts of concern
- View using either a “top down” or a “bottom up” approach… [*Greg’s methodology *]
- Start a website (top down) and look at dependency or
- Start at a DATABASE (bottom up) and look @ impact chart.
- From either views, hover over additional services that show unimportant connectivity and select “hide” option:
- From Application components menu, select multiple components that you would like to group together:
- From drop down menu, choose “add tags to selected items” and name these applications as a comprehensive business line application.
- If you’d like to go one step further, also choose “add application component dependencies” and create a new top-level application component that groups multiple components together as dependents:
Once the above steps are complete and you’ve hidden any other services that you may have missed, you will have a clean view showing only the services you care about:
The below is a before and after topology of the same server after hiding common services. The results are dramatic, indeed!
If you’ve reached this point, you should have a crystal clear picture of the servers, applications, and interdependencies that power your organization in Device42.
Of course, for larger organizations, and more complex deployments, understanding the entire deployment may prove exponentially harder, but therein lies the beauty of organizing services in this fashion: Namely, the services can be broken up into ‘digestible’ pieces, logically arranged such that the “front end” and its dependencies are clear, the “middleware” and their dependencies are clear, and the “data layer” and it’s are completely understandable as well.
The information, organized in this fashion is also extremely useful to have at hand during a wide range of digital transformation planning, be it preparation for migration, a cloud cost feasibility analysis, or for plans to build a disaster recovery site with a redundant stack.
Hopefully, you found this post useful, and now understand what to do post-discovery! If there are any questions or comments, please do leave them below! We would especially love to hear feedback on how the above process worked for you, and any suggestions for tweaks, additions, or changes you might have come across in your real-world usage!
Thanks for reading, and as always, if you have any questions you’d like an engineer’s help to answer, send an email to email@example.com
After importing, you should see something similar to the following: