Вопрос
При удаленном изменении сетевых конфигураций существует ли возможность для сети попытаться использовать другой файл конфигурации в случае сбоя?
Фон- tldr;
Я искал, но не видел никаких ссылок на что-то вроде передачи файла в ifup, хотя это и натолкнуло меня на мысль проверить страницу руководства ifup, но все равно. Я не могу проверить это прямо сейчас.
Наш сервер переместили в центр обработки данных, пока я работаю в другом городе. Сетевые технологии — не моя сильная сторона, и после установки я хотел объединить две сетевые карты вместе, чтобы улучшить пропускную способность. Но при этом я потерял связь, так как сетевой интерфейс не смог инициализироваться.
Я попытался настроить связь в /etc/sysconfig/network-scripts
bond0: Берем eth0 и eth1 eth0: Настраиваем для связывания eth1: Настраиваем для связывания, а затем eth1:1, думая, что смогу привязать к нему IP-адрес на случай, если меня снова заблокируют...
К сожалению, это не сработало, и единственный человек, достаточно квалифицированный, чтобы пойти в центр обработки данных и оказать поддержку, — это мой босс. Нехорошая ситуация. (И я дважды проверял это на виртуальном сервере, просто чтобы убедиться, что не потеряю соединение)
Теперь мы его подключили, но, насколько я могу судить, нет возможности сделать конфигурацию «на всякий случай»...
Поэтому сегодня мне нужно было установить соединение для виртуальной машины внутри сервера.... И вот, я снова потерял соединение, и это уже вторая поездка моего босса в центр обработки данных в этом месяце. :facepalm:
Должен быть способ, при котором, если интерфейс не определен как работающий, сеть будет использовать совершенно другой набор файлов конфигурации, отказоустойчивый, если можно так выразиться, так, чтобы после неудачной попытки подключения к сети задание cron, запускаемое каждые пять минут, восстанавливало сетевое соединение с отказоустойчивым, если сеть вышла из строя.
Хотелось бы иметь доступ к Linux-боксу прямо сейчас, но я обычно проверяю сеть, выполняя команду service network restart. Есть ли способ дать ему команду failsafe, которая, если сеть не обнаружена, в свою очередь попробует другую конфигурацию failsafe, пока не поднимется.
решение1
tl;dr: Используйте OOB, рассмотрите управление конфигурацией, или вам придется создавать собственное решение.
Я не знаком ни с чем готовым в Linux-land для таких вещей - обычно это IPMI/ILOM/OOB. Вы не только получите удаленный консольный доступ к хосту, но и сможете (обычно) проверить состояние оборудования, выполнить удаленную перезагрузку, если оно жестко заблокировано и т. д. и т. п.
Если OOB невозможен, вы можете рассмотреть возможность настройки задания cron для проверки различных сценариев и определения того, находится ли ваш хост в недоступном состоянии, а также выполнить задачи по его восстановлению.
Конечно, здесь есть большие риски. Вам нужно рассмотреть множество различных сценариев — скажем, вы хотите проверить, можете ли вы попасть на IP-адрес вашего шлюза, но ваш шлюз ненадолго отключается — вы не хотите, чтобы ваш хост перенастраивал свой интерфейс, если проблема не в вашем ящике, а в чем-то вышестоящем.
Также есть возможность управления конфигурацией, которую вы можете настроить для восстановления локальной машины до ожидаемого состояния/проверки ее нахождения в ожидаемом состоянии каждый час и т. д. — вам придется настроить эти приложения на использование локальной копии файлов конфигурации, а не пытаться связаться с удаленным сервером, но это возможно. Это может быть немного избыточно в зависимости от того, сколько систем вы управляете (а если их больше 5, я настоятельно рекомендую рассмотреть управление конфигурацией в целом, это сэкономит вам МНОГО времени).
Если вы чувствуете, что хотите пойти по пути, имея какой-то скрипт на мониторе ящика для изменений, я настоятельно рекомендую вам настроить его в режиме холостого хода на довольно долгое время. Таким образом, вы могли бы заставить его регистрировать, когда он посчитал бы, что ему нужно перенастроить сетевой интерфейс, что позволило бы вам отладить/протестировать/проверить работоспособность функциональности, прежде чем вы запустите его в эксплуатацию.
Еще лучше, если вы подключите к хосту второй или третий интерфейс (поскольку вы хотите объединить их) и либо никогда не трогайте конфигурацию этого интерфейса, либо пусть ваш скрипт попытается восстановить себя только с помощью этого интерфейса. Таким образом, если он выйдет из строя, он не будет затрагивать интерфейсы, которые он считает плохими, а только третий интерфейс, который вы используете только для этой цели.