Vraag Kiezen tussen betekenisvolle en betekenisloze hostnamen [gesloten]


Veronderstel een omgeving met een door poppen beheerd cluster van verschillende servers - verschillende hardware, software, besturingssystemen, virtueel / dedicated, enz.

Zou je zinvolle hostnamen kiezen (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup, etc.) of zou je liever geen betekenisvolle hostnamen zoals karakters uit een boek of film gebruiken?

Het probleem dat ik zie met zinvolle hostnamen is dat namen meestal één service vertegenwoordigen en als een server meer dan één doel heeft, wordt het echt rommelig (vooral als serverrollen vaak veranderen).

Is het niet toewijzen van een servicenaam aan een IP-adres en het onderhouden van die toewijzing wat DNS zou moeten doen?

Wat zijn de voor- en nadelen van beide benaderingen en welke concrete problemen moet je aanpakken met de aanpak die je hebt gekozen?


74
2018-02-18 14:04


oorsprong


Als u DNS beheert, kunt u beide altijd doen. - jscott
Ik laat het hier gewoon achter: RFC 1178 - gelraen
Hoewel oppervlakkig een op opinie gebaseerde vraag, zijn de feitelijke antwoorden gebaseerd op feiten met empirische opiniepeilingen en gebaseerd op menselijke cognitieve functie (hoe het menselijk brein dingen onthoudt). Naar mijn mening zou deze vraag opnieuw moeten worden geopend. - dotancohen


antwoorden:


Er was eens in de gelegenheid een besluit te nemen over een naamgevingsschema. Dus ging ik rond en vroeg mijn ontwikkelaars, die immers de mensen waren die elke dag met deze namen moesten werken, of ze er de voorkeur aan gaven functioneel namen (dat zijn namen die in een gecodeerde vorm het doel van de machine weergeven) of ezelsbruggetje namen (dat wil zeggen, namen ontleend aan een reeds bestaand menselijk naamgevingsschema, dat geen impliciete inhoud bevatte over het doel van de machine).

Van de 38 ontwikkelaars gaven 37 de voorkeur aan mnemonic-namen; slechts één voorkeur functionele namen. Dus heb ik ze allemaal vernoemd naar rivieren (er is een zeer grote pool van mogelijke namen, en veel ervan zijn kort, gemakkelijk te onthouden en snel in te typen).

Het menselijk brein is behoorlijk goed ontworpen om betekenis aan namen te hechten. Als je namen opgeeft die gedenkwaardig zijn, onthouden mensen vrij snel waar die namen voor worden gebruikt en gebruiken ze die. Als je namen gebruikt die zijn getekend op een gemeenschappelijke achtergrond (bijv. Rivieren, elementen, sterren, provincies, drankjes, krijg je het idee), helpt het mensen om de hostnaam van een bedrijf onmiddellijk te herkennen wanneer ze het tegenkomen; anders zijn er uitspraken als "alle e-mail is terechtgekomen betelgeuse"kan een beetje verwarrend zijn).

Omgekeerd voelden mijn ontwikkelaars dat ze in eerdere banen het heel moeilijk hadden om te onthouden wat precies pr1ms001 was.

Maar ik moet hieraan toevoegen dat we CNAMEs in de interne DNS hebben gebruikt om een ​​functionele naam te geven voor mnemonic naamtoewijzing, dus als je het echt gemakkelijker vond om te onthouden dat de hoofdserver in het eerste cluster op de PR-site pr1ms001, dan laat de DNS je weten dat dat op dit moment was orwell. Ook, dat laat ons vele functionele namen per machine hebben, dus zolang je altijd de functionele naam gebruikte die relevant is voor de functie waar je aan werkte, zou je zeker kunnen zijn dat pr1imap001 zou altijd naar de IMAP-server wijzen, zelfs als we die functionaliteit hebben verplaatst orwell naar rhine. En wanneer hudson Toen we stierven, konden we de naam van de vervanging veranderen zonder de operationele functies te beïnvloeden, zodat we nooit de "bedoel je nieuw" hadden hudsonof oud hudson?" verwarring.


96
2018-02-18 14:10



Je zou dat misschien denken, maar mijn ontwikkelaars zeiden dat het mnemonisch schema beter was, of er nog iets anders werd gecommuniceerd, omdat ze allemaal hun eigen interne statustabellen bouwden van wat waar was, en dat soort geheugen is gemakkelijker te bouwen op namen die het menselijk brein houdt van onthouden. - MadHatter
Je had ze naar vulkanen in IJsland moeten vernoemen. - Chloe
+1 voor "pool of rivers";) - Konerak
Dit is een geweldig idee, en ik steel het. - SpacemanSpiff
Ik ben het ermee eens dat het benoemen van servers op deze manier meer werk met een autobuild-systeem is, maar ik merk op dat het punt waarop ze worden gebouwd is voor andere mensen om ze te gebruiken - en de bovenstaande gegevens zijn van de mensen die moesten gebruik hen. Het kan zijn dat wat ze willen, is veranderd, maar ik denk dat onze beslissingen op server-admin gebaseerd moeten zijn op meer dan wat ons werk gemakkelijk maakt. - MadHatter


