Які найбільш керовані та цікаві схеми іменування серверів використовуються? [зачинено]

Мені цікаво побачити, які схеми використовуються при іменуванні серверів ...

По-перше, кожен, хто вибирає схему іменування, повинен прочитати RFC 1178 - "Вибір імені для комп'ютера" . Люди говорять про цю проблему до тих пір, поки комп’ютерам не давали імена, тому читайте, що сказали інші, перш ніж винайти колесо.

Мої власні думки - я схильний розбивати політику іменування на теми та схеми .

Використання теми (наприклад, грецькі боги, персонажі від Dr. Who, марки горілки) добре працює в невеликій мережі. Якщо у вас менше 20 хостів, швидше за все, у вас є кілька апаратних конфігурацій - можливо, кожен хост має унікальну конфігурацію. У таких випадках добре вміти вважати кожну машину такою, що має унікальну особистість, адже - шанси є - це так і є.

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

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

Проблеми з темами включають:

• Зазвичай вони містять невеликий пул імен. Як тільки у вас закінчилися римські боги, ви переходите на грецьку? Ви повторно використовуєте ім’я у відставного хоста, який відповідає вашій темі іменування, або вибираєте нове ім’я з нової теми, щоб уникнути проблем і плутанини, які можуть виникнути внаслідок повторного використання імені?
• Вони дозволяють антропоморфізувати ваші машини. Це погано - комп’ютери не люблять цього. Якщо ви ставитесь до своїх машин так, ніби вони мають чітку особистість, ви ризикуєте ігнорувати докази, що суперечать вашим припущенням про те, як ця машина "поводиться", а також іноді припускаючи, що несправність лежить на певній машині, оскільки "це завжди недоброзичливо ».

Проблеми зі схемами включають:

• Вони призводять до імен хостів, які важче запам'ятати. Це набагато менше проблем, коли у вас є гарне управління системами, але іноді корисно мати можливість миттєво згадати, що певна проблема проявляється не раз на певній машині, або що саме певна машина відповідальна за виконуючи якусь конкретну функцію.
• Якщо схема зміниться, можливо, доведеться перейменувати всіх своїх хостів. Це може призвести до великої кількості змін у DNS, зміни конфігурації, списку доступу та змін дозволів тощо.

У реальному світі ви знайдете обидві системи, що використовуються, іноді поруч. Наприклад, на мій досвід, високопродуктивні обчислювальні кластери завжди мають імена. Ім'я часто присвоюється головному вузлу (який використовується інтерактивно), тоді як різні вузли кластера матимуть імена, такі як compute-01, highmem-01, storage-01 тощо.

І, як було сказано раніше, для віртуальних машин і фізичних хостів прийнято використовувати різні схеми іменування.

Під цікавою категорією є одна з відповіді на переповнення стека

Елементи періодичної таблиці. Ми також використовуємо номер елемента в IP-адресі, так

Водень = 192.168.0.1

Гелій = 192.168.0.2

тощо.

Я ДУЖЕ прихильний називати фізичні сервери за їх місцезнаходженням (тобто код країни / код міста / код центру даних / код / ​​підлога / стійка / стійка-висота) та програмне забезпечення / VM-сервери лише за їх функцією ( платформа / функція / кластер / ітерація). Я знаю, що це може зробити імена довше, ніж називати їх після семи гномів чи що завгодно, але це чудовий спосіб забезпечити, що ви більше 'захищені від майбутнього' та займаєтесь віртуалізацією структурно.

Як приклад, ми маємо сервери VMWare під назвою 044LONTH72G216 (це локалізує сервер саме у світі) з VM-серверами гостьових серверів, такими як NESQLC11S08. Ви завжди можете створити короткі імена для роботи в ІТ-команді, кожен з яких посилається на ці більш довгі, більш організовані імена.

Сподіваюсь, це допомагає.

Ми почали називати наші сервери певною темою (книги Біблії), але, коли наша ІТ-команда (і кількість серверів) зростала і стала більш спеціалізованою - і, як ми мали більше плинності персоналу, ми виявили, що будь-яка система імен, яка не якимось чином пов'язані з функцією (або розташуванням) сервера стали заплутаними.

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

Тепер ми перейшли до більш описової схеми іменування.

Ми даємо всі наші сервери імена відповідно до їх ролі, тобто того, що вони роблять.

Отже, наші сервери мають такі назви

- PDC
- SQL
- EXCHANGE
- RDP
- FILE etc..

На мій досвід, сервери з нечитабельними іменами (тобто метод схеми) не є керованими. Я часто бачив помилкові символи, що призводять до того, що невірний сервер із застосуванням xyz застосовано до нього, іноді з катастрофічними результатами.

Зрозуміле для людини ім'я з пов'язаними метаданими, що зберігаються в полі опису чи подібними, здається, менш схильні до проблем PEBKAC.

До деяких багаторічних фаворитів належать:

• Грецькі боги
• Римські боги (іноді відрізняються від "Планет")
• Скандинавські боги (самим недоброзичливим сервером може бути Локі)
• Князі Бурштину
• Філософи

Ми почали з Бертом і Ерні ще в ті часи, коли кластер з 2 microVAX 3400 був великою справою для компанії. Ми на деякий час трималися на вулиці Сезамі - Бігбірд, Елмо, Гровер, акаунт (фінансова система), але врешті-решт довелося піти за схемою. Від того, які елементи в схемі залежать від розміру вашої компанії, ми повинні були включити:

Місцерозташування (2-літерне абревіатура для міста) Відділ (компанія була утворена об'єднанням 4 спільнот, тому ми мали 3-літерну абревіатуру для цих функцій) Функція (PDC, пошта, друк, www тощо). Серійний номер (I мені завжди подобалося, що рік та місяць є частиною серійного номера)

Персонажі Сімпсонів :)

Колись був клієнт, який назвав серверів після зайчиків Playboy. Однак це не було широко розголосовано поза межами ІТ. ;-)

Мені подобалося називати їх після великих котів, але тоді OS X прийшов і зруйнував це для мене.

Ще одна прикмета - види алкоголю. JimBeam, Beefeater, Stoli тощо. Різні класи алкоголю були різними класами сервера. Джин для поштових серверів, віскі для баз даних, PDC завжди був самогонним.

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

Музиканти в топ-40.

Вони змінюються досить часто, щоб надавати нові свіжі, але що ще важливіше, вони будуть досить скептичними для тих, хто старше 12 років.

Ми схильні мати ініціали компанії з подальшим її завданням, а потім його числом, тобто

GSK-WEB-12
ST-DB-3

Ми використовуємо це, що працює досить добре.

• сайт (2 символи)
• dev / test / live (3/4 символів)
• функція (3+ символів)
• кількість (2 символи)
• vm чи ні (2 символи)

У своїх робочих місцях я бачив наступні тенденції, крім класичного сервера01, сервера02 тощо:

• дорогоцінні камені
• риба
• квіти
• Герої Зоряних воєн
• тварин

В університеті, де я навчаюсь, вони використовують імена різних персонажів з історій Астерікс та Обелікс. Такі як miraculix, astmatix і т.д.

Всі наші сервери названі на честь домашніх тварин. з невеликим розбиттям за типом. Всі контролери домену названі на честь птахів. Собаки для файлів і друку. Кішки для серверів додатків.