การเลือกระหว่างชื่อโฮสต์ที่มีความหมายและไร้ความหมาย [ปิด]

79

สมมติสภาพแวดล้อมด้วยคลัสเตอร์ที่จัดการโดยหุ่นกระบอกของเซิร์ฟเวอร์ที่แตกต่างกัน - ฮาร์ดแวร์ซอฟต์แวร์ระบบปฏิบัติการเสมือน / โดยเฉพาะเป็นต้น

คุณจะเลือกชื่อโฮสต์ที่มีความหมาย (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup, ฯลฯ ) หรือคุณต้องการชื่อโฮสต์ที่ไม่มีความหมายเช่นตัวละครจากหนังสือหรือภาพยนตร์?

ปัญหาที่ฉันเห็นด้วยชื่อโฮสต์ที่มีความหมายคือชื่อมักจะเป็นตัวแทนของบริการเดียวและถ้าเซิร์ฟเวอร์มีวัตถุประสงค์มากกว่าหนึ่งวัตถุประสงค์มันจะยุ่งเหยิงจริงๆ (โดยเฉพาะถ้าบทบาทเซิร์ฟเวอร์เปลี่ยนบ่อย)

การแมปชื่อบริการกับที่อยู่ IP และการบำรุงรักษาการแมปนั้นควรทำอะไร DNS

อะไรคือข้อดีและข้อเสียของวิธีการทั้งสองและคุณมีปัญหาอะไรจริงต้องจัดการกับวิธีการที่คุณเลือก?

configuration-management best-practices

— keymone
แหล่งที่มา

10

หากคุณควบคุม DNS คุณสามารถทำได้ทั้งสองอย่าง

— jscott

16

ฉันจะทิ้งไว้ที่นี่: RFC 1178

— gelraen

แม้ว่าจะเป็นคำถามเชิงความคิดเห็นเพียงเล็กน้อย แต่คำตอบที่แท้จริงนั้นมีพื้นฐานจากการสำรวจเชิงประจักษ์และตามหน้าที่การรับรู้ของมนุษย์ (สมองของมนุษย์จดจำสิ่งต่าง ๆ ได้อย่างไร) ในความคิดของฉันคำถามนี้ควรจะเปิดใหม่

— dotancohen

98

กาลครั้งหนึ่งฉันมีโอกาสที่จะตัดสินใจเกี่ยวกับรูปแบบการตั้งชื่อ ดังนั้นฉันจึงไปและถามนักพัฒนาของฉันซึ่งหลังจากนั้นทุกคนเป็นคนที่ต้องทำงานกับชื่อเหล่านี้ในแต่ละวันไม่ว่าพวกเขาจะชอบชื่อฟังก์ชั่น (นั่นคือชื่อที่เป็นตัวแทนในรูปแบบที่เข้ารหัส) จุดประสงค์ของเครื่อง) หรือชื่อช่วยในการจำ (นั่นคือชื่อที่ดึงมาจากโครงร่างการตั้งชื่อมนุษย์ที่มีอยู่แล้วบางรายการซึ่งไม่มีเนื้อหาโดยนัยเกี่ยวกับจุดประสงค์ของเครื่อง)

จากนักพัฒนา 38 คน 37 ชื่อที่ต้องการช่วยในการจำ ชื่อฟังก์ชันที่ต้องการหนึ่งชื่อเท่านั้น ดังนั้นฉันจึงตั้งชื่อพวกเขาทั้งหมดตามแม่น้ำ (มีสระว่ายน้ำขนาดใหญ่มากของชื่อที่เป็นไปได้และหลายคนสั้นจำง่ายและพิมพ์เร็ว)

สมองของมนุษย์นั้นได้รับการออกแบบมาอย่างดีสำหรับการแนบความหมายกับชื่อ หากคุณให้ชื่อที่น่าจดจำคนจะจำได้อย่างรวดเร็วว่าชื่อเหล่านั้นถูกใช้เพื่ออะไรและใช้ชื่อเหล่านั้น หากคุณใช้ชื่อที่ดึงมาจากพื้นหลังทั่วไป (เช่นแม่น้ำองค์ประกอบดวงดาวมณฑลเครื่องดื่มคุณจะได้รับความคิด) มันช่วยให้ผู้คนจำชื่อโฮสต์ของ บริษัท ได้ทันทีเมื่อพบเจอ มิฉะนั้นข้อความเช่น "อีเมลทั้งหมดที่ลงเอยด้วยbetelgeuse" อาจทำให้สับสนเล็กน้อย)

