Using netbox as an AMS.

[9maf4you]

Hello, netbox team. I’d like to use Netbox as an assets management system.
The goals are:

• Keep track all assets we have
• Lifecycle of VM’s
• Batch of integrations

Seems netbox is mostly pretty good for it.

So, during my research I'm trying to model a case when several customers ( Tenants ) share same location ( Site-groups/Sites )

I've mapped:
Tenants as Customers.
Which maps perfectly

Site as DC in AZ ( in terms of Amazon )
..represents a building within a region and/or site group

Site Group as AZ ( in terms of Amazon )
..site groups may be used for functional grouping

Another thing I’m a bit confused about is Regions / Location / Sites & Clusters:

According wiki:

A computer cluster is a set of computers that work together so that they can be viewed as a single system. Unlike grid computers, computer clusters have each node set to perform the same task, controlled and scheduled by software.

Which means VM of cluster might be in different dc to have HA. But netbox’s Clusters doesn’t allow to bind more that one Site, Site-Group and region as well.

I can be tricky here and put VM’s with different role into a group and call it cluster, set a Region or/and Site, marks VM’s with Roles I need and finally join all Clusters into Cluster Group.

Probably the model I thinking about does not suited with that model netbox offers. Probably did it wrong way.
Could you please explain ideas why those cases are not possible

I’ll be appreciate if you share some idea how to implement my needs using netbox.

Thanks!

[candlerb]

I’d like to use Netbox as an assets management system.

Netbox isn't an asset management system - in particular it doesn't handle asset lifecycle, spares management, purchase history etc. Have a look at InvenTree, snipe-it, GLPI etc.

Netbox is intended to show where your assets are installed right now (or where you plan to install them soon), and the configuration that should be running on them, i.e. the desired configuration.

"Clusters" in Netbox are specifically for VM platforms where VMs are mobile between the hosts that comprise that cluster. If you want a cluster which spans multiple sites, then you leave the cluster "site" unset. If you're talking about a DR site, then that would imply that you have layer 2 mobility between the sites though, and probably storage mobility too. In many cases, DR is really a separate cluster.

"Roles" for VMs are usually used for the primary purpose that the VM is serving (e.g. "it's a firewall" or "it's a webserver"; or some people might use "prod" and "test"), rather than what hardware it's running on. But you can use them for whatever you like. Tags are even more general.

[9maf4you]

@candlerb Brian, thanks for quick response.
Sorry, I've been not so clear in my first message.
I'd like to use Netbox as asset management system partly to be honest. I mean we are totally in cloud so all ours assets are VMs.
So I'm looking for a tool to be aware of all our Clusters, VMs at glance. As well to represent their statuses during lifecycle: planned -> active -> offline, etc.
On top of it to build integration with saltstck, internal services and so on.

InvenTree, snipe-it, GLPI
Thanks I'll take a look.

[candlerb]

I mean we are totally in cloud so all ours assets are VMs

OK, then it's much simpler (and if you don't have any physical assets, you don't need an asset management system like those I listed)

I thought that in AWS, VMs are not transparently mobile between availability zones: you have different VPC subnets for each AZ, so you'd need to renumber a VM to move it. Some things like elastic IPs can attach to any AZ in a region though.

So you could either:

1. make each AZ a 'Site', and then use either 'Region' or 'Site Group' to group them into AWS Regions.
2. make each AWS Region a 'Site', and then use 'Location' within them to split into AZs

I think my inclination is to go with 2, because then there's a one-to-one relationship between the AWS name (e.g. "eu-west-1") and a Site. If you choose option 1 then the sites would be "eu-west-1a", "eu-west-1b" etc. But you're free to go either way.

If you have multiple AWS accounts, and they use overlapping private address space (e.g. 2 accounts both use 172.31.x.x) then you'll need to create separate VRFs for them. That can be the case at the Region level even within one account.

If your VMs are pretty static, then using Netbox to document what you have should be OK.

If you're creating VMs frequently by hand, then you should consider whether it would be better to push this through Netbox (e.g. creation of the VM in Netbox automatically creates the corresponding VM in AWS, via API). That needs some glue for the automation of course.

If you're creating VMs frequently through other means, e.g. auto-scaling groups or CloudFormation stacks, then Netbox may not be the best tool for the job. Netbox isn't supposed to be a portal on data which originates elsewhere, and stale data in Netbox is worse than no data. There are other ways you can make a real-time dynamic view of the VMs in your infrastructure: for example polling the AWS EC2 API to get a list of VMs, and then ingesting this into Prometheus/Grafana.

[9maf4you]

@candlerb Thanks, Brian for the detailed response. Appreciate it.
So, I'll try both cases and decide which one is best for us.