Escolhendo entre nomes de host significativos e sem sentido [fechado]

Assuma um ambiente com um cluster gerenciado por fantoches de servidores diferentes - vários hardwares, softwares, sistemas operacionais, virtuais / dedicados etc.

Você escolheria nomes de host significativos (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup etc.) ou preferiria nomes de host sem sentido, como personagens de um livro ou filme?

O problema que vejo com nomes de host significativos é que os nomes geralmente representam um único serviço e, se um servidor tiver mais de um objetivo, ele ficará muito confuso (especialmente se as funções do servidor mudarem com frequência).

O mapeamento de um nome de serviço para um endereço IP e a manutenção do mapeamento que o DNS deve fazer?

Quais são as vantagens e desvantagens de ambas as abordagens e que problemas reais você teve que enfrentar com a abordagem escolhida?

Uma vez tive a oportunidade de decidir sobre um esquema de nomeação. Por isso, perguntei aos meus desenvolvedores, que afinal eram as pessoas que tinham que trabalhar com esses nomes diariamente, se preferiam nomes funcionais (ou seja, nomes que representam, de alguma forma codificada, o finalidade da máquina) ou nomes mnemônicos (ou seja, nomes extraídos de algum esquema de nomeação humano pré-existente, que não continha conteúdo implícito sobre a finalidade da máquina).

Dos 38 desenvolvedores, 37 preferiram nomes mnemônicos; apenas um nome funcional preferido. Então, eu os nomeei todos depois dos rios (há uma grande quantidade de nomes possíveis, e muitos deles são curtos, fáceis de lembrar e rápidos de digitar).

O cérebro humano é muito bem projetado para atribuir significado aos nomes. Se você fornecer nomes memoráveis, as pessoas lembrarão rapidamente para que esses nomes são usados ​​e os usarão. Se você usar nomes de algum contexto comum (por exemplo, rios, elementos, estrelas, condados, bebidas, você entendeu), isso ajudará as pessoas a reconhecer imediatamente o nome de host de uma empresa quando o encontrarem; caso contrário, declarações como "todo o email acabou betelgeuse" podem ser um pouco confusas).

Por outro lado, meus desenvolvedores achavam que eles tinham em trabalhos anteriores muito difícil lembrar exatamente o que pr1ms001era.

Mas devo acrescentar que usamos CNAMEs no DNS interno para fornecer um nome funcional ao mapeamento de nomes mnemônicos; portanto, se você realmente achou mais fácil lembrar que o servidor de email principal no primeiro cluster no site de relações públicas era pr1ms001, então o DNS que você saiba que isso era atualmente orwell. Além disso, temos muitos nomes funcionais por máquina, desde que você sempre use o nome da função relevante para a função em que estava trabalhando, você pode ter certeza de que pr1imap001sempre apontará para o servidor IMAP, mesmo que tenhamos movido essa funcionalidade de orwellpara rhine. E quando hudsonmorríamos, podíamos mudar o nome da substituição sem afetar as funções operacionais, para que nunca tivéssemos o "quer dizer novo hudsonou velho hudson?" confusão.

Isso se resume em grande parte ao fato de seus servidores serem petsou não livestock.

Animais de estimação recebem nomes individuais. Eles são distintos um do outro, e nós nos preocupamos com essas diferenças. Quando alguém fica doente, geralmente tentamos recuperar a saúde. Tradicionalmente, os servidores são animais de estimação.

Gado ganha números. Eles são praticamente idênticos, e com quais diferenças existem, não nos importamos e geralmente tentamos minimizar. Quando um fica doente, colocamos no chão e pegamos outro. Servidores totalmente virtualizados, especialmente servidores IaaS, como o AWS, são animais.

Nos ambientes mais complexos, você tem uma mistura. Seus back-end da web, por exemplo, são quase certamente gado. Se você precisar de mais, você aumenta um pouco mais com a configuração padrão; se você não precisar de tantos, desative alguns. Seus servidores de banco de dados, em algumas configurações, são animais de estimação. Pode haver muitas configurações especiais em cada uma; você pode até executá-los em bare metal em vez de virtualização.

