Задаём виртуальной машине IP по MAC без использования DHCP


    В статье рассказывается о использовании скриптов для CentOS и Windows XP, которые устанавливают IP в соответствии с MAC сетевого интерфейса VM, а также о сложностях управления сетевым интерфейсом в Windows

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

    Конечно, в момент запуска каждая виртуальная машина идентична шаблонной. В том числе наследуются и установленные параметры сети. Все виртуальные машины работают в одной подсети, а значит, они не должны пользоваться тем статическим IP, который достался им от шаблонной машины — иначе будут возникать конфликты. То есть каждая машина должна получить собственный IP. Казалось бы, решение очень простое — использовать DHCP сервер и динамические IP.

    Однако, есть и другой вариант, о котором я расскажу в этой статье.

    1. Для чего нам нужны виртуальные машины
    2. Проблема одинаковых статических адресов при запуске нескольких клонов VM
    3. Кодируем IP в MAC
    4. Выделение IP по MAC: DHCP
    5. Выделение IP по MAC: скрипт mac2ip
    a) Linux
    b) Windows
    6. Замечания

    Update
    Update 2

    Спойлер: собственно, самое интересное — в пунктах 3) и 5), остальное — для тех, кто захочет увидеть всю картину.

    1. Для чего нам нужны виртуальные машины


    Наш проект, Nerrvana, выполняет функциональные тесты сайтов в разных браузерах. Тесты эти работают со специальным фреймворком для функционального тестирования — Selenium, который позволяет эмулировать действия пользователя в брaузере (клики по элементам, движения мышью, ввод символов, чтение текста), делать скриншоты страниц и некоторые другие вещи.
    Тест сайта представляет собой последовательность действий, которые мог бы сделать на сайте пользователь, и проверок, что результат этих действий — точно такой, как ожидается. Например, простейший тест — логин на сайт. Необходимо открыть страницу логина, ввести логин, пароль, нажать «Ввод», и убедиться, что мы залогинены — скажем, увидев стандартное приветствие. Все знают, что браузеры могут совершенно по-разному отображать и работать с одной и той же страницей, и поэтому имеет смысл выполнить одинаковые тесты в наиболее популярных браузерах. Как уже говорилось, именно этой работой и занимается наша система.

    Тесты в выбранных браузерах выполняются одновременно и совершенно независимо друг от друга. Выполнение теста в одном из браузеров мы назвали спеком (speck). То есть, допустим, если я хочу выполнить тест логина на браузерах IE 8 и FF 3.6, наша система сделает два независимых спека — выполнит код тестов с использованием выбранных браузеров. Не сильно вдаваясь в подробности, скажу, что для работы каждого спека мы создаём как минимум две виртуальные машины. Одна машина, «хаб», будет заниматься собственно выполнением тестов — там есть Java и PHP, на которых должны быть написаны тесты. На второй машине, «тестере», работает Selenium RC и нужный браузер. Через Selenium RC происходит взаимодействие между тестами и браузером. После выполнения каждого спека виртуальные машины, на которых он работал, уничтожаются.

    Так как одновременно работающих тестов может быть много, и каждый может использовать несколько спеков, виртуальных машин тоже может работать относительно много — 50, к примеру.

    2. Проблема одинаковых статических адресов при запуске нескольких клонов VM


    Для каждого типа виртуальных машин имеется шаблонный образ. Когда ядру системы требуется очередная машина, этот образ копируется, и запускается копия образа — сам образ остаётся неизменным. Таким образом, одновременно может работать очень много копий по сути одной и той же машины.

    И тут появляется некоторая проблема.
    Естественно, в момент запуска каждая виртуальная машина абсолютно идентична шаблонной — ведь все данные хранятся в образе, в который нельзя внести изменений. В том числе наследуются и установленные параметры сети. Так как все виртуальные машины работают в одной подсети, совершенно очевидно, что они не должны пользоваться тем статическим IP, который достался им от шаблонной машины — иначе будут возникать конфликты адресов. То есть каждая машина должна динамически получить собственный IP.
    Казалось бы, решение очень простое — использовать DHCP сервер, который и выдаст каждой машине уникальный адрес.

    Однако, не всё так просто. Дело в том, что ядро системы активно взаимодействует с виртуальными машинами. Оно должно проделать просто кучу работы с ними: например, убедиться, что виртуальные машины успешно стартовали, запустить Selenium RC на тестере, загрузить на хаб и выполнить сами тесты, следить за их выполнением, а потом получить обратно результаты (скриншоты, логи и т.д.). Работа ведётся через ssh.
    Т.е. ядро системы, как ни крути, должно знать IP-адреса машин, которые только что были запущены по её требованию.

    Мы видели два подхода к решению задачи:
    1) После того, как виртуальная машина поднялась, она получает случайный адрес от DHCP, и затем каким-то образом регистрирует себя в базе — т.е. указывает, что я — машина такого-то типа, получила от DHCP такой-то адрес.
    2) Каким-то образом ядро даёт понять виртуальной машине, какой адрес ей следует использовать, т.е. соответствие IP — виртуальная машина имеется ещё до запуска машины.

    Первый вариант казался нам довольно сложным по нескольким причинам. Этот вариант делал VM слишком  независимыми от ядра,   появлялась лишняя связь — от виртуальной машины к базе, появлялись сложности с сопоставлением запрошенных и зарегистрированных VM, и некоторые проблемы, связанные с архитектурой ядра.
    Второй вариант нам нравился куда больше, потому что ядро сразу получало полный контроль над VM, а не оказывалось в подвешенном состоянии в ожидании, пока VM сама зарегистрируется.

    3. Кодируем IP в MAC


    Как же воздействовать на ещё не запущенную машину, чтобы сообщить ей будущий ip-адрес? Мы нашли такой способ: при запуске виртуальной машины можно задать MAC-адрес виртуальной сетевой плате. А сама виртуальная машина может в любой момент его узнать. То есть MAC можно использовать как носитель информации о IP (или о чём-нибудь ещё).

    Как именно мы будем кодировать IP в мак-адресе? Для виртуализации мы используем Xen, и виртуальные сетевые платы xen должны иметь MAC, который выглядит так: 00:16:3E:XX:XX:XX, где 00:16:3E — код производителя сетевой платы. Последние три байта мы можем использовать по своему усмотрению (конечно, помня о том, что MAC должен быть уникальным).
    Предположим, что наша система будет работать в подсети 10.0.0.0/8, и поэтому логичное решение — использовать для трёх последних байтов MAC значения, соответствующие трём последним байтам IP адреса, который мы хотим закодировать.
    То есть для адреса 10.1.1.3 мы будем использовать MAC 00:16:3E:01:01:03.

    Осталось заставить машину получить нужный IP, соответствующий её MAC. Это опять-таки можно сделать двумя способами.

    4. Выделение IP по MAC: DHCP


    Первый способ довольно очевиден. Мы запустим DHCP сервер, который будет настроен так, чтобы выдавать IP по MAC-адресу в соответствии с описанным способом кодирования.

    Сценарий работы будет выглядеть так:
    1) Ядру требуется VM.
    2) Ядро просматривает пул IP-адресов, выбирает первый незанятый IP (например, 10.4.0.15), и преобразует его в MAC (00:16:3E:04:00:0F)
    4) Ядро копирует шаблонный образ VM нужного типа, подготавливает файл конфигурации VM (в котором указывает в том числе и полученный MAC)
    5) Ядро запускает VM
    6) VM обращается к DHCP за адресом, тот сверяется с таблицей соответствия MAC/IP, и выдаёт IP 10.4.0.15.
    7) Ядро в это время периодически пингует 10.4.0.15, и, получив ответ, начинает работать с виртуальной машиной (конечно, предварительно дождавшись старта sshd)

    - требуется DHCP сервер
    - если мы переедем в другую подсеть или получим другой пул IP-адресов, придётся менять конфигурацию не только ядра, но и DHCP
    + используется стандартный подход к получению IP

    5. Выделение IP по MAC: скрипт mac2ip


    Второй способ менее очевиден и требует некоторой дополнительной работы.
    Он заключается в том, что VM при старте выполнит специальный скрипт, который получит MAC, преобразует его в IP, и назначит сетевой плате. Сценарий работы, таким образом, будет практически таким же — изменится только пункт 6. Он будет выглядеть так:

    6) VM вычисляет свой IP на основании своего MAC, и устанавливает его перед стартом интерфейса.

    + не требуется дополнительное звено в виде DHCP и хранения там таблицы соответствия MAC-IP.
    - для каждой ОС потребуется свой скрипт mac2ip

    Мы реализовали именно этот вариант.
    Мы работаем с виртуальными машинами с CentOS 5.6 и Windows XP PRO SP3, и поэтому нам нужно было два скрипта mac2ip — для каждой из систем.
    Рассмотрим оба скрипта.

    a) Linux

    #!/bin/bash
    
    # первый байт всегда будет равен 10
    IP1=10
    
    IFCFG=/etc/sysconfig/network-scripts/ifcfg-eth0
    NETWORK=/etc/sysconfig/network
    
    case "$1" in
    *start)
    ;;
    *)
    exit
    ;;
    esac
    
    # получаем MAC и проверяем, что мы его таки получили
    MAC=$(ifconfig eth0|grep HWaddr|awk '{print $NF}'|grep ^00:16:3E)
    if [[ -z "$MAC" ]] ; then
    echo "Can't determine MAC address" >&2
    exit 1
    fi
    
    # преобразуем MAC в IP
    set -- $(echo $MAC|awk -F: '{print $4,$5,$6}')
    IPADDR=${IP1}.$((0x$1)).$((0x$2)).$((0x$3))
    
    # меняем настройки интерфейса
    sed -i -e "s/^IPADDR.*/IPADDR=$IPADDR/" $IFCFG
    sed -i -e "/^HWADDR/d" $IFCFG
    sed -i -e "s/^HOSTNAME.*/HOSTNAME=localhost/" $NETWORK

    И заставляем запускаться этот скрипт до запуска network.

    b) Windows

    Та же самая работа в Windows XP делается куда более заумными путями. Возможно, со временем найдётся более эффективный способ преобразования MAC в IP.

    Первая проблема, с которой я столкнулся — это невозможность относительно лёгкими путями изменить адрес интерфейса ДО его включения. Таким образом, шаблонная VM должна иметь выключенный по умолчанию «сетевое подключение», иначе две одновременно запущенные копии Windows сразу после запуска попробуют использовать один и тот же адрес (он статический, т.к. для VM мы не используем DHCP).

    Ок, это не проблема — выключить интерфейс. Однако утилита getmac, которую мы будем использовать для получения мак-адреса сетёвки, не может вернуть MAC для того интерфейса, который выключен! Поэтому нам придётся сначала присвоить интерфейсу случайный IP, включить его, узнать MAC, и уже тогда установить желаемый IP.

    Для манипуляций с устройствами используется утилита devcon.
    Вот как это выглядит:
    @echo off
    SET MAC=
    SET IP=
    SET MASK=255.255.255.0
    SET GATEWAY=
    
    rem получаем случайный IP. Этот IP будет использоваться в течении пары секунд,
    rem и поэтому для обеспечения уникальности достаточно сгенерировать случайно два последних байта.
    rem 100 - смещение, которое гарантирует, что мы в любом случае
    rem не воспользуемся реально используемыми IP.
    set /A TEMP_THIRD_BYTE=100+%RANDOM:~0,2%
    set /A TEMP_FOURTH_BYTE=100+%RANDOM:~0,2%
    set TEMP_IP="192.168.%TEMP_THIRD_BYTE%.%TEMP_FOURTH_BYTE%"
    set TEMP_GATEWAY="192.168.%TEMP_THIRD_BYTE%.1"
    
    rem устанавливаем параметры интерфейса
    netsh interface ip set address local static %TEMP_IP% %MASK% %TEMP_GATEWAY% 1
    
    rem включаем интерфейс. для этого мы используем
    C:\devcon\i386\devcon enable *VEN_10E*
    
    rem получаем три последних байта MAC
    FOR /F "Tokens=4-6 Delims=- " %%d in ('getmac^|find "Device\Tcpip_"') do (
    set /a dec_d=0x%%d
    set /a dec_e=0x%%e
    set /a dec_f=0x%%f
    )
    
    rem подготавливаем нужный IP и шлюз
    SET IP=10.%dec_d%.%dec_e%.%dec_f%
    SET GATEWAY=10.%dec_d%.0.1
    
    rem меняем параметры интерфейса на реальные
    netsh interface ip set address local static %IP% %MASK% %GATEWAY% 1
    netsh interface ip set dns local static %GATEWAY%

    Добавляем этот скрипт в автозагрузку — например, так (требуется перезагрузка):
    reg ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "mac2ip" /t REG_SZ /d "c:\init\mac2ip.bat"

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

    Возможно, эта схема добавит наглядности (по клику — полный размер в новом окне):


    6. Замечания


    Используемый нами способ — со скриптом mac2ip в автозагрузке — оказался довольно медленным в Win XP. Во всяком случае, текущая его реализация делает свою работу 10-15 секунд. При этом время, которое уходит от старта виртуальной машины до начала выполнения скрипта mac2ip, составляет 15-20 секунд.

    Однако мы не спешим перейти на использование первого способа (DHCP с привязкой IP к MAC), потому что:

    — во-первых, VM у нас завершаются не штатным для них способом (т.е. centos/windows не выполняют завершение работы), а выполнением virsh destroy для VM (всё равно, что питание выдернуть). Это позволяет экономить много времени, а целостность использованной VM нас всё равно не интересует — она будет немедленно удалена после использования. Так вот, арендованный VM адрес не будет в этом случае освобождён сразу, а будет освобождён по истечении default-lease-time DHCP. Это значит, что мы не сможем сразу же запустить VM с таким же MAC (и таким же IP). Вряд ли установка default-lease-time слишком маленьким (секунды) — хорошая идея. Более реальный вариант — изучение и использование OMAPI/omshell, и с их помощью удалять ненужные записи DHCP сразу после остановки VM.

    — во-вторых, для Linux получение адреса от DHCP будет происходить медленнее, чем текущий вариант с назначением статического адреса.

    — в третьих — конечно, обнаружатся и другие подводные камни.

    Так что относительно медленная работа текущей версии скрипта в Windows — недостаточная причина для того, чтобы перейти на использовать варинанта с DHCP.

    Идеальным решением было бы ускорение работы скрипта mac2ip для Windows. Буду рад советам — поскольку это мой первый опыт в управлении сетевым интерфейсом windows из скриптов, то, возможно, уже имеется велосипед.


    Update: Во-первых, The_Kf открыл глаза на банальный способ получения MAC на выключенном интерфейсе с помощью ipconfig.
    Во-вторых, gribozavr провёл эксперимент, который показал, что заботиться о lease-time арендованного IP вообще не надо, потому что при привязке IP к MAC DHCP выдаст IP в любом случае машине с тем же MAC, даже ели аренда не истекла. Также он указал на stateless autoconfiguration из IPv6.
    В-третьих, при общении с akshakirov я внезапно понял, почему сразу более пристально не смотрели в сторону DHCP.

    Update 2: в-четвёртых, amarao предложил использовать xenstore для передачи IP в VM. В гостевой Linux-машине для этого просто надо установить xenstore-utils, однако для винды, возможно, потребуется написать утилиту для чтения из xenstore.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 74

      +3
      >Однако утилита getmac, которую мы будем использовать для получения мак-адреса сетёвки, не может вернуть MAC для того интерфейса, который выключен!

      Очевидно, что когда драйвер сетевой карты выгружен, то мак-адрес взять неоткуда. Следовательно, надо не отключать сетевое подключение, а, например, отключать на нём поддержку TCP/IP.
        0
        Ух ты, интересная идея, спасибо, проверю и напишу. Надеюсь, это тоже несложно сделать более-менее стандартными средствами Windows.
        +1
        Мы используем первый вариант и я уверен, — мы не одни такие.
        Ни один из описанных «минусов» за несколько лет работы не проявился.
        DHCP-сервер — прост как лом, его конфигурирование или переконфигурирование (у нас за три года это было лишь единожды) занимает считанные минуты даже для человека, кот. первый раз в жизни с ним встречается. И это уж точно проще чем написание/тестирование предложенного mac2ip
        Но я уверен, вы получили массу удовольствия в процессе изобретения велосипеда :)
          0
          А как насчёт нештатного завершения виртуальных машин, без освобождения ими адресов, взятых в аренду? Это существенно экономит время.
          Насколько много у вас машин и как часто они создаются?
          Для конкретики — например, у меня есть пул на 100 IP, в каждый момент времени поднято 50 машин, каждая машина работает 2-5 минут. С текущим подходом при создании свежей машины я точно знаю, что IP уже не используется, т.к. предыдущая машина с ним destroyed.

          Если я правильно понимаю, для использования DHCP мне надо будет или завершать машины штатным способом, теряя ресурсы на это, или общаться с DHCP? чтобы освободить адреса.

          В любом случае — вы правы, я получил массу удовольствия )
            +2
            У вас целая /8 и можно IP адреса не переиспользовать сразу же, а выдавать циклически.
              0
              Да, сейчас — целая /8, потому что всё работает на локальных серверах, стоящих в офисе )
              Но при размещении системы на у какого-либо првайдера, что скоро планируется делать, может оказаться, что адреса надо экономить + диапазоны могут быть с разрывами.
                +1
                Тогда mac2ip станет довольно нетривиальным, не находите?
                  0
                  Мне кажется, что за исключением первого байта IP — он довольно универсален.
                    0
                    А кто вам «у провайдера» даст /8 global IPv4 адресов?
                      0
                      Но ведь я же и говорю, что поэтому и не рассчитываю на них.
                        0
                        А скрипт mac2ip ещё и как рассчитывает именно получить в своё распоряжение /8.
                          0
                          Нет, он не рассчитывает на это. Сейчас он рассчитывает только на то, что все доступные адреса будут находиться в одной подсети /8.
                          Ведь если выданные мне 100 адресов начинаются на один и тот же байт — это же не означает, что я владею всей подсетью /8? )
                            0
                            А, понятно, вы будете генерировать MAC адреса не случайным образом, а в зависимости от доступного диапазона.
                              0
                              Точно, ядро знает, какие свободны адреса, генерит соответствующие MAC, и с ними запускает VM.
                  0
                  Если размещать систему где-то, то можно использовать те же частные диапазоны и VPN для доступа.
                0
                у вас пул 256^3 — дефицита адресов как-то не наблюдается
                а для того, чтобы с DHCP не общаться — выставьте на нем lease time в низкое значение

                  0
                  Да, низкое значение lease time было бы выходом. Однако с учтом того, что я не расчитываю на такой большой пул, потребуются слишком маленькие значения, идеально — секунды. Допустимо ли это?
                  +1
                  Если после уничтожения виртуальной машины создатётся новая VM с тем же MAC-адресом, разве DHCP-сервер просто не выдаст новой VM тот же самый IP-адрес, что был у уничтоженной VM?
                    0
                    gribozavr уже проверил ниже — выдаст, и это отличные новости.
                    0
                    Какая разница как часто они создаются и как они удаляются?
                    Вы, создавая новую машину, уже знаете какой mac ей будете задавать, — не создадите же вы две машины с одинаковым mac`ом?
                    Дело DHCP-сервера — выдать ip по вашему mac`у используя внутреннюю статическую таблицу mac->ip, он не будет разбираться включена еще одна машина с таким адресом или нет.
                      0
                      Да, этот вопрос уже прояснили — вы правы.
                  +1
                  1) После того, как виртуальная машина поднялась, она получает случайный адрес от DHCP, и затем каким-то образом регистрирует себя в базе — т.е. указывает, что я — машина такого-то типа, получила от DHCP такой-то адрес.

                  1) Avahi
                  2) tools.ietf.org/html/rfc2136

                  А вообще вы изобрели stateless autoconfiguration из IPv6 на коленке. В вашем случае как раз проблеем совместимости нет (нет необходимости в IPv4, весь софт под вашим контролем) и можно использовать IPv6 непосредственно.
                    0
                    Спасибо, я почитаю про avahi/bonjour.

                    Если я правильно понял, именно этот метод (полное автоопределение IP) — нам не очень подходит, хоть в нём явно и не участвует DHCP. Проще и удобнее знать IP машины заранее и контролировать её состояние (поднялась она или нет), чем делать машину «самостоятельной».
                    Кроме того, всё равно остаётся проблема установления соответствия «машина, которую запустило ядро» — «машина, которая только что получила случайный IP и зарегистрировалась».
                      +1
                      OK, возможно avahi вам не совсем подходит.

                      Но в stateless autoconfiguration IPv6 адрес однозначно определяется MAC адресом по адресу сети.
                        0
                        Пока ничего об этом, обязательно почитаю.
                        Однако перевод всей системы с IPv4 на IPv6 хотя и неизбежная вещь, но, думаю, куда более сложная, чем написание mac2ip (
                          0
                          А можете описать характер сложностей? Технические (старые маршрутизаторы, IP адреса хранятся в базе как uint32, ad-hoc парсеры IP адресов в shell скриптах), организационные (неизвестная технология для персонала)?
                            0
                            Я сейчас не могу проконсультирваться с нашим админом, чтобы точно узнать о сложностях (и, действительно, так ли они велики).

                            Первое, что приходит на ум — нужно переделать kickstarts шаблонов VM и xen-серверов. (Xen-сервера объединеняются в облако — поэтому всё не ограничится просто правкой нескольких уже работающих серверов).
                            Параметры запуска Selenium RC и Selenium HUB используют IPv4 или hostnames, не знаю, честно говоря, как там сейчас с IPv6.

                            Но, думаю, самое страшное не само изменение всего на IPv6, а тестирование и вылавливание трудных багов, которые непременно будут.
                    +2
                    должно знать IP-адреса машин, которые только что были запущены по её требованию.

                    так через xen api элементарно же узнается IP гостя, сразу же после старта сети

                     
                        def get_ip_addr(self,vm_ref):
                            vgm = self.session.xenapi.VM.get_guest_metrics(vm_ref)
                            try:
                                os = self.session.xenapi.VM_guest_metrics.get_networks(vgm)
                                if "0/ip" in os:
                                    return os["0/ip"]
                                return None
                            except:
                                return None
                      0
                      Это тоже интересная идея, и об этом мы не подумали, спасибо.

                      Однако этот вариант тоже не решает проблему с освобождением адресов, выданных DHCP при нештатном завершении.
                      Кроме того, если сейчас можно пинговать VM, ожидая, пока она поднимется (это делается раз в пару секунд), в этом варианте необходимо будет с тем же интервалом подключаться к xen-серверу по ssh и выполнять на нём этот скрипт.
                        +1
                        > Кроме того, если сейчас можно пинговать VM

                        в ксене гостя можно считать поднавшимся после того как считывается его имя через API

                        self.session.xenapi.VM.get_name_label(vm_ref)

                        читаете с sleep(1) пока оно не появится

                        пинг же вам показывает что сеть поднялась
                        но это не означает, что всё остальное уже работает

                        >варианте необходимо будет с тем же интервалом подключаться к xen-серверу по ssh

                        в случае использование xenAPI вам не понадобится ssh
                        вы будете подключаться к апи серверу через http(s)

                        т.е. подключились с логином паролем админа ксена
                        получили сессию
                        self.session = xen.Session(self.server_addr)
                        self.session.login_with_password(self.user,self.password)
                        и в рамках этой сессии удалённо выполняете все команды
                        self.session.xenapi.VM.get_name_label(vm_ref)

                          0
                          >> пинг же вам показывает что сеть поднялась
                          >> но это не означает, что всё остальное уже работает

                          Конечно, это только первый уровень проверки готовности VM.

                          >> в случае использование xenAPI вам не понадобится ssh
                          >> вы будете подключаться к апи серверу через http(s)
                          Да, это, возможно, более быстрый вариант. Хотя всё равно менее удобно, чем просто пинговать.

                          Однако этот подход решает проблему в сопоставлении поднятой VM с выданным DHCP IP. Однако остаётся проблема с освобождением адреса при нештатном завершении.
                            +1
                            ну поставте lease-time в минуту
                              0
                              это слишком много, я написал выше, на какие примерно условия мы ориентируемся:
                              «например, у меня есть пул на 100 IP, в каждый момент времени поднято 50 машин, каждая машина работает 2-5 минут»

                              Даже при lease time в минуту учёт гарантированно свободных в настоящий момент IP ощутимо усложнится.
                              Но да, если рассчитывать на большой пул адресов, это нормальный вариант. Правда, linux-то всё равно будет получать IP от DHCP дольше, чем сейчас )
                                +1
                                > Правда, linux-то всё равно будет получать IP от DHCP дольше, чем сейчас

                                странно, что у вас появилась эта проблема
                                у меня центОС 56 почти мгновенно получает
                                  +1
                                  Я не совсем серьёзно об этом говорил ) Да, вероятно, разница не будет существенной.
                      0
                      > Первый вариант казался нам довольно сложным по нескольким причинам…

                      Я бы предложил использовать zeroconf/avahi, он как раз для этого замечательно подходит.
                        0
                        Если вы назначаете MAC-и самостоятельно, то можно сразу статику по тому же шаблону прописать в DHCP.
                          0
                          Верно, но об этом варианте я писал:
                          «Мы запустим DHCP сервер, который будет настроен так, чтобы выдавать IP по MAC-адресу в соответствии с описанным способом кодирования»
                          Однако, с нашей точки зрения, у него есть пара недостатков.
                            0
                            Поделитесь пожалуйста вашим мнением относительно недостатков.
                              0
                              Я рассказал о них неоднократно — в самом посте, а также в комментариях. В частности, об этом говорится в разделе 6.
                                +1
                                Первая часть, пара лишних секунд действительно так критична?
                                Вторая, если прописывать статику этой проблемы не будет.
                                  0
                                  Нормальное завершение будет занимать несколько дольше, чем 2 секунды. Но ведь mac2ip на винде работает сопоставимое время.

                                  Хм, я только сейчас сообразил, что решение мы выбирали тогда, когда работали только с VM на linux, поэтому mac2ip был идеальным во всех отношениях вариантом.
                                  Собственно, сложность появилась только со временем работы на винде (правда, первый комментарий на пост открывает перспективы для оптимизации скрипта).

                                  Если не удастся радикально сократить время работы скрипта на винде — то в целом получится, что преимущество в mac2ip только в том, что эта схема уже отлажена и надёжно работает.
                                    0
                                    Выглядит очевидным простое решение, линуксы пусть статику назначают себе вашим скриптом, а винды пусть берут статично прописанные ip из dhcp.
                                      +1
                                      Тоже вариант, но, думаю, минус того, что надо поддерживать две разные системы, перевешивает небольшой выигрыш по времени.
                                        +1
                                        тогда я возвращаюсь к своему первому предложению, используйте dhcpd в конфиге у которого статично прописаны все маки и ip адреса. Костылей лучше избегать…

                                        И поддерживать dhcp не нужно, вы сразу все возможные мак адреса прописываете.
                                          +1
                                          Да — вероятно, теперь так и сделаем.
                          +1
                          Непонятно, зачем вы так странно получаете MAC в Виндоуз, если для этого можно использовать штатную утилиту ipconfig или WMI.
                            0
                            getmac не менее стандартна, чем ipconfig )
                              +1
                              Тем не менее, ipconfig и WMI показывают отключённые интерфейсы.
                                0
                                Хм, а вот это просто чудесно, вы чертовски правы!

                                Даже жалко, что после комментария gribozavr и обсуждению с akshakirov mac2ip, скорее всего, не понадобится.
                            –1
                            Не уверен, т.к. не пробовал. Но не будет ли быстрее и проще без DHCP делать это через реестр: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
                              +1
                              Так вот, арендованный 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
                              хард-резет
                              После этого машина нормально загрузилась и получила свой адрес.
                                +1
                                gribozavr, вот это отличные новости, спасибо за эксперимент!

                                Я попрошу нашего админа проверить то же самой на нашей конфигурации — если всё так, то тогда mac2ip снимем и повесим на стенку в рамочку. Надеюсь, о нём хотя бы интересно было почитать:)
                                  +1
                                  Обязательно протестируйте, особенно с Windows клиентом (где именно там хранится информация DHCP клиента я не знаю, поэтому лучше запустите свежий клон с тем же MAC).
                                    0
                                    Ок.
                                    Кстати, на всякий случай, какое значение lease-time сейчас у DHCP?
                                      0
                                      В смысле? У меня установлено в 600, для этого теста увеличил до 3600.
                                        +1
                                        Да, именно это и хотел узнать, спасибо. Вдруг бы оно был меньше времени, которое ушло на ребут )
                                +1
                                Как всё сложно. А использовать паравиртуализованную БД для хранения IP не судьба? Тот же xenstore решит все проблемы (наверняка у VMWare есть что-то подобное).
                                  0
                                  Правильно я понимаю, что предварительно придётся:
                                  1) конфигурировать каждый xen в облаке дополнительно, устанавливая соответствие типа имя домена-IP
                                  2) как следствие, общий пул адресов разобъётся ещё на пулы для каждого из xen-серверов
                                  3) нельзя будет использовать произвольные имена VM?

                                  Кроме того, очевидно, ядро системы опять-таки будет вынуждено знать о настройках каждого из xen.
                                  Чем этот вариант лучше варианта с DHCP?
                                    +1
                                    Э… Не совсем. В атрибуты VM пишется IP (я бы это писал в атрибуты VIF), делать это может скрипт, который машину клонирует. (Кстати, он может по любому удобному алгоритму это делать, хоть по MAC'у, хоть по списку, хоть по времени создания, хоть по каким ещё параметрам). Дальше VM при старте смотрит свой IP и назначает его.

                                    Плюс: смена алгоритма генерации IP потребует изменения в одном месте и будет применена к существующим машинам (после их перезагрузки). Аналогично может быть проблема смены сетевых настроек (шлюз, номер сети и т.д.).
                                      0
                                      >> делать это может скрипт, который машину клонирует
                                      скрипт так и делает, то прописывает MAC, а не IP.

                                      >> Дальше VM при старте смотрит свой IP и назначает его.
                                      Я был уверен, что IP невозможно напрямую передать в VM…
                                      Поясните, пожалуйста, какими именно средствами VM смотрит на свой IP и как назначает его? Кто этим занимается, сама VM или каким-то образом xen? Какой именно атрибут испльзуется для того, чтобы прописать IP? Это имеет отношение к xenstore, или это уже другой вариант?

                                      >> смена алгоритма генерации IP потребует изменения в одном месте и будет применена к существующим машинам (после их перезагрузки
                                      это есть и при текущем подходе, всеми IP заведует ядро системы.
                                        +1
                                        Э… ребята, позоритесь. Лучшее изобретение Xen'а для Cross-Domain-Communication: XenStore.

                                        Ставите в гостя утилиты xenstore-utils (есть в большинстве дистрибьютивов) и можете делать xenstore-read, xenstore-write.

                                        Для развлечения сделайте из dom0 xenstore-ls, вас обрадует.
                                          +1
                                          >> и можете делать xenstore-read, xenstore-write.
                                          ага, понял, это хороший вариант для Linux.

                                          Но я навскидку не нашёл, поэтому спрошу — есть ли xenstore-utils для Windows?
                                            +1
                                            Я с виндами вообще плохо, но, поскольку xenbus используется для поиска PV-драйверов, то доступ из HVM с виндами есть, драйвер есть. Насколько я понимаю, есть библиотека, так что написать простенький xenstore-read не так уж и сложно. гугль подсказывает: svn.zentific.com/trunk/Zentific-Tools/win32/zentsrv/xenstore.c
                                              0
                                              Смотрите, MAC на винде я могу получить стандартными для винды способами. Преобразовать его в IP — пара строчек в скрипте.

                                              Ваш вариант позволит получить сразу IP, однако для этого придётся писать обёртку к xenstore-read. По-моему, это в данном случае совершенно лишнее звено.
                                                +1
                                                Э… Извиняюсь, а откуда ваша сетевая карта в виндах знает свой MAC? (это подсказка).
                                                  0
                                                  Я это понимаю следующим образом.
                                                  Xen эмулирует устройство — сетевую карту.
                                                  Думаю, что для винды это сэмулированное устройство ничем не отличается от реальной сетёвки.
                                                  Сетёвки обязаны иметь параметр «MAC». Раз xen эмулирует устройство, он имеет возможность установить этот параметр для сэмулированной сетёвки, соответственно, мы имеем возможность этот параметр задать в конфиге.

                                                  Если это так, то:
                                                  1) xenstore тут ни при чём
                                                  2) передача IP через параметры сетёвки таким способом невозможна, поскольку стандартные сетёвки не несут на себе сведений об IP
                                                    0
                                                    Если у вас 'xen эмулирует сетевую карту', то у вас используются qemu драйвера, а это безумно медленно. Вероятнее всего у вас стоят gplpv или citrix'овские PV-драйвера. А теперь вопрос — откуда они читают свои параметры?

                                                    Все паравиртуализированные устройства анонсируются и читают свои настройки через xenstore. Я ж сказал, сделайте xenstore-ls в dom0.
                                                      0
                                                      К сожалению (или счастью), xen занимается наш админ, и я плохо разбираюсь в том, как происходит виртуализация устройств. Поэтому пока не могу вести диалог с вами на этом уровне.

                                                      Однако, даже если виртуализированные устройства читают свои настройки из xenstore, это ничего не меняет в моём утверждении, что MAC можно передать через настройки сетёвки (а потом получить стандартными средствами винды), а IP — нельзя.
                                                      Это верно?
                                                        0
                                                        Все PV устройства общаются с Xen, и поэтому их драйвера к стандартным средствам винды не относятся.
                                                          +1
                                                          Выше человек уже написал — если вы ставите pv-драйвера, значит, как минимум, вы уже что-то в машину ставите. Использовать xenstore — куда более логичное решение для IDC, чем странные манипуляции с mac-адресами (попытка изготовить ipv6 из ipv4?)
                                                            +1
                                                            amarao, скорее всего, вы правы, и использование xenstore — даже при том, что потребуется писать xenstore-read для винды — более красивый и правильный вариант, поэтому я разберусь в том, как его реализовать и насколько сложно это будет для нас.

                                                            Рад, что пост получился таким продуктивным — я получил идеи ускорения текущего варианта решения своей задачи (хотя, скорее всего, мы от него и откажемся), и несколько идей, о которых совершенно не имел понятия — спасибо.
                                                              +1
                                                              Вообще, если собираетесь что-то делать с зеном, Definitive guide to xen hypervisor просто must read.
                                                                0
                                                                Спасибо — нашёл, просмотрел. Кажется, написано простым языком и интересно.

                                  Only users with full accounts can post comments. Log in, please.