Scegliere tra nomi host significativi e senza significato [chiuso]


79

Supponi un ambiente con un cluster gestito da fantoccio di server diversi - vari hardware, software, sistemi operativi, virtuali / dedicati, ecc.

Sceglieresti nomi host significativi (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup, ecc.) O preferiresti nomi host privi di significato come personaggi di un libro o di un film?

Il problema che vedo con nomi host significativi è che i nomi di solito rappresentano un singolo servizio e se un server ha più di uno scopo diventa davvero disordinato (specialmente se i ruoli del server cambiano spesso).

La mappatura di un nome di servizio su un indirizzo IP e il mantenimento di tale mappatura non dovrebbe comportare il DNS?

Quali sono i vantaggi e gli svantaggi di entrambi gli approcci e quali problemi reali hai dovuto affrontare con l'approccio che hai scelto?


10
Se controlli il DNS, puoi sempre fare entrambe le cose.
jscott,

16
Lascio qui: RFC 1178
gelraen,

Sebbene superficialmente una domanda basata sull'opinione, le risposte effettive sono basate sui fatti con sondaggi empirici e sulla funzione cognitiva umana (come il cervello umano ricorda le cose). A mio avviso, questa domanda dovrebbe essere riaperta.
dotancohen,

Risposte:


98

Una volta ho avuto l'opportunità di decidere uno schema di denominazione. Così andai in giro e chiesi ai miei sviluppatori, che dopo tutto erano le persone che dovevano lavorare con questi nomi quotidianamente, se preferivano nomi funzionali (cioè nomi che rappresentano, in una forma codificata, il scopo della macchina) o nomi mnemonici (ovvero nomi tratti da uno schema di denominazione umana preesistente, che non conteneva alcun contenuto implicito sullo scopo della macchina).

