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

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?

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.

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.

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).

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.

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.