Scegliere tra nomi host significativi e senza significato [chiuso]

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?

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.

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.

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).

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.

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.