Как мне настроить Ubuntu / Upstart для необычной конфигурации сети?
Я недавно установил Ubuntu Utopic 14.04 LTS на новый серверный блок, который я специально создал для размещения некоторых виртуальных машин. Конфигурация сети для этого блока, который содержит два сетевых адаптера, предоставляет два сетевых адаптера только через виртуальные мосты - один для частной сети, другой для общедоступного Интернета. Одна гостевая виртуальная машина будет получать доступ к обоим мостам через ответвления, выступая в качестве брандмауэра и шлюза для хоста в частности и для частной сети в целом. Другая виртуальная машина будет просто отдельным гостевым сервером в частной сети. Хост будет напрямую участвовать только в частной сети через соответствующий частный мост.
В результате ни eth0, ни eth1 не будут только «вверх», кроме контекста их соответствующих виртуальных мостов. Однако, когда Ubuntu загружается, я полагаю, что отказоустойчивый upstart неправильно предполагает (настаивает?), Что хотя бы eth0 будет работать независимо, прежде чем это позволит системе преодолеть 20/40/60 секундных задержек. Тем не менее, задержки почти не дают надежды на их устранение до тех пор, пока загрузка не завершится, а гостевой виртуальной машине разрешено запускаться беспрепятственно! Видишь парадокс? Честно говоря, я не уверен, что eth0 или eth1 когда-либо достигнут состояния, требующего безопасности.
На сыром, реакционном уровне разочарованная сторона, не связанная с Ubuntu, хочет избавиться от отказоустойчивости, потому что каждая перезагрузка для изменения конфигурации вынуждает меня ждать до двух минут для изменения состояния, которое я на 99,9% уверен, что никогда не случится по замыслу . Итог - безаварийная зависимость. Я просто хотел бы сделать дополнительные обручи, которые, как я понимаю, отказоустойчивые заставляют просто уйти.
К тому же, я пытаюсь быть, по крайней мере, несколько непредубежденным в отношении того, что Upstart пытается сделать с отказоустойчивым, так как это мое первое знакомство с ним. Я видел некоторую (очень расплывчатую) информацию, что один из подходов к этому включает изменение способа настройки / etc / network / interfaces, перемещение моих настроек моста в их собственные задачи Upstart, но я действительно предпочел бы оставить определения моего интерфейса в покое , счастлив, и работает.
Итак, каков мой выбор? Могу ли я просто устранить отказоустойчивое задание или изменить его, чтобы изменить его условия? Если так, то как? Должен ли я взломать мой интерфейсный файл?
1 ответ
Во-первых, позвольте мне принести извинения за ответ на мой собственный вопрос.
1112-секундный, я, на самом деле, завоевал проблему задержки запуска failsafe.conf. В то время как я понимаю, что не было никакого потока действия по этому вопросу, я видел достаточно действия по различным другим потокам о подобных отказоустойчивых проблемах задержки / проблемах задержки начальной загрузки, что я отправляю свое исследование и решение в пользу других в подобном рассоле.
Обзор
, Как отмечено в первом сообщении, проблема, поскольку я видел, что это было то, где отказоустойчивое новомодное задание налагало нежелательное ограничение на начальную загрузку моей системы. Я тогда исследовал проблему далее, узнанный, почему отказоустойчивый вел себя, как это было.
Анализ
По умолчанию, failsafe.conf определяет условие запуска, которое эффективно запускает его во время начальной загрузки (как только файловая система и петлевой интерфейс доступны), и определяет одно из двух возможных условий остановки:
start on filesystem and net-device-up IFACE=lo
stop on static-network-up or starting rc-sysinit
настойчивость Failsafe на задержки не возникла на основании никакого увольнения события 'остановки'. Второе условие, дистанционное-управление-sysinit, является одним из заключительных системных новомодных выполнений задач инициализации, которое имеет ее собственное условие запуска
start on (filesystem and static-network-up) or failsafe-boot
С отказоустойчивым не остановка , это - очевидное дистанционное-управление-sysinit, не запуск. Отказоустойчивый испустит событие отказоустойчивой начальной загрузки, как только его тайм-ауты истекают. Учитывая отказоустойчивый запустился, 'файловая система' подразумевается, таким образом оставляя единственное остающееся условие характерным для обоих событий, являющихся 'static-network-up'. Отказоустойчивый работает, потому что это не думает, что любые сетевые интерфейсы возросли.
причина
Работа назад через/etc/network/if-up.d, новомодный сценарий определяется, который выполняет итерации через все сетевые интерфейсы, определенные в/etc/network/interfaces, определенном с "автоматическим" спецификатором, означая, что интерфейс должен быть поднят во время начальной загрузки. Определение того, как интерфейс рассматривают, становится важной семантической проблемой, которую я опишу позже.
, Если и только если все "автоматические" - настроенные интерфейсы произошли, новомодный сценарий испустит знаменитое 'static-network-up' событие. Это, в свою очередь, позволило бы дистанционному-управлению-sysinit стрелять и завершаться отказоустойчивый - следовательно первопричина моей проблемы. Ни один из моих сетевых интерфейсов не имеет IP-адрес во время начальной загрузки - дизайном. Но 'static-network-up' не выносит идею интерфейса, являющегося без , IP-адрес, следовательно отказоустойчивый, зависает, пока тайм-ауты не истекают.
Для моей ситуации, я назначаю два физических NIC ведомым устройством в поле к мостам и представляю их через касания к двум различным VM's. Один VM подает DHCP через одно касание, другой просто сервер в той же сети. Для мостов для функционирования правильно, как коснулись VM's NIC должен, по крайней мере, произойти, пассивно позволив пакеты через. Следовательно, 'автоматический' казался соответствующим в/etc/network/interfaces. Это было не соответствующее, однако, в глазах отказоустойчивых, следовательно единственным решением должно было быть то, которое вынесло семантику failsafe.
решение моей проблемы, тогда, было двукратным:
- Удаляют 'автоматическое' объявление из каждого сетевого интерфейса, который я определил (кроме обратной петли).
- Создают новомодные задания для перевода в рабочее состояние ранее "автоматических" интерфейсов "вручную".
я определил одно задание четыре каждое из четырех устройств - два касания и два виртуальных моста - путем имитации решения обеспечили здесь .
В этой конфигурации, без 'автоматических' интерфейсов, сетевой сценарий должен теперь сразу испустить 'static-network-up', таким образом вынудив отказоустойчивый завершиться. Заключительная модификация потребовала, чтобы я добавил "пост" пункт к интерфейсному определению каждого касания, чтобы назвать 'brctl' и создать соответствующий виртуальный мост, ранее сделанный как часть 'автоматической' конфигурации.
Так, мой/etc/network/interfaces (частично) теперь похож:
#auto tpRED (commented out)
iface tpRED inet manual
pre-up /usr/sbin/tunctl -t tpRED
post-up /sbin/brctl addbr brRED
#auto brRED
iface brRED inet manual
bridge_ports eth1 tpRED
bridge_hw xx:yy:aa:bb:cc:dd
испытание на кислотность
испытание на кислотность? Перезагрузите сервер. И когда я сделал, , отказоустойчивый тайм-аут увели , и моя сеть подошла в функционально идентичной конфигурации. РАБОТЫ IT!! Мне просто жаль, что у нас не было лучшего дескриптора на семантике сетевой интерфейс!!