From OpenDCIM Wiki
Jump to: navigation, search
(Fields)
(Device Templates)
Line 2: Line 2:
  
 
Device Templates are just what they sound like - templates for devices in your data center that you can assign to individual assets.  The purpose is to keep track of the common attributes - size, weight, and power profile - so that you don't have to remember them each time you rack up one in your data center.
 
Device Templates are just what they sound like - templates for devices in your data center that you can assign to individual assets.  The purpose is to keep track of the common attributes - size, weight, and power profile - so that you don't have to remember them each time you rack up one in your data center.
 +
 +
You can see a video tutorial of how to implement device templates at:
 +
{{#ev:youtube|2pqSDnL6Ixg}}
  
 
=== Database Information ===
 
=== Database Information ===

Revision as of 19:32, 21 February 2013

Device Templates

Device Templates are just what they sound like - templates for devices in your data center that you can assign to individual assets. The purpose is to keep track of the common attributes - size, weight, and power profile - so that you don't have to remember them each time you rack up one in your data center.

You can see a video tutorial of how to implement device templates at: {{#ev:youtube|2pqSDnL6Ixg}}

Database Information

The fac_DeviceTemplate table stores this data, and uses ManufacturerID as a foreign key from the fac_Manufacturer table.

Fields

  • TemplateID - An auto_increment field within MySQL that guarantees a unique ID. This is invisible to the users.
  • ManufacturerID - The users see a picklist of fac_Manufacturer.Name, but within this field is stored the foreign key of fac_Manufacturer.ManufacturerID.
  • Model - Simply a text description of the model of the system you are creating a template for.
  • Height - The height, in Rack Units (RU), which is roughly 1.75" per RU.
  • Weight - The maximum weight of this model of system. This is used to calculate capacity and center of gravity for individual cabinets. It's a good idea to enter the maximum weight, since you never know what options will be added in the future.
  • Wattage - This is the black magic portion of nearly all DCIM solutions. Rarely does what the manufacturer state in terms of wattage match up to real world scenarios. It definitely never matches up to what the power supplies are rated for. A good rule of thumb is to take the wattage of the minimum number of power supplies required to operate (so if you have 3, it may take 2 to operate in a non-redundant fashion) and multiply that total by 60%. Some applications will go over that amount, and some will go under. Depending on the diversity of uses in your data center, you may even want to create multiple templates for the same model - such as "Dell R710 - Low Utilization", "Dell R710 - Medium Utilization", and "Dell R710 - High Utilization".
  • Device Type - Whether this device is a server, storage, chassis, switch, etc. Certain device types will cause the application to behave differently. For instance, if a device is a switch, openDCIM will display a table to allow you to manage the connections. If the device is a chassis, it will allow you to enter child devices within the slots.
  • No. Power Supplies - This is what it sounds like - the total number of power supplies for this template.
  • No. Ports - The number of network ports, which should include management, network, and SAN, since those are the potential ports to document connecting to various switch devices.

Future Development

As with the fac_Manufacturer table, one of the development ideas is to add an opt-in synchronization function to allow users of openDCIM to collaborate and share their device templates. There is no scheduled date for this function, but if you would like to contribute to the effort, please let one of the developers know.

Return to the Main Page