Anlamlı ve anlamsız hostname arasında seçim yapma [kapalı] | m24sniperweaponsystem.com
Farklı sunucular, çeşitli donanım, yazılım, işletim sistemleri, sanal / özel vb. Kukla yönetimli bir kümeyle ortam yaratın.
Anlamlı hostnameleri seçer misiniz (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup, vb.) Veya bir kitap veya filmdeki karakterler gibi anlamsız hostnameleri tercih eder misiniz?
Anlamlı sunucu isimleriyle gördüğüm problem, isimlerin genellikle tek bir hizmeti temsil ettikleri ve bir sunucunun birden fazla amaca sahip olması durumunda gerçekten dağınık olduğu (özellikle sunucu rollerinin sık sık değiştiği durumlarda).
Bir hizmet adını bir IP adresine eşleme ve bu DNS'nin yapması gereken eşleştirmeyi sürdürmüyor mu?
Her iki yaklaşımın avantajları ve dezavantajları nelerdir ve seçtiğiniz yaklaşımla ne gibi sorunlarla başa çıkmak zorunda kaldınız?
DNS'yi kontrol ederseniz, her ikisini de yapabilirsiniz. - jscott
Onu burada bırakacağım: RFC 1178 - gelraen
Her ne kadar yüzeysel olarak bir kanaat temelli soru olsa da, asıl cevaplar ampirik sorgulama ve insan bilişsel işlevine dayanan (insan beyninin şeyleri nasıl hatırladığı) gerçeğe dayalıdır. Bence bu soru yeniden açılmalıdır. - dotancohen
Bir zamanlar bir adlandırma şemasına karar verme fırsatım oldu. Bu yüzden turlara devam ettim ve geliştiricilerime sordum ki, her şeyden önce bu isimlerle günlük olarak çalışmak zorunda olan insanlar, ister tercih ettiler fonksiyonel adları (yani, kodlanmış bir biçimde, makinenin amacını temsil eden adlar) veya hafıza isimleri (yani, makinenin amacı hakkında herhangi bir dolaylı içerik içermeyen önceden varolan insan isimlendirme şemasından alınan isimler).
38 geliştiriciden 37'si tercih edilen mnemonik isim; sadece bir tane tercih edilen fonksiyonel isim. Bu yüzden hepsini nehirlerden sonra isimlendirdim (çok büyük isimlerden oluşan bir havuz var, birçoğu kısa, hatırlaması kolay ve yazması hızlı).
İnsan beyni, isimlere anlam vermek için oldukça iyi tasarlanmış. Unutulmaz isimler sunuyorsanız, insanlar bu isimlerin ne için kullanıldığını oldukça çabuk hatırlayacak ve bunları kullanacaktır. Bazı ortak geçmişlerden (örneğin, nehirler, elementler, yıldızlar, ilçeler, içecekler, fikirleri alırsanız) isimleri kullanırsanız, insanların bir şirketin ana bilgisayar adını anında tanımaları için yardımcı olur; aksi halde "e-postaların tümü" betelgeuse"biraz kafa karıştırıcı olabilir".
Tersine, geliştiricilerim, önceki işlerde sahip olduklarının tam olarak ne olduğunu hatırlamakta gerçekten zorlandıklarını hissetti. pr1ms001 oldu.
Ancak, iç DNS'de CNAME'leri mnemonik ad eşlemesine işlevsel bir ad sağlamak için kullandığımızı eklemeliyiz. Bu nedenle, PR sitesindeki ilk kümedeki ana posta sunucusunun gerçekten olduğunu hatırlamanız daha kolay olduysa pr1ms001sonra DNS, bunun şu anda olduğunu bilmenizi isterdi orwell. Ayrıca, bu makine başına çok sayıda işlevsel isme sahip olalım, bu yüzden üzerinde çalıştığınız işlevin işlevsel adını her zaman kullandığınız sürece, emin olabilirsiniz. pr1imap001 Bu işlevi taşıyalım bile, IMAP sunucusuna her zaman işaret eder orwell için rhine. Ve ne zaman hudson öldü, operasyonel fonksiyonları etkilemeden değiştirmenin ismini değiştirebilirdik, böylece "hiç demek istemedin" hudsonveya yaşlı hudson"karışıklık.
Bunu düşünebilirsiniz, ancak geliştiricilerim, mnemonik şemanın, başka bir şey iletilip iletilmediğinin daha iyi olduğunu söyledi, çünkü bunların hepsi, nerede olduğuyla ilgili kendi iç durum tablolarını oluşturdular ve bu tür bellekler, İnsan beyni hatırlamayı sever. - MadHatter
İzlanda'daki volkanlardan sonra onları adlandırmış olmalısın. - Chloe
"Nehir havuzu" için +1;) - Konerak
Bu harika bir fikir ve ben de çalıyorum. - SpacemanSpiff
Sunucuları bu şekilde isimlendirmenin bir autobuild sistemi ile daha fazla çalıştığına katılıyorum, ama onları inşa etmenin diğer insanların onları kullanması gerektiğine inanıyorum - ve yukarıdaki veriler kullanım onlar. İstedikleri şey değişmiş olabilir, ama bence sunucu yöneticileri hakkındaki kararlarımız, işimizi kolaylaştıran şeylerden daha fazlasına dayanmalıdır. - MadHatter
Bu büyük ölçüde sunucularınızın olup olmadığıdır. pets veya livestock.
Evcil hayvanlar bireysel isimler alır. Birbirlerinden ayrılar ve bu farklılıkları önemsiyoruz. Birisi hastalandığında, genellikle onu tekrar sağlığa kavuşturmaya çalışırız. Geleneksel olarak, sunucular evcil hayvanlardı.
Hayvancılık sayıları alır. Çoğunlukla özdeşler, ve hangi farklılıklar var, umurumda değil ve genellikle en aza indirmeye çalışıyoruz. Biri hastalandığında, onu yere koyar ve bir tane daha alırız. Tamamen sanallaştırılmış sunucular, özellikle AWS gibi IaaS sunucuları çiftlik hayvanlarıdır.
Çoğu karmaşık ortamlarda, bir karışımınız var. Örneğinizin arka kısımları, neredeyse kesinlikle hayvancılıktır. Daha fazlasına ihtiyacınız varsa, standart yapılandırma ile birkaç tane daha döndürün; Eğer çok fazla ihtiyacın yoksa bazılarını kapatırsın. Bazı sunucularda veritabanı sunucularınız evcil hayvanlardır. Her birinde çok sayıda özel kurulum olabilir; hatta sanallaştırma yerine onları çıplak metal üzerinde çalıştırıyor olabilirsiniz.
Tabii ki, her iki ortamda, HİZMETLERİ isimlendirebilir ve bunları doğrudan ele alabilirsiniz. Bu her durumda en iyi uygulamadır; geliştiricilerin bir hizmetin gerçek ana bilgisayar adının ne olduğunu bilmesi veya önemsemesi gerekmemelidir. Ana bilgisayar adı sadece operasyonel bir detay olmalıdır. Öyleyse, o zaman, sunucu adlarında host personeliniz için yararlı olan kodlama bilgisini düşünün - örneğin, bir sunucunun hangi veri merkezini içerdiğini belirtmek genellikle yararlıdır.
Evcil hayvan veya hayvancılık - bunu koymak için iyi bir yol. - Michael Hampton♦
Son zamanlarda bu konsepti ilk gördüğüm makaleyi yeniden buldum: gregarnette.com/blog/2012/05/cloud-servers-are-not-our-pets - Ian
Teşekkürler @Ian bu yazı için geçen gün avlandım, SEO başarısız heh - Rudolf Olah
Bu daha önce burada ele alındı ​​...
Benim önerim, işlevsel isimler ve anımsatıcı isimlerin birleşimidir ...
Bir uygulama yazıyorsanız ve adresi gerekiyorsa ccts-logserver1, bu adı kullanın, ancak bir CNAME veya bir takma ad verin. Gerçek ana bilgisayar adı istediğiniz her şey olabilir: Bir meyve ya da sebze, Yunan mitolojisi ya da Seinfeld karakteri ... ama gerçek işlevsel isimleri ilişkilendirmeniz gerektiğinde size biraz esneklik sağlar, ancak insanların hatırlayabileceği bir şeyi saklayın.
Örneğini düşün mango, DB sunucusu başarısız ... ama başka bir şeyle değiştirildi, söyle peach. Belki mevcut süreçler ve uygulamalar görmek gerekir cmt-prod-db1. Sistemleri takas edebilir, çakışmalara isim vermeden bunları inşa edebilir ve uygulamaları (ve geliştiricileri) mutlu tutabilirsiniz.
Çalıştığım yerde birden çok şehirde birden çok şirketi, birden çok şirketi yönetiyoruz. Bizim için anımsatıcı isimler çalışamaz. Bunun yerine, sunucularımızı tanımlayan kısa bir form kullanıyoruz. Bu durum, farklı alanlarda birden fazla ofise sahip (veya birden fazla alandaki tek bir ofise veya aynı alanda birden fazla ofise veya yukarıdakilerin tümüne sahip olan) bazı müşterilerimiz olduğu için bizim durumumuzda iyi sonuç verir.
Bizim için bilgi Şirket / Domain, şehir, fonksiyon, sayı içerir. Şirket için bir etki alanı denetleyicisi için, Şikago'daki Cypress şöyle olurdu:
CYPRCHDOM001 (Bunu konuşmamızda Cypress ana DOM olarak ifade ederiz)
CYPRCHSQL001 onun SQL sunucusu olurdu, CYPRCHMGM001 onun yönetimi (yani, anti-virüs, yedekler, vb) olurdu ve CYPRCHAPP001 bir karma uygulamalar sunucusu olurdu. Hatırlanması kolay, sıralaması kolay, öğretmesi kolay.
Peki, CYPRCHAPP003'ün CYPRCHAPP001'in aksine hangi uygulamaların çalıştığını nasıl hatırlıyorsunuz? Bunun mnenomic isimleriyle ilgili bir problem olduğunu itiraf edeceğim, fakat bir tür işlevsel isimle ilgileniyorsanız, spesifik de olabilir. - α CVn
@ MichaelKjörling Bir sunucuda neyin ince taneli özellikleri bir ada ait değil, bir tür belgelere aittir. Birisinin CYPRCHAPP001'de neyin çalıştığını bilmesi gerekiyorsa, belgeleri okuyorlar. Uygulamaların taşınmasının yanı sıra, CYPRCHAPP001_PointofSale_Payroll_HRSoftware-etc, şirket bordro yazılımını barındırılan bir çözüme taşıdığında bir yanlış isim olacaktır. - Wulfhart
@Wulfhart Sizinle aynı fikirdeyim, fakat CNAME'lerin sahip olmasının nesi yanlış? pointofsale, payroll, vb.? Böylelikle, sysadmins dışındaki hiç kimsenin bordro yazılımının tam olarak nerede çalıştığıyla ilgilenmesi gerekmez; herkes için, sadece çalışır. Başka bir veri merkezine taşınmak mı istiyorsunuz? Hiç sorun değil. Satış sistemi veritabanının noktasını kendi özel sunucusuna taşımak ister misiniz? Sadece güncellemek pointofsale-database CNAME yeni yere işaret edecek. Ve bunun gibi. - α CVn
Bir makineyi değiştirmeniz gerektiğini varsayalım: CYPRCHSQL002'yi kurduktan ve test ettikten sonra, sadece CYPRCHSQL001 adını (hiç değiştirilmemeli) mi yoksa eski 001'i kaldırdıktan sonra 002 - 001 olarak yeniden adlandırıyor musunuz? Başka? - nickgrim
@ MichaelKjörling Bu benim için harika bir fikir gibi görünüyor. "Belirtiler bir isme ait değil" ifadesiyle, makinenin ana makine adında değil. - Wulfhart
Tek gereklilik ana bilgisayar adları için ağda benzersiz olmaları gerektiğidir.
Anlam sadece sunucular işleviyle ilgili olmak zorunda değildir. Fiziksel cihazlarla uğraşmanız gerekiyorsa, konum çok kullanışlı olabilir. Bir cihazın sanal veya fiziksel olup olmadığını bilmek de yararlı olabilir. Bir ağ aygıtı, bir linux sunucusu veya bir windows kutusu arasındaki farkı anlayabilmek, hangi aracın oturum açmak için kullanıldığını bulmak için çok kullanışlı olabilir.
İşleyiş şeklimiz bu bilgiyi aşağıdaki gibi cihaz adına koymak ve denemek:
L veya T - Canlı veya Test P veya V - Fiziksel veya Sanal S veya N - Sunucu veya Ağ (herhangi bir Linux sunucumuz yok) benzersizliği sağlamak için bir sıra numarası bir ISO 3166-1 üç harfli ülke kodu Cihazın bulunduğu yeri gösterir.
Daha sonra DNS'de CNAMES'i kullanarak, çeşitli servis isimlerini hostname ile eşleştiriyoruz.
Bunun hakkında karışık duygular var. Belirli bir cihazın nerede bulunduğuna bakmak için zaman ayırır. Öte yandan, verilmiş bir sunucunun ana makine adı ile sunulduğunda, değerli taşların kullanıldığı önceki sistemimize kıyasla ne olduğunu hatırlamak çok daha zordur. Değerli taşlar hiçbir anlam ifade etmiyordu, ama hatırlamak kolaydı çünkü her kişi kendi bağlantılarını yaratabilirdi.
Tek bir sistemden diğerine geçiş yaptığımızda en büyük karışıklığın ortaya çıkmasıyla tek tavsiyenin tek bir şemaya yerleşmesi olacağını düşünüyorum.
Buna katılmıyorum: "Bir aygıtın sanal veya fiziksel olup olmadığını bilmek de yararlı olabilir." adlandırma tartışma. Tabii ki bu yararlı bir bilgidir, ancak bir sunucu hakkında adını bilmeniz gereken ilk şey bu değildir. Ayrıca, P2V veya V2P ya planınızı bozar ya da sunucunun yeniden adlandırılmasını gerektirir, bu da başka şeylere zarar verebilir. - mfinni
Tecrübemde P2V veya V2P bir çok şeyi kırıyor ve mümkün olduğunda önlenmeli - bu yüzden isimlendirme sözleşmemizle ilgili bir sorun değil. Adlandırma kuralı, onu tasarlayanların gereksinimlerini karşılamalıdır - çalışmakta olduğum kuruluşta, tüm sunucuları ve ağ ekipmanlarını yöneten ekip tarafından tasarlandı ve yukarıdaki şeyleri anlatmak istiyorlar. Sizin için doğru olmayabilir, ama sonra tartışmalara açıktır. Tek teknik gereksinim, tekliktir. - dunxd
Bir Linux kullanıcısının ev dizinini bir varsayılana kadar nasıl temizleyebilir ve sıfırlayabilirim? 'pip install carbon' işe yarıyor gibi görünüyor, ancak pip daha sonra aynı fikirde değil mod_wsgi AWS Elastic Beanstalk Python 3.6 platformunda “Call to 'site.addsitedir ()' başarısız” Apache 2.4 ile RFC 2616 OpenLDAP Ters Grup Üyelik Bakımı kaplamasını ekledikten sonra varolan nesnelerin memberOf niteliklerini nasıl güncellerim? IP adresinizi nasıl seçersiniz? Bir sunucu odası için en iyi yangın söndürme nedir? [kapalı]