Я собираюсь настроить соглашение об именах хостов для наших серверов на основе предоставляемой ими службы, например http, https, smtp, pop, dns, sql и т. Д. Каждая служба находится на своих собственных виртуальных машинах на хост-сервере Xen (dom0 ), для которых существует несколько хост-серверов Xen (10+). Я прочитал схему именования центров обработки данных Марка Гарнера из Sun и RFC 1178, а также несколько поисковых запросов в Google, но они, похоже, сосредоточены на наличии множества серверов, которые выполняют только несколько сервисов, таких как более крупный кластер (10+) базы данных. серверы, большой кластер веб-серверов, большой кластер почтовых серверов и т.д. В моей ситуации мы работаем с небольшим кластером (2-4) виртуальных серверов для большого количества сервисов (12+). В этом отношении мне не нравится идея иметь разные темы имени хоста для каждой службы, например, все почтовые серверы названы в честь птиц, все серверы баз данных - после деревьев и так далее, потому что я думаю, что это сбивает с толку при очень небольшом количестве хостов и очень много разных сервисов. Мне интересно, есть ли у кого-нибудь хорошая идея для определения имен хостов в такой среде. Спасибо.
Поскольку у вас есть более одной службы на сервере, я бы посоветовал дать вашим машинам имя хоста на основе любой темы, которая вам нравится, а затем использовать «имена служб».
Например, хост Барт могут иметь названия служб www1, imap1 и ftp1.
Добавьте эти имена служб в DNS, а затем (в зависимости от ваших предпочтений и сложности) либо:
Теперь убедитесь, что вы ссылаетесь на службы на этом компьютере, используя имя службы (www1), а не имя хоста.
здесь я нашел хорошее соглашение об именах:
Что не так с http ###, sql ###, dns ### и т. Д.?
Соглашения об именах хороши, когда нет легко описываемого различия между тем, что делают различные виртуальные машины, но если на каждой из них работает отдельная служба, будет проще всего назвать их этой службой.
Схема именования, в которой я работаю сегодня, работает так:
| роль сервера || домен или владелец || код сайта || серийный номер || дополнительный модификатор |
Это переводится на такие имена: dnsenet0b1ab
Ключ к именованию - последовательность. Какую бы схему именования вы ни использовали, до тех пор, пока она передает нужную вам информацию и безжалостно соблюдается, вы обнаружите, что согласованное и информативное именование ускорит проекты и упростит управление для больших баз установок.
Эта система может показаться устрашающей, но она действительно хороша, когда вы к ней привыкнете, И о ней достаточно легко печатать и говорить. С первого взгляда легко определить тип сервера, его местонахождение и т. Д. Вы можете легко расширить его, включив в него другую информацию, которая для вас значит больше.
Для вещей, которые имеют доступ к клиенту, я думаю, что это отличная идея дополнить это описательными записями CNAME, которые не привязаны к серверу. Сделайте свой почтовый сервер mail.example.com, http-сервер intranet.example.com и т. Д.
Вы упомянули, что серверы разделяют роли. Если вы видите сходство между сервисами, создайте «серверный класс». Во многих местах SMS / SCCM, очереди печати и AV размещаются на файловых серверах ... назовите это «сервером управления хостом (hms)» или как-то еще.