1 / 8

New host naming policy

New host naming policy. IT-DSS feedback Collected by CERN ID: 57287 with contributions from 55023, 96271, 109353 and others. General 1/2. IT-DSS services use physical machines with physical devices attached (disk arrays, tape drives)

russ
Télécharger la présentation

New host naming policy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. New host naming policy IT-DSSfeedback Collected by CERN ID: 57287with contributions from55023, 96271, 109353 and others.

  2. General 1/2 • IT-DSS services use physical machines with physical devices attached (disk arrays, tape drives) • In multiple services, hosts do not change names during their production lifetime • Current host names contain physical location information • Examples: LXFSRD57A01, TPSRV655, LXBSP0722 • Speeds up physical interventions by simplifying machine localization • Different host names help service managers, SysAdmins and operators to be immediately aware of different services running on the machines • Examples: C2PUBLICSRV201, EOSLHCBSRV2, LXTSM614, AFS260 • Name suggests the service running on the machine • Name suggests the importance of the machine • If wrongly intervened on, can have cascading effect on many other machines

  3. General 2/2 • With the new policy, additional lookups in various databases will be needed • Adding administrative overhead in daily operations • While the machine unique information can be linked to the physical hardware for the duration of its lifetime, renaming should be allowed and be part of the service • Having 16 character long names is impractical in human (telephone) conversation while solving a problem • Cut & Paste is not always an option when dealingwith install failures / misbehaving machines

  4. Technical 1/2 • DNS was created to “most prominently translate easily memorized domain names to the numerical IP addresses” • Source: http://en.wikipedia.org/wiki/Domain_Name_System • Proposed policy is more complicated than IPv4 addresses • 15 digits vs. 4 bytes (even MAC address (6 bytes) would be simpler) • Various EDH documents vs. static CERN subnets • Random vs. sequential numbers • Proposed policy not only suggests the human unusable name, but also requests creation of DNS alias which should never change • Example: Interface name: P05153026178575.CERN.CH IP aliases: CD5153026-CR018016C • The DNS alias is however duplicating information from the name which may lead to inconsistencies • Wouldn’t the suggested (never changeable) DNS alias be sufficient?

  5. Technical 2/2 • Using DNS aliases • Machines / Applications are not aware of DNS aliases • Any application with central host catalog will use its hostname(rather than the alias name (AFS has tools like this)) • Monitoring would work but alarm follow-up would be more complex(alarms will still be sent with the hostname, not the alias name) • Procedures would need to be modified • It might lead to human errors (in high stress situations) on all support levelseven with correct procedures • The shell prompt includes the real hostname, not the alias name • When working with >5 prompts open, it is difficult to know which prompt to use (accident reboots of a production non-HA server instead of a new node install) • Applications require (significant) (re-)development • CASTOR User Privilege Validation daemon (CUPVD) is hostname based:stage st ^c2cmssrv10[1-2].cern.ch$ ^castorsrv[1-4]0[1-3].cern.ch$ TP_OPER

  6. Alternative proposal • All physical machines are equipped with IPMI board • Proposal: Use the main NIC for user names; use IPMI NIC for procurement team names • IPMI board stays with the system • User and procurement team naming spaces are separated and independent • (Idea drafted by Julien Leduc)

  7. Conclusion • The suggested policy helps hardware life-cycle management • Its deployment is affecting many other groups each having to deal with its own cost • Affected groups do not see clear benefits • Loosing track of machine history and protection against host name reuse should be solved in applications requiring this information • For example by using never changeable DNS aliasthat identifies the physical hardware • We thought about alternative solution separating user and procurement team host naming spaces • Host renames should be allowed • Service managers should be responsible for their services(including the host names)

  8. Summary for discussion • Problems • Scheme is human error prone (too many (random like) numbers) • Additional overhead / lookups required forinformation needed instantaneously (e.g. in emergency) • For role / importance / location of a machine • Procedures and tools need modifications • Verbal communication about hostnames becomes impossible • Aliases NOT a solution • Alarms come by their hostname • Prompts use hostname (confusing with multiple terminal windows) • Application with reverse lookup break or need modifications • Registration and management of aliases labor intensive • Machines might have more than 1 DNS alias, which one is the important one? • Proposals: • Use IPMI board NIC • Allow renames, but track procurement data with static DNS alias

More Related