Memilih antara nama host yang berarti dan tidak berarti [ditutup]


79

Asumsikan sebuah lingkungan dengan klaster yang dikelola oleh boneka dari berbagai server - berbagai perangkat keras, perangkat lunak, sistem operasi, virtual / khusus, dll.

Apakah Anda memilih nama host yang bermakna (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup, dll.) Atau Anda lebih suka nama host yang tidak berarti seperti karakter dari buku atau film?

Masalah yang saya lihat dengan nama-nama host yang bermakna adalah bahwa nama-nama biasanya mewakili layanan tunggal dan jika server memiliki lebih dari satu tujuan itu menjadi sangat berantakan (terutama jika peran server sering berubah).

Bukankah memetakan nama layanan ke alamat IP dan mempertahankan pemetaan itu apa yang seharusnya dilakukan DNS?

Apa kelebihan dan kekurangan dari kedua pendekatan tersebut dan masalah apa yang Anda miliki untuk mengatasinya dengan pendekatan yang Anda pilih?


10
Jika Anda mengontrol DNS, Anda selalu dapat melakukan keduanya.
jscott

16
Saya akan meninggalkannya di sini: RFC 1178
gelraen

Meskipun secara dangkal merupakan pertanyaan berbasis opini, jawaban aktualnya berdasarkan fakta dengan polling empiris dan berdasarkan pada fungsi kognitif manusia (bagaimana otak manusia mengingat sesuatu). Menurut pendapat saya, pertanyaan ini harus dibuka kembali.
dotancohen

Jawaban:


98

Sekali waktu saya memiliki kesempatan untuk memutuskan skema penamaan. Jadi saya berputar dan bertanya kepada pengembang saya, yang bagaimanapun adalah orang-orang yang harus bekerja dengan nama-nama ini setiap hari, apakah mereka lebih suka nama fungsional (yaitu, nama yang mewakili, dalam beberapa bentuk yang disandikan, tujuan mesin) atau nama mnemonik (yaitu, nama yang diambil dari beberapa skema penamaan manusia yang sudah ada sebelumnya, yang tidak mengandung konten tersirat tentang tujuan mesin).

Dari 38 pengembang, 37 nama mnemonik pilihan; hanya satu nama fungsional yang disukai. Jadi saya menamai mereka semua setelah sungai (ada kumpulan nama yang sangat besar, dan banyak dari mereka pendek, mudah diingat, dan cepat untuk mengetik).

Otak manusia dirancang cukup baik untuk melekatkan makna pada nama. Jika Anda memberikan nama yang mudah diingat, orang akan dengan cepat mengingat untuk apa nama itu digunakan, dan menggunakannya. Jika Anda menggunakan nama yang diambil dari latar belakang yang sama (misalnya sungai, elemen, bintang, kabupaten, minuman, Anda mendapatkan ide) itu membantu orang untuk segera mengenali nama host perusahaan ketika mereka menemukannya; jika tidak, pernyataan seperti "semua email berakhir betelgeuse" bisa sedikit membingungkan).

Sebaliknya, pengembang saya merasa bahwa mereka memiliki pekerjaan sebelumnya yang sangat sulit mengingat apa pr1ms001sebenarnya.

Tetapi saya harus menambahkan bahwa kami menggunakan CNAME dalam DNS internal untuk memberikan nama fungsional ke pemetaan nama mnemonik, jadi jika Anda benar-benar merasa lebih mudah untuk mengingat bahwa server email utama pada kluster pertama di situs PR adalah pr1ms001, maka DNS akan beri tahu Anda bahwa itu saat ini orwell. Selain itu, kami memiliki banyak nama fungsional per mesin, jadi selama Anda selalu menggunakan nama fungsional yang relevan dengan fungsi yang sedang Anda kerjakan, Anda dapat yakin bahwa itu pr1imap001akan selalu mengarah ke server IMAP, bahkan jika kami memindahkan fungsionalitas itu. dari orwellke rhine. Dan ketika hudsonmati, kita bisa mengganti nama penggantian tanpa mempengaruhi fungsi operasional, sehingga kita tidak pernah memiliki "maksud Anda yang baru hudsonatau yang lama hudson?" kebingungan.


7
Anda mungkin berpikir begitu, tetapi pengembang saya mengatakan bahwa skema mnemonik lebih baik apakah hal lain dikomunikasikan, atau tidak, karena mereka semua membangun tabel keadaan internal mereka sendiri di mana, dan memori semacam itu lebih mudah dibangun berdasarkan nama yang otak manusia suka mengingat.
MadHatter

11
Anda seharusnya menamainya setelah gunung berapi di Islandia.
Chloe

1
+1 untuk "genangan sungai";)
Konerak

2
Ini adalah ide yang luar biasa, dan saya mencurinya.
SpacemanSpiff