ในทางกลับกันนักพัฒนาของฉันรู้สึกว่าพวกเขามีงานก่อนหน้านี้มีช่วงเวลาที่ยากลำบากอย่างมากในการจดจำสิ่งที่pr1ms001เป็น

แต่ฉันควรเพิ่มว่าเราใช้ CNAME ใน DNS ภายในเพื่อให้ชื่อที่ใช้งานได้เพื่อการจับคู่ชื่อช่วยในการจำดังนั้นถ้าคุณพบว่ามันง่ายกว่าที่จะจำได้ว่าเซิร์ฟเวอร์เมลหลักของคลัสเตอร์แรกที่ไซต์ PR คือpr1ms001DNS orwellแจ้งให้ทราบว่าที่เป็นอยู่ในปัจจุบัน นอกจากนี้ยังช่วยให้เรามีชื่อการใช้งานมากมายต่อเครื่องตราบใดที่คุณใช้ชื่อฟังก์ชันที่เกี่ยวข้องกับฟังก์ชั่นที่คุณกำลังทำงานอยู่เสมอคุณสามารถมั่นใจได้ว่าpr1imap001จะชี้ไปที่เซิร์ฟเวอร์ IMAP เสมอแม้ว่าเราจะย้ายฟังก์ชันการทำงานนั้น จากการorwell rhineและเมื่อhudsonเสียชีวิตเราสามารถเปลี่ยนชื่อของการเปลี่ยนโดยไม่ส่งผลกระทบต่อฟังก์ชั่นการทำงานดังนั้นเราจึงไม่เคยมี "คุณหมายถึงใหม่hudsonหรือเก่าhudsonหรือไม่" ความสับสน

— MadHatter
แหล่งที่มา

7

คุณอาจคิดว่า แต่นักพัฒนาของฉันบอกว่ารูปแบบช่วยในการจำดีกว่าว่าจะสื่อสารอะไรอีกหรือไม่เพราะพวกเขาทุกคนสร้างตารางสถานะภายในของตัวเองว่าอะไรอยู่ที่ไหนและหน่วยความจำประเภทนั้นง่ายต่อการสร้างชื่อที่ สมองมนุษย์ชอบจดจำ

— MadHatter

11

คุณควรตั้งชื่อพวกมันตามภูเขาไฟในไอซ์แลนด์

— Chloe

1

+1 สำหรับ "สระว่ายน้ำของแม่น้ำ";)

— Konerak

2

นี่เป็นความคิดที่ยอดเยี่ยมและฉันก็ขโมยมัน

— SpacemanSpiff

1

ฉันยอมรับว่าการตั้งชื่อเซิร์ฟเวอร์ด้วยวิธีนี้จะทำงานได้มากขึ้นกับระบบ autobuild แต่ฉันสังเกตว่าจุดสร้างพวกเขานั้นมีไว้สำหรับคนอื่น ๆ ที่จะใช้พวกเขา - และข้อมูลข้างต้นมาจากคนที่ต้องใช้พวกเขา อาจเป็นไปได้ว่าสิ่งที่พวกเขาต้องการเปลี่ยนไป แต่ฉันคิดว่าการตัดสินใจของเราเกี่ยวกับผู้ดูแลระบบเซิร์ฟเวอร์ควรมีการบอกกล่าวล่วงหน้ามากกว่าสิ่งที่ทำให้งานของเราง่ายขึ้น

— MadHatter

93

สิ่งนี้ส่วนใหญ่เกิดขึ้นกับเซิร์ฟเวอร์ของคุณpetsหรือlivestockไม่

สัตว์เลี้ยงได้รับชื่อบุคคล พวกเขาแตกต่างกันและเราใส่ใจกับความแตกต่างเหล่านั้น เมื่อมีคนป่วยเรามักจะพยายามพยาบาลให้กลับมามีสุขภาพดี ตามเนื้อผ้าเซิร์ฟเวอร์เป็นสัตว์เลี้ยง

