4 ms·
My naming system is pretty similar. Infrastructure consists of a handful of big beefy machines that then each host anywhere from 4 to 12 single purpose guest vm
by corford 12y ago
My naming system is pretty similar. Infrastructure consists of a handful of big beefy machines that then each host anywhere from 4 to 12 single purpose guest vms.
For the beefy host machines, I just go with core-a, core-b, core-c etc plus a geo tag. So: 'core-a.de.domain.local', 'core-b.de.domain.local' etc.
For the vms, they get functional names like 'n0-dbc1.de.domain.local' (for node0, database cluster 1) or 'git.de.domain.local' etc.
Only the last two digits of each guest vms mac address (or addresses if it has multiple eth interfaces) changes. The rest is tied to the underlying host machine. So e.g. 00:50:56:01:01:06 means a mac for a guest on 'core-a', 00:50:56:02:02:03 means a mac for a guest on 'core-b' etc.
All internal non-publicly routable IPs use our domain and the '.local' TLD (with bind serving our internal network). All external, publicly routable IPs use our domain and the .net TLD. Finally, our frontend website IPs use our domain and the .com TLD.
The above wont scale well beyond one or two hundred vms per data centre location but if we ever need more than that, it will be a nice problem to have :)
- btgeekboy 12y agoI'm guessing you don't use live migration of VMs very often?
- corford 12y agoNope, never. If a vm needs permanently moving from one core to another (which would be unusual for us), we just spin it down and dd the lvm volumes for that guest via ssh and then change the mac. It helps that we don't filter on mac. The main reason for tieing the addresses to the underlying core is to avoid accidentally allocating the same mac to two different vms (since at the moment vm creation is still a relatively manual process for us - hoping to improve this in the future though!).