If those questions have been keeping you awake at night, then you need to get a grip. There are better reasons to lose sleep!
But even so, CI Scan is just the most visible part of some big changes in how Discovery works under the covers. It's all about CI identity. We introduced the feature as an option in the Winter 2010 release — and sometime later this year it won't be an option, it will be the standard way that discovery works. If you'd like to know more, then keep reading...
After a CI Scan discovery kicks off, the first thing that happens is the scan phase. The Shazzam probe does all the scan work. It's only job is to identify those IP addresses within the discovery's range that have active services on them. Shazzam does this by attempting to open TCP connections (without actually sending any data) and by looking for responses from UDP ports.
Once Shazzam has identified an IP address that has active services, the next thing that happens is the identity phase. This is the part that's new, so pay attention! During the identity phase, no CIs are created, updated, or deleted — the CMDB isn't touched at all, not even to create IP Devices (as used to happen). Instead, during this phase Discovery collects all the information it needs to unambiguously identify a CI. At the end of the identity phase (more precisely, in the Identity sensor), one of several things can happen with the out-of-the-box configuration:
- The identity sensor cannot find an existing CI with matching identity. In this case, Discovery will create a new CI and start exploring and updating it.
- The identity sensor finds exactly one existing CI with matching identity. In this case, Discovery will start exploring and updating the existing CI.
- The identity sensor finds two or more existing CIs with matching identity. In this case, Discovery will not explore or update the CI, as your CMDB is in need of your attention and intervention.
- The identity sensor finds exactly one existing CI with matching identity, but sees that an IP address on that CI is already being explored. In this case, Discovery will not redundantly explore this additional IP on the CI.
Finally comes the exploration phase (assuming the IP is going to be explored), which hasn't changed significantly. In this phase, Discovery launches probes to find out about the CI, and uses the results of those probes to update the CI in the CMDB.
This new identity-based approach to discovery has several compelling advantages:
- No CIs are ever deleted by Discovery. Period.
- CIs that change IP addresses (such as workstations or laptops provisioned with DHCP) are always updated correctly — even when those addresses change frequently, or when the CI changes location (e.g., someone carries a laptop from the New York office to the Hong Kong office).
- CIs with multiple IPs are only explored once. This is particularly helpful if your organization has web farms with servers that have dozens of IPs provisioned for different services.
- If your CMDB contains duplicate CIs, Discovery will figure this out and not update any of them (as it can't know which one is the right one). You'll know this happened because the device history log will tell you, in plain language.
We urge you to take CI Scan for a test spin, if you haven't already done so — and to move to CI Scanning in your production environment once you've learned how to use it. Consider this your early warning announcement, because later this year, CI Scan won't be an option, it will be the only way Discovery works!
7 Comments