Dit komt grotendeels neer op of uw servers zijn pets of livestock.

Huisdieren krijgen individuele namen. Ze zijn verschillend van elkaar en we geven om die verschillen. Als iemand ziek wordt, proberen we hem meestal weer gezond te maken. Traditioneel zijn servers huisdieren geweest.

Vee krijgt getallen. Ze zijn meestal identiek, en welke verschillen er zijn, we geven niet om en proberen meestal te minimaliseren. Wanneer iemand ziek wordt, leggen we het neer en krijgen er nog een. Volledig gevirtualiseerde servers, vooral IaaS-servers zoals AWS, zijn vee.

In de meeste complexe omgevingen heb je een mix. Uw webbackends zijn bijvoorbeeld vrijwel zeker vee. Als je meer nodig hebt, draai je er nog een paar met de standaardconfiguratie; als je niet zoveel nodig hebt, zet je er een paar af. Uw databaseservers zijn in sommige configuraties huisdieren. Er kan een heleboel speciale instellingen voor elk zijn; je kunt ze zelfs op blote metaal gebruiken in plaats van virtualisatie.

Natuurlijk, in beide omgevingen, kunt u SERVICES een naam geven en deze rechtstreeks aanspreken. Dit is in ieder geval een goede praktijk; uw ontwikkelaars hoeven niet te weten of te weten wat de werkelijke hostnaam van een service is. De hostnaam moet een puur operationeel detail zijn. Denk dan aan het coderen van informatie die nuttig is voor uw ops-personeel in de hostnamen - het is bijvoorbeeld vaak handig om aan te geven in welk datacenter een server zich bevindt.


93
2018-02-18 18:16



Huisdieren of vee - dat is een mooie manier om het te zeggen. - Michael Hampton♦
Ik heb onlangs het artikel opnieuw gevonden dat ik voor het eerst zag in dit concept: gregarnette.com/blog/2012/05/cloud-servers-are-not-our-pets - Ian
Bedankt @Ian ik heb gezocht naar de laatste dag voor dat artikel, SEO faalt heh - Rudolf Olah


Dit is hier eerder besproken ...

Mijn aanbeveling is een combinatie van functionele namen en mnemonic-namen ...

Als u een applicatie schrijft en deze moet adresseren ccts-logserver1, gebruik die naam overal, maar maak dat een CNAME of een alias. De echte hostnaam kan zijn wat je wilt: een fruit of een groente, een Griekse mythologie of een Seinfeld-personage ... maar het geeft je enige flexibiliteit als je echte functionele namen moet associëren, maar iets wilt behouden dat mensen zich kunnen herinneren.

Denk aan het voorbeeld waar mango, de DB-server faalt ... maar wordt bijvoorbeeld vervangen door iets anders peach. Misschien moeten bestaande processen en toepassingen zien cmt-prod-db1. Je kunt de systemen omwisselen, ze bouwen zonder conflicten te benoemen en de applicaties (en ontwikkelaars) tevreden houden.


18
2018-02-18 14:17





Waar ik werk, beheren we meerdere sites, meerdere bedrijven, in meerdere steden. Voor ons kunnen mnemonische namen niet werken. In plaats daarvan gebruiken we een steno-formulier dat onze servers beschrijft. Dit werkt goed in ons geval omdat we sommige clients hebben die meerdere kantoren op verschillende domeinen kunnen hebben (of een enkel kantoor op meerdere domeinen, of meerdere kantoren op hetzelfde domein, of al het bovenstaande!)

Voor ons bevat de informatie Bedrijf / Domein, stad, functie, nummer. Dus voor een domeincontroller voor bedrijven, zeg Cypress in Chicago, zou het zijn:

CYPRCHDOM001 (We zouden dit als een DOM van Cypress in gesprek noemen)

CYPRCHSQL001 zou zijn SQL-server zijn, CYPRCHMGM001 zou het beheer ervan zijn (dwz antivirus, back-ups, enz.) En CYPRCHAPP001 zou een gemengde applicatieserver zijn. Gemakkelijk te onthouden, gemakkelijk te sorteren, gemakkelijk te onderwijzen.


