Existe uma convenção de nomenclatura de host do servidor? [fechadas]

1

Para manter muitos servidores, como você atribui um nome aos seus servidores? Apenas pelo nome do host do servidor, eu gostaria de classificar o tipo de serviço do servidor, seja máquina virtual ou não, estágios (alfa, beta, real), especificações de hardware e assim por diante. Existe uma ideia?

    
por Benjamin 11.10.2012 / 07:58

2 respostas

7

Enquanto eu normalmente me movo para fechar uma pergunta como esta, esta questão em particular é uma que eu sinto muito strongmente, então eu vou morder.

Os esquemas de nomenclatura geralmente podem ser divididos em dois tipos: nomes mnemônicos e nomes funcionais.

Os nomes mnemônicos são nomes reutilizados de algum outro campo; Os personagens do Senhor dos Anéis são populares, assim como os elementos, e tenho certeza de que você já viu muitos outros; Eu mesmo sou a favor dos rios. Mas a coisa sobre nomes mnemônicos é que eles são todos nomes testados e testados de algum outro campo do esforço humano, e eles não incorporam nenhuma informação implícita sobre uma máquina. Eles são apenas nomes.

Nomes funcionais são nomes que incorporam alguma função da máquina, às vezes de forma simples (solaris-database-5.example.com), às vezes de forma mais opaca (s10db01.example.com). Em nomes funcionais, incluo nomes que não contêm nenhuma informação, desde que não sejam mnemônicos (s00345.example.com).

Na minha experiência, grupos e gerentes de TI adoram esquemas de nomeação funcionais. Mas a última vez que assumi a autoridade para fundar um esquema de nomes, fui e perguntei às pessoas que usariam esses nomes mais diariamente: os desenvolvedores.

De cerca de 40 desenvolvedores, todos, exceto um, disseram que preferiam nomes mnemônicos . Há algo sobre um bom nome que é fácil para o cérebro humano lembrar, e nós somos bem projetados para pendurar notas sobre a função nesses nomes (Steve Gregson mora ao lado. Steve é um padeiro. Steve dirige um Land Rover. me sua rebarbadora). Nós não somos, como espécie, bem projetados para pendurar estruturas de memória semelhantes em números aleatórios.

Como um esquema secundário , eles pediram que os nomes funcionais fossem incorporados nos registros CNAME. Então, cada host recebeu um nome mnemônico como nome principal; que viveu e morreu com o chassi; quando um chassi foi atualizado, ele recebeu um nome diferente. Mas os nomes funcionais ainda poderiam ser usados por qualquer pessoa para quem eles fossem apropriados e, como eram CNAMEs, muitos poderiam apontar para um único host.

Assim, os DBAs usariam pr1db01.example.com; os chaps de email usariam pr1ms01.example.com; os caras de aplicativos usariam pr1je03.example.com. Mas todos os três CNAMEs apontaram para o nile.example.com. Se uma função foi desativada, o CNAME foi reposicionado. Se o nile fosse atualizado, os CNAMEs apontariam para um chassi diferente. Mas quando você efetuou login no host, seja como pr1db01 ou pr1ms01, o prompt do sistema disse "nile". Quando enviei um e-mail dizendo que o Nilo iria de 2300 a 0330 no dia seguinte, todos liam o que precisavam para esse nome, porque o Nilo é um nome utilizável pelo homem, no qual é fácil para o cérebro bloquear registros internos. .

Isso é o que eu recomendo. E não se esqueça de que o DNS é um namespace hierárquico; use a hierarquia como parte do seu esquema de nomes, para simplificá-lo, se você precisar; sol1.dba.example.com pode ser um CNAME diferente para sol1.mail.example.com).

    
por 11.10.2012 / 08:42
1

Existem provavelmente tantos deles quanto organizações. A maioria das organizações que vi não nomeia servidores depois de suas funções, mas alguns o fazem (alguns apenas os numeram arbitrariamente). A localização do servidor é frequentemente adicionada, mas praticamente nunca vi alguém fazer isso com base em especificações de hardware.

Qualquer combinação de dados usada para criar um nome de servidor terá desvantagens iguais (particularmente, as informações serão longas e você precisará saber tudo para saber o nome do servidor). Você poderia, no entanto, usar algum tipo de código, como 2-4 caracteres do nome do serviço, opcional v para virtual, um caractere para o estágio (normalmente os nomes usados são dev, UAT e prod) e algum código que corresponde a o hardware. Talvez você possa nomear um controlador de domínio de produção como dc1pvnv522us. Ele pode ser decifrado e acho que está dentro dos requisitos de nomes legados, mas é feio.

Eu realmente não consigo pensar em nenhuma maneira prática de colocar especificações de hardware lá. Você poderia usar o número do modelo, mas isso não funcionaria para as VMs e não falaria sobre qualquer coisa que você tenha adicionado. Eu aconselharia contra isso. Normalmente, esse tipo de dado é gerenciado em detalhes usando algum tipo de sistema de inventário (talvez uma planilha ou talvez um software de rastreamento de ativos).

Já vi pessoas usarem localização e um código numérico de ativos antes (por exemplo, vax00313d para o servidor número 313 em Vauxhall, parte do ambiente dev; as especificações do servidor seriam mantidas em outro lugar) e também convenções como a função do servidor localização, ambiente e número de exclusividade são comuns (por exemplo, dc-vaxp1 para o primeiro DC de produção em Vauxhall).

Use tudo o que achar interessante, mas evite tentar armazenar muita informação em um nome de host.

    
por 11.10.2012 / 08:22