ปศุสัตว์รับตัวเลข พวกเขาส่วนใหญ่เหมือนกันและมีความแตกต่างอะไรเราไม่สนใจและมักจะพยายามลดให้น้อยที่สุด เมื่อมีคนป่วยเราก็วางมันลงแล้วก็เอาอีกอัน เซิร์ฟเวอร์เสมือนจริงอย่างสมบูรณ์โดยเฉพาะเซิร์ฟเวอร์ IaaS เช่น AWS นั้นเป็นปศุสัตว์

ในสภาพแวดล้อมที่ซับซ้อนที่สุดคุณมีส่วนผสม ยกตัวอย่างเช่นเว็บแบ็กเอนด์ของคุณนั้นเกือบจะหมดแล้ว หากคุณต้องการมากกว่านี้คุณจะเพิ่มอีกสองสามครั้งด้วยการกำหนดค่ามาตรฐาน หากคุณไม่ต้องการมากนักคุณจะปิด เซิร์ฟเวอร์ฐานข้อมูลของคุณในการกำหนดค่าบางอย่างเป็นสัตว์เลี้ยง อาจมีการตั้งค่าพิเศษจำนวนมากในแต่ละครั้ง คุณอาจใช้มันกับโลหะเปลือยแทนที่จะใช้ virtualization

แน่นอนในสภาพแวดล้อมทั้งสองคุณสามารถตั้งชื่อบริการและที่อยู่เหล่านั้นโดยตรง นี่เป็นวิธีปฏิบัติที่ดีที่สุดในทุกกรณี นักพัฒนาของคุณไม่จำเป็นต้องรู้หรือสนใจว่าชื่อโฮสต์ที่แท้จริงของบริการคืออะไร ชื่อโฮสต์ควรเป็นรายละเอียดการทำงานอย่างแท้จริง คิดว่าจากการเข้ารหัสข้อมูลที่เป็นประโยชน์กับเจ้าหน้าที่ ops ของคุณในชื่อโฮสต์ - ตัวอย่างเช่นมักจะมีประโยชน์ในการแสดงว่าศูนย์ข้อมูลใดที่เซิร์ฟเวอร์อยู่

— Thaeli
แหล่งที่มา

22

สัตว์เลี้ยงหรือปศุสัตว์ - เป็นวิธีที่ดีที่จะวางไว้

— Michael Hampton

5

ฉันเพิ่งพบบทความที่ฉันเห็นแนวคิดนี้ครั้งแรกอีกครั้งใน: gregarnette.com/blog/2012/05/cloud-servers-are-not-our-pets

— Thaeli

ขอบคุณ @Ian ฉันได้ตามล่าหาวันสุดท้ายสำหรับบทความนั้น SEO ล้มเหลวเหรอ

— Rudolf Olah

18

สิ่งนี้ได้ถูกกล่าวถึงก่อนหน้านี้ ...

คำแนะนำของฉันคือการรวมกันของชื่อการทำงานและชื่อช่วยในการจำ ...

หากคุณกำลังเขียนแอปพลิเคชันและจำเป็นต้องระบุที่อยู่ccts-logserver1ให้ใช้ชื่อนั้นตลอด แต่ทำให้เป็น CNAME หรือชื่อแทน ชื่อโฮสต์ที่แท้จริงอาจเป็นอะไรก็ได้ที่คุณต้องการไม่ว่าจะเป็นผลไม้หรือผักตำนานกรีกหรือตัวละคร Seinfeld แต่มันให้ความยืดหยุ่นเมื่อคุณต้องการเชื่อมโยงชื่อที่ใช้งานได้จริง แต่เก็บสิ่งที่ผู้คนจำได้

คิดว่าตัวอย่างที่mangoเซิร์ฟเวอร์ฐานข้อมูลล้มเหลว ... peachแต่จะถูกแทนที่ด้วยสิ่งอื่นพูด cmt-prod-db1บางทีอาจจะเป็นกระบวนการที่มีอยู่และการใช้งานต้องดู คุณสามารถสลับระบบสร้างมันได้โดยไม่ต้องตั้งชื่อความขัดแย้งและทำให้แอปพลิเคชัน (และนักพัฒนา) มีความสุข

— ewwhite
แหล่งที่มา

4

ฉันทำงานที่ไหนเราจัดการเว็บไซต์หลายแห่ง บริษัท หลายแห่งในหลายเมือง สำหรับเราชื่อช่วยจำไม่สามารถทำงานได้ แต่เราใช้แบบฟอร์มย่อที่อธิบายเซิร์ฟเวอร์ของเรา สิ่งนี้ทำงานได้ดีในกรณีของเราเนื่องจากเรามีลูกค้าบางรายที่อาจมีสำนักงานหลายแห่งในโดเมนที่แตกต่างกัน (หรือสำนักงานเดียวในหลายโดเมนหรือสำนักงานหลายแห่งในโดเมนเดียวกันหรือทั้งหมดข้างต้น!)