Obviamente, em qualquer ambiente, você pode nomear SERVIÇOS e endereçá-los diretamente. Esta é uma prática recomendada em qualquer caso; seus desenvolvedores não precisam saber ou se importar com o nome real do host de um serviço. O nome do host deve ser um detalhe puramente operacional. Pense, então, em codificar informações que são úteis para a equipe de operações nos nomes de host - por exemplo, geralmente é útil indicar em qual datacenter o servidor está.

Isso foi abordado aqui antes ...

Minha recomendação é uma combinação de nomes funcionais e nomes mnemônicos ...

Se você estiver escrevendo um aplicativo e ele precisar ser endereçado ccts-logserver1, use esse nome por toda parte, mas faça dele um CNAME ou um alias. O nome do host real pode ser o que você quiser: uma fruta ou vegetal, mitologia grega ou personagem de Seinfeld ... mas oferece flexibilidade quando você precisa associar nomes funcionais reais, mas mantenha algo que as pessoas possam lembrar.

Pense no exemplo em que mangoo servidor do DB falha ... mas é substituído por outra coisa, digamos peach. Talvez os processos e aplicativos existentes precisem ver cmt-prod-db1. Você pode trocar os sistemas, construí-los sem conflitos de nome e manter os aplicativos (e desenvolvedores) felizes.

Onde trabalho, gerenciamos vários sites, várias empresas, em várias cidades. Para nós, nomes mnemônicos não podem funcionar. Em vez disso, usamos um formulário abreviado que descreve nossos servidores. Isso funciona bem no nosso caso, pois temos alguns clientes que podem ter vários escritórios em domínios diferentes (ou um único escritório em vários domínios, ou vários escritórios no mesmo domínio, ou todos os itens acima!)

Para nós, as informações contêm Empresa / Domínio, cidade, função, número. Portanto, para um controlador de domínio da empresa, digamos Cypress em Chicago, seria:

CYPRCHDOM001 (Nós nos referiríamos a isso como DOM principal do Cypress na conversa)

O CYPRCHSQL001 seria seu servidor SQL, o CYPRCHMGM001 seria seu gerenciamento (por exemplo, antivírus, backups etc.) e o CYPRCHAPP001 seria um servidor de aplicativos mistos. Fácil de lembrar, fácil de classificar, fácil de ensinar.

O único requisito para nomes de host é que eles sejam únicos na rede.

O significado não tem a ver apenas com a função de servidores. A localização pode ser muito útil se você precisar lidar com dispositivos físicos. Saber se um dispositivo é virtual ou físico também pode ser útil. Ser capaz de dizer a diferença entre um dispositivo de rede, um servidor Linux ou uma caixa do Windows pode ser muito útil quando se trata de descobrir qual ferramenta usar para fazer login.

A maneira como lidamos com isso é tentar colocar essas informações no nome do dispositivo da seguinte maneira:

L ou T - ao vivo ou teste P ou V - S ou N físico ou virtual - servidor ou rede (não temos servidores Linux) um número seqüencial para garantir a exclusividade Um código de país com três letras ISO 3166-1 indicando onde o dispositivo está localizado.

Em seguida, usamos CNAMES no DNS para mapear vários nomes de serviço até o nome do host.

Eu tenho sentimentos mistos sobre isso. Certamente economiza tempo ao procurar onde um determinado dispositivo está localizado. Por outro lado, é muito mais difícil lembrar o que um determinado servidor faz quando apresentado com seu nome de host, quando comparado ao nosso sistema anterior que usava pedras preciosas. As pedras preciosas não implicavam nenhum significado, mas eram fáceis de lembrar, porque cada pessoa podia criar suas próprias conexões.

Acho que o único conselho seria resolver um esquema à medida que surgisse a maior confusão quando passássemos de um sistema para outro.