1
Saya setuju bahwa penamaan server dengan cara ini lebih berfungsi dengan sistem autobuild, tetapi saya perhatikan bahwa titik pembuatannya adalah agar orang lain dapat menggunakannya - dan data di atas berasal dari orang-orang yang harus menggunakannya . Mungkin apa yang mereka inginkan telah berubah, tetapi saya pikir keputusan kami pada server admin harus didasarkan pada lebih dari apa yang membuat pekerjaan kami mudah.
MadHatter

93

Ini sebagian besar turun ke apakah server Anda petsatau livestock.

Hewan peliharaan mendapatkan nama masing-masing. Mereka berbeda satu sama lain, dan kami peduli dengan perbedaan itu. Ketika seseorang sakit, kami biasanya mencoba merawatnya kembali agar tetap sehat. Secara tradisional, server adalah hewan peliharaan.

Ternak mendapatkan angka. Mereka sebagian besar identik, dan perbedaan apa yang ada, kami tidak pedulikan dan biasanya berusaha untuk meminimalkan. Ketika seseorang sakit, kami taruh dan dapatkan yang lain. Server yang sepenuhnya tervirtualisasi, terutama server IaaS seperti AWS, adalah ternak.

Di sebagian besar lingkungan yang kompleks, Anda memiliki campuran. Backend web Anda, misalnya, hampir pasti ternak. Jika Anda membutuhkan lebih banyak, Anda berputar lagi dengan konfigurasi standar; jika Anda tidak membutuhkan banyak, Anda mematikannya. Server database Anda, dalam beberapa konfigurasi, adalah peliharaan. Mungkin ada banyak pengaturan khusus pada masing-masing; Anda bahkan dapat menjalankannya di bare metal alih-alih virtualisasi.

Tentu saja, di lingkungan mana pun, Anda dapat memberi nama LAYANAN dan mengatasinya secara langsung. Bagaimanapun, ini adalah praktik terbaik; pengembang Anda tidak perlu tahu atau peduli apa nama host sebenarnya dari suatu layanan. Nama host harus murni detail operasional. Maka, pikirkan pengkodean informasi yang berguna bagi staf ops Anda di hostname - misalnya, sering kali membantu menunjukkan pusat data server mana yang ada.


22
Hewan peliharaan atau ternak - itu cara yang bagus untuk menggambarkannya.
Michael Hampton

5
Saya baru-baru ini menemukan kembali artikel yang pertama kali saya lihat konsep ini di: gregarnette.com/blog/2012/05/cloud-servers-are-not-our-pets
Thaeli

Terima kasih @Ian saya telah berburu untuk hari terakhir untuk artikel itu, SEO gagal heh
Rudolf Olah

18

Ini telah dibahas di sini sebelum ...

Rekomendasi saya adalah kombinasi nama fungsional dan nama mnemonik ...

Jika Anda sedang menulis aplikasi dan perlu alamat ccts-logserver1, gunakan nama itu di seluruh, tetapi buatlah itu menjadi CNAME atau alias. Nama inang sebenarnya bisa berupa apa pun yang Anda inginkan: buah atau sayuran, mitologi Yunani atau karakter Seinfeld ... tetapi memberi Anda beberapa fleksibilitas ketika Anda perlu mengaitkan nama fungsional nyata, tetapi menyimpan sesuatu yang dapat diingat orang.

Pikirkan contoh di mana mango, server DB gagal ... tetapi diganti dengan yang lain, katakanlah peach. Mungkin proses dan aplikasi yang ada perlu dilihat cmt-prod-db1. Anda dapat menukar sistem, membangunnya tanpa menyebutkan konflik, dan membuat aplikasi (dan pengembang) senang.


4

Di mana saya bekerja, kami mengelola banyak situs, beberapa perusahaan, di beberapa kota. Bagi kami nama mnemonik tidak dapat berfungsi. Alih-alih, kami menggunakan formulir singkat yang menggambarkan server kami. Ini berfungsi baik dalam kasus kami karena kami memiliki beberapa klien yang mungkin memiliki beberapa kantor di domain yang berbeda (atau satu kantor di beberapa domain, atau beberapa kantor di domain yang sama, atau semua hal di atas!)

Bagi kami, informasi tersebut mengandung Perusahaan / Domain, kota, fungsi, nomor. Jadi untuk pengontrol domain untuk perusahaan, katakanlah Cypress di Chicago:

CYPRCHDOM001 (Kami akan menyebutnya sebagai DOM utama Cypress dalam percakapan)

CYPRCHSQL001 akan menjadi server SQL, CYPRCHMGM001 akan menjadi manajemennya (yaitu, anti-virus, cadangan, dll), dan CYPRCHAPP001 akan menjadi server aplikasi campuran. Mudah diingat, mudah disortir, mudah diajar.


