Какая уникальная, постоянная альтернатива MAC-адресу?

Question

Мне нужно иметь возможность повторять, неслучайно, однозначно идентифицировать хост сервера, который может быть произвольно виртуализирован и над которым я не контролирую.

• MAC-адрес не работает, поскольку в некоторых виртуализованных средах сетевые интерфейсы не имеют аппаратных адресов.
• Создание файла состояния и сохранение его на диск не работает, потому что виртуальная машина может быть клонирована, что дублирует файл.
• Ключи хоста сервера SSH могут быть кандидатами. Они могут быть клонированы как файл состояния, но на практике они обычно не потому, что это такая проблема безопасности, что это ошибка, которую часто не делают.
• Существует также/var/lib/dbus/machine-id, но это зависит от dbus. (Спасибо преэтам).
• Есть cpuid, но это, очевидно, устарело. (Спасибо Бруно Агирре в Twitter).
• Имя хоста стоит рассмотреть. Многие системы, такие как Chef, уже требуют уникальных имен хостов. (Спасибо Alfie John)

Я бы хотел, чтобы решение сохранялось долгое время, и, конечно же, перезагрузка сервера и перезагрузка программного обеспечения. В конечном счете, я также знаю, что пользователи моего программного обеспечения будут обесценивать хост и хотят заменить его другим, но сохраняют непрерывность связанных с ним данных, поэтому есть причины, по которым UUID может считаться изменчивым в долгосрочной перспективе, но я не Особенно хочу, чтобы хост начал считать себя неизвестным и перерегистрироваться без причины.

Есть ли альтернативные постоянные уникальные идентификаторы для хоста?

Answer 1

Это действительно зависит от того, что подразумевается под «стойким». Например, две виртуальные машины не могут открывать для вас один и тот же сетевой сокет, поэтому даже если они являются клонами на уровне бит, можно рассказать их обособленно.

Таким образом, все, что требуется, - это достаточная информация, чтобы рассказать обо всех машинах независимо от продолжительности сохранения.

• Если длительность сохранения длина сетевого соединения, то вам не нужны никакие идентификаторы вообще - сокеты сами являются уникальными.

• Если стойкость должна быть длиннее - скажем, для длины загрузки - тогда вы можете регенерировать UUID каждый раз, когда система загружается. (Обратите внимание, что виртуальная машина, которая клонирована, все равно должна перезагрузиться, если вы ее не скопируете.)

• Если это должно быть длиннее, чем, скажем, неопределенно, то вы можете сгенерировать UUID идентификатор при загрузке и сохранить его на диск, , но используйте это только как часть идентифицирующей информации машины. Если впоследствии виртуальная машина будет клонирована, вы узнаете об этом, так как у вас будет две машины, сообщающие один и тот же идентификатор из разных источников - например, два разных сетевых сокета, разные времена загрузки и т. Д. Поскольку вы можете рассказать их обособленно, у вас есть достаточно информации для дифференциации двух клонированных машин, что означает, что вы можете предпринять последующее действие, которое заставляет больше дифференцировать, например, инструктировать каждую машину для восстановления своего файла состояния.

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

Подразумевая, что вы можете сказать разницу между «реальным» и «клонированного один» означает, что существует некоторое состояние вы можете использовать, чтобы записать разницу между ними, как и временной метке, когда виртуальная машина сам был создан, и в этом случае вы можете включить это в государственную запись.

Answer 2

Если я правильно понимаю, вы хотите, прочный, глобально уникальный идентификатор в этих условиях:

• установку ОС, которые могут быть клонированы во время работы, так что любое состояние внутри ВМ не будет работать, и
• Может быть запущен в произвольной среде виртуализации, поэтому любое состояние за пределами VM не будет работать.

Я понимаю, что это прямо не отвечает на ваш вопрос, но действительно кажется, что дизайн или ограничения требуют некоторой существенной корректировки для размещения решения.

Answer 3

Я не думаю, что есть прямое решение «использовать X-решение» на основе имеющейся информации, но вот несколько общих советов, которые могут помочь вам стать лучше.

• Если клонирование из «золотого изображения» предполагает использование некоторой логики «первой загрузки» для генерации уникального идентификатора. Системы управления Config, такие как Chef, Puppet или Cf-engine, обеспечивают некоторые строительные леса для достижения этого.
• Рассмотрим глобального государственного менеджера, такого как zookeeper. В частности, это функция атомного счетчика. Такая же система может получить новый идентификатор с течением времени, но она будет уникальной.
• Также этот stack overflow может дать вам другое направление. Он ссылается на подход Twitter к аналогичной проблеме.

Answer 4

Похоже, что простые решения были исключены. Таким образом, это может привести к сложным решениям, таким как этот протокол: - Клиент отправляет кортеж [MAC-адрес, SSH-код общедоступного хоста, порядковый номер] - Если сервер получает этот кортеж, как ожидалось, сервер и клиент оба увеличивают порядковый номер. - В противном случае сервер должен определить, что произошло (клиент был клонирован, клиент переместился?), Возможно, доведя предварительный вывод и предупредив человека о его проверке.