Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Here are some general guidelines I try to abide by, based on mistakes I've made in the past.</p> <p>Never base your machine names on...</p> <ul> <li><p><strong>Hardware</strong> Machines get swapped out all the time, and you don't want to have to do too much work if you change from an IBM server, to a Sun server, to a Dell server.</p></li> <li><p><strong>Location</strong> Equipment and even entire server rooms can be moved based on business requirements or technical issues.</p></li> <li><p><strong>Intended Use</strong> As your product evolves, so too may the intended use of each server. Having a machine named "dbsrv" but eventually acts as a file server too, is confusing.</p></li> <li><p><strong>Owner</strong> The person who "owns" the equipment (an employee) can change, due to firings, layoffs, and moves within the company.</p></li> <li><p><strong>Subnet</strong> As I said before, labs can move, and so can subnets. One of the main goals of DNS is to free you from being tied to a specific IP address, so why tie yourself down needlessly?</p></li> </ul> <p>Now, some suggestions for the situation you described...</p> <ul> <li><p><strong>Machines spread across a region</strong> This is what subdomains are for in DNS. You could have "west.company.com" and "east.company.com".</p></li> <li><p><strong>Have one or many functions</strong> Don't name them based on intended use. If you name them based on some large collection of names--Greek gods, for example--you will eventually intuitively know that zeus.east means your master database server and apollo.west is your backup database server. Worst case, look it up in a spreadsheet.</p></li> <li><p><strong>Load-balanced or not</strong> You can take two approaches. You could have a unique name per node behind the load balancer, or you could do something like athena-1.east, athena-2.east, etc. Either way, a load balancer will (hopefully) free you from worrying too much about what each node is named.</p></li> <li><p><strong>Standby or not</strong> This doesn't sound like a criterion that should have an impact on the machine name.</p></li> </ul> <p>What I'm essentially saying is:</p> <ol> <li>Separate your equipment into different regional subdomains</li> <li>Choose a naming scheme with plenty of names (Greek gods in this example)</li> <li>Don't base the names on any of the criteria I mentioned above (intended use, location, etc.)</li> </ol> <p>Trying to do anything <em>more</em> than that will be more trouble than it's worth.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload