Wybieranie między sensownymi a bezsensownymi nazwami hostów [zamknięte]

79

Załóż środowisko z zarządzanym marionetkowo klastrem różnych serwerów - różnego sprzętu, oprogramowania, systemów operacyjnych, wirtualnych / dedykowanych itp.

Czy wybrałbyś sensowne nazwy hostów (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup itp.) Czy wolałbyś pozbawione znaczenia nazwy hostów, takie jak postacie z książki lub filmu?

Problem, który widzę w znaczących nazwach hostów, polega na tym, że nazwy zwykle reprezentują pojedynczą usługę, a jeśli serwer ma więcej niż jeden cel, robi się naprawdę bałagan (szczególnie, jeśli role serwera często się zmieniają).

Czy mapowanie nazwy usługi na adres IP i utrzymywanie tego mapowania nie powinno być wykonywane przez DNS?

Jakie są zalety i wady obu podejść i jakie rzeczywiste problemy musiałaś rozwiązać przy wybranym podejściu?

keymone
źródło
10
Jeśli kontrolujesz DNS, zawsze możesz zrobić jedno i drugie.
jscott
16
Zostawię to tutaj: RFC 1178
gelraen
Choć pozornie pytanie oparte na opiniach, rzeczywiste odpowiedzi są oparte na badaniu empirycznym i oparte na ludzkich funkcjach poznawczych (jak ludzki mózg pamięta rzeczy). Moim zdaniem pytanie to należy ponownie otworzyć.
dotancohen

Odpowiedzi:

98

Pewnego razu miałem okazję zdecydować o schemacie nazewnictwa. Poszedłem więc i zapytałem moich programistów, którzy przecież byli ludźmi, którzy musieli pracować z tymi nazwami na co dzień, czy wolą nazwy funkcjonalne (to znaczy nazwy, które reprezentują, w jakiejś zakodowanej formie, nazwę celu maszyny) lub nazwach mnemonicznych (tj. nazwach zaczerpniętych z wcześniej istniejącego schematu nazewnictwa ludzi, który nie zawierał niejawnej treści o celu maszyny).

Spośród 38 programistów 37 preferowało nazwy mnemoniczne; tylko jedna preferowana nazwa funkcjonalna. Nazwałam je więc wszystkie po rzekach (istnieje bardzo duża pula możliwych nazw, a wiele z nich jest krótkich, łatwych do zapamiętania i szybkiego pisania).

Ludzki mózg jest dość dobrze zaprojektowany do nadawania znaczenia imionom. Jeśli podasz imiona, które są niezapomniane, ludzie dość szybko zapamiętają, do czego są one używane, i użyją ich. Jeśli używasz nazw zaczerpniętych z jakiegoś wspólnego tła (np. Rzeki, żywioły, gwiazdy, powiaty, napoje, masz pomysł), pomaga to ludziom natychmiast rozpoznać nazwę hosta firmy, gdy ją napotkają; w przeciwnym razie stwierdzenia takie jak „wszystkie wiadomości e-mail się skończyły betelgeuse” mogą być nieco mylące).

I odwrotnie, moi programiści czuli, że w poprzednich pracach mieli naprawdę ciężki problem z zapamiętaniem dokładnie tego, co pr1ms001było.

Ale powinienem dodać, że użyliśmy CNAME w wewnętrznym DNS, aby zapewnić funkcjonalną nazwę do mnemonicznego mapowania nazw, więc jeśli naprawdę łatwiej ci było zapamiętać, że głównym serwerem poczty w pierwszym klastrze w witrynie PR był pr1ms001DNS, to DNS daję znać, że to było obecnie orwell. Dzięki temu mamy wiele nazw funkcjonalnych na maszynę, więc tak długo, jak zawsze używałeś nazwy funkcjonalnej odpowiedniej dla funkcji, nad którą pracujesz, możesz być pewien, pr1imap001że zawsze wskaże serwer IMAP, nawet jeśli przenieśliśmy tę funkcjonalność od orwelldo rhine. A kiedy hudsonumarł, moglibyśmy zmienić nazwę zamiennika bez wpływu na funkcje operacyjne, abyśmy nigdy nie mieli „czy masz na myśli nowy hudsonczy stary hudson?”. zamieszanie.

Szalony Kapelusznik
źródło
7
Możesz tak myśleć, ale moi programiści stwierdzili, że schemat mnemoniczny był lepszy niezależnie od tego, czy przekazano coś jeszcze, ponieważ wszyscy zbudowali własne tabele stanów wewnętrznych tego, co było gdzie, a tego rodzaju pamięć łatwiej zbudować na nazwach, które ludzki mózg lubi pamiętać.
MadHatter
11
Powinieneś nazwać je imionami wulkanów na Islandii.
Chloe,
1
+1 za „kałużę rzek”;)
Konerak
2
To niesamowity pomysł i go kradnę.
SpacemanSpiff
1
Zgadzam się, że nazywanie serwerów w ten sposób wymaga więcej pracy z systemem autobuild, ale zauważam, że celem ich zbudowania jest to, aby inni mogli z nich korzystać - a powyższe dane pochodzą od osób, które musiały z nich korzystać . Być może zmieniło się to, czego chcą, ale myślę, że nasze decyzje dotyczące administratora serwera powinny opierać się bardziej niż na tym, co ułatwia nam pracę.
MadHatter
93