สำหรับเราข้อมูลนั้นมี บริษัท / โดเมน, เมือง, ฟังก์ชั่น, หมายเลข ดังนั้นสำหรับตัวควบคุมโดเมนสำหรับ บริษัท พูด Cypress ในชิคาโกมันจะเป็น:

CYPRCHDOM001 (เราจะเรียกสิ่งนี้ว่า DOM หลักของ Cypress ในการสนทนา)

CYPRCHSQL001 จะเป็นเซิร์ฟเวอร์ SQL ส่วน CYPRCHMGM001 จะเป็นการจัดการ (เช่นป้องกันไวรัสสำรองข้อมูล ฯลฯ ) และ CYPRCHAPP001 จะเป็นเซิร์ฟเวอร์แอปพลิเคชันผสม จำง่ายเรียงง่ายสอนง่าย

— โรคนอนไม่หลับ
แหล่งที่มา

1

ดังนั้นคุณจะจำแอปพลิเคชันใดที่ทำงานบน CYPRCHAPP001 ซึ่งต่างจาก CYPRCHAPP003 อย่างไร ฉันจะยอมรับว่านี่เป็นปัญหาเกี่ยวกับชื่อ mnenomic ด้วยเช่นกัน แต่ถ้าคุณจะใช้ชื่อฟังก์ชั่นบางอย่างอาจจะเฉพาะเจาะจงด้วย

— CVn

2

@ MichaelKjörlingข้อมูลเฉพาะที่ละเอียดของสิ่งที่อยู่บนเซิร์ฟเวอร์ไม่ได้อยู่ในชื่อพวกเขาอยู่ในเอกสารบางประเภท หากมีคนต้องการรู้ว่าสิ่งที่ทำงานอยู่ใน CYPRCHAPP001 พวกเขาอ่านเอกสาร นอกจากการย้ายแอปพลิเคชันแล้ว CYPRCHAPP001_PointofSale_Payroll_HRSoftware-etc จะเป็นผู้เรียกชื่อผิดเมื่อ บริษัท ย้ายซอฟต์แวร์บัญชีเงินเดือนไปยังโซลูชันที่โฮสต์

— Wulfhart

2

@Wulfhart ผมเห็นด้วยกับจุดของคุณ แต่สิ่งที่ผิดกับการมี CNAME สำหรับผู้รับpointofsale, payrollฯลฯ ? ด้วยวิธีนี้ไม่มีใครยกเว้น sysadmins ต้องกังวลตัวเองกับที่ทำงานซอฟต์แวร์เงินเดือน สำหรับคนอื่นมันใช้งานได้ ต้องการย้ายบางสิ่งไปยังดาต้าเซ็นเตอร์อื่นหรือไม่ ไม่มีปัญหาเลย. ต้องการย้ายฐานข้อมูลระบบจุดขายไปยังเซิร์ฟเวอร์เฉพาะของตนเองหรือไม่ เพียงอัปเดตpointofsale-databaseCNAME ให้ชี้ไปที่ตำแหน่งใหม่ และอื่น ๆ

— CVn

1

สมมติว่าคุณต้องเปลี่ยนเครื่อง: เมื่อคุณสร้าง CYPRCHSQL002 และทดสอบแล้วคุณจะเกษียณชื่อ CYPRCHSQL001 (ไม่ต้องเปลี่ยน) หรือเปลี่ยนชื่อ 002 เป็น 001 หลังจากลบ 001 เก่าหรืออะไรบางอย่าง อื่น?

— nickgrim

@ MichaelKjörlingดูเหมือนว่าเป็นความคิดที่ดีสำหรับฉัน โดย "เฉพาะไม่ได้อยู่ในชื่อ" ฉันหมายถึงไม่ได้อยู่ในชื่อโฮสต์ของเครื่อง

— Wulfhart

2

ข้อกำหนดเพียงอย่างเดียวสำหรับชื่อโฮสต์ก็คือควรจะไม่ซ้ำกันในเครือข่าย

