저는 최근 일부 가상 머신을 호스팅하기 위해 특별히 제작한 새 서버 상자에 Ubuntu Utopic 14.04 LTS를 설치했습니다. 두 개의 NIC가 포함된 이 상자의 네트워크 구성은 가상 브리지(하나는 개인 네트워크에, 다른 하나는 공용 인터넷)를 통해서만 두 개의 NIC를 노출합니다. 하나의 게스트 VM은 탭을 통해 두 브리지에 액세스하여 특정 호스트와 일반적으로 개인 네트워크에 대한 방화벽 및 게이트웨이 역할을 합니다. 다른 VM은 단순히 개인 네트워크의 별도 게스트 서버가 됩니다. 호스트는 해당 개인 브리지를 통해서만 개인 네트워크에 직접 참여합니다.
결과적으로 eth0이나 eth1은 해당 가상 브리지의 컨텍스트 외에는 "작동" 상태가 되지 않습니다. 그러나 Ubuntu가 부팅될 때 upstart의 비상 안전 장치는 시스템이 비상 안전 장치로 인한 20/40/60초 지연을 초과할 수 있도록 하기 전에 적어도 eth0이 독립적으로 작동한다고 잘못 가정(주장?)하고 있다고 생각합니다. 그러나 부팅이 완료되고 게스트 VM이 자유롭게 시작될 때까지 지연이 해결될 가능성이 거의 없습니다! 역설이 보이시나요? 솔직히 말해서 eth0이나 eth1이 그럴지는 잘 모르겠습니다.항상안전 장치가 요구하는 상태에 도달하십시오.
원시적이고 반동적인 수준에서 좌절감을 느끼고 Ubuntu가 아닌 쪽에서는 안전 장치를 제거하고 싶어합니다. 구성 변경을 위해 재부팅할 때마다 99.9% 확신하는 상태 변경을 위해 최대 2분을 기다려야 하기 때문입니다. 결코 일어나지 않는다디자인에 의해. 결론 - 안전 장치 종속성이 없습니다. 나는 안전 장치가 강요하는 추가 고리를 그냥 없애고 싶습니다.
마찬가지로, 저는 Upstart가 안전 장치를 통해 무엇을 하려고 하는지에 대해 적어도 어느 정도 열린 마음을 가지려고 노력하고 있습니다. 왜냐하면 이것이 제가 처음으로 접한 것이기 때문입니다. 이에 대한 한 가지 접근 방식이 /etc/network/interfaces 설정 방식을 변경하고 브리지 설정을 자체 Upstart 작업으로 이동하는 것과 관련된 일부 (매우 모호한) 정보를 보았지만 실제로는 인터페이스 정의를 그대로 두는 것을 선호합니다. , 행복하고 일하고 있습니다.
그렇다면 나의 선택은 무엇인가? 안전 장치 작업을 제거하거나 수정하여 조건을 변경할 수 있습니까? 그렇다면 어떻게? 인터페이스 파일을 해킹해야 합니까?
답변1
먼저 제 질문에 답변을 드려 죄송합니다.
둘째, 저는 실제로 passsafe.conf 시작 지연 문제를 극복했습니다. 이 질문에 대한 활동이 급증하지 않았다는 것을 알고 있지만 유사한 안전 장치/부팅 지연 문제에 대한 다양한 다른 스레드에서 충분한 활동을 보았으며 유사한 피클에 다른 사람들의 이익을 위해 연구 및 솔루션을 게시하고 있습니다.
개요
초기 게시물에서 언급했듯이, 내가 본 문제는 비상 안전 시작 작업이 내 시스템 부팅에 원치 않는 제약을 가하는 문제였습니다. 그런 다음 문제를 더 자세히 조사하여 안전 장치가 왜 그렇게 작동하는지 알아냈습니다.
분석
기본적으로failsafe.conf는 부팅 시(파일 시스템과 루프백 인터페이스를 사용할 수 있게 되자마자) 효과적으로 실행하는 시작 조건을 정의하고 가능한 두 가지 중지 조건 중 하나를 정의합니다.
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 이벤트를 발생시킵니다. 안전 장치가 시작되면 '파일 시스템'이 암시되므로 두 이벤트에 공통적으로 남아 있는 유일한 조건은 '정적 네트워크 작동'입니다. 네트워크 인터페이스가 '작동 중'이라고 생각하지 않기 때문에 비상 안전 장치가 실행 중입니다.
원인
/etc/network/if-up.d를 통해 뒤로 작업하면 "auto" 한정자로 정의된 /etc/network/interfaces에 정의된 모든 네트워크 인터페이스를 반복하는 upstart 스크립트가 정의됩니다. 즉, 인터페이스가 표시됩니다. 부팅 시. 인터페이스가 '위'로 간주되는 방식에 대한 정의는 나중에 설명할 중요한 의미론적 문제가 됩니다.
"자동"으로 구성된 모든 인터페이스가 'up'인 경우에만 upstart 스크립트는 유명한 'static-network-up' 이벤트를 발생시킵니다. 그러면 rc-sysinit가 안전 장치를 실행하고 종료할 수 있으므로 문제의 근본 원인이 됩니다. 의도적으로 내 네트워크 인터페이스에는 부팅 시 IP 주소가 없습니다. 그러나 '정적 네트워크 업'은 인터페이스가 '업'된다는 개념을 따르지 않습니다.없이IP 주소이므로 시간 초과가 만료될 때까지 안전 장치가 정지됩니다.
내 상황에서는 상자에 있는 두 개의 물리적 NIC를 브리지에 종속시키고 탭을 통해 두 개의 다른 VM에 노출합니다. 한 VM은 한 탭에서 DHCP를 제공하고 다른 VM은 동일한 네트워크에 있는 서버입니다. VM의 탭에 따라 브리지가 제대로 작동하려면 NIC가 최소한 "UP" 상태여야 하며 수동적으로 패킷 통과를 허용해야 합니다. 따라서 /etc/network/interfaces에서는 'auto'가 적절해 보였습니다. 그것은~ 아니다그러나 안전 장치의 관점에서는 적절하므로 유일한 해결책은 안전 장치의 의미를 준수하는 것이어야 했습니다.
내 문제에 대한 해결책은 두 가지였습니다.
- 내가 정의한 모든 네트워크 인터페이스(루프백 제외)에서 'auto' 선언을 제거합니다.
- 이전의 "자동" 인터페이스를 "수동으로" 불러오려면 시작 작업을 만듭니다.
제공된 솔루션을 모방하여 4개의 장치(2개의 탭과 2개의 가상 브리지) 각각에 대해 하나의 작업을 정의했습니다.여기.
'auto' 인터페이스가 없는 이 구성에서는 네트워킹 스크립트가 이제 즉시 'static-network-up'을 내보내므로 비상 안전 장치가 강제로 종료됩니다. 마지막 수정에서는 'brctl'을 호출하고 이전에 'auto' 구성의 일부로 수행되었던 해당 가상 브리지를 생성하기 위해 각 탭의 인터페이스 정의에 "post-up" 절을 추가해야 했습니다.
따라서 내 /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" 네트워크 인터페이스의 의미를 더 잘 이해할 수 있었으면 좋겠습니다!!