4
2018-02-18 18:31



Dus hoe weet je nog welke applicaties draaien op CYPRCHAPP001 in tegenstelling tot CYPRCHAPP003? Ik geef toe dat dit ook een probleem is met meneomic namen, maar als je voor een soort functionele namen gaat, kan het net zo goed specifiek zijn. - α CVn
@ MichaelKjörling Fijne korrelspecificaties van wat zich op een server bevindt, horen niet in een naam, ze horen in een soort documentatie. Als iemand moet weten wat er op CYPRCHAPP001 draait, lezen ze de documentatie. Naast het verplaatsen van applicaties zal CYPRCHAPP001_PointofSale_Payroll_HRSoftware-etc een verkeerde benaming zijn wanneer het bedrijf zijn payroll-software verplaatst naar een gehoste oplossing. - Wulfhart
@Wulfhart Ik ben het met je punt eens, maar wat is er mis met CNAME's voor pointofsale, payroll, enz.? Op die manier hoeven niemand anders dan de sysadmins zich bezig te houden met precies waar de salarissoftware draait; voor alle anderen werkt het gewoon. Wilt u iets naar een ander datacenter verplaatsen? Geen enkel probleem. Wilt u de database met kassasystemen naar een eigen dedicated server verplaatsen? Werk gewoon het pointofsale-database CNAME om naar de nieuwe locatie te wijzen. Enzovoorts. - α CVn
Stel dat je een machine moet vervangen: als je eenmaal CYPRCHSQL002 hebt gebouwd en hebt getest, stop je gewoon de naam CYPRCHSQL001 (moet je nooit vervangen), of hernoem je 002 tot 001 nadat je de oude 001 hebt verwijderd, ofzo anders? - nickgrim
@ MichaelKjörling Dat lijkt mij een geweldig idee. Door "specifieke kenmerken horen niet in een naam" bedoel ik niet in de hostnaam van de machine. - Wulfhart


De enige eis voor hostnamen is dat ze uniek moeten zijn op het netwerk.

De betekenis hoeft niet alleen te maken te hebben met de functie van de server. Locatie kan erg handig zijn als je te maken hebt met fysieke apparaten. Weten of een apparaat virtueel of fysiek is, kan ook nuttig zijn. Het verschil kunnen zien tussen een netwerkapparaat, een linux-server of een Windows-box kan erg handig zijn als het erom gaat uit te zoeken welk hulpprogramma je moet gebruiken om in te loggen.

De manier waarop we het verwerken is om te proberen deze informatie als volgt in de naam van het apparaat te zetten:

L of T - Live of Test P of V - fysiek of virtueel S of N - Server of netwerk (we hebben geen Linux-servers) een volgnummer om de uniekheid te waarborgen Een ISO 3166-1 drieletterige landcode aangeven waar het apparaat zich bevindt.

Vervolgens gebruiken we CNAMES in DNS om verschillende servicenamen door te geven aan de hostnaam.

Ik heb hier gemengde gevoelens over. Het bespaart zeker tijd doordat je moet opzoeken waar een bepaald apparaat zich bevindt. Aan de andere kant is het veel moeilijker om te onthouden wat een bepaalde server doet wanneer het wordt gepresenteerd met zijn hostnaam, in vergelijking met ons vorige systeem dat edelstenen gebruikte. De edelstenen hadden helemaal geen betekenis, maar ze waren gemakkelijk te onthouden omdat elke persoon zijn eigen verbindingen kon creëren.

Ik denk dat het enige advies zou zijn om genoegen te nemen met één schema, omdat de grootste verwarring ontstond toen we van het ene systeem naar het andere overgingen.


2
2018-02-19 15:18



Ik ben het hier niet mee eens: "Weten of een apparaat virtueel of fysiek is, kan ook nuttig zijn" in de context van een naamgeving discussie. Natuurlijk is het nuttige informatie, maar het is niet het eerste dat u moet weten over het feit dat een server zijn naam leest. Verder breekt P2V of V2P uw schema, of vereist het hernoemen van de server, wat andere dingen kan breken. - mfinni
In mijn ervaring breekt P2V of V2P een heleboel dingen en moet waar mogelijk worden vermeden - dat doen we, vandaar dat het geen probleem is met onze naamgevingsconventie. De naamgevingsconventie moet voldoen aan de vereisten van degene die het heeft ontworpen - in de organisatie waarin ik werk, is het team ontworpen dat alle servers en netwerkapparatuur beheert en zij willen bovenstaande dingen kunnen vertellen. Het is misschien niet goed voor u, maar dan is het allemaal open voor debat. De enige technische vereiste is uniciteit. - dunxd