ความหมายไม่จำเป็นต้องเกี่ยวข้องกับฟังก์ชั่นเซิร์ฟเวอร์เท่านั้น ตำแหน่งจะมีประโยชน์มากหากคุณต้องจัดการกับอุปกรณ์ทางกายภาพ การรู้ว่าอุปกรณ์นั้นเป็นเสมือนจริงหรือทางกายภาพก็สามารถมีประโยชน์ ความสามารถในการบอกความแตกต่างระหว่างอุปกรณ์เครือข่ายเซิร์ฟเวอร์ linux หรือกล่อง windows อาจเป็นประโยชน์อย่างมากเมื่อต้องค้นหาเครื่องมือที่จะใช้ในการเข้าสู่ระบบ

วิธีที่เราจัดการคือพยายามใส่ข้อมูลนี้ในชื่ออุปกรณ์ดังนี้:

L หรือ T - Live หรือทดสอบ P หรือ V - ฟิสิคัลหรือเวอร์ชวล S หรือ N - เซิร์ฟเวอร์หรือเครือข่าย (เราไม่มีเซิร์ฟเวอร์ Linux ใด ๆ ) ตามลำดับหมายเลขเพื่อให้แน่ใจว่าไม่ซ้ำกันรหัสประเทศ ISO 3166-1 สามตัวอักษรระบุตำแหน่งของอุปกรณ์ ตั้งอยู่.

จากนั้นเราจะใช้ CNAMES ใน DNS เพื่อจับคู่ชื่อบริการต่างๆกับชื่อโฮสต์

ฉันรู้สึกสับสนเกี่ยวกับเรื่องนี้ ช่วยประหยัดเวลาในการค้นหาที่ตั้งของอุปกรณ์ ในทางกลับกันมันยากกว่ามากที่จะจดจำสิ่งที่เซิร์ฟเวอร์ที่ให้ไว้ทำเมื่อนำเสนอด้วยชื่อโฮสต์เมื่อเปรียบเทียบกับระบบก่อนหน้าของเราซึ่งใช้อัญมณี อัญมณีนั้นไม่ได้มีความหมายใด ๆ เลย แต่พวกเขาจำได้ง่ายเพราะแต่ละคนสามารถสร้างการเชื่อมต่อของตนเองได้

ฉันเดาว่าคำแนะนำเพียงอย่างเดียวก็คือให้ใช้สคีมาหนึ่งอันเนื่องจากความสับสนที่ยิ่งใหญ่ที่สุดเกิดขึ้นเมื่อเราเปลี่ยนจากระบบหนึ่งไปเป็นอีกระบบหนึ่ง

— dunxd
แหล่งที่มา

ฉันไม่เห็นด้วยกับสิ่งนี้: "การรู้ว่าอุปกรณ์เป็นเสมือนจริงหรือมีประโยชน์จริง" ในบริบทของการอภิปรายการตั้งชื่อ แน่นอนมันเป็นข้อมูลที่มีประโยชน์ แต่ไม่ใช่สิ่งแรกที่คุณต้องรู้เกี่ยวกับเซิร์ฟเวอร์ไม่ให้อ่านชื่อ นอกจากนี้ P2V หรือ V2P อาจแบ่งชุดรูปแบบของคุณหรือต้องการเปลี่ยนชื่อเซิร์ฟเวอร์ซึ่งอาจทำให้เกิดสิ่งอื่น ๆ

— mfinni

1

จากประสบการณ์ของฉัน P2V หรือ V2P แบ่งสิ่งต่าง ๆ มากมายและควรหลีกเลี่ยงถ้าเป็นไปได้ - เราทำดังนั้นจึงไม่มีปัญหากับแบบแผนการตั้งชื่อของเรา แบบแผนการตั้งชื่อจะต้องตอบสนองความต้องการของใครก็ตามที่ออกแบบมัน - ในองค์กรที่ฉันทำงานอยู่นั้นได้รับการออกแบบโดยทีมงานที่จัดการเซิร์ฟเวอร์และอุปกรณ์เครือข่ายทั้งหมดและพวกเขาต้องการที่จะบอกสิ่งต่าง ๆ ข้างต้น อาจไม่เหมาะสำหรับคุณ แต่ทุกอย่างก็เปิดให้มีการอภิปราย ข้อกำหนดทางเทคนิคเพียงอย่างเดียวคือความเป็นเอกลักษณ์

— dunxd