Su 38 sviluppatori, 37 preferivano nomi mnemonici; solo un nome funzionale preferito. Quindi li ho chiamati tutti come fiumi (c'è un grande bacino di nomi possibili e molti di loro sono brevi, facili da ricordare e veloci da digitare).

Il cervello umano è abbastanza ben progettato per assegnare significato ai nomi. Se fornisci nomi che sono memorabili, le persone ricorderanno abbastanza rapidamente per cosa sono usati quei nomi e li useranno. Se usi nomi tratti da un background comune (ad es. Fiumi, elementi, stelle, contee, bevande, ottieni l'idea) aiuta le persone a riconoscere immediatamente un nome host dell'azienda quando lo incontrano; in caso contrario, dichiarazioni come "tutte le e-mail sono finite betelgeuse" possono essere un po 'confuse).

Al contrario, i miei sviluppatori pensavano di aver avuto difficoltà nei lavori precedenti a ricordare esattamente cosa pr1ms001fosse.

Ma dovrei aggiungere che abbiamo usato CNAME nel DNS interno per fornire un nome funzionale alla mappatura dei nomi mnemonici, quindi se hai davvero trovato più facile ricordare che il server di posta principale nel primo cluster nel sito PR era pr1ms001, allora il DNS avrebbe farti sapere che era attualmente orwell. Inoltre, ciò ci consente di avere molti nomi funzionali per macchina, quindi fintanto che hai sempre usato il nome funzionale relativo alla funzione su cui stavi lavorando, potresti essere sicuro che pr1imap001rimanderebbe sempre al server IMAP, anche se abbiamo spostato quella funzionalità da orwella rhine. E quando è hudsonmorto, potremmo cambiare il nome del sostituto senza influire sulle funzioni operative, in modo che non abbiamo mai avuto il "vuoi dire nuovo hudsono vecchio hudson?" confusione.


7
Potresti pensare che, ma i miei sviluppatori hanno detto che lo schema mnemonico era migliore indipendentemente dal fatto che fosse comunicata o meno qualcos'altro, perché tutti avevano costruito le proprie tabelle di stato interne di ciò che era dove, e quel tipo di memoria è più facile costruire su nomi che al cervello umano piace ricordare.
MadHatter,

11
Avresti dovuto chiamarli come vulcani in Islanda.
Chloe,

1
+1 per "pool of rivers";)
Konerak,

2
Questa è un'idea fantastica e la sto rubando.
SpacemanSpiff,

1
Sono d'accordo che la denominazione dei server in questo modo è più lavoro con un sistema di autobuild, ma rilevo che il punto di costruirli è per le altre persone di usarli - ei dati di cui sopra sono le persone che hanno dovuto usare loro. Può darsi che ciò che vogliono sia cambiato, ma penso che le nostre decisioni sull'amministratore del server debbano basarsi su qualcosa di più di ciò che semplifica il nostro lavoro.
MadHatter l'

93

Ciò dipende in gran parte dal fatto che i server lo siano petso livestock.

Gli animali domestici hanno nomi individuali. Sono distinti l'uno dall'altro e ci preoccupiamo per quelle differenze. Quando uno si ammala, di solito proviamo a riportarlo in salute. Tradizionalmente, i server sono stati animali domestici.

Il bestiame ottiene numeri. Sono per lo più identici e quali differenze ci sono, non ci interessa e di solito proviamo a minimizzare. Quando uno si ammala, lo mettiamo giù e ne prendiamo un altro. I server completamente virtualizzati, in particolare i server IaaS come AWS, sono bestiame.

Negli ambienti più complessi, hai un mix. I tuoi backend web, ad esempio, sono quasi sicuramente bestiame. Se hai bisogno di più, ne giri un po 'di più con la configurazione standard; se non ne hai bisogno, ne spegni alcuni. I tuoi server di database, in alcune configurazioni, sono animali domestici. Ci possono essere molte configurazioni speciali su ciascuna; potresti persino eseguirli su bare metal anziché sulla virtualizzazione.

Naturalmente, in entrambi gli ambienti, puoi nominare SERVIZI e indirizzarli direttamente. Questa è la migliore pratica in ogni caso; i tuoi sviluppatori non dovrebbero aver bisogno di sapere o preoccuparsi di quale sia l'effettivo nome host di un servizio. Il nome host dovrebbe essere un dettaglio puramente operativo. Pensa, quindi, alla codifica delle informazioni utili al tuo personale operativo nei nomi host - ad esempio, è spesso utile indicare in quale centro dati si trova un server.


22
Animali domestici o bestiame: è un bel modo di dirlo.
Michael Hampton

5
Recentemente ho ritrovato l'articolo in cui ho visto questo concetto per la prima volta in: gregarnette.com/blog/2012/05/cloud-servers-are-not-our-pets
Thaeli

Grazie @Ian ho cercato l'ultimo giorno per quell'articolo, SEO non riesce heh
Rudolf Olah

18

Questo è stato trattato qui prima ...

La mia raccomandazione è una combinazione di nomi funzionali e nomi mnemonici ...

Se si scrive un'applicazione e ha bisogno di affrontare ccts-logserver1, utilizzare quel nome in tutto, ma fare che un CNAME o un alias. Il vero nome host può essere quello che vuoi: un frutto o una verdura, una mitologia greca o un personaggio di Seinfeld ... ma ti dà una certa flessibilità quando devi associare nomi funzionali reali, ma conserva qualcosa che le persone possano ricordare.

Pensa all'esempio in cui mangoil server DB non funziona ... ma viene sostituito con qualcos'altro, diciamo peach. Forse i processi e le applicazioni esistenti devono vedere cmt-prod-db1. È possibile scambiare i sistemi, crearli senza conflitti di denominazione e rendere felici le applicazioni (e gli sviluppatori).


4

Dove lavoro gestiamo più siti, più aziende, in più città. Per noi i nomi mnemonici non possono funzionare. Invece usiamo un modulo abbreviato che descrive i nostri server. Questo funziona bene nel nostro caso in quanto abbiamo alcuni clienti che possono avere più uffici su domini diversi (o un singolo ufficio su più domini, o più uffici sullo stesso dominio, o tutto quanto sopra!)

Per noi, le informazioni contengono Azienda / Dominio, città, funzione, numero. Quindi, per un controller di dominio per azienda, dire Cypress a Chicago sarebbe:

CYPRCHDOM001 (Faremo riferimento a questo come DOM principale di Cypress in conversazione)

CYPRCHSQL001 sarebbe il suo server SQL, CYPRCHMGM001 sarebbe la sua gestione (cioè antivirus, backup, ecc.) E CYPRCHAPP001 sarebbe un server di applicazioni miste. Facile da ricordare, facile da ordinare, facile da insegnare.


1
Quindi, come ricordi quali applicazioni vengono eseguite su CYPRCHAPP001 rispetto a CYPRCHAPP003? Devo ammettere che questo è un problema anche con i nomi mnenomici, ma se stai cercando qualche tipo di nome funzionale, potrebbe anche essere specifico.
un CVn

2
@ MichaelKjörling I dettagli specifici di ciò che si trova su un server non appartengono a un nome, ma appartengono a una sorta di documentazione. Se qualcuno deve sapere cosa è in esecuzione su CYPRCHAPP001, legge la documentazione. Oltre allo spostamento delle applicazioni, CYPRCHAPP001_PointofSale_Payroll_HRSoftware-etc diventerà un termine improprio quando la società sposta il proprio software di gestione stipendi in una soluzione ospitata.
Wulfhart,

2
@Wulfhart Sono d'accordo con il punto, ma cosa c'è di sbagliato con avere CNAME per pointofsale, payrolle così via? In questo modo, nessuno, tranne i amministratori di sistema, deve preoccuparsi di sapere esattamente dove è in esecuzione il software del libro paga; per tutti gli altri, funziona e basta. Vuoi spostare qualcosa in un altro datacenter? Nessun problema. Vuoi spostare il database di sistema del punto vendita sul proprio server dedicato? Basta aggiornare pointofsale-databaseCNAME per puntare alla nuova posizione. E così via.
un CVn del

1
Supponiamo che tu debba sostituire una macchina: una volta che hai creato CYPRCHSQL002 e l'hai testato, devi semplicemente ritirare il nome CYPRCHSQL001 (mai da sostituire) o rinominare da 002 a 001 dopo aver rimosso il vecchio 001 o qualcosa del genere altro?
Nickgrim,

@ MichaelKjörling Mi sembra un'ottima idea. Con "i dettagli non appartengono a un nome" intendevo non nel nome host della macchina.
Wulfhart,

2

L'unico requisito per i nomi host è che dovrebbero essere univoci sulla rete.

Il significato non deve riguardare solo la funzione server. La posizione può essere molto utile se devi trattare con dispositivi fisici. Sapere se un dispositivo è virtuale o fisico può anche essere utile. Essere in grado di dire la differenza tra un dispositivo di rete, un server Linux o una finestra di Windows può essere molto utile quando si tratta di capire quale strumento utilizzare per accedere.

Il modo in cui lo gestiamo è provare a inserire queste informazioni nel nome del dispositivo come segue:

L o T - dal vivo o di prova P o V - S fisico o virtuale o N - Server o di rete (non abbiamo alcun server Linux) un numero sequenziale per garantire l'unicità Una tre lettere codice ISO 3166-1 che indica dove il dispositivo si trova.

Quindi utilizziamo CNAMES in DNS per mappare vari nomi di servizi attraverso il nome host.

Ho sentimenti contrastanti su questo. Fa sicuramente risparmiare tempo nel cercare dove si trova un determinato dispositivo. D'altra parte è molto più difficile ricordare cosa fa un determinato server quando viene presentato con il suo nome host, rispetto al nostro sistema precedente che utilizzava le pietre preziose. Le pietre preziose non implicavano alcun significato, ma erano facili da ricordare perché ogni persona poteva creare le proprie connessioni.

Immagino che l'unico consiglio sarebbe quello di accontentarsi di uno schema in quanto si è creata la più grande confusione quando siamo passati da un sistema all'altro.


Non sono d'accordo con questo: "Sapere se un dispositivo è virtuale o fisico può anche essere utile" nel contesto di una discussione sulla denominazione . Naturalmente sono informazioni utili, ma non è la prima cosa che devi sapere su un server dalla lettura del suo nome. Inoltre, P2V o V2P interrompono lo schema o richiedono la ridenominazione del server, che potrebbe interrompere altre cose.
mfinni,

1
Nella mia esperienza P2V o V2P rompe un sacco di cose e dovrebbe essere evitato ove possibile - lo facciamo, quindi non è un problema con la nostra convenzione di denominazione. La convenzione di denominazione deve soddisfare i requisiti di chiunque l'abbia progettata - nell'organizzazione in cui lavoro è stata progettata dal team che gestisce tutti i server e le apparecchiature di rete e vogliono essere in grado di dire le cose sopra. Potrebbe non essere giusto per te, ma poi è tutto aperto al dibattito. L'unico requisito tecnico è l'unicità.
Dunxd,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.