In previous blogs about flexibility in a DCIM software, we discussed the importance of being able to decide how to organize your Data Center documentation project hierarchies. In this blog, we will focus mainly on the hardware piece of this.
netTerrain DCIM provides a very flexible, n-layered, object-oriented hardware model, where the users have complete control over what a location, a rack, a device and a card constitute.
Why is this important? Because you don’t know which DCIM configuration situations you may encounter. There can be countless variations in terms of the location distribution. For instance, you could have a top level that consists of regions, some of them may contain sites, which could contain one or more buildings. The buildings can have several floors, and if those are large, you may break them down into rooms, with rack aisles, and so on. However, not all of your regions or sites may be the same. Would you then want to impose a specific rigid hierarchy on all of them, increasing complexity while sacrificing usability? Probably not.
As we mentioned in a blog about DCIM architecture, most DCIM software will impose a specific hierarchy because the internal architecture is not flexible.
Equally important is the flexibility required in the hardware components. To be fair, this is also key for network documentation and outside plant projects (as there is plenty of hardware involved in those projects as well).
We already know that each object type can have unlimited properties and behaviors, but from a hardware model point of view, netTerrain supports the following hierarchy, depicting the flexible nature of netTerrain:
The device, in this hierarchy, could be a network switch or router, a server, a patch panel and so on. Basically the chassis that you plug on the wall or you rackmount. The slot is the hole, or placeholder, in a chassis that allows for the insertion of what we call cards. In turn, cards can have slots all their own, where you could insert daughtercards and so on.
As we can see, this hierarchical model allows for any possible hardware scenario, real-world or imagined. Even the definition of a rack is very broad: it doesn’t really have to be an actual rack.
How is this designed in netTerrain? Through the catalog modeler. The catalog modeler provides the means to model any type of rack, with any set of dimensions, number of rack units and even the size of each unit. We wrote a blog not too long ago about that.
Rack Elevation View
We also wrote a blog about the process of modeling devices. Important to note here, if it wasn’t clear from that blog, is that the device modeler let’s you define not just slots for cards, and ports directly under the chassis, but a recursive unlimited hierarchy, with slots that can house cards that can in turn have slots underneath to insert daughtercards and so on, ad infinitum. Hence, with the modeler you are graphically representing the actual physical look and feel of the most complex and bizarre network or data center gear you can imagine, exactly as it looks in real life.
In terms of the cards, the netTerrain catalog provides a similar modeler. Cards are no different than devices: they can contain ports directly underneath but also slots that contain daughtercards and so on. The piece of the puzzle that glues these cards, daughtercards and so on to their parent hardware is a process that we call hardware mapping.
With hardware mapping you can assign business rules that can simplify the data entry in your DCIM project while at the same time adding a layer of consistency and error proofing. Using the case of devices and cards as an example. The process of hardware mapping consists of two steps:
- Identify a slot in the device (or card)
- Pick a card (or daughtercard) type that is allowed to be inserted in that slot
This hardware mapping process gives the end user two main advantages: the user only sees relevant cards that can be used, thus reducing clutter, and the system prevents the user from inserting the wrong type of card in the wrong slot.
In a subsequent blog, we will dig deeper into card modeling and hardware mapping and in the meantime, happy documenting!