To w dużej mierze sprowadza się do tego, czy twoje serwery są petsczy livestock.

Zwierzęta otrzymują indywidualne imiona. Różnią się od siebie i dbamy o te różnice. Kiedy ktoś zachoruje, zwykle staramy się przywrócić go do zdrowia. Tradycyjnie serwery to zwierzęta domowe.

Zwierzęta hodowlane otrzymują numery. Są w większości identyczne, a jakie są różnice, nie dbamy o to i zwykle staramy się je minimalizować. Kiedy ktoś zachoruje, odkładamy go i dostajemy kolejnego. W pełni zwirtualizowane serwery, zwłaszcza serwery IaaS, takie jak AWS, są żywymi zwierzętami.

W najbardziej złożonych środowiskach masz mieszankę. Na przykład twoje zaplecze sieciowe prawie na pewno są inwentarzem żywym. Jeśli potrzebujesz więcej, rozkręcasz jeszcze kilka przy standardowej konfiguracji; jeśli nie potrzebujesz ich tak wielu, wyłącz niektóre. Twoje serwery baz danych, w niektórych konfiguracjach, są zwierzętami domowymi. Każda z nich może zawierać wiele specjalnych ustawień; możesz nawet uruchamiać je na czystym metalu zamiast wirtualizacji.

Oczywiście w każdym środowisku możesz nazwać USŁUGI i adresować je bezpośrednio. W każdym razie jest to najlepsza praktyka; Twoi programiści nie powinni wiedzieć ani przejmować się faktyczną nazwą hosta usługi. Nazwa hosta powinna być szczegółem czysto operacyjnym. Pomyśl więc o kodowaniu informacji, które są przydatne dla twojego personelu operacyjnego w nazwach hostów - na przykład często pomocne jest wskazanie, w którym centrum danych znajduje się serwer.

Thaeli
źródło
22
Zwierzęta domowe lub zwierzęta gospodarskie - to dobry sposób na wyrażenie tego.
Michael Hampton
5
Niedawno ponownie znalazłem artykuł, w którym po raz pierwszy zobaczyłem tę koncepcję: gregarnette.com/blog/2012/05/cloud-servers-are-not-our-pets
Thaeli
Dzięki @Ian Poluję na ostatni dzień dla tego artykułu, SEO zawiodę heh
Rudolf Olah
18

Zostało to tutaj omówione wcześniej ...

Moja rekomendacja to połączenie nazw funkcjonalnych i nazw mnemonicznych ...

Jeśli piszesz aplikację, która wymaga adresu ccts-logserver1, użyj tej nazwy przez cały czas, ale nadaj jej nazwę CNAME lub alias. Prawdziwa nazwa hosta może być dowolna: owocem lub warzywem, mitologią grecką lub postacią Seinfelda ... ale daje ci pewną elastyczność, gdy potrzebujesz skojarzyć prawdziwe funkcjonalne nazwy, ale zachować coś, co ludzie mogą zapamiętać.

Pomyśl o przykładzie, w którym mangoserwer DB nie działa ... ale jest zastąpiony przez coś innego, powiedzmy peach. Być może trzeba zobaczyć istniejące procesy i aplikacje cmt-prod-db1. Możesz wymieniać systemy, budować je bez konfliktów nazw i dbać o zadowolenie aplikacji (i programistów).

ewwhite
źródło
4

Tam, gdzie pracuję, zarządzamy wieloma witrynami, wieloma firmami, w wielu miastach. Dla nas nazwy mnemoniczne nie mogą działać. Zamiast tego używamy skróconego formularza opisującego nasze serwery. Działa to dobrze w naszym przypadku, ponieważ mamy niektórych klientów, którzy mogą mieć wiele biur w różnych domenach (lub jedno biuro w wielu domenach lub wiele biur w tej samej domenie lub wszystkie powyższe!)

Dla nas informacje zawierają firmę / domenę, miasto, funkcję, numer. Więc dla kontrolera domeny dla firmy, powiedzmy Cypress w Chicago, byłoby to:

CYPRCHDOM001 (określilibyśmy to jako główny DOM Cypress w rozmowie)

CYPRCHSQL001 to serwer SQL, CYPRCHMGM001 to jego zarządzanie (tj. Antywirusy, kopie zapasowe itp.), A CYPRCHAPP001 to serwer aplikacji mieszanych. Łatwy do zapamiętania, łatwy do sortowania, łatwy do nauczenia.

