Вибір між змістовними та безглуздими іменами хостів [закрито]

Припустимо середовище з кластерним керуванням ляльок різних серверів - різного обладнання, програмного забезпечення, операційних систем, віртуальних / виділених тощо.

Ви б вибрали значущі імена хостів (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup тощо), чи віддасте перевагу безглуздим іменам хостів, таким як персонажі з книги чи фільму?

Проблема, яку я бачу при значущих іменах хостів, полягає в тому, що імена, як правило, являють собою одну службу, і якщо сервер має кілька цілей, він стає справді безладним (особливо, якщо ролі сервера часто змінюються).

Не відображає ім’я служби з IP-адресою та не підтримує це відображення тим, що DNS повинен робити?

Які переваги та недоліки обох підходів та які актуальні проблеми вам довелося вирішити із обраним вами підходом?

Колись у мене була можливість визначитися зі схемою іменування. Тож я розібрався і запитав своїх розробників, які зрештою були людьми, яким доводилося щодня працювати з цими іменами, чи віддають перевагу функціональним іменам (тобто іменам, які представляють у певному закодованому вигляді призначення машини) або мнемонічні назви (тобто назви, отримані з якоїсь раніше існуючої схеми іменування людиною, яка не містила неявного вмісту щодо призначення машини).

З 38 розробників 37 кращих мнемонічних імен; лише одне переважне функціональне найменування. Тому я назвав їх усі по річках (існує дуже великий набір можливих назв, і багато з них короткі, легко запам’ятовуються і швидко набираються).

Людський мозок досить добре розроблений для приєднання значення до імен. Якщо ви надасте запам’ятовуються імена, люди досить швидко запам’ятають, для чого ці імена використовуються, і використовуватимуть їх. Якщо ви використовуєте назви, виведені з якогось загального фону (наприклад, річки, стихії, зірки, округи, напої, ви розумієте), це допомагає людям негайно розпізнати ім'я хазяїна компанії, коли вони натрапляють на нього; інакше висловлювання на кшталт "весь електронний лист увімкнено betelgeuse" можуть бути дещо заплутаними).

І навпаки, мої розробники вважали, що їм на попередніх робочих місцях було дуже важко запам'ятати, що саме pr1ms001було.

Але я мушу додати, що ми використовували CNAME у внутрішній DNS для надання функціонального імені для мнемічного відображення імен, тому, якщо вам дійсно було легше запам’ятати, що основний поштовий сервер на першому кластері на PR-сайті був pr1ms001, то DNS буде дайте вам знати, що це було зараз orwell. Крім того, це дозволить нам мати багато функціональних імен на одній машині, так що поки ви завжди використовували функціональне ім'я, що відповідає функції, над якою ви працювали, ви можете бути впевнені, що pr1imap001це завжди вказуватиме на сервер IMAP, навіть якщо ми перемістили цю функціональність від orwellдо rhine. І коли hudsonпомер, ми могли змінити назву заміни, не впливаючи на оперативні функції, так що у нас ніколи не було "ви маєте на увазі нове hudsonчи старе hudson?" плутанина.

Це значною мірою зводиться до того, чи є ваші сервери petsчи livestock.

Домашні тварини отримують індивідуальні імена. Вони відрізняються один від одного, і ми дбаємо про ці відмінності. Коли хтось захворіє, ми зазвичай намагаємося повернути його до здоров'я. Традиційно серверами були домашні тварини.

Худоба отримує чисельність. Вони здебільшого однакові, і які існують відмінності, нас не хвилює і зазвичай намагаються мінімізувати. Коли один захворіє, ми відкладаємо його і отримуємо ще одного. Повністю віртуалізовані сервери, особливо сервери IaaS, такі як AWS, є худобою.

У більшості складних середовищ у вас є суміш. Наприклад, ваші веб-сайти - це майже напевне поголів’я. Якщо вам потрібно більше, ви обертаєте ще кілька стандартних конфігурацій; якщо вам не потрібно стільки, ви вимикаєте. Ваші сервери баз даних у деяких конфігураціях - домашні тварини. На кожному може бути багато спеціальних налаштувань; ви можете навіть запускати їх на голому металі замість віртуалізації.

