Недавно я установил Ubuntu Utopic 14.04 LTS на новый серверный ящик, который я построил специально для размещения нескольких виртуальных машин. Сетевая конфигурация этого ящика, который содержит две сетевые карты, раскрывает две сетевые карты только через виртуальные мосты — одну в частную сеть, одну в общедоступный Интернет. Одна гостевая виртуальная машина будет получать доступ к обоим мостам через ответвления, выступая в качестве брандмауэра и шлюза для хоста в частности и частной сети в целом. Другая виртуальная машина будет просто отдельным гостевым сервером в частной сети. Хост будет напрямую участвовать в частной сети только через соответствующий частный мост.
В результате ни eth0, ни eth1 не будут "включены" только в контексте соответствующих им виртуальных мостов. Однако, когда загружается Ubuntu, я считаю, что отказоустойчивость upstart неправильно предполагает (настаивает?), что по крайней мере eth0 будет включен независимо, прежде чем она позволит системе преодолеть задержки в 20/40/60 секунд, которые накладывает отказоустойчивость. Однако задержки почти не имеют надежды на разрешение, пока загрузка не завершится и гостевые виртуальные машины не получат разрешение на запуск без ограничений! Видите парадокс? Честно говоря, я не уверен, что eth0 или eth1 будутвсегдадостижение состояния отказоустойчивости является требовательным.
На грубом, реакционном уровне, моя разочарованная, не-Ubuntu-сторона хочет вырвать Failsafe, потому что каждая перезагрузка для изменения конфигурации заставляет меня ждать до двух минут изменения статуса, которое, я на 99,9% уверен, никогда не произойдет.по дизайну. Итог - нет зависимости от отказоустойчивости. Я просто хотел бы, чтобы дополнительные обручи, которые, как я понимаю, отказоустойчивость заставляет просто уйти.
По той же причине я пытаюсь быть хотя бы немного непредвзятым в отношении того, что Upstart пытается сделать с отказоустойчивостью, поскольку это мое первое знакомство с ней. Я видел некоторую (очень смутную) информацию о том, что один из подходов к этому заключается в изменении способа настройки /etc/network/interfaces, перемещении моих настроек моста в их собственные задачи Upstart, но я бы действительно предпочел оставить свои определения интерфейсов в покое, довольными и работающими.
Итак, какой у меня выбор? Могу ли я просто убрать отказоустойчивую задачу или изменить ее, чтобы изменить ее условия? Если да, то как? Должен ли я взломать свой файл интерфейсов?
решение1
Во-первых, позвольте мне извиниться за то, что я отвечаю на свой собственный вопрос.
Во-вторых, я, по сути, победил проблему задержки запуска failsafe.conf. Хотя я понимаю, что по этому вопросу не было большого потока активности, я видел достаточно активности в различных других темах о похожих проблемах failsafe/boot delay, поэтому я публикую свое исследование и решение для пользы других в похожей ситуации.
Обзор
Как было отмечено в первоначальном посте, проблема, как я ее увидел, заключалась в том, что задание failsafe upstart накладывало нежелательное ограничение на загрузку моей системы. Затем я исследовал проблему глубже, выяснил, почему failsafe вел себя так, а не иначе.
Анализ
По умолчанию failsafe.conf определяет условие запуска, которое эффективно запускает его во время загрузки (как только файловая система и интерфейс loopback становятся доступны), и определяет одно из двух возможных условий остановки:
start on filesystem and net-device-up IFACE=lo
stop on static-network-up or starting rc-sysinit
Настойчивость Failsafe в отношении задержек возникла из-за того, что не было ни одного из событий «стоп». Второе условие, rc-sysinit, является одной из последних задач инициализации системы, которые upstart запускает, и имеет свое собственное условие запуска
start on (filesystem and static-network-up) or failsafe-boot
С отказоустойчивостью нетостановка, очевидно, rc-sysinit не являетсяначиная.Failsafe выдаст событие failsafe-boot по истечении тайм-аутов. Поскольку failsafe запущен, подразумевается 'filesystem', таким образом, единственным оставшимся условием, общим для обоих событий, является 'static-network-up'. Failsafe работает, потому что не считает, что какие-либо сетевые интерфейсы 'up'.
Причина
Проходя в обратном направлении через /etc/network/if-up.d, определяется сценарий upstart, который проходит по всем сетевым интерфейсам, определенным в /etc/network/interfaces, определенным с помощью квалификатора "auto", что означает, что интерфейс должен быть поднят во время загрузки. Определение того, как интерфейс считается "включенным", становится важной семантической проблемой, которую я опишу позже.
Если и только если все "автоматически" настроенные интерфейсы "включены", скрипт upstart выдаст знаменитое событие "static-network-up". Это, в свою очередь, позволит rc-sysinit запуститься и завершиться без сбоев - отсюда и корень моей проблемы. Ни один из моих сетевых интерфейсов не имеет IP-адреса во время загрузки - по замыслу. Но "static-network-up" не приемлет идею того, что интерфейс "включен"безIP-адрес, поэтому отказоустойчивый режим зависает до истечения времени ожидания.
В моей ситуации я подключаю два физических сетевых адаптера в коробке к мостам и открываю их через ответвления к двум разным виртуальным машинам. Одна виртуальная машина обслуживает DHCP через один ответвитель, другая — просто сервер в той же сети. Чтобы мосты работали правильно, как ответвления виртуальных машин, сетевые адаптеры должны быть как минимум «UP», пассивно пропуская пакеты. Поэтому «auto» показалось уместным в /etc/network/interfaces. Это былонетОднако с точки зрения отказоустойчивости это было уместно, поэтому единственным решением должно было быть такое, которое соответствовало бы семантике отказоустойчивости.
Таким образом, решение моей проблемы было двояким:
- Удалите объявление «auto» из каждого определенного мной сетевого интерфейса (кроме loopback).
- Создайте задания upstart, чтобы вручную запускать ранее «автоматические» интерфейсы.
Я определил одну задачу для каждого из четырех устройств — двух кранов и двух виртуальных мостов — путем имитации предоставленного решения.здесь.
В этой конфигурации без интерфейсов 'auto' сетевой скрипт должен немедленно выдать 'static-network-up', тем самым заставляя failsafe завершиться. Последняя модификация потребовала от меня добавить предложение "post-up" к определению интерфейса каждого крана для вызова 'brctl' и создания соответствующего виртуального моста, что ранее делалось как часть конфигурации 'auto'.
Итак, мой /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
Лакмусовая бумажка
Лакмусовая бумажка? Перезагрузил сервер. И когда я это сделал,время ожидания безотказной работы исчезло, и моя сеть появилась в функционально идентичной конфигурации. ЭТО РАБОТАЕТ!! Хотелось бы, чтобы мы лучше разбирались в семантике сетевого интерфейса "UP"!!