먼저, 이름 지정 체계를 선택하는 사람은 RFC 1178- "컴퓨터 이름 선택" 을 읽어야합니다. 사람들은 컴퓨터에 이름이 부여되어있는 한이 문제에 대해 이야기 해 왔으므로 바퀴를 다시 발명하기 전에 다른 사람들이 한 말을 읽어보십시오.
내 생각-나는 네이밍 정책을 테마 과 계획.
테마 사용 (예 : 그리스 신, Dr. Who의 캐릭터, 보드카 브랜드)는 작은 회로망. 호스트가 20 개 미만인 경우 여러 하드웨어 구성이있을 수 있습니다. 모든 호스트에 고유 한 구성이있을 수 있습니다. 그러한 경우, 기회가 있기 때문에 각 기계를 고유 한 성격을 갖는 것으로 생각하는 것이 좋습니다.
체계 사용 (예 : 지리적 위치, 랙 위치, 하드웨어 ID 등의 요소로 구성된 이름)는 동일한 하드웨어 및/또는 소프트웨어 구성을 가진 많은 수의 시스템이있는 경우 잘 작동합니다. 매일 기계를 다루지 않는 사람들과 기계에 대해 의사 소통 해야하는 경우에도 잘 작동합니다. 예를 들어 NOC 직원에게 기계를 재설정하도록 지시해야하는 경우 특정 레이블이있는 기계를 랙에서 검색하는 것보다 랙에서 기계를 찾는 데 도움이되는 이름이 더 좋습니다.
기능 이름 사용 (예 : 메일, 웹, 파일 서버)는 가상 머신에는 좋지만 내 경험에 따르면 실제 호스트에게는 좋지 않습니다. 물리적 호스트는 종종 여러 기능을 수행하게되며 (이상적이지 않더라도) 개별 기능은 시간이 지남에 따라 리소스 사용량과 요구 사항이 변경되어 다른 호스트로 마이그레이션됩니다.
테마 문제 포함:
- 그들은 일반적으로 작은 이름의 풀을 제공합니다. 로마 신이 부족하면 그리스어로 전환합니까? 이름 지정 테마에 맞는 은퇴 한 호스트의 이름을 재사용하거나 이름 재사용으로 인해 발생할 수있는 문제와 혼동을 피하기 위해 새 테마에서 새 이름을 선택합니까?
- 그들은 당신의 기계를 의인화시킵니다. 컴퓨터가 마음에 들지 않습니다. 기계가 서로 다른 개성을 가진 것처럼 취급한다면, 기계가 어떻게 행동하는지에 대한 가정과 상반되는 증거를 무시할 위험이 있으며 때로는 "기계가 잘못되어 특정 기계에 결함이 있다고 가정 할 때" 항상 오작동합니다. ".
계획의 문제 포함:
- 이로 인해 기억하기 어려운 호스트 이름이 생성됩니다. 시스템 관리가 잘되어 있으면 문제가 훨씬 적지 만 특정 시스템에서 특정 문제가 두 번 이상 발생했거나 특정 시스템이 담당하는 시스템임을 즉시 기억하는 것이 유용 할 때가 있습니다. 특정 기능 수행.
- 구성표가 변경되면 모든 호스트의 이름을 바꿔야 할 수도 있습니다. 이로 인해 많은 DNS 변경, 구성 변경, 액세스 목록 및 권한 변경 등이 발생할 수 있습니다.
현실 세계에서 두 시스템 모두 사용 중이며 때로는 나란히 있습니다. 예를 들어, 내 경험상 고성능 컴퓨팅 클러스터에는 항상 이름이 있습니다. 이름은 종종 헤드 노드 (대화식으로 사용됨)에 할당되는 반면 다양한 클러스터 노드는 compute-01, highmem-01, storage-01 등과 같은 이름을 갖습니다.
또한 앞에서 언급했듯이 가상 시스템과 물리적 호스트의 이름 지정 체계가 서로 다른 것이 일반적이며 유용합니다.
흥미로운 카테고리에는 스택 오버플로 답변 중 하나가 있습니다.
주기율표의 요소. 또한 IP 주소에 요소 번호를 사용하므로
수소 = 192.168.0.1
헬륨 = 192.168.0.2
기타.
나는 위치 (예 : 국가 코드/도시 코드/데이터 센터 코드/플로어/랙/랙 U 높이)로 물리적 서버의 이름을 지정하는 매우 강력한 신자입니다. 플랫폼/기능/클러스터/iterance). 나는 이것이 7 명의 드워프 또는 그 이후의 이름을 따서 이름을 짓는 것보다 이름을 더 길게 만들 수는 있지만, 당신 이보다 미래 지향적이며 가상화 된 방식으로 가상화를 다루는 좋은 방법입니다.
예를 들어 NESQLC11S08과 같은 게스트 서버 VM과 함께 044LONTH72G216 (세계에서 정확히 서버를 찾습니다)이라는 VMWare 서버가 있습니다. 더 길고 조직화 된 이름을 다시 언급하는 내부 IT 팀 작업을 위해 항상 짧은 이름을 만들 수 있습니다.
도움이 되었기를 바랍니다.
우리는 특정 주제 (성서의 책)로 서버 이름을 짓는 것으로 시작했지만 IT 팀 (및 서버 수)이 점점 더 전문화되면서 직원 이직률이 높아짐에 따라 모든 이름 지정 시스템이 어떻게 든 서버의 기능 (또는 위치)과 관련이 없었습니다.
사람들은 정기적으로 작업하는 서버를 알고 있었지만 새로운 프로젝트를 수행하거나 교차 교육을 받거나 다른 관리자를 도와 주려고 할 때 "psalms는 메일이라는 것을 아무도 알지 못했기 때문에 문제가 발생하지 않습니다. 서버 "등.
우리는 이제 더 설명적인 명명 체계로 다시 전환했습니다.
우리는 모든 서버 이름을 역할, 즉 서버의 역할에 따라 지정합니다.
따라서 서버 이름은
- PDC
- SQL
- EXCHANGE
- RDP
- FILE etc..
필자의 경험에 따르면 사람이 읽을 수없는 이름을 가진 서버 (예 : 구성표 방법)는 not 관리 가능합니다. 잘못 입력 된 문자를 보았을 때 잘못된 서버에 xyz 작업이 적용되어 때로는 위험한 결과를 초래했습니다.
설명 필드 등에 저장된 관련 메타 데이터가 포함 된 사람이 읽을 수있는 이름은 PEBKAC 문제가 덜 발생하는 것 같습니다.
우리는 2 microVAX 3400 클러스터가 회사에 큰 일이었던 시절에 Bert와 Ernie로 시작했습니다. Bigbird, Elmo, Grover, the count (금융 시스템)-Sesame Street와 잠시 동안 붙어 있었지만 결국 계획을 세워야했습니다. 체계에 어떤 요소가 있는지는 회사의 규모에 따라 다르며 다음을 포함해야했습니다.
위치 (도시의 2 글자 약어) 부서 (회사는 4 개의 회사를 합병하여 설립되었으므로 3 글자의 약어가있었습니다) 기능 (PDC, 메일, 인쇄, www 등) 일련 번호 (I '일련 번호의 일환으로 년과 월을 갖는 것을 항상 좋아했습니다.)
다년생 즐겨 찾기는 다음과 같습니다.
- 그리스 신들
- 로마 신들 (때로는 '식물들'과 구별 할 수없는)
- Norse gods (가장 잘못 행동 한 서버는 Loki 일 수 있음)
- 황색의 공주
- 철학자
심슨 캐릭터 :)
Playboy 토끼의 이름을 따서 서버 이름을 지정한 클라이언트가 한 번있었습니다. 그러나 IT 외부에서는 널리 공개되지 않았습니다. ;-)
나는 큰 고양이의 이름을 따서 이름을 짓는 것을 좋아했지만 OS X가 와서 나를 위해 그것을 망쳤습니다.
또 다른 인기는 알코올의 종류입니다. JimBeam, Beefeater, Stoli 등. 다른 종류의 알코올은 다른 종류의 서버였습니다. 메일 서버의 진, 데이터베이스의 위스키, PDC는 항상 Moonshine이었습니다.
올해는 새로운 시스템부터 시작하여 지루한 설명 이름 (메일, 인쇄물 등)을 사용하기 시작하지만 지금까지 조류, 물고기, 정글 동물 등 다양한 목적을 위해 다양한 유형의 동물과 함께 동물을 사용했습니다.
40 대 음악가.
그들은 종종 새로운 것을 계속 제공하기에 충분하게 변화하지만, 더 중요한 것은 12 세 이상의 사람들에게 충분히 암호가 될 것입니다.
우리 서버는 모두 애완 동물의 이름을 따서 명명되었습니다. 유형별로 약간의 고장이 있습니다. 모든 도메인 컨트롤러는 새 이름을 따서 명명되었습니다. 파일 및 인쇄용 개. 응용 프로그램 서버용 고양이.
우리는 회사 이니셜 다음에 작업과 번호, 즉 번호를 갖는 경향이 있습니다.
GSK-WEB-12
ST-DB-3
우리는 이것을 잘 사용합니다.
- 사이트 (2 자)
- dev/test/live (3/4 자)
- 기능 (3 자 이상)
- 개수 (2 자)
- vm 여부 (2 자)
내가했던 일에서 고전적인 server01, server02 등 이외의 트렌드를 보았습니다.
- 보석
- 물고기
- 꽃들
- 스타 워즈 캐릭터
- 동물
내가 공부하는 대학에서 그들은 Asterix와 Obelix 이야기와 다른 캐릭터의 이름을 사용합니다. miraculix, astmatix 등과 같은.