A mature CMDB is crucial to the speed of business
by Lisa Kurowski, Sr. Business Process Analyst
Managing a true hybrid multicloud requires a strong, well-managed Configuration Management Database (CMDB). At NetApp IT, it’s not an answer for managing a complicated enterprise environment, it’s the only answer. Without the CMDB serving as the central source of truth, we wouldn’t be able to operate day-to-day and keep the organization running at the speed of business.
The long-term benefits of using a well-resourced CMDB are greater than the short-term struggles of building and integrating one. Our CMDB has been a massive benefit for NetApp IT.
So, how’d we do it? What did we learn?
CMDBs don’t happen overnight
Quality CMDBs are large and highly complex. Because they carry such a mighty burden, they must store a huge amount of data. The first step to properly building one is to prioritize what’s most important. There must be a stack of foundational data, which you then iteratively mature.
This is going to take time – probably a lot of it. Data must be added – and updated as needed. Rounds of analysis on what should be automated need to be completed. Governance processes need to be established.
Then, there is maintenance. A CMDB is not a fire and forget solution. It requires constant discovery and monitoring, which can realistically only be done through automation. NetApp IT leverages ServiceNow’s Discovery combined with integration to NetApp’s own OnCommand Insight (OCI) to give us complete visibility into our infrastructure and storage. These have helped us mature the CMDB, which must happen before integration with other tools and processes.
How did NetApp IT implement our CMDB?
Our original, homegrown CMDB was primarily used by datacenter services and was designed to capture information about equipment in the data centers. However, it lacked complete and accurate data regarding storage, logical infrastructure, and the applications which relied on the physical infrastructure. Many business services teams didn’t even know it existed.
So, we moved to ServiceNow’s CMDB with the intention of consolidating data in a space where everyone would have access to it. We also wanted to take this opportunity to build automation and self-service into the foundation, so from the start, the CMDB would be as efficient as possible. Additionally, it would need to support on-prem data centers as well as the private and public cloud.
We built our foundation by focusing on data from the Application through the logical infrastructure to the hardware and data center. We created naming standards and guidelines that clearly defined data ownership. Governance had to be worked through with custom roles and security standards unique to our organization.
We created catalogs that drive hardware provisioning. The same was done for compute with storage provisioning. Then, we set up automated discovery and maintenance to keep the CMDB always updated. We probe scan all known devices daily and perform bi-weekly scans of all data center subnets, as defined by Infoblox.
The final part of our foundational work was shrinking the chasm between application and infrastructure teams. The application layer isn’t owned by a defined group, it’s owned by individuals. That required some unique controls, such as self-service registration, secure access for IT vs the business for data maintenance, ownership transfer controls, a Leaver process to maintain continuity of ownership when owners leave the company, and quarterly reviews.
The second phase: Building on the foundation
Our first year was spent importing data, establishing standards, and expanding discovery and automation efforts. The second year started the growth phase. We identified deficiencies – the CMDB didn’t include everything – and worked to solve for those.
IT’s first integration was with OnCommand Insight (OCI), to fill CMDB’s data gaps around storage and to speed issue triaging by enabling users to jump directly from a logical server in the CMDB to the related storage directly in OCI. We make hundreds of changes to storage assets weekly. OCI, and now Cloud Insights, provide us with detailed information on how the storage assets are used and what needs to be updated. By being able to jump from the CMDB to OCI or Cloud Insights, users can get a detailed picture of the health and hygiene of our entire storage ecosystem, in real time, which makes it easier to make data-driven decisions.
We also integrated with Ansible and Zenoss for monitoring and configuration management and with Incident and Change Management for risk and impact assessment and for automated approval generation. We extended discovery to capture load balancers and relate them to Applications.
Most recently, we integrated with our CloudOne platform. CloudOne isn’t necessarily a CMDB initiative, but it sits on top of it. CloudOne DevOps empowers developers via self-service to build cloud-aware applications using DevOps methodologies. For traditional application hosting, CloudOne IaaS enables provisioning and management of compute, storage, and load balancer assets in the public and private cloud, with cost control through Spot by NetApp and Smart Parking. All assets provisioned and managed via CloudOne live in the CMDB from order to retirement and are updated via scanning, including those hosted in Kubernetes clusters and DbaaS through StorageGrid.
What we’ve learned
Our CMDB will never be finished. It’s an organic, growing ecosystem of data that will always be in flux.
Implementing our CMDB hasn’t been an easy process and we’ve learned much from the journey:
– Don’t forget end-of-life automation, this helps keep the CMDB updated.
– Be wary of out-of-the-box security options, extra work may be required for your needs.
– Always discover, be prepared to invest in automation.
– Invest in healthy reporting and governance, data quality is paramount.
– Cloud Insights is a must-have for automatically updating data volumes and relationships
Done correctly, CMDBs make the lives of everyone who interact with your IT organization easier. However, if applications, processes or the CMDB aren’t mature enough, integrations may go poorly and negatively impact the enterprise. An iterative process that mindfully and deliberately builds on previous lessons is a set-up for success.