Comments 74
>Однако утилита getmac, которую мы будем использовать для получения мак-адреса сетёвки, не может вернуть MAC для того интерфейса, который выключен!
Очевидно, что когда драйвер сетевой карты выгружен, то мак-адрес взять неоткуда. Следовательно, надо не отключать сетевое подключение, а, например, отключать на нём поддержку TCP/IP.
Очевидно, что когда драйвер сетевой карты выгружен, то мак-адрес взять неоткуда. Следовательно, надо не отключать сетевое подключение, а, например, отключать на нём поддержку TCP/IP.
Мы используем первый вариант и я уверен, — мы не одни такие.
Ни один из описанных «минусов» за несколько лет работы не проявился.
DHCP-сервер — прост как лом, его конфигурирование или переконфигурирование (у нас за три года это было лишь единожды) занимает считанные минуты даже для человека, кот. первый раз в жизни с ним встречается. И это уж точно проще чем написание/тестирование предложенного mac2ip
Но я уверен, вы получили массу удовольствия в процессе изобретения велосипеда :)
Ни один из описанных «минусов» за несколько лет работы не проявился.
DHCP-сервер — прост как лом, его конфигурирование или переконфигурирование (у нас за три года это было лишь единожды) занимает считанные минуты даже для человека, кот. первый раз в жизни с ним встречается. И это уж точно проще чем написание/тестирование предложенного mac2ip
Но я уверен, вы получили массу удовольствия в процессе изобретения велосипеда :)
А как насчёт нештатного завершения виртуальных машин, без освобождения ими адресов, взятых в аренду? Это существенно экономит время.
Насколько много у вас машин и как часто они создаются?
Для конкретики — например, у меня есть пул на 100 IP, в каждый момент времени поднято 50 машин, каждая машина работает 2-5 минут. С текущим подходом при создании свежей машины я точно знаю, что IP уже не используется, т.к. предыдущая машина с ним destroyed.
Если я правильно понимаю, для использования DHCP мне надо будет или завершать машины штатным способом, теряя ресурсы на это, или общаться с DHCP? чтобы освободить адреса.
В любом случае — вы правы, я получил массу удовольствия )
Насколько много у вас машин и как часто они создаются?
Для конкретики — например, у меня есть пул на 100 IP, в каждый момент времени поднято 50 машин, каждая машина работает 2-5 минут. С текущим подходом при создании свежей машины я точно знаю, что IP уже не используется, т.к. предыдущая машина с ним destroyed.
Если я правильно понимаю, для использования DHCP мне надо будет или завершать машины штатным способом, теряя ресурсы на это, или общаться с DHCP? чтобы освободить адреса.
В любом случае — вы правы, я получил массу удовольствия )
У вас целая /8 и можно IP адреса не переиспользовать сразу же, а выдавать циклически.
Да, сейчас — целая /8, потому что всё работает на локальных серверах, стоящих в офисе )
Но при размещении системы на у какого-либо првайдера, что скоро планируется делать, может оказаться, что адреса надо экономить + диапазоны могут быть с разрывами.
Но при размещении системы на у какого-либо првайдера, что скоро планируется делать, может оказаться, что адреса надо экономить + диапазоны могут быть с разрывами.
Тогда mac2ip станет довольно нетривиальным, не находите?
Мне кажется, что за исключением первого байта IP — он довольно универсален.
А кто вам «у провайдера» даст /8 global IPv4 адресов?
Но ведь я же и говорю, что поэтому и не рассчитываю на них.
А скрипт mac2ip ещё и как рассчитывает именно получить в своё распоряжение /8.
Если размещать систему где-то, то можно использовать те же частные диапазоны и VPN для доступа.
у вас пул 256^3 — дефицита адресов как-то не наблюдается
а для того, чтобы с DHCP не общаться — выставьте на нем lease time в низкое значение
а для того, чтобы с DHCP не общаться — выставьте на нем lease time в низкое значение
Если после уничтожения виртуальной машины создатётся новая VM с тем же MAC-адресом, разве DHCP-сервер просто не выдаст новой VM тот же самый IP-адрес, что был у уничтоженной VM?
Какая разница как часто они создаются и как они удаляются?
Вы, создавая новую машину, уже знаете какой mac ей будете задавать, — не создадите же вы две машины с одинаковым mac`ом?
Дело DHCP-сервера — выдать ip по вашему mac`у используя внутреннюю статическую таблицу mac->ip, он не будет разбираться включена еще одна машина с таким адресом или нет.
Вы, создавая новую машину, уже знаете какой mac ей будете задавать, — не создадите же вы две машины с одинаковым mac`ом?
Дело DHCP-сервера — выдать ip по вашему mac`у используя внутреннюю статическую таблицу mac->ip, он не будет разбираться включена еще одна машина с таким адресом или нет.
1) После того, как виртуальная машина поднялась, она получает случайный адрес от DHCP, и затем каким-то образом регистрирует себя в базе — т.е. указывает, что я — машина такого-то типа, получила от DHCP такой-то адрес.
1) Avahi
2) tools.ietf.org/html/rfc2136
А вообще вы изобрели stateless autoconfiguration из IPv6 на коленке. В вашем случае как раз проблеем совместимости нет (нет необходимости в IPv4, весь софт под вашим контролем) и можно использовать IPv6 непосредственно.
Спасибо, я почитаю про avahi/bonjour.
Если я правильно понял, именно этот метод (полное автоопределение IP) — нам не очень подходит, хоть в нём явно и не участвует DHCP. Проще и удобнее знать IP машины заранее и контролировать её состояние (поднялась она или нет), чем делать машину «самостоятельной».
Кроме того, всё равно остаётся проблема установления соответствия «машина, которую запустило ядро» — «машина, которая только что получила случайный IP и зарегистрировалась».
Если я правильно понял, именно этот метод (полное автоопределение IP) — нам не очень подходит, хоть в нём явно и не участвует DHCP. Проще и удобнее знать IP машины заранее и контролировать её состояние (поднялась она или нет), чем делать машину «самостоятельной».
Кроме того, всё равно остаётся проблема установления соответствия «машина, которую запустило ядро» — «машина, которая только что получила случайный IP и зарегистрировалась».
OK, возможно avahi вам не совсем подходит.
Но в stateless autoconfiguration IPv6 адрес однозначно определяется MAC адресом по адресу сети.
Но в stateless autoconfiguration IPv6 адрес однозначно определяется MAC адресом по адресу сети.
Пока ничего об этом, обязательно почитаю.
Однако перевод всей системы с IPv4 на IPv6 хотя и неизбежная вещь, но, думаю, куда более сложная, чем написание mac2ip (
Однако перевод всей системы с IPv4 на IPv6 хотя и неизбежная вещь, но, думаю, куда более сложная, чем написание mac2ip (
А можете описать характер сложностей? Технические (старые маршрутизаторы, IP адреса хранятся в базе как uint32, ad-hoc парсеры IP адресов в shell скриптах), организационные (неизвестная технология для персонала)?
Я сейчас не могу проконсультирваться с нашим админом, чтобы точно узнать о сложностях (и, действительно, так ли они велики).
Первое, что приходит на ум — нужно переделать kickstarts шаблонов VM и xen-серверов. (Xen-сервера объединеняются в облако — поэтому всё не ограничится просто правкой нескольких уже работающих серверов).
Параметры запуска Selenium RC и Selenium HUB используют IPv4 или hostnames, не знаю, честно говоря, как там сейчас с IPv6.
Но, думаю, самое страшное не само изменение всего на IPv6, а тестирование и вылавливание трудных багов, которые непременно будут.
Первое, что приходит на ум — нужно переделать kickstarts шаблонов VM и xen-серверов. (Xen-сервера объединеняются в облако — поэтому всё не ограничится просто правкой нескольких уже работающих серверов).
Параметры запуска Selenium RC и Selenium HUB используют IPv4 или hostnames, не знаю, честно говоря, как там сейчас с IPv6.
Но, думаю, самое страшное не само изменение всего на IPv6, а тестирование и вылавливание трудных багов, которые непременно будут.
UFO just landed and posted this here
Это тоже интересная идея, и об этом мы не подумали, спасибо.
Однако этот вариант тоже не решает проблему с освобождением адресов, выданных DHCP при нештатном завершении.
Кроме того, если сейчас можно пинговать VM, ожидая, пока она поднимется (это делается раз в пару секунд), в этом варианте необходимо будет с тем же интервалом подключаться к xen-серверу по ssh и выполнять на нём этот скрипт.
Однако этот вариант тоже не решает проблему с освобождением адресов, выданных DHCP при нештатном завершении.
Кроме того, если сейчас можно пинговать VM, ожидая, пока она поднимется (это делается раз в пару секунд), в этом варианте необходимо будет с тем же интервалом подключаться к xen-серверу по ssh и выполнять на нём этот скрипт.
UFO just landed and posted this here
>> пинг же вам показывает что сеть поднялась
>> но это не означает, что всё остальное уже работает
Конечно, это только первый уровень проверки готовности VM.
>> в случае использование xenAPI вам не понадобится ssh
>> вы будете подключаться к апи серверу через http(s)
Да, это, возможно, более быстрый вариант. Хотя всё равно менее удобно, чем просто пинговать.
Однако этот подход решает проблему в сопоставлении поднятой VM с выданным DHCP IP. Однако остаётся проблема с освобождением адреса при нештатном завершении.
>> но это не означает, что всё остальное уже работает
Конечно, это только первый уровень проверки готовности VM.
>> в случае использование xenAPI вам не понадобится ssh
>> вы будете подключаться к апи серверу через http(s)
Да, это, возможно, более быстрый вариант. Хотя всё равно менее удобно, чем просто пинговать.
Однако этот подход решает проблему в сопоставлении поднятой VM с выданным DHCP IP. Однако остаётся проблема с освобождением адреса при нештатном завершении.
UFO just landed and posted this here
это слишком много, я написал выше, на какие примерно условия мы ориентируемся:
«например, у меня есть пул на 100 IP, в каждый момент времени поднято 50 машин, каждая машина работает 2-5 минут»
Даже при lease time в минуту учёт гарантированно свободных в настоящий момент IP ощутимо усложнится.
Но да, если рассчитывать на большой пул адресов, это нормальный вариант. Правда, linux-то всё равно будет получать IP от DHCP дольше, чем сейчас )
«например, у меня есть пул на 100 IP, в каждый момент времени поднято 50 машин, каждая машина работает 2-5 минут»
Даже при lease time в минуту учёт гарантированно свободных в настоящий момент IP ощутимо усложнится.
Но да, если рассчитывать на большой пул адресов, это нормальный вариант. Правда, linux-то всё равно будет получать IP от DHCP дольше, чем сейчас )
> Первый вариант казался нам довольно сложным по нескольким причинам…
Я бы предложил использовать zeroconf/avahi, он как раз для этого замечательно подходит.
Я бы предложил использовать zeroconf/avahi, он как раз для этого замечательно подходит.
Если вы назначаете MAC-и самостоятельно, то можно сразу статику по тому же шаблону прописать в DHCP.
Верно, но об этом варианте я писал:
«Мы запустим DHCP сервер, который будет настроен так, чтобы выдавать IP по MAC-адресу в соответствии с описанным способом кодирования»
Однако, с нашей точки зрения, у него есть пара недостатков.
«Мы запустим DHCP сервер, который будет настроен так, чтобы выдавать IP по MAC-адресу в соответствии с описанным способом кодирования»
Однако, с нашей точки зрения, у него есть пара недостатков.
Поделитесь пожалуйста вашим мнением относительно недостатков.
Я рассказал о них неоднократно — в самом посте, а также в комментариях. В частности, об этом говорится в разделе 6.
Первая часть, пара лишних секунд действительно так критична?
Вторая, если прописывать статику этой проблемы не будет.
Вторая, если прописывать статику этой проблемы не будет.
Нормальное завершение будет занимать несколько дольше, чем 2 секунды. Но ведь mac2ip на винде работает сопоставимое время.
Хм, я только сейчас сообразил, что решение мы выбирали тогда, когда работали только с VM на linux, поэтому mac2ip был идеальным во всех отношениях вариантом.
Собственно, сложность появилась только со временем работы на винде (правда, первый комментарий на пост открывает перспективы для оптимизации скрипта).
Если не удастся радикально сократить время работы скрипта на винде — то в целом получится, что преимущество в mac2ip только в том, что эта схема уже отлажена и надёжно работает.
Хм, я только сейчас сообразил, что решение мы выбирали тогда, когда работали только с VM на linux, поэтому mac2ip был идеальным во всех отношениях вариантом.
Собственно, сложность появилась только со временем работы на винде (правда, первый комментарий на пост открывает перспективы для оптимизации скрипта).
Если не удастся радикально сократить время работы скрипта на винде — то в целом получится, что преимущество в mac2ip только в том, что эта схема уже отлажена и надёжно работает.
Непонятно, зачем вы так странно получаете MAC в Виндоуз, если для этого можно использовать штатную утилиту ipconfig или WMI.
Не уверен, т.к. не пробовал. Но не будет ли быстрее и проще без DHCP делать это через реестр: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Так вот, арендованный VM адрес не будет в этом случае освобождён сразу, а будет освобождён по истечении default-lease-time DHCP. Это значит, что мы не сможем сразу же запустить VM с таким же MAC (и таким же IP).
Только что проверил на ISC DHCP 4.1.1 и такой проблемы не увидел. Проверял так:
dhcpd настроен статикой и default-lease-time 3600
на клиенте: kill -9 $(pidof dhclient) && rm /var/lib/dhcp/dhclient.eth0.leases
хард-резет
После этого машина нормально загрузилась и получила свой адрес.
gribozavr, вот это отличные новости, спасибо за эксперимент!
Я попрошу нашего админа проверить то же самой на нашей конфигурации — если всё так, то тогда mac2ip снимем и повесим на стенку в рамочку. Надеюсь, о нём хотя бы интересно было почитать:)
Я попрошу нашего админа проверить то же самой на нашей конфигурации — если всё так, то тогда mac2ip снимем и повесим на стенку в рамочку. Надеюсь, о нём хотя бы интересно было почитать:)
Как всё сложно. А использовать паравиртуализованную БД для хранения IP не судьба? Тот же xenstore решит все проблемы (наверняка у VMWare есть что-то подобное).
Правильно я понимаю, что предварительно придётся:
1) конфигурировать каждый xen в облаке дополнительно, устанавливая соответствие типа имя домена-IP
2) как следствие, общий пул адресов разобъётся ещё на пулы для каждого из xen-серверов
3) нельзя будет использовать произвольные имена VM?
Кроме того, очевидно, ядро системы опять-таки будет вынуждено знать о настройках каждого из xen.
Чем этот вариант лучше варианта с DHCP?
1) конфигурировать каждый xen в облаке дополнительно, устанавливая соответствие типа имя домена-IP
2) как следствие, общий пул адресов разобъётся ещё на пулы для каждого из xen-серверов
3) нельзя будет использовать произвольные имена VM?
Кроме того, очевидно, ядро системы опять-таки будет вынуждено знать о настройках каждого из xen.
Чем этот вариант лучше варианта с DHCP?
Э… Не совсем. В атрибуты VM пишется IP (я бы это писал в атрибуты VIF), делать это может скрипт, который машину клонирует. (Кстати, он может по любому удобному алгоритму это делать, хоть по MAC'у, хоть по списку, хоть по времени создания, хоть по каким ещё параметрам). Дальше VM при старте смотрит свой IP и назначает его.
Плюс: смена алгоритма генерации IP потребует изменения в одном месте и будет применена к существующим машинам (после их перезагрузки). Аналогично может быть проблема смены сетевых настроек (шлюз, номер сети и т.д.).
Плюс: смена алгоритма генерации IP потребует изменения в одном месте и будет применена к существующим машинам (после их перезагрузки). Аналогично может быть проблема смены сетевых настроек (шлюз, номер сети и т.д.).
>> делать это может скрипт, который машину клонирует
скрипт так и делает, то прописывает MAC, а не IP.
>> Дальше VM при старте смотрит свой IP и назначает его.
Я был уверен, что IP невозможно напрямую передать в VM…
Поясните, пожалуйста, какими именно средствами VM смотрит на свой IP и как назначает его? Кто этим занимается, сама VM или каким-то образом xen? Какой именно атрибут испльзуется для того, чтобы прописать IP? Это имеет отношение к xenstore, или это уже другой вариант?
>> смена алгоритма генерации IP потребует изменения в одном месте и будет применена к существующим машинам (после их перезагрузки
это есть и при текущем подходе, всеми IP заведует ядро системы.
скрипт так и делает, то прописывает MAC, а не IP.
>> Дальше VM при старте смотрит свой IP и назначает его.
Я был уверен, что IP невозможно напрямую передать в VM…
Поясните, пожалуйста, какими именно средствами VM смотрит на свой IP и как назначает его? Кто этим занимается, сама VM или каким-то образом xen? Какой именно атрибут испльзуется для того, чтобы прописать IP? Это имеет отношение к xenstore, или это уже другой вариант?
>> смена алгоритма генерации IP потребует изменения в одном месте и будет применена к существующим машинам (после их перезагрузки
это есть и при текущем подходе, всеми IP заведует ядро системы.
Э… ребята, позоритесь. Лучшее изобретение Xen'а для Cross-Domain-Communication: XenStore.
Ставите в гостя утилиты xenstore-utils (есть в большинстве дистрибьютивов) и можете делать xenstore-read, xenstore-write.
Для развлечения сделайте из dom0 xenstore-ls, вас обрадует.
Ставите в гостя утилиты xenstore-utils (есть в большинстве дистрибьютивов) и можете делать xenstore-read, xenstore-write.
Для развлечения сделайте из dom0 xenstore-ls, вас обрадует.
>> и можете делать xenstore-read, xenstore-write.
ага, понял, это хороший вариант для Linux.
Но я навскидку не нашёл, поэтому спрошу — есть ли xenstore-utils для Windows?
ага, понял, это хороший вариант для Linux.
Но я навскидку не нашёл, поэтому спрошу — есть ли xenstore-utils для Windows?
Я с виндами вообще плохо, но, поскольку xenbus используется для поиска PV-драйверов, то доступ из HVM с виндами есть, драйвер есть. Насколько я понимаю, есть библиотека, так что написать простенький xenstore-read не так уж и сложно. гугль подсказывает: svn.zentific.com/trunk/Zentific-Tools/win32/zentsrv/xenstore.c
Смотрите, MAC на винде я могу получить стандартными для винды способами. Преобразовать его в IP — пара строчек в скрипте.
Ваш вариант позволит получить сразу IP, однако для этого придётся писать обёртку к xenstore-read. По-моему, это в данном случае совершенно лишнее звено.
Ваш вариант позволит получить сразу IP, однако для этого придётся писать обёртку к xenstore-read. По-моему, это в данном случае совершенно лишнее звено.
Э… Извиняюсь, а откуда ваша сетевая карта в виндах знает свой MAC? (это подсказка).
Я это понимаю следующим образом.
Xen эмулирует устройство — сетевую карту.
Думаю, что для винды это сэмулированное устройство ничем не отличается от реальной сетёвки.
Сетёвки обязаны иметь параметр «MAC». Раз xen эмулирует устройство, он имеет возможность установить этот параметр для сэмулированной сетёвки, соответственно, мы имеем возможность этот параметр задать в конфиге.
Если это так, то:
1) xenstore тут ни при чём
2) передача IP через параметры сетёвки таким способом невозможна, поскольку стандартные сетёвки не несут на себе сведений об IP
Xen эмулирует устройство — сетевую карту.
Думаю, что для винды это сэмулированное устройство ничем не отличается от реальной сетёвки.
Сетёвки обязаны иметь параметр «MAC». Раз xen эмулирует устройство, он имеет возможность установить этот параметр для сэмулированной сетёвки, соответственно, мы имеем возможность этот параметр задать в конфиге.
Если это так, то:
1) xenstore тут ни при чём
2) передача IP через параметры сетёвки таким способом невозможна, поскольку стандартные сетёвки не несут на себе сведений об IP
Если у вас 'xen эмулирует сетевую карту', то у вас используются qemu драйвера, а это безумно медленно. Вероятнее всего у вас стоят gplpv или citrix'овские PV-драйвера. А теперь вопрос — откуда они читают свои параметры?
Все паравиртуализированные устройства анонсируются и читают свои настройки через xenstore. Я ж сказал, сделайте xenstore-ls в dom0.
Все паравиртуализированные устройства анонсируются и читают свои настройки через xenstore. Я ж сказал, сделайте xenstore-ls в dom0.
К сожалению (или счастью), xen занимается наш админ, и я плохо разбираюсь в том, как происходит виртуализация устройств. Поэтому пока не могу вести диалог с вами на этом уровне.
Однако, даже если виртуализированные устройства читают свои настройки из xenstore, это ничего не меняет в моём утверждении, что MAC можно передать через настройки сетёвки (а потом получить стандартными средствами винды), а IP — нельзя.
Это верно?
Однако, даже если виртуализированные устройства читают свои настройки из xenstore, это ничего не меняет в моём утверждении, что MAC можно передать через настройки сетёвки (а потом получить стандартными средствами винды), а IP — нельзя.
Это верно?
Все PV устройства общаются с Xen, и поэтому их драйвера к стандартным средствам винды не относятся.
Выше человек уже написал — если вы ставите pv-драйвера, значит, как минимум, вы уже что-то в машину ставите. Использовать xenstore — куда более логичное решение для IDC, чем странные манипуляции с mac-адресами (попытка изготовить ipv6 из ipv4?)
amarao, скорее всего, вы правы, и использование xenstore — даже при том, что потребуется писать xenstore-read для винды — более красивый и правильный вариант, поэтому я разберусь в том, как его реализовать и насколько сложно это будет для нас.
Рад, что пост получился таким продуктивным — я получил идеи ускорения текущего варианта решения своей задачи (хотя, скорее всего, мы от него и откажемся), и несколько идей, о которых совершенно не имел понятия — спасибо.
Рад, что пост получился таким продуктивным — я получил идеи ускорения текущего варианта решения своей задачи (хотя, скорее всего, мы от него и откажемся), и несколько идей, о которых совершенно не имел понятия — спасибо.
Sign up to leave a comment.
Задаём виртуальной машине IP по MAC без использования DHCP