Звичайно, в будь-якому середовищі ви можете називати ПОСЛУГИ та безпосередньо звертатися до них. Це найкраща практика в будь-якому випадку; ваші розробники не повинні знати або дбати про те, що власне ім'я хоста послуги. Ім'я хоста має бути суто оперативною деталлю. Тоді подумайте про кодування інформації, яка корисна персоналу вашого оператора в іменах хостів - наприклад, часто корисно позначити, в якому центрі обробки даних працює сервер.

Це було висвітлено тут раніше ...

Моя рекомендація - це поєднання функціональних імен та мнемонічних назв ...

Якщо ви пишете заявку, і їй потрібно звертатися ccts-logserver1, використовуйте це ім’я в усьому світі, але зробіть це CNAME або псевдонім. Справжнє ім’я хазяїна може бути будь-яким, що вам завгодно: фруктовим чи овочевим, грецькою міфологією чи символом Шейнфельда ... але це дає вам певну гнучкість, коли вам потрібно асоціювати реальні функціональні назви, але зберігайте щось, що люди можуть запам’ятати.

Пригадайте приклад, де mangoсервер БД виходить з ладу ... але замінюється чимось іншим, скажімо peach. Можливо, потрібно бачити існуючі процеси та програми cmt-prod-db1. Ви можете обмінюватися системами, створювати їх, не називаючи конфліктів і підтримуючи програми (та розробники) щасливими.

Де я працюю, ми управляємо декількома сайтами, кількома компаніями, у багатьох містах. Для нас мнемонічні імена не можуть працювати. Замість цього ми використовуємо скорочену форму, яка описує наші сервери. У нашому випадку це добре працює, оскільки у нас є кілька клієнтів, які можуть мати кілька офісів у різних доменах (або один офіс у кількох доменах, або кілька офісів на одному домені, або все вищезазначене!)

Для нас інформація містить компанію / домен, місто, функцію, номер. Так що для контролера домену для компанії, скажімо, Cypress в Чикаго, це було б:

CYPRCHDOM001 (У розмові ми би назвали це головним DOM Cypress)

CYPRCHSQL001 - це сервер SQL, CYPRCHMGM001 - це його управління (тобто антивірус, резервне копіювання тощо), а CYPRCHAPP001 - це змішаний сервер додатків. Легко запам'ятовується, легко сортується, легко навчається.

Єдина вимога до імен хостів - це те, щоб вони були унікальними в мережі.

Сенс не має стосуватися лише функції сервера. Розташування може бути дуже корисним, якщо вам доведеться мати справу з фізичними пристроями. Знання, чи пристрій віртуальний чи фізичний, також може бути корисним. Можливість виявити різницю між мережевим пристроєм, сервером Linux та вікном Windows може бути дуже зручною, якщо мова йде про те, який інструмент використовувати для входу.

Ми намагаємося вкласти цю інформацію у назву пристрою наступним чином:

L або T - Живий або Тестовий P або V - Фізичний або віртуальний S або N - Сервер або мережа (у нас немає жодних серверів Linux) послідовний номер для забезпечення унікальності ISO тривалий трицифровий код країни, що вказує, де знаходиться пристрій знаходиться.

Потім ми використовуємо CNAMES в DNS для зіставлення різних імен служб через ім'я хоста.

У мене змішані почуття з цього приводу. Це, безумовно, заощаджує час на пошук місця, де знаходиться певний пристрій. З іншого боку, набагато складніше запам’ятати, що робить даний сервер, коли він представлений своїм іменем хоста, порівняно з нашою попередньою системою, яка використовувала дорогоцінні камені. Камені дорогого значення взагалі не передбачали жодного сенсу, але їх було легко запам’ятати, оскільки кожна людина могла створити власні зв’язки.

Я думаю, що єдиною порадою було б зупинитися на одній схемі, оскільки найбільша плутанина виникла при переході від однієї системи до іншої.