Bezsenność
źródło
1
Jak więc pamiętasz, które aplikacje działają na CYPRCHAPP001, a nie na CYPRCHAPP003? Przyznaję, że jest to problem również z nazwami mnenomicznymi, ale jeśli szukasz jakiegoś rodzaju nazw funkcjonalnych, równie dobrze może być specyficzny.
CVn
2
@ MichaelKjörling Szczegółowe informacje o tym, co znajduje się na serwerze, nie należą do nazwy, lecz do jakiejś dokumentacji. Jeśli ktoś musi wiedzieć, co działa na CYPRCHAPP001, zapozna się z dokumentacją. Poza przenoszeniem aplikacji CYPRCHAPP001_PointofSale_Payroll_HRSoftware-etc będzie błędem, gdy firma przeniesie swoje oprogramowanie płacowe do hostowanego rozwiązania.
Wulfhart
2
@Wulfhart zgadzam się z punktem, ale to, co jest nie tak z konieczności rekordy CNAME dla pointofsale, payrollitp? W ten sposób nikt oprócz administratorów nie musi martwić się dokładnie tym, gdzie działa oprogramowanie płac; dla wszystkich innych po prostu działa. Chcesz przenieść coś do innego centrum danych? Żaden problem. Chcesz przenieść bazę danych punktów sprzedaży na własny serwer dedykowany? Po prostu zaktualizuj pointofsale-databaseCNAME, aby wskazywał nową lokalizację. I tak dalej.
CVn
1
Załóżmy, że musisz wymienić maszynę: po zbudowaniu CYPRCHSQL002 i przetestowaniu go po prostu wycofujesz nazwę CYPRCHSQL001 (nigdy nie będzie zastępowana), czy zmieniasz nazwę 002 na 001 po usunięciu starego 001 lub czegoś jeszcze?
nickgrim
@ MichaelKjörling To wydaje mi się świetnym pomysłem. Przez „szczegóły nie należą do nazwy” nie miałem na myśli nazwy hosta komputera.
Wulfhart,
2

Jedynym wymaganiem dla nazw hostów jest to, że powinny być unikalne w sieci.

Znaczenie nie musi dotyczyć tylko funkcji serwerów. Lokalizacja może być bardzo przydatna, jeśli masz do czynienia z urządzeniami fizycznymi. Przydatna może być również wiedza, czy urządzenie jest wirtualne czy fizyczne. Możliwość odróżnienia urządzenia sieciowego, serwera linuksowego lub okna systemu Windows może być bardzo przydatna, jeśli chodzi o ustalenie, jakiego narzędzia użyć do zalogowania się.

Sposób, w jaki sobie z tym poradzimy, polega na umieszczeniu tych informacji w nazwie urządzenia w następujący sposób:

L lub T - na żywo lub test P lub V - fizyczny lub wirtualny S lub N - serwer lub sieć (nie mamy żadnych serwerów Linux) kolejny numer, aby zapewnić unikalność Trzyliterowy kod kraju ISO 3166-1 wskazujący, gdzie urządzenie jest usytuowany.

Następnie używamy CNAMES w DNS do mapowania różnych nazw usług na nazwę hosta.

Mam mieszane uczucia na ten temat. Z pewnością oszczędza czas na sprawdzanie, gdzie znajduje się określone urządzenie. Z drugiej strony znacznie trudniej jest zapamiętać, co robi dany serwer, gdy jest prezentowany z nazwą hosta, w porównaniu z naszym poprzednim systemem, który używał kamieni szlachetnych. Kamienie nie miały żadnego znaczenia, ale były łatwe do zapamiętania, ponieważ każda osoba mogła tworzyć własne połączenia.

Wydaje mi się, że jedyną radą byłoby rozstrzygnięcie jednego schematu, ponieważ największe zamieszanie powstało, gdy przechodziliśmy z jednego systemu do drugiego.

dunxd
źródło
Nie zgadzam się z tym: „Wiedza, czy urządzenie jest wirtualne czy fizyczne, może być również przydatne” w kontekście dyskusji na temat nazewnictwa . Oczywiście jest to użyteczna informacja, ale nie jest to pierwsza rzecz, którą musisz wiedzieć o serwerze, czytając jego nazwę. Ponadto P2V lub V2P albo psuje twój schemat, albo wymaga zmiany nazwy serwera, co może zepsuć inne rzeczy.
mfinni
1
Z mojego doświadczenia wynika, że ​​P2V lub V2P psują całą masę rzeczy i należy ich unikać, tam gdzie to możliwe - robimy to, dlatego nie jest to problem z naszą konwencją nazewnictwa. Konwencja nazewnictwa musi spełniać wymagania każdego, kto ją zaprojektował - w organizacji, w której pracuję, został zaprojektowany przez zespół zarządzający wszystkimi serwerami i sprzętem sieciowym, i chcą móc powiedzieć powyższe rzeczy. To może nie być dla ciebie odpowiednie, ale wtedy wszystko jest otwarte na debatę. Jedynym wymaganiem technicznym jest wyjątkowość.
dunxd