Devices come in different shapes and sizes. When they are big, they can be ‘modular’ which means that they have so-called slots and cards. If you need to document your network with such devices, your IT documentation system should have the capability and granularity to model these slots and cards. In previous blogs, we’ve discussed a bit about devices and their subcomponents. In this blog, we will focus specifically on cards.
Usually in a DCIM or Network Documentation project, cards work in conjunction with their parent devices and are mapped to specific device slots. The basic difference between a card and a device is that a card is not rack mounted on a rack, but only positioned inside a device slot. Slots cannot be moved or resized (simply because it wouldn’t make much sense to do so, as when was the last time you could stretch a card on a router!).
To illustrate: a blade server chassis could be regarded as a device in your DCIM software or Network Mapping tool and the blade servers inside it are what we like to call cards (even though they can behave as servers in their own right as far as capabilities go).
A good DCIM or IT documentation software package not only gives you complete flexibility as to modeling this hardware exactly as it is in real life, by you, in minutes, but can also give you unlimited nesting levels (cards inside cards inside cards, etc.).
In netTerrain, you assign a card to a slot by simply selecting the slot, and then picking the card type to place in it, using the type drop down box. A properly designed netTerrain catalog will only provide you with valid options for a slot: a specific Cisco router will not only just show you Cisco card types that are compatible with that router, it will also limit which card type goes into which specific slot number.
Populating a slot with a card, as seen in the project
Once a card has been created, its ports are also created automatically (just as with a device). In netTerrain DCIM (or Logical), to see the ports and other subcomponents inside a card just double-click on it.
Card backplane with automatically created ports, as seen in the project
Predefined card properties
A flexible DCIM or IT documentation tool will allow you to model any number of properties, independently, for each different card type. netTerrain lets you do that in the catalog. However, there are a number of predefined system properties (or fields) that apply for all types. Cards, just like devices, have the same two predefined properties that are inherited from the catalog:
- Peak Power [W]: this is the predefined nameplate power assigned in the card modeler.
- Weight [lb]: this is the predefined static weight capacity assigned in the card modeler.
These properties can be overridden on an instance-by-instance basis. Also, users can create additional custom fields representing power readings (which can, in turn, be the result of a discovery or some other importing mechanism).
Card dimensions and power consumption can also be modeled, but they play a minor role in the project. Racks do not currently aggregate card name plate power figures, so we recommend that when you specify power for devices you should account for the maximum power when the device is fully loaded with cards. Also, since cards are mapped to slots, the card dimensions become irrelevant from a diagramming perspective, as the cards will automatically fit inside the slot the card is mapped to.
In addition to these system fields, it may also be convenient to have a predefined set of custom fields for all types, so that whenever a new hardware card type is created, these fields automatically apply to them. With this, you save yourself the effort of having to create these fields every time, for every new card type you add in the catalog.
In netTerrain you can create these default custom fields for cards in the catalog:
Defining default custom fields for cards
As a result, with a proper card modeling process and a catalog based on card templates your DCIM project is not only accurate and represents the hardware as it is in real life, but it also simplifies the documentation process by automating as many steps as possible.
In the next blog, we will dig deeper into the actual modeling process of cards in the netTerrain catalog.