1
Jadi bagaimana Anda ingat aplikasi apa yang berjalan pada CYPRCHAPP001 dibandingkan dengan CYPRCHAPP003? Saya akui ini adalah masalah dengan nama-nama mnenomic juga, tetapi jika Anda mencari beberapa nama fungsional, mungkin lebih spesifik.
CVn

2
@ MichaelKjörling Butir halus spesifik tentang apa yang ada di server tidak termasuk dalam nama, mereka termasuk dalam semacam dokumentasi. Jika seseorang perlu tahu apa yang berjalan di CYPRCHAPP001, mereka membaca dokumentasinya. Selain memindahkan aplikasi, CYPRCHAPP001_PointofSale_Payroll_HRSoftware-etc akan menjadi kesalahan ketika perusahaan memindahkan perangkat lunak penggajian mereka ke solusi yang di-host.
Wulfhart

2
@Wulfhart Saya setuju dengan maksud Anda, tapi apa yang salah dengan memiliki CNAME untuk pointofsale, payroll, dll? Dengan begitu, tidak ada seorang pun selain sysadmin yang perlu memperhatikan sendiri di mana perangkat lunak penggajian berjalan; untuk semua orang, itu hanya berfungsi. Ingin memindahkan sesuatu ke pusat data lain? Tidak masalah sama sekali. Ingin memindahkan basis data sistem penjualan ke server khusus? Cukup perbarui pointofsale-databaseCNAME untuk menunjuk ke lokasi baru. Dan seterusnya.
CVn

1
Misalkan Anda perlu mengganti mesin: setelah Anda membangun CYPRCHSQL002 dan mengujinya, apakah Anda baru saja pensiun nama CYPRCHSQL001 (tidak pernah diganti), atau apakah Anda mengganti nama 002 hingga 001 setelah Anda menghapus 001 yang lama, atau sesuatu lain?
jamaah

@ MichaelKjörling Itu sepertinya ide bagus bagi saya. Dengan "spesifik tidak termasuk dalam nama" Maksud saya tidak dalam nama host mesin.
Wulfhart

2

Satu-satunya persyaratan untuk nama host adalah mereka harus unik di jaringan.

Makna tidak harus hanya dengan fungsi server. Lokasi bisa sangat berguna jika Anda harus berurusan dengan perangkat fisik. Mengetahui apakah perangkat itu virtual atau fisik juga bisa bermanfaat. Mampu mengetahui perbedaan antara perangkat jaringan, server linux atau kotak windows bisa sangat berguna ketika datang untuk mencari tahu alat apa yang digunakan untuk login.

Cara kami mengatasinya adalah dengan mencoba dan memasukkan informasi ini ke nama perangkat sebagai berikut:

L atau T - Langsung atau Uji P atau V - Fisik atau Virtual S atau N - Server atau Jaringan (kami tidak memiliki server Linux) nomor urut untuk memastikan keunikan. ISO 3166-1 Tiga huruf kode negara yang menunjukkan di mana perangkat terletak.

Kami kemudian menggunakan CNAMES dalam DNS untuk memetakan berbagai nama layanan hingga nama host.

Saya memiliki perasaan campur aduk tentang ini. Ini tentu menghemat waktu karena harus mencari di mana perangkat tertentu berada. Di sisi lain, akan jauh lebih sulit untuk mengingat apa yang dilakukan server ketika disajikan dengan nama hostnya, jika dibandingkan dengan sistem kami sebelumnya yang menggunakan batu permata. Batu permata tidak menyiratkan makna sama sekali, tetapi mereka mudah diingat karena setiap orang dapat membuat koneksi mereka sendiri.

Saya kira satu-satunya saran adalah menyelesaikan satu skema ketika kebingungan terbesar muncul ketika kita beralih dari satu sistem ke yang lain.


Saya tidak setuju dengan ini: "Mengetahui apakah perangkat itu virtual atau fisik juga bisa berguna" dalam konteks diskusi penamaan . Tentu saja itu informasi yang berguna, tetapi itu bukan hal pertama yang perlu Anda ketahui tentang server dari membaca namanya. Lebih lanjut, P2V atau V2P dapat merusak skema Anda, atau mengharuskan penggantian nama server, yang dapat merusak hal-hal lain.
mfinni

1
Dalam pengalaman saya, P2V atau V2P merusak banyak hal dan harus dihindari jika memungkinkan - ya, karena itu bukan masalah dengan konvensi penamaan kami. Konvensi penamaan perlu memenuhi persyaratan siapa pun yang mendesainnya - dalam org saya bekerja di dalamnya dirancang oleh tim yang mengelola semua server dan peralatan jaringan, dan mereka ingin dapat menceritakan hal-hal di atas. Ini mungkin tidak tepat untuk Anda, tetapi kemudian terbuka untuk diperdebatkan. Satu-satunya persyaratan teknis adalah keunikan.
dunxd
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.